System Design
Trazabilidad del diseño
Explica cómo conectar problemas, objetivos, requisitos, decisiones, componentes, pruebas y métricas para comprender el origen y el impacto de cada cambio.
- Última actualización
- Actualizada
- Nivel
- Profundización
System Design
Explica cómo conectar problemas, objetivos, requisitos, decisiones, componentes, pruebas y métricas para comprender el origen y el impacto de cada cambio.
La trazabilidad permite responder dos preguntas: ¿qué necesidad justifica este elemento? y ¿qué evidencia demuestra que la necesidad quedó cubierta?
La trazabilidad conecta objetivos, requisitos, reglas, diseños, implementación, pruebas y señales operativas. No exige una matriz burocrática; exige relaciones suficientes para explicar origen e impacto.
problema
→ objetivo
→ requisito
→ historia/caso
→ regla
→ decisión y modelo
→ implementación
→ prueba
→ métrica o evidenciaComprueba que cada necesidad llegue a una solución y una forma de verificación.
Permite justificar por qué existe una API, campo, componente o prueba.
Ambas detectan requisitos huérfanos y funcionalidades sin propósito.
Problema: pedidos incompletos
OBJ-01: reducir errores de captura
RF-01: registrar productos, cantidades y dirección obligatoria
RB-03: cantidad > 0
CU-04: registrar pedido
Diseño: Order + OrderLine + validación de dirección
Contrato: POST /orders
Pruebas: aceptación, dominio e integración
SLI: porcentaje de pedidos rechazados por datos incompletosLa cadena muestra tanto construcción como evidencia de resultado.
Ante “permitir pedidos programados”, la trazabilidad conduce a:
Así se evita tratar el cambio como un campo aislado.
No enlaces cada línea de código. Prioriza artefactos que cambian decisiones o garantías. IDs estables, enlaces y relaciones en Notion suelen ser suficientes cuando están mantenidos.
Una relación no prueba cumplimiento. RF-01 → CT-12 indica intención; el resultado de la prueba y la métrica aportan evidencia. Distingue vínculo, estado y evidencia.
Cuando un requisito se reemplaza, conserva historial:
RF-07 v1 → deprecado
RF-07 v2 → activo
ADR-12 → explica transiciónNo edites el pasado hasta parecer que siempre se diseñó así.
Puede detectarse:
La automatización ayuda, pero no comprende por sí sola si la relación tiene sentido.
Un requisito puede afectar varias pruebas y un test cubrir varias reglas. Evita forzar una jerarquía falsa.
Entrevistas, tickets o contratos pueden ser fuentes; enlaza ubicación y fecha.
OpenAPI o esquema de base pueden generarse, pero todavía necesitan vínculo con significado y decisión.
Puede no alterar requisitos, pero sí componentes, riesgos, pruebas estructurales y despliegue.
Validación y revisión del diseño utiliza escenarios y perspectivas para comprobar coherencia, utilidad y factibilidad.