BABoK V3 Techniques PDF

BABoK® V3 Techniques 2017 Edition
Copyright notice
All rights reserved.
IIBA®, BABOK®, CBAP®, CCBA®, ECBA® are registered Trademarks of

International Institute of Business Analysis, Canada.
All trademarks of copyrights mentioned herein are the possession

of their respective owners. We make no claim of ownership by the
mention of products that contain these marks.
Contents of this document should not be disclosed to any

unauthorized person. This document may not, in whole or in part,
be reduced, reproduced, stored in a retrieval system, translated,
or transmitted in any form or by any means, electronic or
mechanical.
This publication used in assisting aspirants for CBAP®

examination. It does not warrant that use of this publication will
ensure passing the CBAP®, CCBA®, ECBA® examination.
2006-17 ©Adaptive Processes Think BA. Think Adaptive! Page 2 of 221

Introduction
As the book title suggests, this book is a guidebook on BABoK V3

techniques for the aspirants of the CBAP®, CCBA® and ECBA®
examination from IIBA®, Canada. We value your time and hence the
book is designed to be extremely specific – Help you pass the
certification examination with least possible effort.
This book is authored by qualified CBAP® trainers who have helped

many other participants clear the CBAP® and CCBA® examination in
the very first attempt.
They are also regular trainers for CBAP®, CCBA®, ECBA®

preparations in both corporate and open-hose workshops and have
trained participants across the world – USA, Australia, Middle
East, South East Asia, Europe and Africa.
Now CBAP®, CCBA®, ECBA® examinations are based on BABOK® v3.0 and
so is this book. This book presents BABOK® techniques in a
simplified manner. This book will soon be followed by an audio
book and elearning to further assist participants.
Feedbacks and suggestions on the book
We will be glad and thankful if you can share your feedbacks and
suggestions on the book. Please send your feedbacks and
suggestions to Info@AdaptiveProcesses.com.

TABLE OF CONTENTS
Copyright notice............................................... 2
Introduction .................................................. 3
Feedbacks and suggestions on the book .......................... 3
About Adaptive Processes Consulting ............................ 7
Unique benefits of working with us ............................. 8
Our key clients................................................ 8
Adaptive workshops catalogue ................................... 9
1. PREFACE AND INTRODUCTION .................................. 12
1What is business analysis? ................................... 12

1What is IIBA®?............................................... 14
1.4 What and Why of CCBA® ..................................... 19
1.5 What and Why of CBAP® ..................................... 22
2. BUSINESS ANALYSIS TECHNIQUES .............................. 28
2.1 Acceptance and Evaluation criteria ...................... 28

2.2 Backlog management ...................................... 30
2.3 Balance score card ...................................... 33
2.4 Benchmarking and Market Analysis ........................ 36
2.5 Brainstorming ........................................... 40
2.6 Business Capability Analysis ............................ 43
2.7 Business Cases .......................................... 47
2.8 Business Model Canvas ................................... 51
2.9 Business rules analysis ................................. 58
2.10 Collaborative Games ..................................... 61
2.11 Concept Modelling ....................................... 64
2.12 Data dictionary ......................................... 66
2.13 Data Flow Diagrams (DFDs) ............................... 69

2.14 Data Mining............................................. 74
2.15 Data Modelling .......................................... 79
2.16 Decision analysis ....................................... 86
2.17 Decision modeling ....................................... 90
2.18 Document analysis ....................................... 95
2.19 Estimation.............................................. 98
2.20 Financial analysis ..................................... 103
2.21 Focus groups........................................... 106
2.22 Functional decomposition ............................... 112
2.23 Glossary............................................... 115
2.24 Interface analysis ..................................... 117
2.25 Interviews............................................. 120
2.26 Item tracking .......................................... 126
2.27 Lessons Learned ........................................ 128
2.28 Metrics and Key Performance Indicators (KPIs) .......... 130
2.29 Mind map............................................... 135
2.30 Non-functional requirements analysis ................... 137
2.31 Observations........................................... 141
2.32 Organizational model ................................... 145
2.33 Prioritization ......................................... 148
2.34 Process analysis ....................................... 150
2.35 Process modeling ....................................... 155
2.36 Prototyping............................................ 160
2.37 Reviews................................................ 164
2.38 Risk analysis .......................................... 170
2.39 Roles and permissions matrix ........................... 173
2.40 Root cause analysis (RCA) .............................. 176
2.41 Scope models........................................... 180

2.42 Stakeholder List, Map, or Personas ..................... 184
2.43 State Modelling ........................................ 190
2.44 Sequence diagram ....................................... 194
2.45 Survey and questionnaires .............................. 197
2.46 SWOT .................................................. 203
2.47 Use cases and scenarios ................................ 205
2.48 User story............................................. 211
2.49 Vendor assessment ...................................... 214
2.50 Workshops.............................................. 218

About Adaptive Processes Consulting
Adaptive Processes is a leading Key facts

global player helping its clients
 Consulting, training,
improve their business analysis
staffing and products for
and requirements engineering
business analysis and
capabilities and practices.
requirements engineering.
 200+ person-years
consulting experience.
 200+ Clients across the

globe.
 10+ Fortune 500 clients.
 200+ workshops in India,

US, Thailand, Philippines,
Malaysia.

Unique benefits of working with us
Our key clients
Govern
ment

Adaptive workshops catalogue
Category Course Name
Business analysis Certified Business analyst Professional

(CBAP® ) (Endorsed by IIBA®, Canada)
Business analysis Certification of Competency in Business

Analysis (CCBA®) (Endorsed by IIBA®,
Canada)
Business analysis Entry Certificate in Business Analysis

(ECBA®) (Endorsed by IIBA®, Canada)
Business analysis Certified Professional in Requirements

Engineering(CPRE-FL®) (Endorsed by
IREB, Germany)
Business analysis Elicitation techniques
Business analysis Requirements modeling using UML
Business analysis Behavioral skills for BAs
Business analysis The ACE business analysis program
Agile Certified Agile Practitioner
Agile Introduction to Agile and Scrum

BSC Balance Score Card
CMMI CMMI for Services
CMMI Introduction to CMMI for Development
CMMI CMMI Implementation Workshop
CoBIT Introduction to COBIT
Excel Excel for Executive Managers
ISO 27001 Certified ISO 27001 Implementer
ISO 27001 Certified ISO 27001 Internal Auditor
Project Management Introduction to MS-Project
Project Management Project Management Basics
Project Management Program Management Professional
Project Management Stakeholder Management
Six Sigma Six Sigma Green Belt
Project Management Certified Software Team Lead
Software Engineering Configuration Management

Software Engineering Good Programming Practices
Software Engineering Introduction to Software Quality
Software Engineering Requirements Management
Software Engineering Software Engineering Principles
Software Engineering Introduction to Software QA
Software Engineering Software Reviews
Software Engineering Software Testing Principles
Software Engineering Software Metrics
Software Engineering Statistics for Project managers
Software Engineering Statistical Process Control
Please note that we modify course catalog based on changing

business needs. For the latest information, always refer to our
web-site, www.AdaptiveProcesses.com.

1. Preface and Introduction Your notes:
1What is business analysis?
BABOK® definition: business analysis is the

practice of enabling change in an enterprise
by defining needs and recommending solutions
that deliver value to stakeholders.
BA enables an enterprise to articulate its

needs, rationale for change and to design and
describe solutions that can deliver value.
BA can be performed within a project or across

the enterprise. It can be to understand the
current state, define future state and
determine activities required for transition.
BA can be performed from various perspectives

like agile, business intelligence, information
technology, business architecture, business
process management etc.
Who is a Business analyst?
A person who performs business analysis tasks

mentioned in BABOK® is considered a Business
analyst irrespective of his job title or
organization role.

Business analysts elicit actual needs of

stakeholders, not simply capture expressed
desires. They are also responsible for
discovering and analysing information from
various sources.
Common job titles for Business analysts are

business architect, system analyst,
requirements engineer, process analyst,
management consultant, product manager etc.
Business analysts help organizations define

the optimal solutions for their needs, given
the set of constraints (including time,
budget, regulations and others).
Key activities Business analysts perform are:

1What is IIBA®?
International Institute of Business Analysis

(IIBA® ) was founded in Toronto, Canada in
October of 2003 to support the business
analysis community by:
 Creating and developing awareness and

recognition of the value and contribution
of the business analyst.
 Defining the business analysis body of

knowledge (BABOK®).
 Providing a forum for knowledge sharing

and contribution to the business analysis
profession.
 Publicly recognizing and certifying

qualified practitioners through an
internationally acknowledged certification
program.
1.3 What is BABOK®?
BABOK® contains a description of generally

accepted practices in the field of business
analysis. It gives guidance on the skills and
knowledge that a business analyst MUST
possess.

Contents of BABOK® have been verified

thoroughly by practitioners.
BABOK® does not mandate that practices

described should be followed under all
circumstances.
Any set of practices MUST be tailored to the

specific business analysis conditions.
The goal of revising BABOK® v2.0 and coming up

with the new version v3.0 are as follows:
 Incorporate new concepts and practices
 Address the evolving scope of the

profession
 Incorporate lessons learnt form

practitioners
 Enhance readability and usability of the

guide and consistency and quality of
texts and illustrations
 Improve consistency with other generally

accepted business analysis standards

1.4 What and Why of ECBA®
ECBA® stands for Entry Certificate in Business

Analysis, 1st level certification provided by
International Institute of Business Analysis
(IIBA®), Canada (www.IIBA.org).
Following are some of the benefits of becoming

a ECBA® :
 Be recognized for your competency in

business analysis.
 Business analysis is the fastest growing
career opportunity for IT professionals.
 People with domain experience can move into
IT sector by becoming a business analyst.
 Better job prospects.
 Better salary.
Target Audience for ECBA®
ECBA examination targets the following

audience:
 Individuals entering the business analysis

profession:
 Students enrolled in business analysis
academic programs
 New graduates
 Professionals transitioning careers
 Functional managers who are not Business

analysts but manage them
Eligibility for ECBA®
 High school (i.e., 12 years of education is

required. In India, this will be higher
secondary school) and above.
 Prior business analysis-related work is not
required.
 Professional development: 21 hours of
verifiable BABOK® coursework in the last 4
years. Adaptive Processes is an authorized
EEP of IIBA®, its trainings provide desired
PDUs for the ECBA® certification
examination.
 References: Not required.
 Prior knowledge area expertise is not
required.
 Signed code of conduct is required.
ECBA® Question pattern
 This will be a knowledge based examination.

 Basic multiple choice questions
 50 questions
 Testing knowledge
 1.5 hours

Examination weightage – KA wise
Business Analysis Knowledge
Domain % Distribution
Business Analysis & the

2.5%
business analysis
Professional
Underlying Competencies 5%
Business Analysis Key 5%

Concepts
Techniques 12.5%
BABOK® Guide Knowledge Areas
Business Analysis Planning

5%
and Monitoring
Elicitation and 20%

Collaboration
Requirements Life Cycle 20%

Management
Strategy Analysis 5%

Requirements Analysis and 24%

Design Definition
Solution Evaluation 1%
1.5 What and Why of CCBA®
CCBA® stands for Certification of Capability

in Business Analysis, 2nd level certification
provided by International Institute of
Business Analysis (IIBA®), Canada
(www.IIBA.org).

a CCBA® :

business analysis.
 Business analysis is the fastest growing
career opportunity for IT professionals.
 Better salary.
Target Audience for CCBA®

CCBA examination targets the following

audience:
 Current CCBAs
 Level 1s
 Those who have fallen into the role
 Developing BAs
 Hybrid Business analysts (PMs, testers, QA,
change managers, designers)
 Product owners/managers
 Non-BA consultants
 Trainers
Eligibility for CCBA®

 Minimum 3750 hours of Business analysis-
related work in the last 7 years.

PDUs for the CCBA® certification
examination.
 References: 2 references.
 Minimum 900 hours in each of the 2
knowledge areas or 500 hrs in each of 4

KAs.
CCBA® Question pattern
 This will be a scenario based examination.

 Situations will be described in 2-4
sentences
 Multiple choice answers
 130 questions
 3 hours
Business Analysis Planning

12%
and Monitoring
Elicitation and 20%

Collaboration
Requirements Life Cycle 18%

Management
Strategy Analysis 12%

Requirements Analysis and 32%

Design Definition
Solution Evaluation 6%
1.6 What and Why of CBAP®
CBAP® stands for Certified business analysis

Professional, 3rd level certification provided
by International Institute of business
analysis (IIBA®), Canada (www.IIBA.org).

a CBAP® :

business analysis.
 BA is the fastest growing career
opportunity for IT professionals.
 Better salary.
Target Audience for CBAP®
CBAP examination targets the following

audience:
 Seasoned BAs
 BA Consultants
 Trainers
Eligibility for CBAP®

 Minimum 7500 hours of Business analysis-
related work in the last 10 years.

PDUs for the CBAP® certification
examination.
 References: 2 references from a career

manager, client (internal or external) or
CBAP®.
 Minimum 900 hours in each of the 4

knowledge areas.
You can download a business analysis

experience calculator at no cost from our
eStore.
CBAP® Question pattern

 This will be a case and scenario based
examination.
 Longer cases (1-1.5 pages) of information
 Multiple questions about the case
 Single choice answers
 120 questions
 3.5 hours
BA planning and monitoring 14%
Elicitation and 12%

collaboration
Requirements life cycle 15%

management
Strategy analysis 15%
Requirements analysis and 30%

design definition
Solution evaluation 14%
Additional Information
 Application expires within 1 year from

approval
 3 exams can be taken within a year without

any waiting time in between
Certification process
 Become an IIBA® member at www.IIBA.org.

 Benefits include free, unlimited access to
the BABOK® and 500+ online books, local,
national and international networking
opportunities and ability to influence the
growth and direction of the business
analysis profession.
 Take required training from an IIBA® EEP,
such as Adaptive Processes
(www.AdaptiveProcesses.com).
 Download BABOK® and start reading.
 Join a study group, or start one.
 Begin preparing for the application.
Preparing the application
 Begin the application at least 2 weeks

before you plan to apply.
 It can take anywhere from 6-10 hours to
complete.
 Download and use Adaptive business analysis
experience calculator.
 Apply within 6 months of when you plan to
write.
 You can download the CBAP® handbook for a
detailed application process at IIBA® web-
site.
Tips for the certification examination
 Please keep it in your mind that CBAP® is a

test on your knowledge of BABOK®, not your
knowledge on business analysis practice as
you following in your workplace.
 Answers need to be as per BABOK®, not what
you may think appropriate.
 Questions are pretty much straight forward.
 No long descriptive questions. However,
there are questions with diagrams.
 No long answers. All questions had single
statement answers.
 Avoid answers which are prescriptive.
BABOK® does not provide any specific level
of rigor to be adopted in any activity.
 Be careful with answers which say something
