M. Elizabeth C. Hull, Ken Jackson and A. Jeremy J. Dick
Springer 2002
M. Elizabeth C. Hull, Ken Jackson and A. Jeremy J. Dick
Springer 2002
ISBN 1852335777 (paper)
Buy it from Amazon.com
Buy it from Amazon.co.uk
This very welcome book does something simple but special: it concentrates entirely on showing you what you actually need to do in a "common sense" way to get your requirements accurately stated, and what is more important, met. It avoids both academic pussyfooting and commercial arm-wrestling. Instead, it takes the reader through the sorts of things that simply have to happen for a project to be a success.
If there is one thing that the authors take for granted (from the first paragraph of the Introduction), it is that development and change are best organized through projects; and unfortunately not every manager even realizes that much. However, you have to start from somewhere. The very name Requirements Engineering (RE), though familiar to many people, may also mislead some managers into imagining that this powerful habit of thought is not for them, but for "oily rags" of engineers far down in their hierarchies: how wrong they are.
For what Hull, Dick, and Jackson so clearly and capably describe is nothing other than a practical recipe for making developments work. Every area has its own particular methods of analysis and design: if you are making an aircraft, you analyze airflow and fuel efficiency and carrying capacity; if you are making a telephone switch, you analyze transaction capacity, and so on. But one thing is common to all developments: you have to know what you are trying to do, the requirements. The introduction begins with the wonderful quotation:
There is no fair wind for one who knows not whither he is bound.
(Lucius Annĉus Seneca, philosopher, 3-65 AD)
and it sums up the task: define your goal before you start trying to get there. All development managers - take note.
The book provides, in the short space of some 200 pages: a crisp Introduction, a Generic Process for RE, a chapter on System Modelling for RE, a brisk tour of Writing and Reviewing Requirements (of course there is more detail on this topic in Alexander & Stevens' Writing Better Requirements, which focuses exclusively on that, though I say so myself), RE in the Problem Domain (i.e. what used to be confusingly called User Requirements), RE in the Solution Domain (i.e. system specifications); Advanced Traceability; and Management Aspects of RE.
The approach is simple and uniform. For instance, Modelling is introduced in a brief paragraph, then half-a-dozen representations including the familiar dataflow, entity-relationship, state-transition, and object diagrams are illustrated and discussed. Then a few typical methods, chosen to illustrate the range of possibilities, are discussed on a couple of pages each - though the examples used differ. Finally a short summary avoids saying which is best, instead arguing that all "have been widely used in industry". This practical stance gives the book a definite strength, and should be helpful to newcomers to the field. For instance, Table 4.4 gives 'boilerplates' (templates) for writing constraint requirements, such as:
Performance/capability:
The [system] shall be able to [function] [object]
not less than [performance] times per [units].
This is naturally rather prescriptive, and experienced hands may feel they can think of exceptions, but when you are starting out, simple rules are just what you need.
The only topic which is not necessarily suitable for readers new to requirements is the one on Traceability, and indeed the caution implied by the 'Advanced' prefix is justified. Jeremy Dick is well known for his work on Rich Traceability, and the chapter is a clear summary of his thinking. It is not the only proposed approach to presenting rationale and arguments in a logical form; for instance safety cases are often analysed with (diagrammed) AND/OR trees, sometimes weighted to show connection or belief strengths for more or less plausible pieces of argumentation. So this chapter should be taken as a practical proposal in a controversial field, unlike the rest of the book.
Ordinary traceability is as expected covered throughout the book: if you are going to drive a project by defining its requirements, it follows that you have to check that you have met them, and you do this by following traces from specifications, design elements, and tests back to the requirements.
A final chapter introduces DOORS: A Tool to Manage Requirements. This tallies with the use of the Telelogic logo on the front cover, and indeed the affiliations of Jackson and Dick; the rest of the book is entirely generic. The chapter also serves to present a worked example, based on the requirements for a family sailing boat; the example was originally chosen to show that RE was not just about software. Let us hope that many more books with this degree of clarity and usefulness now come from this stable.
The book ends with a sensibly thorough bibliography, presumably chosen to be accessible to practical people, though there are a few journal papers. There are no descriptions of the references, though the text does imply what each reference is good for, as for instance the pointer to Ward and Mellor (1985) for more on State Transition Diagrams. The index quickly took me to where I needed to go. There is no glossary, but the book gives readers a clear intuitive understanding of what the terms used mean in practice.
The authors have steered a course that Seneca would have approved of. The book is clear and well-organized, with no wasted discussion. It is practical, being based on the authors' daily experience of many projects, and it is easy to follow.
If you want a book to guide you through the concepts you will need to organize and manage the requirements for your development project, this may be the ideal book for you. The book might also be a good source for lecturers preparing undergraduate or MSc courses in requirements, software, or systems engineering, though it offers no exercises or projects as such, and students on such courses might also find it useful.
© Ian Alexander 2002