2B系统业务场景识别与分析

识别出系统相关的业务流程，然后对这些流程进行详细的分析、优化，接下来就需要识别出这些流程中存在哪些和系统相关的业务场景。这也是业务为中心需求分析方法的重要任务。 

 1、业务场景识别

识别出系统相关的业务流程，然后对这些流程进行详细的分析、优化，接下来就需要识别出这些流程中存在哪些和系统相关的业务场景。这也是业务为中心需求分析方法的重要任务。

要完成好业务场景识别任务，首先要深入理解业务场景／使用场景的思维角度，理解用例、用户故事的本质。

Q：什么是用例？

A：用例即业务场景、使用场景 。

Q：多大才是一个合适的用例业务场景？

A：一个完整的业务场景应该是独立的、可汇报的、可暂停的单元。粒度是由组织分工决定。

Q：什么是用户故事？

A：用户故事是一种轻量的、有效的用户需求描述方式，它希望用户以“作为xxx（角色），希望通过系统xxx（解决方案、功能要求），以便达成×××业务目的、要解决的业务问题” 的形式提出需求。

在对业务流程进行分析、优化之后，识别系统所需支持的业务场景将变得十分简单，只要基于流程图来识别出角色、场景，然后补充一些时间、状态触发的场景，最后选择合适的模型将其呈现出来即可。

（1）基于流程图识别系统角色：明确业务流程中哪些岗位将涉及系统，之后将其“角色化”，基层岗位通常可以直接使用岗位名作为角色名。

（2）基于流程图识别业务场景：沿着流程，对每个活动、分支、判断点进行分析和思考，哪些业务活动要系统支持、哪些是部分支持，审批点是否属于系统内，判断点是否为独立环节。

（3）补充业务场景：除了由人触发的业务场景之外，还存在特定时间、特定状态触发的业务场景，它们有可能没有在流程图中体现出来。因此，在完成前两步之后，还有必要再花一点时间补充出这类易于遗漏的业务场景。

（4）绘制用例图片段并概述业务场景：所有业务场景都识别出来之后，可以使用一张用例图片段来呈现结果，并对里面的业务场景逐一做出概述性说明。用例图中最核心的元素就是Actor（角色、参与者）与用例。

用例与用例之间三种有效关系：包含、扩展和泛化。

        包含关系表示 的是一定会执行的公共子事件流 ，而且通常只有开发团队关心；

        扩展关系表示 的是不一定会执行的扩展事件流；

        泛化关系表示 的是公共的事件流。

业务场景识别是封装需求的“分子”单位，输出模板如下，

2、业务场景分析

识别出系统要支持的业务场景之后，将以“场景—问题／挑战—方案”的逻辑来分析每个业务场景，从而导出所需的功能。

标识出业务场景之后，还应该细化业务场景的事件流，从而实现以用户视角发现系统应该提供的功能。要执行好这个任务，应该深入理解用户视角的场景描述、场景—挑战—方案两个基础思维。

该任务一共有五个步骤，实际上就是对“场景—问题／挑战—方案”思维逻辑的一些补充，

（1）概述业务场景，以便大家对这个场景建立总体的认识。

该业务场景，用户要实现什么样的业务目的？执行有什么前提条件？结束前需保证何状态？除执行者之外，还有谁关心？关心什么？

（2）细化业务场景的业务步骤（即场景部分）

最典型的、用户预期内的业务步骤是怎么样的（基本事件流）；针对各个步骤，有哪些潜在的变化情况（扩展事件流）；针对各个步骤，有无异常情况，异常如何处理（异常事件流，通常是错误处理部分）

（3）遍历步骤分析困难并导出功能（即挑战、方案部分）

一般建议从两个角度来思考。首先是执行这些步骤时会遇到什么困难？针对这些困难，系统需要提供什么样的功能支持？

其次是分析是否存在一些关键例外，会带来执行的麻烦？这种情况需要系统提供什么样的功能支持？

（4）识别环境与规则

质量要求和约束是有局部性的，在分析一个业务场景时，还应该考虑到环境、业务特点给系统实现带来的要求和影响。

（5）分析实现方式并完成初步交互设计，初步交互设计中主要包括以下几个方面的内容。

交互过程：也可以理解为界面流转图，用来表达你希望系统如何来实现该场景所有业务步骤。

静态快照：即每个页面上的具体内容，可以使用纸上原型呈现。

设计说明：针对每个页面内容、界面流转做一些描述，核心在于说明自己为什么这样考虑，以及它是一种建议还是一种约束。

输出模板如下，

《有效需求分析》一书聚焦于组织应用类软件系统的需求分析环节，介绍了18个按需求组合的关键任务，针对每个任务的一步步指导，以及每个任务输出的“软件需求规格书”片段模板。