ISBN 1580537707
Buy it from Amazon.com
Buy it from Amazon.co.uk
"You folks start coding.
I'll go find out what the requirements are." (page 31)
Ah yes. With Dilbertesque humour along the lines of Fred Brooks' Mythical Man-Month, it is at once clear that Goldsmith knows what he's up against: requirements are seen as obvious, trivial, small bits of documentation that can be left for an idle moment... and projects break time after time as a result. The challenge isn't to do anything terribly complicated; it's to get something simple done properly. As Richard Stevens used to say, "Making good wine is simple, but not easy".
Goldsmith, an experienced consultant, enters a crowded market with a distinctively different requirements book: on discovery. There are very few other books on requirements discovery as such, though many (such as Alexander & Stevens' Writing Better Requirements) touch on it. Ellen Gottesdiener's Requirements by Collaboration is certainly a discovery phase book, though it largely focuses on use case workshop techniques.
But perhaps discovery (despite the title) isn't the half of it. Much of the book is about what Goldsmith calls "testing" the requirements:
Moe: I know 20 ways to test business requirements.
Joe: Well, there's the regular way...
Moe: 21 ways! (page 17)
The two things are of course tightly coupled -- there is no such thing as a tidy waterfall going from discovery to documentation to validation and testing: these things go along together. In fact Goldsmith eventually lists no fewer than 64 techniques, of which 11 are specifically about "revealing overlooked requirements" (which itself is about validating a requirement set), and the rest are about "testing" or validating the requirements, though in the process they'll often help to discover requirements and fix requirement weaknesses.
Chapter 1 looks at the disconnect between what everybody says: that requirements matter a lot; and what everybody does: they work on projects doing the wrong things and doing things wrong because the requirements were poor.
Chapter 2, The Regular Way, looks at traditional review techniques. The hint in the chapter title is, plainly, that there is a whole world of exciting and better alternatives.
Chapter 3, Real requirements, goes into the "as is" versus the "as should be" (what Michael Jackson calls the indicative and optative moods), and takes a critical look at the Business vs System requirement distinction.
Chapter 4 looks at evaluating the form rather than the content of requirements. Goldsmith rightly points out that rules don't apply evenly across the board; he'd surely agree with Søren Lauesen's Software Requirements - Styles and Techniques that different forms are needed for different situations -- a security requirement looks very unlike a reliability one, for instance. So the different "tests" -- magic words, ambiguity, being positive, etc, are guidelines rather than absolutes.
Chapter 5, Discovering real requirements, begins by observing the commonplace, that users never know what they want. Requirements, in other words, cannot be captured, but must be invented, hunted down as Detective Columbo hunts villains by piecing together the available evidence.
Chapter 6 seems in some ways to be the heart of the book: the Problem Pyramid. This is a simple but powerful technique - something like a template - identifying the problem, the measurable benefit before and after, the cause (as is) of the problem, the what (should be), and the how (system spec, design). This is good stuff, simple and effective, and not I think quite like anyone else's approach (though it contains hints of Tom Gilb's Gist and so on, and of Suzanne Robertson's Fit Criteria).
Chapter 7 is on Applying the techniques.
Chapter 8 is called Data gathering, but actually it's much better than that: it's about requirements discovery, elicitation, detective work, whatever. It covers a wide range of techniques from surveys and literature searches to prototyping, JAD, observation and work experience, and a detailed chunk on interviewing. The advice is supplemented by solid warnings (surely based on experience) and a worked example. An excellent chapter.
Chapter 9 is called Formats for analyzing requirements, but it's about the need to find out what we don't know, which means becoming aware of it, a paradoxical thing at best. This is very much a fresh take on the familiar types of analysis diagram, plus some that might be less familiar, such as cause-and-effect graphing (a simple and elegant way of drawing business rules). The different techniques each give another angle on a problem, an approach that Goldsmith calls "taking a CAT scan" from the complex medical imaging technique that reveals hidden details in three dimensions.
Chapter 10, Key to completeness, looks at that most difficult attribute, whether a set of requirements is in fact good enough to go. One way is to document end to end scenarios using swimlanes to give a "customer view" (he means operational stakeholder). This is obviously essential (in some form): omitting it is a major cause of project failure.
Chapter 11, Formats for documenting requirements, dives into IEEE Std 830-1998 (which you might think a not particularly wonderful standard); then looks at Use Cases ("today's most commonly favored format for documenting requirements"); and then the more traditional "hierarchical itemized deliverables" (like Mazza, for instance) that constitute the "as should be" part of the Problem Pyramid. These are supported by a dataflow model of the high-level conceptual design.
Chapter 12, Finding overlooked requirements, suggests a list of "tests" such as whether you've forgotten any interfaces or quality requirements, whether you've checked to see if you conform to laws and regulations, and so on. These are all sensible, corresponding to the use of templates for NFRs, and stakeholder modelling.
Chapter 13, Checking requirements accuracy and completeness, proposes another twenty "test" methods, many of which are Sommerville & Sawyer-like good practice guidelines. The chapter covers a great deal of ground in a few pages, and some of the "tests" such as "balancing conflicting requirements trade-offs" deserve much more than the half-page that they get.
Finally, Chapter 14, Measuring [the] proof of the pudding, goes into cost-benefit analysis and other checks of whether you have got, or will get, what you want. One is to "define system requirements". Of course whole volumes have been written about that; but perhaps that's the point: people dive into specification and design before the problem is properly characterised. The hard bits are the easy bits, and vice versa. A little more attention to discovery and validation would be a good thing.
All in all, this is a very welcome book. It is practical and down to earth, to the extent that there is no bibliography, though in fact a score of references are scattered through the chapters. It is not that Goldsmith is not aware of the literature; rather that from a practitioner's viewpoint, he mostly sees little need to refer to other sources. The exceptions are to make a specific point, and they have an industrial feel -- the Standish Group (the Chaos report), Fagan (inspections), the IEEE software engineering "body of knowledge".
If you are involved in creating or reviewing requirements in industry, this book is essential homework. It's not too long, and every page contains practical and worthwhile advice. Buy a copy now.
© Ian Alexander 2004 You may also like:
