Requirements Traceability Matrix (RTM) Template

Forward and backward links from business need to tests and results, coverage metrics, orphan analysis, change impact

Exigences & AnalyseStandardISO/IEC/IEEE 29148:2018traceability matrix mathMis à jour 20 oct. 2026

Mode d'emploi: Use it from the first baseline onward to prove every need is built and tested and to size changes. Fix the ID conventions first. The main pitfall is filling the matrix only at the end, when links can no longer be reconstructed.

Aperçu

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.

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

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

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

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

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

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

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

Identify the item to change (requirement, design element or component) and record the change request ID.
Trace up to find the stakeholder requirements and business needs affected; confirm with their owners that the change is acceptable.
Trace down to list every derived requirement, design element, code component and test that may change.
Estimate effort and risk for each affected item and record it in the change request.
After approval, update links in the same change that modifies the items; re-run the affected tests and record results.
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.

Modèles associés

Exigences & Analyse