需求变更管理的应对六大原则.docx

需求变更是因为需求发生变化。 根据软件工程思想， 需求说明书一般要经过论证， 如果在需求说明书经过论证以后， 需要在原有需求基础上追加和补充新的需求或 对原有需求进行修改和削减，均属于需求变更。 需求变更的出现主要是因为在项目的需求确定阶段， 用户往往不能确切地定 义自己需要什么。 用户常常以为自己清楚， 但实际上他们提出的需求只是依据当 前的工作所需，而采用的新设备、新技术通常会改变他们的工作方式 ;或者要开 发的系统对用户来说也是个未知数， 他们以前没有过相关的使用经验。 随着开发 工作的不断进展， 系统开始展现功能的雏形， 用户对系统的了解也逐步深入。 于 是， 他们可能会想到各种新的功能和特色， 或对以前提出的要求进行改动。 他们 了解得越多，新的要求也就越多，需求变更因此不可避免地一次又一次出现。 这时， 如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无 效， 抑或不按变更控制流程来管理需求变更， 那么很可能造成项目进度拖延、 成 本不足、人力紧缺，甚至导致整个项目失败。当然，即使按照需求变更控制流程 进行管理， 由于受进度、 成本等因素的制约， 软件质量还是会受到不同程度的影 响。 但实施严格的软件需求管理会最大限度地控制需求变更给软件质量造成的负 面影响，这也正是我们进行需求变更管理的目的所在。 实施需求变更管理需要遵循以下六大原则 (1) 建立需求基线，需求基线是需求变更的依据。在开发过程中，需求确定 并经过评审后 (用户参与评审 )， 可以建立第一个需求基线。 此后每次变更并经过 评审后，都要重新确定新的需求基线。 (2) 制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提 出的所有变更都必须遵循这个控制流程进行控制。 同时， 这个流程具有一定的普 遍性，对以后的项目开发和其他项目都有借鉴作用。 (3) 成立项目变更控制委员会 (CCB)或相关职能的类似组织， 负责裁定接受哪 些变更。 CCB由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决 策人员在内。 (4) 需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评 审确认。 (5) 需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以 保持和更新的需求一致。 (6) 妥善保存变更产生的相关文档。 应对之道 需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如 果变更被接受， 还要增加实施变更和验证两个步骤， 有时还会有取消变更的步骤。 1 / 7 针对变更控制流程， 在实际工作中总结出了软件开发人员在需求变更管理实践中 的几点对策： 优先排序 分批实现 每个需求的重要性是不同的。由于资源或技术条件的 限制，会显得“僧多粥少”，因此不可能把所有的需求一次完成。怎么办 ?把每 个需求按照对效益的贡献打个分， 排出个优先级来， 优先级高的需求先实现， 低 的到一下版式本实现。 由于不断有新的需求进来， 有的需求可能永远没有机会被 子实现，但不紧，还是要记录下来，并一起参加排序，保证在每个版本发布时重 要的需求先得到满足。 每个需求的实现是需要花时间的， 没人有百分百的把握预 估得很清楚， 但借鉴过去的经验可以大概估算出人力成本， 然后根据开发人员和 开发周期得出可用人力投入作为上限。 从优先级高的需求中挑， 直到挑中的人力 成本总和刚刚低于可用投入上限， 这样得出的就是需求的录取榜。 今后的软件开 发规划也会以此为依据， 分期分批地在不同的回合中实现。 最合理的不一定是优 先级最高的， 也就是说不一不定是最先考虑的， “经济为本”是指导优先排序的 最终原则。 相互协作 很难想像遭到用户抵制的项目能够成功。 在讨论需求时， 开发人 员与用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。 即使用户提出了在开发人员看来 过分 的要求， 也应该仔细分析原因， 积极提出 可行的替代方案。 充分交流 需求变更管理的过程很大程度上就是用户与开发人员的交流过 程。 软件开发人员必须学会认真听取用户的要求、 考虑和设想， 并加以分析和