www.theiiba.

org
The Guide to the
Business Analysis
Body of Knowledge
Version 2.0 Framework
www.theiiba.org 2
Introduction
Purpose
This document is intended to provide an overview of the
framework developed for version 2.0 of the Business
Analysis Body of Knowledge (BABOK).
Key Concepts
Business Analysis
Business analysis is the set of tasks and techniques
used to work as a liaison among stakeholders in order to
understand the structure, policies, and operations of an
organization, and recommend solutions that enable the
organization to achieve its goals.
The BABOK is intended to describe and defne
business analysis as a discipline, rather than defne
the responsibilities of a person with the job title of
business analyst (which may vary signifcantly between
organizations). Business analysis may be performed by
people with job titles such as systems analyst, process
analyst, project manager, product manager, developer, QA
analyst, business architect, or consultant, among others.
Solution
A solution meets a business need, by solving problems
or allowing the organization to take advantage of an
opportunity. A solution can be subdivided into components,
including the information systems that support it, the
processes that manage it, and the people who operate
it. Business analysis helps organizations to defne the
optimal solution for their needs, given the set of constraints
(including time, budget, regulations, and others) under
which that organization operates.
Scope
The term scope is used to mean a number of different
things, but two defnitions predominate:
Solution scope is the set of capabilities a solution must
support to meet the business need.
Project scope is the work necessary to construct and
implement a particular solution.
When the BABOK refers to scope, the solution scope
is meant unless we specifcally say otherwise. The
defnition and management of the solution scope is central
to business analysis, and differentiates it from project
management (which is concerned with the project scope).
Requirement
A requirement is:
A condition or capability needed by a stakeholder to
solve a problem or achieve an objective.
A condition or capability that must be met or possessed
by a solution or solution component to satisfy a contract,
standard, specifcation, or other formally imposed
documents.
A documented representation of a condition or capability
as in (1) or (2).
As implied by this defnition, a requirement may be
unstated, implied by other requirements, or directly stated
and managed. The elicitation, analysis, and communication
of requirements, with the objective of ensuring that they are
visible to and understood by all stakeholders, is central to
the discipline of business analysis.

1)
2)
3)
www.theiiba.org 3
Structure of BABOK 2.0
Task
A task is an essential piece of work that must be performed
as part of business analysis. Tasks may be performed
formally or informally. The defnition of the task should be
universally applicable to business analysis efforts, no matter
what type of initiative it is. It does not mean that it is done
frequently or that most BAs will necessarily perform the
tasks.
A task must have the following characteristics:
A task accomplishes a result in an output that creates
valuethat is, if we perform a task we agree that
something useful has been done

A task is completein principle successor tasks that

make use of outputs should be able to be performed by
a different person
A task is a necessary part of the purpose of the KA to
which it belongs.
As can be seen in the chart below, tasks are not necessarily
performed at a particular time in the lifecycle of a project.
Even lifecycles with clearly defned phases will require tasks
from most if not all KAs to be performed in every phase.
Iterative or agile lifecycles may require that tasks in all KAs
be performed as close to simultaneously as possible. Tasks
may be performed in any order, as long as the necessary
inputs to a task are present.
Technique
Relationship to Tasks
Techniques describe how tasks are performed under
specifc circumstances. A task may have none, one, or
more related techniques. A technique must be related to at
least one task.
The techniques described in the BABOK are intended
to cover the most common and widespread use in the
business analysis community. Business analysts are

0
25
50
75
100
RM & C
SA & V
RA
E
EA
BAP & M
Implementation
Execution
Analysis
Initiation
BAP & M Business Analysis Planning and Monitoring
EA Enterprise Analysis
E Elicitation
RA Requirements Analysis
SA & V Solution Assessment and Validation
RM & C Requirements Management and Communication
www.theiiba.org 4
expected to apply their experience and best judgement in
determining which techniques are appropriate to a given
situation, and this may include techniques that are not
described or mentioned in the BABOK. As our feld evolves,
we expect that techniques will be added, changed, or
removed.
Multiple KAs
Techniques frequently apply to multiple KAs:
If the technique applies to signifcantly more tasks in one
KA than any others, it will be described there.
If the technique applies to a similar number of tasks, it
will appear in the frst KA in which it is described.
Input/Output
An input represents the information necessary for a task
to begin. Inputs should not be optional (at least not as the
basic defnition)if something is merely helpful we do not
defne it as an input.
Inputs may be:
Explicitly generated outside the scope of business
analysis (e.g., a project plan).
Generated by a business analysis task. In this case the
input is maintained by the BABOK task that created it.
An output is a necessary result of the work described in the
task. Outputs are produced and maintained by one and only
one task, although a task can have multiple outputs.
Outputs may be produced at any level of formality, from
verbal discussion with affected stakeholders to being

