企业系统需求分析（04）：业务场景识别与分析

继上一篇业务流程识别与分析篇后，本文主要分享业务场景识别与分析相关知识点。

用例名称要基于用户场景去设定，使用业务语言去描述，而不是机械式的使用“增删改查”

在业务场景中的用例粒度是由组织分工决定的，特征是独立、可汇报、可暂停的单元（一般不会是太细化的动作）

2人/周的工作量分拆成更小的故事，另外大故事要保留的原因是方便组织小故事，不忘初心。

对这个流程提供支撑需要有哪些角色？

非必需的角色纳入系统支持中有什么价值？不纳入的话有什么影响？（在优先级排序时有指导作用）

一般执行层的角色会用岗位名称命名

在权限系统中要如何抽象各个角色

我们要思考在流程过程中，哪些业务活动要系统支持，哪些是部分支持，审批点是否属于系统内，判断点是否为独立环节。

（下图是一套体检系统的流程图，假如工程排期优先内部作业电子化，故体检者一栏暂时不纳入电子系统。红圈则是现要开发的系统所支持的任务活动）

常见如由时间、状态而触发的业务场景，如信用卡到期还款以及长期逾期状态导致信用卡冻结的场景。

注意常见三个关系_包含、扩展、泛化。

包含关系——公共子事件流（不需给用户看），如检查座位信息。

扩展关系——不一定执行的扩展事件流（需给用户看），如处理等候队列。

泛化关系——公共事件流，如办理结账。

1.概述业务场景（包括业务目的、前后置条件等）

2.把场景细化成事件流，整理去用户预期的步骤，并思考扩展和异常事件流。

注意两点：

用例描述重在人机交互和意图，不需要过多些人机界面和动作

结构化语言描述，少用“如果..就”的表达方式了；扩展或备选事件流单独列出来分支，降低理解成本。

3.针对每一个步骤，思考并罗列用户可能遇到的问题

4.针对问题思考解决方案

5.考虑环境与业务特点带来的影响或要求，主要是性能、易用性、部署环境等三方面

6.开始初步的交互设计

本文由@PM达云霄原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。