Discovering Real Business Requirements for Software Project Success
While a number of books on the market deal with software requirements, this is the first resource to offer you a methodology for discovering and testing the real business requirements that software products must meet in order to provide value. The book provides you with practical techniques that help prevent the main causes of requirements creep, which in turn enhances software development success and satisfaction among the organizations that apply these approaches. Complementing discovery methods, you also learn more than 21 ways to test business requirements from the perspectives of assessing suitability of form, identifying overlooked requirements, and evaluating substance and content.
The powerful techniques and methods presented are applied to a real business case from a company recognized for world-class excellence. You are introduced to the innovative Problem Pyramid (tm) technique which helps you more reliably identify the real problem and requirements content. From an examination of key methods for gathering and understanding information about requirements, to seven guidelines for documenting and communicating requirements, while avoiding analysis paralysis, this book is a comprehensive, single source for uncovering the real business requirements for your software development projects.
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.
Review By: Clark Riffe
12/30/2005In "Discovering REAL Business Requirements for Software Project Success," author Robin Goldsmith focuses on the critical early stage of software development in which we gather and document business requirements. He credits Barry Boehm's book, "Software Engineering Economics" (1981), with making the world aware that the cost of fixing an error rises by an approximate factor of ten for each additional later stage at which the error is fixed. He says that this implies the most expensive error is a requirements error that is not found until the system is in production.
Based on these compelling economics, Goldsmith leads us through what it takes to do a better job discovering and testing REAL business requirements. First he defines the term "REAL business requirements." Next he goes into considerable detail about twenty-one ways to test whether the requirements have been appropriately defined. Throughout the book the author places responsibility on those charged with discovering requirements, encouraging them to look beyond the input received from business operators and users and to dig for the REAL business requirements.
A unifying element of the book is an actual case study introduced in the second chapter and carried through to the final chapter. Goldsmith includes exercises based on the case to aid the reader’s understanding of the subject matter. The case study, which builds upon itself as the book develops, is one reason the author recommends reading the book in sequence rather than skipping around. Using the case study as a foundation, chapter eleven provides examples of both top-level and detailed business requirements documented using hierarchical, itemized deliverables to facilitate testing.
The last three chapters deal with finding overlooked requirements, checking requirements for accuracy and completeness, and measuring the results of the requirements gathering process.
This book deals with an area of particular interest to me--the challenge of building a system that really delivers business results. All too often the author’s opening problem illustration occurs between a business manager and a development manager:
"It's not right."
"It's what you said you wanted."
"Well it's still not right."
Robin Goldsmith offers an approach to discovering REAL business requirements that, if followed properly, can reduce the number of similar dialogues. We cannot expect our business partners to give us well-structured requirements ready for programming.
I have found some of these techniques useful--in particular, the definition of a business requirement as "what must be delivered to add value" and the examples of well-written, top-level, and detailed business requirements. If you are interested in improving your business requirements process, I recommend Robin Goldsmith's "Discovering Real Business Requirements for Software Project Success."