25 Questions — PMI – PMI-PBA : Certified Professional in Business Analysis - Domain 4 - Traceability and Monitoring

Expand any question to reveal the correct answer and explanation.

1. 1 A business analyst is working on a hybrid project where software is iterative and hardware follows a predictive lifecycle. A stakeholder requests a modification to the hardware component's specification. According to the 'Lifecycle Rule', what is the most appropriate action for managing this change?

   Consider which governance process applies to the 'plan-driven' portion of a project versus the 'iterative' portion.

   Perform a formal impact assessment against the hardware baseline and submit it to the Change Control Board.

   For predictive (plan-driven) components in a hybrid project, changes must be formally evaluated against the baseline and processed through a structured change control board to maintain integrity.

   • ✗ Add the request to the product backlog and prioritize it during the next sprint planning session.

     While suitable for the software component, hardware elements in this scenario follow a plan-driven schedule where backlogs are not the primary control mechanism for baselined specifications.

   • ✗ Update the hardware specification document immediately to ensure the design team has the most current information.

     Updating the document before a formal impact analysis and approval bypasses governance and introduces uncontrolled scope changes.

   • ✗ Reject the request because hardware specifications must remain fixed once the design phase begins in a hybrid environment.

     Legitimate business needs should be considered regardless of the lifecycle; the error lies in skipping the assessment process, not in the possibility of change itself.

2. 2 When monitoring requirements throughout their lifecycles (Task 2), what is the analyst's primary objective regarding supporting artifacts?

   Distinguish between tracking the status of the requirement itself and overseeing the development of the documents that prove it was built correctly.

   To ensure that items such as models, design documentation, and test cases are produced and approved at each stage.

   Monitoring focuses on the creation and approval of the necessary documentation that supports the requirement as it moves through the delivery cycle.

   • ✗ To update the status of each requirement from 'In Progress' to 'Completed' in the tracking tool.

     Updating status is specifically defined as Task 3, whereas Task 2 is concerned with the existence and quality of the supporting evidence.

   • ✗ To capture the sources and relationships of requirements to provide evidence of delivery.

     This describes Task 1 (Tracking), which focuses on the connectivity and lineage of requirements rather than the oversight of supporting work products.

   • ✗ To inform the project manager of any conflicts or risks identified during the analysis phase.

     Communication of status, risks, and conflicts is the core focus of Task 4, rather than the monitoring of artifact production.

3. 3 A stakeholder requests a feature that is not part of the approved requirements baseline. What is the correct first action for the business analyst to ensure baseline integrity?

   Think about the mandatory step that must occur before a decision-making body can review a change request.

   Evaluate the request and perform an impact assessment on scope, schedule, and risks.

   Before any change is accepted or rejected, a formal impact assessment must be conducted to understand how it affects the project constraints and baseline.

   • ✗ Inform the stakeholder that the baseline is locked and no changes can be made until the next project phase.

     Baselines can be changed through formal processes; outright rejection without review may disregard a high-value requirement.

   • ✗ Submit the request directly to the Change Control Board (CCB) for an immediate vote.

     The CCB requires an impact analysis to make an informed decision; the analyst must provide this evaluation first.

   • ✗ Instruct the development team to create a prototype to see if the feature is feasible before documenting it.

     Committing resources to development or prototyping before performing an impact assessment on the baseline contributes to scope creep.

4. 4 In a traceability environment, what does 'bi-directional' traceability specifically refer to?

   Think about the two opposite ends of the requirement lifecycle: its beginning and its end results.

   The ability to track a requirement forward to its deliverables and backward to its business origin.

   Bi-directional traceability ensures that every requirement is linked both to the need that justifies it and the artifacts that satisfy it.

   • ✗ The process of communicating status updates both to the project manager and the primary stakeholders.

     While communication goes to multiple parties (Task 4), bi-directional traceability is a technical link between requirements and project artifacts.

   • ✗ A documentation method that records both the current version and the previous version of a requirement.

     This refers to version control or document control (Planning Task 5) rather than the logical mapping of requirements across the lifecycle.

   • ✗ Ensuring that requirements are compatible with both Agile and Waterfall methodologies simultaneously.

     Traceability links requirements to project elements; it is not about the simultaneous application of conflicting methodologies.

