3.

0 Business Analysis Planning and Monitoring

3.1 Plan Business Analysis Approach

Purpose
Defines appropriate overall method to
conduct business analysis activities on a
given initiative.

Description
Describes how and when tasks will be
performed & deliverables produced.

Identifies initial set of techniques to use.

May be defined by a methodology or by

organizational standards.

May be standardized and formalized

and/or tailored to the needs of the
initiative.

May be developed in collaboration with

stakeholders to determine how work
will be completed.
 Approach should:
• Align to overall goals of the change
• Coordinate business analysis tasks with activities and
deliverables of overall change
• Include tasks that manage those risks that could
reduce business analysis deliverables quality or impede
task efficiency
• Leverage approaches and select techniques and tools
that have historically worked well

Inputs
Needs
-

Elements
Planning Approach

Formality and Level of Detail of Business

Analysis Deliverables
Business Analysis Activities
Timing of Business Analysis Work
Complexity and Risk
Acceptance
Guidelines and Tools
Business Policies: Define the limits
within which decisions must be made.
May be described by regulations,
contracts, agreements, deals,
warranties, certifications, or other
legal obligations, and can influence the
business analysis approach.

Expert Judgment: Used to determine

the optimal business analysis approach;
may be provided from a wide range of
sources including stakeholders on the
initiative, organizational Centres of
Excellence, consultants, or associations
and industry groups; prior experiences
of the business analyst and other
stakeholders should be considered
when selecting or modifying approach.
 Methodologies and Frameworks: Shape
approach used by providing methods,
techniques, procedures, working
concepts, and rules; may need to be
tailored to better meet needs of specific
business challenge.

3.2 Stakeholder Engagement Approach:

Understanding the stakeholders and
their concerns and interests may
influence decisions made when
determining approach.

3.5 Business Analysis Performance

Assessment: Provides results of
previous assessments that should
be reviewed and incorporated into all
planning approaches.

Techniques
10.1 Acceptance and
Evaluation Criteria
10.2 Backlog Management
10.3 Balanced Scorecard
10.4 Benchmarking and
Market Analysis
10.5 Brainstorming Brainstorming: Identify activities,
techniques, risks, etc.
10.6 Business Capability
Analysis
10.7 Business Cases Business Cases: Identify particular
aspects of the need or solution
10.8 Business Model
Canvas
10.9 Business Rules
Analysis

10.10 Collaborative Games

10.11 Concept Modelling
10.12 Data Dictionary
10.13 Data Flow Diagrams
10.14 Data Mining
10.15 Data Modelling
10.16 Decision Analysis
10.17 Decision Modelling
10.18 Document Analysis Document Analysis: Review existing
documents to see what can be used
10.19 Estimation Estimation: Identify how long activities
will take
10.20 Financial Analysis Financial Analysis: Determine costs of
different approaches
10.21 Focus Groups
10.22 Functional Functional Decomposition: Breakdown
Decomposition complex approaches
10.23 Glossary
10.24 Interface Analysis
10.25 Interviews Interviews: Use to help build the plan

10.26 Item Tracking Item Tracking: Track risks or issues

10.27 Lessons Learned Lessons Learned: Use past experience

with planning approaches
10.28 Metrics and Key
Performance Indicators
(KPIs)

10.29 Mind Mapping

10.30 Non-Functional
Requirements Analysis
10.31 Observation

10.32 Organizational
Modelling
10.33 Prioritization
10.34 Process Analysis

10.35 Process Modelling Process Modelling: Document the

business analysis approach
10.36 Prototyping
 10.37 Reviews Reviews: Validate the selected
approach
10.38 Risk Analysis and Risk Analysis and Management: Used
Management to assess risks

10.39 Roles and

Permissions Matrix
10.40 Root Cause Analysis

10.41 Scope Modelling Scope Modeling: Used to determine

boundaries
10.42 Sequence Diagrams
10.43 Stakeholder List,
Map, or Personas
10.44 State Modelling
10.45 Survey or Survey or Questionnaire: Identify
Questionnaire activities, risks, techniques, etc
10.46 SWOT Analysis
10.47 Use Cases and
Scenarios
10.48 User Stories
10.49 Vendor Assessment
10.50 Workshops Workshops: Used to help build the plan

Stakeholders
Business Analyst The business analyst is inherently a stakeholder in all business analysis activities.
Customer

Domain Subject Matter Domain Subject Matter Expert:

Expert Approach may depend on availability
and level of involvement.

End User

Implementation Subject
Matter Expert
Operational Support
 Project Manager Project Manager: Determines that
approach is realistic for overall schedule
and timelines; approach must be
compatible with other activities.

Regulator Regulator: May provide approval for

aspects of approach, especially where
process is audited.

Sponsor Sponsor: Can provide objectives for

approach and ensure organizational
policies are followed; may depend on
availability and involvement with
initiative.

Supplier

Tester
Other
Outputs
3.1 Business Analysis Approach

Tasks Using outputs

3.2 Stakeholder Engagement Approach

3.3 Governance Approach

3.4 Information Management Approach

3.5 Business Analysis Performance

Assessment
4.1 Prepare for Elicitation
4.2 Conduct Elicitation
4.4 Communicate Business Analysis
Information
4.5 Manage Stakeholder Collaboration
6.1 Analyze Current State
6.3 Assess Risks
6.4 Define Change Strategy
ng and Monitoring
3.2 Plan Stakeholder Engagement 3.3 Plan Business Analysis Governance

Plan approach for establishing and Define how decisions are made about
maintaining effective working requirements and designs, including
relationships with the stakeholders. reviews, change control, approvals, and
prioritization.

