lesson 7 - identifying user needs and establishing ... · pdf fileccu 2010 / 2011 lesson 7...

CCU 2010 / 2011

Lesson 7

Identifying User Needs and Establishing Requirements

(Part1 – Requirements & Data Collection)

Previous Lesson (1)

  Participative Design   Users are active in

  Developing

  Discussing and deciding

©2007-2010 IST, RP & JB 2

Previous Lesson (2)

  Topics

  Who represents the users?

  How to facilitate the communication between different user groups?

  Sharing representations

  Cultural differences

  Cooperative design

  Cooperative evaluation

©2007-2010 IST, RP & JB 3

Previous Lesson (3)   Techniques

  PICTIVE

  CARD

  Card Sorting

  “Six Thinking Hats”

  “Acting out”

©2007-2010 IST, RP & JB 4

  Introduction   Requirements: What, How, Why   Requirements   Data collection   Interpretation and analysis   Task description   Task analysis

©2007-2010 IST, RP & JB 5

A short story...

©2007-2010 IST, RP & JB 6

Identifying Needs and Requirements   When?

  Substituting / Updating an existing product   Creating a new product

  What should the product provide?   There are already some requirements   Refine existing requirements   Create new set of requirements from scratch

©2007-2010 IST, RP & JB 7

From Needs to Requirements   Users have

  Needs   Wishes   Expectations   Difficulties

  That need be   Discussed   Refined   Clarified   Reviewed

©2007-2010 IST, RP & JB 8

How to Get Good Requirements

  Implies   Understand the users   Know users’ capacities and skills   Know the tasks they carry out and their objectives   Know under which conditions tasks are carried

out   Know which product(s) they use   Know the constraints in the use of the product(s)

©2007-2010 IST, RP & JB 9

How to Identify Requirements

  Identify

  User needs

  Stating requirements

  Set of requirements is not a wish list

  Do no isolate / put users away   They are needed for the several evaluation and

design cycles

©2007-2010 IST, RP & JB 10

Requirements: What?

  Attain 2 objectives   Gather data on

  Users   Work / activity context   User Needs

  The design cycle path   Data > Requirements > Design

©2007-2010 IST, RP & JB 12

Requirements: How?

  How?   Gather data   Interpret data   Analyse data   Stating requirements

  Requirements specification and documentation

  Iterative refinement process   Do not put users out of the loop!

©2007-2010 IST, RP & JB 13

Requirements: Why? (1)‏   Surveys and studies show that

  Bad requirements are one of the main factors behind many products’ failure

  Successful products are the outcome of clear and detailed requirements

  Establishing requirements is a critical activity of the development process

©2007-2010 IST, RP & JB 14

Requirements: Why? (2)‏   User Centred Design

  Is a way to get correct requirements   That answer user needs and expectations

©2007-2010 IST, RP & JB 15

Establishing Requirements

  Requirements engineering   Requirements identification

  Existing (in other products)‏

  Capture requirements   With the help of the various stakeholder groups

  Requirement analysis   Classification, conflict resolution, consistency   Reformulation

  Requirements validation   Confirmation

©2007-2010 IST, RP & JB 16

Identifying Requirements

  It is not easy because   Requirements are not self evident   Users do not always know what they really

want   User may not be able to express themselves

clearly   User tell needs and wishes, not requirements

©2007-2010 IST, RP & JB 17

Identifying Requirements

  It is not easy because (cont.)

  Different user groups tell things differently

  External factors (business procedures, legislation, etc.)

  Requirements may be unrealistic or not in line with the application context

©2007-2010 IST, RP & JB 18

What is a Requirement (1)‏

  From the dictionary

  Necessary condition

  Legal rule

©2007-2010 IST, RP & JB 20

What is a Requirement (2)‏   Statement of what a product

  Should do   How to do it   Under which conditions

  Must be   Specific   Clear   Without ambiguity

  Specification and documentation

©2007-2010 IST, RP & JB 21

Requirements: Examples   All pages of the WWW site must load in less

than 5 seconds

  The product must be attractive to users   You need to know what “attractive” means to

the users…

©2007-2010 IST, RP & JB 22

The Volere Model‏ (Robertson, 2006)

©2007-2010 IST, RP & JB 23

Example of a Specification (1)

  Description:   An alarm must always be raised when the RPU

stops transmitting any messages   Rationale:

  A loss in data transmission signals the likely malfunction of the substation, maintenance must be called in, and prevents visualizing and controlling all equipments located upstream

  Source:   National grid control

©2007-2010 IST, RP & JB 24

Example of a Specification (2)‏   Fit Criterion:

  The product will raise an alarm at all times that the number of messages per minute with origin from the RPU is less than the number set for that RPU

  Customer Satisfaction: 3

  Costumer Dissatisfaction: 5

©2007-2010 IST, RP & JB 25

Example of a Specification (3)‏   Dependencies:

None

  Supporting Materials: RPU configuration and Operation Manual

  History: Raised by F. Fernandes, 2009/10/25

©2007-2010 IST, RP & JB 26

Types of Requirements (1)‏   Functional

  What the product must do

  Ex.: image viewer must be able to read files written in several image formats

  Ex.: Product to support pointer and sweep interaction input devices

©2007-2010 IST, RP & JB 27

Types of Requirements (2)‏   Non functional

  Constraints to the product and/or its development

  ex.: product to be portable to a list of hardware/software platforms

  ex.: product to run on platforms with hard drives with 30 MB capacity

  ex.: product to be delivered in 6 months

