B端产品经理必知必会：基于UML的B端产品需求文档撰写探究

B端产品经理必知必会：基于UML的B端产品需求文档撰写探究

编辑导语：UML最大特点是面向对象，与java相同，如果产品经理可以掌握UML方法，会事半功倍，减少交流成本，提高团队效率。这篇文章从一个相关案例的UML建模准备工作出发，从获取需求，到需求分析，再到系统分析，最后是系统设计，客观详细地将整个流程展开进行了叙述，推荐想要了解UML的童鞋进行阅读。

UML是统一建模语言，它不是系统设计的方法，而是系统建模的标准。现在无论是B端还是C端的互联网产品都是基于java所开发而成的，java的最大特点是面向对象，UML最大的特点也是面向对象。如果产品经理掌握了UML方法，无疑可以加强团队效率，减少交流成本。本篇文章适合有一定uml基础的同学阅读。

本篇文章将直接从一个关于“高职院校提前批报名系统”的建设实践出发，从准备工作→获取需求→需求分析→系统分析→系统设计完整流程展开叙述，其中每个模块都参杂了我对B端产品经理业务的思考。

关于整个UML建模流程图和如下：

一、准备工作

1. 了解业务概况，整理业务目标

在这个阶段，我们的视野应当聚焦在业务中，因为B端产品的核心归纳就是“产品即服务”。在我们获取到企业的业务需求时，我们不应当直接开始思考如何将需求实现，而是去其更上一层思考其整个业务的执行流程，思考原来的业务是否可以进行优化，我们不应只是解决企业需求的系统实现，更应该思考其业务如何优化。系统只是业务执行的效能工具，系统在业务中何时出现，何时使用才能让企业的需求得到满足，这才达到我们的目的。

（1）相关讲解

业务概况：当你要为一个企业建设一个系统以解决其相关业务需求时，你需要去了解该业务的整个大体的流程和该业务的现运行现状，总结出其该需求下所涉及的业务范围。

注意⚡️：业务范围是我们确定业务目标的出发点，对于B端的业务一般比较复杂，所以业务可能是多角度和多模块的，我们要将业务进行分类，划分出大致的一个业务范围。

业务目标：一般在去为企业解决业务需求和建立系统时，企业都会提出一些层次比较高的期望，再结合你对整个业务的了解，你可以整理出该企业此业务的业务目标。

注意⚡️：业务目标是我们定义业务边界的出发点，所以业务目标最好是根据整理出来的业务范围进行。

提示🛰：最初确定的业务目标一定不是最准确的，在你后续调研涉众需求、定义业务边界、发现主角的过程中一定要带着业务目标去思考，要前后保持一致，业务目标不是定死的，要给每个业务范围定义一个目标，这是个反复修改的过程，包括后续的业务边界定义、发现主角的过程都会随之发生修改，这是一个正常的事，因为这是决定了系统的最终建设成果。

（2）实践示例

业务概况：

① 业务流程概览

在提前招生录取流程中，学生完成报名工作需要经历以下流程：根据已公布的提前批招生计划进行选报招生录取院校、进行缴费、申请素质特长、打印准考证、参加考试、入围资格查询、成绩查询、拟录取查询等一系列活动。

相应地，参与提前招考的高职院校需要完成：提前批考生信息初审（对报名考生的基本信息与考试院的数据进行对接）、考生报考资格筛选、考务编排、缴费收取、成绩录入、拟录取计算、拟录取结果发布等一系列活动。

② 现存业务问题

• 没有标准统一化的报考系统导致部分院校线上资源利用率差，工作冗余度高，出现一个业务多个系统来完成的情况。
• 线上线下的业务执行结合度不高，也将导致业务完成效率低，增加工作人员和报考学生的负担。
• 当前大部分高职院校所采用的招生管理系统没有涉及到整个招考和报考流程，只局限于解决部分工作，没有完全实现业务的数字化转型。
• 对于系统建设主要面向PC端，未能面向移动端，不符合当下移动化操作趋势。

