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