should be 100% or 0% - It’s very hard to
find such digital options in life.
 Avoid terms which are not mentioned in
BABOK®. Such a term can be technically
correct, for example a specific company may
have a Wok Breakdown System – however
BABOK® does not have any such term. BABOK®
term is Work breakdown structure.
 Multiple options can be technically
correct; choose the BEST option.
 Do not trust long lists.

Knowledge areas
Knowledge areas represent areas of specific

business analysis expertise.
There are 6 knowledge area in BABoK:
1. Business analysis planning and monitoring

2. Elicitation and collaboration
3. Requirements life cycle management
4. Strategy analysis
5. Requirements analysis and design definition
6. Solution evaluation

2. Business Analysis Techniques
2.1 Acceptance and Evaluation criteria
Acceptance and evaluation criteria define

measures used for assessing and comparing
solutions or alternative designs.
Acceptance criteria describe minimal set of

requirements which MUST be met for a solution
to be worth implementing.
Acceptance criteria are typically used when

evaluation ONLY one possible solution and is
expressed as pass or fail.
Evaluation criteria define a set of measures to

rank multiple solutions options, solutions or
solution components based on their value for
stakeholders.
This allows for a range of possible scores.
Requirements for Acceptance and evaluation

criteria
 Comprises of value attributes: Solution

characteristics such as performance,
applicability, scalability, reliability etc.
which determine value for stakeholders.

 Acceptance criteria MUST be expressed in a

testable form.
 Evaluation criteria MUST be able to measure

whether the features can provide value to
stakeholders.
Strengths
 Agile methodologies require requirements to

be expressed as testable acceptance
criteria.
 Necessary when requirements express

contractual obligations.
 Evaluation criteria help in assessing

diverse needs, defining priorities and
delivering estimated RoI.
Limitations
 Difficult to change for legal or political

reasons if part of contractual obligations.
 Achieving consensus on criteria is

challenging.

2.2 Backlog management
Backlog record, track and prioritize remaining

work items.
Backlog management refers to the planned

approach manage remaining work for the project.
In a managed backlog, items at the top have the

highest business value and the highest
priority.
Review backlog periodically.
There more than one backlog to manage backlogs

at different levels.
Items in the backlog
Backlog items can be user story, use case,

defect, change request, risk etc.
Prioritization
Items in the backlog are prioritized relative

to each other.
One may use multi-phased prioritization

approach to backlog items.

Estimation
High priority backlog items are described in

more detail with an accurate estimate of
relative size and complexity.
Do minimal amount of work on low priority

backlog items; just enough to be able to
understand the work involved to complete it.
Managing Changes to the Backlog
Add and re-order backlog when new or changed

requirements are identified.
Remove items when items are completed, decided

to remove them.
Removed items can be re-added to the backlog.
Strengths
 Effective in changing stakeholder needs and

priorities.
 ONLY items near the top of the backlog are

elaborated and estimated in detail.
 Effectively communicates what items need to

be worked on and what items can wait.

Limitations
 Large backlogs are difficult to manage.
 Needs experience to break down items for

accurate estimate.
 Lack of details can result in lost

information over time.

2.3 Balance score card
A strategic planning and management tool to

measure organizational performance beyond
traditional financial measures.
This includes tangible objectives, specific

measures and targeted outcomes derived from an
organization's vision and strategy.
Balanced business scorecards can be used at

multiple levels within an organization.
Learning and Growth Dimension
Measures regarding employee training and

learning, product and service innovation and
corporate culture.
Business Process Dimension
Measures indicating how well the enterprise is

operating and if its products meet customer
needs.
Customer Dimension
Measures on customer focus, satisfaction and

delivery of value.

Financial Dimension
Measures indicating profitability, revenue

growth and added economic value.
Measures or Indicators
2 basic types of measures or indicators are:
Lagging indicators that provide results of

actions already taken.
Leading indicators that provide information

about future performance.
Measures to be meaningful, they should be

quantitative, linked to strategy and easily
understood by all stakeholders.
Allows the organization to establish monitoring

and measuring of progress against objectives
and to adapt strategy as needed.
Strengths
 Facilitates holistic and balanced planning

and thinking.
 Encourages forward thinking and

competitiveness.

Limitations
 Lack of clear strategy can make aligning the

dimensions difficult.
 Perceived as ONLY tool for strategic

planning rather than just one tool among
many strategic planning tools.
 Misinterpreted as a replacement for

strategic planning, execution and
measurement.

2.4 Benchmarking and Market Analysis

Benchmark studies are conducted to compare
organizational practices against the best-in-
class practices from competitor enterprises, in
government, or from industry associations or
standards.
Market analysis involves researching customers

in order to determine the products and services
that they need or want, the factors that
influence their decisions to purchase, and the
competitors that exist in the market. Market
analysis can also help determine when to exit a
market.
Benchmarking
Benchmarking includes:
1. identifying the areas to be studied,
2. identifying benchmarking sources
3. conducting a survey/ visiting enterprises,
4. determining gaps between current and best
practices, and
5. Developing a project proposal to implement

best practices.
Market Analysis
Market Analysis requires that business
analysts:
1. identify customers and understand their
preferences,
2. identify opportunities that may increase
value to stakeholders,
3. identify competitors and investigate their
operations,
4. look for trends in the market, anticipate
growth rate, and estimate potential
profitability,
5. define appropriate business strategies,
6. gather market data,
7. use existing resources such as company
records, research studies, and books and
apply that information to the questions at
hand, and
8. Review data to determine trends and draw
conclusions.

Strengths
 Benchmarking provides organizations with

information about new and different methods,
ideas, and tools to improve organizational
performance.
 Market analysis can target specific groups
and can be tailored to answer specific
questions.
 Market analysis can expose weaknesses within
a certain company or industry.
 Market analysis can identify differences in
product offerings and services that are
available from a competitor.
Limitations
 Benchmarking is time-consuming;
organizations may not have the expertise to
conduct the analysis and interpret useful
information.
 Benchmarking cannot produce innovative
solutions or solutions
 Market analysis can be time-consuming and
expensive, and the results may not be

immediately available.
 Without market segmentation, market analysis
may not produce the expected results or may
provide incorrect data about a competitor's
products or services.

2.5 Brainstorming
Brainstorming is a technique where one or
group of stakeholders deliberate on an idea
with the aim to produce numerous new ideas in
a non-judgmental environment, and to derive
themes for further analysis. Brainstorming
encourages participants to use new ways of
looking at things to heighten creativity.
Steps for Brainstorming
Prepare for brainstorming
 Develop a clear and concise definition of

the area of interest.
 Determine a time limit for the group to

generate ideas; larger the group, allocate
more time.
 Identify facilitator, and participants.
 Aim for 6 to 8 participants representing

range of backgrounds, and experiences with
the topic.
 Set expectations with participants, and get

their buy into the process.
 Establish criteria for evaluating, and

rating ideas.
Conduct session
 Share new ideas without any discussion,

criticism or evaluation.
 Visibly record all ideas.
 Encourage participants to be creative, share

exaggerated ideas, and build on others’
ideas.
 Don’t limit the number of ideas as the goal

is to elicit as many as possible within the
time period.
Wrap-up
 Upon reaching the time limit, discuss, and

evaluate ideas using pre-determined
evaluation criteria.
 Create a condensed list of ideas, combine

ideas where appropriate, and eliminate
duplicates.

 Rate the ideas.
 Distribute final list of ideas to

appropriate parties.
Strengths
 Excellent way to foster creative thinking as

ideas are not judged.
 Facilitated properly, it can be fun,

engaging, and productive.
 Ability to elicit many ideas in a short time

period.
 Useful during a workshop to reduce tension

between participants.
Limitations
 Dependent on participants’ creativity, and

willingness to participate.
 Organizational and interpersonal politics

may limit participation.
 Group participants must agree to avoid

debating the ideas raised during
brainstorming.

2.6 Business Capability Analysis

Business capabilities describe the ability of
an enterprise to act on or transform something
that helps achieve a business goal or
objective. Capabilities may be assessed for
performance and associated risks to identify
specific performance gaps and prioritize
investments.
Capabilities
Capabilities are the abilities of an

enterprise to perform or transform something
that helps achieve a business goal or
objective. Capabilities describe the purpose
or outcome of the performance or
transformation, not how the performance or
transformation is performed. Each capability
is found only once on a capability map, even
if it is possessed by multiple business units.

Using Capabilities
Capabilities impact value through increasing

or protecting revenue, reducing or preventing
cost, improving service, achieving compliance,
or positioning the company for the future.
Performance Expectations
Capabilities can be assessed to identify

explicit performance expectations. And current
performance which will provide performance.
Risk Model
Capabilities alone do not have risks—the

risks are in the performance of the
capability, or in the lack of performance.
These risks may fall into various categories

such as business risk, technology risk,
organizational risk, and market risk.

Strategic Planning
Business capabilities for future state and

capability gaps of an enterprise can be used
to determine where that enterprise needs to go
in order to accomplish its strategy. A
business capability assessment can produce a
set of recommendations or proposals for
solutions.
Capability Maps
Capability maps provide a graphical view of

elements involved in business capability
analysis. There is no set standard for the
notation of capabilities maps.
Strengths
 Create very focused and aligned initiatives

by providing a shared articulation of
outcomes, strategy, and performance
 Align business initiatives across multiple
aspects of the organization.

Limitations
 Requires an organization to agree to

collaborate on this model.
 Requires a broad, cross–functional
collaboration in defining the capability

model and the value framework.

2.7 Business Cases

A business case provides a justification for a
course of action based on the benefits to be
realized by using the proposed solution, as
compared to the cost, effort, and other
considerations to acquire and live with that
solution.
A business case is frequently presented in a

formal document, but may also be presented
through informal methods. The amount of time
and resources spent on the business case
should be proportional to the size and
importance of its potential value. Business
cases do not provide intricate details.
A business case is used to:
1. Define the need,

2. Determine the desired outcomes,
3. Assess constraints, assumptions, and risks,
and
4. Recommend a solution.

Need Assessment
Need drives business case. It is the relevant

business goal or objective that must be met.
Objectives are linked to a strategy or the
strategies of the enterprise. The need
assessment identifies the problem or the
potential opportunity.
Desired Outcomes
The desired outcomes describe the state which

should result if the need is fulfilled. They
should include measurable outcomes that can be
utilized to determine the success of the
business case or the solution.
Assess Alternatives
Business case identifies and assesses various

alternative solutions. Alternatives may
include (but are not limited to) different
technologies, processes, or business models.
Each alternative should be assessed in terms

of:
Scope: Scope can be defined using

organizational boundaries, system boundaries,
business processes, product lines or
geographic regions. Scope statements clearly
define what will be included and what will be
excluded.
Feasibility: Includes organizational

knowledge, skills, and capacity, as well as
technical maturity and experience in the
proposed technologies.
Assumptions, Risks, and Constraints
Financial Analysis and Value Assessment:
Recommend Solution
Describes the most desirable way to solve the

problem or leverage the opportunity.
Strengths
 Provides integrated view of facts,

issues, and analysis required to make
decisions regarding change.
 Provides a detailed financial analysis of
cost and benefits.
 Provides guidance for ongoing decision
making throughout the initiative.
Limitations
 May be subject to the biases of authors.

 Frequently not updated once funding for the
initiative is secured.
 Contains assumptions regarding costs and
benefits that may prove invalid upon further
investigation.

2.8 Business Model Canvas

A business model canvas is comprised of nine
building blocks that describe how an
organization intends to deliver value:
1. Key Partnerships
2. Channels
3. Key Activities
4. Customer Segments
5. Key Resources
6. Cost Structure
7. Value Proposition
8. Revenue Streams
9. Customer Relationships.
A business model canvas can be used as a

diagnostic and planning tool regarding
strategy and initiatives. As a diagnostic
tool, the various elements of the canvas are
used as a lens into the current state of the
business, especially with regards to the
relative amounts of energy, time, and
resources the organization is currently

investing in various areas.
As a planning and monitoring tool, the canvas

can be used as a guideline and framework for
understanding inter-dependencies and
priorities among groups and initiatives.
A business model canvas allows for the mapping

of programs, projects, and other initiatives
(such as recruitment or talent retention) to
the strategy of the enterprise. In this
capacity, the canvas can be used to view where
the enterprise is investing, where a
particular initiative fits, and any related
initiatives.
A business model canvas can also be used to

demonstrate where the efforts of various
departments and work groups fit and align to
the overall strategy of the enterprise.

Elements
Key Partnerships
Key partnerships often involve some degree of
sharing of proprietary information, including
technologies. An effective key partnership can
lead to more formalized relationships such as
mergers and acquisitions.
Key Activities
Key activities are those that are critical to
the creation, delivery, and maintenance of
value, as well as other activities that
support the operation of the enterprise.
Key activities can be classified as:
Value-add: characteristics, features, and
business activities for which the customer is
willing to pay.
Non-value-add: aspects and activities for
which the customer is not willing to pay.
Business non-value-add: characteristics that
must be included in the offering, activities
performed to meet regulatory and other needs,
or costs associated with doing business, for
which the customer is not willing to pay.

Key Resources
Resources are the assets needed to execute a
business model. Resources may be different
based on the business model.
Resources can be classified as:
Physical: applications, locations, and
machines.
Financial: what is needed to fund a business
model, such as cash and lines of credit.
Intellectual: any proprietary aspects that
enable a business model to thrive, such as
knowledge, patents and copyrights, customer
databases, and branding.
Human: the people needed to execute a
particular business model.
Value Proposition
A value proposition represents what a customer
is willing to exchange for having their needs
met.
Customer Relationships
Customer relationships are classified as
customer acquisition and customer retention.
Organizations interact with their customers in

different ways depending on the relationship
they want to establish and maintain.
Channels
Channels are the different ways an enterprise
interacts with and delivers value to its
customers. Some channels are very
communication-oriented (for example, marketing
channel), and some are delivery-oriented (for
example, distribution channel). Other examples
include sales channels and partnering
channels.
Enterprises use channels to:
1. Raise awareness about their offerings,
2. Help customers evaluate the value
proposition,
3. Allow customers to purchase a good or
service,
4. Help the enterprise deliver on the value
proposition, and
5. Provide support.
Customer Segments
Customer segments group customers with common
needs and attributes so that the enterprise

can more effectively and efficiently address
the needs of each segment.
Cost Structure
Every entity, product, or activity within an
enterprise has an associated cost. Enterprises
seek to reduce, minimize, or eliminate costs
wherever possible. It is important to
understand the type of business models, the
differences in the types of costs and their
impact, and where the enterprise is focusing
its efforts to reduce costs.
Revenue Streams
A revenue stream is a way or method by which
revenue comes into an enterprise from each
customer segment in exchange for the
realization of a value proposition. There are
two basic ways revenue is generated for an
enterprise:
Revenue resulting from a one-time purchase of
a good or service and recurring revenue from
periodic payments for a good, service, or
ongoing support.
Licensing or Subscription fees: the customer

