《需求分析概述》PPT課件

1、需求分析概述,主要內(nèi)容,需求分析的根本任務(wù) 建立分析模型 建立解決方案 需求分析技術(shù) 需求分析方法 前期需求階段的建模與分析 需求分析的活動,1. 需求分析的根本任務(wù),1. 需求分析的根本任務(wù),建立分析模型 將復(fù)雜的系統(tǒng)分解成為簡單的部分以及它們之間的聯(lián)系，確定本質(zhì)特征 和用戶達(dá)成對信息內(nèi)容的共同理解 分析的活動主要包括識別、定義和結(jié)構(gòu)化，它的目的是獲取某個可以轉(zhuǎn)換為知識的事物的信息,1. 需求分析的根本任務(wù),創(chuàng)建解決方案 將一個問題分解成獨立的、更簡單和易于管理的子問題來幫助尋找解決方案 創(chuàng)建解決方案的過程是創(chuàng)造性的 幫助開發(fā)者建立問題的定義，并確定被定義的事物之間的邏輯關(guān)系 這些邏輯關(guān)系可

2、以形成信息的推理，進而可以被用來驗證解決方案的正確性。,1.1建立分析模型,模型 “模型是對事物的抽象，幫助人們在創(chuàng)建一個事物之前可以有更好的理解” 集中關(guān)注問題的計算特性（數(shù)據(jù)、功能、規(guī)則等等） “它是對系統(tǒng)進行思考和推理的一種方式。建模的目標(biāo)是建立系統(tǒng)的一個表示，這個表示以精確一致的方式描述系統(tǒng)，使得系統(tǒng)的使用更加容易” 建模方法 抽象 分解 投影,1.1建立分析模型,抽象（Abstraction） 一方面要求人們只關(guān)注重要的信息，忽略次要的內(nèi)容 通過強調(diào)本質(zhì)的特征，就減少了問題的復(fù)雜性 另一方面也要求人們將認(rèn)知保留在適當(dāng)?shù)膶哟危帘胃顚哟蔚募?xì)節(jié) 在問題的各元素之間推斷出更廣泛和更普遍的

3、關(guān)系，幫助人們尋找解決方案 分解（Decomposition / Partitioning） “分而治之” 將單個復(fù)雜和難以理解的問題分解成多個相對更容易的子問題，并掌握各子問題之間的聯(lián)系 分解的方案往往還能提供問題的解決思路 投影（Projection） 多視點方法,1.1建立分析模型,計算世界與計算模型 使用軟件的構(gòu)成單位作為模型的組元 軟件構(gòu)建單位之間的關(guān)系作為模型組元之間的關(guān)系 基于計算科學(xué)建立的，具有形式化的特征 信息的描述具有明確化、準(zhǔn)確化和確定化的特征 需求分析階段不適宜建立形式化的計算模型 重點是問題，缺乏和軟件實現(xiàn)相關(guān)的技術(shù)細(xì)節(jié) 用戶無法理解,1.1建立分析模型,問題世界與業(yè)

4、務(wù)模型 使用問題域中的重要概念作為模型的組元 使用概念之間的業(yè)務(wù)聯(lián)系作為組元之間的關(guān)系 使用了業(yè)務(wù)描述的方式，具有非形式化特征 業(yè)務(wù)模型元素（即業(yè)務(wù)概念和業(yè)務(wù)聯(lián)系）的選取和定義上具有不準(zhǔn)確、不確定和模糊化 可以抽取出需求信息中最重要和最本質(zhì)的內(nèi)容 可以達(dá)成用戶和開發(fā)者的共同理解 非形式化特征使得它不適合于進行需求建模 不足以用于描述一個有效的軟件解決方案 不準(zhǔn)確、不確定和模糊化,1.1建立分析模型,軟件分析模型 介于計算模型和業(yè)務(wù)模型二者之間的模型形式 使用了計算模型的組元形式 在組元的表現(xiàn)上采用了業(yè)務(wù)模型的表現(xiàn)方式 半形式化的 不像計算模型那么嚴(yán)謹(jǐn) 比業(yè)務(wù)模型更嚴(yán)格,1.1建立分析模型,三種

