需求蒐集範本：我在專案中使用的 7 個技巧

需求蒐集範本要有存在的價值，就得逼大家及早面對困難的對話：誰簽核、誰能擋下、成功長什麼樣子，以及系統必須多快。這份指南寫給專案經理、業務分析師與 SAP 負責人，他們需要的是一份撐得過第一次指導委員會的範本。以下是我使用的完整大綱，每個章節都有負責人，另外還有我從不跳過的五個章節，以及七個涵蓋訪談、優先順序與變更的技巧。請把大綱複製到您自己的文件，並在設計開始之前填完。

我曾親眼看著一個六位數金額的專案崩塌，因為沒有人做好需求。客戶期待的是一回事，開發團隊做出來的是另一回事。每個人都被推出去當替罪羊，這時才找我進場。

這種模式並不罕見。PMI 2014 年《Pulse of the Profession》中關於需求管理的報告發現，47% 的失敗專案未能達成目標，原因是需求管理不善。我親眼見過幾十次這種情形。

我自己也差點在一次大型系統上線中踏進同樣的處境。利害關係人各說各話，開發人員只能猜。我們喊停，擬出一份像樣的需求範本，最後準時、不超出預算，交付了業務真正需要的東西。

一位朋友的公司花了 $350K 做了一套客製 CRM，結果沒有人用。業務需要一件事，行銷想要另一件事，開發人員則做出他們以為大家想要的東西。

我有一位醫療業客戶，花了 18 個月導入電子病歷（EMR）系統，結果醫師拒絕使用。沒有人問過他們日常工作流程需要什麼。專案被廢止，重新來過。

太晚才發現，代價高昂。一份關於錯誤成本升高的 NASA 研究發現，在整合與測試階段才抓到的需求錯誤，修正成本是在需求階段抓到的 21 到 78 倍。若是在營運階段才抓到，倍數從 29 到超過 1,500 倍。在企業級專案裡，這就是一場工作坊，與一張價值數十萬的變更請求之間的差別。

1. 需求階段修正的基準成本在需求還在撰寫時就抓到
2. 整合與測試成本的 21 至 78 倍系統建好、進入測試後才抓到
3. 營運階段成本的 29 至超過 1,500 倍系統上線後才抓到

來源: NASA 錯誤成本升高研究

吃過苦頭之後，這五個章節是任何需求範本都不該跳過的。

1. 附簽名欄的執行摘要

忙碌的主管不會讀一份 30 頁的需求文件。我曾遇過一位專案發起人，在不了解自己簽的是什麼的情況下核准了專案，看到成果之後又大發雷霆。請把它控制在一頁：商業影響、時程、資源、預期效益，並在同一頁放上簽名欄，讓核准者無法聲稱自己漏看了關鍵細節。

2. 角色與影響力對照

一份名單是不夠的。您需要一張權力地圖：誰能拖垮專案、誰必須被諮詢、誰只需要被告知進度。我在之前的工作中，開發進行到第六個月時，法務部門帶著需求出現，逼得我們重新設計。當初沒有人想到要把他們納進來。請把每個受影響的部門、它的代表與它的影響力都標出來。

3. 是商業目標，不是技術需求

我們要解決什麼問題，又要怎麼衡量成功？有一家製造客戶完全依照規格導入了庫存軟體，結果倉儲作業慢了 20%。範本應該逼利害關係人，用目前的基準線來定義商業上的成功，而不是列一份功能清單。

4. 開發人員用得上的功能需求

丟掉術語。讓每一條需求都具體、可測試。「系統應該改善客戶體驗」毫無用處。「使用者必須能在 3 分鐘內完成退貨處理並開立退款」才是需求。如果您無法驗證它是否完成，就重寫。

5. 非功能需求

效能、資安、法遵、可用性、可擴展性。這是幾乎所有人都會跳過的章節，結果系統在負載下撐不住，或是資安稽核不過關。我聽過一個零售專案，系統一直運作得很好，直到黑色星期五，因為沒有人訂定效能需求，系統在負載下崩潰。請把回應時間、運行時間、尖峰使用者負載與法遵義務，用數字寫下來。

這是完整的大綱。上面五個章節都在其中，旁邊還有讓它在簽核之後仍能保持運作的各種紀錄。

