Topics
|
Understanding Context of UseGathering System RequirementsFailing to Consider the User
A recent student project involved the development of a Web-based Information Kiosk about London transport. The Website was intended for tourists visiting the Capital. The student spoke to a number of potential users, asking them what features such a system should have, and determined that tourists would like to be able to specify a landmark and be told how to get there using the appropriate transport. Then, the student identified that there are a number of different forms of transport (for example, buses, underground, rail) and structured the site with sections for each, including maps of the routes and lines. When demonstrating the site, I asked if a tourist could find out how to get to a particular landmark from their current location and the student admitted that they couldn't very easily, especially if their journey involved more than one form of transport. Despite having structured the Website logically, it was practically useless, because the needs of the intended users had been ignored during subsequent design stages. The first stage in designing any computer system is to gather
requirements. This highly problematic stage is the key part of any software
development project, because any mistakes mean that the wrong system is
built. Requirements need to be elicited (obtained) and then represented
(documented). User-centred Design (UCD) advocates that system requirements
should be based on the needs of the intended users of the system. If the
needs of the users are not sufficiently considered, ultimately a system
will be built that does not support the work of its users (see side panel:
'Failing to Consider the User'). Required Reading Self-assesment Question 4
What are the different elicitation techniques considered by Preece? Observation,
interviews, questionaires, document analysis, checklists. See Poulson(1998)
for further discussion of these techniques.
Contextual EnquiryWithin UCD the requirements-gathering stage is often known as contextual enquiry (see Figure 3.1). In fact, this is a broader and deeper approach than traditional requirements gathering. As well as specifying the system, it is intended that the characteristics of the prospective users, the context of use, and the work tasks to be supported are determined. Thus the outcomes of contextual enquiry are a representation of the:
Poulson (1998) provides a succinct definition: 'Contextual enquiry is a method for better understanding a person's working environment and the needs that they might have for products to assist them'. Its origins lie in ethnography, which was
developed by anthropologists and has been practised for a number of years
to understand how groups of people interact with their environment and
culture. Required Reading Self-assessment Question 5
Why might it be difficult to examine the work of users using an ethnographic
approach like contextual enquiry?
Basing design on an understanding of people's work is possible if a system
is being developed for an existing organisation (for example, an new Business
Information System for an existing retail company) or group of users.
Sometimes new systems are developed for users that do not yet exist (for
example, a new on-line shopping site for a supermarket). However, in situations
like the latter it is often possible to gather requirements by considering
related work and environments (for example, how customers shop in real
stores).
|
