Requirements
Engineering
Southern Methodist University
CSE 7316
1
Module 4 Understanding
the problem domain
2
Requirements and Design
Patterns
 Orderly engineering starts with some type
of design pattern
we know we want a bridge
 Rigorous research and definition of
requirements is possible only in relation
to a specific design pattern
what type of traffic to carry, auto and/or
pedestrians, etc
3
Requirements and Design
Patterns
 A ferry solution would pose an entirely
different set of questions
thats why you cannot get too detailed in
specifying what you want - you limit the
solution space
 Common complaint from customers,
programmers, testers, etc
“Requirements are so abstract that
nobody can understand them”
4
Requirements and Design
Patterns
 Corresponding to every design pattern is
a set of questions to ask about the
problem that the pattern solves. A
requirements document answers these
questions.
 Writing requirements answers a specific
set of questions
should be precise enough to allow the
engineer to apply the pattern to create a
new design
5
Software Problems
 All software problems are of this form:
“Configure machine M to produce effects R
in domain D.”
M = computer to be programmed
R = the requirements
D = part of the world in terms of which the
requirements are defined.
6
Software Problems
 Fundamental questions to answer when
writing software requirements;
what type of machine do you want
configured?
what effects do you want the
configuration to produce?
what are the properties of the outside
world that the machine can exploit to
produce those effects?
7
The information problem
 The task of the s/w developer is to
configure the computer into an
information system (combination of h/w
and s/w) to supply information about the
state of some part of the world
 Questions to answer;
1. what machine is to be configured to
act as the information server?
8
The information problem
2. what questions can the user ask of
the information system?
3. what part of the world do these
questions concern and what events
happen there?
4. how can the machine get access to
these events?
 (2) provides the requirements
 (3) and (4) provide info about the domain
 (1) usually fades into the background
9
Requirements Engineering
 Requirements are the desired effect
 Interfaces, program code, etc are the
means to bring it about
 Requirements engineering
the design of requirements
most critical part of many projects
the desired effects - someone has to
think of these desired effects
10
Requirements Engineering
 Software quality is not just meeting the
requirements
 Software fails many time because people
refused to buy or use the software
because
 the problem that it solved was of no
concern to them
they preferred to leave that problem
unsolved
 Requirements can be of low quality!
11
Requirements Engineering
 There are many ways of meeting
requirements
user interface solutions take on many
forms
 What makes requirements different from
design
defines a problem such that we can say
that the interfaces and program code
either solve it or fail to solve it
12
Requirements Engineering
 Inventing requirements is a matter of
inventing a well defined problem to solve
 Well-defined problem; a set of criteria
according to which proposed solutions
either definitely solve the problem or
definitely fail to solve it, along with any
ancillary information, such as which
materials are available to solve the
problem.
13
Requirements Engineering
 Must design against an open-ended
problem
 Open-ended problem; a situation in which
we believe that some improvement is
possible, but we have no definite criteria
for measuring improvement. Discovering
new criteria is, itself, part of the problem.
14
Requirements Engineering
 Options to building a bridge
dig a tunnel
widen existing roads
narrow existing roads (people stop
driving and move closer -> culture
changes….)
 What is the requirement? to make traffic
move faster? to get people to work
faster?
15
Requirements Engineering
 All engineering begins with open-ended
problems
no requirements - just the belief that
improvement is possible
 Two common mistakes
settling on strict evaluation criteria too
early
writing requirements so vaguely that
they don’t define any requirements at all
16
Requirements Engineering
 Requirements engineering starts with an
open-ended problem and finish with a
well-defined problem
 If you haven’t made the decision to write
software, you are not ready to hand the
problem off to software engineers -> you
are still doing requirements
17
Summary
 Generalized problem solving methods
don’t work , at least not well enough to
base a method of requirements-writing on
them
 Do not try to document an entire openended problem in a requirements
document
18
Summary
 Tailor the information in requirements
documents to specific kinds of software
and specific known design patterns and
programming techniques
 Provide information about specific events
in domain D
19
The Problem Domain
20
The Problem Domain
 Requirements define the problem to be
solved by the software; they do not
describe the software that solves it
customers rarely specify software
behavior
more interested in problem domain
 Problem domain; part of the world where
the computer is to produce desired
effects; and the means to produce them
21
The Problem Domain
 Indirect means
users whom the computer can have do
tasks
motors that can be turned on and off
people or other machines to supply
information
 Direct means
behavior of I/O devices
keyboards
screens
printers
22
The Problem Domain
 Problem domain is not just the world
outside the computer
without knowledge of the I/O devices
the problem becomes abstract
sometimes the problem domain does
not exist outside the computer
word processor
CAD program
these programs create the problem domain
23
The Problem Domain
requirements are specifically for the I/O
devices to behave a certain way
24
Requirements
 Requirement; the effects that the
