CSE 4739

Human Computer Interaction (HCI)

Lecture 7: Identifying needs and establishing requirements

Winter 2017
Hasan Mahmud | [email protected]
 Overview
• The importance of requirements
• Different types of requirements
• Data gathering for requirements
• Task descriptions: Scenarios
Use Cases
Essential use cases
• Task analysis: HTA

CIT 4739 | HCI | Winter-2017 2

What, how and why?
• What are we trying to achieve in this design activity?
− There are two aims:
1. To understand as much as possible about the users, their work, and the
context of that work, so that the system under development can support
them in achieving their goals; this is called "identifying needs."
2. Produce a stable set of requirements

• How can we achieve this? Data Gathering

1. Data gathering activities Analysis Stable set of Design

Identify
Clarify Interpretation requirements Activity
2. Data analysis activities
Presentation
3. Expression as ‘requirements’
4. All of this is iterative

CIT 4739 | HCI | Winter-2017 3

 What, how and why?

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

Getting requirements right is crucial

4
 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 a sound understanding of the users’
needs
− Requirements can be justified & related to back to the data
collected
CIT 4739 | HCI | Winter-2017 5
What are requirements?
• A requirement is a statement about an intended
product that specifies what it should do or how it
should perform.
• One of the aim of requirement activity is to make the
requirement as specific, unambiguous, and clear as
possible.
– E.g. For example, a requirement for a website might be
that the time to download any complete page is less than 5
seconds.

CIT 4739 | HCI | Winter-2017 6

Volere Shell

CIT 4739 | HCI | Winter-2017 7

Volere requirements template

CIT 4739 | HCI | Winter-2017 8

What are requirements?
• Kinds of requirements
– In software engineering, two kinds
• Functional
• Non-functional
– In Interaction Design
• Functional requirements
• Data requirements
• Environmental requirements
• User requirements
• Usability requirements

CIT 4739 | HCI | Winter-2017 9

Different kinds of requirements in IxD
• Functional:
—What the system should do
—Historically the main focus of requirements activities
—E.g.
 A functional requirement for a word processor may be that it
should support a variety of formatting styles.
 A smart fridge should be able to tell when the butter tray is
empty.

• (Non-functional: memory size, response time...)

• Data:
—What kinds of data need to be stored?
—How will they be stored (e.g. database)?

CIT 4739 | HCI | Winter-2017 10

 Different kinds of requirements in IxD
Environment or context of use: Refers to the circumstances in which the interactive
product will be expected to operate.
— Physical:
• How much lighting, noise, and dust is expected in the operational environment.
• e.g. ATM.
— Social:
• Social aspects of interaction design, such as collaboration and coordination, in the
context of current environment.
• 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.
— Technical:
• What technologies will the product run on or need to be compatible with, and what
technological limitations might be relevant?

CIT 4739 | HCI | Winter-2017 11

Underwater computing

CIT 4739 | HCI | Winter-2017 12

Underwater computing

CIT 4739 | HCI | Winter-2017 13

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, wide ranged access/power of control
• Frequent: short cuts
• Casual/infrequent: clear instructions, e.g. menu paths

CIT 4739 | HCI | Winter-2017 14

Kinds of requirements: Example
• Suggest one key functional, data, environmental, user and
usability requirement for the following scenarios:
a) A system for use in a university's self-service cafeteria that allows
users to pay for their food using a credit system.
b) A system to control the functioning of a nuclear power plant.
c) A system to support distributed design teams, e.g., for car design.

CIT 4739 | HCI | Winter-2017 15

Kinds of requirements: Example
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

CIT 4739 | HCI | Winter-2017 16

Data gathering for requirements
• Data gathering is an important part of the requirements
activity and also for evaluation
• The purpose of data gathering is to collect sufficient, relevant,
and appropriate data so that a set of stable requirements can
be produced.
• Data gathering techniques
– questionnaires
– interviews
– focus groups and workshops
– naturalistic observation, and
– studying documentation

CIT 4739 | HCI | Winter-2017 17

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
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
CIT 4739 | HCI | Winter-2017 18
 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
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

CIT 4739 | HCI | Winter-2017 19

CIT 4739 | HCI | Winter-2017 20
Data interpretation and analysis
• The aim of the interpretation is to begin structuring and
recording descriptions of requirements
• Techniques:
– Data-flow diagram
– Class diagram
– Sequence diagram
– State chart diagram
– Entity relationship diagram
– Use case diagram
– And many more…

CIT 4739 | HCI | Winter-2017 26

Task descriptions
• Task descriptions are used throughout the development, from
early requirements activities through prototyping, evaluation, and
testing.

• Scenarios
― an informal narrative story, simple, ‘natural’, personal, not
generalizable
• 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

CIT 4739 | HCI | Winter-2017 27

 Personas
• Capture a set of user characteristics (user profile)

• Not real people, but synthesised from real users

• Should not be idealised

• Bring them to life with a name, characteristics, goals,

personal background

• Develop a small set of personas with one primary

CIT 4739 | HCI | Winter-2017 28

Example Persona

CIT 4739 | HCI | Winter-2017 29

Scenarios
• A scenario is an "informal narrative description" (Carroll,
2000). It describes human activities or tasks in a story that
allows exploration and discussion of contexts, needs, and
requirements.
• It does not explicitly describe the use of software or other
technological support to achieve a task.
• The construction of scenarios by stakeholders is often the
first step in establishing requirements.
• Use of baskinger template.

CIT 4739 | HCI | Winter-2017 30

 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…”
CIT 4739 | HCI | Winter-2017 31
Scenarios and Personas

CIT 4739 | HCI | Winter-2017 32