Manage a Requirements Change — Requirements Engineering, Part 9
- Shawn West
- Jul 28
- 7 min read
Updated: Aug 17
Requirements Engineering · Part 9
Changes are not the problem. Changes that arrive in a corridor, get absorbed quietly, and never reach the plan are the problem — because the cost is real whether or not anyone wrote it down, and by the time it's visible it's spent.
This tutorial walks one change from request to decision. For the reasoning behind the note and the three honest destinations, see managing requirements changes mid-sprint. This is the procedure.
Illustrative composite continuing the support-tooling example from Parts 1–8. Figures are illustrative, not measured.
Before You Start
A baselined scope to measure change against — the MoSCoW ordering from Part 5 and the requirement set committed to this release. Without a baseline, "change" is indistinguishable from work.
The traceability matrix from Part 4, open in front of you. Step 4's impact assessment is a matrix walk: which requirement rows, which acceptance criteria, which in-progress work.
Your remaining buffer in engineer-days, as a number you can state out loud. Step 5 is unanswerable without it. Ours was three days with five weeks left.
Your elicitation notes from Part 1. Step 3 asks whether the need was true at planning. You can only answer that by re-reading what you asked — and what you didn't.
An engineering lead for one to three hours, and the product owner — specifically someone who can say no without checking with anyone.
Block tomorrow. Step 2 buys you a day; Steps 3 through 7 fit inside it.
What You'll Build
A change-request workflow, exercised on one real change, ending in a recorded decision with a named approver.
Step 1: Set Up the Template Once (10 min)
# Change Request CR-###
Requested by: [name] Date: [today]
## What changes
Add / Remove / Modify: [the requirement]
## Why now
[Incident, deadline, customer, regulation — what makes this arrive today]
## Is it new or restated?
[New need · Already true but never elicited · Contradicts an existing one]
## Impact
- Touches: [requirements, in-progress work, acceptance criteria]
- Cost: [engineer-days]
- Risk: [what gets less safe]
## What it displaces
[The specific item that comes out — required if we're taking it in]
## Recommendation
Absorb / Defer / Swap — and why
## Approver
[Who actually decides]
Check: the template has a displaces field that cannot be left blank when the recommendation is "absorb." That single field does most of the work.
Step 2: Capture It, Don't Answer It (5 min)
The request arrives verbally, in week three of eight: "While you're in there — could the queue also email me a digest at 7am? Then I wouldn't have to open it."
Say the one sentence that costs nothing and protects everything: "Good idea — let me assess it and come back to you tomorrow."
Not yes. Not no. Both are answers to a question you haven't priced.
Check: nothing was committed in the room. If you said "should be easy," you've already answered, and the assessment is now a formality with a predetermined outcome.
Step 3: Ask Whether It's New or Restated (10 min)
Before estimating anything, ask: was this need true at planning, and we failed to elicit it — or is it genuinely new?
Asked here, the answer was revealing. The lead had always started the day in email, not in the tool. That was true in Part 1 and nobody had asked where the day starts — so this is a discovery miss, not a new requirement.
The distinction changes what you learn. A genuinely new need is legitimate work competing for space. A restated one means your intake has a leak, and three of those in a release is a process finding rather than a scoping one.
Check: you've classified it in writing. Teams that never classify can't tell a changing world from a discovery gap, and will fix the wrong thing.
Step 4: Assess Impact With Engineering (1–3 hours)
Get specifics, not impressions:
Touches: a new scheduled job, an email template, per-user send-time preference, and a new failure mode (job runs, email silently bounces, lead trusts an empty inbox)
Cost: ~3 engineer-days
Risk: the silent-bounce path is the real one — a digest that fails quietly is worse than no digest, because it converts "I should check the queue" into "no news is good news"
Check: the assessment names at least one thing nobody mentioned when the change was requested. If it doesn't, you've estimated the request rather than assessed the change.
Step 5: Name What It Displaces (15 min)
With three engineer-days remaining as buffer and five weeks left, taking this in means something else comes out. Lay out all three destinations honestly:
Option | What happens | What it costs | Right when |
Absorb | Take it in, keep everything | Consumes the entire remaining buffer | Fits in real slack and touches no in-progress criteria |
Defer | Next increment, with an interim path | A short wait; you build a stopgap and throw it away | The need is real but a cheap bridge exists |
Swap | Take it in, pull something out by name | A visible, agreed loss this release | It genuinely outranks something already committed |
There is no fourth option. "Squeeze it in" is absorb with the cost deleted from the record rather than from the plan — and what gets displaced is the buffer that was protecting your Must list.
Check: you can name the specific item that comes out under the swap option. If you can't, you haven't found the cost yet.
Step 6: Recommend, With the Bridge (15 min)
CR-014 Morning digest email
Classification: restated (discovery miss — day starts in email)
Cost: ~3 eng-days = the full remaining buffer
Displaces: nothing available; buffer is the only slack left
Recommendation: DEFER to increment 2.
Bridge (this week, ~1 hour): a saved link to the queue filtered to
at-risk, in the lead's 7:15 calendar reminder. Removes the actual
pain — remembering to look — without the job, the template, or the
silent-bounce failure mode.
Approver: [product owner] · Decision needed: Thursday
The bridge is what makes a deferral honest rather than a refusal. The underlying need — don't rely on me remembering — gets met this week for an hour of work. What's deferred is the expensive, failure-prone version.
Check: your deferral includes something that helps them before the next increment. A defer with no bridge is a no, and will be heard as one.
Step 7: Route It to Whoever Actually Decides (15 min)
The approver is whoever owns the trade-off — usually the product owner, occasionally the sponsor if the change crosses a commitment made outside the team. It is not the requester, and it is not you.
Check: the approver can say no without checking with anyone. If they can't, you've routed it to a messenger and the decision will be reopened.
Step 8: Update Every Artifact It Touches (1 hour)
On a decision — either way — update: the requirements document, the traceability matrix, the release plan, and the backlog entry for anything deferred.
Skipping this is how the next change gets assessed against a plan that no longer exists.
Check: someone reading the plan tomorrow can see this change happened and why, without asking you.
Step 9: Track the Change Rate (ongoing)
Count changes per release as a share of original scope. There is no published benchmark worth quoting here, so use your own history as the baseline: track the ratio across three releases, then treat a sharp rise above your own norm as the signal to investigate. What the number is for is comparison against yourself, not against an industry figure.
Ours ran at four changes in eight weeks, three of them classified restated. That ratio is the finding: the requirements weren't changing, they were surfacing late — which points at elicitation, not at change control.
Check: you know your ratio of new to restated. A high restated share is a discovery problem wearing a change-management costume.
Step 10: Run the Process on Small Changes Too (ongoing)
The erosion is always the same: a change is obviously tiny, so it goes through informally, and after four of those nobody can explain where the buffer went. Scale the template down — three lines for a small change — but keep the displacement question, because it's the one that keeps the cost visible.
Check: your smallest recorded change this release took under five minutes to file. If filing is expensive, people will route around it, and they'll be right to.
You're Done When
Your CR has every field filled including displaces, and the classification, recommendation, approver, and decision date all sit on the same page.
The requirements document, traceability matrix, release plan, and backlog all reflect the decision — and someone who wasn't in the room can reconstruct why from those four alone.
You can state this release's ratio of new to restated from your own filed CRs, and it's written down where the next release's ratio will sit beside it.
If This Goes Wrong
You already said "should be easy" in the room. Go back the same day with one line — "I want to check the impact before I commit to that" — and file the CR anyway. Reopening costs a little face; an unpriced commitment costs the buffer.
Engineering can't estimate without a spike. Time-box the spike to half a day, enter it in the CR as its own cost, and route the CR with the spike as the recommendation. A CR waiting on a perfect estimate is a CR that gets absorbed informally instead.
Nothing is available to displace — the buffer is the only slack left. That's the finding, not a dead end. Recommend defer, and spend the hour building the bridge from Step 6 so the underlying need is met this week.
The approver hands it back to you — "what do you think?" Restate the recommendation, and ask for a yes or a no by the decision date already written in the CR. If they still won't decide, you've routed to a messenger; escalate to whoever owns the trade-off.
Your restated share is climbing against your own earlier releases. Stop tuning change control — the leak is upstream. Re-run the Part 1 interview on the roles whose needs keep arriving late, and the Part 6 workshop on whatever keeps colliding.
Common Failure Modes
Answering in the room. "Should be easy" is a commitment, and everything after it is negotiation from a worse position.
No displacement named. The team absorbs it, the buffer disappears, and the sprint goal fails for reasons nobody can reconstruct.
Defer with no bridge. Functionally a refusal, and the requester will route around you next time.
Never classifying new vs restated. You treat a leaky intake as an unstable world and fix the wrong process.
Exempting small changes. They're the ones that erode the practice, precisely because each is individually defensible.
Continue the Requirements Engineering path
Part of the Requirements Engineering learning path.
