ModuleRDREQM需求开发与需求管理_第1页
ModuleRDREQM需求开发与需求管理_第2页
ModuleRDREQM需求开发与需求管理_第3页
ModuleRDREQM需求开发与需求管理_第4页
ModuleRDREQM需求开发与需求管理_第5页
已阅读5页,还剩40页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、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 Requiremen

2、ts4)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) i

3、s 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 desir

4、ed 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 requir

5、ements 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. De

6、velop and Validate Product Requirements1.Develop Customers Requirements1. 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

7、 to reach the complete and consistent requirements. 1. Develop Customers Requirements3. The SA develop the Customer Requirement Specification ,it contains:The product instruction The product constraintsThe product function requirementThe product non-function requirementInterface, software, hardware,

8、 quality and so on2. Analyze and Validate Requirements1. 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 comprehe

9、nsive methods ;(Prototypes)3. The SA develop the Software Requirement Specification (SRS软件需求规格说明书包括:Use Case Diagram+ Use Case Spec + Non-functional Requirements)PracticeRefer to Use Case Diagram: You are required to establish the High level USE CASE Diagrams and the detailed ones for at least one h

10、igh 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 Review2. Use Case and Prototype 1. Requirement DevelopmentOverview5. ITO Terms for RD/REQMUse Case Spec

11、用例规格说明书用例规格说明书 用例规约(Use Case Specification)是用例建模(Use Case Modeling)的最终呈现说明,该文档描述用例的细节内容。用例方法完全是站在用户的角度上(从系统的外部)来描述系统的功能的。 在用例方法中,我们把被定义系统看作是一个黑箱,我们并不关心系统内部是如何完成它所提供的功能的。用例方法首先描述了被定义系统有哪些外部使用者(抽象成为Actor),这些使用者与被定义系统发生交互。针对每一参与者,用例方法又描述了系统为这些参与者提供了什么样的服务(抽象成为Use Case),或者说系统是如何被这些参与者使用的。 与传统的功能分解方式相比,用

12、例方法完全是从外部来定义系统的功能,它把需求与设计完全分离开来。在面向对象的分析设计方法中,用例模型主要用于表述系统的功能性需求,系统的设计主要由对象模型来记录表述。另外,用例定义了系统功能的使用环境与上下文,每一个用例描述的是一个完整的系统服务。用例方法比传统的需求规格说明书更易于被用户所理解,在实际外包项目中,用例规约一般结合原型模型作为开发人员和用户之间针对系统需求进行沟通的一个有效手段。Use Case Spec用例规格说明书用例规格说明书用例场景 (Use-Case Scenario) 场景主要是由基本流(basic flow成功场景)和备选流(alternative flow失败场

13、景)组合而成的。用例在实际执行的时候会有很多的不同情况发生,称之为用例场景;也可以说场景是用例的实例,我们在描述用例的时候要覆盖所有的用例场景,否则就有可能导致需求的遗漏。场景既可以帮助我们防止需求的遗漏,同时也可以对后续的开发工作起到很大的帮助:开发人员必须实现所有的场景、测试人员可以根据用例场景来设计测试用例。Use Case Spec用例规格说明书用例规格说明书EHSS Use Case SpecSample2014-3-3测试测试121PracticeYou are required to develop at least one USE CASE DIAGRAM with the i

14、nstructions for the HRMS SRS as the Use Case Sample.Review for this Module1. Please list the methods SA may use during the requirement researching works.2. What is the purpose for RD ?3. What are the main activities for the RD process?4. Compared to the classic SRS, what are the comprehensive method

15、s for requirement validation? 3. Requirement Management 4. Requirement Review2. Use Case and Prototype 1. Requirement DevelopmentOverview5. ITO Terms for RD/REQMWhy Prototyping原型法原型法?根据国外有关统计,大约 66% 的软件开发项目不是失败,就是超出预算、超出项目时间,或是交付缩水的功能。项目失败或亏损的前三大原因为: 缺乏使用者的参与 需求或规格不完整 需求或规格变更根据离岸外包项目成本和进度等要求的特点,一些需求

