Documentos del Proyecto · Serie 15 · Semana Inicio · Tema 22
El enunciado del alcance dice qué se entrega. Este dice qué tiene que hacer y cumplir cada cosa, con el detalle suficiente para construirla y para verificarla.
Es el documento más largo del proyecto y el que peor envejece. Conviene saber qué lo mantiene vivo.
Para qué sirve, en una línea
Es la lista contra la que se construye y contra la que se prueba. Si algo no está aquí, no se construye; y si está, alguien tiene que poder decir si se cumplió.
Cómo se escribe cada requisito
Un requisito útil tiene cinco cosas. Solo cinco, y todas caben en una fila de tabla:
| Campo | Para qué |
|---|---|
| Identificador | Sin él no hay trazabilidad, ni pruebas enlazadas, ni forma de hablar de «ese» requisito |
| Enunciado | Qué debe hacer o cumplir. Una frase |
| Origen | Quién lo pidió. El requisito sin dueño es el primero que sobra |
| Criterio de aceptación | Cómo se comprueba, en términos que no admitan discusión |
| Prioridad | Qué se cae primero cuando no quepa todo. Y no cabe nunca |
Lo demás —categoría, versión, estado, complejidad— ayuda en proyectos grandes y estorba en los pequeños.
Los tipos que se olvidan
Casi todo el esfuerzo se va en los requisitos funcionales, que son los que el cliente sabe contestar. Los que se olvidan son los que hunden el proyecto en pruebas:
- De rendimiento. Cuántos usuarios a la vez, cuánto tarda, cuánto aguanta.
- De operación. Quién lo va a mantener, con qué herramientas, y qué tiene que poder cambiar sin llamar al proveedor.
- De seguridad y cumplimiento. Qué datos se guardan, cuánto tiempo, quién accede.
- De migración. Qué se trae del sistema anterior y hasta cuándo.
- De formación y documentación. Que casi siempre entran como sorpresa dos semanas antes de entregar.
Una forma rápida de sacarlos: preguntar, por cada requisito funcional, «¿y esto quién lo va a mantener, y con cuánta carga?».
Qué lo vuelve papel mojado
- Requisitos con adjetivos. Rápido, sencillo, moderno. No se pueden verificar ni rechazar.
- Sin identificador. Sin él no se puede trazar hacia atrás ni hacia adelante, y el documento deja de ser útil en cuanto crece.
- Sin prioridad. Cuando llegue el recorte —y va a llegar— se recortará por criterio de quien esté esa tarde.
- Congelado. Un documento de requisitos que no se ha tocado en cuatro meses de proyecto no describe lo que se está construyendo.
- Dos versiones circulando. El día que hay dos, ninguna es la buena.
Y si me falta lo que pide
El usuario no sabe decirme el criterio de aceptación. Normal: no es su oficio. Pregúntale cómo sabrá que quedó bien, o qué haría el primer día con el sistema delante. De ahí sale el criterio.
Tengo requisitos contradictorios entre áreas. No los resuelvas tú. Escríbelos los dos, con su origen, y escala la contradicción. Resolverla por tu cuenta te convierte en el culpable de la decisión.
No hay tiempo para documentarlo todo. Documenta con detalle lo de la primera fase y en grueso lo demás, con fecha de concreción. Es mejor que un documento completo y superficial.
Caso práctico: el recorte a ciegas
Escenario construido con patrones habituales; las cifras son ilustrativas.
Un proyecto de gestión documental para una administración local documentó 63 requisitos. Cada uno con su identificador, su criterio de aceptación y su prioridad.
Faltaba un campo: el origen.
En el mes cinco hubo que recortar para llegar a la fecha comprometida. La pregunta era cuáles se caían. Sin origen no se podía preguntar a nadie, porque no se sabía quién había pedido qué.
Se recortó por criterio técnico —lo más caro de construir— y se cayeron cinco requisitos. Tres eran los que el área de registro necesitaba para cerrar el ejercicio, y uno era obligatorio por la normativa de conservación.
Los cuatro volvieron a entrar en el mes siete, con prisa y peor hechos.
Una columna de origen habría convertido el recorte en una conversación de media hora con tres personas. Sin ella fue una decisión a ciegas que costó dos meses.
Es el campo que más se omite porque parece burocrático. Es el que más sirve el día que hay que decidir qué se cae.
Checklist
- ¿Cada requisito tiene identificador único?
- ¿Cada uno dice quién lo pidió?
- ¿Los criterios de aceptación se pueden comprobar sin discutir?
- ¿Hay prioridad, y sirve para decidir qué se cae?
- ¿Hay requisitos de operación, rendimiento y migración, o solo funcionales?
- ¿Cuándo se actualizó por última vez?
- ¿Hay una sola versión, y todo el mundo sabe cuál es?
Para cerrar
La documentación de requisitos no se juzga por lo completa que esté el día que se firma, sino por lo bien que aguanta el día del recorte. Y ese día lo que salva no es el detalle: es el origen y la prioridad.
Te leo en los comentarios: si mañana tuvieras que quitar un 20 % del alcance, ¿tu documento de requisitos te dice a quién preguntar?
Referencias
- Project Management Institute, Guía del PMBOK, sobre recopilar requisitos y la documentación de requisitos.
- Wiegers, K. y Beatty, J., Software Requirements, sobre atributos de un requisito y requisitos no funcionales.
- International Institute of Business Analysis, BABOK, sobre trazabilidad y priorización.
- ISO 21502:2020, sobre gestión del alcance y los requisitos.
← Anterior en la serie: El enunciado del alcance: el apartado que ahorra dinero es el de exclusiones
Siguiente en la serie: Plan de gestión de requisitos: la fecha de corte →
Este artículo forma parte de Documentos del Proyecto, una serie de 73 artículos. Ver todos los de esta serie · Índice completo por materia.