captured in a software tool and placed under strict change

control. The form of an output is dependent on the type of
initiative underway, standards adopted by the organization,
and best judgement of the business analyst as to an
appropriate way to address the information needs of key
stakeholders.
There is no assumption that the presence of an input or an
output means that the associated deliverable is complete
and/or fnal. The I/O only needs to be suffciently complete
to allow successive work to begin.
Knowledge Area
A knowledge area groups a related set of tasks and
techniques.
Methodology
A methodology determines which business analysis tasks
and techniques are used to solve a business problem.
Unlike a technique, which is leveraged by some of the tasks
performed, a methodology will generally affect all of the
tasks that are performed during the course of a project.
Methodologies generally fall outside the scope of the
BABOK. We acknowledge their existence and may provide
some guidelines as to how they affect the BABOK as
a whole but their proper defnition should be left to the
methodology authors.
BABOK v.2 Knowledge Areas
Enterprise
Analysis
Business Analysis Planning
Elicitation
Requirements
Analysis
Requirements Management and Communication
Solution
Assessment
and Validation
Fundamentals
2007 International Institute of Business Analysis
www.theiiba.org 5
Business Analysis Planning and Monitoring
Description
Business Analysis Planning and Monitoring describes how
to determine which activities are necessary to perform
in order to complete a business analysis effort. It covers
identifcation of stakeholders, selection of business
analysis techniques, the process we will use to manage
our requirements, and how we assess the progress of the
work in order to make necessary changes in work effort.
Business analysis planning is a key input to the project plan,
and project management responsibilities include organizing
and coordinating business analysis activities with the needs
of the rest of the project team.
Tasks Purpose Inputs Outputs
Conduct Stakeholder
Analysis
Identify stakeholders who may be impacted
by a proposed initiative or who share a
common business need. This task includes
determining appropriate stakeholders for
the project or project phase, and analyzing
stakeholder infuence, authority (approve, sign
off, veto), and project attitude.
Organizational
Standards
Defned Business
Problem/Opportunity

Stakeholder list
Stakeholder roles
and responsibility
designation

Plan Business
Analysis Activities
Determines which activities are required to
defne the solution to a business problem,
how those activities will be carried out, the
work effort involved, and an estimate of how
long the activities will take.
Identifes business analysis deliverables
Determines the scope of work for the
business analysis activities
Determine tasks for the business
analysis activities in the Knowledge
Areas: Enterprise Analysis, Elicitation,
Requirements Analysis, Solution
Assessment and Validation. Detail will vary
from KA to KA.
Identifes task dependencies, and
interfaces between tasks
Develop estimates for BA work (time, skill
level, complexity of tasks, etc.)

Stakeholder list
Stakeholder roles
and responsibility
designation
Organizational
Standards

Business Analysis
Plans for:
Enterprise Analysis
Business Analysis
Planning and
Monitoring
Elicitation
Requirements
Analysis
Solution
Assessment and
Validation
Requirements
Management and
Communication

Purpose
Plan the execution of business analysis tasks
Update or change the approach to business analysis as
required
Assess effectiveness of and continually improve
business analysis practices

www.theiiba.org 6
Tasks Purpose Inputs Outputs
Plan Business
Analysis
Communication
Determine what information the various
stakeholders need to be provided about the
results of business analysis and the forms it
should take (verbal, written, etc). It includes
considerations for, as well as constraints,
impacts, durability and trade-offs of different
communications media.
Stakeholder list
Stakeholder roles
and responsibility
designation
Business Analysis
Plan(s)

Business Analysis
Communication Plan
Plan Requirements
Management Process
Describes how to determine the appropriate
requirements process for a particular
initiative. It describes how we determine
what is currently in place, and how to create
the process if it doesnt exist. It includes
determining whether and how requirements
are changed, which stakeholders need to
approve (instead of the actual approval
of requirements), as well as who will be
consulted on, or informed of changes, etc. It
also includes the approach to requirements
traceability and determining which
requirements attributes we will capture.
Organizational
Standard
Business Analysis
Plan(s)

