30. Trazabilidad entre modelo de dominio, requerimientos y casos de uso
30.1 Introducción
La trazabilidad permite seguir la relación entre distintos artefactos del análisis: necesidades del negocio, requerimientos, casos de uso, conceptos del dominio, reglas, escenarios y pruebas. Su objetivo es evitar que el modelo de dominio quede aislado o desconectado del resto del trabajo.
Cuando existe trazabilidad, podemos responder preguntas como: ¿de qué requerimiento surge esta regla?, ¿qué caso de uso usa este concepto?, ¿qué prueba verifica este invariante?, ¿qué partes se ven afectadas si cambia una política del negocio?
30.2 Imagen conceptual de trazabilidad
30.3 Qué significa trazabilidad
Trazabilidad significa poder recorrer vínculos entre elementos relacionados. No necesariamente implica usar una herramienta compleja o generar documentación pesada. Puede comenzar con tablas simples, referencias cruzadas, identificadores o notas claras.
Por ejemplo, si el modelo contiene la regla "un paciente no puede reservar dos turnos pendientes para la misma especialidad", deberíamos poder saber qué requerimiento la originó, en qué caso de uso aparece y qué escenarios la validan.
30.4 Trazabilidad desde requerimientos
Los requerimientos suelen ser el punto de partida. Un requerimiento puede originar conceptos, atributos, asociaciones, reglas o estados del modelo de dominio.
Por ejemplo, el requerimiento "El paciente debe poder cancelar un turno con al menos 24 horas de anticipación" se relaciona con Paciente, Turno, Cancelación, política de anticipación y posiblemente con el evento Turno cancelado.
30.5 Trazabilidad desde casos de uso
Los casos de uso muestran objetivos y escenarios. Cada paso puede involucrar conceptos del dominio. Cada flujo alternativo puede revelar reglas, estados o excepciones.
En el caso de uso "Reservar turno", aparecen conceptos como Paciente, Profesional, Especialidad, Agenda, Franja horaria y Turno. También pueden aparecer reglas como disponibilidad, restricciones por paciente o confirmación posterior.
30.6 Trazabilidad hacia reglas de negocio
Una regla de negocio debería tener origen claro. Puede venir de un requerimiento, una política interna, una norma legal, una entrevista o un escenario validado. Si no sabemos de dónde salió una regla, será difícil justificarla o cambiarla.
Además, una regla puede estar relacionada con varios artefactos. Una política de cancelación puede aparecer en requerimientos, casos de uso, diagramas de estados, escenarios de prueba y documentación del negocio.
30.7 Trazabilidad hacia conceptos del dominio
Cada concepto importante debería poder explicarse. Si el modelo incluye Reserva, Cancelación, Confirmación o Inasistencia, conviene saber en qué escenarios aparecen y qué reglas dependen de ellos.
Esto evita modelos inflados con conceptos que nadie usa o conceptos críticos que no tienen respaldo en requerimientos ni procesos reales.
30.8 Trazabilidad hacia estados y eventos
Los estados y eventos también deben rastrearse. Si Turno tiene estados como Reservado, Confirmado, Atendido, Cancelado y Ausente, cada uno debería responder a escenarios reales y reglas validadas.
De igual modo, eventos como Turno reservado o Paciente ausente registrado deben tener una razón de negocio: auditoría, consecuencias posteriores, comunicación entre contextos o historial.
30.9 Trazabilidad hacia pruebas
Los escenarios validados pueden transformarse en pruebas. La trazabilidad permite conectar una prueba con la regla o requerimiento que verifica. Esto ayuda cuando una prueba falla o cuando cambia una regla.
Por ejemplo, una prueba que verifica que no se pueda cancelar un turno atendido se vincula con una regla del dominio, con el estado Atendido y con el caso de uso Cancelar turno.
30.10 Matriz simple de trazabilidad
Una forma práctica de registrar trazabilidad es una tabla. No tiene que ser compleja:
| Origen | Elemento del dominio | Regla o escenario | Verificación |
|---|---|---|---|
| REQ-01: Reservar turno | Turno, Paciente, Franja horaria | La franja debe estar disponible. | Escenario: reserva exitosa. |
| REQ-02: Cancelar turno | Cancelación, Turno | Cancelar con al menos 24 horas de anticipación. | Prueba de cancelación en límite de 24 horas. |
| CU-03: Registrar atención | Turno atendido | Un turno atendido no puede cancelarse. | Contraejemplo: cancelar turno atendido. |
| Política interna | Inasistencia | Cancelación fuera de término registra inasistencia. | Escenario: cancelación tardía. |
30.11 Trazabilidad bidireccional
La trazabilidad puede recorrerse en dos direcciones. Desde un requerimiento podemos llegar a conceptos, reglas y pruebas. Desde una regla del modelo podemos volver al requerimiento, caso de uso o política que la originó.
Esta bidireccionalidad es útil para mantenimiento. Si cambia un requerimiento, identificamos qué partes revisar. Si encontramos una regla dudosa, buscamos su origen para decidir si sigue vigente.
30.12 Impacto de cambios
Uno de los mayores beneficios de la trazabilidad es analizar impacto. Si cambia la política de cancelación de 24 a 48 horas, debemos revisar requerimientos, casos de uso, reglas, diagramas de estados, escenarios, pruebas y posiblemente comunicación con otros contextos.
Sin trazabilidad, el equipo depende de memoria o búsqueda manual. Eso aumenta el riesgo de cambios incompletos.
30.13 Cuánta trazabilidad conviene tener
No todos los proyectos necesitan el mismo nivel de trazabilidad. En sistemas pequeños puede alcanzar con referencias simples. En sistemas críticos, regulados o con muchos equipos, puede requerirse trazabilidad más formal.
La clave es que el esfuerzo sea proporcional al riesgo. La trazabilidad debe ayudar a comprender y mantener, no convertirse en burocracia sin uso.
30.14 Herramientas posibles
La trazabilidad puede gestionarse con distintas herramientas: documentos, planillas, gestores de requerimientos, tableros de trabajo, wikis, enlaces entre historias de usuario, identificadores en pruebas o repositorios de documentación.
La herramienta importa menos que la disciplina de mantener vínculos útiles y actualizados. Una planilla simple bien mantenida puede ser más valiosa que una herramienta compleja abandonada.
30.15 Preguntas para revisar trazabilidad
Estas preguntas ayudan a evaluar si la trazabilidad es suficiente:
- ¿Sabemos de dónde surge cada regla importante?
- ¿Cada concepto clave aparece en algún requerimiento, caso de uso o escenario?
- ¿Podemos identificar qué pruebas verifican una regla?
- ¿Podemos analizar impacto si cambia un requerimiento?
- ¿Hay reglas en el modelo sin origen claro?
- ¿Hay requerimientos sin representación en el modelo?
- ¿La trazabilidad se mantiene actualizada cuando cambia el dominio?
30.16 Errores frecuentes
Al trabajar con trazabilidad, suelen aparecer estos errores:
- Crear trazabilidad solo al inicio y no mantenerla.
- Registrar vínculos demasiado generales que no ayudan a decidir.
- No conectar reglas de negocio con escenarios o pruebas.
- Dejar conceptos importantes sin origen claro.
- Usar herramientas complejas sin una práctica concreta.
- Confundir trazabilidad con documentación extensa.
- No usar trazabilidad para analizar impacto de cambios.
30.17 Qué debes recordar de este tema
- La trazabilidad conecta requerimientos, casos de uso, modelo de dominio, reglas, escenarios y pruebas.
- Permite saber por qué existe un elemento del modelo.
- Ayuda a analizar impacto cuando cambia una regla o requerimiento.
- Puede ser simple o formal según el riesgo del proyecto.
- Debe mantenerse actualizada para ser útil.
- La trazabilidad bidireccional permite ir del origen al modelo y del modelo al origen.
- No debe convertirse en burocracia sin valor práctico.
30.18 Conclusión
La trazabilidad mantiene conectado el modelo de dominio con el resto del análisis. Gracias a ella, los conceptos y reglas no quedan como decisiones aisladas, sino vinculados con necesidades, escenarios y verificaciones concretas. Esto mejora el mantenimiento, reduce ambigüedad y facilita analizar cambios.
En el próximo tema estudiaremos cómo evoluciona el modelo cuando cambian reglas, aparecen nuevos conceptos o se necesita refactorizar el conocimiento del dominio.