ESTABLISHING REQUIREMENTS

CHAPTER 8
 TOPICS

• What, How and Why?

• What are Requirements?
• Data Gathering for Requirements
• Task Description
• Task Analysis
 LEARNING OUTCOME

• Describe different kinds of requirements.

• Enable you to identify different kinds of requirements
from a simple description.
• Explain how different data gathering techniques may be
used during the requirements activity.
• Enable you to develop a scenario, a use case, and an
essential use case from a simple description.
• Enable you to perform hierarchical task analysis on a
simple description.
 What, How, and Why?

1. What Are We Trying to Achieve in the

Requirements Activity?
• One aim is to understand as much as possible about
the users, their activities, and the context of that
activity, so the system under development can
support them in achieving their goals.
• Second aim is to produce a set of stable
requirements that form a sound basis to start
designing.
 What, How, and Why?
2. How Can We Achieve This?
• At the beginning of the requirements activity, there is a
lot to find out and to clarify.
• At the end of the activity we will have a set of stable
requirements that can be the basis of the design activity.
• In the middle, there are activities concerned with data
gathering, analysis, interpretation, and presentation,
with the aim of expressing the findings as requirements.
• In a sequential manner: first gather some data, then
analyse and interpret it, and then extract some
requirements from it.
 What, How, and Why?

3. Why Bother? The Importance of Getting it Right

• The cartoon below illustrates very well what can go
wrong if requirements are not clearly articulated.
 What, How, and Why?
4. Why ‘Establish’ Requirements?
• The term establishing requirements is to represent the
fact that requirements have been established from a
sound understanding of the users’ needs and that they
can be justified by and related back to the data collected.
• The term requirements analysis is normally used to
describe the activity of investigating and analysing an
initial set of requirements that have been gathered,
elicited, or captured.
 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 aims of the requirements activity is to make the
requirements as specific, unambiguous, and clear as possible.
• For example, a requirement for a smartwatch GPS app might
be that the time to load a map is less than half a second.
• Another, less precise, example might be that teenagers
should find the smartwatch appealing.
• In the case of this latter example, further investigation would
be necessary to explore exactly what teenagers would find
appealing.
 What Are Requirements?

An example requirement using the Volere shell

 What Are Requirements?
1. Different Kinds of Requirements
• Two different kinds of requirements have traditionally been identified:
• Functional requirements - which say what the system should do. For
example, a new video game may be that it should be challenging for a
range of user abilities. This requirement might then be decomposed
into more specific requirements detailing the structure of challenges,
e.g. hierarchical levels, hidden tips and tricks, magical objects, and so
on.
• Non-functional requirements - which say what constraints there are on
the system and its development. A non-functional requirement for this
same game might be that it can run on a variety of platforms such as
Xbox, PlayStation, and Wii consoles. A different kind of non-functional
requirement would be that it must be delivered in 6 months’ time. This
represents a constraint on the development activity itself rather than
on the product being developed.
 What Are Requirements?

1. Different Kinds of Requirements

• List / Categories of requirements:
– Functional requirements
– Data requirements
– Environmental requirements – or context of use
– User characteristics
– Usability requirements
– User experience goals
 What Are Requirements?
1. Different Kinds of Requirements
Functional requirements
• Capture what the product should do.
• For example, a functional requirement for a robot
working in a car assembly plant might be that it should
be able to accurately place and weld together the
correct pieces of metal.
• Understanding the functional requirements for an
interactive product is fundamental.
 What Are Requirements?

1. Different Kinds of Requirements

Data requirements
• Capture the type, volatility, size/amount, persistence,
accuracy, and value of the required data.
• All interactive products have to handle some data.
• For example, if the system under consideration is a share-
dealing application, then the data must be up-to date and
accurate, and is likely to change many times a day.
• In the personal banking domain, data must be accurate,
must persist over many months and probably years, and
there is likely to be a lot of it.
 What Are Requirements?

1. Different Kinds of Requirements

