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. [IEEE 1012-2024](https://standards.ieee.org/ieee/1012/7324/) [NASA verification planning](https://swehb.nasa.gov/plugins/viewsource/viewpagesrc.action?pageId=135332996)    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. [IEEE 1012-2024](https://standards.ieee.org/ieee/1012/7324/) [NASA verification planning](https://swehb.nasa.gov/plugins/viewsource/viewpagesrc.action?pageId=135332996)    ## Verification and validation    ### Verification    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. [NASA verification planning](https://swehb.nasa.gov/plugins/viewsource/viewpagesrc.action?pageId=135332996)    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    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. [IEEE 1012-2024](https://standards.ieee.org/ieee/1012/7324/)    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. [FDA guidance](https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-principles-software-validation)    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.    ## Life-cycle scope  

− 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. [ISO/IEC/IEEE 12207:2026](https://www.iso.org/standard/90219.html)

+ 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. [ISO/IEC/IEEE 12207:2026](https://standards.ieee.org/ieee/12207/11416/)

    A practical life-cycle mapping is:    | Stage or artifact | Example verification evidence | Example validation evidence |  | --- | --- | --- |  | Needs and requirements | Reviews for consistency, feasibility, traceability, and testability | Stakeholder confirmation that documented needs reflect intended use |  … 53 unchanged lines …    ## Related subjects    [Verifying completion in tool-using agents](/wiki/verifying-completion-in-tool-using-agents) applies acceptance criteria and evidence records to agent actions. [Evaluating long-running agents](/wiki/evaluating-long-running-agents) covers repeated trials, interruptions, and environment drift. [Provenance and revision-pinned citations](/wiki/provenance-and-revision-pinned-citations) covers evidence identity and versioning. [Reproducible builds](/wiki/reproducible-builds) and [content-addressed storage](/wiki/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.