Knowledge Area Description

Business Analysis Planning and

Monitoring describes the tasks that business analysts perform to organize and
coordinate the efforts of business analysts and stakeholders.
BAPM

the tasks that business analysts perform to prepare for and conduct
elicitation activities and confirm the results obtained. It also
Elicitation and Collaboration
describes the communication with stakeholders once the business
EC
analysis information is assembled and the ongoing collaboration with
them throughout the business analysis activities.
 describes the tasks that business analysts perform in order to
manage and maintain requirements and design information from
Requirements Life Cycle
inception to retirement. These tasks describe establishing
Management
meaningful relationships between related requirements and designs,
RLCM
and assessing, analyzing and gaining consensus on proposed changes
to requirements and designs.

describes the business analysis work that must be performed to

collaborate with stakeholders in order to identify a need of strategic
Strategy Analysis
or tactical importance (the business need), enable the enterprise to
SA
address that need, and align the resulting strategy for the change
with higher- and lower-level strategies.
 describes the tasks that business analysts perform to structure and
organize requirements discovered during elicitation activities, specify
and model requirements and designs, validate and verify
Requirements Analysis and information, identify solution options that meet business needs, and
Design Definition estimate the potential value that could be realized for each solution
RADD option. This knowledge area covers the incremental and iterative
activities ranging from the initial concept and exploration of the need
through the transformation of those needs into a particular
recommended solution.

describes the tasks that business analysts perform to assess the

Solution Evaluation performance of and value delivered by a solution in use by the
SE enterprise, and to recommend removal of barriers or constraints that
prevent the full realization of the value.
 Tasks
Plan Business Analysis Approach
Plan Stakeholder Engagement
Plan Business Analysis Governance
Plan Business Analysis Information Management
Identify Business Analysis Performance Improvements improvement opportunities are realized.
Prepare for Elicitation
Conduct Elicitation
Confirm Elicitation Results
Communicate Business Analysis Information
Description
describes the planning of business analysis work from
creation or selection of a methodology to planning the
individual activities, tasks, and deliverables.
describes understanding which stakeholders are
relevant to the change, what business analysts need
from them, what they need from business analysts, and
the best way to collaborate.
defines the components of business analysis that are
used to support the governance function of the
organization. It helps ensure that decisions are made
properly and consistently, and follows a process that
ensures decision makers have the information they
need.
defines how information developed by business
analysts (including requirements and designs) is
captured, stored, and integrated with other information
for long-term use.
describes managing and monitoring how business
analysis work is performed to ensure that
commitments are met and continuous learning and
involves ensuring that the stakeholders have the
information they need to provide and that they
understand the nature of the activities they are going
to perform. It also sets a shared set of expectations
regarding the outcomes of the activity. Preparation
may also involve identifying research sources or
preparing to conduct an experiment to see if a process
change actually results in an improvement.
describes the work performed to understand
stakeholder needs and identify potential solutions that
may meet those needs. This may involve direct
interaction with stakeholders, doing research, or
running experiments.
involves ensuring that stakeholders have a shared
understanding of the outcomes of elicitation, that
elicited information is recorded appropriately, and that
the business analyst has the information sought from
an elicitation activity. This task also involves comparing
the information received with other information to look
for inconsistencies or gaps.
provides stakeholders with the information they need,
at the time they need it. The information is presented
in a useful form, using the right terminology and
concepts.

Manage Stakeholder Collaboration
Trace Requirements
Maintain Requirements
Prioritize Requirements
Assess Requirement Changes
Approve Requirements
Analyze Current State
Define Future State
Assess Risks
Define Change Strategy
Specify and Model Requirements
describes working with stakeholders to engage them in
the overall business analysis process and to ensure that
the business analyst can deliver the outcomes needed.
analyzes and maintains the relationships between
requirements, designs, solution components, and other
work products for impact analysis, coverage, and
allocation.
ensures that requirements and designs are accurate
and current throughout the life cycle and facilitates
reuse where appropriate.
assesses the value, urgency, and risks associated with
particular requirements and designs to ensure that
analysis and/or delivery work is done on the most
important ones at any given time.
evaluates new and changing stakeholder requirements
to determine if they need to be acted on within the
scope of a change.
works with stakeholders involved in the governance
process to reach approval and agreement on
requirements and designs.
understands the business need and how it relates to
the way the enterprise functions today. Sets a baseline
and context for change.
defines goals and objectives that will demonstrate that
the business need has been satisfied and defines what
parts of the enterprise need to change in order to meet
those goals and objectives.
understands the uncertainties around the change,
considers the effect those uncertainties may have on
the ability to deliver value through a change, and
recommends actions to address risks where
appropriate.
performs a gap analysis between current and future
state, assesses options for achieving the future state,
and recommends the highest value approach for
reaching the future state including any transition states
that may be required along the way.
describes a set of requirements or designs in detail
using analytical techniques.

