軟件工程概論-3-需求分析

軟件工程概論

SoftwareEngineering

賈恒彬李恒

E-mail:jiahengbin@E-mail:liheng@

第3章需求分析

軟件工程師所解決的問題往往十分復雜。尤其是

開發(fā)全新的系統(tǒng)時，了解問題的性質可能是非常困難

的。因此，搞清楚系統(tǒng)應該做什么也是困難的。

對系統(tǒng)應提供的服務和所受到的約束的描述就是

系統(tǒng)需求關心的內容，對服務和約束的發(fā)現(xiàn)、分析、

建立文檔、檢驗的過程叫做需求工程。

軟件需求分析是軟件生存周期中最關鍵一步。

第3章需求分析

■3.1軟件需求分析的基本概念

■3.2軟件需求

■3.3需求工程

■3.4圖形工具

■3.5驗證軟件需求

3.1軟件需求分析的基本概念

3.1.1需求分析定義

A百度百科的定義

所謂“需求分析”，是指對要解決的問題進行詳細的分析，弄清楚問題

的要求，包括需要輸入什么數(shù)據(jù)，要得到什么結果，最后應輸出什么?？梢?/p>

說，在軟件工程當中的“需求分析”就是確定要計算機“做什么”。

＞通俗的定義

在軟件工程中，需求分析指的是在建立一個新的或改變一個現(xiàn)存的電腦

系統(tǒng)時描寫新系統(tǒng)的目的、范圍和定義時所要做的所有的工作。需求分析是

軟件工程中的一個關鍵過程。

在這個過程中，系統(tǒng)分析員和軟件工程師確定顧客的需要，只有在確

定了這些需要后，他們才能夠分析和尋求新系統(tǒng)的解決方法。在軟件工程的

歷史中，很長時間里人們一直認為需求分析是整個軟件工程中最簡單的一個

步驟，但在過去十年中越來越多的人認識到它是整個過程中最關鍵的一個過

程。假如在需求分析時分析者們未能正確地認識到顧客的需要的話，那么最

后的軟件實際上不可能達到顧客的真正需要，或者軟件無法在規(guī)定的時間里

完工。

3.1.2軟件需求分析概述

＞軟件需求分析的任務

口軟件需求分析的任務是準確地定義未來系統(tǒng)的目

標，確定為了滿足用戶的需求，系統(tǒng)必須做什么

O用《需求規(guī)格說明書》規(guī)范的形式準確地表達

用戶的需求，以及對需求進行審查。

?需求分析的具體內容包括

□深入描述軟件的功能和性能

□確定軟件設計的約束

□確定軟件同其他系統(tǒng)元素的接口細節(jié)

□定義軟件的其他有效性需求

＞需求分析階段的產(chǎn)品——需求規(guī)格說明書

3.1.3軟件需求分析的任務

由于需求分析方法不同，描述形式不同。其實現(xiàn)步

驟如下圖所示：

理

解

導

需

抽象化出

邏輯模型求

一

表

實例化達

邏輯模型需

求

3.1.3軟件需求分析的任務

3.1.3軟件需求分析的任務

根據(jù)上述分析得知，需求分析的具體任務是：

1.確定系統(tǒng)的綜合要求

■確定系統(tǒng)功能要求一這是最主要的需求，確定系統(tǒng)必

須完成的所有功能。

?確定系統(tǒng)性能要求一應而就具體系統(tǒng)定，例如可靠性、

聯(lián)機系統(tǒng)的響應時間、存儲容量、安全性能等。

■確定系統(tǒng)運行要求一主要是對系統(tǒng)運行時的環(huán)境要求；

如系統(tǒng)軟件、數(shù)據(jù)庫管理系統(tǒng)、外存和數(shù)據(jù)通信接口等。

?將來可能提出的要求一對將來可能提出的擴充及修改

作預準備。

3.1.3軟件需求分析的任務

2.分析系統(tǒng)的數(shù)據(jù)要求

軟件系統(tǒng)本質上是信息處理系統(tǒng)，因此，必須考慮：

?數(shù)據(jù)（需要哪些數(shù)據(jù)、數(shù)據(jù)間聯(lián)系、數(shù)據(jù)性質、結

構）

■數(shù)據(jù)處理（處理的類型、處理的邏輯功能）

3.導出系統(tǒng)的邏輯模型——通常系統(tǒng)的邏輯模型用DFD

圖來描述。

4.修正系統(tǒng)的開發(fā)計劃——通過需求對系統(tǒng)的成本及進

度有了更精確的估算，可進一步修改開發(fā)計劃。

3.1.4需求分析原則

近幾年來已提出許多軟件需求分析與說明的方法，每一

種分析方法都有獨特的觀點和表示方法，但都適用下面的

基本原則。

1、能夠表達和理解問題的信息域和功能域

對于計算機程序處理的數(shù)據(jù)，其信息域包括信息流（如

下圖，即數(shù)據(jù)通過一個系統(tǒng)時的變化方式）、信息內容和

信息結構，而功能域反映上述三方面的控制信息。

結果數(shù)據(jù)

3.1.4需求分析原則

2、建立描述系統(tǒng)信息、功能和行為的模型

建立模型的過程是“逐步精化”的綜合分析的過程。

通過對模型的不斷深化認識，來達到對實際問題的深刻

認識。

3、能夠對問題進行分解和不斷細化，建立問題的層次

結構。

分解是為了降低問題的復雜性，增加問題的可解性和

可描述性。分解可以在同一個層次上進行（橫向分解），

也可以在多層次上進行（縱向分解）。

3.1.4需求分析原則

4、需要給出系統(tǒng)的邏輯視圖和物理視圖

軟件需求的邏輯視圖給出的是軟件要達到的功能和

要處理信息之間的關系，而不是實現(xiàn)的細節(jié)。

軟件需求的物理視圖給出的是處理功能和信息結構

的實際表現(xiàn)形式，這往往是由設備本身決定的。

請同學們特別注意：

需求分析只研究軟件系統(tǒng)“做什么？”，而不考慮

“怎樣做？”。

3.1.5需求分析方法

不同的開發(fā)方法，需求分析的方法也有所不同，常見的分

析方法有：

?功能分析方法

將系統(tǒng)看作若干功能模塊的集合，每個功能又可以分

解為若干子功能，子功能還可繼續(xù)分解，分解的結果已經(jīng)

是系統(tǒng)的雛形。

?結構化分析方法

是一種以數(shù)據(jù)、數(shù)據(jù)的封閉性為基礎，從問題空間到某

種表示的映射方法，由數(shù)據(jù)流圖（DFD圖）表示。

3.1.5需求分析方法

?信息建模法

是從數(shù)據(jù)的角度對現(xiàn)實世界建立模型的，基本工具是

E-R圖。

?面向對象的分析方法

面向對象的分析方法（00A）的關鍵是識別問題域內

的對象，分析它們之間的關系，并建立起模型。

