写在前面

终于写到这个系列的最后一篇了……
让我算算，第一篇是上个月发的还是上上个月发的？

因为时间太长，所以我们先来回顾一下为什么要写这个系列。

我认识的很多团队都是在敏捷的方法，近些年来，这类快速迭代的开发流程在整个圈子里面迅速的流行起来。
不管是出于为了快速交付、快速验证、还是不写文档等诸多原因。
不知道大家在执行敏捷过程中，特别是作为BA或者产品经理，发现有个问题。
这么多用户故事，这么多高内聚低耦合的用户故事，你有办法组织在一起吗？

其实我一直在考虑一个问题，就是敏捷执行一段时间后，如何能保证不偏离当初设定好的目标。
有人说，我们就没目标。
是，可能刚开始做产品并没有一个非常清晰的目标，比如我要做个共享单车，比如我要做个共享女友。
但是总会有个愿景或者是想要解决的问题。
我想要解决从家到地铁的500米距离的问题，我想要结束单身狗的命运……

而且在评估一个需求或者用户故事是否重要的时候，也很纠结。
因为目标和问题不明确，所以也不知道到底重不重要。
于是最后很可能演变成功能的堆砌。

连产品经理或者需求负责人都有这种感受的话，就更别说其他干系人了。
这种只见树木，不见森林的方法，想想可能引发的后果，就有点“不寒而栗”。

我不是来抨击敏捷的，因为我发现即便你用瀑布，可能也会有同样的问题。
你同样会进行需求的拆分，类似拆故事一样。
形成需求矩阵或者需求树进行管理。
但是顶层需求之间有什么样的关系，和你的整体目标以及要解决的问题有什么样的关系，这个估计也会有欠缺考虑的时候。

最近很巧的，看了三本书，介绍了三种方法，从三个不同的角度，都是为了解决同样的这个问题：
“只见树木，不见森林”。
第一本：用户故事地图
第二本：软件需求设计
第三本：软件需求可视化模型

软件需求可视化模型概述

一提到模型，大家可能会想到UML。
但是正如《软件需求可视化模型》提到的，UML还是会有点偏向技术的视角来进行建模。
优点是面向对象，设计的考虑比较全面和清晰。
缺点就是，很容易在业务还没有弄清楚的情况下，陷入技术细节，并且缺乏应对业务价值等方面的建模。

在系统工程领域，模型分为：概念模型、逻辑模型、物理模型。
我的理解，UML更加偏向于逻辑模型。
而从UML衍生出来的SYSML，也更加偏向于逻辑模型。

需求可视化模型使用RML（需求建模语言），主要是针对软件需求分析使用的，而且便于业务干系人理解，便于快速转化为UML等开发设计人员可以理解的模型。
而RML的模型覆盖比较广，使用的面向对象和面向过程两种分析方法的融合。

模型分类

RML主要分为四类OPSD，从四个视角对需求进行分析和描述。

O： Object 目标模型

主要用于描述系统的业务价值，并且根据系统的价值设置功能和需求的优先级。
它比较特别的地方在于将功能与业务目标联系起来。
通过建模，理清WHY，为什么要做这个功能，是要实现什么目标，带来什么价值……

目标模型中包括：业务目标模型、目标链、关键绩效指标模型、特性树、需求映射矩阵。
目标模型的主要思路是：
通过业务目标模型进行业务问题分析，为了解决这个问题，我们想要达成的目标是什么。

有了目标之后，我们通过目标链模型定义衡量目标成功的指标有哪些，这些指标可否量化计算，数据怎么捕获。

为了捕获这些数据，我们所需要建立的特性是什么。
有了高级别的特性，我们通过特性树（其实展示出来就是鱼骨图）来进行特性树的分解。

特性关联了功能、关联了需求，从而建立需求映射矩阵。

这一整套分析下来，你会很有底气的说，我们为什么要做这个需求。
在未来进行解决方案效果评估的时候，你也有相应的指标以及数据支撑。
到底这个解决方案能否解决问题，能解决多少问题等等。

P：Person人员模型

主要用于描述干系人以及他们的业务流程和目的。
我们常见的组织结构图（Org Chart）就可以归为其中的一个模型。

