2011 1 www.id-book.

com
Identifying needs
and establishing
requirements
Chapter 10

2011 2 www.id-book.com
Overview

The importance of requirements
Different types of requirements
Data gathering for requirements
Task descriptions: Scenarios
Use Cases
Essential use cases
Task analysis: HTA


2011 3 www.id-book.com
What, how and
why?

What
Two aims:
1. Understand as much as possible
about users, task, context
2. Produce a stable set of
requirements

How:
Data gathering activities
Data analysis activities
Expression as requirements
All of this is iterative
2011 4 www.id-book.com
What, how and why?


Why:
Requirements
definition: the
stage where
failure occurs
most commonly


Getting requirements right is crucial

2011 5 www.id-book.com
Volere shell

2011 6 www.id-book.com
Volere requirements
template

2011 7 www.id-book.com
Establishing
requirements

What do users want? What do users need?
Requirements need clarification, refinement,
completion, re-scoping
Input: requirements document (maybe)
Output: stable requirements

Why establish?
Requirements arise from understanding users
needs
Requirements can be justified & related to data
2011 8 www.id-book.com
Different kinds of requirements


Functional:
What the system should do
Historically the main focus of
requirements activities
(Non-functional: memory size, response
time...)
Data:
What kinds of data need to be stored?
How will they be stored (e.g.
database)?
2011 9 www.id-book.com
Different kinds of requirements


Environment or context of use:

physical: dusty? noisy? vibration? light?
heat? humidity? . (e.g. OMS insects, ATM)
social: sharing of files, of displays, in paper,
across great distances, work individually,
privacy for clients
organisational: hierarchy, IT departments
attitude and remit, user support,
communications structure and infrastructure,
availability of training

2011 10 www.id-book.com
An extreme example
2011 11 www.id-book.com
Different kinds of requirements


Users: Who are they?
Characteristics: ability, background, attitude
to computers
System use: novice, expert, casual, frequent
Novice: step-by-step (prompted),
constrained, clear information
Expert: flexibility, access/power
Frequent: short cuts
Casual/infrequent: clear instructions, e.g.
menu paths
2011 12 www.id-book.com
What are the users capabilities?


Humans vary in many dimensions:
size of hands may affect the size and positioning of input
buttons
motor abilities may affect the suitability of certain input
and output devices
height if designing a physical kiosk
strength - a childs toy requires little strength to operate,
but greater strength to change batteries
disabilities (e.g. sight, hearing, dexterity)
2011 13 www.id-book.com
Kinds of requirements


What factors (environmental, user,
usability) would affect the following
systems?

Self-service filling and payment system for
a petrol (gas) station

On-board ship data analysis system for
geologists searching for oil

Fashion clothes website


2011 14 www.id-book.com
Personas
Capture user characteristics
Not real people, but synthesised from
real user characteristics
Should not be idealised
Bring them to life with a name,
characteristics, goals, personal
background
Develop multiple personas
2011 15 www.id-book.com
Personas
2011 16 www.id-book.com
Data gathering for
requirements

Interviews:
Props, e.g. sample scenarios of use,
prototypes, can be used in interviews
Good for exploring issues
But are time consuming and may be
infeasible to visit everyone
Focus groups:
Group interviews
Good at gaining a consensus view and/or
highlighting areas of conflict
But can be dominated by individuals
2011 17 www.id-book.com
Data gathering for requirements


Questionnaires:
Often used in conjunction with other
techniques
Can give quantitative or qualitative data
Good for answering specific questions from
a large, dispersed group of people
Researching similar products:
Good for prompting requirements

2011 18 www.id-book.com
Data gathering for requirements


Direct observation:
Gain insights into stakeholders tasks
Good for understanding the nature and
context of the tasks
But, it requires time and commitment
from a member of the design team, and
it can result in a huge amount of data
Indirect observation:
Not often used in requirements activity
Good for logging current tasks
2011 19 www.id-book.com
Data gathering for requirements