computer is to exert in the problem
domain, by virtue of the computer’s
programming
what the customer wants to achieve in
the problem domain
truck, cargo, driver, road are all objects
in a problem domain
25
Software Designs
 Three principle designs
design of the requirements
design of the interfaces that bring about
the requirements
design of the program that makes the
computer behave as specified by the
interface design
26
Problem domain
Machine domain
Pick up cargos
Two worlds
Database schemas
Haul cargos to
destinations
Linked lists
Print reports
Specification
Requirements
subroutines
interfaces
Three
designs
27
Program
Validation of Interfaces and
Programs
 It should always be possible to prove the
validity of the interface design on the
basis of the description of the problem
domain plus the requirements
28
Validation of an interface
design
 Premises:
the behavior described in the I/F design
occurs
the computers environment matches th
description of the problem domain
 Conclusion
the requirements are fulfilled
 If the conclusion does not follow from the
premises, the I/F design is invalid
29
Validation of a Program
 Premises;
the program consists of specified
instructions
the platform on which the program runs
possesses the specified library, OS,
H/W
 Conclusion
the behavior described in the I/F design
occurs
30
More simply put..
 A program is validated against a
specification
 A specification is validated against
requirements and the problem domain
 Therefore
without requirements there is no way to
validate a program design (to connect
the program to the customers desires)
31
Requirements
 Writing down requirements is a device to
help people work together on the same
project
 Requirements; designed in response to an
open-ended problem
 Interface design; derives from a well
defined problem (provided by
requirements)
32
Types of information in a
problem domain description
Information
Examples
Entities in the domain
and attributes
Trucks; manufacturer, maximum
cargo weight, maintenance records,
whether includes refrigeration
Hurricanes; name, location, shape,
direction of rotation, etc
Cardinalities of relations
between entities
For every customer, there can be
zero or more invoices; for every
invoice, there is exactly one
customer
Events that the entities
are capable of
Trucks move along roads, from city
to city. A new truck can be bought.
The company can sell or otherwise
retire a truck from service. A
hurricane can move, possibly
overlapping a city
33
Problem Domain
Description
 Software designers need knowledge of the
problem domain
requirements or descriptive statements
are not enough
well written requirements document
contain more information about the
problem domain than requirements
statements
 Requirements document must describe
the problem domain in sufficient detail
34
Evolving the requirements
 Impossible to write excellent requirements
at the beginning of a complex project
evolves from our knowledge of
interfaces and programming
incrementally developed software
 Two strategies
start with sketchy requirements and add
detail at each stage
spiral approach
35
NASA Space Program
 Strategy of rigorously solving a series of
progressively more complex problems
 Goal: Land a man on the moon and return
him safely to the earth
far too ambitious to attempt all at once
numerous complete spacecraft were
designed and launched for the purpose
of learning about various problems with
space flight
36
NASA Space Program
Project Mercury; solved problems of
orbital dynamics and human life
support in space
Project Gemini; solved problems of
extravehicular activity and space
docking
Project Apollo; solved the final
problems of landing a man on moon
and returning
 Each experience improved the
requirements for the next design
37
What software requirements
are not
 Not top-down
mainly concerned with the program and
not the problem domain
 Not sketches
may be too abstract - no well defined
problem
 Not what versus How
everything in engineering is what and
everything is how
38
39
Problem Framing
40
Knights Tour - Before
41
Knights Tour - After
42
Framing the Problem
 First step in documenting software
requirements is to frame the problem
definite form
definite parts
definite relations between the parts
 Makes the details fit into a systematic
framework to be analyzed without
becoming overwhelmed
43
Domains
Each domain contains a set of
individuals
distinguishable things about which
we want to make a statement
trucks, cargo, drivers, etc
the physical part of the world
subroutines, data structures, I/O
potential individuals; customers
Individuals are distinguishable from
each other
44
Separation into Domains
Machine domain
Problem domain
Pick up cargos
Haul cargos to
destinations
Database schemas
subroutines
interfaces
Linked lists
Print reports
Specification
Requirements
45
Program
Domains
Domains also contain everything we
want to say about the individuals
truck is now carrying the cargo
predicate; everything we want to
be able to assert or deny
one subroutine calls another
46
Domain Framing
Statements made about the problem
domain must address individuals
within the problem domain only
requirements documents address
issues in the problem domain
cannot address issues in the
machine domain
47
Types of Domain Information
 What types of entities can be in the
domain?
 What attributes should those entities
have?
 Relationships between entities
 Types of events that can occur in the
domain
 The causal law according to which the