Conduct thorough stakeholder analysis Ensure that governance process is in

to identify all involved stakeholders and place and clarify any ambiguities within
analyze their characteristics. it.

Use to define best collaboration and Identifies decision makers, process, and
communication approaches for initiative information required for decisions to be
and appropriately plan for stakeholder made.
risks.

Degree of complexity can increase as Describes how approvals and

the number of stakeholders involved prioritization decisions are made for
increases. requirements and designs.

Important since new or different When planning the governance

techniques for stakeholder
management may be required when
engagement moves from collaborating prioritized
with a few stakeholders to many.
approach, identify:
• How business analysis work will be approached and
• Process for proposing a change to business analysis
information
• Who has authority and responsibility to propose
changes and who should be involved in the change
discussions
• Who has responsibility for analyzing change requests
• Who has authority to approve changes
• How changes will be documented and communicated
Needs
3.1 Business Analysis Approach 3.1 Business Analysis Approach
3.2 Stakeholder Engagement Approach

Perform Stakeholder Analysis Decision Making

Roles Change Control Process

Attitudes Plan Prioritization Approach

Decision Making Authority Plan for Approvals
Level of Power or Influence
Define Stakeholder Collaboration
Stakeholder Communication Needs

Business Policies: Define the limits

within which decisions must be made.
May be described by regulations,
contracts, agreements, warranties,
certifications or other legal obligations.

3.5 Business Analysis Performance
Assessment: Provides results of
previous assessments that should
be reviewed and incorporated into all
planning approaches.
6.1 Current State Description: Provides
context within which the work needs to
be completed. Leads to more effective
stakeholder analysis and better
understanding of impact of desired
change.
6.4 Change Strategy: Used for improved
assessment of stakeholder impact
and development of more effective
stakeholder engagement strategies.
Brainstorming: Used to produce
stakeholder list
Legal/Regulatory Information:
Describes legislative rules or regulations
that must be followed, and can be used
to help develop a framework that
ensures sound business decision
making.
3.5 Business Analysis Performance
Assessment: Provides results of
previous assessments that should
be reviewed and incorporated into all
planning approaches.
6.1 Current State Description: Provides
context within which the work needs to
be completed. This information can help
drive how to make better decisions.
Brainstorming: Identify approvers in the
governance process
Business Rules Analysis: Identify
stakeholders who are sources of
business rules

Document Analysis: Existing documents Document Analysis: Evaluate existing

used to plan engagement governance process

Interviews: Used to gain more Interviews: Help identify approaches

information about stakeholders
Lessons Learned: Use previous
experience with stakeholders
Item Tracking: Track issues related to
governance planning
Lessons Learned: Use previous
experience with governance

Mind Mapping: Identify stakeholders

and relationships

Organizational Modelling: Used to Organizational Modelling: Use to

identify stakeholders understand roles and responsibilities

Process Modelling: Use to categorize Process Modelling: Use to document

stakeholders the process
 Reviews: Review governance process
with key stakeholders
Risk Analysis and Management: Identify
stakeholder related risks

Scope Modelling: Used to define

boundaries

Stakeholder List, Map, or Personas:

Depict stakeholder relationships

Survey or Questionnaire: Identify Survey or Questionnaire: Use to identify

shared characteristics process and approvers

Workshops: Used to gain more Workshops: Use to identify process and

information approvers

ently a stakeholder in all business analysis activities.

Customer: Source of external
stakeholders
Domain Subject Matter Expert: Helps Domain Subject Matter Expert: May be
identify stakeholders; may fulfill one or a possible source of requested change
more roles on initiative or may be identified as needing to be
involved in change discussions.

End User: Source of internal

stakeholders
Project Manager: May identify and
recommend stakeholders; may share
responsibility for stakeholder
identification and management with
business analyst
Project Manager: Works with business
analyst to ensure that overall project
governance aligns with governance
approach.

Regulator: May require specific Regulator: May impose rules or

stakeholders or groups be involved in regulations that need to be considered
activities when determining the governance plan;
may also be possible source of
requested change.

Sponsor: May request specific Sponsor: Can impose their own

stakeholders be involved in activities requirements for how information
should be managed; participates in
change discussions and approves
proposed changes.

Supplier: Source of external

stakeholders

3.2 Stakeholder Engagement Approach 3.3 Governance Approach

3.1 Business Analysis Approach

3.3 Governance Approach

3.4 Information Management Approach 3.4 Information Management Approach

4.1 Prepare for Elicitation

4.2 Conduct Elicitation
4.4 Communicate Business Analysis
Information
4.5 Manage Stakeholder Collaboration
 5.3 Prioritize Requirements
5.4 Assess Requirements Changes
5.5 Approve Requirements

6.3 Assess Risks

6.4 Define Change Strategy
3.4 Plan Business Analysis Information 3.5 Identify Business Analysis
Management Performance Improvements

Develop an approach for how business Assess business analysis work and plan
analysis information will be to improve processes where
stored and accessed. required.

Comprised of all the information that To monitor and improve performance,

business analysts elicit, create, compile, it’s necessary to:
and disseminate in the course of • Establish performance measures
performing business analysis; examples: •• Conduct the performance analysis
Report on the results of the analysis
models, scope statements, stakeholder • Identify necessary preventive, corrective, or
concerns, elicitation results, developmental actions
requirements, designs, solution options,
requirements, designs, user stories,
formal requirement documents,
functioning prototypes, etc.

Information management entails Performance analysis should occur

