PMI-PBA PMI Professional in Business Analysis Questions and Answers

Communication is an essential part of requirements management, as it ensures that the requirements are clear, consistent, and agreed upon by all the project stakeholders. Stakeholders are the individuals or groups who have an interest or influence in the project, and who can provide input, feedback, and approval for the requirements. Communication also helps to avoid surprises, misunderstandings, and conflicts among the stakeholders, and to manage their expectations and satisfaction. Communication should be timely, accurate, relevant, and transparent, and should follow the communication plan and strategy defined in the requirements management plan12.

One of the aspects of communication is the status of the requirements, which indicates the progress and completion of the requirements throughout the project life cycle. The status of the requirements can be tracked and documented using a traceability matrix, which is a tool that links the requirements to their sources and traces them throughout the project. The status of the requirements can also be monitored and controlled using a change control process, which is a process that evaluates, approves, and implements any changes to the requirements. The status of the requirements can have different values, such as proposed, approved, implemented, verified, deferred, deleted, or rejected12.

When the status of a requirement changes, it should be communicated to all the project stakeholders, not just the source of the requirement or the project team. This is because the change in the status of a requirement may have an impact on the scope, schedule, cost, quality, or risk of the project, and may affect the interests or expectations of the stakeholders. Communicating the status of the requirements to all the project stakeholders helps to keep them informed and engaged, and to obtain their feedback and approval. It also helps to prevent surprises, such as the one experienced by the major stakeholder in the question, who was unaware that a particular requirement was deferred12.

Therefore, the best option is C. The status should have been communicated to all project stakeholders. Option A is not the best option, because the status should have been communicated to more than just the requirement’s source. Option B is not the best option, because the status should have been communicated earlier than prior to project launch. Option D is not the best option, because updating the status in the traceability matrix is not enough, as the stakeholders may not have access to or awareness of the matrix. References: 1 PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline, page 9-11; 2 Requirements Management 101 | Smartsheet 2

 The business analyst will need to use the product scope as an input to the business case. The product scope is the description of the features, functions, and characteristics of the product, service, or result that the project will deliver. The product scope helps to define the business problem or opportunity, the desired outcomes, and the benefits of the solution. The product scope also helps to identify the assumptions, constraints, risks, and dependencies that may affect the project feasibility and viability. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 9; Business Analysis for Practitioners: A Practice Guide2, page 36.

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

Root cause analysis is a technique that involves identifying and analyzing the underlying causes of a problem or an issue. Root cause analysis can help the business analyst to determine how the selection criteria requirement was missed, and to prevent similar errors from occurring in the future. Root cause analysis can be done using various tools, such as fishbone diagram and the Five Whys. A fishbone diagram is a graphical tool that organizes the possible causes of a problem into categories, such as people, process, technology, environment, etc. A fishbone diagram can help the business analyst to visualize the relationships between the causes and the effects, and to identify the most likely root causes. The Five Whys is a questioning technique that involves asking “why” repeatedly until the root cause of a problem is revealed. The Five Whys can help the business analyst to drill down into the details of the problem, and to uncover the underlying factors and assumptions that led to the missed requirement. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 21; Business Analysis for Practitioners: A Practice Guide2, page 101.

 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.

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

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

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.

The business analyst is using a bottom-up estimation technique, which involves breaking down the work into smaller components and estimating the time and resources needed for each component. Then, the estimates are aggregated to obtain the total estimate for the project. Bottom-up estimation is more accurate and reliable than other techniques, but it also requires more time and effort. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 15; Business Analysis for Practitioners: A Practice Guide2, page 85.

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.

 A product scope is a description of the features, functions, and characteristics of a product that meets the needs and expectations of the stakeholders. It defines what the product is and what it is not, and provides the basis for planning, developing, testing, and delivering the product. A product scope should align with the company’s objectives, which are the desired outcomes or results that the company wants to achieve through its products, services, and projects. Aligning the product scope with the company’s objectives helps to ensure that the product delivers value to the customers and the business, supports the company’s vision and mission, and contributes to the company’s strategic goals12.

To collaborate on a product scope that aligns with the company’s objectives, the business analyst should follow these steps12:

Identify and engage the relevant stakeholders, such as the human resources, engineering, and marketing departments, as well as the product sponsor, the customers, and the end users. Stakeholders are the individuals or groups who have an interest or influence in the product, and who can provide input, feedback, and approval for the product scope.

