南京大學(xué) 軟件 需求工程.需求分析概述

1、單擊此處編輯母版標(biāo)題樣式單擊此處編輯母版文本樣式第二級(jí)第三級(jí)第四級(jí)第五級(jí)*單擊此處編輯母版標(biāo)題樣式單擊此處編輯母版文本樣式第二級(jí)第三級(jí)第四級(jí)第五級(jí)*第11章.需求分析概述主要內(nèi)容需求分析的根本任務(wù)建立分析模型建立解決方案需求分析技術(shù)需求分析方法前期需求階段的建模與分析需求分析的活動(dòng)1. 需求分析的根本任務(wù)1. 需求分析的根本任務(wù)建立分析模型將復(fù)雜的系統(tǒng)分解成為簡(jiǎn)單的局部以及它們之間的聯(lián)系，確定本質(zhì)特征和用戶(hù)達(dá)成對(duì)信息內(nèi)容的共同理解分析的活動(dòng)主要包括識(shí)別、定義和結(jié)構(gòu)化，它的目的是獲取某個(gè)可以轉(zhuǎn)換為知識(shí)的事物的信息1. 需求分析的根本任務(wù)創(chuàng)立解決方案將一個(gè)問(wèn)題分解成獨(dú)立的、更簡(jiǎn)單和易于管理的子問(wèn)題

2、來(lái)幫助尋找解決方案創(chuàng)立解決方案的過(guò)程是創(chuàng)造性的幫助開(kāi)發(fā)者建立問(wèn)題的定義，并確定被定義的事物之間的邏輯關(guān)系這些邏輯關(guān)系可以形成信息的推理，進(jìn)而可以被用來(lái)驗(yàn)證解決方案的正確性。1.1建立分析模型模型 “模型是對(duì)事物的抽象，幫助人們?cè)趧?chuàng)立一個(gè)事物之前可以有更好的理解 集中關(guān)注問(wèn)題的計(jì)算特性數(shù)據(jù)、功能、規(guī)那么等等 “它是對(duì)系統(tǒng)進(jìn)行思考和推理的一種方式。建模的目標(biāo)是建立系統(tǒng)的一個(gè)表示，這個(gè)表示以精確一致的方式描述系統(tǒng)，使得系統(tǒng)的使用更加容易 建模方法抽象分解投影1.1建立分析模型模型在軟件開(kāi)發(fā)中建立軟件模型可以取得以下好處：通過(guò)建模抽象降低應(yīng)用的復(fù)雜性；在建模的過(guò)程中更深刻的理解信息；可以幫助人們更好的

3、記憶細(xì)節(jié)；可以更好的與其他開(kāi)發(fā)人員進(jìn)行交流；可以更好的與用戶(hù)以及其他涉眾進(jìn)行交流；為以后的維護(hù)和升級(jí)提供文檔 1.1建立分析模型抽象Abstraction一方面要求人們只關(guān)注重要的信息，忽略次要的內(nèi)容通過(guò)強(qiáng)調(diào)本質(zhì)的特征，就減少了問(wèn)題的復(fù)雜性另一方面也要求人們將認(rèn)知保存在適當(dāng)?shù)膶哟危帘胃顚哟蔚募?xì)節(jié)在問(wèn)題的各元素之間推斷出更廣泛和更普遍的關(guān)系，幫助人們尋找解決方案分解Decomposition / Partitioning“分而治之將單個(gè)復(fù)雜和難以理解的問(wèn)題分解成多個(gè)相對(duì)更容易的子問(wèn)題，并掌握各子問(wèn)題之間的聯(lián)系分解的方案往往還能提供問(wèn)題的解決思路投影Projection多視點(diǎn)方法1.1建立分析

