1.
BABOK
Study
Group
Meeting 4. Elicitation
http://zubkiewicz.com 1
Paweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2
pawel@zubkiewicz.com

2.
Elicitation?
The definition of elicitation is1:
• to draw forth or bring out (something latent or potential) .
• to call forth or draw out (as information or a response).
These definitions highlight the need to actively engage the
stakeholders in defining requirements.
3/9/2016http://zubkiewicz.com 2

3.
Elicitation tasks
3/9/2016http://zubkiewicz.com 3

4.
BABOK – Knowledge Areas &
Tasks
3/9/2016http://zubkiewicz.com
Source: www.projerra.ca
5.4 Define
Solution Scope
4

5.
3 – Elicitation
3/9/2016Paweł Zubkiewicz 5
Task Name Inputs Elements Techniques Stakeholders Outputs
3.1 Prepare For
Elicitation
Ensure all needed
resources are organized
and scheduled for
conducting the elicitation
activities.
Business Case (5.5)
Business Need (5.1)
Solution Scope (5.4)
Stakeholder List, Roles, and
Responsibilities (2.2)
Implicit Input:
BA plan(s) (2.3)
 Clarify the scope for
selected elicitation
technique
 Schedule all resources
(people, facilities,
equipment)
 Notify appropriate
parties
General:
Brainstorming (9.3)
Document Analysis (9.9)
Focus Groups (9.11)
Interface Analysis (9.13)
Interviews (9.14)
Observation (9.18)
Prototyping (9.22)
Requirements Workshops (9.23)
Survey / Questionnaire (9.31)
All stakeholders
Project Manger
Scheduled Resources (3.1)
Supporting Materials (3.1)
Implicit Output:
BA perf metrics
3.2 Conduct Elicitation
Activity
Meet with stakeholder(s)
to elicit information
regarding their needs.
Business Need (5.1)
Solution Scope (5.4)
Business Case (5.5)
Requirements Management
Plan (2.5)
Scheduled Resources (3.1)
Supporting Materials (3.1)
OPAs
Implicit Input:
BA plan(s) (2.3)
Tracing requirements
Capturing requirements
attributes
Metrics
Essential:
Data Dictionary and Glossary (9.5)
General:
Brainstorming (9.3)
Document Analysis (9.9)
Focus Groups (9.11)
Interface Analysis (9.13)
Interviews (9.14)
Observation (9.18)
Prototyping (9.22)
Requirements Workshop (9.23)
Survey / Questionnaire (9.31)
Customer
Domain SME
End User
Supplier
Sponsor
Implementation
SME
Operational
Support
Project Manger
Supplier
Tester
Regulator
Elicitation Results (3.2)
Implicit Output:
BA perf metrics
3.3 Document Elicitation
Results
Record the information
provided by stakeholders
for use in analysis.
Elicitation results (3.2)
Implicit Input:
BA plan(s) (2.3)
Documentation:
 Written docs
 Visual or recordings
 Whiteboards
General:
Brainstorming (9.3)
Document Analysis (9.9)
Focus Groups (9.11)
Interface Analysis (9.13)
Interviews (9.14)
Observation (9.18)
Problem Tracking (9.20)
Prototyping (9.22)
Requirements Workshops (9.23)
Survey / Questionnaire (9.31)
Business Analyst Requirements [Stated] (3.3)
Stakeholder Concerns (3.3)
Implicit Output:
BA perf metrics
3.4 Confirm Elicitation
Results
Validate that the stated
requirements expressed
by the stakeholder match
the stakeholder’s
understanding of the
problem and the
stakeholder’s needs.
Requirements [Stated,
Unconfirmed] (3.3)
Stakeholder Concerns
[Unconfirmed] (3.3)
Implicit Input:
BA plan(s) (2.3)
General:
Interviews (9.14)
Observation (9.18)
Any stakeholder
who has
participated in
other elicitation
tasks
Requirements [Stated &
Confirmed] (3.4)
Stakeholder Concerns
[Confirmed] (3.4)
Implicit Output:
BA perf metrics

6.
3/9/2016http://zubkiewicz.com 6
Source: Modern Analyst

7.
3.1 Prepare for Elicitation
Elements
• Clarify the specific scope for
the selected elicitation
technique and gathers any
necessary supporting
materials.
• Schedule all resources
(people, facilities, equipment)
• Notify appropriate parties of
the plan
3/9/2016http://zubkiewicz.com 7
Outputs
• Scheduled Resources: This
includes the participants, the
location in which the elicitation
activity will occur, and any
other resources that may be
required.
• Supporting Materials: Any
materials required to help
explain the techniques used or
perform them.
Ensure all needed resources are organized and scheduled for conducting the
elicitation activities.

8.
3.2 Conduct Elicitation Activity
Elements
• Tracing requirements: While eliciting the
requirements it is important to guard against
scope creep. Tracing requirements back to the
business goals/objectives helps to validate
whether a requirement should be included.
• Capturing requirement attributes: While
eliciting the requirements documenting
requirements attributes such as the
requirement’s source, value and priority will aid in
managing each requirement throughout its life
cycle.
• Metrics: Tracking the elicitation participants and
the actual time spent eliciting the requirements
provides a basis for future planning.
3/9/2016Paweł Zubkiewicz 8
Outputs
• Elicitation Results: May
include documentation
appropriate to the
technique and capture the
information provided by the
stakeholder.
Meet with stakeholder(s) to elicit information regarding their needs.

