Babok v3 0 Framekwork

The Guide to the Business Analysis
Body of Knowledge (BABOK)™

Version 3.0 Framework
Author: Joseph Lapuz, CBAP, CSM

Wellington, New Zealand
Date Created: December 2016
Last Update Date: July 2018
Email: [email protected]
^J
1. INTRODUCTION
DESCRIPTION
A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) is the globally recognised 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
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.
KNOWLEDGE AREAS
Knowledge areas represent areas of specific business analysis expertise that encompass several tasks.
The six knowledge areas are:
1. Business Analysis Planning and Monitoring: describes the tasks that business analysts perform to organise 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.
2. 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.
3. 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.
4. 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.
5. Requirements Analysis and Design Definition: describes the tasks that business analysts perform to structure and organise 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 realised 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.
6. 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|P a g e
^J
DIAGRAM
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.
• 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.
• 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.
Each task in the BABOK® Guide is presented in the following format:

• Purpose
• Description
• Inputs
• Elements
• Guidelines/Tools
• Techniques
• Stakeholders
• Outputs
2|P a g e
^J
2. BUSINESS ANALYSIS KEY CONCEPTS

DESCRIPTION
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.
COMPOSITION
Business Analysis Core Concept Model™ (BACCM™): defines a conceptual framework for the business analysis profession.
• Key Terms: provides definitions of essential concepts, which are highlighted because of their importance to the BABOK® Guide.
• Requirements Classification Schema: identifies levels or types of requirements that assist the business analyst and other stakeholders in categorizing requirements.
• Stakeholders: defines 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.
BACM DIAGRAM
3|P a g e
^J
Requirements Classification Schema Requirements and Design Cycle

1 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.
2 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.
3 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.
4 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.
4|P a g e
^J
BUSINESS ANALYSIS TASKS BY KNOWLEDGE AREA

3. BUSINESS ANALYSIS 4. ELICITATION AND 5. REQUIREMENTS LIFE 6. STRATEGY ANALYSIS 7. REQUIREMENTS ANALYSIS 8. SOLUTION EVALUATION
PLANNING AND COLLABORATION CYCLE MANAGEMENT AND DESIGN DEFINITION
MONITORING
3.1 Plan Business Analysis 4.1 Prepare for Elicitation 5.1 Trace Requirements 6.1 Analyse Current State 7.1 Specify and Model 8.1 Measure Solution
Approach Requirements Performance
3.2 Plan Stakeholder 4.2 Conduct Elicitation 5.2 Maintain Requirements 6.2 Define Future State 7.2 Verify Requirements 8.2 Analyse Performance
Management Measure
3.3 Plan Business Analysis 4.3 Confirm Elicitation Results 5.3 Prioritise Requirements 6.3 Assess Risks 7.3 Validate Requirements 8.3 Assess Solution Limitations
Governance
3.4 Plan Business Analysis 4.4 Communicate Business 5.4 Assess Requirements 6.4 Define Change Strategy 7.4 Define Requirements 8.4 Assess Enterprise Limitations
Management Analysis Information Changes Architecture
3.5 Identify Business Analysis 4.5 Manage Stakeholder 5.5 Approve Requirements 7.5 Define Design Options 8.5 Recommend Actions to
Performance Improvements Collaboration Increase Solution Value
7.6 Analyse Potential Value and
Recommend Solution
5|P a g e
^J
3. BUSINESS ANALYSIS PLANNING AND MONITORING (BAPM)

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 identification 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 the necessary changes in the work effort.
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
INPUT/OUTPUT DIAGRAM
6|P a g e
^J
Tasks Inputs Elements Techniques Stakeholders Outputs

A Plan Business Analysis Approach  Needs  Planning Approach  Brainstorming  Domain SME  BA Approach
 Formality and Level of  Business Cases  Project Manager
Describes the planning of business analysis Detail of BA Deliverables  Document Analysis  Regulator
work from creation or selection of a  BA Activities  Estimation  Sponsor
methodology to planning the individual  Timing of BA Work  Financial Analysis
activities, tasks, and deliverables.  Complexity and Risk  Functional Decomposition
 Acceptance  Interviews
 Item Tracking
 Lessons Learned
 Process Modelling
 Reviews
 Risk Analysis and Management
 Scope Modelling
 Survey/Questionnaire
 Workshops
S Plan Stakeholder Engagement  Needs  Perform Stakeholder  Brainstorming  Customers  Stakeholder
 Business Analysis Analysis  Business Rules Analysis  Domain SME Engagement
Describes understanding which stakeholders Approach  Define Stakeholder  Document Analysis  End User Approach
are relevant to the change, what business Collaboration  Interviews  Project Manager
analysts need from them, what they need  Stakeholder  Lessons Learned  Regulator
from business analysts, and the best way to Communication Needs  Mind Mapping  Sponsor
collaborate.
 Organisational Modelling  Supplier
 Scope Modelling
 Stakeholder List, Map or Personas
 Survey or Questionnaire
 Workshops
G Plan Business Analysis Governance  Needs  Decision Making  Brainstorming  Domain SME  Governance
 Stakeholder  Change Control Process  Document Analysis  Project Manager Approach
Defines the components of business analysis Engagement Approach  Plan Prioritisation  Interviews  Regulator
that are used to support the governance Approach  Item Tracking  Sponsor
function of the organisation. It helps ensure  Plan for Approvals  Lessons Learned
that decisions are made properly and
 Organisational Modelling
consistently, and follows a process that
ensures decision makers have the
 Reviews
information they need. Examples of this
include requirements management, business  Survey or Questionnaire
analysis risk management, and allocation of  Workshops
business analysis resources.
M Plan Business Analysis Information  BA Approach  Organisation of Business  Brainstorming  Domain SME  Information
Management  Governance Approach Analysis Information  Interviews  Regulator Management
 Stakeholder  Level of Abstraction  Item Tracking  Sponsor Approach
Defines how information developed by Engagement Approach  Plan Traceability Approach  Lessons Learned
business analysts (including requirements  Plan for Requirements  Mind Mapping
and designs) is captured, stored, and Reuse  Processing Modelling
integrated with other information for long-  Storage and Access  Survey or Questionnaire
term use.
 Requirements Attributes  Workshops
7|P a g e
^J
P Identify Business Analysis  Business Analysis  Performance Analysis  Brainstorming  Domain SME  Business Analysis
Performance Improvements Approach  Assessment Measures  Interviews  Project Manager Performance
 Performance  Analyse Results  Lessons Learned  Sponsor Assessment
Describes managing and monitoring how Objectives (external)  Recommend Actions for  Metrics and KPIs
business analysis work is performed to Improvement  Observation
ensure that commitments are met and
 Process Analysis
continuous learning and improvement
opportunities are realised.
 Reviews
 Root Cause Analysis
 Workshops
8|P a g e
^J
4. ELICITATION AND COLLABORATION (EC)

DESCRIPTION
The Elicitation and Collaboration knowledge area describes the tasks that business analysts perform to obtain information from stakeholders and confirm the results. It also describes the communication with
stakeholders once the business analysis information is assembled. Elicitation is the drawing forth or receiving of information from stakeholders or other sources. It is the main path to discovering requirements and
design information, and might involve talking with stakeholders directly, researching topics, experimenting, or simply being handed information. Collaboration is the act of two or more people working together
towards a common goal. The Elicitation and Collaboration knowledge area describes how business analysts identify and reach agreement on the mutual understanding of all types of business analysis information.
Elicitation and collaboration work is never a 'phase' in business analysis; rather, it is ongoing as long as business analysis work is occurring.
Elicitation and collaboration can be planned, unplanned, or both. Planned activities such as workshops, experiments, and/or surveys can be structured and organised in advance. Unplanned activities happen in the
moment without notice, such as last-minute or 'just in time' collaboration or conversations. Business analysis information derived from an unplanned activity may require deeper exploration through a planned
activity.
PURPOSE
 Explore, identify and document stakeholder needs.
9|P a g e
^J

P Prepare for Elicitation  Needs  Understand the Scope of  Brainstorming  Domain SME  Elicitation Activity
 Stakeholder Elicitation  Data Mining  Project Manager Plan
The purpose of Prepare for Elicitation is to Engagement Approach  Select Elicitation  Document Analysis  Sponsor
understand the scope of the elicitation Techniques  Estimation
activity, select appropriate techniques, and  Setup Logistics  Interviews
plan for (or procure) appropriate supporting  Secure Supporting Material  Mind Mapping
materials and resources.  Prepare Stakeholders  Risk Analysis and Management
 Stakeholder List, Map and Personas
C Conduct Elicitation  Elicitation Activity  Guide Elicitation Activity  Benchmark and Market Analysis  Customers  Elicitation Results
Plan  Capture Elicitation  Brainstorming  Domain SME (unconfirmed)
The purpose of Conduct Elicitation is to Outcomes  Business Rules Analysis  End User
draw out, explore, and identify  Collaborative Games  Implementation SME
information relevant to the change.  Concept Modelling  Sponsor
 Data Mining  Any Stakeholders
 Data Modelling
 Document Analysis
 Focus Groups
 Interface Analysis
 Interviews
 Mind Mapping
 Observation
 Processing Modelling
 Prototyping
 Workshops
C Confirm Elicitation Results  Elicitation Results  Compare Elicitation Results  Document Analysis  Domain SME  Elicitation Results
(unconfirmed) Against Source Information  Interviews  Any Stakeholders (confirmed)
The purpose of Confirm Elicitation Results is  Compare Elicitation Results  Reviews
to check the information gathered during an Against Other Elicitation  Workshops
elicitation session for accuracy and Results
consistency with other information.
C Communicate Business Analysis  BA Information  Determine Objectives and  Interviews  End User  Business Analysis
Information  Stakeholder Format of Communication  Reviews  Customer Information
Engagement Approach  Communicate Business  Workshops  Domain SME (communicated)
The purpose of Communicate Business Analysis Package  Implementation SME
Analysis Information is to ensure  Tester
stakeholders have a shared understanding of
 Any Stakeholder
business analysis information.
C Manager Stakeholder Collaboration  Stakeholder  Gain Agreement on  Collaborative Games  All Stakeholders  Stakeholder
Engagement Approach Commitments  Lessons Learned Engagement
The purpose of Manage Stakeholder  Business Analysis  Monitor Stakeholder  Risk Analysis and Management
Collaboration is to encourage stakeholders to Performance Engagement  Stakeholder List, Map, or Personas
work towards a common goal. Assessment  Collaboration
10 | P a g e
^J
5. REQUIREMENTS LIFE CYCLE MANAGEMENT (RLCM)

DESCRIPTION
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 analysing 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.
PURPOSE
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.
11 | P a g e
^J

T Trace Requirements  Requirements  Level of Formality  Business Rules Analysis  Customers  Requirements
 Designs  Relationships  Functional Decomposition  Domain SME (traced)
