33. Trazabilidad entre casos de uso, requisitos y pruebas
33.1 Introducción
La trazabilidad permite relacionar elementos del análisis, diseño, desarrollo y pruebas. En el contexto de casos de uso, ayuda a saber de dónde surge una funcionalidad, qué requisitos la detallan, qué reglas la condicionan y qué pruebas verifican su cumplimiento.
Sin trazabilidad, un cambio aparentemente pequeño puede generar dudas: ¿qué casos de uso afecta?, ¿qué requisitos deben actualizarse?, ¿qué pruebas hay que repetir?, ¿qué pantallas o servicios pueden cambiar?
La trazabilidad no es solo una actividad documental. Es una herramienta práctica para controlar cambios, validar cobertura y reducir riesgos durante el proyecto.
33.2 Qué significa trazar
Trazar significa establecer una relación explícita entre dos o más elementos. Por ejemplo, una necesidad del usuario puede relacionarse con un caso de uso; ese caso de uso puede relacionarse con requisitos funcionales; y esos requisitos pueden relacionarse con pruebas.
La trazabilidad permite recorrer esas relaciones hacia adelante y hacia atrás. Desde una necesidad se puede llegar a las pruebas que la verifican. Desde una prueba fallida se puede volver al requisito y al caso de uso que intenta validar.
33.3 Cadena de trazabilidad
Una cadena típica conecta la necesidad inicial con el caso de uso, los requisitos derivados, las reglas de negocio, los elementos de diseño y las pruebas. Esta conexión ayuda a comprobar que no se construyen funcionalidades sin justificación y que no quedan necesidades sin verificar.
33.4 Trazabilidad hacia adelante
La trazabilidad hacia adelante parte de una necesidad o caso de uso y permite ver qué elementos lo desarrollan o verifican.
Ejemplo:
Caso de uso: CU-01 Solicitar turno.
Requisitos: listar horarios disponibles, registrar reserva, enviar confirmación.
Pruebas: prueba de reserva exitosa, prueba de horario no disponible, prueba de confirmación.
33.5 Trazabilidad hacia atrás
La trazabilidad hacia atrás permite tomar un requisito, una prueba o una funcionalidad implementada y encontrar su origen. Esto ayuda a detectar trabajo sin justificación o pruebas desconectadas de objetivos reales.
Por ejemplo, si existe una prueba para validar recordatorios por mensaje, la trazabilidad debería indicar qué caso de uso o requisito justifica ese comportamiento.
33.6 Identificadores estables
Para lograr trazabilidad, cada elemento importante necesita un identificador estable. Por ejemplo:
- CU-01 para casos de uso.
- RF-01 para requisitos funcionales.
- RN-01 para reglas de negocio.
- RNF-01 para requisitos no funcionales.
- TC-01 para casos de prueba.
Los identificadores permiten crear relaciones claras sin depender solo de nombres que pueden cambiar.
33.7 Matriz de trazabilidad
Una matriz de trazabilidad es una tabla que muestra relaciones entre elementos. Puede ser simple o muy detallada, según el proyecto.
| Caso de uso | Requisito funcional | Regla de negocio | Prueba |
|---|---|---|---|
| CU-01 Solicitar turno | RF-01 Mostrar horarios disponibles | RN-01 No reservar horarios ocupados | TC-01 Reserva exitosa |
| CU-01 Solicitar turno | RF-02 Registrar reserva | RN-02 Evitar doble reserva | TC-02 Horario ya reservado |
| CU-02 Cancelar turno | RF-05 Cancelar reserva existente | RN-03 Cancelación hasta 24 horas antes | TC-06 Cancelación fuera de plazo |
33.8 Cobertura de requisitos
La trazabilidad permite verificar cobertura. Si un requisito no tiene pruebas asociadas, quizá no se está verificando. Si una prueba no se relaciona con ningún requisito, quizá está mal ubicada o falta documentar su origen.
La cobertura no garantiza calidad por sí sola, pero ayuda a detectar huecos importantes.
33.9 Control de cambios
Cuando cambia un caso de uso, la trazabilidad ayuda a identificar impacto. Por ejemplo, si cambia la regla de cancelación de turnos, se pueden localizar los requisitos y pruebas relacionados.
Esto evita que el equipo actualice la especificación pero olvide modificar pruebas, mensajes, reglas o documentación relacionada.
33.10 Trazabilidad con flujos
La trazabilidad puede llegar al nivel de flujos. Un flujo alternativo o una excepción pueden tener pruebas específicas.
Ejemplo:
- Flujo principal de CU-01: prueba de reserva exitosa.
- Flujo alternativo A1: prueba de búsqueda por profesional.
- Excepción E1: prueba de horario no disponible al confirmar.
33.11 Trazabilidad con reglas de negocio
Las reglas de negocio suelen afectar varios casos de uso. Por eso conviene trazarlas explícitamente.
Por ejemplo, la regla "un médico no puede tener dos turnos en el mismo horario" puede afectar Solicitar turno, Modificar turno y Registrar turno presencial. Una prueba de esa regla debe considerar esos contextos.
33.12 Trazabilidad con requisitos no funcionales
Los requisitos no funcionales también deben trazarse. Si Solicitar turno exige respuesta en menos de 3 segundos, debe existir alguna verificación de rendimiento relacionada.
Si el caso de uso maneja datos sensibles, la trazabilidad puede relacionarlo con requisitos de privacidad, permisos y auditoría.
33.13 Herramientas posibles
La trazabilidad puede mantenerse con diferentes herramientas:
- Tablas simples en documentos o planillas.
- Gestores de requisitos.
- Sistemas de seguimiento de tareas.
- Repositorios de pruebas.
- Documentación enlazada en una wiki.
La herramienta importa menos que la disciplina de mantener las relaciones actualizadas.
33.14 Nivel adecuado de trazabilidad
No todos los proyectos necesitan el mismo nivel de trazabilidad. En sistemas críticos, regulados o contractuales, puede ser necesaria una matriz detallada. En proyectos pequeños, puede alcanzar con relaciones simples entre casos de uso y pruebas.
La trazabilidad debe aportar control y claridad, no convertirse en una carga que nadie mantiene.
33.15 Ejemplo aplicado a Solicitar turno
Para CU-01 Solicitar turno, podríamos tener:
Caso de uso: CU-01 Solicitar turno.
Requisitos funcionales: RF-01 buscar disponibilidad, RF-02 confirmar reserva, RF-03 enviar confirmación.
Reglas: RN-01 no permitir doble reserva, RN-02 paciente registrado.
Pruebas: TC-01 reserva exitosa, TC-02 horario ocupado, TC-03 paciente no registrado.
33.16 Errores frecuentes
Al trabajar con trazabilidad, suelen aparecer estos errores:
- No asignar identificadores estables.
- Relacionar elementos solo de memoria.
- No actualizar relaciones cuando cambia un caso de uso.
- Tener pruebas sin requisito asociado.
- Tener requisitos sin pruebas.
- Crear una matriz demasiado detallada para un proyecto simple.
- No usar la trazabilidad para analizar impacto de cambios.
33.17 Lista de revisión
Antes de cerrar la trazabilidad, conviene revisar:
- ¿Cada caso de uso importante tiene identificador?
- ¿Los requisitos derivados están relacionados con casos de uso?
- ¿Las reglas de negocio críticas están vinculadas?
- ¿Cada requisito importante tiene pruebas?
- ¿Las pruebas están conectadas con requisitos o flujos?
- ¿Se puede analizar impacto ante un cambio?
- ¿La trazabilidad es mantenible para el equipo?
33.18 Qué debes recordar de este tema
- La trazabilidad conecta necesidades, casos de uso, requisitos y pruebas.
- Permite avanzar desde una necesidad hasta su verificación.
- También permite volver desde una prueba o requisito hasta su origen.
- Los identificadores estables facilitan mantener relaciones.
- La matriz de trazabilidad ayuda a revisar cobertura e impacto.
- El nivel de trazabilidad debe ajustarse al proyecto.
- Una trazabilidad útil se mantiene actualizada y se usa para tomar decisiones.
33.19 Conclusión
La trazabilidad evita que casos de uso, requisitos y pruebas queden desconectados. Permite saber por qué existe una funcionalidad, cómo se expresa en requisitos y cómo se verifica.
Cuando se mantiene con criterio, mejora el control de cambios, la cobertura de pruebas y la comunicación del equipo. En el próximo tema estudiaremos la relación entre casos de uso y prototipos de interfaz.