PMI PMI-PBA PMI Professional in Business Analysis Exam Practice Test

Decomposition is an analysis technique that breaks down a complex system, process, or problem into smaller and simpler components. It helps to identify the tasks, activities, functions, features, and requirements that are necessary to implement the deliverable. Decomposition also helps to organize, structure, and prioritize the components based on their dependencies and relationships. Organization, dependency, and interface are not analysis techniques, but rather aspects or results of decomposition . References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline, page 10; Business Analysis for Practitioners: A Practice Guide, page 131-132

 Solution scope is the set of features and functions that define the boundaries of the solution and align with the business requirements. Solution scope describes what will be included in and excluded from the new system, and helps to manage stakeholder expectations and avoid scope creep. The business analyst has defined the solution scope by working with project team members to define what will be included in and excluded from the new system. The other options are not correct. Solution design is the process of creating a detailed specification of how the solution will meet the requirements. Business requirements are the higher-level needs or goals of the organization or stakeholders that justify the project. Business case is a document that provides the justification for initiating a project based on its expected benefits, costs, and risks. References: PMI-PBA® Examination Content Outline, page 13; PMI-PBA® Reference List, page 1, BABOK® Guide v3, page 39.

 Engaging all stakeholders early in the requirements gathering phase is a good practice to ensure stakeholder satisfaction with the enhancement. By involving the stakeholders in the elicitation process, the business analyst can understand their needs, expectations, preferences, and constraints. By defining the acceptance criteria with the stakeholders, the business analyst can establish a clear and measurable definition of what constitutes a successful solution. Engaging all stakeholders early can also help to build trust, collaboration, and buy-in for the change. Requesting that the project manager identify all affected project stakeholders is not sufficient to ensure stakeholder satisfaction, as it does not involve direct communication with the stakeholders. Providing all signed-off project documentation to the stakeholders for information purposes only is not effective, as it does not allow for feedback or validation from the stakeholders. Soliciting feedback and adding requirements to the project backlog is not advisable, as it can lead to scope creep, rework, and delays. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 11; Business Analysis for Practitioners: A Practice Guide2, page 66.

A requirements traceability matrix (RTM) is a tool that helps to track the relationship between the requirements and the product features, test cases, and other artifacts. It can be used to ensure that all requirements have been met by verifying that each requirement has a corresponding feature, test case, and acceptance criterion. A RTM can also help to identify the risks associated with dependent requirements, but that is not its primary purpose. A RTM does not define a convention to map the requirements to their sources, but rather uses an existing convention or standard. A RTM does not address the responsibility owner for each requirement, but rather shows the status and priority of each requirement. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, PMI Guide to Business Analysis2, Business Analysis for Practitioners: A Practice Guide

The main reason for the business failure was a failure to establish measurable success criteria in the business case. The success criteria are the standards or indicators that are used to measure the achievement of the business objectives and the expected benefits of the project. The success criteria should be defined and agreed upon by the stakeholders in the business case, and they should be specific, measurable, achievable, realistic, and time-bound (SMART). The success criteria can help the business analyst and the project team to evaluate the feasibility, viability, and desirability of the project, and to monitor and control the project performance and outcomes. The success criteria can also help to ensure the alignment of the project deliverables with the stakeholder expectations and the market needs. If the success criteria are not established or are poorly defined in the business case, the project may fail to deliver the desired value and return on investment, even if it meets the time, cost, scope, and quality constraints. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 16; Business Analysis for Practitioners: A Practice Guide2, page 86.

The business analyst should use document analysis as an elicitation technique during this time. Document analysis is a technique that involves reviewing and analyzing existing documents, such as policies, procedures, standards, reports, or contracts, to elicit information about the business needs, requirements, or solution options. Document analysis is useful when the stakeholders are not available to participate, or when the business analyst needs to gain background knowledge or context before engaging with the stakeholders. Document analysis can also help to identify gaps, issues, or assumptions that need to be clarified or validated with the stakeholders later. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 12; Business Analysis for Practitioners: A Practice Guide2, page 51.

Time-boxing is a prioritization technique that involves allocating a fixed amount of time or resources to each requirement or backlog item. Time-boxing can help the business analyst to review the amount of work the team is capable of delivering based on the approved project schedule by setting deadlines and constraints for each requirement or backlog item. Time-boxing can also help to focus on the most valuable and feasible requirements or backlog items and avoid scope creep or gold plating. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline (2019), page 11; Business Analysis for Practitioners: A Practice Guide (2015), page 66.

A business requirement is a statement that describes a business need or problem that must be addressed by the project. It should be stated in terms of what the business wants to achieve or improve, not how it will be done. The requirement in the question states a solution (an API) rather than a business need (synchronizing name and address data). It should be revised to focus on the business need and avoid specifying a solution. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline (2019), page 7; Business Analysis for Practitioners: A Practice Guide (2015), page 35.

Clear and unambiguous requirements are crucial for verification. Ambiguity can lead to misunderstandings and difficulty in assessing whether the product meets the specified needs during testing. References: PMI-PBA® Examination Content Outline, Business Analysis for Practitioners: A Practice Guide.

