Chapter 7 Identifying Needs and

Establishing Requirements

By:

Wang, Miao

Fan, Xiaona

Introduction

Before establishing requirements, we need to fully understand

Users and user needsUsers’ capabilityCurrent task and goalsCondition under which the product will be usedProduct performance constrainsNature of problem space

Definition of RequirementsRequirement is:

“A statement about an intended product that specified what it should do or how it should perform.”

Requirements should be:SpecificUnambiguousClearFit criterion: quantifiable and measurable

Intertwined Activities

Design Activity

EvaluationActivity

RequirementsActivity

Goals of Establishing Requirements

Identify/ invent needs: understand user, their work, context of that work

Produce a set of stable requirements to move forward to design

Sequential Activities of Establishing Requirements

Gather data

Interpreting data

Analyze data

End goal: Stable Requirements

Importance of Getting It Right

One major cause of IT project failure -unclear objective and requirements

Product should support stakeholders’ needs

Product be ignored, despised

Cause grief, anxiety, frustration

Lose revenue, customer confidence

Different Kinds of Requirements (1) Functional requirements

what the product/system should do

Data requirements the type, volatility, size/ amount …of the required data

Environmental requirementsPhysical environment: noise, heating, lighting Social environment: collaboration and coordination Organizational environment: training, job design, politics, roles Technical environment: software compatibility

Different Kinds of Requirements (2)

User requirementscharacters of the intended users group: beginning vs. advanced user.

User profile affects the way interaction is designed.

Usability requirementsCapture the usability goals and associate measures

Specific measures of the usability goals are established and agreed early in the development process

then revisited and used to track progress

Data Gathering Goals of data gathering:

Collect efficient relevant and appropriate data to produce stable requirements Expand clarify and confirm the initial requirements

Data gathering techniques: QuestionnairesInterviewsFocus groups/ workshopsObservationStudy documentation

Data Gathering Techniques (1)

Data Gathering Techniques (2)

Questionnaires: Admin at a distance Get answers for a specific question from a large group of peopleNo geographical location limitation Design is crucial and low response rate

Interviews:Exploring issues and encourage response Time consuming, and not efficient to meet with all the people

Data Gathering Techniques (3)Focus groups/ workshops

Good at gaining a consensus view pointHighlight areas of conflictHelps users to meet designers and each other to express their view in public.

Observation:Spending time with user in the natural context of activity.Observe, take notes ask questionsGain insights, and overcome the limitation of other techniques

Data Gathering Techniques (4)• Users can’t explain accurately

• Fill in details not provided by other

• Good at understand the nature of the task and the context

• Time consuming and huge amount of data

Study documentation: Study the written down procedures and rules in manuals

Study user dairies/ job logs

Good for understand legislation and background info; does not take time form users.

Issues Influence Choice of Techniques (1)

The nature of techniques Olson and Moran (1996):

The amount of time

The level of detail

The risk with the finding

The scales of the task Olson and Moran (1996):

Sequential steps vs. over-lapping steps

High information content vs. low information content

Issues Influence Choice of Techniques (2)

The knowledge required of the analyst:Layman vs. practitioner The knowledge about basic cognitive processes analyst must have

The point in development reached The available resource (money, time, people)Location and accessibility of stakeholders

Data Gathering Guidelines (1)

Focus on identifying users’ needs

Involve all the stakeholder groups

Involve only one representative from each stakeholder group is NOT enough

Combination of data gathering techniques 

Data Gathering Guidelines (2)

Support the data gathering sessions with suitable props (task description to be reused.) Run a pilot session  Make compromises because of pragmatic constraints (resource) How to record the data during the face to face data gathering sessions

7.5 Data Interpretation and Analysis

When? As soon after the gathering session

Aim: begin structuring and recording descriptions of the requirements

Approaches:Initial interpretation templateMore focused analysis of data

Example of Interpretation Template(The Volere Shell for Requirements)

Requirement #: Unique ID

Requirement Type: Template section

Event/use case#: Origin of the requirement

Description: A one-sentence statement of the intention of the requirement

