The Component Software Series

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.