軟件需求工程09-3

1、第三章 軟件需求獲取周立新 博士北京大學軟件與微電子學院課程提綱軟件需求根本理論和概念 軟件需求工程過程 軟件需求獲取 軟件需求分析 軟件需求規(guī)格說明 軟件需求驗證 軟件需求管理 軟件需求實現(xiàn) 軟件需求工程新進展 軟件需求開發(fā)與需求管理工具內容提要建立工程視圖和范圍需求獲取一.工程視圖和范圍文檔業(yè)務需求工程視圖解決方案 范圍和局限性業(yè)務環(huán)境產品成功的因素基于工程視圖和范圍的管理工程視圖和范圍文檔業(yè)務需求 為什么開發(fā)該工程？新產品為客戶和軟件開發(fā)者帶來的利益背景業(yè)務機遇業(yè)務目標客戶需求業(yè)務風險工程視圖和范圍文檔背景總結新產品的理論根底產品開發(fā)的歷史背景業(yè)務機遇描述產品競爭的市場及運用的環(huán)境現(xiàn)有產

2、品評價及存在的問題新產品的競爭優(yōu)勢工程視圖和范圍文檔業(yè)務目標描述產品所帶來的商業(yè)利潤客戶獲得的價值，如提高生產率、節(jié)省開支、符合產業(yè)標準、提高可用性等產品預算和交付日期工程視圖和范圍文檔客戶需求描述典型客戶的需求客戶對現(xiàn)有產品使用所遇到的問題通過原型或舉例闡述新產品的使用方法確定新產品運行的軟、硬平臺定義較高層次的關鍵接口產品的性能要求工程視圖和范圍文檔業(yè)務風險市場競爭帶來的風險產品預算和交付日期帶來的風險用戶是否可以接受實現(xiàn)技術的可行性預測每一項風險的嚴重性制定風險應對或減輕措施工程視圖和范圍文檔工程視圖解決方案 長遠工程視圖，業(yè)務目標，決策信息等工程視圖陳述 開發(fā)新系統(tǒng)(產品)的目的簡要陳

3、述產品主要性能列表 強調區(qū)別于以往產品和競爭產品的特性主要假設和產品依賴的環(huán)境工程視圖和范圍文檔范圍和局限性 確定工程根本解決方案及適用范圍，產品應包含和不應包含的性能Release 1.0 首次發(fā)行(開發(fā))的范圍，目的 (爭奪市場優(yōu)先權？)Release 2.0 隨后發(fā)行(開發(fā))的范圍Release 相關的產品局限性和專用性工程視圖和范圍文檔業(yè)務環(huán)境 客戶分類概述和工程管理優(yōu)先級不同客戶群的特征，包括客戶能獲得的益處，對新產品的態(tài)度，對產品哪些特性最感興趣，使用該產品的可能性有多大，客戶的限制工程優(yōu)先級，通過對產品性能、質量、開發(fā)方案、開發(fā)本錢、可用資源(主要為人力)的分析建立工程開發(fā)優(yōu)先級

4、工程視圖和范圍文檔產品成功的因素產品成功的定義和測量影響產品成功的主要因素與所有關鍵風險承擔者達成一致一.工程視圖和范圍文檔基于工程視圖和范圍的管理新的需求或特性出現(xiàn)時確認是否在工程范圍之內。當不得不改變工程范圍時，必須重新商定預算、資源和進度安排。為應對較小改變可能帶來的麻煩，最初方案中留有余地，如25%，會是較現(xiàn)實的做法.通常拒絕一個新的需求因缺乏根據難以做到，但基于工程視圖和范圍文檔卻可以合理地拒絕這些新的要求。需求獲取的三個主要方面:應獲取什么信息?應使用何種信息來源?應采用什么獲取技術?二.軟件需求獲取1.需求獲取的信息獲取信息就是為了能夠得到產生需求文檔和規(guī)格說明所必需的信息：問題

5、域的描述要求解決的問題列表(需求)用戶對解系統(tǒng)的行為或結構施加的任何約束2. 信息來源高層系統(tǒng)需求 System Requirements客戶(實際的和潛在的) Customers客戶的“規(guī)格說明書 CRS原有解系統(tǒng)(即運行在問題域中，執(zhí)行與預期的新的解系統(tǒng)相似功能的系統(tǒng))及其文檔原有系統(tǒng)的用戶競爭對手的產品應用領域專家定義了任何接口系統(tǒng)的特征和行為的文檔相關的技術標準和法規(guī)2.1 Identifying Requirements Info SourcesAs a start points, you first need to identifyKey stakeholders - as we

6、learned before, they are users, customers and developersPotential users and operators who need this productHistorical data, including process dataBecause they are easy to identify? No, because they are important!2.1 Identifying Requirements Info SourcesBaseline documents 基線文檔Source requirements docu

7、ments 原始需求Contracts 合同Proposal 提案StandardsProduct visions and scopeRegulationsCustomer requirements2.1 Identifying Requirements Info SourcesAuxiliary documents 補充文檔Early system concept studiesUser profiles 用戶概況Marketing studyInterviewing notesCurrent technologyWhite papersLessons learned study2.1 Id

8、entifying Requirements Info SourcesRelated systemsSimilar systemsPredecessor systemsPrototypesInterfacing systemsExisted subsystems2.1 Identifying Requirements Info SourcesInterviews and discussions with potential usersMarketing surveys and user questionnaires調查表Observing users at workScenario analy

9、sis of user tasksEvents (stimulus) and responses (for real time system)2.2 Evaluate Requirements Info SourcesRefered documents version, is it latest? Avoid to use outdated source documentsRefered documents are complete? The information sources are relevant to current product?Do you interview the rig

10、ht person?Why they are reluctant to provide information?課程工程課堂分組討論目的：1描述問題域2確定該系統(tǒng)需求信息來源課程工程課堂分組討論要求：對工程從問題域加以描述(關鍵點即可)指明已有信息和待挖掘信息并分類對不確定的信息方案如何獲取確定信息來源可能的困難每小組選一位代表(moderator)加以陳述將結果完整記錄(記錄關鍵點，課后整理)小組討論20分鐘，每組陳述35分鐘3. 需求獲取技術一旦確定了可能的信息來源，接下來的工作是通過選擇適宜的獲取技術來挖掘所需的信息。3. 需求獲取技術3.1 面談 Interviewing面談是最直接的

11、獲得需求的方法結構化面談，集中討論一組事先方案好的問題；非結構化面談，面談進行時通過臨場發(fā)揮獲得問題的答案；對面談主題做充分的準備可以大大提高面談效率,例如對被咨詢人的預先了解及期望獲取的答案;面談進程控制面談信息記錄3. 需求獲取技術3.2 調查表 Surveys當事先可以很好地確定問題時，調查表方法提供了一個高效的需求獲取方法;對問題列表預先作充分的準備，以便使問題易于理解，最小化二義性;調查表可以認為是結構化面談的最終表現(xiàn)形式，可作為面談技術的補充方法。3. 需求獲取技術3.3 用例(Use Case)和場景(Scenario)分析一個精確定義的Use Case是面向解系統(tǒng)的而非問題域的

12、。Use Case的觀點和方法論對需求開發(fā)是極有幫助的，因為它可以描述用戶使用系統(tǒng)所要完成的所有任務。Scenario描述了系統(tǒng)對用戶特定的輸入存在的可能的響應，可以和Use Case聯(lián)合使用。經常和分析階段一起使用。3. 需求獲取技術3.4 頭腦風暴 Brainstorming用于復雜、模糊不清的需求獲取。通過一個短暫、集中式的討論，使關鍵系統(tǒng)需求浮出水面。在這里，參加人員應包括各關鍵性領域代表，討論將是自由式的，著重的是想法而不是辯論和批評。3. 需求獲取技術3.5 需求裁剪 Requirements Tailoring當存在一份客戶需求規(guī)格說明書，或者存在一份相似的已有產品需求規(guī)格說明書

13、時，就可使用這種技術。需求裁剪可以是手工的，也可以通過工具來完成。3. 需求獲取技術Key Points:Actually, all the technique can be combined together, 在需求獲取過程中它們并非獨立進行的。與Stakeholders的交流(communication)與溝通(interaction)是需求獲取過程中的關鍵能力表達。3.1 InterviewingThe 80/20 Rule80% of the talking should be done by the customers or users 20% of the talking sho