③ 业务范围分类

综合学生报考完成工作和高职院校招生完成工作的流程，提前招生管理业务主要有：考生报考业务、考务管理业务、财务管理业务、信息管理业务等。系统应当面向学生和院校建立不同的管理终端，在各终端中需要完成各类业务，实现线上线下的业务配合，优化报考中的各个流程。

业务目标：

• 优化学生报考流程，提供考生一体化自助服务，方便考生报考，降低考生报考院校的业务复杂度。
• 优化高职院校业务处理流程，实现业务数字化覆盖，减轻人为工作量和物理资源浪费。
• 实现财务管理电子化和缴费一站化，提高学生缴费便捷度和减少财务部门的工作复杂度。
• 实现学生信息管理、教务管理、考生结果管理统一化，规范数据库输入与输出流程，提供分权限数据限调用机制。

2. 做好涉众分析，获取系统期望

这个阶段，是为了理清、列举所有与要建设的业务系统（B端产品）相关的一切人和事。大多数时候，我们做用户需求调研时，直接向系统的直接使用者进行调研，对于B端产品来说是不正确的。我们要到更上一层次去分析，分析业务的利益相关者，分析系统使用者背后所代表的部门或者上级，统计一切利益相关者的期望。因为我们做的东西不仅要让使用者满意，更要让使用者的领导满意，因为不同的人对系统的视角不同，我们调查系统需求时，要站在更高的视角去分析业务的需求，最后得到的系统才能让B端用户满意。

注意⚡️：此处我们没有直接说明为“需求”，而是“期望”，是因为，此处我们探讨的是更高层次的需求，这大多是非功能性需求，以这样的需求点出发，才能使系统建设的大方向不会出现错误。不会为了满足而满足，导致业务最终的执行未得到效率的提升。

（1）相关讲解

涉众分析：涉众指的是系统的使用者和与业务系统有利益关系的人和事。涉众分析就是理清所做的系统的使用者和利益涉及者。这步和调查用户群和用户需求是一致的。

发现涉众步骤：列举涉众、说明涉众在业务或者系统中所负责的事件、调查所列举涉众对业务优化或者系统建设的期望

（2）实践示例

涉众概要：

用户概要：

二、获取需求

在准备工作中，我们已经归纳出了业务的范围，对业务的模块有了大致的划分。根据业务范围的划分，我们确定了每个业务范围相应的业务目标。已知：业务范围、业务目标、业务涉众，我们就可以借此进一步探讨用户的详细需求。

1. 定义业务边界，回望业务目标

定义边界其实是进一步明确业务范围，明确该业务范围所含的业务主角和业务工人。此处强调根据业务去划分范围。这里我们常常会理所当然地将系统模块和业务边界混淆。这是不正确的，因为系统实现的时候会出现业务范围的交叉，也有的业务不会在系统中体现。另外一个错误点就是以企业现有的业务模块进行划分，因为业务模块之间存在许多交互，即会产生依赖关系，我们要根据我们所调查的业务范围的业务目标进行划分，一个目标对应一个业务边界。

（1）相关讲解

定义边界：根据一个业务目标对应一个业务边界的法则，确定该业务边界中所包含的涉众，并在涉众中确定谁为业务工人，谁为业务主角。

提示🛰：

确定业务边界：即进一步确定业务范围，确定该业务所对应的系统是为哪些涉众服务的。

确定业务主角（业务主角是参与者的版型）：

• 是否有对该业务进行信息提供、信息修改或信息调用
• 是否主动发起这个业务（即在边界中是否有其业务用例），这是其期望依据

确定业务工人（业务工人不属于参与者）：

• 在此业务中的动作是否为被动发生
• 不是业务执行的发起者，而是业务执行的一部分

（2）实践示例

根据第四个业务目标“实现学生信息管理、教务管理、考生结果管理统一化，规范数据库输入与输出流程，提供分权限数据限调用机制。”可知，该业务目标是为教务处和各院系服务，我们定以一个命名为“考务管理处理业务边界”。

