Cómo se escribe un requerimiento de software que sí se cumple
Resumen:
- Un requerimiento mal escrito no se nota al firmar: se nota en la semana ocho, cuando lo entregado cumple el texto y no sirve para la operación.
- El formato que funciona tiene cuatro partes: quién, qué, para qué y cómo se comprueba.
- Los criterios de aceptación son lo que convierte una opinión en una verificación.
- La lista de lo que el sistema no hará ahorra más dinero que la de lo que sí hará.
- Los cambios no son el problema; cambiar sin cotizar el impacto sí lo es.
Cuando un desarrollo se entrega y el cliente dice "no es lo que pedí", casi nunca hubo mala fe. Hubo una frase que admitía dos lecturas y cada parte eligió la suya. "Que el sistema avise cuando haya poco inventario" es una frase perfectamente razonable que no dice qué es poco, a quién se avisa, por cuál medio ni con qué frecuencia. El proveedor eligió un correo diario al administrador con umbral del diez por ciento. El cliente esperaba un mensaje de WhatsApp inmediato al jefe de almacén. Los dos cumplieron lo escrito.
El formato de cuatro partes
Un requerimiento útil contesta cuatro preguntas en el mismo párrafo. Quién lo usa, qué debe poder hacer, para qué le sirve y cómo se comprueba que quedó. La cuarta es la que casi nadie escribe y es la que cierra discusiones.
Comparado con la frase del inventario, la versión completa sería: el jefe de almacén recibe un mensaje de WhatsApp dentro de los cinco minutos siguientes a que el inventario disponible de un producto marcado como crítico baje del mínimo que él mismo configuró, para reponer antes de quedarse sin surtir un pedido; se comprueba bajando manualmente el inventario de un producto de prueba y verificando que el mensaje llega con el nombre del producto, la cantidad disponible y el proveedor habitual.
Es más largo y es más barato. La versión larga no se puede implementar de dos formas distintas.
Criterios de aceptación: la diferencia entre opinar y verificar
Un criterio de aceptación es una frase que alguien puede ejecutar y marcar como cumplida o no cumplida. No admite "más o menos". La tabla muestra el mismo requerimiento escrito de las dos maneras.
| Escrito como opinión | Escrito como criterio |
|---|---|
| El buscador debe ser rápido | Una búsqueda por nombre de cliente devuelve resultados en menos de un segundo con treinta mil clientes cargados |
| El sistema debe ser fácil de usar | Un capturista nuevo registra un pedido completo en menos de dos minutos después de una capacitación de quince minutos |
| Debe funcionar en celular | Las pantallas de captura de pedido y consulta de inventario se usan completas en un celular de cinco pulgadas, sin desplazamiento horizontal |
| Debe conectarse con el sistema de facturación | Al cerrar un pedido se genera el CFDI en el sistema de facturación y el folio queda guardado en el pedido, sin captura manual |
| Los reportes deben ser completos | Existen los cuatro reportes de la lista anexa, cada uno exportable a Excel con los mismos totales que muestra en pantalla |
La columna derecha se verifica en media hora. La izquierda se discute durante tres semanas.
La sección que más dinero ahorra
En todo proyecto hay funciones que alguien mencionó en una junta, nadie descartó y nadie incluyó. Viven en un limbo donde el cliente cree que están cotizadas y el proveedor cree que no. Aparecen en la semana nueve.
La solución es una lista de exclusiones explícitas al final del documento: esto no incluye aplicación móvil, no incluye conexión con el sistema contable, no incluye migración del histórico anterior a 2024, no incluye facturación. Cada línea de esa lista es una conversación que no vas a tener, o que vas a tener como cotización adicional en lugar de como reclamo.
Los cambios y cómo manejarlos sin romper nada
Nadie escribe requerimientos perfectos, porque al ver la primera versión funcionando se entiende el problema mejor que antes. Eso es normal y es sano. Lo que no es sano es meter cambios por mensaje suelto sin medir qué arrastran.
El mecanismo es simple: todo cambio entra por escrito, el proveedor responde con el impacto en horas y en fecha de entrega, y el cliente decide con ese número enfrente. A veces el cambio vale la pena y se acepta el retraso. A veces cuesta tres semanas y se deja para la segunda etapa. Lo importante es que la decisión se tome viendo el costo, no después.
En un proyecto de ocho semanas que acompañamos el año pasado entraron once cambios. Seis se aceptaron, cinco se pasaron a una segunda fase. El proyecto entregó en diez semanas en lugar de ocho y nadie se sorprendió, porque cada semana adicional tenía nombre y firma.
¿Qué tan detallado debe ser un requerimiento?
Lo suficiente para que dos personas que no hablaron entre ellas lleguen a la misma conclusión sobre qué hace el sistema. Si tu requerimiento admite dos implementaciones distintas y las dos cumplen lo escrito, está incompleto. No necesitas describir cómo se programa; necesitas describir qué debe pasar y cómo se comprueba.
¿Quién debe escribir los requerimientos, el cliente o el proveedor?
El cliente escribe el qué y el por qué, porque es quien conoce su operación. El proveedor traduce eso a cómo y lo devuelve para que el cliente lo confirme. Cuando el proveedor escribe todo sin ese ida y vuelta, el documento refleja lo que el proveedor entendió, no lo que el negocio necesita.
¿Qué es un criterio de aceptación?
Es la frase que define cuándo una función está terminada, escrita de forma que se pueda comprobar sin discutir. En lugar de "el reporte debe ser rápido", un criterio de aceptación dice "el reporte de ventas del mes carga en menos de tres segundos con doce meses de datos". El primero genera juntas; el segundo se verifica y se cierra.
¿Conviene poner lo que el sistema NO va a hacer?
Sí, y es la sección que más dinero ahorra. Toda función que alguien imaginó y nadie descartó por escrito vuelve a aparecer a mitad del proyecto como si siempre hubiera estado incluida. Una lista de exclusiones explícitas convierte esa discusión en una cotización adicional, que es lo que debe ser.
¿Se pueden cambiar los requerimientos a mitad del proyecto?
Se pueden y casi siempre se cambian, porque al ver el sistema funcionando se entiende mejor el problema. Lo que debe existir es el mecanismo: un cambio se cotiza en horas y días antes de entrar, y se decide con ese número a la vista. Cambiar sin medir el impacto es como se atrasan los proyectos.