16、管理技术或者上百页的文档已经不合时宜,不能作为我们跟客户讨论交流的介质和核心。所以我们需要制作原型,用来提高与客户沟通的效率、让客户参与到设计中来并且帮助他们找到核心需求。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 p

17、rototype is to save time and resources. The value of the prototype is that it is a facadefs: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 fin

18、d usability and design problems and adjust your UI before you invest heavily大量地 in the final design and technologies.Definition of Prototype原型可以分为三类: 淘汰(抛弃)式(disposable):目的达到即被抛弃,原型不作为最终产品。 演化式(evolutionary):系统的形成和发展是逐步完成的,它是高度动态迭代和高度动态的循环,每次迭代都要对系统重新进行规格说明、重新设计、重新实现和重新评价,所以是对付变化最为有效的方法。 增量式(increme

19、ntal):系统是一次一段地增量构造,与演化式原型的最大区别在于增量式开发是在软件总体设计基础上进行的。很显然,其应付变化的能力比演化式差。 Prototype Tools 2014-2-28软件软件121 原型的呈现形式主要有Web页面(HTML, ASP)、框架图(Wireframe)和微软窗体(Windows, Forms)等几种。进行原型设计的软件工具也有很多种,目前企业比较常用的设计工具有Frontpage, Dreamweaver, MS Visio、Axureakse: 和Excel等。 软件原型设计的工作是结合需求用例说明书中的用例、批注、以及流程图画框架图,将软件功能和操作完

20、整而准确的表述给软件开发人员,市场人员和用户,并通过沟通会议,反复修改直至最终确认,开始投入执行。Prototype Tools-VISIO Visio是强大的框架图原型设计工具,他有很多的模板可以选择,可以制作包括流程图、平面布置图、工程绘图、日程图、软件界面、UML、灵感脑图Visio的优点是上手快,能比较快的画出不同种类的图,但缺点是外观功能不够强大。 Visio并不太适合太过于精细的高保真原型,后者需要用Photoshop、fireworks之类的工具来画,甚至直接使用Dreamweaver和FrontPage制作html页面来用。Visio设计的原型图比较适合“开始构思”到“提交给美

21、工设计”的过程中使用。 Visio的缺点是在表现交互方面比较弱。EHSS Wireframe Made by VISIO(To demonstrate with visio)PracticeYou 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 UML1. UML Instru

22、ction2. To develop requirements using UML3. Use Case and Prototype4. Requirement Management2. Requirement Review1. Requirement DevelopmentOverview5. ITO Terms for RD/REQMRequirement ManagementRequirements Management (REQM) involves applying management disciplines to the requirements development proc

23、ess. 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

24、 products。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

25、-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 sta

26、keholders 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 maint

27、ained 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 a

28、nd 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 FormMain

29、tain 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 fi

30、lls 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

31、 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

32、 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 Cr

33、iteria1Issue 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需求评审是技术评审的一种。技术评审通常指对需求、设计、代码和测试的评审,四者的评审

34、过程和方法都是相同的。 技术评审的目的是在软件开发阶段对有关技术性文档进行正确性的检查,侧重于在缺陷导入阶段就尽早尽可能地发现他们以防止他们进入下一个阶段(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 Re

35、sponsibilityRolesKey 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/B

36、A)Provide deliverablesIntroduce deliverablesFix defects and modify deliverablesProvide the Technical Review Measurement ReportRecorderRecord technical review course in the Technical Review RecordTechnical Review Mechanism1. Formal Technical Review: Inspection-follow technical review workflow strictl

37、y 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 ProcedureEntry CriteriaDeliverables are completedInputs1 Deliverables2 Standards and Ch

38、ecklistsSteps1 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

39、界外、非现场界外、非现场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. De

40、fects 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 re

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论