Verify Requirements
Validate Requirements
Define Requirements Architecture
Define Design Options
Analyze Potential Value and Recommend Solution
Measure Solution Performance
Analyze Performance Measures
Assess Solution Limitations
Assess Enterprise Limitations
Recommend Actions to Increase Solution Value
ensures that a set of requirements or designs has been
developed in enough detail to be usable by a particular
stakeholder, is internally consistent, and is of high
quality.
ensures that a set of requirements or designs delivers
business value and supports the organization's goals
and objectives.
structures all requirements and designs so that they
support the overall business purpose for a change and
that they work effectively as a cohesive whole.
identifies, explores and describes different possible
ways of meeting the need.
assesses the business value associated with a potential
solution and compares different options, including
trade-offs, to identify and recommend the solution
option that delivers the greatest overall value.
determines the most appropriate way to assess the
performance of a solution, including how it aligns with
enterprise goals and objectives, and performs the
assessment.
examines information regarding the performance of a
solution in order to understand the value it delivers to
the enterprise and to stakeholders, and determines
whether it is meeting current business needs.
investigates issues within the scope of a solution that
may prevent it from meeting current business needs.
investigates issues outside the scope of a solution that
may be preventing the enterprise from realizing the full
value that a solution is capable of providing.
identifies and defines actions the enterprise can take to
increase the value that can be delivered by a solution.
 Purpose

The purpose of Plan Business Analysis Approach is to

define an appropriate method to conduct business
analysis activities.

The purpose of Plan Stakeholder Engagement is to plan

an approach for establishing and maintaining effective
working relationships with the stakeholders.

The purpose of Plan Business Analysis Governance is to

define how decisions are made about requirements and
designs, including reviews, change control, approvals,
and prioritization.

The purpose of Plan Business Analysis Information

Management is to develop an approach for how
business analysis information will be stored and
accessed.

The purpose of Identify Business Analysis Performance

Improvements is to assess business analysis work and
to plan to improve processes where required.

The purpose of Prepare for Elicitation is to understand

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

The purpose of Conduct Elicitation is to draw out,

explore, and identify information relevant to the
change.

The purpose of Confirm Elicitation Results is to check

the information gathered during an elicitation session
for accuracy and consistency with other information.

The purpose of Communicate Business Analysis

Information is to ensure stakeholders have a shared
understanding of business analysis information.
The purpose of Manage Stakeholder Collaboration is to
encourage stakeholders to work towards a common
goal.

The purpose of Trace Requirements is to ensure that

requirements and designs at different levels are aligned
to one another, and to manage the effects of change to
one level on related requirements.

The purpose of Maintain Requirements is to retain

requirement accuracy and consistency throughout and
beyond the change during the entire requirements life
cycle, and to support reuse of requirements in other
solutions.

The purpose of Prioritize Requirements is to rank

requirements in the order of relative importance.
The purpose of Assess Requirements Changes is to
evaluate the implications of proposed changes to
requirements and designs.

The purpose of Approve Requirements is to obtain

agreement on and approval of requirements and
designs for business analysis work to continue and/or
solution construction to proceed.

The purpose of Analyze Current State is to understand

the reasons why an enterprise needs to change some
aspect of how it operates and what would be directly or
indirectly affected by the change.

The purpose of Define Future State is to determine the

set of necessary conditions to meet the business need.

The purpose of Assess Risks is to understand the

undesirable consequences of internal and external
forces on the enterprise during a transition to, or once
in, the future state. An understanding of the potential
impact of those forces can be used to make a
recommendation about a course of action.

The purpose of Define Change Strategy is to develop

and assess alternative approaches to the change, and
then select the recommended approach.
The purpose of Specify and Model Requirements is to
analyze, synthesize, and refine elicitation results into
requirements and designs
The purpose of Verify Requirements is to ensure that
requirements and designs specifications and models
meet quality standards and are usable for the purpose
they serve.

The purpose of Validate Requirements is to ensure that

all requirements and designs align to the business
requirements and support the delivery of needed value.
The purpose of Define Requirements Architecture is to
ensure that the requirements collectively support one
another to fully achieve the objectives.

The purpose of Define Design Options is to define the

solution approach, identify opportunities to improve
the business, allocate requirements across solution
components, and represent design options that achieve
the desired future state.

The purpose of Analyze Potential Value and

Recommend Solution is to estimate the potential value
for each design option and to establish which one is
most appropriate to meet the enterprise’s
requirements.

The purpose of Measure Solution Performance is to

define performance measures and use the data
collected to evaluate the effectiveness of a solution in
relation to the value it brings.

The purpose of Analyze Performance Measures is to

provide insights into the performance of a solution in
relation to the value it brings.
The purpose of Assess Solution Limitations is to
determine the factors internal to the solution that
restrict the full realization of value.
The purpose of Assess Enterprise Limitations is to
determine how factors external to the solution are
restricting value realization.

The purpose of Recommend Actions to Increase

Solution Value is to understand the factors that create
differences between potential value and actual value,
and to recommend a course of action to align them.
 Knowledge Area Tasks

Plan Business Analysis Approach

Plan Stakeholder Engagement

Business Analysis Planning and

Monitoring
BAPM
Plan Business Analysis Governance

Plan Business Analysis Information Management

Identify Business Analysis Performance Improvements

Prepare for Elicitation

 Conduct Elicitation

Elicitation and Collaboration

EC Confirm Elicitation Results

Communicate Business Analysis Information

Manage Stakeholder Collaboration

Trace Requirements

Maintain Requirements

Requirements Life Cycle

Management
RLCM

Prioritize Requirements
 Assess Requirement Changes

Approve Requirements

Analyze Current State

Define Future State

Strategy Analysis
SA
 Strategy Analysis
SA

Assess Risks

Define Change Strategy

Specify and Model Requirements

Verify Requirements

Validate Requirements

Requirements Analysis and

Design Definition
RADD
Requirements Analysis and
Design Definition
RADD
Define Requirements Architecture

Define Design Options

Analyze Potential Value and Recommend Solution

Measure Solution Performance

Analyze Performance Measures

Solution Evaluation
SE Assess Solution Limitations
Solution Evaluation
SE

Assess Enterprise Limitations

Recommend Actions to Increase Solution Value

 Inputs

Needs: the business analysis approach is shaped by the problem or

opportunity faced by the organization. It is necessary to consider what is
known about the need at the time of planning, while acknowledging that
understanding evolves throughout business analysis activities.

Needs: understanding the business need and the parts of the enterprise
that it affects helps in the identification of stakeholders. The need may
evolve as stakeholder analysis is performed.
Business Analysis Approach: incorporating the overall business analysis
approach into the stakeholder analysis, collaboration, and
communication approaches is necessary to ensure consistency across
the approaches.

Business Analysis Approach: incorporating the overall business analysis

approach into the governance approach is necessary to ensure
consistency across the approaches.
Stakeholder Engagement Approach: identifying stakeholders and
understanding their communication and collaboration needs is useful in
determining their participation in the governance approach. The
engagement approach may be updated based on the completion of the
governance approach.

Business Analysis Approach: incorporating the overall business analysis

approach into the information management approach is necessary to
ensure consistency across the approaches.
Governance Approach: defines how business analysts manage changes
to requirements and designs, how decisions and approvals for business
analysis deliverables will be made, and how priorities will be set.
Stakeholder Engagement Approach: identifying stakeholders and
understanding their communication and collaboration needs is useful in
determining their specific information management needs.

Business Analysis Approach: identifies business analysis deliverables

that will be produced, activities that will need to be performed (including
when they will be performed and who will be performing them), and
techniques that will be used.
Performance Objectives (external): describe the desired performance
outcomes that an enterprise or organization is hoping to achieve.

Needs: guides the preparation in terms of the scope and purpose of

elicitation activities. Elicitation can be used to discover the needs, but in
order to get started there must be some need that exists—even if it has
not yet been fully elicited or understood.
Stakeholder Engagement Approach: understanding stakeholders'
communication and collaboration needs helps plan and prepare
appropriate and effective elicitation events.
Elicitation Activity Plan: includes the planned elicitation activities and
techniques, activity logistics (for example, date, time, location, resources,
agenda), scope of the elicitation activity, and available sources of
background information.

Elicitation Results (unconfirmed): capture information in a format

specific to the elicitation activity.

Business Analysis Information: any kind of information at any level of

detail that is used as an input or output of business analysis work.
Business analysis information becomes an input for this task when the
need is discovered to communicate the information to additional
stakeholders.
Stakeholder Engagement Approach: describes stakeholder groups, roles,
and general needs regarding communication of business analysis
information.

Stakeholder Engagement Approach: describes the types of expected

engagement with stakeholders and how they might need to be
managed.
Business Analysis Performance Assessment: provides key information
about the effectiveness of business analysis tasks being executed,
including those focused on stakeholder engagement.

Requirements: may be traced to other requirements (including goals,

objectives, business requirements, stakeholder requirements, solution
requirements, and transition requirements), solution components,
visuals, business rules, and other work products.
Designs: may be traced to other requirements, solution components,
and other work products.

Requirements: include goals, objectives, business requirements,

stakeholder requirements, solution requirements, and transition
requirements. These should be maintained throughout their life cycle.
Designs: can be maintained throughout their life cycle, as needed.

Requirements: any requirements in the form of text, matrices, or

diagrams that are ready to prioritize.
Designs: any designs in the form of text, prototypes, or diagrams that are
ready to prioritize.
Proposed Change: can be identified at any time and impact any aspect of
business analysis work or deliverables completed to date. There are
many triggers for a proposed change including business strategy
changes, stakeholders, legal requirements, or regulatory changes.
Requirements: may need to be assessed to identify the impact of a
proposed modification.
Designs: may need to be assessed to identify the impact of a proposed
modification.

Requirements (verified): a set of requirements that have been verified

to be of sufficient quality to be used as a reliable body of work for
further specification and development.
Designs: a set of designs that have been determined as ready to be used
for further specification and development.

Elicitation Results: used to define and understand the current state.

Needs: the problem or opportunity faced by an enterprise or
organization often launches business analysis work to better understand
these needs.

Business Requirements: the problems, opportunities, or constraints that

the future state will address.
Business Objectives: describing the desired direction needed to achieve
the future state can be used to identify and discuss potential risks.
Elicitation Results (confirmed): an understanding of what the various
stakeholders perceive as risks to the realization of the desired future
state.
Influences: factors inside of the enterprise (internal) and factors outside
of the enterprise (external) which will impact the realization of the
desired future state.
Potential Value: describing the value to be realized by implementing the
proposed future state provides a benchmark against which risks can be
assessed.
Requirements (prioritized): depending on their priority, requirements
will influence the risks to be defined and understood as part of solution
realization.

Current State Description: provides context about the current state, and
includes assessments of internal and external influences to the
enterprise under consideration.
Future State Description: provides context about the desired future
state.
Risk Analysis Results: describe identified risks and exposure of each risk.
Stakeholder Engagement Approach: understanding stakeholders'
communication and collaboration needs can help identify change-related
activities that need to be included as part of the change strategy.

Elicitation Results (any state): modelling can begin with any elicitation
result and may lead to the need for more elicitation to clarify or expand
upon requirements. Elicitation and modelling may occur sequentially,
iteratively, or concurrently.
Requirements (specified and modelled): any requirement, design, or set
of those may be verified to ensure that text is well structured and that
matrices and modelling notation are used correctly.

Requirements (specified and modelled): any types of requirements and

designs can be validated. Validation activities may begin before
requirements are completely verified. However, validation activities
cannot be completed before requirements are completely verified.
Information Management Approach: defines how the business analysis
information (including requirements and models) will be stored and
accessed.
Requirements (any state): every requirement should be stated once, and
only once, and incorporated into the requirements architecture so that
the entire set may be evaluated for completeness.
Solution Scope: must be considered to ensure the requirements
architecture is aligned with the boundaries of the desired solution.

Change Strategy: describes the approach that will be followed to

transition to the future state. This may have some impact on design
decisions in terms of what is feasible or possible.
Requirements (validated, prioritized): only validated requirements are
considered in design options. Knowing the requirement priorities aids in
the suggestion of reasonable design options. Requirements with the
highest priorities might deserve more weight in choosing solution
components to best meet them as compared to lower priority
requirements.
Requirements Architecture: the full set of requirements and their
relationships is important for defining design options that can address
the holistic set of requirements.

Potential Value: can be used as a benchmark against which the value

delivered by a design can be evaluated.
Design Options: need to be evaluated and compared to one another to
recommend one option for the solution.

Business Objectives: the measurable results that the enterprise wants to

achieve. Provides a benchmark against which solution performance can
be assessed.
Implemented Solution (external): a solution (or component of a
solution) that exists in some form. It may be an operating solution, a
prototype, or a pilot or beta solution.

Potential Value: describes the value that may be realized by

implementing the proposed future state. It can be used as a benchmark
against which solution performance can be evaluated.
Solution Performance Measures: measures and provides information on
how well the solution is performing or potentially could perform.

Implemented Solution (external): a solution that exists. The solution

may or may not be in operational use; it may be a prototype. The
solution must be in use in some form in order to be evaluated.
Solution Performance Analysis: results of the analysis of measurements
collected and recommendations to solve for performance gaps and
leverage opportunities to improve value.
Current State Description: the current internal environment of the
solution including the environmental, cultural, and internal factors
influencing the solution limitations.
Implemented (or Constructed) Solution (external): a solution that exists.
The solution may or may not be in operational use; it may be a
prototype. The solution must be in use in some form in order to be
evaluated.
Solution Performance Analysis: results of the analysis of measurements
collected and recommendations to solve performance gaps and leverage
opportunities to improve value.

Enterprise Limitation: a description of the current limitations of the

enterprise including how the solution performance is impacting the
enterprise.
Solution Limitation: a description of the current limitations of the
solution including constraints and defects.
 Guidelines and Tools

Business Analysis Performance Assessment

Business Policies
Expert Judgement
Methodologies and Framework
Stakeholder Engagement Approach

Business Analysis Performance Assessment

Change Strategy
Current State Description

Business Analysis Performance Assessment

Business Policies
Current State Description
Legal / Regulatory Information

Business Analysis Performance Assessment

Business Policies
Information Management Tools
Legal / Regulatory Information

Organizational Performance Standards

Business Analysis Approach

Business Objectives
Existing Business Analysis Information
Potential Value
Business Analysis Approach
Existing Business Analysis Information
Stakeholder Engagement Approach
Supporting Materials

Elicitation Activity Plan

Existing Business Analysis Information

Business Analysis Approach

Information Management Approach

Business Analysis Approach

Business Objectives
Future State Description
Recommended Actions
Risk Analysis Results

Domain Knowledge
Information Management Approach
Legal/Regulatory Information
Requirements Management Tools/Repository

Information Management Approach

Business Constraints
Change Strategy
Domain Knowledge
Governance Approach
Requirements Architecture
Requirements Management Tools/Repository
Solution Scope
Change Strategy
Domain Knowledge
Governance Approach
Legal/Regulatory Information
Requirements Architecture
Solution Scope

Change Strategy
Governance Approach
Legal/Regulatory Information
Requirement Management Tools/Repository
Solution Scope

Business Analysis Approach

Enterprise Limitation
Organizational Strategy
Solution Limitation
Solution Performance Goals
Solution Performance Measures
Stakeholder Analysis Results

Current State Description

Metrics and Key Performance Indicators (KPIs)
Organizational Strategy
Business Analysis Approach
Business Policies
Change Strategy
Current State Description
Future State Description
Identified Risks
Stakeholder Engagement Approach

Business Analysis Approach

Design Options
Solution Recommendations

Modelling Notations/Standards
Modelling Tools
Requirements Architecture
Requirements Life Cycle Management Tools
Solution Scope

Requirements Life Cycle Management Tools

Business Objectives
Future State Description
Potential Value
Solution Scope
Architecture Management Software
Legal/Regulatory Information

Existing Solutions
Future State Description
Requirements (traced)
Solution Scope

Business Objectives
Current State Description
Future State Description
Risk Analysis Results
Solution Scope

Change Strategy
Future State Description
Requirements (validated)
Solution Scope

Change Strategy
Future State Description
Risk Analysis Results
Solution Scope

Change Strategy
Risks Analysis Results
Solution Scope
Business Objectives
Change Strategy
Future State Descriptions
Risk Analysis Results
Solution Scope

Business Objectives
Current State Description
Solution Scope
 Outputs

Business Analysis Approach: identifies the business analysis

approach and activities that will be performed across an initiative
including who will perform the activities, the timing and
sequencing of the work, the deliverables that will be produced and
the business analysis techniques that may be utilized.

Stakeholder Engagement Approach: contains a list of the

stakeholders, their characteristics which were analyzed, and a
listing of roles and responsibilities for the change. It also identifies
the collaboration and communication approaches the business
analyst will utilize during the initiative.

Governance Approach: identifies the stakeholders who will have

the responsibility and authority to make decisions about business
analysis work including who will be responsible for setting priorities
and who will approve changes to business analysis information. It
also defines the process that will be utilized to manage
requirement and design changes across the initiative.

Information Management Approach: includes the defined

approach for how business analysis information will be stored,
accessed, and utilized during the change and after the change is
complete.

Business Analysis Performace Assessment: includes a comparison

of planned versus actual performance, identifying the root cause of
variances from the expected performance, proposed approaches
to address issues, and other findings to help understand the
performance of business analysis processes.

Elicitation Activity Plan: used for each elicitation activity. It

includes logistics, scope of the elicitation activity, selected
techniques, and supporting materials.
Elicitation Results (unconfirmed): captured information in a format
that is specific to the elicitation activity.

Elicitation Results (confirmed): integrated output that the business

analyst and other stakeholders agree correctly reflects captured
information and confirms that it is relevant and useful as an input
to further work.

Business Analysis Information (communicated): business analysis

information is considered communicated when the target
stakeholders have reached an understanding of its content and
implications.

Stakeholder Engagement: willingness from stakeholders to engage

in business analysis activities and interact with the business analyst
when necessary.

Requirements (traced): have clearly defined relationships to other

requirements, solution components, or releases, phases, or
iterations, within a solution scope, such that coverage and the
effects of change are clearly identifiable.
Deigns (traced): clearly defined relationships to other
requirements, solution components, or releases, phases, or
iterations, within a solution scope, such that coverage and the
effects of change are clearly identifiable.

Requirements (maintained): defined once and available for long-

term usage by the organization. They may become organizational
process assets or be used in future initiatives. In some cases, a
requirement that was not approved or implemented may be
maintained for a possible future initiative.
Designs (maintained): may be reusable once defined. For example,
as a selfcontained component that can be made available for
possible future use.

Requirements (prioritized): prioritized or ranked requirements are

available for additional work, ensuring that the highest valued
requirements are addressed first.
Designs (prioritized): prioritized or ranked designs are available for
additional work, ensuring that the highest valued designs are
addressed first.
Requirements Change Assessment: the recommendation to
approve, modify, or deny a proposed change to requirements.
Designs Change Assessment: the recommendation to approve,
modify, or deny a proposed change to one or more design
components.

Requirements (approved): requirements which are agreed to by

stakeholders and are ready for use in subsequent business analysis
efforts.
Designs (approved): designs which are agreed to by stakeholders
and are ready for use in subsequent business analysis or solution
development efforts.

Current State Description: the context of the enterprise’s scope,

capabilities, resources, performance, culture, dependencies,
infrastructure, external influences, and significant relationships
between these elements.
Business Requirements: the problem, opportunity, or constraint
which is defined based on an understanding of the current state.

Business Objectives: the desired direction that the business wishes

to pursue in order to achieve the future state.
Future State Description: the future state description includes
boundaries of the proposed new, removed, and modified
components of the enterprise and the potential value expected
from the future state. The description might include the desired
future capabilities, policies, resources, dependencies,
infrastructure, external influences, and relationships between each
element.
Potential Value: the value that may be realized by implementing
the proposed future state.
Risk Analysis Results: an understanding of the risks associated with
achieving the future state, and the mitigation strategies which will
be used to prevent those risks, reduce the impact of the risk, or
reduce the likelihood of the risk occurring.

Change Strategy: the approach that the organization will follow to

guide change.
Solution Scope: the solution scope that will be achieved through
execution of the change strategy.

Requirements (specified and modelled): any combination of

requirements and/or designs in the form of text, matrices, and
diagrams.

Requirements (verified): a set of requirements or designs that is of

sufficient quality to be used as a basis for further work.

Requirements (validated): validated requirements and designs are

those that can be demonstrated to deliver benefit to stakeholders
and align with the business goals and objectives of the change. If a
requirement or design cannot be validated, it either does not
benefit the organization, does not fall within the solution scope, or
both.
Requirements Architecture: the requirements and the
interrelationships among them, as well as any contextual
information that is recorded.

Design Options: describe various ways to satisfy one or more needs

in a context. They may include solution approach, potential
improvement opportunities provided by the option, and the
components that define the option.

Solution Recommendation: identifies the suggested, most

appropriate solution based on an evaluation of all defined design
options. The recommended solution should maximize the value
provided to the enterprise.

Solution Performance Measures: measures that provide

information on how well the solution is performing or potentially
could perform.

Solution Performance Analysis: results of the analysis of

measurements collected and recommendations to solve
performance gaps and leverage opportunities to improve value.

Solution Limitation: a description of the current limitations of the

solution including constraints and defects.
Enterprise Limitation: a description of the current limitations of
the enterprise including how the solution performance is impacting
the enterprise.

Recommended Actions: recommendation of what should be done

to improve the value of the solution within the enterprise.
 Tasks

Plan Business Analysis Approach

Plan Stakeholder Engagement

Plan Business Analysis Governance

Plan Business Analysis Information Management

Identify Business Analysis Performance Improvements

Prepare for Elicitation

Conduct Elicitation

Confirm Elicitation Results

Communicate Business Analysis Information

Manage Stakeholder Collaboration

Trace Requirements

Maintain Requirements

Prioritize Requirements

Assess Requirement Changes

Approve Requirements
Analyze Current State

Define Future State

Assess Risks

Define Change Strategy

Specify and Model Requirements

Verify Requirements

Validate Requirements

Define Requirements Architecture

Define Design Options

Analyze Potential Value and Recommend Solution

Measure Solution Performance

Analyze Performance Measures

Assess Solution Limitations

Assess Enterprise Limitations

Recommend Actions to Increase Solution Value

 Elements

Planning Approach (Predictive Approach, Adaptive Approach)

Formality and Level of Detail of BA Deliverables (Solution
Definition, Level of Formality, Activities, Timing)
Business Analysis Activities
Timing of Business Analysis Work
Complexity and Risk
Acceptance

Perform Stakeholder Analysis (Roles, Attitudes, Decision Making

Authority, Level of Power of Influence)
Define Stakeholder Collaboration (approaches - timing and
frequency, locations, online communication or wiki, delivery
method, preference of stakeholders etc.)
Stakeholder Communication Needs (What needs to be
communicated, who the audience is, frequency, location level of
detail, level of formality)

Decision Making
Change Control Process (process for requesting changes,
elements of CR, how changes will be prioritized, how changes
will be documented, how change will be communicated, who
will perform impact assessment, who will authorize)
Plan Prioritization Approach
Plan for Approval

Organization of Business Analysis Information

Level of Abstraction
Plan Traceability Approach
Plan for Requirements Reuse
Storage and Access
Requirements Attributes

Performance Analysis
Assessment Measures
Analyze Results
Recommend Actions for Improvement (Preventive, Corrective,
Improvement)

Understand the Scope of Elicitation (domain, locations, solution

approach etc.)
Select Elicitation Techniques (techniques commonly used in
similar initiatives, techniques specifically suited to the situation,
and the tasks needed to prepare, execute, and complete each
technique)
Set Up Logistics
Secure Supporting Material
Prepare Stakeholders
Guide Elicitation Activity - In order to help guide and facilitate
towards the expected outcomes, business analysts consider:
• the elicitation activity goals and agenda,
• scope of the change,
• what forms of output the activity will generate,
• what other representations the activity results will support,
• how the output integrates into what is already known,
• who provides the information,
• who will use the information, and
• how the information will be used.
Capture Elicitation Outcomes
Compare Elicitation Results Against Source Information
Compare Elicitation Results Against Other Elicitation Results

Determine Objectives and Format of Communication(Formal

Documentation, InFormal Documentation or Presentations)
Communicate Business Analysis Package (Group collaboration,
Individual collaboration, or, E-mail or other non-verbal methods)
Gain Agreement on Commitments
Monitor Stakeholder Engagement
Collaboration

Level of Formality
Relationships (Derive, Depends (Necessity, Effort), Satisfy,
Validate)
Traceability Repository

Maintain Requirements
Maintain Attributes
Reusing Requirements (within the current initiative, within
similar initiatives, within similar departments, and throughout
the entire organization)

Basis for Prioritization (Benefit, Cost, Penalty, Risk,

Dependencies, Time Sensitivity, Stability, Regulatory or Policy
Compliance)
Challenges of Prioritization
Continual Prioritization
Assessment Formality
Impact Analysis (Benefit, Cost, Impact, Schedule, Urgency)
Impact Resolution

Understand Stakeholder Roles

Conflict and Issue Management
Gain Consensus
Track and Communicate Approval
Business Needs (From the top-down, From the bottom-up, From
middle management, or From external drivers)
Organizational Structure and Culture
Capabilities and Processes (capability-centric view or Process-
centric view)
Technology and Infrastructure
Poilicies
Business Architecture
Internal Assets
External Influencers (Industry Structure, Competitors,
Customers, Suppliers, Political and Regulatory Environment,
Technology, Macroeconomic Factors)

Business Goals and Objectives (Objectives must be Specific,

Measurable, Achievable, Relevant and Time-bounded)
Scope of Solution Space
Constraints (budgetary restrictions, time restrictions,
technology, infrastructure, policies, limits on the number of
resources available, restrictions based on the skills of the team
and stakeholders, a requirement that certain stakeholders not
be affected by the implementation of the solution, compliance
with regulations, and any other restriction.)
Organizational Structure and Culture
Capabilities and Processes
Technology and Infrastructure
Poilicies
Business Architecture
Internal Assets
Identify Assumptions
Potential Value

Unknowns
Constraints, Assumptions, and Dependencies
Negative Impact to Value
Risk Tolerance (Risk-aversion, Neutrality, Risk-seeking)
Recommendation

Solution Scope
Gap Analysis
Enterprise Readiness Assessment
Change Strategy (high-level plan of key activities and events that
will be used to transform the enterprise from the current state
to the future state)
Transition States and Release Planning

