Requirements traceability
Requirements-traceability review for certification evidence
A requirements-traceability review checks whether the trace from system requirements down through software and hardware requirements is bidirectional and complete: every parent decomposes into children, every child traces back to a parent or is declared derived, and nothing is orphaned. It is for avionics and equipment suppliers whose certification data spans ARP4754B, DO-178C, and DO-254. The review reads the requirement sets at each level and the trace links between them, then checks the chain for breaks, dangling links, and unparented requirements. You receive a trace integrity status and a list of orphaned, dangling, and undeclared-derived requirements.
When this review is needed
- A program spans system, software, and hardware levels and the trace between them needs an independent read.
- Requirements changed and the trace links have to be re-checked for breaks the change introduced.
- A stage-of-involvement review is approaching and the trace has to be defensible end to end.
- Lifecycle reviews flag requirements that decompose into children with no parent.
The problem
Traceability is maintained in matrices and tools that drift the moment requirements move. A parent requirement is split and one child is forgotten, a requirement is deleted but its trace links linger, and a new requirement appears with no parent and no derived declaration. The trace reads as complete because the links exist, while the links point at requirements that changed, moved, or are gone.
What gets reviewed
- The requirement sets at the system, software, and hardware levels
- The downward trace from parents to their decomposed children
- The upward trace from children back to a parent or a derived declaration
- Derived requirements and whether each is declared and routed for assessment
- Trace links that point at requirements that have changed or been removed
- The consistency of the trace across the tools and matrices that hold it
What gets validated
- Every parent requirement decomposes into at least one child or is implemented directly
- Every child traces up to a parent or is declared a derived requirement
- No trace link points at a requirement that has been deleted or renumbered
- Derived requirements are declared and routed to the safety assessment
- The trace is consistent across the matrices and tools that maintain it
- Requirement changes are reflected on both ends of the affected trace links
- There are no requirements that exist outside the trace entirely
Evidence normally required
- The system, software, and hardware requirement sets
- The trace matrices or the tool export of the trace links
- The derived requirement records and declarations
- The change history affecting requirements and their links
- Any prior trace findings the program is carrying
Common discrepancies
- A parent split into children with one branch never created
- Trace links pointing at requirements that were deleted or renumbered
- A child requirement with no parent and no derived declaration
- Derived requirements present in the trace but not routed for assessment
- A trace that agrees in one tool and disagrees in the matrix exported from it
- A requirement that exists in a set but never appears in the trace at all
What is at stake
A broken trace surfaces as a finding that the package cannot answer, because the missing link is a hole in the decomposition rather than a wording issue. An undeclared-derived requirement leaves the safety assessment blind to it. Each dangling link a reviewer finds invites a wider look, and the trace has to be rebuilt while the program waits.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Gather the trace
Collect the requirement sets and the trace links from the matrices and tools that hold them.
Walk both directions
Follow the trace down from parents to children and up from children to parents or derived declarations.
Find the breaks
Identify orphaned, dangling, and undeclared-derived requirements and reconcile tool against matrix.
Report the gaps
Produce a trace integrity status and a closure list ordered by review and safety exposure.
What the buyer receives
- A trace integrity status across the system, software, and hardware levels
- A list of orphaned, dangling, and undeclared-derived requirements
- A decomposition view showing parents with missing children
- A prioritized closure list ordered by review and safety exposure
Who uses the output
- Certification leads making the trace defensible before submittal
- Requirements engineering teams repairing broken and dangling links
- Safety and certification teams confirming derived requirements are routed
How the work fits into the transaction or program
The review checks the trace that systems-development, software, and hardware reviews each rely on within their level, and it joins those levels into one chain. It pairs with a verification-traceability review that follows the trace forward from requirements into evidence.
Start with a single asset
Confirm requirements trace through verification.
Regulatory limits
Endeavor Elements reviews the applicant's requirement trace for integrity and completeness. It does not make compliance findings, approve the requirement set, or guarantee acceptance of the data the trace supports.
What this review does not cover
- Making compliance findings or issuing any approval
- Authoring the missing requirements or derived declarations
- Re-baselining the requirement set in place of the applicant
Specific to this review
- Traceability is bidirectional, and a trace can be complete downward while broken upward, so the two directions are checked separately rather than treated as one link.
- A requirement with no parent is acceptable only when declared derived, so the difference between a derived requirement and an orphan is a declaration, and the review tests for that declaration.
- Trace links survive the requirements they point at, so a deleted or renumbered requirement leaves a dangling link the matrix still counts as connected.
- The same trace can disagree between a tool and its exported matrix, so the review reconciles the representations rather than trusting either alone.
Sources
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
Frequently asked questions
How is this different from a verification-traceability review?
This review checks the trace among requirements, parent to child and back. A verification-traceability review follows requirements forward into the test, analysis, and review evidence that verifies them.
Can you reconcile a trace held across more than one tool?
Yes. A common engagement is reconciling the trace as it appears in different tools and exported matrices, then reporting where the representations disagree so a single defensible trace can be established.
Relevant glossary terms
Related pages
Where this fits
Talk to an engineer who has done this work
We will walk through your current state, the records or evidence involved, and a scoped first engagement.
Walk through your situation with an engineer who has done this work.