25 Questions — PMI – PMI-PBA : Certified Professional in Business Analysis - Domain 2 - Planning

Expand any question to reveal the correct answer and explanation.

1. 1 A business analyst is assigned to a project with a hybrid delivery model where the infrastructure follows a predictive lifecycle and the application software follows an adaptive lifecycle. Which action is most appropriate when developing the business analysis approach?

   Consider how requirements should be formatted to best support different types of work within the same initiative.

   Tailor the requirements planning to use plan-driven specifications for hardware and user stories for the software application.

   Effective planning requires aligning the requirements approach with the specific delivery method used for each component of the solution.

   • ✗ Mandate that all requirements are documented as detailed text-based specifications to ensure consistency across the project.

     Forcing a single documentation style ignores the specific needs of the software component, which benefits from the flexibility of iterative modeling.

   • ✗ Utilize agile burnup charts and product backlogs for the entire project to maintain transparency for all stakeholders.

     Applying purely adaptive tools to hardware components that follow a plan-driven schedule can lead to a lack of necessary architectural detail.

   • ✗ Postpone requirements planning until the software team selects their specific sprint duration and cadence.

     Delaying the business analysis approach until execution begins risks misalignment between the hardware constraints and software capabilities.

2. 2 During the creation of the requirements management plan, a stakeholder suggests that the team should start eliciting requirements immediately to save time. What is the most critical risk of bypassing the formalization of this plan?

   Think about the consequences of gathering information without first defining how that information will be approved or altered.

   Requirements will be created and modified without an agreed-upon governance structure for approvals and changes.

   Establishing how requirements are governed before they are created prevents uncontrolled alterations and ensures a clear pathway to sign-off.

   • ✗ The project will fail to meet its baseline schedule compliance and cost variance metrics.

     While schedule and cost are important, they are primarily project management metrics rather than core business analysis risks.

   • ✗ Stakeholders will be unable to attend elicitation workshops due to a lack of communication protocols.

     Logistical issues are a symptom of poor planning, but they do not represent the primary risk to the integrity of the requirements themselves.

   • ✗ The business analyst will be unable to utilize the Fishbone diagram technique during elicitation.

     Technique selection is part of the plan, but losing access to a specific tool is less critical than the loss of overall governance.

3. 3 When defining the strategy for requirements traceability (Task 2), the business analyst must determine the necessary level of detail. Which factor most heavily influences this decision in a highly regulated industry?

   Reflect on why an organization would need to prove that a requirement was successfully tested and implemented.

   The level of risk, safety, or compliance exposure associated with the solution.

   Traceability depth should be tailored to provide the necessary evidence for audits and to ensure that all critical requirements are satisfied.

   • ✗ The total number of stakeholders identified during the Needs Assessment phase.

     Stakeholder count influences communication effort but does not necessarily dictate the depth of the traceability logic.

   • ✗ The specific project management software being used by the development team.

     Tools should support the strategy, but the strategy itself should be driven by business and compliance needs rather than software limitations.

   • ✗ The requirements of the organization's configuration management system (CMS).

     The CMS provides the infrastructure for control but does not define the business value or compliance-driven depth of the trace.

4. 4 A business analyst is performing Task 5 of the Planning domain: 'Select methods for document control.' Which of the following best describes the primary purpose of this task within the context of requirements management?

   Focus on the need to maintain a 'single version of the truth' throughout the project lifecycle.

   Establishing standards for requirements versioning, security, and storage to prevent uncontrolled access.

   Document control ensures that the team is always working from the correct, authorized version of requirements and that data is protected.

   • ✗ Defining the specific fonts and styles to be used in the requirements specification document.

     Document formatting is a matter of presentation rather than the controlled management of requirements integrity.

   • ✗ Determining the sequence of activities in the project schedule for document reviews.

     Scheduling is a project management function, whereas document control focuses on the standards and procedures for the artifacts themselves.

   • ✗ Identifying the technical requirements for the database server that will host the document repository.

     Technical infrastructure is usually handled by IT, while the analyst focuses on the processes for managing the documents within that system.

5. 5 When defining business metrics and acceptance criteria (Task 6), which approach helps ensure that the criteria are measurable and actionable?

   Consider the difference between a subjective opinion and an objective measurement.

   Applying 'Planguage' or other measurement tools to define observable conditions for acceptance.

   Measurement tools like Planguage allow for the definition of precise, measurable thresholds that clearly indicate when a requirement is met.

   • ✗ Using qualitative terms such as 'user-friendly' and 'highly efficient' to provide flexibility.

     Vague, subjective terms lead to ambiguity and make objective verification of solution success impossible.

   • ✗ Allowing each stakeholder to define their own individual definition of success in isolation.

     Individual success definitions can conflict; the analyst must facilitate consensus to reach a unified set of criteria.

   • ✗ Delaying the definition of criteria until the Evaluation domain when the solution is already built.

     Defining criteria too late prevents the team from building the solution to the correct standards and increases the risk of rework.

6. 6 A business analyst is using 'Bottom-Up' estimation to determine the effort required for analysis activities. This is an example of which planning capability?

   This involves calculating the time and effort necessary to perform the work described in the BA plan.

   BA Resource Planning

   Estimating analysis effort and skill requirements is a core part of planning the resources needed to execute business analysis tasks.

   • ✗ Requirements Traceability Strategy

     Traceability strategy focuses on the relationships between requirements, not the estimation of the time needed to manage them.

   • ✗ Needs Assessment Goal Alignment

     Goal alignment ensures the project solves the right problem, whereas resource planning focuses on the work required to do so.

   • ✗ Stakeholder Value Analysis

     Stakeholder analysis identifies what stakeholders want, which is distinct from calculating the labor required to gather that information.

7. 7 Task 1 of the Planning domain involves reviewing the business case and project goals. Why is this review performed before developing the requirements management plan?

   Think about how the initial justification for a project should influence how the requirements are managed.

   To provide the necessary context to ensure analysis activities align with strategic objectives.

   Reviewing the business case ensures the analyst understands the project's 'why,' which informs the 'how' of the requirements approach.

   • ✗ To identify which technical stakeholders are responsible for writing code for the final solution.

     Detailed technical assignments are typically part of execution and project management, not the initial BA context review.

   • ✗ To ensure that the business analyst has the authority to reject the project if the ROI is too low.

     The business analyst provides input and context but usually does not have the authority to unilaterally cancel a project based on ROI.

   • ✗ To finalize the solution design before elicitation begins.

     Design should follow requirements elicitation and analysis; finalizing it before understanding needs is a procedural error.

8. 8 A project utilizes a configuration management system (CMS) to manage requirements changes. Which task in the Planning domain is most directly supported by the implementation of a CMS?

   Identify the planning task that deals with protecting the requirements baseline from unauthorized edits.

   Selecting methods for requirements change control (Task 4).

   A CMS is a primary tool for automating the process of requesting, tracking, and incorporating changes into a requirements baseline.

   • ✗ Establishing document control methods (Task 5).

     While related, Task 5 focuses on versioning and storage standards, which is a subset of the broader change control managed by a CMS.

   • ✗ Developing the strategy for requirements traceability (Task 2).

     Traceability strategy defines the links between requirements, whereas a CMS manages the lifecycle and changes of the artifacts themselves.

   • ✗ Defining business metrics and acceptance criteria (Task 6).

     Acceptance criteria are business definitions, whereas a CMS is a technical tool for governance and version management.

9. 9 Which artifact created during the Planning domain specifically identifies who has the authority to approve requirement changes?

   Look for a document that clarifies roles and responsibilities regarding the final 'say' on project deliverables.

   Decision-Authority Map

   A decision-authority map (or RACI) identifies the roles responsible for making final approvals and decisions on requirements.

   • ✗ Communication Matrix

     A communication matrix defines who gets what information and when, but it doesn't necessarily grant decision-making authority.

   • ✗ Requirements Traceability Matrix (RTM)

     The RTM tracks the history and status of requirements but does not define the organizational governance structure for decision-making.

   • ✗ Solution Scope Model

     The scope model defines the boundaries of the solution, not the governance roles within the project team.

10. 10 When planning requirements traceability, a business analyst decides to trace requirements to specific test cases. What is the primary benefit of this trace relationship?

    Think about the phase of the project where you must prove that the 'build' matches the 'plan'.

    It facilitates solution verification by providing evidence that each requirement has been tested.

    Tracing requirements to test cases allows the analyst to prove that the solution was built according to the approved requirements.

    • ✗ It helps the team identify which developers are responsible for specific code defects.

      Traceability is intended to validate requirement satisfaction, not to assign individual blame for software bugs.

    • ✗ It ensures that the project schedule is updated automatically when a test fails.

      Schedule updates are a separate management process; traceability provides evidence of coverage, not automated project scheduling.

    • ✗ It reduces the need for stakeholder engagement during the Evaluation phase.

      Evidence of testing does not replace the need for stakeholders to confirm that the solution actually delivers business value.

