目录1. 概述2. User Story 用户故事2.1 标准模板2.2 关键英文词汇说明2.3 使用场景2.4 编写规则3. GWTGiven / When / Then场景描述3.1 标准模板Gherkin语法3.2 关键英文词汇说明3.3 使用场景3.4 编写规则4. User Story GWT 组合使用说明4.1 组合逻辑4.2 完整组合样例4.3 组合使用步骤适配4A业务架构BA4.4 常见误区5. 适用边界适用场景企业架构BA业务能力梳理、敏捷需求编写、业务场景定义、验收标准编写可直接放入4A业务架构章节。1. 概述User Story用户故事用来表达业务需求描述角色想要的能力与业务价值回答「为什么要做、给谁做、要实现什么能力」属于需求摘要。GWTGiven-When-Then基于BDD行为驱动的场景描述方式用来编写验收标准 Acceptance CriteriaAC描述系统在特定条件下的行为回答「在不同场景下系统应该表现成什么样如何验证」。二者是配套关系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 toBusiness Value业务价值解决什么痛点带来什么收益Acceptance Criteria (AC)验收标准判断User Story是否完成的条件常用GWT编写Epic史诗大业务模块拆解为多个FeatureFeature再拆User StoryINVESTINVEST原则User Story质量评判标准Independent独立 / Negotiable可协商 / Valuable有价值 / Estimable可估算 / Small短小 / Testable可测试2.3 使用场景业务架构BA业务能力拆解从业务能力项提炼User Story产品Backlog敏捷待办条目需求管理需求评审业务、IT、测试对齐需求目标项目立项快速描述业务诉求不深入技术细节2.4 编写规则站在业务用户视角不要写技术实现必须包含Role、Feature、Business Value三要素粒度适中遵循INVEST原则User Story本身不写详细校验规则校验规则放在ACGWT。✅ 示例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. GWTGiven / When / Then场景描述3.1 标准模板Gherkin语法Given [前置状态/预置条件] And [附加前置条件] When [用户/外部系统触发动作] And [附加动作] Then [可观测预期结果] And [附加校验结果]And承接上一段关键字同类型条件延续But用于描述例外结果较少用3.2 关键英文词汇说明英文术语中文释义说明Given给定场景前置条件系统初始状态、预置数据、身份环境When当触发动作用户操作、外部事件一个场景只允许1个WhenThen那么断言/预期结果可观察、可验证的系统状态变化And并且追加同类型Given/When/Then条件But但是描述反向、例外结果可选Scenario场景一套完整Given/When/Then为1个ScenarioGherkinGherkin自然语言脚本语法支持Cucumber等BDD自动化工具Behavior行为GWT描述系统Behavior行为而非内部实现3.3 使用场景User Story的验收标准AC业务架构BA业务场景梳理固化业务规则测试用例编写跨角色对齐业务、开发、测试对场景达成共识可转BDD自动化脚本。3.4 编写规则Given只写前置环境/数据不要写结果When只写外部触发动作不要写断言一个场景仅1个WhenThen只写可观测、可验证结果禁止写内部实现场景独立每个Scenario不依赖其他Scenario执行后的状态业务语言优先避免接口、数据库等技术细节。✅ 示例正常流程场景Scenario: 提交合法采购申请单 Given 采购人员已登录系统 When 采购人员填写采购信息并提交申请单 Then 系统生成采购申请单状态为待审批 And 审批人收到待办通知✅ 示例异常场景Scenario: 提交不带物品名称的申请单 Given 采购人员已登录系统 When 采购人员未填写物品名称直接提交申请单 Then 系统返回错误提示 物品名称不能为空 And 申请单不保存4. User Story GWT 组合使用说明4.1 组合逻辑Epic史诗→ Feature特性 →User Story用户故事→多条ScenarioGWT场景User Story 回答我们要做什么能力价值是什么GWT场景集合作为该User Story的验收标准AC覆盖正常流程、异常、边界场景。4.2 完整组合样例User StoryAs a customer, I want to cancel unpaid orders, so that I can release inventory when I do not need goods.作为客户我希望取消未支付订单以便不需要商品时释放库存。Acceptance CriteriaScenario1: 取消未支付订单Given 当前客户存在一笔未支付订单库存已锁定When 客户取消该订单Then 订单状态变更为已取消And 锁定库存被释放Scenario2: 取消已支付订单Given 当前客户拥有一笔已支付订单When 客户尝试直接取消订单Then 系统提示 “已支付订单不可直接取消请申请退款”4.3 组合使用步骤适配4A业务架构BA梳理业务能力域拆分Epic与Feature基于业务能力提炼User Story明确Role、Feature、Business Value需求精化Refinement头脑风暴识别全部业务场景使用GWT编写每个Scenario作为User Story的AC架构/需求评审业务、IT一起评审User Story和GWT场景开发、测试基于GWT场景实现与验证上线后架构资产归档更新业务场景模型。4.4 常见误区❌ 只用User Story不写AC/GWT验收标准模糊上线容易需求不一致❌ 在User Story中写大量业务规则User Story应当简短规则下沉到GWT场景❌ GWT中写技术细节调用API、SQLGWT描述业务Behavior行为❌ 一个Scenario多个When多个动作应当拆分为多个Scenario❌ GWT写Business ValueBusiness Value写在User StoryGWT只描述状态与结果。5. 适用边界适合业务能力梳理、业务流程场景、系统功能需求、验收标准不太适合底层技术改造、基础设施变更TA技术架构这类无业务Role角色的工作项。