Rationale: Why is the requirement considered important or necessary?

Source: Who raised this requirement?

Example of Interpretation Template(The Volere Shell for Requirements) Continued

Fit Criterion: A quantification of the requirement used to determine whether the solution meets the requirement.

Customer Satisfaction: Measures the desire to have the requirement implemented

Customer Dissatisfaction: Unhappiness if it is not implemented

Dependencies: Other requirements with a change effect

Kinds of More Focused Analysis of Data

Data-flow diagrams

State charts

Work-flow chart

Class diagrams

Scenarios

Use cases

Essential use cases

Task analysis

7.6 Task Description

Techniques of Task descriptionScenarios

Use cases

Essential use cases

Relationships between different Techniques

7.6.1 ScenariosDefinitionAdvantages

Easy to understand by the stakeholdersConcentrate on the human activityGood start point

CharacteristicsPersonalized account, offering only one perspectiveThe level of detail present in a scenario variesHuman activity may not be preserved in the future

Example of Scenarios(using library catalogs)

I want to find a book by Charles Dickens. He was a British Writer. I remember the title is something like “Christmas Carol”, but not very sure if the author name and title are accurate. So I go to the website of library catalog. There are different kinds of Catalogs: Author, Title/Journal Title, Keyword, Author/Title, Subject Heading, etc. Since I have unclear ideas of author and title, so I click author/title catalog. On the webpage of “Author/Title Search”, I type “Dickens” into the Author box, and “Christmas Carol” into Title box. Then the search result comes out. There are several editions of “A Christmas Carol” written by Charles Dickens. I choose my favorite edition, and get the call No. and location of the book.

7.6.2 Use Cases

Characteristics: emphasize on user-system interaction, stress is still very much on the user’s perspective, not the system’s

Associate with an actor (user)

“Normal course” & “alternative course”

Example of Use Case1. The user go to the catalog website2. The system prompts user for all kinds of

catalogue3. The user chooses the Author/Title catalog4. The system prompts the user for Author/Title

Catalog5. The user types the author name and book title in

the appropriate boxes6. The system search the book

Example of Use Case (continued)

7. The system displays a list of potential books.

8.The user chooses one of the book

9.The system displays the detail information of the book

10.The user get the call No. and location of the book

Example of Use Case (continued)

7. If no book is matched the search criterion,

7.1 The system provide “no match book” information

7.2 The system returns to step2

Graphical Representation of Use Case

Locate book

Collect books

Update catalog

Use case diagram for the library automatic system

7.6.3 Essential Use CasesCharacteristics:

abstract from scenarios, and try to avoid the assumptions of a traditional use caseMore generalare associated with user roles

• Difference between actor and user roles

Compositions:A name which expresses the overall user intentionA stepped description of user actionsA stepped description of system responsibility

Example of an essential use case

User Intention System Responsibility

Request appropriate details

Offer known details

Offer search results

Note search results

Quit system

close

Note that it does not specify search options or details of how to initiate the search

7.7 Task Analysis

Purpose: Analyze the underlying rationale and purpose of what people are doing

Definition: An umbrella term that covers techniques for investigating cognitive processes and physical actions, at a high level of abstraction and in minute detail

Widely used versionHTA: Hierarchical Task Analysis

GOMS: goals, operations, methods, and selection rules

7.7.1 Hierarchical Task Analysis

How? Top-down approach

Characteristics Focus on physical and observable actions

Examples

A Graphical Representation of the Task Analysis for Borrowing a Book

go to thelib rary

1

access ca ta log

2.1

acesssearchscreen

2.2

entersearchcrite ria

2 .3

identifyrequ ired

book2.4

notelocation

2.5

find therequ ired book

2

re trieve bookfrom she lf

3

take bookto counter

4

Borrow a book from the lib rary0

An HTA for borrowing a book from the library0. In order to borrow a book from the library1. Go to the library2. Find the required book

2.1 access library catalog2.2 access the search screen2.3 enter search criteria2.4 identify required book2.5 note location

3. Go to correct shelf and retrieve book