对于企业管理软件开发过程中的文档，我们一般有需求分析说明书，其编写格式和思路，和我们的需求调研方法一致，也是说，我们的需求调研的结果，落实到纸面，有需求分析说明书，另外还有一份需求调研报告，是偏向于项目过程叙述的。

需求分析说明书回来，研发部内部会进行大家一起学习理解，然后讨论。

讨论主要由：需求调研人、业务组组长、测试组组长来参加。一个个的过流程。因为在需求调研期间，去的只是调研人，可能有想不全的地方。如果这样直接进行开发，无疑会有很多漏洞。这样给开发、测试，都带来了返工修改，给项目管理也带来了项目进度、任务分配的调整，计划的打乱也间接影响了质量管理。

根据大家讨论补充后的需求分析说明书，比较容易得到我们下面环节的文档。

首先我们会出功能点文档。

我们会把需求分析说明书中的业务功能都列出来清单，属于组织结构建立、组织角色、权限分配、登陆验证、基础数据维护之类的都归类到系统功能中。系统管理，各个企业管理软件差不多，我们又有公共的系统管理模块，不需要重新发明轮子了。所以，我们主要重点是分析业务功能。

根据需求分析说明书中的每个流程，都先提出来成为一个功能点。然后针对现在整理出来的功能点，再一个个对照流程，如果这个流程复杂，拆分，把这个功能点拆成几个复杂性和预估工作量差不多的功能点。经过这样的拆分，形成了终的功能点文档。

而功能点之间，根据上述方法的拆分，形成了功能群。

功能点成为功能权限控制的小单位。功能群成了软件菜单中的一项。几个相关联的功能群成为了一个业务子系统。

这样的方法，使子系统-功能菜单-功能点（可能是某个功能窗口上的功能按钮）三级分开，与组织结构-员工-角色-用户-权限结合。一个软件，未来会成为什么样子，大框架出来了。

做功能点清单，类似于跑马圈地，这个项目到底多大，我先把项目边界框起来，而不要让这个项目无边无界，那自然也不会有可落实的项目进度和项目管理。知道了项目大做到多大，能决定是亏是赚，是做还是不做，能不能做了，有可用的时间和人力来做否。

然后，我们会根据功能点清单，为每一个功能进行优先级的标示。我们通常会把优先级分为三级。这意味着一个项目，大致分为三个阶段。一级是必须要做的，即使延期也要做，必须调度多加人手多加班也要完成。一级做完后，如果有时间，把二级完成。如果时间超期，有适度的尽量去完成二级，可以延期，但也要根据预算和时间。如果适当延期也无法完成，我们会给客户去上线实施，变实施边并行开发，使实施团队和开发团队进行并行工作。所以，二级也是重要的功能。三级是如果时间用完，三级的功能要舍弃掉不开发。

一般是，按功能的重要性来划分优先级，我们在之前已经讲过，我们调研需求的时候，把常用业务和异常业务分开，把每天做的业务，和每周、每月、每季、每年做的业务分开。几个结合特别紧密的，互相关联的，我们也会把他们划分在同一个优先级，需要单独开发的基础数据维护界面，我们也会放在同一个优先级。这样，只要我们项目到期，或者我们迫于竞争突变，我们会随时推出一个可以完整使用的系统。虽然这个系统可能功能简陋，但可以完整处理整个常用业务流程，而不会造成中断，无法处理下去。

很多开发团队，开发的方法是先字典功能，然后是业务功能，然后是报表。这种开发方法导致了很多业务系统，客户上线使用了，光输入数据，没有输出，业务系统成了一个闷葫芦，用户得不到使用价值，可能只是减轻了工作量，加快了工作效率，提高了部门间的自动配合。更有甚者，业务功能开发了一半，到处都是断路，走不下去，无法成为一个完整的系统，是个半成品，上不上下不下，无法适应竞争变化。