SWE 4324 Ch. 2 - How to gather requirements:

some techniques to use

Ch. 3 – Finding out about the users and their domain

UIDE Chapter 2 2

Please get out an 8.5 X 11 sheet of paper Put your name & the title above. Follow the lecture and write your answers

for each of the “Par” questions. (They will always be in red.)

Hand in this sheet on your way out of class. Thanks!

Attendance/Par for Monday 6/1

UIDE Chapter 2 3

Users◦ Who are the usual? The unusual?◦ Demographics Description◦ Education Technology Attitude

Task Characteristics◦ Frequency Job Complexity◦ Structure Schedule Reward

Environment Characteristics◦ Presence Interruptions Privacy◦ Lighting Noise Layout

Par1-Why is this information needed?

The Crucial Knowledge needed

UIDE Chapter 2 4

Observing Your Users doing the task in their environment◦ Direct Observation

Field or Controlled Studies

◦ Indirect Observation: Video Recording

◦ Points to Consider in Relation to Observation

Direct: cheapest, most straightforward, loss of information

Indirect: Permanent record, easily reviewed

UIDE Chapter 2 5

• Cost of requirements defects

• Different types of requirements

• Data gathering

• Task Scenarios – read page 67-76

• Concrete Use Cases (not personalized)

• Essential use cases (abstract)

• Workflow Analysis

• Hiearchical Task analysis: HTA

• Par2- Which of these did you do in Web A?

The importance of requirements

UIDE Chapter 2 6

• 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◦ Expression as ‘requirements’◦ All of this is iterative

• Why:◦ Requirements definition: the stage where failure

occurs most commonly◦ Getting requirements right is crucial

What, how and why?

UIDE Chapter 2 7

• 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◦ Requirements can be justified & related to data

Establishing requirements

UIDE Chapter 2 8

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?—How will they be stored (e.g. database)?

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 attitude and remit,

user support, communications structure and infrastructure, availability of training

Usability: learnability, throughput, flexibility, attitude

Different kinds of requirements

UIDE Chapter 2 9

—Personal User Information—Knowledge and Experience— Job and Task Characteristics—User Constraints—Personal Preferences and Traits—Social Environment

—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—Casual/infrequent: clear instructions, e.g. menu paths

Users: Who are they?

UIDE Chapter 2 10

In teams of two – read the scenario for an on-line system to get tickets for an event….discuss, then give the following: User Profile Tasks the user was involved with Considerations for the new System

◦ Functional◦ Data◦ Environmental◦ User◦ Usability

Par3 Requirement Activity

UIDE Chapter 2 11

Dan is a SPSU first year student who enjoys taking part in virtual chat environments. He is 17 years old and partially deaf. Late one night, he is in conversation with someone who recommends that he go and see the movie “Man of Steel” directed by Zack Snyder which has just come out. Dan enjoyed the movie 300 which was also directed by Zack Snyder. It's too late to phone the local cinema to see if it's on there, so he decides to use the internet to obtain some tickets for the following weekend. At the cinema website he looks for the film titles currently showing. The structure of the site is quite clear, and it's possible to go straight to the information about films and showing times. The movie “Man of Steel” is indeed showing. From this page, he can indicate the time of his choice and order the tickets. He chooses the 7pm performance, but the system tells him that this is fully-booked and offers him alternatives: the 5.30pm and the 8pm showings both have available seats. The system displays the seating plan for the cinema which shows the available seats for each showing, and how much each costs. Dan then chooses the seats and showing time that he wants and confirms the booking. Next year, when he has his own bank account, he'll be able to pay for tickets online too and they can be posted to him, but for now he must collect the tickets from the box office and pay for them an hour before the film starts. As he is partially deaf, he needs to double-check that the cinema is equipped with suitable sound amplification technology that links in to his hearing aid. Having completed his order, he returns to chatting with his friends.

UIDE Chapter 2 12

Interviewing your users

--- Forum for talking to people

—Structured, unstructured or semi-structured

—Props, e.g. sample scenarios of use,

prototypes, can be used in interviews

—Good for exploring issues

—But are time consuming and may be

infeasible to visit everyone Talking to or questioning users

Structured interview

Flexible interview

◦ Points to Consider in Relation to Interviewing

Structured is easiest

Audio/Video recording gives a permanent record

Avoid “leading” questions.

Data gathering techniques

UIDE Chapter 2 13

Questionnaires:—A series of questions designed to elicit

specific information —Questions may require different kinds of

answers: simple YES/NO; choice of pre-supplied answers; comment

—Often used in conjunction with other techniques

—Can give quantitative or qualitative data—Good for answering specific questions from

a large, dispersed group of people

◦ Types of Question Structure

Closed Questions

Select from a list of answer choices (y/n, a-d)

Semantic Differential

Questionnaires and Surveys

UIDE Chapter 2 14

Closed Questions

Rate the usefulness of the COPY command on the following scale

Very Useful

Of no use

Semantic Differential

UIDE Chapter 2 15

Questions

Closed Questions Open Questions

Likert Scale“A rating scale measuring the strength of agreement with a clear statement. Often administered in the form of a questionnaire used to gauge attitudes or reactions.”

