Why it matters
Traceability matters because systems change. When a requirement changes, the team needs to know what else is affected and whether verification coverage still makes sense.
What is requirements traceability?
Requirements traceability links requirements to design elements, verification methods, dependencies, and decisions so teams can understand coverage and impact.
Requirements traceability
Requirements traceability is the practice of connecting requirements to the artifacts that satisfy, implement, verify, derive from, or depend on them. A traceable requirement is not just a sentence in a document. It has relationships to the subsystem that owns it, the design element that satisfies it, the test or analysis that verifies it, and the decisions that shaped it.
Common mistakes
- Keeping requirements in a spreadsheet disconnected from architecture
- Rebuilding traceability right before reviews
- Confusing requirement status with real verification coverage
Where this concept fits in Cairn
Cairn stores trace links between model artifacts. Requirements can connect to nodes, verifications, and related artifacts so traceability becomes part of the model rather than a spreadsheet assembled before a review.
FAQ
Is a requirements spreadsheet traceability?
It can be a starting point, but traceability is the relationship network between requirements, design elements, verifications, and dependencies.
Can traceability be useful before formal requirements management?
Yes. Early traceability helps teams see impact and gaps before the model becomes too large to reconstruct manually.