PMI-PBA Sample Questions & Answers

Root cause analysis (RCA) is a systematic problem-solving method used to identify the underlying causes of a problem. Techniques like the Fishbone (Ishikawa) diagram or the 5 Whys are used to look beyond the immediate symptoms and find the fundamental issue, which is exactly what is needed in this scenario to address the product defects effectively.

The primary purpose of a business case is to provide justification for undertaking a project or initiative. It focuses on the business need, benefits, costs, risks, and alignment with organizational goals. While it may reference high-level requirements, a detailed list is developed later in the project lifecycle.

These are business objectives. They are specific, measurable, achievable, relevant, and time-bound (SMART) goals that define the success criteria for the future state. They quantify the expected business value and provide a benchmark against which the solution's performance will be measured.

Observation (or job shadowing) is the most effective technique in this scenario. It allows the business analyst to see the process in action, understand the context, identify workarounds and pain points that users might not articulate in interviews, and gather rich, tacit knowledge. This provides a much deeper understanding than surveys, high-level focus groups, or potentially outdated documentation.

The BA is beginning the process of requirements analysis and modeling. This involves taking the unstructured information gathered during elicitation and organizing, structuring, and specifying it. Modeling techniques (like process models, data models, and use cases) are used to clarify requirements, identify gaps, and present the information in a clear, unambiguous way.

This is a non-functional requirement (NFR), specifically related to usability and accessibility. NFRs define the quality attributes of a system and how it should perform, rather than what it should do (which is covered by functional requirements). Other examples include performance, security, and reliability.

This is part of requirements verification. Verification ensures that the requirements are well-formed, complete, clear, consistent, and feasible. Confirming technical feasibility is a key verification activity to ensure that the specified requirement can actually be built and implemented by the development team.

This is the classic distinction. Verification focuses on the quality of the requirements and design specifications themselves—are they clear, complete, consistent, and testable? ('Are we building the product right?'). Validation focuses on whether the requirements, and the resulting solution, will actually meet the business need and provide value to stakeholders. ('Are we building the right product?').

For a project that is large, complex, has high regulatory oversight, and a distributed team, an informal approach with minimal documentation is the least appropriate. Such projects require robust documentation for clarity, traceability, and audit purposes. The complexity and distributed nature of the team also benefit from more formal communication and planning, which are hallmarks of predictive or hybrid approaches.

This describes the information management approach, which is a key component of the overall business analysis plan. It defines how BA information will be stored, accessed, traced, and used throughout the project. This includes selecting a repository, defining access levels, and setting standards for requirements attributes and traceability.