1. 首頁
2. 知識庫
3. Sharing AI 架站平台教學
4. 網站需求書怎麼寫？架站前的需求規格、驗收標準與範本

Sharing AI 架站平台教學

網站需求書怎麼寫？架站前的需求規格、驗收標準與範本

作者：JamXu更新日期：2026-10-27

網站需求書是什麼？和詢價單、提案、合約差在哪裡

架網站最常見的爭執，不是技術做不到，而是雙方對「做好」的想像不同。業主說的「要有會員功能」，廠商可能理解成一個登入頁；業主說的「手機版要好用」，到了驗收時才發現沒有人知道怎樣算好用。網站需求書的作用，就是在動工前把這些想像寫成同一份文字。

網站需求書是一份說明「網站要做什麼、做到什麼程度、由誰負責」的文件，它是報價、簽約、製作與驗收共同的依據。它和架站過程中其他幾份文件的分工如下：

還在判斷要不要改版，先寫一頁網站改版決策單；只想知道大概要花多少錢，用架站費用拆解中的詢價單問價即可。需求書則在決定要做之後寫，把詢價單的每一欄展開成可以逐條檢查的規格。

為什麼值得花時間寫？需求不清是網站專案最常見的問題

需求不清的代價，連政府機關也很熟悉。根據行政院 112 年 10 月的院會新聞稿，資訊服務產業反映資服採購遭遇的困境包括採購需求不明確、費用不足及爭議處理費時，工程會因此訂定指引，提醒機關應反覆檢視需求、合理編列費用。工程會與數位發展部於 2023 年 9 月 25 日上路的《資訊服務採購作業指引》，也把「開發過程需設定查核點」列為重點之一。

企業網站的規模比政府系統小得多，但道理相同：需求寫得越具體，報價越能比較、進度越好掌握、驗收越少爭議。

• 報價可以比較：每家廠商依同一份需求估價，價差才看得出是範圍不同還是單價不同。
• 範圍有邊界：需求書沒寫的功能，就是額外的變更，雙方都知道要另外討論時程與費用。
• 驗收有標準：每條需求都附上判斷方法，驗收時對照清單打勾，而不是憑感覺。

動筆之前：誰來寫、誰要參與

需求書最好由業主這一方主導，因為只有你知道生意怎麼做、顧客會問什麼。但它不該由一個人關起門來寫完。網站牽涉業務、行銷、客服與管理多個部門，少了誰的意見，上線後就會在那個環節卡住。

小公司一人身兼多職沒關係，重點是每一欄都有名字。最容易被漏掉的是驗收人與內容提供者：沒有指定驗收人，最後常變成老闆在上線前一天才第一次看到網站；沒有指定內容提供者，頁面就會一直停在範本文字。

一份網站需求書的九個章節

需求書沒有法定格式。數位發展部公開的系統建置案〈建議書徵求文件〉參考範本，把需求分成整體、功能、效能、資安與管理需求，另列工作時程、教育訓練與交付項目。企業網站可以精簡成下面九個章節：

第 1 到 5 章描述「要做什麼」，第 6 到 9 章描述「怎麼完成與交接」。很多人只寫前半段，結果網站做得出來，卻在驗收、付款與維護時起爭執。後四章的篇幅可以不多，但一定要有。

第一章與第二章：目標、使用者與成功指標

網站目的寫得太抽象，是需求書最常見的開頭問題。「提升品牌形象」「增加曝光」這類句子沒有錯，但沒有人能據此判斷某個設計是好是壞。比較好的寫法，是把目的拆成「誰、做什麼、怎麼量」。

使用者與情境這一章寫「誰會來、為什麼來」。設備維修公司的訪客，可能是比較廠商的採購人員，也可能是機器故障、急著找電話的老客戶，兩者需要的頁面完全不同。列出二到四種主要訪客，各寫下來源、想解決的問題與希望的行動即可。

成功指標不是驗收標準，沒有人能保證詢問量或排名，但它決定網站要裝哪些追蹤。上線後才想追蹤，前幾個月的數據就再也補不回來，追蹤代碼的安排可以在GA4 與 GTM 的設定方式中先了解。

