Buy it from Amazon.com (commission paid)
Buy it from Amazon.co.uk (commission paid)

Other Reviews

2002 seems to be the year that Sam Gamgee returns from the War of the Rings to scatter the magic earth from the land of Lothlorien over the gardens of the Shire where we live - at least as judged by the profusion of new and varied books on requirements that have sprouted this year.

This book "is intended for the novice, in particular the undergraduate novice" and it should serve admirably for that purpose. Getting inexperienced students to appreciate the need for a practical systems engineering discipline and the tools and techniques that support it is a tricky problem, and few if any earlier authors have attempted it. Actually Bray is too modest: this is really quite a general introduction and it may make many an experienced practitioner reflect on what they do, and why. I'll also enter the too-familiar plea for systems not just software engineering; happily this book's message mostly generalises perfectly well to requirements for systems of many types, despite Bray's arguments to the contrary in the Introduction.

Ian Bray has written an engaging, lively, and exceptionally clear book. His skill as a teacher plainly contributes to his ability to write and to discover requirements effectively. He has made an entirely fresh attempt at organising our domain, with some success. Better, he does not merely describe a list of techniques you can apply: the book steps through a credible process - in part 1, from elicitation to analysis to specification to validation; in part 2, through techniques for all of these - and shows how the different approaches contribute to getting the right system. Few other books do this; Sutcliffe's new book does, but in a far more detailed and researchy way. These are very welcome signs that RE is beginning to mature: something coherent can be said about each stage and also about different types of problem.

Bray is fresh and funny on the errors of the past: why did Structured Analysis fail? Why did people call SA approaches methodologies when these weren't even methods? For instance:

Ironically reflecting the 'Victorian novel' problem that it was introduced to combat, a morass of documentation was produced, much of it modelling the detailed process of a pre-existing system. It is highly questionable whether [such a] process .. is a matter for detailed study anyway; the process of the problem domain, certainly, and maybe the function of a pre-existing system but that is not the same thing.

It might have been seen as a clue to the problem that sometimes much of this documentation was not used. After expending a great deal of effort .. on its production it was simply side-lined.

This is at once witty and serious, light and reflective, though we may wonder whether the novice will appreciate its subtleties.

How can we do better? Bray's recipe is a mixture of techniques for elicitation and analysis and modelling, including more than just a graceful bow to Michael Jackson's Problem Frames.

Much of the Analysis chapter explains in detail how to select and apply Problem Frames - in fact forming a detailed and readable introduction to the topic. He's very good on things you probably thought you knew, like Decision Tables and how to optimise them -- the reader is invited to try to make the simplified table smaller, which is possible (I did it) but which (surprise, surprise) makes it harder to understand. And like Kovitz, who is also one of Bray's heroes, he's good on making requirements readable:

[Avoid] Duckspeak - meaningless padding and tautologies, e.g. 'The lift request validation function will validate lift requests'.

Quack, quack indeed.

Unfortunately the book also contains a few mistakes.

• Tacit knowledge does not just mean stuff 'considered too obvious to mention'; it's to do with what 'we know but cannot tell', such as skill, as Polanyi says.
• Reviews do not need to walk through documents - it is often better to walk through the change requests instead.
• Several diagrams risk confusing "the novice" with wrong labels, e.g. Figure 4.40 swaps the reality and machine boxes.
• It isn't true that RE happens at the start of software projects; it is strongly connected with acceptance and verification, not to mention tracing requirements during partitioning into separate hardware and software subsystems.
• Design constraints are far from rare as claimed - at least in railway, telecommunications, and aerospace, to name just a few domains; indeed, non-functional requirements often make up well over half the specifications. It seems peculiar to classify safety, security, reliability and durability as 'performance' when people typically use that term to cover speed and capacity requirements.
• The Jackson structure chart / entity life history diagram in Figure 13.18 breaks the syntax rules for such diagrams, as well as failing to span the life history by omitting installation and decommissioning: two cardinal Jackson sins in one diagram. Jackson himself explains how to do it right in the Tree Diagrams section of Software Requirements & Specifications.

The lack of system focus is clearly shown up in the absence of a discussion of traceability, which to industrial ears is the crucial thing that enables us to get our requirements met. Indeed, atomic requirements are dismissed as those

that may be expressed in one sentence and which are at the lowest level of abstraction short of detailing the physical details of the interaction… Perhaps the terms are best avoided.

But no, we trace back to individual 'atoms' to ensure we have met them and can verify (e.g. test) them. We know we don't have an atom when we can see there are two things to be tested. It matters very much when we want to ensure that our subcontractors have indeed done every single thing we needed.

Happily, Bray more than makes up for this with well-crafted and often witty explanation and discussion. The organisation of the book, the glossary and other helps are all excellent. The book's value on undergraduate courses is enhanced by exercises at the end of each chapter in Part 1 ('The Topics'), though there are none in Part 2, and no answers seem to be available. For instance, the reader is invited to complete a process model diagram; to match ten descriptions to ten RE terms; to classify 25 statements as problem domain, commercial constraints, design constraints, functions, or performance; to devise a problem frame for a small problem.

There are also good examples, which are both used throughout the text and then listed out to a reasonable degree of non-repetitive completeness in Part 3. In the space of fifty pages this describes four systems with elicitation plan, elicitation notes, requirements, and specifications (incidentally, this is a characteristically clear and workable naming convention). These show students (and practitioners, perhaps) how the products of each activity help to make the requirements clear. The range of examples is interesting - yacht racing results; the dreaded lift controller; a drilling machine's data file translator; and a Petri net diagramming tool. Happily, at least two of these are certainly system problems.

Teachers of university courses will find this a serious (if unusually readable) contender for the role of introductory text. There aren't many existing rivals; Sutcliffe's excellent book is intentionally far more advanced; Kotonya & Sommerville has a strong slant towards viewpoints and conflict resolution (scarcely mentioned by Bray); Alexander & Stevens isn't intended as a university text and doesn't cover analysis, though it is introductory and has detailed exercises (with answers); the Robertsons' is actually quite suitable but is designed for industry.

More experienced practitioners may also find it useful as a light introduction to techniques that came into service since their graduate days. It's a very welcome addition to the literature.

© Ian Alexander 2002-3