PMI-PBA PMI Professional in Business Analysis Questions and Answers

 Baseline information is the current state or performance of a system or process before any changes are made. Baseline information is essential for documenting the acceptance criteria, which are the conditions that must be met for a solution or deliverable to be accepted by the stakeholders. The analyst should have gathered baseline information to support the minor modification in the user portal, such as the current customer satisfaction rate, response time, error rate, etc. The analyst should have compared the baseline information with the expected outcomes of the modification, and defined the acceptance criteria accordingly. If the analyst failed to gather any baseline information, the acceptance criteria would be incomplete and returned. The other options are not likely to cause this problem. The scope document is a document that defines the boundaries and deliverables of the project or solution, but it is not required to be included in the acceptance criteria paperwork. Forward and backward traceability are techniques to link the requirements to their sources and deliverables, which can help to ensure completeness and consistency of the requirements. User stories are a tool to document the requirements from the perspective of a user or customer, using a simple format of “As a , I want , so that ”. User stories can be used as a requirements document tool, but they are not sufficient for defining the acceptance criteria. References: PMI-PBA® Examination Content Outline, page 13; PMI-PBA® Reference List, page 1, BABOK® Guide v3, page 39.

Managing solution scope is the task of ensuring that the solution meets the agreed-upon requirements and delivers the expected value to the stakeholders. Managing solution scope involves analyzing the impact of any changes to the scope, assessing the feasibility and risks of the changes, and obtaining approval from the stakeholders before implementing the changes. Managing solution scope can help the business analyst to identify the impacts, dependencies, or risks associated with the addition to the scope. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline (2019), page 14; Business Analysis for Practitioners: A Practice Guide (2015), page 83.

 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.

A review of the solution prototype would be the most viable technique to use in this scenario for validating requirements through in-person sessions. A solution prototype is a simplified version of part or all of a solution that can be used to elicit feedback from stakeholders. A review of a solution prototype involves presenting or demonstrating it to stakeholders and asking them questions to assess their satisfaction, understanding, agreement, or concerns. A review of a solution prototype can help to validate that the solution meets the stakeholder requirements and delivers value to them. A brainstorming session is a technique for generating ideas or solutions by encouraging free and creative thinking from participants. A brainstorming session can help to elicit or analyze requirements but not validate them. A use-case development session is a technique for creating use cases that describe how actors interact with a system to achieve their goals. A use-case development session can help to elicit or specify requirements but not validate them. A review of the previous version is a technique for examining an existing solution or product to identify its strengths, weaknesses, opportunities, or threats. A review of the previous version can help to elicit or analyze requirements but not validate them. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 13; Business Analysis for Practitioners: A Practice Guide2, page 76.

 A capability table is a tool that lists the current capabilities of an application and compares them with the desired capabilities identified by the end users. A capability table can help the business analyst to analyze this information and determine project scope by showing the gaps between the current and future states of the application, and prioritizing the new features that will address those gaps. A capability table can also help to define the high-level requirements and objectives of the project. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline (2019), page 11; Business Analysis for Practitioners: A Practice Guide (2015), page 67.

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.

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

Internal rate of return (IRR) is a technique that calculates the annualized rate of return of an investment or a project. IRR can help the business analyst to determine the estimated growth rate of potential solution options by comparing the present value of the expected cash inflows and outflows of each option. IRR can also help to select the option that has the highest rate of return and exceeds the minimum required rate of return or the cost of capital. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline (2019), page 11; Business Analysis for Practitioners: A Practice Guide (2015), page 66.

Decomposition model is a technique that involves breaking down a complex entity into smaller and more manageable components. Decomposition model can help the business analyst to estimate the effort associated with project requirements by providing a hierarchical structure of the requirements, showing the dependencies and relationships among them, and allowing for more accurate and detailed estimation at lower levels. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline (2019), page 13; Business Analysis for Practitioners: A Practice Guide (2015), page 71.

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.

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

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

Tracing requirements is a technique that involves tracking the origin, dependencies, allocation, and status of each requirement throughout the project life cycle. Tracing requirements can help the business analyst to determine this issue before delivery by ensuring that each project objective is linked to one or more requirements, and that each requirement is verified and validated against the project objectives. Tracing requirements can also help to identify any missing, redundant, or conflicting 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.

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.

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

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.

 A force-field analysis is a tool that helps to identify and analyze the factors or forces that support or oppose a change or an initiative. It can help to facilitate the decision-making process when stakeholders do not agree on the value of an initiative by showing the pros and cons of the initiative, as well as the relative strength and importance of each factor. A force-field analysis can also help to develop strategies to increase the supporting forces or decrease the opposing forces, or both, to achieve the desired outcome. A PEST analysis is a tool that helps to examine the external factors that affect an organization or an initiative, such as political, economic, social, and technological factors. It does not help to facilitate the decision-making process when stakeholders do not agree on the value of an initiative, as it does not show the internal factors or the balance of forces. A feasibility analysis is a tool that helps to evaluate the viability and suitability of a project or an initiative, as well as the risks and benefits associated with it. It does not help to facilitate the decision-making process when stakeholders do not agree on the value of an initiative, as it does not show the supporting and opposing forces. A gap analysis is a tool that helps to compare the current state and the desired state of a process, a product, or a service, and identify the gaps or differences between them. It does not help to facilitate the decision-making process when stakeholders do not agree on the value of an initiative, as it does not show the factors or forces that influence the initiative. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, PMI Guide to Business Analysis2, Business Analysis for Practitioners: A Practice Guide3, What is Force Field Analysis: Definition and Example