pays for the right to access a particular
asset, either as a one-time fee or as a
recurring cost.
Transaction or Usage fees: the customer pays
each time they use a good or service.
Sales: the customer is granted ownership
rights to a specific product.
Lending, Renting, or Leasing: the customer has
temporary rights to use an asset.
Strengths
 Widely used and effective framework to
understand and optimize business models.
 Easy to understand and simple to use.
Limitations
 Does not account for alternative measures of
value such as social and environmental
impacts.
 Does not provide a holistic insight for
business strategy.
 Does not include the strategic purpose of
the enterprise within the canvas.

2.9 Business rules analysis

Business policies and rules guide the day-to-
day operation of the business and its
processes. It shapes operational business
decisions. A business policy dictates the
actions of an enterprise and the people in it
by broadly controlling, influencing, or
regulating them.
A business rule serves as a criterion for

guiding behavior, shaping judgments, or making
decisions in a specific, testable manner.
Business rules analysis is used to identify,
express, validate, refine, and organize the
rules that shape day-to-day business behavior.
It also guides operational business decision
making.
Business rules may be explicit or tacit. It

requires a defined glossary of terms. A set of
rules for making an operational business
decision may be expressed as a decision table
or decision tree.

Business rules should be:
 Stated in appropriate terminology for Domain
SMEs to validate.
 Documented independently from enforcement.
 Stated at atomic level, and in declarative
format.
 Maintained in a manner which can be
monitored and adapted as the business
policies change.
Definitional rules
These rules represent operational knowledge of
the organization. They prescribe how
information may be derived, inferred or
calculated based on information available to
the business. They can be misapplied but
cannot be violated. An example of an operative
rule is: “No customer should be provided a
credit period more than 30 days.”
Behavioral rules
Behavioral rules intend to guide the actions
of people working within the organization, or
people who interact with it. These rules can

be violated directly but organizations may
take extraordinary precautions in its solution
to prevent it.
“An order must not be placed when the billing
address provided by the customer does not
match the address on file with the credit card
provider.”
Strengths
 Having an enterprise-wide engine can assist
in quick implementation of changes in
business rules.
 Centralized repository enables reuse of
business rules across the organization.
 Allows organizations to make changes to
policy without altering processes.
Limitations
 Can be lengthy, contradict one another or
produce unanticipated results when combined.
 Poorly defined and organized vocabulary can
result in inaccurate or contradictory

business rules.

2.10 Collaborative Games
Collaborative games use game playing

techniques to collaborate in developing common
understanding of a problem or a solution.
They usually involve strong visual or tactile

(activities) elements such as moving sticky
notes, writing on whiteboards, or drawing
pictures.
A neutral facilitator guides the game flow.
Steps are:
1. Define Game Purpose
2. Play the game
1. Opening step - Learn the rules of the game

and start generating ideas.
2. Exploration step - Participants engage with

one another and look for connections between
their ideas, test those ideas and experiment
with new ideas.
3. Closing step – Assess ideas which are

likely to be the MOST productive.

Examples of Collaborative Games
Game Description Objective
Product Construct a product box to be Identify features those

box sold in a retail store. drive interest in the
marketplace.
Affinity Write features on sticky Identify related or

map notes, put them on a wall. similar features or
Move noted to other features themes.
that are similar.
Fishbowl Divide participants in 2 Identify hidden

groups. One group speaks assumptions or
about a topic. Other group perspectives.
listens intently and
documents its observations.
Strengths
 Identify hidden assumptions or differences

of opinion.
 Encourages creative thinking.
 Challenges participants to take a more

active role.
 Useful in exposing business needs that

aren't being met.

Limitations
 Perceived as silly and unproductive.
 Uncomfortable for participants with

reserved personalities or cultural norms.
 Time-consuming.
 Can lead to a false confidence in the

conclusions reached due to group activity.

2.11 Concept Modelling
Concept models organize business vocabulary,

usually starting with glossary.
These models are effective where:
 Organizing, managing and communicating core

knowledge,
 Need to capture large numbers of business

rules,
 Stakeholders find it hard to understand data

models,
 Re-engineering business processes or

business capability and
 Regulatory or compliance challenges.
Concept models are different from data models.
Concept models support expression of natural

language statements.
Concept models are NOT intended to unify,

codify and simplify data.
Noun concepts – Entities or objects of

interest for e.g. “Customer”, “Order” etc.
Verb concepts – Actions those can be carried

out on Noun concepts. Such as “Create”,
“Update”. This would form sentence like
“Create Customer”, “Update Order”.
Strengths
 Makes precise communication.
 Independent of data design biases.
 Helps in reducing ambiguity
Limitations
 Requires abstract thinking skill
 Need tool support for strict implementation.
Note: This was called “Glossary” in BABoK

v2.

2.12 Data dictionary
Data dictionaries comprise of standard

definitions of primitive data elements, their
meanings and allowable values and indicate how
those elements combine into composite data
elements.
It is to manage data within a solution’s

context and is often used in conjunction with
ER diagrams.
Primitive data elements
Record following information about each data

element in the data dictionary:
Name A unique name for the data

element.
Aliases Alternate names for the data

element.
Values List of acceptable values for

the data element.
Meanings If the values are abbreviated,

include an explanation of the
meaning.

Description Definition of the data element

in the context of the
solution.
Composite data elements
Composite data is assembled from primitive

data elements, for example an intelligent ID
to describe items. Composite structures
include:
Sequence Show primitive data elements

in specific order.
Repetition Shows that one or more

primitive data elements occur
multiple times in the
composite element.
Optional May or may not occur in a

element particular instance of the
data element.
Strengths
 Ensures all stakeholders are in agreement on

format and content of relevant information.
 Capturing these definitions in a single

model ensures consistent usage.

Limitations
 Unless maintained regularly, can become

obsolete or incorrect metadata.
 Need maintenance has to ensure quick and

easy retrieval.
 Metadata required by multiple scenarios MUST

be taken into account.

2.13 Data Flow Diagrams (DFDs)
DFDs show transformation of data from (data

source such as external sources, activities
and destination).
They are useful for depicting a transaction-

based systems and boundaries of a physical,
logical, or manual system.
Data used in DFD should be described in a data

dictionary.
DFDs can be at multiple layers of abstraction,

highest level diagram (Level 0) is context
diagram representing the entire system.
Context Diagram Gane-Sarson Notation
Level 1, next level of DFD illustrates

processes related to the system with the
respective input data, output transformed data
and data stores.

Level 1 Diagram Yourdon Notation
Further levels of the data flow diagram (level

2, level 3 and so forth) break down the major
processes from the level 1 diagram.
Logical data flow diagrams represent the

future or essential state—that is, what
transformations need to occur regardless of
the current physical limitations.
Physical data flow diagrams model all of the

data stores, printers, forms, devices and
other manifestations of data. The physical
diagram can show either the current state or
how it will be implemented.

Externals (Entity, Source, Sink)
An external (entity, source, sink) is a

person, organization, automated system, or any
device capable of producing data or receiving
data.
It is outside of the system under analysis.
Each external MUST HAVE AT LEAST ONE DATA flow

going to or coming from it.
Externals are represented by using a noun

inside a rectangle and are found within
context-level diagrams as well as lower levels
of abstraction.
Data Store
Data stores store data for future use.
Each data store MUST have at least one data

flow going to or coming from it.
A data store is represented as either 2

parallel lines or as an open-ended rectangle
with a label.
Process
Processes transform data into an output.

Naming standards for a process should contain
a verb and a noun.
Each process MUST have at least one data flow

going to it and one data flow coming from it.
A data process is represented as a circle or

rectangle with rounded corners.
Data Flow
Data flows indicate movement of data between

an external, a process and a data store.
Data flows are represented as a line with an

arrow displayed between processes.
The data flow is named using a noun.
Data Flow Diagram Yourdon Notation
Strengths
 To discover processes and data.
 Verify functional decompositions or data

models.
 Excellent way to define scope of a system

and its interfaces.
 Effort estimation.
 Easy to understand.
 Helps to identify duplicate or missing data

elements.
 Illustrates connections to other systems.
 Can be used as part of system documentation.
 Helps to explain the logic behind the data

flow within a system.
Limitations
 Can become complex for large-scale systems.
 Different DFD notations exist.
 Does not illustrate sequence of activities

or stakeholders.

2.14 Data Mining
Data mining improves decision making by

finding useful patterns and insights from
data.
It is an analytic process that examines large

amounts of data from different perspectives
and summarizes the data in such a way that
useful patterns and relationships are
discovered.
Results of data mining techniques are

generally mathematical models describing
underlying patterns and relationships.
Data mining can be utilized in either

supervised (user poses a question) or
unsupervised (pure pattern discovery)
investigations.
Data mining has 3 primary techniques:
Descriptive
Clustering make it easier to see the patterns

in a set of data, such as similarities between
customers.

Diagnostic
Decision trees or segmentation can show why a

pattern exists, such as the characteristics of
an organization's MOST profitable customers.
Predictive
Regression or neural networks can show how

likely something is to be true in the future,
such as predicting the probability that a
particular claim is fraudulent.
Requirements elicitation
Define goal and scope of data mining such as

support for an important identified business
decision, or domain-specific pattern
discovery.
This top-down versus a bottom-up mining

strategy allows analysts to pick the correct
set of data mining techniques.
Formal decision modelling techniques are to

define requirements for top-down data mining
exercises.
Data mining exercises are more effective in

agile environment.

Data preparation: Analytical dataset
Data mining tools work on an analytical

dataset which are formed by merging records
from multiple tables or sources into a single,
wide dataset.
Repeating groups are typically collapsed into

multiple sets of fields.
Analytic data set physical file or virtual

file.
Data volumes can be very large, sometimes

resulting in the need to work with samples or
to work in-data store so that the data does
not have to be moved around.
Data analysis
Apply wide variety of statistical measures and

use visualization tools to see how data values
are distributed, what data is missing and how
various calculated characteristics behave.
This step is often the longest and MOST

complex in a data mining effort and is
increasingly the focus of automation.

Modelling techniques
1. Classification and regression trees (CART),

C5 and other decision tree analysis
techniques.
2. Linear and logistic regression.
3. Neural networks.
4. Support sector machines.
5. Predictive (additive) scorecards.
Deployment
For human users, data mining results presented

using visual metaphors or as simple data
fields.
Potential business rules can be deployed using

a business rules management system. Such
executable business rules can be fitted into a
decision model along with expert rules as
necessary.
Some data mining techniques—especially those

described as predictive analytic techniques—
result in mathematical formulas. These can
also be deployed as executable business rules
but can also be to generate SQL or code for
deployment.

Strengths
 Reveals hidden patterns and useful insights.
 Can be integrated into system design to

increase accuracy of the data.
 Can be to eliminate or reduce human bias.
Limitations
 Can take considerable effort.
 Applying techniques without a thorough

understanding can result in erroneous
correlations.
 May lead to accidental misuse.
 Require specialist knowledge.
 Use of advanced math and lack of

transparency can cause resistance from some
stakeholders.

2.15 Data Modelling
Data model describe entities, classes or data

objects relevant to a domain, their attributes
and relationships among them.
There are several variations of data models:
Conceptual data model
Independent of any solution. To represent how

business perceives its information. It can be
to help establish a consistent vocabulary
describing business information and the
relationships within that information.
Logical data model
Incorporates rules of normalization to

formally manage the integrity of the data and
relationships. To design a solution.
Physical data model
Describe how a database is physically

organized. It addresses concerns like
performance, concurrency and security.
At the conceptual level, different data

modelling notations are likely to produce
broadly similar results and can be thought of
as a single technique.
Logical and physical data models include

elements specific to the solutions they
support and are generally developed by
stakeholders with expertise in implementing
particular technical solutions.
For instance, logical and physical entity-

relationship diagrams (ERDs) would be to
implement a relational database, whereas a
logical or physical class diagram would be to
support object-oriented software development.
Object diagrams can be to illustrate

particular instances of entities from a data
model.
They can include actual sample values for the

attributes, making object diagrams more
concrete and more easily understood.
Entity or Class
Entities may represent something physical

(such as a Warehouse), something
organizational (such as a Sales Area),
something abstract (such as a Product Line),
or an event (such as an Appointment).
In a class diagram, entities are referred to

as classes.

Like an entity in a data model, a class

contains attributes and has relationships with
other classes.
A class also contains operations or functions

that describe what can be done with the class,
such as generating an invoice or opening a
bank account.
Each instance of an entity or class will have

a unique identifier that sets it apart from
other instances.
Attribute
Attributes define particular piece of

information associated with an entity,
including how much information can be captured
in it (size), its allowable values and the
type of information it represents.
Attributes can be described in a data

dictionary.
Allowable values specified through business

rules.
Attributes can include such values as:
Name: a unique name for the attribute. Other

names used by stakeholders captured as
aliases.
Values/Meanings: a list of acceptable values

for the attribute. This expressed as an
enumerated list or as a description of allowed
formats for the data (including information
such as the number of characters). If the
values are abbreviated this will include an
explanation of the meaning.
Description: the definition of the attribute

in the context of the solution.
Relationship or Association
Term cardinality is to refer to the minimum

and maximum number of occurrences to which an
entity related.
Typical cardinality values are zero, one and

many. The relationship between 2 entities read
in either direction, using this format:
Each occurrence (of this entity) is related to

(minimum, maximum) (of this other entity).
In a class model, the term association is used

instead of relationship and multiplicity is
used instead of cardinality.

Diagrams
Diagram in a data model is called an entity-

relationship diagram (ERD).
In a class model, the diagram is called a

class diagram.
Entity-Relationship Diagram (Crow's Foot

Notation)

Class Diagram (UML®)
Class names optionally can have a stereotype

which defines additional properties.
<<stereotype>>
Metadata
A data model optionally contains metadata

describing what the entities represent, when
and why they were created or changed, how they
should be used, how often they are used, when
and by whom.
There could be restrictions on their creation

or use, as well as security, privacy and audit
constraints on specific entities or whole
groups of entities.
Strengths
 Can be to define and communicate a

consistent vocabulary used by Domain and
Implementation SMEs.
 Review of a logical data model helps to

ensure that the logical design of persistent
data correctly represents business needs.
 Provides a consistent approach to analyzing

and documenting data and its relationships.

 Offers the flexibility of different levels

of detail.
 Formal modelling of the information held by

the business may expose new requirements as
inconsistencies are identified.
Limitations
 Unfamiliar to people without a background in

IT.
 Typically beyond the business knowledge base

of individual stakeholders.

2.16 Decision analysis
Decision analysis supports decision-making in

dealing with complex, difficult, or uncertain
situations.
It examines and models the possible

consequences of different decisions.
Effective decision analysis requires that the

analyst understand:
 Values, goals and objectives relevant to the

decision problem
 Nature of the decision that MUST be made
 Areas of uncertainty that affect the
decision
 Consequences of each possible decision.