entities behave
motor A is on iff bit 7 of I/O port is
high...
48
Types of Domain
Information
Events treated as individuals
attributes are entities that
participated in the event
relations are things like before and
after
Information then incorporated into
propositions; assertions or denials
that certain individuals possess
certain attributes or bear certain
relations to each other
49
Mathematics
Individuals and predicates
relations between propositions
attributes
This is a form of predicate and
propositional calculus
Also a natural language form
The tricky part is to decide what
individuals to talk about and what
predicates to use
50
Shared Phenomena
Intersection between domains
required to allow one domain to exert
effects on another domain
states
events
objects
Many times these are described in an
interface document
51
Examples
 Keystrokes typed by a user are keystrokes
received by software
 Every pixel displayed on a monitor by
software is also a pixel seen by the user
 Signals sent by an oxygen sensor to a
microprocessor inside a car
 Employee punching a time clock is the
time clock recording the event
52
S/W Problem w/ 4 domains
Weather stations
A/D
converter
Serial I/F
The
computer
The weather
temperatures
Temperature
sensor
program
Users
53
User I/F
Researchers
Connection Domains
 A domain that shares phenomena with two
domains that we wish had a direct
connection, but don’t
 Put an upper limit on how well you can
fulfill the requirements
 Introduces some form of distortion and
delay which may impact the users of the
software
54
Connection Domains
 Customer must be informed about the
limitations with these connection domains
must invent desired results
design software accordingly
55
Realized Domains
 Nearly any type of commitment between
people, if a computer is to manage it, must
appear as a realized domain in a
requirements document
debts
accounts
responsibilities to perform tasks
scheduled times to meet
 Just reporting on these is different!
56
Frame Diagrams
 Rectangles are domains
 Lines connecting domains represent
shared phenomena
 Double border rectangle is the machine to
be programmed
name in the double lined rectangle is
the type of system this is to become
57
Frame Diagram for the
Temperature Information
System
temperatures
weather
stations
information
system
researchers
58
Big Dot indicates that one
domain is wholly contained
in another
word
processor
documents
59
Big Dot
drivers
trucks
truck
driving
events
locations
60
cargoes
Adding the Requirements
 Have M and D
 Need R
 These are ovals
assert relations within a domain
relations between domains
short description added inside oval
arrows from the ovals to domains
indicate the requirements apply to
those domains
61
Complete Frame Diagram
temperatures
weather
stations
queries
information
system
researchers
62
Frame Diagram for ImageProcessing Software
image
processing
algorithm
input image
filter
63
output
image
Reading a Frame Diagram
 1. Read the oval and notice which
domains it relates
these are the primary domains of
interest
problem, in most fundamental form, is
to create this relation between domains
in order to enable users to make queries
about temperatures or create output
images
64
Reading a Frame Diagram
2. Find the machine domain and see
how it directly or indirectly connects
to the domains of interest
do any connection domains
complicate the problem
Frame diagrams are the first step
towards writing a requirements
document
May be included in a requirements
document
65
From Diagram to
Documentation
 A list of all the queries that users can
initiate
 Description of the temperatures
 Description of how the weather station
interacts with temperature
 Description of how the weather station
interacts with the computer
 Description of the connection between the
researchers and the computer
 Description of the researchers
66
What a Frame Diagram is
NOT
 It is not an outline of the program
structure
 It is not a description of the behavior rules
that make up the specification
 It is only a graphical overview of the
software problem, not its solution
 Framing the problem is preparing the
development staff to apply design
patterns that they know
67
Types of Problem Frames
68
Types of Problem Frames
Requirement type
Description
Queries
Behavioral Rules
Requests for information
Rules according to which
the problem domain is to
behave
Mappings
Mappings between data
input and output
Operations on realized
Operations that users can
Domains
perform on objects that
exist inside the software
Correspondences between Keeping domains that
domains
have no shared
phenomena in
corresponding states
69
Problem Frame
Information
Control
Transformation
Workpiece
Connection
Problem Frames
 Describe very large scale software
patterns
describe a specific kind of problem
not an exhaustive list
many problems are multi-frame
problems
goal is to recognize familiar problems
when you see them
70
Information Problems
 Answers queries about a certain part of
the real world
 Types of information requests to be
satisfied
 How the software can get access to that
part of the real world
71
Information Problem
real
world
queries
information
system
information
requesters
72
Information Problems
 Documenting requirements
relevant part of the world
queries
people or things that initiate the queries
 Requirement is to satisfy queries initiated
by information requestors
 System reports on the state of the world
but does not change its state (no
causation)
73
Example Software
 Inventory control system
 Program to search texts for sequences
 Web search engine
 API that returns status of graphics adaptor
 Electronic thesaurus
 Library catalog system
74
Connection domain
 Computers are not psychic
nearly all information problems required
some sort of a connection domain
relays information from the real world to the
software
common example - people performing data
entry
75
Information Problem Including a
Typical Connection Domain
queries
real
world
data
entry
staff
information
requesters
76
information
system
Static and Dynamic
 Dynamic systems; reporting on
information that is always changing
information builds up while system in
operation
must document how to get access to
the info
 Static systems; things not changing
