CMMI-module1-需求工程简介

1需求工程简介CMMI高级咨询顾问袁庆平内部交流，请勿翻印2SeminarAgenda•需求基础•需求管理•需求开发–建立负责需求的团队–需求调研(获取)•问题分析•需求启发、导出–需求分析•需求工作的主要困难与对策•写需求常犯的错误2需求基础需求，是什么和为什么内部交流，请勿翻印4业界的状况-1998存在问题的项目46%成功的项目26%失败的项目28%资料来源：Standish集团《混乱与指南》报告（1998）功能没有使用,45%平均超支,89%超出进度,122%0%20%40%60%80%100%120%140%项目现状3内部交流，请勿翻印5业界的状况-2000存在问题的项目,49%成功的项目,28%失败的项目;成功的项目23%资料来源：Standish集团报告（2000）内部交流，请勿翻印6项目失败的昀重要原因„不完整的需求„没有用户的介入„不实际的客户期望„需求和规范的变更„提供不再需要了的能力以上五个问题都有需求有关！4内部交流，请勿翻印7昀大软件开发问题分类0%5%10%15%20%25%30%35%40%45%50%需求规格说明管理客户需求建档软件和测试项目管理编码主要问题次要问题不是问题数据来源于ESPITI内部交流，请勿翻印8软件开发的三个重要问题•应用系统的领域知识浅薄–业务专家•需求的变更以及需求之间的矛盾–需求规格说明–管理客户需求•沟通和协同问题–项目管理需求工程刚好可以解决这三方面的问题！5内部交流，请勿翻印9软件需求的问题根源•客户提供的需求并不是真实需求•系统开发商使用低效的需求分析和项目管理方法•对客户和开发商在项目成功的共同责任方面强调不够。内部交流，请勿翻印10需求问题的代价20050201051需求设计编码单元测试验收测试系统维护200倍软件公司昀值得改进的环节6内部交流，请勿翻印11项目成功的重要因素内部交流，请勿翻印12需求的定义•IEEE软件工程标准词汇表(1997)–(1)用户解决问题或达到目标所需要的条件或能力(capability)。–(2)系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力。–(3)一种反映以上(1)或(2)所描述的条件或能力的文档说明。7内部交流，请勿翻印13角色•客户–出资支付项目或者项目昀终产品的人。通常意义下，客户是指直接或间接从产品中获得利益的个人或组织。软件客户包括提出要求、支付款项、选择、具体说明或使用软件产品的项目风险承担者或是获得产品所产生的结果的人。•用户(使用者)–以某种方式使用系统，因此必须从实际使用的观点理解系统的任何项目有关人员。•客户不一定是用户。内部交流，请勿翻印14需求的层次业务需求项目前景与范围文档项目前景与范围文档用户需求功能需求软件需求规格说明软件需求规格说明系统需求质量属性其它非功能需求约束条件8内部交流，请勿翻印15需求的层次概念•业务需求(businessrequirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目前景与范围文档中予以说明。•用户需求(userrequirement)文档描述了用户使用产品必须要完成的任务，这在用例(usecase)文档或方案脚本说明中予以说明。•功能需求(functionalrequirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。•所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。内部交流，请勿翻印16一个字处理程序的例子•业务需求可能是：“用户能有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。•而对应的用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。•同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换。9内部交流，请勿翻印17需求工程模型需求过程(需求工程过程、需求管理过程)需求工具（CaliberRM、RequisitePro、Doors、Catalyze）需求技术/方法CMM、XP、RUP(用例分析技术)内部交流，请勿翻印18需求过程模型需求工程过程需求管理过程需求技术（用例）需求获取编写需求文档需求变更需求状态跟踪版本控制需求跟踪需求验证需求分析10需求管理内部交流，请勿翻印20需求管理需求管理需求管理需求管理•建议变更•分析影响•做出决策•交流•合并•测量需求的稳定性•建议变更•分析影响•做出决策•交流•合并•测量需求的稳定性变更控制变更控制•确定需求文档版本•确定单个需求文档版本•确定需求文档版本•确定单个需求文档版本版本控制版本控制•定义对其他需求的连接链•定义对其他系统元素的连接链•定义对其他需求的连接链•定义对其他系统元素的连接链需求跟踪需求跟踪•定义需求状态•跟踪需求每一个状态•定义需求状态•跟踪需求每一个状态需求状态跟踪需求状态跟踪11内部交流，请勿翻印21需求管理的原则和实现•建立需求基线•控制对需求基线的变更•保持项目计划与需求一致•控制单个需求和需求文档的版本情况•管理需求和联系链之间的联系或管理单个需求和其他项目可交付产品之间的依赖关系•跟踪基线中需求的状态(已实现、已验证、已删除等)内部交流，请勿翻印22管理需求变更请求•应该仔细评估已建议的变更•挑选合适的人选对变更做出决定（CCB）•变更应及时通知相关小组和个人•项目要按照一定的程序来采纳需求变更12内部交流，请勿翻印23需求的跟踪•IEEE为可跟踪性提供的定义：–“在开发过程的两个或多个产品之间能够建立关系的程度，尤其是某产品与其他产品之间前任及后续或者主要或从属的关系。例如，某给定软件组件的需求和设计的匹配程度。”–“软件开发产品中每个元素能够建立其存在理由的程度；例如，数据流图中的每个元素引用它所满足需求的程度。”内部交流，请勿翻印24需求跟踪客户需求客户需求客户需求软件需求软件需求软件需求下游工作产品下游工作产品下游工作产品追溯到需求从需求回溯从需求追溯回溯到需求13内部交流，请勿翻印25可能的需求跟踪能力联系链业务需求业务需求系统需求，用例，业务规则及外部接口需求系统需求，用例，业务规则及外部接口需求软件功能需求软件功能需求体系结构、用户接口或功能设计体系结构、用户接口或功能设计变更请求变更请求集成测试集成测试代码代码单元测试单元测试规格说明影响影响影响影响被验证被实现被验证系统测试系统测试项目计划任务项目计划任务被陈述被验证连接到依赖另一个内部交流，请勿翻印26需求跟踪动机•审核跟踪能力信息可以帮助审核确保所有需求被应用。•变更影响分析跟踪能力信息在增、删、改需求时可以确保不忽略每个受到影响的系统元素。•维护可靠的跟踪能力信息使得维护时能正确、完整地实施变更，从而提高生产率。•项目跟踪在开发中，认真记录跟踪能力数据，就可以获得计划功能当前实现状态的记录。还未出现的联系链意味着没有相应的产品部件。14内部交流，请勿翻印27需求跟踪动机(Cont)•再设计（重新建造）你可以列出传统系统中将要替换的功能，记录它们在新系统的需求和软件组件中的位置。通过定义跟踪能力信息链提供一种方法收集从一个现成系统的反向工程中所学到的方法。•重复利用跟踪信息可以帮助你在新系统中对相同的功能利用旧系统相关资源。例如：功能设计、相关需求、代码、测试等。•减小风险使部件互连关系文档化可减少由于一名关键成员离开项目带来的风险•测试测试模块、需求、代码段之间的联系链可以在测试出错时指出昀可能有问题的代码段。内部交流，请勿翻印28跟踪能力联系链可能的信息源测试工程师测试案例功能性需求开发者代码设计元素开发者其他设计元素功能性需求软件体系结构设计者软件体系结构元素功能性需求需求分析员功能性需求功能性需求需求分析员功能性需求用例系统工程师软件需求系统需求信息源链的目的对象类链的源对象种类15需求开发内部交流，请勿翻印30RequirementsDevelopment-需求开发Purpose:•Toproduceandanalyzecustomer,product,andproduct-componentrequirements.•需求开发的目的是产生和分析客户需求、产品需求和产品组件需求。16内部交流，请勿翻印31RequirementsDevelopmentSG1:DevelopCustomerRequirements开发客户需求•Stakeholderneeds,expectations,constraints,andinterfacesarecollectedandtranslatedintocustomerrequirements.收集利益相关人的需要、期望、限制条件和接口，并且把它们转换成客户需求。SG2:DevelopProductRequirements开发产品需求•Customerrequirementsarerefinedandelaboratedtodevelopproductandproduct-componentrequirements对客户需求加以精炼和细化，以便开发产品和产品组件需求。SG3:AnalyzeandValidateRequirements分析和确认需求•Therequirementsareanalyzedandvalidated,andadefinitionofrequiredfunctionalityisdeveloped.对各项需求进行分析和确认，并且开发所要求的功能度的定义。内部交流，请勿翻印32特定实践•SP1.1-2ElicitNeeds捕获需要–Elicitstakeholderneeds,expectations,constraints,andinterfacesforallphasesoftheproductlifecycle.–捕获出对产品生命周期中所有的各个阶段，利益相关人的需要、期望、限制条件和接口。•SP1.2-1DeveloptheCustomerRequirements开发客户需求–Transformstakeholderneeds,expectations,constraints,andinterfacesintocustomerrequirements.–把利益相关人的需要、期望、限制条件和接口转换成客户需求。•除了翻译需求之外，还要界定需求能否，以及如何去确认掘地三尺，也要把需求给我挖出来！（有人把需求埋起来了？）需求发掘也是个长期的事谁去转换？转换的结果给谁看？17内部交流，请勿翻印33需求捕获挖掘的做法•了解商业和技术环境，发现“信息源”•设计信息获取的办法，想办法把数据“钓上来”–一般会找出不止一种方法，综合使用，尽可能充分地获得需求•跟相关的干系人沟通，制订计划、获取承诺–重要的是需要让干系人了解我们为什么要这么做，以及他们的参与对项目成败的重要性–制订计划的时候要注意持续性，“一揽子”全部完成的想法并不现实•执行计划、适时调整和补充内部交流，请勿翻印34特定实践•SP2.1-1EstablishProductandProduct-ComponentRequirements建立产品和产品构件需求–Establishandmaintainproductandproduct-componentrequirements,whicharebasedonthecustomerrequirements.–基于客户需求，建立和维护产品和产品构件需求。•产品需求和产品组件的需求有时候是设计考虑引发的！•建立产品需求的时候要考虑需求之间的追溯性（可跟踪性）•SP2.2-1AllocateProduct-ComponentRequirements分配产品构件需求–Allocatetherequirementsforeachproductcomponent.–为每个产品构件分配需求。•所谓“分配”–到功能–到组件–分配设计限制•SP2.3-1IdentifyInte