第三章：頁面清單與內容分工

頁面這一章包含兩件事：網站有哪些頁，以及每一頁的內容從哪裡來。前者是架構，後者是分工，兩者都要寫。

頁面清單不必重新發明：依網站頁面架構與選單的規劃方法完成架構表當附件，本文只補上每頁的任務與版型種類。

內容是最容易延誤的部分，每一頁都要寫清楚由誰提供、誰改寫、何時交付。

素材的盤點與到位程度，可以直接沿用架站前品牌素材整理清單中的「頁面 × 素材」表，把到位度欄位一併附上。內容交付日要寫進時程，並註明延遲時上線日如何順延，否則內容晚交的責任，最後常常變成製作方趕工或雙方爭執。

要請廠商撰寫文案、翻譯或拍攝的頁面，標示為「委託項目」並在報價中單獨列出。交付內容前，可以先用首頁內容規劃與關於我們頁面的寫法整理段落架構。

第四章：功能需求怎麼寫成可以檢查的句子

功能需求是需求書的主體，也是最容易寫成「願望清單」的部分。判斷一條需求寫得好不好，只要問一個問題：兩個不同的人拿著這句話去檢查網站，會不會得到相同的結論？會，就是可以驗收的需求；不會，就要改寫。

用「誰、在什麼情況、可以做什麼、結果是什麼」來寫

比較穩定的寫法，是把每條功能寫成一個情境：某一類使用者，在某個情況下，可以完成某件事，完成後會看到或收到什麼。這樣寫的好處是，驗收時可以直接照著句子操作一遍。

替每條需求標上優先順序

預算有限時，把需求分成三級：「必要」是沒有就不能上線的功能，例如詢問表單；「重要」是上線後短期內要補上的功能，例如常見問題頁；「加分」是有餘裕再做的功能，例如動態效果或多語版本。分級要在報價前完成，因為它直接決定第一版的範圍與費用。

表單是大多數企業網站最關鍵的功能，欄位取捨、個資告知與通知對象都值得在需求書裡寫清楚，聯絡表單的設計方法整理了需要事先決定的每一項。

第五章：非功能需求，速度、手機、無障礙與資安

非功能需求描述「做得多好」，而不是「做什麼」。它們很少被業主主動提出，卻是上線後最常被抱怨的部分：手機版跑版、載入很慢、表單被灌垃圾訊息。沒寫在需求書裡，驗收時就很難要求修正。

速度要求寫數字，但要寫對指標

「網站要很快」無法驗收。根據Google 搜尋中心對核心網頁指標的說明，良好的使用者體驗是 LCP（最大內容繪製）在 2.5 秒內、INP（與下一個顯示的互動）低於 200 毫秒、CLS（累計版面配置位移）低於 0.1。把這三個門檻寫進需求書，比寫「秒開」具體得多。

要注意的是，核心網頁指標的正式數據來自真實使用者，新網站上線前通常還沒有。驗收時先參考 PageSpeed Insights 的實驗室數據，你可以依PageSpeed Insights 的指標說明判讀分數。

手機版與無障礙：用可以觀察的條件來寫

手機版不要只寫「響應式設計」，而是列出可以觀察的條件：沒有左右捲動、可以放大、圖片與表格不超出畫面、按鈕夠大。這些條件的檢查方法，RWD 響應式網站的檢查重點有逐項說明。

無障礙方面，台灣的網站無障礙規範以 WCAG 2.1 為基礎。一般企業網站即使不追求完整符合，把「替代文字、對比、表單標籤、可用鍵盤操作」幾項基本要求寫進需求書，成本不高，也能讓更多人順利使用網站。

資安與個資：寫清楚誰負責

資安需求的重點是責任歸屬：主機與程式由誰更新、發現漏洞多快處理、後台帳號由誰管理。自架主機與架站平台的分工完全不同，站長安全檢查清單與平台的責任分工整理了兩者的差別；有表單時，也要把隱私權政策與 Cookie 告知列為上線條件。

