无论是互联网产品还是IT项目，所有这一切的开端都始于需求分析，一份好的需求文档往往是项目成功的先决条件，对一个IT产品经理或项目经理来说就显得尤为重要。如何才能写出一份让客户，开发人员都能读懂且满意的文档？

掌握需求分析的方法

需求分析的方法，是写好一份需求文档的内功；毛主席曾教导我们说“没有调查就没有发言权”，那么一份凭空臆想出来的需求文档，最后的结果也可想而知。需求分析也有各种方法，但终究起目的都是解决下面4个问题。

谁提出的想法？要解决什么问题？ 需要哪些业务来处理这个想法？ 这些业务是由什么信息支撑的？ 这些业务的支撑需要什么样的环境？

接下来，我会以“XXX校园安全平台的需求”为例，其原始的信息源如下，通过需求分析的方法来回答上面的问题。

XXX学校，希望对学生的出勤率，归寝情况进行统计；并希望使用信息化的手段，对学生的请假进行管理；而且学校了解到，现在的AI摄像机能进行人脸识别，希望能运用到新系统中，成为他们学校安全的一个亮点。

方法1：梳理出需求涉及的人员、组织机构及他们的诉求和职责

在围绕校园安全的需求中，大多数人都能分析出如下角色及职责：

但是这里他们犯了一个错误，混淆了客户与用户的概念。以上分析只是站在使用系统人的及（最终用户）角度来进行的，但是要知道最终付钱的（客户）还有想法的，所以上面的角色及职责应该还可以扩展成如下的表格才较完整。

上面只是通过原始信息源分析得到的，在通过不断需求访谈或挖掘中，你会发现的人员角色还在不断的扩展，这种就是通过人员与人员之间关联来的到的。所以最终的角色表大致如下：

组织机构图如下：

由上可见我们要避免如下错误：

不要混淆了用户和客户的概念，优先考虑客户，因为钱是他付的，想法是他提的； 用户角色的梳理中，需要考虑到关联的人员是否也有可能在系统中；例如学生—家长，学生—保安

有了上面的角色，业务及业务流程就有了来源，我们就可以开始来回答第二个问题了。

方法2：找到支撑这些诉求及职责的业务或业务流程

什么是业务了？我的理解一般就是大家平常说的做事的流程或者做事的步骤。一般情况下我们可以根据用户的诉求就梳理出大致的业务及流程，再通过一对一的访谈就能达到你想要的业务。

根据上述的用户角色及诉求，我梳理了如下的业务。这里只做部分列举，不做详细说明。

学生出勤业务：学生上学通过AI摄像机进行到校，离校签到，系统记录相关数据。 学生归寝业务：学生上学通过AI摄像机进行归寝，离寝签到，系统记录相关数据。 学生请销假业务：学生在系统进行请假申请，提交到班主任处；学生凭借假条出入学校。

注意事项：由于信息化系统的引入，很多原有的业务流程需要再造。

例如在学生请销假业务由于AI摄像机和平板的引入其流程就会再造，再造后的流程如下：

学生在系统进行请假申请，提交到班主任处；或由班主任直接创建请假申请；通过后学生在非上下学时间离开时，AI摄像头识别到该学生后，会在门卫的PAD上显示该学生的请假信息，核实后允许其离校，离校时会将信息推送给家长。

考虑业务流程中的异常业务

大家分析业务时，都是正常流程很容易，但是一定要考虑其异常流程的处理，因为谁都没有一直顺的时候，例如下面这个异常业务。

学生归校异常业务：学生请假时间已过或未经请假就出校后归校，这个对于正常的请销假业务而言是个异常业务了。 学生未按时归寝业务，这个也是归寝业务的异常业务。

复杂业务使用流程图更直观：有些业务比较复杂，这个时候使用业务流程图可以很清晰的表达出该业务，与客户沟通时可以取得事倍功半的效果。

找到支撑业务的数据信息

任何业务离开了数据信息，都是瞎说，所以发现业务背后的数据很重要，那么数据从何而来了？

收集客户日常流程使用到的单据：

角色日常工作我们经常会看到各种单据，具体到本文中，我们至少可以发现下面两种单据，学生的假条，访客进校的登记表，宿管查寝的登记表等。

跟踪客户的日常工作，找到他们用到的非正式表格

注意事项：原始表单并不能直接放入到需求中，需要加工成数据字典。

例如请假条：

我们要把他们转换成对应的数据字典或表格如下图所示：

梳理要实现以上业务的环境

按理说，完成了以上的业务梳理后我们对需求有了很深入的了解了，能写出较好的需求文档了。但是我们还要考虑实现这些的业务的软硬件环境，外部接口。就本例而言需要考虑如下的环境。

政策环境：

公安局对校园安装摄像头的要求 教育局是否有对校园安全的政策文件等

系统运行的环境例如：

服务器是物理服务器还是云服务器； 操作系统使用的是Linux还是，Windows的某个版本 数据库需要使用Mysql Oracle Sqlserver的哪个版本 物理服务器是否需要硬件防火墙，是否需要牵专线

外部接口：

罪犯的人脸头像库如何提供 学籍信息，教师信息，年级班级信息如何提供

通过需求分析，其实我们已经掌握了很多的业务，流程，角色信息等，我们或多或少也使用了一些文档，例如需求访谈表，文档最终的目的是减少沟通的成本，确保能清晰的解释需求。

如果说需求分析方法是写好需求文档的内功，那么规范专业的文档目录及内容，则是写好需求文档的外功。再好的内功，只有使用恰当的外功才能发挥其效果。

需求文档

这里主要介绍三种需求文档的模版及其作用：

原始需求访谈表—记录用户最原始的需求文档； 需求规格说明书—对现有业务整理或流程改造后的系统需求文档； 需求清单及功能结构脑图—用于时间人力等资源进行估算成本计划。 1. 原始需求访谈表记录表

我们在与用户沟通交流时，每次都有必要做好需求的沟通记录。有了该文档，我们每次的需求访谈的效率和质量才会更高，而避免不必要的瞎扯，浪费大家时间。

需求的访谈记录的格式可包含如下要素：

2. 需求规格说明书

需求规格说明书是对原始需求进行加工后，可供开发使用的文档，所以需求规格说明书的需求是高于原始需求的，对原始需求中的某些内容进行了增删，确保按照新系统的方式进行的业务能满足用户的需求。

好的一份需求规格说明书会节省开发系统设计的大部分时间。需求规格说明书应包含如下结构：

3. 需求清单

需求清单是根据需求规格文档，按子系统，模块，功能进行分解后的功能清单；可以通过脑图进行分解展示，也可以通过Excle文档进行分类确定。

使用脑图便于分析和讲解：

使用Excle文档，方便统计和时间估计：