Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 21

Managing Requirements Changes

Recommended resources

Hello! Welcome to our final lesson in the "Documenting and Managing Requirements" module.

In our last session, we built a Requirements Traceability Matrix (RTM) to create a clear, traceable link from a business need all the way to its testing and delivery. We noted that one of the RTM's key benefits is simplifying impact analysis. Today, we'll see that in action.

Projects rarely go exactly as planned. Stakeholders discover new needs, market conditions change, and technical challenges arise. This inevitability of change can lead to chaos, delays, and budget overruns if not managed properly. This is where a formal change control process becomes essential. Your project management background has likely exposed you to the challenges of uncontrolled "scope creep," and this lesson will formalize the Business Analyst's specific role in preventing it.

Our goal is to learn how to execute a requirements change control process, including impact analysis. You will learn how to field a change request, analyze its true impact on the project, and present your findings to decision-makers, all while using the RTM we studied previously.

The Change Control Process: From Chaos to Control

Change is not the enemy; unmanaged change is. A structured change control process ensures that every proposed change is evaluated thoughtfully, allowing teams to make informed decisions rather than reactive ones.

To start, let's get a high-level overview of what this process entails and why it's so tightly linked to risk management.

Change Management Process (5 Steps Explained) - ITIL & PMP Training

This video, 'Change Management Process (5 Steps Explained)' from ACI Learning, provides an excellent introduction. It frames change as an inevitable part of projects that must be embraced with a structured process.

Please watch from the beginning to 03:02. Pay close attention to the concepts of the Request for Change (RFC) and the link between change and risk.

The video introduces two key ideas:

  1. All change should start with a formal Request for Change (RFC). This isn't just bureaucracy; it's the starting point for documentation and analysis.
  2. Managing change is fundamentally about managing risk to the project's scope, timeline, and budget.

The 5 Steps of the Change Control Process

A robust change control process typically follows a clear, five-step flow. As a Business Analyst, you are the central facilitator for the first three steps.

Change Control Process: Benefits, Examples, and Templates

For a detailed breakdown of the steps and the key artifacts involved, let's turn to the article 'Change Control Process: Benefits, Examples, and Templates' from KnowledgeHut.

First, read the section 'Key Elements of Change Control Process' to understand the main components like the Change Request and Change Control Board. Then, read 'Change Control Process [In 5 Steps]' to see how these elements fit into a structured workflow.

Let's synthesize those steps from the perspective of a BA:

Step 1: Identify and Log the Change Request (RFC)
A stakeholder—perhaps a client, a project manager, or a team member—identifies a need for a change. They submit a formal RFC. As a BA, your first job is to ensure the request is clear, logical, and contains enough information to be analyzed, including:

  • A clear description of the proposed change.
  • The justification or business value behind the change.
  • The name of the person requesting it.

All requests are logged in a Change Log, a master document that tracks the status of all RFCs throughout the project.

Step 2: Perform Impact Analysis
This is your most critical contribution. You take the RFC and determine its "blast radius." What will this change really affect? We will do a deep dive into this step next.

Step 3: Review and Decision (The CCB)
You present your impact analysis findings to a Change Control Board (CCB). The CCB is a group of stakeholders—often including the project sponsor, product owner, tech lead, and project manager—responsible for approving or rejecting changes. Your analysis gives them the data they need to make an informed decision based on the trade-offs (e.g., "Is this feature worth a two-week delay and a $10k budget increase?").

Step 4: Implement the Change
If the CCB approves the change, it's assigned to the development team for implementation. As the BA, your role here is to update all relevant documentation—the BRD, FSD, user stories, and especially the Requirements Traceability Matrix (RTM)—to reflect the approved change.

Step 5: Close the Request
Once the change is implemented, tested, and verified, the RFC is formally closed in the Change Log. You communicate the change and its outcome to all relevant stakeholders.

This flowchart provides a great visual summary of the process and the roles involved.

Change Control Process Flow Chart
This flowchart illustrates the key steps and roles in a change control process. It shows how a change request moves from the Project Team to the Project Manager for initial assessment, and then to the Change Control Board for a formal review and decision, before being implemented or rejected.

Deep Dive: Requirements Impact Analysis (RIA)

Impact analysis is the investigation you conduct to understand the full consequences of a proposed change. This is where the RTM you created in the last lesson becomes indispensable.

Requirements Impact Analysis: A Comprehensive Guide

The article 'Requirements Impact Analysis: A Comprehensive Guide' offers an excellent, in-depth look at this practice.