According to the PMI Professional in Business Analysis objectives and content, an impact analysis is a technique that is used to assess the effects and implications of a change request on the requirements, scope, schedule, cost, quality, and other aspects of a project or product. An impact analysis can help to determine the feasibility, desirability, and priority of the change request, as well as to identify the risks, issues, and dependencies associated with the change. An impact analysis can also help to communicate the impact of the change to the stakeholders, and to support the decision-making process for approving or rejecting the change request. References:

PMI Professional in Business Analysis objectives and content: PMI-PBA Certification

PMI Professional in Business Analysis reference list: PBA Reference List

PMI Professional in Business Analysis study guide: Study.com

According to the PMI Guide to Business Analysis, user acceptance testing is a technique that involves verifying and validating that the solution meets the business requirements and satisfies the stakeholder needs and expectations. User acceptance testing is usually performed by the end users or their representatives, who evaluate the solution against predefined acceptance criteria and provide feedback on its functionality, usability, performance, quality, etc. User acceptance testing can help to determine whether a solution satisfies business requirements, as it can demonstrate that the solution delivers the intended business value and benefits, and that it meets or exceeds the stakeholder satisfaction. By reviewing the results of user acceptance testing, a business analyst can assess how well the solution meets business requirements, and identify any gaps or issues that need to be addressed or resolved. Evaluating the solution against the project charter, conducting a brainstorming session with end users, or reviewing the traceability matrix are other ways to analyze and validate requirements, but they do not necessarily determine whether a solution satisfies business requirements, as they do not involve testing or evaluating the solution in real or simulated conditions. References: PMI Guide to Business Analysis, page 317-318.

 According to the PMI Professional in Business Analysis objectives and content, one of the techniques to ensure consensus among stakeholders is to conduct a pre-review of the requirements with the key stakeholders before the formal review meeting. This can help to identify and resolve any issues, gaps, or conflicts that may arise during the meeting. A pre-review can also help to build trust and rapport with the stakeholders, and increase their confidence and commitment to the requirements. A pre-review can be done through interviews, workshops, surveys, or other methods of communication. References:

PMI Professional in Business Analysis objectives and content: PMI-PBA Certification

PMI Professional in Business Analysis reference list: PBA Reference List

PMI Professional in Business Analysis study guide: Study.com

The business analyst should communicate that the status of this requirement has changed to the relevant stakeholders, such as the project manager, the sponsor, the development team, and the quality assurance team. Communication is an essential skill for business analysts, as it helps to ensure that everyone involved in the project is aware of the current state of the requirements, the rationale behind any changes, and the impact of those changes on the project scope, schedule, budget, quality, and risks. Communication also helps to manage stakeholder expectations and avoid confusion or conflicts. Bringing the subsequent project to the change control board (CCB) is not necessary at this stage, as the requirement has been deferred and not added to another project. Asking the stakeholders to review the requirement before any other action is taken is not effective, as the requirement cannot be implemented until the needed information is available. Marking the requirement as complete so that it is not forgotten is incorrect, as it does not reflect the true status of the requirement and may cause errors or inconsistencies in the requirements documentation and traceability. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 13; Business Analysis for Practitioners: A Practice Guide2, page 77.

This is because it has the highest score in the “Lower maintenance cost” category, which has a weight of 2, and the second highest score in the “Improved customer satisfaction” category, which has a weight of 3. The weighted-ranking matrix is a technique that helps to compare and evaluate different options based on multiple criteria and their relative importance. Each option is assigned a score for each criterion, and the score is multiplied by the weight of the criterion. The option with the highest total score is the most preferred one.

 A requirements baseline document is the most valuable document for a business analyst to provide to the project sponsor to know which requirements will be implemented. A requirements baseline document is a version of the requirements specification that has been reviewed, approved, and formally established as the basis for further development and delivery of the solution. A requirements baseline document defines the scope of the project and the expected value of the solution. It also serves as a reference point for managing changes and measuring progress. A requirements traceability matrix is a document that shows the relationship between requirements and other project artifacts, such as design, test cases, or deliverables. A requirements traceability matrix can help to ensure completeness, consistency, and quality of the requirements, but it does not indicate which requirements will be implemented. A requirements management plan is a document that describes how requirements will be elicited, analyzed, documented, validated, and managed throughout the project. A requirements management plan can help to define the roles, responsibilities, processes, and tools for managing requirements, but it does not specify which requirements will be implemented. A reliability matrix is not a standard document in business analysis, but it may refer to a tool that measures the reliability or dependability of a system or a process. A reliability matrix can help to evaluate the performance or quality of a solution, but it does not determine which requirements will be implemented. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 13; Business Analysis for Practitioners: A Practice Guide2, page 76.

 A feasibility study is a technique that involves evaluating the viability and suitability of a proposed project or solution. A feasibility study can help the business analyst to define the scope of this project by assessing the technical, economic, legal, operational, and schedule aspects of designing and building three bridges within a limited time frame. A feasibility study can also help to identify the risks, benefits, costs, and assumptions associated with each bridge project. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline (2019), page 10; Business Analysis for Practitioners: A Practice Guide (2015), page 52.

