Book Review: Requirements Engineering
A good practice guide

Ian Sommerville & Pete Sawyer
John Wiley, 1997
.
 

ISBN 0471974447 (paper)

Buy it from Amazon.com
Buy it from Amazon.co.uk

Other Reviews

 

Sommerville has an excellent reputation for his research and his definitive textbook Software Engineering (5th Edition, Addison-Wesley, 1996) so I read this book with some interest. It is organised into the chapters that one might expect, from requirements elicitation through analysis, modelling, validation, and management to the ‘more detailed’ chapters on critical systems, structured methods, and formal specifications. Introductory chapters discuss process improvement and the requirements document. But below that level, it is organised as ‘guidelines where we make practical suggestions for improving requirements engineering processes’.

Each ‘guideline’ is a section (as 5.1, etc) whose title is a piece of advice, such as ‘Define System Boundaries’. These inevitably tend towards motherhood- and-apple-pie but are nevertheless good and useful concepts. Each section begins with four subheadings ‘Key benefit’, ‘Costs of introduction’, ‘Costs of application’, and ‘Guideline type’ (basic, intermediate or advanced). The first paragraph briefly expounds the guideline; the rest of the section, generally a couple of pages, enumerates the benefits and the means of implementing the suggestion, unfortunately largely unsupported by figures or tables. Examples of well-laid out requirements complete with identifiers, section headings, and attributes (priority, benefit, cost, systems affected, ...) would have been helpful.

The book does not present the reader up-front with a process or task model of the subject: this is surprising, as the introductory chapters are closely focussed on processes. The subdivision into some 66 short guidelines inevitably fragments the account; there is no particular connection between one guideline and the next. Chapter 2 does identify which guidelines are basic and which advanced, complete with a blank ‘Usage’ column for readers to fill in to suit their organization, but few readers can be expected to do this systematically.

Several important aspects of requirements engineering are scarcely addressed: for example the nature of tool support, or the basic distinction between user and system requirements. On this last point, for example, the reader is exhorted (in just over one page) to make a business case for the system, ‘as a separate section of the introduction to the requirements document’. Such a section could readily be overlooked, and a systems engineer might attempt to write one in a morning given the rather low importance the guideline seems to have: ‘There are no significant costs involved in introducing or applying this guideline’. On the contrary, the elicitation and refinement of business requirements, to describe the problem to be solved, may be an intensive, controversial and time-consuming process involving several reviews and all levels of management.

The book is rather IT-centric, as witness guideline 4.5: ‘The operating environment of a system consists of the host computer, ... and other hardware and software systems which will interact with the system’. Perhaps a bank’s customers using its teller machines, or the patients being carried in ambulances, are essentially computer peripherals?

In addition, there is not enough emphasis on the crucial role that requirements play in business: to manage risk. Risk is indeed discussed, but from the narrow perspective of assigning risk attributes to requirements: necessary but not sufficient. The guideline (5.8) is a little dismissive: the type is stated to be ‘advanced’ rather than ‘basic’ and ‘as risk assessment is not widely practised, the principal problem .. is the lack of people with risk assessment experience’. The book is very clearly and ably written, and is full of the accumulated common sense of some experienced system engineers. The guidelines are all useful and interesting, making many excellent suggestions. Experienced requirements engineers will want to look at a copy to see what Sommerville and Sawyer have to say; I’d be more hesitant in recommending it as a textbook for novices.

© Ian Alexander 1997