Environmental requirements or context of use
• Refer to the situations in which the interactive
product will operate.
• Four aspects of the environment must be considered
when establishing requirements which are :
– physical environment
– social environment
– organizational environment
– technical environment
 What Are Requirements?
1. Different Kinds of Requirements
Environmental requirements or context of use

i. Physical environment - such as how much lighting, noise,

movement, and dust is expected in the operational environment.
ii. Social environment - e.g. will data need to be shared?
iii. Organizational environment - e.g. how good is user
support likely to be, how easily can it be obtained, and
are there facilities or resources for training?
iv. Technical environment – e.g. what technologies will the
product run on or need to be compatible with, and
what technological limitations might be relevant?
 What Are Requirements?

1.Different Kinds of Requirements

User characteristics
• Capture the key attributes of the intended user group.
• The relevance of a user's abilities and skills are an important
aspect of user characteristics.
• Other characteristics that may affect the design are: the users’
nationality, educational background, preferences, personal
circumstances, physical or mental disabilities, and so on.
• A user may be a novice, an expert, a casual, or a frequent user
and this affects the ways in which interaction is designed.
 What Are Requirements?
1.Different Kinds of Requirements
Usability Requirements
• Usability requirement concerns with user’s satisfaction and overall
performance of a system.
• Usability requirement is gathered using the same technique as
other requirement gathering techniques such as interviewing, and
observation. The activity of gathering the usability of a system is
known as usability study.
• Usability metrics is the measurement of usability requirements.
The performance accessed includes time to complete tasks by a
specified user, how many errors made and time spent on system
documentation.
• Focus on objective measures of the user's performance.
 What Are Requirements?

1.Different Kinds of Requirements

User Experience Goals
• Although it is harder to identify quantifiable
measures that track these qualities, an
understanding of their importance should be
obtained during the requirements activity.
• Focus on the user's perceptions of the interaction.
 What Are Requirements?-ACTIVITY
Suggest some key requirements in each category above
(functional, data, environmental, user characteristics,
usability goals and user experience goals) for each of
the following situations:
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.
2. An interactive product to control the functioning of a
nuclear power station.
 Data Gathering for Requirements

• The overall purpose of data gathering in the

requirements activity is to collect sufficient, relevant,
and appropriate data so that a set of stable
requirements can be produced.
• Data gathering needs to cover a wide spectrum of
issues: the tasks that users currently perform and
their associated goals, the context in which the tasks
are performed, and the rationale for the current
situation.
 Data Gathering for Requirements
• Interviews - Interviews are good for exploring issues,
and semi-structured or unstructured interviews are
often used early on to elicit scenarios. It is equally
important for development team members to meet
stakeholders and for users to feel involved.
• Focus groups - Focus groups are good for gaining a
consensus view and highlighting areas of conflict and
disagreement during the requirements activity. On a
social level it also helps for stakeholders to meet
designers and each other, and to express their views
in public.
 Data Gathering for Requirements

• Questionnaires - Questionnaires may be used for getting

initial responses that can then be analysed to choose
people to interview or to get a wider perspective on
particular issues that have arisen elsewhere.
• Direct observation - Observation of participants in their
natural setting is used to understand the nature of the tasks
and the context in which they are performed.
• Indirect observation - If a product is being developed
iteratively or is evolving from an existing product, indirect
observation and experience sampling are very valuable.
Interaction logging together with sophisticated web
analytics are particularly useful for improving websites.
 Data Gathering for Requirements

• Studying documentation - Studying documentation is good

for understanding legislation and getting some background
information on the work. It also doesn't involve stakeholder
time, which is a limiting factor on the other techniques.
• Researching similar products - Looking at similar products
will generate alternative designs. Another reason to look at
similar products is to help prompt requirements. For
example, when developing an image editor for a mobile
device, Kangas and Kinnunen (2005) report that they
looked at PC image editing software in order to gain an
understanding of the kinds of features and interaction that
such a package might offer.
 Data Gathering for Requirements
