域名频道资讯站做一款产品前，我们事先要做的就是明确需求与对应场景。对一款企业系统来说，关注点也是如此。
继上一篇业务流程识别与分析篇后，本文主要分享业务场景识别与分析相关知识点。
一、识别业务场景
首先是要理解用例和用户故事的本质，它要求我们不是去关注系统提供什么功能，而是用户在什么场景下需要系统提供支持！
1. 用例的关键知识认知
- 用例名称要基于用户场景去设定，使用业务语言去描述，而不是机械式的使用“增删改查”
- 在业务场景中的用例粒度是由组织分工决定的，特征是独立、可汇报、可暂停的单元（一般不会是太细化的动作）
- 2人/周的工作量分拆成更小的故事，另外大故事要保留的原因是方便组织小故事，不忘初心。
2. 基于流程图识别参与系统的角色。
- 对这个流程提供支撑需要有哪些角色？
- 非必需的角色纳入系统支持中有什么价值？不纳入的话有什么影响？（在优先级排序时有指导作用）
- 一般执行层的角色会用岗位名称命名
- 在权限系统中要如何抽象各个角色
3. 基于流程图识别业务场景
我们要思考在流程过程中，哪些业务活动要系统支持，哪些是部分支持，审批点是否属于系统内，判断点是否为独立环节。
（下图是一套体检系统的流程图，假如工程排期优先内部作业电子化，故体检者一栏暂时不纳入电子系统。红圈则是现要开发的系统所支持的任务活动）
4. 补充业务场景
常见如由时间、状态而触发的业务场景，如信用卡到期还款以及长期逾期状态导致信用卡冻结的场景。
5. 绘制用例图
注意常见三个关系_包含、扩展、泛化。
- 包含关系——公共子事件流（不需给用户看），如检查座位信息。
- 扩展关系——不一定执行的扩展事件流（需给用户看），如处理等候队列。
- 泛化关系——公共事件流，如办理结账。
二、六步分析业务场景
1. 概述业务场景（包括业务目的、前后置条件等）
2. 把场景细化成事件流，整理去用户预期的步骤，并思考扩展和异常事件流。
注意两点：
- 用例描述重在人机交互和意图，不需要过多些人机界面和动作
- 结构化语言描述，少用“如果..就”的表达方式了；扩展或备选事件流单独列出来分支，降低理解成本。
3. 针对每一个步骤，思考并罗列用户可能遇到的问题
4. 针对问题思考解决方案
5. 考虑环境与业务特点带来的影响或要求，主要是性能、易用性、部署环境等三方面
6. 开始初步的交互设计
本文素材来自互联网
