Iiba cbap

1© 2020 SpectraMind
CBAP®
Certified Business Analysis Professional™

Business
Architecture &
Systems
Design
Project Management,
Management
& Leadership
Computer Software
Business &
Corporate
Web, Marketing,
PR &Social
Legal, Finance &
Accounting
Workplace
Requirements
Technical &
Programming
o World Class Training Solutions
o Subject Matter Experts
o Highest Quality Training Material
o Accelerated Learning Techniques
o Project, Programme and Change Management,
ITIL Consultancy
o Bespoke tailor made training solutions
o PRINCE2®, MSP®, Change Management,
ITIL and Soft skills and more
About SpectraMind

o Trainer
o Fire Procedures
o Facilities
o Days/Times
o Breaks
o Special Needs
o Delegate ID check
o Phones & Mobile devices
Administration

Section 1: Business Analysis Planning and Monitoring
Section 2: Elicitation and Collaboration
Section 3: Requirements Life Cycle Management
Section 4: Strategy Analysis
Section 5: Requirements Analysis and Design Definition
Section 6: Solution Evaluation
Syllabus

Section 1: Business Analysis
Planning and Monitoring
1.1 Plan Business Analysis Approach
1.2 Plan Stakeholder Engagement
1.3 Plan Business Analysis Governance
1.4 Plan Business Analysis Information Management
1.5 Identify Business Analysis Performance Improvements

The word “requirements” brings to mind the image of Mr. Potato Head.
There are a group of pieces and multiple number of ways to put the pieces together
Built without
approach
Built with
approach

In absence of a concrete plan, there can be:
Requirements development also works on the same principle
As there are multiple ways of putting the pieces of requirements and information together, one
needs to plan a systematic APPROACH to develop a product with specifications
• No commitment of purpose from
the team
• No communication of a clear vision
to the team

Business Analysis
Planning and
Monitoring
Strategy Analysis
Requirements
Analysis and Design
Definition
Solution Evaluation
Elicitation and
Collaboration
Requirements
Lifecycle
Management

Business Analysis Planning and Monitoring Input / Output figure
INPUTS
•Needs
•Internal Objectives
•External Objectives
TASKS
•Plan Business Analysis
Approach
•Plan Stakeholder
Engagement
Governance
Information Management
•Identify Business Analysis
Performance
Improvements
OUTPUT
•Business Analysis
Approach
•Stakeholder Engagement
Approach
•Governance Approach
•Information
Management Approach
Performance Assessment

Tasks under Business Analysis
Planning and Monitoring
Plan Business
Analysis
Approach
Plan
Stakeholder
Engagement
Plan Business
Analysis
Governance
Plan Business
Analysis
Information
Management
Identify
Business
Analysis
Performance
Improvements

Business Analysis approach describes:
 Overall method to be followed for performing business analysis activities
 Instructions and considerations for planning a project solution
 Agreed plan to achieve the outcome
Identify Deliverables
Purpose

Plan Business Analysis Approach Input / Output figure
INPUTS
• Business Needs
TASKS
•Plan Business
Analysis Approach
OUTPUT
Approach
Problems or opportunities faced by the
organization define the “why” of an
action
This “why” component helps in
shaping the Business analysis approach
Identifies activities that will be
performed, who will perform the
activities, the schedule of work, the
deliverables that will be produced and
the business analysis methods and
techniques that may be used

INPUTS
•Business Needs
TASKS
•Plan Business
Analysis Approach
OUTPUT
Approach
Guidelines and Tools
Business
Analysis
Performance
Assessment
Business
Policies
Expert
Judgment
Methodologies
and Framework
Stakeholder
Engagement
Approach

INPUTS
•Business Needs
TASKS
•Plan Business
Analysis Approach
OUTPUT
Approach
Tasks using this output
Plan
Stakeholder
Engagement
Plan
Business
Analysis
Governance
Plan Business
Analysis
Information
Management
Identify Business
Analysis
Performance
Improvements
Prepare
for
elicitation
Conduct
elicitation
Communicate
Business
Analysis
Information
Manage
Stakeholder
Collaboration
Analyze
Current State
Define
Change
Strategy
Assess Risks

Planning Business Analysis approach seeks answers to the following questions:
Description
What is the scope
of work?
• Identify all that needs to be done and outline tasks and associated
deliverables
What
methodology is
to be used?
• It determines the project activities and the sequence of execution
• Plan-driven approach implies completing analysis before commencing
development
• Change-driven approach implies developing and clarifying requirements
as the project progresses
Who are the
stakeholders?
• These are people forming a part of the team that creates and validates
deliverables created by Business Analyst
• They need to be considered in the plan by outlining their roles and
responsibilities along with time commitment required from them

1.1 Plan Business Analysis Approach contd.
Description contd.
What is the
schedule?
• Each task to be completed needs to be time estimated
• Determine the priority of tasks considering the time estimation for task
completion
How will
requirements be
managed?
• Constructing an approach for tracking and prioritizing requirements
• Planning for getting the requirements approved during the course of the
project
What all
deliverables to
be created?
• The main outcome of business analysis effort is a set of deliverables that
lead to customer's needs being met
• Examples of business analysis deliverables include Functional
Requirements Document, Requirement Specification Documents,
Business Case, Process Models, Use Case , Data Models

Description contd.
How will
communication
be handled?
• Business Analysis Plan should indicate how the business analyst shall
receive, access and distribute information
• Who, What, Why, Where and How of communication should be planned
How work will be
assessed?
• Set of metrics are defined for assessing the effort of business analyst
• Primarily, assessment is made by identifying how quickly and successfully
the work was completed

Elements: What BA needs to do here?
Mainly Plan-Driven, with
focus on minimizing
upfront risk & uncertainty
and maximizing control
End solution is defined
before implementation
Waterfall methodologies
Predictive Mainly Change-Driven, with
focus on exploring and
delivering business value
rapidly in short iterations
End solution progresses
towards incremental
improvements
Agile methodologies
Adaptive
Pick a Planning Approach

Understand and Pick a Planning Approach
Predictive Adaptive
Formality &
detail of
deliverables
Formality and detail Prioritized list of requirements
Tasks are performed in specific
phases – elicitation, analysis,
documentation, verification and
communication
Tasks are performed iteratively based
on prioritizing and reprioritizing high
level requirements
Timing of
BA work
Identify activities required to
complete deliverables and then
divide them into tasks
Work is divided into iterations,
deliverables are identified for each
iteration and then associated tasks
are determined
Business
Analysis
activities

Depends on factors like:
• Number of stakeholders
• Number of business areas affected
• Amount and nature of risk
• Type of requirements
• Resource requirement
Business analysis approach is required to be reviewed and signed off by
the key stakeholders
Acceptance
Complexity
and Risk

Agile Principles compared to Waterfall
Key Agile Principles Traditional Waterfall ideology
Highest value tops the priority list
Project vision is aligned to deliver high priority Business needs
first. Better quality products are delivered faster and cheaper
All or nothing
Aims at building and delivering all features of the project at once.
Complete product is delivered and nothing can be delivered in
isolation
Responding to Change
Team learns to acknowledge uncertainty.
Embraces both internal and external changes by modifying plans
and approach
Baseline and Change Control
Sticks to initial plans and makes no scope changes. Constrain on
modifying or eliminating features
Iterative
Working software are delivered regularly in short time frames to
the customer. Quality of deliverables refines over time
Phased
Project execution occurs in fixed long phases
Feedback and Continuous Improvement
Continuous feedback loops to inform plans and modify approach.
This aids continuous improvement
Lessons learned in the end
Feedback is rarely given during the development cycle so that it
may be used towards improving processes
Small but Integrated Teams
Communication gets simplified and better in a small team
Self discipline and flexibility is created
Silo Teams
Team works per functionality oriented groups

AGILE
1. Scrum 2. Extreme Programming (XP)
3. Dynamic Systems Development Method (DSDM) 4. Kanban
Various Agile methods for Project Management

Extreme Programming
• CODING: Writing effective codes is the top priority. Product changes are introduced in
increments: small releases once per three weeks instead of one big release in a year
• TESTING: Chances of eliminating flaws increases with the level of testing performed:
- Unit Tests: These are written before programming the code, with the purpose to confirm
the validity of each piece of code written
- Acceptance tests: To validate that the code satisfies the customer’s product requirements
- Integration tests: To detect interaction flaws of software modules
• FEEDBACK: Understanding the user needs better by taking regular feedback from the
business and encouraging discussion between the development and business team. This is
enabled by making available the minimal viable system into production quickly and then
growing it further in the most valuable direction in subsequent iterations based on
feedback
• DESIGNING: Projects are started with simple design which evolve constantly by adding
required flexibility and removing unnecessary complexity
Fundamentals

Dynamic Systems Development Method (DSDM) framework

KANBAN
Kanban Board is a physical or virtual board that is used for work visualization, optimizing the work flow
among team members and identifying all hurdles and obstacles in order to resolve them immediately
Virtual Kanban boards aid in tracing work, easy collaboration and accessibility from multiple locations
Kanban Board has a three step process:
• To Do
• In Progress
• Done
It relies on:
• Transparency of work
• Real time communication of capacity
Kanban cards in the form of sticky notes are used to display critical information about that particular
work item, giving visibility to entire team regarding:
 who is working on which work item
 Brief description of job being done
 Estimated time to complete the particular task

Kanban Board illustration

Brainstorming Business Cases
Document
Analysis
Estimation
Financial
Analysis
Functional
Decomposition
Interviews Item Tracking
Lessons
Learned
Process
Modelling
Reviews
Risk Analysis
and
Management
Scope
Modelling
Survey or
Questionnaire
Workshops
Techniques

Domain Subject Matter Expert
Project Manager
Regulator
Sponsor
Stakeholders

1.2 Stakeholder Engagement
INPUTS
•Business Needs
Approach
TASKS
•Plan Stakeholder
Engagement
OUTPUT
•Stakeholder
Engagement
Approach
Business Analysis
Performance
Assessment
Change
Strategy
Current
State
Description

1.2 Stakeholder Engagement
INPUTS
•Business Needs
Approach
TASKS
•Plan Stakeholder
Engagement
OUTPUT
•Stakeholder
Engagement
Approach
Plan
Business
Analysis
Governance
Plan Business
Analysis
Information
Management
Prepare
for
elicitation
Conduct
elicitation
Communicate
Business
Analysis
Information
Manage
Stakeholder
Collaboration
Define
Change
Strategy
Assess Risks

1.2 Stakeholder Engagement contd.
Purpose
 Process used by an organization to engage relevant stakeholders to achieve a common
purpose of accepted outcomes
 Following characteristics need to be analyzed to list the relevant stakeholders:
• Decision Making Authority
• Level of Power or Influence
Description
• Thorough stakeholder analysis is conducted to identify all the involved stakeholders and their
respective characteristics
• Analysis results help in planning for collaboration, communication and stakeholder risks