The purpose of Trace Requirements is to  Traceability Repository  Process Modelling  End User  Designs (traced)
ensure that requirements and designs at  Scope Modelling  Implementation SME
different levels are aligned to one another,  Operational Support
and to manage the effects of change to one  Project Manager
level on related requirements.
 Sponsor
 Supplier
 Tester
M Maintain Requirements  Requirements  Maintain Requirements  Business Rules Analysis  Domain SME  Requirements
 Designs  Maintain Attributes  Functional Decomposition  Implementation SME (maintained)
The purpose of Maintain Requirements is to  Reusing Requirements  Process Modelling  Operational Support  Designs
retain requirement accuracy and consistency  Use Cases and Scenarios  Regulator (maintained)
throughout and beyond the change during  User Stories  Tester
the entire requirements life cycle, and to
support reuse of requirements in other
solutions.
P Prioritise Requirements  Requirements  Basis for Prioritisation  Backlog Management  Customer  Requirements
 Designs  Challenges for  Business Cases  End user (prioritised)
The purpose of Prioritize Requirements is to Prioritisation  Decision Analysis  Implementation SME  Designs (prioritised)
rank requirements in the order of relative  Continual Prioritisation  Estimation  Project Manager
importance.  Financial Analysis  Regulator
 Interviews  Sponsor
 Item Tracking
 Prioritisation
 Workshops
A Assessment Requirement Changes  Proposed change  Assessment Formality  Business Cases  Customer  Requirements
 Requirements  Impact Analysis  Business Rules Analysis  Domain SME Change Assessment
The purpose of Assess Requirements Changes  Designs  Impact Resolution  Decision Analysis  End User  Designs Change
is to evaluate the implications of proposed  Document Analysis  Operational Support Assessment
changes to requirements and designs.  Estimation  Project Manager
 Financial Analysis  Regulator
 Interviews  Sponsor
 Item Tracking  Tester
 Workshops
A Approve Requirements  Requirements  Understand Stakeholder  Acceptance and Evaluation Criteria  Customer  Requirements
(verified) Roles  Decision Analysis  Domain SME (approved)
The purpose of Approve Requirements is to  Designs  Conflict and Issue  Item Tracking  End User  Designs (approved)
obtain agreement on and approval of Management  Reviews  Operational Support
requirements and designs for business  Gain Consensus  Workshops  Project Manager
analysis work to continue and/or solution  Track and Communicate  Regulator
construction to proceed. Approval  Sponsor
 Tester
12 | P a g e
^J
6. STRATEGY ANALYSIS (SA)

DESCRIPTION
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. It covers strategic thinking in business analysis,
as well as the discovery or imagining of possible solutions that will enable the enterprise to create greater value for stakeholders, and/or capture more value for itself. 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.
PURPOSE
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.
13 | P a g e
^J

A Analyse Current State  Elicitation Results  Business Needs  Benchmarking and Market Analysis  Customers  Current State
 Needs  Organisational Structure  Business Capability Analysis  Domain SME Description
The purpose of Analyse Current State is to and Culture  Business Model Canvas  End User  Business
understand the reasons why an enterprise  Capabilities and Processes  Business Cases  Implementation SME Requirements
needs to change some aspect of how it  Technology and  Concept Modelling  Operational Support
operates and what would be directly or Infrastructure  Data Mining  Project Manager
indirectly affected by the change.  Policies  Document Analysis  Regulator
 Business Architecture  Financial Analysis  Sponsor
 Internal Assets  Focus Groups  Supplier
 External Influencers  Functional Decomposition  Tester
 Interviews
 Item Tracking
 Lessons Learned
 Metrics and KPIs
 Mind Mapping
 Observation
 Scope Modelling
 SWOT Analysis
 Vendor Assessment
 Workshops
D Define Future State  Business Requirements  Business Goals and  Acceptance and Evaluation Criteria  Customers  Business Objectives
Objectives  Balanced Scorecard  Domain SME  Future State
The purpose of Define Future State is to  Scope of Solution Space  Benchmarking and Market Analysis  End User Description
determine the set of necessary conditions to  Constraints  Brainstorming  Implementation SME  Potential Value
meet the business need.  Organisational Structure  Business Capability Analysis  Operational Support
and Culture  Business Cases  Project Manager
 Capabilities and Processes  Business Model Canvas  Regulator
 Technology and  Decision Analysis  Sponsor
Infrastructure  Decision Modelling  Supplier
 Policies  Financial Analysis  Tester
 Business Architecture  Functional Decomposition
 Internal Assets  Interviews
 Identify Assumptions  Lessons Learned
 Potential Value  Metrics and KPIs
 Mind Mapping
 Prototyping
 Scope Modelling
 SWOT Analysis
14 | P a g e
^J

 Workshops
A Assess Risks  Business Objectives  Unknowns  Brainstorming  Domain SME  Risks Analysis
 Elicitation Results  Constraints, Assumptions  Business Cases  Implementation SME Results
The purpose of Assess Risks is to understand (confirmed) and Dependencies  Decision Analysis  Operational Support
the undesirable consequences of internal and  Influences  Negative Impact to Value  Document Analysis  Project Manager
external forces on the enterprise during a  Potential Value  Risk Tolerance  Financial Analysis  Regulator
transition to, or once in, the future state. An  
Requirements Recommendation  Interviews  Sponsor
understanding of the potential impact of (Prioritised)  Lessons Learned  Supplier
those forces can be used to make a
 Mind Mapping  Tester
recommendation about a course of action.
 Workshops
D Define Change Strategy  Current State  Solution Scope  Balanced Scorecard  Customer  Change Strategy
Description  Gap Analysis  Benchmarking and Market Analysis  Domain SME  Solution Scope
The purpose of Define Change Strategy is to  Future State  Enterprise Readiness  Brainstorming  End User
develop and assess alternative approaches to Description Assessment  Business Capability Analysis  Implementation SME
the change, and then select the recommended  Risk Analysis Results  Change Strategy  Business Cases  Operational Support
approach.  Stakeholder  Transition State and  Business Model Canvas  Project Manager
Engagement Approach Release Planning  Decision Analysis  Regulator
 Estimation  Sponsor
 Financial Analysis  Supplier
 Focus Groups  Tester
 Functional Decomposition
 Interviews
 Lessons Learned
 Mind Mapping
 Scope Modelling
 SWOT Analysis
 Workshops
15 | P a g e
^J
7. REQUIREMENTS ANALYSIS AND DESIGN DEFINITION (RADD)

DESCRIPTION
The Requirements Analysis and Design Definition knowledge area describes the tasks that business analysts perform to structure and Organise 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 realised 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. Both requirements
and designs are important tools used by business analysts to define and guide change. The main difference between requirements and designs is in how they are used and by whom. One person’s designs may be
another person’s requirements. Requirements and designs may be either high-level or very detailed based upon what is appropriate to those consuming the information.
PURPOSE
The business analyst's role in modelling needs, requirements, designs, and solutions is instrumental in conducting thorough analysis and communicating with other stakeholders. The form, level of detail, and what
is being modelled are all dependent on the context, audience, and purpose. Business analysts analyse 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.
16 | P a g e
^J

S Specify and Model Requirements  Elicitation Results (any  Model Requirements  Acceptance and Evaluation Criteria  Any Stakeholder  Requirements
state)  Analyse Requirements  Business Capability Analysis (Specified and
The purpose of Specify and Model  Represent Requirements  Business Model Canvas Modelled)
Requirements is to analyse, synthesize, and and Attributes  Business Rules Analysis
refine elicitation results into requirements  Implement the Appropriate  Concept Modelling
and designs. Level of Abstraction  Data Dictionary
 Data Flow Diagrams
 Data Modelling
 Decision Modelling
 Functional Decomposition
 Glossary
 Interface Analysis
 Non-Functional Requirements
Analysis
 Prototyping
 Roles and Permissions Matrix
 Scope Modelling
 Sequence Diagrams
 Stakeholder List, Map, or Personas
 State Modelling
 Use Cases and Scenarios
 User Stories
V Verify Requirements  Requirements  Characteristics of  Acceptance and Evaluation Criteria  All Stakeholders  Requirements
(Specified and Requirements and Designs  Item Tracking (Verified)
The purpose of Verify Requirements is to Modelled) Quality  Metrics and KPIs
ensure that requirements and designs  Verification Activities  Reviews
specifications and models meet quality  Checklists
standards and are usable for the purpose they
serve.
V Validate Requirements  Requirements  Identify Assumptions  Acceptance and Evaluation Criteria  All Stakeholders  Requirements
(Specified and  Define Measurable  Document Analysis (Validated)
The purpose of Validate Requirements is to Modelled) Evaluation Criteria  Financial Analysis
ensure that all requirements and designs  Evaluate Alignment with  Item Tracking
align to the business requirements and Solution Scope  Metrics and KPIs
support the delivery of needed value.
 Reviews
 Risks Analysis and Management
A Define Requirements Architecture  Information  Requirements Viewpoints  Data Modelling  Domain Subject Matter  Requirements
Management and Views  Functional Decomposition Expert, Implementation Architecture
The purpose of Define Requirements Approach  Template Architectures  Interviews Subject Matter Expert,
Architecture is to ensure that the  Requirements (any  Completeness  Organisational Modelling Project Manager,
requirements collectively support one another state)  Relate and Verify  Scope Modelling Sponsor, Tester
to fully achieve the objectives.  Solution Scope Requirements  Any Stakeholder
 Workshops
Relationships
 Business Analysis
Information Architecture
O Define Design Options  Change Strategy  Define Solution  Benchmarking and Market Analysis  Domain SME  Design Options
17 | P a g e
^J

 Requirements Approaches  Brainstorming  Implementation SME
The purpose of Define Design Options is to (Validated, Prioritised)  Identify Improvement  Document Analysis  Operational Support
define the solution approach, identify  Requirements Opportunities  Interviews  Project Manager
opportunities to improve the business, Architecture  Describe Design Options  Lessons Learned  Supplier
allocate requirements across solution  Mind Mapping
components, and represent design options  Root Cause Analysis
that achieve the desired future state.
 Surveys or Questionnaire
 Workshops
V Analyse Potential Value and  Potential Value  Expected Benefits  Acceptance and Evaluation Criteria  Customer  Solution
Recommend Solution  Design Options  Expected Costs  Backlog Management  Domain SME Recommendation
 Determine Value  Brainstorming  End User
The purpose of Analyse Potential Value and  Assess Design Options and  Business Cases  Implementation SME
Recommend Solution is to estimate the Recommend Solution  Business Model Canvas  Project Manager
potential value for each design option and to
 Decision Analysis  Regulator
establish which one is most appropriate to
 Estimation  Sponsor
