CST3180

z
User
Experience
(UX) Design
Week 3 Task Analysis and Requirements
Specification
 Introduction

 Explain the purpose of task analysis and modelling

 Carry out HTA

 Explain and show how results of HTA can be used to improve interaction

 Usability Metrics

 Specification of Functional and Non-Functional requirements od a system

 Requirements specification

 Describing what the proposed system should do

 (Not how it should do it, or what it should look like)

 Output: The requirements statement

 Divided into ‘functional’, ‘usability’, ‘user’, ‘data’ and ‘environment’ requirements

Sources for
The Task Analysis
should tell you all the
Task Analysis tasks that the system
requirements... should support

Not design rules

Usability principles But you need to explain

why the principles are
applicable

Personas will be covered in week 5

Other constraints Technical, legal, etc.

 A list of what is required
of a system

Requirements

For each requirement…

(Maybe) a metric
scheme that shows
What its justification is
how the system
What it is (where is it coming
performance can be
from)
measured against the
requirement
 What is task analysis?

 Means of analysing and describing the jobs people do

 Method and notation

 Focus on

 peoples’ goals and the actions they carry out

 the things people know

 the things they act on

 Hierarchical Task Analysis

 One of the most common forms of Task Analysis

 Involves

 Identifying goals that user wants to achieve

 Decomposing goals into tasks

 Further decomposing into subtasks

 Repeat; stop at the level of actions

 HTA Example: withdrawing cash
from an ATM
 Withdrawing cash from an ATM requires tasks from the user...

 What are those tasks?

 0 Withdraw cash
1 Check machine will work
1.1 Look at status indicator
1.2 Look for card logo
2 Insert card

Textual 3 Enter PIN number

4 Initiate withdrawal transaction
presentation 4.1 Select withdraw cash
4.2 Enter amount
5 Complete transaction
5.1 Take card
5.2 Take cash
 Adding plans

 Hierarchical diagram / text indicates what subtasks are part of a task

 Does not specify how the subtasks are carried out

 Plans are used to describe

 order of subtasks

 conditional or optional subtasks

 repetition

 etc.
Plans

A plan needed for each decomposed task

Plan 0: do 1; if possible do 2; repeat 3

until PIN correctly entered;
do 4; do 5.

Plan 1: do 1.1, 1.2 in any order

Plan 4: do 4.1; do 4.2

Plan 5: wait until card available; do 5.1;

wait until cash available; do
5.2
 Functional Requirements

Functional requirement 1:
 Description: The user should be able to withdraw cash.
 Justification: This is the main function of a ATM.

Functional requirement 2:
 Description: The ATM should indicate if it is fully working.
 Justification: The user should know if the ATM is working or not.

Functional requirement 3:
 Description: The ATM should indicate if all bank cards are accepted for cash withdrawal.
 Justification: The user should know if their cash card is accepted by the ATM.
 .
 .
Functional requirement 5:
 Description: The ATM should ask the user to enter their PIN number.
 Justification the user should : This should be required by the ATM to correctly identify the owner.
 .
Functional requirement 7:
 Description: The ATM should inform the user to take their cash.
 Justification: The user should know that the cash is ready to collect.
 Data Requirements

Data requirement 1: Description: The ATM should display/output information on the screen
indicating if the machine works or not. Required by Functional Req. 2.

Data requirement 2: Description: The ATM should display/output information for the PIN entry.
Required by Functional Req. 5.

Data requirement 3: Description: The user should be able input their PIN number.
Required by Functional Req. 5.
 Usability Metrics...

 A ‘metric’ is a way of measuring things  Quantitative:

 Metrics can be direct or indirect  Time

 If you weigh something, then you are  Key presses

directly measuring its weight  Number of errors
 Measuring the volume and density and
 Qualitative
then calculating the mass is an indirect
metric  User satisfaction

 Most usability metrics are indirect  User enjoyment

 Non-functional requirements

User requirements

 Description: The system should be a 'walk up and use’ system, requiring very little explicit
training

 Justification: The intended users are a very broad sample of the population who would
not expect to be 'trained’ to use an ATM. 

