客製軟體驗收標準怎麼寫
客製軟體的驗收標準寫明可觀察的結果、負責人，以及這項結果在示範或使用者驗收裡如何被做出來。標準先於示範，示範與驗收才對得上同一份清單。寫不出結果與負責人的句子，先不要放進驗收。
一條標準裡要有的三項
每一條寫三項：做完之後旁人看得到什麼、誰對這條負責、用示範還是使用者驗收把這條做出來。三項齊了，才放進清單。
ISO/IEC/IEEE 29148:2018 的名稱是系統與軟體工程—生命週期過程—需求工程，第二版於 2018 年 11 月出版。ISO 該頁寫明此版於 2024 年覆核並確認，因此現行仍然有效，同時寫明預期於數月內由 ISO/IEC/IEEE DIS 29148 取代；生命週期表將 2026-02-16 標為國際標準待修訂。該標準規定需求過程要產出的資訊項目及其必要內容，並適用於各種專案範圍、方法、規模與複雜度。IEEE 的對應頁 寫明該標準於 2018-11-30 出版，狀態為 Active Standard，並寫明它定義良好需求的構造、需求的屬性與特性，以及需求過程在生命週期中反覆、遞迴地應用。本文不抄錄上述官方頁面沒有列出的特性形容詞，也不引用售價。購買方寫驗收時，把每一條落成可觀察的結果、負責人，以及展示方式。
跟示範走同一份清單
示範前，主持人念出條目編號與預期結果，再操作。在場的人核對的是結果有沒有出現。一段沒有條目編號的畫面導覽，不能代替這份清單。
示範當下做不到的條目留在清單上，標明未示範與原因。條目若要改，回到清單改完，下一輪示範再用新條目。當場把條目改成剛剛做出來的樣子，下一輪就失去對照。
使用者驗收走同一份清單
使用者驗收的腳本就是這份清單，換由條目的負責人執行，或在場簽認。負責人缺席的條目，留到負責人在場再計入通過。
邊界單獨成條：空白輸入、重複送出、權限不足、紀錄已經存在。只有順利路徑的清單，可以在驗收裡全數通過，同時漏掉購買方在意的失敗。邊界沒寫的，補進清單，再排下一次驗收。
三種常見的寫法會使驗收落空
「易用」「穩定」「快」沒有可觀察的結果，就還沒有標準。速度若沒有貴司自己的量測與日期，條目裡不寫秒數。改寫成旁人看得到的結果，例如負責人在指定畫面完成指定步驟，並留下紀錄。
沒有負責人的條目，示範結束後無人簽。條目若寫的是類別名稱、套件或演算法，結果仍成立時實作一換，條目就會整條作廢。實作留在設計說明。驗收只留結果、負責人與展示方式。
什麼時候不要寫得過細
不必為每個標籤、顏色與內部函式各寫一條。那些句子一輪示範走不完，負責人也不會逐條簽。條目數量以一輪示範或一次驗收實際走得完為度。
負責人還沒命名之前，先不要把清單加長。先補人，再補他會簽的那幾條。邊界要寫進驗收。內部實作留在設計說明。
清單與被驗收的版本放在一起
條目一改，示範腳本與驗收腳本在同一筆修改裡一起改。驗收紀錄寫明對上的軟體版本。版本放在團隊已經在用的 Git 或同等紀錄裡，事後才看得到當時簽的是哪一版。
若這套軟體管的是租賃紀錄，條目要對上已經寫明的紀錄種類，見 設備租賃管理系統怎麼選。交付範圍見 客製軟件、網站與應用程式。
什麼時候先不要召開驗收
條目仍是「易用」、邊界沒寫、或負責人不會到場時，先不要召開驗收。先改清單，再約時間。
本文不給出缺陷數、合約期限或服務水準。那些數字要來自貴司自己的驗收紀錄，並註明口徑。沒有這份紀錄之前，用「每條是否有結果、負責人與展示方式，示範與驗收是否走同一份清單」來檢查驗收有沒有按標準走。