系统分析员应该协调最好由变更控制委员会 (CCB) 执行的复审活动，收集并检查所有的变更请求，并将它们分类为：
实施中不影响需求的缺陷， 对现有的某类型需求的修改，或者 扩展修改。
分类后，按在其他需求工作流程中描述的方法为所提出的需求变更指定属性和值。
在复审变更请求的时候，系统分析员向一个由涉众代表和项目团队成员组成的 CCB 陈述确定优先顺序的需求变更。超过资源限制的规模修改请求被拒绝，或者将其上交给涉众代表，涉众代表有权批准对日期以及预算事项的必需变更。
CCB 批准或拒绝需求变更。
系统分析员把需求变更传达给需求阐释者，或直接修改前景、用例、补充规约文档或其他需求工件中的需求。
需求复审员(开发人员、测试员、经理及其他团队成员)通过审查需求历史，对需求变更对他们的工作造成的影响进行评估。最后，他们实施变更，对他们有权修改的相关需求作适当改动。
总结
管理需求的需要并不新鲜。那么，究竟是什么值得我们去思考呢?
首先，如果项目常常不能满足客户、错过最后期限和预算超支，就有理由重新考虑开发方案了。在设计方案时，如果您确信与需求相关的问题正在消耗你的开发工作，就有理由考虑改进需求管理了。
其次，本文总结的需求管理方案体现了几千个案例的集体经验和智慧，而且代表了许多个人深思熟虑的观点，他们在需求管理领域与客户合作已有数年时间。我们认为，他们的贡献 - 以及 Rational Unified Process 对这些贡献所作的透彻陈述 - 总结起来代表了需求管理的“最佳方案”。你将发现这些需求建议是最可靠的。
作者向 Dr. Ivar Jacobson 对本文的直接和间接贡献，以及 Dean Leffingwell、Dr. Alan Davis、Ed Yourdon 和 Elemer Magaziner等人的帮助表示感谢。尤其，我们要感谢 Rational Software 的客户，他们在数以百计开发项目中应用和改进了这些方案。
最后，在过去的两年内，生产有效软件开发解决方案的领先公司 Rational Software 接受需求管理的挑战，生产了多种工具来使执行这一艰巨任务实现自动化。长期、普遍存在的需求管理问题得到了解决。也许这最终才是今天在需求管理领域开始追求卓越的最佳原因。
关于上述概念的完整论述，请参考 Dean Leffingwell 的关于软件需求管理的优秀著作[7]。
参考资料
[1] CHAOS, The Standish Group International, Inc., Dennis, MA, 1994, 1997.
[2] Computer Industry Daily, December 12, 1997.
[3] Dorfman, M. and R. Thayer, Software Engineering, IEEE Computer Society Press,
Los Alamitos, CA, 1997 pp.79.
[4] Dorfman, M. and R. Thayer, Software Engineering, IEEE Computer Society Press,
Los Alamitos, CA, 1997 pp.80.
[5] Spence, Ian and Leslee Probasco, “通过用例进行需求管理的可追踪性策略”, 白皮书, Rational Software Corporation, 1998.
[6] Rational Unified Process?, Rational Software Corporation, Cupertino, CA, 1999.
[7] Leffingwell, Dean and Don Widrig, Managing Software Requirements - A Unified Approach, Addison-Wesley, 2000.
文章来源于领测软件测试网 https://www.ltesting.net/
