Thirty years of confusion . . .

Another Implicit Data Dictionary Example

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 cweisert@acm.org and we'll show the best ideas in a future article.

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 for 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 agile and test-driven project.

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.


1 -- Scott Ambler: "Scaling Test-Driven Development", Dr. Dobb's Journal, February, 2008, p. 71

2 -- Chris Gane & Trish Sarson: Structured Systems Analysis: Tools and Techniques, 1979, Prentice Hall, ISBN 0-13-854547-2.

Return to table of contents
technical articles
systems analysis topics

Last modified January 15, 2008