interaction properties of drugs
all available information built in
how can software developers get info
77
Passive and Active
 Passive; queries initiated by user
 Active; supplies info without being asked
burglar alarm
inventory running low
notifications; require more
documentation
what triggers the notification?
what kind of response time?
knowing that information was received
78
Solving an information
problem
 Model the real world inside the computer
bits change state following rules that
map them to an activity in the real world
behaves analogous to the real world
answer questions directly instead of
contacting the real world
new shipment of sweaters cause qty_in_stk
field to be updated w/o having to contact
real world
specification must describe the model
79
Other Considerations
 Document each event response
 Static systems must document how the
info gets into the system in the first place
 If problem domain changes, how is the
model updated
 Validation rules to counteract the
distortion in the connection domain
 All screens in the application
80
Control Problem
 Software responsible for ensuring that
some part of the real world behaves in
accordance with specified rules
 Describe the objects that inhabit that part
of the world that the rules they obey
 How the software will monitor that part of
the world and initiate causal chains that
cause the rules to behave
81
Control Problem
queries
controller
controlled
domain
82
Control Problems
 Focus exclusively on causation (making
part of the world behave in accordance
with specified rules)
 Things to describe in this type of problem
causal properties of relevant parts of
the world
rules that the objects follow by nature
rules we would like them to follow -rqmt
phenomena shared between computer
and problem domain
83
Control Problem Examples
 Heating control system
fans, furnaces, A/C on/off to make best
compromise
 Traffic light controller
timing rules, activity at sensors, timing
relationships with other lights
 Telephone switch software
directs switches to incoming calls to
wires that lead directly to phones,
parses rules and touch tones, connects
phones
84
Connection Domains
 Common problem is directing people to
perform certain types of activities
users are a connection domain (may or
may not do what is instructed or enter
wrong data)
move inventory
new orders received
delay between data entry and actual
unique numbers to reduce redundancy
85
Connection Domain in a Control
Problem
business
rules
warehouse
employees
orders
86
inventory
control
system
Solving a Control Problem
 Specification for this problem describes
behavior rules for the shared phenomena
 Timing rules must be documented
 Postulate a set of states the software
takes on
map every possible input to a response
in the problem domain and the next
state
87
Transformation Problem
 Software generated output data that maps
to input data in accordance with specified
rules
 Describe the entire set of all possible
inputs and the mapping rules that
indicate, for each possible input, the
correct output
88
Transformation Problem
mapping
input
data
filter
89
output
data
Transformation Problem
 Input data and output data are elements
from two sets
 Documentation consists of
set of all possible inputs
set of all possible outputs
rule relating each possible input to its
corresponding output
 This mapping is the only requirement
90
Two sets
a
B
A
b
d
c
w
x
y
z
x
A x B = {< a,b > | a  A and b B} and contains pairs < a,x >, < a,y >, < a,z >, < b,w>, < b,x >, <
b,y>, < b,z >, < c,w>, < c,x >, < c,y>, < c,z >, < d,w>, < d,x >, < d,y>, < d,z >, < x,w>, < x,x >, < x,y
>, and < x,z >.
91
A relation between two sets
B
A
b
d
a
w
x
c
y
x
92
z
A relation between two sets
that qualifies as a function
B
A
b
x
d
a
w
c
y
x
93
z
A complete function
B
A
b
x
d
a
w
c
y
x
94
z
Specifying a system
If the systems planners and customer do not specify
what is expected in all types of interactions with the
system, i.e. the behavior of the system, someone else will.
That someone else is most likely the programmer when he
or she is coding the ELSE option of some IF statement.
There is a very low probability that the programmer’s
guesses as to the expected behavior will be what the
customer expects.
-- James Kowal, “Behavior Models: Specifying User’s
Expectations”
95
The software system viewed
as a function
CO-DOMAIN
DOMAIN
RANGE
a
b
c
d
e
f
g
h
X
software
system
Y
Z
FUNCTION f(n)
Q
96
Examples of Transformation
Problems
 Subroutine that translates bar codes into
numbers
 Image processing S/W that removes dust
and scratches from digitized photos
 Program to generate weather maps from
meteorological data
 Printer driver that converts commands
from the OS to equivalent commands to
control a printer
97
Solving a Transformation
problem
 Mainly programming
 No interface design work
 Specification only needs to add a GUI or
API
98
Workpiece Problem
 Software serves as a tool for creating
objects that exist only with the software
 Describe the objects to exist within the
computer and the operations that users
can perform on them
99
Workpiece Problem
operations
users
tool
100
workpiece
Workpiece Problem
 Software helps users create objects
documents
designs
 Work pieces are intangible and exist in a
realized domain
 Software may generate tangible versions
printed copy
101
Example Workpiece
Problems
 Word processor
 Program to create business graphics
 Music editor
 Program to generate composite sketches
