And Franchise Colleges
Supplement 02 (b)
i.
Requirements gathering and Task Analysis
ii.
User Requirements
By MANSHA NAWAZ
Supplement 02 (b)
User Requirements
1
Learning Objectives
• The Problem of Establishing User
Requirements
• What do we start with?
• What do we need to achieve?
• Reflections on the Problem Domain
• What is important?
• What abstractions can we use?
Supplement 02 (b)
User Requirements
2
i. Requirements gathering and
Task Analysis
• Requirements gathering is a central part of systems
development
• Analysis involves understanding as well as
representation of requirements
• Requirements should include functional, data and
usability requirements
• In user-centred approaches, requirements gathering
almost always involves some design
Supplement 02 (b)
User Requirements
3
Requirements Gathering
Techniques
• Traditional, Structured Methods use a toolkit
of techniques for gathering requirements
– input from client in the form of a Problem
Statement
– interviews, questionnaires, observation, document
analysis
• Functional Requirements modelled through
Data -Flow Diagrams
• Data requirements through EntityRelationship Models
Supplement 02 (b)
User Requirements
4
Traditional “life-cycle” model of
software development
Requirements Gathering
Requirements Specification
Design
Implementation
Maintenance
Supplement 02 (b)
User Requirements
5
A User- centered approach to
software development
Task analysis/
functional analysis
Implementation
Prototyping
Star Model (Hartson & Hix)
Supplement 02 (b)
Evaluation
Requirements
specification
Conceptual design/
Formal design
User Requirements
6
User-Centered Approach
• Analyst can additionally use cognitive and
other task analysis techniques
• Prototyping and Requirements animation can
be used to facilitate requirements gathering
• Object Technology has added Object/Class
modelling and Use Cases to the toolkit
• These techniques facilitate an approach
which engages users throughout the lifecycle
Supplement 02 (b)
User Requirements
7
Usability Requirements
• Core requirements are viewed as “black box”
functions plus key non-functional
requirements (e.g., speed of response etc.)
• Usability requirements are often overlooked
usability = “Any system designed for people to use should be easy
to learn (and remember), useful, that is contains functions people
really need in their work, and be easy and pleasant to
use”(Gould and Lewis, 1985)
Supplement 02 (b)
User Requirements
8
Components of Usability
• Learnability
– time and effort required to reach a specified level
of performance
• Throughput
– tasks accomplished by experienced users, speed,
number of errors etc.
• Flexibility
– system’s ability to respond to change
• Attitude
– positive feelings of users to the system
Supplement 02 (b)
User Requirements
9
Components of a Usability
Study
• A Usability Study gathers Usability
Requirements alongside functional, data
specs. etc. and can involve
– Usability Models
– Usability Metrics
– Usability Specifications
Supplement 02 (b)
User Requirements
10
Task analysis
• Describes behavior at 3 levels
– goals, tasks and actions
• Tasks are usually viewed in terms of tasks and subtasks
• Hierarchical Task Analysis (HTA) focuses on what
actually happens in terms of tasks and subtasks
• Cognitive task analysis focuses on aspects of the
cognitive characteristics of the users’ work
Supplement 02 (b)
User Requirements
11
Goal-Task-Action
• Goal (a.k.a. “external task”)
– the state of the system the user wishes to achieve
– e.g, produce a spreadsheet report, calculate
payroll figures etc.,
• Task (a.k.a. “internal task”)
– activities thought to be necessary to achieve the
goal
• Action
– a task that involves no problem solving, or control structure
Supplement 02 (b)
User Requirements
12
Hierarchical Task Analysis
• Aim is to describe a task in terms of a hierarchy
of operations and plans where
– operations = Goal-Task-Action
– plans = specification of conditions under which (sub)
tasks are carried out
• Can be captured graphically
– using a form of structure chart
Supplement 02 (b)
User Requirements
13
Partial HTA chart for Editing Text
in Windows
0. Edit Text
Plan 1: According to Requirements
1. Cut Text
1. Use Menu
option
2. Use Hot-key
Combo.
3. Use Toolbar
Icon
1. Select Text
2. Press Ctrl + X
4. Use Delete
Plan 1.2: 1,2
Supplement 02 (b)
User Requirements
14
Hierarchical Task Analysis
techniques
• Starting the analysis
– specify area of work or main task
– break down into 4 - 8 subtasks
– draw subtasks out into layered plans
• Progressing the analysis
– determine “granularity” of analysis
– choose depth-first or breadth-first
– document (notation in Preece p.415)
• Finalizing the analysis
– check for consistency, integrity
– present to external “task expert” for confirmation
Supplement 02 (b)
User Requirements
15
b. User Requirements
We start with nothing!
• At first we know nothing of what users want
• … and maybe little about the organisation.
• This may be:
–
–
–
–
–
a manufacturing business
a supermarket chain
a software house
a government department
an electricity generating company
Supplement 02 (b)
User Requirements
16
User Requirements–
We start with nothing!
• Within the organisation, the problem
domain may be:
–
–
–
–
–
real-time—e.g. industrial process control
transaction processing—e.g. customer orders
safety-critical—e.g. air traffic control
communications—e.g. with sales reps
database—e.g. personnel records
Supplement 02 (b)
User Requirements
17
User Requirements–
We start with nothing!
• Users work in widely differing contexts and
organisations
• Their need for information and computer
support also varies tremendously
• We must begin by finding out about:
– their circumstances
– their problems
– what they want
Supplement 02 (b)
User Requirements
18
User Requirements–
What do we need to achieve?
• The goal is simple: to learn enough to
develop a computerised IS that will be
useful to:
– these specific users, in...
– these particular circumstances, with...
– these unique problems
• We must also document what we learn,
so others can access our knowledge
Supplement 02 (b)
User Requirements
19
User Requirements–
What is important?
• What matters depends on the problem
domain:
– for control systems, process and timing
matter
– for record-keeping systems, data matters
– for financial system, security matters
• Note these are not mutually exclusive
• It’s more a matter of emphasis
Supplement 02 (b)
User Requirements
20
User Requirements–
What is important?
• Let’s consider a few examples.
– Real-time: a car cruise control system
– Safety-critical: an air traffic control system
– Transaction processing: a travel agency
booking system
Supplement 02 (b)
User Requirements
21
User Requirements for a car
cruise control system
• What would we
need to know to
develop a car
cruise control
system?
Supplement 02 (b)
User Requirements
22
User Requirements for a car
cruise control system
• We will need to
know about:
– how engine
components work
– engine fuel demand
– vehicle electronics interface standards
– driver ergonomics (to design the controls)
– timing and synchronisation information
Supplement 02 (b)
User Requirements
23
User Requirements for an air
traffic control system
• What would we
need to know to
develop an air
traffic control
system?
Supplement 02 (b)
User Requirements
24
User Requirements for an air
traffic control system
• Clearly different from car cruise control. We
need to know:
–
–
–
–
–
–
number of flights and aircraft handled
aircraft navigation / instrument landing systems
throughput of stacks and queues
priority of different types of aircraft
user characteristics and environment
emergency routines
Supplement 02 (b)
User Requirements
25
Cruise control and air traffic
control systems compared
• Similarities:
– Timing and synchronisation are important
– Safety issues are important
• Contrasts: for air traffic control...
– Much more data is required for system running
– Relationships among data matters
– User issues are much more important
Supplement 02 (b)
User Requirements
26
User Requirements for a travel
agency booking system
• What would we
need to know to
develop a travel
agency booking
system?
Supplement 02 (b)
User Requirements
27
User Requirements for a travel
agency booking system
• Clearly different again. We need to know
about:
– holiday and travel operators
– current prices and discounts
– destinations
– network characteristics
– journeys
– customer characteristics
– user characteristics
Supplement 02 (b)
User Requirements
28
Travel agency bookings and air
traffic control compared
• Some similarities:
– Data / relationships among data important
– Response time an issue (but not milliseconds!)
• Contrasts: for travel agency bookings...
–
–
–
–
No significant safety issues
Remote network access vital
Non-technical users
Customer issues?—E.g. multimedia interface?
Supplement 02 (b)
User Requirements
29
User Requirements–
What abstractions can we use?
• Which abstractions are useful depends on the
type of information that matters.
• We may need to capture details of:
–
–
–
–
Timings and sequence
Data (and relationships / structure of data)
Processes
Other aspects, e.g. users issues and safety factors
Supplement 02 (b)
User Requirements
30
Modelling Requirements
for Air Traffic Control
• Has both Real-Time Process Control and TPS
Aspects
1.
2.
3.
4.
5.
Number of flights and aircraft handled
Aircraft navigation / instrument landing systems
Throughput of stacks and queues
Priority of different types of aircraft
Emergency routines
• For each of the above requirements state the relative importance of
modelling Data, Process & Time and suggest suitable models to be
developed.
Supplement 02 (b)
User Requirements
31
SUMMARY
Establishing User Requirements
• At the start we know nothing at all
• By the end of this stage we have:
– Decided (more or less) what matters
– Found out what users want
– Recorded all this in an appropriate way
• Utilise Rich Pictures
Supplement 02 (b)
User Requirements
32