How to Build a Traceability Matrix
Prove every requirement is tested — and every test traces to a requirement.
What a how-to is not
A how-to is SPEQ’s practitioner method, not a procedure. It does not replace your own SOP, it is not a validated approach, and the judgement calls in it belong to your quality unit.
A traceability matrix links requirements to design/specifications and to the tests that verify them, so you can demonstrate complete coverage in both directions. In computerized-system validation and qualification it is the artifact that proves nothing was missed and no test exists without a reason.
- 1
Start from the requirements
Start from the requirements as the spine, with each one uniquely identified and stated so that a verification could fail it. The matrix inherits the quality of the requirements: an untestable requirement produces a row that cannot be honestly completed, and the usual response — recording a test that does not actually test it — is how a matrix becomes decorative.
- 2
Link requirements to design and risk
Link each requirement forward to the design elements that satisfy it and to the risk assessment entries that bear on it. This is the link that makes the matrix useful during change rather than only at the end: when a design element changes, the matrix answers which requirements and which risks are affected, which is the assessment change control needs and rarely has.
- 3
Link requirements to verification
Link each requirement to the verification that demonstrates it — commissioning test, qualification protocol, supplier documentation leveraged with its rationale, or design review finding. Record which, because the evidence type carries different weight and an inspector will ask. A requirement verified by supplier documentation is a legitimate position that has to be visible as such.
- 4
Check coverage both ways
Check coverage in both directions, and treat the reverse direction as the valuable one. Forward, an unverified requirement is an obvious gap. Backward, a verification that traces to no requirement is either scope nobody asked for or a requirement nobody wrote down — and the second is the more common and the more dangerous, because it means the matrix is incomplete rather than merely padded.
- 5
Maintain it through change
Maintain the matrix through change rather than assembling it at the end. A matrix built retrospectively documents what happened and can no longer influence anything; one maintained live is the instrument that tells a change assessment what it touches. This is the single difference between a traceability matrix that earns its cost and one that is produced for the binder.
- !Requirements without stable identifiers, so links break as documents change.
- !One-directional traceability that hides orphan tests or untested requirements.
- !A matrix built once and never maintained, diverging from reality.
- !Tracing to test titles rather than to specific, executed test evidence.
How to Build a Traceability Matrix: frequently asked questions
Common questions on build a traceability matrix.
What is a traceability matrix?
A document that links requirements to their design/implementation and to the tests that verify them, in both directions, so you can demonstrate that every requirement is verified and every test traces to a requirement. It is core evidence of validation coverage.
What are the two failure modes it catches?
A requirement with no verifying test (a coverage gap) and a test with no originating requirement (an orphan). Bidirectional traceability surfaces both; one-directional traceability hides one of them.
Why do requirements need stable identifiers?
Because the matrix links to them. Without stable IDs, links break whenever documents are revised, and traceability silently degrades — which is why requirement identity should not depend on wording or position that can change.