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

Expand any question to reveal the correct answer and explanation.

1. 1 A business analyst is facilitating a requirements workshop where two senior stakeholders from different departments disagree on the priority of a specific feature. Following the PMI-PBA standards for the Analysis domain, what is the most effective first step?

   Consider the role of the business analyst in establishing a shared understanding and using objective frameworks before involving project-level governance.

   Facilitate a discussion to review the agreed-upon prioritization criteria and stakeholder values.

   Applying agreed criteria and facilitating consensus within the Analysis domain is the primary responsibility before external escalation.

   • ✗ Escalate the conflict to the project manager for a final decision on the project schedule.

     Escalation to the project manager is a later step and bypasses the analyst's role in facilitation and consensus building.

   • ✗ Submit the conflicting requirements to the Change Control Board (CCB) for formal evaluation.

     The CCB is typically involved during the Traceability and Monitoring phase for changes to a baseline, not during initial requirement prioritization.

   • ✗ Identify the stakeholder with higher organizational authority and prioritize their requirement.

     Allowing senior voices to dominate requirement decisions without analysis is a common error that ignores business value and goals.

2. 2 During the process of requirements decomposition, a project team is struggling to maintain the relationship between high-level business needs and granular functional requirements. Which tool is best suited to verify that every lower-level requirement remains aligned with a business objective?

   Identify the artifact used to track requirements across their entire lifecycle and maintain links between different levels of abstraction.

   Requirements Traceability Matrix (RTM)

   An RTM is specifically designed to link requirements from their origin to the deliverables, ensuring bi-directional alignment.

   • ✗ CRUD Matrix

     A CRUD matrix focuses on the lifecycle of data (Create, Read, Update, Delete) within a system rather than vertical alignment with objectives.

   • ✗ Ishikawa Diagram

     An Ishikawa (fishbone) diagram is used for root cause analysis during Needs Assessment, not for mapping requirement hierarchies.

   • ✗ Business Case

     While providing context, the business case is a high-level document and lacks the granular tracking needed for decomposed requirements.

3. 3 In a scenario where a business analyst needs to obtain a consensus from a geographically dispersed group of experts who are prone to 'groupthink' or being influenced by dominant personalities, which decision-making technique is most appropriate?

   Think of an iterative process that relies on anonymity to ensure objective, expert-driven results.

   Delphi Technique

   The Delphi technique uses anonymous rounds of surveys to reach consensus, specifically preventing dominant voices from biasing the expert pool.

   • ✗ Nominal Group Technique

     This technique involves face-to-face interaction and voting, which may not mitigate the influence of dominant personalities as effectively as anonymous methods.

   • ✗ Multi-voting

     Multi-voting is a prioritization tool that identifies top choices from a list but does not inherently protect against the bias of influential individuals.

   • ✗ Unanimity

     Unanimity is a decision state where everyone agrees, but it is not a technique for managing the social dynamics of the decision-making process.

4. 4 When developing requirements specifications for a complex system integration, the business analyst creates a conceptual model to define entities, their attributes, and the rules governing their relationships. What type of model is being used?

   This model is essential for ensuring that business terms are consistent and that the technical database design reflects business reality.

   Data Model

   Data models, such as entity-relationship diagrams, are used to clarify business terms, relationships, and data-related rules.

   • ✗ Process Model

     Process models focus on actors, activities, and handoffs rather than the static structure of data and business rules.

   • ✗ Interface Model

     Interface models (like wireframes or report tables) focus on user interaction or system exchange points rather than underlying data structures.

   • ✗ Scope Model

     Scope models define boundaries and high-level boundaries of the solution, not the detailed attributes of business entities.

5. 5 A requirement states: 'The system must be highly user-friendly and respond to all requests within a reasonable timeframe.' According to requirement verification principles, why is this requirement problematic?

   Consider the quality criteria used to determine if a requirement can be effectively tested and implemented.

   It contains ambiguous and non-measurable terms.

   Terms like 'user-friendly' and 'reasonable' are subjective and cannot be objectively tested or verified.

   • ✗ It lacks validation against the business case.

     While validation is important, the primary issue here is the lack of objective quality within the statement itself.

   • ✗ It fails to identify the primary stakeholder.

     A requirement does not always need to name a specific stakeholder to be well-formed, though it must be testable.

   • ✗ It focuses on the solution rather than the business need.

     This is a characteristic of requirement types, but the fundamental flaw preventing development is its lack of specificity.

