32 Important Techniques for CBAP Certification Examination


Important Techniques for CBAP Certification Examination

This again is a very frequent question that we receive from our CBAP participants. BABoK V3 has 50 techniques and obviously, all techniques would not be of equal importance for all three certifications. Some techniques are more important to junior business analysts and some techniques are used more by the Senior Business Analysts.

In this article, we are going to categorize the techniques into three categories based on their complexity levels. Low complexity techniques are more useful for ECBA aspirants. Medium and high complex ones are more important for CBAP examination aspirants. High complexity techniques would require CBAP practitioners more time and effort to understand and be comfortable with.

You must be wondering how did we come up with this list?

It’s primarily based on inputs from many of our past CBAP participants regarding what kind of techniques challenged them more during the CBAP certification examination. Secondly, most business analysts start their careers as requirements analysts and as part of requirement analysis work, they use some techniques more extensively than others. Techniques that typically belong to strategy analysis planning and solution evaluation are the techniques where usually many have a lesser comfort level and obviously, they need to pay more attention to those techniques. Three specific areas that we would advise CBAP participants to pay attention are the techniques related to Financial Analysis, Decision Analysis, and UML.

Here is a summary of important techniques for CBAP certification:

Techniques Purpose of the technique Key elements
Estimation Estimation techniques are used for better understanding of the possible range of costs and efforts associated with any change.

Types of estimation:

  • Top-down
  • Bottom-up
  • Parametric
  • Rough order of magnitude (RoM) / Ballpark
  • Rolling wave
  • Delphi
  • PERT (Program Evaluation Review Technique)
Interface analysis An interface is a connection between 2 components or solutions. Identify interfaces and interactions between solutions and/or solution components Types of interface:
  1. User interfaces - Users interacting with system plus reports.
  2. Data interfaces between systems.
  3. Application programming interfaces (APIs).
  4. Hardware devices.
  5. Business processes.
  6. External partners.
Stakeholder list, map, or personas Identify stakeholders affected by a proposed initiative or share a common business need, level of decision-making authority, authority within domain and organization, attitude/ interest towards change, and business analysis work. RACI Matrix:
Scope modeling Describe the 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 model can include:

  1. Business processes, functions, capabilities to be defined or modified.
    Use cases to be supported.
  2. Technologies to be changed.
  3. Organizational roles and units impacted.
  4. Events to be responded to and impacted.
  5. Systems, tools, assets required for change or impacted by a change
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 1 or a few days).

Roles during the workshop:

Focus groups Elicit ideas, impressions, preferences, and needs and attitudes from pre-qualified individuals about a specific product, service or opportunity in an interactive group environment. Guided by a moderator. Typically, 1 to 2 hours with 6-12 attendees. Can be carried out for products under development, to be launched, in production
Collaborative games Uses game playing techniques to collaborate in developing a common understanding of a problem or a solution. Involves strong visual or tactile (activities) elements such as moving sticky notes, writing on whiteboards, or drawing pictures. Example collaborative games:
Product box
Affinity map
Benchmarking and market analysis Benchmarking compares org. practices against best-in-class practices from competitors, government, industry associations or standards.
Market analysis understands customers’ needs, factors influencing purchase decisions, and studies competitors.
Key principle: No criticism.
Prototyping Provides an early model of the final result, widely used for product design. Details UI requirements and integrate 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. Prototypes can discover the desired process flow and business rules. Throw-away prototype
An evolutionary or Functional prototype
Business rules analysis Business policies dictate actions of an enterprise and people in it by broadly controlling, influencing, or regulating them. Business rules serve as a criterion for guiding behavior and making decisions in a specific, testable manner.
  1. Use business terminology for validation.
  2. Documented independently from enforcement.
  3. Stated in a declarative format at the atomic level.
  4. Maintained in a manner enabling monitoring and adaption as they change.
Balanced scorecard A strategic planning and management tool to measure org. performance beyond traditional financial measures aligned to organization's vision and strategy. 4 dimensions of balanced scorecard are:
Learning and growth dimension
Business process dimension
Customer dimension
Financial dimension
Business capability analysis Capability maps provide a graphical view of capabilities. Capabilities describe the ability of an enterprise to act on or transform something that helps achieve a business goal or objective. Capabilities describe the outcome of performance or transformation, not how it is performed.  
Business cases Formally or informally, justify investments based on estimated value compared to cost. Spend time and resources on business case proportional to the size and importance of its potential value. Business cases do not provide intricate details.


  1. Define needs.
  2. Determine desired outcomes.
  3. Assess constraints, assumptions, and risks.
  4. Recommend solutions.
