Requirements traceability
Requirements-trace evidence review for software assurance teams
This review checks that a software project's requirements, design, and verification hang together in both directions, with nothing derived or changed slipping out of the trace. It runs before a submittal, during a finding response, or after a change reshapes the requirement set, and it is done by or with the software assurance team that owns the traceability data. The work follows requirements down into design and verification and back up again, and it flags every derived requirement missing from the trace and every design or test element with no requirement above it. You receive a gap list, an evidence map exposing the broken links, and a closure sequence for software assurance leadership.
When this review is needed
- A traceability dataset is heading to the authority and the team wants the links checked in both directions first.
- A finding questions whether derived requirements are captured and justified in the trace.
- A change reshaped the requirement set and the trace has not caught up to the additions and deletions.
- Requirements, design, and verification were maintained in separate tools and the trace between them was never reconciled.
The problem
Traceability is generated continuously and reconciled rarely. High-level requirements decompose into low-level ones, which drive design, which drives verification, and every step is supposed to link both ways. But derived requirements appear in design without a parent above them, changed requirements orphan the design and tests below them, and links maintained by hand or across tools drift from the artifacts they claim to connect. The trace can look dense and still be missing the exact requirement a finding will ask about.
What gets reviewed
- High-level to low-level requirement decomposition checked for complete, bidirectional links
- Low-level requirements traced into design and into the verification that exercises them
- Derived requirements identified and checked for a justification and a place in the trace
- Design and verification elements checked upward for a requirement that calls for them
- Changed and deleted requirements checked so the design and tests below them were updated
- Trace references checked against the certification basis and the applicable software level
What gets validated
- Every high-level requirement decomposes to low-level requirements with links that resolve both ways
- Each low-level requirement reaches design and at least one verification activity
- Derived requirements carry a recorded justification and appear in the trace rather than only in design
- No design or verification element lacks a requirement above it that calls for it
- Changes to requirements are reflected in the design and tests the trace connects to them
Evidence normally required
- The requirements traceability data across high-level, low-level, design, and verification
- The requirement set at its current revision, including derived requirements
- The design and verification artifacts the trace connects to
- The change history covering added, changed, and deleted requirements
- The certification basis and applicable software level
Common discrepancies
- A derived requirement present in design with no parent and no recorded justification
- A low-level requirement that reaches design but has no verification exercising it
- A test or code element with no requirement above it, left over from a deleted requirement
- A changed requirement whose linked design and tests still reflect the prior wording
What is at stake
A broken trace undermines the argument that the software does what its requirements demand and nothing it was not asked to. A derived requirement with no parent and no justification is a classic finding, and an unlinked piece of code or test raises the question of what it is there for. Reconstructing trace late, after design and verification have moved on, is slow and error-prone precisely when the schedule has no slack.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Walk the trace down
Follow requirements through decomposition into design and verification, link by link.
Walk the trace up
Check design and verification elements upward for a requirement that calls for each one.
Test derived and changed items
Confirm derived requirements are justified and traced and that changes propagated below them.
List and order the gaps
Record each break with its direction and sequence upstream fixes before downstream relinking.
What the buyer receives
- A gap list naming each broken or missing link and the direction it fails in
- An evidence map showing the trace across requirements, design, and verification with the breaks marked
- A closure sequence ordered so upstream requirement fixes precede the design and test relinking below them
Who uses the output
- Software assurance leadership confirming the trace holds in both directions before submittal
- Assurance engineers repairing the links and justifying the derived requirements that are flagged
- Certification leadership judging whether the trace is complete or needs a reconciliation pass
How the work fits into the transaction or program
The review runs on the traceability data after requirements, design, and verification exist but before the trace is offered as proof they align. It confirms the links resolve both ways, and its gap list drives the relinking and justification work that lets the trace stand as evidence.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both expect bidirectional traceability consistent with DO-178C and, for hardware, DO-254, and both scrutinize derived requirements closely because they bypass the parent requirement above them. The review notes where a trace acceptable to one authority needs derived-requirement justifications strengthened to satisfy the other.
Regulatory limits
The review checks that the trace is complete and bidirectional. It does not accept the traceability data, make a compliance finding, or determine that the requirements themselves are correct. Those determinations rest with the applicant's authorized representatives and the authority.
What this review does not cover
- Authoring or correcting the requirements, design, or verification artifacts
- Justifying derived requirements on the applicant's behalf
- Accepting the trace or making any compliance finding
Specific to this review
- Derived requirements are the trace's weak point, because they enter at design level with no parent and are the item findings probe hardest.
- Deletion, not addition, leaves the quietest orphans: a removed requirement can leave live code and tests below it with nothing above them.
- A trace maintained across separate requirement, design, and verification tools drifts fastest at the tool boundaries, where the links are least automated.
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
Our trace tool reports full coverage. Why review it independently?
A tool reports the links it holds; it does not judge whether a derived requirement is justified, whether a change actually propagated, or whether an unlinked element should exist at all. The review reads those judgments the tool cannot make.
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.
Talk through the aircraft, records, evidence, deadline, and next useful step.