CBAP Certified Business Analysis Professional Questions and Answers

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 should provide process models as artifacts that can be used organization wide for the long-term. Process models are graphical representations of the activities, inputs, outputs, and interactions of a business process. They can help to document, analyze, improve, and communicate the current and future states of a process. They can also serve as a basis for developing other artifacts, such as requirements, test cases, user manuals, and training materials. Process models can be useful for various stakeholders, such as business users, managers, developers, testers, and trainers, to understand and optimize the business process. 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. 263-264
• 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. 159-160
• A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 9: Solution Evaluation, Section 9.5: Assess Organizational Readiness, p. 261-262

 A concept model is a visual representation of the business concepts and their relationships. It helps to clarify the meaning of the terms and concepts used in the requirements. However, different stakeholders may have different levels of understanding and interest in the concept model, depending on their roles and perspectives. Therefore, the BA should use an appropriate level of abstraction to support differing viewports, which are views of the same model that focus on different aspects or levels of detail. This way, the BA can tailor the presentation of the concept model to suit the needs and expectations of each stakeholder group, and help them understand the impacts to their respective daily tasks. References: BABOK Guide v3, p. 112-113; CBAP/CCBA Study Guide, p. 140-141.

 A formal review with the stakeholders is a way to validate the elicitation results and ensure that nothing is missed or misunderstood. The review can also help to build trust and confidence among the stakeholders and the BA. The other options are not directly related to addressing the sponsor’s concerns. References: CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 5: Elicitation and Collaboration, p. 173-174; [A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 3], Chapter 4: Elicitation and Collaboration, Section 4.4: Confirm Elicitation Results, p. 107-108.

A BA should identify any potential constraints that may affect the requirements or the solution and communicate them to the relevant stakeholders for resolution. In this case, the policies are a constraint that may prevent the implementation of the requirement or require a change to the policies. The BA should review the constraint with management and seek their guidance on how to proceed. The BA should not modify the policies or the requirements without proper approval or justification. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 5: Requirements Analysis and Design Definition, page 214
• Business Analysis Body of Knowledge (BABOK ®) Guide, Version 3, Section 5.2: Analyze Current State, page 112
• Certified Business Analysis Professional™ (CBAP®) | Coursera, Course 3: Requirements Analysis and Design Definition, Week 2: Analyze Current State, video: “Identify Constraints”

Reviews and workshops are effective techniques for validating and negotiating requirements with stakeholders. They can help the BA to identify and resolve any conflicting or contradictory requirements, as well as to gain consensus and agreement among the stakeholders. Reviews can be done in various forms, such as walkthroughs, inspections, or peer reviews. Workshops can be used to facilitate collaborative discussions, brainstorming, and decision making among the stakeholders. Both techniques can help the BA to safeguard against conflicting requirements by ensuring that the requirements are clear, accurate, complete, and aligned with the business goals and needs123. References:

• 1: BABOK Guide v3, Chapter 4: Elicitation and Collaboration, Section 4.5: Validate Requirements
• 2: BABOK Guide v3, Chapter 5: Requirements Life Cycle Management, Section 5.5: Approve Requirements
• 3: BABOK Guide v3, Chapter 10: Techniques, Section 10.32: Reviews, Section 10.50: Workshops

 The relationships among the requirements add to the level of complexity of the solution. Requirements can have dependencies, conflicts, overlaps, and gaps that make them more difficult to analyze, prioritize, and implement. The business analyst needs to identify and manage these relationships to ensure the solution meets the stakeholder needs and delivers value. References:

• A Guide to the Business Analysis Body of Knowledge (BABOK Guide), version 3, section 4.2.3
• Business Analysis Professional (CBAP) Certification Study Guide, version 3.0, page 131

 Process modeling is a technique that can be used to define and document the business analysis approach, as it describes the activities, tasks, inputs, outputs, and roles involved in the business analysis work. Process modeling can help to identify the scope, objectives, deliverables, dependencies, assumptions, constraints, and risks of the business analysis work. Process modeling can also help to communicate and validate the business analysis approach with stakeholders and ensure alignment with the project management approach. References: BABOK Guide v3, section 4.1.1.1, page 110; Business Analysis Techniques: Planning and Monitoring Business Analysis Work by Milena Pajic, section Using Process Modeling for Planning and Monitoring, page 171

A WBS, or Work Breakdown Structure, is a technique that is used to divide a project into controllable parts. It is a hierarchical decomposition of the project scope into smaller and more manageable components, called work packages. Each work package represents a deliverable or an outcome that contributes to the project objectives. A WBS helps to define and organize the project work, estimate the time and cost, assign the roles and responsibilities, and monitor and control the project progress. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, page 47
• Business Analysis Professional Resources | IIBA®, under Business Analysis Body of Knowledge (BABOK ®) Guide
• Work Breakdown Structure Wbs vs. Project Plan vs. Project Schedule, paragraph 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 business analysis approach is the set of processes, activities, tasks, deliverables, and techniques that are used to conduct business analysis. The business analysis approach should be aligned with the needs, preferences, and expectations of the stakeholders, as well as the characteristics and constraints of the project and the organization. The level of formality is one of the factors that influences the business analysis approach. It refers to the degree of rigor, detail, and documentation that is required for the business analysis work. The level of formality may vary depending on the type, size, complexity, and risk of the project, as well as the regulatory and governance requirements, the stakeholder involvement, and the organizational culture. In this scenario, the BA is dealing with two main stakeholders that have different levels of formality. The government agency is highly regulated and may require a formal approach that follows strict standards, policies, and procedures, and produces detailed and comprehensive documentation. The private company is less formal and may prefer a flexible and collaborative approach that allows for rapid changes, feedback, and experimentation, and produces minimal and concise documentation. Therefore, the BA’s strategy should be to develop consensus on a tailored approach for formality that balances the needs and expectations of both stakeholders, and that is suitable for the project context and objectives. The BA should facilitate a meeting with the representatives from each entity and discuss the advantages and disadvantages of different levels of formality, and how they can be adapted and customized to meet the project requirements and deliver value. The BA should also consider the impact of the level of formality on the other aspects of the business analysis approach, such as the planning, elicitation, analysis, validation, and management of the requirements and design specifications. The BA should seek to achieve a common understanding and agreement among the stakeholders on the level of formality and the business analysis approach. Option B is incorrect because using a formal approach to appeal to the government entity’s higher authority may not satisfy the needs and preferences of the private company, and may create conflict and dissatisfaction among the stakeholders. Option C is incorrect because employing the standard business analysis level of formality may not be appropriate or effective for the project and the organization, and may not address the specific needs and expectations of the stakeholders. Option D is incorrect because asking the government entity to accept a flexible collaborative approach may not comply with the regulatory and governance requirements, and may create resistance and distrust among the stakeholders. References: BABOK Guide v3, Chapter 2: Business Analysis Planning and Monitoring, Section 2.2: Plan Business Analysis Approach, p. 28-32; Chapter 10: Techniques, Section 10.6: Business Analysis Approach, p. 501-502.

 A change control process is a technique that helps to manage the changes to the requirements or the solution throughout the project lifecycle. A change control process defines the roles and responsibilities, the criteria and procedures, the tools and techniques, and the documentation and communication for handling the changes. A change control process helps to ensure that the changes are properly identified, analyzed, approved, implemented, verified, and tracked. A change control process can help the BA to keep this situation from occurring in the future by creating a clear and consistent mechanism for managing the changes and avoiding any unauthorized or uncontrolled changes that may affect the quality or scope of the solution. A risk strategy is a technique that helps to identify, analyze, and manage the uncertainties and threats that may affect the project or the solution. A risk strategy defines the risk appetite, tolerance, and thresholds, the risk identification and assessment methods, the risk response and monitoring plans, and the risk roles and responsibilities. A risk strategy can help the BA to mitigate the potential impacts of the changes, but it does not prevent the changes from occurring. A prioritization approach is a technique that helps to rank the requirements or solution options based on their relative importance, urgency, value, or dependency. A prioritization approach defines the criteria and methods, the tools and techniques, and the roles and responsibilities for prioritizing the requirements or solution options. A prioritization approach can help the BA to determine the optimal scope and sequence of the solution delivery, but it does not control the changes to the requirements or solution options. A stakeholder engagement plan is a technique that helps to plan and manage the interactions and communications with the stakeholders throughout the project. A stakeholder engagement plan defines the stakeholder identification and analysis, the stakeholder communication and collaboration methods, the stakeholder feedback and approval mechanisms, and the stakeholder roles and responsibilities. A stakeholder engagement plan can help the BA to ensure that the stakeholders are informed, engaged, and satisfied with the project progress and outcomes, but it does not regulate the changes requested by the stakeholders. References: BABOK Guide v3, Chapter 10: Techniques, Section 10.11: Change Control Process, p. 510-512; Section 10.51: Risk Analysis and Management, p. 567-569; Section 10.38: Prioritization, p. 550-552; Section 10.24: Focus Groups, p. 532-533.

The implementation approach is a component of the solution scope that describes how the chosen solution approach will deliver the solution scope. The solution approach is the method or process that will be used to implement the solution, such as a predictive or adaptive approach. The solution scope is the set of capabilities and features that the solution must provide to meet the business need1. The implementation approach explains how the solution approach will be applied to achieve the solution scope, such as the phases, activities, tasks, deliverables, and resources involved. The implementation approach also considers the risks, issues, assumptions, and constraints that may affect the implementation process23.

The other options are not correct. A. The implementation approach is not described in terms of the major features and functions that are to be included, as this is part of the solution scope, not the implementation approach. B. The implementation approach does not define major business and technical dependencies that impose constraints to the effort to deploy the solution, as this is part of the risk analysis, not the implementation approach. C. The implementation approach does not describe the new capabilities required to meet the business need, as this is part of the solution scope, not the implementation approach. References:

