V-Model in Systems Engineering: Verification and Validation

Understand the V-Model in Systems Engineering: needs, requirements, architecture, integration, verification, validation, V&V, FAT, SAT, and acceptance criteria.

Check it out!

The V-Model in Systems Engineering is a representation of the development life cycle that relates the progressive decomposition of needs and requirements on the left side to integration, verification, and validation at corresponding levels on the right side. Its value lies in showing that test criteria should not be created only at the end of the project: every level of definition should have a corresponding strategy for demonstrating that the system was built correctly and meets its intended use.

The model is neither a single methodology nor a rigid process. It works as a conceptual framework for organizing relationships among stakeholder requirements, system requirements, architecture, subsystems, components, integration, and V&V evidence. ISO/IEC/IEEE 15288:2023 does not prescribe the V-Model, but its definition, realization, verification, and validation processes can be organized consistently with this logic.

In complex systems, the principal benefit of the V-Model is preserving traceability between what was defined while moving down the “V” and what must be demonstrated while moving up. This reduces the tendency to treat commissioning and acceptance as isolated activities disconnected from engineering decisions.

The V-Model Connects Definition and Evidence

The most useful interpretation of the V-Model is not “design first and test later.” The principle is that verification methods and validation criteria should be planned while requirements and architecture are being defined.

Every requirement should be formulated so it can be demonstrated. Every critical interface should have a test strategy. Every relevant operational condition should generate a validation scenario.

A typical V-Model progresses from stakeholder needs to system requirements, architecture and subsystems, components and implementation, and then upward through component integration, subsystem verification, system verification, and operational validation.

The representation may vary among organizations, but the principle remains: definition decisions have corresponding demonstration activities.

Verification and Validation Are Different

Verification asks whether a product, subsystem, or system meets the specified requirements. Validation asks whether the system satisfies the need and intended use in its operational context.

A system may pass every verification test and still fail validation. This occurs when requirements were incomplete, incorrect, or did not reflect actual operations.

Process	Central question	Basis for comparison
Verification	Was it built according to specification?	Requirements and specifications
Validation	Does it solve the need in the intended use?	Needs, missions, and operational scenarios

Confusing the two processes leads to weak acceptance criteria. Demonstrating that equipment complies with its datasheet does not prove that the integrated system satisfies the user’s operational workflow.

The Left Side of the V Begins with Needs

The left side begins with stakeholders, needs, constraints, and the concept of operations. Before decomposing requirements, the team must understand which outcomes the system must produce and under which conditions.

Systems Engineering structures the transformation from need to requirement, architecture, and validation. The V-Model provides a visual way to connect those definitions with demonstration activities.

Poorly understood needs propagate errors to every lower level. Efficient testing cannot correct a system that was specified to solve the wrong problem.

Concept of Operations as the Basis for Validation

A Concept of Operations (ConOps) describes how the system will be used in normal, degraded, maintenance, contingency, and other relevant operating scenarios.

This matters because validation should occur against real use, not only against isolated requirements. A security system may satisfy individual functions yet fail under loss of communications, multiple simultaneous alarms, or an operator handover.

Defining these scenarios early makes it possible to prepare validation criteria before the system is deployed.

Stakeholder Requirements and System Requirements

Stakeholder needs are translated into verifiable system requirements. This transition requires removing ambiguity and defining measurable conditions whenever possible.

Requirements Management in Engineering helps structure identification, traceability, change control, and acceptance criteria.

In the V-Model, each requirement needs an associated verification strategy. If the team cannot explain how a requirement will be demonstrated, the wording may be vague or the project may not yet have defined adequate means of observation.

Verifiable Requirements from the Beginning

A requirement such as “the system shall have high availability” is insufficient for verification. The metric, observation period, exclusions, failure criteria, and measurement method must be defined.

The same applies to performance, security, interoperability, autonomy, capacity, and recovery.

Planning verification during requirements definition prevents discovering at the end that an important requirement cannot be measured with the available instrumentation, architecture, or data.

Architecture in the V-Model

After system requirements, the solution is decomposed into architecture, subsystems, and components. This decomposition should preserve traceability to higher-level requirements.

System Architecture defines functions, elements, interfaces, and structural decisions that determine how the system will be realized.

On the right side of the V, integration occurs at corresponding levels. Components are combined into subsystems; subsystems are combined into the system; and the system is integrated with the operational environment.

Decomposition Is More Than Breaking the System into Parts

Useful decomposition distributes responsibilities, requirements, and interfaces. Each subsystem must know what it is expected to deliver and how its contribution will be demonstrated.

Dividing a system solely by discipline or supplier may hide cross-cutting functions. Availability, security, and performance usually depend on more than one package.

