需求分析之路专题(6) 详细需求功能分析之业务场景篇

引言

上一小节讲述了需求功能分析中的业务流程识别、分析和优化。接下来的工作就是基于业务流程来识别系统中关键的业务场景。

下面是业务场景识别任务指引图：

场景的识别先从识别角色入手，再结合流程图进行识别，并以用例图的方式进行输出。最后根据业务特点对业务场景进行补充。

场景的识别流程上很清晰，其难易程度依赖于大家之前业务流程梳理的质量好坏，以及是否掌握了业务场景识别相关的技能，下面先介绍业务场景识别必须掌握好的几个技能。

业务场景识别必备技能

业务场景和功能场景思维

作为互联网时代产品经理，相信大家都应该对用例、用户故事需求分析技术耳熟能详了，但是在实践中，真正能正确使用的，还是少数人。

大部分常常还是假借用例、用户故事分析，行功能分解之实。特别是由程序员转岗过来的产品，往往陷在功能场景里。业务场景是站在用户视角，关注其业务场景和使用场景；功能场景是站在开发视角，关注提供什么功能。

拿一个教新用户使用照相机的例子来说明下二者区别，功能场景模式的教法就是一上来告诉他：这个是开关，这个是快门，这个是回放，这个是闪光......；而业务场景模式的教法就是先确定目的，了解用户需求，比如先满足如何拍照和查看照片。

如果直接进行枯燥的功能性描述，只能拒人千里之外，导致与用户沟通不畅，影响需求的获取与理解。而生动的、用户视角的使用场景、业务场景描述，才能与用户产生共鸣，实现需求的获取与理解。

所以我们一定要从功能场景思维切换到业务场景思维。

用例图正确打开方式

用例分析技术的核心在于用户视角的需求观，强调目的和场景的重要性，而不是技术功能性罗列。

以下是一个图书馆管理系统的用例图，你觉得存在什么问题？

大多偏工程思维的产品经理，特别是工程师看到后都认为非常合理和正确，但是这是典型的使用了功能场景思维去描述业务。如果按照这种CURD(增删改查)的方式，那么所有系统的所有功能都可以通过CURD来表示了。

那正确的用例图怎么画呢？就像上面所说的要切换到业务场景去思考。

如果站在业务角度，那就要考虑图书馆新增图书到底表达的是什么？有可能是新购买了图书入库，也有可能是之前遗失的图书，突然找到了，然后重新要登记到系统库中。

另外删除图书表达的业务到底是什么？可能是图书遗失了，也可能是图书过于陈旧需要报废了。

所以新增图书和删除图书的用例，可以修改为下面所示：

注意：并非所有系统CRUD都不适用，有些偏技术性功能或计算机域系统，可能是完全是适用的，比如购物车功能、数据库持久框架系统。

使用用户故事描述场景

熟悉用户故事的人应该都知道它的标准句式：

作为XXX(角色)，希望通过系统XXX(解决方案，功能要求等活动)，以便达成XXX(业务目的，业务价值) 

这个句式强行让人站在用户视角去考虑，天然具备业务场景的特性。强烈推荐大家使用。

用户故事自身具备六个特点：独立性、可协商性、有价值、可估算、简短、可测试。

可以说把项目需求拆分成用户故事是很高级的技能，用户故事技能的具体的使用不是本章节探讨的范畴，有兴趣的读者可以参考阅读用户故事专题和相关书籍。

业务场景识别要点

掌握了业务场景思维模式，再加上用户故事和如何正确的绘制用例图。业务场景识别上就能顺利很多了。这里针对4个流程的一些关键点再做下说明。

识别系统角色

基于流程图识别系统角色，我们需要提出下列问题：

• 流程中涉及哪些用户？

• 对于非必须的用户纳入系统支持有什么价值？

• 不支持有什么不足？

• 系统中这些用户角色是什么？

• 如何抽象为权限系统的角色？

基于流程图识别业务场景

基于流程图识别业务场景时，我们要对每个活动、分支、判断点进行分析思考，判断哪些业务活动系统要支持？哪些是部分支持？审批点是否属于系统内？判断点是否为独立环节？

绘制用例图

绘制用例图的目的是来概述业务场景，我们可以利用用例角色之间泛化关系，用例之间包含、扩展、泛化来简化用例图，同时要注意用例图的阅读对象。

在绘制用例图时，一定要切换到业务场景思维，不要被CRUD带偏。

特别说明下包含关系表示一定会执行的公共子事件流；扩展关系表示不一定会执行的扩展事件流；泛化表示公共事件流。至更多于用例图的绘制标准，大家可以参考UML相关书籍或参考我的另一份专题教程《如何构建现代巴别塔》。

