What Are Requirements?

Depending on the type of restaurants you frequent, your dining experience may differ significantly. At the first type of restaurant, you might drive up to the menu board. While reading the menu, a distorted voice comes through a cheap speaker and says something that is completely unintelligible. You respond by ordering what you want. The voice says something else you cannot understand. You drive around to the pickup window, pay for and receive your meal in a bag, and leave.

At a different establishment, a waiter comes to your table and greets you, asks about any immediate needs you have (adult beverages, soft drinks, water, etc.), provides you with menus, and leaves you to contemplate your choices. (The amount of time you get to review the menu always seems to be inversely proportional to the size of the menu.) The waiter returns and proceeds to tell you about any special meals that are available. When he completes his recitation, you place your order. Depending on the type of restaurant, your scenario varies.

The orders you place at restaurants are your requirements for your meal. They are the essential specifications, details, and terms of the contract, in this case, between you and the restaurant. The restaurant attempts to satisfy these requirements (thus meeting your needs, in this case, satisfying your specific hunger), though with varying levels of success. The better you define what you want (the requirements), the more satisfied you generally are with what is delivered to you.

One common definition of a requirement is “a software capability needed by the user to solve a problem that will achieve an objective.” [DORF1]

From the Real World—Tag! You're It! (Reprise) In the real world, not all demands for software and other capabilities will meet such an exacting definition. Remember from the last chapter the orphaned software I inherited from a programmer who had moved on? You will recall the users wrote numerous incorrect defects because they did not understand what the software was required to do. One of those users kept hounding management to have the software changed so that it didn't report so many errors. However, reporting errors was the primary function of the application! This change he asked for was not “a software capability needed by the user”—it was not needed at all. It was something he wanted. (Hence, I refer to these as desirements, not requirements.) This change would not “solve a problem”—indeed, this change would cause problems. However, the change would “achieve an objective”—this fellow simply did not want to have to check out all the reported errors; he didn't have the time.

Lessons Learned Be aware that in the real world, a “requirement” may merely be something that someone wants. You may have to satisfy desirements and requirements. (I was eventually directed to engineer a solution to satisfy this fellow's desirement without compromising the correctness of the application—a great deal of work for very little value.)

The sidebar is an example of why we prefer the following definition of requirements:

“A requirement is an expression of a perceived need that something be accomplished or realized. Note that this definition is intended to encompass all defined requirements for a project. In particular, it includes the following:

• Product, work, programmatic, service, and other requirements (including those commonly called 'constraints')

• Incorrect requirements, i.e. requirements which are not valid statements of the customer's needs, although they may be perceived as such

• Poor requirements and poorly expressed requirements

• The expression of needs in different forms, not necessarily statements in natural language

• Requirements expressed in technical and non-technical language

• Wants and desires, noting that these are normally expressed as needs

• Requirements which may not be binding or which are prioritized” [GABB1]

This much broader definition takes into account the real-world truth about “requirements” that we all need to be prepared to encounter.