ModuleRDREQM需求開(kāi)發(fā)與需求管理

1、Module 5Requirement Development and ManagementGeorge Cao /曹紀(jì)清 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問(wèn)卷, Interviews面談, Operational scenarios操作場(chǎng)景 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軟件需求規(guī)格說(shuō)明書包括：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. 識(shí)別用例圖Use case diagram過(guò)程：1.識(shí)別actor（end users, admin, external interfaces）2.識(shí)別這些角色使用系統(tǒng)的哪些功能或操作或數(shù)據(jù)交互？3.底層用例細(xì)化3. Requirement Management 4. Requirement Review2. Use Case and Prototype 1. Requirement DevelopmentOverview5. ITO Terms for RD/REQMUse Case Spec

11、用例規(guī)格說(shuō)明書用例規(guī)格說(shuō)明書 用例規(guī)約(Use Case Specification)是用例建模（Use Case Modeling）的最終呈現(xiàn)說(shuō)明，該文檔描述用例的細(xì)節(jié)內(nèi)容。用例方法完全是站在用戶的角度上(從系統(tǒng)的外部)來(lái)描述系統(tǒng)的功能的。 在用例方法中，我們把被定義系統(tǒng)看作是一個(gè)黑箱，我們并不關(guān)心系統(tǒng)內(nèi)部是如何完成它所提供的功能的。用例方法首先描述了被定義系統(tǒng)有哪些外部使用者(抽象成為Actor)，這些使用者與被定義系統(tǒng)發(fā)生交互。針對(duì)每一參與者，用例方法又描述了系統(tǒng)為這些參與者提供了什么樣的服務(wù)(抽象成為Use Case)，或者說(shuō)系統(tǒng)是如何被這些參與者使用的。 與傳統(tǒng)的功能分解方式相比，用

12、例方法完全是從外部來(lái)定義系統(tǒng)的功能，它把需求與設(shè)計(jì)完全分離開(kāi)來(lái)。在面向?qū)ο蟮姆治鲈O(shè)計(jì)方法中，用例模型主要用于表述系統(tǒng)的功能性需求，系統(tǒng)的設(shè)計(jì)主要由對(duì)象模型來(lái)記錄表述。另外，用例定義了系統(tǒng)功能的使用環(huán)境與上下文，每一個(gè)用例描述的是一個(gè)完整的系統(tǒng)服務(wù)。用例方法比傳統(tǒng)的需求規(guī)格說(shuō)明書更易于被用戶所理解，在實(shí)際外包項(xiàng)目中，用例規(guī)約一般結(jié)合原型模型作為開(kāi)發(fā)人員和用戶之間針對(duì)系統(tǒng)需求進(jìn)行溝通的一個(gè)有效手段。Use Case Spec用例規(guī)格說(shuō)明書用例規(guī)格說(shuō)明書用例場(chǎng)景 (Use-Case Scenario) 場(chǎng)景主要是由基本流（basic flow成功場(chǎng)景）和備選流（alternative flow失敗場(chǎng)

13、景）組合而成的。用例在實(shí)際執(zhí)行的時(shí)候會(huì)有很多的不同情況發(fā)生，稱之為用例場(chǎng)景；也可以說(shuō)場(chǎng)景是用例的實(shí)例，我們?cè)诿枋鲇美臅r(shí)候要覆蓋所有的用例場(chǎng)景，否則就有可能導(dǎo)致需求的遺漏。場(chǎng)景既可以幫助我們防止需求的遺漏，同時(shí)也可以對(duì)后續(xù)的開(kāi)發(fā)工作起到很大的幫助：開(kāi)發(fā)人員必須實(shí)現(xiàn)所有的場(chǎng)景、測(cè)試人員可以根據(jù)用例場(chǎng)景來(lái)設(shè)計(jì)測(cè)試用例。Use Case Spec用例規(guī)格說(shuō)明書用例規(guī)格說(shuō)明書EHSS Use Case SpecSample2014-3-3測(cè)試測(cè)試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原型法原型法?根據(jù)國(guó)外有關(guān)統(tǒng)計(jì)，大約 66% 的軟件開(kāi)發(fā)項(xiàng)目不是失敗，就是超出預(yù)算、超出項(xiàng)目時(shí)間，或是交付縮水的功能。項(xiàng)目失敗或虧損的前三大原因?yàn)椋?缺乏使用者的參與 需求或規(guī)格不完整 需求或規(guī)格變更根據(jù)離岸外包項(xiàng)目成本和進(jìn)度等要求的特點(diǎn)，一些需求

