Information Technology Reference
In-Depth Information
techniques with sound processes for validating that one understands
correctly what is represented.
How to Specify a Problem
It is true, as the saying goes, that a problem clearly
stated is already half solved. It is also true that a prob-
lem cannot be efficiently solved unless it is
precisely
described.
The (paper manufacturing) plant was working well
when suddenly it was discovered that small pieces of
wood were coming through in the dried, finished
sheets of paper. It was immediately assumed that some-
thing was wrong in the pulping process, that one of the
huge stainless steel screens had broken. …
However, one man was not blinded by his papermaking
experience. He did not take the “obvious” explanation.
Instead, he closely examined the troublesome pieces
of the paper and found that these were not softwood
chips but hardwood splinters; moreover, they had
never been cooked or chemically treated. Then he spot-
ted a hardwood pipeline used to transfer the pulp to
the papermaking machine. He told his colleagues that
the lining of this pipe must be breaking up on the inside
and let the hardware splinters get into the pulp mixture.
…his explanation was finally checked out and found to
be so, proving that the problem had nothing to do with
the pulping equipment. This might have been deter-
mined at the outset if the problem had originally been
precisely specified as “uncooked hardwood splinters in
finished paper” instead of simply “pieces of wood in
the paper.”
—From
The Rational Manager,
Charles Kepner and
Benjamin Tregoe
When systems fail, one often finds that either the requirements were
wrongly specified or that the application was not built to specifications.
There are, therefore, two possible problem areas that one must watch out
for:
 
Search WWH ::




Custom Search