Agile Module 5: Elicit Requirements

Elicitation techniques
Elicitation techniques depend
on business domain, corporate
culture, and environment, skills
of the business analyst, and
requirements deliverables
This document is a partial preview. Full document download can be found on Flevy:
http://flevy.com/browse/document/5-elicit-requirements-2551

Steps of elicitation
Elicitation is one the most
critical activities for an agile
business analyst
It is actually a combination of
following 9 activities

Record requirements:
Gathered requirements
must be recorded for
future use
Most popular method:
User story

Analyze requirements:
Analyze requirements to
ensure you have received
complete requirements and
exceptions are covered

Confirm requirements:
Confirm requirements to
ensure verified requirements
are in alignment with source
of requirements

Common challenges in elicitation
• Lack of clarity in the wordings
• Ambiguity of written language
• Conflicts between
requirements / stakeholders
• No way to test
• Providing a solution rather than
stating requirementsThis document is a partial preview. Full document download can be found on Flevy:

Impact of communication on
requirements
Business analysts can take help of
modeling languages such as
Unified Modeling Language (UML)
and Business Process Modeling
Notation (BPMN) which reduces
ambiguity in communication using
natural languageThis document is a partial preview. Full document download can be found on Flevy:

Nominalization (Compression of
activities)
Users tend to convert a
long-lasting activity or
group of nouns into a
single event or noun

Nouns without reference index
For example, let us study
a requirement “No user
can update other user’s
password.”
Is this correct?

Universal quantifiers
Most likely the specified behavior
or property may not apply to all
the objects in the specified group
Business analysts MUST verify
whether specified behavior or
property really applies to all
objects grouped through
quantifiers

Incompletely specified conditions
Conditions are usually
associated with words such
as
• If... then
• In case
• Whether
• Depending onThis document is a partial preview. Full document download can be found on Flevy:

Incompletely specified conditions
In this example, at least
one aspect remains
unspecified: “Which
programs shall be offered
to graduates or lower”?

Incompletely specified process verbs
For example, verb
“Communicate” requires
at least three aspects for
completeness: “What is
being Communicated,
Who is communicating
and to whom it is being
Communicated”

Determine suitable elicitation techniques
Purpose: Determine suitable elicitation techniques to elicit requirements
Stakeholders: Product owner, Scrum team, Regulator, Supplier
Inputs Elements Outputs
1. Requirements
context
2. System scope
1. Understand different types of
requirements to be elicited
2. Determine suitable
requirements techniques to
elicit requirements
1. Identified
elicitation
techniques
Tools and Techniques: Brainstorming, Elicitation techniques chart

Real life example:
Type of
meeting
Focus of
workshop
Participants Date Time Status
Workshop Stakeholder
commitment
Dave Richards
Mike Dent
Dinesh Pandey
Lee Fung
Adi Gururaj
Iqbal Mohammed
Pieter Bisemans
John Munyan
Rebecca Randad
17-Mar 10:00 AM
to 12:00
Noon

Elicit requirements
Purpose: To elicit information from stakeholders regarding their needs
Stakeholders: Product owner, Domain SME, Customer, End user, Supplier,
and Regulator
1. Solution scope
2. Requirements
Template
3. Scheduled resources
4. Supporting materials
1. Ensure requirements
expressed are aligned
to solution scope
2. Capture requirement
attributes
1. Confirmed
requirements
Tools and Techniques: Interview, Observation, Requirements workshop,
Survey/Questionnaire

Real life example:
Mike: Thanks Michelle
Yes indeed this is a very
good news for our
organization
I hope you are enjoying
your work in our
organizationThis document is a partial preview. Full document download can be found on Flevy:

Real life example:
In this regard, I would
like to discuss and
collect business
requirements for the
system
Mike: Sure Michelle, go
ahead

Real life example:
We had 40 active projects
3 years back and now we
have 120+ active projects
In next 3 years, we may
have 200+ active projects

Real life example:
Mike: That’s fine
Michelle: Would we like
the GRC system to be
deployed to our main
development center in
Seattle or to all
development centers
world-wide?This document is a partial preview. Full document download can be found on Flevy:

Real life example:
Mike: Although senior
management will be the
primary stakeholders of the
system, everyone in the
organization will be using
the system

Real life example:
Michelle: Thanks for this
information Mike
Since we are deploying
the system world-wide, do
you expect the system to
support multiple
languages and currencies?

Real life example:
Michelle: What are the
platforms and browsers
would you like this system
to support?
On the end user front, we
expect it to support 4 most
popular browsers, IE,
Chrome, Fire-fox and OperaThis document is a partial preview. Full document download can be found on Flevy:

Real life example:
Michelle: What are your
key requirements from
the GRC system?
Mike: Let me explain my
roles for the organization

Real life example:
Michelle: What are the
challenges that we face in
the current process?
Mike: Challenges are many
We spend significant effort
in collecting and
consolidating the data

Real life example:
Mike: Senior management
would like to have a visual
dashboard about revenue
projection and project
health of all projects in the
organization
We would like to have color
coded indicators with
ability to drill down

Real life example:
Michelle: Will do that Mike
Let me make a note of that
Would you like to describe
any other critical feature
from your perspective?

Document elicitation results
Purpose: To record the information provided by stakeholders for
use in analysis
Stakeholders: Business analyst
1. Elicitation
results
1. Minutes of meeting
2. Visual or audio recordings
3. Whiteboards
1. Stated
requirements
2. Stakeholder
concerns
Tools and Techniques: Brainstorming, Document analysis, Focus
group, Interface analysis, Interview, Problem tracking, Observation,
Prototyping, Requirements workshop, and Survey/Questionnaire

Real-life example : Requirements
Requirements Provider Priority
Assist in monitoring health of client
relationships and project’s health
CDO High
Provide visual dashboard about revenue
projection and project health of all
projects in the organization. Dashboards
shall have color coded indicators with
ability to drill down
CDO High

Real-life example : Confirmed
requirements
Requirements Priority Status
The system must assist senior management
to monitor project performances
High Confirmed
The system must support world-wide
deployment
High Confirmed
Capture effort and attendance High Confirmed
Support up to 100000 users High Confirmed
Must support multiple currencies High Confirmed

1
Flevy (www.flevy.com) is the marketplace
for premium documents. These
documents can range from Business
Frameworks to Financial Models to
PowerPoint Templates.
Flevy was founded under the principle that
companies waste a lot of time and money
recreating the same foundational business
documents. Our vision is for Flevy to
become a comprehensive knowledge base
of business documents. All organizations,
from startups to large enterprises, can use
Flevy— whether it's to jumpstart projects, to
find reference or comparison materials, or
just to learn.
Contact Us
Please contact us with any questions you may have
about our company.
• General Inquiries
support@flevy.com
• Media/PR
press@flevy.com
• Billing
billing@flevy.com

Agile Module 5: Elicit Requirements

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (9)

More from Flevy.com Best Practices

More from Flevy.com Best Practices (20)

Recently uploaded

Recently uploaded (20)

Agile Module 5: Elicit Requirements