5、模型,1.1建立分析模型,模型的描述 三個要素之間互為依賴，每個要素都為下一個要素提供了一個必需的環(huán)境 語法：使用規(guī)則怎樣使用模型的元素，并且以什么方式組織、連接或關(guān)聯(lián)這些元素； 語義：特定模型元素所具有的含義； 語用：模型元素的上下文，以及影響該模型元素意義的約束和假定 分析模型 語用復(fù)雜 語義豐富 語法嚴(yán)格同時又不太復(fù)雜,曾經(jīng)有很多的研究者嘗試建立一種能夠描述軟件開發(fā)中各種情景的形式化或半形式化模型語言，但最后都失敗了,1.1建立分析模型,模型的描述 多視點方法,1.1建立分析模型,視點（Viewpoints）：將系統(tǒng)中既交織共存又相對獨立的不同內(nèi)容拆解成不同的部分 每一個視點都是獨立的模

6、型存在，用獨立的模型語言和表示法進行描述 多視點：所有視點的模型描述集成起來，就是對原有復(fù)雜系統(tǒng)的模型描述 依據(jù)系統(tǒng)內(nèi)不同部分之間的關(guān)系，建立不同模型內(nèi)元素之間的聯(lián)系，從而將多個獨立的模型描述在語義上連接起來,1.1建立分析模型模型、模型語言與表示法,1.1建立分析模型,需求建模 通常的做法是： 先依據(jù)獲取的問題域信息建立初步的模型。 然后分析用戶需求，對模型進行調(diào)整，得到一個中間形式的模型形式。 最后，對調(diào)整后的模型進行邏輯推理和驗證，如果符合預(yù)期的期望，那么它就是最終的解決方案模型。,1.2 建立解決方案,需求分析的目標(biāo),1.2 建立解決方案建立解決方案的過程,主要內(nèi)容,需求分析的根本任務(wù)

7、 需求分析技術(shù) 常用需求分析技術(shù) 需求分析技術(shù)的發(fā)展過程 Wieringa框架 Zachman 框架 需求分析方法 前期需求階段的建模與分析 需求分析的活動,2.1 常用需求分析技術(shù),結(jié)構(gòu)化技術(shù) 數(shù)據(jù)建模 實體關(guān)系圖Entity Relationship Diagram 過程建模 數(shù)據(jù)流圖Data Flow Diagram 上下文圖Context Diagram 微規(guī)格說明Mini-Specification 數(shù)據(jù)字典Data Dictionary 行為建模 狀態(tài)(轉(zhuǎn)換)圖/矩陣State (Transition) Diagram/Matrix 過程/數(shù)據(jù)關(guān)系建模 功能實體矩陣Function

8、/Entity Matrix 信息工程方法 功能分解圖Function Decomposition Diagram 過程依賴圖Process Dependency Diagram,面向?qū)ο蠹夹g(shù) UML 用例圖Use-Case Diagram 類圖Class Diagram 交互圖（順序圖/通信圖）Interaction（Sequence / Communication）Diagram 活動圖Activity Diagram 對象約束語言O(shè)bject Constraint Language 狀態(tài)圖State Chart Diagram,Next,2.1 常用需求分析技術(shù),技術(shù)的綜合運用 如何為各

9、個視角選擇需求分析技術(shù)？ 每一種需求分析技術(shù)都有自己的特點，具有在應(yīng)用上的獨特性 如何實現(xiàn)它們之間的配合？ 只有通過多種需求分析技術(shù)的有機結(jié)合與集成才能充分的描述復(fù)雜應(yīng)用,2.2需求分析技術(shù)的發(fā)展過程,2.3 Wieringa框架,系統(tǒng)對外交互,系統(tǒng)內(nèi)部交互,功能式描述,通信式描述,行為式描述,對交互的有用性的描述,對交互中發(fā)生的信息交流情況的描述,更小的交互相互之間形成的先后銜接與協(xié)作關(guān)系,交互所涉及的系統(tǒng)或者系統(tǒng)部分的分解關(guān)系,分解可以使得系統(tǒng)的對外交互轉(zhuǎn)換為系統(tǒng)的內(nèi)部交互形式,2.3 Wieringa框架,2.4 Zachman 框架,2.4 Zachman 框架,Zachman矩陣的行

