CBAP Questions and Answers

 The information management approach is a document that describes how the business analysis information will be stored, accessed, distributed, and maintained throughout the project. It includes the details of the tools, formats, standards, and processes for managing the information. The BA will update the information management approach to reflect the changes in how the user stories will be organized and made more accessible for the next sprint. This will help to ensure that the information is consistent, accurate, and available for the stakeholders. References:

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 3: Business Analysis Planning and Monitoring, Section 3.4: Plan Business Analysis Information Management, p. 101-102

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 3: Business Analysis Planning and Monitoring, Section 3.4: Plan Business Analysis Information Management, p. 64-65

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

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 6: Requirements Analysis and Design Definition, Section 6.4: Model and Validate Requirements, p. 265-266

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 6: Requirements Analysis and Design Definition, Section 6.4: Model Requirements, p. 161-162

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 10: Solution Evaluation, Section 10.6: Validate Solution, p. 283-284

Rough order of magnitude (ROM) cost estimating is a process of estimating the costs of the proposed solutions with a high level of uncertainty, usually in the range of -25% to +75%. ROM cost estimating is used to compare the feasibility and affordability of different solutions and to support decision making. ROM cost estimating is not a detailed or accurate process, but rather a quick and approximate way of assessing the costs of the solutions. References: CBAP / CCBA Certified Business Analysis Study Guide, Chapter 6: Requirements Analysis, page 202. Certified Business Analysis Professional (CBAP®) Handbook, page 6.

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)

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”

The waterfall software development life cycle is a methodology that divides the project into phases, and the project manager focuses on control of time, cost, and scope. The waterfall model is a linear and sequential approach that follows a predefined set of steps from the initiation to the closure of the project. The waterfall model assumes that the requirements, scope, and design of the project are clear and stable, and that each phase can be completed before moving to the next one. The waterfall model helps to ensure that the project deliverables meet the quality standards and specifications, and that the project is completed within the budget and schedule12. The spiral software development life cycle is a methodology that combines the iterative and incremental approach with the risk management and prototyping techniques. The spiral model is a cyclical and evolutionary approach that follows a series of loops or iterations from the planning to the deployment of the project. The spiral model assumes that the requirements, scope, and design of the project are dynamic and complex, and that each iteration can be refined and improved based on the feedback and learning from the previous ones. The spiral model helps to identify and mitigate the risks and uncertainties of the project, and to deliver a functional and adaptable product13. The agile software development life cycle is a methodology that emphasizes the collaboration, communication, and flexibility among the project stakeholders. The agile model is an adaptive and iterative approach that follows a series of short and frequent cycles or sprints from the conception to the delivery of the project. The agile model assumes that the requirements, scope, and design of the project are emergent and changing, and that each sprint can deliver a working and valuable product increment. The agile model helps to respond to the changes and feedback of the project, and to maximize the customer satisfaction and value14. The incremental software development life cycle is a methodology that breaks down the project into smaller and manageable chunks or modules. The incremental model is a progressive and modular approach that follows a series of steps from the analysis to the implementation of each module of the project. The incremental model assumes that the requirements, scope, and design of the project are partially known and defined, and that each module can be developed and delivered independently. The incremental model helps to reduce the complexity and risk of the project, and to provide a gradual and continuous delivery of the product15. References:

CBAP® Handbook

Waterfall Model - iiba.org

Spiral Model - iiba.org

Agile Model - iiba.org

Incremental Model - iiba.org

The Delphi technique is a type of requirements elicitation technique that is based on a survey method. The Delphi technique involves sending a series of questionnaires to a group of experts who have knowledge or experience in the domain of the project or the solution. The questionnaires are designed to elicit opinions, ideas, or feedback on the requirements or the issues related to the project or the solution. The responses from the experts are collected and analyzed by a facilitator, who then provides a summary of the results and the areas of agreement or disagreement to the experts. The facilitator also prepares a new questionnaire based on the feedback and sends it back to the experts for another round of responses. This process is repeated until a consensus is reached or a sufficient level of information is obtained. The Delphi technique is useful for gathering requirements from a large and diverse group of stakeholders who are geographically dispersed or have conflicting views. The Delphi technique also helps to reduce the influence of dominant or biased individuals and to encourage honest and independent opinions. The Delphi technique is different from a workshop, which is a type of requirements elicitation technique that involves bringing together a group of stakeholders in a face-to-face or virtual setting to collaborate and exchange information on the requirements or the issues related to the project or the solution. The workshop is facilitated by a moderator, who guides the discussion and ensures the participation and contribution of all the attendees. The workshop is useful for generating a large number of ideas and finding solutions for a specific problem in a short time. The workshop also helps to build rapport and trust among the stakeholders and to resolve conflicts or misunderstandings. The Delphi technique is also different from a round table, which is a type of requirements elicitation technique that involves inviting a group of stakeholders to a formal or informal meeting to share their perspectives and insights on the requirements or the issues related to the project or the solution. The round table is moderated by a leader, who introduces the topic and encourages the dialogue and debate among the participants. The round table is useful for exploring different viewpoints and opinions and for gaining a deeper understanding of the problem and the context. The round table also helps to foster a sense of involvement and ownership among the stakeholders and to identify the areas of agreement or disagreement. The Delphi technique is not a prototyping, which is a type of requirements elicitation technique that involves creating a simplified or partial version of the solution or a component of the solution and presenting it to the stakeholders for feedback. The prototype can be either low-fidelity or high-fidelity, depending on the level of detail and functionality. The prototype is useful for validating and verifying the requirements and for demonstrating the feasibility and usability of the solution. The prototype also helps to reduce the ambiguity and uncertainty of the requirements and to increase the satisfaction and acceptance of the solution. References:

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 4: Elicitation and Collaboration, page 180-181.

Top 10 Most Common Requirements Elicitation Techniques, paragraph 9

Software Engineering | Requirements Elicitation - GeeksforGeeks, paragraph 6

Delphi Method Forecasting Definition and How It’s Used - Investopedia, paragraph 1

The Delphi Technique - Students 4 Best Evidence, paragraph 1

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

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.

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

 A fishbone diagram is a technique that helps identify, explore, and display the possible causes of a specific problem or quality characteristic. It can also be used to analyze the root causes of a problem or a gap between the current and desired states of a solution. By using a fishbone diagram, the BA can understand the reason why the performance of the solution does not meet the expected benefits and identify potential corrective actions. References:

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 10: Solution Evaluation, page 393

Business Analysis Body of Knowledge (BABOK ®) Guide, Version 3, Section 10.23: Fishbone Diagrams, page 382-383

The BA should handle the change request by adding the feature to the product backlog for future prioritization. The product backlog is a list of features, functions, and requirements that are desired for the solution, but have not yet been planned or implemented. The product backlog is constantly updated and prioritized by the product owner, who represents the voice of the customer and the stakeholders. The BA should collaborate with the product owner to capture and document the change request and add it to the product backlog. The product owner will then decide when and how to prioritize the feature for the next iteration or release, based on the value and urgency of the feature and the feedback from the stakeholders. 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. 90-91

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 3: Business Analysis Planning and Monitoring, Section 3.2: Plan Business Analysis Approach, p. 58-59

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 4: Elicitation and Collaboration, Section 4.6: Communicate Business Analysis Information, p. 124-125

The next step for the BA after selecting a passive approach for establishing performance metrics is to identify the performance measures. Performance measures are the indicators that are used to evaluate the effectiveness and efficiency of a process, a solution, or an outcome. They can be quantitative or qualitative, and they can be based on various criteria, such as time, cost, quality, customer satisfaction, or compliance. The BA should identify the performance measures that are relevant, measurable, achievable, and aligned with the objectives and requirements of the project. The BA should also define the baseline and target values for each performance measure, as well as the data sources and collection methods. References:

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 7: Solution Evaluation, Section 7.1: Measure Solution Performance, p. 307-308

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 7: Solution Evaluation, Section 7.1: Measure Solution Performance, p. 267-268

Risk management is the process of identifying, analyzing, responding, and monitoring the risks that may affect the project or the organization. Risk management helps to minimize the negative impacts and maximize the positive opportunities of the uncertainties and assumptions. Risk management involves setting the risk tolerance, which is the level of risk exposure that the organization is willing to accept. Risk management also involves identifying the potential risks, which are the factors that may jeopardize the project or the organization’s objectives. Risk management also involves prioritizing the tolerance for risk, which is the order of importance of the risks based on their probability and impact. Risk management is an iterative and continuous process that should be performed throughout the project life cycle and at different levels of the organization. References: [IIBA BABOK Guide v3], section 11.1, page 384; CBAP / CCBA Certified Business Analysis Study Guide, chapter 5, page 227; CBAP Sample Questions, question 232.

A Gantt chart is a graphical tool that represents the duration of activities against a calendar. It shows the start and end dates, dependencies, and progress of each activity in a project. A Gantt chart can help project managers to plan, schedule, monitor, and control the project activities. It can also help to identify the critical path, which is the longest sequence of activities that determines the minimum time required to complete the project. References:

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, page 47

