Discovering Requirements: How to Specify Products and Services [Paperback]

Ian Alexander's latest requirements book is a pleasure to read. He and his co-author have succeeded in producing a book that represents the latest thinking in requirements management.

The authors approach their task in a typically rigorous manner by describing firstly different requirements elements, then different discovery contexts, before combining both elements and contexts to suggest approaches for different types of project.
Among the highlights of the book are:
- A lucid explanation of Alexander's onion model for stakeholder analysis, put in context using goal diagrams, where stakeholders' aspirations are mapped to look for any conflict early in the project.
- The use of the Soft Systems Method to capture the soft boundaries of the project environment before formalising it using context diagrams and event tables.
- Some simple but effective ways to capture high-level scenarios in a workshop environment.
- Using goal analysis to capture constraints and qualities. There is a lot of material in this chapter, including some that will be increasingly important in coming years, such as sustainability.
- The use of rationale models and goal structuring notation to document assumptions.
- A large chapter on measurements, with a balanced approach to the debate on whether acceptance tests are a substitute for requirements statements (a view promulgated in the Agile world), leaving the reader to decide what is best for his or her circumstances. Recognising that many large projects now include a service element, there is a sizeable section on quality of service measures.

After a comprehensive section on contexts for discovering requirements, the section on trade-offs gives a number of methods, such as principal component analysis, for formalising the often-unstructured way that design options are chosen.

One of the strengths of the book is that it is un-wedded to a particular method, tool or diagramming style; and the focus on systems engineering projects, with side-references to software-only projects, rather than the other way around as found in many texts.

I predict that this excellent book will become the standard requirements reference work for serious practitioners and one to be re-read frequently for new insights. Those coming from an Agile software background will find much to learn (and challenge!) from the more formal approaches presented, while those from a rigorous systems engineering background will find food for thought in options for a softer, collaborative approach and an emphasis on scenario-based structure.

Fantastic book! Have you ever struggled to find out what your customer actually wants? And after you're well on the way with your project, you start getting customer comments like: "yes, but..", "I didn't mean that..", etc. And then you begin to feel like "uh, oops, we really should have elaborated more on defining the requirements...".

But the term defining implies that your customer tells what they want and you write it down in a meeting, polish later on, and that's it. Go on and start a project ... and problems like above surfaces.

Requirements need to be discovered and this is the best book on how to systematically "tease" out what the customer (=stakeholders) want, what are they assuming, but not saying unless explicitly asked, etc.

The "abstraction level" is very good, not too cookbook specific and not too academically general. Text is very readable and clear and well structured.

This book helps you to direct your (and your customer) thinking to obtain desired goals, and thus is valuable also for people outside the engineering field.

I have never bothered reviewing a book on Amazon before, but for this I have made an exception. I have over 20 books on requirements engineering, and I can say without hesitation that this is one of the very best. This is an extremely readable and useful book.

This book is well organised, practical and insightful. The authors propose a matrix of "Elements" and "Contexts" for requirements discovery. Following this model, the book is divided into two parts; Part 1 - Discovering Requirement Elements (with chapters on Stakeholders; Goals; Context, Interfaces, Scope; Scenarios; Qualities and Constraints; Rationale and Assumptions; Definitions; Measurements, and; Priorities), and Part 2 - Discovery Contexts (with chapters on Requirements from Individuals; Requirements from Groups; Requirements from Things; Trade-offs, and; Putting it all Together). In the Introduction, the authors state that requirements specification can be considered to be a network of related elements, "...and indeed, the chapter structure of this book can be seen as a customisable template for organising the requirements on your project."

If pithy quotes are a good measure of the value of a book, then this is a great book. I stopped scribbling down quotes by page 10 when I had amassed the following:
* "Requirements are discovered by the use of appropriate inquiry techniques. They are not sitting about, waiting to be `captured'."
* "Discovery, however surprising and delightful the actual moment of realisation, comes as a result of a deliberate search."
* "Projects need to pay attention to discovering their requirements, using a battery of complementary techniques..."
* "Perhaps the projects in greatest danger from poor requirements work are those that seem fairly small and simple, but turn out to contain hidden complexities."

In addition to the quotable quotes, the book is also crammed with well-crafted expressions and valid observations. A few that I liked are:
* "goals and stakeholders work together"
* "ill-defined boundaries"
* "interfaces aren't just hardware"
* "requirements archaeology" (gathering requirements from documents)
* "Requirements Chef" (a lovely concept, included in Chapter 15, "Putting it all Together")
* "no two projects are alike"

This book is unusually easy to read and extremely well structured. Each chapter begins with a couple of sentences defining the questions that the chapter will answer. Next is a paragraph summarising the chapter. The reader can therefore establish, in less than a minute, whether a chapter is likely to help them with their immediate problem. Following the main body of each chapter (all of which are also very well structured), there is a "Bare Minimum of..." which, as the heading suggests, defines the least you should do for this element or context. Each chapter also includes a small but valuable set of Exercises and suggested Further Reading.

Many people involved in system development (still) talk about "users" as a homogeneous group. Increasingly, more enlightened people talk about "stakeholders" - but I am not convinced that stakeholder analysis is actually taken seriously in many developments. For this reason I'd argue that chapter 2 of this book ("Stakeholders") is essential reading for every systems engineer/business analyst/project manager. There is a strong emphasis in this chapter (and throughout the book) on the importance of stakeholders and consideration of stakeholder roles. As ever, Ian Alexander is quick to remind us that we should always consider negative stakeholders.

The book comfortably straddles what might loosely be called "theory" and "practice". The breadth and depth of the authors' experiences are woven throughout, with no awkward distinction between concept and application. The final chapter "Putting it all Together" does exactly what it claims. Included in this chapter is an essential table of "possible discovery context/requirement element approaches" and a set of case studies that illustrate how an element/context matrix may be populated for a specific project.

Having read the book and made some notes for this review, I tried an experiment. I randomly opened the book in half a dozen places. On each page I quickly found something interesting and useful. I tried the same experiment with a range of other requirements books, and not one of them was nearly as satisfying. I don't suppose this is how the authors intended the book to be used, but it does give a good indication of its quality and value. There is no filler in these 450 pages. I wholeheartedly recommend this book.