by Karl Wiegers
Microsoft Press, 1999
ISBN 0735606315 (paper)
by Karl Wiegers
Microsoft Press, 1999
ISBN 0735606315 (paper)
Buy it from Amazon.com
Buy it from Amazon.co.uk
Einkaufen von Amazon.de
Deutsche Ausgabe
Disponible chez Amazon.fr
Wiegers has set out to write a practical book for engineers, and in the main he has succeeded. By choosing the Microsoft press - not noted for RE - he has certainly brought the subject to the notice of engineers, and very possibly of some major software development organizations, who have up to now never heard of it.
It seems he has also decided not to try for the crowded academic course market, as there are no exercises beyond a well-thought out self-assessment questionnaire. This might be a pity, as the plain but organized approach could easily lend itself to coursework.
Wiegers has managed the prodigy of squeezing the table of contents onto one page - a risky decision - with three sections: What & Why, Requirements Engineering, and Requirements Management. The attempt to draw a firm distinction between RE and RM does seem a little forced, though there is a neat hierarchy diagram in Chapter 1 which explains the classification. Indeed, on Wiegers' system, section 2 should have been called Requirements Development instead.
The What & Why begins with an imagined story which at least gives the reader something to focus on. The need for RE is established briefly and at once; then Wiegers dives happily into definitions, risks, and benefits. The story is clouded by some diagrams that come close to contradicting the text, and there is a brave attempt to distinguish constraints, non-functional requirements, and quality 'attributes'. Fortunately the practical tips on these matters later in the book are perfectly usable.
Chapter 2 introduces the customer's perspective in a way that may be eye-opening to RE newcomers. There is a rather good 'Bill of Rights' for customers - but also a 'Bill of Responsibilities', emphasizing the 'contract' of partnership between customer and developer.
Chapter 3 leaps into good practices - effectively introducing the rest of the book. It extends the list given in Sommerville and Sawyer and organizes it helpfully into sections such as elicitation, analysis, specification, and verification. This shows the span of RE in the software (and for that matter systems) lifecycle, and also classifies the practices in two dimensions - difficulty and priority - on the page. Whether or not one agrees that, for instance, basing plans on requirements is highly difficult, it is clearly a high priority goal.
From there, Wiegers moves into processes and risk - both areas that involve management as well as engineering - and then into the body of the book. The ten chapters of section two span scope, the voice of the customer, documenting requirements, pictures (worth a thousand words...), quality 'attributes', prototyping to reduce risk - a very practical approach, prioritisation, quality, and beyond.
Section three looks at RM, by which the author means handling change, traceability, and tools. Few books dare to compare tools and this one does little of it, but the effort is welcome nonetheless.
Wiegers' strength is his evident experience in handling requirements in industry: this brings both a degree of engagement with the reader and a certain homespun quality. One claim to fame is his concept of 'Product Champions', people who take the customer's cause throughout the process: or perhaps, several people who champion several stakeholders' causes.
Topics such as inspection and estimating change are very deftly handled. The use-case pitfalls are helpful and the templates and other helps quite usable.
Wiegers tends to be uncritical of techniques he has used; for instance, dataflow is simply accepted and described as an option: "you can elaborate the context diagram..." without pointing out the dangers. Some other diagramming techniques are simply not covered.
The readable text is rather weakly supported by the figures, apparently because the Microsoft press policy doesn't like diagrams much. There are a reasonable number of these, but they are sometimes confusing and unhelpful. For example, the figure 'Some possible requirements traceability links' arrives at Project Task Plan by the uninspiring link 'connects to', while simple trace relationships are variously labelled 'drives spec of', 'is origin of', and 'is addressed by'. Other attempts are happier, as with the sensible project metrics of requirements progress (proposed - approved - implemented - verified - deleted) with time, or the simple but effective bar-chart showing sources of proposed changes.
Things that are unaccountably not in the index include Stakeholders, Workshops, and (Problem...) Domains, though to be fair these things are discussed one way or another in the text.
This is an honest and workmanlike book which should prove a useful resource and stimulus to the people Wiegers calls 'developers' unused to RE. It is perhaps strongest on the use of requirements to manage projects, weakest on object-oriented techniques.
There is a good and quite up-to-date bibliography to take the reader further; each chapter ends in some practical ways to take the 'next steps', and the self-assessment appendix may well provoke some serious reflection. As already mentioned, students and others who prefer a tutorial approach may miss the lack of exercises.
At US$34-99 or a rather less cheap UK£32-49 (recommended) the book is a good buy for the software developer. As with several other texts, the restriction to software is probably calculated to attract the programming community: systems engineers will find that everything that is said in the book applies equally to requirements for systems.
© Ian Alexander, 2000