# Verification and Validation Plan: [System or software name]

> Complete Verification and Validation (V&V) Plan. The structure follows
> the V&V plan concepts of IEEE 1012-2016: V&V overview, integrity levels,
> V&V processes and tasks across the life cycle, minimum tasks by integrity
> level, independence, reporting, anomaly resolution, administrative
> procedures, documentation and schedule. Replace every `[bracketed]`
> value and every row marked *Example*.

<!--
Guidance: How to use this template
- Verification asks "did we build the product right?" (does each work product
  meet the requirements of the previous step). Validation asks "did we build
  the right product?" (does it meet the user's intended use).
- Assign integrity levels first (section 2). The level of each component
  decides how many V&V tasks it gets and how independent they must be.
- The integrity scheme below is an example written for this template. If your
  domain has its own scheme (safety standard, contract), use that and map it here.
- Plan tasks per life-cycle activity, then check that every task has an output
  and a place in the schedule.
-->

## Document control

<!-- Guidance: Identify the plan. For independent V&V, note the V&V organisation and the contracting party. -->

| Field | Value |
|---|---|
| Document ID | [VVP-SYSTEM-001] |
| System / software | [System name] [version or increment] |
| V&V organisation | [Internal V&V team / independent V&V contractor name] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@vv-lead] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Related documents | [Project management plan], [SQA plan], [Test strategy], [Hazard or risk analysis], [SRS] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| V&V lead | [@name] | [Approved / Rejected / Approved with comments] | YYYY-MM-DD |
| Project manager | [@name] | [Decision] | YYYY-MM-DD |
| System safety or risk owner | [@name] | [Decision] | YYYY-MM-DD |
| Acquirer / customer | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: One row per approved version. Re-issue when integrity levels or scope change. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial draft |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Raised dosing calculation module to integrity level 4 after hazard review |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved at system requirements review |

## Contents

<!-- Guidance: Keep in sync with headings. -->

