Skip to main content
Department of Information Technology

Theoretical highlight 10: Users, Tasks and Requirements

This theoretical highlight consists of tree parts:
1) Requirements, 2) User analysis and 3) Task Analysis.

Part 1: Requirements

Who is the user of the system, and why are people using the system? How and where is the system used? These are questions that have to be answered when computer systems are designed and developed. A system developer cannot answer these questions by herself. To understand the user - you have to understand that you are not the user. In order to get the necessary knowledge, we have to study real users.

Introduction

When computer systems are developed, there is a need for knowledge of which the users are, their goals, and what tasks they have to accomplish. These knowledge processes are usually called user analysis and task analysis respectively. They are important in order to find goals and requirements for the computer system. Different terms are used for these phases of system development, but the most common are requirement analysis or requirement gathering.

Requirement analysis

In order to early on elucidate the needs of the users, the requirements analysis is done in beginning of the system development process. This also includes needs that are indistinct, overlooked and even impossible.

In traditional software development, the focus is on functional and technical requirements. In a user-centered development process, the usability requirements are more important. If a certain function hardly could be used, it is more or less worthless or could make the user's work inefficiency or even dangerous. The requirements are sometimes categorized as functional or non-functional requirements respectively. Usability requirements are usually classified as non-functional.

Is it possible to a get complete grasp of all the relevant requirements early on in the development? Probably not. The reason behind this is that the composite interactions of the system, users and their organization, often gets very complex. And early on, there is too difficult to get knowledge about how this complexity works.

The developers start with a limited knowledge about the problems to be solved and the existing requirements. Gradually, they get a better understanding of the problem domain and can explore different design solutions. This way of working is called iterative development, which means that the developers go through and repeat different design activities, every time with a better understanding of the problem to be solved. During the iterative development the design is gradually refined.

Knowledge of users

It is important to realize that programmers, software engineers, business analysts, user interface designers and other people involved in the development process, are not themselves typical end users. These people can not replace real users as sources of knowledge. To understand the users, it is is important to understand that you are not the user.

"To understand the users, it is is important to understand that you are not the user"

How can we, as designers and developers, gather information about the users? The best means is to study, interview and more or less 'live with' the users in their workplaces. It will give necessary knowledge in work environment, work tasks, users' characteristics and other important conditions.

In order to grasp knowledge that is not possible to get in any other way, we must visit workplaces or other environments where the system is to be used. Then, it is possible (but not easy), to discover informal structures of the organizations, unknown task procedures and find out about 'tacit' knowledge. If the users are not available for some reasons, for example when we not yet know who they are, we have to try to gather as much information as possible by market surveys, opinion polls or ethnographic studies.

Activities in requirements analysis

One problem with designing usable systems is to know if the completed system really is usable. Are the goals of the project met or not?
In order to evaluate the usability of the system, we have to define demands, requirements, of the system to be constructed. The requirements must also be measurable and specified in advance, in order to see if the goals have been met.

The system or prototypes that are developed have to be evaluated according to specified usability requirements. It is not sufficient to just say that the system should be 'user friendly' - it must be possible to validate that this is true.

To find out and specify usability requirements or goals for a system, involves three main categories of knowledge elicitation and analysis. The general purpose with the activities is to define which services or functions that the new system must provide in order to support the user's work. The goal of task analysis is to organize and prioritize these services/functions. We are also interested in understand and describe the users and the context where they work or use the system.

The following activities are included:

  1. The User analysis should answer questions about who the users are and what characteristics they have that might be important for the computer system (read more in part 2 of this lesson).
  2. The Context analysis is focusing on the environment where the users are working or using the system in. This includes both aspects on the physical environment as well as organizational issues (read more in ((part2|part 2) of this lesson).
  3. The Task analysis should answer questions about the users' tasks and how these are carried out (read more in part 3 of this lesson).

>>Part 2: User analysis

Updated  2013-03-19 14:47:21 by Magnus Larsson.