Competitive analysis is a technique to compare the strengths and weaknesses of similar products or services offered by competitors in the same market. Competitive analysis can help to identify opportunities, threats, and gaps in the market, and to develop strategies to increase sales and customer satisfaction. Competitive analysis can be used to identify solutions for the startup company that sells organic vegetable and fruit smoothies by comparing their best-selling juice with similar products offered by competitors. The other techniques are not suitable for this purpose. Benchmarking is a technique to compare the performance of a product, service, or process with a standard or best practice. Trend analysis is a technique to analyze historical data or patterns to forecast future outcomes or behaviors. Focus group is a technique to elicit opinions, preferences, or feedback from a representative group of customers or users. References: PMI-PBA® Examination Content Outline, page 11; PMI-PBA® Reference List, page 1, BABOK® Guide v3, page 51.

 Agile is an approach to enable developers and product owners to be in constant communication so that changes or issues that occur during development are exposed and discussed as they develop. Agile emphasizes iterative and incremental delivery of value, collaboration, feedback, and adaptation. Agile methods include Scrum, Kanban, XP, and others. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline (2019), page 14; Business Analysis for Practitioners: A Practice Guide (2015), page 17.

 Inspection is a technique or tool that is used to obtain acceptance of the delivered product. Inspection is a process that involves examining and measuring the product or its components against the predefined standards, criteria, or specifications, to determine its quality, completeness, and correctness. Inspection can help the business analyst and the project team to identify and correct any defects, errors, or deviations in the product, and to ensure that it meets the requirements and the stakeholder expectations. Inspection can also help to obtain the formal approval and acceptance of the product from the customer and other stakeholders, and to confirm that the product is ready for delivery or deployment. Inspection can be done using various methods, such as reviews, walkthroughs, audits, or tests. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 21; Business Analysis for Practitioners: A Practice Guide2, page 101.

The system requirements verification matrix is a tool that helps to track the status of each requirement throughout the project lifecycle. It shows whether a requirement has been accepted, rejected, deferred, or implemented. The business analyst should have used this tool to record the reasons for rejection or deferral of any requirement, as well as the impact and resolution of such changes. This way, the business analyst can easily provide a list of rejected and deferred requirements to the project manager upon request. Setting up a change control board is not enough to track the number of rejections, as it does not provide a detailed record of each requirement’s status. Limiting the number of rejected requirements on the project is not a realistic or helpful approach, as some requirements may be invalid, incomplete, or conflicting and need to be rejected or deferred for the benefit of the project. Spending more time up-front reviewing the requirements may reduce the chances of rejections, but it does not guarantee that no requirement will be rejected or deferred later in the project. References: Business Analysis for Practitioners: A Practice Guide, page 161-162; PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline, page 19.

 According to the PMI Guide to Business Analysis, a use case is a technique that describes how an actor interacts with a system or a process to achieve a specific goal. A use case can help to prevent problems from occurring in the implementation of a new application, as it can capture the functional requirements and the expected behavior of the system or the process, as well as the exceptions and alternative flows. A use case can also help to design and execute test cases that cover all the possible scenarios and outcomes. In this case, a use case could have prevented the problem of a worker using a field that was not supposed to be used, as it could have specified the valid inputs and outputs for the report, and the actions and responses of the system or the process. Prototyping, diagrams, and document analysis are other techniques that can help to analyze and communicate requirements, but they do not necessarily prevent problems from occurring in the implementation of a new application, as they do not describe the interactions and outcomes of the system or the process in detail. References: PMI Guide to Business Analysis, page 165-166.

User acceptance testing (UAT) is a process that should be done by the business analyst after the software developers have delivered a completed solution and the quality assurance team has passed it. User acceptance testing is a process of verifying that the solution meets the requirements and expectations of the end users and delivers value to them. User acceptance testing involves preparing test cases, scenarios, or scripts based on the acceptance criteria, executing them with representative users or stakeholders, collecting feedback, identifying defects or issues, and obtaining sign-off or approval for deployment. User acceptance testing can help to ensure that the solution is fit for use, suitable for purpose, and aligned with business objectives. Evaluating the solution against the project charter is not necessary at this stage, as it does not involve testing or validation by the end users or stakeholders. Evaluating the solution with the sponsor(s) is not sufficient at this stage, as it does not capture the perspective of all relevant users or stakeholders who will use or benefit from the solution. Conducting performance testing is not relevant at this stage, as it is usually done by the quality assurance team before delivering the solution to ensure that it meets the non-functional requirements such as speed, reliability, scalability, etc. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 14; Business Analysis for Practitioners: A Practice Guide2, page 80.

 Gap analysis is a technique that contrasts the current and desired business views to analyze possible business changes. It identifies the gaps between the current state and the future state of the business and helps to prioritize the actions needed to close those gaps. Gap analysis can be used to assess the feasibility, scope, and value of a proposed change. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline (2019), page 10; Business Analysis for Practitioners: A Practice Guide (2015), page 52.