meet the enterprise’s requirements.
 Financial Analysis
 Focus Groups
 Interviews
 Metrics and KPIs
 SWOT Analysis
 Workshops
18 | P a g e
^J
8. SOLUTION EVALUATION (SE)

DESCRIPTION
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.
PURPOSE
Solution Evaluation describes tasks that analyse the actual value being delivered, identifies limitations which may be preventing value from being realised, and makes recommendations to increase the value of the
solution. It may include any combination of performance assessments, tests, and experiments, and may combine both objective and subjective assessments of value. Solution Evaluation generally focuses on a
component of an enterprise rather than the entire enterprise.
19 | P a g e
^J

M Measure Solution Performance  Business Objectives  Define Solution  Acceptance and Evaluation Criteria  Customer  Solution
 Implemented Solution Performance Measures  Benchmarking and Market Analysis  Domain SME Performance
The purpose of Measure Solution (external)  Validate Performance  Business Cases  End User Measures
Performance is to define performance Measures  Data Mining  Project Manager
measures and use the data collected to  Collect Performance  Decision Analysis  Sponsor
evaluate the effectiveness of a solution in Measures  Focus Groups  Regulator
relation to the value it brings.
 Metrics and Key Performance
Indicators (KPIs)
 Non-Functional Requirements
Analysis
 Observation
 Prototyping
 Use Cases and Scenarios
A Analyse Performance Measure  Potential Value  Solution Performance  Acceptance and Evaluation Criteria  Domain SME  Solution
 Solution Performance versus Desired Value  Benchmarking and Market Analysis  Project Manager Performance
The purpose of Analyse Performance Measures  Risks  Data Mining  Sponsor Analysis
Measures is to provide insights into the  Trends  Interviews
performance of a solution in relation to the  Accuracy  Metrics and Key Performance
value it brings.  Performance Variances Indicators (KPIs)
 Observation
 Root Case Analysis
L Assess Solution Limitations  Implemented Solution  Identify Internal Solution  Acceptance and Evaluation Criteria  Customer  Solution Limitation
(external) Component Dependencies  Benchmarking and Market Analysis  Domain SME
The purpose of Assess Solution Limitations is  Solution Performance  Investigate Solution  Business Rules Analysis  End User
to determine the factors internal to the Analysis Problems  Data Mining  Regulator
solution that restrict the full realization of  Impact Assessment  Decision Analysis  Sponsor
value.
 Interviews  Tester
 Item Tracking
 Lessons Learned
E Assess Enterprise Limitations  Current State  Enterprise Culture  Benchmarking and Market Analysis  Customer  Enterprise
Description Assessment  Data Mining  Domain SME Limitation
The purpose of Assess Enterprise Limitations  Implemented (or  Stakeholder Impact  Brainstorming  End User
is to determine how factors external to the Constructed) Solution Analysis  Decision Analysis  Regulator
solution are restricting value realization. (external)  Organisational Structure  Document Analysis  Sponsor
 Solution Performance Changes  Interviews
Analysis  Operational Assessment  Item Tracking
 Lessons Learned
 Observation
20 | P a g e
^J

 Roles and Permission Matrix
 SWOT Analysis
 Workshops
R Recommend Actions to Increase  Enterprise Limitation  Adjust Solution  Data Mining  Customer  Recommended
Solution Value  Solution Limitation Performance Measures  Decision Analysis  Domain SME Actions
 Recommendations  Financial Analysis  End User
The purpose of Recommend Actions to  Focus Groups  Regulator
Increase Solution Value is to understand the  Organisational Modelling  Sponsor
factors that create differences between
 Prioritisation
potential value and actual value, and to
recommend a course of action to align them.
21 | P a g e
^J
8. UNDERLYING COMPETENCIES (UC)

DESCRIPTION
The Underlying Competencies chapter provides a description of the behaviours, characteristics, knowledge, and personal qualities that support the practice of business analysis. The underlying competencies
described here are not unique to business analysis. They are described here to ensure readers are aware of the range of fundamental skills required and provide a basis for them to further investigate the skills and
knowledge that will enable them to be accomplished and adaptable business analysts.
These competencies are grouped into six categories:
• Analytical Thinking and Problem Solving,

• Behavioural Characteristics,
• Business Knowledge,
• Communication Skills,
• Interaction Skills, and
• Tools and Technology
Each underlying competency is defined with a purpose, definition, and effectiveness measures.
Competency Name Components

1 Analytical Thinking and Problem Solving  Creative Thinking,
 Decision Making,
Analytical thinking and problem solving skills are required for business  Learning,
analysts to analyse problems and opportunities effectively, identify which  Problem Solving,
changes may deliver the most value, and work with stakeholders to understand  Systems Thinking,
the impact of those changes.  Conceptual Thinking, and
 Visual Thinking
2 Behavioural characteristics  Ethics
 Personal Accountability
Behavioural characteristics are not unique to business analysis but they have  Trustworthiness
been found to increase personal effectiveness in the practice of business  Organisation and Time
analysis. These characteristics exist at the core of every business analyst’s skill Management
set. Each of the behavioural characteristics described here can impact the  Adaptability
outcome of the practitioner's efforts.
3 Business Knowledge  Business Acumen
 Industry Knowledge
Business knowledge is required for the business analyst to perform effectively  Organisation Knowledge
within their business, industry, organisation, solution, and methodology.  Solution Knowledge
Business knowledge enables the business analyst to better understand the  Methodology Knowledge
overarching concepts that govern the structure, benefits, and value of the
situation as it relates to a change or a need.
4 Communication Skills  Verbal
 Non-Verbal
Communication is the act of a sender conveying information to a receiver in a  Written
method which delivers the meaning the sender intended. Active listening skills  Listening
help to deepen understanding and trust between the sender and the receiver.
Effective communication benefits all stakeholders.
5 Interaction Skills  Facilitation
 Leadership and Influencing
Interaction skills are represented by the business analyst's ability to relate,  Teamwork
22 | P a g e
^J
Competency Name Components

cooperate, and communicate with different kinds of people including  Negotiation and Conflict Resolution
executives, sponsors, colleagues, team members, developers, vendors, learning  Teaching
and development professionals, end users, customers, and subject matter
experts (SMEs).
6 Tools and Technology  Office Productivity and Technology
 Business Analysis Tools and
Business analysts use a variety of software applications to support Technology
communication and collaboration, create and maintain requirements  Communications Tools and
artefacts, model concepts, track issues, and increase overall productivity. Technology
23 | P a g e
^J
8. TECHNIQUES
DESCRIPTION
The Techniques chapter provides a high-level overview of the techniques referenced in the Knowledge Areas of the BABOK® Guide. Techniques are methods business analysts use 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. Business analysts apply their experience and
judgment in determining which techniques are appropriate to a given situation and how to apply each technique. This may include techniques that are not described in the BABOK® Guide. As the practice of
business analysis evolves, techniques will be added, changed, or removed from future iterations of the BABOK® Guide. In a number of cases, a set of conceptually similar approaches have been grouped into a single
technique. Any approach within a technique may be used individually or in combination to accomplish the technique's purpose.
Description Elements Strengths Limitations Illustration

1 Acceptance and Evaluation  Value Attributes  Agile methodologies may require  Acceptance criteria may express
Criteria  Assessment that all requirements be expressed contractual obligations and as
in the form of testable acceptance such may be difficult to change
Acceptance criteria are used to criteria. for legal or political reasons.
define the requirements,  Acceptance criteria are necessary  Achieving agreement on
outcomes, or conditions that when the requirements express evaluation criteria for different
must be met in order for a contractual obligations. needs among diverse
solution to be considered  Acceptance criteria provide the stakeholders can be challenging.
acceptable to key stakeholders. ability to assess requirements
Evaluation criteria are the based on agreed upon criteria.
measures used to assess a set of
 Evaluation criteria provide the
requirements in order to choose
ability to assess diverse needs
between multiple solutions.
based on agreed upon criteria, such
as features, common indicators,
local or global benchmarks, and
agreed ratios.
 Evaluation criteria assist in the
delivery of expected return on
investment (ROI) or otherwise
specified potential value.
 Evaluation criteria helps in
defining priorities.
2 Backlog Management  Items in the Backlog  An effective approach to  Large backlogs may become na
 Prioritisation responding to changing cumbersome and difficult to
The backlog is used to record,  Estimation stakeholder needs and priorities manage.
track, and prioritise remaining  Managing Changes because the next work items  It takes experience to be able to
work items. to the Backlog selected from the backlog are break down the work to be done
always aligned with current into enough detail for accurate
Items in the Backlog: stakeholder priorities. estimation.
 use cases,  Only items near the top of the  A lack of detail in the items in the
 user stories, backlog are elaborated and backlog can result in lost
 functional requirements, estimated in detail; items near the information over time.
 non-functional bottom of the backlog reflect lower
requirements, priorities and receive less attention
 designs, and effort.
 customer orders,  Can be an effective communication
 risk items, vehicle because stakeholders can
 change requests, understand what items are about
24 | P a g e
^J

 defects, to be worked on, what items are
 planned rework, scheduled farther out, and which
 maintenance, ones may not be worked on for
 conducting a some time.
presentation, or
 completing a document.
3 Balanced Scorecard  Learning and  Facilitates holistic and balanced  A lack of a clear strategy makes
Growth Dimension planning and thinking. aligning the dimensions
The balanced scorecard is used to  Business Process  Short-, medium-, and long-term difficult.
manage performance in any Dimension goals can be harmonised into  Can be seen as the single tool
business model, organisational  Customer programs with incremental for strategic planning rather
structure, or business process. Dimension success measures. than just one tool to be used in a
 Financial  Strategic, tactical, and operational suite of strategic planning tools.
Dimension teams are more easily aligned in  Can be misinterpreted as a
 Measures or their work. replacement for strategic
Indicators  Encourages forward thinking and planning, execution, and
competitiveness. measurement.
4 Benchmarking and Market  Benchmarking • Benchmarking provides • Benchmarking is time-consuming; Na

Analysis  Market Analysis organisations with information about organisations may not have the
new and different methods, ideas, and expertise to conduct the analysis and
Benchmarking and market tools to improve organisational interpret useful information.
analysis are conducted to performance. • Benchmarking cannot produce
improve organisational • An organisation may use innovative solutions or solutions that
operations, increase customer benchmarking to identify best will produce a sustainable
satisfaction, and increase value to practices by its competitors in order to competitive advantage because it
stakeholders. meet or exceed its competition. involves assessing solutions that
• Benchmarking identifies why similar have been shown to work elsewhere
companies are successful and what with the goal of reproducing them.
processes they used to become • Market analysis can be time-
successful. consuming and expensive, and the
• Market analysis can target specific results may not be immediately
groups and can be tailored to answer available.
specific questions. • Without market segmentation,
• Market analysis may expose market analysis may not produce the
weaknesses within a certain company expected results or may provide
or industry. incorrect data about a competitor's
• Market analysis may identify products or services.
differences in product offerings and
services that are available from a
competitor.
25 | P a g e
^J

