A requirements traceability matrix (RTM) is a table or generated report that connects each requirement to its source, rationale, allocation, implementation, verification activity, result and objective evidence. It lets a reviewer follow the path from engineering intent to demonstrated compliance and back again, identify missing or suspect relationships, and check whether the evidence still applies to the requirement baseline and product configuration under review.
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.
For the wider process around definition, ownership, baselines and verification, read the requirements management guide for space teams. For the quality of the requirement statements themselves, use the 25 before-and-after spacecraft requirements examples.
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 RTM 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 the underlying discipline; the RTM is one way to present it. A complete trace should let a reviewer understand the requirement’s origin, relationships, applicable product configuration, verification method, activity and evidence without treating the exported matrix as a separate source of truth.
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 12U CubeSat backup-power function, but the same structure can apply to avionics, industrial equipment, medical devices, automotive systems and other complex hardware.
The CubeSat programme, identifiers, values, activities and results on this page are fictional. They demonstrate record structure and do not provide design values or evidence for a real mission.
| 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.
Reveal coverage and programme status
Traceability reveals requirements with no defined source or rationale, higher-level requirements that have not been allocated, and lower-level requirements with no clear contribution to an approved need. Requirements-to-test links also show which requirements have a selected method, a planned activity, a completed result or accepted evidence. Keeping those states separate gives review teams a more useful status picture than one generic “covered” label.
Control scope and assess change risk
Backward traces help distinguish justified work from items that have no approved origin. When a requirement changes, forward and horizontal links provide a starting point for identifying affected subsystem requirements, interfaces, verification activities, evidence, owners and open anomalies. The trace graph does not decide whether a change is safe, but it makes the scope of the engineering assessment more visible.
Investigate defects and support evidence reviews
When a test fails or an in-service problem appears, a backward trace can identify the requirements, interfaces, configurations and prior decisions associated with the result. The same connected record helps teams prepare for design, test-readiness, verification and acceptance reviews. In contract-driven work, it may also support compliance evidence, although the applicable contract, standards and programme procedures determine the required deliverables and acceptance process.
What makes requirements traceability difficult?
Most traceability problems come from maintaining relationships across changing engineering records, not from drawing the first matrix. Common challenges include:
- Scale and many-to-many relationships. A system requirement may allocate to several subsystems and use several verification activities, while one integrated test may support multiple requirements.
- Changing baselines and configurations. A valid link for one product version, model or test configuration may not support another.
- Fragmented tools. Requirements, interfaces, tests, evidence, risks and changes can live in separate systems with different identifiers and ownership.
- Manual-link errors. Copied IDs, stale spreadsheet references and unreviewed imports can leave links that appear complete but point to the wrong revision or item.
- Inconsistent relationship definitions. A generic “related to” link cannot reliably distinguish derivation, allocation, satisfaction, verification or evidence.
Teams reduce these risks by defining expected relationship types, ownership, applicable configurations and review triggers before measuring completeness. A high link count is not a substitute for meaningful, reviewed traces.
Which integrity checks should an RTM expose?
NASA requirements-management guidance describes checking source currency, maintaining bidirectional traceability and managing approved baseline changes; NASA configuration-management guidance describes keeping product information consistent with the controlled product. The checks below are Arc's practical synthesis rather than a prescribed agency checklist.
| Check | What it detects | Required disposition |
|---|---|---|
| Orphan requirement | No accepted source, parent or justified self-derived rationale | Connect the source, record and approve the derivation, or remove the unsupported requirement |
| Suspect link | A connected object's content, revision or applicability changed after the relationship was approved | Reassess the relationship and record whether it remains valid |
| Stale evidence | The requirement, procedure, tested item, configuration or approval basis no longer matches current closure | Reopen verification or justify continued applicability through review |
| Baseline mismatch | Rows combine requirements, design records or evidence from incompatible controlled states | Filter to one review baseline or make the cross-baseline exception explicit |
| Missing relationship type | A generic link does not say whether it represents rationale, allocation, satisfaction or verification | Assign a defined semantic type and responsible owner |
Forward, backward, horizontal and bidirectional traceability
Forward traceability follows a requirement towards lower-level requirements, implementation and verification. Backward traceability follows an implementation item, test or result to the requirement and source that justify it. Together, forward and backward navigation form the bidirectional concept illustrated in NASA's software-oriented traceability guidance. In this guide, horizontal traceability is a programme-defined working label for relationships among peer requirements, interfaces and same-level dependencies; organisations may use different terminology.
| 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? |
| Horizontal | Peer requirement ↔ interface ↔ peer requirement | Are same-level constraints and both sides of a boundary consistent? |
| Bidirectional | Both directions remain navigable | Are there missing requirements, unjustified work items or broken links in either direction? |
Use the measures as review prompts rather than universal pass thresholds. A programme can have complete-looking links and still contain weak requirements, inappropriate verification methods or evidence from the wrong configuration.
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.
Keep rationale, implementation, verification and validation links distinct
NASA's product-verification guidance separates conformance to specified requirements from validation against intended use. A trace should preserve that distinction rather than applying one generic evidence link to both questions.
| Relationship class | Claim made by the link | Review question |
|---|---|---|
| Rationale or source | The need, decision or analysis explains why the requirement exists | Is the source authoritative, current and applicable? |
| Decomposition or allocation | A lower-level obligation or product element carries part of the parent intent | Does the set completely and consistently address the parent? |
| Implementation or satisfaction | A design element is intended to realise the controlled requirement | Which configuration and design revision does the claim cover? |
| Verification | An activity and its evidence demonstrate conformance to the specified requirement | Do method, result, evidence and configuration support closure? |
| Validation | An activity or evidence addresses intended use and stakeholder expectations | Does the realised system solve the operational need in context? |
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.
| Question | Requirements traceability matrix (RTM) | Requirements verification matrix (RVM) |
|---|---|---|
| Primary purpose | Show the upstream and downstream relationships around each requirement. | Plan, execute and close the verification of each applicable requirement. |
| Typical scope | Needs, parents, children, architecture, interfaces, changes, risks, verification and evidence. | Requirement, method, level, stage, activity, configuration, result, evidence and closure. |
| Typical question | Why does this requirement exist, where is it allocated and what does a change affect? | How, where and when will this requirement be verified, and has the evidence been accepted? |
| Relationship | Can contain the complete verification record as part of a wider connected model. | Can be a filtered verification view generated from the same connected records. |
| Important caveat | Some programmes reverse these labels or use “verification control document” for related information. Define the terms and required fields in the programme plan rather than relying on the acronym alone. | |
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.
Verification method, level, stage and evidence are different fields
A verification record is most useful when it keeps four decisions separate. The method describes how compliance will be established. The level identifies the product or assembly at which the requirement is verified. The stage identifies when or on which model the activity occurs. The evidence is the controlled output that supports the result.
| Field | What it answers | Illustrative values | CubeSat example |
|---|---|---|---|
| Method | What technical approach will establish compliance? | Test, analysis, inspection, demonstration, review of design | Thermal-vacuum test supported by thermal analysis |
| Level | At what product level will verification occur? | Equipment, subsystem, spacecraft, segment or system | Integrated 12U spacecraft |
| Stage | When, and using which model or article? | Development, qualification, acceptance, on-orbit or recurring | Protoflight environmental campaign |
| Activity | Which controlled procedure, case or analysis performs the work? | Procedure ID, analysis task, inspection record | TVAC-PROC-012 Rev C |
| Evidence | Which result supports closure for the applicable configuration? | Report, dataset, certificate, image, record or reviewed calculation | TVAC-RPT-012 Rev A, runs 4–11 |
| Status | Where is the work in its agreed lifecycle? | Planned, ready, passed, failed, under review, accepted | Passed; evidence under review |
Do not infer the level or stage from the method. “Test” does not say whether a component qualification, spacecraft acceptance or on-orbit demonstration is intended. Likewise, a completed activity is not closed evidence until its result, anomalies, configuration and approval have been reviewed under the programme’s process.
Worked CubeSat traceability chain: backup power
Consider an illustrative 12U Earth-observation CubeSat and 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
15 representative CubeSat requirements in an RTM
The rows below show how a compact CubeSat traceability and verification view can span mission performance, power, communications, attitude control, payload, structures, thermal control, software and operations. They are illustrative teaching examples, not a flight-ready specification or a substitute for mission analysis, applicable launch requirements, licensing, standards or supplier data.
| ID | Representative requirement | Allocation | Method | Level / stage | Planned evidence |
|---|---|---|---|---|---|
| MIS-IMG-001 | The mission shall collect image data over each approved target within 24 hours of an uploaded imaging request during nominal operations. | Mission operations | Analysis and demonstration | System / operational validation | Operations-scenario report and end-to-end demonstration record |
| SYS-IMG-004 | The spacecraft shall achieve a ground sample distance of 5 m or better at a 500 km reference altitude under the defined imaging conditions. | Payload, ADCS and structure | Analysis and test | Spacecraft / qualification | Imaging performance budget and calibrated optical test report |
| PAY-OPT-012 | The payload modulation transfer function shall be at least 0.20 at the detector Nyquist frequency at the qualification hot and cold limits. | Payload | Test | Equipment / qualification | Optical performance report with temperature configuration |
| ADCS-POINT-007 | The ADCS shall maintain absolute pointing error below 0.10° (3σ) throughout each imaging interval lasting up to 45 seconds. | ADCS | Analysis and test | Subsystem and spacecraft / qualification | Monte Carlo analysis and hardware-in-the-loop test report |
| ADCS-RATE-011 | The spacecraft body rate shall be below 0.01°/s on each axis before payload exposure begins. | ADCS | Test | Spacecraft / protoflight | Closed-loop simulation and integrated functional-test data |
| EPS-ENE-003 | The electrical power subsystem shall maintain a predicted end-of-life energy margin of at least 20% for the reference worst-case orbit. | Electrical power | Analysis | Subsystem / design qualification | Reviewed power and energy balance for the controlled configuration |
| SYS-PWR-001 | The spacecraft shall maintain command and telemetry capability for at least 30 minutes following loss of primary power. | Electrical power and avionics | Test | Spacecraft / acceptance | Integrated backup-power test report and time-history dataset |
| COM-DL-006 | The downlink shall deliver at least 100 Mbit of payload data during a 10-minute pass at the reference link conditions defined in COM-ICD-002. | Communications and ground segment | Analysis and test | Segment / end-to-end | Link budget, RF test report and ground-station compatibility record |
| COM-CMD-009 | The command receiver shall reject any command frame that fails authentication or integrity checking and shall record the rejection event. | Communications and flight software | Test | Spacecraft / qualification | Negative test results and security event log |
| FSW-BOOT-002 | Following a processor reset, flight software shall enter a commandable safe mode within 60 seconds. | Flight software and avionics | Test | Avionics / qualification and acceptance | Fault-injection procedure, execution log and reviewed result |
| THM-TEMP-015 | Battery cell temperature shall remain between 0°C and 35°C during all analysed mission modes. | Thermal and electrical power | Analysis and test | Spacecraft / protoflight | Correlated thermal model and thermal-vacuum dataset |
| STR-MASS-001 | The integrated spacecraft launch mass shall not exceed 24.0 kg in its as-flown configuration. | Spacecraft structure and all subsystems | Inspection | Spacecraft / acceptance | Calibrated mass-properties record and as-built configuration |
| STR-FREQ-004 | The spacecraft first lateral natural frequency shall be at least 100 Hz in the launch configuration. | Structure | Analysis and test | Spacecraft / qualification | Finite-element correlation report and modal-survey results |
| ENV-VIB-008 | The spacecraft shall retain all specified functions after exposure to the applicable qualification vibration environment. | Integrated spacecraft | Test | Spacecraft / qualification | Vibration report, pre/post functional results and anomaly dispositions |
| OPS-PASS-005 | The ground segment shall produce an operator alert within 2 minutes when expected telemetry is not received during a scheduled contact. | Ground software and operations | Demonstration and test | Ground segment / operational validation | Scenario execution record, alert timestamp and operator acceptance |
These rows are deliberately compact. In a controlled workspace, each would also link to its source, rationale, owner, lower-level requirements, interface definition, applicable configuration, changes and anomalies. The companion SRR, PDR and CDR requirements-readiness checklist explains which parts of that record should be mature at each review.
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.
When evaluating dedicated requirements management software, test whether it stores requirements, tests and evidence as linked records rather than repeated cell values, and whether it provides the relationship views, version history, controlled reviews, audit trails, coverage reports and change-impact analysis the programme needs. Do not infer those capabilities from the category label alone. Where supported, the matrix can become 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.
Private worked example in Arc
Get a free Arc account with the worked CubeSat verification example
Download the spreadsheet for immediate use, or request a private Arc account containing the same example as connected requirements, verification activities and evidence. Luc will provision a customer-scoped workspace under Arc's documented tenant-isolation and role controls and send you a secure invitation without shared credentials. If you already use Arc, the example can be added as a private programme in your existing organisation.
How Arc approaches requirements traceability
Arc's traceability and impact-analysis capability 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. Arc's verification capability reference defines the connected method, case, execution, result and evidence records and leaves acceptance criteria and evidence sufficiency to the customer's programme.
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.
The illustrative CubeSat programme specified for this account request includes requirements, sources, allocations, verification methods, test cases, evidence placeholders, results, status and one controlled change-impact scenario. The engineering change-impact analysis guide explains how to assess that scenario without treating trace-graph output as an engineering decision.
For the adjacent controls, read as-designed, as-built and as-tested configuration management, distinguish the evidence questions in verification vs validation for space systems, and connect an approved change to implementation and release through ECR vs ECO vs ECN.
Common RTM mistakes
- Treating the matrix as a copied status report. Repeated requirement text and manually entered pass labels drift away from the controlled source and evidence.
- Linking only requirements to tests. Without sources, allocations, configurations and evidence, the matrix cannot explain why the test exists or what a change affects.
- Using one generic “covered” status. A selected method, drafted procedure, completed activity and accepted result are materially different states.
- Confusing verification method with activity. “Test” is a method; TVAC-PROC-012 Rev C is a controlled activity that applies the method.
- Leaving the verification level and stage implicit. The same requirement may need equipment qualification, spacecraft acceptance and operational validation evidence.
- Closing a requirement without objective evidence. A pass label should lead to the applicable report, result, dataset and configuration.
- Repairing traceability just before a review. Links should be updated and reviewed as part of change control, while the engineering context is still available.
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 requirements traceability?
Requirements traceability is the controlled ability to follow a requirement to its origin, allocations, implementation, verification activities and evidence, and to navigate back from those downstream records to the requirement.
What are the five types of requirements traceability?
Common views are forward, backward, bidirectional, vertical and horizontal traceability. They describe different directions through the same controlled engineering relationships rather than five separate records.
How is requirements traceability health measured?
Useful measures include source coverage, allocation coverage, verification coverage, orphan count, suspect-link count and accepted-evidence coverage. Programmes should define each measure and its review threshold for their own lifecycle.
What is a requirements traceability matrix?
A requirements traceability matrix is a table or generated report that connects requirements to their sources, allocations, verification activities, results and objective evidence.
What is the difference between an RTM and a requirements verification matrix?
An RTM usually covers broader upstream and downstream traceability. A requirements verification matrix concentrates on verification methods, levels, activities, results, evidence and closure, although programme terminology varies.
What should be included in a requirements traceability matrix?
A useful RTM normally includes a stable requirement ID, controlled text, source or parent, allocation, owner, verification method, verification activity, evidence reference, applicable configuration and separate requirement and verification statuses.
Can a requirements traceability matrix be created in Excel?
Yes. A spreadsheet can suit a small, relatively stable requirement set with simple relationships and clear ownership. Linked requirements software becomes more useful as changes, configurations, contributors and many-to-many evidence relationships grow.
Does NASA or ECSS require one universal RTM format?
No. NASA and ECSS publish requirements-management and verification guidance, but there is no single matrix layout that automatically applies to every programme. The governing contract, applicable standards, tailoring, verification plan and programme procedures determine the required traceability, fields and deliverables.
Apply this to a space bid
For a funded hardware project, use this engineering method to build a bid maturity-evidence ledger. Keep proposed commitments, current evidence and unresolved customer decisions distinct.
Evaluate Arc
Try Arc on a representative engineering workflow
Start with one requirement set and test traceability, change control, review and verification in a private Arc workspace.