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.
Document control
| 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
| 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
1. Purpose and scope
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
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
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
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
| 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
| 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
| 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
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
- V&V records the anomaly with evidence and proposed class.
- The developer analyses and proposes a resolution within [5] working days.
- The CCB approves the resolution or deferral; V&V may record dissent.
- V&V verifies the fix and performs regression analysis for affected items.
- 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
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
| 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
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.
12. Glossary and references
| 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.