CBAP Certified Business Analysis Professional (CBAP) Designation Questions and Answers

 The Information Management Approach is a document that describes how the business analysis information will be stored, accessed, distributed, and maintained throughout the project or initiative. It includes information such as the tools, formats, standards, and processes for managing the business analysis information. The Information Management Approach will indicate how requirements will be managed for reuse, because it will specify how the requirements or requirement components that have long term reuse will be identified, classified, stored, retrieved, and updated. Legal Regulatory Information, Architectural Repositories, and Business Rules Analysis are not documents that indicate how requirements will be managed for reuse. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 2: Business Analysis Planning and Monitoring, page 51
• Business Analysis Body of Knowledge (BABOK) Guide, Version 3, Chapter 2: Business Analysis Planning and Monitoring, section 2.5: Plan Business Analysis Information Management, page 36
• Business Analysis Professional Resources, IIBA Resource Collection, Business Analysis Body of Knowledge (BABOK) Guide
• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Skillsoft Book, Chapter 2: Business Analysis Planning and Monitoring, page 51

 The timing and frequency of collaboration are aspects that should be taken into account when working on a stakeholder collaboration plan. This is because the timing and frequency of collaboration affect the availability, engagement, and satisfaction of the stakeholders, as well as the quality and efficiency of the business analysis work. The BA should consider the stakeholder preferences, expectations, and constraints, as well as the project schedule, scope, and complexity, when determining the optimal timing and frequency of collaboration. The BA should also ensure that the collaboration activities are aligned with the business analysis plan and the stakeholder communication plan. Collaboration skills of BA, solution design, or business governance plan are not the best options for the aspects that should be taken into account, because they are either irrelevant, inaccurate, or not the root cause of the problem. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 4: Elicitation and Collaboration, page 167
• Business Analysis Body of Knowledge (BABOK) Guide, Version 3, Chapter 4: Elicitation and Collaboration, section 4.2: Conduct Elicitation, page 77
• Business Analysis Professional Resources, IIBA Resource Collection, Business Analysis Body of Knowledge (BABOK) Guide
• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Skillsoft Book, Chapter 4: Elicitation and Collaboration, page 167

 Milestone funding is an approach where the project is funded for enough capital to reach the next milestone, which is a predefined point in the project where some deliverables are completed or some criteria are met. Milestone funding helps to reduce the risk of investing too much money in a project that may not deliver the expected value or benefits. It also helps to monitor the progress and performance of the project and ensure that the project is aligned with the business objectives and stakeholder expectations. Milestone funding is a common practice in agile projects, where the project is divided into short iterations that deliver incremental value and feedback. References: CBAP / CCBA Certified Business Analysis Study Guide, chapter 5, page 229; CBAP (Certified Business Analysis Professional): 230+ Exam Practice Questions with Detail Explanations and Case Study Based Questions, question 230.

A cause-and-effect diagram, also known as an Ishikawa diagram or a fishbone diagram, is a graphical tool that visualizes the result of a root cause analysis study. It helps to identify, sort, and display the possible causes of a specific problem or quality issue. It can also be used to explore the root causes of a problem or a desired outcome. The diagram looks like the skeleton of a fish, hence the name fishbone diagram. The effect or problem is shown as the fish’s head, and the causes are shown as the bones along the spine. The diagram helps to organize the causes into categories, such as people, processes, equipment, materials, environment, etc. The diagram can be created by brainstorming the causes and grouping them into major categories. The diagram can then be analyzed to identify the most likely or significant causes of the problem or outcome. References:

• Root Cause Analysis: Definition, Examples & Methods | Tableau, under Approaches to Root Cause Analysis
• Root Cause Analysis, Ishikawa Diagrams and the 5 Whys - isixsigma.com, paragraph 1
• Root Cause Analysis - Practical Action, paragraph 1

Focus groups are directed conversations for gathering ideas, opinions, and attitudes about a product, service, problem, or opportunity. Focus groups are a type of elicitation technique that involves bringing together a group of selected stakeholders, usually potential or actual users or customers, and facilitating a structured discussion on a specific topic. Focus groups help to explore the needs, expectations, preferences, and perceptions of the stakeholders, as well as to generate new ideas or solutions. Focus groups also help to identify the commonalities and differences among the stakeholders, as well as the risks and opportunities related to the product, service, problem, or opportunity. References: IIBA BABOK Guide v3, section 4.2.4, page 114; CBAP / CCBA Certified Business Analysis Study Guide, chapter 4, page 176; CBAP Exam Questions - Institute i4, question 244.

A run chart is a line graph that shows data points plotted in the order in which they occur. It shows the history and pattern of variation of a process over time. It can be used to perform trend analysis, which is the examination of data over time to identify patterns, changes, or shifts in the process. A run chart can help to identify process stability, variation, and improvement opportunities. A run chart is also known as a line chart, a trend chart, or a time series plot. References:

• Run Chart: Creation, Analysis, & Rules - Six Sigma Study Guide
• Line Graph | Introduction to Statistics | JMP
• A Complete Guide to Line Charts | Tutorial by Chartio

 Collaborative games are a technique that can be used to elicit requirements in a workshop setting. They involve engaging the participants in structured activities that encourage creativity, collaboration, and consensus. Collaborative games can help to avoid disrupting the workshop by creating a positive and productive atmosphere, reducing the potential for conflict, and increasing the buy-in and ownership of the requirements. Some examples of collaborative games are brainstorming, affinity diagramming, storyboarding, and prioritization games. References:

• Business Analysis Body of Knowledge (BABOK) Guide, section 10.18, Collaborative Games
• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, chapter 6, Elicitation and Collaboration, page 223-224
• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, chapter 10, Review Questions, question 10.14, page 440

 Cost-benefit analysis is a technique that compares two or more systems, states, services, products, or things to determine the best viable choice. It involves estimating and comparing the total costs and benefits of each alternative over a specified period of time. The costs and benefits can be expressed in monetary or non-monetary terms, depending on the nature and scope of the analysis. Cost-benefit analysis can help to identify the most efficient and effective solution that maximizes the net benefit or minimizes the net cost. Cost-benefit analysis can also help to evaluate the feasibility, desirability, and sustainability of a project or initiative. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, page 47
• Business Analysis Professional Resources | IIBA®, under Standards, Regulations, and Best Practices
• Cost-Benefit Analysis Definition

 Risk Analysis and Management is a technique that involves identifying, assessing, and treating the uncertainties and potential negative impacts that may affect the requirement or the solution. Risk Analysis and Management can help the BA to identify scenarios that would alter the benefit delivered by a requirement, because it can help the BA to quantify and prioritize the risks, determine the appropriate responses and mitigation strategies, and monitor and control the risk exposure and outcomes. Risk Analysis and Management can also help the BA to communicate and report the risk status and issues to the stakeholders and the organization, and to ensure that the requirement delivers the expected value and benefit. Metrics and Key Performance Indicators, Data Modeling, or Document Analysis are not the best options for identifying scenarios that would alter the benefit delivered by a requirement, because they are either too specific, too general, or not directly related to the risk analysis and management process. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 8: Solution Evaluation, page 346
• Business Analysis Body of Knowledge (BABOK) Guide, Version 3, Chapter 8: Solution Evaluation, section 8.4: Assess Solution Limitations, page 158
• Business Analysis Professional Resources, IIBA Resource Collection, Business Analysis Body of Knowledge (BABOK) Guide
• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Skillsoft Book, Chapter 8: Solution Evaluation, page 346

 Functional is not a characteristic of a requirement, but a type of requirement. A functional requirement describes what the system or solution should do, such as the features, functions, behaviors, or capabilities1. A characteristic of a requirement is a quality or attribute that makes the requirement good or effective. There are different sources that list different characteristics of a requirement, but some of the common ones are: clear, complete, consistent, correct, feasible, modifiable, unambiguous, and testable2345. These characteristics help to ensure that the requirement is well-defined, understood, verified, and validated. References:

• Functional vs Non-functional Requirements: What’s the Difference?
• 1.4 Characteristics of a Good Requirement - InformIT
• How To Write a Good Requirement? 14 Qualities | Insights Spotter
• Needs and Solutions, Requirements and Designs - IIBA®
• Effectively! – Requirement Characteristics - ArgonDigital

Prioritizing requirements by the likelihood of success is a technique that can help build confidence and trust among the project stakeholders, especially if the project is complex, risky, or has a long duration. By delivering some of the requirements that have a highchance of success early in the project, the business analyst can demonstrate the value of the project and the effectiveness of the business analysis process. This can also help reduce resistance to change and increase user satisfaction and adoption. Some of the other factors that can be used to prioritize requirements are business value, urgency, dependency, risk, cost, and effort. References:

• Certified Business Analysis Professional (CBAP) Handbook, page 6, section 4. Review the Exam Blueprint.
• BABOK Guide v3, page 34, section 4.2.3. Prioritize Requirements.

 Functional decomposition is the analysis of complex systems by breaking them down into smaller simpler elements. It involves breaking down processes, systems, functional areas, or deliverables into simpler components, so that each part can be analyzed separately12. By breaking down larger components into smaller parts, it allows the organization to measure and track each work effort involved in implementing the solution. It also helps in the assessment of the effectiveness of each sub-component as it relates to other larger or smaller components3. Functional decomposition is a technique used in business analysis to facilitate the understanding and management of large and complex processes2. It is also used in systems engineering, software architecture, database theory, machine learning, and a variety of other fields2. References: 1: Functional decomposition in business analysis – The Functional BA 2: Functional Decomposition: Definition, Diagrams, and Applications 3: 10.22 Functional Decomposition | IIBA®

 Risk Data Quality Assessment is a technique that evaluates the degree to which the data about individual project risks is useful for risk management. It involves examining the extent to which the risk data is accurate, reliable, timely, complete, and realistic. This helps to determine the quality and credibility of the information used for risk analysis and response planning. References:

• BABOK® Guide v3, section 11.6.5.8, page 417
• CBAP® Exam Prep Study Guide, chapter 9, page 339
• CBAP® Certification Study Guide v3.0, chapter 9, page 301

 Business or technical risk is a requirements prioritization approach that involves ranking the requirements based on the potential negative consequences or uncertainties associated with their implementation or non-implementation. This approach can help to identify and mitigate the most critical risks early in the project and reduce the likelihood of project failure. Business or technical risk can be assessed by considering factors such as the impact on the business value, the feasibility of the solution, the complexity of the requirements, the dependencies among the requirements, the volatility of the requirements, and the stakeholder satisfaction. Business or technical risk is one of the common criteria for requirements prioritization, as it helps to balance the benefits and costs of the requirements1234. References: 1: Requirement prioritization3 2: The Ultimate Guide to Requirements Prioritization4 3: Business Analysis Techniques: Prioritizing Requirements5 4: Requirements Prioritization: How to Prioritize Requirements

A plan-driven approach to business analysis is a methodology that focuses on minimizing up-front uncertainty and ensuring that the solution is fully defined before implementation begins in order to maximize control and minimize risk. This approach tends to be preferred in situations where requirements are stable and clear, and where changes are costly and disruptive. Therefore, changes in the plan-driven approach are generally avoided unless they are genuinely necessary to address a significant issue or opportunity. Changes in the plan-driven approach require formal approval and documentation, and may affect the scope, schedule, budget, and quality of the project. Changes in the plan-driven approach should be carefully analyzed and justified before being implemented123. References: 1: How to Choose the Right Business Analysis Approach1 2: Plan driven projects versus change driven2 3: Business Analysis Methodology3

Quality control is the process of monitoring and measuring the quality of the project deliverables and outputs against the quality standards and criteria established in the quality management plan. Quality control is used to make certain that the project team members are completing the project work according to the project plan and meeting the stakeholder expectations. Quality control involves performing quality audits, inspections, tests, reviews, and validations to identify and correct any defects, errors, or deviations from the specifications. Quality control is one of the key processes in the project quality management knowledge area, which ensures that the project meets the quality requirements1234. References: 1: BABOK® Guide v3, section 11.6.5.9 Quality Management and Control, page 418 2: CBAP® Exam Prep Study Guide, chapter 9, page 340 3: Project Quality Management: Processes & Tools | Villanova University5 4: Quality Control in Project Management | PMI6

 A repository is a centralized place where project requirements are stored and managed throughout the project lifecycle. A repository can be a physical or electronic system that allows business analysts to access, update, and track the status of the requirements. A repository can also facilitate the communication, collaboration, and verification of the requirements among the stakeholders. A repository is not the same as a change management system (A), a project scope statement ©, or a requirements register (D), which are different tools or documents that serve different purposes in project management. References:

• IIBA BABOK Guide v3, p. 30, 176, 264
• How to Write Project Requirements | Smartsheet, paragraph 3
• What is Requirements Management? | IBM, paragraph 1

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

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 thebusiness 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

Stakeholder analysis is performed as soon as a business need is identified, as this is the first step in the business analysis process. Stakeholder analysis helps to identify who are the people or groups that have an interest or influence in the project, what are their needs and expectations, and how to engage them effectively. Stakeholder analysis is essential for defining the project scope, objectives, requirements, risks, and success criteria. Stakeholder analysis is also an ongoing process that should be revisited throughout the project lifecycle, as stakeholders may change or new ones may emerge12. References:

• Stakeholder Analysis: Overview, Tools and Techniques - KnowledgeHut
• How to Perform a Stakeholder Analysis | Lucidchart

 Business value is a basis for prioritizing requirements that considers the benefits and costs of each requirement to the organization. It helps to identify the most valuable requirements that can deliver the highest return on investment. Business value can be measured in terms of revenue, cost savings, customer satisfaction, market share, competitive advantage, or other criteria that are relevant to the organization’s goals and objectives. References:

• Certified Business Analysis Professional (CBAP) Handbook, page 6, section 4. Review the Exam Blueprint, Table 4.1: BABOK® Guide Knowledge Areas and Tasks
• BABOK® Guide v3, page 33, section 4.2 Prioritize Requirements
• Tips for Earning a Business Analysis Certification, section 3. Leverage a variety of study resources

 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.

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

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

The business analysis approach is a plan that describes how the business analysis activities will be performed, including the deliverables, the team roles, the analysis techniques, the communication methods, the change management process, and the stakeholder engagement strategy. The business analysis approach does not define the requirements for solutions acceptance, which are the criteria that the solution must meet to be accepted by the stakeholders. The requirements for solutions acceptance are part of the solution scope, which is an output of the enterprise analysis tasks, not the business analysis approach. References:

• [A Guide to the Business Analysis Body of Knowledge (BABOK Guide)], version 3, page 24, section 2.21
• [CBAP Certification Study Guide v3.0], Chapter 4: Requirements Life Cycle Management, Section 4.1: Plan Business Analysis Approach, page 4-22
• Business Analysis Approach, paragraph 1

A non-negotiable demand by a stakeholder during the requirements prioritization session is one that does not allow for any trade-offs, compromises, or alternatives. It is a demand that must be met regardless of the impact on other requirements, the feasibility of the solution, or the value to the organization. A stakeholder who insists that all requirements are ranked as high is making a non-negotiable demand, as this would prevent any meaningful prioritization and allocation of resources. Communication, cost-benefits ratio, and cost are not non-negotiable demands, as they can be negotiated,adjusted, or balanced with other factors during the requirements prioritization session. References: BABOK Guide v3, section 10.25 Requirements Prioritization; 1

A work product is any output of the business analysis process that is used to communicate, document, or manage requirements1. Examples of work products include requirements documentation, interview questions and notes, meeting agendas and minutes, models, diagrams, matrices, traceability reports, and business cases2. Presentation slides are not a work product, as they are not used to capture or manage requirements, but rather to present or summarize them to an audience. Presentation slides may contain information from work products, but they are not work products themselves. References:

• Work Product Definition & Meaning | Merriam-Webster Legal
• Examples of ownership of work product clauses in contracts - Afterpattern

The work breakdown structure (WBS) is not an element of the solution scope, but rather a project management tool that decomposes the project scope into manageable deliverables and tasks. The WBS is created after the solution scope is defined and approved, and it helps to plan, monitor, and control the project execution.

The other options are elements of the solution scope, which are:

• B. Implementation approach, which describes how the solution will be delivered, such as the methodology, the phases, the roles and responsibilities, and the quality measures.
• C. Solution scope definition, which describes what the solution is, what it does, and what it does not do, in terms of the features, functions, and characteristics that address the business need.
• D. Dependencies, which describe the relationships and interactions between the solution and other internal or external factors, such as other projects, systems, processes, or stakeholders.

References:

• CBAP® Handbook, page 15, section 4.1.2.3
• BABOK® Guide, page 32, section 3.2.3
• Solution Scope – An Insight
• How To Write a Project Scope in 5 Steps (With Example)

 A business analysis communication plan is a document that describes how the business analyst will communicate with the stakeholders, including the stakeholder groups, communication needs, level of formality, frequency, format, and methods of communication. It is one of the outputs of the business analysis planning and monitoring knowledge area, and it helps to ensure that the stakeholders are informed, engaged, and satisfied with the business analysis process and deliverables. A business analysis communication plan is not the same as a project communication plan, which covers the overall communication needs of the project and is typically created by the project manager. A business analysis communication plan focuses on the specific communication needs related to the business analysis activities and requirements. References:

• IIBA BABOK Guide v3, p. 36, 38, 40, 42
• How to Create a Stakeholder Management Plan Smartsheet
• CBAP 150 Practice Questions Flashcards, Question 5
• How To Create an Effective Stakeholder Communication Plan

The requirements analysis processes are the activities that prioritize, organize, specify, model, verify, and validate the requirements for the solution. They ensure that analysis and implementation efforts focus on the most critical requirements that deliver the most value to the stakeholders and the organization. They also help to resolve any conflicts or inconsistencies among the requirements and the stakeholders. References:

• CBAP® Handbook, page 6, section 2.4 Review the Exam Blueprint
• BABOK® Guide, page 30, section 3.2 Requirements Analysis and Design Definition
• CBAP / CCBA Certified Business Analysis Study Guide, page 111, chapter 5 Requirements Analysis

 A dependency is a relationship or a condition that affects the completion or the quality of a task or an activity. A dependency can be internal or external, mandatory or discretionary, or positive or negative. In this case, the inspector’s signoff on the initial deliverables is a dependency because it is a condition that must be met before the task can be completed. The inspector’s signoff is an external and mandatory dependency, as it involves an outside party and it is required by the project scope or contract. A dependency is not the same as an assumption (A), which is a factor that is considered to be true without proof, a milestone ©, which is a significant point or event in the project, or a constraint (D), which is a factor that limits the options or performance of the project. References:

• What is a Dependency in Project Management? - Wrike, paragraph 1
• Project Dependencies: Types, Examples, and Tips for Project Managers, paragraph 1
• CBAP Certification Study Guide v3.0, Chapter 4: Requirements Life Cycle Management, Section 4.3: Trace Requirements, page 4-10
• [A Guide to the Business Analysis Body of Knowledge (BABOK Guide)], version 3, page 402, section 10.31.3.1

