需求的表达：能用图讲的就别用文字。
统一建模语言（UML，UnifiedModelingLanguage）是面向对象软件的标准化建模语言。UML因其简单、统一的特点，而且能表达软件设计中的动态和静态信息，目前已成为可视化建模语言的工业标准。
UML统一建模语言建立了一套采用图解需求的标准方法，用它来解析和呈现业务需求，就能事半功倍～接下来详细说下需求文档中用图说到的事儿。
用流程图呈现业务流程
先简单讲讲画流程图的需要知道的基本元素
组成流程图的元素
流程图的基本元素.png
- 开始/结束 Begin/End
用于描述一个流程的开始和结束。 - 活动Action
是描述一个业务流程中最基本的步骤，用来描述对象的一个动作，比如一次点击、一次选择。 - 判断Judge
用于描述业务流程中需要根据条件进行判断的步骤，比如系统根据数值大小系统会提供有不同信息。 - 子流程/其他流程Subflow
比较复杂的流程图往往是先用一个比较大的粒度（称为一级流程）先去描述的，因为在这些流程中，往往会包含一些子流程，在一级流程中，不便将子流程的细节展示出来，就可以先用它来表示。 - 连接线Connection line
用于连接活动，并指明下一步，更重要的是，在连接线上，还可以填写一些额外的信息。
用“在超市购物完后结账时的流程”举个🌰：
基本步骤.png
由于大家对这个超市结账的流程都比较熟悉，可以脑补出以上步骤所对应的角色，但是面对千千万万的业务场景，可能用以上简单的步骤图就描述不出来了，接下来简单介绍可以用到的泳道图。
结合泳道区分流程中的角色
在描述流程中活动的时候，可以使用泳道来区分角色即“谁做的什么事情”。如图：
用泳道区分角色.png
实体关系图
产品经理在了解业务的流程后，为了便于后续的产品设计工作，还需要关注业务中的数据关系，接下来简单讲下可以用到的实体关系图。
E-R图为实体-联系图，提供了表示实体型、属性和联系的方法，用来描述现实世界的概念模型。实体关系图表示在信息系统中概念模型的数据存储。
实体关系图，又称做ER图，用来描述实体间的数据关系。
ER图.png
以上ER图（只画了一部分实体关系，像账单等实体省略掉了）表示：
- 一个营业员可以为多个顾客执行结账流程
- 一个顾客可以购买多种物品
- 一种物品也可以被多个顾客购买
- 一个营业员也可以扫描多种物品
产品经理在需求分析时，还需要理清每个实体的属性，也就是对于一个实体【顾客】，它有哪些数据属性，比如顾客的手机号、性别、年龄、是否是VIP等等。B端产品经理经常会设计配置后台等产品，用户在配置后台进行创建、删除、编辑、搜索等操作就是对数据的CRUD（增删改查），理清了这些数据属性，我们可以试着从数据角度进行需求的探索，即对需求进行查漏补缺。
举个🌰-账单实体：
- 创建：顾客结账，收营员扫描完该顾客的所有物品时，生成一份账单。
- 修改：收营员在扫描错误物品时，会有编辑的需求。
- 删除：对于收营员或顾客来说，好像没有删除的需求。
- 查询：当超市的会计对某份账单有疑问时，可能会有搜索的需求。
数据流图
数据流图可以呈现数据的扭转，用户在系统中的每一步操作可以说都存在数据的输入和输出，了解这些不仅能让产品经理自身更清楚产品的功能和范围，还能跟开发更好地沟通。完整的数据流图难度较大，一般不做要求，有兴趣的可以去了解数据流图。
需求文档的内容结构：
- 需求名称
- 背景
- 目标/收益
- 功能需求
- 业务概念
- 流程展示
- 需求描述
- 非功能需求
需求名称
概括性地描述这是一件什么样的事情以及要实现的目标，这可能是产品的名称也可能是项目的名称。
背景
背景主要是说明为什么要做这个需求，通常是说明现状及现状带来的问题。
目标/收益
讲清楚做了这个需求后预计达到的目标或是收益，比如能赚多少钱、能节省多少人力等等
需求范围
在这里可以把需求以列表的方式概括性展示出来，可以让团队成员大概知道这些需求包含哪些内容，便于后续评估工作量。
功能需求
业务概念
这里需要放上实体关系图，以及每个实体的属性，有助于理清业务概念，也可以帮助开发拿到需求后设计数据结构。
流程展示
这里需要放上流程图和数据流图，用于描述业务流程和数据扭转。
需求描述
这是文档的核心部分，在这个阶段描述需求时，建议不要描述界面相关的内容，避免增加文档的复杂性，以下是对一个需求/用例的描述。
| 内容 | 描述 |
|---|---|
| 名称 | 用例的名称叫什么，比如：结账 |
| 角色 | 谁在系统中使用这个功能 |
| 前置条件 | 用例的前提条件，或者系统正处于什么状态 |
| 需求描述 | 对需求内容的描述，可以是操作成功的正向流程，也可以是操作失败的逆向流程。 |
| 后置条件 | 操作这个用例后，信息是否改变。 |
| 备注 | 可以填写一些备忘或需要注明的信息 |
非功能需求
除了功能性的需求，非功能需求是用户指对产品的期望，举例说明：
- 功能适应性
- 功能完整性
- 功能适当性
- 功能正确性
- 性能效率
- 时间特性
- 资源利用率
- 容量
- 易用性
- 易学习性
- 易操作性
- 用户错误防御
- UI美观
- 可靠性
- 容错性
- 易恢复性
- 安全性
- 保密性
- 责任
- 可维护性
- 可复用性
- 易修改性
网友评论