轉念學 – 敏捷三叔公的學習之旅

如何寫出人人有共識的需求 – 範例描述需求篇

2025 年線下課程 第三梯次 開課時間: 12 月 20 日 (台中) (星期六) (09:00-16:00) 報名網址: https://forms.gle/GcZmQNd1eN68YuFK8 2026 年線下課程 第二梯次 開課時間: 3 月 22 日 (台北)(星期日) (09:00-16:00) 報名網址: https://forms.gle/eqe2ytr2rCdDVbRm8

以協作方式, 和具體描述範例的方式, 讓大家對需求有共識

課程特色

手把手實際練習

利用真實案例來練習    每種範例開立方式都會嘗試    小組分享交流不同做法

回答常見問題

實例化需求的範例和測試個案有什麼不同 範例要寫多少才夠 實例化需求的重點是什麼? 自動化嗎 好的需求範例有什麼要素 如何可以系統性開立出完整的範例 用哪種格式來描述範例比較好? Given When Then 嗎? 誰需要來參加實例化需求的討論？

課程簡介

在軟體專案中，成功的關鍵往往取決於需求管理。根據《Standish Report 2014》，專案成功的五大因素中，「用戶參與」排在第一位，而「需求清晰表述」位居第三。相對地，失敗專案中最常見的問題是「需求不完整」，其次是「缺乏用戶參與」。因此，如何與用戶共同整理出有共識的需求，無疑是軟體專案成功的第一步。

傳統的需求處理流程通常始於客戶訪談，然後根據會議中的討論整理需求規格與說明。然而，無論需求文檔寫得多麼詳細，開發人員和客戶之間仍經常會存在誤解。開發人員可能以為自己理解了客戶或PM的需求，但客戶或PO則可能錯誤地認為開發人員已經完全理解。這種誤解往往反覆發生，導致專案進度和品質受損。

此外，傳統需求管理方法中的文檔撰寫通常需要較長時間，這期間需求有可能會發生變動，而在需求變動後，發現原本的需求文件無法反映最新的需求，進而造成系統與真實需求不符。

為了解決這些問題，Gojko Adzic 提出了透過測試範例來清晰表達需求的做法。這種方法不僅能避免抽象描述所帶來的誤解，還能確保開發團隊和客戶基於具體範例進行有效的需求溝通。在系統開發完成後，這些範例還能用來驗證系統是否按照原始需求進行實現，因為它們包含具體的數據和條件，避免了模糊空間。

本課程將介紹這一高效且具體的方法，讓您學會如何利用實際範例來闡述需求，並在過程中識別潛在問題。我們會實際運用不同功能來練習列出範例，確保您學會的技能可以直接應用於實際專案中。

本課程不僅讓您深入理解如何以具體範例來解釋需求，還會教您如何利用AI工具輔助需求分析和測試驗收，讓您在專案中快速實踐並達成卓越的需求管理效果。

適合對象

• 軟體開發人員, 測試人員
• 專案經理, 系統分析師
• 需要處理軟體系統需求的人
• 對於需求不清楚感到痛苦的人

課程大綱

爲什麼要用範例來說明需求	a. 需求文件常見的問題 b. 用範例描述需求的想法 演練: 需求模擬遊戲 討論: 要如何進行討論可以讓需求比較容易懂
描述範例的方法	a. 範例可以幫忙什麼 b. 驗收條件 c. 驗收測試 d. 驗收條件和做完定義的比較 討論: 如果要用範例來描述需求, 大家需要做什麼
如何協作討論出範例	a. 可以有哪些角色來協作討論需求 b. Example Mapping 演練: 利用 Example mapping 撰寫範例 討論: 要做什麼可以讓example mapping 更有效果
系統化開立範例的方法	a. 三種驗收條件的格式 b. 四種開立範例的方法 討論: 不同格式的優缺點
實例化需求的歷史和流程	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. 上課會介紹自動化工具或寫程式嗎? 不需要, 本課程不會介紹自動化工具, 也不會有任何撰寫程式的部分, 是要讓大家對於這個流程有認識並且知道怎麼實施

課程花絮