3.1.5需求分析工作流程

i■切

|口求知折民

報告.開發(fā)計劃

BI*/■定系筑'

褥求補充；功卷，性食,少

?用戶，有其至

坤埴介超度等*求，聶

已有的

類惘軟

件

定

義

文

檔

板方法

就再定義文檔

，線麻&煙、

件定

3.2軟件需求

3.2.1需求定義

＞權威的定義（IEEE軟件工程標準詞匯表中的定義）

?用戶解決問題或達到目標所需要的條件或權能

?系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)范或其他正式規(guī)定

文檔所要具有的條件或權能

?反映上面兩條的文檔說明

IEEE公布的需求定義分別從用戶和開發(fā)者的角度闡明了什么是需求，需求

一方面反映了系統(tǒng)的外部行為，另一方面反映了系統(tǒng)的內部特性，反映的方式是

需求文檔。

＞通俗的定義

?需求是指明系統(tǒng)必須實現(xiàn)什么的規(guī)格說明，他描述了系統(tǒng)

的行為、特性或屬性，是在開發(fā)過程中對系統(tǒng)的約束。

3.2.1需求分類

軟件需求一般包括功能需求和非功能需求。

1、功能需求

包括對系統(tǒng)應該提供的服務、如何對輸入做出反

映以及系統(tǒng)在特定條件下的行為的描述。在某些

情況下，功能需求可能還需要聲明系統(tǒng)不應該做

布么。

3.2.1需求分類

2、非功能需求

＞非功能需求是對系統(tǒng)提供的服務或功能給出的約束。

包括時間約束、開發(fā)過程約束、標準等。

＞非功能需求比功能需求更關鍵

許多非功能需求關心的是系統(tǒng)的整體特性而不

是個別的系統(tǒng)特性。一個功能需求沒有滿足可能會

降低系統(tǒng)的能力，而一個非功能需求沒有滿足則可

能使整個系統(tǒng)無法使用

□例如：如果一個飛機系統(tǒng)不符合可靠性要求，它將不會被

批準飛行；如果一個實時控制系統(tǒng)無法滿足其性能需求，

控制功能可能根本無法使用

3.2.1需求分類

2、非功能需求

＞性能需求

軟件開發(fā)的技術性能指標，包括對存儲容量、運行時間

的限制、安全保密性要求等。

□例如：系統(tǒng)的最大客戶容量、運行的峰值速度、平均速率

、充分運行時最少需要多少內存、同步問題等

＞環(huán)境需求

對軟件系統(tǒng)運行時所處環(huán)境的要求，包括硬件方面、軟

件方面、使用方面等

＞可用性需求

人機界面友好、使用舒適、可理解性好、可修改性好

3.2.1需求分類

2、非功能需求

＞可移植性需求

?可靠性需求

在一定的環(huán)境下以用戶能夠接受的方式運行時所表現(xiàn)出

來的始終如一的能力。

?硬件方面：系統(tǒng)的平均失效時間、系統(tǒng)的平均故障間

隔時間、失效率

?軟件方面：出錯保障能力、健壯性、內部信息的一致

性、錯誤識別能力

＞資源使用需求：件運行時所需的數(shù)據(jù)、軟件、內存空

間等資源

＞軟件成本消耗與開發(fā)進度需求等

3.2.2高質量的軟件需求應該具備的特征

□完整性

■不能遺漏任何必要的需求

■每一項需求要完成的任務必須要描述清楚，以便開發(fā)人

員明白實現(xiàn)這項需求的所有信息，用戶能夠審查這項需

求描述的正確性

3.2.2高質量的軟件需求應該具備的特征

需求描述舉例

“如果電話A呼叫電話B并且電話B空閑，那么電

話B應該響鈴”

測試中出現(xiàn)問題：A呼叫空閑的B時，所有的鈴都響了

改進1：“如果A呼叫B并且B空閑，那么除B響鈴

夕卜，其他所有電話都不響鈴

測試中又出現(xiàn)問題：與此同時，c也有正當?shù)捻戔徖碛?/p>

改進2：在需求規(guī)格說明書的開頭加上，系統(tǒng)只

做需求規(guī)格說明書中要求做的事，而不做別的。

3.2.2高質量的軟件需求應該具備的特征

□無二義性

■不同的人員對需求的理解應該是一致的。一般情況下，

描述需求都使用自然語言，因此容易引起需求理解的二

義性。

3.2.2高質量的軟件需求應該具備的特征

□需求描述舉例

“發(fā)現(xiàn)任何不友好且?guī)в形粗蝿盏幕蛘哂锌?/p>

能在5分鐘內飛入空中禁區(qū)的飛行物時,要拉響

上述需求描述的是：

說明針對軍事系統(tǒng)中空中禁區(qū)受到入侵時的報警事件

討論：以下情況是否拉警報

1.有明確任務的不友好飛行物

2.無明確任務的不友好飛行物

3.2.2高質量的軟件需求應該具備的特征

□正確性

■每項需求都必須準確地反映用戶要完成的任務

口可行性

■每一個成功的軟件系統(tǒng)其解決方案都應該是可行的，可

行性體現(xiàn)在技術、經(jīng)濟、操作可行性

□必要性

■每項需求都應該是客戶所需要的，開發(fā)人員不要自作主

張?zhí)砑有枨?/p>

□劃分優(yōu)先級

■為每項需求按重要程度分配一個優(yōu)先級，有助于項目管

理者決沖突、安排階段性交付，在必要時作出功能取舍

,以最小的費用獲得產(chǎn)品最大的功能

3.2.2高質量的軟件需求應該具備的特征

□可驗證性

■例：系統(tǒng)目標：

”系統(tǒng)很好用，即使對于一個沒有經(jīng)驗的用戶，而

且應該使用戶錯誤降到最少”

可驗證的非功能需求：

“對一個沒有經(jīng)驗的用戶來說，經(jīng)過2小時的培訓應

該能夠使用系統(tǒng)的所有功能。在這樣的培訓之后，一個

有經(jīng)驗的用戶每天的出錯平均數(shù)不應超過2次”

3.2.2高質量的軟件需求應該具備的特征

■指定非功能需求的度量

理論上，非功能需求能夠量化，從而使其驗證更為可觀。

在實際過程中，對需求描述的量化通常是很困難的

性質度量方法

速度每秒鐘處理的事務，用戶/事件響應時間，屏幕刷新時間

規(guī)模K字節(jié)，RAM芯片數(shù)

易用性培訓時間，幫助國Hl數(shù)

可靠性失敗平均時間，無效的概率，失敗的發(fā)生率，有效性

魯棒性失敗之后的重啟次數(shù)，事件引起失敗的百分比，失敗中

數(shù)據(jù)崩潰的可能性

可移植性依賴于目標的語句百分比，目標系統(tǒng)數(shù)

3.2.3獲取需求的方法

＞訪談

訪談是最早開始使用的獲取用戶需求的技術，也是迄今

為止仍然廣泛使用的需求分析技術。

訪談有兩種基本形式，分別是正式的和非正式的訪談。

正式訪談時，系統(tǒng)分析員將提出一些事先準備好的具體

問題。

在非正式訪談中，分析員將提出一些用戶可以自由回答

的開放性問題，以鼓勵被訪問人員說出自己的想法。

3.2.3獲取需求的方法

＞面向數(shù)據(jù)流自頂向下求精

數(shù)據(jù)決定了需要的處理和算法，數(shù)據(jù)顯然是需求分析的

出發(fā)點，結構化分析方法就是面向數(shù)據(jù)流自頂向下逐步

求精進行需求分析的方法。

把一個復雜的問題劃分成若干小問題，然后再分別解

決，將問題的復雜性降低到人可以掌握的程度。分解的

方法可分層進行，方法原理是先考慮問題最本質的方面,

忽略細節(jié)，形成問題的高層概念。然后再逐層添加細節(jié)。

即在分層過程中采用不同程度的“抽象”級別，最高層

的問題最抽象，而低層的較為具體。

3.2.3獲取需求的方法

＞面向數(shù)據(jù)流自頂向下求精

X頂層

3.2.3獲取需求的方法

＞面向數(shù)據(jù)流自頂向下求精

當認為某一層比較復雜時到底應該劃分為多少個子系

統(tǒng)，針對不同的系統(tǒng)的處理不同。劃分的原則可以根據(jù)

業(yè)務工作的范圍、功能性質、被處理數(shù)據(jù)對象的特點。

一般情況下上面一些層的劃分往往按照業(yè)務類型劃分的

比較多，下面一些層往往按照功能的劃分比較多。

依照這個策略，對于任何復雜的系統(tǒng)，分析工作都可

以有計劃、有步驟及有條不紊地進行。

（雙方確定問題的綜合需求。、

這些需求包括功能需求（最主

需求工程要的需求）、性能需求、環(huán)境

3.3需求和用戶界面需求，另外還

3.3需求工程

需求和分析.問題識別

導出

需求描述

分析與綜合

需求有效性

系統(tǒng)模型

驗證編寫文檔

用戶需求和分析評審

系統(tǒng)需求

:需求文擋

露寫“需求說明書”，

雙方共同的理解與分析結果

3.3需求工程用規(guī)范的方式描述出來；

⑵編寫初步用戶使用手冊;

⑶編寫確認測試計劃；

需求和分析一()修改完善項目開發(fā)計劃;問題識別

導出

需求描述

分析與綜合

需求有效性

系統(tǒng)模型

驗證編寫文檔

用戶需求和

系統(tǒng)需求

需求文擋

3.3.1需求工程的定義

需求工程是指系統(tǒng)分析人員通過細致的調研分析，

準確地理解用戶的需求，將不規(guī)范的需求陳述轉化

成完整的需求定義，再將需求定義寫成需求規(guī)格說

明書以及需求審查的過程。

3.3.2需求工程的重要性

□事實

■需求工程處于或接近于軟件工程過程的開始階段，它提

供了軟件項目其余部分得以構建的根基。如果你在開發(fā)

的后期階段出錯，受到影響的僅僅是那些與后期階段相

關的工作，而修正錯誤通常也是相對簡單的事情。然而

,如果錯誤出現(xiàn)在接近開始的階段，而且并未立即予以

糾正，那么所有后續(xù)階段的工作都是在錯誤的基礎上進

行的。修正錯誤的代價將飛速增加，通常情況下重新開

發(fā)也許更為經(jīng)濟。

需求問題是造成軟件工程項目失敗的主要原因，這已

經(jīng)是一個不爭的事實。

3.3.2需求工程的重要性

需求錯誤放大示意圖

3.3.2需求工程的重要性

□有關軟件錯誤的一些事實

■在軟件生命周期中，一個錯誤發(fā)現(xiàn)的越晚，修復錯誤的

費用越高

■許多錯誤是潛伏的，并且在錯誤產(chǎn)生后很長一段時間才

被檢查出來

■在需求過程中產(chǎn)生很多的錯誤

■在需求階段，代表性的錯誤為疏忽、不一致和二義性

■需求錯誤是可以被檢查出來

□規(guī)模的大小是問題的關鍵（拿建筑作類比）

■花園棚發(fā)生傾斜（塞幾塊磚即可扶正，幾乎不需費用）

■房屋因地基不牢發(fā)生傾斜（打樁止陷，相當可觀的費用）

■高層建筑發(fā)生傾斜（最好不要讓它發(fā)生）

3.3.3需求工程的主要活動內容

軟件需求工程的主要活動內容包括:

□需求獲取

□需求分析

□編寫需求規(guī)格說明書

口需求審查

還有需求管理：包括需求變更控制、需求跟蹤等

需求獲取

需求獲取需要考慮的三個問題：

□應當收集什么信息；

能從什么來源中來收集；

可能通過什么機制或技術來收集

□問題1：需求獲取的信息

■問題的描述

■要求解決問題的列表

■用戶對系統(tǒng)的行為或結構施加的任何約束

需求獲取

□問題2：信息的主要來源

■客戶（實際的和潛在的）

■客戶的規(guī)格說明書

■任何原有的系統(tǒng)及其文檔

■原有系統(tǒng)的用戶

■新系統(tǒng)的潛在用戶

■原有產(chǎn)品（開發(fā)者的其他產(chǎn)品，執(zhí)行與可能要開發(fā)的產(chǎn)

品相似的功能

■競爭對手的產(chǎn)品

■應用領域專家

■相關的技術標準和法規(guī)

需求獲取

□問題3：需求獲取的技術

■背景資料閱讀

■面談

■調查表

■文檔檢查

■任務觀察

■討論分析

■頭腦風暴

■用例和場景

需求獲取

系統(tǒng)分析人員應該在調研前做充分的準備,

針對具體項目的特點設計一些問題和表格。在

實際項目中應該根據(jù)項目的規(guī)模、涉及的業(yè)務

領域，有針對性的設計一些特別的問題。

下面給出一組比較通用的調研問題供參考:

需求獲取

?調研的基本問題

□部門的名稱、人員數(shù)量和結構

部門發(fā)展或變化簡單介紹

□部門的主要任務

□業(yè)務處理流程

業(yè)務處理流程中涉及那些專業(yè)領域的知識

工作需要的審批流程是什么？

□主要算法描述

那些業(yè)務需要實時處理

那些業(yè)務需要交互操作

□部門各崗位的職責

需求獲取

部門接收哪些部門或外界的信息？信息內容和格

式要求是什么？

部門產(chǎn)生哪叱信息？

□部門產(chǎn)生的宿W、荏到哪些其他部門？格式要求是

什么？

對信息的輸入和輸出方式有要求嗎？輸入輸出設

備是什么