What Is a Gantt Chart? | Definition & Examples | APM

Activity Duration Estimates: Definition, Importance and Techniques - Indeed, under What are activity duration estimates?

An enterprise readiness assessment is a process of evaluating the current state of an organization and its readiness to adopt a new system or change12. It helps to identify the gaps, risks, and opportunities that may affect the success of the project3. Before eliciting requirements for a new system, the BA needs to understand the current situation, the stakeholders, the culture, the processes, and the potential impacts of the change4. This will help the BA to define the scope, objectives, and approach for the requirements elicitation. 

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

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 8: Solution Evaluation, page 346

Business Analysis Body of Knowledge (BABOK) Guide, Version 3, Chapter 8: Solution Evaluation, section 8.4: Assess Solution Limitations, page 158

Business Analysis Professional Resources, IIBA Resource Collection, Business Analysis Body of Knowledge (BABOK) Guide

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Skillsoft Book, Chapter 8: Solution Evaluation, page 346

The plan business analysis activities process involves defining the tasks and resources needed to perform the business analysis work. The inputs to this process are the business analysis approach, the organizational process assets, the stakeholder list, roles, and responsibilities, and the business analysis performance assessment. The list of identified risks is not an input to this process, but rather an output of the identify risks process, which is part of the business analysis planning and monitoring knowledge area. References: BABOK Guide v3, page 37; CBAP / CCBA Certified Business Analysis Study Guide, page 75.

Brainstorming is a technique to generate a large number of ideas or options for a problem or opportunity in a short time. It involves a group of stakeholders who share their thoughts and suggestions without criticism or evaluation. Brainstorming helps to identify options, factors, delays, and ideas for a solution by encouraging creativity, diversity, and collaboration. Benchmarking is a technique to compare the current state of a process, product, or service with a desired or best practice state. It involves identifying the performance indicators, standards, and targets for improvement. Benchmarking helps to identify gaps, opportunities, and best practices for a solution by providing a reference point or a baseline. Data flow diagrams are a technique to model the flow of data and information through a system or process. They involve identifying the sources, destinations, processes, and stores of data and information, and the relationships among them. Data flow diagrams help to identify inputs, outputs, transformations, and storage of data and information for a solution by providing a visual representation of the system or process. Business rules analysis is a technique to identify, express, validate, refine, and organize the rules that shape day-to-day business behavior and guide operational business decision making. Business rules are specific, actionable, testable directives that support a business policy. Business rules analysis helps to identify rules, policies, decisions, and constraints for a solution by providing a clear, consistent, and separated expression of the business logic. References: 9 Elicitation Techniques Used by Business Analysts – Tips and Guidance, CBAP® Handbook, Requirements Elicitation - Where to start as a Business Analyst?

 Problem tracking is a document elicitation technique that can help in this scenario. Problem tracking is the process of identifying, documenting, and resolving issues that arise during the business analysis process. Problem tracking helps to ensure the quality and validity of the requirements and the solutions. Problem tracking also provides an opportunity for stakeholders to rank the importance of issues affecting them. Problem tracking can be done using various tools, such as spreadsheets, databases, or software applications. Problem tracking can help the business analyst to monitor the status of the issues, communicate the progress and outcomes to the stakeholders, and improve the business analysis performance and practices. The other options are not document elicitation techniques, but rather information elicitation techniques. Brainstorming is a technique that involves generating new ideas and finding solutions for a specific problem. Observation is a technique that involves watching how people perform their tasks or interact with a system. Interviews are a technique that involves asking questions and documenting the responses from a single person or a group of people. References:

Problem/Issue Tracking Technique — Business Analyst Learnings, paragraph 1

Elicitation Methods | SpringerLink, paragraph 1

Understanding the Document Analysis Technique - Business Analyst Learnings, paragraph 1

 A schedule constraint is a limitation or restriction on the time available to complete a project or a task. A schedule constraint can be imposed by the organization, the customer, the stakeholders, or the environment. A schedule constraint can affect the scope, quality, cost, and risk of the project or the task. In this case, the 60 day implementation is a schedule constraint that limits the duration of the project and the scope of the changes that can be made to the existing web services. References: BABOK Guide v3, page 36; CBAP / CCBA Certified Business Analysis Study Guide, page 74.

A requirements workshop is a type of elicitation technique that involves carefully selected stakeholders and subject matter experts for a short, intensive period (usually for one to a few days) to define and document the requirements for a solution. A requirements workshop is also known as a joint application development (JAD) session or a facilitated workshop. The benefits of a requirements workshop include increased stakeholder collaboration, consensus building, creativity, and productivity. A requirements workshop is facilitated by a business analyst or a professional facilitator, who guides the participants through a structured agenda and ensures that the objectives of the workshop are met. References:

BABOK Guide, section 4.2.5.1, page 108

CBAP / CCBA Certified Business Analysis Study Guide, chapter 5, page 173

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

The project charter is the document that is created first after the project is awarded and the statement of work is handed over to the project manager. The project charter is a high-level document that formally authorizes the initiation of the project and defines the project vision, objectives, scope, deliverables, stakeholders, roles and responsibilities, assumptions, constraints, risks, and success criteria. The project charter also identifies the project sponsor, the project manager, and the project budget and schedule. The project charter provides the direction and guidance for the project and serves as a reference point for future decisions and changes. The project charter is usually created by the project sponsor or the customer, in collaboration with the project manager and the business analyst, and approved by the key stakeholders. References: [IIBA BABOK Guide v3], section 5.1.1, page 161; CBAP / CCBA Certified Business Analysis Study Guide, chapter 6, page 233; CBAP Sample Questions, question 243.

Visual learners are the type of learners who learn best through the presentation of models. Models are graphical representations of concepts, processes, systems, or data that help to illustrate and communicate information. Visual learners prefer to see the information rather than hear it or read it. They benefit from the use of colors, shapes, symbols, and spatial arrangements to organize and highlight the information. Models can help visual learners to understand the relationships, patterns, and trends of the information, as well as to compare and contrast different aspects of the information. Some examples of models that can be used in a presentation are diagrams, charts, graphs, maps, tables, and infographics. The other options are not the type of learners who learn best through the presentation of models, although they may also benefit from them. Auditory learners are the type of learners who learn best through listening to the information. They prefer to hear the information rather than see it or read it. They benefit from the use of voice, tone, pitch, and volume to convey and emphasize the information. Auditory learners can also learn from verbal explanations, discussions, debates, and questions. Kinesthetic learners are the type of learners who learn best through doing or experiencing the information. They prefer to interact with the information rather than see it or hear it. They benefit from the use of movement, touch, and physical activities to engage and stimulate the information. Kinesthetic learners can also learn from demonstrations, simulations, experiments, and role-plays. Communication model learners are not a type of learners, but rather a term used to describe a framework that explains how communication works. A communication model consists of elements such as sender, receiver, message, channel, feedback, and noise. A communication model can help the business analyst to understand the factors that affect the effectiveness and efficiency of communication, as well as to identify and overcome the barriers and challenges of communication. References:

The four different types of learners, and what they mean for your presentations (infographic), paragraph 2

Presentations for Each Type of Learner – Microsoft 365, paragraph 3

8 Types of Learning Styles | The Definitive Guide - Bay Atlantic University, paragraph 1

Learning styles (power point) | PPT - SlideShare, slide 4

 Functional decomposition is a technique that helps the business analyst understand the scope of the work by breaking down the scope into smaller work products. Functional decomposition is the process of identifying the high-level functions or capabilities of a solution and then dividing them into lower-level functions or sub-functions. This technique helps to create a hierarchical structure of the solution scope, which can be used to define the requirements, design the solution, and plan the project. Functional decomposition can also help to identify the dependencies, interfaces, and risks among the functions or sub-functions of the solution. References:

BABOK Guide v3, section 10.25, page 512-513

Solution Scope – An Insight, section 1.2, paragraph 2

Software Project Scope | Solution Scope in Business Analysis, paragraph 2

 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”

 A plan-driven approach to business analysis planning and monitoring is one that follows a predefined and detailed plan for the business analysis activities, deliverables, and tasks. A plan-driven approach is usually preferred when the scope, requirements, and solution are well-defined and stable, and when the stakeholders have a high degree of agreement and alignment. A plan-driven approach typically requires a significant amount of formality and detail in the documentation, approval, and communication of the requirements and the business analysis work. A plan-driven approach is also known as a predictive or waterfall approach. References:

BABOK® Guide, p. 13-14

CBAP / CCBA Certified Business Analysis Study Guide, p. 27-28

Certified Business Analysis Professional™ (CBAP®) | Coursera, Course 1, Week 2, Video: “Business Analysis Planning and Monitoring”

A model is a representation of a concept or system that is used to help people understand, change, or simulate the concept or system. A model can have various purposes, such as categorizing and creating hierarchies of items, defining boundaries for business domains, and showing business logic. However, a model does not define the risk and reward for the requirements, as this is a function of the business analysis approach and the stakeholder analysis. References:

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 4: Business Analysis Planning and Monitoring, p. 133

