Review By: Noel LeJeune
04/25/2011The value that author Klaus Pohl brings to the requirements engineering discipline in this book is scope. While the author claims a target audience of nearly everyone, it is primarily a comprehensive textbook for graduate studies in requirements engineering. However, it is also a reference book for practitioners with many useful techniques for requirements engineering in any software development effort. The book makes a fairly reasonable and successful attempt to synthesize the entire body of knowledge related to requirements engineering.

Reasons you might not add this book to your library include: You do not need a reference that covers most aspects of requirements engineering. You are unwilling to read a detailed, thorough textbook with explicit definitions and descriptions of principles, techniques, and practices of requirements engineering. You have previously read and synthesized into a fairly comprehensive body of knowledge nearly every topic and technique of requirements engineering.

The book’s thirty-eight chapters (over 800 pages) are organized into eight major sections. The first four chapters provide the fundamentals and framework. The remaining thirty-four chapters discuss core activities such as the many elicitation techniques, documentation, and negotiation, as well as three chapters on validation and four chapters on requirements management. The breadth of coverage includes topics ranging from a discussion of the many requirements elicitation techniques to the details of using finite automata (deterministic and non-deterministic) and state machines.

The writing style and organization make the book easily readable despite its origins in an earlier, less-thorough German version. At times the author follows the overly verbose model of “tell them what you are going to tell them, tell them, and then tell them what you told them.” For example, the discussion of key disadvantages of using natural language for requirements (Chapter 17: Natural Language Documentation) includes several pages describing four kinds of ambiguity (lexical, syntactic, semantic, and referential). As you would expect from a good textbook, each chapter is well organized with many logical subheadings, examples to illustrate the material, and literature recommendations for additional reading.

The shortcomings are few but significant. The entire context of the book seems to presume a very heavyweight software development process. Only a three-page discussion of continuous requirements engineering acknowledges different software development models. The book makes no attempt to situate the requirements engineering activities in the context of any particular development model–least of all within the context of agile software development. The reader is left with the problem of determining how to practice good requirements engineering in any specific software development process, which could be a challenge for agile development projects.