The V-Model reinforces that decomposition must enable verifiable recomposition during integration.

Requirements Allocation

System requirements are allocated to subsystems and components. Some may be satisfied by one element; others require combined contributions.

An allocation matrix can relate each requirement to the responsible element, affected interface, verification method, and test level.

Requirement	Responsible element	Verification level	Method	Evidence
Processing capacity	Server/application	Subsystem	Test	Load report
Interoperability	Systems A+B	Integration	Demonstration/test	Logs and procedure
Autonomy	Power/UPS	System	Test/analysis	Curve and measurements
Degraded operation	Multiple subsystems	Validation	Scenario	Operational report

This structure turns the V-Model into a governance mechanism rather than merely a teaching diagram.

The Bottom of the V: Implementation and Realization

At the bottom of the V are component implementation or realization activities. Depending on the domain, this may mean manufacturing, configuration, software development, assembly, installation, or parameterization.

These activities also need their own controls. Inspections, unit tests, FATs, and configuration checks reduce the chance of carrying basic defects into higher levels of integration.

The earlier a problem is detected, the lower the correction cost tends to be.

Integration Begins Before the Site Phase

Integration should not be treated as a final phase that begins after every supplier has completed installation. It needs a strategy, sequence, prerequisites, and defined environments from the design stage.

In digital systems, integration can often be anticipated in a laboratory. APIs, authentication, protocols, flows, and interoperability can be tested before final infrastructure is available.

In electromechanical systems, FATs, mockups, and bench tests can validate interfaces before mobilization.

Integration Strategy

The integration strategy defines order, dependencies, environments, simulators, test data, and entry and exit criteria for each stage.

An incremental approach is usually more robust than integrating everything at once. When only a few elements are added in each step, failures are easier to isolate.

Architecture defines dependencies; the integration strategy turns those dependencies into an execution sequence.

Horizontal and Vertical Integration

Vertical integration combines decomposition levels: component → subsystem → system. Horizontal integration combines elements at the same level that need to cooperate.

A video surveillance system may require vertical integration among cameras, networks, servers, and VMS, but also horizontal integration with access control, fire detection, and the corporate directory.

The V&V plan must cover both types of relationships.

Verification at Multiple Levels

Verification does not occur only at the complete-system level. Components, subsystems, interfaces, and the system itself may each have their own criteria.

Verification at lower levels reduces uncertainty. If an integrated test fails, the team should know whether components and interfaces already passed earlier verification.

Without this discipline, system testing becomes a diagnostic environment for problems that should have been resolved earlier.

Verification Methods

Common methods include inspection, analysis, demonstration, and test. The correct choice depends on the nature of the requirement.

Inspection suits observable attributes. Analysis can demonstrate conditions through calculation or simulation. Demonstration verifies behavior without necessarily measuring every parameter. Testing applies stimuli and compares measured results against criteria.

More than one method may be required for critical requirements.

When requirements and evidence are not connected from the design stage, acceptance tends to depend on interpretation at the end. Structuring the verification matrix before deployment helps identify testability gaps and incomplete criteria while there is still time to correct the engineering.

Verification Cross Reference Matrix

The verification matrix relates requirements to methods, levels, cases, and evidence. It acts as the bridge between the left and right sides of the V.

In large projects, the matrix supports V&V coverage monitoring and helps detect gaps before execution.

Requirements, Evidence, and Acceptance Criteria Management turns this logic into evidence-based acceptance governance.

Entry and Exit Criteria

Every integration and test level should have conditions for starting and for being considered complete.

Beginning integrated testing with unconfigured components, uncontrolled firmware, or temporary interfaces produces results that are difficult to interpret.

Entry criteria may include configuration review, approval of earlier tests, environment readiness, and closure of critical pending items. Exit criteria define success, tolerances, and treatment of anomalies.

Test Procedure and Test Case

Test cases describe conditions and expected results. Procedures describe the execution sequence, preparation, instruments, data, criteria, and records.

This documentation should derive from requirements. Procedures based only on familiar supplier functionality may leave contractual requirements uncovered.

Traceability from requirement → case → result is central to the V-Model.

Verification Evidence

A statement that a “test was successfully completed” is insufficient evidence in critical systems. The record should make it possible to understand configuration, conditions, results, and responsibility.

Reports may include the requirement identifier, software version, equipment, parameters, date, environment, measured results, deviations, and attachments.

Photographs, logs, and native files supplement evidence when applicable.

Defects, Anomalies, and Retesting

Test failures should generate controlled records. The purpose is not only to correct the defect but also to preserve traceability among the problem, cause, change, and retest.

If a correction changes architecture or configuration, previously approved tests may need to be repeated. Impact analysis defines the required regression scope.

