电商系统用例建模实战：从需求分析到架构设计

1. 项目背景与核心价值

这个幻灯片项目聚焦于软件工程中最基础也最关键的环节——需求分析阶段的系统用例建模。作为从业十余年的系统分析师，我见过太多项目因为前期需求模糊导致的后期返工。这份材料正是为了解决这个痛点，通过完整案例演示如何从零开始构建精准的用例模型。

不同于教科书式的理论讲解，本套幻灯片以真实的电商订单系统为背景，逐步展示：

• 如何识别系统边界与执行者
• 怎样区分用户目标级用例与子功能
• 编写具有可测试性的用例规约模板
• 处理"包含"与"扩展"关系的典型误用场景

2026年1月的最新更新特别增加了AI时代下的用例建模变化，例如如何处理智能推荐系统等非确定性需求。

2. 系统用例图深度解析

2.1 要素拆解与绘制规范

用例图看似简单，但魔鬼藏在细节里。以电商系统为例，必须严格区分：

• 核心执行者（如买家、卖家）与辅助执行者（如支付网关）
• 用户目标级用例（如"提交订单"）与系统功能（如"计算运费"）
• 系统边界框的合理划定（哪些属于本系统范围）

常见错误：把全部后台管理功能都塞进同一个用例图中。正确做法是按业务域拆分视图，比如订单管理、商品管理分别建图。

绘制工具推荐：

• 企业级：Enterprise Architect的用例矩阵功能
• 轻量级：draw.io的UML模板库
• 协作型：Miro的敏捷需求板

2.2 关系类型实战技巧

包含(include)关系最容易滥用。判断标准：被包含的用例是否：

1. 必须发生（如支付流程必须验证账户余额）
2. 在多个父用例中重复出现

扩展(extend)关系的典型场景：

• 异常流程（如"处理支付失败"扩展自"完成支付"）
• 可选功能（如"使用优惠券"扩展自"结算订单"）

继承关系的使用要极其谨慎，一般仅当：

• 子执行者有显著不同的行为模式（如VIP买家比普通买家多出"使用专属折扣"用例）

3. 用例规约编写指南

3.1 六要素黄金模板

一个完整的规约应包含：

1. 前置条件（如"用户已登录"）
2. 主成功场景（6-8步为宜）
3. 扩展场景（所有if分支）
4. 业务规则（如"单笔订单最多使用3张优惠券"）
5. 非功能需求（如"响应时间<2秒"）
6. 后置条件（系统状态变更）

示例片段：

code复制用例名称：取消订单
主成功场景：
1. 买家在订单列表选择待付款订单
2. 系统显示订单详情页
3. 买家点击"取消订单"按钮
4. 系统验证订单状态为"待付款"
5. 系统更新订单状态为"已取消"
6. 系统释放库存占用

3.2 常见缺陷规避

新手常犯的错误包括：

• 把UI操作细节写进基本流程（如"点击红色按钮"）
• 遗漏异常分支（如网络中断时的补偿机制）
• 混淆业务规则与实现约束（前者是what后者是how）

经验法则：好的规约应该能让开发人员不询问需求方就直接编码，同时让测试人员能据此编写所有测试用例。

4. 现代需求工程中的用例演进

4.1 应对AI系统的挑战

当系统包含机器学习组件时，传统用例方法需要调整：

• 用概率性前置条件（如"推荐准确率≥80%"）
• 扩展场景中增加模型迭代路径
• 标注数据依赖关系（如"需要用户历史行为数据"）

4.2 敏捷环境下的轻量级实践

在Scrum中可以采用：

• 用户故事与用例图的映射关系
• 将复杂用例拆分为多个冲刺Backlog
• 使用用例切片(Use Case Slicing)技术

工具链整合建议：

• Jira插件生成可追溯的用例矩阵
• Confluence模板库中的规约模板
• 与Swagger实现需求到API的自动衔接

5. 企业级案例实操

某跨境电商平台的需求设计实录：

1. 识别出47个核心用例，按业务域划分为：

   • 订单处理（12个）
   • 商品管理（9个）
   • 跨境支付（7个）
   • 物流跟踪（6个）
   • 客服系统（13个）

2. 关键复杂用例"处理关税计算"的规约要点：

   • 主场景涉及3个国家/地区的税法规则
   • 扩展场景包含7种异常情况
   • 需要集成第三方关税API

3. 版本控制策略：

   • 用例图用Git管理版本差异
   • 规约文档与测试用例双向链接
   • 变更影响分析矩阵

6. 效能提升技巧

6.1 需求复用策略

建立企业级用例资产库：

1. 抽取公共基础用例（如用户认证）
2. 按行业分类典型场景（如电商的购物车）
3. 标注可配置点（如支付方式组合）

6.2 评审加速方法

采用"3+1"评审法：

• 3个角色必须参与（BA、Dev、QA）
• 1份检查清单覆盖：
  • 完整性（所有分支是否覆盖）
  • 一致性（术语是否统一）
  • 可测试性（是否有明确验收标准）

6.3 工具链优化

我的个人工作台配置：

• Visual Paradigm做图形化建模
• Notion管理规约文档库
• Postman自动化验证业务规则
• 自定义的VS Code片段库快速生成模板

7. 从需求到架构的衔接

优秀用例模型应该自然导出：

• 系统模块划分（微服务边界）
• API接口定义（Swagger描述）
• 领域模型雏形（DDD中的限界上下文）

以"订单履约"用例为例：

1. 识别出订单服务、库存服务、物流服务
2. 定义出OrderSubmissionEvent等领域事件
3. 明确Saga事务的补偿机制需求

这种衔接能减少70%以上的后期架构调整，也是判断用例模型质量的重要标准。