Software verification and validation

Software verification and validation (software V&V) are complementary activities used to assess whether software work products conform to their specified requirements and whether the resulting software satisfies its intended use and user needs. Verification asks whether an artifact meets the requirements imposed on that artifact; validation asks whether the delivered system is suitable for its intended use. The distinction is useful, but terminology varies across standards and regulated domains, so a V&V plan should name the governing definitions rather than relying only on slogans. ^{[1] [2]}

Software V&V is broader than end-of-project testing. Current IEEE 1012 describes analysis, evaluation, review, inspection, assessment, and testing as V&V processes, and applies them to systems, software, hardware, interfaces, and related documentation. NASA likewise treats V&V as life-cycle work performed in parallel with development rather than as a final gate. ^{[1] [2]}

Verification evaluates a work product against the requirements, standards, or conditions that apply to it. The work product may be a requirements specification, architecture, design, source code, test procedure, built package, or operational change—not only an executable program. NASA’s handbook says verification solicits confirmation that work products properly reflect their specified requirements and includes multiple processes and techniques, not just testing. ^[2]

Typical verification questions include:

• Are requirements complete, consistent, traceable, and testable?
• Does the design implement the allocated requirements and interfaces?
• Does source code conform to the design, coding rules, and relevant safety or security constraints?
• Do test cases cover the identified requirements and expected boundary conditions?
• Does a release contain the approved versions and required documentation?

Reviews, inspections, static analysis, model checking, simulation, traceability analysis, and dynamic tests can all supply verification evidence. The appropriate method depends on the artifact and claim. A passing executable test cannot by itself verify that a missing requirement was captured, while a document inspection cannot establish runtime performance.

Validation evaluates whether the software, in its relevant system and operating context, fulfills intended use and user needs. This can expose a system that correctly implements an inadequate specification. IEEE 1012 states both sides explicitly: V&V determines conformity to activity requirements and whether the product satisfies intended use and user needs. ^[1]

Validation can include acceptance testing, operational scenarios, user evaluation, simulation, and assessment on representative hardware, data, interfaces, and environmental conditions. The FDA’s General Principles of Software Validation applies validation principles to medical-device software and to software used to design, develop, or manufacture medical devices; that regulated scope should not be generalized into a universal legal requirement for all software. ^[3]

The familiar shorthand—verification as “building the product right” and validation as “building the right product”—is a mnemonic, not a complete procedure. Both activities need explicit criteria, evidence, configuration identity, and documented limitations.

V&V can begin with concept and requirements work and continue through architecture, implementation, integration, deployment, operation, maintenance, and retirement. ISO/IEC/IEEE 12207:2026 establishes a common framework for software life-cycle processes spanning acquisition, supply, development, operation, maintenance, and disposal; it allows those processes to be applied concurrently, iteratively, recursively, and incrementally rather than requiring one development model. ^[4]

A practical life-cycle mapping is:

These columns overlap in practice. A system test may support both verification and validation if it is designed against specified requirements and executed in conditions representative of intended use. The important distinction is the claim each observation supports, not the label attached to the test.

A V&V plan should define the items under assessment, applicable requirements, methods, environments, responsibilities, independence, entry and exit criteria, expected results, anomaly handling, records, and configuration identifiers. NASA specifically requires planning of verification activities, methods, environments, and criteria, and notes that expected results may be numeric ranges, pass/fail conditions, or other stated satisfaction criteria. ^[2]

Traceability connects needs and requirements to design elements, implementation, hazards, tests, and results. Traceability does not prove correctness by itself: a matrix can be complete while the linked requirements or tests are weak. It is an index into the evidence and a way to find omissions, not a substitute for technical assessment.

A useful evidence record identifies:

• the exact item and version assessed;
• the requirement or intended-use criterion;
• the method, tool, environment, and relevant data;
• the expected and observed result;
• the reviewer or executing organization;
• anomalies, deviations, unresolved assumptions, and corrective action; and
• the scope of the resulting claim.

Evidence should be proportionate to risk, integrity level, change impact, and consequence of failure. IEEE 1012 specifies V&V life-cycle process requirements for different integrity levels. This supports tailoring, but tailoring should be documented: omitting a technique because it is inapplicable is different from silently leaving a high-risk claim unevaluated. ^[1]

Independent verification and validation (IV&V) introduces organizational separation from the development effort. Independence is not all-or-nothing. NASA identifies technical, managerial, and financial independence as key parameters and uses IV&V as risk mitigation for selected safety- and mission-critical software. ^[5]

Technical independence can provide different personnel, tools, assumptions, and analyses; managerial independence can protect reporting from delivery pressure; financial independence can reduce conflicts over findings. IV&V can increase confidence and expose shared blind spots, but it does not guarantee defect-free software. Its scope, access, authority, and reporting route must still be defined.

NASA’s public embedded-software lesson describes IV&V as technical and management activities performed by someone other than the developer and lists requirements analysis, tracing, peer review, simulation, risk analysis, code inspection, audits, and testing across the life cycle. That lesson is historical NASA guidance for embedded systems, not evidence that every project needs the same activities or degree of independence. ^[6]

Testing is an important V&V technique, but V&V also includes static and documentary activities. Testing observes behavior for selected inputs and conditions; it cannot exhaustively establish correctness for most nontrivial systems. Reviews may identify ambiguous requirements, static analysis may prove or flag properties without executing the program, and formal verification may establish a mathematically defined property of a model or implementation under stated assumptions.

Software quality assurance is broader still: it can include process assurance, configuration management, audits, supplier oversight, problem reporting, and compliance. Security assurance and safety assurance add threat, hazard, and consequence analyses that ordinary functional testing may not cover. Certification or regulatory acceptance can depend on domain-specific evidence and authority; a project should not claim certification merely because its internal V&V completed.

V&V evidence is bounded by the specification, oracle, environment, and observations. Common failure modes include:

• verifying an incomplete or incorrect requirement set;
• testing only nominal paths while omitting boundaries and adverse conditions;
• using an environment that differs materially from deployment;
• losing configuration identity between the tested and released artifact;
• treating trace coverage as evidence that linked tests are adequate;
• allowing the developer and evaluator to share the same unchecked assumptions;
• closing anomalies without re-verifying affected claims; and
• reporting “all tests passed” without naming what the tests establish.

V&V also does not freeze a changing system. Requirements, dependencies, operating environments, data distributions, and threats can change after an assessment. Maintenance and operational monitoring therefore need their own change-impact analysis and re-verification or re-validation criteria.

Verifying completion in tool-using agents applies acceptance criteria and evidence records to agent actions. Evaluating long-running agents covers repeated trials, interruptions, and environment drift. Provenance and revision-pinned citations covers evidence identity and versioning. Reproducible builds and content-addressed storage provide neighboring mechanisms for rebuilding and identifying software artifacts.

This article gives a cross-domain engineering overview. Project-specific obligations must be derived from the current governing contracts, standards, regulations, risk classification, and organizational policy.