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
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of System Analysis and Design.
Lesson complete
Earn the 3 college credits for System Analysis and Design
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: Agile Thinking: Core Definitions, Concepts, and Steps →← Incremental Development Models: The Iterative Approach and the Risk-Driven Spiral Model ComparedNext lesson: Agile Thinking: Core Definitions, Concepts, and Steps →
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.
Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →
Why take it here
Why students take System Analysis and Design with UPI Study
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.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →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?
Which testing levels match which phases in the V-Model?
How is the V-Model different from the Waterfall model?
What are the advantages and disadvantages of the V-Model?
About the System Analysis and Design course
How many college credits is System Analysis and Design?
How much does System Analysis and Design cost and what is included?
Which universities accept UPI Study credits?
How long does System Analysis and Design take?
How are the exams done?
How do my credits reach my college?
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.
3 credits · NCCRSEnroll →