Page 234 -

7.2 What, how, and why? 203

capturing the findings in a form that can be expressed as requirements. Broadly
speaking, these activities progress in a sequential manner: first gather some data,
then interpret it, then extract some requirements from it, but it gets a lot messier
than this, and the activities influence one another as the process iterates. One of the
reasons for this is that once you start to analyze data, you may find that you need to
gather some more data to clarify or confirm some ideas you have. Another reason
is that the way in which you document your requirements may affect your analysis,
since it will enable you to identify and express some aspects more easily than oth-
ers. For example, using a notation which emphasizes the data-flow characteristics
of a situation will lead the analysis to focus on this aspect rather than, for example,
on data structure. Analysis requires some kind of framework, theory or hypothesis
to provide a frame of reference, however informal, and this will inevitably affect
the requirements you extract. To overcome this, it is important to use a comple-
mentary set of data-gathering techniques and data-interpretation techniques, and
to constantly revise and refine the requirements. As we discuss below, there are dif-
ferent kinds of requirements, and each can be emphasized or de-emphasized by the
different techniques.
Identifying needs and establishing requirements is itself an iterative activity in
which the subactivities inform and refine one another. It does not last for a set
number of weeks or months and then finish. In practice, requirements evolve and
develop as the stakeholders interact with designs and see what is possible and how
certain facilities can help them. And as shown in the lifecycle model in Chapter 6,
the activity itself will be repeatedly revisited.

Why bother? The importance of getting it right
An article published in January 2000 (Taylor, 2000) investigated the causes of IT
project failure. The article admits that "there is no single cause of IT project fail-
ure," but requirements issues figured highly in the findings. The research involved
detailed questioning of 38 IT professionals in the UK. When asked about which
project stages caused failure, respondents mentioned "requirements definition"
more than any other phase. When asked about cause of failure, "unclear objectives
and requirements" was mentioned more than anything else, and for critical success
factors, "clear, detailed requirements" was mentioned most often.
As stressed in previous chapters, understanding what the product under de-
velopment should do and ensuring that it supports stakeholders' needs are criti-
cally important activities in any product development. If the requirements are
wrong then the product will at best be ignored and at worst be despised by the
users, and will cause grief and lost productivity. In either case, the implications
for both producer and customer are serious: anxiety and frustration, lost revenue,
loss of customer confidence, and so on. However we look at it, getting the re-
quirements of the product wrong is a very bad move and something to be avoided
at all costs.
Taking a user-centered approach to development is one way to address this. If
users' voices and needs are clearly heard and taken into account, then it is more
likely that the end result will meet users' needs and expectations. Involving users
isn't always easy, however, and we explore in more detail how to do this effectively