10、 目標(biāo)/范圍（規(guī)劃者視圖） 關(guān)心軟件系統(tǒng)的成本和效益， 對最終系統(tǒng)的規(guī)模、形式、位置空間以及基本目標(biāo)的粗略描述 規(guī)劃者視圖規(guī)定了項目的前景和范圍。 企業(yè)模型（所有者視圖）： 關(guān)心軟件系統(tǒng)會如何參與和幫助實際工作 對業(yè)務(wù)實體、業(yè)務(wù)過程以及它們與系統(tǒng)之間交互的描述 利用業(yè)務(wù)概念限定了系統(tǒng)的解決方案分析模型。 系統(tǒng)模型（設(shè)計師視圖）： 關(guān)注軟件系統(tǒng)應(yīng)該的需要以及設(shè)計方法的選擇限制 對軟件系統(tǒng)的基本功能和設(shè)計空間的描述體系結(jié)構(gòu)。,2.4 Zachman 框架,Zachman矩陣的行 技術(shù)模型（構(gòu)建者視圖）： 關(guān)注程序 對軟件系統(tǒng)當(dāng)中控制邏輯、算法、I/O控制以及其他各種具體技術(shù)細(xì)節(jié)的描述描述詳細(xì)設(shè)計的

11、設(shè)計模型 組件模型（集成者視圖）： 關(guān)注組裝 對軟件系統(tǒng)的組件、接口以及編碼程序等內(nèi)容的描述 實際運行的系統(tǒng)： 描述系統(tǒng)投入使用后的實際狀況和在運行中的實際表現(xiàn)。,2.4 Zachman 框架,Zachman矩陣的列： 數(shù)據(jù)：對企業(yè)有重要意義的事物以及企業(yè)對這些事物的理解 功能：企業(yè)在業(yè)務(wù)中執(zhí)行的任務(wù)以及企業(yè)對任務(wù)的理解。 位置：組織活動和軟件系統(tǒng)的地理分布，以及它們與組織的其他方面的關(guān)聯(lián)。 人：在軟件系統(tǒng)被引入后會涉及的人員和組織 時間：系統(tǒng)內(nèi)的事件-事件關(guān)聯(lián)之間的時間因素，表現(xiàn)為業(yè)務(wù)的規(guī)劃調(diào)度、系統(tǒng)的事件響應(yīng)和控制結(jié)構(gòu)。 動機：該列針對的是企業(yè)建立目標(biāo)系統(tǒng)的動機，揭示了企業(yè)的目標(biāo)、目的、業(yè)

12、務(wù)規(guī)劃、知識架構(gòu)、思想路線和決策基礎(chǔ)。,2.4 Zachman 框架,Project scope,Analysis model,Design model,Coded program,Application System,Planing*,Analysis,Design,Implementation,Integration,Data Modeling,Behavior Modeling,Event Modeling,Business Rules,Network topologies,Organizational structure modeling,Business Model,2.4 Zach

13、man 框架,2.4 Zachman 框架,主要內(nèi)容,需求分析的根本任務(wù) 需求分析技術(shù) 需求分析方法 前期需求階段的建模與分析 需求分析的活動,3. 需求分析方法,傳統(tǒng)分析 沒有方法 (1950s) 依賴個體才智,依據(jù)個人習(xí)慣 缺乏結(jié)構(gòu)、不可重復(fù)、不可測量,冗長、混亂、偏頗、無結(jié)構(gòu)等等 結(jié)構(gòu)化分析 傳統(tǒng)結(jié)構(gòu)化分析 (late 1960s),現(xiàn)代結(jié)構(gòu)化分析 (late 1970s) 以數(shù)據(jù)流動為中心，以DFD為核心技術(shù)，輔助ERD,STD 信息工程 (late 1980s) 以數(shù)據(jù)知識結(jié)構(gòu)為基礎(chǔ)，ERD為核心技術(shù)，輔助DFD，STD, FDD, PD 面向?qū)ο蠓治?（1990s） 以對象為中心，