4、模型計(jì)算世界與計(jì)算模型使用軟件的構(gòu)成單位作為模型的組元軟件構(gòu)建單位之間的關(guān)系作為模型組元之間的關(guān)系基于計(jì)算科學(xué)建立的，具有形式化的特征信息的描述具有明確化、準(zhǔn)確化和確定化的特征需求分析階段不適宜建立形式化的計(jì)算模型重點(diǎn)是問(wèn)題，缺乏和軟件實(shí)現(xiàn)相關(guān)的技術(shù)細(xì)節(jié)用戶(hù)無(wú)法理解1.1建立分析模型問(wèn)題世界與業(yè)務(wù)模型使用問(wèn)題域中的重要概念作為模型的組元使用概念之間的業(yè)務(wù)聯(lián)系作為組元之間的關(guān)系使用了業(yè)務(wù)描述的方式，具有非形式化特征業(yè)務(wù)模型元素即業(yè)務(wù)概念和業(yè)務(wù)聯(lián)系的選取和定義上具有不準(zhǔn)確、不確定和模糊化可以抽取出需求信息中最重要和最本質(zhì)的內(nèi)容可以達(dá)成用戶(hù)和開(kāi)發(fā)者的共同理解非形式化特征使得它不適合于進(jìn)行需求建模缺乏

5、以用于描述一個(gè)有效的軟件解決方案不準(zhǔn)確、不確定和模糊化1.1建立分析模型軟件分析模型介于計(jì)算模型和業(yè)務(wù)模型二者之間的模型形式使用了計(jì)算模型的組元形式在組元的表現(xiàn)上采用了業(yè)務(wù)模型的表現(xiàn)方式半形式化的不像計(jì)算模型那么嚴(yán)謹(jǐn)比業(yè)務(wù)模型更嚴(yán)格1.1建立分析模型三種模型1.1建立分析模型模型的描述三個(gè)要素之間互為依賴(lài)，每個(gè)要素都為下一個(gè)要素提供了一個(gè)必需的環(huán)境語(yǔ)法：使用規(guī)那么怎樣使用模型的元素，并且以什么方式組織、連接或關(guān)聯(lián)這些元素；語(yǔ)義：特定模型元素所具有的含義；語(yǔ)用：模型元素的上下文，以及影響該模型元素意義的約束和假定分析模型語(yǔ)用復(fù)雜語(yǔ)義豐富語(yǔ)法嚴(yán)格同時(shí)又不太復(fù)雜曾經(jīng)有很多的研究者嘗試建立一種能夠描述

6、軟件開(kāi)發(fā)中各種情景的形式化或半形式化模型語(yǔ)言，但最后都失敗了1.1建立分析模型模型的描述多視點(diǎn)方法1.1建立分析模型視點(diǎn)Viewpoints：將系統(tǒng)中既交織共存又相對(duì)獨(dú)立的不同內(nèi)容拆解成不同的局部每一個(gè)視點(diǎn)都是獨(dú)立的模型存在，用獨(dú)立的模型語(yǔ)言和表示法進(jìn)行描述多視點(diǎn)：所有視點(diǎn)的模型描述集成起來(lái)，就是對(duì)原有復(fù)雜系統(tǒng)的模型描述依據(jù)系統(tǒng)內(nèi)不同局部之間的關(guān)系，建立不同模型內(nèi)元素之間的聯(lián)系，從而將多個(gè)獨(dú)立的模型描述在語(yǔ)義上連接起來(lái)1.1建立分析模型模型、模型語(yǔ)言與表示法 1.1建立分析模型需求建模通常的做法是：先依據(jù)獲取的問(wèn)題域信息建立初步的模型。然后分析用戶(hù)需求，對(duì)模型進(jìn)行調(diào)整，得到一個(gè)中間形式的模型形

7、式。最后，對(duì)調(diào)整后的模型進(jìn)行邏輯推理和驗(yàn)證，如果符合預(yù)期的期望，那么它就是最終的解決方案模型。 1.2 建立解決方案需求分析的目標(biāo)1.2 建立解決方案建立解決方案的過(guò)程主要內(nèi)容需求分析的根本任務(wù)需求分析技術(shù)常用需求分析技術(shù)需求分析技術(shù)的開(kāi)展過(guò)程Wieringa框架Zachman 框架需求分析方法前期需求階段的建模與分析需求分析的活動(dòng)2.1 常用需求分析技術(shù)結(jié)構(gòu)化技術(shù)數(shù)據(jù)建模實(shí)體關(guān)系圖Entity Relationship Diagram過(guò)程建模數(shù)據(jù)流圖Data Flow Diagram上下文圖Context Diagram微規(guī)格說(shuō)明Mini-Specification數(shù)據(jù)字典Data Dict

8、ionary行為建模狀態(tài)(轉(zhuǎn)換)圖/矩陣State (Transition) Diagram/Matrix過(guò)程/數(shù)據(jù)關(guān)系建模功能實(shí)體矩陣Function/Entity Matrix信息工程方法功能分解圖Function Decomposition Diagram過(guò)程依賴(lài)圖Process Dependency Diagram面向?qū)ο蠹夹g(shù)UML用例圖Use-Case Diagram類(lèi)圖Class Diagram交互圖順序圖/通信圖InteractionSequence / CommunicationDiagram活動(dòng)圖Activity Diagram對(duì)象約束語(yǔ)言O(shè)bject Constraint

9、Language狀態(tài)圖State Chart Diagram2.1 常用需求分析技術(shù)技術(shù)的綜合運(yùn)用如何為各個(gè)視角選擇需求分析技術(shù)？每一種需求分析技術(shù)都有自己的特點(diǎn)，具有在應(yīng)用上的獨(dú)特性如何實(shí)現(xiàn)它們之間的配合？只有通過(guò)多種需求分析技術(shù)的有機(jī)結(jié)合與集成才能充分的描述復(fù)雜應(yīng)用2.2需求分析技術(shù)的開(kāi)展過(guò)程2.3 Wieringa框架系統(tǒng)對(duì)外交互系統(tǒng)內(nèi)部交互功能式描述通信式描述行為式描述對(duì)交互的有用性的描述對(duì)交互中發(fā)生的信息交流情況的描述更小的交互相互之間形成的先后銜接與協(xié)作關(guān)系交互所涉及的系統(tǒng)或者系統(tǒng)局部的分解關(guān)系分解可以使得系統(tǒng)的對(duì)外交互轉(zhuǎn)換為系統(tǒng)的內(nèi)部交互形式2.3 Wieringa框架結(jié)構(gòu)化信息

10、工程面向?qū)ο笸ㄓ闷渌獠抗δ芄δ芊纸鈭D用例圖狀態(tài)（轉(zhuǎn)移）圖/矩陣外部通信上下文圖用例圖交互圖外部行為過(guò)程依賴(lài)圖交互圖概念組元數(shù)據(jù)流圖DFD實(shí)體關(guān)系圖ERD功能實(shí)體矩陣實(shí)體生命歷史事件實(shí)體矩陣類(lèi)圖數(shù)據(jù)字典對(duì)象角色模型組元功能對(duì)象約束語(yǔ)言微規(guī)格說(shuō)明組元通信數(shù)據(jù)流圖DFD功能實(shí)體矩陣事件實(shí)體矩陣過(guò)程依賴(lài)圖交互圖組元行為實(shí)體生命歷史活動(dòng)圖狀態(tài)（轉(zhuǎn)移）圖/矩陣業(yè)務(wù)過(guò)程模型Petri網(wǎng)2.4 Zachman 框架2.4 Zachman 框架Zachman矩陣的行目標(biāo)/范圍規(guī)劃者視圖關(guān)心軟件系統(tǒng)的本錢(qián)和效益，對(duì)最終系統(tǒng)的規(guī)模、形式、位置空間以及根本目標(biāo)的粗略描述規(guī)劃者視圖規(guī)定了工程的前景和范圍。企業(yè)模型所有

11、者視圖：關(guān)心軟件系統(tǒng)會(huì)如何參與和幫助實(shí)際工作對(duì)業(yè)務(wù)實(shí)體、業(yè)務(wù)過(guò)程以及它們與系統(tǒng)之間交互的描述利用業(yè)務(wù)概念限定了系統(tǒng)的解決方案分析模型。系統(tǒng)模型設(shè)計(jì)師視圖：關(guān)注軟件系統(tǒng)應(yīng)該的需要以及設(shè)計(jì)方法的選擇限制對(duì)軟件系統(tǒng)的根本功能和設(shè)計(jì)空間的描述體系結(jié)構(gòu)。2.4 Zachman 框架Zachman矩陣的行技術(shù)模型構(gòu)建者視圖：關(guān)注程序?qū)浖到y(tǒng)當(dāng)中控制邏輯、算法、I/O控制以及其他各種具體技術(shù)細(xì)節(jié)的描述描述詳細(xì)設(shè)計(jì)的設(shè)計(jì)模型組件模型集成者視圖：關(guān)注組裝對(duì)軟件系統(tǒng)的組件、接口以及編碼程序等內(nèi)容的描述實(shí)際運(yùn)行的系統(tǒng)：描述系統(tǒng)投入使用后的實(shí)際狀況和在運(yùn)行中的實(shí)際表現(xiàn)。2.4 Zachman 框架Zachman矩陣

