第七讲面向对象分析.ppt

需求管理 需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。需求管理强调： 控制对需求基线的变动。 保持项目计划与需求一致。 控制单个需求和需求文档的版本情况。 管理需求和跟踪链之间的联系或管理单个需求和其他项目可交付物之间的依赖关系。 跟踪基线中需求的状态。 需求管理的主要活动 需求管理 需求跟踪 定义对其 他需求的 跟踪链 定义对其 他系统需 求的跟踪 链 版本控制 确定需求 文档版本 确定单个 需求文档 版本 需求状态跟踪 定义需求状 态 跟踪需求的 每一状态 变更控制 建议变更 分析影响 做出决策 交流 合并 测量需求 的稳定性 需求的变更控制 对于很多软件项目来说，需求变更是合理的，而且是不可避免的。 如果对需求的变更不加控制，持续不断地返工，持续不断地调整资源、进度或质量目标，会导致开发过程混乱，开发成本上升和开发进度延误，同时导致产品质量的下降。所以，必须严格控制需求的变更。 变更控制的策略 变更控制的策略描述如何处理需求变更。 所有需求的变更必须遵循一个变更控制的过程，如果一个变更请求未被批准，则其后续过程不再予以考虑。 对于未获批准的变更，除可行性论证之外，不应再做其他设计和实现工作。 提交一个变更请求不能保证该变更一定能实现，要由项目变更控制委员会决定实现哪些变更。 项目风险承担者应该能够了解变更数据库的内容。 绝不能从数据库中删除或修改变更请求的原始文档。 每一个集成的需求变更必须必须能跟踪到一个经核准的变更请求。 变更控制委员会（CCB） 变更控制委员会的主要工作是： 制定决策。对每个变更权衡利弊后做出决定。 交流情况。一旦变更控制委员会做出决策，应及时更新变更数据库中请求的状态，通知所有相关人员，保证他们能充分处理变更。 重新协商约定。当软件开发组接受了重要的需求变更时，要与管理部门和客户重新协商约定。协商内容包括推迟“交货”时间、要求增加人手、推迟实现尚未实现的较低优先级的需求，或者质量上进行折衷。 变更控制的步骤 开始条件：变更控制的开始条件是通过合适的渠道接受一个合法的变更请求。 任务： 1) 接受一个新的变更请求后评估该变更的技术可行性、代价、业务需求和资源限制。 CCB要求评估者做系统的影响分析、风险分析和危害分析，了解变更可能带来的潜在影响，根据评估结果决定是批准变更请求还是拒绝变更请求。 CCB给每一个批准的变更需求设定一个优先级或变更实现日期，并通过更新请求状态和通知所有相关小组来传达变更决定。 变更人员者更新相关的工作制品。 通过评审确保更新后的软件需求规格说明、用例、分析模型都正确地反映变更的各个方面。 使用跟踪能力信息找出受变更影响的系统的各个部分，确认它们也实现了变更。 变更人员安装更新后的部分工作产品并通过调试使之能与其他部分正常工作。 结束条件： 变更请求的最终状态应为“被拒绝”、“结束”或“已取消”。 所有修改后的工作产品安装至合适位置。 变更请求的提交者、CCB主席、项目经理和其他相关的项目参与者都已经注意到了变更的细节和当前的状态。 为已完成修改并成功安装的工作制品建立了新版本并给予了版本号。 已经更新需求跟踪能力矩阵。 版本控制是为了管理软件需求规格说明文档。它主要的活动是统一标识需求规格说明文档的每一个版本，并让每一个开发组的成员能够获得和使用他所需要的任一版本。 版本控制最简单的方法是根据约定，标记软件需求规格说明的每一次修改。 需求规格说明的版本控制 为已完成修改并成功安装的工作制品建立了新版本并给予了版本号。 已经更新需求跟踪能力矩阵。 版本控制是为了管理软件需求规格说明文档。它主要的活动是统一标识需求规格说明文档的每一个版本，并让每一个开发组的成员能够获得和使用他所需要的任一版本。 版本控制最简单的方法是根据约定，标记软件需求规格说明的每一次修改。 需求规格说明的版本控制 需求跟踪 需求跟踪是为了确保所有需求都被实现。同时，使用跟踪能力信息，确保在变更需求时不遗漏每个受到影响的系统元素，包括其他需求、体系结构、源代码、测试用例、帮助文件、文档等。 需求跟踪链 通过需求跟踪链，可以在整个软件生存周期中跟踪一个需求的使用和更新情况。 Jarke提出了4类需求跟踪能力链 (1) 第一个链是从用户需求向前追溯到软件需求: 区分开发过程中或开发结束后由于用户需求变更受到影响的软件需求； 确保软件需求规格说明中包含了所有的用户需求。 需求 追溯到 需求 用户 需求 从需求 回溯 下游工 作制品 追溯到 下游制品 向需求 回溯 (2) 第二个链是从软件需求回溯到相应的用