章節	內容	負責人	簽核者
1. 執行摘要	問題、商業影響、時程、資源、預期效益。一頁，附簽名欄	專案發起人，由業務分析主管起草	專案發起人與財務
2. 範圍與部署基準	範圍內與範圍外、限制條件。SAP 專案：公有版、私有版或地端	專案總監	指導委員會
3. 角色與影響力對照	部門、代表人、影響力層級、諮詢或告知	業務分析主管	專案發起人
4. 商業目標	每個目標附帶 KPI、目前的基準線與目標值	流程負責人	專案發起人
5. 功能需求	編號（例如 REQ-FUN-023）、說明、來源、優先順序、驗收標準、Fit-to-Standard 決策	功能顧問主管	流程負責人
6. 非功能需求	效能、資安、法遵、可用性；SAP 專案則包含每個差異的延伸做法	方案架構師	IT、資安與法遵
7. 待議清單	延後處理的請求、提出者、下次檢視日期	業務分析主管	升級為正式需求之前不需簽核
8. 否決紀錄	什麼被否決、原因、時間與決定者	業務分析主管	專案發起人
9. 變更紀錄	簽核之後的每一項變更，及其對時間與成本的影響	PMO	變更委員會

1. 在利害關係人訪談中使用「五個為什麼」

問「您需要什麼？」，您得到的是一份願望清單。改問痛點：「什麼事讓您想把電腦從窗戶丟出去？」然後問為什麼，再問為什麼，一共五次。真正的需求通常和第一個提出的請求不一樣。

我遇過一位利害關係人，堅持要有複雜的報表功能。等我們把他實際的使用情境逐一走過，他需要的其實是三個簡單的儀表板。

2. 建立一份需求待議清單

利害關係人提出的要求中，有相當一部分永遠不會被用到。當有人堅持某件有疑問的事，我不爭論。我把它放進待議清單，每個月寄一次提醒，問它是否該移進正式需求。多數都會永遠停在待議區。

3. 對一直改變主意的利害關係人，使用三次法則

他們可以改變方向兩次，不受任何後果。第三次變更時，他們要寄信給自己的主管，說明這項變更與其影響。沒有人想寄那封信。變更就停了。

4. 用資金分配法逼出優先順序

給每位利害關係人 100 個虛擬美元，讓他們分配到所有需求上。他們不可能什麼都要，所以會把錢花在真正重要的地方。我曾用這個方法處理一家金融服務客戶，他們有超過 200 條「關鍵」需求。一個小時之內，我們就得到了真正的前 20 名。

5. 替每一條需求編號

使用一致的格式，例如 REQ-FUN-023。這能終結「我們現在討論的是哪一條需求？」的混亂，那種混亂浪費了會議時間。記下來源、是誰提的、為什麼提，這樣在需要刪減項目時，您就知道該打電話給誰。

6. 用利害關係人的語言，把需求複述給他們聽

文件寫好之後，用利害關係人自己的話，把需求讀回給他們聽。對於任何複雜的項目，在開發開始之前先做一個快速的原型或線框圖。誤解在還很便宜的時候就會浮現。

7. 記錄被否決的項目

總會有人在第五個月把已被否決的需求再拿出來。「我們四月討論過這件事，這是我們當時決定不做的原因」，這句話能很快結束那場對話。沒有這份紀錄，您就得再吵一遍。

這七個技巧適用於任何專案。SAP 專案的範本裡，還需要多三樣東西。

部署模式要放進基準

在蒐集功能需求之前，先記錄部署模式：S/4HANA Cloud Public Edition（透過 GROW with SAP 或 RISE）、Private Edition（通常透過 RISE）或地端。它決定了什麼是可能的。公有版不允許修改核心，所以依賴非標準流程的需求，必須重新調整或否決。私有版與地端允許更多彈性，代價是升級的工作量。

在做這個決定之前就蒐集需求，等決定出爐時，您會重寫其中許多條。

每個差異都要有一個延伸決策

SAP 的 Clean Core 做法，意味著每個差異都需要一項有記錄的決策：用配置解決、使用已釋出的 API 延伸（用 ABAP Cloud 做 on-stack，或在 SAP BTP 上做 side-by-side），或否決。在公有版，這由產品本身強制執行。在私有版與地端，這是 SAP 的強烈建議，而您允許的每一項修改，日後都會變成升級工作。請把這項決策放在範本的第 6 節，與效能和資安並列，並指定一位架構師擁有核准的權限。我的 Clean Core 指南說明了各個層級。

AI 起草，人來決定

AI 現在能協助處理文書工作。SAP Cloud ALM 提供需求產生功能，能從 Fit-to-Standard 工作坊的逐字稿，把需求草擬進範本，並以 AI 單位計費。像 Microsoft Copilot 這類通用助理，則能依會議記錄草擬摘要與會議紀要。

當原始資料乾淨時，AI 草擬工具確實能省下文書工作的時間。但它們不會改變訪談。提出「五個為什麼」的，仍然是人。也沒有任何工具能讓部門主管簽下執行摘要。驗證、排定優先順序與簽核，仍然是人的工作。

軟體開發。加入技術限制、整合點、使用者流程（使用者實際採取的步驟，而不只是功能），以及通過與否的驗收標準。我們在一個客戶入口網站專案漏掉了這一項，結果花了三個月爭論功能是否「運作正確」。

