★对于一些复杂系统，客户可能很难准确地描述其中的业务，这时就需要需求分析人员亲身参业务工作，了解业务活动的情况。同时也可以请求查阅与现有工作相关或与原系统相同的数据记录，包括原始数据、账簿、报表等。但这些数据如果涉及企业商业机密，则必须征得主管领导的同意并为客户保密，这种方法可以比较准确地理解客户的需求，但比较耗费时间；
◆需求会议：
★在需求调研开始时，可以召开需求会议，请客户的需求各方参与，通过座谈了解业务活动情况及客户需求。在座谈时，参加者之间可以相互启发。另外，在需求调研经过一个阶段后也可以召开需求会议，对已经获得的需求进行确认，并告知客户后续的调研计划，这样可以避免因前面不正的结论影响后续的需求调研工作。在召开需求会议前，要明确会议需解决的问題 . 并做好充分的准备，不要让会议流于形式或脱离主题；
☉在需求调研结束的时候，我们需要得到一个准确的，经过客户确认的需求规格说明，需求说明书经过客户确认后，成为下一个阶段设计和开发的重要依据，是项目组成员理解需求的最主要的工具；
4、 需求规格说明书：
●在充分调研的基础上. 就可以开始定义需求了， 我们往往需要在软件项目实施合同中，明确定义要给客户做一个什么样的系统，客户要支付多少钱给我们。如果这时候对系统需求定义得不明确往往会引起纠纷或造成损失。如何明确甚至精准地定义需求，也需要专门的方法；
●需求规格说明书作为产品需求的最终成果必须具有综合性、必须包括所有的需求。开发人员和客户不能做任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明书，那么它将不能作为协议的一部分并且不能在产品中出现；
●需求规格说明书阐述一个软件系统必须提供的功能和性能，以及它所要考虑的限制条件，它不仅是系统测试和用户文档的基础. 也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为，除了设计和实现上的限制。需求规格说明书不该包括设计、构造、测试和工程管理的细节；
●近年釆，随着软件工程的不断成熟，在一些 Web 开发中，有人提出不需要编写需求规格说明书，而使用原型代替， 采用快速迭代不断完善系统功能的思想。 这种做法符合敏捷开发的要求，在一些企业自已开发的系统、小型系统或简单 Web 应用开发时，合理使用确实可以提高开发效率。但对于大型的、复杂的系统或参与部门和人员众多、开发周期较长的系统，还是要有完善的需求规格说明书；否则在开发后期可能会出现需求混乱、项目管理失控的局面；
5、需求规格说明书文档结构：
●需求规格说明书模板是编写软件需求文档定义的一种标准模板。该模板为记录功能需求和各种其他与需求有关的重要信息提供了统一的结构；
●结构如下：
1、综合描述：
1）、软件的概述：这里需要描述软件的背景。例如，软件是否是目前正在使用的软件的升级版本，是否是某个大型系统的新增部分，是否与其他系统存在某种联系等
2)、产品的功能：这里不是详细描述软件的功能，而是从业务层面描述软件的主要功能即可. 也可以采用图形的方式表现。
3)、用户及特性：需要确定使用该软件的用户类别，并且描述他们的特征，往往有些功能只和某些用户相关户，权限管理只和超级管理员有关，普通用户不涉及权限管理，再如，用户有没计算机操作基础，这决定了后续软件要满足易操作性和要为用户提供必要的培；
4)、运行环境：需要清楚软件运行的环境，一般包括以下几个方面：
★硬件平台
★操作系统及其版本
★支撑系统，如数据库的类型和版本
★与该软件共存的应用程序
5)、设计和实现上的限制：设计和实现上的限制主要用于限制和规范软件开发人员，例如：
★必须使用的特定技术、工具、编程语言和数据库
★不能使用的特定技术、工具；
★必须遵守的开发规范和标准
2、外部接口需求：