1. Contextual Inquiry

• Contextual inquiry is one of seven parts of contextual design which is a

structured approach to the collection and interpretation of data from
fieldwork with the intention of building a software-based product.
• Contextual design involves the production of five different models of work.
• It is a popular technique for uncovering requirements, and in particular in
uncovering requirements relating to the context of use.
• For example Meschtscherjakov et al (2011) used contextual inquiry over a
period of six weeks to investigate how car drivers interact with the multi-
function rotating button often found in the centre of the car dashboard.
The study highlighted that comfort, safety, and security factors were
mentioned most often, while visual and haptic aesthetics were not
mentioned by any participants. These findings informed the design of new
in-vehicle information systems.
 Data Gathering for Requirements
1. Contextual Inquiry
• It is an approach that emerged from the
ethnographic approach to data gathering.
• The most typical format for contextual inquiry is a
contextual interview, which is a combination of
observation, discussion, and reconstruction of past
events.
• Contextual inquiry rests on four main principles:
context, partnership, interpretation, and focus.
 Data Gathering for Requirements
2. Data Gathering Guidelines for Requirements
Here are a few more specific guidelines worthy of note
when gathering data for requirements:
Focus on identifying the stakeholders’ needs.
Involve all the stakeholder groups.
Involving only one representative from each
stakeholder group is not enough, especially if the
group is large.
Support the data gathering sessions with suitable
props, such as task descriptions and prototypes if
available.
 Task Description
• As shown by Alexander and Maiden's (2004)
collection of scenarios, stories, and use cases, there
are many different flavours of task description, and
they can be used for different purposes, emphasizing
different elements of the product being developed.
• There are three common description types :
scenarios, use cases, and essential use cases
(sometimes referred to as task cases).
 Task Description
1. Scenarios
• A scenario is an ‘informal narrative description’.
• It describes human activities or tasks in a story that allows
exploration and discussion of contexts, needs, and
requirements.
• It does not necessarily describe the use of software or
other technological support to achieve a task.
• Using the vocabulary and phrasing of users means that
scenarios can be understood by the stakeholders, and they
are able to participate fully in the development process.
• In fact, the construction of scenarios by stakeholders is
often the first step in establishing requirements.
 Task Description
1. Scenarios
A scenario that might be generated by potential users of an online movie
rental subscription service is given below:
• Say I want to find a movie directed by Martin Scorsese. I don't
remember the title but I know it came out in the cinemas around 2006
or 2007. I go to the service web site and choose the director option. A
huge list of directors is displayed – I had no idea there were so many
directors with surnames beginning with S! After scrolling through the
list I find Martin Scorsese and choose to see further details about him.
Another long list of movies eventually leads me to the movie I was
looking for – The Departed. As an existing subscriber, I need to log in to
be able to rent the movie. Once my login has been confirmed, I can
choose the rental period and payment method. I have my preferences
already registered in the system, so I just choose the defaults and
download my movie.
 Task Description - ACTIVITY

• Write a scenario of how you would currently go

about choosing a new car. This should be a brand
new car, not a second-hand car. Having written it,
think about the important aspects of the task: your
priorities and preferences. Then imagine a new
interactive product that supports you in your goal
and takes account of these issues. Write a futuristic
scenario showing how this product would support
you.
 Task Description
2. Use Cases
• Use cases also focus on user goals, but the emphasis here is on
a user–system interaction rather than the user's task itself.
• Although their focus is specifically on the interaction between
the user (called an actor) and a software system, the stress is
still very much on the user's perspective, not the system's.
• The term scenario is also used in the context of use cases.
• In this context, it represents one path through the use case, i.e.
one particular set of conditions.
• A use case is associated with an actor, and it is the actor's goal
in using the system that the use case wants to capture.
 Task Description
2. Use Cases
A use case for retrieving the visa requirements using the travel organizer, with the normal course being that information about the
visa requirements is available, might be:
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 the 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.
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.
 Task Description
