Verification vs. Validation - What are the differences?

[Helmut Jilling]

In Reply to Parent Post by mmantunes

I think the main problem is that the definition of the standard is generic, and don´t show how it fits in the process.

For example, from the definitions it´s difficult to understand things as shown in the waterfall model below.

What about the diagram is hard to understand? Design verification tends to be on paper or electronic, verifying that all the inputs were addressed and expected to be achived.

Validation is generally performed on an actual part or prototype part to determine whether this sucker will meet the customer or user needs. I think it does a great job of showing the links.

[Jeff Frost]

mmantunes

Yes they are but they are also used in conjunction with the requirements contained within the Standard Your waterfall model is only showing pictorially what is required by clause 7.3

[Marcelo Antunes]

Your waterfall model is only showing pictorially what is required by clause 7.3

Which is the original questioning of this thread.

[w_grunfeld]

In Reply to Parent Post by mmantunes

Hello

Verification would verify that the input requirements are met.....this not not mean that necessarily the intended function is met, because the input requirements in the design phase could be wrong translated from the costumer requirements.

Well if your design input requirements do not include the intended function, you've got a big problem pal, regardless how we play with words...
If a glucose meter does not measure glucose level in the blood , I would not bother doing any other activities whether you call them verification or validation, just scrap the project and start all over.
Gentlemen, in the real word, not all is definitions and auditor's opinions.
ISO is too generic to debate the meaning of this or that word.
What counts is how we interpret ISO to adapt it to real life. I hope all agree at least that validation is to be done on a production sample , meaning a product that was manufactured to the same documentation, processes and machinery used /to be used for the actual production run.
If we agree as much, than simply any paper review, inspection, measuement or test that is performed on anything other than a production product is verification.

No one in his right mind would release a design to production prior to thoroughly verifying the design. (Even if the ISO auditor says that according with section so and so , that's validation) Who ever says that design inputs can be verified on paper or electronically only , hasn't faced a technologically complex product.
For any product that is somewhat complex (more than a fiew simple parts ) design verification is actually done in several phases and steps. No one would spend tons of money to even prepare for production (tooling alone could cost a bundle) without verifying every aspect of the design.
As for design inputs/intended function here is a joke that is actually based on fact:
I worked once upon a time on a fighter aircraft project.
The spec was somewhat like 700-800 pages and it referred to a few dozens other documents, totalling thousands of pages.
One day at a meeting , someone threw a remark: "Have you noticed that nowhere in all these thousands of pages does it say that this thing has to fly !"
And he was right.

[vanputten]

I don't understand what this debate is all about and I don't understand W_Grunfeld's arguement towards the other postings. Verification and validation are different things and both important.

Verifiy the design requirements are met, whatever they are. Does it have a wing? An engine? Does the thing have everything as detailed in the 700 pages?

Validate that the thing meets its intended purpose. Does it fly as the customer would expect?

Do verification and validation how your organization best beleives it is effective. In unique independent events, in stages, concurrently, ...............

[w_grunfeld]

"Verification and validation are different things and both important."
No one said otherwise ......
Read the beginning of the thread : the question was what is considered verification and what is validation. When people started to give specific
examples, most were mixing up between the two.

To the best of my knowledge I did not post anything "against" other posters. I did argue some of others opinions, isn't this forum excatly for that?
The 700 pages airfraft spec was a joke- there is really no need to comment on jokes.

[Randy]

In Reply to Parent Post by w_grunfeld

To a certain degree it is, we just need to ba careful how passionate that agument is.

You'll find that some folks have no sense of humor, so one has to be careful. (Most of them don't go to the bathroom either)

You provided pretty good comment, just hang in there and stay involved.

[Kevin Mader]

More for the mix…

Customer need: chocolate cake

How will this be specified? Milk chocolate, dark or perhaps a blend? If I gather the ingredients, develop a recipe, mix the ingredients and bake the cake, will the customer be happy?

Through verification activities, I can confirm that my inputs are correct, the proportions correctly measured, and blending and bake times correct. There’s still no guarantee that the customer will like my chocolate cake, but I did create a chocolate cake.

Through validation, I need to confirm that I’ve met the consumer’s expectations (requirements). Did I use enough chocolate or too much? Was the cake moist and fluffy? All the bench testing (verification) in the world can’t confirm that I’ve met expectations. I must have the consumer’s (user’s) confirmation. It's the one that counts!!

Marketing specifications, which are usually vague, establish the general customer requirements. These must be refined into more detailed requirements (which can take the shape of product requirements) for engineering. Here, the engineering team establishes design requirements on how they plan to fulfill the customer needs. These might be thought of as to how the engineering team plans to mechanically and electronically establish the product the customer wants. These initial design requirements will undergo an iterative design process until final input requirements can be established. Often times, engineering test is performed during this development phase (sniff testing), but this is not yet design verification. Customer preference testing might also be done at this time to further dial in the product requirements. Design verification will occur later after the final design inputs have been established, generally in the form of a design requirements specification. Design Verification activities trace directly to the Design Inputs. Design Validation is performed to confirm that the customer/end user requirements (intended uses) have been met. As noted in Randy’s post, both activities are important, but separate.

Potential document/activity hierarchy:

· Marketing Specification (top level user needs sometimes called a User Needs Document)
· Product Specification (engineering translation of user needs)
· Design Requirements (initial design inputs, perhaps broken down into subordinate requirements documents for recognized disciplines such as mechanical, electrical, software, etc.)
· Design Requirements Specifications (final design inputs)
· Design Verification (confirmation of final design inputs)
· Design Validation (confirmation of user needs)

It has been my experience that mastery of these two concepts is difficult. I suspect that this is why there is disagreement amongst us Covers, especially for those folks who seldom engage in validation activities. The thing of it is that through continued discussion and debate, we continue to refine our theory of what verification and validation are. For me, I’m always in a curious mode to refine my own theory, so I enjoy these types of exchanges.

Enough for now, so back to the group…

Kevin