Requirements and verification trace
Closing STC requirements marked complete without verification evidence
This is a closure task for STC requirements that a data set records as satisfied while the verification proof behind them is missing. It is run for the modifier holding the program, usually after a self-audit or a reviewer comment shows requirements standing without a test, analysis, inspection, or review result. The work walks each affected requirement, decides which verification method it actually needs, and either locates the evidence or writes it up as an open action with a named owner. You get a closure brief per requirement, an evidence request list to send to the responsible authors, and a disposition package a reviewer can accept line by line.
When this review is needed
- A trace export shows requirements at a satisfied state with no linked verification record behind them.
- A reviewer asked to see the proof for a block of requirements and the authors cannot produce it on demand.
- A late requirement change added text that nobody carried into a verification method or result.
- The program is days from a data submittal and the verification column has silent holes.
The problem
A requirement set can read as complete while the proof is not there. Somebody marked the line satisfied during development, the verification activity was planned but never captured, and the tool kept showing green. The authors who ran the tests have moved to other work, so the evidence has to be recovered by memory and file archaeology rather than pulled from a maintained record. Every requirement in that state is a place where the story falls apart under a direct question.
What gets reviewed
- Every requirement recorded as satisfied but lacking a linked verification result
- The verification method each affected requirement actually calls for: test, analysis, inspection, or review
- Located evidence matched back to the requirement it is meant to prove
- Requirements with no recoverable proof restated as open actions with owners
- The trace corrected so the satisfied state reflects real evidence
What gets validated
- Each closed requirement points to a verification result that names the method and the artifact
- The verification method on file suits the requirement rather than the easiest activity to claim
- Recovered evidence covers the requirement as written, not an earlier or narrower version of it
- Requirements that stay open carry a named owner and a stated path to evidence
- No requirement is left in a satisfied state without a document a reviewer can open
Evidence normally required
- The requirements and verification trace export in its current state
- Test reports, analyses, inspection records, and review minutes held by the program
- The verification plan or cross-reference matrix if one exists
- Change history showing which requirements moved late in development
- Contact points for the engineers who ran the original verification activities
Common discrepancies
- A requirement satisfied against a test that was planned but never actually run
- Evidence that exists but proves an earlier revision of the requirement, not the current text
- A block of requirements closed by review with no record of the review having happened
- A late requirement change that was never assigned any verification method at all
What is at stake
A reviewer who finds one requirement satisfied without evidence stops trusting the whole column and starts sampling harder. That turns a targeted comment into a broad finding, and the modifier answers it during formal review instead of quietly beforehand. Requirements left unproven at issuance become a latent liability that resurfaces at the first amendment, when the data has to stand up again with even fewer of the original authors available.
Move from findings to resolution
Identify the missing data behind the finding.
How the work runs
Pull the satisfied-but-unproven set
Filter the trace to every requirement recorded as satisfied with no linked verification result.
Fix the method per requirement
Decide the verification method each one needs and check that any evidence on file matches it.
Recover or open the item
Locate the proof and link it, or restate the requirement as an open action with a named owner.
Assemble the disposition
Package each requirement's closure so a reviewer can accept it line by line.
What the buyer receives
- A closure brief per affected requirement stating method, evidence, and disposition
- An evidence request list routed to the authors who can supply the missing results
- A reviewer-ready disposition package that walks each requirement to its proof or its open action
Who uses the output
- Certification leads who need the verification column defensible before submittal
- Engineering owners assigned to run or recover the missing verification
- Program managers tracking which requirements still block the data package
How the work fits into the transaction or program
This work sits between requirement development and the formal data submittal, after the trace exists but before a reviewer relies on it. It feeds the compliance matrix that cites the verification results and clears the path for the finding-closure review that follows, so the submittal opens on evidence the modifier has already checked.
Start with a single asset
Confirm each requirement maps to substantiating evidence.
Jurisdiction-specific considerations
FAA and EASA both expect verification to be traceable to the requirement it proves, but the depth of evidence and the review posture differ by authority and by the design assurance level involved. The closure work notes where a requirement proven adequately for one authority needs a fuller record for the other so the same gap does not reopen on the second submission.
Regulatory limits
This work recovers and organizes verification evidence so a reviewer can evaluate it. It does not run new tests, make an airworthiness determination, approve the modification, or grant the STC. Whether the evidence is sufficient remains the authority's decision.
What this review does not cover
- Performing the missing test, analysis, or inspection activity itself
- Authoring new verification procedures or acceptance criteria
- Any determination that the modification is compliant or airworthy
Specific to this review
- A requirement can sit satisfied for months because the tool state and the actual evidence were never reconciled after the activity slipped.
- The most expensive miss is evidence that proves a superseded requirement text, because it reads as closure until someone compares revisions.
- Requirements closed by review are the hardest to defend, since a review with no minutes leaves nothing for a reviewer to open.
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
What happens to a requirement whose verification evidence cannot be found?
It is restated as an open action with the verification method it needs and an owner assigned to run or recover it. Carrying it openly is far stronger than leaving it marked satisfied, because a reviewer who finds one hollow closure starts doubting the rest of the column.
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.