Requirements Traceability Matrix
Every requirement linked forward to the design element that satisfies it and the test that proves it, so nothing is silently dropped.
A requirement, the design decision that addresses it, and the test that demonstrates it — one row each, with the gaps visible. In validated environments it is a regulatory obligation; everywhere else it is the cheapest way to catch a requirement that quietly fell out during design.
The shape
| Req | Requirement | Source | Design element | Verified by | Status |
|---|---|---|---|---|---|
| FR-04 | Amend an order until despatch | BRD §3.2 | Order state machine; amend endpoint | IT-11, UAT-03 | Met |
| FR-09 | Partial refund per line | BRD §3.7 | Refund service; line-level ledger | IT-19 | Met |
| NF-01 | p99 submit < 400 ms | NFR matrix N1 | Read replica; cache; async fulfilment | PT-02 | Met |
| NF-05 | RTO 30 min, region loss | NFR matrix N5 | Multi-region topology; warm standby | DR-01 (2026-05-18) | Met |
| RG-02 | Erasure within 30 days | GDPR Art.17 | Erasure job; crypto-shred in archive | CT-07 | Partial — archive not covered |
| RG-05 | Full audit trail of price changes | Internal policy | Append-only price event log | CT-09 | Met |
| SE-03 | No card data at rest | PCI-DSS 3.4 | Tokenisation at edge | SEC-02 scan | Met |
| IN-02 | EDI to partner within 1 h | Contract §7 | Scheduled AS2 job | IT-24 | At risk — partner sandbox unavailable |
| FR-17 | Bulk order upload | BRD §3.9 | — | — | Not addressed — deferred, see ADR-021 |
When you produce it
For anything with a formal acceptance, an external auditor, or a supplier contract. Start it during requirements and grow it — written retrospectively it is a compliance exercise that catches nothing.
Who reads it
Reviewers signing off the design. Test leads deriving coverage. Auditors, in validated environments, where the matrix is the artifact they trace through. Procurement, comparing a supplier's claims with the contract.
What good looks like
- Both directions work: every requirement reaches a test, and every test traces to a requirement. Orphan tests are as informative as orphan requirements.
- Non-functional and regulatory requirements are in the same matrix as functional ones — segregating them is how NFRs get dropped.
- "Not addressed" rows are present and point at a decision record. A deliberate deferral is a valid state; an invisible one is not.
- Source column cites a specific clause, not a document name.
- Maintained in a tool that links to the actual tests, not typed twice.
Common mistakes
- Written at the end, when it can only confirm what happened.
- Functional requirements only, so the performance and regulatory ones have no owner.
- One-to-one mapping assumed. One requirement often needs several design elements and several tests, and forcing one row per pair hides that.
- Status never revisited after the first sign-off.