Interface modeling is a technique to describe how different components or systems interact with each other and exchange information. Interface modeling can be used to depict how the solution will work with all of the company’s systems by showing the inputs, outputs, and dependencies of each system. Interface modeling can help to identify potential integration issues, gaps, and conflicts among the systems. The other techniques are not suitable for this purpose. Data modeling is a technique to define the structure, format, and relationships of data. Rules modeling is a technique to define the logic, constraints, and policies that govern the behavior of the solution. Enterprise modeling is a technique to describe the structure, culture, and processes of an organization. References: PMI-PBA® Examination Content Outline, page 11; PMI-PBA® Reference List, page 1, BABOK® Guide v3, page 54.

 Prototyping is a technique that involves creating a simplified or partial version of the solution to elicit feedback from the stakeholders. Prototyping can help the business analyst to deal with a complex project with stakeholders who find it difficult to articulate their needs by providing a visual and interactive representation of the solution. Prototyping can also help to reduce requirements risk by validating or verifying the requirements, identifying gaps or errors, and resolving ambiguities or conflicts. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline (2019), page 12; Business Analysis for Practitioners: A Practice Guide (2015), page 69.

Requirements baseline is the approved version of the requirements document that serves as a reference point for further changes. Requirements can be changed after they are baselined through a defined process that involves submitting a change request, analyzing the impact of the change, obtaining approval from the stakeholders, updating the requirements document, and communicating the change to the project team and other affected parties. Requirements can be changed at any stage of the project life cycle as long as they follow the defined process. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline (2019), page 10; Business Analysis for Practitioners: A Practice Guide (2015), page 40.

The best course of action to take when the customer reports defects after implementation of the product is to compare reported defects with user acceptance test results. User acceptance testing (UAT) is a process of verifying that the solution meets the requirements and expectations of the end users and delivers value to them. User acceptance testing involves preparing test cases, scenarios, or scripts based on the acceptance criteria, executing them with representative users or stakeholders, collecting feedback, identifying defects or issues, and obtaining sign-off or approval for deployment. By comparing reported defects with user acceptance test results, the business analyst can determine whether the defects were already detected and resolved during UAT, whether they were missed or overlooked during UAT, or whether they emerged after UAT due to changes in the environment, configuration, data, or usage. This can help to assess the impact and severity of the defects and decide on the appropriate actions to address them. Escalating the issue to the project manager since the acceptance was given by the customer is not helpful, as it does not involve investigating or resolving the defects. Doing nothing since the solution is now the responsibility of the operations manager is not responsible, as it does not ensure customer satisfaction or solution quality. Involving the end users and planning a new round of acceptance tests to check the gaps is not feasible, as it may be costly, time-consuming, and disruptive to conduct another UAT after implementation. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 14; Business Analysis for Practitioners: A Practice Guide2, page 80.

Requirements management is a method for requirements change control. Requirements management is a process that involves planning, monitoring, and controlling the requirements and the solution throughout the project lifecycle. Requirements management can help the business analyst to ensure that the requirements are clear, complete, correct, and consistent, and that they align with the business needs and objectives. Requirements management can also help to handle changes to the requirements and the solution, and to communicate the impact and implications of the changes to the stakeholders. Requirements management can be done using various tools and techniques, such as a requirements management plan, a requirements traceability matrix, a change control system, and a configuration management system52. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline3, page 24; Business Analysis for Practitioners: A Practice Guide4, page 133.

 Documenting the source of each requirement in the requirements traceability matrix allows for easy identification of the requestor and facilitates communication with stakeholders. References: PMI-PBA® Examination Content Outline, Business Analysis for Practitioners: A Practice Guide.

