客製化網站設計規格怎麼寫？需求說不清楚也能寫出可驗收的規格書

作者｜瞻新資訊　張安邦執行長（台大醫工背景・十年以上IT服務公司創辦人）

如果你正在找客製化網站設計，而且已經跟幾家廠商聊過，大概會有一種熟悉的挫折感：對方問你「想要什麼功能」，你講了一輪，對方點點頭，回去給了一份報價單。你看著那份報價單，其實不太確定它到底包含了什麼，也不確定三個月後交出來的東西，會不會是你腦中想的那個。

這種卡住的感覺很常見。常見到它幾乎已經是這個行業的預設狀態了。

「我知道我需要一個系統，但我說不清楚要做什麼」，是很多人第一次找開發團隊時講的第一句話。 而這句話本身沒有問題——需求在初期本來就是模糊的，能一次講清楚的反而是少數。真正會出問題的，是模糊的需求沒有經過任何程序，就直接變成了報價單、變成了合約、變成了三個月後的爭執。

所以這篇不談客製化網站要多少錢、跟套版差在哪、該找哪一家做——那些是你在決定「要不要做」的時候該想的事，我們在〈客製化網頁設計怎麼選？費用、流程與套版差異完整解析〉已經整理過。這篇處理的是下一關：當你已經決定要做，需求該怎麼談、規格該怎麼寫、驗收該怎麼定、中途要改該怎麼算。

客製化網站設計最貴的一筆錢，通常花在「做完」沒有定義

先講結論：客製化網站專案超支與延期，多數不是因為漏寫了某個功能，而是因為「做完了」這三個字，從頭到尾沒有被雙方寫下來過。

這件事不是台灣特有的。國際上研究資訊專案成敗最久的 Standish Group 在 CHAOS Report 裡整理過受訪主管認為專案受困的主因，排在前面的幾項分別是「使用者參與不足」「需求與規格不完整」「需求與規格持續變動」。這裡要老實說明它的限制：這份報告最早的版本是 1990 年代的調查、樣本以美國企業為主、統計方法後來也被學界討論過，所以那些百分比不能直接搬到今天的台灣中小企業身上。但它點出的形狀三十年來沒有變過——問題出在專案開始之前，不是開始之後。

常見的情況是這樣的：企業想做一個能線上收單的網站，跟廠商說「要有購物功能」。廠商依照自己的理解報價、開發，三個月後交件。這時候企業說：「怎麼沒有分期付款？」廠商說：「你沒有提到分期。」兩邊都覺得自己有理，而且兩邊確實都有理——因為「購物功能」這四個字，本來就可以是三種截然不同的規模：只收一次性刷卡，跟支援分期、超商取貨付款、退款流程、發票串接，是完全不同的工程量。

規格書存在的意義，就是把這種「兩邊都有理」的空間關掉。

所以規格書真正的用途，不是告訴工程師要做什麼——好的工程師不需要你教他怎麼寫程式——而是讓雙方對「做完了」的定義一致。 這是本文接下來每一節的共同底層邏輯。

規格沒寫清楚，實際上會多花多少？

這一節來算一筆帳。「規格很重要」這句話講一百次，都不如把不寫的代價攤開來看一次。

先說清楚，下面是一個推導，不是統計數據，用的都是約數：

假設一個三個月的專案，走到第八週，你才發現訂單流程跟你想的不一樣。這時候要改，成本有三塊。第一塊是工錢，重做那個模組可能是兩三週的工——這一塊其實是最小的。第二塊是連帶影響：訂單流程改了，後台的報表、通知信、庫存扣減可能都要跟著調，所以實際動到的往往不只那一個模組。第三塊，也是最痛的一塊，是時間：上線日往後推一個月，你原本排好的檔期、廣告預算、業務說詞全部要重排。

返工真正貴的地方從來不是工錢，是時間；而時間是唯一一種你付再多錢也買不回來的成本。

反過來看規格這一端的投入：把需求整理清楚、寫成文件、雙方確認，通常是幾天到一兩週的事，而且大部分是你自己內部就能做的事，不用付錢給別人。

