David
Gelperin
ClearSpecs Enterprises, 2017.
David
Gelperin
ClearSpecs Enterprises, 2017.
ISBN 978-0-9989162-0-0 (paper)
Buy it from Amazon.com
Buy it from Amazon.co.uk
There are around 67 requirements books on the market (and reviewed here), and given that they all have their own takes on the subject, they might be thought to cover every conceivable angle. Gelperin states up front that the old silver bullet, the Waterfall method with its lengthy specifications, has been replaced by another, the Agile method. Requirements look very different, but they're still difficult: he lists 12 reasons, from stakeholders who're unclear or who disagree, to tacit knowledge, misunderstandings and rapid technological change. So why yet another book? Gelperin argues that other books tell the (waterfall) story of elicitation, analysis, specification, and validation, but omit stakeholder understanding, demonstrations that the developer understands too, quality attributes (in which he includes goal definitions), and requirements risk analysis, among other things. He cheerfully admits that the book is not for beginners, and does not list analysis techniques. Instead, it focuses on how experienced practitioners can develop an understanding of a project's requirements.
With this goal in mind, you can see why the book is organised as it is. It begins with a discussion of how to develop an understanding that is "task-adequate". Requirements are stated to be a combination of local or crosscutting requirements, including many domain functions; negatively stated requirements (things that must not happen); and imprecise requirements, sometimes embodying intentional vagueness. The book moves on to how to demonstrate the developer's understanding: Gelperin's experience in testing is evident here, and it's certainly the case that a tester is a valuable person when it comes to reviewing requirements. But the techniques go far wider: prototyping ("functional code"), personas and misuse cases all get a mention. "Skeptical review" is advised, and compared to proof by contradiction. On the technical side, hazard analysis, FMEA, fault tree analysis and more are listed: the reader is referred to the chapter's sources for the details.
The quality goals chapter has its own website, evidently representing one of the author's major interests. Here, Gelperin talks not of (traditional) non-functional requirements but of quality attributes, quality goals, and quality "debt" (what's missing, "undefined or unachieved quality goals"). The account acknowledges the subject's complexity: only a small subset of the types are actually listed, safety being taken as a "fragile" example (fragile since it depends on so many other things), and it's listed in a figure that takes up three pages. Gelperin notes drily that the complexity of the illustrations of quality goals indicates how much is missing from current quality models, even including the ISO standard (25010).
The specification chapter is interesting for carefully not talking about "requirements". Instead, it speaks of RIFs, requirement information fragments (not to be confused with the tool vendors' requirement interchange format). RIFs include many old friends, from natural language to modelling languages, scenarios, diagrams, and equations, but also rules, charts, "facts", definitions, pseudocode, mockups and prototypes, even references to specifications from other projects (which must then be reviewed). It's a motley list, and absolutely not something you could give to beginners. The checking chapter, naturally, turns a critical eye to how you can know that a specification is of good quality: it's mainly lists of bullet points, each one ("walk through critical scenarios") a great deal of work.
The basics covered, attention moves on to custom approaches rather than pure Waterfall or pure Agile. The chapter discusses the characteristics of project situations, such as when the customer is expert in the domain and the developer is familiar with quality goals but unfamiliar with the domain, and so on. There are evidently very many combinations, and Gelperin actually states (without explanation) how many there are: apparently 1,889,568 for the Waterfall's "sweet spot". Customisation becomes necessary when a predefined life-cycle doesn't do what your project needs, depending on risk and other attributes. It's fascinating stuff, but definitely not for the faint-hearted.
The requirements management chapter covers 8 activities such as planning the requirements work, managing its risk, handling its conflicts, and sorting out its configuration in a database (the work of a requirements management tool, and a conspicuously small part of what the book covers).
The final chapter singles out managing requirements risk, something that is handled "immaturely" in many organisations, to their great cost later. Again, a lot of the text is lists of bullet points: Hazards to requirements, including unfamiliar domains and disruptive stakeholders (ah yes); hazards in requirements; and hazards associated with defective requirements, such as missing, imprecise, infeasible and unvalidatable: these are of course hazards to the whole project. The "tactics" for managing these risks are described in a set of well thought out checklists: each checkbox ("manage stakeholder understanding") will get sage nods from the experienced and baffled looks from the novice.
Gelperin writes in short paragraphs, and speaks only about concepts: the effect is compact, even compressed. The reader is expected to be attentive, and where necessary to follow up the references: Chapter 2, for instance, lists 23 sources, including books, papers and a YouTube video: the papers are on the book's website. Each chapter has its own one-page table of contents, giving much more detail than the outline table at the front of the book. There are few diagrams; one or two cartoons (like the blind men and the elephant); quite a few hierarchies which should be more than sufficient hints for engineers wanting to structure documents; some screenshots; plenty of bullet points. Important points and key books are emphasised in boldface. The material has evidently been thoroughly tested in training courses.
This is, as stated, a very different sort of book from standard requirements textbooks. It is for a limited and unusual audience, experienced practitioners. Normally, to state the obvious, authors write mainly for students or newish practitioners, because they're the people who want to learn, whether from a "dummies' guide" or a traditional text. Experienced practitioners only want to consult a book when, to be frank, a subject is so difficult that it's too costly to learn it from experience: in other words, they have the scars to prove they're experienced, and they're receptive to other practitioners' collected wisdom. The book has plenty of the "I tried this and it worked" feeling about it; its many sources demonstrate years of going to conferences and reading around the subject, picking out approaches that work in each area. As such, it's an overview, almost a set of "notes to self", a distillation of process knowledge.
© Ian Alexander 2017