# Requirements Traceability Matrix: [Product or system name]

> Requirements traceability matrix (RTM) linking each business need through
> stakeholder, system and software requirements to design, code, tests and
> results, in both directions. Structured to support the bidirectional
> traceability described in ISO/IEC/IEEE 29148:2018. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Fix the ID conventions in section 2 before filling any table; traceability
  breaks when two teams number the same thing differently.
- Maintain the matrix continuously, not at the end. Update it in the same
  change that adds a requirement, a component or a test.
- Read it in both directions: forward (is every need delivered and
  tested?) and backward (does every test and component serve a need?).
- If a tool generates the matrix, keep this document for conventions,
  metrics and the gap analysis, and attach the export.
-->

| Field | Value |
|---|---|
| Document ID | [RTM-PRODUCT-001] |
| Version | [0.1] |
| Status | [Draft / In review / Baselined] |
| Owner | [@requirements-owner] |
| Baseline | [Requirements baseline ID, for example REQ-BL-2.0] |
| Last updated | YYYY-MM-DD |
| Source of truth | [Tool or repository where links are maintained] |

## 1. Purpose and scope

<!-- Guidance: State which artefacts and which release the matrix covers, and who uses it for what decisions. -->

This matrix shows, for [Product name] [release], how every business need
is realised by requirements, design elements and code, and how every
requirement is verified. It is used to:

- confirm that every agreed need is delivered and tested (coverage);
- find requirements, components or tests with no parent (orphans);
- assess the impact of a proposed change before it is approved;
- give auditors and customers evidence of verification.

Out of scope: [artefacts not traced, for example UI copy, internal
tooling].

## 2. ID conventions

<!-- Guidance: One prefix per artefact type, never reused, never renumbered. Write the format and the system where each ID is issued. -->

| Artefact | Prefix and format | Issued in | Example |
|---|---|---|---|
| Business need / objective | `BN-nnn` | Business case / BRS | BN-004 |
| Stakeholder requirement | `STK-UR-nnn` | StRS | STK-UR-012 |
| System requirement | `SYS-<type>-nnn` | SyRS | SYS-FR-020 |
| Software requirement | `SRS-<type>-nnn` | SRS / backlog | SRS-FR-031 |
| Design element | `DES-<component>` or ADR-nnn | Architecture description | DES-SYNC, ADR-007 |
| Code component | Repository path or module | Source control | `services/sync` |
| Test case | `TC-<area>-nnn` | Test management tool | TC-SYNC-004 |
| Test result | Run ID | CI or test tool | RUN-2026-118 |

Link types used: **derives** (child requirement from parent), **satisfies**
(design or code satisfies a requirement), **verifies** (test verifies a
requirement).

## 3. Forward traceability

<!-- Guidance: One row per lowest-level requirement. Read left to right: does each need reach a passing test? Leave a cell visibly empty with "none" rather than blank, so gaps stand out. -->

| Business need | Stakeholder req | System req | Software req | Design | Code / component | Test | Result |
|---|---|---|---|---|---|---|---|
| *Example:* BN-004 | STK-UR-010 | SYS-FR-020 | SRS-FR-031 | DES-SYNC | `services/sync` | TC-SYNC-001 | Pass (RUN-118) |
| *Example:* BN-004 | STK-UR-010 | SYS-FR-021 | SRS-FR-032 | DES-SYNC, ADR-007 | `services/sync/queue` | TC-SYNC-004 | Fail (RUN-118) |
| *Example:* BN-002 | STK-UR-002 | SYS-FR-010 | SRS-FR-012 | DES-DISPATCH | `services/dispatch` | TC-DSP-002 | Pass (RUN-117) |
| *Example:* BN-006 | STK-UR-030 | SYS-PL-001 | SRS-FR-050 | DES-REPORTS | none | none | Not started |
| [BN-nnn] | [STK-UR-nnn] | [SYS-xx-nnn] | [SRS-xx-nnn] | [DES-x] | [path] | [TC-x-nnn] | [Pass / Fail / Not run] |

## 4. Backward traceability

<!-- Guidance: Start from the right-hand side. Every test and component should trace back to a requirement and a need; those that do not are either missing requirements or gold plating. -->

| Test case | Verifies | Software req | System req | Stakeholder req | Business need |
|---|---|---|---|---|---|
| *Example:* TC-SYNC-001 | SRS-FR-031 | SRS-FR-031 | SYS-FR-020 | STK-UR-010 | BN-004 |
| *Example:* TC-UI-077 | none | none | none | none | none (orphan test) |
| [TC-x-nnn] | [ID] | [ID] | [ID] | [ID] | [ID] |