所以這筆帳大致是這樣：花幾天把規格寫清楚，換掉的是「幾週工程 ＋ 連帶影響 ＋ 上線日往後推」這一整包風險。 通常划算，而且愈是功能複雜、串接愈多的專案愈划算。反過來說，如果你的網站只是五頁的形象官網、沒有金流也沒有串接，那把規格寫成十頁確實是浪費——這種專案本來就沒什麼「做完了沒有」的爭議空間。

判斷方式很簡單：專案裡只要有「錢會流動」或「資料要跨系統跑」的環節，規格就值得認真寫。 純內容展示的網站，抓個重點就好。

先分清楚兩件事：你要達成什麼，跟工程師怎麼做到

這是寫規格最容易一開始就走錯的岔路。

很多人寫需求時，會不自覺地寫進實作方式：「首頁輪播要用 Swiper」「後台要用 WordPress」「資料庫要用 MySQL」。感覺很專業，但這通常不是在幫自己，而是在幫自己綁手綁腳。

國際上定義需求該長什麼樣的標準是 ISO/IEC/IEEE 29148，它列出一條合格需求應該具備的特性，其中一項叫做「適切（Appropriate）」——意思是需求的抽象層級要對，要排除不必要的限制，避免寫進實作細節。

用白話講：你負責定義「要達成什麼」，開發團隊負責決定「怎麼做到」。你把實作方式寫死，等於是自己承擔了技術選擇的風險，而你其實沒有能力承擔它。

打個比方。你請水電師傅來裝一套熱水系統，你該說的是「兩間浴室同時用熱水的時候，水溫不能掉」「我家沒有陽台，機器要能裝在室內」。你不需要指定他用哪個牌子的哪一顆加壓馬達——那是他的專業，而且他選的那顆壞掉時，責任在他。你一旦指定了型號，責任就變成你的了。

當然，有些實作面的東西你是該寫進去的，因為它們其實不是實作，是限制條件：

這算「你要達成什麼」（該寫死）	這算「工程師怎麼做到」（該留白）
網站要能在手機、平板、桌機正常瀏覽	用哪套 CSS 框架做響應式
編輯人員要能自己更新最新消息，不需要工程協助	後台用哪一套 CMS
要能串接現有的 ERP 抓庫存	用 API 還是排程同步
資料每天要有備份，可回復到七天內任一天	備份放哪個雲、用什麼工具
網站要沿用公司既有的 CI 色系與字體	前端怎麼切版

右邊那一欄有個例外：如果你公司內部已經有工程人力、將來要自己接手維護，那技術選型就從「實作細節」升格成「限制條件」，這時候寫進規格是合理的，但要說明理由。 規格書裡的每一條限制，都應該有一個能講出口的原因。

不懂技術也寫得出功能清單，從「誰要完成什麼事」開始拆

直接回答這一節的問題：你不需要懂程式，因為你要寫的不是技術規格，是任務清單。

你需要的其實只是換一個問法——不要問「網站要有什麼功能」，改問「誰會用這個網站，他來這裡是要完成什麼事」。

功能是技術語言，任務是你的語言。你完全講得出後者。

實際做法分三層：

第一層，列出所有會碰到這個網站的人。 不要只想到客戶。一個企業網站通常至少有四種人：不認識你的訪客、已經是客戶的人、公司內部要更新內容的同事、公司內部要看數據或處理訂單的同事。有些網站還會有第五種：外部的經銷商、供應商、或需要登入的會員。

第二層，逐一問每種人「他來這裡要完成什麼事」。 例如內部同事的任務可能是「每週貼一篇最新消息」「月底匯出這個月的詢價名單」「客戶打電話來時，快速查到他上次問過什麼」。

第三層，把每個任務翻成一句功能敘述。 「每週貼一篇最新消息」→「後台提供最新消息的新增、編輯、下架功能，支援圖片與超連結」。

這樣拆出來的清單，通常會比你原本憑空想的完整很多，而且不會漏掉最容易被忘記的那一群人——網站上線後真正每天在用它的，往往不是客戶，是你自己的同事；但功能清單裡最常被漏掉的，也正是他們。

還有一個判斷方式，比你自己寫得好不好更管用：看廠商在需求訪談時問了什麼。

如果對方從頭到尾只問「你要幾個頁面」「你有沒有參考網站」「預算多少」，那他在報一個網頁的價。如果對方會問「這個表單送出去之後，誰會收到？收到之後他要做什麼？」「你們現在的訂單資料存在哪裡？」「這個功能如果第一年沒人用，你還要不要它？」——那他在幫你把需求拆開。

