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—well, perhaps even a cat's eye small blue marble—would have sufficed. And he probably changed his mind about his requirements between the delivery of the first (large) rock and the third (small blue) rock.

At each subsequent meeting with the customer, it's common for the developer to 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 prescribed characteristics; the customer is equally frustrated because, even though he might find it difficult to articulate what he wants, he's convinced that he's 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, 2-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 a rock. 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.

Software systems, by their nature, are intangible, abstract, complex and—in theory, at least—infinitely changeable. So, if the customer begins articulating vague requirements for a "rock system," he often does so 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%–33% 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. It's important to realize, though, that 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, documentation folks, and the like—as well as those members of the external "customer" team—users and other stakeholders, marketing, and management— everyone, really, who has the need and requirement to contribute to the requirements solution.

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 they 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: If you were a building contractor, you wouldn't need to be convinced that a series of carefully orchestrated 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 stakeholders who, along with the person who intends to pay for and inhabit the house, will determine whether the finished house meets the full set of requirements. It's also clear that many 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 system may vary widely.

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 engineering drawings; 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.

Many of the team skills you will need to master in order to address this challenge can also be described in terms of practical, common-sense 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." In a software project, we will be offering similar advice: "Make sure you ask the right questions, make sure that you prioritize the requirements, and don't let the customer tell you that 100 percent of the requirements are critical, because you're not likely to have time to finish them all before the deadline."

In this book, Leffingwell and Widrig have taken a pragmatic approach to describing the solution to the rock problem. They have organized the book into seven parts. The introduction provides some of the context, definitions, and background that you'll need to understand what follows.Chapter 1 reviews the systems development "challenge." The data shows that some software project failures are indeed caused by sloppy programming, but a number of recent studies demonstrate rather convincingly that poor requirements management may be the single largest cause of project failure. And though I've described the basic concept of requirements management in a loose, informal fashion in this foreword, the authors will define it more carefully inChapter 2, in order to lay the groundwork for the chapters that follow.Chapter 3 provides a brief introduction to some of the characteristics of modern software teams, so that they can relate the team skills that will be developed to the team context, wherein the skills must be applied.

Each of the next six major parts is intended to help you and your team understand and master one of the six requisite team skills for effective requirements management.

Finally, after a brief summary, the authors provide a prescription that you and your team can use to manage requirements in your next project. They conclude with this in a Chapter 35, Getting Started.

We hope that armed with these newly acquired team skills, you, too, will be able to build the perfect marble. But it will never be easy; even with the best techniques and processes, and even with automated tool support for all of this, you'll still find that it's hard work. And it's still risky; even with these team skills, some projects will fail because we're "pushing the envelope" in many organizations, attempting to build ever more complex systems in ever less time. But the skills defined in this book will go a long way toward reducing the risk and thereby helping you achieve the success you deserve.

—Ed Yourdon