| Component | Satisfies | Business need |
|---|---|---|
| *Example:* `services/sync` | SRS-FR-031, SRS-FR-032 | BN-004 |
| *Example:* `services/legacy-export` | none | none (orphan component) |
| [path] | [IDs] | [BN-ID] |

## 5. Coverage metrics

<!-- Guidance: Report the same metrics at each milestone so trends are visible. Define the denominator precisely: usually approved requirements in the current baseline. -->

Requirement coverage by tests and verification pass rate are calculated
as:

$$
C_{test} = \frac{|R_{\text{with}\ge 1\text{ test}}|}{|R_{\text{approved}}|} \times 100\%
\qquad
P_{verified} = \frac{|R_{\text{all tests passed}}|}{|R_{\text{approved}}|} \times 100\%
$$

| Metric | Formula / definition | Target | Current | Trend |
|---|---|---|---|---|
| Forward coverage to tests | $C_{test}$ | 100% for Must | [n]% | [Up / Down / Flat] |
| Verified requirements | $P_{verified}$ | 95% at release | [n]% | [Trend] |
| Backward coverage of needs | Needs with at least one requirement / all needs | 100% | [n]% | [Trend] |
| Design coverage | Requirements with a satisfying design element / approved | 100% | [n]% | [Trend] |
| Orphan tests | Tests with no requirement link | 0 | [n] | [Trend] |
| Orphan components | Components with no requirement link | 0 | [n] | [Trend] |

*Example:* 186 approved requirements, 179 with at least one test:
$C_{test} = 179 / 186 = 96.2\%$.

## 6. Orphan and gap analysis

<!-- Guidance: List every gap found, decide what to do and assign it. Common causes: requirement added without a test, test written for removed behaviour, component built from an informal request. -->

| ID | Type | Item | Finding | Action | Owner | Due | Status |
|---|---|---|---|---|---|---|---|
| GAP-01 | Untested requirement | SRS-FR-050 | No design, code or test yet | Plan in sprint 14 | [@lead] | YYYY-MM-DD | Open |
| GAP-02 | Orphan test | TC-UI-077 | Tests a removed feature | Delete test | [@qa] | YYYY-MM-DD | Open |
| GAP-03 | Orphan component | `services/legacy-export` | No requirement; used by finance | Raise requirement or retire | [@po] | YYYY-MM-DD | Open |
| GAP-04 | Failed verification | SRS-FR-032 | TC-SYNC-004 fails | Defect BUG-412 | [@dev] | YYYY-MM-DD | Open |
| [GAP-nn] | [Type] | [Item] | [Finding] | [Action] | [@name] | YYYY-MM-DD | [Status] |

## 7. Change impact procedure

<!-- Guidance: Use the matrix to size a change before approving it. The output of this procedure goes to the change control board. -->

1. Identify the item to change (requirement, design element or component)
   and record the change request ID.
2. Trace **up** to find the stakeholder requirements and business needs
   affected; confirm with their owners that the change is acceptable.
3. Trace **down** to list every derived requirement, design element, code
   component and test that may change.
4. Estimate effort and risk for each affected item and record it in the
   change request.
5. After approval, update links in the same change that modifies the items;
   re-run the affected tests and record results.
6. Recalculate the coverage metrics in section 5 and note the change in the
   revision table.

| Change request | Item changed | Upstream affected | Downstream affected | Tests to re-run | Decision |
|---|---|---|---|---|---|
| *Example:* CR-031 | SYS-FR-020 (offline 12 h to 24 h) | STK-UR-010, BN-004 | SRS-FR-031, DES-SYNC, `services/sync` | TC-SYNC-001 to 006 | [Approved / Rejected] |
| [CR-nnn] | [ID] | [IDs] | [IDs] | [TC IDs] | [Decision] |

## 8. Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial matrix for baseline [n] |
| [x.y] | YYYY-MM-DD | [@name] | [Links added, gaps closed, metrics updated] |

## Standard and licence note

Structure aligned with ISO/IEC/IEEE 29148:2018, *Systems and software
engineering: Life cycle processes, Requirements engineering*, in its
treatment of bidirectional requirements traceability. This template is
original text written for this collection and reproduces no text from the
standard; obtain the standard for its normative requirements. Template
licence: MIT.