identifying: throughout an initiative. Once potential
• How information should be organized, performance improvements are
• The level of detail at which information should be
captured, identified, they become guidelines for
• Any relationships between the information, the next time a task is executed.
• How information may be used across multiple
initiatives and throughout the enterprise,
• How information should be accessed and stored,
• Characteristics about the information that must be
maintained

Information management helps ensure

that business analysis information is
organized in a functional and useful
manner, is easily accessible to
appropriate personnel, and is stored for
the necessary length of time.
3.1 Business Analysis Approach 3.1 Business Analysis Approach
3.2 Stakeholder Engagement Approach

3.3 Governance Approach

Performance Objectives (external)

Organization of Business Analysis Performance Analysis

Information
Level of Abstraction Assessment Measures

Plan Traceability Approach Analyze Results

Plan for Requirements Reuse Recommend Actions for Improvement
Storage and Access
Requirements Attributes

Business Policies: Define the limits

within which decisions must be made.
May be described by regulations,
contracts, agreements, warranties,
certifications, or other legal obligations.

Information Management Tools: Each

organization uses some tools to store,
retrieve, and share business analysis
information. These may be as simple as
a whiteboard, or as complex as a global
wiki or robust requirements
management tool.
Legal/Regulatory Information:
Describes legislative rules or regulations
that must be followed, and helps
determine how business analysis
information will be managed.

Organizational Performance Standards:

May include performance metrics or
expectations for business analysis work
mandated by the organization.

3.5 Business Analysis Performance

Assessment: Provides results of
previous assessments that should
be reviewed and incorporated into all
planning approaches.

Brainstorming: Used to uncover needs Brainstorming: Generate ideas for

improvement
Interviews: Used to uncover needs
Item Tracking: Track issues related to
current management processes
Lessons Learned: Source of past
experiences
Mind Mapping: Categorize information
to be managed
Process Modelling: Use to document
the management process
Interviews: Gather assessments of
performance
Item Tracking: Issues related to business
analysis performance
Lessons Learned: Recommended
changes based on past performance
Metrics and Key Performance
Indicators (KPIs): Determine
appropriate metrics for measuring
performance
Observation: Witness business analysis
performance
Process Analysis: Analyze existing
business analysis processes
Process Modelling: Used to modify
existing processes

Survey or Questionnaire: Input into
defining information management
Workshops: Use to uncover needs
Domain Subject Matter Expert: May
need to access and work with business
analysis information, and will be
interested in a more specific view of
business analysis information which
relates to their area of expertise.
Reviews: Use to identify improvements
Risk Analysis and Management: Use to
manage conditions that may impact
performance
Root Cause Analysis: Identify causes of
failure
Survey or Questionnaire: Use to gather
feedback
Workshops: Gather assessments and
determine improvements
Domain Subject Matter Expert:
Informed about BA activities to set
expectations regarding their
involvement in the work and to elicit
their feedback regarding possible
improvements to the approach.
 Project Manager: Is accountable for the
success of a project and must be kept
informed of the current status of
business analysis work. If potential
problems or opportunities for
improvement are identified, the project
manager must be consulted before
changes are implemented to assess
whether those changes will have an
impact on the project. They may also
deliver reports on business analysis
performance to the sponsor and other
stakeholders.

Regulator: May define rules and

processes related to information
management.

Sponsor: Reviews, comments on, and Sponsor: May require reports on

approves business analysis information. business analysis performance to
address problems as they are
identified.
Note: A manager of business analysts
may also sponsor initiatives to improve
the performance of business analysis
activities.

3.4 Information Management Approach 3.5 Business Analysis Performance

Assessment

3.1 Business Analysis Approach

3.2 Stakeholder Engagement Approach

3.3 Governance Approach

3.4 Information Management Approach

4.4 Communicate Business Analysis

Information
4.5 Manage Stakeholder Collaboration

5.1 Trace Requirements

5.2 Maintain Requirements
7.4 Define Requirements Architecture
 4.0 Elicitation and Collaboration
4.1 Prepare for Elicitation

Purpose
To understand the scope of the
elicitation activity, select appropriate
techniques, and plan for (or procure)
appropriate supporting materials and
resources.

Description
Business analysts prepare for elicitation
by defining the desired outcomes of the
activity, considering the stakeholders
involved and the goals of the initiative.

This task includes:

• Determining which work products will be produced
using the elicitation results
• Deciding which techniques are best suited to produce
those results
• Establishing the elicitation logistics
• Identifying any supporting materials needed
• Understanding circumstances to foster collaboration
Inputs
Needs

3.2. Stakeholder Engagement Approach

Elements
Understand the Scope of Elicitation

Select Elicitation Techniques

Set Up Logistics
Secure Supporting Material
Prepare Stakeholders
Guidelines and Tools
Business Objectives: Describe the
desired direction needed to achieve the
future state.
Existing Business Analysis Information:
May provide a better understanding
of the goals of the elicitation activity,
and aid in preparing for elicitation.

3.1 Business Analysis Approach: Sets

the general strategy to be used to guide
the business analysis work.

6.2 Potential Value: Describes the value

to be realized by implementing the
proposed future state, and can be used
to shape elicitation events.
Techniques
10.1 Acceptance and
Evaluation Criteria
10.2 Backlog Management
10.3 Balanced Scorecard
10.4 Benchmarking and
Market Analysis

10.5 Brainstorming Brainstorming: Used to collaboratively

identify and reach consensus about
which sources of business analysis
information should be consulted and
which elicitation techniques might be
most effective.

10.6 Business Capability

Analysis
10.7 Business Cases
10.8 Business Model
Canvas
10.9 Business Rules
Analysis

10.10 Collaborative Games

10.11 Concept Modelling

