A requirements traceability matrix (RTM) is a table that maps every requirement to its parent, its children, its verification method (test, analysis, inspection, or demonstration), and its status. To build one: define a four-to-five-level hierarchy, tag every requirement with a verification method, enforce zero orphans and zero gaps, and flag downstream links suspect whenever a parent changes.
Prefer watching? Build a Requirements Traceability Matrix — self-hosted, no tracking.
Transcript
An RTM is only as good as the hierarchy underneath it. Each requirement carries its number, its parent, and a verification method — test, analysis, inspection, or demonstration. Get those three attributes right and the matrix builds itself.
This is that matrix: every requirement crossed against the four verification methods, with stakeholder needs, requirement counts, and verification results summarised across the top.
The rollup column gives each row a single colour — red, yellow, green, or not traced. That is the number a review board looks at first, and it is computed, not typed.
Coverage analysis asks four questions. Upstream: does every requirement know why it exists? Downstream: did the high-level requirements actually get decomposed? Method: can every leaf be verified? And stakeholder tracing closes the loop back to the mission need.
Instead of auditing for gaps the week before a review, the gaps are a standing list. An orphaned requirement means something the system must do has no stated reason. A requirement with no method means there is no plan to prove it.
The failure mode of every spreadsheet RTM is staleness: a requirement changes and the matrix keeps smiling. Here, when something a link depends on changes, that link is flagged suspect. In this programme a test passed against an imager requirement, and then the parent tightened the ground sample distance from three metres to two and a half.
Each flag is a decision, not a notification. Confirm the downstream item still holds and clear it, or dig in with the built-in five-whys root cause panel. A clean matrix is one where this page is empty.
For the programme view, the same data rolls into one score with a letter grade, broken down by test coverage, verification, risk coverage, and parent tracing. Snapshots give you the trend — whether coverage is improving or decaying between reviews.
What is a requirements traceability matrix?
A Requirements Traceability Matrix (RTM) is a table that maps every requirement in your project to its origin, its children, its verification method, and its current status. It is the backbone of configuration management for any space program. Without it, you cannot answer basic questions: "Does every mission objective have a verifiable requirement?" or "What downstream requirements are affected if we change this pointing spec?"
The simplest RTM is a spreadsheet with columns for requirement ID, parent ID, text, verification method (test, analysis, inspection, demonstration), responsible engineer, and status. For 30 requirements, this works. For 300, it starts breaking. For 3,000, it is unmaintainable without tooling.
The key insight is that an RTM is not a document. It is a directed acyclic graph. Mission objectives flow down to system requirements, which flow to subsystem requirements, which flow to component specifications. Each level adds specificity. Each link carries meaning: "this lower-level requirement exists because of that higher-level requirement."
Why do suspect links matter?
When you change a requirement at any level, the RTM tells you what is affected downstream. This is suspect link detection — the ability to flag every connected requirement as "needs review" when its parent changes. Without suspect links, requirement changes propagate by email, meeting minutes, and institutional memory. Things get missed.
Building an effective RTM requires three things: a clear hierarchy (L0 mission objectives through L3+ component specs), a verification method for every leaf requirement, and automated suspect link detection. If any of these are missing, your RTM is a checkbox exercise rather than a working tool.
How do you structure the requirement hierarchy?
Step one: define the hierarchy. Most space programs use four to five levels. L0 is the mission objectives (the why). L1 is the system requirements (the what). L2 is the subsystem requirements (the how). L3 is the assembly or component specifications (the build). Some programs add L4 for piece-part specs. The exact number does not matter. Consistency does. If one subsystem uses three levels and another uses five, traceability rollups become inconsistent and coverage analysis breaks.
| Level | Scope | What it captures |
|---|---|---|
| L0 | Mission objectives | The why — what the mission must accomplish |
| L1 | System requirements | The what — measurable system-level behavior |
| L2 | Subsystem requirements | The how — allocation to each subsystem |
| L3 | Assembly / component specs | The build — hardware-level specification |
| L4 (optional) | Piece-part specs | Extra detail some programs add below L3 |
Which verification method does each requirement need?
Step two: tag every requirement with a verification method. The four standard methods are Test (T), Analysis (A), Inspection (I), and Demonstration (D). Test means physically exercising the hardware and measuring performance. Analysis means computing whether the design meets the requirement based on physics or simulation. Inspection means visual or measurement-based confirmation against drawings. Demonstration means observing the system perform the function in a representative environment. Mixing methods is fine: one requirement can be verified by both analysis and test.
| Method | How it verifies |
|---|---|
| Test (T) | Physically exercising the hardware and measuring performance |
| Analysis (A) | Computing whether the design meets the requirement from physics or simulation |
| Inspection (I) | Visual or measurement-based confirmation against drawings |
| Demonstration (D) | Observing the system perform the function in a representative environment |
How do you enforce coverage and change control?
Step three: enforce coverage. A healthy RTM has zero orphans (requirements with no parent and no verification method) and zero gaps (mission objectives that no lower-level requirement traces to). The numbers should be visible on a dashboard, not buried in an audit report. Every program review should start by looking at the coverage chart.
Step four: establish a change-control discipline. When a requirement at any level changes, every downstream link should automatically be flagged suspect. The owner of each downstream requirement reviews the change, decides whether their requirement is still valid, and either confirms or updates it. This is how you keep a 9,000-requirement program in sync without losing your weekends to reconciliation.
How should the RTM connect to budgets and risk?
Step five: integrate the RTM with the rest of your engineering data. A requirement is not just text. It allocates mass, power, data rate, link margin, and risk. When the RTM lives next to the budgets and risk register, you can answer questions like "what happens to mass margin if we tighten this pointing requirement?" in seconds. When the RTM is isolated in DOORS while budgets live in Excel, those questions take days.
What are the most common RTM pitfalls?
Common pitfalls to avoid: requirements that combine two or more shall statements ("the system shall do X and Y"), requirements without measurable verification criteria ("the system shall be reliable"), and requirements that describe implementation rather than need ("the system shall use a 12-volt bus"). Each of these makes the RTM less useful and verification harder. Split combined requirements. Quantify subjective requirements. Move implementation choices to design documents.
How Hitt Hosting SE generates the RTM
Hitt Hosting SE generates the RTM as a live artifact from your requirement tree. Coverage gaps, orphan requirements, and suspect links are visible in real time. The matrix updates automatically when requirements change — no manual reconciliation needed. Import your existing requirements from CSV or ReqIF, and the platform builds the trace graph in seconds. Every phase gate review starts with a coverage chart that the review board can see and trust.