Verification at Every Stage: The V-Shaped Model in the SDLC

UPI Study › Courses › System Analysis and Design › Free lessons › Lesson 2.8 Free with a free account

Verification at Every Stage: The V-Shaped Model in the SDLC

System Analysis and Design · Chapter 2: Business Analysis Tools and Development MethodsSection 2.8 · lesson 14 of 698 min · free with a free account

← Incremental Development Models: The Iterative Approach and the Risk-Driven Spiral Model ComparedNext lesson: Agile Thinking: Core Definitions, Concepts, and Steps →

Earn 3 college credits for System Analysis and DesignRecommended for credit by NCCRS · Computer Science 390 · self-paced · one payment, lifetime access

In this lesson

Verification planned at every stage of the SDLC.

  • Describe the V-Model's structure and its link to a straight-line SDLC
  • Explain how each development phase pairs with a test level
  • Identify the 4 phase-to-test-level pairings
  • Explain when the V-Model fits, and weigh its pros and cons

Transcript

Everything said in the video, section by section (1,130 words). Read along, or search it.

Business Analysis Tools and Development Methods

The V-Shaped Model

In Waterfall, testing waits until the code is written. The V-shaped model keeps the same straight sequence, but changes when testing is planned. In the V-Model, every development phase gets a matching test level, and the two are planned together from the start. This section covers the shape of the model, its four pairings, why early test planning matters, and when the model fits.

The Shape

A Straight Line, Bent Into a V

The V-Model takes a straight-line, phase-by-phase development sequence, and bends it into the shape of a V. Development activities run down the left arm. They go from broad requirements, down to detailed design. The arms meet at the bottom vertex, where the code itself is written. Testing activities then run up the right arm. They go from the narrowest, most detailed testing, back up to the broadest test against the original requirements. The model gets its name, and its usefulness, from what happens across the two arms. Every development phase on the left has a matching test level on the right. And each pair is planned together, from the start.

Figure 2.5

Each Phase Pairs With a Test Level

Here is the full V. On the left, going down: requirements analysis, system design, architecture or high-level design, and module or detailed design. At the bottom, coding. On the right, going up: unit testing, integration testing, system testing, and acceptance testing. The dashed lines show the pairs, straight across the V. Notice the symmetry. The first thing designed is the last thing tested. And the most detailed design is the first to be tested. Follow one dashed line, and you have the whole idea. The requirements written at the top left are exactly what acceptance testing checks at the top right.

The 4 Pairings

What Each Test Level Confirms

Let's go through the four pairings. Requirements analysis pairs with acceptance testing. Acceptance testing confirms the finished system does what the business and end users actually asked for. System design pairs with system testing. System testing confirms the system as a whole behaves the way the overall design specified. Architecture, or high-level design, pairs with integration testing. Integration testing confirms that modules and components work correctly once they are connected to one another. Module, or detailed design, pairs with unit testing. Unit testing confirms that each individual module works correctly on its own. Each test level checks the work of exactly one design level. Nothing is tested against a vague whole.

The Vertex

Where Coding Sits

Coding sits at the bottom vertex. It is the single point where the development arm ends, and the testing arm begins. Here is a subtle detail. Coding has no separate paired test level of its own. Instead, the code produced at the vertex is what all four test levels ultimately verify. Working back up the right arm, each test level looks at that same code, at a wider scope. First each module alone, then modules together, then the whole system, and finally the system against what the users asked for.

The Defining Habit

Test Plans Written Early, in Pairs

The defining habit of the V-Model is about timing. The test plan for each level is written at the same time as its paired development phase. Not afterward. So the acceptance test plan is drafted while requirements are being analyzed, not after the system has been built. And the unit test plan is drafted alongside detailed module design, not after coding is finished. That changes the role of testing. Instead of a phase that happens to the software at the end, it becomes part of how the software is specified in the first place. This is the key difference from plain Waterfall. Both run in the same straight sequence. But in the V-Model, the tests exist on paper long before there is any code to test.

The Side Benefit

Testable Means Specific

Writing tests this early has a side benefit, beyond the tests themselves. It forces requirements and designs to be specific enough to test. Consider a requirement like, the system should be easy to use. Try writing an acceptance test for that. You cannot. What exactly would the test check? So that requirement gets caught, and clarified, during requirements analysis. That happens long before it could cause confusion during coding, or during late-stage testing. In other words, planning tests early is also a quality check on the requirements themselves. Recall the cost of change curve. A vague requirement caught during analysis costs a conversation. Caught in testing, it costs a rebuild.

When It Fits

Stable Requirements, Strict Traceability

