高級軟件工程陳寧江chnj@2008.101精選課件需求工程概述需求獲取需求分析和建模需求驗證與管理本章內容2精選課件什么是需求（Requirement）？需求用戶對目標軟件系統在功能、行為、性能、設計約束等方面的期望IEEE的定義（1997年）用戶解決問題或達到目標所需的條件或能力系統或系統部件要滿足合同、標準、規范或其它正式規定文檔所需具有的條件或能力反映以上兩條的文檔說明軟件需求分析的目標：調查分析，準確理解用戶的要求撰寫需求，將用戶的非形式的要求轉化為完整的、形式的規格說明3精選課件

軟件需求分析的任務4精選課件需求必須描述的基本問題功能——所設計的軟件要做什么；性能——軟件功能在執行過程中的速度、可使用性、響應時間、各種軟件功能的恢復時間、吞吐能力、精度、頻率等等；強加給實現的設計限制——在效果、實現的語言、數據庫完整性、資源限制、操作環境等等方面所要求的標準；屬性——可移植性、正確性、可維護性及安全性等方面的考慮因素；外部接口——與人、硬件、其他軟件和其它硬件的相互關系。

5精選課件需求的類型

業務需求（businessrequirement）客戶對系統的高層次的目標要求。在項目視圖與范圍文檔中予以說明用戶需求（userrequirement）用戶使用產品必須要完成的任務功能需求（functionalrequirement）開發人員必須實現的軟件功能，使得用戶能完成他們的任務，滿足業務需求非功能需求（non-functionalrequirement）對系統提供的服務或者功能提出的約束，包括時間、開發過程、軟件質量、標準等約束6精選課件一個例子從不同的角度來看，需求具有不同的層次，即業務需求、用戶需求、功能需求和非功能需求等例子：字處理程序之“拼寫檢查器”業務需求：“用戶能有效地糾正文檔中的拼寫錯誤”用戶需求：“找出文檔中的拼寫錯誤并通過一個提供的替換項列表來供選擇替換拼錯的詞”功能需求：“找到并高亮度提示錯詞的操作”；“顯示提供替換詞的對話框”；“實現整個文檔范圍的替換”非功能需求：“替換操作執行速度快”；“異常出現概率小”7精選課件

如一個小型超市需要一個商品的查詢系統。業務需求：進貨人員需要查詢商品庫存以便保證及時進貨；收款員需要查詢商品的銷售價格以便結賬；經理需要查詢商品的銷售及盈利情況。

用戶需求:這三類用戶怎樣去查詢系統，查詢哪些信息，還需要哪些操作。8精選課件功能需求對于功能性的系統需求，應需要詳細描述系統中的操作功能、輸入、輸出、異常等功能需求的描述應做到：嚴密性全面性一致性9精選課件非功能需求與軟件系統的總體特性相關，并作用于整個系統；與軟件系統的開發過程有關10精選課件非功能需求的度量11精選課件軟件需求各組成部分之間的關系

12精選課件軟件需求的作用軟件開發的基礎和前提只有在明確了軟件需求之后才能開展有針對性的軟件開發工作沒有需求無法進行設計和編碼制定軟件開發計劃的基礎只有知道你想做什么，才能知道需要多少工作量，才能制定計劃最終目標軟件系統驗收的標準只有知道你想做什么，才能知道你最終是否做好了沒有定義明確的需求，就不知道最終基于什么進行驗收13精選課件需求分析的意義

