产品经理

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

2021-05-08  本文已影响0人  番茄990

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

 1、业务场景识别

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

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

Q:什么是用例?

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

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

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

Q:什么是用户故事?

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

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

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

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

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

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

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

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

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

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

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

2、业务场景分析

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

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

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

(1)概述业务场景,以便大家对这个场景建立总体的认识。

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

(2)细化业务场景的业务步骤(即场景部分)

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

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

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

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

(4)识别环境与规则

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

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

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

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

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

输出模板如下,

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

上一篇下一篇

猜你喜欢

热点阅读