该边界条件下，招就处、教务处、各院系都可以提出对考务相关业务处理优化的期望，所以作为该业务的业务主角位于边界之外。

2. 发现业务主角，确定业务工人

前后一致原则，我们在此处已经确定了谁是业务主角，谁是业务工人。但是我们之前对于业务主角的描述是站在业务边界的视角，在此我们是以业务部门进行说明，我们要站在业务主角的视角对其进行进一步说明。

（1）相关讲解

业务主角：此处的业务主角是具体的与系统直接进行交互的工作人员（或者事物），之前提到的业务主角是在边界的视角，所以是整个部门对边界的期望。此处是系统的直接使用者，代理了其它利益相关的涉众权力。我们应当从边界出发，分析每个边界的业务主角。

提问❓：为什么要进一步确定业务主角？

因为一个业务边界代表了一个业务目标，而一个业务目标代表的是该业务的业务主角的需求，我们应该围绕该需求进行后续系统的建设，我们甚至可以忽略业务工人的需求和期望，忽略那些和业务目标无关的期望。这样才能保证系统满足最本质的需求，不至于为了多余的需求导致系统混乱。

提问❓：为什么不直接说是系统参与者，要搞个业务主角？

因为还没到我们分析系统用例，进行系统建模的时候。站在B端产品经理的角度，我们最终的目的就是建设系统，我们的业务调研，需求调研也是大部分围绕系统建设展开。但是，正是因为如此，虽然我们现在“三句离不开系统”，但是此处用业务主角是要强调我们是在对业务进行分析，业务的优化和效率提升，才是我们建设系统的最终目的。此处的好处，即是提高我们深层次探讨业务的意识。

（2）实践示例

考务管理业务边界：

1. 教务处涉众主角分析教务处主要负责通过系统录入考生信息并进行考务编排，教务处的主要工作人员是教务处工作人员，负责考务编排、生成准考证等，行使了考官管理处理业务的职能，因此各院系工作人员是“考务管理业务边界”的业务主角。
2. 各院系涉众主角分析各院系主要负责考试相关安排。其中各院系工作人员通过计算机系统进行考试面试顺序、考场安排等，负责考务内部管理的职能，因此各院系工作人员是“考务管理业务边界”的业务主角。
3. 招就处涉众主角分析

招就处工作人员主要会在考务现场进行考生现场确认的工作，会通过考务管理系统查看考生的考试信息，因此招就处工作人员是“考务管理业务边界”的业务主角。

3. 获取业务用例，建立业务模型

我们从边界出发，分析了业务主角。那获取业务用例时，就可以从业务主角出发，去分析业务用例。

（1）相关讲解

业务用例：在确定业务范围时，我们已经分析了该业务的业务执行流程。此时，我们要从业务主角出发，调查他们的业务用例，即他们所做的事情。可以从岗位手册，业务流程指南、职务说明中获得。确定业务用例，即是确定业务主角的业务需求。业务用例是一个完整的存在，它包含了业务主角对系统的期望，业务主角在业务中要完成的业务，完成对应业务的目的以及期望的结果。

业务模型：应该包含：

• 业务用例视图：是对业务用例的罗列
• 业务用例场景：活动图描述、时序图描述、协作图描述
• 业务用例规约：对业务用例的名称、执行者、执行条件、执行过程、执行结果、业务规则进行文字描述
• 业务用例实现视图：一个业务用例可有多个实现方式，在此用实现视图进行列举
• 业务用例实现场景：根据业务用例场景进行进一步绘制，重点在于“实现”

（2）实践示例

①业务用例视图

②业务用例场景

4.  找到复杂问题，建立领域模型

领域模型就是发现业务某一领域中的复杂问题，分析这个问题，解决这个问题。建立领域模型就是为了将业务中复杂的问题解释清楚。

（1）相关讲解