軟件需求的深入理解是軟件開發工作獲得成功的前提條件，不論我們把設計和編碼做得如何出色，不能真正滿足用戶需求的程序只會令用戶失望，給開發帶來煩惱。14精選課件需求分析的重要性：例子3153916%的項目被終止！平均超出時間122%%的項目超支，平均超支89%！%的項目按期在預算之內完成！(大公司)%的項目按期在預算之內完成！(小公司)StandishGroup‘98ChaosReport用戶參與不足！不完整的用戶需求！需求不斷變化！15精選課件需求分析的重要性：例子說明16精選課件需求分析的重要性：事實支撐（1/4）軟件生命周期中，一個錯誤發現得越晚，修復錯誤的費用越高17精選課件需求分析的重要性：事實支撐（2/4）許多錯誤是潛伏的，并且在錯誤產生后很長一段時間才被檢查出來在需求過程中會產生很多錯誤DeMarco研究報告：被檢查出來的錯誤的56％產生的根源可以追溯到需求階段。18精選課件需求分析的重要性：事實支撐（3/4）在需求階段，代表性的錯誤為疏忽、不一致和二義性美國海軍研究實驗室對海軍A-7E飛機上的飛行操作程序進行實地測試，得出的研究數據表明：A-7E項目中77％的需求錯誤特點是不明確：疏忽、不一致和二義性。按錯誤類型對這些錯誤分布進行分析的結果是：49％不正確的事實，31％疏忽，l3％不一致，5％二義性19精選課件需求分析的重要性：事實支撐（4/4）需求錯誤是可以被檢查出來的20精選課件需求分析的重要性——推論在需求過程中會產生很多錯誤許多錯誤并沒有在早期被發現這樣的錯誤是能夠在產生的初期被檢查出來的如果沒有及時檢查出來這些錯誤，軟件費用會直線上升21精選課件獲取軟件需求的復雜性系統復雜和龐大如何將軟件需求得到？描述清楚？片面,不完全如何保證得到了所有的軟件需求？模糊,不準確如何保證把需求說清楚和準確？不一致,歧義如何保證所描述的需求是不矛盾的？及時性當需求變更時，如何讓相關人員都知道需求已經變更？軟件需求變動帶來的問題波動性放大性22精選課件需求分析與程序分析的不同23精選課件需求分析常見問題誤解交流障礙缺乏共同語言“完整性”問題需求永遠不會穩定用戶意見不統一錯誤要求認識混淆24精選課件案例分析：中源公司的電信軟件項目思考：為什么需求工作出現了問題？在需求出現變更時怎么辦？如何更好地進行需求管理？下一步可采取什么措施？25精選課件需求問題的解決方法和手段技術層面需求分析方法、技術和工具方法：數據流、面向對象技術：抽象、建模、多視點、原型、……工具：UML，Rose，Word，Excel，RequisitePro管理層面對需求分析中的人、活動和產品進行管理形成新的研究領域：需求工程26精選課件需求工程（RequirementEngineering）軟件工程的子領域。應用已證實有效的技術、方法進行需求分析，確定客戶需求，幫助分析人員理解問題并定義和管理目標系統的需求

需求工程需求開發需求管理需求獲取需求分析需求建模需求規約需求驗證27精選課件軟件需求工程：需求獲取需求分析與協商需求建模需求描述需求驗證需求管理需求分析和協商需求描述需求驗證系統模型用戶需求和系統需求需求規約需求管理需求獲取需求建模28精選課件（一）需求獲取系統分析人員通過與用戶交流，對現有系統的觀察及對任務進行分析：確定系統或產品范圍與系統或產品有關的人員及特征列表系統的技術環境的描述系統功能的列表及應用于每個需求的領域限制一組描述不同運行條件下系統的應用場景為更好地定義需求而開發的原型

需求獲取工作的產品為進行需求分析提供了基礎29精選課件需求獲取方法工作內容用耳聆聽用戶的需求用腦分析和整理所獲取的信息用手形成文檔化的描述方法建立順暢的通信途徑客戶訪談和調查建立聯合分析小組，觀察用戶操作流程組成聯合小組及時整理分析，反饋循環快速原型30精選課件建立順暢的通信途徑建立分析所需要的通信途徑，以保證能順利地對問題進行分析。31精選課件訪談與調查在具體的實踐中，通常采用折衷的方法，即適當地計劃好面談，但不要過于詳細，允許有一定的靈活性。一般按照如下原則進行準備：所提問的問題應該循序漸進，從整體的方面開始提問，接下來的問題應有助于對前面的問題更好的理解和細化不要限制用戶對問題的回答，這有可能會引出原先沒有注意的問題提問和回答在匯總后應能夠反映用戶需求的全貌。32精選課件需求分析要深入實際市場調查了解市場對待開發軟件的要求；市場上有無與待開發軟件類似的系統及其情況訪問用戶和用戶領域的專家考察現場,跟蹤現場業務流程查閱與待開發系統有關的資料33精選課件觀察用戶操作流程到用戶的實際工作環境中對用戶的工作流程進行觀察，了解用戶實際的操作環境、操作過程和操作要求，對照用戶提交的問題陳述，對用戶需求可以有更全面、更細致的認識。34精選課件組成聯合小組便利的應用規約技術(FacilitatedApplicationSpecificationTechniques,FAST)：打破用戶（需方）和開發者（供方）的界限，共同組成一個聯合小組，發揮各自的長處，共同負責項目的推進，這樣有助于發揮各自優勢并增進解和協調鼓勵建立客戶和系統分析員之間的合作，由他們共同工作來標識問題、提出解決方案的要素、商議不同的方法以及刻畫出初步的解決方案需求加強聯系促進交流增進合作35精選課件FAST基本原則在中立的地點舉行由開發者和用戶出席的會議；建立準備和參與會議的規則；建議一個足夠正式的議程以便可以進行自由的交流；一個“協調者”(他可以是用戶、開發者或其他外人)來控制會議；使用一種“定義機制”(它可以是工作表、圖表、墻上膠黏紙或墻板)；目標是標識問題、提出解決方案的要素、商議不同的方法、以及在有利于完成目標的氛圍中刻畫出初步的需求。36精選課件需求收集的注意事項如果應用規模較大，可分成幾個需求調查小組同時進行，最后對結果進行匯總一定要和用戶進行充分的交流，發現問題要及時溝通要和用戶打成一片，建立起良好的合作關系如果發現多個軟件需求相互矛盾，要能找到仲裁人或者決策人需求調查應遵循先整體后部分、先抽象后具體的原則幫助用戶發現潛在的需求37精選課件（二）需求分析需求獲取結束后，分析活動對需求進行分類組織，分析每個需求與其它需求的關系，檢查需求的一致性、重疊和遺漏的情況，并對需求進行排序在需求獲取階段，經常出現以下問題：用戶提出的要求超出軟件系統可以實現的范圍或實現能力不同的用戶提出了相互沖突的需求38精選課件需求協商協商的過程就是討論需求沖突，找出每個人都滿意的折衷方案協商不是簡單的邏輯或技術上的爭論，要注意組織和行政方面的因素①不一致的目標②責任的喪失或轉移③組織文化④組織管理態度和士氣⑤部門差異39精選課件參加者應該包括發現沖突、遺漏或重疊的分析員，以及可以解決發現的問題的項目相關人員會議應該討論那些非正式討論不能解決的問題通常會議是解決沖突最快的方式40精選課件（三）需求建模為什么需要對軟件需求進行建模？——需求調查所獲取和文檔化（文字）的軟件需求不能有效地描述軟件需求文字描述的局限性(不準確、二義、歧義、不能直觀揭示關聯)不準確不一致不全面…..41精選課件建模技術建模工具的使用在用戶和系統分析人員之間建立了統一的語言和理解的橋梁，同時系統分析人員借助建模技術對獲取的需求信息進行分析，排除錯誤和彌補不足，確保需求文檔正確反映用戶的真實意圖常用的建模方法面向數據流方法面向對象的方法42精選課件結構化分析方法數據建模的基礎，描述數據對象及其關系功能建模的基礎，描述數據怎樣轉換以及轉換的功能行為建模的基礎，表示系統的各種行為狀態以及狀態間的轉換方式適用于數據處理類型軟件的需求分析43精選課件數據建模：實體關系圖（ERD）數據模型的基本元素數據對象描述對象的屬性描述對象間相互連接的關系數據對象之間的關聯一對一（1:1）一對多（1:N）多對多（M:N）44精選課件數據流圖描述了信息流和數據轉換，表達系統內數據的運動情況系統的功能體現在核心的數據變換中系統的輸入源于用方框表示的外部實體，這種輸入引發系統的數據變換，產生傳遞給外部實體的輸出基本元素45精選課件 數據流圖的基本組成46精選課件數據字典數據字典描述數據流圖的數據存儲、數據加工（最底層加工）和數據流。它記錄的主要內容有：基本信息：名字、別名、描述定義：數據長度、數據類型、數據結構使用特點：取值范圍、使用頻率、使用方式等控制信息：來源、用戶、引用程序、讀寫權限等其它47精選課件行為建模狀態―遷移圖/表描述系統或對象的狀態，以及導致系統或對象的狀態改變的事件，從而描述系統的行為48精選課件（四）需求規約需求規約是分析任務的最終產物，通過建立完整的信息描述、詳細的功能和行為描述、性能需求和設計約束的說明、合適的驗收標準，給出對目標軟件的各種需求需求規約作為用戶和開發者之間的一個協議，在之后的軟件工程各個階段發揮重要作用簽字不是萬能的但沒有簽字是萬萬不能！49精選課件需求的描述不宜使用自然語言描述系統需求原因：理解的二義性，隨意性大，難以模塊化書寫需求的一些原則設計一個標準的格式，保證需求定義按格式書寫使用一致的語言突出顯示關鍵性需求盡量避免使用計算機專業術語50精選課件需求描述方法結構化語言描述依賴于定義標準格式或模板來表達需求描述程序描述語言（PDL）使用一種類似于程序設計語言的語言，但是具有更多抽象特征，通過定義系統的操作模型來定義需求圖形化符號圖形語言輔之以文本注釋來定義系統的功能需求數學描述基于數學概念的符號（如有限狀態機、集合等）51精選課件結構化語言描述模塊標識：Eclipse/Workstation/Tools/DE/FS/3.5.1功能添加節點描述添加一個節點到一個已經存在的設計中。……輸入節點類型，節點位置和設計標識符來源節點類型和節點位置由用戶輸入，設計標識符來自數據庫輸出設計標識符前條件設計處于打開狀態后條件在相應位置添加一個節點，其余無改變副作用無異常無設計標識符……52精選課件程序描述語言（PDL）好處：可以用軟件工具進行語法和語義檢查可檢查需求遺漏和不一致便于描述比較復雜的操作，如循環、選擇等可定義接口便于實現需求到設計的過渡缺點：表達功能的能力不夠充分需要具有程序語言知識的人容易提前進入設計階段，偏離需求分析的目標53精選課件圖形化符號描述結構化分析用例分析54精選課件需求的描述（續1）需求說明語句保持語句和段落的簡短采用主動語態的表達方式編寫具有正確的語法和標點的完整句子使用的術語應該和詞匯表中定義的一致需求陳述應該具有一致的式樣，例如“系統必須……”，或者“用戶必須……”，并緊跟一個行為動作和可觀察的結果例如：“倉庫管理子系統必須實現一張在所請求的倉庫中有存貨的藥品名單。”55精選課件需求的描述（續2）為了減少不確定性，避免采用模糊的、主觀的術語例如：用戶友好、容易、簡單、迅速、有效、支持、許多、最新技術、優越的、可接受的、健壯的避免使用比較性的詞匯例如：提高，最大化，最小化和最佳化定量地說明所需要提高的程度或者說清一些參數可接受的最大值和最小值56精選課件需求說明的質量特性正確性完整性一致性無二義性可修改性可跟蹤性可驗證性