Elicit and analyze the business needs, requirements, and expectations of the stakeholders, using various techniques, such as interviews, surveys, workshops, observation, prototyping, and brainstorming. Business needs are the problems or opportunities that the product aims to address or exploit, and that justify the investment in the product. Requirements are the specifications or conditions that the product must meet or satisfy to fulfill the business needs. Expectations are the desires or wishes that the stakeholders have for the product, which may or may not be realistic or feasible.

Validate and prioritize the business needs, requirements, and expectations, based on their value, urgency, risk, dependency, and alignment with the company’s objectives. Validation is the process of ensuring that the business needs, requirements, and expectations are clear, complete, correct, consistent, and feasible. Prioritization is the process of ranking the business needs, requirements, and expectations according to their relative importance and impact on the product scope and the company’s objectives.

Define and document the product scope, using various tools, such as a product vision statement, a product scope statement, a product backlog, a product roadmap, and a product breakdown structure. A product vision statement is a brief and compelling description of the purpose, value proposition, and target market of the product. A product scope statement is a detailed and formal description of the product scope, including the product objectives, deliverables, features, functions, boundaries, assumptions, constraints, and acceptance criteria. A product backlog is a list of the product requirements, features, and enhancements that are prioritized and refined for development. A product roadmap is a high-level and strategic plan that shows the direction, timeline, and milestones of the product development. A product breakdown structure is a hierarchical and graphical representation of the product components and their relationships.

Communicate and manage the product scope, using various techniques, such as reviews, walkthroughs, inspections, audits, and change control. Communication is the process of sharing and exchanging the product scope information with the stakeholders, and ensuring that they understand and agree on the product scope. Management is the process of monitoring and controlling the product scope, and ensuring that it is delivered according to the plan and the company’s objectives. Change control is the process of evaluating, approving, and implementing any changes to the product scope, and ensuring that they are aligned with the company’s objectives.

Voting on the product’s highest-value business needs is not the best option, because it may not consider the perspectives and preferences of all the stakeholders, and it may not reflect the company’s objectives. Negotiating to best meet each department’s objectives is not the best option, because it may result in compromises or trade-offs that may not benefit the product or the company as a whole, and it may not align with the company’s objectives. Delegating the decision to be made by the product sponsor is not the best option, because it may not involve the participation and collaboration of the other stakeholders, and it may not align with the company’s objectives. References: 1 PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline, page 10-11; 2 Business Analysis for Practitioners: A Practice Guide, page 133-134

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.

 Communication is a technique that involves exchanging information and feedback with stakeholders throughout the project life cycle. Communication can help the business analyst to deal with conflicting requirements by informing the stakeholders about the nature, cause, and impact of the conflict, and facilitating a resolution that satisfies their needs and expectations. Communication can also help to prevent or reduce future conflicts by establishing clear and consistent channels, methods, and frequency of communication. 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 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 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.

A test case is a set of conditions or variables under which a tester will determine whether a system under test satisfies the requirements or works correctly. A test case is derived from the requirements and the acceptance criteria, and it specifies the input data, expected output, and execution steps. A test case is incorrect if it does not match the requirements or the acceptance criteria, or if it contains errors, ambiguities, or inconsistencies. If the business analyst receives a test result report that shows evidence of defective functionality, but verifies that the functionality behaves according to the requirements, the business analyst should first verify that the test case is incorrect. This can be done by reviewing the test case, comparing it with the requirements and the acceptance criteria, and identifying any discrepancies or flaws. By verifying that the test case is incorrect, the business analyst can avoid unnecessary changes to the requirements or the solution, and ensure that the test results are valid and reliable. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline3, page 21; Business Analysis for Practitioners: A Practice Guide4, page 101.

 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 would use brainstorming to identify stakeholders. Brainstorming is a technique that involves generating ideas or solutions through a group discussion or a creative thinking process. Brainstorming can help the business analyst to identify potential stakeholders who have an interest, influence, or impact on the project or the solution, and to solicit their input and feedback on the project requirements and expectations. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 9; Business Analysis for Practitioners: A Practice Guide2, page 38.

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.

According to the PMI Guide to Business Analysis, change control systems are tools that help to manage changes to requirements or other project deliverables throughout the project life cycle. Change control systems include provisions to implement changes without formal review in the event of an emergency, such as when there is an urgent need to fix a critical defect or issue that affects the project scope, schedule, cost, quality, or risk. However, when this provision is utilized, changes must still be documented and captured in order to maintain traceability and accountability of the changes, and to communicate them to all relevant stakeholders. Documenting and capturing changes also helps to avoid any confusion or inconsistency in the requirements or other project deliverables, and to evaluate their impact and outcome. The risk associated with the change is still evaluated before implementing it, even in an emergency situation. A change control board should already be established as part of the change control system. Changes may still require further managerial involvement after they are implemented in order to monitor and control their effects. References: PMI Guide to Business Analysis, page 288-289.

