|
|
|
|
|
扩展需求是指在软件需求基线已经确定后又要增添新的功能或进行较大改动。
|
|
|
|
|
|
.把新系统的视图、范围、限制文档化并作为业务需求的一部分，将每一项建议的需求与项目的视图和范围相比较决定是否应该采纳。
|
|
|
|
.原型法：能够给用户提供预览所有可能的实现，以帮助用户与开发方沟通从而准确把握用户的真实需求。
|
|
|
|
|
|
|
|
|
|
.所有需求变更必须遵循的过程，按照此过程，如果一个变更需求未被采纳，则其后过程不再予以考虑。
|
|
|
|
.对于未获批准的变更，除可行性论证之外，不应再做其他设计和实现工作。
|
|
|
|
.简单请求一个变更不能保证能实现变更，要由项目变更控制委员会决定实现哪些变更。
|
|
|
|
|
|
|
|
.每一个集成的需求变更必须能跟踪到一个经核准的变更请求。
|
|
|
|
变更控制状态报告是用报告、图表来总结变更控制数据库的内容和按状态分类的变更请求数量。项目管理人员通常使用这些报告来跟踪项目状态。
|
|
|
|
变更控制过程可以通过自动工具来执行，挑选工具时应该注意以下几个方面：
|
|
|
|
|
|
|
|
.可以加强状态转换图，使经授权的用户仅能作出所允许的状态变更。
|
|
|
|
|
|
.可以定义在提交新请求或请求状态被更新后应该自动通知的设计人员。
|
|
|
|
|
|
|
|
变更控制委员会可以由一个小组担任，也可由多个不同的组担任，负责做出决定究竟将哪一些已建议需求变更或新产品特性付诸应用，其人员可以包括：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
