Verification vs. Validation - What are the differences?

[Stijloor]

In Reply to Parent Post by AndyN

And there I was thinking they were called Charlatans.........

Some Charlotteans are charlatans.....

Stijloor.

[reaganmom]

In Reply to Parent Post by Stijloor

Some Charlotteans are charlatans.....

Stijloor.

Depends on the neighborhood

[michellemmm]

In Reply to Parent Post by reaganmom

Hmmm....to be perfectly honest...I'm not really sure!
I guess I"m just struggling with the entire design concept. When we took the manufacturing company in as a division of our company, we took their designs and drawings and made them our own. But, since we're manufacturing, I was told that we do need to include 7.3 in our QMS. I hope this makes sense...I'm starting to confuse myself!

Susan,
I use a simple circuit board manufacturing example when I have to explain the difference between verification and validation.

In PCB manufacturing I ask:

1- Did you design for the right component to be at right location with correct polarity?
In circuit test (ICT) or inspection will verify those requirements...(Design verification)

2- Did the circuit board pass functional test? (Design Validation)

Hope this helps.

[w_grunfeld]

In Reply to Parent Post by michellemmm

Susan,
I use a simple circuit board manufacturing example when I have to explain the difference between verification and validation.

In PCB manufacturing I ask:

1- Did you design for the right component to be at right location with correct polarity?
In circuit test (ICT) or inspection will verify those requirements...(Design verification)

2- Did the circuit board pass functional test? (Design Validation)

Hope this helps.

Sorry , but I have to disagree.
First off, you call your example as being from PCB manufacturing while in fact you refer to a PCB Assembly !
The right component being at the right location with the correct polarity is not a design verification, it is an inspection to verify that the assembly was done correctly (assembly vs. blueprint)
If it is intended as a design verification, it should be done before a board even exists through:
a)design review - verify that the schematics is correct (incl. calculations, simulations, etc)
b) layout vs. schematics
c) tests and measurements on breadboards , etc.
Functional test is definitely verification and not validation (assuming it is done on a first-off or small sample)
All of the above is done in a lab (room temperature)
Validation type activities (in your example) would be:
Functional testing over the entire specified temperature range (min. and max. specified temp)
Same as above with the board installed in the target application (rack, box or a mockup that would simulate surrounding thermal environment)
Testing that the board meets spec over the entire range of specified input voltages
EMI testing (immunity to RF radiation and emission meerting specified limits, when applicable)
Other environmental conditions (humidity, vibration, shock, etc. as and when applicable - think of a board for a laptop or mobile device- it may work perfectly in the lab but shatter to pieces when dropped on the floor).....and so on and on, depending on the intended functionality and use environment. There might be also regulatry issues involved. All of the latte are Validation.
To sum it up, design verification are all tests, inspections and analysis intended to verify that the design has the capability of performing its intended function.
Validation is to verify that this capability is maintained over the entire range of inputs, stresses, environmental conditions, regulatory and safety requirements and over production variability (tolerances0
Hope this clarifies the difference ...

[joshua_sx1]

In Reply to Parent Post by reaganmom

Our company just recently aquired a manufacturing division. This required me to remov our 7.3 exclusion(much to my dismay). I created a controlled form that requires all of the measurements to be checked and recorded after the product has been made. Can this be my validation? If so, how do I show verification?

Thanks in advance!
Susan

…well, first of all congratz to your company because it means that you are expanding for adding processes…

…anyway just for clarification only, when you mentioned that you acquired a manufacturing division, that includes adding design & development process?...

[Marcelo Antunes]

To sum it up, design verification are all tests, inspections and analysis intended to verify that the design has the capability of performing its intended function.

Validation is to verify that this capability is maintained over the entire range of inputs, stresses, environmental conditions, regulatory and safety requirements and over production variability (tolerances)

Hello

I still think there´s something misinterpretations...intended function is related to validation, not verification...just see the definition in the beginning of this thread. So any "tests, inspections and analysis intended to verify that the design has the capability of performing its intended function" would be a validation process..."also, verify that this capability is maintained over the entire range of inputs, stresses, environmental conditions, regulatory and safety requirements and over production variability (tolerances)" would also mean validation.

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.

[Jeff Frost]

In Reply to Parent Post by Randy

Always use you References..

ISO 9000:2005 defines the answer to your question as.......

3.8.4
verification
confirmation, through the provision of objective evidence (3.8.1), that specified requirements (3.1.2) have been fulfilled

NOTE 1 The term “verified” is used to designate the corresponding status.

NOTE 2 Confirmation can comprise activities such as
— performing alternative calculations,
— comparing a new design specification (3.7.3) with a similar proven design specification,
— undertaking tests (3.8.3) and demonstrations, and
— reviewing documents prior to issue.


3.8.5
validation
confirmation, through the provision of objective evidence (3.8.1), that the requirements (3.1.2) for a specific intended use or application have been fulfilled

NOTE 1 The term “validated” is used to designate the corresponding status.

NOTE 2 The use conditions for validation can be real or simulated.

3.8.1
objective evidence
data supporting the existence or verity of something

NOTE Objective evidence may be obtained through observation, measurement, test (3.8.3), or other means.

Here's how I like to put it.............

Verification checks whether the design meets the original specifications (design input).

Validation checks whether the new product works (does it do what it's supposed to as it is supposed to do it).

Both are important, but different ways of looking at a new product.

The input to for example would be NASCAR regs, but also would include and the owner/engineer/driver input. One of those inputs might have to do with the speed the vehicle needs to be capable of. That speed requirement is translated into an engine design in terms of displacement, horse power, torque, etc.

When the engine is designed and built we 'verify' that it is the displacement specified, supplies the specified torque, produces x amount of horsepower. This is design verification.

We then take it to the track to determine if it can meet the speed requirement, which is the 'end user' requirement. Does it perform? This is design validation. Now, in theory, we should do the validation under use conditions, which would imply running it in a race. In fact, the validation probably is performed in a more 'sterile' condition with just that vehicle on the track.

In retrospect, every flight of every Space Shuttle has been a "Validation" flight to test the new design under actual conditions. No 2 shuttles have ever flown in the same configuration and many systems cannot be validated except under actual conditions.

Randy got it right the first time by quoting the requirements of the standard yet everyone is still trying to define this question. If these are the internationally acceptable definitions of the two terms per ISO 9000 and mandated by ISO 9001 then there is no redefining the definitions to meet personnel preferences.

If an industry, through contract requirements, or as required by law (regulatory/statutory) modify the ISO definition then that is fine. We as implementers or auditors must remember that if we are to comply with the requirements of the international standards we must also use the agreed to language.

[Marcelo Antunes]

Randy got it right the first time by quoting the requirements of the standard yet everyone is still trying to define this question. If these are the internationally acceptable definitions of the two terms per ISO 9000 and mandated by ISO 9001 then there is no redefining the definitions to meet personnel preferences.

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.