37. Matriz de trazabilidad y relación con diseño, código y pruebas
La matriz de trazabilidad es una forma organizada de mostrar las relaciones entre requerimientos y otros elementos del proyecto. Permite ver, en una misma estructura, de dónde viene cada requerimiento, cómo se diseña, dónde se implementa y con qué pruebas se verifica.
No se trata de completar una tabla por obligación. Su valor está en ayudar al equipo a controlar cobertura, analizar impacto de cambios y detectar inconsistencias entre lo pedido, lo construido y lo probado.
37.1 Introducción
En el tema anterior estudiamos la trazabilidad de requerimientos como concepto. Ahora veremos una herramienta concreta para representarla: la matriz de trazabilidad.
La matriz puede ser una planilla simple, una tabla en un documento o una vista generada por una herramienta especializada. Lo importante es que muestre relaciones útiles y se mantenga actualizada.
37.2 Qué es una matriz de trazabilidad
Una matriz de trazabilidad es una tabla que relaciona requerimientos con fuentes, objetivos, reglas, casos de uso, historias, componentes de diseño, módulos de código, casos de prueba, defectos y versiones.
Cada fila suele representar un requerimiento o una relación principal. Las columnas muestran la información necesaria para seguir su estado y sus vínculos.
37.3 Para qué sirve
Sirve para comprobar que los requerimientos aprobados tienen cobertura en diseño, desarrollo y pruebas. También permite identificar partes del sistema que no están justificadas por ningún requerimiento.
Además, facilita responder preguntas como qué pruebas cubren un requerimiento, qué módulo se ve afectado por un cambio o qué requerimientos quedan pendientes de implementar.
37.4 Estructura básica
Una estructura básica puede incluir identificador, descripción breve, fuente, prioridad, estado, componente de diseño, elemento de implementación, casos de prueba y observaciones.
En proyectos pequeños, una matriz simple es suficiente. En proyectos grandes, puede dividirse por módulo, proceso, entrega o tipo de requerimiento.
37.5 Identificador del requerimiento
El identificador es la columna más importante porque permite referenciar el requerimiento sin ambigüedad. Debe ser único y estable durante la vida del proyecto.
Ejemplos simples son RF-001 para un requerimiento funcional, RNF-004 para un requerimiento no funcional o RN-012 para una regla de negocio.
37.6 Descripción resumida
La matriz no debe reemplazar la especificación completa. Por eso conviene incluir una descripción breve que permita reconocer el requerimiento sin copiar todo el detalle.
Si la descripción cambia, debe revisarse si el cambio afecta relaciones existentes, criterios de aceptación, diseño o pruebas.
37.7 Fuente u origen
La fuente indica de dónde proviene el requerimiento. Puede ser un interesado, una entrevista, una norma, un objetivo de negocio, un documento, un sistema existente o una decisión aprobada.
Esta columna ayuda a justificar el requerimiento y a saber a quién consultar cuando aparece una duda o un conflicto.
37.8 Prioridad y criticidad
Registrar prioridad ayuda a planificar entregas y a enfocar el esfuerzo de trazabilidad. Registrar criticidad ayuda a entender qué requerimientos tienen mayor impacto si fallan.
Un requerimiento de baja prioridad puede tener alta criticidad si está relacionado con seguridad, cumplimiento legal o continuidad operativa.
37.9 Estado del requerimiento
El estado permite saber si el requerimiento está propuesto, aprobado, en análisis, implementado, probado, rechazado, diferido o modificado.
Una matriz sin estados actualizados pierde utilidad porque no permite distinguir trabajo pendiente de trabajo ya completado.
37.10 Relación con objetivos y reglas
Vincular requerimientos con objetivos y reglas permite evaluar si cada elemento del alcance aporta valor o responde a una restricción real.
Esta relación también ayuda a detectar reglas de negocio que no están implementadas o funcionalidades que no tienen un objetivo claro.
37.11 Relación con diseño
La matriz puede indicar qué pantalla, proceso, servicio, componente, entidad de datos o decisión arquitectónica cubre cada requerimiento.
Esta relación es útil para revisar si el diseño contempla todo el alcance aprobado y si una modificación del diseño afecta requerimientos específicos.
37.12 Relación con arquitectura
Algunos requerimientos, especialmente los no funcionales, se relacionan con decisiones arquitectónicas. Por ejemplo, disponibilidad, escalabilidad, seguridad o integración pueden requerir componentes específicos.
Registrar estas relaciones permite justificar decisiones técnicas y revisar su impacto cuando cambian restricciones o atributos de calidad.
37.13 Relación con código
La relación con código puede registrarse a nivel de módulo, servicio, paquete, repositorio, rama, tarea o cambio entregado. No siempre conviene llegar al detalle de cada archivo.
El nivel adecuado depende del riesgo del proyecto. Lo importante es poder ubicar qué parte de la implementación responde a cada requerimiento relevante.
37.14 Relación con tareas de desarrollo
En equipos ágiles, la matriz puede vincular requerimientos con historias de usuario, tareas del tablero, incidencias o elementos del backlog.
Esto permite seguir el avance de implementación y detectar requerimientos aprobados que todavía no tienen trabajo planificado.
37.15 Relación con pruebas
La matriz debe mostrar qué casos de prueba, pruebas automatizadas, revisiones o evidencias verifican cada requerimiento.
Esta relación permite medir cobertura y decidir qué pruebas ejecutar cuando cambia un requerimiento o una parte relacionada del sistema.
37.16 Relación con defectos
Vincular defectos con requerimientos ayuda a entender qué partes del alcance presentan más problemas. También permite diferenciar defectos de implementación, errores de especificación y cambios de expectativa.
Cuando se corrige un defecto, la matriz puede indicar qué pruebas deben repetirse y qué requerimientos deben volver a verificarse.
37.17 Cobertura de requerimientos
La cobertura muestra si los requerimientos tienen diseño, implementación y pruebas asociadas. Una matriz permite detectar requerimientos sin cobertura o con cobertura incompleta.
Por ejemplo, un requerimiento aprobado sin caso de prueba asociado representa un riesgo, porque no hay una evidencia clara de cómo se confirmará su cumplimiento.
37.18 Cobertura de pruebas
La matriz también permite ver pruebas que no están relacionadas con ningún requerimiento. Esto puede indicar pruebas obsoletas, alcance no documentado o necesidades que todavía no fueron formalizadas.
No toda prueba sin requerimiento es incorrecta, pero sí debe analizarse para entender si falta documentación o si la prueba ya no aporta valor.
37.19 Análisis de impacto
Ante un cambio, la matriz ayuda a identificar qué diseño, código, pruebas, documentación y entregas podrían verse afectados. Esto mejora la estimación y reduce sorpresas durante la implementación.
Un buen análisis de impacto evita aprobar cambios sin entender sus consecuencias reales sobre costo, tiempo, calidad y riesgos.
37.20 Mantenimiento de la matriz
La matriz debe actualizarse cuando se agregan, modifican, eliminan o aprueban requerimientos. También debe revisarse cuando cambian diseño, código, pruebas o defectos.
Si se actualiza solo al final del proyecto, probablemente será incompleta y poco confiable. Lo mejor es integrarla al flujo normal de trabajo.
37.21 Ejemplo de columnas
Un ejemplo de columnas puede ser: ID, descripción breve, fuente, prioridad, estado, objetivo relacionado, regla relacionada, componente de diseño, módulo de implementación, caso de prueba, defecto asociado y versión.
No es obligatorio usar todas estas columnas. Cada proyecto debe elegir las que respondan a sus necesidades de control y seguimiento.
37.22 Herramientas posibles
La matriz puede mantenerse en una hoja de cálculo, una herramienta de gestión de requerimientos, un sistema de incidencias, una plataforma de pruebas o una combinación de herramientas integradas.
Para proyectos simples, una planilla bien mantenida puede ser suficiente. Para proyectos grandes, conviene usar herramientas que reduzcan trabajo manual y errores de actualización.
37.23 Errores frecuentes
Algunos errores comunes son crear una matriz demasiado compleja, no actualizarla, duplicar información innecesaria, registrar vínculos imprecisos y usarla solo como requisito documental.
También es un error mantener relaciones que nadie consulta. La matriz debe responder preguntas reales del proyecto.
37.24 Buenas prácticas
Conviene empezar con pocas columnas, usar identificadores estables, definir responsables de actualización, revisar cobertura de forma periódica y enfocar más detalle en requerimientos críticos.
Además, la matriz debe estar disponible para analistas, desarrolladores, testers y responsables del proyecto, no guardada como un documento aislado.
37.25 Qué debes recordar
La matriz de trazabilidad organiza las relaciones entre requerimientos, diseño, código y pruebas. Permite revisar cobertura, analizar impacto de cambios y justificar decisiones.
Su utilidad depende de mantenerla simple, actualizada y orientada a preguntas concretas del proyecto.
37.26 Conclusión
Una matriz de trazabilidad bien diseñada convierte la trazabilidad en una herramienta operativa. Ayuda a ver si el equipo está construyendo lo acordado, si lo está probando correctamente y qué consecuencias tendría modificar un requerimiento.
En el siguiente tema estudiaremos la gestión de cambios en los requerimientos, una actividad fundamental para controlar cómo evoluciona el alcance durante el proyecto.