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

A requirements traceability tool is a tool that provides combined functionality for business analysis and quality assurance activities. It helps to document and track the relationships and dependencies among the requirements, the sources of the requirements, and the project deliverables. It also helps to monitor the status, changes, and verification of the requirements throughout the project life cycle. A requirements traceability tool can also support the analysis, validation, and testing of the requirements, as well as the evaluation of the solution quality and performance12.

A functional specification tool is a tool that helps to define and document the functional requirements of a system or a solution. It describes the features, functions, behaviors, and inputs and outputs of the system or the solution. It also specifies the acceptance criteria and the expected results of the system or the solution. A functional specification tool is mainly used for business analysis activities, but not for quality assurance activities13.

A system use case modeling tool is a tool that helps to illustrate and communicate the interactions and scenarios between the users and the system or the solution. It uses diagrams, symbols, and text to represent the actors, use cases, relationships, and flows of events of the system or the solution. It also defines the preconditions, postconditions, and exceptions of each use case. A system use case modeling tool is mainly used for business analysis activities, but not for quality assurance activities14.

A solution quality assurance tool is a tool that helps to measure and evaluate the quality of the system or the solution. It uses various methods and techniques, such as testing, inspection, review, audit, and feedback, to check the quality of the system or the solution against the quality standards and criteria. It also identifies and reports any quality issues, defects, or errors of the system or the solution. A solution quality assurance tool is mainly used for quality assurance activities, but not for business analysis activities1 .

References: 1 PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline, page 9-11; 2 Business Analysis for Practitioners: A Practice Guide, page 121; 3 Business Analysis for Practitioners: A Practice Guide, page 133; 4 Business Analysis for Practitioners: A Practice Guide, page 135; Business Analysis for Practitioners: A Practice Guide, page 125

 A closed-ended survey using the Likert scale is a type of survey that asks respondents to indicate their level of agreement or disagreement with a series of statements related to the current business process. This type of survey is useful for gathering data that can be used in a statistical analysis to measure user satisfaction, identify pain points, and evaluate the performance of the current business process. A closed-ended survey is also easier to administer and analyze than an open-ended survey, which requires more time and effort to code and interpret the responses. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 17; Business Analysis for Practitioners: A Practice Guide2, page 91.

The next step that the business analyst should take after incorporating all the relevant feedback from stakeholders in the business analysis plan is to obtain approval on the plan. The business analysis plan is a document that describes how the business analysis activities will be performed, managed, and controlled throughout the project. It should be approved by the key stakeholders before the business analyst starts documenting or implementing the requirements. The approval process ensures that the stakeholders agree on the scope, approach, deliverables, roles, and responsibilities of the business analysis work. Starting documenting requirements without obtaining approval on the plan is not advisable, as it may lead to confusion, rework, or conflicts among the stakeholders. Storing the document for safe keeping is not a productive step, as it does not communicate or validate the plan with the stakeholders. Starting implementing the project without obtaining approval on the plan is not feasible, as it may result in wasted resources, missed expectations, or failed outcomes. References: Business Analysis for Practitioners: A Practice Guide 1, page 29-30; PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline 2, page 13.

The business analyst should check the traceability matrix to identify affected use cases. A traceability matrix can help the business analyst to find out which use cases are related to the new set of regulations, and how they will impact the scope, schedule, cost, quality, and risk of the project. The business analyst should also communicate the changes to the relevant stakeholders, and update the requirements documentation and the business analysis plan accordingly. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 20; Business Analysis for Practitioners: A Practice Guide2, page 100.

