CBAP Certified Business Analysis Professional Question and Answers

 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

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?

A flowchart is a business analysis technique that graphically depicts the steps or actions involved in a process or workflow. A flowchart consists of four main components: activities, decisions, forks, and joins. Activities are the tasks or steps that are performed in the process. Decisions are the points where a choice must be made between two or more alternatives. Forks are the points where the flow splits into two or more parallel paths. Joins are the points where two or more paths converge. Attributes are not a component of flowchart, but rather a term used to describe the characteristics or properties of an entity or object in a data model. 

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

TCO=I+(S×T)

where I is the initial investment, S is the monthly support cost, and T is the number of months.

For the inhouse solution, the TCO is:

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

For the vendor solution, the TCO is:

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

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

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

Simplifying and rearranging, we get:

T=50016,000​=32

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

 A business case is a document that provides justification for undertaking a project, programme or portfolio. It evaluates the benefit, cost and risk of alternative options and provides a rationale for the preferred solution. The purpose of the business case is to communicate the value of the solution to the organization and help the decision-makers decide whether to approve the project or not. The business case should include the following elements:

Executive summary: A brief overview of the problem, opportunity, solution, benefits, costs, risks and recommendations.

Introduction: A description of the background, context, scope and objectives of the project.

Analysis: A detailed analysis of the current state, future state, gap, options, criteria, assumptions and constraints.

Evaluation: A comparison of the options based on the criteria, such as financial, strategic, operational, technical, social and environmental factors.

Recommendation: A clear statement of the preferred option and the reasons for choosing it over the others.

Implementation: A description of the implementation plan, including the schedule, resources, roles, responsibilities, governance, change management and risk management.

Appendices: Any supporting information, such as data, calculations, charts, diagrams, references, etc.

References:

Business Analysis Body of Knowledge (BABOK) Guide, Version 3, Chapter 3: Business Analysis Planning and Monitoring, Section 3.4: Plan Business Analysis Approach, Task 3.4.3: Define Business Analysis Process, Technique 3.4.3.1: Decision Analysis, p. 66-67.

What is business case? | APM

How to Write a Business Case: Template & Examples | Adobe Workfront

 Issue tracking is a technique to capture and assign responsibility for issues and stakeholder concerns that pose an impact to the solution. It helps to monitor the status and resolution of issues throughout the project lifecycle. Problem tracking is not a valid term in the BABOK® Guide. RTM stands for Requirements Traceability Matrix, which is a technique to track the relationships among requirements and other project artifacts. Baselining is a technique to establish an approved version of a requirements package or other deliverable as a basis for future development or change control. References: CCBA® and CBAP® Certifications Study Guide, CBAP® Handbook, [BABOK® Guide]

https://www.iiba.org/globalassets/standards-and-resources/babok/babok-guide-v3.pdf

 The kinesthetic learning approach is a style of learning that involves physical movement, hands-on activities, and experimentation. Kinesthetic learners prefer to learn by doing rather than by reading, listening, or watching. They learn best by experiencing the topic through simulations, role-plays, demonstrations, exercises, or games. They also benefit from frequent breaks, movement, and feedback. The other statements describe different learning approaches. The learners who learn best by reading and pondering are verbal learners. The learners who learn best by seeing the topic in a model or through storyboards are visual learners. The learners who are not interested in the topic unless they can immediately apply it to their lives or jobs are pragmatic learners. References: Learning Styles: The Four Modalities, Learning Styles and the Business Analyst, Learning Styles and the CBAP Exam

Implementation subject matter experts are the stakeholders who would need detailed technical interface requirements. These are the people who are responsible for designing, developing, and deploying the solution components that interact with other systems or applications. Technical interface requirements specify the format, structure, protocol, and security of the data exchange between the solution and the external entities. Project manager, regulators, and testers are other types of stakeholders who may need different levels of information related to the requirements, but not necessarily the technical interface details. References:

BABOK® Guide, p. 29, 36, 51, 54

CBAP / CCBA Certified Business Analysis Study Guide, p. 45, 49, 50, 52

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

