AI 需求分析教學：把模糊交辦變成可驗收的 Given／When／Then 標準

10月 23, 2026

原內容日期：2026-09-04。本文為既有教學內容補發；範例依原文標示使用，實際權限與規則請以所屬組織核定資料為準。

需求文件很長，為什麼還會做錯？

需求落差通常不是因為文字不夠多，而是不同角色對同一句話有不同理解。

「資料要即時更新」可能代表五秒內、五分鐘內，也可能只是每天不必人工匯入。「最多 50 筆」可能是畫面顯示、單次選取或整批處理的上限。這些差異若沒有在開發前確認，最後就會變成「你當初沒說」與「這不是常識嗎」。

AI 的第一個工作，是標示不知道

AI 很擅長把零散內容整理得像完整規格，這也正是風險所在。

好的需求提示詞必須要求 AI 區分已確認需求、範例、建議、假設及待決事項。資料不足時，最有價值的答案可能不是一份漂亮規格，而是一張「現在還不能決定什麼」的清單。

先寫工作結果，再談畫面與功能

使用者常用熟悉的解法描述問題，例如「幫我加一個匯出按鈕」。專案團隊應先確認真正目的：是要提供主管週報、交付外部單位，還是保留稽核證據？

目的不同，正確解法、欄位、格式、權限與時機都可能不同。

範圍一定要有「不包含」

只有包含清單，仍然容易讓人把相關功能全部視為本次承諾。

將內容分成「本次包含、本次不包含、尚待決定」，能讓估時、報價與驗收建立在同一邊界。未納入不代表永遠不做，而是需要另行評估與核准。

正常流程只是需求的一半

真正影響現場使用的，往往是資料缺漏、重複送出、權限不足、外部系統逾時、部分成功及多人同時修改。

每個例外都要說明觸發條件、使用者看到什麼、是否阻擋、能採取什麼動作、誰人工介入及留下哪些紀錄。AI 可以列出應檢查的情境，但不能替業務方決定處理政策。

用 Given／When／Then 建立共同語言

Given 描述前置狀態，When 描述動作或事件，Then 描述可觀察結果。

「系統要正確處理未完成標籤」無法驗收；「同批次尚有兩張未列印時，批次維持待印狀態並顯示未列印數量」就能讓業務、開發與測試對同一結果確認。

每條驗收標準都要能追溯

驗收標準應連回需求、業務規則及原始來源。這能回答三個重要問題：為什麼要測這件事？誰提出這條規則？規則變更時會影響哪些測試？

沒有追溯關係，需求文件很容易成為一份看起來完整、實際無法維護的孤島。

需求基準是合作界線，不是用來抓戰犯

開發前建立版本、範圍、未決事項、核准與驗收角色。之後若規則改變，評估畫面、資料、流程、測試、時程與成本影響。

這不是為了證明誰改口，而是讓團隊知道新的想法需要多少代價，以及應由誰做取捨。

AI 找缺口，人確認規則

AI 最適合處理大量文字、交叉比對矛盾、列出例外、改寫驗收情境及建立追溯表。業務規則、權限、容許誤差、法規與正式驗收仍必須由有權責的人確認。

一份真正好用的需求文件，不是最厚的那份，而是讓不同角色都能回答：我們要交付什麼、怎樣算完成、還有哪些事情沒有決定。

逐步操作

第一步：保留原始需求，不急著改寫

先將 Email、會議紀錄或口頭交辦逐句整理，保留來源、日期及說話角色。

原文是未來確認歧義的重要依據。AI 改寫後的漂亮文字不能取代原始說法。

第二步：先問「要改善什麼結果」

把功能需求背後的工作結果說清楚，例如：

模糊：增加批次處理功能。
清楚：操作人員可一次選取同批次的多筆原料，減少逐筆輸入，並在送出前確認總重量一致。

目的可以幫助團隊判斷某個功能到底必要，還是只是其中一種做法。

第三步：寫出使用角色與使用情境

不要只寫「使用者」。區分：

現場操作人員
班長或覆核人員
系統管理者
維護或客服角色
外部系統

再補上使用時機、設備、工作環境與前置條件。

第四步：畫出範圍邊界

建立三欄：

本次包含
本次不包含
尚待決定

「不包含」不是推卸，而是避免後續把未討論事項當成承諾。

第五步：建立名詞與資料字典

例如「完成」可能代表列印完成、資料已送出、主管已覆核或 ERP 已回寫。每個關鍵名詞都要寫成可被不同部門共同理解的定義。

資料欄位至少記錄：名稱、意義、來源、格式、是否必填、範例、缺漏時處理方式。

