第4章 异常流捕获：可能失败场景识别、错误状态列举、异常处理优先级
本章聚焦于用户故事向业务流程转化中的异常流捕获。在梳理正常步骤后，必须系统性地识别可能失败的场景、枚举错误状态，并按优先级编排异常处理逻辑，才能构建健壮的业务流程。本章提供完整的SOP操作指引。
核心目标：从用户故事中提取“如果…那么…否则…”的异常分支，形成可执行的异常处理矩阵，防止业务中断或数据不一致。
适用场景
- 新业务流程设计，需要预埋异常兜底逻辑
- 已有流程优化，排查高频失败环节并补充恢复方案
- 需求评审阶段，检验用户故事是否覆盖边界条件
- 自动化或半自动化流程开发，需要明确异常返回路径
前置条件
- 已完成正常流的步骤识别（章节2、3）
- 每个正常步骤的输入/输出物已定义
- 用户故事中已标注可能出现的“失败”关键词
- 已确定流程责任角色（系统/人工）
操作步骤
- 扫描正常流步骤：逐条检查第3章输出的步骤列表，对每个步骤提问“什么情况下该步骤会失败？”
- 分类失败场景：将失败原因归为三类——数据错误（格式/缺失/重复）、外部依赖超时/不可用、业务规则冲突。
- 枚举错误状态：为每个失败场景定义一个唯一错误码和描述（见输出物表格）。
- 确定异常处理优先级：按影响严重性（阻塞/恢复成本/数据安全）从高到低排序，采用 1（最高）→ 3（最低）三级。
- 关联恢复动作：为每个异常码指定重试、回滚、人工干预或静默忽略。
- 输出异常处理矩阵：汇总为结构化表格（见输出物）。
输入输出物
| 类型 | 名称 | 格式/内容要求 | 来源/去向 |
|---|---|---|---|
| 输入 | 正常流程步骤列表 | 步骤编号+动作+预期结果 | 第3章输出 |
| 输入 | 用户故事原文 | 含“如果不能/否则/失败”等关键词 | 产品需求文档 |
| 输出 | 异常处理矩阵 | 见下表“记录材料” | 交付给流程设计/开发团队 |
责任边界
- 业务分析师（BA）：主导失败场景识别，确保覆盖所有用户故事边界条件。
- 技术架构师：评估自动化恢复可行性，设定重试次数和超时阈值。
- QA：验收异常流覆盖率，验证每个异常码有对应的测试用例。
- PO/产品经理：确认优先级排序符合业务影响预期。
记录材料
必须维护以下文档（格式示例）：
异常处理矩阵（示例片段）
+------+----------+-----------+-----------+-----------------+
| 编码 | 所属步骤 | 失败场景 | 错误状态 | 优先级 | 恢复动作 |
+------+----------+-----------+-----------+-------+----------+
| E01 | 3.2 | 用户ID为空 | ERR_EMPTY| 1 | 弹窗提示 |
| E02 | 3.4 | 支付超时 | ERR_TIMEOUT| 2 | 重试3次 |
| E03 | 4.1 | 库存不足 | ERR_STOCK | 1 | 回滚+通知 |
+------+----------+-----------+-----------+-------+----------+异常处理
⚠ 常见陷阱：
- 遗漏“部分成功”场景——例如流程中途中断，部分步骤已执行；需定义补偿事务。
- 优先级与恢复动作不匹配：高优先级却用静默忽略，导致数据丢失。
- 错误状态枚举过于粗粒度：不同失败原因共用同一错误码，无法精准路由。
若在识别过程中发现新的边界条件，应回溯更新正常流输入条件，并重新评估已有异常优先级。
验收标准
- 每个正常步骤至少有一个对应的异常场景（若步骤具备失败可能）。
- 所有错误状态均有独立编码，且与恢复动作一一对应。
- 异常优先级排序已由PO签字确认。
- 异常处理矩阵表格可在15分钟内被开发人员理解并实现。
- 通过至少一个用户故事的逆向测试：故意输入非法数据，流程应触发预期恢复动作而非系统崩溃。