A regulator is a stakeholder who may be responsible to dictate that a specific process or technique be followed during the requirements elicitation activities. A regulator is an external stakeholder who has the authority to enforce laws, rules, standards, or policies that affect the project or the solution. A regulator may impose certain requirements or constraints on the project or the solution, such as compliance, security, privacy, or quality. A regulator may also require the use of specific methods, tools, or documentation for eliciting, analyzing, or validating the requirements. The other options are not necessarily responsible for dictating the process or technique for requirements elicitation, although they may have some influence or preference. A project manager is a stakeholder who is responsible for planning, executing, monitoring, and controlling the project activities and resources. A project manager may collaborate with the business analyst to select the appropriate process or technique for requirements elicitation, but does not have the authority to dictate it. A functional management is a stakeholder who is responsible for the day-to-day operations of a specific function or department within the organization, such as finance, marketing, or human resources. A functional management may provide input or feedback on the requirements elicitation process or technique, but does not have the authority to dictate it. A project sponsor is a stakeholder who is responsible for initiating, funding, and supporting the project or the solution. A project sponsor may approve or endorse the requirements elicitation process or technique, but does not have the authority to dictate it. References:

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

Engaging Stakeholders in Elicitation and Collaboration, paragraph 4

Top 10 Most Common Requirements Elicitation Techniques, paragraph 2

A Review of Fundamental Tasks in Requirements Elicitation, paragraph 1

 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

Return on investment (ROI) is a measure of the profitability of an investment, calculated as the ratio of the net benefit to the total cost. The net benefit is the difference between the revenue and the cost. The total cost is the sum of the initial and ongoing costs. In this case, the ROI over the first 3 years can be computed as follows:

RevenueInitial costOngoing costTotal costNet benefitROI​=150,000×3=450,000=200,000=30,000×2=60,000=200,000+60,000=260,000=450,000−260,000=190,000=260,000190,000​×100%=73.08%​

Therefore, the projected ROI over the first 3 years is 73.08%, which is closest to option A. 44%. References: CBAP Handbook, CBAP Study Guide, Why should you be a CBAP in 2023

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.

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

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.

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

A Guide to the Business Analysis Body of Knowledge (BABOK Guide), version 3, section 4.2.3

Business Analysis Professional (CBAP) Certification Study Guide, version 3.0, page 131

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

References:

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 3: Requirements Elicitation, p. 97-98

[BABOK Guide v3], Section 4.1: Prepare for Elicitation, p. 94-95

Certified Business Analysis Professional™ (CBAP®) Specialization, Course 2: Business Analysis: Requirements Analysis and Design Definition, Week 2: Requirements Classification and Prioritization, Video: Requirements Abstraction Levels

future state will

be defined at a level of detail that:

• allows for competing strategies to achieve the future state to be identified

and assessed,

• provides a clear definition of the outcomes that will satisfy the business

needs,

• details the scope of the solution space,

• allows for value associated with the future state to be assessed, and

• enables consensus to be achieved among key stakeholders.

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 3, Chapter 5: Strategy Analysis, p. 176-177; Chapter 10: Root Cause Analysis, p. 356-359.

Business Analysis for Practitioners: A Practice Guide, Chapter 5: Requirements Analysis and Design Definition, p. 122-123, 129-130.

The type of project or initiative affects the business analysis duties that need to be performed, as different types of projects may require different approaches, techniques, deliverables, and stakeholders. For example, a software development project may have different business analysis needs than a business process improvement project. The business analyst should plan the business analysis process according to the project type and its characteristics, such as scope, complexity, risk, methodology, and lifecycle. References:

A Checklist for Business Analysis Planning

Business Analysis Process Flow: Step by Step Tutorial

What is Business Analysis? Process & Techniques

How do you plan a business analysis approach?

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

How to create a business analysis communication plan

How to Choose the Right Business Analysis Approach

Plan Business Analysis Approach - iiba.org

Defining the Business Analysis Approach in 2023 | Free Template

 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 bidders conference is a meeting that brings all of the potential vendors together to discuss the statement of work and the request for proposal. A bidders conference is an opportunity for the soliciting organization to clarify any questions or issues regarding the project, the requirements, the evaluation criteria, and the procurement process. A bidders conference also allows the potential vendors to network with each other and explore possible partnerships or subcontracting opportunities. A bidders conference is different from a contract bidding meeting, which is a meeting where the soliciting organization evaluates and selects the winning vendor. A bidders conference is also different from a status meeting, which is a meeting that provides updates on the progress and performance of a project. A bidders conference is not a qualified vendors meeting, which is a meeting that pre-qualifies vendors based on their capabilities and experience. References:

RFP: A Quick Guide to Request for Proposals (Templates Included), paragraph 8

How to Write a Statement of Work for Any Industry | Smartsheet, paragraph 9

50+ SAMPLE Vendor Request for Proposal in PDF, paragraph 3

The Ultimate RFP Guide: Steps, Guidelines & Template for Requests for …, paragraph 5

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

 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 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 change-driven approach to business analysis is one that adapts to the changing needs and priorities of the stakeholders and the business environment. It focuses on delivering business value in short iterations, rather than following a fixed and detailed plan. A change-driven approach is often associated with agile methodologies, such as Scrum, Kanban, or XP, which emphasize collaboration, feedback, and continuous improvement. A change-driven approach can help business analysts respond to uncertainty, complexity, and ambiguity, and deliver solutions that meet the customer’s expectations and satisfaction. References:

Defining Business Analysis, section 1.3.2, page 7

How to Choose the Right Business Analysis Approach, paragraph 4

Business Analysis Approach, paragraph 2

The Agile Business Analysis Approach Means…, paragraph 1

Defining the Business Analysis Approach in 2023, paragraph 2

When the number of stakeholders is too large or dispersed to involve them all in the requirements elicitation process, one possible approach is to use representatives or proxies. These are stakeholders who can act on behalf of a larger group of stakeholders and provide their input, feedback, and approval for the requirements. The representatives should be selected based on their knowledge, experience, authority, and availability. They should also communicate regularly with the group they represent and ensure that their views and needs are accurately reflected. Meeting with a small group of administrative assistants that will serve as representatives for the remaining administrative assistants can help to manage and gather requirements from these 2,400 administrative assistants in an efficient and effective way. References: BABOK Guide v3, page 51; CBAP / CCBA Certified Business Analysis Study Guide, page 159.

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

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

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

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

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

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

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

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

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

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

 An entity relationship diagram (ERD) is a graphical representation of how entities and relationships are organized in a database or a system. An ERD consists of three main components: entities, attributes, and relationships. Entities are the objects or concepts that store data, such as customers, products, or orders. Attributes are the properties or characteristics of entities, such as name, price, or quantity. Relationships are the associations or connections between entities, such as one-to-one, one-to-many, or many-to-many. Forks are not a component of an ERD, but rather a symbol used to represent a relationship type. A fork indicates that a relationship is either one-to-many or many-to-many, depending on the direction of the fork. For example, a fork pointing from an entity A to an entity B means that one instance of A can be related to many instances of B, while a fork pointing from an entity B to an entity A means that many instances of B can be related to one instance of A. References:

ER Diagram (ERD) - Definition & Overview | Lucidchart, paragraph 1-2

A Guide to the Entity Relationship Diagram (ERD) - Database Star, paragraph 1-2

ERD Templates | ER Diagram Examples | Moqups, paragraph 1

What is an Entity Relationship (ER) Diagram - Creately, paragraph 1

Components of an ER Diagram - TAE - Tutorial And Example, paragraph 1-2

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

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

 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

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

CBAP® Handbook, page 15, section 4.1.2.3

BABOK® Guide, page 32, section 3.2.3

How to Write a Business Case (Template Included), under Step 3: Calculate the Financials

A 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

Functional decomposition is a technique that breaks down a complex system or process into smaller and simpler parts, each with a specific function or purpose. By doing so, it helps to understand the structure, behavior, and functionality of the system or process, and to identify the requirements for each part. In this scenario, Ben is doing functional decomposition by taking the laser printer apart and documenting the purpose of each component. This can help him to improve the performance, quality, or efficiency of the laser printer by analyzing and optimizing each component’s function. References:

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

[CBAP Certification Study Guide v3.0], Chapter 6: Requirements Analysis and Design Definition, Section 6.3: Organize Requirements, page 2502

