CMMI3-PA解读 (需求管理培训)_V2

1/36需求管理(REQM)培训•保持课堂安静•手机设置为震动•任何人可以提议休息•签到授课说明REQM:RequirementsManagement2/36课程目的•理解需求管理的目标与内容•需求管理与其他过程域的关系•了解需求管理的应用3/36议程•需求管理的目的和意义•与其他过程域的关系•需求管理的内部结构•特定目标与特定实践•共性目标与共性实践•需求管理过程的示例4/36需求管理的目的•需求管理目的：管理产品需求和产品组件的需求,并且确保能把需求的更改反映到项目计划、活动和工作产品中。•需求：项目接收的或项目产生的产品和产品组件需求以及组织对项目实施的要求。5/36议程•需求管理的目的和意义•与其他过程域的关系•需求管理的内部结构•特定目标与特定实践•共性目标与共性实践•需求管理过程的示例6/36工程类过程域••RDPIValCustomerTSVerREQMRequirements需求Customerneeds客户需求Productandproductcomponentrequirements产品和产品构件需求Productcomponents,workproducts,verificationandvalidationreports产品组件、中间产品以及验证和确认报告Productcomponents产品组件Alternativesolutions供选择方案Require-mentsProduct与其他过程域的关系-1注：REQM:需求管理RD：需求开发TS：技术解决PI：产品集成VER：验证VAL：确认7/36z需求开发(RD):将关键人士需求转为产品需求，并决定如何配置到产品组件z技术解决(TS):将需求转为技术解决方案z项目计划(PP):有关于项目计划如何反应需求或因应需求而变动z配置管理(CM):有关与需求相关之文件控制管理部分z项目监督和控制(PMC):有关需求之各项项目活动与工作产品之跟踪监控与其他过程域的关系-28/36议程•需求管理的目的和意义•与其他过程域的关系•需求管理的内部结构•特定目标与特定实践•共性目标与共性实践•需求管理过程的示例9/36RequirementsObtainanUnderstandingofRequirements获得可理解需求ObtainCommitmenttoRequirements获得对需求的承诺TraceabilityMatrixorRequirementsTrackingSystemMaintainBidirectionalTraceabilityofRequirements维护需求的双向可溯性IdentifyInconsistenciesBetweenProjectWorkandReqmts识别需求和工产品不一致性ManageRequirements需求管理ManageRequirementsChanges管理需求的变更需求管理内部结构10/36议程•需求管理的目的和意义•与其他过程域的关系•需求管理的内部结构•特定目标与特定实践•共性目标与共性实践•需求管理过程的示例11/36•SG1管理需求对需求进行管理并识别与项目计划和工作产品之间的不一致之处。–SP1.1获得可理解需求设法理解需求提供者提出这些需求的含义。–SP1.2获得对需求的承诺项目开展过程中，对需求的变更、分解和实施达成共识。–SP1.3管理需求变更各项需求在项目的整个过程中发展变化的同时，对需求的变更进行管理。–SP1.4维护需求的双向可溯性维护需求与项目计划和工作产品之间的双向可溯性。垂直：底层需求可以溯源到某个有效来源；水平：需求变更对项目计划、组织活动以及工程产品的关系。–SP1.5识别需求与工作产品间的不一致性识别项目计划和工作产品与需求之间的不一致之处。特定目标与特定实践12/36¾产出物：辨识谁是需求提供者的准则清单、需求的评估和接受准则、基于规则的分析、达成一致的需求。¾子实践：[1]确定需求提供者清单；[2]制定需求的评估和接受准则；[3]根据规则分析需求；[4]与需求提供者达成对需求的共识。¾导致需求不合格的原因：•无足够用户参与；•用户需求的不断增加；•模棱两可的需求；•不必要的特性；•过于精简的规格说明；•忽略了用户分类；•不准确的计划。SP1.1获得可理解需求13/36优秀需求具有的特征•完整性•正确性•可行性•必要性•划分优先级•无二义性•可验证性•一致性•可修改性•可跟踪性14/36特征说明-1•完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息；•正确性：每一项需求都必须准确地陈述其要开发的功能；•可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的；•必要性：每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来；•划分优先级：给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量；15/36特征说明-2•无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来；•可验证性：检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了；•一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾；•可修改性：在必要时或为维护每一需求变更历史记录时，应该修订SRS(需求规格说明书)；•可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接；16/36¾产出物：需求影响评估、文档化需求和需求变更的承诺。¾子实践：[1]评估需求变更或设立新需求时对现有承诺影响；[2]承诺的变更和记录。¾需求的参与者：外：客户、最终用户。内：公司高层领导、项目经理、分析员、系统工程师、工程师、构架设计师、设计员、程序员、技术文档编写员；测试员、质量保证人员等。SP1.2获得对需求的承诺17/36¾产出物：需求状态、需求数据库、需求决策数据库。¾子实践：[1]收集所有的需求及其变更；[2]维护需求变更历史及变更理由；[3]共同利益者评估需求变更影响；[4]保证需求和需求变更数据可提供给项目组应用。¾不管您多么认真地定义需求，需求终将改变（实际上，一些变更是非常值得的！这意味着您的团队需要与相关利益者保持密切联系）¾如何处理需求的变更：•商务手段（需求定义、验收标准、变更流程和成本）•沟通手段（需求分层、与客户目标一致）•技术手段（需求获取与分析技术、复用技术）•管理手段（严格的需求变更流程）SP1.3管理需求的变更18/36SP1.4维护需求双向可溯性¾产出物：需求可溯性矩阵，需求跟踪系统。¾子实践：[1]维护需求可溯性，保证低层或推导需求文档化；[2]维护需求到派生需求，需求到功能、人力、对象、工作产品以及过程的对应关系；[3]维护需求到功能和跨接口的横向可溯性；[4]生成需求可溯性矩阵。19/36¾产出物：文档化的不一致，纠正措施。¾子实践：[1]审查项目计划、活动和工作产品，判决是否和需求以及变更一致；[2]识别不一致来源和理由；[3]识别需求基线变化而导致的计划和工作产品必须作的变化；[4]启动纠正措施。SP1.5辨别需求和工作产品的不一致20/36议程•需求管理的目的和意义•与其他过程域的关系•需求管理的内部结构•特定目标与特定实践•共性目标与共性实践•需求管理过程的示例21/36zGP2.1建立组织方针（CO1）–建立组织政策以规划并执行需求管理流程•GP2.2策划该过程(AB1)–建立并维护执行需求管理流程的需求、目标与计划–这些规划将说明于项目规划过程域之项目计划中•GP2.3提供资源(AB2)–提供足够资源以执行需求管理流程、发展工作产品及提供流程服务–资源：如需求追溯工具或追溯工具•GP2.4分配责任(AB3)–指定需求管理流程的相关责任与授权以执行流程•GP2.5培训人员(AB4)–依据需要，训练人员以执行需求管理流程培训内容：¾专业领域知识、¾需求定义分析审核管理技巧¾需求管理工具¾配置管理¾协调及冲突解决共性目标与共性实践-122/36•GP2.6管理配置项(DI1)–将指定的需求管理流程工作产品纳入适当层级的组态管理–如:需求、需求追溯表等•GP2.7确定相关共利益使之介入(DI2)–依据计划界定并纳入需求管理流程相关之关键人员–人员通常包含客户、使用者、发展人员、制作人员、测试人员、供货商、营销业务、维护人员、报废处理人员以及其它相关人士–这些人员参与的活动有解决需求了解的议题、评估变更影响、沟通双向追溯性、界定需求与项目间的差异等•GP2.8监控流程(DI3)–依据计划监控需求管理流程，并采取相对之矫正措施–监控指标如需求变更比率共性目标与共性实践-223/36•GP2.9客观评估遵循情况(VE1)–客观评估需求管理流程、工作产品与服务在适当需求目标与标准下的遵循程度，并说明不符合的情形–列入评估的活动有需求管理活动、界定差异的活动–列入评估之工作产品如:需求与需求追溯表•GP2.10与高层共同审查状况(VE2)–与高层共同审查需求管理流程活动、状况与结果并解决问题–提出之承诺变更若延伸与组织相关须经高层认可共性目标与共性实践-324/36GP3.1建立定义过程建立并维护一个以定义的需求管理流程。GP3.2收集改进信息收集派生于策划和实施该过程的工作产品数据、度量值、测量结果以及改进信息，以便支持将来对组织过程和过程财富的利用和改进。共性目标与共性实践-325/36议程•需求管理的目的和意义•与其他过程域的关系•需求管理的内部结构•特定目标与特定实践•共性目标与共性实践•需求管理过程的示例26/36需求管理过程的示例