Requerimientos de software: cómo escribirlos sin ambigüedad
Por Alessandro Massoni 4 min de lectura
La mayoría de los requerimientos de software no fallan por el código, fallan por una frase como "que avise cuando falte stock". ¿Avise a quién, por qué medio, cuando falte cuánto y qué pasa si nadie lo lee? Cada pregunta sin responder es una decisión que alguien va a tomar por ti, y hoy ese alguien suele ser una IA.
En este artículo verás por qué la ambigüedad sale cara, cómo escribir requerimientos con un formato simple que nació en la industria aeronáutica, un ejemplo paso a paso y qué no debe faltar en el documento que le entregas a tu proveedor.
Por qué los requerimientos de software ambiguos salen caros
Un requerimiento ambiguo no desaparece: se resuelve más tarde y en el peor momento. Si se descubre en la especificación, cambiarlo cuesta una conversación. Si se descubre con el sistema funcionando, cuesta rehacer pantallas, migrar datos y volver a capacitar al equipo.
Con IA el problema se agrava de una forma silenciosa. Un programador que no entiende algo suele preguntar; un modelo de lenguaje rellena el vacío con el supuesto más probable y sigue adelante. El resultado se ve correcto, compila y pasa la demo, pero responde a una regla que nadie definió. Por eso en el desarrollo de software con IA la especificación pasó a ser la pieza más importante del proyecto.
Cuando construimos sistemas a medida para empresas, la mitad del valor está en esta etapa: convertir lo que tu equipo hace todos los días en reglas que no admitan dos lecturas.
El formato EARS: cinco patrones para escribir requerimientos
EARS (Easy Approach to Requirements Syntax) es un método que desarrolló Alistair Mavin en Rolls-Royce para redactar requisitos de sistemas de control de motores de avión. Su idea es simple: casi todo requerimiento bien escrito sigue uno de cinco patrones, y cada patrón obliga a decir lo que suele quedar implícito.
- Siempre: "El sistema debe registrar el usuario que crea cada cotización".
- Cuando ocurre algo: "Cuando una cotización se aprueba, el sistema debe generar la orden de trabajo".
- Mientras se mantiene un estado: "Mientras una orden esté abierta, el sistema debe impedir modificar su precio".
- Si pasa algo no deseado: "Si el stock de un producto baja del mínimo, entonces el sistema debe notificar por correo al encargado de bodega".
- Donde aplique una opción: "Donde el cliente tenga crédito aprobado, el sistema debe permitir la venta sin pago anticipado".
El método no requiere herramientas ni capacitación larga, y por eso funciona bien con equipos de operaciones. Además, su estructura es fácil de leer tanto para personas como para modelos de lenguaje, lo que lo volvió un estándar práctico para especificar sistemas que se construyen con IA.
De la frase suelta al requerimiento: un ejemplo paso a paso
Tomemos la frase del principio, "que avise cuando falte stock", y hagámosle las preguntas que la IA no va a hacer:
- ¿Qué significa faltar? Bajar de un mínimo definido por producto.
- ¿A quién se avisa? Al encargado de la bodega donde está el producto.
- ¿Por qué medio? Correo y aviso dentro del sistema.
- ¿Cada cuánto? Una sola vez hasta que el stock se reponga.
- ¿Qué pasa si no hay encargado asignado? Se avisa al jefe de operaciones.
El requerimiento final queda así: "Si el stock de un producto baja de su mínimo, entonces el sistema debe enviar un único aviso por correo y en el panel al encargado de esa bodega, y si la bodega no tiene encargado, al jefe de operaciones". Es más largo, pero ya no hay nada que adivinar, y cualquiera puede comprobar si el sistema lo cumple.
Qué debe tener un documento de requerimientos de software
No necesitas un documento de cien páginas. Necesitas que cubra lo que una persona nueva tendría que preguntar para hacer el trabajo sin equivocarse:
- Los datos: qué información se guarda y cómo se relaciona.
- Los roles: quién usa el sistema y qué puede ver o modificar cada uno.
- Las reglas: los requerimientos escritos con los patrones anteriores.
- Las excepciones: qué pasa cuando algo sale del camino normal.
- Lo que queda fuera: lo que el sistema no hará en esta etapa.
El primer punto es el que más se omite y el que más problemas evita después; lo desarrollamos en por qué conviene empezar por la base de datos. Otra forma útil de llegar a buenos requerimientos es partir desde los reportes que necesitas, como proponemos en diseñar tu sistema partiendo de las preguntas que necesitas responder.
¿Cuántas reglas de tu operación viven hoy solo en la cabeza de alguien? Agenda una reunión de levantamiento y las convertimos juntos en requerimientos listos para construir.
Preguntas frecuentes
Es una descripción de algo que el sistema debe hacer o cumplir, escrita de forma que se pueda verificar. Un buen requerimiento dice qué ocurre, en qué condición y a quién afecta, sin dejar decisiones implícitas.
Es un método para redactar requerimientos desarrollado por Alistair Mavin en Rolls-Royce. Propone cinco patrones: siempre, cuando ocurre algo, mientras se mantiene un estado, si pasa algo no deseado y donde aplica una opción.
Los datos que se guardan, los roles y sus permisos, las reglas escritas con patrones claros, las excepciones y lo que queda fuera del alcance. No necesita ser largo, necesita responder lo que una persona nueva preguntaría.