11. 11 A business analyst is using 'Estimation Poker' with a team to plan the effort for upcoming analysis tasks. Why is this technique particularly useful in an adaptive project environment?

    Consider how relative sizing helps groups of people reach an agreement on the difficulty of a task.

    It surfaces differing perspectives on task complexity and facilitates team consensus.

    By revealing outliers in estimation, the team can discuss and resolve misconceptions about the effort required for specific tasks.

    • ✗ It allows the project manager to dictate precisely when each task will be finished.

      Estimation poker is a collaborative technique that relies on team consensus, not a top-down management directive.

    • ✗ It uses historical data from other organizations to calculate exact labor costs.

      Estimation poker focuses on relative effort based on the team's internal expertise rather than external parametric data.

    • ✗ It eliminates the need for a contingency plan by providing $100\%$ accuracy in time estimates.

      No estimation technique provides perfect accuracy; contingency planning is always necessary for managing uncertainty.

12. 12 During the development of the Requirements Management Plan (Task 3), the business analyst specifies the 'Requirements Lifecycle States.' What is the purpose of defining these states?

    This involves creating a 'status' field that shows how close a requirement is to being 'done'.

    To track the progress of each requirement from elicitation through to closure.

    Defining states (e.g., Draft, Approved, Implemented) allows for consistent status reporting and ensures every requirement is managed to completion.

    • ✗ To determine the order in which stakeholders will be interviewed.

      Stakeholder sequencing is part of elicitation planning, whereas lifecycle states track the status of the requirements themselves.

    • ✗ To define the financial value of each requirement in the business case.

      Financial valuation is a Needs Assessment activity; lifecycle states focus on the operational status within the project.

    • ✗ To assign a specific version number to every document in the VCS.

      Versioning is a document control function; lifecycle states are attributes of the requirement objects within those documents.

13. 13 In the context of planning, how does 'Requirement Verification' differ from 'Requirement Validation'?

    One checks if the requirement is 'written right,' while the other checks if it's the 'right requirement'.

    Verification ensures requirements are well-formed and testable, while validation ensures they support business needs.

    Verification focuses on the technical quality of the requirement statements, while validation focuses on whether they solve the right problem.

    • ✗ Verification checks for technical feasibility, while validation checks for organizational feasibility.

      Both feasibility types are analyzed earlier; verification and validation specifically deal with the quality and alignment of written requirements.

    • ✗ Verification is done by the project manager, while validation is done exclusively by the business analyst.

      Both activities are core business analysis tasks, though they involve different stakeholders for feedback.

    • ✗ Verification happens during the Planning phase, while validation only happens during the Evaluation phase.

      Both verification and validation should happen iteratively throughout Analysis to ensure the baseline is accurate and valuable.

14. 14 A business analyst is tailoring the business analysis approach for an exploratory product initiative with high uncertainty. Which planning decision is most appropriate?

    Think about which planning style prioritizes learning and speed over rigid documentation.

    Focus on iterative models, prototypes, and backlog refinement instead of exhaustive text-based specifications.

    Adaptive planning uses lean documentation and iterative feedback to manage requirements as the team's understanding of the solution evolves.

    • ✗ Require formal sign-off for every individual requirement before any prototyping can occur.

      Excessive formality in high-uncertainty projects can stifle innovation and prevent the learning that comes from prototyping.

    • ✗ Use a plan-driven Requirements Traceability Matrix with bi-directional links to every code module.

      Highly detailed RTMs in rapidly changing environments often become obsolete quickly and require excessive maintenance effort.

    • ✗ Skip the change control process entirely since the project is in a state of constant flux.

      Even agile projects need change control via backlog prioritization; skipping it leads to uncontrolled scope creep.

15. 15 Task 4 of the Planning domain involves selecting requirements change control methods. Why is it important to establish these methods before a requirements baseline is set?

    Consider what happens when a stakeholder asks for 'just one more thing' after the scope has already been agreed upon.

    To provide a structured way to handle requests that fall outside the approved scope once the baseline is established.

    Once a baseline is set, it represents a commitment; change control ensures that any deviations are analyzed for impact and formally approved.

    • ✗ To ensure that all stakeholders have an equal vote in every change request.

      Change control defines the *process* for decisions, but authority is usually centralized in a Change Control Board rather than an equal vote.

    • ✗ To allow the team to begin development without needing a project sponsor.

      A project sponsor is still required for funding and high-level direction, regardless of the change control process.

    • ✗ To guarantee that no changes will be allowed for the duration of the project.

      Change control is not about *preventing* change, but about *managing* it to protect the project's integrity and value.