1. Conduct Stakeholder Analysis
• A systematic way to analyze stakeholders based on their power to influence and interest
• Key players are characterized as High power, high interest
• Least important have Low power and low interest
Understanding who all stakeholders are helps in knowing
the impact proposed changes have on them, and the
influence they may have on the change.
Not knowing about the relevant stakeholders can lead to
missing critical needs, wants, and expectations that must
be satisfied by a solution

1.2 Stakeholder Engagement contd.PowerofInfluenceofstakeholders
Interest of stakeholders
After mapping the interests of
the stakeholders, they need to
be prioritized in order of
importance
High Influence
Low Interest
Low Influence
Low Interest
Low Influence
High Interest
High Influence
High Interest
Power and Interest matrix

1.2 Stakeholder Engagement contd.PowerofInfluenceofstakeholders
Interest of stakeholders

RACI Matrix – Stakeholder Analysis
It is used for categorizing stakeholder’s roles and responsibilities in context of a specific task or process
RACI is an acronym for RESPONSIBLE, ACCOUNTABLE, CONSULTED and INFORMED
RACI example

Partnership
Participation
Consultation
Push Communications
Pull Communications
High Influence
High Interest
High Influence
Low Interest
Low Influence
High Interest
Low Influence
Low Interest
2. Define Stakeholder
Engagement

Stakeholder
Engagement Approach
Description
Partnership Stakeholders share accountability and responsibility. The engagement
level is two-ways, involving joint learning, decision making and actions
Participation Stakeholders are part of the team engaged in delivering tasks. The
two-way engagement is within the area of interest and responsibility
Consultation Involvement of stakeholders is there but without any responsibility.
Two way engagement is limited till asking relevant questions from
stakeholders and obtaining an answer in return
Push Communications Engagement level is one-way. Information is broadcasted to the
stakeholders by means of e-mails, webcasts, videos etc
Pull Communications Engagement level is one-way. Information is made available through a
website or posters. Stakeholders choose whether to get engaged

3. Stakeholder Communication Needs
• What are the communication goals?
• What communication channels can be most effective?
• How frequently communication needs to be shared with stakeholders?
• Identify the key stakeholders, internal and external.
• What are the key information and messages that need to be communicated?
• How to gather stakeholder’s feedback?
• What are the expected benefits to be achieved?
• Determine the role of leaders in the communication plan
• How to measure effectiveness of communication?
Assessment can be made on the following basis:

Communication Process
1. Stakeholder
Analysis
2. Develop
Communication
Plan
Implement
Communication
Plan
4. Evaluate
communication
activities

Illustration of a Communication Plan

Illustration of Stakeholder Communication

Brainstorming
Business Rules
Analysis
Document
Analysis
Mind Mapping
Interviews
Organizational
Modelling
Lessons
Learned
Process
Modelling
Risk Analysis
and
Management
Scope
Modelling
Survey or
Questionnaire
Workshops
Techniques
Stakeholder
List, Map or
Personas

Stakeholders
Stakeholders
Customer
Domain
Subject Matter
Expert
Project
Manager
Regulator
Sponsor
Supplier

Dealing with difficult stakeholders
Dealing with human moods and possessing a tact in dealing
with them is the golden skill of a good Business Analyst
Stakeholders come in all kinds of temperaments –
From the shifty one who does not commit to any decision
One with the loudest voice in the room who seems to know it all
One who runs late for meetings or does not bother to show up
To the ones who show up but find it difficult to agree with anything that is said
The list is endless.
Getting a difficult stakeholder to see reason can be challenging but not impossible.

INPUTS
•Business Analysis Approach
Approach
TASKS
Governance
OUTPUT
Plan Business
Analysis
Information
Management
Prioritize
Requirements
Assess
Requirements
Change
Approve
Requirements

INPUTS
Approach
TASKS
Governance
OUTPUT
Business Analysis
Performance
Assessment
Current State
Description
Business
Policies
Legal /
Regulatory
Information

Purpose
Defines how decisions are made about requirements and designs. This also includes decisions
regarding reviews, prioritization, change control and approvals
Description
For proper decision making, it is crucial that a process, decision makers and required
information exists in place. This is where the governance process comes into picture and
describes how decisions regarding approvals and prioritization are made for requirements and
designs

1.3 Plan Business Analysis Governance contd.
Elements:
What BA
needs to
do here?
Decision
Making
Change
Control
Process
Plan
Priority
Approach
Plan for
Approvals

Brainstorming Item TrackingDocument
Analysis
Interviews
Organizational
Modelling
Lessons
Learned
Process
Modelling
Survey or
Questionnaire
Workshops
Techniques
Reviews

Stakeholders
Domain
Subject Matter
Expert
Project
Manager
Regulator
Sponsor

1.4 Plan Business Analysis Information
Management
INPUTS
Approach
TASKS
OUTPUT
•Information Management
Approach
Communicate
Business Analysis
Information
Maintain
Requirements
Trace
Requirements
Define
Requirements
Architecture
Business Analysis
Performance
Assessment
Information
Management Tools
Business
Policies
Legal/Regulatory
Information

Management
Purpose
To develop an approach for storing and accessing business analysis information
Description
Planning Information Management involves identifying:
• How to organize information
• At what level of detail should the information be captured
• Any relationships between the information
• How to utilize information across multiple initiatives and throughout the enterprise
• How to store and access information
• Characteristics about the information that must be maintained

Management contd.
1. Organization of Business Analysis Information
Business Analyst needs to organize information in
a structure that allows easy location of
information, does not conflict with other
information or does not create duplicate copies
This is done by considering:
• Type and amount of information collected
• Stakeholder’s access and usage needs
• Size and complexity of the information
• Relationships between the information
2. Level of Abstraction
It describes the representation of
information at different level of detail,
depending upon the needs and roles of the
stakeholder
3. Plan Traceability Approach
It is based on:
• Domain complexity
• Any requirement-related risks,
organizational standards, applicable
regulatory requirements
• An understanding of the costs and
benefits involved with tracing

Management contd.
4. Plan for Requirements Re-use
Organization can save tine, effort and cost if the
requirements can be reused. This is possible if
requirements are accessible and structured in a
way to support its reuse
Requirements with long term use potential are:
• Regulatory requirements
• Contractual obligations
• Quality standards
• Service level agreements
• Business rules
• Business processes
• Requirements describing products the
enterprise produces
5. Storage and Access
It depends on multiple factors:
• Who must access the information
• How often they need to access it
• What conditions must be present for
accessing information
6. Requirement Attributes
Allows the business analysts to associate
information with individual or related
groups of requirements

Management contd.
Brainstorming Item TrackingInterviews
Mind Mapping
Lessons
Learned
Process
Modelling
Survey or
Questionnaire
Workshops
Techniques

Management contd.
Stakeholders
Domain Subject
Matter Expert
Regulator
Sponsor

1.5 Identify Business Analysis Performance
Improvements
INPUTS
•Performance Objectives
(External)
TASKS
•Identify Business
Analysis Performance
Improvements
OUTPUT
Plan Business
Analysis Approach
Plan Business
Analysis Governance
Plan Stakeholder
Engagement
Plan Business Analysis
Organizational
Performance Standards
Manage
Stakeholder
Collaboration

Improvements
Purpose
To assess business analysis work and plan to improve processes where required
Description
To keep a check on performance and identify scope of improvement, it is necessary to:
• Establish performance measures
• Conduct performance analysis
• Report the results of analysis
• Identify preventive, corrective, developmental actions

Improvements contd.
1. Performance Analysis
Description of an effective business analysis work
depends on the context of a particular organization
Analysis reports are designed to tailor meet the
needs of reviewer types
2. Assessment Measures
• Effectiveness: whether the deliverables were
easy to use or they required extensive
explanation in order to be understood
• Organizational Support: whether there were
adequate resources available to complete
business analysis activities as needed
• Significance: Compare the benefits from the
deliverables against the cost, time, and
resource investments expended to produce the
deliverables and assess if the value delivered
was justified
• Strategic: whether business objectives were
met, problems were solved, and improvements
were achieve
• Timeliness: whether the business analyst
delivered the work on time per stakeholder
expectations and schedule
Some of the measures that may be adopted are:
• Accuracy and Completeness: whether the
deliverables were correct and relevant or
whether revisions were needed to gain
acceptance by stakeholders
• Knowledge: whether the business analyst had
the required skills, experience to perform the
assigned task

Management contd.
3. Analyze Results
Business analysis process and deliverables are
compared against the set of defined performance
measures
Following aspects are analyzed:
• Business Analysis process
• Resources involved
• Deliverables
4. Recommend Actions for Improvement
After analyzing the performance results,
business analyst engages the appropriate
stakeholders to identify the following actions:
• Preventive: reduces the probability of an
event with a negative impact
• Corrective: establishes ways to reduce the
negative impact of an event
• Improvement: establishes ways to
increase the probability or impact of
events with a positive impact

Improvements contd.
Brainstorming Item TrackingInterviews
Reviews
Lessons
Learned
Process
Modelling
Survey or
Questionnaire
Workshops
Techniques
Metrics and
Key
Performance
Indicators
Process
Analysis
Risk Analysis
and
Management
Root Cause
Analysis

Improvements contd.
Stakeholders
Domain Subject
Matter Expert
Project Manager
Sponsor

Business
Architecture &
Systems
Design
Project Management,
Management
& Leadership
Computer Software
Business &
Corporate
Web, Marketing,
PR &Social
Legal, Finance &
Accounting
Workplace
Requirements
Technical &
Programming
Section 2
Elicitation and Collaboration

2.1 Prepare for Elicitation
2.2 Conduct Elicitation
2.3 Confirm Elicitation Results
2.4 Communicate Business Analysis Information
2.5 Manage Stakeholder Collaboration for elicitation activities
Section 2: Elicitation and
Collaboration

What does Elicitation really mean?
Earlier, requirements were “Gathered” or
“Collected” or “Captured”
Then time progressed and now the
requirements as well as other business analysis
information are “Elicited”
The term Elicit can be defined as “to draw out or extract response, fact or answer”.
It is about uncovering unstated and implied needs and not relying only on what the subject matter
experts (SME’s) tell about the requirements
Business Analysts have to work at it to explore what the SME’s aren’t telling

Business Analysis
Planning and
Monitoring
Strategy Analysis
Requirements
Analysis and Design
Definition
Solution Evaluation
Elicitation and
Collaboration
Requirements
Lifecycle
Management

Tasks under Elicitation and Collaboration
Prepare for
Elicitation
Conduct
Elicitation
Confirm
Elicitation
Results
Communicate
Business
Analysis
Information
Manage
Stakeholder
Collaboration

Elicitation and Collaboration Input / Output figure
INPUTS
•Business Needs
Information
Approach
TASKS
•Prepare for Elicitation
•Conduct Elicitation
•Confirm Elicitation
Results
•Communicate Business
Analysis Information
•Manage Stakeholder
Collaboration
OUTPUT
•Elicitation Activity Plan
•Elicitation Results
(unconfirmed)
(confirmed)
Information
(communicated)

