V-model: Avoiding the 5 most common problems

The V-model is a development process model that was originally used for government projects (e.g., armaments). To this day, it is still anchored in many people’s minds and in standards for projects in regulated environments (e.g., medical technology, banks). This leads to disputes in teams that prefer agile development processes.

This article helps to resolve this contradiction. You will learn how to avoid the five most common problems and how to use the V-model correctly.

1. V-model: The basics

a) Objectives of the V-model

Objective 1: Achieve development goals

Like all development process models, the V-model is intended to help development projects achieve the planned quality of output (devices, software) in the planned time and with the planned resources.

Objective 2: Create clarity

This requires each role in the development project to know which input it needs to convert into which output at which point in time and using which methods.

Objective 3: Meet regulatory requirements

In regulated industries such as medical technology, banking, or the aviation industry, laws, standards, and guidelines must be followed that suggest working according to the V-model.

b) Special features of the V-model

The different phases

The V-model distinguishes between many development phases, which can be divided into three groups:

1. Planning and specification (see Fig. 1 in blue)
2. Implementation (in green)
3. Verification and validation (in purple)

Specification of tests during the planning phases

The V-model is characterized by the fact that verification and validation are already specified during the planning phase. The “tests” used to decide whether the requirements set in the planning phase are fulfilled or not are already determined during the planning phase.

The red arrows in Fig. 1 represent this assignment.

In the test phases, the testers then check against the specifications from the specification/planning phases.

c) Differentiation from other process models

Waterfall model

It is precisely this assignment that distinguishes the V-model from the waterfall model. The V-model is not a waterfall model in which the verification and validation activities are only “folded up” in the graphical representation.

In both models, it is possible to jump back to previous phases if errors are detected in one phase in order to rectify the errors there. But the activities are linear.

Agile process models

Despite all the backward steps, the V is only run through once as part of the development project. It is assumed that the requirements were determined sufficiently, completely, and correctly at the start of the project.

Agile process models do not make this assumption. Instead, they benefit from an iterative, incremental approach to elicit and fulfill the requirements step by step.

2. Phases and responsibilities

a) Overview of the phases and activities

This overview assumes that the system/device to be developed consists of several system components, each containing hardware and software, which are themselves subdivided into components (e.g., software items) (see Fig. 2).

b) Description of the activities/phases

Number according to Fig. 1, 2	Phase(s) including links to in-depth articles	Activities
1	Stakeholder requirements	Elicit stakeholder requirements (e.g., user requirements)
2	System requirements	Derive system requirements from stakeholder requirements and specify the system as a black box
3	System architecture and requirements for components	Derive which components are needed and which requirements they must fulfill to meet the system requirements
4	Component architecture and hardware and software requirements	Break down the system components into engineering domains (e.g., hardware (HW) and software system (SW)) and specify the respective requirements so that the system component fulfills its requirements
5	HW or software architecture and HW or software requirements	Determine which components (e.g., software components) the respective trade (e.g., software system) must consist of and specify the requirements
6	Implementation	Develop the hardware and software items according to specification
7	HW/SW component tests	Review whether the hardware and software items have been developed according to specification
8	HW/SW integration tests	Assemble hardware or software items piece by piece and check that they interact correctly
9	HW/SW subsystem tests	Check the complete hardware or software system against the specification Attention: There may be more than one hardware or software system per complete system (see Fig. 2).
10	Component integration tests	Assemble the components from their trades (HW, software) piece by piece and check that they interact correctly
11	Component tests	Test the complete system components against their specification
12	System integration tests	Assemble the system components piece by piece and check that they work together correctly
13	System tests	Test the complete system against its specification (system requirements)
14	System validation	Investigating whether the system meets the stakeholder requirements and intended purpose. Usability tests are an example of these tests.

c) Responsible roles

The activities of the V-model are not limited to the development department (see Tab. 2).

Number according to Fig. 1, 2	Responsible role
1	Requirements engineer
2	Usability engineer (for UI), interface experts for data interfaces
3	System architect
4	System architect
5	Software architect for software, design engineer, or electrical engineer for hardware
6	Software developer, electrical engineer
7	Software developer, electrical engineer
8	Software developer or software tester, electrical engineer, or hardware tester
9	Like 8 or dedicated software or hardware testers
10, 11, 12, 13	Dedicated system testers
14	Context and subject matter experts, usability experts

