What is a requirements traceability matrix?

The table that ties each requirement to the requirement above it and to the verification that proves it: IDs, parent links, verification method, linked tests, results and dates.

What does an assessor sample in a requirements traceability matrix?

Verification coverage (a verification for every requirement, passing against the current version) and source coverage (a parent or need behind every requirement, a requirement behind every test), then broken or duplicate IDs, wording that cannot be verified, derived requirements not identified, user needs with no validation and, where the matrix carries them, hazard links.

Requirements traceability matrix

What a requirements traceability matrix is, and what an assessor samples

A requirements traceability matrix (RTM) is the table that ties each requirement to the requirement above it and to the verification that proves it. Aerospace and defence teams often call the verification half a verification cross reference matrix (VCRM); medical device teams keep a design traceability matrix in the design history file.

What it carries

At least a requirement ID and its parent. Usually the level, the verification method, the linked test or verification IDs, the latest result and its date, the date the requirement last changed, the safety rating (ASIL, DAL or software safety class), a derived flag and, for user needs, the validation record. The requirement text is useful and optional.

What an assessor samples

1 Requirement with no parent: an unexpected blank parent: a requirement below the top level of the paste, not flagged derived, whose parent cell is empty (a confirmed top-level requirement, a flagged derived one and a parent outside this export are their own states, never this finding)
2 No verification method or no linked verification: a requirement below the top level with a blank verification method, or with no linked test or verification ID in either paste; where every child is verified and passing, or an analysis, inspection, review or simulation carries a recorded justification, it is asked as a question for that justification, never counted as a break
3 Verification failed, blocked or not run: a linked verification whose latest result is failed, blocked, not run, inconclusive, deferred or passed with a deviation, or has no result row
4 Changed after its last passing verification: a requirement whose revision differs from the revision its latest pass was run against (when both are pasted), or else whose last-changed date is strictly later than the date of its latest passing verification
5 Test that traces to no requirement: a test or verification in the results that no requirement links and that names no requirement in the paste; where the results carry a test type, regression, exploratory, infrastructure, robustness, qualification and smoke tests are shown apart by type and never raise it
6 Derived requirement not identified as derived: with DO-178C ticked: a requirement below the top level with no parent and no derived flag
7 Parent outside this export, or an ID used twice: a parent ID that no requirement in the paste carries (outside this export, or not an ID at all: an export cannot tell the two apart), or one requirement ID on more than one row (never merged)
8 Wording that may not be verifiable: only when requirement text is pasted: a word or phrase from the published list (TBD, as appropriate, user-friendly, sufficient and the rest), word-bounded
9 Design validation not recorded: a user need or stakeholder requirement with a blank validation cell, where the paste has a validation column or ISO 13485 is ticked
10 Safety-rated requirement with no hazard or risk link: only when the paste carries a hazard, risk or safety goal column: a requirement with a safety rating above QM, DAL E or class A whose link cell is blank

Bidirectional traceability

The trace runs both ways. Verification coverage: every requirement has a verification that proves it. Source coverage: every requirement serves a parent requirement or a need, and every test verifies a requirement. A matrix that checks only verification coverage hides orphan requirements and tests that trace to nothing; this reads both at once, as a first-pass traceability integrity review, never a claim that the matrix is complete.

The standards that ask for it

Start from the requirements traceability matrix template, or paste the export your requirements tool produces as it is.

See the specimen run Trace your own export