1. [Purpose and scope](#1-purpose-and-scope)
2. [Integrity levels](#2-integrity-levels)
3. [V&V overview](#3-vv-overview)
4. [V&V processes and tasks by life-cycle phase](#4-vv-processes-and-tasks-by-life-cycle-phase)
5. [Minimum V&V tasks by integrity level](#5-minimum-vv-tasks-by-integrity-level)
6. [Independence](#6-independence)
7. [V&V reporting](#7-vv-reporting)
8. [Anomaly resolution and reporting](#8-anomaly-resolution-and-reporting)
9. [Administrative procedures](#9-administrative-procedures)
10. [V&V documentation requirements](#10-vv-documentation-requirements)
11. [Schedule](#11-schedule)
12. [Glossary and references](#12-glossary-and-references)

## 1. Purpose and scope

<!-- Guidance: State the system, its intended use and what V&V covers: which components, which life-cycle phases, which work products. -->

### 1.1 Purpose

This plan defines the verification and validation effort for [system
name], so that the acquirer, the developer and [regulator, if any] can
rely on objective evidence that the software meets its requirements and
its intended use at the assurance level its integrity requires.

### 1.2 System and intended use

[System name] is a [type of system] used by [users] to [intended use].
Failure could [describe the worst credible consequence, for example
"delay medication delivery to patients" or "misreport account balances"].

### 1.3 Scope of V&V

| Aspect | In scope | Out of scope |
|---|---|---|
| Software components | [List components in section 2.3] | [Commercial operating system, used as-is and covered by vendor evidence] |
| Life-cycle phases | Concept, requirements, design, implementation, test, installation and checkout | Operation and maintenance after acceptance (separate plan) |
| Hardware | Interfaces to [devices] | Hardware qualification |
| Work products | Requirements, design, code, test documentation, user documentation | Marketing material |

## 2. Integrity levels

<!-- Guidance: An integrity level expresses how much the system depends on a component being correct. Assign a level per component from consequence and likelihood of failure. Record the rationale; levels drive cost. -->

### 2.1 Integrity level scheme

This plan uses four integrity levels, from 4 (highest assurance needed) to
1 (lowest). The level is chosen from the worst credible consequence of a
component failure and the likelihood that a failure leads to that
consequence.

| Consequence category | Definition used in this plan |
|---|---|
| Severe | Death or serious injury, major environmental harm, or loss exceeding [amount] |
| Major | Injury requiring treatment, regulatory breach, or loss between [amount] and [amount] |
| Moderate | Service disruption over [4 hours], recoverable data error, or loss below [amount] |
| Minor | Inconvenience with easy workaround, no lasting effect |

| Likelihood category | Definition used in this plan |
|---|---|
| Likely | Expected to occur at least once in the operating life of the system |
| Possible | Could occur a few times across the installed base |
| Unlikely | Not expected, but conceivable |
| Rare | Only under a combination of independent failures |

### 2.2 Integrity level matrix

| Consequence / likelihood | Likely | Possible | Unlikely | Rare |
|---|---|---|---|---|
| **Severe** | 4 | 4 | 3 | 3 |
| **Major** | 4 | 3 | 3 | 2 |
| **Moderate** | 3 | 2 | 2 | 1 |
| **Minor** | 2 | 1 | 1 | 1 |

The system integrity level is the highest level of any of its components,
unless architectural partitioning is shown to isolate lower-level
components.

### 2.3 Integrity level assignments

| Component | Function | Worst consequence | Likelihood | Integrity level | Rationale |
|---|---|---|---|---|---|
| *Example:* Dose calculation | Computes infusion rate from prescription | Severe | Possible | 4 | Wrong rate can harm patient; no independent check downstream |
| *Example:* Alarm manager | Raises occlusion and empty-bag alarms | Severe | Unlikely | 3 | Hardware alarm exists as secondary barrier |
| *Example:* Audit log | Records user actions | Moderate | Possible | 2 | Needed for investigation, not for safe operation |
| *Example:* Report export | Produces PDF reports | Minor | Possible | 1 | No operational dependency |
| [Component] | [Function] | [Category] | [Category] | [1-4] | [Rationale] |

## 3. V&V overview

<!-- Guidance: Describe the V&V organisation, the master schedule, resources and the techniques V&V will use. -->

### 3.1 Organisation

The V&V team reports to [head of quality / acquirer program office] and is
separate from the development team. It interfaces with the project through
the V&V lead, who attends [technical reviews and change control board] as a
non-voting member with the right to record dissent.

### 3.2 Resources

| Resource | Quantity | Notes |
|---|---|---|
| V&V lead | 1 (50%) | Plans, reports, escalates |
| V&V engineers | [2] | Analysis, test witnessing, independent tests |
| Tools | [Static analyser, requirements tool, test harness] | Qualified for integrity level 4 use where required |
| Test facilities | [Hardware-in-the-loop rig] | Shared with development, booked per schedule |

### 3.3 Techniques

| Technique | Purpose | Used for levels |
|---|---|---|
| Traceability analysis | Show each requirement flows to design, code and tests | All |
| Interface analysis | Check consistency of data and control across interfaces | 2-4 |
| Hazard analysis support | Confirm software contributions to hazards are controlled | 3-4 |
| Criticality analysis | Confirm integrity levels remain valid after change | 3-4 |
| Code inspection and static analysis | Find defects before test | 2-4 (inspection 3-4) |
| Independent testing | Tests designed and run by V&V | 3-4 |
| Test witnessing | Observe developer tests | 2-4 |

### 3.4 V&V objectives

- Find defects as early in the life cycle as possible.
- Provide evidence that each requirement is correct, complete and testable, and that the software satisfies it.
- Provide evidence that the software is fit for its intended use in its operational environment.
- Give management an independent view of product quality and risk at each milestone.

## 4. V&V processes and tasks by life-cycle phase

<!-- Guidance: For each phase, list the V&V tasks, their inputs and outputs. Keep task names consistent with section 5 so the minimum-task matrix can be checked. -->

### 4.1 Concept

| Task | Inputs | Outputs |
|---|---|---|
| Concept documentation evaluation | ConOps, system requirements | Concept evaluation report |
| Criticality analysis (initial) | Concept, hazard list | Initial integrity level assignment |
| Hazard analysis support | Preliminary hazard analysis | Software hazard contributions list |
| Risk analysis | Project risk register | V&V risk inputs |

### 4.2 Requirements

| Task | Inputs | Outputs |
|---|---|---|
| Traceability analysis (system to software requirements) | SyRS, SRS | Trace report |
| Software requirements evaluation | SRS | Requirements evaluation report: correctness, consistency, testability |
| Interface analysis | Interface requirements | Interface analysis report |
| Validation test planning | SRS, ConOps | Draft acceptance and system test plans |

### 4.3 Design

| Task | Inputs | Outputs |
|---|---|---|
| Traceability analysis (requirements to design) | SRS, design | Trace report |
| Design evaluation | Architecture and detailed design | Design evaluation report |
| Interface analysis | Interface design | Interface analysis report |
| Component and integration test design | Design | Test designs |
| Criticality analysis update | Design | Updated integrity levels |

### 4.4 Implementation

| Task | Inputs | Outputs |
|---|---|---|
| Traceability analysis (design to code) | Design, source | Trace report |
| Source code evaluation | Source, coding standard | Code evaluation report |
| Static analysis review | Analyser results | Findings list |
| Component test execution or witnessing | Component tests | Component test report |

### 4.5 Test

| Task | Inputs | Outputs |
|---|---|---|
| Integration test execution or witnessing | Integration procedures | Integration test report |
| System test execution or witnessing | System procedures | System test report |
| Acceptance test support | Acceptance procedures | Acceptance test report |
| Traceability analysis (requirements to test results) | Trace matrix, results | Final trace report |

### 4.6 Installation and checkout

| Task | Inputs | Outputs |
|---|---|---|
| Installation configuration audit | Release package, installation guide | Installation audit report |
| Installation checkout | Site installation | Checkout report |
| V&V final report | All V&V outputs | V&V final report |

## 5. Minimum V&V tasks by integrity level

<!-- Guidance: The matrix shows which tasks are mandatory at each level. "R" = required, "O" = optional (at V&V lead's judgement), "-" = not required. Adjust to your scheme and explain changes. -->

| Task | Level 1 | Level 2 | Level 3 | Level 4 |
|---|---|---|---|---|
| Traceability analysis | O | R | R | R |
| Requirements evaluation | O | R | R | R |
| Interface analysis | - | O | R | R |
| Criticality analysis | - | O | R | R |
| Hazard analysis support | - | - | R | R |
| Design evaluation | - | O | R | R |
| Source code evaluation (sampled) | - | O | R | - |
| Source code evaluation (complete) | - | - | O | R |
| Static analysis review | O | R | R | R |
| Independent test design and execution | - | - | O | R |
| Test witnessing | - | O | R | R |
| Installation configuration audit | O | O | R | R |
| Regression analysis after change | O | R | R | R |

Coverage targets by level: [Level 4: 100% statement and decision coverage,
MC/DC for decision logic; Level 3: 100% decision coverage; Level 2: 80%
statement coverage; Level 1: no target].

## 6. Independence

<!-- Guidance: State how independent V&V is from development in three dimensions. Higher integrity levels need more independence. -->

| Dimension | Arrangement | Applies to levels |
|---|---|---|
| Technical | V&V staff design their own analyses and tests; they do not author development products | 3-4 fully; 1-2 peer verification allowed |
| Managerial | V&V lead reports to [head of quality / acquirer], not to the project manager; V&V decides its own priorities | 3-4 |
| Financial | V&V budget is held separately and cannot be reallocated by the project | 4 |

Any exception to these arrangements is recorded in section 9.4 with the
compensating measure.

## 7. V&V reporting

<!-- Guidance: Define what V&V reports, to whom and when. Reports must show findings and their status, not only activity. -->

| Report | Content | Frequency | Recipients |
|---|---|---|---|
| Task report | Results of one V&V task: scope, method, findings, conclusion | Per task | Project manager, technical lead |
| Phase summary report | Tasks done in the phase, anomalies, assessment of quality, recommendation to proceed | End of each phase | Project manager, acquirer |
| Anomaly report | One anomaly with classification and status | As found | Developer, CCB |
| V&V final report | Summary of all V&V, residual anomalies, overall assessment, recommendation | At completion | Acquirer, management, [regulator] |
| Special studies | Investigation of a specific concern | On request | Requester |

## 8. Anomaly resolution and reporting

<!-- Guidance: Define how anomalies found by V&V are classified, tracked and closed, and who decides when developers disagree. -->

### 8.1 Anomaly classification

| Class | Meaning | Required action |
|---|---|---|
| A: Blocking | Prevents a phase exit; violates a requirement at integrity level 3-4 | Must be resolved before phase exit |
| B: Significant | Requirement not met at level 1-2, or design weakness with credible effect | Resolved or formally deferred by CCB |
| C: Minor | Documentation or style issue with no functional effect | Resolved at developer's discretion |

### 8.2 Process

1. V&V records the anomaly with evidence and proposed class.
2. The developer analyses and proposes a resolution within [5] working days.
3. The CCB approves the resolution or deferral; V&V may record dissent.
4. V&V verifies the fix and performs regression analysis for affected items.
5. The anomaly is closed and appears in the phase summary report.

| ID | Phase | Component | Level | Description | Class | Status | Closed |
|---|---|---|---|---|---|---|---|
| ANOM-001 | *Example:* Requirements | Dose calculation | 4 | SRS-FR-044 does not define behaviour when weight is missing | A | Resolved, SRS v1.3 | YYYY-MM-DD |
| [ANOM-nnn] | [Phase] | [Component] | [Level] | [Description] | [A / B / C] | [Status] | YYYY-MM-DD |

## 9. Administrative procedures

<!-- Guidance: Cover the practical rules: task iteration after change, deviations from this plan, control of V&V records, standards used. -->

### 9.1 Task iteration policy

A change to a baselined product triggers regression analysis. V&V repeats
the tasks for that product if the change affects a component at level 3
or 4, changes an interface, or alters a hazard control.

### 9.2 Deviation policy

Deviations from this plan are requested in writing by the V&V lead or the
project, assessed for effect on assurance, and approved by [the acquirer
and the head of quality].

### 9.3 Control procedures

V&V records are configuration items under the SCM plan. They are stored
in [location], protected from modification after approval, and retained
for [product life plus regulatory period].

### 9.4 Standards, practices and conventions

[List the standards V&V uses to evaluate products: SRS template, coding
standard, test documentation standard, safety standard.]

## 10. V&V documentation requirements

<!-- Guidance: List the development documents V&V needs as inputs, with the date V&V needs them. Late inputs are the most common cause of compressed V&V. -->

| Document needed | From | Needed by | Purpose |
|---|---|---|---|
| Concept of operations | Systems engineering | YYYY-MM-DD | Concept evaluation, validation basis |
| Software requirements specification | Requirements lead | YYYY-MM-DD | Requirements evaluation, test planning |
| Architecture and design descriptions | Architect | YYYY-MM-DD | Design evaluation |
| Source code and build instructions | Development | Continuous | Code evaluation |
| Developer test plans and results | Test manager | Per test phase | Witnessing and evaluation |
| Hazard analysis | Safety engineer | YYYY-MM-DD | Hazard analysis support |
| Installation guide | Documentation | YYYY-MM-DD | Installation audit |

## 11. Schedule

<!-- Guidance: Align V&V tasks with project milestones. V&V of a phase must finish before the phase exit review. -->

V&V work starts with the concept phase and continues through installation
checkout; each phase ends with a V&V phase summary report before the
corresponding milestone review.

```mermaid
gantt
  title V&V schedule
  dateFormat YYYY-MM-DD
  section Development milestones
  System requirements review :milestone, m1, 2026-02-15, 0d
  Design review              :milestone, m2, 2026-04-30, 0d
  Test readiness review      :milestone, m3, 2026-08-15, 0d
  Acceptance                 :milestone, m4, 2026-10-30, 0d
  section V&V tasks
  Concept and requirements V&V :v1, 2026-01-05, 40d
  Design V&V                   :v2, after v1, 60d
  Implementation V&V           :v3, after v2, 90d
  Test V&V and witnessing      :v4, after v3, 60d
  Installation checkout        :v5, after v4, 15d
```

## 12. Glossary and references

<!-- Guidance: Define terms and list referenced documents. -->

| Term | Meaning |
|---|---|
| Verification | Confirming that a work product meets the requirements set for it by the previous activity |
| Validation | Confirming that the product meets its intended use and user needs |
| Integrity level | A value showing how much assurance a component needs, based on consequence and likelihood of failure |
| Anomaly | Any condition that deviates from expectations based on requirements, standards or experience |
| MC/DC | Modified condition/decision coverage |

References: [ConOps], [SRS], [Hazard analysis], [SQA plan], [SCM plan],
IEEE 1012-2016, *IEEE Standard for System, Software, and Hardware
Verification and Validation*.

## Standard and licence note

Structure aligned with IEEE 1012-2016, *IEEE Standard for System,
Software, and Hardware Verification and Validation*, V&V plan concepts.
The integrity level scheme in section 2 is an original example written
for this template, not the scheme published in the standard. This
template is original text written for this collection and reproduces no
text from the standard; obtain the standard from IEEE for its normative
requirements. Template licence: MIT.