• Solution Scope - IIBA®
• Defining the Business Analysis Approach in 2023 | Free Template
• Business Analysis Planning and Monitoring - IIBA®

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

 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

 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

 A workshop is a technique that helps to facilitate a structured and collaborative discussion among a group of stakeholders on a specific topic, such as the impact of the requirement changes. A workshop can help the BA to obtain a resolution on the impact of the requirement changes by providing an opportunity for the stakeholders to share their views, concerns, and suggestions, to analyze the pros and cons of the changes, to negotiate and resolve any conflicts or disagreements, and to reach a consensus on the best course of action. A workshop can also help the BA to communicate the rationale and benefits of the changes, to obtain feedback and approval from the stakeholders, and to document the outcomes and action items of the discussion. A focus group is a technique that helps to elicit the opinions, preferences, and feedback of a group of stakeholders about a specific topic, such as a prototype or a solution option. A focus group can help the BA to understand the stakeholders’ perception, ideas, and attitudes, and to identify any issues, gaps, or improvements, but it does not help the BA to obtain a resolution on the impact of the requirement changes. An interview is a technique that helps to elicit information from an individual stakeholder or a small group of stakeholders by asking open-ended, closed-ended, or probing questions. An interview can help the BA to gather detailed and specific information, to clarify and validate the requirements, and to build rapport and trust with the stakeholders, but it does not help the BA to obtain a resolution on the impact of the requirement changes. A survey is a technique that helps to collect quantitative or qualitative data from a large number of stakeholders by using a predefined set of questions or statements. A survey can help the BA to measure the level of satisfaction, agreement, or importance of the stakeholders, to identify the trends and patterns of the data, and to support decision making and prioritization, but it does not help the BA to obtain a resolution on the impact of the requirement changes. References: BABOK Guide v3, Chapter 10: Techniques, Section 10.53: Workshops, p. 570-572; Section 10.24: Focus Groups, p. 532-533; Section 10.25: Interviews, p. 534-536; Section 10.46: Surveys or Questionnaires, p. 560-562.

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

 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

 The first step for the BA is to understand the current state of the service provider’s business operations and the root causes of the reduced profit margin. This will help the BA to identify the problems and opportunities for improvement, as well as to establish a baseline for measuring the effectiveness of the proposed solutions. The BA can use various techniques to conduct the current state analysis, such as document analysis, interviews, observation, surveys, and SWOT analysis. The other options are not the first step, as they are either focused on the future state or the solution, without understanding the current situation and the underlying needs. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 3: Business Analysis Planning and Monitoring, Section 3.2: Plan Business Analysis Approach, p. 93-94
• A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 5: Strategy Analysis, Section 5.1: Analyze Current State, p. 106-109

 The BA should consider including the priority of each requirement in the project requirements document. The priority is the relative importance or urgency of a requirement in relation to other requirements, based on the value, risk, or dependency of the requirement. By assigning a priority to each requirement, the BA can ensure that the requirements are delivered according to the customer expectations and the project constraints, such as time, budget, and scope. The priority can also help to manage changes, resolve conflicts, and allocate resources for the requirements. 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

An elicitation activity plan is a technique that helps to plan and prepare the activities and tasks that are required to elicit the information and requirements from the stakeholders. An elicitation activity plan defines the objectives, scope, approach, methods, techniques, tools, resources, schedule, and deliverables of the elicitation process. An elicitation activity plan can help the BA to create an output of the initial meeting with experts, as it can help to identify the stakeholders, their roles and responsibilities, their information and communication needs, their availability and preferences, and their expectations and constraints. An elicitation activity plan can also help the BA to select the most appropriate and effective elicitation techniques, such as interviews, workshops, observation, or document analysis, to obtain the relevant and reliable information and requirements from the experts. An entity relationship diagram is a technique that helps to represent the data and information needs of an organization or a solution using graphical or textual symbols and relationships. An entity relationship diagram shows the entities that are relevant to the domain, the attributes that describe the entities, and the relationships that exist between the entities. An entity relationship diagram can help the BA to define and analyze the data requirements, but it is not an output of the initial meeting with experts. A current state flowchart is a technique that helps to create a graphical representation of the activities and tasks that are performed to achieve a specific goal or outcome in the current state of the organization or the solution. A current state flowchart shows the sequence and flow of the activities and tasks, the roles and responsibilities of the performers, the inputs and outputs of each activity or task, and the rules and conditions that govern the process. A current state flowchart can help the BA to understand and document the current state of the delivery process, but it is not an output of the initial meeting with experts. An information management approach is a technique that helps to plan and manage the storage, access, distribution, and retention of the information and requirements throughout the project lifecycle. An information management approach defines the format, structure, level of detail, and quality of the information and requirements, the tools and techniques to be used, the roles and responsibilities of the information and requirements owners and users, and the policies and procedures to be followed. An information management approach can help the BA to ensure the consistency, accuracy, completeness, and security of the information and requirements, but it is not an output of the initial meeting with experts. References: BABOK Guide v3, Chapter 10: Techniques, Section 10.12: Elicitation Activity Plan, p. 513-514; Section 10.19: Data Modeling, p. 525-527; Section 10.43: Process Modeling, p. 557-559; Section 10.14: Information Management Approach, p. 516-517.

 The BA can use organizational modeling to highlight the required changes to the structure. Organizational modeling is a technique that involves creating a graphical representation of the roles, responsibilities, relationships, and reporting lines within an organization. It can help to illustrate the current and future states of the organization, identify the gaps and impacts of the change, and communicate the proposed solution to the stakeholders. In this case, the BA can use organizational modeling to show how the process for the first contact resolution for customer issues will be streamlined by having a single point of contact instead of two separate divisions. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 5: Strategy Analysis, Section 5.1: Analyze Current State, p. 207-208
• A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 5: Strategy Analysis, Section 5.1: Analyze Current State, p. 107-108
• A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 10: Solution Evaluation, Section 10.5: Assess Organizational Readiness, p. 281-282

Effectiveness is a performance measure that evaluates how well the work products meet the intended goals and objectives. It can be assessed by comparing the actual outcomes with the expected outcomes, and by measuring the degree of stakeholder satisfaction and value realization. Effectiveness can help the BA to determine the quality and impact of the business analysis work, and to identify any gaps or areas for improvement123. References:

• 1: BABOK Guide v3, Chapter 2: Business Analysis Planning and Monitoring, Section 2.5: Plan Business Analysis Performance Improvements
• 2: BABOK Guide v3, Chapter 10: Techniques, Section 10.35: Root Cause Analysis, Section 10.36: Scope Modeling
• 3: Performance Measurement - What Is It, Example, Methods, Types(https://www.wallstreetmojo.com/performance-measurement/)

 In addition to existing regulations and contracts, the BA also checks the policies of the organization that may constrain the project. Policies are the guidelines or principles that govern the decision making and actions of the organization. They reflect the values, vision, and mission of the organization and provide a framework for achieving its goals and objectives. Policies can also influence the scope, feasibility, and acceptance of the project and its solution. Therefore, the BA should identify and analyze the policies that are relevant to the project and ensure that they are aligned with the requirements and the solution. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 5: Strategy Analysis, Section 5.1: Analyze Current State, p. 206-207
• A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 5: Strategy Analysis, Section 5.1: Analyze Current State, p. 106-107
• A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 10: Solution Evaluation, Section 10.3: Assess Enterprise Limitations, p. 277-278

 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.

 The management horizon is the time period over which the costs and benefits of a proposed solution are evaluated. It is also the point in time when the net present value of the solution becomes positive, meaning that the solution has recovered its initial investment and started to generate a profit. The management horizon helps to determine the feasibility and viability of a solution, as well as its alignment with the strategic goals of the organization. References:

• CBAP® Handbook, page 15, section 4.1.2.3
• BABOK® Guide, page 32, section 3.2.3
• How to Write a Business Case (Template Included), under Step 3: Calculate the Financials

 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

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)

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

Change requests are more likely to occur in the early stages of a project, when the requirements are being elicited, analyzed, and validated. During this time, stakeholders may discover new needs, identify gaps, or revise their expectations. Change requests may also arise due to changes in the business environment, such as new regulations, market trends, or competitor actions. Change requests are less frequent in the later stages of aproject, when the requirements are more stable and the solution is being designed, developed, and tested. References:

• A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 3, Chapter 4: Requirements Life Cycle Management, Section 4.5: Manage Changes1
• CBAP Certification Study Guide v3.0, Chapter 4: Requirements Life Cycle Management, Section 4.5: Manage Changes2

SMART is an acronym that stands for Specific, Measurable, Achievable, Relevant, and Time-bound. It is a widely used approach to assess the business goals and their validity and longevity. SMART helps to ensure that the business goals are clear, realistic, and aligned with the business vision and strategy. SMART also helps to monitor and evaluate the progress and outcomes of the business goals. By using SMART, business analysts can define the business needs and requirements more effectively, and communicate them to the stakeholders more efficiently12. References:

• SMART Goals: Definition and Examples | Indeed.com
• How to Set SMART Goals: Guide for Supervisors and Employees

SWOT analysis is a technique for assessing the internal and external factors that may affect the feasibility, acceptability, and suitability of a proposed solution or solution approach. It evaluates the strengths and weaknesses of the solution or solution approach, as well as the opportunities and threats in the business environment. SWOT analysis helps to identify the key issues and risks that need to be addressed or mitigated, as well as the potential benefits and advantages that can be leveraged or enhanced. References:

• A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 3, Chapter 10: Techniques, Section 10.50: SWOT Analysis
• SWOT Analysis: How To With Table and Example - Investopedia
• SWOT - Definition, Examples, Process, Uses - Corporate Finance Institute