第六步：整理業務規則

一條規則只說一件事，並附來源與確認人。例如：

同一批次標籤尚未全部列印時，狀態維持「待印標籤」。

如果原始資料只說「應該維持待印」，要標示為待確認，不能自動升級為正式規則。

第七步：寫正常流程

使用最簡單的順序：

使用者看到什麼？
使用者做什麼？
系統檢查什麼？
系統回傳什麼？
資料記錄在哪裡？

先完成一條最常發生的主流程，再處理例外。

第八步：補齊例外與邊界案例

至少檢查：

必填資料缺漏
資料格式錯誤
重複送出
超過數量或容量上限
權限不足
外部系統無回應
操作中斷後重新進入
多人同時修改
部分成功、部分失敗
已完成後又要求修改

第九步：把「系統要提醒」寫成可執行規則

每個提醒都要回答：

什麼條件觸發？
顯示給誰？
在哪裡顯示？
是否阻擋後續操作？
使用者可以採取什麼動作？
是否留下紀錄？

第十步：使用 Given／When／Then 寫驗收標準

這是一種不需要會寫程式的情境寫法：

Given：前置狀態
When：使用者動作或事件
Then：可觀察結果

例如：

Given 同一批次共有 12 張標籤且已列印 10 張；When 操作人員返回批次清單；Then 該批次狀態仍顯示「待印標籤」，並顯示尚有 2 張未列印。

第十一步：為每條驗收標準準備測試資料

不要只寫測試步驟。還要準備：

輸入資料
使用角色與權限
前置狀態
預期結果
完成證據
測試負責人

第十二步：分開需求、建議與待確認

建議狀態：

已確認需求
設計建議
技術建議
假設
待決定
已排除
延後處理

AI 可以提出建議，但必須清楚標示，不能混入已確認需求。

第十三步：做一次角色走查

讓 AI 分別扮演：

第一次使用的現場人員
負責驗收的業務代表
開發人員
測試人員
維運人員
資安或權限管理者

請它只找矛盾、遺漏與不可驗收處，不替角色做決定。

第十四步：建立需求基準版本

在開始開發前記錄：

版本號與日期
已確認範圍
未決事項
核准角色
關聯原始來源
驗收負責人

這是後續判斷「原需求」與「新增需求」的基準。

第十五步：需求變更要說明影響

新增或修改需求時，記錄：

變更內容與原因
原規則與新規則
影響畫面、資料、流程、測試及文件
時程與成本影響
是否接受、延後或拒絕
核准人及生效版本

可直接複製的完整提示詞

你是一位資深商業分析師、產品經理、專案經理與軟體驗收顧問，擅長把口語交辦、Email、會議紀錄及畫面構想，整理成非技術人員也能確認、開發與驗收的需求包。

【任務】
請根據我提供的原始資料：
1. 保留原始需求與來源。
2. 找出模糊詞、矛盾、缺漏、隱含假設與未決事項。
3. 整理業務目的、角色、範圍、資料、規則、流程、例外與權限。
4. 產生可觀察、可測試的 Given／When／Then 驗收標準。
5. 建立測試資料需求、需求追溯表與變更基準。

你的工作是協助澄清，不是替需求提出者決定規則。不得把範例、建議、推測或技術做法自行改寫成正式需求。

【專案基本資料】
專案名稱：[填寫]
本次功能／流程名稱：[填寫]
業務提出角色：[填寫]
最終確認角色：[填寫]
驗收角色：[填寫]
預計使用者：[填寫]
目標上線／交付日期：[YYYY-MM-DD／未定]
目前版本：[填寫]
相關系統：[填寫]
敏感資訊限制：[填寫]

【原始資料】
使用格式：
來源編號｜日期｜來源類型｜發言角色｜原始內容｜附件或畫面編號
[貼上匿名化的會議紀錄、Email、聊天訊息、流程或需求草稿]

【已知業務目的】
目前問題：[填寫]
希望改善的工作結果：[填寫]
不做的影響：[填寫]
成功指標：[填寫；沒有則填未定]

【已知範圍】
本次包含：[填寫]
本次不包含：[填寫]
尚待決定：[填寫]

【已知角色與權限】
角色｜可查看｜可新增｜可修改｜可刪除／作廢｜可覆核｜其他限制
[貼上資料；沒有則填無]

【已知資料】
欄位｜定義｜來源｜格式｜是否必填｜範例｜缺漏時處理
[貼上資料；沒有則填無]

【已知業務規則】
規則編號｜內容｜來源｜是否已確認｜確認人
[貼上資料；沒有則填無]