Requirements
Management Plan
Plan, monitor and
Report on Business
Analysis Performance
Determine which metrics will be used
to measure the work performed by the
business analysts. It includes how we track,
assess, and report on the quality of the work
performed by business analysts and take
steps to correct any problems that may crop
up. If problems are identifed, determine
appropriate corrective action (which may feed
into the development of future plans on this or
other projects).
Organizational
Performance
Standards
Actual Performance
Metrics
Business Analysis
Plan(s)
Requirements
Management Plan

BA Performance
Assessment
Lessons Learned
Process
improvement
recommendations

www.theiiba.org 7
Enterprise Analysis
Purpose
Identify and propose projects that meet strategic needs and
goals.
Tasks Purpose Inputs Outputs
Identify Business
Need
Evaluate the internal and external
environment
Internal:
Defne/refne current/future business
architecture
Assess the current state of
technology (infrastructure and
applications)
External:
Benchmark analysis
Competitive studies
Fully defne business problem/opportunity

Business Architecture
Business Goal(s)

Defned Business
Problem/Opportunity
Determine Solution
Approach
Identify potential solutions
Analyze feasibility of options
Recommend viable business solution
Validate with decision makers

Business Architecture
Defned Business
Problem/Opportunity

Solution Approach
Defne Solution Scope Context diagram
Product Breakdown Structure

Business Architecture
Defned Business
Problem/Opportunity
Solution Approach

Solution Scope
Develop the Business
Case
Defne project objectives and expected
business benefts
Develop project scope
Estimate time, cost, resources
Analyze cost vs. beneft
Evaluate risk

Business Architecture
Business Goal(s)
Defned Business
Problem/Opportunity
Solution Scope

Business Case
Description
Enterprise Analysis describes how we take a business
need, refne and clarify the defnition of that need, and
defne a solution scope that can feasibly be implemented
by the business. It covers problem defnition and analysis,
business case development, feasibility studies, and the
defnition of a solution scope.
www.theiiba.org 8
Elicitation
Purpose
Explore, identify and document stakeholder needs.
Tasks Purpose Inputs Outputs
Prepare for Elicitation Prepare for elicitation by ensuring all needed
resources are organized and scheduled for
conducting the elicitation activities.
Stakeholder list
Stakeholder roles
and responsibility
designation
Either (Defned
Business Problem/
Opportunity) or
(Business Case and
Solution Scope)
Elicitation plan

Scheduled
resources
Supporting
materials

Conduct Elicitation Meet with stakeholder(s) to elicit information

regarding their needs
Supporting materials
Either (Defned
Business Problem/
Opportunity) or
(Business Case and
Solution Scope)
Organizational
standards

Elicitation activity
results
Assumptions,
constraints, risks,
issues
Documentation
based on technique
(e.g., interview
notes, workshop
results, survey
responses, etc.)

Document Elicitation
Results
Record the information provided by
stakeholders for use in analysis.
Elicitation activity
results
Stated
requirements

Confrm Elicitation
Results
Validate that the stakeholders intentions have
been correctly captured and understood.
Stated requirements Validated stated
requirements

Description
Elicitation describes how we work with stakeholders to fnd
out what their needs are and ensure that we have correctly
and completely understood their needs.
www.theiiba.org 9
Requirements Analysis
Purpose
Progressively elaborate stated requirements to suffcient
level of detail that accurately defnes the business need
within specifed scope
Validate requirements meet the business need
Verify requirements are acceptable quality

Tasks Purpose Inputs Outputs

Organize
Requirements
Structure and organize a set of requirements
into logical sets. The organization may
be based on defning multiple levels of
requirements, packaging related functions
together, and so forth.
Business Case
Solution Scope
Requirements

Structured
requirements
Prioritize
Requirements
Determine the business priority of
requirements (including voting, ranking,
beneft analysis and so forth). Identify logical
dependencies between requirements and
requirements packages.
Requirements
Business Case

Prioritized
requirements
Specify and Model
Requirements
Describes standard practices for writing
textual requirements and creating models or
diagrams. Specifc models are addressed as
techniques.
Includes capturing the requirements
attributes.
Requirements Specifed or modeled
Requirements
Determine
Assumptions and
Constraints
As we analyze stakeholder requests we
will fnd that some of their desires are not
properly requirements but are rather based
on assumptions regarding what the solution
team is capable of delivering. These should
be captured and assessed but are not
properly requirements .
Stakeholder Statements Assumptions and
Constraints
Verify Requirements Determine that the requirements are correctly
and completely defned.
Specifed or modeled
Requirements
Verifed requirements
Validate Requirements Validate that a requirement will satisfy a
business need.
Verifed requirements Validated requirements
Description
Requirements Analysis describes how we progressively
elaborate the solution defnition in order to enable the
project team to design and build a solution that will meet
the needs of the business and stakeholders. In order to
do that, we have to analyze the stated requirements of our
stakeholders to ensure that they are correct, assess the
current state of the business to identify and recommend
improvements, and ultimately verify and validate the results,
www.theiiba.org 10
Solution Assessment and Validation
Purpose
Assess solutions to ensure that strategic goals are met and
requirements are satisfed.
Tasks Purpose Inputs Outputs
Assess Requirements
Coverage
Determine how well possible options
for solution designs will meet the
requirements. The assessment may include
a recommendation of a particular solution,
rejection of all solutions, or an assessment of
possible trade-offs.
Examples:
RFI/RFP responses
Internal designs
Manual procedures

