您好,欢迎访问三七文档
当前位置:首页 > 商业/管理/HR > 其它文档 > 01-CMMI-L2-RM需求管理
1CyberKeJi版权所有请勿翻印CMMIL2REQM需求管理RequirementsManagement赛柏科技n初始级o已管理级p已定义级q定量管理级r优化级n初始级o已管理级p已定义级q定量管理级r优化级2CyberKeJi版权所有请勿翻印主题I需求管理的目的IIREQM的SG和SPsIIIREQM的GGs和GPsIV小结参考材料3CyberKeJi版权所有请勿翻印RM的目的•需求管理的目的:管理项目的产品和产品构件的需求,并识别出这些需求与项目计划和工作产品的不一致4CyberKeJi版权所有请勿翻印IIREQM的SG和SPsSG1:管理需求:管理需求,并识别需求与项目计划和工作产品之间的不一致SP1.1获得对需求的理解SP1.2获得对需求的承诺SP1.3管理需求变更SP1.4维护需求的双向可跟踪性SP1.5识别项目工作和需求的不一致5CyberKeJi版权所有请勿翻印SG1管理需求SG1管理需求:管理需求,并识别需求与项目计划和工作产品之间的不一致性。•在整个项目生命周期中,项目维持一个当前被批准的需求集:–管理所有需求变更(申请变更、评估影响、跟踪变更的执行)–维持需求与项目计划和工作产品之间的关系(跟踪矩阵)–识别需求与项目计划和工作产品之间的不一致性(对照需求评审计划和工作产品)–采取纠正行动6CyberKeJi版权所有请勿翻印#需求管理的基本任务•项目要采取适当的步骤来确保管理已得到批准的需求集,以便支持项目的计划和执行的需要–获得对需求的理解:从被认可的需求提供者收集需求,并与他们共同评审,以便在将需求纳入项目计划之前,解决不明确的问题并排除误解–获得对需求的承诺:一旦需求提供者和需求接收者达成了协议,从项目参与者获得对需求的承诺–管理需求变更:随着项目进展和标识出计划、工作产品和需求之间出现不一致时,项目经理要更改需求或更改计划–维持需求的双向可跟踪性:需求管理要将需求的变更及其变更的理由文档化,并维持源需求与所有产品和产品构件的需求之间的双向可跟踪性7CyberKeJi版权所有请勿翻印REQM语境图需求SP11获得对需求的理解SP12获得对需求的承诺需求跟踪矩阵SP14维护需求的双向可跟踪性SP15识别项目工作和需求的不一致SG1管理需求SP13管理需求的变化8CyberKeJi版权所有请勿翻印SP1.1获得对需求的理解SP1.1获得对需求的理解:与需求提供者共同理解需求的含义•随着项目的成熟和各项需求的派生,所有活动或工程学科都要接受相应的需求•为了避免这些需求的漫无边际地外延或者“遗漏”,要建立一些准则,用以指明接收需求的适当的渠道或正式来源•接收需求的活动应该是与需求提供者一起进行的需求分析活动,以确保对需求的含义达成共识•分析和对话的结果是达成一致的需求集合9CyberKeJi版权所有请勿翻印典型工作产品1.确定合适需求提供者的准则2.需求评价和验收准则3.按准则分析的结果4.已同意的需求集10CyberKeJi版权所有请勿翻印子实践1.建立区分合适需求提供者的准则2.建立需求验收的客观准则:缺乏验收准则,常导致验证不充分、昂贵的返工或客户拒收3.分析需求来确保满足已建立的验收准则4.与需求提供者达成对需求的理解,这样项目参与者就能对需求作出承诺11CyberKeJi版权所有请勿翻印子实践5.验收准则的实例包括:–清晰、适当的文字陈述–完整的–相互一致的–唯一可识别的–可行的、能适当实现的–通过评审和测试,可以验证和确认的–可跟踪的12CyberKeJi版权所有请勿翻印举例1.需求通过的准则,《需求评审检查单》◎13CyberKeJi版权所有请勿翻印SP1.2获得对需求的承诺SP1.2获得对需求的承诺:从项目参与者获得对需求的承诺•项目组开始启动项目之前,要与客户共同评审需求,以建立工作基线•分析和评审需求要确保在其含义上达成一致、共同的理解,并获得开发人员对需求的承诺•在整个项目推进中,需求可能会演变。随着需求的演变,要求在所有有关的项目相关人员(Stakeholder)之间对已批准的现行需求重新建立承诺并且对项目计划、活动和工作产品中的后续变更做出承诺.14CyberKeJi版权所有请勿翻印SP1.2获得对需求的承诺(续)•承诺的变更必须与所有项目相关人员商量•对组织外部的委托或承诺的变更,要由高层经理评审(他是项目相关人员之一),以确保这次委托或承诺和以前批准的委托/承诺的顺利进行15CyberKeJi版权所有请勿翻印典型工作产品1.对需求影响的评估2.对需求和需求变更的文档化的承诺16CyberKeJi版权所有请勿翻印子实践1.评估需求变更对现有承诺的影响:当需求变更或引入一个新的需求时,应该评估对项目参与者的影响2.协商和记录承诺:在项目参与者对需求或需求变更作出承诺之前,应该协商对现有承诺的变更17CyberKeJi版权所有请勿翻印举例•需求承诺有多种形式:–参加需求建立的评审(顾客、项目组、供应商等)–参加需求变更的评审(顾客、项目组、供应商等)•需求承诺记录(需求建立)◎18CyberKeJi版权所有请勿翻印SP1.3管理需求变更SP1.3管理需求变更:在项目期间要管理对需求的变更•在项目推进期间,需求会由于各种各样原因而发生变更。•随着原来的需要发生变化和工作的推进,将会产生一些附加的需求,因此必然要对现行的需求做出相应的变更。•有效地管理这些需求和需求变更相当重要。•有必要了解每个需求的来源并且把做出变更的理由形成文件。•项目经理可能希望跟踪相应的需求变更度量数据,以便判断是否需要采取新的控制措施或对已有的控制做出调整。19CyberKeJi版权所有请勿翻印#需求变更•在软件或系统的开发过程中,需求必定会发生变更,这一点无一例外•对于大型项目来说,说出完整的需求不仅仅是困难的,实际上是不可能的。除非以前做过类似的工作,现在只需要作微小的变更•软件或系统开发是一个学习过程,步伐宜小不宜大,昀好的实践经验是采取渐进式的开发过程20CyberKeJi版权所有请勿翻印#需求变更原因•客户并不完全了解其需求,更不用说其他人•昀初的需求常常是不完善的,需要补充、删除和修改•必须与了解产品应用领域的人建立联系、共同工作,直到整个工作完成。系统越大越复杂,需要的应用领域知识就越多21CyberKeJi版权所有请勿翻印#需求变更影响分析•增加、修改或删除需求时,要进行影响分析:–对开发进度的影响–对发布进度的影响–对人员安排的影响–对成本的影响–对现有承诺(Commitment)的影响–变更引起的风险分析–对其他相关的工作产品的影响–等等•对变更进行影响分析时,要使用《需求跟踪矩阵》22CyberKeJi版权所有请勿翻印#对变更状态的跟踪基线需求数500报告周期增加需求数修改需求数删除需求数总的需求数变更数需求稳定性000050000.00%152-150481.59%264-3507214.14%335-2508316.10%422-3507387.50%531-1509438.45%661-25135210.14%•总的需求数=(基线需求数+增加的需求数-删除的需求数)•需求变更数=(增加的需求数+删除的需求数+修改的需求数)•需求稳定性=(需求变更数/基线需求数)23CyberKeJi版权所有请勿翻印#需求变更的度量-20.000.0020.0040.0060.0080.00100.00120.00140.00160.00180.001234567891011报告期间需求和变更数量初始的需求增加的需求修改的需求删除的需求需求总数变更累计24CyberKeJi版权所有请勿翻印#需求变更要控制•在项目生命周期中,需求在不断进化,对需求变更必须进行控制–需求变更请求要受到控制:所有相关的人员在变更实施前,要评审变更请求,并对变更请求达成一致–对批准的需求变更要进行跟踪–对每个需求及其变更要记录,要维护其变更历史•初始采集的和/或导出的•批准的变更已经应用之后–应用的需求变更要与所有相关人员及时沟通25CyberKeJi版权所有请勿翻印#需求变更的控制示例变更请求软件经理系统测试软件工程系统工程软件质量保证软件配置管理,以及文档支持更改软件计划、工作产品和活动审批关闭请求变更的需求一致YSCMN变更完成26CyberKeJi版权所有请勿翻印典型工作产品1.需求状态2.需求数据库3.需求决策库27CyberKeJi版权所有请勿翻印子实践1.获取所有由项目给出的或产生的需求和需求变更2.维持需求变更的历史以及进行变更的理由,以有助于跟踪易变的需求3.从利益相关者的角度评价需求变更的影响4.使需求和变更数据对项目可用28CyberKeJi版权所有请勿翻印举例•需求库◎•需求变更申请表◎•需求变更跟踪表○29CyberKeJi版权所有请勿翻印SP1.4维持需求的双向可跟踪性SP1.4维持需求的双向可跟踪性:在需求和工作产品之间维持双向可跟踪性•这个特定实践的目的在于维护对每个工作产品的双向可跟踪性•如果需求管理得好,就可以建立起从来源需求到它的较低层次的需求的可跟踪性,和从较低层次的需求到它们的来源需求的可跟踪性•这种双向可跟踪性有助于确定是否所有来源需求都完全得到处理,是否所有的低层需求都可以跟踪到有效的来源。•需求的可跟踪性还可以覆盖与其他实体的关系,例如:与产品、设计文档的变更、测试计划、验证、确认以及工作任务等的关系。•在评估需求变更对工作产品的影响时,尤其需要可跟踪性。30CyberKeJi版权所有请勿翻印#需求的双向可跟踪性•可跟踪:–知道每个需求的来源–知道哪些需求与它相关–知道需求如何与其它信息(如:设计、编码、制造及用户手册等)相关•双向:–纵向:需求跟踪矩阵向前、向后。前向跟踪意味着看需求是否在生命周期的后期阶段(如设计和编码阶段)的输出元素中得到体现。后向跟踪则相反,它意味着后期各个阶段的输出元素满足何种需求。后向跟踪也经常意味着跟踪到原始需求的能力–横向:需求之间相关31CyberKeJi版权所有请勿翻印#常见需求跟踪矩阵•纵向八个对应关系:–客户需求-产品需求–产品需求-概要设计–概要设计-详细设计–详细设计-编码–客户需求-验收测试用例–产品需求-系统测试用例–概要设计-集成测试用例–详细设计-单元测试用例32CyberKeJi版权所有请勿翻印#需求跟踪矩阵的维护•维护矩阵时,需要进行完整性检查:–矩阵中的需求数目与需求文档中的需求相同。–矩阵中列出的所有程序在昀终的软件中都是必要的,–确保功能需求与实现程序的对应。–如果设计和程序列没有对应,需要检查和验证这些需求对程序有没有直接的影响–对每个性能需求,都应该对应一些测试用例。–集成和系统测试计划可以和矩阵一起进行交叉检查,以保证需求的所有条款都包含在系统测试计划中33CyberKeJi版权所有请勿翻印#需求状态•可以将需求分为:被建议、被拒绝、被批准、被实现、被验证、被取消、被交付等状态–被建议:该需求已被有权提出需求的人建议–被拒绝:该需求被建议后,评审未通过–被批准:该需求已被分析,估计了其成本和对项目其他部分的影响,而且通过评审–被实现:已实现需求的设计、编码和单元测试–被验证:使用所选择的方法(如测试)已验证了实现的需求,该需求现在被认为完成–被取消:被批准的需求已从基线中取消,但记录了原因说明和做出取消决定的人员–被交付:需求已通过客户的验收。34CyberKeJi版权所有请勿翻印#对需求状态的跟踪5月份需求状态分布被建议17%被验证17%被批准5%被删除5%被拒绝5%被实现51%前三季度需求状态分布0204060801001月2月3月4月5月6月7月8月9月月需求数被建议被批准被实现被验证被删除35CyberKeJi版权所有请勿翻印#需求状态的变化层次示例承诺的客户需求(双方一致同意的)需求分析设计要进行设计的需求(设计规格说明)测试被实现的需求(代码)编码已分析的需求(即SRS,产品需求)被验证的需求(测试计划和报告)36CyberKeJi版权所有请勿翻印典型工作产品1.需求跟踪矩阵2.需
本文标题:01-CMMI-L2-RM需求管理
链接地址:https://www.777doc.com/doc-5502423 .html