The task of management is to determine the context of the device or system.

3. 5 problems when using the V-model

Problem 1: Confusing the requirements types

Distinguishing between the different types of requirements is important, as is using the right methods to identify these requirements.

Even Wikipedia lacks this differentiation and/or identification of stakeholder requirements (see Fig. 3).

Standards such as IEC 60601-1 also confuse the requirement types (see Fig. 4).

In contrast to the illustration in Fig. 4, system requirements are verified, not validated. The “S” in PEMS stands for “system.” The identification of stakeholder requirements is also missing in this representation.

Problem 2: “Waterfall model” illusion

The assumption that all (stakeholder) requirements are recorded completely and correctly from the beginning is rarely fulfilled. However, the V-model is based on precisely this assumption.

There are several approaches to achieving this:

• Elicit stakeholder requirements systematically using the context method (A direct survey of users is not a suitable method)
• Validate the collected stakeholder requirements with the stakeholders
  • Have the stakeholder requirements specification checked by the stakeholders
  • Develop prototypes and mockups and have them evaluated in formative evaluations before the actual development. Use the feedback to improve the stakeholder and system requirements iteratively (see Fig. 5)
• Develop the device in several iterations (several Vs)

Problem 3: Increased expenses due to “mini-Vs”

Through iterative development with “mini-Vs” (see Fig. 6), manufacturers try to balance regulatory requirements and agile development.

The danger here is that the bureaucratic effort increases disproportionately. For example, document checks and releases as well as tests (both are verification activities) now have to be run through not just once, but with every iteration (sprint).

If manufacturers do not have lean investigator and release processes, they paralyze themselves.

Problem 4: Non-conformities due to “fake V-model”

To get around this problem, some manufacturers work iteratively and incrementally in reality (without documenting this) but “officially” according to the V-model. In other words, they develop relatively free of process-related specifications and end up creating documentation intended to give the impression that development was carried out according to the specifications of a V-model.

This violates many regulatory requirements and, if available, the requirements of your own QM system.

Problem 5: Recognizing development risks too late

With the V-model, you only know whether the development project was successful at the end. Therefore, the development risks are high.

The following examples show how manufacturers can minimize these risks:

• Use vertical prototypes to find out at an early stage whether the software architecture is suitable for the software to meet the requirements for time behavior and resource consumption.
• Use mock objects to replace components that have not yet been developed to test the components that have already been developed.
• Use formative evaluations to clarify early whether the system is usable (see Fig. 5).

4. V-model for medical devices

a) Regulatory requirements

Several standards impose requirements on the development process for medical devices:

• ISO 13485 requires this process to be specified, which determines roles and defines activities such as design reviews, verification, and validation.
• IEC 60601-1 also requires defining a development process for Programmable Electrical Medical Systems (PEMS). This must include the activities shown in Fig. 1. However, the standard does not prescribe a V-model.
• IEC 62304 contains the diagram shown in the Annex. It refers to IEC 60601-1 but does not insist on a V-model either. It even emphasizes that agile approaches are common and possible.

b) Interaction with other processes

Other standards also place requirements on processes:

• ISO 14971 requires a risk management process.
• IEC 62366-1 determines requirements for the usability engineering process.

c) V-model as a documentation model

Only a few medical device manufacturers use the V-model in its pure form. They benefit from it as a documentation model. The V-model describes which documents should be created during development and the dependencies between them.

This approach has proven itself as long as the problem 4 described above (non-conformities due to a “fake” V-model) is not committed.

5. Conclusion and summary

The V-model has established itself in the minds of most manufacturers and inspectors (e.g., notified bodies and authorities). However, it is rarely practiced in its pure form. Agile process models have become established in many companies.

However, agile development teams should also adopt the best practices of the V-model:

• Identify stakeholder requirements early and as wholly and systematically as possible
• Create and check at least the rough architecture at an early stage (and not iteratively and incrementally)
• Create and verify the documents according to the V-model

Medical device manufacturers hardly use the newer V-model XT, which supports agile approaches. The old V-model apparently continues to provide good service.

---

Change history

• 2023-04-28: Article completely rewritten
• 2018-07-11: First version of the article