2. Use Cases
• Use cases may be described graphically. Figure below shows the use case diagram for the
travel organizer.
• To develop a use case, first identify the actors, i.e. the people or other systems that will be
interacting with the system under development. Then examine these actors and identify
their goal or goals in using the system. Each of these will be a use case.

Use case diagram for the travel organizer showing four use cases and two actors
 Task Description
3. Essential Use Cases
• Essential use cases were developed by Constantine and Lockwood (1999)
to fight what they see as the limitations of both scenarios and use cases
as described before.
• Essential use cases (also referred to sometimes as task cases) represent
abstractions from scenarios, i.e. they represent a more general case than
a scenario embodies, and try to avoid the assumptions of a traditional
use case.
• An essential use case is a structured narrative consisting of three parts: a
name that expresses the overall user intention, a stepped description
of user actions, and a stepped description of system responsibilities.
• This division between user and system responsibilities can be very
helpful during conceptual design when considering task allocation and
system scope, i.e. what the user is responsible for and what the system is
to do.
 Task Description
3. Essential Use Cases
• An example essential use case based on the visa requirements is shown in figure
below.
• Essential use cases would normally be developed before the more detailed use case.

An essential use case for retrieving visa requirements in the travel organizer
 Task Analysis
• Task analysis is used mainly to investigate an existing
situation, not to envision new products.
• It is used to analyse the underlying rationale and
purpose of what people are doing: what are they
trying to achieve, why are they trying to achieve it,
and how are they going about it?
• The most widely used version is Hierarchical Task
Analysis.
 Task Analysis
1. Hierarchical Task Analysis
• Hierarchical Task Analysis (HTA) was originally designed
to identify training needs.
• It involves breaking a task down into subtasks and then
into sub-subtasks and so on.
• These are then grouped together as plans that specify
how the tasks might be performed in a real situation.
• HTA focuses on the physical and observable actions that
are performed, and includes looking at actions that are
not related to software or an interactive product at all.
 Task Analysis
1. Hierarchical Task Analysis
• The starting point is a user goal.
• This is then examined and the main tasks associated
with achieving that goal are identified.
• Where appropriate, these tasks are subdivided into
subtasks, and then subtasks can be divided further –
down to low-level steps of the interaction which may
be represented in a screen sketch.
 Task Analysis
1. Hierarchical Task Analysis
• Consider the task of buying a DVD.
• This task can be decomposed into the subtasks: locate
DVD; add DVD to shopping basket; enter payment details;
complete address; and confirm order.
• Some of these subtasks might not be performed if the
user is a regular user – entering payment and address
details may not be performed in this case.
• This can be captured through plans.
 Task Analysis
1. Hierarchical Task Analysis
Figure below shows the subtasks for buying a DVD and one
plan showing two alternative paths through those subtasks.
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.
Figure 1: An HTA for buying a DVD
 Task Analysis
1. Hierarchical Task Analysis
Figure 2 below shows the graphical version of the HTA
in Figure 1.
An alternative expression of an HTA is a graphical box-
and-line notation.

A graphical representation of the

task analysis for buying a DVD
 Task Analysis
1. Hierarchical Task Analysis
• There are two main problems with using it on real
problems:
1. Real tasks are very complex, and task analysis does not
scale very well. The notation soon becomes unwieldy,
making it difficult to follow.
2. Task analysis is limited in the kinds of task it can model.
For example, it cannot model tasks that are overlapping
or in parallel, nor can it model interruptions. Most people
work through interruptions of various kinds, and many
significant tasks happen in parallel.
 Task Analysis
1. Hierarchical Task Analysis
Benefits of task analysis include:
1. It lets you objectively compare alternative designs,
based on a user's planned tasks and subtasks.
2. It provides a good understanding of the
interaction at whichever level of abstraction is
appropriate. This facilitates good design.
3. It supports design reuse – again at different levels
of abstraction.