Verification traceability
Verification-trace evidence review for software assurance teams
This review checks that the verification credited to each software requirement actually exists and is the right kind, so a requirement marked complete is backed by evidence, not just a status. It runs before a submittal, during a finding response, or after a change alters what was verified, and it is done by or with the software assurance team that owns the verification data. The work follows each requirement to its test, analysis, inspection, or review evidence and confirms the evidence covers the requirement and passed. It flags every requirement marked verified whose evidence is missing, partial, or inconclusive. You receive a gap list, an evidence map linking requirements to their verification results, and a closure sequence for software assurance leadership.
When this review is needed
- A verification dataset is going to the authority and the team wants each verified requirement backed by evidence first.
- A finding questions whether a requirement marked complete actually has passing verification behind it.
- A change re-ran some verification and the trace has not caught up to which results are now current.
- Verification was performed by several methods across teams and the coverage has never been checked as a whole.
The problem
Verification status is a checkbox that outruns its evidence. A requirement gets marked verified when the test is expected to pass, when an analysis is drafted, when a review is scheduled, and the status sticks even if the evidence never fully lands. Test cases cover part of a requirement and leave an edge unexercised, an analysis reaches a conditional result, a review record exists but does not address the requirement it is credited to. The verification matrix shows green while the evidence behind a cell is thin, partial, or simply absent.
What gets reviewed
- Each verified requirement traced to the specific test, analysis, inspection, or review that covers it
- The cited verification evidence checked for a passing, conclusive result rather than a pending or conditional one
- Coverage checked so the evidence exercises the whole requirement, not a subset of its behavior
- The verification method checked as appropriate to the requirement and the software level
- Re-verified requirements checked so the current result, not a superseded run, backs the status
- Verification references checked against the certification basis and the applicable software level
What gets validated
- Every requirement marked verified links to verification evidence that exists and is retrievable
- The cited evidence records a passing, conclusive result with no unresolved condition
- The verification exercises the full requirement, including its boundary and error behavior where applicable
- The method used suits the requirement type and the objectives for the software level
- Where verification was re-run, the current passing result is the one the status reflects
Evidence normally required
- The verification traceability data linking requirements to results
- The test, analysis, inspection, and review evidence at its current revision
- The requirement set the verification is credited against
- The change history covering re-run or superseded verification
- The certification basis and applicable software level
Common discrepancies
- A requirement marked verified whose test evidence covers only part of its stated behavior
- An analysis credited as verification that reached a conditional result never resolved
- A review record credited to a requirement it does not actually address
- A status that reflects a superseded verification run rather than the current one after a change
What is at stake
A requirement marked verified without passing evidence is an assertion an authority can puncture by asking for the result. When the evidence turns out partial or missing, the verification has to be completed or re-run, and if the software changed since, the whole activity may repeat. A pattern of overstated status invites the authority to sample deeper, turning a few thin cells into a broad reopening of the verification argument.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Trace each verified mark
Follow every requirement marked verified to the specific evidence credited with it.
Read the result
Confirm the evidence records a passing, conclusive result and exercises the whole requirement.
Check currency and method
Verify the current run backs the status and the method suits the requirement and level.
List and order the gaps
Record each thin or absent verification and sequence re-runs by dependency and software impact.
What the buyer receives
- A gap list naming each verified requirement whose evidence is missing, partial, or inconclusive
- An evidence map linking each requirement to its verification result and coverage state
- A closure sequence ordered so re-verification is scheduled by dependency and software impact
Who uses the output
- Software assurance leadership confirming verification status is backed before submittal
- Assurance engineers completing or re-running the verification flagged as thin or absent
- Certification leadership judging whether the verification argument holds or needs a coverage pass
How the work fits into the transaction or program
The review runs on the verification data after activities are performed but before the status is offered as proof the requirements are met. It confirms each verified mark rests on complete, passing evidence, and its gap list drives the completion and re-runs the verification argument needs to stand.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both expect verification coverage consistent with DO-178C objectives, and for higher software levels both look closely at structural coverage and the resolution of coverage gaps. The review notes where verification acceptable to one authority needs additional coverage analysis or justification to satisfy the other.
Regulatory limits
The review checks that verification evidence exists, passes, and covers the requirement. It does not perform verification, accept the verification results, or make a compliance finding. Those acts rest with the applicant's authorized representatives and the authority.
What this review does not cover
- Performing or re-running the tests, analyses, inspections, or reviews
- Accepting the verification results or making a compliance finding
- Resolving structural coverage gaps on the applicant's behalf
Specific to this review
- Verification status is the most over-reported field in a software package, because a mark is fast to set and slow to fully back.
- Partial coverage is more dangerous than a missing test, because the requirement reads as verified while an edge of its behavior was never exercised.
- A re-run after a change can leave two results on file, and the status often points at the older passing run rather than the current one.
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
Isn't a verified status enough if our process set it?
A status records that someone judged the requirement verified; it does not, by itself, show the evidence covers the requirement and passed. The review reads the evidence behind the status, which is exactly what an authority does when it samples.
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.