The business analysis process that ensures that requirements specifications and models meet the necessary standard of quality to allow them to be used effectively to guide further work is verify requirements. According to the BABOK® Guide1, this process involves checking that the requirements are well-defined, clear, consistent, complete, correct, feasible, modifiable, testable, and traceable. It also involves resolving any defects or issues that may affect the quality of the requirements. The purpose of this process is to confirm that the requirements specifications and models accurately reflect the stakeholder needs and expectations, and that they are ready for validation and approval.

The other options are not correct, but rather:

• A. Identify constraints and assumptions is a task within the assess capability gaps process, which involves comparing the current and future states of the organization to identify the gaps that must be addressed by a solution.
• B. Validate requirements is a process that ensures that the requirements support the delivery of value to the stakeholders and achieve the goals and objectives of the project or initiative. It involves evaluating the alignment, acceptability, and approval of the requirements by the stakeholders.
• D. Specify and model requirements is a process that involves defining and representing the requirements in various formats, such as textual, graphical, or tabular. It helps to communicate, analyze, and refine the requirements more effectively.

References:

• CBAP® Handbook, page 6, section 4. Review the Exam Blueprint, under Requirements Analysis and Design Definition, task 5.3: Verify Requirements
• BABOK® Guide, page 33, section 4.2.3: Verify Requirements
• How Do Business Analysts Verify Requirements? (BABOK 6.5)
• What Is Requirements Analysis? Process and Techniques

The solution scope definition is a document that describes the features and functions of the solution that will address the business need and deliver the expected benefits. It also defines the boundaries and assumptions of the solution, as well as the criteria for its acceptance and evaluation. The solution scope definition should include the following elements:

• Solution vision: A brief statement that summarizes the purpose, value proposition, and target audience of the solution.
• Solution objectives: A list of measurable and achievable goals that the solution aims to accomplish, aligned with the business goals and objectives.
• Solution requirements: A detailed and specific description of the stakeholder and solution requirements that define the scope and functionality of the solution, organized by categories, types, and priorities.
• Solution constraints: A list of factors that limit the options or performance of the solution, such as technical, legal, regulatory, or organizational constraints.
• Technical dependencies: A list of relationships or interactions between the solution and other systems, components, or technologies that affect the solution’s design, development, or implementation.
• Solution risks: A list of potential threats or uncertainties that may affect the solution’s success, along with their probability, impact, and mitigation strategies.
• Solution scope statement: A concise statement that defines what is in and out of scope for the solution, and clarifies any ambiguities or conflicts among the solution requirements.

The solution scope definition does not include the business case (A), which is a separate document that justifies the need for the solution and analyzes its costs and benefits. The solution scope definition also does not include the elicitation techniques ©, which are themethods or tools used to gather information from the stakeholders and discover the requirements. The solution scope definition also does not include the organization readiness assessment (D), which is an analysis of the organization’s ability and willingness to adopt the solution and manage the change.

References:

• [A Guide to the Business Analysis Body of Knowledge (BABOK Guide)], version 3, page 30, section 3.11
• Solution Scope – An Insight - Modern Analyst, paragraphs 2-3
• Scoping a Solution | Microsoft Solutions Framework Essentials … - Flylib, paragraph 1
• [Solution Scope vs. Project Scope - Enfocus Solutions Inc], paragraph 2
• [How to Write Project Requirements | Smartsheet], paragraph 3

 MoSCoW is an acronym for Must-have, Should-have, Could-have, and Won’t-have this time. It is a prioritization technique that many organizations use in project management, software development, business analysis, etc., to categorize and prioritize requirements or tasks based on their importance and urgency. The method provides a simple and effective way to prioritize work items by assigning them to one of the four categories12:

• Must-have: These are the critical and non-negotiable requirements or tasks that must be completed for the project or product to be successful. Without them, the project or product will fail or become useless. For example, compliance with legal or security standards, or core functionality of the product.
• Should-have: These are the important but not essential requirements or tasks that should be completed for the project or product to be satisfactory. They add significant value or benefit, but they are not as time-sensitive or critical as the must-haves. They can be postponed or omitted without compromising the project or product. For example, performance improvements, minor bug fixes, or nice-to-have features.
• Could-have: These are the desirable but not necessary requirements or tasks that could be completed for the project or product to be enhanced. They improve the user experience or customer satisfaction, but they have a low impact or benefit. They can be included if time and resources permit, or they can be left out without affecting the project or product. For example, aesthetic changes, extra functionality, or user feedback.
• Won’t-have: These are the least important or relevant requirements or tasks that won’t be completed for the project or product at the current time. They have a low or negative impact or benefit, or they are not appropriate or feasible at the moment. They can be excluded, deferred, or reconsidered for future projects or products. For example, out-of-scope requests, low-priority issues, or unrealistic expectations.

MoSCoW prioritization helps to manage the expectations and needs of the stakeholders, and to focus on the most valuable and urgent work items. It also helps to deal with changing requirements, scope creep, and resource constraints. MoSCoW prioritization is often used with timeboxing, which is a technique that sets a fixed deadline for the completion of a project or product34. References:

• What is MoSCoW Prioritization? | Overview of the MoSCoW Method
• MoSCoW method - Wikipedia
• Simplify Requirement Prioritization With the MoSCoW Method - Geekflare
• MoSCoW: Framework for Effective Prioritization | craft.io

Before making a presentation about the requirements for a large software development project, Gary should determine an appropriate format for the presentation. This means he should consider the following factors:

• The audience: Who are the stakeholders that will attend the presentation? What are their roles, interests, and expectations? How familiar are they with the project and the requirements? How much detail do they need to understand the requirements?
• The purpose: What is the goal of the presentation? Is it to inform, persuade, or seek feedback from the stakeholders? What are the key messages and takeaways that Gary wants to convey?
• The time: How much time does Gary have to present the requirements? How can he allocate the time effectively to cover the most important and relevant aspects of the requirements?
• The tools: What tools and resources does Gary have to create and deliver the presentation? Does he have access to a projector, a laptop, a microphone, or a whiteboard? What software or applications does he need to use to create the presentation slides or documents?
• The style: How can Gary make the presentation engaging, clear, and professional? What visual aids, diagrams, charts, or examples can he use to illustrate the requirements? How can he use colors, fonts, images, and animations to enhance the presentation? How can he structure the presentation to have a logical flow and a strong introduction and conclusion?

By determining an appropriate format for the presentation, Gary can ensure that he communicates the requirements effectively and efficiently to the stakeholders, and that he addresses their needs and concerns.

References:

• How to Make Interesting Presentations for Software Projects, paragraphs 1-3
• How To Write The Software Development Project Brief, steps 1-7
• Complete Guide to Software Development Requirements, paragraphs 1-2

Opportunity cost is the value of the next best alternative that is forgone as a result of making a decision1. In this scenario, the opportunity cost of choosing Project B over Project A is the value of Project A, which is $235,987. This means that by pursuing Project B, the organization is giving up the potential benefit of earning $235,987 from Project A. The risk of Project B is not relevant for calculating the opportunity cost, as it only affects the expected return of Project B, not the value of Project A. The difference between the values of Project B and Project A ($331,013) is not the opportunity cost, as it does not reflect the value of the forgone alternative. The value of Project B ($567,000) is not the opportunity cost, as it is the value of the chosen alternative, not the forgone one. References: 1: Opportunity Cost: Definition, Calculation Formula, and Examples1

 The project manager is the stakeholder who is responsible for writing the project scope. The project scope is a document that defines the work that needs to be done to deliver the project, including the objectives, deliverables, milestones, resources, and constraints. The project manager is the person who leads and coordinates the project team, plans and monitors the project activities, manages the project risks and issues, and communicates with the project stakeholders. The project manager works closely with the business analyst, who is responsible for writing the solution scope, which defines the features and functions of the solution that will address the business need. The project manager also consults with the domain subject matter expert, the implementation subject matter expert, and the sponsor, who are stakeholders who provide input, feedback, and approval for the project scope and the solution scope. References:

• Project Scope Management: What It is and Why It’s Important, paragraph 2
• What is Project Scope? Definition, Example, & Project Scope …, paragraph 1
• Project Scope vs. Solution Scope: What’s the Difference?, paragraph 1
• [Project Manager vs. Business Analyst: What’s the Difference?], paragraph 1

 Assessing the capability gaps is the business analysis process that involves comparing the current state and the future state of an organization to identify the gaps or differences that must be addressed by a solution. This process helps to understand the root causes of the problems, the needs and opportunities for improvement, and the feasibility and scope of the solution. In this question, the NGQ Company wants to analyze its ability to meet an identified business need, which implies that there is a gap between its current and desired performance. Therefore, assessing the capability gaps is the appropriate process to complete for the organization. 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
• Business Analysis Process Flow: Step by Step Tutorial, step 3. Analyze all the project relevant documents

Alternative generation is a business analysis element that tries to identify as many potential options as possible to meet the business objectives and fill identified gaps in capabilities. Alternative generation is part of the strategy analysis knowledge area, which involves defining the business need, assessing the current state, defining the future state, identifying solution options, and recommending a solution. Alternative generation helps to explore the possible ways to achieve the desired outcomes, and to evaluate the feasibility, viability, and suitability of each option. Alternative generation can use various techniques, such as brainstorming, benchmarking, market analysis, or SWOT analysis, to generate and compare different solution alternatives. References:

• [A Guide to the Business Analysis Body of Knowledge (BABOK Guide)], version 3, page 100, section 5.41
• [CBAP Certification Study Guide v3.0], Chapter 5: Strategy Analysis, Section 5.4: Identify Solution Options, page 5-152
• What Is Business Analysis and Why Is It Important? - Indeed, paragraph 4
• More CBAP Preparation Questions – The Functional BA, question 4