57精選課件其它需求分析階段的文檔初步的用戶手冊：著重反映目標軟件的用戶功能界面和用戶使用的具體要求。測試計劃修改和完善軟件開發計劃58精選課件（五）需求驗證作為需求開發階段工作的復查手段，需求驗證對功能的正確性、完整性和清晰性，以及其它需求給予評價。為保證軟件需求定義的質量，評審應以專門指定的人員負責，并按規程嚴格進行。59精選課件需求驗證方法需求評審原型建立測試用例生成自動的一致性分析編寫用戶手冊60精選課件需求評審需求審查是需求分析階段工作的最后一步，是由軟件工程師和客戶一起進行并完成的目的是發現軟件需求規格說明中的錯誤、二義性和遺漏的需求復審首先在宏觀的級別上進行，復審者試圖保證軟件需求規格說明是完整的、一致的、精確的，然后更詳細地關注軟件需求規格說明中的措詞61精選課件評審實施(1/2)高級管理者定期參與對軟件需求管理活動進行的評審高級管理者參與定期評審的主要目的是在合適的抽象層次上及時地了解和洞察軟件過程。評審間隔時間應該滿足組織的需要，如果存在異常情況報告機制，間隔時間可以長些項目負責人可定期或者事件驅動地參與對軟件需求管理活動的評審62精選課件評審實施(2/2)軟件質量保證組對軟件需求管理活動和工作產品進行評審和(或)審計，并報告其結果軟件需求已評審，且有關問題在軟件工程組開發軟件之前已得到解決當軟件需求更動時，軟件計劃、工作產品和活動已經適當地更動由軟件需求的更動所導致的對承諾的更動已與受影響組進行協商63精選課件評審人員往往需要檢查以下內容：系統定義的目標是否與用戶的要求一致；系統需求分析階段提供的文檔資料是否齊全；文檔中的描述是否完整、清晰、準確地反映了用戶要求被開發項目的數據流與數據結構是否確定且充足主要功能是否已包括在規定的軟件范圍之內，是否都已充分說明設計的約束條件或限制條件是否符合實際開發的技術風險是什么是否詳細制定了檢驗標準，它們能否對系統定義是否成功進行確認

