系统架构设计师学习之路（18）

4.2 需求管理

软件需求开发的最终文档经过评审批准后，则定义了开发工作的需求基线。这个基线在客户和开发者之间构筑了计划产品功能需求和非功能需求的一个约定。需求约定是需求开发与需求管理之间的桥梁。
需求管理是对一个系统需求变更、了解和控制的过程。一旦形成了需求文档的初稿，需求管理活动就开始了。
需求管理的主要活动：

• 变更控制
  建议变更、分析影响、做出决策、交流、合并、测量需求的稳定性。
• 版本控制
  确定需求文档版本、确定单个需求文档版本。
• 需求跟踪
  定义对其他需求的连接链、定义对其他系统元素的连接链。
• 需求状态跟踪
  定义需求状态、跟踪需求每一个状态。

需求管理强调：

1. 控制对需求基线的变动；
2. 保持项目计划与需求一致；
3. 控制单个需求与需求文档的版本情况；
4. 管理需求和联系链，或者管理单个需求和其他项目可交付产品之间的依赖关系；
5. 跟踪基线中的需求状态。

4.2.1 需求管理原则
过程能力成熟度模型（CMM），用来指导软件过程改进。该模型描述了软件处理能力的5个成熟级别。为了到达第2级，组织机构必须具有6个关键过程域（KPA）。
需求管理是其中之一，它的目标如下：
（1）为软件需求建立一个基线，提供给软件工程和管理使用。
（2）软件计划、产品和活动与软件需求保持一致。
关于需求管理的关键过程域内的原则和策略，可以参考：
（1）需求管理的关键过程领域不涉及收集和分析项目需求，而是假定已收集了软件需求，或者已由更高一级的系统给定了需求。一旦需求获得并且文档化，软件开发组合有关团队（例如质量保证和测试组）需要评审文档。发现问题应与客户或者其他需求源协商解决。软件开发计划是基于已确认的需求。
（2）开发人员在向客户以及有关部门承诺某些需求之前，应该确认需求和约束条件、风险、偶然因素、假定条件等。且决不能承诺任何无法实现的事。
（3）关键处理领域同样建议通过版本控制和变更控制来管理文档。版本控制确保随时能知道在项目开发和计划中正在使用的需求的版本情况。变更控制提供了支配下的规范的方式来统一需求变更，并且基于业务和技术的因素来同意或者反对建议的变更。当在开发中修改、增加、减少需求时，软件开发计划应该随时更新，确保与新的需求保持一致。

4.2.2 需求规格说明书的版本控制
当需求发生变更时，应该清楚地把变更写成文档，并且随时通知所有涉及人员。为了尽量减少困惑、冲突和误传，应该仅允许指定的人员来更新需求。
每一个新版本的需求文档，应该公布其包括修正版本在内的历史情况，，例如变更的内容、变更日期、变更人员的姓名以及变更的原因等。
任何新文档的第一版应当标记为“1.0版（草案1）”，下一版本标记为“1.0版（草案2）”，在文档被确认为基线前，草案可以随着改进逐次增加，当文档被确认为基线后，标记为“1.0正式版”。以后有较小的修改，可以标记为“1.1版（草案1）”，如果有较大的修改，可以标记为“2.0版（草案1）”。

4.2.3 需求属性
需求属性：功能需求相关的信息。
例如在文档中的需求属性：

• 创建需求的时间；
• 需求的版本号；
• 创建需求的作者；
• 负责认可该软件需求的人员；
• 需求状态；
• 需求的原因和根据；
• 需求涉及的子系统；
• 需求涉及的产品版本号；
• 使用的验证方法或者接受的测试标准；
• 产品的优先级或者重要程度；
• 需求的稳定性。

4.2.4 需求变更
软件需求文档应该精确描述要交付的产品，这是一条基本原则。
为了使开发组织能够严格控制软件项目，应该确保以下事项：

• 仔细评估已建议的变更；
• 挑选合适的人选对变更做出决定；
• 变更应及时通知所有涉及的人员；
• 项目要按一定的程序来采纳需求变更。

1.变更控制过程
一旦确定了需求基线，应该使所有已建议的变更都遵循变更控制过程。
需求变更管理过程：

• 问题分析和变更描述
  识别和分析需求问题或者一份明确的变更提议，以检查它的有效性，从而产生一个更明确的需求变更提议。
• 变更分析和成本计算
  使用可追溯性信息和系统需求的一般知识，对需求变更提议进行影响分析和评估。变更成本计算应该包括对需求文档的修改、系统修改的设计和实现的成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。
• 变更实现
  这要求需求文档和系统设计以及实现都要同时修改。如果先对系统的程序做变更，然后再修改需求文档，这几乎无法避免出现需求文档和程序不一致。

需求变更控制过程是一个渠道和过滤器，通过它可以确保采纳最合适的变更，使变更产生的负面影响降到最低。变更过程应该形成文档，并且要简单、高效。
控制需求变更与项目的其他配置管理决策也有着密切的联系。
需求变更策略：
（1）所有需求变更必须遵循变更控制过程；
（2）对于未获得批准的变更，不应该做设计和实现工作；
（3）变更应该由项目变更控制委员会决定实现哪些变更；
（4）项目风险承担者应该能够了解变更数据库的内容；
（5）决不能从数据库中删除或者修改变更请求的原始文档；
（6）每一个集成的需求变更必须能跟踪到一个经核准的变更请求。

问题跟踪工具挑选考虑：
（1）可以定义变更请求的数据项；
（2）可以定义变更请求生存期的状态转换图；
（3）可以加强状态转换图使经授权的用户仅能做出所允许的状态变更。
（4）记录每一种状态变更的数据，确认做出变更的人员；
（5）可以定义在提交新请求或请求状态被更新后应该自动通知的设计人员；
（6）可以根据需要生成的标准的或定制的报告和图表。

2.变更控制委员会
广义上，变更控制委员会对项目中任何基线工作产品的变更都可以做出决定，需求变更文档仅是其中之一。
变更控制委员会可以由一个小组担任，也可以由多个不同的组担任。包括以下方面的代表：
（1）产品或计划管理部门；
（2）项目管理部门；
（3）开发部门；
（4）测试或质量保证部门；
（5）市场部或客户代表；
（6）制作用户文档的部门；
（7）技术支持部门；
（8）帮助桌面或用户支持热线部门；
（9）配置管理部门。
建立变更控制委员会在保证权威性的前提下应尽可能精简人员。
变更控制委员会应有一个总则，描述变更控制委员会的目的、授权范围、成员构成、做出决策的过程及操作步骤、举行会议的频度和事由。
过程和操作步骤：

1. 制定决策
2. 交流情况
3. 重新协商约定