工大軟工本科課件需求獲取

1、計算機科學(xué)與技術(shù)學(xué)院軟件工程軟件工程第五章需求獲取喬立民qlm2011年4月20日1第5章 需求獲取本章內(nèi)容§ 5.1 需求獲取的§ 5.2 需求獲取的途徑§ 5.3 需求獲取技術(shù)§ 5.4 需求獲取管理2第5章需求獲取需求工程的總體流程活動需求開發(fā)產(chǎn)出物3第5章 需求獲取需求規(guī)格說明書分析模型會議紀(jì)要討論紀(jì)要審核通過的規(guī)格說明書需求管理需求獲取需求驗證規(guī)格說明需求分析需求獲取的基本步驟業(yè)務(wù)需求CxO部門經(jīng)理交流需求紀(jì)要問題？客戶分類(按)分類整理優(yōu)先級排序消解簽字確認(rèn)第5章 需求獲取標(biāo)目統(tǒng)系求需能功求需能功非則規(guī)務(wù)業(yè)求需口接部外案方?jīng)Q解議建業(yè)務(wù)員用戶需

2、求管理員4了解領(lǐng)域背景知識需求獲取的基本步驟第1步：了解相關(guān)背景和領(lǐng)域/行業(yè)的知識，確定類；所期望的用戶第2步：與客戶企業(yè)或組織的進(jìn)行交流，了解實際用戶任務(wù)和目標(biāo)以及這些任務(wù)所支持的業(yè)務(wù)需求；第3步：與客戶企業(yè)或組織的底層細(xì)的用戶需求；第4步：整理需求紀(jì)要，發(fā)現(xiàn)新問題，并重復(fù)1-3步；第5步：需求分類和組織，形成系統(tǒng)需求，區(qū)別功能需求、非功能需求、約束條件、業(yè)務(wù)規(guī)則、外部接口需求、建議解決方法和附加信息；進(jìn)行交流，獲取每個用戶類的詳?shù)?步：優(yōu)先排序和解決；第7步：整理出需求規(guī)格說明，并與客戶協(xié)商確認(rèn)。5第5章 需求獲取“看似簡單，實際卻很難” “需求獲?。坎痪褪菃枂栴}嗎？這有什么難的？ ”6第

3、5章 需求獲取案例分析1“他們忙，沒有時間與你討論需求”“銀彈”公司的CEO 王神話約見軟件開發(fā)小組李敏捷，商討為公司開發(fā)新系統(tǒng)的事情我們的“銀彈”經(jīng)常出故障，客戶總抱怨我們的質(zhì)量！我們需要建立一套化學(xué)制品跟蹤信息系統(tǒng)，可以內(nèi)開發(fā)出該系統(tǒng)嗎？并化學(xué)藥品的使用情況小組能在五王神話我已經(jīng)明白這個項目的重要性了，但在我制定計劃前，我們必須收集一些系統(tǒng)的 需求。李敏捷你什么意思？我不是剛告訴你需求了嗎？王神話你只說明了整個項目的概念與目標(biāo)，這些次的業(yè)務(wù)需求并不能為我們提供足夠的詳細(xì)信息以確定究竟要開發(fā)什么樣的軟件，以及需要多長時間。我需要一些李敏捷分析與一些知道系統(tǒng)使用要求的化學(xué)進(jìn)行討論，然后才能真正

4、明白達(dá)到業(yè)務(wù)目標(biāo)所需的各種功能和用戶的要求。那些化學(xué)都非常忙，沒有時間與詳細(xì)討論各種細(xì)節(jié)，你不能讓你的手下王神話的人說明要做的系統(tǒng)嗎？如果我們只是憑空猜想用戶要求，結(jié)果令人滿意。李敏捷行了，行了，我們沒有那么多時間，我來告訴你需求，請馬上開始開發(fā)系統(tǒng)，并王神話隨時將的進(jìn)展情況告訴我。7第5章 需求獲取(1) “Yes, But”綜合癥當(dāng)你把新開發(fā)的系統(tǒng)展示給用戶時 “Wow，太酷了！這正是我們想要的，你做了一個了不起的系統(tǒng)！”后 “Yes, but, 嗯.這個模塊是怎么回事？如果你把它修改成這樣豈不是會變得更好？ 如果那樣的話，我覺得我會更喜歡它”8第5章 需求獲取(1) “Yes, But”

5、綜合癥“Yes, But”是軟件開發(fā)中最經(jīng)常遇到的問題，這種反應(yīng)實際上是人的一種自然反應(yīng)。不管之前他多么認(rèn)同你的設(shè)計，在沒有看到真正的系統(tǒng)之前，用戶決不可能完全理解你的設(shè)計；軟件本質(zhì)上的“無形性”造成的必然結(jié)果機械設(shè)計里的每一步都是看的見摸得到的，用戶從最開始就能與設(shè)計步理解，所以不存在“Yes, But”問題同在軟件設(shè)計里，需求獲取階段的一個重要目標(biāo)就是如何盡早的把“But”后面的部分發(fā)現(xiàn)出來9第5章 需求獲取(2) “Undiscovered Ruins”綜合癥“我們已經(jīng)發(fā)現(xiàn)了所有的需求，現(xiàn)在讓我們開始著手開發(fā)吧”“知道的越多，不知道的也越多”“Undiscovered Ruins”：請問

6、尚未被發(fā)現(xiàn)的廢墟有多少呢？需求是永無止境的10第5章 需求獲取(3) “User and Developer”綜合癥中國貓：喵喵喵貓：涅呀涅呀軟件開發(fā)中，開發(fā)目標(biāo)不同，雙方在與用戶處于不同的知識、技術(shù)層面，所關(guān)注的 時必然存在communication gap(交流的鴻溝)。11第5章 需求獲取(3) “User and Developer”綜合癥“理解用戶需求”這一目標(biāo)驅(qū)使軟件開發(fā)轉(zhuǎn)入到現(xiàn)實中的世界；從他們所沉溺的“01”世界巨大的鴻溝(gap)導(dǎo)致開發(fā)與用戶之間無法充分的相互理解；為了在兩個截然不同的世界之間架起一座橋梁，有必要學(xué)習(xí)一些技術(shù)以便于有效的獲取和理解客戶需求。12第5章 需求獲

7、取小結(jié)13第5章 需求獲取問題解決方案“Yes, But”綜合癥：直到開發(fā)將用戶描述的東西交給他們，用戶才認(rèn)為他們知道要什么盡早提供可選擇的啟發(fā)技術(shù)：應(yīng)用用例、扮演、開發(fā)原型等方法“Undiscovered Ruins”綜合癥：用戶不知道 需要什么，或知道但不知如何表達(dá)將用戶當(dāng)作領(lǐng)域來認(rèn)識和激勵， 嘗試其他交流和啟發(fā)技術(shù)“User and Developer”綜合癥：分析員認(rèn)為比用戶更了解用戶的需求把分析員放在用戶的位置上，試著角色扮演一小時或一天本章內(nèi)容§ 5.1 需求獲取的§ 5.2 需求獲取的途徑§ 5.3 需求獲取技術(shù)§ 5.4 需求獲取管理14

8、第5章需求獲取需求獲取途徑§ 需求獲取的關(guān)鍵：和交流§ 所要避免的問題： 交流、不全、意見§ 所要必備的條件： 較高的技術(shù)水平、豐富的實踐經(jīng)驗、較強的人際交往能力§ 可能采取的 用戶訪談、現(xiàn)場：咨詢、會議討論、15第5章 需求獲取需求獲取途徑§ 面對面訪談(face-to-face interviewing)§ 專題討論會(workshop)§ 現(xiàn)場觀察(observing on the scene)§ 頭腦風(fēng)暴(brainstorming)§ 重點注意業(yè)務(wù)單據(jù)等資料的收集、整理！-分析的依據(jù)§

9、 多種方法要復(fù)合在一起使用，效果更好16第5章 需求獲取面對面訪談需求獲取中最直接的方法：用戶面談(interviewing)“看起來很美”，但“做起來并不容易”需求分析者個人的偏見、事先的理解、以往的經(jīng)驗積累是導(dǎo)致面談失敗的最重要在面談時，忘掉一切以往所作的事情，通過問題啟發(fā)，陳述對方的不要把放在“”的位置上17第5章 需求獲取如何提問？“每個人都能提問題，但并不等于人人都會提問題”封閉式問題： 對錯或多項選擇題，回答只需要一兩個詞開放式問題： 這種問題需要解釋和說明，同時向?qū)Ψ奖硎灸銓λ麄冋f的話很感，還想了解的內(nèi)容。通過提問題增強你對談話進(jìn)展和方向的問題不能過于寬泛最開始的問題不能太難不能

10、在提問之前就已經(jīng)表示不贊同 談話之前有意識的準(zhǔn)備一些備用問題18第5章 需求獲取訪談問題的分類§ 上下文無關(guān)的問題(context-free questions)：充分理解用戶的問題，不涉及具體的解決方案 客戶是誰？ 最終用戶是誰？ 不同用戶的需求是否不同？ 這種需求目前的解決方案是什么？§ 解決方案相關(guān)的問題(solution-context questions)：通過這類問題，探尋特定的解決方案并得到用戶認(rèn)可 你希望如何解決這個問題？ 你覺得該問題這樣解決如何？19第5章 需求獲取面談之前§ 確立面談目的§ 確定要包括的相關(guān)用戶§ 確定參加

11、會議的項目小組成員§ 建立要討論的問題和要點列表§ 復(fù)查有關(guān)文檔和資料§ 確立時間和地點§ 通知所有參加者有關(guān)會議的目的、時間和地點20第5章 需求獲取面談之中§ Step 1：事先準(zhǔn)備一系列上下文無關(guān)的問題，并將其下來以便面談時參考；§ Step 2：面談前，了解一下要面談的客戶公司的背景資料，不要選擇能回答的問題而浪費時間；§ Step 3：面談過程中，參考事先準(zhǔn)備的面談模板，以保證提出的問題是正確的。將錄下未回答條目和未解決問題；§ Step 4：面談之后，分析總結(jié)面談到紙面上，并指出和記。21第5章 需求獲