Decision analysis approaches use the following

activities:
Define
problem
statement
Implement Define
choice Alternatives
Choose
Evaluate
alternative to
Alternatives
implement

Components of decision analysis:
1. Description of the decision to be made or

the problem statement
2. Person responsible for taking the decision
3. Possible alternatives
4. Decision criteria to evaluate the

alternatives
2 types of decision matrices
In a simple decision matrix, each alternate is

checked to see whether it meets each criterion
under evaluation or not.
After this, the number of criteria matched for

each alternate is tallied.
In a weighted decision matrix options are

assessed against weighted criterions.
The weight is assigned based on importance.

The higher the weighting, the more important
the criterion.

Decision trees
To assess the preferred outcome when multiple

sources of uncertainty exists. Decision trees
include:
Decision nodes:
includes different strategies
Chance nodes:
Defines uncertain outcomes
Terminator or end nodes:

Identifies final outcome
Trade-offs
Trade-offs is needed whenever a decision

problem involves multiple, possibly
conflicting, objectives.
Effective methods include:
 Elimination of clearly inferior or dominated

alternatives,
 Ranking objectives on a similar scale.

Strengths
 Helps to determine the expected value of

alternative scenarios.
 Helps stakeholders to honestly assess the

importance they place on different
alternatives.
 Assists stakeholders under pressure to

assess options based on criteria rather than
emotions and descriptions.
 Helps Business analysts to construct

suitable metrics to compare financial and
non-financial outcomes.
Limitations
 Requires specialized knowledge of

probability and skills.
 Information may not be available on time to

take an informed decision.
 Decisions may have to be taken immediately

at times.
 Tendency to treat results of decision

analysis as more certain than they actually
are.

2.17 Decision modeling
Decision modelling shows how repeatable

business decisions are made using data and
knowledge for any decision, simple or complex.
Comprehensive decision model is an overarching

model that is linked to processes, performance
measures and organizations. It shows where the
business rules come from and represents
decisions as analytical insight.
Types of models and notations
Decision tables represent all the rules

required to make an atomic decision.
Decision tables
A decision table is a compact, tabular

representation of a set of these rules. Each
row (or column) is a rule and each column (or
row) represents one of the conditions of that
rule.
When all the conditions in a particular rule

evaluate to true for a set of input data, the
outcome or action specified for that rule is
selected.

Criteria Graduate Post graduate
Scored > 60% Not eligible Eligible
Scored > 75% Eligible Eligible
Decision trees
In decision trees, each path on a decision

tree leaf node is a single rule. Each level in
the tree represents a specific data element;
the downstream branches represent the
different conditions that MUST be true to
continue down that branch.

Decision Requirements Diagrams
A decision requirements diagram shows

information, knowledge and decision making
involved in a more complex business decision.
It contains following elements:
Decisions: Shown as rectangles. Each decision

takes a set of inputs and selects from a
defined set of possible outputs by applying
business rules and other decision logic.
Input Data: Shown as ovals, representing data

that MUST be passed as an input to a decision
on the diagram.
Business Knowledge Models: Shown as a

rectangle with the corners cut off,
representing sets of business rules, decision
tables, decision trees, or even predictive
analytic models that describe precisely how to
make a decision.
Knowledge Sources: Shown as a document,

representing the original source documents or
people from which the necessary decision logic
can be or has been derived.
Solid arrows show the information requirements

for a decision.

Dashed arrows display knowledge requirements.
Knowledge sources can be linked to decisions

with a dashed, rounded arrow to show that a
knowledge source (for example, a document or
person) is an authority for the decision. This
is called an authority requirement.
Strengths
 Easy to share and understand.
 Facilitate shared understanding.
 Support impact analysis.
 Multiple perspectives can be shared and

combined, especially when a diagram is used.
 Decision tables help in managing large

numbers of parameters.
 Helps with reuse.
 Helps in rules-based automation, data

mining, predictive analytics and BI
projects.
Limitations
 Unnecessary for simple decisions coupled to

the process.
 May limit rules to those required by known

decisions and so limit the capture of rules
not related to a known decision.

 Practices may differ from the model.
 Difficult to obtain agreement on cross-

functional rules.
 May not address behavioural business rules

in a direct fashion.
 Needs clearly defined business terminology

to avoid data quality issues for process
automation.

2.18 Document analysis
Document analysis is to elicit business

analysis information, by examining materials
which describe about the business environment
or organizational assets.
Document analysis helps in understanding the

context of a business need or understanding
how existing solutions are implemented.
Based on business analysis information being

explored, the purpose, scope and topics to be
researched are determined.
Data mining, an approach to document analysis

is to analyze data to group it into
categories, determine patterns and
opportunities for change.
Background research gathered through document

analysis comprises of reviewing materials like
marketing studies, industry standards,
guidelines etc.
Document analysis about an existing solution

may comprise of reviewing business rules,
technical documentation, previous requirements
documents, problem reports etc. in order to
determine how the existing solution works and

the reason for implementing it the way it is.
It is also useful when SMEs are no longer
present or available for the duration of the
elicitation process.
Steps for conducting document analysis
1. Preparation
Consider the following aspects pertaining to

the content relevance, credibility,
understandability, and ease with which the
content can be conveyed.
2. Performing document review and analysis
 Conduct detailed review of each document’s

content and record relevant notes.
 Identify conflicting or duplicate notes.
 Note gaps in knowledge.
3. Record findings
 Check whether the content and level of

detail is appropriate
 Consider transforming information into

visual aids to improve understanding

Strengths
 Existing source materials used as a basis

for analysis without creating new content.
 Existing sources used as a reference to

determine what is current and what has
changed.
 Results can be to validate against results

of other elicitation techniques.
 Findings can be presented in easy to

understand formats.
Limitations
 Limited to “as-is” perspective
 Existing documentation may not be up-to-date

or valid.
 Unavailability of authors for clarification.
 Can be time-consuming to locate relevant

information for a wide range of sources.

2.19 Estimation
Estimation techniques are used for better

understanding of possible range of costs and
effort associated with any initiative.
Estimation is an iterative process.
Estimation techniques are used when it is

impossible to determine exact costs.
Note that estimation techniques do not

eliminate uncertainty, rather help to get a
reasonable assessment of likely costs or
effort required.
Representing estimation as a range of values,

with minimum and maximum may add more value to
stakeholders.
Different techniques of estimation
• Top-down estimation
Estimate efforts for components using

hierarchical breakdown.
• Bottom-up estimation
Bottom-up estimation uses WBS technique to

estimate deliverables, activities, tasks and
estimates from all the involved stakeholders

and rolls them up to get a total for all the
activities and tasks.
Because it is normally easier to estimate

smaller items than larger items, bottom-up
estimating can produce the MOST accurate and
defensible estimates.
• Parametric estimation
Uses a calibrated parametric model of the

element attributes. For example, if one use
case takes 24 hours to develop, it will take
480 hours for developing 20 use cases.
• Rough order of magnitude (ROM)
Based on limited information, a high level

estimate with a very wide confidence interval.
• Rolling Wave
Rolling wave technique involves continual

refinement of estimates. Estimate the details
for activities in the current iteration or
increment and extrapolate it for the entire
scope of work.
As the end of the iteration approaches,

estimates for the next iteration can be made
and the initial estimate for all activities is
refined.

• Delphi Estimation
Uses a combination of expert judgment and

history. Include individual estimates, sharing
the estimates with experts and having several
rounds until consensus is reached.
• PERT (Program Evaluation Review Technique)
Each component of the estimate is given three

values:
• Optimistic estimate or best-case

scenario.
• Pessimistic estimate or worst-case

scenario.
• Most likely estimate.
Note that the most likely estimate is not an

average of best and worst case scenarios. It
requires in depth knowledge of the situation.
Under the right circumstances, the best- case
scenario may also be the most likely.
A PERT value for each estimated component is

computed as a weighted average:
(Optimistic + Pessimistic + (4 times Most

Likely))/6.
Accuracy of the estimates
It is a measure of uncertainty that evaluates

how close an estimate is to the actual value
measured later.
Sources of information
• Analogous situations - Using an element

(project, initiative, risk, or other) like
the element being estimated.
• Organization History - Prior experiences of

the organization with similar work.
• Expert Judgement - Estimating relies on the

expertise of those who have performed the
work in the past.
Precision and Reliability of Estimates
Precision is how close the estimates are to

each other when multiple estimates are made
for a particular attribute. Reliability of an
estimate is its repeatability when different
methods of estimating are used.
Contributors to Estimates
Estimators of an element are frequently those

responsible for that element.
Strengths
 Helps making better decisions based on an

improved understanding costs and time.
 Team of knowledgeable individuals can

provide a better estimate than a single
individual.
Limitations
 Stakeholders treat estimates as commitments.
 Use of a single estimation method can set

undue expectations.
 Accuracy of estimates depends on the

knowledge level about the elements.
 Often altered to match the desires of

influential stakeholders.
2.20 Financial analysis
Financial analysis explores financial aspects

(benefits and costs) of an investment. Costs
to consider are:
 Initial cost with time frame of investments,
 Expected financial benefits with time frame,
 Ongoing usage and support costs.
 Risk factors for investment.
Cost of the Change
Expected cost of building or acquiring the

solution components and costs of
transitioning.
Total Cost of Ownership (TCO)
Cost of change + Usage cost + Support cost for

a period.
Cost-Benefit Analysis
Expected total benefits - Expected total

costs.
Financial Calculations
Return on Investment
Net benefits * 100 / Cost of the change.
When making a comparison between potential

investments, use the same time period for both
investments.
Discount Rate
Assumed interest rate + risk premium.
Present Value
Present Value = Sum of (Net Benefits in that

period / (1 + Discount Rate for that period))
for all periods in the cost-benefit analysis.
Present value does not consider the cost of

the original investment.
Net Present Value
Net present value (NPV) is the present value

of the benefits minus the original cost of the
investment.
Net Present Value = Present Value – Cost of

Investment
Internal Rate of Return
Discount rate at which a NPV becomes 0.
Payback Period
Time period required to generate enough
benefits to recover the cost of the change.
Strengths
 Objective comparison of investments.
 Assumptions and estimates are clearly

stated.
 Reduces uncertainty by identifying and

analyzing influencing factors.
Limitation
 Costs and benefits are difficult to

quantify.
 Numbers often gives false sense of security.
2.21 Focus groups

Focus groups elicit ideas, and attitudes from
pre-qualified individuals about a specific
product, service or opportunity in an
interactive group environment. Participants
share their impressions, preferences, and
needs, guided by a moderator.
Focus groups are typically 1 to 2 hours in

length.
Focus groups can be utilized during any life-

cycle state: exploratory, under development,
ready to launch, or in production. For a
product ‘under development’, focus group’s
ideas are analyzed in relationship to the
stated requirements.
This may result in updating existing

requirements or uncovering new requirements.
For a ‘to be launched’ product, focus group
may influence how to position the product in
the market. For a product ‘in production’,
focus group may provide direction on the
revisions to the next release of requirements.
Focus groups may also serve as a means to

assess customer satisfaction with a product or
service. Observers may record or monitor the
focus group but should not participate. Being
a form of qualitative research, focus group
results are analyzed, and reported as themes,
and perspectives, rather than numerical
findings.
Traditional focus groups gather in the same

physical room. However, online focus groups
allow members to be located remotely.
Focus groups are similar to brainstorming

sessions. Differences are:
 Focus groups are typically more structured,

and mandate a moderator.
 Brainstorming session’s goal is to actively

seek broad, creative, even exaggerated
ideas.
Steps for focus group

1. Have a clear and specific objective for
the focus group
2. Have a focus group plan which defines

activities like purpose, location,
logistics, participants, budget,
timelines, outcomes etc.
3. Recruit participants
Participants should be willing to share their

perspectives on a specific topic as well as
listen to others opinions.
A focus group typically has 6-12 attendees.
Invite additional individuals to allow for

non-attendance due to scheduling conflicts,
emergencies or for other reasons. If many
people need to participate, run more focus
groups. Topic of the focus group influences
who should be recruited. If the topic is a new
product, existing users (experts, and novices)
should be included.
4.Create discussion guide
Provides a prepared script for the moderator

comprising of specific questions and topics to
be discussed during the session. Includes
reminders to welcome participants, explain
goals/objectives of the session, how to
conduct the session and how to use the
feedback.
5.Assign moderator, and recorder

Moderator should be experienced in
facilitating groups.
Typical skills include ability to:
 Promote discussion.
 Ask open questions - requiring or promoting
an extended response.
 Facilitate interactions between group
members.
 Engage all members.
 Keep session focused.
 Remain neutral.
 Be adaptable, and flexible.
Recorder takes notes during the session. BAs
can fill the role of either moderator or
recorder.
6.Conduct focus group session
Sessions usually last for 1-2 hours. Follow a

pre-planned script of specific issues, and
ensure the focus group objectives are met.
However, the discussion should appear free-
flowing and relatively unstructured to the
participants.
7.After the focus group
Moderator analyses, and documents

participants’ agreements, and disagreements,
looks for trends and produces a summary
report.
Strengths
 Saves time, and cost compared to conducting

multiple individual interviews.
 Effective for learning people’s attitudes,
experiences, and desires.
 Encourages active participation and
discussion which enables participants to
analyze their personal views with regard to
others.
 Online focus groups works best when
participants are distributed geographically
Limitations
 Issues of trust or unwillingness to discuss

sensitive or personal topics may arise in a
group setting.
 Data collected (what people say) may not be
consistent with how they actually behave.
 Homogeneous groups may not represent
complete set of requirements.
 Skilled moderator is needed to manage group
interactions, and discussions.
 Difficult to schedule.
 Limited interaction and inability to read
body language can be a flaw in online focus
groups.
2.22 Functional decomposition
Functional decomposition breaks down a large

aspect (processes, functional areas,
deliverables, scope, or problems) into smaller
aspects, as independent as possible, so that
work can be assigned to different groups.
Doing so reduces the complexity of analysis.
Functional decomposition provides ability to

scale and manage larger projects.
Decomposition objectives determine the process

of decomposition and defines what to
decompose, how to decompose and how deeply to
decompose.
Objectives may vary from isolating specific

manageable factors, simplifying a design
problem, estimating and forecasting
constituent factors, reusing and optimizing
solutions etc.
Functional decomposition can be applied to

diverse subjects like:
Business Work to be Business

outcomes done process
Solution
Function Business unit
component
Products and
Activity Decisions
services
The appropriate level of functional

decomposition defines where, why and when to
stop decomposing the subject in order to meet
the analysis objectives.
Functional decomposition can be represented by

a combination of plain textual descriptions,
hierarchical diagram, programming languages,
visual diagrams etc.
Work breakdown structure (WBS) decomposes

project scope in phases, work packages and
deliverables.
Strengths
 Helps to manage complex problems by breaking

them into parts.
 Provides shared understanding of complex

matters.
 Assists in estimation.