數(shù)據(jù)要求實時備份嗎？備份的設備是什么？時間

策略？

業(yè)務處理有高峰期嗎？高峰時間是什么時候？業(yè)

務量有多少？

現(xiàn)有的哪些設備要繼續(xù)使用？

對產(chǎn)品的運行環(huán)境有要求嗎？

需求獲取

對界面風格和操作方式有要求嗎？

在系統(tǒng)運行過程中允許停機嗎？

操作方式要根據(jù)操作環(huán)境和使用人員素質分類嗎

□需要的操作權限有哪些？

需要記錄系統(tǒng)操作運行日志嗎？

用戶有能力進行系統(tǒng)維護嗎？

□需要分布式處理嗎？

需要什么方式的用戶操作培訓？

□需要制作聯(lián)機幫助嗎？

需求獲取

?某出版社系統(tǒng)調查表

編號提出的問題

1您在哪個部門工作？

2出版業(yè)務的流程是什么？

3您每天都處理哪些文件、數(shù)據(jù)、報表？

4工作中手工處理特別麻煩的事情是什么？

5工作中手工處理什么問題解決不了？影響效率的問題有哪些？

6您認為提局工作效率，節(jié)省工作時間，減輕工作強度可米取哪些辦法？

7您的部門需要成本核算和統(tǒng)計的內容有哪些？

8您的部門采用計算機管理工作情況如何？

9如何改進業(yè)務流程使之更合理？

10那些問題是目前傳統(tǒng)手工方法根本無法解決的？

11出版社計算機管理信息系統(tǒng)需要解決什么問題？

需求分析

需求分析的任務就是借助于當前系統(tǒng)的邏輯模型導出目標

系統(tǒng)的邏輯模型，解決目標系統(tǒng)的“做什么”的問題。

需求分析的具體任務

＞獲得當前系統(tǒng)的物理模型

＞抽象出當前系統(tǒng)的邏輯模型

＞建立目標系統(tǒng)的邏輯模型

理

怎么做

解

模型化:抽象化

導

需

出

棗

一

表

達

具體化；實例化

（物理模型）r--------（邏輯模里）需

求

需求分析建立模型的過程示意圖

需求分析

■需求分析建立建模的過程（示例）

1.通過對現(xiàn)實環(huán)境的調查，獲得當前系統(tǒng)的物理模

型，如下圖是學生購買教材軟件系統(tǒng)的實際建立

模型過程分析。

學生購買教材的實際處理流程——當前系統(tǒng)物理模型

需求分析

■需求分析建立建模的過程（示例）（續(xù)）

2.去掉具體模型中的非本質因素，抽取現(xiàn)實系統(tǒng)的

實質，抽象出當前系統(tǒng)的邏輯模型。

領

書

L、

書

單

學

開

領f

生

書

單

，

學生購買教材的邏輯模型

需求分析

■需求分析建立建模的過程（示例）（續(xù)）

3.分析當前系統(tǒng)與目標系統(tǒng)的差別，建立目標系統(tǒng)

的邏輯模型

4.對目標系統(tǒng)的邏輯模型進行改進與優(yōu)化。

5.需求分析的驗證。

無效書單

計算機教材管理系統(tǒng)的邏輯模型

需求分析

■需求分析建模方法

軟件開發(fā)過程實質是：

人通過抽象、歸納把客

觀系統(tǒng)變換到軟件系統(tǒng),

并保證軟件系統(tǒng)的解等

價客觀系統(tǒng)的解；由于

客觀系統(tǒng)與軟件系統(tǒng)差

異很大，所以變換過程

必須通過一個中間過渡

系統(tǒng)。不同的軟件開發(fā)

模型采用不同的過渡系

統(tǒng)完成變換過程。

軟件系統(tǒng)的本質示意圖

需求分析

□結構化分析模型

結構分析方法也就是面向數(shù)據(jù)流的分析方法，它是最基本

的圖形模型是數(shù)據(jù)流圖和數(shù)據(jù)字典，在表示復雜數(shù)據(jù)模型時，

一般要求建立實體關系圖（ER模型）。另外也可建立狀態(tài)遷移

圖，ER模型是對數(shù)據(jù)對象的說明，而數(shù)據(jù)流圖是對加工說明，

也就是對數(shù)據(jù)對象的加工說明。狀態(tài)變遷圖是對控制信息的說

明。數(shù)據(jù)字典就是對系統(tǒng)的數(shù)據(jù)結構進行模型化的描述。

狀態(tài)變遷圖

（STD圖）

控制說明

需求分析

□結構化分析模型

■結構化分析方法是抽象模型的概念，按照軟

件內部數(shù)據(jù)傳遞、變換的關系，自頂向下逐

層分解，直到找到滿足功能要求的所有可實

現(xiàn)的軟件為止。

■抽象和分解是這個方法的主要手段，由于數(shù)

據(jù)傳遞與變換而形成的數(shù)據(jù)流，是這個方法

的主要依據(jù)。

D1庫存清單

▼庫存清單

12「

溥

溥

務

務

等

，1.12

新

倉庫更庫存信息1.3定貨報表

接受產(chǎn)生

庫

管理員存處理

事務清正貝報表

工

\J

定貨信息

定貨信息

D2定貨信息

定貨系統(tǒng)數(shù)據(jù)流圖

需求分析

□面向對象分析模型

面向對象分析建模型方法是當前使用最多的方法。主要由

現(xiàn)在都是采用面向對象語言編程。目前采用UML模型來建立其

分析模型結構。UML綜合其他幾種面向對象分析模型，采用很

多種模型方法從不同視角也描述軟件邏輯模型。比如，它包括

用例圖、類圖、順序圖，狀態(tài)圖、協(xié)作圖。其分化為類模型、

行為模型、關系模型，還有協(xié)作等模型。所以它有很多模型方

法來描述軟件結構。

支持需求分析的原型化方法

原型是指模擬某種產(chǎn)品的原始模型。在軟件開發(fā)

中，原型是軟件的一個早期可運行的版本，它反映最

終系統(tǒng)的部分重要特性。如果在獲得一組基本需求說

明后，通過快速分析構造出一個小型的軟件系統(tǒng)，滿

足用戶的基本要求。使得用戶可在試用原型系統(tǒng)的過

程中得到親身感受和受到啟發(fā)，做出反應和評價。然

后開發(fā)者根據(jù)用戶的意見對原型加以改進。隨著不斷

試驗、糾錯、使用、評價和修改，獲得新的原型版本

,如此周而復始，逐步減少分析和通信中的誤解，彌

補不足之處，進一步確定各種需求細節(jié)，適應需求的

變更，從而提高了最終產(chǎn)品的質量。

支持需求分析的原型化方法

1、開發(fā)原型系統(tǒng)原因

把建立原型系統(tǒng)作為一種可能采取的策略的主要理由

＞人類受認識能力局限，不能預先指定所有要求；