According to the PMI Guide to Business Analysis, the requirements baseline is a version of the requirements that has been formally reviewed and agreed upon by the stakeholders, and that serves as a basis for further development and validation activities. The requirements baseline is ready for sign-off when the requirements are clear, consistent, complete, and validated. These are the four characteristics of good requirements that ensure that they are understandable, unambiguous, accurate, and feasible. Complete means that the requirements cover all the necessary aspects of the business problem or opportunity, and that they do not have any gaps or omissions. Clear means that the requirements are expressed in simple and precise language, and that they avoid any jargon or ambiguity. Consistent means that the requirements do not have any conflicts or contradictions with each other or with the business objectives. Validated means that the requirements have been checked and confirmed by the stakeholders, and that they meet their needs and expectations. References: PMI Guide to Business Analysis, page 183-184.

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.

 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.

 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.

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

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.

The person identified in the RACI matrix as accountable for deployment approval is the one who should be contacted by the business analyst to review the testing results and get approval to proceed with deployment. The RACI matrix defines who is Responsible, Accountable, Consulted, and Informed for each task or deliverable in a project or a process. The accountable person has the authority and accountability to approve or reject the work. The tester identified in the testing strategy is not necessarily the one who can approve deployment, as they may only be responsible for conducting testing. The project manager identified in the project charter may not have the authority to approve deployment, as they may only be responsible for managing the project. The project sponsor identified in the scope document may not be involved in deployment approval, as they may only be informed of the project progress and outcomes.

 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.

 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.

 A requirements traceability matrix (RTM) is a tool that helps to track the relationship between the requirements and the product features. It can be used to determine the scope of a change request by identifying which requirements and test cases are affected by the modification of an existing feature. A project schedule and cost baseline are not directly related to the product features, but rather to the project management aspects. A requirements attributes table is a tool that helps to classify and prioritize the requirements, but it does not show the link between the requirements and the product features. A sequence diagram is a tool that helps to illustrate the interactions between the components of the product, but it does not show the traceability of the requirements. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, PMI Guide to Business Analysis2, Business Analysis for Practitioners: A Practice Guide

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

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.

A configuration management system is a tool that can be used to trace the large number of requirements that will be generated by this project. A configuration management system is a system that consists of the processes, procedures, tools, and databases that are used to manage and control the configuration items of the project. A configuration item is any component of the project that has a defined and approved version, such as a requirement, a deliverable, a document, a model, a test case, etc. A configuration management system can help the business analyst and the project team to record, track, update, and maintain the configuration items throughout the project lifecycle, and to ensure their consistency, integrity, and traceability. A configuration management system can also help to handle changes, resolve issues, and measure the quality and performance of the project. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 24; Business Analysis for Practitioners: A Practice Guide2, page 133.

According to the PMI Professional in Business Analysis objectives and content, a critical design review is a formal review that occurs after the completion of the design phase of a project. The purpose of a critical design review is to verify that the design specification meets the requirements and that the solution is feasible, cost-effective, and acceptable to the customer. A critical design review can help to establish an approved requirements baseline, which is a set of agreed-upon requirements that serves as a reference for further development and testing activities. 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: PMI.com

When a change request is received, the business analyst is responsible for analyzing the impact on business and underlying systems. The business analyst should assess how the change request will affect the business needs, objectives, and value, as well as the existing or planned systems, processes, and functions. The business analyst should also evaluate the feasibility, priority, and urgency of the change request, and provide recommendations and alternatives to the stakeholders. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 23; Business Analysis for Practitioners: A Practice Guide2, page 132.

 Acceptance criteria are the conditions that must be met for a solution or deliverable to be accepted by the stakeholders. Acceptance criteria should be measurable, testable, and clear, so that the team can verify if the requirements have been met or not. If the acceptance criteria for the requirements were not measurable, the team would have difficulty confirming if certain requirements have been met, as they would not have a clear and objective way to evaluate the solution or deliverable. The other options are not likely to cause this issue. The test engineer is not responsible for communicating requirements to the team, but for testing them against the acceptance criteria. Not all stakeholders need to be involved during requirements elicitation, as long as the key stakeholders who can provide relevant and accurate information are consulted. Requirements should be adequately reviewed with the project sponsor, but this does not affect the confirmation of meeting the requirements, as the sponsor is not the one who verifies them. References: PMI-PBA® Examination Content Outline, page 13; PMI-PBA® Reference List, page 1, BABOK® Guide v3, page 39.

 Prototyping is a tool or technique that could have been used by the business analyst to avoid the situation of unclear and conflicting requirements. Prototyping is the process of creating a simplified and partial version of the product or system that can be used to elicit, validate, and refine the requirements. Prototyping can help the business analyst and the stakeholders to visualize the solution, to identify and resolve any issues or gaps, and to reach a common understanding and agreement on the requirements. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 18; Business Analysis for Practitioners: A Practice Guide2, page 94.

 According to the PMI Professional in Business Analysis objectives and content, the business analyst should recommend the option with the highest functionality score and the lowest cost score. In this case, option A, 1, Custom solution, has the highest functionality score of 10 and the lowest cost score of 1. Therefore, it should be recommended. 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: PMI.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.

