Dean Leffingwell and Don Widrig
Addison-Wesley, 2000
ISBN 0201615932 (boards)
Buy it from Amazon.com
Buy it from Amazon.co.uk
This chunky handbook of almost 500 pages is a serious attempt at covering the whole field of Requirements Engineering from the viewpoint of Rational. Leffingwell is a VP of Rational and the developer of Requisite Pro, so traceability is unsurprisingly illustrated with matrices in that tool. Widrig is a consultant who trains Requisite Pro users, and the Series editors' names speak for themselves. That said, the book is not a sermon on the merits of Rational tools and methods, though there is an appendix on the Rational unified process which formalizes the book's approach. The book provides instead a wide-ranging and reflective account of the problems, people, processes and causes involved in putting requirements together. The style is direct and personal: ".. we described storyboarding ..", and the issues are discussed openly and practically.
The book is divided into an introduction and 6 parts, named Team Skills. These are introduced with drawings, mercifully not clip-art, of people sitting at computer desks and thinking collectively into little clouds. The introduction looks at the problem, the Requirements Engineering solution, and the need for software teams which Rational sees as including the requirements engineers. This is plainly one possibility, another being that a customer organization engineers the requirements and uses them to obtain what they want from a software house. The issue of whether there is anything to distinguish software from any other requirements is not raised.
The Team Skills are analyzing the problem, understanding user needs, defining the system, managing scope, refining system definition, and building the right system. These titles are evidently somewhat artificial, but they broadly reflect the stages in a well-adapted approach to large system development: model the business, find out the user requirements, specify the system at high level, and make sure that what is built is what you asked for. The stages 'defining the system' and 'refining' reflect the Rational idea of putting together an outline of a complex system in a 'vision document', essentially a high-level system architecture, then scoping this down to realistic proportions, and then writing software requirements and adding detail to the use cases.
The approach is definitely object-oriented but the authors are aware of other approaches and make an effort to be fair. For example, the chapter on 'technical methods for specifying requirements' in the 'refining the system definition' team skill section covers pseudocode, finite state machines, decision trees, flowcharts, ERDs, object analysis and DFDs. The authors rather grandly state that "each is worthy of an entire book on its own" -- a bit of an exaggeration in the case of several of these techniques. Humour emerges, however, when comparing the effects:
"Data flow diagram models run the same risk as ERD models [being difficult for a nontechnical reader to understand, but ..] there is a larger danger in using DFDs in today's world; the OO folks will think that you are a 'functionally decomposing data modeler' and thereby fossilized matter and will ignore everything further you have to say on any subject."
At least it's clear which camp the authors are in; what is more, the descriptions are both short and readable, arguing the pros and cons of each technique. It is also good to see that even use cases are considered on their merits, and the authors recognize there are times when use cases aren't ideal. In particular, once use cases have been built up with additional details to serve as software specifications, they can become quite complex. Other techniques may be easier to understand.
The problem of illustrative examples is handled quite neatly with a fictitious case study for residential lighting automation. The case study is referenced throughout the book, and a nearly complete set of 'artifacts' - project documents - is provided in an appendix. The book's approach reveals itself as rather too heavy for the example project, suggesting a possible concern: no real account is taken in the book of the needs of smaller projects. The appendix is however a useful and informative document in its own right, and would certainly be helpful for getting a project up to speed with object-oriented requirements management.
The book is well organized and indexed. The bibliography is, like the book, intentionally non-academic but contains a sensible list of practical and readable books on software, systems, requirements, objects, process modelling, and use cases. It is perhaps a slight pity that these topics are not itemized, nor are summaries provided.
Curiously, the authors do not define their target audience or for that matter supply a use case for the book. It is certainly aimed at the larger model of systems development, where subsystems are expected, and where software is dominant. Hardware is in fact mentioned, so the software in the title is not to be taken too seriously. The book contains no exercises for students, so the readership must be presumed to be practitioners who want to systematize their approach on larger projects. I think this book will prove quite helpful for that audience, as it describes a wide range of techniques accurately and clearly, in a practical step-by-step way, with a reasoned discussion of the pitfalls. They will not be dissuaded by the relatively high price, as the book contains much that is of value.
© Ian Alexander 2000
You may also like:
