軟件需求分析

軟件需求分析第1頁，共56頁，2023年，2月20日，星期日課程提綱軟件需求基本理論和概念

軟件需求工程過程

軟件需求獲取

軟件需求分析

軟件需求規(guī)格說明

軟件需求驗證

軟件需求管理

軟件需求實現(xiàn)

軟件需求工程新進展

軟件需求開發(fā)與需求管理工具第2頁，共56頁，2023年，2月20日，星期日內(nèi)容提要需求分析面臨的困難需求分析基本方法和工具數(shù)據(jù)需求分析功能需求分析非功能性需求分析實時系統(tǒng)需求分析基于USECASE的需求分析基于原型方法的分析第3頁，共56頁，2023年，2月20日，星期日需求分析分析是指通過對問題域的研究,獲得對該領(lǐng)域特性及存在于其中的待解決的問題特性的透徹理解并用文檔說明。需求分析是前面需求獲取階段的繼續(xù)，通過對所獲取的信息進一步加工獲得對系統(tǒng)的更精確描述，成為轉(zhuǎn)換成需求規(guī)格說明的直接信息元。但是否將需求分析作為獨立的過程？第4頁，共56頁，2023年，2月20日，星期日需求分析的關(guān)鍵點問題域的結(jié)構(gòu)問題域的數(shù)據(jù)問題域的行為問題域的事件問題域的狀態(tài)派生需求

只是針對問題域嗎？第5頁，共56頁，2023年，2月20日，星期日一.需求分析面臨的困難需求分析是一個項目的開端，也是項目建設(shè)的基石。在失敗的項目中，80％是由于需求分析的不明確而造成的。因此一個項目成功的關(guān)鍵因素之一，就是對需求分析的把握程度。

由于軟件項目的特殊性和行業(yè)覆蓋的廣闊性，以及需求分析的高風險性，軟件需求分析的重要性是不言而喻的，同時需求分析又面臨著很多困難。第6頁，共56頁，2023年，2月20日，星期日二.需求分析基本方法和工具圖1軟件需求工程的組成獲取需求工程需求開發(fā)需求管理分析編寫規(guī)約確認繪制關(guān)聯(lián)圖創(chuàng)建用戶界面和技術(shù)原型分析需求的可行性確定需求的優(yōu)先級為需求建模創(chuàng)建數(shù)據(jù)字典將需求分解到子系統(tǒng)應(yīng)用質(zhì)量功能調(diào)配需求分析包括：第7頁，共56頁，2023年，2月20日，星期日分析方法結(jié)構(gòu)化分析面向?qū)ο蠓治龅?頁，共56頁，2023年，2月20日，星期日分析模型描述工具結(jié)構(gòu)化分析工具DFD、DD和PSPECCFD、CSPEC和STDE-R圖面向?qū)ο蠓治龉ぞ哂美龍D，類圖，對象圖對象-關(guān)系圖對象-行為圖第9頁，共56頁，2023年，2月20日，星期日需求分析建模工具數(shù)據(jù)流圖實體關(guān)系圖狀態(tài)轉(zhuǎn)換圖對話圖類圖PetriNet第10頁，共56頁，2023年，2月20日，星期日建模技術(shù)面向處理技術(shù)Contextdiagram上下文圖Dataflowdiagram(DFD)數(shù)據(jù)流圖流程圖面向數(shù)據(jù)結(jié)構(gòu)技術(shù)E-RD-EntityRelationshipDiagrams面向?qū)ο蠼Ｌ幚砗蛿?shù)據(jù)相結(jié)合ObjectandClass對象和類的技術(shù)第11頁，共56頁，2023年，2月20日，星期日需求分析基本方法

——結(jié)構(gòu)化分析方法(SA)結(jié)構(gòu)化分析（StructuredAnalysis,簡稱SA法）的基本思想：“分解”和“抽象”分解：把系統(tǒng)的復(fù)雜性降低到可以掌握的程度，把大問題分解成若干小問題，然后分別解決。抽象：即先考慮問題最本質(zhì)的屬性，暫把細節(jié)略去，以后再逐層添加細節(jié)，直至涉及到最詳細的內(nèi)容。