看廠商問什麼問題，比看他報多少錢更能判斷他行不行。 報價可以壓低，問題問不出來就是問不出來，而問不出來的那些，最後都會變成追加費用。

必須、想要、有更好——這一步決定你的報價會不會失控

英文的需求文件寫作有一個很成熟的做法，叫做需求分級。把每一條需求標上優先層級，讓報價方知道哪些是不能砍的、哪些是可以談的。

翻成白話就三級：

層級	判準（用這句話問自己）	對報價與專案的影響
必須有	沒有這個，網站上線也沒有意義、或根本不能上線	這一層決定專案的價格底線，不能砍
想要有	有的話會明顯更好，但沒有不影響上線	這一層是預算的調節閥，也是分期開發的第一批候選
有更好	想到了、寫下來，但坦白說暫時沒有也還好	這一層最適合留到第二期，不要放進第一次報價

分級不是為了砍功能，是為了讓「砍功能」這件事在報價超出預算時有依據，而不是臨時憑感覺刪。

實務上這一步的價值會在兩個時間點顯現。第一次是收到報價的時候：如果報價超出預算，你不需要重談整個專案，只要把「有更好」那一層整批移到第二期，價格就會下來，而且你很清楚自己犧牲了什麼。第二次是專案中途：當你想加一個新功能時，分級表讓你可以說「我想加這個，那把原本『想要有』裡的某某拿掉，換掉它」——這是一個對雙方都合理的談法，比單純要求「順便加一下」好談太多。

還有一個很實際的好處：分級會逼你自己面對現實。 很多清單上洋洋灑灑三十條功能的專案，真的逐條問「沒有這個能不能上線」之後，會發現「必須有」大概只有八到十條。剩下的二十條不是不重要，是它們可以晚一點。

同一句需求的三種寫法，差別在能不能驗

現在來到規格書真正的技術活：把一句話寫到「將來可以拿它來驗收」的程度。

前面提到的 ISO/IEC/IEEE 29148 對單一需求列了一組品質特性，包括必要、適切、無歧義、完整、單一、可行、可驗證、正確、一致。這九項聽起來很抽象，但實際用起來，只要抓住其中兩項就能解決八成問題：無歧義（只能有一種解讀）與可驗證（能證明它做到了）。

國際系統工程協會 INCOSE 在一份談需求目的的公開文件裡直接點名，像「user-friendly（好用、使用者友善）」這種主觀字眼不能出現在需求裡，因為它無法被驗證——沒有人能證明一個東西「夠不夠好用」。

我們拿一句台灣業主最常講的話來實際改三次。

第一版（原始說法）：「後台要好操作。」

這句話的問題不是它不重要，而是它無法驗收。上線後你說不好操作，廠商說已經很好操作了，兩邊沒有共同基準。

第二版（試著具體化）：「後台介面要簡單，讓不懂電腦的同事也能用。」

有進步，但還是不能驗。「簡單」是誰的簡單？「不懂電腦」到什麼程度？

第三版（可驗證）：「行銷部同事在只看過一次操作說明的情況下，能夠獨立完成『新增一篇含三張圖與兩個超連結的最新消息並發布』的流程，全程不需要工程人員協助，且在十分鐘內完成。」

第三版看起來很囉嗦，但它有三個第一、二版沒有的東西：誰（行銷部同事）、做什麼（明確的一個任務）、達到什麼標準（不需協助、十分鐘內）。驗收那天，把人找來，做一次，結果一翻兩瞪眼。

再看幾組對照：

不可驗證的寫法	可驗證的寫法
網站速度要快	首頁在 4G 行動網路下，主要內容顯示時間不超過 2.5 秒（以 Google PageSpeed Insights 行動版量測為準）
網站要對 SEO 友善	每個頁面可獨立設定標題與描述；網站產生 sitemap.xml；所有頁面可被搜尋引擎索引（除指定的後台頁面）
要能支援手機	在螢幕寬度 375px 至 1920px 之間，所有頁面內容不出現橫向捲動，主要按鈕可單手點擊
網站要安全	全站啟用 HTTPS；後台登入具備錯誤次數限制；上傳檔案限制副檔名與大小
資料要能匯出	管理者可將詢價名單以 CSV 格式匯出，欄位包含姓名、聯絡方式、詢問內容、送出時間