Limitations
 No way to be certain that all components

have been captured.
 Lack of understanding of the relationships

between pieces can create an inappropriate
structure.
 Missing or incorrect elements can lead to

re-work.
 Need deep knowledge of the subject and

extensive collaboration with stakeholders.
2.23 Glossary
Comprises of key terms relevant to a business

domain in order to provide a common
understanding of terms.
It contains definitions as well as synonyms.
Glossary needs to be organized and be

accessible to all stakeholders.
A term is included in a glossary when:
1. It is unique to a domain
2. It has multiple definitions
3. Commonly used meaning is different from that

which is used within the domain
4. There is chance for misunderstanding
Glossaries should be defined in the early

stages of the project to enhance understanding
and transfer knowledge.
Identify person responsible for maintaining

the glossary.
Limit glossary editing to specific

stakeholders ONLY.
Strengths
 Promotes communication and common

understanding of the business domain.
 Encourages consistency as single reference

source for business terms.
 Simplifies the writing and maintenance of

business analysis information like
requirements, business rules etc.
Limitations
 Requires a dedicated person to update and

maintain.
 Challenging to get stakeholder agreement on

a single definition for a term.
2.24 Interface analysis
An interface is a connection between 2

components or solutions.
Interface analysis identifies interfaces and

interactions between solutions and/or solution
components.
Interface types include:
1. User interfaces, including human users

directly interacting with the system, as
well as reports provided.
2. Data interfaces between systems.
3. Application programming interfaces (APIs).
4. Hardware devices.
5. Business processes.
6. People external to the organization.
Interface analysis defines and clarifies

aspects like:
 Who will use the interface?

 What kind of information will be exchanged
through the interface?
 When information will be exchanged and how
frequently
 Where the information exchange will occur
 Why the interface is needed?
 How the interface should be implemented?
Early identification of interfaces allows

determining which stakeholders will get
affected and who should be present during
elicitation.
Preparing for identification
Business analysts can utilize techniques like

document analysis, observation, scope
modelling, interviews etc. to understand which
interfaces need to be identified.
Conduct interface identification
Identify the interfaces which are needed in the

future for each stakeholder or system that
interacts with the system. They describe the
function of the interface, assess the usage,
evaluate the suitable type and elicit details
about the interface.
Define interfaces
Interface definition includes name of the

interface, exchange method between entities,
message format, exchange frequency etc.
Strengths
 Early identification leads to increased

functional coverage.
 Clear specifications of the interfaces

provide a structured means of allocating
requirements, business rules and constraints
to the solution.
 Avoids over analysis of fine detail owing to

its broad application.
Limitations
 Does not provide insight into internal

components / other aspects of the solution.
2.25 Interviews
Interviews are a common form of elicitation

technique where interviewers ask questions to
stakeholders.
Effective interviewers control discussions,

understand needs from all stakeholders, probe
deeper when needed and ensure completeness of
answers.
Successful interviewing depends on:
1. Domain understanding of the interviewer,

2. Experience and willingness of the
interviewer,
3. Interviewer skill in documenting
discussions,
4. Interviewee readiness to provide relevant
information
5. Clarity in interviewee’s mind about the
interview goal, and
6. Rapport between interviewer and
interviewee.
Elements
Interview Goal
Consider purpose of the interview based on a

business need, individual goals for each
interview, based on what the interviewee can
provide.
Communicate goals clearly to interviewees.
Potential Interviewees
Identified potential interviewees along with

PM, sponsors and other stakeholders, based on
the goals for the interview.
Interview Questions
Design interview questions according to the

interview goals, such as, data collection,
research stakeholder’s view of the change or
proposed solution, develop a proposed
solution, or build rapport with interviewees.
Use open-ended questions to encourage

description. These are good tools to encourage
thinking.
Use closed questions to elicit a single

response such as yes, no, or a specific
number.
Closed questions are useful to clarify or

confirm a previous answer.
Organize interview questions based on priority

and significance. Order questions in a flow
such as general to specific, start to finish,
and detailed to summary, interviewee's level
of knowledge and the subject of the interview.
Interview Logistics
Pay attention to logistics aspects such as,

location (should be adapted to the schedule
and availability of the interviewees) and the
mode of communication (in-person, phone, or
online conferencing), recording needs, whether
to send the questions to the interviewees in
advance.
ONLY when the interviewee needs to collect

information to prepare for the interview, send
questions in advance.
Interview Flow
Opening:
1. Describe purpose and why the interviewees'

time is needed,
2. Confirm interviewees' roles,
3. Address any initial concerns raised by the

interviewees, and
4. Explain how information from the interview

will be recorded, and shared with the
interviewees, and other stakeholders.
During the interview
1. Maintain focus on the established goals and

predefined questions,
2. Adapt based on the information provided and

non-verbal clues,
3. Provide the required information,
4. Considers multiple sessions if needed,
5. Manage concerns raised by addressing them

during the interview or documenting them for
follow-up,
6. Practice active listening to confirm what

interviewees have said, and
7. Take written notes or records the interview

as appropriate.
Closing the interview includes:
1. Check for areas that may have been

overlooked in the session,
2. Provide contact information for the

interviewees to follow up with additional
information after the meeting as needed,
3. Summarizing the session,
4. Outlining the process for how the interview

results will be used and
5. Thank interviewees for their time.
Interview Follow-Up
Organize interview information and confirm

results quickly.
Strengths
 Encourages participation.
 Builds rapport with stakeholders.
 Simple and direct technique.
 Allows discussions and explanations.
 Allows observations of non-verbal behavior.
 Interviewers can ask follow-up and probing

questions to confirm their own
understanding.
 Allows interviewees to express opinions in

private that they reluctant to express in
public.
Limitations
 Needs significant time.
 Requires considerable commitment and
involvement of the participants.
 Needs trained facilitator.
 Subject to the interviewer's interpretation.
 Risk of unintentionally leading the

interviewee.
2.26 Item tracking
Item tracking captures and assigns

responsibility for issues and stakeholder
concerns. Items can refer to actions,
assumptions, constraints, dependencies,
defects, enhancements and issues.
Item Record
Record items, manually or through a system,

containing following attributes:
1. Item Identifier: a unique identifier

2. Summary: a brief description of the item.
3. Category: a grouping of items with similar
properties.
4. Type: Type of item.
5. Date Identified
6. Identified by
7. Impact: Possible consequences. Impact can
be assessed wrt time, cost, scope, or
quality.
8. Priority
9. Resolution date
10.Owner
11.Resolver: the stakeholder assigned to
resolve the item
12.Agreed Strategy: Such as accept, pursue,
ignore, mitigate and avoid.
13.Status: Such as open, assigned, resolved
and cancelled.
14.Resolution Updates: a running log of
details about how the item’s resolution is
proceeding
15.Escalation Matrix.
Item Management
Each item MUST be tracked to its closure or

resolution.
Metrics
Report on item tracking performance.
Strengths
 Ensures stakeholder concerns are tracked and

resolved.
 Allows stakeholders to rank the importance

of outstanding items.
Limitations
 Can be expensive to capture and track items.
 Consumes productive time.
 Stakeholders could become mired in details

and statistics.
2.27 Lessons Learned
Lessons learned process (also known as a

retrospective) compiles and documents
successes, opportunities for improvement,
failures and recommendations for improving the
performance of future projects or project
phases.
It helps to identify changes to business

analysis processes and deliverables.
Lessons learned sessions can include any format

or venue that is acceptable to the key
stakeholders and can be either formal
facilitated meetings with set agendas and
meeting roles or informal working sessions.
Review following during Lessons learned

session:
1. BA activities or deliverables,
2. Final solution, service, or product,
3. automation introduced or eliminated,
4. Impact to organizational processes,
5. Performance expectations and results,
6. Root causes impacting performance results,
7. Recommendations for behavioral approaches.
Strengths
 Identifies areas of improvement with the

project structure, methodology, or tools
use.
 Assists in building team morale.
 Reinforces positive experiences.
 Reduces risks for future projects.
 Provides tangible metrics.
 Recognizes strengths or shortcomings.
Limitations
 Can become blame game
 Participants unwilling to document and

discuss problems.
 Proactive facilitation required to ensure

discussions remain focused on solutions and
improvement opportunities.
2.28 Metrics and Key Performance

Indicators (KPIs)
Metrics and KPIs measure the performance of

solutions, solution components and other
matters of interest to stakeholders.
A metric is a quantifiable level of an

indicator to measure progress.
A target metric is the objective to be reached

within a specified period.
An indicator identifies a specific numerical

measurement that represents the degree of
progress toward achieving a goal, objective,
output, activity, or further input.
A key performance indicator (KPI) is one that

measures progress towards a strategic goal or
objective.
Reporting is the process of informing

stakeholders of metrics or indicators in
specified formats and at specified intervals.
Monitoring is a continuous process of data

collection to determine how well a solution
has been implemented as compared to the
expected results.
Evaluation is the systematic and objective

assessment of a solution to determine its
status and effectiveness in meeting objectives
over time and to identify ways to improve the
solution to better meet objectives.
Indicators
A good indicator has 6 characteristics:
1. Clear: precise and unambiguous.
2. Relevant: appropriate to the concern.
3. Economical: available at reasonable cost.
4. Adequate: provides a sufficient basis on

which to assess performance.
5. Quantifiable: can be independently

validated.
6. Trustworthy and Credible: based on evidence

and research.
Use proxies when data for direct indicators

are not available or when it is not feasible
to collect at regular intervals.
When establishing an indicator, consider its

source, method of collection, collector, cost,
frequency and difficulty of collection.
Secondary sources of data the MOST economical,
may not be very good indicator.
Use primary research such as surveys,

interviews, or direct observations if
necessary.
Metrics
In setting a metric for an indicator, it is

important to have a clear understanding of the
baseline starting point, resources that can be
devoted to improving the factors covered by
the indicator and political concerns.
A metric can be a specific point, a threshold,

or a range. Range can be useful if the
indicator is new.
Structure
Establish data collection, analysis and

reporting procedure.
Data collection procedure covers units of

analysis, sampling procedures, data collection
instruments to use, collection frequency and
responsibility for collection.
Specify analysis method for conducting the

data analysis.
Reporting procedure covers the report

templates, recipients, frequency and means of
communication.
Baseline information is the data provided

immediately before or at the beginning of a
period. Baseline data is used learn about
recent performance and to measure progress
from that point forward.
Ensure quality of indicators and metrics:

reliability, validity and timeliness.
Reporting
Reports compare baseline, current metrics and

target metrics. Trends are usually more
credible and important than absolute metrics.
Visual presentations tend to be more effective
than tables.
Strengths
 Allows stakeholders to understand the extent

to which a solution meets an objective
 Facilitate organizational alignment, linking

goals to objectives, supporting solutions,
underlying tasks and resources.
Limitations
 Data collection, analysis and reporting can

be expensive.
 Can distract project members from other

responsibilities, especially on agile
projects.
 Can become bureaucratic, expensive and

useless.
 Mostly no feedback is provided to

stakeholders collecting metric data as to
understand how their actions are affecting
the quality of the project results.
 Can lead to sub-optimal performance when

metrics are to assess performance.
2.29 Mind map

Mind mapping helps in articulating and
capturing ideas in a non-linear (tree)
structure. Ideas are grouped as topics, sub-
topics, further sub-sub-topics. Mind maps use
words, images, colour, and connections to
structure thoughts, ideas, and information.
Strengths
 Effective collaboration and communication

tool.
 Structures complex thoughts, ideas, and
information.
 Facilitate understanding and decision
making.
 Enable creative problem solving.
Limitations
 Can be misused as a brainstorming tool.

 Can become complex with details.
2.30 Non-functional requirements analysis
Non-functional requirements (NFRs) analysis

examines the requirements for a solution that
define how well the functional requirements
MUST perform.
Such requirements are also known as quality

attributes or quality of service requirements.
NFRs are generally expressed in textual

formats as declarative statements or in
matrices
NFR categories
Availability Extent to which solution is operable and

accessible when required.
Compatibility Ability to co-exist and interact with other

applications.
Functionality Extent to which user needs are met by the

solution functions.
Maintainability Ability to change one component without

affecting others and without causing unexpected
failures, ability to re-use components and
testability.
Performance Time taken to perform activities and resource

efficiency utilization levels.
Portability How easy it is to transfer a solution or

component from one environment to another.
Reliability Measure of application being available when

needed. Includes ability of the application to
recover from errors, uptime, or failures in
interfaces.
Scalability Extent to which a solution is able to evolve to

handle increased amounts of work.
Security Ability to ensure appropriate confidentiality

and integrity of information, to verify when
actions were taken and by whom and to
authenticate users.
Usability How easy it is for a user to learn how to use

the solution.
Certification Constraints on the solution which is necessary

to meet certain standards or industry
convention.
Compliance Legal, financial or regulatory constraints

which can differ based on the scenario.
Localization Requirements which deal with local languages,

laws, currencies, cultures, spellings etc.
Service Level Organization constraints which are agreed upon

Agreements by the provider and user of the solution.
Extensibility Whether the solution is able to incorporate new

functionality.
Non-functional requirements MUST be quantified

to the extent possible in order to be
verifiable and also add value to developers.
Few examples are:
 90% of operators shall be able to use all

the functionality of the system in 6 hours
of training.
 The system shall provide 90% of responses

in less than 2 seconds.
Business analysts may also have to modify the

non-functional requirements based on the
relative stability of the context.
Strengths
 Provides measurable expressions of how well

the functional requirements MUST perform.
 Clearly states the constraints applicable

to a set of functional requirements.
Limitations
 More difficult to articulate and define

than Functional requirements.
 Usefulness depends on the how well the

stakeholders can express their needs.
 Getting agreement on NFRs can be difficult.
 Overly stringent NFRs significantly

increase cost and effort for development.
 Many NFRs are difficult to measure on a

scale.
2.31 Observations
To elicit information by observing activities

and their context.
2 types of observations are:
Active/Noticeable observation – Observer asks

questions during the process. May interrupt
the work flow but helps in gaining a quick
understanding.
Passive/Unnoticeable observation - Observer

asks questions at the end and does not cause
interruption to work.
During observation, collect requirements by

conducting an assessment of the stakeholder’s
work environment.
This is useful for:
 Documenting details about current processes.
 When the project’s objective is to enhance

or change a current process.
 Stakeholders are unable to express the

requirements well.
Some possible variations of observations are:
 Stronger intervention in actor’s activities

by asking them to perform specific tasks.
 Participating in actual work to get a hands-

on feel. Limit this to activities
appropriate for a non-expert to perform and
whose results would not negatively impact
business.
 Becoming temporary apprentice.
 Video recording the activity and viewing it

with the observed person to get further
details.
Steps for observation
Observation objectives
 Have a clear and specific objective about

the observation.
Prepare for observation
 Determine activities to observe.
 Identify sample users (e.g. experts and

novices or just experts) to observe.
 Prepare observation questions.