圖4自頂向下逐層分解第12頁，共56頁，2023年，2月20日，星期日數(shù)據(jù)流圖數(shù)據(jù)流圖DFD描述系統(tǒng)邏輯模型信息在系統(tǒng)中的流動和處理用途交流信息的工具結(jié)構(gòu)化分析和設(shè)計的工具第13頁，共56頁，2023年，2月20日，星期日數(shù)據(jù)流圖數(shù)據(jù)流圖DFD組成符號圓框代表加工箭頭代表數(shù)據(jù)流向方框代表源點和終點雙杠表示數(shù)據(jù)文件或數(shù)據(jù)庫分層從高層到低層分解前后的數(shù)據(jù)流必須一致命名數(shù)據(jù)流處理第14頁，共56頁，2023年，2月20日，星期日數(shù)據(jù)流圖

DFD練習—售書系統(tǒng)領(lǐng)書單

進書通知

購書單

缺書單

學生教材購銷系統(tǒng)書庫保管員圖5售書系統(tǒng)頂層數(shù)據(jù)流圖第15頁，共56頁，2023年，2月20日，星期日數(shù)據(jù)流圖

DFD練習—售書系統(tǒng)領(lǐng)書單進書通知

進書通知

購書單缺書單

1銷售

2采購書庫保管員

學生F1教材存量表

F2缺書登記表

第16頁，共56頁，2023年，2月20日，星期日功能需求分析

——加工說明PSPEC加工說明PSPEC說明DFD中的每個加工描述工具結(jié)構(gòu)化語言判定表判定樹第17頁，共56頁，2023年，2月20日，星期日處理方法：事件列表與功能列表事件就是要求系統(tǒng)執(zhí)行某項功能的請求業(yè)務(wù)事件與產(chǎn)品事件對復(fù)雜的業(yè)務(wù)任務(wù)采用任務(wù)說明、用例說明或數(shù)據(jù)流圖等方法進行解釋。對復(fù)雜的功能采用數(shù)據(jù)流圖、算法描述、活動圖、數(shù)學說明等進行解釋。第18頁，共56頁，2023年，2月20日，星期日處理方法：事件列表與功能列表事件及功能列表的優(yōu)點主要作為核對清單，以說明應(yīng)開發(fā)什么。其中對這些功能的詳細說明構(gòu)成了功能需求的主要部分。開發(fā)人員可以方便的檢查產(chǎn)品是否實現(xiàn)每一個功能。用戶能夠在某種程度上確認業(yè)務(wù)事件和任務(wù)列表。通過一致性檢查確定列表是否完備。第19頁，共56頁，2023年，2月20日，星期日數(shù)據(jù)需求分析

——數(shù)據(jù)字典DDDFD中所有元素的定義的集合內(nèi)容數(shù)據(jù)流數(shù)據(jù)流分量數(shù)據(jù)存儲處理（一般不用DD描述）定義數(shù)據(jù)的方法自頂向下分解數(shù)據(jù)第20頁，共56頁，2023年，2月20日，星期日數(shù)據(jù)需求分析

——數(shù)據(jù)字典DD數(shù)據(jù)元素的組合方式順序：A+B選擇：[A|B]重復(fù)：1{A}5可選：（A）DD的用途分析階段的交流工具包含控制信息數(shù)據(jù)庫設(shè)計的基礎(chǔ)第21頁，共56頁，2023年，2月20日，星期日E-R圖用于對復(fù)雜數(shù)據(jù)的數(shù)據(jù)分析和建模實體、屬性和關(guān)系組成符號0：11：10：m1:m第22頁，共56頁，2023年，2月20日，星期日E-R圖例子電話機生產(chǎn)廠商經(jīng)銷商用戶生產(chǎn)購買使用經(jīng)銷第23頁，共56頁，2023年，2月20日，星期日數(shù)據(jù)需求與功能需求的區(qū)別數(shù)據(jù)需求指定了系統(tǒng)的存儲數(shù)據(jù)。功能需求則說明數(shù)據(jù)的用途，以及如何記錄、計算、轉(zhuǎn)換、修改及傳輸數(shù)據(jù)等。數(shù)據(jù)需求與功能需求的區(qū)別：第24頁，共56頁，2023年，2月20日，星期日狀態(tài)遷移圖

——STDSTD(StateTransitionDiagram)描述軟件狀態(tài)變遷符號表示矩形---系統(tǒng)狀態(tài)箭頭---狀態(tài)轉(zhuǎn)變方向規(guī)則表達式---事件/觸發(fā)行為狀態(tài)1狀態(tài)2事件/觸發(fā)行為第25頁，共56頁，2023年，2月20日，星期日狀態(tài)遷移圖

