CMM中的需求管理及需求开发.doc

需求管理（Requirements Management）是属于CMM2中的过程域，简称为REQM，需求开发（Requirements Development）是CMM3中的过程域，简称RD。这两个过程域是CMMI体系中关于需求的全部内容，下面分别对这两部分进行介绍。本文对CMM的一些基础知识、基础术语不再介绍。需求管理与需求开发的分界线： 大家可以这样理解，需求管理是指对需求变更的管理、对需求的跟踪，而获取需求、定义需求则属于需求开发部分。需求管理在CMMI中，需求管理的目标定义为：a. 把软件需求建立一个基线供软件工程和管理使用。b. 软件计划、活动和工作产品同软件需求保持一致。更高的目标：软件需求的复用需求管理的原则和方法a. 必须与需求工程的其他活动紧密整合b. 需求必须是文档化的、正确的、最新的、可管理的、可理解的c. 只要需求变化了，需求变更的影响就必须被评估d. 需求必须分优先级e. 需求一定要分类管理需求管理的主要工作：特定目标和特定实践 特定目标l 管理需求管理需求并识别需求与项目计划和工作产品之间的差异。l SP 1.1 取得需求理解l SP 1.2 取得需求承诺l SP 1.3 管理需求变更l SP 1.4 维护需求的双向追溯性l 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 取得项目成员对需求的承诺。l 评估需求对现有承诺的影响。需求变更或新需求发生时，评估它们对项目成员的影响。l 协商并记录承诺。在项目成员对需求或需求改变承诺之前，对现有承诺的改变应先进行协商。l 承诺的时间点：a. 需求刚建立时b. 需求变更时产出物l 需求影响评估l 需求和需求变更承诺的纪录l 项目组成员工作任务书SP 1.3 管理需求变更SP 1.3 当需求在项目执行期间逐渐开发时，管理需求的变更。l 在项目执行期间，造成需求变更的原因很多：a. 需要改变b. 工作进行中产生新需求l 提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。对项目开发小组而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发小组要为此付出较重的代价。如果每次需求变更请求都被采纳的话，这个项目也许永远不能按时完成。配置变更委员会CCBl CCB是授权进行正式基线变更的机构 例如客户需求、设计基线。l 职能： 确保变更被分类以及被评估 评审和批准变更 确保只有被批准的变更得到实施 决定需要实施的变更的优先级l 变更控制活动必须在整个项目中具有可视性l CCB成员可能包括：项目经理，配置管理员，质量保证人员，开发人员代表，客户代表。需求变更的阶段l 提交l 评估l 审批l 实施l 验证l 关闭产出物l 需求变更申请表l 需求变更汇总表SP 1.4 维护需求的双向追溯性l 维护需求与项目计划和工作产品间的双向追溯性。l 产出物：需求跟踪矩阵需求跟踪矩阵的主要作用RTM的作用A、验证需求的可实现性、可测试性B、进行需求变更的影响分析C、维护阶段，管理需求的变更需求跟踪矩阵分为：纵向跟踪和横向跟踪应该建立哪些需求跟踪矩阵？l 在SEI的调查中达成的基本共识是：纵向跟踪是必须的，如果没有，则REQM SP1.4无法通过。l 对于纵向跟踪矩阵： 必需的： 客户需求与产品需求的跟踪 产品需求与测试用例的跟踪 100%的接口需求 全局性需求 核心需求并非必需的： 性能需求 不影响系统架构的功能需求需求跟踪矩阵由谁来建立？l 有多个角色参与建立RTM：a. 需求开发人员b. 设计人员c. 测试用例的编写人员d. PPQARTM是否纳入基线管理？l RTM要纳入基线管理。l 纳入基线后，每次变更都要申请，RTM的变更一般是和其他配置项的变更一起申请，很少单独申请变更RTM，除非RTM有错误。l 如何简化RTM的工作？l 由于在RTM中，需求可能有很多项，设计、测试用例、代码等都有多项，所以建立和维护RTM的工作量还是比较大、比较烦琐。对于变化频繁的项目，更是如此。在实践中，为了简化该RTM的建立与维护工作，有的企业仅仅通过需求与设计、代码、测试用例的编号来实现跟踪，如需求为：r1,r2,等编号，而设计的编号为：r1-d1,r1-d2,.,测试用例的编号为：r1-t1,r1-t2等等。需要注意的是需求与它们之间是多对多的关系，仅通过编号是无法实现这种关系的。如果不借助DOORS之类的需求管理工具，一般只能通过EXCEL来维护RTM，工作量就l 是比较大。要简化，就要平衡管理的投入与产出。l 当然也可以考虑增大需求、设计、代码、测试用例的颗粒度大小，但是那样RTM的作用就打了折扣，还是一个平衡问题。SP1.5 确认项目工作和需求间的差异主要活动：l 评审项目计划、活动和工作产品是否与需求和需求变更相符。l 识别差异来源及其理由。l 当需求基线有变动时，识别有关计划和工作产品所需的变更。l 启动纠正措施。识别差距的时机？l 评审时l 变更时l 日常工作中识别出的不一致问题要有记录，并跟踪问题的关闭需求管理我们需要客户方如何做。l 了解乙方需求变