The relationship between use cases “Create a role” and “Find a role” when there is a high level of formality is derive. This means that the use case “Find a role” is derived from the use case “Create a role”, because it is a sub-function or a variation of the main function. A derived use case is dependent on another use case and cannot be performed independently. A derived use case can also be called an extension, an inclusion, or a generalization of another use case. The other options are not valid relationships between use cases. Validate, necessity, and satisfy are relationships between requirements and other elements, such as stakeholders, objectives, or design components. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 7: Requirements Analysis and Design Definition, page 293
• Business Analysis Body of Knowledge (BABOK) Guide, Version 3, Chapter 7: Requirements Analysis and Design Definition, section 7.5: Specify and Model Requirements, page 135
• Business Analysis Professional Resources, IIBA Resource Collection, Business Analysis Body of Knowledge (BABOK) Guide
• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Skillsoft Book, Chapter 7: Requirements Analysis and Design Definition, page 293

Millstones are timeless events that show progress in the project. Millstones are significant points or achievements in the project lifecycle that indicate the completion of a major deliverable, phase, or stage. Millstones are typically achieved at the end of each phase in the project lifecycle, such as initiation, planning, execution, monitoring and control, and closure. Millstones help to measure and communicate the project status, performance, and results, and to ensure the alignment and satisfaction of the project stakeholders12. Achievements are the outcomes or results of the project that fulfill the project objectives and deliver value to the project stakeholders. Achievements are not necessarily timeless events that show progress in the project, as they may occur at any point in the project lifecycle, depending on the nature and scope of the project. Achievements help to evaluate and demonstrate the project success, quality, and benefits, and to justify the project investment and resources34. Phases are the stages or segments of the project lifecycle that divide the project into manageable and logical units. Phases are not timeless events that show progress in the project, as they are the periods of time during which the project activities and tasks are performed and the project deliverables are produced. Phases help to organize and structure the project work, scope, and schedule, and to apply the appropriate methods, tools, and techniques for each phase1 . Templates are the standardized documents or formats that are used to plan, execute, and control the project. Templates are not timeless events that show progress in the project, as they are the tools or aids that facilitate the project management processes and practices. Templates help to ensure the consistency, completeness, and quality of the project documentation, communication, and reporting1 . References:

• CBAP® Handbook
• Millstone - iiba.org
• Achievement - iiba.org
• Project Success - iiba.org
• [Phase - iiba.org]
• [Template - iiba.org]

 Risk governance is the process of establishing organizational checks and balances with a proper segregation of front, back, and middle office functions for effective risk management. Risk governance is the set of roles, responsibilities, policies, procedures, and standards that define how risk management is performed and overseen within an organization. Risk governance helps to ensure that risk management is aligned with the organizational strategy, objectives, and values, and that risk management activities are coordinated, consistent, and transparent across the organization. Risk governance also helps to promote a risk-aware culture and to foster accountability and ownership of risk management among the stakeholders12. A risk response plan is a document that describes the strategies and actions to address the identified and prioritized risks. A risk response plan is the output of the risk analysis process, which evaluates the risks and determines the appropriate responses to them. A risk response plan helps to implement the risk governance policies and procedures, and to execute the risk management plan13. A risk analysis is a process that evaluates the identified and prioritized risks, and determines the appropriate responses to them. A risk analysis is a sub-process of the risk management process, which encompasses risk identification, risk estimation, risk analysis, and risk monitoring and control. A risk analysis helps to develop strategies and actions to avoid, reduce, transfer, or accept the risks, and to allocate resources and contingency reserves for risk management14. A risk management plan is a document that describes how risk management will be performed and controlled throughout the project or the solution lifecycle. A risk management plan is the output of the scope and plan initiation process, which defines the scope, objectives, approach, and deliverables of the risk management process. A risk management plan helps to implement the risk governance policies and procedures, and to guide the risk management activities and decisions15. References:

• CBAP® Handbook
• Risk Governance - iiba.org
• Risk Response Plan - iiba.org
• Risk Analysis - iiba.org
• Risk Management Plan - iiba.org

A presentation is a conversation between one or more speakers centering on one specific topic, such as a business analysis technique, a solution option, or a project status update. Presentations are used to communicate information, persuade stakeholders, or demonstrate a solution. Presentations can be delivered in various formats, such as slides, videos, or posters. Presentations are one of the 50 business analysis techniques described in the BABOK® Guide. References:

• BABOK® Guide, section 10.41, Presentation
• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, chapter 8, Elicitation and Collaboration Techniques, page 247
• Certified Business Analysis Professional™ (CBAP®) | Coursera, course 3, Business Analysis: Elicitation and Collaboration, week 3, Presentation

A business process model is a graphical representation that captures all of the activities within a business, the inputs and outputs of each activity, and the required resources to complete each activity. It shows the sequence, dependencies, roles, and responsibilities of the activities, as well as the information and materials that flow between them. A business process model can help to document, analyze, improve, and automate the business processes that deliver value to the customers and stakeholders. A business process model can also help to align the business and IT strategies, and to identify the gaps and opportunities for innovation. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, page 279
• Business Analysis Professional Resources | IIBA®, under Business Analysis Body of Knowledge (BABOK ®) Guide
• All About Business Process Mapping, Flow Charts and Diagrams | Lucidchart, under What is business process mapping?

 The BA should first understand the root cause of the problem before proposing any solution. Reviewing historic sales and related data can help the BA identify patterns, trends, and factors that affect the customer base. This can also help the BA validate or invalidate the assumption that increased competition is the main cause of the problem. Performing market research, creating a training program, or identifying training providers are potential solutions that should be considered only after the problem is clearly defined and analyzed. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 6: Strategy Analysis, page 253
• Business Analysis Body of Knowledge (BABOK) Guide, Version 3, Chapter 5: Strategy Analysis, section 5.1: Analyze Current State, page 95

 A proven and tailored analysis approach is suitable for this project because it allows the business analyst to adapt to the specific needs and context of the project, while leveraging the best practices and standards of the profession. A proven and tailored analysis approach can also accommodate the different cultures, languages, regulations, and time zones of the countries involved in the project. A proven and tailored analysis approach is based on the following principles1:

• Business analysis is performed in alignment with the organization’s strategy and objectives
• Business analysis is driven by stakeholder needs and values
• Business analysis is collaborative and iterative
• Business analysis is adaptive and responsive to change
• Business analysis is supported by effective communication and documentation
• Business analysis is guided by ethical and professional conduct

References:

• 1: CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 1: Introduction to Business Analysis, page 82
• 2: CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition

A phase gate review is a process that must be performed at the end of each project phase to determine the completeness of the project work and to gain the customer’s acceptance to move the project forward. A phase gate review is also known as a stage gate review, a milestone review, or a toll gate review. The purpose of a phase gate review is to evaluate the project’s performance, risks, issues, deliverables, and alignment with the business objectives and requirements. A phase gate review also provides an opportunity to decide whether to continue, modify, or terminate the project based on the current status and expected outcomes. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, page 47
• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, page 47
• CERTIFIED BUSINESS ANALYSIS PROFESSIONAL, page 6
• Business Analysis Professional Resources | IIBA®, under Standards, Regulations, and Best Practices

The HAZOP technique, which stands for Hazard and Operability Study, is a qualitative technique that involves a disciplined analysis of the event sequences that could transform a potential hazard into an accident. The HAZOP technique is a systematic and structured method of identifying and evaluating the possible deviations from the intended design, operation, or functionality of a system, process, or product. The HAZOP technique uses a set of guide words, such as no, more, less, as well as, part of, and reverse, to generate different scenarios of what could go wrong and why. The HAZOP technique helps to identify the causes, consequences, and safeguards of the deviations, and to recommend the appropriate actions or controls to prevent or mitigate the hazards12. A failure mode and effects criticality analysis (FMECA) is a qualitative technique that involves an extension of the failure mode and effects analysis (FMEA) by adding a criticality rating to each failure mode. A FMECA is a method of identifying and evaluating the potential failures of a system, process, or product, and their impacts on the performance, safety, or reliability of the system, process, or product. A FMECA helps to prioritize the failures based on their severity and frequency, and to determine the corrective actions or preventive measures to reduce or eliminate the failures13. A failure mode and effects analysis (FMEA) is a qualitative technique that involves a systematic analysis of the potential failures of a system, process, or product, and their effects on the performance, safety, or reliability of the system, process, or product. An FMEA is a method of identifying and evaluating the causes, modes, and consequences of the failures, and the existing or planned controls to detect or prevent the failures. An FMEA helps to improve the design, operation, or functionality of the system, process, or product, and to reduce the risk of failures14. A preliminary risk analysis (PRA) is a qualitative technique that involves a high-level assessment of the risks that may affect a project or a solution. A PRA is a method of identifying and evaluating the sources, events, and impacts of the risks, and the existing or planned responses to the risks. A PRA helps to determine the feasibility and viability of the project or the solution, and to establish the scope and objectives of the risk management process15. References:

• CBAP® Handbook
• HAZOP Technique - iiba.org
• Failure Mode and Effects Criticality Analysis - iiba.org
• Failure Mode and Effects Analysis - iiba.org
• Preliminary Risk Analysis - iiba.org

