軟件需求工程09-3

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

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

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

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

5、域的描述要求解決的問(wèn)題列表(需求)用戶(hù)對(duì)解系統(tǒng)的行為或結(jié)構(gòu)施加的任何約束2. 信息來(lái)源高層系統(tǒng)需求 System Requirements客戶(hù)(實(shí)際的和潛在的) Customers客戶(hù)的“規(guī)格說(shuō)明書(shū) CRS原有解系統(tǒng)(即運(yùn)行在問(wèn)題域中，執(zhí)行與預(yù)期的新的解系統(tǒng)相似功能的系統(tǒng))及其文檔原有系統(tǒng)的用戶(hù)競(jìng)爭(zhēng)對(duì)手的產(chǎn)品應(yīng)用領(lǐng)域?qū)＜叶x了任何接口系統(tǒng)的特征和行為的文檔相關(guān)的技術(shù)標(biāo)準(zhǔn)和法規(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 補(bǔ)充文檔Early system concept studiesUser profiles 用戶(hù)概況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調(diào)查表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描述問(wèn)題域2確定該系統(tǒng)需求信息來(lái)源課程工程課堂分組討論要求：對(duì)工程從問(wèn)題域加以描述(關(guān)鍵點(diǎn)即可)指明已有信息和待挖掘信息并分類(lèi)對(duì)不確定的信息方案如何獲取確定信息來(lái)源可能的困難每小組選一位代表(moderator)加以陳述將結(jié)果完整記錄(記錄關(guān)鍵點(diǎn)，課后整理)小組討論20分鐘，每組陳述35分鐘3. 需求獲取技術(shù)一旦確定了可能的信息來(lái)源，接下來(lái)的工作是通過(guò)選擇適宜的獲取技術(shù)來(lái)挖掘所需的信息。3. 需求獲取技術(shù)3.1 面談 Interviewing面談是最直接的

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

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

13、時(shí)，就可使用這種技術(shù)。需求裁剪可以是手工的，也可以通過(guò)工具來(lái)完成。3. 需求獲取技術(shù)Key Points:Actually, all the technique can be combined together, 在需求獲取過(guò)程中它們并非獨(dú)立進(jìn)行的。與Stakeholders的交流(communication)與溝通(interaction)是需求獲取過(guò)程中的關(guān)鍵能力表達(dá)。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 準(zhǔn)備Environmental Scanning 環(huán)境審查Customers business 客戶(hù)的業(yè)務(wù)領(lǐng)域Customer

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

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

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

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

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

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

21、下來(lái)不要期望將來(lái)慢慢整理也要讓別人讀懂你的記錄正式地文檔化大家關(guān)注的問(wèn)題清單如何快速有效的獲取需求，并保證需求的完整性和正確性 如何更好的理解客戶(hù)的表達(dá)與客戶(hù)協(xié)商溝通 如何對(duì)不斷變化的需求做出反響對(duì)概念的理解和區(qū)別 如何實(shí)踐、如何在沒(méi)有開(kāi)發(fā)經(jīng)驗(yàn)的情況下把握好本門(mén)課程、需要儲(chǔ)藏的知識(shí) 如何準(zhǔn)確地區(qū)分業(yè)務(wù)需求、用戶(hù)需求和功能需求 客戶(hù)對(duì)系統(tǒng)開(kāi)發(fā)的理由和重要性認(rèn)識(shí)不充分監(jiān)理方提的需求過(guò)于細(xì)致?(合理? 限制? 時(shí)間?) 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:請(qǐng)注意觀察所用的方法觀察interviewer是否對(duì)所關(guān)心的主題得到足夠的信息采訪時(shí)間10分鐘Interview Skill Excise check list開(kāi)場(chǎng)使用了何種提問(wèn)方式? Closed or Open?是否滿(mǎn)足20/80 ?使用了專(zhuān)業(yè)術(shù)語(yǔ)Jargon(行話)?是否使用了primary and secondary questioning?對(duì)談話過(guò)程有控制嗎?有沒(méi)有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一個(gè)實(shí)例: 用戶(hù)可以分為:高端用戶(hù)底端用戶(hù)職業(yè)用戶(hù)每類(lèi)用戶(hù)特點(diǎn)不同，歸結(jié)到產(chǎn)品其功能也不同Communications with users用戶(hù)和開(kāi)發(fā)者之間可能通訊途徑3.2 Product Champion產(chǎn)品代表最了解客戶(hù)的需求，是客戶(hù)與開(kāi)發(fā)者之間的接口，通過(guò)產(chǎn)品代表解決溝通上的問(wèn)題。產(chǎn)品代表從所代表的用戶(hù)類(lèi)中收集需求信息，通過(guò)與需求分析人員合作解決用戶(hù)在需求表達(dá)上的不一致和不兼容性。產(chǎn)品代表必須具備較強(qiáng)的交流能力，熟知應(yīng)用領(lǐng)域，在軟件開(kāi)發(fā)方面有足夠的經(jīng)驗(yàn)，能夠判斷在現(xiàn)有技術(shù)背景和運(yùn)行環(huán)境下，開(kāi)發(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分類(lèi)活動(dòng) Check List計(jì)劃轉(zhuǎn)化產(chǎn)品的使用范圍和局限性；定義與其它系統(tǒng)的外部接口；定義現(xiàn)有用戶(hù)應(yīng)用程序

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

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

29、ard (CCB)?Senior Management Team?對(duì)客戶(hù)輸入進(jìn)行分類(lèi)客戶(hù)或用戶(hù)提供的需求信息往往是零散的、缺乏組織的。需求分析者必須把這些零散的信息按某種規(guī)那么分成不同類(lèi)型以便最終形成組織良好的需求文檔。對(duì)客戶(hù)輸入進(jìn)行分類(lèi)業(yè)務(wù)需求 Business (op) requirements描述客戶(hù)開(kāi)發(fā)部門(mén)可以從產(chǎn)品中得到的資金、市場(chǎng)和業(yè)務(wù)利潤(rùn)方面的需求信息最有可能屬于業(yè)務(wù)需求范圍。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對(duì)客戶(hù)輸入進(jìn)行分類(lèi)使用實(shí)例 Use cases or scenarios有關(guān)利用系統(tǒng)執(zhí)行的業(yè)務(wù)任務(wù)或到達(dá)用戶(hù)目標(biāo)的總的陳述可能就是使用實(shí)例，而特定的任務(wù)描述表示了用法說(shuō)明。與客戶(hù)商討，把特定的、零散的任務(wù)描述概況成廣泛的、系統(tǒng)的使用實(shí)例是系統(tǒng)分析者的重要技能，可以通過(guò)不斷地讓客戶(hù)描述他們的業(yè)務(wù)工作流程活動(dòng)來(lái)完成這一過(guò)程。對(duì)客戶(hù)輸入進(jìn)行分類(lèi)使用實(shí)例 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對(duì)客戶(hù)輸入進(jìn)行分類(lèi)業(yè)務(wù)規(guī)那么 Business rule當(dāng)客戶(hù)說(shuō)明一些活動(dòng)只能在特定條件下，由一些特定的人來(lái)完成時(shí)，客戶(hù)是在描述一個(gè)業(yè)務(wù)規(guī)那么，既業(yè)務(wù)過(guò)程的操作原那么。而業(yè)務(wù)規(guī)那么是由一系列的功能需求來(lái)完成的。Must comply with Must conform to If , then Must be calculated

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

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

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

35、驗(yàn)證設(shè)計(jì)正確性驗(yàn)證出現(xiàn)問(wèn)題工程相關(guān)知識(shí)與背景成功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