Field approval data
Requirements traceability support for an FAA field approval
This review checks the requirements traceability behind a field-approval package, confirming that the thread from each requirement to its design implementation and its verification is complete and current. It is run by or for a modifier or operator whose alteration adds or changes function, where an inspector will expect requirements to be traceable rather than asserted. It looks for derived requirements that never entered the trace, changed requirements that left orphaned design or verification behind them, and design elements that satisfy no stated requirement. You get a gap assessment, an evidence map of the requirement-to-verification thread, and a closure plan for the requirements and design elements the trace has stranded.
When this review is needed
- An alteration adds or changes function and requirements now have to trace to design and verification.
- Derived requirements emerged during design and may never have been captured in the trace.
- A late requirement change left design or verification behind that no longer maps to anything.
- Software or hardware in the alteration brings DO-178C or DO-254 trace expectations into the package.
The problem
Requirements traceability degrades in two directions at once. Going down, derived requirements appear during design, from a decision, a constraint, or an interface, and they get implemented without ever being written back into the requirement set, so the trace has design with no requirement above it. Going up, a requirement changes late and the design and verification that served the old version are left in place, mapping to a requirement that no longer reads that way. Both breaks are invisible in a trace that only counts links and never tests whether the links still mean anything.
What gets reviewed
- The thread from each requirement to its design implementation to its verification
- Derived requirements identified during design and traced back into the requirement set
- Changed requirements checked for orphaned design or verification left behind
- Design elements confirmed to satisfy a stated requirement rather than standing alone
- DO-178C software and DO-254 hardware trace included where the alteration contains them
- ARP4754B function and interface requirements represented in the trace where function is added
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 down to a design element and up to a verification result
- Each derived requirement generated in design appears in the requirement set and the trace
- No design or verification is orphaned against a requirement that has since changed
- No design element exists in the package without a requirement it satisfies
- Software and hardware trace threads are present where the alteration includes DO-178C or DO-254 items
Evidence normally required
- The requirement set for the alteration, including any derived requirements
- The design description and the elements that implement the requirements
- The verification records that close each requirement
- The change history for requirements revised during the effort
- Any DO-178C or DO-254 trace data for embedded software or hardware
Common discrepancies
- A derived requirement implemented in design but never written back into the requirement set
- Verification that maps to a requirement whose wording changed after the test
- A design element in the package that satisfies no stated requirement
- A software trace thread that stops before reaching a verification result
What is at stake
A derived requirement outside the trace is unverified by definition, so a function the alteration actually relies on may have no evidence behind it, and an inspector who finds one such gap questions the completeness of the whole trace. Orphaned design and verification from a changed requirement are the opposite failure: effort was spent verifying against a requirement that no longer exists, which both wastes that work and hides whether the current requirement is verified at all.
How the work runs
Walk the thread down
Trace each requirement to the design element that implements it and flag design with no requirement above it.
Recover the derived set
Identify requirements generated during design and confirm they entered the requirement set and the trace.
Re-map the changes
Check every changed requirement for orphaned design or verification left mapping to the old wording.
Close the strands
List the stranded requirements and design elements and sequence the repairs before submission.
What the buyer receives
- A gap assessment of broken and orphaned links across the requirements trace
- An evidence map of the requirement-to-design-to-verification thread
- A closure plan for the derived and changed requirements the trace has stranded
Who uses the output
- Engineering leads confirming every requirement is traced before the package reaches an inspector
- Compliance staff reconciling derived requirements into the trace
- Maintenance leadership confirming the added function is fully accounted for in the requirement set
How the work fits into the transaction or program
Requirements traceability is what lets an inspector confirm that everything the alteration adds is both required and verified, rather than taking the modifier's word for it. This review runs after design and verification are substantially done and before submission, so derived requirements and orphaned links are repaired while the team still remembers why each element exists, rather than reconstructing that intent under inspector questioning.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
A field-approved alteration that adds function is held to the same expectation of traceability an FAA inspector applies to any alteration data, and where the alteration contains software or complex hardware the DO-178C and DO-254 trace expectations come with it. The review notes where a trace assembled for the field-approval path would need extension to support an STC on the same modification, since the type-certificate route examines the thread in more depth.
Regulatory limits
The review checks that the requirements trace is complete and current. It does not write the missing requirements, perform the verification, obtain the field approval, or determine that the altered aircraft is airworthy.
What this review does not cover
- Authoring the derived or changed requirements the trace is missing
- Performing the verification that closes an untraced requirement
- Any airworthiness determination on the altered aircraft
Specific to this review
- Trace breaks in two directions: derived requirements appear below the set and get implemented without being captured, while changed requirements strand the design and verification above them.
- A derived requirement outside the trace is unverified by definition, so it hides a function the alteration relies on with no evidence behind it.
- A link-counting trace looks complete while being hollow, because it never tests whether a link still connects a current requirement to current evidence.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
U.S. Government (eCFR). Maintenance recordkeeping content and approval-for-return-to-service requirements, including 43.9, 43.11, and Appendix B.
Federal Aviation Administration. FAA type certification process, certification basis establishment, and compliance findings.
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
Why do derived requirements cause so many trace gaps?
Derived requirements are generated during design from a decision or constraint, not handed down from the original requirement set, so they are easy to implement and forget to document. A derived requirement that never enters the trace is unverified by definition, which is why the review actively recovers them rather than only checking existing links.
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.