A resource breakdown structure (RBS) is a type of chart that shows which resources are needed in the project and allows you to group the resources by project phase or other attributes. A resource is anything that is required to perform the project activities, such as human resources, equipment, materials, facilities, etc. A RBS is a hierarchical representation of the resources, where each level represents a category or a subcategory of resources. A RBS helps to plan, allocate, monitor, and control the resources for the project. A RBS also helps to identify the dependencies and constraints among the resources, as well as the potential risks and opportunities related to the resources. References: CBAP / CCBA Certified Business Analysis Study Guide, chapter 6, page 237; CBAP Sample Questions, question 237.

 Operational assessment is a type of analysis that involves evaluating the current state of the business processes, activities, and performance, and identifying the gaps, issues, and opportunities for improvement. Operational assessment was missed prior to purchasing a solution, because it would have helped to understand the differences and similarities between the Life and Non-Life teams, and to determine the best solution that would meet the needs and expectations of both groups. By skipping the operational assessment, the company bought a solution that did not fit the processes and preferences of the Non-Life team, and resulted in inefficiency and dissatisfaction. Organizational structure, stakeholder impact analysis, or stakeholder location are not the best options for the type of analysis that was missed, because they are either irrelevant, inaccurate, or not the root cause of the problem. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 6: Strategy Analysis, page 248
• Business Analysis Body of Knowledge (BABOK) Guide, Version 3, Chapter 5: Strategy Analysis, section 5.2: Analyze Current State, page 95
• Business Analysis Professional Resources, IIBA Resource Collection, Business Analysis Body of Knowledge (BABOK) Guide
• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Skillsoft Book, Chapter 6: Strategy Analysis, page 248

The BA should base requirements on the priority set by stakeholders to maximize the value of the solution. This is because the stakeholder priority reflects the relative importance, urgency, and benefit of each requirement for the business and the solution. The BA should allocate the highest priority requirements to the earliest releases, and the lower priority requirements to the later releases, to ensure that the solution delivers the most value to the stakeholders as soon as possible. The other options are not the best criteria for allocating requirements, because they do not directly measure the value of the requirements. Available resources, timing of the release, and components in scope are factors that may influence the feasibility and scope of the solution, but they do not determine the value of the solution. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 3: Requirements Life Cycle Management, page 122
• Business Analysis Body of Knowledge (BABOK) Guide, Version 3, Chapter 3: Requirements Life Cycle Management, section 3.5: Prioritize Requirements, page 62
• Business Analysis Professional Resources, IIBA Resource Collection, Business Analysis Body of Knowledge (BABOK) Guide
• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Skillsoft Book, Chapter 3: Requirements Life Cycle Management, page 122

 A formal approach is suitable for a project that has a high level of complexity, uncertainty, and risk, as well as a high degree of stakeholder involvement and scrutiny. A project to expand into new markets is likely to have these characteristics, especially in the banking industry, which is highly regulated and competitive. A formal approach would help ensure that the project scope, objectives, and requirements are clearly defined, communicated, and approved by the relevant stakeholders, such as the CEO and the CFO. A formal approach would also provide more control and traceability over the project deliverables and changes, as well as more visibility and accountability for the project progress and outcomes. References: CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 2: Business Analysis Planning and Monitoring, page 59; Business Analysis Body of Knowledge (BABOK ®) Guide, Chapter 2: Business Analysis Planning and Monitoring, section 2.1.4: Selecting the Business Analysis Approach, pages 28-29.

Risk analysis is the process of analyzing the areas of a project that are most affected by risk. It involves estimating the probability and impact of each identified risk, as well as assessing the quality and reliability of the available data. Risk analysis helps to prioritize the risks based on their severity and potential effect on the project objectives and deliverables. Risk analysis also helps to identify the root causes and triggers of the risks, as well as the interrelationships and dependencies among the risks. Risk analysis is the second step of risk management, which also includes risk identification, risk response, and risk monitoring and control. References: [IIBA BABOK Guide v3], section 11.2.2, page 387; CBAP / CCBA Certified Business Analysis Study Guide, chapter 5, page 231; CBAP Sample Questions, question 234.

 The level of decomposition needed for the requirements depends on the complexity of the system, the level of detail required by the stakeholders, and the level of architecture decomposition that is necessary to specify the system being developed. The BA must take into account the stakeholder perspectives when decomposing the requirements, as different stakeholders may have different needs and expectations for the granularity and clarity of the requirements. The BA must also ensure that the decomposed requirements are consistent, feasible, verifiable, and traceable to the higher-level requirements. References:

• BABOK Guide v3, Section 5.2.3: Decompose Requirements - Guidelines and Tools1
• Step 4: Analyze, Refine & Decompose Requirements - AcqNotes2
• MDRE: Developer Derived/Decomposed Requirements | SpringerLink3
• Requirements Decomposition - ArgonDigital | Making Technology a …4
• Requirements decomposition - No Magic Product Documentation

Risk communication is the technique that involves coordinating and collaborating with other credible sources in risk. Risk communication is the process of exchanging information and opinions about the nature, magnitude, significance, and control of the risks among the stakeholders. Risk communication helps to create a common understanding of the risks, to build trust and confidence among the stakeholders, to inform and educate the stakeholders about the risk management activities and outcomes, and to solicit feedback and input from the stakeholders. Risk communication is an essential part of risk management, which also includes risk identification, risk analysis, and risk response. References: [IIBA BABOK Guide v3], section 11.2.4, page 389; CBAP / CCBA Certified Business Analysis Study Guide, chapter 5, page 233; Free CBAP CBAP® Exam Questions - IIBA CBAP Exam - Study4Exam, question 246.

Variance analysis is the process of comparing the planned project results with the actual project results and identifying the causes and impacts of any deviations. Variance analysis helps project managers to monitor and control the project performance, identify and mitigate risks, and implement corrective actions or changes if needed. Variance analysis can be applied to various aspects of the project, such as scope, schedule, cost, quality, and resources. References:

• A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition, Chapter 4.5.3, p. 123
• Planned vs. Actual Progress Explained - SmartPM

 The BA should proceed by obtaining approval to change the policies that are either constraining or insufficient to achieve the value desired by the future state. This is because the BA’s role is to align the solution with the business need and ensure that it delivers value to the stakeholders. If the existing policies are preventing or limiting the value realization, the BA should seek to change them by following the appropriate governance process and obtaining the necessary buy-in from the policy owners and other affected parties. Modifying the solution to comply with the policies, identifying an assumption about future state value, or modeling two future states are not the best options because they do not address the root cause of the problem and may result in suboptimal or ineffective solutions. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 6: Strategy Analysis, page 254
• Business Analysis Body of Knowledge (BABOK) Guide, Version 3, Chapter 5: Strategy Analysis, section 5.3: Define Future State, page 99
• Business Analysis Professional Resources, IIBA Resource Collection, Business Analysis Body of Knowledge (BABOK) Guide
• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Skillsoft Book, Chapter 6: Strategy Analysis, page 254

 In the context of a parcel tracking solution, non-functional requirements are crucial as they define the system’s performance, security, usability, etc., ensuring that the solution adds value to both the business and its customers. These requirements ensure that the system is efficient, reliable, and secure and meets user expectations in terms of experience while aligning with legal and regulatory standards. References: The answer can be verified from the following sources:

• A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 3, Chapter 4: Requirements Analysis and Design Definition, p. 115-116; Chapter 5: Requirements Classification Schema, p. 174-175.
• Business Analysis for Practitioners: A Practice Guide, Chapter 5: Requirements Analysis and Design Definition, p. 120-121, 127-128.

Requirement 5 is not atomic, meaning it is not expressed in the simplest form possible. It combines two sub-requirements: one for selecting an option and one for supplying input. These sub-requirements should be separated into two distinct requirements for clarity and traceability. References: CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, page 77; CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, page 77.

The potential success rate of the mortgage origination process can be calculated by subtracting the percentage of total rejects from 100%. The current success rate is 70%, which means the current percentage of total rejects is 30%. If the verification rejects (8.4% of the total transactions) were to be reduced by 50%, there would be only 4.2% verification rejects remaining. This would decrease the percentage of total rejects to (30% - 4.2%) = 25.8%. Therefore, the potential success rate would be (100% - 25.8%) = 74.2%. However, this answer does not account for the effect of the documentation checklists, which would also reduce the documentation rejects (12.2% of the total transactions). Assuming that the documentation checklists would eliminate all the documentation rejects, the percentage of total rejects would further decrease to (25.8% - 12.2%) = 13.6%. Therefore, the potential success rate would increase to (100% - 13.6%) = 86.4%, which can be rounded to 86%.

References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 5: Solution Assessment and Validation, p. 211-212
• Certified Business Analysis Professional™ (CBAP®) Specialization, Course 4: Business Analysis: Solution Evaluation, Week 2: Solution Performance Assessment, Video: Solution Performance Metrics
• Basic Math Operations, Khan Academy

The question asks about the time required to achieve the desired sales and retention goals, given the current rate of increase. To answer this question, we need to use the formula for compound growth rate, which is:

Final value = Initial value x (1 + Growth rate) ^ Number of periods

We can apply this formula to both sales and retention, using the given values and solving for the number of periods. For sales, we have:

1.15 = 1 x (1 + 0.06) ^ Number of periods

Taking the natural logarithm of both sides, we get:

ln(1.15) = ln(1 + 0.06) x Number of periods

Dividing by ln(1 + 0.06), we get:

Number of periods = ln(1.15) / ln(1 + 0.06)

Using a calculator, we get:

Number of periods = 2.29

Since each period is six months, we multiply by 6 to get the number of months:

Number of months = 2.29 x 6

Number of months = 13.74

Rounding up to the nearest whole number, we get:

Number of months = 14

Therefore, it will take 14 months, or about 18 months, to achieve the sales goal.

