Requirements traceability matrix

How it works

A traceability matrix shows that every requirement comes from somewhere, is implemented somewhere and is proved by something. Each row here is a requirement with its parent, the design elements that implement it, how it is verified, the tests, and the latest result. The tool checks the links in both directions and lists what is missing, so gaps are found before a review finds them for you.

1. Write each requirement as a row. Give every requirement a unique id and one of six types: stakeholder need, system, hardware, software, safety or test. A good requirement is necessary, singular and verifiable; the guide to writing requirements lists the rules. The parent is the requirement it derives from, and a row may name several parents.
2. Backward checks. Each parent id must exist in the matrix. Each type you mark as needing a parent must have one. The parent links must not loop, and no id may be used twice. A test used by several requirements is listed so you can confirm it really covers all of them.
3. Forward coverage. Four coverage figures follow a requirement down: the share that name a design element (system, hardware, software and safety requirements), the share with a verification method, the share with a test, and the share whose result is pass with a test named. Stakeholder needs are left out of the last three because they are met through the requirements derived from them. A stakeholder need is covered when at least one requirement names it as its parent.coverage = rows with the link / rows that should have it x 100
4. Closure. A requirement is closed when it has a verification method, a named test if the method is test, a design element if the type needs one, and no failing result. If you require a pass, the result must also be pass. A stakeholder need is closed when it has a child. Closure is reported by type and by safety integrity as a bar chart.closed share = closed rows / rows in the group x 100
5. Safety integrity along the chain. Safety requirements inherit the integrity of the requirement they derive from, so the tool flags a child whose level (QM, A, B, C or D) is below its parent's. A lower level is allowed only with a recorded decomposition, so check it. A requirement at C or D that is verified by review alone is also flagged.
6. The gap list. Every failed check becomes a line in the gap list with the requirement id, the kind of gap and what to do, ready to export as CSV for a review.

Sources

The methods and default figures rest on these public sources. The wording here is our own; read the source for its full text.

• ISO/IEC/IEEE 29148:2018, Systems and software engineering, Life cycle processes, Requirements engineering, International Organization for Standardization, 2018. Cited by name; the characteristics of good requirements and the idea of tracing each one to its source and to its verification.
• Guide to Writing Requirements, version 4 (INCOSE-TP-2010-006-04) (opens in a new tab), International Council on Systems Engineering (INCOSE), Requirements Working Group, July 2023. The rules for well-formed requirements. The link is the working group's published draft; the released document is dated July 2023.
• ISO 26262-8:2018, Road vehicles, Functional safety, Part 8: Supporting processes (clause 6, specification and management of safety requirements), International Organization for Standardization, 2018. Cited by name, part and clause: safety requirements are traceable to their source and carry their integrity level; the method is written in our own words.
• DO-178C, Software Considerations in Airborne Systems and Equipment Certification, RTCA, 2011. Cited by name for the practice of tracing requirements both ways between system, high-level, low-level requirements, code and tests.