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

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

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

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

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

5、綜合癥“Yes, But”是軟件開發(fā)中最經(jīng)常遇到的問題，這種反應實際上是人的一種自然反應。不管之前他多么認同你的設計，在沒有看到真正的系統(tǒng)之前，用戶決不可能完全理解你的設計；軟件本質上的“無形性”造成的必然結果機械設計里的每一步都是看的見摸得到的，用戶從最開始就能與設計步理解，所以不存在“Yes, But”問題同在軟件設計里，需求獲取階段的一個重要目標就是如何盡早的把“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ā)目標不同，雙方在與用戶處于不同的知識、技術層面，所關注的 時必然存在communication gap(交流的鴻溝)。11第5章 需求獲取(3) “User and Developer”綜合癥“理解用戶需求”這一目標驅使軟件開發(fā)轉入到現(xiàn)實中的世界；從他們所沉溺的“01”世界巨大的鴻溝(gap)導致開發(fā)與用戶之間無法充分的相互理解；為了在兩個截然不同的世界之間架起一座橋梁，有必要學習一些技術以便于有效的獲取和理解客戶需求。12第5章 需求獲

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

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

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

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

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

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

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

14、#167; 5.1 需求獲取的§ 5.2 需求獲取的途徑§ 5.3 需求獲取技術 5.3.1 業(yè)務調研 5.3.2 基于用例的需求獲取§ 5.4 需求獲取管理27第5章 需求獲取領 域 模 型S a leS a les1. .*1. . .基于用例的需求獲取業(yè)務建模Lin e I t e md a t e. . . . .quantity對 象 、屬 性 、關 聯(lián)范 圍 、目 標 、參與者、特 性設 想用 例 模 型用 例名 稱術 語 、屬 性 、驗 證詞 匯 表需 求用 例 圖用 例 文 本系統(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)非功能性需求、質量屬性操 作 契 約系 統(tǒng) 順 序 圖requirements設 計 模 型en t erIt em (it em ID , quantity)設 計spec = getProductSpec( item ID )ad d Lin eItem ( sp e c , quantity )28第5章 需求獲取基本概念參與者(actor)：是某些具有行為的事物，可以是人（由計算機系統(tǒng)或者組織，例如

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

38、系統(tǒng)目標1.2 系統(tǒng)范圍1.3 術語表1.4 參考資料1.5 總結現(xiàn)狀描述 建議的系統(tǒng)2.3.76第5章 需求獲取SRS的三大部分：“2. 現(xiàn)狀描述”1.2.引言現(xiàn)狀描述如開發(fā)的是支持業(yè)務系統(tǒng)軟件（如銷售業(yè)務），詳細描述業(yè)務現(xiàn)狀。如業(yè)務概況、與業(yè)務相關的組織機構設置、職責、與其他相關業(yè)務等。如開發(fā)的是支持系統(tǒng)的軟件（多為軟件），描述市場上與之相關的功能，并分析其特點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章 需求獲取本章內容§ 5.1 需求獲取的§ 5.2 需求獲取的途徑§ 5.3 需求獲取技術§ 5.4 需求獲取管理 5.4.1 需求規(guī)格說明 5.4.2 需求驗證 5.4.3 需求變更79第5章 需求獲取需求驗證活動需求開發(fā)產(chǎn)出物80第5章 需求獲取需求管理需求獲取需求驗證需求驗證§ 需求驗證：通過確定以下幾方面的內容來檢驗需求能否滿足客戶的意愿 軟件需求規(guī)格說明正確描述了預期的系統(tǒng)行為和特征 從系統(tǒng)需求或其它來源中得到軟件需求 需求是完整的和高質量的 所有對需求的看法是一致的 需求為繼續(xù)進行設計、構造和測試提供了足夠的

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

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

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

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