5 Brainstorming  Preparation • Ability to elicit many ideas in a short • Participation is dependent on
 Session time period. individual creativity and willingness
Brainstorming is an excellent  Wrap-up • Non-judgmental environment to participate.
way to foster creative thinking enables creative thinking. • Organisational and interpersonal
about a problem. The aim of • Can be useful during a workshop to politics may limit overall
brainstorming is to produce reduce tension between participants. participation.
numerous new ideas, and to • Group participants must agree to
derive from them themes for avoid debating the ideas raised
further analysis. during brainstorming.
6 Business Capability Analysis  Capabilities  Provides a shared articulation of  Requires an organisation to agree
 Using Capabilities outcomes, strategy, and performance, to collaborate on this model.
Business capability analysis  Performance which help create very focused and  When created unilaterally or in a
provides a framework for scoping Expectations aligned initiatives. vacuum it fails to deliver on the
and planning by generating a  Risk Model • Helps align business initiatives goals of alignment and shared
shared understanding of  Strategic Planning across multiple aspects of the understanding.
outcomes, identifying alignment organisation.  Requires a broad, cross–functional
 Capability Maps
with strategy, and providing a • Useful when assessing the ability of collaboration in defining the
scope and Prioritisation filter. an organisation to offer new products capability model and the value
and services. framework.
7 Business Cases  Need Assessment • Provides an amalgamation of the • May be subject to the biases of Na
 Desired Outcomes complex facts, issues, and analysis authors.
A business case provides a  Assess Alternatives required to make decisions regarding • Frequently not updated once
justification for a course of action  Recommended change. funding for the initiative is secured.
based on the benefits to be Solution • Provides a detailed financial analysis • Contains assumptions regarding
realised by using the proposed of cost and benefits. costs and benefits that may prove
solution, as compared to the cost, • Provides guidance for ongoing invalid upon further investigation.
effort, and other considerations to decision making throughout the
acquire and live with that
26 | P a g e
^J

solution. initiative.
8 Business Model Canvas  Key Partnerships • It is a widely used and effective • Does not account for alternative
 Key Activities framework that can be used to measures of value such as social and
A business model canvas  Key Resources understand and optimise business environmental impacts.
describes how an enterprise  Value Proposition models. • The primary focus on value
creates, delivers, and captures  Customer • It is simple to use and easy to propositions does not provide a
value for and from its customers. Relationships understand. holistic insight for business strategy.
 Channels • Does not include the strategic
 Customer Segments purpose of the enterprise within the
 Cost Structure canvas.
 Revenue Streams
9 Business Rules Analysis  Definitional Rules • When enforced and managed by a • Organisations may produce Na
 Behavioural Rules single enterprise-wide engine, changes lengthy lists of ambiguous business
Business rules analysis is used to to business rules can be implemented rules.
identify, express, validate, refine, quickly. • Business rules can contradict one
and Organise the rules that shape • A centralized repository creates the another or produce unanticipated
day-to-day business behaviour ability to reuse business rules across results when combined unless
and guide operational business an Organisation. validated against one another.
decision making. • Business rules provide structure to • If available vocabulary is
govern business behaviours. insufficiently rich, not business-
• Clearly defining and managing friendly, or poorly defined and
business rules allows Organisations to Organised, resulting business rules
make changes to policy without will be inaccurate or contradictory.
altering processes or systems.
10 Collaborative Games  Game Purpose • May reveal hidden assumptions or • The playful nature of the games Na
 Process differences of opinion. may be perceived as silly and make
Collaborative games encourage  Outcome • Encourages creative thinking by participants with reserved
participants in an elicitation  Examples of stimulating alternative mental personalities or cultural norms
activity to collaborate in building Collaborative processes. uncomfortable.
a joint understanding of a Games • Challenges participants who are • Games can be time-consuming and
problem or a solution. normally quiet or reserved to take a may be perceived as unproductive,
more active role in team activities. especially if the objectives or
• Some collaborative games can be outcomes are unclear.
useful in exposing business needs that • Group participation can lead to a
aren't being met. false sense of confidence in the
conclusions reached.
11 Concept Modelling  Noun Concepts • Provide a business-friendly way to • May set expectations too high Na
 Verb Concepts communicate with stakeholders about about how much integration based
A concept model is used to  Other Connections precise meanings and subtle on business semantics can be
organise the business vocabulary distinctions. achieved on relatively short notice.
needed to consistently and • Is independent of data design biases • Requires a specialized skill set
thoroughly communicate the and the often limited business based on the ability to think
knowledge of a domain. vocabulary coverage of data models. abstractly and non-procedurally
• Proves highly useful for white-collar, about know-how and knowledge.
knowledge-rich, decision-laden • The knowledge-and-rule focus
business processes. may be foreign to stakeholders.
27 | P a g e
^J

• Helps ensure that large numbers of • Requires tooling to actively
business rules and complex decision support real-time use of standard
tables are free of ambiguity and fit business terminology in writing
together cohesively. business rules, requirements, and
other forms of business
communication.
12 Data Dictionary  Data Elements • Provides all stakeholders with a • Requires regular maintenance,
 Primitive Data shared understanding of the format otherwise the metadata could
A data dictionary is used to Elements and content of relevant information. become obsolete or incorrect.
standardise a definition of a data  Composite • A single repository of corporate • All maintenance is required to be
element and enable a common Elements metadata promotes the use of data completed in a consistent manner in
interpretation of data elements. throughout the Organisation in a order to ensure that stakeholders can
consistent manner. quickly and easily retrieve the
information they need. This requires
time and effort on the part of the
stewards responsible for the
accuracy and completeness of the
data dictionary.
• Unless care is taken to consider the
metadata required by multiple
scenarios, it may have limited value
across the enterprise.
13 Data Flow Diagrams  Externals (Entity, • May be used as a discovery • Using data flow diagrams for
Source, Sink) technique for processes and data or as large-scale systems can become
Data flow diagrams show where  Data Store a Technique for the verification of complex and difficult for
data comes from, which activities  Process functional decompositions or data stakeholders to understand.
process the data, and if the output  Data Flow models. • Different methods of notation with
results are stored or utilized by • Are excellent ways to define the different symbols could create
another activity or external scope of a system and all of the challenges pertaining to
entity. systems, interfaces, and user interfaces documentation.
that attach to it. Allows for estimation • Does not illustrate a sequence of
of the effort needed to study the work. activities.
• Most users find these data flow • Data transformations (processes)
diagrams relatively easy to say little about the process or
understand. stakeholder.
• Helps to identify duplicated data
elements or misapplied data elements.
• Illustrates connections to other
systems.
• Helps define the boundaries of a
system.
• Can be used as part of system
documentation.
• Helps to explain the logic behind the
data flow within a system.
14 Data Mining  Requirements • Reveal hidden patterns and create • Applying some techniques without Na
28 | P a g e
^J

Elicitation useful insight during analysis— an understanding of how they work
Data mining is used to improve  Data Preparation: helping determine what data might be can result in erroneous correlations
decision making by finding useful Analytical Dataset useful to capture or how many people and misapplied insight.
patterns and insights from data.  Data Analysis might be impacted by specific • Access to big data and to
 Modelling suggestions. sophisticated data mining tool sets
Techniques • Can be integrated into a system and software may lead to accidental
 Deployment design to increase the accuracy of the misuse.
data. • Many techniques and tools require
• Can be used to eliminate or reduce specialist knowledge to work with.
human bias by using the data to • Some techniques use advanced
determine the facts. math in the background and some
stakeholders may not have direct
insights into the results. A perceived
lack of transparency can cause
resistance from some stakeholders.
• Data mining results may be hard to
deploy if the decision making they
are intended to influence is poorly
understood.
15 Data Modelling  Entity or Class • Can be used to define and • Following data modelling
 Attribute communicate a consistent vocabulary standards too rigorously may lead to
A data model describes the  Relationship or used by domain subject matter experts models that are unfamiliar to people
entities, classes or data objects Association and implementation subject matter without a background in IT.
relevant to a domain, the  Diagrams experts. • May extend across multiple
attributes that are used to • Review of a logical data model helps functional areas of the Organisation,
describe them, and the to ensure that the logical design of and so beyond the business
relationships among them to persistent data correctly represents the knowledge base of individual
provide a common set of business need. stakeholders.
semantics for analysis and • Provides a consistent approach to
implementation. analysing and documenting data and
its relationships.
• Offers the flexibility of different
levels of detail, which provides just
enough information for the respective
audience.
• Formal modelling of the information
held by the business may expose new
requirements as inconsistencies are
identified.
29 | P a g e
^J

16 Decision Analysis  Components of • Provides business analysts with a • The information to conduct proper
Decision Analysis prescriptive approach for determining decision analysis may not be
Decision analysis formally  Decision Matrices alternate options, especially in available in time to make the
assesses a problem and possible  Decision Trees complex or uncertain situations. decision.
decisions in order to determine  Trade-offs • Helps stakeholders who are under • Many decisions must be made
the value of alternate outcomes pressure to assess options based on immediately, without the luxury of
under conditions of uncertainty. criteria, thus reducing decisions based employing a formal or even informal
on descriptive information and decision analysis process.
emotions. • The decision maker must provide
• Requires stakeholders to honestly input to the process and understand
assess the importance they place on the assumptions and model
different alternate outcomes in order limitations. Otherwise, they may
to help avoid false assumptions. perceive the results provided by the
• Enables business analysts to business analyst as more certain than
construct appropriate metrics or they are.
introduce relative rankings for • Analysis paralysis can occur when
outcome evaluation in order to directly too much dependence is placed on
compare both the financial and non- the decision analysis and in
financial outcome evaluation criteria. determining probabilistic values.
• Some decision analysis models
require specialized knowledge (for
example, mathematical knowledge in
probability and strong skills with
decision analysis tools).
17 Decision Modelling  Types of Models and • Decision models are easy to share • Adds a second diagram style when
Notations with stakeholders, facilitate a shared modelling business processes that
Decision modelling shows how understanding, and support impact contain decisions. This may add
repeatable business decisions are analysis. unnecessary complexity if the
made. • Multiple perspectives can be shared decision is simple and tightly
and combined, especially when a coupled with the process.
diagram is used. • May limit rules to those required
• Simplifies complex decision making by known decisions and so limit the
by removing business rules capture of rules not related to a
management from the process. known decision.
• Assists with managing large • Defining decision models may
numbers of rules in decision tables by allow an Organisation to think it has
grouping rules by decision. This also a standard way of making decisions
helps with reuse. when it does not. May lock an
• These models work for rules-based Organisation into a current-state
automation, data mining, and decision-making approach.
predictive analytics, as well as for • Cuts across Organisational
manual decisions or business boundaries, which can make it
intelligence projects. difficult to acquire any necessary
sign-off.
• May not address behavioural
business rules in a direct fashion.
• Business terminology must be
clearly defined and shared
definitions developed to avoid data
quality issues affecting automated
30 | P a g e
^J