14、uld be done by the requirement engineer (interviewer)3.1 InterviewingKey skills for successful interviewPreparationAsking the right questionsCareful listeningChecking for the understandingRecording information3.1 InterviewingPreparation 準備Environmental Scanning 環(huán)境審查Customers business 客戶的業(yè)務領域Customer

15、s needs 客戶的需要Resource and document asked for 打算獲得什么信息和文檔資料Prepare for presentation, demonstration 準備你的陳述和演示等3.1 InterviewingPreparation 準備Establishment of Rapport 建立和諧的環(huán)境Use relaxed and approachable manner平易近人的態(tài)度Use non-technical language, No jargon!少用專業(yè)語言，行話Establish comfortable time frame 建立客戶滿意的時

16、間表3.1 InterviewingAsking the right questions詢問問題是最直接的信息獲取方法從最容易答復的問題著手，可以使用戶容易進入角色過程中通過詢問確信懂得對方的想法正確跟蹤確認前面的問題正確地總結關鍵點并加以確認3.1 InterviewingClosed questions 直接的問題Answer: Yes or No例如：你是該工程的負責人嗎？誰是該工程的財務經理？六個月的開發(fā)周期是否現(xiàn)實？3.1 Interviewing直接問題的優(yōu)點：可以有效地控制問題范圍和答案在短時間內包含較多的問題答案容易記錄和分析客戶容易答復3.1 Interviewing直接問題

17、的缺點：因答復過于簡單，不能得到充分的信息，需要有后續(xù)的問題進一步獲取更多的信息其答復可能不代表客戶的真實想法鋒利的問題可能會被隱藏采訪者占用太長談話時間3.1 Interviewing直接問題適合的場合：復雜問題的前奏采集簡單的事實數(shù)據確認對問題的理解3.1 InterviewingOpen questions 間接問題 客戶/用戶決定提供什么信息，答復過程可能比較復雜能夠派生新的想法例如：你是該工程中擔任什么角色？為什么該系統(tǒng)需要改進？這是我們提出的初步解決方案，你看能否解決現(xiàn)有的產品問題？3.1 Interviewing間接問題的優(yōu)點：表達對客戶/用戶思想、觀點的重視提供客戶/用戶認為的

18、重要信息和隱藏問題客戶/用戶能主動提供一些未涉及到的信息能顯現(xiàn)客戶/用戶對問題的不了解或錯誤理解談話多數(shù)時間在客戶/用戶方，符合80/20原那么能夠獲取新的產品解決思路 - brainstorming3.1 Interviewing間接問題的缺點：答復以下問題需要較長時間問題較難跟蹤和記錄，必需有較好的訓練才能記錄下有價值的和關鍵的信息需防止客戶/用戶思路跑題，通常需要穿插一些直接問題來保持主題連貫性3.1 InterviewingPrimary and secondary questions 原始的和派生的問題原始問題引入新的主題，可以是直接問題也可以是間接問題如：關于新的應用流媒體(str

19、eaming)能否談談你的認識？派生問題試圖從原始問題中提取或探查更多的信息,如：為什么你認為流媒體業(yè)務還不能開展？是用戶負擔不起嗎？3.1 InterviewingSummary questions 總結性問題為確信對一個主題的理解無二義性幫助采訪者獲得最后確定性信息當與進一步的行動相關聯(lián)時會使用根據我們的討論，整個方案分為2個階段，第一階段為調研，需要3個月，2個人，共6個人月，基于此決定下一階段任務。是這樣嗎？3.1 InterviewingCareful listening 集中精力傾聽仔細的傾聽和正確的提問是成功地與客戶/用戶交流的關鍵技術不能很好地傾聽對方、理解對方，就不可能提出恰

20、當?shù)膯栴}每字每句的真實含義及細微差異沉默(silence) 問題無法答復?拒絕答復?身體語言(body language)3.1 Interviewing傾聽的障礙：不能集中精力同樣詞語但可能包含不同含義先入為主的觀念和看法傾聽的關鍵：傾注熱情，表現(xiàn)出真正的關注給客戶/用戶足夠時間解釋其想法3.1 InterviewingCheck for understanding對關鍵點重復解釋關注關鍵細節(jié)對進一步的活動達成共識留出足夠時間進行總結，而不是草草收場 通過總結強調關鍵問題并發(fā)現(xiàn)可能的遺漏3.1 Interviewing記錄收集的信息recording info每條信息來之不易，將其清晰地記錄