10.12 Data Dictionary

10.13 Data Flow Diagrams
10.14 Data Mining Data Mining: Used to identify
information or patterns that require
further investigation.
10.15 Data Modelling
10.16 Decision Analysis
10.17 Decision Modelling
10.18 Document Analysis Document Analysis: Used to identify
and assess candidate sources of
supporting materials.

10.19 Estimation Estimation: Used to estimate the time

and effort required for the elicitation
and the associated cost.
10.20 Financial Analysis
10.21 Focus Groups

10.22 Functional
Decomposition
10.23 Glossary
10.24 Interface Analysis

10.25 Interviews Interviews: Used to identify concerns

about the planned elicitation, and can
be used to seek authority to proceed
with specific options.

10.26 Item Tracking

10.27 Lessons Learned

10.28 Metrics and Key

Performance Indicators
(KPIs)
10.29 Mind Mapping Mind Mapping: Used to collaboratively
identify and reach consensus about
which sources of business analysis
information should be consulted and
which elicitation techniques might be
most effective

10.30 Non-Functional
Requirements Analysis
10.31 Observation

10.32 Organizational
Modelling
10.33 Prioritization
10.34 Process Analysis

10.35 Process Modelling

10.36 Prototyping

10.37 Reviews

10.38 Risk Analysis and Risk Analysis and Management: Used

Management to identify, assess, and manage
conditions or situations that could
disrupt the elicitation, or affect the
quality and validity of the elicitation
results.

10.39 Roles and

Permissions Matrix
10.40 Root Cause Analysis
10.41 Scope Modelling
10.42 Sequence Diagrams
10.43 Stakeholder List, Stakeholder List, Map, or Personas:
Map, or Personas Used to determine who should be
consulted while preparing for the
elicitation, who should participate in the
event, and the appropriate roles for
each stakeholder.

10.44 State Modelling

10.45 Survey or
Questionnaire

10.46 SWOT Analysis

10.47 Use Cases and
Scenarios
10.48 User Stories
10.49 Vendor Assessment
 10.50 Workshops

Stakeholders
Business Analyst The business analyst is inherently a stakeholder in all business analysis activities.
Customer

Domain Subject Matter Domain Subject Matter Expert:

Expert Provides supporting materials as well as
guidance about which other sources of
business analysis information to consult.
May also help to arrange research,
experiments, and facilitated elicitation.

End User

Implementation Subject
Matter Expert

Operational Support
Project Manager Project Manager: Ensures that the
appropriate people and resources are
available to conduct the elicitation.
Regulator
Sponsor Sponsor: Has the authority to approve
or deny a planned elicitation event.
Authority to authorize and require the
participation of specific stakeholders.

Supplier
Tester
 Other

Outputs
4.1 Elicitation Activity Plan

Tasks Using outputs

4.2 Conduct Elicitation
4.3 Confirm Elicitation Results
tion
4.2 Conduct Elicitation 4.3 Confirm Elicitation Results

To draw out, explore, and identify To check the information gathered

information relevant to the change. during an elicitation session for accuracy
and consistency with other information.

There are three common types of Elicited information is confirmed to

elicitation: identify any problems and resolve them
• Collaborative: involves direct interaction with before resources are committed to
stakeholders, and relies on their experiences, expertise, using the information.
and judgment.
• Research: involves systematically discovering and
studying information from materials or sources that are
not directly known by stakeholders involved in the
change. Stakeholders might still participate in the
research. Research can include data analysis of
historical data to identify trends or past results
• Experiments: involves identifying information
that could not be known without some sort of
controlled test. Some information cannot be drawn
from people or documents—because it is unknown.
Experiments can help discover this kind of information.
Experiments include observational studies, proofs of
concept, and prototypes

One or more elicitation techniques may Elicitation results can be compared

be used to produce the desired against their source and other elicitation
outcome within the scope of elicitation. results to ensure consistency.

Stakeholders may collaborate in Collaboration with stakeholders might

elicitation by:
• Participating and interacting during the elicitation
activity
• Researching, studying, and providing feedback on
documents, systems, models, and interfaces.
be necessary to ensure their inputs are
correctly captured and that they agree
with the results of non-facilitated
elicitation.

This review may discover errors,

omissions, conflicts, and ambiguity.
 If information is not correct or
inconsistent, the business analyst
determines what is correct, which can
require more elicitation to determine
the correct information or resolve the
discrepancies, respectively.

Committing resources to business

analysis activities based on unconfirmed
elicitation results may mean stakeholder
expectations are not met.

Confirming the elicitation results is a

much less rigorous and formal review
than what occurs during analysis (for
more information, see 7.1 Specify and
Model Requirements).

4.1 Elicitation Activity Plan

4.2 Elicitation Results (unconfirmed)

Guide Elicitation Activity Compare Elicitation Results Against

Source Information
Capture Elicitation Outcomes Compare Elicitation Results Against
Other Elicitation Results
Existing Business Analysis Information:
May guide the questions posed during
elicitation and the approach used to
draw out information from various
stakeholders.
Existing Business Analysis Information:
Used to confirm the results of elicitation
activities. Used to develop additional
questions to draw out more detailed
information.

Supporting Materials: Includes any

materials to prepare both the business
analyst and participants before
elicitation. Includes any information,
tools, or equipment to be used during
the elicitation.

3.1 Business Analysis Approach:

Influences how each elicitation activity
is performed, as it identifies the types of
outputs that will be needed based on
the approach.

3.2 Stakeholder Engagement Approach:

Provides collaboration and
communication approaches that might
be effective during elicitation.

4.1 Elicitation Activity Plan: Used to

