Documentos del Proyecto · Serie 15 · Semana Inicio · Tema 26
De todos los documentos del proyecto, este es el que más se presenta y menos se usa. Se enseña en las auditorías como prueba de que todo está cubierto, que es justo el uso que menos rinde.
Su valor está en recorrerla al revés.
Para qué sirve, en una línea
Enlaza cada requisito con su origen por un lado y con lo que lo satisface por el otro. Con eso contestas tres preguntas que sin ella no se pueden contestar:
- Si cae este requisito, ¿a quién le importa?
- ¿Hay algo que estemos construyendo que no pidió nadie?
- ¿Hay algo pedido que nadie está probando?
Qué columnas necesita de verdad
Hay matrices de veinte columnas. Con seis se hace el trabajo:
| Columna | Para qué |
|---|---|
| ID del requisito | La llave |
| Enunciado corto | Para leerla sin abrir otro documento |
| Origen | Persona o documento. Sin esto la matriz es decorativa |
| Entregable | Qué paquete de la EDT lo satisface |
| Prueba | Qué caso lo verifica |
| Estado | Pendiente / construido / verificado / descartado |
El estado «descartado» es importante: un requisito que se cae no se borra, se marca. Borrarlo hace imposible explicar después por qué no está.
Las tres lecturas
Hacia adelante, del requisito a la prueba. Es la lectura de auditoría: demuestra cobertura. Es la que se presenta y la que menos descubre.
Hacia atrás, del requisito a su origen. Es la que descubre cosas. Todo lo que no enlaza con nadie es candidato a sobrar.
Por huecos. Requisitos sin prueba, entregables sin requisito, pruebas sin requisito. Cada hueco es una pregunta concreta que alguien tiene que contestar.
Cuándo se construye
En cuanto hay requisitos con identificador, aunque no haya EDT ni pruebas todavía. Las columnas vacías se rellenan solas conforme el proyecto avanza, y mientras tanto la columna de origen ya está haciendo su trabajo.
Construirla al final es el error que la deja en decorativa: para entonces ya se estimó, ya se construyó y ya no se puede quitar nada.
Qué la vuelve papel mojado
- Se construye al final. Para la auditoría. Entonces solo documenta; ya no puede cambiar nada.
- Sin columna de origen. Es el fallo más común y deja la matriz sin su lectura útil.
- No se actualiza. Una matriz desfasada es peor que ninguna, porque da una seguridad falsa.
- Demasiadas columnas. A partir de diez, nadie la mantiene, y una matriz que no se mantiene no existe.
Y si me falta lo que pide
No tengo EDT todavía. Deja la columna vacía y rellénala cuando exista. La matriz se construye por capas, no de una vez.
No sé el origen de requisitos heredados. Escribe «sin origen identificado» y ponlo en la lista de cosas a resolver. Eso ya es información: son los primeros candidatos a caerse.
Son demasiados requisitos para una hoja. Traza solo los imprescindibles e importantes. Trazar los deseables casi nunca compensa.
Caso práctico: la matriz que se construyó en el mes seis
Escenario construido con patrones habituales; las cifras son ilustrativas.
Un proyecto de gestión de siniestros para una aseguradora mediana trabajaba con 52 requisitos aprobados. La matriz de trazabilidad estaba en el plan desde el principio, con una fecha: mes uno.
Se construyó en el mes seis, cuando la pidió una auditoría interna. No hubo mala intención: cada mes había algo más urgente y la matriz parecía un documento de archivo.
Leída hacia delante, salió impecable: las once necesidades del acta estaban cubiertas.
Leída hacia atrás apareció lo otro. Nueve requisitos no enlazaban con ninguna necesidad, ningún interesado y ningún documento de origen. Todos pertenecían al mismo bloque: un panel de indicadores para dirección.
El origen se reconstruyó preguntando. El patrocinador había visto, en una feria, el producto de un competidor con un panel muy vistoso, y lo había comentado en una reunión. Nadie lo aprobó y nadie lo desmintió; alguien lo recogió en la especificación y a partir de ahí viajó solo.
Eran el 24 % del esfuerzo estimado.
Y en el mes seis ya estaban construidos en sus dos terceras partes.
Ahí está la diferencia que marca la fecha. Detectados en el mes uno, la conversación habría sido si se quería ese panel o no: media hora con el patrocinador. Detectados en el mes seis, la conversación fue qué hacer con un trabajo ya pagado, y la respuesta práctica fue terminarlo, porque tirar lo construido era políticamente imposible.
El panel se entregó. Al año siguiente, el registro de accesos decía que lo habían abierto once veces.
La matriz no falló: dijo exactamente lo que tenía que decir. Lo dijo cinco meses tarde, y una matriz de trazabilidad tardía deja de ser una herramienta de decisión para convertirse en un acta de lo que ya no tiene arreglo.
Checklist
- ¿Tiene columna de origen, con persona o documento?
- ¿La has leído alguna vez hacia atrás, no solo hacia adelante?
- ¿Hay requisitos sin prueba asociada?
- ¿Hay entregables que no satisfacen ningún requisito?
- ¿Los descartados están marcados o borrados?
- ¿Se actualiza al aprobar cada requisito, o solo cuando alguien la pide?
Para cerrar
La matriz de trazabilidad se justifica el día del recorte y el día de la auditoría, en ese orden de importancia. Y para el primero hace falta una columna que la mitad de las matrices no tiene.
Te leo en los comentarios: si recorrieras la tuya hacia atrás, ¿cuántas filas no enlazarían con nadie?
Referencias
- Project Management Institute, Guía del PMBOK, sobre la matriz de trazabilidad de requisitos.
- International Institute of Business Analysis, BABOK, sobre trazabilidad y análisis de cobertura.
- Wiegers, K. y Beatty, J., Software Requirements, sobre trazabilidad bidireccional.
← Anterior en la serie: Plan de gestión de requisitos: la fecha de corte
Siguiente en la serie: La checklist del plan: lo que afirmas sin respaldo →
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.