Studying documentation:
Procedures and rules are often written
down in manuals
Good source of data about the steps
involved in an activity, and any
regulations governing a task
Not to be used in isolation
Good for understanding legislation, and
getting background information
No stakeholder time, which is a limiting
factor on the other techniques




2011 20 www.id-book.com
Some examples
Cultural
probes
Diary and
interview
2011 21 www.id-book.com
Contextual Inquiry


An approach to ethnographic study where user is
expert, designer is apprentice
A form of interview, but
at users workplace (workstation)
2 to 3 hours long
Four main principles:
Context: see workplace & what happens
Partnership: user and developer collaborate
Interpretation: observations interpreted by
user and developer together
Focus: project focus to understand what to look
for
2011 22 www.id-book.com
Problems with data gathering (1)
Identifying and involving stakeholders:
users, managers, developers, customer reps?,
union reps?, shareholders?
Involving stakeholders: workshops, interviews,
workplace studies, co-opt stakeholders onto the
development team
Real users, not managers:
traditionally a problem in software engineering,
but better now

2011 23 www.id-book.com
Problems with data gathering
(2)
Requirements management: version control,
ownership
Communication between parties:
within development team
with customer/user
between users different parts of an
organisation use different terminology
Domain knowledge distributed and implicit:
difficult to dig up and understand
knowledge articulation: how do you
walk?
Availability of key people

2011 24 www.id-book.com
Problems with data gathering (3)

Political problems within the organisation

Dominance of certain stakeholders

Economic and business environment
changes

Balancing functional and usability
demands

2011 25 www.id-book.com
Some basic guidelines


Focus on identifying the stakeholders
needs
Involve all the stakeholder groups
Involve more than one representative
from each stakeholder group
Use a combination of data gathering
techniques
2011 26 www.id-book.com
Some basic guidelines


Support the process with props such as
prototypes and task descriptions
Run a pilot session
You will need to compromise on the data you
collect and the analysis to be done, but before
you can make sensible compromises, you need
to know what youd really like
Consider carefully how to record the data
2011 27 www.id-book.com
Data interpretation and analysis

Start soon after data gathering session

Initial interpretation before deeper
analysis

Different approaches emphasize different
elements e.g. class diagrams for object-
oriented systems, entity-relationship
diagrams for data intensive systems

2011 28 www.id-book.com
Task descriptions

Scenarios
an informal narrative story, simple, natural,
personal, not generalisable
Use cases
assume interaction with a system
assume detailed understanding of the
interaction
Essential use cases
abstract away from the details
does not have the same assumptions as use
cases

2011 29 www.id-book.com
Task analysis
Task descriptions are often used to envision
new systems or devices
Task analysis is used mainly to investigate an
existing situation
It is important not to focus on superficial
activities
What are people trying to achieve?
Why are they trying to achieve it?
How are they going about it?
Many techniques, the most popular is
Hierarchical Task Analysis (HTA)

2011 30 www.id-book.com
Hierarchical Task Analysis
Involves breaking a task down into subtasks,
then sub-sub-tasks and so on. These are
grouped as plans which specify how the tasks
might be performed in practice

HTA focuses on physical and observable
actions, and includes looking at actions not
related to software or an interaction device

Start with a user goal which is examined and
the main tasks for achieving it are identified

Tasks are sub-divided into sub-tasks

2011 31 www.id-book.com
Example Hierarchical Task
Analysis

0. In order to buy a DVD
1. locate DVD
2. add DVD to shopping basket
3. enter payment details
4. complete address
5. confirm order

plan 0: If regular user do 1-2-5.
If new user do 1-2-3-4-5.
2011 32 www.id-book.com
Example Hierarchical Task
Analysis (graphical)
2011 33 www.id-book.com
Summary
Getting requirements right is crucial
There are different kinds of requirement,
each is significant for interaction design
The most commonly-used techniques for
data gathering are: questionnaires,
interviews, focus groups, direct observation,
studying documentation and researching
similar products
Scenarios, use cases and essential use
cases can be used to articulate existing and
envisioned work practices.
Task analysis techniques such as HTA help
to investigate existing systems and
practices