案例分析的基本方法，基于案例分析 返回列表

“从产品做出原型到研发编程实现，中间有一条鸿沟。需求越复杂，这条鸿沟就越大。”如何弥补这个“鸿沟”呢？我们需要进行两个工作：系统分析与架构设计。本篇 Chat 先讲其中的系统分析。

系统分析强调对问题的调查，要解决的是系统必须做什么的问题。

此次交流以一个零售企业的实际项目为例，讲述如何进行系统分析。内容包括：

软件系统分析全过程定义系统的目标和范围分析系统流程需求规格描述

系统分析能力是架构师必备的，希望通过本次交流，为学员成为系统架构师打好专业基础。

移动支付的使用已经非常广泛。不管是线上的电商平台，还是线下的实体零售，都支持多种支付方式，这就给企业财务人员的核账工作带来极大的挑战。拿实体零售来说，没有移动支付前，只能付现金，财务人员只要核对实收现金和营业额。如今，支付方式繁多，每一种支付都需要财务人员去核对。以我们公司为例，我们有 400+ 实体店，每天是几十万的支付流水，而一个运作良好的电商平台，每天会产生上百万的支付流水。面对巨量的支付数据，财务人员依赖于手工核账显然是不行的，不光工作量大，还容易出错。这时，财务部门会要求建立对账系统，由系统来完成核账。

在业务部门或者产品经理(互联网公司设有产品岗，一般需求来自产品经理) 提出需求之后，我们首先要分析业务逻辑抓住核心需求，理清系统的边界，知道系统能做什么，不能做什么。然后，才能设计出满足业务方要求的系统。一种常见的情况是，职场新人拿到需求就开始设计数据表结构，写代码了，想到哪写到哪。另一种情况是，一些有工作经验的人，凭着自己的经验去设计，要么是考虑不周，要么就是漏掉一些功能。这都是设计系统之前缺少系统分析而造成的问题。

下面我们通过零售企业的对账系统，介绍系统设计前如何做好系统分析。

需求分析

需求分析的目的是确定系统目标和范围。有了清晰的目标和范围，我们才知道系统要建成什么样，成功与否的衡量标准是什么。社交平台上，经常看到有人说学习静不下心，没看几页书心就不知道飘到哪去了。这就是典型的没有目标的学习，学到什么程度可以结束没有清晰的界定。

首先是定义系统目标，就是说我们为什么要建立这个系统？系统目标最好用一句话能描述清楚，对账系统的目标可以这样描述：

帮助财务人员提高对账效率，保障资金安全

确定了目标，就有了方向。再来看如何理清系统范围。系统范围指的就是我们要开发的那些功能，理解核心流程（对账业务的流程）或者企业最为关注的事件，可以帮助我们理清系统范围。

1. 对账业务流程

企业内部有各种各样的流程，我们只要关注跟系统有关的业务流程。我们的对账系统跟对账有关，对账业务一般是这样的：

财务人员每天从外部支付平台下载前一天的支付对账单，同时也拉取出前一天公司业务系统里的支付流水，统一调整好数据格式后，将两边的数据进行一一比对，找出问题数据并处理掉。

从整体来看，按照时间的先后，对账业务可以分为三个阶段：数据准备 (下载对账单，统一数据格式) 、数据核对和差错处理（问题数据处理），但它们在同一个业务流程上，即对账流程。我们用业务用例图描述如下:

业务用例描述：

业务用例名称简述对账财务人员核对支付数据，找出问题数据进行处理2. 分析业务流程

圈出了系统将参与的业务流程（对账）后，就来分析它的工作流程，看看在流程内部的一连串工作，哪些工作是人工操作的，哪些工作是可以信息化的，可信息化的工作项目将作为系统的服务项目，也就是系统的功能。

读者朋友可能已经发现了，我们分析业务流程，其目的就是为了定义出系统用例。所以会有一套切分工作项目的准则：

有时间间隔的工作，适合切分成两项工作。人工操作跟可信息化操作分开。记录系统上线之后的工作项目。一项工作最好只有一个负责人。

现在来看一下对账业务流程，财务人员首先是拿到外部平台的对账单和公司内部业务支付数据，然后调整数据格式，最后进行数据比对，找出问题。这一连串的工作，我们可以用活动图来表示。