16. 16 While creating a communication matrix (Task 3), the business analyst identifies that the regulatory compliance officer requires a different level of detail than the development team. How should this be handled?

    This involves applying the principle that 'one size does not fit all' in professional communications.

    Tailor the frequency and format of the requirements information to match the specific needs of each stakeholder group.

    Effective communication planning ensures that each stakeholder receives the right information in a way that allows them to perform their role.

    • ✗ Send the same comprehensive document to all stakeholders to ensure everyone has access to the same information.

      Providing too much irrelevant detail to stakeholders can lead to 'information overload' and missed critical communications.

    • ✗ Only provide information to the development team, as they are the ones building the solution.

      Ignoring compliance stakeholders risks legal or safety issues that could halt the project later.

    • ✗ Instruct the compliance officer to attend all daily stand-ups to stay informed of every minor requirement change.

      Requiring all stakeholders to attend every meeting is an inefficient use of time and does not provide targeted, relevant information.

17. 17 A business analyst is defining the requirements traceability strategy. They must choose between tracing requirements to 'business goals' or tracing them to 'software code.' Which option represents 'forward' traceability?

    Identify the direction that moves from the 'source' of a need toward the 'delivery' of a solution.

    Tracing from business goals forward to requirements and then to solution components.

    Forward traceability follows a requirement from its origin through the design and implementation phases to ensure it is addressed.

    • ✗ Tracing from code back to business goals.

      Tracing from an output back to an input or origin is considered 'backward' or 'reverse' traceability.

    • ✗ Tracing only between the different versions of the requirements document in the VCS.

      Versioning manages changes to a document over time, which is distinct from tracing the relationships between different types of artifacts.

    • ✗ Tracing from stakeholders to the project manager.

      Traceability links requirements to business needs or delivery artifacts, not to the communication lines between individuals.

18. 18 Which tool is best suited for Task 4 (Change Control) when the business analyst needs to evaluate how a single requirement change will affect connected requirements and downstream components?

    Look for an artifact that shows how requirements are linked together like a web.

    Requirements Traceability Matrix (RTM)

    The RTM explicitly maps relationships between requirements, making it the essential tool for performing comprehensive change-impact analysis.

    • ✗ Fishbone Diagram

      Fishbone diagrams are used for root cause analysis in Needs Assessment, not for tracking requirement dependencies.

    • ✗ Kano Model

      The Kano model is used to categorize and prioritize features based on customer satisfaction, not to map technical dependencies.

    • ✗ WBS Model

      A Work Breakdown Structure (WBS) decomposes work tasks, but it does not typically show the logical dependencies between specific product requirements.

19. 19 A business analyst is specifying the document control procedure. They include a 'revision history' section for each requirement document. This is primarily an application of which planning capability?

    This involves keeping track of 'who' did 'what' to the file over time.

    Document Control

    Tracking who changed a document, when, and why is a core function of maintaining a standard for versioning and audit trails.

    • ✗ Requirements Change Control

      Change control focuses on the governance and approval of the changes, while the revision history itself is an artifact of document control.

    • ✗ BA Resource Planning

      Revision history does not help in estimating the labor effort or skills needed for future tasks.

    • ✗ Stakeholder Engagement

      While it provides transparency, a revision history is a technical procedural requirement for document management rather than an engagement strategy.

20. 20 What is the primary danger of a 'weak stakeholder judgment' error during the Planning phase?

    Think about the risks involved when the 'wrong people' are making decisions or the 'right people' are ignored.

    Crucial influencers or affected groups will be omitted from the elicitation and approval processes.

    Poor judgment in identifying stakeholders leads to missing requirements and potential rejection of the solution during the Evaluation phase.

    • ✗ The business analyst will select the wrong color for the UI buttons.

      This is a minor requirement detail that can be fixed later and does not represent a foundational planning failure.

    • ✗ The project will be canceled by the sponsor due to a lack of technical feasibility.

      Feasibility issues are generally uncovered during Needs Assessment, not as a result of poor stakeholder judgment in planning.

    • ✗ The requirements traceability matrix will become too large to manage efficiently.

      An oversized RTM is a tool-scaling issue, not necessarily a direct result of poor stakeholder judgment.