6. 6 An analyst is performing Task 2 of the Analysis domain: Analyze, decompose, and elaborate requirements. They use a technique to show actors, activities, decisions, and controls. Which pitfall should they be most careful to avoid?

   The goal of modeling is not just documentation but clarifying capabilities and uncovering product options.

   Creating diagrams that reproduce current inefficiencies without analysis.

   A common mistake in process modeling is simply documenting the 'as-is' state without identifying improvements for the 'to-be' state.

   • ✗ Ignoring the technical implementation risks.

     While important, this is usually part of risk analysis rather than a primary failure mode of process modeling.

   • ✗ Using user stories instead of use cases for hardware components.

     This relates to methodology tailoring rather than a logical error in the act of modeling a process.

   • ✗ Defining business metrics before the solution is implemented.

     Defining metrics early is a recommended practice in Planning and Analysis to ensure the solution's success can be measured.

7. 7 The project team must decide which requirements will be included in a release. They use a prioritization method where they categorize requirements as 'Must-have', 'Should-have', 'Could-have', and 'Won't-have'. Which technique are they using?

   Look for the acronym that represents the specific categories mentioned in the question.

   MoSCoW Analysis

   MoSCoW is the standard acronym for this specific four-category prioritization technique.

   • ✗ Weighted Criteria Matrix

     Weighted criteria involve assigning numerical scores based on specific factors rather than categorical grouping.

   • ✗ Kano Model

     The Kano model classifies requirements based on customer satisfaction (Basic, Performance, Excitement), not release categories.

   • ✗ Timeboxing

     Timeboxing is a method of allocating fixed time for activities, not a method for categorizing requirement importance.

8. 8 A business analyst is working on a hybrid project. The hardware components follow a Waterfall methodology, while the software components are iterative. Which 'Correct Action' aligns with the Lifecycle Rule for requirements planning?

   Recall how business analysis practices should adapt across different project methodologies.

   Tailor the approach to use plan-driven specifications for hardware and user stories for software.

   The Lifecycle Rule requires tailoring the requirements approach to match the delivery method of each component.

   • ✗ Mandate the use of user stories for both hardware and software to maintain consistency.

     Applying Agile techniques to Waterfall components can lead to poor planning and mismanaged expectations.

   • ✗ Convert the entire project to a Waterfall model to ensure all requirements are baseline-compliant.

     Forcing a methodology shift ignores the benefits of Hybrid environments and violates the principle of methodology neutrality.

   • ✗ Use evolving prototypes for hardware and detailed text-based specifications for software.

     This reverses the logical application of methodologies, as hardware typically requires more rigid, upfront planning.

9. 9 During Task 4 of the Analysis domain, the business analyst is allocating accepted requirements. What must they balance against the value proposition to create a requirements baseline?

   Focus on the primary project variables that must be aligned to ensure a realistic delivery roadmap.

   Scope, schedule, budget, and resource constraints.

   Creating a baseline requires balancing what is valuable against the real-world limits of scope, time, cost, and people.

   • ✗ Stakeholder interest and technical feasibility.

     These are factors for evaluation, but the task specifically mentions constraints related to project delivery.

   • ✗ Current-state and future-state process maps.

     Mapping is an analysis activity used to define requirements, not the primary set of constraints used for final allocation.

   • ✗ Internal and external environmental factors.

     These factors are generally assessed during Needs Assessment rather than the final allocation of requirements to a baseline.

