BABOK® v3
A GUIDE TO THE BUSINESS ANALYSIS BODY OF KNOWLEDGE®
I. Introduction
• A Guide to the Business Analysis Body of Knowledge® (BABOK®
Guide) is the globally recognized standard for the practice of business
analysis.
• The BABOK® Guide describes business analysis knowledge areas,
tasks, Underlying competencies, techniques and perspectives on how
to approach business analysis.
Purpose of the BABOK® Guide
• The primary purpose of the BABOK® Guide is to define the profession
of business analysis and provide a set of commonly accepted
practices. It helps practitioners discuss and define the skills necessary
to effectively perform business Analysis work.
• The BABOK® Guide also helps people who work with and employ
business analysts to understand the skills and knowledge they should
expect from a skilled practitioner.
Purpose of the BABOK® Guide
• Business analysis is a broad profession in which business analysts
might perform work for many different types of initiatives across an
enterprise.
• Practitioners may employ different competencies, knowledge, skills,
terminology, and attitudes that they use when performing business
analysis tasks.
• The BABOK® Guide is a common framework for all perspectives,
describing business analysis tasks that are performed to properly
analyze a change or evaluate the necessity for a change.
• Tasks may vary in form, order, or importance for individual business
analysts or for various initiatives.
The six knowledge areas
• The six knowledge areas of the BABOK® Guide (Business Analysis
Planning and Monitoring, Elicitation and Collaboration, Requirements
Life Cycle Management, Strategy Analysis, Requirements Analysis and
Design Definition (RADD), and Solution Evaluation) describe the
practice of business analysis as it is applied within the boundaries of a
project or throughout enterprise evolution and continuous
improvement.
Business Analysis Beyond Projects
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.
What is Business Analysis?
• 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.
• Business analysis can be performed from a diverse array of
perspectives. The BABOK® Guide describes several of these
perspectives: agile, business intelligence, information technology,
business architecture, and business process management.
Who is a Business Analyst?
• 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 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.
The activities that business analysts perform
include
• understanding enterprise problems and goals,
• analyzing needs and solutions,
• devising strategies,
• driving change, and
• facilitating stakeholder collaboration.
Other common job titles for people who
perform business analysis include
• business architect,
• business systems analyst,
• data analyst,
• enterprise analyst,
• management consultant,
• process analyst,
• product manager,
• product owner,
• requirements engineer, and
• systems analyst.
Structure of the BABOK® Guide
• 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. These tasks
describe specific activities that accomplish the purpose of their
associated knowledge area.
• The Business Analysis Key Concepts, Underlying Competencies,
Techniques, and Perspectives sections form the extended content in
the BABOK® Guide that helps guide business analysts to better
perform business analysis tasks.
Structure of the BABOK® Guide
• Business Analysis Key Concepts: define 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.
Structure of the BABOK® Guide
• Techniques: provide a means to perform business analysis tasks. The
techniques described in the BABOK® Guide are intended to cover the
most common and widespread techniques practiced within the
business Analysis community.
• 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.
II. Business Analysis Key Concepts
This chapter consists of:
• Business Analysis Core Concept Model™ (BACCM™)
• Key Terms
• Requirements Classification Schema
• Stakeholders
• Requirements and Design
III. – IV. Knowledge Areas
Knowledge areas represent areas of specific business analysis expertise that
encompass several tasks.
Business Analysis Planning and Monitoring: describes the tasks that
business analysts perform to organize and coordinate the efforts of business
analysts and stakeholders. These tasks produce outputs that are used as key
inputs and guidelines for the other tasks throughout the BABOK® Guide.
Elicitation and Collaboration: describes the tasks that business analysts
perform to prepare for and conduct elicitation activities and confirm the
results obtained. It also describes the communication with stakeholders once
the business analysis information is assembled and the ongoing
collaboration with them throughout the business analysis activities.
V. – VI. Knowledge Areas
• 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.
These tasks describe establishing meaningful relationships between
related requirements and designs, and assessing, analyzing and
gaining consensus on proposed changes to requirements and designs.
• 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.
VII. Knowledge Areas
• 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. 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.
VIII. Knowledge Areas
• 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.
Relationships Between Knowledge Areas
Tasks
• A task is a discrete piece of work that may be performed formally or
informally as part of business analysis. The BABOK® Guide defines a
list of business Analysis tasks. The definition of a given task is
universally applicable to business Analysis efforts, independent of the
initiative type.
• Tasks are grouped into knowledge areas. Business analysts perform
tasks from all knowledge areas sequentially, iteratively, or
simultaneously. The BABOK® Guide does not prescribe a process or an
order in which tasks are performed. Tasks may be performed in any
order, as long as the necessary inputs to a task are present.
Task format
• Purpose
• Description
• Inputs
• Elements
• Guidelines/Tools
• Techniques
• Stakeholders
• Outputs
IX. Underlying Competencies
• Underlying competencies reflect knowledge, skills, behaviours,
characteristics, and personal qualities that help one successfully
perform the role of the business analyst. These underlying
competencies are not unique to the business Analysis profession.
However, successful execution of tasks and techniques is often
dependent on proficiency in one or more underlying competencies.
Underlying competencies have the following structure:
• Purpose
• Definition
• Effectiveness Measures
Underlying Competencies structure
• The Purpose section describes why it is beneficial for business
analysts to have this underlying competency.
• The Definition section describes the skills and expertise involved in
the application of this competency.
• The Effectiveness Measures section describes how to determine
whether a person is demonstrating skills in this underlying
competency.
X. Techniques
• Techniques provide additional information on ways that a task may be
performed. The list of techniques included in the BABOK® Guide is
not exhaustive. There are multiple techniques that may be applied
alternatively or in conjunction with other techniques to accomplish a
task.
• Business analysts are encouraged to modify existing techniques or
engineer new ones to best suit their situation and the goals of the
tasks they perform.
X. Techniques
Techniques have the following structure:
• Purpose
• Description
• Elements
• Usage Considerations
Techniques structure
• The Purpose section describes what the technique is used for and the
circumstances under which it is most likely to be applicable.
• The Description section describes what the technique is and how it is
used.
• The Elements section describes key concepts that are needed to
understand how to use the technique.
• The Usage Considerations section describes the conditions under
which the technique may be more or less effective.
XI. Perspectives
• 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
XI. Perspectives
Perspectives have the following structure:
• Change Scope
• Business Analysis Scope
• Methodologies, Approaches, and Techniques
• Underlying Competencies
• Impact on Knowledge Areas
Perspectives structure
• The Change Scope section describes what parts of the enterprise the
change encompasses when viewed from this perspective and to what
extent it impacts both the objectives and operations of the
enterprise. The change scope also identifies the type of problems
solved, the nature of the solutions being sought, and the approach to
delivering these solutions and measuring their value.
• The Business Analysis Scope section describes the key stakeholders,
including a profile of the likely types of sponsors, the target
stakeholders, and the business analyst's role within an initiative. It
also defines likely outcomes that would be expected from business
analysis work in this perspective.
Perspectives structure
Methodologies, Approaches, and Techniques - The composition of this
section is unique to each perspective. In each case it describes the
methodologies, approaches, or techniques that are common and
specific to the application of business analysis in the perspective.
Methodologies and approaches are specialized ways of undertaking
the business analysis work. The techniques included in this section are
techniques that are not included in the Techniques chapter of the
BABOK® Guide but are especially relevant to the perspective.
Perspectives structure
• The Underlying Competencies section describes the competencies
that are most prevalent in the perspective.
• The Impact on Knowledge Areas section describes how knowledge
areas are applied or modified. It also explains how specific activities
within a perspective are mapped to tasks in the BABOK® Guide.
II. I. - Business Analysis Core Concept Model™
(BACCM™)
• The Business Analysis Core Concept Model™ (BACCM™) is a conceptual
framework for business analysis. It encompasses what business analysis is and
what it means to those performing business analysis tasks regardless of
perspective, industry, methodology, or level in the organization.
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 holistically evaluating the relationships
among these six concepts, and
• evaluate the impact of these concepts and relationships at any point during a
work effort in order to establish both a foundation and a path forward.
Business Analysis Core Concept Model™
The BACCM – Core concept description
• Change - The act of transformation in response to a need. Change
works to improve the performance of an enterprise. These
improvements are deliberate and controlled through business
analysis activities.
• Need - A problem or opportunity to be addressed. Needs can cause
changes by motivating stakeholders to act. Changes can also cause
needs by eroding or enhancing the value delivered by existing
solutions.
The BACCM – Core concept description
• Solution - A specific way of satisfying one or more needs in a context.
A solution satisfies a need by resolving a problem faced by
stakeholders or enabling stakeholders to take advantage of an
opportunity.
• Stakeholder - A group or individual with a relationship to the change,
the need, or the solution. Stakeholders are often defined in terms of
interest in, impact on, and influence over the change. Stakeholders
are grouped based on their relationship to the needs, changes, and
solutions.
The BACCM – Core concept description
• Value - The worth, importance, or usefulness of something to a
stakeholder within a context.
• Value can be seen as potential or realized returns, gains, and
improvements. It is also possible to have a decrease in value in the form of
losses, risks, and costs.
• Value can be tangible or intangible. Tangible value is directly measurable.
Tangible value often has a significant monetary component. Intangible
value is measured indirectly. Intangible value often has a significant
motivational component, such as a company's reputation or employee
morale.
• In some cases, value can be assessed in absolute terms, but in many cases
is assessed in relative terms: one Solution option is more valuable than
another from the perspective of a given set of stakeholders.
The BACCM – Core concept description
• Context - The circumstances that influence, are influenced by, and
provide understanding of the change.
• Changes occur within a context. The context is everything relevant to
the change that is within the environment. Context may include
attitudes, behaviours, beliefs, competitors, culture, demographics,
goals, governments, infrastructure, languages, losses, processes,
products, projects, sales, seasons, terminology, technology, weather,
and any other element meeting the definition.
The BACCM
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?
II. II. - Key Terms
• 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 refers to the broad and diverse sets of
information that business analysts analyze, transform, and report. It is
information of any kind—at any level of detail—that is used as an
input to, or is an output of, business analysis work. Examples of
business analysis information include elicitation results,
requirements, designs, solution options, solution scope, and change
strategy.
II. II. - Key Terms
• 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. The
nature of the representation may be a document (or set of documents) and
can vary widely depending on the circumstances.
• 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. For the purpose of business analysis, enterprise boundaries
can be defined relative to the change and need not be constrained by the
boundaries of a legal entity, organization, or organizational unit. An
enterprise may include any number of business, government, or any other
type of organization.
II. II. - Key Terms
• 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, as opposed to
an initiative or project team, which may be disbanded once its
objectives are achieved.
• 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.
II. II. - Key Terms
• 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. The nature of the representation may be a document (or set of
documents), but can vary widely depending on the circumstances.
• 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:
mitigating the consequences, removing the source of the risk, avoiding the
risk altogether by deciding not to start or continue with an activity that
leads to the risk, sharing the risk with other parties, or accepting or even
increasing the risk to deal with an opportunity.
II. III. Requirements Classification Schema
• 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.
II. III. Requirements Classification Schema
• 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.
II. III. Requirements Classification Schema
• 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.
II. IV. Stakeholders
• 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 BABOK® Guide does not mandate that these roles be filled for
any given initiative. Any stakeholder can be a source of requirements,
assumptions, or constraints.
II. IV. Stakeholders
• business analyst,
• customer,
• domain subject matter expert,
• end user,
• implementation subject matter
• expert,
• operational support,
• project manager,
• regulator,
• sponsor,
• supplier, and
• tester.
Business Analyst
• The business analyst is inherently a stakeholder in all business
analysis activities.
• The BABOK® Guide presumes that the business analyst is responsible
and accountable for the execution of these activities. In some cases
the business analyst may also be responsible for performing activities
that fall under another stakeholder role.
Customer, Domain Subject Matter Expert
• 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.
• A domain subject matter expert is any individual with in-depth
knowledge of a topic relevant to the business need or solution scope.
This role is often filled by people who may be end users or people
who have in-depth knowledge of the solution such as managers,
process owners, legal staff, consultants, and others.
End User, Implementation Subject Matter
Expert
• 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.
• An implementation subject matter expert is any stakeholder who has
specialized knowledge regarding the implementation of one or more
solution components. While it is not possible to define a listing of
implementation subject matter expert roles that are appropriate for
all initiatives, some of the most common roles are: project librarian,
change manager, configuration manager, solution architect,
developer, database administrator, information architect, usability
analyst, trainer, and organizational change consultant.
Operational Support
• Operational support is responsible for the day-to-day management
and maintenance of a system or product.
• While it is not possible to define a listing of operational support roles
that are appropriate for all initiatives, some of the most common
roles are: Operations analyst, product analyst, help desk, and release
manager.
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.
• While it is not possible to completely define a listing of project
management roles that are appropriate for all initiatives, some of the
most common roles are: project lead, technical lead, product
manager, and team leader.
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.
Sponsor, Supplier
• 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.
• 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.
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.
II. V. Requirements and Designs
• Eliciting, analyzing, validating, and managing requirements have
consistently been recognized as key activities of business analysis.
However, it is important to recognize that business analysts are also
responsible for the definition of design, at some level, in an initiative.
The level of responsibility for design varies based on the perspective
within which a business analyst is working.
• 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.
Requirements and Design Cycle
Requirements and Designs
• Stakeholders may present a need or a solution to an assumed need. A
business analyst uses activities found in Elicitation and Collaboration ,
Strategy Analysis, Requirements Analysis and Design Definition and
Solution Evaluation 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?’.
• For example, “Why is either the requirement or design necessary to
provide value to an enterprise and to facilitate the realization of an
enterprise’s goals and objectives?”
Requirements and Designs
The following table provides some basic examples of how information
may be viewed as either a requirement or a design.
Requirement Design
View six months sales data across multiple
organizational units in a single view.
A sketch of a dashboard.
Reduce amount of time required to pick
and pack a customer order.
Process model.
Record and access a medical patient’s
history.
Screen mock-up showing specific
data fields.
Develop business strategy, goals, and
objectives for a new business.
Business Capability Model.
Provide information in English and French. Prototype with text displayed in
English and French.
BABOK
• Business Analysis is the practice of enabling change in an organizational
context, by defining needs and recommending solutions that deliver value
to stakeholders.
BABOK®3 consists of:
• 6 Knowledge Areas,
• 30 Tasks,
• 50 Techniques,
• 6 Underlying Competencies of Business Analyst,
• 1 Business Analysis Core Concept Model (BACCM),
• 5 Perspectives.
Knowledge Areas
Task characteristics
30 Tasks
Business Analysis Core Concept Model
(BACCM)
Techniques
• 10.1 Acceptance and Evaluation Criteria
• 10.2 Backlog Management
• 10.3 Balanced Scorecard
• 10.4 Benchmarking and Market Analysis
• 10.5 Brainstorming
• 10.6 Business Capability Analysis
• 10.7 Business Cases
• 10.8 Business Model Canvas
• 10.9 Business Rules Analysis
• 10.10 Collaborative Games
• 10.11 Concept Modelling
• 10.12 Data Dictionary
• 10.13 Data Flow Diagrams
• 10.14 Data Mining
• 10.15 Data Modelling
• 10.16 Decision Analysis
• 10.17 Decision Modelling
• 10.18 Document Analysis
• 10.19 Estimation
• 10.20 Financial Analysis
• 10.21 Focus Groups
• 10.22 Functional Decomposition
• 10.23 Glossary
• 10.24 Interface Analysis
• 10.25 Interviews
• 10.26 Item Tracking
• 10.27 Lessons Learned
• 10.28 Metrics and Key Performance Indicators
(KPIs)
• 10.29 Mind Mapping
• 10.30 Non-Functional Requirements Analysis
• 10.31 Observation
• 10.32 Organizational Modelling
• 10.33 Prioritization
• 10.34 Process Analysis
• 10.35 Process Modelling
• 10.36 Prototyping
• 10.37 Reviews
• 10.38 Risk Analysis and Management
• 10.39 Roles and Permissions Matrix
• 10.40 Root Cause Analysis
• 10.41 Scope Modelling
• 10.42 Sequence Diagrams
• 10.43 Stakeholder List, Map, or Personas
• 10.44 State Modelling
• 10.45 Survey or Questionnaire
• 10.46 SWOT Analysis
• 10.47 Use Cases and Scenarios
• 10.48 User Stories
• 10.49 Vendor Assessment
• 10.50 Workshops
Underlying Competencies of Business Analyst
Perspectives
Stakehodlers