——STD例子20秒到/翻屏生成最新數(shù)據(jù)/翻屏半小時到/工控處理半分鐘到/傳送空閑/采集物品經(jīng)過/計數(shù)采集PLC計數(shù)傳送工控處理實時翻屏第26頁，共56頁，2023年，2月20日，星期日上下文圖作用上下文圖能很好地概括產(chǎn)品的必要接口，初步確定產(chǎn)品包含了哪些內(nèi)容，產(chǎn)品之外又包含哪些內(nèi)容。即說明產(chǎn)品及其環(huán)境的視圖。說明產(chǎn)品的范圍。優(yōu)點：上下文圖為開發(fā)任務(wù)概括了所有的接口，在開發(fā)中或開發(fā)后，方便地驗證是否已經(jīng)處理了所有接口。用戶容易理解，并發(fā)現(xiàn)遺漏的接口。第27頁，共56頁，2023年，2月20日，星期日對話圖對話圖代表了一個高層抽象的用戶界面體系結(jié)構(gòu)。對話圖描繪了系統(tǒng)中的對話元素和它們之間的導(dǎo)航連接，但它沒有揭示具體的屏幕設(shè)計。對話圖可以使你在對需求的理解上探索假設(shè)的用戶界面概念。用戶和開發(fā)者可以通過對話圖在用戶如何利用系統(tǒng)執(zhí)行任務(wù)上達成共同的視覺界面。對話圖與系統(tǒng)情節(jié)敘述相關(guān)聯(lián)，這些敘述還包括對每一個屏幕意圖的簡短說明。對話圖抓住了用戶一系統(tǒng)交互作用和任務(wù)流的本質(zhì)，而不會使你太快陷入到屏幕布局和數(shù)據(jù)元素的特定細節(jié)中。用戶可以通過跟蹤對話圖尋找遺漏、錯誤或多余的轉(zhuǎn)換，和因此而有遺漏、錯誤或多余的需求。你可以把在需求分析過程中形成的對話圖用作詳細用戶界面設(shè)計時的指南，最終形成一個執(zhí)行的對話圖，該對話圖記錄了產(chǎn)品的真正用戶界面的體系結(jié)構(gòu)。第28頁，共56頁，2023年，2月20日，星期日對話圖示例第29頁，共56頁，2023年，2月20日，星期日非功能性需求分析所謂非功能性需求，是指軟件產(chǎn)品為滿足用戶業(yè)務(wù)需求而必須具有且除功能需求以外的特性。軟件產(chǎn)品的非功能性需求包括系統(tǒng)的性能、可靠性、可維護性、可擴充性和對技術(shù)和對業(yè)務(wù)的適應(yīng)性等。非功能性需求涉及的范圍很廣，軟件產(chǎn)品本身不是孤立存在的，還涉及到諸多外在環(huán)境的影響。非功能性需求必須考慮軟件既要可用，又要易用。第30頁，共56頁，2023年，2月20日，星期日實時系統(tǒng)需求分析實時系統(tǒng)廣泛應(yīng)用在航天、航空、通信、國防等領(lǐng)域。實時系統(tǒng)以計算機技術(shù)為基礎(chǔ)、以應(yīng)用為目的、將軟件和硬件緊密結(jié)合在一起，實現(xiàn)特定功能的系統(tǒng)。與通用系統(tǒng)相比，實時系統(tǒng)具有一些顯著的特點：實時性可靠性可預(yù)測性第31頁，共56頁，2023年，2月20日，星期日實時系統(tǒng)需求分析基于實時系統(tǒng)的特點，在開發(fā)一個復(fù)雜的實時系統(tǒng)時，一個充分再現(xiàn)系統(tǒng)特性的建模工具至關(guān)重要，對于系統(tǒng)分析、設(shè)計、實現(xiàn)、成本控制、可重用都具有重要的意義?？蛇x用UML-RT工具進行實時系統(tǒng)的需求分析。UML-RT是利用通用建模語言UML的擴展機制并借鑒實時的面向?qū)ο蟮姆椒≧OOM（Real-timeObject-OrientedModeling）的優(yōu)點發(fā)展而來。第32頁，共56頁，2023年，2月20日，星期日實時系統(tǒng)需求分析UML-RT用協(xié)作圖表示特定環(huán)境下類之間的關(guān)系。UML-RT有兩種結(jié)構(gòu)元素：模型結(jié)構(gòu)和模型行為。模型結(jié)構(gòu)：封裝體端口連接器模型行為：協(xié)議狀態(tài)機定時服務(wù)第33頁，共56頁，2023年，2月20日，星期日PetriNet(ActivityDiagram)ElementsPositionTransitionTransitionarcMarking第34頁，共56頁，2023年，2月20日，星期日PetriNet第35頁，共56頁，2023年，2月20日，星期日行為(功能)建模FSM有限狀態(tài)機-通過輸入輸出之間的因果關(guān)系對系統(tǒng)的行為進行建模系統(tǒng)可看作有若干個相互區(qū)別的穩(wěn)定狀態(tài)外部刺激使系統(tǒng)從當前某個狀態(tài)改變到另一個狀態(tài)狀態(tài)轉(zhuǎn)移圖StateTransitionDiagram狀態(tài)圖StateChartDiagramSpecificationanddescriptionlanguage(SDL)規(guī)范與描述語言PetriNet第36頁，共56頁，2023年，2月20日，星期日基于USECASE的需求分析