Environment requirements

 Description: An outdoor ATM should function in any time of a day and in any weather
condition.

 Justification: The main aim of an outdoor ATM to provide service whenever needed.
 Non-functional requirements

Usability requirements 1

 Description: The system should be an easy to use 'walk up and use’, learnable /
learnable system and should maximize the use’s ability to correctly predict the
outcome of actions with a minimum of experience with the system.

 Justification: An easy to use / learnable / predictable system will help users to

predict the results of their use.

 Metric: The useful implementation of these usability requirements is hard to

measure. If more than 10 % of the users have to ask basic questions relating to the
functionality of an interface element, then this requirement has not been satisfied.
 Non-functional requirements

Usability requirements 2

 Description: An ATM should allow users to recover any error conditions which may
arise.

 Justification: Even frequent users may encounter errors when using an ATM.
Therefore, the users should be able to recover easily. This requirement draws directly
from Nielsen’s heuristic of ‘Help users recognize, diagnose, and recover from errors’ as
well as ‘Recoverability’.

 Metric: when any error do occur, 95% of the test subjects can navigate their way to a
state that has removed the error condition without having to resort to restarting the
entire process.
 Non-functional requirements

Usability requirements 3

 Description: An ATM should allow users to know what is happening inside the
system via providing timely and relevant information.

 Justification: the interface of an ATM would let the user know what the relevant
internal states of the system are at that moment. This requirement draws directly
from Nielsen’s principle of ‘Visibility of system status’ as well as ‘Observability’.

 Metric: No more that 15% of the users should find themselves in a dead end.
 Summary

 Task analysis gives designers a means of describing how people do their jobs

 Task analysis help to investigate existing systems and build “walk up and use”
systems

 There are different kind of requirements: Functional, environmental, data, user and
usability requirements

 Getting requirement right is crucial

 Recommended Reading

1. Serengul Smith-Atakan (2006). Human Computer Interaction (FastTrack). ISBN

10-84480-454-2
 Additional HTA example
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
2.3. Travel to Cinema

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
 HTA – Cinema Ticket Machine
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.

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 the 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.
 Functional Requirements

Functional Requirement 1: List Cinemas

Description: The system should provide the user with a listing of available cinemas.
Justification: The user needs to know which cinemas are available before they can choose one.
HTA 1.

Functional Requirement 2: List Films

Description: The system should provide the user with a listing of available films.
Justification: The user needs to know which films are available before they can choose one. HTA
3.1.

Functional Requirement 3: List Film Show Times

Description: The system should provide the user with a listing of the times of all the available film
showings.
Justification: The user needs to know when each film is being shown in order to be able to
choose one. HTA 3.2.
 Functional Requirements

Functional Requirement 4: Secure Payments

Description: The system should have a secure method of taking payments for the tickets sold.
Justification: In order for an online ticket selling system to sell tickets the system needs to be
able to take payments. HTA 5.2.2.

Functional Requirement 5: Ticket Collection

Description: The system should have a method of the purchased tickets being physically
collected / delivered.
Justification: Since unlike the physical task modelled in the HTA above the purchase was made
online, the tickets can not be given at the same time. There needs to be a way of collecting these
tickets otherwise there is no point in buying them. Extrapolated from HTA 5.2.3.
Etc etc….
 Other Requirements

Data requirement
Description: The system should output: cinemas catered for (functional requirement 1), available
films (functional requirement 2), times (functional requirement 3) and availability (functional
requirement 6). The system should take as input: users’ requests for which cinema/film they wish
to see (functional requirement 7) and credit card details (functional requirements 7 and 4).
Justification: All these data are needed by the functional requirements.

Environment requirement
Description: The system should be accessible via the Internet using an HTTP protocol.
Justification: An online system by definition needs to be online.

User requirement
The intended users are a very broad sample of the population who would not expect to have to
be ‘trained’ in using the site. Therefore the system should be ‘walk up and use’, requiring very
little explicit training. The broad nature of the user population means that care must also be
taken to ensure that (for example) cultural differences do not exclude certain parts of the
population