14、以UML（類圖）為核心技術(shù) 以全面思想革新為理想，以承繼結(jié)構(gòu)化技術(shù)為現(xiàn)實,3. 需求分析方法,結(jié)構(gòu)化分析,3. 需求分析方法,面向?qū)ο蠓治?主要內(nèi)容,需求分析的根本任務(wù) 需求分析技術(shù) 需求分析方法 前期需求階段的建模與分析 需求分析的活動,4. 前期需求階段的建模與分析,4. 前期需求階段的建模與分析,面向目標(biāo)的分析（Goal Oriented Analysis） 面向問題域的分析（Problem Domain Oriented Analysis） 領(lǐng)域分析（Domain Analysis） 企業(yè)建模（Enterprise Modeling）,4. 前期需求階段的建模與分析,面向問題域的分析

15、問題框架 特性 解決 框架分解與組合 基本思路 研究所有可能的問題域，從中發(fā)現(xiàn)一些重復(fù)出現(xiàn)的簡單問題類型 分析每一種問題框架的特性，確定問題的理解和解決方法 將問題框架的建立和分類系統(tǒng)化，以簡單的問題框架為基本單位，進行復(fù)雜問題的分解,4. 前期需求階段的建模與分析,領(lǐng)域分析,4. 前期需求階段的建模與分析,企業(yè)建模,主要用來理解組織的結(jié)構(gòu)、行為規(guī)則、目標(biāo)、重要成員的任務(wù)與職責(zé)、操縱的數(shù)據(jù)等等。企業(yè)建模利用企業(yè)的目標(biāo)、任務(wù)、策略、資源等來刻畫組織的行為，并依此來發(fā)現(xiàn)組織開發(fā)系統(tǒng)的目的，建立系統(tǒng)的業(yè)務(wù)需求,主要內(nèi)容,需求分析的根本任務(wù) 需求分析技術(shù) 需求分析方法 前期需求階段的建模與分析 需求分

16、析的活動,5. 需求分析的活動,5. 需求分析的活動需求細(xì)化,明確用戶需求的隱含因素 將從問題域和業(yè)務(wù)的角度表述的用戶需求等價的轉(zhuǎn)化為從軟件和技術(shù)的角度表述的系統(tǒng)需求 非功能需求也需要從高層次的表述方式轉(zhuǎn)化為一系列更加詳細(xì)和具體的需求表述 需求細(xì)化也會發(fā)現(xiàn)新的細(xì)節(jié)需求 需求已經(jīng)得了充分的理解，并且開發(fā)者已經(jīng)可以著手為其進行方案設(shè)計時停止細(xì)化過程 細(xì)化后的需求應(yīng)該被一一的標(biāo)識和記錄下來,5. 需求分析的活動需求細(xì)化,需求的記錄 標(biāo)識符（ID），每一條需求都應(yīng)該能夠通過ID唯一的標(biāo)識自己。 源頭（Source），要能夠回溯到需求的源頭，例如特定的涉眾。 理由（Rational），需求被提出的目的。

17、 優(yōu)先級（Priority），詳細(xì)情況見下一節(jié)。 成本（Cost），預(yù)估的實現(xiàn)成本。 風(fēng)險（Risk），實現(xiàn)該需求的過程中可能帶來的風(fēng)險。 可變性（Volatility），將來發(fā)生變化的可能性。,5. 需求分析的活動確定需求優(yōu)先級,累計投票 區(qū)域劃分 重要性。需求的不可或缺程度。 緊急性。需求的時間緊迫程度。 懲罰性。忽略需求會導(dǎo)致的懲罰程度。 成本。實現(xiàn)需求的代價。 風(fēng)險。需求實現(xiàn)中可能產(chǎn)生的風(fēng)險程度。,5. 需求分析的活動確定需求優(yōu)先級,Top-N N的取值是不受明確限制的，真正受限制的是Top-N個需求的實現(xiàn)代價總和 數(shù)據(jù)量化,5. 需求分析的活動需求協(xié)商,明確沖突的因素，避免情緒上的沖突 明確沖突的解決空間 確定最佳解決方案,本章小結(jié),需求分析是需求工程中最為重要和核心的活動，它對信息的建模是理解問題的關(guān)鍵，也是創(chuàng)建正確解決方案的關(guān)鍵 需求分析涉及很多的技術(shù)和方法，需求分析活動的有效執(zhí)行需要分析人員能夠掌握