A business case is a document that provides the rationale and justification for initiating a project or an investment. It describes the business problem or opportunity, the proposed solution, the expected benefits, costs, risks, and assumptions. A business case also includes an analysis of the alternatives and a recommendation for the best option. A business case helps management to make a go/no go decision based on the value proposition and the return on investment of the project. A business case is one of the key outputs of the enterprise analysis process, which involves defining the business need, assessing the capability gaps, determining the solution approach, defining the solution scope, and defining the business case1234. References: 1: BABOK Guide v3, section 3.4, pages 68-77 2: CBAP / CCBA Certified Business Analysis Study Guide, chapter 4, pages 107-108 3: Business Analysis Techniques: Developing the Business Case, pages 25-26 4: How to Write a Business Case: 4 Steps to a Perfect Business Case Template

According to the BABOK Guide, defining the business needs is the process of identifying the ends that the organization is seeking to achieve. Business goals and objectives are statements of the desired outcomes of the change initiative that align with the organization’s strategy and vision. They provide the context for identifying and evaluating alternative solutions that can satisfy the business needs. Alternative identification, solution assessment, and requirements are parts of other processes that follow defining the business needs. References:

• BABOK Guide, Chapter 5: Strategy Analysis, Section 5.1: Define the Business Need, p. 100-101
• CBAP Certification Study Guide v3.0, Chapter 5: Strategy Analysis, Section 5.1: Define the Business Need, p. 5-3 to 5-4

 Benchmarking is a technique for comparing the performance or practices of an organization with those of other organizations, usually considered to be the best in the field. It is not a technique for identifying the solution approach, which is the process of defining the most feasible and appropriate way to implement a change that addresses a business need. The other techniques are useful for identifying the solution approach. Decision analysis helps to evaluate multiple options and select the best one based on criteria and trade-offs. Risk analysis helps to identify and assess the uncertainties and potential impacts of the solution approach. Brainstorming helps to generate and explore diverse ideas for the solution approach. References:

• BABOK® Guide v3, section 10.17 Benchmarking, section 10.18 Brainstorming, section 10.25 Decision Analysis, section 10.33 Risk Analysis and Management, section 11.2 Define Solution Approach
• CBAP® Handbook, section 5. Review the Exam Blueprint
• Tips for Earning a Business Analysis Certification, section 4. Leverage a variety of study resources

 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

 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

Enterprise analysis is a knowledge area that describes the business analysis activities that take place for an enterprise to identify business opportunities, build a business architecture, determine the optimal project investment path for the enterprise and implement new business and technical solutions1. Enterprise analysis can be triggered by different need generation approaches, such as bottom-up, external drivers, middle management, or top-down2. In this case, the business need stems from external drivers, which are factors outside the organization that influence its performance, such as customers, competitors, regulations, or market trends3. A customer requesting new software for collecting customer information is an example of an external driver that creates a business need for the organization. The organization should conduct enterprise analysis to understand the customer’s requirements, assess the current capabilities and gaps, evaluate the feasibility and risks of the proposed solution, and define the business case and scope for the project. References:

• What is Enterprise Analysis: does it differ from Enterprise Architecture?
• [Enterprise Analysis - Business Analyst Training]
• [External Drivers: Definition & Examples - Video & Lesson Transcript | Study.com]

 User classes, profiles, or roles are model types that categorize and describe the people who directly interact with a solution. They help to identify the different types of users, their characteristics, needs, preferences, and behaviors. They also help to define the requirements, features, and functions that are relevant for each user group. User classes, profiles, or roles can be represented in various ways, such as personas, user stories, use cases, or user interface prototypes12. References:

• User Classes, Profiles, and Roles
• User Modeling: Definition, Methods, and Examples

 Requirements elicitation is not a business analysis planning and monitoring approach, but a business analysis task that involves identifying and documenting the needs andexpectations of stakeholders. Business analysis planning and monitoring is the knowledge area that covers the tasks of defining the business analysis approach, planning the business analysis activities, managing the business analysis performance, and communicating the business analysis information. The other three options are examples of techniques that can be used in business analysis planning and monitoring, such as structured walkthroughs for validating the business analysis approach, decision analysis for selecting the best solution option, and process modeling for defining the business analysis process. References: BABOK Guide, Business Analysis Planning and Monitoring, Requirements Elicitation and Collaboration

 Regulatory ranking is a type of requirements prioritization that involves ranking the requirements based on the compliance with laws and regulations in the industry. Regulatory ranking can help to ensure that the solution meets the legal and ethical standards and avoids penalties or lawsuits. Regulatory ranking can also help to align the solution with the organizational policies and objectives. Regulatory ranking is one of the factors that influence the requirement prioritization, as it reflects the penalty of not implementing a requirement. Regulatory ranking can be done by identifying the relevant laws and regulations for the solution, assessing the impact and likelihood of non-compliance, and assigning a priority level to each requirement123. References: 1: What AreRequirement Prioritization Techniques?1 2: Prioritizing Legal Requirements2 3: What Is Requirements Prioritization?3

Mitigation is not a category of risk tolerance, but rather a strategy for reducing the probability or impact of a risk. Risk tolerance refers to the degree of uncertainty that a stakeholder is willing to accept in relation to the achievement of the project or solution objectives. According to the BABOK® Guide1, there are three categories of risk tolerance associated with the stakeholders: risk-averse, risk-neutral, and risk-seeking. These categories are based on how much risk the stakeholders can tolerate and how they perceive the potential rewards of taking risks.

• Risk-averse stakeholders prefer to avoid risks or minimize their exposure. They tend to choose safer options that have lower returns but higher certainty. They may require more analysis and evidence before making decisions or approving requirements.
• Risk-neutral stakeholders are indifferent to risks and rewards. They base their decisions on the expected value of the outcomes, regardless of the uncertainty involved. They may accept higher risks if they are compensated by higher returns, or lower risks if they are accompanied by lower returns.
• Risk-seeking stakeholders prefer to take risks or maximize their exposure. They tend to choose riskier options that have higher returns but lower certainty. They may be willing to accept lower levels of analysis and evidence before making decisions or approving requirements.

References:

• CBAP® Handbook, page 6, section 4. Review the Exam Blueprint, under Requirements Analysis and Design Definition, task 5.1: Prioritize Requirements
• BABOK® Guide, page 33, section 4.2.1: Prioritize Requirements
• Risk Tolerance - Overview, Factors, and Types of Tolerance
• Applying stakeholder risk tolerance strategies in business

A plan-driven approach to business analysis follows a sequential and linear process, where each phase must be completed before moving on to the next. This approach requires thorough planning upfront, reducing uncertainties later on. Therefore, communication in a plan-driven approach is likely to be formal, structured, and documented. Formal communication ensures that information is relayed in a clear, consistent, and accurate manner, and that stakeholders are aware of their roles and responsibilities. Formal communication also helps to manage changes, risks, and issues that may arise during the project lifecycle. Formal communication may include written reports, presentations, meetings, emails, and memos. References:

• How to create a business analysis communication plan
• How to Choose the Right Business Analysis Approach
• Plan Business Analysis Approach - iiba.org
• Defining the Business Analysis Approach in 2023 | Free Template

The number of communication channels in a project is an indicator of the complexity of communication among the stakeholders. It is calculated by using the following formula1:

Number of communication channels = N x (N - 1) / 2

Where N = Number of stakeholders

In this case, N = 435, so the number of communication channels is:

435 x (435 - 1) / 2 = 188,790

Therefore, the correct answer is A. 188,790. References:

• Communication Channels in Project Management: Formula & Examples
• Number of Communication Channels (+ PMP® Formula & Calculator)

According to the BABOK Guide, textual requirements are one of the forms of specifying and modeling requirements. Textual requirements are written statements that describe the characteristics of the solution in a clear, concise, and consistent manner. Textual requirements typically consist of three components: the capability of the solution, the condition under which the requirement is applicable, and the constraint that may limit the solution. The capability describes what the solution must or should do, the condition describes the situation or scenario in which the requirement is relevant, and the constraint describes the restriction or limitation that may affect the solution’s ability to meet the requirement. For example, a textual requirement for a banking system could be:

The system shall allow customers to withdraw cash from any ATM machine (capability) within the network (condition) up to a maximum of $500 per day (constraint).

References:

• [A Guide to the Business Analysis Body of Knowledge (BABOK Guide)], version 3, page 402, section 10.31.2.11
• Textual Requirement Artifacts - Blueprint Online Help - HelpDocs, paragraph 1
• How to Model Textual Requirements - Formal Mind GmbH, paragraph 2

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

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.

 A requirements management plan is a business analysis plan that defines and describes the process to be followed in managing the solution scope and requirements. It includes the following items12:

• The requirements structure and traceability
• The requirements prioritization and approval process
• The requirements change control process
• The requirements communication and reporting process
• The requirements validation and verification process
• The requirements configuration management process
• The requirements reuse and disposal process

A requirements management plan is an important component of the business analysis plan, as it helps to ensure that the requirements are aligned with the business needs and objectives, and that they are delivered and maintained in a consistent and effective way. References:

• Requirements Management Plan - IIBA®
• Requirements Management Plan Template

 Verify scope is a process to determine the completeness of the project work and to gain the customer’s acceptance to move the project forward. Verify scope involves reviewing the deliverables and comparing them with the requirements and the scope baseline. It also involves obtaining the formal acceptance of the deliverables from the customer or sponsor. Verify scope helps to ensure that the project meets the expectations and needs of the customer or sponsor, and to avoid scope creep or rework12. Phase gate review is a process to evaluate the progress and performance of the project at predefined points or milestones. Phase gate review involves assessing the deliverables, risks, issues, and resources of the project against the criteria and objectives of each phase. It also involves deciding whether to continue, terminate, or modify the project. Phase gate review helps to ensure that the project is aligned with the business strategy and value, and to control the quality and scope of the project13. Inspection of key results is a process to measure and evaluate the quality and effectiveness of the project work and deliverables. Inspection of key results involves checking the work and deliverables for defects, errors, or deviations from the standards and specifications. It also involves identifying and implementing corrective actions to improve the quality and effectiveness of the work and deliverables. Inspection of key results helps to ensure that the project meets the quality requirements and standards, and to prevent or reduce the cost of poor quality14. Quality control is a process to monitor and control the quality of the project work and deliverables. Quality control involves performing quality audits, inspections, tests, and measurements to verify that the work and deliverables conform to the quality requirements and standards. It also involves identifying and implementing quality improvements to enhance the quality of the work and deliverables. Quality control helps to ensure that the project satisfies the customer or sponsor expectations and needs, and to increase the customer or sponsor satisfaction1 . References: CBAP® Handbook, CBAP® Exam Prep Study Guide, Project Management Institute, Inspection of Key Results - iiba.org, [Quality Control - iiba.org]

Prioritizing requirements is a process of determining the relative importance and urgency of the requirements based on the criteria and preferences of the stakeholders. Prioritizing requirements can help to allocate resources, manage scope, and resolve conflicts. One of the factors that can affect the prioritization of requirements is the dependency, which means that one requirement must be implemented before another requirement can be implemented. In this case, you are correct to move one of the requirements higher in the prioritization because it is needed to be implemented before some of the more important requirements are done. This way, you can ensure that the dependency is satisfied and that the project can deliver the expected value. Ralph is incorrect to rank the requirements based on their level of difficulty, as this is not a relevant criterion for prioritization. The level of difficulty can be considered in the estimation and planning of the project, but not in the prioritization of the requirements. References: BABOK Guide v3, page 52; CBAP / CCBA Certified Business Analysis Study Guide, page 160.

The future value of the requirements is not a factor that will help with the decision analysis approach to the requirements prioritization process. The future value of the requirements is the expected benefit or return that the requirements will provide in the longterm, which may depend on various assumptions and uncertainties. The future value of the requirements is not a reliable or objective criterion for comparing and selecting the best decision for the requirements outcome.

The other three factors are essential for the decision analysis approach to the requirements prioritization process. The values, goals, and objectives that are relevant to the requirements are the desired outcomes and criteria that the stakeholders want to achieve or satisfy with the solution. The consequences of each possible decision are the impacts and risks that each option will have on the organization and its stakeholders. The nature of the decision that must be made is the type and complexity of the decision, such as whether it is strategic, operational, or tactical, and whether it involves multiple alternatives, trade-offs, or uncertainties. These factors help the business analyst to evaluate and compare the options and to select the best one that maximizes the value and minimizes the risk of the solution. References:

• BABOK® Guide, p. 66-67
• CBAP / CCBA Certified Business Analysis Study Guide, p. 133
• Certified Business Analysis Professional™ (CBAP®) | Coursera, Course 1, Week 2, Video: “Business Analysis Planning and Monitoring”

Interface analysis is a technique of identifying and specifying the points of interaction between a solution and its external entities, such as other systems, devices, or users. Interface analysis can help to determine the interoperability of the software, the databases, and the web application by defining the requirements for the data exchange, communication, and integration among them. Interface analysis can also help to identify any potential issues, risks, or dependencies related to the interfaces. References: BABOK Guide v3, page 128; CBAP / CCBA Certified Business Analysis Study Guide, page 184.

A schedule variance report is a report that shows the difference between the planned and actual schedule of a project. It indicates whether the project is ahead of, on, or behind schedule, and by how much. It also identifies the causes of the schedule variance and the corrective actions needed to bring the project back on track. A status report is a report that provides an overview of the current state of the project, including the scope, schedule, cost, quality, risks, issues, and deliverables. A delay report is a report that documents the reasons for a delay in the project, the impact of the delay, and the mitigation strategies to minimize the delay. A cost variance report is a report that shows the difference between the planned and actual cost of a project. It indicates whether the project is under or over budget, and by how much. It also identifies the causes of the cost variance and the corrective actions needed to control the project cost. References: CBAP® Handbook, CBAP® Exam Prep Study Guide, Project Management Institute

Enterprise analysis is a knowledge area that covers the activities of identifying and defining business needs and opportunities, and determining feasible solutions to meet the organizational goals and objectives. Enterprise analysis includes the following tasks: define business need, assess capability gaps, determine solution approach, define solution scope, and define business case. Solution performance assessment is not a task of enterprise analysis, but rather a task of solution evaluation, which is another knowledge area that covers the activities of measuring and validating the value deliveredby a solution. References: BABOK Guide v3, page 25; CBAP / CCBA Certified Business Analysis Study Guide, page 69.

 Business goals and objectives are the desired outcomes that the organization wants to achieve through the project. They are not the same as the solution requirements, which describe the features and functions of the solution. Business goals and objectives are also not the same as the project scope, which describes the work that needs to be done to deliver the solution. Business goals and objectives are the ends, not the means, of the project. References:

• IIBA BABOK Guide, section 5.1.1, page 97
• CBAP/CCBA Study Guide, chapter 5, page 217

 Decision analysis is a technique of evaluating the possible outcomes of different alternatives and choosing the best one based on the criteria and preferences of the stakeholders. Decision analysis can be used to assess potential risks that may impact the solution and the cost and benefits associated with it, by using methods such as decision trees, decision tables, or expected value analysis. Decision analysis can help to select the optimal solution that maximizes the value and minimizes the risk for the organization. References: BABOK Guide v3, page 130; CBAP / CCBA Certified Business Analysis Study Guide, page 185.

 The project manager is the stakeholder who is responsible for assessing the solution scope to determine the project scope. The solution scope defines the features and functions of the product or service that will meet the business needs and requirements. The project scope defines the work that needs to be done to deliver the solution. The project manager is the person who plans, executes, monitors, and controls the project activities, and ensures that the project scope is aligned with the solution scope, the project objectives, and the stakeholder expectations. References: BABOK Guide v3, page 36; CBAP / CCBA Certified Business Analysis Study Guide, page 74.

Active observation is a technique of observing the behavior and activities of stakeholders while asking questions or participating in the work. Active observation can help to gain a deeper understanding of the work processes and environment of the stakeholders, as well as any issues or challenges they face. Active observation can also help to build rapport and trust with the stakeholders, and to elicit tacit or implicit knowledge that may not be easily expressed. In this case, Martha is using active observation by workingalongside Sarah and helping her complete the work, so that Martha can understand all of the steps Sarah must complete. References: BABOK Guide v3, page 97; CBAP / CCBA Certified Business Analysis Study Guide, page 163.

 A request for quote (RFQ) is a procurement form that asks the vendor to provide only a price for a standard or fixed product or service, such as a commercial-off-the-shelf (COTS) solution. An RFQ is used when the requirements are well-defined and there is no need for negotiation or customization. An RFQ is different from a request for proposal (RFP), which asks the vendor to provide a detailed proposal for a complex or customized product or service, including the price, schedule, approach, and qualifications. An RFQ is also different from a purchase order (PO), which is a formal document that authorizes the purchase of a product or service from a specific vendor. An RFQ is also different from a request for information (RFI), which asks the vendor to provide general information about their products or services, capabilities, or references, without asking for a price or a proposal. References: CBAP / CCBA Certified Business Analysis Study Guide, Chapter 9: Solution Assessment and Validation, page 275. Certified Business Analysis Professional (CBAP®) Handbook, page 6.

A class model is a technique to represent the structure and behavior of the entities within a solution domain. It shows the attributes, operations, and relationships of the classes that define the entities. A class is a category or type of entity that has common characteristics and can perform certain functions. A class model helps to identify the entities, their properties, their behaviors, and their interactions for a solution. Entity Relationship is a technique to represent the data and information requirements of a solution. It shows the entities, attributes, and relationships of the data and information. An entity is a thing or object of interest that can be uniquely identified and has attributes that describe its properties. An entity relationship model helps to identify the data and information, their characteristics, their associations, and their constraints for a solution. Data dictionary is a technique to define and document the data and information elements of a solution. It provides a detailed description of each data and information element, such as its name, definition, format, type, source, owner, and usage. A data dictionary helps to standardize and clarify the data and information, their meaning, their structure, and their quality for a solution. CRUD matrix is a technique to analyze the alignment of the data and information elements with the business processes or functions of a solution. It shows the data and information elements and the business processes or functions that create, read, update, or delete them. A CRUD matrix helps to identify the data and information, their lifecycle, their dependencies, and their gaps for a solution. References: Class Model - iiba.org, Entity Relationship - iiba.org, Data Dictionary - iiba.org, CRUD Matrix - iiba.org

GAP analysis is a technique that involves determining and documenting the variance between business requirements and current capabilities. GAP analysis helps to identify the gaps or discrepancies between the current state and the desired state of a system or a process. GAP analysis can also help to prioritize the requirements, define the scope, and plan the actions needed to close the gaps. GAP analysis is different from risk analysis, which is a technique that involves identifying, assessing, and managing the uncertainties and threats that may affect the project objectives. GAP analysis is also different from schedule analysis, which is a technique that involves estimating, monitoring, and controlling the time and resources needed to complete the project activities. GAP analysis is not a cost benefit analysis, which is a technique that involves comparing the costs and benefits of alternative solutions or courses of action. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 6: Enterprise Analysis, page 215-216.
• Business Capability Analysis: How to analyze capabilities, paragraph 3
• ProjectManagement.com - Variance Analysis, paragraph 1
• Which of the following techniques involves determining and documenting …, paragraph 1

 Data flow diagramming is a technique that shows how data moves through a system, from external entities, through processes, to data stores. Data flow diagrams can be used to model the current state or the desired state of a system, and to identify gaps or redundancies in data processing. Data flow diagrams can also be decomposed to lower levels of detail to show the sub-processes and data elements involved in each function. Functional decomposition, work decomposition, and organization modeling are different techniques that can be used to break down a system, a project, or an organization into smaller components, but they do not focus on the data movement. References:

• BABOK® Guide, p. 10, 98-99
• CBAP / CCBA Certified Business Analysis Study Guide, p. 240-241
• Certified Business Analysis Professional™ (CBAP®) | Coursera, Course 2, Week 2, Video: “Data Flow Diagrams”

 Informal communication is a type of communication that is spontaneous, casual, and unstructured. It can be useful for building rapport, trust, and collaboration among the business analysis team and the stakeholders. However, it can also pose some risks and challenges for the business analysis process. One of the dangers that Holly may experience with informal communication is that stakeholders may miss information and the requirements could become ambiguous. This is because informal communication is often not documented, verified, or validated. It may also lack clarity, consistency, and completeness. As a result, stakeholders may have different or conflicting understandings of the requirements, the solution scope, and other concerns. This can lead to errors, rework, delays, and dissatisfaction in the project. Therefore, Holly should balance informal communication with formal communication, which is a type of communication that is planned, structured, and documented. Formal communication can help to ensure the accuracy, quality, and traceability of the requirements and the solution. It can also help to communicate the roles, responsibilities, and expectations of the stakeholders and the business analyst. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 4: Elicitation and Collaboration, page 169-170.
• Formal & Informal Business Communication | Bizfluent, paragraph 3
• Analysis of Informal Communication Networks – A Case Study | Business …, paragraph 2
• 8.3 Glance at Genre: Informal and Formal Analytical Reports, paragraph 1

To compare the two solutions, we need to calculate the total cost of ownership (TCO) for each option over a given period of time. The TCO includes both the initial investment and the ongoing support costs. The formula for TCO is:

TCO=I+(S×T)

whereIis the initial investment,Sis the monthly support cost, andTis the number of months.

For the inhouse solution, the TCO is:

TCOinhouse​=65,000+(5,600×T)

For the vendor solution, the TCO is:

TCOvendor​=49,000+(6,100×T)

To find the breakeven point, we need to set the two TCOs equal to each other and solve forT:

65,000+(5,600×T)=49,000+(6,100×T)

Simplifying and rearranging, we get:

T=50016,000​=32

This means that the two solutions have the same TCO after 32 months. Therefore, the inhouse solution is cheaper if the solution is used for less than 32 months, and the vendor solution is cheaper if the solution is used for more than 32 months. Hence, the correct answer is A.References:BABOK® Guide, p. 97-98;Certified BusinessAnalysis Professional™ (CBAP®) | Coursera, Course 2, Week 3, Video: “Financial Analysis Techniques”

The conduct elicitation activity is a technique to understand stakeholder needs and identify potential solutions that may meet those needs. It involves guiding stakeholders and collaborating with them through the elicitation activity, doing research or running experiments, and capturing elicitation outcomes1. The inputs for this activity are the following2:

• Requirements management plan: This document defines how requirements will be elicited, analyzed, documented, validated, and managed throughout the project lifecycle. It provides guidance on the elicitation approach, techniques, roles, responsibilities, and deliverables.
• Business need: This is the problem or opportunity that the project intends to address. It provides the context and rationale for the elicitation activity and helps to define the scope and objectives of the project.
• Solution scope: This is the set of capabilities and features that a solution must deliver in order to meet the business need. It defines the boundaries and assumptions of the project and helps to identify the stakeholders and sources of information for the elicitation activity.
• Stakeholder list, roles, and responsibilities: This is the identification and description of the individuals and groups who have an interest or influence in the project. It defines their roles, responsibilities, expectations, and level of involvement in the elicitation activity.
• Business analysis information: This is the collection of information that has been gathered, analyzed, and documented during the business analysis process. It includes the business analysis plan, the business case, the current and future state descriptions, the requirements, the assumptions, the constraints, the risks, the issues, and the change requests. It provides the input and reference for the elicitation activity and helps to avoid duplication or inconsistency of information.
• Elicitation activity plan: This is the plan that describes the specific details of the elicitation activity, such as the purpose, scope, objectives, approach, techniques, participants, agenda, logistics, materials, and expected outcomes. It helps to prepare and organize the elicitation activity and ensure its alignment with the requirements management plan and the business analysis plan.

Documented elicitation results are not an input, but an output of the conduct elicitation activity. They are the records of the information that has been elicited from the stakeholders and other sources during the elicitation activity. They include notes, transcripts, recordings, models, diagrams, sketches, prototypes, surveys, questionnaires, and other artifacts that capture the stakeholder needs, expectations, preferences, assumptions, constraints, and feedback. They are used as an input for the confirm elicitation results activity, where they are checked for accuracy, completeness, and consistency. References: Conduct Elicitation - iiba.org, Exploring the CBAP Knowledge Areas - Institute i4

 Surveys are a conduct stakeholder analysis technique that is useful for identifying shared characteristics of a stakeholder group. Surveys are structured questionnaires that are distributed to a large number of stakeholders to collect quantitative and qualitative data about their needs, expectations, preferences, and opinions. Surveys can help to identify common patterns, trends, and themes among the stakeholder group, as well as to measure the level of agreement, satisfaction, or importance of the requirements. Surveys can also be used to segment the stakeholder group based on their characteristics, such as roles, responsibilities, interests, or influence.

Scope modeling, brainstorming, and interviews are other conduct stakeholder analysis techniques, but they are not as effective as surveys for identifying shared characteristics of a stakeholder group. Scope modeling is a technique that defines the boundaries and context of the business domain and the solution. Brainstorming is a technique that generates a large number of ideas or solutions in a creative and collaborative way. Interviews are a technique that involves one-on-one or group discussions with the stakeholders to elicit detailed information about their needs, expectations, preferences, and opinions. These techniques are more suitable for exploring the specific and individual characteristics of the stakeholders, rather than the general and collective ones. References:

• BABOK® Guide, p. 104-105, 377-378
• CBAP / CCBA Certified Business Analysis Study Guide, p. 49-50, 52
• Certified Business Analysis Professional™ (CBAP®) | Coursera, Course 1, Week 3, Video: “Stakeholder Analysis”

Dependencies between requirements are an important consideration to include in the assessment of the solution, as they may affect the delivery options and the value realization of the solution. Dependencies between requirements are the relationships or interconnections among the requirements that indicate that one requirement is contingent on another requirement. Dependencies may be logical, temporal, or resource-based. Dependencies may influence the order, timing, and feasibility of the solution delivery, as well as the benefits and risks associated with the solution. Therefore, the business analyst should identify, analyze, and manage the dependencies between requirements as part of the solution assessment.

Historical information, experience of the implementation team, and enterprise environmental factors are also relevant factors to consider in the solution assessment, but they are not as specific as dependencies between requirements. Historical information may provide insights into the past performance, lessons learned, and best practices of similar projects or solutions. Experience of the implementation team may affect the quality, efficiency, and effectiveness of the solution delivery. Enterprise environmental factors may include the organizational culture, structure, policies, processes, and systems that may influence the solution design and implementation. However, these factors are more general and may not directly relate to the tradeoffs between delivery options or the value realization of the solution. References:

• BABOK® Guide, p. 123-124, 128-129
• CBAP / CCBA Certified Business Analysis Study Guide, p. 299-300, 304-305
• Certified Business Analysis Professional™ (CBAP®) | Coursera, Course 2, Week 4, Video: “Assess Proposed Solution”

 According to the BABOK® Guide, a risk is “an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives such as scope, schedule, cost, and quality” (p. 10). A risk can have both positive and negative impacts, depending on the perspective of the stakeholders and the objectives of the solution. For example, a risk of adopting a new technology may be that it increases the productivity of the employees (positive) but also requires more training and maintenance (negative). A risk analysis in the business case should consider both the probability and the impact of the risks, as well as the strategies to mitigate or exploit them. References: BABOK®Guide, p. 10, 114-115; Certified Business Analysis Professional™ (CBAP®) | Coursera, Course 3, Week 2, Video: “Risk Analysis and Management”

Risky requirements are those that have a high probability of causing problems or failures in the project. By addressing them early in the prioritization, the project team can identify and resolve any issues before they affect the rest of the requirements or the projectdeliverables. This way, the project can avoid rework, delays, and cost overruns that may result from risky requirements. References: CBAP / CCBA Certified Business Analysis Study Guide, Chapter 6: Requirements Analysis, page 203. Certified Business Analysis Professional (CBAP®) Handbook, page 6.

 Work performance information is the input of Monitor and Control Risks that acquires information from performance measurements and evaluates it to provide variance analysis and forecasting. Work performance information includes information such as the status of deliverables, implementation status for change requests, and forecasted estimates to complete. This information helps the business analyst to monitor and control the risks associated with the project and the solution. References: BABOK® Guide, p. 116; Certified Business Analysis Professional™ (CBAP®) | Coursera, Course 3, Week 2, Video: “Risk Analysis and Management”

A control chart is a quality control chart that tracks trends in project execution by plotting the values of a quality metric over time against established control limits. A control chart can help the project team monitor the variation and stability of a process, identify the causes of variation, and take corrective actions if the process goes out of control. A control chart can also show the performance of a process in relation to the customer specifications and expectations. A control chart is different from a RACI chart, which shows the roles and responsibilities of project team members. A control chart is also different from a PERT chart, which shows the sequence and duration of project activities. A control chart isnot a Pareto chart, which shows the frequency and impact of problems or defects. References:

• Quality Control in Project Management, paragraph 6
• 15 Quality management tools in project management, paragraph 3
• Control Chart: A Key Tool for Ensuring Quality and Consistency, paragraph 1
• Control Chart - Project Management Knowledge, paragraph 1

Benchmarking is the process of comparing the performance or quality of a product, service, or process against a standard or best practice. Bob and Susan are benchmarking the materials by testing them and measuring the results to see how they compare to each other. This will help them select the best material for their project.

References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 6: Enterprise Analysis, page 217.
• BABOK® Guide, Version 3, Section 3.4: Strategy Analysis, page 50.

 Voting is a technique of requirements prioritization that involves asking the stakeholders to express their preferences for the requirements using various methods, such as ranking, rating, or allocating points or money. Voting helps to achieve consensus and alignment among the stakeholders and to identify the most important and valuable requirements. In this scenario, the business analyst is using a voting method that assigns play money to the requirements, which reflects the relative importance and benefit of each requirement. The requirements with the highest amount of play money are prioritized over the ones with lower amounts.

References:

• BABOK® Guide, p. 55, 376-377
• CBAP / CCBA Certified Business Analysis Study Guide, p. 165-166
• Certified Business Analysis Professional™ (CBAP®) | Coursera, Course 2, Week 1, Video: “Requirements Prioritization”

A current state domain model is a visual representation of the existing business domain, including the entities, attributes, relationships, and rules that define the current situation. A current state domain model can help identify opportunities for improvement by highlighting the gaps, issues, or inefficiencies in the current domain. A current state domain model can also help validate the solution scope with business and technical stakeholders by providing a common understanding of the current domain and its boundaries. A current state domain model can also help assist stakeholders in understanding the current state by showing the structure and logic of the current domain in a simple and clear way. However, a current state domain model cannot help the business analyst create Pareto charts for process improvement, as Pareto charts are a different type of analysis tool that show the frequency and impact of different types of problems or causes. Pareto charts are not based on the current state domain model, but rather on the data collected from the current processes or activities. References: BABOK Guide v3, page 123; CBAP / CCBA Certified Business Analysis Study Guide, page 181.

A horizontal prototype is a type of prototype that focuses on the user interface and the look and feel of the system, without much attention to the functionality or the back-end processes. It is useful for demonstrating the appearance and navigation of the system to the customer and getting feedback on the design. A horizontal prototype is also called a mock-up prototype or a storyboard prototype.

References:

• Certified Business Analysis Professional Handbook, page 19
• Certified Business Analysis Professional Specialization, Course 4, Week 3, Lesson 3.1
• CBAP / CCBA Certified Business Analysis Study Guide, page 261

An independent task is a task that does not rely on other activities, and no other activities rely on this task completing. An independent task can be performed at any time during the project, as long as it meets the project objectives and requirements. An independent task has no dependencies or constraints with other tasks. An analysis task is a task that involves examining, evaluating, and interpreting information to identify and understand the problem, need, or opportunity. An analysis task may rely on other activities, such as elicitation, documentation, or validation, and other activities may rely on this task completing, such as design, development, or testing. An analysis task may have dependencies or constraints with other tasks. A predecessor task is a task that must be completed before another task can start or finish. A predecessor task has a logical or sequential relationship with another task, which is called a successor task. A predecessor task may affect the start or end date, duration, or resources of the successor task. A dependent task is a task that relies on another task to start or finish. A dependent task has a logical or sequential relationship with another task, which is called a predecessor task. A dependent task may be affected by the start or end date, duration, or resources of the predecessor task. References: CBAP® Handbook, CBAP® Exam Prep Study Guide, Project Management Institute

Creative thinking is a type of analytical thinking that involves generating new ideas and innovative concepts to approach problems, solve problems, and generate alternative solutions. Creative thinking helps the business analyst to find novel and original ways to address the needs and expectations of the stakeholders, overcome the challenges and constraints of the project, and add value to the solution. Creative thinking also helps the business analyst to explore different perspectives, challenge assumptions, and experiment with different possibilities. The other options are not types of analytical thinking, but rather techniques or skills that can be used to enhance creative thinking. Lateral thinking is a technique that involves using logic and reasoning to find unconventional or unexpected solutions. Brainstorming is a technique that involves generating a large number of ideas in a group setting. Decision making is a skill that involves choosing the best option among several alternatives based on criteria and evidence. References:

• 9.1 Analytical Thinking and Problem Solving, paragraph 1
• Top 11 Most Effective Business Analysis Techniques | 2024, paragraph 2
• 6 business analysis techniques to use in your strategic plans, paragraph 2
• What is analytical thinking ? – The Functional BA, paragraph 2
• Business Analysis Blog | Systems Thinking – An Analyst’s Essential …, paragraph 2

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 is the most impacted element by the organization’s change from a waterfall methodology to an agile approach. This is because the waterfall and agile methods have different ways of planning, executing, and delivering business analysis work.

In a waterfall method, the business analysis work is done in a sequential and linear manner, following predefined phases and milestones. The requirements are elicited, analyzed, and documented upfront, before the design and development stages. The changes to the requirements are minimized and controlled, and the deliverables are verified and validated at the end of the project. The timing of business analysis work is fixed and predictable, but it may also be rigid and inflexible.

In an agile method, the business analysis work is done in an iterative and incremental manner, following short cycles of development and feedback. The requirements are elicited, analyzed, and documented continuously, along with the design and development stages. The changes to the requirements are welcomed and managed, and the deliverables are verified and validated throughout the project. The timing of business analysis work is variable and adaptable, but it may also be challenging and uncertain.

Therefore, the business analyst (BA) needs to adjust the timing of business analysis work according to the agile method, which involves:

• Breaking down the requirements into smaller and manageable chunks, called user stories or features, that can be delivered in each iteration or sprint
• Prioritizing and refining the requirements backlog, which is the list of all the requirements that need to be addressed in the project, based on the business value and stakeholder feedback
• Collaborating and communicating with the project team and stakeholders frequently and effectively, using various techniques and tools, such as daily stand-ups, retrospectives, demos, etc.
• Adapting and responding to the changing requirements and business needs, using various techniques and tools, such as change requests, impact analysis, traceability, etc.

References:

• [BABOK Guide v3], Section 2.4: Plan Business Analysis Work, p. 24-27
• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 2: Business Analysis Planning and Monitoring, p. 43-44
• Certified Business Analysis Professional™ (CBAP®) Specialization, Course 1: Business Analysis: Planning and Monitoring, Week 1: Introduction to Business Analysis Planning and Monitoring, Video: Waterfall vs. Agile
• Agile vs. Waterfall | Pros, Cons, and Key Differences - ProductPlan

The BA needs to perform a root cause analysis to analyze the performance of the application and provide recommendations. A root cause analysis is a technique that involves identifying and addressing the underlying causes of a problem or an issue, rather than the symptoms or the effects. A root cause analysis can help the BA to find out why the solution implemented three months ago has decreased performance as the volume of transactions has increased, and to propose and implement appropriate solutions to improve the performance and prevent the problem from recurring. The other options are not the best actions for the BA to take, as they are more suitable for different purposes, such as measuring the performance, evaluating the alternatives, or reviewing the existing metrics, rather than finding the root cause of the problem. References: Task: Assessing Solution Limitations, CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, BABOK Guide

Lessons learned is a technique that involves identifying and documenting the knowledge gained from a project or an activity, and sharing it with relevant stakeholders. Lessons learned can include the successes, failures, best practices, and improvement opportunities that occurred during or after the project or activity. Lessons learned can help the BA to understand the stakeholders’ level of satisfaction, to offer them an opportunity to help improve the working relationships, and to apply the learned knowledge to future projects or activities. The other options are not the best techniques for this purpose, as they are more focused on identifying and managing risks, generating and evaluating ideas, or engaging stakeholders in a fun and creative way. References: CBAP Handbook, CBAP Study Guide, BABOK Guide

According to the CBAP competencies, one of the skills required for business analysis planning and monitoring is to guide practice in performing stakeholder analysis1. Stakeholder analysis is the process of identifying and assessing the needs, interests, and influence of stakeholders on a project or initiative2. One of the outputs of stakeholder analysis is a stakeholder list, which identifies the key stakeholders and their roles, responsibilities, and expectations3. A stakeholder list can also include information on the potential risks and issues that may arise from stakeholder involvement or lack thereof4. Therefore, developing a risk plan to anticipate negative behavior from the Director of Human Resources is a valid activity that is included in performing a stakeholder analysis. This can help the team to mitigate the impact of the Director’s bitterness and resistance on the project’s success.

The other options are not included in performing a stakeholder analysis. Comparing the expertise of the Director of Human Resources to other stakeholders is not relevant to the stakeholder analysis process, as it does not help to understand the Director’s needs, interests, or influence. Recommending excluding the Director of Human Resources as a stakeholder is not a good practice, as it may create more conflict and resentment, and ignore the Director’s legitimate role and authority in the project. Implementing all of the Director of Human Resources suggestions to relieve tension is not a realistic or effective strategy, as it may compromise the quality and feasibility of the project, and disregard the needs and interests of other stakeholders. References:

• 1: CBAP Competencies - International Institute of Business Analysis
• 2: BABOK Guide v3, Section 2.2.2: Conduct Stakeholder Analysis
• 3: BABOK Guide v3, Section 2.2.2.3: Outputs
• 4: CBAP / CCBA Certified Business Analysis Study Guide, Chapter 3: Business Analysis Planning and Monitoring, p. 83

The missing stakeholder is a risk that can affect the quality and validity of the requirements, as well as the delivery and acceptance of the solution. The BA should identify this risk and its potential impact on the project, and recommend an adaptive approach for the analysis phase. An adaptive approach is one that allows for flexibility and responsiveness to changing requirements and stakeholder needs. An adaptive approach can help the BA to cope with the uncertainty and complexity of the project, and to deliver value incrementally and iteratively. The other options are not the best actions for the BA to proceed, as they may compromise the scope, schedule, cost, or contract terms of the project, and may not address the root cause of the risk. References: CBAP Handbook, CBAP Study Guide, BABOK Guide

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