BABOK® Guide, Section 9.1: Plan Business Analysis Approach, p. 100

BABOK® Guide, Section 9.2: Conduct Stakeholder Analysis, p. 104

 A desired outcome is a statement of what the organization wants to achieve as a result of the business analysis work. A desired outcome should be specific, measurable, achievable, relevant, and time-bound (SMART). A desired outcome should also be aligned with the organizational goals and objectives, and provide value to the stakeholders. Examples of desired outcomes are increase sales, reduce costs, and reduce time to deliver a product or service. Implement new machinery to complete the work processes faster is not an example of a desired outcome, but rather a possible solution or requirement that may help to achieve a desired outcome. References: BABOK Guide v3, page 97; CBAP / CCBA Certified Business Analysis Study Guide, page 217.

Enterprise analysis is the business analysis knowledge area that involves defining the business need, assessing the capability gaps, determining the solution approach, defining the solution scope, and building the business case. In this scenario, the activity of examining the workflow and internal processes for order fulfillment and identifying the business problems and opportunities is part of the enterprise analysis. The purpose of this activity is to understand the current state of the organization and its environment, and to propose a solution that can address the business need and deliver value to the stakeholders. References:

BABOK® Guide, p. 16-17

CBAP / CCBA Certified Business Analysis Study Guide, p. 83-84

Certified Business Analysis Professional™ (CBAP®) | Coursera, Course 1, Week 4, Video: “Enterprise Analysis”

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

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

BABOK® Guide, page 30, section 3.2 Requirements Analysis and Design Definition

CBAP / CCBA Certified Business Analysis Study Guide, page 111, chapter 5 Requirements Analysis

Scenario and uses cases and user stories are conduct stakeholder analysis techniques that identify stakeholder roles that may serve as a useful starting point for identifying actors and roles. These techniques describe how stakeholders interact with the solution or the business process, and what their goals, needs, and expectations are. By creating scenarios and use cases and user stories, the business analyst can identify the primary and secondary stakeholders, as well as their roles and responsibilities. These techniques can also help to elicit, validate, and prioritize the requirements, as well as to communicate and collaborate with the stakeholders1234. References: 1: Scenarios, Use Cases, and User Stories1 2: Business Analysis Techniques: Eliciting Information and Collaborating with Stakeholders2 3: Use Cases and Scenarios3 4: User Stories4

A plan-driven approach to business analysis is a methodology that focuses on minimizing up-front uncertainty and ensuring that the solution is fully defined before implementation begins in order to maximize control and minimize risk. This approach tends to be preferred in situations where requirements are stable and clear, and where changes are costly and disruptive. Therefore, a plan-driven approach has the most business analysis work at the beginning of the project or during the start of a project phase, as it involves detailed planning, analysis, and documentation of the requirements and the solution. A plan-driven approach also requires formal approval and sign-off of the requirements and the solution before moving to the next phase123. References: 1: How to Choose the Right Business Analysis Approach1 2: Plan driven projects versus change driven2 3: Business Analysis Methodology3

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.

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

Functional vs Non-functional Requirements: What’s the Difference?

1.4 Characteristics of a Good Requirement - InformIT

How To Write a Good Requirement? 14 Qualities | Insights Spotter

Needs and Solutions, Requirements and Designs - IIBA®

Effectively! – Requirement Characteristics - ArgonDigital

 A constraint is a factor that limits the options or the performance of the project or the solution. Constraints are usually imposed by external factors, such as laws, regulations, standards, policies, resources, time, or budget. Constraints can affect the feasibility, desirability, and suitability of the solution, and may require trade-offs or compromises among the requirements. A constraint is different from a requirement, which is a condition or capability that the solution must have or meet to satisfy the stakeholder needs and expectations123.

In this question, the $300,000 represents a constraint, as it is a factor that limits the options or the performance of the solution. The customer demands that the solution should not cost more than $300,000 to implement and support for one year, which means that the solution must fit within this budget constraint. This constraint may affect the choice of technologies, processes, or features that the solution can include, and may require prioritizing or eliminating some requirements to meet the budget limit. References: 1: BABOK® Guide v3, section 3.4.2 Assess Capability Gaps, page 70 2: CBAP / CCBA Certified Business Analysis Study Guide, chapter 4, page 109 3: Business Analysis Techniques: Identifying Constraints, page 24

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

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

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

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

How to Write a Business Case | Smartsheet

Business Case Examples, explained in simple language - Chase Consulting

Feasibility Study: Definition, Methods, and Examples

Project Assumptions and Constraints: Examples and Differences

[Business Need - IIBA®]

[Solution Options - IIBA®]

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

[Stakeholder Concerns - IIBA®]

A capabilities gap assessment is a process of identifying and analyzing the gaps between the current and desired capabilities of an organization. It helps to determine what new capabilities are needed to achieve the business goals and objectives, and to seize the business opportunities1. A business opportunity is the chance to take advantage of an occurrence in the market for business gain. It involves some kind of favourable condition that can be used to create and implement ideas and innovations, solve problems, and maximize profits2.

If an organization does not have the necessary resources and technology to seize a business opportunity, the most likely course of action is to launch a new project. A project is a temporary endeavor undertaken to create a unique product, service, or result3. By launching a new project, the organization can allocate the required resources and technology, define the project scope, schedule, and budget, and deliver the desired outcome. A new project can also help the organization to close the capabilities gap, improve its performance, and gain a competitive advantage in the market.

The other options are less likely or not feasible. Hiring additional resources or contractors may not be enough to close the capabilities gap, as they may not have the relevant skills, knowledge, or experience. Moreover, hiring may incur additional costs and risks for the organization. Moving onto the next opportunity may not be a wise decision, as it may result in losing a valuable chance to grow the business and satisfy the customer needs. Therefore, launching a new project is the best course of action for the organization. References:

Capabilities Based Assessment (CBA) - AcqNotes

What Is Business Opportunity? – Importance, Types … - Feedough

Project Management Basics: What Is a Project? | PMI

 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.

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

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

Key performance indicators (KPIs) are a technique that involves defining and measuring specific, quantifiable, and relevant indicators of the performance and progress of a program, project, or solution. KPIs can help to validate the desired outcomes by:

Comparing the actual results of the solution against the expected or target results, such as the increase in sales and customer retention

Evaluating the effectiveness and efficiency of the solution in achieving the business objectives and meeting the stakeholder needs

Identifying the strengths and weaknesses of the solution and the areas for improvement or optimization

Communicating and reporting the performance and value of the solution to the stakeholders and the decision-makers

Some examples of KPIs that could be used to validate the desired outcomes of the restructured pricing model are:

Sales growth rate: The percentage change in sales over a given period of time

Customer retention rate: The percentage of customers who remain loyal to the company over a given period of time

Customer lifetime value: The net profit generated by a customer over the duration of their relationship with the company

Customer satisfaction score: The degree to which customers are satisfied with the company’s products, services, and interactions

References:

[BABOK Guide v3], Section 7.5: Validate Solution, p. 186-187

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 5: Solution Assessment and Validation, p. 211-212

Certified Business Analysis Professional™ (CBAP®) Specialization, Course 4: Business Analysis: Solution Evaluation, Week 2: Solution Performance Assessment, Video: Solution Performance Metrics

Key Performance Indicators (KPIs) - Definition, Types & Examples, Blog Post, June 2023

 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

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

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 3, Chapter 9: Data Modeling, p. 326-331; Chapter 10: Data Flow Diagrams, p. 336-339; Chapter 10: Activity Diagrams, p. 340-343.

Business Analysis for Practitioners: A Practice Guide, Chapter 5: Requirements Analysis and Design Definition, p. 125-126, 131-132.

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.

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

[BABOK Guide v3], Section 10.18: Document Analysis, p. 386-387

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 4: Requirements Elicitation and Collaboration, p. 149-150

Certified Business Analysis Professional™ (CBAP®) Specialization, Course 2: Business Analysis: Requirements Elicitation and Analysis, Week 1: Elicitation Techniques, Video: Document Analysis

Scope is the important factor that the BA needs to understand to ensure the workshop remains focused on the topic in question. Scope is the boundary or extent of the business analysis effort, which defines what is included and excluded from the change initiative. Scope also provides the context and direction for the requirements elicitation and analysis activities. By understanding the scope, the BA can plan and facilitate the workshop effectively, and avoid any irrelevant, out-of-scope, or conflicting discussions or issues. The other options are not the best answers, as they are not as critical as scope for keeping the workshop focused, although they may be related to the topic in question. For example, future state is the desired outcome of the change initiative, assets are the resources or capabilities of the enterprise, and risk register is the document that records the identified risks and their responses. References: CBAP Handbook, CBAP Study Guide, BABOK Guide

Verification is the process of evaluating the stated requirements to ensure that they are well-formed, consistent, complete, correct, and aligned with the organizational standards for business analysis. Verification is usually done by the BA or a peer reviewer before presenting the requirements to the stakeholders for validation or acceptance. Verification helps to ensure the quality and accuracy of the requirements, and to avoid errors, ambiguities, or misunderstandings. The other options are not the states that the BA is attempting to move the requirements into, as they are more related to the evaluation of the requirements against the business need, stakeholder expectations, or solution design. References: CBAP Handbook, CBAP Study Guide, BABOK Guide

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

