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
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?
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
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
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
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
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
38.
39.
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