注意右欄沒有一句話寫到「用什麼技術做」。這就是前面說的分層：把標準寫死，把方法留白。

你不需要每一條需求都寫到這種程度。抓一個原則就好：這條需求如果將來會有爭議，就寫到可驗證；不會有爭議的，寫得簡單一點沒關係。 規格書的長度不是美德，能不能終結爭議才是。

非功能性需求：沒人在談，卻最容易在上線後爆炸的那一半

先給答案：功能沒做出來，驗收當天就看得到；非功能性需求沒做到，通常要等到流量上來、資料變多、或出事的那一天才會發現。

到目前為止我們談的都是「網站能做什麼」，這在專業上叫功能性需求。還有另一半叫非功能性需求，講的是「網站要做得多好」。這一半在中文的網站發包討論裡幾乎是空白的。

類別	你該問自己的問題	寫進規格的例子
效能	尖峰時段大概多少人同時在用？資料會長到多大？	商品列表頁在 5,000 筆資料下，載入時間不超過 3 秒
相容性	我的客戶用什麼裝置、什麼瀏覽器？	支援最新版本與前一版本的 Chrome、Safari、Edge；支援 iOS 與 Android 主流瀏覽器
無障礙	有沒有法規與標章要求？有沒有視障使用者？	文字與背景對比度符合 W3C WCAG 2.2 AA 等級；所有圖片有替代文字
資安與個資	會蒐集個資嗎？存哪裡？誰能看？	個資欄位加密儲存；後台權限分級；符合個人資料保護法之告知義務
備份與復原	出事的時候，能倒回到哪一天？	每日自動備份，保留 30 天，可回復至任一備份時點
維運	上線後誰改？多快要修好？	系統異常回報後 4 小時內回應，24 小時內提出處理方案
可擴充	一年後可能要加什麼？	商品分類層級可由管理者自行擴充，不需修改程式碼

其中有兩項在台灣正在變成法遵問題，不再只是加分項，值得單獨講。

個資：一萬筆是一條真實的分界線

如果你的網站會蒐集會員資料、訂單資料、詢價名單，這一段跟你有關。

台灣的個資監管在 2025 年有一次結構性的變動：個人資料保護法部分條文修正案於 2025 年 11 月 11 日公布，原本分散在各目的事業主管機關的監管權限，改由 個人資料保護委員會 集中負責。對企業而言最實際的影響是：非公務機關中，非屬中小企業且保有個人資料檔案達一萬筆以上者，須訂定個人資料檔案安全維護計畫，包含指定專責人員、建立個資盤點清冊、定期風險評估與內部稽核。

一萬筆聽起來很多，但一個經營三五年、有會員制度或電商訂單的網站，累積到這個量級並不困難。

這件事跟規格的關係是：如果你的網站會落在這條線上，那「個資盤點清冊」「權限分級」「存取紀錄」就不是加值功能，是法遵需求，必須寫進規格、寫進驗收。 等到主管機關來稽核才回頭改，成本高很多。

無障礙：目前是免費的品質基準，未來可能是門票

台灣的政府網站有無障礙標章制度，由數位發展部的無障礙網路空間服務網負責；一般民間企業網站目前沒有普遍性的法定義務。

但國際上的方向很明確。歐盟的《歐洲無障礙法案》（Directive (EU) 2019/882）自 2025 年 6 月 28 日起，對投放到歐盟市場的新產品與服務課予無障礙義務，適用對象包含電子商務服務，而且不以企業註冊地為準——只要你要在歐盟市場做生意就適用（員工少於 10 人且年營收低於 200 萬歐元的微型企業有豁免）。它採用的技術基準是歐洲標準 EN 301 549，而該標準又是以 WCAG 為底。

⚠️ 這是歐盟的規定，不是台灣現況，台灣目前沒有對一般民間網站的等同義務。列出來是因為兩件事：一是如果你的網站有歐洲客戶或計畫進歐洲市場，這件事已經發生了；二是它顯示無障礙正在從「建議」變成「條件」。

