写给需求经理的建议书

一、大家心目中的需求

1.       客户：对他们业务描述正确的、详细的需求，需求所描述的系统能真真正正解决他们的问题，切切实实让他们省力省心。

2.       开发人员：通过需求能最清楚的知道业务的流程和系统的样子；需求无歧义，按照需求开发出来的系统是客户想要的；容易实现，比如不要为一个可有可无的字段写很多程序，查很多数据库表。

3.       需求人员：用最少的文字、最简单的图表描述清楚业务和系统，让客户满意，让开发人员和测试人员清楚系统的样子。

二、谈谈开发人员想要的需求。

现在的需求已经非常的好了，我求全责备总结了以下几点建议：

1、  集中描述：

由于种种原因我们的需求很厚，开发人员是不希望看到二三百页的需求，所以折中，建议把开发人员关心的部分集中描述，可以集中在两个部分，不看仔细研究其他部分也不会遗漏规则。

（1）       系统通用规则部分，在这里把所有系统共性的东西描述清楚，比如日期格式、权限控制、数值精度等等。

（2）       功能分析部分，在这一部分中，

Ø         模块业务流程图，能做到描述清楚业务逻辑，尤其是复杂的，不是常规操作的更要详细描述，如果画图困难可以在业务规则中用文字补充详细。

Ø         数据描述（界面元素说明部分），这部分非常好了，但是很重要所以强调下：输入输出描述清楚、输出的数据来源描述清楚、非部标的字典描述清楚。

Ø         业务规则，这部分是最核心的业务描述了，开发中最多的时间是耗在这部分的实现上。建议如下:

A.        不要出现“业务规则同其他规则”的描述，不要出现“在其他业务规则上增加以下规则”的描述，如果规则有交叉，建议把规则拷贝过来不要引用位置。

B.        规则的描述与“数据描述（界面元素说明部分）”要保持一直。

C.        对于日期、年龄、天数等数值范围的描述要清楚，是否含当天这类有歧义的地方要说清楚，复杂的最好举个例子。

D.       规则描述的顺序要合理，尽量按照页面上的“查询”、“新增”、“修改”、“导入”、“导出”等操作顺序描述。

2、  需求评审：

对于业务较多、较复杂的需求，复杂报表类的需求。通过开发人员看需求，然后再用两三个小时去评审，对于及时发现问题和让开发人员完全理解需求是不够的。建议需求人员先讲解需求，开发人员研习需求，最后需求评审。由于开发人员能否完全理解需求人员所描述的需求对于开发出成功的系统很关键，对于复杂的系统又不可能用文字描述的没有遗漏没有歧义，所以建议在需求评审上增加需求讲解这个步骤和评审的时间。

3、  开发过程的需求问题

开发过程中最能看到需求的问题，尤其是那些深层的业务规则是否有问题，规格说明书各个部分之间是否有矛盾，往往是在开发时才发现，但这时需求规格说明书客户又已经签字，不能来来回回的修改需求说明书，但这些问题很重要必须记录下来，口头上交流很容易遗忘漏掉，所以建议用规范的文档记录下这些变更，方便以后测试和一次性补充修改需求规格说明书。

   4、上线维护期间的需求问题

           上线后客户往往发现系统不完美，这个地方优化下，那个地方改变下，即使我们需求变更的问题不修改，但时间一长优化的问题一多，需求和系统差别就大了。如果以后再按照新的政策，在原来的系统上开发新系统就会出问题，尤其是在系统和需求不一直的时候再去提交测试，这时候测试部和配合测试的人员就浪费了很多时间纠缠在需求和系统不一致的缺陷上。所以建议上线后也要有规范的文档来记录系统的变更。

  总之：需求人员能准确的通过需求规格说明书描述客户的需求，设计出功能全操作简易的系统；开发人员能清楚的了解需求所描述的系统，开发出和需求一直的系统；需求规格说明书和需求变更记录形成需求体系，这个体系与我们系统保持同步性、一致性。