When does the V-Model suit a project? It works best when requirements are well understood, and unlikely to change significantly once development begins. Like the straight-line SDLC it is based on, it is not built to absorb major changes in the middle of a project. It is especially common in regulated or safety-critical settings. Healthcare devices. Aerospace systems. Government systems with strict audit requirements. In those settings, the documented, traceable link between each requirement and the test that verifies it is often required. It is a compliance requirement in its own right, not just good practice. An auditor can ask, for any single requirement, which test proved it was met. The V-Model is built to answer that question.

Weighing It Up

Advantages and Disadvantages

Let's weigh it up. The advantages start with traceability. Every requirement is clearly linked to the test that verifies it. Testing is planned early, rather than rushed at the end. The model is well suited to projects with strict documentation or regulatory needs. And defects tied to unclear requirements tend to surface early. The disadvantages mirror Waterfall's. There is little built-in flexibility for requirements that change once development is underway. Stakeholders do not see a working version of the system until late in the project. And it can involve heavier upfront documentation than a project with stable, simple requirements actually needs. So the V-Model is a strong choice when requirements are stable and proof matters. It is a weak one when requirements are still being discovered.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. The V-Model bends a straight-line SDLC into a V, pairing each development phase with a specific test level. Acceptance testing confirms the finished system does what the business and end users asked for. System testing confirms the whole system behaves the way the overall design specified. Integration testing confirms that modules and components work correctly once connected. And unit testing confirms that each individual module works correctly on its own.

Key Takeaways

What to Carry Forward

To pull this together. The V-Model bends a straight-line SDLC into a V, pairing each development phase with a specific test level. Requirements analysis pairs with acceptance testing, and system design with system testing. Architecture, or high-level design, pairs with integration testing, and module design with unit testing. Coding sits at the vertex, where development ends and testing begins. Writing each test plan alongside its paired phase forces requirements and designs to be specific enough to test. And the V-Model suits well-understood, stable, regulated, or safety-critical projects. But it offers little flexibility for major changes once development begins.

About System Analysis and Design at UPI Study

System Analysis and Design (Computer Science 390) is a self-paced online course of 69 video lessons in 9 chapters, from the analyst's role and requirements to UML modeling, interface and database design, testing, maintenance and project management. It carries a NCCRS credit recommendation for 3 semester credits.

Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Compare: Software Engineering vs Systems Analysis

Why take it here

Why students take System Analysis and Design with UPI Study

From business problem to working systemSystem Analysis and Design teaches how analysts study a business need and turn it into a system design: requirements, UML and data-flow models, interface and database design, implementation and project management. It is a core course in information systems and IT degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Where the credit goes

Universities that work with NCCRS

System Analysis and Design carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.

FAQ

Questions students ask us

About Verification at Every Stage: The V-Shaped Model in the SDLC

What is the V-Model in software development?
The V-Model is a sequential development model that pairs each development phase with a matching test level, drawn in the shape of a V. Development runs down the left arm from requirements to detailed design, coding sits at the bottom vertex, and testing runs up the right arm from unit testing to acceptance testing. The first thing designed is the last thing tested, and each pair is planned together from the start.
Which testing levels match which phases in the V-Model?
In the V-Model, requirements analysis pairs with acceptance testing, system design with system testing, architecture or high-level design with integration testing, and module or detailed design with unit testing. Acceptance testing confirms the system does what users asked for, system testing checks the whole against the overall design, integration testing checks connected modules, and unit testing checks each module alone. Coding has no separate paired test level.
How is the V-Model different from the Waterfall model?
The V-Model follows the same straight sequence as Waterfall but plans testing much earlier: each test plan is written alongside its paired development phase rather than after coding. The acceptance test plan, for instance, is drafted during requirements analysis. This also forces requirements to be testable, so a vague statement like the system should be easy to use gets caught and clarified early, when fixing it is cheap.
What are the advantages and disadvantages of the V-Model?
The V-Model's advantages are strong traceability between each requirement and its test, early test planning, early discovery of unclear requirements, and a good fit for regulated or safety-critical settings such as medical devices and aerospace. Its disadvantages mirror Waterfall's: little flexibility once development begins, no working version for stakeholders until late, and possibly heavier upfront documentation than a simple, stable project needs.

About the System Analysis and Design course

How many college credits is System Analysis and Design?
System Analysis and Design (Computer Science 390) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does System Analysis and Design cost and what is included?
$250, paid once, with lifetime access: all 69 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. Students who want several courses choose UPI Study PRO instead.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does System Analysis and Design take?
It is self-paced with no deadlines. The 69 lessons total about 9 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

Ready for the full course? Earn 3 credits in System Analysis and Design.

69 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.

System Analysis and Design
3 credits · NCCRS
Enroll →