下载对账单和获取业务支付流水都是为了拿到对账所需的数据，抽象一点的话，可以把它们看作为数据接入。

3. 定义系统范围

活动图中的每一个动作，都可能成为系统用例。系统用例是我们需要开发的功能，它们构成了系统的范围。前面我们说过，可以信息化的动作将作为系统用例。

我们来看一下每个动作，数据接入、数据转换和数据核对一定是可以信息化的，它们是对账系统要解决的核心问题，而差错处理目前是人工操作的，不可以信息化，它不能作为系统用例。但在系统上线后可以有系统报警，以邮件或短信的形式通知财务人员。对应的，就可以用 \”发送报警邮件\” 或 \”发送报警短信\” 作为系统用例。

下面用 “定时启动者” 作为用例的启动者，是因为对账系统上线后是定时自动运行的。

系统用例名称简述1）数据接入系统每日于约定时间主动从外部系统拉取对账单2）数据转换系统把对账单以统一的格式进行转换3）数据存储系统将转换过格式的数据存储到对账数据池中

系统用例名称简述1）数据对比系统对双方的每条数据依次进行比对2）差异记录记录比对过程中发现的问题数据

系统用例名称简述1）二次核对系统对差错记录中的数据会进行二次核对，避免由于日切的原因造成问题错报2）系统报警对不能自动修复的问题数据，通知手工处理

至此，我们已经确定了系统的范围。就是说，我们已经知道对账系统将会有哪些功能了。

4. 分析系统流程

就像分析业务流程一样，得到系统用例后，我们还需要分析每个系统用例的细节和规则，最后编写成用例叙述文档，这份文档作为正式需求分析文件，也可以作为业务人员与开发人员之间的沟通文件。

一份用例叙述格式里包含很多字段，实践中常用的字段有这些：

用例基本数据 用例名称用例编号 (ID)用例简述用例图 执行流程 主要流程代替流程例外流程条件及规则 前置条件后置条件失败时状态业务规则

我们以 “拉取数据” 为例，其他用例类似。

用例名称拉取数据用例编号SUC001用例简述系统每日于约定时间主动从外部系统拉取数据用例图参考画面主要流程1) 时间一到，系统自动通过外部系统的 api 拉取对账单。 2）调用数据转换服务例外流程1a) [网络异常]请求超时，3秒后重试。业务规则5. 建立领域模型

编写好系统用例叙述后，需求分析的工作就完成了。

建立领域模型可以放在系统设计时去做，通常分析阶段输出的模型图，系统（架构）设计师会再进行调整以便开发人员参照编写代码。我们的对账业务比较简单，这里提供一下思路，读者朋友可以试着挑战一下。需要注意的是一定要理清业务的概念，使用统一语言，这是进一步沟通的基础。

我们是从企业流程分析开始的，从 Use Case 的叙述中去寻找概念，然后再将这些概念合起来组成概念 (类) 图。也可以从领域概念分析着手，找出概念及关系，然后拿比较关键的 Use Case 来检验看看这些类别是否能正确支撑 Use Case，若是无法通过检验，就逐步修正类别或其关系。

这两种方式哪种好，是见仁见智的。若是能让它们相辅相成是最理想的。其实，很多年前 James Rumbaugh 就提出了 Two-prong 系统分析方法，将领域分析和 Use Case 结合起来，首先是捕捉领域知识来建立领域模型；然后针对特定应用系统的 use cases 加以检验，来建立应用模型。

总结

最后，我们再来回顾一下需求分析的过程，首先我们要找到跟系统有关的业务流程，换句话说，就是企业关心的事件；接着，我们就要分析流程内部的工作项目，哪些是手工操作，哪些是可以信息化的，可以信息化的将作为系统用例，用来定义系统的范围；确定了系统的范围之后，就要仔细的分析业务细则，最后编写系统用例叙述，形成正式的需求分析文档。

本文首发于 GitChat，未经授权不得转载，转载需与 GitChat 联系。

阅读全文: http://gitbook.cn/gitchat/activity/5caab0d09748e11d2f2412b2

您还可以下载 CSDN 旗下精品原创内容社区 GitChat App ，阅读更多 GitChat 专享技术内容哦。

66823281

《案例分析的基本方法，基于案例分析》来自互联网同行内容，若有侵权，请联系我们删除！