Major change program
Requirements traceability review for a major change program
This review checks the requirements traceability underpinning a major change, confirming that requirements, design, and verification stay aligned and that derived and changed requirements are actually captured. A certification specialist follows the trace up and down, looking for the derived requirements a design decision created but never recorded and the changed requirements the trace still reflects in their old form. The output shows where the requirement set the package is built on has holes. You receive a gap assessment, a corrected trace view, and a closure plan before the traceability anchors the verification work.
When this review is needed
- A major change added derived requirements during design and the trace may not have captured all of them.
- Requirements changed after the trace was first built and some entries still reflect the earlier version.
- The verification work is about to key off the trace, so a hole in it propagates into missing verification.
- Software and hardware trace has to connect to the system requirements the change introduced.
The problem
Derived requirements are born inside design decisions, which is exactly where they escape the trace. A designer resolves an architecture choice and creates a requirement the system spec never named, and unless someone records it, the trace is complete against the requirements it knows and blind to the one it does not. Changed requirements have the mirror problem: the trace keeps pointing at the old wording while the design has moved to the new.
What gets reviewed
- Requirements, design, and verification alignment checked in both directions across the change
- Derived requirements created during design confirmed present in the trace
- Changed requirements reconciled so the trace reflects the current wording, not the superseded one
- System requirements connected to the software and hardware trace they flow into
- Orphan design elements identified where design exists with no requirement above it
- Requirements with no downstream design or verification link flagged as trace holes
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
- Each derived requirement a design decision created appears in the trace with a parent and a child
- Changed requirements are reflected in the trace at their current version, not the prior one
- Every requirement links downward to design and verification without a dangling end
- No design element exists as an orphan with no requirement above it
- System requirements connect cleanly to the software and hardware trace below them
Evidence normally required
- The requirements traceability data for the change
- The system, software, and hardware requirement sets
- The design data and any change records that created derived requirements
- The verification plan the trace will feed
- The change history showing which requirements were revised
Common discrepancies
- A derived requirement created in design that never entered the trace
- A changed requirement the trace still shows in its superseded wording
- A design element with no requirement traced above it
- A system requirement with no link into the software or hardware trace
What is at stake
A derived requirement absent from the trace is a requirement nothing verifies, which surfaces as a coverage gap when verification is mapped back or as an authority finding at review. A changed requirement the trace still shows in its old form sends verification to prove the wrong thing, so the evidence passes against a requirement the design no longer has.
How the work runs
Trace both directions
Walk requirements down to design and verification and back up, marking every dangling end.
Recover the derived
Read the design change records for requirements created in design that the trace never captured.
Reconcile the changes
Confirm each revised requirement appears in the trace at its current version, not the superseded one.
Close the holes
List the missing derived requirements and orphan elements and sequence the trace corrections.
What the buyer receives
- A gap assessment naming the missing derived and changed requirements
- A corrected trace view with the holes and orphans identified
- A closure plan for restoring full up-and-down traceability
Who uses the output
- Certification leadership confirming the requirement set is whole before verification keys off it
- Engineering leadership resolving orphan design and missing derived requirements
- Compliance managers tracking the trace holes still open
How the work fits into the transaction or program
The trace review runs before the verification work commits to the requirement set, because verification inherits whatever the trace contains, holes and all. Fixing a missing derived requirement here costs a trace entry and a verification task; finding it after verification is complete costs a rework of the evidence.
Start with a single asset
Reduce finding cycles by checking the package first.
Regulatory limits
The review confirms the requirements trace is complete and internally consistent. It does not approve the requirements, verify the design against them, or make any compliance or airworthiness finding on the change.
What this review does not cover
- Writing the missing derived requirements
- Performing the verification the trace feeds
- Any compliance or airworthiness determination on the change
Specific to this review
- Derived requirements are created inside design decisions, which is the one place a requirements trace built from the spec cannot see them.
- A trace can be internally perfect and still wrong, because it is complete against the requirements it knows and silent on the ones it never captured.
- A changed requirement left in its old wording in the trace sends verification to prove something the design no longer does.
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. FAA type certification process, certification basis establishment, and compliance findings.
European Union / EASA. EASA design and production certification, STCs, ETSO authorizations, and EASA Form 1 release.
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 is complete top to bottom. How can it still have gaps?
A trace is only as complete as the requirement set it starts from. Derived requirements created during design and requirements changed after the trace was built are the two ways the set itself is incomplete, so the trace can be internally consistent and still miss real requirements.
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.