A requirements traceability matrix is a document that links every requirement to the design, code, test cases, and defects that prove it was delivered. Its job is to answer two questions on demand: is every requirement covered by something? and does every piece of work exist because of a requirement? When both answers are yes, you have coverage. When either is no, you have a gap — and gaps are what audits, escaped defects, and scope disputes are made of.

Most teams build one because a standard, a customer, or a regulator asked for it. The teams that get value from it build it because it makes change cheap. This guide covers the columns that matter, a worked example you can copy, and the seven ways traceability quietly stops working.

The matrix is not paperwork. It is an index of relationships. Each row represents one requirement and carries pointers to every artifact downstream of it.

Three things become possible once those pointers exist:

•      Coverage checking. You can list requirements with no linked test case in seconds instead of reading a test plan cover to cover.

•      Change impact analysis. When a stakeholder changes requirement REQ-042, you can see the four test cases, two modules, and one open defect that just became suspect.

•      Audit evidence. In regulated work, the matrix is the artifact an assessor asks for first, because it demonstrates that the process was followed rather than asserted.

Which standards expect it

Traceability is not an agile-versus-waterfall argument in regulated sectors — it is a condition of shipping.

Under DO-178C, code with no upstream requirement is a certification finding — it is classified as extraneous, regardless of whether it works correctly. That is the sharpest illustration of why backward traceability matters as much as forward.

An RTM bloats fast. Every column you add is a column someone has to maintain. Start with these and add only what a stakeholder will actually read.

Two columns quietly do most of the work: test case IDs and test status. A matrix that lists linked tests but never their outcome tells you a test exists, not that the requirement works.

The three traceability directions

•      Forward traceability runs from requirement to test case. It answers: has this been verified? A requirement with no forward link is an untested promise.

•      Backward traceability runs from test case, code, or defect back to a requirement. It answers: why does this exist? Work with no backward link is either gold-plating or an undocumented requirement.

•      Bidirectional traceability is both maintained at once, and it is what most standards actually require. It is also the harder discipline, because it means you cannot merge orphan work quietly.

Here is a fragment from an authentication feature. Note that REQ-044 is the interesting row.

Two findings drop out of four rows. REQ-044 is built but has no test case — a coverage gap that a green build will happily hide. REQ-045 has a failing test and a linked defect, so it is not release-ready no matter what the burndown says. That is the whole point of the artifact: it surfaces what the sprint board does not.

1. Building it after the fact. A matrix assembled the week before an audit is archaeology, not traceability. It records what people remember, and it has zero influence on decisions already made. Links should be created when the work is created.

2. Unstable requirement IDs. If REQ-042 gets renumbered when someone inserts a requirement above it, every link in the matrix silently points at the wrong thing. IDs must be assigned once and never reused, even after deletion.

3. Requirements that cannot be tested. "The system shall be user-friendly" cannot be traced because it cannot be verified. Untestable requirements produce empty cells that people learn to ignore, and ignored cells spread.

4. Tracing to test cases but not test results. Coverage is not a count of links. A requirement mapped to six test cases that have not run since March is not covered — it is documented.

5. One matrix for the whole programme. A single spreadsheet spanning five products and three years becomes unreadable and un-mergeable. Scope the matrix to a product line and a release, then roll up.

6. Manual maintenance in a spreadsheet. The matrix is a join across four systems: requirements, code, tests, and defects. Maintaining that join by hand means it is accurate on the day it is written and decaying every day after. Spreadsheets also have no notion of "this link is now suspect because the requirement changed."

7. No owner. Traceability without a named owner degrades to whoever last needed it. Assign it to the business analyst or QA lead who runs release readiness, and review the coverage report at every gate.

Excel is a perfectly reasonable place to start. It is free, everyone has it, and for a single product with fifty requirements it is faster than configuring a tool. Build it with one row per requirement, use VLOOKUP or XLOOKUP against a test case sheet rather than typing IDs twice, and add conditional formatting that turns any empty test-case cell red.

The spreadsheet stops working at a predictable point: when requirements change often enough that the matrix goes stale between updates, or when more than one person edits it. At that point the matrix is being maintained rather than generated, and maintained matrices drift.

The alternative is to hold requirements, tests, and defects in one system so the matrix is a live report rather than a document. This is where tool choice bites. In a Jira-centred stack, requirements are issues, test cases live in a separate paid app such as a test management add-on, and the traceability report is a third app on top — three licences and two integrations before you see a coverage gap.

Sanplex takes the opposite approach: stories, tasks, bugs, and test cases are distinct native object types inside one product, and a story tracking matrix is built in rather than purchased. Because a test case links natively to the story it verifies and a failed test step raises a linked bug directly, the coverage view is a query against data you already have. Sanplex Premium extends this with built-in review, baseline, and configuration management for teams working to CMMI Level 4 and 5 expectations. You can compare the module-by-module differences on the Sanplex vs Jira page.

Traceability on agile teams

Agile teams often assume traceability is a waterfall relic. It is not — the granularity just changes. Instead of tracing a 40-page specification, you trace user stories to acceptance criteria to automated tests. The discipline is the same: every story has acceptance criteria, every criterion has a test, and no code merges without a linked story. Definition of Done is where traceability gets enforced on an agile team; if the DoD does not mention linked tests, the matrix will always be built retroactively.