Skip to content

Requirements Traceability Matrix

At a glance

  • Purpose: Show that every requirement came from somewhere, is built by something, and is verified by something — and that nothing is being built without a requirement.
  • Use it when: Requirements are identified and again whenever scope, design, or tests change. It is the document that answers "why is this in the build?" and "was that requirement tested?".
  • Owner: The business analyst, maintained continuously rather than reconstructed at the end.
  • Related: Module 05 · Module 09 · Lab 06
  • Spreadsheet version: csv/requirements-traceability-matrix.csv

How to use this template

  1. Give every requirement a stable ID and never reuse one. IDs outlive requirements.
  2. Trace in both directions: from a source to a requirement (nothing invented), and from a requirement to a test (nothing unverified).
  3. Fill the source column with a person, document, or decision — not "the business".
  4. Fill the verification column with a test, review, or demonstration. A requirement with no verification is not finished.
  5. Run the three checks at the end of this template, and act on what they find. They are the whole point of the matrix.

Field descriptions

Column What goes in it Watch out for
ID FR-01, NFR-01, CON-01 (functional / non-functional / constraint) Renumbering; sequence gaps that hide deletions
Requirement One verifiable statement Bundling several requirements into one row
Type Functional, non-functional, constraint, or business rule Everything marked functional
Source The person, document, or workshop it came from "Stakeholders" or "the business"
Priority Must / Should / Could, or a value rating Everything marked Must
WBS / component Where it is built Blank for requirements nobody owns
Acceptance criterion How completion is judged "Works correctly"
Verification The test, review, or demonstration that will check it A criterion with no test
Status Proposed / agreed / built / verified / deferred Rows left at "agreed" after delivery
Change reference The change request that added or altered it Untraced additions — the whole problem this document solves

Blank template

# Requirements Traceability Matrix — [Project name]

| | |
| --- | --- |
| **Owner** | [Who maintains this] |
| **Version** | [1.0] |
| **Last updated** | [YYYY-MM-DD] |

| ID | Requirement | Type | Source | Priority | WBS / component | Acceptance criterion | Verification | Status | Change ref |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| FR-01 | [Verifiable statement] | Functional | [Person, document, or workshop] | Must | [WBS ID] | [Testable condition] | [Test or review] | Agreed | |
| NFR-01 | [Verifiable statement] | Non-functional | [Source] | Should | [WBS ID] | [Measurable target] | [Measurement method] | Agreed | |
| CON-01 | [Limit or rule] | Constraint | [Source] | Must | — | [How compliance is shown] | [Review] | Agreed | |

## Three checks

### Check 1 — Every requirement has a source
Requirements with no source are inventions. Either find the source or remove the requirement.

### Check 2 — Every requirement has a verification
Requirements with no verification are not testable and cannot be accepted.

### Check 3 — Every build item traces to a requirement
Work in the WBS or backlog with no requirement behind it is **gold plating** or unapproved scope.
This check is the one that catches scope growth after the baseline.

| Check | Rows that failed | Action |
| --- | --- | --- |
| 1. Source | | |
| 2. Verification | | |
| 3. Build trace | | |

Worked example

An extract for the admission portal from Lab 07, with invented requirements for teaching:

ID Requirement Type Source Priority WBS Acceptance criterion Verification Status
FR-01 An applicant can submit an application for one programme Functional Requirements workshop 1 Must 3.1 An unfamiliar tester completes a submission unaided Acceptance test Verified
FR-02 An applicant can upload one supporting document Functional Requirements workshop 1 Must 3.2 A 5 MB PDF uploads and is retrievable by staff Integration test Built
FR-03 An administrator can see all submitted applications Functional Admin console workshop Must 4.1 Applications list shows every submission with status Acceptance test Agreed
NFR-01 The application form responds within 2 seconds for 200 concurrent users Non-functional IT operations Should 5.2 Load test at 200 concurrent users, 95th percentile under 2 s Performance test Agreed
CON-01 Applicant data is retained for the period confirmed by the records office Constraint Records office Must 6.1 Retention configuration matches the confirmed period Review with records office Agreed
FR-04 Applicants receive an email acknowledgement Functional No source recorded — — — — Proposed

FR-04 fails Check 1, and NFR-01 has a measurable target rather than a vague one. If the build contains a "notifications" component that no requirement traces to, Check 3 has found unapproved scope — which is exactly the failure recorded in Lab 25.

Common mistakes

  • A one-way matrix. Tracing requirements forward to tests but not backward to sources misses invented requirements, which are the more expensive category.
  • Untestable acceptance criteria. "Works correctly" cannot fail, so it cannot be verified.
  • Maintaining it at the end. A traceability matrix reconstructed after delivery is a documentation exercise, not a control.
  • Using it as a workload tracker. It records traceability, not progress; the schedule does that.
  • Sources recorded as roles. "The business" cannot be asked whether the requirement is still valid.
  • Forgetting non-functional requirements. They are usually where acceptance actually fails, and they are usually the rows left blank.