A business analyst can not be imagined without elicitation

Prepare for Elicitation Input / Output Diagram
INPUTS
•Business Needs
Approach
TASKS
•Prepare for Elicitation
OUTPUT
Conduct
Elicitation
Confirm
Elicitation
Results
Business Analysis
Approach
Business
Objectives
Existing Business
Potential Value

Purpose
Preparation is done to ensure that all the required resources are organized and scheduled for
conducting elicitation
Description
Preparation is done to ensure that all the required resources are organized and scheduled for
conducting elicitation. This task involves:
• Define scope of the elicitation technique
• Select appropriate technique
• Gather supporting material and resources
• Schedule and plan for all the required people and equipment

2.1 Prepare for Elicitation contd.
1. Define scope of the elicitation technique
• This involves prepping up for the type of business analysis information to be explored during
interaction
• A detailed elicitation plan can be created that covers the meeting agenda, stakeholders
involved and their role
It is like consciously or intuitively preparing oneself for
the conversation before appearing in client’s office

2. Gather supporting material and resources
• This may involve researching for already existing artifacts or documents, if any.
• Could also involve creating a deliverable that may act as a starting point for the discussion,
such as draft versions of requirement analysis or analysis models
For a geographically dispersed organization, a wiki can be put in place to
promote stakeholder participation in the elicitation activity
Wiki acts as a primary mode of sharing information and documentation
 A skeleton page can be created with any or all known information about
the project
 Links can be added for other supporting material like “as is” processes or
visual representations
 Stakeholders can go through this information in advance of the meeting
 Example

3. Select appropriate technique
• Depends on the cost and time constraints, types of sources of business analysis information,
organizational culture and desired outcome
4. Schedule resources
Involves identifying:
• Participants and their roles
• Availability of all the required participants
• Working out the logistics – conference room, conference call numbers, scheduling webcast, tools
etc
• Determine the communication channels
4. Preparing Stakeholders
Educating participants on the logic, relevance and working of elicitation techniques

Sometimes, a conversation alone just isn’t enough
At times, Business Analyst can encounter scenarios of conflicting requirements with the SME. Even
asking more questions may not lead the track of conversation anywhere.
It might sound unbelievable, but sometimes when SME’s are asked about their requirements,
they might end up telling what the current system does, or how the new process could or
should be organized.
They think that they provided the required answer, but it could sometimes be difficult to tell
the difference.
What to do during such conflicts?
 Verify that the SME’s are expressing a requirement that represents a need and not a solution
 Be clear on whether they are describing the current state or the future state

Both are conversation devices, but different, very different!

Brainstorming EstimationDocument
Analysis
Interviews
Mind MappingData Mining
Risk Analysis
and
Management
Techniques
Stakeholder
List, Map,
Personas

Stakeholders
Stakeholders
Domain Subject
Matter Expert
End User
Implementation
Subject Matter
Expert
Sponsor
Customer

Conduct Elicitation Input / Output Diagram
INPUTS
TASKS
•Conduct Elicitation
OUTPUT
(unconfirmed)
Confirm Elicitation
Results
Business Analysis
Approach
Stakeholder
Engagement Approach
Existing Business
Supporting Materials

The idea is to replace conversation and arguments with task performance
Induce techniques that encourage the participants in performing the task, identifying
discrepancies and collaborating to understand the inconsistencies
Rather than just focusing on questions and recording SME’s opinions as facts, follow a
structured process that enables the SME’s to apply their judgment
Example
Business Analyst can ask several SMEs to review case studies or perform business domain tasks
and share their expert opinions. In case their conclusions differ, they may be asked to explain so.
This helps in uncovering hidden assumptions and knowledge under conflicting requirements

Requirement Elicitation Questioning Techniques
Type Explanation Example
1. Analyze Personal understanding of concepts,
facts, cause & effect are expressed
“Would you please break that
requirement further, so I can have a
better understanding?”
2. Check To ensure removal of
misunderstanding
“Would you share with me your
understanding of what we just discussed?
3. Classify Attempting to organize facts in
relation to a given subject
“It would be really helpful in organizing
my thoughts if you would please classify
those points.”
4. Compare Reveal similarities and differences of
facts
“Can we compare this requirement to the
one we reviewed earlier?”
S.No:

Requirement Elicitation Questioning Techniques contd.
5. Define Understanding the term
interpretation
“To me help me understand better, can
you please define that term?”
6. Describe Defining characteristic features of a
condition or process
“Can you describe a typical scenario to
which this requirement may apply?
7. Discuss Analyzing a subject by extending its
application
“Lets explore the implications and
ramifications of this.”
8. Illustrate Examples that clarify the subject “Can anyone share few examples on how
this would work?”
S.No:

Requirement Elicitation Questioning Techniques contd.
9. Prompt &
Probe
To get more quantity & quality “What else?” ; “How exactly that can be
shown?”
10. Redirect Getting the discussion back on track “Good point, shall we put that on the
issues list?”
11. Restate Demonstrate your understanding “In other words…”
12. Review Recap to ensure nothing is missed “Shall we review the points covered so
far, before moving further?”
13. Verify Supply information to support a
statement
“How can this be verified to be depicted
as a valid case?”
S.No:

Purpose
To extract, draw out and identify relevant information for the subject under investigation
Description
Types of elicitation activities:
 Collaborative: Direct interaction with stakeholders, relying purely on their judgment and expertise
 Research: Exploring information out of sources or materials not directly known or owned by the
stakeholders involved in change. Helps identifying trends and past results
 Experiments: Identifying information utilizing some kind of controlled test. It is used when people
or documents are not enough to discover the information. Includes observational studies, proof of
concept and prototypes

2.2 Conduct Elicitation contd.
Delphi Technique
• SMEs are given a questionnaire or assigned a set of tasks to be performed
• They are required to justify their answers and actions
• Hidden assumptions are revealed based on the explanation provided
• SMEs discuss these assumptions, which results in revealing requirement characteristics
In order to deal with business scenarios that hadn’t cropped up before, it might require to
modify some decision criteria, identify new ideas to address the data quality or lack of
information available to the person performing the task, and eliminate some steps or even
entire flows.
The business analyst acts as a facilitator and uses the Delphi technique to:
 Manage the effects of group behavior
 Enable the SME’s to collaborate to identify, describe and justify their actions
Example

Nominal Group Technique
• Each SME is asked to perform a task or describe a solution to a problem
• Each SME describes their approach to the group
• Business Analyst lists the explanations, removing any duplicates
• Then each SME is asked to rank the proposed solutions starting with best, next best, etc
• A secret vote can be used to minimize the influence of some SME’s on others
• Pointers are used to weight each of the votes, with 5 points being the highest and so on
• The total points are revealed by the business analyst and a discussion is facilitated among the
experts
• If a clear winner comes out, then little or no discussion may be required
• In case of no obvious consensus about the “best” approach, there are likely some underlying
assumptions that have not yet been identified and agreed to, so the process is repeated
• The end result of this technique is often a hybrid “best” approach that can be supported and
agreed by all of the SME’s

Experiments
What if the requirements are to be discovered for a product or service that has never been done before?
In such cases a hypothesis can be developed about each of the conflicting
requirements which could then be confirmed or rejected through an experiment
• The experiment should be designed in a way so as to test just the hypothesis,
along with minimizing the cost and risk to the organization as well as the
people involved in the experiment
• Either a prototype is developed based on one SME’s perspective and tested
with independent users
• Or a simulation of a process is built and executed hundreds of times in
simulation

1. Guide Elicitation Activity
Elicitation activities must be planned in a way to
produce the intended information at the desired
level of detail
Business analyst needs to consider:
• Goals and agenda of elicitation activity
• Scope of the change
• Expected outputs from the activity
• Information sources
• How the output will integrate with what is
already known
• Who will use the information
• How information will be used
2. Capture Elicitation Outcomes
Elicitation is an iterative activity that is
conducted over a series of sessions in
accordance to the activity scope
The outcomes must be captured to ensure
future reference and use of the information
generated during elicitation

Brainstorming
Collaborative
Games
Benchmarking
and Market
Analysis
Business Rules
Analysis
Data Mining
Concept
Modelling
Data
Modelling
Techniques
Document
Analysis
Interviews Mind Mapping Focus Groups Prototyping
Survey or
Questionnaire
Workshops
Process
Analysis
Process
Modelling

Stakeholders
Stakeholders
Domain Subject
Matter Expert
End User
Implementation
Subject Matter
Expert
Sponsor
Customer

Confirm Elicitation Results Input / Output Diagram
INPUTS
(unconfirmed)
TASKS
•Confirm Elicitation Results
OUTPUT
(confirmed)
Assess
Risks
Elicitation
Activity Plan
Existing
Business
Analysis
Information
Analyze
Current
State

2.3 Confirm Elicitation Results
Purpose
The gathered information is checked for accuracy and consistency with other information
Description
The idea is to confirm the elicited information to identify any discrepancies and resolve them
before anyone uses that information
Consistency is verified by comparing the elicitation results against their source and other
elicitation results

2.3 Confirm Elicitation Results contd.
1. Compare elicitation results against source
information
• Sources can be discussions, stakeholder
knowledge, documents etc
• Conduct follow up meetings with
stakeholders to correct the elicitation results
2. Compare elicitation results against other
elicitation results
• Information collected through multiple
elicitation activities is compared for
accuracy and consistency
• Discrepancies are resolved in collaboration
with stakeholders
• Developing specifications and models
reveals inconsistencies in elicitation results

2.3 Confirm Elicitation Results contd.
Reviews
Document
Analysis
Interviews Workshops
Techniques
Stakeholders
Domain Subject Matter Experts: They have substantial knowledge, experience, or expertise about
the business analysis information being elicited. They also hold knowledge for proposed change or
solution.
These people help in confirming elicitation results as correct as well as identify omissions,
inconsistencies and conflicts in elicitation results

Communicate Business Analysis Information Input
/ Output Diagram
INPUTS
•Business Analysis Information
Approach
TASKS
•Communicate Business
OUTPUT
Information
(communicated)
Business
Analysis
Approach
Information
Management
Approach

A communication plan is created that describes the proposed structure and schedule
of communicating business analysis activities
Activities are recorded and organized to provide a basis for setting expectations for
business analysis work, meetings, walkthroughs, and other related communications
Business Analyst must consider the following:
• What needs to be communicated?
• How the information needs to be stated?
• What is optimum way to deliver the information?
• Who are the recipients of information?
• What is the frequency of expecting communication?

