企业官网建设流程全解析

适用场景：企业架构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 关键英文词汇说明

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 关键英文词汇说明

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角色的工作项。