深入理解需求分析的目标（C系架构设计法）

需求分析的目标：是尽可能准确、全面、深入的理解业务。

1：理解“尽可能准确”

首先，需求分析，要做的事，肯定是去理解业务，但是要达到什么样的程度，才算是我们理解了这个业务呢？

第一个是“尽可能”，尽可能的意思，就是你不太可能百分之百的、完整的、准确的去理解，做不到。我们只能说是尽自己最大努力去理解，理解性的东西，你不可能做到百分之百的理解这些业务。

第二个词叫“准确”，这个是特别重要的关键词。准确的含义就是：对每个功能点的理解要没有歧义，理解的这个功能点要不可再分，也就是说如果对一个功能点，不同的人有不同的理解，那这就是有歧义。

举个例子来说，当我们看到需求调研文档上有这么一句话，“这个用户数据需要在界面上进行选择”。出现这样的句子，这个就是不准确的，为什么呢？因为这句话他是有歧义的。

什么样的歧义呢？关键就在这个选择上，大家怎么选呢，是下拉列表选；还是checkbox选；还是像搜索框一样搜索参照去选择。你并没有给我一个准确的描述，所以说，你告诉我界面上可以选择用户，对于看文档的人来说，这就是有歧义的，不同的人他可以有不同的理解，这样是不行的。

当然，如果这个时候是配了原型界面，或者是有相应的html，上面已经准确的画出来了，他就是下拉列表，或者说他就是checkbox，这没有问题。但是如果单纯只有文档，这个就是有歧义的。

第三个词是“不可再分”。意思是这个功能点不能太大，不能说这个功能点还能够裂变成很多小功能点。如果他还能够裂变成很多小功能点的话，这个功能点的理解就是不够准确的。

比如说在文档当中来这么一句话：“要求能够对日志进行管理”。其实咱们最怕看到这种话，进行管理，怎么管？有些什么样的功能？是只对日志做一个保存，然后取出来进行查看，还有没有其他的真正管理性的功能？

这一个“管理”，它就可以再往下分出很多具体的功能。比如说，我还要把日志存储起来，又会涉及到要存储多长时间的日志；如何存储？是集中式的存储，还是分布式的存储；对这些存储的日志，有没有什么其他的功能要求，比如说查看，比如说审计，比如说进行数据分析，而数据分析，又涉及到要分析哪些东西？分析的算法是什么？

这些东西都属管理的内容，你光给我一个要求对日志进行管理，就这么一句话，你让架构师怎么设计？你让开发人员怎么开发？这就是不够准确。

看到这个地方，可能很多朋友就会在想，咱们自己的需求里头，看过太多这样子的坑了，往往是一两句话，就一笔带过了好大一个功能块，做着做着就发现问题了。最后为了去填坑，耗费出大量的人力和时间，咱可没少吃这样子的亏。

所以说，咱们现就要求，对于需求分析来说，一定要尽可能准确去理解。

2：理解“全面”

第二个，“全面”。这个比较容易理解，就是这个功能点，涉及到什么细节功能，涉及到什么样的流程等等的，都应该分析到，不要漏东西。这个咱就不多讲了。

3：理解“深入”

第三个，“深入”。这又有两层含义，一个就是对自己功能点的一个深入，另一个是功能点之间的深入理解，也就是功能点之间的关系。

对自己功能点的深入，咱们来个例子，比如需求文档上是这么写的：“这个价格可以被价格管理员修改，修改后要进行审核才能生效”，说的很清楚，对吧。但是你仔细往下去分析，就会发现问题了。

你看“价格可以被价格管理员修改”，这句话应该没啥太大的问题。但是修改过后要进行审核才能生效，问题就来了，既然是审核，谁来审核？审核有没有流程？审核过后的结果，是回到价格管理人员，还是直接生效等等的。大家一看就知道这中间是有问题的了。

有人可能会说，这好像是对审核功能理解不准确，不是我们说的最终的功能点，也可以这么理解。

这里强调的是深入，他有可能并没有流程，但是我们深入思考一下，要进行审核才能生效，那么这个时候我们就要求明确，比方说谁来审、如何审、审核结果对业务有什么影响、有没有审核流程等等的。我们一定要把这些问题，都要考虑清楚，这才是需求分析真正要做的。

需求分析，不是叫你表面上把拿到的这些需求文档读一遍，不是这样子的，你读完了觉得说这些字我都看懂了，然后大概意思也明白了，这样子的需求分析是不到位的。一定要一个功能点一个功能点的，准确、全面、深入的去理解才行。

因为在这个过程当中，你会发现很多不明确的地方，而这些东西，现在如果不把它找出来，这些问题就往后推延，就遗留到开发期间，光写这句话，程序人员根本没有办法去做的。

所以说，咱们越早分析清楚越好，这中间可能很多功能，需要我们在做架构设计，做概要设计、详细设计的过程当中，就需要把它考虑进去，而不是说把这个任务，一直推到程序人员开发的时候。因此，架构师在做需求分析的时候一定要分析的特别的仔细。

再来看另外一个点，就是功能点之间的一些关系的深入理解，可能在需求文档里面，并没有提到A功能和B功能之间有什么样的联系。但是经过我们的深入分析，发现他们之间是有联系的。

看个简单的例子，就来个大家熟悉的请假功能吧，当然请假是有流程的，但是这里假设它是一个单一的功能，比方说叫“短时请假”的功能。这个功能要求请假人填写请假单，然后由他的直接领导审核，他的直接领导批准了，这个请假就通过了，请假成功；不同意的话，也就是请假不成功，就这么简单。

但是这个功能，你仔细来分析，又有几个点，第一个，短时请假，请问啥叫短时？一天两天三天还是几个小时，这就意味着为了做短时请假，我们需要有一个配置这个时间限制的功能。这个时候就要想，整个系统里面有没有这样子的配置功能，能够去控制什么是短时请假，什么是长时间请假，是这个道理吧。可能由于这个分析，就引申出新的功能点来了，也可算是一个功能点之间的关系。

再看这句话，“由他的直接领导审核”。什么叫他的直接领导？可能有朋友会说，直接领导，不就是他所在的部门领导吗？那不一定，如果他所在的部门比较大，他可能是在某一个项目组里面，那项目组长或者TeamLeader算不算他的直接领导？

你看，这又引伸出来一个功能，就是能够设置每个人的直接领导。这个功能，通常是由组织机构和人员管理子系统来提供的，这就是功能点之间的一个关系，如果组织机构和人员管理子系统那边不提供这个功能，请问我怎么判断谁是他的直接领导呢？

这就是做深入理解，所以，需求分析要真正做好，不是那么简单的，是需要大家花很多力气，去认真、仔细、反复、深入的思考的。总之，大家需要理解，需求分析的目标就是：尽可能准确、全面、深入的去理解业务。就算咱不能百分之百做到，也要尽可能朝这个目标去努力。

为了大家更好的交流架构设计的思想和知识，大家可以加sishuok，拉你进架构设计群，一起共同学习，共同进步。