Project Management: Different Types of Requirement - Visual Paradigm, paragraph 4

 A procurement document is a document that is used to solicit proposals or quotations from potential suppliers or vendors of products or services for a project. A procurement document describes the problem or need, the desired solution, the evaluation criteria, and the contractual terms and conditions. A procurement document can be a request for proposal (RFP), a request for quote (RFQ), a request for information (RFI), or an invitation for bid (IFB). An invitation for bid (IFB) is a type of procurement document that is used to request bids from prospective sellers of products or services. An IFB describes the specifications, quantity, quality, and delivery schedule of the products or services. An IFB invites sellers to submit a sealed bid that indicates the cost of providing the products or services. An IFB is used when the buyer has a well-defined or standard problem or need, and wants to select the lowest bidder among the qualified sellers123. A project work breakdown structure (WBS) is not a procurement document, but a project management document. A WBS is a hierarchical decomposition of the project scope into smaller and manageable components. A WBS defines the deliverables, activities, and tasks that are required to complete the project4. A project charter is not a procurement document, but a project management document. A project charter is a document that formally authorizes the initiation of a project. A project charter defines the purpose, objectives, scope, assumptions, constraints, risks, stakeholders, roles, responsibilities, and authority of the project. A vision document is not a procurement document, but a business analysis document. A vision document is a document that describes the desired future state of a solution. A vision document defines the goals, benefits, features, and scope of the solution. References: CBAP® Handbook, CBAP® Exam Prep Study Guide, Project Management Institute, Project Work Breakdown Structure, [Project Charter], [Vision Document]

 A regulator is not a stakeholder that is considered when completing the business analysis planning and monitoring task to determine a business analysis approach. A regulator is an external entity that imposes rules, standards, or guidelines that the organization and the solution must comply with. A regulator is not directly involved in the business analysis process, but rather in the governance and validation of the solution. Therefore, a regulator does not influence the choice of the business analysis approach, which is based on the characteristics and needs of the project and the organization.

The other options are stakeholders that are considered when completing the business analysis planning and monitoring task to determine a business analysis approach. A tester is a stakeholder who verifies and validates the quality and functionality of the solution. A project manager is a stakeholder who oversees and coordinates the project activities, resources, and deliverables. A functional manager is a stakeholder who manages a specific business function or department, such as finance, marketing, or human resources. These stakeholders have different roles, responsibilities, expectations, and interests in the business analysis process, and they may affect or be affected by the choice of the business analysis approach. References:

BABOK® Guide, p. 29, 32, 66

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

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

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

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 6: Enterprise Analysis, page 215-216.

Business Capability Analysis: How to analyze capabilities, paragraph 3

ProjectManagement.com - Variance Analysis, paragraph 1

Which of the following techniques involves determining and documenting …, paragraph 1

 A plan-driven approach to business analysis is characterized by a high degree of upfront planning, detailed documentation, and formal processes. In this approach, the requirements are captured using standardized templates that provide a consistent and comprehensive format for describing the business needs, objectives, and specifications. The templates may include sections such as scope, assumptions, constraints, risks, acceptance criteria, and traceability. The templates are usually predefined by the organization or the project management office, and they help to ensure the quality, clarity, and completeness of the requirements. The templates also facilitate the communication, verification, and validation of the requirements among the stakeholders.

References:

Plan Business Analysis Approach - iiba.org, page 1

How to Choose the Right Business Analysis Approach, paragraph 4

Business analysis approach planning – The Functional BA, paragraph 2

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

 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.

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

According to the BABOK Guide, a change-driven approach to business analysis is characterized by frequent delivery of value to stakeholders, iterative planning and feedback, and adaptive responses to changing needs and priorities. In such an approach, communications are managed by focusing more on the frequency of communication and using face-to-face channels as much as possible. This helps to ensure that information is shared quickly and effectively, and that feedback loops are established and maintained. Formal communications are less emphasized in a change-driven approach, as they may slow down the delivery process and introduce unnecessary overhead. Ad hoc communications are not sufficient for managing change-driven projects, as they may lead to inconsistency, confusion, and missed information. References:

BABOK Guide, section 2.5.3, page 35