Context diagrams are a technique that can be used to determine if requirements align to the product’s objectives. Context diagrams are a technique that involves creating a visual representation of the product and its interactions with its environment, such as other systems, processes, or stakeholders. Context diagrams can help to define and clarify the scope, boundaries, and interfaces of the product. Context diagrams can also help to verify that the requirements are consistent and compatible with the product’s objectives and value proposition. Five Whys is not a technique that can be used to determine if requirements align to the product’s objectives. Five Whys is a technique that involves asking a series of why questions to identify the root cause of a problem or an effect. Five Whys can help to understand and resolve the underlying issues or needs that drive the requirements, but it does not directly compare or evaluate the requirements against the product’s objectives. Activity network diagrams are not a technique that can be used to determine if requirements align to the product’s objectives. Activity network diagrams are a tool that involves creating a graphical representation of the sequence and dependencies of the activities or tasks in a project or a process. Activity network diagrams can help to plan and manage the schedule, resources, and risks of a project or a process, but they do not depict or assess the requirements or the product’s objectives. Business use cases are not a technique that can be used to determine if requirements align to the product’s objectives. Business use cases are a tool that involves describing and documenting how a stakeholder interacts with a system or a solution to achieve a specific goal or outcome. Business use cases can help to specify and communicate the functionality and behavior of a system or a solution, but they do not measure or validate the requirements or the product’s objectives. References: Business Analysis for Practitioners: A Practice Guide 1, page 78-79; PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline 2, page 16.

 The type of requirements that do not trace to a business need are out-of-scope requirements. Out-of-scope requirements are the requirements that are not related to the project scope, objectives, or deliverables, and that do not contribute to the solution of the business problem or opportunity. Out-of-scope requirements are usually identified and excluded during the requirements analysis and traceability processes, to avoid wasting time, resources, and effort on unnecessary or irrelevant features or functions. Out-of-scope requirements can be caused by various factors, such as unclear or changing business needs, conflicting or unrealistic stakeholder expectations, poor communication or elicitation techniques, or lack of validation or verification methods. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 18; Business Analysis for Practitioners: A Practice Guide2, page 92.

 According to the PMI Guide to Business Analysis, one of the best practices for managing changes to requirements is to communicate them to all relevant stakeholders and solicit their feedback before approving or rejecting the change request. This ensures that the impact of the change is understood and agreed upon by all parties, and that the change does not introduce any conflicts or inconsistencies with the existing requirements. By sharing the new requirements with all stakeholders and asking them to submit their comments before the meeting, the business analyst can facilitate a constructive discussion and reach a consensus on how to proceed with the change request. References: PMI Guide to Business Analysis, page 287-288.

 A change-driven approach is the approach that best aligns with the business need for an organization that prefers taking an exploratory approach to finding the solution that best meets the business need. A change-driven approach is an adaptive and iterative approach that embraces changes and feedback throughout the project lifecycle. It allows the organization to explore different options and alternatives for the solution and deliver value incrementally and frequently. A change-driven approach is suitable for projects that have high uncertainty, complexity, or volatility in the requirements or the environment. A plan-driven approach is not the approach that best aligns with the business need for an organization that prefers taking an exploratory approach to finding the solution that best meets the business need. A plan-driven approach is a predictive and sequential approach that follows a detailed plan and minimizes changes and deviations from the baseline. It requires the organization to have a clear and stable vision of the solution and deliver value at the end of the project. A plan-driven approach is suitable for projects that have low uncertainty, complexity, or volatility in the requirements or the environment. A waterfall approach is not the approach that best aligns with the business need for an organization that prefers taking an exploratory approach to finding the solution that best meets the business need. A waterfall approach is a type of plan-driven approach that divides the project into distinct phases and completes each phase before moving to the next one. It does not allow for any changes or revisions once a phase is completed. A waterfall approach is suitable for projects that have very simple, well-defined, and fixed requirements and solutions. An analytical approach is not the approach that best aligns with the business need for an organization that prefers taking an exploratory approach to finding the solution that best meets the business need. An analytical approach is a technique or a method for solving problems or making decisions based on data, logic, and reasoning. It does not refer to a specific project management or business analysis approach. References: Business Analysis for Practitioners: A Practice Guide 1, page 28-29; PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline 2, page 13.

Before beginning requirements elicitation, the business analyst should document how the relevant systems interact. This is an important activity that helps to understand the current state of the systems, their interfaces, dependencies, and data flows. It also helps to identify the gaps, issues, and opportunities for improvement in the systems. Documenting how the systems interact can be done using various techniques, such as system context diagrams, data flow diagrams, or interface analysis12.

Preparing the requirements traceability matrix, defining how the solution will be evaluated, and drafting a high-level data model are not activities that should be initiated before beginning requirements elicitation. These activities are part of the analysis, validation, and management of the requirements, and they should be done after the requirements have been elicited12.

References: 1 PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline, page 10-11; 2 Business Analysis for Practitioners: A Practice Guide, page 131-132

The decision-making process in the business analysis plan defines how decisions will be made regarding the requirements and the business analysis approach. It specifies the roles and responsibilities of the decision makers, the criteria and methods for making decisions, and the process for resolving conflicts and disagreements. Having a clear decision-making process can help the business analyst facilitate the requirements workshop and reach an agreement among the stakeholders with different points of view and priorities. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline, page 13.

Interface analysis is a technique to describe how different components or systems interact with each other and exchange information. Interface analysis can help to identify the inputs, outputs, and dependencies of each system, and to ensure that they are compatible and consistent with each other. Interface analysis can also help to detect potential integration issues, gaps, and conflicts among the systems. An organization that is in the process of replacing its current system should conduct interface analysis to facilitate a successful migration, as it would help to ensure that all current connections to other systems remain functional after the upgrade. The other options are not correct. Document analysis is a technique to review existing documents or records to elicit information or requirements. User interface analysis is a technique to design and evaluate how users interact with a system or product. Systems analysis is a technique to understand and model the structure, behavior, and functions of a system or process.

According to the PMI Guide to Business Analysis, a Pareto analysis is a tool that helps to prioritize problems or causes based on their frequency or impact. It is based on the Pareto principle, which states that 80% of the effects come from 20% of the causes. A Pareto analysis can help to identify the high-priority changes needed to improve a service by showing which problems or causes account for most of the complaints or dissatisfaction. A work breakdown structure analysis, a flowchart, and a cause-and-effect diagram are other tools that can help to analyze a service, but they do not necessarily help to prioritize the changes needed to improve it. References: PMI Guide to Business Analysis, page 145-146.

