Requirements Traceability in DO-254

Traceability is often reduced to a matrix. A matrix is a representation of traceability, not the thing itself. What a reviewer is assessing is whether the chain of reasoning from an allocated system requirement to a verification result holds together, and whether anything in the implemented hardware falls outside it.

The links that must hold

1. System requirements allocated to hardware, with the allocation itself justified.
2. Hardware requirements that are verifiable as written, including derived requirements with their rationale.
3. Design data showing how each requirement is implemented.
4. Verification procedures that demonstrate the requirement, at a level of rigour matching the design assurance level.
5. Verification results, including the configuration they were produced against.
6. Problem reports linked to whatever they affect, with their disposition recorded.

A chain is only as strong as its weakest link, and in practice the weakest link is usually the verification procedure. A requirement can be well written and clearly implemented, yet be verified by a test that would pass whether or not the requirement was met.

Bidirectionality is the part teams skip

Forward traceability answers whether every requirement has been implemented and verified. Backward traceability answers the harder question: whether every element of the implementation traces to a requirement. Functionality present in the device but absent from the requirements is either dead logic, an undocumented derived requirement, or a defect. All three matter, and only backward traceability finds them.

Forward traceability shows that you built what you said you would. Backward traceability shows that you did not build anything else.

Signals that a chain will not survive review

• Requirements that restate the design rather than constrain it.
• Verification procedures traced to many requirements without stating which aspect each one demonstrates.
• Results recorded without the configuration identifier of the item under test.
• Derived requirements with no recorded rationale and no evidence they reached the safety assessment.
• Problem reports closed without tracing the change back through the affected life cycle data.

A traceability health check looks for exactly these signals. Finding them early is inexpensive; finding them during a stage of involvement review is not.