References:

[BABOK Guide v3], Section 10.9: Data Modeling, p. 358-360

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 6: Requirements Analysis and Design Definition, p. 221-223

Certified Business Analysis Professional™ (CBAP®) Specialization, Course 2: Business Analysis: Requirements Elicitation and Analysis, Week 4: Requirements Analysis Techniques, Video: Data Modeling

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

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

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 3, Chapter 6: Requirements Life Cycle Management, p. 202-203, 207-208, 211-212.

Business Analysis for Practitioners: A Practice Guide, Chapter 4: Requirements Life Cycle Management, p. 97-98, 101-102, 105-106.

The 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 modeling technique that the BA will use to create this diagram is state modeling, as it is used to represent the dynamic behavior of an entity or a system over time. A state model shows the possible states that an entity can have, the events or conditions that trigger a change from one state to another, and the actions or outcomes that result from a state change. A state model can help to illustrate the various levels that a trainee goes through in a martial arts seminar, such as white belt, yellow belt, green belt, etc., and the criteria or requirements for advancing to the next level. References: The answer can be verified from the following sources:

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 3, Chapter 10: State Modeling, p. 344-347.

Business Analysis for Practitioners: A Practice Guide, Chapter 5: Requirements Analysis and Design Definition, p. 133-134.

This type of recommendation involves suggesting new or enhanced features or functions that can improve the performance or value of the solution. In this case, the BA recommended adding a feature that would allow the customer to select their industry and receive more relevant and personalized promotions and search results. This could potentially increase the use of the site and the awareness of the risk exposures for the customers.

Some additional sentences are:

This type of recommendation is different from the other options because it does not involve changing the organization, reducing the complexity of the interfaces, or retiring the solution.

The BA based this recommendation on the analysis of the feedback from the customers, the comparison with the similar companies, and the data on the claims filed during the pilot period.

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

Which incident-related activities require approval and confirmation

Who are the authorized personnel for each activity

What are the criteria and triggers for approval and confirmation

What are the outcomes and exceptions of approval and confirmation

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

References:

[BABOK Guide v3], Section 10.28: Process Modeling, p. 410-412

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 4: Requirements Elicitation and Collaboration, p. 161-163

Certified Business Analysis Professional™ (CBAP®) Specialization, Course 2: Business Analysis: Requirements Elicitation and Analysis, Week 4: Requirements Analysis Techniques, Video: Process Modeling

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 type of analysis that would help the BA gain approval to proceed with creating this type of training program for this team is cost benefit analysis, as this is a technique that helps to compare the expected costs and benefits of a proposed solution or change. Cost benefit analysis can help the BA to demonstrate the value and feasibility of the training program, as well as the potential risks and impacts of not implementing it. By showing the positive return on investment and the alignment with the business objectives and needs, the BA can persuade the decision makers and stakeholders to approve the training program. References: The answer can be verified from the following sources:

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 3, Chapter 7: Strategy Analysis, p. 232-233; Chapter 10: Cost Benefit Analysis, p. 352-355.

Business Analysis for Practitioners: A Practice Guide, Chapter 6: Solution Evaluation, p. 159-160.

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 BA should recommend implementing a system that coordinates order processing activities in advance with all trips. This approach aims to ensure that orders are ready for loading when the trucks arrive, eliminating the waste of both the truck’s and driver’s time. By aligning order preparation with delivery schedules, the distributor can optimize resource utilization and improve efficiency. References: I need to search for specific references from Business Analysis Professional (CBAP) Learning documents or resources to provide an exact source.

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

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

Reduce the number of individual meetings and interviews that need to be conducted

Increase the quality and quantity of information that can be gathered from different perspectives and sources

Enhance the communication and understanding among the stakeholders and the BA

Promote the consensus and agreement on the requirements and the solution scope

Identify and resolve any conflicts, issues, or gaps in the requirements

Some examples of collaborative elicitation techniques are:

Requirements workshops: A structured and facilitated session that brings together a group of stakeholders to elicit, analyze, and prioritize requirements

Brainstorming: A technique that generates a large number of ideas or solutions from a group of stakeholders in a creative and spontaneous manner

Focus groups: A technique that collects the opinions, preferences, and feedback of a group of stakeholders on a specific topic or issue

Prototyping: A technique that creates a simplified or partial version of the solution to elicit, demonstrate, and validate requirements

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

References:

[BABOK Guide v3], Section 4.2: Conduct Elicitation, p. 100-101

Types of Elicitation Techniques for the Business Analyst, Blog Post, September 2018

Elicitation Techniques Used by Business Analysts – Tips and Guidance, Blog Post, July 2023

 Success measures are the criteria that are used to evaluate the performance and value of a solution. They are derived from the business objectives and the expected benefits of the project. They help to determine whether the solution meets the needs and expectations of the stakeholders, and whether it delivers the desired outcomes and benefits. Success measures can be quantitative or qualitative, and they should be specific, measurable, achievable, relevant, and time-bound (SMART).

The other options are not correct because they are not the outputs of the initial analysis that the BA has been conducting. Business needs are the problems or opportunities that the organization wants to address with the project. Solution requirements are the capabilities and qualities that the solution must have to meet the business needs. Solution limitations are the constraints or risks that affect the solution’s performance or value. These aspects are more related to the scope and design of the solution, which are not yet defined at this point. References:

[A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 3], Chapter 6: Strategy Analysis, pp. 134-135, 140-141; Chapter 7: Requirements Analysis and Design Definition, pp. 152-153, 158-159, 164-165; Chapter 8: Solution Evaluation, pp. 178-179, 184-185.

[Business Analysis for Practitioners: A Practice Guide], Chapter 3: Needs Assessment, pp. 46-47; Chapter 5: Requirements Analysis and Design Definition, pp. 123-124, 133-134, 140-141; Chapter 6: Solution Evaluation, pp. 157-158, 163-164.

The lead BA should implement key performance measures to identify areas of improvement, as this is the most effective way to assess the current state of the business analysis practices and the value they deliver to the organization. Key performance measures are quantifiable indicators that reflect the critical success factors of a project, process, or activity. They can be used to evaluate the quality, efficiency, and effectiveness of the business analysis deliverables and outcomes, as well as the satisfaction and engagement of the stakeholders. By measuring and analyzing the key performance indicators, the lead BA can identify the gaps, issues, and opportunities for improvement in the business analysis practices, and propose solutions to enhance them.

The other options are not the best actions to take. A BA time tracking system may help to monitor the effort and duration of the business analysis activities, but it does not provide information on the quality and value of the deliverables and outcomes. Templates for BAs to use may help to standardize and document the business analysis deliverables, but they do not ensure the alignment and agreement of the requirements and the stakeholder needs. Workload plans of the BA may help to manage the resources and priorities of the business analysis activities, but they do not measure the impact and benefits of the business analysis outcomes. References: The answer can be verified from the following sources:

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 3, Chapter 2: Business Analysis Planning and Monitoring, p. 40-41, 48-49, 51-52.

Business Analysis for Practitioners: A Practice Guide, Chapter 4: Requirements Life Cycle Management, p. 93-94, 97-98.

This is because the enhancements aim to provide the following capabilities to the subscriber:

Ability to integrate online maps and GPS technology with the mobile application in real time to display location of service providers in the subscriber’s vicinity that participate in the subscriber’s plan network.

Ability for the subscriber to lookup the service providers by specifying either a postal code or a search area radius in miles.

Ability for the subscriber to initiate the download of fee information for one or more service providers in a single request.

These capabilities would enable the subscriber to find and compare the service providers that are convenient and affordable for them, thus addressing their business need.

The new success rate of the mortgage closure process can be calculated by subtracting the percentage of total rejects from 100%. The current success rate is 80%, which means the current percentage of total rejects is 20%. If the documentation rejects (10% of the total transactions) are eliminated by the use of documentation checklists, there would be no documentation rejects remaining. This would decrease the percentage of total rejects to (20% - 10%) = 10%. Therefore, the new success rate would be (100% - 10%) = 90%. References: The answer and explanation are derived based on logical reasoning and calculations from the data provided in the question, as well as the following sources:

Process Improvement Steps - Process Improvement Guide - Planview, Web Article, January 2023

7 Types of Process Improvement Methodologies [2023] • Asana, Web Article, January 2023

Certified Business Analysis Professional™ (CBAP®) Specialization, Online Course, December 2023

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.

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

According to the BABOK® Guide, the purpose of the Assess Proposed Solution task is to determine how well a proposed solution meets the business need and to identify any gaps, risks, or shortcomings before committing resources to its implementation. This task involves evaluating the solution against the requirements, the solution scope, and the solution acceptance criteria. Paul is performing this task by examining a single solution to determine its business value and feasibility. References: BABOK® Guide v3, Section 6.4: Assess Proposed Solution; CBAP® Handbook, Section 4: Review the Exam Blueprint.