5. 5 During the Traceability and Monitoring phase, the business analyst identifies a conflict between two requirements that were already baselined. What should be the primary focus of the status report regarding this issue?

   Focus on the responsibility of the analyst to maintain transparency when project specifics are in dispute.

   Highlighting the conflict and its potential risks to the project manager and key stakeholders.

   Task 4 of Traceability and Monitoring requires communicating requirement issues and conflicts to keep stakeholders informed of project status.

   • ✗ Choosing the requirement with the highest stakeholder priority and deleting the conflicting one.

     Unauthorized deletions violate baseline integrity; conflicts must be analyzed and resolved through formal channels.

   • ✗ Reworking the business case to justify the inclusion of both conflicting requirements.

     The business case justify investments; conflicts at the requirement level are typically resolved through analysis and stakeholder consensus, not by modifying the business case.

   • ✗ Updating the traceability matrix to show that both requirements are now in a 'deferred' status.

     Changing status without a decision-making process or impact assessment is an administrative error that hides the underlying conflict.

6. 6 A business analyst is configuring a notification workflow for a requirements repository. Which trigger is the most relevant for notifying stakeholders about updates that affect the repository's integrity?

   Look for the specific event that directly modifies the primary document used to track requirements.

   Any change to the requirements matrix.

   The requirements matrix is the central artifact for Traceability and Monitoring; any change to it directly impacts the baseline and stakeholder expectations.

   • ✗ Changes to stakeholder membership in the project directory.

     While important for communication, a change in personnel does not inherently change the requirements or the technical baseline of the product.

   • ✗ The completion of a single developer's unit testing phase.

     Unit test completion is a technical progress milestone, but it is not a requirement change trigger that necessitates a broad repository notification.

   • ✗ Periodic time-based reminders set for every Friday afternoon.

     Time-based triggers are not workflow triggers related to the actual content or modifications of the requirements matrix.

7. 7 Which artifact is specifically used to verify that the product design meets the stated requirements by showing dependencies between requirements and design elements?

   Identify the grid-like tool that provides a mechanism for tracking information across the product lifecycle.

   Traceability matrix

   The traceability matrix maps requirements to design elements, test cases, and verification results to ensure coverage and consistency.

   • ✗ Requirements management plan

     The plan defines 'how' activities will be performed but does not contain the actual mapping of specific requirements to design components.

   • ✗ Scope statement

     The scope statement defines solution boundaries at a high level but lacks the granular level of detail required for tracing individual requirements to design elements.

   • ✗ Stakeholder register

     The stakeholder register is a list of project participants and their interests, not a technical tool for mapping requirement-to-design dependencies.

8. 8 In the context of the PMI-PBA, what is the 'Scope Rule' designed to protect?

   Consider what an analyst is trying to prevent when they insist on a formal impact assessment for every new request.

   The approved requirements baseline.

   The Scope Rule ensures that changes are managed formally to prevent scope creep and maintain the integrity of what was previously agreed upon.

   • ✗ The project budget from over-allocation.

     While scope management affects budget, the specific 'Scope Rule' in the context of requirements focuses on protecting the baseline integrity.

   • ✗ The business analyst's authority over the product owner.

     The rules are about process and product integrity, not establishing hierarchy between project roles.

   • ✗ The number of stakeholders involved in a single elicitation workshop.

     The Scope Rule pertains to requirement changes and baseline protection, not the logistics of elicitation techniques.

9. 9 What is the primary difference between Task 1 (Track Requirements) and Task 2 (Monitor Requirements) within the Traceability and Monitoring domain?

   One task deals with the requirement's state/connections, while the other deals with the lifecycle's 'paper trail'.

   Tracking records the status and relationships, while monitoring ensures the production and approval of supporting artifacts.

   Tracking is about the 'what' and 'where' (status/links), while monitoring is about the 'process health' (ensuring artifacts exist and are approved).

   • ✗ Tracking is used in Waterfall projects, while monitoring is only used in Agile environments.

     Both activities are required across all methodologies, though the tools (RTM vs. Backlog) may differ.

   • ✗ Tracking is a planning activity, while monitoring occurs only during solution evaluation.

     Both are ongoing activities within Domain 4 that occur throughout the requirements lifecycle after the baseline is set.

   • ✗ Tracking involves the project manager, while monitoring is done exclusively by the testing team.

     The business analyst is responsible for both tasks, though they collaborate with many roles; monitoring is not limited to testing.

10. 10 When assessing the impact of a proposed requirement change, which of the following should be the analyst's focus to ensure 'Solution Verification' is later successful?

    Think about what is needed to prove that a solution component was built according to the approved requirements.

    Evaluating how the change affects existing test cases and the requirement-to-test evidence map.

    Impact analysis must consider downstream effects, particularly on testing evidence, to ensure the solution can still be verified against its requirements.

    • ✗ Determining if the change increases the total number of stakeholders in the project.

      While stakeholder involvement may shift, the primary concern for verification is the link between requirements and testable evidence.

    • ✗ Calculating the exact monetary penalty for missing a regulatory deadline.

      This is a business risk assessment; while relevant to the decision, it does not directly facilitate the technical 'Solution Verification' process.

    • ✗ Updating the business case to reflect the new expected value before performing any analysis.

      Value assessment is part of impact analysis, but updating the business case prematurely skips the required analysis of the change's technical feasibility.