＞在用戶和系統(tǒng)分析員之間存在固有的通信鴻溝；

＞用戶需要“活的”系統(tǒng)模型，以便獲得實踐經(jīng)驗；

＞在開發(fā)過程中重復和反復是必要和不可避免的；

＞目前有快速建立原型系統(tǒng)的工具可供選用(

RationalRose)。

支持需求分析的原型化方法

1、開發(fā)原型系統(tǒng)原因

?在開發(fā)初期，要想得到一個完整準確的規(guī)格

說明不是一件容易的事。特別是對一些大型

的軟件項目。

?用戶往往對系統(tǒng)只有一個模糊的想法，很難

完全準確地表達對系統(tǒng)的全面要求。

＞軟件開發(fā)者對于所要解決的應用問題認識更

是模糊不清

支持需求分析的原型化方法

1、開發(fā)原型系統(tǒng)原因

＞隨著開發(fā)工作向前推進，用戶可能會產(chǎn)生新的

要求，或因環(huán)境變化，要求系統(tǒng)也能隨之變化

;開發(fā)者又可能在設計與實現(xiàn)的過程中遇到些

沒有預料到的實際困難，需要以改變需求來解

脫困境。

＞因此規(guī)格說明難以完善、需求的變更、以及通

信中的模糊和誤解，都會成為軟件開發(fā)順利推

進的障礙。

＞為解決這些問題，逐漸形成了軟件系統(tǒng)的快速

原型的概念。

支持需求分析的原型化方法

2、原型的分類

□廢棄型：先構造一個功能簡單而且質量要求不高的模型系

統(tǒng)，針對這個模型系統(tǒng)反復進行分析修改，形成比較好的

設計思想，據(jù)此設計出更加完整、準確、一致、可靠的最

終系統(tǒng)。系統(tǒng)構造完成后，原來的模型系統(tǒng)就廢棄不用。

■探索型：目的是要弄清對目標系統(tǒng)的要求，確定所希望的特性，并

探討多種方案的可行性。它主要針對開發(fā)目標模糊，用戶和開發(fā)者

對項目都缺乏經(jīng)驗的情況

-實驗型：用于大規(guī)模開發(fā)和實現(xiàn)之前，考核方案是否合適，規(guī)格說

明是否可靠

□追加型或演化型：先構造一個功能簡單而且質量要求不高

的模型系統(tǒng)，作為最終系統(tǒng)的核心，然后通過不斷地擴充

修改，逐步追加新要求，最后發(fā)展成為最終系統(tǒng)。

支持需求分析的原型化方法

3、原型類型的選擇

□系統(tǒng)結構：聯(lián)機事務處理系統(tǒng)，相互關聯(lián)的應用

系統(tǒng)適合于用原型化方法，而批處理、批修改等

結構不適宜用原型化方法

邏輯結構：有結構的系統(tǒng)，如操作支持系統(tǒng)、管

理信息系統(tǒng)、記錄管理系統(tǒng)等適合于用原型化方

法，而基于大量算法的系統(tǒng)不宜用原型化方法。

□用戶特征：不滿足于預先做系統(tǒng)定義說明，愿意

為定義和修改原型投資，不易肯定詳細需求，愿

意承擔決策的責任，準備積極參與的用戶是適合

于使用原型的用戶。

支持需求分析的原型化方法

3、原型類型的選擇（續(xù)）

□應用約束：對已經(jīng)運行系統(tǒng)的補充，不能用原型

化方法。

□項目管理：項目負責人愿意使用原型化方法，才

適合于用原型化的方法。

□項目環(huán)境：需求說明技術應當根據(jù)每個項目的實

際環(huán)境來選擇。

當系統(tǒng)規(guī)模很大、要求復雜、系統(tǒng)服務不清晰的

時候，在需求分析階段先開發(fā)一個系統(tǒng)原型是很

值得的。特別是當性能要求比較高時，在系統(tǒng)原

型上先做一些試驗也是很必要的。

支持需求分析的原型化方法

4、原型化分析的好處

＞增進軟件者和用戶對系統(tǒng)服務需求的理

解，使比較含糊的具有不確定性的軟件需

求（主要是功能）明確化。

＞軟件原型化方法提供了一種有力的學習

手段。

支持需求分析的原型化方法

4、原型化分析的好處

＞使用原型化方法，可以容易地確定系統(tǒng)

的性能，確認各項主要系統(tǒng)服務的可應用

性，確認系統(tǒng)設計的可行性，確認系統(tǒng)作

為產(chǎn)品的結果。

＞軟件原型的最終版本，有的可以原封不

動地成為產(chǎn)品，有的略加修改就可以成為

最終系統(tǒng)的一個組成部分，這樣有利于建

成最終系統(tǒng)。

支持需求分析的原型化方法

5、原型開發(fā)技術

□可執(zhí)行規(guī)格說明

基于場景的設計

□自動程序設計

專用語言

□軟件復用技術

□簡化假設

3.3,3.3編寫需求規(guī)格說明書

■需求規(guī)格說明書

需求工程最大的成果是得到需求規(guī)格說明書。

□需求規(guī)格說明書是軟件產(chǎn)品開發(fā)過程中唯一與用

戶共同協(xié)商、共同起草的一個文件，它包含了用

戶方和開發(fā)方兩方面的意見，

需求規(guī)格說明書作為系統(tǒng)開發(fā)各方的共識，是對

系統(tǒng)進行設計、實現(xiàn)、測試和驗收的基本依據(jù)

■項目經(jīng)理根據(jù)它制定開發(fā)計劃

■設計人員根據(jù)它進行系統(tǒng)設計

■測試人員根據(jù)它編寫測試計劃、設計測試用例

■維護人員根據(jù)它理解系統(tǒng)及其中的各個部分間的關系

■用戶根據(jù)它進行系統(tǒng)的驗收，檢查系統(tǒng)是否符合要求

編寫需求規(guī)格說明書

■制定軟件需求規(guī)格說明的原則

□原則1：功能與實現(xiàn)分離，即描述要“做什么”而

不是“怎樣實現(xiàn)”。

□原則2：要求使用面向處理的規(guī)格說明語言，討論來

自環(huán)境的各種刺激可能導致系統(tǒng)做出什么樣的功能性

反應，來定義一個行為模型，從而得到“做什么”的

規(guī)格說明。

□原則3：如果目標軟件只是一個大系統(tǒng)中的一個元素

,那么整個大系統(tǒng)也包括在規(guī)格說明的描述之中。描

述該目標軟件與系統(tǒng)的其他系統(tǒng)元素交互的方式。

□原則4：規(guī)格說明必須包括系統(tǒng)運行的環(huán)境。

□原則5：系統(tǒng)規(guī)格說明必須是一個認識的模型，而不

是設計或實現(xiàn)的模型。

編寫需求規(guī)格說明書

■制定軟件需求規(guī)格說明的原則

□原則6：規(guī)格說明必須是可操作的規(guī)格說明必須是

