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