12、取面談之后§ 復(fù)查筆記的準(zhǔn)確性、完整性和可理解性§ 把所收集的信息轉(zhuǎn)化為適當(dāng)?shù)哪Ｐ秃臀臋n§ 確定需要進(jìn)一步澄清的問題域§ 向參加會議的每一個人發(fā)出此次面談的minutes(會議紀(jì)要)22第5章 需求獲取面對面訪談的優(yōu)缺點分析§ 優(yōu)點： 人們很愿意談?wù)撜?；的工作，并且總是很喜歡接受訪§ 缺點： 大多數(shù)人都采用專業(yè)術(shù)語和“行話”，而太多的專業(yè)術(shù)語讓需求工程師難以理解，往往造成很多誤解； 有些需求對用戶來說太普通了，以至于他們不自覺地認(rèn)為這些需求太基本，不值得去提。但它們對需求工程師來說卻不是顯而易見的。這往往會造成某些需求被忽略；23第5

13、章 需求獲取本章內(nèi)容§ 5.1 需求獲取的§ 5.2 需求獲取的途徑§ 5.3 需求獲取技術(shù) 5.3.1 業(yè)務(wù)調(diào)研 5.3.2 基于用例的需求獲取§ 5.4 需求獲取管理24第5章 需求獲取業(yè)務(wù)調(diào)研§ 調(diào)研準(zhǔn)備 了解背景、領(lǐng)域知識 確定調(diào)研組織、對象 準(zhǔn)備調(diào)研提綱，制定調(diào)研計劃 設(shè)計調(diào)研問卷§ 調(diào)研過程 訪談、 填寫問卷 整理調(diào)研材料（思考，回訪）§ 撰寫調(diào)研報告§ 確認(rèn)調(diào)研結(jié)果第5章25需求獲取業(yè)務(wù)調(diào)研案例§ 河南同力水泥 調(diào)研問卷 調(diào)研計劃 調(diào)研資料 調(diào)研報告信息系統(tǒng)工程26第5章 需求獲取本章內(nèi)容&

14、#167; 5.1 需求獲取的§ 5.2 需求獲取的途徑§ 5.3 需求獲取技術(shù) 5.3.1 業(yè)務(wù)調(diào)研 5.3.2 基于用例的需求獲取§ 5.4 需求獲取管理27第5章 需求獲取領(lǐng) 域 模 型S a leS a les1. .*1. . .基于用例的需求獲取業(yè)務(wù)建模Lin e I t e md a t e. . . . .quantity對 象 、屬 性 、關(guān) 聯(lián)范 圍 、目 標(biāo) 、參與者、特 性設(shè) 想用 例 模 型用 例名 稱術(shù) 語 、屬 性 、驗 證詞 匯 表需 求用 例 圖用 例 文 本系統(tǒng)操 作 :en t erIt em ()m a ke補 充 性規(guī) 格

15、 說 明system operationsN ew Sale ( )P o st-conditions:- . . .e n te r Ite m (i d , q u a n tity)非功能性需求、質(zhì)量屬性操 作 契 約系 統(tǒng) 順 序 圖requirements設(shè) 計 模 型en t erIt em (it em ID , quantity)設(shè) 計spec = getProductSpec( item ID )ad d Lin eItem ( sp e c , quantity )28第5章 需求獲取基本概念參與者(actor)：是某些具有行為的事物，可以是人（由計算機系統(tǒng)或者組織，例如

16、收銀員標(biāo)識）、場景(scenario)：是參與者和系統(tǒng)之間的一系列特定的活動交互，也稱為用例實例(use case instance)用例(use case)：就是一組相關(guān)的與者如何使用系統(tǒng)來實現(xiàn)其目標(biāo)和失敗場景集合，參§ 用例是文本文檔，而非圖形；§ 用例建模主要是編寫文本的活動，而非制圖。29第5章 需求獲取用例的特征§ 用例：站在用戶角度定義軟件系統(tǒng)的外部特征§ 四大特征：行為序列(sequences of actions)：一個用例由一組可產(chǎn)生某些特定，這些行為是不可再分解的(接收用戶輸入、執(zhí)行、結(jié)果的行為產(chǎn)生結(jié)果)系統(tǒng)執(zhí)行(system per

17、forms)：系統(tǒng)為外部提供服務(wù)；可觀測到的、有價值的結(jié)果(observable result of value)：用例必須對用戶產(chǎn)生價值；(particular actor)：特定的、某臺設(shè)備、某外部系統(tǒng)、等等，能夠觸發(fā)某些行為。Use case30第5章 需求獲取用例方法的基本思想用例方法的基本思想：從用戶的角度來看，他們并不想了解系統(tǒng)的內(nèi)部結(jié)構(gòu)和設(shè)計，他們所關(guān)心的是系統(tǒng)所能提供的服務(wù)，也就是被開發(fā)出來的系統(tǒng)將是如何被使用的。用例模型主要由以下模型元素：參與者(Actor) ：存在于被定義系統(tǒng)外部并與該系統(tǒng)發(fā)生交互的人或其他系統(tǒng)，代表系統(tǒng)的使用者或使用環(huán)境。用例(Use Case)通訊關(guān)聯(lián)