decisions.
18 Document Analysis  Preparation • Existing source material may be • Existing documentation may be Na
 Document Review used as a basis for analysis. out of date or invalid (incorrect,
Document analysis is used to and Analysis • The business analyst does not need missing information, unreadable, un-
elicit business analysis  Record Findings to create content. reviewed or unapproved).
information, including • Existing sources, although possibly • Authors may not be available for
contextual understanding and outdated, can be used as a point of questions.
requirements, by examining reference to determine what is current • Primarily helpful only for
available materials that describe and what has changed. evaluating the current state, via
either the business environment • Results can be used to validate review of as-is documentation.
or existing Organisational assets. against the results of other • If there is a wide range of sources,
requirements elicitation techniques. the effort may be very time-
• Findings can be presented in formats consuming and lead to information
that permit ease of review and reuse. overload and confusion.
19 Estimation  Methods (top-down, • Estimates provide a rationale for an • Estimates are only as accurate as Na
bottom up, assigned budget, time frame, or size of the level of knowledge about the
Estimation is used by business parametric, rough a set of elements. elements being estimated. Without
analysts and other stakeholders to order of magnitude, • Without an estimate, teams making a Organisation or local knowledge,
forecast the cost and effort rolling wave, Delphi, change may be provided an unrealistic estimates can vary widely from the
involved in pursuing a course of PERT), budget or schedule for their work. actual values determined later.
action.  Accuracy of the • Having a small team of • Using just one estimation method
Estimate knowledgeable individuals provide an may lead stakeholders to have
 Sources of estimate by following a defined unrealistic expectations.
Information technique generally results in a closer
(analogous, org. predictor of the actual value than if an
history, expert estimate was made by one individual.
judgment) • Updating an estimate throughout a
 Precision and work cycle, in which the estimated
Reliability of elements are refined over time,
Estimates incorporates knowledge and helps
 Contributors to ensure success.
Estimates
31 | P a g e
^J

20 Financial Analysis  Cost of the Change • Financial analysis allows executive • Some costs and benefits are
 Total Cost of decision makers to objectively difficult to quantify financially.
Financial analysis is used to Ownership (TCO) compare very different investments • Because financial analysis is
understand the financial aspects  Value Realization from different perspectives. forward looking, there will always be
of an investment, a solution, or a  Cost-Benefit Analysis • Assumptions and estimates built some uncertainty about expected
solution approach.  Financial into the benefits and costs, and into the costs and benefits
Calculations financial calculations, are clearly stated • Positive financial numbers may
so that they may be challenged or give a false sense of security—they
approved. may not provide all the information
• It reduces the uncertainty of a required to understand an initiative.
change or solution by requiring the
identification and analysis of factors
that will influence the investment.
• If the context, business need, or
stakeholder needs change during a
change initiative, it allows the business
analyst to objectively re-evaluate the
recommended solution.
21 Focus Groups  Focus Group • The ability to elicit data from a • In a group setting, participants Na
Objective group of people in a single session may be concerned about issues of
A focus group is a means to elicit  Focus Group Plan saves both time and costs as compared trust or may be unwilling to discuss
ideas and opinions about a  Participants to conducting individual interviews sensitive or personal topics.
specific product, service, or  Discussion Guide with the same number of people. • Data collected about what people
opportunity in an interactive  Assign a Moderator • Effective for learning people's say may not be consistent with how
group environment. The and Recorder attitudes, experiences, and desires. people actually behave.
participants, guided by a • Active discussion and the ability to • If the group is too homogeneous
 Conduct the Focus
moderator, share their ask others questions creates an their responses may not represent
Group
impressions, preferences, and environment in which participants can the complete set of requirements.
needs.  After the Focus
Group consider their personal view in • A skilled moderator is needed to
relation to other perspectives. manage group interactions and
• An online focus group is useful discussions.
when travel budgets are limited and • It may be difficult to schedule the
participants are distributed group for the same date and time.
geographically. • Online focus groups limit
• Online focus group sessions can be interaction between participants.
recorded easily for playback. • It is difficult for the moderator of
an online focus group to determine
attitudes without being able to read
body language.
• One vocal participant could sway
the results of the focus group.
32 | P a g e
^J

22 Functional Decomposition  Decomposition • Makes complex endeavours possible • Missing or incorrect information at
Objectives by breaking down complex problems the time decomposition is performed
Functional decomposition helps  Subjects of into feasible parts. may later cause a need to revise the
manage complexity and reduce Decomposition • Provides a structured approach to results of decomposition partially or
uncertainty by breaking down  Level of building a shared understanding of entirely.
processes, systems, functional Decomposition complex matters among a diverse • Many systems cannot be fully
areas, or deliverables into their  Representation of group of stakeholders. represented by simple hierarchical
simpler constituent parts and Decomposition • Simplifies measurement and relationships between components
allowing each part to be analysed estimation of the amount of work because the interactions between
Results
independently. involved in pursuing a course of components cause emergent
action, defining scope of work, and characteristics and behaviours.
defining process metrics and • Every complex subject allows
indicators. multiple alternative decompositions.
Exploring all alternatives can be a
challenging and time-consuming
task, while sticking with a single
alternative may disregard important
opportunities and result in a
suboptimal solution.
• Performing functional
decomposition may involve deep
knowledge of the subject and
extensive collaboration with diverse
stakeholders.
23 Glossary A term is included in the • A glossary promotes common • A glossary requires an owner to Na
glossary when: understanding of the business domain perform timely maintenance,
A glossary defines key terms • the term is unique to a and better communication among all otherwise it becomes outdated and
relevant to a business domain. domain, stakeholders. may be ignored.
• there are multiple • Capturing the definitions as part of • It may be challenging for different
definitions for the term, an enterprise's documentation stakeholders to agree on a single
• the definition implied provides a single reference and definition for a term.
is outside of the term's encourages consistency.
common use, or • Simplifies the writing and
• there is a reasonable maintenance of other business analysis
chance of information including but not limited
misunderstanding. to requirements, business rules, and
change strategy.
24 Interface Analysis  Preparing for • By engaging in interface analysis • Does not provide insight into other
Identification early on, increased functional coverage aspects of the solution since the
Interface analysis is used to  Conduct Interface is provided. analysis does not assess the internal
identify where, what, why, when, Identification • Clear specification of the interfaces components.
how, and for whom information  Define Interfaces provides a structured means of
is exchanged between solution allocating requirements, business
components or across solution rules, and constraints to the solution.
boundaries. • Due to its broad application, it
avoids over analysis of fine detail.
25 Interviews  Interview Goal • Encourages participation by and • Significant time is required to plan Na
 Potential establishes rapport with stakeholders. for and conduct interviews.
An interview is a systematic Interviewees • Simple, direct technique that can be • Requires considerable commitment
approach designed to elicit  Interview Questions used in a variety of situations. and involvement of the participants.
33 | P a g e
^J

business analysis information  Interview Logistics • Allows the interviewer and • Training is required to conduct
from a person or group of people  Interview Flow participant to have full discussions effective interviews.
by talking to the interviewee(s),  Interview Follow-Up and explanations of the questions and • Based on the level of clarity
asking relevant questions, and answers. provided during the interview, the
documenting the responses. The • Enables observations of non-verbal resulting documentation may be
interview can also be used for behaviour. subject to the interviewer's
establishing relationships and • The interviewer can ask follow-up interpretation.
building trust between business and probing questions to confirm their • There is a risk of unintentionally
analysts and stakeholders in own understanding. leading the interviewee.
order to increase stakeholder • Maintains focus through the use of
involvement or build support for clear objectives for the interview that
a proposed solution. are agreed upon by all participants
and can be met in the time allotted.
• Allows interviewees to express
opinions in private that they may be
reluctant to express in public,
especially when interview results are
kept confidential.
26 Item Tracking  Item Record • Ensures concerns around • If not careful, the copious Na
 Item Management stakeholder requirements are recording of data about items may
Item tracking is used to capture  Metrics captured, tracked, and resolved to the outweigh any benefits realised.
and assign responsibility for stakeholder’s satisfaction. • It may use time that could be better
issues and stakeholder concerns • Allows stakeholders to rank the spent on other efforts and
that pose an impact to the importance of outstanding items. stakeholders could become mired in
solution. details and statistics.
27 Lessons Learned Sessions can include a • Useful in identifying opportunities • Honest discussion may not occur if Na
review of: or areas of improvement. participants try to assign blame
The purpose of the lessons learned • business analysis • Assists in building team morale after during these sessions.
process is to compile and activities or deliverables, a difficult period. • Participants may be reluctant to
document successes, • the final solution, • Reinforces positive experiences and document and discuss problems.
opportunities for improvement, service, or product, successes. • Proactive facilitation may be
failures, and recommendations • automation or • Reduces risks for future actions. required to ensure that the
for improving the performance of technology that was • Provides tangible value or metrics as discussions remain focused on
future projects or project phases. introduced or a result of the effort. solutions and improvement
eliminated, • Recognises strengths or opportunities.
• impact to shortcomings with the project
Organisational structure, methodology, or tools that
processes, were used.
• performance
expectations and results,
• positive or negative
variances,
• root causes impacting
performance results, and
• recommendations for
behavioural approaches.
28 Metrics and Key Performance  Indicators • Establishing a monitoring and • Gathering excessive amounts of Na
Indicators (KPIs)  Metrics evaluation system allows stakeholders data beyond what is needed will
 Structure to understand the extent to which a result in unnecessary expense in
Metrics and key performance  Reporting solution meets an objective, as well as collecting, analysing, and reporting.
34 | P a g e
^J

indicators measure the how effective the inputs and activities It will also distract project members
performance of solutions, solution of developing the solution (outputs) from other responsibilities. On Agile
components, and other matters of were. projects, this will be particularly
interest to stakeholders. • Indicators, metrics, and reporting relevant.
also facilitate Organisational • A bureaucratic metrics program
alignment, linking goals to objectives, fails from collecting too much data
supporting solutions, underlying and not generating useful reports
tasks, and resources. that will allow timely action. Those
charged with collecting metric data
must be given feedback to
understand how their actions are
affecting the quality of the project
results.
• When metrics are used to assess
performance, the individuals being
measured are likely to act to increase
their performance on those metrics,
even if this causes sub-optimal
performance on other activities.
29 Mind Mapping  Main Topic • Can be used as an effective • Can be misused as a brainstorming
 Topics collaboration and communication tool. tool, and the related documenting of
