Chapter 10

ESTABLISHING REQUIREMENTS
 Chapter 10
10.1 Introduction
10.2 What, How, and Why?
10.3 What Are Requirements?
10.4 Data Gathering for Requirements
10.5 Data Analysis, Interpretation, and
Presentation
10.6 Task Description
10.7 Task Analysis
www.id-book.com 2
 10.1 Introduction
• The importance of requirements
• Different types of requirements
• Data gathering for requirements (ch.7)
• Data analysis and presentation (ch.8)
• Task description: Scenarios
Use Cases
Essential use cases
• Task analysis
www.id-book.com 3
 Examples
1. Smart phone, tablet
2. Reader
3. Smart watch
4. Máy ATM
5. Máy bán hàng tại siêu thị 24h
6. Thiết bị cầm tay của nhân viên phục vụ ăn
uống
7. Thiết bị cầm tay của nhân viên giao hàng
www.id-book.com 4
https://logisticsmgepsupv.wordpress.com/
2014/03/26/improving-logistics-and-shipping-
the-scanner/

https://store.optori.com/product/pda-gia-re-
may-kiem-kho-nhanh-va-chinh-xac-may-quet-
ma-vach-android-chat-luong-chainway-c61/?
gclid=CjwKCAjwvrOpBhBdEiwAR58-3K-
AiuT2cY3dt3MVp4erDqYi2dRqJRqVbGcgHtMUl
EzNDdGpcNfnuxoCIcEQAvD_BwE#iLightbox[pro
duct-gallery]/1
• Figma – tạo prototype (thiết kế giao diện
phần mềm)
• Sketch up (thiết kế giao diện phần cứng)

www.id-book.com 11
 Process of ID

Establish requirements

Evaluation Solutions

Prototype

12
 10.2 What, how and why?
10.2.1 What needs to be achieved?

1. Understand as much as possible about users,

activity, context of activity
2. Produce a stable set of requirements

10.2.2 How can this be done?

• Data gathering activities (ch.7)

• Data analysis activities (ch.8)
• Expression as ‘requirements’
• All of this is iterative
www.id-book.com 13
 10.2 What, how and why?
10.2.3 Why
bother?
Requirements
definition is the
stage where
failure occurs
most commonly

Getting requirements right is crucial

www.id-book.com 14
 10.2 What, how and why?
10.2.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 understanding users’ needs

Requirements can be justified & related to data
www.id-book.com 15
 10.3 What are requirements
• Requirements: specific, unambiguous, clear

— Ex: smartwatch GPS app

• Example requirement: atomic requirement

sell (next slide)

www.id-book.com 16
Volere shell

17
10.3.1 Different kinds of requirements
1. Functional:
—What the system should do
—Ex: new video game challenging for a range of user
abilities
2. Non-functional:
—Constrains
—Ex: many platforms, security, response time,…
—Ex: telecare system
3. Data:
—What kinds of data need to be stored?
—How will they be stored (e.g. online database, banking,
…)? 18
Volere requirements template

www.id-book.com 19
10.3.1 Different kinds of requirements
4. 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, synchronous, privacy for clients
• organisational: hierarchy, IT department’s attitude
and remit, user support, communications structure
and infrastructure, availability of training
5. User Characteristics

www.id-book.com 23
 Box 10.1
Environmental requirements: Underwater computing

www.id-book.com 24
 Display “what you see is what you press”

Kord Key Pad

Underwater computing – SeaSlate

www.id-book.com 26
10.3.1 Different kinds of requirements
Users: Who are they? (user profile)
— Characteristics: nationality, educational background,
attitude to computers

— System use: novice, expert, casual, frequent

— Novice: prompted, constrained, clear

— Expert: flexibility, power of control

— Frequent: short cuts

— Casual/infrequent: clear menu paths

www.id-book.com 27
 What are the users’capabilities?
Humans vary in many dimensions:
— size of hands may affect the size and positioning of input
buttons

— height if designing a physical kiosk

— strength - a child’s toy requires little strength to operate,

but greater strength to change batteries

— disabilities (e.g. sight, hearing, dexterity)

www.id-book.com 28
 Personas
• Capture a set of user characteristics (user
profile): skill, attitudes, tasks, enviroments.

• 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

www.id-book.com 29
Box 10.2 Example Persona

www.id-book.com 30
Box 10.2 Example Persona

www.id-book.com 31
 Activity 10.1
An interactive product for use in a
university's self-service cafeteria that
allows users to pay for their food
using a contactless card or
smartphone.

Suggest some key requirements in

each category:

1. Functional requirements
2. Non-functional requirements
3. Data requirements
4. Environmental or context of use
5. User Characteristics

32
www.id-book.com
 10.4 Data gathering for requirements
• Interviews:
— Props, e.g. sample scenarios of use, prototypes, can be used in
interviews

— Good for exploring issues

— Development team members can connect with stakeholders

• Focus groups:
— Group interviews

— Good at gaining a consensus view and/or highlighting areas of

conflict

— But can be dominated by individuals

www.id-book.com 33
10.4 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

www.id-book.com 34
10.4 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

www.id-book.com 35
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

www.id-book.com 36
Some examples

Cultural probes

www.id-book.com 37
 Some examples
Ethnographic study, interviews, usability tests, and user
participation

www.id-book.com 38
 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

www.id-book.com 39
 Considerations for 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

• Political problems within the organisation

• Dominance of certain stakeholders

• Economic and business environment changes

• Balancing functional and usability demands

www.id-book.com 40
 Considerations for 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
www.id-book.com 41
 Data gathering 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
• Support the process with props such as
prototypes and task descriptions
www.id-book.com 42
10.5 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
www.id-book.com 43
 10.6 Task descriptions