guide which alternative sources and
which elicitation results are to be
compared.
Benchmarking and Market analysis:
Source of information used to compare
specific processes, systems, services,
structure with an external baseline.
Determines customer wants and what
competitors provide.

Brainstorming: Generates many ideas in

a short period of time. Allows for
organization and prioritization of those
ideas.

Business Rules Analysis: Identifies rules

used to govern decisions. Rules define,
constrain, enable operations.
Collaborative Games: Develops a better
understanding of a problem. Stimulate
creative solutions

Concept Modeling: Identifies key terms

and ideas of importance. Defines the
relationship of the key terms and ideas

Data Mining: Used to identify pertinent

information and patterns

Data Modeling: Used to understand

relationships
Document Analysis: Review of existing Document Analysis: Used to confirm
systems, contracts, business elicitation results against source
procedures, policies, standards, and information or other existing
regulations. documents.

Focus Groups: Identify and understand

ideas and attitudes.

Interface Analysis: Aids in

understanding the interaction, and the
characteristics of that interaction
between two entities.
• Systems
• Roles
• Organization

Interviews: Used to ask questions and Interviews: Used to confirm the

uncover needs of stakeholders. business analysis information and to
Identities problems. Uncovers additional confirm that the integration of that
opportunities information is correct.

Mind Mapping: Used to generate many

ideas from a group in limited amount of
time. Organize and prioritize ideas

Observation: Gain insight how current

process is done in different
environments or circumstances
Process Analysis: Understanding the
current process and to identify
opportunities for improvement.
Process Modeling: Used to elicit
processes from participants during
activities.
Prototyping: Elicit and validate needs
through an iterative process. Creates a
model or requirements or designs.
Reviews: Used to confirm a set of
elicitation results. Such reviews could be
informal or formal depending on the
risks of not having correct, useful, and
relevant information.

Survey or Questionnaire: Elicit business

analysis information thru a series of
questions. Large audience in a short
amount of time. Provides information
about customers, products, practices,
and attitudes.
 Workshops: Elicit business analysis
information thru a more structured and
facilitated method. Provides
information about customers, products,
practices, and attitudes.
Workshops: Used to conduct reviews of
the drafted elicitation results using any
level of formality. A predetermined
agenda, scripts, or scenario tests may be
used to walk through the elicitation
results, and feedback is requested from
the participants and recorded.

ently a stakeholder in all business analysis activities.

Customer: Will provide valuable
business analysis information during
elicitation.
Domain Subject Matter Expert: Has Domain Subject Matter Experts: People
expertise in some aspect of the situation with substantial knowledge, experience,
and can provide the required business or expertise about the business analysis
analysis information. Often guides and information being elicited, or about the
assists the business analyst in change or the solution, help to confirm
identifying appropriate research that elicitation results are correct, and
sources, and may help to arrange can help to identify omissions,
research, experiments, and facilitated inconsistencies and conflicts in
elicitation. elicitation results. They can also confirm
that the right business analysis
information has been elicited.

End User: User of existing and future

solutions, who should participate in
elicitation.
Implementation Subject Matter Expert:
Designs and implements a solution and
provides specialist expertise. Can
participate in elicitation by asking
clarifying questions and offering
alternatives.

Sponsor: Authorizes and ensures that

the stakeholders necessary to
participate in elicitation are involved.
Any Stakeholders: Could have relevant Any stakeholder: All types of
knowledge or experience to participate stakeholders may need to participate in
in elicitation activities. confirming elicitation results.

4.2 Elicitation Results (unconfirmed) 4.3 Elicitation Results (confirmed)

4.3 Confirm Elicitation Results

6.1 Analyze Current State
6.3 Assess Risks
4.4 Communicate Business Analysis
Information
To ensure stakeholders have a shared
understanding of business analysis
information.
Business analysts must communicate
appropriate information to stakeholders
at the right time and in formats that
meet their needs.
Consideration is given to expressing the In this task, the business analyst does
information in language, tone, and style the following with stakeholders:
that is appropriate to the audience.
Communication of business analysis
information is bi-directional and
iterative. It involves determining:
• Recipients
• Content
• Purpose
• Context
• Expected outcomes
Communicating information does not
simply involve pushing information out
and assuming it was received and
understood.
4.5 Manage Stakeholder Collaboration
To encourage stakeholders to work
towards a common goal.
Business analysis work lends itself to
many collaboration opportunities
between groups of stakeholders on the
business analysis work products.
Stakeholders hold various degrees of
influence and authority over the
approval of work products, and are also
an important source of needs,
constraints, and assumptions.
• Identifies stakeholders
• Confirms their roles
• Communicates with them to ensure that the right
stakeholders participate at the right times and in the
appropriate roles
This is an ongoing activity.
• Begins once stakeholders have been identified and
analyzed, new stakeholders may be identified at any
point during an initiative.
• As new stakeholders are identified, their role,
influence, and relationship to the initiative are
analyzed.
• Each stakeholder's role, responsibility, influence,
attitude, and authority may change over time.
• The more significant the impact of the change or its
visibility within the organization, the more attention is
directed to managing stakeholder collaboration.
• Business analysts manage stakeholder collaboration
to capitalize on positive reactions, and mitigate or avoid
negative reactions.
Business analyst should constantly
monitor and assess each stakeholder’s
attitude to determine if it might affect
their involvement in the business
analysis activities.
Task 3.2 Plan Stakeholder Engagement
evaluates communication needs and
plans anticipated messages.
In communication, business analysts:
• Engage stakeholders to ensure they understand the
information and gain agreement
• Act on any disagreements
The method of delivering the
information may need to change if the
stakeholders are not receiving or
understanding it.
Multiple forms of communication might
be required for the same information.
Business Analysis Information
3.2. Stakeholder Engagement Approach 3.2. Stakeholder Engagement Approach
Determine Objectives and Format of
Communication
Communicate Business Analysis Package Monitor Stakeholder Engagement
Poor relationships with stakeholders can
have many detrimental effects on
business analysis, including:
• failure to provide quality information
• strong negative reactions to setbacks and obstacles
• resistance to change
• lack of support for, and participation in, business
analysis work
• business analysis information being ignored
Effects of poor relationships with
stakeholders can be modified in part
through strong, positive, and trust-
based relationships with stakeholders.
Business analysts actively manage
relationships with stakeholders who:
• Provide services to the business analyst, including
inputs to business analysis tasks and other support
activities
• Depend on services provided by the business analyst,
including outputs of business analysis tasks
• Participate in the execution of business analysis tasks
3.5 Business Analysis Performance
Assessment
Gain Agreement on Commitments
Collaboration
Business Objectives: Describe the
desired direction needed to achieve the
future state. They can be used to focus
diverse stakeholders on a common
vision of the desired business outcomes.
3.1 Business Analysis Approach: 3.1 Business Analysis Approach:
Describes how the various types of Describes the nature and level of
information will be disseminated rather collaboration required from each
than what will be disseminated. stakeholder group to perform planned
Describes the level of detail and business analysis activities.
formality required, frequency of the
communications, and how
communications could be affected by
the number and geographic dispersion
of stakeholders.