18、(Communication Association) ：用于表示參與者和用例之間的對應(yīng)關(guān)系，它表示參與者使用了系統(tǒng)中的哪些服務(wù)(用例)、系統(tǒng)所提供的服務(wù) (用例)是被哪些參與者所使用的。通訊關(guān)聯(lián)參與者用例31第5章 需求獲取示例：ATM系統(tǒng)的用例參與者：用例：客戶客戶使用自動提款機來進(jìn)行帳戶的、取款和轉(zhuǎn)帳取款客戶轉(zhuǎn)帳32第5章 需求獲取關(guān)于“通訊關(guān)聯(lián)”的幾點說明通訊關(guān)聯(lián)表示的是參與者和用例之間的關(guān)系：箭頭表示在這一關(guān)系中哪一方是動接受者；的主動發(fā)起者，箭頭所指方是的被如果不想強調(diào)中的主動與關(guān)系，可以使用不帶箭頭的關(guān)聯(lián)實線。通訊關(guān)聯(lián)不表示在參與者和用例之間的信息流，并且信息流向是雙向的，它與通

19、訊關(guān)聯(lián)箭頭所指的方向沒有關(guān)系。通訊關(guān)聯(lián)參與者用例33第5章 需求獲取用例的內(nèi)部剖析§ 用例= 橢圓 + 名字？ NO！§ 用例=文本！用例名：參與者及關(guān)注點：Use case主場景：12擴(kuò)展前置條件： 后置條件：34第5章需求獲取如何發(fā)現(xiàn)用例§ Step 1：確定系統(tǒng)邊界§ Step 2：識別并描述參與者(actor)；§ Step 3：確定每個參與者目標(biāo)，識別用例(use case) ；§ Step 4：識別參與者與用例之間的通訊關(guān)聯(lián)(Association)；§ Step 5：給出每一個用例的詳細(xì)描述§ Ste

20、p 6：細(xì)化用例模型35第5章 需求獲取Step 1：確定系統(tǒng)邊界§ 系統(tǒng)目標(biāo)§ 系統(tǒng)范圍36第5章需求獲取Step 2：識別并描述參與者§ 通過以下問題來識別Actor： 誰使用這個系統(tǒng)的功能？ 誰從該系統(tǒng)獲得信息？ 誰向該系統(tǒng)提供信息？參與者 該系統(tǒng)需要(讀寫)那些外部硬件設(shè)備？負(fù)責(zé)維護(hù)和管理這個系統(tǒng)以保證其正常運行？ 該系統(tǒng)需要與其他系統(tǒng)進(jìn)行交互嗎？37第5章 需求獲取識別并描述參與者例1：對一個館管理系統(tǒng)來說，有哪些參與者？普通讀者管理員系統(tǒng)管理員普通讀者管理員系統(tǒng)管理員例2：對ATM系統(tǒng)來說，有哪些參與者？客戶ATM維護(hù)服務(wù)器客戶維護(hù)服務(wù)器38第5章 需

21、求獲取特殊的參與者：系統(tǒng)時鐘有時候需要在系統(tǒng)內(nèi)部定時的執(zhí)行一些操作，如檢測系統(tǒng)況、定期生成統(tǒng)計報表等等；但這些操作并不是由外部的人或系統(tǒng)觸發(fā)的；使用情對于這種情況，可以抽象出一個系統(tǒng)時鐘或定時器參與者，利用該參與者來觸發(fā)這一類定時操作；從邏輯上，這一參與者應(yīng)該被理解成是系統(tǒng)外部的，由它來觸發(fā)系統(tǒng)所提供的用例。觸發(fā)系統(tǒng)時鐘周期性任務(wù)39第5章 需求獲取Step 3：識別用例(use case)§ 找到參與者之后，據(jù)此來確定系統(tǒng)的用例，主要是看各參與者需要系統(tǒng)提供什么樣的服務(wù)，或者說參與者是如何使用系統(tǒng)的。§ 尋找用例可以從以下問題入手(每一個參與者)： 參與者使用該系統(tǒng)執(zhí)行什

22、么任務(wù)？ 參與者是否會在系統(tǒng)中創(chuàng)建、修改、刪除、數(shù)據(jù)？如果是的話，參與者又是如何來完成這些操作的？ 參與者是否會將外部的某些 系統(tǒng)是否會將內(nèi)部的某些通知給該系統(tǒng)？通知該參與者？Use case40第5章 需求獲取識別用例（目標(biāo)識別）例1：對館管理系統(tǒng)來說，有哪些用例？ 普通讀者：管理員管理讀者信息預(yù)訂取消預(yù)訂瀏覽管理信息信息登記借書登記還書例2：對ATM系統(tǒng)來說，有哪些參與者？客戶 ATM維護(hù)維護(hù)系統(tǒng)服務(wù)器周期性操作取款轉(zhuǎn)裝41第5章 需求獲取識別用例的幾點注意事項§ 用例必須是由某一個actor觸發(fā)而產(chǎn)生的活動，即每個用例至少應(yīng)該涉及一個actor。§ 如果存在與acto