The rationale for each requirement is the justification or explanation of why the requirement is needed and how it supports the business objectives. It should include the reasons and assumptions behind the requirement, as well as any constraints or dependencies that affect it. The product vision and operational relationships are part of the business case, not the rationale. The stakeholder impact and design decisions are part of the analysis and solution evaluation, not the rationale. The functional relationships and work breakdown structure code are part of the solution scope and architecture, not the rationale. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline, page 17; Business Analysis for Practitioners: A Practice Guide, page 113.

 Interface analysis is a technique that should be used to analyze input to and output from the product for a large, highly complex project with significant risk. Interface analysis is a technique that involves identifying and specifying how different components of a product interact with each other or with external systems or users. Interface analysis can help to define and document the data flows, formats, protocols, rules, and behaviors of each interface. Interface analysis can also help to identify and mitigate any risks or issues related to compatibility, integration, interoperability, or usability of the product. System analysis is not a technique that should be used to analyze input to and output from the product for a large, highly complex project with significant risk. System analysis is a broad term that refers to various activities and techniques for studying, designing, developing, testing, or maintaining a system. System analysis can include interface analysis as one of its aspects, but it is not a specific technique for analyzing input to and output from the product. Dependency analysis is not a technique that should be used to analyze input to and output from the product for a large, highly complex project with significant risk. Dependency analysis is a technique that involves identifying and evaluating how different elements of a project or a product depend on each other or on external factors. Dependency analysis can help to determine the impact of changes, prioritize tasks, allocate resources, or manage risks. Dependency analysis can include interface analysis as one of its aspects, but it is not a specific technique for analyzing input to and output from the product. Risk analysis is not a technique that should be used to analyze input to and output from the product for a large, highly complex project with significant risk. Risk analysis is a technique that involves identifying and assessing potential threats or uncertainties that may affect a project or a product. Risk analysis can help to quantify or qualify risks, prioritize risks, plan responses, or monitor risks. Risk analysis can include interface analysis as one of its aspects, but it is not a specific technique for analyzing input to and output from the product. References: Business Analysis for Practitioners: A Practice Guide 1, page 78-79; PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline 2, page 16-17.

 The business analyst should trace the requirements and measure the impact of the requested changes on the existing delivery date. Tracing the requirements means identifying the source, dependencies, and relationships of the requirements, and ensuring their alignment with the business needs, objectives, and expectations. Measuring the impact of the changes means assessing how the changes will affect the scope, schedule, cost, quality, and risk of the project. These actions can help the business analyst and the project team to evaluate the feasibility and priority of the changes, and to communicate the implications and alternatives to the customer and other stakeholders. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 23; Business Analysis for Practitioners: A Practice Guide2, page 131.

Power/interest grid is a technique that involves plotting the stakeholders on a matrix based on their level of power and interest in the project. Power/interest grid can help the business analyst to identify and categorize the stakeholders during the initial phase of a project by showing how influential and engaged each stakeholder is. Power/interest grid can also help to determine the appropriate communication and engagement strategy for each stakeholder group. References: = PMI Professional in Business Analysis (PMI-PBA) ® Examination Content Outline (2019), page 9; Business Analysis for Practitioners: A Practice Guide (2015), page 61.

 The business analyst should conduct a stakeholder analysis and balance requirements by understanding the relative power associated with each stakeholder group. This action will help the business analyst to identify and prioritize the needs and expectations of different stakeholders, and to manage any conflicts or trade-offs among them. The business analyst should also consider the alignment of the requirements with the project objectives and the business value. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 9; Business Analysis for Practitioners: A Practice Guide2, page 38.

 Active observation is an elicitation technique that involves observing the work performed by stakeholders in their own environment and asking questions to clarify or confirm the understanding of the process. Active observation allows the business analyst to gain insights into the current state, identify gaps or issues, and discover undocumented or implicit requirements. Active observation is different from participatory observation, which involves performing the work alongside the stakeholders, and from interview, which involves asking structured or unstructured questions to elicit information from stakeholders. Simulation is an elicitation technique that involves creating a model or a prototype of the solution or a part of it and using it to elicit feedback from stakeholders. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 10; Business Analysis for Practitioners: A Practice Guide2, page 62.

 An organizational chart is a tool that helps to visualize the structure and hierarchy of an organization, as well as the roles and responsibilities of its members. It can also show the relationships and interactions between different units, departments, or teams within the organization. An organizational chart can help the business analyst to identify the missing project stakeholders by showing who are involved in or affected by the online ordering system, such as the purchasing department. A business case is a tool that helps to justify the need and value of a project or initiative, as well as the costs and benefits associated with it. It does not provide information about the project stakeholders. A business analysis plan is a tool that helps to define the scope, approach, activities, deliverables, and schedule of the business analysis work. It does not provide information about the project stakeholders. A business analyst communication plan is a tool that helps to determine the communication needs, methods, frequency, and channels for the business analysis work. It does not provide information about the project stakeholders. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, PMI Guide to Business Analysis2, Business Analysis for Practitioners: A Practice Guide3, Organizational Chart - What is an Organization Chart? Definition, Types, Tips, Tutorial, and Examples

The business analyst should follow the change control process to handle the new regulatory mandate that affects the project. The change control process is a set of procedures that defines how changes to the requirements or the project scope are identified, analyzed, approved, and implemented. The change control process helps to ensure that changes are aligned with the business need, the project objectives, and the stakeholder expectations. References: PMI Guide to Business Analysis, Chapter 9, Section 9.4.1; PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline, Domain IV: Traceability and Monitoring, Task 2.