Assessing capability gaps is a task of enterprise analysis that involves analyzing the current state of the organization and comparing it with the desired future state. The purpose of this task is to identify the new capabilities that the organization needs to acquire or enhance in order to meet the business need and achieve the organizational goals and objectives. These new capabilities can be related to processes, systems, people, or resources. Assessing capability gaps can help to determine the scope and feasibility of the solution, as well as the risks and benefits associated with it. References: BABOK Guide v3, page 25; CBAP / CCBA Certified Business Analysis Study Guide, page 69.

 The communications management plan is a document that defines the approach, methods, frequency, and responsibilities for communicating with the stakeholders throughout the business analysis process. The communications management plan also specifies how the business analysis communications will be stored, distributed, updated, and disposed of at the end of the project. Therefore, the business analyst must follow the communications management plan to determine what to do with all of the communication documents created as part of the project.

The other options are incorrect because they do not reflect the best practice for managing the business analysis communications. All formal communication must not be destroyed once the project is completed, as they may contain valuable information and lessons learned that can be used for future reference or audit purposes. All communications must not be documented and passed onto the solution’s project manager for analysis and to serve as supporting detail, as this may create unnecessary duplication, confusion, and overhead. The project manager may not be the best person to analyze and use the business analysis communications, as they may have different objectives and perspectives than the business analyst. All communications must not be archived and will become part of the organizational process assets, as this may not be appropriate or feasible for all types of communication. Some communication may be confidential, sensitive, or irrelevant for the organization, and may not need to be archived or shared with others. References:

BABOK® Guide, p. 29, 32

CBAP / CCBA Certified Business Analysis Study Guide, p. 45, 48

Certified Business Analysis Professional™ (CBAP®) | Coursera, Course 1, Week 2, Video: “Business Analysis Planning and Monitoring”

 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”

 A trainer is a role that works with the project team to understand the deliverables and then teaches the users of the deliverables how to utilize the project’s product. A trainer is responsible for designing, developing, and delivering training programs and materials that enable the users to learn and apply the skills and knowledge required to use the project’s product effectively and efficiently. A trainer also evaluates the effectiveness and outcomes of the training programs and provides feedback and support to the users and the project team12. An end user is a role that uses the project’s product to perform their tasks or functions. An end user is the ultimate beneficiary of the project’s product, and their needs and expectations are the primary drivers of the project’s requirements and scope. An end user also provides feedback and input to the project team throughout the project lifecycle, and participates in testing and validating the project’s product13. A database analyst is a role that designs, develops, and maintains the database systems and structures that store and manage the data and information for the project’s product. A database analyst is responsible for analyzing the data and information requirements and specifications, creating and modifying the database schemas and models, ensuring the data quality and integrity, and optimizing the database performance and security14. A stakeholder is a role that has an interest or influence in the project or the project’s product. A stakeholder can be an individual, group, or organization that is affected by or can affect the project’s outcomes and objectives. A stakeholder can have different roles and responsibilities in the project, such as a sponsor, a customer, a supplier, a regulator, a team member, or a subject matter expert15. References:

CBAP® Handbook

Trainer - iiba.org

End User - iiba.org

Database Analyst - iiba.org

Stakeholder - iiba.org

 An unstructured interview is a type of elicitation that allows each stakeholder to freely discuss their role in a particular process. An unstructured interview is a flexible and informal conversation that does not follow a predefined set of questions or topics. An unstructured interview allows the interviewer to explore the stakeholder’s perspectives, opinions, needs, and expectations in depth. An unstructured interview also allows the interviewer to adapt to the stakeholder’s responses and follow new lines of inquiry. An unstructured interview is useful for eliciting tacit knowledge, complex information, and emotional aspects of the stakeholder’s role. References: IIBA BABOK Guide v3, section 4.2.5, page 115; CBAP / CCBA Certified Business Analysis Study Guide, chapter 4, page 177; CBAP Sample Questions, question 238.

The planning stage of a project defines the number of risks and opportunities, including intense planning and anticipation of risk events. The planning stage is the process of establishing the scope, objectives, approach, and deliverables of the project. It involves defining the project requirements, assumptions, constraints, and dependencies. It also involves developing the project management plan, which includes the subsidiary plans for scope, schedule, cost, quality, resources, communications, risk, procurement, and stakeholder management. The planning stage helps to identify and analyze the risks and opportunities that may affect the project, and to plan the appropriate responses and strategies to address them. The planning stage also helps to align the expectations and involvement of the project stakeholders, and to obtain their approval and commitment for the project12. The executing stage of a project is the process of performing the work and producing the deliverables of the project. It involves implementing the project management plan, managing the project resources, executing the project activities and tasks, and creating the project outputs and outcomes. The executing stage helps to monitor and control the risks and opportunities that occur during the project, and to implement the planned responses and strategies to deal with them. The executing stage also helps to communicate and collaborate with the project stakeholders, and to manage their expectations and satisfaction12. The initiation stage of a project is the process of authorizing and launching the project. It involves identifying the problem or opportunity that the project intends to address, and defining the purpose, objectives, scope, and justification of the project. It also involves developing the project charter, which is a document that formally approves and initiates the project. The initiation stage helps to identify and assess the high-level risks and opportunities that are associated with the project, and to determine the feasibility and viability of the project. The initiation stage also helps to identify and engage the key project stakeholders, and to obtain their support and endorsement for the project12. The closing stage of a project is the process of finalizing and terminating the project. It involves verifying and validating the project deliverables, evaluating and documenting the project performance, and closing the project contracts and accounts. It also involves developing the project closure report, which is a document that summarizes and communicates the project results and lessons learned. The closing stage helps to identify and resolve the remaining risks and opportunities that are related to the project, and to ensure the project objectives and benefits are achieved. The closing stage also helps to acknowledge and appreciate the project stakeholders, and to transfer the project ownership and responsibility to the customer or sponsor12. References: CBAP® Handbook, Project Management Body of Knowledge (PMBOK® Guide) - Sixth Edition

 The medium is the portion of the communications model that could be defined as the translator. The medium is the channel or the tool that is used to transmit the message from the sender to the receiver. The medium can be verbal, written, visual, or a combination of these. The medium can also be electronic, such as email, phone, or video conference, or physical, such as paper, board, or face-to-face meeting. The medium acts as a translator by converting the message into a form that can be understood by the receiver. The medium also influences the effectiveness and efficiency of the communication, as different mediums have different advantages and disadvantages, such as speed, cost, feedback, and noise. References: IIBA BABOK Guide v3, section 2.2.2.3, page 25; CBAP / CCBA Certified Business Analysis Study Guide, chapter 6, page 236; Free CBAP CBAP® Exam Questions - IIBA CBAP Exam - Study4Exam, question 251.

The BA should trace the requirements to the business needs, because the business needs are the high-level goals or objectives that the organization or stakeholders want to achieve. By tracing the requirements to the business needs, the BA can ensure that the requirements are aligned with the strategic direction and value proposition of the organization or stakeholders, and that they do not conflict with each other or with the business needs. Tracing the requirements to the business needs can also help to prioritize, validate, and verify the requirements, as well as to manage changes and dependencies. Stakeholder tasks, organizational functions, and solution components are not the best options for tracing the requirements, because they are either too specific or too abstract, and they do not directly measure the value or benefit of the requirements. References:

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 5: Requirements Traceability and Monitoring, page 197

Business Analysis Body of Knowledge (BABOK) Guide, Version 3, Chapter 6: Requirements Analysis and Design Definition, section 6.1: Trace Requirements, page 121

Business Analysis Professional Resources, IIBA Resource Collection, Business Analysis Body of Knowledge (BABOK) Guide

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Skillsoft Book, Chapter 5: Requirements Traceability and Monitoring, page 197

 A requirement attribute is a characteristic or property of a requirement that provides additional information about it. Requirement attributes can help to manage, prioritize, trace, and verify the requirements. Some common requirement attributes are source, priority, status, owner, version, etc. One of the qualities of a good requirement is that it should be unambiguous, which means that it should have only one possible interpretation and avoid any confusion or misunderstanding. An unambiguous requirement is clear, precise, and consistent, and it can be easily verified and validated. An ambiguous requirement, on the other hand, can lead to errors, defects, rework, and conflicts among the stakeholders. References:

Characteristics of Effective Software Requirements and Software Requirements Specifications (SRS) - Jama Software, under Qualities of Good Requirements

The Four Attributes of High-Quality Requirements - ArgonDigital, paragraph 1

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, page 47