21、下來不要期望將來慢慢整理也要讓別人讀懂你的記錄正式地文檔化大家關注的問題清單如何快速有效的獲取需求，并保證需求的完整性和正確性 如何更好的理解客戶的表達與客戶協(xié)商溝通 如何對不斷變化的需求做出反響對概念的理解和區(qū)別 如何實踐、如何在沒有開發(fā)經驗的情況下把握好本門課程、需要儲藏的知識 如何準確地區(qū)分業(yè)務需求、用戶需求和功能需求 客戶對系統(tǒng)開發(fā)的理由和重要性認識不充分監(jiān)理方提的需求過于細致?(合理? 限制? 時間?) Interview Skill ExciseGoal:Applying and practicing interviewing skills to identify key issu

22、es, needs and any concerns of stakeholders related to your projectInterview Skill ExciseApproach:請注意觀察所用的方法觀察interviewer是否對所關心的主題得到足夠的信息采訪時間10分鐘Interview Skill Excise check list開場使用了何種提問方式? Closed or Open?是否滿足20/80 ?使用了專業(yè)術語Jargon(行話)?是否使用了primary and secondary questioning?對談話過程有控制嗎?有沒有summary questi

23、oning?是否有效?3.2 User ClassesThe frequency with which they use the productTheir application domain experience and computer systems expertiseThe features they useThe tasks they perform in support of their business processesTheir access privilege or security levels (such as ordinary user, guest user, or

24、 administrator)3.2 User Classes3.2 User Classes一個實例: 用戶可以分為:高端用戶底端用戶職業(yè)用戶每類用戶特點不同，歸結到產品其功能也不同Communications with users用戶和開發(fā)者之間可能通訊途徑3.2 Product Champion產品代表最了解客戶的需求，是客戶與開發(fā)者之間的接口，通過產品代表解決溝通上的問題。產品代表從所代表的用戶類中收集需求信息，通過與需求分析人員合作解決用戶在需求表達上的不一致和不兼容性。產品代表必須具備較強的交流能力，熟知應用領域，在軟件開發(fā)方面有足夠的經驗，能夠判斷在現(xiàn)有技術背景和運行環(huán)境下，開發(fā)

25、路線是否可行。Who will be the product champion?If possible, best fit is the userSometimes, Project Champion is the meaning, Thus, a technical team leader may be a good choiceQuestion: does each class excise group need to identify a champion?Answer is yes, if you really want to make the communication more e

26、fficientMultiple Product ChampionsCurrent project is composed of multiple functionsOne person can not provide all related requirementsIt is the PMs responsibility to breakdown the task and assign to multiple championsProduct Champion Expectations分類活動 Check List計劃轉化產品的使用范圍和局限性；定義與其它系統(tǒng)的外部接口；定義現(xiàn)有用戶應用程序

27、到新系統(tǒng)的過渡途徑需求收集用戶需求描述；提出使用腳本和實例；解決需求沖突；定義實現(xiàn)優(yōu)先級；確定質量屬性和其它非功能需求；評估用戶接口原型驗證和確認審查需求文檔；確定用戶接受標準；根據使用腳本編寫測試用例；進行beta測試；提供測試數(shù)據集用戶幫助編寫用戶手冊和在線幫助；準備培訓材料；為同行提供產品演示變更管理對缺陷改正進行評估并根據所耗資源等設置實施優(yōu)先級；對增加的和增強的需求進行評估和設置優(yōu)先級；評估需求變更對用戶的影響；參加CCB參與變更決策需求決策問題如果個別用戶不能在需求方面達成一致意見，那么應由產品代表作出決策。如果不同的用戶類有不一致的需求，必須決策出滿足哪類用戶的需求更重要。這決定

28、于哪類用戶所占份額更大以及產品業(yè)務目標的匹配情況。不同的客戶可能都要求產品按照各自的喜好來設計，你不可能面面具到。通過業(yè)務目標找出你最關心的核心用戶，而相對次要的會拖延到未來版本。需求決策問題當開發(fā)者的想法與客戶需求沖突時，通常應該由客戶作出決策。但要防止陷入“客戶總是對的的陷阱中，要客觀地對待客戶的選擇，因為誰都會犯錯誤。由于市場需求更有分量，當其和開發(fā)部門想要開發(fā)的產品沖突時，通常會依照市場需求而定。問題是，為了獲得訂單，市場常常遷就客戶需求，而輕視這些需求的合理性和可行性。誰來作出需求決策Engineers?Team Leader or Manager?Change Control Bo

