Requirements traceability
Requirements traceability evidence review for certification teams
A requirements traceability evidence review checks that the thread from each requirement down into the design and up into verification is unbroken, and that nothing the design added has escaped the trace. It is run for a certification team before submittal, during a finding response, or ahead of a design change review, by or for the team that owns the requirements baseline. The work reads requirements, design, and verification alignment across the trace, then flags derived or changed requirements that never entered it. You receive a gap list, an evidence map of every broken or missing link, and a closure sequence compliance management can execute.
When this review is needed
- The design introduced derived requirements that were never fed back up into the requirements baseline.
- A requirement changed and the design or verification links pointing at it were not revisited.
- The trace shows a requirement with no design element implementing it or no verification confirming it.
- The team is preparing to submit and wants the requirement threads proven end to end.
The problem
Traceability is maintained by hand across tools that were never meant to agree, so the links rot faster than anyone notices. A design decision spawns a derived requirement that stays in an engineer's head instead of the baseline, a requirement is reworded and its downstream links still point at the old intent, and a late change touches one requirement while its neighbors quietly fall out of alignment. The trace matrix reports full coverage, but a share of its links no longer mean what they claim.
What gets reviewed
- Each top-level requirement traced down to the design elements that implement it
- Each requirement traced up to the verification that confirms it
- Derived requirements checked for capture in the baseline and for their own verification
- Changed requirements checked so downstream links were revisited after the change
- Bidirectional consistency confirmed so no design element implements an absent requirement
- Requirement wording checked against the links so a reworded requirement did not orphan its trace
What gets validated
- Every requirement links to at least one design element that implements it
- Every requirement links to verification that confirms it, with no requirement left unverified
- Each derived requirement appears in the baseline and carries its own downstream trace
- A requirement that changed shows its design and verification links were re-examined
- No design element or test traces to a requirement that no longer exists in the baseline
Evidence normally required
- The requirements baseline at the level being traced
- The design data the requirements are implemented in
- The verification records the requirements are confirmed by
- The traceability matrix or database in its current state
- The change history for requirements revised during the program
Common discrepancies
- A derived requirement present in the design but never entered into the baseline
- A requirement-to-verification link pointing at a test that no longer confirms the reworded requirement
- A design element tracing to a requirement that a later change deleted
- A requirement with a design link but no verification obligation attached
What is at stake
A derived requirement missing from the trace is a piece of the design with no verification obligation attached, which is exactly the kind of gap a safety-relevant standard is written to prevent. A broken requirement-to-verification link leaves a requirement that appears met but was never actually confirmed, and finding those late means reopening verification the team believed was finished.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Trace both directions
Follow each requirement down to design and up to verification, then check the reverse links.
Hunt the derived
Confirm every derived requirement reached the baseline and carries its own trace.
Re-check the changed
Confirm requirements that changed had their downstream links revisited.
Sequence the repairs
Order the trace fixes against the submittal date.
What the buyer receives
- A gap list identifying each broken, missing, or orphaned trace link
- An evidence map showing where derived and changed requirements fell out of the thread
- A closure sequence ordering the trace repairs against submittal
Who uses the output
- Compliance managers confirming the requirement threads hold end to end before submittal
- Certification leads deciding which broken links must close first
- Engineering owners capturing derived requirements that never reached the baseline
How the work fits into the transaction or program
Requirements traceability is the backbone every safety-relevant standard leans on, because it is how a project proves nothing in the design escaped a requirement and nothing in the requirements escaped verification. Reviewing it before submittal exposes the derived requirements and stale links that erode that proof, and the repaired trace it produces underpins the verification traceability and safety evidence built on top of it.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both expect bidirectional traceability under ARP4754B and the software and hardware standards, and their expectations for derived-requirement handling are close but their acceptance of trace tooling and evidence form is not. Where a project is certified under both, the review notes where the trace evidence needs to be presented differently to satisfy each authority.
Regulatory limits
The review confirms the traceability is complete and bidirectionally consistent. It does not author requirements, perform verification, or determine that the requirements are correct or that the design meets them.
What this review does not cover
- Writing or deriving requirements on the team's behalf
- Performing the verification that confirms a requirement
- Any determination that the requirements are complete or correct
Specific to this review
- Derived requirements are the classic escape point, because they originate in design decisions and can live entirely outside the baseline the trace is built from.
- A reworded requirement is more dangerous than a deleted one, because its downstream links survive and silently point at intent that no longer matches.
- Bidirectional consistency catches what one-way tracing misses: a design element implementing a requirement that the baseline no longer contains.
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 do derived requirements cause so many trace gaps?
Derived requirements come out of design and architecture decisions rather than from the parent requirements, so they can exist in the design without ever being written back into the baseline the trace matrix is generated from. That leaves a real design constraint with no verification obligation attached, which is precisely what the review looks for.
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.