接受/驗收條件

2022/03/23 (新增投影片)
2022/05/08 (微調內容)
2024/02/25 (更動內容)
2024/03/20 (English references are added)
2025/03/01 (更動內容)
2025/03/10 (更新投影片)

接受/驗收條件

一般而言，接受條件就是說明要如何滿足這個使用者故事，也可以進一步將接受條件當作測試案例(Test Case)，讓開發者與驗收者可以根據接受條件驗收系統，也可以讓接受條件成為自動測試的測試案例(Test Case)，請詳參: 接受條件 (吳濟聰老師敏捷軟體開發課程教材)。

• What Are Acceptance Criteria: Explanation and Examples

接受條件有不同的寫法，一般是採取情境取向的寫法，也就是利用Given、When、Then來寫。Given是指前提條件，When是所採取的動作，Then則是可驗證的結果。當user story裡有不同情況時，就會有不同的情境(Scenario)。在User Activity、User Task層級，主要描述的是User Activity下的User Task之間的邏輯關係，主要描述的是User Task下的User Story之間的邏輯關係。以系統分析與設計所開發的系統，規模都不大，不需要區分成User Activity、User Task、User Story三個階層，可以簡化為Epic及User Story即可。

Epic

當規模不大時，會利用接受條件來說明Epic下的相關user story，接受條件可以採用列點式表示。

1 訂購

角色: 身為 購買者

需求: 我想要可以 線上購買產品

價值: 因此我可以 解決不能去實體店面的問題

接受條件:

• 購買者可以依類別(1.1)、關鍵字尋找產品(1.2)也可以看推薦產品(1.3)

• 接下來購買者可以點選產品看詳細資料(1.4)並可將想購買之產品加入購物車

• 購買者可以管理購物車(1.5)

• 要下訂單時，如果使用者還沒登入，會要求登入(1.7)

• 登入時，如果使用者還沒註冊，可以進行註冊(1.6)

• 成功登入後，可以將購物車內的產品產生訂單(1.8)

• 消費者在匯款前可以取消訂單 (1.9)

User Story

在user story的層次，在Given裡就是User Story的準備動作，如果準備動作是另一個User Story，就表示該User Story應該要先完成，才能進行這個User Story。在When裡面通常是使用者所採取的動作，所以，要詳述使用者的輸入資料。在Then裡面就是確認user story是否完成的條件，通常會是使用者所得到的資訊，所以，要詳述使用者所應看到的輸出資料。

1.1 依類別尋找產品 

角色: 身為 購買者

需求: 我想要可以 依類別找到產品

價值: 因此我可以線上購買產品

接受條件:

Given 購買者知道產品所屬類別 

When購買者可以看到所有類別(書籍、音樂、影片、T恤帽袋、圖像、紀念品)，並選擇產品所屬類別

Then 購買者可以看到該類別中的產品(名稱、價格)，若超過十個產品每頁十個產品

User Activity

配合user story mapping的三層級的user story，在user activity層級，可以利用接受條件來說明user activity下的相關user task之間的邏輯關係，通常可採用列表方式，有時候會根據不同的情境進行列表。例如:

1 訂購

角色: 身為 購買者
需求: 我想要可以 線上購買產品
價值: 因此我可以 解決目前的購買方式不夠方便的問題

接受條件:
Scenario 1: 購買者不想註冊為會員

• 購買者可以尋找產品(1.1)

• 看產品資訊 (1.2)

• 將所需要的產品加入購物車 (1.3)

• 購買者可以線上下訂單 (1.6)

Scenario 2: 購買者還沒註冊為會員

• 購買者可以尋找產品(1.1)

• 看產品資訊 (1.2)

• 將所需要的產品加入購物車 (1.3)

• 註冊 (1.4)

• 購買者可以線上下訂單 (1.6)

Scenario 3: 購買者已經註冊為會員

• 購買者已經想好要訂購的產品

• 購買者可以尋找產品(1.1)

• 看產品資訊 (1.2)

• 將所需要的產品加入購物車 (1.3)

• 登入 (1.5)

• 購買者可以線上下訂單 (1.6)

User Task

在user task層級，可以利用接受條件來說明user task下的相關user story，通常可採用列表方式，有時候會根據不同的情境進行列表。例如:

1.1 尋找產品
角色:身為 購買者
需求:我想要可以找到產品
價值:因此我可以 找到我想要的產品以進行線上購買

接受條件:
使用者可利用以下三種方式尋找產品:

• 購買者利用類別尋找產品 (1.1.1)

• 購買者輸入關鍵字尋找產品 (1.1.2)

• 購買者瀏覽推薦商品尋找產品 (1.1.3)

1.2 看產品資訊

角色: 身為 購買者
需求: 我想要可以 看到產品資訊
價值: 因此我可以 確認找到我想要的產品以進行線上購買

接受條件:

• 購買者點選產品，看產品詳細資訊 (1.2.1)

• 購買者可以將產品放到我的最愛 (1.2.2)

User Story

在user story的層次，在Given裡就是User Story的準備動作，如果準備動作是另一個User Story，就表示該User Story應該要先完成，才能進行這個User Story。在When裡面通常是使用者所採取的動作，所以，要詳述使用者的輸入資料。在Then裡面就是確認user story是否完成的條件，通常會是使用者所得到的資訊，所以，要詳述使用者所應看到的輸出資料。

例如:

角色: 身為 購買者
需求: 我想要可以 依類別找到產品
價值: 因此我可以 找到我想要的產品以進行線上購買

接受條件:
Given 購買者知道產品所屬類別
When購買者可以看到所有類別(書籍、音樂、影片、T恤帽袋、圖像、紀念品)，並選擇產品所屬類別
Then 購買者可以看到該類別中的產品(名稱、價格)，若超過十個產品每頁十個產品

• 當user story裡有多個情境時，就需要標註情境，當採取的步驟多於一個時，也可以利用And來表示 (不會有OR，因為會把OR分割為不同情境)

角色:身為 老闆
需求:我想要可以 對已收款項之訂單出貨
價值:因此我可以 出貨，並且降低出貨錯誤率

接受條件:
Scenario 1:正常出貨
Given 老闆收到匯款並已登記已收到貨款 (2.2.1)
When 老闆會看到「已收到貨款但未出貨之訂單」，(包含:訂單時間、訂單編號、訂單狀態:未出貨或進貨中)，訂單依訂單時間排序
And 老闆點選最早下訂單的訂單
And 根據訂單準備好貨品，將訂單註記為「已出貨」
Then 該筆訂單不在「已收到貨款但未出貨之訂單」列表中出現

Scenario 2: 無法出貨
Given 老闆收到匯款並已登記已收到貨款 (2.1.2) 但缺貨
When 老闆會看到「已收到貨款但未出貨之訂單」(包含:訂單時間、訂單編號、訂單狀態:未出貨或進貨中)，訂單依訂單時間排序
And 老闆點選最早下訂單的訂單
And 老闆發現其中一個貨品缺貨，將訂單註記「進貨中 」
Then 該筆訂單仍會在「已收到貨款但未出貨之訂單」列表中出現，訂單狀態為「進貨中 」

常見的問題

• 在驗收條件中明列畫面規格 (如，「點選藍的『送出』按鈕)，在接受條件中，應該明列功能需求，而非畫面設計，畫面設計應該在畫面設計說明

• 需求不清楚，需求必須在接受條件中說明所需要的資料 (如:產品名稱、價格)

• 接受/驗收條件與需求不相符

• 驗收條件遺漏Given所需要的前置user story

• 沒有列出接受/驗收條件 (詳參: 撰寫使用者故事常見的問題 的第四項) 或太粗略

• 其他問題詳參: Documentation 

流程圖

如果不使用列表方式，也可以使用流程圖來表示。

參考資料

Acceptance Criteria with Gherkin

• What Are Acceptance Criteria: Explanation and Examples

• Writing User Stories With Gherkin

  • Gherkin follows a very specific syntax:

    • Scenario -> Given -> When -> Then

• Gherkins: A better way of writing user stories 

  • User stories focus on the user, not the product.

  • Outline your personas to add context.

  • Add empathy to your stories to understand actions and motivations.

  • Gherkins: a better way of writing stories.

  • Use gherkins to focus on outcomes, not just outputs.

Acceptance Criteria

• User Stories Acceptance Definition and Criteria in Agile Methodologies

  • Definition of Acceptance Criteria in Agile Methodologies for user stories

  • How to write acceptance criteria for a User Story in Agile?

  • Agile Acceptance Criteria Template

  • What Agile Acceptance Criteria Should Not Include

  • How to Write User Stories & acceptance Criteria

• What is User Story and Acceptance Criteria (Examples)

• Clear Acceptance Criteria and Why They’re Important

  • There are several types of acceptance criteria. The most popular are rules-oriented (in the form of a list) and scenario-oriented (in the form of scenarios that illustrate each criterion). The scenario-oriented type is popular among Agile teams since it helps with getting across requirements, envisaging various use cases, and further using scenarios for manual and automated acceptance tests.

• What Characteristics Make Good Agile Acceptance Criteria?

  • Functional Criteria

  • Non-functional Criteria

    • Performance Criteria

• How to Craft Strong Acceptance Criteria for a User Story : 5 simple practices that can yield extraordinary results

  • Who, When and How ?

  • Shared understanding and consensus

  • Clarity comes first

  • Make it testable, measurable and achievable

  • The format

    • Rule-oriented (checklist)

    • Scenario-oriented (Given/When/Then)

    • Custom formats

• Software Architecture Rule of Thumb — Requirements!

  • Use Testable Acceptance Criteria