1. Define and Refine
the information
Information should be
precise around the key
points of the theme
2. Prepare
Content must
be strong and
effective
3. Develop Structure
Information content
must follow a
structure: context,
about & description,
conclusion
4. Concise and Precise
Words and format used must be
simple, easy to understand and
according to requirements
5. Use Visuals
Information is easily
retained if
complimentary figures,
graphs are used
6. Be Persuasive
Effective and impactful
information helps the
target audience
understand key
messages
7. End Strong
Provide clear outline of the take
away message and illustrative
conclusion

Purpose
To ensure that all the stakeholders hold a shared understanding of business analysis information
Description
Information must be communicated to the stakeholders at the right time and in right format
according to the needs
The process is two-way and iterative, involving determination of recipients, content, purpose,
context and expected outcomes
Information needs to be communicated in an effective way ensuring it is received and understood
Appropriate communication of information enables stakeholder engagement and agreement

contd.
1. Determine the objectives and format of communication
Information needs to be conveyed in a clear and usable format. It may be packaged in following
ways:
• Formal Documentation: An organization template is used to include information details. The
template may include placeholders for text, date, diagrams, matrices.
• Presentations: A high level overview is delivered that helps in understanding the change goals,
solution functions or supportive material information for decision making
• Informal Documentation: Texts, diagrams, matrices may be used during a change

contd.
2. Communicate Business Analysis Package
Communicating via appropriate platform is really important to ensure stakeholders understand
the level of detail of information as well as review it. It can be communicated through:
• Group Collaboration: Information can be communicated to all the relevant stakeholders at the
same time. Issues or concerns, if any, can be discussed immediately
• Individual Collaboration: When the aim is to gather individual understanding or in case group
setting is not feasible, information is communicated to single stakeholder, one at a time
• E-mail or other non-verbal methods: When the target stakeholders are highly mature to imbibe
the information without any supporting verbal explanation, these methods are good to
communicate

contd.
ReviewsInterviews Workshops
Techniques

contd.
Stakeholders
Stakeholders
Domain Subject
Matter Expert
End User
Implementation
Subject Matter
Expert
Tester
Customer

Manage Stakeholder Collaboration Input / Output
Diagram
INPUTS
Approach
TASKS
•Manage Stakeholder
Collaboration
OUTPUT
Business Analysis
Approach
Business
Objectives
Future State
Description
Recommended
Actions
Risk Analysis
Results

2.5 Manage Stakeholder Collaboration
Purpose
To encourage stakeholders to collaborate and work towards a common objective
Description
Once the stakeholder’s roles are confirmed, Business Analyst communicates with them to ensure
right participation of right stakeholders at the right times
The role, responsibility, influence, attitude, and authority of each stakeholder may change over time
 Higher the significance of the change impact, more focus is directed towards managing
stakeholder collaboration
 Collaboration helps in capitalizing on positive reactions and mitigate negative reactions
 The business analyst should constantly monitor and assess each stakeholder’s attitude to
determine if it might affect their involvement in the business analysis activities

2.5 Manage Stakeholder Collaboration contd.
1. Gain agreement on Commitments: Time and resource commitments are basic expectations
and must be agreed upon early in the initiative
2. Monitor engagement of stakeholders: This ensures consistency in influence, authority,
attitude and interest of stakeholders. Deliverables are conducted in a timely manner and
approvals occur without any delay
3. Collaboration: Free flow of information, ideas and opinions ensures support from
stakeholders. For a healthy engagement, business analyst needs to ensure that stakeholders
feel that their contributions are recognized, their opinions matter and they are heard

What can happen if there is lack of management in stakeholder collaboration?
Weak collaboration with stakeholders can cause negative impacts on business analysis
 Lack of quality information
 Strong negative feedbacks and hindrances
 Resistance to change
 Poor support and participation in business analysis activities

Lessons
Learned
Collaborative
Games
Risk Analysis
and
Management
Techniques
Stakeholder
List, Map or
Personas
Stakeholders
All types of stakeholders who might be involved in collaboration during change process

Business
Architecture &
Systems
Design
Project Management,
Management
& Leadership
Computer Software
Business &
Corporate
Web, Marketing,
PR &Social
Legal, Finance &
Accounting
Workplace
Requirements
Technical &
Programming
Section 3
Requirements Life Cycle Management

3.1 Trace Requirements
3.2 Maintain Requirements
3.3 Prioritize Requirements
3.4 Assess Requirement Changes
3.5 Approve Requirements
Section 3: Requirements Life Cycle
Management

What are Requirements?
Requirements are the spinal cord of any project
Effective implementation is based on precisely gathered and analyzed requirements
Business analyst acts as a bridge between different
stakeholders and is responsible for managing the
project requirements:
• Understanding the requirements shared by
business owners, subject matter experts, in detail
• Communicate the understanding to different
stakeholders on time to avoid any delays in the
implementation

Requirements Life Cycle
• Beginning: Business need is represented as a requirement
• Continuation: Requirements are then developed into a solution
• Conclusion: The solution and its representative requirements retire at this stage

Business Analysis
Planning and
Monitoring
Strategy Analysis
Requirements
Analysis and Design
Definition
Solution Evaluation
Elicitation and
Collaboration
Requirements
Lifecycle
Management

Requirements Lifecycle Management Input / Output figure
INPUTS
•Requirements
•Designs
•Proposed Change
•Requirements (verified)
TASKS
•Trace Requirements
•Maintain Requirements
•Prioritize Requirements
•Assess Requirements
•Approve Requirements
OUTPUT
•Requirements and
Designs (traced)
•Requirements and
Designs (maintained)
•Requirements and
Designs (prioritized)
•Requirements and Design
Change Assessment
•Requirements and
Designs (approved)

Tasks under Requirements Lifecycle Management
Trace
Requirements
Maintain
Requirements
Prioritize
Requirements
Assess
Requirements
Changes
Approve
Requirements

Trace Requirements Input / Output Diagram
INPUTS
•Requirements
•Designs
TASKS
•Trace Requirements
OUTPUT
•Requirements (traced)
•Designs (traced)
Domain Knowledge
Information
Management
Approach
Define Design
Options
Legal / Regulatory
Information
Requirements
Management Tools /
Repository

Why is it so hard to talk about anything software?

The picture may look funny and exaggerated, but it
addresses a truly inherent issue – Gap in requirements
Such gaps lead to absence of “Quality” and “Value”
These gaps result in delivering something that is far from being close to what the client had asked
Problems with requirement practices

3.1 Trace Requirements
Purpose
To ensure alignment between requirements and designs as well as mitigate gaps in requirements
Description
Requirement Traceability is used to:
• Ensure that the solution conforms to the requirements
• Assist in scope, change, risk, time, cost and communication management
• Detect missing functionality and gaps in requirements
Simpler and faster impact
analysis
If requirement X changes, what all needs to be reviewed that is associated
with the requirement?
Deep insights into scope
and complexity of change
If requirement X is included in the solution scope, what else needs to be
included to support the requirement?
Assessment of addressed
requirements vs
unaddressed
Are the necessary supporting requirements related to requirement X
included? Is requirement Y connect to business objective?
It enables:

3.1 Trace Requirements contd.
Process Traceability Software Requirements Traceability

What all is traced?
User Needs
High – Level
Product
Description
Business
Requirements
Document
Supplemental
Requirements
Test Case Test Case
Design
Artifact
Design &
Construction
Enterprise
Analysis
Requirements
Gathering &
Analysis
Test Period
traced
traced
traced
traced

Example: Agile methodology
What all is traced?
Requirements are
traced from Epic
To support User
Stories
To Sprints for
implementation
Related user stories are connected based on effort, value and necessity

How to record traceability?
1. Coverage Matrix (spread sheet)
High level product descriptions are traced to the requirements
Requirement
1
Requirement 2 Requirement 3 Requirement 4
Product description 1 X x
Product description 2 x x
Product description 3 x
Product description 4 X

How to record traceability? contd.
2. Requirement Traceability Matrix
Displays the backward as well as forward traceability of each requirement feature. This ensures:
• Each feature is mapped to its objective
• Each feature is complete with requirement

How to record traceability? contd.
3. Requirement Management Tools
Process Street IRIS Business Architect IBM Rational Enterprise Architect
Accompa agileSpecs Blueprint Polarion
REQUIREMENTS

Functional
Decomposition
Business Rules
Analysis
Process
Modelling
Techniques
Scope
Modelling

Stakeholders
Stakeholders
Domain Subject
Matter Expert
End User
Implementation
Subject Matter
Expert
Project
Manager
Tester
Customer

Maintain Requirements Input / Output Diagram
INPUTS
•Requirements
•Designs
TASKS
•Maintain Requirements
OUTPUT
•Requirements & Design
(maintained)
Information Management Approach

3.2 Maintain Requirements
Purpose
To ensure accuracy and consistency of requirements throughout the requirements life cycle
To reuse requirements in other solutions
Description
Requirement maintenance is an ongoing need to keep the requirement valid throughout and
beyond the change
• Requirements must be represented consistently
• A standardized process should be in place to review and approve maintenance
• Requirements must be easily accessible and understandable

3.2 Maintain Requirements contd.

Reasons for Tracing and Maintaining Requirements
Example
A billing system had to be fixed in a major domestic bank. They had a system to calculate bills based on
complex actuarial tables. There was a development environment, a test environment and a production
environment, each with their own sets of different reference tables.
The first thought for a person would be to refer the system documentation, but this had never been kept up
to date. The analysts had no idea which actuarial data was current. Consequently, all the data was re-created
and loaded into all three environments.
This discrepancy must have led to so many pensions been paid incorrectly.
 In case of any requirements
change, it is important to
identify when and why they
changed.
 This is important because no
one will remember in 5-6 weeks
time why a certain requirement
was modified from X to Y.
 In absence of traceability,
testing team will be clueless
about what to test
 Test plan should reflect the
requirements. If the
requirements specify X, then
the testing needs to test X.
 Out of date requirements
can lead to developing a
solution that is required no
more. Such changes need to
be tracked and maintained
so that latest solution is built
on latest requirements.

Functional
Decomposition
Business Rules
Analysis
Process
Modelling
Techniques
User Stories
Data Flow
Diagrams
Data Modelling
Use Cases and
Scenarios
Document
Analysis

Stakeholders
Stakeholders
Domain Subject
Matter Expert
Implementation
Subject Matter
Expert
Operational
SupportRegulator
Tester

Prioritize Requirements Input / Output Diagram
INPUTS
•Requirements
•Designs
TASKS
•Prioritize Requirements
OUTPUT
(prioritized)
Business
Constraints
Change Strategy
Domain
Knowledge
Governance
Approach
Requirements
Architecture
Solution Scope
Business
Constraints

3.3 Prioritize Requirements
Purpose
Requirements are ranked and worked upon in order or relative importance and urgency
Description
This is also an ongoing process. Ranking is based on:
• Relative value of a requirement
• Relative importance to stakeholders

3.3 Prioritize Requirements contd.

Business Analyst can’t take forever to capture the requirements.
They must be prioritized based on time schedule and cost.

