《需求分析概述》PPT課件

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

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

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

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

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

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

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 對象約束語言Object Constraint Language 狀態(tài)圖State Chart Diagram,Next,2.1 常用需求分析技術(shù),技術(shù)的綜合運用 如何為各

9、個視角選擇需求分析技術(shù)？ 每一種需求分析技術(shù)都有自己的特點，具有在應用上的獨特性 如何實現(xiàn)它們之間的配合？ 只有通過多種需求分析技術(shù)的有機結(jié)合與集成才能充分的描述復雜應用,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、 目標/范圍（規(guī)劃者視圖） 關(guān)心軟件系統(tǒng)的成本和效益， 對最終系統(tǒng)的規(guī)模、形式、位置空間以及基本目標的粗略描述 規(guī)劃者視圖規(guī)定了項目的前景和范圍。 企業(yè)模型（所有者視圖）： 關(guān)心軟件系統(tǒng)會如何參與和幫助實際工作 對業(yè)務實體、業(yè)務過程以及它們與系統(tǒng)之間交互的描述 利用業(yè)務概念限定了系統(tǒng)的解決方案分析模型。 系統(tǒng)模型（設計師視圖）： 關(guān)注軟件系統(tǒng)應該的需要以及設計方法的選擇限制 對軟件系統(tǒng)的基本功能和設計空間的描述體系結(jié)構(gòu)。,2.4 Zachman 框架,Zachman矩陣的行 技術(shù)模型（構(gòu)建者視圖）： 關(guān)注程序 對軟件系統(tǒng)當中控制邏輯、算法、I/O控制以及其他各種具體技術(shù)細節(jié)的描述描述詳細設計的

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

12、務規(guī)劃、知識架構(gòu)、思想路線和決策基礎。,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)容,需求分析的根本任務 需求分析技術(shù) 需求分析方法 前期需求階段的建模與分析 需求分析的活動,3. 需求分析方法,傳統(tǒng)分析 沒有方法 (1950s) 依賴個體才智,依據(jù)個人習慣 缺乏結(jié)構(gòu)、不可重復、不可測量,冗長、混亂、偏頗、無結(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)為基礎，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)容,需求分析的根本任務 需求分析技術(shù) 需求分析方法 前期需求階段的建模與分析 需求分析的活動,4. 前期需求階段的建模與分析,4. 前期需求階段的建模與分析,面向目標的分析（Goal Oriented Analysis） 面向問題域的分析（Problem Domain Oriented Analysis） 領域分析（Domain Analysis） 企業(yè)建模（Enterprise Modeling）,4. 前期需求階段的建模與分析,面向問題域的分析

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

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

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