requirements: gathering. why to understand what we are going to be doing we build systems for...

Post on 20-Dec-2015

218 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Requirements: Gathering

Why

To understand what we are going to be doing

We build systems for others, not for ourselves

Requirements definition: the stage where failure occurs most commonly

Getting requirements right is crucial

Functional vs. NonFunctional

Historically requirements

Features, functions that the system should do

Properties of the overall system

“-ilities” (quality, evolveability, flexibility, etc.)

Usability requirements

Not just “requirements”

Overall goals, success criteria User characteristics Task analysis Environment – physical, social,

technical Constraints Usability goals, criteria

User Characteristics

Attitude, morale, willingness to change, motivation, reading level, typing skill, education, frequency of use, training, color-blindness, handedness, gender,…

Novice, intermediate, expert System experience, task experience, computer

literacy Cultural factors

Uses of icons, colors, words, metaphors

Task Analysis

• Process of analyzing and documenting how people perform their tasks or activities

Learn what users do, why they do it, how they do it, when they do it, with what tools or people they do it

• Task-subtask decomposition

Physical Environment

Amount of space to work Lighting levels / directions Noise level Temperature, humidity, dust… Standing / sitting Power availability Dangers

Implications?

Technical Environment

Computers/platforms for application Technology to interact with Networking Mobility

Implications?

Social Environment

How do users interact with system? Roles?

How do users interact with others? Social implications of problem or

solution? Interruption Privacy

Implications?

Stakeholders

Primary – targeted end users Secondary – receive output or

provide input to system Tertiary – others directly receiving

benefits from system success or failure

Facilitating – design, development, maintenance

Stakeholder analysis

Cell phone

Bus location web page

Nuclear power plant control system

Typical Real-World Constraints

