The Myth of the V-Model

Product Development & Management

The Myth of the V-Model

By |

The Myth of the V-Model

If you are building complex systems, then you have probably heard of the V-Model. Before we explain it, a word of caution: There are different, partially contradicting definitions of the V-Model. Further, it’s easily misunderstood, which can be more harmful than helpful. This is also the source of the myths of the V-Model. Understanding the Myth of the V-Model helps you apply it correctly, thereby making you more effective.

The V-Model in Brief

Above is one visualization of the V-Model: To understand it, we start in the top left. Here you find the high-level requirements (“Concept of Operations”). Following the left arm of the V, the product definition is refined until we reach the implementation. The right arm of the V contains the corresponding items for validation and verification, like tests, analysis or inspection.

What’s unclear about the model (and frequently a source of confusion) are the relationships between the elements, visualized through arrows. Note that the various arrows have different meanings:

  • The solid lines connecting the boxes represent dependencies. For instance, there is a relationship between “Requirements” and “Detailed Design” (the Detailed Design is a possible solution). If the requirement changes, then usually the design needs to change as well. For instance, changing the battery life from 24 to 48 hours (requirement) will probably require a larger battery (design).
  • The dashed “Verification & Validation” lines also represent a dependency, but this time for test coverage. Note that the arrows in the figure represent a “tests” relationship (“System Verification & Validation tests Requirements & Architecture”). The direction of the dependency is in the other direction (e.g., changing the battery life from 24 to 48 hours will trigger an update to the corresponding Systems Test).
  • The outer dashed lines denote activities, and broadly represent time. But here we have to be very careful because they do not represent a strict time sequence. This is a huge source of confusion.

Now that we have a rough understanding of the V-Model, let’s look at four of its common myths:

Myth: The V-Model is Only an Extended Waterfall

If we take the time axis too literally, then the V-Model appears to be the Waterfall Model (the left side of the V), with the verification “folded” up. Just as a reminder, the Waterfall model is a linear development approach. It consists of different phases (requirements, design, implementation, etc.), where each one is completed before the next starts. The main difference between the V-Model and Waterfall is the fact that the V-Model iteratively increases the maturity of the development, affecting all items of the product description.

Myth: The V-Model is Simply a Process

This statement is correct, but not complete. Yes, the V-Model is a process. In fact, it is widely used, cited and standardized in various ways: There is the German “Das V-Modell,” a government standard and PRINCE2 method, which is used in the UK and US. Many standards reference it, including ISO/IEC/IEEE 15288.

But this view focuses on the process and ignores the fact that the V-Model also represents the artifacts of product development and their relationships. This second view can generate additional insights, especially if the artifacts are fine-grained: For instance, traditionally the box “requirements” in the figure above would represent a requirements process, with a process flow to the design process.

But if these represent individual requirements, with a precise traceability to design elements, this relationship can suddenly be used for coverage analysis (“ensure all requirements are covered”), change management (“after this requirement change, which design elements are affected?”) and much more.

Looking at both — the process and data model — significantly increases the value of the V-Model.

Myth: The V-Model Cannot be Applied in an Agile Environment

This myth is related to the previous one: The existing methods based on the V-Model were created in the ‘90s, before the Agile Manifesto was created.

But the V-Model itself is not just compatible with Agile methods. It’s (almost) a prerequisite! To be more precise, a robust relationship model, like the V-Model, is the foundation for making changes with confidence. And frequent changes are one of the aspects of Agile development. A robust relationship model reflects the triangular relationship between requirement, test and implementation.

Myth: During Development, We Move from Left to Right

As already indicated in the two myth we busted, the V-Model requires jumping back and forth during development. Nevertheless, the assumption is that we need requirements before we can create the corresponding tests.

But the V-Model is well-suited to also support behavior-driven development (BDD). In BDD, the expected behavior is defined in a testable manner. Design only starts after the behavior is defined.

This corresponds to test-driven software development, where an automated test is written before the software implementation is created. For BDD to work, the relationships between the items concerned must be clearly defined and available for analysis and change management.

The V-Model provides the necessary structures for this process. In fact, this triangular relationship is visible in the V-Model’s triangular form, except that BDD uses a slightly different terminology.

The V-Model and Product Development Platforms

The V-Model can be confusing, as it relates to both process and data models. Product development platforms like Jama Software distinguish between these two aspects and address them separately:

  • Works with a flexible data model consisting of item types and relationships. These can be tailored to existing artifacts and workflows. This allows the product description to evolve naturally, while managing the relationships automatically. The results are a clearer understanding of coverage without the fear of changes.
  • Allows workflows to guide the maturity of the product description, aligned with existing processes. This creates the confidence in the quality of the product, makes it easy to work in a compliant environment and takes the anxiety out of audits.

Conclusion

The V-Model is a powerful concept. But it has been around for a long time: It was created in a time where document-based work was the norm, and where Agile was not yet an established approach. Applied in a modern context, the V-Model is the enabler for the faster development of better products. But in order to take advantage of this, it must be understood.

Learn how to overcome tight timelines, increasing product complexity and risk and regulation adversity with our webinar, “Do More with Less: How Effective Requirements Management Increases Productivity.” 

Michael Jastram
Latest posts by Michael Jastram (see all)