Module41RDREQM需求开发与需求管理.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,2020年5月29日星期五,#,11 十月 2026,Module41RDREQM需求开发与需求管理,This Module enables you to understand the followings:,How to Elicit,ilisit引起、抽出,the Customer Requirement,How to Develop Product Requirements,How to Analyze and Validate Requirements,How to Obtain an understanding of requirements,How to manage changes to requirements,How to ensure consistency between the requirements,the project plans and work products,and maintaining bi-directional traceability of requirements and work products,Study Purpose,Requirement 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 RD,3.Requirement Management,4.Requirement Review,2.Use Case and Prototype,1.Requirement Development,Overview,5.ITO Terms,Roles and Responsibility,Roles,Responsibilities,System 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 Development,Elicit and Develop Customer Requirements,2.Develop and Validate Product Requirements,Develop Customers Requirements,The SA determine the method of the requirement elicit:,Questionnaires问卷,Interviews面谈,Operational scenarios操作场景 obtained from,end users.,2.The stakeholders discuss the requirement information to eliminate misunderstandings and to reach the complete and consistent requirements.,1.Develop Customers Requirements,3.The SA develop the,Customer Requirement Specification,it contains:,The product instruction,The product constraints,The product function requirement,The product non-function requirement,Interface,software,hardware,quality and so on,2.Analyze and Validate Requirements,1.The SA establish a Definition of Required Functionality.,Establish actions,sequence,inputs,outputs,or other information that communicates the manner in which the product will be used.(,USE CASE,),2.The SA,validate,requirements with,comprehensive,methods;(,Prototypes,),3.The SA develop the Software Requirement Specification(,SRS,软件需求规格说明书包括：Use Case Diagram+Use Case Spec+Non-functional Requirements),Practice,Refer to Use Case Diagram:,You are required to establish the,High level USE CASE Diagrams,and the,detailed ones,for at least one high level Use Case diagram based on the HRMS SRS.,识别用例图Use case diagram过程：,1.识别actor（end users,admin,external interfaces）,2.识别这些角色使用系统的哪些功能或操作或数据交互？,3.底层用例细化,3.Requirement Management,4.Requirement Review,2.,Use Case,and Prototype,1.Requirement Development,Overview,5.ITO Terms for RD/REQM,Use Case Spec,用例规格说明书,用例规约(Use Case Specification)是用例建模（Use Case Modeling）的最终呈现说明，该文档描述用例的细节内容。用例方法完全是,站在用户的角度上,(从系统的外部)来描述系统的功能的。,在用例方法中，我们把被定义系统看作是一个黑箱，我们并不关心系统内部是如何完成它所提供的功能的。用例方法首先描述了被定义系统有哪些外部使用者(抽象成为Actor)，这些使用者与被定义系统发生交互。针对每一参与者，用例方法又描述了系统为这些参与者提供了什么样的服务(抽象成为Use Case)，或者说,系统是如何被这些参与者使用的,。,与传统的功能分解方式相比，用例方法完全是,从外部来定义系统的功能,，它把需求与设计完全分离开来。在面向对象的分析设计方法中，用例模型主要用于表述系统的功能性需求，系统的设计主要由对象模型来记录表述。另外，用例定义了系统功能的使用环境与上下文，每一个用例描述的是一个完整的系统服务。,用例方法比传统的需求规格说明书更易于被用户所理解,，在实际外包项目中，用例规约一般结合原型模型作为开发人员和用户之间针对系统需求进行沟通的一个有效手段。,Use Case Spec,用例规格说明书,用例场景(Use-Case Scenario)场景主要是由,基本流（basic flow,成功场景）和,备选流（alternative flow,失败场景）组合而成的。用例在实际执行的时候会有很多的不同情况发生，称之为用例场景；也可以说场景是用例的实例，我们在描述用例的时候要覆盖所有的用例场景，否则就有可能导致需求的遗漏。,场景既可以帮助我们防止需求的遗漏，同时也可以对后续的开发工作起到很大的帮助：,开发人员必须实现所有的场景、测试人员可以根据用例场景来设计测试用例。,Use Case Spec用例规格说明书,EHSS Use Case SpecSample,2014-3-3测试121,Practice,You are required to develop,at least one,USE CASE DIAGRAM with the instructions for the HRMS SRS as the Use Case Sample.,Review for this Module,Please list the methods SA may use during the requirement researching works.,What is the purpose for RD?,What are the main activities for the RD process?,4.Compared to the classic SRS,what are the comprehensive methods for requirement validation?,3.Requirement Management,4.Requirement Review,2.Use Case and,Prototype,1.Requirement Development,Overview,5.ITO Terms for RD/REQM,Why Prototyping原型法?,根据国外有关统计，大约 66%的软件开发项目不是失败，就是超出预算、超出项目时间，或是交付缩水的功能。,项目失败或亏损的前三大原因为,：,缺乏使用者的参与,需求或规格不完整,需求或规格变更,根据离岸外包项目成本和进度等要求的特点，一些需求管理技术或者,上百页的文档已经不合时宜,，不能作为我们跟客户讨论交流的介质和核心。所以我们需要制作原型，用来提高与客户沟通的效率、让客户参与到设计中来并且帮助他们找到核心需求。,The Art of UI Prototyping,Prototyping,is a means of,exploring,探索 ideas before you invest in 投资them.Software and Web designers create,mock-ups,of how users will,interact with与相互作用,their designs.,The,best reason to prototype is to save time and resources.The value of the prototype is that it is a facade,fs:d 正面、外观,like a,Hollywood set,where only the front of the building is constructed.Relative to相对于 the real product,prototypes are easy and inexpensive to create.So,for a minimal investment,you can find usability and design problems and adjust your UI before you invest heavily大量地 in the final design and technologies.,Definition of Prototype,原型可以分为三类：,淘汰(抛弃)式(disposable)：目的达到即被抛弃，原型不作为最终产品。,演化式(evolutionary)：系统的形成和发展是逐步完成的，它是高度动态迭代和高度动态的循环，每次迭代都要对系统,重新,进行规格说明、,重新,设计、,重新,实现和,重新,评价，所以是对付变化最为有效的方法。,增量式(incremental)：系统是一次一段地,增量构造,，与演化式原型的最大区别在于增量式开发是在,软件总体设计,基础上进行的。很显然，其应付变化的能力比演化式差。,Prototype Tools 2014-2-28软件121,原型的呈现形式主要有,Web页面(HTML,ASP),、,框架图（Wireframe）,和微软,窗体(Windows,Forms),等几种。进行原型设计的软件工具也有很多种，目前企业比较常用的设计工具有Frontpage,Dreamweaver,MS Visio、Axureakse:和Excel等。,软件原型设计的工作是,结合需求用例说明书,中的用例、批注、以及流程图画框架图，将软件功能和操作完整而准确的表述给软件开发人员，市场人员和用户，并通过沟通会议，反复修改直至最终确认，开始投入执行。,Prototype Tools-VISIO,Visio是强大的框架图原型设计工具,，他有很多的模板可以选择，可以制作包括流程图、平面布置图、工程绘图、日程图、软件界面、UML、灵感脑图Visio的优点是上手快，能比较快的画出不同种类的图，但缺点是外观功能不够强大。,Visio并不太适合太过于精细的高保真原型，后者需要用Photoshop、fireworks之类的工具来画，甚至直接使用Dreamweaver和FrontPage制作html页面来用。,Visio设计的原型图比较适合“开始构思”到“提交给美工设计”的过程中使用。,Visio的缺点是在表现,交互方面比较弱,。,EHSS Wireframe Made by VISIO（,To demonstrate with visio,）,Practice,You are required to create a wireframe(maybe with several UI pages)for at least one use case using,VISIO,.,-,Refer to the Prototype in,web pages,and,wireframe,.,To develop requirements using UML,1.,UML Instruction,2.,To develop requirements using UML,3.Use Case and Prototype,4.Requirement Management,2.Requirement Review,1.Requirement Development,Overview,5.ITO Terms for RD/REQM,Requirement Management,Requirements Management(REQM)involves applying management disciplines to the requirements development process.,REQM involves establishing and maintaining an,agreement,with the customer on the requirements for a project,managing,changes,to requirements,ensuring,consistency,between the requirements,the project plans and work products,and maintaining bi-directional,traceability,of requirements and work products。,Review,About the practice;,What are the main types for prototyping?,What presentation types are there for prototyping?,Procedures for REQM,2013-5-16 S111,Obtain understanding,Obtain commitment,Control changes,Maintain traceability,Identify inconsistencies,Obtain understanding(,需求理解,),2013-5-16 S115,Inputs,1,Software requirements,Steps,1,PM and stakeholders establish,acceptance criteria,for defining requirements with appropriate requirements providers,2,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 requirements,Exit Criteria,1,The stakeholders understand and commit to the requirements.,Control changes（变更流程控制）,Inputs,1,The new requirement or,requirement change request,Steps,1,PM defines which products of this process are to be maintained under configuration control.,2,PM and relevant stakeholders evaluate and document impact of,the proposed changes,against existing commitments,project plans,current requirements,project activities,and other work products,3,PM,relevant stakeholders and high level management review the changes and make their decisions(approve or disapprove),4,If changes are approved,relevant stakeholders execute the changes for the impacted work products.,5,CM makes requirements and change data available to the projects relevant stakeholders,Outputs,1,Modified SRS,Modified related CI items,Change request Form,Maintain traceability,Entry Criteria,1,Requirements have been understood,Design spec has been reviewed,test plan and test case have been reviewed,Steps,1,The 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 ID,2,Designers fill in the relevant Design spec ID,3,QA manager fills in the relevant test plan and test case ID,4,Developers fill in the relevant code ID,5,PM maintains the Requirement Traceability Matrix,Exit Criteria,1,The,Requirement Traceability Matrix Form,is established and maintained,Identify inconsistencies,Entry Criteria,1,Requirements are documented and understood or requirement changes are approved.,Inputs,1,Software requirement spec,Steps,1,PM and relevant stakeholders review project plans,activities,and work products for consistency with requirements and requirements changes.,2,Inconsistencies(issues)with rationale,rnl基本原理,are documented and corrective action are planned as appropriate,3,PM and relevant stakeholders update plans and work products resulting from changes or additions to the requirements baseline,Outputs,1,Issue tracking list,Exit Criteria,1,Issue tracking mechanism is established and all issues are tracked and corrective actions are taken.,3.Requirement Management,4.Requirement Review,2.Use Case and Prototype,1.Requirement Development,Overview,5.ITO Terms for RD/REQM,4.Requirement Review,需求评审是技术评审的一种。技术评审通常指对需求、设计、代码和测试的评审，四者的评审过程和方法都是相同的。,技术评审的目的是在软件开发阶段对有关技术性文档进行,正确性的检查,，侧重于在缺陷导入阶段就尽早尽可能地发现他们以防止他们进入下一个阶段（To focus on discovering defects at the defect import phase as early as possible and prevent them from entering the next phase），从而节约成本，使后续过程的变更减少，减少重复工作的工作量（to reduce rework effort），降低风险。,技术评审尝试发现更多的缺陷而不能发现所有的缺陷,。,Roles and Responsibility,Roles,Key Responsibilities,Project Manager,Apply Technical Review,Ensure all deliverables have been prepared,Review Leader,Develop Technical Review Plan,Distribute deliverables to Review Members,Provide the Technical Review Report,Review Member,Review deliverables and discover defects,Author,(SA/BA),Provide deliverables,Introduce deliverables,Fix defects and modify deliverables,Provide the Technical Review Measurement Report,Recorder,Record technical review course in the Technical,Review Record,Technical Review Mechanism,Formal Technical Review:,Inspection-follow technical review workflow,strictly,by holding formal review,meeting,.,2.Informal Technical Review,Walkthrough,Four Eyes Review-review form is,flexible,can be conducted,within project team,or by several companions(同事、同伴),Formal Technical Review Procedure,Entry Criteria,Deliverables are completed,Inputs,1,Deliverables,2,Standards and Checklists,Steps,1,Apply Technical Review,Project Manager applies PMO for the technical review,2,Identify Review Leader,PMO 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 discovered,Formal Technical Review Procedure,5,Hold Review Meeting,The 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 eligible,elidbl符合条件的、合格的,:not to be modified,not to review again,Deliverable 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 Procedure,6,Deliverable 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.,7,Close Review:,The review team,confirms,the closure of all the defects and closes the review.,Outputs,:Technical Review Record,Exit Criteria,:All defects are fixed,Requirement Review Checklist and Record,Requirement Review Checklist and Record,Practice:,Conduct the requirement review for SRS (parital)of HRMS project using the SRS Review Record.xls,3.Requirement Management,4.Requirement Review,2.Use Case and Prototype,1.Requirement Development,Overview,5.ITO Terms for RD/REQM,