需求管理体系改进方法研究
需求管理过程
当软件开发完成需求开发工作之后，不可避免地会遇到软件需求的变更。有效的需求管理需要对变更带来的潜在影响及可能的成本费用进行评估。变更控制委员会与关键的项目风险承担者要进行协商，以确定哪些需求可以变更。同时，无论是在开发阶段还是在系统测试阶段，还应跟踪每项需求的状态。需求管理的主要工作如下：
1) 确定需求变更控制过程：确定一个选择、分析和决策需求变更的过程。所有的需求变更都需遵循此过程，商业化的问题跟踪工具都能支持变更控制过程。
2) 建立变更控制委员会：组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内，估价它们，并对此评估作出决策以确定选择哪些，放弃哪些，并设置实现的优先顺序，制定目标版本。
3) 进行需求变更影响分析：应评估每项选择的需求变更，以确定它对项目计划安排和其它需求的影响。明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于变更控制委员会作出更好的决策。
4) 跟踪所有受需求变更影响的工作产品：当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计模板、源代码和测试用例，这些相关部分可能也需要修改。这样能减少因疏忽而不得不变更产品的机会，这种变更在变更需求的情况下是必须进行的。
5) 建立需求基准版本和需求控制版本文档：确定一个需求基准，这是一致性需求在特定时刻的快照。之后的需求变更就遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。最好的办法是使用合适的配置管理工具在版本控制下为需求文档定位。
6) 维护需求变更的历史记录：记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等。
7) 跟踪每项需求的状态：建立一个数据库，其中每一条记录保存一项功能需求。保存每项功能需求的重要属性，它包括状态（如已推荐的，已通过的，已实施的，或已验证的），这样在任何时候都能得到每个状态类的需求数量。
8) 衡量需求稳定性：记录基准需求的数量和每周或每月的变更（添加、修改、删除）
数量。过多的需求变更“是一个报警信号”，意味着问题并未真正弄清楚，项目范围并未很好地确定下来或是政策变化较大。
9) 使用需求管理工具：商业化的需求管理工具能帮助在数据库中存储不同类型的需求，为每项需求确定属性，可跟踪其状态，并在需求与其它软件开发工作产品间建立跟踪能力联系链。
根据以上对需求管理过程的理解，制定以下软件需求管理过程规范。
软件需求管理过程规范 1、前言 1.1 目的
本文的目的是规范公司的软件需求管理过程。以后的项目过程均要遵循此规范的要求，
规范的改进工作将在过程的改进过程中进行。
1.2 范围
本规范详尽地规范和要求了软件开发项目的需求管理过程，主要包括过程的具体活动，
活动的负责人角色，以及采用的工具模板。
主要包括三个大的阶段：Discover 阶段，define 阶段，和需求维护阶段。对于每个阶段
具体活动的详细要求将在对应的章节中一一介绍。
1.4 有关的角色及职责
角色
职责描述
负责discover 阶段所有工作，并帮助开发项目经理和设计师在define 阶段初期很快地了解业务和客户
开发项目经理
协调discover 阶段的所有活动；与设计师共同完成需求文档；维护scope matrix。
设计师
与开发项目经理共同完成需求文档
市场人员
行业专家 高层团队 SEPG
提供行业咨询
指导discover 和define 阶段的工作
负责过程的培训，提供过程支持，负责过程的跟进和改进
2、软件需求管理过程的概貌
需求可定义为“（正在构建的）系统必须符合的条件或具备的功能”，也有人定义为
“用户解决某一问题或达到某一目标所需的软件功能”。
而需求管理是一种获取、组织并记录系统需求的系统化方案，以及 一个使客户与项
目团队对不断变更的系统需求达成并保持一致的过程。需求管理的目的是在顾客和将处理顾客需求的软件项目组之间建立对顾客需求的共同理解。
需求管理的目标是：
∙ 使软件需求受控，并建立供软件工程和管理使用的基线。 ∙ 使软件计划、产品和活动与软件需求保持一致。
2.1 过程图
Discover 阶段
Define 阶段
需求维护阶段
2.2 注解
Discover 阶段
本阶段的目的是了解客户的问题，分析并确定公司是否开展此行业的项目。这里的客户
不一定针对一个企业，有可能是一个行业。在进行具体的调研时，目标是本行业的一个或几个典型用户。市场人员主要对客户的问题，客户的现状，和客户的业务模式三方面进行了解，然后对照公司的业务发展方向和实际现状进行可行性分析，并负责编写可行性分析报告。
然后发起可行性分析会议，邀请公司高层，行业专家和利益相关者一起来商议公司
是否开展此项目。一旦决定做此项目，下来将寻找有意向的用户。找到合适的用户后，就可以正式开始创建开发团队进行开发系统的定义，设计，编码等工作。 Define 阶段
目的是得到一套客户认可的详细的需求说明文档，用来指导后期的软件开发工作。开发
项目经理和设计师通过与客户沟通交流，分析项目目标和成功因素，识别项目风险和假设，以及系统的功能需求和技术需求，最终整理出一套详细的需求说明文档，包括总体系统的需求信息，每个子系统的需求信息，数据字典，等。
为了指导后期的开发和跟踪需求实现的状态和范围，项目经理需要根据需求来建立本项
目的Scope Matrix。在Scope Matrix中随时跟踪每项功能的In 或Out ，以及现在处于开发的什么阶段。
所有需求文档完成之后，由项目经理和设计师发起并组织阶段审核会议，并邀请客户和
行业专家参加。审核的内容包括所有需求文档和Scope Matrix。一旦审核通过，则开始制定下阶段的计划，准备进入概念阶段。 需求维护阶段
目的是管理需求的变更。在软件开发过程中，需求不可避免会有大或小的更改。为了更
有效地管理需求的变更，这里规范了需求变更，需求跟踪，和需求配置管理的要求。对每项内容的详细内容，将在后面的章节中介绍。
3、Discover 阶段 3.1 过程图
3.2 活动
3.2.1 理解客户的需求
活动：与客户沟通交流，了解他们的原始需求。并分析公司开发此项目的业务机遇，业务目标，
客户和市场的需求，以及业务风险等问题。
职责：由公司高层负责，市场人员具体执行。
3.2.2 了解客户的现状
活动：评估客户的现状，如信息化程度，人员的计算机技能水平，业务模式等。 职责：由公司高层负责，市场人员具体执行。
3.2.3 了解客户的业务模式
活动：了解客户当前的业务模式，包括业务角色及其关系。 职责：由公司高层负责，市场人员具体执行。
3.2.4 编写可行性分析报告
活动：根据前面三项内容，对本项目做评估，分析是否开展此项目 职责：由公司高层负责，市场人员具体执行
模板：依据提供的“可行性分析报告的模板”整理。根据实际内容，允许对模板进行裁剪。
3.2.5 可行性问题的决策
活动：审核可行性分析报告的内容；决定是否开展此项目
参与人：市场人员（发起者和组织者），行业专家，公司高层决策人员。 主要沟通内容：可行性分析报告 输出：作出结论的可行性分析报告
职责：市场人员发起，组织，和主持会议，做会议记录。负责可行性分析报告的修订和决策
记录。
说明：决定开展此项目后，方可进入define 阶段。在进入Define 阶段之前，需要由项目经
理和设计师确定项目的整体计划和define 阶段的详细计划。
4、Define 阶段 4.1 过程图
4.2 活动
4.2.1 准备
活动：了解discover 阶段的输出文档，安排交流的客户代表
职责：市场人员帮助开发项目经理和设计师了解可行性分析报告中的内容，并共同联系客户代表；
开发项目经理和设计师理解可行性报告中的相关内容，为后面工作的开展作好准备。
4.2.2 分析项目目标和成功因素
活动：通过与客户的沟通，定义项目目标和成功的关键因素 职责：开发项目经理和设计师共同完成，市场人员可协助。
4.2.3 识别项目的风险和假设
活动：通过与客户的沟通，识别项目的风险和假定，并分析他们对项目的影响，给出风险的减缓方法。
职责：开发项目经理和设计师共同完成，市场人员可协助。
4.2.4 获取功能需求和技术需求
活动：通过与客户的沟通，获取功能需求和技术需求，即明确系统的功能需求和使用什么样的技术
职责：开发项目经理和设计师共同完成，市场人员可协助。
4.2.5 编写需求说明文档
活动：根据前面几个步骤的沟通结果，整理项目的需求文档。需求文档不一定是一个，可以是几
个文档。但必须包括内容：总体系统的需求信息，每个子系统的需求信息，数据字典。公司建议将总体系统的需求信息与每个子系统的需求信息分开写成文档。在总体系统的需求中，从系统整体出发来阐述，而每个子系统的需求只针对子系统本身来阐述。
职责：开发项目经理和设计市共同完成。
模板：依据提供的“总体系统的需求说明模板”“子系统的需求说明模板”“数据字典的模板”
整理。根据实际内容，允许对模板进行裁剪。
高质量的需求说明文档的关键特点：
完整：不应该遗漏要求和必需的信息。发现缺少的信息很难，因为根本不存在。如
果你知道已缺少一些信息，使用TBD （to be determined）标准标志可以突出这些缺陷，当你在构建产品的相关部分时，就可以从一个给定的需求集中解决所有的缺陷。
∙ 一致性：一致性需求就是不要于其他的软件需求或高级别的系统（商业）需求发生
冲突。
∙ 可修改性：每个需求必须相对于其他需求有其单独的标示和分开的说明，便于清晰
的查阅。通过良好的组织可以使需求易于修改，如：将相关的需求分组，建立目录表，索引，以及前后参考（照）。
4.2.6 建立Scope Matrix
活动：根据系统的需求建立Scope Matrix，以指导后期的开发。Scope Matrix的所有内容必
须忠实于整理出来的需求文档。如果需求文档的内容不足以得到完整细致的Scope Matrix ，可以回过头来完善需求文档；如果实在确定不下来的内容，可以在Scope Matrix中标注出来，待以后确定。 职责：开发项目经理和设计市共同完成。
模板：依据提供的“Scope matrix的模板”整理。根据实际内容。 如何在Scope matrix中描述功能域：
∙ 罗列所有的详细功能点，而与流程无关。 ∙ 有关的功能限制也可列入。
∙ 禁忌用冗长的描述性语言陈述。这样不容易将功能点划开。
∙ 每个功能点用一句简短的话来描述。如果一个功能点需要两句话才能描述清楚，
则将其划为两个功能点。
4.2.7 Define阶段的审核
活动：以会议的形式沟通需求的内容，对需求进行Quality review. 参与人：项目经理（发起者和组织者），设计师，行业专家，和客户
审核内容：数据字典，总体系统的需求说明，各子系统的需求说明，Scope matrix 输出：Review notes。Review notes要求填写在公司规定的Quality review notes的模板中。 职责：
∙ 设计师发起，组织，并主持审核会议，做会议记录。会后总结review notes. ∙ 开发项目经理。与设计师共同完成审核工作。
说明：Define 阶段审核通过后，方可进入设计阶段。
5、需求维护
需求维护的关键内容是需求变更管理。需求的变更是不可避免的，如何以可控的方式管
理软件的需求，对于项目的顺利进行有着重要的意义。对于需求变更的管理，我们主要使用需求变更控制流程，需求跟踪矩阵，和需求配置的管理方式。
5.1 变更控制
5.1.1 变更控制流程
5.1.2 变更审核小组
成员组成：项目经理，设计师，和客户代表
职责：处理每一份需求更改申请单
5.1.3 变更申请单
变更申请单的模板请参见“需求更改单模板”文件。本模板包含两部分内容，第一部分是更改申请的信息，第二部分是审核小组的分析和决策信息（包括他们的签字）。
需求更改的提出者可以是客户，也可以是开发团队的任何人。
5.2 需求跟踪
活动：使用scope matrix来跟踪每项需求是否要求实现，以及需求实现的状态 职责：由开发项目经理负责维护scope matrix。
5.3 需求配置管理
活动：保存需求方面的所有文档的所有版本
职责：每个有关需求的文档以及升级文档均要求保存到CVS 。
要求：
∙ 所有资料均放入CVS 。
∙ 按照规定的目录存放资料。现有两个：Client 和Requirement 目录。
文件的每个修改版本都要求保存。
6、识别与需求管理有关的风险
1) 变更需求：将前景文档作为变更的参照可以减少项目范围的延伸。用户积极参与的具有良好合作精神的需求获取过程可把需求变更减少近一半。能在早期发现需求错误的质量控制方法可以减少以后发生变更的可能。而为了减少需求变更的影响，将那些易于变更的需求用多种方案实现，并在设计时更要注重其可修改性。
2) 需求变更过程：需求变更的风险来源于未曾明确的变更过程或采用的变动机制无效或不按计划的过程来做出变更。应当在开发的各阶层都建立变更管理的纪律和氛围，当然这需
要时间。需求变更过程包括对变更的影响评估，提供决策的变更控制委员会，以及支持确定 重要起点步骤的工具。
3) 未实现的需求：需求跟踪能力矩阵有助于避免在设计、结构建立及测试期间遗漏的任何需求。也有助于确保不会因为交流不充分而导致多个开发人员都未实现某项需求。
4) 扩充项目范围：如果开始未很好定义需求，那么很可能隔段时间就要扩充项目的范围。产品中未说明白的地方将耗费比预料中更多的工作量，而且按最初需求所分配好的项目资源也可能不按实际更改后用户的需求而调整。为减少这些风险，要对阶段递增式的生存期制定计划，在早期版本中实现核心功能，并在以后的阶段中逐步增加实现需求。 规范针对七命题方面采用的方案描述
⏹ 成熟度命题：软件需求管理过程规范要组织所有相关人员学习，已达到成熟度命题
的要求。
⏹ 效果命题：需要在需求管理过程中有明确的评估，体现在“define 阶段的审核”和
“变更控制审核”两个方面。
⏹ 领导命题：开发项目经理协调discover 阶段的所有活动；与设计师共同完成需求文
档；维护scope matrix。
⏹ 过程命题：明确的定义了软件需求管理过程规范。
⏹ 文档命题：在过程规范的各个阶段需要按要求编写文档，包括可行性分析包够、需
求说明文档、Scope Matrix。
⏹ 团队命题：在“有关的角色及职责”中明确定义了所有相关人员的角色和职责。 ⏹ 投资命题：体现在需求维护与识别与需求管理相关的分析方面，这两个部分的内容
定义了控制需求变更的流程及其风险，在控制需求变更的同时就控制了项目的人力和成本。
需求管理体系改进方法研究
需求管理过程
当软件开发完成需求开发工作之后，不可避免地会遇到软件需求的变更。有效的需求管理需要对变更带来的潜在影响及可能的成本费用进行评估。变更控制委员会与关键的项目风险承担者要进行协商，以确定哪些需求可以变更。同时，无论是在开发阶段还是在系统测试阶段，还应跟踪每项需求的状态。需求管理的主要工作如下：
1) 确定需求变更控制过程：确定一个选择、分析和决策需求变更的过程。所有的需求变更都需遵循此过程，商业化的问题跟踪工具都能支持变更控制过程。
2) 建立变更控制委员会：组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内，估价它们，并对此评估作出决策以确定选择哪些，放弃哪些，并设置实现的优先顺序，制定目标版本。
3) 进行需求变更影响分析：应评估每项选择的需求变更，以确定它对项目计划安排和其它需求的影响。明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于变更控制委员会作出更好的决策。
4) 跟踪所有受需求变更影响的工作产品：当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计模板、源代码和测试用例，这些相关部分可能也需要修改。这样能减少因疏忽而不得不变更产品的机会，这种变更在变更需求的情况下是必须进行的。
5) 建立需求基准版本和需求控制版本文档：确定一个需求基准，这是一致性需求在特定时刻的快照。之后的需求变更就遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。最好的办法是使用合适的配置管理工具在版本控制下为需求文档定位。
6) 维护需求变更的历史记录：记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等。
7) 跟踪每项需求的状态：建立一个数据库，其中每一条记录保存一项功能需求。保存每项功能需求的重要属性，它包括状态（如已推荐的，已通过的，已实施的，或已验证的），这样在任何时候都能得到每个状态类的需求数量。
8) 衡量需求稳定性：记录基准需求的数量和每周或每月的变更（添加、修改、删除）
数量。过多的需求变更“是一个报警信号”，意味着问题并未真正弄清楚，项目范围并未很好地确定下来或是政策变化较大。
9) 使用需求管理工具：商业化的需求管理工具能帮助在数据库中存储不同类型的需求，为每项需求确定属性，可跟踪其状态，并在需求与其它软件开发工作产品间建立跟踪能力联系链。
根据以上对需求管理过程的理解，制定以下软件需求管理过程规范。
软件需求管理过程规范 1、前言 1.1 目的
本文的目的是规范公司的软件需求管理过程。以后的项目过程均要遵循此规范的要求，
规范的改进工作将在过程的改进过程中进行。
1.2 范围
本规范详尽地规范和要求了软件开发项目的需求管理过程，主要包括过程的具体活动，
活动的负责人角色，以及采用的工具模板。
主要包括三个大的阶段：Discover 阶段，define 阶段，和需求维护阶段。对于每个阶段
具体活动的详细要求将在对应的章节中一一介绍。
1.4 有关的角色及职责
角色
职责描述
负责discover 阶段所有工作，并帮助开发项目经理和设计师在define 阶段初期很快地了解业务和客户
开发项目经理
协调discover 阶段的所有活动；与设计师共同完成需求文档；维护scope matrix。
设计师
与开发项目经理共同完成需求文档
市场人员
行业专家 高层团队 SEPG
提供行业咨询
指导discover 和define 阶段的工作
负责过程的培训，提供过程支持，负责过程的跟进和改进
2、软件需求管理过程的概貌
需求可定义为“（正在构建的）系统必须符合的条件或具备的功能”，也有人定义为
“用户解决某一问题或达到某一目标所需的软件功能”。
而需求管理是一种获取、组织并记录系统需求的系统化方案，以及 一个使客户与项
目团队对不断变更的系统需求达成并保持一致的过程。需求管理的目的是在顾客和将处理顾客需求的软件项目组之间建立对顾客需求的共同理解。
需求管理的目标是：
∙ 使软件需求受控，并建立供软件工程和管理使用的基线。 ∙ 使软件计划、产品和活动与软件需求保持一致。
2.1 过程图
Discover 阶段
Define 阶段
需求维护阶段
2.2 注解
Discover 阶段
本阶段的目的是了解客户的问题，分析并确定公司是否开展此行业的项目。这里的客户
不一定针对一个企业，有可能是一个行业。在进行具体的调研时，目标是本行业的一个或几个典型用户。市场人员主要对客户的问题，客户的现状，和客户的业务模式三方面进行了解，然后对照公司的业务发展方向和实际现状进行可行性分析，并负责编写可行性分析报告。
然后发起可行性分析会议，邀请公司高层，行业专家和利益相关者一起来商议公司
是否开展此项目。一旦决定做此项目，下来将寻找有意向的用户。找到合适的用户后，就可以正式开始创建开发团队进行开发系统的定义，设计，编码等工作。 Define 阶段
目的是得到一套客户认可的详细的需求说明文档，用来指导后期的软件开发工作。开发
项目经理和设计师通过与客户沟通交流，分析项目目标和成功因素，识别项目风险和假设，以及系统的功能需求和技术需求，最终整理出一套详细的需求说明文档，包括总体系统的需求信息，每个子系统的需求信息，数据字典，等。
为了指导后期的开发和跟踪需求实现的状态和范围，项目经理需要根据需求来建立本项
目的Scope Matrix。在Scope Matrix中随时跟踪每项功能的In 或Out ，以及现在处于开发的什么阶段。
所有需求文档完成之后，由项目经理和设计师发起并组织阶段审核会议，并邀请客户和
行业专家参加。审核的内容包括所有需求文档和Scope Matrix。一旦审核通过，则开始制定下阶段的计划，准备进入概念阶段。 需求维护阶段
目的是管理需求的变更。在软件开发过程中，需求不可避免会有大或小的更改。为了更
有效地管理需求的变更，这里规范了需求变更，需求跟踪，和需求配置管理的要求。对每项内容的详细内容，将在后面的章节中介绍。
3、Discover 阶段 3.1 过程图
3.2 活动
3.2.1 理解客户的需求
活动：与客户沟通交流，了解他们的原始需求。并分析公司开发此项目的业务机遇，业务目标，
客户和市场的需求，以及业务风险等问题。
职责：由公司高层负责，市场人员具体执行。
3.2.2 了解客户的现状
活动：评估客户的现状，如信息化程度，人员的计算机技能水平，业务模式等。 职责：由公司高层负责，市场人员具体执行。
3.2.3 了解客户的业务模式
活动：了解客户当前的业务模式，包括业务角色及其关系。 职责：由公司高层负责，市场人员具体执行。
3.2.4 编写可行性分析报告
活动：根据前面三项内容，对本项目做评估，分析是否开展此项目 职责：由公司高层负责，市场人员具体执行
模板：依据提供的“可行性分析报告的模板”整理。根据实际内容，允许对模板进行裁剪。
3.2.5 可行性问题的决策
活动：审核可行性分析报告的内容；决定是否开展此项目
参与人：市场人员（发起者和组织者），行业专家，公司高层决策人员。 主要沟通内容：可行性分析报告 输出：作出结论的可行性分析报告
职责：市场人员发起，组织，和主持会议，做会议记录。负责可行性分析报告的修订和决策
记录。
说明：决定开展此项目后，方可进入define 阶段。在进入Define 阶段之前，需要由项目经
理和设计师确定项目的整体计划和define 阶段的详细计划。
4、Define 阶段 4.1 过程图
4.2 活动
4.2.1 准备
活动：了解discover 阶段的输出文档，安排交流的客户代表
职责：市场人员帮助开发项目经理和设计师了解可行性分析报告中的内容，并共同联系客户代表；
开发项目经理和设计师理解可行性报告中的相关内容，为后面工作的开展作好准备。
4.2.2 分析项目目标和成功因素
活动：通过与客户的沟通，定义项目目标和成功的关键因素 职责：开发项目经理和设计师共同完成，市场人员可协助。
4.2.3 识别项目的风险和假设
活动：通过与客户的沟通，识别项目的风险和假定，并分析他们对项目的影响，给出风险的减缓方法。
职责：开发项目经理和设计师共同完成，市场人员可协助。
4.2.4 获取功能需求和技术需求
活动：通过与客户的沟通，获取功能需求和技术需求，即明确系统的功能需求和使用什么样的技术
职责：开发项目经理和设计师共同完成，市场人员可协助。
4.2.5 编写需求说明文档
活动：根据前面几个步骤的沟通结果，整理项目的需求文档。需求文档不一定是一个，可以是几
个文档。但必须包括内容：总体系统的需求信息，每个子系统的需求信息，数据字典。公司建议将总体系统的需求信息与每个子系统的需求信息分开写成文档。在总体系统的需求中，从系统整体出发来阐述，而每个子系统的需求只针对子系统本身来阐述。
职责：开发项目经理和设计市共同完成。
模板：依据提供的“总体系统的需求说明模板”“子系统的需求说明模板”“数据字典的模板”
整理。根据实际内容，允许对模板进行裁剪。
高质量的需求说明文档的关键特点：
完整：不应该遗漏要求和必需的信息。发现缺少的信息很难，因为根本不存在。如
果你知道已缺少一些信息，使用TBD （to be determined）标准标志可以突出这些缺陷，当你在构建产品的相关部分时，就可以从一个给定的需求集中解决所有的缺陷。
∙ 一致性：一致性需求就是不要于其他的软件需求或高级别的系统（商业）需求发生
冲突。
∙ 可修改性：每个需求必须相对于其他需求有其单独的标示和分开的说明，便于清晰
的查阅。通过良好的组织可以使需求易于修改，如：将相关的需求分组，建立目录表，索引，以及前后参考（照）。
4.2.6 建立Scope Matrix
活动：根据系统的需求建立Scope Matrix，以指导后期的开发。Scope Matrix的所有内容必
须忠实于整理出来的需求文档。如果需求文档的内容不足以得到完整细致的Scope Matrix ，可以回过头来完善需求文档；如果实在确定不下来的内容，可以在Scope Matrix中标注出来，待以后确定。 职责：开发项目经理和设计市共同完成。
模板：依据提供的“Scope matrix的模板”整理。根据实际内容。 如何在Scope matrix中描述功能域：
∙ 罗列所有的详细功能点，而与流程无关。 ∙ 有关的功能限制也可列入。
∙ 禁忌用冗长的描述性语言陈述。这样不容易将功能点划开。
∙ 每个功能点用一句简短的话来描述。如果一个功能点需要两句话才能描述清楚，
则将其划为两个功能点。
4.2.7 Define阶段的审核
活动：以会议的形式沟通需求的内容，对需求进行Quality review. 参与人：项目经理（发起者和组织者），设计师，行业专家，和客户
审核内容：数据字典，总体系统的需求说明，各子系统的需求说明，Scope matrix 输出：Review notes。Review notes要求填写在公司规定的Quality review notes的模板中。 职责：
∙ 设计师发起，组织，并主持审核会议，做会议记录。会后总结review notes. ∙ 开发项目经理。与设计师共同完成审核工作。
说明：Define 阶段审核通过后，方可进入设计阶段。
5、需求维护
需求维护的关键内容是需求变更管理。需求的变更是不可避免的，如何以可控的方式管
理软件的需求，对于项目的顺利进行有着重要的意义。对于需求变更的管理，我们主要使用需求变更控制流程，需求跟踪矩阵，和需求配置的管理方式。
5.1 变更控制
5.1.1 变更控制流程
5.1.2 变更审核小组
成员组成：项目经理，设计师，和客户代表
职责：处理每一份需求更改申请单
5.1.3 变更申请单
变更申请单的模板请参见“需求更改单模板”文件。本模板包含两部分内容，第一部分是更改申请的信息，第二部分是审核小组的分析和决策信息（包括他们的签字）。
需求更改的提出者可以是客户，也可以是开发团队的任何人。
5.2 需求跟踪
活动：使用scope matrix来跟踪每项需求是否要求实现，以及需求实现的状态 职责：由开发项目经理负责维护scope matrix。
5.3 需求配置管理
活动：保存需求方面的所有文档的所有版本
职责：每个有关需求的文档以及升级文档均要求保存到CVS 。
要求：
∙ 所有资料均放入CVS 。
∙ 按照规定的目录存放资料。现有两个：Client 和Requirement 目录。
文件的每个修改版本都要求保存。
6、识别与需求管理有关的风险
1) 变更需求：将前景文档作为变更的参照可以减少项目范围的延伸。用户积极参与的具有良好合作精神的需求获取过程可把需求变更减少近一半。能在早期发现需求错误的质量控制方法可以减少以后发生变更的可能。而为了减少需求变更的影响，将那些易于变更的需求用多种方案实现，并在设计时更要注重其可修改性。
2) 需求变更过程：需求变更的风险来源于未曾明确的变更过程或采用的变动机制无效或不按计划的过程来做出变更。应当在开发的各阶层都建立变更管理的纪律和氛围，当然这需
要时间。需求变更过程包括对变更的影响评估，提供决策的变更控制委员会，以及支持确定 重要起点步骤的工具。
3) 未实现的需求：需求跟踪能力矩阵有助于避免在设计、结构建立及测试期间遗漏的任何需求。也有助于确保不会因为交流不充分而导致多个开发人员都未实现某项需求。
4) 扩充项目范围：如果开始未很好定义需求，那么很可能隔段时间就要扩充项目的范围。产品中未说明白的地方将耗费比预料中更多的工作量，而且按最初需求所分配好的项目资源也可能不按实际更改后用户的需求而调整。为减少这些风险，要对阶段递增式的生存期制定计划，在早期版本中实现核心功能，并在以后的阶段中逐步增加实现需求。 规范针对七命题方面采用的方案描述
⏹ 成熟度命题：软件需求管理过程规范要组织所有相关人员学习，已达到成熟度命题
的要求。
⏹ 效果命题：需要在需求管理过程中有明确的评估，体现在“define 阶段的审核”和
“变更控制审核”两个方面。
⏹ 领导命题：开发项目经理协调discover 阶段的所有活动；与设计师共同完成需求文
档；维护scope matrix。
⏹ 过程命题：明确的定义了软件需求管理过程规范。
⏹ 文档命题：在过程规范的各个阶段需要按要求编写文档，包括可行性分析包够、需
求说明文档、Scope Matrix。
⏹ 团队命题：在“有关的角色及职责”中明确定义了所有相关人员的角色和职责。 ⏹ 投资命题：体现在需求维护与识别与需求管理相关的分析方面，这两个部分的内容
定义了控制需求变更的流程及其风险，在控制需求变更的同时就控制了项目的人力和成本。