Michael Jackson
Addison-Wesley, 2001.
Michael Jackson
Addison-Wesley, 2001.
ISBN 020159627X (paper)
Buy it from Amazon.com
Buy it from Amazon.co.uk
This is in many ways a deeply practical book, but anyone who knows or has read anything by Jackson will know that it must also be razor-sharp on theoretical issues.
One of Jackson's precepts is that one should not invent yet more notations - unless there is very good reason. And especially, one should not propose yet another method for describing problems and solutions - unless all existing methods are inadequate.
Well, this book makes it clear that Jackson believes there are grave weaknesses in current practices. Problems are confounded with solutions; requirements that purport to be about the one are often about the other. The idea that one can write requirements for a system without knowing what it will be - a burglar alarm that is either electronic or a flock of geese - is risible. And the claim that one can identify a point where the requirements are stable and complete is just plain wrong.
In that case we need to think about the problem first, and then, using knowledge of the world and of systems, identify a pattern that accurately relates problem to solution, and conduct analysis and design on that basis. This is not far from what the Object-Oriented community has been claiming for some time, but Jackson does not entirely agree with their prescriptions.
For a start, he does not hold with Use Cases:
The use case view can work quite well when it makes sense to think of the machine as a facility offering discrete services that are used in clearly delimited episodes.
Hmm, yes, Michael, but that is quite a lot of machines actually -- almost anything that provides someone with a screen and a keyboard or pointing device, for a start. And while having clearly delimited episodes is the cleanest case, the keep-on-doing-this-as-long-as-you-need-to sort of problem seems reasonably susceptible to the use case treatment as well. Think of describing a driver's interface to a car - subproblems like steering and stopping are perfectly describable, even though we know they interact and go on more or less continuously. The cases are not 'steer the car' but must consider how to stop the car while steering, so there are more cases than immediately appear. The question is whether the approach is worth applying, or whether a different and perhaps novel approach like problem frames would be better.
In addition, Jackson doubts whether large-scale patterns as posited by the OO 'Gang of Four' often apply:
The ideal use of problem frames is when your whole problem perfectly fits a recognised frame, and the frame provides an effective and systematic method of analysis and solution. It doesn't often happen...But in some cases, in a highly specialised and refined application area, a large composite frame is developed, and becomes widely accepted...
This is a healthy degree of scepticism, combined with a respect for the other guy's point of view.
In consequence, Jackson believes that we have no choice but to devise a way of dealing with problems and solutions at the same time, refining each as we come to understand more of both. If as is likely no fully-formed pattern can come to our rescue, then the only workable approach is to build up our own analysis pattern from domains and their logical interfaces.
 |
Problem Frames is a lively, vigorous, closely-argued book. It is exceptionally clearly written, always interesting and often provocative. A curious feature is that many of the sections end with an 'Any questions?' subsection. This contains questions that the interested reader might (possibly) ask, immediately answered in conversational if not indeed Socratic style: 'Surely the transformation frame .. should be forbidden. Your instincts are very admirable!...' This literary device won't suit all readers but the answers do give further information on more advanced topics, enabling the book to be read at different speeds according to the reader's appetite for detail.
It would not be appropriate to venture to answer the 64,000 dollar question, namely whether problem frames will or should take over from Patterns, Objects, and Use Cases as the preferred route from World to Machine. To some extent, choice of technique is governed by fashion; to some extent, by what is familiar. Only when fashion and familiarity let us down do we really start to look for other approaches.
This eagerly-awaited book is as good as everyone thought it would be. Jackson has expanded and systematised his thinking on problem frames, requirements, specifications, architecture, and much else. It is supported by a concise summary of the problem frame and related notations in an appendix, by a glossary that is as carefully crafted as any data dictionary, and by thorough references and indexes. The bibliography does not describe the referenced documents, but there are brief descriptions of the issues in many of the 'Any questions' sections and these do introduce some of the books mentioned.
This book will remain a key reference for anyone thinking about the roots of requirements engineering, its relationship to architecture, and the management of complexity for many years to come. It can be highly recommended to everyone interested in how we can improve our repertoire of techniques and build better systems.
© Ian Alexander 2001