Unit 1 Establishing

Requirements
 Overview
• The importance of requirements
• Different types of requirements
• Data gathering for requirements
• Bringing requirements to life
- Personas
- Scenarios
• Capturing interaction with user cases
 What, how and why?
• What is the purpose of the requirements activity? / What needs to
be achieved?
- Explore the problem space to gain insights about the
problem/understand as much as possible about users, task, context.
- Establish a description of what will be developed.
• How to capture requirements once discovered?/How can this be done?
- Data gathering and data analysis activities
- In prototypes or operational product
- Through structured or rigorous notations
- Different capturing mechanisms emphasize and de-emphasize
different aspects
- all of this is iterative
 Why bother?

• Requirements
activity is the
stage where
miscommunic
ation occurs
most
commonly
 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:
- 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>
The seven product dimensions
 Different kinds of requirements

• Functional: What the system should do

• Data:
- What kinds of data need to be stored?
- How will they be stored (for example,
database)?
 Different kinds of requirements
• Environment or context of use:
- Physical: dusty? noisy? vibration? light? heat?
humidity? …. (for example, in a hospital)
- Social: collaboration and co-ordination, data
sharing, distributed, synchronous or asynchronous,
privacy
- Organizational: user support, communications
structure and infrastructure, availability of training
- Technical: On what technologies will it run or need
to be compatible?
 Different kinds of requirements
• Users — Who are they?
- Characteristics: nationality, educational
background, attitude to computers
- System use: novice, expert, casual, frequent
* Novice: prompted, constrained, clear
* Expert: flexibility, access/power
* Frequent: shortcuts
* Casual/infrequent: clear menu paths
- User profile
 Different kinds of requirements

•Usability goals
•User experience goals
•Different products have different
requirements and may be
implemented in different ways,
for example, trustworthiness
 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
 Data gathering for requirements
• Interviews, observation, and questionnaires
• 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 for other
techniques
• Researching similar products:
- Good for prompting requirements
 Combining data gathering

• Direct
observation,
indirect
observation,
interviews,
diaries, and
surveys
Source: Hollis et al (2017), Figure 1. Used courtesy of
Taylor and Francis
 Combining data gathering
• Diaries and interviews: multiple information devices
• Interviews, think aloud evaluation, questionnaire,
evaluation of working prototype: memory aid for
traumatic brain injury
• Studying documentation, evaluating other systems,
user observation, and group interviews: ship’s
maneuvering system
• Ethnographic study, interviews, usability tests, and
user participation: tabletop user interface for
genomic data
 Using probes to engage with users
• Many types of probe:
- Designed to prompt users into action
- For researchers to learn about users
• Cultural probe:
- Wallet containing postcards, maps, camera, photo album, and diary
- Participants asked to answer questions using wallet contents
• Design probe:
- Form relates specifically to particular question and context, for example, Top
Trumps probe

Source: Wallace et al. (2013) Figure 6. Reproduced with permission of ACM Publications.
 Using probes to engage with users

• Technology probe:
- Toolkits, mobile phone apps, sensor-based monitoring, for example, M-
Kulinda to alert participants about unexpected movement at home.
• Provocative probe:
- Technology probe designed to challenge norms and attitudes, for example,
the Box to challenge domestic laundry practices

Source: Raptis et al. (2017). Reproduced with permission of ACM Publications.

 Contextual Inquiry

• Part of Contextual Design, but also used on its own to gather requirements
• One-on-one field interviews (contextual interviews)
- 1.5 to 2 hours long
- Focus on daily life at home or work relevant to the project
- Uses a model of master (participant) and apprentice (researcher)
• Four main principles:
- Context: Going to the user, wherever they are, and seeing what they do as they do it
- Partnership: User and interviewer explore user’s life together
- Interpretation: Observations interpreted by user and interviewer together
- Focus: Project focus to understand to what should be paid attention
 Contextual Inquiry

• Interview guided by “cool concepts” divided into two groups

• Joy of life concepts:
- How products make our lives richer and more fulfilling
- Accomplish, connection, identity, and sensation
• Joy of use concepts:
- Describe impact of using the product
- Direct in action, the hassle factor, and the learning delta
• Interview in four parts
- Overview, transition, main interview, and wrap-up
• Following interview, interpretation session
- Contextual design models are created or consolidated
- Most relevant models are chosen by team, out of 10 suggested
 Brainstorming for innovation

