V-Model and V&V Planning

Verification and Validation (V&V) ensure we build the right system correctly. The V-Model is a classic SE approach that pairs development activities with corresponding verification/validation activities.

Verification vs Validation

This distinction is critical and often confused:

Aspect	Verification	Validation
Question	"Did we build it right?"	"Did we build the right thing?"
Focus	Conformance to specifications/requirements	Conformance to stakeholder needs and intended use
When	Throughout development (reviews, inspections, tests)	At end and often with stakeholders/users
Methods	Inspection, analysis, demonstration, test	Demonstration, test, user acceptance, operational evaluation
Basis	Requirements, design documents, standards	Stakeholder needs, CONOPS, use cases
Example	"Does the API return the correct schema?"	"Does this agent actually solve the support team's problem?"

The V-Model

The V-Model shows the relationship between decomposition (left side) and integration/verification (right side).

graph TD
    A[User/Stakeholder Needs] --> B[Stakeholder Requirements]
    B --> C[System Requirements]
    C --> D[Architecture Design]
    D --> E[Detailed Design]
    E --> F[Implementation]

    F --> G[Unit Test/Verification]
    G --> H[Integration Test]
    H --> I[System Test]
    I --> J[System Validation]
    J --> K[Acceptance/Operational Validation]

    B -.validates.-> K
    C -.verifies.-> J
    D -.verifies.-> I
    E -.verifies.-> H
    F -.verifies.-> G

    style A fill:#e1f5fe
    style K fill:#e8f5e9
    style G fill:#fff3e0

Development Levels and Corresponding V&V

Level	Development Activity	Verification Activity	Validation Activity
Stakeholder/Operational	Capture needs, CONOPS	Reviews of needs/CONOPS	User validation, operational testing
System	System requirements, architecture	System requirements verification, architecture reviews	System validation against stakeholder needs
Subsystem	Subsystem design/specs	Subsystem verification, interface testing	(usually verification-focused at this level)
Component/Unit	Detailed design, implementation	Unit tests, code reviews, inspections	N/A typically

Verification Methods in Detail

Method	Description	Example
Inspection	Static examination without execution	Code review, requirements review, design document review
Analysis	Theoretical/mathematical evaluation	Performance analysis, security analysis, traceability analysis
Demonstration	System operated to show it works as specified	Demo of agent tool use in sandbox
Test	Execution under controlled conditions with measured results	Unit tests, integration tests, load tests, eval suites

V&V Planning

A V&V plan should address:

Element	Content
Objectives	What V&V will achieve
Scope	What is in/out of scope
Responsibilities	Who does what (independent V&V vs developer V&V)
Methods	Which methods for each requirement
Test/Eval Environment	Where testing happens
Criteria	Pass/fail criteria
Traceability	Link requirements to verification activities
Resources/Schedule	Time, tools, people
Reporting	How results are documented

Traceability Matrix (V&V)

Req ID	Requirement	Verification Method	Test/Eval ID	Status	Notes
REQ-001	Agent shall authenticate via OAuth	Test	TEST-001	Pass	Integration test
REQ-002	Responses < 2s at p95	Test/Analysis	PERF-001	Pass	Load test results
REQ-003	Citations for RAG answers	Test/Demo	EVAL-001	Pass	LLM-as-judge eval
REQ-004	Refuse harmful requests	Test	SAFETY-001	Pass	Red team eval set

Applying to Software & Agentic Systems

The V-Model is often criticized for being rigid, but the principle holds. Modern approaches blend with agile:

Traditional SE	Agile/Modern Adaptation
Big bang validation at end	Continuous validation through user feedback, canary releases
Heavy documentation	Living documentation, ADRs, automated tests
Sequential V	Shift-left testing, TDD, continuous integration
Separate V&V team	Embedded quality, but still need independent perspective
Deterministic testing	Eval-driven development for AI (regression sets + LLM-as-judge)

For Agentic Systems

Verification: Unit tests for tools, schema validation, guardrail tests, trace inspection
Validation: End-to-end evals, human evaluation, red teaming, production sampling with evals
Key difference: Non-determinism means you need statistical evaluation, not just pass/fail

Reviews and Audits

Review Type	Purpose	When	Participants
Requirements Review	Validate requirements are correct/complete	After requirements	Stakeholders, SE, QA
Preliminary Design Review (PDR)	Review architecture meets requirements	After architecture	Cross-functional team
Critical Design Review (CDR)	Review detailed design ready for implementation	After detailed design	Engineering + stakeholders
Test Readiness Review (TRR)	Ready to test?	Before integration/system test	Test team, dev team
Acceptance Review	Stakeholder acceptance	Before transition to ops	Stakeholders, product owner

Best Practices

Plan V&V early - Don't wait until end; plan as you go
Trace everything - Every requirement should have verification/validation coverage
Use right methods - Don't over-test simple things, don't under-test critical ones
Test early and often - Shift-left; catch issues when cheap to fix
Independent perspective helps - Developer testing is necessary but not sufficient
For AI, measure distributions - Look at pass rates over eval sets, not single tests
Validate with real users - Dogfooding and beta testing catch what specs miss
Automate regression - Keep eval suites running as system evolves

Writing Good Requirements — Verifiable requirements
Requirements Analysis Traceability — Traceability
Test Pyramid — Software testing strategies
Eval In Production — Continuous eval for AI
Agent Benchmarks — Benchmarks

Sources

INCOSE Systems Engineering Handbook
NASA Systems Engineering Handbook
ISO/IEC/IEEE 15288
MIL-STD-1521 (historical)
IEEE 1012 - Standard for System and Software Verification and Validation
MITRE Systems Engineering Guide

From the Systems Engineering research vault · CC BY 4.0 · all notes · raw markdown