of police suspects
 A recipe file
102
Solving a Workpiece
Problem
 Majority is user-interface design
 Rest is programming
representing workpieces
performing operations on objects being
created
103
Connection Problem
 Software must simulate or make do with a
connection between domains that do not
really share phenomena
 Describe the delay and distortion
characteristics of the connection domain
and the behavioral characteristics of the
domain of interest
allows the system to detect invalid data
104
Connection Problem
achievable
correspondence
system
connection
domain
105
domain
of
interest
Connection Problems
 Problem is to make two indirectly
connected domains behave as if they were
directly connected
system can make do with a connection
domain
system is the connection domain
 Perfect correspondence hard to achieve
 Usually part of a larger problem
106
Connection Problem
Examples
 Data entry staff
 Data warehouse answering queries
overlapping parts of the real world
 Error-free data transfer across a noisy line
 Video conferencing
107
Issues to consider
 Must document how the system will be
able to determine if the connection
domain is not functioning properly
 Mistake theory is used for user interface
designers
does not belong in a requirements
document
 Requirements document must contain as
much information as possible about the
domain of interest
108
Making do with an Indirect
Connection
achievable
correspondence
system
connection
domain
109
domain
of
interest
Creating an Indirect
Connection
achievable
correspondence
system A
comm
system
110
system B
Multiple Connections to the same
domain of interest
queries
domain
of
interest
database A
database B
database C
users
111
information
system
Creating a Connection Across a
Communication Medium
achievable
correspondence
system A
comm
system
comm
medium
112
comm
system
system B
Solving a Connection
Problem
 Primarily create redundancy in the
problem domain
peoples names don’t contain control
characters
atmospheric conditions don’t change
faster than one degree per second
 Guesses can be made at delayed data
 Modems exploit redundancy in the English
language (sent faster than programs)
113
User and Task Analysis
114
Topics
 Introduction to user and task analysis
 Thinking about the users
 Thinking about tasks
 Thinking about the users environment
115
What makes a product
usable?
 They reflect the workflows that are familiar or
comfortable
 They support the users learning styles
 They are compatible in the users working
environments
 They encompass a design concept that is familiar
to the users
 They have a consistency of presentation
116
Understanding how the user
performs the task
 What the users goals are; what they are trying to
achieve
 What users actually do to achieve those goals
 What personal, social, and cultural
characteristics the users bring to the tasks
 How users are influenced by their physical
environment
117
Understanding how the user
performs the task
• How users previous knowledge and
experience influence how they think
about their work and the workflow
they follow to perform their tasks
• What users value most that will make
a new interface be a delight for them
(speed? accuracy? help in
recovering from errors? human
contact? fun? challenge?)
118
Why isn’t this done already?
 Marketing knows the users
 The product is new - there aren’t any users to
observe
 The users are all too different - we can’t possible
visit all of them
 We don’t have enough time in the schedule
 We don’t have enough money in the budget
119
Where does user and task
analysis come from?
 Anthropology
 the study of people
 Ethnography
 practice of immersing oneself in a culture in
order to describe that culture
 Cognitive psychology
 study of how people think and learn
 Rhetoric
 communicating with others through mediums
120
Focusing on users
 How do they think about their relationship
to their work?
 Is what you are developing related to their
primary work or something they will use
occasionally?
 What and how much do they know about
the subject matter you are designing for?
121
Focusing on users
• What tools do they know how to
use?
• What motivates them in doing their
job?
• What motivates them in using their
personal time at home?
• What technical skills do they bring to
performing their work?
• What languages are they comfortable
122
using?
Users that must be studied
 Individuals who buy the software and use it
without assistance or interaction from others
 Individuals who use the interface and information
as part of their work, even though they did not
buy the software
 Groups of people who use the software and
information as part of a larger business process
 Those who administer the software
123
Users that must be studied
 Individuals who repair products that are broken
or who troubleshoot systems
 Those that install products for themselves and
other and may also use the software
 Customers of the users and others who are
affected by users working with the interface
124
Starting a user and task
analysis
 Assemble a group of people in your
organization who regularly interact with
the users
customer service
training
marketing
 Brainstorm a preliminary list of users and
potential users
125
Starting a user and task
analysis
• Create a user/task matrix or a
user/characteristic matrix to serve as
an initial model of your community of
users
• Discuss the characteristics that you
assume are typical of your user
community
• Decide how to test your assumption
126
Assemble a user profile
team
 Salespeople who call or visit buyers and users
 Sales engineering people who install or
customize products at user sites
 Marketing professionals will have conducted
research studies
 Trainers who work with users in classroom
settings
 Telephone support personnel
127
Assemble a user profile
team
 Field support personnel
 Consultants who study and advise on
interactions with user communities
 Former users who now work in your
organization
128
Brainstorm a list if users







