Requirements traceability
Requirements traceability evidence review for hardware teams
This review checks that the trace from requirements through design to verification is complete in both directions and that nothing fell out of it. A certification engineer works the traceability data across the ARP4754B, DO-178C, and DO-254 tiers, confirms requirements flow down to design and verification and back up again, and hunts for the derived and changed requirements that trace links most often miss. Hardware assurance teams use it before submittal, in a finding response, or after a change that added requirements. You receive a gap list of broken or missing trace links, an evidence map, and a closure sequence.
When this review is needed
- A submittal depends on the traceability data and you need it complete before an authority reads it.
- The authority asked to see the trace for a requirement and the answer has to be end to end.
- A change added or altered requirements and the trace has to be rebuilt to catch them.
- Requirements, design, and verification were developed in different tools that never fully linked.
The problem
Traceability is maintained by the people writing requirements and the people running verification, and derived requirements fall in the seam between them. A derived requirement is created during design or implementation, so it never came down from a parent and is easy to leave without an upward link. A changed requirement is worse, because the old trace stays in place and looks intact while the change it should reflect is absent from the chain.
What gets reviewed
- Downward trace from requirements to design and to verification
- Upward trace from verification and design back to the requirements they satisfy
- Derived requirements and their links to design, verification, and the safety process
- Changed requirements and whether the trace was rebuilt to match the change
- Trace continuity across the system, software, and hardware tiers
- Requirements with no verification and verification with no requirement
What gets validated
- Every requirement traces down to design and to the verification that closes it
- Every verification result traces up to a requirement it satisfies
- Derived requirements carry an upward link and reach the safety process
- Changed requirements have a trace rebuilt to the current version, not a stale one
- No verification exists without a requirement and no requirement without verification
Evidence normally required
- The requirements set across system, software, and hardware tiers
- The design data the requirements flow into
- Verification results and their requirement references
- The traceability data or matrix linking the three
- The change history if a change added or altered requirements
Common discrepancies
- A derived requirement with no upward link and no path to the safety process
- A changed requirement whose trace still points at the pre-change version
- A verification result that traces to no requirement in the current set
- A requirement with design but no verification closing it
What is at stake
A trace with holes means the program cannot show that every requirement is designed and verified, which is a core expectation an authority will not waive. Derived requirements missing an upward link can leave the safety process unaware of them, and a changed requirement with a stale trace can send verification against the wrong version, which surfaces as a finding at exactly the wrong time.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Trace top to bottom
Follow each requirement down through design to the verification that closes it.
Trace bottom to top
Confirm each verification result and design element links back up to a requirement.
Hunt the seams
Find derived requirements without upward links and changed requirements with stale traces.
Relink and sequence
List the breaks and prioritize the derived and changed requirements to rebuild first.
What the buyer receives
- A gap list of broken, stale, or missing trace links
- An evidence map showing the complete chains and the incomplete ones
- A closure sequence prioritizing the derived and changed requirements to relink
Who uses the output
- Hardware assurance leads confirming the trace is complete before submittal
- Certification leadership answering a finding on a requirement's trace
- Engineering leads rebuilding the trace a change disturbed
How the work fits into the transaction or program
Traceability is the spine every other evidence type hangs on, since a compliance claim, a safety argument, and a verification result all assume the requirement they reference is properly linked. Reading the trace for completeness before submittal keeps a missing derived requirement or a stale changed one from undermining the packages built on top of it.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both expect bidirectional traceability across the requirement tiers, and both treat derived requirements as a specific concern for the safety process. Their divergence is procedural rather than conceptual, in how the trace is presented and reviewed at each stage, so the review notes where the trace data would need re-presenting for a second authority.
Regulatory limits
This review reads the traceability data for completeness and consistency. It does not author requirements, perform verification, or make a compliance finding. Acceptance of the trace rests with the authority.
What this review does not cover
- Writing or deriving requirements the set is missing
- Performing the verification a requirement lacks
- Any compliance finding on the traceability data
Specific to this review
- Derived requirements are the trace's blind spot, because they are born during design with no parent to link them upward.
- A changed requirement leaves the most deceptive gap, since the old trace stays visibly intact while the change it should carry is absent.
- A trace break in the requirement tier propagates into the safety case and the compliance matrix, so it is the most leveraged evidence type to check first.
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 single out derived and changed requirements?
They are where trace data reliably fails. A derived requirement never had a parent to link it upward, and a changed requirement leaves its old trace looking intact. Ordinary requirements written top-down are usually linked correctly; these two categories are where the review concentrates its effort.
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.