10. 10 Which validation technique involves demonstrating a simplified version of a solution to stakeholders to assess their satisfaction and agreement before full-scale development?

    Think of a 'hands-on' or 'visual' way to confirm that requirements support the actual business need.

    Solution Prototyping

    Prototyping is a core validation tool used to elicit feedback and confirm that a solution meets requirements and delivers value.

    • ✗ Peer Review

      Peer reviews involve colleagues examining documents for quality, which is a verification activity rather than solution validation.

    • ✗ Root Cause Analysis

      Root cause analysis identifies the source of a problem, not the viability of a proposed solution's requirements.

    • ✗ Data Dictionary

      A data dictionary defines data elements and is a specification tool, not a method for validating stakeholder satisfaction.

11. 11 In the Analysis domain, Task 7: Validate requirements, aims to ensure that requirements are complete, accurate, and aligned with what specific element?

    Recall the fundamental distinction between verification (quality of the requirement) and validation (value of the requirement).

    Goals, objectives, and the value proposition.

    Validation ensures requirements are not just well-written, but actually solve the business problem and deliver value.

    • ✗ The project schedule and resource plan.

      These are delivery constraints rather than the business drivers used to validate the 'rightness' of a requirement.

    • ✗ Software development standards and coding guidelines.

      Alignment with standards is a component of verification, not the business-focused validation against goals.

    • ✗ The architectural design and system interface table.

      Requirements should drive design; validating against design would be circular and miss the business alignment.

12. 12 A business analyst is using a weighted ranking matrix to evaluate product options. What is the primary benefit of using this specific technique?

    This technique helps analysts avoid 'gut-feeling' decisions when choosing between multiple plausible solutions.

    It adds objectivity to a recommendation by combining pair-matching with weighted criteria.

    Weighted ranking ensures that decisions are based on systematic evaluation rather than personal preference.

    • ✗ It provides an anonymous consensus from a group of experts.

      This describes the Delphi technique, whereas weighted ranking involves scoring against criteria.

    • ✗ It identifies the root cause of variances in solution performance.

      Root cause analysis tools like the 5 Whys are used for variances, not for ranking solution options.

    • ✗ It determines the number of stakeholders required for requirement sign-off.

      Stakeholder identification and sign-off protocols are part of Planning and Stakeholder Analysis, not ranking matrices.

13. 13 While writing requirements specifications (Task 6), an analyst includes process models such as user stories. To be 'suitable for development', what must these stories be?

    The goal of a specification is to communicate requirements effectively to those who will build the solution.

    Measurable and actionable.

    To be useful for developers, requirements must clearly communicate what needs to be built in a way that can be verified.

    • ✗ Approved by the Change Control Board (CCB).

      The CCB approves changes to baselines, but the initial 'suitability' is a matter of specification quality and measurability.

    • ✗ Linked to a data flow diagram physical model.

      While models are related, a user story's suitability is not strictly dependent on its link to a physical data flow diagram.

    • ✗ Documented using a text-heavy specification template.

      Suitability is about clarity and measurability, not the specific length or format of the documentation.

14. 14 A team is evaluating solution results and finds that the percentage of defects stemming from poorly written requirements is high. Which task from the Analysis or Evaluation domain would they revisit to improve this metric?

    Focus on the step where the analyst ensures requirements are accurate, complete, and aligned with the intended solution.

    Task 7: Validate requirements

    Improving the accuracy and completeness of requirements through validation sessions directly reduces downstream defects.

    • ✗ Task 1: Elicit requirements

      Elicitation gathers information, but the 'writing' and quality checking happen in specification and verification/validation tasks.

    • ✗ Task 3: Obtain stakeholder sign-off

      Sign-off is a consensus activity; it doesn't inherently improve the technical quality of the requirements if they were already poor.

    • ✗ Task 1: Review the business case

      This task provides context but is too high-level to address specific defects in requirement documentation quality.

15. 15 Which analytical tool is best suited for clarifying actors, activities, and handoffs in a business process to clarify capabilities?

    This tool is often used in both Waterfall and Agile environments to define system-user interactions.

    Use Cases

    Use cases are designed to describe the interactions between actors and a system to achieve a specific goal.

    • ✗ Data Dictionary

      A data dictionary defines the structure and attributes of data elements, not the behavior of actors or activities.

    • ✗ Wireframes

      Wireframes are interface models that focus on layout and user interaction points rather than underlying process steps.

    • ✗ Pareto Diagram

      A Pareto diagram is a quality tool used to identify the most significant causes of problems, not for process modeling.