Mind mapping is used to  Sub-topics • Summarizes complex thoughts, ideas and creating associations may
articulate and capture thoughts,  Branches ideas, and information in a way that inhibit idea generation.
ideas, and information.  Keywords shows the overall structure. • A shared understanding of a mind
 Colour • Associations and sub-topics facilitate map can be difficult to communicate.
 Images understanding and decision making.
• Enable creative problem solving by
articulating associations and
generating new associations.
• Can be helpful in preparing and
delivering presentations.
30 Non-Functional  Categories of Non- • Clearly states the constraints that • The clarity and usefulness of a non- Na
Requirements Analysis Functional apply to a set of functional functional requirement depends on
Requirements requirements. what the stakeholders know about
Non-functional requirements  Measurement of • Provides measurable expressions of the needs for the solution and how
analysis examines the Non-Functional how well the functional requirements well they can express those needs.
requirements for a solution that Requirements must perform, leaving it to the • Expectations of multiple users may
define how well the functional  Measurement of functional requirements to express be quite different, and getting
requirements must perform. It Non-Functional what the solution must do or how it agreement on quality attributes may
specifies criteria that can be used Requirements must behave. This will also have a be difficult because of the users'
to judge the operation of a system strong influence on whether the subjective perception of quality. For
rather than specific behaviours solution is accepted by the users. example, what might be 'too fast' to
(which are referred to as the one user might be 'too slow' to
functional requirements). another.
35 | P a g e
^J

• A set of non-functional
requirements may have inherent
conflicts and require negotiation. For
example, some security requirements
may require compromises on
performance requirements.
• Overly strict requirements or
constraints can add more time and
cost to the solution, which may have
negative impacts and weaken
adoption by users.
• Many non-functional requirements
are qualitative and therefore may be
difficult to be measured on a scale,
and may garner a degree of
subjectivity by the users as to how
they believe the particular
requirements ultimately meet their
needs.
31 Observation  Observation • Observers can gain realistic and • May be disruptive to the Na
Objectives practical insight about the activities performance of the participant and
Observation is used to elicit  Prepare for and their tasks within an overall the overall Organisation.
information by viewing and Observation process. • Can be threatening and intrusive to
understanding activities and  Conduct the • Instances of informally performed the person being observed.
their context. It is used as a basis Observation Session tasks as well as any workarounds can • While being observed, a
for identifying needs and  Confirm and Present be identified. participant may alter their work
opportunities, understanding a Observation Results • Productivity can be viewed first- practices.
business process, setting hand and realistically compared • Significant time is required to plan
performance standards, against any established performance for and conduct observations.
evaluating solution performance, standards or metrics. • Not suitable for evaluating
or supporting training and • Recommendations for improvement knowledge-based activities since
development. are supported by objective and these are not directly observable.
quantitative evidence.
32 Organisational Modelling  Types of • Organisational models are common • Organisational models are
Organisational in most Organisations. sometimes out of date.
Organisational modelling is used Models • Including an Organisational model • Informal lines of authority,
to describe the roles,  Roles in business analysis information influence, and communication not
responsibilities, and reporting  Interfaces allows team members to provide reflected in the org chart are more
structures that exist within an  Organisational support. Future projects may benefit difficult to identify and may conflict
Organisation and to align those Charts from knowing who was involved in with the Organisational chart.
structures with the this project and what their role
 Influencers
Organisation's goals. entailed.
36 | P a g e
^J

33 Prioritisation  Grouping • Facilitates consensus building and • Some stakeholders may attempt to
 Ranking trade-offs and ensures that solution avoid difficult choices and fail to
Prioritisation provides a  Time value is realised and initiative recognise the necessity for making
framework for business analysts Boxing/Budgeting timelines are met. trade-offs.
to facilitate stakeholder decisions  Negotiation • The solution team may
and to understand the relative intentionally or unintentionally try to
importance of business analysis influence the result of the
information. Prioritisation process by
overestimating the difficulty or
complexity of implementing certain
requirements.
• Metrics and key performance
indicators are often not available
when prioritizing business analysis
information; therefore, a
stakeholder’s perspective of the
importance may be subjective.
34 Process Analysis  Identify Gaps and • Ensures solutions address the right • Can be time-consuming.
Areas to Improve issues, minimizing waste. • There are many techniques and
Process analysis assesses a  Identify Root Cause • Many different techniques and methodologies in process analysis. It
process for its efficiency and  Generate and methodologies can be used and can be challenging to decipher which
effectiveness, as well as its ability Evaluate Options provide teams with great flexibility in to use and how rigorously to follow
to identify opportunities for  Common Methods approach. them, given the scope and purpose.
change. • May prove ineffective at process
improvement in knowledge or
decision intensive processes.
37 | P a g e
^J

35 Process Modelling  Types of Process • Appeals to the basic human • To many people in IT, a formal
Models and understanding of sequential activities. process model tends to reflect an
Process modelling is a Notations • Most stakeholders are comfortable older and more document-heavy
standardized graphical model with the concepts and basic elements approach to software development.
used to show how work is carried of a process model. Therefore, project time is not
out and is a foundation for • The use of levels can accommodate allocated to developing a process
process analysis. the different perspectives of various model, especially of the current state
stakeholder groups. or problem domain.
• Effective at showing how to handle a • Can become extremely complex
large number of scenarios and parallel and unwieldy if not structured
branches. carefully. This is especially true if
• Can help identify any stakeholder business rules and decisions are not
groups that may have otherwise been managed separately from the
overlooked. process.
• Facilitates the identification of • Complex processes can involve
potential improvements by many activities and roles; this can
highlighting “pain points” in the make them almost impossible for a
process structure (i.e. process single individual to understand and
visualisation). ‘sign off’.
• Likely to have value in its own right. • Problems in a process cannot
They provide documentation for always be identified by looking at a
compliance purposes and can be used high-level model. A more detailed
by business stakeholders for training model with reference to metadata
and coordination of activities. (such as path frequency, cost, and
• Can be used as a baseline for time factors) is usually required. It is
continuous improvement. often necessary to engage with
• Ensures labelling consistency across stakeholders directly to find the
artefacts. operational problems they have
• Provides transparency and clarity to encountered while working with a
process owners and participants on process.
activity responsibilities, sequence and • In a highly dynamic environment
hand-overs. where things change quickly, process
models can become obsolete.
• May prove difficult to maintain if
the process model only serves as
documentation, as stakeholders may
alter the process to meet their needs
without updating the model.
36 Prototyping  Prototyping • Provides a visual representation for • If the system or process is highly Na
Approach (throw the future state. complex, the prototyping process
Prototyping is used to elicit and away, evolutionary) • Allows for stakeholders to provide may become bogged down with
validate stakeholder needs  Prototyping input and feedback early in the design discussion of 'how' rather than
through an iterative process that Examples process. ‘what’, which can make the process
creates a model or design of  Prototyping Methods • When using throw-away or paper take considerable time, effort, and
requirements. It is also used to prototyping methods, users may feel facilitation skill.
optimize user experience, to more comfortable being critical of the • Underlying technology may need
evaluate design options, and as a mock-up because it is not polished and to be understood or assumed in
basis for development of the final release-ready. order to initiate prototyping.
business solution. • A narrow yet deep vertical • If the prototype is deeply elaborate
prototype can be used for technical and detailed, stakeholders may
38 | P a g e
^J

feasibility studies, proof of concept develop unrealistic expectations for
efforts, or to uncover technology and the final solution. These can range
process gaps. from assumed completion dates to
higher expectations of performance,
reliability, and usability.
• Stakeholders may focus on the
design specifications of the solution
rather than the requirements that any
solution must address. This can, in
turn, constrain the solution design.
Developers may believe that they
must provide a user interface that
precisely matches the prototype,
even if more elegant technology and
interface approaches exist.
37 Reviews  Objectives • Can help identify defects early in the • Rigorous team reviews take time
 Techniques work product life cycle, eliminating and effort. Thus, only the most
Reviews are used to evaluate the  Participants the need for expensive removal of critical work products might be
content of a work product. defects discovered later in the life reviewed using inspection or formal
cycle. walkthrough techniques.
• All parties involved in a review • Informal reviews by one or two
become engaged with the final reviewers are practical in terms of
outcome; they have a vested interest in the effort required, but they provide
a quality result. less assurance of removing all
• Desk checks and pass around significant defects than using a larger
reviews can be performed by a team and more formal process.
reviewer at a convenient time, rather • For desk checks and pass around
than interrupting work in progress to reviews it may be difficult for the
attend a meeting. author to validate that an
independent review was done by
each participant.
• If review comments are shared and
discussed via e-mail there may be
many messages to process, which
makes it difficult for the author to
resolve disagreements or differences
in suggested changes.
39 | P a g e
^J

38 Risk Analysis and  Risk Identification • Can be applied to strategic risks • The number of possible risks to
Management  Analysis which affect long-term value of the most initiatives can easily become
 Evaluation enterprise, tactical risks which affect unmanageably large. It may only be
Risk analysis and management  Treatment the value of a change, and operational possible to manage a subset of
identifies areas of uncertainty risks which affect the value of a potential risks.
that could negatively affect value, solution once the change is made. • There is the possibility that
analyses and evaluates those • An Organisation typically faces significant risks are not identified.
uncertainties, and develops and similar challenges on many of its
manages ways of dealing with the initiatives. The successful risk
risks. responses on one initiative can be
useful lessons learned for other
initiatives.
• The risk level of a change or of a
solution could vary over time.
Ongoing risk management helps to
recognise that variation, and to re-
evaluate the risks and the suitability of
the planned responses.
39 Roles and Permissions Matrix  Identifying Roles • Provides procedural checks and • Need to recognise the required
 Identifying Activities balances, as well as data security, by level of detail for a specific initiative
A roles and permissions matrix is  Identifying restricting individuals from or activity; too much detail can be
used to ensure coverage of Authorities performing certain actions. time-consuming and not provide
activities by denoting  Refinements • Promotes improved review of value, too little detail can exclude
responsibility, to identify roles, to transaction history, in that audit logs necessary roles or responsibilities.
discover missing roles, and to can capture details about any assigned
communicate results of a planned authorities at the time.
change. • Provides documented roles and
responsibilities for activities.
40 Root Cause Analysis  The Fishbone • Helps to maintain an objective • Works best when the business
Diagram perspective when performing cause- analyst has formal training to ensure
Root cause analysis is used to  The Five Whys and-effect analysis. the root causes, not just symptoms of
identify and evaluate the • Enables stakeholders to specify an the problem, are identified.
underlying causes of a problem. effective solution at the appropriate • May be difficult with complex
points for corrective action. problems; the potential exists to lead
to a false trail and/or dead–end
conclusion.
40 | P a g e
^J

41 Scope Modelling  Objectives • A scope model facilitates agreement • An initial, high-level model can Na
 Scope of Change and as a basis for: lack a sufficient level of granularity,