16、管理技術(shù)或者上百頁(yè)的文檔已經(jīng)不合時(shí)宜，不能作為我們跟客戶討論交流的介質(zhì)和核心。所以我們需要制作原型，用來(lái)提高與客戶溝通的效率、讓客戶參與到設(shè)計(jì)中來(lái)并且?guī)椭麄冋业胶诵男枨?。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相對(duì)于 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)：目的達(dá)到即被拋棄，原型不作為最終產(chǎn)品。 演化式(evolutionary)：系統(tǒng)的形成和發(fā)展是逐步完成的，它是高度動(dòng)態(tài)迭代和高度動(dòng)態(tài)的循環(huán)，每次迭代都要對(duì)系統(tǒng)重新進(jìn)行規(guī)格說(shuō)明、重新設(shè)計(jì)、重新實(shí)現(xiàn)和重新評(píng)價(jià)，所以是對(duì)付變化最為有效的方法。 增量式(increme

19、ntal)：系統(tǒng)是一次一段地增量構(gòu)造，與演化式原型的最大區(qū)別在于增量式開(kāi)發(fā)是在軟件總體設(shè)計(jì)基礎(chǔ)上進(jìn)行的。很顯然，其應(yīng)付變化的能力比演化式差。 Prototype Tools 2014-2-28軟件軟件121 原型的呈現(xiàn)形式主要有Web頁(yè)面(HTML, ASP)、框架圖（Wireframe）和微軟窗體(Windows, Forms)等幾種。進(jìn)行原型設(shè)計(jì)的軟件工具也有很多種，目前企業(yè)比較常用的設(shè)計(jì)工具有Frontpage, Dreamweaver, MS Visio、Axureakse: 和Excel等。 軟件原型設(shè)計(jì)的工作是結(jié)合需求用例說(shuō)明書中的用例、批注、以及流程圖畫框架圖，將軟件功能和操作完

20、整而準(zhǔn)確的表述給軟件開(kāi)發(fā)人員，市場(chǎng)人員和用戶，并通過(guò)溝通會(huì)議，反復(fù)修改直至最終確認(rèn)，開(kāi)始投入執(zhí)行。Prototype Tools-VISIO Visio是強(qiáng)大的框架圖原型設(shè)計(jì)工具，他有很多的模板可以選擇，可以制作包括流程圖、平面布置圖、工程繪圖、日程圖、軟件界面、UML、靈感腦圖Visio的優(yōu)點(diǎn)是上手快，能比較快的畫出不同種類的圖，但缺點(diǎn)是外觀功能不夠強(qiáng)大。 Visio并不太適合太過(guò)于精細(xì)的高保真原型，后者需要用Photoshop、fireworks之類的工具來(lái)畫，甚至直接使用Dreamweaver和FrontPage制作html頁(yè)面來(lái)用。Visio設(shè)計(jì)的原型圖比較適合“開(kāi)始構(gòu)思”到“提交給美

21、工設(shè)計(jì)”的過(guò)程中使用。 Visio的缺點(diǎn)是在表現(xiàn)交互方面比較弱。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需求評(píng)審是技術(shù)評(píng)審的一種。技術(shù)評(píng)審?fù)ǔＶ笇?duì)需求、設(shè)計(jì)、代碼和測(cè)試的評(píng)審，四者的評(píng)審

34、過(guò)程和方法都是相同的。 技術(shù)評(píng)審的目的是在軟件開(kāi)發(fā)階段對(duì)有關(guān)技術(shù)性文檔進(jìn)行正確性的檢查，側(cè)重于在缺陷導(dǎo)入階段就盡早盡可能地發(fā)現(xiàn)他們以防止他們進(jìn)入下一個(gè)階段（To focus on discovering defects at the defect import phase as early as possible and prevent them from entering the next phase），從而節(jié)約成本，使后續(xù)過(guò)程的變更減少，減少重復(fù)工作的工作量（to reduce rework effort），降低風(fēng)險(xiǎn)。技術(shù)評(píng)審嘗試發(fā)現(xiàn)更多的缺陷而不能發(fā)現(xiàn)所有的缺陷。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、界外、非現(xiàn)場(chǎng)界外、非現(xiàn)場(chǎng)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