The document discusses requirements elicitation techniques used in business analysis. It defines requirements elicitation as actively engaging stakeholders to understand their needs rather than just gathering requirements. The document outlines key techniques for each stage of the requirements elicitation process: prepare for elicitation, conduct elicitation, document elicitation results, and confirm elicitation results. Common individual and group techniques are described such as interviews, observation, brainstorming, prototyping and interface analysis.

1. A Guide to the Business Analysis Body of Knowledge (BABoK®) – Knowledge Area
Requirements Elicitation
By – Amjad Shaikh

2. Enterprise
Analysis
Business Analysis
Planning &
Monitoring
Requirements
Elicitation
Requirements
Analysis
Solution
Assessment &
Validation
Underlying
Competency
Requirements
Management &
Communication
Techniques
Concepts
(BABoK)
BABoK®Version2Release2009

3. a recap…
 A condition or capability needed by a stakeholder to solve a problem
or achieve an objective
 A condition or capability that must be met or possessed by a system
or system component to satisfy a contract, standard specification or
other formally imposed document
 A documented representation of a condition or capability as in 1 or 2
above
Requirement
Business Requirement
Stakeholder Requirement
Solution Requirement
Transition Requirement
Classification of Requirement
Functional Requirement
Non-Functional Requirement

4. a classic…

6. Requirements Gathering
Vs.
Requirements Elicitation

7. Going beyond just gathering
Active engagement of stakeholders to
identify and understand their needs and the
environment in which they work
WHAT?
Business Analyst &
Stakeholders
WHO?
To ensure that a stakeholders actual or
underlying needs are understood, rather
than their stated or superficial desires
WHY?
Iterative throughout elicitation, analysis,
verification and validation activities
WHEN?

8. TASKS

9. Prepare For Elicitation

10. The Purpose of the task
Ensure all needed resources are
organized and scheduled for
conducting the elicitation activities

11. Layout of the task
 Business Need
Business Scope
 Business Case
 Stakeholders List, Roles &
Responsibilities
Input
Prepare for Elicitation
Task
 Scheduled Resources
 Support Material
Output
Techniques
 Brainstorming
 Document Analysis
 Focus Groups
Interface Analysis
 Interviews
Observation
Prototyping
 Requirements Workshops
 Survey/Questionnaire
Stakeholders
All Stakeholders Project Manager

12. Key Elements

13. Level of details that should be considered
Resources
Ground Rules
 People
 Facilities
 Equipment
 For event-based elicitation
(brainstorming, focus group, interview,
observation, prototyping, requirements
workshop) ground rules must be
established
Inform
 Notify
appropriate
parties of the
plan
Process
 Agree on form and frequency of feedback
during the elicitation process and the
mechanism for verifying and signing off on
the elicited results or at the beginning or
during one specific phase

14. Conduct Elicitation

15. The Purpose of the task
Meet with stakeholder(s) to elicit
information regarding their needs

16. Layout of the task
 Business Need
 Organizational Process Assets
 Requirement Management Plan
 Scheduled Resources
 Solution Scope
 Business Case
 Supporting Materials
Input
Conduct Elicitation Activity
Task
Elicitation Results
Output
Techniques
 Brainstorming
 Document Analysis
 Focus Groups
 Interface Analysis
 Interviews
Observation
Prototyping
 Requirements Workshops
 Survey/Questionnaire
Stakeholders
All Stakeholders Project Manager

17. Key Elements

18. Level of details that should be considered
 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
Tracking
 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
Attributes
 Tracking the
elicitation participants
and the actual time
spent eliciting the
requirements
provides a basis for
future planning
Metrics

19. Document Elicitation Results

20. The Purpose of the task
Record the information provided by
stakeholders for use in analysis

21. Layout of the task
Elicitation Results
Input
Document Elicitation
Results
Task
 Requirement [Stated]
 Stakeholder Concerns
Output
Techniques
 Brainstorming
 Document Analysis
 Focus Groups
 Interface Analysis
 Interviews
Observation
Prototyping
 Requirements Workshops
 Survey/Questionnaire
Stakeholders
Business Analyst

22. Key Elements

23. Level of details that should be considered
 Documentation can take a
number of forms
 Minutes of meeting (MOM)
 Visual or audio recordings
 Whiteboards
 Notes
Output Form
The form of output
depends upon the
technique used for
elicitation

24. Confirm Elicitation Results

25. The Purpose of the task
Validate that the stated requirements
expressed by the stakeholder match
the stakeholder’s understanding of the
problem and the stakeholder’s needs

26. Layout of the task
Requirement [Stated,
Unconfirmed]
 Stakeholder Concerns
[Unconfirmed]
Input
Confirm Elicitation
Results
Task
 Requirement [Stated,
Confirmed]
 Stakeholder Concerns
[Confirmed]
Output
Techniques
 Brainstorming
 Document Analysis
 Focus Groups
 Interface Analysis
 Interviews
Observation
Prototyping
 Requirements Workshops
 Survey/Questionnaire
Stakeholders
All Stakeholders

27. The complete picture
 Clarify scope.
 Schedule
activities,
resources and
dates.
 Publish the
plan.
Prepare
 Meet with
stakeholders
to elicit
requirements
 Capture
requirements
attribute &
trace
requirements
Conduct
 Summarize
output from
elicitation
Document
 Review the
outcome with
stakeholders
& confirm
Confirm

28. Key Techniques