For example:Question: "I found the software easy to use..."

1 Strongly disagree2 Somewhat disagree3 Undecided4 Somewhat agree5 Strongly agree

• What do you…………..

• How do you……………

• What ways…………….

• Provide richer data

• Time consuming to analyze

UIDE Chapter 2 16

Keep it simple (K.I.S.)◦ Few questions as possible◦ One sheet of paper, one side if possible

Clear and unambiguous questions Gather needed information Comment section Statistics Package for Social Sciences (SPSS)

Techniques Par4- Does your Pre ? and Post ? have

both closed and open ? If no, please consider adding some.

Points to Consider

UIDE Chapter 2 17

“The user types in all the names of the meeting participants together with some constraints such as the

length of the meeting, roughly when the meeting needs to take place, and possibly where it needs to take place. The system then checks against the individuals’ calendars and the central departmental calendar and presents the user with a series of dates on which everyone is free all at the

same time. Then the meeting could be confirmed and written into people’s calendars. Some people, though, will

want to be asked before the calendar entry is made. Perhaps the system could email them automatically and

ask that it be confirmed before it is written in.”

Scenario for shared calendar

UIDE Chapter 2 18

1. The user chooses the option to arrange a meeting.2. The system prompts user for the names of attendees.3. The user types in a list of names.4. The system checks that the list is valid.5. The system prompts the user for meeting constraints.6. The user types in meeting constraints.7. The system searches the calendars for a date that satisfies the constraints. 8. The system displays a list of potential dates.9. The user chooses one of the dates.10. The system writes the meeting into the calendar.11. The system emails all the meeting participants informing them of them appointment

Use case for shared calendar

UIDE Chapter 2 19

Example use case diagram for shared calendar

Administrator Departmentalmember

Arrange ameeting

Update calendarentry

Retrievecontact details

UIDE Chapter 2 20

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)

Task analysis

UIDE Chapter 2 21

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

Tasks are sub-divided into sub-tasks

Hierarchical Task Analysis

UIDE Chapter 2 22

0. In order to borrow a book from the library 1. go to the library 2. find the required book

2.1 access library catalogue2.2 access the search screen2.3 enter search criteria2.4 identify required book 2.5 note location

3. go to correct shelf and retrieve book4. take book to checkout counter

plan 0: do 1-3-4. If book isn’t on the shelf expected, do 2-3-4.

plan 2: do 2.1-2.4-2.5. If book not identified do 2.2-2.3-2.4.

Example Hierarchical Task Analysis

UIDE Chapter 2 23

Example Hierarchical Task Analysis (graphical) Please look at Personas PPT slides for a better HTA

321 4

access search screen

0

Borrow a book from the library

go to the library

find required book

retrieve book from shelf

take book to counter

access catalog

enter search criteria

identify required book

note location

plan 0: do 1-3-4. If book isn’t on the shelf expected, do 2-3-4.

plan 2: do 2.1-2.4-2.5.If book not identified from information available, do 2.2-2.3-2.4-2.5

2.1 2.2 2.3 2.4 2.5

UIDE Chapter 3

◦ Describing the Users: Users Have “Characteristics” That Are Relevant to UI Design

◦ Designing for Physical Limitations

◦ User Profiling: Describing Your Users and Their Characteristics

Users: Finding Out Who They Are

UIDE Chapter 3

Age Sex Culture Physical abilities and disabilities Educational background Computer/IT experience Motivation Attitude

Users Characteristics

UIDE Chapter 3

15%-35% population with impairment/disability Colorblindness

◦ Deuteranopia – red/green◦ Protanopia – red/green/bluish green◦ Tritanopia – blue/yellow

Designing for Physical Limitations

UIDE Chapter 3

A precise description of a user ans what he or she wishes to do when using a system

A concrete person in the designer’s mind Cast of characters At least one ‘primary’ persona, the main

focus of the design

Personas: Another Way to Describe Your

Users

UIDE Chapter 3

Primary users Secondary users (i.e.)

◦ Senior managers, business analysts, system analysts, project managers, application developers, interface designers,……..

Other Stakeholders

UIDE Chapter 3

Finding Out What Users WantThe Domain: What Expert Knowledge Is Relevant to the Application?◦ Understanding the Domain

◦ Representing the Domain

Users’ Needs:

UIDE Chapter 3

Felt needs – unsure what the system can do

Expressed needs – what users say they want.

Normative needs – professional view about the nature of the problem and what may be needed

Users’ Needs: Finding Out What Users Want

UIDE Chapter 3

Domain Analysis ◦ Talking to, observing, interviewing domain

experts.◦ Identify of the experts will vary◦ Knowledge acquisition is often informal◦ Iteration of observation/interviews/analyses

Understanding the Domain

UIDE Chapter 3

Domain Models – derived from analyses◦ Text descriptions◦ Diagrams

Dataflow Entity-relationship State transition

Understanding the Domain

UIDE Chapter 3

Understanding the Domain

UIDE Chapter 2 34

• 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 and workshops, naturalistic observation, studying documentation

• 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

Summary