chapter 10 identifying needs and establishing requirements
TRANSCRIPT
Chapter 10
Identifying needs and establishing requirements
Outline
What, How, and Why? What are requirements? Data gathering for requirements Data analysis, interpretation, and
presentation Task description Task analysis
What, how, and why
What are we trying to achieve in the requirements activity?
Two aims 1) to identify needs -> to understand as much as
possible about the users, their work, and the context of that work
2) to establish requirements -> to produce a set of stable requirements that form a sound basis to move forward into thinking about design
How can we achieve this?
The process seems sequential
1) Gather some data
2) Analyze and interpret the data
3) Extract some requirements from the data
But, actually, the activities influence one another as the process iterates
Why bother? The importance of getting it right
Many research works have reported the significant cost of fixing errors late in the software development lifecycle rather than early, during the requirements activity
What are requirements?
Requirement
A requirement is a statement about an intended product that satisfies what it should do or how it should perform
One of the aims of the requirements activity is to make the requirements as specific, unambiguous, and clear as possible, and that how to tell when they have been fulfilled
Different kinds of requirements
Functional requirements Data requirements Environmental requirements User characteristics Usability goals and user experience goals
Functional requirements
Capture what the product should do
Example: a robot working in a car assembly plant Functional requirement: the robot should be able
to accurately place and weld together the correct pieces of metal
Data requirements
Capture the type, volatility, size/amount, persistence, accuracy, and value of the required data
Example: in the personal banking domain Data must be accurate, must persist over many
months and probably years, is very valuable, and there is likely to be a lot of it
Environmental requirements
Context of use – circumstances in which the interactive products will be expected to operate
Physical environment Social environment Organizational environment Technical environment
Physical environment
Amount of light, noise, dust expected in the operational environment
Will users need to wear protective clothing, such as large gloves or headgear, that might affect the choice of interface type?
How crowded is the environment? e.g. speech interface may not be appropriate to be used in a public space
Social environment
Will data need to be shared? Synchronous vs. asynchronous
Do collaborators have to communicate across great distances?
Organizational environment
How good is user support likely to be? How easily can it be obtained? Are there facilities or resources for training? How efficient or stable is the communications
infrastructure? How hierarchical is the management?
Technical environment
What technologies will the product run on or need to be compatible with?
What technological limitations might be relevant?
Underwater PCs
User characteristics
User’ s abilities User’ s skills Novice, Expert, Casual or Frequent user User’s nationality Educational background Preferences Personal circumstances Physical or mental disabilities
User characteristics
User profile: a collection of attributes for a ‘typical user’
Personas: rich descriptions of typical users of the product synthesized from a number of real users each persona has a unique set of goals include a description of the pretend user’s skills, attitudes,
tasks, and environment a name, a photograph, some personal details user experience goals
Data gathering for requirements
Data gathering
Interviews explore issues involve users
Focus group gain a consensus view highlight areas of conflicts and disagreement help stakeholders to meet designers and each
other
Data gathering
Questionnaires get initial responses to choose people to interview get a wider perspective on particular issues
Direct observation understand the nature of the tasks and the context in which
they are performed
Indirect observation Use less often in requirements activity Good for logging current tasks
Data gathering
Studying documentation good source of data about the steps involved in
an activity, and any regulations governing a task good for understanding legislation and getting
some background information on the work doesn’t involve stakeholder time
Researching similar products
Data gathering
Contextual inquiry Follows an apprenticeship model (user is expert,
designer is apprentice) A combination of observation, discussion, and
reconstruction of past events Four main principles
Context (going to the workplace and seeing what happens)
Partnership (user and developer collaborate) Interpretation (between the user and the developer) Focus (on the goals)
Problems with data gathering (1)
Identifying and involving stakeholders:users, managers, developers, customer reps?, union reps?, shareholders?
Involving stakeholders: workshops, interviews, workplace studies, co-opt stakeholders onto the development team
‘Real’ users, not managers:traditionally a problem in software engineering, but better now
From: www.id-book.com
Problems with data gathering (2)
Requirements management: version control, ownership Communication between parties:
— within development team— with customer/user— between users… different parts of an organisation
use different terminology Domain knowledge distributed and implicit:
— difficult to dig up and understand— knowledge articulation: how do you walk?
Availability of key people
From: www.id-book.com
Problems with data gathering (3)
• Political problems within the organisation
• Dominance of certain stakeholders
• Economic and business environment changes
• Balancing functional and usability demands
From: www.id-book.com
Data gathering guidelines for requirements
Focus on identifying the stakeholders’ needs Involve all the stakeholder groups Involve more than one representative from
each stakeholder group Support the data gathering sessions with
suitable props, e.g. task descriptions and prototypes
Data interpretation and analysis
• Start soon after data gathering session
• Initial interpretation before deeper analysis
• Different approaches emphasize different elements e.g. class diagrams for object-oriented systems, entity-relationship diagrams for data intensive systems
From: www.id-book.com
Brainstorming for innovation
Include participants from a wide range of disciplines, with a broad range of experience
Don’t ban ‘silly stuff’ Use catalysts for further inspiration
Build one idea on top of another Jump back to an earlier idea Consider alternative interpretations
Brainstorming for innovation
Keep records Start the brainstorm with a well-honed
problem Use warm-up exercises, e.g. word games,
exploration of physical items related or unrelated to the problem
Task description
Task description
Scenarios Use cases Essential use cases
Scenarios
Informal narrative description Describes human activities or tasks in a story
that allows exploration and discussion of contexts, needs, and requirements
Does not describe the use of software or other technological support to achieve a task
Use user’s vocabulary and phrasing
Scenarios
Help to understand what people do now So, help to explore constraints, contexts,
irritations, facilitators, etc. Help to identify stakeholders and products
involved in the activity It is a good idea to emphasize the context,
the usability and user experience goals, and the tasks the user is performing
Scenarios
Inclusion of emotional elements helps to increase developers’ understanding of context
Often, they are generated during workshop, interview, or brainstorming sessions to help explain or discuss users’ goals
Can be used to imagine potential uses of a product and to capture existing behavior
Scenarios
Not intended to capture a full set of requirements
Are very personalized account, offering only one perspective
Scenario for holiday planner
“The Thomson family enjoy outdoor activity holidays and want to try their hand at sailing this year. There are four members of the family: Sky who is 10 years old, Eamonn who is 15 years old, Claire who is 35, and Will who is 40. While out on a shopping trip they call by at the travel agents
in their local town to start exploring the possibilities ... The travel organizer is located in a quiet corner of the agents’ office, where there
are comfortable seats and play things for young children. They all gather around the organizer and enter their initial set of requirements—a sailing holiday for four novices. The stand-alone console is designed so that all members of the family can interact easily and comfortably with it. The
system’s initial suggestion is that they should consider a flotilla holiday, where several novice crews go sailing together and provide mutual
support for first-time sailors…”
Use cases
Focus on user goals, but the emphasis here is on a user-system interaction rather than the user’s task itself
Describes ‘normal course’, i.e., the set of actions that the analyst believes to be most commonly performed
Alternative courses are listed at the bottom of the use case
Use cases
More formal than scenarios
More useful at conceptual design stage than during requirements or data gathering
But use cases have been found to help some stakeholders express their views on how existing systems are used and how a new system might work
Use cases
To develop a use case, identify actors (people or system) actors’ goals or goals in using the system
Use case for holiday planner1. The system displays options for investigating visa and vaccination
requirements.
2. The user chooses the option to find out about visa requirements.
3. The system prompts user for the name of the destination country.
4. The user enters the country’s name.
5. The system checks that the country is valid.
6. The system prompts the user for her nationality.
7. The user enters her nationality.
8. The system checks the visa requirements of the entered country for a
passport holder of her nationality.
9. The system displays the visa requirements.
10. The system displays the option to print out the visa requirements.
11. The user chooses to print the requirements.
Alternative courses for
holiday planner Some alternative courses:
6. If the country name is invalid:6.1 The system displays an error message.6.2 The system returns to step 3.
8. If the nationality is invalid:8.1 The system displays an error message.8.2 The system returns to step 6.
9. If no information about visa requirements is found:9.1 The system displays a suitable message.9.2 The system returns to step 1.
Example use case diagram for holiday planner
HolidaymakerTravel agent
Update holiday details
Identify potential Holiday options
Retrieve visa requirements
Retrieve vaccination requirements
From: www.id-book.com
Essential use cases
Represent abstractions from scenarios, i.e. they represent a more general case than a scenario embodies
Try to avoid the assumptions of a traditional use case, i.e. there is a piece of technology to interact with, and assumptions about the user interface and the kind of interaction to be designed
Essential use cases
Is a structured narrative consisting of three parts A name that expresses the overall user intention A stepped description of user actions A stepped description of system responsibility
Instead of actors, essential use cases are associated with user roles
Example essential use case for holiday planner
retrieveVisa
USER INTENTION SYSTEM RESPONSIBILITYfind visa requirements
request destination and nationality
supply required informationobtain appropriate visa info
obtain copy of visa infooffer info in different formats
choose suitable formatprovide info in chosen format
From: www.id-book.com
Task analysis
Task analysis
Used mainly to investigate an existing situation, not to envision new products
What are they trying to achieve, why are they trying to achieve it, and how are they going about it?
Examples: Hierarchical Task Analysis (HTA) Goals, Operations, Methods, and Selection rules
(GOMS)
Hierarchical task analysis 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
From: www.id-book.com
Example Hierarchical Task Analysis
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
From: www.id-book.com
Example Hierarchical Task Analysis (plans)
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.
From: www.id-book.com
Example Hierarchical Task Analysis (graphical)
Borrow a book from the library
go to the library
find required book
retrieve book from shelf
take book to counter
321 4
0
access catalog
access search screen
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
From: www.id-book.com
Summary• 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, direct observation, studying documentation and researching similar products
• 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
From: www.id-book.com