【已知流程】
步驟｜角色｜輸入｜動作｜系統反應｜輸出／狀態
[貼上資料；沒有則填無]

【整理限制】
1. 保留原始內容、來源編號、日期與角色，改寫內容不得取代原文。
2. 將內容分類為：已確認需求、設計建議、技術建議、範例、假設、待決定、已排除或延後。
3. 「簡單、快速、彈性、智慧、方便、即時、正常」等詞必須指出不可驗收之處。
4. 不得自行發明業務規則、欄位、權限、狀態、數量上限、期限或錯誤處理方式。
5. 「例如」後面的內容預設為範例，不得直接視為完整規則或限制。
6. 「希望、建議、可以考慮、應該」不得直接標示為已確認需求。
7. 同一名詞有不同含義時，列出差異並要求指定正式定義。
8. 同一需求在不同來源矛盾時，保留全部說法，列出需由誰決定。
9. 將業務目的與解法分開；若原文直接指定畫面或技術，說明它想解決的工作結果。
10. 本次範圍、明確不包含、尚待決定必須分欄。
11. 每項功能至少辨識使用角色、觸發條件、前置狀態、輸入、處理、輸出及完成狀態。
12. 每個資料欄位至少包含定義、來源、格式、必填與缺漏處理；未知者標示待確認。
13. 每個狀態需定義進入條件、可執行動作、離開條件與最終狀態。
14. 每個通知或警示需說明觸發條件、對象、管道、是否阻擋及後續動作。
15. 至少檢查缺漏、格式錯誤、重複、超限、權限不足、逾時、系統中斷、多人同時操作、部分成功及撤回修改。
16. 不得將未定的異常處理方案自行補成正式流程。
17. 驗收標準使用 Given／When／Then，且結果必須可以被畫面、資料、紀錄或通知觀察。
18. 一條驗收標準只驗證一個主要行為；複合情境請拆開。
19. 不得使用「系統應正確處理」「畫面應友善」等不可觀察結果。
20. 每條驗收標準需連結需求編號、規則編號及原始來源。
21. 測試資料不得使用真實個資、客戶機密、帳密、API金鑰或正式生產資料。
22. 涉及法規、資安、個資、財務、品質或合約時，標示需由權責角色確認。
23. 新增建議必須放在獨立區塊，不能混入正式需求。
24. 若資料不足，提出最多10個高價值確認問題，依「不回答就無法開發或驗收」的程度排序。
25. 使用繁體中文，語氣中立、清楚、具體。

【輸出格式】

一、主管摘要
在150字內說明業務目的、範圍、目前完整度、前三個重大缺口與需要決定的事項。

二、原始需求分類
| 來源 | 原始語句 | 類型 | 可否直接成為需求 | 原因 | 待確認人 |

三、業務目的與成功結果
| 現況問題 | 目標使用者 | 希望改善的結果 | 成功指標 | 證據／來源 |
沒有成功指標時標示待定，不得自行設定數字。

四、範圍邊界
| 本次包含 | 本次不包含 | 尚待決定 | 來源 |

五、名詞與狀態字典
| 名詞／狀態 | 建議定義 | 進入條件 | 離開條件 | 需誰確認 |

六、角色與權限矩陣
| 角色 | 查看 | 新增 | 修改 | 作廢／刪除 | 覆核 | 待確認 |

七、資料字典
| 欄位 | 定義 | 來源 | 格式 | 必填 | 範例 | 缺漏／錯誤處理 |

八、業務規則表
| 規則編號 | 規則內容 | 適用條件 | 例外 | 來源 | 確認狀態 |

九、正常流程
| 步驟 | 角色 | 前置狀態 | 動作 | 系統反應 | 輸出／新狀態 |

十、例外與邊界案例
| 情境 | 觸發條件 | 預期處理 | 是否阻擋 | 人工介入 | 確認狀態 |

十一、需求清單
| 需求編號 | 使用者故事 | 業務價值 | 優先序 | 關聯規則 | 來源 | 狀態 |
使用者故事格式：作為[角色]，我希望[能力]，以便[工作結果]。

十二、驗收標準
| 驗收編號 | 關聯需求 | Given | When | Then | 完成證據 |

十三、測試資料與環境
| 驗收編號 | 測試角色 | 前置資料 | 輸入 | 預期結果 | 所需環境 | 是否可匿名化 |

十四、需求追溯表
| 原始來源 | 業務規則 | 需求編號 | 驗收編號 | 測試案例 | 覆蓋狀態 |

