Verification adds no value and should be eliminated from the system life-cycle.
From the point of view of quality control, verification (and to a lesser extent, validation), is no different to inspection. Anyone who has taken to heart Deming’s teachings on the quality understand that inspection does not produce quality; it can only detect problems (and only some of the problems), but can neither prevent them nor fix them.
Deming on Inspection
“Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. As Harold F. Dodge said, “You can not inspect quality into a product.”
What is Verification?
Verification is the act of inspecting an artefact to confirm that it meets the conditions it is subject to. For a manufactured products, this means it meets dimensional specifications, for example. In the case of a set of requirements, verification is about confirming that the requirements faithfully and completely address the agreed needs from which they were derived. That is, if the requirements are fully implemented, they would resolve the problems stated in the needs.
(Lou Wheatcraft extends the definition of verification to include assessing the requirements against policies on how to write requirements, but the distinction is not relevant for this post).
Why is Verification a Waste of Time?
Whatever the scope of verification is, it’s about taking the artefact that is the set of requirements, and comparing it against the source from which they were transformed, in this case, the stakeholder needs. If a discrepancy is found, then a different set of activities (not verification) is taken to fix the problem. Verification DOES NOT transform the set of requirements. According to the principles of lean, any activity that does not transform the product can be considered a waste that should be removed if possible.
Why do we need to perform Verification?
If it’s a waste of time, why do it? The primary reason is because the methods and procedures we use to transform the set of needs into the set of requirements is imperfect; it provides us no guarantee that the transformation is complete.
Think of that transformation as the function F(). We can model F() as:
F(N1, N2, N3, … Nn) = Ra, Rb, Rc, … Rz
where the set of R’s is the perfect set of requirements required to satisfy the set of needs (the N’s). If F() was perfect, and could be executed perfectly, we would not need to perform verification of this transformation. The R’s we get perfectly deliver the set of needs N.
However, the resulting set of R’s is seldom perfect, because of two reasons:
1. We do not have a function F() that can produce it perfectly
2. Whatever imperfect versions of F() we have, we do not execute it perfectly.
Therefore, we need to inspect the result (but what is that method we use to inspect and find the gaps? Could we not have used that in the transformation? No, because it’s not perfect either)
To further illustrate, when were taught how to do long division, we were also taught how to verify the results. To divide 27 by 3, we execute the long division process to get the result:
F_division (27 / 3) = 9
To verify that the resulting output (‘9’) is a correct transformation, we use another function F_multiplication():
F_multiplication(9 * 3) = 27
If F_multiplication() results in a number that do not confirm the results of F_division(), we review the execution of the function, not the function itself.
Until we have a similar function or process or algorithm to transform needs into requirements, we are forced to do verification. We can continue to look for ways to become more and more efficient in this waste activity, but we should attempt to keep improving the transformation function so we do less and less verification
