Review By: Lee Copeland
12/30/2005"Defining business requirements is the most important and poorest performed part of system development." So begins "Discovering Real Business Requirements for Software Project Success" by Robin Goldsmith. Business requirements, unlike user requirements, define what a system must do to provide value to the organization. Many software projects ultimately do not satisfy organizations simply because the business goals were never defined. This book helps the reader effectively identify those requirements.

Goldsmith’s background as a software tester adds a unique perspective to this subject. He emphasizes that all requirements--business and system--must be tested. He intermingles suggestions for requirements elicitation with requirements testing. Throughout the book he introduces his classic "Twenty-one Plus" approaches to testing requirements--now up to sixty-four ways. He shows how these approaches can be "turned around" and used during the requirements discovery process. The author discusses the "regular way" of testing requirements--reviews, and their inherent difficulties, and offers suggestions for making reviews more effective through the use of formal checklists. These checklists include topics such as clarity, deliverable "whats" rather than "hows," testability, review-ability, itemization, traceability, ambiguity, consistency--all with a focus of adding value to the requirements.

One of the most useful ideas in the book is Goldsmith’s Problem Pyramid. The pyramid is made up of six blocks of information.

• Block 1 describes a problem to be solved (or an opportunity to be exploited).
• Block 2 contains measures that show the problem exists.
• Block 3 sums the measures that, when achieved, would show the problem has been solved.
• Block 4 describes the "as is" process that creates the problem.
• Block 5 describes the "should be" process that will lead to the success described in Block 3.
• Block 6 defines the "hows" that will accomplish the "whats" in Block 5.

Most organizations leap directly to Block 5, ignoring the real business requirements that ultimately define success.

In the middle of the book, Goldsmith goes soft on us. Like other excellent practitioners, he knows that many "requirements problems" are not technical in nature--they are related to people and their "soft skills." He reviews useful techniques such as prototyping, focus groups, Joint Application Development, observing, learning, and interviewing. Robin finishes the book by discussing formats for documenting requirements--the IEEE 830 standard and use cases.

"Discovering Real Requirements" is a valuable addition to the growing literature dealing with software requirements. Goldsmith weaves an interesting case study throughout the chapters to illustrate his methods. Unfortunately, good advice on this subject has been largely ignored. Goldsmith provides no illusion that this book will solve that problem. When illustrating our long history with requirements problems, he describes the classic cartoon with the caption, "You start coding; I'll go find out what they want." He notes, "We pay to build the wrong stuff, then pay to find out what’s wrong, and pay again to fix it. What a business model!" He continues, "As an industry, we've been at system development for fifty years and still don't get it right. Let me suggest that maybe we just don't get it--period. Our customary approaches don't work very well "

But, his topic is vital: the discovery and documentation of business requirements. And his presentation is well done. The book is clearly organized and well written and is a valuable resource to anyone creating or testing requirements.