The business case is a document that provides the justification for initiating a project or program. It describes the business problem or opportunity, the benefits and costs of the proposed solution, and the risks and assumptions involved. The business case also includes the intangible costs and benefits associated with the change, such as the disruption and short-term loss of productivity that the client anticipates. The business analyst can use the business case to communicate the value proposition of the project or program to the stakeholders and decision makers. References: PMI Guide to Business Analysis, Chapter 3, Section 3.2.1; PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline, Domain II: Planning, Task 4.

A cost-benefit analysis is a tool or technique that compares the expected costs and benefits of a project or an investment. It helps to determine the value of a business case by estimating the net present value (NPV) of the project, which is the difference between the present value of the benefits and the present value of the costs. A positive NPV indicates that the project is worth pursuing, while a negative NPV suggests that the project should be rejected. A cost-benefit analysis can also calculate the return on investment (ROI) of the project, which is the ratio of the net benefits to the net costs. A higher ROI implies a higher value of the business case. A cost-benefit analysis can also consider the qualitative aspects of the project, such as the risks, assumptions, constraints, and opportunities12.

A variance analysis is a tool or technique that compares the actual performance of a project with the planned or expected performance. It helps to identify and explain the deviations or differences between the actual and planned results, such as costs, schedule, scope, quality, and benefits. A variance analysis can also provide corrective actions or recommendations to improve the project performance and align it with the business case13.

A SWOT analysis is a tool or technique that evaluates the strengths, weaknesses, opportunities, and threats of a project, a business, or a situation. It helps to identify the internal and external factors that can affect the success or failure of the project or the business. A SWOT analysis can also provide strategies or actions to leverage the strengths and opportunities, and to overcome or mitigate the weaknesses and threats14.

A feasibility analysis is a tool or technique that assesses the viability and practicality of a project or a solution. It helps to determine if the project or the solution can be implemented within the available resources, time, budget, and technology. A feasibility analysis can also evaluate the potential benefits and risks of the project or the solution, and compare it with other alternatives15.

References: 1 PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline, page 10-11; 2 Business Analysis for Practitioners: A Practice Guide, page 123-124; 3 Business Analysis for Practitioners: A Practice Guide, page 125-126; 4 Business Analysis for Practitioners: A Practice Guide, page 127-128; 5 Business Analysis for Practitioners: A Practice Guide, page 129-130

 A customer metrics tool is a tool that measures the satisfaction, loyalty, retention, and advocacy of customers. It helps to evaluate the performance and quality of the products or services offered by a company, as well as the effectiveness of the customer service and support. A customer metrics tool can also provide insights into the needs, preferences, expectations, and feedback of customers, which can help to improve the customer experience and increase customer retention and referrals. Some examples of customer metrics tools are12:

Customer Satisfaction Score (CSAT): This tool measures how satisfied customers are with a specific product, service, or interaction. It typically uses a scale of 1 to 5 or 1 to 10, where higher scores indicate higher satisfaction. CSAT can be used to assess the overall satisfaction of customers, or to focus on specific aspects, such as ease of use, quality, or speed.

Customer Effort Score (CES): This tool measures how easy or difficult it is for customers to complete a task, such as placing an order, resolving an issue, or finding information. It usually uses a scale of 1 to 7, where lower scores indicate lower effort. CES can be used to identify and eliminate the pain points and friction that customers encounter, and to enhance the customer experience and loyalty.

Net Promoter Score (NPS): This tool measures how likely customers are to recommend a product, service, or company to others. It uses a scale of 0 to 10, where customers are classified as detractors (0-6), passives (7-8), or promoters (9-10). NPS can be used to gauge the loyalty and advocacy of customers, and to calculate the growth potential and profitability of a company.

Churn Rate: This tool measures the percentage of customers who stop using a product or service within a given period of time. It can be calculated by dividing the number of customers who left by the total number of customers at the beginning of the period. Churn rate can be used to monitor the retention and attrition of customers, and to identify the reasons and factors that cause customers to leave.

Customer Lifetime Value (CLV): This tool measures the total revenue or profit that a customer generates for a company over their entire relationship. It can be calculated by multiplying the average purchase value by the average purchase frequency, and then multiplying the result by the average customer lifespan. CLV can be used to estimate the value and profitability of each customer, and to allocate resources and strategies accordingly.

