軟體需求怎麼寫：非工程師也能完成的需求文件
「我把想法講給廠商聽了，為什麼做出來不是我要的？」這個問題的答案通常不在對方身上，而在於雙方對同一句話的理解不同——而沒有人發現。
需求文件的作用不是給工程師看的技術規格，而是把雙方腦中的畫面對齊。你不需要懂技術也能寫，因為真正該由你提供的是業務規則，那一段只有你知道。
需求文件該包含什麼
一、目標與成功條件
先寫「為什麼要做」，而不是「要做什麼功能」。
不好的寫法：我要一個會員系統。 好的寫法：我想知道哪些客人超過三個月沒回來，並且能只對他們發訊息。目前這件事要靠人工翻出貨單，一個月做一次都很吃力。
把目標寫清楚的好處是：開發方有機會提出你沒想到、但更簡單的作法。只講功能，對方就只會照著做。
成功條件則是驗收的依據——上線後什麼情況算達成？這一段值得多花時間，因為它同時是驗收標準，相關作法見軟體驗收測試 UAT 指南。
二、使用者與角色
列出會使用這套系統的每一種人，以及他們各自能做什麼、不能做什麼。
| 角色 | 主要工作 | 不該能做的事 |
|---|---|---|
| 顧客 | 下單、查詢自己的紀錄 | 看到別人的資料 |
| 門市人員 | 建立訂單、查詢會員 | 修改金額、匯出名單 |
| 主管 | 審核、看報表 | — |
| 系統管理者 | 帳號與權限管理 | — |
這張表常常在寫的當下就問出問題：店長到底算不算主管？工讀生能不能查會員手機？這些爭議越早浮現越好。
三、主要流程
用最簡單的方式描述「從頭到尾會發生什麼」，一步一行就好：
- 顧客在網站選擇商品，加入購物車
- 結帳時選擇付款方式
- 付款成功後，系統寄出訂單確認信
- 門市人員在後台看到新訂單，確認庫存
- 出貨後填入物流編號，系統通知顧客
流程寫完後，回頭在每一步問一次「如果失敗會怎樣」——這就是下面的例外情境。
四、畫面與欄位
不需要畫得漂亮，重點是每個欄位的規則：
- 這個欄位是必填還是選填？
- 有沒有格式限制（手機、統一編號、日期）？
- 有沒有長度或數值上下限？
- 填錯時要顯示什麼訊息？
- 送出之後還能不能改？
欄位規則沒寫清楚，是上線後最常出現爭議的地方。用手繪加註記、或截圖現有系統再標示要改什麼，都比純文字有效。
五、業務規則
這是整份文件最有價值、也最無法被外部取代的部分。凡是「什麼情況下要怎麼算」的條件，都屬於這一段：
- 折扣與優惠能不能疊加？順序是什麼？
- 什麼條件下自動升等？降等怎麼處理？
- 誰的訂單需要審核？金額超過多少要主管簽核（門檻由你定義）？
- 庫存不足時，是擋下訂單還是允許預購？
寫規則的訣竅是：每條規則都要能被判定真假。「重要客戶優先處理」無法執行，「標記為 VIP 的客戶，訂單自動排在列表最前面」才可以。
六、例外情境
正常流程大家都想得到，出事的時候才是系統好壞的分野。至少要想過：
- 付款失敗、付款成功但沒收到通知
- 同一筆資料兩個人同時修改
- 網路中斷、第三方服務無回應
- 資料重複（同一個人用不同方式註冊兩次）
- 需要退回上一步、需要取消已經完成的動作
七、非功能需求
不是功能，但會嚴重影響成本與體驗的條件：
- 效能：同時會有多少人使用？尖峰在什麼時候？
- 相容性：要支援哪些裝置與瀏覽器？有沒有必須支援的舊環境？
- 安全與權限：哪些資料屬於個資？誰能匯出？操作紀錄要不要留？
- 可用性：能接受的停機時間？備份頻率與還原方式？
- 語言：要不要多語系？未來會不會加？
多語系和權限是最典型的「後補比一開始做貴很多」的項目，務必在需求階段就決定。
最常被漏掉的五件事
一、資料從哪裡來。 新系統上線時，舊資料要不要搬？格式是什麼？誰負責整理？資料轉移常常是整個專案最耗時的一段，卻最少被寫進需求。
二、誰來維護內容。 上線後誰改文案、誰上架商品、誰調整規則？如果沒有後台，每次修改都要回頭找廠商。
三、通知要發給誰。 系統事件觸發的信件與訊息，收件者、內容、時機都要列出來，包含「不該發」的情況。
四、報表要看什麼。 報表需求若沒在前期提出，資料庫可能根本沒存下相關欄位，事後補就要重做。
五、結案後拿到什麼。 原始碼、設計檔、部署與維護文件、帳號權限。NETVANA 的作法是專案費用結清後完整移交這些交付物，但這件事在任何合作中都應該白紙黑字寫下來，相關檢查點見如何挑選軟體開發公司。
一份可以直接照抄的目錄
如果不知道從哪裡開始，就照這個結構往下填，每一節寫得完就寫、寫不出來就標記「待確認」——標記本身也是有用的資訊：
- 我們是誰、現在怎麼運作
- 這個專案要解決什麼問題、成功長什麼樣子
- 使用者角色與權限一覽
- 主要流程（一步一行，含每步的負責角色）
- 畫面清單與各欄位規則
- 業務規則（每條都要能判定真假）
- 例外情境與錯誤處理
- 需要串接的外部系統與服務
- 舊資料轉移範圍
- 非功能需求（效能、相容性、安全、備份、語言）
- 待確認事項與已知風險
第八項特別值得花時間。凡是要和既有系統交換資料的部分，都會牽涉到對方系統的開放程度，而那通常不在你的控制範圍內，越早釐清越好，相關風險見系統整合與 API 串接開發指南。
幾個讓文件立刻變好用的小習慣
- 用實際例子取代形容詞：不要寫「介面要簡潔」，改寫「這一頁的操作最多三步完成」。
- 附上現況截圖：現有系統或競品的畫面加註記，溝通效率遠高於純文字描述。
- 把不做的事也寫下來：明確寫出「這一期不含的功能」，能省下大量後期爭議。
- 標註優先順序：分成必要、重要、加分三級。預算或時程壓縮時，才有依據決定砍什麼。
需求與報價的關係
報價差距大，多半不是因為廠商不同，而是因為每一家看到的需求範圍不一樣。一份模糊的需求，收到的報價只能是各自的猜測；一份清楚的需求，才有比較的基礎。
想得到可比較的報價，作法是：把需求整理成一份清單，請每一家針對同一份清單逐項回覆，並要求明確寫出「不包含什麼」。成本結構與該注意的項目見網站製作費用怎麼算。
另一個常見狀況是需求還沒定型就急著開案。這時比較務實的選擇不是硬寫一份假裝完整的文件，而是先縮小範圍做第一版，用實際使用回饋補完需求——作法見MVP 最小可行產品開發指南。
變更管理：需求一定會變，重點是怎麼變
需求在開發過程中改變是常態，真正的問題是變更沒有被記錄與評估。建議在開案時就約定好三件事：
- 變更要書面提出，口頭追加不算數。
- 變更要先評估影響：牽動哪些已完成的功能、工期增加多少、費用如何計算，雙方確認後才動工。
- 變更要有落點：不緊急的需求排進後續週期，而不是打斷正在進行的工作。NETVANA 以兩週為一個 Sprint、每個週期結束提供可操作的 Demo，新需求通常會排進下一個週期。
專案為什麼會拖，多數原因都和變更沒被管理有關，更多情境見軟體專案為什麼會延遲。
需求文件不是形式，它是把「你以為」和「對方以為」的差距提早暴露出來的工具。寫的過程一定會發現自己也還沒想清楚的地方——那正是它最大的價值。
如果你手上有初步的想法但不知道怎麼整理成可以報價的需求，與 NETVANA 討論你的專案。我們的需求訪談階段會協助把模糊的想法整理成需求規格書初稿，各服務的內容與交付物可以看軟體服務介紹。
延伸閱讀：需求寫完之後怎麼挑合作對象，看如何挑選軟體開發公司；需求還沒定型就想先動，看MVP 最小可行產品開發指南；想知道交出去之後怎麼驗收，看軟體驗收測試 UAT 指南；需求寫得清楚，才談得了外包這條路，可以看軟體外包還是自建團隊；無障礙要寫進需求，事後補的成本高很多，可以看網頁無障礙設計指南；需求寫到什麼程度，其實跟合約模式互相牽動，可以看固定報價還是敏捷開發怎麼選；需求文件寫好後，接下來就是看懂廠商怎麼報價，可以看軟體報價單怎麼看；需求文件之外，啟動前還有哪些準備不能少，可以看軟體專案啟動前業主要準備什麼。
