Requirements traceability
Requirements traceability review for qualification test teams
A requirements traceability review confirms that the links from certification requirements down through design and up through verification hold without a break. It is run for a qualification test team before a submittal, a finding response, or a design change review reopens the trace. The reviewer follows requirements into the design that implements them and into the verification that closes them, then hunts the places where derived or changed requirements never made it into the chain. You receive a gap list of broken and orphaned links, a trace map, and the order to close them in.
When this review is needed
- The trace has grown across several requirement baselines and no one has walked it end to end.
- A finding asked the team to show how a specific requirement flows to verification.
- A design change spawned derived requirements that may not have been threaded back in.
- Requirements were reallocated between hardware and software and the links have to follow.
The problem
Traceability tools report a link count, not whether the links mean anything. A requirement can trace to a design element that no longer implements it, or a derived requirement can appear during design and never trace back up to the parent that justifies it. The matrix shows green while the actual chain has a hole in it, and the hole only becomes visible when someone reads the requirement text at both ends of a link instead of trusting the identifier.
What gets reviewed
- Certification requirements traced down into the design elements that implement them
- Design and derived requirements traced back to a justified parent
- Verification objectives traced to the requirements they are meant to close
- Links checked at both ends by reading the requirement text rather than trusting the identifier
- Requirements reallocated across hardware and software confirmed to still trace
- Changed and added requirements from the latest baseline confirmed present in the trace
What gets validated
- Each requirement resolves to at least one design element that actually implements it
- Every derived requirement traces up to a parent or a documented rationale
- No verification objective is left with no requirement behind it
- A trace link survives reading the text at both ends, beyond matching the number
- The current requirement baseline matches the population in the trace matrix
Evidence normally required
- The requirements baseline and the trace matrix or tool export
- Design data showing how requirements are allocated and implemented
- The verification plan and the objectives it maps to requirements
- The change record for requirements added or reallocated since the last baseline
- The certification basis the top-level requirements derive from
Common discrepancies
- A derived requirement with no parent and no recorded rationale
- A trace link whose two ends describe different requirements once read in full
- A requirement that traces to design but has no verification behind it
- Reallocated requirements whose links stayed with the old owner
What is at stake
A broken trace surfaces as a finding that forces the team to reconstruct the chain under review pressure, often reopening design decisions that were considered settled. Derived requirements with no parent are the classic snag: the authority asks what drove them, and the team has no answer that traces to the certification basis. That reopens the whole allocation question late, when it is most expensive.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Fix the requirement baseline
Confirm the trace matrix reflects the current requirements population, including recent changes and reallocations.
Read links at both ends
Walk each trace link and read the requirement text on both sides rather than trusting the identifier.
Hunt the orphans
Find derived requirements with no parent and verification objectives with no requirement.
Order the repairs
Rank the broken links by how much downstream verification they block.
What the buyer receives
- A gap list of broken, orphaned, and missing trace links
- A trace map showing requirement flow through design and verification
- A closure order ranking gaps by the verification work they hold up
Who uses the output
- Test leadership sizing the trace repair before the data ships
- Certification leadership showing an authority how a requirement flows to closure
- Engineering leads reattaching derived requirements to their parents
How the work fits into the transaction or program
Requirements trace is the spine the verification and lifecycle data reviews rely on. If a requirement has no honest link to design, no downstream evidence can close it, so this review usually runs early and feeds the verification-trace pass that follows. Gaps found here define which requirements the later evidence reviews must confirm are covered.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
ARP4754B, DO-178C, and DO-254 each expect traceability, but they scope it differently across the system, software, and hardware levels. On a program validated by both the FAA and EASA, the review confirms the trace holds at each level and notes where an authority expects the parent-child rationale to be shown explicitly rather than implied.
Regulatory limits
The review verifies that the trace is complete and coherent. It does not judge whether a requirement is correct, approve the verification approach, or determine compliance. Whether the traced evidence satisfies the requirement remains an authority decision.
What this review does not cover
- Writing or correcting requirements or design data
- Performing the verification that a requirement is missing
- Any compliance determination on the requirement set
Specific to this review
- A link count from a trace tool proves nothing about meaning; the defect lives in links whose two ends no longer describe the same requirement.
- Derived requirements are the usual orphan, because they are born in design and it is easy to forget to thread them back to a parent.
- Reallocation between hardware and software leaves stale links pointing at the previous owner, so a reallocated requirement is checked on both sides.
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
Our trace tool already reports full coverage. What does this add?
Tool coverage confirms that links exist, not that they are true. This review reads the requirement text at both ends of a sample of links and chases the orphans a coverage report cannot see, such as a derived requirement with no parent. That is where findings come from.
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.