ExamFinch.com My Study

Study guide

4.4 Assess Requirements Changes (Task 5.4)

Practice this exam

CCBA Certification of Capability in Business Analysis Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & CCBA Exam Foundation

1.1 CCBA Exam Structure, Eligibility & IIBA Framework 1.2 The Business Analysis Core Concept Model (BACCM™) 1.3 Requirements Classification Schema & Architecture 1.4 CCBA Competency & Proficiency Levels (Level 2 — Skilled)

2 Chapter 2: Business Analysis Planning and Monitoring

2.1 Plan Business Analysis Approach (Task 3.1) 2.2 Plan Stakeholder Engagement (Task 3.2) 2.3 Plan Business Analysis Governance (Task 3.3) 2.4 Plan Business Analysis Information Management (Task 3.4) 2.5 Identify BA Performance Improvements (Task 3.5)

3 Chapter 3: Elicitation and Collaboration

3.1 Prepare for Elicitation (Task 4.1) 3.2 Conduct Elicitation (Task 4.2) 3.3 Confirm Elicitation Results (Task 4.3) 3.4 Communicate Business Analysis Information (Task 4.4) 3.5 Manage Stakeholder Collaboration (Task 4.5)

4 Chapter 4: Requirements Life Cycle Management

4.1 Trace Requirements (Task 5.1) 4.2 Maintain Requirements (Task 5.2) 4.3 Prioritize Requirements (Task 5.3) 4.4 Assess Requirements Changes (Task 5.4) 4.5 Approve Requirements (Task 5.5)

5 Chapter 5: Strategy Analysis

5.1 Analyze Current State (Task 6.1) 5.2 Define Future State (Task 6.2) 5.3 Assess Risks (Task 6.3) 5.4 Define Change Strategy (Task 6.4)

6 Chapter 6: Requirements Analysis and Design Definition — Modeling & Architecture

6.1 Specify and Model Requirements (Task 7.1) 6.2 Verify Requirements (Task 7.2) 6.3 Validate Requirements (Task 7.3) 6.4 Define Requirements Architecture (Task 7.4)

7 Chapter 7: Requirements Analysis and Design Definition — Design & Value

7.1 Define Design Options (Task 7.5) 7.2 Analyze Potential Value and Recommend Solution (Task 7.6) 7.3 Estimation Techniques & Solution Trade-Offs 7.4 Acceptance and Evaluation Criteria Definition

8 Chapter 8: Solution Evaluation

8.1 Measure Solution Performance (Task 8.1) 8.2 Analyze Performance Measures (Task 8.2) 8.3 Assess Solution Limitations (Task 8.3) 8.4 Assess Enterprise Limitations (Task 8.4) 8.5 Recommend Actions to Increase Solution Value (Task 8.5)

9 Chapter 9: Essential BABOK Techniques

9.1 Core Elicitation & Analysis Techniques 9.2 Process, Data & Non-Functional Requirements Modeling 9.3 Financial Analysis & Business Case Techniques 9.4 Prioritization & Scope Techniques 9.5 Root Cause & Decision Analysis Techniques

10 Chapter 10: Underlying Competencies & Perspectives

10.1 Analytical Thinking, Problem Solving & Systems Thinking 10.2 Behavioral Characteristics, Communication & Interaction Skills 10.3 Business Acumen, Solution Knowledge & BA Tooling 10.4 The Five BABOK Perspectives in Practice

11 Chapter 11: CCBA Exam Mastery & Scenario Strategy

11.1 Deconstructing CCBA Scenario Questions & BABOK Logic 11.2 Common Traps, Distractors & Subtle BABOK Distinctions 11.3 Comprehensive 8-Week Study Plan & Exam Day Strategy

4.4 Assess Requirements Changes (Task 5.4)

Key Takeaways Explain This Topic AI

Task 5.4 evaluates the overall business and technical implications of proposed requirements modifications, additions, or deletions before any commitment to build is made.

Comprehensive impact analysis evaluates six dimensions: Cost/Benefit impact, Schedule impact, Resource capacity, Risk profile, Upstream/Downstream requirement dependencies, and Solution architecture.

Change assessment formality varies from formal Change Control Boards (CCB) in predictive environments to continuous backlog refinement and trade-off negotiation in adaptive/agile settings.

Following an impact analysis, the business analyst recommends one of four formal resolutions: Approve, Reject, Defer, or Modify/Request More Information.

All change assessments must align with the decision-making rules, authority thresholds, and governance protocols established during Task 3.3 (Plan BA Governance).

Last updated: August 2026

4.4 Assess Requirements Changes (Task 5.4)

