Verifying Validation and Validating Verification

People (I guess we classify engineers as people) have always talked about verification and the "testing" of a piece of hardware to see if it works as the "same thing". Unfortunately for us there is a movement within international standards bodies (dating back centuries) to have us believe that there are really two types of testing: verification and validation.

Is your head spinning?

Validation is often defined as "checking if you built the right thing". Verification, in just as catchy a way, is defined as "checking if you built the thing right."

What is the right thing? Why that is the thing the customer wanted. So I can go with that. Who wants to build stuff the customer doesn't want? (Frequently many companies do this and go out of business. Others build things the customers don't want but convince them that they want it anyway -- that is worth a whole blog!)

In the book "Exploring Requirements Quality Before Design" by Gause & Weinberg (ISBN 0-932633-137-7 (C) 1989)Ā  a particularly brilliant comment is expressed in the preface:

If people don't know what they want, no development process -- no matter how exact, how clever, or how efficient -- will satisfy them. And that's why we do requirements work -- so we don't design systems that people don't want.

Boiled down: The right thing is the requirements!

My argument is that requirements exist everywhere in a system, at every level of abstraction and between every component. The customer is not just the entity that "buys" your system but is anybody or anything that express a requirement. You must satisfy the requirement then verify that you did so. The entity responsible for the requirement does not factor into the equation so I believe the distinction between "validating" and "verifying" as used in international standards is just confusing. (I see this all the time in the work I'm doing right now. The documentation is rife with confusion w.r.t. the usage of these very similar "v" words.)

Also, the idea of checking if you built (past tense) the right thing seems economically tenuous at best. Why build something then ask if it is the right thing? That seems awfully expensive. So, really what needs to happen is to validate the requirements themselves before the race starts, before the chicken hatches, before the horses get out of the barn, etc., etc., etc.

In my dictionary I would define validation as the art and science of confirming, checking, testing, and verifying that the requirements are correct. Correct in the sense that you know they properly specify what is needed. If you build the requirements right, the right thing will get built -- not as cute and catchy but a better statement of what needs to be done me thinks!

So, I require the phone number of the ISO President, Secretariat General, or head dude so I can let him in on the secret. If you have it drop me a line. Thanks!

Copyright (C) 2010 Aspen Logic, Inc. All Rights Reserved.