Why Prioritize Requirements?
A project with resource limitations has to establish the relative priorities of the
requested features, use cases, or functional requirements
When customer expectations are high, timelines are short, and resources are limited,
developers want to make sure that the product contains the most essential functions
Customers express the
order of importance
Developers suggest the
associated cost and
technical complexity
Prioritization is determined by Customer and Developer Collaboration

How to Prioritize Requirements?
The knee-jerk response to a request for customers to set priorities is,
"I need all of these features. Just make it happen somehow."
This does not Help!
• The reality is that some features are more essential than others
• If customers are left to their own devices, they might set 85% of the requirements
at high priority, 10% at medium, and 5% at low priority. This doesn’t give much help
to the project manager
Example
On one project, the management steering team became impatient when the business analyst insisted on
prioritizing the requirements. The managers reasoned out that they could often do without one feature, but
another feature may need to be puffed up to make up for the omitted requirements. It was pointed out that
if too many requirements were deferred, the resulting system would fail to achieve the revenue that the
business plan promised.
 Tip: When evaluating priorities, look at the connections and interrelationships among different
requirements and their alignment with the business requirements.

How to Prioritize Requirements?
Prioritization Scales
Name Meaning
High Critical requirement. Required for next implementation
Medium Supports necessary system operations. Required eventually but could wait until a later
implementation if necessary
Low Functional or quality enhancement. Would be nice to have someday if resources permit
Name Meaning
Essential Product is not acceptable unless these requirements are satisfied
Conditional Product will enhance, but still acceptable if these requirements are absent
Optional Functions that may or may not be worthwhile to include
Scale 1
Scale 2

Business Cases
Backlog
Management
Interviews
Techniques
Item Tracking
Decision
Analysis
Risk Analysis
and
Management
Financial
Analysis
Estimation
Prioritization Workshops

Stakeholders
Stakeholders
Customer
End User
Implementation
Subject Matter
Expert
Project Manager
Regulator
Sponsor

Assess Requirements Input / Output Diagram
INPUTS
•Requirements
•Designs
•Proposed Change
TASKS
•Assess Requirements
Changes
OUTPUT
change assessment
Legal/ Regulatory
Information
Change Strategy
Domain
Knowledge
Governance
Approach
Requirements
Architecture
Solution Scope

3.4 Assess Requirements
Purpose
To evaluate the implications of the proposed changes on requirements and designs
Description
The following are considered carefully when assessing a change in requirements:
• Overall strategy
• Potential impact on solution value
• Business Value to business or stakeholders?
• Time or Resources?
• Risks, Opportunities and Constraints

3.4 Assess Requirements contd.

Business Cases
Business Rules
Analysis
Interviews
Techniques
Item Tracking
Decision
Analysis
Risk Analysis
and
Management
Document
Analysis
Estimation
Financial
Analysis

Stakeholders
Stakeholders
Customer
Domain Subject
Matter Expert
End User
Project Manager
Regulator
Tester

Approve Requirements Input / Output Diagram
INPUTS
•Designs
TASKS
•Approve Requirements
OUTPUT
•Requirements & Designs
(approved)
Legal/ Regulatory
Information
Change
Strategy
Governance
Approach
Requirements
Architecture
Solution Scope

3.5 Approve Requirements
Purpose
To obtain agreement of client on and approval of requirements & designs so that business
analysis work can continue and solution construction and implementation can process
Description
Business analysts collaborate with key
stakeholders to:
 Gain consensus on new and changed
requirements
 Communicate the outcome of discussions
 Track and manage the approval
Approval process can be formal or informal
• Predictive approach: Approvals are performed
towards the phase end or during planned change
control meetings
• Adaptive approach: Requirements are approved
only when construction and implementation of a
solution according to the requirement can begin

3.5 Approve Requirements contd.

“A high-five isn’t enough, sir.
You still need to review and prove a sign – off on the requirements.”

Getting a Sign – Off on requirements
The goal of organizations and projects when it comes to tracking requirement approval sign-off is about
Who, What, When and Why
Stakeholders, specially the client, may not always understand how to read the business
requirement documents
It is Business Analyst’s job to obtain a meaningful feedback and consequently an approval,
despite any short comings the stakeholders might have
 If they need pictures, draw pictures
 If they are comfortable reading lists, create lists
 If they prefer a story, tell it
It is Business Analyst’s responsibility to provide various ways of communicating requirements,
so that stakeholders understand the requirements and what is expected out of them

Getting a Sign – Off on requirements contd.
Before scheduling a requirements review session, Business Analyst should spend some time
to consider the desired outcome from discussion
 If the purpose is Discovery:
• List out the unknowns in a logical manner, for discussion in the meeting
• Prepare for a visual alignment to aid better understanding of the issue
 If the purpose is to Validate:
• List the hidden assumptions and ensure the attendees “think through” the process in the
required level of details
• Discuss about the points that need verification
 If the purpose is to Facilitate:
• In case of obtaining collaboration over a conflict, have a pre – understanding of each
individual’s point of view
• Keep some resolution ideas ready

Acceptance
and Evaluation
Criteria
Techniques
Item Tracking
Decision
Analysis
Reviews

Stakeholders
Stakeholders
Customer
Domain Subject
Matter Expert
End User
Project ManagerRegulator
Sponsor
Tester

Tips for effective Requirements Management

Tips for effective Requirements Management contd.

Business
Architecture &
Systems
Design
Project Management,
Management
& Leadership
Computer Software
Business &
Corporate
Web, Marketing,
PR &Social
Legal, Finance &
Accounting
Workplace
Requirements
Technical &
Programming
Section 4
Strategy Analysis

4.1 Analyse Current State
4.2 Define Future State
4.3 Assess Risks
4.4 Define Change Strategy
Section 4: Strategy Analysis

What is Strategy planning
and analysis?
It is the path an organization take from
“why they exist” (MISSION) to
“what they want to become?” (VISION)
Strategy
Planning
are more
profitable
MAJORITY of the
Business
failures
Are primarily
because they

Strategy
Planning
are more
profitable
MAJORITY of the
Are primarily
because they

Strategy
Planning
are more
profitable
MAJORITY of the
Are primarily
because they
Strategy Analysis
• Collaboration with stakeholders to develop
a change strategy
• Strategic Plan
• Product Vision
• Business Case
• Product Roadmap
Strategy may be captured in a
• Focus on analyzing the current state for identifying needs within
the current state
• Needs are prioritized to define the future state required to
address the desired business need
• Provides context for requirement analysis and design
definition for a given change
• Solution scope is defined

Business Analysis
Planning and
Monitoring
Strategy Analysis
Requirements
Analysis and Design
Definition
Solution Evaluation
Elicitation and
Collaboration
Requirements
Lifecycle
Management

Strategy Analysis Input / Output figure
INPUTS
•Needs
•Influences (internal,
external)
Approach
(unconfirmed)
(confirmed)
•Designs (prioritized)
•Requirements
(prioritized)
TASKS
•Analyze Current State
•Define Future State
•Assess Risks
•Define Change Strategy
OUTPUT
•Current State Description
•Business Requirements
•Business Objectives
•Future State Description
•Potential Value
•Risk Analysis Results
•Change Strategy
•Solution Scope

Tasks under Strategy Analysis
Analyze Current
State
Define Future State Assess Risks
Define Change
Strategy

Analyse Current State
INPUTS
•Needs
•Elicitation Results (confirmed)
TASKS
OUTPUT
Tasks using “Business
requirements”
Define Future State
Tasks using “Current State Description”
Plan
Stakeholder
Engagement
Plan Business
Analysis
Governance
Define
Future
State
Assess
Risks
Define
Change
Strategy
Analyze potential value
and recommend solution
Assess
Enterprise
Limitations
Recommend Actions to
Increase Solution Value

Analyse Current State
INPUTS
•Needs
•Elicitation Results (confirmed)
TASKS
OUTPUT
Guidelines and tools
Business
Analysis
Approach
Enterprise
Limitation
Organizational
Strategy
Solution
Limitation
Solution
Performance Goals
Solution
Performance
Measures
Stakeholder Analysis
Results

4.1 Analyse Current State
Purpose
To determine the causes that generate a need in the enterprise to change some or entire
aspect of its operations. Also, understand what all direct or indirect impact will be generated
by the change
Description
 Usually, changes are triggered by problems or opportunities which require altering of
current state in order to be addressed
 This requires clear understanding of the business needs
 No under understanding of the needs, no possibility of developing a coherent strategy

4.1 Analyse Current State contd.
Analyzing the current state or “As Is” state is appropriate when:
•There are known issues with the current state:
 Orders not getting processed
 Customers being frustrated with organization’s level of service
•Business users are confused regards choosing the right process or appropriate
steps to be taken
•Organization wants to automate or streamline the current processes, but there is
lack of current state understanding as well as any documentation

1. Evaluation of Business Needs
Analyze Business Needs
From top -
down
From
bottom - up
From middle
management
From external
drivers
Business need once identified should be documented in the Business Case, with following factors:
• Quantify the adverse impacts caused by the problem: Potential Lost Revenue, dissatisfied
customers, inefficiencies
• Highlight the expected benefits from any potential solution: increased revenue, reduced costs,
increased market share
• Cost of doing nothing
• Problem source

2. Organizational Structure and Culture
• Identify if cultural changes can help better in achieving the goals
• Identify if the rationale for the current state and the value delivered by it is understood by
the stakeholders
3. Capabilities and Processes
Capability –
centric view
Process –
centric view
Easier to
identify gaps
Improves performance
of current activities

4. Understand the Technology and Infrastructure of the organization
7. Understanding the External Influencers
5. Understand the Organizational Policies and Business Rules
6. Understanding the Organization’s Business Architecture
The current state must not be assessed in isolated parts
Business Analyst must understand the fit between different parts of the current state
These may not be change participants but may pose constraints and dependencies:
 Industry Structure
 Competitors
 Customers
 Suppliers
 Political Environment
 Technology
 Macroeconomic Factors

Tools for Analyzing Current State to
make Strategic Decisions
SWOT Analysis
Industry Analysis –
Porter’s five forces
model

SWOT Analysis
Tool for identifying opportunities and threats in the external business environment as
well as strengths and weaknesses from the internal business environment
STRENGTHS
WEAKNESSES
OPPORTUNITIES
THREATS
S
W
O
T
Conducting SWOT Analysis
• List the objectives of analysis
• Identify all the strengths and weaknesses of the firm, with
respect to the stated objectives
• Identify all the opportunities and threats, with respect to
the stated objectives
• Examine the assessment of strengths and weaknesses
versus opportunities and threats – SO, ST, WO, WT
• Identify action items for achieving the stated objectives

This technique uses five industry forces to determine the intensity
of competition in an industry and its profitability level
Can help the business analyst to ascertain the market attractiveness
based on organization’s current capabilities to make profit
The Five Forces
Industry Analysis – Porter’s 5 forces model

