Suzanne and James Robertson
Addison-Wesley 1999
£29-95 (boards)
ISBN 0201360462
Suzanne and James Robertson
Addison-Wesley 1999
£29-95 (boards)
ISBN 0201360462
Buy it from Amazon.com
Buy it from Amazon.co.uk
Einkaufen von Amazon.de
Disponible chez Amazon.fr
This is a requirements book specifically about process (in contrast, say, to Kovitz).
The book is based solidly on the Robertsons' own experience. James is a management (i.e. requirements!) consultant, and Suzanne would have been called an expert Requirements Engineer quite a few years ago, if the term had been invented then. The writing is clear and plain, if without the Kovitz sparkle.
The approach is quite traditional, at least as far as nomenclature is concerned. The chapter on Non-Functional Requirements, like many in the book, reveals Suzanne's background in analysis, as Yourdon-style dataflow diagrams relate processes to products. Fortunately, Stakeholders make an appearance, communicating their 'wants and needs' and (startlingly) receiving the 'rejects' (rejected requirements) from the quality gateway: the accepted ones make it into the 'requirements Specification'.
The Robertsons do live in the modern world, though: they have a clear idea of identifying objects as 'things' and 'work areas', and they skilfully combine old-style analytical thinking about topics such as work context with a practical treatment of use cases.They can stake a strong claim to being practical, as they propose a fully-worked out method, VOLERE, which they explain in detail in the book.
Suzanne Robertson in particular makes much of the concept of the Fit Criterion - pretty well the same as an Acceptance Criterion: how do you know whether the proposed solution fits the need? Systems engineers should not need telling that requirements have to be verifiable, nor that defining what is expected of acceptance tests is a good idea. The fact is, though, that the Fit Criterion message still needs to be preached to a sizeable audience.
The Robertsons are efficient and systematic engineers, and it is comforting for the reader to come across statements like 'This is how we intend to proceed:' – followed by, in the Event-driven Use Cases chapter, a straightforward bulleted list of steps leading neatly to 'Derive the requirements for each use case' at the end. Of course the list is a scenario, even if the reader does not know it at that stage: the Robertsons practise what they preach.
One of the real strengths of the Robertsons' book is the inclusion of templates for each of the work products that the book advocates. For example, a non-functional requirement is illustrated as a card, pre-printed with attributes for Requirement #, Type, Event/use case #, Description, Rationale, Source, Fit Criterion (the key Robertson concept), Customer Satisfaction, Customer Dissatisfaction (!), Dependencies, Conflicts, Supporting Materials, and History. The approach is thorough, pays proper attention to people, is perfectly suitable for use with paper and card-indexes instead of computers, and may not suit everyone. The danger is that the sheer amount of detail on what has to be done may seem overwhelming.
The marginal icons may irritate some readers - a raised thumb for 'Rule of Thumb' is at best pedestrian; the clip-art graphics are not the finest; and the Yourdon process model of the requirements process itself is a wonder of the analyst's art rather than something to refer to daily. But the text is good and reliable, and the advice if followed step-by-step actually works.
This is a useful and interesting book for practising systems engineers. It may also be a good reference for students, as it has a thorough glossary and bibliography, and would introduce students to the human processes of dialog and feedback between different groups of people so essential in requirements engineering.
© Ian Alexander 1999