23、r不進(jìn)行交互的用例，需要將其并入其他用例，或者是檢查該用例相對應(yīng)的參與者是否被遺漏。§ 反之，每個參與者也必須至少涉及到一個用例，如果發(fā)現(xiàn)有不與任何用例相關(guān)聯(lián)的參與者存在： 仔細(xì)考慮該參與者是如何與系統(tǒng)發(fā)生 由參與者確定一個新的用例； 該參與者是一個多余的模型元素，應(yīng)該將其刪除。的；42第5章 需求獲取發(fā)現(xiàn)有用的用例§ 下面那個是有效用例？ 就供應(yīng)者合同進(jìn)行協(xié)商 處理退貨 登錄 將商品進(jìn)行條碼掃描測試§ 基本業(yè)務(wù)過程測試 基本業(yè)務(wù)過程：一個人于某個時刻在一個地點所執(zhí)行的任務(wù)，用以響應(yīng)業(yè)務(wù)。該任務(wù)能夠增加可量化的業(yè)務(wù)價值，并且以持久狀態(tài)留下數(shù)據(jù)。§ 規(guī)模測

24、試用例由一系列相關(guān)聯(lián)的步驟組成，不能是單獨的活動！第5章 需求獲取43Step 4：識別參與者與用例之間的通訊關(guān)聯(lián)ATM系統(tǒng)客戶服務(wù)器操作員維護(hù)系統(tǒng)系統(tǒng)時鐘周期性任務(wù)4借閱管理讀者普通讀者預(yù)訂管理信息取消預(yù)訂登記借書登記還書45用例圖示例通信N extGen POS系 統(tǒng) 邊 界處 理 銷 售計 算 機 系 統(tǒng)參 與 者 的 可選 表 示 法顧 客支付服務(wù)處 理 退 貨參 與 者收 銀 員收 款經(jīng) 理分 析 活 動管 理 安 全 性管 理 用 戶系 統(tǒng) 管 理 員用 例. . .第5章 需求獲取46Step 5：給出用例的詳細(xì)描述單純的用例圖并不能描述完整的信息，需要用文字描述不能反映在圖形上

25、的信息。用例名：參與者及關(guān)注點：主場景：12擴(kuò)展前置條件： 后置條件：47求獲取流§ 用例的流： 說明用例如何啟動，即哪些參與者在何種情況下啟動用例？ 說明參與者與用例之間的信息處理過程； 說明用例在不同條件下可以選擇執(zhí)行的多種方案； 說明用例在什么情況下才能被視作完成；§ 分為常規(guī)流和擴(kuò)展流兩類： 常規(guī)流：描述該用例最正常的一種場景，系統(tǒng)執(zhí)行一系列活動步驟來響應(yīng)參與者提出的服務(wù)請求； 擴(kuò)展流：負(fù)責(zé)描述用例執(zhí)行過程中異常的或偶爾發(fā)生的一些情況。48第5章 需求獲取常規(guī)流每一個步驟都需要用數(shù)字編號以清楚地標(biāo)先后順序用一句簡短的標(biāo)題來概括每一步驟的主要內(nèi)容對每一步驟，從正反兩個

26、方面來描述驟的Step 1Step 2參與者向系統(tǒng)提交了什么信息對此系統(tǒng)有什么樣的響應(yīng)Step 3Step 3aStep 3bStep 4Step 3cStep 549第5章需求獲取擴(kuò)展流擴(kuò)展流的描述格式可以與基本流的格式一致，也需要編號并以標(biāo)題概述其內(nèi)容。Step 1起點：該擴(kuò)展流從流的哪一步開始；條件：在什么條件下會觸發(fā)該擴(kuò)展流；動作：系統(tǒng)在該擴(kuò)展流下會采取哪些動作；恢復(fù)：該擴(kuò)展流結(jié)束之后，該用例應(yīng)如何繼續(xù)執(zhí)行。Step 2Step 3Step 3aStep 3bStep 4Step 3cStep 550第5章 需求獲取編寫用例文本的準(zhǔn)則§ 以無用戶界面約束的本質(zhì)風(fēng)格編寫用例&#

27、167; 編寫簡潔的用例§ 編寫黑盒用例§ 采用參與者和參與者目標(biāo)的視角51第5章 需求獲取案例用例描述152第5章 需求獲取案例用例描述2用例名稱：處理銷售參與者與關(guān)注點：收銀員：希望準(zhǔn)確、快速地輸入，而且沒有支付錯誤，因為如果少收貨款，將從其工資中扣除。 前置條件：收銀員必須經(jīng)過確認(rèn)和認(rèn)證保證（或后置條件）：銷售信息。準(zhǔn)確計算稅金。更新賬務(wù)和庫存信息。主場景（或基本流程）：1. 顧客攜帶所購商品或服務(wù)到收銀臺通過POS機付款。2. 收銀員開始一次新的銷售。3. 收銀員輸入商品條碼擴(kuò)展（或替代流程）：3a.無效商品ID（在系統(tǒng)中未發(fā)現(xiàn)）： 系統(tǒng)提示錯誤并拒絕輸入該ID。收

