STC certification
Requirements traceability support for an STC program
This review readies the requirements traceability behind an STC, so the chain from each requirement to its design and its verification holds without a break. It is run for an aircraft modifier or equipment supplier while the design data is maturing. The work checks that requirements link forward to the design that implements them and to the verification that confirms them, and that derived and changed requirements are captured rather than lost when the design moved. You receive a gap assessment of the trace, an evidence map showing the requirement-to-design-to-verification chain, and a closure plan for the links that are broken or missing.
When this review is needed
- The design has iterated and the trace has to catch up to requirements that were added, changed, or dropped.
- Derived requirements emerged from the design and need to be captured in the trace and verified.
- A requirement changed but its downstream design and verification links still point at the old version.
- The submittal will be examined for traceability under a standard that expects derived requirements to be handled explicitly.
The problem
Traceability decays every time the design changes. A requirement is revised and its verification link still points at the result that satisfied the old wording. The design throws off a derived requirement that no one adds to the trace, so it is implemented but never verified. A requirement is dropped and its now-orphaned verification stays in the package. Each change is small, but they accumulate into a trace that no longer describes the requirements the design actually implements.
What gets reviewed
- Each requirement linked forward to the design element that implements it
- Each requirement linked forward to the verification that confirms it
- Derived requirements captured in the trace and given a verification link
- Changed requirements reconciled so downstream links point at the current version
- Dropped requirements and their orphaned verification cleared from the package
- Broken and missing links collected into a closure plan
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 forward to a design element that implements it
- Every requirement traces forward to a verification that confirms the current version
- Derived requirements appear in the trace with their own verification, not just in the design
- A changed requirement's downstream links point at the revised requirement, not the superseded one
- No orphaned verification remains for a requirement the program has dropped
Evidence normally required
- The requirement set at its current revision, including derived requirements
- The design data that implements the requirements
- The verification evidence and its links to requirements
- The change history showing how requirements were added, revised, or dropped
- The certification basis and standards defining the traceability expectations
Common discrepancies
- A derived requirement implemented in the design but absent from the trace and unverified
- A verification link pointing at the result that satisfied a since-revised requirement
- A dropped requirement whose orphaned verification is still carried in the package
- A requirement with a design link but no verification link at all
What is at stake
A broken trace means a requirement can be implemented but unverified, or verified against a version that changed, and either gap is exactly what a standards-based review looks for. A derived requirement missing from the trace is a requirement no one confirmed the design meets, which is a safety-relevant hole rather than a paperwork one. Reconstructing traceability after the design has moved several times is slow, because the history of each change has to be rebuilt.
How the work runs
Baseline the requirements
Fix the current requirement set, including derived requirements, as the trace reference.
Follow the chain forward
Confirm each requirement links to a design element and a verification of the current version.
Capture the derived set
Confirm derived requirements are in the trace and verified, not only implemented.
Clear and close
Remove orphaned verification and plan the closure of the broken or missing links.
What the buyer receives
- A gap assessment of the forward and backward trace across the requirement set
- An evidence map of the requirement-to-design-to-verification chain
- A closure plan for the broken links and uncaptured derived requirements
Who uses the output
- Certification engineers assembling the traceability evidence for the submittal
- Design and verification leads accountable for the links their work supports
- Program managers tracking which requirements are fully traced and which are not
How the work fits into the transaction or program
Requirements traceability is the spine that the compliance matrix and the verification trace both attach to, so this review runs as the design stabilizes and before the submittal is compiled. It confirms the chain from requirement to design to verification holds, which is what lets the downstream verification-trace and compliance-matrix work rest on a stable requirement set rather than a moving one.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
Standards-based reviews under both FAA and EASA expect derived requirements to be identified and traced explicitly rather than absorbed into the design, so the review holds the trace to that expectation regardless of which authority will examine it.
Regulatory limits
The review confirms the requirement trace is complete and current. It does not verify the requirements themselves, accept the traceability on the authority's behalf, or grant the STC.
What this review does not cover
- Performing the verification that closes a requirement
- Authoring or approving the derived requirements
- Any authority acceptance of the trace or the STC
Specific to this review
- Traceability decays with every design change, because a revised requirement rarely drags its downstream links along with it automatically.
- A derived requirement missing from the trace is a safety-relevant gap, not a clerical one, since it means the design does something no requirement confirmed it should.
- Orphaned verification for a dropped requirement clutters the package and can mask that a current requirement is actually unverified.
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.
European Union / EASA. EASA design and production certification, STCs, ETSO authorizations, and EASA Form 1 release.
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.
Frequently asked questions
Why do derived requirements matter so much in the trace?
A derived requirement comes out of design decisions rather than the original requirement set, so it is easy to implement and forget to verify. If it is missing from the trace, the design meets a need that no requirement confirmed and no verification checked, which is precisely the kind of gap a standards-based review is built to 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.