A requirements traceability matrix is a structured record that connects each requirement to the engineering artifacts that explain, implement and verify it. Those artifacts may include parent and lower-level requirements, system elements, interfaces, verification methods, test cases, results, evidence and anomalies. Engineering teams use the matrix to show that requirements are accounted for, changes are understood and verification is supported by objective evidence.
The word matrix often suggests a spreadsheet, but the underlying concept is a set of traceable relationships. A small programme may maintain those relationships in Excel. A larger programme may generate an RTM from linked objects in requirements management software. In either case, the matrix should help an engineer move from intent to implementation and evidence without reconstructing the history from separate documents.
What is a requirements traceability matrix?
A requirements traceability matrix, commonly abbreviated to RTM, is a table or report that maps requirements to related upstream and downstream engineering information. It provides a visible path between why a requirement exists, where it is allocated, how it will be verified and what evidence demonstrates the result.
The exact contents depend on the organisation and lifecycle. A basic requirement traceability matrix may connect requirement IDs to test cases and status. A systems-engineering RTM may also trace stakeholder needs to system requirements, system requirements to subsystem requirements, requirements to architecture elements, and verification activities to results and issues.
Requirements traceability is therefore broader than recording that a test passed. A complete trace should let a reviewer understand the requirement’s origin, its relationships, the applicable product configuration, the verification method, the activity performed and the evidence used to close it.
What does an RTM look like?
An RTM usually presents one requirement per row, with columns for identifiers, relationships, allocation, verification and status. The example below uses a simplified spacecraft backup-power function, but the same structure can apply to avionics, industrial equipment, medical devices, automotive systems and other complex hardware.
| Requirement ID | Requirement | Parent | System / subsystem | Verification method | Activity | Evidence | Status |
|---|---|---|---|---|---|---|---|
| SYS-PWR-001 | The spacecraft shall maintain command and telemetry capability for at least 30 minutes following loss of primary power. | MISSION-AVAIL-004 | Spacecraft system | Test | SYS-TEST-042 | SYS-TEST-042-RPT Rev A, §6.2 | Verified |
| EPS-PWR-014 | The backup power assembly shall supply the essential avionics bus with at least 120 W for 30 minutes after loss of primary power. | SYS-PWR-001 | Electrical power subsystem | Test | EPS-QUAL-014 | EPS-QUAL-014-RPT Rev B, Table 5 | Verified |
| AV-LOAD-009 | Essential avionics equipment shall consume no more than 120 W in backup-power mode. | SYS-PWR-001 | Avionics subsystem | Analysis and test | AV-PWR-TEST-009 | AV-PWR-TEST-009-RPT Rev A; AV-LB-07 | Verified |
This is deliberately compact. A real programme may need separate columns for requirement version, owner, rationale, verification level, procedure revision, test configuration, result, anomaly disposition and approval. The useful fields are the ones that answer real engineering and review questions.
Why use a requirements traceability matrix?
The practical purpose of an RTM is to expose gaps and preserve engineering context across the product lifecycle. It helps teams answer whether every approved requirement has been allocated, implemented and verified, and whether every design or test activity has a justified origin.
Account for every requirement
Traceability reveals orphan requirements with no parent or source, and lower-level requirements with no clear contribution to a system need. It also reveals parent requirements that have not been decomposed or allocated far enough for a team to implement them.
Prove verification coverage
Requirements-to-test traceability shows which requirements have a planned verification activity and which do not. During verification, the matrix can distinguish between a method that has been selected, a procedure that exists, an activity that has run and evidence that has been reviewed. Calling all four states “covered” can hide significant programme risk.
Support engineering changes
When a requirement changes, its trace links provide a starting point for impact analysis. Engineers can identify affected subsystem requirements, interfaces, verification activities, evidence and open anomalies. The RTM does not make the change decision, but it reduces the chance that a downstream consequence is missed.
Prepare for technical reviews and audits
A current traceability record helps teams prepare for design, test readiness, verification and acceptance reviews. Reviewers can inspect gaps and evidence directly instead of relying on a manually assembled status presentation. In regulated or contract-driven work, the matrix may also support compliance evidence, although the applicable contract, standard and organisational process determine what is formally required.
Forward, backward and bidirectional traceability
Forward traceability follows a requirement towards implementation and verification. Backward traceability follows an implementation item, test or result back to its originating requirement. Bidirectional requirements traceability maintains both paths.
| Direction | Path | Question it answers |
|---|---|---|
| Forward | Requirement → subsystem → test → evidence | Has this requirement been allocated and verified? |
| Backward | Evidence → test → subsystem → requirement | Why was this activity performed, and what does the result support? |
| Bidirectional | Both directions remain navigable | Are there missing requirements, unjustified work items or broken links in either direction? |
For the backup-power example, forward traceability starts at SYS-PWR-001 and leads to the electrical power allocation, the integrated test and its report. Backward traceability starts at the report and shows which test produced it and which system requirement it verifies. Maintaining both directions makes it easier to detect an unverified requirement or a test with no defined purpose.
NASA’s software engineering guidance on bidirectional traceability is a useful software-oriented example of tracing requirements forward to design and tests and backward to their source. Hardware and systems programmes should apply the trace relationships defined by their own lifecycle and governing process.
Requirements traceability matrix vs requirements verification matrix
A requirements traceability matrix is generally broader than a requirements verification matrix, but organisations do not use the terms consistently. The governing programme documents should define the intended meaning.
An RTM may connect needs, requirements, architecture, design elements, interfaces, verification activities, evidence, changes and issues. A requirements verification matrix usually concentrates on how each requirement will be or has been verified. Typical verification-matrix fields include the requirement ID, verification method, verification level, activity or procedure, result, evidence reference and closure status.
The two can overlap completely when an organisation uses its RTM primarily for verification. Another organisation may maintain a broad traceability model and generate a narrower verification matrix for a specific review or delivery. Appendix D of the NASA Systems Engineering Handbook provides one requirements verification matrix example and suggested fields, but neither that layout nor the naming convention is universal.
How to create a requirements traceability matrix
- Establish stable requirement IDs. Give each controlled requirement an identifier that remains usable as the text and status evolve. Avoid using row numbers that change whenever a spreadsheet is sorted.
- Define the traceability purpose. Decide which questions the matrix must answer, such as decomposition completeness, interface allocation, verification coverage, compliance or change impact.
- Choose the relationship types. Define the meaning of links such as derives from, satisfies, allocated to and verified by. A link should communicate more than simple association.
- Connect higher- and lower-level requirements. Trace system requirements to their sources and to the subsystem or component requirements that implement them. Record derived requirements with their rationale.
- Allocate requirements to the product architecture. Identify the system, subsystem, component or interface responsible for satisfying each requirement.
- Define verification methods. Select an appropriate method such as test, analysis, inspection or demonstration. Some requirements need a combination.
- Link verification activities. Reference the controlled test, analysis, inspection or demonstration that will produce the result. Keep the method distinct from the specific activity.
- Connect results and evidence. Link the executed activity to its report, dataset, record or other objective evidence. Record relevant configuration and procedure revisions where needed.
- Track status and issues. Show whether the requirement and verification activity are draft, approved, planned, in progress, blocked, failed or closed according to the programme’s own lifecycle.
- Review gaps and maintain the links. Check for missing parents, allocations, activities and evidence. Update affected relationships as part of change control rather than repairing the matrix just before a review.
Common requirements traceability matrix fields
A useful requirements traceability matrix template starts with a small set of controlled fields and adds detail only where it supports a decision, review or evidence need.
At minimum, a useful RTM records a stable requirement ID, requirement text, source or parent, allocation, verification method, verification activity, evidence reference and status.
| Field | What it contains | Typical use |
|---|---|---|
| Requirement ID | Stable unique identifier | Basic |
| Requirement | Controlled requirement statement | Basic |
| Parent or source | Higher-level requirement, stakeholder need, contract or other origin | Basic traceability |
| Rationale | Reason the requirement exists or was derived | Useful for change decisions |
| System / subsystem | Architecture element to which the requirement is allocated | Hardware and systems engineering |
| Owner | Person or team responsible for maintaining or closing the item | Useful for coordination |
| Verification method | Test, analysis, inspection, demonstration or a defined combination | Verification planning |
| Verification activity | Procedure, test case, analysis or inspection identifier | Requirements-to-test traceability |
| Evidence / result | Report, dataset, certificate, record or other objective evidence | Verification closure |
| Status | Separate requirement and verification lifecycle states | Reviews and reporting |
| Issue / anomaly | Related failure, non-conformance or open action | Failure disposition |
| Version / configuration | Applicable requirement baseline, product configuration and procedure revision | Configuration-sensitive programmes |
Avoid combining requirement approval and verification closure in one status field. An approved requirement can still be unverified, and a completed test may need review before it becomes accepted evidence.
Requirements traceability matrix example: backup power
Consider the system requirement SYS-PWR-001: the spacecraft must maintain command and telemetry for at least 30 minutes after losing primary power. The requirement traces upward to a mission availability objective, which explains why the capability matters.
The systems team allocates the capability across two areas. EPS-PWR-014 requires the backup power assembly to supply at least 120 W for 30 minutes. AV-LOAD-009 constrains essential avionics consumption to no more than 120 W in backup mode. Neither lower-level requirement is sufficient alone; together they support the system outcome.
The planned method is test, supported by load analysis. The power assembly is tested with EPS-QUAL-014, while avionics consumption is measured with AV-PWR-TEST-009. An initial avionics run exceeds the limit and creates ANOM-118. After the cause is corrected, a controlled retest passes. The final evidence references the applicable test reports and load budget rather than recording only “pass”.
An integrated system test then demonstrates 34 minutes of command and telemetry operation after simulated primary-power loss. That result closes the system-level requirement for the tested configuration. If the avionics load or battery design later changes, the trace identifies the analyses, tests and evidence that may need reassessment.
Backup-power system requirement
Power supply
Avionics load
Reviewed verification evidence
Excel vs requirements traceability software
Excel can be effective requirements traceability matrix software for a small team when the requirements set is limited, relationships are simple, changes are infrequent and one person can maintain the controlled file. A spreadsheet is familiar, easy to tailor and suitable for a focused review or early programme.
The difficulty grows with many-to-many relationships. One requirement may trace to several subsystem requirements and tests; one test may verify several requirements. Teams then duplicate identifiers across cells, add more tabs and rely on manual checks. Frequent changes, parallel editing, multiple configurations, large evidence sets and formal review history make the workbook harder to trust.
Dedicated requirements management software typically stores requirements, tests and evidence as linked records rather than repeated cell values. It can provide relationship views, version history, controlled reviews, audit trails, coverage reports and change-impact analysis. The matrix becomes a generated view of current links rather than a separate document that must be reconciled.
The decision is not simply spreadsheet bad, software good. Choose the lightest approach that preserves reliable traceability for the programme’s size, rate of change, configuration complexity and assurance obligations. A well-owned spreadsheet is better than an elaborate system nobody keeps current. Teams that prefer to own their tooling can compare six open-source requirements management tools and their different traceability models.
Free XLSX template
Get the requirements traceability matrix template
Enter your email and we’ll send you the editable three-sheet RTM template, including instructions and a worked spacecraft example.
How Arc approaches requirements traceability
Arc treats traceability as relationships between engineering objects rather than as a manually maintained reporting spreadsheet. Requirements, architecture, engineering changes, verification activities and evidence can remain connected as the product develops.
When something changes, engineers can inspect affected relationships and downstream impact instead of reconstructing them from separate files. The RTM can then be understood as a view of the connected engineering record, while engineers continue to own the technical decisions, reviews and evidence.
Requirements traceability best practices
- Use stable unique IDs. Identifiers should survive sorting, wording changes and exports.
- Define relationship meanings. Distinguish derivation, allocation, satisfaction and verification instead of using an ambiguous generic link.
- Trace meaningful relationships. More links do not automatically create better understanding. Maintain the paths needed for engineering decisions and evidence.
- Assign ownership. Make responsibility for requirements, verification activities and closure visible.
- Plan verification early. Choosing a method while developing the requirement helps expose language that cannot be objectively verified.
- Connect evidence, not only status. A pass label is not a substitute for the applicable result, report, dataset and configuration.
- Maintain traceability during change. Updating links should be part of the engineering workflow, not a documentation exercise deferred until a gate.
- Review gaps before reviews. Regularly check for orphan requirements, missing tests, unresolved failures and evidence that has not been approved.
Frequently asked questions
What is a requirements traceability matrix?
A requirements traceability matrix is a table or report that connects requirements to related artifacts such as parent requirements, system elements, verification activities, test results and evidence.
What does RTM stand for?
RTM stands for requirements traceability matrix. Some teams use the singular phrase requirement traceability matrix for the same concept.
What is the purpose of an RTM?
The purpose of an RTM is to demonstrate requirements coverage, identify missing or unjustified links, support change-impact analysis and provide a navigable path from engineering intent to verification evidence.
What should be included in a requirements traceability matrix?
Most RTMs include a requirement ID and statement, source or parent, allocation, verification method, verification activity, evidence reference and status. Ownership, rationale, configuration and issue links are useful when the process requires them.
Who creates a requirements traceability matrix?
Responsibility varies. Systems or requirements engineers often establish the structure, while design, test and V&V engineers maintain the allocations, activities, results and evidence they own.
Is a traceability matrix required?
Not universally. A contract, standard, regulator, customer or organisational process may require defined traceability or a particular deliverable. Teams should follow the obligations that apply to their product and programme.
What is bidirectional requirements traceability?
Bidirectional traceability means links can be followed both from a requirement to its implementation and verification artifacts and from those artifacts back to the originating requirement.
Can you create an RTM in Excel?
Yes. Excel works well for smaller, relatively stable requirements sets with straightforward relationships and clear ownership. It becomes difficult when links, changes, configurations, evidence and concurrent contributors multiply.
What is the difference between an RTM and a requirements verification matrix?
An RTM is generally broader and may cover the full chain from source to design and evidence. A requirements verification matrix usually focuses on verification methods, activities, results and closure. Organisations may use the terms differently.