Elapsed time to market Cost/effort to design and implement Size/footprint/weight/power/price Computer power/memory (related to cost

and power Consistency with overall product line Backward compatibility Differentiation from competitive products

Usability Requirements

Usability goals: such as learnability, consistency, robustness, etc.

Ways to measure and judge success Time to complete key tasks - min, max Time to become proficient - do given set of

tasks in given time Subjective satisfaction

Example

What factors (environmental, user, usability) would affect the following systems?

• Self-service filling and payment system for a gas station

• On-board ship data analysis system for geologists searching for oil

• Fashion website for buying clothes

Bus location web page

User characteristics Context: Environment, types of

users Constraints: device, market, etc. Functional requirements Non-functional requirements

Gather, Organize, Represent

Gather data Interviews, observation,

surveys/questionnaires, documentation, immersion

Organize data Notes, cards, brainstorming, computer tools

Represent data Lists, outlines, matrices Narratives Hierarchies, Networks, Flow charts

Formative & Summative Evaluation Formative evaluation

Conducting this process to help guide the formation (ie, design) of a UI

Summative Evaluation Conducting this process to help summarize

(sum up) the effectiveness of an existing or developmental UI

Many techniques can be used for both formative and summative evaluation Our focus right now is on formative

evaluation Will revisit some of the methods again later

(Not All) Requirements Gathering Methods

1. Observation2. Thinking Out Loud & Cooperative

Evaluation3. Interviews4. Questionnaires5. Focus groups6. Study Documentation7. Look at competitive products8. Ethnography - learn by immersion/doing

Observation & Thinking Out Loud

Watch user(s) doing activity of interest to you

Video or audio record (with permission)

Think out loud - encourage user to verbalize what they are thinking Not everyone is good at this Hard to keep it up for long time while

also doing something; need breaks

Observing Tips

Carefully observe everything about users and their environment

Think of describing it to someone who has never seen this activity before

What users say is important, so are non-verbal details

Cooperative (Participative) Evaluation

Sit with user doing activity of interest to you Talk with user as the do their activity

Ask questions Why are you doing that? How did you know the result was what you

wanted? Are there other ways to achieve the same goal? How did you decide to do things this way?

Relaxed version of thinking out loud Observer and participant can ask each other

questions

Example: mall kiosk

What could you observe? How could you use coop eval?

Interviews

Structured Efficient Require training

Unstructured Inefficient No training

Semi-structured Good balance Often appropriate

Semi-Structured Interviews Predetermine data of interest - know why you

are asking questions - don’t waste time Plan for effective question types

How do you perform task x? Why do you perform task x? Under what conditions do you perform task x? What do you do before you perform…? What information do you need to…? Whom do you need to communicate with to …? What do you use to…? What happens after you…? What is the result or consequence of…? What is the result or consequence of NOT…?

See ID 13.2 for more tips and discussion

Domain Expert Interviews

Expert describes how it should be done (not necessarily how it is done)

Questionnaires

General criteria Make questions clear and specific Ask some closed questions with range

of answers Sometimes also have a no opinion option,

or other answer option Do test run with one or two people

Seven-point Likert Scale (use odd #)

Could also use just words Strongly agree, agree, neutral,

disagree, strongly disagree

Questionnaires - Example

See ID 13.3 for more tips

Other Typical Questions

Rank the importance of each of these tasks (give a list of tasks)

List the four most important tasks that you perform (this is an open question)

List the pieces of information you need to have before making a decision about X, in order of importance

Are there any other points you would like to make? (open-ended opinion question; good way to end)

Open ended questions

Can ask questions similar to semi-structured interview …but you can’t follow up, so take care

what you ask Keep as short and simple as

possible

Focus Groups

Group of individuals - 3 to 10 Use several different groups with different roles or

perspectives And to separate the powerful from those who are

not Careful about few people dominating discussion

Use structured set of questions More specific at beginning, more open as progresses Allow digressions before coming back on track

Relatively low cost, quick way to learn a lot Audio or video record, with permission

Example: mall kiosk

Who to interview? What questions? Who to give questionnaire to? What

questions? What about focus group?

What are differences between methods?

Study Documentation

Similar in some ways to the expert interview

Often describe how things should be done rather than how they are done Try to understand why not done “by the

book”

Look at Competitive Products

Looking for both good and bad ideas Functionality UI style

Do user task performance metrics to establish bounds on your system

Ethnography

Deeply contextual study Immerse oneself in situation you want to

learn about (has anthropological and sociological roots) Observing people in their cultural context

Behavior is meaningful only in context For UI designers: understand current

methods, activities, environment, problems to aid design

Ethnography

Things of interest to evaluator Structure and language used in work Individual and group actions Culture affecting work Explicit and implicit aspects of work

Example: Office work environment Business practices, rooms, artifacts, work

standards, relationships between workers, managers, …

Drawbacks of Ethnographic Methods

Time required Can take weeks or months for large systems

Scale Most use small numbers of participants just to

keep somewhat manageable Type of results

Highly qualitative, may be difficult to present/use

Acquired skill – “learn by doing” Identifying and extracting “interesting” things

is challenging

Which Methods to Use?

Depends on Resources Current knowledge of tasks and users Context

Can’t use talking out loud if work involves two people working together

Essential to use some methods Not likely you will use all methods

See pg. 214 in ID

Which Methods to Use?

• Self-service filling and payment system for a gas station

• On-board ship data analysis system for geologists searching for oil

• Fashion website for buying clothes at large department store

Bus Location Web Page

Create a requirements plan which methods What to look for/ask/do for each?

(Not All) Requirements Gathering Methods

1. Observation2. Thinking Out Loud & Cooperative

Evaluation3. Interviews4. Questionnaires5. Focus groups6. Study Documentation7. Look at competitive products8. Ethnography - learn by immersion/doing

Assignment 1

Semi-structured interview 1 person List of questions Summarize responses

Think about your project topic Due: Wednesday at noon

Brainstorming, cont.

top related