Quick Summary: BABOK v3 Task 5.4 ( Assess Requirements Changes ) evaluates the implications of proposed changes to requirements and designs. Business analysts perform comprehensive impact analysis across cost, schedule, resources, risks, and dependencies to determine whether a proposed change delivers positive net value, and formulate formal recommendations to Approve, Reject, Defer, or Modify the request.

Purpose and Strategic Role of Task 5.4

The purpose of Assess Requirements Changes is to evaluate the implications of proposed changes to requirements and designs. Change is inevitable in business analysis. Market conditions fluctuate, customer behaviors shift, and technical discoveries emerge during execution. However, unmanaged change ("scope creep") is the leading cause of budget overruns, milestone delays, and software instability.

Task 5.4 does not aim to prevent change; rather, it ensures that every proposed change is evaluated systematically so that decision-makers understand the true cost, organizational disruption, and risk before committing enterprise resources. +-----------------------------------------------------------------------------------+

  • | BABOK Task 5.4 Structure |
  • +-----------------------------------------------------------------------------------+
  • | INPUTS: |
  • | * Requirements & Designs (Current baselined state) |
  • | * Proposed Change (New need, modification, or deletion request) |
  • | |
  • | ELEMENTS: |
  • | 1. Assessment Formality (Formal CCB vs. Adaptive backlog trade-offs) |
  • | 2. Impact Analysis (Cost, Schedule, Resources, Risks, Architecture, Dependencies)|
  • | 3. Impact on Value (Net business value vs. cost of disruption) |
  • | 4. Resolution / Recommendation (Approve, Reject, Defer, Modify) |
  • | |
  • | OUTPUTS: |
  • | * Requirements Change Assessment (Formal impact report and recommendation) |
  • +-----------------------------------------------------------------------------------+
  • The Formality Spectrum: Predictive vs. Adaptive Change Assessment

The approach to assessing changes is defined during Business Analysis Planning (Task 3.3: Plan BA Governance) and varies based on the delivery lifecycle. PREDICTIVE / FORMAL GOVERNANCE ADAPTIVE / AGILE GOVERNANCE

  • +------------------------------------+ +------------------------------------+
  • | * Formal Change Request (CR) Form | | * User Story in Backlog |
  • | * Change Control Board (CCB) Review| | * Product Owner Backlog Grooming |
  • | * Strict Version-Controlled Baseline| | * Scope Swapping / Trade-off Matrix|
  • | * Formal Contract / Budget Addendum| | * Continuous Value Prioritization |
  • +------------------------------------+ +------------------------------------+

Predictive Approach: Changes to baselined requirements require a formal Change Request (CR), detailed multi-departmental impact analysis, and voting by a formal Change Control Board (CCB) or Executive Sponsor.

Adaptive Approach: Changes are treated as new user stories placed into the product backlog. The Product Owner and squad evaluate the story's relative value and cost during backlog refinement. If a new high-value story is accepted into a fixed sprint, an equivalent volume of lower-priority work is swapped out.

The Six Dimensions of Comprehensive Impact Analysis

When a change is requested, the business analyst conducts an Impact Analysis across six interrelated dimensions. The analyst leverages the Requirements Traceability Matrix (Task 5.1) to follow upstream and downstream linkages. +-----------------------------------------------------------------------------------+

  • | The 6-Dimensional Impact Analysis Framework |
  • +-----------------------------------------------------------------------------------+
  • | |
  • | 1. BENEFIT & VALUE IMPACT Does the change increase net business value? |
  • | 2. COST IMPACT What is the total cost to build, test, & operate? |
  • | 3. SCHEDULE / TIMELINE Does it breach release dates or critical paths? |
  • | 4. RESOURCE CAPACITY Are specialized developers / SMEs required? |
  • | 5. RISK & QUALITY PROFILE Does it introduce security, legal, or tech risk? |
  • | 6. UPSTREAM & DOWNSTREAM Which other requirements, APIs, & tests break? |
  • | |
  • +-----------------------------------------------------------------------------------+
  • Detailed Dimensions Breakdown

Benefit and Value Impact: Analyzes whether the change delivers sufficient business value to justify its cost and operational disruption. Will it increase revenue, reduce customer churn, or satisfy a new legal mandate?

Cost Impact: Calculates total expenditure including analysis, engineering, refactoring existing code, user acceptance testing, updating documentation, and ongoing maintenance.

Schedule and Milestone Impact: Evaluates whether incorporating the change will push back committed delivery dates, delay sprint goals, or breach critical-path milestones.

Resource Capacity Impact: Identifies whether the change requires specialized technical skill sets (e.g., cryptography experts, cloud architects) or pulls key business SMEs away from daily operations.

Risk and Quality Profile: Identifies new risks introduced by the change (e.g., potential regressions in existing features, security vulnerabilities, or third-party vendor dependencies).

Upstream and Downstream Requirement Dependencies: Uses bidirectional traceability to determine which business goals (upstream), functional specifications (peer), architectural components (downstream), and test suites (validation) are impacted.

