Page 125 -

108 Chapter 4 Requirements engineering

coordinate actions. It is assumed that a phone conference for voice communica-
tion will be separately set up.

Scenarios and use cases are effective techniques for eliciting requirements from
stakeholders who interact directly with the system. Each type of interaction can be
represented as a use case. However, because they focus on interactions with the sys-
tem, they are not as effective for eliciting constraints or high-level business and non-
functional requirements or for discovering domain requirements.
The UML is a de facto standard for object-oriented modeling, so use cases and
use case–based elicitation are now widely used for requirements elicitation. I discuss
use cases further in Chapter 5 and show how they are used alongside other system
models to document a system design.

4.5.5 Ethnography

Software systems do not exist in isolation. They are used in a social and organiza-
tional context and software system requirements may be derived or constrained by
that context. Satisfying these social and organizational requirements is often critical
for the success of the system. One reason why many software systems are delivered
but never used is that their requirements do not take proper account of how the social
and organizational context affects the practical operation of the system.
Ethnography is an observational technique that can be used to understand opera-
tional processes and help derive support requirements for these processes. An ana-
lyst immerses himself or herself in the working environment where the system will
be used. The day-to-day work is observed and notes made of the actual tasks in
which participants are involved. The value of ethnography is that it helps discover
implicit system requirements that reflect the actual ways that people work, rather
than the formal processes defined by the organization.
People often find it very difficult to articulate details of their work because it is
second nature to them. They understand their own work but may not understand its
relationship to other work in the organization. Social and organizational factors that
affect the work, but which are not obvious to individuals, may only become clear
when noticed by an unbiased observer. For example, a work group may self-organize
so that members know of each other’s work and can cover for each other if someone
is absent. This may not be mentioned during an interview as the group might not see
it as an integral part of their work.
Suchman (1987) pioneered the use of ethnography to study office work. She
found that the actual work practices were far richer, more complex, and more
dynamic than the simple models assumed by office automation systems. The differ-
ence between the assumed and the actual work was the most important reason why
these office systems had no significant effect on productivity. Crabtree (2003)
discusses a wide range of studies since then and describes, in general, the use of
ethnography in systems design. In my own research, I have investigated methods of