For retention, we have:

1.1 = 1 x (1 + 0.05) ^ Number of periods

Repeating the same steps as above, we get:

Number of periods = ln(1.1) / ln(1 + 0.05)

Number of periods = 1.86

Number of months = 1.86 x 6

Number of months = 11.16

Rounding up to the nearest whole number, we get:

Number of months = 12

Therefore, it will take 12 months, or 1 year, to achieve the retention goal.

References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 5: Solution Assessment and Validation, p. 211-212
• Certified Business Analysis Professional™ (CBAP®) Specialization, Course 4: Business Analysis: Solution Evaluation, Week 2: Solution Performance Assessment, Video: Solution Performance Metrics
• Compound Growth Rate Calculator

An operational assessment is an input that is required to perform the assessment of enterprise limitations. An operational assessment is a technique that evaluates the current state of the business operations and identifies the gaps, issues, and opportunities for improvement. An operational assessment can help to determine how the solution will affect the existing business processes, policies, procedures, roles, and responsibilities, and how these factors may limit the value realization of the solution. An operational assessment can also help to identify the dependencies, assumptions, constraints, risks, and issues that may arise from the implementation of the solution and how they can be addressed or mitigated.

The other options are not inputs for the assessment of enterprise limitations, but rather outputs or outcomes of the task. Potential value is the expected benefit that the solution will provide to the enterprise and the stakeholders, and it is determined by comparing the current state and the future state of the enterprise. Solution performance analysis is a technique that measures and evaluates the actual performance of the solution against the expected performance and the business objectives. Organizational structure is the arrangement of the roles, responsibilities, and relationships within the enterprise, and it may be affected or changed by the solution.

References:

• [BABOK Guide v3], Section 8.4: Assess Enterprise Limitations, p. 206-207
• Measure Solution Performance, Task Card: Assess Enterprise Limitations, p. 2
• How to assess enterprise limitations – The Functional BA, Blog Post, November 2019

A change in the requirement is a situation where the requirement is different from what was originally agreed upon by the stakeholders. This can happen due to various reasons, such as changing business needs, stakeholder feedback, regulatory changes, or technical constraints. To assess the change, the BA needs to conduct an impact analysis using traceability, which is a technique that involves identifying and documenting the relationships among requirements, stakeholders, solution components, and other artifacts. Traceability can help the BA to determine the scope, cost, schedule, quality, and risk implications of the change, and to communicate them to the relevant stakeholders for approval or rejection. The other options are not the best actions for assessing the change, as they are more suitable for different purposes, such as closing a defect that is not a defect, evaluating the potential threats and opportunities of the change, or finding the underlying cause of the defect. References: CBAP Handbook, CBAP Study Guide, BABOK Guide

An activity diagram is a technique that is used to model the dynamic aspects of a system or a domain. It shows the sequence and conditions of the actions (or activities) that are performed by the actors or components involved in a business process or a use case. An activity diagram can also show the inputs, outputs, and resources required for each action, as well as the exceptions and alternative paths that may occur. An activity diagram can help to identify and analyze the business processes that need to be performed and managed in the future state of the solution. References: The answer can be verified from the following sources:

• A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 3, Chapter 9: Data Modeling, p. 326-331; Chapter 10: Data Flow Diagrams, p. 336-339; Chapter 10: Activity Diagrams, p. 340-343.
• Business Analysis for Practitioners: A Practice Guide, Chapter 5: Requirements Analysis and Design Definition, p. 125-126, 131-132.

A process diagram is a kind of asset that the BA should provide to fully specify the approval requirement. A process diagram is a visual representation of the sequence of activities and decisions involved in a business process or a system. It shows the inputs, outputs, roles, tasks, events, conditions, and flows that occur in each step of the process. A process diagram can help the BA specify the approval requirement by showing:

• Which incident-related activities require approval and confirmation
• Who are the authorized personnel for each activity
• What are the criteria and triggers for approval and confirmation
• What are the outcomes and exceptions of approval and confirmation

A process diagram can also help the EA compare the existing application and the new application by showing the similarities and differences in the process flows, data sources, and user interfaces.

References:

• [BABOK Guide v3], Section 10.28: Process Modeling, p. 410-412
• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 4: Requirements Elicitation and Collaboration, p. 161-163
• Certified Business Analysis Professional™ (CBAP®) Specialization, Course 2: Business Analysis: Requirements Elicitation and Analysis, Week 4: Requirements Analysis Techniques, Video: Process Modeling

 In this scenario, the distributor is under pressure to fully meet the year-round market demand in order to stay in business. The primary objective is not directly related to making more profit, defeating competitors, or stabilizing its performance but rather ensuring that customer orders are fulfilled even during peak demand periods. This aligns with one of the key aspects of business analysis - understanding and prioritizing the needs and expectations of stakeholders (in this case, customers) to deliver value. References: Business Analysis Professional (CBAP) Learning documents or resources available at 1 and 2

The governance approach defines the roles and responsibilities of the stakeholders involved in the business analysis activities, including who has the authority to make decisions and approve deliverables. In this case, the Director of Human Resources is not the decision maker, but one of the stakeholders who needs to be consulted and informed. The final decision should be made by those who have the decision-making authority as per the governance approach, which may include the sponsor, the Director of Finance, or other senior managers. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 2: Business Analysis Planning and Monitoring, page 67
• BABOK Guide, Version 3, Section 2.4: Governance, page 29

 A focus group is a technique that involves organizing a discussion with a small group of stakeholders to understand their perceived value and expectations of a set of requirements and design options. A focus group can help the BA to estimate the potential value delivered by the solution, as it allows the BA to collect feedback, opinions, preferences, and attitudes from the stakeholders in a structured and interactive way. A focus group can also help the BA to identify and resolve any conflicts or issues among the stakeholders, and to build consensus and buy-in for the solution. The other options are not the best techniques for this purpose, as they are more focused on generating and evaluating ideas, collecting information from a large number of stakeholders, or interviewing stakeholders individually or in a group. References: CBAP Handbook, CBAP Study Guide, BABOK Guide

According to the BABOK Guide, “prioritization is the process of ranking requirements in order of importance or urgency”. However, not all requirements can be prioritized at the same time, especially if they are not stable or well-defined. In such cases, the BA should leave the priority unfilled until the requirements are clarified and agreed upon by the stakeholders. This will avoid premature decisions that may lead to rework, conflicts, or missed expectations. The BA should also communicate the rationale for leaving the priority unfilled and the criteria for assigning it later. References: BABOK Guide, Version 3, Section 6.2.4.3, CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 8, Page 287

The timing of business analysis work in this project should be defined by the overall project schedule, which is the plan that outlines the sequence and duration of project activities and tasks. The business analysis work should be aligned with the project schedule to ensure that the deliverables are completed on time and within the scope and budget of the project. The business analyst should also consider the dependencies, risks, and constraints that may affect the timing of business analysis work, such as the availability of stakeholders, the complexity of requirements, the quality of data, and the change management process. The business analyst should communicate and coordinate with the project manager and the solution consultants to ensure that the business analysis work is integrated with the project schedule and meets the expectations of the sponsor and the PGA staff.

References:

• BABOK Guide v3, Section 3.2: Plan Business Analysis Approach, p. 48-49
• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 2: Business Analysis Planning and Monitoring, p. 51-52
• Certified Business Analysis Professional™ (CBAP®) Specialization, Course 1: Business Analysis: Planning and Communication, Week 2: Planning the Business Analysis Approach, Video: Planning the Business Analysis Work

The lead BA should track approvals at the level of individual requirements, as this is the first step to address the root cause of the problem, which is the lack of agreement and clarity on the requirements. By tracking approvals at the level of individual requirements, the lead BA can identify which requirements are causing the most disagreement or confusion, and focus on resolving them with the relevant stakeholders. This can also help to reduce the number of reviews and sign-offs needed, as well as the time and effort spent on them. Tracking approvals at the level of individual requirements can also provide objective evidence of the progress and quality of the requirements, and support the communication and collaboration among the stakeholders.

The other options are not the best actions to take first. Escalating the problem to the executive management may be necessary at some point, but it is not the first thing to do, as it may create more conflict and pressure, and undermine the lead BA’s credibility and authority. Setting limits on duration of sign-offs and the number of reviews may be helpful to manage the expectations and deadlines, but it does not address the underlying issue of the requirements quality and agreement. Offering the stakeholders incentives to sign off documents sooner may be counterproductive, as it may encourage hasty or superficial approvals, and compromise the validity and value of the requirements. References: The answer can be verified from the following sources:

• A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 3, Chapter 6: Requirements Life Cycle Management, p. 202-203, 207-208, 211-212.
• Business Analysis for Practitioners: A Practice Guide, Chapter 4: Requirements Life Cycle Management, p. 97-98, 101-102, 105-106.

The lead BA is trying to improve the business analysis practices by finding out the root causes of the problems and inefficiencies in the current state. By measuring the time spent on planned and unplanned activities, the lead BA can identify the typical missing or wasteful activities that are affecting the quality and timeliness of the deliverables. For example, the lead BA may discover that the BAs are spending too much time on rework, clarifications, or scope changes due to poor elicitation, validation, or prioritization techniques. The lead BA can then propose solutions to address these issues and enhance the business analysis performance and value. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 2: Business Analysis Planning and Monitoring, page 57
• Senior Business Analysis Certification CBAP® | IIBA®, Business Analysis Planning and Monitoring, page 5

1. The BA has collected the following information over the last three months

2. current process capability were increased by 50% => 30 + (30/2) =45

3. new success rate continues to remain the same after implementing the BA's recommendation = 80%