Impact Analysis Evaluation Matrix

Evaluation Dimension Key Questions for the BA Traceability Usage Common Risk / Pitfall

Net Value Impact "Does the ROI of this change exceed the cost of disruption?" Traces to Business Needs Accepting "nice-to-have" changes that dilute project focus

Schedule Impact "Will this push out our production release date?" Traces to Release Plan Overestimating team velocity to avoid admitting delays

Cost & Effort "How many development and QA hours are required?" Traces to Solution Requirements Ignoring the cost of regression testing and documentation

Dependencies "Which existing APIs, database tables, and UI screens break?" Traces to Satisfy & Depends links Overlooking secondary dependencies in legacy systems

Regulatory Risk "Does this change violate existing compliance baselines?" Traces to Regulatory Sources Implementing a feature that inadvertently voids GDPR/HIPAA compliance

Architecture "Does this force fundamental re-architecture or refactoring?" Traces to Architecture Models Underestimating architectural rework ("simple UI tweak" requiring DB rewrite)

The Four Formal Change Recommendations

Upon completing the impact analysis, the business analyst does not simply present raw data; the BA provides a structured Requirements Change Assessment with a definitive recommendation. +-----------------------------------------------------------------------------------+

  • | BABOK v3 Change Recommendation Taxonomy |
  • +-----------------------------------------------------------------------------------+
  • | |
  • | [ APPROVE ] Change delivers high net value, acceptable cost/risk; incorporate |
  • | into current baseline or upcoming sprint. |
  • | |
  • | [ REJECT ] Change delivers negative ROI, excessive risk, or diverges from |
  • | strategic business objectives; decline request. |
  • | |
  • | [ DEFER ] Change has valid business merit, but budget/schedule constraints |
  • | require postponing it to a future phase or release. |
  • | |
  • | [ MODIFY ] Change is valuable in concept, but current proposal is too costly; |
  • | request modified scope or alternative design option. |
  • | |
  • +-----------------------------------------------------------------------------------+

Recommendation Categories:

Approve: The change adds substantial value, budget/time reserves can accommodate it, and risks are manageable. The baseline is formally updated.

Reject: The proposed change provides minimal value compared to its severe cost, introduces unacceptable architectural risk, or conflicts with core project goals.

Defer: The change represents a great idea, but incorporating it now would jeopardize the hard launch date. It is cataloged in the future release backlog.

Modify / Request More Information: The underlying problem is legitimate, but the proposed solution is unnecessarily complex or expensive. The BA proposes a lighter-weight alternative or requests further discovery.

Enterprise Scenario: Health Insurance Claims Engine Regulatory Mandate

Eight weeks before the national rollout of a modernized health insurance claims platform, the government introduces a new statutory rule requiring mandatory auditing of all telehealth claim reimbursements over $500.

Change Submission: The Compliance Officer submits an urgent Change Request (CR-88).

Impact Analysis Execution:

Traceability Scan: The Lead BA traces from the compliance statute to 4 claims calculation rules, 2 database schemas, and 6 validation test suites.

Effort & Cost: Engineering estimates 120 hours of microservice modifications and 40 hours of automated regression testing.

Schedule Impact: Incorporating CR-88 without adjustments will delay the production launch by two weeks.

Trade-Off Formulation: The BA identifies that an optional reporting dashboard scheduled for the initial release can be deferred to Release 1.1, freeing up exactly 160 engineering hours.

Recommendation: The BA recommends Approve with Scope Swap to the Change Control Board. The CCB approves the recommendation, preserving both the launch date and statutory compliance.

Key BABOK v3 Techniques for Task 5.4

Decision Analysis: Evaluates alternative change options using cost-benefit scoring and trade-off matrices to support the final recommendation.

Financial Analysis: Assesses the budgetary impact and recalculates Net Present Value (NPV) and ROI if the scope expands.

Impact Analysis: The core technique used to systematically evaluate all upstream, downstream, operational, and organizational ramifications of a proposed change.

Risk Analysis and Management: Determines whether the change introduces new vulnerabilities, technical debt, or operational failure points.

Tip

CCBA Exam Tip: On scenario questions, if a key stakeholder demands an urgent mid-project change, the business analyst should NEVER immediately accept it (causes scope creep) or immediately reject it (unprofessional). The correct BABOK answer is always to conduct an Impact Analysis (Task 5.4) to evaluate cost, schedule, risk, and value before presenting options to the decision-makers.

Warning

CCBA Exam Trap: Remember that the business analyst does NOT unilaterally approve or reject major baselined scope changes unless granted explicit delegated authority in the Governance Plan (Task 3.3). The BA's role is to assess the impact and make a formal recommendation to the designated authority.