注意：不要试图利用用例图来表达业务的流程，用例图是表达执行者到底能做什么，流程是管理者关心的角度。就像开发团队中，产品和测试要专注业务的全部流程节点，而前端开发和后端开发，作为执行者，更关心的是在不同业务流程中，自己负责那部分细节，前端只需考虑调用后端接口的时机，需要提供的参数，以及响应结果，至于业务处理细节，前端人员一般无需知道。

补充业务场景

最后补充业务场景，需要我们去思考特定时间、特定状态下触发的业务场景，比如系统是否需要提供定时任务(每月账单)，是不是需要告警提醒(余额不足)等。

另外也存在一些无业务流程或弱业务流程的系统，服务请求基本上就可以代表为业务场景，就无需单独列出来了。

业务场景分析

识别出系统的业务场景之后，就要以场景—问题/挑战—方案的逻辑来分析每个业务场景，得出系统所需要的功能。

下面是业务场景分析的任务指引图：

业务场景分析大致可以分为5个步骤：

• 概述业务场景

• 细化业务场景

• 遍历步骤分析

• 识别环境与规则

• 分析实现方式，完成初步交互设计

在具体介绍每个步骤之前，我们要先了解下从场景到方案是怎么转化的。

什么是从场景到方案逻辑

从场景到方案逻辑主要包含了两个基础思维：一个是用户视角场景描述，另一个就是场景—挑战—方案的思考路径。

用户视角场景描述比较好理解，就是站在用户视角来描述场景，使用用户故事的模式就能做到这一点。

举一个在线旅游网站中行程计划这个功能为例进行说明下什么是场景—挑战—方案的完整思考路径。

首先看场景。

以用户视角找场景，行程计划中用户有什么需求场景？用户决定要去某地旅游，第一步要干嘛？找攻略吗？如果你的答案是找攻略，说明你还没切换到用户视角。

你再思考下找攻略是需求场景还是解决方案？很明显找攻略是用户想制订旅游计划的一个解决方案。用户场景应该是想去的景点、想买的东西、想玩的项目、想吃的美食......

所以我们大致可以得到下面这样的基本场景：

再看挑战。

思考每个场景下，可能会遇到的问题，这里就不展开讨论，直接给可能的描述了

在看解决方案。

针对问题，思考系统应该提供什么样的功能。针对上面可能的问题，我们可能得到下面的产品解决方案：

以上就是一个从场景到挑战再到方案的完整思考路径。

业务场景分析要点

• 概述业务场景：思考该业务场景中，用户的业务目的是什么？执行该业务场景有什么前提条件？结束条件？除了场景执行者外，还有谁关心它？关心什么？

• 细化业务场景的业务步骤：梳理方法就是上面提到的场景—挑战—方案模型中场景步骤进行，描述时需要注意一些要点。在描述的时候着重点放在人机交互而非人机界面，着重在用户意图而非用户动作。另外再进行结构化陈述时候，要避免分支与循环，分支循环用单独事件流陈述。(避免出现如果..那么...重复执行...等词汇)

• 遍历步骤分析困难，导出功能：这个阶段属于场景—挑战—方案模型的后面二个步骤，思考的时候建议从以下两个角度进行，1 执行步骤时，变化和异常情况下会遇到什么困难？2 针对这些困难，系统需要需要提供什么的功能支持？

• 识别环境与规则：环境与规则主要是考虑性能(人数、业务量、峰值密度等)、易用性(用户文化水平、学习曲线)、部署环境(网络、软硬件环境)等非功能性需求。

• 分析实现方式，完成初步交互设计：这个阶段体现交互过程(页面流转、业务步骤)，一些静态快照(体现页面具体内容)，设计说明(设计原因、建议、约束)

小结

本小结主要介绍了业务场景的识别和分析。其中场景识别的过程依赖之前业务流程的分析识别，所以前一个环节的工作质量会影响到后一个环节。在识别分析的过程中如果发现业务流程存在问题和不清楚之处，也可以回头进行迭代补充。

业务场景识别需要大家先掌握好正确的思维方式和方法，这里提到的主要有：场景思维、用例图绘制法、用户故事法。然后按照4个识别步骤按顺序展开即可。

在业务场景分析中要掌握的核心技巧就是从场景到挑战再到方案的思考模型，结合5个分析步骤逐一展开就能很好完成分析过程，输出初步的解决方案。

附录

当我们完成业务场景识别后，需要输出用例场景图示文档，模板如下图所示：

当我们完成业务场景分析之后，需要输出业务场景分析模板，模板如下图所示：