Ambas direcciones, y por qué importa la segunda
La trazabilidad directa responde qué pruebas verifican un requisito dado. Es lo que piden los auditores y para lo que se construyen la mayoría de las matrices.
La trazabilidad inversa responde qué requisito justifica una prueba dada. Se soporta mucho menos, y es la dirección que encuentra huérfanos — casos que sobrevivieron al requisito que los motivó y ahora consumen esfuerzo verificando comportamiento que nadie pidió.
Por qué se desactualiza la matriz
Porque es una segunda fuente de verdad sobre una relación que no está registrada en ningún otro lado. Nada la hace cumplir y nada detecta la desviación. Un requisito se revisa y cambia su identificador; una suite se reorganiza y los casos se renumeran; un ingeniero escribe tres casos y registra uno.
Ninguno produce un error en el momento. Cada uno aparece meses después como hallazgo de auditoría, por eso existe el ritual de reconstrucción previa y por eso los equipos presupuestan semanas para él.
La solución estructural
Deje de tratar la trazabilidad como documentación y trátela como procedencia. Cuando un caso se genera desde un requisito, escriba el identificador en el caso al crearlo. La matriz deja de ser un documento que mantener y se vuelve una consulta que ejecutar — nada puede desviarse, porque no hay una segunda copia.
La trazabilidad no es cobertura
Una matriz completa demuestra que todo requisito escrito está verificado. No dice nada sobre comportamiento que entró al sistema sin requisito — un enclavamiento agregado en integración, un tiempo de espera ajustado tras un problema en campo, una ruta alternativa para sortear un componente de proveedor.
Ese comportamiento es real, se entrega y es invisible para un reporte basado en requisitos. Responder "¿está verificado todo el comportamiento implementado?" requiere un índice de lo que existe, derivado analizando la implementación y no mantenido a mano.