Closing an anomaly without checking side effects may introduce failures in requirements that had previously passed.

Validation: Demonstrating Fitness for Use

Validation is performed against the need, mission, and intended use. It should involve representative conditions and appropriate stakeholders.

An automation system may satisfy every functional requirement and still be difficult to operate during an emergency. A security system may meet component-level performance and still fail the response workflow of the operating team.

Validation must test the system as a system, not merely confirm its components.

Operational Scenarios in Validation

Scenarios represent real journeys: login, normal operation, network failure, server outage, maintenance, recovery, simultaneous alarms, loss of power, or other relevant conditions.

They help verify emergent behavior—properties that appear only when multiple elements interact.

These scenarios should originate in the ConOps and evolve throughout the project.

Progressive Validation

Some needs can be partially validated before the final system exists. Prototypes, simulations, mockups, and proofs of concept can be used to assess usability, performance, or critical workflows.

This anticipation reduces the risk of discovering late that a technically correct system does not satisfy real use.

The V-Model does not require all validation to occur only at the top of the V.

Iterative V-Model

A rigid interpretation of the V-Model as a waterfall sequence is inappropriate for many current projects. Systems Engineering uses iteration, concurrency, and evolving baselines.

ISO/IEC/IEEE 15288:2023 allows iterative, concurrent, and recursive application of processes to the system and its elements. The V-Model can therefore be applied in smaller repeated cycles.

Each increment may have its own decomposition, integration, and V&V.

V-Model and Agile Development

Agile methods do not eliminate the need for requirements, architecture, or V&V. They change cadence and granularity.

In systems combining hardware and software, software may evolve through sprints while physical infrastructure follows longer gates. The challenge is maintaining compatible interfaces and baselines.

The V-Model can serve as a high-level traceability map while teams execute iterative cycles within individual components.

V-Model and MBSE

MBSE — Model-Based Systems Engineering can make V-Model relationships explicit in a structured model.

Requirements can be connected to architecture elements, verification cases, and evidence. Changes can indicate which tests need to be repeated.

The V-Model provides the correspondence logic; MBSE can provide the traceability environment.

V-Model and Commissioning

Commissioning is strongly related to the right side of the V because it verifies installation, functionality, integration, and system readiness.

However, commissioning does not replace all verification. Many requirements should be demonstrated in the factory, laboratory, through analysis, or by inspection before SAT.

If all V&V is postponed until commissioning, the project transfers engineering problems into an expensive phase under schedule pressure.

FAT, SAT, and Integrated Tests

A Factory Acceptance Test (FAT) verifies elements or subsystems before shipment or deployment. A Site Acceptance Test (SAT) verifies behavior in the installation environment. Integrated tests assess interactions among subsystems.

These names do not automatically define scope. Each contract should establish which requirements are covered, which configuration is used, and which evidence will be accepted.

The V-Model helps position each test within the overall verification strategy.

Handover and Acceptance

Acceptance should be a consequence of demonstrated requirements, not a subjective final inspection.

When the V&V matrix, results, pending items, and evidence are organized, handover can clearly show what has been verified, what has been validated, and which exceptions remain open.

The Technical Acceptance Record formalizes this transition when contractual criteria have been satisfied.

In systems contracted through multiple packages, each supplier may demonstrate its own scope while an end-to-end performance gap still remains. Owner coordination must connect system-level requirements, interfaces, and tests across separate contracts.

V-Model in Multi-Supplier Contracts

Each supplier may have its own test plan, but the Owner needs an integrated strategy. System-level requirements cannot disappear at contract boundaries.

One supplier tests equipment; another tests the network; a third tests software. Someone still has to demonstrate that the end function works from end to end.

Owner’s Engineering can coordinate this cross-cutting view and preserve traceability between requirements and evidence from different packages.

Responsibility for Integration

Contracts should clarify who provides the test environment, simulators, data, access, tools, and resources required for integration.

They should also define who leads interface tests and who corrects problems when the cause lies in the interaction between two suppliers.

Without this definition, system-level V&V can become a boundary dispute.

V-Model and Change Management

A change on the left side modifies obligations on the right side. If a requirement, architecture element, or interface changes, verification and validation cases may also need to change.

Engineering Change Management should analyze impacts on V&V as well.

The question is not only “what must be redesigned?” but also “what must be tested again to demonstrate that the new configuration satisfies the requirements?”

Regression Testing

Regression testing checks that a change has not compromised previously approved functions. In interdependent systems, a local correction may affect behavior in another subsystem.

Architecture and requirements traceability help select a regression test set proportional to the impact.

Repeating every test may be expensive; repeating too few may leave residual risk. The decision should be technical.

