A requirement changed after testing began. How do we handle it?
Late requirement changeAssess the change's effect on implemented work, tests, documentation, and acceptance. Make the decision visible and preserve the prior baseline so nobody mistakes changed criteria for a failed delivery.
What to do now
- Record the revised requirement
- Trace affected outputs and tests
- Estimate rework and risk
- Approve the change and rebaseline affected evidence
When to escalate
Escalate when
The change threatens a committed release or invalidates critical testing.
Who decides
The scope owner and authorized sponsor
Example
A new approval level requires updates to workflow logic, test cases, training, and the release forecast.
Mistake to avoid
Changing acceptance criteria without recording the impact.
Prevent a repeat
Review ambiguous requirements and unresolved acceptance conditions before the affected work begins.
Suggested ApprovedFlow setup
- Projects
- Tasks
- Documents
- Approvals
Keep the agreed scope and acceptance evidence with the project; record any proposed change and its decision separately. See the platform
Related cases
- How do we prove every requirement was delivered and tested?Missing requirements traceability
- How can we manage scope when users discover needs during delivery?Evolving requirements
- A regulatory requirement changes during the project. How should we react?External requirement change
- Users request a change during training. Should we implement it immediately?Late adoption feedback