Requirements traceability
Requirements traceability evidence review for quality teams
This review checks that the trace from requirements through design to verification holds together, with particular attention to the derived and changed requirements that most often fall out of it. A certification specialist reads the alignment across the requirement, design, and verification layers with your quality function, confirms each level ties to the certification basis, and finds where a derived or modified requirement never made it into the trace. It runs before submittal, during a finding response, or after a change reworks requirements already traced. You receive a gap list, an evidence map keyed to each requirement, and a closure sequence for quality leadership.
When this review is needed
- A trace is about to be submitted and quality wants derived and changed requirements confirmed present first.
- A finding questions whether a requirement was carried through design and verification or dropped along the way.
- A change reworked the requirement set and the trace mixes original and revised requirements without reconciliation.
- Requirements were authored across system, software, and hardware teams and the trace has never been read end to end.
The problem
Traceability is easy to keep for the requirements everyone knows about and hard to keep for the ones the design invents along the way. A derived requirement is created inside a design decision, satisfied locally, and never linked back up the trace. A change revises a requirement, and the design and verification below it still point at the old wording. Quality inherits a trace that looks connected at the top and frays exactly where the risk lives.
What gets reviewed
- Alignment confirmed across the requirement, design, and verification levels so each ties to the ones above and below
- Derived requirements identified and checked for their trace both downward and back to the safety assessment
- Requirements changed since the last trace pass checked so design and verification below them followed the change
- Each requirement level tied to the certification basis so nothing floats unanchored
- Orphaned design or verification elements found where no requirement above them claims the work
What gets validated
- Each requirement traces down to design and verification and back up to its parent or the basis
- Every derived requirement is present in the trace and visible to the safety assessment
- Requirements revised by a change carry design and verification that reflect the revised wording, not the superseded one
- No design or verification element is orphaned below a requirement that no longer exists
- The trace resolves to one consistent baseline rather than a blend of pre- and post-change requirements
Evidence normally required
- The requirement set at its current baseline with derived requirements marked
- The trace matrix or database linking requirements to design and verification
- The design data the requirements decompose into
- The certification basis the top-level requirements anchor to
- Change records for any requirement modified since the last trace reconciliation
Common discrepancies
- A derived requirement created in the design but never linked upward or fed to the safety assessment
- A requirement revised by a change while its design and verification still point at the old wording
- A design element with no requirement above it, signalling either scope creep or a requirement that was dropped
- A trace that mixes pre- and post-change requirements, so completeness reads differently depending on the baseline used
What is at stake
A trace with a missing derived requirement or a stale changed one gives a reviewer a thread to pull. They follow a design element back and find no requirement above it, or they read a requirement and find the verification below still answers an earlier version. What looked like a complete trace turns into a rework of every level the gap touches, and derived requirements that were never traced to the safety assessment can reopen the safety story as well.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Fix the baseline
Pin the current requirement set, mark derived requirements, and confirm the trace reflects that baseline rather than a blend.
Trace both directions
Confirm each requirement links down to design and verification and up to its parent or the basis so orphans and gaps both surface.
Check the derived and changed
Confirm derived requirements are present and fed to safety, and that changed requirements pulled their design and verification with them.
Sequence the closures
Order the fixes so the derived and changed requirements are reconciled before the levels that depend on them.
What the buyer receives
- A gap list naming each requirement missing from the trace and each level left misaligned
- An evidence map tying every requirement to its design and verification links
- A closure sequence ordering the fixes so derived and changed requirements are reconciled first
Who uses the output
- Quality leadership deciding whether the trace will hold under a reviewer's read
- Systems and design engineers who need to know which requirements to relink or reconcile
- The safety team confirming derived requirements reached the assessment they should have
How the work fits into the transaction or program
Requirements traceability is the structure verification and safety both hang from, so a hole in the trace weakens everything downstream of it. This review sits between the engineering that decomposed the requirements and the submittal that presents the trace, finding the derived and changed requirements that slipped out while there is still time to fold them back in.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both expect the trace to reach the certification basis, and the software and hardware development assurance standards it spans apply the same way under both. The finding path differs: FAA delegated findings against a project plan on one side, EASA review items and means-of-compliance acceptance on the other. The trace has to satisfy both, so the review reads it against whichever basis and finding path the program is filing under.
Regulatory limits
This review reads your own traceability and reports where it holds and where it breaks. It does not make an airworthiness determination, does not issue or accept a compliance finding, and does not replace the authority's or the delegate's review of the requirement and verification data.
What this review does not cover
- Authoring the missing requirements or trace links the gaps call for
- Re-running the design or verification work behind a requirement
- Rendering the compliance finding an authority or delegate reserves
Specific to this review
- Derived requirements are the trace's structural blind spot: they are born inside the design, so they are easy to satisfy locally and easy to leave out of the trace up and to the safety assessment.
- A change that revises a requirement rarely propagates cleanly, so the design and verification below it often keep answering the old wording.
- Reading the trace upward from design finds orphaned elements that no requirement claims, which usually mark either scope creep or a silently dropped requirement.
- Completeness of a trace is meaningless without a fixed baseline, because a set mixing pre- and post-change requirements can read complete against either one and consistent against neither.
Sources
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).
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
Frequently asked questions
Why focus so much on derived and changed requirements specifically?
Because those are where the trace almost always breaks. Requirements written up front tend to be traced by habit. Derived requirements appear inside design decisions and get satisfied without being linked upward, and changed requirements leave stale design and verification behind them. The review reads the whole trace but weighs its attention toward the two failure modes that actually produce findings.
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.