——用例圖用例：系統(tǒng)和外部角色的交互符號表示：

系統(tǒng)名稱系統(tǒng)用例名用例角色關(guān)聯(lián)第37頁，共56頁，2023年，2月20日，星期日保險商務(wù)系統(tǒng)簽定保險單銷售統(tǒng)計客戶統(tǒng)計客戶保險銷售員基于USECASE的需求分析

——UseCase圖例子第38頁，共56頁，2023年，2月20日，星期日基于USECASE的需求分析

——用例之間的關(guān)系擴展關(guān)系使用關(guān)系組合關(guān)系《擴展》簽保險單簽汽車購買契約《使用》《使用》簽保險單簽汽車保險單簽房屋保險單第39頁，共56頁，2023年，2月20日，星期日類圖第40頁，共56頁，2023年，2月20日，星期日面向?qū)ο笮枨蠓治鲆驗槿祟愖匀坏刳呄蛴谟谩皩ο蟆钡挠^點或“方法”來認識問題，分析問題以及解決問題，用基于“對象”的概念模型來建立問題域模型自然成為系統(tǒng)分析員與用戶交流的有效工具。用面向?qū)ο蟮姆椒ㄟM行需求分析，其根本要點在于，利用"對象"的概念模型建立一個針對于問題域的模型，用戶和軟件工程師通過該模型進行交流。通過在這么一個基于"對象"的問題域模型的基礎(chǔ)上形成需求規(guī)格說明書。第41頁，共56頁，2023年，2月20日，星期日面向?qū)ο笮枨蠓治?步驟通過查看相關(guān)資料并與用戶廣泛地接觸，自己對問題域有一個大致的了解。在這個基礎(chǔ)上，將問題域中與系統(tǒng)和問題有關(guān)的對象提取出來。這就是標識對象的工作。將第一步中抽象出來的對象(類)的之間的關(guān)系考慮清楚；如整體與部分、從屬關(guān)系等；為“類”提取與系統(tǒng)問題域有關(guān)的屬性、服務(wù)等；由于要完成一項任務(wù)，肯定是有不同的對象互相協(xié)作完成的。同時一個對象的屬性、服務(wù)也是在與相關(guān)對象的協(xié)作中體現(xiàn)出來的。將問題域中所有任務(wù)的對象的協(xié)作關(guān)系搞清楚，是面向?qū)ο笮枨蠓治龅年P(guān)鍵一環(huán)。即將問題域中的“劇情”搞清楚，是需求分析的主要工作之一。第42頁，共56頁，2023年，2月20日，星期日面向?qū)ο笮枨蠓治鲆陨纤牟讲⒉皇菃为毜亩腔ビ新?lián)系，可以同時進行的。通過，對以上4步工作的反復(fù)執(zhí)行我們就可以建立一個基于對象的問題域的模型。在該模型的基礎(chǔ)上，可以比較容易地產(chǎn)生一個符合用戶需求的軟件需求規(guī)格說明書成為后續(xù)工作的基礎(chǔ)。第43頁，共56頁，2023年，2月20日，星期日基于原型方法的分析軟件原型是所提議的新產(chǎn)品的部分實現(xiàn)或可能的實現(xiàn)，使用原型有3個主要目的：明確并完善需求研究設(shè)計選擇方案發(fā)展為最終產(chǎn)品原型法就是不斷地運行系統(tǒng)“原型”來進行啟發(fā)、揭示、判斷、修改和完善的系統(tǒng)開發(fā)方法。第44頁，共56頁，2023年，2月20日，星期日基于原型方法的分析對原型的基本要求包括：體現(xiàn)主要的功能；提供基本的界面風格；展示比較模糊的部分以便于確認或進一步明確；原型最好是可運行的，至少在各主要功能模塊之間能夠建立相互連接。