How to create a business analysis communication plan, paragraph 2

CBAP/CCBA/ECBA Certification Practice Test, question 8

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

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

A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 3, Chapter 10: Techniques, Section 10.50: SWOT Analysis

SWOT Analysis: How To With Table and Example - Investopedia

SWOT - Definition, Examples, Process, Uses - Corporate Finance Institute

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

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

The EA is interested in how the existing solution integrates with other data sources, such as the asset management system. Therefore, the requirement should specify how the incident records are linked to the equipment records in the asset management system. Option D does that by stating that the incident records use the Equipment ID as a foreign key to relate to the equipment records. Option A is too vague and does not indicate how the association is established. Option B implies that the incident records duplicate the equipment information, which is not desirable for data integrity and consistency. Option C does not specify where the Equipment ID comes from or how it is used to link the incident records to the equipment records. References:

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

CBAP / CCBA Certified Business Analysis Study Guide | Wiley, Chapter 6: Requirements Analysis and Design Definition, page 223.

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

References:

BABOK Guide v3, Section 3.2: Plan Business Analysis Approach, p. 48-49

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 2: Business Analysis Planning and Monitoring, p. 51-52

Certified Business Analysis Professional™ (CBAP®) Specialization, Course 1: Business Analysis: Planning and Communication, Week 2: Planning the Business Analysis Approach, Video: Planning the Business Analysis Work

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

Data mining is a technique that involves analyzing large data sets to discover patterns and trends that can provide useful information or insights123

The BA used data mining to find the source of the increase in claims by examining the documentation of the 1000 claims that were filed during the pilot period. The BA found that the majority of the claims were caused by severe winter storms in one region of the country, which were beyond the control of the customers.

Document analysis is a technique that involves reviewing and evaluating existing documents to elicit information and identify requirements.

The BA did not use document analysis to find the source of the increase in claims because this technique is more suitable for analyzing the content and structure of the documents, not the data within them.

Survey is a technique that involves collecting information from a sample of stakeholders using a predefined set of questions.

The BA did use survey to understand the customer feedback and preferences on the site and the promotions, but not to find the source of the increase in claims. The survey did not ask the customers about the reasons for their claims or the impact of the winter storms.

Decision modelling is a technique that involves defining and analyzing the criteria, options, and outcomes of a decision.

The BA did not use decision modelling to find the source of the increase in claims because this technique is more suitable for evaluating the alternatives and consequences of a decision, not the causes and effects of a problem.

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

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

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

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

Taking the natural logarithm of both sides, we get:

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

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

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

Using a calculator, we get:

Number of periods = 2.29

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

Number of months = 2.29 x 6

Number of months = 13.74

Rounding up to the nearest whole number, we get:

Number of months = 14

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

For retention, we have:

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

Repeating the same steps as above, we get:

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

Number of periods = 1.86

Number of months = 1.86 x 6

Number of months = 11.16

Rounding up to the nearest whole number, we get:

Number of months = 12

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

References:

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

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

Compound Growth Rate Calculator

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.

The business analyst (BA) will create a Data Model to meet Requirement ID FE10001, as it is related to the entity classification, specifically stating “The solution shall use the CrewContactID field as a primary key.” This requirement indicates the need for structuring data and defining how data elements are related, which is typically addressed through a Data Model. 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.

Business Analysis Professional (CBAP) Learning documents or resources available on IIBA’s official website and bookstore.

The BA should pause the activity and reiterate the rules to the entire group, as this is the best way to address the disruptive behavior and remind everyone of the purpose and objectives of the session. The BA should not continue the activity with the group and provide a report, as this would ignore the problem and potentially affect the quality and validity of the results. The BA should not reschedule the session without the Director of Human Resources, as this would exclude a critical stakeholder and create more resentment. The BA should not ask the Director of Human Resources to observe instead of participate, as this would also exclude a critical stakeholder and reduce the diversity of perspectives in the session. References:

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 9: Requirements Analysis and Design Definition, page 319

CBAP / CCBA Certified Business Analysis Study Guide | Wiley, Chapter 9: Requirements Analysis and Design Definition, page 319