A review is a technique that involves examining a work product, such as requirements, to identify errors, omissions, inconsistencies, or ambiguities. A review can be formal or informal, depending on the level of rigor and documentation required. A review can be conducted by the business analyst alone or with other stakeholders, such as the project manager, the sponsor, the subject matter experts, or the end users. A review can be done through various methods, such as reading, walkthroughs, inspections, or peer reviews. The purpose of a review is to ensure that the requirements are clear, complete, correct, and consistent, and that they meet the quality standards and expectations of the stakeholders. By conducting a review, the business analyst can obtain approval from the stakeholders and confirm their agreement and commitment to the requirements. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 23; Business Analysis for Practitioners: A Practice Guide2, page 131.

The business analyst could use the expected vs. actual results technique to iteratively validate the solution. This technique involves comparing the expected results or outcomes of the solution with the actual results or outcomes that are observed or measured after the solution is implemented. This technique helps to verify that the solution meets the requirements and the acceptance criteria, and to identify any gaps, issues, or defects that need to be resolved or corrected. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 25; Business Analysis for Practitioners: A Practice Guide2, page 141.

The customer and the business analyst are collaborating in the development of a solution scope, which is a description of the boundaries, assumptions, and deliverables of the solution that will address the business need. It is important for the customer to spend the time required to provide, clarify, and elaborate requirements, because requirements are the basis for defining the solution scope. Requirements are the capabilities, features, functions, and qualities that the solution must have or meet to satisfy the customer and the stakeholders. By providing, clarifying, and elaborating requirements, the customer can help the business analyst to understand the problem, the needs, the expectations, and the value proposition of the solution. This will enable the business analyst to define a solution scope that is aligned with the customer’s vision and goals, and that is feasible, viable, and desirable. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline, page 15.

 Moscow analysis is a tool or technique that the business analyst can use with the stakeholders to prioritize the requirements to determine which requirements are approved, deferred, or rejected. Moscow analysis is a method of categorizing requirements into four groups: must-have, should-have, could-have, and won’t-have. Must-have requirements are essential and non-negotiable for the project success. Should-have requirements are important but not critical for the project success. Could-have requirements are desirable but not necessary for the project success. Won’t-have requirements are out of scope or low priority for the current project. Moscow analysis can help to identify the most valuable and feasible requirements that can be delivered within the available time and budget. It can also help to manage stakeholder expectations and resolve conflicts or disagreements on the priority of the requirements. SMART goals is a tool or technique that can be used to define clear and measurable objectives for a project or a process, but it does not help to prioritize the requirements. SMART goals are specific, measurable, achievable, relevant, and time-bound. SWOT analysis is a tool or technique that can be used to assess the strengths, weaknesses, opportunities, and threats of a project or a process, but it does not help to prioritize the requirements. SWOT analysis can help to identify the internal and external factors that affect the project or process performance and quality. Timeboxing analysis is not a standard tool or technique in business analysis, but it may refer to a method of allocating a fixed amount of time for each task or activity in a project or a process, but it does not help to prioritize the requirements. Timeboxing analysis can help to manage time and resources efficiently and effectively. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 15; Business Analysis for Practitioners: A Practice Guide2, page 95.

 The change control process is a set of procedures and tools that are used to manage changes to the requirements and the solution throughout the project life cycle. The change control process is defined in the business analysis plan, which is a document that describes how the business analysis activities will be performed, monitored, and controlled. The business analysis plan also specifies the roles and responsibilities of the business analyst and other stakeholders involved in the change control process. The business analyst should follow the change control process as defined in the business analysis plan to ensure that any changes to the requirements are properly documented, analyzed, approved, communicated, and implemented. By following the change control process, the business analyst can avoid scope creep, maintain the quality and integrity of the requirements, and align the solution with the business needs and objectives. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 24; Business Analysis for Practitioners: A Practice Guide2, page 133.

A requirements baseline is a set of approved requirements that serves as the basis for further development and validation. A requirements baseline approval form is a document that records the formal acceptance of the requirements baseline by the customer and other stakeholders. Creating a requirements baseline approval form for the customer to review and approve is the best action to take to establish an approved requirements baseline with the customer. The other actions are not sufficient or appropriate for this purpose. A requirements traceability matrix is a tool that links the requirements to their sources, objectives, and deliverables, but it does not record the approval of the requirements. Requesting that the customer create a baseline of the requirements in the contract specification is not a proactive or collaborative approach. Performing a variance analysis on the design specification and reporting the results to the customer is not relevant to establishing an approved requirements baseline. References: PMI-PBA® Examination Content Outline, page 13; PMI-PBA® Reference List, page 1, BABOK® Guide v3, page 39.

 Using a table to map business rules to functional requirements ensures that all tax and fee calculations are implemented correctly. It helps in verifying that the system reflects current regulations and avoids calculation errors. References: PMI-PBA® Examination Content Outline, Business Analysis for Practitioners: A Practice Guide.

Status is a critical field that is needed to ensure that the traceability matrix is usable. Status indicates the current state of each requirement, such as approved, deferred, implemented, tested, or verified. Status helps to track the progress and completion of requirements throughout the project life cycle. It also helps to identify any gaps or discrepancies that may exist between the requirements and the project deliverables. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline (2019), page 10; Business Analysis for Practitioners: A Practice Guide (2015), page 40.

