需求管理体系改进方法研究需求管理过程当软件开发完成需求开发工作之后，不可避免地会遇到软件需求的变更。

有效的需求管理需要对变更带来的潜在影响及可能的成本费用进行评估。

变更控制委员会与关键的项目风险承担者要进行协商，以确定哪些需求可以变更。

同时，无论是在开发阶段还是在系统测试阶段，还应跟踪每项需求的状态。

需求管理的主要工作如下：1) 确定需求变更控制过程：确定一个选择、分析和决策需求变更的过程。

所有的需求变更都需遵循此过程，商业化的问题跟踪工具都能支持变更控制过程。

2) 建立变更控制委员会：组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内，估价它们，并对此评估作出决策以确定选择哪些，放弃哪些，并设置实现的优先顺序，制定目标版本。

3) 进行需求变更影响分析：应评估每项选择的需求变更，以确定它对项目计划安排和其它需求的影响。

明确与变更相关的任务并评估完成这些任务需要的工作量。

通过这些分析将有助于变更控制委员会作出更好的决策。

4) 跟踪所有受需求变更影响的工作产品：当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计模板、源代码和测试用例，这些相关部分可能也需要修改。

这样能减少因疏忽而不得不变更产品的机会，这种变更在变更需求的情况下是必须进行的。

5) 建立需求基准版本和需求控制版本文档：确定一个需求基准，这是一致性需求在特定时刻的快照。

之后的需求变更就遵循变更控制过程即可。

每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。

最好的办法是使用合适的配置管理工具在版本控制下为需求文档定位。

6) 维护需求变更的历史记录：记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等。

7) 跟踪每项需求的状态：建立一个数据库，其中每一条记录保存一项功能需求。

保存每项功能需求的重要属性，它包括状态（如已推荐的，已通过的，已实施的，或已验证的），这样在任何时候都能得到每个状态类的需求数量。

8) 衡量需求稳定性：记录基准需求的数量和每周或每月的变更（添加、修改、删除）数量。

过多的需求变更“是一个报警信号”，意味着问题并未真正弄清楚，项目范围并未很好地确定下来或是政策变化较大。

9) 使用需求管理工具：商业化的需求管理工具能帮助在数据库中存储不同类型的需求，为每项需求确定属性，可跟踪其状态，并在需求与其它软件开发工作产品间建立跟踪能力联系链。

根据以上对需求管理过程的理解，制定以下软件需求管理过程规范。

软件需求管理过程规范1、前言1.1 目的本文的目的是规范公司的软件需求管理过程。

以后的项目过程均要遵循此规范的要求，规范的改进工作将在过程的改进过程中进行。

1.2 范围本规范详尽地规范和要求了软件开发项目的需求管理过程，主要包括过程的具体活动，活动的负责人角色，以及采用的工具模板。

主要包括三个大的阶段：Discover阶段，define阶段，和需求维护阶段。

对于每个阶段具体活动的详细要求将在对应的章节中一一介绍。

1.4 有关的角色及职责角色职责描述市场人员负责discover阶段所有工作，并帮助开发项目经理和设计师在define阶段初期很快地了解业务和客户开发项目经理协调discover阶段的所有活动；与设计师共同完成需求文档；维护scope matrix。

设计师与开发项目经理共同完成需求文档行业专家提供行业咨询高层团队指导discover和define阶段的工作SEPG 负责过程的培训，提供过程支持，负责过程的跟进和改进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。