Skip to content

Requirements Traceability Matrix

Artifact — instantiates Target-Complete Mapping Design

Threads every requirement through to the design, code, and verification that satisfy it, so any requirement with no downstream link — or no passing test — is a visible coverage hole.

Requirements Traceability Matrix (RTM) is the living document that threads each requirement (target) forward to the design elements, code, and verification activities that satisfy it, and backward from every test and build artifact to the requirement it exists to serve. Its defining move is to enforce bidirectional traceability as a standing contract: every requirement must terminate in at least one passing verification, and every artifact must trace back to a requirement — so an untraced requirement or an orphan test is a coverage defect surfaced by construction rather than discovered late. Where a bare coverage grid merely marks that a link exists, the RTM carries the evidence that the link works, across the whole lifecycle.

Example

An infusion pump under design controls has a requirement: "shall stop infusion within 0.5 s of an occlusion alarm." Its RTM row links a design spec, the firmware module that implements it, and a verification test carrying its latest result. At a pre-submission review the matrix shows 212 of 214 requirements traced to a passing test; two rows dead-end at "test written, last run FAILED" — one of them the occlusion-stop timing. The aggregate test-pass rate of 96% had looked shippable, but the RTM pins the two requirements not actually satisfied, converting a vague "mostly done" into a two-item blocking list. (IEC 62304 and FDA design-control practice are the real backdrop here; the figures are illustrative.)

How it works

What distinguishes it from a plain matrix is that each cell is a link plus evidence, checked in both directions. Every target row holds a preimage witness — the design, code, or test element that satisfies the requirement — and a coverage evidence record, the verification result proving the witness currently works. The coverage contract then flags two failure shapes at once: requirements with no terminating passing test (under-coverage) and artifacts that trace to no requirement (gold-plating).

Tuning parameters

  • Trace depth — requirement-to-test only, versus requirement-to-design-to-code-to-test-to-defect. Deeper traces power impact analysis but cost upkeep on every change.
  • Evidence bar — "a test exists" versus "a test passed on the current build." Raising the bar means fewer false "covered" rows and more maintenance.
  • Bidirectionality — forward-only versus both directions. Backward links are what catch work built without a requirement.
  • Baseline discipline — how tightly the matrix is frozen and re-verified per release.

When it helps, and when it misleads

Its strength is that it makes "done" mean "every requirement has current, passing evidence," and its backward links catch unrequested scope that a forward-only check never sees. Its weakness is that a trace link is not itself proof of satisfaction: a linked-but-stale or linked-but-failing test still leaves the requirement uncovered, and the matrix silently rots as the system changes underneath it. The classic misuse is back-filling traces to pass an audit — writing the links after the fact so the matrix looks complete, checkbox traceability that documents rather than drives verification.[1] The discipline that keeps it honest is to gate each link on current passing evidence and re-baseline every release, treating the matrix as the source of truth rather than the paperwork produced at the end.

How it implements the components

Requirements Traceability Matrix realizes the contract-and-evidence side of the archetype — the components that turn a claimed mapping into an evidenced one:

  • target_coverage_contract — the standing rule that every requirement must terminate in at least one passing verification, and every artifact trace back to a requirement.
  • preimage_witness_record — each row's link to the design, code, or test element that satisfies the requirement.
  • coverage_evidence_record — the attached verification result proving that witness actually works on the current build.

It does not lay out the abstract source-by-target relation — that is the Bipartite Coverage Matrix — nor construct a witness where none yet exists, which is Preimage Witness Generator; the RTM records and evidences witnesses that already exist.

Notes

A row with a trace but a failing or stale test is still an uncovered target — a link is necessary, but passing evidence is what actually closes the gap. Keep the evidence bar pinned at "current build," or the matrix quietly drifts into fiction while every requirement still shows a reassuring link.

References

[1] Bidirectional traceability — the requirements-engineering practice of maintaining links both forward (requirement to its implementation and verification) and backward (artifact to originating requirement). The backward direction is what distinguishes real traceability from a one-way coverage list, because it exposes work that answers to no requirement. ↩