Solution Design
Option(s)
Solution Design
Assessment

Allocate Requirements Allocate requirements among releases and/or

solutions components. This task ensures that
the possible release options are designed in a
way to maximize the possible business value
given the options and alternatives generated
by the design team.
Allocate requirements to hardware,
software, manual procedures, etc.
Recommend the release/delivery strategy
Understand trade-offs between different
implementation approaches

Solution Design
Validated
Requirements

Allocated
Requirements

Determine
Organizational
Readiness
Determine organizational readiness to
effectively operate the new solution
Conduct organizational readiness
assessment
Recommend ways to optimize the
organizational deployment

Business Architecture
Solution Design

Organizational
Readiness
Assessment
Organizational
Change
Recommendations

Description
Solution Assessment and Validation describes how to
assess proposed solutions to determine which solution
best fts the business need, identify gaps and shortcomings
in solutions, and determine necessary workarounds
or changes to the solution. It also describes how we
assess deployed solutions to see how well they met the
original need in order to enable businesses to assess the
performance and effectiveness of projects.
www.theiiba.org 11
Tasks Purpose Inputs Outputs
Validate Solution Validate the verifed and deployed solution
meets the business need:
Defne acceptance criteria (including what
level of conformance to requirements is
acceptable)
Identify defects/shortcomings (this should
be distinguished from functional testing)
Analyze impact
Defne corrective actions
Validate corrective actions
When a problem is identifed with the
deployed solution (i.e., a failure to meet a
requirement whether or not the requirement
was correctly specifed) determine what is the
most appropriate response.

Verifed or Deployed
Solution
Validated
Requirements

Validated Solution
Defect Impact
Analysis
Validated Corrective
Actions

Evaluate Solution Assess the value of the solution as deployed

to the business (to determine if the original
goals are met). Compare actual vs. expected
costs and benefts.
Deployed Solution
Performance Metrics
Cost/Beneft Analysis
www.theiiba.org 12
Requirements Management and Communication
Purpose
Recognize that communication takes places throughout
all knowledge areas and is important for managing
requirements
Manage the approved solution and requirements scope
Ensure stakeholders have access to business analysis
work products
Prepare and communicate requirements to stakeholders
Facilitate enterprise consistency and effciency by re-
using requirements whenever possible

Tasks Purpose Inputs Outputs

Manage Solution and
Requirements Scope
Baseline and manage changes to business
case, solution and requirements
Approve requirements (according to
the approval authority stated in the
Requirements Management Plan)
Baseline requirements
Manage formal and informal change
control on requirements
Control multiple versions of requirements
work products
Manage requirements conficts and issues

Stakeholder roles
and responsibility
designation
Requirements
Requirements
management plan

Approved
Requirements
Decision Record

Manage Requirements
Traceability
Trace requirements (update and
maintaining relationships between
requirements components)
Perform impact analysis when changes
are requested and supply this information
to the change control process (in previous
task)
Support the allocation of requirements to
the solution in Solution Assessment and
Validation.

Requirements Traced
Requirements

Maintain
Requirements for
re-use
Select which implemented requirements
will be maintained after solution
implementation
Name the responsible party who will
maintain the requirements (i.e. custodian,
librarian)
Facilitate ongoing use of requirements for
impact analysis and solution maintenance
Facilitate re-use of requirements on
related projects to encourage enterprise
consistency of business models

Implemented
requirements
Maintained/re-used
requirements

Description
Requirements Management and Communication describes
how we manage conficts, issues and changes and
ensure that stakeholders and the project team remain
in agreement on the solution scope. Depending on the
complexity and methodology of the project, this may require
that we manage formal approvals, baseline and track
different versions of requirements documents, and trace
requirements from origination to implementation.
www.theiiba.org 13
Tasks Purpose Inputs Outputs
Prepare Requirements
Package
Determine appropriate format for
requirements (v1.6 task)
Create a requirements package (V1.6 task)

