Page 235 -

204 Chapter 7 Identifying needs and establishing requirements

in Chapter 9. Here we focus on establishing the requirements, while keeping the
emphasis clearly on users' needs.

I
7.2.4 Why establish requirements?
The activity of understanding what a product should do has been given various la-
bels-for example, requirements gathering, requirements capture, requirements
elicitation, requirements analysis, and requirements engineering. The first two
imply that requirements exist out there and we simply need to pick them up or
catch them. "Elicitation" implies that "others" (presumably the clients or users)
know the requirements and we have to get them to tell us. Requirements, however,
are not that easy to identify. You might argue that, in some cases, customers must
know what the requirements are because they know the tasks that need to be per-
formed, and may have asked for a system to be built in the first place. However,
they may not have articulated requirements as yet, and even if they have an initial
set of requirements, they probably have not explored them in sufficient detail for
development to begin.
The term "requirements analysis" is normally used to describe the activity of
investigating and analyzing an initial set of requirements that have been gath-
ered, elicited, or captured. Analyzing the information gathered is an important
step, since it is this interpretation of the facts, rather than the facts themselves,
that inspires the design. Requirements engineering is a better term than the oth-
ers because it recognizes that developing a set of requirements is an iterative
process of evolution and negotiation, and one that needs to be carefully managed
and controlled.
We chose the term establishing requirements to represent the fact that require-
ments arise from the data-gathering and interpretation activities and have been es-
tablished from a sound understanding of the users' needs. This also implies that
requirements can be justified by and related back to the data collected.

7.3 What are requirements?
Before we go any further, we need to explain what we mean by a requirement. In-
tuitively, you probably have some understanding of what a requirement is, but we
should be clear. A requirement is a statement about an intended product that spec-
ifies what it should do or how it should perform. One of the aims of the require-
ments activity is to make the requirements as specific, unambiguous, and clear as
possible. For example, a requirement for a website might be that the time to down-
load any complete page is less than 5 seconds. Another less precise example might
be that teenage girls should find the site appealing. In the case of this latter exam-
ple, further investigation would be necessary to explore exactly what teenage girls
would find appealing. Requirements come in many different forms and at many dif-
ferent levels of abstraction, but we need to make sure that the requirements are as
clear as possible and that we understand how to tell when they have been fulfilled.
The example requirement shown in Figure 7.1 is expressed using a template from
the Volere process (Robertson and Robertson, 1999), which you'll hear more
about later in this chapter and in Suzanne Robertson's interview at the end of this