28、銀員響應(yīng)該錯誤特殊需求：使用大平面顯示器觸摸屏，文本信息可見距離為1米。發(fā)生頻率：可能會不斷地發(fā)生未解決問題：提成處理規(guī)則不確定收銀員時如何處理 Step 6：細(xì)化用例模型1.在一般的用例圖中，只需表述參與者和用例之間的通訊關(guān)聯(lián)，除此之外，還可以描述：參與者與參與者之間的泛化(generalization) 用例和用例之間的包含(include)用例和用例之間的擴(kuò)展(extend)用例和用例之間的泛化(generalization)關(guān)系根據(jù)用例描述繪制活動圖補充非功能性需求2.3.54第5章 需求獲取參與者之間的關(guān)系actor 1參與者之間可以有泛化(Generalization)關(guān)系。act

29、or 2用例之間的關(guān)系：包含(include)“包含關(guān)系”是通過在關(guān)聯(lián)關(guān)系上加入<<include>>標(biāo)記來表示；語義：用例1會用到用例2，用例2的流中一般表示為公共功能流將入到用例1的<<include>>用例1用例2<<include>><<include>>取款客戶打印回執(zhí)<<include>>轉(zhuǎn)帳用例之間的關(guān)系：擴(kuò)展(extend)“擴(kuò)展關(guān)系”是通過在關(guān)聯(lián)關(guān)語義：用例2在某些特定情況入到用例2的一般表示為異常功能流中。客戶打<<extend>>

30、<<extend>>呼叫等待呼叫轉(zhuǎn)移用例之間的關(guān)系：擴(kuò)展(extend)58第5章 需求獲取<<extend>>打<<extend>>呼叫等待呼叫轉(zhuǎn)移常規(guī)流：擴(kuò)展流：1 撥號1a 如果應(yīng)答方正忙，用鈴聲提2 建立通話鏈路示應(yīng)答方并保持撥號呼叫擴(kuò)展流：1b 如果應(yīng)答方無應(yīng)答，進(jìn)行呼叫轉(zhuǎn)移3 通話實際上相當(dāng)于第一個用例的“擴(kuò)展流”4用例之間的關(guān)系：泛化(generalization)第5章 需求獲取§ 當(dāng)多個用例共同抽象成為父用例§ 子用例繼承了父用例1采購員采購物料采購鋼材采購辦公用品用例259“用例的關(guān)

31、系”§ 參與者與參與者之間的泛化(generalization)§ 用例和用例之間的包含(include)§ 用例和用例之間的擴(kuò)展(extend)§ 用例和用例之間的泛化(generalization)關(guān)系§ 為什么要引入上述關(guān)系？有什么優(yōu)越性？60第5章 需求獲取活動圖§ 顯示了組成復(fù)雜過程的步驟序列，例如算法或工作流§ 活動圖用于詳細(xì)描述用例初始終止并發(fā)分叉并發(fā)合并61第5章 需求獲取Activity3Activity1活動圖描述62第5章求獲取泳道圖63第5章 需求獲取標(biāo)識非功能性需求（URPS+）§ 可用性

32、§ 可靠性§ 性能§ 可支持性§ 實現(xiàn)§ 接口（參見示例）64第5章 需求獲取本章內(nèi)容§ 5.1 需求獲取的§ 5.2 需求獲取的途徑§ 5.3 需求獲取技術(shù)§ 5.4 需求獲取管理 5.4.1 需求規(guī)格說明 5.4.2 需求驗證 5.4.3 需求變更65第5章 需求獲取需求工程的總體流程活動需求開發(fā)產(chǎn)出物66第5章 需求獲取需求管理需求獲取需求驗證與客戶協(xié)商規(guī)格說明-應(yīng)用設(shè)計(Joint Application Design, JAD)通過讓所有相關(guān)一起參加某個單一會議來定義需求或設(shè)計系統(tǒng)。系統(tǒng)相關(guān)者在

33、短暫而緊湊的時間段內(nèi)集中在一起，一般為1至2天，與會者可以在應(yīng)用需求上達(dá)成共識、對操作過程盡快取得統(tǒng)一意見。協(xié)助建立一支高效團(tuán)隊，一個目的：項目的；所有都暢所欲言；促進(jìn)用戶與開發(fā)團(tuán)隊之間達(dá)成共識；能夠和解決那些妨礙項目的行政問題；最終很快產(chǎn)生初步的系統(tǒng)定義。67第5章需求獲取需求規(guī)格說明書(SRS)§ 軟件需求規(guī)格說明書SRS (Software Requirements Specification)： 需求開發(fā)的結(jié)果，精確的闡述一個軟件系統(tǒng)必須提供的功能和性能，以及它所要考慮的限制條件。 為了使用戶和軟件開發(fā)者雙方對該軟件的初始規(guī)定有一個共同的理解，使之成為整個開發(fā)工作的基礎(chǔ)。68