Requirements
Business analysis
communications plan

Requirements
package (e.g.,
executive
summary, formal
documentation,
RFI, RFP, etc.)

Communicate
requirements
Interaction with all stakeholders before,
during and after projects.
Each KA involves communication that will
be noted here
Interaction with solution team to assure
that requirements are correctly understood
and implemented

Requirements
package
Business analysis
communications plan

Communicated
requirements

www.theiiba.org 14
Business Analysis Techniques
any technique that modifes only one task will likely be
addressed within the body of that task.
Technique BAP & M EA E RA SA & V RM & C
Brainstorming X X
Business Rules X
Change Control Systems X X
Communication needs and media analysis? X X
Confguration Management/Repository X X
Coverage Matrix X X
Data Model X X
Decision Analysis X X
Decomposition X X X
Document Analysis X
Environmental Assessment (Internal/External) X X
Event/State Model X X
Financial Analysis (Cost/beneft, ROI, etc.) X X
Focus group X X
Gap analysis X X
Goal Analysis (Strategy maps, etcbreaking down a goal
into SMART objectives)
X
Interface Analysis X
Interface Identifcation X X
Interview X X
Issue and Defect Reporting X X
Metrics and Reporting X X X X
Nonfunctional Requirements X
The following techniques will be described in depth in
BABOK version 2. Other techniques not listed here may be
included within the scope of a particular task. In particular,
www.theiiba.org 15
Technique BAP & M EA E RA SA & V RM & C
Observation X X
Organizational Modeling X X
Personas and User Profles X X X
Process Model X X X
Prototyping X X
Requirements Workshop X
Retrospective X X
Reverse Engineering X
Scenarios and Use Cases X X
Scope Defnition (Context diagrams, use case diagrams,
etc).
X X
Structured Walkthrough X X X
Survey X
Traceability Matrix X X
User Acceptance Testing X
User Interface Modeling X
www.theiiba.org 16
Contributors
The following volunteers have participated in the development of the BABOK as authors, subject experts, reviewers, or in
other volunteer positions. The IIBA would like to thank them for their generous assistance and support.
Sharon Aker
Tony Alderson
Scott Ambler
James Baird
Betty Baker, CBAP
Finny Barker, CBAP
Kathleen Barrett
Jo Bennett
Kevin Brennan, CBAP
Cathy Brunsting
Neil Burton
Barbara Carkenord, CBAP
Jake Calabrese
Gerrie Caudle
Bruce Chadbourne
Carrollynn Chang
Patricia Chappell, CBAP
Karen Chandler
Pauline Chung
Joseph Czarnecki
Rafael Dorantes
Steve Erlank
Malcolm Eva
Kiran Garimella
Stephanie Garwood, CBAP
Robin Goldsmith
Peter Gordon, CBAP
Mary Gorman, CBAP
Ellen Gottesdiener
Paul Harmon
Kathleen B. Hass
Rosemary Hossenlopp
Jessica Hoyt
Monica Jain
May Jim
Brenda Kerton
Day Knez
Barbara Koenig
Peter Kovaks
Janet Lai
Gladys Lam
Robert Lam
Elizabeth Larson, CBAP
Richard Larson, CBAP
Dean Leffngwell
Cherifa Liamani
Karen Little, CBAP
Laura Markey
Patricia Martin
Richard Martin
Chris Matts
Gillian McCleary
Kent J. McDonald
Rosina Mete
Karen Mitchell
Bill Murray
Mark McGregor
Dulce Olivera
Meilir Page-Jones
Harish Pathria
Laura Paton
Debra Paul
Richard Payne
Kathleen Person
Kelly Piechota
Cleve Pillifant
Howard Podeswa
Leslie Ponder
Jason Questor
Cecilia Rathwell
Tony Rice
James Robertson
Suzanne Robertson
Jennifer Rojek
Ronald Ross
David Ruble
Keith Sarre, CBAP
Chip Schwartz, CBAP
John Slater
Jessica Sols
Jim Subach
Diane Talbot
Steve Tockey
Krishna Vishwanath
Marilyn Vogt
Katie Wise
Scott Witt
David Wright
Jacqueline Young
Ralph Young
IIBA, the IIBA logo, BABOK and Business Analysis Body of Knowledge are trademarks owned by the International Institute of Business Analysis.
CBAP is a certifcation mark owned by the International Institute of Business Analysis.