Business
Capability
Analysis
Techniques
Benchmarking
and Market
Analysis
Document
Analysis
Concept
Modelling
Business
Cases
Data
Mining
Financial
Analysis
Focus
Groups
Interviews
Lessons
Learned
Process
Analysis and
Modelling
Risk Analysis
and
Management
Metrics and
KPIs
Mind Mapping
Root Cause
Analysis
SWOT analysis
Vendor
Assessment
Scope
Modelling

Stakeholders
Stakeholders
Customer
Domain
Subject
Matter Expert
End User
Implementation
Subject Matter
ExpertProject
Manager
Regulator
Sponsor
Tester

Define Future State Input / Output Diagram
INPUTS
TASKS
OUTPUT
•Potential Value
Refer notes
Tasks using “Potential
Value”
Refer notes
Tasks using “Business Objectives”
Refer notes
Tasks using “Future State
Description”

Define Future State Input / Output Diagram contd.
INPUTS
TASKS
OUTPUT
•Potential Value
Constraints
Current State
Description
Organizational
Strategy
Metrics and KPIs

4.2 Define Future State
Purpose
To define a set of necessary conditions that are required to meet the business need
Description
BA must ensure to define the future state that is achievable with available resources and
shares vision with key stakeholders. The following points should be ensured:
• Clearly define outcomes that will satisfy business needs
• Scope of solution space should be in detail
• Enable assessment of the value associated with the future state
• Changes that lead to improved Future State may include:
 Business Processes
 Functions
 Line of Business
 Staff Competencies
 Technology know how
 Data and Information
 Organization Locations
 Facilities

4.2 Define Future State contd.
1. Articulate Business Goals and Objectives
The goals and objectives depict the changes an organization wants to accomplish and current
conditions it wants to maintain
Goals are long term and ongoing statements. They are converted into more descriptive and
specific objectives
For objectives to be assessed they must be SMART:
 Specific
 Measurable
 Achievable
 Relevant
 Time-bounded

2. Scope of Solution Space
It defines what all type of options will be considered when investigating possible solutions for
changes in organisational structure, processes and capabilities, policies, products and services
Expertise of both BA and delivery team is required for defining solutions in these areas
The critical considerations for making decisions are dependent on the following:
• Overall objectives of the enterprise
• Understanding of the quantitative and qualitative value of each option
• Time and cost constraints

3. Constraints
It defines the aspects of current and future state that
may not be changed by the solution. These may be
viewed as the set of restrictions within which the
changes to future state may be devised. It can include
the following:
• Time constraints
• Budget constraints
• Infrastructure
• Policies
• Resource availability
• Regulatory compliance
4. Organizational Structure and Culture
5. Capabilities and Processes
6. Technology and Infrastructure
7. Policies
8. Business Architecture
9. Internal Assets
10. Identify Assumptions
11. Potential Value

Acceptance and
Evaluation
Criteria
Techniques
Benchmarking
and Market
Analysis
Business
Capability
Analysis
Decision
Analysis
Business
Cases
Balanced
Scorecard
Financial
Analysis
Decision
Modelling
Functional
Decomposition
Lessons
Learned
Process
Modelling
Prototyping
Metrics and
KPIs
Mind Mapping
Organizational
Modelling
SWOT
analysis
Brainstorming
Interviews
Scope
Modelling
Vendor
Assessment
Survey or
questionnaire

Stakeholders
Stakeholders
Customer
Domain
Subject
Matter Expert
End User
Implementation
Subject Matter
ExpertProject
Manager
Regulator
Sponsor
Tester

Assess Risks Input / Output Diagram
INPUTS
•Influences (internal and
external)
•Requirements Prioritized
•Potential Value
TASKS
•Assess Risks
OUTPUT
Manage
Stakeholder
Collaboration
Define
Change
Strategy
Analyze Potential
Value and
Recommend Solution
Analyze
Performance
Measures
Assess
Solution
Limitations
Assess
Enterprise
Limitations

Assess Risks Input / Output Diagram contd.
INPUTS
•Influences (internal and
external)
•Requirements Prioritized
•Potential Value
TASKS
•Assess Risks
OUTPUT
Business
Analysis
Approach
Business
Policies
Change
Strategy
Current
State
Description
Future
State
Description
Identified
Risks
Stakeholder
Engagement
Approach

4.3 Assess Risks
Purpose
Risk assessment is carried out to understand the undesirable consequences due to internal and
external forces on the enterprise during a transition to the future state. Based on understanding
of the potential impact of those forces, recommendations can be made about a course of action
Description
Risks could be related to anything – the current state, desired future state or the change itself
Assessing these risks include analyzing and managing them
Based on the type of risk categories, suitable strategies are chosen.
A risk is accepted if the assessment reveals that chances of success outweigh the probable loss

4.3 Assess Risks contd.
1. Searching the Unknowns
BA needs to collaborate with stakeholders for risk assessment, as there is an uncertainty involved
in its occurrence and impact
When it is not possible to know all that will occur as a result of a particular change strategy,
Business Analysts consider historical contexts and past lessons learnt from similar situations to
assess possible impact of unknown or uncertain events
2. Constraints, Assumptions and Dependencies
3. Negative Impact on Value
Business analysts identify and express each risk and estimate its probability of occurrence and
impact to determine the level of risk. In some cases, overall level of risk can be quantified in
financial terms, or in amount of time, effort, or other measures.

4. Risk Tolerance
Risk Tolerance is the ability and willingness of an enterprise to accept uncertainty in exchange for
potential value. There are following three types of attitude towards risk:
• Risk Aversion – unwillingness to accept much uncertainty, hence choose to avoid
• Neutrality – some level of risk is acceptable, provided the probability of loss occurrence is minimal
• Risk Seeking – willingness to assume more and more risk in exchange for higher potential value
5. Recommendation
Business analysts recommend a course of action depending on the risk analysis.
Recommendation can be one of the following:
• Pursue the benefits of change irrespective of the risk
• Pursue the change benefits but also invest in risk reduction
• Identify ways to optimize and manage opportunities
• Do not pursue the benefits of change

Brainstorming
Techniques
Decision
Analysis
Business
Cases
Financial
Analysis
Root Cause
Analysis
Risk Analysis
and
Management
Lessons
Learned
Mind Mapping
Document
Analysis
Interviews
Survey or
questionnaire

Stakeholders
Stakeholders
Domain Subject
Matter Expert
Implementation
Subject Matter
Expert
Project Manager
Regulator
Sponsor
Tester

Define Change Strategy Input / Output Diagram
INPUTS
Approach
TASKS
•Define Change Strategy
OUTPUT
•Change Strategy
•Solution Scope
Refer notes
Tasks using “Solution
Scope”
Refer notes
Tasks using “Change
Strategy”
Refer notes

4.4 Define Change Strategy
Purpose
To develop and assess alternative approaches to absorb the change, and choose the
recommended approach
Description
Nature of change is described by the change strategy, in terms of:
• Context of change
• Identified approaches for change strategies
• Justifying why a particular change strategy is the best
• Investment and resource requirement
• Value realization after solution delivery
• Key stakeholders in the change

4.4 Define Change Strategy contd.
1. Solution Scope
Outcome of a change strategy is “Solution” that allows an organization to satisfy its
requirements. Multiple solution options are evaluated and the best solution approach is justified
and selected.
Solution Scope defines the solution boundaries, describing it in enough detail to enable the
stakeholders’ understanding of new capabilities that the change will deliver.
It also describes how the proposed solution enables the future state's goals

2. Gap Analysis
Difference between current state and future state is identified by Gap Analysis. To perform this
analysis both current and future state should be defined
• Helps in identifying causes that prevent an organization from realizing its needs and goals
• Determines if the goals can be achieved with the set of current conditions and capabilities. If
yes, then little or no change may be involved
3. Enterprise Readiness Assessment
It involves assessing the organization’s capacity to make changes, as well as use and sustain the
solution value. The following are considered for assessing readiness:
• Cultural readiness of the stakeholders and operational readiness in making the change
• Timeline from when the change is implemented to when value can be realized
• Resource availability to support the change effort

4. Change Strategy
It is a high-level plan consisting of key activities and events that will be used to transform the
enterprise from the current state to the future state
• Business analysts may develop a business case for each potential change strategy to support
decision making.
• Options considered and rejected are an important component of the final strategy, as they
provide stakeholders with an understanding of the pros and cons of various approaches to
making the change
• The potential value, including the details of the expected benefit and costs, are key
components to making a business case for the change

Tools for Defining Change Strategy
BCG Growth/Share
Portfolio Matrix
GE Business Screen
Matrix

BCG Growth/Share Portfolio Matrix
This technique helps in detecting priority areas in a firm’s business portfolio
Using BCG Matrix
• Identify all of the business units in a firm
• Determine the market share and growth rate of each
business unit
• Place them appropriately under Stars, Question Marks,
Cash Cows and Dogs
STARS
QUESTION
MARKS
CASH
COWS
DOGS
high
high
low
low
Relative Position (Market Share)
BusinessGrowthRate(MarketGrowth)
Analysis
 STARS: Maintain the market share and use strategies like
market penetration, product development to optimize
growth rate
 Cash Cows: Maintain the market share. Make changes to
enhance its profitability and move it under “STARS”
 Dogs: These business units must be liquidated or disposed
off
 Question Marks: Since growth rate is higher, if it can be
optimized by product development, market penetration, it
can shift under “STARS” else will become a “Dog”

GE Business Screen Matrix
Another technique for crafting business portfolio
Using BCG Matrix
• Identify all of the business units in a firm
• Determine Industry Attractiveness of each business unit
by considering drivers like market size, market growth
rate, resource availability, competition, risks and returns,
profitability
• Determine Business Unit Strength of each business unit by
considering drivers like production capacity, market share,
brand equity, customer loyalty, management, product
quality, innovation, etc
• Determine relative importance of each driver
• Award points to business unit on each driver
• Multiply relative weights and points for each business unit
• Plot graph and interpret results

Balanced
Scorecard
Techniques
Benchmarking
and Market
Analysis
Business
Cases
Decision
Analysis
Interviews
Functional
Decomposition
Financial
Analysis
Focus Groups
Business
Capability
Analysis
Estimation
Lessons
Learned
Process
Modelling
Mind
Mapping
SWOT
Analysis
Organizational
Modelling
Vendor
Assessment
Business
Model
Canvas
Scope
Modelling

Stakeholders
Stakeholders
Customer
Domain
Subject
Matter Expert
End User
Implementation
Subject Matter
ExpertProject
Manager
Regulator
Sponsor
Tester

Expert BA behavior that helps in executing the task
1. Systems Thinking 2. Business Acumen
• The business analyst needs to have a
holistic view of the business.
• It is crucial to understand the
interaction and relationship among
people, processes and technology
• In context of systems theory, the term
system includes the people involved,
the interactions between them and the
external forces affecting their behavior
• It is the ability to understand and apply
the knowledge based on similar practices
followed in the industry within differing
situations
• Business acumen is gained by using
knowledge and experience obtained from
different situations
• It is required to have a fundamental
understanding of the best practices and
principles followed in a business