RML提到一个非常重要的观点，就是模型的相互验证。
比如我通过Org Chart去识别干系人，角色。

那么在进行处理流程模型建立时，我需要对照着Org Chart进行检查，有没有角色和人员的遗漏。
在进行用例编写的时候，通过OrgChart和处理流程，相互检查是否有过度的设计或者遗漏。
包括后面的角色权限矩阵都可以利用之前模型的数据进行项目的校验。

跨模型也可以进行需求的校验。
比如上面提到的目标模型里面有个需求映射矩阵，可以关联验证我们的OrgChart，用例，角色权限以及处理流程。

S：System系统模型

主要用于描述存在什么系统，用户界面是怎样的，如何交互，如何响应。
这类模型在UML中有部分对应的上下文图、组件图。
但是还有很多模型在UML中是没有涉及的。

比如，决策树和决策表，可以分别用来处理复杂的判断和业务规则。

打个比方，我们要实现一个业务逻辑，里面有很多的if else。
你可以想象一下，如果你使用用例来进行描述，分支可能会有6、7层。
写的人晕，估计看的人更晕。
而使用决策树就可以很好的解决这个问题。
非常清晰的展示先校验什么，什么校验结果走哪条分支等等。

D：Data数据模型

主要用来描述从最终用户的角度看待业务数据对象之间的关系。
注意，不是数据库设计，而是从最终用户，从业务的角度进行分析。
干系人想要用数据来做什么，数据是怎么传递和计算的。
干系人关心的数据方面的信息，通过这个模型进行分析、展示和说明。

一提到数据模型，大家想到的无外乎数据流图、数据字典、实体关系图（E-R)。
这里我想要分享的是BDD，业务数据对象模型。
这个模型其实是E-R的简化版。
我们都知道E-R是用来进行数据库设计的必备工具，而UML的类图其实也有类似的功效。
但是，对于我们BA来说，我们的设计其实并不会涉及到数据库表以及相应的操作设计。
我们对这方面不专业。
数据库设计是一门很专业的很深的学科。
不同的表设计会影响性能、可扩展、可维护等等方面。
我们BA很难做到很专业，而且这也不是我们的强项和职责范围。
专业的事情留给专业的人员去完成。
我们需要做的是，从业务的角度进行对象的分析和阐述。

BDD最终看上去很像简化版的E-R，但是BDD只会作为数据库设计的输入，而不会作为最终数据库设计的方案。
我们只是在描述，有哪些业务数据对象，他们的关系，他们可能出现在什么处理流程，什么系统流程，哪些界面上。
而至于具体的实现以及技术设计，BA不会做决策。

需求架构

这个词我倒是第一次看到。
在BABOK里面其实有提到过，BA需要在开展工作前进行一些规划，以便指导后续的相关工作。

需求架构其实就是策划需求工作如何开展的过程。
比如RML这么多模型，是否在这个产品，这个项目中全都使用？

如果要使用一部分模型，那么顺序是怎样的？输入有哪些？

模型的相关性

在前面也有提到，RML的诸多模型是可以相互验证的。
这样更有利于让我们从整体到部分，从一个角度到另外一个角度进行需求的透彻理解和分析。

几乎每个模型都和其他多个模型有关联、验证关系。
我觉得这正是我们作为需求分析目前很欠缺的，又十分重要的部分。
使用RML，你可以从不同的角度看待问题，并且保证自己的整个解决方案是说的圆的。

只是说，建模是需要耗费精力和时间的。
但我觉得十分值得。

写在最后：

其实这三本书正如我开篇提到的，侧重点是不一样的。
用户故事地图我觉得比较适用于从0到1的小型项目。
软件需求设计更侧重于需求过渡到架构的设计。
而软件需求可视化模型适用于中型、大型的项目，经过裁剪后也适用于一些小型的项目。
但是软件需求可视化模型更加适合于目标比较明确的项目，对于探索性项目可能不会太合适。

另外，吐槽一下《软件需求设计可视化模型》的翻译。
感觉前半部分和后半部分就是两个人翻译的。后半部分的章节层次错乱，并且就像是翻译软件翻译出来的那样生硬。