REQUIREMENTS GATHERING, STORYBOARDING AND PROTOTYPING

Learning outcomes:
 Discuss the purpose of requirements gathering
 Distinguish between functional and non-functional requirements
 Relate requirements gathering to user-centred system design
 Develop a storyboard design
 Explain and apply various prototyping methods.
6.1 Introduction
This chapter follows earlier discussion to look at the requirements gathering,
design and prototyping stages of the user-centred system design (UCSD) process. Given
that task analysis provides us with some information as to what a new interactive system
should do, we look at other sources of information about what such systems should, can
or cannot do. In particular, we look at constraints that are put on system designs by their
users or the technology with which they implemented.
6.2 Waterfall versus UCSD
Typically in projects that reflect the Waterfall approach (introduced in Chapter 4),
the costs up to the point of product release are lower than when a user-centred approach
is used. It could also be argued that the time management may be easier up to his point
as the schedule is relatively stable (no repeated or corrective activities are
accommodated in the Waterfall approach). These are both relatively modest advantages,
however, and are outweighed by the advantages of UCSD after release.
 Getting to that stage involves an in-depth understanding of the task (hence we use
task analysis) and users’ individual viewers of task (hence we use requirements
elicitation techniques). This understanding requires validation from users and a
shared understanding between users and design team members (hence we use
prototyping and evaluation methods).
 Architectural Design: having specified the functional requirements (essentially, a
wish list of features written in plain language), this is processed into the
specification of system components. These either come from a software library or
are created anew. Typically the designers will have an idea of what to put in for
users, but nothing about how to design interactivity.
 Detailed design/coding and unit testing: some components of the program may
require further description to be integrated in a suitable programming language
(detailed design). The program is then put into machine code. This is then tested
for robustness and completeness. This would not test any usability component, but
tests for bugs or its ability to cope with the volume of transactions.
 Integration and testing: components of the design are integrated into the unified
program. The program is then tested against requirements. This is largely against
functionality. No attentions is paid to usability issues.
 Maintenance: ‘maintenance’ may suggest a narrower range of activities than is
typical in this phase. Maintenance suggests the routine upkeep of a working
system. In reality, there is often more chaos and difficulty than that. It is usual for
systems developed by the Waterfall approach to need a lot of corrective attention.
This is usually to do either with the system’s failure to support a key aspect of the
task or user difficulties in performing tasks. In the former case, the early closure of
the requirements activity may have caused requirements to be missed.

Requirements
specification

Architectural
design

Detailed design

Coding and testing

Integration and
deployment

Maintenance

Figure 6.1: Waterfall model

The user-centred Approach
Let’s now remind ourselves of the UCSD model, as introduced in Chapter 4.
 Problem statement observation of existing systems

Task analysis HTA

Requirement statement
Requirements
gathering -functional
Usability guidelines & -non-functional
Heuristics Design and Storyboard
storyboarding
Technical & legal etc.
Constraints Prototype
implementation
Prototype

Evaluation
transcript & evaluation
report

Installation
Final implementation

Figure 6.2: User-centred system design (UCSD)

The user-centred approach differs from the Waterfall model in two key philosophical and
practical aspects:
 It takes the position that the user and consideration of user needs should be at the
centre of the design process
 There is the belief that systems evolve through a process of iterative refinement,
rather than simply being developed through a linear process.
On a practical note, it introduces two key concepts not present in traditional approaches:
formative evaluation and design iteration.
 Formative evaluation: here we are referring to the evaluation of design ideas and
the thinking that they embody. It may be an idea embodied in a prototype or simply
submitted as an idea. The key aim is to learn more about factors that impinge on
 design, such as knowledge of the task-space, of users’ abilities and needs and
about requirements. Each developmental stage in the user-centred approach is
accompanied by an evaluation.
 Design iteration: this addresses a key problem in using traditional methods, such
