Qué es una matriz de trazabilidad de requisitos, y por qué la NASA exige seis enlaces dentro de ella

Cifras de SWE-052 — Bidirectional Traceability, del NASA Software Engineering Handbook (NPR 7150.2). Para software de clase A, B y C el responsable del proyecto debe registrar y mantener trazabilidad bidireccional en seis relaciones: requisitos de nivel superior con requisitos de software, requisitos con peligros del sistema, requisitos con componentes de diseño, componentes de diseño con código, requisitos con las verificaciones del software y requisitos con no conformidades.

Qué contiene una RTM

Una fila por requisito y una columna por cada cosa con la que ese requisito conecta. Los proyectos varían, pero un juego de columnas que funciona es este:

• Identificador — uno que sobreviva a las reordenaciones. Volvemos a ello más abajo.
• Texto del requisito, o una versión corta.
• Origen — el requisito de cliente, la cláusula o la norma de la que desciende.
• Elemento de diseño — el componente que lo implementa.
• Caso de prueba — la verificación que demuestra que funciona.
• Estado — cómo está ese enlace hoy.

Los proyectos de seguridad funcional suelen añadir el peligro que controla el requisito, un nivel de criticidad como un ASIL o un DAL, y la baseline en la que se congeló. También verás el artefacto llamado matriz de trazabilidad, matriz de requisitos o directamente RTM: tres nombres alternativos para lo mismo.

Hacia delante, hacia atrás, bidireccional

Tres términos que se usan indistintamente y no deberían. La diferencia decide qué puede y qué no puede contarte tu matriz. Cambia entre ellos y mira qué enlaces se encienden.

Una RTM de cuatro filas

Una matriz de cuatro requisitos. Apaga un enlace de verificación y mira qué dice la matriz: este es el trabajo entero de una RTM, en una tabla que cabe de un vistazo.

La dificultad de una RTM no está en el número de requisitos ni en el de enlaces, que crecen a la par. Está en el análisis de impacto: cuando cambia un requisito de arriba, lo que hay que revisar se propaga de nivel en nivel, y esa cuenta sí se dispara. Por ahí es por donde esto deja de ser una tarea documental, normalmente alrededor de la segunda baseline.

Qué pide exactamente cada norma

"La norma exige trazabilidad" es cierto y casi inútil. Lo que cambia entre unas y otras es hasta dónde tiene que llegar la evidencia y en qué documento acaba. Elige la que te aplique.

Un detalle que conviene saber si te aplica más de una. Tanto ISO 26262 como Automotive SPICE exigen trazabilidad bidireccional, y en el eje central —requisitos, diseño, pruebas— los enlaces se reutilizan. Pero no se solapan en los extremos: Automotive SPICE no contempla el análisis de peligros ni los ASIL, e ISO 26262 no pide trazar los requisitos que no son de seguridad. Una sola infraestructura, sí; un solo conjunto de enlaces, no. Quien lo monte como si fuera lo mismo llega a una de las dos auditorías con la mitad.

Dónde deja de servir la hoja de cálculo

Casi todos los proyectos empiezan su RTM en una hoja de cálculo, y para un primer prototipo es una decisión perfectamente razonable. Nadie compra una herramienta de requisitos para gestionar cuarenta requisitos. El modo de fallo, eso sí, es predecible, y llega siempre en el mismo orden.

El identificador se desplaza

En una hoja, un requisito es una fila. Inserta una fila encima y toda referencia cruzada que apuntaba a "la fila 47" apunta ahora a otra cosa. Los equipos lo esquivan con una columna de ID manual, que aguanta hasta que dos personas editan el fichero la misma tarde y una de las dos gana.

Nadie sabe qué invalidó un cambio

El cliente cambia un requisito de nivel superior. ¿Qué requisitos de software quedan en duda? ¿Qué pruebas dejaron de valer? Una hoja no puede responder, porque el enlace es texto, no una relación. Alguien tiene que deducirlo leyendo, y lo hará la semana antes de la entrega, que es cuando se lee más deprisa y peor.

La matriz es una foto, no un estado

La RTM que hay en la carpeta era cierta el día que se exportó. Si sigue siéndolo hoy es cuestión de fe. Los auditores han aprendido a preguntar cuándo se generó y a partir de qué. La pregunta es educada; la respuesta, no siempre.

Qué cambia con una herramienta de gestión de requisitos

Las organizaciones no se pasan a una herramienta de gestión de requisitos porque dibuje una matriz más bonita. Se pasan porque la matriz deja de ser un documento que alguien mantiene y pasa a ser una vista que se genera a demanda a partir de enlaces que ya existen.

En IBM DOORS, cada requisito es un objeto con un número absoluto que no cambia en toda su vida. Conviene saberlo desde el principio: la numeración jerárquica que se ve en pantalla (1.1, 1.2) sí se reordena al insertar por encima, igual que en una hoja. Lo que no se mueve es el número absoluto, y es el que hay que referenciar. Los enlaces entre módulos son relaciones reales y no texto escrito a mano, de modo que la cobertura se calcula en lugar de recopilarse. Y cuando cambia un requisito de origen, los enlaces que cuelgan de él quedan marcados automáticamente como sospechosos: la herramienta te dice qué hay que revisar en vez de esperar a que alguien se dé cuenta.

La diferencia se nota el día de la auditoría. Producir la matriz pasa de ser una semana de la vida de alguien a un informe que se ejecuta, y ese informe se puede automatizar, y la respuesta a "¿cuándo se generó esto?" pasa a ser "ahora mismo, a partir de la baseline que estás mirando".

Cinco formas de hacerlo mal

• Trazar solo hacia delante. Es la mitad del requisito, y la mitad de la que menos se fía un auditor.
• Una sola matriz para todo el programa. Divídela por subsistema o por baseline. Nadie lee una tabla de cuatro mil filas, empezando por quien la hizo.
• Enlazar a documentos en vez de a requisitos. "Véase el apartado 4.2" es una referencia, no trazabilidad. No sobrevive a la primera reorganización del documento.
• Estado en texto libre. Si en la misma columna conviven "Hecho", "hecho" y "OK", la matriz no se puede filtrar, y una matriz que no se puede filtrar es una matriz que no usa nadie.
• Construirla al final. Una RTM montada el mes antes de certificar documenta lo que pasó. Una mantenida desde el principio cambia lo que pasa.

Preguntas frecuentes