A focus group is not a metrics tool, but rather a research method that involves a small group of customers who share their opinions and experiences about a product, service, or topic. A focus group can provide qualitative data and insights, but not quantitative measurements. A business completion metrics tool is a tool that measures the percentage of customers who complete a desired action, such as signing up, purchasing, or renewing. It can be used to evaluate the conversion and retention rates of customers, and to optimize the customer journey and funnel. A sales and marketing metrics tool is a tool that measures the performance and effectiveness of the sales and marketing activities and campaigns of a company. It can be used to track and analyze the sales and marketing goals, strategies, and outcomes, and to improve the sales and marketing efficiency and ROI. References: 1 The Top 5 Customer Satisfaction Metrics You Need to Track; 2 Customer Satisfaction Metrics: 7 Best Metrics to Measure

 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.

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

According to the PMI Guide to Business Analysis, one of the best strategies to define appropriate acceptance criteria is to clearly define the performance measures and targets for the solution, such as accuracy, reliability, availability, efficiency, etc. These measures and targets help to evaluate how well the solution meets the stakeholder needs and expectations, and how it contributes to the business value. In this case, since the operations manager is concerned about the accuracy of the new measurement system, a good strategy would be to clearly define the maximum acceptable error rate for the new system, which would indicate how accurate the system should be in order to be accepted by the stakeholder. Quantifying the risks associated with measurement errors, asking for a formal acceptance of requirements documents, or planning a training session for the new system are not effective strategies to define appropriate acceptance criteria, as they do not specify how the performance of the solution will be measured or evaluated. References: PMI Guide to Business Analysis, page 316-317.

 A configuration management system is a capability that will help ensure that the product conforms to approved requirements, changes can be documented, and the status of each change can be reported. 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.

 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.

Requesting information on the current ordering process and comparing it with other companies is a technique that involves gathering data and benchmarking best practices from similar or relevant sources. Requesting information on the current ordering process and comparing it with other companies can help the business analyst to take the next step after completing the requirements by analyzing the current state of the problem, identifying gaps or opportunities for improvement, and proposing possible solutions or alternatives. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline (2019), page 12; Business Analysis for Practitioners: A Practice Guide (2015), page 69.

One of the main purposes for creating a requirements traceability matrix is to track how requirements can be connected to the solution. A requirements traceability matrix is a tool that links the requirements to the project scope, objectives, deliverables, and test cases. A requirements traceability matrix can help the business analyst to track the origin, allocation, dependencies, and status of the requirements throughout the project lifecycle, and to ensure that the solution meets the requirements and the stakeholder expectations. A requirements traceability matrix can also help to manage changes, resolve issues, and measure the quality and performance of the solution. A requirements traceability matrix can be created using various formats, such as a table, a spreadsheet, or a database12. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline3, page 18; Business Analysis for Practitioners: A Practice Guide4, page 92.

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 properly written requirement statement should be clear, concise, consistent, complete, and testable. It should specify what the product or service should do, not how it should do it. It should also avoid using ambiguous or vague words that could be interpreted differently by different stakeholders. Among the four options, only option C meets these criteria. Option C is a properly written requirement statement because it clearly and precisely defines the attribute of the pot (the colors) and the possible values for that attribute (yellow, red, brown, blue). It is also consistent with the standard terminology and format for requirement statements, and it is complete and testable, as it can be verified by inspection or measurement. Option A is not a properly written requirement statement because it uses ambiguous and vague words such as “lightweight” and “heat up quickly”. These words do not specify the exact or measurable criteria for the pot’s weight and heating time, and they could mean different things to different stakeholders. Option B is not a properly written requirement statement because it does not specify the conditions or constraints for the pot’s usability in the oven or on the stove. For example, it does not state the maximum temperature or duration that the pot can withstand, or the type of oven or stove that the pot can be used on. Option D is not a properly written requirement statement because it does not specify the requirement for the pot itself, but rather for the company brand. The company brand is not a feature or function of the pot, but rather a marketing or branding strategy. The requirement statement should focus on the pot’s characteristics and capabilities, not on the company’s image or reputation. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, PMI Guide to Business Analysis2, Business Analysis for Practitioners: A Practice Guide3, How To Write Good Requirements (With Example) - TestLodge Blog

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.

 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.

