by Conrad Weisert
January 14, 2008
© 2008 Information Disciplines, Inc.
Scott Ambler's column1 in the new Dr. Dobb's Journal resurrects a disturbing example from Gane & Sarson's classic structured analysis text.2 In presenting techniques for specifying decision logic, Gane & Sarson offer this example of an informally stated requirement (p.79) that might be captured from a user representative:
|Customers who place more than $10,000 business per year and have a good payment history or have been with us for more than 20 years are to receive priority treatment.|
Now an experienced systems analyst will immediately grasp that the requirement statement is loaded with ambiguity. Furthermore, the requirement contains several implicit data definitions, which we've noted before are extremely dangerous. Worse, still, the values of some of those data items are hard coded, a practice we deplore in source code that undermines system quality even more in a requirements specification.
Mr. Ambler's incompletely stated "feature" specification is similar, dealing with a discount rather than priority treatment.
How would you write it?
Suppose you're a systems analyst and have gotten the above
informal requirement statement from a naive end user representative. Making reasonable
guesses about the user's intent, how would you incorporate a rigorous, unambiguous,
and maintainable specficiation into the system specification?
Send your solution to
February Update—Based partly on comments from readers, we put together further discussion of this example, still not finished.
Gane & Sarson go on to show how to formalize the requirement in a decision tree, in a
decision table, and in structured English. They prepare an explicit data dictionary entry
good payment history, but retain the other
implicit data definitions and repeat the hard coded values throughout the examples.
An experienced programmer should decline to implement the decision logic or its context
until the ambiguities and repetitions are resolved. Similarly,
Mr. Ambler goes on to discuss how the requirement would be implemented in an
I wonder whether a generation of systems analysts and programmers have been influenced by Gane & Sarson's book or by a course based on it, and have then contributed to the unreasonable cost of software maintenance. And I wish that more of our younger authors would profit from the past 30 years of maturing systems analysis methodology.
2 -- Chris Gane & Trish Sarson: Structured Systems Analysis: Tools and Techniques, 1979, Prentice Hall, ISBN 0-13-854547-2.
Return to table of contents
systems analysis topics
Last modified January 15, 2008