Certified Business Analysis Professional™ (CBAP®) | Coursera, Course 3: Business Analysis: Requirements Analysis and Design Definition, Week 3: Requirements Analysis Techniques, Video: Brainstorming

Dependencies are the relationships among requirements that indicate that one requirement is reliant on another requirement for its implementation, verification, or validation. Dependencies can influence the prioritization of requirements, as some requirements may need to be implemented before others to ensure the functionality, quality, or feasibility of the solution. In this case, the requirement ‘parsing of data’ must be implemented before other requirements, which means that it has a dependency relationship with them. Therefore, the BA has given this requirement a high priority to reflect its importance and urgency. References: Prioritization techniques in business analysis, CBAP / CCBA Certified Business Analysis Study Guide, BABOK Guide

The BA should not simply adopt the structure of the solution consultants’ requirements catalog © or the corporate standard (D), because they may not be suitable for the branch’s specific needs and preferences. The BA should analyze the existing structures and compare them with the branch’s definitions of user roles, tasks, and features, as well as with the best practices for specifying customization requirements.

The BA should not devise a structure that best fits the branch’s definition of user roles (A), because this may not capture all the relevant aspects of the customization requirements, such as the system features, the user tasks, the dependencies, the constraints, the acceptance criteria, etc. The BA should consider all these factors and use a comprehensive and consistent structure that facilitates communication and understanding among the stakeholders.

The BA should explore and apply best practices for specifying this type of requirements (B), because this will help the BA to create a clear, complete, and accurate specification that meets the expectations of the sponsor, the solution consultants, and the PGA staff. The BA should also ensure that the structure of the specification is aligned with the branch’s standards and conventions, and that it supports the project objectives and scope.

The type of analysis that the BA has just conducted is impact analysis. Impact analysis is a technique that evaluates the potential effects of implementing a particular change in the existing business operations, in this case, changing the premiums and associated discounts offered to customers. Impact analysis helps to:

Assess the feasibility and viability of the proposed change

Identify the benefits and costs of the change for the organization and the stakeholders

Estimate the time and resources required to implement the change

Analyze the risks and issues associated with the change

Communicate and justify the change to the decision-makers and the affected parties

References:

[BABOK Guide v3], Section 6.2: Define Future State, p. 164-165

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 3: Strategy Analysis, p. 97-98

Certified Business Analysis Professional™ (CBAP®) Specialization, Course 3: Business Analysis: Strategy Analysis, Week 2: Define Future State, Video: Impact Analysis

Impact Analysis - How to Conduct an Impact Analysis in 5 Steps, Blog Post, June 2023

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

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

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

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

The BA should interview the domain subject matter expert and the end user to determine the changes needed to the comparison tool, as they are the ones who have the most knowledge and experience with the product specifications and the business needs. The domain subject matter expert can provide the BA with the technical and functional details of the product specifications, as well as the criteria and rules for comparing different versions. The end user can provide the BA with the feedback and expectations on the usability and value of the comparison tool, as well as the pain points and issues they face with the current tool. By interviewing these two stakeholders, the BA can elicit the requirements and design options for improving the comparison tool. 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. 25-26; Chapter 3: Elicitation and Collaboration, p. 57-58, 61-62.

Business Analysis for Practitioners: A Practice Guide, Chapter 3: Elicitation and Collaboration, p. 69-70, 73-74.

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

Interviews are a common and effective technique for eliciting requirements from stakeholders1234.

Interviews allow the BA to gain an in-depth understanding of the business needs and create the opportunity for a discussion and clarification on any statements made by the stakeholder5.

Interviews enable the BA to ask open-ended questions, probe for details, and uncover hidden or implicit requirements that the stakeholder may not be aware of or may not express otherwise124.

Interviews can also help the BA to establish rapport and trust with the stakeholder, which can facilitate the collaboration and communication throughout the project12.

Interviews can be used to verify facts, clarify ambiguity, trigger enthusiasm, engage end users, identify requirements and solicit opinions and ideas3.

The other options are not as good as option D because:

Option A is not a good approach because it assumes that the current solution is suitable for the PGA department without validating it with the actual users. Deploying the solution without eliciting user requirements may result in low user satisfaction, low adoption, and poor performance. Surveying users for improvement proposals after the deployment may be too late or too costly to implement changes.

