业务场景、异常情况与范围控制
本章目标：把访谈记录整理成明确、可验证的业务场景，同时确定第一版做什么、不做什么。
1. 场景是连接需求、设计和测试的主线
一个好的业务场景应说清楚：
谁，在什么前提下，为了什么目标，执行什么操作，系统和其他人应产生什么结果。
采购案例的正常场景：
申请人在办公用品目录中填写两项物品、数量和用途，保存并提交。系统计算每行金额和总金额。由于总额不超过 5000 元，申请进入直属主管审批。主管同意后，行政采购员在待采购视图中看到该申请。
这个场景以后可以同时指导：
- 需要哪些字段；
- 需要哪些计算；
- 流程如何分支；
- 哪些角色能看到记录；
- 应该怎样测试。
2. 场景的七个组成部分
| 部分 | 要回答的问题 |
|---|---|
| 参与者 | 谁执行？ |
| 目标 | 他为什么要做？ |
| 前提 | 开始前必须满足什么？ |
| 触发 | 什么事情让场景开始？ |
| 主要步骤 | 正常情况下依次发生什么？ |
| 结果 | 完成后业务处于什么状态？ |
| 例外 | 哪些情况会改变或中断正常路径？ |
示例
场景名称：提交普通金额采购申请
- 参与者：申请人；
- 目标：获得办公用品采购批准；
- 前提：申请人有权访问应用，物品和预计价格已知；
- 触发：申请人发现部门需要补充办公用品；
- 主要步骤：新建申请 → 填写明细 → 自动计算 → 提交；
- 结果：申请进入直属主管待办，申请人看到“审批中”；
- 例外：金额为零、明细为空、审批人不存在、重复提交。
3. 不要只写正常路径
至少从以下方向寻找例外：
3.1 输入异常
- 必填内容没有填写；
- 数量或金额不合理；
- 同一物品重复添加；
- 附件格式不符合要求。
3.2 业务异常
- 申请人在审批前撤回；
- 审批人退回修改；
- 采购过程中发现缺货；
- 已批准申请因业务变化作废。
3.3 人员异常
- 找不到审批人；
- 审批人请假或离职；
- 申请人在流程中转部门；
- 行政采购员发生工作交接。
3.4 时间异常
- 审批超过约定时限；
- 申请跨月处理；
- 价格有效期已过；
- 申请在规则变更前提交、变更后仍在处理。
3.5 权限异常
- 普通员工尝试查看其他人的申请；
- 主管尝试修改申请内容；
- 已离开岗位的人仍然拥有角色；
- 未经授权的人获得导出文件。
异常并不一定都在第一版自动处理，但必须知道由谁、用什么方式处理。
4. 把模糊说法改写成可验证需求
模糊
系统要简单好用。
改写
- 申请人只需填写用途和明细，申请编号、申请日期和总金额自动得到；
- 正常申请不超过一个页面即可完成；
- 校验失败时明确指出哪个字段和原因。
模糊
主管能看部门数据。
改写
- 直属主管可以查看由自己负责部门的采购申请；
- 只能审批分配给自己的待办；
- 不能修改申请人的物品明细；
- 是否允许导出由业务负责人单独确认。
模糊
大额需要高级审批。
改写
- 总金额大于 5000 元时，在直属主管同意后增加行政负责人审批；
- 总金额等于 5000 元时只需直属主管审批；
- 金额以提交时的申请总额判断；
- 退回修改导致金额跨越边界时，重新提交应按新金额选择路线。
5. 给需求设定优先级
建议使用四级：
| 级别 | 含义 | 判断方式 |
|---|---|---|
| 必须 | 缺少就无法完成核心业务或违反明确制度 | 第一版一定实现 |
| 重要 | 显著改善效率或管理，但可短期人工处理 | 时间允许优先实现 |
| 可选 | 有价值，但不影响首个闭环 | 后续迭代 |
| 暂不做 | 当前无清楚价值、依赖未满足或超出范围 | 明确记录原因 |
采购第一版示例：
- 必须：申请、明细、金额计算、主管审批、权限、状态查询；
- 重要：高金额分支、退回修改、待采购视图；
- 可选：自动催办、采购月报、打印；
- 暂不做：供应商比价、付款和库存入库。
“暂不做”也是有效决定
它不是忘记需求，而是为了让第一版可按时完成。记录原因和重新评估条件，后续就能有依据地恢复。
6. 定义第一版边界
范围需要同时写“包含”和“不包含”。
第一版包含
- 办公用品采购申请；
- 员工、主管和行政三个主要角色；
- 申请到批准、采购完成；
- 本部门试点；
- 新产生的数据。
第一版不包含
- 生产物料采购；
- 供应商合同和询价管理；
- 财务付款；
- 库存数量变化；
- 历史 Excel 全量迁移；
- 移动端专项优化。
如果只写包含项，其他人容易默认未提到的内容也包含在内。
7. 处理非功能性的业务期望
业务开发者不需要设计底层技术，但要问清会影响使用的期望：
- 大约有多少用户和多少条记录；
- 是否多人同时操作；
- 是否有跨地区和时区使用；
- 哪些数据敏感；
- 是否必须打印或留档；
- 业务中断多久可以接受；
- 是否有固定的月末、年末高峰；
- 哪些操作必须可追溯。
这些信息会影响表单、权限、视图、上线和验收设计。
8. 建立需求追踪表
给每一条需求一个编号，后续设计和测试都引用它：
| 编号 | 场景或需求 | 优先级 | 设计落点 | 验收方式 | 状态 |
|---|---|---|---|---|---|
| R-01 | 员工提交采购申请 | 必须 | 采购申请模板 | 正常提交场景 | 已确认 |
| R-02 | 总额自动计算 | 必须 | 计算规则 | 两行明细核算 | 已确认 |
| R-03 | 大于 5000 元增加审批 | 重要 | 流程分支 | 5000/5000.01 边界测试 | 待确认 |
| R-04 | 每月采购统计 | 可选 | 管理视图 | 月度样例核对 | 后续 |
追踪表的价值是防止需求在设计、开发或测试中悄悄消失。
9. 需求进入分析阶段的门槛
在继续之前，至少应满足：
- 业务目标和第一版边界已经明确；
- 关键角色都已参与；
- 正常场景能够从开始讲到结束；
- 主要异常情况已经列出；
- 关键争议有负责人和决定期限；
- 每项必须需求都能描述预期结果；
- 还没有急着把所有内容翻译成字段和页面。
10. 常见错误
- 把“以后可能需要”全部塞进第一版；
- 场景只写用户点击什么，不写业务目标和结果；
- 用“支持”“优化”“灵活”等词代替明确行为；
- 忽略边界值，例如 5000 元到底属于哪一侧；
- 只写系统应该允许什么，不写应该拒绝什么；
- 没有记录不做的内容，导致范围持续扩大。
11. 本章完成标准
- [ ] 核心业务至少有一条完整正常场景；
- [ ] 已按输入、业务、人员、时间和权限寻找异常；
- [ ] 模糊要求已改写成可观察结果；
- [ ] 第一版包含和不包含的内容都已明确；
- [ ] 所有需求都有优先级；
- [ ] 必须需求已进入需求追踪表。
下一步
需求已经形成可验证的场景，接下来进入业务分析：先统一业务语言并识别业务对象。