The more time I spend running software projects, the more convinced I become that a strong requirements process is the hardest part.

This is an excellent book that covers developing a strong requirements process. Wiegers doesn’t cover underlying philosophy (see Kovitz or Jackson), but he provides a useful reference. The book outlines many good practices – and his point about “good practices” versus “best practices” is well taken, but it is not as well organized as some other toolbox-style books.

A big part of establishing effective requirements gathering is selling the management team. This book doesn’t really tackle this challenge.

The sample project is helpful, but I wish Wiegers had gone the last mile and attached the project requirements documents as an appendix.

Despite this list of gripes about what the book doesn’t do, it has many, many good points and is written in a clear, if not lively, fashion. Recommended.

If you are looking for a very direct, down-to-earth approach to developing and managing requirements, this is the book for you. If you believe that managing requirements is overhead that you cannot support, you need to read this book. Karl takes a very practical approach to requirements development and management. He explains his approach in a succinct manner and provides very good examples to make his point. This book should be a mandatory read by all software development project managers, whether they come from the business or technical side of the business. Additionally, Karl’s book makes good reading for anyone who is affected by the development of a software system such as business visionaries, end-users, quality assurance, business analysts, technical writers, trainers, and developers.

Karl Wieger’s book is destined to be classic in software requirements. It delivers a large set (over 40) no-nonsense best practices in highly readable, non-nonsense manner. I believe every project manager, IT (Information Technology) and business analyst, and IT account manager should read this book. Further, developers would do well to read it to gain critical insight into the ‘big picture’ of requirements engineering.

The book is broken down into three sections: the case for requirements engineering best practices (“What and Why”), the requirements discovery, verification and validation process (“Software Requirements Engineering”), and the essentials of requirements management (“Software Requirements Management”). Throughout, the dual necessities of doing requirements right (verification) and doing the right requirements (validation) is addressed. Wiegers has thoroughly delved into the literature in the software requirements field. The text is liberally spiced with tidbits of data to support the business case for implementing these best practices. I found myself making notes in the inside cover and folding back pages to reference again as I read through the book.

Early in the book, Wiegers presents a set of software engineering best practices which are classified into priority (high, medium, low) and difficulty (high, medium, low). Although you may disagree with the specific rankings for your shop, this table is an excellent example of modeling appropriate requirements engineering practices – prioritizing requirements! Other goodies abound. For example, a partial case study flows throughout the book which gives the reader enough of an idea of what a use case, dialog map, text requirement, etc. looks like to get the concept being resented. Each chapter ends with a concise list of suggested next steps, providing the reader with concrete actions to take to implement the practices covered in that chapter. In addition, there are numerous sample templates (e.g. Risk Item Tracking, Software Requirements Specification), several excellent checklists (e.g. Inspection Checklist for Software Requirements Spec, Software Elements Affected by a Proposed Change,), visual models (e.g. Requirements Traceability Links, Change Control Process) and a wonderful “bill of rights” for the software customer which boldly and directly asserts both rights and responsibilities of the customer.

A set of example models is provided in the chapter called “A Picture is Worth 1024 Words”. You will need to read other books or take training on the mechanics, notations and semantics of these models for visualized functional requirements. But the author covers the key models and their purpose succinctly.

This book is easy to read, cuts to the chase, and provides a bounty of information that will wet our appetite to take action. This book is not a requirements engineering method or methodology, which would prescribe step-by-step protocols of task, roles, and techniques. Rather, like the classic cookbook The Joy of Cooking, you will find well-proven, sensible, and reusable practices. In Software Requirements, you will find the right ingredients and essential practices needed to ‘cook’ tasty requirements.