One benefit of documenting the change control process is that stakeholders know how to request changes. The change control process is a process that defines how changes to the project scope, schedule, cost, quality, or requirements are identified, evaluated, approved, implemented, and communicated. Documenting the change control process helps to establish clear and consistent guidelines and procedures for managing changes and ensuring that they are aligned with the project objectives and stakeholder expectations. Documenting the change control process also helps to inform the stakeholders about how to request changes, what information and justification are required, who is responsible for reviewing and approving changes, and what criteria and methods are used for assessing the impact and value of changes. Stakeholders are not shielded from how changes are assessed by documenting the change control process, as it implies that they are excluded or unaware of the change evaluation and decision making process. On the contrary, documenting the change control process helps to increase transparency, collaboration, and communication among the stakeholders regarding changes. Stakeholders do not have a schedule of changes to be deployed by documenting the change control process, as it implies that they have a predetermined or fixed plan of when and how changes will be implemented. On the contrary, documenting the change control process helps to ensure that changes are implemented in a timely and effective manner based on their priority, feasibility, and dependency. Stakeholders do not understand the difficulty of managing requirements by documenting the change control process, as it implies that they have a negative or pessimistic view of the requirements management process. On the contrary, documenting the change control process helps to improve the quality and stability of the requirements and reduce ambiguity, confusion, or conflicts among the stakeholders. References: Business Analysis for Practitioners: A Practice Guide 1, page 163-164; PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline 2, page 20.

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.

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

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.

A configuration management system is a standardized, effective, and efficient way to manage changes to project documentation. A configuration management system is a set of tools and processes that help to track, control, and update the configuration items (CIs) of a project, such as documents, requirements, designs, code, tests, etc. A configuration management system helps to ensure that the project documentation is consistent, accurate, and up-to-date throughout the project life cycle. It also helps to maintain the traceability and auditability of the changes made to the project documentation. A configuration management system typically includes the following components:

A configuration management plan that defines the scope, roles, responsibilities, policies, procedures, and standards for configuration management.

A configuration management database (CMDB) that stores the information about the CIs, their attributes, relationships, versions, baselines, and changes.

A configuration identification process that assigns unique identifiers and names to the CIs and their versions.

A configuration control process that evaluates, approves, and implements changes to the CIs and their versions.

A configuration status accounting process that records and reports the status and history of the CIs and their versions.

A configuration verification and audit process that verifies and validates the CIs and their versions against the requirements and specifications.

References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline, page 13.

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.

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.

The selected project life cycle is a characteristic of the project that is needed to determine the approach so that the business analyst can validate whether they will need to have a discussion about the budget. The project life cycle is the sequence of phases or stages that the project goes through from initiation to closure. The project life cycle can be selected based on various factors, such as the nature, complexity, size, and uncertainty of the project, the stakeholder preferences, the organizational culture, and the industry standards. The project life cycle can influence the approach that the business analyst and the project team use to plan, execute, monitor, and control the project, and to deliver the product or service. The project life cycle can also affect the budget, schedule, scope, and quality of the project, and the level of stakeholder involvement and communication. Therefore, the business analyst should understand the selected project life cycle and its implications for the project, and validate whether it is appropriate and feasible for the project, and whether it requires any adjustments or discussions with the stakeholders. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 15; Business Analysis for Practitioners: A Practice Guide2, page 84.

 The business analyst can determine the impact of a new requirement on existing requirements by reviewing the requirements traceability matrix. The requirements traceability matrix is a tool that tracks the relationships and dependencies among the requirements, as well as other project elements such as design, test cases, risks, or issues. By reviewing the requirements traceability matrix, the business analyst can identify which existing requirements are affected by the new requirement and assess the impact of the change on the scope, schedule, cost, or quality of the project. Performing a stakeholder analysis is not a way to determine the impact of a new requirement on existing requirements, as it focuses on identifying and understanding the needs, expectations, and influence of the stakeholders, not the requirements. Using time-boxing to defer the new requirement is not a way to determine the impact of a new requirement on existing requirements, as it postpones the analysis and implementation of the new requirement until a later iteration or phase of the project. Updating the use case documentation is not a way to determine the impact of a new requirement on existing requirements, as it only reflects how the new requirement affects one aspect of the solution functionality, not the entire project. References: Business Analysis for Practitioners: A Practice Guide 1, page 161-162; PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline 2, page 19.