Option B is better than option A, but it still relies on the assumption that the current solution can meet the PGA needs with minimal customization. Utilizing the solution in a test environment with actual data may help elicit some feedback, but it may not capture all the requirements or address all the issues that the users may have. Moreover, this approach may require more time and resources than conducting interviews.

Option C is also better than option A, but it may not be sufficient to collect the requirements from the sponsor and domain subject matter experts only. The sponsor may not represent the views and needs of all the users, and the domain subject matter experts may not be familiar with the current solution or the future state of the process. Collecting the requirements from a wider range of stakeholders, including the end users, can help ensure that the solution is aligned with the business goals and user expectations.

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.

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

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 2: Business Analysis Key Concepts, Section 2.4: Requirements Classification Schema, p. 66-67

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 2: Business Analysis Key Concepts, Section 2.4: Requirements Classification Schema, p. 34-35

 A purchase solution approach is one that involves acquiring a COTS software package from an external vendor or provider, rather than developing a custom solution in-house. A purchase solution approach can offer several benefits, such as faster delivery, lower cost, higher quality, and reduced risk. However, a purchase solution approach also has some drawbacks, such as limited customization, dependency on the vendor, compatibility issues, and licensing fees. A BA should evaluate the pros and cons of a purchase solution approach against the business needs and requirements, and compare it with other possible solution approaches, such as outsource, exploit, or create. References:

Evaluating Candidate COTS Packages, ArgonDigital

Seven Insights: Agile and Custom Off The Shelf (COTS) packaged software, Kenny & Company

COTS Software Procurement Methodology, IGI Global

Before the BA can proceed with any analysis of the features, they need to confirm that the feature requests are valid and aligned with the product vision and goals. Customer support calls may not reflect the actual needs and preferences of the target market, and may include requests that are out of scope or inconsistent with the product strategy. Therefore, the BA should first validate the feature requests with the product owner and other stakeholders, and eliminate any irrelevant or invalid ones. References:

BABOK Guide v3, section 7.2.2.1: “The business analyst validates that the requirements and designs are aligned with the business need and the solution scope.”

Guide to building a product roadmap (with template and examples), section “How to create a product roadmap”: “The first step in creating a product roadmap is to define the product vision. This is the overarching goal or purpose of the product, and it should guide all subsequent decisions and actions.”

The BA’s first step is to perform a gap analysis to understand the missing capabilities of the COTS tool and the existing manual processes. A gap analysis is a technique that compares the current state and the desired future state of a solution or a process, and identifies the gaps or differences between them. By performing a gap analysis, the BA can determine the feasibility, suitability, and risks of using the COTS tool to automate the existing manual processes, and identify the requirements and changes needed to bridge the gaps. The other options are not the first steps, as they may either be premature, unnecessary, or ineffective without a proper gap analysis. References:

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 5: Strategy Analysis, Section 5.1: Analyze Current State, p. 206

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 5: Strategy Analysis, Section 5.1: Analyze Current State, p. 106

Certified Business Analysis Professional™ (CBAP®) | Coursera, Course 3: Strategy Analysis, Week 2: Analyze Current State, video: “Gap Analysis”

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

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 6: Requirements Analysis and Design Definition, Section 6.3: Prioritize Requirements, p. 255-256

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 6: Requirements Analysis and Design Definition, Section 6.3: Prioritize Requirements, p. 155-156

The elicitation technique that the BA should select to enable the customer and the key stakeholders to visualize the final product is prototyping. Prototyping is a technique that involves creating a simplified or partial version of the solution that can demonstrate its features, functions, and appearance. Prototyping can help to elicit, validate, and verify the requirements, as well as to obtain feedback and approval from the stakeholders. Prototyping can also help to reduce the risks, costs, and time of the project by identifying and resolving any issues or gaps before the final implementation of the solution. References:

CBAP / CCBA Certified Business Analysis Study Guide, 2nd Edition, Chapter 4: Elicitation and Collaboration, Section 4.2: Conduct Elicitation, p. 167-168

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 3, Chapter 4: Elicitation and Collaboration, Section 4.2: Conduct Elicitation, p. 103-104

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

 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