CSE4107-Human Computer Interaction

Lecture 4: Establishing Requirements

Dr. Md. Sazzad Hossain, PhD (Japan)

Professor
Department of CSE
Mawlana Bhashani Science and Technology University
Email: [email protected]

1
Agile methods and requirements

• Many agile methods argue that producing detailed system

requirements is a waste of time as requirements change so
quickly.
• The requirements document is therefore always out of date.
• Agile methods usually use incremental requirements
engineering and may express requirements as ‘user stories’.
• This is practical for business systems but problematic for
systems that require pre-delivery analysis (e.g. critical
systems) or systems developed by several teams.

2
Functional and non-functional requirements

• Functional requirements
• Statements of services the system should provide, how the system should
react to particular inputs and how the system should behave in particular
situations.
• May state what the system should not do.
• Non-functional requirements
• Constraints on the services or functions offered by the system such as
timing constraints, constraints on the development process, standards,
etc.
• Often apply to the system as a whole rather than individual features or services.
• Domain requirements
• Constraints on the system from the domain of operation

3
functional Vs non-functional requirements

• An example of a functional requirement would be:

• A system must send an email whenever a certain condition is met (e.g. an
order is placed, a customer signs up, etc).
• A related non-functional requirement for the system may
be:
• Emails should be sent with a latency of no greater than 12 hours from such an
activity.
• The functional requirement is describing the behavior of
the system as it relates to the system's functionality. The
non-functional requirement elaborates a performance
characteristic of the system.

4
System stakeholders

• Any person or organization who is affected by the

system in some way and so who has a legitimate
interest
• Stakeholder types
• End users
• System managers
• System owners
• External stakeholders

5
Case Study : Stakeholders

Suppose that you have to develop software for cash dispenser. You
should develop software for both cash dispenser, i.e. the part for
communication with the customers (delivering money and report
the account state), the software for communication and software
needed in banks for communicate with the bank transaction
systems. You have a team of 10 people – all of them can play a role
of designers, developers, testers and document writers. You have
got a contract to implement the first version in 6 months. All
hardware and development tools are available. In the project 5
banks are included that use 2 different transaction systems. The
customer wants that you incrementally implement the system –
first the cash dispenser software, then the interface to the bank
account system, finally the communication. The total system
should be delivered after 6 months.
6
Problems of requirements elicitation

• Stakeholders don’t know what they really want.

• Stakeholders express requirements in their own terms.
• Different stakeholders may have conflicting requirements.
• Organisational and political factors may influence the system
requirements.
• The requirements change during the analysis process. New
stakeholders may emerge and the business environment may
change.

7
The requirements elicitation and analysis
process

8
Process activities

• Requirements discovery
• Interacting with stakeholders to discover their requirements. Domain
requirements are also discovered at this stage.
• Requirements classification and organisation
• Groups related requirements and organises them into coherent
clusters.
• Prioritisation and negotiation
• Prioritising requirements and resolving requirements conflicts.
• Requirements specification
• Requirements are documented and input into the next round of the
spiral.

9
Requirement Gathering

• The importance of requirements

• Data gathering for requirements
• Data analysis and presentation
• Task description: Scenarios
Use Cases
Essential use cases
• Task analysis: HTA
What, how and why?

• Why bother?
Requirements
definition is the
stage where
failure occurs
most commonly

Getting requirements right is crucial

11
 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

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: short cuts

— Casual/infrequent: clear menu paths

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 child’s toy requires little strength to operate, but greater

strength to change batteries

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

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

• Not real people, but synthesised from real users

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

• Develop a small set of personas with one primary

• Personas are fictional characters, which we create based upon our research to
represent the different user types that might use our service, product, site, or
brand in a similar way. Creating personas will help us understand our users’
needs, experiences, behaviors and goals.
Example Persona
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
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 understanding legislation, and

getting background information
— No stakeholder time, which is a limiting
factor on the other techniques
Some examples

Cultural probes
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

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
 How to describe the tasks?
• 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
— an essential use case describes only the most important information it
represents a single success scenario. In contrast, a system use case
describes the interaction between the user and system in a more
detailed way than and essential use case.
Scenarios and Personas
 Case Study: 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. 26
Alternative courses for travel organizer
Some alternative courses:

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.
27
Example use case diagram for travel organizer
Example essential use case (business use case)
for travel organizer

retrieve Visa

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

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)
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

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.
Example Hierarchical Task Analysis
Guidelines for writing requirements

• Invent a standard format and use it for all requirements.

• Use language in a consistent way. Use shall for mandatory
requirements, should for desirable requirements.
• Use text highlighting to identify key parts of the requirement.
• Avoid the use of computer jargon.
• Include an explanation (rationale) of why a requirement is
necessary.

34