第二篇 信息系统项目管理知识

第六章 信息系统项目管理

6.15 需求管理

6.15.1 考点梳理

“需求”指的是由项目接受的或项目产生的产品和产品构件需求，包括由组织征集的对项目的需求。这种需求既有技术性的，也有非技术性的。“需求管理”（Requirements　Management, REQM）的目的是确保各方对需求的一致理解、管理和控制需求的变更、从需求到最终产品的双向跟踪。

 需求基线

把所有与需求直接相关的活动通称为需求工程。

需求工程的活动可分为两大类，一类属于需求开发；另一类属于需求管理。

需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。软件项目需求开发的结果应该有项目视图和范围文档、用例文档、软件需求规格说明及相关分析模型，经评审批准，这些文档就定义了开发工作的需求基线，这个基线在客户和开发人员之间就构筑了计划产品功能需求和非功能需求的一个约定。

需求开发的过程有四个主要活动：

1) 需求获取；

2) 需求分析；

3) 需求定义；

4) 需求验证。

 需求变更控制

变更控制策略：

 所有需求变更必须遵循的过程，按照此过程，如果一个变更需求未被采纳，则其后过程不再予以考虑。

  对于未获批准的变更，除可行性论证之外，不应再做其他设计和实现工作。

  简单请求一个变更不能保证能实现变更，要由项目变更控制委员会(CCB)决定实现哪些变更。

  项目风险承担者应该能够了解变更数据库的内容。

  绝不能从数据库中删除或修改变更请求的原始文档。

 每一个集成的需求变更必须能跟踪到一个经核准的变更请求。

变更控制状态报告：用报告、图表来总结变更控制数据库的内容和按状态分类的变更请求数量。描述产  生报告的步骤。项目管理者通常使用这些报告来跟踪项目状态。

变更控制委员会（CCB）可以由一个小组担任，也可由多个不同的组担任，负责做出决定究竟将哪一些已建议需求变更或新产品特性付诸应用。典型的变更控制委员会同样决定在哪一些版本中纠正哪一些错误。许多项目已经有负责变更决策的人员，而正式组建变更控制委员会、制定操作步骤会使他们更有效地工作。

变更控制委员会可能包括如下方面的代表：

  产品或计划管理部门。

  项目管理部门。

  开发部门。

  测试或质量保证部门。

  市场部或客户代表。

  制作用户文档的部门。

  技术支持部门。

  帮助桌面或用户支持热线部门。

  配置管理部门。

 需求版本控制

需求文档的每一个版本必须被统一确定。组内每个成员必须能够得到需求的当前版本，必须清楚地将变更写成文档，并及时通知到项目开发所涉及的人员。为了尽量减少困惑、冲突、误传，应仅允许指定的人来更新需求。这些策略适用于所有关键项目文档。

一个具有更高级别的版本控制包括用版本控制工具来存储需求文档，如用登录（Checkln）和检出（CheckOut）程序来管理源代码。这方面有很多商业配置管理工具。版本控制的最有力方法是用一个商业需求管理工具的数据库存储需求。这些工具能跟踪和报告每个需求的变动历史，当需要恢复早期的需求时很有价值。在添加、变动、删除、拒绝一个需求后，附加一些评语描述变更的原因在将来需要讨论时会很有用。

 需求跟踪

需求跟踪包括编制每个需求同系统元素之间的联系文档。这些元素包括别的需求、体系结构、其他设计部件、源代码模块、测试、帮助文件、文档等。跟踪能力信息使变更影响分析十分便利，有利于确认和评估实现某个建议的需求变更所必需的工作。