# 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).

```mermaid
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

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

## Related Notes

- [[Requirements-Engineering/Writing-Good-Requirements.md]] — Verifiable requirements
- [[Requirements-Engineering/Requirements-Analysis-Traceability.md]] — Traceability
- [[../SoftEngine/Testing/Test-Pyramid.md]] — Software testing strategies
- [[../AgenticEngineering/Evaluation/Eval-In-Production.md]] — Continuous eval for AI
- [[../AgenticEngineering/Evaluation/Agent-Benchmarks.md]] — 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