A trigger for re-prioritization is an event or a change that affects the relative importance or urgency of the project’s requirements or deliverables1. A new initial public offering (IPO) in the stock market is an example of such an event, as it may create new opportunities or threats for the online stock trading system and its stakeholders. The project team may need to re-prioritize the requirements or deliverables to align with the new market conditions and stakeholder expectations. The other options are not triggers for re-prioritization, but rather project issues or risks that need to be managed or mitigated. References: 1

 The information architect is the role that helps assess the data requirements of a project, identifies data assets, and helps the project team complete data modeling requirements. The information architect is responsible for designing and organizing the data structures, relationships, and flows that support the business processes and objectives. The information architect also ensures that the data quality, security, and integrity are maintained throughout the project. The information architect works closely with the business analyst, the database analyst, the end user, and the subject matter expert to elicit, analyze, validate, and communicate the data requirements and models. References: CBAP / CCBA Certified Business Analysis Study Guide, chapter 6, page 237; CBAP Sample Questions, question 231.

The T in SWOT analysis stands for Threats. These are external factors that may pose risks or challenges to the organization, its projects, or its solutions. Threats can be related to the market, the industry, the technology, the environment, the society, the regulation, or the competition. Business analysts should identify and assess the potential threats and their impact on the organization’s objectives and strategies, and recommend ways to mitigate or avoid them. References:

CBAP® Handbook, page 15, section 4.1.2.3

BABOK® Guide, page 32, section 3.2.3

SWOT Analysis: How To With Table and Example

SWOT Analysis Threats: Definition & Examples

 A one-to-one interview is the most common type of interview as part of requirements elicitation. A one-to-one interview is a systematic approach for eliciting information from a single person in an informal or formal setting by asking questions and documenting the responses. A one-to-one interview allows the business analyst to establish rapport with the interviewee, probe deeper into their needs and expectations, observe their non-verbal cues, and clarify any ambiguities or inconsistencies. A one-to-one interview is also easier to schedule and conduct than other types of interviews that involve multiple participants, such as many-to-one, many-to-many, or one-to-many. References:

Requirements Elicitation: Interview Dos and Don’ts, paragraph 1

Top 10 Most Common Requirements Elicitation Techniques, paragraph 3

Types of Elicitation Techniques for the Business Analyst, paragraph 2

What Questions Do I Ask During Requirements Elicitation?, paragraph 1

Interviews: Requirements Elicitation Technique, paragraph 1

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 BA should review the future state with the process owner who expresses a strong opinion that the solution will not deliver the expected value. This is because the future state describes the desired outcomes, benefits, and capabilities of the solution, and how it will address the business need and stakeholder requirements. By reviewing the future state, the BA can help the process owner to understand the value proposition of the solution, clarify any misunderstandings or assumptions, and address any concerns or objections. This can help to increase the process owner’s engagement and support for the change. Updating the requirements, recording the feedback and continuing, or changing the governance approach are not the best options because they do not address the root cause of the problem and may result in resistance or conflict. References:

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 6: Strategy Analysis, page 254

Business Analysis Body of Knowledge (BABOK) Guide, Version 3, Chapter 5: Strategy Analysis, section 5.3: Define Future State, page 99

Business Analysis Professional Resources, IIBA Resource Collection, Business Analysis Body of Knowledge (BABOK) Guide

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Skillsoft Book, Chapter 6: Strategy Analysis, page 254

A project schedule network diagram is a graphical representation of the logical relationships among the project activities. It shows the dependencies, sequence, and duration of all the activities in a project. A project schedule network diagram is always laid out in a left to right display to properly reflect the chronology of all project work. The diagram can be drawn using different methods, such as the precedence diagramming method (PDM), the arrow diagramming method (ADM), or the graphical evaluation and review technique (GERT). References:

Project Schedule Network Diagrams from the Project Management Body of Knowledge (PMBOK® Guide) - Sixth Edition

Schedule Network Analysis from the Business Analysis Body of Knowledge (BABOK® Guide) - Version 3

The stakeholders and the BA need to measure benefits, penalties, and costs to determine if the solution is providing expected value and ensure the accuracy of the measurements. Benefits are the positive outcomes or value that the solution delivers to the stakeholders or the organization. Penalties are the negative consequences or costs that the solution may incur if it fails to meet the requirements or expectations. Costs are the resources or expenses that are required to implement, operate, and maintain the solution. By measuring benefits, penalties, and costs, the stakeholders and the BA can assess the return on investment (ROI), the net present value (NPV), and the break-even point (BEP) of the solution, and compare them with the expected or planned values. This can help to evaluate the effectiveness, efficiency, and feasibility of the solution, and to identify any gaps, issues, or opportunities for improvement. Strategy, solution, and scope are not the best options to measure, because they are either too general, too abstract, or not directly related to the value of the solution. References:

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 8: Solution Evaluation, page 337

Business Analysis Body of Knowledge (BABOK) Guide, Version 3, Chapter 8: Solution Evaluation, section 8.2: Analyze Performance Measures, page 153

Business Analysis Professional Resources, IIBA Resource Collection, Business Analysis Body of Knowledge (BABOK) Guide

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Skillsoft Book, Chapter 8: Solution Evaluation, page 337

 A top-down estimate is an estimate based on past projects to predict the current cost and/or duration of the current project. It is also called an analogous estimate, as it involves using data from previous, similar projects to estimate activity durations1. Top-down estimates are usually done at the early stages of a project, when there is not enough detail or information available to perform more accurate estimates. They are useful for providing a rough order of magnitude (ROM) or a ballpark figure for the project scope, cost and schedule. Top-down estimates are typically faster and cheaper to produce than bottom-up estimates, but they are also less accurate and reliable23. References: 2: Project Cost Estimation: How to Estimate Project Cost - ProjectManager2 3: 11 Cost Estimating Methods (With Formulas and Examples) | Indeed.com3 1: Understanding the Analogous Estimating Technique | Runn1

A requirements trace matrix (RTM) is a tool that helps to ensure that the project’s scope, requirements, and deliverables remain consistent and aligned throughout the project lifecycle. It traces the requirements from their origin to their fulfillment by linking them to other project artifacts, such as design documents, test cases, and solution components. An RTM can also be used to verify that all requirements are met and to identify changes to the scope when they occur. An RTM is especially useful for smaller projects where there are few requirements, as it can help to track the progress and status of each requirement and avoid scope creep. A requirements trace matrix is not the same as a roles and responsibility matrix (A), a RACI matrix (B), or a coverage matrix ©, which are different types of matrices that serve different purposes in project management. References:

IIBA BABOK Guide v3, p. 30, 176, 264

Requirements Traceability Matrix – RTM - Project-Management.com

CBAP/CCBA/ECBA Certification Practice Test | MindsMapped, Question 6

Ad images are a strong candidate to be addressed while planning for requirements reuse, because they are likely to change frequently and have common elements that can be reused across different weeks. Requirements reuse is a technique that involves identifying, storing, and reusing requirements or requirement components for future projects or initiatives. It can help to reduce duplication, improve consistency, and save time and effort. Ad images can benefit from requirements reuse, because they can use a standard template, format, and style, and only change the specific image and text for each new topping. Dough preparation, toppings preparation, and topping recipes are not good candidates for requirements reuse, because they are either stable or unique for each week. References:

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 3: Requirements Life Cycle Management, page 124

Business Analysis Body of Knowledge (BABOK) Guide, Version 3, Chapter 3: Requirements Life Cycle Management, section 3.7: Reuse Requirements, page 66

Business Analysis Professional Resources, IIBA Resource Collection, Business Analysis Body of Knowledge (BABOK) Guide

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Skillsoft Book, Chapter 3: Requirements Life Cycle Management, page 124

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

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, page 279

Business Analysis Professional Resources | IIBA®, under Business Analysis Body of Knowledge (BABOK ®) Guide

All About Business Process Mapping, Flow Charts and Diagrams | Lucidchart, under What is business process mapping?

 Fast tracking is a schedule compression technique that involves overlapping two or more phases or activities of a program that are normally performed in sequence. Fast tracking is used to shorten the overall duration of a program without changing its scope or reducing its quality. Fast tracking can increase the risk of rework, errors, or conflicts due to the concurrent execution of interdependent phases or activities12. Lead time is the amount of time between the start or finish of one activity and the start or finish of another activity that is dependent on it. Lead time is used to create a logical or sequential relationship between two activities, such as a finish-to-start, start-to-start, finish-to-finish, or start-to-finish relationship. Lead time can be positive or negative, depending on whether the successor activity starts or finishes before or after the predecessor activity13. Rolling is a planning technique that involves progressively elaborating the details of a program as more information becomes available. Rolling is used to cope with the uncertainty and complexity of a program, and to adapt to the changes and feedback that occur during the program lifecycle. Rolling can be applied to different aspects of a program, such as the scope, schedule, cost, quality, or risk14. Crashing is a schedule compression technique that involves adding or reallocating resources to critical or near-critical activities of a program that are on the critical path. Crashing is used to shorten the overall duration of a program without changing its scope or compromising its quality. Crashing can increase the cost, complexity, or risk of a program due to the additional or redistributed resources15. References:

CBAP® Handbook

Fast Tracking - iiba.org

Lead Time - iiba.org

Rolling - iiba.org

Crashing - iiba.org