充分完全和形式的，以便能夠利用它決定對于任意給

定的測試用例，已提出的實現(xiàn)方案是否都能滿足規(guī)格

說明。

□原則7：規(guī)格說明必須容許不完備性并允許擴充。

□原則8：規(guī)格說明必須局部化和松散的耦合。它所包

括的信息必須局部化，這樣當信息被修改時，只要修

改某個單個的段落（理想情況）。同時，規(guī)格說明應

被松散地構造（即耦合），以便能夠很容易地加入和

刪去一些段落。

3.3,3.3編寫需求規(guī)格說明書

■需求規(guī)格說明書框架

1引言

2任務描述

3數(shù)據(jù)描述

4功能需求

5性能需求

6運行需求

7其他需求

3.3?3.4需求審查

■需求審查的主要內容

系統(tǒng)定義的目標是否與用戶的要求一致

系統(tǒng)需求分析階段提供的文檔資料是否齊全

□文檔中的所有描述是否完整、清晰、準確反映用

戶要求

與所有其他系統(tǒng)成分的重要接口是否都已經(jīng)描述

□被開發(fā)項目的數(shù)據(jù)流與數(shù)據(jù)結構是否足夠，確定

□所有圖表是否清楚，在不補充說明時能否理解

□主要功能是否已包括在規(guī)定的軟件范圍之內，是

否都已充分說明

軟件的行為和它必須處理的信息、必須完成的功

能是否一致；

3.3?3.4需求審查

■需求審查的主要內容

設計的約束條件或限制條件是否符合實際

是否考慮了開發(fā)的技術風險

是否考慮過軟件需求的其他方案

是否考慮過將來可能會提出的軟件需求

是否詳細制定了檢驗標準，它們能否對系統(tǒng)定義

是否成功進行確認

□有沒有遺漏，重復或不一致的地方

用戶是否審查了初步的用戶手冊或原型

□軟件開發(fā)計劃中的估算是否受到了影響。

3.4圖形工具

＞在描繪復雜關系時，圖形比文字敘述優(yōu)越得多，它

形象直觀。

＞本節(jié)簡要介紹需求分析階段可能用到的三種圖形工

具。

3.4.1層次方框圖

＞層次方框圖用樹形結構的一系列多層次的矩形框描

述數(shù)據(jù)的層次結構。

＞樹形結構的頂層是一個單獨的矩形框，它代表完整

的數(shù)據(jù)結構，下面的各層矩形框代表這個數(shù)據(jù)的子

集，最底層的各個框代表組成這個數(shù)據(jù)的實際數(shù)據(jù)

元素（不能再分割的元素）。

3.4.1層次方框圖

＞隨著結構的精細化，層次方框圖對數(shù)據(jù)結構的描

繪也越來越詳細，這種模式非常適合于需求分析

階段的需要。

?系統(tǒng)分析員從對頂層信息的分類開始，沿圖中每

條路徑反復細化，直到確定了數(shù)據(jù)結構的全部細

節(jié)為止。

例如，描繪一家計算機公司全部產(chǎn)品的數(shù)據(jù)結構可

以用層次方框圖表示。

3.4.1層次方框圖

定貨報表

零件

編號

定貨報表的層次方框圖

3.4.2Warnier圖

＞法國計算機科學家Warnier提出了表示信息層次結構

的另一種圖形工具，比層次方框圖提供了更豐富的

手段。

＞用Warnier圖可以表明信息的邏輯組織，也就是說,

它可以指出一類信息或一個信息量是重復出現(xiàn)的，

也可以表示特定信息在某一類信息中是有條件地出

現(xiàn)的。

3.4.2Warnier圖

A花括號：區(qū)分數(shù)據(jù)結構的層次，在一個花括號內的

所有名字都屬于同一類信息。

＞異或符號十：表明一類信息或一個數(shù)據(jù)元素在一定

條件下才出現(xiàn)，而且在這個符號上、下方的兩個名

字所代表的數(shù)據(jù)只能出現(xiàn)一個。

＞圓括號：中間的數(shù)字指明了這個名字代表的信息類

（或元素）在這個數(shù)據(jù)結構中重復出現(xiàn)的次數(shù)。

零件編號一——字符(8)

零件名稱一——字符(1,20)

定貨數(shù)量一——整數(shù)。5)

目前價格一——實數(shù)

定貨報表<廠供電商編號-------字符(8)

主要供應商<供及商名稱----字符(1,20)

〔供應商地址-----字符(1,50)

「供應商編號-----字符(8)

,次要供應商

<供成商名稱----字符(1,20)

〔供應商地址-----字符(1,50)

定貨報表的Warnier圖

3.4.3IPO圖

＞IPO圖是輸入/處理/輸出圖的簡稱，它是美國

舊M公司發(fā)展完善起來的一種圖形工具，能夠方

便地描繪輸入數(shù)據(jù)、數(shù)據(jù)處理和輸出數(shù)據(jù)之間

的關系。

＞左框：列出輸入數(shù)據(jù)。

＞中框：列出主要的處理（次序暗示了執(zhí)行的順

序）。

＞右框：列出輸出數(shù)據(jù)

＞粗大箭頭：指出數(shù)據(jù)通信的情況。

343IPO圖

?A

圖3.5IPO圖的一個例子

343IPO圖

圖3.6改進的卬0圖的形式

343IPO圖

＞在需求分析階段可以使用IPO圖簡略地描述系統(tǒng)的

主要算法（即數(shù)據(jù)流圖中各個處理的基本算法）。

＞當然，在需求分析階段，IPO圖中的許多附加信息

暫時還不具備，但是在軟件設計階段可以進一步補

充修正這些圖，作為設計階段的文檔。

3.5軟件需求驗證

3.5.1從哪些方面驗證軟件需求的正確性

軟件系統(tǒng)中15%的錯誤起源于錯誤的需求，

因此，應該從下述4個方面進行驗證：

(1)一致性，需求不能和其他需求互相矛盾。

(2)完整性，規(guī)格說明書應該包括用戶需要

的每一個功能或性能。

(3)現(xiàn)實性，指定的需求應該是用現(xiàn)有的硬

件技術和軟件技術基本上可以實現(xiàn)的。

(4)有效性，必須證明需求是正確有效的，

確實能解決用戶面對的問題。

3.5.2軟件需求驗證方法

1.驗證需求的一致性

自然語言書寫的需求，除了靠人工技術審查驗

證軟件系統(tǒng)規(guī)格說明書的正確性之外，目前還沒

有其他更好的“測試”方法。

由于人工審查的效果是沒有保證的，冗余、遺

漏和不一致等問題可能沒被發(fā)現(xiàn)而繼續(xù)保留下來

,以致軟件開發(fā)不能在正確的基礎上順利進行。

形式化的描述軟件需求的方法較好地彌補了上

述缺點。

3.5.2軟件需求驗證方法

