首頁 › 名詞百科 › 需求規格書與規格凍結

數位與系統・Knowledge

需求規格書與規格凍結

需求規格書是把「系統要做什麼」寫成可驗收條文的文件；規格凍結是雙方簽認後，變更一律走變更單與報價的時點。客製系統開發的報價、時程與驗收，都以這份文件為準。

關鍵事實

由誰寫：開發方依訪談整理初稿，業主逐條確認後簽認；不是業主自己憑想像寫，也不是開發方單方面定。
寫什麼：角色與權限、每一個流程的輸入與輸出、單據欄位、報表、串接對象、資料移轉範圍、驗收標準與排除項目。
凍結時點：原型試用完成並簽認之後；凍結前可免費調整，凍結後每一項變更都走變更單、重新估工時與時程。
與報價的關係：報價依規格書範圍計算；沒有規格書的報價只是範圍不明的估計，追加費用多半從這裡來。
與驗收的關係：驗收以規格書列出的功能與驗收標準逐項勾稽，規格書沒寫的功能不在驗收範圍內。
權利歸屬：規格書、原型與原始碼的著作權依《著作權法》以契約約定，常見作法是約定歸業主所有並交付原始碼。

白話解釋

需求規格書常跟「需求訪談紀錄」與「報價單上的功能列表」搞混。訪談紀錄是雙方談了什麼，還沒整理成可驗收的條文；報價單的功能列表只有名稱，沒有輸入輸出與驗收標準。

需求規格書的差別在於每一條都寫到能夠勾稽：這個單據有哪些欄位、送出後誰收到、錯誤時怎麼處理、做到什麼程度算完成。規格凍結則是這份文件的生效點：凍結前雙方可以反覆修改，凍結後任何新增或變更都另外估價與排程。沒有凍結點的專案，功能會一直長，時程與費用跟著失控。

你什麼時候會遇到它

找開發公司做進銷存、客戶管理、報價系統或任何客製系統，對方在報價前要求先做需求訪談並產出規格書時；或專案進行中對方說「這不在規格內，要另外報價」時，看的就是這份文件與凍結日期。

常見情境與對策

兩家開發公司報價差距很大，一家只給功能列表，一家附了二十頁規格書。——附規格書的那份才有比較基礎。請另一家依同一份規格書重新報價，或先委託規格階段再比價，否則比的是兩個不同範圍。
原型試用後業主想加一個報表，開發方說要走變更單。——先看規格是否已凍結。凍結後的新增本來就應另估；凍結前則屬免費調整範圍。凍結日期要在契約或簽認紀錄上找得到。
驗收時業主認為某功能「本來就應該有」，開發方認為沒寫就不做。——以規格書為準。規格書沒寫的功能不在驗收範圍，這是規格書存在的目的；要補做就走變更單。下次在規格階段把「理所當然」的功能也逐條寫進去。

LINE 諮詢

把系統開發的現況與需求傳過來，先免費書面初判。

傳什麼: 現有網站網址與後台權限還沒有網站也能先談
商品或服務清單、作業流程說明表單樣張或試算表皆可
需求清單一句話也行
多久回: 週一至週五 09:00–18:00 依序回覆；LINE 全天可傳資料
下一步: 免費書面初判
約時間細談
委任開發

先傳資料做初判，需要時再約時間細談

加 LINE 諮詢系統開發，偉騰統包開發

程序怎麼走

需求訪談：業主提供現行流程、單據範本與報表，開發方訪談各角色，整理成流程圖與功能清單初稿。
規格書初稿：開發方把每一項功能寫到欄位、輸入輸出、例外處理與驗收標準，列出排除項目與串接對象。
原型試用：依規格做可點選的畫面原型，讓實際操作的人員試走主要流程，把修改意見回填規格書。
簽認與凍結：雙方逐條確認後簽認，標明凍結日期；開發方依凍結版規格出正式報價與時程。
變更管理：凍結後的新增或修改填變更單，載明影響範圍、工時與時程調整，雙方簽認後才納入開發。
驗收勾稽：上線前依規格書的驗收標準逐項測試並記錄，未通過項目列缺失清單限期修正。

先看清楚

規格書要寫「排除項目」：明確列出這次不做的功能與不串接的平台，比寫做什麼更能防止驗收爭議。另外注意規格書的著作權與原始碼歸屬要一併約定在契約裡，否則換開發團隊時連規格都帶不走。

常見錯誤

跳過規格階段直接開發——功能邊界不清，開發到一半反覆改方向，費用與時程失控。
規格書只有功能名稱沒有驗收標準——驗收時雙方對「做完」的定義不同，上線遙遙無期。
沒有凍結日期——業主持續加需求、開發方持續追加費用，雙方都覺得對方不守約。
規格書由業主單方面撰寫——寫的是想像中的系統，技術可行性與資料結構沒經過開發方確認。

行動前自查清單

規格書列出所有角色與權限、每個流程的輸入輸出與例外處理
每項功能附驗收標準，並列出排除項目與不串接的平台
原型試用由實際操作人員執行，修改意見已回填規格書
簽認紀錄標明凍結日期，契約載明凍結後走變更單
規格書、原型與原始碼的權利歸屬已依《著作權法》在契約約定

常見問題