3.4 Information Management

Approach: Helps determine how
business analysis information will be
packaged and communicated to
stakeholder.

6.2 Future State Description: Defines

the desired future state and the
expected value it delivers which can be
used to focus diverse stakeholders on
the common goal.

6.3 Risk Analysis Results: Stakeholder-

related risks will need to be addressed
to ensure stakeholder collaboration
activities are successful.
8.5 Recommended Actions:
Communicating what should be done to
improve the value of a solution can help
to galvanize support and focus
stakeholders on a common goal.

Collaborative Games: Used to stimulate

teamwork and collaboration by
temporarily immersing participants in a
safe and fun situation in which they can
share their knowledge and experience
on a given topic, identify hidden
assumptions, and explore that
knowledge in ways that may not occur
during the course of normal
interactions.
Interviews: Used to individually
communicate information to
stakeholders.

Lessons Learned: Used to understand

stakeholders' satisfaction or
dissatisfaction, and offer them an
opportunity to help improve the
working relationships.
Reviews: Used to provide stakeholders
with an opportunity to express
feedback, request required
adjustments, understand required
responses and actions, and agree or
provide approvals. Reviews can be used
during group or individual collaboration.

Risk Analysis and Management: Used

to identify and manage risks as they
relate to stakeholder involvement,
participation, and engagement.

Stakeholder List, Map, or Personas:

Used to determine the following:
• Who is available to participate in the business analysis
work
• Show the informal relationships between
stakeholders
• Understand which stakeholders should be consulted
about different kinds of business analysis information
Workshops: Used to provide
stakeholders with an opportunity to
express feedback and to understand
required adjustments, responses, and
actions. They are also useful for gaining
consensus and providing approvals.
Typically used during group collaborate.

Customer: Needs to be communicated All Stakeholders: All types of

with frequently so they are aware of stakeholders who might be involved in
relevant business analysis information. collaboration during change.
Domain Subject Matter Expert: Needs
to understand the business analysis
information as part of confirming and
validating it throughout the change
initiative.

End User: Needs to be communicated

with frequently so they are aware of
relevant business analysis information.
Implementation Subject Matter Expert:
Needs to be aware of and understand
the business analysis information,
particularly requirements and designs,
for implementation purposes.

Tester: Needs to be aware of and

understand the business analysis
information, particularly requirements
and designs for testing purposes.
Any stakeholder: All types of
stakeholders will likely need to be
communicated with at some point
during the change initiative.

4.4 Business Analysis Information 4.5 Stakeholder Engagement

(communicated)

- -
 5.0 Requirements Lifecycle Management
5.1 Trace Requirements
Purpose
Ensure that requirements and design at
different levels are aligned to one
another.
Manage the effects of change to one
level on related requirements.

Description
Identify and document the lineage of
each requirement, including its
backward traceability, its forward
traceability, and its relationship to
other requirements.

While traceability is valuable, the

business analyst balances the
number of relationship types with the
benefit gained by representing
them.

Requirements Traceability is used:

• To help ensure that the solution conforms to the
requirements
• To assist in scope, change, risk, time, cost and
communication management
• To detect missing functionality or to identify if there is
implemented functionality that is not supported by any
requirement

Requirements Traceability enables:

• Faster and simpler impact analysis
• More reliable discovery of inconsistencies and gaps in
requirements
• Deeper insights into the scope and complexity of a
change
• Reliable assessment of which requirements have been
addressed and
which have not

Traceability also supports both

requirements allocation and release
planning by providing a direct line of
sight from requirement to expressed
need.

Inputs
Requirements

Designs

Elements
Level of Formality
Relationships
Traceability Repository

Guidelines and Tools

 Domain Knowledge: Knowledge of and
expertise in the business domain need
to support traceability.
Legal/Regulatory Information:
Legislative rules or regulations that must
be followed and taken into
consideration when defining traceability
rules.

Requirements Management
Tools/Repository: Storage and
management of business analysis
information. May be as simple as a text
document or as complex as a dedicated
requirements management tool.

3.4 Information Management

