CMM中的需求理与需求开发.docVIP

需求管理（Requirements Management）是属于CMM2中的过程域，简称为REQM，需求开发（Requirements Development）是CMM3中的过程域，简称RD。这两个过程域是CMMI体系中关于需求的全部内容，下面分别对这两部分进行介绍。本文对CMM的一些基础知识、基础术语不再介绍。 需求管理与需求开发的分界线： 大家可以这样理解，需求管理是指对需求变更的管理、对需求的跟踪，而获取需求、定义需求则属于需求开发部分。 需求管理 在CMMI中，需求管理的目标定义为： a. 把软件需求建立一个基线供软件工程和管理使用。 b. 软件计划、活动和工作产品同软件需求保持一致。 更高的目标： 软件需求的复用 需求管理的原则和方法 a. 必须与需求工程的其他活动紧密整合 b. 需求必须是文档化的、正确的、最新的、可管理的、可理解的 c. 只要需求变化了，需求变更的影响就必须被评估 d. 需求必须分优先级 e. 需求一定要分类管理 需求管理的主要工作： 特定目标和特定实践 特定目标 管理需求 管理需求并识别需求与项目计划和工作产品之间的差 异。 SP 1.1 取得需求理解 SP 1.2 取得需求承诺 SP 1.3 管理需求变更 SP 1.4 维护需求的双向追溯性 SP 1.5 识别项目工作与需求间的差异 REQM特定目标的关系 SP 1.1 取得需求理解 SP 1.1 和需求提出者一同来了解需求。 l 识别出谁是需求的提供者 l 识别出需求的接受标准： a. Clearly and properly stated得到清晰和恰当的定义 b. Complete完整的 c. Consistent with each other相互一致的 d. Uniquely identified得到唯一标识的 e. Appropriate to implement适宜实现 f. Verifiable (testable)可以验证（测试） g. Traceable可追溯 l 分析需求，确保符合已建立的准则。 l 与需求提供者达到需求共识，以使项目成员能承诺它们 SP1.2 获取对需求的承诺 SP1.2 取得项目成员对需求的承诺。 评估需求对现有承诺的影响。 需求变更或新需求发生时，评估它们对项目成员的影 响。 协商并记录承诺。 在项目成员对需求或需求改变承诺之前，对现有承诺 的改变应先进行协商。 承诺的时间点： a. 需求刚建立时 b. 需求变更时 产出物 需求影响评估 需求和需求变更承诺的纪录 项目组成员工作任务书 SP 1.3 管理需求变更 SP 1.3 当需求在项目执行期间逐渐开发时，管理 需求的变更。 在项目执行期间，造成需求变更的原因很多： a. 需要改变 b. 工作进行中产生新需求 提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。对项目开发小组而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发小组要为此付出较重的代价。如果每次需求变更请求都被采纳的话，这个项目也许永远不能按时完成。 配置变更委员会CCB CCB是授权进行正式基线变更的机构 例如客户需求、设计基线。。。 职能： 确保变更被分类以及被评估 评审和批准变更 确保只有被批准的变更得到实施 决定需要实施的变更的优先级 变更控制活动必须在整个项目中具有可视性 CCB成员可能包括：项目经理，配置管理员，质量保证人员，开发人员代表，客户代表。 需求变更的阶段 提交 评估 审批 实施 验证 关闭 产出物 需求变更申请表 需求变更汇总表 SP 1.4 维护需求的双向追溯性 维护需求与项目计划和工作产品间的双向追溯性。 产出物： 需求跟踪矩阵 需求跟踪矩阵的主要作用 RTM的作用 A、验证需求的可实现性、可测试性 B、进行需求变更的影响分析 C、维护阶段，管理需求的变更 需求跟踪矩阵分为：纵向跟踪和横向跟踪 应该建立哪些需求跟踪矩阵？ 在SEI的调查中达成的基本共识是：纵向跟踪是必须的，如果没有，则REQM SP1.4无法通过。 对于纵向跟踪矩阵： 必需的： 客户需求与产品需求的跟踪 产品需求与测试用例的跟踪 100%的接口需求 全局性需求 核心需求 并非必需的： 性能需求 不影响系统架构的功能需求 需求跟踪矩阵由谁来建立？ 有多个角色参与建立RTM： a. 需求开发人员 b. 设计人员 c. 测试用例的编写人员 d. PPQA RTM是否纳入基线管理？ RTM要纳入基线管理。 纳入基线后，每次变更都要申请，RTM的变更一般是和其他配置项的变更一起申请，很少单独申请变更RTM，除非RTM有错误。 如何简化RTM的工作？ 由于在RTM中，需求可能有很多项，设计、测试用例、代码等都有多项，所以建立和维护RTM的工作