La matriz de trazabilidad del requisito al control y a la prueba

La matriz se lee hacia adelante: de cada requisito a su origen (una entrevista, una ley, una política, un acta), a los controles que lo cumplen y a la prueba que lo demuestra. Un requisito sin control es una promesa que nadie construyó; uno sin prueba es algo que nadie puede demostrar.

Y se lee hacia atrás: de cada control al requisito que lo justifica. Un control que no responde a ningún requisito es un costo sin razón conocida: o falta escribir su requisito, o sobra. Los catálogos públicos, como los requisitos de arquitectura del ASVS de OWASP, ayudan a no olvidar requisitos, pero la matriz es propia de cada sistema: nadie la trae hecha.

Recorre trazabilidad/matriz.txt hacia adelante. Fíjate en el origen de cada requisito: si sale de una entrevista, ya sabes cuánto le importa al negocio.

Ahora léela hacia atrás. Cada control de trazabilidad/controles.txt debería aparecer en la columna de controles de la matriz. Los que aparecen dos veces o junto a otro control también cuentan como cubiertos.

Que una prueba pase no significa nada si comprueba otra cosa. La prueba de un requisito con umbral tiene que llevar el sistema hasta el umbral y mirar qué hace: con cinco intentos fallidos, ¿se bloquea o no? Una prueba que solo mira un mensaje en pantalla pasa aunque el bloqueo no exista.

Compara cada requisito resumido de la matriz con lo que comprueba su prueba en trazabilidad/pruebas.txt.

El comité de riesgos no lee pruebas: lee el informe del equipo. Por eso la trazabilidad termina en la evidencia, y el arquitecto contrasta el informe con los resultados de la última ejecución antes de que llegue a la reunión.