29、ard (CCB)?Senior Management Team?對客戶輸入進行分類客戶或用戶提供的需求信息往往是零散的、缺乏組織的。需求分析者必須把這些零散的信息按某種規(guī)那么分成不同類型以便最終形成組織良好的需求文檔。對客戶輸入進行分類業(yè)務需求 Business (op) requirements描述客戶開發(fā)部門可以從產品中得到的資金、市場和業(yè)務利潤方面的需求信息最有可能屬于業(yè)務需求范圍。For examples:Increase market share by X%Save $Y per year on electricity now wasted by inefficient units

30、Save $Z per year in maintenance costs that are consumed by the legacy system對客戶輸入進行分類使用實例 Use cases or scenarios有關利用系統(tǒng)執(zhí)行的業(yè)務任務或到達用戶目標的總的陳述可能就是使用實例，而特定的任務描述表示了用法說明。與客戶商討，把特定的、零散的任務描述概況成廣泛的、系統(tǒng)的使用實例是系統(tǒng)分析者的重要技能，可以通過不斷地讓客戶描述他們的業(yè)務工作流程活動來完成這一過程。對客戶輸入進行分類使用實例 Use cases or scenariosA user who says, “I need to

31、 is probably describing a use case:I need to print a mailing label for a packageI need to change to Cell ID, if A-GPS is not available對客戶輸入進行分類業(yè)務規(guī)那么 Business rule當客戶說明一些活動只能在特定條件下，由一些特定的人來完成時，客戶是在描述一個業(yè)務規(guī)那么，既業(yè)務過程的操作原那么。而業(yè)務規(guī)那么是由一系列的功能需求來完成的。Must comply with Must conform to If , then Must be calculated

32、 according to 對客戶輸入進行分類功能需求對諸如“用戶應該能執(zhí)行某些功能，“系統(tǒng)應該具備某些行為的信息根本上屬于功能需求范疇。功能需求描述了系統(tǒng)展示的可觀察行為，大多數(shù)是處于執(zhí)行者或系統(tǒng)輸入 系統(tǒng)響應順序的環(huán)境中。功能需求定義了系統(tǒng)應該做什么，組成了需求規(guī)格說明的最重要的局部。對客戶輸入進行分類質量屬性對系統(tǒng)如何能很好地執(zhí)行某些行為等方面的陳述屬于質量屬性，這是一種非功能需求，往往包括如下相關的一些屬性：快捷性、簡易性、直覺性、健壯性、可靠性、執(zhí)行速度和效率?？蛻魧|量屬性的表達經常不準確和模棱兩可，承諾的不切實際的屬性可能給后面的開發(fā)帶來無窮的麻煩。對客戶輸入進行分類外部接口這類

33、需求描述的是系統(tǒng)與外部的聯(lián)系，包含用戶接口和通信機制，外部實體可能是另外一個軟件或硬件應用系統(tǒng)?？蛻魧ν獠拷涌诘拿枋隹赡転椋簭哪承┰O備讀取信號給其它系統(tǒng)發(fā)送消息以某種格式讀取文件對一些硬件設備進行控制等對客戶輸入進行分類限制限制是指一些合理限制設計者和程序員應選擇的條件。這是軟件需求規(guī)格說明中的另一類非功能需求。但要盡量防止客戶施加不必要的限制，因為這會阻礙提出一個好的解決方案以及軟件的可移植性。一定的限制卻有助于提高質量屬性。客戶描述可能為：必須使用一個特定的數(shù)據庫或語言不能申請多于一定數(shù)量的內存操作必須與某些其它系統(tǒng)或應用程序相同對客戶輸入進行分類數(shù)據定義當客戶描述一個數(shù)據項或一個復雜的業(yè)