Scope models define the nature of Context • defining contractual obligations, particularly for boundary elements,
one or more limits or boundaries  Level of Detail • estimating the project effort, that is needed to ensure clear scope
and place elements inside or  Relationships • justifying in-scope/out-of-scope identification.
outside those boundaries.  Assumptions decisions in requirements analysis, • Once a scope is defined, changing
 Scope Modelling and it may be difficult due to political
Results • assessing the completeness and reasons and contractual obligations.
impact of solutions. Meanwhile, many factors can affect
the scope validity before the targets
are achieved. Such factors as wrong
initial assumptions, situation change,
evolution of stakeholder needs, or
technology innovations may cause a
need for revising the scope partially
or entirely.
• Traditional scope models cannot
address common complex
boundaries, such as a horizon (a
boundary that is completely
dependent on the position of the
stakeholder).
42 Sequence Diagrams  Lifeline • Shows the interaction between the • Time and effort can be wasted
 Activation Box objects of a system in the chronological creating a complete set of sequence
Sequence diagrams are used to  Message order that the interactions occur. diagrams for each use case of a
model the logic of usage scenarios • Shows the interaction between the system, which may not be necessary.
by showing the information objects in a visual manner that allows • Have historically been used for
passed between objects in the the logic to be validated by modelling system flows and may be
system through the execution of stakeholders with relative ease. considered too technical in other
the scenario. • Use cases can be refined into one or circumstances.
more sequence diagrams in order to
provide added detail and a more in-
depth understanding of a business
process.
43 Stakeholder List, Map, or  Stakeholder Lists • Identifies the specific people who • Business analysts who are Stakeholder Matrix
Personas  Stakeholder Map must be engaged in requirements continuously working with the same
 Responsibility elicitation activities. teams may not utilize the
Stakeholder lists, maps, and (RACI) Matrix • Helps the business analyst plan stakeholder analysis and
personas assist the business  Personas - A persona collaboration, communication, and management technique because they
analyst in analysing stakeholders is defined as a fictional facilitation activities to engage all perceive change as minimal within
and their characteristics. This character or archetype stakeholder groups. their respective groups.
analysis is important in ensuring that exemplifies the • Useful to understand changes in • Assessing information about a
that the business analyst way a typical user impacted groups over time. specific stakeholder representative,
identifies all possible sources of interacts with a such as influence and interest, can be
requirements and that the product. Personas are complicated and may feel politically
stakeholder is fully understood so helpful when there is a risky.
decisions made regarding desire to understand
stakeholder engagement,
41 | P a g e
^J

collaboration, and the needs held by a
communication are the best group or class of users.
choices for the stakeholder and for
the success of the initiative.
Onion Diagram
RACI
42 | P a g e
^J
44 State Modelling  State • Identifies business rules and • Is usually only used to understand
 State Transition information attributes that apply to the and communicate about information
State modelling is used to  State Diagram entity being modelled. entities that are perceived to be
describe and analyse the different  State Tables • Identifies and describes the activities complex; simple entities may be
possible states of an entity within that apply to the entity at different understood without the time and
a system, how that entity changes states of the entity. effort required to build a state model.
from one state to another, and • Is a more effective documentation • Building a state model appears
what can happen to the entity and communication tool than plain simple at the start, but achieving a
when it is in each state. text, especially if the entity being consensus among domain SMEs
described has more than a few states, about the details required by the
transitions, and conditions governing model can be difficult and time-
those transitions. consuming.
• A high degree of precision about
states and transitions is required to
build a state diagram; some domain
SMEs and business analysis
practitioners are uncomfortable
43 | P a g e
^J

trying to describe such a level of
detail.
45 Survey or Questionnaire  Prepare • Quick and relatively inexpensive to • To achieve unbiased results, Na
 Distribute the Survey administer. specialized skills in statistical
A survey or questionnaire is used or Questionnaire • Easier to collect information from a sampling methods are needed when
to elicit business analysis  Document the larger audience than other techniques surveying a subset of potential
information—including Results such as interviews. respondents.
information about customers, • Does not typically require significant • The response rates may be too low
products, work practices, and time from the respondents. for statistical significance.
attitudes—from a group of people • Effective and efficient when • Use of open-ended questions
in a structured way and in a stakeholders are geographically requires more analysis.
relatively short period of time. dispersed. • Ambiguous questions may be left
• When using closed-ended questions, unanswered or answered incorrectly.
surveys can be effective for obtaining • May require follow-up questions
quantitative data for use in statistical or more survey iterations depending
analysis. on the answers provided.
• When using open-ended questions,
survey results may yield insights and
opinions not easily obtained through
other elicitation techniques.
46 SWOT Analysis Na • Is a valuable tool to aid in • The results of a SWOT analysis
understanding the Organisation, provide a high-level view; more
SWOT analysis is a simple yet product, process, or stakeholders. detailed analysis is often needed.
effective tool used to evaluate an • Enables business analysts to direct • Unless a clear context is defined for
Organisation's strengths, the stakeholders’ focus to the factors the SWOT analysis the result may be
weaknesses, opportunities, and that are important to the business. unfocused and contain factors which
threats to both internal and are not relevant to the current
external conditions. situation.
44 | P a g e
^J

47 Use Cases and Scenarios  Use Case Diagram • Use case diagrams can clarify scope • The flexibility of the use case
 Use Case Description and provide a high-level description format may lead to
Use cases and scenarios describe understanding of requirements. information being embedded that
how a person or system interacts • Use case descriptions are easily would be better captured using other
with the solution being modelled understood by stakeholders due to techniques such as user interface
to achieve a goal. their narrative flow. interactions, non-functional
• The inclusion of a desired goal or requirements, and business rules.
outcome ensures that the business • Decisions and the business rules
value of the use case is articulated. that define them should not be
• Use case descriptions articulate the recorded directly in use cases, but
functional behaviour of a system. managed separately and linked from
the appropriate step.
• The flexible format of use cases
may result in capturing
inappropriate or unnecessary detail
in the attempt to show every step or
interaction.
• Use cases intentionally do not
relate to the design of the solution
and as a result, significant effort may
be required in development to map
use case steps to software
architecture.
48 User Stories  Title (optional) • Easily understandable by In general, user stories are intended Na
 Statement of Value stakeholders. as a tool for short-term capture and
A user story represents a small,  Conversation • Can be developed through a variety Prioritisation of requirements and
concise statement of functionality  Acceptance Criteria of elicitation techniques. not for long-term knowledge
or quality needed to deliver value • Focuses on value to stakeholders. retention or to provide a detailed
to a specific stakeholder. • A shared understanding of the analysis. Neglecting this principle
business domain is enhanced through can lead to the following
collaboration on defining and issues:
exploring user stories. • This conversational approach can
• Tied to small, implementable, and challenge the team since they do not
testable slices of functionality, which have all the answers and detailed
facilitates rapid delivery and frequent specifications upfront.
customer feedback. • Requires context and visibility; the
team can lose sight of the big picture
if stories are not traced back through
validation or supplemented with
higher level analysis and visual
artefacts.
• May not provide enough
documentation to meet the need for
governance, a baseline for future
work, or stakeholder expectations.
Additional documentation may be
required.
49 Vendor Assessment  Knowledge and • Increases the chances of the • May be consuming in regards to Na
Expertise Organisation to develop a productive time and resources.
A vendor assessment assesses the  Licensing and and fair relationship with a suitable • Does not prevent risk of failure as
45 | P a g e
^J

ability of a vendor to meet Pricing Models and reliable vendor, and to improve the partnership evolves.
commitments regarding the  Vendor Market long-term satisfaction with the • Subjectivity may bias the
delivery and the consistent Position decision. evaluation outcome.
provision of a product or service.  Terms and
Conditions
 Vendor Experience,
Reputation, and
Stability
50 Workshops  Prepare for the • Can be a means to achieve • Stakeholder availability may make Na
Workshop agreement in a relatively short period it difficult to schedule the workshop.
Workshops bring stakeholders  Workshop Roles of time. • The success of the workshop is
together in order to collaborate on  Conduct the • Provides a means for stakeholders to highly dependent on the expertise of
achieving a predefined goal. Workshop collaborate, make decisions, and gain a the facilitator and knowledge of the
 Post Workshop mutual understanding. participants.
Wrap-up • Costs are often lower than the cost of • Workshops that involve too many
performing multiple interviews. participants can slow down the
• Feedback on the issues or decisions workshop process. Conversely,
can be provided immediately by the collecting input from too few
participants. participants can lead to the
overlooking of needs or issues that
are important to some stakeholders,
or to the arrival at decisions that
don't represent the needs of the
majority of the stakeholders.
46 | P a g e
^J
9. PERSPECTIVES
DESCRIPTION
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, and
• Business Process Management.
These perspectives do not presume to represent all the possible perspectives from which business analysis is practiced. The perspectives discussed in the BABOK® Guide represent some of the most common views
of business analysis at the time of writing.
While the business analysis tasks detailed in the BABOK® Guide are intended to be applicable across all areas of business analysis, they are also pertinent to each specific business analysis perspective. Perspectives
provide ways to approach business analysis work in a more focused manner suitable to the context. The perspectives help interpret and understand the knowledge areas and tasks in the BABOK® Guide from the
lens in which one is currently working. Each perspective follows a common structure:
• Change Scope,
• Business Analysis Scope,
• Methodologies, Approaches, and Techniques,
• Underlying Competencies, and
• Impact on Knowledge Areas.
Perspective Change Scope Methodologies, Approaches and Illustration

Reference Models/Techniques
Breadth of Change Depth of Change
1 Agile Agile approaches are Agile principles and  Crystal Clear Na
used to address a practices are often  Disciplined Agile Delivery
The Agile Perspective highlights the variety of needs in an successfully applied in (DAD)
unique characteristics of business enterprise. The most initiatives where:  Dynamic Systems
analysis when practiced in the common use of agile • there is a clear Development Method (DSDM)
context of agile environments. practices is in software commitment from the  Evolutionary Project
Agile is about having a flexible development projects. customer and engagement Management (Evo)
mindset, embodied in a set of values However, many by empowered subject  Extreme Programming (XP)
and principles and exhibited by a organisations have matter experts (SMEs),  Feature Driven Development
variety of complementary practices. started to apply agile • the business need or (FDD)
Agile initiatives involve constant principles to non- proposed solution is
change. Business analysts working  Kanban
software related change complex or complicated,  Scaled Agile Framework®
on agile initiatives continually such as process and • business needs are
reassess, adapt, and adjust their (SAFe™)
engineering and changing or unknown and  Scrum
efforts and tactics. Business analysts
business improvement. are still emerging.  Behaviour Driven
conduct analysis and deliver work
Initiatives using agile Development (BDD)
products at the last responsible
approaches can be
moment to continually allow  Kano Analysis
undertaken within a
flexibility for change; detailed  Lightweight Documentation
single department or
analysis work is not done ahead of  MoSCoW Prioritisation
time, but just in time to be effectively can span across
 Personas
