The V-model is a software development process in which every development phase has a matching test phase, which is why the process is drawn as a V. It is also called the verification and validation model, and it is used where a missed defect is costly. This guide explains how V-model software development works, shows an example, and gives a test for when it fits a custom software development project.
What is the verification and validation model in software engineering?
The verification and validation model in software engineering is a sequential process with design phases on the left, coding at the base, and matching test levels on the right. It is a variant of the waterfall model: instead of flowing straight down, the process bends upward after coding, so every design phase has a corresponding test phase, and test planning starts with design.
The V model SDLC does the same work as any other approach across the software development lifecycle; what changes is that test planning starts with design, not after coding.
Principles of the paired-test process
The paired-test process rests on one principle: every development phase is paired with a test that is planned at the same time. Common descriptions of this V methodology give a longer list, and these four principles do the work in TekRevol’s reading:
- Plan tests in parallel with design. Each design phase produces its test plan before the next phase starts.
- Prevent defects early. Reviews and test plans catch gaps while they are cheap to fix.
- Trace every requirement to a test. Each requirement links to a design item and a test case.
- Check each phase before the next. A phase ends when its output passes review.
V-model diagram: how to read it
In the V-model diagram, time runs left to right, and the horizontal lines pair each design phase with the test that checks it. The left side steps down through the design phases; the base is coding, and the right side steps up through the test levels.
The design gets more detailed going down the left side, and the tests get broader going up the right side. In TekRevol’s reading, the pairing lines are the most important part of the picture, because they show that each test is written against a specific design phase. The same V shape is used in systems engineering, where it covers hardware and human interaction as well as software.
Phases and test levels of the V-model
Four design phases each pair with one test level, from requirements and acceptance testing down to module design and unit testing. Coding sits at the base of the V, and this approach says little about how to code.
| Design phase | Test level it pairs with | What the test checks |
| Requirements analysis | Acceptance testing | That the finished system meets the business need, run by business users in a production-like setting |
| System design | System testing | That the complete system meets its functional and non-functional requirements |
| Architectural design | Integration testing | That tested units work together across their interfaces |
| Module design | Unit testing | That the smallest units work on their own |
Sources name these phases a little differently, for example, business requirement analysis or system analysis, but the pairing is the same. This pairing is what testing means in this approach: each level of test checks one level of design.
Verification and validation in this approach
Verification asks whether the product is built right, and validation asks whether it is the right product. In this approach, verification checks each output against the one above it, and validation checks the finished product against what users need.
Wikipedia notes that the usage of the two terms varies in practice, and validation can partly happen on the left side of the V. In TekRevol’s reading, the safe habit is to ask the question each time: is this built right, or is it the right thing? Validation is the second question, and acceptance testing answers it most directly.
A V-model example: a card payment terminal
One requirement travels down the left side and back up the right side through four tests in this example. The example is TekRevol’s illustration: a payment terminal needs the rule that a refund above a set limit requires a supervisor PIN.
| Level | Written on the way down | Test written at the same time | What the test found |
| Requirements | A refund above the limit needs a supervisor PIN | An acceptance test with a supervisor approving a large refund | Passed once the receipt order and the message format were fixed |
| System design | The terminal asks for the PIN before it contacts the payment network | A system test of the full refund flow, from PIN entry to receipt | The receipt is printed before approval |
| Architectural design | The PIN module sends an approval message to the refund module | An integration test of the two modules | The two modules used different message formats |
| Module design | The refund module checks the amount against the limit | Unit tests at the limit and on each side of it | Passed |
The tests run from the bottom up: the integration test found the message mismatch, and the system test found the early receipt. Because every test was written when its design was written, the team traced each failure to a design document. A real project would have many more tests.
Advantages of the V Model
The main advantage of the V-model is that tests are planned while the design is still on paper. These are the benefits most often cited:
- Early test planning. Writing acceptance tests exposes vague requirements while they are cheap to fix.
- Clear structure. Each phase has an output and a paired test, so progress is easy to track.
- Every requirement links to a design item and a test, which helps in audited work.
- Simple to learn. Teams need little training to follow the V.
- A fit for regulated work. The model is aligned with standards such as ISO 26262 in V-model automotive projects.
Disadvantages of the V and how to soften them
The main disadvantage of the V-model is that it handles change poorly. Wikipedia describes it as rigid and linear, and as a variant of waterfall that inherits waterfall’s weaknesses. The fixes below are our judgment.
- Costly change. A changed requirement reaches every paired level. Use formal change control and keep the upper levels of design light.
- No early working software. Nothing runs until coding is done. Add a prototype or a proof of concept for the riskiest requirement.
- False confidence from a simple picture. The V can make a project look more orderly than it is. Review the plan against real progress, not against the diagram.
- Tests as paperwork. Teams can write test plans to tick a box. Treat test planning as a design review, so a vague requirement is fixed instead of documented.
Industrial challenges of the V Model
The main industrial challenge is that real projects rarely hold their requirements still for the length of a V. The challenges below come up when teams deliver with the model in practice, and the fixes are TekRevol’s judgment.
- Late requirement changes. A regulator or a customer can change a signed requirement mid-project. Agree on a change process and the cost of a change before the build starts.
- Testing squeezed at the end. Protect the test time in the plan, and run unit tests as code is written.
- Hardware and software integration. Automotive and device projects test software together with hardware, which usually needs specialized test setups. Plan the setups and the integration order at architectural design.
- Evidence for audits. Regulated projects must show that every requirement was tested. Keep the requirement-to-test links in a tool.
V vs Waterfall, Agile and Spiral
The verification and validation model is a form of waterfall with a test phase paired to every design phase. Waterfall plans testing after the build, and the V model plans it alongside design. The table is our reading of how these SDLC methodologies differ.
| Aspect | The V | Waterfall | Agile |
| What drives the plan | Paired design and test phases | The signed-off phase plan | The product backlog |
| When tests are planned | While each phase is designed | After the build | In every sprint |
| User involvement | At requirements and at acceptance | At the start and at acceptance | Throughout |
| Cost of change | High, across paired levels | High late in the project | Kept low by short cycles |
| Best fit | Stable scope, costly defects, audits | Stable scope and a fixed contract | Needs that change |
Compared with waterfall, the V comes down to timing: both fix the plan up front, but the V writes the tests with the design. The spiral model differs more, because it picks each step by the biggest open risk, so it suits a project where the main unknown is not yet settled.
Can the V model work with agile?
It can, by running a small V inside each increment while keeping the architecture planned up front. Firesmith’s 2013 SEI critique notes that real projects often work incrementally and concurrently.
In TekRevol’s judgment, the workable hybrid is to plan the architecture and the safety or compliance requirements as a V, then build features in sprints that each carry their own unit and integration tests. Our guide to agile vs waterfall covers when each approach fits.
When to use the V-model development
Use this approach when requirements are stable and a missed defect is costly. The TekRevol V Fit Check turns that into five questions. The check is TekRevol’s judgment.
| Question | Points toward the V | Points away from the V |
| Are the requirements stable? | Yes, they are agreed and unlikely to change | No, users will change them once they see the product |
| How costly is a missed defect? | High, such as a safety or legal risk | Low, and easy to fix after release |
| Does an auditor need traceability? | Yes, each requirement must trace to a test | No formal audit trail is needed |
| Is hardware part of the system? | Yes, and it must be tested with the software | No, it is software only |
| Can the client decide quickly during the build? | No, the client can only review at set points | Yes, a named owner can decide every week |
In TekRevol’s judgment, automotive and medical device projects are typical fits. Four or five answers in the middle column point to this approach, and four or five in the last column point to an iterative approach. Anything in between suggests a hybrid, such as a V plan for the core and sprints for the features.
The Fit Check covers how the software is built and tested. The wider product choices, such as when to launch and when to retire a product, belong to the product life cycle, which our SDLC vs PDLC guide compares.
Not sure if a test-paired plan fits your contract and your tests?
If your contract fixes the scope and your product must pass audits or safety checks, a test-paired plan may fit. Bring your contract and your requirements to a conversation before you choose a model.
TekRevol is a software development company that scopes fixed-price work honestly when a project needs it, and it proposes a more sequential engagement when a client cannot commit to a decision timeline. Its custom software development process records the delivery model in the statement of work, so the plan and the contract match.
Choose the model after you check the contract and the risks, not before. Start with a Free Consultation.