64精選課件自動化工具需求分析工具幫助分析員制定需求規格說明。軟件需求能夠用一種規格說明語言來描述，這種語言把關鍵字指示符與自然語言(例如英語)描述結合起來。規格說明語言被送進一個處理機，它產生出一份需求規格說明，更為重要的是，它同時還產生出一組有關規格說明的一致性和組織的診斷報告。65精選課件自動化工具的手段演繹綜合手段：基于數學推理的構造式證明程序變換手段：將一程序轉換成另一功能等價的程序，并保持其正確性不變實例推廣手段從實例特征出發，將它推廣為待編程序的特征，最后得到程序。過程化手段：研究甚高級語言的編譯和知識的過程化66精選課件可執行規格說明基于腳本(scenario)的設計自動程序設計專用語言可復用(reusable)的軟件簡化假設原型開發技術67精選課件小結1：需求開發活動不會是線性地、順序地完成。實際上，這些活動是交叉的、遞增的和反復的領域了解需求收集需求描述需求文檔過程入口分類沖突解決優先排序需求檢查(1)(2)(3)(4)(5)(6)(7)(8)(9)(10)(11)(12)(13)(14)(15)68精選課件小結2：軟件需求分析人員應該具備的素質善于領會一些抽象的概念，重新整理使之成為各種邏輯成分，并根據各種邏輯成分綜合出問題的解決辦法善于從各種相互沖突或混淆的原始資料中吸取恰當的論據能夠理解用戶的環境及領域知識具備把系統的硬件和軟件部分應用于用戶環境的能力具備良好的書面和口頭形式進行討論和交換意見的能力具有“既能看到樹木，又能看到森林”的能力69精選課件（六）需求管理為什么要需求管理？軟件需求肯定是不完全的需求變動，軟件演化需求管理是對系統需求變更了解和控制的過程，是一組用于幫助項目組在項目進展中的任何時候去標識、控制和跟蹤需求的活動從演化的角度看，需求分為：持久的需求易變的需求70精選課件需求管理常見的問題軟件開發所基于的需求往往不完整不準確模棱兩可需求定義沒有生成文檔，或文檔未及時更新即使已采用一個個孤立的文檔來管理需求，但是文檔散布各處，沒人知道哪個是最新版本文檔對信息分析、優先級別劃分和跟蹤效率不高很難從需求文檔中提取與項目有關的狀態信息對需求沒有達成共識隨著情況的改變需求產生變更，但無法有效地管理和跟蹤71精選課件導致問題的原因缺乏用戶參與忽略了用戶分類在需求階段，項目的范圍尚未很好的定義忽視了運行、操作、法規等方面的約束“張三”不知道怎么寫需求說明對需求過程不夠了解管理層不重視開發過程中修補原始需求的缺陷不可控制的外因72精選課件需求管理的內容73精選課件需求管理的方法確定需求變更控制過程進行需求變更影響分析維護需求變更的歷史記錄建立需求基準版本和需求控制版本文檔跟蹤每項需求的狀態衡量需求穩定性74精選課件需求變更管理問題分析和變更描述變更分析和成本計算識別出的問題修正后的需求變更實現需求變更管理的要求仔細評估已建議的變更制定合適的變更處理變更及時通知所有涉及的人員75精選課件控制需求的變更(1/3)需求變更不可避免軟件需求本身是變化的在需求分析階段對軟件需求的描述和分析不全面、不準確等需求變更對軟件項目的開發會產生巨大的影響產品功能開發成本開發進度產品質量76精選課件控制需求的變更(2/3)需求變更的權衡，需要和用戶協商，并對計劃進行變更需求成本進度77精選課件控制需求的變更(3/3)如何控制需求的變更提出軟件需求變更請求對軟件需求變更進行評審變更軟件需求說明書（SRS）將變更后的SRS納入配置通知受影響小組和人員變更其他產品(軟件設計文檔、測試文檔)和計劃(軟件開發計劃)78精選課件8.3軟件需求的變更控制需求變更處理流程79精選課件需求文檔的版本控制統一確定版本變更必須文檔化，及時通知有關人員指定專人更新需求文檔應包括版本修正歷史需求管理工具的數據庫存儲需求使用專門的版本管理工具及數據庫80精選課件需求跟蹤當某項業務需求發生變化時，可能會影響到系統需求和功能需求的變化，并且連帶地影響到設計、測試、實現、項目計劃等各方面的變化需求跟蹤：應編制每個需求同系統元素之間的聯系文檔81精選課件需求跟蹤的方式正向跟蹤：以用戶需求為切入點，檢查《需求規約》中的每個需求是否都能在后繼工作產品中找到對應點逆向跟蹤：檢查設計文檔、代碼、測試用況等工作產品是否都能在《需求規約》中找到出處82精選課件需求跟蹤能力矩陣例子：大量的需求跟蹤信息可以使用特定的工具進行管理83精選課件小結：需求階段的常見問題需求的溝通與理解缺乏足夠的用戶參與添加不必要的特性忽略了用戶分類

需求的變化與控制用戶需求不斷增加

需求說明的明確與完整需求模棱兩可需求說明過于簡單

用戶積極參與，各方和諧合作有效管理與評審準確、無二義性的高質量需求文檔84精選課件CMM對需求管理的要求(1/3)需求管理是CMM2級的一個關鍵過程域CMM對需求管理的理解和定義需求管理是指在用戶和將處理“分配給軟件的系統需求”的軟件項目組之間建立對“分配給軟件的系統需求