The relationship between F1 and F2 is that they are mutually exclusive and dependent features. This means that the customer can only choose one of them, and the choice depends on their charging needs. If the customer wants to have their mobile device fully charged, they will select F1. If the customer only wants to have their mobile device partially charged, they will select F2 and specify the amount of charge they need. The customer cannot select both F1 and F2 at the same time, nor can they select neither of them. Therefore, F1 and F2 depend on each other and on the customer’s preference. 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

Requirements Relationships - Business Analyst Learnings, under Mutually Exclusive Relationship

The BA should set up additional activities to collaboratively resolve the variations in the elicitation results, as this will help to ensure that the information is accurate, consistent, and complete. The BA can use techniques such as reviews, workshops, or focus groups to confirm the elicitation results with the stakeholders, identify and address any gaps, conflicts, or ambiguities, and reach a consensus on the requirements12. The other options are not effective ways to resolve the variations. Identifying a few key stakeholders to resolve the conflicts may exclude other relevant stakeholders and create bias or resentment. Removing requirements that cause differences may result in losing important information or value. Weighting the results from the observation because it is more reliable may ignore other sources of information or perspectives.

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

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 6: Strategy Analysis, page 254

Business Analysis Body of Knowledge (BABOK) Guide, Version 3, Chapter 5: Strategy Analysis, section 5.3: Define Future State, page 99

Business Analysis Professional Resources, IIBA Resource Collection, Business Analysis Body of Knowledge (BABOK) Guide

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Skillsoft Book, Chapter 6: Strategy Analysis, page 254

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

The BA should recommend to eliminate the requirement that does not deliver benefit to any of the stakeholders and does not align with the solution scope. This is because the requirement is not necessary, valuable, or feasible, and it may introduce unnecessary complexity, cost, or risk to the solution. Eliminating the requirement would help to optimize the solution and ensure that it meets the stakeholder needs and expectations. Updating the solution design, re-evaluating the future state, or changing the solution scope are not the best options because they do not address the root cause of the problem and may result in scope creep or rework. References:

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 3: Requirements Life Cycle Management, page 115

Business Analysis Body of Knowledge (BABOK) Guide, Version 3, Chapter 3: Requirements Life Cycle Management, section 3.6: Assess Requirements Changes, page 64

 A work breakdown structure (WBS) is a visual decomposition of the project scope into smaller and manageable components or deliverables. A WBS is a hierarchical representation of the work that needs to be done to complete the project and achieve its objectives. A WBS defines the scope, schedule, cost, and quality of the project, and helps to allocate the resources and assign the responsibilities for the project. A WBS also helps to identify the dependencies, risks, and issues of the project, and to monitor and control the project performance12. A budgeted cost of work scheduled (BCWS) is a measure of the planned value of the project. A BCWS is the sum of the budgets for all the work packages and activities that are scheduled to be completed by a given date. A BCWS defines the expected cost of the project, and helps to compare the actual cost and the earned value of the project. A BCWS also helps to identify the cost variance and the cost performance index of the project, and to forecast the cost at completion and the estimate at completion13. A resource breakdown structure (RBS) is a visual decomposition of the resources that are needed to complete the project. An RBS is a hierarchical representation of the human and non-human resources that are required to perform the work packages and activities of the project. An RBS defines the types, categories, and quantities of the resources, and helps to estimate, acquire, and manage the resources for the project. An RBS also helps to identify the availability, utilization, and allocation of the resources, and to optimize the resource efficiency and effectiveness14. A product breakdown structure (PBS) is a visual decomposition of the products that are delivered by the project. A PBS is a hierarchical representation of the components and features that make up the products of the project. A PBS defines the scope, quality, and functionality of the products, and helps to design, develop, and test the products for the project. A PBS also helps to identify the requirements, specifications, and standards of the products, and to verify and validate the products1 . References:

CBAP® Handbook

Work Breakdown Structure - iiba.org

Budgeted Cost of Work Scheduled - iiba.org

Resource Breakdown Structure - iiba.org

[Product Breakdown Structure - iiba.org]

The critical path method (CPM) is a graphical presentation of a project plan that shows the sequence and duration of the project activities, and the dependencies and constraints among them. The CPM identifies the critical path, which is the longest path of activities that determines the minimum time required to complete the project. The CPM also identifies the float or slack, which is the amount of time that an activity can be delayed without affecting the project completion date. The CPM is most appropriate for presenting to upper management because it provides a clear and concise overview of the project schedule, scope, and risk. It also helps to communicate the project milestones, deliverables, and progress, and to highlight the critical activities and issues that need attention or resolution12. A pie chart is a graphical presentation of a project plan that shows the proportion of each category or segment of data in relation to the whole. A pie chart is useful for presenting to upper management when the project plan involves a simple breakdown of the project budget, resources, or scope into discrete and mutually exclusive categories or segments. A pie chart helps to compare the relative size and distribution of the categories or segments, and to illustrate the percentage or fraction of the whole that each category or segment represents34. A Pareto chart is a graphical presentation of a project plan that shows the frequency or impact of different factors or causes of problems or issues in descending order of importance. A Pareto chart is based on the Pareto principle, also known as the 80-20 rule, which states that 80% of the effects come from 20% of the causes. A Pareto chart is useful for presenting to upper management when the project plan involves a complex analysis of the project quality, performance, or risk. A Pareto chart helps to identify and prioritize the most significant factors or causes of problems or issues, and to focus on the vital few rather than the trivial many5 . A scatter chart is a graphical presentation of a project plan that shows the relationship or correlation between two variables or sets of data. A scatter chart plots the values of the variables or sets of data as points on a coordinate plane, and shows the pattern or trend of the points. A scatter chart is useful for presenting to upper management when the project plan involves a sophisticated evaluation of the project variables, outcomes, or assumptions. A scatter chart helps to explore and test the hypotheses or causal relationships between the variables or sets of data, and to measure the strength and direction of the correlation . References:

Critical Path Method - iiba.org

How to Make a Project Plan Presentation for Clients and Stakeholders

Pie Chart - iiba.org

How to Use a Schedule Model in Project Management

Pareto Chart - iiba.org

[ProjectManagement.com - Certified Business Analysis Professional (CBAP®)]

[Scatter Chart - iiba.org]

[CBAP Presentation | PPT - SlideShare]

 According to Herzberg’s two-factor theory of motivation, there are two sets of factors that influence job satisfaction: hygiene factors and motivators. Hygiene factors are those job factors that are essential for existence of motivation at workplace, but do not lead to positive satisfaction for long-term. They are also called dissatisfiers or maintenance factors, as they are required to avoid dissatisfaction. Hygiene factors include pay, company policies, fringe benefits, physical working conditions, status, interpersonal relations, and job security. Motivators are those factors that yield positive satisfaction and enhance motivation. They are inherent to work and relate to self-growth and self-actualization. Motivators include recognition, sense of achievement, growth, responsibility, and advancement. The chance to excel is a motivator, not a hygiene factor, according to Herzberg’s theory. References: Herzberg’s Two-Factor Theory Of Motivation-Hygiene - Simply Psychology; Herzberg’s Two-Factor Theory of Motivation - Management Study Guide; Two-factor theory - Wikipedia

 A dependent task is a task that belongs to a certain work entity (project or process) and relates to other tasks of the same work entity in a way that ensures their interconnection and common direction. A dependent task can be a sub-task of a larger activity. It causes an effect to other tasks and sub-tasks. A dependent task cannot start until other tasks are completed, because it relies on the output, input, or resource of those tasks. A dependent task is also referred to as a logical relationship, because it shows the logical order or sequence of the tasks1. An analysis task is a task that involves examining, evaluating, or interpreting data, information, or requirements. An analysis task can be a dependent task or an independent task, depending on whether it requires the completion of other tasks or not. An analysis task can also be a predecessor task or a successor task, depending on whether it precedes or follows other tasks. An analysis task is a common type of task in business analysis2. A predecessor task is a task that comes before another task in a sequence or a network of tasks. A predecessor task can be a dependent task or an independent task, depending on whether it affects or is affected by other tasks or not. A predecessor task can also be an analysis task or a different type of task, depending on its nature and purpose. A predecessor task can start before other tasks are completed, as long as it does not depend on them3. An independent task is a task that does not belong to a certain work entity (project or process) or does not relate to other tasks of the same work entity. An independent task can be a standalone activity or a part of a larger activity. It does not cause an effect to other tasks or sub-tasks. An independent task can start at any time, regardless of the completion of other tasks, because it does not rely on the output, input, or resource of those tasks. An independent task is also referred to as a discrete task, because it is separate and distinct from other tasks1. References:

CBAP® Handbook

Predecessor Task - iiba.org

Dependent Task - iiba.org

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 high chance 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.

The all out approach is a timeboxing or budgeting technique that involves excluding all the requirements for a start and then including the ones that can be implemented within the constrained time or budget. Henry is using this approach by removing the requirements from the allowed list until he meets the budget limit. This is different from the all in approach, which involves including all the requirements necessary for the solution and then removing or postponing the ones that will cause the project to exceed the deadline or budget. The parametric approach is a cost estimation technique that uses statistical relationships between historical data and other variables. The selective approach is a prioritization technique that involves ranking the requirements based on their value and urgency. References:

CBAP Certification Study Guide v3.0, p. 223

BABOK Guide v3, p. 156

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

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

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

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

 Scope creep is the change or expansion in the project scope that occurs without proper assessment and approval. It can result in cost overruns, delays, and client satisfaction issues. Scope creep can happen due to unclear or changing requirements, lack of stakeholder involvement, poor communication, or inadequate change control. To prevent scope creep, business analysts should define the project scope clearly, manage stakeholder expectations, document and prioritize requirements, and follow a change management process. References:

Scope Creep: Definition, Examples & How To Prevent It - Forbes

What is Scope Creep and 7 Ways to Avoid it [2023] • Asana

What is the meaning of Scope Creep in Project Management?

The project manager is the stakeholder who must approve the business analysis approach to ensure that it is compatible with the other project activities. The project manager is responsible for overseeing the project execution, managing the project resources, and ensuring that the project meets its objectives, scope, schedule, and budget. The project manager also coordinates the work of the project team, including the business analyst, and ensures alignment between the project management approach and the business analysis approach. The project manager needs to approve the business analysis approach to ensure that it supports the project goals, fits the project constraints, and does not conflict with the project plan. The project manager also needs to monitor and control the business analysis activities and deliverables throughout the project lifecycle. The project manager and the business analyst should collaborate closely to define and document the business analysis approach, as well as to communicate and manage changes to the approach as needed1234. References: 1: How to Choose the Right Business Analysis Approach1 2: Business analysis approach planning2 3: Approve Requirements3 4: Defining the Business Analysis Approach in 20235

 Requirements prioritization is the process of ranking the requirements in the order of their importance or value to the stakeholders and the solution. Requirements prioritization helps to ensure that the most critical and beneficial requirements are implemented first, and that the project focuses on delivering the maximum value to the stakeholders within the available time and resources. Requirements prioritization also helps to manage the scope, schedule, budget, and quality of the project, as well as to handle changes and risks effectively123. References: 1: Five Requirements Prioritization Methods1 2: What is Requirements Prioritization?2 3: The 6 Most Important Requirements Practices3

Prioritizing requirements is a process that helps business analysts and stakeholders to rank the requirements according to their importance, value, urgency, and dependency. Prioritizing requirements helps to ensure that the most critical requirements are addressed first, and that the available resources are allocated effectively. Prioritizing requirements also helps to manage the scope, schedule, and budget of the project, and to deal with changes and uncertainties. Prioritizing requirements is not only about determining the cost or the schedule of each requirement, but also about understanding the impact and the benefit of each requirement on the business need and the solution. Prioritizing requirements is not only about identifying the risks associated with each requirement, but also about mitigating or avoiding those risks by choosing the best solution option. References:

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

Why Prioritise Requirements – How to do it and Why it is Critical to Project Success – BusinessAnalystMentor.com, paragraph 1

Why You Should Prioritize Requirements - ArgonDigital, paragraph 1

What Is Requirements Prioritization? Definition & Examples - airfocus, paragraph 1

Business analysts : How to prioritize requirements - Adaptive US, paragraph 1

 A solution approach is a description of the proposed method for delivering a solution that meets the business need. It is one of the outputs of the enterprise analysis tasks, along with business need, capability gaps, solution scope, and business case. A solution approach defines the type, nature, and complexity of the solution, and provides a high-level view of how the solution will be implemented. It also identifies the major components, features, and functions of the solution, as well as the key stakeholders, risks, assumptions, and constraints. A solution approach helps to evaluate the feasibility and viability of different solution options and compare them with the business need and expected benefits. References:

IIBA BABOK Guide v3, p. 30, 176, 264

An Overview of Enterprise Analysis - Modern Analyst

How Do You Know When You Are Doing Enterprise Analysis

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

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

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

Plugging in the numbers, we get:

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

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

BABOK® Guide, section 3.4.5.5, pages 76-77

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

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

A methodology is a set of principles, rules, and processes that guide the business analysis activities and deliverables within a project or organization. A methodology can be based on a standard, such as the BABOK Guide, or a specific framework, such as Waterfall or Agile. A methodology helps the business analyst to plan, execute, monitor, and control the business analysis work in a consistent and effective way. References:

BABOK Guide, Chapter 2: Business Analysis Planning and Monitoring, Section 2.1: Plan Business Analysis Approach, p. 24-25

Business Analysis Methodology | What is this and is it real?

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

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 2: Business Analysis Planning and Monitoring, page 50

Business Analysis Body of Knowledge (BABOK ®) Guide, Version 3, Chapter 6: Solution Evaluation, section 6.5.2: Assess Enterprise Limitations, page 176

Certified Business Analysis Professional™ (CBAP®) | Coursera, Course 4: Business Analysis Planning and Monitoring, Week 2: Plan Business Analysis Approach, video: “Solution Evaluation”

 Quality control is not one of the reasons why trace requirements is useful, but a process that monitors and measures the quality of the project deliverables and outputs against the quality standards and criteria established in the quality management plan. Quality control is used to make certain that the project team members are completing the project work according to the project plan and meeting the stakeholder expectations. Quality control involves performing quality audits, inspections, tests, reviews, and validations to identify and correct any defects, errors, or deviations from the specifications1.

The other three options are valid reasons why trace requirements is useful. Trace requirements is a technique that involves establishing and documenting the relationships between requirements and other aspects of the product management process, such as design elements, test cases, releases, and incidents. Trace requirements is useful for the following purposes234:

Impact analysis: Trace requirements helps to evaluate the impact of a potential change or a problem on the requirements and the solution. By tracing the dependencies and links between requirements and other items, the business analyst can quickly and easily assess the scope, cost, time, and risk implications of the change or the problem, and plan the appropriate response actions.

Requirements coverage: Trace requirements helps to ensure that all the requirements are fulfilled by the solution and that all the solution components contribute to the requirements. By tracing the alignment and mapping between requirements and solution components, the business analyst can verify that the solution meets the stakeholder needs and expectations, and that there are no gaps or redundancies in the solution.

Requirements allocation: Trace requirements helps to assign requirements to solution components and to releases. By tracing the distribution and allocation of requirements to different parts of the solution and to different phases of the project, the business analyst can prioritize and schedule the requirements based on their value, risk, dependency, and complexity, and ensure that the solution is delivered incrementally and iteratively. References: 1: Project Quality Management: Processes & Tools | Villanova University5 2: Requirements Traceability - The What, Why and How | Netmind6 3: Requirements traceability – why and how to do it?7 4: Requirements traceability : What, why and how - Modern Analyst8

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

References:

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

How the RACI Matrix Streamlines Stakeholder Engagement, paragraph 1

Stakeholder Wrangling 101: The RACI Framework, paragraph 1

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

 A vision statement is a document that defines the business needs, identifies key stakeholders, and describes the positive impact the solution will provide on the key stakeholders. A vision statement is a high-level summary of the purpose, scope, and objectives of the project or initiative. It helps to align the stakeholders’ expectations, communicate the value proposition, and guide the decision making throughout the project lifecycle. A vision statement is one of the key inputs for 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.1 Define Business Need, page 69 2: CBAP / CCBA Certified Business Analysis Study Guide, chapter 4, page 106 3: Business Analysis Techniques: Developing the Vision, pages 23-24 4: How to Write a Vision Statement for Your Business5

Benchmarking is a business analysis approach that involves comparing one’s own performance, processes, or products with those of other organizations, especially the best performers or industry leaders, to identify gaps and opportunities for improvement. Benchmarking can help business analysts understand the competitive landscape, identify best practices, set realistic goals, and measure progress. In this question, Sally and her business analysis team are using benchmarking to determine what the competition is offering and how they can increase their revenue by remaining competitive. References:

CBAP® Handbook, page 15, section 4.1.2.3

BABOK® Guide, page 32, section 3.2.3

CBAP / CCBA Certified Business Analysis Study Guide, page 96, section 3.2.3

What is a Competitive Analysis — and How Do You Conduct One?

 Brainstorming is a technique for generating creative ideas and solutions through intensive and freewheeling group discussion. One of the guidelines for effective brainstorming is to encourage quantity over quality, meaning that participants should try to generate as many ideas as possible without worrying about their feasibility or quality. Setting a limit of ten ideas may discourage further creativity and prevent the group from exploring other potential solutions. Therefore, the goal should be to come up with as many solutions as possible, not just ten ideas. References:

BABOK® Guide, section 10.25.3, page 404

Certified Business Analysis Professional™ (CBAP®) Handbook, page 6

Tips for Earning a Business Analysis Certification | IIBA®

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)

 According to the BABOK® Guide, conflicts among stakeholders are inevitable and must be resolved before formal approval of the requirements can be obtained. The business analyst is responsible for facilitating the resolution of conflicts by using various techniques such as problem-solving, negotiation, or escalation. The business analyst should not make the decision for the stakeholders, nor should the decision be based on seniority or deferred until later. References: BABOK® Guide v3, section 4.5.5, page 142; CBAP® Handbook, section 4.4, page 6.