Configuration Baseline During V&V

Test results are valid only for the tested configuration. Firmware, software, parameterization, hardware, topology, and documents must be identified.

If the system changes after testing, the organization must assess whether the previous result remains applicable.

This connection between evidence and configuration is essential for auditability and acceptance.

Independence in Verification

Critical systems may require some degree of independence between those who develop and those who verify. The appropriate level depends on risk, contract, standards, and criticality.

Independence does not mean excluding the development team; it means ensuring objective review and avoiding unchallenged assumptions in the evaluation.

Owner’s Engineering, QA/QC, or an independent third party may perform verification functions in specific contexts.

Readiness Reviews

Before important tests, Test Readiness Reviews may assess whether the system, documentation, configuration, environment, and team are ready.

The review reduces wasted test windows and prevents invalid results caused by missing prerequisites.

In projects with expensive mobilization or constrained operational outages, this gate can be decisive.

V&V as Part of Project Planning

Verification and validation consume resources, environments, equipment, personnel, and time. They therefore need to appear in the project schedule and budget from the beginning.

Integration dates depend on component and environment availability. Corrections and retests require contingency.

Projects that reserve only “a few days of testing” at the end usually underestimate V&V complexity.

V&V Indicators

Requirements coverage, first-pass approval rate, number of open anomalies, age of pending items, blocked tests, and requirements without evidence are useful indicators.

Interpretation should consider criticality. A single failure in a safety or security requirement may be more significant than dozens of minor approved cases.

The purpose of indicators is to support readiness decisions, not to produce an artificial progress percentage.

Common Mistakes When Applying the V-Model

One mistake is treating the model as an inflexible waterfall. Another is writing requirements and considering testing only after the system is complete.

Other common problems include V&V matrices without actual evidence, test cases based on manufacturer features instead of requirements, missing configuration records for tested items, and validation reduced to user training.

The V-Model loses value when it becomes merely a diagram in a corporate procedure.

When the V-Model Adds the Most Value

The approach is particularly useful in systems with multiple decomposition levels, large numbers of requirements, critical interfaces, high traceability requirements, and high costs of late failure.

It also helps in regulated or contract-driven projects where acceptance must be supported by objective evidence.

Smaller projects can apply the same principles through a simple requirements and verification matrix without formalizing the entire framework.

Final Considerations

The V-Model organizes an essential Systems Engineering discipline: what is defined should have a corresponding means of demonstration. Needs lead to validation; requirements lead to verification; architecture guides integration; configuration sustains the validity of evidence.

Its most valuable use is not the shape of the diagram but the traceability it creates between definition and proof. When V&V is planned from the beginning, requirements, interface, and testability problems appear before deployment.

In complex systems, this logic turns testing and commissioning from final activities into an integral part of the engineering process, improving predictability, technical quality, and acceptance objectivity.

Technical References

[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION; IEC; IEEE. ISO/IEC/IEEE 15288:2023 — Systems and software engineering — System life cycle processes. Geneva: ISO, 2023. Available at: https://www.iso.org/standard/81702.html

[2] NASA. NASA Systems Engineering Handbook. NASA/SP-2016-6105 Rev2. Washington, DC: NASA, 2016. Available at: https://www.nasa.gov/reference/systems-engineering-handbook/

[3] NASA. NASA-HDBK-1009A — NASA Systems Modeling Handbook for Systems Engineering. Washington, DC: NASA, 2025. Available at: https://standards.nasa.gov/standard/NASA/NASA-HDBK-1009

[4] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION; IEC; IEEE. ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life cycle processes — Requirements engineering. Geneva: ISO, 2018. Available at: https://www.iso.org/standard/72089.html

Frequently Asked Questions

What is the V-Model in Systems Engineering?

It is a representation that relates the decomposition of needs, requirements, and architecture to integration, verification, and validation at corresponding levels.

Is the V-Model the same as waterfall?

No. Although it can be applied sequentially, its principles can also be used iteratively and in incremental cycles. ISO 15288 permits iterative, concurrent, and recursive processes.

What is the difference between verification and validation?

Verification confirms compliance with specified requirements; validation confirms that the system satisfies the need and intended use in its operational context.

How does the V-Model relate to MBSE?

The V-Model provides the correspondence between definition and V&V; MBSE can represent these relationships in a structured model connecting requirements, architecture, tests, and evidence.

Are FAT and SAT part of the V-Model?

They can be part of the verification strategy depending on requirements and integration levels. The test name alone does not define which requirements are covered.

Why should verification be planned from the requirements stage?

Because it helps create verifiable requirements, define required instrumentation and environments, and avoid discovering at the end that important criteria cannot be demonstrated.

Additional Technical Materials