第六章：驗收標準怎麼寫，每條需求都要有判斷方法

驗收標準是需求書中最有價值、也最常被省略的部分。驗收標準回答的是「怎樣才算完成」，它要在動工前寫好，而不是做完才討論。如果等到驗收時才訂標準，雙方都會傾向對自己有利的解釋。

寫驗收標準最簡單的方法，是在每條需求旁邊加兩欄：「怎麼檢查」與「合格條件」。檢查方法要寫出具體操作，合格條件要寫出看得到的結果。

設計風格難有客觀標準，可以改成驗收「過程」：約定提案數量、修改次數與簽核方式。設計稿一旦簽核，之後的大幅修改就屬於需求變更，這一點也要在需求書裡事先說明。

改版時最容易漏掉舊網址轉址，網站搬家的網址對照表可以直接當成附件。

驗收流程：分階段驗收、問題分級與驗收紀錄

驗收不該只在上線前一天做。分階段各驗收一次，問題越早發現，修正成本越低。

問題要分級，才知道能不能上線

不是每個問題都要修好才能上線，先約定等級與處理方式：

• 嚴重：影響網站主要目標或造成錯誤資訊，例如表單送不出去、價格或電話錯誤、頁面打不開。必須修正後才能上線。
• 一般：功能可以使用但不符合需求，例如某頁手機版排版跑掉、某個欄位順序錯誤。約定在上線後幾個工作天內修正。
• 輕微：錯字、間距、圖片稍微模糊等不影響使用的問題。列入清單，統一修正。

每次驗收都在共用試算表留下紀錄：日期、檢查人、每條需求的結果、問題等級與預計修正日，修正後再複驗。

付款節點最好和驗收階段對應。民法第 505 條規定，工作分部交付且報酬就各部分定之者，應於每部分交付時給付該部分報酬；把階段、交付物與金額寫清楚，付款時點就不會有爭議。

第七章：交付物、帳號與著作權，上線後網站屬於誰

網站做好後你手上應該有什麼？很多人等到換廠商時才發現答案是「什麼都沒有」。需求書要列出交付清單：

• 帳號與權限：網域註冊、架站平台或主機、網站後台、Google Analytics、Search Console 等帳號，都以公司名義或公司信箱開設，廠商只取得必要的使用者權限。
• 檔案：設計原始檔、照片與影片原始檔、標誌與圖示的向量檔。
• 文件：網站架構表、後台操作手冊、追蹤設定說明、網址對照表與驗收紀錄。
• 程式：如果是客製開發，約定是否交付原始碼與部署說明。
• 教育訓練：後台操作教學的次數、時數與對象，最好錄影保存。

著作權是另一個常被忽略的問題。根據著作權法第 12 條，出資聘請他人完成的著作，除契約另有約定外，以受聘人為著作人；著作財產權依契約約定，未約定時歸受聘人享有，出資人只能利用該著作。換句話說，付了設計費，不代表網站的設計稿、文案與照片的著作財產權就自動屬於公司。

需求書與合約至少要寫明：設計稿、文案、照片與程式的著作財產權歸誰；如果歸廠商，公司可以在哪些範圍、多久期間使用；廠商使用的圖庫、字型與外掛，授權是否涵蓋公司日後的用途。實際條款涉及個案判斷，金額較大的合約建議請律師審閱。

帳號權限的原則和SEO 公司合約與帳號權限的檢查相同；網域則一定要登記在公司名下，理由在網域名稱的註冊與續約注意事項中有說明。

第八章：時程、查核點與需求變更

時程表要列出每個階段的期間、交付物，以及哪些項目由業主提供，進度落後時才看得出是哪一個環節卡住。

上面的週數只是示意，實際時程依網站規模與雙方人力而定。重點在於每一列都有「業主要提供」：業主的回覆速度與內容交付，往往比製作本身更決定上線日期。

需求變更：不是不能改，而是要有程序

