议题
软件风险管理基础 与需求有关的风险 风险管理是你的好助手
软件风险管理基础
除了与项目范围和需求有关的风险外，项目还面临 着许多风险。依赖于外界实体，例如 个转包承揽 着许多风险。依赖于外界实体，例如一个转包承揽 者或生产重用部件的另一个项目就是一种常见的风 险来源。项目管理一直面临各种风险挑战：不准确 的估计、对准确估计的否决、对项目状态不清楚及 资金的周转的困难。 技术风险威胁着高度复杂或很前沿的开发项目，缺 乏知识是另 种风险源，以及参与者对所用的技术 乏知识是另一种风险源，以及参与者对所用的技术 和应用领域很陌生等等。强制的或总是变更的政府 规范会使一个很好的计划彻底作废。
风险管理的要素
风险管理就是使用某些工具和步骤把项目风险限制 在 个可接受的范围内。风险管理提供了 种标准 在一个可接受的范围内。风险管理提供了一种标准 的方法来指出风险并把风险因素编成文档，评估其 潜在的威胁，以及确定减少这些风险的战略。
编写项目风险文档
仅仅认识到项目面临的风险是远远不够的。应该将 其编写成文档并妥善进行管理，这样在整个项目开 发过程中有利于风险承担者了解风险情况和状态。
风险条目跟踪模板
制定风险管理计划
一张风险列表还不等于一个风险管理计划。对于一个小项目， 你可以把控制风险的计划放在软件项目管理计划里。但一个大 项目则需要一份独立的风险管理计划，包括用于识别、评估、 编写、跟踪风险的各种方法与途径。这份计划还应包括风险管 理活动的角色和责任。你可能希望专门让一个项目风险管理人 员负责可能引起麻烦的事。
化学制品跟踪系统的风险条目样例
与需求有关的风险
下面介绍的风险因素是按需求工程中获取、分析、 编写规格说明、验证和管理汇总起来的，并推荐了 一些方法用于降低风险发生的可能性或减轻风险发 生给项目带来的影响。 下面列出了在做需求分析时一些很危险的做法，如 果你发现你的一些做法与之相似，那么，给自己一 些时间，好好思考一下，这些做法会对你的软件产 生致命的影响。
需求获取相关风险(9-1)
产品视图与范围
如果团队成员没有对他们要做的产品功能达 成一个清晰的共识，则很可能导致项目范围 的逐渐扩大。因此最好在项目早期写一份项 目视图与范围将业务需求涵盖在内，并将其 作为新的需求及修改需求的指导。
需求获取相关风险(9-2)
需求开发所需时间
紧张的工程进度安排给管理者造成很大的压 力，使他们觉得不赶紧开始编码将无法按时 完成项目，因而对需求一带而过。项目因其 规模和应用种类不同（如信息系统，系统软 件，商业的或军事的应用）而有着很大的不 同。粗略的统计表明：需求开发工作应占全 部 作量的 部工作量的1 5 %（Rubin 1999）。记录你参 （ ） 记录你参 与的每个项目中实际需求开发的工作量，这 样就能知道所花的时间是否合适并改进将来 项目的工作计划。
需求获取相关风险(9-3)
需求规格说明的完整性和正确性
为确保需求是客户真正需要的，要以用户的 为确保需求是客户真 需要的 要以用户的 任务为中心，应用使用实例技术获取需求。 根据不同的使用情景编写需求测试用例，建 立原型，使需求对用户来说更加直观，同时 获取用户的反馈信息。让客户代表对需求规 格说明和分析模型进行正式的评审。
需求获取相关风险(9-4)
对革新产品的需求
有时容易忽略市场对产品的反馈信息。故要 有时容易忽略市场对产品的反馈信息 故要 强调市场调查研究，建立原型，并运用客户 核心小组来获得革新产品任务的反馈信息。
需求获取相关风险(9-5)
明确非功能需求
由于一般强调产品的功能性要求，非常容易 由于 般强调产品的功能性要求 非常容易 忽略产品的非功能性的需求。询问客户关于 产品性能、使用性、完整性、可靠性等质量 特性，编写非功能需求文档和验收标准， （像在S R S中一样）作为可接受的标准。
需求获取相关风险(9-6)
客户赞同产品需求
如果不同的客户对产品有不同的意见，那最 如果不同的客户对产品有不同的意见 那最 后必将有些客户会不满意。确定出主要的客 户，并采用产品代表的方法来确保客户代表 的积极参与，确保在需求决定权上有正确的 人选。
需求获取相关风险(9-7)
未加说明的需求
客户可能会有一些隐含的期望要求，但并未 客户可能会有 些隐含的期望要求 但并未 说明。要尽量识别并记录这些假设。提出大 量的问题来提示客户以充分表达他们的想法、 主意和应关注的一切。
需求获取相关风险(9-8)
把已有的产品作为需求基线
在升级或重做的项目中需求开发可能显得不很重 要。开发人员有时被迫把已有的产品作为需求说 明的来源。“只是修改一些错误和增加一些新特 性”，这时的开发人员不得不通过现有产品的逆 向工程(reverse engineering)来获取需求。可是， 逆向工程对收集需求是一种既不充分也不完整的 方法。因此新系统很可能会有 些与现有系统同 方法 因此新系统很可能会有一些与现有系统同 样的缺陷。将在逆向工程中收集的需求编写成文 档，并让客户评审以确保其正确性。
需求获取相关风险(9-9)
给出期望的解决办法
用户推荐的解决方法往往掩盖了用户的实际 需求，导致业务处理的低效，或者给开发人 员带来压力以至做出很差的设计方案。因此 分析人员应尽力从客户叙说的解决方法中提 炼出其本质核心。
需求分析相关的风险(3-1)
划分需求优先级
划分出每项需求、特性或使用实例的优先级 划分出每项需求 特性或使用实例的优先级 并安排在特定的产品版本或实现步骤中。评 估每项新需求的优先级并与已有的工作主体 相对比以做出相应的决策。
需求分析相关的风险(3-2)
带来技术困难的特性
分析每项需求的可行性以确定是否能按计划 实现。成功好象总是悬于一线的，于是运用 项目状态跟踪的办法管理那些落后于计划安 排的需求，并尽早采取措施纠正。
需求分析相关的风险(3-3)
不熟悉的技术、方法、语言、工具或硬件平台
不要低估了学习曲线中表明的满足某项需求所需要的新技 术的速度跟进情况。明确那些高风险的需求并留出一段充 裕时间从错误中学习、实验及测试原型。
需求规格说明相关的风险(4-1)
需求理解
开发人员和客户对需求的不同理解会带来彼 此间的期望差异，将导致最终产品无法满足 客户的要求。对需求文档进行正式评审的团 队应包括开发人员，测试人员和客户。训练 有素且颇有经验的需求分析人员能通过询问 客户一些合适的问题，从而写出更好的规格 说明。模型和原型能从不同角度说明需求， 这样可使一些模糊的需求变得清晰。
需求规格说明相关的风险(4-2)
时间压力对T B D的影响
将S R S中需要将来进 步解决的需求注上T S中需要将来进一步解决的需求注上T B D记号，但如果这些T B D并未解决，则将 给结构设计与项目的继续进行带来很大风险。 因此应记录解决每项T B D的负责人的名字， 如何解决的以及解决的截止日期。
需求规格说明相关的风险(4-3)
具有二义性的术语
建立一本术语和数据字典，用于定义所有的 建立 本术语和数据字典 用于定义所有的 业务和技术词汇，以防止它被不同的读者理 解为不同的意思。特别是要说明清楚那些既 有普通含义又有专用领域含义的词语。对S R S的评审能够帮助参与者对关键术语、概念等 达成一致的共识。
需求规格说明相关的风险(4-4)
需求说明中包括了设计
包含在S R S中的设计方法将对开发人员造成 不必要的限制并妨碍他们发挥创造性设计出 最佳的方案。仔细评审需求说明以确保它是 在强调解决业务问题需要做什么，而不是在 说怎么做。
需求验证相关的风险(2-1)
未经验证的需求
审查相当篇幅的S R S是有些令人沮丧 正如要 S是有些令人沮丧，正如要 在开发过程早期编写测试用例一样。但如果在构 造设计开始之前通过验证基于需求的测试计划和 原型测试来验证需求的正确性及其质量，就能大 大减少项目后期的返工现象。在项目计划中应为 这些保证质量的活动预留时间并提供资源。从客 户代表方获得参与需求评审的赞同（承诺），并 户代表方获得参与需求评审的赞同（承诺） 并 尽早且以尽可能低的成本通过非正式的评审逐渐 到正式评审来找出其存在的问题。
需求验证相关的风险(2-2)
审查的有效性
如果评审人员不懂得怎样正确地评审需求文 如果评审人员不懂得怎样 确地评审需求文 档和怎样做到有效评审，那么很可能会遗留 一些严重的问题。故要对参与需求文档评审 的所有团队成员进行培训，请组织内部有经 验的评审专家或外界的咨询顾问来讲课、授 教以使评审工作更加有效。
需求管理相关的风险(4-1)
变更需求
将项目视图与范围文档作为变更的参照可以 减少项目范围的延伸。用户积极参与的具有 良好合作精神的需求获取过程可把需求变更 减少近一半（ Jones 1996a）。能在早期发 现需求错误的质量控制方法可以减少以后发 生变更的可能。而为了减少需求变更的影响， 将那些易于变更的需求用多种方案实现，并 在设计时更要注重其可修改性。
需求管理相关的风险(4-2)
需求变更过程
需求变更的风险来源于未曾明确的变更过程 或采用的变动机制无效或不按计划的过程来 做出变更。应当在开发的各阶层都建立变更 管理的纪律和氛围，当然这需要时间。需求 变更过程包括对变更的影响评估，提供决策 的变更控制委员会，以及支持确定重要起点 步骤的工具。
需求管理相关的风险(4-3)
未实现的需求需求
跟踪能力矩阵有助于避免在设计、结构建立 跟踪能力矩阵有助于避免在设计 结构建立 及测试期间遗漏的任何需求。也有助于确保 不会因为交流不充分而导致多个开发人员都 未实现某项需求。
需求管理相关的风险(4-4)
扩充项目范围
如果开始未很好定义需求，那么很可能隔段 如果开始未很好定义需求 那么很可能隔段 时间就要扩充项目的范围。产品中未说明白 的地方将耗费比预料中更多的工作量，而且 按最初需求所分配好的项目资源也可能不按 实际更改后用户的需求而调整。为减少这些 风险，要对阶段递增式的生存期制定计划， 在早期版本中实现核心功能，并在以后的阶 段中逐步增加实现需求。
风险管理是你的好助手
项目管理人员可以运用风险管理来提高对造成项目 损失的条件的警惕，在需求获取阶段要有用户的积 极参与。精明的管理者不仅能认识到它能带来风险 的条件，而且将它编入风险清单，并依据以往项目 的经验估计其可能性和影响。 如果用户一直没有参与，风险危害值将会扩大以至 危害项目的成功。我曾说服管理人员把项目延期是 由于缺少用户的积极参与，我告诉他们不能把公司 的资金投入一项注定要失败的项目。
周期性的风险跟踪能使管理人员保持对风险危害变 化的了解，对那些并未得到完全控制的风险能得到 高层管理人员的注意。他们要么开始采取一些修正 措施，要么不管风险，依旧按原业务决策思路进行。 即使不能控制项目可能遇到的所有风险，风险管理 也能使你看清形势，做出的决策是有所依据。
议题
需求管理和过程能力成熟度模型 需求管理步骤 需求管 步骤 需求规格说明的版本控制 需求属性 度量需求管理的效果
将需求工程分为需求开发和需求管理。需求开发包 括对 个软件项目需求的获取、分析、规格说明及 括对一个软件项目需求的获取、分析、规格说明及 验证。典型需求开发的结果应该有项目视图和范围 文档、使用实例文档、软件需求规格说明及相关分 析模型。经评审批准，这些文档就定义了开发工作 的需求基线（ b a s e l i n e）。这个基线在客户和 开发人员之间就构筑了计划产品功能需求和非功能 需求的一个约定（ a g r e e m e n t）。工程项目可 能会有其它的约定，例如可交付性、约束条件、进 度安排、预算及合同约定等。但这些均超出了本书 范围。
需求约定是需求开发和需求管理之间的桥梁， 需求管理包括在工程进展过程中维持需求约 定集成性和精确性的所有活动，需求管理强 调：
控制对需求基线的变动。 保持项目计划与需求一致。 控制单个需求和需求文档的版本情况。 管理需求和联系链之间的联系或管理单个需求和 其它项目可交付品之间的依赖关系。 跟踪基线中需求的状态。
需求管理的主要活动
为达到软件过程能力成熟度模型的第二级，组织必 须具有在软件开发与管理的六个关键过程域（ key process areas，K PA）以展示达到目标的能力。需 求管理是其中之一，它的目标如下：
1) 把软件需求建立一个基线供软件工程和管理使用。 2) 软件计划，产品和活动同软件需求保持一致。
需求管理的关键过程领域不涉及收集和分析项目需 求。而是假定已收集了软件需求或已由更高 级的 求。而是假定已收集了软件需求或已由更高一级的 系统给定了需求。一旦需求到手且文档化了，软件 开发团队和有关的团队（例如质量保证和测试）需 要评审文档。发现问题应与客户或其它需求源协商 解决，软件开发计划是基于已确认的需求。
开发团队在向客户、市场部或经理们作出承诺（ c o m m i t m e n t）之前，应该确认需求和确认约束 条件、风险、偶然因素、假定条件。也许不得不面 对由于技术因素或进度原因而不现实的需求作出承 诺。但是，决不要承诺任何无法实现的事。
关键处理领域同样建议通过版本控制和变更控制来 管理需求文档。版本控制确保随时能知道在开发和 计划中正在使用的需求的版本情况。变更控制提供 了支配下的规范的方式来统一需求变更，并且基于 业务和技术的因素来同意或反对建议的变更。当在 开发中修改、增加、减少需求时，软件开发计划应 该随时更新以与新的需求保持一致。不反映现实的 计划于事无补。
当接受了所建议的变更时，你可能在进程调度或质量上不能满 足这项变更。在这种情况下，必须就约定的变更与所涉及的经 理、开发者以及其它相关组织进行协商。通过如下方法能使项 目反映最新的或变更过的需求。
? 暂时搁置次要需求。 ? 得到一定数量的后备人员。 ? 短期内带薪加班处理。 ? 将新的功能排入进度安排。 ? 为了保证按时交工使质量受些必要的影响（通常，这是缺省反应）。
由于项目在特性、进度、人员、预算、质量各个方 面的要求不同，所以不存在 个放之四海皆准的模 面的要求不同，所以不存在一个放之四海皆准的模 式。根据早期计划阶段中项目风险承担者确定的优 先级顺序挑选各项选择。不管你对变更需求或项目 情况（如全体职工工作完成量）采取何种措施，必 要时调整一些约定仍是需要养成的一个好习惯。这 总比不现实地期待所有新要求在原定交付日期前魔 术般地实现且其他方面（例如预算或员工工作强度） 不受什么影响要好。
需求管理步骤
开发组织应该定义项目组执行管理他们需求的步骤。文档化编 写这些步骤能使组织成员持续有效地进行必要的项目活动。请 考虑选择以下主题：
? 用于控制各种需求文档和单个需求版本的工具、技术和习惯做法。 ? 建议、处理、协商、通告新的需求和变更给有关的功能域的方法。 ? 如何制定需求基线。 ? 将使用的需求状态，并且是谁允许作出的变更。 ? 需求状态跟踪和报告过程。 ? 分析已建议变动的影响应遵循的步骤。 ? 在何种情况下需求变更将会怎样影响项目计划和约定。 在何种情况下需求变更将会怎样影响项目计划和约定
你可以在一个文档中包含上面所有的信息。或者，你可能喜欢 专题分述，例如分成变更控制过程，影响分析过程，状态跟踪 过程。这些过程可能在多个项目中都有用，因为他们反映每个 项目所应遵循的公共功能。
需求规格说明的版本控制
版本控制是管理需求的一个必要方面。需求文档的 每 个版本必须被统 确定。组内每个成员必须能 每一个版本必须被统一确定。组内每个成员必须能 够得到需求的当前版本，必须清楚地将变更写成文 档，并及时通知到项目开发所涉及的人员。为了尽 量减少困惑、冲突、误传，应仅允许指定的人来更 新需求。这些策略适用于所有关键项目文档。
每一个公布的需求文档的版本应该包括一个修正版 本的历史情况，即已做变更的内容、变更日期、变 更人的姓名以及变更的原因。你应该使用标准修改 符，例如，中划线代表取消，下化线代表添加，在 页边空白的竖划线指示每个变动的位置。因为这些 符号会弄乱文档，支持修改符的字处理软件使你能 够预览和打印编辑后的文档或最终的结果。可以考 虑给每个需求标记上版本号，当修改需求后就增加 版本号。
需求属性
除了文本，每个功能需求应该有一些相关的信息或 称之为属性与之相联系。这些属性在它的预期功能 性之外为每个需求建立了一个上下文和背景资料。 属性值可以写在一张纸上，存储在一个数据库或需 求管理工具中。商业工具除由系统产生一些属性外， 还可以由你自己定义各种数据类型的其它属性。这 些工具允许过滤、排序、查询数据库来察看按选择 的需求属性的需求集。
对大型的复杂项目来说，丰富的属性类别显得尤为重要。在你 的每个需求文档中考虑明确如下的属性：
? 创建需求的时间 ? 需求的版本号 ? 创建需求的作者 ? 负责认可该需求的人员 ? 需求状态 ? 需求的原因或根据（或信息的出处） ? 需求涉及的子系统 ? 需求涉及的产品版本号 需求 版 ? 使用的验证方法或接受的测试标准 ? 产品的优先级或重要程度（例如高、中、低或把你能定义的属性来表示描述 的优先级的四个方面：收益、损失、成本、风险） ? 需求的稳定性（在将来需求可能变更的指示器，不稳定的需求意味你应给予 较多的关注，因为你将面临不定的、混沌的、或不能重复的业务过程。）
定义和更新这些属性值是需求管理成本的一部分。 精心挑选属性最小子集能帮助你有效管理项目。例 如，你不必把负责认可需求的人员和需求涉及的子 系统都记录下来。如果这样的属性在别的地方已经 设置了，在总的开发跟踪系统中就不必在需求数据 库中重复设置。
在整个开发过程中，跟踪每个需求的状态是需求管 理的 个重要方面。在每 可能的状态类别中，如 理的一个重要方面。在每一可能的状态类别中，如 果你周期性地报告各状态类别在整个需求中所占的 百分比将会改进项目的监控工作。假如你有清晰的 要求，指定了允许修改状态信息的人员和每个状态 变更应满足的条件，跟踪需求状态才能正常工作。 工具能帮你跟踪每次状态改变的日期。
建议的需求状态表
状态值 已建议 已批准 定义 该该需求已被有权提出需求的人建议 该需求已被分析，估计了其对项目余下部分的影响（包 括成本和对项目其余部分的干扰），已用一个确定的产 品版本号或创建编号分配到相关的基线中，软件开发团 队已同意实现该项需求 已实现需求代码的设计、编写和单元测试 使用所选择的方法已验证了实现的需求，例如测试和检 测，审查该需求跟踪与测试用例相符。该需求现在被认 为完成 该计划的需求已从基线中删除，但包括一个原因说明和 做出删除决定的人员
已实现 已验证
已删除
在整个项目开发周期中跟踪需求状态的分布
度量需求管理的效果
在每个项目的工作分类细目结构中需求管 理活动应该表现为分配有资源的任务。测 理活动应该表现为分配有资源的任务 测 算当前项目中的需求管理成本，是计划未 来需求管理工作或经费的最佳途径。
一个从未度量过工程任何一个方面的组织通常发现 很难开始保持 个耗时记录。测算实际开发和项目 很难开始保持一个耗时记录。测算实际开发和项目 管理的工作量要求一个文化上的改变和养成记录日 常工作的习惯。然而，测算并不像人们所担心的那 样花费时间，了解成员花费在各个项目任务上的确 切工作量会使你获得有价值的资料。应该注意到工 作量计算与翻过的日历时间不成正比，任务进度可 能被打断或因同客户协商造成拖延。每个单元的工 作时数总和表明一个任务的工作量，这个数据没必 要随外界因素变化，但总体上却要比原计划长一些。
跟踪实际的需求管理效果能使你了解组员是否采取 了措施进行需求管理。执行需求管理措施不得力， 会由于不受约束的变更、范围延伸和遗漏需求等原 因而增加项目的风险。考虑一下需求管理的下列活 动的效果：
? 提出需求变更和已建议的新需求。 ? 评估已建议的变更，包括影响分析。 ? 变更控制委员会活动。 ? 更新需求文档或数据库。 ? 在涉及人员或团队中交流需求的变更。 ? 跟踪和报告需求状态。 ? 定义和更新需求跟踪能力信息。
尽管忽视和效率不高会随时发生，管理项目需求能 确保你投资到需求的收集、归档和分析的努力没有 白费。有效的需求管理策略能在整个开发过程中使 项目参与者获悉需求的当前状态信息，从而减少大 家在需求认识上的差距。
议题
控制项目范围的扩展 变更控制过程 变更控制委员会 测量变更活动
不被控制的变更是项目陷入混乱、不能按 进度执行或软件质量低劣的共同原因。为 进度执行或软件质量低劣的共同原因 为 了使开发组织能够严格控制软件项目应确 保以下事项：
? 应仔细评估已建议的变更。 ? 挑选合适的人选对变更做出决定。 ? 变 应 时 知所有涉 的人 变更应及时通知所有涉及的人员。 ? 项目要按一定的程序来采纳需求变更。
只有项目风险承担者在开发过程中能控制变更，他 们才知道将交付什么，哪 项将会导致与目标的差 们才知道将交付什么，哪一项将会导致与目标的差 距。对项目越深入了解后，你就越能发现采纳变更 需求条件的苛刻。在需求文档中一定要反映项目的 变更，需求文档应精确描述要交付的产品，这就是 你的原则。要是软件需求文档同产品不一致，那它 就毫无用处，甚至就象没有一个软件需求文档来指 导开发组开发一样。
当你不得不做出变更时，应该按从高级到低级的顺 序对被影响的需求文档进行处理。举个例子， 个 序对被影响的需求文档进行处理。举个例子，一个 已建议的变更可能影响一个使用实例和功能需求但 不影响任何业务需求。改动高层系统需求能够影响 多个软件需求。如果在最低层需求上做出变更， （典型的情况是一个功能性需求），可能会导致需 求同上层文档不一致。
控制项目范围的扩展
扩展需求是指在软件需求基线已经确定后又要增添 新的功能或进行较大改动。问题不仅仅是需求变更 本身，而是迟到的需求变更会对已进行的工作有较 大的影响。要是每个建议的需求都被采纳，对于项 目出资者（ s p o n s o r）、参与者与客户来说项目 将永远也不会完成—事实上，这是不可能的。
对许多项目来说，一些需求的改进是合理的且不可 避免。业务过程、市场机会、竞争性的产品和软件 技术在开发系统期间是可以变更的，管理部门也会 决定对项目做出一些调整。 在你的项目进度表中应该对必要的需求改动留有余 地。若不控制范围的扩展将使我们持续不断地采纳 新的功能，而且要不断地调整资源、进度、或质量 目标，这样做极其有害。这儿 点小的改动，那儿 目标，这样做极其有害。这儿一点小的改动，那儿 一点添加，很快项目就不可能按客户预期的进度和 预期质量交付使用了。
管理范围扩展的第一步就是把新系统的视图、范围、 限制文档化并作为业务需求的 部分，评估每 项 限制文档化并作为业务需求的一部分，评估每一项 建议的需求和特性，将它与项目的视图和范围相比 较决定是否应该采纳它。强调客户参与的有效的需 求获取方法能够减少遗漏需求的数量，只在做出提 交承诺和分配资源后才采纳该需求。控制需求扩展 的另一个有效的技术是原型法，这个方法能够给用 户提供预览所有可能的实现，以帮助用户与开发者 沟通从而准确把握用户的真实需求。
变更控制过程
一个好的变更控制过程给项目风险承担者提供了正 式的建议需求变更机制。通过这些处理过程，项目 负责人（ l e a d e r）可以在信息充分的条件下做出 决策，这些决策通过控制产品生存期成本来增加客 户和业务价值。你通过变更控制过程来跟踪已建议 变更的状态，确保不会丢失或疏忽已建议的变更。 一旦你确定了一个需求集合的基线，你应该对所有 已建议的变更都遵循变更控制过程。
变更控制过程并不是给变更设置障碍。相反地，它 是 个渠道和过滤器，通过它可以确保采纳最合适 是一个渠道和过滤器，通过它可以确保采纳最合适 的变更，使变更产生的负面影响减少到最小。变更 过程应该做成文档，尽可能简单，当然首要的是有 效性。如果变更过程没有效率且冗长，又很复杂， 大家宁愿用旧方法来做出变更决定（或许他们应该 那样做）。
控制需求变更同项目其它配置管理决策紧密相连。 管理需求变更类似于跟踪错误和做出相应决定过程， 相同的工具能支持这两个活动。然而记住它是工具 而不是过程。使用商业问题跟踪工具来管理已建议 的需求变更并不能代替写下变更需求的内容和处理 的过程。
变更控制策略
项目管理应该达成一个策略，它描述了如何处理需求变更。策 略具有现实可行性，要被加强才有意义。下述需求变更的策略 是有用的：
? 所有需求变更必须遵循的过程，按照此过程，如果一个变更需求未 被采纳，则其后过程不再予以考虑。 ? 对于未获批准的变更，除可行性论证之外，不应再做其它设计和实 现工作。 ? 简单请求一个变更不能保证能实现变更，要由项目变更控制委员会 （ C C B）决定实现哪些变更（本章将讨论C C B）。 ? 项目风险承担者应该能够了解变更数据库的内容 项目风险承担者应该能够了解变更数据库的内容。 ? 绝不能从数据库中删除或修改变更请求的原始文档。 ? 每一个集成的需求变更必须必须能跟踪到一个经核准的变更请求。
有一个项目它由两大部分组成，一个是用户集成界 面应用，另 个是内部知识库，但缺乏变更过程。 面应用，另一个是内部知识库，但缺乏变更过程。 当知识库开发人员改变了外部界面但没有将此变更 通知应用开发人员，这个项目就碰到了麻烦。还有 一个项目，开发人员在测试时才发现有人应用了新 的已被修改的功能却没有通知小组中其余人员，导 致重做了测试程序和用户文档。采用统一的变更控 制方法可以避免这样的问题所带来的错误、开发的 返工和耗费时间。
变更控制步骤
下面主要讨论关于过程是如何处理需求变更 的。步骤中的4个组件和若干个过程描述将 的 步骤中的4个组件和若干个过程描述将 会是很有用的：
? 开始条件（ entry criteria）—在执行过程或步骤前应该满足 的条件。 ? 过程和步骤中所包含的不同任务（ t a s k）及项目中负责完 成它们的角色。 ? 验证（v e r i f y）任务正确完成的步骤。 ? 结束条件（ exit criteria）—指出过程或步骤完成的条件。
简单变更控制步骤模板
a. 绪论
a.1 目的 a.2 a 2 范围 a.3 定义
b. 角色和责任 c. 变更请求状态 d. 开始条件 e. 任务
e.1 产生变更请求 e.2 评估变更请求 e.3 作出决策 e.4 通知变更人员 4
f. 验证 g. 结束条件 h. 变更控制状态报告 附录：存储的数据项
变更管理活动中可能的项目角色
变更需求状态转换图
常见变更请求数据项
挑选工具时可以考虑以下几个方面
可以定义变更请求的数据项。 可以定义变更请求生存期的状态转换图。 可以定义变更请求生存期的状态转换图 可以加强状态转换图使经授权的用户仅能做出所允 许的状态变更。 记录每一种状态变更的数据，确认做出变更的人员。 可以定义在提交新请求或请求状态被更新后应该自 动通知的设计人员。 可以根据需要生成标准的或定制的报告和图表。
变更控制委员会
软件开发活动中公认变更控制委员会或C C B（有 时也称为结构控制委员会）为最好的策略之 时也称为结构控制委员会）为最好的策略之一 （McConnell 1996）。变更控制委员会可以由一个 小组担任，也可由多个不同的组担任，负责做出决 定究竟将哪一些已建议需求变更或新产品特性付诸 应用。典型的变更控制委员会同样决定在哪一些版 本中纠正哪一些错误。许多项目已经有负责变更决 策的人员，而正式组建变更控制委员、制定操作步 骤会使他们更有效地工作。
广义上，变更控制委员会对项目中任何基线工作产 品的变更都可做出决定，需求变更文档仅是其中之 一。大项目可以有几级控制委员会，有些负责业务 决策（例如需求变更），另一些负责技术决策 （ Sorensen 1999）。有些变更控制委员会可以独 立做出决策，而有些只是负责决策的建议工作。高 级变更控制委员会做出的决策对计划的影响应比低 级的大。小项目中，只需一两个人就可做出所有决 策。
变更控制委员会的组成
变更控制委员会的成员应能代表变更涉及的团体。 变更控制委员会可能包括如下方面的代表：
产品或计划管理部门。 项目管理部门。 开发部门。 测试或质量保证部门。 市场部或客户代表。 制作用户文档的部门。 技术支持部门。 帮助桌面或用户支持热线部门。 配置管理部门。
变更控制委员会总则
设立变更控制委员会的第一步是写一个总则，描述 变更控制委员会的目的、授权范围、成员构成、做 出决策的过程及操作步骤（ Sorensen 1999）。总 则也应该说明举行会议的频度和事由。管理范围是 指该委员会能做什么样的决策，及哪种决策应上报 到高一级的委员会。
制定决策 交流情况 重新协商约定
变更总是有代价的。即使拒绝的变更也因为决策行为（提交、 评估、决策）而耗费了资源。变更对新的产品特性会有很大的 影响。向一个工程项目中增加很多功能，又要求在原先确定的 进度计划、人员安排、资金预算和质量要求限制内完成整个项 目是不现实的。当工程项目接受了重要的需求变更时，为了适 应变更情况要与管理部门和客户重新协商约定
测量变更活动
软件测量是深入项目、产品、处理过程的调查研究，比起主观 印象或对过去发生事情的模糊回忆要精确得多。测量方法的选 择应该由所面临的问题和要达到的目标为依据。测量变更活动 是评估需求的稳定性和确定某种过程改进时机（ o p p o r t u n i t y）的一种方法，这种时机可以减少未来的变更请求。需 求变更活动的下列方面值得考虑
接收、未作决定、结束处理的变更请求的数量。 已实现需求变更（包括增、删、改）的合计数量（也可以用在基线上占需 求总数的百分比来表示）。 每个 每个方面发出的变更请求的数量。 变 请求 数 每一个已应用的需求（是指已划过基线）建议变更和实现变更的数量。 投入处理变更的人力、物力。
需求变化活动的样本图
需求变更起源的样本图