第45頁，共56頁，2023年，2月20日，星期日原型方法的一般過程第46頁，共56頁，2023年，2月20日，星期日基于原型方法的分析原型可以分為三類：淘汰(拋棄)式(disposable)：目的達到即被拋棄，原型不作為最終產(chǎn)品。演化式(evolutionary)：系統(tǒng)的形成和發(fā)展是逐步完成的，它是高度動態(tài)迭代和高度動態(tài)的循環(huán)，每次迭代都要對系統(tǒng)重新進行規(guī)格說明、重新設(shè)計、重新實現(xiàn)和重新評價，所以是對付變化最為有效的方法。增量式(incremental)：系統(tǒng)是一次一段地增量構(gòu)造，與演化式原型的最大區(qū)別在于增量式開發(fā)是在軟件總體設(shè)計基礎(chǔ)上進行的。很顯然，其應(yīng)付變化的能力比演化式差。第47頁，共56頁，2023年，2月20日，星期日基于原型方法的分析

——淘汰式原型利用廢棄原型從用例到用戶界面設(shè)計的活動序列：用例描述對話框廢棄型原型詳細用戶界面設(shè)計反饋反饋反饋第48頁，共56頁，2023年，2月20日，星期日RiskReductionThroughPrototyping

通過原型減小風險原型開發(fā)與需求獲取原型開發(fā)與需求分析原型開發(fā)與需求規(guī)范文檔原型開發(fā)與需求驗證原型開發(fā)與需求風險管理第49頁，共56頁，2023年，2月20日，星期日使用質(zhì)量功能部署 質(zhì)量功能部署(QFD)是一種高級系統(tǒng)技術(shù)，它將產(chǎn)品特性、屬性與對客戶的重要性聯(lián)系起來。該技術(shù)提供了一種分析方法以明確哪些是客戶最關(guān)注的特性。QFD將需求分為三類：期望需求，即客戶或許并未提及，但若缺少會讓他們感到不滿意；普通需求；興奮需求，即實現(xiàn)了會給客戶帶去驚喜，但若未實現(xiàn)也不會受到責備。第50頁，共56頁，2023年，2月20日，星期日QFD示例第51頁，共56頁，2023年，2月20日，星期日如果你有足夠的資源來完成你和你的客戶所想做的全部需求，那再好不過了。但在快速變化的市場環(huán)境中，這是不現(xiàn)實的！設(shè)定需求優(yōu)先級第52頁，共56頁，2023年，2月20日，星期日多種設(shè)定需求優(yōu)先級的規(guī)則命名意義參考高一個關(guān)鍵任務(wù)的需求；下一版本所需求的中支持必要的系統(tǒng)操作；最終所要求的，但如果有必要的話，可以延遲到下一個版本低功能或質(zhì)量上的增強；如果資源允許的話，實現(xiàn)這些需求總有一天使產(chǎn)品更完美基本的只有在這些需求上達成一致意見，軟件才會被接受（IEEE1998）條件的實現(xiàn)這些需求將增強產(chǎn)品的性能，但如果忽略這些需求，產(chǎn)品也是可以被接受的可選的一個功能類，實現(xiàn)或不實現(xiàn)均可3必須完美地實現(xiàn)（Kovitz1999）2需要付出努力，但不必做得太完美1可以包含缺陷(但不是有意的)第53頁，共56頁，2023年，2月20日，星期日設(shè)定需求優(yōu)先級3GPPMandatory(M)–IfarequirementoramessageismarkedasM,itmustbeimplementedConditional(C)–IfarequirementoramessageismarkedasC,itwillbeimplementedconditionallyOptional(O)–IfarequirementoramessageismarkedasO,it