View
245
Download
1
Category
Preview:
Citation preview
Software Requirements Third Edition
Chapter 4
Requirements elicitation
“Elicitation is a collaborative and analytical process that includes activities to collect, discover, extract and define
requirements.”
Rules
Create an environment conducive to a thorough
exploration of the product being specified
• Use vocabulary of the business
• Record significant application domain terms in a
glossary
• Customers must understand that ta discussion
about possible functionality is NOT a commitment
• Brainstorming and imagining the possibilities is a
separate matter from analyzing priorities,
functionality and constraints.
Requirements Elicitation Process
Figure 7-2 Activities for a single req’ts elicitation session
Perform
elicitation
activities
Decide on
elicitation
scope and
agenda
Prepare
resources
Prepare
questions
and straw
man models
Perform
elicitation
session
Organize
and share
notes
Document
open issues
Prepare for elicitation Follow up after elicitation
Req’ts elicitation techniques
Facilitated activities and independent activities
1. Interviews
2. Workshops
3. Focus Groups
4. Observations
5. Questionnaires
6. System interface analysis
7. User interface analysis
8. Document Analysis
Interviews
• One on one or small-group – facilitated
• User buy-in to the process
Tips (prepare):
Establish rapport
Stay in scope
Prepare questions and straw man models ahead of
time
Suggest ideas
Listen actively!!!
Workshops
“Facilitation is the art of leading people through processes toward agreed-upon objectives in a manner that encourages
participation, ownership, and productivity from all involved.”
Tips:
• Establish and enforce ground rules
• Fill all of the team roles
• Plan an agenda
• Stay in scope
• Use parking lots to capture items for later consideration
• Timebox discussion
• Keep the team small but include the right stakeholders
• Keep everyone engaged
Focus Groups
“A representative group of users who convene in a
facilitated elicitation activity to generate input and ideas
on a product’s functional and quality requirements.”
• Useful for exploring users’ attitudes, impressions,
preferences… when you do not have access to users
within your company.
• Focus groups must be facilitated.
• Keep on topic without influencing the opinions
expressed
Observations
… you can often learn a lot by observing exactly how users perform their task.
Observing a user’s workflow in the task environment allows you to:
• validate information collected from other sources,
• identify new topics for interviews,
• see problems with the current system, and
• identify ways that the new system can better support the workflow.
Silent observations are appropriate when busy users cannot be interrupted
Interactive observations allow you to interrupt the user mid-task and ask questions.
Questionnaires
Preparing well-written questions is not easy!
Suggestions:• Provide answer options that cover the full set of possible
responses
• Make answer choices both mutually exclusive (no overlaps in numerical ranges) & exhaustive
• Don’t phrase a question in a way that implies a ‘correct’ answer
• If you use scales, use them consistently throughout the questionnaire
• Use closed questions with two or more specific choices if you want to use the questionnaire results for statistical analysis. Open-ended questions allows users to respond any way they want.
• Consider consulting with an expert in questionnaire design and administration…
• Always test a questionnaire before distributing it.
• Don’t ask too many questions or people won’t respond
System interface analysis
• Independent elicitation techniques that entails
examining the systems to which your system
connects.
… reveals functional req’ts regarding the exchange of
data and services between systems.
Context diagrams… and obvious choices to begin
finding interfaces
User interface analysis
• Technique used to study existing systems to discover
user and functional req’ts.
• Best to interact with the existing systems directly…
but if necessary use screen shots
• UI analysis can help you identify a complete list of
screens to help you discover potential features.
Document analysis
• A way to get up to speed on an existing system or
new domain.
• Although… I would guess that the available
documents are not up to date … or even available.
Planning elicitation on your project
An elicitation plan includes techniques you use, when
they will be used and for what purpose.
The plan should address:
• Elicitation objectives
• Elicitation strategy and planned techniques
• Schedule and resource estimates
• Documents and systems needed for independent elicitation
• Expected products of elicitation efforts
(use cases, an SRS, an analysis of questionnaire results, or quality
attribute specs… make sure you target the right stakeholders)
• Elicitation risks
(what might get in the way of these activities, the severity, and
mitigation plan)
Fig 7-3 Suggested elicitation techniques by project
characteristic
Inte
rvie
w
Work
shops
Focu
s G
roups
Obse
rvat
ions
Ques
tionnai
res
Syst
em i
nte
rfac
e an
alysi
s
Use
r in
terf
ace
anal
ysi
s
Docu
men
t an
alysi
s
Mass-market SW x x x
Internal corporate SW x x x x x x
Replacing existing system x x x x x x
Enhancing existing system x x x x x
New application x x x
Packaged SW implementation x x x x
Embedded system x x x
Geographically distributed stakeholders x x x
Preparing for each session
Plan session scope and agenda
Prepare resources
Learn about stakeholders
Prepare questions
Imagine yourself learning the user’s job
Probe around the exceptions
Prepare straw man models
Perform
elicitation
activities
Decide on
elicitation
scope and
agenda
Prepare
resources
Prepare
questions
and straw
man models
Perform
elicitation
session
Organize
and share
notes
Document
open issues
Prepare for elicitation Follow up after elicitation
Performing elicitation activities
Educate stakeholders
Teach stakeholders about your elicitation approach
Explain exploration techniques
Take good notes
Exploit the physical space
Use walls… for diagrams, lists
Whiteboards
Perform
elicitation
activities
Decide on
elicitation
scope and
agenda
Prepare
resources
Prepare
questions
and straw
man models
Perform
elicitation
session
Organize
and share
notes
Document
open issues
Prepare for elicitation Follow up after elicitation
Following up after elicitation
• Organize and share notes
• Document open issues
• Classify newly gathered information
Perform
elicitation
activities
Decide on
elicitation
scope and
agenda
Prepare
resources
Prepare
questions
and straw
man models
Perform
elicitation
session
Organize
and share
notes
Document
open issues
Prepare for elicitation Follow up after elicitation
Classify customer input
Leftover… what doesn’t fit
• Req’t not related to the SW development (e.g. training)
• Project constraint (cost or schedule restriction)
• An assumption of dependency
• Additional info of historical, context setting, or descriptive nature
• Extraneous information that does not add value
Examples: Phrases that might indicate classification
category for requirements
• Business req’ts
• User req’ts
• Business rules
• Functional req’ts
• Quality attributes
• External interface req’ts
• Constraints
• Data req’ts
• Solution ideas
How to know when you’re done?
Perhaps if:
• The user can’t think of any more use cases or user stories.
• Users propose new scenarios, but they don’t lead to any new functional req’ts.
• Users repeat issues they already covered
• Suggested new features, user req’ts, or functional req’ts are all deemed to be out of scope
• Proposed new req’ts are all low priority
• The users are proposing capabilities that might be included “sometime in the lifetime of the product” rather than “in the specific product you are talking about
• Developers and testers who review the req’ts for an area raise few questions
Cautions
• Balance stakeholder representation
• Define scope appropriately
• Avoid the req’ts – versus - design arguments
• Research within reason
Assumed and Applied
“You will never document 100% of the req’ts… but
Req’t you don’t specify pose a risk that the project might deliver a solution different from what stakeholders expect.”
• Assumed req’ts
Those that people expect without having explicitly expressed them.
• Implied req’ts
Those that are necessary because of another req’t but aren’t explicitly stated.
Developers can’t implement functionality they don’t know about.
Finding missing req’ts
• Decompose high-level req’ts… so you know exactly
what is being requested.
• Ensure that all user classes have provided input… and
each user req’t has at least one identified user class
who will receive value.
• Trace system, user, event response lists, and business
rules to their corresponding functional req’ts.
• Check boundary values for missing req’ts.
• Represent req’ts information in more than one way…
it difficult to read a mass of text and notice if an item
is absent.
Finding missing req’ts
• Sets of req’ts with complex Boolean Logic often are
incomplete… and wrong.
• Create a checklist of common functional areas to
consider for your projects… error logging, backup
and restore, access security, reporting, printing,
preview capabilities, and configuring user interfaces.
• A data model can reveal missing functionality.
All data entities that the system will manipulate must have
corresponding CRUD functionality,
Recommended