Page 121 -

should not be out of order. However, it is unlikely that the text will be read that way. In
this case, all of the developers will almost certainly understand what the requirements
analyst meant when the text was written, and writing the extra explanation into the
requirement could make it more confusing.
The requirements analyst has a great deal of discretion about how to break requirements
up. For example, the example above could potentially be broken into two separate
requirements, with one requirement allowing for a case-sensitive search and another
specifying that the replacement text needs to retain the case of the original text when the
search is not case-sensitive. A good general rule is that requirements should only be split
up when that split offers more clarity. In this case, a split probably would not make the
requirement any clearer, so keeping these together makes sense.
Many requirements define behavior that the user can turn on or off (like the user’s ability
to specify a case-sensitive search in the example). In this case, the requirement should
always specify the default behavior (in the example case, the default search is case-insen-
sitive). Requirements often specify behavior that only occurs under certain conditions
(like the conditions in which the case is retained). It is also important to specify a fall-
through case to show what happens if none of the specified conditions are met (“In all
other cases…“).
As with the use case, the requirements should not contain any design elements. The
requirements analyst should avoid words like window, button, click, checkbox, radio but-
ton, form, etc. For example, many search-and-replace features use a checkbox to imple-
ment context-sensitive searching. But there is no need to require that the designer use a
checkbox—it’s possible that an innovative designer might come up with a better way to let
the user turn on case-sensitive searching (like with two separate buttons, a radio button, a
separate tab, or some other way that isn’t immediately obvious). Leaving the design
unconstrained allows the designers and programmers more freedom to implement the
requirements creatively. The more that the design is constrained in the SRS, the harder it
makes their jobs.

Nonfunctional requirements

Users have implicit expectations about how well the software will work. These character-
istics include how easy the software is to use, how quickly it executes, how reliable it is,
and how well it behaves when unexpected conditions arise. The nonfunctional requirements
define these aspects about the system. (The nonfunctional requirements are sometimes
referred to as “nonbehavioral requirements” or “software quality attributes.”)

The nonfunctional requirements should be defined as precisely as possible. Often, this is
done by quantifying them. Where possible, the nonfunctional requirements should provide
specific measurements that the software must meet. The maximum number of seconds it
must take to perform a task, the maximum size of a database on disk, the number of hours
per day a system must be available, and the number of concurrent users supported are
examples of requirements that the software must implement but do not change its behavior.

SOFTWARE REQUIREMENTS 113