專案中途改需求很正常，問題在於口頭說一聲就改，最後沒有人記得改了什麼、影響多少時間與費用。建議約定一個簡單的變更程序，並在每次修改後更新需求書的版本號：

1. 提出：由專案負責人以書面（Email 或共用表單）提出變更內容與理由。
2. 評估：製作方回覆這項變更對時程與費用的影響，以及是否影響其他功能。
3. 決定：由決策者確認是否執行，或改列為上線後的第二階段。
4. 記錄：更新需求書的版本號與變更紀錄，驗收標準一併修改。

第九章：保固與維護，上線後誰負責

網站上線不是終點。需求書最後一章要寫清楚兩件不同的事：保固和維護。保固是修正交付時就存在的問題，維護是上線後持續的工作，兩者常被混為一談，結果發生問題時雙方對「這該不該收費」有不同看法。

委託廠商完成網站、完成後付款的合作，性質接近民法所稱的承攬。民法第 492 條要求工作具備約定品質，第 493 條讓定作人可定相當期限請求修補瑕疵；但依第 498 條，瑕疵在交付後經過一年才發現就不能再主張。建議在合約中直接寫明保固期間與範圍，個案適用請諮詢專業人士。

維護要把回應時間分級寫清楚，例如網站無法開啟時多久回應、一般修改多久完成。用架站平台時主機與安全更新多由平台處理；自架主機則要寫明誰負責系統與外掛更新。

最後，指定一位公司內部的網站負責人，即使維護全部委外，也要有人知道帳號在哪裡、廠商是誰、合約何時到期。上線前的最後一關，可以搭配網站上線前檢查清單逐項確認。

網站需求書範本：可以直接複製的欄位

下面這份範本把前面九章濃縮成一張表。複製到文件或試算表後，依自己的網站逐欄填寫；寫不出來的欄位，就是需要在發包或動工前先討論的地方。

參考網站要寫出「喜歡的是哪一部分」，只附網址，製作方只能猜。已有配色、字型與按鈕的網站設計規範時，也一併附上。

五頁左右的形象網站，整份需求書加附件可能只有五到八頁；有會員、購物或系統串接時就會長得多。長短不是重點，每一條都能被檢查才是重點。

自己用 Sharing AI 架站時，需求書怎麼用

自己用架站平台製作時，需求書一樣有用：先拿來檢驗平台，再當製作清單，最後當驗收表。

以 Sharing AI 架站平台為例，需求書中常見的項目在後台大致對應以下位置（名稱以 2026 年 10 月的後台為準）：

Sitemap、麵包屑結構化資料與改網址時的 301 轉址由平台自動處理，在需求書中標成「平台內建，驗收時確認」即可；各功能的操作畫面集中在Sharing AI 架站平台教學。還在比較自己做與委外的話，先讀無程式碼架站的適用情境與限制，再拿需求書逐條試用Sharing AI 架站平台。

寫網站需求書常見的八個錯誤

最後整理幾個在需求書裡反覆出現的問題。寫完初稿後，用這張清單檢查一次：

• 只寫形容詞：「美觀」「好用」「快速」無法驗收。
• 只指定做法不說目的：「首頁要放輪播」不如「首頁第一個畫面說明三項主要服務」。
• 每一條都是必要：沒有優先順序，預算不夠時就無從取捨。
• 忘了內容由誰提供：頁面規劃完整，卻沒人寫文字。
• 沒有驗收標準：做完才討論怎樣算完成，雙方各自解讀。
• 帳號不在公司名下：網域與後台由廠商或個人開設，日後難以收回。
• 沒寫著作權歸屬：以為付了錢就擁有所有設計與照片的權利。
• 上線後的責任空白：沒寫保固、維護與內部負責人。

寫完後請一位沒參與討論的同事讀一遍：網站做給誰、怎樣算完成、出問題找誰，三題都答得出來，就可以拿去詢價或開始製作了。

如果你想先把需求整理清楚，再決定要自己用平台做還是委託製作，也歡迎與我們聯絡，一起討論網站的目標、範圍與適合的做法。