Identifying needs and

establishing
requirements
 What, how and why?
What is requirement gathering
Two aims:
1. Identify the user/ stakeholder
2. Understand as much as possible about users,
task, context
3. Produce a stable set of requirements

How to gather requirements

Data gathering activities
Data analysis activities
All of this is iterative
 What, how and why?

Why:
Requirements definition: the stage where failure
occurs most commonly.
Getting requirements right is crucial.

Requirements are easily misunderstood, often

unclear, incomplete and poorly written.

Many Users do not even know what they want!

 Importance of getting the
requirements right
• Better to get the requirements right the first time.
• It takes effort and time to fix errors later on in the
design.
• Many projects fail due to poor requirement
gathering.
• Contributing factors to failure:
– Insufficient user communication, poor specs, insufficient
analysis, limited identification of stakeholders, insufficient
user involvement, assumption of requirements, etc.
Misunderstood requirements
 Establishing requirements
Different names for the same thing
•Requirements gathering
•Requirements capture
•Requirements elicitation
•Requirement analysis
•Requirements engineering

•Gathering or capture seems like requirements just need to be collection out of

thin air
•Elicitation means users know the requirements. We just need to ask them to
tell us.
•Requirement analysis is the process of investigating and analyzing an initial
set of requirements.
•Establishing requirements and requirements engineering are better term
owing to wider coverage.
 A Good Requirement
• Unambiguous.
• Testable (verifiable)
• Concise
• Correct
• Understandable
• Feasible (realistic, possible)
• Independent
• Atomic
Different kinds of requirements
• Functional:
• What the system should do
• Historically the main focus of requirements activities
• Non-functional
• What constraints are on the system and its development
• memory size, response time...
• Data:
—Describe the details of data that the system works with.
—Type, volatility, size, persistence, accuracy etc.
Different kinds of requirements
Environment or context of use:

— physical: dusty? noisy? vibration? light?

heat? humidity?
— Social environment: sharing of files, of
displays, in paper, across great distances, work
individually, privacy for clients
— Organisational: hierarchy, IT department’s
attitude, user support, communications
structure and infrastructure, availability of
training
—Technical Environment: What technologies
will the system run on. Performance
requirements etc
Different kinds of requirements

•Usability:
learnability, throughput, flexibility,
attitude

Note that user requirements and usability

requirements refer to different things
 Kinds of requirements
What factors (environmental, user, usability) would
affect the following system?

• Self-service filling and payment system for a petrol

(gas) station
Data gathering techniques (1)
Questionnaires:
—A series of questions designed to elicit specific information

—Questions may require different kinds of answers:

simple YES/NO; choice of pre-supplied
answers; comment

—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
Data gathering techniques (2)
Interviews:
—Forum for talking to people
—Structured, unstructured or semi-structured
—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
Data gathering techniques (3)
Workshops or focus groups:
—Group interviews
—Good at gaining a consensus view and/or
highlighting areas of conflict
Data gathering techniques (4)
Naturalistic observation:
—Spend time with stakeholders in their
day-to-day tasks, observing work as it
happens
—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
—Ethnography is one form
Data gathering techniques (5)
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
 Choosing between techniques
Data gathering techniques differ in two ways:
1. Amount of time, level of detail and risk associated
with the findings
2. Knowledge the analyst requires

The choice of technique is also affected by the kind of

task to be studied:
—Sequential steps or overlapping series of subtasks?
—High or low, complex or simple information?
—Task for a layman or a skilled practitioner?
 Problems with 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:
 Problems with 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
• Availability of key people
Problems with data gathering (3)
•Political problems within the organisation

•Dominance of certain stakeholders

•Economic and business environment changes

•Balancing functional and usability demands

 Some basic 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
 Some basic guidelines
•Support the process with props such as prototypes
and task descriptions
•You will need to compromise on the data you collect
and the analysis to be done
•Consider carefully how to record the data
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
 Task descriptions
•Scenarios
an informal narrative story, simple, ‘natural’,
personal, not generalisable
•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
Scenario for shared calendar
“The user types in all the names of the meeting participants
together with some constraints such as the length of the
meeting, roughly when the meeting needs to take place, and
possibly where it needs to take place. The system then checks
against the individuals’ calendars and the central
departmental calendar and presents the user with a series of
dates on which everyone is free all at the same time. Then the
meeting could be confirmed and written into people’s
calendars. Some people, though, will want to be asked before
the calendar entry is made. Perhaps the system could email
them automatically and ask that it be confirmed before it is
written in.”
 Sample Requirements
1. The system must maintain a list of employees
2. The system will allow meeting moderator to call a meeting
3. The moderator must specify who will be part of the meeting by
choosing people from the list of employees
4. The moderator must specify a suitable date for the meeting
5. The moderator must specify a suitable time for the meeting
6. The moderator must specify a meeting duration
7. The moderator must specify a suitable location for the meeting
8. Based on the provided constraints the system must suggest
suitable date(s) and time(s) for the meeting.
9. The moderator must choose a suitable meeting slot from those
presented by the system.
Example use case diagram for shared calendar

Arrange a
meeting

Retrieve
contact details

Administrator Departmental
member
Update calendar
entry
 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 borrow a book from the library

1. go to the library
2. find the required book
2.1 access library catalogue
2.2 access the search screen
2.3 enter search criteria
2.4 identify required book
2.5 note location
3. go to correct shelf and retrieve book
4. take book to checkout counter
Example Hierarchical Task Analysis
(graphical)
Borrow a
book from the
library 0
plan 0:
do 1-3-4.
If book isn’t on the shelf expected, do 2-3-4.

go to the find required retrieve book take book to

library book from shelf counter
1 2 3 4

plan 2:
do 2.1-2.4-2.5.
If book not identified from information available, do 2.2-2.3-2.4-2.5

access access enter identify note

catalog search search required location
2.1 screen 2.2 criteria 2.3 book 2.4 2.5