Data sheet Position on the V: Verify Revised
Verification & Validation
Requirements-based test development, structural coverage analysis and independent V&V team leadership, so the verification evidence closes before the authority samples it.
- Standards
- DO-178C
- Assurance
- Up to Design Assurance Level (DAL) A, modified condition/decision coverage (MC/DC) where the level requires it
- When to call us
- Before verification starts, or before Stage of Involvement (SOI) 3
- Delivery
- Mostly remote, on-site as needed
Scope
Every test has a reason, and every gap has an explanation.
We build test cases directly from requirements, so every verification activity has a clear, defensible link back to what the system is supposed to do. We measure structural coverage (statement, decision and MC/DC, modified condition/decision coverage, where the DAL requires it) to close the gap between requirements-based testing and the code as written, and we analyse what the number does not cover rather than reporting the number alone.
For programs that need demonstrable independence between development and verification, we stand up or lead independent V&V teams, embedded with your engineering organization or operating as a separate function reporting to program management. The work spans test automation and tooling selection, hardware-in-the-loop and test-cell campaigns, and flight-test support, always with the evidence organized and traceable rather than merely voluminous.
Deliverables
The evidence SOI 3 samples.
| Document | What it is | First reviewed |
|---|---|---|
| SVP | Software Verification Plan: reviews, analyses, tests, independence and coverage resolution | SOI 1 |
| Test cases | Requirements-based cases, normal range and robustness, each traced to a requirement | SOI 3 |
| Test procedures | How each case is run, under configuration control and re-runnable | SOI 3 |
| Results | Verification results, with the independence the level requires | SOI 3 |
| Coverage | Structural coverage at the level's criterion, with every gap analysed | SOI 3 |
| Trace | Requirement to test case to result, and back from code to requirement | SOI 2 |
| Problem reports | Classified and dispositioned, read with the ship decision in mind | SOI 3 |
SOI: the authority's Stage of Involvement reviews.
From requirement to result
The thread the reviewer pulls.
A reviewer picks one requirement and follows it down to the result that shows it passed; a break anywhere becomes a finding. We build the chain in that order.
- 01 Cases from requirements Normal-range and robustness cases written from the requirement, never from the code.
- 02 Execution Automated where it pays, hardware-in-the-loop and test cell where it must, flight test when the program gets there.
- 03 Coverage Statement, decision or MC/DC, as the level demands, measured on the code as built.
- 04 Gap analysis Every uncovered construct explained: dead code, deactivated code or a missing test, each with its disposition.
Verification is not just testing
Four kinds of evidence.
- Reviews Requirements, design and code reviewed against a checklist, with records, not "in the meeting".
- Analyses Coverage, timing and the other analyses the objectives require, each with a conclusion, not only a measurement.
- Tests Requirements-based, normal and robustness, with results under configuration management.
- Independence Where the level requires it, staffed so the plan's promise is arithmetically possible.
Field notes