V-model stands for ‘Verification and Validation model‘. It is a sequential process, where each phase must be finished before the next begins. Development of the testing protocol and measurement systems are done in parallel.
The V-model starts top-left with the (latent) need within the target group. ‘The statement of need’ describes the customer insightsthat is, the challenges the target group experiences.
Step 1: Formulating the Commercial Requirements
The first step is to formulate this in a value proposition (the ‘Commercial Requirements’). This describes the benefits the new innovation offers the target group in such a way that these challenges can be solved or made more manageable..
At the end of the project, these Commercial Requirements will be tested by a field-test (‘Acceptance Test’). According to the V-model, the test plan, procedures and measurement system all have to be written parallel to writing the Commercial Requirements.
Step 2: Developing the System Requirements
Next we need to translate the Commercial Requirements into System Requirements. The System Requirements are the end-product parameters, usually technical parameters with specifications.
In DfSS, this is the same as the Identify phase <LINK>. Again, in parallel to this phase, the measurement methods, test plans and procedures must be written for the System Test (or alfa-test).
The System Test answers the question: “have we built the system correctly?” Frequently, after the System Test but before the field test, a beta test is performed. The beta test answers the question “have we built the right system?”
Step 3: Architecture phase
The third step is the architecture phase, where the total system is broken down into the building blocks or sub-systems. This is known as the Design phase in DfSS <LINK>.
In this phase, the System Requirements are translated to Requirements for the sub-systems. In our experience, such a translation of specifications is often not done properly. Here you can see how this can best be done using the transfer functions <LINK>.
Step 4: Component Requirements
Next you need to further breakdown the sub-systems into Component Requirements. For more complex products there can be a further breakdown into parts and, if applicable, into process parameters. This is the same as the CTQ flow-down in the DfSS Optimize phase <LINK>.
Advantages and difficulties
The advantages of the V-model are that:
- it gives a clear structure and logical sequence of steps. This means tasks and responsibilities can be clearly assigned to sub-development teams.
- it forces early thinking about test plans, test procedures and measurement methods.
The difficulties are that:
- it may not be possible to test individual modules independently. For example, for medical X-ray tubes certain important parts (e.g. the anode and cathode) can only be tested once it has been build into a vacuum tube. In such cases, it is often hard to assign failures of the total system to such parts.
- the V-model is inflexible with regard to changes: when something changes in the requirements during the innovation project, all higher-level requirements, test plans and possibly even measurement methods must be updated accordingly.
For more information, please contact Bert Schriever.