If you approach someone in the street and ask for directions then,
providing that person knows the way ­ and speaks the same language as
you do, it should be easy for him to help you. But often, when you
try and follow the directions you become more confused and lost.
Perhaps the person giving the directions has assumed that you know
about a local landmark or has forgotten to mention that there is
another small street on the left before the one you are seeking. Or
maybe the director has not understood your request and has sent you
to a place with a similar name..there are so many reasons that the
transfer of information from one person to another is fraught with
difficulties.

When you try to discover the requirements for any kind of product the
difficulties are even more complex because the source of the
requirements is not just one person, it is all of the people who are
stakeholders in the project. And all of these people have their own
view of what is important, along with their own experience,
prejudices and views of the world. Considering the variations between
your sources of requirements (stakeholders) it makes sense to have a
variety of techniques for discovering the requirements. We call these
trawling techniques because, like fishing, we run a net through the
organisation and trap as many requirements as we can. Then, using the
appropriate technique we identify the relevant requirements (the
juicy codfish) and separate them from the irrelevant (the minnows).
We also look for rare and amazing fish that nobody has ever seen
before. This paper summarises a number of techniques that you can use
when trawling for requirements.


The problem of requirements - Why didn't you tell me what you want?

The reason for the late discovery of requirements is usually because
we have not been able to inspire the stakeholders to think past
preconceptions and communicate what they want.


Conscious Requirements

The type of requirement that a stakeholder is most likely to
communicate is what we call a conscious requirement. A conscious
requirement is something the stakeholder is particularly aware of.
This might be because it is one of the reasons for building the
product like "I want the camera to fit in my handbag". Or it might be
because a current product has a shortcoming ­ "I want the battery to
last longer". Or maybe it is because the stakeholder is aware of a
new piece of technology ­ "I want the camera to be able to take
digital photographs". In all these cases a particular stakeholder is
conscious of a requirement because of his particular view of the
world, consequently it is something he is likely to mention.


Unconscious Requirements

Another situation is when a stakeholder does not mention a
requirement because he does not realise that he has it. Think of it
as an unconscious requirement. Reasons for this situation might be
that the stakeholder is so used to having this requirement satisfied
that he no longer thinks of it as a requirement. If he is so used to
his camera automatically rewinding at the end of the film, then he is
less likely to articulate that requirement. But if you deliver a
camera that does not rewind then he is amazed. How could you possibly
have missed that requirement when surely anyone would know it is
necessary. The problem of unconscious requirements happens often when
the stakeholder knows a lot about the subject matter and makes
assumptions that everyone else has the same knowledge. Another reason
is because it is sometimes very difficult to tell someone all the
details about something you know a lot about because you feel that
maybe you are patronising them. You feel that surely they know that
and you might be boring them by even mentioning it. Yet another
reason might be that the stakeholder does not understand what an
existing product does and therefore assumes that any new product will
maintain the status quo.

Undreamed Requirements

Undreamed of requirements are rather different. If a stakeholder has
a fixed idea of what he believes is possible then he is unlikely to
mention requirements that he thinks cannot be carried out within his
understanding of the constraints. "No point in mentioning that I
would like the camera to be waterproof ­ I know it's not possible
within the budget". Then there are many undreamed of requirements
that do not even occur to the stakeholders because they cannot
imagine what it might be like to have the product and to experience
new technology. Remember that many of these undreamed of requirements
will not be invented by stakeholders who fall into the category of
customers or end users. Instead other stakeholders like technical
specialists and developers will be the inventors and suggestors of
undreamed of requirements. Unless we encourage stakeholders to
imagine these undreamed of requirements, they are unlikely to surface
until later in the product's lifecycle when people understand more
about the potential uses of new technologies. By then, even though it
might have been possible earlier, it is often too late to add these
new competitive features to the product.