1.2 What Is a Requirement?

Requirements are the effects that the computer is to exert in the problem domain, by virtue of the computer's programming.

”B ENJAMIN L. K OVITZ

A requirement is something that a computer application must do for its users. It is a specific function, feature, quality, or principle that the system must provide in order for it to merit its existence. Requirements constitute part of the scope of a software development project. Add a few requirements, and the scope increases ; take some away, and the scope decreases. The requirements also dictate how the system should respond to user interaction. It should do specific things when poked or prodded by the user in a certain way.

Requirements often seem abstract and intangible, especially to software developers. Requirements and design tend to blur together in a software person's brain until they become indistinguishable. However, it is crucial to keep requirements and design separate. Following are some of the ways IT people typically get off track with requirements:

• Design considerations ” Anything that relates to how the system should operate , rather than what it needs to accomplish, is design . Design should not be part of requirements.

• Vagueness ” If a requirement does not contribute positively to shaping the application design, it is too vague to be useful.

• The use of computer industry language ” Requirements must always be phrased in the users' language. Jargon is OK as long as it's the users' jargon!

• Relating to the business goals ” Every requirement must clearly relate to the goals of the businesspeople.

For clarification of this thorny issue, let's look again at the unfortunate requirements shown earlier in Table 1.1. This time let's look at them in detail and try to identify those things that do not constitute high-quality requirements.

The system must provide the capability to capture all of the customer transactions for the fiscal year.

This requirement is too vague. How could it translate into a valuable constraint on the design of an application? It implies that the fiscal year has some impact on how customer transactions are organized, but we are not sure what impact. In fact, what is a "customer transaction"? We understand that this system has some type of data entry, but that must be stated more specifically . Maybe this is a suggestion about volume, meaning that old transactions can't be archived until they are a year old, but that interpretation is a stretch from looking at this requirement.

The system will provide restricted remote inquiry access (via dial-in) to view images and data separately or simultaneously .