Verification is the process of ensuring that the requirements meet a quality checklist and conform to the specified standards, rules, and criteria. Verification can help the business analyst to ensure that all requirements meet a quality checklist before the development and testing phase by checking the completeness, correctness, clarity, consistency, and testability of each requirement. Verification can also help to identify and resolve any defects, errors, or ambiguities in the requirements. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline (2019), page 10; Business Analysis for Practitioners: A Practice Guide (2015), page 40.

Decision trees, weighted matrix, and context diagrams are tools and techniques that can help the business analyst to maximize business value while establishing the requirements baseline. Decision trees are graphical representations of possible outcomes and choices based on certain conditions or criteria. Decision trees can help to evaluate and select the best option among multiple alternatives based on their expected value or risk. Weighted matrix are tables that assign scores and weights to different factors or measures to compare and prioritize them. Weighted matrix can help to rank the requirements based on their alignment with the business objectives, benefits, costs, risks, dependencies, urgency, etc. Context diagrams are visual models that show the boundaries and interactions of a system or product with its environment. Context diagrams can help to define the scope and stakeholders of a project, as well as their needs and expectations. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline (2019), page 11-12; Business Analysis for Practitioners: A Practice Guide (2015), page 66-69.

 A RACI matrix is a tool that defines the roles and responsibilities of stakeholders in a project or a process. It clarifies who is Responsible, Accountable, Consulted, and Informed for each task or deliverable. The business analyst should refer to the RACI matrix to identify who is responsible for signoff, as this person has the authority and accountability to approve the solution and its testing results. Contacting the sponsor, the stakeholder who provided the majority of requirements, or the project manager may not be appropriate, as they may not be the designated person for signoff according to the RACI matrix. No signoff is necessary is incorrect, as signoff is an important step to confirm that the solution meets the requirements and acceptance criteria. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 13; Business Analysis for Practitioners: A Practice Guide2, page 77.

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.

According to the PMI Guide to Business Analysis, a data dictionary is a tool that defines and describes the data elements and their attributes in a consistent and standardized way. A data dictionary can help to minimize the risk of misunderstanding or misinterpreting data items mentioned in the requirements documents, as it provides a common language and reference for all stakeholders involved in the project. A data dictionary can also help to ensure the quality, accuracy, and completeness of the data requirements. Planning a peer review, asking for a formal acceptance, or holding a workshop are other ways to improve the clarity and understanding of the requirements specification, but they do not address the specific issue of defining and describing the data items. References: PMI Guide to Business Analysis, page 169-170.

 The MoSCoW technique is a prioritization technique that helps to rank requirements according to their importance and urgency. The acronym stands for Must have, Should have, Could have, and Won’t have. This technique can help the business analyst to manage requirements by focusing on the most critical ones and minimizing the scope creep. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline, page 19.

 The business analyst should clearly communicate project objectives and attempt to defuse tensions when there is concern that users may not accept a new product that forces them to change existing practices. Communication is a key skill for business analysts, as it helps to ensure that stakeholders understand the purpose, scope, benefits, and risks of the project and the solution. Communication also helps to manage stakeholder expectations, address their concerns, resolve conflicts, and gain their support and buy-in for the change. By communicating project objectives and trying to defuse tensions, the business analyst can demonstrate the value of the new product, explain the rationale behind the change, listen to the feedback and suggestions of the users, and foster a positive and collaborative relationship with them. Adhering to the project plan to achieve project objectives is not sufficient, as it does not address the user resistance or dissatisfaction with the new product. Voicing user concerns to management and recommending that the project be closed is not advisable, as it may undermine the project success and waste the resources invested in it. Delaying the application’s deployment until the conflicts have been resolved is not effective, as it may cause delays, rework, or scope creep in the project. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 9; Business Analysis for Practitioners: A Practice Guide2, page 55.

 A change control process is a set of procedures that defines how changes to the requirements are identified, assessed, approved, implemented, and communicated. A change control process helps to ensure that changes are aligned with the business objectives, do not introduce unnecessary risks, and do not adversely affect the quality of the solution. A change control process also helps to manage stakeholder expectations and avoid scope creep. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 13; Business Analysis for Practitioners: A Practice Guide2, page 77.

Version control is a technique that helps to manage changes to requirements and ensure that only authorized changes are made. It also helps to maintain a history of requirements changes, which records the date, reason, and impact of each change. Tracking the status of each requirement helps to monitor the progress and completion of requirements throughout the project life cycle. These practices help to ensure the integrity of requirements and avoid confusion, inconsistency, or ambiguity. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline (2019), page 8; Business Analysis for Practitioners: A Practice Guide (2015), page 38.

 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.

According to the PMI Guide to Business Analysis, a context diagram is a model that shows the boundaries of an area of analysis, such as a project, a system, a process, or an organization. A context diagram depicts the main entities or actors involved in the area of analysis, and the interactions or data flows between them. A context diagram can help to ensure the most effective representation of analysis boundary, as it provides a high-level overview of the scope and context of the area of analysis, and helps to identify the key stakeholders and their relationships. A context diagram can also help to communicate and validate the scope and context with the stakeholders, and to identify any assumptions or risks related to the area of analysis. A data flow diagram, a state diagram, and an entity relationship diagram are other models that can help to analyze an area of analysis, but they do not necessarily show the boundary or scope of it. References: PMI Guide to Business Analysis, page 158-159.

Functional specifications are a type of requirements documentation that describes what the system or product should do in terms of functions, features, behaviors, inputs, outputs, etc. Functional specifications can help the business analyst to document the requirements in a way that is clearly understood by the development team and provides enough information to check if the requirement has been met. Functional specifications can also include acceptance criteria, test cases, data models, user interface designs, etc. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline (2019), page 10; Business Analysis for Practitioners: A Practice Guide (2015), page 39.

 Team peer review is a technique that is used to identify ambiguous or unverifiable requirements. Team peer review is a technique that involves having a group of peers or experts examine and evaluate the requirements for quality, completeness, correctness, clarity, consistency, and testability. Team peer review can help to identify any ambiguous or unverifiable requirements that may cause confusion, misunderstanding, or errors in the project. Team peer review can also provide feedback and suggestions for improvement or resolution of any issues or defects in the requirements. Fishbone analysis is not a technique that is used to identify ambiguous or unverifiable requirements. Fishbone analysis is a technique that is used to identify the root causes of a problem or an effect by analyzing its contributing factors and their relationships. Fishbone analysis can help to understand why a problem exists or why an effect occurs, but it does not directly examine or evaluate the quality of the requirements. Resource checklist is not a technique that is used to identify ambiguous or unverifiable requirements. Resource checklist is a tool that is used to identify and document the resources needed to perform business analysis activities, such as people, tools, facilities, equipment, etc. Resource checklist can help to plan and manage the resources required for business analysis work, but it does not assess or verify the quality of the requirements. Traceability matrix is not a technique that is used to identify ambiguous or unverifiable requirements. Traceability matrix is a tool that is used to track and document the relationships and dependencies among requirements and other project elements, such as design, test cases, risks, issues, etc. Traceability matrix can help to monitor and control changes to requirements and ensure alignment with project objectives and stakeholder needs, but it does not measure or validate the quality of the requirements. References: Business Analysis for Practitioners: A Practice Guide 1, page 162-163; PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline 2, page 19-20.

 A use case is a technique that describes how an actor interacts with a system to achieve a goal or perform a task. A use case consists of a main scenario and possible alternative scenarios that capture the normal, exceptional, and error flows of events. A use case can be used as a source for building tests of end-to-end business processes across business functions and systems, as it provides a comprehensive and realistic view of the expected behavior and outcomes of the solution. A use case can also help to verify and validate the functional requirements and acceptance criteria of the solution. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 20; Business Analysis for Practitioners: A Practice Guide2, page 99.

 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.

