自從團隊開始實施敏捷開發，我們就使用「User Story」撰寫需求規格，說實話，這麼多年下來，我們對於怎麼寫需求已經有了一套不錯的做法了（至少我們是這麼認為的），但我總是會有個疑問：我們真的寫對了嗎？是不是還有改進的空間？

於是，我們報名了敏捷三叔公的課程——【如何寫出人人有共識的需求-範例描述需求篇】，希望從課程中了解我們目前的寫法是否有在正確的路上，以及學習更多寫需求規格的方法。

接下來的內容，我將根據自身的實戰經驗以及課堂上所學，為大家整理出幾個重點；希望這些方法能像一個好的GPS導航一樣，幫助大家在撰寫需求時少走彎路、事半功倍！

撰寫 User Story 的目的，就像是在告訴一個好故事——你需要清楚傳達角色的需求 ，並讓開發團隊理解他們正在打造的功能究竟有什麼價值 。然而，每個人對文字的解讀，就像看電影一樣，有時候導演的意圖和觀眾的解讀大相徑庭；一句話，當你以為它簡單明了，實際上卻可能因為每個人不同的經驗與理解力，解讀出完全不一樣的意思。

這時候，「範例描述」 就像是給劇本加了分鏡表一樣——它能進一步將商業邏輯轉化成具體的場景，減少需求解讀上的偏差，且讓需求更易於理解，還讓開發團隊少了一些「這到底是什麼意思？」的頭疼時刻。

範例的描述格式

1. Given-When-Then
通常用於描述行為或功能如何在特定條件下運作 ，這種格式清楚定義了前置條件（Given）、當事件發生時（When）以及期望結果（Then）。

• 定義：
  Given：系統當前的狀態或前提條件。
  When：用戶執行的動作或觸發的事件。
  Then：系統預期的反應或結果。
• 範例：身為一位 HR 人員，我想要查詢職務主檔，這樣我能找到特定職位的詳細資訊。
  Given：HR 人員已經登入系統，並且處於職務查詢頁面。
  When：HR 人員輸入關鍵字「軟體工程師」並按下「搜尋」按鈕。
  Then：系統應該顯示包含「軟體工程師」職務的查詢結果列表。

這種格式讓團隊成員清楚知道在何種條件下應觸發什麼結果。

2. Table
適合當需求中有多組相似條件和結果 時使用，它能快速對比不同的輸入和輸出，幫助讀者快速掌握需求的變化。

• 定義：利用表格方式，列出多組輸入條件及其對應的期望結果，讓需求的不同情況清晰明瞭。
• 範例：身為一位 HR 人員，我想要查詢職務主檔，這樣我能找到特定職位的詳細資訊。

表格式的範例可以清楚呈現不同輸入情境下的期望結果，有助於開發與測試團隊快速參考。

3. Rule Base
適合用來描述更複雜的業務規則或條件下的需求 ，這種格式強調的是系統根據特定規則的行為，特別適用於有多種業務邏輯的情境。

• 定義：以規則的形式列出系統的行為模式，根據不同條件來描述系統應如何反應。
• 範例：身為一位 HR 人員，我想要查詢職務主檔，這樣我能找到特定職位的詳細資訊。
  規則 1：若使用者輸入的關鍵字符合現有職位名稱，則顯示相關的職務列表。
  規則 2：若使用者未輸入關鍵字，則顯示所有職務列表。
  規則 3：若使用者輸入的關鍵字不符合任何現有職位名稱，則顯示「查無此職務」提示。

這種格式有助於處理有多重邏輯或流程的需求 ，並將系統的反應具體規範下來。

分析優缺點

這三種範例描述格式各有優勢，當你在撰寫 User Story 時，可視故事的內容、性質、難易度靈活運用 1~2 種方式 ，不僅能讓需求更清晰，還能減少大家在理解上的誤會，讓開發與測試過程更加流暢。

參考資料：
敏捷三叔公課程 – 如何寫出人人有共識的需求
阿塔的故事歲月之寫過無數故事