• Include participants from a wide range of disciplines, with a broad

range of experienceDon't ban silly stuffUse catalysts for further
inspirationKeep records. Capture every idea, without
censoringSharpen the focusUse warm-up exercises and make the
session fun
 Bringing requirements to life

• Augmenting the basic requirements expressed as stories, in Volere

template, or in other formPersonasRich descriptions of typical
users, not specific peopleScenariosAn informal narrative story,
simple, ‘natural’, personal, and not generalizable
 Personas

• Capture a set of user characteristics (user profile)

• Synthesized from real people based on user research
• Typical, not idealized
• Bring to life with name, characteristics, goals, and personal background
- Relevant to product under development
• Good persona helps designer with design decisions and reminds team about who will
use the product
• Develop a small set of personas with one primary
Example Persona #1
 Example Persona #2

• Developed using Xtensio Templates

 Scenario for group travel organizer
• “The Thomson family enjoy outdoor activities and want to try their hand at sailing this
year. There are four family members: Sky (8 years old), Eamonn (12 years old), Claire (32),
and Will (35). One evening after dinner they decide to start exploring the possibilities.
They want to discuss the options together but Claire has to visit her elderly mother so will
be joining the conversation from her mother’s house down the road. As a starting point,
Will enters an idea they had been discussing over dinner – a sailing trip for four novices in
the Mediterranean. The system supports users to log on from different locations and use
different devices so that all members of the family can interact easily and comfortably
with it wherever they are. 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
Thomson’s 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 s them a summary of the
different options available.”
 Scenarios
•May be textual
descriptions,
animations,
audio or video
•Example
animation
scenarios
Source: Keirnan et al. (2015), Figure 1. Reproduced with permission of ACM
Scenarios and personas
 Design fiction

• Communicate a vision with future technologies

• Fictional world in which ethics, emotions, and context can be explored without
concrete constraints
• Examples:
- Privacy and surveillance
- Exploring ethics
• Scenarios are about “overcoming the monster,” while design fiction is about
“quest”
 Use cases

• Focus on functional requirements and capture interaction

• Can be used in design or to capture requirements
• Use cases are step-by-step descriptions of interactions
• Two styles:
- Essential use cases: division of tasks, no implementation
detail
- Use case with normal and alternative courses: more detail
 Example essential use case for travel
organizer
• RetrieveVisa
USER INTENTION SYSTEM RESPONSIBILITY
Find visa requirements Request destination and nationality
Supply required information Obtain appropriate visa info
Obtain copy of visa info Offer info in different formats
Choose suitable format Provide info in chosen format

Note: The user intention and system responsibility are offset vertically, showing a sequence of interactions
 Use case for travel organizer

1. The product asks for the name of the destination country

2. The user provides the country’s name
3. The product checks that the country is valid
4. The product asks the user for their nationality
5. The user provides their nationality
6. The product checks the visa requirements of that country for a passport holder of the user’s
nationality
7. The product provides the visa requirements
8. The product asks whether the user wants to share the visa requirements on social media
9. The user provides appropriate social media information
 Alternative courses for travel
organizer
• Some alternative courses:
4. If the country name is invalid:
4.1: The product provides an error message
4.2: The product returns to step 1
6. If the nationality is invalid:
6.1: The product provides an error message
6.2: The product returns to step 4
7. If no information about visa requirements is found:
7.1: The product provides a suitable message
7.2: The product returns to step 1
 Summary
• A requirement is a statement about an intended product that specifies what it is expected to do or
how it will perform.
• Articulating requirements avoids miscommunication and supports technical developers and users
to contribute.
• Different kinds of requirements: functional, data, environmental (context of use), user
characteristics, usability goals, and user experience goals.
• Requirements data gathering uses: questionnaires, interviews, observation, studying
documentation, and similar products
• Scenarios are a story-based narrative to explore existing behavior, potential of new products, and
futuristic visions of use.
• Personas capture characteristics of typical users that are relevant to the product under
development.
• Scenarios and personas together bring requirements to life.
• Use cases capture details about an existing or imagined interaction between users and the product.