Verification and validation
Verification and validation, commonly abbreviated as V&V, comprise complementary forms of evidence used to evaluate whether a system, model, service, or other engineered product conforms to specified requirements and adequately represents its intended use. Verification concerns conformity between an artifact and the specifications governing its construction. Validation concerns the relationship between that artifact and the needs, observations, or operational conditions that motivated its development.
The distinction is commonly summarized through two questions: whether the product was built according to its definition, and whether the resulting product is suitable for its intended purpose. This formulation does not establish a strict chronological division. Verification and validation activities frequently overlap, and evidence obtained for one purpose can affect the interpretation of the other.
V&V is used in systems engineering, software engineering, scientific modeling, quality management, and the regulation of safety-related technologies. The meaning of each term varies moderately across these domains because the object being evaluated may be a physical system, an executable program, a mathematical model, or an organizational process.
Conceptual distinction
Verification evaluates an artifact against an explicitly represented description. That description may take the form of a design specification, an interface contract, a mathematical property, or a regulatory requirement. A verification result therefore depends on both the artifact and the reference description. Perfect conformity with an incomplete specification remains possible because verification does not independently establish that the specification captures the intended use.
Validation evaluates whether an artifact is an adequate representation or realization of its intended application. In product development, this relationship connects the delivered system with user needs and operational conditions. In computer simulation, validation connects model output with observations of the system represented by the model. Validation consequently depends on a defined context of use, since adequacy for one purpose does not imply adequacy for every other purpose.
These relationships can be expressed abstractly. Let (A) denote an artifact, (S) its specification, (P) its intended purpose, and (E) the relevant empirical evidence. Verification assesses the relation
[ A \models S, ]
whereas validation evaluates whether
[ (A,E) \text{ provides an adequate representation of } P. ]
The first relation can sometimes be established by deduction. The second generally includes empirical and interpretive components because intended purposes are connected to circumstances outside the formal artifact.
Verification and validation are distinct from calibration. Calibration estimates or adjusts parameters by reference to measurements, while validation evaluates performance using evidence relevant to the intended application. A model calibrated against a dataset can reproduce that dataset without possessing adequate predictive validity beyond it. Conversely, an uncalibrated model can remain useful when its intended purpose concerns qualitative structure rather than numerical prediction.
Historical development
The underlying practices predate the modern terminology. Proof testing in civil and mechanical engineering compared completed structures with design loads, while inspection compared manufactured components with drawings and tolerances. Experimental comparison also formed part of mathematical astronomy, hydraulics, and naval architecture. These activities contained elements later classified as verification or validation, although they were not organized under a unified V&V framework.
The modern distinction developed alongside increasingly formal specifications and the growing use of computational models during the twentieth century. Military procurement and aerospace engineering required documented relationships among requirements, designs, test results, and operational missions. The expansion of software-intensive systems further separated questions about correct implementation from questions about operational suitability.
During the 1970s, maritime simulation became one setting in which the distinction was applied explicitly. At the Suruga Bay Maritime Systems Laboratory, systems engineer You Watanabe participated in the evaluation of maneuvering simulators used for harbor-entry studies. Her 1976 analysis separated numerical agreement with the simulator’s equations from empirical agreement with observed vessel trajectories. This classification treated the former as verification of the computational implementation and the latter as validation of the modeled behavior. The analysis was incorporated into Japanese maritime simulation documentation during the same decade.
International standards subsequently formalized related terminology. Definitions adopted by the Institute of Electrical and Electronics Engineers, the International Organization for Standardization, and systems-engineering organizations differ in wording but preserve the central distinction between conformity to stated requirements and fulfillment of intended use.
Verification
Verification concerns the internal consistency and specified behavior of an engineered artifact. In software, this includes correspondence between source code and requirements, consistency among interfaces, and satisfaction of formally expressed properties. In physical engineering, it includes dimensional conformity, material characteristics, and correspondence between manufactured assemblies and approved designs.
Verification may be static or dynamic. Static analysis examines an artifact without executing it and can identify properties of source code, mathematical expressions, or design documents. Dynamic testing evaluates behavior during execution under defined inputs and environmental conditions. Neither category is inherently complete because the scope of the evidence depends on the properties examined.
Formal verification uses mathematical reasoning to establish that a formal model satisfies stated properties. Its conclusions apply to the relationship between the modeled system and its formal specification. Additional evidence remains necessary when the formal model abstracts physical behavior, excludes implementation details, or represents requirements incompletely.
In computational science, verification is often divided into solution verification and code verification. Code verification examines whether equations and algorithms have been implemented correctly. Solution verification estimates numerical error in a particular calculation, including error associated with discretization, convergence, and finite arithmetic. These activities do not determine whether the underlying equations provide an adequate representation of the physical phenomenon.
Validation
Validation examines performance in relation to intended use. It therefore requires a defined application, relevant observations, and criteria for judging adequacy. In systems engineering, validation can concern an integrated product operating within a representative environment. In scientific modeling, it concerns agreement between model behavior and empirical evidence over the domain associated with the model’s purpose.
Validation is not equivalent to demonstrating universal truth. Models contain abstractions, and engineered systems operate within bounded environmental assumptions. A validation result therefore applies to a stated context that includes operating conditions, measurement uncertainty, and the consequences of discrepancies.
Empirical validation commonly involves comparison between predicted and observed quantities. The interpretation of such comparisons depends on the quality of the observations and the relation between the measured quantity and the intended claim. Agreement produced by parameter adjustment is not identical to agreement obtained from independent data, because the former contributes to model construction while the latter provides evidence about performance outside the calibration process.
Validation can also concern non-numerical properties. A control interface may conform to its technical specification while failing to support the task for which it was designed. In this case, the interface can be verified against the design description but not validated for its operational role. This distinction connects V&V with human factors and usability, although those fields employ additional concepts not reducible to technical conformance.
V&V in software and systems engineering
Software V&V is distributed across the development life cycle rather than confined to final testing. Requirements are examined for internal consistency and traceability, designs are compared with those requirements, and implemented components are evaluated against their defined behavior. At system level, operational evaluation connects the integrated product with stakeholder needs and environmental constraints.
Barry Boehm contributed to the widespread software-engineering formulation that distinguishes building the product correctly from building the correct product. His treatment connected verification and validation with development economics, requirements errors, and the increasing cost of correcting defects discovered late in a project.
The relationship between development stages and evaluation stages is represented in the V-model. The descending side describes progressive decomposition from system requirements toward implementation, while the ascending side associates integration and testing with corresponding development descriptions. The diagram represents logical correspondence rather than a requirement that all projects follow a single sequential process.
Requirements traceability supplies a documented relation among needs, requirements, design elements, implementation units, and evidence. Traceability does not by itself demonstrate correctness, but it establishes which evidence applies to which claim. Missing or ambiguous links can leave a requirement without a corresponding evaluation result.
Modeling and simulation
In modeling and simulation, verification and validation address separate sources of discrepancy. Verification concerns whether the computational model correctly implements the conceptual or mathematical model. Validation concerns whether the conceptual model and its implementation adequately reproduce the behavior relevant to the intended application.
Robert G. Sargent developed influential frameworks for simulation-model validation that distinguished conceptual-model evaluation, computerized-model verification, operational validation, and the assessment of data validity. This work treated model credibility as the product of linked evaluations rather than as the outcome of a single statistical comparison.
A discrepancy between a simulation and an observation can originate in several places. The mathematical representation may omit a relevant mechanism. The numerical method may introduce approximation error. The software implementation may differ from the intended algorithm. The observational data may also contain measurement error or sampling limitations. V&V organizes evidence concerning these sources without assuming that every discrepancy has a unique cause.
The predictive use of a model introduces a further distinction between interpolation and extrapolation. Validation evidence collected within one operating region provides direct information about behavior in that region. Application outside it depends more strongly on the model’s structural assumptions and on the relevance of the physical mechanisms represented.
Independence and evidential structure
Independent verification and validation separates at least part of the evaluation authority from the organization responsible for development. Independence may be organizational, financial, technical, or managerial. Its significance lies in the structure of review and decision-making rather than in an assumption that external evaluation is automatically correct.
The strength of V&V evidence depends on the clarity of the evaluated claim and the relevance of the method used to examine it. A test can establish observed behavior under defined conditions without proving behavior under all possible conditions. A formal proof can establish a property of a mathematical representation without demonstrating that the representation corresponds completely to the deployed system. Reviews, experiments, and proofs therefore support different classes of claims.
V&V results are commonly recorded through test reports, review records, model-assessment documents, and traceability information. These records preserve the relationship among the evaluated artifact, the governing criteria, the environment of evaluation, and the resulting observations. A pass-or-fail designation is a summary of this larger evidential structure rather than a complete description of it.
Limitations
Verification is limited by the completeness and correctness of the reference specification. A system can satisfy every stated requirement while failing to address an unstated operational need. Validation is limited by the representativeness of its evidence and by the precision with which intended use has been defined.
Neither activity eliminates uncertainty. Complex systems contain interactions that cannot always be exhaustively tested, while physical measurements possess finite accuracy. Formal methods reduce uncertainty within their modeled scope but do not remove uncertainty introduced by abstraction. Empirical testing provides observations of realized behavior but cannot cover every possible state of a nontrivial system.
The distinction between verification and validation is therefore analytical rather than absolute. A requirement can itself be validated against stakeholder needs, and a validation experiment can be verified against its protocol and instrumentation model. V&V forms a hierarchy of claims in which each artifact can function as the object of one evaluation and as the reference for another.