Verification traceability
Verification-traceability review for certification evidence
A verification-traceability review checks whether every requirement traces forward to a verification method and to a result that actually substantiates the status claimed for it. It is for avionics and equipment suppliers whose certification data marks requirements verified by test, analysis, inspection, or review. The review reads the requirement set, the verification method assigned to each, and the test, analysis, and review records behind them, then checks that a passed status rests on a result run against the current baseline. You receive a verification status per requirement and a list of requirements verified by stale, missing, or method-mismatched evidence.
When this review is needed
- A program is closing out and the verified status of every requirement needs an independent read.
- Requirements or design changed and the verification results behind them may now be stale.
- A submittal claims requirements met by test or analysis and the evidence has to be confirmed.
- Findings question whether a requirement marked verified has a result behind it.
The problem
Verification status is recorded as a column in a matrix, and a status survives the result that earned it. A requirement is marked verified by a test that ran before the code or device changed, an analysis is cited that addresses an earlier requirement wording, and a verified status sits against a method the evidence never used. The matrix shows a clean wall of passed entries while the results behind them no longer match the current baseline.
What gets reviewed
- The requirement set and the verification method assigned to each requirement
- The forward trace from each requirement to its verification record
- Test results, analysis records, inspections, and review records cited as evidence
- Whether each result was run against the current requirement and design baseline
- The match between the planned verification method and the evidence produced
- The verification status and whether the evidence substantiates it
What gets validated
- Every requirement traces forward to a verification method and a result
- Each verified status rests on a result run against the current baseline
- The verification method used matches the method the plan assigned
- Each result postdates the requirement and design changes it covers
- Requirements verified by analysis cite an analysis addressing the current wording
- No requirement carries a verified status with no result behind it
- Open verification items are tracked rather than absorbed into a passed status
Evidence normally required
- The requirement set and the verification method assignments
- The forward verification trace or the matrix that holds it
- Test results, analysis records, and review records cited as evidence
- The baseline history for requirements and design
- Any open verification items the program is carrying
Common discrepancies
- A requirement marked verified by a test that predates a later design change
- A verified status against a method the cited evidence never used
- An analysis cited for a requirement whose wording has since changed
- Requirements showing a passed status with no result located behind them
- Open verification items quietly rolled into a verified status
- Evidence that addresses an earlier baseline than the one submitted
What is at stake
A verified status with no current result is a finding the package cannot defend at submittal, and confirming it can mean re-running the test or analysis on the frozen design. A method mismatch, where a requirement was to be verified by test but only analyzed, can reopen the verification plan. Each stale result a reviewer catches calls the rest of the status into question.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Trace forward
Follow each requirement to its assigned verification method and to the result cited for it.
Check currency
Confirm each result was run against the current requirement and design baseline.
Match the method
Compare the verification method used against the method the plan assigned and reconcile open items.
Report the status
Produce a verification status per requirement and a closure list ordered by re-verification cost.
What the buyer receives
- A verification status per requirement, confirmed or flagged
- A list of requirements verified by stale, missing, or method-mismatched evidence
- A method-coverage view comparing planned methods against evidence produced
- A prioritized closure list ordered by re-verification cost and review risk
Who uses the output
- Certification leads closing out the verification status before submittal
- Verification engineering teams re-running or re-citing flagged evidence
- Program management sequencing any re-verification against the schedule
How the work fits into the transaction or program
The review follows the trace forward from requirements into evidence, completing the picture a requirements-traceability review starts. It draws on the verification results the software and hardware lifecycle reviews examine and feeds the status a compliance matrix review reports.
Start with a single asset
Confirm requirements trace through verification.
Regulatory limits
Endeavor Elements reviews the applicant's verification trace and evidence for currency and consistency. It does not witness the verification, make compliance findings, or guarantee that the verified status will be accepted.
What this review does not cover
- Witnessing or performing the verification activities
- Issuing any compliance finding or approval
- Producing the missing or re-run verification evidence
Specific to this review
- A verification status is a claim and the result is the substantiation, and the two come apart when design changes after the result, so currency against the baseline is the central check.
- Verification methods are planned per requirement, and a requirement to be verified by test that was only analyzed is a method mismatch, distinct from a stale result.
- Analysis evidence is tied to a requirement wording, so a wording change can leave an otherwise sound analysis verifying a requirement that no longer exists.
- Open verification items can be absorbed into a passed status without a trace, which is why the review reconciles open items against the status rather than reading the status alone.
Sources
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).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
Frequently asked questions
How does this relate to a requirements-traceability review?
A requirements-traceability review checks the trace among requirements, parent to child. This review follows requirements forward to the verification evidence and confirms the result substantiates the status claimed.
Do you re-run the verification?
No. The review confirms whether existing results substantiate the verified status against the current baseline. Any re-test or re-analysis it identifies is performed under the applicant's verification arrangements.
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.
Walk through your situation with an engineer who has done this work.