Design Input/Output and Design V&V (Verification and Validation) Interpretations

[dweebie]

Hi,

I was wondering is someone could help me interpret the following statements I once heard from a Design control expert:

***********************************

Requirements = design input: broader than specifications and concern (are derived from) intended use(s) and user needs (testable natural language).

Specifications = design output: translates requirements into detailed measurable descriptions (engineering language).

Requirements must be verifiable i.e. quantified through specifications in a way that can be verified.

It might require several verification-results (against specifications) to demonstrate compliance to one single design input requirement.

*****************

To me this sounds as is requirements (design input) are verified by demonstrating that the derived specifications (design output) can be met, because the underlying assumption is that the specifications meet the requirements. Validation, on the other hand, is done by testing directly against the requirement (which represents the user needs and intended use). But how does this fit with: "verification must show that design output meets design input"?

I found an blog entry on mddi, which in my opinion supports the above, by stating that "design validation is really what happens near the end of the design or redesign of a medical device, it is done as a set of various activities to answer the question, does this design solution actually perform and function as I intend it to and does it meet my user needs. Design verification activities provide theoretical assurance that the design is appropriate in regards to your defined design input requirements, design validation provides evidence beyond theoretical that the device you designed is truly safe and effective within the context of those same design input requirements".

In additions to this, the FDA state in their "Medical device quality systems manual" that "design verification is always done versus specifications".

Do I understand the concept of verification and validation correctly? How do you interpret the above?

Best regards

 

[Marc]

<snip> "design validation is really what happens near the end of the design or redesign of a medical device, it is done as a set of various activities to answer the question, does this design solution actually perform and function as I intend it to and does it meet my user needs. Design verification activities provide theoretical assurance that the design is appropriate in regards to your defined design input requirements, design validation provides evidence beyond theoretical that the device you designed is truly safe and effective within the context of those same design input requirements". <snip>

Yup - That's it in a nutshell.

Verification = Theoretical (the old "According to my calculations...")
Validation = Actual as determined by testing (often done on a prototype, but in some cases validation is done through actual use - depends upon the product and the industry).

 

[dweebie]

Thanks for your quick reply. I really appreciate it.

The blog entry's real message is that validation is more than user testing (which is a common misconception). As I see it right now, validation is basically about simulating use scenarios, to check that the device indeed does what is required of it in the real world post release, including by the users. This could concern e.g. driving a car into a wall (can our design really survive a real-life crash), taking a plane on its first flight (can our design really fly), confirming the shelf-life of a product through accelerated tests (can our design really last 2 years) etc.

Does this sound right?

 

[Marc]

That's my understanding.

 

[gholland]

Validation is also ensuring your device meets the user needs. How you define your user needs is up to you but as you develop an idea you would have a set of user needs you are trying to meet. Something like 'the customer needs the device to be used in xxx environment' for example. Then you would go out and show that the device is usable in whatever environment you chose (laminar flow hood, clean room, whatever). You have to show that you understand what the user needs are and that your device meets them.

 

[dweebie]

Thanks Gholland for your reply. I agree with what you say - validation is also about demonstrating that the device meets the user needs, in addition to intended use(s).

As I understand the literature on Design controls, user needs + intended use(s) are expressed as (organized into) testable design input requirements (the "what", written in a language that all stakeholders can understand), such as "the device must tolerate being used in xxx environment for the stated period of time" (similar to your example). Specifications are the "how" (translated from requirements), and are typically concept-dependent. The link between requirements and user needs is called requirements validation. The link between implementation and requirements is called design validation.

What do you think? Any comments anyone?

 

[Marc]

Typically ensuring your device meets the user needs starts in the design stage prior to design verification. User needs is part of the design process "front end" inputs.

Validation is more "Does it work as intended".

 

[Julie O]

21CFR 820.3 Definitions:

Verification means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled.

Design validation means establishing by objective evidence that device specifications conform with user needs and intended use(s).

 

[deethreepio]

I am dealing with a little different situation. It's a little off subject but I was hoping to get your opinion on the following:
If design validation is proving that a representative device meets the user requirements using objective evidence, and process validation is proving that a process can reliable create that same device, should IQ/OQ activities for process validation occur prior to design validation?

Thank you

 

[Julie O]

D3, I just sent you a friend request. I'm thinking this will allow us to communicate offline, which is probably a better way to help you with this question.