We need requirements for all our projects, and we build our systems based on them. Unfortunately, requirement lists can become incredibly long, and sometimes you just ask yourself “Who thought that would be a good idea?”
‘Thought that...’ is correct: unfortunately, it often happens that requirement requests are the result of conversations between project leaders, clients, salespeople or other roles who make assumptions about what users need or might need. This quickly becomes evident in phrases such as “Surely the users do it that way…” or “I'm assuming that…” All too often it later turns out that no one actually needs the functionality that results from such assumptions.
Personally I find this way of working based on assumptions enormously hampering – neither users nor we developers want any part of it. My wish is that we should develop solutions that users really need, and in their entirety.
User requirements engineering – the next step
At the beginning of December I took further training as a User Requirements Engineer (CPUX-UR) with Thomas Geis, which I recommend, not only because of the great experience of the trainer. Among other things Thomas was involved in ISO 9241, which is essential for usability engineering.
User requirements engineering is both a sub-discipline of requirements and usability engineering. Collecting user requirements is one of the first steps in the user-centered design process, which demonstrates once again that usability is much more than just design.
A statement from the course stayed with me: “What the user sees – that is the user interface – is for them the product, not the underlying technology”. The latter is simply perceived by the user as a given.
What does this statement mean for requirements engineering? Simply that we should first focus on identifying requirements that describe what the user must be able to recognize, select, or type in the system being developed, and for the moment keep away from system requirements. These sorts of requirements are known as usage requirements.
I would like to introduce you to a way to arrive at usage requirements that are not based solely on assumptions. There is a fairly structured approach to this.
How do I get a usage request?
The exciting thing about usage requirements is that they are not there ‘all of a sudden’, or arise from anyone's thinking about what else to do in the system. Usage requirements are well founded and based on the usage context of a user.
The usage context is easily explained
When we carry out a task, be it on a computer system or elsewhere, we always do so within a specific usage context. We use those resources that are available to us, such as materials, hardware or software, and always work within an environment (physical, social and cultural). Depending on how our usage context is designed, this has an influence on our activities. For example, working in a large office (a physical environment) with many colleagues (a social environment) determines how we behave in our workplace. When we listen to music we will most likely do so via headphones, to avoid disturbing our colleagues’ concentration. If we are alone, on the other hand, we might take greater liberties.
Capture information about the usage context
We can obtain detailed information about the usage context by conducting interviews with people who are relevant to the product under development – in other words, with real users. Alternatively, or in addition, we can observe users as they complete their tasks within their specific contexts. We then formulate all this information as context scenarios, which describe in narrative form how users perform their tasks within their usage contexts.
Derive user needs from the usage context
Now we come to one of the central steps in user requirements engineering: deriving user needs from the information about the usage context. User needs are necessary prerequisites for a user to reach a goal within their usage context. They are therefore structured such that they consist of a need (the user needs to know something, needs to have something available or needs to do something) and a goal, in the form of an activity (to decide something or do something).
Imagine I interview you about your sleep behavior and you tell me that you often wake up at night feeling the urge to go to the bathroom. Your decision about whether to get up and go depends on how long you have before your alarm rings. Besides, you wear glasses, and it bothers you that you always have to put them on to read the time.
What are your user needs here? I would put it this way:
‘A glasses-wearer, even without putting on their glasses, must know how much longer they can sleep in order to decide whether to go to the bathroom.’
From user needs to usage requirements
So we have now derived a user need from the usage context. What are we going to do with it? That’s simple – we derive a usage requirement from it.
Usage requirements describe what the user needs to recognize, enter or select within the system while performing a task in their usage context. At this stage we don’t care what kind of system it is: the creative and design processes come later.
To derive usage requirements, you merely ask yourself three questions about what the user must do to fulfill their requirements while completing a task:
- What do they have to recognize?
- What must they be able to enter?
- What must they be able to select?
For example, I would derive the following usage requirement from the above requirement:
‘The user needs to be able to recognize within the system for how much longer they can sleep, even without putting on their glasses.’
This gives us a well-founded basis from which we can derive a system requirement that will later (however implemented) be expressed in the developed solution.
Now think about your alarm clock: only a few alarm clocks show you how much longer you can sleep for. The Apple alarm clock goes some way in this direction, but as a glasses-wearer I still have problems. So we have identified a challenging usage requirement that results from the usage context. We can now use this as a basis to start creative design processes and work out which solution best supports the user.
Why should you consider usage requirements for requirements engineering?
The alarm clock example shows how we can follow the path from usage context, via user needs, to usage requirements . In this way we no longer work just with assumptions, but instead focus on genuinely necessary and supportive requirements. Goodbye to long and unnecessary requirements lists!
Even better, this path can give rise to innovations. Our example identified a major problem: that glasses-wearers do not feel like putting on their glasses at night to find out what the time is. If we can find a solution that supports this, we will also have found something that does not yet exist on the market. This might give us an edge over our competitors.
Comments