TSO finding closure
Closing TSO requirements marked complete without verification evidence
This closes a specific defect in a TSO program: requirements that are marked complete but have no verification evidence standing behind them. An engineer reads the requirements and verification trace, isolates every requirement that claims closure without a supporting result, and works out what test, analysis, inspection, or review each one actually needs. It is run when the missing-verification problem threatens to reopen review cycles. You receive a closure brief, an evidence request list naming what has to be produced, and a reviewer-ready disposition for each affected requirement.
When this review is needed
- A verification audit shows requirements flagged closed with no linked test, analysis, or inspection result.
- A reviewer questioned a completion claim and the underlying evidence could not be produced.
- Software or hardware requirements at a given assurance level show closure without the objective evidence to match.
- A submission date is near and the trace has to hold before the authority reads it.
The problem
A requirement marked complete in a trace tool reads as closed to everyone downstream, whether or not a result sits behind it. On a TSO program the trace crosses ARP4754B system requirements, DO-178C software, and DO-254 hardware, and each domain closes requirements in its own tool. A requirement closed against a plan reference, an obsolete result, or nothing at all looks identical to a properly verified one until someone opens the link and finds it empty.
What gets reviewed
- Every requirement marked complete without a linked verification result identified
- Each affected requirement classified by what evidence it needs: test, analysis, inspection, or review
- ARP4754B, DO-178C, and DO-254 requirements checked at the assurance level assigned
- Closures made against plan references or superseded results separated from genuine ones
- A disposition path defined for each requirement so the trace can be closed properly
What gets validated
- Each closed requirement is either backed by a named result or flagged for evidence
- The evidence type assigned to a requirement fits its verification method rather than convenience
- Software and hardware requirements are verified to the objectives their DAL demands
- No requirement is closed against a plan or a result that predates the current build
- The disposition for each gap states exactly what has to be produced and by whom
Evidence normally required
- The requirements and verification trace as it stands
- The verification plans and any existing test, analysis, and inspection results
- The assigned DAL for software and hardware requirements
- The current configuration of the item under verification
Common discrepancies
- A requirement linked to a verification plan rather than an actual result
- A completion claim resting on a result run against a superseded build
- A software requirement closed below the objectives its DAL requires
- A requirement marked verified by inspection where analysis was the appropriate method
What is at stake
Requirements closed without verification are the finding an authority expands, because one empty link suggests others. What starts as a single questioned requirement becomes a full re-examination of the trace, and every cycle of that pulls engineers back onto work the program treated as done. Left in the package, the gap surfaces during review at the worst possible time and stalls the authorization.
Move from findings to resolution
Identify the missing data behind the finding.
How the work runs
Isolate the empty closures
Find every requirement marked complete with no linked verification result behind it.
Classify the need
Assign each gap the verification method it actually requires at its assurance level.
Separate the false closes
Split plan-reference and superseded-result closures from genuinely verified ones.
Disposition each gap
State what evidence must be produced so the trace can be closed and reviewed.
What the buyer receives
- A closure brief listing each requirement with missing verification and its disposition
- An evidence request list naming the test, analysis, or inspection each gap needs
- A reviewer-ready disposition package the authority can follow requirement by requirement
Who uses the output
- Certification leads answering an authority's questions on the verification trace
- Verification engineers who have to produce the missing results
- Program managers sequencing the evidence work against the submission date
How the work fits into the transaction or program
The work targets one defect inside a TSO program's verification trace and drives it to a defensible close before it spreads into repeat review. Its evidence request list feeds the verification team, and its disposition package feeds the compliance submission, so a questioned trace becomes a closed one the authority can follow.
Start with a single asset
Confirm each requirement maps to substantiating evidence.
Regulatory limits
The work identifies missing verification and defines how each requirement should be closed. It does not perform the verification, accept the resulting evidence on an authority's behalf, or make any airworthiness or authorization determination.
What this review does not cover
- Running the missing test, analysis, or inspection
- Rewriting the requirements or verification plans
- Any authorization or airworthiness decision on the item
Specific to this review
- A requirement linked to its verification plan rather than a result is the most common false close, because the trace tool shows a link and no one opens it.
- One empty verification link tends to trigger a broader audit, since an authority reasonably assumes it is not the only one.
- Closures made against a superseded build are harder to spot than empty links, because the result exists but no longer applies.
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
Do you generate the missing verification evidence?
No. The work pinpoints which requirements lack verification and defines what each one needs and why. Producing the test, analysis, or inspection result stays with the supplier's verification engineers, working from the evidence request list.
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.