Module 5Requirement Development and ManagementGeorge Cao /曹纪清 Created on Oct 18, 2010 Last revised on Feb 28, 2014This Module enables you to understand the followings:1)How to Elicit ilisit引起、抽出引起、抽出the Customer Requirement2)How to Develop Product Requirements3)How to Analyze and Validate Requirements4)How to Obtain an understanding of requirements5)How to manage changes to requirements6)How to ensure consistency between the requirements, the project plans and work products, and maintaining bi-directional traceability of requirements and work productsStudy PurposeRequirement development (RD) is an iterative task, with iterations continuing as needed until the abstract notion of the systems objectives and needed capability have been translated into the detailed requirements necessary for implementation. The RD Process involves transforming the stakeholders requirement-driven view of desired services into a technical specification for the products that deliver those services. Purpose of RD3. Requirement Management 4. Requirement Review2. Use Case and Prototype 1. Requirement DevelopmentOverview5. ITO Terms Roles and ResponsibilityRoles ResponsibilitiesSystem Analyst (SA)Elicit requirements from the clients, analyze and establish the requirement spec; Manage requirements.Relevant Stakeholders (e.g., sales, client representative)Impacted participants that review, commit to software requirements. Procedures for Requirement Development1.Elicit and Develop Customer Requirements2. Develop and Validate Product Requirements1.Develop Customers Requirements1.TheSAdeterminethemethodoftherequirementelicit:Questionnaires问卷,Interviews面谈,Operationalscenarios操作场景obtainedfromendusers.2.Thestakeholdersdiscusstherequirementinformationtoeliminatemisunderstandingsandtoreachthecompleteandconsistentrequirements.1. Develop Customers Requirements3.TheSAdeveloptheCustomerRequirementSpecification,itcontains:TheproductinstructionTheproductconstraintsTheproductfunctionrequirementTheproductnon-functionrequirementInterface,software,hardware,qualityandsoon2. Analyze and Validate Requirements1.TheSAestablishaDefinitionofRequiredFunctionality.Establishactions,sequence,inputs,outputs,orotherinformationthatcommunicatesthemannerinwhichtheproductwillbeused.(USECASE)2.TheSAvalidaterequirementswithcomprehensivemethods;(Prototypes)3.TheSAdeveloptheSoftwareRequirementSpecification(SRS软件需求规格说明书包括：UseCaseDiagram+UseCaseSpec+Non-functionalRequirements)PracticeRefertoUseCaseDiagram:YouarerequiredtoestablishtheHighlevelUSECASEDiagramsandthedetailedonesforatleastonehighlevelUseCasediagrambasedontheHRMSSRS.识别用例图Usecasediagram过程：1.识别actor（endusers,admin,externalinterfaces）2.识别这些角色使用系统的哪些功能或操作或数据交互？3.底层用例细化3. Requirement Management 4. Requirement Review2. Use Case and Prototype 1. Requirement DevelopmentOverview5. ITO Terms for RD/REQMUse Case Spec用例规格说明书用例规格说明书用例规约(UseCaseSpecification)是用例建模（UseCaseModeling）的最终呈现说明，该文档描述用例的细节内容。用例方法完全是站在用户的角度上(从系统的外部)来描述系统的功能的。在用例方法中，我们把被定义系统看作是一个黑箱，我们并不关心系统内部是如何完成它所提供的功能的。用例方法首先描述了被定义系统有哪些外部使用者(抽象成为Actor)，这些使用者与被定义系统发生交互。针对每一参与者，用例方法又描述了系统为这些参与者提供了什么样的服务(抽象成为UseCase)，或者说系统是如何被这些参与者使用的。与传统的功能分解方式相比，用例方法完全是从外部来定义系统的功能，它把需求与设计完全分离开来。在面向对象的分析设计方法中，用例模型主要用于表述系统的功能性需求，系统的设计主要由对象模型来记录表述。另外，用例定义了系统功能的使用环境与上下文，每一个用例描述的是一个完整的系统服务。用例方法比传统的需求规格说明书更易于被用户所理解，在实际外包项目中，用例规约一般结合原型模型作为开发人员和用户之间针对系统需求进行沟通的一个有效手段。Use Case Spec用例规格说明书用例规格说明书用例场景(Use-CaseScenario)场景主要是由基本流（basicflow成功场景）和备选流（alternativeflow失败场景）组合而成的。用例在实际执行的时候会有很多的不同情况发生，称之为用例场景；也可以说场景是用例的实例，我们在描述用例的时候要覆盖所有的用例场景，否则就有可能导致需求的遗漏。场景既可以帮助我们防止需求的遗漏，同时也可以对后续的开发工作起到很大的帮助：开发人员必须实现所有的场景、测试人员可以根据用例场景来设计测试用例。Use Case Spec用例规格说明书用例规格说明书EHSS Use Case SpecSample2014-3-3测试测试121PracticeYouarerequiredtodevelopatleastoneUSECASEDIAGRAMwiththeinstructionsfortheHRMSSRSastheUseCaseSample.Review for this Module1.PleaselistthemethodsSAmayuseduringtherequirementresearchingworks.2.WhatisthepurposeforRD?3.WhatarethemainactivitiesfortheRDprocess?4.ComparedtotheclassicSRS,whatarethecomprehensivemethodsforrequirementvalidation?3. Requirement Management 4. Requirement Review2. Use Case and Prototype 1. Requirement DevelopmentOverview5. ITO Terms for RD/REQMWhy Prototyping原型法原型法?根据国外有关统计，大约66%的软件开发项目不是失败，就是超出预算、超出项目时间，或是交付缩水的功能。项目失败或亏损的前三大原因为：缺乏使用者的参与需求或规格不完整需求或规格变更根据离岸外包项目成本和进度等要求的特点，一些需求管理技术或者上百页的文档已经不合时宜，不能作为我们跟客户讨论交流的介质和核心。所以我们需要制作原型，用来提高与客户沟通的效率、让客户参与到设计中来并且帮助他们找到核心需求。The Art of UI Prototyping Prototypingisameansofexploring探索ideasbeforeyouinvestin投资them.SoftwareandWebdesignerscreatemock-upsofhowuserswillinteractwith与相互作用theirdesigns. The bestreasontoprototypeistosavetimeandresources.Thevalueoftheprototypeisthatitisafacadefs:d 正面、外观正面、外观likeaHollywoodset,whereonlythefrontofthebuildingisconstructed.Relativeto相对于therealproduct,prototypesareeasyandinexpensivetocreate.So,foraminimalinvestment,youcanfindusabilityanddesignproblemsandadjustyourUIbeforeyouinvestheavily大量地inthefinaldesignandtechnologies.Definition of Prototype原型可以分为三类：淘汰(抛弃)式(disposable)：目的达到即被抛弃，原型不作为最终产品。演化式(evolutionary)：系统的形成和发展是逐步完成的，它是高度动态迭代和高度动态的循环，每次迭代都要对系统重新进行规格说明、重新设计、重新实现和重新评价，所以是对付变化最为有效的方法。增量式(incremental)：系统是一次一段地增量构造，与演化式原型的最大区别在于增量式开发是在软件总体设计基础上进行的。很显然，其应付变化的能力比演化式差。 Prototype Tools 2014-2-28软件软件121原型的呈现形式主要有Web页面(HTML,ASP)、框架图（Wireframe）和微软窗体(Windows,Forms)等几种。进行原型设计的软件工具也有很多种，目前企业比较常用的设计工具有Frontpage,Dreamweaver,MSVisio、Axureakse:和Excel等。软件原型设计的工作是结合需求用例说明书中的用例、批注、以及流程图画框架图，将软件功能和操作完整而准确的表述给软件开发人员，市场人员和用户，并通过沟通会议，反复修改直至最终确认，开始投入执行。Prototype Tools-VISIOVisio是强大的框架图原型设计工具，他有很多的模板可以选择，可以制作包括流程图、平面布置图、工程绘图、日程图、软件界面、UML、灵感脑图Visio的优点是上手快，能比较快的画出不同种类的图，但缺点是外观功能不够强大。Visio并不太适合太过于精细的高保真原型，后者需要用Photoshop、fireworks之类的工具来画，甚至直接使用Dreamweaver和FrontPage制作html页面来用。Visio设计的原型图比较适合“开始构思”到“提交给美工设计”的过程中使用。Visio的缺点是在表现交互方面比较弱。EHSS Wireframe Made by VISIO（To demonstrate with visio）PracticeYouarerequiredtocreateawireframe(maybewithseveralUIpages)foratleastoneusecaseusingVISIO.-RefertothePrototypeinwebpagesandwireframe.To develop requirements using UML1. UML Instruction2. To develop requirements using UML3. Use Case and Prototype4. Requirement Management2. Requirement Review1. Requirement DevelopmentOverview5. ITO Terms for RD/REQMRequirement ManagementRequirementsManagement(REQM)involvesapplyingmanagementdisciplinestotherequirementsdevelopmentprocess.REQMinvolvesestablishingandmaintaininganagreementwiththecustomerontherequirementsforaproject,managingchangestorequirements,ensuringconsistencybetweentherequirements,theprojectplansandworkproducts,andmaintainingbi-directionaltraceabilityofrequirementsandworkproducts。Review1.About the practice;2.What are the main types for prototyping?3.What presentation types are there for prototyping?Procedures for REQM2013-5-16 S111Obtain understandingObtain commitmentControl changesMaintain traceabilityIdentify inconsistenciesObtain understanding(需求理解需求理解)2013-5-16 S115Inputs1 Software requirementsSteps1 PM and stakeholders establish acceptance criteria for defining requirements with appropriate requirements providers2 PM and designated personnel review and analyze the requirements, ensuring that the requirements acceptance criteria is met.3 PM and all stakeholders hold a meeting to reach sufficient understanding on requirementsExit Criteria1 The stakeholders understand and commit to the requirements. Control changes（变更流程控制）（变更流程控制）Inputs1The new requirement or requirement change request Steps1PM defines which products of this process are to be maintained under configuration control.2PM and relevant stakeholders evaluate and document impact of the proposed changes against existing commitments, project plans, current requirements, project activities, and other work products3PM, relevant stakeholders and high level management review the changes and make their decisions (approve or disapprove)4If changes are approved, relevant stakeholders execute the changes for the impacted work products.5CM makes requirements and change data available to the projects relevant stakeholdersOutputs1Modified SRSModified related CI itemsChange request FormMaintain traceabilityEntry Criteria1Requirements have been understood, Design spec has been reviewed, test plan and test case have been reviewedSteps1The requirements have been understood and the commitment to requirements has been obtained, PM establishes the requirement traceability matrix form and fills in the function ID and relevant requirement ID2Designers fill in the relevant Design spec ID3QA manager fills in the relevant test plan and test case ID4Developers fill in the relevant code ID5PM maintains the Requirement Traceability Matrix Exit Criteria1The Requirement Traceability Matrix Form is established and maintainedIdentify inconsistenciesEntry Criteria1Requirements are documented and understood or requirement changes are approved.Inputs1Software requirement specSteps1PM and relevant stakeholders review project plans, activities, and work products for consistency with requirements and requirements changes.2Inconsistencies(issues) with rationale,rnl基基本原理本原理 are documented and corrective action are planned as appropriate3PM and relevant stakeholders update plans and work products resulting from changes or additions to the requirements baselineOutputs1Issue tracking listExit Criteria1Issue tracking mechanism is established and all issues are tracked and corrective actions are taken.3. Requirement Management 4. Requirement Review2. Use Case and Prototype 1. Requirement DevelopmentOverview5. ITO Terms for RD/REQM4. Requirement Review需求评审是技术评审的一种。技术评审通常指对需求、设计、代码和测试的评审，四者的评审过程和方法都是相同的。技术评审的目的是在软件开发阶段对有关技术性文档进行正确性的检查，侧重于在缺陷导入阶段就尽早尽可能地发现他们以防止他们进入下一个阶段（Tofocusondiscoveringdefectsatthedefectimportphaseasearlyaspossibleandpreventthemfromenteringthenextphase），从而节约成本，使后续过程的变更减少，减少重复工作的工作量（toreducereworkeffort），降低风险。技术评审尝试发现更多的缺陷而不能发现所有的缺陷。Roles and ResponsibilityRolesKey ResponsibilitiesProject ManagerApply Technical ReviewEnsure all deliverables have been preparedReview LeaderDevelop Technical Review Plan Distribute deliverables to Review MembersProvide the Technical Review ReportReview MemberReview deliverables and discover defectsAuthor (SA/BA)Provide deliverablesIntroduce deliverablesFix defects and modify deliverablesProvide the Technical Review Measurement ReportRecorderRecord technical review course in the Technical Review RecordTechnical Review Mechanism1.FormalTechnicalReview:Inspection-followtechnicalreviewworkflowstrictlybyholdingformalreviewmeeting.2.InformalTechnicalReviewWalkthrough,FourEyesReview-reviewformisflexible,canbeconductedwithinprojectteamorbyseveralcompanions(同事、同伴)Formal Technical Review ProcedureEntry CriteriaDeliverables are completedInputs1 Deliverables2 Standards and ChecklistsSteps1 Apply Technical Review Project Manager applies PMO for the technical review2 Identify Review LeaderPMO will identify Review Leader 3 Develop Technical Review Plan Review Leader develops technical review plan and distributes deliverables to review members 4 Review Deliverables off site界外、非界外、非现场Review Members review deliverables off site and record defects discoveredFormal Technical Review Procedure5Hold Review MeetingThe author introduces the deliverables summarily. The review team and the author meet to discuss the defects identified by the reviewers in the formal meeting. Defects that need to be fixed are documented in the Technical Review Record. Before the meeting close, review leader and review members need to make closure decisions:Deliverable is eligibleelidbl符合条件的、合格符合条件的、合格的的: not to be modified ,not to review againDeliverable is eligible basically: Minor modification needed, after that the deliverable should be submitted to the review member to review again.Deliverable is not eligible: Major modification needed, and review meeting needs to be held again.Formal Technical Review Procedure6Deliverable Modification and Tracking:The author modifies the deliverable according to the defects documented in the Review Record after the meeting. After the author completes all the modifications, he/she informs（notify） the review team.7Close Review:The review team confirms the closure of all the defects and closes the review.Outputs: Technical Review RecordExit Criteria: All defects are fixed Requirement Review Checklist and RecordRequirement Review Checklist and RecordPractice:ConducttherequirementreviewforSRS(parital)ofHRMSprojectusingtheSRSReviewRecord.xls3. Requirement Management 4. Requirement Review2. Use Case and Prototype 1. Requirement DevelopmentOverview5. ITO Terms for RD/REQMRequirementdevelopment,Specification(SPEC),Systemanalyst,Questionnaires,Operationalscenarios,Endusers,Suppliers，Effectiveness，Functionalrequirement，SRS,Customerrequirement,Productrequirement,Object-orientedanalysis,Usecase,Prototype,Userinterface,Wireframe,Visio,Photoshop,Dreamweaver,Frontpage,Compliance符合性,Completeness,Clarity明确、清晰性,Consistency,Testability,Readability,Traceability,Priority,basicflow,alternativeflow,BusinessRules,Pre-Conditions,Post-Conditions,mock-up,ChangerequestForm,Terminologies for RD/REQM