experience on the job
education level
background of training
age, gender, physical differences
geographic locations, wage differences
language skills, terminology differences
job level
129
Create an initial user/task
matrix
Tasks likely to be performed
Users
Patients
Patient
families
Novice
clinicians
Expert
clinicians
Getting
comfortable
with software
X
X
Basic
user
difference
X
X
Advanced
software use
Training
the
patients
X
X
X
X
X
X
X
130
Customizing
the software
X
Users and their jobs
 Do the users all have the same job title?
 Do the users have different job titles that reflect
wide differences in skills and responsibilities?
 Are the users professionals who have learned
aspects of their jobs in school?
 Do your users consider their jobs to define their
modes of behavior?
131
Issues to consider about tasks
 How did your users learn to perform the tasks
that they do?
 How long have they been doing these tasks?
 Have the tasks changed over time?
 Do the user perform many varied tasks in a
typical day?
 Do the users teach others to perform the same
tasks?
 Which people in the organization are considered
the experts?
132
Issues to consider about
tools
 What tools are the users using today to perform
their tasks?
 How did they learn to use these tools?
 How comfortable are they using the tools?
 Are the users familiar with technology that is
similar to your intended design?
 To what extent do their tools define that they do?
133
Mental models and
vocabulary
 Mental models are internal pictures of how
things work
a term from cognitive psychology
vague, amorphous, individual, and
changeable collection of associations in
peoples minds
 Users mental models will emerge through
conversations with them
134
Mental models and
vocabulary
 People use their mental models to make
associations between information (words,
pictures, sounds, smells) they are learning
and information they already know
135
Mental Models
 The picture of a trash can on a Mac is associated
with a physical trash can used to throw
something away (throwing away files)
 Designers also used trash can to eject a floppy
disk from the drive - this confused users who
thought that they would be “throwing away” the
information on the floppy!!
136
What is task analysis?
 Things related to goals and tasks
 “Things” are usually considered work
 admitting a patient to the hospital
 find a customers order in a database
 send a message to everybody on the project
team
 put up a new web site
 change payroll codes
 set up a new computer at home
137
Users goals
 Users goals inside a company
keeping my job
getting done so I can go home on time
Making the boss happy so I get a good
review
 Companies goals for users doing tasks
increasing revenue
increasing the number of applications
that get processed
decrease the cost of providing support
138
Norman’s seven stage cycle
 Forming the goal
 Forming the intention
 Specifying the action
 Executing the action
 Perceiving the state of the world
 Interpreting the state of the world
 Evaluating the outcome
139
Simple situation
 User forms goal
 User forms intention (decides
task)
 User specifies action(s)
 User does the action(s)
 User perceives the state of
the world
 User interprets the state of
the world
 User evaluates the outcome
140
 Go outside to get some fresh
air
 Open the door
 “It looks like I pull this handle
here”
 Pulls on the handle
 The door didn’t open
 “Well that didn’t work. I
guess I need to push it”
 Didn’t get outside yet. If the
user still wants to meet the
goal follow steps 3-7 again
this time pushing the door.
Different types and levels of
task analysis
 How work gets done when several people are
involved (workflow analysis)
 What a single individual does throughout the day
or week or month (job analysis)
 How workflow analysis interacts with job analysis
 The order in which users do tasks
 How a large task is made up of subtasks
141
Workflow analysis
 Understanding how a particular process is
accomplished if several people are
involved in completing the work (business
process analysis)
 Many companies are trying to simplify
business processes
 Look for redundancies or unnecessary
steps
142
Filling a prescription
 At least two people involved
 patient
 pharmacist
 Others may be involved
 relative or friend
 caregiver
 clerk or assistant
 receptionist at doctors office
 doctor
143
Filling a prescription







Patient contacts the pharmacy
Pharmacist or clerk takes the information
Pharmacist looks up the patients prescription
Pharmacist call the doctor for approval
Receptionist send the call to the doctor
Pharmacist waits for the call back
After the call back the prescrition is filled
144
Workflow analysis
 Workflow analysis is an important part of task
analysis because the situation in which different
types of people are involved in the process is
much more common than processes individuals
do alone
 If a task analysis is done by only looking at one
part of the workflow the risk is that the product
will not be used because it is in compatible with
the rest of the workflow
145
Job analysis
 Understanding all the work that a person does in
a certain position during the day, week, or month
 Workflow analysis is a horizontal picture of how
work moves across people
 Job analysis is a vertical picture of all the types
of work that flow through a person
146
Job analysis
 Benefits
find new marketing and development
opportunities
understand specific features to build into
the product
learn what pressures they are under and
what they value
147
Factors in job analysis





Frequency (how often tasks are performed)
Criticality (how important is each task)
Time to complete (how time consuming)
Difficulty (problems accomplishing tasks)
Division of responsibility (do all the people in that
job do this task?)
148
Developing a task list
 A task is any observable, measurable action that
