Requirements traceability
Requirements traceability support for an installation approval
This review checks the requirements traceability for an installation approval so requirements, design, and verification stay aligned through every layer. A certification engineer runs it before the trace anchors the compliance argument. It confirms each requirement traces down to a design response and up to a verification result, that derived requirements from the DO-178C and DO-254 work appear in the trace, and that a requirement changed late did not leave orphaned design or stale verification behind it. You receive a gap assessment of the trace, a linked view from requirement through design to verification, and a plan for the broken and missing links.
When this review is needed
- The trace links requirements to verification but no one has confirmed the derived requirements are in it.
- A requirement changed late and it is unclear whether the design and verification below it moved with it.
- Verification results exist that no requirement traces to, or requirements that no result closes.
- A reviewer will follow the trace end to end and any orphan or break stops the compliance argument.
The problem
Traceability is only as strong as its weakest link, and links break silently. Derived requirements emerge from the DO-178C and DO-254 work and never make it back into the top-level trace, a requirement changes late while the design and verification below it stay put, and verification results accumulate that no requirement claims. Each break is small, but a trace that reads complete can still leave a requirement with no verification or a result with no requirement, and the disconnect only shows when someone follows the chain end to end.
What gets reviewed
- Each requirement traced down to a design response and up to a verification result
- Derived requirements from the DO-178C and DO-254 work carried into the trace
- Late requirement changes propagated through design and verification
- Orphaned verification results and unverified requirements identified
- Bidirectional consistency across the requirement, design, and verification layers
- Trace completeness reconciled against the certification basis for the installation
Scope this review
Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.
Identify what is missing against the means of compliance.
What gets validated
- Every requirement traces to a design response and to a verification result
- Derived requirements appear in the top-level trace rather than only in the item data
- A requirement changed late shows corresponding changes in its design and verification
- No verification result is orphaned from the requirement it was meant to close
- The trace is consistent in both directions across all layers
Evidence normally required
- The requirements traceability data for the installation
- The requirement set including derived requirements
- The design data the requirements trace to
- The verification results credited against the requirements
- The certification basis and change impact assessment for the installation
Common discrepancies
- A derived requirement present in the item data but absent from the top-level trace
- A requirement changed late with design or verification that never moved with it
- A verification result that no requirement traces to
- A requirement with a design response but no verification closing it
What is at stake
A broken trace undermines the compliance argument it is supposed to carry, because a requirement without verification is unproven and a result without a requirement proves nothing that was asked for. A derived requirement missing from the trace can hide an unverified function, and a late change that did not propagate leaves design or verification that no longer matches intent. A reviewer following the chain finds these, and each one reopens as a finding.
How the work runs
Trace top to bottom
Confirm each requirement reaches a design response and a verification result in both directions.
Recover derived requirements
Pull derived requirements out of the item data and confirm they are in the top-level trace.
Propagate late changes
Check that a requirement changed late moved its design and verification with it.
Plan the closure
Sequence the fixes for orphaned results and unverified requirements before submission.
What the buyer receives
- A gap assessment of the trace's broken and missing links
- A linked view from each requirement through design to verification
- A closure plan for the orphaned results and unverified requirements
Who uses the output
- Certification engineers confirming the trace a reviewer follows holds end to end
- Systems and software leads reconciling derived requirements into the trace
- Compliance managers tracking which requirements still lack verification
How the work fits into the transaction or program
Traceability is the connective tissue of the whole installation approval, so this review confirms it before the compliance argument rests on it. It reads the requirement, design, and verification layers together and reconciles the derived requirements out of the DO-178C and DO-254 work, feeding the compliance matrix a trace whose links actually hold when a reviewer follows them.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
The FAA and EASA both expect bidirectional traceability, but the depth of derived-requirement treatment and the artifacts each asks to see can differ. The review notes where the trace needs additional articulation for one authority so the same requirements data supports both findings.
Regulatory limits
The review confirms the trace is complete and consistent across its layers. It does not verify requirements on the program's behalf, accept the trace on the authority's behalf, or make any airworthiness determination.
What this review does not cover
- Performing the verification the trace links to
- Authoring the requirements or the design data
- Any airworthiness determination on the installation
Specific to this review
- Derived requirements are the most common trace gap, because they originate in the item-level work and no step forces them back into the top-level trace.
- A late requirement change is the quiet break: the requirement moves, the design and verification below it do not, and the trace reads intact while intent and evidence have diverged.
- An orphaned verification result is a symptom worth chasing, because it usually means a requirement was removed or renumbered without cleaning up what it once closed.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Federal Aviation Administration. STC application process, certification basis, and continued airworthiness obligations of an STC holder.
RTCA. Environmental qualification test categories and procedures referenced by TSO and equipment qualification.
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).
Frequently asked questions
Our trace tool shows full coverage. Why review it manually?
A tool shows links that exist, not links that should exist. Derived requirements that never entered the trace, and late changes that did not propagate, produce a trace that reads complete while a requirement goes unverified. The review checks for the links that are missing, which is what a reviewer following the chain will find.
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.