Review By: Scott McMaster
12/22/2008Making the most of the requirements process is critical to the success of almost all software projects. This book explains how requirements management relates to and enhances the practice of other systems engineering disciplines. The book contains some interesting insights into requirements development such as dividing the process between definition of scope and definition of requirements, yet the true focus of the book is on the management of requirements after they are produced.

The authors define requirements management as "the sum of all activities in connection with requirements that take place after the requirements have been developed or engineered." Following that theme, the second and longest part of the book takes a detailed look at how requirements can be leveraged to improve processes in other areas of systems engineering, including project, quality, risk, configuration, test, change, and version management. A chapter is devoted to each of these disciplines. Perhaps the most useful parts of this section are the examples and suggestions for how requirements can be linked and used to enhance other documents such as the project plan, risks list, and test plan.

The final section introduces the authors' Hood Capability Models for Requirements Definition and Requirements Management. These models could be used to guide and track an organization's process improvements in the requirements domain as it relates to the rest of systems engineering.

Despite the quality content in the book, it suffers in places from awkward grammar and typographical errors. "Requirements Management" would be most useful for professionals working within a process improvement framework such as CMMI. The requirements management approaches and capability models described in the book would fit in quite naturally in such an environment and likely lead directly to improvements in several process areas. Agile practitioners would find the book considerably less helpful. The relative lack of formal documentation produced by most agile teams would limit the applicability of many of the techniques detailed in this book.