External dependencies are the factors or conditions that are outside the control of the project, but may affect its scope, schedule, cost, quality, or risks. External dependencies may include legal, regulatory, cultural, environmental, political, economic, or technological factors. An organization that is evaluating the possibility of conducting business internationally should investigate these factors at the onset of the initiative, as they may have significant impacts on the feasibility, viability, and desirability of the project. The other options are not factors that should be investigated at the onset of the initiative. Deliverables to be produced are the outputs or results of the project that meet the stakeholder requirements. Impacts on requirements baseline are the changes or deviations from the approved set of requirements that define the solution scope. Change control processes are the procedures and tools that manage how changes to the project scope, schedule, cost, quality, or risks are identified, evaluated, approved, implemented, and communicated. These factors are determined or addressed during the planning or execution phases of the project, not at the onset of the initiative. References: PMI-PBA® Examination Content Outline, page 13; PMI-PBA® Reference List, page 1, BABOK® Guide v3, page 39; 4.

 MoSCoW is a requirements prioritization method that classifies requirements into four categories: Must have, Should have, Could have, and Won’t have. This method helps the business analyst and the stakeholders to agree on the essential requirements that must be delivered within a fixed time frame, and the desirable requirements that can be deferred or dropped if necessary. MoSCoW is suitable for this project because it allows the business analyst to focus on the minimum viable product that meets the business need of replacing the current enrollment and billing software application before the vendor contract ends, and to cope with the large volume of requirements by prioritizing them based on their value and urgency. 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 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

 Root cause analysis (RCA) is a technique that can be used to investigate the problem of increased call interval in a new call management system. Root cause analysis is a method of identifying and resolving the underlying causes of a problem or an issue, rather than treating the symptoms or the effects. Root cause analysis involves asking questions, collecting data, analyzing evidence, finding patterns, drawing conclusions, and recommending solutions. Root cause analysis can help to prevent recurrence of the problem, improve performance, reduce risks, and increase customer satisfaction. Interviews are a technique that can be used to elicit information from stakeholders, but they may not be sufficient to investigate the problem in depth and find its root causes. Observation is a technique that can be used to understand how stakeholders perform their work in their own environment, but it may not be able to explain why the problem occurs and what causes it. Process modeling is a technique that can be used to represent how activities are performed in a process, but it may not be able to identify and resolve the problem in the process. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 15; Business Analysis for Practitioners: A Practice Guide2, page 95.

Quality assurance is a function that involves applying quality standards and processes to ensure that the project or program meets the quality requirements and delivers the expected value to the stakeholders. Quality assurance also involves auditing the quality requirements and the results of quality control measurements to ensure that appropriate quality standards and operational definitions are being used. Quality assurance helps to prevent defects and errors, improve customer satisfaction, and enhance the credibility and reputation of the organization. References: PMI Guide to Business Analysis, Chapter 10, Section 10.3.1; PMI Professional in Business Analysis (PMI-PBA) ® Examination Content Outline, Domain V: Evaluation, Task 3.

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.

