4.1 准备
活动：了解discover阶段的输出文档，安排交流的客户代表
职责：市场人员帮助开发项目经理了解可行性分析报告中的内容，并共同联系客户代表；开发项目经理理解可行性报告中的相关内容，为后面工作的开展作好准备。
4.2 分析项目目标和成功因素
活动：通过与客户的沟通，定义项目目标和成功的关键因素
职责：开发项目经理完成，市场人员可协助。
4.3 识别项目的风险和假设
活动：通过与客户的沟通，识别项目的风险和假定，并分析他们对项目的影响，给出风险的减缓方法。
职责：开发项目经理同完成，市场人员可协助。
4.4 获取功能需求和技术需求
活动：通过与客户的沟通，获取功能需求和技术需求，即明确系统的功能需求和使用什么样的技术
职责：开发项目经理完成，市场人员可协助。
4.5 编写需求说明文档
活动：根据前面几个步骤的沟通结果，整理项目的需求文档。需求文档不一定是一个，可以是几个文档。但必须包括内容：总体系统的需求信息，每个子系统的需求信息，数据字典。公司建议将总体系统的需求信息与每个子系统的需求信息分开写成文档。在总体系统的需求中，从系统整体出发来阐述，而每个子系统的需求只针对子系统本身来阐述。
职责：开发项目经理完成。
模板：依据提供的“总体系统的需求说明模板”“子系统的需求说明模板”“数据字典的模板”整理。根据实际内容，允许对模板进行裁剪。
高质量的需求说明文档的关键特点：
完整：不应该遗漏要求和必需的信息。发现缺少的信息很难，因为根本不存在。如果你知道已缺少一些信息，使用TBD（to be determined）标准标志可以突出这些缺陷，当你在构建产品的相关部分时，就可以从一个给定的需求集中解决所有的缺陷。
一致性：一致性需求就是不要于其他的软件需求或高级别的系统（商业）需求发生冲突。
可修改性：每个需求必须相对于其他需求有其单独的标示和分开的说明，便于清晰的查阅。通过良好的组织可以使需求易于修改，如：将相关的需求分组，建立目录表，索引，以及前后参考（照）。
4.6 建立Scope Matrix
活动：根据系统的需求建立Scope Matrix，以指导后期的开发。Scope Matrix的所有内容必须忠实于整理出来的需求文档。如果需求文档的内容不足以得到完整细致的Scope Matrix，可以回过头来完善需求文档；如果实在确定不下来的内容，可以在Scope Matrix中标注出来，待以后确定。
职责：开发项目经理完成。
模板：依据提供的“Scope matrix的模板”整理。根据实际内容。
如何在Scope matrix中描述功能域：
罗列所有的详细功能点，而与流程无关。
有关的功能限制也可列入。
禁忌用冗长的描述性语言陈述。这样不容易将功能点划开。
每个功能点用一句简短的话来描述。如果一个功能点需要两句话才能描述清楚，则将其划为两个功能点。
4.7 Define阶段的审核
活动：以会议的形式沟通需求的内容，对需求进行Quality review.
参与人：项目经理（发起者和组织者），行业专家，和客户
审核内容：数据字典，总体系统的需求说明，各子系统的需求说明，Scope matrix
输出：Review notes。Review notes要求填写在公司规定的Quality review notes的模板中。
职责：
项目经理发起，组织，并主持审核会议，做会议记录。会后总结review notes.
说明：Define阶段审核通过后，方可进入设计阶段。
5、需求维护
需求维护的关键内容是需求变更管理。需求的变更是不可避免的，如何以可控的方式管理软件的需求，对于项目的顺利进行有着重要的意义。对于需求变更的管理，我们主要使用需求变更控制流程，需求跟踪矩阵，和需求配置的管理方式。
5.1 变更控制流程
5.2 需求跟踪
活动：使用scope matrix来跟踪每项需求是否要求实现，以及需求实现的状态
职责：由开发项目经理负责维护scope matrix。
5.3 需求配置管理
活动：保存需求方面的所有文档的所有版本
职责：每个有关需求的文档以及升级文档均要求保存到配置管理系统中。
要求：
所有资料均放入配置管理系统。
按照规定的目录存放资料。
文件的每个修改版本都要求保存。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
