正在做的项目是与国企合作的，虽然国企给一般人的印象是高傲，嚣张，事实上我体验也是这样。除了对乙方的态度外，国企对于工作的态度是非常令人钦佩的。

最近工作出了很多问题，大多数都是自己当初幼稚导致的。幼稚的文档导致今天无尽的纠纷。下面来聊聊需求文档的作用。

记录甲方的原始需求

甲方的需求一般是很模糊的，总是用几两句话即可描述出来那种。这几句话既是原始需求，也是核心需求。原始需求是因为甲方没有考虑到系统的现状是如何的，也没有考虑到现实的情形是多么复杂多变的；核心需求是因为甲方利用这几句话言简意赅地表明他期望的最小开发实现。

产品经理无需考虑原始需求的更改，但是要记录甲方的原始需求，作为需求文档的一部分。

分析原始需求

原始需求背后都有其核心诉求。按我接触的来说，一般的核心诉求会有：提升业务办理量、减少投诉、减少报障、拓展业务渠道等。原始需求是核心诉求的表现，而且核心诉求并非一定要按照甲方给出的原始需求来表现。

分析原始需求，寻找核心诉求可以让产品人员更加容易找到原始需求中的隐含需求及场景，考虑得更全面。

梳理系统现有功能与逻辑规则

系统现有的功能以及逻辑不一定会完整地支撑整个流程，因而需要对系统现有功能与逻辑进行评估。这一步的分析及其重要及其困难，重要是因为结合业务流程及系统现有功能逻辑，可以梳理出功能需求，包括需要实现的或改造的。困难的是，第一，如果系统过于陈旧，复杂，或由多个子系统组成，对新手设置了高门槛，导致新手一时间难以吃透系统，更别提对系统进行改造了；第二，系统过于复杂，改动难度更大，方案更难梳理，出具方案时会有更多细节难以设计，系统故障风险也就越大。

我曾经参与过一个需求的开发实现，由于当时我是新加入的，对许多子系统不甚熟悉，功能设计时，没有将子系统、子模块考虑到位，导致规划的功能有许多遗失。需求上线后，相关报障逐渐增多，甲方也频繁召集各方开会，对我方的信任感也逐渐下降。

描述业务主流程

使用UML活动图、UML状态机图、泳道图、BPMN图等方式描述业务的主流程，并使用最少的文字精确描述业务流程。

甲方一般只愿意看业务流程图，因而业务流程图非常重要，是让甲方确认我们是否正确了解其流程的重要工具。

梳理功能性需求

功能性需求指的是为了实现流程，开发人员必须要对系统功能新增、改造的部分。开发经理会根据功能性需求以及业务的具体要求，建立开发进度表，详细评估每个功能开发的工作内容，优先级，负责人、开始时间、工作量、完成时间，输入物、输出物等信息。

一般来说，功能性需求可以描述系统需要实现什么功能，供什么角色的用户使用；如果想要更进一步，可以附上明确需要输入、输出的信息，展示相关原型等。该部分可以逐渐在需求推进过程中完善。

注意，有些功能并不是必须要马上开发的。

没有技术背景的产品经理常常无法评估需要实现什么功能，改造什么功能，但是可以大概梳理需要实现的功能模块，交给对系统较熟悉的开发同事重新评估。

梳理非功能性需求

非功能性需求是指无需开发，但需要其他相关部门协助的一些需求，这部分需求实施之后，功能性需求才可以正常运转。

根据我的经验，一般的非功能性需求就是数据初始化：由于部分功能新增会涉及部分属性新增，需要初始化该部分数据；

为满足该部分需求，产品经理需要主动协调其他部门或公司，利用资源，充当牵头人的角色，并监控项目进度。如果该部分需求没有实现，可能会导致功能使用有问题甚至不可用。这部分需求一旦确定，往往就需要马上进行，确保在功能性需求完成之前完成。

梳理并评估风险

无论流程设计得如何完美，需求新增总会有风险存在，很多都是超出意外的。例如，由于权限设计不当导致的数据泄露风险，用户不了解逻辑导致投诉增加的风险，用户输入格式不规范导致的系统数据错乱风险，需求本身的流程设计导致的风险等。

需求文档需要列举所有的风险，预测风险出现的可能性，影响范围，并给出风险预防方案，风险发生后的临时方案，最终解决方案。当一个项目涉及多方时，风险的预测及记录非常重要，这是保护自身利益的方法之一。

记录其他内容

需求文档也需要列举其他内容，记录下版本详细变更情况，需求涉及的人员及联系方式，需求文档中涉及的术语及其解释，附录，需求变更记录，需求答疑等等其他部分。