即使這兩件事都跟你無關，還是有一個很務實的理由把無障礙寫進規格：無障礙標準是少數把「網站要好用」寫成可以量測的數字的規範。 文字對比度要多少、可點擊目標要多大，W3C 的 WCAG 2.2 都有明確數值。把 AA 等級寫進規格，等於免費拿到一組現成的、可驗收的品質標準——你不用自己發明「怎樣叫做好讀」。

驗收標準要在開工前寫，不是上線前才想

這一節是台灣中小企業踩雷最多的地方。

典型的走法是這樣的：規格談完、報價簽了、開始做，三個月後廠商說一句「好了，你看一下」。這時候雙方才第一次認真討論「什麼叫好了」——而這個時間點，雙方的立場已經完全對立，一個想結案收尾款，一個想再改一輪。

驗收標準要在開工前寫，理由其實很簡單——那是整個專案裡，唯一一個雙方立場還一致的時間點。

台灣其實有現成的參考範本可以抄。行政院公共工程委員會有一份〈資訊服務採購契約範本〉，是政府機關發包資訊服務時的官方契約格式，民間企業當然沒有義務照用，但它把「付款要綁在履約階段與驗收」這件事處理得很完整，是很好的參考骨架。工程會另外還有〈採購契約要項〉，其中對「契約變更」下了明確定義——指原契約標的之規格、價格、數量或條款之變更，並包括追加契約以外之新增工作項目。這句話值得抄進你自己的合約，因為它把「什麼算變更」講清楚了。

至於驗收該驗什麼，最常見的錯誤是：只驗畫面，不驗行為。 打開網站，跟設計稿長得一樣，就簽字了。但畫面一樣不代表功能對，更不代表非功能性需求達標。

一份可用的驗收清單，至少要涵蓋四層：

層次	驗什麼	誰來驗
看得到的	頁面數量與內容齊全、視覺符合確認過的設計稿、各種裝置尺寸下的呈現	專案窗口
點得動的	每一條「必須有」的功能逐條實際操作一遍	將來真正會用的人，不是廠商示範
量得出來的	速度、相容性、無障礙這類有數值的項目，用工具實測並留下報告	廠商提供報告，你抽驗
交得出來的	原始碼、資料庫、帳號密碼、第三方服務所有權、後台操作說明、教育訓練	專案窗口逐項簽收

第二層那個「誰來驗」值得特別說一次。驗收要由將來真正的使用者操作，不是由廠商示範——廠商示範的是他知道怎麼走的那條路，你要驗的，是別人不知道怎麼走的時候會怎樣。 讓實際要用後台的同事自己點一遍，十分鐘就會冒出三個規格沒寫到的問題，而那時候還來得及談。

第四層最常被漏掉，而它是四層裡面唯一「事後補不回來」的。交付清單沒寫進合約，等到雙方拆夥那天才要原始碼，你會發現手上什麼籌碼都沒有。

需求中途要改怎麼辦？變更控制不是為了刁難你

這裡要先講一句，可能跟你想的不太一樣：需求中途會改，是正常的，不是失敗；沒有一套決定「改不改」的機制，才是失敗。

任何一個做了三個月的專案，中途一定會出現「原本沒想到」的事。真正的問題不是「能不能改」，而是「改了之後，時間、金錢、範圍怎麼重新算」。

專案管理的專業社群早就把這件事研究得很透徹——範圍在專案過程中不受控地膨脹，有一個專有名詞叫 scope creep（範圍潛變），而它最主要的成因不是客戶貪心，是初始需求本來就不完整、加上沒有一套決定「改不改」的機制。

所以合約裡該有的不是「不准改」，是「改的程序」。一個對雙方都公平的變更流程，大致是這樣：

1. 提出變更（誰都可以提，包含廠商）
2. 廠商評估對工時、費用、時程的影響，書面回覆
3. 雙方決定要怎麼處理
4. 決定結果寫成書面紀錄，附在合約後面

第三步的「怎麼處理」，實務上有四種選擇，而多數人只知道第三種：

處理方式	什麼情況適用	對誰有利
吸收	影響很小，例如文案調整、顏色微調	通常廠商吸收，維持關係
等值置換	你想加 A，同時願意拿掉一個差不多份量的 B	雙方都不吃虧，是最被低估的一種
追加計價	新需求份量大，且確實是新增的	廠商合理收費，你要拿到明確報價再點頭
延到第二期	重要但不急，不影響第一期上線	保住上線時程，最務實