Business model canvas Comprises 9 building blocks describing how an organization intends to deliver value.
As a diagnostic tool, use elements of the canvas as a lens into the current state of business, especially wrt relative amounts of energy, time, and resources currently invested in various areas.
The 9 building blocks:
Key partnerships
Key activities
Key resources
Value proposition
Customer relationships
Customer segments
Cost structure
Revenue streams
Decision analysis Supports decision-making in complex, difficult, or uncertain situations. Examines and models possible consequences of different decisions. Values, goals and objectives relevant to decision problem.
Nature of decision to be made.
Areas of uncertainty that affect a decision.
Consequences of each possible decision.
Decision modeling Show how repeatable business decisions are made using data and knowledge.  
Financial analysis Explore financial aspects (benefits and costs) of an investment. Cost of change
The total cost of ownership (TCO)
Opportunity cost
Sunk cost
Net benefit
Return on investment
Payback period
Discount rate
Free cash flow
Risk analysis and management Identify, analyze and evaluate uncertainties that could negatively affect value, develop and manage way of dealing with risks.

Risk management techniques are:

Concept modeling Organizes business vocabulary, usually starting with the glossary. Organizing, managing and communicating core knowledge,
Need to capture large numbers of business rules,
Stakeholders find it hard to understand data models,
Regulatory or compliance challenges.
Data dictionary Standard definitions of primitive data elements, their meanings, allowable values, how those elements combine into composite data elements. Used to manage data within a solution’s context, often used along with ER diagrams. Data elements can be primitive or composite
Data modeling The data model describes entities, classes or data objects relevant to a domain, their attributes, and relationships among them.  
Data flow diagrams Show transformation of data from (data source such as external sources, activities, and destination). Data used in DFDs should be described in a data dictionary. Highest level diagram (Level 0) is context diagram represents the entire system.  
Process modeling Graphical model to describe the sequential flow of 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.
  1. Describes the context of the solution or part of the solution,
  2. Describes current (as is), or is desired (to be) process,
  3. Provides a visual to accompany a text description and
  4. Provides a basis for process analysis.
Sequence diagrams Sequence diagrams (also known as event diagrams) model logic of usage scenarios, by showing information (also known as stimuli, or message) passed between objects during the execution of a scenario.  
State modeling State models (also sometimes called a state transition model) describe and analyze 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.
  1. Set of possible states (Statuses) for an entity,
  2. sequence of states that entity can be in,
  3. how an entity changes from one state to another,
  4. events and conditions that cause the entity to change states and
  5. Actions that can or must be performed by an entity in each state as it moves by its life cycle.
User stories 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. A user story describes actor (who uses story), the goal they are trying to accomplish, and any additional information to be critical to the understanding scope of the story. Parts of a user story:
Statement of value.
Acceptance criteria
Use cases and scenarios Scenarios and use cases describe how actors (a person or a system) interacts with a solution to accomplish one or more of that person or systems goals.  
Non-functional requirements analysis Examines requirements for a solution that defines how well functional requirements must perform. Also known as quality attributes or quality of service requirements. Expressed in textual formats as declarative statements or in matrices. NFR categories are:
Availability, Compatibility
Functionality, Maintainability, Performance efficiency,
Portability, Reliability,
Scalability, Security,
Usability, Certification
Compliance, Localization, Extensibility
Metrics and key performance indicators (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 objective to be reached within a specified period.

Properties of indicators:

  1. Clear: Precise and unambiguous.
  2. Relevant: Appropriate to the concern.
  3. Economical: Available at a 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.
Process analysis Analyzes processes for their effectiveness, efficiency, and identifies improvement opportunities.  
Vendor assessment Assess the ability of a potential vendor to meet commitments wrt delivery and consistent provision of a product or service. Aspects to be careful:
Choose licensing and pricing models
Determine product reputation and market position
Determine terms and conditions
Determine vendor reputation
Determine vendor stability
Data mining Finds useful patterns and insights from large amounts of data, usually resulting in mathematical models. Utilized in either supervised (user poses a question) or unsupervised (pure pattern discovery) investigations.

Elicit requirements
Data preparation:
Analytical dataset
Analyze data
Modelling techniques


Author: L N Mishra, Co-Founder, Adaptive US

L N Mishra co-founded Adaptive US, a business analysis skill development organization, working with professionals from 80+ countries in skyrocketing their BA career and staying ahead of the game. He has helped 5000+ BA professionals to achieve better salary and role in their BA career. He is the ONLY trainer who holds all 7 certifications from IIBA (ECBA, CCBA, CBAP, CCA, AAC, CBDA, and CPOA).

LN has authored 12 best-selling books on business analysis. He is also a Versatile trainer, coach and speaker on all IIBA Certifications.

Grab a copy of best-selling eBook - FREE 50 CBAP Exam Mock Questions Plus Comprehensive CBAP Exam Information utilized by 1000s of BA professionals to ace their IIBA exam.

LN is also a member of IIBA Question Setting Committee, mentored 100+ global clients and 3000+ Bas. He has 24+ years of working experience as a Business Analyst and conducted 1000+ workshops in business analysis, requirements engineering and agile, project management, requirements engineering and different BA Skilled webinars.

Please write to LN if your thoughts are in sync with his or if they spark a thought in you.

  • Email: [email protected]
  • LinkedIn: https://www.linkedin.com/in/lnmishra-ba-trainer/
  • Website: www.AdaptiveUS.com



Copyright 2006-2024 by Modern Analyst Media LLC