Conduct the observation session
 Explain reason for the observation.
 Assure participants that the sole purpose is

to gather requirements.
 Inform participants that you are present

ONLY to study their processes.
 Inform users to stop the observation process

if it interferes with their work.
 Attentively watch the activity.
 Record what you see, time taken, quality of

work, process anomalies etc.
 Ask questions while the work is being

performed or after the observation session.
Confirm and present observation results
 Review notes and recorded data.
 Follow up with participants to obtain

further clarification.
 Share notes and data with participants to

ease any concerns that they may have.
 Validated notes and data are collated with

other related observations.
 Findings are summarized, analyzed and

opportunities for improvement are
communicated with stakeholders.
Strengths
 Provides realistic and practical insight

into business processes.
 Productivity can be directly viewed and

compared with standards or performance
metrics.
 Identify informally performed tasks or work-

arounds which may not be documented.
 Recommendations for improvement are based on

evidence
Limitations
 Possible for existing processes ONLY.
 Time-consuming.
 Can be disruptive.
 Participants may alter work practices when

observed.
 Can’t help in evaluating knowledge based

activities as they can’t be observed.
2.32 Organizational model

Organization modelling describes roles,
responsibilities, and reporting structures
that exist within an organization, and aligns
those structures with the organization’s
goals.
An organizational model is a visual

representation of the organizational unit
which defines:
• Members in the group

• Who reports to whom
• Functional role for each person, and
• Interfaces between the unit and other units
or stakeholders.
Organizational models are categorized into

three types based on:
Functions: Functionally oriented organizations

groups staff together based on shared skills
or areas of expertise. They encourage a
standardization of work or processes within
the organization.
Markets: The term “market-oriented” covers a

number of different possible ways of
organizing an enterprise. It is primarily
intended to serve particular customer
segments, geographical areas, projects or
processes rather than group employees based on
common skills or expertise. Market-oriented
structures enable the organization to be
better oriented with the needs of its
customers, but may develop inconsistencies in
work performance, and duplicate work in
multiple divisions.
Matrix: In matrix model, there are separate

managers for each functional area, and for
each product, service, or customer group.
Staff report to:
 A line manager, who is responsible for the

performance of a type of work, and for
identifying opportunities for efficiency in
the work, and
 A market (product/service/project/etc.)
manager, who is responsible for managing the
product, service, etc. across multiple
functional areas.
Organizational unit comprises of a number of

defined roles and has interfaces with other
organizational units. Organizational charts is
the main diagram for organizational modelling.
BAs also identify influencers in the
organization.
Strengths
 Common in most organizations.
 Including it in BA information enables

future projects to know the participants
involved and their roles.
Limitations
 Out of date at times
 Difficult to figure out the influencers in

the organization
2.33 Prioritization
Prioritization provides a framework for
stakeholder decisions and to understand the
relative importance of business analysis
information. The importance may be based on
value, risk, difficulty of implementation, or
other criteria.
Grouping
Classify into high, medium, or low priority.
Ranking
Rank orders from most to least important.
Time Boxing/Budgeting
Based on the allocation of fixed resources
such as time (duration) or budget (a fixed
amount of money). Used frequently when the
solution approach has been determined.
Negotiation
Establishing a consensus among stakeholders as
to priority requirements.
Strengths
 Facilitates consensus building and trade-
offs
 Ensures solution value is realized,
 Assists in meeting initiative timelines.
Limitations
 Stakeholders avoid difficult choices and do
not make trade-offs.
 Solution team may intentionally or
unintentionally try to influence
prioritization process by overestimating
difficulty or complexity of certain
requirements.
 Absence of metrics and KPIs may make the
process subjective.
2.34 Process analysis
Process analysis analyzes processes for their

effectiveness, efficiency and identifies
improvement opportunities.
Process analysis is used for various purposes

including:
a. recommending a more efficient or effective
process,
b. determining the gaps between the current and
future state of a process,
c. understanding factors to be included in a
contract negotiation,
d. understanding how data and technology are
used in a process, and
e. Analyzing the impact of a pending change to
a process.
Common process improvements include:
 Reducing execution time,

 Improving co-ordination between roles and
organizational units to remove errors,
reduction or elimination of bottlenecks,
 Automating routine or predictable steps, and
 Automating process decision making.
When analyzing a process, look for:
 Process value addition,
 Alignment to organizational goals and

strategy,
 Process needs to be efficient, effective,

repeated, measured, controlled, used and
transparent and
 How requirements for a solution cover the

future state processes.
Identify Gaps and Areas to Improve
 Identify current and desired future state

gaps,
 Identify value and non-value added

activities,
 Understand process challenges from multiple

viewpoints,
 Understand process improvement opportunities

from multiple viewpoints,
 Align improvements with strategic direction

of the organization.
Identify Root Cause
Identifying the root cause of the gaps and

improvement areas ensures that the solution
addresses the right gap and area. When
identifying the root cause, understand:
 there multiple root causes,
 Inputs leading to the gap or area of

improvement,
 Right people to identify the root cause and
 Current measurements and motivators for

those owning or performing the process.
Generate and Evaluate Options
Generate and evaluate options and alternative

solutions to solve for the gap or area of
improvement.
Common Methods
SIPOC
SIPOC (Suppliers, Inputs, Process, Outputs and

Customers) originated in Six Sigma methodology
and has been more commonly adopted as a
process analysis method outside of Six Sigma.
Value Stream Mapping (VSM)
Value stream mapping (VSM) originated in Lean

methodologies. It involves diagramming and
recording of wait time and processing times
for every processing step.
Strengths
 Ensures solutions address the right issues.
 Minimizing waste.
 Ample flexibilities with respect to

techniques and methodologies.
Limitations
 Time-consuming,
 Challenging to decide which approach to use

and how rigorously to follow them.
 Not very effective in knowledge or decision-

intensive processes.
2.35 Process modeling
Process modelling is a standardized graphical

model to describe the sequential flow of work
or activities.
A system process model defines the sequential

flow of control among programs or units within
a computer system.
A program process flow shows the sequential

execution of program statements within a
software program.
Process models can be constructed on multiple

levels.
Process models can be used to:
 Describe the context of the solution or part

of the solution,
 Describe what actually happens (as is), or

is desired to happen (to be),
 Provide an understandable description of a

sequence of activities to an external
observer,
 Provide a visual to accompany a text

description and
 Provide a basis for process analysis.
Process models generally include:
 Event (Basic)
 Activities (both manual and automated, can

be atomic or non-atomic)(Basic)
 Results (Basic)
 Participants (Role) (Intermediate),
 Paths (flows) and decisions that logically

link those activities (Intermediate)
 Data/ materials (Supplementary)
 Inputs and outputs (Supplementary) and
 Call-out descriptions (Supplementary).
Elements
Types of Process Models and Notations
1. Flowcharts and Value Stream Mapping (VSM):

Used in the business domain.
2. Data Flow diagrams and Unified Modelling

Language™ (UML®) diagrams: Used in the
information technology domain.
3. Business Process Model and Notation (BPMN):

Used across both business and information
technology domains; is increasingly adopted
as an industry standard.
4. Integrated Definition (IDEF) notation and

Input, Guide, Output, Enabler (IGOE)
diagrams: Used for establishing scope.
5. SIPOC and Value Stream Analysis: Used for

process modelling.
Flowchart
A flowchart can be simple, displaying just the

sequence of activities, or it can be more
comprehensive using swim-lanes.
Business Process Model and Notation (BPMN)
BPMN is an industry-standard that is

accessible by both business users and
technical developers. It covers many types of
modelling, including both internal (private)
processes and collaborative (public)
processes.
Activity Diagram (part of UML)
Activity diagram uses swim-lanes to show

responsibilities, synchronization bars to show
parallel processing and multiple exit decision
points.
Strengths
 MOST stakeholders understand process models.
 Multiple levels can accommodate the

different stakeholder perspectives.
 Show large number of scenarios and parallel

branches.
 Identify overlooked stakeholder groups.
 Identify potential improvements by

highlighting “pain points” in the process
structure (i.e. process visualization).
 Provide documentation for compliance

purposes
 Can be used for training and coordination of

activities.
 Can be used as a baseline for continuous

improvement.
 Ensures labelling consistency across

artifacts.
 Provides transparency and clarity to process

owners and participants on activity
responsibilities, sequence and hand-overs.
Limitations
 IT may perceive formal process models as

document-heavy approach to software
development.
 Can become extremely complex and unwieldy if

not structured carefully.
 Single individual will not be able to

understand and ‘sign off’ a complex
process.
 Cannot process problems just from the model.
 In a highly dynamic environment, process

models can become obsolete.
 Stakeholders often alter the process to meet

their needs without updating the model.
2.36 Prototyping
Prototyping is a widely used technique for

product design. Prototypes provide an early
model of the final result. It details user
interface requirements and integrates them
with other requirements such as use cases,
scenarios, data, and business rules.
Stakeholders often find prototyping to be a

concrete means of identifying, describing and
validating their interface needs.
Business rules and data prototypes can be to

discover desired process flow and business
rules.
2 common approaches to prototyping are:
Throw-away Seeks to quickly uncover and clarify interface

prototype requirements using simple tools, sometimes just
paper and pencil. Focus on functionalities which
are not easily elicited by other techniques, have
conflicting viewpoints, or difficult to understand.
Evolutionary Extends the initial interface requirements into a

or fully functioning system. Requires specialized
Functional prototyping tool or language and produces a working
prototype application.
Prototyping examples
Proof of Created to validate the system design without

Principle or modelling appearance, materials used etc.
Concept
Form Study Focuses on basic size, look and feel of the product
Prototype: and not on the functionality
Usability Model to test how end user interacts with the

Prototype system
Visual Model to test visual aspects of the solution

Prototype
Functional To test software functionality, qualities of the

Prototype system, workflow etc. Also referred to as ‘working
model’
Prototyping Methods
Storyboarding Visually and textually details the sequence of

activities
Paper Interface or process is drafted using paper and

Prototyping pencil
Workflow Shows sequence of operations that is performed.

modelling Focuses ONLY on human aspects
Simulation To demonstrate solutions or solution components
Strengths
 Supports users who are more comfortable and

effective at articulating their needs by
using pictures.
 Allows for early user interaction and

feedback.
 Throw-away prototypes can be an inexpensive

approach to quickly uncover and confirm a
variety of requirements.
 Vertical prototypes can demonstrate what is

feasible with existing technology and
identify technology gaps.
Limitations
 Can take considerable time if the process

gets bogged down by the “how’s” rather
than “what’s”.
 Assumptions about underlying technology need

to be made to initiate prototyping.
 Users may develop unrealistic expectations

regarding delivered system’s performance,
completion date and reliability and
usability characteristics. An elaborated,
detailed prototype can look similar to a
fully functional system.
 Users may focus on design specifications of

the solution rather than the requirements
that the solution MUST address. This can
constrain the solution design.
 Developers may believe that they MUST

provide a user interface that precisely
matches the prototype, even if superior
technology exists.
2.37 Reviews
Reviews are performed to communicate, verify

and validate the content of work products.
Different types of reviews are conducted based

on the objectives of review, techniques used
and participants to be included.
Objectives of review
Communicate objectives well in advance to the

participants which may be one or more of the
following:
 Removal of defects
 Check for conformity to specifications or
standards
 Check for complete and correct work product
 Work product quality measurement
 Establishment of consensus on approach or
solution
 Issue resolution, alternative exploration or
education of reviewers about work product
Review techniques can be formal or informal.
MOST commonly used techniques by business

analysis are:
Formal techniques
Inspection Here, the focus is to remove defects and

create a high quality product. Includes review
of work product as well as follow up to ensure
changes have been implemented
Formal Technique that uses the individual review and

Walkthrough (also team consolidation activities
known as Team
Review)
Single Issue Focuses on either one issue or a standard

Review (also
known as
Technical Review)
Informal techniques
Informal Informal technique conducted when the work

Walkthrough product is in draft state and calls for
feedback
Desk Check Informal technique where a reviewer who was

not involved in creation of the work product
provides a feedback
Pass Around Multiple reviewers provide verbal or written

feedback
Ad hoc Seeks informal review or assistance from a

peer.
Role of participants vary depending on objectives of the review,

the selected technique and any existing organizational standards.
Roles in review
Mandatory?
Role Played by Responsibility Applicable

techniques
Author Yes Author of Answers questions All

requirements about the
document, document, listens
typically to suggestions,
the business comments.
analyst. Incorporates
changes after the
review session.
Reviewer Yes A peer or Reviews All

stakeholder. requirements
document prior to
the working
session. Presents
questions,
comments,
suggests changes
and discusses
them with the
group.
Facilitator Yes Must be Facilitates the  Inspection

neutral. review session.
 Formal
Ideally Keeps
author participants  Walkthrough
should not focused each
 Helpful for
be moderator section of the
single
in order to requirements
issue
avoid document as it is
review
compromising discussed.
the review Verifies all
participants have
reviewed the
document before
the session
begins. Ensures
that all
participants are
participating in
the review.
Scribe No Neutral Documents all  Inspection

participant suggestions,
 Formal
with strong comments,
communication issues,  Informal
skills concerns, Walkthrough
outstanding
questions that
rose during the
review.
Strengths
 Promotes stakeholder discussion and

involvement to come up with a quality
output.
 Identifies possible ambiguities and areas of

misunderstanding early on.
 Desk checks and pass around reviews can be

performed by a reviewer at a convenient
time.
Limitations
 Rigorous team reviews can be time consuming.
 Informal reviews are more practical but may

not ensure complete removal of significant
defects.
 Difficult to validate whether independent

review was carried out by each participant
in desk check and pass around type of
reviews.
 Can lead to repeated revisions if changes

are not carefully managed.
 Sharing and discussing review comments over

e-mail can elongate the approval process.
2.38 Risk analysis
Identify uncertainties that could negatively

affect value, analyze and evaluate those
uncertainties and develop and manages way of
dealing with the risks.
Risk Identification
Use expert judgment, stakeholder input,

experimentation, past experiences and
historical analysis of similar initiatives.
Identify comprehensive set of relevant risks
and to minimize the unknowns. This is an
ongoing activity.
Record risks in a risk register.
Risk information Residual
Risk event Cons. Prob. Impact Risk Mitigation Owner Prob. Impact Risk
or Level Level
condition
Analysis
Understand the risk and estimate level of a

risk. Consider existing controls when
analyzing the risk.
Scope Quality Cost Effort Duration Reputation Social

resp.
Low
Medium
High
Evaluation
Compare risk analysis results with potential

value of the change to determine if the level
of risk is acceptable or not. Add risk levels
to obtain overall risk level.
Treatment
Common approaches for dealing with risks are:
Avoid: Remove source of the risk so that the

risk does not occur.
Transfer: Liability for dealing with the risk

is moved to, or shared with, a third party.
Mitigate: Reduce risk probability or the
possible negative consequences.
Accept: Decide not to do anything about the