2.驗證需求的現(xiàn)實性

為了驗證需求的現(xiàn)實性，分析員應該參照以往

開發(fā)類似系統(tǒng)的經(jīng)驗，分析用現(xiàn)有的軟、硬件技

術實現(xiàn)目標系統(tǒng)的可能性。必要的時候應該采用

仿真或性能模擬技術，輔助分析軟件需求規(guī)格說

明書的現(xiàn)實性。

3.5.2軟件需求驗證方法

3.驗證需求的完整性和有效性

只有目標系統(tǒng)的用戶才真正知道軟件需求規(guī)格

說明書是否完整、準確地描述了他們的需求。

然而許多用戶只有當他們有某種工作著的軟件

系統(tǒng)可以實際使用和評價時，才能完整確切地提

出他們的需要。

使用原型系統(tǒng)是一個比較現(xiàn)實的方法。

3.5.3需求評審

基線需求文檔

附1需求管理

■需求管理是一組用于幫助項目組在項目進展中的

任何時候去標識、控制和跟蹤需求的活動

■需求跟蹤有兩種方式，正向跟蹤與逆向跟蹤

□正向跟蹤：以用戶需求為切入點，檢查《需求規(guī)約》

中的每個需求是否都能在后繼工作產(chǎn)品中找到對應點

□逆向跟蹤：檢查設計文檔、代碼、測試用況等工作產(chǎn)

品是否都能在《需求規(guī)約》中找到出處

需求管理

需求管理

變更控制版本控制需求跟蹤需求狀態(tài)跟蹤

?建議變更?確定需求文?定義對其它?定義需求狀

?分析影響檔的版本需求的鏈接態(tài)

?作出決策?確定需求文?定義對其它?跟蹤需求的

?交流檔的版本系統(tǒng)元素的每一個狀態(tài)

?合并邊接鏈

?測量需求的

穩(wěn)定性

附2實體?聯(lián)系圖（E?R圖）

1、兩個實體型之間的聯(lián)系

用圖形來表示兩個實體型之間的這三類聯(lián)系

1:1聯(lián)系l:n聯(lián)系m:n聯(lián)系

實體?聯(lián)系圖（E?R圖）

■一對一聯(lián)系（1:1）

□實例班級

一個班級只有一個正班長

一個班長只在一個班中任職

□定義：

如果對于實體集A中的每一個實體，實

體集B中至多有一個（也可以沒有）實體班長

與之聯(lián)系，反之亦然，則稱實體集A與實

體集B具有一對一聯(lián)系，記為1:1。1:1聯(lián)系

實體■聯(lián)系圖（E?R圖）

■，對多聯(lián)系（1：n）

□實例

一個班級中有若干名學生，

每個學生只在一個班級中學習

□定義：

如果對于實體集A中的每一個實體，實

體集B中有n個實體（心0）與之聯(lián)系，反之

,對于實體集B中的每一個實體，實體集A

中至多只有一個實體與之聯(lián)系，則稱實體集

A與實體集B有一對多聯(lián)系，記為1:n。l:n聯(lián)系

實體?聯(lián)系圖（E?R圖）

■多對多聯(lián)系（m:n）

□實例

課程與學生之間的聯(lián)系：

一門課程同時有若干個學生選修

一個學生可以同時選修多門課程

□定義：

如果對于實體集A中的每一個實體，實體集B

中有n個實體（論0）與之聯(lián)系，反之，對于實體集

B中的每一個實體，實體集A中也有m個實體（m?0

）與之聯(lián)系，則稱實體集A與實體B具有多對多聯(lián)系

，記為m:n。

m:n聯(lián)系

實體■聯(lián)系圖(E?R圖)

2、兩個以上實體型之間的聯(lián)系

■兩個以上實體型之間一對多聯(lián)系

□若實體集E1，E2,En存在聯(lián)系，對于實體集Ej

(j=1,2,i-1,i+1,n)中的給定實體，

最多只和Ej中的一個實體相聯(lián)系，則我們說E1與

,E2,EM,Ei+1,En之間的聯(lián)系是一對多

的。

實體?聯(lián)系圖（E?R圖）

■實例

課程、教師與參考書三個實體型

一門課程可以有若干個教師講

授，使用若干本參考書，每一個

教師只講授一門課程，每一本參

考書只供一門課程使用。

兩個以上實體型間

l:n聯(lián)系

實體?聯(lián)系圖（E?R圖）

■多個實體型間的一對一聯(lián)系

一對夫婦一個孩供應商

■兩個以上實體型間的多對多聯(lián)系

m

供應商、項目、零件三個實體型-k

一個供應商可以供給多個項目多種/供應

零件，每個項目可以使用多個供應商/

供應的零件每種零件可由不同供應口/

商供給。/

項目零件

兩個以上實體型間m:n聯(lián)系

實體■聯(lián)系圖（E?R圖）

3、ER圖-概念模型的一種表示方法

■實體一聯(lián)系方法（E-R方法）

□用E-R圖來描述現(xiàn)實世界的概念模型

E-R方法也稱為E-R模型

實體?聯(lián)系圖（E?R圖）

■實體型

用矩形表示，矩形框內寫明實體名。

學生教師

■屬性

用橢圓形表示，并用無向邊將其與相應的實體連

接起來

學生

實體■聯(lián)系圖（E?R圖）

■聯(lián)系

□聯(lián)系本身：

用菱形表示，菱形框內寫明聯(lián)系名，并用無向邊分

別與有關實體連接起來，同時在無向邊旁標上聯(lián)系的類

型（1:1、1:n或m:n）。

實體?聯(lián)系圖（E?R圖）

■聯(lián)系的表示方法

1:1聯(lián)系l:n聯(lián)系m:n聯(lián)系

實體?聯(lián)系圖（E?R圖）

■聯(lián)系的表示方法示例

1:1聯(lián)系l:n聯(lián)系m:n聯(lián)系

實體■聯(lián)系圖（E?R圖）

?:?聯(lián)系的屬性：

課程

聯(lián)系本身也是一種實體型，也

可以有屬性。如果一個聯(lián)系具有屬

性，則這些屬性也要用無向邊與該

聯(lián)系連接起來。

學生

實體?聯(lián)系圖（E?R圖）

4、一個實例

用E-R圖表示某個工廠物資管理的概念模型

■實體

倉庫：倉庫號、面積、電話號碼

零件：零件號、名稱、規(guī)格、單價、描述

□供應商：供應商號、姓名、地址、電話號碼、帳號

□項目：項目號、預算、開工日期

□職工：職工號、姓名、年齡、職稱

實體■聯(lián)系圖（E?R圖）

■實體之間的聯(lián)系如下：

（1）一個倉庫可存放多種零件，一種零件可以存放在多個

倉庫中。倉庫和零件具有多對多的聯(lián)系。用庫存量來表示某

種零件在某個倉庫中的數(shù)量。

