需求分析與驗證教材P117第5章先思考幾個問題？需求獲取涉及的UML圖形？（回顧）需求獲取過程模型？（回顧）2023/2/42閱讀書的第五章回答下列問題？需求分析使用的UML圖形有哪些？需求分析的過程模型包括哪些活動？如何確定需求的優先級？10分鐘2023/2/43第五章需求分析與驗證

5.1分析模型的表示

順序圖、通信圖、狀態圖5.2需求分析的過程模型

5.3需求優先級分析

5.4用例分析5.5利用快速原型輔助需求分析5.6評審分析模型

5.7需求規約

5.8需求驗證

2023/2/44第五章需求分析與驗證5.1分析模型的表示

5.1.1順序圖

5.1.2通信圖

5.1.3狀態圖

2023/2/455.1分析模型的表示在用例模型已成的情形下為何還要構建分析模型？2023/2/46分析模型的表示構建分析模型的兩點理由：⑴分析模型比用例模型更加結構化、更加清晰直觀。⑵分析模型是用例模型與軟件設計模型之間的“橋梁”。2023/2/47分析模型的表示參與者：需求工程師。軟件架構師、利益相關方，以及項目軟件經理、質量保證工程師。輸入與輸出：輸入制品與需求獲取活動的輸出制品相同。在所有這些輸入制品中，用例模型最重要。輸出制品主要是軟件需求的分析模型。該模型是需求規約的主要組成部分，同時也是后續軟件設計、構造和測試活動的工作基礎。2023/2/485.1分析模型的表示2023/2/49順序圖分類：交互圖包括順序圖和通信圖兩種。前者強調消息傳遞的時間序，后者突出交換消息的對象之間的合作關系。雖然它們各有側重，但從語義上講基本等價，可從一種圖自動轉換為另一種圖。2023/2/410順序圖交互圖的作用：業務分析及需求分析人員？軟件設計及實現人員？測試人員？課程注冊管理系統中“制訂選課計劃”用例的順序圖2023/2/411圖5.1課程注冊管理系統中“制訂選課計劃”用例的順序圖2023/2/4125.1.2通信圖通信圖是順序圖的另一種表現形式。如，圖5.5是與圖5.1所示的順序圖等價的通信圖（除注解外）2023/2/4132023/2/414圖5.5課程注冊管理系統中“制訂選課計劃”用例的通信圖（三）順序圖與通信圖之間的選取順序圖和通信圖互為派生視圖，建模者往往面臨選用順序圖還是通信圖的困惑。建議讀者依次考慮以下規則（前面的規則優先級較高）：⑴當需要強調消息傳遞的時間序時采用順序圖；

當需要強調對象之間的交互、協作關系時采用通信圖。⑵當刻畫用例的動作序列時，采用順序圖；

當刻畫軟件內部等某項功能的實現構想時，采用通信圖。⑶在業務分析和需求建模階段，優先考慮順序圖；在設計和實現階段，優先考慮通信圖。2023/2/4155.1.3狀態圖定義：狀態圖描述一個實體在事件刺激下的反應式動態行為。構成：狀態、事件以及響應動作。實體可以是對象，軟件系統（或其子部分）或其中一個軟構件，整個大系統。作用：狀態圖可用來描述實體的行為。2023/2/416圖5.6課程注冊管理系統中“課程設置”

類的典型對象的狀態圖2023/2/4175.2需求分析的過程模型如何展開需求分析？應該遵循何種過程模型來展開需求分析？需求分析的主要任務是：建立比用例模型更完整、更精細的分析模型，以期獲得對軟件需求的更深入理解，提高軟件需求的質量，為軟件設計奠定更堅實的基礎。2023/2/418需求分析的過程模型用例驅動的需求分析過程的主要活動如下⑴需求優先級分析。⑵用例分析。⑶分析模型評審。⑷為輔助需求分析而構建快速原型。這些活動可按序組織為需求分析工作流。圖5.12需求分析工作流2023/2/4195.3需求優先級分析主要任務：確定每項需求優先級。三種不同的詮釋方法：⑴基于實現緊迫度的優先級(其他兩個略)高優先級必須實現的需求項；中優先級最終必須實現的需求項，至下一軟件版本再實現；低優先級