47 | P a g e
^J

utilized by the agile team. multiple teams,  Planning Workshop
Agile business analysis ensures that departments, and  Purpose Alignment Model
information is available to the agile divisions of an  Real Options
team at the right level of detail at the organisation.  Relative Estimation
right time.  Retrospectives
Business analysts help agile teams
 Story Decomposition
answer these questions:
 Story Mapping
• What need are we trying to satisfy?
 Storyboarding
• Is that need worth satisfying?
• Should we deliver something to  Value Stream Mapping
satisfy that need?
• What is the right thing to do to
deliver that need?
2 The Business Intelligence A key objective of a  Executive level  Descriptive analytics
Perspective business intelligence  Management level  Predictive analytics
system is the consistent  Process level  Prescriptive analytics
The Business Intelligence Perspective definition and usage of
highlights the unique characteristics information throughout
of business analysis when practiced an organisation by
in the context of transforming, establishing a 'single
integrating, and enhancing data. point of truth' for
The focus of business intelligence is diverse business data.
the transformation of data into value-
added information: where to source
it, how to integrate it, and how to
enhance and deliver it as analytic
insight to support business decision
making.
Business intelligence initiatives
apply data-centric system
architectures as well as technologies
and tools to deliver reliable,
consistent, high-quality information
that enables stakeholders to better
manage strategic, tactical, and
operational performance.
3 The Information Technology  Create a new The nature of business  Predictive Na
Perspective organisational analysis activities in an IT  Adaptive
capability environment depend on a
The Information Technology  Achieve an variety of solution impact
Perspective highlights the organisational factors:
characteristics of business analysis objective by • What happens to the
when undertaken from the point of enhancing an business if this system
view of the impact of the change on existing capability shuts down?
information technology systems.  Facilitate an • What happens if the
When working in the information operational system performance
technology (IT) discipline, business degrades?
improvement
analysts deal with a wide range of • What business
 Maintain an
complexity and scope of activities. capabilities and processes
existing
48 | P a g e
^J

Initiatives may be as small as minor information depend on the IT system?
bug fixes and enhancements, or as technology system • Who contributes to those
large as re-engineering the entire  Repair a broken capabilities and processes?
information technology information • Who uses those
infrastructure for an extended technology system capabilities and processes?
enterprise. Business analysts are
called upon to work with this diverse
level of knowledge and skills among
stakeholders to deliver valuable
solutions to their IT needs.
Business analysts working in an

information technology environment
consider their tasks in light of three
key factors:
• Solution impact: the value and risk
of the solution to the business.
• Organisational maturity: the
formality and flexibility of the
organisational change processes.
• Change scope: the breadth, depth,
complexity, and context for the
proposed change.
4 The Business Architecture Business architecture A business architecture Reference Models: Na
Perspective may be performed: effort may focus on the  Association for Cooperative
executive level of the Operations Research and
The Business Architecture • across the enterprise enterprise to support Development (ACORD)
Perspective highlights the unique as a whole, strategic decision making,  Business Motivation Model
characteristics of business analysis • across a single line of or on the management (BMM)
when practiced in the context of business within the level to support the  Control Objectives for IT
business architecture. enterprise (defining the execution of initiatives. (COBIT)
Business architecture models the architecture of one of While business architecture  eTOM and FRAMEWORX
enterprise in order to show how the enterprise's business provides important  Federal Enterprise Architecture
strategic concerns of key stakeholders models), or context, it does not usually Service Reference Model (FEA
are met and to support ongoing • across a single operate at the operational SRM)
business transformation efforts. functional division. decision or process level;
Business architecture provides  Information Technology
instead, it assesses Infrastructure Library (ITIL®)
architectural descriptions and views,
processes at the level of the  Process Classification
referred to as blueprints, to provide a
value stream. Framework (PCF)
common understanding of the
organisation for the purpose of  Supply Chain Operations
aligning strategic objectives with Reference (SCOR)
tactical demands. The discipline of  Value Reference Model (VRM)
business architecture applies
analytical thinking and architectural Techniques:
principles to the enterprise level. The  Archimate®
solutions may include changes in the  Business Motivation Model
business model, operating model, (BMM)
organisational structure, or drive  Business Process Architecture
other initiatives.
49 | P a g e
^J

 Capability Map
 Customer Journey Map
 Enterprise Core Diagram
 Information Map
 Organisational Map
 Project Portfolio Analysis
 Roadmap
 Service-Oriented Analysis
 The Open Group Architecture
 Framework (TOGAF®)
 Value Mapping
 Zachman Framework
5 The Business Process  Designing Business analysts use BPM Framework:

Management Perspective  Modelling frameworks to facilitate the  ACCORD
 Execution and analysis and deep  Enhanced Telecommunications
The Business Process Management Monitoring understanding of the Operations Map (eTOM)
Perspective highlights the unique  Optimizing organisation's processes.  Governments Strategic
characteristics of business analysis BPM frameworks are sets Reference Model (GSRM)
when practiced in the context of or descriptions of processes  Model based and Integrated
developing or improving business for a generic organisation, Process Improvement (MIPI)
processes. specific industry,  Process Classification
Business Process Management professional area, or type Framework(PCF)
(BPM) is a management discipline of value stream. BPM
and a set of frameworks define Methodologies:
enabling technologies that:
particular levels of  Adaptive Case Management
• focuses on how the organisation
processes throughout the (ACM)
performs work to deliver value across
organisation's process  Business Process Reengineering
multiple functional areas to
architecture. (BPR)
customers and stakeholders,
• aims for a view of value delivery  Continuous Improvement (CI)
that spans the entire organisation,  Lean
and  Six Sigma
• views the organisation through a  Theory Of Constraints (TOC)
process-centric lens.  Total Quality Management
(TQM)
Techniques:
 Cost Analysis
 Critical to Quality (CTQ)
 Cycle-time Analysis
 Define Measure Analyze Design
Verify (DMADV )
 Define Measure Analyze
Improve Control (DMAIC)
 Drum-Buffer-Rope (DBR)
 Failure Mode and Effect
Analysis (FMEA)
50 | P a g e
^J

 House of Quality/ Voice of
Customer
 Inputs, Guide, Outputs,
Enablers (IGOE)
 Kaizen Event
 Process Simulation
 Suppliers Inputs Process
Outputs Customers (SIPOC)
 Theory of Constraints (TOC)
Thinking Processes
 Value Added Analysis
 Value Stream Analysis
 Who What When Where Why
(5Ws)
51 | P a g e
^J
CONTENT REVIEWERS
The following individuals reviewed and proof read the contents in this document:
1. Tia Rameka, CBAP (New Zealand)

2. Dave Hosking, CBAP (New Zealand)
3. Robert Fall, CBAP (New Zealand)
4. Yvonne Bishop, BA Capability Practitioner (New Zealand)
5. Leah Lapuz, Senior Business Analyst, Spark New Zealand
Disclaimer: The information provided hereof came from a purchased copy of BABOK
v3.0 by IIBA (www.iiba.org), with the sole purpose of helping individuals understand the
BABOK guidelines in a simplified format that can be used for personal, professional and
educational purposes.
IIBA®, the IIBA® logo, BABOK® and Business Analysis Body of Knowledge® are
registered trademarks owned by International Institute of Business Analysis. CBAP® is a
registered certification mark owned by International Institute of Business Analysis.
52 | P a g e

Babok v3 0 Framekwork

Uploaded by

Copyright:

Available Formats

Babok v3 0 Framekwork

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Babok v3 0 Framekwork

Uploaded by

Copyright:

Available Formats

The Guide to the Business Analysis

Body of Knowledge (BABOK)™

Author: Joseph Lapuz, CBAP, CSM

STRUCTURE OF THE BABOK GUIDE

Each task in the BABOK® Guide is presented in the following format:

2. BUSINESS ANALYSIS KEY CONCEPTS

Requirements Classification Schema Requirements and Design Cycle

 Non-functional requirements or quality of service requirements: do not relate directly to the

BUSINESS ANALYSIS TASKS BY KNOWLEDGE AREA

3. BUSINESS ANALYSIS PLANNING AND MONITORING (BAPM)

 Plan the execution of business analysis tasks

Tasks Inputs Elements Techniques Stakeholders Outputs

Tasks Inputs Elements Techniques Stakeholders Outputs

4. ELICITATION AND COLLABORATION (EC)

 Explore, identify and document stakeholder needs.

Tasks Inputs Elements Techniques Stakeholders Outputs

5. REQUIREMENTS LIFE CYCLE MANAGEMENT (RLCM)

The requirements life cycle:

• begins with the representation of a business need as a requirement,

Tasks Inputs Elements Techniques Stakeholders Outputs

6. STRATEGY ANALYSIS (SA)

Tasks Inputs Elements Techniques Stakeholders Outputs

Tasks Inputs Elements Techniques Stakeholders Outputs

7. REQUIREMENTS ANALYSIS AND DESIGN DEFINITION (RADD)

Tasks Inputs Elements Techniques Stakeholders Outputs

Tasks Inputs Elements Techniques Stakeholders Outputs

8. SOLUTION EVALUATION (SE)

Tasks Inputs Elements Techniques Stakeholders Outputs

Tasks Inputs Elements Techniques Stakeholders Outputs

8. UNDERLYING COMPETENCIES (UC)

These competencies are grouped into six categories:

• Analytical Thinking and Problem Solving,

Competency Name Components

Competency Name Components

Description Elements Strengths Limitations Illustration

Description Elements Strengths Limitations Illustration

4 Benchmarking and Market  Benchmarking • Benchmarking provides • Benchmarking is time-consuming; Na

Description Elements Strengths Limitations Illustration

Description Elements Strengths Limitations Illustration

Description Elements Strengths Limitations Illustration

Description Elements Strengths Limitations Illustration

Description Elements Strengths Limitations Illustration

Description Elements Strengths Limitations Illustration

Description Elements Strengths Limitations Illustration

Description Elements Strengths Limitations Illustration

Description Elements Strengths Limitations Illustration

Description Elements Strengths Limitations Illustration

Description Elements Strengths Limitations Illustration

Description Elements Strengths Limitations Illustration

Description Elements Strengths Limitations Illustration

Description Elements Strengths Limitations Illustration

Description Elements Strengths Limitations Illustration

Description Elements Strengths Limitations Illustration

Description Elements Strengths Limitations Illustration

Description Elements Strengths Limitations Illustration

Description Elements Strengths Limitations Illustration

Description Elements Strengths Limitations Illustration

Description Elements Strengths Limitations Illustration

The perspectives included in the BABOK® Guide are:

Perspective Change Scope Methodologies, Approaches and Illustration