12、的列：數(shù)據(jù)：對(duì)企業(yè)有重要意義的事物以及企業(yè)對(duì)這些事物的理解功能：企業(yè)在業(yè)務(wù)中執(zhí)行的任務(wù)以及企業(yè)對(duì)任務(wù)的理解。位置：組織活動(dòng)和軟件系統(tǒng)的地理分布，以及它們與組織的其他方面的關(guān)聯(lián)。人：在軟件系統(tǒng)被引入后會(huì)涉及的人員和組織時(shí)間：系統(tǒng)內(nèi)的事件-事件關(guān)聯(lián)之間的時(shí)間因素，表現(xiàn)為業(yè)務(wù)的規(guī)劃調(diào)度、系統(tǒng)的事件響應(yīng)和控制結(jié)構(gòu)。動(dòng)機(jī)：該列針對(duì)的是企業(yè)建立目標(biāo)系統(tǒng)的動(dòng)機(jī)，揭示了企業(yè)的目標(biāo)、目的、業(yè)務(wù)規(guī)劃、知識(shí)架構(gòu)、思想路線和決策根底。2.4 Zachman 框架ContextualConceptualLogicalPhysicalAs BuiltFunctioningContextualConceptualLogic

13、alPhysicalAs BuiltFunctioningWhyWhyWhoWhoWhenWhenWhereWhereWhatWhatHowHowProject scopeAnalysis modelDesign modelCoded programApplication SystemPlaning*AnalysisDesignImplementationIntegrationData ModelingBehavior ModelingEvent ModelingBusiness RulesNetwork topologiesOrganizational structure modelingB

14、usiness Model2.4 Zachman 框架2.4 Zachman 框架結(jié)構(gòu)化信息工程面向?qū)ο笸ㄓ闷渌麛?shù)據(jù)數(shù)據(jù)流圖DFD實(shí)體關(guān)系圖ERD數(shù)據(jù)流圖DFD實(shí)體關(guān)系圖ERD類(lèi)圖數(shù)據(jù)字典對(duì)象角色模型功能上下文圖數(shù)據(jù)流圖DFD功能實(shí)體矩陣上下文圖數(shù)據(jù)流圖DFD功能實(shí)體矩陣功能分解圖過(guò)程依賴(lài)圖用例圖交互圖活動(dòng)圖對(duì)象約束語(yǔ)言微規(guī)格說(shuō)明狀態(tài)（轉(zhuǎn)移）圖/矩陣業(yè)務(wù)過(guò)程模型網(wǎng)絡(luò)Map人員層次模型矩陣模型網(wǎng)狀模型時(shí)間實(shí)體生命歷史事件實(shí)體矩陣實(shí)體生命歷史事件實(shí)體矩陣狀態(tài)（轉(zhuǎn)移）圖/矩陣Petri網(wǎng)動(dòng)機(jī)對(duì)象約束語(yǔ)言微規(guī)格說(shuō)明對(duì)象角色模型主要內(nèi)容需求分析的根本任務(wù)需求分析技術(shù)需求分析方法前期需求階段的建模與分析需

15、求分析的活動(dòng)3. 需求分析方法傳統(tǒng)分析 沒(méi)有方法 (1950s)依賴(lài)個(gè)體才智,依據(jù)個(gè)人習(xí)慣缺乏結(jié)構(gòu)、不可重復(fù)、不可測(cè)量,冗長(zhǎng)、混亂、偏頗、無(wú)結(jié)構(gòu)等等結(jié)構(gòu)化分析 傳統(tǒng)結(jié)構(gòu)化分析 (late 1960s),現(xiàn)代結(jié)構(gòu)化分析 (late 1970s)以數(shù)據(jù)流動(dòng)為中心，以DFD為核心技術(shù)，輔助ERD,STD信息工程 (late 1980s) 以數(shù)據(jù)知識(shí)結(jié)構(gòu)為根底，ERD為核心技術(shù)，輔助DFD，STD, FDD, PD面向?qū)ο蠓治?1990s以對(duì)象為中心，以UML類(lèi)圖為核心技術(shù)以全面思想革新為理想，以承繼結(jié)構(gòu)化技術(shù)為現(xiàn)實(shí)3. 需求分析方法結(jié)構(gòu)化分析3. 需求分析方法面向?qū)ο蠓治鲋饕獌?nèi)容需求分析的根本任務(wù)需

