Free Practice Questions for IIBA CBAP Exam

A RACI chart is a tool that helps to define and clarify the roles and responsibilities of different stakeholders in a project or a process. It stands for Responsible, Accountable, Consulted, and Informed, which are the four types of tasks or activities that stakeholders can be involved in. A RACI chart is a matrix that lists the tasks or activities in the left column and the stakeholders or roles in the top row. For each task or activity, the RACI chart indicates who is Responsible, Accountable, Consulted, or Informed by using the letters R, A, C, or I. A RACI chart can help to improve communication, collaboration, and accountability among stakeholders, and to avoid confusion, duplication, or conflict of roles. A RACI chart can be used as part of the stakeholder analysis process, which is the process of identifying, categorizing, and assessing the stakeholders of a project or a process, and understanding their needs, expectations, and interests.

References:

RACI Chart - a how to guide to using RACI, paragraph 1

How the RACI Matrix Streamlines Stakeholder Engagement, paragraph 1

Stakeholder Wrangling 101: The RACI Framework, paragraph 1

[A Guide to the Business Analysis Body of Knowledge (BABOK Guide)], version 3, page 30, section 2.51

An assumption is something that is believed to be true or certain to happen, without proof. Assumptions are often used to fill in the gaps of incomplete or uncertain information, and they can affect the analysis of the current and future states. In this question, the project manager is assuming that her project team members have a certain skill, without verifying it. This is an example of an assumption that should be identified and validated as part of the assessment of capability gaps.

The other options are not assumptions, but rather:

B. A constraint, which is a restriction or limitation that affects the performance or outcomes of a project or solution.

C. A requirement, which is a condition or capability needed by a stakeholder to solve a problem or achieve an objective.

D. A risk, which is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project or solution objectives.

References:

CBAP® Handbook, page 14, section 4.1.2.2

BABOK® Guide, page 30, section 3.2.1

CBAP / CCBA Certified Business Analysis Study Guide, page 94, section 3.2.1

The solution approach is the process of defining the most feasible and appropriate way to implement a change that addresses a business need. It involves identifying and evaluating different options for creating or acquiring new capabilities, such as products, services, processes, or systems, that will deliver value to the stakeholders and solve the business problem. The solution approach also considers the constraints, risks, assumptions, and dependencies that may affect the solution. The solution approach provides the basis for defining the solution scope, which specifies the features and functions of the solution, and the project scope, which specifies the work required to deliver the solution123.

The other options are not correct definitions of the solution approach. Option A is the definition of scope change control, which is the process of managing and documenting the changes to the product scope as approved by the project stakeholders. Option C is the definition of a risk, which is an uncertain event or condition that may have a positive or negative impact on the project objectives. Option D is the definition of decomposition, which is a technique that breaks down the project scope into smaller deliverables; each deliverable is subdivided repeatedly until the deliverable cannot or should not be broken down any further4. References: 1: BABOK® Guide v3, section 11.2 Define Solution Approach, page 402 2: CBAP® Exam Prep Study Guide, chapter 9, page 323 3: How to Choose the Right Business Analysis Approach 4: PMBOK® Guide, Sixth Edition, section 5.4.2.1 Decomposition, page 156

To calculate the break-even point, we need to compare the total costs of the internal solution and the vendor’s solution over time. The internal solution has a higher initial cost ($78,000) and a higher monthly cost ($8,765) than the vendor’s solution ($61,000 and $7,990 respectively). Therefore, the internal solution will take longer to break even with the vendor’s solution. The formula for the break-even point is:

Break-even point = (Initial cost difference) / (Monthly cost difference)

Plugging in the numbers, we get:

Break-even point = ($78,000 - $61,000) / ($8,765 - $7,990) Break-even point = $17,000 / $775 Break-even point = 21.94 months

Rounding up to the nearest whole month, we get 22 months as the break-even point. References: This question is based on the concept of financial feasibility analysis, which is part of the business analysis planning and monitoring knowledge area in the BABOK® Guide. Financial feasibility analysis is the process of comparing the costs and benefits of different solutions to determine the optimal one for the organization. One of the techniques for financial feasibility analysis is break-even analysis, which calculates the point in time when the costs of a solution equal the benefits of the solution. You can find more information about financial feasibility analysis and break-even analysis in the following sources:

BABOK® Guide, section 3.4.5.5, pages 76-77

CBAP / CCBA Certified Business Analysis Study Guide, chapter 3, pages 85-86

Certified Business Analysis Professional™ (CBAP®) | Coursera, course 2, week 3, video 3.3

Solution components are the parts of the physical architecture that implement the solution requirements. They include business processes, business policies, business rules, software applications, hardware devices, data structures, and other elements that constitute the solution. Solution components are identified and defined during the design process, and they are allocated to the requirements during the allocate requirements process. The purpose of allocating requirements to solution components is to ensure that each requirement is fulfilled by one or more solution components, and that each solution component contributes to one or more requirements123.