Approach: Decisions made from
planning activities that may influence
the traceability approach.

Techniques
10.1 Acceptance and
Evaluation Criteria
10.2 Backlog Management

10.3 Balanced Scorecard

10.4 Benchmarking and
Market Analysis
10.5 Brainstorming
10.6 Business Capability
Analysis
10.7 Business Cases

10.8 Business Model

Canvas
10.9 Business Rules Business Rules Analysis: Used to trace
Analysis business rules to requirements that
they support, or rules that support
requirements.

10.10 Collaborative Games

10.11 Concept Modelling
10.12 Data Dictionary
10.13 Data Flow Diagrams

10.14 Data Mining

10.15 Data Modelling

10.16 Decision Analysis

10.17 Decision Modelling

10.18 Document Analysis

10.19 Estimation

10.20 Financial Analysis

10.21 Focus Groups

10.22 Functional Functional Decomposition: Used to
Decomposition break down solution scope into smaller
components for allocation. Also used to
trace high-level concepts to low-level
concepts.

10.23 Glossary
10.24 Interface Analysis

10.25 Interviews
10.26 Item Tracking

10.27 Lessons Learned

10.28 Metrics and Key
Performance Indicators
(KPIs)
10.29 Mind Mapping
10.30 Non-Functional
Requirements Analysis
10.31 Observation
10.32 Organizational
Modelling
10.33 Prioritization

10.34 Process Analysis

10.35 Process Modelling Process Modelling: Used to visually
show the future state process. Also used
to trace requirements to future state
process.

10.36 Prototyping
10.37 Reviews

10.38 Risk Analysis and

Management

10.39 Roles and

Permissions Matrix
10.40 Root Cause Analysis
10.41 Scope Modelling Scope Modelling: Used to visually depict
scope. Also used to trace requirements
to the area of scope the requirement
supports.

10.42 Sequence Diagrams

10.43 Stakeholder List,
Map, or Personas
10.44 State Modelling
10.45 Survey or
Questionnaire
10.46 SWOT Analysis
10.47 Use Cases and
Scenarios

10.48 User Stories

10.49 Vendor Assessment

10.50 Workshops
Stakeholders
Business Analyst The business analyst is inherently a stakeholder in all business analysis activities.
Customer Customers: are affected by how and
when requirements are implemented,
and may have to be consulted.

Domain Subject Matter Domain Subject Matter Expert: may

Expert have recommendations.

End User End User: may require specific

dependency relationships to be
implemented.
Implementation Subject Implementation Subject
Matter Expert Matter Expert: ensures that
the solution being developed
meets the business needs.
Operational Support Operational Support: have
reference source (traceability
documentation) for help desk
support.

Project Manager Project Manager: can leverage

traceability for project change and
scope management.
Regulator

Sponsor Sponsor: is required to approve the

various relationships.

Supplier Suppliers: are affected by how and

when requirements are implemented.
Tester Tester: needs to understand how and
where requirements are implemented,
and may trace test cases to
requirements

Outputs
5.1 Requirements (traced)

5.1 Designs (traced)

Tasks Using outputs

7.5 Define Design Options

Management
5.2 Maintain Requirements 5.3 Prioritize Requirements

Retain requirement accuracy and Rank requirements in the order of

consistency throughout and beyond relative importance.
the change during the entire
requirements life cycle. Support reuse
of requirements in other solutions.

A requirement that represents an Prioritization is the act of ranking

ongoing need must be maintained to requirements to determine their
ensure that it remains valid over time. relative importance to stakeholders.

A requirement must be: consistently Priority can refer to the relative value of
represented, reviewed and approved for a requirement or to the sequence in
maintenance, and easily accessible and which a requirement will be
understandable. implemented.

Prioritization is an ongoing process.

Requirements Requirements

Designs Designs

Maintain Requirements Basis for Prioritization

Maintain Attributes Challenges of Prioritization
Reusing Requirements Continual Prioritization
 Business Constraints: Regulatory
statutes, contractual obligations and
business policies.
Domain Knowledge: Knowledge and
expertise of the business domain.

Requirements Management
Tools/Repository: Priority can help to
sort and access requirements.

3.3 Governance Approach: Outlines the

approach for prioritizing requirements.

3.4 Information Management

Approach: Indicates how requirements
will be managed for reuse.

6.4 Change Strategy: Provides

information on costs, timelines and
value realization.

6.4 Solution Scope: Considered in

prioritization to ensure scope is
managed.

7.4 Requirements Architecture: Utilized

to understand the relationship with
other
requirements and work products.

Backlog Management: Backlog is used

to compare requirements. Backlog is a
location where requirements can be
maintained.
 Business Cases: Used to assess
requirements against identified business
goals and objectives.

Business Rules Analysis: Identify similar

business rules across the enterprise.

Data Flow Diagrams: Identify similar

information flows across the enterprise.

Data Modeling: Identify similar data

structures across the enterprise.
Decision Analysis: Used to identify high-
value requirements.

Document Analysis: Analyze existing

documentation about an enterprise.

Estimation: Estimates can be the basis

for prioritization.
Financial Analysis: Used to assess
financial value of a set of requirements
and how the timing of delivery will
affect that value.

Functional Decomposition: Identify

requirements associated with the
components.

Interviews: Used to gain an

understanding.
 Item Tracking: Used to track issues.

Prioritization: Used to facilitate the

process of prioritization.

Process Modelling: Identify

requirements associated with the
processes.

Risk Analysis and Management: Used

to understand the risks.

Use Cases and Scenarios: Identify a

solution component that may be reused
by more than one solution.
User Stories: Identify requirements
associated with the story.

