如何寫出人人有共識的需求 – AI 協作實例化需求
| 2026 年線下課程 第二梯次 開課時間: 5 月 10 日 (台中)(星期日) (09:00-16:00) 報名網址: https://forms.gle/Qvbk1EgouDQQbvFJ6 |
以協作方式, 和具體描述範例的方式, 讓大家對需求有共識
課程特色
| 手把手實際練習 |
| 利用真實案例來練習 每種範例開立方式都會嘗試 小組分享交流不同做法 |
| 回答常見問題 |
| 實例化需求的範例和測試個案有什麼不同 範例要寫多少才夠 實例化需求的重點是什麼? 自動化嗎 好的需求範例有什麼要素 如何可以系統性開立出完整的範例 用哪種格式來描述範例比較好? Given When Then 嗎? 誰需要來參加實例化需求的討論？ |
課程簡介
A. 軟體失敗的真相：消失在模糊的需求中
根據軟體工程界最具權威的 Standish Group “CHAOS Report” 長期調查顯示，軟體專案成功的比例往往不到 35%。而在導致專案失敗、預算超支或時程延宕的眾多因素中，「需求不完整」與「模糊的需求描述」始終蟬聯前兩名。
- 50% 的功能乏人問津：由於一開始對需求理解錯誤，開發團隊花費大量精力製作的功能，最終有近一半很少或從未被使用者開啟。
- 修正成本的巨大槓桿：根據 IBM 軟體工程學院的研究，在「維運階段」修正一個需求邏輯錯誤的成本，是在「設計/需求階段」發現並修正的 100 倍。
B. SBE 是如何解決這些痛點的？
本課程的核心建立在 Gojko Adzic 的獲獎著作 《實例化需求》(Specification by Example, SBE) 所奠定的理論基石上。SBE 不僅是一套撰寫需求的技巧，更是一套「確保交付正確產品」的商業戰略。
Gojko Adzic 指出，傳統需求文件的最大危機在於「知識的流失」與「錯誤的假設」。SBE 透過協作性發現 (Collaborative Discovery)，讓開發、測試與業務三方（三劍客）在編寫程式碼之前，先達成「單一事實來源」(Single Source of Truth) 的共識，徹底解決溝通中的資訊不對稱。
C. 在 GenAI 時代SBE 比以往任何時候都重要
在生成式 AI 蓬勃發展的今天，開發門檻降低了，但「失敗的風險」卻反而增加。
- 垃圾進，垃圾出 (GIGO)
AI 的生成速度極快，但如果輸入（Prompt）的需求描述模糊不清，AI 只會以更快的速度產出無效的程式碼。SBE 提供的「結構化範例」是目前與 AI 溝通最完美的提示詞架構 (Prompt Framework)，確保 AI 生成的結果符合業務邏輯。
- 從「撰寫者」轉型為「審核者」
當 AI 承擔了大部分的編碼工作，軟體人員的價值將轉向精確定義規格與邊界測試分析。本課程教導如何運用 SBE 的測試思維（如 ECT 等價類別、BVT 邊界值）來挑戰 AI 的產出，確保產品在各種極端情境下依然穩健。
- AI 無法取代的「共識凝聚」
AI 可以幫你寫 Code，但 AI 無法幫你的利害關係人達成共識。本課程強調的 Example Mapping 與引導技巧，是人類在 AI 時代的核心溢價——透過面對面的溝通，化解各方衝突，凝聚團隊對產品價值的理解。
D. 課程收穫
- 內建品質，預防勝於治療
引用品質大師戴明 (W. Edwards Deming) 的思想：「停止依賴檢驗來達成品質，而是將品質內建於流程中。」本課程教你如何在需求階段利用 Story、Rule、Example、Question 四色卡片，在開發前就排除 80% 的邏輯錯誤，大幅降低 Rework 成本。
- AI 協作的高級提示詞工程
課程將實戰示範如何利用 SBE 產出的範例表格 (Table) 與 Given-When-Then 格式，搭配 Chain-of-Thought (CoT) 與 Few-Shot Prompting 技術，讓 AI 成為您最精準的開發副駕駛。
- 科學化的測試思維應用
我們不憑感覺寫範例。課程涵蓋了專業的測試設計方法：
(1) ECT (等價類別分割)：用最少的範例覆蓋最多的場景。
(2) BVT (邊界值測試)：精準捕捉程式最容易出錯的臨界點。
(3) DTT (決策表測試)：理清複雜商業邏輯的利器。
- 適用於多樣化的開發框架
無論您的團隊是採用 Scrum、Kanban 還是 大規模 Scrum (LeSS)，甚至是在傳統的瀑布流中尋求改進，實例化需求都能無縫嵌入您的開發生命週期，成為跨團隊溝通的共同語言。
適合對象
- 軟體開發人員, 測試人員
- 專案經理, 系統分析師
- 需要處理軟體系統需求的人
- 對於需求不清楚感到痛苦的人
課程大綱
| 爲什麼要用範例來說明需求 | a. 需求文件常見的問題 b. 用範例描述需求的想法 演練: 需求模擬遊戲 討論: 要如何進行討論可以讓需求比較容易懂 |
| 描述範例的方法 | a. 範例可以幫忙什麼 b. 驗收條件 c. 驗收測試 d. 驗收條件和做完定義的比較 討論: 如果要用範例來描述需求, 大家需要做什麼 |
| 如何整合至目前開發流程 | a. 瀑布式開發流程 b. Scrum 開發流程 c. 大規模敏捷開發流程 |
| 如何協作討論出範例 | a. 可以有哪些角色來協作討論需求 b. Example Mapping 演練: 利用 Example mapping 撰寫範例 討論: 要做什麼可以讓example mapping 更有效果 |
| 好的範例的特性 | a. BRIEF 原則 b. 分析現成範例來學習何謂好的範例 |
| 如何使用 AI 系統化開立範例的方法 | a. 驗收條件的格式 Gherkin/Table/Rule based 討論: 不同格式的優缺點 b. 開立範例的方法 – 普通範本提示 角色扮演 + 規則 少樣本提示（Few-Shot Prompting） 思維鏈提示（Chain-of-Thought Prompting） 思維樹提示（Tree of Thoughts Prompting） c. 開立範例的方法 – 測試設計提示 Use Case Testing Equivalence Class Testing Boundary Value Testing Decision Table Testing |
| 實例化需求的歷史和流程 | a. 實例化需求的來源 b. 實例化需求的流程 c. 要寫多少才足夠 d. 如何評量做得好不好 |
| 刻意練習 | a. 演練: 用use case testing 開立PCHome 7-11 取貨功能 b. 演練: 用 Equivalence Class Test 開立高鐵售票功能 c. 演練: 用 decision table test 開立高鐵早鳥票功能 d. 演練: 使用GenAI 建立User Story, 驗收條件 |
常見問題
| Q1. 不會程式開發是否可以上此門課? 不用會寫程式也能聽得懂. 只要簡易知道軟體開發流程即可 |
| Q2. 開發人員也適合這堂課嗎? 合適, 不管你有沒有專職測試人員幫你測試, 或者不管是手動測試或是自動測試, 你總是需要開立測試個案, 來驗證自己的程式. 這時候你就需要此方面的技能. |
| Q3. 需要懂敏捷開發嗎? 不需要, 課程中只有一小部分會提到, 提到到的部分當場也可以聽得懂 |
| Q4. 上課會介紹自動化工具或寫程式嗎? 不需要, 本課程不會介紹自動化工具, 也不會有任何撰寫程式的部分, 是要讓大家對於這個流程有認識並且知道怎麼實施 |
課程花絮