流程改善。把現況對照出來，包含人們在會議中不會提的那些雜亂的變通做法，依角色評估影響，並抓取確實的效能基準線。有一家製造客戶在沒有基準線的情況下大幅改造了倉儲流程。六個月後，它無法證明改善成果，也無法為花費辯護。

廠商選擇。把必備項目與加分項目分開，為評分準則加權，並把支援與導入的期待寫得鉅細靡遺，連痛處都寫清楚。我看過一家公司幾乎完全憑功能與展示印象選擇廠商。它忽略了支援需求，最後得到的系統，不付大筆額外顧問費就無法導入。

小型專案：用 Trello 讓需求依核准階段流轉，用附留言功能的 Google Docs 做審閱，用 Miro 在工作坊中做流程對照。

企業級專案：搭配需求管理附加元件的 Jira、用於動態文件的 Confluence（它的 AI 功能現在歸在 Atlassian 的 Rovo 品牌之下），以及如果您使用 Azure DevOps，則有 Modern Requirements。在 SAP 專案中，SAP Cloud ALM 把需求、使用者故事與測試案例放在同一個地方，並與 SAP Activate 路線圖連結。

工具本身沒那麼重要，連結才是。把需求連結到專案計畫與測試案例，並在需求變更時自動發送通知。「我不知道那個改了」，毀掉的專案比糟糕的工具多得多。需求一旦簽核，我寫的避免 SAP 導入中的範圍蔓延一文，談了如何維持現狀，而 SAP 品質關卡則說明需求簽核在治理循環中的位置。

簽核之後就沒人打開的範本，只是作秀。有效的範本很簡短，每個章節都有人負責，而且每當有人改變主意就更新，在任何值得執行的專案裡，這就是每一週。

需求蒐集的 5 個階段是什麼？

1. 需求引出：透過訪談、工作坊與觀察蒐集資訊
2. 分析：整理、排定優先順序，並解決需求之間的衝突
3. 文件化：撰寫規格（依方法不同，可以是 BRD、FRD 或使用者故事）
4. 驗證：確認需求反映真實的需要，而且可以測試
5. 管理：在專案其餘的時間裡追蹤變更

每個階段都建立在前一個階段之上。多數團隊會趕著做需求引出，這會在之後的每個階段製造問題。

BRD 與 FRD 有什麼差別？

商業需求文件（BRD）涵蓋商業需要：背景、目標、利害關係人、限制條件與高階需求。它回答的是「業務需要什麼？」

功能需求文件（FRD）涵蓋系統將如何運作：使用者故事、系統行為、介面與驗收標準。它回答的是「系統必須做什麼？」

我一律先從 BRD 開始，在進入 FRD 之前先取得業務上的共識。直接跳到 FRD 的團隊，常常做出技術上正確、卻解決了錯誤問題的系統。

需求的 3 種類型是什麼？

1. 商業需求：專案為何存在、它的目標與成功衡量標準
2. 功能需求：系統必須做什麼
3. 非功能需求：系統必須做得多好（效能、資安、可擴展性、法遵）

我見過的專案失敗，多數都能追溯到缺少非功能需求。系統做了被要求的事，然後在真實負載下撐不住，或是法遵稽核不過關。

SAP 的部署模式如何改變需求蒐集？

先把它記錄下來。S/4HANA Cloud Public Edition 不允許修改核心，所以建立在非標準流程上的需求，必須重新調整或否決。Private Edition 與地端允許更多彈性，但每一項修改都會增加升級的工作量。

如果在決定之前就蒐集功能需求，您會把其中許多條重做。請為每個差異加上一項有記錄的延伸決策（配置、透過已釋出的 API 延伸，或否決）。

什麼樣的需求才是可測試的？

有清楚、可衡量的通過與否條件。「系統應該很快」無法測試。「在標準負載下，95% 的查詢必須在 2 秒內回傳搜尋結果」才可以。

我的檢驗方法：您現在能不能寫出測試案例，並附上清楚的通過與否標準？如果不能，就重寫那條需求。無法測試的需求，在上線時引發的爭議，比我見過的任何其他原因都多。

如何避免需求不斷變動？

1. 變更管制：簽核之後的任何變更，在有人核准之前，都要記錄它對時間、預算與資源的影響。讓變更的成本被看見。
2. 待議清單：新的請求進待議清單，而不是直接進入範圍。每月檢視一次。多數看似緊急的請求，撐不過這段等待。
3. 品質關卡：定義「需求完成」是什麼意思，在達到之前不要開始設計。

在 SAP 專案中，延伸決策再多加一道技術檢查：需要修改核心的請求，必須先通過架構師，才能被核准。