risk. If the risk does occur, a workaround
will be developed at that time.
Increase: Decide to take on more risk to

pursue an opportunity.
Strengths
 Can be applied at multiple levels -

strategic, tactical or operational risks.
 Often, similar risks affect many

initiatives. Successful risk responses on
one initiative can be useful for others.
 Ongoing risk management helps to re-

evaluate the risks and the suitability of
the planned responses.
Limitations
 # of possible risks can easily become

unmanageably large.
 It may ONLY be possible to manage a subset

of potential risks.
 Often significant risks may not be

identified.
2.39 Roles and permissions matrix
Roles and permissions matrix ensures coverage

of activities by denoting responsibility, to
identify roles, to discover missing roles and
to communicate results of a planned change.
This can be at different levels such as

initiative level roles and responsibilities
such as RACI (Responsible, Accountable,
Consulted and Informed) matrix, or specific
information technology system roles and
responsibilities identified in a CRUD (Create,
Read, Update and Delete) matrix.
Group 1 Group 2 Group 3
Activity Role Role Role Role Role Role Role Role Role
1 2 3 4 5 6 7 8 9
Create X X X
project
View X X X X X X X X X
project
Identifying Roles
Review organizational models, job

descriptions, procedure manuals and system
user guides and discuss with stakeholders to
uncover roles.
Look for common functions that are performed

by individuals with similar needs.
Identifying Activities
Use functional decomposition, process

modelling and use cases to identify
activities.
Identifying Authorities
Authorities are actions that identified roles

are permitted to perform. For each activity,
identify authorities for each role.
Refinements
Delegations
Identify which authorities can be delegated by

one individual to another on a short-term or
permanent basis.
Inheritances
Automatic assignment to subsidiaries.
Strengths
 Provides procedural checks and balances, as

well as data security, by restricting
individuals from performing certain actions.
 Promotes improved review of transaction

history, in that audit logs can capture
details about any assigned authorities at
the time.
 Provides documented roles and

responsibilities for activities.
Limitations
 Need to recognize the required level of

detail for a specific initiative or
activity;
 Too much detail can be time consuming, too

little detail can exclude necessary roles.
2.40 Root cause analysis (RCA)
Root cause analysis (RCA) helps in identifying

and evaluating the underlying causes of a
problem. RCA mainly looks into causes
occurring due to people, physical or
organizational effects.
Root cause analysis can be used for:
Reactive analysis: Identifying root causes for

corrective action
Proactive analysis: Identifying problem areas

for preventive action
Four main activities used in RCA are:
Problem Statement Definition
Data Collection
Cause Identification
Action Identification
2 popular tools for RCA are Fish-bone diagram

and Five-whys.
Fish-bone diagram
Fishbone diagrams (also known as Ishikawa or

Cause-and-effect diagram) are to identify and
organize possible causes of a problem.
Fishbone diagram helps to focus on the cause

of the problem versus the solution and
organizes ideas for further analysis.
Steps to develop a cause-and-effect diagram:
1. Capture the issue or problem in a box at the

right end of the diagram.
2. Draw a line from the box across the paper or

white board (forming the spine of the
fishbone).
3. Draw diagonal lines from the spine

representing major categories of potential
causes (people, process, tools and
policies).
4. Draw smaller lines to represent deeper

causes on each major cause.
5. Brainstorm categories and potential causes

of the problem and capture them under the
appropriate categories.
6. Analyze the results. Remember that the group
has identified ONLY potential causes of the
problem. Further analysis is needed to
validate the actual cause, ideally with
data.
7. Brainstorm potential solutions once the

actual cause has been identified.
Five-whys
Five-whys is a process of repeatedly asking

questions to find out the root cause of a
problem.
This is one of the simplest facilitation tools

to use when problems have a human interaction
component.
Steps to use:
1. Write the problem on a flip chart or white

board.
2. Ask “Why do you think this problem

occurs?” and capture the idea below the
problem.
3. Ask “Why?” again and capture that idea

below the first idea.
4. Continue with step 3 until you are convinced

the actual root cause has been identified.
Five-whys may take more or less than five

times of asking why. The technique is called
five-whys because often it takes that many
whys to reach the root cause, not because it
MUST be asked five times.
Five-whys can be used alone, or as part of the

fishbone diagram technique. Once all ideas are
captured in the diagram, use five-whys
approach to drill down to the root causes.
Strengths
 Structured method to identify root causes of

identified problems.
 Helps stakeholders to come up with effective

solutions for corrective action.
Limitations
 May need formal training or extensive

experience to facilitate a team of experts.
 May prove to be difficult with complex

problems.
2.41 Scope models
Scope models describe scope of analysis or

scope of a solution. They serve as a basis for
defining and limiting the scope of business
analysis and project work.
Scope models may show elements that include:
In-scope: Elements contained by the boundary

(as seen from inside). E.g.: Functional
decomposition.
Out-of-scope: Elements not contained within

the boundary (as seen from outside). E.g.:
Context diagram.
Both: Elements on both sides of the boundary

(as seen from both sides).
Scope models provide an understanding of the

boundaries of:
While considering scope of change and context,

business analysts determine:
 Business processes, functions, new

capabilities to be defined or modified,
 Use cases to be supported, technologies to

be changed, informational assets to be
acquired,
 Organizational roles and units impacted by
the change,
 External and internal events to be responded

to and impacted by the change,
 Systems, tools, assets etc. which is

required for the change or impacted by the
change.
In order to ensure completeness and integrity

of scope models, identify relationships
between potential scope elements.
Some of the diagramming techniques used for

exploring relationships are:
Parent-Child/Composition-Subset: Relates
elements of the same type by way of
hierarchical decomposition
Function-Responsibility: Relates a function

with the agent that is responsible for its
execution
Supplier-Consumer: Relates how information or

materials is transmitted between them
Cause-Effect: Logical relations identifying

aspects that are involved or impacted by
change
Emergent: Complex systems have several
elements which interact to produce results
that cannot be predicted
Scope models should explicitly state critical

assumptions and their implications. The
results can be represented as textual
descriptions, diagrams or matrices.
Strengths
 Scope model facilitates agreement as a basis

for:
Defining contractual obligations
Project effort estimation
Justification of In scope/Out of scope decisions
Assessing completeness and impact of solutions
Limitations
 High-level model may not have sufficient

details and granularity
 Changing a scope that has been defined may

prove to be difficult due to political and
contractual obligations.
 Wrong assumptions, changing needs,

technological advancements etc. may result
in a need to revising the scope
 Common complex boundaries such as a horizon

(a boundary that is completely dependent on
the position of the stakeholder) cannot be
addressed by traditional scope models
2.42 Stakeholder List, Map, or Personas
Stakeholder List, Map, or Personas are three

tools which can assist Business analysts in
analyzing stakeholders and their
characteristics.
It helps to identify all possible sources of

requirements.
Stakeholder analysis involves identifying

stakeholders affected by a proposed initiative
or share a common business need, level of
decision making authority, authority within
the domain and organization, attitude/interest
towards change, and business analysis work.
Stakeholder lists
Brainstorming and interviews are 2 common

techniques to generate a stakeholder list.
Having an exhaustive list ensures that

important stakeholders or stakeholder groups
have not been overlooked.
This helps in minimizing risks of missing out

requirements.
Stakeholder map
Represent the relationship of stakeholders to

the solution and to one another. 2 common
forms of stakeholder maps are:
Stakeholder matrix: Maps level of stakeholder

influence against level of stakeholder
interest/impact on stakeholders. Here,
stakeholders are classified into 4 quadrants:
1. High influence/High impact
2. High influence/Low impact
3. Low influence/High impact
4. Low influence/Low impact
Onion diagram: Indicates level of stakeholder

involvement with the solution and which
stakeholder directly interacts with the
solution or participate in a business process
External
stakeholders
Organization
Organizational
Unit
Project
Responsibility (RACI) matrix
RACI stands for the four types of

responsibility that a stakeholder may hold on
the initiative:
Responsible Those who will be performing the work on the task
Accountable Person who is the decision maker and who is held

accountable for successful completion of the task
Consulted Stakeholder or stakeholder group who will can be

asked for opinions or information about the task.
SMEs are generally considered for this
Informed Stakeholder or stakeholder group who is kept up to

date on the task and informed of its outcome
Personas
Persona is a fictional character or model that

depicts the way a typical user interacts with
a product.
Although the user groups are fictional, they

are built in such a way that they represent
actual users.
Personas are created based on research and

knowledge rather than opinions.
Personas are written in narrative form and

focuses on providing insight into the goals of
the group.
Strengths
 Identifies those people who MUST should be

part of requirements elicitation activities
 Helps Business analysts to plan on how to

engage all stakeholder groups
 Useful to understand changes in impacted

groups over time
Limitations
 Those who continuously work with the same

stakeholders may not use stakeholder
analysis technique as they don’t feel much
change will happen in their respective team.
 Assessing influence and interest of specific

stakeholders can be complicated and risky.
2.43 State modelling
State models (also sometimes called a state

transition model) describe and analyze the
different possible states (formal
representation of a status) of an entity
within a system, how that entity changes from
one state to another and what can happen to
the entity when it is in each state.
State models help to have a precise and

consistent understanding of an entity that has
complex behavior and complex rules about that
behavior.
A state model describes:
a. set of possible states for an entity,

b. sequence of states that the entity can be
in,
c. how an entity changes from one state to
another,
d. events and conditions that cause the entity
to change states and
e. Actions that can or MUST be performed by the
entity in each state as it moves through its
life cycle.
While a process model can show all of the

entities that are used in or affected by that
process, a state model shows a complementary
view: what happens to one entity across all
the processes that affect it or use it.
State
An entity can have many states during its life

cycle and it can be in more than one state
(Active-In progress, Inactive-Cancelled) at
the same time.
A complex state can be decomposed into sub-

states.
State transition
State transitions (can be conditional,

automatic or recursive) are determined by the
steps of a process, by business rules, or by
information content. Sequences of states of an
entity are not always linear; an entity could
skip over several states or revert to a
previous state, perhaps more than once.
State Diagram
A state diagram shows the life cycle of one

entity, beginning when the entity first comes
into existence and moving through all of the
different states that the entity may have
until it is discarded and no longer of use.
A state on a state diagram is shown as a

rectangle with rounded corners.
State Tables
A state table is a 2-dimensional matrix

showing states and the transitions between
them. It can be used during elicitation and
analysis either as an alternative, a
precursor, or a complement to a state diagram.
It is a simple way to get started on a state

model in order to elicit the state names and
event names from the domain subject matter
experts.
Strengths
 Identifies business rules and information

for the entity being modelled.
 Identifies activities that apply to the

entity at different states of the entity.
Limitations
 Consumes time and effort
 Obtaining consensus on state model can be

time-consuming.
2.44 Sequence diagram
Sequence diagrams (also known as event

diagrams) model logic of usage scenarios, by
showing the information (also known as
stimuli, or message) passed between objects
during execution of a scenario.
Sequence diagrams show how objects (interface

components or software components) used in the
scenario interact but not how they are related
to one another. Information is represented in
horizontal and vertical alignment.
Objects that send messages to each other are

represented as boxes from left to right.
Messages sent from one object to another are
represented as horizontal arrows.
Sequence diagrams show particular instances of

each object with a lifeline beneath each
object to indicate when the object is created
and destroyed. The earliest events in the
scenario are depicted at the top of the
lifeline, with later events shown further
down.
Arrival of the stimulus at the object is

called an event.
Sequence diagrams ONLY specify ordering of

events, not exact timings of events.
An activation box represents the period during

which an operation is executed.
A message is shown as an arrow pointing from

the activation box of the object sending the
message to the activation box of the object
receiving it.
Message name is placed on top of the arrowed

line. The types of messages sent between
objects are:
Synchronous call transfers the control to the

receiving object. The sender cannot act until
a return message is received.
Asynchronous call (also known as a signal)

allows the object to continue with its own
processing after sending the signal. The
object may send many signals simultaneously,
but may ONLY accept one signal at a time.
Strengths
 Shows interactions between objects in visual

and chronological order.
 Use cases can be refined into sequence

diagrams to obtain more depth and detail.
Limitations
 Creating sequence diagram for each and every

use case can be a waste of time and effort.
 Generally used for modelling system flows

and is considered too technical otherwise.
2.45 Survey and questionnaires
A survey, also known as questionnaire, can

elicit information from many people, sometimes
anonymously, in a relatively short period of
time.
It can collect information about customers,

products, work practices and attitudes.
A survey administers a set of written

questions to stakeholders and SMEs.
Alternatively, respondents are provided with a

series of statements and asked for their level
of agreement. Responses are analysed and
distributed to appropriate parties.
Survey questions are of 2 types:
Closed – Respondents select from available

responses. Typically Yes/No, multiple-choice,
rank order decision etc.
This is useful when the range of user’s

responses is defined well and understood.
Responses to closed questions are easier to
analyse than open-ended questions as they can
be tied to numerical coefficients.
Open-ended – Respondents are free to answer

the questions as they wish. Useful when the
issues are known but the range of user
responses is unknown.
Responses to open-ended questions may provide

more detail and a wider range of responses.
However, open-ended questions are more
difficult to quantify and summarize as they
often include qualitative than quantitative
language.
Steps for Survey
Prepare for survey to ensure that the needed

information is obtained while minimizing
respondent’s time to complete it.
1. Define purpose and objective of survey
2. Identify target groups to be surveyed
3. Choose appropriate survey or questionnaire

types
4. Select the sample group. Be aware of the

group’s characteristics.
 Use information about the background of the

target group, including their environment
and specific terminology to develop
questions.
 If the target group is significantly
diverse, divide the group into smaller and
homogeneous groups during preparation stage
and then produce variations of the survey
that fit each subgroup’s background.
5. Identify distribution and collection

methods
6. Define target level and timeline for

response
7. Determine whether the survey should be

followed up with individual interviews
8. Write the survey questions
9. Perform usability test on the survey. Use

results to fine-tune the survey.
10. Focus on requirements - All questions

MUST be directed towards the stated
objectives.
11. Make the survey easy and fast to

complete, ideally not more than 5 or 10
minutes.
12. Arrange questions in an order which tells

a story.
13. Ensure question wordings are clear and
concise, using terminologies familiar to
respondents.
14. Each question MUST address a single

point.
15. Avoid the following:
 Double questions in a single question.

 Negative phrasing.
 Complex branching structures.
 Uncomfortable questions
 Information restricted by regulations.
Distribute survey or questionnaire
1. Communicate survey objectives, use of

results and arrangements for confidentiality
or anonymity. This may improve the response
rate.
2. Select distribution means according to:
 Organizational policies,
 Urgency of obtaining the results,
 Level of security required and
 Geographic distribution of the respondents.
Document survey results
1. Collate responses. Evaluate details and

