Managing Requirement Changes
Part of the Business Analyst Roadmap
In short
Requirements will change. Business needs shift, someone remembers a rule. The problem isn't change, it's change that slips in quietly and blows the deadline. A simple change process keeps it visible.
Requirements inevitably change mid-project — a formal change control process (assess impact, get approval, update documentation) prevents scope creep from silently derailing a project.
Think of it like this
Moving the kitchen window
Halfway through building your house, you want the kitchen window moved. A good contractor doesn't just start breaking walls. They tell you it costs two more weeks and extra money, you agree or drop it, and the plan gets updated.
Watch it happen
How a change request moves
1/6Sales asks: 'Can refunds also go to wallet balance, not just the bank?'
The big ideas
What you need to know
Scope creep
Small, unrecorded additions that pile up until the project is late. Each one 'only takes a day'.
Always assess impact
Before saying yes, find out what the change costs in time, effort, risk and other requirements.
The right person decides
The sponsor or product owner decides, using your impact analysis. The BA doesn't approve changes alone.
Agile still manages change
In Agile, changes go into the backlog and get prioritised, instead of being forced into the current sprint.
Save yourself the pain
Common mistakes
Oops
Saying 'sure, small change' in a hallway conversation.
Do this instead
Say 'Let me log it and check the impact', then come back with facts.
Oops
Updating the requirement but not the tests and RTM.
Do this instead
Follow the trace links and update everything connected, then tell the people affected.
Your mission
Write a change request
Quick check
A stakeholder asks for a 'tiny change' two days before testing starts. What should the BA do first?
Go deeper
- 1Draft a simple change request template capturing what changed and its impact.
- 2Learn to assess a change's ripple effect on timeline, budget, and other requirements before approving it.
- 3Practice the phrase 'let's evaluate the impact before committing' when a change is requested.
More topics at this stop
Functional vs Non-Functional Requirements
Business Requirements Document (BRD)
Functional Requirements Document (FRD)
User Stories & Acceptance Criteria
Use Cases & Use Case Diagrams
Requirements Traceability Matrix (RTM)
Requirements Prioritization (MoSCoW)
Writing Clear, Testable Requirements
Requirements Validation & Sign-Off
Stuck on this topic? Ask an Insider
Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.
