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."
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.
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.
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.
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.
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.
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.
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.