has an observable beginning and an observable
end.
 Task list for an e-mail program
 write a message
 send a message
 receive a message
 read a message that you received
 reply to a message
 save a message to look at it late
 forward a message
 send a formatted file with the message
149
Process analysis, task
sequences
 In an e-mail program these sets of tasks have a
natural sequence
 write a message
comes before
 send a message
 Receive a message from someone else
 reply to a message or
 forward a message to someone else
150
Task Hierarchies
Job
Task
Subtask
Task
Subtask
Task
Task
Subtask
Task analysis is hierarchical. You can break up a job into
tasks and each task into subtasks
151
Procedural analysis
Job
Start
You can carry a task
analysis down to the
individual steps and
decisions users make
as they carry out the
task
Action (step)
Decision
Action (step)
Action (step)
152
End
Action (step)
Other path
Example task analysis
User is using prior
experience; says other
machine worked from
buttons
TV is off. VCR is off. TV and VCR
are set up and connected. No
cable box
User looks for buttons on front of
machine. Gets down on knees to do
this
Are most VCRs kept
this close to the floor?
Note that the user has tried
to solve the problem by trial
and error, has not yet gone
to the manuel.
Takes off bifocals to see better.
Complains that buttons are small
and black on black
Opens front panel, reads labels,
says “Nothing here is relevant”
153
The light i this living
room is too dim to see
the TV. Are most VCRs
used in dim lighting?
Ask about how he
typically uses a
manual
Inference: he jumped
directly to a page part
way through the manual
because he just wants to
get the task done, not
learn anything more about
the VCR
Decides to use the manual. Says
he can’t possibly read the whole
thing
Looks in table of contents. Finds
section for setting the timer. Turns
to that page. Reads that he must get
a menu up on the screen
Puts manual down. Picks up 2
remotes. Turns on TV with 1
remote. Turns on VCR with other.
Picks up manual again. Reads
“Press program button on remote
control. Does that
154
It’s hard to hold a
manual open and operate
two remote controls at the
same time
Types of users
 Any particular user at any particular
moment in time with any particular
product is at one of the four stages of use
novice
advanced beginner
competent performer
expert
155
Characteristics of novice
users
 Fear of failure, fear of the unknown
 Focus on accomplishing real work
 Impatient with learning concepts rather
than performing tasks
 Theoretical understanding only - no
practical experience
156
Characteristics of advanced
beginners
 Focus on accomplishing real work
 Impatient with learning concepts rather
than performing tasks
 Randomly access tasks
 By adding new and progressively more
complicated tasks, begin to develop an
empirically based mental model
157
Characteristics of
competent performers
 Focus on performing more complex tasks that
require many coordinated actions
 Ability to plan how to perform a complex series of
tasks to achieve a goal
 Willingness to learn how tasks fit into a
consistent mental model of the interface as a
whole
158
Characteristics of
competent performers
 Interest in solving simple problems by
applying a conceptual framework to
diagnose and correct errors
159
Characteristics of expert
performers
 Focus on developing a comprehensive and
consistent mental model of the product
functionality and the interface
 Ability to understand complex problems and find
solutions
 Interest in learning about concepts and theories
behind a product’s design and use
 Interest in interacting with other expert users
160
Thinking about the users’
environment
161
Why is environment
important?
 People do not perform their work in
isolation
 Influenced by the activity around them
physical characteristics of the
workplace
type of equipment being used
work relationships with other people
 Product must fit into environment or it will
be frustrating to use or be rejected
162
What aspects are
important?
 Physical environment
 light levels
 placement of controls
 amount of space to work in
 noisy or quiet
 dirt, dust, pollution
 temperature, humidity
 power availability
 dangers in the environment
163
Working at home?
 Users in an office
 will probably have a T1 line
 Users at home may
 have a slower modem
 may require different strategies for getting the
information they need
 may need a longer power cord
 automatic save feature (disruptions from kids)
164
Adequate space?
 “Standard” may not be so standard
 Is there room for a mouse or detached keyboard?
 Is there room for paper manuals or should on-line
help be used?
 Adequate space for optimal viewing angle?
 Bookcases in Japan are narrower then in US
 cubicle walls are rare
165
A noisy environment?
 Noisy environments make learning more difficult
 Sound cues (bells, beeps, etc) may distract coworkers
 Will they be able to hear the audio tones
 people with hearing aids have a hard time
hearing in the presence of background noise
166
Dirt, dust, and wind
 Will touch screen be usable if the screen
smears from oil?
 Working in a cleanroom may require no
paper (manuals) at all
 Dust can make computers unusable
 Wind can make the use of manuals and
paper almost unusable
maintenance technicians
167
Adequate lighting
 Can the user see the screen? The manuals? The
controls?
 Can they see the images in dim light?
 Will colors for warnings or cautions be