3. Industry Knowledge 4. Organization Knowledge
• Understanding the prevalent trends of
industry and how the business is positioned
within an industry
• It helps to being familiar with the
 Largest customer segment
 Knowledge about major competitors and
partners
 Knowledge about common products and
types
 Understanding of industry specific terms and
processes
• Provides an understanding of an
enterprise’s management structure and
business architecture
• Understanding includes how the
organization
 Generates profits
 Accomplishes its goals
 Organizes structure
 Maintain relationships between business
units
 Appoints persons at key stakeholder
positions
Expert BA behavior that helps in executing the task

Business
Architecture &
Systems
Design
Project Management,
Management
& Leadership
Computer Software
Business &
Corporate
Web, Marketing,
PR &Social
Legal, Finance &
Accounting
Workplace
Requirements
Technical &
Programming
Section 5
Requirement Analysis and Design Definition

5.1 Specify and Model Requirements
5.2 Verify Requirements
5.3 Validate Requirements
5.4 Define Requirements Architecture
5.5 Define Design Options
5.6 Analyse Potential Value and Recommend Solution
Section 5: Requirement Analysis
and Design Definition

Business Analysis
Planning and
Monitoring
Strategy Analysis
Requirements
Analysis and Design
Definition
Solution Evaluation
Elicitation and
Collaboration
Requirements
Lifecycle
Management

Requirement Analysis and Design Definition Input / Output figure
INPUTS
•Requirements (any state)
•Information
Management Approach
•Elicitation Results (any
state)
•Potential Value
•Solution Scope
•Change Strategy
TASKS
•Specify and Model
Requirements
•Verify Requirements
•Validate Requirements
•Define Requirements
Architecture
•Define Design Options
•Analyze Potential Value
and Recommend Solution
OUTPUT
•Requirements (specified
and modelled)
•Requirements (validated)
•Requirements
Architecture
•Design Options
•Solution
Recommendation

Tasks under Requirement Analysis and Design
Definition
Specify and
Model
Requirements
Verify
Requirements
Validate
Requirements
Define
Requirements
Architecture
Define Design
Options
Analyze
Potential
Value and
Recommend
Solution

Specify and Model Requirements Input / Output
Diagram
INPUTS
•Elicitation Results (any state)
TASKS
•Specify and Model
Requirements
OUTPUT
•Requirements (specified
and modelled)
Tasks using this Output
Verify
Requirements
Modelling
Notations/
Standards
Modelling
Tools
Requirements
Architecture
Requirements
Life Cycle
Management
Tools
Solution Scope
Validate
Requirements

5.1 Specify and Model Requirements
Purpose
To form well defined requirements and designs by analyzing, synthesizing and refining elicitation results
Description
Specifying and Modelling describes the practices for analyzing elicitation results requirements
Requirements:
• Outputs are referred to as requirements, when the specifying and modelling activity is focused on
understanding the need
• All Business Deliverables are referred to as requirements
Designs:
• Outputs are referred to as designs, when the specifying and modelling activity is focused on a solution
• “Designs” refers to technical designs of the software, created by developers and data architects

5.1 Specify and Model Requirements contd.

1. Model Requirements
It is a descriptive and visual way of representing information
for a specific set of audience in order to support analysis,
communication, and understanding of requirements
Models may be used for following
purposes:
• Confirm Knowledge
• Identify Information Gaps that the
business analyst may have
• Identify Duplicate Information.
Modelling Formats
Matrices
• Used when a set of requirements having
complex but uniform structure
• May be used for requirement
traceability or for gap analysis
Diagrams
• Pictorial representation of a set of
requirements
• Complexity is depicted via visuals, that
would be difficult to do with words

2. Analyze Requirements
• What must change?
• What must not change?
• What is missing?
• What is necessary?
• Constraints and Assumptions?
3. Represent Requirements and Attributes
Information for requirements is identified as part of
elicitation results
Requirement details should be represented in detail so as to
exhibit characteristics and design quality of requirements
4. Implement the Appropriate Levels of Abstraction
• Not all stakeholders require or find value in the complete set of requirements and models
• So it may be appropriate to produce different viewpoints of requirements to represent the
same need for different stakeholders
• Business analysts take special care to maintain the meaning and intent of the requirements
over all representations

Acceptance
and Evaluation
Criteria
Techniques
Concept
Modelling
Business
Rules
Analysis
Data
Dictionary
Interface
Analysis
Use Cases
and
Scenarios
Functional
Decomposition
Data
Modelling
Business
Capability
Analysis
Data Flow
Diagrams
Prototyping
Process
Modelling
Root Cause
Analysis
Sequence
Diagrams
Organizational
Modelling
Roles and
Permissions
Matrix
Business
Model
Canvas
Scope
Modelling
User Stories

Stakeholders
Any Stakeholder
• Either Business Analysts may opt to perform this task on their own and then package the
requirements in order to communicate to stakeholders for their review and approval
• Or the Business Analysts may invite some or all the stakeholders to participate in this task

Verify Requirements Input / Output Diagram
INPUTS
•Requirements (specified and
modelled)
TASKS
•Verify Requirements
OUTPUT
Approve
Requirements
Requirements Life Cycle
Management Tools

5.2 Verify Requirements
Purpose
To ensure that requirements and designs:
• Meet the standards of quality
• Can be used for the purpose they serve
Description
• Verification is done so as to ensure that the requirements and designs have been defined correctly
• It is a check to determine that the requirements are ready for validation
• Must meet the needs of the stakeholders, who are going to use them for a particular purpose

5.2 Verify Requirements contd.

5.2 Verify Requirements contd.
Acceptance
and Evaluation
Criteria
Techniques
Reviews
Item
Tracking
Metrics and Key
Performance
Indicators (KPIs)
Stakeholders
All Stakeholders
• Business Analyst, along with domain and subject matter experts, is primarily responsible for
determining the completeness of this task
• Other stakeholders may also participate in the task to avoid discovering problematic
requirements during requirements communication

Conducting Requirements Review Sessions
1. Minimum text, more pictures
Use graphical models and mock-up screens to make the sessions more
interactive and keeping the audience engaged
2. Walkthroughs are meant for detecting errors and
flaws and not correcting these on the spot
Note down the corrections or highlight them on the document. These can be
corrected later after completing the review session
3. Prioritize the issues to be discussed
• Need not pend much time focusing on rare scenarios or exceptions
• Prioritize the requirement issues beforehand and discuss in a sequence
4. Probe the stakeholders for feedback
• Ask probing questions to generate thoughts and feedback
• Solicit for constructive criticism

Conducting Requirements Review Sessions contd.
5. Send the requirements package in advance
This will enable the stakeholders to go through the requirements and prepare in advance
6. It is better to have a right stakeholder mix
Do stakeholder profiling and select stakeholders possessing sufficient domain knowledge and authority
7. Set up boundaries
• Discuss only key and high priority issues
• Postpone issues that are out of scope or extensive
8. Obtain stakeholders’ sign off on the requirements
• Sign-off indicates their readiness to approve the requirements
• Make necessary changes and corrections after the session
• Send the documents for a formal sign-off from the stakeholders

Validate Requirements Input / Output Diagram
INPUTS
•Requirements (specified and
modelled)
TASKS
•Validate Requirements
OUTPUT
Define Design
Options
Business
Objectives
Measure Solution
Performance
Future
State
Description
Potential
Value
Solution
Scope

5.3 Validate Requirements
Purpose
To ensure that requirements and designs:
• Support Business Needs
• Deliver the required business value
Description
Validating requirements is an ongoing process
• Overall goal of validating the requirements is to achieve the stakeholders' desired future state

5.3 Validate Requirements contd.

5.3 Validate Requirements contd.
Acceptance
and Evaluation
Criteria
Techniques
Reviews
Item
Tracking
Metrics and Key
Performance
Indicators (KPIs)
Stakeholders
All Stakeholders
• Business Analyst, along with customer, end user and sponsors, is primarily responsible for
determining the validity of requirements
• Other stakeholders may also participate in the task to avoid discovering any problematic
requirements during requirements communication
Risk Analysis
and
Management
Document
Analysis
Financial
Analysis

Define Requirements Architecture Input / Output Diagram
INPUTS
•Requirements (any state)
•Information Management
Approach
•Solution Scope
TASKS
•Define Requirements
Architecture
OUTPUT
Prioritize
Requirements
Architecture
Management
Software Assess Requirement
Changes
Legal /
Regulatory
Information
Methodologies
and Framework
Specify and Model
Requirements
Define Design
Options

5.4 Define Requirements Architecture
Purpose
The goal is to ensure that the requirements support each other collectively and achieve the
business objectives fully
Description
The structure of all the requirements of a change is the Requirements architecture
It binds the individual data models and requirement specifications together to ensure that
all of the requirements are in sync and form a single whole that supports the overall
business objectives and produces a useful outcome for stakeholders

5.4 Define Requirements Architecture contd.

Data
Modelling
Techniques
Workshops
Organizational
Modelling
Scope
Modelling
Functional
Decomposition Interviews

Stakeholders
Stakeholders
Domain Subject
Matter Expert
End User
Implementation
Subject Matter
Expert
Project
Manager
Sponsor
Tester

Define Design Options Input / Output Diagram
INPUTS
•Requirements (validated,
prioritized)
•Change Strategy
•Requirements Architecture
TASKS
•Define Design Options
OUTPUT
•Design Options
Define
Change
Strategy
Existing
Solutions
Future
State
Description
Requirements
(traced)
Analyze Potential
Value and
Recommend
Solution
Solution
Scope

5.5 Define Design Options
Purpose
To achieve the desired future state by :
• Defining a solution approach
• Identifying opportunities to improve the business
• Allocating requirements across solution components
• Representing design options
Description
• Design options are representations of ways to satisfy a set of requirements
• More than one design options may be identified when designing a solution
• Design options evolve with the evolution of requirements

5.5 Define Design Options contd.

Benchmarking
and Market
Analysis
Techniques
Lessons
Learned
Interviews
Mind
Mapping
WorkshopsVendor
Assessment
Survey or
Questionnaire
Brainstorming
Root Cause
Analysis
Document
Analysis

Stakeholders
Stakeholders
Domain Subject
Matter Expert
Implementation
Subject Matter
Expert
Operational
SupportProject Manager
Supplier

Analyse Potential Value and Recommend Solution
Input / Output Diagram
INPUTS
•Potential Value
•Design Options
TASKS
•Analyze Potential Value
and Recommend Solution
OUTPUT
•Solution Recommendation
Define
Change
Strategy
Business
Objectives
Current
State
Description
Future State
Description
Risk Analysis
Results
Solution
Scope

