客製軟體範圍變更怎麼管
客製軟體的範圍變更，在需求規格與驗收清單已經寫好之後，另開一筆變更請求。請求要寫明動到哪一條、誰可以核准，以及核准或退回之後規格版本是哪一版。沒有這筆請求，範圍維持原版。
變更請求與規格分開記
規格寫的是這一版要達成的結果、負責人、範圍外，以及誰可以收下修改。那一份怎麼寫，見 客製軟體需求規格怎麼寫。變更請求是規格已經存在之後另開的一筆：誰提出、要改哪一條、核准或退回。
驗收清單怎麼從結果條目產生，見 客製軟體驗收標準怎麼寫。交付範圍見 客製軟件、網站與應用程式。會議上口頭答應的句子，先變成請求，再談要不要改規格。
標準提供的是組態管理指引
ISO 10007:2017 的名稱是品質管理—組態管理指引，第三版。目錄頁的出版日期寫 2017-03，生命週期表把 2017-04-07 標為國際標準已出版。該頁寫明此版於 2023 年覆核並確認，因此現行仍然有效；生命週期表把 2023-02-16 標為確認，並把 2025-06-04 標為國際標準待修訂。該頁並註明更正版只適用西班牙文，英文版不受該更正影響。
摘要寫明，這份標準提供組織內使用組態管理的指引，適用於從構想到處置的產品與服務支援。公開頁面沒有列出組態管理的步驟名稱。本文不把頁面沒有寫的步驟算進標準，也不引用售價。下面的請求與紀錄是購買方在規格已經寫好之後用來管理範圍的寫法。
請求裡要寫的項目
每一筆請求寫六項：規格的現行版本、要動的是哪一條結果或範圍外的哪一項、做完之後什麼會不一樣、誰提出、提出日期、誰可以核准。六項缺任何一項，請求先留在草稿，不進入核准。
「做完之後什麼會不一樣」沿用規格那篇的結果寫法：哪一個角色在哪一個畫面完成哪一件事，系統留下哪一筆紀錄。只有「更好」「更快」而沒有結果的請求，退回提出人改寫。速度若沒有貴司自己的量測與日期，請求裡不寫秒數。
核准人沿用規格已寫的角色
可以核准的人，就是規格裡已經寫明可以收下修改的那一位。請求不另找一位沒有寫在規格上的人來核准。規格上這個角色還是空白時，先回到規格補上名字，請求繼續留在草稿。
提出人與核准人可以是同一人，紀錄上仍分兩欄。核准人缺席時，不由在場的人代勾。請求等到核准人在紀錄上寫下核准或退回。
範圍外留到核准寫入紀錄
仍列在規格範圍外的事項，維持在範圍外。它要進入範圍，請求必須寫明新的結果與負責人，並在核准之後於同一筆修改裡改規格版本、改範圍外那一段、改驗收清單。
只把範圍外的句子刪掉、沒有新的結果條目，範圍會在無紀錄的情況下變大。退回的請求留在變更紀錄裡，狀態寫明退回與日期。退回之後，該句子仍留在範圍外，不寫進規格正文。
變更紀錄的每一行
變更紀錄每一行保留：請求編號、提出人、提出日期、規格版本、動到的條目、核准或退回、核准人、決定日期、決定之後的規格版本。退回的行同樣保留，決定之後的版本與提出時相同。
紀錄放在團隊已經在用的 Git 或同等地方，並能指回請求全文。聊天裡一句「可以」沒有寫進這一行之前，規格版本不變。本文不另設一套與現行紀錄平行的編號。
核准後規格與驗收一起改
核准的同一筆修改裡，規格的結果或範圍外、驗收清單、變更紀錄三者一起改，並指向決定之後的版本。驗收要補上的展示方式，沿用驗收那一篇，不在變更紀錄裡改寫示範規則。
建造途中才發現要改，仍然先寫請求。請求核准之前，建造沿現行版本。把已經做出來的畫面回寫成規格，下一輪就失去對照。
什麼時候先不要收變更
規格版本指不出來、核准人還沒寫在規格上，或請求仍是「更好」時，先不要收進核准。先補規格或改寫請求。驗收當天想把條目改成剛剛做出來的樣子，同樣先寫請求，不在會上改清單。
本文不給出核准時限、缺陷數或服務水準。時限若要寫，來自貴司自己的規則並註明日期，本文不代填。ISO 目錄頁的出版日期是 2017-03，生命週期表的出版標記是 2017-04-07。沒有變更紀錄之前，用「每筆請求是否指向規格版本與條目、核准人是否就是規格已寫的角色、範圍外是否要到核准才改」來檢查範圍有沒有在按紀錄走。