The CEO’s executive decision to start and complete the top 25 revenue-producing stores in the first year shows a risk-seeking or risk-taking attitude. This means that the CEO is willing to accept higher risks for higher rewards, and sees risks as opportunities rather than threats. The CEO is not avoiding, mitigating, or neutral to the risks involved in the remodeling project, but rather embracing them and pursuing them aggressively. This may result in increased revenue and customer satisfaction, but also exposes the organization to potential losses and disruptions. References:

• Risk Attitude in Project Management: Definition, Types & Example, Web Article, August 2022
• Risk Appetite vs. Risk Tolerance: What is the Difference?, Web Article, October 2022
• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 3: Strategy Analysis, p. 95-96
• Certified Business Analysis Professional™ (CBAP®) Specialization, Course 3: Business Analysis: Strategy Analysis, Week 1: Strategy Analysis Overview, Video: Risk Analysis

The relationship type that correctly identifies the nature of the relationship between the 3 business capabilities and the 11 requirements is derives. Derives is a relationship type that indicates that a lower-level element is derived from a higher-level element that provides the context or rationale for the lower-level element. In this case, the 11 requirements are lower-level elements that are derived from the 3 business capabilities (I, II, and III) that provide the scope and purpose for the requirements. Therefore, each requirement derives a corresponding capability by providing more detail on how the capability will be implemented and tested. References:

• BABOK Guide v3, Section 9.2: Requirements Classification Schema, p. 336-337
• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 6: Requirements Analysis and Design Definition, p. 216-217
• Certified Business Analysis Professional™ (CBAP®) Specialization, Course 2: Business Analysis: Requirements Elicitation and Analysis, Week 3: Requirements Classification, Video: Requirements Relationships

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

 Business architecture is the description of how an organization creates, delivers, and captures value for its stakeholders. It includes the business model, the value proposition, the value streams, the capabilities, and the organizational structure of the organization. By evaluating the business architecture, the BA can help determine the value of the project in relation to the current state and the desired future state of the organization. The BA can also identify the gaps and opportunities for improvement that the project can address. References:

• IIBA BABOK Guide v3, Section 2.2.1: Business Architecture
• [IIBA Business Analysis Competency Model], Section 3.1.1: Business Architecture Knowledge

 A data dictionary is a technique that is used to define the data elements of a system or a domain. It provides detailed information about the attributes of each data element, such as name, description, type, format, length, range, default value, validation rules, relationships, and constraints. A data dictionary helps to ensure a common understanding of the data elements among the stakeholders and to maintain consistency and accuracy in the data usage and manipulation. A data dictionary can be used to complement a class diagram, which is a graphical representation of the classes and their associations in an object-oriented system or domain. 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 Dictionary, p. 332-335.
• Business Analysis for Practitioners: A Practice Guide, Chapter 5: Requirements Analysis and Design Definition, p. 123-124, 129-130.

The risk associated with Requirement ID F-P0001 is HIGH because if the assumption is that the system will be inaccessible in remote locations, it directly impacts the core objective of having a web-based system for reporting company finances internationally. Inaccessibility in remote locations would mean that the Crew Chiefs, who are presumably located at various international job sites, would not be able to report project status effectively. This could lead to significant delays and inefficiencies, making this assumption a high-risk factor. References: The answer can be inferred from general knowledge on business analysis and risk assessment principles as specific references from CBAP documents are not provided here.

Interface analysis is a technique that identifies and specifies the information that is exchanged between systems or system components. It defines the communications protocol, data format, and timing of the information exchange. Interface analysis is useful for designing and documenting the interactions between the PS and other systems. It can also help to identify potential issues or risks related to the integration of the systems.

Vertical prototyping is a technique that creates a working model of one or more aspects of a solution, such as the user interface, functionality, or performance. It is used to validate the requirements and design of the solution, and to obtain feedback from stakeholders. It is not directly related to defining the communications protocol between the systems.

Concept modelling is a technique that defines the terms and concepts relevant to a domain or a problem. It establishes a common vocabulary and understanding of the domain among the stakeholders. It is not focused on the technical details of the system interactions.

System analysis is a broad term that refers to the process of studying and understanding the current or desired state of a system. It involves identifying the system components, functions, inputs, outputs, and relationships. It is not a specific technique for defining the communications protocol between the systems. References:

• [A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 3], Chapter 10: Techniques, pp. 402-403, 414-415, 420-421, 424-425.
• [Business Analysis for Practitioners: A Practice Guide], Chapter 5: Requirements Analysis and Design Definition, pp. 123-124, 133-134, 140-141, 144-145.

A capability-centric view is a type of view that analyzes the current state of an organization based on its capabilities, which are the abilities and skills that enable the organization to achieve its goals and objectives. A capability-centric view helps to identify the strengths and weaknesses of the organization, as well as the opportunities and threats in the external environment. By proposing a change that leverages the existing capabilities of the organization, such as manufacturing vending machines, and adapts them to a new market segment, such as mobile device users, the BA used a capability-centric view to analyze the current manufacturer’s state.

The other options are not correct because they do not match the type of view that the BA used. A data-centric view is a type of view that analyzes the current state of an organization based on its data, which are the facts and information that support the organization’s operations and decision-making. A data-centric view helps to identify the sources, quality, and usage of data, as well as the data requirements and gaps. A process-centric view is a type of view that analyzes the current state of an organization based on its processes, which are the activities and tasks that transform inputs into outputs. A process-centric view helps to identify the inputs, outputs, resources, and performance of processes, as well as the process improvements and optimizations. A people-centric view is a type of view that analyzes the current state of an organization based on its people, which are the stakeholders who are involved in or affected by the organization’s activities and outcomes. A people-centric view helps to identify the roles, responsibilities, relationships, and needs of the people, as well as the people management and engagement strategies.

References:

• [BABOK Guide v3], Section 6.1: Analyze Current State, p. 158-159
• Certified Business Analysis Professional™ (CBAP®) Specialization, Course 3: Business Analysis: Strategy Analysis, Week 1: Strategy Analysis, Video: Current State Analysis
• What is Strategic Analysis? 8 Best Strategic Analysis Tools + Examples, Blog Post, July 2023

 The BA failed to consider the informal relationships that exist among the stakeholders, such as the communication channels, the influence networks, the power dynamics, and the cultural norms that may affect the acceptance and adoption of the solution. Informal relationships are often not reflected in the formal organizational structure, but they can have a significant impact on the behavior and performance of the stakeholders. The BA should have identified and analyzed the informal relationships as part of the stakeholder analysis and change management activities, and should have designed the solution to accommodate or leverage them. References: CBAP Handbook, CBAP Study Guide, BABOK Guide

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

 The BA could have assessed the current state and stakeholder needs to prevent this situation. The current state is the description of the existing situation, including the problems, opportunities, capabilities, and constraints of the organization and its stakeholders. The stakeholder needs are the expectations, preferences, and requirements of the stakeholders that are relevant to the change initiative. By assessing the current state and stakeholder needs, the BA could have identified and documented the existing report “Consolidated Sales by Customer” as a requirement, and ensured that it was not affected or replaced by the new report “Customer Sales by Date”. The BA could have also verified and validated that the new report met the stakeholder needs and did not cause any negative impacts or trade-offs. The other options are not the best answers, as they are more related to the evaluation of the solution or the organization, rather than the identification and management of the requirements. References: CBAP Handbook, CBAP Study Guide, BABOK Guide

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

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.

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.

Option D shows the correct use of the extend relationship between the two use cases. This means that the “Send notification” use case is an optional extension of the “Setup new supervisor” use case, and it only occurs under certain conditions. The arrow points from the base use case (“Setup new supervisor”) to the extension use case (“Send notification”), as per the UML notation. Option C is incorrect because it reverses the direction of the arrow, implying that the “Send notification” use case is the base use case and the “Setup new supervisor” use case is the extension use case, which does not make sense. Options A and B are incorrect because they use the include relationship, which means that the “Send notification” use case is a mandatory part of the “Setup new supervisor” use case, and it always occurs whenever the “Setup new supervisor” use case is executed. This does not reflect the requirement that the notifications are sent only under specific conditions. 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.

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]

Business Analysis Governance is the set of processes, rules, and decision-making rights that define how business analysis work is performed and how business analysis deliverables are approved and managed. It also defines the roles and responsibilities of the business analysis stakeholders and how they collaborate and communicate. In a predictive approach, change requests are usually subject to formal approval and impact analysis, which can be time-consuming and burdensome for the project manager. The business analyst could propose to revisit the Business Analysis Governance approach and suggest ways to streamline or simplify the change management process, such as delegating some approval authority, prioritizing or grouping change requests, or adopting a more adaptive approach that allows for more flexibility and feedback. References: CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 2: Business Analysis Planning and Monitoring, p. 59-60; BABOK Guide v3, Chapter 2: Business Analysis Planning and Monitoring, Section 2.5: Plan Business Analysis Governance, p. 40-41.