16. 16 An analyst is assigned to a project where the requirements involve sensitive information. Which elicitation technique is most appropriate for drawing out nuanced, individual stakeholder needs in this context?

    Consider the technique that provides the highest level of privacy and detail between the analyst and the source.

    Stakeholder Interviews

    Interviews are ideal for one-on-one, in-depth understanding, especially when information is confidential or complex.

    • ✗ Brainstorming

      Brainstorming is a group technique that may prevent stakeholders from sharing sensitive or confidential concerns.

    • ✗ Focus Groups

      Focus groups involve group dynamics which are better for discovering shared attitudes than confidential, individual details.

    • ✗ Surveys

      Surveys reach large populations but often produce shallow evidence and lack the 'probing' ability needed for nuanced needs.

17. 17 A stakeholder requests a functional change during a design workshop. According to the Scope Rule, what is the 'Correct Action' for the business analyst?

    Protecting the requirements baseline requires a systematic approach to evaluating new requests.

    Document the request and perform a formal impact assessment against the baseline.

    Protecting the baseline requires analyzing how a change affects scope, traceability, and related components before approval.

    • ✗ Ask the developer to implement the change to keep the project moving.

      Implementing changes immediately without analysis leads to scope creep and uncontrolled alterations.

    • ✗ Reject the request immediately as it was not part of the initial elicitation sessions.

      Arbitrarily rejecting requests without evaluation is a common student error; changes must be managed, not just blocked.

    • ✗ Instruct the product owner to add the request to the bottom of the backlog.

      Adjusting the backlog without an impact analysis is incorrect because the change might have unseen dependencies or risks.

18. 18 The Analysis domain involves securing formal stakeholder consensus on the requirements baseline (Task 5). What is the primary purpose of this task?

    Sign-off is the bridge between finalizing analysis and beginning the development/execution phase.

    To achieve stakeholder approval and facilitate a shared commitment to the scope.

    Obtaining sign-off ensures that all key parties agree on what will be delivered, preventing future scope disputes.

    • ✗ To finalize the project budget and resource allocation.

      These are project management outputs that use the requirements baseline but are not the primary goal of the task itself.

    • ✗ To complete the Traceability Matrix for the project lifecycle.

      The matrix is a tool used during this and other tasks, but 'completing' it is not the same as securing consensus.

    • ✗ To validate that the solution satisfies all technical coding requirements.

      Technical verification happens during development and testing; baseline sign-off is about business and stakeholder agreement.

19. 19 In the context of the Analysis domain, which modeling technique is used to describe the valid states an entity can take and the transitions between them?

    Think of a diagram that tracks an object (like an order or a user account) from 'new' to 'closed'.

    State Diagram

    State diagrams specifically model the lifecycle of a single object or entity within a system.

    • ✗ Process Flow Diagram

      Process flows focus on activities and events rather than the specific status changes of a single entity.

    • ✗ CRUD Matrix

      A CRUD matrix identifies which processes interact with which data but doesn't necessarily show transitions or lifecycles.

    • ✗ Data Flow Diagram

      Data flow diagrams show how data moves through a system but do not define the specific states of that data.

20. 20 When an analyst elaborates acceptance criteria (Task 8), they define 'observable conditions' that demonstrate requirement satisfaction. What should they avoid doing to keep these criteria effective?

    Vague criteria lead to disputes during the Evaluation phase when determining if the solution 'passed'.

    Using phrases such as 'user-friendly' or 'efficient' without measurable conditions.

    Effective acceptance criteria must be objective and measurable so that there is no ambiguity during testing.

    • ✗ Collaborating with stakeholders to define quality metrics.

      Collaboration is a required part of defining metrics to ensure they align with business expectations.

    • ✗ Linking the criteria to specific use cases or user stories.

      Linking criteria to specific requirements is a best practice for traceability and verification.

    • ✗ Using 'Given-When-Then' frameworks for Agile projects.

      This is a standard and effective validation technique for Agile acceptance criteria.