When a business analyst uses subject matter experts to define roles and identify influencers, the project artifact that is created or updated is the stakeholder register. The stakeholder register is a document that identifies and records information about the stakeholders who are involved in or affected by the project or the solution. The stakeholder register can include information such as stakeholder names, roles, responsibilities, interests, expectations, influence levels, communication preferences, etc. The business analyst can use subject matter experts as sources of information or advice to help define roles and identify influencers among the stakeholders. Subject matter experts are individuals who have specialized knowledge or expertise in a specific domain or area related to the project or the solution. A RACI matrix is not a project artifact that is created or updated when a business analyst uses subject matter experts to define roles and identify influencers. A RACI matrix is a tool that defines and clarifies the roles and responsibilities of each stakeholder for each task or deliverable in the project. A RACI matrix can use four categories: Responsible (who performs the task), Accountable (who approves or oversees the task), Consulted (who provides input or feedback for the task), and Informed (who is notified of the task outcome). A SWOT analysis is not a project artifact that is created or updated when a business analyst uses subject matter experts to define roles and identify influencers. A SWOT analysis is a technique that involves identifying and evaluating the strengths, weaknesses, opportunities, and threats of an organization, a project, or a solution. A SWOT analysis can help to assess the internal and external factors that may affect the performance or value of an organization, a project, or a solution. A stakeholder management plan is not a project artifact that is created or updated when a business analyst uses subject matter experts to define roles and identify influencers. A stakeholder management plan is a document that describes how the stakeholders will be engaged, communicated with, managed, and satisfied throughout the project lifecycle. A stakeholder management plan can include strategies, actions, tools, and metrics for stakeholder management. References: Business Analysis for Practitioners: A Practice Guide 1, page 34-35; PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline 2, page 14-15.

 The requirements baseline is a document that contains the approved and validated requirements that are used as the basis for developing the solution. The requirements baseline defines the scope and boundaries of the product development, as it specifies what the product must do, what features and functions it must have, and what criteria it must meet to satisfy the stakeholders’ needs and expectations. The requirements baseline also serves as a reference point for measuring the progress and performance of the product development, as well as for managing changes and resolving issues. The requirements baseline is established after the requirements have been elicited, analyzed, prioritized, and verified by the business analyst and the stakeholders, and it is formally approved by the project sponsor or other authorized person. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 18; Business Analysis for Practitioners: A Practice Guide2, page 92.

An entity relationship diagram (ERD) is a type of requirements document that would be most valuable to a database administrator. An ERD is a graphical representation of data entities and their relationships in a database. An ERD shows how data is organized, stored, accessed, and manipulated in a database. An ERD can help to design, document, and communicate a database schema. A data flow diagram (DFD) is a graphical representation of how data flows through a system or a process. A DFD shows where data comes from, where it goes, how it is transformed, and what it is used for. A DFD can help to analyze, design, or improve a system or a process. A business process diagram (BPD) is a graphical representation of how activities are performed by actors in a business process. A BPD shows who does what, when, where, why, and how in a business process. A BPD can help to model, document, or optimize a business process. An object diagram is a graphical representation of objects and their relationships in an object-oriented system. An object diagram shows how objects interact with each other through messages or operations. An object diagram can help to illustrate or test an object-oriented design. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 15; Business Analysis for Practitioners: A Practice Guide2, page 95.

 Quality function deployment (QFD) is a technique that involves translating customer needs or requirements into product features or specifications. QFD helps to relate the product features to customer value by using a matrix called a House of Quality, which shows how each feature satisfies a customer requirement, how important each requirement is to the customer, how well each feature performs compared to competitors, and how each feature affects other features. QFD can also help to identify gaps or opportunities for improvement in the product design. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline (2019), page 12; Business Analysis for Practitioners: A Practice Guide (2015), page 69.

The workflow trigger that the business analyst should incorporate is any change to the requirements matrix. This trigger would ensure that the appropriate stakeholders are notified of any updates, additions, deletions, or modifications to the requirements that affect the business analysis repository. Changes to test cases traced to requirements, change through project life cycle, and changes to stakeholder memberships are not relevant triggers for the notification workflow, as they do not directly affect the requirements matrix. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, PMI Guide to Business Analysis2, Business Analysis for Practitioners: A Practice Guide

 Interviewing stakeholders to clearly define the problem is the most important action to contribute to the success of the initial stage of the project. Interviewing is an elicitation technique that involves asking questions to stakeholders to gather information about their needs, expectations, issues, and goals. Defining the problem clearly helps to establish the business need, the project scope, and the solution approach. References: PMI Guide to Business Analysis, Chapter 6, Section 6.3.2.5; PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline, Domain I: Needs Assessment, Task 2.

According to the PMI Professional in Business Analysis objectives and content, a subject matter expert (SME) is a person who has specialized knowledge or skills in a particular domain or area. A SME can provide valuable insights, information, and guidance to the project team, especially when the project involves a new or unfamiliar market. By hiring external SMEs for the core project team, the business analyst can help to ensure that the project has the necessary expertise and resources to perform the business analysis activities effectively and efficiently. External SMEs can also help to identify and validate the business needs, requirements, and solutions for the new market, and to reduce the risks and uncertainties associated with the project. References:

PMI Professional in Business Analysis objectives and content: PMI-PBA Certification

PMI Professional in Business Analysis reference list: PBA Reference List

PMI Professional in Business Analysis study guide: Study.com