面向对象的需求分析方法

前言

作者最近在做一个电商系统的项目，于是决定用面向对象的需求分析来对整个系统进行需求建模，以该项目为例来聊一聊如何进行面向对象的需求分析，成型打法，拿来即可用。

关于结构化的需求分析方法，作者前面已有文章写过：

结构化分析方法-CSDN博客

目录

1.一些核心概念

2.面向对象的需求分析的核心

3.寻找参与者

4.用例建模

5.业务流程建模

1.一些核心概念

1.需求分析要达到的目的

需求建模，即通过需求来建立起系统的模型。

2.需求建模的作用

形成第一个版本的需求，即形成基线版本。合同中基于基线版本来计算基于基线版本的百分之多少的变化，即需求变化是可以接受的。这样便于成本控制。后续的需求变更都基于基线版本来建立需求变更追踪链。需求追踪：需求、代码、测试，合起来是一条完整需求追踪链

3.需求建模就是要通过需求来描述系统，那么要描述哪些需求？

两个核心点

• 功能性需求

• 性能性需求

功能性需求是一定要满足的基本需求，是程序员的基本价值所在；性能需求可以通过强行购买昂贵的硬件来达到，但是程序员的设计和技术可以降低硬件成本，这是程序员的高价值所在，也是区分程序员价格的一个重要的点。

4.需求的优先级

一个系统的需求是很多的，而且需求的打磨是需要花很多人力物力的，要把每一个需求都打磨到用户体验很好是不现实的，所以将人力物力倾斜到哪里？去打磨些什么？这是值得关注的。从用户用到的频度、广度、强度来决定哪些功能（用户常用的功能）要先做、花更大代价优化体验、提升性能。

2.面向对象的需求分析的核心

在面向对象的需求分析的时候，用用例模型来描述系统，这是面向对象的分析的核心。用例由格式化的表格+非格式化的文字+用例图来合起来建模，建立用例模型。

一个系统有很多个场景，如购买商品是一个场景，退货也是个场景。每个场景里面都包含很多个用例，当我们用用例来组合好场景，用场景来覆盖整个系统的使用需求时，我们就用用例模型来描述好了一个完整的系统。

这里稍微扩展两句，为什么将这种用用例建需求模型的方式叫面向对象的喃？博主前面有一篇关于面向对象的编程范式的思考：

面向对象编程范式_面向对象范式-CSDN博客

这篇文章里聊过：

在面向对象的世界观里世界是由一个一个的节点组成的，每个节点都有自己的职责，节点之间以通信的方式进行协作，构成了整个世界的运行。

用用例建需求模型的过程中，其实就是去找，去描述这些节点的过程，后面我们可以发现我们描述好用例后，在编码实现的时候，就可以通过上面文章中提到的名词分析法去识别出一个个的业务实体对象。

3.寻找参与者

我们上面说了：

当我们用用例来组合好场景，用场景来覆盖整个系统的使用需求时，我们就用用例模型来描述好了一个完整的系统。那么这么来找使用场景有哪些喃？这就要先找到系统的主参与者，系统的主参与者要用到的场景就是整个系统的全场景。所以面向对象的需求分析的第一步是：

寻找所有主参与者

电商的主要参与者：

• 顾客

• 卖东西的商户

• 平台管理人员

找到主参与者后，分析主参与者各自使用系统要完成的场景：

4.用例建模

上面我们找到了主参与者，以及分析出了他们要用到的场景，接下来就是建立场景里的一个个用例。

1.如何描绘用例

找到系统的参与者后就可以根据他们在系统里面要用到的场景来定义用例，覆盖系统了。

用例首先是每个参与者一个总的用例图，再是单个用例。总的用例图起到目录的作用，否则一眼望过去全是单个用例，会很散。

以下是顾客的总用例图，其余的可以参照来画：

2.如何辨别一个用例

整个面向过程的需求分析是先找主参与者，然后找他们的场景，然后去找场景里面的用例，但有时候会发现很难界定出来某一个业务场景到底该有几个用例。比如：商品上架。

商品上架=商家发起+管理员审核。

一个流程分了两步，该做成一个用例还是两个？

这种时候遵循ebp原则：每一个用例的操作人只能有一个，所以应该分成两个用例。

3.如何定义一个用例

定义一个用例的格式要求不高，只要能说清楚就行 哪怕是一段文字都行。以下是推荐的一种用表格进行描述的格式：

针对上面给出的用表格描述的这种方式，有以下几个点要说明。

1.用例里面到底描述一个怎样的流程？

在编写用例的时候很可能会陷入这样的纠结：

用例里面到底描述一个怎样的流程？

因为我们发现一个业务流程稍微复杂一点分支是很多的，选择哪个分支来描述流程？还是全部流程都串起来描述？首先肯定是不能全部流程串起来描述的，这样读都能读晕。完全起不到清晰的建模，描述系统的目的。

一般来说选一个最好扩展出各种子用例的场景作为主成功场景，经验之谈是选用happy path，也就是顺利成功的一条线路的用例。然后整个过程描述的内容是人机之间的交互，以及传递的内容，其它不用描述，这样最简洁。

2.用例的级别

用例可以分为三种级别：

• 用户级别：主参与者要用到的功能点。

• 汇总级别：分类目录，可以设置多层汇总级别，想目录一样。名称自定义

• 子功能级别，指很多地方公用的功能、很多用例公用的能力，比如支付就是一个子功能，到处都要用到，开会员、售后、买商品等。

引入用例级别是为了将用例更好的进行逻辑上的分类。

5.业务流程建模

用例分析出来后会是一地散落的用例，没法系统化的描述系统，需要把用例、场景串起来进行业务流程的建模，可以用用活动图或者泳道图串起来，只要能体现用例之间的流程关系即可。这里给出一个电商的购买商品、订单、配送、售后的全流程活动图。

椭圆：动作，即用例。

矩形：中间过程产生的东西。

菱形：决策节点，判断分叉。

黄色矩形：系统外的操作。

红色矩形：非活动用例，系统默认实现的功能。

要注意的是肯定一张图是说不全整个系统的，按照实际需求来决定要把哪些核心流程描述清楚，画多少张图，这个是很灵活的。