Identifying needs and

establishing
requirements

Chapter 10
 Overview
• The importance of requirements
• Different types of requirements
• Data gathering for requirements
• Task descriptions: Scenarios
Use Cases
Personas
 What, how and why?
• What Are We Trying to Achieve in the Requirements
Activity?
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
 What, how and why?

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

Getting requirements right is crucial

 What are requirements?
• A statement about an intended product that specifies what it is
expected to do or how it will perform
• Different forms and different levels of abstraction
• User stories (most prevalent in agile development contexts)
• Format:
• As a <role>, I want <behavior> so that <benefit>
• Example user stories for a travel organizer might be:
• As a <traveler>, I want <to save my favorite airline for all my
flights> so that <I will be able to collect air miles>
• As a <travel agent>, I want <my special discount rates to be
displayed to me> so that <I can offer my clients competitive
rates>
 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
 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)?
 Different kinds of
requirements
Environment or context of use:

— physical: dusty? noisy? vibration? light? heat?

humidity? …. (e.g ATM)
— social: sharing of files, of displays, in paper,
across great distances, work individually, privacy
for clients
— organisational: hierarchy, IT department’s
attitude and remit, user support, communications
structure and infrastructure, availability of training
Environmental Requirements:
Underwater Computing
 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
 Usable security
• How to make security robust without
detracting from user experience
• If the usability of security is ignored, then
security mechanisms will be circumvented
• Passwords as an example
• Too much advice about how to choose a
password
• Coping strategies may compromise security
 Different kinds of
requirements
• Usability goals
• User experience goals
• Different products have different
requirements and may be
implemented in different ways, for
example, trustworthiness
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
 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
 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
 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 getting background information
— No stakeholder time, which is a limiting
factor on the other techniques
 Combining Data Gathering
• Diaries and interviews: multiple information
devices
• Interviews, think aloud evaluation, questionnaire,
evaluation of working prototype
• Studying documentation, evaluating other
systems, user observation, and group interviews:
Ethnographic study, interviews, usability tests, and
user participation
 What are Probes?

• In Human-Computer Interaction
(HCI), there are a plethora of ways
for real collecting data that is close to
a user’s actual behavior in their daily
lives.
• One of the methods of such data
collection which is more popular lately
is the probe
 What is probe?
• probe is usually a diary where the user writes his
observations throughout a day or maybe weeks. These
observations can be in the form of photos taken by the user,
writings in the form of data or graphs, voice recordings in a
phone, etc. Put in general, a probe is a form of “diary study.”

• Now, these diaries in the case of research are probes, and

the user generates these probes by providing them with
‘probe packs.’ It consists of a pack of common items such as
a notebook, camera, voice recorder, scrapbooks, etc. to
record their daily observations.
 Types of Probe?

• Probes can be classified into two

types -
• Cultural probes
• Technology probes
 Cultural Probes

• Cultural probes are used to

understand the culture of the user.
Data recorded by the user can give us
plenty of insight into their cultural
background, environment, and their
approach towards interaction with
objects in that environment’.
 technology probes
• Whereas on the other hand technology
probes have a different motivation behind its use.
Sometimes it really becomes difficult for us to get
adept at new technology quickly.
• We take our time to understand the product or
technology according to our different needs.
• Hence to understand the user needs industry
practitioners often use technology probes as a tool
here to test the early prompts (prototypes) to
understand the needs of the user by testing the
prototype in the user environment itself.
 Bringing requirements to
life
• Augmenting the basic requirements expressed
as stories, in Volere template, or in other form
• Personas
• Rich descriptions of typical users, not
individual user
• Scenarios
• An informal narrative story, simple, ‘natural’,
personal, and not generalizable
 Personas

• Capture user characteristics

• Not real people, but synthesised from real
user characteristics
• Bring them to life with a name,
characteristics, goals, personal background
• Develop multiple personas
 What are personas?

Personas are descriptions of individual

people who represent groups of users
that would interact with your system.
 You use them to guide your design.
For example, as you are discussing
features, you may ask "How would
Mary feel about this," where Mary is a
persona you have developed.
Why personas are useful?
Alternative approach
 Why personas (1)
To create a product that must satisfy a
diverse audience, logic might tell you
to make it as broad in its functionality
as possible to accommodate the most
people.
This logic ,however, is flawed. The
best way to accommodate a variety of
users is to design for specific
individuals with specific needs.
 Why personas (2)
• When you extend a product's functionality to include
many constituencies, you increase the cognitive load
and navigational overhead for all users. Facilities that
please some users will likely displease others.

Key to this approach is first to choose the right

individuals to design for - those whose needs represent
those of a larger set of key constituents - and then
prioritize those individuals so that the needs of the most
important users are met without compromising our
ability to meet the needs of secondary users.
 Persona Specifications

Design for one person

 represents a group

Hypothetical not real

Powerful tool if used to complement other methods but not

replace them.
 3 types of persona

• Proto personas, meant to quickly align the

team’s existing assumptions about who their users
are, but not based on (new) research
• Qualitative personas, based on small-sample
qualitative research, such as interviews, usability
tests, or field studies
• Statistical personas, where initial qualitative
research informs a survey instrument that is used
to gather a large sample size, and the personas
emerge from statistical analysis
 Proto persona

• Proto personas can be based on

existing user data if your team has
any, but in many cases are based
solely on the team’s assumptions
about who the users are, and what
they need.
 Qualitative Personas:

• For most teams, the best approach

