议时间;
4. 通过调研会议，需求调研和分析小组成员针对调研问题或新发现的问题进行讨论，达成一致的形成结论，由需求调研和分析小组成员签字确认，不能达成一致的，需求负责人整理形成备忘录提交到项目经理，由项目经理组织更高层的会议处理解决;一般调研会议需要反复召开多次才能把需求基本清晰化;
5. 系统分析员编写业务需求说明书。如编写过程仍有之前因为考虑不周遗漏的问题，则通过电话、会议等形式与客户沟通交流，之后的处理方式与第4点一致;业务需求说明书主要包括以下几方面的内容：
1) 业务概述。简要说明业务意义，何时办理，频率多少(如一天一次、一月一次等)等;
2) 业务流程。说明该业务是如何办理的，必要时通过流程图、序列图等图形化说明;
3) 业务规则。说明办理该业务有什么规则，需要满足什么条件等;
4) 输入信息。说明办理该业务需提供何种资料，需何种信息等;
5) 输出信息。说明办理该业务后会打印何种资料，产生何种电子化信息等;
6) 管理岗位与权限。说明什么角色的人可以办理或审核该业务。
6. 业务需求说明书编写完毕后，系统分析员提交给项目经理，然后组织内部评审会议。评审会议的目的是控制需求质量。评审人员包括实施部门内的系统分析员、其他事业部实施部门的系统分析员、质量控制部QA、测试人月等。主要从以下几方面评审：
1) 可读。从文档编写格式、语言表达是否有二义、是否使用过多的技术术语、客户是否易于理解、是否可以直接作为系统设计文档的基础等方面考量;
2) 完整。考量需求是否已覆盖了用户所有的业务需要;
3) 一致。考量需求是否与客户所要求的一致;
4) 可测试。从测试的角度考量需求中的业务规则是否可以明确无歧义的转换为测试用例;
5) 实现可能。从技术的角度考量业务规则是否能被满足，目前的技术是否支持等方面考量。
7. 内部评审通过后，通过邮件方式发送给客户需求负责人，同时抄送给信息部门相关负责人，明确反馈时间，要求客户对需求予以确认;客户如提出异议，则重复以上流程，直至达成一致;
8. 客户签字确认，建立业务需求基线。
值得一提的是，在迭代过程中，有时候为了加快开发进度，充分利用资源，可能获得客户口头上的确认后就开始进入后续的功能需求和系统设计阶段。
§1.2.4 开发功能需求
功能需求主要通过原型设计、原型展示和讨论、需求会议和评审会议等方法开发。在每一迭代开发的过程，我们按照如下流程开发功能需求：
1. 系统分析员根据业务需求说明书设计系统界面原型文档(Word格式);
2. 初级程序员根据系统界面原型文档开发界面原型。由于我们的技术体系基于J2EE，因而界面原型使用Web方式展示，原型文件为HTML文件;
3. 组织内部评审会议，主要从以下几方面评审：
1) 完整性。原型界面是否完全表达了业务需要，功能是否完备等;通常来说，如不完备但又无法使用原型展示的，都会建议在界面原型文档中补充说明;
2) 技术可行性。目前的技术是否支持，如不支持或实现难度较大有什么可替换方案等;
3) 操作简便性。界面设计是否合理，是否清晰展示了业务数据，是否便于用户操作等;
4. 内部评审完毕后，由项目经理协调客户评审，征求客户意见，该项任务一般由系统分析员负责。客户评审通过原型展示的方式进行，由系统分析员逐个介绍各个功能模块，包括界面的数据展示方式、操作方式，如弹出窗口确认、弹出查询窗口、如何输入数据等。通过原型展示，可以让客户看到未来系统的“样子”，便于及时发现问题，减少返工;在展示过程中，客户可随时提出意见或建议与系统分析员互动交流，最终确认界面原型。
5. 客户确认过程中，如对某些细节无法达成一致的，则形成问题日志，提交给项目经理，由项目经理组织更高层的评审会议解决，直至双方达成一致;
6. 确认的电子文档和纸质文档分别通过配置管理系统和档案系统进行归档。
通常情况下，我们以系统界面原型的确认以客户的书面签字为准。与业务需求说明书开发类似，在实际项目过程中，为加快开发进度，在取得客户口头、邮件或会议纪要的确认后，就可以组织开发人员对部分模块进行开发了。