So What IS User Requirements Gathering?

Requirements gathering is all about aiming at the right target. It doesn't matter how accurate you are, if you aim at the wrong target, you miss.

More than one reader has pointed out that our recent article "Alternatives To User Requirement Gathering" spent plenty of time illustrating why certain methods were inappropriate for the task of requirement gathering, without actually detailing the correct way to undertake this type of research. In way of compensation, this week we provide some (brief) advice on this absolutely crucial area to successful application or site development.

The Need For Requirements Gathering

Requirements gathering is all about aiming at the right target. It doesn't matter how accurate you are, if you aim at the wrong target, you miss. To be usable, an interface must let the people who use the product (users), working in their own physical, social, and cultural environments, accomplish their goals and tasks effectively and efficiently.

Unless you know who is going to use a product, for what purpose, and in what circumstances, you cannot design it effectively or test whether it works well. User and task analysis is designed to identify this information and use it to set design and testing goals and establish measurable success criteria.

The following techniques will be useful for those organisations that wish to undertake some form of requirements gathering. A good programme will combine these techniques in order to provide a well-rounded picture of the needs that must be addressed by an application or site. Of course there are further possibilities, but the three approaches below certainly provide somewhere to start.

Ethnographic Interviews

As was mentioned in our previous article, interviews can be a dangerous way to evaluate user requirements. However, they do provide an obvious start point and can be an important element of an overall programme if certain approaches are used. Most importantly, focus on discussing how the user works now, in the present, rather than on aspirations and future 'wants'. Interviews should be directed to include discussion of specific incidents, behaviours and tasks that are a part of the job (and sub tasks) that the new application or site will (hopefully) simplify. This information will be useful in pinpointing current difficulties in working practises.

Contextual Enquiry

Simply put, contextual enquiry involves the observation of users in their typical work environment. It can also incorporate discussion with users as they perform work tasks, and as such overlaps to some extent with the ethnographic interview detailed above (the two could certainly be both performed during the same site visit). It should be remembered, however, that the primary purpose of observation is not to engage in long discussions - let the user talk by all means but don't fill the air with the sound of your own voice.

Careful observation and recording can be an excellent way to identify common tasks and areas that could be targeted for efficiency gains. Perhaps even more importantly, it can help understand the 'mental model' of the user, as well as the reasons and logic behind the decisions they make when completing tasks.

Evaluation

A good requirements gathering programme should include some form of evaluation of current usability levels, or at least provide baseline information on performance levels. This can either be an aspect of contextual enquiry or be formalised in a user test. This type of evaluation will provide vital information on areas in which users currently have difficulty and help set usability targets for future development.

Competitive analysis can be a further element in an evaluation programme - comparing other methods of performing the tasks in question in terms of effectiveness and efficiency. This comparative study should be as broad as possible. For example, an online ticket booking system should be compared not just with other similar services, but also with more conventional approaches to the task such as ringing a travel agent. It is often the case that the basic user requirement is an improvement over 'offline' methods of performing the same task.