十五、矛盾、假設與待決事項
| 編號 | 類型 | 內容 | 不確認的影響 | 建議確認角色 | 期限 |
沒有期限資料時填未定，不得自行指定。

十六、高價值確認問題
依阻礙程度排序，最多10題；每題說明為何必須回答，以及答案會影響哪些需求。

十七、設計與改善建議
所有AI新增內容放在此區，標示為建議，不得寫成已核准需求。

十八、需求基準與變更紀錄草案
列出版本、日期、納入範圍、未決事項、核准角色、驗收角色，以及未來變更需評估的影響面。

十九、人工確認清單
列出交付開發、排程、估價、驗收與上線前需人工確認的事項。

實際教學範例

原始需求

標籤畫面要支援同原料多選，最多可以顯示 50 筆。系統依批次用量自動分配重量，也要讓人員可以調整。如果標籤沒有印完，畫面要維持待印狀態。

AI 不應直接假設的內容

「50 筆」是畫面顯示上限、單次勾選上限，還是系統處理上限？
自動分配採平均、比例或其他規則？
人工調整後，總量是否必須維持一致？允許的誤差是多少？
誰有權限調整？調整是否需要原因與覆核？
「沒有印完」如何判定？列印工作送出、印表機回報或人工確認？
重印、作廢、印表機斷線及部分列印如何處理？

整理後的需求草案

業務目的： 現場人員能以同一畫面處理同批次多筆原料標籤，減少逐筆操作，並確保分配後總重量可被核對。

本次包含： 多選、重量自動分配、人工調整、總量檢核、列印狀態顯示。

尚待決定： 50 筆的正式定義、分配規則、允許誤差、調整權限、列印完成判定方式。

可直接確認的驗收標準

AC-001：部分標籤尚未列印

Given：批次 B001 共有 12 張有效標籤，其中 10 張已有可追溯的列印完成紀錄。
When：具查看權限的操作人員開啟批次清單。
Then：B001 顯示「待印標籤」，並顯示尚有 2 張未列印。

AC-002：所有標籤完成列印

Given：批次 B001 的 12 張有效標籤皆已有可追溯的列印完成紀錄。
When：系統重新計算批次狀態。
Then：B001 不再顯示「待印標籤」，並進入由業務方確認的下一狀態。

注意：下一狀態原始資料未提供，因此不能自行填成「完成」。

AC-003：人工調整造成總量不一致

Given：使用者已完成自動分配，且具有人工調整權限。
When：調整任一筆重量後，分配總量不等於批次需求總量。
Then：系統顯示差異值，並依已確認規則阻擋或允許下一步。

注意：是否阻擋及允許誤差尚未決定，這條驗收標準仍不能正式簽核。

高價值確認問題

50 筆限制作用在哪個層級？超過時要分頁、禁止勾選或改用其他方式？
重量自動分配的正式公式與小數位規則是什麼？
人工調整後總量不一致時，是否允許儲存或列印？
哪些角色可以調整重量、重印及作廢？
系統依什麼證據判斷一張標籤已列印完成？
部分列印失敗時，要保留成功紀錄還是整批重來？

這些問題比「按鈕要放左邊還是右邊」更早決定，因為它們會直接影響資料、流程、權限與驗收。

常見錯誤、隱私與使用注意事項

把需求寫漂亮就當成清楚： 語句通順不代表規則完整。 - 把解法當成目的：「增加按鈕」沒有說明要改善什麼工作結果。 - 把範例當成全部規則： 一個例子無法涵蓋上下限與例外。 - 只寫正常流程： 上線後多數爭議來自異常處理。 - 使用模糊形容詞： 快速、友善、正確都需要可觀察定義。 - 一條驗收標準塞太多行為： 失敗時無法判斷問題在哪裡。 - Then 寫成「正確處理」： 必須描述畫面、資料、狀態或通知的具體結果。 - 遺漏權限： 能看到不代表能修改；能修改不代表能作廢。 - 未定事項藏在正文： 應集中列出，指定確認角色。 - AI 建議混入正式需求： 所有新增想法都應標示為建議。 - 開發完成就算驗收： 驗收需要指定角色、情境、資料及證據。 - 需求變更覆蓋原版： 應保留原規則、變更原因與核准紀錄。 - 直接貼正式資料： 客戶名稱、員工資料、批號、配方、價格及帳號應匿名化。 - 貼入系統憑證： 不要輸入帳密、API 金鑰、連線字串、內網位址及弱點資訊。 - 用生產資料測試： 優先使用合成或去識別化資料，並遵守公司政策。 - 讓 AI 判定法規或資安合格： 必須由法務、資安及資料權責人正式確認。