Business rules are statements that define or constrain some aspect of the business, such as policies, standards, procedures, regulations, or constraints. Business rules can be uncovered by asking about the reasons for choosing a particular course of action when modeling processes or analyzing tasks. By asking why a certain decision is made, what criteria are used, what conditions are applied, or what consequences are expected, the business analyst can elicit the business rules that govern the behavior or outcome of the process or task. Asking about tasks that overlap with each other, work that may be performed out of sequence, or task transitions that hinder organizational performance may help to identify issues or opportunities for improvement in the process or task, but they may not reveal the business rules that underlie them. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 15; Business Analysis for Practitioners: A Practice Guide2, page 95.

Requirements are statements of the needs, expectations, or conditions that must be met by a solution. Requirements should be clear, complete, consistent, and testable, so that they can be understood, verified, and validated by the stakeholders. If the requirements are not ready for peer review, it means that they have not met these quality criteria, and that they need to be refined or revised. One possible cause of this situation is that the requirements do not provide all of the information needed to define the work, such as the scope, objectives, deliverables, assumptions, constraints, risks, dependencies, etc. This would make it difficult for the peer reviewers to evaluate the feasibility, accuracy, and alignment of the requirements with the business needs and goals. The other options are not likely to cause this problem. Some requirements having not yet been discussed in a work group session is not a reason to delay the peer review, as long as the requirements have been elicited from the relevant sources and documented properly. The requirements’ reference codes not tracing to the attribute numbers in the work breakdown structure is a minor issue that can be easily fixed by updating the reference codes or the work breakdown structure. The requirements documents having not yet received sign-off from the sponsor is not a prerequisite for peer review, as sign-off is usually obtained after the peer review and validation process. References: PMI-PBA® Examination Content Outline, page 13; PMI-PBA® Reference List, page 1, BABOK® Guide v3, page 39.

 A requirements traceability matrix is a tool that shows the relationship between each requirement and other project elements, such as objectives, deliverables, test cases, design components, etc. A requirements traceability matrix can help the business analyst to determine the impact for the specific requirement change by showing how the change affects other related requirements and project elements. A requirements traceability matrix can also help to assess the feasibility, scope, value, and risk of the change request. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline (2019), page 10; Business Analysis for Practitioners: A Practice Guide (2015), page 40.