as the Waterfall method. User-centred system design builds on the use of
formative evaluation by allowing for the revisiting and refinement of any phase of
the design. For example, an evaluation of a prototype may reveal that a user may
like a facility that compiles data into a particular presentation format. The user may
only mention this requirement on inspecting the system and envisioning its actual
use in real situations. As a result of this new information, the designers can modify
the requirements statement.
6.3 Three phases of the UCSD process
Traditional methods of design tend to have a system or technology focus, rather
than a user focus. The user interface is often designed around a technical view of how
the system works. For example, the developers of an online marketplace might see
technical aspects of designing software to handle complex transactions as the central
design challenge. So many systems are designed with capabilities that users are unable
to exploit – either because they cannot understand how to operate it, or it operates in
such way that they are unable to use it.
The next three sections consider three aspects of UCSD:
 Requirements gathering
 Design and storyboarding
 Prototyping

6.4 Requirements gathering

Requirements gathering is the phase in which we find out what the proposed
system needs to do. This involves gathering information by probing potential users and
the environment in which system will be used. It may involve combination of interviews
with management, workplace observation, user surveys and analysis of existing manual
systems.
Here is an example of a requirement:
 Requirement: the system should be really learnable
 Justification: the system will be used by people with little, if any, previous
experience of IT systems
 Metric: a novice user should be able to complete the task in 20 seconds.
Sources of requirements
 The hierarchical task analysis (HTA) is one source for functional requirements. The
HTA should tell you all the tasks that the system needs to support. Usability principles
and the heuristics (the agreed ‘set of rules’) are a source for usability requirements. Other
sources include technical and legal constraints.

Types of requirement
We will consider the following types of requirement:
 Functional: as you might expect, functional requirements specify the functions
that your system will need. For example, there might be a need to be able to return
to the home screen directly from any screen
 Data: data requirements focus on the types of input and output required. For
example, the system might require you to input a password in the form of a
combination of numbers and letters. It might be required to output responses to
users in the form of easy-to-understand sentences.
 Environmental: environmental requirements set out the environment in which the
system will be used (technical and non-technical). For example, the system might
work under the UNIX operating system (technical) and be used in an office setting
only.
 User: the user requirement defines the user group (e.g. qualified lawyers)
 Usability: finally, usability requirements identify key usability issues, for example
that the system is capable of being used by inexperienced users or those with
visual impairments.
Usability could also include learnability, flexibility and consistency.

The distinction between useful and usable is relevant here and worth exploring:
 Useful means that the system can do the task. Functional requirements are what
make the system useful. Functional requirements are typically quantitative. They
are there or not there, for example, ‘The system should allow the user to enter
credit card details and debit the user’s account accordingly’. It is clear whether the
system does or does not do this.
 Usable means that using the system makes the task easy to do. Usability
requirements are what make the system usable, and are more subjective, usually
qualitative. It might not always be very clear how to measure whether a system
fulfils its usability requirements, so a metric is needed to assess the system against
requirements in a systematic and rigorous a way as possible.
Consider the following example, which is similar to that of Alice, the DIY expert in
Chapter 5:
 Gill keeps a stack of new shopping catalogues in a corner of her kitchen. When
she is preparing for dinner, she can flip through a catalogue to see what’s new or on
sale or what strikes her interest. In the evening she may pick out five or six
catalogues to look at while the family is watching TV. She may even take a few to
bed, or to the bath.
She generally browses through the pictures, reading descriptions only when the
pictures look interesting. When she finds something interesting, she may fold down
(‘dog-ear’) the corner of the page, draw a circle round it or mark the page with a
sticky note. She keeps catalogues with marked pictures around until she wants to
make a purchase.