11. 11 A business analyst is using a 'Requirement-to-test evidence map'. In which domain is this artifact most likely utilized, and for what purpose?

    This artifact serves as the final check that development efforts match the initial request.

    Evaluation; to confirm solution components are built according to requirements.

    Evidence maps are critical in the Evaluation domain for solution verification, proving that the developed product satisfies the documented needs.

    • ✗ Needs Assessment; to define the initial business case for the project.

      Needs Assessment occurs before requirements are even elicited, so test evidence would not yet exist.

    • ✗ Planning; to select the appropriate elicitation techniques for stakeholders.

      Planning establishes the roadmap for BA activities; evidence maps are results of the execution and evaluation phases.

    • ✗ Analysis; to decompose high-level business goals into user stories.

      Decomposition happens in the Analysis domain, but it relates to the structure of requirements, not the mapping to test evidence.

12. 12 If a requirement's status moves through various 'lifecycle states', which task ensures that these changes are documented and stakeholders are kept informed of the progress toward closure?

    Look for the task that focuses on the recording of progression rather than the evaluation of a new request.

    Task 3: Update a requirement’s status.

    Task 3 explicitly covers tracking requirements toward closure by recording status changes and communicating them to appropriate stakeholders.

    • ✗ Task 5: Manage changes to requirements.

      Task 5 is about evaluating 'change requests' to the baseline, whereas Task 3 is about tracking the 'natural progression' of a requirement through its states.

    • ✗ Task 1: Elicit or identify requirements.

      Elicitation is about gathering requirements (Analysis Domain), not managing their status once they have been identified and baselined.

    • ✗ Task 2: Define strategy for requirements traceability.

      Defining the strategy happens in the Planning domain; the actual updating of status is an execution task in Traceability and Monitoring.

13. 13 A stakeholder wants to know why a specific requirement is necessary. Which traceability link in the Requirements Traceability Matrix (RTM) provides the 'Rationale' or 'Source'?

    To justify a requirement's existence, you must look toward the project's 'upstream' artifacts.

    Backward traceability to business objectives and stakeholder needs.

    Tracing backward allows the analyst to prove that a requirement has a valid origin and supports a specific business goal or stakeholder request.

    • ✗ Forward traceability to design components and code modules.

      Forward traceability shows 'how' a requirement is being implemented, not 'why' it was needed in the first place.

    • ✗ Horizontal traceability to other requirements with shared dependencies.

      Horizontal links show how one requirement affects another, which helps with impact analysis but does not define the original rationale.

    • ✗ Vertical traceability to the project budget and resource plan.

      PMI-PBA traceability typically focuses on the relationship between business needs and solution artifacts, not direct links to administrative budget line items.

14. 14 The business analyst identifies that a requirement is 'volatile' during risk analysis. How does this affect the Traceability and Monitoring approach?

    Risk and uncertainty usually lead to a need for tighter control and oversight, not less.

    It requires more frequent monitoring of status and more rigorous impact analysis for change requests.

    Volatile requirements are more likely to change, requiring the analyst to be more vigilant in monitoring their state and assessing the effects of modifications.

    • ✗ It means the requirement should be removed from the baseline to prevent scope creep.

      Volatility is a risk to be managed, not a reason to automatically discard a potentially necessary business need.

    • ✗ It dictates that the project must switch from Waterfall to Agile immediately.

      While Agile handles change well, methodology selection is based on broader project factors, and one volatile requirement does not mandate a total project shift.

    • ✗ It simplifies traceability because volatile requirements do not need to be linked to test cases.

      Volatile requirements actually need stronger traceability because changes to them will impact more downstream artifacts.

15. 15 When performing 'Change-Impact Analysis' (Task 5), why is it critical to examine 'connected requirements' even for a seemingly minor change?

    A change in one part of a system often ripples through other parts due to how requirements are linked.

    To identify hidden dependencies that could cause the solution to fail or create inconsistencies.

    Impact analysis must look beyond the single change to ensure that related requirements, interfaces, and designs remain aligned and functional.

    • ✗ To ensure the stakeholder who requested the change is the only person notified.

      The goal of impact analysis is technical and procedural assessment, not limiting communication to a single party.

    • ✗ To prove that the business analyst has more knowledge than the development team.

      Impact analysis is a collaborative process to protect the project, not a tool for establishing professional dominance.

    • ✗ To justify increasing the project's contingency budget for every change request.

      Impact analysis identifies 'if' more budget is needed; it is not a mechanism for automatic or unjustified budget increases.

