requirements engineering southern methodist university cse 7316 – framing the problem

RequirementsEngineering

Southern Methodist University

CSE 7316 – Framing the Problem

Understanding the problem domain

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

Requirements and Design Patterns A ferry solution would pose an entirely

different set of questions That’s 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”

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

Software Problems All software problems are of this form:

“Configure machine M to produce effects R in domain D.”

M = computer to be programmedR = the requirementsD = part of the world in terms of which the

requirements are defined.

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?

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?

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

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


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!


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


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.


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.


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?


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


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

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 open-ended problem in a requirements document

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

The Problem Domain

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

The Problem Domain Indirect means

users whom the computer can do tasks with 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

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

The Problem Domain

requirements are specifically for the I/O devices to behave a certain way

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

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

Pick up cargos

Haul cargos todestinations

Print reports

interfaces

Database schemas

subroutines

Linked lists

Machine domainProblem domain Two worlds

Three designsRequirements

Specification 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

Validation of an interface design Premises:

the behavior described in the I/F design occurs the computers environment matches the

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

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

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)

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)

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 refrigerationHurricanes; 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

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

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

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

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

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

Problem Framing

Knights Tour - Before

Knights Tour - After

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

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

Separation into Domains

Pick up cargos

Haul cargos todestinations

Print reports

interfaces

Database schemas

subroutines

Linked lists

Machine domainProblem domain

Requirements

Specification 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

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

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...

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

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

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

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

S/W Problem w/ 4 domains

temperatures

Weather stations

Thecomputer

Researchers

The weather

Temperaturesensor

A/Dconverter

Serial I/F

program

User I/FUsers

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

Connection Domains

Customer must be informed about the limitations with these connection domains must invent desired results design software accordingly

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!

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

Frame Diagram for the Temperature Information System

temperatures

researchers

weatherstations

informationsystem

Big Dot indicates that one domain is wholly contained in another

wordprocessor

documents

Big Dot

trucks

drivers

truckdrivingevents

locations

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

Complete Frame Diagram

temperatures

researchers

weatherstations

informationsystem

queries

Frame Diagram for Image-Processing Software

input imageoutputimagefilter

imageprocessingalgorithm

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

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

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

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

Types of Problem Frames

Types of Problem Frames

Requirement type Description Problem FrameQueries Requests for information InformationBehavioral Rules Rules according to which

the problem domain is tobehave

Control

Mappings Mappings between datainput and output

Transformation

Operations on realizedDomains

Operations that users canperform on objects thatexist inside the software

Workpiece

Correspondences betweendomains

Keeping domains thathave no sharedphenomena incorresponding states

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

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

Information Problem

realworld

informationrequesters

informationsystem

queries

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)

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

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

Information Problem Including a Typical Connection Domain

realworld

informationrequesters

informationsystem

queriesdataentrystaff

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

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

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

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

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 where the rules apply

How the software will monitor that part of the world and initiate causal chains that cause objects to behave based on the rules

Control Problem

controlleddomain

controller

queries

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

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

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

Connection Domain in a Control Problem

inventorycontrolsystem

businessrules employees

warehouse

orders

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

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


inputdata

outputdatafilter

mapping


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

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

Solving a Transformation problem Mainly programming No interface design work Specification only needs to add a GUI or API

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

Workpiece Problem

users workpiecetool

operations

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

Example Workpiece Problems Word processor Program to create business graphics Music editor Program to generate composite sketches of

police suspects A recipe file

Solving a Workpiece Problem

Majority is user-interface design Rest is programming

representing workpieces performing operations on objects being created

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

Connection Problem

connectiondomain

domainof

interest

system

achievablecorrespondence

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

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

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

Making do with an Indirect Connection

connectiondomain

domainof

interest

system


Creating an Indirect Connection

system Bsystem A


commsystem

Multiple Connections to the same domain of interest

domainof

interest

users

informationsystem

queries

database A

database B

database C

Creating a Connection Across a Communication Medium

system A


commsystem

system Bcommsystem

commmedium

Solving a Connection Problem Primarily create redundancy in the

problem domain people’s 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)

User and Task Analysis

Topics

Introduction to user and task analysis Thinking about the users Thinking about tasks Thinking about the users environment

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

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

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?)

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

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

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?

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 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

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

Users that must be studied

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

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

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

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

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

Create an initial user/task matrix

Tasks likely to be performedUsers Getting

comfortablewith software

Basicuserdifference

Advancedsoftware use

Trainingthepatients

Customizingthe software

Patients X XPatientfamilies

X X X

Noviceclinicians

X X X

Expertclinicians

X X X 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?

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?

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?

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

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

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!!

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

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

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

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

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

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

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

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

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

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

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

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?)

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

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

Task Hierarchies

Job

Task Task Task Task

Subtask Subtask Subtask

Task analysis is hierarchical. You can break up a job intotasks and each task into subtasks

Procedural analysisJob

Start

Action (step)

Decision

Action (step)

Action (step)

Action (step)

End

Other path

You can carry a taskanalysis down to theindividual steps anddecisions users makeas they carry out thetask

Example task analysisTV is off. VCR is off. TV and VCRare set up and connected. Nocable box

User looks for buttons on front ofmachine. Gets down on knees to dothis

User is using priorexperience; says othermachine worked frombuttons

Are most VCRs keptthis close to the floor? Takes off bifocals to see better.

Complains that buttons are smalland black on black

The light i this livingroom is too dim to seethe TV. Are most VCRsused in dim lighting?

Opens front panel, reads labels,says “Nothing here is relevant”

Note that the user has triedto solve the problem by trialand error, has not yet goneto the manuel.

Decides to use the manual. Sayshe can’t possibly read the wholething

Looks in table of contents. Findssection for setting the timer. Turnsto that page. Reads that he must geta menu up on the screen

Puts manual down. Picks up 2remotes. Turns on TV with 1 remote. Turns on VCR with other.

Picks up manual again. Reads “Press program button on remotecontrol. Does that

Ask about how hetypically uses a manual

Inference: he jumpeddirectly to a page partway through the manualbecause he just wants toget the task done, notlearn anything more aboutthe VCR

It’s hard to hold a manual open and operatetwo remote controls at thesame 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

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

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

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

Characteristics of competent performers Interest in solving simple problems by

applying a conceptual framework to diagnose and correct errors

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

Thinking about the users’ environment

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

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

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)

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

A noisy environment?

Noisy environments make learning more difficult Sound cues (bells, beeps, etc) may distract co-

workers Will they be able to hear the audio tones

people with hearing aids have a hard time hearing in the presence of background noise

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

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

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

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


• 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– relationship between users and

customers


• Cultural environment– national cultural influences– work in different cities, states, regions,

etc– professional culture with particular

values

Making the business case for site visits

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

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

Preparing a business proposal

Task Hours per task Labor cost per taskBrainstorming and initialuser/task matrix andoutlining the proposed site

80 $5600

Planning the site visit 34 2380Recruiting participants 42 2940Conducting six days of sitevisits/two observers

120 8400

Analysis and report 80 5600Total hours and labor costs 356 $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)

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”

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)

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

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

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

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

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

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 scenario-based

design

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

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

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

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

requirements engineering southern methodist university cse 7316 – framing the problem

Documents