领域模型：包含提出领域问题、分析领域问题、建立领域模型、检验领域模型

（2）实践示例

①提出领域问题

②分析领域问题

③建立领域模型

5. 获取非功能性需求，制定业务规则

（1）相关讲解

业务规则包含：

• 全局规则：对于系统大部分业务或系统设计都起到约束作用的那些规则
• 交互规则：交互规则产生于用例场景中，用例场景是由活动图、交互图等来描述，交互规则就是描述交互过程中的限制性条件，规定了满足什么条件后业务将如何反应
• 内禀规则：指业务对象本身具备的，并且不因为外部的交互而变化的规则。通常用来描述对象封装的属性

非功能性需求：非业务范围内的需求，通常指安全性、事务性、稳定性、流畅性、美观性相关需求。

三、需求分析

获取需求部分，我们从发现业务主角→发现业务用例→业务用例建模→领域建模→业务规则和非功能性需求。基本将需求梳理完毕，好像工作已经结束了，但是在uml中远不止此。因为虽然需求已经罗列，但是如果我们不进一步解释那些业务是重点和难点，到设计人员手中难免会出现信息失真的情况，为减少多余的交流，我们需要进一步解释需求的重点和难点。

1. 关键概念分析，建立概念模型

概念模式是围绕关键业务来建立的。

（1）相关讲解

①概念模型建立

过程包含：

• 获取概念用例：首先要梳理出业务主线，然后用业务主线的用例中挑选出关键或复杂的用例作为概念用例进行进一步分析。
• 分析概念用例：分析概念用例和业务用例建模过程相同，我们通过绘制概念用例的场景图找出关键的对象，然后为这些关键的对象绘制协作图说明对象之间的关系和交互场景。
• 建立概念模型：概念模型从抽象的系统对象视角来解释业务主线如何在计算机中运行，我们要用这些关键对象实现业务主线。一般采用MVC模式进行建立。

②实践示例

2.  建立业务架构，搭建整体框架

搭建业务架构和面向过程的结构化设计方法区别？

• 面向过程的结构化设计：按照业务模块进行系统模块的划分，得到子系统和模块
• 业务架构设计：从业务模型、概念模型中“抽取”业务构件进行组合，得到业务构件

（1）相关讲解

之前已经建立了业务用例模型、领域模型和概念模型，业务用例模型为我们解释了业务的细节，领域模型帮助我们为业务的若干问题提出了解决方案，概念模型提供了业务骨架的实现和软件架构的实践。业务架构从这三者出发，进行构建。

四、系统分析

很多人疑惑，产品经理为什么要做系统分析，我对产品代码实现又不太了解。正是因为产品经理不去向技术部门提出需求的系统实现要求，直接把需求丢给技术部门，这将导致技术部门设计好产品后不符合产品经理的预期而反复修改，从而导致程序员不断加班。所以产品经理做好系统要求后再让技术部门进行开发，将会大大提高工作效率，降低沟通成本和修改成本。

1. 确定系统用例，分析系统用例

普遍的理解是系统用例是从业务用例中细化而来。从用例的含义来看，业务用例描述业务，而系统用例描述系统，即它们的目的截然不同。实际上，从业务用例到系统用例，更适当的说法是抽象关系，或者说是映射关系。可以说是从业务用例中抽象出系统用例，也可以说把业务用例映射到系统用例。

即从业务用例中抽取出系统需要实现的用例。

2. 分析系统组成，建立组件模型

这一步我相信技术部门负责架构的童鞋应该会比产品经理更熟悉组件化开发，所以这一步可以省略。

五、系统设计

一般有产品经理岗位的公司，从需求到设计即是从产品到技术，所以这里不再讲解系统的设计方法，因为技术和框架的不断更新与变化，技术部门更懂得选用什么框架进行搭建。

所以：交给技术部门吧😜

参考资料：

【1】谭云杰.《大象——Think in UML》.北京：水利水电出版社.2016

本文由 @未来村村长 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Pexels，基于 CC0 协议