Chap6EstablishRequire-Latest

(1)

Chapter 6: Establishing

requirement

1

Data gathering process

http://www.youtube.com/watch?v=-WWjGPyiVf4

Man-Machine Nightmares: Chaos buttons, human error and healthcare

(2)

Overview

•

Data gathering for requirements

•

Data gathering guidelines

•

Data interpretation and presentation

•

Different types of requirements

(3)

What, how and why?

3

• _What

Two aims:

1. Understand as much as possible about users, task, context

2. Produce a stable set of requirements

• How:

Data gathering activities Data analysis activities

(4)

What, how and why?

•

Why:

Requirements

definition: the

stage where

failure occurs

most commonly

(5)

Volere shell

(6)

Volere requirements

template

(7)

(8)

Data gathering::Five key

issues

1.

Setting goals

 _{Decide how to analyze data once collected}

2.

Identifying participants

 _{Decide who to gather data from}

3.

Relationship with participants

 _{Clear and professional}

 _{Informed consent when appropriate}

4.

Triangulation

 _{Look at data from more than one perspective}

5.

Pilot studies

(9)

Observation

Direct observation in the field

◦ Structuring frameworks

◦ Degree of participation (insider or outsider)

◦ Ethnography

Direct observation in controlled environments Indirect observation: tracking users’ activities

◦ Diaries

(10)

Structuring frameworks to

guide observation

 - The person. Who?

- The place. Where? - The thing. What?

 The Goetz and LeCompte (1984) framework:

- Who is present? - What is their role? - What is happening?

- When does the activity occur? - Where is it happening?

- Why is it happening?

(11)

Direct observation in a controlled

environment

•

Think-aloud technique

•

Indirect observation

(12)

Data gathering for

requirements

Direct observation:

— Gain insights into stakeholders’ tasks — Good for understanding the nature and

context of the tasks

— But, it requires time and commitment

from a member of the design team, and it can result in a huge amount of data

Indirect observation:

(13)

Data gathering for

requirements

13

Studying documentation:

— Procedures and rules are often written down in manuals

— Good source of data about the steps involved in an activity, and any regulations governing a task

— Not to be used in isolation

— Good for understanding legislation, and getting background information

(14)

Choosing and combining techniques



Depends on

◦ The focus of the study

◦ The participants involved

◦ The nature of the technique

(15)

Some examples

15

Cultural probes Diary and

(16)

Focus group

(17)

Summary

•Five key issues of data gathering: goals, choosing participants, triangulation, participant relationship, pilot

•_{Observation may be direct or indirect, in the field} or in controlled setting

•_{Techniques can be combined depending on study} focus, participants, nature of technique and

(18)

Techniques in data

gathering



Recorded audio/video

(19)

Data recording

•

Notes+still camera

• _{Advg: handwritten notes}

