Requirements traceability evidence review for aircraft modifiers

When this review is needed

• A submittal depends on showing that every requirement flows to design and back from verification.
• A finding questioned whether derived requirements were captured and traced.
• A design change added, split, or retired requirements and the trace was not re-walked afterward.
• The requirement set spans system, software, and hardware tiers and the cross-tier links were never verified together.

The problem

Traceability is easy to assert and hard to keep true. Requirements move: one gets decomposed into three, another is derived from a design decision, a third is changed by a late finding. Each move is a chance for a link to break silently. The trace database still reports coverage, but the links it reports may point at a parent that was retired or a child that was never created, and nobody notices until a reviewer walks a specific thread.

What gets reviewed

• Downward links from each parent requirement to the design elements that implement it
• Upward links from verification results back to the requirements they satisfy
• Derived requirements confirmed to be captured, justified, and fed back into the safety and design process
• Requirements changed by findings or engineering churn confirmed to have propagated to design and verification
• Cross-tier links between system, software, and hardware requirements checked for continuity
• Orphaned requirements with no parent and childless parents with no implementation both surfaced

What gets validated

• Each parent requirement links to at least one design element that implements it
• Each verification result links up to the specific requirement it verifies
• Every derived requirement is recorded with a rationale and fed to the safety process
• Requirements altered by a change carry that change through to design and verification links
• System, software, and hardware requirements connect across tiers without a dropped link

Evidence normally required

• The requirement set across system, software, and hardware tiers
• The trace data or matrix that records parent-child and verification links
• The design description or architecture the requirements map into
• The verification records that close the requirements
• Change records that added, split, or retired requirements since baseline

Common discrepancies

• Derived requirements present in the design but absent from the trace
• Verification results linked to a requirement that a later change already retired
• Parent requirements with no child design element implementing them
• Cross-tier links dropped where a system requirement should reach a software or hardware child

What is at stake

A broken trace lets a requirement go unverified while the program believes it is covered, which is precisely the failure certification traceability exists to prevent. Derived requirements outside the trace are the common cause, and a finding on any one of them tends to trigger a full re-walk under deadline, which is far more costly than catching the break early.

How the work runs

What the buyer receives

• A gap list of broken, orphaned, and unpropagated links with the tier each sits in
• An evidence map showing the trace threads that hold and the ones that do not
• A repair order that reconnects derived and changed requirements before dependent threads

Who uses the output

• STC program managers judging whether traceability will survive a reviewer's spot check
• Certification engineers answering a finding on derived-requirement capture
• Engineering leads assigning the rework to reconnect the broken threads

How the work fits into the transaction or program

Traceability is the spine that lets verification evidence answer requirements and lets the safety process see every derived requirement. This review tests that spine end to end, so the compliance data downstream rests on links that actually hold rather than a coverage count that flatters them.

Jurisdiction-specific considerations

FAA and EASA both expect bidirectional traceability, and both read derived requirements with particular care because they carry the design decisions the basis did not anticipate. The review applies the governing authority's emphasis on derived-requirement rationale rather than treating all links as equal.

Regulatory limits

This review checks the modifier's own trace. It does not verify any requirement, does not make a compliance finding, and does not determine airworthiness. Those actions belong to the program's verification activity and the authority.

What this review does not cover

• Authoring or repairing the trace links for the modifier
• Performing the verification that closes an unverified requirement
• Deriving or justifying missing derived requirements

Specific to this review

• Coverage counts stay green even when links break, because a link pointing at a retired parent still counts as a link until someone walks the thread.
• Derived requirements are the usual point of failure, since they enter after the baseline and depend on someone remembering to route them into both design and safety.
• A single retired requirement can strand a valid verification result, which then reads as evidence for nothing and hides the requirement it should have covered.
• Cross-tier breaks are easy to miss because system, software, and hardware traces are often maintained in separate tools that are reconciled only at review time.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits