CBAP BABOK v3 notes

BABOK Guide v3 Study Notes
CBAP V3 Study Notes
Chapter 1: Introduction (page 1)
1.1 Purpose of the BABOK Guide (page 1)
• Define the profession of business analysis and provide a set of commonly accepted
practices
• Helps practitioners discuss and define the skills necessary to effectively perform business
analysis work
• Understand the skills and knowledge they should expect from a skilled practitioner
• Common framework for all perspectives, describing business analysis tasks that are
performed to properly analyze a change or evaluate the necessity for a change
• The six knowledge areas of the BABOK
®
Guide describe the practice of business analysis as it
is applied within the boundaries of a project or throughout enterprise evolution and
continuous improvement
The following image shows how three of the knowledge areas support the delivery of business
value before, during, and after the life cycle of a project.
1.2 What is Business Analysis? (page 2)
• Business analysis is the practice of enabling change in an enterprise by defining needs and
recommending solutions that deliver value to stakeholders.
• Business analysis enables an enterprise to articulate needs and the rationale for change, and to
design and describe solutions that can deliver value.
• Initiatives may be strategic, tactical, or operational.
• It can be used to understand the current state, to define the future state, and to determine
the activities required to move from the current to the future state
saifur.rahman62@gmail.com Page of1 107

1.3 Who is a Business Analyst? (page 2)
• A business analyst is any person who performs business analysis tasks described in the
BABOK Guide, no matter their job title or organizational role. (business architect, business
system analyst, data analyst, enterprise analyst, management consultant, system analyst…)
• Business analysts are responsible for discovering, synthesizing, and analyzing information
from a variety of sources within an enterprise, including tools, processes, documentation, and
stakeholders.
• The business analyst is responsible for eliciting the actual needs of stakeholders—which
frequently involves investigating and clarifying their expressed desires—in order to determine
underlying issues and causes.
• Business analysts play a role in aligning the designed and delivered solutions with the
needs of stakeholders.
 
The activities that business analysts perform include:
- understanding enterprise problems and goals,
- analyzing needs and solutions,
- devising strategies,
- driving change, and
- facilitating stakeholder collaboration.
1.4 Structure of the BABOK Guide (page 3)
The core content of the BABOK
®
Guide is composed of business analysis tasks organized
into knowledge areas. Knowledge areas are a collection of logically (but not sequentially)
related tasks. The Business Analysis Key Concepts, Underlying Competencies, Techniques,
and Perspectives sections form the extended content in the BABOK Guide.
• Business Analysis Key Concepts: deﬁne the key terms needed to understand all other
content, concepts, and ideas within the BABOK Guide.
• Underlying Competencies: provide a description of the behaviours, characteristics,
knowledge, and personal qualities that support the effective practice of business analysis.
• Techniques: provide a means to perform business analysis tasks.
• Perspectives: describe various views of business analysis. Perspectives help business analysts
working from various points of view to better perform business analysis tasks, given the context
of the initiative.  
1.4.1 Key Concepts (page 4)
• Basic understanding of the central ideas necessary for understanding the BABOK Guide. This
chapter consists of:
- Business Analysis Core Concept Model (BACCM)
- Key Terms
- Requirements Classiﬁcation Schema
- Stakeholders

- Requirements and Design
1.4.2 Knowledge Areas (page 4)
Knowledge areas represent areas of specific business analysis expertise that encompass
several tasks. Each knowledge area includes a visual representation of its inputs and outputs. The
six knowledge areas are:
• Business Analysis Planning and Monitoring: describes the tasks that business analysts
perform to organize and coordinate the efforts of business analysts and stakeholders.
• Elicitation and Collaboration: describes the tasks that business analysts perform to prepare
for and conduct elicitation activities and confirm the results obtained along with the
communication and ongoing collaboration with the stakeholders.
• Requirements Life Cycle Management: describes the tasks that business analysts perform in
order to manage and maintain requirements and design information from inception to retirement.
• Strategy Analysis: describes the business analysis work that must be performed to collaborate
with stakeholders in order to identify a need of strategic or tactical importance (the business
need), enable the enterprise to address that need, and align the resulting strategy for the
change with higher- and lower-level strategies.
• Requirements Analysis and Design Definition: 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 information, identify solution options
that meet business needs, and estimate the potential value that could be realized for each
solution option.
• Solution Evaluation: describes the tasks that business analysts perform to assess the
performance of and value delivered by a solution in use by the enterprise, and to recommend
removal of barriers or constraints that prevent the full realization of the value.

1.4.3 Tasks (page 5)
A task is a discrete piece of work that may be performed formally or informally as part of
business analysis. Tasks are grouped into knowledge areas. Business analysts perform tasks
from all knowledge areas sequentially, iteratively, or simultaneously; in any order as long as
the necessary inputs are present. Each task in the BABOK Guide is presented in the following
format:
Purpose - Description - Inputs - Elements - Guidelines/Tools - Techniques - Stakeholders - Outputs
1.4.4 Underlying Competencies (page 7)
Underlying competencies reflect knowledge, skills, behaviours, characteristics, and personal
qualities that help one successfully perform the role of the business analyst. Underlying
competencies have the following structure:
Purpose - Definition - Effective Measures
1.4.5 Techniques (page 8)
Techniques provide additional information on ways that a task may be performed. Techniques
have the following structure:
Purpose - Description - Elements - Usage Considerations
1.4.6 Perspectives (page 9)
Perspectives are used within business analysis work to provide focus to tasks and techniques
specific to the context of the initiative. Most initiatives are likely to engage one or more
perspectives. The perspectives included in the BABOK Guide are:
• Agile
• Business Intelligence
• Information Technology
• Business Architecture
• Business Process Management
Perspectives have the following structure:
Change Scope - Business Analysis Scope - Methodologies, Approaches, and Techniques -
Underlying Competencies - Impact on Knowledge Areas

Chapter 2: Business Analysis Key Concepts (page 11)
The Business Analysis Key Concepts chapter includes information that provides a foundation for all
other content, concepts, and ideas within the BABOK Guide. It provides business analysts with a
basic understanding of the central ideas necessary for understanding and employing the BABOK
Guide in their daily practice of business analysis.
This chapter consists of:
• Business Analysis Core Concept Model (BACCM)
• Key Terms
• Requirements Classification Schema
• Stakeholders
• Requirements and Design
2.1 Business Analysis Core Concept Model (BACCM) (page 12)
• Defines a conceptual framework for the business analysis profession.
• The six core concepts in the BACCM are: Change, Need, Solution, Stakeholder, Value, and
Context.
• Each core concept is defined by the other five core concepts and cannot be fully understood
until all the concepts are understood.
• These concepts are instrumental to understanding the type of information elicited, analyzed, or
managed in business analysis tasks.
The BACCM can be used to:
- describe the profession and domain of business analysis,
- communicate about business analysis with a common terminology,
- evaluate the relationships of key concepts in business analysis,
- perform better business analysis by evaluating the relationships among these six concepts,
- evaluate the impact of these concepts and relationships at any point during a work effort  

The core concepts can be used by business analysts to consider the quality and completeness of
the work being done. While planning or performing a task or technique, business analysts can
consider how each core concept is addressed by asking questions such as:
• What are the kinds of changes we are doing? 
• What are the needs we are trying to satisfy? 
• What are the solutions we are creating or changing?
• Who are the stakeholders involved? 
• What do stakeholders consider to be of value? 
• What are the contexts that we and the solution are in?
If any of the core concepts experience a change, it should cause us to re-evaluate these core
concepts and their relationships to value delivery.

2.2 Key Terms (page 14)
Key Terms provides definitions of essential concepts, which are highlighted because of their
importance to the BABOK Guide.
• Business Analysis: The BABOK Guide describes and defines business analysis as the practice
of enabling change in an enterprise by defining needs and recommending solutions that deliver
value to stakeholders.
• Business Analysis Information: Business analysis information refers to the broad and diverse
sets of information that business analysts analyze, transform, and report. Examples include
elicitation results, requirements, designs, solution options, solution scope, and change strategy.
• Design: A design is a usable representation of a solution. Design focuses on understanding how
value might be realized by a solution if it is built.
• Enterprise: An enterprise is a system of one or more organizations and the solutions they use
to pursue a shared set of common goals. These solutions (also referred to as organizational
capabilities) can be processes, tools or information.
• Organization: An autonomous group of people under the management of a single individual or
board, that works towards common goals and objectives. Organizations often have a clearly
defined boundary and operate on a continuous basis.
• Plan: A plan is a proposal for doing or achieving something. Plans describe a set of events, the
dependencies among the events, the expected sequence, the schedule, the results or
outcomes, the materials and resources needed, and the stakeholders involved.
• Requirement: A requirement is a usable representation of a need. Requirements focus on
understanding what kind of value could be delivered if a requirement is fulfilled.
• Risk: Risk is the effect of uncertainty on the value of a change, a solution, or the enterprise.
Business analysts collaborate with other stakeholders to identify, assess, and prioritize risks,
and to deal with those risks by altering the likelihood of the conditions or events that lead to the
uncertainty.
2.3 Requirements Classification Schema (page 16)
Requirements Classification Schema identifies levels or types of requirements that assist the
business analyst and other stakeholders in categorizing requirements.
• Business requirements: statements of goals, objectives, and outcomes that describe why a
change has been initiated. They can apply to the whole of an enterprise, a business area, or a
specific initiative.
• Stakeholder requirements: describe the needs of stakeholders that must be met in order to
achieve the business requirements. They may serve as a bridge between business and solution
requirements.
• Solution requirements: describe the capabilities and qualities of a solution that meets the
stakeholder requirements. They provide the appropriate level of detail to allow for the
development and implementation of the solution. Solution requirements can be divided into two
sub-categories:
- functional requirements: describe the capabilities that a solution must have in terms of the
behaviour and information that the solution will manage, and

- non-functional requirements or quality of service requirements: do not relate directly to
the behaviour of functionality of the solution, but rather describe conditions under which a
solution must remain effective or qualities that a solution must have.
• Transition requirements: describe the capabilities that the solution must have and the
conditions the solution must meet to facilitate transition from the current state to the future state,
but which are not needed once the change is complete. They are differentiated from other
requirements types because they are of a temporary nature. Transition requirements address
topics such as data conversion, training, and business continuity.
• Stakeholders: deﬁnes roles, and characteristics of groups or individuals participating in or
affected by the business analysis activities within a change.
• Requirements and Designs: describes the distinction between—and the importance of—
requirements and designs as they relate to business analysis.
2.4 Stakeholders (page 16)
Each task includes a list of stakeholders who are likely to participate in the execution of that task or
who will be affected by it. A stakeholder is an individual or group that a business analyst is likely to
interact with directly or indirectly. the generic list of stakeholders includes the following roles:
2.4.1 Business Analyst
Business analyst is responsible and accountable for the execution of these activities and may also
be responsible for performing activities that fall under another stakeholder role.
2.4.2 Customer
A customer uses or may use products or services produced by the enterprise and may have
contractual or moral rights that the enterprise is obliged to meet.
2.4.3 Domain Subject Matter Expert
A domain subject matter expert is any individual with in-depth knowledge of a topic relevant to the
business need or solution scope. Eg. managers, process owners, legal staff, consultants
2.4.4 End User
End users are stakeholders who directly interact with the solution. End users can include all
participants in a business process, or who use the product or solution.
2.4.5 Implementation Subject Matter Expert
An implementation subject matter expert is any stakeholder who has specialized knowledge
regarding the implementation of one or more solution components. Eg. project librarian, change
manager, conﬁguration manager, solution architect, developer, database administrator, information
architect, usability analyst, trainer, and organizational change consultant

2.4.6 Operational Support
Operational support is responsible for the day-to-day management and maintenance of a system
or product. Eg. operations analyst, product analyst, help desk, and release manager.
2.4.7 Project Manager
Project managers are responsible for managing the work required to deliver a solution that meets a
business need, and for ensuring that the project's objectives are met while balancing the project
factors including scope, budget, schedule, resources, quality, and risk. Eg. project lead, technical
lead, product manager, and team leader.
2.4.8 Regulator
Regulators are responsible for the definition and enforcement of standards. Standards can be
imposed on the solution by regulators through legislation, corporate governance standards, audit
standards, or standards defined by organizational centers of competency. Alternate roles are
government, regulatory bodies, and auditor. 
 
2.4.9 Sponsor
Sponsors are responsible for initiating the effort to define a business need and develop a solution
that meets that need. They authorize the work to be performed, and control the budget and scope
for the initiative. Alternate roles are executive and project sponsor.
2.4.10 Supplier
A supplier is a stakeholder outside the boundary of a given organization or organizational unit.
Suppliers provide products or services to the organization and may have contractual or moral
rights and obligations that must be considered. Alternate roles are providers, vendors, and
consultants.
2.4.11 Tester
Testers are responsible for determining how to verify that the solution meets the requirements
defined by the business analyst, as well as conducting the verification process. Testers also seek
to ensure that the solution meets applicable quality standards, and that the risk of defects or
failures is understood and minimized. An alternate role is quality assurance analyst.
2.5 Requirements and Design (page 19)
Requirements are focused on the need; designs are focused on the solution. The distinction
between requirements and designs is not always clear. The same techniques are used to elicit,
model, and analyze both. A requirement leads to a design which in turn may drive the discovery
and analysis of more requirements. The shift in focus is often subtle.
A requirement (or set of requirements) may be used to define a design. That design may then be
used to elicit additional requirements that are used to define more detailed designs. The business
analyst often reviews the final designs to ensure that they align with the requirements.

Stakeholders may present a need or a solution to an assumed need. A business analyst uses
activities found in Elicitation and Collaboration to transform that request into a requirement or
design. Regardless of the focus of the stakeholder, the importance of the role of the business
analyst lies in continuously asking the question ‘why?’

Chapter 3: Business Analysis Planning and Monitoring (page 21)
The Business Analysis Planning and Monitoring knowledge area tasks organize and coordinate
the efforts of business analysts and stakeholders. These tasks produce outputs that are used
as key guidelines for the other tasks throughout the BABOK Guide. The Business Analysis
Planning and Monitoring knowledge area includes the following tasks:
• Plan Business Analysis Approach: describes the planning of business analysis work from
creation or selection of a methodology to planning the individual activities, tasks, and
deliverables.
• Plan Stakeholder Engagement: 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.
• Plan Business Analysis Governance: deﬁnes the components of business analysis that are
used to support the governance function of the organization and help ensure that decisions are
made properly and consistently, and follows a process that ensures decision makers have the
information they need.
• Plan Business Analysis Information Management: deﬁnes how information developed by
business analysts (including requirements and designs) is captured, stored, and integrated with
other information for long-term use.
• Identify Business Analysis Performance Improvements: describes managing and monitoring
how business analysis work is performed to ensure that commitments are met and continuous
learning and improvement opportunities are realized.

3.1 Plan Business Analysis Approach (page 24)
3.1.1 Purpose (page 24)
• deﬁne an appropriate method to conduct business analysis activities.
3.1.2 Description (page 24)
• describe the overall method that will be followed when performing business analysis work on a
given initiative, how and when tasks will be performed, and deliverables that will be produced.
• identify an initial set of techniques to use. This list may change as the initiative proceeds

The business analysis approach should:
- align to the overall goals of the change,
- coordinate the business analysis tasks with the activities and deliverables of the overall
change,
- include tasks to manage any risks that could reduce the quality of business analysis
deliverables or impede task efficiency, and
- leverage approaches and select techniques and tools that have historically worked well.
3.1.3 Inputs (page 24)
• Needs: 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.
3.1.4 Elements (page 26)
.1 Planning Approach
• planning methods fit somewhere along a continuum between predictive and adaptive
approaches.
• Predictive approaches focus on minimizing upfront uncertainty and ensuring that the solution is
defined before implementation begins in order to maximize control and minimize risk. Preferred
in situations where requirements can effectively be defined ahead of implementation, the risk of
an incorrect implementation is unacceptably high, or when engaging stakeholders presents
significant challenges.
• Adaptive approaches focus on rapid delivery of business value in short iterations in return for
acceptance of a higher degree of uncertainty regarding the overall delivery of the solution.
Preferred when taking an exploratory approach to finding the best solution or for incremental
improvement of an existing solution.
• Planning typically occurs more than once on a given initiative as plans are updated to address
changing business conditions and newly raised issues. The business analysis approach should
describe how plans will be altered if changes are required.
.2 Formality and Level of Detail of Business Analysis Deliverables
• BAs consider the level of formality that is appropriate for approaching and planning the initiative
• Predictive approaches typically call for formal documentation and representations. Information is
captured at various levels of detail.
• Adaptive approaches favour defining requirements and designs through team interaction and
gathering feedback on a working solution. Mandatory requirements representations are often
limited to a prioritized requirements list. Formal documentation is often produced after the
solution is implemented to facilitate knowledge transfer.
Other considerations that may affect the approach include:
- the change is complex and high risk,
- the organization is in, or interacts with, heavily regulated industries,
- contracts or agreements necessitate formality,

- stakeholders are geographically distributed,
- resources are outsourced,
- staff turnover is high and/or team members may be inexperienced,
- requirements must be formally signed off, and
- business analysis information must be maintained long-term or handed over for use on future
initiatives.
.3 Business Analysis Activities
• provides a description of the types of activities that the business analyst will perform. Integrating
business analysis activities in the business analysis approach includes:
- identifying the activities required to complete each deliverable and then breaking each activity
into tasks,
- dividing the work into iterations, identifying the deliverables for each iteration, and then
identifying the associated activities and tasks, or
- using a previous similar initiative as an outline and applying the detailed tasks and activities
unique to the current initiative.
.4 Timing of Business Analysis Work
Business analysts determine when the business analysis tasks need to be performed and if the
level of business analysis effort will need to vary over time, along with determining whether the
business analysis tasks will be performed primarily in speciﬁc phases or iteratively over the course
of the initiative. The timing of business analysis activities can also be affected by:
- the availability of resources,
- priority and/or urgency of the initiative,
- other concurrent initiatives, or
- constraints such as contract terms or regulatory deadlines.

.5 Complexity and Risk
The complexity and size of the change and the overall risk of the effort to the organization are
considered when determining the business analysis approach. Factors that can impact complexity
include:
- increase in complexity and risk
- change in the number of stakeholders
- size of the change,
- number of business areas or systems affected,
- geographic and cultural considerations,
- technological complexities, and
- any risks that could impede the business analysis effort.
Factors that can impact the risk level of a business analysis effort include:
- experience level of the business analyst,
- extent of domain knowledge held by the business analyst,
- level of experience stakeholders have in communicating their needs,
- stakeholder attitudes about the change and business analysis in general,
- amount of time allocated by stakeholders to the business analysis activities,
- any pre-selected framework, methodology, tools, and/or techniques imposed by organizational
policies and practices, and
- cultural norms of the organization.
.6 Acceptance
The business analysis approach is reviewed and agreed upon by key stakeholders. Some
organizations may require key stakeholders to sign off on the approach to ensure all business
analysis activities have been identiﬁed, estimates are realistic, and the proposed roles and
responsibilities are correct.
3.1.5 Guidelines and Tools (page 29)
• Business Analysis Performance Assessment
• Business Policies: deﬁne the limits within which decisions must be made.
• Expert Judgment
• Methodologies and Frameworks: shape the approach that will be used for business analysis
• Stakeholder Engagement Approach
• Brainstorming
• Business Cases
• Document Analysis
• Estimation
• Financial Analysis
• Functional Decomposition
• Interviews
• Item Tracking
• Lessons Learned
• Process Modelling
• Reviews
• Risk Analysis and
• Management
• Scope Modelling
• Surveys or Questionnaire
• Workshops

3.1.7 Stakeholders (page 30)
• Domain Subject Matter Expert
• Project Manager
• Regulator
• Sponsor
3.1.8 Outputs (page 31)
• 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.
3.2 Plan Stakeholder Engagement (page 31)
3.2.1 Purpose (page 31)
• plan an approach for establishing and maintaining effective working relationships with the
stakeholders.
3.2.2 Description
• conducting a thorough stakeholder analysis to identify all of the involved stakeholders and
analyze their characteristics.
• define the best collaboration and communication approaches for the initiative and to
appropriately plan for stakeholder risks.
• the degree of complexity can increase disproportionately as the number of stakeholders involved
in the business analysis activities increases.
3.2.3 Inputs (page 31)
• Needs: business need and the parts of the enterprise that it affects helps in the identification of
stakeholders. Needs may evolve.
• Business Analysis Approach: incorporating the overall business analysis approach into the
stakeholder analysis, collaboration, and communication approaches.
3.2.4 Elements (page 32)
.1 Perform Stakeholder Analysis
• identifying the stakeholders (who will be directly or indirectly impacted by the change) and their
characteristics, as well as analyzing the information once collected, which is performed
repeatedly.
• A company’s organizational chart and business processes can serve as an initial source for
identifying internal stakeholders, in addition to sponsors who also identify stakeholders.

• External stakeholders are identified from existing contracts, regulatory and governing bodies.
Shareholders, customers, and suppliers are also considered when searching for external
stakeholders.
Important factors to consider while performing the stakeholder analysis are:
Roles: how the stakeholders will contribute to the initiative.
Attitudes: Stakeholder attitudes can positively or negatively impact a change. Business analysts
analyze stakeholder attitudes about:
- business goals, objectives of the initiative, and any proposed solutions,
- business analysis in general,
- the level of interest in the change,
- the sponsor,
- team members and other stakeholders, and
- collaboration and a team-based approach.
Decision Making Authority: identify the authority level a stakeholder possesses
Level of Power or Influence: Understanding the influence and attitude of each stakeholder
.2 Define Stakeholder Collaboration
Ensuring effective collaboration with stakeholders is essential for maintaining their engagement in
business analysis activities. Collaboration can be a spontaneous event. Some considerations when
planning collaboration include:
- timing and frequency of collaboration,
- location,
- available tools such as wikis and online communities,
- delivery method such as in-person or virtual, and
- preferences of the stakeholders.
Planning considerations can be documented in the form of a stakeholder collaboration plan.
.3 Stakeholder Communication Needs
The business analyst evaluates:
- what needs to be communicated,
- what is the appropriate delivery method (written or verbal),
- who the appropriate audience is,
- when communication should occur,
- frequency of communication,
- geographic location of stakeholders who will receive communications,
- level of detail appropriate for the communication and stakeholder, and
- level of formality of communications.

3.2.5 Guidelines and Tools (page 35)
• Business Analysis Performance Assessment: provides results of previous assessments that
should be reviewed and incorporated.
• Change Strategy: used for improved assessment of stakeholder impact and the development of
more effective stakeholder engagement strategies.
• Current State Description: provides the context within which the work needs to be completed.
3.2.7 Stakeholders (page 36)
• Customers
• Domain Subject Matter Experts
• End Users
• Project Managers
• Regulators
• Sponsor
• Supplier
3.2.8 Outputs (page 36)
• 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 identiﬁes
the collaboration and communication approaches the business analyst will utilize during the
initiative.
3.3 Plan Business Analysis Governance (page 37)
3.3.1 Purpose
• deﬁne how decisions are made about requirements and designs, including reviews, change
control, approvals, and prioritization.
3.3.2 Description
When planning the governance approach, business analysts identify:
• how business analysis work will be approached and prioritized,
• what the process for proposing a change to business analysis information is,
• Brainstorming
• Business Rules Analysis
• Interviews
• Lessons Learned
• Mind Mapping
• Organizational Modelling
• Risk Analysis and Management
• Scope Modelling
• Stakeholder List, Map or Personas
• Survey or Questionnaire
• Workshops

• who has the authority and responsibility to propose changes and who should be involved in the
change discussions,
• who has responsibility for analyzing change requests,
• who has the authority to approve changes, and
• how changes will be documented and communicated.
3.3.3 Inputs
• Business Analysis Approach
3.3.4 Elements
.1 Decision Making
A stakeholder may serve in various roles in the decision-making process such as:
- participant in decision-making discussions,
- subject matter expert (SME) lending experience and knowledge to the decision-making process,
- reviewer of information, and
- approver of decisions.
The decision-making process defines what happens when teams cannot reach consensus, by
identifying escalation paths and key stakeholders who hold final decision-making authority.
.2 Change Control Process
When business analysts develop a change control process, they:
• Determine the process for requesting changes
• Determine the elements of the change request
- Cost and time estimates
- Benefits
- Risks
- Priority
- Course(s) of action
• Determine how changes will be prioritized
• Determine how changes will be documented
• Determine how changes will be communicated
• Determine who will perform the impact analysis
• Determine who will authorize change
.3 Plan Prioritization Approach
Timelines, expected value, dependencies, resource constraints, adopted methodologies, and other
factors influence how requirements and designs are prioritized. When planning the prioritization
process, business analysts determine the:
- formality and rigour of the prioritization process,

- participants who will be involved in prioritization,
- process for deciding how prioritization will occur, including which prioritization techniques will
be utilized, and
- criteria to be used for prioritization. For example, requirements may be prioritized based on
cost, risk, and value.
.4 Plan for Approvals
The business analyst must determine the type of requirements and designs to be approved, the
timing for the approvals, the process to follow to gain approval, and who will approve the
requirements and designs. Also includes the schedule of events where approvals will occur and
how they will be tracked.
3.3.5 Guidelines and Tools
• Business Analysis Performance Assessment: provides results of previous assessments that
should be reviewed and incorporated into all planning approaches.
• Business Policies: define the limits within which decisions must be made. May be described by
regulations, contracts, agreements, warranties, certifications or other legal obligations.
• Current State Description: provides the context within which the work needs to be completed.
This information can help drive how to make better decisions.
• 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.3.6 Techniques
3.3.7 Stakeholders
• Project Manager
• Regulator
• Sponsor
3.3.8 Output
• 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.
• Brainstorming
• Interviews
• Item Tracking
• Lessons Learned
• Organization Modelling
• Reviews
• Survey and Questionnaire
• Workshops

3.4 Plan Business Analysis Information Management (page 42)
3.4.1 Purpose
• develop an approach for how business analysis information will be stored and accessed.
3.4.2 Description
Information is comprised of all the information business analysts elicit, create, compile, and
disseminate in the course of performing business analysis. Information management entails
identifying:
- how information should be organized,
- the level of detail at which information should be captured,
- any relationships between the information,
- how information may be used across multiple initiatives and throughout the enterprise,
- how information should be accessed and stored, and
- characteristics about the information that must be maintained.
3.4.3 Inputs
• Governance Approach
3.4.4 Elements
.1 Organization of Business Analysis Information
Information must be well structured to ensure it is not difficult to locate, conflicts with other
information, or is needlessly duplicated. Things to consider are type and amount of information to
be collected, the stakeholder's access and usage needs, and the size and complexity of the
change.
.2 Level of Abstraction
Level of abstraction describes the breadth and depth of the information being provided.
.3 Plan Traceability Approach
The traceability approach is based on:
- the complexity of the domain,
- the number of views of requirements that will be produced,
- any requirement-related risks, organizational standards, applicable regulatory requirements,
and
- an understanding of the costs and benefits involved with tracing.

.4 Plan for Requirements Reuse
Reusing requirements can save an organization time, effort, and cost—provided the requirements
are accessible and structured in a manner that supports their reuse.
Requirements that are potential candidates for long-term use are those an organization must meet
on an ongoing basis such as:
• regulatory requirements, • contractual obligations, • quality standards,• service level
agreements, • business rules, • business processes, or • requirements describing products the
enterprise produces.
.5 Storage and Access
Business analysis information can be stored in many ways depending on who must access the
information, how often they need to access it, and what conditions must be present for access. It
deﬁnes how various tools will be used on the initiative and how the information will be captured and
stored within those tools.
.6 Requirements Attributes
Requirements attributes provide information about requirements, and aid in the ongoing
management of the requirements throughout the change. Some commonly used requirements
attributes include:
• Absolute reference (Unique ID), • Author, • Complexity,• Ownership, • Priority, • Risks, •
Source, • Stability, • Status, • Urgency
• Business Analysis Performance Assessments
• Business Policies
• Information Management Tools
• Legal/ Regulatory Information
3.4.6 Techniques
3.4.7 Stakeholders
• Regulator
• Sponsor
• Brainstorming
• Interviews
• Item Tracking
• Lessons Learned
• Mind Mapping
• Workshops

3.4.8 Output
• 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.
3.5 Identify Business Analysis Performance Improvements (page 47)
3.5.1 Purpose
• assess business analysis work and to plan to improve processes where required.
3.5.2 Description
To monitor and improve performance, it is necessary to establish the performance measures,
conduct the performance analysis, report on the results of the analysis, and identify any necessary
preventive, corrective, or developmental actions. Performance analysis should occur throughout an
initiative. Once potential performance improvements are identified, they become guidelines for the
next time a task is executed.
3.5.3 Inputs
• Performance Objectives (external): describe the desired performance outcomes that an
enterprise or organization is hoping to achieve.
3.5.4 Elements
.1 Performance Analysis
Reports on business analysis performance can be informal and verbal, or they may include formal
documentation; and are designed and tailored to meet the needs of the various types of reviewers.
.2 Assessment Measures
Appropriate performance measures enable the business analyst to determine when problems are
occurring that may affect the performance of business analysis or identify opportunities for
improvement. Measures may be both quantitative and qualitative. Some possible measures are:
- Accuracy and Completeness (correct and relevant)
- Knowledge
- Effectiveness
- Organizational Support
- Significance (value justification)
- Strategic (meet objectives, solve problems and achieve improvements)
- Timeliness
.3 Analyze Results
The business analysis process and deliverables are compared against the set of defined
measures. The analysis may be performed on the business analysis process, the resources
involved, and the deliverables.

.4 Recommend Actions for Improvement
- Preventive: reduces the probability of an event with a negative impact
- Corrective: establishes ways to reduce the negative impact of an event
- Improvements: establishes ways to increase the probability or impact of events with a positive
impact.
• Organizational Performance Standards
3.5.6 Techniques
3.5.7 Stakeholders
• Project Manager
• Sponsor
3.5.8 Outputs
Business Analysis Performance 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 ﬁndings to help understand the performance of business
analysis processes.
• Brainstorming
• Interviews
• Item Tracking
• Lessons Learned
• Metrics and Key Performance Indicators (KPIs)
• Observation
• Process Analysis
• Reviews
• Root Cause Analysis
• Workshops

Chapter 4: Elicitation and Collaboration (page 53)
• The Elicitation and Collaboration knowledge area describes the tasks that business analysts
perform to obtain information from stakeholders, conﬁrm the results and communicate
with stakeholders once the business analysis information is assembled.
• Elicitation is the drawing forth or receiving of information from stakeholders or other
sources and is the main path to discovering requirements and design information.
• Collaboration is the act of two or more people working together towards a common goal.
• Elicitation and collaboration can be planned, unplanned, or both and is an ongoing activity.
Planned activities include workshops, experiments, and/or surveys whereas unplanned activities
can be last-minute or 'just in time' collaboration or conversations.
The Elicitation and Collaboration knowledge area is composed of the following tasks:
• Prepare for Elicitation
• Conduct Elicitation
• Conﬁrm Elicitation Results
• Communicate Business Analysis Information
• Manage Stakeholder Collaboration
 

4.1 Prepare for Elicitation (page 56)
4.1.1 Purpose
• understand the scope of the elicitation activity, select appropriate techniques, and plan for (or
procure) appropriate supporting materials and resources.
4.1.2 Description
• deﬁning the desired outcomes of the activity, considering the stakeholders involved and the
goals of the initiative
• 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, and understanding circumstances to foster
collaboration during an elicitation activity.
4.1.3 Inputs
• Needs
4.1.4 Elements
.1 Understand the Scope of Elicitation
To determine the type of business analysis information to be discovered during the elicitation
activity and the techniques that may be used, business analysts consider:
• business domain,
• overall corporate culture and environment,
• stakeholder locations,
• stakeholders who are involved and their group dynamics,
• expected outputs the elicitation activities will feed,
• skills of the business analysis practitioner,
• other elicitation activities planned to complement this one,
• strategy or solution approach,
• scope of future solution, and
• possible sources of the business analysis information that might feed into the speciﬁc elicitation
activity.  
.2 Select Elicitation Techniques
The techniques used depend on cost and time constraints, the types of business analysis
information sources and their access, the culture of the organization, and the desired outcomes; in
addition to the needs of the stakeholders, their availability, and their location (co-located or
dispersed). When selecting elicitation techniques, business analysts consider:

• techniques commonly used in similar initiatives, 
• techniques speciﬁcally suited to the situation, and 
• the tasks needed to prepare, execute, and complete each technique.
Due to changing dynamics and situations, the business analyst may be required to adjust the initial
selections by incorporating more appropriate techniques. A thorough understanding of the variety
of techniques available assists the business analyst in adapting to changing circumstances.
.3 Set Up Logistics
Logistics are planned prior to an elicitation activity. 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).
.4 Secure Supporting Material
Business analysts identify sources of information that are needed to conduct the elicitation activity.
There might be a great deal of information needed to conduct elicitation including people, systems,
historical data, materials and documents. Business analysts procure or develop the materials and
tools needed.
.5 Prepare Stakeholders
Business analysts may need to educate stakeholders on how an elicitation technique works or
what information is needed. Stakeholders may be unresponsive or challenging during an elicitation
activity. In preparing for elicitation, the business analyst should ensure that there is buy-in from all
necessary stakeholders.
• Business Objectives
• Existing Business Analysis Information
• Potential Value
4.1.6 Techniques
• Brainstorming
• Data Mining
• Estimation
• Interviews
• Mind Mapping
• Stakeholder List, Map, or Personas

4.1.7 Stakeholders
• Project Manager
• Sponsor
4.1.8 Outputs
• Elicitation Activity Plan: used for each elicitation activity. It includes logistics, scope of the
elicitation activity, selected techniques, and supporting materials.
4.2 Conduct Elicitation (page 61)
4.2.1 Purpose
• draw out, explore, and identify information relevant to the change.
4.2.2 Description
There are three common types of elicitation:
- Collaborative: involves direct interaction with stakeholders, and relies on their experiences,
expertise, and judgment.
- Research: involves systematically discovering and studying information from materials or
sources that are not directly known by stakeholders involved in the change. 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. Experiments can help discover previously unknown information. Experiments
include observational studies, proofs of concept, and prototypes.
Stakeholders may collaborate in elicitation by:
- participating and interacting during the elicitation activity, and
- researching, studying, and providing feedback on documents, systems, models, and interfaces.
4.2.3 Inputs
• Elicitation Activity Plan
4.2.4 Elements
.1 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.
.2 Capture Elicitation Outcomes
If the elicitation activity is unplanned, outcomes are captured and integrated into the appropriate
planned outcomes. Capturing the elicitation outcomes helps to ensure that the information
produced during elicitation activities is recorded for later reference and use.
• Supporting Materials
4.2.6 Techniques
4.2.7 Stakeholders
• Customers
• End Users
• Implementation Subject Matter Experts
• Sponsor
• Any stakeholders
4.2.8 Outputs
• Elicitation Results (unconﬁrmed): captured information in a format that is speciﬁc to the
elicitation activity.
• Benchmarking and Market Analysis
• Brainstorming
• Collaborative Games
• Concept Modelling
• Data Mining
• Data Modelling
• Focus Groups
• Interface Analysis
• Interviews
• Mind Mapping
• Observation
• Prototyping
• Workshops

4.3 Confirm Elicitation Results (page 65)
4.3.1 Purpose
• check the information gathered during an elicitation session for accuracy and consistency with
other information.
4.3.2 Description
Elicited information is confirmed to identify any problems and resolve them before resources are
committed to using the information. This review may discover errors, omissions, conflicts, and
ambiguity.
4.3.3 Inputs
• Elicitation Results (Unconfirmed)
4.3.4 Elements
.1 Compare Elicitation Results Against Source Information
Task Conduct Elicitation (p. 61) describes sources from which elicitation results may be derived,
including documents and stakeholder knowledge. The business analyst may lead follow-up
meetings where stakeholders correct the elicitation results.
.2 Compare Elicitation Results Against Other Elicitation Results
Business analysts compare results collected through multiple elicitation activities, identify
variations in results and resolve them, to confirm that the information is consistent and accurately
represented.
• Elicitation Activity Plan
4.3.6 Techniques
4.3.7 Stakeholders
4.3.8 Outputs
• 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.
• Interviews
• Reviews
• Workshops

4.4 Communicate Business Analysis Information (page 67)
4.4.1 Purpose
• Ensure stakeholders have a shared understanding of business analysis information.
4.4.2 Description
• Business analysts must communicate appropriate information to stakeholders at the right time
and in formats that meet their needs considering the language, tone, and style that is
appropriate to the audience.
• Communication of business analysis information is bi-directional and iterative. It involves
determining the recipients, content, purpose, context, and expected outcomes.
• Business analysts engage stakeholders to ensure they understand the information and gain
agreement. The business analyst acts on any disagreements.
4.4.3 Inputs
• Business Analysis Information
4.4.4 Elements
.1 Determine Objectives and Format of Communication
Business analysis information packages may be prepared for a number of reasons including:
- communication of requirements and designs to stakeholders,
- early assessment of quality and planning,
- evaluation of possible alternatives,
- formal reviews and approvals,
- inputs to solution design,
- conformance to contractual and regulatory obligations, and
- maintenance for reuse
The primary goal of developing a package is to convey information clearly and in usable format for
continuing change activities. Possible forms for packages may include:
• Formal Documentation: usually based on a template used by the organization and may include
text, matrices, or diagrams. It provides a stable, easy to use, long-term record of the information.
• Informal Documentation: may include text, diagrams, or matrices that are used during a
change but are not part of a formal organizational process.
• Presentations: deliver a high-level overview appropriate for understanding goals of a change,
functions of a solution, or information to support decision making.  

.2 Communicate Business Analysis Package
The main purpose of this is to provide stakeholders with the appropriate level of detail about the
change so they can understand the information it contains. Stakeholders are given the opportunity
to review the package, ask questions about the information, and raise any concerns they may
have. Common communication platforms include:
• Group collaboration: used to communicate the package to a group of relevant stakeholders at
the same time. It allows immediate discussion about the information and related issues.
• Individual collaboration: used to communicate the package to a single stakeholder at a time to
gain individual understanding of the information when a group setting is not feasible, most
productive, or going to yield the best results.
• E-mail or other non-verbal methods: used to communicate the package when there is a high
maturity level of information that will need little or no verbal explanation to support it.
• Information Management Approach
4.4.6 Techniques
4.4.7 Stakeholders
• End User
• Customer
• Implementation Subject Matter Expert
• Tester
4.4.8 Outputs
• Business Analysis Information (communicated): business analysis information is considered
communicated when the target stakeholders have reached an understanding of its content and
implications.
4.5 Manage Stakeholder Collaboration (page 71)
4.5.1 Purpose
• Encourage stakeholders to work towards a common goal.
4.5.2 Description
• Stakeholders hold various degrees of inﬂuence and authority over the approval of work
products, and are also an important source of needs, constraints, and assumptions. As the
• Interviews
• Reviews
• Workshops

business analysis work progresses, the business analyst identifies stakeholders, confirms their
roles, and communicates with them to ensure that the right stakeholders participate at the right
times and in the appropriate roles.
• Managing stakeholder collaboration is an ongoing activity. Although managing stakeholder
collaboration begins once stakeholders have been identified and analyzed, new stakeholders
may be identified at any point during an initiative.
• 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 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, and
- participate in the execution of business analysis tasks.
4.5.3 Inputs
• Business Analysis Performance Assessment
4.5.4 Elements
.1 Gain Agreement on Commitments
Stakeholders participate in business analysis activities that may require time and resource
commitments. The business analyst and stakeholders identify and agree upon these commitments
as early in the initiative as possible. The specific details of the commitments can be communicated
formally or informally, as long as there is explicit understanding of the expectations and desired
outcomes of the commitment.
.2 Monitor Stakeholder Engagement
Business analysts monitor the participation and performance of stakeholders to ensure that:
• the right subject matter experts (SMEs) and other stakeholders are participating effectively,
• stakeholder attitudes and interest are staying constant or improving,
• elicitation results are confirmed in a timely manner, and
• agreements and commitments are maintained.
Business analysts continually monitor for such risks as:
• stakeholders being diverted to other work,
• elicitation activities not providing the quality of business analysis information required, and
• delayed approvals.  

.3 Collaboration
Stakeholders are more likely to support change if business analysts collaborate with them and
encourage the free ﬂow of information, ideas, and innovations. Genuine stakeholder engagement
requires that all stakeholders involved feel that they are heard, their opinions matter, and their
contributions are recognized. Collaboration involves regular, frequent, and bi-directional
communication.
• Future State Description
• Recommended Actions
• Risk Analysis Results
4.5.6 Techniques
4.5.7 Stakeholders
• All stakeholders
4.5.8 Outputs
• Stakeholder Engagement: willingness from stakeholders to engage in business analysis
activities and interact with the business analyst when necessary.
• Collaborative Games
• Lessons Learned

Chapter 5: Requirements Life Cycle Management (page 75)
• The Requirements Life Cycle Management knowledge area describes the tasks that business
analysts perform in order to manage and maintain requirements and design information
from inception to retirement.
• These tasks describe establishing meaningful relationships between related requirements
and designs, assessing changes to requirements and designs when changes are
proposed, and analyzing and gaining consensus on changes.
• The purpose of requirements life cycle management is to ensure that business, stakeholder, and
solution requirements and designs are aligned to one another and that the solution implements
them. It involves a level of control over requirements and over how requirements will be
implemented in the actual solution to be constructed and delivered. It also helps to ensure that
business analysis information is available for future use. The requirements life cycle:
- begins with the representation of a business need as a requirement,
- continues through the development of a solution, and
- ends when a solution and the requirements that represent it are retired.
The Requirements Life Cycle Management knowledge area includes the following tasks:
• Trace Requirements: analyzes and maintains the relationships between requirements, designs,
solution components, and other work products for impact analysis, coverage, and allocation.
• Maintain Requirements: ensures that requirements and designs are accurate and current
throughout the life cycle and facilitates reuse where appropriate
• Prioritize Requirements: 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.
• Assess Requirements Changes: evaluates new and changing stakeholder requirements to
determine if they need to be acted on within the scope of a change.
• Approve Requirements: works with stakeholders involved in the governance process to reach
approval and agreement on requirements and designs.

5.1 Trace Requirements (page 79)
5.1.1 Purpose
• 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.
5.1.2 Description
• Requirements traceability identifies and documents the lineage of each requirement, including
its backward traceability, its forward traceability, and its relationship to other requirements.
• Traceability is used to help ensure that the solution conforms to requirements and to assist in
scope, change, risk, time, cost, and communication management. It is also used to detect
missing functionality or to identify if there is implemented functionality that is not supported by
any requirement. 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, and
- 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.
5.1.3 Inputs
• Requirements
• Designs
5.1.4 Elements
.1 Level of Formality
When tracing requirements, business analysts consider the value that each link is supposed to
deliver, as well as the nature and use of the specific relationships that are being created. The effort
to trace requirements grows significantly when the number of requirements or level of formality
increases .
.2 Relationships
There are several types of relationships that the business analyst considers when defining the
traceability approach:
• Derive: relationship between two requirements, used when a requirement is derived from
another requirement. This type of relationship is appropriate to link the requirements on different
levels of abstraction. For example, a solution requirement derived from a business or a
stakeholder requirement.
• Depends: relationship between two requirements, used when a requirement depends on
another requirement. Types of dependency relationships include:
- Necessity: when it only makes sense to implement a particular requirement if a related
requirement is also implemented.

- Effort: when a requirement is easier to implement if a related requirement is also
implemented.
• Satisfy: relationship between an implementation element and the requirements it is satisfying.
For example, the relationship between a functional requirement and a solution component that is
implementing it.
• Validate: relationship between a requirement and a test case or other element that can
determine whether a solution fulfills the requirement.  
.3 Traceability Repository
Requirements traceability is documented and maintained in accordance with the methods identified
by the business analysis approach.
• Domain Knowledge
• Legal/Regulatory Information
• Requirements Management Tools/Repository
5.1.6 Techniques
5.1.7 Stakeholders
• Customer
• End User
• Operational Support
• Project Manager
• Sponsor
• Suppliers
• Tester
5.1.8 Outputs
• 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.
• Designs (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.
• Scope Modelling

5.2 Maintain Requirements (page 83)
5.2.1 Purpose
• 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.
5.2.2 Description
• A requirement that represents an ongoing need must be maintained to ensure that it remains
valid over time. In order to maximize the benefits of maintaining and reusing requirements, the
requirements should be:
- consistently represented,
- reviewed and approved for maintenance using a standardized process that defines proper
access rights and ensures quality, and
- easily accessible and understandable.
5.2.3 Inputs
• Requirements
• Designs
5.2.4 Elements
.1 Maintain Requirements
Requirements are maintained so that they remain correct and current after an approved change.
Business analysts are responsible for conducting maintenance to ensure this level of accuracy is
retained. For requirements to be properly maintained they must be clearly named and defined, and
easily available to stakeholders. Business analysts also maintain the relationships among
requirements, sets of requirements, and associated business analysis information to ensure the
context and original intent of the requirement is preserved.
.2 Maintain Attributes
While eliciting requirements, business analysts elicit requirement attributes. Information such as
the requirement’s source, priority, and complexity aid in managing each requirement throughout
the life cycle. Some attributes change as the business analyst uncovers more information and
conducts further analysis. An attribute may change even though the requirement does not.
.3 Reusing Requirements
Requirements that are candidates for long-term use by the organization are identified, clearly
named, defined, and stored in a manner that makes them easily retrievable by other stakeholders.
Depending on the level of abstraction and intended need being addressed, requirements can be
reused:
• within the current initiative,
• within similar initiatives,
• within similar departments, and
• throughout the entire organization.

5.2.6 Techniques
5.2.7 Stakeholders
• Regulator
• Tester
5.2.8 Outputs
• 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 self- contained
component that can be made available for possible future use.
5.3 Prioritize Requirements (page 86)
5.3.1 Purpose
• Rank requirements in the order of relative importance.
5.3.2 Description
• Prioritization is the act of ranking requirements to determine their relative importance to
stakeholders. When a requirement is prioritized, it is given greater or lesser priority. Priority can
refer to the relative value of a requirement, or to the sequence in which it will be implemented.
Prioritization is an ongoing process, with priorities changing as the context changes.
• Inter-dependencies between requirements are identified and may be used as the basis for
prioritization. Prioritization is a critical exercise that seeks to ensure the maximum value is
achieved.
5.3.3 Inputs
• Requirements
• Designs
• Data Flow Diagrams
• Data Modelling
• Use Cases and Scenarios
• User Stories

5.3.4 Elements
.1 Basis for Prioritization
The basis on which requirements are prioritized is agreed upon by relevant stakeholders as
defined in the Business Analysis Planning and Monitoring knowledge area. Typical factors that
influence prioritization include:
• Benefit: the advantage that accrues to stakeholders as a result of requirement implementation,
as measured against the goals and objectives for the change. If there are multiple stakeholders,
each group may perceive benefits differently. Conflict resolution and negotiation may be
employed to come to consensus on overall benefit.
• Penalty: the consequences that result from not implementing a given requirement. This includes
prioritizing requirements in order to meet regulatory or policy demands imposed on the
organization, which may take precedence over other stakeholder interests. Penalty may also
refer to the negative consequence of not implementing a requirement that improves the
experience of a customer.
• Cost: the effort and resources needed to implement the requirement. Information about cost
typically comes from the implementation team or the vendor. Customers may change the priority
of a requirement after learning the cost. Cost is often used in conjunction with other criteria, such
as cost-benefit analysis.
• Risk: the chance that the requirement cannot deliver the potential value, or cannot be met at all.
This may include many factors such as the difficulty of implementing a requirement, or the
chance that stakeholders will not accept a solution component. A proof of concept may be
developed to establish that high risk options are possible.
• Dependencies: relationships between requirements where one requirement cannot be fulfilled
unless the other requirement is fulfilled. Dependencies may also be external to the initiative,
including but not limited to other teams’ decisions, funding commitments, and resource
availability.
• Time Sensitivity: the 'best before' date of the requirement, after which the implementation of
the requirement loses significant value. This includes seasonal functionality, or time-to-market
scenarios, in which the benefit derived will be exponentially greater if the functionality is
delivered ahead of the competition.
• Stability: the likelihood that the requirement will change, either because it requires further
analysis or because stakeholders have not reached a consensus about it. If a requirement is not
stable, it may have a lower priority in order to minimize unanticipated rework and wasted effort.
• Regulatory or Policy Compliance: requirements that must be implemented in order to meet
regulatory or policy demands imposed on the organization, which may take precedence over
other stakeholder interests. 
.2 Challenges of Prioritization
Prioritization is an assessment of relative value. Each stakeholder may value something different.
Stakeholders may also have difficulty characterizing any requirement as a lower priority, and this
may impact the ability to make necessary trade-offs.

.3 Continual Prioritization
Priorities may shift as the context evolves and as more information becomes available. Initially,
prioritization is done at a higher level of abstraction. As the requirements are further refined,
prioritization is done at a more granular level and will incorporate additional bases for prioritization
as they become appropriate. The basis for prioritization may be different at various stages of the
change based on factors such as benefits or cost.
• Business Constraints
• Change Strategy
• Requirements Architecture
• Requirements Management Tools/ Repository
• Solution Scope
5.3.6 Techniques
5.3.7 Stakeholders
• Customer
• End User
• Project Manager
• Regulator
• Sponsor
5.3.8 Outputs
• 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.
5.4 Assess Requirements Changes (page 91)
5.4.1 Purpose
• Evaluate the implications of proposed changes to requirements and designs.
• Backlog Management
• Business Cases
• Decision Analysis
• Estimation
• Interviews
• Item Tracking
• Prioritization
• Workshops

5.4.2 Description
• Performed as new needs or possible solutions are identified. Assessment must be performed to
determine whether a proposed change will increase the value of the solution, and if so, what
action should be taken.
• Business analysts assess the potential effect of the change to solution value, and whether
proposed changes introduce conflicts with other requirements or increase the level of risk.
Business analysts also ensure each proposed change can be traced back to a need. When
assessing changes, business analysts consider if each proposed change:
- aligns with the overall strategy,
- affects value delivered to the business or stakeholder groups,
- impacts the time to deliver or the resources required to deliver the value, and
- alters any risks, opportunities, or constraints associated with the overall initiative.
5.4.3 Inputs
• Proposed Change
• Requirements
• Designs
5.4.4 Elements
.1 Assessment Formality
Business analysts will determine the formality of the assessment process based on the information
available, the apparent importance of the change, and the governance process.
A predictive approach may indicate a more formal assessment of proposed changes. In predictive
approaches, the impact of each change can be disruptive; the change can potentially generate a
substantial reworking of tasks and activities completed in previous activities.
An adaptive approach may require less formality in the assessment of proposed changes. While
there may be reworking needed as a result of each change, adaptive approaches try to minimize
the impact of changes by utilizing iterative and incremental implementation techniques.
.2 Impact Analysis
Impact analysis is performed to assess or evaluate the effect of a change. Traceability is a useful
tool for performing impact analysis. When a requirement changes, its relationships to other
requirements or solution components can be reviewed. When considering changes or additions to
existing requirements, business analysts assess the impact of the proposed change by
considering:
Benefit: the benefit that will be gained by accepting the change.
Cost: the total cost to implement the change including the cost to make the change, the cost of
associated rework, and the opportunity costs.
Impact: the number of customers or business processes affected if the change is accepted.

Schedule: the impact to the existing delivery commitments if the change is approved.
Urgency: the level of importance including the factors which drive necessity such as regulator or
safety issues.
.3 Impact Resolution
Depending on the planned approach, various stakeholders (including the business analyst) may be
authorized to approve, deny, or defer the proposed change. All impacts and resolutions resulting
from the change analysis are to be documented and communicated to all stakeholders.
• Change Strategy
• Solution Scope
5.4.6 Techniques
5.4.7 Stakeholders
• Customer
• End User
• Project Manager
• Regulator
• Sponsor
• Tester
5.4.8 Outputs
• 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.
• Business Cases
• Estimation
• Interviews
• Item Tracking
• Workshops

5.5 Approve Requirements (page 95)
5.5.1 Purpose
• Obtain agreement on and approval of requirements and designs for business analysis work to
continue and/or solution construction to proceed.
5.5.2 Description
• Business analysts are responsible for ensuring clear communication of requirements, designs,
and other business analysis information to the key stakeholders responsible for approving that
information. Approval of requirements and designs may be formal or informal.
• Predictive approaches typically perform approvals at the end of the phase or during planned
change control meetings.
• Adaptive approaches typically approve requirements only when construction and implementation
of a solution meeting the requirement can begin.
5.5.3 Inputs
• Requirements (verified)
• Designs
5.5.4 Elements
.1 Understand Stakeholder Roles
Part of defining the approval process is understanding stakeholder roles and authority levels.
Business analysts are responsible for obtaining stakeholder approvals and are required to
understand who holds decision-making responsibility and who possesses authority for sign-off
across the initiative.
.2 Conflict and Issue Management
Stakeholder groups frequently have varying points of view and conflicting priorities. A conflict may
arise among stakeholders as a result of different interpretations of requirements or designs and
conflicting values placed on them.
The business analyst facilitates communication between stakeholders in areas of conflict so that
each group has an improved appreciation for the needs of the others. Conflict resolution and issue
management may occur quite often, as the business analyst is reviewing requirements and
designs, and aiming to secure sign-off.
.3 Gain Consensus
Approval may confirm that stakeholders believe that sufficient value will be created for the
organization to justify investment in a solution. Business analysts obtain approval by reviewing the
requirements or changes to requirements with the accountable individuals or groups and
requesting that they approve, indicating their agreement with the solution or designs described.
Complete agreement may not be necessary for a successful change, but if there is a lack of
agreement, the associated risks are to be identified and managed accordingly.

.4 Track and Communicate Approval
The business analyst records approval decisions, possibly in requirements maintenance and
tracking tools. In order to communicate the status of requirements, it is necessary to keep accurate
records of current approval status.
• Change Strategy
• Requirements Management Tools/ Repository
• Solution Scope
5.5.6 Techniques
5.5.7 Stakeholders
• Customer
• End User
• Project Manager
• Regulator
• Sponsor
• Tester
5.5.8 Outputs
• 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.
• Acceptance and Evaluation Criteria
• Item Tracking
• Reviews
• Workshops

Chapter 6: Strategy Analysis (page 99)
• Strategy defines the most effective way to apply the capabilities of an enterprise in order to
reach a desired set of goals and objectives. Strategies may exist for the entire enterprise, for a
division, department or region, and for a product, project, or iteration.
• The Strategy Analysis knowledge area describes the business analysis work that must be
performed to collaborate with stakeholders in order to identify a need of strategic or tactical
importance (the business need), enable the enterprise to address that need, and align the
resulting strategy for the change with higher- and lower-level strategies.
• Strategy analysis focuses on defining the future and transition states needed to address the
business need, and the work required is defined both by that need and the scope of the solution
space.
• Strategy analysis provides context to requirements analysis and design definition for a given
change. Strategy analysis should be performed as a business need is identified. This allows
stakeholders to make the determination of whether to address that need or not. Strategy
analysis is an ongoing activity that assesses any changes in that need, in its context, or any new
information that may indicate that an adjustment to the change strategy may be required.
The following image illustrates the spectrum of value as business analysis activities progress from
delivering potential value to actual value.
A strategy may be captured in a strategic plan, product vision, business case, product roadmap, or
other artifacts. The Strategy Analysis knowledge area includes the following tasks:
• Analyze Current State: understands the business need and how it relates to the way the
enterprise functions today. Sets a baseline and context for change.
• Define Future State: 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.
• Assess Risks: 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.

• Deﬁne Change Strategy: 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.

6.1 Analyze Current State (page 103)
6.1.1 Purpose
• 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.
6.1.2 Description
• The starting point for any change is an understanding of why the change is needed. Potential
change is triggered by problems or opportunities that cannot be addressed without altering the
current state. Without clearly understood business needs, it is impossible to develop a coherent
strategy.
• Change always occurs in a context of existing stakeholders, processes, technology, and policies
which constitute the current state of the enterprise. Business analysts examine the current state
in the context of the business need to understand what may influence proposed changes, and
what will be affected by them.
• The current state is explored in just enough detail to validate the need for a change and/or the
change strategy. The current state of an enterprise is rarely static while a change is being
developed and implemented.
6.1.3 Inputs
• Elicitation Results
• Needs
6.1.4 Elements
.1 Business Needs
Business needs are the problems and opportunities of strategic importance faced by the
enterprise. An issue encountered in the organization, such as a customer complaint, a loss of
revenue, or a new market opportunity, usually triggers the evaluation of a business need. A
business need may be identified at many different levels of the enterprise:
• From the top-down: a strategic goal that needs to be achieved.
• From the bottom-up: a problem with the current state of a process, function or system.
• From middle management: a manager needs additional information to make sound decisions
or must perform additional functions to meet business objectives.
• From external drivers: customer demand or business competition in the marketplace.
The definition of business needs is frequently the most critical step in any business analysis effort.
A solution must satisfy the business needs to be considered successful. The way the need is
defined determines which alternative solutions will be considered, which stakeholders will be
consulted, and which solution approaches will be evaluated.
Business needs are always expressed from the perspective of the enterprise, and not that of any
particular stakeholder. Business needs are often identified or expressed along with a presumed
solution. Business needs will drive the overall analysis of the current state.

 
A solution to a set of business needs must have the potential to generate benefits for the enterprise
or its stakeholders, or avoid losses that would otherwise occur. Factors the business analyst may
consider include:
• adverse impacts the problem is causing within the organization and quantify those impacts (for
example, potential lost revenue, inefficiencies, dissatisfied customers, low employee morale),
• expected benefits from any potential solution (for example, increased revenue, reduced costs,
increased market share),
• how quickly the problem could potentially be resolved or the opportunity could be taken, and the
cost of doing nothing, and
• the underlying source of the problem.  
.2 Organizational Structure and Culture
Organizational structure defines the formal relationships between people working in the enterprise.
While communication channels and relationships are not limited to that structure, they are heavily
influenced by it.
Organizational culture is the beliefs, values, and norms shared by the members of an organization.
These beliefs drive the actions taken by an organization. Business analysts perform a cultural
assessment to:
• identify if cultural changes are required to better achieve the goals,
• identify whether stakeholders understand the rationale for the current state of the enterprise and
the value delivered by it, and
• ascertain whether the stakeholders view the current state as satisfactory or if change is needed.
.3 Capabilities and Processes
Capabilities and processes describe the activities an enterprise performs. They also include the
knowledge the enterprise has, the products and services it provides, the functions it supports, and
the methods it uses to make decisions. Core capabilities or processes describe the essential
functions of the enterprise that differentiate it from others. They are measured by performance
indicators that can be used to assess the benefits of a change.
Business analysts may use:
• A capability-centric view of the enterprise when looking for innovative solutions that combine
existing capabilities to produce a new outcome. A capability-based view is useful in this situation
because capabilities are generally organized in a functional hierarchy with relationships to other
capabilities, making it easier to identify any gaps.
• A process-centric view of the enterprise when looking for ways to improve the performance of
current activities. A process-based view is useful in this situation because processes are
organized in an end-to-end fashion across the enterprise to deliver value to its customers,
making it easier to ensure that a change does in fact increase performance.  

.4 Technology and Infrastructure
Information systems used by the enterprise support people in executing processes, making
decisions, and in interactions with suppliers and customers.
The infrastructure describes the enterprise’s environment with respect to physical components and
capabilities. The infrastructure can include components such as computer hardware, physical
plants, and logistics, as well as their operation and upkeep.
.5 Policies
Policies define the scope of decision making at different levels of an enterprise. They generally
address routine operations rather than strategic change. They ensure that decisions are made
correctly, provide guidance to staff on permitted and appropriate behaviour and actions, support
governance, and determine when and how new resources can be acquired.
.6 Business Architecture
Business analysts must understand how all of the elements of the current state fit together and
support one another in order to recommend changes that will be effective. The existing business
architecture typically meets an assortment of business and stakeholder needs.
.7 Internal Assets
Business analysts identify enterprise assets used in the current state. Resources can be tangible
or intangible, such as financial resources, patents, reputation, and brand names.
.8 External Influences
There are external influences on the enterprise that do not participate in a change but might
present constraints, dependencies, or drivers on the current state. Sources of external influence
include:
• Industry Structure
• Competitors
• Customers
• Suppliers
• Political and Regulatory Environment
• Technology
• Macroeconomic Factors 
• Enterprise Limitation
• Organizational Approach
• Solution Limitation
• Solution Performance Goals
• Solution Performance Measures
• Stakeholder Analysis Results

6.1.6 Techniques
6.1.7 Stakeholders
• Customer
• End User
• Project Manager
• Regulator
• Sponsor
• Supplier
• Tester
6.1.8 Outputs
• 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 Capability Analysis
• Business Model Canvas
• Business Cases
• Data Mining
• Focus Group
• Interviews
• Item Tracking
• Lessons Learned
• Mind Mapping
• Observation
• Scope Modelling
• SWOT Analysis
• Vendor Assessment
• Workshops

6.2 Define Future State (page 110)
6.2.1 Purpose
• Determine the set of necessary conditions to meet the business need.
6.2.2 Description
• Business analysts work to ensure that the future state of the enterprise is well defined, that it is
achievable with the resources available, and that key stakeholders have a shared consensus
vision of the outcome. The future state will be defined at a level of detail that:
- allows for competing strategies to achieve the future state to be identified and assessed,
- provides a clear definition of the outcomes that will satisfy the business needs,
- details the scope of the solution space,
- allows for value associated with the future state to be assessed, and
- enables consensus to be achieved among key stakeholders.
• The future state description can include any context about the proposed future state. It describes
the new, removed, and modified components of the enterprise. It can include simple changes to
existing components of an organization to changes to the boundaries of the organization itself.
• Change may be needed to any component of the enterprise, including (but not limited to)
business processes, functions, lines of business, organization structures, staff competencies,
knowledge and skills, training, facilities, desktop tools, organization locations, data and
information, application systems, and/or technology infrastructure.
• Descriptions may include visual models and text to clearly show the scope boundaries and
details. Relevant relationships between entities are identified and described.
6.2.3 Inputs
• Business Requirements
6.2.4 Elements
.1 Business Goals and Objectives
Business goals and objectives describe the ends that the organization is seeking to achieve. Goals
and objectives can relate to changes that the organization wants to accomplish, or current
conditions that it wants to maintain.
Goals are longer term, ongoing, and qualitative statements of a state or condition that the
organization is seeking to establish and maintain. Examples of business goals include:
• Create a new capability such as a new product or service, address a competitive disadvantage,
or create a new competitive advantage.
• Improve revenue by increasing sales or reducing cost.
• Increase customer satisfaction.
• Increase employee satisfaction.
• Comply with new regulations.

• Improve safety.
• Reduce time to deliver a product or service
High-level goals can be decomposed to break down the general strategy into areas that may lead
to desired results, such as increased customer satisfaction, operational excellence, and/or
business growth.
As goals are analyzed they are converted into more descriptive, granular and specific objectives,
and linked to measures that make it possible to objectively assess if the objective has been
achieved. A common test for assessing objectives is to ensure that they are SMART (Specific,
Measurable, Achievable, Relevant and Time-bound)
.2 Scope of Solution Space
The scope of the solution space defines which kinds of options will be considered when
investigating possible solutions, including changes to the organizational structure or culture,
capabilities and processes, technology and infrastructure, policies, products, or services, or even
creating or changing relationships with organizations currently outside the scope of the extended
enterprise.
If multiple future states can meet the business needs, goals and objectives, it will be necessary to
determine which ones will be considered. This decision is typically based on the value to be
delivered to stakeholders and requires an understanding of possible change strategies. The critical
considerations for the decision are dependent on the overall objectives of the enterprise, but will
involve an understanding of the quantitative and qualitative value of each option, the time needed
to achieve each future state, and the opportunity cost to the enterprise.
.3 Constraints
Constraints describe aspects of the current state, aspects of the planned future state that may not
be changed by the solution, or mandatory elements of the design. They must be carefully
examined to ensure that they are accurate and justified. Constraints may reflect any of the
following: 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.
.4 Organizational Structure and Culture
The formal and informal working relationships that exist within the enterprise may need to change
to facilitate the desired future state. Changes to reporting lines can encourage teams to work more
closely together and facilitate alignment of goals and objectives. Elements of the organizational
structure and culture may need to change to support the future state. Describing the components
of the future state provides insight into potential conflicts, impact, and limits.
.5 Capabilities and Processes
Identify new kinds of activities or changes in the way activities will be performed to realize the
future state. New or changed capabilities and processes will be needed to deliver new products or
services, to comply with new regulations, or to improve the performance of the enterprise.

.6 Technology and Infrastructure
The existing technology may impose technical constraints on the design of the solution. If current
technology and infrastructure are insufficient to meet the business need, the business analyst
identifies the changes necessary for the desired future state.
.7 Policies
Policies are a common source of constraints on a solution or on the solution space. Business
policies may mandate what solutions can be implemented given certain levels of approval, the
process for obtaining approval, and the necessary criteria a proposed solution must meet in order
to receive funding.
.8 Business Architecture
The elements of any future state must effectively support one another and all contribute to meeting
the business goals and objectives. In addition, they should be integrated into the overall desired
future state of the enterprise as a whole, and support that future state.
.9 Internal Assets
The analysis of resources might indicate that existing resources need to be increased or require
increased capabilities, or that new resources need to be developed. When analyzing resources,
business analysts examine the resources needed to maintain the current state and implement the
change strategy, and determine what resources can be used as part of a desired future state.
.10 Identify Assumptions
Most strategies are predicated on a set of assumptions that will determine whether or not the
strategy can succeed, particularly when operating in a highly uncertain environment. These
assumptions must be identified and clearly understood, so that appropriate decisions can be made
if the assumption later proves invalid.
.11 Potential Value
When defining the future state, business analysts identify the potential value of the solution. The
potential value of the future state is the net benefit of the solution after operating costs are
accounted for. A change must result in greater value for the enterprise than would be achieved if no
action was taken. However, it is possible that the future state will represent a decrease in value
from the current state for some stakeholders or even for the enterprise as a whole. While
determining the future state, business analysts consider increased or decreased potential value
from:
• external opportunities revealed in assessing external influences,
• unknown strengths of new partners,
• new technologies or knowledge,
• potential loss of a competitor in the market, and
• mandated adoption of a change component
In addition to the potential value of the future state, this analysis should consider the acceptable
level of investment to reach the future state.

• Current State Description
• Organizational Strategy
6.2.6 Techniques
6.2.7 Stakeholders
• Customer
• End User
• Project Manager
• Regulator
• Sponsor
• Supplier
• Tester
6.2.8 Outputs
• 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 modiﬁed components of the enterprise and the potential value expected from the
future state.
• Potential Value: the value that may be realized by implementing the proposed future state.
• Balanced Scorecard
• Brainstorming
• Business Cases
• Decision Modelling
• Interviews
• Lessons Learned
• Mind Mapping
• Prototyping
• Scope Modelling
• SWOT Analysis
• Workshops

6.3 Assess Risk (page 120)
6.3.1 Purpose
• 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.
6.3.2 Description
• Assessing risks includes analyzing and managing them. Risks might be related to the current
state, a desired future state, a change itself, a change strategy, or any tasks being performed by
the enterprise. The risks are analyzed for the:
- possible consequences if the risk occurs,
- impact of those consequences,
- likelihood of the risk, and
- potential time frame when the risk might occur.
• A risk assessment can include choosing to accept a risk if either the effort required to modify the
risk or the level of risk outweighs the probable loss. If the risks are understood and the change
proceeds, then the risks can be managed to minimize their overall impact to value.
6.3.3 Inputs
• Elicitation Results (conﬁrmed)
• Inﬂuences (internal and external)
• Potential Value
• Requirements (prioritized)
6.3.4 Elements
.1 Unknowns
When assessing a risk, there will be uncertainty in the likelihood of it occurring, and the impact if it
does occur. Business analysts collaborate with stakeholders to assess risks based on current
understanding.
.2 Constraints, Assumptions, and Dependencies
Constraints, assumptions, and dependencies can be analyzed for risks and sometimes should be
managed as risks themselves. If the constraint, assumption, or dependency is related to an aspect
of a change, it can be restated as a risk by identifying the event or condition and consequences
that could occur because of the constraint, assumption, or dependency.
.3 Negative Impact to Value
Risks are expressed as conditions that increase the likelihood or severity of a negative impact to
value. Business analysts clearly identify and express each risk and estimate its likelihood and
impact to determine the level of risk. Business analysts estimate a total risk level from the

aggregated set of risks, indicating the overall potential impact for the risks being assessed. In
some cases overall risk level can be quantified in financial terms, or in an amount of time, effort, or
other measures.
.4 Risk Tolerance
How much uncertainty a stakeholder or an enterprise is willing to take on in exchange for potential
value is referred to as risk tolerance. In general, there are three broad ways of describing attitude
toward risk:
• Risk-aversion: An unwillingness to accept much uncertainty
• Neutrality: Some level of risk is acceptable
• Risk-seeking: Willingness to accept or even take on more risk in return for a higher potential
value
If there is low tolerance for risk, there may be more effort on avoidance, transfer or mitigation
strategies. If the tolerance for risk is high, more risks are likely to be accepted.
.5 Recommendation
Based on the analysis of risks, business analysts recommend a course of action. Business
analysts work with stakeholders to understand the overall risk level and their tolerance for risk. The
recommendation usually falls into one of the following categories:
• pursue the benefits of a change regardless of the risk,
• pursue the benefits of a change while investing in reducing risk (likelihood and/or impact),
• seek out ways to increase the benefits of a change to outweigh the risk,
• identify ways to manage and optimize opportunities, and
• do not pursue the benefits of a change.
• Business Policies
• Change Strategy
• Identified Risks
6.3.6 Techniques
• Brainstorming
• Business Cases
• Interviews
• Lessons Learned
• Mind Mapping
• Workshops

6.3.7 Stakeholders
• Project Manager
• Regulator
• Sponsor
• Supplier
• Tester
6.3.8 Outputs
• 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.
6.4 Define Change Strategy (page 124)
6.4.1 Purpose
• Develop and assess alternative approaches to the change, and then select the recommended
approach.
6.4.2 Description
• Developing a change strategy is simpler when the current state and the future state are already
defined because they provide some context for the change. The change strategy clearly
describes the nature of the change in terms of:
- context of the change,
- identified alternative change strategies,
- justification for why a particular change strategy is the best approach,
- investment and resources required to work toward the future state,
- how the enterprise will realize value after the solution is delivered,
- key stakeholders in the change, and
- transition states along the way.
• The appropriate representation of a change strategy depends on the perspective of the change
team and their stakeholders. The change strategy might be presented as part of a business
case, Statement of Work (SOW), an enterprise’s strategic plan, or in other formats.
6.4.3 Inputs

6.4.4 Elements
.1 Solution Scope
The solution is the outcome of a change that allows an enterprise to satisfy a need. Multiple
solution options might be evaluated and, as part of a change strategy, the best solution approach is
justified and selected. The solution scope defines the boundaries of the solution, and is described
in enough detail to enable stakeholders to understand which new capabilities the change will
deliver. The solution scope might be described in different ways, including the use of:
The solution scope can also include descriptions of out-of-scope solution components to provide
clarity.
.2 Gap Analysis
A gap analysis identifies the difference between current state and future state capabilities. To
perform gap analysis, both current state and future state should be defined. Gap analysis can help
identify the gaps that prevent the enterprise from meeting needs and achieving goals. It can be
used to determine if the enterprise can meet its needs using its existing structure, resources,
capabilities, and technology. The gaps will need to be addressed in the transition and future states.
.3 Enterprise Readiness Assessment
Business analysts analyze the enterprise to assess its capacity to make the change and to sustain
the change in the future state. The readiness assessment considers the enterprise’s capacity not
only to make the change, but to use and sustain the solution, and realize value from the solution.
.4 Change Strategy
A change strategy is a high-level plan of key activities and events that will be used to transform the
enterprise from the current state to the future state. Change strategies may be a singular initiative
composed of smaller changes which might be structured as a set or sequence of projects, or as
various continuous improvement efforts.
During the course of the development of a change strategy, several options are identified,
explored, and described in enough detail to determine which options are feasible. Alternatives can
be identified through brainstorming and consulting subject matter experts (SMEs). Sources of

ideas can include historical ideas, historical changes, other markets' strategies, and competitors'
approaches. The preferred change strategy should be selected considering:
• organizational readiness to make the change,
• major costs and investments needed to make the change,
• timelines to make the change,
• alignment to the business objectives,
• timelines for value realization, and
• opportunity costs of the change strategy.
Business analysts may develop a business case for each potential change strategy to support
decision making. The opportunity cost of each change strategy also needs to be considered. While
every change facilitated by business analysts is intended to increase value, some changes
decrease value in parts of an enterprise while increasing it in others.
.5 Transition States and Release Planning
In many cases, the future state will need to be achieved over time rather than through a single
change, meaning that the enterprise will have to operate in one or more transition states. Release
planning is concerned with determining which requirements to include in each release, phase, or
iteration of the change.
There are many factors that guide these decisions, such as the overall budget, deadlines or time
constraints, resource constraints, training schedules, and the ability of the business to absorb
changes within a deﬁned time frame.
• Design Option
• Solution Recommendations
6.4.6 Techniques
6.4.7 Stakeholders
• Customer
• Balanced Scorecard
• Brainstorming
• Business Cases
• Estimation
• Focus Group
• Interviews
• Lessons Learned
• Mind Mapping
• Scope Modelling
• SWOT Analysis
• Workshops

• End User
• Project Manager
• Regulator
• Sponsor
• Supplier
• Tester
6.4.8 Outputs
• 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.

Chapter 7: Requirements Analysis and Design Definition (page 133)
• The Requirements Analysis and Design Definition knowledge area 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
information, identify solution options that meet business needs, and estimate the potential
value that could be realized for each solution 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.
• One person’s designs may be another person’s requirements, and it may be either high-level or
very detailed based upon what is appropriate to those consuming the information.
• Business analysts analyze the potential value of both requirements and designs. In collaboration
with implementation subject matter experts, business analysts define solution options that can
be evaluated in order to recommend the best solution option that meets the need and brings the
most value. The following image illustrates the spectrum of value as business analysis activities
progress from delivering potential value to actual value.
The Requirements Analysis and Design Definition knowledge area includes the following tasks:
• Specify and Model Requirements: describes a set of requirements or designs in detail using
analytical techniques.
• Verify Requirements: 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.
• Validate Requirements: ensures that a set of requirements or designs delivers business value
and supports the organization's goals and objectives.
• Define Requirements Architecture: 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.
• Define Solution Options: identifies, explores and describes different possible ways of meeting
the need.
• Analyze Potential Value and Recommend Solution: 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.

7.1 Specify and Model Requirements (page 136)
7.1.1 Purpose
• Analyze, synthesize, and reﬁne elicitation results into requirements and designs.
7.1.2 Description
• Specify and Model Requirements describes the practices for analyzing elicitation results and
creating representations of those results. When the focus of the specifying and modelling activity

is on understanding the need, the outputs are referred to as requirements. When the focus of
the specifying and modelling activity is on a solution, the outputs are referred to as designs.
• In many IT environments, the word 'design' is used specifically for technical designs created by
software developers, data architects, and other implementation subject matter experts. All
business deliverables are referred to as 'requirements'.
7.1.3 Inputs
• Elicitation Results (any state)
7.1.4 Elements
.1 Model Requirements
A model is a descriptive and visual way to convey information to a specific audience in order to
support analysis, communication, and understanding; and sometimes used to confirm knowledge,
identify information gaps that the business analyst may have, and identify duplicate information.
Business analysts choose from one or more of the following modelling formats:
• Matrices: a matrix is used when the business analyst is modelling a requirement or set of
requirements that have a complex but uniform structure, which can be broken down into
elements that apply to every entry in the table. Matrices may be used for data dictionaries,
requirements traceability, or for gap analysis. Matrices are also used for prioritizing requirements
and recording other requirements attributes and metadata.
• Diagrams: a diagram is a visual, often pictorial, representation of a requirement or set of
requirements. A diagram is especially useful to depict complexity in a way that would be difficult
to do with words. Diagrams can also be used to define boundaries for business domains, to
categorize and create hierarchies of items, and to show components of objects such as data and
their relationships.
Model categories can include:
• People and Roles: models represent organizations, groups of people, roles, and their
relationships within an enterprise and to a solution. Techniques include Organizational Modelling,
Roles and Permissions Matrix and Stakeholder List, Map, or Personas.
• Rationale: models represent the ‘why’ of a change. Techniques include Decision Modelling,
Scope Modelling, Business Model Canvas, Root Cause Analysis, and Business Rules Analysis.
• Activity Flow: models represent a sequence of actions, events, or a course that may be taken.
Techniques include Process Modelling, Use Cases and Scenarios, and User Stories.
• Capability: models focus on features or functions of an enterprise or a solution. Techniques
include Business Capability Analysis, Functional Decomposition, and Prototyping.
• Data and Information: models represent the characteristics and the exchange of information
within an enterprise or a solution. Techniques include Data Dictionary, Data Flow Diagrams, Data
Modelling, Glossary, State Modelling, and Interface Analysis.  
.2 Analyze Requirements
Business analysis information is decomposed into components to further examine 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.
.3 Represent Requirements and Attributes
Requirements should be explicitly represented and should include enough detail such that they
exhibit the characteristics of requirements and designs quality. Various attributes can be specified
for each requirement or set of requirements. These attributes are selected when planning for
information management.
.4 Implement the Appropriate Levels of Abstraction
The level of abstraction of a requirement varies based on the type of requirement and audience for
the requirement. Not all stakeholders require or find value in the complete set of requirements and
models. It may be appropriate to produce different viewpoints of requirements to represent the
same need for different stakeholders.
• Modelling Notations/Standards
• Modelling Tools
• Requirements Life Cycle Management Tools
• Solution Scope
7.1.6 Techniques
7.1.7 Stakeholders
• Any Stakeholders
7.1.8 Outputs
• Requirements (specified and modelled): any combination of requirements and/or designs in
the form of text, matrices, and diagrams.
• Data Dictionary
• Data Flow Diagrams
• Data Modelling
• Decision Modelling
• Glossary
• Non-Functional Requirements Analysis
• Prototyping
• Roles and Permissions Matrix
• Scope Modelling
• Sequence Diagrams
• State Modelling
• User Stories

7.2 Verify Requirements (page 141)
7.2.1 Purpose
• Ensure that requirements and designs specifications and models meet quality standards and are
usable for the purpose they serve.
7.2.2 Description
• Verifying requirements ensures that the requirements and designs have been defined correctly.
Requirements verification determines that the requirements and designs are ready for validation,
and provides the information needed for further work to be performed.
• A high-quality specification is well written and easily understood by its intended audience. The
most important characteristic of quality requirements and designs is fitness for use. They must
meet the needs of stakeholders who will use them for a particular purpose. Quality is ultimately
determined by stakeholders.
7.2.3 Inputs
• Requirements (specified and modelled)
7.2.4 Elements
.1 Characteristics of Requirements and Designs Quality
A While quality is ultimately determined by the needs of the stakeholders who will use the
requirements or the designs, acceptable quality requirements exhibit many of the following
characteristics:
• Atomic: self-contained and capable of being understood independently
• Complete: enough to guide further work and at the appropriate level of detail
• Consistent: aligned with the identified needs of the stakeholders and not conflicting with other
requirements.
• Concise: contains no extraneous and unnecessary content.
• Feasible: reasonable and possible within the agreed-upon risk, schedule, and budget.
• Unambiguous: the requirement must be clearly stated to clarify whether a solution does or does
not meet the associated need.
• Testable: able to verify that the requirement or design has been fulfilled.
• Prioritized: ranked, grouped, or negotiated in terms of importance and value.
• Understandable: represented using common terminology of the audience
.2 Verification Activities
Verification activities are typically performed iteratively throughout the requirements analysis
process. Verification activities include:
• checking for compliance with organizational performance standards for business analysis,
• 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.
.3 Checklists
Checklists are used for quality control when verifying requirements and designs. Checklists may
include a standard set of quality elements that business analysts use to verify the requirements, or
they may be specifically developed to capture issues of concern. The purpose of a checklist is to
ensure that items determined to be important are included in the final requirements deliverables, or
that steps required for the verification process are followed.
• Requirements Life Cycle Management Tools
7.2.6 Techniques
7.2.7 Stakeholders
• All Stakeholders
7.2.8 Outputs
• Requirements (verified): a set of requirements or designs that is of sufficient quality to be used
as a basis for further work.
7.3 Validate Requirements (page 144)
7.3.1 Purpose
• Ensure that all requirements and designs align to the business requirements and support the
delivery of needed value.
7.3.2 Description
• Requirements validation is an ongoing process to ensure that stakeholder, solution, and
transition requirements align to the business requirements and that the designs satisfy the
requirements.
• Understanding what the desired future state looks like for stakeholders after their needs have
been met is valuable to business analysts when validating requirements. The overall goal of
implementing the requirements is to achieve the stakeholders' desired future state. In many
cases, stakeholders have different, conflicting needs and expectations that may be exposed
through the validation process.
• Item Tracking
• Reviews

7.3.3 Inputs
• Requirements (specified and modelled)
7.3.4 Elements
.1 Identify Assumptions
If an organization is launching an unprecedented product or service, it may be necessary to make
assumptions about customer or stakeholder response, as there are no similar previous
experiences on which to rely. In other cases, it may be difficult or impossible to prove that a
particular problem derives from an identified root cause. Stakeholders may have assumed that
certain benefits will result from the implementation of a requirement. These assumptions are
identified and defined so that associated risks can be managed.
.2 Define Measurable Evaluation Criteria
While the expected benefits are defined as part of the future state, the specific measurement
criteria and evaluation process may not have been included. Business analysts define the
evaluation criteria that will be used to evaluate how successful the change has been after the
solution is implemented. Baseline metrics or target metrics might be established based on the
current state.
.3 Evaluate Alignment with Solution Scope
A requirement can be of benefit to a stakeholder and still not be a desirable part of a solution.
When requirements do not align, either the future state must be re-evaluated and the solution
scope changed, or the requirement removed from the solution scope.
If a design cannot be validated to support a requirement, there might be a missing or
misunderstood requirement, or the design must change.
• Potential Value
• Solution Scope
7.3.6 Techniques
7.3.7 Stakeholders
• All Stakeholders
• Item Tracking
• Reviews

7.3.8 Outputs
• 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.
7.4 Define Requirements Architecture (page 148)
7.4.1 Purpose
• Ensure that the requirements collectively support one another to fully achieve the objectives.
7.4.2 Description
• Requirements architecture is the structure of all of the requirements of a change. A requirements
architecture fits the individual models and specifications together to ensure that all of the
requirements form a single whole that supports the overall business objectives and produces a
useful outcome for stakeholders. Business analysts use a requirements architecture to:
- understand which models are appropriate for the domain, solution scope, and audience,
- organize requirements into structures relevant to different stakeholders,
- illustrate how requirements and models interact with and relate to each other, and show how
the parts fit together into a meaningful whole,
- ensure the requirements work together to achieve the overall objectives, and
- make trade-off decisions about requirements while considering the overall objectives.
• Requirements architecture is not intended to demonstrate traceability, but rather to show how
elements work in harmony with one another to support the business requirements, and to
structure them in various ways to align the viewpoints of different stakeholders. Traceability is
often used as the mechanism to represent and manage these relationships. Traceability proves
that every requirement links back to an objective and shows how an objective was met.
Traceability does not prove the solution is a cohesive whole that will work.
7.4.3 Inputs
• Requirements (any state)
• Solution Scope
7.4.4 Elements
.1 Requirements Viewpoints and Views
A viewpoint is a set of conventions that define how requirements will be represented, how these
representations will be organized, and how they will be related. Viewpoints provide templates for
addressing the concerns of particular stakeholder groups. 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.
No single viewpoint alone can form an entire architecture. Trying to put too much information into
any one viewpoint will make it too complex and degrade its purpose. Examples of viewpoints
include - Business process models, Data models and information, User interactions including use
cases and/or user experience, Audit and security, and Business models.
The actual requirements and designs for a particular solution from a chosen viewpoint are referred
to as a view. A collection of views makes up the requirements architecture for a specific solution.
Business analysts align, coordinate, and structure requirements into meaningful views; and this set
of coordinated, complementary views provides a basis for assessing the completeness and
coherence of the requirements.
In short, the viewpoints tell business analysts what information they should provide for each
stakeholder group to address their concerns, while views describe the actual requirements and
designs that are produced.
.2 Template Architectures
An architectural framework is a collection of viewpoints that is standard across an industry, sector,
or organization. Business analysts can treat frameworks as predefined templates to start from in
defining their architecture. Similarly, the framework can be populated with domain-specific
information to form a collection of views.
.3 Completeness
An architecture helps ensure that a set of requirements is complete. The entire set of requirements
should be able to be understood by the audience in way that it can be determined that the set is
cohesive and tells a full story. Structuring requirements according to different viewpoints helps
ensure this completeness. Iterations of elicitation, specification, and analysis activities can help
identify gaps.
.4 Relate and Verify Requirements Relationships
Requirements may be related to each other in several ways when defining the requirements
architecture. Business analysts examine and analyze the requirements to define the relationships
between them. Business analysts examine each relationship to ensure that the relationships satisfy
the following quality criteria:
• Defined: there is a relationship and the type of the relationship is described.
• Necessary: the relationship is necessary for understanding the requirements holistically.
• Correct: the elements do have the relationship described.
• Unambiguous: there are no relationships that link elements in two different and conflicting ways.
• Consistent: relationships are described in the same way, using the same set of standard
descriptions as defined in the viewpoints.
.5 Business Analysis Information Architecture
The information architecture is a component of the requirements architecture because it describes
how all of the business analysis information for a change relates. It defines relationships for types

of information such as requirements, designs, types of models, and elicitation results.
Understanding this type of information structure helps to ensure that the full set of requirements is
complete by verifying the relationships are complete.
• Architecture Management Software
• Methodologies and Frameworks
7.4.6 Techniques
7.4.7 Stakeholders
• Project Manager
• Sponsor
• Tester
• Any Stakeholders
7.4.8 Outputs
• Requirements Architecture: the requirements and the interrelationships among them, as well
as any contextual information that is recorded.
7.5 Define Design Options (page 152)
7.5.1 Purpose
• 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.
7.5.2 Description
• When designing a solution, there may be one or more design options identified. Each design
option represents a way to satisfy a set of requirements. Design options exist at a lower level
than the change strategy, and are tactical rather than strategic. As a solution is developed,
tactical trade-offs may need to be made among design alternatives.
• Business analysts must assess the effect these trade-offs will have on the delivery of value to
stakeholders. As initiatives progress and requirements evolve, design options evolve as well.
• Data Modelling
• Interviews
• Scope Modelling
• Workshops

7.5.3 Inputs
• Change Strategy
• Requirements (validated, prioritized)
7.5.4 Elements
.1 Define Solution Approaches
The solution approach describes whether solution components will be created or purchased, or
some combination of both. Business analysts assess the merits of the solution approaches for
each design option. Solution approaches include:
• Create: solution components are assembled, constructed, or developed by experts as a direct
response to a set of requirements.
• Purchase: solution components are selected from a set of offerings that fulfill the requirements.
• Combination of both: Design options may include a combination of both creation and purchase
of components.
The requirements and the design options have enough detail to make a decision about which
solution to construct or purchase.
.2 Identify Improvement Opportunities
When proposing design options, a number of opportunities to improve the operation of the
business may occur and are compared. Some common examples of opportunities include:
• Increase Efficiencies: automate or simplify the work people perform by re- engineering or
sharing processes, changing responsibilities, or outsourcing.
• Improve Access to Information: provide greater amounts of information to staff who interface
directly or indirectly with customers, thereby reducing the need for specialists.
• Identify Additional Capabilities: highlight capabilities that have the potential to provide future
value and can be supported by the solution.
.3 Requirements Allocation
Requirements allocation is the process of assigning requirements to solution components and
releases to best achieve the objectives. Allocation is supported by assessing the trade-offs
between alternatives in order to maximize benefits and minimize costs. The objective of allocation
is to maximize that value.
Requirements may be allocated between organizational units, job functions, solution components,
or releases of a solution. Requirements allocation typically begins when a solution approach has
been determined, and continues until all valid requirements are allocated and the solution is
implemented.
.4 Describe Design Options
Design options are investigated and developed while considering the desired future state, and in
order to ensure the design option is valid. Solution performance measures are defined for each

design option. A design option usually consists of many design components, each described by a
design element. 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.
• Existing Solutions
• Requirements (traced)
• Solution Scope
7.5.6 Techniques
7.5.7 Stakeholders
• Project Manager
• Supplier
7.5.8 Outputs
• 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 deﬁne the option.
7.6 Analyze Potential Value and Recommend Solution (page 157)
7.6.1 Purpose
• Estimate the potential value for each design option and to establish which one is most
appropriate to meet the enterprise’s requirements.
• Brainstorming
• Interviews
• Lessons Learned
• Mind Mapping
• Workshops

7.6.2 Description
• Describes how to estimate and model the potential value delivered by a set of requirements,
designs, or design options. Potential value is analyzed many times over the course of a change.
This analysis may be a planned event, or it may be triggered by a modification to the context or
scope of the change.
• The analysis of potential value includes consideration that there is uncertainty in the estimates.
Value can be described in terms of finance, reputation, or even impact on the marketplace. Any
change may include a mix of increases and decreases in value.
• Design options are evaluated by comparing the potential value of each option to the other
options. Depending on the reasons for the change, there may be no best option to recommend,
or there may be a clear best choice.
7.6.3 Inputs
• Potential Value
• Design Options
7.6.4 Elements
.1 Expected Benefits
Expected benefits describe the positive value that a solution is intended to deliver to stakeholders.
Value can include benefits, reduced risk, compliance with business policies and regulations, an
improved user experience, or any other positive outcome. The total expected benefit is the net
benefit of all the requirements a particular design option addresses. Benefits are often realized
over a period of time.
.2 Expected Costs
Expected costs include any potential negative value associated with a solution, including the cost
to acquire the solution, any negative effects it may have on stakeholders, and the cost to maintain
it over time. Expected costs can include - timeline, maintenance costs, effort, physical resources,
operating costs, information resources, purchase and/or implementation costs, and human
resources.
Expected costs for a design option consider the cumulative costs of the design components.
Business analysts also consider opportunity cost when estimating the expected cost of a change.
.3 Determine Value
Potential value is uncertain value. The potential value of a solution to a stakeholder is based on the
benefits delivered by that solution and the associated costs. Value can be positive (if the benefits
exceed the costs) or negative (if the costs exceed the benefits).
Business analysts consider potential value from the points of view of stakeholders. Value to the
enterprise is almost always more heavily weighted than value for any individual stakeholder
groups. Many changes are proposed in terms of intangible or uncertain benefits, while costs are
described as tangible, absolute, and might grow.

.4 Assess Design Options and Recommend Solution
Each design option is assessed based on the potential value it is expected to deliver. At any point
in analyzing the design options, it may become necessary to re-evaluate the initial allocation of
design elements between components. The reasons for re-evaluation include better understanding
of the cost to implement each component and to determine which allocations have the best cost-to-
benefit ratio. There are several factors to take into consideration:
• Available Resources: there may be limitations regarding the amount of requirements that can
be implemented based on the allocated resources. In some instances, a business case can be
developed to justify additional investment.
• Constraints on the Solution: regulatory requirements or business decisions may require that
certain requirements be handled manually or automatically, or that certain requirements be
prioritized above all others.
• Dependencies between Requirements: some capabilities may in and of themselves provide
limited value to the organization, but need to be delivered in order to support other high-value
requirements
Other considerations may include relationships with proposed vendors, dependencies on other
initiatives, corporate culture, and sufficient cash flow for investment. Business analysts recommend
the option or options deemed to be the most valuable solution to address the need. It is possible
that none of the design options are worthwhile and the best recommendation is to do nothing.
• Solution Scope
7.6.6 Techniques
7.6.7 Stakeholders
• Customer
• End User
• Backlog Management
• Brainstorming
• Business Cases
• Estimation
• Focus Groups
• Interviews
• SWOT Analysis
• Workshops

• Project Manager
• Regulator
• Sponsor
7.6.8 Outputs
• Solution Recommendation: identiﬁes the suggested, most appropriate solution based on an
evaluation of all deﬁned design options. The recommended solution should maximize the value
provided to the enterprise.

Chapter 8: Solution Evaluation (page 163)
• The Solution Evaluation knowledge area describes the tasks that business analysts perform to
assess the performance of and value delivered by a solution in use by the enterprise, and to
recommend removal of barriers or constraints that prevent the full realization of the value.
• An important distinction between the Solution Evaluation knowledge area and other knowledge
areas is the existence of an actual solution, which may only be a partial solution, but the solution
or solution component has already been implemented and is operating in some form.
• Solution Evaluation tasks can be performed on solution components in varying stages of
development:
- Prototypes or Proofs of Concept: working but limited versions of a solution that
demonstrate value.
- Pilot or Beta releases: limited implementations or versions of a solution used in order to
work through problems and understand how well it actually delivers value before fully
releasing the solution.
- Operational releases: full versions of a partial or completed solution used to achieve
business objectives, execute a process, or fulfill a desired outcome.
• Solution Evaluation describes tasks that analyze the actual value being delivered, identifies
limitations which may be preventing value from being realized, and makes recommendations to
increase the value of the solution. Solution Evaluation generally focuses on a component of an
enterprise rather than the entire enterprise. The following image illustrates the spectrum of value
as business analysis activities progress from delivering potential value to actual value.
The Solution Evaluation knowledge area includes the following tasks:
• Measure Solution Performance: determines the most appropriate way to assess the
performance of a solution, its alignment with enterprise goals and objectives.
• Analyze Performance Measures: examines the performance information of a solution in order
to understand the value it delivers, and determines whether it is meeting current business needs.
• Assess Solution Limitations: investigates issues within the scope of a solution that may
prevent it from meeting current business needs.
• Assess Enterprise Limitations: 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.
• Recommend Actions to Increase Solution Value: identifies and defines actions the enterprise
can take to increase the value that can be delivered by a solution.  

8.1 Measure Solution Performance (page 166)
8.1.1 Purpose
• Deﬁne performance measures and use the data collected to evaluate the effectiveness of a
solution in relation to the value it brings.
8.1.2 Description
• Performance measures determine the value of a newly deployed or existing solution. The
measures used depend on the solution itself, the context, and how the organization deﬁnes

value. When solutions do not have built-in performance measures, the business analyst works
with stakeholders to determine and collect the measures that will best reflect the performance of
a solution. Performance may be assessed through key performance indicators (KPIs) aligned
with enterprise measures, goals and objectives for a project, process performance targets, or
tests for a software application.
8.1.3 Inputs
• Implemented Solution (external)
8.1.4 Elements
.1 Define Solution Performance Measures
Business analysts ensure that any existing performance measures are accurate, relevant and elicit
any additional performance measures identified by stakeholders. Business goals, objectives, and
business processes are common sources of measures. Performance measures may be influenced
or imposed by third parties such as solution vendors, government bodies, or other regulatory
organizations.
Solution performance measures may be quantitative, qualitative, or both, depending on the value
being measured.
• Quantitative Measures: are numerical, countable, or finite, usually involving amounts,
quantities, or rates.
• Qualitative Measures: are subjective and can include attitudes, perceptions, and any other
subjective response. Customers, users, and others involved in the operation of a solution have
perceptions of how well the solution is meeting the need.
.2 Validate Performance Measures
Validating performance measures helps to ensure that the assessment of solution performance is
useful. Business analysts validate the performance measures and any influencing criteria with
stakeholders. Specific performance measures should align with any higher-level measures that
exist within the context affecting the solution. Decisions about which measures are used to
evaluate solution performance often reside with the sponsor, but may be made by any stakeholder
with decision-making authority.
.3 Collect Performance Measures
When defining performance measures, business analysts may employ basic statistical sampling
concepts. When collecting performance measures, business analysts consider:
• Volume or Sample Size: Smaller sample size might skew the results and lead to inaccurate
conclusions. Larger sample sizes may be more desirable, but may not be practical to obtain.
• Frequency and Timing: the frequency and timing with which measurements are taken may
have an effect on the outcome.
• Currency: measurements taken more recently tend to be more representative than older data.
Using qualitative measures, business analysts can facilitate discussions to estimate the value
realized by a solution.

• Change Strategy
• Requirements (validated)
• Solution Scope
8.1.6 Techniques
8.1.7 Stakeholders
• Customer
• End User
• Project Manager
• Regulator
• Sponsor
8.1.8 Outputs
• Solution Performance Measures: measures that provide information on how well the solution
is performing or potentially could perform.
8.2 Analyze Performance Measures (page 170)
8.2.1 Purpose
• Provide insights into the performance of a solution in relation to the value it brings.
8.2.2 Description
• Performance measures themselves rarely trigger a decision about the value of a solution. In
order to meaningfully analyze performance measures, business analysts require a thorough
understanding of the potential value that stakeholders hope to achieve with the solution. To
assist in the analysis, variables such as the goals and objectives of the enterprise, key
performance indicators (KPIs), the level of risk of the solution, the risk tolerance of both
stakeholders and the enterprise, and other stated targets are considered.
8.2.3 Inputs
• Potential Value (6.2)
• Business Cases
• Data Mining
• Focus Groups
• Non-Functional Requirements Analysis
• Observation
• Prototyping

• Solution Performance Measures (8.1)
8.2.4 Elements
.1 Solution Performance versus Desired Value
Business analysts examine the measures previously collected in order to assess their ability to
help stakeholders understand the solution’s value. If the measures are not sufficient to help
stakeholders determine solution value, business analysts either collect more measurements or
treat the lack of measures as a solution risk.
.2 Risks
Performance measures may uncover new risks to solution performance and to the enterprise.
These risks are identified and managed like any other risks.
.3 Trends
When analyzing performance data, business analysts consider the time period when the data was
collected to guard against anomalies and skewed trends. A large enough sample size over a
sufficient time period will provide an accurate depiction of solution performance on which to make
decisions and guard against false signals brought about by incomplete data. Any pronounced and
repeated trends, such as a noticeable increase in errors at certain times or a change in process
speed when volume is increased, are noted.
.4 Accuracy
Business analysts test and analyze the data collected by the performance measures to ensure
their accuracy. To be considered accurate and reliable, the results of performance measures
should be reproducible and repeatable.
.5 Performance Variance
The difference between expected and actual performance represents a variance that is considered
when analyzing solution performance. Root cause analysis may be necessary to determine the
underlying causes of significant variances within a solution.
• Change Strategy
• Solution Scope
8.2.6 Techniques
• Data Mining
• Interviews
• Observation

8.2.7 Stakeholders
• Project Manager
• Sponsor
8.2.8 Outputs
• Solution Performance Analysis: results of the analysis of measurements collected and
recommendations to solve performance gaps and leverage opportunities to improve value.
8.3 Assess Solution Limitations (page 173)
8.3.1 Purpose
• Determine the factors internal to the solution that restrict the full realization of value.
8.3.2 Description
• Identifies the root causes for under-performing and ineffective solutions and solution
components. This task focuses on the assessment of those factors internal to the solution if the
solution has not met its potential value. This assessment may be performed at any point during
the solution life cycle. It may occur on a solution component during its development, on a
completed solution prior to full implementation, or on an existing solution that is currently
working within an organization.
8.3.3 Inputs
• Implemented Solution (external)
• Solution Performance Analysis (8.2)
8.3.4 Elements
.1 Identify Internal Solution Component Dependencies
Solutions often have internal dependencies that limit the performance of the entire solution to the
performance of the least effective component. Business analysts identify solution components
which have dependencies on other solution components, and then determine if there is anything
about those dependencies or other components that limit solution performance and value
realization.
.2 Investigate Solution Problems
Business analysts identify problems in a solution or solution component by examining instances
where the outputs from the solution are below an acceptable level of quality or where the potential
value is not being realized. Problems may be indicated by an inability to meet a stated goal,
objective, or requirement, or may be a failure to realize a benefit that was projected during the
tasks Define Change Strategy or Recommend Actions to Increase Solution Value.

.3 Impact Assessment
Business analysts review identified problems in order to assess the effect they may have on the
operation of the organization or the ability of the solution to deliver its potential value. This requires
determining the severity of the problem, the probability of the re-occurrence of the problem, the
impact on the business operations, and the capacity of the business to absorb the impact.
Business analysts identify which problems must be resolved, which can be mitigated through other
activities or approaches, and which can be accepted.
In addition to identified problems, business analysts assess risks to the solution and potential
limitations of the solution. This risk assessment is specific to the solution and its limitations.
• Change Strategy
• Solution Scope
8.3.6 Techniques
8.3.7 Stakeholders
• Customer
• End User
• Regulator
• Sponsor
• Tester
8.3.8 Outputs
• Solution Limitation: a description of the current limitations of the solution including constraints
and defects.
8.4 Assess Enterprise Limitations (page 177)
8.4.1 Purpose
• Determine how factors external to the solution are restricting value realization.
• Data Mining
• Interviews
• Item Tracking
• Lessons Learned

8.4.2 Description
• Solutions may operate across various organizations within an enterprise, and therefore have
many interactions and interdependencies. Solutions may also depend on environmental factors
that are external to the enterprise. Enterprise limitations may include factors such as culture,
operations, technical components, stakeholder interests, or reporting structures.
• Assessing enterprise limitations identifies root causes and describes how enterprise factors limit
value realization. This assessment may be performed at any point during the solution life cycle.
It may occur on a solution component during its development or on a completed solution prior to
full implementation, or on an existing solution that is currently working within an organization.
8.4.3 Inputs
• Current State Description (6.1)
• Implemented (or Constructed) Solution (external)
• Solution Performance Analysis (8.2)
8.4.4 Elements
.1 Enterprise Culture Assessment
Enterprise culture is defined as the deeply rooted beliefs, values, and norms shared by the
members of an enterprise. While these beliefs and values may not be directly visible, they drive the
actions taken by an enterprise. 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.
The enterprise culture assessment evaluates the extent to which the culture can accept a solution.
.2 Stakeholder Impact Analysis
A stakeholder impact analysis provides insight into how the solution affects a particular stakeholder
group. When conducting stakeholder impact analysis, business analysts consider:
• Functions: the processes in which the stakeholder uses the solution, which include inputs a
stakeholder provides into the process, how the stakeholder uses the solution to execute the
process, and what outputs the stakeholder receives from the process.
• Locations: the geographic locations of the stakeholders interacting with the solution. If the
stakeholders are in disparate locations, it may impact their use of the solution and the ability to
realize the value of the solution.
• Concerns: the issues, risks, and overall concerns the stakeholders have with the solution. This
may include the use of the solution, the perceptions of the value of the solution, and the impact
the solution has on a stakeholder’s ability to perform necessary functions.  

.3 Organizational Structure Changes
The use of a solution and the ability to adopt a change can be enabled or blocked by formal and
informal relationships among stakeholders. The reporting structure may be too complex or too
simple to allow a solution to perform effectively. Assessing if the organizational hierarchy supports
the solution is a key activity. On occasion, informal relationships within an organization, whether
alliances, friendships, or matrix-reporting, impact the ability of a solution to deliver potential value.
.4 Operational Assessment
The operational assessment is performed to determine if an enterprise is able to adapt to or
effectively use a solution. This identifies which processes and tools within the enterprise are
adequately equipped to benefit from the solution, and if sufficient and appropriate assets are in
place to support it. 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.
• Change Strategy
• Solution Scope
8.4.6 Techniques
8.4.7 Stakeholders
• Customer
• End User
• Regulator
• Sponsor
8.4.8 Outputs
• Enterprise Limitation: a description of the current limitations of the enterprise including how the
solution performance is impacting the enterprise.
• Brainstorming
• Data Mining
• Interviews
• Item Tracking
• Lessons Learned
• Observation
• Roles and Permission Matrix
• SWOT Analysis
• Workshops

8.5 Recommend Actions to Increase Solution Value (page 182)
8.5.1 Purpose
• Understand the factors that create differences between potential value and actual value, and to
recommend a course of action to align them.
8.5.2 Description
• The task Recommend Actions to Increase Solution Value (p. 182), focuses on understanding the
aggregate of the performed assessments and identifying alternatives and actions to improve
solution performance and increase value realization.
• Recommendations generally identify how a solution should be replaced, retired, or enhanced.
They may also consider long-term effects and contributions of the solution to stakeholders.
8.5.3 Inputs
• Enterprise Limitation (8.4)
• Solution Limitation (8.3)
8.5.4 Elements
.1 Adjust Solution Performance Measures
In some cases, the performance of the solution is considered acceptable but may not support the
fulfillment of business goals and objectives. An analysis effort to identify and define more
appropriate measures may be required.
.2 Recommendations
While recommendations often describe ways to increase solution performance, this is not always
the case. Depending on the reason for lower than expected performance, it may be reasonable to
take no action, adjust factors that are external to the solution, or reset expectations for the solution.
Some common examples of recommendations that a business analyst may make include:
• Do Nothing: is usually recommended when the value of a change is low relative to the effort
required to make the change, or when the risks of change significantly outweigh the risks of
remaining in the current state.
• Organizational Change: is a process for managing attitudes about, perceptions of, and
participation in the change related to the solution. Organizational change management generally
refers to a process and set of tools for managing change at an organizational level. Possible
recommendations that relate to organizational change include:
- automating or simplifying the work people perform.
- improving access to information.
• Reduce Complexity of Interfaces: interfaces are needed whenever work is transferred between
systems or between people. Reducing their complexity can improve understanding.
• Eliminate Redundancy: different stakeholder groups may have common needs that can be met
with a single solution, reducing the cost of implementation.
• Avoid Waste: the aim of avoiding waste is to completely remove those activities that do not add
value and minimize those activities that do not contribute to the final product directly.

• Identify Additional Capabilities: solution options may offer capabilities to the organization
above and beyond those identiﬁed in the requirements. In many cases, these capabilities are not
of immediate value to the organization but have the potential to provide future value.
• Retire the Solution: it may be necessary to consider the replacement of a solution or solution
component. This may occur because technology has reached the end of its life, services are
being insourced or outsourced, or the solution is not fulﬁlling the goals for which it was created.
• Some additional factors that may impact the decision regarding the replacement or retirement of
a solution include:
- ongoing cost versus initial investment
- opportunity cost
- necessity
- sunk cost
• Solution Scope
8.5.6 Techniques
8.5.7 Stakeholders
• Customer
• End User
• Regulator
• Sponsor
8.5.8 Outputs
• Recommended Actions: recommendation of what should be done to improve the value of the
solution within the enterprise.
• Data Mining
• Focus Group
• Prioritization

Chapter 9: Solution Evaluation (page 187)
• The Underlying Competencies chapter provides a description of the behaviours, characteristics,
knowledge, and personal qualities that support the practice of business analysis.
• These competencies are grouped into six categories:
- Analytical Thinking and Problem Solving (p. 188),
- Behavioural Characteristics (p. 194),
- Business Knowledge (p. 199),
- Communication Skills (p. 203),
- Interaction Skills (p. 207), and
- Tools and Technology (p. 211).
• Each underlying competency is defined with a purpose, definition, and effectiveness measures.
9.1 Analytical Thinking and Problem Solving (page 188)
Analytical thinking and problem solving skills are required for business analysts to analyze
problems and opportunities effectively, identify which changes may deliver the most value, and
work with stakeholders to understand the impact of those changes.
Business analysts use analytical thinking by rapidly assimilating various types of information (for
example, diagrams, stakeholder concerns, customer feedback, schematics, user guides, and
spreadsheets), and identifying which are relevant.
Possessing a sound understanding of the analytical thinking and problem solving core
competencies allows business analysts to identify the best ways to present information to their
stakeholders. Analytical Thinking and Problem Solving core competencies include -
Creative Thinking, Decision Making, Learning, Problem Solving, Systems Thinking, Conceptual
Thinking, and Visual Thinking.
9.1.1 Creative Thinking
.1 Purpose & .2 Definition
Thinking creatively and helping others to apply creative thinking helps business analysts to be
effective in generating new ideas, approaches, and alternatives to problem solving and
opportunities. Creative thinking involves generating new ideas and concepts as well as finding new
or different associations between existing ideas and concepts. Creative thinking may involve
combining, changing, and reapplying existing concepts or ideas.
.3 Effective Measures
Measures of effective creative thinking include:
• generating and productively considering new ideas,
• exploring concepts and ideas that are new,
• exploring changes to existing concepts and ideas,
• generating creativity for self and others, and
• applying new ideas to resolve existing problems.

9.1.2 Decision Making
Business analysts must be effective in understanding the criteria involved in making a decision,
and in assisting others to make better decisions. Determining this involves gathering the
information that is relevant to the decision, analyzing the relevant information, making comparisons
and trade-offs between similar and dissimilar options, and identifying the most desirable option.
Measures of effective decision making include:
• the appropriate stakeholders are represented in the decision-making process,
• stakeholders understand the decision-making process and the rationale behind the decision,
• the pros and cons of all available options are clearly communicated to stakeholders,
• the decision reduces or eliminates uncertainty, and any remaining uncertainty is accepted,
• the decision made addresses the need or the opportunity at hand and is in the best interest of all
stakeholders,
• stakeholders understand all the conditions, environment, and measures in which the decision will
be made, and
• a decision is made.
9.1.3 Learning
The ability to quickly absorb new and different types of information and also modify and adapt
existing knowledge allows business analysts to work effectively in rapidly changing and evolving
environments. Learning is the process of gaining knowledge or skills. Learning techniques to
consider include:
• Visual: learning through the presentation of pictures, photographs, diagrams, models, and
videos.
• Auditory: learning through verbal and written language and text.
• Kinesthetic: learning by doing.
Measures of effective learning include:
• understanding that learning is a process for all stakeholders,
• learning the concepts presented and then demonstrating an understanding of them,
• demonstrating the ability to apply concepts to new areas or relationships,
• rapidly absorbing new facts, ideas, concepts, and opinions, and
• effectively presenting new facts, ideas, concepts, and opinions to others.
9.1.5 Systems Thinking
Understanding how the people, processes, and technology within an organization interact allows
business analysts to understand the enterprise from a holistic point of view. Systems theory and

systems thinking suggest that a system as a whole has properties, behaviours, and characteristics
that emerge from the interaction of the components of that system.
Measures of effective systems thinking include:
• communicating how a change to a component affects the system as a whole,
• communicating how a change to a system affects the environment it is in, and
• communicating how systems adapt to internal and/or external pressures and changes.
9.1.6 Conceptual Thinking
Conceptual thinking is about understanding the linkage between contexts, solutions, needs,
changes, stakeholders, and value abstractly and in the big picture. It involves understanding and
connecting information and patterns that may not be obviously related. Conceptual thinking
involves understanding where details fit into a larger context.
Measures of effective conceptual thinking include:
• connecting disparate information and acting to better understand the relationship,
• confirming the confidence and understanding of the concept being communicated with
stakeholders,
• formulating abstract concepts using a combination of information and uncertainty, and
• drawing on past experiences to understand the situation.
9.1.7 Visual Thinking
Visual thinking skills allow business analysts to create graphical representations of the concepts or
systems being discussed. The goal of these graphical representations is to allow stakeholders to
easily understand the concepts being presented, and then provide input. Visual thinking requires
that the analyst make abstractions and then find suitable graphic devices to represent them.
Measures of effective visual thinking include:
• complex information is communicated in a visual model which is understandable by
stakeholders,
• visuals allow for comparisons, pattern finding, and idea mapping with participants,
• productivity increases due to increased learning, quick memory, and follow through from effective
visuals,
• stakeholders are engaged at a deeper level than with text alone, and
• stakeholders understand critical information which may have been missed if presented in textual
content alone.

9.2 Behavioural Characteristics (page 194)
Behavioural characteristics exist at the core of every business analyst’s skill set. Each of the
behavioural characteristics described here can impact the outcome of the practitioner's efforts. The
core competencies of behavioural characteristics focus on the skills and behaviours that allow a
business analyst to gain the trust and respect of stakeholders.
Business analysts do this by consistently acting in an ethical manner, completing tasks on time and
to expectations, efficiently delivering quality results, and demonstrating adaptability to changing
needs and circumstances. Behavioural Characteristics core competencies include -
Ethics, Personal Accountability, Trustworthiness, Organization and Time Management, and
Adaptability
9.2.1 Ethics
Behaving ethically and thinking of ethical impacts on others allows business analysts to earn the
respect of the stakeholders. Ethics require an understanding and focus on fairness, consideration,
and moral behaviour through business analysis activities and relationships. Ethical behaviour
includes consideration of the impact that a proposed solution can have on all stakeholder groups
and working to ensure that those groups are treated as fairly as possible.
Measures of effective ethical behaviour include:
• prompt identification and resolution of ethical dilemmas,
• feedback from stakeholders confirming they feel decisions and actions are transparent and fair,
• decisions made with consideration of the interests of all stakeholders,
• reasoning for decisions that is clearly articulated and understood,
• full and prompt disclosure of potential conflicts of interest, and
• honesty regarding one's abilities, the performance of one's work, and accepting responsibility for
failures or errors.
9.2.2 Personal Accountability
Personal accountability is important for a business analyst because it ensures business analysis
tasks are completed on time and to the expectations of colleagues and stakeholders. It includes
effectively planning business analysis work to achieve targets and goals, and ensuring that value
delivered is aligned with business needs.
Measures of effective personal accountability include:
• work effort is planned and easily articulated to others,
• work is completed as planned or re-planned with sufficient reasoning and lead time,
• status of both planned and unplanned work is known,
• stakeholders feel that work is organized,

• risks and issues are identified and appropriately acted on,
• completely traceable requirements are delivered on time, and stakeholder needs are met.
9.2.3 Trustworthiness
Earning the trust of stakeholders helps business analysts elicit business analysis information
around sensitive issues and enables them to help stakeholders have confidence that their
recommendations will be evaluated properly and fairly. Several factors can contribute to being
considered trustworthy like - intentionally and consistently completing tasks and deliverables on
time and within budget, presenting a consistent attitude of confidence, acting in an honest and
straightforward manner, addressing conflict and concerns immediately, and maintaining a
consistent schedule over a long period of time.
Measures of effective trustworthiness include:
• stakeholders involve the business analyst in discussions and decision making,
• stakeholders bring issues and concerns to the business analyst,
• stakeholders are willing to discuss difficult or controversial topics with the business analyst,
• stakeholders do not blame the business analyst when problems occur,
• stakeholders respect the business analyst's ideas and referrals, and
• stakeholders respond to the business analyst's referrals with positive feedback.
9.2.4 Organization and Time Management
Organization and time management skills help business analysts perform tasks effectively and use
work time efficiently. It involves the ability to prioritize tasks, perform them efficiently, and manage
time effectively. Techniques of organization include establishing short- and long-term goals, action
plans, prioritizing tasks, and utilizing a checklist. Techniques for effective time management include
establishing time limits on non-critical tasks, focusing more time on high risk and priority tasks,
setting aside focus time, and managing potential interruptions.
Measures of effective organization and time management include:
• the ability to produce deliverables in a timely manner,
• stakeholders feel that the business analyst focuses on the correct tasks at the right time,
• schedule of work effort and deadlines is managed and communicated to stakeholders,
• stakeholders feel their time in meetings and in reading communications is well spent,
• complete preparation for meetings, interviews, and requirements workshops,
• relevant business analysis information is captured, organized, and documented,
• adherence to the project schedule and the meeting of deadlines,
• provides accurate, thorough, and concise information in a logical manner which is understood by
stakeholders, and
• maintains up-to-date information on the status of each work item and all outstanding work.

9.2.5 Adaptability
Business analysts frequently work in rapidly changing environments and with a variety of
stakeholders. They adjust their behavioural style and method of approach to increase their
effectiveness when interacting with different stakeholders, organizations, and situations.
Adaptability is the ability to change techniques, style, methods, and approach to changing
situations and context.
Measures of effective adaptability include:
• demonstrating the courage to act differently from others,
• adapting to changing conditions and environments,
valuing and considering other points of view and approaches,
demonstrating a positive attitude in the face of ambiguity and change,
demonstrating a willingness to learn new methods, procedures, or techniques in order to
accomplish goals and objectives,
• changing behaviour to perform effectively under changing or unclear conditions,
• acquiring and applying new information and skills to address new challenges,
• acceptance of having changes made to tasks, roles and project assignments as organizational
realities change,
• altering interpersonal style to highly diverse individuals and groups in a range of situations, and
• evaluating what worked, what did not, and what could be done differently next time.
9.3 Business Knowledge (page 199)
Business knowledge is required for the business analyst to perform effectively within their
business, industry, organization, solution, and methodology. Business knowledge enables the
business analyst to better understand the overarching concepts that govern the structure, beneﬁts,
and value of the situation as it relates to a change or a need. Business Knowledge underlying
competencies include -
Business Acumen, Industry Knowledge, Organization Knowledge, Solution Knowledge, and
Methodology Knowledge
9.3.1 Business Acumen
Business acumen is the ability to understand business needs using experience and knowledge
obtained from other situations. Being aware of the experiences or challenges encountered in the
past may assist a business analyst in determining which information may be applicable to the
current situation. Factors that may cause differences in practices can include industry, location,
size of organization, culture, and the maturity of the organization.
Measures of effective business acumen include:

• demonstrating the ability to recognize potential limitations and opportunities,
• demonstrating the ability to recognize when changes to a situation may require a change in the
direction of an initiative or effort,
• understanding the risks involved and the ability to make decisions on managing risks,
• demonstrating the ability to recognize an opportunity to decrease expenses and increase profits,
and
• understanding the options available to address emerging changes in the situation.
9.3.2 Industry Knowledge
Industry knowledge provides the business analyst with an understanding of current practices and
activities within an industry, and similar processes across industries. Industry knowledge is an
understanding of: current trends, market forces, market drivers, key processes, services, products,
definitions, customer segments, suppliers, practices, regulations, and other factors that impact or
are impacted by the industry and related industries. Industry knowledge is also an understanding of
how a company is positioned within an industry, and its impacts and dependencies, in regards to
the market and human resources.
Measures of effective industry knowledge include:
• being aware of activities within both the enterprise and the broader industry,
• having knowledge of major competitors and partners,
• the ability to identify key trends shaping the industry,
• being familiar with the largest customer segments,
• having knowledge of common products and product types,
• being knowledgeable of sources of information about the industry,
• understanding of industry specific terms, standards, processes and methodologies, and
• understanding of the industry regulatory environment.
9.3.3 Organization Knowledge
Organization knowledge includes an understanding of how the enterprise generates profits,
accomplishes its goals, the management and organization structure, the relationships that exist
between business units, and the persons who occupy key stakeholder positions. Organization
knowledge also includes understanding the organization's formal and informal communication
channels as well as an awareness of the internal politics that influence decision making.
Measures of effective organization knowledge include:
• the ability to act according to informal and formal communications and authority channels,
• understanding of terminology or jargon used in the organization,
• understanding of the products or services offered by the organization,
• the ability to identify subject matter experts (SMEs) in the organization, and
• the ability to navigate organizational relationships and politics.

9.3.4 Solution Knowledge
Solution knowledge allows business analysts to leverage their understanding of existing
departments, environments, or technology to efficiently identify the most effective means of
implementing a change. The business analyst may leverage knowledge gained from prior
experiences to expedite the discovery of potential changes through elicitation or in-depth analysis.
Familiarity with the range of commercially available solutions or suppliers can assist with the
identification of possible alternatives.
Measures of effective solution knowledge include:
• reduced time or cost to implement a required change,
• shortened time on requirements analysis and/or solution design,
• understanding when a larger change is, or is not, justified based on business benefit, and
• understanding how additional capabilities that are present, but not currently used, can be
deployed to provide value.
9.3.5 Methodology Knowledge
Organizations adopt or create their own methodologies to fit varying levels of culture, maturity,
adaptability, risk, uncertainty, and governance. Knowledge regarding a variety of methodologies
allows the business analyst to quickly adapt to, and perform in, new environments.
Measures of effective methodology knowledge include:
• the ability to adapt to changes in methodologies,
• the willingness to use or learn a new methodology,
• the successful integration of business analysis tasks and techniques to support the current
methodology,
• familiarity with the terms, tools, and techniques prescribed by a methodology, and
• the ability to play multiple roles within activities prescribed by a methodology.
 
9.4 Communication Skills (page 203)
Communication is the act of a sender conveying information to a receiver in a method which
delivers the meaning the sender intended. Active listening skills help to deepen understanding and
trust between the sender and the receiver. Effective communication benefits all stakeholders.
Communication may be accomplished using a variety of delivery methods: verbal, non-verbal,
physical, and written. Most communication methods deal with words, while some methods deal
with movements and expressions.
Planning effective communication includes the sender reviewing the information that is known
about the receiver. Differences between the sender and the receiver, such as native language,
culture, motivations, priorities, communication, learning, and thinking styles may call for specific

communication methods. When planning to communicate information, the following considerations
may be helpful:
• consider what the receiver knows or does not know,
• structure the information in a logical, comprehensible manner,
• determine how to best present the information to convey the intended meanings (for example,
using visual aids, graphs, diagrams, or bullet points), and
• understand the expectations of the recipients.
Communication Skills core competencies include -
Verbal Communication, Non-Verbal Communication, Written Communication, and Listening.
9.4.1 Verbal Communication
Business analysts use verbal communication to convey ideas, concepts, facts, and opinions to a
variety of stakeholders. Verbal communication uses spoken words to convey information from the
sender to the receiver. Verbal communication skills are used to express business analysis
information, ideas, concepts, facts, and opinions. It allows for the efficient transfer of information,
including emotional and other non-verbal cues. Verbal communication deals specifically with the
sender's choice of words and the tone of voice. It can be paired with both written and non-verbal
communication.
Measures of effective verbal communication include:
• restating concepts to ensure all stakeholders clearly understand the same information,
• assisting conversations to reach productive conclusions,
• delivering effective presentations by designing and positioning content and objectives
appropriately, and
• communicating an issue's important points in a calm and rational manner, and presenting
solution options.
9.4.2 Non-Verbal Communication
Non-verbal communication skills enable the effective sending and receiving of messages through
—but not limited to—body movement, posture, facial expressions, gestures, and eye contact.
Moods, attitudes, and feelings impact body movement and facial expressions. Non-verbal
communication begins immediately when one person is able to see another. The effective use of
non-verbal communication skills can present a trustworthy, confident, and capable demeanor.
Measures of effective non-verbal communication include:
• being aware of body language in others, but not assuming a complete understanding through
non-verbal communication,
• intentional awareness of personal non-verbal communication,

• improving trust and communication as a result of non-verbal communication, and
• effectively addressing and resolving situations when a stakeholder's non- verbal communication
does not agree with their verbal message.
9.4.3 Written Communication
Written communication is the practice of using text, symbols, models (formal or informal), and
sketches to convey and share information. An understanding of the audience is beneficial to
effectively use written communication. Written communication has the added challenge of
presenting information using the correct words to the audience, and at a time or place that is
remote from the time and place it was created.
Measures of effective written communication include:
• adjusting the style of writing for the needs of the audience,
• proper use of grammar and style,
• choosing words the audience will understand the intended meaning of, and
• ability of the reader to paraphrase and describe the content of the written communication.
9.4.4 Listening
Listening is the process of not just hearing words but understanding their meaning in context. By
exhibiting effective listening skills, business analysts not only have a greater opportunity to
accurately understand what is being communicated, but also to demonstrate that they think what
the speaker is saying is important.
Measures of effective listening include:
• giving the speaker undivided attention,
• acknowledging the speaker with verbal or non-verbal encouragement,
• providing feedback to the person or the group that is speaking to ensure there is an
understanding, and
• using active listening skills by deferring judgment and responding appropriately.
9.5 Interaction Skills (page 207)
Interaction skills are represented by the business analyst's ability to relate, cooperate, and
communicate with different kinds of people. Business analysts are uniquely positioned to facilitate
stakeholder communication, provide leadership, encourage comprehension of solution value, and
promote stakeholder support of the proposed changes. Interaction Skills core competencies
include:
Facilitation, Leadership and Influencing, Teamwork, Negotiation and Conflict Resolution, and
Teaching.

9.5.1 Facilitation
Business analysts facilitate interactions between stakeholders in order to help them make a
decision, solve a problem, exchange ideas and information, or reach an agreement regarding the
priority and the nature of requirements, and also for negotiation and conflict resolution. Facilitation
is the skill of moderating discussions within a group in order to enable all participants to effectively
articulate their views on a topic under discussion, and to ensure that participants in the discussion
are able to recognize and appreciate the differing points of view that are articulated.
Measures of effective facilitation include:
• making it clear to the participants that the facilitator is a third party to the process and not a
decision maker nor the owner of the topic,
• encouraging participation from all attendees,
• remaining neutral, but at the same time being impartial and intervening when required,
• establishing ground rules,
• ensuring that participants in a discussion correctly understand each other's positions,
• using meeting management skills and tools to keep discussions focused and organized,
• preventing discussions from being sidetracked onto irrelevant topics, and
• understanding and considering all parties’ interests, motivations, and objectives.
9.5.2 Leadership and Influencing
Leadership and influencing involves motivating people to act in ways that enable them to work
together to achieve shared goals and objectives, and guiding stakeholders during the investigation
of business analysis information and solution options. Understanding the individual motives, needs,
and capabilities of each stakeholder and how those can be effectively channeled assists business
analysts in meeting the shared objectives of the organization.
Measures of effective leadership and influencing include:
• reduced resistance to necessary changes,
• articulation of a clear and inspiring vision of a desired future state,
• success in inspiring others to turn vision into action,
• influence on stakeholders to understand mutual interests,
• effective use of collaboration techniques to influence others,
• influence on stakeholders to consider broader objectives over personal motivations, and
• re-framing issues so alternate perspectives can be understood and accommodated to influence
stakeholders towards shared goals.

9.5.3 Teamwork
Teamwork skills allow business analysts to work productively with team members, stakeholders,
and any other vested partners so that solutions can be effectively developed and implemented.
Business analysts often work as part of a team with other business analysts, project managers,
stakeholders, and subject matter experts (SMEs). Relationships with people in those roles are a
critical part of the success of any project or enterprise.
Measures of effective teamwork include:
• fostering a collaborative working environment,
• effectively resolving conflict,
• developing trust among team members,
• support among the team for shared high standards of achievement, and
• promoting a shared sense of ownership of the team goals.
9.5.4 Negotiation and Conflict Resolution
Business analysts occasionally mediate negotiations between stakeholders in order to reach a
common understanding or an agreement. During this process, business analysts help resolve
conflicts and differences of opinion with the intent of maintaining and strengthening working
relationships among stakeholders and team members. Negotiation and conflict resolution involves
mediating discussions between participants in order to help them recognize that there are differing
views on the topic, resolve differences, and reach conclusions that have the agreement of all
participants.
Measures of effective teamwork include:
• a planned approach to ensure that the negotiation takes into account the tone of voice, the
conveyed attitude, the methods used, and the concern for the other side’s feelings and needs,
• the ability to recognize that the needs of the parties are not always in opposition and that it is
often possible to satisfy both parties without either side losing,
• an objective approach to ensure the problem is separated from the person so that the real issues
are debated without damaging working relationships, and
• the ability to recognize that effective negotiation and conflict resolution are not always achieved
in a single autonomous meeting, and that sometimes several meetings are required in order to
achieve the stated goals.
9.5.4 Teaching
Teaching skills help business analysts effectively communicate business analysis information,
concepts, ideas, and issues. Teaching is the process of leading others to gain knowledge.
Business analysts are responsible for confirming that the information communicated has been

understood by stakeholders. This requires teaching skills in selecting the most appropriate visual,
verbal, written, and kinesthetic teaching approaches according to the information or techniques
being taught.
Measures of effective teaching include:
• utilizing different methods to communicate information to be learned by stakeholders,
• discovering new information through high levels of stakeholder engagement,
• validating that audiences have a clear understanding of the key messages that are intended to
be learned, and
• verifying that the stakeholders can demonstrate the new knowledge, facts, concepts, and ideas.
9.6 Tools and Technology (page 211)
Business analysts use a variety of software applications to support communication and
collaboration, create and maintain requirements artifacts, model concepts, track issues, and
increase overall productivity. Requirements documentation is often developed using word
processing tools. Requirements management technologies support requirements workflow,
approvals, baselining, and change control. Interacting with the stakeholders and team members
may require the use of communication and collaboration tools, as well as presentation software
Business Analysis Tools and Technology core competencies include:
Office Productivity Tools and Technology, Business Analysis Tools and Technology, and
Communication Tools and Technology.
9.6.1 Office Productivity Tools and Technology
Business analysts use office productivity tools and technology to document and track information
and artifacts. Office productivity tools and technology provide business analysts with the ability to
organize, dissect, manipulate, understand, and communicate information clearly. Many
organizations utilize these tools to study, store, and distribute information. Office productivity tools
and technology include the following:
• Word processing and presentation programs
• Presentation software
• Spreadsheets
• Communication Tools (e-mail and instant messaging programs)
• Collaboration and knowledge management tools
• Hardware
Measures of effective office productivity tools and technology include:
• increased efficiencies and streamlining of processes by exploring features and functions of tools,
• awareness of available tools, their operation, and abilities,
• the ability to determine the tool that will best meet stakeholder needs, and
• the ability to clearly communicate the major features of available tools.

9.6.2 Business Analysis Tools and Technology
Business analysts use a variety of tools and technology to model, document, and manage outputs
of business analysis activities and deliverables to stakeholders. Tools that are specific to the field
of business analysis provide specialized capabilities in - modelling, diagramming, documenting,
analyzing and mapping requirements, identifying relationships between requirements, tracking and
storing requirements artifacts, and communicating with stakeholders.
Tools specifically designed for business analysis may include such functionality as modelling,
requirements management, issue tracking, prototyping and simulation, computer aided software
engineering (CASE), and survey engines.
Measures of effective business analysis tools and technology include:
• the ability to apply an understanding of one tool and other similar tools,
• being able to identify major tools currently available and describe their strengths, weaknesses,
and how they may be used in any given situation,
• understanding of and the ability to use the major features of the tool, ability to select a tool or
tools that support organizational processes,
• the ability to use the tools to complete requirements-related activities more rapidly than otherwise
possible, and
• the ability to track changes to the requirements and their impact on the solution implementation,
stakeholders, and value.
9.6.3 Communication Tools and Technology
Business analysts use communication tools and technology to perform business analysis activities,
manage teams, and collaborate with stakeholders. Communication tools are used to plan and
complete tasks related to conversational interactions and collaborative interactions.
Communication tools allow business analysts to work with virtual and co-located teams. Business
analysts select the appropriate tool and technology for the situation and stakeholder group while
balancing cost, risk, and value.
Examples of conversation interaction tools include voice communications, instant messaging,
online chat, e-mail, blogging, and microblogging. Examples of collaboration tools include video
conferencing, electronic white boarding, wikis, electronic calendars, online brainstorming tools,
electronic decision making, electronic voting, document sharing, and idea sharing.
Measures of effective business analysis tools and technology include:
• the selection of appropriate and effective tools for the audience and purpose,
• effectively choosing when to use communication technology and when not to,
• the ability to identify tools to meet communication needs, and
• understanding of and the ability to use features of the tool.

CBAP BABOK v3 notes

More Related Content

What's hot (20)

Similar to CBAP BABOK v3 notes (20)

Recently uploaded (20)

CBAP BABOK v3 notes