21. 21 A business analyst is using 'Analogous' estimation for a new project's BA activities. Which source of information is most critical for this technique to be effective?

    Identify the estimation method that relies on saying, 'This project looks a lot like the one we did last year'.

    Historical data and documentation from a similar project completed in the past.

    Analogous estimation relies on using 'actuals' from a previous, comparable initiative as a baseline for the current project's estimates.

    • ✗ The current market salary for business analysts in the local area.

      Labor rates are used for budgeting, but analogous estimation focuses on the *duration* or *effort* based on similar past work.

    • ✗ A detailed decomposition of every requirement into individual software tasks.

      Decomposition into tasks is a characteristic of Bottom-Up estimation, not the high-level comparison used in Analogous estimation.

    • ✗ The results of a Kano model survey performed during Needs Assessment.

      A Kano model categorizes features but does not provide historical benchmarks for the effort required to manage those features.

22. 22 When developing the Requirements Management Plan (Task 3), the business analyst defines a 'Conflict Resolution Process.' Why is this included in the BA plan rather than just the general project plan?

    Consider how an analyst should proceed when two different departments want a system to do two different, incompatible things.

    To provide a structured path for resolving competing stakeholder needs regarding the product's features.

    Requirement conflicts are common; having an agreed-upon escalation path prevents project delays and ensures objective decision-making.

    • ✗ Because requirements conflicts are more expensive to fix than scheduling conflicts.

      While often true, the cost is not the primary reason for including the process in the BA plan; it's about the domain-specific nature of the conflict.

    • ✗ To ensure that the business analyst has the final say in all technical disagreements.

      The analyst facilitates resolution but often defers to subject matter experts or sponsors for final technical decisions.

    • ✗ To eliminate the need for stakeholder sign-off on the requirements baseline.

      Sign-off is still a critical milestone for establishing a baseline, regardless of how conflicts are resolved during the process.

23. 23 A business analyst is assigned to a project where the team uses 'User Story Mapping.' In which task of the Planning domain would the analyst decide to use this specific modeling technique?

    Look for the task that involves building the 'roadmap' or 'how-to' guide for all future business analysis work.

    Developing the requirements management plan (Task 3).

    The Requirements Management Plan is where the analyst identifies the methods and techniques that will be used for eliciting and analyzing requirements.

    • ✗ Reviewing the business case (Task 1).

      Reviewing the business case provides context but does not involve selecting specific modeling or elicitation techniques.

    • ✗ Defining the strategy for requirements traceability (Task 2).

      Traceability strategy defines the *logic* of relationships, while story mapping is a *technique* used to perform the analysis itself.

    • ✗ Selecting document control methods (Task 5).

      Document control deals with versioning and security, not with the analytical techniques used to discover requirements.

24. 24 A business analyst is defining the requirements change control process (Task 4). They decide that any change impacting the project budget by more than $5\%$ must be approved by the Project Steering Committee. This is an example of defining:

    Think about a 'rule' that determines when a decision is too big for the team to make on their own.

    A Change Control Threshold.

    Thresholds are limits that determine when a change is considered 'minor' (approvable by the BA/PM) or 'major' (requiring steering committee approval).

    • ✗ A Requirements Lifecycle State.

      Lifecycle states track individual requirement status, not the threshold for organizational escalation and approval.

    • ✗ An Elicitation Protocol.

      Elicitation protocols define how information is gathered, while this scenario defines how a change decision is made.

    • ✗ A Document Control Standard.

      Document standards deal with the format and storage of files, not the budgetary impact of the requirements within those files.

25. 25 A business analyst is performing Task 6 (Defining business metrics and acceptance criteria). They are struggling to get stakeholders to agree on what 'success' looks like. What is the most effective next step?

    Consider the core responsibility of a business analyst when multiple parties have conflicting views on a solution's goal.

    Facilitate a consensus-building workshop to align stakeholder definitions of success with the business case goals.

    Collaboration is key to defining criteria that stakeholders will actually sign off on during the Evaluation phase.

    • ✗ Write the acceptance criteria based on the analyst's own best professional judgment.

      The analyst should not unilaterally define success, as the criteria must be validated and accepted by the business stakeholders who will use the solution.

    • ✗ Postpone defining criteria until the solution is built and stakeholders can see the physical output.

      Delaying criteria definition until the end of the project risks building a solution that fails to meet stakeholder needs, leading to costly rework.

    • ✗ Assign the task of defining success solely to the technical development team.

      The development team defines technical performance, but the business stakeholders must define the business value and acceptance metrics.