5.6 Analyze Potential Value and Recommend
Solution
Purpose
To estimate the potential value for each design option and determine the most appropriate
option to meet the business requirements
Description
• Design options are evaluated by comparing the potential value of each option
• Value can be described in terms of finance, reputation, or even impact on the marketplace
• Depending upon the analysis, there could either be no best option to recommend or there
may be a clear best choice

Solution contd.

Solution contd.
Acceptance
and Evaluation
Criteria
Techniques
Business
Cases
Business
Model
Canvas
Focus
Groups
Financial
AnalysisEstimation
Backlog
Management
Decision
Analysis
Brainstorming
Interviews
SWOT
Anlysis
Survey or
Questionnaire
Risk Analysis
and
Management
Metrics and
Key
Performance
Indicators
Workshops

Solution contd.
Stakeholders
Stakeholders
Customer
Domain
Subject
Matter Expert
End User
Implementation
Subject Matter
Expert
Project
Manager
Regulator
Sponsor

Paralysis of Analysis
It is not exactly a physical disease
Rather, it is a state of mind that traps you and prevents you from making progress
It is over analysing a situation so much so that a decision or
action takes long to happen or never really happen

Not wanting to stop
Causes could be:
1. Fear
2. Lack of confidence
3. Indecision
Analysis Paralysis can lead to:
• Delay in project
implementation
• Scope Creep
• Increased Risk
• Wrong Decisions
• Project Failure
• Complexity
Not knowing when to stop analysing
It happens when there are:
1. NO deadlines
2. NO clearly defined objectives and
structure
3. NO plan
Paralysis of Analysis

Useful Techniques to avoid Paralysis of Analysis
80/20 Rule
Vision Statement
Timeboxing
Prioritize the work items. 80% of the benefits can be obtained from by
focusing on vital tasks that consume 20% of the total time and effort
It ensures that the deliverables are planned and turned out
within a specific timeframe
It describes the Why, What and Who of the solution
Scope Modelling
Define the scope of the project, make the plan and stick to it

Responsibilities of Business Analyst in Requirement
Analysis and Design Definition

Business
Architecture &
Systems
Design
Project Management,
Management
& Leadership
Computer Software
Business &
Corporate
Web, Marketing,
PR &Social
Legal, Finance &
Accounting
Workplace
Requirements
Technical &
Programming
Section 6
Solution Evaluation

6.1 Measure Solution Performance
6.2 Analyse Performance Measures
6.3 Assess Solution Limitations
6.4 Assess Enterprise Limitations
6.5 Recommend Actions to Increase Solution Value
Section 6: Solution Evaluation

How does one know whether activities are on the right
track or are they building the right solution that would
satisfy the business needs as defined by the stakeholder?
By Evaluating the Solution – early and often.
Planned Actual
The results of evaluation provide:
 Comparison between the planned and actual values
 Facilitates go / no go decision
 Leads to solution refinement or new solutions

“Improvement” is an ongoing need and organizations chase it by investing in
new solutions and initiating projects
Solution Evaluation can be performed during varying stages of development:
• Prototypes or Proof of Concept
• Pilot or Beta releases
• Operational Releases
Business Analysis Value Spectrum

Perspectives in Solution Evaluation
Solutions are evaluated on following parameters:
• Savings in cost
• Increase in turnover
• Improved customer base
• Enhanced employee satisfaction
• Better Legal Compliance
Before initiating an evaluation, it is necessary to have documented business requirements and
use cases.
 This challenging, as unclear or incomplete requirements lead to unsatisfying or weak
solution evaluation

Business Analysis
Planning and
Monitoring
Strategy Analysis
Requirements
Analysis and Design
Definition
Solution Evaluation
Elicitation and
Collaboration
Requirements
Lifecycle
Management

Solution Evaluation Input / Output figure
INPUTS
•Implemented Solution
(external)
•Potential Value
TASKS
•Measure Solution
Performance
•Analyze Performance
Measures
•Assess Solution
Limitations
•Assess Enterprise
Limitations
•Recommend Actions to
OUTPUT
•Solution Performance
Measures
Analysis
•Solution Limitation
•Enterprise Limitation
•Recommend Actions

Tasks under Solution Evaluation
Measure
Solution
Performance
Analyze
Performance
Measures
Assess Solution
Limitations
Assess
Enterprise
Limitations
Recommend
Actions to
Increase
Solution Value

Measure Solution Performance Input /
Output Diagram
INPUTS
(external)
TASKS
•Measure Solution
Performance
OUTPUT
Measures
Change Strategy
Requirements
(validated)
Analyze Current State
Future State
Description
Solution Scope Analyze Performance
Measures

6.1 Measure Solution Performance
Purpose
To define performance measures and then use the collected data to evaluate how effective a
solution has been in relation to the value it brings
Description
Value of a newly implemented or existing solution is measured based on the performance criteria
In case of absence of built-in performance measures in the solutions, the business analyst has to
work with stakeholders to determine and collect the measures that will best reflect the
performance of a solution.
Performance assessment is done through “Key Performance Indicators” (KPIs) aligned with
enterprise measures, goals and objectives for a project, process performance targets.

6.1 Measure Solution Performance contd.
Define Solution Performance Measures
Quantitative Measures Qualitative Measures
Validate Performance Measures
Collect Performance Measures
Volume or Sample size Qualitative Measures

Acceptance
and Evaluation
Criteria
Techniques
Benchmarking
and Market
Analysis
Decision
Analysis
Metrics and
KPIs
Business Cases Data Mining
Non-Functional
Requirements
Analysis
Prototyping
Survey or
Questionnaire
Use Cases and
Scenarios

Stakeholders
Stakeholders
Customer
Domain Subject
Matter Expert
End User
Project Manager
Regulator
Sponsor

Analyze Performance Measures Input /
Output Diagram
INPUTS
•Potential Value
Measures
TASKS
•Analyze Performance
Measures
OUTPUT
Analysis
Change Strategy
Risk Analysis
Results
Assess Enterprise
Limitations
Future State
Description
Solution Scope
Analyze Solution
Limitations

6.2 Analyze Performance Measures
Purpose
Provides insights into a solution’s performance in relation to the value it brings
Description
Performance measures are analyzed on the basis of:
• Enterprise goals and objectives
• Key Performance Indicators (KPIs)
• Risk level of the solution
• Risk tolerance of both stakeholders and the enterprise
• Other stated targets, if any

6.2 Analyze Performance Measures contd.
Solution Performance vs Desired Value
Risk Identification and Management
Consideration of Trends
Performance Variances

Acceptance
and Evaluation
Criteria
Techniques
Benchmarking
and Market
Analysis
Observation
Metrics and
KPIs
Interviews
Data Mining
Risk Analysis
and
Management
Root Cause
Analysis
Survey or
Questionnaire

Stakeholders
Stakeholders
Domain
Subject
Matter Expert
Project
ManagerSponsor

Assess Solution Limitations Input / Output
Diagram
INPUTS
(external)
•Solution Performance Analysis
TASKS
•Assess Solution
Limitations
OUTPUT
Change
Strategy
Risk Analysis
Results
Solution
Scope
Analyze Current State

6.3 Assess Solution Limitations
Purpose
Provides insights into a solution’s performance in relation to the value it brings
Description
Performance measures are analyzed on the basis of:
• Enterprise goals and objectives
• Key Performance Indicators (KPIs)
• Risk level of the solution
• Risk tolerance of both stakeholders and the enterprise
• Other stated targets, if any

6.3 Assess Solution Limitations contd.
Identify Internal Solution Component Deficiencies
Investigate Solution Problems
Impact Assessment

Acceptance
and Evaluation
Criteria
Techniques
Benchmarking
and Market
Analysis
Business rules
Analysis
Decision
Analysis
Interviews
Data Mining
Risk Analysis
and
Management
Root Cause
Analysis
Survey or
Questionnaire
Lessons
Learned

Stakeholders
Stakeholders
Customer
Domain Subject
Matter Expert
End User
Sponsor
Regulator
Tester

Assess Enterprise Limitations Input / Output
Diagram
INPUTS
•Implemented or Constructed
Solution (external)
•Solution Performance Analysis
TASKS
•Assess Enterprise
Limitations
OUTPUT
Change Strategy
Risk Analysis
Results
Solution
Scope
Analyze Current StateBusiness
Objectives
Future State
Description

6.4 Assess Enterprise Limitations
Purpose
Determines the impact of external factors on solution and how it restricts the solution from realizing
its full potential value
Description
Enterprise limitations may include factors such as:
• Culture
• Operations
• Technical Components
• Stakeholder Interests,
• Reporting Structures.
Assessing enterprise limitations leads to the identification of root causes and describes how enterprise
factors limit value realization.

6.4 Assess Enterprise Limitations contd.
Enterprise Culture Assessment
Stakeholder Impact Analysis
Organizational Structure Changes
Operational Assessment
Functions Locations Concerns

Brainstorming
Techniques
Benchmarking
and Market
Analysis
Document
Analysis
Decision
Analysis
Interviews
Data Mining
Risk Analysis
and
Management
Root Cause
Analysis
Survey or
Questionnaire
Lessons
Learned
Process
Analysis and
Modelling
SWOT Analysis

Stakeholders
Stakeholders
Customer
Domain Subject
Matter Expert
End User
Sponsor
Regulator

Recommend Actions to Increase Solution Value
Input / Output Diagram
INPUTS
TASKS
•Recommend Actions to
OUTPUT
•Recommended Actions
Guidelines and Tools Tasks using this output
Solution
Scope
Manage Stakeholder
Collaboration
Business
Objectives
Current State
Description

Purpose
Determines the impact of external factors on solution and how it restricts the solution from realizing
its full potential value
Description
Enterprise limitations may include factors such as:
• Culture
• Operations
• Technical Components
• Stakeholder Interests,
• Reporting Structures.
Assessing enterprise limitations leads to the identification of root causes and describes how enterprise
factors limit value realization.

contd.
Adjust Solution Performance Measures
Recommendations
Do Nothing Organizational Change Reduce Complexity
Eliminate Redundancy Retire the Solution
Cost vs Initial
Investment
Opportunity
Cost
Necessity Sunk Cost

contd.
Techniques
Financial
Analysis
Decision
Analysis
Prioritization
Data Mining
Risk Analysis
and
Management
Survey or
Questionnaire
Process
Analysis
Focus Groups
Organizational
Modelling

contd.Stakeholders
Stakeholders
Customer
Domain Subject
Matter Expert
End User
Sponsor
Regulator

Identify Growth
Opportunities
Time & Cost
Analysis
Automation
of processes Employee
performance
Return on
investment

Solution Performance AnalysisAssess Solution Limitations
Finalize and Implement the solution
My perfect solution

Congratulations
Congratulations on completing this course!
Keep in touch
info@spectramindsolutions.com
Thank you

Iiba cbap

More Related Content

What's hot

Similar to Iiba cbap

Recently uploaded

Iiba cbap