Assessment of proposed solution is not a solution component, but a technique that evaluates the feasibility, desirability, and suitability of a solution option. Assessment of proposed solution is used during the enterprise analysis process, which involves defining the business need, assessing the capability gaps, determining the solution approach, defining the solution scope, and defining the business case. The purpose of assessing the proposed solution is to compare the expected benefits and costs of the solution option, and to identify the risks, assumptions, and dependencies that may affect the solution delivery456. References: 1: BABOK® Guide v3, section 7.2 Allocate Requirements, page 254 2: CBAP / CCBA Certified Business Analysis Study Guide, chapter 7, page 243 3: Allocation and Traceability7 4: BABOK® Guide v3, section 3.4.5.1 Assessment of Proposed Solution, page 75 5: CBAP / CCBA Certified Business Analysis Study Guide, chapter 4, page 122 6: Business Analysis Techniques: Assessing the Proposed Solution, page 27

 Automation is a type of process improvement that can reduce the time, cost, and errors involved in performing tasks. By automating some of the software and activities that the stakeholders use, you can increase the efficiency and effectiveness of the data report generation process. Automation can also enhance the quality and consistency of the outputs, as well as the satisfaction of the customers and the workers. References:

CBAP® Handbook, page 6, section 4. Review the Exam Blueprint, under Business Analysis Planning and Monitoring, task 5.2: Plan Business Analysis Process Improvements.

CBAP / CCBA Certified Business Analysis Study Guide, page 144, section 5.2.2: Plan Business Analysis Process Improvements, under Automation.

Overlooking a key set of stakeholders can have serious consequences for the project, as they may have different needs, expectations, and perspectives than the existing stakeholders. Their requirements may conflict with or invalidate the ones that have been already elicited and analyzed, leading to rework, delays, and increased costs. Alternatively, they may introduce new requirements that require changes to the project scope, schedule, budget, or quality. Therefore, it is important to identify all relevant stakeholders as early as possible in the business analysis process and to engage them throughout the project lifecycle. References:

CBAP Handbook, page 12, section 2.0 Nine-Steps to Certification, step 3. Enter Your Eligibility Details into the BA Development Log

[BABOK Guide], page 30, section 2.2 Conduct Stakeholder Analysis, task description and output

CBAP/CCBA Study Guide, page 55, section 2.2.3 Stakeholder Analysis, stakeholder identification and analysis techniques

 Focus groups are a type of requirements elicitation activity that involve gathering a group of stakeholders from different perspectives and backgrounds to discuss a specific topic or issue. Focus groups can help to identify the ideas and attitudes of the stakeholders about the current situation, the desired outcomes, the problems, the solutions, and the actions needed to improve the service. Focus groups can also help to generate new ideas, uncover hidden needs, and reveal conflicting opinions. Focus groups are facilitated by a moderator who guides the discussion, asks open-ended questions, and encourages participation from all members. Focus groups are usually recorded and analyzed to extract the key findings and requirements1234. References: 1: Software Engineering | Requirements Elicitation - GeeksforGeeks 2: A Review of Fundamental Tasks in Requirements Elicitation 3: Top 10 Most Common Requirements Elicitation Techniques 4: 20 Tips for Effective Requirements Elicitation | Inflectra

A business case is a document that clearly identifies the reasoning for initiating a project to justify the resources required. It is written to justify the resources required for the project (money or effort) and align the project objectives to the business needs. It also includes the costs, benefits, and risks of the proposed solution, and compares it with alternative options1. A business case is an important input for the project initiation and approval process, as it helps the decision makers to assess the value and feasibility of the project2.

To write a business case, you need four main inputs: feasibility study, assumptions and constraints, business need, and solution options3. A feasibility study is an analysis that evaluates the technical, economic, social, and environmental aspects of the project, and determines whether it is viable and worth pursuing4. Assumptions and constraints are factors that affect the project scope, cost, schedule, and quality, and that need to be identified and documented in the business case. Assumptions are things that are believed to be true or certain, while constraints are things that limit or restrict the project5. Business need is the problem or opportunity that the project aims to address, and that aligns with the strategic goals and vision of the organization. Solution options are the different ways of solving the business need, and their respective costs, benefits, and risks.

Stakeholder concerns are not an input for writing a business case, but rather an output of stakeholder analysis. Stakeholder analysis is a process of identifying and prioritizing the people or groups who have an interest or influence in the project, and understanding their needs, expectations, and perspectives. Stakeholder concerns are the issues or challenges that the stakeholders face or anticipate in relation to the project, and that need to be addressed or resolved. Stakeholder concerns are important for defining the requirements, managing the communication, and ensuring the stakeholder satisfaction, but they are not directly used for writing the business case. References:

How to Write a Business Case (Template Included) - ProjectManager

How to Write a Business Case | Smartsheet

Business Case Examples, explained in simple language - Chase Consulting

Feasibility Study: Definition, Methods, and Examples

Project Assumptions and Constraints: Examples and Differences

[Business Need - IIBA®]

[Solution Options - IIBA®]

[Stakeholder Analysis: Overview, Tools and Techniques - KnowledgeHut]

[Stakeholder Concerns - IIBA®]

Requirements are dynamic and may change throughout the project life cycle due to various factors, such as changing stakeholder needs, new business opportunities, feedback from testing, or regulatory changes. Business analysis planning and monitoring involves defining the process for managing changes to requirements, including identifying the roles and responsibilities, the approval levels, the change control tools, and the communication methods. The business analyst should be prepared to handle changes to requirements at any time and follow the established change control process. References:

CBAP® Handbook, page 6, section 2.4. Review the Exam Blueprint

BABOK® Guide, page 29, section 2.4. Manage Business Analysis Performance

Tips for Earning a Business Analysis Certification, point 3. Understand the BABOK® Guide