Chapter 1. What Are Requirements?

in which we consider why we are interested in requirements

The most useful products are those where the developers have understood what the product is intended to accomplish for its users and how it must accomplish that purpose. To understand these things, you must understand what kind of work the users want to do and how the product will affect that work and fit into the organization's goals. What the product does for its users and which constraints it must satisfy in this context are the product's requirements. Apart from a few fortuitous accidents, no product has ever succeeded without prior understanding of its requirements. It does not matter what kind of work the user wishes to do, be it scientific, commercial, e-commerce, or word processing. Nor does it matter which programming language or development tools are used to construct the product. The development processwhether agile, eXtreme Programming, prototyping, the Rational Unified Process, or any other methodis irrelevant to the need for understanding the requirements. One fact always emerges: You must come to the correct understanding of the requirements, and have your client understand them, or your product or your project will fail.

". . . even perfect program verification can only establish that a program meets its specification. The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification."

Source: Fred Brooks, No Silver Bullet: Essence and Accidents of Software Engineering

This book discusses how to discover the requirements and determine their precise nature. Moreover, it explains how you will know that you have found the correct requirements and how to communicate them.

Any important endeavor needs some kind of orderly process. Moreover, the people who are active in the process must be able to see why different parts of the process are important, and which parts carry particular significance for their particular project. This book presents Volerea process, a requirements specification template, and a set of techniques for gathering, confirming, organizing, and documenting the requirements for a product. This process and template can beindeed, have beenused for any kind of product or project. Since the first version of Volere was released in 1995, it has been used by thousands of projects in hundreds of countries.

The requirements process, as we describe it here, is a thorough exploration of the intended product with the intention of discoveringin some cases, inventingthe functionality and behavior of the product. The output of this requirements process is a written description of the requirements to be used as input to the design of the product.

Requirements are not meant to place an extra burden on your project. Instead, they are there to make your project run more smoothly. There is little point in attempting to construct a product unless you know what you are trying to build. This does not mean that your understanding must always be perfect before you start construction, and it does not mean that all the requirements have to be written down. But it does mean that if you intend to deliver useful and usable products at the lowest cost to your organization, you must pay attention to requirements.

This book discusses how you can come to an understanding of the requirements and how you might write them down so that the constructors, and the future generations of maintenance people, can understand them.

Requirements are usually expressed as an abstraction. That is, they are expressed in a technologically neutral way so as to intentionally avoid influencing the design of the solution. The requirements are a pure statement of business needs, without any implementation bias. The role of product design is to translate the requirements into a plan to build some physical reality that will, in the real world, do what is needed. Product design determines which devices are to be used, which software components are necessary, and how they are to be constructed. It is important to the success of the product that final design decisions are not taken before the relevant requirements are known. It is equally important to note that a well-organized requirements process means that requirements, design, and implementation can be done as a number of iterative loops. Each iteration produces some usable functionality. Figure 1.1 depicts the requirements process as part of the ongoing development life cycle.

Figure 1.1.

The diagram illustrates the role of requirements in the development life cycle. The Requirements Gathering process studies the work and then specifies the product that most helps with that work. As an outcome of this process, the Requirements Specification provides a complete description of the needed functionality and behavior of the product. System Modeling produces working models of the functions and data needed by the product, as well as models of the work to support the requirements process. Product Design turns the abstract specification into a design suitable for the real world. Once built, the product is used, and this real-world experience inevitably provides more new requirements. This diagram should be read as iterative. That is, the complete Requirements Specification does not have to be produced before design and construction begin. In fact, if you are working in an agile environment, you will produce a minimal set of requirements components and use those as a guide to planning iterations.

Requirements are expressed in a technologically neutral way so as to intentionally avoid influencing the design of the solution.

Once the product is built, it is used, and immediately begins to evolve. Users demand more functionality, and the product must be able to grow to accommodate the new demands. If you are using an agile process where new functionality is delivered frequently, the partial product has an effect on the work practices. For example, it may trigger new, previously unforeseen requirements, some of which may change the delivered product. The evolution of the product and its requirements is a process that we cannot control or prescribe, but it is one that we must accept. Requirements for a product are not frozen the moment that it is built. Instead, they evolve over a period of time, and any requirements process must take this fact of ongoing change into account.

Requirements for a product are not frozen the moment that it is built.