Model Requirements (Matrices, Diagrams)(Model categories -

People and Roles, Rationale, Acivity Flow, Capability, Data and
Information)
Analyze Requirements
Represent Requirements and Attributes
Implement the Appropriate Levels of Abstraction
Characteristics of Requirements and Designs Quality (Atomic,
Complete, Consistent, Concise, Feasible, Unambiguous, Testable,
Prioritized, Understandable)
Verification Activities
Checklists
Identify Assumptions
Define Measurable Evaluation Criteria
Evaluate Alignment with Solution Scope

Requirements Viewpoints and Views

Template Architectures
Completeness
Relate and Verify Requirements Relationships (Defined,
Necessary, Correct, Unambiguous, Consistent)
Business Analysis Information Architecture

Define Solution Approaches (Create, Purchase, Combination of

both)
Identify Improvement Opportunities (Increase Efficiencies,
Improve Access to Information, Identify Additional Capabilities)
Requirements Allocation
Describe Design Options

Expected Benefits
Expected Costs
Determine Value
Assess Design Options and Recommend Solution

Define Solution Performance Measures (Quantitative Measures,

Qualitative Measures)
Validate Performance Measures
Collect Performance Measures (Volume or Sample Size,
Frequency and Timing, Currency)

Solution Performance versus Desired Value

Risks
Trends
Accuracy
Performance Variances
Identify Internal Solution Component Dependencies
Investigate Solution Problems
Impact Assessment

Enterprise Culture Assessment

Stakeholder Impact Analysis (Functions, Locations, Concerns)
Organizational Structure Changes
Operational Assessment

Adjust Solution Performance Measures

Recommendations (Do Nothing, Organizational Change, Reduce
Complexity of Interfaces, Eliminate Redundancy, Avoid Waste,
Identify Additional Capabilities, Retire the Solution, additional
factors (ongoing cost versus initial investment, opportunity cost,
necessity, sunk cost)
Elements of CR - cost and time estimation, benefits, risk, priority, course of
action

Requirement Attributes - Absolute Reference, Author, Complexity, Ownership,

Priority, Risk, Source, Stability, Status, Urgency

Assessment Measures - Accuracy and Completeness, Knowledge,

Effectiveness, Organizational Support, Significance, Strategic, Timeliness

The logistics for each elicitation activity include identifying:

• the activity's goals,
• participants and their roles,
• scheduled resources, including people, rooms, and tools,
• locations,
• communication channels,
• techniques, and
• languages used by stakeholders (oral and written).
The logistics may also involve creating an agenda if other stakeholders are
involved.
Analyze for :
• anything that must change to meet the business need,
• anything that should stay the same to meet the business need,
• missing components,
• unnecessary components, and
• any constraints or assumptions that impact the components.
Verification Activites include:
• checking for compliance with organizational performance standards for
business analysis, such as using the right tools and methods,
• checking for correct use of modelling notation, templates, or forms,
• checking for completeness within each model,
• comparing each model against other relevant models, checking for
elements that are mentioned in one model but are missing in other models,
and verifying that the elements are referenced consistently,
• ensuring the terminology used in expressing the requirement is
understandable to stakeholders and consistent with the use of those terms
within the organization, and
• adding examples where appropriate for clarification

Requirements viewpoints frequently include standards and guidelines for the:

• model types used for requirements,
• attributes that are included and consistently used in different models,
• model notations that are used, and
• analytical approaches used to identify and maintain relevant relationships
among models.

Design elements may describe:

• business policies and business rules,
• business processes to be performed and managed,
• people who operate and maintain the solution, including their job functions
and responsibilities,
• operational business decisions to be made,
• software applications and application components used in the solution, and
• organizational structures, including interactions between the organization,
its customers, and its suppliers.
Business analysts perform cultural assessments to:
• identify whether or not stakeholders understand the reasons why a solution
exists,
• ascertain whether or not the stakeholders view the solution as something
beneficial and are supportive of the change, and
• determine if and what cultural changes are required to better realize value
from a solution.

Possible recommendations that relate to organizational change include:

• automating or simplifying the work people perform. Relatively simple
tasks are prime candidates for automation. Additionally, work activities
and business rules can be reviewed and analyzed to determine
opportunities for re-engineering, changes in responsibilities, and
outsourcing.
• improving access to information. Change may provide greater amounts
of information and better quality of information to staff and decision
makers.
When conducting an operational assessment,
business analysts consider:
• policies and procedures,
• capabilities and processes that enable other
capabilities,
• skill and training needs,
• human resources practices,
• risk tolerance and management approaches, and
• tools and technology that support a solution.