“錦上添花”式的需求項，趨于完美。2023/2/420表5.1家庭保安系統的需求優先級序號用例/質量需求項名稱優先級說明1開關機及復位處理高必須完整實現2系統配置高同上3傳感器監測高同上4日志查詢中應該實現其中大部分功能5性能：Req-Performance-001~002高對產品可接受度的影響最大6可靠性：Req-Reliability-001~003高同上7安全性：Req-Authentication-001和Req-Authorization-001高同上8可配置性：Req-Config-001高同上9安全性：Req-Audit-001中對產品可接受度有一定影響10易用性：Req-EasyUse-001~002中同上11可擴展性：Req-Extend-001中同上12可伸縮性：Req-Scalability-001中同上13兼容性：Req-Compatibility-001低可以不予實現，但其實現可以增強產品可接受度14本地化與國際化：Req-Intl-001低同上2023/2/421用例分析用例分析的子活動歸納如下：⑴精化領域概念模型；⑵設置分析類；⑶構思分析類之間協作關系；⑷導出分析類圖。2023/2/422圖5.13家庭保安系統的領域概念模型（精化）2023/2/4235.4.2設置分析類分析類：是指直接服務于軟件的功能性需求的概念層面的類，它與待開發軟件系統的具體實現技術無關。從功能需求的角度看，用例的業務邏輯處理功能主要由邊界類、控制類和實體類三種分析類協同完成。2023/2/424邊界類：負責目標軟件系統與外部執行者之間的交互。

控制類：用例任務的責任承擔者，負責協調、控制其他類共同完成用例規定的功能或行為。實體類負責保存目標軟件系統中具有持久意義的信息項并向其他類提供信息訪問的操作。2023/2/4255.4.2設置分析類5.4.3構思分析類之間的協作關系將用例模型中的用例描述轉化成UML交互圖構造交互圖的關鍵在于將用例的各項功能分解并分派至合適的分析類交互圖有助于需求工程師更深入地理解、分析軟件需求，剔除用例描述中的模糊性、不一致性、不完整性，同時也為后續的軟件設計奠定基礎。2023/2/426圖5.16“傳感器監測”用例的順序圖

2023/2/4275.4.4導出分析類圖將消息的響應對應到分析類的職責，從而推動分析模型的建立和精化，持續邁向軟件設計和編程實現。從用例描述中的事件及動作序列，到交互圖中的消息，再到分析類的職責，最后演變為設計元素的功能或方法，這個進化過程是面向對象分析與設計過程的關鍵2023/2/428（一）創建初始的分析類圖比較并研究領域概念模型和交互圖，以領域概念模型為基礎創建初始的分析類圖。如果交互圖中出現了某個對象，其所屬的分析類未在領域概念模型中出現，則應在分析類圖中添加此分析類；反之，針對領域概念模型中的類，如果其對象未在任何交互圖中出現，則需求工程師必須判斷該類是否對用戶需求的實現有所貢獻。2023/2/429圖5.18家庭保安系統的分析類圖（初步）2023/2/430（二）根據消息確定分析類的職責（三）根據消息傳遞確定分析類之間的連接（四）根據交互圖確立分析類的屬性（五）整理分析類圖2023/2/431圖5.21家庭保安系統的分析類圖2023/2/432例5.10

導出分析類圖5.5利用快速原型輔助需求分析原型的分類：探索性原型實驗性原型進化性原型2023/2/4335.6評審分析模型參與人員：需求工程師、軟件設計師、項目軟件經理、利益相關方的代表和業務專家任務：正式地審查需求優先級、基于UML的分析模型（含分析類圖、交互圖、狀態圖、活動圖），快速原型等分析模型是被評審的主體對象。2023/2/4345.7需求規約需求規約：需求工程師經需求獲取的分析后形成的軟件文檔。需求規約主體內容：軟件需求的用例模型和分析模型。需求規約的作用是什么？2023/2/4355.8需求驗證⑴需求評審。⑵問題整理。⑶問題求解。⑷達成一致。2023/2/436需求工程習題詳見