16. 16 What is the primary risk of allowing 'informal decisions' to alter approved requirements without a formal baseline management process?

    Think about the negative consequences of 'scope creep' and undocumented modifications.

    Unauthorized scope changes and loss of baseline integrity.

    Informal changes bypass governance, leading to scope creep and making it impossible to accurately track what is being delivered against what was agreed.

    • ✗ The project manager will lose interest in the business analysis activities.

      While undesirable, the primary risk of informal changes is to the product's scope and quality, not just the interest level of one role.

    • ✗ Stakeholders will be too satisfied and request even more changes.

      Satisfying stakeholders is good, but the danger of informal changes is the 'uncontrolled' nature of the modifications, not the satisfaction itself.

    • ✗ It will make the Requirements Traceability Matrix (RTM) too easy to maintain.

      Informal changes actually make the RTM harder to maintain because the links between requirements and deliverables become undocumented and unreliable.

17. 17 A business analyst is using 'Phased Baselining'. This approach is most effective for managing which type of project risk in the Traceability and Monitoring domain?

    Consider the approach that allows a project to 'absorb' new information in increments rather than all at once.

    High requirements volatility due to evolving regulations.

    Dividing requirements into subsets that can be baselined and delivered incrementally allows for better management of changing priorities and feedback.

    • ✗ A total lack of stakeholder engagement during the needs assessment.

      Baselining requires requirements to exist; if stakeholders aren't engaged, the problem lies in elicitation and analysis, not the baselining method.

    • ✗ The inability to use any software-based traceability tools.

      Phased baselining is a methodology approach, not a workaround for a lack of software tools; it can be done with or without them.

    • ✗ The risk that the development team will complete the project too early.

      Managing change and volatility is about protecting the solution's value and scope, not arbitrarily extending the timeline.

18. 18 In Task 4: Communicate requirements status, which of the following is NOT typically listed as a key piece of information to report?

    Focus on what is relevant to the 'health of the requirements' versus 'management of human resources'.

    The individual performance reviews of the development team members.

    Requirements status reporting focuses on the requirements themselves (risks, changes, conflicts), not HR-related performance evaluations of team members.

    • ✗ Unresolved conflicts between different stakeholder groups regarding a requirement.

      Conflicts are a critical status item because they can stall progress and affect the integrity of the requirements baseline.

    • ✗ Identified risks that may affect the implementation of a specific requirement.

      Communicating risks is a primary sub-task of status reporting to ensure the project manager can plan for contingencies.

    • ✗ The current approval status of the requirements baseline.

      Stakeholders must know if the requirements are still being drafted, are under review, or have been formally approved.

19. 19 A stakeholder wants to know how to submit a formal request for a requirement revision. Which planning document should the business analyst reference to provide the correct process?

    Look for the document that serves as the 'procedural manual' for modifications after the baseline is set.

    Change management plan

    The change management plan (or requirements change control process) outlines the channels and procedures for requesting and managing revisions.

    • ✗ Requirements traceability matrix

      The matrix tracks the *results* and *links* of requirements, but it does not define the *process* for requesting a change.

    • ✗ Business case

      The business case justifies the project but does not contain the operational procedures for daily requirement revisions.

    • ✗ Stakeholder engagement strategy

      While it defines how to interact with stakeholders, the specific protocol for requirement changes is found in the change management plan.

20. 20 During monitoring (Task 2), an analyst discovers that a design document was approved but does not address a mandatory regulatory requirement. What is the correct next step?

    Think about the analyst's responsibility to ensure 'bi-directional' consistency between requirements and design.

    Flag the gap in the traceability matrix and communicate the conflict to the project manager.

    Identifying that an artifact (design) does not support a requirement is a monitoring finding that must be tracked and communicated for resolution.

    • ✗ Ignore the issue because the design document has already received formal stakeholder approval.

      Approval does not negate the need for correctness; the analyst's role is to ensure all artifacts produced actually support the requirements.

    • ✗ Delete the regulatory requirement from the baseline to make the design document 'correct'.

      Deleting mandatory requirements to fit a flawed design is a major failure of professional ethics and project governance.

    • ✗ Wait until the testing phase to see if the system passes without the regulatory feature.

      Waiting until testing to address a known requirement-to-design gap is inefficient and significantly increases project risk and cost.