29. What impacts the choice of tools & techniques
Consider stakeholder needs when making
decisions about tools or techniques
Stakeholder
To ensure that a stakeholders actual or underlying needs are understood, rather
than their stated or superficial desires
Skills of Business
Analyst Involved
Conflicts Rely on ground rules when conflicts arise

30. Some widely used techniques
Group Techniques
One on One
 Interview
 Observation
Collaborative Sessions
 Brainstorming
 Focus Group
 Requirements Workshop
Interface
 Prototyping
 Interface Analysis
Document Based
 Document Analysis
 Surveys / Questionnaire

31. Structured Interview – Interview that
has defined set of questions, agenda &
execution pattern
Unstructured Interview – Interview
which is free-flow and progression is
based on information surfacing within
the process of interview
Types of Interview
Closed Ended – Questions that results
into objective responses (provide
options for responses)
Open Ended – Questions that results
into subjective responses
Types of Questions
Interview techniques is the process of interacting with individual stakeholder to
understand their need/s and perspective about the change/project
Positive Negative Cannot be used where there is a need to build
consensus across a group of stakeholders
Interview techniques allows Business Analyst
to confirm understanding by asking follow-up
questions

32. Example from Web
 BA: Why should the submit button be red?
 Client: Because we really want the user to press it?
 BA: Why do you think that the user will press it if it's red?
 Client: Because it will stand out on the page?
 BA: What if the user is color blind?
 Client: Hmm... I didn't think of that! Let's just make the text bold?
 BA: (thinking: we are getting nowhere) Why is it so important that the user clicks the submit
button?
 Client: Because currently it does important things and some users don't click it.
 BA: What is so important?
 Client: (getting annoyed, of course): Because it has logic which submits the new lead to the
marketing department which provides us lots of value. Many users click the cancel button by
mistake.
 BA: (a-ha) So the problem is that when the user clicks the cancel button my mistake they lose
their data right away and they probably don't want to re-enter all the info.
 Client: Exactly! Now can we just make the button bold!
 BA: What if we put a message box when clicking the "Cancel" button which asks the user
something like "Are you sure you want to cancel and lose all the data you just entered?"
 Client: Wow... that would be great!

33. Passive or invisible – Observe
stakeholder without interruption to
there work
Active or visible – Observe with active
feedback & questions
Study the stakeholder performing their job in order to
document details about the current process
Positive Negative Suitable for AS-IS process only without
identify infrequent exceptions
Can provide you un-documented process
(Tacit knowledge)
Shadowing – Learning via observation
Apprenticing – Learning via
participating on job
Types of Observations

34. Using the creative powers of a group to generate many ideas quickly to help solve a problem or
resolve an issue. Ideas generated need to undergo additional evaluation and analysis.
Feature of Brainstorming
 Time limit and criteria for evaluating and
rating the ideas is established in advance.
 Do not debate the ideas during the
brainstorming session.
 Produce as many ideas as possible within time
limit.
 Typically last 20 minutes.
 Variation is anonymous brainstorming.

35. Visual representation of user interface
 Horizontal prototype – covers a wide but
shallow view of functionality.
 Vertical prototype – covers a narrow but deep
view of functionality.
 Throw away prototype – uses simple tools e.g.
whiteboard.
 Evolutionary prototype – produces running
software which will emerge as the actual
system further downstream
Types of Prototyping

36. Study of the connection between components of a solution, generally system to system
or hardware to hardware interfaces
Fundamentals of Interface Analysis
 Identify system boundaries
 Identify dependencies within system
 Identify the inputs & outputs
transactions
 Identify key data elements

37. Example
Health Plan Management
System
Consumer Portal Application
Consumer Requests
Plan Information
Provider CRM
Appointment Scheduling
Content Format and Subject Area [Content Format]
Message - ID Description Content format Subject Areas
Message-1 Plan Information Web Services Benefits
Message-2 Appointments Schedule Web Services Scheduling

40. BABoK®Version2Release2009
BABOK V2 - Business Analysis Knowledge Areas & Tasks Layout
[2] Business Analysis
Planning & Monitoring
[3] Elicitation
[4] Requirements
Management &
Communication
[5] Enterprise Analysis
[6] Requirement
Analysis
[7] Solution
Assessment &
Validation
[2.1] Plan Business
Analysis Approach
[3.1] Prepare for
Elicitation
[4.1] Manage Solution
Scope and Requirements
[5.1] Define Business Need
[6.1] Prioritize
Requirements
[7.1] Assess Proposed
Solution
[2.2] Conduct Stakeholder
Analysis
[3.2] Conduct Elicitation
Activity
[4.2] Manage
Requirement Traceability
[5.2] Assess Capability Gap
[6.2] Organize
Requirements
[7.2] Allocate
Requirements
[2.3] Plan Business
Analysis Activities
[3.3] Document Elicitation
Results
[4.3] Maintain
Requirement for Re
[5.3] Determine Solution
Approach
[6.3] Specify and Model
Requirements
[7.3] Assess Organization
Readiness
[2.4] Plan Business
Analysis Communication
[4.4] Prepare Requirement
Package
[5.4] Define Solution Scope
[6.4] Define Assumptions
& Constraints
[7.4] Define Transition
Requirements
[2.5] Plan Requirement
Management Process
[4.5] Communicate
Requirements
[5.5] Define Business Case [6.5] Verify Requirements [7.5] Validate Solution
[2.6] Manage Business
Analysis Performance
[6.6] Validate
Requirements
[7.6] Evaluate Solution
Performance
[3.4] Confirm Elicitation
Results