（2）一個倉庫有多個職工當倉庫保管員，一個職工只能在

一個倉庫工作，倉庫和職工之間是一對多的聯(lián)系。職工實體

型中具有一對多的聯(lián)系。

實體■聯(lián)系圖(E?R圖)

(3)職工之間具有領導-被領導關系。即倉庫主任領導若

干保管員。

(4)供應商、項目和零件三者之間具有多對多的聯(lián)系。

實體?聯(lián)系圖(E?R圖)

(S)(電話號碼)

儂應商吩3庫而(ML)@話號碼)瓢(w)

(W)

(c)完整的實體-聯(lián)系圖

面向數(shù)據(jù)流的分析過程

■任何信息處理系統(tǒng)的基本功能都是把輸入數(shù)

據(jù)轉變成需要的輸出信息。

■數(shù)據(jù)決定了需要的處理和算法，看來數(shù)據(jù)顯

然是分析的出發(fā)點。

■結構化分析方法（簡稱SA方法）就是面向數(shù)

據(jù)流自頂向下逐步求精進行需求分析的方法

面向數(shù)據(jù)流的分析過程

■通過可行性研究已經(jīng)得出了目標系統(tǒng)的高層

數(shù)據(jù)流圖，需求分析的目的之一就是把數(shù)據(jù)

流和數(shù)據(jù)存儲定義到元素級。

■為了達到這個目的，通常從數(shù)據(jù)流圖的輸出

端著手分析，這是因為系統(tǒng)的目標是產(chǎn)生這

些輸出，輸出數(shù)據(jù)確定了系統(tǒng)必須具有的最

基本的組成元素。

1、沿數(shù)據(jù)流圖回溯

■輸出數(shù)據(jù)是由哪些元素組成的呢?

■每個輸出數(shù)據(jù)元素又是從哪里來的呢？

■沿數(shù)據(jù)流圖從輸出端往輸入端回溯，應該能

夠確定每個數(shù)據(jù)元素的來源，與此同時也就

初步定義了有關的算法。

1、沿數(shù)據(jù)流圖回溯

■沿數(shù)據(jù)流圖回溯時常常遇到下述問題：

1.為了得到某個數(shù)據(jù)元素需要用到數(shù)據(jù)流圖中

目前還沒有的數(shù)據(jù)元素；

2.或者得出這個數(shù)據(jù)元素需要用的算法尚不完

全清楚。

1、沿數(shù)據(jù)流圖回溯

■為了解決這些問題，往往需要向用戶和其他

有關人員請教；

■他們的回答使分析員對目標系統(tǒng)的認識更深

入更具體了，系統(tǒng)中更多的數(shù)據(jù)元素被劃分

出來了，更多的算法被搞清楚了。

1、沿數(shù)據(jù)流圖回溯

■通常把分析過程中得到的有關數(shù)據(jù)元素的信

息記錄在數(shù)據(jù)字典中，把對算法的簡明描述

記錄在IPO圖中。

■通過分析而補充的數(shù)據(jù)流、數(shù)據(jù)存儲和處理

,應該添加到數(shù)據(jù)流圖的適當位置上。

2、用戶復查

■從輸入端開始，分析員借助數(shù)據(jù)流圖以及數(shù)

據(jù)字典和簡明的算法描述向用戶解釋輸入數(shù)

據(jù)是怎樣一步一步地轉變成輸出數(shù)據(jù)的。

■用戶應該注意傾聽分析員的報告，并及時糾

正和補充分析員的認識。復查過程驗證了已

知的元素，補充了未知的元素，填補了文檔

中的空白。

2、用戶復查

■追蹤數(shù)據(jù)流圖和復查系統(tǒng)的邏輯模型這兩個

步驟實質上構成一個循環(huán)。

■在分析員對目標系統(tǒng)的認識螺旋式上升的過

程中，用戶及其他和系統(tǒng)有關的人員的參與

是必不可少的：分析過程中產(chǎn)生的問題依靠

他們來回答，分析員對系統(tǒng)的更深入的認識

必須經(jīng)過他們的檢驗和確認。

3、細化數(shù)據(jù)流圖

■通過功能分解可以完成數(shù)據(jù)流圖的細化。

■在數(shù)據(jù)流圖中選出一個功能比較復雜的處

理，并把它的功能分解成若干個子功能，

這些較低層的子功能成為一張新數(shù)據(jù)流圖

上的處理，在這張新數(shù)據(jù)流圖上還應該包

括自己的數(shù)據(jù)存儲和數(shù)據(jù)流。

3、細化數(shù)據(jù)流圖

■分層細化的兩條原則：

1.第一，在分層細化時必須保持信息連續(xù)性，

也就是說細化前后對應功能的輸入/輸出數(shù)

據(jù)必須相同；

2.第二，當進一步細化將涉及如何具體地實現(xiàn)

一個功能時，就不應該再分解了。

3、細化數(shù)據(jù)流圖

■下圖粗略地概括了上述分析過程：

3/1、分層數(shù)據(jù)流圖的畫法

1.畫系統(tǒng)的輸入和輸出

■把整個軟件系統(tǒng)看作一個大的加工，然后根

據(jù)系統(tǒng)從外界的哪些源點接受哪些數(shù)據(jù)流，

以及系統(tǒng)的哪些數(shù)據(jù)流送到外界的哪些終點

,就可畫出系統(tǒng)的輸入和輸出圖。

■這張圖稱為頂層圖。

3」、分層數(shù)據(jù)流圖的畫法

2.畫系統(tǒng)的內部

■將頂層圖中的加工分解成若干個加工，并用數(shù)據(jù)

流將這些加工連接起來，使得頂層圖中的輸入數(shù)

據(jù)流經(jīng)一連串的加工處理后變換成頂層圖的輸出

數(shù)據(jù)流。

■這張圖稱為0層圖。從一個加工畫出一張數(shù)據(jù)流圖

的過程實際上就是對這個加工的分解過程。

3/1、分層數(shù)據(jù)流圖的畫法

可用下述的方法來確定加工：

■在數(shù)據(jù)流的組成或值發(fā)生變化的地方應畫一

個加工，這個加工的功能就是實現(xiàn)這一變化

■也可根據(jù)系統(tǒng)的功能確定加工。

3」、分層數(shù)據(jù)流圖的畫法

確定數(shù)據(jù)流的方法可以是：

■當用戶把若干個數(shù)據(jù)看作一個單位來處理（

這些數(shù)據(jù)一起到達，一起加工）時，把這些

數(shù)據(jù)看成一個數(shù)據(jù)流。

■通常可以把實際工作中的單據(jù)（如報名單）

作為一個數(shù)據(jù)流。

■對于一些以后某個時間要使用的數(shù)據(jù)可組織

成一個數(shù)據(jù)（文件）存儲。

3」、分層數(shù)據(jù)流圖的畫法

3.畫加工的內部

■我們把每個加工看作一個小系統(tǒng)，該加工的