Michael Jackson
Addison-Wesley, 1995.
Michael Jackson
Addison-Wesley, 1995.
ISBN 0201877120 (paper)
Buy it from Amazon.com
Buy it from Amazon.co.uk
Michael Jackson is one of the very few requirements engineers who is almost a household name - even if one discounts the risk of confusion with a rock singer. Jackson Structured Design, and more recently the concept of Problem Frames, are among his achievements.
This is the first of Jackson's books to focus entirely on requirements. As always, he is sharp, convincing, refreshing, and on occasion wryly humorous. He blends his own writing seemingly effortlessly with quotations from philosophers Ayer and Popper, computer scientists Dijkstra and Babbage, managers, novelists, and logicians. His accounts slip equally fluently into pseudocode, his own style of Context and Frame Diagrams, and even formal predicate logic - without losing his readers.
Reading a page of this book is quite unlike the feeling of ploughing through the average computer science textbook. The experience is light and heady: what C.S.Lewis is to theology, Alan Watts is to mysticism, or Bertrand Russell is to philosophy, Jackson is to specification. In short, this is a wonderful book to dip into and savour. Whatever subject Jackson chooses, he finds something intelligent and thought-provoking to say.
The topics covered include ambiguity, brilliance, connection frames, dataflow diagrams, events and intervals, frame diagrams, graphic notations, ... In fact, the book is what the subtitle states, an alphabetically-sorted 'lexicon' of not-quite-randomly selected essays on what are plainly important fragments of the Jackson world view. The cover illustration suggests a virtual beachcombing experience, and perhaps that is just right. In a way it seems a pity that the pieces do not add up to a picture of the whole field, nor to a method as such. Perhaps Jackson has a book on Frame-Oriented Requirements Engineering up his sleeve. (This guess was correct; see review of Jackson's Problem Frames 2001)
Instead, readers get suggestive reflections, one step removed from actual practice. How, for instance, can one decide if a development method is suitable for a problem? When might it be appropriate to use formal logic or mathematics to prove that an algorithm is correctly specified? This might sound old-fashioned, but:
"A programmer's failure to solve this [mutual exclusion] problem was responsible for several deaths. The Therac-25 was a software-controlled radiation therapy machine..."
Jackson carries the argument to the reader in an essay which begins with the barbed phrase 'Real Engineers...':
"Make a list of all the languages that you use in all your development activities... include only languages that you have used for real work at least once. Your list might include one or two programming languages along with ... Dataflow Diagrams, State Transition Diagrams and Decision Tables.Now ask yourself which of the languages on your list you would choose to say these things, and how easily you would say them:|
- The lift can't move from the nth to the n+2th floor without passing the n+1th floor."
After nine other challenges in the same vein comes the sting in the tail:
"Did you find it all easy? I didn't."
It is this combination of penetrating intellect and sympathetic humanity that is the signature of Jackson's greatness, and the appeal of this little book. As he comments in the essay on Dekker and the mutual exclusion problem, the elegant simplicity of the right answer is both "illuminating and humbling".
Software Requirements & Specifications contains much that is timeless - some problems haven't changed since Heraclitus. Opinions date more rapidly. The decision to discuss use cases in a paragraph as an example of a frame suitable for transaction-based problems, while not exactly wrong, does look a little curious.
This is a book for the practitioner with some years of experience into which Jackson's hints and gentle reprimands may fit. Programmers and computer scientists may equally enjoy his lightly worn mantle of erudition. Beginners would be best advised to start elsewhere. Incidentally, much of what Jackson writes about software also applies to systems.
© Ian Alexander 2000
You may also like:
