Module4-1RD_REQM(2h)需求开发与需求管理.ppt

Module5RequirementDevelopmentandManagement,GeorgeCao/曹纪清CreatedonOct18,2010LastrevisedonFeb28,2014,ThisModuleenablesyoutounderstandthefollowings:HowtoElicitilisit引起、抽出theCustomerRequirementHowtoDevelopProductRequirementsHowtoAnalyzeandValidateRequirementsHowtoObtainanunderstandingofrequirementsHowtomanagechangestorequirementsHowtoensureconsistencybetweentherequirements,theprojectplansandworkproducts,andmaintainingbi-directionaltraceabilityofrequirementsandworkproducts,StudyPurpose,Requirementdevelopment(RD)isaniterativetask,withiterationscontinuingasneededuntiltheabstractnotionofthesystemsobjectivesandneededcapabilityhavebeentranslatedintothedetailedrequirementsnecessaryforimplementation.TheRDProcessinvolvestransformingthestakeholdersrequirement-drivenviewofdesiredservicesintoatechnicalspecificationfortheproductsthatdeliverthoseservices.,PurposeofRD,3.RequirementManagement,4.RequirementReview,2.UseCaseandPrototype,1.RequirementDevelopment,Overview,5.ITOTerms,RolesandResponsibility,ProceduresforRequirementDevelopment,ElicitandDevelopCustomerRequirements2.DevelopandValidateProductRequirements,DevelopCustomersRequirements,TheSAdeterminethemethodoftherequirementelicit:Questionnaires问卷,Interviews面谈,Operationalscenarios操作场景obtainedfromendusers.2.Thestakeholdersdiscusstherequirementinformationtoeliminatemisunderstandingsandtoreachthecompleteandconsistentrequirements.,1.DevelopCustomersRequirements,3.TheSAdeveloptheCustomerRequirementSpecification,itcontains:TheproductinstructionTheproductconstraintsTheproductfunctionrequirementTheproductnon-functionrequirementInterface,software,hardware,qualityandsoon,2.AnalyzeandValidateRequirements,1.TheSAestablishaDefinitionofRequiredFunctionality.Establishactions,sequence,inputs,outputs,orotherinformationthatcommunicatesthemannerinwhichtheproductwillbeused.(USECASE)2.TheSAvalidaterequirementswithcomprehensivemethods;(Prototypes)3.TheSAdeveloptheSoftwareRequirementSpecification(SRS软件需求规格说明书包括：UseCaseDiagram+UseCaseSpec+Non-functionalRequirements),Practice,RefertoUseCaseDiagram:YouarerequiredtoestablishtheHighlevelUSECASEDiagramsandthedetailedonesforatleastonehighlevelUseCasediagrambasedontheHRMSSRS.识别用例图Usecasediagram过程：1.识别actor（endusers,admin,externalinterfaces）2.识别这些角色使用系统的哪些功能或操作或数据交互？3.底层用例细化,3.RequirementManagement,4.RequirementReview,2.UseCaseandPrototype,1.RequirementDevelopment,Overview,5.ITOTermsforRD/REQM,UseCaseSpec用例规格说明书,用例规约(UseCaseSpecification)是用例建模（UseCaseModeling）的最终呈现说明，该文档描述用例的细节内容。用例方法完全是站在用户的角度上(从系统的外部)来描述系统的功能的。在用例方法中，我们把被定义系统看作是一个黑箱，我们并不关心系统内部是如何完成它所提供的功能的。用例方法首先描述了被定义系统有哪些外部使用者(抽象成为Actor)，这些使用者与被定义系统发生交互。针对每一参与者，用例方法又描述了系统为这些参与者提供了什么样的服务(抽象成为UseCase)，或者说系统是如何被这些参与者使用的。,与传统的功能分解方式相比，用例方法完全是从外部来定义系统的功能，它把需求与设计完全分离开来。在面向对象的分析设计方法中，用例模型主要用于表述系统的功能性需求，系统的设计主要由对象模型来记录表述。另外，用例定义了系统功能的使用环境与上下文，每一个用例描述的是一个完整的系统服务。用例方法比传统的需求规格说明书更易于被用户所理解，在实际外包项目中，用例规约一般结合原型模型作为开发人员和用户之间针对系统需求进行沟通的一个有效手段。,UseCaseSpec用例规格说明书,用例场景(Use-CaseScenario)场景主要是由基本流（basicflow成功场景）和备选流（alternativeflow失败场景）组合而成的。用例在实际执行的时候会有很多的不同情况发生，称之为用例场景；也可以说场景是用例的实例，我们在描述用例的时候要覆盖所有的用例场景，否则就有可能导致需求的遗漏。场景既可以帮助我们防止需求的遗漏，同时也可以对后续的开发工作起到很大的帮助：开发人员必须实现所有的场景、测试人员可以根据用例场景来设计测试用例。,UseCaseSpec用例规格说明书,EHSSUseCaseSpecSample2014-3-3测试121,Practice,YouarerequiredtodevelopatleastoneUSECASEDIAGRAMwiththeinstructionsfortheHRMSSRSastheUseCaseSample.,ReviewforthisModule,PleaselistthemethodsSAmayuseduringtherequirementresearchingworks.,WhatisthepurposeforRD?WhatarethemainactivitiesfortheRDprocess?,4.ComparedtotheclassicSRS,whatarethecomprehensivemethodsforrequirementvalidation?,3.RequirementManagement,4.RequirementReview,2.UseCaseandPrototype,1.RequirementDevelopment,Overview,5.ITOTermsforRD/REQM,WhyPrototyping原型法?,根据国外有关统计，大约66%的软件开发项目不是失败，就是超出预算、超出项目时间，或是交付缩水的功能。项目失败或亏损的前三大原因为：缺乏使用者的参与需求或规格不完整需求或规格变更根据离岸外包项目成本和进度等要求的特点，一些需求管理技术或者上百页的文档已经不合时宜，不能作为我们跟客户讨论交流的介质和核心。所以我们需要制作原型，用来提高与客户沟通的效率、让客户参与到设计中来并且帮助他们找到核心需求。,TheArtofUIPrototyping,Prototypingisameansofexploring探索ideasbeforeyouinvestin投资them.SoftwareandWebdesignerscreatemock-upsofhowuserswillinteractwith与相互作用theirdesigns.Thebestreasontoprototypeistosavetimeandresources.Thevalueoftheprototypeisthatitisafacadefs:d正面、外观likeaHollywoodset,whereonlythefrontofthebuildingisconstructed.Relativeto相对于therealproduct,prototypesareeasyandinexpensivetocreate.So,foraminimalinvestment,youcanfindusabilityanddesignproblemsandadjustyourUIbeforeyouinvestheavily大量地inthefinaldesignandtechnologies.,DefinitionofPrototype,原型可以分为三类：淘汰(抛弃)式(disposable)：目的达到即被抛弃，原型不作为最终产品。演化式(evolutionary)：系统的形成和发展是逐步完成的，它是高度动态迭代和高度动态的循环，每次迭代都要对系统重新进行规格说明、重新设计、重新实现和重新评价，所以是对付变化最为有效的方法。增量式(incremental)：系统是一次一段地增量构造，与演化式原型的最大区别在于增量式开发是在软件总体设计基础上进行的。很显然，其应付变化的能力比演化式差。,PrototypeTools2014-2-28软件121,原型的呈现形式主要有Web页面(HTML,ASP)、框架图（Wireframe）和微软窗体(Windows,Forms)等几种。进行原型设计的软件工具也有很多种，目前企业比较常用的设计工具有Frontpage,Dreamweaver,MSVisio、Axureakse:和Excel等。软件原型设计的工作是结合需求用例说明书中的用例、批注、以及流程图画框架图，将软件功能和操作完整而准确的表述给软件开发人员，市场人员和用户，并通过沟通会议，反复修改直至最终确认，开始投入执行。,PrototypeTools-VISIO,Visio是强大的框架图原型设计工具，他有很多的模板可以选择，可以制作包括流程图、平面布置图、工程绘图、日程图、软件界面、UML、灵感脑图Visio的优点是上手快，能比较快的画出不同种类的图，但缺点是外观功能不够强大。Visio并不太适合太过于精细的高保真原型，后者需要用Photoshop、fireworks之类的工具来画，甚至直接使用Dreamweaver和FrontPage制作html页面来用。Visio设计的原型图比较适合“开始构思”到“提交给美工设计”的过程中使用。Visio的缺点是在表现交互方面比较弱。,EHSSWireframeMadebyVISIO（Todemonstratewithvisio）,Practice,Youarerequiredtocreateawireframe(maybewithseveralUIpages)foratleastoneusecaseusingVISIO.-RefertothePrototypeinwebpagesandwireframe.,TodeveloprequirementsusingUML,1.UMLInstruction2.TodeveloprequirementsusingUML,3.UseCaseandPrototype,4.RequirementManagement,2.RequirementReview,1.RequirementDevelopment,Overview,5.ITOTermsforRD/REQM,RequirementManagement,RequirementsManagement(REQM)involvesapplyingmanagementdisciplinestotherequirementsdevelopmentprocess.REQMinvolvesestablishingandmaintaininganagreementwiththecustomerontherequirementsforaproject,managingchangestorequirements,ensuringconsistencybetweentherequirements,theprojectplansandworkproducts,andmaintainingbi-directionaltraceabilityofrequirementsandworkproducts。,Review,Aboutthepractice;Whatarethemaintypesforprototyping?Whatpresentationtypesarethereforprototyping?,ProceduresforREQM2013-5-16S111,ObtainunderstandingObtaincommitmentControlchangesMaintaintraceabilityIdentifyinconsistencies,Obtainunderstanding(需求理解)2013-5-16S115,Controlchanges（变更流程控制）,Maintaintraceability,Identifyinconsistencies,3.RequirementManagement,4.RequirementReview,2.UseCaseandPrototype,1.RequirementDevelopment,Overview,5.ITOTermsforRD/REQM,4.RequirementReview,需求评审是技术评审的一种。技术评审通常指对需求、设计、代码和测试的评审，四者的评审过程和方法都是相同的。技术评审的目的是在软件开发阶段对有关技术性文档进行正确性的检查，侧重于在缺陷导入阶段就尽早尽可能地发现他们以防止他们进入下一个阶段（Tofocusondiscoveringdefectsatthedefectimportphaseasearlyaspossibleandpreventthemfromenteringthenextphase），从而节约成本，使后续过程的变更减少，减少重复工作的工作量（toreducereworkeffort），降低风险。技术评审尝试发现更多的缺陷而不能发现所有的缺陷。,RolesandResponsibility,TechnicalReviewMechanism,FormalTechnicalReview:Inspection-followtechnicalreviewworkflowstrictlybyholdingformalreviewmeeting.2.InformalTechnicalReviewWalkthrough,FourEyesReview-reviewformisflexible,canbeconductedwithinprojectteamorbyseveralcompanions(同事、同伴),FormalTechnicalReviewProcedure,FormalTechnicalReviewProcedure,FormalTechnicalReviewProcedure,Requirem