Imagina este escenario: el gerente de operaciones escribe a un proveedor de software: “Necesitamos un sistema para controlar inventario y generar reportes”. El proveedor responde con una cotización, el equipo empieza a desarrollar y, dos meses después, surgen preguntas que nadie había previsto: ¿qué reportes?, ¿cada cuánto?, ¿con qué datos?, ¿quién los consulta? El proyecto se alarga, el presupuesto se mueve y la confianza se deteriora.
Por qué documentar requisitos antes de desarrollar software
Un documento de requisitos no es un contrato rígido ni un manual técnico. Es una descripción ordenada de qué problema se quiere resolver, para quién, bajo qué condiciones y cómo saber si quedó resuelto. Cuando una empresa pide desarrollo sin especificar, el equipo técnico tiene que adivinar el contexto. Cada suposición puede llevar a cambios de alcance, retrabajo y plazos más largos. Documentar no elimina la necesidad de conversar, pero hace que la conversación sea específica y verificable. Esto es especialmente relevante cuando el proyecto involucra a varias áreas o cuando el desarrollo se subcontrata. Un buen documento de requisitos permite que una persona que no vivió las conversaciones originales entienda qué se espera y hasta dónde llega el alcance.
Qué incluir: requisitos funcionales y no funcionales
Una forma práctica de organizar los requisitos es separarlos en dos grupos.
- Funcionales: describen qué debe hacer el sistema. Ejemplos hipotéticos: registrar una venta, cambiar el estado de un pedido, enviar un correo de confirmación, listar productos por categoría.
- No funcionales: describen restricciones o cualidades del sistema. Ejemplos hipotéticos: tiempo de respuesta aceptable, cantidad de usuarios simultáneos, niveles de seguridad, disponibilidad esperada, compatibilidad con otras herramientas.
Ambos grupos importan. Si solo defines los requisitos funcionales, el equipo sabrá qué construir, pero no sabrá con qué calidad ni bajo qué condiciones. Si solo defines los no funcionales, tendrás restricciones sin propósito. Además, los requisitos no funcionales suelen ser los que más afectan la experiencia de uso. Un sistema puede hacer exactamente lo que se pidió, pero si carga lento o no soporta el número de usuarios, nadie lo percibirá como exitoso. Por eso conviene escribirlos tan pronto como se identifiquen, aunque después se ajusten.
Convierte cada necesidad en un caso de uso
Un caso de uso es una descripción simple de una interacción entre una persona y el sistema. Tiene tres elementos básicos: quién participa, qué acción realiza y qué resultado espera.
Ejemplo hipotético: “El encargado de almacén escanea el código de un producto; el sistema descuenta una unidad del inventario y muestra el stock restante”. Después se pueden agregar variaciones: “Si no hay stock suficiente, el sistema muestra un aviso y no permite completar el movimiento”.
No hace falta escribir casos extensos. Dos o tres frases por caso son suficientes para que un desarrollador entienda la lógica y para que la empresa detecte huecos. También conviene definir quién es el usuario de cada caso. Si un mismo proceso lo ejecutan el almacén, ventas y administración, el caso de uso puede variar según el rol.
Define criterios de aceptación para cada requisito
Un criterio de aceptación es la condición que permite decir: “esto está terminado”. Es útil para evitar discusiones al final del proyecto.
- En lugar de “el sistema debe manejar descuentos”, un criterio más claro es: “Cuando el usuario registra una venta con un código de descuento válido, el sistema calcula el total con el descuento aplicado y lo muestra antes de confirmar”.
- En lugar de “el reporte debe ser rápido”, un criterio verificable puede ser: “El reporte de ventas diarias carga en menos de cinco segundos con un volumen de hasta diez mil registros”.
Cada requisito importante debería tener al menos un criterio de aceptación. Si no se puede definir una condición de verificación, probablemente el requisito todavía es confuso. Si un requisito no tiene criterio, se convierte en una promesa abierta. El equipo de desarrollo puede interpretar que cumplió, mientras la empresa esperaba otro comportamiento. Definir el camino de verificación reduce esa ambigüedad.
Pasos prácticos para documentar requisitos antes de cotizar
- Reúne a las personas que conocen el proceso. Incluye a quien ejecuta la tarea todos los días, no solo a quien aprueba la compra.
- Describe el proceso actual. Antes de decir “necesito un módulo de inventario”, explica cómo se controla hoy: quién registra, con qué datos y qué pasa cuando algo falla.
- Escribe cada requisito como una frase accionable. Prefiere “el sistema permite crear una orden de compra” a “el sistema debe tener compras”.
- Prioriza. Marca qué es imprescindible para operar, qué es importante pero puede esperar y qué quedaría para una segunda versión.
- Revisa el documento con personas de otras áreas. Lo que para unos es un detalle, para otros puede ser la función principal.
- Comparte el documento con el proveedor antes de pedir una cotización. Así la conversación empieza por el alcance y no por una lista de funciones idealizadas.
Errores comunes al documentar requisitos
- Suponer que un término significa lo mismo para todos. “Reporte”, “cliente” o “urgente” se pueden entender de muchas formas.
- Mezclar requisitos con soluciones técnicas. Decir “el sistema debe estar en la nube” puede ser una decisión válida, pero no debe reemplazar una descripción del problema que se quiere resolver.
- Documentar solo el camino feliz y omitir los bordes: qué pasa si falta un dato, si un usuario no tiene permiso o si un proceso se interrumpe.
- No definir quién aprueba cambios. Sin esa persona, cualquier conversación puede modificar el alcance sin que nadie lo decida formalmente.
- Escribir un documento tan largo que nadie quiera leerlo. Un buen documento se puede recorrer en menos de una hora y cada sección responde a una pregunta concreta.
Cómo saber si tu documento está listo
Antes de enviarlo, haz estas preguntas de diagnóstico:
- ¿Una persona nueva podría leer el documento y explicar el flujo principal del sistema?
- ¿Cada requisito funcional tiene un criterio de aceptación?
- ¿Los requisitos no funcionales están definidos para aspectos como tiempo de respuesta, seguridad o capacidad?
- ¿Las prioridades son claras para separar lo imprescindible de lo opcional?
Si alguna respuesta es no, ajusta primero el documento. Si tienes dudas, conviene resolverlas antes de iniciar el desarrollo; el costo de una aclaración temprana es menor que el de un cambio en plena construcción. Además, invita a una persona que no haya participado en la redacción a leerlo. Si esa persona puede explicar qué se va a construir y qué se va a medir, el documento cumple su función.
Siguiente paso
Si ya tienes un documento de requisitos o un borrador, el siguiente paso es validarlo con un equipo técnico antes de pedir una cotización cerrada. Agenda una sesión de descubrimiento en Kodium para revisar tu documento, aclarar dudas y definir el alcance inicial de tu proyecto de software.
