1.1 What Are Requirements?

At least I have got a grip of the essential facts of the case. I shall enumerate them to you, for nothing clears up a case so much as stating it to another person, and I can hardly expect your cooperation if I do not show you the position from which we start.
-Sherlock Holmes: Silver Blaze,
Arthur Conan Doyle

Let's keep our definition of requirements simple:

The requirements of a system define what it needs to do-but not how.

The requirements define the problem that has to be solved: what the system is for and everything it needs in order to achieve that. They do not define the solution. A requirement is a single, measurable objective that a system must satisfy. The best way to express each requirement is in plain text. A requirements specification for a system is a document stating all its requirements plus any background material needed to make it readable and understandable. It needs to define all the functions and other capabilities that the system must possess.

There's no single "right" level of detail to go into in requirements. Requirements can be specified at various levels of detail. A relatively broad requirement can be broken down into more specific requirements that spell out the implications of the original. It's also possible to write multiple requirements specifications at different levels. Some organizations and experts divide requirements into separate levels as a matter of course, often into "high-level" requirements, which capture the business objectives, and "detailed" requirements, which spell out the functions and other capabilities that the system needs in order to achieve the business objectives. This book does not separate all requirements into levels. However, several of its requirement patterns introduce two (or even three) local levels of their own that show how to break down a specific kind of broad goal into clear requirements that are as detailed as developers need. For example, if our system must satisfy a particular standard (the broad goal), we can specify detailed requirements for what the system must do to achieve that goal. (What, but not how!)

Requirements define most importantly what the system must do, the activities it must be able to perform. These are called functional requirements. They attract the bulk of the attention, often to the neglect of the other characteristics that the system must possess-called nonfunctional requirements-which cover a wide range of topics from performance to security to standards with which the system must comply.

The process of specifying requirements is that of identifying what a system needs to do. It is performed for every system that's ever built, regardless of whether the requirements are spelled out explicitly. A programmer who decides what's needed and simply goes ahead and codes it performs a lightning-fast requirements specification process along the way, even if requirements exist only as fleeting thoughts before being overtaken by more exciting design brainwaves. I argue that it's advantageous to write down all requirement cogitations so that they can be debated and justified in their own right, independent of the design of the solution. A full-blown requirements definition phase isn't the only way to achieve that.