The Rock Problem

One of my students summarized the issues discussed in this book as the "rock" problem. She works as a software engineer in a research laboratory, and her customers often give her project assignments that she describes as "Bring me a rock." But when you deliver the rock, the customer looks at it for a moment and says, "Yes, but , actually, what I really wanted was a small blue rock." The delivery of a small blue rock elicits the further request for a spherical small blue rock.

Ultimately, it may turn out that the customer was thinking all along of a small blue marble. Or maybe he wasn't sure what he wanted, but a small blue marble would have sufficed.

At each subsequent meeting with the customer, the developer may exclaim, "You want it to do what? " The developer is frustrated because she had something entirely different in mind when she worked long and hard to produce a rock with the characteristics she thought the customer said he needed; the customer is equally frustrated because he's convinced that he has expressed it clearly. These developers just don't get it!

To complicate matters, in most real projects, more than two individuals are involved. In addition to the customer and the developer ”who may, of course, have very different names and titles ”there are likely to be marketing people, testing and quality assurance people, product managers, general managers, and a variety of "stakeholders" whose day-to-day operations will be affected by the development of the new system.

All of these people can become frustrated by the problems of specifying an acceptable "rock," particularly because there often isn't enough time in today's competitive, fast-moving business world to scrap an expensive, two-year "rock project" and do it all over again. We've got to get it right the first time yet also provide for the iterative process in which the customer ultimately discovers what kind of rock he wants.

It's difficult enough to do this when we're dealing with tangible , physical artifacts like rocks. Most business organizations and government agencies today are "information intensive ," so even if they're nominally in the business of building and selling rocks, there's a good chance that the rock contains an embedded computer system. Even if it doesn't, there's a good chance that the business needs elaborate systems to keep track of its e-commerce rock sales, its rock customers, its rock competitors and suppliers, and all of the other information that it needs to remain competitive in the rock business. Moreover, for thousands of companies today, those companies whose business is dedicated exclusively to the development and sales of software products , their entire business focuses on making their products ”intangible and abstract as they are ”into tangible rocks that their customers can purchase, evaluate, and apply.

Software systems, by their nature, are intangible, abstract, complex, and ”in theory, at least ”"soft" and infinitely changeable . So, if the customer begins articulating vague requirements for a "rock system," he often does this on the assumption that he can clarify, change, and fill in the details as time goes on. It would be wonderful if the developers ”and everyone else involved in the creation, testing, deployment, and maintenance of the rock system ”could accomplish this in zero time, and at zero cost, but it doesn't work that way.

In fact, it often doesn't work at all: More than half of the software systems projects taking place today are substantially over budget and behind schedule, and as much as 25 percent to 33 percent of the projects are canceled before completion, often at a staggering cost.

Preventing these failures and providing a rational approach for building the system the customer does want is the objective of this book. However, this is not a book about programming, and it's not written just for the software developer. This is a book about managing requirements for complex software applications. As such, this book is written for every member of the software team (analysts, developers, tester and QA personnel, project management, product management, documentation folks, and the like) as well as members of the external "customer" team (users and other stakeholders, marketing, and management) ” everyone, really, who has a stake in the definition and delivery of the software system.

You'll discover that it is crucial that the members of both teams , including the nontechnical members of the external team, master the skills required to successfully define and manage the requirements process for your new system ”for the simple reason that the y are the ones who create the requirements in the first place and who ultimately determine the success or failure of the system. The stand-alone, hero programmer is an anachronism of the past: May he rest in peace .

A Simple Metaphor: Building a House

If you were a building contractor, you wouldn't need to be convinced that a series of critical conversations with the homeowner are necessary; otherwise , you might end up building a two-bedroom house when your customer wanted a three-bedroom house. But it's equally important that these "requirements" be discussed and negotiated with the government authorities concerned with building codes and zoning regulations, and you may need to check with the next -door neighbors before you decide to cut down any trees on the property where the house will be built.

The building inspector and the next-door neighbors are among the other stakeholders who, along with the person who intends to pay for and inhabit the house, will determine whether the finished house meets their needs. It's also clear that these important stakeholders of your system, such as neighbors and zoning officials, are not users (homeowners), and it seems equally obvious that their perspectives on what makes a quality home may differ from the homeowner's opinion.

Again, we're discussing software applications in this book, not houses or rocks. The requirements of a house might be described, at least in part, with a set of blueprints and a list of specifications; similarly, a software system can be described with models and diagrams. But just as the blueprints for a house are intended as a communication and negotiation mechanism between laypeople and engineers ”and lawyers and inspectors and nosy neighbors ”so the technical diagrams associated with a software system can also be created in such a way that "ordinary" people can understand them.

Many of the crucially important requirements don't need any diagrams at all. The prospective house buyer, for example, can write a requirement in ordinary English that says, "My house must have three bedrooms, and it must have a garage large enough to hold two cars and six bicycles." As you'll see in this book, the majority of the crucial requirements for a software system can be written in plain English. In other cases, it would be more helpful to have a picture of what kind of fireplace the homeowner had in mind.

Many of the team skills you will need to master in order to address this challenge can also be described in terms of practical, commonsense advice. "Make sure you talk to the building inspector," we might advise our novice house builder, " before you dig the foundation for the house, not after you've poured the cement and begun building the walls and the roof." For a software project, we would offer similar advice: "Make sure you ask the right questions of the right people, make sure that you understand how the system is going to be used, and don't assume that 100 percent of the requirements are critical, because you're not likely to have time to finish them all before the deadline."