Certification evidence
Requirements trace evidence review for avionics suppliers
A requirements trace evidence review checks that the thread running from a requirement through the design to its verification is unbroken and complete. It is for an avionics supplier heading into submittal, a finding response, or a design change who needs the trace to hold up under DO-178C and DO-254 scrutiny. The review reads the links between requirements, design, and verification and finds where derived or changed requirements never made it into the trace at all. You get a gap list of the broken and missing links, an evidence map behind the trace, and a closure sequence certification leadership can work through.
When this review is needed
- A submittal is near and the trace has to show every requirement reaching design and verification.
- Derived requirements were generated during design and may never have entered the trace.
- A design change altered requirements and the downstream and upstream links were not updated.
- A finding response rests on a trace that has not been walked end to end recently.
The problem
A requirements trace is only useful if it is complete, and completeness is exactly what erodes as a program runs. Derived requirements appear during design and get implemented without ever being added to the trace, a changed requirement gets a new verification but keeps its old design link, and the matrix that should show a clean thread from requirement to test carries orphans in both directions. The trace looks dense and finished while the specific threads a reviewer samples are the ones that break.
What gets reviewed
- Requirements traced forward to the design elements that implement them
- Design elements traced forward to the verification that exercises them
- Derived requirements checked for presence in the trace and a verification path
- Changed requirements checked so both upstream and downstream links followed the change
- Orphan design and verification items caught where nothing traces to them
- The trace reconciled to the DO-178C and DO-254 objectives it has to satisfy
What gets validated
- Every requirement traces forward to a design element that implements it
- Every design element traces to verification that actually exercises it
- Each derived requirement appears in the trace with its own verification path
- A changed requirement carries both its updated design link and its updated verification link
- No design or verification item is orphaned with nothing tracing to it
Evidence normally required
Common discrepancies
- A derived requirement implemented in the design but absent from the trace
- A changed requirement whose verification still exercises the old behavior
- A design element with no requirement tracing to it
- A verification item that traces to nothing, leaving its purpose unclear
What is at stake
A derived requirement missing from the trace is a piece of the design that was never shown to be verified, which under DO-178C or DO-254 is a direct objective shortfall a reviewer will find by sampling. A changed requirement whose links did not follow it leaves verification pointing at the old behavior, so the evidence exists but proves the wrong thing, and untangling that near submittal reopens both the design and the verification thought settled.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Walk it forward
Trace each requirement through the design to the verification that exercises it.
Hunt the derived
Confirm every derived requirement entered the trace with its own verification path.
Follow the changes
Check that changed requirements carried both their design and verification links.
Clear the orphans
Find design and verification items with nothing tracing to them and resolve each.
What the buyer receives
- A gap list of the broken and missing links in the trace
- An evidence map from each requirement to its design and verification
- A closure sequence to add the missing links and correct the mismatched ones
Who uses the output
- Certification leads confirming the trace will survive a reviewer sampling threads
- Engineering leads deciding how a derived or changed requirement enters the trace cleanly
- Reviewers on the supplier side hunting orphans before a finding response goes out
How the work fits into the transaction or program
The requirements trace is the spine the DO-178C and DO-254 assurance argument runs along, so a break in it undermines the accomplishment summary that reports the objectives as met. Walking it before submittal lets the supplier repair a broken thread while the design and verification teams are still engaged, and the completed trace feeds the compliance matrix and the means-of-compliance map that both assume every requirement reaches evidence.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
The trace satisfies the DO-178C and DO-254 objectives the FAA and EASA both recognize, and the two authorities can differ in how strictly they sample derived requirements and their verification. The review notes where a trace accepted by one authority would draw deeper sampling from the other, so a trace built for one submittal is not assumed sufficient for the second.
Regulatory limits
The review checks the trace for complete, unbroken links from requirement to design to verification. It does not verify a requirement, accept the trace on an authority's behalf, or determine that the article satisfies its objectives.
What this review does not cover
- Performing the verification a trace link is missing
- Authoring the derived requirements absent from the trace
- Any determination that the trace satisfies the authority's objectives
Specific to this review
- Derived requirements are the classic hole in a trace, because they are born during design and nothing forces them into the matrix the way top-level requirements are.
- A changed requirement whose verification did not follow it is more dangerous than a missing link, because the evidence exists and proves the old behavior, so the trace reads as complete.
- Orphan verification items point to work done without a requirement behind it, which either signals a missing requirement or effort that proves nothing the certification basis asked for.
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
Why do derived requirements get so much attention here?
Top-level requirements are captured up front, but derived requirements appear during design and nothing automatically adds them to the trace. A reviewer sampling under DO-178C or DO-254 tends to find exactly these, so the review looks for the derived requirements that were implemented but never traced or verified.
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.