Saying "restricted" access is OK, but details about the restriction (who can, who can't) must be stated clearly in this context. Also vague is the reference to remote inquiry. How remote? Saying "remote access" when referring to mobile employees working in the field but still within a couple of miles of the office is one thing ”but talking about worldwide access is yet another. Implications on the system design and architecture could be huge.

The system will barcode documents automatically prior to distribution. At a minimum, the codes will be used to identify to which work queue the documents should be routed within the organization when they are returned.

This requirement makes several technical assumptions concerning the design. Barcoding is a solution to a problem, not a requirement. This system probably needs a way to identify each document uniquely, but it doesn't have to be barcodes. If all the existing systems use document barcoding (not the case with this system), it would make sense to write a nonfunctional requirement that states, "Unique identification of all documents will be done through barcoding." What's the difference? By embedding the barcoding assumption in various functional requirements, you make it difficult for someone to change the identification method from barcoding to glyphs, optical character recognition (OCR), or some other technology, thereby reducing your ability to respond to user needs discovered later in the process.

Another sticky point in this requirement is the reference to work queues. This seems to make an assumption about a workflow-oriented system. Workflow tools are solutions, not requirements. A better way to put it might have been, "At a minimum, the unique identification will ensure routing to a specific worker in the organization when the documents are returned."

When a workflow is initiated, the system must be able to prefetch the documents that are in electronic image format by document type or grouping of documents by process.

Look at the reference to a workflow . Our suspicions were right! The requirements document has already specified a workflow solution in its requirements. Actually, this whole entry is suspicious. It seems to be saying that we must cache documents by two different criteria: by type or by process. The criteria are good requirements, but the caching (or prefetching ) is really a solution to address performance problems and probably is not a requirement in itself.

The system must create an entry in the journal file whenever a letter is created.

This requirement assumes the presence of a journal file, which has entries put into it when a letter is created. This requirement seems focused on the front end ("do this") instead of the back end ("in order to get this"). Why put entries into a journal file? You might do that so that you could create a list of all the letters that were created, when, and by whom. You really want the ability to audit letters written. Looking at it from the back end actually makes for a better, clearer requirement. You could create a journal file, but don't think about that until design!

The system must maintain a list of current, open work processes and identify the work process to be executed and the workflow queue for the process. When particular documents are scanned, the system will determine whether there is a process open for that SSN. If there is an open process, the system will route the document to the appropriate workflow queue, display the work process script, and highlight the current work process.

Again, this requirement seems more focused on the how than the what . Rather than look at the different steps a system must go through, it should clearly document the end in mind. Here is our rewrite for this requirement: "When a new document image is brought into the system, it should be routed to the worker who has the account open for the same SSN as the new document and should be made obvious to that worker. If no worker has an open account, the document should be made available to any worker."

You will also see that none of the requirements in our list are linked to a business person. It would be very difficult to pinpoint "who cares" about each of these requirements. Who are the computer users who will gain value from these requirements? The answers to these questions are not clear from these requirement statements.

But why not include design in requirements? Why do we keep harping on keeping design out of requirements?

There are several reasons. First, skill sets for a development project are matched to the activity performed. Therefore, the people who are gathering requirements probably have skills that are not suited to design or development. Furthermore, the designers/developers may not have the skills to conduct good quality user interviews and requirements planning sessions. It is also important to keep these activities separate because the design ultimately must be based on the requirements of the business.

Documenting requirements is an effort in understanding the problem at hand. Designing is the activity of solving the problem. The solution for the problem must come after the problem has been identified, documented, understood , and agreed on.

This can be tricky, especially in an iterative/incremental lifecycle. Perhaps a more accurate way to state our rule is that no system, subsystem, or increment should proceed into design until the requirements for that system, subsystem, or increment have been identified, documented, and understood . (Clumsy sentence structure, but good advice.) When design precedes requirements, or supplants them, the system takes on requirements of its own ”requirements that are neither documented nor representative of the users' needs. The end result can be a wasted design effort, an unusable system, missed milestones, and unhappy users. Not knowing the problem that your design is solving is dangerous business. It is always advisable (if difficult) to define the problem completely before designing.

Another reason to keep design out of requirements gathering is related to the team environment. If a group is designing a system with no documented requirements, it is likely that group members will be working with different goals in mind. Because they do not have a common document from which to begin, they form the requirements picture in their own minds and use that to formulate their designs. These designs almost certainly will be incompatible and overlapping, causing integration problems, skipped requirements, scope creep, schedule issues, and unhappy users.

1.2.1 Functional Requirements

Without requirements, there is no way to validate a program design ”that is, no way to logically connect the program to the customer's desires.

”B ENJAMIN L. K OVITZ

Functional requirements are what the users need for the system to work. Functional requirements are functions and features. These are the requirements we typically think of when we describe systems.

Here are some sample functional requirements for an order entry system:

• The system shall accept orders for products and provide notification to the entry clerk as to whether there is sufficient inventory to fulfill the order.

• The system shall use reorder points set by the inventory clerk to order new parts automatically.

• The system shall substitute comparable parts for parts that are out of stock as specified by the inventory manager.

• The system shall produce a nightly report of the orders for the previous day.

Use cases, the subject of this book, are one way to document functional requirements. We'll examine alternatives to use cases later in this chapter.

1.2.2 Nonfunctional Requirements

Nonfunctional requirements address the hidden areas of the system that are important to the users even though they may not realize it. As you can probably judge by the name , these requirements do not deal with the functionality of a system. Nonfunctional requirements are the global, fuzzy factors or principles that relate to the system's overall success. Many of them end in -ility , so we sometimes call the collection of them the -ilities . An example of an -ility is scalability: the ability of the system to handle an increased workload without significantly increasing the transaction processing time. (See Section 4.2.10 for details.)