• future state will
• be defined at a level of detail that:
• • allows for competing strategies to achieve the future state to be identified
• and assessed,
• • provides a clear definition of the outcomes that will satisfy the business
• needs,
• • details the scope of the solution space,
• • allows for value associated with the future state to be assessed, and
• • enables consensus to be achieved among key stakeholders.
• A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 3, Chapter 5: Strategy Analysis, p. 176-177; Chapter 10: Root Cause Analysis, p. 356-359.
• Business Analysis for Practitioners: A Practice Guide, Chapter 5: Requirements Analysis and Design Definition, p. 122-123, 129-130.

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

 The BA is performing an enterprise assessment, which is the process of evaluating the current state and capabilities of the enterprise in relation to the desired future state and the proposed solution. An enterprise assessment can include reviewing the existing processes, tools, systems, culture, structure, and strategy of the enterprise, and identifying their strengths, weaknesses, opportunities, and threats. An enterprise assessment can help the BA to determine the feasibility, readiness, and risks of adopting a potential solution, and to recommend the appropriate change strategy and transition plan. The other options are not the best answers, as they are more specific types of assessments that focus on a particular aspect of the enterprise, such as the stakeholders, the organization, or the operations. References: CBAP Handbook, CBAP Study Guide, BABOK Guide

A high level of abstraction means that the requirements are expressed in general terms, without specifying details or implementation methods. This allows the requirements to be more flexible and adaptable to changing business needs and contexts. For the seasonal products, which are likely to be different every year and require major variations in some business processes, using a high level of abstraction would help to manage the requirements in the long term, as they would not need to be revised or updated frequently. On the other hand, using a low level of abstraction, which means that the requirements are expressed in specific and detailed terms, would make the requirements more rigid and prone to changes, as they would need to be aligned with the particular characteristics and constraints of each seasonal product and process variation.

References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 3: Requirements Elicitation, p. 97-98
• [BABOK Guide v3], Section 4.1: Prepare for Elicitation, p. 94-95
• Certified Business Analysis Professional™ (CBAP®) Specialization, Course 2: Business Analysis: Requirements Analysis and Design Definition, Week 2: Requirements Classification and Prioritization, Video: Requirements Abstraction Levels

 Quantitative and qualitative data are two types of data that can help the end users evaluate the effectiveness of a solution. Quantitative data are numerical, measurable, and objective, such as cost, time, scope, quality, and customer satisfaction. Qualitative data are descriptive, subjective, and interpretive, such as feedback, opinions, perceptions, and experiences. By using both types of data, the end users can assess the solution from different perspectives and dimensions, and compare the results with the predefined success criteria for the initiative. References:

• Project Success Criteria Guide, Smartsheet
• 7 Project Success Criteria Examples, Indeed.com
• IIBA BABOK Guide, Section 5.4, Evaluate Solution Performance

The BA should use the Allocate Requirements technique to assign requirements to the various solution components to ensure all objectives are met. This technique involves distributing stakeholder and solution requirements among solution components and releases in order to maximize the possible business value given the options and alternatives generated by the design team. The BA should consider the dependencies, constraints, priorities, and risks of each requirement and component, and ensure that the allocation is traceable, verifiable, and consistent with the project scope and objectives. References:

• IIBA BABOK Guide, Section 7.2, Allocate Requirements
• Oh Where, Oh Where Does This Requirement Belong? (BABOK 7.2), Bridging the Gap
• Requirements Allocation, AcqNotes

This question is based on a case study that compares four scenarios for implementing a new system for a bank. The case study provides the following information about the duration of each scenario:

• Scenario 1: 6 months
• Scenario 2: 9 months
• Scenario 3: 10 months
• Scenario 4: 7 months

The question asks for the time difference in days between the shortest and longest implementation. The shortest implementation is Scenario 1, which is 6 months or 180 days. The longest implementation is Scenario 3, which is 10 months or 300 days. Therefore, the time difference in days is 300 - 180 = 120 days. References: The case study is available in the CBAP® Exam Sample Questions and Exam Blueprint document1. The answer is also verified by the CBAP® Exam Answer Key document2. Both documents are accessible from the IIBA® website3.

Based on the table in the image, the total cost for each company over the three years can be calculated by adding the Year 0 license costs, Years 1 and 2 total license costs, and implementation costs. For Company A, the total cost is $323,458 (Year 0) + $270,092 (Years 1 and 2) + $28,500 (Phase Ia) + $55,000 (Phase Ib) + $121,500 (Phase 2) = $798,550. For Company B, it’s $373,555 (Year 0) + $202,056 (Years 1 and 2) + ($1.500 150 days of implementation)= $578611 which is less than the insurance company’s maximum budget of $310000. For Company C it’s = ($400244+$214096+($31.50159))= $695439 which exceeds the budget. References: The answer is derived from a direct calculation based on the provided information in the image and does not reference specific CBAP learning documents or resources.

 A risk-averse organization is one that prefers to minimize or eliminate the exposure to risks, even if it means sacrificing some potential benefits or opportunities. A risk avoidance strategy is one that involves changing the project plan, scope, schedule, or budget to avoid the risk or its impact. A risk avoidance strategy is suitable for a risk-averse organization, as it reduces the uncertainty and the potential negative consequences of the risk. In this scenario, the BA has identified an assumption that has a high degree of uncertainty and may affect the validity of the requirements. The BA has added the assumption to the risk register and performed a risk analysis to handle this situation. If the organization is risk-averse, the BA may use a risk avoidance strategy to modify the requirements or the solution design to eliminate the dependency on the assumption, or to seek more information or evidence to validate the assumption. A risk acceptance strategy is one that involves acknowledging the risk and its impact, but not taking any action to prevent or reduce it. A risk acceptance strategy is suitable for a risk-seeking or risk-neutral organization, or for risks that have low probability or impact. A risk transfer strategy is one that involves shifting the responsibility or ownership of the risk or its impact to a third party, such as a vendor, a partner, or an insurer. A risk transfer strategy is suitable for risks that have high impact but low probability, or for risks that require specialized skills or resources to manage. A risk mitigation strategy is one that involves taking actions to reduce the probability or impact of the risk, such as implementing contingency plans, preventive measures, or backup solutions. A risk mitigation strategy is suitable for risks that have high probability and impact, or for risks that can be controlled or influenced by the project team. References: BABOK Guide v3, Chapter 10: Techniques, Section 10.51: Risk Analysis and Management, p. 567-569; Free CBAP IIBA Actual Exam Questions & Answers, Question 467.

 The requirement ‘’Ability to view policies created in the legacy system for a period of 6 months’’ is a transition requirement. A transition requirement is a temporary requirement that specifies the capabilities or conditions that the solution must have or meet during the transition from the current state to the future state. Transition requirements are typically related to data conversion, training, migration, or decommissioning. In this case, the requirement is needed to ensure that the policies created in the legacy system are still accessible for a limited time after the system is decommissioned, until the new system is fully operational and stable. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 2: Business Analysis Key Concepts, Section 2.4: Requirements Classification Schema, p. 66-67
• A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 2: Business Analysis Key Concepts, Section 2.4: Requirements Classification Schema, p. 34-35

As part of identifying enterprise limitations, the BA should perform a stakeholder impact and operational analysis. This technique involves assessing how the proposed change will affect the stakeholders and the current operations of the enterprise. It can help to identify the potential benefits, costs, risks, and issues of the change, as well as the readiness and resistance of the stakeholders. The BA should consider the impact of the change on the following aspects of the enterprise:

• Strategy and goals
• Processes and policies
• Structure and roles
• Culture and values
• Systems and technology
• Performance and quality

In this case, the BA should analyze how the merger proposal will impact the stakeholders and operations of Manufacturer O, especially in the scenario of Manufacturer K moving headquarters and closing the current Manufacturer O site. The BA should also consider the impact of the regulatory environment and the potential changes in the future. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 5: Strategy Analysis, Section 5.1: Analyze Current State, p. 207-208
• A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 5: Strategy Analysis, Section 5.1: Analyze Current State, p. 107-108
• A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 10: Solution Evaluation, Section 10.5: Assess Organizational Readiness, p. 281-282

The BA should approach the solution limitation by assessing the impact on the business operations. This means that the BA should analyze how the inability to meet the SLA in one out of five scenarios would affect the business goals, objectives, performance, value, and risks. The BA should also consider the frequency, severity, and likelihood of the scenarios, and the expectations and needs of the stakeholders. Based on the impact assessment, the BA can then recommend the best course of action, such as modifying the SLA, changing the business process, increasing the scope, or deferring the requirement to a future release. The other options are not the best approaches, as they may either be unrealistic, unnecessary, or ineffective without a proper impact assessment. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 7: Solution Evaluation, Section 7.2: Analyze Performance Measures, p. 311-312
• A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 7: Solution Evaluation, Section 7.2: Analyze Performance Measures, p. 269-270

Decision analysis is a technique that helps the BA evaluate and compare different alternatives based on their costs, benefits, and risks, and select the best option that meets the objectives and criteria. In this case, the BA needs to determine if one of the systems (Sys A or Sys B) is better suited to be modified and upgraded, based on the upgrade cost and cost new of each feature. The BA can use the table in the image to calculate the total cost of upgrading or creating new features for each system, and compare them with the expected value and return on investment of each system. The BA can also consider other factors, such as the feasibility, compatibility, reliability, and maintainability of each system, and the preferences and expectations of the stakeholders. By using decision analysis, the BA can make an informed and rational choice that maximizes the value and minimizes the risk of the solution. References:

• IIBA BABOK Guide, Section 10.23, Decision Analysis
• Decision Analysis for the Professional, SmartOrg
• Decision Analysis: Making Justifiable, Defensible Decisions, MindTools

 The method that the BA should use so the stakeholders can review the document before final approval is e-mail. E-mail is a communication technique that allows the BA to send and receive messages and documents electronically. E-mail can be used to share information, elicit feedback, confirm agreements, and document decisions. E-mail is suitable for situations where the stakeholders are geographically dispersed, have different time zones, or have limited availability for meetings. E-mail can also provide a record of the communication and the review process. References:

• CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 4: Elicitation and Collaboration, Section 4.3: Communicate Business Analysis Information, p. 175-176
• A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 4: Elicitation and Collaboration, Section 4.4: Manage Stakeholder Collaboration, p. 118-119