Requirements traceability matrix: proving every requirement was tested

A requirements traceability matrix is a table that connects each requirement to the things that satisfy and verify it: the design element, the implementation, and the test case that proves it works. In regulated development — medical devices, aerospace, automotive, pharma software — it is a deliverable an assessor asks for by name. Everywhere else it is optional and still useful, because it answers the two questions nobody can otherwise answer: has everything we promised been built, and has everything we built been tested.

What a requirements traceability matrix contains

• A unique identifier per requirement, stable for the life of the product — renumbering a requirement mid-project is how traceability quietly breaks.
• The requirement itself, stated so it can be verified. "The system should be fast" cannot be traced to a test; "responds within 500 ms at 100 concurrent users" can.
• The source: which stakeholder, regulation or upstream document it came from. This is what lets you delete a requirement safely years later.
• Where it is satisfied — the design element, module or component.
• How it is verified: the test case, inspection or analysis, by reference rather than description.
• Current status, and the change history where the requirement has been revised.

The two directions that matter

1. Forward: every requirement leads to something built and something tested. Gaps here are unimplemented or unverified promises.
2. Backward: every test and every component traces back to a requirement. Orphans here are work nobody asked for, which is either scope creep or a missing requirement — both worth knowing about.
3. Run both checks as queries rather than by reading. If the matrix cannot be filtered to show gaps in one action, it is too elaborate to maintain.
4. Check at every baseline, not at the end. A matrix assembled in the final week documents what happened; it does not influence it.

The matrix is a by-product, not a document. Where teams write it separately from the work, it drifts within weeks and becomes an exercise in reconstruction before an audit. Where the identifiers live in the tickets and the test names, the matrix is a report you can regenerate — and regenerating it is the only version anyone will trust.

Where it goes wrong

• Requirements written as narrative prose, so a single paragraph contains four testable claims and traces to nothing cleanly.
• Coverage recorded at document level — "tested in the system test plan" — which proves nothing about the individual requirement.
• A separate spreadsheet maintained by one person, which becomes unreliable the first week they are on leave.
• Changes made to requirements without a corresponding change to the tests, so the matrix shows full coverage of an outdated specification.
• Confusion with the design history file, which is the wider record of how the product was developed; the matrix is one part of it, not a substitute.

Where the matrix lives

Ettex Sheets is a reasonable home for this at small and medium scale: one row per requirement, with identifier, source, design reference, test reference and status as columns, filtered to show the gaps rather than read end to end. Keep the identifiers the same as those used in your tickets and test names, or the matrix becomes a translation layer nobody maintains. Ettex is not an application lifecycle management tool — there is no automatic linking to code or test runs, and for a large regulated programme a dedicated ALM system will pay for itself. Below that scale, the spreadsheet that is actually kept beats the tool that is abandoned.