for creating personas is by running
solid exploratory qualitative research
(such as interviewing users) with a
small-to-medium sample size, and
then segmenting users based on
shared attitudes, goals, pain points,
and expectations.
Statistical Personas: Mix of
Qualitative and Quantitative
Research
• This type of personas requires some exploratory
qualitative research beforehand to identify what
questions to include in the survey.
• You must have a solid working knowledge of your
specific users’ expectations and needs to create
a survey that will reveal anything useful.
Persona example –remaining
portion of previous slide
diagram
 Steps to create Personas
Step 1: Do research
Step 2: Segment your audience
Step 3: Decide on the layout
Step 4: Set demographic info
Step 5: Describe Persona’s background
Step 6: Define Persona’s goals
Step 7: Define motivations and frustrations
Step 8: Add other ingredients
Persona’s background
 Define Persona’s goals-
Examples
• For example- Emma is looking for great discount
offers, cheap deals, and best value products.
While Cynthia wants to see only verified customer
reviews and ratings and high-quality product
images and videos on the website. And Thomas is
interested in purchasing the latest and trending
fashion products to make his own style stand out.
•
 Define motivations and
frustrations
• Finding what motivates and frustrates your customers is
something you must include in Personas. Once done, it will
illuminate what you can do to win their hearts and loyalty.
• For example- In Emma’s case, her pain points may be that
she doesn’t want to deal with high delivery charges and
taxes. She also wants to know when exactly the coupons she
has are due to expire.
• Speaking of her motivations, Emma would love to get
early access to deals and discounts. Also, she wants to get
reminders and alerts for deals and seasonal sales.
 Add other ingredients

• you can add loads of other sections

to describe your Persona in the most
detailed way possible. So add skills,
touchpoints, tech that your Persona
uses, quotes, etc.
 Example
• An example of how personas can become explicitly involved in the design
and development process
 Scenarios
• Scenarios
―an informal narrative story, simple, ‘natural’, personal,
not generalizable
― Scenarios describe the stories and context behind why a specific user or user group comes to
use your product
― User scenarios are detailed descriptions of a user – that describe realistic situations relevant to
the design of a solution. By painting a “rich picture” of a set of events, teams can appreciate user
interactions in context, helping them to understand the practical needs and behaviors of users.

―Describe typical usage location

―Focus on goals, action and objects
―Leaves out user interface details
Scenario Elements
 Guidelines for scenarios
Good scenarios are concise but answer the following key questions:
•Who is the user? Use the personas that have been developed to
reflect the real, major user groups coming to your site.
•Why does the user come to the site/product? Note what
motivates the user to come to the site and their expectations upon
arrival, if any.
•What goals does he/she have? Through task analysis, you can
better understand the what the user wants on your site and therefore
what the site must have for them to leave satisfied.
•Some scenarios also answer:
•How can the user achieve their goals on the site? Define how
the user can achieve his/ her goal on the site, identifying the various
possibilities and any potential barriers.
 Types of scenarios
• Goal- or Task-Based Scenarios state only what the
user wants to do.
• Do not include any information on how the user would
complete the scenario.
• These scenarios are useful in helping to define your
site /product architecture and content.
• You should give these types of scenarios to users in a
usability test.
• It gives them a reason and a goal for going to the site,
but it lets them show you how they would use the site
to accomplish that goal.
 Example –task based scenario
• Example: A parent is worried about a ten-year old
refusing to drink milk and wants to know if it really
makes a difference that the child is getting very
little calcium.
• Example: You are traveling to Seattle for your job
next week and you want to check on the amount
you can be reimbursed for meals and other
expenses.
 Elobarated Scenario
• Elaborated Scenarios give more user story
details.
• These details give the team a deeper
understanding of the users and users’
characteristics that may help or hinder
site/product interaction.
• Knowing this information, the team is more likely
to develop content, functionality, and site/product
behavior that users find comfortable and easy to
work with.
 Example – Elaborated scenario
• Example: Mr. and Mrs. Macomb are retired schoolteachers who are now in
their 70s. Their Social Security checks are an important part of their
income. They've just sold their big house and moved to a small apartment.
They know that one of the many chores they need to do now is tell the
Social Security Administration that they have moved. They don't know
where the nearest Social Security office is and it's getting harder for them
to do a lot of walking or driving. If it is easy and safe enough, they would
like to use the computer to notify the Social Security Administration of
their move. However, they are somewhat nervous about doing a task like
this by computer. They never used computers in their jobs. However, their
son, Steve, gave them a computer last year, set it up for them, and
showed them how to use email and go to websites. They have never been
to the Social Security Administration's website, so they don't know how it
is organized. Also, they are reluctant to give out personal information
online, so they want to know how safe it is to tell the agency about their
new address this way.
 Scenario for holiday
planner
“The Thomson family enjoy outdoor activity holidays and want to try
their hand at sailing this year. There are four members of the
family: Sky who is 10 years old, Eamonn who is 15 years old, Claire
who is 35, and Will who is 40. While out on a shopping trip they call
by at the travel agents in their local town to start exploring the
possibilities ... The travel organizer is located in a quiet corner of the
agents’ office, where there are comfortable seats and play things for
young children. They all gather around the organizer and enter their
initial set of requirements—a sailing holiday for four novices. The
stand-alone console is designed so that all members of the family
can interact easily and comfortably with it. The system’s initial
suggestion is that they should consider a flotilla holiday, where
several novice crews go sailing together and provide mutual support
for first-time sailors…”
 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,personas, use cases and essential use
cases can be used to articulate existing and
envisioned work practices.