# Requirements Traceability Matrix

> 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 | | |
