No necesitas saber programar para explicar qué debe hacer tu software. Sí necesitas describir el trabajo que quieres mejorar: quién participa, qué información utiliza y cómo se reconoce un resultado correcto. Una buena definición permite al equipo técnico hacer mejores preguntas y comparar soluciones con menos suposiciones.

Empieza por el resultado de negocio

Describe una situación observable. «Queremos responder las solicitudes sin perder el seguimiento» es más útil como punto de partida que «necesitamos una aplicación moderna». Después indica cómo se hace hoy y qué dificulta el trabajo: información dispersa, pasos repetidos, demoras o falta de claridad sobre responsables.

Elige una medida que puedas observar antes y después, por ejemplo el tiempo entre la recepción de una solicitud y su asignación. Registra cómo se mide y quién revisará el resultado; no presupongas que todo cambio producirá ahorro.

Identifica personas y recorrido principal

Lista los roles que interactúan con el proceso: quien solicita, quien atiende, quien aprueba y quien supervisa. Un rol describe una responsabilidad, no necesariamente un cargo. La misma persona puede tener varios roles, y conviene aclarar qué puede ver o modificar cada uno.

Después recorre un caso de principio a fin. En una solicitud interna podría ser: una persona la registra, un responsable revisa la información, decide si la aprueba y comunica el resultado. Es un ejemplo hipotético que debes adaptar a tu operación.

Anota reglas y excepciones

Para cada paso, pregunta qué datos son obligatorios, quién puede actuar y qué sucede si algo falla. ¿Puede corregirse una solicitud enviada? ¿Qué pasa cuando el responsable está ausente? ¿Debe quedar un historial? Las excepciones suelen cambiar el esfuerzo tanto como el camino normal.

Si hay sistemas externos, registra de dónde viene cada dato, quién es responsable de su calidad y si ya existe una manera autorizada de intercambiarlo. No des por viable una integración hasta comprobar las condiciones técnicas del proveedor.

Incluye requisitos de operación

Las funciones visibles son solo una parte. Habla de acceso desde celular o computador, permisos, respaldos, continuidad, protección de información y necesidad de soporte. Describe condiciones concretas —quién necesita recuperar qué información y en qué plazo deseado— en lugar de pedir que el sistema sea simplemente «seguro» o «rápido».

Prioriza una primera entrega comprobable

Separa lo imprescindible para usar el flujo de lo que puede esperar. Una primera etapa debe resolver un problema completo para un grupo de usuarios, no ser únicamente una colección de pantallas inconexas. Mantén una lista de preguntas abiertas y revisa su impacto antes de prometer fecha o precio.

Escribe ejemplos de aceptación

Una forma sencilla es: dado un contexto, cuando ocurre una acción, entonces esperamos un resultado. Por ejemplo: «Dada una solicitud pendiente, cuando su responsable la aprueba, el sistema registra la decisión y la fecha». Añade un caso donde la persona no tiene permiso y otro donde falta información. Son ejemplos para acordar con el equipo, no pruebas exhaustivas.

La guía de Colombia Compra Eficiente trata la definición técnica y económica de adquisiciones públicas; puede orientar la preparación, aunque cada empresa debe adaptar el documento a su propio proyecto. Cuando recibas ofertas, usa estos requisitos para comparar las cotizaciones con la misma base.

Fuentes consultadas

Empecemos por el proceso

Cuéntanos cómo trabajas hoy y qué necesitas cambiar; juntos podemos identificar una primera etapa.

Describir mi proyecto