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.
SMAD Portal 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.