adequately visible on the screen?
 VCR black on black buttons hard to see
 probably designed in a bright lab
168
Temperature
 Extremes of temperature and elevation
disk drives have a hard time working at
high elevations because there is not
enough air to float the disk above the
read mechanism
 Cold temperatures make it difficult to use
controls
will users be wearing gloves?
 High temperature and humidity may fog
screens or make hands slip
169
How quickly must they
react?
 Users may be measured by how quickly
type can react (customers standing in line)
 Are they in any danger?
what happens when the users make
mistakes?
ATM machines are a focal point of
robberies
170
What aspects are
important?
• Social environment
– are tasks performed quickly and/or
accurately
– resources available to answer
questions
– do people who share info work in same
location
– social hierarchy in the organization
– how do physical and social
environments interact
171
– relationship between
users and
What aspects are
important?
• Cultural environment
– national cultural influences
– work in different cities, states, regions,
etc
– professional culture with particular
values
172
Making the business case
for site visits
173
Verifying your assumption
 Primary reason for traveling to user sites
is to challenge or verify your assumptions
 May meet with resistance to watching
users and listening to them
 The users doing the new process will be
the same users that did the old process!
 Very rare that a new product is so new that
there is nothing in existence to study
174
Preparing a business
proposal
 Analyze the return on investment
changes later are more expensive
 Meeting or exceeding the competition
are they doing usability studies
 Calculating the time required to conduct
an analysis
175
Preparing a business
proposal
Task
Brainstorming and initial
user/task matrix and
outlining the proposed site
Planning the site visit
Recruiting participants
Conducting six days of site
visits/two observers
Analysis and report
Total hours and labor costs
176
Hours per task
80
Labor cost per task
$5600
34
42
120
2380
2940
8400
80
356
5600
$24,920
Selecting Techniques
 Contextual inquiries; a philosophy as
much as a technique
Plan (understand the issues for the
visit)
Select the users to represent the right
diversity
Treat the users as a partner
Watch, listen and talk with users about
their work
Make the conversation concrete
Take your cues from the user (make
sure you are interpreting things
correctly)
177
Techniques
 Get the user to talk aloud while doing the
task
determine the users mental models
 Talk right after the task (if you can’t do it
during the task)
sometimes it is best to be a “fly on the
wall”
178
Techniques
 When to be unobtrusive;
the task involves helping another
person (call on the phone, etc)
the task involves safety (air traffic
controller)
the task requires a high degree of
concentration (solving complex
mathematical problems)
you are timing the task
the user is on a deadline (working under
pressure)
179
Role playing and staged
scenarios
 Not as credible as data collected under
actual circumstances (this was done for
the AA SABRE travel info Network)
 Must have relevant scenarios
 Advantage is that you can use the same
scenario at several sites and observe
different users handle the same scenario
180
Cue recall with videotapes
 Sometime, users do not want or do not
have the time to interview and talk but are
willing to be videotaped
 Questions can be answered later about
tasks that need more explanation or
interpretation
181
Doing a process analysis
 Interview and ask questions
 when does the first task in the process happen
 what triggers it
 who does it
 what information is required to do the task
 what are the major steps in the task
 who is the next person in the chain of the
process
 when does the next task happen
182
Ethnographic interviews
 “Top down” approach
 Start by getting a general framework from the
users
 Use that knowledge to structure and understand
future observation
 Contextual inquiry, on the other hand, is bottom
up (observing and gathering large samples of
work and then develop
183
Collecting artifacts
 Artifacts can be paper or screen shots
 “cheat sheets”
 forms that trigger data entry or the start of a
process
 forms and reports that get printed at various
times during a process
 examples of output from tasks
 hand-written notes or logs as reminders
184
Collecting stories
 Gather stories of real situations
 “critical-incident technique” - a way to
gather stories in a short period of time
ask each interviewee to recall a specific
critical incident
then probe for more information about it
questions are planned in advance
iterate
can be used as a base for scenariobased design
185
Working with users away
from the work site
 Sometimes it is hard to go to the users site
 security reasons
 equipment that is not portable to the users site
 Usability lab
 Conference room
 Ask the users to bring example of real work
186
Market research techniques
 Meet with users in focus groups
 facilitator skilled in asking questions, getting
opinions, etc
 focus groups don’t show behavior
 User surveys
 designed to gather information from a large
group of people (direct-mail questionnaires,
telephone survey, fax, web)
 Meeting users at trade shows
187
Other
 Bringing users to requirements-gathering
sessions
 focus on functionality rather than usability
 what users say may not be what they do
 users talk about the typical case
 what they need may not be the best way to
solve the problem
 group dynamics problems
 Including a user on the design team
188
Conclusion
 Requirements elicitation is a collaborative
decision-making activity involving users,
developers and customers
 Dependent on the diversity and experience of the
problem being formulated
 Techniques should be tailored to the project
189