Total success = 80% of 45 = 36

So, per month = 36 / 3 =12

References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 5: Solution Assessment and Validation, p. 211-212
• Certified Business Analysis Professional™ (CBAP®) Specialization, Course 4: Business Analysis: Solution Evaluation, Week 2: Solution Performance Assessment, Video: Solution Performance Metrics
• Basic Math Operations, Khan Academy

The activity that the BA should do to determine which stores will be the first to start the renovations is to perform document analysis for stores annual records. Document analysis is a technique that involves reviewing existing documentation to elicit relevant information for the business analysis purpose. In this case, the BA needs to analyze the annual records of each store to identify the top 25 revenue-producing stores, as per the CEO’s decision. This would provide the BA with objective and reliable data to prioritize the stores for the renovation project. The other options are not as effective or efficient as document analysis, because they rely on subjective or incomplete information from the store managers, who may have different opinions or preferences on which stores should be renovated first. References:

• [BABOK Guide v3], Section 10.18: Document Analysis, p. 386-387
• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 4: Requirements Elicitation and Collaboration, p. 149-150
• Certified Business Analysis Professional™ (CBAP®) Specialization, Course 2: Business Analysis: Requirements Elicitation and Analysis, Week 1: Elicitation Techniques, Video: Document Analysis

The BA should recommend to gather more information from the individuals who had errors when they attempted to sign on, as this would help to identify and resolve the root cause of the problem. The BA could use techniques such as interviews, surveys, or observation to collect feedback from the affected users, and to understand their needs, expectations, and challenges. The BA could also analyze the system event log to find out the details and frequency of the errors, and to determine if they are related to the user’s behavior, the system’s design, or the environment’s conditions. By gathering more information, the BA could propose and implement appropriate solutions to improve the overall performance of the pilot application. The other options are not the best recommendations for improving the performance, as they may not address the underlying problem, or may introduce new risks or issues. For example, sending a reminder of the user ID and password may not help if the users already know them, or may compromise the security of the system. Automating the login process may not be feasible or desirable, as it may require significant changes to the system or the user’s preferences. Extending the pilot to more people may not improve the performance, but may worsen it, as more users may encounter the same errors or create more workload for the system. References: CBAP Handbook, CBAP Study Guide, BABOK Guide

A data model is a diagram type that can describe the association between the subscriber, the medical plan, and the participating service providers. A data model is a visual representation of the data entities, attributes, and relationships involved in a business domain or a system. It shows the structure, constraints, and rules that govern the data and how they are stored, accessed, and manipulated. A data model can help the business analyst specify the data requirements for the mobile application platform and how the data is integrated from different sources. A data model can also help the enterprise architect compare the existing solution and the new solution by showing the similarities and differences in the data entities, attributes, and relationships.

References:

• [BABOK Guide v3], Section 10.9: Data Modeling, p. 358-360
• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 6: Requirements Analysis and Design Definition, p. 221-223
• Certified Business Analysis Professional™ (CBAP®) Specialization, Course 2: Business Analysis: Requirements Elicitation and Analysis, Week 4: Requirements Analysis Techniques, Video: Data Modeling

Performance variance is the difference between the actual and expected results of a business activity or process. In this case, the business sponsor expected that the promotions would be viewed by at least 30% of the customers and that they would help reduce claims. However, the actual results showed that only 5% of the customers viewed the promotions and that claims increased by 20%. The business sponsor wanted to understand the reasons for this discrepancy and how to improve the effectiveness of the promotions.

• Data mining is a technique that involves analyzing large data sets to discover patterns and trends that can provide useful information or insights123
• The BA used data mining to find the source of the increase in claims by examining the documentation of the 1000 claims that were filed during the pilot period. The BA found that the majority of the claims were caused by severe winter storms in one region of the country, which were beyond the control of the customers.
• Document analysis is a technique that involves reviewing and evaluating existing documents to elicit information and identify requirements.
• The BA did not use document analysis to find the source of the increase in claims because this technique is more suitable for analyzing the content and structure of the documents, not the data within them.
• Survey is a technique that involves collecting information from a sample of stakeholders using a predefined set of questions.
• The BA did use survey to understand the customer feedback and preferences on the site and the promotions, but not to find the source of the increase in claims. The survey did not ask the customers about the reasons for their claims or the impact of the winter storms.
• Decision modelling is a technique that involves defining and analyzing the criteria, options, and outcomes of a decision.
• The BA did not use decision modelling to find the source of the increase in claims because this technique is more suitable for evaluating the alternatives and consequences of a decision, not the causes and effects of a problem.

A complete requirement is one that provides all the information necessary for the reader to understand it without ambiguity or confusion. This requirement is incomplete because it does not specify what constitutes an incident-related event, who are the appropriate stakeholders, what is the expected timeliness and reliability of the notification, and how the notification should be delivered. These details are essential for designing and testing the solution that meets the requirement. References: CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 3, page 87; CBAP / CCBA Certified Business Analysis Study Guide, Chapter 3, page 86.

 This requirement implies that the new web-based system will provide faster and easier access to the company’s financial information, which is an improvement over the current client-based system.

A collaborative approach is a type of elicitation approach that involves working with multiple stakeholders simultaneously to elicit, analyze, and validate requirements. A collaborative approach can help to complete requirements elicitation activities in a short period of time, as it can:

• Reduce the number of individual meetings and interviews that need to be conducted
• Increase the quality and quantity of information that can be gathered from different perspectives and sources
• Enhance the communication and understanding among the stakeholders and the BA
• Promote the consensus and agreement on the requirements and the solution scope
• Identify and resolve any conflicts, issues, or gaps in the requirements

Some examples of collaborative elicitation techniques are:

• Requirements workshops: A structured and facilitated session that brings together a group of stakeholders to elicit, analyze, and prioritize requirements
• Brainstorming: A technique that generates a large number of ideas or solutions from a group of stakeholders in a creative and spontaneous manner
• Focus groups: A technique that collects the opinions, preferences, and feedback of a group of stakeholders on a specific topic or issue
• Prototyping: A technique that creates a simplified or partial version of the solution to elicit, demonstrate, and validate requirements

The other options are not correct because they are not types of elicitation approaches, but rather techniques that can be used within an elicitation approach. An experiment is a technique that tests a hypothesis or an assumption by observing the results of a controlled or simulated scenario. An estimation is a technique that approximates the size, cost, duration, or effort of a project or a solution. A research is a technique that collects and analyzes information from existing sources, such as documents, reports, databases, etc.

References:

• [BABOK Guide v3], Section 4.2: Conduct Elicitation, p. 100-101
• Types of Elicitation Techniques for the Business Analyst, Blog Post, September 2018
• Elicitation Techniques Used by Business Analysts – Tips and Guidance, Blog Post, July 2023

This is an example of a corrective action, which is an action taken to bring the project performance back in line with the plan. The schedule performance index (SPI) is a measure of schedule efficiency, expressed as the ratio of earned value to planned value. An SPI of less than 1 indicates that the project is behind schedule. In this case, the SPI was 0.87, which means that the project was only 87% as far along as it should have been at milestone 6. To correct this situation, three project team members worked overtime to catch up with the planned schedule. This is a corrective action because it addresses an existing problem and aims to eliminate the root cause of the deviation. References: Schedule Performance Index (SPI) for PMP® Exam Prep, CBAP Training and Exam Preparation - IIBA Endorsed Course, CBAP Step-by-Step Application Process Guide

Stakeholder availability, attitude, and willingness to engage are critical factors for the success of any business analysis effort, as they affect the quality, validity, and acceptance of the requirements and the solution. If the stakeholders are not available or willing to participate in the elicitation, validation, and verification activities, the BA may face difficulties in obtaining, confirming, and managing the requirements, and in ensuring that they meet the stakeholder needs and expectations. Moreover, if the stakeholders are not engaged or supportive of the change initiative, they may delay or reject the approval of the requirements or the solution, which can impact the timeliness of project delivery as well as the realization of the business value. Therefore, the BA should try to schedule stakeholder meetings as early and as frequently as possible, and use various techniques to communicate and collaborate with the stakeholders effectively. The other options are not the best answers, as they are not directly influenced by the stakeholder availability, attitude, and willingness to engage, but rather by other factors, such as the testing strategy, the governance approach, the reuse strategy, or the risk management process. References: Golden Rules of Stakeholder Engagement in Business Analysis, Engaging Stakeholders in Elicitation and Collaboration, CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, [BABOK Guide]

The BA noticed that only 30% of trips have their orders ready for loading when a truck arrives, meaning 70% of the time, trucks are waiting an extra hour. If each truck can make two trips a day and there are 12 trucks, that’s a total of 24 trips per day. With 70% of these trips experiencing downtime, that’s approximately 17 trips (16.8 rounded up). Since each downtime lasts an hour, this results in approximately 17 hours lost to downtime each day.

However, the question asks if trucks are the only constraint - meaning we should consider the maximum capacity of trucks which is not being fully utilized due to other constraints (like workers or tallyers). In this case, we need to calculate how many more hours would be lost if the trucks were operating at full capacity.

The total capacity tons/day for workers is 89 tons/day and for tallyers is 74 tons/day which are less than the truck’s capacity of 101 tons/day. So, we consider worker’s capacity as a constraint here.

Now let’s calculate how many more trips could be made if there were no constraints from workers or tallyers:

101 (truck’s total daily tonnage capacity) /89 (worker’s total daily tonnage capacity) = approximately1.13

So if there were no constraints from workers or tallyers, each truck could make approximately one additional trip per day.

Now let’s add these potential additional trips to our original calculation:

17 (original downtime hours) +3 (additional potential downtime hours due to increased number of trips) =20 total downtime hours

So if trucks were the only constraint and all other factors allowed them to operate at full capacity, approximately20 hours would be lost due to this downtime. References: This answer is inferred based on general business analysis principles as I need access to specific CBAP learning documents or resources for precise referencing and verification according to CBAP standards.

Option D shows the correct use of the include relationship between the three use cases. This means that the “Pass a two-factor authentication” use case is a mandatory part of both the “Change system parameters” and the “Setup new supervisor” use cases, and it always occurs whenever either of them is executed. The arrow points from the base use case to the included use case, as per the UML notation. Option C is incorrect because it uses the protect relationship, which is a non-standard extension of the UML notation. It indicates that the “Pass a two-factor authentication” use case is a security requirement for the other two use cases, but it does not specify how or when it is executed. Options A and B are incorrect because they use the extend relationship, which means that the “Pass a two-factor authentication” use case is an optional extension of the other two use cases, and it only occurs under certain conditions. This does not reflect the requirement that the two-factor authentication is mandatory for both functions. References:

• [A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 3], Chapter 10: Techniques, pp. 424-425.
• [UML 2.5 Specification], Chapter 18: Use Cases, pp. 637-638.

Tracing requirements is a task that involves identifying and documenting the relationships among requirements, stakeholders, solution components, and other artifacts. Tracing requirements can help the BA to discover the issues of missing or unsupported functionality, as it allows the BA to track the origin, allocation, dependencies, and impact of each requirement. By tracing requirements, the BA can ensure that the requirements are aligned with the business need and objectives, and that they are implemented and verified in the solution. The other options are not the tasks that the BA used to discover the issues, as they are more related to the definition, elicitation, or evaluation of the requirements, rather than the tracing of the requirements. References: Task: Trace Requirements, CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, BABOK Guide

A change strategy is a plan that outlines how the project team will manage the transition from the current state to the future state of the system, and how they will address the impacts and risks of the change on the organization and the stakeholders. A change strategy is needed when system A is offline for 3 months, as this will affect the claims processing operations and the user experience. A change strategy should include the following elements:

• Change vision and objectives: This defines the purpose and scope of the change, and the expected outcomes and benefits of the system upgrade.
• Change readiness assessment: This evaluates the current level of awareness, willingness, and ability of the organization and the stakeholders to adopt the change, and identifies any gaps or barriers that need to be addressed.
• Change impact analysis: This identifies and analyzes the potential effects of the change on the business processes, roles and responsibilities, policies and procedures, systems and tools, and culture and behavior of the organization and the stakeholders.
• Change communication plan: This specifies the key messages, channels, methods, and frequency of communication with the organization and the stakeholders, and how to solicit and incorporate feedback and input.
• Change training plan: This defines the learning objectives, content, delivery modes, and evaluation methods of the training programs that will help the organization and the stakeholders acquire the necessary knowledge and skills to use the upgraded system.
• Change management roles and responsibilities: This clarifies the roles and expectations of the project team, the sponsors, the champions, the change agents, and the end users in the change process, and how they will collaborate and coordinate with each other.
• Change monitoring and evaluation plan: This establishes the metrics, indicators, and tools that will measure the progress and performance of the change process, and how to report and act on the results.

References:

• IIBA BABOK Guide, Section 5.6, Define Change Strategy
• Change Management Strategy: A Guide with Best Practices, Smartsheet
• How to Develop a Change Management Strategy, Indeed

 A use case diagram is a technique that helps to depict the interactions between a system and its actors using graphical symbols and relationships. A use case diagram shows the actors that are involved in the system, the use cases that represent the functions or services that the system provides, and the associations that indicate how the actors and use cases are related. A use case diagram can be used with a state diagram to verify that all functions are defined to work with entity “User” for the different roles, as it can help to identify the use cases that correspond to the states and transitions of the entity, and to ensure that the use cases are complete, consistent, and accurate. A sequence diagram is a technique that helps to represent the sequence and timing of the messages that are exchanged between the objects or components of a system. A sequence diagram shows the objects or components that participate in the interaction, the messages that are sent and received by the objects or components, and the time order of the messages. A sequence diagram can help to illustrate the dynamic behavior and logic of the system, but it does not show the interactions between the system and its actors. A functional diagram is a technique that helps to represent the functions or processes that are performed by a system or a solution using graphical symbols and relationships. A functional diagram shows the functions or processes that are relevant to the domain, the inputs and outputs of each function or process, and the decomposition and hierarchy of the functions or processes. A functional diagram can help to define and analyze the functional requirements, but it does not show the interactions between the system and its actors. A data flow diagram is a technique that helps to create a high-level overview of a business process by showing the movement and transformation of data between entities and processes. A data flow diagram uses graphical symbols and arrows to represent the sources and destinations of data, the processes that manipulate data, the data stores that store data, and the data flows that transfer data. A data flow diagram can help to understand and document the data logic and structure of the business process, but it does not show the interactions between the system and its actors. References: BABOK Guide v3, Chapter 10: Techniques, Section 10.50: Use Case Diagram, p. 564-566; Section 10.49: Sequence Diagram, p. 562-563; Section 10.22: Functional Decomposition, p. 528-529; Section 10.18: Data Flow Diagrams, p. 522-524.

A performance assessment is a business analysis artifact that evaluates the effectiveness and efficiency of the business analysis work. It can be used to identify and document the improvement areas for the next piece of analysis work, as well as to measure the value delivered by the business analysis outcomes. A performance assessment can include metrics, indicators, targets, and feedback mechanisms that help the BA to monitor and improve the business analysis performance12. References:

• 1: BABOK Guide v3, Chapter 2: Business Analysis Planning and Monitoring, Section 2.5: Plan Business Analysis Performance Improvements
• 2: Tasks Mapped To Artifacts(https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/5769/Tasks-Mapped-To-Artifacts.aspx)

The BA is using this technique to manage stakeholder collaboration. This technique is known as affinity diagram, which is a technique that helps organize and categorize a large number of ideas, issues, or requirements into logical groups based on their natural relationships or common themes. Affinity diagram can help to manage stakeholder collaboration by facilitating brainstorming, encouraging participation, building consensus, and resolving conflicts among the stakeholders. Affinity diagram can also help to elicit, analyze, and prioritize requirements, but that is not the primary purpose of this technique. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 4: Elicitation and Collaboration, Section 4.3: Confirm Elicitation Results, p. 175-176
• A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 4: Elicitation and Collaboration, Section 4.3: Confirm Elicitation Results, p. 108-109
• A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 9: Underlying Competencies, Section 9.3: Collaboration and Teamwork, p. 350-351

The appropriate model type to assist the stakeholders in testing the performance and visual aspects of requirements 3 through 11 is a usability prototype. A usability prototype is a model that simulates the look and feel of the user interface of the solution, such as the layout, navigation, colors, fonts, and graphics. A usability prototype can help the stakeholders to evaluate the user experience, the ease of use, the accessibility, and the satisfaction of the solution. A usability prototype can also help to identify and resolve any usability issues or defects before the final implementation of the solution. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 6: Requirements Analysis and Design Definition, Section 6.4: Model and Validate Requirements, p. 265-266
• A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 6: Requirements Analysis and Design Definition, Section 6.4: Model Requirements, p. 161-162
• A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 10: Solution Evaluation, Section 10.6: Validate Solution, p. 283-284

 The CFO’s resistance to replacing the older vehicles and suggesting that the truck drivers manually send the truck location from a handheld mobile device every 20 minutes is an opportunity cost. An opportunity cost is the value of the next best alternative that is foregone as a result of making a decision. In this case, the opportunity cost of not replacing the older vehicles is the potential loss of customer satisfaction, retention, and loyalty due to the less accurate and less convenient tracking system. The CFO is choosing to save money on the upfront cost of buying new trucks, but at the expense of losing the competitive advantage and long-term benefits of having a live parcel tracking system. References:

• IIBA BABOK Guide, Section 10.23, Decision Analysis
• Opportunity Cost: Definition, Real-World Examples, How to Calculate, The Balance
• What is Opportunity Cost and How to Calculate It, Investopedia

The BA presented an opportunity to increase efficiencies by simplifying the process of shipping to new countries and reducing the dependency on IT. By eliminating the need to maintain different variations of ship-to-country and location-to-route for various freight carriers, the BA enabled the business to save time and resources, and avoid potential errors or delays. This is an example of how a BA can add value to the business by identifying and proposing solutions that improve the current state and address the root causes of the problems. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 2: Business Analysis Planning and Monitoring, page 50
• Business Analysis Body of Knowledge (BABOK ®) Guide, Version 3, Chapter 6: Solution Evaluation, section 6.5.2: Assess Enterprise Limitations, page 176
• Certified Business Analysis Professional™ (CBAP®) | Coursera, Course 4: Business Analysis Planning and Monitoring, Week 2: Plan Business Analysis Approach, video: “Solution Evaluation”

 The BA should recommend to assign the feature a lower priority for future release. This means that the feature will not be included in the initial release of the solution, but it may be considered for later releases depending on the availability of resources, the feedback from the stakeholders, and the alignment with the business objectives. This approach can help to balance the value and the effort of the feature, as well as to avoid scope creep and unnecessary complexity in the initial release. The other options are not the best recommendations, as they may either ignore the needs of the stakeholders, disrupt the existing business process, or increase the risk and cost of the project. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 6: Requirements Analysis and Design Definition, Section 6.3: Prioritize Requirements, p. 255-256
• A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 6: Requirements Analysis and Design Definition, Section 6.3: Prioritize Requirements, p. 155-156