The first thing the business analyst should do immediately after the discussion with the project manager is to schedule time with the process owners. The process owners are the people or groups responsible for a specific business process or procedure that is affected by the project5. The business analyst needs to understand the current state of the processes, the pain points and opportunities, the requirements and expectations, and the impact of the project on the processes. By meeting with the process owners, the business analyst can establish a relationship, gather relevant information, and ensure alignment and collaboration. Putting the information into a project plan is premature, as the business analyst needs to conduct more analysis and planning before creating a project plan. Developing an issues log is not necessary, as there are no issues identified at this stage. Assessing the risks for the project is important, but it is not the immediate action, as the business analyst needs to understand the scope and objectives of the project first. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline2, PMI Guide to Business Analysis3, Business Analysis for Practitioners: A Practice Guide4, What is a Process Owner? Definition & Responsibilities

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

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

 Time-boxing is a prioritization technique that involves assigning a fixed amount of time or resource to each requirement or deliverable, and delivering as much value as possible within that time or resource constraint. Time-boxing is useful when the project has a tight timeline or budget, and the stakeholders have too many requirements for the delivery window. Time-boxing helps to focus on the most important and valuable requirements, and to manage the expectations and scope of the stakeholders. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 18; Business Analysis for Practitioners: A Practice Guide2, page 97.

According to the PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline, one of the tasks under the domain of Traceability and Monitoring is to “Track the status, priority, and disposition of requirements and issues, and communicate updates as necessary” (Task 1). This implies that the business analyst is responsible for ensuring that the requirements are delivered as stated and that any changes or issues are communicated to the relevant stakeholders. One of the techniques that can be used to perform this task is the traceability matrix, which is a table that shows the relationships between requirements and other project artifacts, such as design documents, test cases, or deliverables. A traceability matrix can help the business analyst to verify that all the requirements are covered by the test cases and that the test output matches the expected results. Therefore, the technique that the business analyst could have used to ensure that requirements were delivered as stated is the traceability matrix.

A fishbone diagram, also known as a cause-and-effect diagram or an Ishikawa diagram, is a tool that helps to identify and analyze the possible causes of a problem or an effect. It can help the business analyst to perform a root cause analysis in order to analyze and resolve the discrepancy identified through user acceptance testing. A fishbone diagram has a structure that resembles a fish skeleton, with a head, a spine, and several branches. The head represents the problem or the effect, the spine represents the main cause categories, and the branches represent the sub-causes or factors that contribute to the problem or the effect. By creating a fishbone diagram, the business analyst can brainstorm and organize the potential causes of the software flaw, and then investigate and verify the most likely root cause. A fishbone diagram can also help to communicate the findings and recommendations to the stakeholders and the development team. An interface analysis is a tool that helps to identify and describe the interactions and dependencies between different components or systems. It does not help to perform a root cause analysis in order to analyze and resolve the discrepancy identified through user acceptance testing, as it does not focus on the causes and effects of the problem. A Delphi estimation is a tool that helps to obtain a consensus among a group of experts on a complex or uncertain issue. It does not help to perform a root cause analysis in order to analyze and resolve the discrepancy identified through user acceptance testing, as it does not provide a systematic and structured way to identify and analyze the causes of the problem. A functional decomposition is a tool that helps to break down a complex system or process into smaller and simpler components or functions. It does not help to perform a root cause analysis in order to analyze and resolve the discrepancy identified through user acceptance testing, as it does not show the relationships and influences between the components or functions. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, PMI Guide to Business Analysis2, Business Analysis for Practitioners: A Practice Guide3, Root Cause Analysis: Definition, Examples & Methods | Tableau1

Requirements baseline is a document that contains the approved version of the requirements that serves as a reference point for further changes. Requirements baseline can help the business analyst to address the issue of underestimating the required budget and schedule by defining the scope, value, quality, risk, and feasibility of each requirement. Requirements baseline can also help to negotiate the scope in the contract with the customer by showing how each requirement aligns with their needs and expectations, and proposing possible trade-offs or alternatives. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline (2019), page 10; Business Analysis for Practitioners: A Practice Guide (2015), page 40.

 According to the PMI Guide to Business Analysis, planning the requirements change process involves defining how requirement changes will be identified, analyzed, approved, and communicated throughout the project life cycle. Communication is a key aspect of managing requirement changes, as it ensures that all stakeholders are aware of the status, impact, and rationale of the changes, and that they can provide their feedback and input. How requirement changes will impact the requirements baseline, how they will be implemented, and how they will impact the validation plan are all important considerations, but they are not part of planning the requirements change process. They are part of executing, monitoring, and controlling the requirements change process. References: PMI Guide to Business Analysis, page 286-287.