9.
3.3 Document Elicitation Results
Elements
Documentation can take a number of
forms, including:
• Written documents describing
the outcomes, such as meeting
minutes
• Visual or audio recordings
• Whiteboards (either actual or
virtual) where notes are retained
until they are transferred to
another medium.
3/9/2016Paweł Zubkiewicz 9
Outputs
• Requirements [Stated]:
Described from the perspective
of the stakeholder. Stated
requirements describe the
stakeholder’s need from the
stakeholder’s perspective.
• Stakeholder Concerns:
Includes issues identified by the
stakeholder, risks, assumptions,
constraints, and other relevant
information.
Record the information provided by stakeholders for use in analysis

10.
3.4 Confirm Elicitation Results
Techniques:
• 9.14 Interviews
• 9.18 Observation
3/9/2016Paweł Zubkiewicz 10
Output
• Requirements [Stated,
Confirmed]: Identical to
Requirements [Stated] for all
practical purposes, including use
as an input to other tasks.
• Stakeholder Concerns
[Confirmed]: Identical to
Stakeholder Concerns for all
practical purposes, including use
as an input to other tasks.
Validate that the stated requirements expressed by the stakeholder match the
stakeholder’s understanding of the problem and the stakeholder’s needs.

11.
3/9/2016http://zubkiewicz.com 11
Source: Modern Analyst

12.
Techniques
3/9/2016Paweł Zubkiewicz 12

13.
Tasks as Techniques elements
TASK Technique meta-
steps
9.11 Focus Group 9.31 Survey /
Questionnairy
Prepare for
Elicitation
Prepare 1. Preparation 1. Prepare
Conduct
Elicitation
Activity
Conduct 2. Run The Focus
Group Session
2. Distribute The
Survey
Document
Elicitation Results
Wrap-up 3. Produce Report 3. Document
Survey Results
3/9/2016http://zubkiewicz.com 13

14.
Techniques lists
Prepare
for
Elicitation
Conduct
Elicitation
Activity
Document
Elicitation
Results
Confirm
Elicitation
Results
1. Brainstorming
2. Document
Analysis
3. Focus Groups
4. Interface Analysis
5. Interviews
6. Observation
7. Prototyping
8. Requirements
Workshops
9. Survey /
Questionnaire
1. Brainstorming
2. Document
Analysis
3. Focus Groups
4. Interface Analysis
5. Interviews
6. Observation
7. Prototyping
8. Requirements
Workshops
9. Survey /
Questionnaire
10. Data Dictionary
and Glossary
1. Brainstorming
2. Document
Analysis
3. Focus Groups
4. Interface Analysis
5. Interviews
6. Observation
7. Prototyping
8. Requirements
Workshops
9. Survey /
Questionnaire
10. Problem
Tracking
1. Interviews
2. Observation
3/9/2016http://zubkiewicz.com 14

15.
Techniques synonyms
3/9/2016http://zubkiewicz.com 15

16.
Techniques types
• The BABOK ® Guide lists three types of elicitation
techniques: events, performed work, and collected work
• Elicitation events take place using one of six techniques:
brainstorming, focus groups, interviews, observation,
prototyping, and requirements workshops.
• Elicitation work is performed by the business analyst using
the document analysis or interface analysis technique.
• Elicitation work is distributed and collected using
surveys/questionnaires that are sent out to the stakeholders.
3/9/2016http://zubkiewicz.com 16

17.
Question types
• Open – ended
• Closed - ended
3/9/2016http://zubkiewicz.com 17
• Meta
• Directive
• Detailed
• Research

18.
Question types
• These are general questions inviting your stakeholders to provide you with information about their
concerns, interests, and needs relative to the solution scope. Research questions allow a skilled
business analyst to scope out the stakeholder needs. People are comfortable answering research
questions when the questions are not limited or specific and the answers are not controlled in any way. An
example of a research question might be, What constitutes success for this project?
Research Questions
• Detailed questions focus on gathering specific information within the predefined solution scope. These
questions are typically the step after research questions and help the business analyst focus on more
specific information that is needed. To be thorough, detailed questions should be framed around the five
W’s: who, what, where, when, and why. As your questions become more specific, it is very important to
discourage one - word answers, such as yes and no. This can often be achieved in the phrasing of each
question. An example of a detailed question is, Who provides you with this information?
Detailed Questions
• Directive questions are used primarily by business analysts in group settings where there are contradictions
in what the business analyst has been told. Directive questions direct the other parties to an area
where agreement needs to be reached and sometimes away from an area that is contentious. For project
requirements information, these questions can be used to get consensus on specific features and
functionality and to encourage stakeholder decision making. One example of a directive question might be,
What is the relative priority of this key feature?
Directive Questions
• Meta questions are powerful tools. They allow you to clarify and enhance what has just been said.
Basically, meta questions are questions about questions. This communications strategy allows the
business analyst to promote open communication in a nonthreatening way. Meta questions clarify and
summarize what the business analyst has been told. They are an active listening technique that proves that
the business analyst has really been listening to what a particular stakeholder is saying during
requirements elicitation. An example of a meta question is, “ Do you mind if I ask you about . . . ? ”
Meta Questions
3/9/2016http://zubkiewicz.com 18
Open/CloseOpen/Close

19.
Prototypes (9.22 Prototyping)
SDLC Prototypes
• Throw-away
prototype seeks to quickly uncover and
clarify interface requirements using simple
tools, sometimes just paper and pencil. As the
name suggests, such a prototype is usually
discarded when the final system has been
developed. The focus is on functionality that
is not easily elicited by other techniques, has
conflicting viewpoints, or is difficult to
understand.
• Evolutionary (or Functional)
extends the initial interface requirements into
a fully functioning system and requires a
specialized prototyping tool or language. This
prototype produces a working software
application
3/9/2016http://zubkiewicz.com 19
Functional scope Prototypes
• Horizontal
• Vertical

20.
Did you enjoy the presentation?
Do you have any questions?
Or maybe you just want to say "thanks"
Just click the pic above to visit my blog http://zubkiewicz.com
http://zubkiewicz.com 20