客製軟體需求規格怎麼寫
客製軟體的需求規格寫明要達成的結果、每一條的負責人、明確留在範圍外的事項，以及誰可以改這份規格。規格先寫好，驗收標準才有對得上的依據。寫不出結果與負責人的句子，先留在討論。
規格寫在驗收之前
每一條先寫四項：做完之後什麼算達成、誰對這一條負責、這一版明確不做什麼、誰可以收下對這一條的修改。四項缺任何一項，這一句還留在討論，不放進規格。
驗收標準寫的是同一條結果在示範或使用者驗收裡如何被做出來，見 客製軟體驗收標準怎麼寫。本文停在開工前的規格。交付範圍見 客製軟件、網站與應用程式。
標準要求的是資訊項目
ISO/IEC/IEEE 29148:2018 的名稱是系統與軟體工程—生命週期過程—需求工程，第二版於 2018 年 11 月出版。ISO 該頁寫明此版於 2024 年覆核並確認，因此現行仍然有效，同時寫明預期於數月內由 ISO/IEC/IEEE DIS 29148 取代；生命週期表將 2026-02-16 標為國際標準待修訂。摘要寫明這份標準規定需求過程要產出的資訊項目、這些項目的必要內容，以及必要與相關資訊項目的格式指引，並適用於各種專案範圍、方法、規模與複雜度。
IEEE 的對應頁 寫明該標準於 2018-11-30 出版，狀態為 Active Standard。同一頁寫明它定義良好需求的構造、需求的屬性與特性，討論需求過程在生命週期中反覆、遞迴地應用，並寫明需求工程適用的資訊項目及其內容已有定義。這些內容可以加進 ISO/IEC/IEEE 12207 或 15288 已有的需求相關過程，也可以獨立使用。公開頁面沒有逐條列出資訊項目的名稱。本文不抄錄上述官方頁面沒有列出的特性形容詞，也不引用售價。下面四段是購買方在開工前用來對齊的寫法。
每一條寫結果與負責人
結果寫成旁人以後對得上的狀態：哪一個角色在哪一個畫面完成哪一件事，系統留下哪一筆紀錄。負責人是會確認「這一條就是我們要的」的那個人，名字寫在條目上。
「易用」「穩定」「快」還沒有結果。速度若沒有貴司自己的量測與日期，條目裡不寫秒數。類別名稱、套件與演算法留在設計說明。規格只留結果與會確認這一條的人。
範圍外單獨成段
規格裡用單獨一段列出這一版不做的事。每一項寫明暫時不做的內容，以及若要納入，要改哪一條結果、由誰收下。沒有這一段，討論過的願望會在建造途中被當成已經答應。
一項從範圍外移進範圍內，要在同一筆修改裡補上結果與負責人，並改規格版本。只把句子從範圍外刪掉、卻沒有新的結果條目，範圍會在無紀錄的情況下變大。
變更留下版本與收件人
每一版規格都是一份可以指認的資訊項目。改動寫在同一筆紀錄：誰提出、誰收下、哪一條結果改了、範圍外有沒有跟著改。收下的人與條目負責人可以是同一人，兩種角色都要在紀錄上分得開。
版本放在團隊已經在用的 Git 或同等紀錄裡，並寫上閱讀或修改的日期。事後要能指出當時開工對上的是哪一版。本文不另設一套與現行紀錄平行的編號規則。
規格交到驗收清單
驗收清單從規格裡的結果條目產生，一條結果對一條或一組驗收。驗收補上的是展示方式：示範還是使用者驗收。展示方式的寫法沿用驗收那一篇，本文不重寫。
規格改了，驗收清單在同一筆修改裡一起改，兩份都指向新版本。驗收當天才把規格改成剛剛做出來的樣子，下一輪就失去對照。範圍外的事項不進驗收清單。
什麼時候先不要加長
不必為每個標籤、顏色與內部函式各寫一條。那些句子沒有單獨的結果，負責人也不會逐條確認。條目數量以負責人實際讀得完、確認得了為度。
負責人還沒命名、範圍外還是空白時，先不要把清單加長。先補人，再補他會確認的那幾條，並把這一版不做的事寫進範圍外。
什麼時候先不要開工
結果仍是「易用」、條目沒有負責人、範圍外空白，或沒有人被指定收下變更時，先不要開工。先改規格，再排建造。
本文不給出頁數、工期或服務水準。那些數字要來自貴司自己的規格與變更紀錄，並註明口徑。沒有這份紀錄之前，用「每條是否有結果與負責人、範圍外是否單獨成段、變更是否寫明誰收下並指向同一版本」來檢查規格能不能作為開工依據。