「等值置換」是四種裡最被低估的。 你手上如果有前面做過的三級分類表，這件事會變得非常好談：「我想加這個新功能，那把『想要有』裡的匯出報表功能拿掉，這樣份量差不多。」廠商通常會答應，因為總工時沒變。反過來說，沒有分級表的專案，每次變更都只能走「追加計價」或「吵架」兩條路。

合約裡這三件事沒寫，做完才會發現不對

規格談完、驗收寫完，還有三件事是簽約前一定要處理的。它們的共同特徵是：平常完全不會有感覺，一旦出事就沒有轉圜餘地。

第一件：原始碼與著作權歸屬。 網站做完，程式碼是誰的？依著作權法，出資聘請他人完成的著作，在雙方沒有另外約定的情況下有一套預設歸屬規則——重點不在那個預設值是什麼，而在於法律允許雙方另行約定。所以正確做法不是去猜預設值，是在合約裡直接寫清楚四件事：著作財產權歸誰、你是否取得完整原始碼、你能不能自行修改、能不能交給第三方繼續開發。這四句話寫進合約要花五分鐘，沒寫進去可能讓你三年後被綁死在同一家廠商身上。

第二件：上線後的維護範圍與期限。 「保固一年」這四個字沒有意義，除非合約寫清楚保固涵蓋什麼。實務上該把兩件事分開定義：

	保固	維護
涵蓋什麼	修復「不符合驗收標準」的缺失	上線後的內容更新、功能調整、環境升級
誰付錢	廠商，通常內含在專案價	另計，通常按月或按次
該寫進合約的	期限多長、回應時間、什麼情況不算	費用怎麼算、含幾小時、超出怎麼計

第三件：瑕疵擔保的時間界線。 台灣的網站開發合約，法律性質上多半屬於民法的承攬契約。承攬編對定作人發現瑕疵後可以主張的權利與期限有明文規定，包含發見期限與權利行使的時效。實務上的意義是：你不能在驗收簽字很久之後才回頭主張某個功能有問題，法律上是有時間界線的。 反過來說，這也是為什麼驗收那一關要認真做——簽下去的那一刻，主張瑕疵的時鐘就開始跑了。

這三件事都不需要你變成法律專家。但它們都需要你在簽約前，把話從「大家都懂啦」，變成「白紙黑字寫在第幾條」。

發包前的規格自我檢查表

把前面談的整理成一份可以直接用的清單。你不需要每一項都填得很完美，但每一項都應該被想過一次——空白比寫錯更危險，因為寫錯至少會被討論到。

目標與範圍

• 這個網站要承擔什麼任務？成功的話，什麼數字會變？
• 這次做的範圍到哪裡？哪些明確不做（寫下來比不寫重要）？

使用者與功能

• 有哪幾種人會用這個網站？（別忘了內部同事）
• 每種人各要完成哪些任務？
• 每個任務對應的功能敘述是什麼？
• 每條功能標好「必須有／想要有／有更好」了嗎？

內容與資料

• 文案、圖片、影片誰負責？什麼時候給？
• 舊網站的資料要不要搬？搬多少？誰整理？
• 要串接哪些既有系統或第三方服務？串接文件拿得到嗎？

非功能性需求

• 效能、相容性、無障礙、資安與個資、備份、維運、可擴充，七項各寫一句了嗎？
• 網站會蒐集個資嗎？資料量可能到什麼規模？需不需要處理法遵？

驗收

• 驗收標準寫進合約了嗎？
• 誰來驗？用什麼方式驗？驗多久？
• 交付清單（原始碼、帳密、文件、教育訓練）列出來了嗎？

變更與合約

• 變更流程寫了嗎？四種處理方式談過了嗎？
• 著作權與原始碼歸屬寫清楚了嗎？
• 保固與維護分開定義了嗎？

如果這份清單你填不滿，其實也沒關係——填不滿本身就是有用的資訊，它會告訴你哪些地方需要在需求訪談時特別問。 一個經驗夠的開發團隊，本來就會帶著你把這些空格補起來；你要判斷的是，對方有沒有主動問這些問題。

真的走到需要有人陪你把模糊需求拆成規格這一步，找一個願意在報價前先花時間把問題問清楚的開發夥伴，長期算下來通常比找報價最低的那一家省錢。

常見問題