PMI PBA Exam Hot Topics

The PMI-PBA addresses the domain of business analysis within the context of projects and programs, which is the primary, and often the only context in which PMs do business analysis. Specifically, the exam pertains to tasks related to everything from building a business case to evaluating solutions once implemented. I am listing below the PMI-PBA exam hot topics where most of the exam questions come from:

1. Product requirements. when performing the work of requirements elicitation, specification, or requirements management, one may choose to indicate the type of requirement to be able to communicate whether the product requirement represents a need of the business, an aspect of the solution, or a product requirement for a particular stakeholder group. A requirement is defined as a condition or capability that is required to be present in a product, service, or result to satisfy a business need. This guide uses the term product requirement to describe the types of requirements that are part of the business analysis effort. Product requirements are the primary focus of this guide, and the term requirement without a qualifier is used to specify all product requirement types. Product requirements can be solution, stakeholder, business, stakeholder, and transition requirement.
2. Stakeholders’ analysis models. In project management, a stakeholder is an individual, group, or organization that may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project. In business analysis, stakeholders also include those affected or perceived to be affected by activities and decisions related to the solution. Stakeholder analysis technique is used to analyze each stakeholder potential impact or influence to manage effectively throughout project life cycle. Stakeholder analysis involves describing how stakeholders may be categorized by classifications, such as their power, influence, impact, or interest. Classification tools which can be used include power/influence grid, power/interest grid, influence/impact grid, stakeholder cube, and salience model which describes stakeholders based on power, urgency, and legitimacy. An onion diagram is a technique that can be used to model relationships between different aspects of a subject. In business analysis, an onion diagram can be created to depict the relationships that exist between stakeholders and the solution.
3. Tools and Techniques. Direct questions about tools and techniques used in business analysis activities: Benchmarking, competitive analysis, market analysis, weighted decision making, Onion diagram, stakeholder matrix, Capability framework, Root cause analysis, Gap analysis, Questionnaires and surveys, Job analysis, RACI model, Poker estimation, SWOT analysis, 5-Whys.
4. Weighted ranking. It is useful technique in the prioritize requirements process. Ranking two or more options can be done using various techniques. A practical and effective method is to use a weighted ranking matrix. A weighted ranking matrix or table combines pair-matching with weighted criteria to add objectivity to a recommendation. It can be defined as a method that first requires decision criteria to be identified and weighted. Then each item is rated by scoring how well the option meets the criteria independent of other options. Ratings are multiplied by the weights and summed to arrive at the score for each item and the overall rankings.
5. Modelling techniques. Models are visual representations of information, in the form of diagrams, tables, or structured text, that effectively arrange and convey a lot of information in a concise manner. The models are organized into five categories: Scope, process, rule, data, and interface. Analyzing models is helpful for finding gaps in information and identifying extraneous information by exploring the solution from multiple perspectives. Models provide context to discussions and analysis and provide for better understanding of complex relationships and concepts. Models can convey information more clearly than textual descriptions. Models provide a concise format to present information and can be used to clarify and discover information with stakeholders. Scope models (bounding the solution): Models that structure and organize the features, functions, and boundaries of the business domain being analyzed. Process models: Models that describe the business processes and ways in which stakeholders interact with those processes. Rule Models: Models of concepts and behaviors that define or constrain aspects of a business in order to enforce established business policies. Data models: Models that document the data used in a process or system and its life cycle. Interface Models: Models that assist in understanding specific systems and their relationships within a solution and with users.
6. Feasibility assessment. Before deciding which option is preferred, the business analyst assesses the feasibility of each possible option. The feasibility assessment can be operational, technology, cost-effectiveness, or time. 
7. Business analysis plan, if formally documented, may be a subplan of the portfolio, program, or project management plan or may be a separate plan. It defines the business analysis approach through the assembly of the sub-approaches across all knowledge areas. It defines the business analysis approach through the assembly of the sub-approaches across all Knowledge Areas. A business analysis plan can include an estimation of level of effort for business analysis activities. It covers the entire business analysis approach, from stakeholder engagement to decisions about how to manage requirements. It is broader than a requirements management plan, which focuses on how requirements will be elicited, analyzed, documented, and managed. Whether formally documented or not, the business analysis plan provides a summary of the agreements reached for all of its components. Whenever a written business analysis plan is a required document, it should be written in a manner that will be easily understood, because it will be reviewed and may need to be approved by key stakeholders
8. Traceability Matrix. It is a grid that links product requirements from their origin to the deliverables that satisfy them. The matrix can support linkages among many different types of objects, providing a mechanism for tracking product information through the project and product life cycles. A traceability matrix can be used to establish relationships among product information, deliverables, and project work to ensure that each relates back to business objectives. Establishing these linkages manages scope creep by ensuring that only relevant product information is incorporated into the solution. On projects using an adaptive project life cycle, the product team may choose to develop an interaction matrix. An interaction matrix is a lightweight version of a traceability matrix that is used to determine whether requirements are sufficiently detailed or if any entities are missing. The main difference between these two types of traceability matrices is that an interaction matrix is a temporary artifact that represents a snapshot in time, whereas a traceability matrix is typically maintained throughout a portfolio, program, or project.
9. Change Management. Managing changes to requirements and other product information entails maintaining the integrity of the requirements and the associated deliverables and work products and ensuring that each new requirement aligns with the business need and business objectives. The key benefit of a requirements change process is that it provides a process to manage changes to approved requirements while minimizing product and project risks associated with uncontrolled and unapproved change. Negative impacts to the product and project often arise from making changes without taking into consideration any dependencies, and how the change will affect the overall product and project, including expected business value. On adaptive projects, change is ongoing. The team utilizes emergent learning, where stakeholders discover their requirements as portions of the solution are delivered over time. Adaptive methods expect that requirements will change as stakeholders learn what they want as they see the solution evolve.
10. Group decision-making techniques are techniques that can be used in a group setting to bring participants to a final decision on an issue or topic under discussion. Expect questions about the difference between plurality, majority, unanimity, and autocratic. During business analysis planning, the team should establish how decisions will be made across the business analysis effort to avoid misunderstandings or conflict later on when performing the work. A few decision-making techniques include the following: Autocratic. One individual makes the decision for the group. Delphi. Reduces bias and prevents any one person from imposing undue influence on the team. Delphi reaches a decision through consensus. Majority. Reaches a decision when support is obtained from more than 50% of the members of the group. Plurality. Obtains a decision by taking the most common answer received from among the decision makers. Unanimity. Reaches a decision by everyone agreeing on a single course of action.

In order to assess your readiness for the real PMI-PBA exam, I highly recommend you practice some high quality mock exams, and in this article, I am listing some of the high quality PMI PBA mock exams in the online market, you can access it from the link here. 

Good Luck in your Journey!