Requirements traceability
Requirements traceability evidence review for equipment suppliers
This review follows a supplier's requirements traceability from the top-level requirement set down through design and into verification, and back up again. It confirms that each requirement lands in design, that verification exists for it, and that nothing has fallen out of the chain when requirements were derived, allocated, or changed. It is carried out by an engineer fluent in ARP4754B and the software and hardware assurance standards, ahead of a submittal or in answer to a finding about trace completeness. You receive a gap list of broken or one-directional links, an evidence map tying requirement to verification, and a closure order for engineering leadership.
When this review is needed
- The requirement set has churned through several revisions and no one has confirmed the trace kept pace with the changes.
- A finding challenges whether every high-level requirement decomposes cleanly into lower-level ones with no orphans.
- Software and hardware were developed by separate teams and the allocated requirements at the boundary need to reconcile.
- A submittal date is close and the trace matrix has never been read against the actual design and test artifacts.
The problem
Requirements traceability tools happily report a link count that looks healthy, but the count says nothing about whether the links point at the right objects or point in both directions. Derived requirements slip in during design and never trace up. High-level requirements get refined and their children are left pointing at a superseded parent. The matrix looks dense and still hides orphans on both ends.
What gets reviewed
- Downward trace from each high-level requirement into the design that implements it
- Upward trace from every derived and low-level requirement to a parent or a documented rationale
- Reconciliation of requirements allocated across the software and hardware boundary
- Trace from requirements into the verification that exercises them
- Check that requirement changes propagated to every child and every linked verification case
- Review of how orphaned and deleted requirements were handled across revisions
What gets validated
- Every high-level requirement decomposes into lower-level requirements or is marked as directly verified
- Each derived requirement has either a parent or a recorded rationale for existing without one
- Requirements allocated to software and to hardware meet consistently at the interface
- The trace resolves in both directions with no link pointing at a deleted or superseded object
- A change to any requirement is reflected in its children and in the verification tied to it
Evidence normally required
- The full requirement set with high-level, low-level, and derived requirements identified
- The design description or architecture the requirements are allocated into
- The existing traceability matrix or tool export in its current revision
- The verification cases or procedures and their mapping to requirements
- A change history showing how requirements moved across recent revisions
Common discrepancies
- Derived requirements that trace down into design but never trace up to a rationale
- Child requirements still linked to a parent that a later revision rewrote
- Interface requirements that read differently on the software side than on the hardware side
- Requirements marked verified whose linked verification case addresses a different behavior
What is at stake
A trace with silent breaks invites a reviewer to pull the thread that unravels furthest. One orphaned derived requirement raises the question of how many others exist, and answering it under review pressure means re-walking the whole trace at the worst possible time. Left unresolved, a broken trace becomes an open finding that holds the certification.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Fix the endpoints
Establish the current requirement set, design allocation, and verification objects so links can be walked against real targets.
Walk both directions
Trace top-down into design and bottom-up to parents or rationales, marking every orphan and broken link.
Reconcile the boundary
Compare requirements allocated to software against those allocated to hardware and record where they disagree.
Order the repairs
Group the gaps by requirement branch so fixes proceed in a way that does not reopen links already checked.
What the buyer receives
- A gap list of broken, orphaned, and one-directional links with the object at each end
- An evidence map tying each requirement to its design allocation and verification
- A closure order grouping fixes by the requirement branch they sit under
Who uses the output
- Engineering leadership scoping the rework needed before the trace is submittable
- Certification leads presenting a defensible trace argument to the authority
- Requirements owners repairing links inside the traceability tool
How the work fits into the transaction or program
Traceability is the connective tissue between the compliance map above it and the verification evidence below it. This review assumes the compliance map has assigned methods and checks that the requirements behind those methods actually reach design and test, handing the verification trace review a clean set of endpoints to confirm.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
ARP4754B frames traceability at the aircraft and system level, while DO-178C and DO-254 impose their own bidirectional trace expectations at the software and hardware item level. FAA and EASA both look for these to knit together at the allocation boundary, and this review checks the seam where a system requirement becomes a software or hardware requirement.
Regulatory limits
The review evaluates the internal consistency of the supplier's trace. It issues no airworthiness determination, approves no data, and does not certify that the trace satisfies a specific regulation. Acceptance of the traceability evidence rests with the authority and its delegates.
What this review does not cover
- Authoring the missing requirements, rationales, or verification cases
- Repairing links inside the supplier's requirements management tool
- Judging the technical adequacy of the design the requirements describe
Specific to this review
- A dense link count is a poor proxy for trace health, because a matrix can be fully populated and still point half its links at superseded objects.
- Derived requirements are the trace's blind spot: they are born in design with no parent, so an unwritten rationale leaves them stranded at the top of the chain.
- The software-to-hardware allocation boundary is where two well-kept traces most often disagree, since each team maintains its own and neither owns the seam.
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 tool reports full traceability. Why review it separately?
A tool confirms that links exist, not that they point at the right objects or resolve in both directions. This review reads what each link connects, catches derived requirements with no upward trace, and finds children still tied to a rewritten parent, which a link count will report as healthy.
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.