《软件过称管理》课程设计报告
第四，需求一旦变化，就必须对需求变更的影响进行评估。无论需求变化的程度如何，只要需求变化了就必须进行评估，这是基本的原则。
第五，需求管理必须与需求工程的其他活动紧密整合。进行需求管理一定不能脱离需求工程， 需求工程包括了需求获取、需求分析、需求描述、需求验证、需求管理，因而需求管理必须与前面的几个需求阶段保持密切相关。
- 4 -
《软件过称管理》课程设计报告
4需求管理的具体活动
需求管理在需求开发的基础上进行，贯穿于整个软件项目过程，是软件项目管理的一部分。在软件项目进行的过程中，无论正处于哪个阶段，一旦有需求错误出现或任何有关需求的变更出现，都需要需求管理活动来解决。需求管理是一个对系统需求变更了解和控制的过程。初始需求导出的同时就启动了需求管理规划，一旦形成了需求文档的草稿版本，需求活动就开始了。需求活动的具体内容如表一所示 ： 需求管理活动 变更控制 版本控制 需求跟踪 需求状态
活动的任务 建议需求变更并分析其影响，做出是否变更的决策 确定单个需求（即功能规格说明）的版本 定义对于其他需求及系统元素的联系链 定义并跟踪需求的状态 4.1 说明
应该说需求管理过程和软件开发过程是并行的。奉文描述的需求管理过程出现在软件开发过程整个周期之中 所以将软件开发过程作为背景信息提供出来。
软件开发过程可分为需求阶段、建议阶段、设计阶段、编码阶段和核实阶段。需求阶段包括程序初始化和程序定义。交付的是程序陈述和需求说明书； 需求说明书包括了用户需求和技术需求。 建议阶段定的组织制度或政策之类的基础，在这样一个基础之上才能够开展各个K P A 的实践活动。 需求管理也不例外，其基础是：覆盖了为确定需求说明书而进行工程建议的活动，建议文档是后续设计阶段的基础。设计阶段包括功能描述和设计交付的是一个或多个为了确定具有更多细节的功能和设计说明书而编写的功能说明书。编码阶段包括实施源代码对目标代码进行单元测试，交付的是实际的软件和文档或产品信息。核实阶段包括各种各样的测试行为， 交付的是基于设计和技术或用户需求的测试说明．测试计划和测试运行结果。
- 5 -
《软件过称管理》课程设计报告
4.2 需求管理过程
本文所建议的需求管理过程采用了一个数据库来标志需求在各个阶段的状态 ，在CMM中称为度量目的是为了明确分配的需求管理活动的状态。下面给出了需求管理过程的数据流图。
用户所需要实现的功能及要求定义项目经理根据用户的需求进行分析分析编写项目计划建议技术需求设计阶段技术需求编写技术要求及规范文档编码阶段技术需求跟踪其他项目管理过程得到的项目需求由系统测试校验用户需求测试阶段技术需求
- 6 -
《软件过称管理》课程设计报告
4.3需求确定的管理
需求确定阶殷可映射到软件开发过程中的需求阶段。具体到需求管理过程可以进一步细分为定义阶段分析阶段。实施办法建议如下：
在定义阶段所做的工作是：
( 1 ) 收集需求，并制定需求说明书的草案。 ( 2 ) 与需求者一起定义 验证所收集的需求。
( 3 ) 跟踪需求的需求者或需求源 及时向他们发送批准的需求或需求的变更。
在这一阶段，需求说明书草案中的每一个需求的状态是“定义的” 。 在分析阶段所做的工作是：
①分析需求，以保证所列需求是清晰的、明确的、有意义的、可测量的，并且可用于开发和测试。
②建立用户和技术需求之的联系。保证技术需求能充分覆盖和分解用户需求。
③划分需求，找出其中的不足和不完善的地方。 ④区分需求的优先级、更新需求说明书。
⑤得到批准的需求说明书，这是软件开发和项目管理行为的基础 。 到目前为止，批准的需求说明书的每一个需求的状态已被更新为“ 批准的” 。
4.4需求实现的管理
需求实现阶段涉及到软件开发过程的建议阶段、设计阶段、编码阶段和核实阶段。
在建议阶段所做的工作是：根据适当的过程开发建议和项目计划。 建议也许不能针对每一个批准的需求，而且有些需求可能在其他项目建议中或今后的交付中才会出现，要审核、批准、提交建议和项目计划到目前为止， 需求说明书中被建议的每一个需求的状态已被更新为“ 建议的”。
在设计阶段所做的工作是：在一个或多个设计说明书中提出技术需求： 必须根据需求来进行设计，检查设计，以判断是否对所有的需求都进行了设计。到目前为止，在设计中提出的每一个需求的状态已被更新为 “设计的”。项目经理要保证在一个或多个设计中包括所有提交的需求。
- 7 -
《软件过称管理》课程设计报告
在编码阶段所做的工作是：实施设计。
实施设计的结果就是软件和文档必须对这些工作产品进行检查。如果设计没有被充分的实施，就会有需求不能满足，这就意味着要重复工作。到目前为止，在软件和文档中被实施的每一个需求的状态已被更新为“ 实施的”。项目经理要保证产品中包括所有提交的需求。
在核实阶段所做的工作是：通过测试软件来检验需求的满足情况。 CMM要求在项目实施过程中，项目组定期与上级管理部门一起审查对分配的需求的管理括动而在项目组内，项目经理也要定期或有审查触发时审查对分配的需求的管理话动。这是对需求管理活动的审查此外。CMM还要求由软件质量保证组审查管理活动的工作产品并报告结果。
由需求者来审核、批准需求说明。
审查软件工程组提交的分配需求。解决有关问题软件计划。工作产品和项目活动是否随分配需求的变更而相应的变化。
在测试阶段，跟踪测试结果。判断哪些需求被满足了。在这一阶段，产品中被核实的每一个需求的状态已被更新为“完备的”。 项目经理要保证产品中包括所有的提交的需求。
4.5需求变更的管理
变更管理主要涉及到分配的需求的更改活动，分配的需求的更改次数等。 接手过项目的人都知道，需求确定之后并不是一成不变的。需求变更可以从需求说明书或建议开始生效。变更必须在相关的计划、交付和行为中反映出来。本文针对几种常见的需求变更情况，对变更的管理工作提出了一些建议，列表如下： 放弃一个不再需要的需求 更新需求说明书删除该需求并重新批准需求说明书。在建议、项目计划和产品交付中反映这一变更 从当前打算的实施中删除需求，而该更新建议，反映这一变更。该需求的需求还是希望在子交付中被满足 在批准需求说明书中加入新的需求 状态还原成“批准的”。变更在项目计划和产品交付中要有所反映 新的需求应是有效的，经过分析的并且划分了优先级的。更新并批准需求说明书。要求在建议、项目计划和产品交付中反映需求变更，该需求状态- 8 -