According to the PMI Professional in Business Analysis objectives and content, a prototype is a tool that can be used to elicit, analyze, and validate requirements. A prototype is a representation of a solution that allows stakeholders to interact with it and provide feedback. By developing a prototype, the business analyst can gather functional requirements from the end user and ensure that the new interface supports their core business processes. A prototype can also help to reduce ambiguity, resolve conflicts, and increase stakeholder satisfaction. 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

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

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.

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

 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.

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

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.

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

Observation is a technique that involves watching how people perform their work in their natural environment. Observation can help the business analyst to understand the company’s current business processes, identify pain points, and discover opportunities for improvement. Observation can also help to validate or verify the information obtained from other sources, such as interviews or documents. References: = PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline (2019), page 9; Business Analysis for Practitioners: A Practice Guide (2015), page 61.

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.

 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.

 The project life cycle is a key factor that drives the selection of business analyst activities to be included in the project. 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 type, level, and timing of the business analysis activities, such as elicitation, analysis, documentation, validation, and management of the requirements. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 15; Business Analysis for Practitioners: A Practice Guide2, page 84.

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.

The best approach to resolve this issue is to suggest re-estimating the requirement and following the change control process. This would allow the project team to assess the impact of the change request, evaluate the feasibility and cost of the modification, and obtain the approval of the stakeholders before implementing the change. A change control process is a method used to manage change requests for projects and big initiatives. It’s part of a change management plan, which defines the roles for managing change within a team or company1. Meeting with the customer and apologizing for misunderstanding the business’s need is not sufficient, as it does not address the root cause of the problem or propose a solution. Providing the stakeholder with a copy of the approved requirements baseline and moving forward without making a change is not acceptable, as it ignores the stakeholder’s feedback and dissatisfaction. Requiring development resources to work overtime to modify the deliverable to satisfy the stakeholder is not advisable, as it may compromise the quality of the work, increase the project cost and risk, and demoralize the team. 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 Change Control Process? (with Example Change Log)

 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.

 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

The business need is the reason why the project is initiated and the problem or opportunity that the project aims to address. The business need defines the key business drivers and the desired outcomes of the project. By asking what the business need is, the business analyst can understand the value proposition of the project and prioritize the requirements that align with the business objectives and deliver the most benefits to the stakeholders. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 9; Business Analysis for Practitioners: A Practice Guide2, page 23.

 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

 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.

 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.

Workshop sessions are a technique to elicit, analyze, and prioritize requirements by bringing together a group of stakeholders, such as subject matter experts, to collaborate and reach a consensus. Workshop sessions can be used to identify and prioritize the requirements for a newly approved project. The other techniques are not suitable for this purpose. Delphi technique is a technique to obtain expert opinions anonymously and iteratively until a consensus is reached. Brainstorming is a technique to generate a large number of ideas or solutions in a short time. Idea and mind mapping is a technique to visually organize ideas or information using diagrams or graphs. References: PMI-PBA® Examination Content Outline, page 10; PMI-PBA® Reference List, page 1, BABOK® Guide v3, page 50.

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

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

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

PMI Professional in Business Analysis reference list: PBA Reference List

PMI Professional in Business Analysis study guide: Study.com

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

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

 Business use cases are the documents that the business analyst should pay the most attention to ensure the project succeeds this time. Business use cases are documents that describe the interactions between the users and the system, and the value or benefit that the users obtain from the system. Business use cases can help the business analyst and the project team to understand the business needs, goals, and expectations of the stakeholders, and to define the scope, functionality, and behavior of the system. Business use cases can also help to verify and validate that the system meets the requirements and delivers the desired outcomes. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 18; Business Analysis for Practitioners: A Practice Guide2, page 93.

A decision tree is a tool that can be used to analyze how the system responds to various combinations of input conditions with the probability of each outcome. A decision tree is a graphical representation of a decision problem that shows the possible choices and their consequences. A decision tree can help to evaluate the expected value of each alternative and choose the optimal one. Functional decomposition is a tool that can be used to break down a complex system or process into smaller and simpler components. Expected monetary value is a tool that can be used to calculate the average outcome of a decision under uncertainty by multiplying the value of each outcome by its probability and summing them up. Weighted criteria is a tool that can be used to prioritize requirements or alternatives based on their importance and performance scores. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline1, page 15; Business Analysis for Practitioners: A Practice Guide2, page 95.

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

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

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

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

 A 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 also include the acceptance criteria that specify the conditions that must be met for the use case to be successfully completed and accepted by the stakeholders. The test team can review the use cases to help identify the acceptance criteria for the solution, as they provide a comprehensive and realistic view of the expected behavior and outcomes of the system. The test team can also use the use cases to design and execute test cases that 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.

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

 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.

 A matrix is a tool that can be used to record, organize, and track the requirements throughout the lifecycle of the project. A matrix can help the business analyst to identify the sources, dependencies, relationships, and attributes of the requirements, as well as to monitor their status, changes, and traceability. A matrix can also facilitate the communication, verification, and validation of the requirements with the stakeholders, and ensure their alignment with the business needs and objectives. A matrix can be updated and reviewed regularly to reflect the current state of the requirements and the solution, and to obtain the approval and acceptance from the stakeholders. A common example of a matrix is the Requirements Traceability Matrix (RTM), which is a tool that links the requirements to the project scope, objectives, deliverables, and test cases12. References: PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline3, page 18; Business Analysis for Practitioners: A Practice Guide4, page 92.