User Story & Given-When-Then（GWT）使用说明

目录

• • [1. 概述](#1. 概述)
  • [2. User Story 用户故事](#2. User Story 用户故事)
  • • [2.1 标准模板](#2.1 标准模板)
    • [2.2 关键英文词汇说明](#2.2 关键英文词汇说明)
    • [2.3 使用场景](#2.3 使用场景)
    • [2.4 编写规则](#2.4 编写规则)
  • [3. GWT（Given / When / Then）场景描述](#3. GWT（Given / When / Then）场景描述)
  • • [3.1 标准模板（Gherkin语法）](#3.1 标准模板（Gherkin语法）)
    • [3.2 关键英文词汇说明](#3.2 关键英文词汇说明)
    • [3.3 使用场景](#3.3 使用场景)
    • [3.4 编写规则](#3.4 编写规则)
  • [4. User Story + GWT 组合使用说明](#4. User Story + GWT 组合使用说明)
  • • [4.1 组合逻辑](#4.1 组合逻辑)
    • [4.2 完整组合样例](#4.2 完整组合样例)
    • [4.3 组合使用步骤（适配4A业务架构BA）](#4.3 组合使用步骤（适配4A业务架构BA）)
    • [4.4 常见误区](#4.4 常见误区)
  • [5. 适用边界](#5. 适用边界)

适用场景：企业架构BA业务能力梳理、敏捷需求编写、业务场景定义、验收标准编写；可直接放入4A业务架构章节。

1. 概述

User Story（用户故事） ：用来表达业务需求，描述角色想要的能力与业务价值，回答「为什么要做、给谁做、要实现什么能力 」，属于需求摘要。

GWT（Given-When-Then） ：基于BDD行为驱动的场景描述方式，用来编写验收标准 Acceptance Criteria（AC） ，描述系统在特定条件下的行为，回答「在不同场景下，系统应该表现成什么样，如何验证」。

二者是配套关系：User Story 定义需求主体，GWT细化验收场景；一个用户故事可以对应多条GWT场景（正常场景、异常场景、边界场景）。

2. User Story 用户故事

2.1 标准模板

As a Role, I want Feature, so that Business Value.

中文直译：作为【Role角色】，我希望【Feature功能/能力】，以便【获得Business Value业务价值】。

2.2 关键英文词汇说明

英文术语	中文释义	说明
User Story	用户故事	需求条目载体
As a	作为	引出Role角色
Role	角色	使用系统的人/外部系统（业务岗位、系统）
I want	我希望	引出需要的Feature能力/功能
Feature	特性、功能	要提供的业务能力
so that	以便	引出Business Value业务价值；也可替换为 in order to
Business Value	业务价值	解决什么痛点，带来什么收益
Acceptance Criteria (AC)	验收标准	判断User Story是否完成的条件，常用GWT编写
Epic	史诗	大业务模块，拆解为多个Feature；Feature再拆User Story
INVEST	INVEST原则	User Story质量评判标准 Independent独立 / Negotiable可协商 / Valuable有价值 / Estimable可估算 / Small短小 / Testable可测试

2.3 使用场景

1. 业务架构BA：业务能力拆解，从业务能力项提炼User Story
2. 产品Backlog：敏捷待办条目，需求管理
3. 需求评审：业务、IT、测试对齐需求目标
4. 项目立项：快速描述业务诉求，不深入技术细节

2.4 编写规则

1. 站在业务用户视角，不要写技术实现；
2. 必须包含Role、Feature、Business Value三要素；
3. 粒度适中，遵循INVEST原则；
4. User Story本身不写详细校验规则，校验规则放在AC（GWT）。

✅ 示例：

As a purchaser, I want to create purchase requisition, so that I can initiate procurement approval.

作为采购人员，我希望创建采购申请单，以便发起采购审批。

❌ 反面示例（技术视角，不推荐）

As a developer, I want to build an API to save purchase data.

3. GWT（Given / When / Then）场景描述

3.1 标准模板（Gherkin语法）

Given [前置状态/预置条件]
And [附加前置条件]
When [用户/外部系统触发动作]
And [附加动作]
Then [可观测预期结果]
And [附加校验结果]

And：承接上一段关键字，同类型条件延续；But：用于描述例外结果（较少用）

3.2 关键英文词汇说明

英文术语	中文释义	说明
Given	给定	场景前置条件：系统初始状态、预置数据、身份环境
When	当	触发动作：用户操作、外部事件，一个场景只允许1个When
Then	那么	断言/预期结果：可观察、可验证的系统状态变化
And	并且	追加同类型Given/When/Then条件
But	但是	描述反向、例外结果（可选）
Scenario	场景	一套完整Given/When/Then为1个Scenario
Gherkin	Gherkin	自然语言脚本语法，支持Cucumber等BDD自动化工具
Behavior	行为	GWT描述系统Behavior行为，而非内部实现

3.3 使用场景

1. User Story的验收标准AC；
2. 业务架构BA业务场景梳理，固化业务规则；
3. 测试用例编写；
4. 跨角色对齐：业务、开发、测试对场景达成共识；
5. 可转BDD自动化脚本。

3.4 编写规则

1. Given：只写前置环境/数据，不要写结果；
2. When：只写外部触发动作，不要写断言；一个场景仅1个When；
3. Then：只写可观测、可验证结果，禁止写内部实现；
4. 场景独立：每个Scenario不依赖其他Scenario执行后的状态；
5. 业务语言优先，避免接口、数据库等技术细节。

✅ 示例（正常流程场景）

Scenario: 提交合法采购申请单
Given 采购人员已登录系统
When 采购人员填写采购信息并提交申请单
Then 系统生成采购申请单，状态为"待审批"
And 审批人收到待办通知

✅ 示例（异常场景）

Scenario: 提交不带物品名称的申请单
Given 采购人员已登录系统
When 采购人员未填写物品名称直接提交申请单
Then 系统返回错误提示 "物品名称不能为空"
And 申请单不保存

4. User Story + GWT 组合使用说明

4.1 组合逻辑

1. Epic（史诗） → Feature（特性） → User Story（用户故事） → 多条Scenario（GWT场景）
2. User Story 回答：我们要做什么能力，价值是什么；
3. GWT场景集合作为该User Story的验收标准AC，覆盖：正常流程、异常、边界场景。

4.2 完整组合样例

User Story

As a customer, I want to cancel unpaid orders, so that I can release inventory when I do not need goods.

作为客户，我希望取消未支付订单，以便不需要商品时释放库存。

Acceptance Criteria

Scenario1: 取消未支付订单

Given 当前客户存在一笔未支付订单，库存已锁定

When 客户取消该订单

Then 订单状态变更为"已取消"

And 锁定库存被释放

Scenario2: 取消已支付订单

Given 当前客户拥有一笔已支付订单

When 客户尝试直接取消订单

Then 系统提示 "已支付订单不可直接取消，请申请退款"

4.3 组合使用步骤（适配4A业务架构BA）

1. 梳理业务能力域，拆分Epic与Feature；
2. 基于业务能力，提炼User Story，明确Role、Feature、Business Value；
3. 需求精化（Refinement），头脑风暴识别全部业务场景；
4. 使用GWT编写每个Scenario，作为User Story的AC；
5. 架构/需求评审：业务、IT一起评审User Story和GWT场景；
6. 开发、测试基于GWT场景实现与验证；
7. 上线后，架构资产归档，更新业务场景模型。

4.4 常见误区

1. ❌ 只用User Story，不写AC/GWT：验收标准模糊，上线容易需求不一致；
2. ❌ 在User Story中写大量业务规则：User Story应当简短，规则下沉到GWT场景；
3. ❌ GWT中写技术细节（调用API、SQL）：GWT描述业务Behavior行为；
4. ❌ 一个Scenario多个When：多个动作应当拆分为多个Scenario；
5. ❌ GWT写Business Value：Business Value写在User Story，GWT只描述状态与结果。

5. 适用边界

1. 适合：业务能力梳理、业务流程场景、系统功能需求、验收标准；
2. 不太适合：底层技术改造、基础设施变更（TA技术架构）这类无业务Role角色的工作项。