34、務數(shù)據結構的格式、允許值和缺省值時，那么屬于數(shù)據定義范圍。把這些數(shù)據集中在數(shù)據字典中，這可以作為工程開發(fā)、測試和維護人員的主要參考文檔。對客戶輸入進行分類解決思想如果客戶描述了用戶與系統(tǒng)交互的特定方法以使系統(tǒng)產生一系列的活動，那么你在聽取建議性的解決方案，而不是需求，這會消耗需求獲取人員的局部精力，尤其是你不能判斷這一區(qū)別時。需求獲取重點應放在系統(tǒng)需要做什么而不是如何設計和構造。但不應無視這樣的信息，因為這有時可以幫助你更好地理解特定方法中隱含的用戶需求。Shared Vision Among Stakeholders需求產生操作流程與概念的產生需求標準用戶操作標準出現(xiàn)問題設計與完成操作可行性

35、驗證設計正確性驗證出現(xiàn)問題工程相關知識與背景成功CustomerUserShared Vision Among Stakeholders3.3 Use Case/Scenario與需求獲取Use case is not necessarily dependent on the object-oriented methodologyUse case focuses on what users need to accomplishTraditional ways focus on what they want the system to doIt provides a shared view fo

36、r customers, end users and developers to discuss the systems functionality and behavior3.3.1 ActorsAn actor is a person, another software system, or a hardware device that interacts with the system. An actor mayOnly input information to the systemOnly receive information from the systemInput and rec

37、eive information to and from the system ActorsThe following questions may help identify the actors for a systemWho is interested in a certain requirement?Where will the system be used?Who will benefit from the use of the system?Who will support and maintain the system?Does the system use an external

38、 resource?Does the system interact with a legacy system?3.3.2 Use CasesModel a dialogue between an actor and the system; describe a sequence of interactions between a system and an external actorRepresent the functionality provided by the systemA use case is a sequence of transactions performed by a

39、 system that yields a measurable result of values for an actor Use CasesThe following questions may help identify the use cases for a systemWhat are the tasks of each actor?Will any actor create, store, change, remove or read info in the system? What use cases do these operation?Will any actor need

40、to inform the system about sudden, external changes? Use CasesThe following questions may help identify the use cases for a systemDoes any actor need to be informed about certain occurrences in the system?What use cases will support and maintain the system?Can all functional requirements be performe

41、d by the use cases? Use Cases Relationships relationship:Optional behaviorBehavior that is only run under certain conditionsSeveral different flows that may be run based on actor selection Use Cases Relationships relationship:Sometimes, several use cases share a common set of steps. To avoid duplica

42、ting these steps in each such use case, define a separate use case that contains the shared functionality, whenever other use cases use this functionality, is used to indicate this relationshipEssential elements of a use-caseA unique identifierA name in the form of “verb + objectA short textual desc

43、ription written in natural languagePreconditions that must be satisfied before the use case can beginPostconditions after the use case is successfully completedThe flow events from the preconditions to the postconditionsThe flow of EventsMain flow, normal course, primary scenario, happy pathSubflows

44、, alternative flows, alternative scenarioExceptions handling (Can you estimate how much effort shall be employed on this? A practical example)The flow of EventsAnother way for a use case dialogA Scenario Description TemplateScenario number: 009Scenario name: User disables the connectionStarting cond

45、itions: The connection enabledUser disables the connectionSystem displays connection statusUser confirms the data is back-upedSystem disable the connection Finishing conditions: The connection disabledUser SystemCharacteristics of a ScenarioScenarios express the needs of the user by description of t

46、he system behavior in response to a stimulus from an actor. The stimulas and response may be data events, control events or conditionsScenarios are as non-technical as possibleEach scenario is treated as linear transactions, the complex relationships among scenarios are treated separatelyScenarios m

47、ake external interfaces clear and apparentCharacteristics of a ScenarioScenarios are the basis for validation of requirements and designScenarios can make the order and timing clearly expressed and facilitate real time problems definitionForce system failures and exceptional conditions to surfaceSce

48、narios can be used to identify uncertainties and risksIdentifying Use CasesIdentify the actors firstIdentify the business processes and the actor roles in each processIdentify the external events to which the system must respond and relate these events to actors and use casesExpress business processes in terms of specific scenarios, generalize the scenarios into use casesDerive likely use cases from existing functional requirements3.3 用例與功能需求Use casescan not replace functional requirements, they are different view of the product, one is from user, the other is