上一篇文章，我們聊了如何用三段句子來撰寫User Story，像是寫小說一樣，讓需求變得清楚明白。那麼接下來的挑戰是什麼呢？就是我們的驗收條件（Acceptance Criteria，簡稱AC）。驗收條件就像是故事中的「結局」，不僅要好看，還要讓人覺得合理，AC的任務就是這麼簡單明確：讓需求「成功被驗收」，證明這個功能確實解決了使用者的問題。

驗收條件(Acceptance Criteria)

用來定義一個User Stroy完成後應該具有的標準與條件，確保需求的實現符合使用者的期望。

如何撰寫好的驗收條件

1. 簡單明瞭：條件應該用簡單的語言描述，避免模糊或技術性太強的詞彙。
2. 具體可測：每個條件應該是具體且可以測試的，不應有主觀判斷或模糊的要求。
3. 保持功能導向：驗收條件應該聚焦於功能需求，而非技術細節，這樣可以讓非技術人員也能理解並參與討論。

假設我們有一個 User Story：「身為一位 HR 人員，我想要查詢職務主檔，這樣我能找到特定職位的詳細資訊。」

1. 使用者可以輸入關鍵字進行搜尋
2. HR人員可以查看職務列表
3. 有權限的人員才可以查詢職務列表

你覺得這個AC有甚麼問題嗎?

這個驗收條件（Acceptance Criteria, AC）表面上看起來是合理的，但存在一些潛在的問題或改進空間，特別是在具體性和可測試性方面：
1. AC 不夠具體： 每個條件都描述了功能的基本目的，但沒有足夠的細節來清楚定義「如何」或「什麼」標準被認為是驗收通過。例如：
- 「使用者可以輸入關鍵字進行搜尋」 沒有說明可以搜尋什麼樣的關鍵字（職務名稱、代號、部門等），也沒有定義結果應該如何呈現（完整匹配還是部分匹配？有沒有分頁？）。
- 「HR 人員可以查看職務列表」 沒有說明列表中會顯示哪些欄位、是否有分頁，或如何排序職務。
2. 缺乏成功標準： 驗收條件應該定義出具體的成功標準，這樣開發人員和測試人員都能明確知道什麼是「成功」的表現。這些條件目前只簡單描述了功能，卻沒有說明具體的驗收標準。例如：
- 搜尋結果應在幾秒內返回？
- 如果搜尋沒有結果，系統應該如何回應？（例如，顯示「無符合條件的結果」）
3. 缺乏可測試性： 每個 AC 應該可以被明確測試，無論是透過自動化測試還是手動測試。以「有權限的人員才可以查詢職務列表」為例，這條 AC 缺乏對於沒有權限的人的具體行為描述。具體的行為應包括：
- 沒有權限的使用者會看到什麼？是否有錯誤訊息？
- 該權限如何定義？例如，HR 部門人員自動擁有權限嗎？
4. 過於簡化： 這些條件的描述過於簡化，沒有考慮不同的使用情境。例如：
- 如果用戶輸入無效的關鍵字，會發生什麼？
- 列表中的資料會不會有篩選或排序功能？
- 如果資料過多（比如超過 1000 筆），應該如何處理？會不會有分頁？

針對上述的問題，進行調整這個AC，對應的驗收條件可以是：

1. 使用者能夠透過輸入{職務名稱}或{職務代號}做為關鍵字進行搜尋，且搜尋結果顯示與管見自完全符合的職務列表
   a. 系統在1秒內返回查詢結果。
   b. 若查無符合搜尋條件的職務時，系統會提醒使用者「未找到符合條件的職務」。
2. 職務列表資訊如下：
   a. 列表欄位：職務名稱、職務代號、狀態
   b. 列表最多顯示20筆資料，超過則顯示分頁
3. 點按任一筆{職務}資料列，顯示該職務的詳細資訊，包括：職務名稱、職務代號、職務描述、該職務負責部門、該職務的主管名稱。
4. 只有擁有「HR管理員」的權限，才可以查詢職務主檔；若無權限者，系統會提醒使用者「您沒有權限查看此資訊」。

這些驗收條件確保 HR 人員能夠有效地使用系統查詢並獲取職務主檔的詳細資訊，同時確保系統操作的便捷性和權限控制。

看到這裡，你應該已經對如何撰寫AC有了一點感覺吧？簡單清晰的AC就像是一個讓人無法拒絕的完美結局——沒有人喜歡被搞得一頭霧水，尤其在驗收時。如果我們能像寫出一個乾淨俐落的故事結尾一樣，把AC寫得明確、易懂，那不僅使用者開心，開發團隊也能少掉不少頭痛的時刻。畢竟，沒有人想在最後一秒發現「故事沒講清楚」而被打回重寫。

所以，記住：寫AC，就像寫故事的結局一樣**，簡單明瞭**才是王道，越精準，大家的心情越好！