Workshops: Used to gain an

understanding of stakeholders’ basis of
prioritization or priorities in a facilitated
group setting.
ently a stakeholder in all business analysis activities.
Customer: verifies delivered value of
prioritized requirements from a
customer perspective and can negotiate
to change the priority.

Domain Subject Matter Expert:

references maintained requirements.

End User: verifies delivered value of

prioritized requirements from an end-
user perspective.
Implementation Subject Matter Expert: Implementation Subject Matter Expert:
utilizes maintained requirements. provides inputs relating to technical
dependencies.

Operational Support: confirms the

current state.

Project Manager: uses prioritization as

inputs into the project plan and
allocation of requirements to releases.
Regulator: confirms compliance to Regulator: verifies that the prioritization
standards. is consistent with legal and regulatory
constraints.

Sponsor: verifies delivered value of

prioritized requirements from an
organizational perspective.

Tester: uses maintained requirements in

test plan and test case creation.

5.2 Requirements (maintained) 5.3 Requirements (prioritized)

5.2 Designs (maintained) 5.3 Designs (prioritized)

- 6.3 Assess Risks

5.4 Assess Requirements Changes 5.5 Approve Requirements

Evaluate the implications of proposed Obtain agreement on and approval of

changes to requirements and requirements and designs for business
designs. analysis work to continue and/or
solution construction to proceed.

Assessment is performed as new needs Approval of requirements may be

or possible solutions are formal or informal.
identified.

Business analysts assess the potential
effect of the change to solution
value and whether the change
introduces conflicts or increase the level
of risk.
Business analysts work with key
stakeholders to gain consensus on
new and changed requirements,
communicate the outcome of
discussions, and track and manage the
approval.

Considerations when assessing changes:

• Aligns with the overall strategy.
• Affects value delivered to the business or stakeholder
groups.
• Impacts the time or resources required to deliver.
• Alters any risks, opportunities or constraints.

Requirements
Requirements (verified)
Designs Designs
Proposed Change

Assessment Formality Understand Stakeholder Roles

Impact Analysis Conflict and Issue Management
Impact Resolution Gain Consensus
Track and Communicate Approval
Domain Knowledge: Knowledge of and
expertise in the business domain is
needed to perform assessment.
Legal/Regulatory Information: Legal/Regulatory Information:
Describes legislative rules or regulations Describes legislative rules or regulations
that must be followed. that must be followed.

Requirements Management
Tools/Repository: Tool to record
requirements approvals.

3.3 Governance Approach: Provides 3.3 Governance Approach: Identifies

guidance on change control, decision
making processes as well as stakeholder
roles within the process.
stakeholders who have the authority
and responsibility to approve.
Explains when such approvals will take
place and how they will align to
organizational policies.

6.4 Change Strategy: Sets the purpose 6.4 Change Strategy: Provides
and direction for changes. Establishes information which assists in managing
context. Identifies critical components. stakeholder consensus.

6.4 Solution Scope: Must be considered 6.4 Solution Scope: Must be considered
to fully understand the impact of a when approving requirements to
proposed change. accurately assess alignment and
completeness.

7.4 Requirements Architecture:

Business analyst examines and analyzes
the requirements relationships to
determine which requirements will be
impacted.

Acceptance and Evaluation Criteria:

Used to define approval criteria
Business Case: Used to justify a
proposed change.

Business Rules Analysis: Assess changes

to business policies and business rules
and develop revised guidance.

Decision Analysis: Used to facilitate Decision Analysis: Used to resolve

change assessment process. issues and gain agreement.

Document Analysis: Used to analyze

any existing documents that facilitate an
understanding of the change’s impact.

Estimation: Used to determine the size

of the change.
Financial Analysis: Used to estimate
financial consequences.

Interface Analysis: Used to identify

interfaces that can be affected by the
change.
Interviews: Used to gain an
understanding of the impact from a
single or small group of stakeholders.
Item Tracking: Used to track any issues Item Tracking: Used to track identified
or conflicts discovered during impact issues.
analysis.

Reviews: Used to evaluate

requirements.
Risk Analysis and Management: Used
to determine the level of risk associated
with the change.

Workshops: Used to gain understanding Workshops: Used to facilitate obtaining

of the impact or to resolve changes in a approval.
group setting.
Customers: provide feedback Customers: may play an active role in
concerning the impact the change will reviews and approvals of requirements
have on value. and designs.

Domain Subject Matter Expert: can
provide insight on how the change will
impact the organization and value.
End User: can offer information about
the impact on their activities.
Domain Subject Matter Expert: may be
involved in the reviews and approvals.
End User: may be involved in the
review, validation and prioritization of
requirements and designs.

Operational Support: provides Operational Support: is responsible for

information on both their ability to ensuring that requirements and designs
support and their need to understand are supportable.
the nature of the change to be able to
support it.

Project Manager: reviews assessment Project Manager: may manage the

results to determine if additional project project plan activities pertaining to
work is required. review and/or approval.
Regulator: is referenced by auditors to Regulator: is responsible for providing
confirm compliance to standards. opinion on the relationship between
stated requirements and specific
regulations.

Sponsor: is accountable for the solution Sponsor: is responsible to review and

scope and can provide insight to be approve the business case, solution or
utilized when assessing change. product scope, and all requirements and
designs.

Tester: is consulted for establishing Tester: is responsible for ensuring

impact of the proposed changes. quality assurance standards are feasible
within the business analysis
information.

5.4 Requirements Change Assessment 5.5 Requirements (approved)

5.4 Designs Change Assessment 5.5 Designs (approved)

- -