HTA Text
0. Using catalogues
1. Browse items
1.1. Browse by what’s new
1.2. Browse by sales
1.3. Browse by items that interest
1.4. Browse by catalogues
1.4.1. Browse in kitchen
1.4.2. Browse while watching TV
1.4.3. Browse in bed
2. Mark items
2.1. Circle item
2.2. Mark page
2.2.1. Dog-ear page
2.2.2. Sticky on page
HTA Plans
The source doesn’t say much about how the tasks are done, but…
Plan 0: do 1, then 2 if item found.
Plan 1: do 1.1 or 1.2 or 1.3 or 1.4.
Plan 2: do 2.1 or 2.2.
Functional requirements
The user must be able to browse items in the catalogues
Browse by what’s new
Browse by sales
Browse by items that interest
Browse by catalogues

Justification: Sub-task 1 from HTA

The user must be able to mark items for later recall.
Justification: Sub-task 2 from HTA
But note that the HTA showed that the ways of marking things in the catalogues was
problematic. Therefore stronger justification is needed here.

Usability
Requirement: the system should be flexible
Justification: the HTA shows that the user fits the task of browsing around other tasks.
Therefore the system should be flexible to accommodate this.
Metric: it should be possible to pause the system at any point without causing errors.

Activity 6.1: Functional requirements specification

Below is a hierarchical task analysis (HTA) description and related plans for
someone buying a cinema ticket manually.
Based on HTA and plans, formulate a requirements specification for a new online
cinema ticket selling system. For each requirement, you should give a thorough
justification linking it to the HTA and you should also, if possible, describe metrics for
the requirements.
Hierarchical Task Analysis (HTA)
0. Buying a cinema ticket manually
1. Choose cinema
1.1. Gather info about available cinemas
1.1.1. Draw upon previous knowledge
1.1.2. Look in local papers for cinema listings
1.1.3. Ask others
1.2. Decide on which cinema
1.2.1. Based on individual preference
1.2.2. Based on group preference
2. Go to the cinema
2.1 Choose time of travel
2.2. Choose travel method
3. Choose film showing
3.1. Read the list of film titles
3.1.1. Look at display board
3.1.2. Look at leaflets
3.1.3. Look at trailers on mini-screen
3.2 Read the list of times for the films
3.3 Choose film showing
2.3.1. Based on individual preference
3.3.2. Based on group preference
4. Check seat availability
4.1. Look on display board
4.2. Ask staff
 5. Buy ticket
5.1. Initiate ticket purchase
5.1.1. Give film details
5.1.1.1. Give film name
5.1.1.2. Give film time
5.1.2. Give ticket(s) details
5.1.2.1. Give ticket type(s)
5.1.2.2. Give ticket count of each type
5.2. Pay for tickets
5.2.1. Find out amount due
5.2.2. Tender payment
5.2.2.1. Offer any proof needed for concessions
5.2.2.2. Pay by cash
5.2.2.3. Pay by credit/ debit card
5.2.2.4. Pay by voucher
5.2.3. Collect tickets
Plan
Plan 0: Do 1, then do 2, then do 3, until satisfied.
If not satisfied, then start at 1 again or stop.
If satisfied do 4.
If available, do 5.
If not available, do 3 or start at 1 again or stop.
The user will choose a cinema, go to it and then choose a film. If a film they want to see
is not showing, then they may either choose another cinema, or give up. If a film they
want to see is showing, then they check seat availability and buy a ticket. If there are no
seats available, they may choose another cinema, choose another film or give up.

Plan 1: Do 1.1, then 1.2.

Users will find out about different cinemas, then choose one.
Plan 2: Do 2.1 and 2.2 in any order, then 2.3.
To get to the cinema, users choose a time for travel and a method, then
travel.
Plan 3: Do 3.1 and 3.2 in any order, then 3.3.
To choose a film, users read the list of films available and times, and then make
a decision.
Plan 4: Do either 4.1 or 4.2 or both.
To check seat availability, users can either look at the notice board or ask cinema
staff.
Plan 5: Do 5.1 then 5.2.
Users must first inform the cinema staff of which tickets they want, before paying
for them.

Plan 1.1: Do 1.1.1 and/or 1.1.2. and/or 1.1.3 in any order.

There is no prescriptive order to how users find out about cinemas.