Traceability

Traceability is a structural property of the evidence, not a separate document. It is what allows a reviewer, or the engineering team itself, to answer a specific question — why does this design decision exist, what does this requirement protect against, has this hazard actually been closed — by following references rather than reconstructing the history from memory or scattered documents.

The chain that needs to hold

• Hazard or risk to requirement: every safety or security requirement should reference the risk it addresses.
• Requirement to design: the architecture or implementation decision that satisfies the requirement should be identifiable.
• Design to verification: the test, analysis or review that confirms the design meets the requirement.
• Verification to evidence: a retained, dated record of the result, not just a pass/fail status in a tool.

Traceability breaks most often at organisational boundaries — between a supplier's component-level evidence and the integrator's system-level argument, or between a legacy analysis and a subsequently changed architecture. Stable identifiers used consistently across tools, rather than reliance on a single integrated platform, tend to survive these boundaries better.

A useful test of a traceability approach is whether a specific hazard or requirement can be followed to its accepted evidence quickly, without a manual reconciliation exercise across documents.