第5講需求分析與驗證

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

5.1分析模型的表示

順序圖、通信圖、狀態(tài)圖5.2需求分析的過程模型

5.3需求優(yōu)先級分析

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

5.7需求規(guī)約

5.8需求驗證

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

5.1.1順序圖

5.1.2通信圖

5.1.3狀態(tài)圖

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

當(dāng)需要強調(diào)對象之間的交互、協(xié)作關(guān)系時采用通信圖。⑵當(dāng)刻畫用例的動作序列時，采用順序圖；

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

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

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

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

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

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