34、第5章 需求獲取需求規(guī)格說明書(SRS)§ SRS作為軟件開發(fā)各類之間進(jìn)行理解和交流的： 用戶：通過SRS指定需求，檢查需求描述是否滿足期望； 設(shè)計發(fā)點； 測試：了解軟件需要開發(fā)的內(nèi)容，將其作為軟件設(shè)計的基本出：指定測試計劃、測試用例和測試過程；：編寫用戶手冊和幫助信息；發(fā)布 項目管理：軟件開發(fā)過程、準(zhǔn)確估計開發(fā)進(jìn)度和成本、控制需求變更過程。69第5章 需求獲取SRS應(yīng)包含的內(nèi)容§ 功能(Functionality)： 該軟件系統(tǒng)能夠向用戶提供何種服務(wù)？§ 非功能屬性(Non-Functional Attributes)： 可用性 可靠性 性能 可支持性 實現(xiàn) 接

35、口 70第5章 需求獲取SRS不應(yīng)包含的內(nèi)容§ 項目開發(fā)計劃 諸如成本、進(jìn)度、工具、方法等保證計劃 諸如配置管理、驗證與測試、質(zhì)量保證等§ 軟件設(shè)計細(xì)節(jié) 需求通常用于表達(dá)“做什么”，而不描述“如何做”71第5章 需求獲取功能性描述§ 例1 如果可能的話，應(yīng)當(dāng)根據(jù)編號的列表確認(rèn)所輸入的編號。§ 修改之后： 系統(tǒng)必須根據(jù)的編號列表確認(rèn)所輸入的的編號，或者當(dāng)進(jìn)行編號。如果在編號確認(rèn)時編號列表中查不到該編號列表不可，系統(tǒng)必須顯示一個出錯信息并且拒絕預(yù)訂。72第5章 需求獲取非功能性描述§ 例2必須在固定的時間間隔內(nèi)提供狀態(tài)信息，并且每次時間間隔不得小于

36、60 秒。§ 修改之后：任務(wù)管理器應(yīng)該在用戶界面的指定區(qū)域顯示狀態(tài)信息。任務(wù)進(jìn)程啟動之后，消息必須每隔60±10 秒更新一次，并且保持連1. 在續(xù)的可見性。2. 如果正在正常處理進(jìn)程已完成的百分比。任務(wù)進(jìn)程，那么任務(wù)管理器必須顯示任務(wù)3. 當(dāng)完成4. 如果任務(wù)管理器必須顯示一個“已完成”的信息。任務(wù)時，任務(wù)中止執(zhí)行，那么任務(wù)管理器必須顯示一個出錯信息。73第5章 需求獲取編寫需求規(guī)格說明的原則§ 原則1：只描述“做什么”而無須描述“怎么做”§ 原則2：必須說明運行環(huán)境§ 原則3：考慮用戶、分析員和實現(xiàn)者的交流 對形式化和自然語言之間作出恰當(dāng)?shù)倪x

37、擇 明確的理解最重要，不存在十全十美的軟件規(guī)格說明書§ 原則4：力求尋找到恰如其分的需求詳細(xì)程度 一個有益的原則就是編寫單個的可測試需求文檔 建議將可測試的需求作為衡量軟件規(guī)模大小的尺度74第5章 需求獲取編寫需求規(guī)格說明的原則§ 原則5：文檔段落不宜太長 簡短 記住：不要在需求說明中使用“和/或”、“等等”之類的詞§ 原則6：避免使用模糊的、的術(shù)語 如用戶友好、容易、簡單、迅速、有效、許多、最新技術(shù)、優(yōu)越的、可接受的、最大化、最小化、提高等 不可驗證§ 建議：采用一種標(biāo)準(zhǔn)的SRS 模板75第5章 需求獲取SRS的三大部分：“1. 引言”1.引言1.1

38、系統(tǒng)目標(biāo)1.2 系統(tǒng)范圍1.3 術(shù)語表1.4 參考資料1.5 總結(jié)現(xiàn)狀描述 建議的系統(tǒng)2.3.76第5章 需求獲取SRS的三大部分：“2. 現(xiàn)狀描述”1.2.引言現(xiàn)狀描述如開發(fā)的是支持業(yè)務(wù)系統(tǒng)軟件（如銷售業(yè)務(wù)），詳細(xì)描述業(yè)務(wù)現(xiàn)狀。如業(yè)務(wù)概況、與業(yè)務(wù)相關(guān)的組織機構(gòu)設(shè)置、職責(zé)、與其他相關(guān)業(yè)務(wù)等。如開發(fā)的是支持系統(tǒng)的軟件（多為軟件），描述市場上與之相關(guān)的功能，并分析其特點3.建議的系統(tǒng)77第5章 需求獲取SRS的三大部分：“3. 建議的系統(tǒng)”1.2.3.引言現(xiàn)狀描述建議的系統(tǒng)3.1 概述3.23.33.4功能性需求非功能性需求系統(tǒng)模型3.4.1 用例模型3.4.2 對象模型3.4.3 動態(tài)模型3.4

