4、Define阶段

　　4.1 准备

　　活动：了解discover阶段的输出文档，安排交流的客户代表

　　职责：市场人员帮助开发项目经理了解可行性分析报告中的内容，并共同联系客户代表；开发项目经理理解可行性报告中的相关内容，为后面工作的开展作好准备。

　　4.2 分析项目目标和成功因素

　　活动：通过与客户的沟通，定义项目目标和成功的关键因素

　　职责：开发项目经理完成，市场人员可协助。

　　4.3 识别项目的风险和假设

　　活动：通过与客户的沟通，识别项目的风险和假定，并分析他们对项目的影响，给出风险的减缓方法。

　　职责：开发项目经理同完成，市场人员可协助。

　　4.4 获取功能需求和技术需求

　　活动：通过与客户的沟通，获取功能需求和技术需求，即明确系统的功能需求和使用什么样的技术

　　职责：开发项目经理完成，市场人员可协助。

　　4.5 编写需求说明文档

　　活动：根据前面几个步骤的沟通结果，整理项目的需求文档。需求文档不一定是一个，可以是几个文档。但必须包括内容：总体系统的需求信息，每个子系统的需求信息，数据字典。公司建议将总体系统的需求信息与每个子系统的需求信息分开写成文档。在总体系统的需求中，从系统整体出发来阐述，而每个子系统的需求只针对子系统本身来阐述。

　　职责：开发项目经理完成。

　　模板：依据提供的“总体系统的需求说明模板”“子系统的需求说明模板”“数据字典的模板”整理。根据实际内容，允许对模板进行裁剪。

　　高质量的需求说明文档的关键特点：

　　完整:不应该遗漏要求和必需的信息。发现缺少的信息很难，因为根本不存在。如果你知道已缺少一些信息，使用TBD（to be determined）标准标志可以突出这些缺陷，当你在构建产品的相关部分时，就可以从一个给定的需求集中解决所有的缺陷。

　　一致性：一致性需求就是不要于其他的软件需求或高级别的系统（商业）需求发生冲突。

　　可修改性：每个需求必须相对于其他需求有其单独的标示和分开的说明，便于清晰的查阅。通过良好的组织可以使需求易于修改，如：将相关的需求分组，建立目录表，索引，以及前后参考（照）。