©2007-2010 IST, RP & JB 28

Requirements in Interactive Systems

  Functional   Data   Environmental   User   Usability

©2007-2010 IST, RP & JB 29

Functional Requirements

  What the product must deliver   Supported tasks   Roles taken

  Examples:   Warn that the inventory is low (under a

predefined number of units)   Prompt for input of mandatory data that was

not supplied

©2007-2010 IST, RP & JB 30

Data Requirements

  Characterization of data produced (output) and data consumed (input)

  Type, volatility, volume persistency, update

  Examples:   Share dealing application data must be

accurate and up-to-date and may change many times a day

  Banks: data persistency over months/years

©2007-2010 IST, RP & JB 31

Environment Requirements

  Environmental   Conditions under which the system must

operate   Physical: lighting, noise, dust, heat, humidity   Social: resource sharing (files, equipments,

synchronicity)   Organizational: available support, training,

(communication ) infrastructures, organization culture and structure

  Technological: platforms, compatibility, portability, technological constraints

©2007-2010 IST, RP & JB 32

User Requirements   User characteristics capture

  Capacities and skills

  Difficulties

  Experience

  User profile

  Examples:   Users must first know the Internet before accessing a

WWW site

  System to be used by persons with motor disabilities

©2007-2010 IST, RP & JB 33

Usability Requirements

  Usability goals and related measurements   Efficiency   Efficacy   Utility   Satisfaction   Learning   Security

  Assess development progress

©2007-2010 IST, RP & JB 34

Exercise

  List some requirements for the following applications

  Estimation of the ecological footprint of a family

  Performance analysis and display of sports data

©2007-2010 IST, RP & JB 35

Data Gathering

  Questionnaires   Interviews   Groups and Workshops   Observation   Prototyping   Documentation   Previous / similar systems

©2007-2010 IST, RP & JB 37

Data Gathering Examples

  Observation   Provides understanding of the business process

  Participative prototypes   (developed hand-in-hand with stakeholders)

Use, explore and identify users’ knowledge   Interviews (enable)

  Decision sequences capture and understanding   Dialogue for negotiation between users and the

development team   Role playing prototypes (and walkthroughs)

  Idem

©2007-2010 IST, RP & JB 38

Data Gathering - Prototyping

  Keep in touch with the “application”

  Enables the gathering of requirements that would not be otherwise visible

  Requirements for innovative systems / applications   Observation in realistic scenarios impossible

  Very useful to validate / confirm requirements

  Explain usage scenarios

©2007-2010 IST, RP & JB 39

Data Gathering - Documentation

  Manuals   Procedure manuals   Business / operational rules

  User records / logs   Good to identify

  Activities and related rules / procedures   Legislation and contextual data

  Should never be the only data source   Does not involve users (directly)

©2007-2010 IST, RP & JB 40

Data Gathering – Previous Systems   Assess what users have been using

  Assess similar (competing) systems   May be a way to start understanding user

difficulties

  Pay attention: what other systems provide is not necessarily good!

  Always check back with the users

©2007-2010 IST, RP & JB 41

Data Gathering Techniques Selection (1)

  Data gathering techniques main differences   Time taken   Level of detail   Risk (incertitude) of conclusions

  Analyst experience

©2007-2010 IST, RP & JB 42

Data Gathering Techniques Selection (2)   Type of tasks to identify / analyze

  Sequential tasks or concurrent / parallel tasks?

  Huge and complex data content or small and simple?

  User characteristics

  Ordinary persons with little training or task experts?

©2007-2010 IST, RP & JB 43

Data Gathering Problems (1) ‏  Identify and involve the stakeholders:

  Users, managers, technicians, consumer reps? Union reps? Shareholders?

  Getting stakeholders involvement:   Workshops, interviews, workplace environment studies

  Get real users, not managers:   A traditional software engineering problem

©2007-2010 IST, RP & JB 44

Data Gathering Problems(2) ‏  Requirements management:

  Version and propriety control

  Communication   Within the development team   With the client / user   Between users

(organization divisions that use different technologies)

  Implicit and distributed knowledge of the domain   Difficult to get and understand   Knowledge discourse

  Availability of key persons

©2007-2010 IST, RP & JB 45

Data Gathering Problems(3) ‏  Political problems within the organizations

  Domination exerted by a group of stakeholders

  Changes in the business or economic environment

  Balance between functionality and usability

©2007-2010 IST, RP & JB 46

Data Gathering: Recommendations (1)   Target data gathering at identifying stakeholders

  Behaviour, tools, other products, previous versions

  Involve user groups   Workshops, interviews, observation

  A representative of each group is not enough   Managers neither too

©2007-2010 IST, RP & JB 47

Data Gathering: Recommendations (2)

  Combine several techniques   Each technique provides a different view   Different views > corroboration   Interviews, surveys > consolidate with

workshops

  Use materials at all times   Prototypes, descriptions, etc.

©2007-2010 IST, RP & JB 48

Data Gathering: Recommendations (3)   Prepare all activities well

  Test tools

  Know what you want to get   Balance data gathering and analysis

  Plan how to gather data adequately   Analyze as early as possible

©2007-2010 IST, RP & JB 49

lesson 7 - identifying user needs and establishing ... · pdf fileccu 2010 / 2011 lesson 7...

Documents