Requirements Traceability Matrix Template
A working RTM, one row per requirement through to verification, plus the two orphan checks that are the whole point and the coverage summary to review weekly.
Markdown. No sign-up, no email.
Generate this from tagged tests and tickets if you possibly can. A matrix maintained by hand is accurate on the day it is written and misleading a fortnight later.
It rests entirely on stable requirement identifiers that are never reused. Retire them; do not recycle them.
Project: _______________ Owner: _______________ Generated / updated: _______ Source of requirements: _______________
The matrix#
| Req ID | Requirement (short) | Source | Design ref | Component | Test case(s) | Status | Verified on |
|---|---|---|---|---|---|---|---|
| FR-001 | BRD-_ | TC-___ | not started / in progress / passed / failed | ||||
| FR-002 |
Status vocabulary, agree it once:
| Status | Means |
|---|---|
| Not started | No test written |
| In progress | Test written, not run against current build |
| Passed | Verified on the build dated ___ |
| Failed | Defect ___ raised |
| Withdrawn | Requirement removed by change ___ (identifier NOT reused) |
The two checks that matter#
Run these weekly. They are the reason the matrix exists, and everything above is just the data they read.
1. Requirements with no test: the coverage gap#
| Req ID | Why there is no test | Owner | By when |
|---|---|---|---|
2. Tests with no requirement: the scope question#
| Test case | What it covers | Is this scope somebody added, or a missing requirement? |
|---|---|---|
Backward tracing is the half most teams skip. It is what catches work that accumulated without a decision, and it is invaluable when someone asks whether a feature can be removed.
Coverage summary#
| Count | |
|---|---|
| Total requirements | |
| With at least one test | |
| Verified on the current build | |
| Failed | |
| No test at all | |
| Tests with no requirement |
Coverage % (verified ÷ total): ____
Report "verified on the current build", not "verified at some point". A requirement passed in March, on a March build, against requirements that changed in May, is not evidence.
Change log#
Every requirement change must reach this matrix, or the chain breaks silently, and the matrix will still look complete, which is worse than looking incomplete.
| Date | Change ref | Requirement(s) affected | Tests to update | Done |
|---|---|---|---|---|
Scope note#
Tracing everything is rarely worth it. Trace what has to be demonstrable: regulated requirements, contractual commitments, anything tied to money or safety. Ordinary tests are their own traceability for the rest.
What we are tracing on this project: _______________ What we deliberately are not, and why: _______________
Sign-off#
| Name | Date | |
|---|---|---|
| Owner | ||
| Test lead | ||
| Coverage accepted for release by |