A requirements traceability matrix is a tool that links the requirements to their sources, objectives, and deliverables. It helps to track the status, changes, and verification of each requirement throughout the project life cycle. If the requirements traceability matrix was not updated with the change, it could result in a key requirement being missed or overlooked in the implementation. The other options are not likely to cause this problem. The requirements management plan is a document that describes how the requirements will be elicited, analyzed, documented, validated, and managed. The scope management plan is a document that describes how the project scope will be defined, controlled, and verified. The schedule management plan is a document that describes how the project schedule will be developed, monitored, and controlled. References: PMI-PBA® Examination Content Outline, page 13; PMI-PBA® Reference List, page 1, BABOK® Guide v3, page 39; 6.

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.

 A weighted-ranking matrix is a technique that involves assigning scores and weights to different criteria and options to compare and prioritize them. A weighted-ranking matrix can help the business analyst to prepare the recommendation by quantifying and ranking the three different solution options based on their alignment with the business objectives, benefits, costs, risks, and other factors. A weighted-ranking matrix can also help to justify and communicate the recommendation with evidence and transparency. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline (2019), page 11; Business Analysis for Practitioners: A Practice Guide (2015), page 66.

 According to the PMI Guide to Business Analysis, a requirements traceability matrix is a tool that helps to ensure that the requirements are aligned with the business needs and objectives, and that they are verified and validated throughout the project life cycle. A requirements traceability matrix can also help to identify gaps, redundancies, and inconsistencies in the requirements. If the requirements matrix did not adequately track back to client requirements, it could result in a product that does not meet the client’s expectations or specifications, even if it passes the test plan. Therefore, it is important to establish and maintain a clear and accurate traceability of requirements from their source to their implementation and verification. References: PMI Guide to Business Analysis, page 179-180.

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.

 Interviewing is a technique to elicit information, opinions, or feedback from stakeholders by asking them questions and listening to their responses. Interviewing can be used to clarify or validate requirements, resolve conflicts or misunderstandings, build rapport and trust, and explore complex or sensitive issues. A good time to consider using the interviewing method is when there are communication challenges among stakeholders, such as different perspectives, expectations, or interests. Interviewing can help to overcome these challenges by providing a direct and personal communication channel, allowing the interviewer to tailor the questions and responses to each stakeholder, and facilitating a deeper understanding of the stakeholder’s needs and concerns. The other options are not good times to consider using the interviewing method. Attempting to obtain sign-off on requirements from stakeholders is not an elicitation activity, but a validation activity that requires formal documentation and approval. There is not enough time to gather requirements from many different sources is a constraint that limits the use of interviewing, as it is a time-consuming and resource-intensive technique that can only involve a few stakeholders at a time. Assembling a requirements traceability matrix is not an elicitation activity, but an analysis activity that involves linking the requirements to their sources and deliverables using a tool or document. References: PMI-PBA® Examination Content Outline, page 10; PMI-PBA® Reference List, page 1, BABOK® Guide v3, page 50.

 Stakeholder analysis is a process of identifying and analyzing the stakeholders who have an interest or influence on the project and its outcomes. Stakeholder analysis helps to ensure that the requirements are elicited from all relevant sources and that the stakeholders are appropriately engaged throughout the project. By identifying the user from a department that did not participate in the requirements analysis as a stakeholder, the business analyst could have avoided the situation of logging a defect during user acceptance testing and minimized the impact on the project. Interviewing the user to understand how the user’s work would be impacted, involving the user in the development and sign-off of the business requirements, and giving the user the opportunity to review the user acceptance test scripts are possible actions that could be taken after identifying the user as a stakeholder, but they are not sufficient to avoid the situation and minimize the impact on the project. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 9; Business Analysis for Practitioners: A Practice Guide2, page 55.

 A user survey is a technique that can be used to determine how well the solution meets the business case. A user survey is a method of collecting feedback from the end users of the solution about their satisfaction, preferences, expectations, needs, problems, or suggestions. A user survey can help to measure the performance, quality, usability, and value of the solution and compare it with the expected benefits and outcomes defined in the business case. A user survey can also help to identify areas for improvement or enhancement of the solution. Asking the sponsor for feedback is not sufficient to determine how well the solution meets the business case, as it does not capture the perspective of the end users who are directly affected by the solution. Surveying the project is not relevant to this scenario, as it does not focus on the solution but rather on the project management processes and practices. Comparing the results of day-in-the-life (DITL) testing and integration testing is not effective, as it does not reflect the actual usage and experience of the solution by the end users after deployment. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 14; Business Analysis for Practitioners: A Practice Guide2, page 80.

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

The requirements sign-off is a process that involves obtaining the formal approval and acceptance of the requirements from the customer and other stakeholders. The requirements sign-off confirms that the requirements are clear, complete, correct, and consistent, and that they meet the customer’s needs and expectations. The requirements sign-off also establishes a baseline for the development and testing of the solution, and serves as a reference point for managing changes and resolving issues. The business analyst should first facilitate the requirements sign-off with the customer before the developers start development, to ensure that the requirements are agreed upon and validated by all parties, and to avoid rework, delays, and conflicts later in the project. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 18; Business Analysis for Practitioners: A Practice Guide2, page 92.