• Scenarios
― an informal narrative story, simple, ‘natural’,
personal, not generalizable
• Use cases (activity 10.4)
— assume interaction with a system
— assume detailed understanding of the interaction

• Essential use cases (task case) (activity 10.5)

— abstract away from the details
— does not have the same assumptions as use cases

www.id-book.com 44
Scenario for University
admissions office
Scenario for movie rental service
 Scenario for travel organizer
“The Thomson family enjoy outdoor activities and want to try their hand at
sailing this year. There are four family members: Sky (10 years old), Eamonn
(15 years old), Claire (35), and Will (40). One evening after dinner they
decide to start exploring the possibilities. They all gather around the travel
organizer and enter their initial set of requirements –a sailing trip for four
novices in the Mediterranean. The console is designed so that all members
of the family can interact easily and comfortably with it. The system’s initial
suggestion is a flotilla, where several crews (with various levels of
experience) sail together on separate boats. Sky and Eamonn aren’t very
happy at the idea of going on vacation with a group of other people, even
though the Thomsons would have their own boat. The travel organizer
shows them descriptions of flotillas from other children their ages and they
are all very positive, so eventually, everyone agrees to explore flotilla
opportunities. Will confirms this recommendation and asks for detailed
options. As it’s getting late, he asks for the details to be saved so everyone
can consider them tomorrow. The travel organizer emails them a summary
of the different options available.”
www.id-book.com 47
Scenario for skinput
http://youtu.be/g3XPUdW9Ryg

www.id-book.com 49
Scenarios and Personas

www.id-book.com 50
 Activity 10.3 for scenario
1. Hãy viết 1 kịch bản/ngữ cảnh về việc bạn đi chọn
mua một chiếc xe hơi mới. Có thể là mua 1 chiếc
hoàn toàn mới hoặc mua xe cũ.
Trong lúc viết, hãy nghĩ các khía cạnh quan trọng
của việc bạn ưu tiên điều gì và thích cái gì (*).
2. Sau đó tưởng tượng ra một sản phẩm (có tính
tương tác) hỗ trợ bạn đạt được mục tiêu mua xe và
quan tâm đến những vấn đề bạn đặt ra (*).
3. Viết một kịch bản cho thấy sản phẩm đó hỗ trợ
bạn như thế nào. www.id-book.com 51
 Use case for travel organizer
1. The system displays options for investigating visa and vaccination
requirements.
2. The user chooses the option to find out about visa requirements.
3. The system prompts user for the name of the destination country.
4. The user enters the country’s name.
5. The system checks that the country is valid.
6. The system prompts the user for her nationality.
7. The user enters her nationality.
8. The system checks the visa requirements of the entered country for a
passport holder of her nationality.
9. The system displays the visa requirements.
10. The system displays the option to print out the visa requirements.
11. The user chooses to print the requirements.
www.id-book.com 52
Alternative courses for travel organizer
Some alternative courses (case):

6. If the country name is invalid:

6.1 The system displays an error message.
6.2 The system returns to step 3.
8. If the nationality is invalid:
8.1 The system displays an error message.
8.2 The system returns to step 6.
9. If no information about visa requirements is found:
9.1 The system displays a suitable message.
9.2 The system returns to step 1.
www.id-book.com 53
Example use case diagram for travel organizer

www.id-book.com 54
 Activity 10.4 for use case
Ví dụ về dịch vụ cho thuê phim. Một use case
là “thuê phim” và nó liên quan đến actor
Subcriber.
1. Hãy xác định một actor quan trọng khác
2. Liệt kê use case “thuê phim” bao gồm các
normal course và alternative course. Có thể
giả thiết normal case là cho user vào
website để tìm kiếm phim theo đạo diễn.
3. Vẽ biểu đồ use case cho hệ thống này
www.id-book.com 55
 Essential Use Cases (task case)
• To combat the limitation of scenarios and
Use Case
• Essential Use Cases represent
abstractions from scenarios, more general
and more structured than scenarios
• Essential Use Cases avoid certain
assumption of “Use Case” (technology to
interact, the user interface, the kind of
interaction)
www.id-book.com 56
Example essential use case for retrieving visa
requirements in travel organizer

www.id-book.com 57
 Activity 10.5 for essential use case

Hãy xây dựng một essential use case (task

case) cho user role “Subscriber” của dịch vụ
thuê phim đã được đề cập trong activity
trước.

www.id-book.com 58
 10.7 Task analysis
• Task descriptions are not 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)
www.id-book.com 59
 Hierarchical Task Analysis
• Involves breaking a task down into subtasks, then sub-
sub-tasks and so on. These are which specify how the
tasks might grouped as plans e 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

www.id-book.com 60
 Example Hierarchical Task Analysis
(HTA)
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.
www.id-book.com 61
Example Hierarchical Task Analysis
(graphical) - HTA

www.id-book.com 62
Example Hierarchical Task Analysis
(graphical) - HTA

https://makeiterate.com/a-simple-guide-to-hierarchical-task-analysis/
www.id-book.com 63
HTA example
https://www.youtube.com/watch?v=MYCIK45W0TQ
www.id-book.com 64
 User story mapping for UX designers

https://www.youtube.com/watch?v=CyGRdC27QqY

www.id-book.com 65
 User story mapping for UX designers

https://www.youtube.com/watch?v=YumNf61xn5E

www.id-book.com 66
 Activity 10.6 for HTA

Xét ví dụ về công ty tổ chức du lịch.

Hãy dùng mô hình phân tích tác vụ HTA với
mục đích xác định vacation của người
dùng sẽ có những gì.
HTA phải bao gồm plan.
Diễn đạt sự phân tích tác vụ bằng văn bản
và đồ họa.
www.id-book.com 67
 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
www.id-book.com 68