16、求分析技術(shù)需求分析方法前期需求階段的建模與分析需求分析的活動(dòng)4. 前期需求階段的建模與分析4. 前期需求階段的建模與分析面向目標(biāo)的分析Goal Oriented Analysis面向問(wèn)題域的分析Problem Domain Oriented Analysis領(lǐng)域分析Domain Analysis企業(yè)建模Enterprise Modeling 4. 前期需求階段的建模與分析面向問(wèn)題域的分析問(wèn)題框架特性解決框架分解與組合根本思路研究所有可能的問(wèn)題域，從中發(fā)現(xiàn)一些重復(fù)出現(xiàn)的簡(jiǎn)單問(wèn)題類(lèi)型分析每一種問(wèn)題框架的特性，確定問(wèn)題的理解和解決方法將問(wèn)題框架的建立和分類(lèi)系統(tǒng)化，以簡(jiǎn)單的問(wèn)題框架為根本單位，進(jìn)行復(fù)雜

17、問(wèn)題的分解4. 前期需求階段的建模與分析領(lǐng)域分析4. 前期需求階段的建模與分析企業(yè)建模主要用來(lái)理解組織的結(jié)構(gòu)、行為規(guī)那么、目標(biāo)、重要成員的任務(wù)與職責(zé)、操縱的數(shù)據(jù)等等。企業(yè)建模利用企業(yè)的目標(biāo)、任務(wù)、策略、資源等來(lái)刻畫(huà)組織的行為，并依此來(lái)發(fā)現(xiàn)組織開(kāi)發(fā)系統(tǒng)的目的，建立系統(tǒng)的業(yè)務(wù)需求主要內(nèi)容需求分析的根本任務(wù)需求分析技術(shù)需求分析方法前期需求階段的建模與分析需求分析的活動(dòng)5. 需求分析的活動(dòng)5. 需求分析的活動(dòng)需求細(xì)化明確用戶(hù)需求的隱含因素 將從問(wèn)題域和業(yè)務(wù)的角度表述的用戶(hù)需求等價(jià)的轉(zhuǎn)化為從軟件和技術(shù)的角度表述的系統(tǒng)需求 非功能需求也需要從高層次的表述方式轉(zhuǎn)化為一系列更加詳細(xì)和具體的需求表述 需求細(xì)化也

18、會(huì)發(fā)現(xiàn)新的細(xì)節(jié)需求需求已經(jīng)得了充分的理解，并且開(kāi)發(fā)者已經(jīng)可以著手為其進(jìn)行方案設(shè)計(jì)時(shí)停止細(xì)化過(guò)程 細(xì)化后的需求應(yīng)該被一一的標(biāo)識(shí)和記錄下來(lái) 5. 需求分析的活動(dòng)需求細(xì)化需求的記錄標(biāo)識(shí)符ID，每一條需求都應(yīng)該能夠通過(guò)ID唯一的標(biāo)識(shí)自己。源頭Source，要能夠回溯到需求的源頭，例如特定的涉眾。理由Rational，需求被提出的目的。優(yōu)先級(jí)Priority，詳細(xì)情況見(jiàn)下一節(jié)。本錢(qián)Cost，預(yù)估的實(shí)現(xiàn)本錢(qián)。風(fēng)險(xiǎn)Risk，實(shí)現(xiàn)該需求的過(guò)程中可能帶來(lái)的風(fēng)險(xiǎn)?？勺冃訴olatility，將來(lái)發(fā)生變化的可能性。5. 需求分析的活動(dòng)確定需求優(yōu)先級(jí)累計(jì)投票 區(qū)域劃分 重要性。需求的不可或缺程度。緊急性。需求的時(shí)間緊迫程度。懲罰性。忽略需求會(huì)導(dǎo)致的懲罰程度