Page 233 -

202 Chapter 7 Identifying needs and establishing requirements

As we discussed in Chapter 6, identifying users' needs is not as straightforward
as it sounds. Establishing requirements is also not simply writing a wish list of fea-
tures. Given the iterative nature of interaction design, isolating requirements activ-
ities from design activities and from evaluation activities is a little artificial, since in
practice they are all intertwined: some design will take place while requirements
are being established, and the design will evolve through a series of evaluation-re-
design cycles. However, each of these activities can be distinguished by its own em-
phasis and its own techniques.
This chapter provides a more detailed overview of identifying needs and estab-
lishing requirements. We introduce different kinds of requirements and explain
some useful techniques.
The main aims of this chapter are to:
Describe different kinds of requirements.
Enable you to identify examples of different kinds of requirements from a
simple description.
Explain how different data-gathering techniques may be used, and enable
you to choose among them for a simple description.
Enable you to develop a "scenario," a "use case," and an "essential use
case" from a simple description.
Enable you to perform hierarchical task analysis on a simple description.

7.2 What, how, and why?
7.2.1 What are we trying to achieve in this design activiiy?
There are two aims. One aim is to understand as much as possible about the users,
their work, and the context of that work, so that the system under development can
support them in achieving their goals; this we call "identifying needs." Building on
this, our second aim is to produce, from the needs identified, a set of stable require-
ments that form a sound basis to move forward into thinking about design. This is
not necessarily a major document nor a set of rigid prescriptions, but you need to
be sure that it will not change radically in the time it takes to do some design and
get feedback on the ideas. Because the end goal is to produce this set of require-
ments, we shall sometimes refer to this as the requirements activity.

7.2.2 How can we achieve this?
The whole chapter is devoted to explaining how to achieve these aims, but first we
give an overview of where we're heading.
At the beginning of the requirements activity, we know that we have a lot to
find out and to clarify. At the end of the activity we will have a set of stable require-
ments that can be moved forward into the design activity. In the middle, there are
1
activities concerned with gathering data, interpreting or analyzing the data, and
'We use interpretation to mean the initial investigation of the data, while analysis is a more detailed
study, using a particular frame of reference and notation.