21. 21 What is the primary purpose of capturing the 'Source' of a requirement in a traceability artifact?

    Consider the need for 'accountability' and 'justification' in a structured project environment.

    To provide evidence that the requirement is delivered as stated and originated from an authorized person or document.

    Knowing the source allows for validation against business needs and ensures the requirement was not 'made up' or introduced through unauthorized channels.

    • ✗ To blame a specific stakeholder if the requirement later causes a project delay.

      Traceability is a quality and governance tool, not a mechanism for assigning blame to stakeholders.

    • ✗ To ensure that only one stakeholder is allowed to talk to the development team about that requirement.

      Knowing the source helps identify who to consult, but it is not intended to restrict collaborative communication between teams.

    • ✗ To categorize the requirement as either 'Agile' or 'Waterfall' based on who requested it.

      Methodology is determined by project characteristics, not the individual identity of the stakeholder who provided a requirement.

22. 22 An analyst is assessing the 'dependency' of a proposed change. Why is 'dependency analysis' included in the Traceability and Monitoring domain for change management?

    Requirements are rarely isolated; they often exist in a 'web' of interrelated needs.

    To determine how the change affects other requirements that rely on the one being modified.

    Many requirements are linked; a change to one may break others or require simultaneous updates elsewhere, which must be identified during impact analysis.

    • ✗ To calculate the number of hours each developer will spend on the change request.

      Detailed task estimation is usually a project management or development lead function, though it uses the analyst's impact findings.

    • ✗ To see if the stakeholder who requested the change is 'dependent' on the project manager's approval.

      Dependency in this context refers to logical and technical links between requirements, not the social hierarchy of project roles.

    • ✗ To ensure that no more than two requirements are ever linked to a single test case.

      There is no rule limiting the number of links; dependency analysis is about understanding 'relationships', not enforcing arbitrary numerical limits.

23. 23 A project uses 'Configuration Management' as part of its document control. How does this support the Traceability and Monitoring domain?

    Focus on the need for 'version control' and 'security' when managing a formal reference point.

    It provides a versioned, secure environment for storing requirements and ensuring baseline integrity.

    Configuration management systems (CMS) allow for controlled access and versioning, preventing unauthorized or undocumented changes to the baseline.

    • ✗ It automatically translates business requirements into executable programming code.

      CMS is a documentation and artifact management system, not an automated code generation tool.

    • ✗ It identifies which stakeholders are most likely to resist change.

      Stakeholder analysis (Needs Assessment/Stakeholder Engagement) identifies resistance; CMS manages the physical and digital 'artifacts' of the project.

    • ✗ It eliminates the need for a Change Control Board (CCB) by approving changes automatically.

      CMS supports the process by tracking versions, but it does not replace the human decision-making of a CCB.

24. 24 Which task specifically requires the business analyst to 'compare [changes] to the requirements baseline' to maintain artifact integrity?

    Identify the task that acts as the 'gatekeeper' for any modification to the project's agreed-upon scope.

    Task 5: Manage changes to requirements.

    This task focuses on the formal comparison of new requests against what was already approved to assess impact and preserve the baseline.

    • ✗ Task 1: Track requirements.

      Tracking records the current state and links but is not the specific step where a 'comparison' of a new change request occurs.

    • ✗ Task 3: Develop requirements management plan.

      This is a Planning task that defines *how* to compare changes, but the *actual execution* of the comparison happens in Domain 4, Task 5.

    • ✗ Task 2: Analyze and communicate solution gaps.

      This task belongs to the Evaluation domain and focuses on final product defects, not the management of changes to the requirements baseline during development.

25. 25 What is the most common mistake made during 'Traceability and Monitoring' that leads to rework during the testing phase?

    Think about the link that connects what was 'requested' to how it is 'checked'.

    Failing to maintain traceability links to test cases, leading to missed requirement coverage.

    If requirements are not traced to tests, testers may not know a requirement exists or may test it incorrectly, requiring costly rework when gaps are found.

    • ✗ Spending too much time reading and re-reading the business case.

      While time management is an issue, reading foundational documents is rarely the direct cause of testing rework compared to technical traceability failures.

    • ✗ Using a simple spreadsheet instead of a high-end database for the RTM.

      The choice of tool is less important than the 'accuracy and consistency' of the links themselves; a spreadsheet can be effective if managed well.

    • ✗ Allowing stakeholders to attend requirements workshops without an invitation.

      This is a logistical issue in the Analysis domain; rework in the 'testing phase' is more directly linked to failures in tracing and verifying the built solution.