Quality tool training a mistake-Start with Understanding Requirements

[FVoehl@aol.com]

In a message dated 3/2/01 4:03:36 AM, SOPKrules@aol.com writes:

<< Look at Dr. Deming's business as a system diagram.  It only portrays 
information and/or materiel flow.  People appear as things (entities).  The 
diagram doesn't portray the coordination of commitments although it may be 
implied.  Implication is not enough - coordination of commitments is at the 
heart of the action in any humanly lead system.   >>

Bob raises some interesting points in his post and underscores the need to 
better understand the coordination of requirements process--that part of 
development where people attempt to discover what is desired.  Dr. Deming 
understood this process and had us focus on five critical words above:  
desire, product, people, attempt, and discover.  I will briefly cover  them 
in this post. (For a more exhaustive treatment, try the book *Understanding 
Requirements* by Donald Cause & Gerald Weinberg {ISBN 0-932633-13-7}). 

Desire: Some people would prefer to always say--attempt to discover what is 
needed--but we usually don't know how to figure out what people need, as 
opposed to what they desire.  By clarifying their desires, people sometimes 
clarify what they really need and don't need.  They don't always buy what 
they need, but they always desire what they buy, even if it is only for a 
short time.

Product:  By this is meant any product that attempts to satisfy a complex set 
of desires.  One reason that desires are complex is that they come from 
people.  When we build a product to satisfy our own desires, we often don't 
need an explicit requirements process.  We just build it, observe our work, 
and make adjustments as we go along.

People:  This might include many different people and discovering who the 
people are is a major part of understanding the requirements process.  The 
problem is, when there are many people involved, and the product is large or 
abstract, the kind of iterative process used to discover personal 
requirements may simply be too drawn out and costly.  The DEN is a good 
example of this.

Attempt:  If we're writing a post about WED and his philosophy, shouldn't we 
be more certain and more positive? Before Deming and Shewhart came along, 
many people thought that product development was an exact discipline.  Dr. 
Deming once quoted John von Neumann, the founding father of software:  
*There's no sense in being exact about something if you don't know what 
you're talking about.*  If people don't know what they want, then no SoPK 
development process, no matter how exact and clever and profound, will 
satisfy them. Which is why we need to start with requirements, so we don't 
design systems that people don't want.

Discover:  This is a most critical word, for we all are trying to help people 
discover what's really worth doing.  Dr. Deming once said:  *The plan is 
nothing;  the planning is everything.*  What he meant was:  the product is 
really nothing;  the process is everything.  As in the discovery is nothing;  
the exploring and discovering is everything.  A Data Dictionary is a way of 
preserving the Operational Definitions that are painstakingly derived with 
the aid of SoPK.  In practice, however, hardly anyone reads the Data 
Dictionary, or possibly any of the documents that at are developed in the 
requirements process.  The reason is that the document is nothing;  the 
process of documenting is everything.

The process of developing requirements is somewhat neglected in the systems 
development literature, which is why Dr. Deming put such an emphasis on 
developing operational definitions.  For it helps us do a better job of 
knowing what we are talking about.

Frank Voehl (FVoehl@aol.com)