21. 21 What is a core difference between 'Requirement Verification' and 'Requirement Validation' as tested on the PMI-PBA exam?

    One checks if the requirement is 'built right' (standards), the other checks if it's the 'right requirement' (needs).

    Verification checks for quality/completeness; Validation checks for business value alignment.

    Verification ensures the requirement is 'well-formed', while validation ensures it addresses the 'right problem'.

    • ✗ Verification is done by stakeholders; Validation is done by developers.

      Both activities involve analysts and often stakeholders; the distinction lies in the 'what' is being checked, not who checks it.

    • ✗ Verification occurs during Evaluation; Validation occurs during Needs Assessment.

      Both primarily occur during the Analysis domain, though they are revisited later in the lifecycle.

    • ✗ Verification uses prototypes; Validation uses peer reviews.

      These tools are often reversed; prototypes are powerful for validation, and peer reviews are often used for verification.

22. 22 During a requirements workshop, a stakeholder gives vague feedback. What should the analyst do to maintain the integrity of the Analysis domain?

    The analyst's role is to discover and capture requirements with supporting details, not just record statements.

    Ask clarifying, probing questions to remove the ambiguity.

    Active facilitation and probing are necessary to convert vague feedback into actionable requirements.

    • ✗ Document the feedback exactly as stated to ensure the stakeholder feels heard.

      Recording ambiguity verbatim without analysis creates poor specifications and downstream defects.

    • ✗ Fill the gap with the analyst’s own assumptions based on previous projects.

      Assumptions are a major source of requirement errors and should be avoided in favor of direct elicitation.

    • ✗ Ignore the feedback if it does not fit into a standard use case format.

      Analysts must address all stakeholder input to ensure completeness and identify potential conflicts.

23. 23 A business analyst is using a CRUD matrix to analyze requirements. What is the primary purpose of this specific analytical technique?

    Think about the lifecycle of data elements and which processes act upon them.

    To map how data is created, read, updated, and deleted by various processes.

    The CRUD matrix is a data analysis tool that ensures data lifecycle completeness across the system.

    • ✗ To identify missing actors or duplicate processes.

      While it may help, this is more the domain of use cases and process flow diagrams.

    • ✗ To determine the financial soundness of a specific solution option.

      Cost-Benefit Analysis is the tool used for evaluating financial soundness, not a CRUD matrix.

    • ✗ To validate the user interface design using wireframes.

      Interface models like wireframes are separate from the logical data mapping provided by CRUD.

24. 24 In Task 3: Evaluate product options, an analyst must choose between several resolution approaches. Which factor should they advocate for most strongly?

    The analyst serves as an advocate for the organization's goals and future state.

    The most advantageous resolution that optimizes benefits and minimizes risks.

    The goal is to find the solution that provides the best equilibrium between expenses, advantages, and risks.

    • ✗ The option with the lowest upfront implementation cost.

      Cost is a factor, but alignment with goals and value optimizes long-term business success.

    • ✗ The option that can be delivered in the shortest timeframe.

      Speed is a constraint, but delivering a fast solution that doesn't solve the core problem is a failure.

    • ✗ The resolution supported by the stakeholder with the highest authority.

      Decisions should be based on objective evaluation and value, not solely on organizational power dynamics.

25. 25 A team reached a decision on requirements. One approach received $33\%$ of the votes, while no other approach achieved more than $25\%$. Which decision role was used?

    This role is often used when there are multiple options and a quick decision is needed without needing a strict majority.

    Plurality

    Plurality means the option with the most votes is selected, even if it does not exceed $50\%$.

    • ✗ Majority

      Majority requires more than $50\%$ of the votes, which was not achieved in this scenario.

    • ✗ Unanimity

      Unanimity requires $100\%$ agreement, which is not represented by a $33\%$ vote.

    • ✗ Autocratic

      An autocratic decision is made by one individual rather than through a stakeholder voting process.