lesson 7 - identifying user needs and establishing ... · pdf fileccu 2010 / 2011 lesson 7...
TRANSCRIPT
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
Introduction Requirements: What, How, Why Requirements Data collection Interpretation and analysis Task description Task analysis
©2007-2010 IST, RP & JB 11
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
Introduction Requirements: What, How, Why Requirements Data collection Interpretation and analysis Task description Task analysis
©2007-2010 IST, RP & JB 19
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
Introduction Requirements: What, How, Why Requirements Data collection Interpretation and analysis Task description Task analysis
©2007-2010 IST, RP & JB 36
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