identify emerging themes.
2. Analyse and summarize results.
3. Report findings to sponsor.
4. Formulate categories for encoding the data.
5. Break down the data into measurable
increments.
Strengths
 Quick and relatively inexpensive to collect

information from a large audiences.
 Does not require significant time from
stakeholders.
 Effective and efficient when stakeholders
are not located in one location.
 Closed-ended surveys are effective in
obtaining quantitative data for use in
statistical analysis.
 Open-ended surveys can provide insights and
opinions which are not easily obtained
through other techniques.
Limitations
 Open-ended surveys require more analysis.

 To achieve unbiased results, specialized
skills in statistical sampling methods are
required.
 Questions left unanswered or answered
incorrectly due to their ambiguity.
 Based on the answers provided, follow up
questions or more survey iterations may be
required.
 Response rates can be too low for any
statistical significance.
2.46 SWOT
SWOT is an acronym for Strengths, Weaknesses,
Opportunities, and Threats. SWOT analysis is a
framework for strategic planning, opportunity
analysis, competitive analysis, business, and
product development.
Strengths and weaknesses are factors internal

to the organization, organizational unit, or
solution, while Opportunities and Threats are
external factors. It can be performed at any
scale from the enterprise as a whole to a
division, business unit, project or even an
individual.
Strengths (Internal) Opportunities (External)

Anything that the External factors that
assessed group does the assessed group can
well such as take advantage of such
experienced as new markets, new
personnel, effective technology, changes in
processes, IT the competitive
systems, customer marketplace, or other
relationships, or forces.
any other internal
factor that leads to
success.
Weaknesses Threats (External)
(Internal) External factors that
Things that the can negatively affect
assessed group does the assessed group
poorly or not at all such as a new
such as not having competitor, economic
market access. downturns, or other
forces. Threats are
also outside of the
group’s control.
Strengths
 Helps quickly analyse various aspects of the
current state of the organization, and its
environment prior to identifying potential
solution options.
 Enables BAs to direct stakeholders focus to
factors which add value to the business
Limitations
 Provides a very high-level view, hence calls
for detailed analysis.
 Clear context must be established to stay
within focus.
2.47 Use cases and scenarios

Scenarios, and use cases describe how a person
or system interacts with a solution to
accomplish one or more of that person or
systems goals. Although the terms scenario,
and use case are often used loosely, a
scenario is generally understood to describe
just one way that an actor can accomplish a
particular goal, while a use case describes
all the possible outcomes of an attempt to
accomplish a particular goal that the solution
will support. Scenarios are written as a
series of steps performed by actors or by the
solution that enable an actor to achieve a
goal. A use case describes several scenarios
in the form of primary, and alternate or
exception flows.
Use case diagram

Visually depicts scope of the solution, actors
involved, use cases they interact with and
relationships between the use cases.
Relationships
Relationships between actors and use cases are
known as associations. There are two commonly
used relationships between use cases:
Extend: Allows for the insertion of additional
behaviour into a use case. Here, the base use
case gets extended by the extended use case.
The extended use case is optional and its

execution ALWAYS depends on a condition.
The specific point at which extension occurs

is called extension point.
The base use case is complete without the

extended use case where as the extended use
case is incomplete without the base use case.
It is represented by a dotted line with an
open arrow on one end.
Include: Allows for the use case to make use
of functionality present in another use case.
In Include relationship, the base use case

includes functionality of the included use
case.
The included use case is ALWAYS executed. The

base use case is incomplete without the
included functionality.
It is represented with a dotted line with open

arrow on one end.
Use case description
Name
Use cases have a unique name comprising of a
verb and noun.
Goal
Brief description of a successful outcome of
the use case from an actor’s perspective.
Actors
Any person, system, or event external to the
system under design that interacts with that
system. Each actor must be given a unique name
that represents the role they play in
interactions with the system. A particular
person may fill the roles of multiple actors
over time.
A use case is started by an actor, referred to

as the primary actor for that use case. Other
actors who participate in the use case in a
supporting role are called secondary actors.
This role does not necessarily correspond with

a job title, and should never be the name of
an actual person.
Trigger
An event (typically an action taken by a
primary actor) that initiates the flow of
event for a use case
Flow of events
Set of steps performed by the actor and the
solution during the execution of the use case.
Type of flows:
Basic, primary or main success flow

Shortest or simplest successful path to
achieve an actor’s goal.
Alternative flow: Other paths that may be

followed to achieve an actor’s goal.
Exception flow: If the circumstance does not
allow the actor to achieve their goal, the use
case is considered unsuccessful, and is
terminated.
For example, in a bank transaction, the ATM

machine asking the user to change the amount
based on account balance. Exception flows are
ones where the application fails to achieve
goal, say for example, the ATM fails to
connect to the bank server.
Post-conditions or guarantees
Any fact that must be true when the use case
is complete. It must be true for all possible
flows including primary and alternative flows.
It can be different for successful, and
unsuccessful executions of the use case.
Strengths
 Good at clarifying scope, and providing a
high-level understanding of requirements
 Narrative flow of use case description makes
it easy to understand
 Use case description articulates the
functional behavior of a system
Limitations
 Written at the higher-level of abstraction

 Flexible format of use cases may result in
capturing inappropriate or unnecessary
details
 Additional analysis and design required to
identify these common elements.
 Use cases do not relate to the design of the
solution. Hence additional effort must be
put during development phase to map use
cases to software architecture.
2.48 User story

User Stories are a brief textual description,
typically 1 or 2 sentences, of functionality
that users need from a solution to meet a
business objective. User story describes who
uses the story, the goal they are trying to
accomplish, and any additional information
that may be critical to understanding the
scope of the story.
It helps in prioritizing, estimating and

planning solutions. It is a tool for short-
term capture and prioritization of
requirements and not for long-term knowledge
retention or to provide a detailed analysis.
The only detail that needs to be included is

information that reduces the risk of
misunderstanding by developers that create the
estimate.
A user story includes:
Title: Active-verb phrase which describes the

activity that a stakeholder wants to carry out
with the system
Statement of value: There are no mandatory
structures but common formats are:
"As a <who>, I need to <what>, so that <why>."
"Given...When...Then."
Conversation: User stories help teams to

understand the feature and the value it will
deliver to the stakeholder.
Acceptance criteria: Helps the team to

understand what the solution needs to provide
in order to deliver value for the
stakeholders.
Strengths
 Stakeholders can easily understand

 Focuses on value to stakeholders
 Results in shared understanding of the
domain through collaboration while
developing user stories
 Facilitates rapid delivery and feedback
through small, implementable, and testable
slices of functionality
Limitations
 Can prove to be a challenge as detailed

specifications may not be available upfront
 Requires context and visibility. Should be
supplemented with higher level analysis and
artifacts
 May not be the best technique for
environments with regulatory restrictions or
when an organization mandates documentation.
2.49 Vendor assessment

Assess ability of a potential vendor to meet
commitments regarding the delivery and
consistent provision of a product or service.
It is done to ensure that the vendor is
reliable and organization expectations are
met.
When solutions or part of solutions are

provided by external vendors (who may be
involved in design, construction,
implementation, or maintenance of the solution
or solution components), or when the solution
is outsourced, specific requirements with
respect to the involvement of third parties
should be identified.
Ensure that the supplier is financially

secure, capable of maintaining specific
staffing levels, committing appropriately
skilled staff to support the solution, etc.
NFRs can be used to define the service levels

expected of a third party. Formal assessments
can be done through the submission of a
Request for Information (RFI), Request for
Quote (RFQ), Request for Tender (RFT), or
Request for Proposal (RFP).
Steps for vendor assessment
Determine knowledge, and expertise to be

transferred, and method of execution
Third party vendors are considered so that

they can provide knowledge, and expertise
which is not available within the
organization.
Target vendors with particular expertise in

methodologies or technologies, so that their
expertise can be transferred to people within
the enterprise.
Determine licensing, and pricing models
Solutions with similar functionalities may

differ greatly in licensing models. Analyse
different usage scenarios to determine which
option will provide the best benefit to cost
ratio.
Determine product reputation, and market

position
Compare each vendor with the competitors and

decide with which player the organization
wants to get involved.
Determine terms, and conditions
Determine if the services provided by the
vendor is temporary or permanent. Consider
challenges in vendor’s licensing terms, and
technology while transitioning to another
vendor.
Vendor’s use of, and responsibility for

protecting integrity of organization’s
confidential data, customization terms for the
product etc. are considered.
Determine vendor reputation
Vendor’s experiences with other customers

provide valuable information on how likely the
vendor will be able to meet its contractual,
and non-contractual obligations. Evaluate
vendors for conformance, and compliance with
external relevant standards for quality,
security, and professionalism.
Determine vendor stability
Determine vendor’s ability to provide the

required services in future. Mitigate risks
with respect to vendor financial difficulties.
Also ensure to maintain, and enhance the
solution even if the vendor’s situation
changes radically.
Strengths
 Reduces risk of developing a relationship

with an unsuitable vendor.
 Improved long-term satisfaction with the
decision.
Limitations
 Can be time-consuming to gather sufficient

information on multiple vendors.
 Risk of failure as the partnership evolves
cannot be prevented
 Subjectivity may bias the evaluation
outcome.
2.50 Workshops
Requirements workshop, also known as JAD
(Joint application design) session, is a
highly productive focused event attended by
carefully selected key stakeholders, and SMEs
for a short, intensive period (typically one
or a few days). Workshops may be used to
generate new ideas for features or products,
reach an agreement on a topic or review
requirements.
An experienced, neutral facilitator must

facilitate requirements workshop. A scribe
documents the requirements, and outstanding
issues.
Business analyst may act as the facilitator or

scribe and can also be a participant in case
she is an SME on the topic. However, she must
approach the participant role with caution, as
she may unduly bias the requirements towards
her own viewpoints, and priorities.
Prepare for requirements workshop
 Clarify stakeholders’ needs, and purpose of

the workshop.
 Identify critical stakeholders for the
workshop.
 Identify facilitator and scribe.
 Define workshop’s agenda.
 Determine how to document outputs of the
workshop.
 Schedule sessions and send invitations.
 Arrange logistics, and equipment, including
seating, flipcharts, projectors etc.
 Send materials in advance to so that
attendees come prepared. This increases
workshop productivity.
 Conduct pre-workshop interviews with
attendees to ensure the purpose of the
requirements workshop is understood, and
aligned with the needs the attendees.
Workshop Roles
Sponsor Has ultimate accountability

for the outcome of the
workshop. Not a frequent
participant
Facilitator Introduces goals, agenda,
rules, facilitates decision
making and conflict
resolution, gives
participants a chance and
ensures they don’t deviate
from the topic
Scribe Documents decisions in a pre-
determined format. Keeps
track of items deferred
during the session
Timekeeper Keeps track of time spent on
each item in the agenda
Participants Key stakeholders and SMEs
Conduct requirements workshop
 State purpose of the workshop and desired

outcomes
 Establish agreed upon ground rules
 Maintain focus by frequently validating
workshops activities with the stated
objectives.
Post requirements workshop wrap-up
 Follow up on any open action items recorded

at the workshop.
 Complete documentation, and distribute it to
workshop attendees.
Strengths
 Helps in getting detailed requirements in a

short time.
 Means for stakeholders to collaborate, work
together to reach consensus, make decisions,
and gain mutual understanding of
requirements.
 Costs are lower than cost of performing
multiple interviews as interviews may yield
conflicting requirements, and resolving the
same can be very costly.
 Stakeholders can immediately validate
facilitator’s interpretation of
requirements, so feedback is immediate.
Limitations
 Difficult to schedule due to stakeholder

unavailability.
 Success is highly dependent on the expertise
of the facilitator, and knowledge of the
participants.
 Too many participants can slow down the
workshop process.
 Not collecting inputs from all participants
can lead to overlooking of important
requirements.
--------End of the document---------

BABoK V3 Techniques PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

BABoK V3 Techniques PDF

Загружено:

Авторское право:

Доступные форматы

BABoK® V3 Techniques 2017 Edition

All rights reserved.

IIBA®, BABOK®, CBAP®, CCBA®, ECBA® are registered Trademarks of

All trademarks of copyrights mentioned herein are the possession

Contents of this document should not be disclosed to any

This publication used in assisting aspirants for CBAP®

2006-17 ©Adaptive Processes Think BA. Think Adaptive! Page 2 of 221

As the book title suggests, this book is a guidebook on BABoK V3

This book is authored by qualified CBAP® trainers who have helped

They are also regular trainers for CBAP®, CCBA®, ECBA®

Feedbacks and suggestions on the book

2006-17 ©Adaptive Processes Think BA. Think Adaptive! Page 3 of 221

1. PREFACE AND INTRODUCTION .................................. 12

1What is business analysis? ................................... 12

2. BUSINESS ANALYSIS TECHNIQUES .............................. 28

2.1 Acceptance and Evaluation criteria ...................... 28

2006-17 ©Adaptive Processes Think BA. Think Adaptive! Page 4 of 221

2006-17 ©Adaptive Processes Think BA. Think Adaptive! Page 5 of 221

2006-17 ©Adaptive Processes Think BA. Think Adaptive! Page 6 of 221

Adaptive Processes is a leading Key facts

 200+ Clients across the

 10+ Fortune 500 clients.

 200+ workshops in India,

2006-17 ©Adaptive Processes Think BA. Think Adaptive! Page 7 of 221

Our key clients

2006-17 ©Adaptive Processes Think BA. Think Adaptive! Page 8 of 221

Category Course Name

Business analysis Certified Business analyst Professional

Business analysis Certification of Competency in Business

Business analysis Entry Certificate in Business Analysis

Business analysis Certified Professional in Requirements

Business analysis Elicitation techniques

Business analysis Requirements modeling using UML

Business analysis Behavioral skills for BAs

Business analysis The ACE business analysis program

Agile Certified Agile Practitioner

Agile Introduction to Agile and Scrum

2006-17 ©Adaptive Processes Think BA. Think Adaptive! Page 9 of 221

BSC Balance Score Card

CMMI CMMI for Services

CMMI Introduction to CMMI for Development

CMMI CMMI Implementation Workshop

CoBIT Introduction to COBIT

Excel Excel for Executive Managers

ISO 27001 Certified ISO 27001 Implementer

ISO 27001 Certified ISO 27001 Internal Auditor

Project Management Introduction to MS-Project

Project Management Project Management Basics

Project Management Program Management Professional

Project Management Stakeholder Management

Six Sigma Six Sigma Green Belt

Project Management Certified Software Team Lead

Software Engineering Configuration Management

2006-17 ©Adaptive Processes Think BA. Think Adaptive! Page 10 of 221

Software Engineering Good Programming Practices

Software Engineering Introduction to Software Quality

Software Engineering Requirements Management

Software Engineering Software Engineering Principles

Software Engineering Introduction to Software QA

Software Engineering Software Reviews

Software Engineering Software Testing Principles

Software Engineering Software Metrics

Software Engineering Statistics for Project managers