39、.4 用戶接口78第5章 需求獲取本章內(nèi)容§ 5.1 需求獲取的§ 5.2 需求獲取的途徑§ 5.3 需求獲取技術(shù)§ 5.4 需求獲取管理 5.4.1 需求規(guī)格說明 5.4.2 需求驗證 5.4.3 需求變更79第5章 需求獲取需求驗證活動需求開發(fā)產(chǎn)出物80第5章 需求獲取需求管理需求獲取需求驗證需求驗證§ 需求驗證：通過確定以下幾方面的內(nèi)容來檢驗需求能否滿足客戶的意愿 軟件需求規(guī)格說明正確描述了預(yù)期的系統(tǒng)行為和特征 從系統(tǒng)需求或其它來源中得到軟件需求 需求是完整的和高質(zhì)量的 所有對需求的看法是一致的 需求為繼續(xù)進(jìn)行設(shè)計、構(gòu)造和測試提供了足夠的

40、基礎(chǔ)81第5章 需求獲取需求驗證§ 需求驗證的技術(shù) 需求評審：由不同代表(如分析員、客戶、設(shè)計的評審小組以會議形式對需求進(jìn)行系統(tǒng)性分析。)組成、測試 原型評價：客戶和用戶在一個可運行的原型系統(tǒng)上實際檢驗系統(tǒng)是否符合他們的真正需要。 測試用例生成：通過設(shè)計具體的測試方法，發(fā)現(xiàn)需求中的問題。§ 需求驗證主要SRS的質(zhì)量特性展開正確性無二義性完整性 一致性按重要度排序可驗證性可修改性可跟蹤性82第5章 需求獲取需求評審“在需求文檔或其它軟件上花費一個小時，可節(jié)省將來十個小時的工作時間?！毙枨笤u審所需的參與：編寫需求文檔的分析員未來的開發(fā)未來的測試項目經(jīng)理客戶/用戶代表83第5章需

41、求獲取需求評審的過程84第5章 需求獲取需求評審的條件§ 已經(jīng)明確闡述了§ 已經(jīng)正確修改了文檔§ 修訂過的文檔已經(jīng)進(jìn)行了拼寫檢查和語法檢查§ 所有TBD的問題已經(jīng)全部解決，或者已經(jīng)定問題的解決過程、目標(biāo)日期和提出問題的人§ 文檔已經(jīng)登記入項目的配置管理系統(tǒng)員提出的所有問題下每個待確§ 檢查是否已將過的資料送到有關(guān)收集處85第5章 需求獲取本章內(nèi)容§ 5.1 需求獲取的§ 5.2 需求獲取的途徑§ 5.3 需求獲取技術(shù)§ 5.4 需求獲取管理 5.4.1 需求規(guī)格說明 5.4.2 需求驗證 5.4

42、.3 需求變更86第5章 需求獲取需求變更§ 需求管理是分析變更影響并變更的過程，主要包括變更、版本和需求跟蹤等活動。87第5章 需求獲取需求變更管理§ “無論何時客戶對我們的分析提出變更要求，他們總是說同意，我們就只好努力去做出來?！边@是軟件設(shè)計與開發(fā)的經(jīng)常抱怨§ 不被的變更是項目陷入、不能按進(jìn)度執(zhí)行或軟件質(zhì)量低劣的共同 應(yīng)仔細(xì)評估已建議的變更 挑選合適的人選對變更做出決定 變更應(yīng)及時通知所有涉及的 項目要按一定的程序來采納需求變更88第5章 需求獲取需求變更管理§ 理想情況： 在開始構(gòu)造前應(yīng)該收集到所有新系統(tǒng)的需求，在通過需求驗證之后應(yīng)該凍結(jié)，而且在

43、開發(fā)中基本上不變更。§ 現(xiàn)實情況： 很早確定需求卻忽視了“有時候客戶并不知道需要什么”的現(xiàn)實，開發(fā)應(yīng)該對用戶這些需求變更作出響應(yīng)。§ 因此，需要采納需求變更過程來用戶需求的頻繁變化。89第5章 需求獲取需求變更§ 變更 過程并不是“拖延時間以敷衍用戶”，它是一個渠道和過濾器，通過它可以確保采納最合適的變更，使變更產(chǎn)生的 影響減少到最小。開始提交變更請求拒絕評估變更影響接受取消實施變更失敗驗證變更結(jié)果結(jié)束90私自變更造成的后果“我正在應(yīng)客戶的要求添加一個銷售分類的功能，本以為很快就可以完成，但實際上比我原先預(yù)計的工作量超期多了。”“本該通過正式我就答應(yīng)他了?！边M(jìn)行變更，但這個功能看上去較簡單，所以當(dāng)時“這個功能其實并不簡單，每次當(dāng)我認(rèn)為該完工了，但總能另一個文件中漏了一個變更，所以不得不修改它、再測試一遍。”在“原以為花4個小時就可以了，實際上花了4天時間，造成我沒能按計劃完成任務(wù)?！?1第5章 需求獲取是什么？各項需求之間存在著關(guān)聯(lián)關(guān)系，因此一個看似很小的改變可能會影響很大的范圍。在同意接受建議的變更之前，要確信弄清楚此次變更到底會影響到什么。波紋效應(yīng)Ripple effect第5獲追蹤性維護(hù)§ 需求追溯