定制软件范围变更怎么管
定制软件的范围变更，在需求规格与验收清单已经写好之后，另开一笔变更请求。请求要写明动到哪一条、谁可以核准，以及核准或退回之后规格版本是哪一版。没有这笔请求，范围维持原版。
变更请求与规格分开记
规格写的是这一版要达成的结果、负责人、范围外，以及谁可以收下修改。那一份怎么写，见 定制软件需求规格怎么写。变更请求是规格已经存在之后另开的一笔：谁提出、要改哪一条、核准或退回。
验收清单怎么从结果条目产生，见 定制软件验收标准怎么写。交付范围见 定制软件、网站与应用程序。会议上口头答应的句子，先变成请求，再谈要不要改规格。
标准提供的是构型管理指引
ISO 10007:2017 的名称是质量管理—构型管理指引，第三版。目录页的出版日期写 2017-03，生命周期表把 2017-04-07 标为国际标准已出版。该页写明此版于 2023 年复核并确认，因此现行仍然有效；生命周期表把 2023-02-16 标为确认，并把 2025-06-04 标为国际标准待修订。该页并注明更正版只适用西班牙文，英文版不受该更正影响。
摘要写明，这份标准提供组织内使用构型管理的指引，适用于从构想到处置的产品与服务支持。公开页面没有列出构型管理的步骤名称。本文不把页面没有写的步骤算进标准，也不引用售价。下面的请求与记录是购买方在规格已经写好之后用来管理范围的写法。
请求里要写的项目
每一笔请求写六项：规格的现行版本、要动的是哪一条结果或范围外的哪一项、做完之后什么会不一样、谁提出、提出日期、谁可以核准。六项缺任何一项，请求先留在草稿，不进入核准。
「做完之后什么会不一样」沿用规格那篇的结果写法：哪一个角色在哪一个画面完成哪一件事，系统留下哪一笔记录。只有「更好」「更快」而没有结果的请求，退回提出人改写。速度若没有贵司自己的测量与日期，请求里不写秒数。
核准人沿用规格已写的角色
可以核准的人，就是规格里已经写明可以收下修改的那一位。请求不另找一位没有写在规格上的人来核准。规格上这个角色还是空白时，先回到规格补上名字，请求继续留在草稿。
提出人与核准人可以是同一人，记录上仍分两栏。核准人缺席时，不由在场的人代勾。请求等到核准人在记录上写下核准或退回。
范围外留到核准写入记录
仍列在规格范围外的事项，维持在范围外。它要进入范围，请求必须写明新的结果与负责人，并在核准之后于同一笔修改里改规格版本、改范围外那一段、改验收清单。
只把范围外的句子删掉、没有新的结果条目，范围会在无记录的情况下变大。退回的请求留在变更记录里，状态写明退回与日期。退回之后，该句子仍留在范围外，不写进规格正文。
变更记录的每一行
变更记录每一行保留：请求编号、提出人、提出日期、规格版本、动到的条目、核准或退回、核准人、决定日期、决定之后的规格版本。退回的行同样保留，决定之后的版本与提出时相同。
记录放在团队已经在用的 Git 或同等地方，并能指回请求全文。聊天里一句「可以」没有写进这一行之前，规格版本不变。本文不另设一套与现行记录平行的编号。
核准后规格与验收一起改
核准的同一笔修改里，规格的结果或范围外、验收清单、变更记录三者一起改，并指向决定之后的版本。验收要补上的展示方式，沿用验收那一篇，不在变更记录里改写演示规则。
建造途中才发现要改，仍然先写请求。请求核准之前，建造沿现行版本。把已经做出来的画面回写成规格，下一轮就失去对照。
什么时候先不要收变更
规格版本指不出来、核准人还没写在规格上，或请求仍是「更好」时，先不要收进核准。先补规格或改写请求。验收当天想把条目改成刚刚做出来的样子，同样先写请求，不在会上改清单。
本文不给出核准时限、缺陷数或服务水平。时限若要写，来自贵司自己的规则并注明日期，本文不代填。ISO 目录页的出版日期是 2017-03，生命周期表的出版标记是 2017-04-07。没有变更记录之前，用「每笔请求是否指向规格版本与条目、核准人是否就是规格已写的角色、范围外是否要到核准才改」来检查范围有没有在按记录走。