How to control scope changes in custom software
After the requirements spec and the acceptance list exist, a scope change in custom software is a separate change request. The request names the line it touches, who may approve it, and which spec version follows an approval or a rejection. Without that request, the scope stays on the current version.
On this page
- Keep the request apart from the spec
- The standard is configuration-management guidance
- What a request has to name
- The approver is the role already in the spec
- Out of scope stays out until the log says otherwise
- What each log row keeps
- Update the spec and acceptance together
- When to leave a change unaccepted
Keep the request apart from the spec
The spec names the outcomes for this version, the owner of each line, what sits outside the scope, and who may accept a change. How to write that document is covered in How to write a custom software requirements spec. A change request is a later record: who asked, which line would change, and whether it was approved or rejected.
How the acceptance list is produced from those outcomes is covered in How to write acceptance criteria for custom software. The delivery scope sits under Custom software, websites, and applications. A sentence agreed aloud in a meeting becomes a request before anyone edits the spec.
The standard is configuration-management guidance
ISO 10007:2017, Quality management — Guidelines for configuration management, is edition 3. The catalogue page gives the publication date as March 2017, and the life-cycle table marks 7 April 2017 as the date the international standard was published. The page says this edition was reviewed and confirmed in 2023, so this version remains current. The life-cycle table marks 16 February 2023 as the confirmation and 4 June 2025 as the date the international standard moved to “to be revised”. The page says the corrected version applies only to Spanish, and that the English version is not affected.
The abstract says the standard provides guidance on the use of configuration management within an organization, and that it applies to the support of products and services from concept to disposal. The public page does not list the step names inside configuration management. This note does not add steps the page does not state, and it does not quote a price. The request and the log below are the way a buyer manages scope after the spec already exists.
What a request has to name
Each request names six things: the current spec version, the outcome line or the out-of-scope item it would change, what would be different when the work is done, who asked, the date of the request, and who may approve it. Leave any of the six blank and the request stays a draft.
“What would be different” follows the outcome style in the spec note: which role finishes which action on which screen, and which record the system keeps. A request that says only “better” or “faster”, with no outcome, goes back to the requester to be rewritten. If you have no measurement of your own, with a date, leave seconds out of the request.
The approver is the role already in the spec
The person who may approve is the person the spec already names as the one who may accept a change. The request does not pick a different person who is absent from the spec. While that role on the spec is still blank, go back and name them, and leave the request as a draft.
The requester and the approver may be the same person. The record still has two columns. When the approver is absent, nobody else in the room ticks the request. It waits until the approver writes approval or rejection on the record.
Out of scope stays out until the log says otherwise
An item still listed as out of scope stays there. To bring it in, the request has to name the new outcome and the owner, and the same edit after approval has to change the spec version, the out-of-scope section, and the acceptance list.
Deleting the out-of-scope sentence, with no new outcome line, widens the scope without a record. A rejected request stays in the change log, with the rejection and the date. After a rejection, that sentence remains in the out-of-scope section.
What each log row keeps
Each row of the change log keeps the request identifier, the requester, the request date, the spec version, the line it touches, approval or rejection, the approver, the decision date, and the spec version after the decision. A rejected row stays. Its version after the decision is the version at the request.
Keep the log in the Git history the team already uses, or in an equivalent place that can point back to the full request. Until a chat message that says “yes” is written on that row, the spec version stays as it is. This note does not add a second numbering scheme beside the record you already keep.
Update the spec and acceptance together
In the same edit as the approval, change the outcome or the out-of-scope section, the acceptance list, and the change log, and point all three at the version after the decision. How acceptance shows the outcome stays in the acceptance note. The change log does not rewrite the demo rule.
A change discovered during the build is still a request first. Until the request is approved, the build follows the current version. Writing the spec so that it matches a screen already built removes the baseline for the next round.
When to leave a change unaccepted
When the request cannot name a spec version, the approver is not yet named on the spec, or the request still says only “better”, leave it out of approval. Fix the spec or rewrite the request. A wish, on acceptance day, to edit a line so that it matches what was just shown, is also a request. Leave the list unchanged in the meeting.
This note does not state an approval time, a defect count, or a service level. If you set a time limit, it comes from your own rule, with a date. This note does not fill one in. The ISO catalogue date is March 2017, and the life-cycle table marks publication on 7 April 2017. Until a change log exists, check scope by whether every request points at a spec version and a line, whether the approver is the role already named in the spec, and whether an out-of-scope item changes only after approval.