(pen & paper less intrusive than a keyboard;flexible

• _{Disadvg: notes –tiring and difficult to type/write}

& listen & observe at the same time; easy to lose concentration;biases creep in;handwritten difficult to understand; speed of writing/typing is limited

(20)

Data recording (2)

•

Audio + photographs

 _{Useful alternative to note taking; less intrusive} than video

 _{In observation – allows observers to focus on} activity rather than spoken word.

 _{In interview – allows the interviewer to pay more} attention to the interviewee rather than taking notes while listening

 _{Transcribing audio data – time consuming but may} be not all only sections needed.

(21)

Data recording(CONT…)

•

Video

• _{Advg: - capture both audio and video.} • _{Issues on video:- where to fix the video}

position or use roving recorder (depend on activity and purpose of what need to be recorded)

• _{Where to point the camera in order to}

capture what it is required.

• _{Understanding the impact of the}

recording on participants – impact on behavior when they are recorded.

(22)

Problems with data gathering

(1)



Identifying and involving stakeholders:

users, managers, developers, customer

reps?, union reps?, shareholders?



Involving stakeholders: workshops,

interviews, workplace studies, co-opt

stakeholders onto the development

team



‘Real’ users, not managers:

(23)

Problems with data gathering (2)



Requirements management: version

control, ownership



Communication between parties:

—_{within development team} —_{with customer/user}

—between users… different parts of an organisation use different terminology



Domain knowledge distributed and

implicit:

—_{difficult to dig up and understand}

—_{knowledge articulation: how do you walk?}



Availability of key people

(24)

Problems with data

gathering (3)

•

Political problems within the organisation

•

Dominance of certain stakeholders

•

Economic and business environment changes

(25)

Some basic

guidelines

25

•

Focus on identifying the stakeholders’

needs

•

Involve all the stakeholder groups

•

Involve more than one representative

from each stakeholder group

•

Use a combination of data gathering

(26)

Some basic

guidelines

• Support the process with props such as

prototypes and task descriptions

• Run a pilot session

• You will need to compromise on the data you

collect and the analysis to be done, but before you can make sensible compromises, you need to know what you’d really like

(27)

(28)

Data interpretation and analysis

•

Start soon after data gathering session

•

Initial interpretation before deeper

analysis

•

Different approaches emphasize different

elements e.g. class diagrams for

object-oriented systems, entity-relationship

(29)

Quantitative & Qualitative

•

Quantitative data – expressed as numbers

•

Qualitative data – difficult to measure sensibly

as numbers, e.g. count number of words to

measure dissatisfaction

•

Quantitative analysis – numerical methods to

ascertain size, magnitude, amount

•

Qualitative analysis – expresses the nature of

elements and is represented as themes,

patterns, stories

• Be careful how you manipulate data and numbers!

(30)

Simple Quantitative Analysis

• Averages

• _{Mean: add up values and divide by number of} data points

• _{Median: middle value of data when ranked}

• _{Mode: figure that appears most often in the data}

• Percentages

• Graphical representations give overview of data

Number of errors made

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5

1 3 5 7 9 11 13 15 17 User N u m b e r o f e rr o rs m ad e Internet use

< once a day once a day once a week 2 or 3 times a week once a month

Number of errors made

0 2 4 6 8 10

0 5 10 15 20

(31)

Visualizing log data

31

Interaction

profiles of players in online game

(32)

Web analytics

(33)

Simple Qualitative Analysis

•

Recurring patterns or themes

–

Emergent from data, dependent on

observation framework if used

•

Categorizing

data

–

Categorization scheme may be emergent or

pre-specified

•

Looking for critical incidents

–

Helps to focus in on key events

(34)

Tools to support data analysis

• Spreadsheet – simple to use, basic graphs

• Statistical packages, e.g. SPSS

• Qualitative data analysis tools

– Categorization and theme-based analysis, e.g. N6

– Quantitative analysis of text-based data

• CAQDAS Networking Project, based at the University of Surrey

(35)

Presenting the findings

• _{Only make claims that your data can support}

• _{The best way to present your findings depends on}

the audience, the purpose, and the data gathering and analysis undertaken

• _{Graphical representations (as discussed above)}

may be appropriate for presentation

• _{Other techniques are:}

– Rigorous notations, e.g. UML

– Using stories, e.g. to create scenarios – Summarizing the findings

(36)

Summary

• The data analysis that can be done depends on the

data gathering that was done

• Qualitative and quantitative data may be gathered

from any of the three main data gathering approaches

• Percentages and averages are commonly used in

Interaction Design

• Mean, median and mode are different kinds of

‘average’ and can have very different answers for the same set of data

• Grounded Theory, Distributed Cognition and Activity

Theory are theoretical frameworks to support data analysis

• Presentation of the findings should not overstate the

(37)

(38)

Establishing

requirements

• What do users want? What do users ‘need’?

Requirements need clarification, refinement, completion, re-scoping

Input: requirements document (maybe) Output: stable requirements

• Why ‘establish’?

Requirements arise from understanding users’ needs

(39)

Different kinds of requirements

39

•

Functional:

—What the system should do

—Historically the main focus of

requirements activities

•

(Non-functional: memory size, response

time...)

•

Data:

—What kinds of data need to be stored?

(40)

Environment or context of use:

— physical: dusty? noisy? vibration? light? heat? humidity? …. (e.g. OMS insects, ATM)

— social: sharing of files, of displays, in paper, across great distances, work individually, privacy for clients

— organisational: hierarchy, IT department’s

(41)

An extreme example

(42)

• Users: Who are they?

— Characteristics: ability, background, attitude to computers

— System use: novice, expert, casual, frequent — Novice: step-by-step (prompted),

constrained, clear information

— Expert: flexibility, access/power — Frequent: short cuts

(43)

What are the users’ capabilities?

Humans vary in many dimensions:

— size of hands may affect the size and positioning of input buttons

— motor abilities may affect the suitability of certain input and output devices

— height if designing a physical kiosk

— strength - a child’s toy requires little strength to operate, but greater strength to change batteries

— disabilities (e.g. sight, hearing, dexterity)

(44)

Kinds of

requirements

What factors (environmental, user,

usability) would affect the following

systems?

•

Self-service filling and payment system for

a petrol (gas) station

•

On-board ship data analysis system for

geologists searching for oil

(45)

Task

descriptions

45

• Scenarios

― an informal narrative story, simple, ‘natural’, personal, not generalisable

• Use cases

— assume interaction with a system

— assume detailed understanding of the interaction

• Essential use cases

— abstract away from the details

(46)

Use case for travel organizer

1. The system displays options for investigating visa and vaccination requirements.

2. The user chooses the option to find out about visa requirements. 3. The system prompts user for the name of the destination country. 4. The user enters the country’s name.

5. The system checks that the country is valid.

6. The system prompts the user for her nationality. 7. The user enters her nationality.

8. The system checks the visa requirements of the entered country for a passport holder of her nationality.

9. The system displays the visa requirements.

(47)

Alternative courses for travel

organizer

47 Some alternative courses:

6. If the country name is invalid:

6.1 The system displays an error message. 6.2 The system returns to step 3.

8. If the nationality is invalid:

8.1 The system displays an error message. 8.2 The system returns to step 6.

9. If no information about visa requirements is found: 9.1 The system displays a suitable message.

(48)

Example use case diagram for travel organizer

(49)

Task analysis

• Task descriptions are often used to envision new systems or devices

• Task analysis is used mainly to investigate an existing situation

• It is important not to focus on superficial activities

What are people trying to achieve? Why are they trying to achieve it? How are they going about it?

• Many techniques, the most popular is Hierarchical Task Analysis (HTA)

(50)

Hierarchical Task Analysis



Involves breaking a task down into

subtasks, then sub-sub-tasks and so on.

These are grouped as plans which specify

how the tasks might be performed in

practice



HTA focuses on physical and observable

actions, and includes looking at actions

not related to software or an interaction

device



Start with a user goal which is examined

and the main tasks for achieving it are

identified

(51)

Example Hierarchical Task

Analysis

51

0. In order to buy a DVD 1. locate DVD

2. add DVD to shopping basket 3. enter payment details

4. complete address 5. confirm order

(52)

Example Hierarchical Task

Analysis (graphical)

(53)

Summary

• Getting requirements right is crucial

• There are different kinds of requirement, each is significant for interaction design

• The most commonly-used techniques for data gathering are: questionnaires, interviews, focus groups, direct observation, studying

documentation and researching similar products

• Scenarios, use cases and essential use cases can be used to articulate existing and

envisioned work practices.

• Task analysis techniques such as HTA help to investigate existing systems and practices

http://www.youtube.com/watch?v=-WWjGPyiVf4