Please read the sections 'What is Requirements Impact Analysis?', 'The Importance of Change Impact Analysis', and 'The Steps in Conducting Requirements Impact Analysis'. Focus on understanding why RIA is important and the different dimensions of impact you need to consider.

As the article highlights, RIA isn't just about technical impact. A thorough analysis considers multiple dimensions. When a stakeholder asks for what seems like a "small change," you need to investigate:

  • Requirements Impact: Which other requirements are affected? Does this change conflict with or duplicate another requirement? (Your RTM is the primary tool here).
  • Design & Development Impact: Which UI mockups, architectural components, or database schemas need to be altered? What is the estimated effort in hours or story points?
  • Testing Impact: Which existing test cases must be updated? What new test cases need to be written?
  • Schedule & Cost Impact: How will the development effort affect the project timeline and budget?
  • Risk Impact: Does this change introduce new security, performance, or operational risks?

To structure this analysis, many BAs use a Change Impact Matrix.

Change Impact Matrix Template
This template for a Change Impact Matrix provides a structured way to document the various impacts of a change across functional areas, stakeholders, products, and processes. It helps quantify the level of impact and identify necessary support.

An AdTech Scenario

Let's put this into practice. Remember the A/B testing feature for an AdTech platform? Your RTM might look something like this:

Req ID Requirement Design ID Test Case ID
REQ02 See clicks for each creative DSN-046 TC-092
REQ03 See impressions for each creative DSN-046 TC-093

Now, a marketing stakeholder submits an RFC: "In addition to clicks and impressions, I want to see the Click-Through Rate (CTR) for each creative in the results dashboard."

Using your RTM and impact analysis framework, you immediately identify:

  1. Forward Traceability (from requirements): This is a new requirement (let's call it REQ04).
  2. Backward Traceability (to requirements): The CTR calculation depends on REQ02 (clicks) and REQ03 (impressions). They are linked.
  3. Impact on Design: The results dashboard DSN-046 must be modified to add a new column for CTR.
  4. Impact on Development: A new calculation must be added to the backend logic.
  5. Impact on Testing: A new test case (TC-094) is needed to verify the CTR calculation is correct. Existing test case TC-092 might need modification if the UI layout change is significant.

You would document these findings and present them to the CCB, who can now make a decision based on a full understanding of the work involved, not just the simple-sounding request.

Test your understanding!

Another RFC comes in for the same AdTech project. An advertiser executive requests: "I want the ability to automatically pause the losing ad creative after 24 hours."

You are the BA assigned to analyze this request. What are the first three types of impact you would investigate and document? (Think about the different dimensions we discussed).

Show answer

Here are the primary impacts you would start investigating:

  1. Technical/Development Impact: This is a major new piece of functionality. It requires a new automated process or background job that runs on a schedule. This is far more complex than adding a display field. You would need to estimate the development effort (e.g., in days or story points).
  2. Requirements Impact: You'd check if this new automated-pause feature conflicts with any existing requirements. For example, is there another requirement about manual campaign control? You would also define the detailed acceptance criteria (e.g., what defines a "losing" creative? Clicks? CTR? What happens in a tie?).
  3. Risk Impact: What if the automated job fails? Could it accidentally pause the wrong ad, or no ad at all, leading to wasted ad spend or lost revenue? You would need to identify these risks and propose potential mitigations (e.g., sending an email notification to the advertiser when an ad is auto-paused).

You would also investigate the impact on the schedule, budget, and testing effort, but these three are the immediate, core areas of analysis for a feature of this nature.

Conclusion

You have now learned how to manage one of the most challenging aspects of any project: change. By establishing a formal change control process, you transform potential chaos into a structured, manageable workflow. The RTM provides the technical backbone for this process, but it is your analytical skill as a BA that brings it to life.

Key Takeaways:

  • A Change Control Process is a formal procedure for managing any alteration to a project's baseline scope, schedule, or budget.
  • The process begins with a Request for Change (RFC) and is governed by a Change Control Board (CCB).
  • The Business Analyst's core role is to perform Impact Analysis, assessing how a change affects requirements, design, testing, schedule, cost, and risk.
  • The Requirements Traceability Matrix (RTM) is an essential tool for quickly identifying the downstream impact of a change to a specific requirement.

Preview of the Next Module:
This lesson concludes our module on documenting and managing requirements. You now have the tools to define, prioritize, trace, and manage a set of requirements.

In our next module, "Business Process and System Modeling," we will shift our focus from what the system should do to how the business operates. We'll start by learning how to create a high-level process map using flowchart notation, a foundational skill for visualizing, analyzing, and improving business workflows.