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

軟件工程概論

SoftwareEngineering

賈恒彬李恒

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

第3章需求分析

軟件工程師所解決的問(wèn)題往往十分復(fù)雜。尤其是

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

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

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

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

建立文檔、檢驗(yàn)的過(guò)程叫做需求工程。

軟件需求分析是軟件生存周期中最關(guān)鍵一步。

第3章需求分析

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

■3.2軟件需求

■3.3需求工程

■3.4圖形工具

■3.5驗(yàn)證軟件需求

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

3.1.1需求分析定義

A百度百科的定義

所謂“需求分析”，是指對(duì)要解決的問(wèn)題進(jìn)行詳細(xì)的分析，弄清楚問(wèn)題

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

說(shuō)，在軟件工程當(dāng)中的“需求分析”就是確定要計(jì)算機(jī)“做什么”。

＞通俗的定義

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

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

軟件工程中的一個(gè)關(guān)鍵過(guò)程。

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

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

歷史中，很長(zhǎng)時(shí)間里人們一直認(rèn)為需求分析是整個(gè)軟件工程中最簡(jiǎn)單的一個(gè)

步驟，但在過(guò)去十年中越來(lái)越多的人認(rèn)識(shí)到它是整個(gè)過(guò)程中最關(guān)鍵的一個(gè)過(guò)

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

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

完工。

3.1.2軟件需求分析概述

＞軟件需求分析的任務(wù)

口軟件需求分析的任務(wù)是準(zhǔn)確地定義未來(lái)系統(tǒng)的目

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

O用《需求規(guī)格說(shuō)明書》規(guī)范的形式準(zhǔn)確地表達(dá)

用戶的需求，以及對(duì)需求進(jìn)行審查。

?需求分析的具體內(nèi)容包括

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

□確定軟件設(shè)計(jì)的約束

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

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

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

3.1.3軟件需求分析的任務(wù)

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

驟如下圖所示：

理

解

導(dǎo)

需

抽象化出

邏輯模型求

一

表

實(shí)例化達(dá)

邏輯模型需

求

3.1.3軟件需求分析的任務(wù)

3.1.3軟件需求分析的任務(wù)

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

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

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

須完成的所有功能。

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

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

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

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

?將來(lái)可能提出的要求一對(duì)將來(lái)可能提出的擴(kuò)充及修改

作預(yù)準(zhǔn)備。

3.1.3軟件需求分析的任務(wù)

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

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

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

構(gòu)）

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

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

圖來(lái)描述。

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

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

3.1.4需求分析原則

近幾年來(lái)已提出許多軟件需求分析與說(shuō)明的方法，每一

種分析方法都有獨(dú)特的觀點(diǎn)和表示方法，但都適用下面的

基本原則。

1、能夠表達(dá)和理解問(wèn)題的信息域和功能域

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

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

信息結(jié)構(gòu)，而功能域反映上述三方面的控制信息。

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

3.1.4需求分析原則

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

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

通過(guò)對(duì)模型的不斷深化認(rèn)識(shí)，來(lái)達(dá)到對(duì)實(shí)際問(wèn)題的深刻

認(rèn)識(shí)。

3、能夠?qū)?wèn)題進(jìn)行分解和不斷細(xì)化，建立問(wèn)題的層次

結(jié)構(gòu)。

分解是為了降低問(wèn)題的復(fù)雜性，增加問(wèn)題的可解性和

可描述性。分解可以在同一個(gè)層次上進(jìn)行（橫向分解），

也可以在多層次上進(jìn)行（縱向分解）。

3.1.4需求分析原則

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

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

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

軟件需求的物理視圖給出的是處理功能和信息結(jié)構(gòu)

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

請(qǐng)同學(xué)們特別注意：

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

“怎樣做？”。

3.1.5需求分析方法

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

析方法有：

?功能分析方法

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

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

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

?結(jié)構(gòu)化分析方法

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

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

3.1.5需求分析方法

?信息建模法

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

E-R圖。

?面向?qū)ο蟮姆治龇椒?/p>

面向?qū)ο蟮姆治龇椒ǎ?0A）的關(guān)鍵是識(shí)別問(wèn)題域內(nèi)

的對(duì)象，分析它們之間的關(guān)系，并建立起模型。

3.1.5需求分析工作流程

i■切

|口求知折民

報(bào)告.開發(fā)計(jì)劃

BI*/■定系筑'

褥求補(bǔ)充；功卷，性食,少

?用戶，有其至

坤埴介超度等*求，聶

已有的

類惘軟

件

定

義

文

檔

板方法

就再定義文檔

，線麻&煙、

件定

3.2軟件需求

3.2.1需求定義

＞權(quán)威的定義（IEEE軟件工程標(biāo)準(zhǔn)詞匯表中的定義）

?用戶解決問(wèn)題或達(dá)到目標(biāo)所需要的條件或權(quán)能

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

文檔所要具有的條件或權(quán)能

?反映上面兩條的文檔說(shuō)明

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

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

需求文檔。

＞通俗的定義

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

的行為、特性或?qū)傩裕窃陂_發(fā)過(guò)程中對(duì)系統(tǒng)的約束。

3.2.1需求分類

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

1、功能需求

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

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

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

布么。

3.2.1需求分類

2、非功能需求

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

包括時(shí)間約束、開發(fā)過(guò)程約束、標(biāo)準(zhǔn)等。

＞非功能需求比功能需求更關(guān)鍵

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

是個(gè)別的系統(tǒng)特性。一個(gè)功能需求沒(méi)有滿足可能會(huì)

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

能使整個(gè)系統(tǒng)無(wú)法使用

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

批準(zhǔn)飛行；如果一個(gè)實(shí)時(shí)控制系統(tǒng)無(wú)法滿足其性能需求，

控制功能可能根本無(wú)法使用

3.2.1需求分類

2、非功能需求

＞性能需求

軟件開發(fā)的技術(shù)性能指標(biāo)，包括對(duì)存儲(chǔ)容量、運(yùn)行時(shí)間

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

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

、充分運(yùn)行時(shí)最少需要多少內(nèi)存、同步問(wèn)題等

＞環(huán)境需求

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

件方面、使用方面等

＞可用性需求

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

3.2.1需求分類

2、非功能需求

＞可移植性需求

?可靠性需求

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

來(lái)的始終如一的能力。

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

隔時(shí)間、失效率

?軟件方面：出錯(cuò)保障能力、健壯性、內(nèi)部信息的一致

性、錯(cuò)誤識(shí)別能力

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

間等資源

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

3.2.2高質(zhì)量的軟件需求應(yīng)該具備的特征

□完整性

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

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

員明白實(shí)現(xiàn)這項(xiàng)需求的所有信息，用戶能夠?qū)彶檫@項(xiàng)需

求描述的正確性

3.2.2高質(zhì)量的軟件需求應(yīng)該具備的特征

需求描述舉例

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

話B應(yīng)該響鈴”

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

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

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

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

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

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

3.2.2高質(zhì)量的軟件需求應(yīng)該具備的特征

□無(wú)二義性

■不同的人員對(duì)需求的理解應(yīng)該是一致的。一般情況下，

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

義性。

3.2.2高質(zhì)量的軟件需求應(yīng)該具備的特征

□需求描述舉例

“發(fā)現(xiàn)任何不友好且?guī)в形粗蝿?wù)的或者有可

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

上述需求描述的是：

說(shuō)明針對(duì)軍事系統(tǒng)中空中禁區(qū)受到入侵時(shí)的報(bào)警事件

討論：以下情況是否拉警報(bào)

1.有明確任務(wù)的不友好飛行物

2.無(wú)明確任務(wù)的不友好飛行物

3.2.2高質(zhì)量的軟件需求應(yīng)該具備的特征

□正確性

■每項(xiàng)需求都必須準(zhǔn)確地反映用戶要完成的任務(wù)

口可行性

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

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

□必要性

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

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

□劃分優(yōu)先級(jí)

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

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

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

3.2.2高質(zhì)量的軟件需求應(yīng)該具備的特征

□可驗(yàn)證性

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

”系統(tǒng)很好用，即使對(duì)于一個(gè)沒(méi)有經(jīng)驗(yàn)的用戶，而

且應(yīng)該使用戶錯(cuò)誤降到最少”

可驗(yàn)證的非功能需求：

“對(duì)一個(gè)沒(méi)有經(jīng)驗(yàn)的用戶來(lái)說(shuō)，經(jīng)過(guò)2小時(shí)的培訓(xùn)應(yīng)

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

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

3.2.2高質(zhì)量的軟件需求應(yīng)該具備的特征

■指定非功能需求的度量

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

在實(shí)際過(guò)程中，對(duì)需求描述的量化通常是很困難的

性質(zhì)度量方法

速度每秒鐘處理的事務(wù)，用戶/事件響應(yīng)時(shí)間，屏幕刷新時(shí)間

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

易用性培訓(xùn)時(shí)間，幫助國(guó)Hl數(shù)

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

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

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

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

3.2.3獲取需求的方法

＞訪談

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

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

訪談?dòng)袃煞N基本形式，分別是正式的和非正式的訪談。

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

問(wèn)題。

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

的開放性問(wèn)題，以鼓勵(lì)被訪問(wèn)人員說(shuō)出自己的想法。

3.2.3獲取需求的方法

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

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

出發(fā)點(diǎn)，結(jié)構(gòu)化分析方法就是面向數(shù)據(jù)流自頂向下逐步

求精進(jìn)行需求分析的方法。

把一個(gè)復(fù)雜的問(wèn)題劃分成若干小問(wèn)題，然后再分別解

決，將問(wèn)題的復(fù)雜性降低到人可以掌握的程度。分解的

方法可分層進(jìn)行，方法原理是先考慮問(wèn)題最本質(zhì)的方面,

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

即在分層過(guò)程中采用不同程度的“抽象”級(jí)別，最高層

的問(wèn)題最抽象，而低層的較為具體。

3.2.3獲取需求的方法

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

X頂層

3.2.3獲取需求的方法

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

當(dāng)認(rèn)為某一層比較復(fù)雜時(shí)到底應(yīng)該劃分為多少個(gè)子系

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

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

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

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

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

以有計(jì)劃、有步驟及有條不紊地進(jìn)行。

（雙方確定問(wèn)題的綜合需求。、

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

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

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

3.3需求工程

需求和分析.問(wèn)題識(shí)別

導(dǎo)出

需求描述

分析與綜合

需求有效性

系統(tǒng)模型

驗(yàn)證編寫文檔

用戶需求和分析評(píng)審

系統(tǒng)需求

:需求文擋

露寫“需求說(shuō)明書”，

雙方共同的理解與分析結(jié)果

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

⑵編寫初步用戶使用手冊(cè);

⑶編寫確認(rèn)測(cè)試計(jì)劃；

需求和分析一()修改完善項(xiàng)目開發(fā)計(jì)劃;問(wèn)題識(shí)別

導(dǎo)出

需求描述

分析與綜合

需求有效性

系統(tǒng)模型

驗(yàn)證編寫文檔

用戶需求和

系統(tǒng)需求

需求文擋

3.3.1需求工程的定義

需求工程是指系統(tǒng)分析人員通過(guò)細(xì)致的調(diào)研分析，

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

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

明書以及需求審查的過(guò)程。

3.3.2需求工程的重要性

□事實(shí)

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

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

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

關(guān)的工作，而修正錯(cuò)誤通常也是相對(duì)簡(jiǎn)單的事情。然而

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

糾正，那么所有后續(xù)階段的工作都是在錯(cuò)誤的基礎(chǔ)上進(jìn)

行的。修正錯(cuò)誤的代價(jià)將飛速增加，通常情況下重新開

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

需求問(wèn)題是造成軟件工程項(xiàng)目失敗的主要原因，這已

經(jīng)是一個(gè)不爭(zhēng)的事實(shí)。

3.3.2需求工程的重要性

需求錯(cuò)誤放大示意圖

3.3.2需求工程的重要性

□有關(guān)軟件錯(cuò)誤的一些事實(shí)

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

費(fèi)用越高

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

被檢查出來(lái)

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

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

■需求錯(cuò)誤是可以被檢查出來(lái)

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

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

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

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

3.3.3需求工程的主要活動(dòng)內(nèi)容

軟件需求工程的主要活動(dòng)內(nèi)容包括:

□需求獲取

□需求分析

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

口需求審查

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

需求獲取

需求獲取需要考慮的三個(gè)問(wèn)題：

□應(yīng)當(dāng)收集什么信息；

能從什么來(lái)源中來(lái)收集；

可能通過(guò)什么機(jī)制或技術(shù)來(lái)收集

□問(wèn)題1：需求獲取的信息

■問(wèn)題的描述

■要求解決問(wèn)題的列表

■用戶對(duì)系統(tǒng)的行為或結(jié)構(gòu)施加的任何約束

需求獲取

□問(wèn)題2：信息的主要來(lái)源

■客戶（實(shí)際的和潛在的）

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

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

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

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

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

品相似的功能

■競(jìng)爭(zhēng)對(duì)手的產(chǎn)品

■應(yīng)用領(lǐng)域?qū)＜?/p>

■相關(guān)的技術(shù)標(biāo)準(zhǔn)和法規(guī)

需求獲取

□問(wèn)題3：需求獲取的技術(shù)

■背景資料閱讀

■面談

■調(diào)查表

■文檔檢查

■任務(wù)觀察

■討論分析

■頭腦風(fēng)暴

■用例和場(chǎng)景

需求獲取

系統(tǒng)分析人員應(yīng)該在調(diào)研前做充分的準(zhǔn)備,

針對(duì)具體項(xiàng)目的特點(diǎn)設(shè)計(jì)一些問(wèn)題和表格。在

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

領(lǐng)域，有針對(duì)性的設(shè)計(jì)一些特別的問(wèn)題。

下面給出一組比較通用的調(diào)研問(wèn)題供參考:

需求獲取

?調(diào)研的基本問(wèn)題

□部門的名稱、人員數(shù)量和結(jié)構(gòu)

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

□部門的主要任務(wù)

□業(yè)務(wù)處理流程

業(yè)務(wù)處理流程中涉及那些專業(yè)領(lǐng)域的知識(shí)

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

□主要算法描述

那些業(yè)務(wù)需要實(shí)時(shí)處理

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

□部門各崗位的職責(zé)

需求獲取

部門接收哪些部門或外界的信息？信息內(nèi)容和格

式要求是什么？

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

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

什么？

對(duì)信息的輸入和輸出方式有要求嗎？輸入輸出設(shè)

備是什么

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

策略？

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

務(wù)量有多少？

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

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

需求獲取

對(duì)界面風(fēng)格和操作方式有要求嗎？

在系統(tǒng)運(yùn)行過(guò)程中允許停機(jī)嗎？

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

□需要的操作權(quán)限有哪些？

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

用戶有能力進(jìn)行系統(tǒng)維護(hù)嗎？

□需要分布式處理嗎？

需要什么方式的用戶操作培訓(xùn)？

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

需求獲取

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

編號(hào)提出的問(wèn)題

1您在哪個(gè)部門工作？

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

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

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

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

6您認(rèn)為提局工作效率，節(jié)省工作時(shí)間，減輕工作強(qiáng)度可米取哪些辦法？

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

8您的部門采用計(jì)算機(jī)管理工作情況如何？

9如何改進(jìn)業(yè)務(wù)流程使之更合理？

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

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

需求分析

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

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

需求分析的具體任務(wù)

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

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

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

理

怎么做

解

模型化:抽象化

導(dǎo)

需

出

棗

一

表

達(dá)

具體化；實(shí)例化

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

求

需求分析建立模型的過(guò)程示意圖

需求分析

■需求分析建立建模的過(guò)程（示例）

1.通過(guò)對(duì)現(xiàn)實(shí)環(huán)境的調(diào)查，獲得當(dāng)前系統(tǒng)的物理模

型，如下圖是學(xué)生購(gòu)買教材軟件系統(tǒng)的實(shí)際建立

模型過(guò)程分析。

學(xué)生購(gòu)買教材的實(shí)際處理流程——當(dāng)前系統(tǒng)物理模型

需求分析

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

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

實(shí)質(zhì)，抽象出當(dāng)前系統(tǒng)的邏輯模型。

領(lǐng)

書

L、

書

單

學(xué)

開

領(lǐng)f

生

書

單

，

學(xué)生購(gòu)買教材的邏輯模型

需求分析

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

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

的邏輯模型

4.對(duì)目標(biāo)系統(tǒng)的邏輯模型進(jìn)行改進(jìn)與優(yōu)化。

5.需求分析的驗(yàn)證。

無(wú)效書單

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

需求分析

■需求分析建模方法

軟件開發(fā)過(guò)程實(shí)質(zhì)是：

人通過(guò)抽象、歸納把客

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

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

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

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

異很大，所以變換過(guò)程

必須通過(guò)一個(gè)中間過(guò)渡

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

模型采用不同的過(guò)渡系

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

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

需求分析

□結(jié)構(gòu)化分析模型

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

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

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

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

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

明。數(shù)據(jù)字典就是對(duì)系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)進(jìn)行模型化的描述。

狀態(tài)變遷圖

（STD圖）

控制說(shuō)明

需求分析

□結(jié)構(gòu)化分析模型

■結(jié)構(gòu)化分析方法是抽象模型的概念，按照軟

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

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

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

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

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

的主要依據(jù)。

D1庫(kù)存清單

▼庫(kù)存清單

12「

溥

溥

務(wù)

務(wù)

等

，1.12

新

倉(cāng)庫(kù)更庫(kù)存信息1.3定貨報(bào)表

接受產(chǎn)生

庫(kù)

管理員存處理

事務(wù)清正貝報(bào)表

工

\J

定貨信息

定貨信息

D2定貨信息

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

需求分析

□面向?qū)ο蠓治瞿Ｐ?/p>

面向?qū)ο蠓治鼋Ｐ头椒ㄊ钱?dāng)前使用最多的方法。主要由

現(xiàn)在都是采用面向?qū)ο笳Z(yǔ)言編程。目前采用UML模型來(lái)建立其

分析模型結(jié)構(gòu)。UML綜合其他幾種面向?qū)ο蠓治瞿Ｐ?，采用?/p>

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

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

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

法來(lái)描述軟件結(jié)構(gòu)。

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

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

中，原型是軟件的一個(gè)早期可運(yùn)行的版本，它反映最

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

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

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

程中得到親身感受和受到啟發(fā)，做出反應(yīng)和評(píng)價(jià)。然

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

試驗(yàn)、糾錯(cuò)、使用、評(píng)價(jià)和修改，獲得新的原型版本

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

補(bǔ)不足之處，進(jìn)一步確定各種需求細(xì)節(jié)，適應(yīng)需求的

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

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

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

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

＞人類受認(rèn)識(shí)能力局限，不能預(yù)先指定所有要求；

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

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

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

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

RationalRose)。

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

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

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

說(shuō)明不是一件容易的事。特別是對(duì)一些大型

的軟件項(xiàng)目。

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

完全準(zhǔn)確地表達(dá)對(duì)系統(tǒng)的全面要求。

＞軟件開發(fā)者對(duì)于所要解決的應(yīng)用問(wèn)題認(rèn)識(shí)更

是模糊不清

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

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

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

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

;開發(fā)者又可能在設(shè)計(jì)與實(shí)現(xiàn)的過(guò)程中遇到些

沒(méi)有預(yù)料到的實(shí)際困難，需要以改變需求來(lái)解

脫困境。

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

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

進(jìn)的障礙。

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

原型的概念。

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

2、原型的分類

□廢棄型：先構(gòu)造一個(gè)功能簡(jiǎn)單而且質(zhì)量要求不高的模型系

統(tǒng)，針對(duì)這個(gè)模型系統(tǒng)反復(fù)進(jìn)行分析修改，形成比較好的

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

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

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

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

對(duì)項(xiàng)目都缺乏經(jīng)驗(yàn)的情況

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

明是否可靠

□追加型或演化型：先構(gòu)造一個(gè)功能簡(jiǎn)單而且質(zhì)量要求不高

的模型系統(tǒng)，作為最終系統(tǒng)的核心，然后通過(guò)不斷地?cái)U(kuò)充

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

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

3、原型類型的選擇

□系統(tǒng)結(jié)構(gòu)：聯(lián)機(jī)事務(wù)處理系統(tǒng)，相互關(guān)聯(lián)的應(yīng)用

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

結(jié)構(gòu)不適宜用原型化方法

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

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

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

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

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

意承擔(dān)決策的責(zé)任，準(zhǔn)備積極參與的用戶是適合

于使用原型的用戶。

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

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

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

化方法。

□項(xiàng)目管理：項(xiàng)目負(fù)責(zé)人愿意使用原型化方法，才

適合于用原型化的方法。

□項(xiàng)目環(huán)境：需求說(shuō)明技術(shù)應(yīng)當(dāng)根據(jù)每個(gè)項(xiàng)目的實(shí)

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

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

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

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

型上先做一些試驗(yàn)也是很必要的。

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

4、原型化分析的好處

＞增進(jìn)軟件者和用戶對(duì)系統(tǒng)服務(wù)需求的理

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

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

＞軟件原型化方法提供了一種有力的學(xué)習(xí)

手段。

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

4、原型化分析的好處

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

的性能，確認(rèn)各項(xiàng)主要系統(tǒng)服務(wù)的可應(yīng)用

性，確認(rèn)系統(tǒng)設(shè)計(jì)的可行性，確認(rèn)系統(tǒng)作

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

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

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

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

成最終系統(tǒng)。

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

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

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

基于場(chǎng)景的設(shè)計(jì)

□自動(dòng)程序設(shè)計(jì)

專用語(yǔ)言

□軟件復(fù)用技術(shù)

□簡(jiǎn)化假設(shè)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

反應(yīng)，來(lái)定義一個(gè)行為模型，從而得到“做什么”的

規(guī)格說(shuō)明。

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

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

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

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

□原則5：系統(tǒng)規(guī)格說(shuō)明必須是一個(gè)認(rèn)識(shí)的模型，而不

是設(shè)計(jì)或?qū)崿F(xiàn)的模型。

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

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

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

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

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

說(shuō)明。

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

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

括的信息必須局部化，這樣當(dāng)信息被修改時(shí)，只要修

改某個(gè)單個(gè)的段落（理想情況）。同時(shí)，規(guī)格說(shuō)明應(yīng)

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

刪去一些段落。

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

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

1引言

2任務(wù)描述

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

4功能需求

5性能需求

6運(yùn)行需求

7其他需求

3.3?3.4需求審查

■需求審查的主要內(nèi)容

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

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

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

戶要求

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

□被開發(fā)項(xiàng)目的數(shù)據(jù)流與數(shù)據(jù)結(jié)構(gòu)是否足夠，確定

□所有圖表是否清楚，在不補(bǔ)充說(shuō)明時(shí)能否理解

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

否都已充分說(shuō)明

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

能是否一致；

3.3?3.4需求審查

■需求審查的主要內(nèi)容

設(shè)計(jì)的約束條件或限制條件是否符合實(shí)際

是否考慮了開發(fā)的技術(shù)風(fēng)險(xiǎn)

是否考慮過(guò)軟件需求的其他方案

是否考慮過(guò)將來(lái)可能會(huì)提出的軟件需求

是否詳細(xì)制定了檢驗(yàn)標(biāo)準(zhǔn)，它們能否對(duì)系統(tǒng)定義

是否成功進(jìn)行確認(rèn)

□有沒(méi)有遺漏，重復(fù)或不一致的地方

用戶是否審查了初步的用戶手冊(cè)或原型

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

3.4圖形工具

＞在描繪復(fù)雜關(guān)系時(shí)，圖形比文字?jǐn)⑹鰞?yōu)越得多，它

形象直觀。

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

具。

3.4.1層次方框圖

＞層次方框圖用樹形結(jié)構(gòu)的一系列多層次的矩形框描

述數(shù)據(jù)的層次結(jié)構(gòu)。

＞樹形結(jié)構(gòu)的頂層是一個(gè)單獨(dú)的矩形框，它代表完整

的數(shù)據(jù)結(jié)構(gòu)，下面的各層矩形框代表這個(gè)數(shù)據(jù)的子

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

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

3.4.1層次方框圖

＞隨著結(jié)構(gòu)的精細(xì)化，層次方框圖對(duì)數(shù)據(jù)結(jié)構(gòu)的描

繪也越來(lái)越詳細(xì)，這種模式非常適合于需求分析

階段的需要。

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

條路徑反復(fù)細(xì)化，直到確定了數(shù)據(jù)結(jié)構(gòu)的全部細(xì)

節(jié)為止。

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

以用層次方框圖表示。

3.4.1層次方框圖

定貨報(bào)表

零件

編號(hào)

定貨報(bào)表的層次方框圖

3.4.2Warnier圖

＞法國(guó)計(jì)算機(jī)科學(xué)家Warnier提出了表示信息層次結(jié)構(gòu)

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

手段。

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

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

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

現(xiàn)的。

3.4.2Warnier圖

A花括號(hào)：區(qū)分?jǐn)?shù)據(jù)結(jié)構(gòu)的層次，在一個(gè)花括號(hào)內(nèi)的

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

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

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

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

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

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

零件編號(hào)一——字符(8)

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

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

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

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

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

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

「供應(yīng)商編號(hào)-----字符(8)

,次要供應(yīng)商

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

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

定貨報(bào)表的Warnier圖

3.4.3IPO圖

＞IPO圖是輸入/處理/輸出圖的簡(jiǎn)稱，它是美國(guó)

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

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

的關(guān)系。

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

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

序）。

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

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

343IPO圖

?A

圖3.5IPO圖的一個(gè)例子

343IPO圖

圖3.6改進(jìn)的卬0圖的形式

343IPO圖

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

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

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

暫時(shí)還不具備，但是在軟件設(shè)計(jì)階段可以進(jìn)一步補(bǔ)

充修正這些圖，作為設(shè)計(jì)階段的文檔。

3.5軟件需求驗(yàn)證

3.5.1從哪些方面驗(yàn)證軟件需求的正確性

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

因此，應(yīng)該從下述4個(gè)方面進(jìn)行驗(yàn)證：

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

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

的每一個(gè)功能或性能。

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

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

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

確實(shí)能解決用戶面對(duì)的問(wèn)題。

3.5.2軟件需求驗(yàn)證方法

1.驗(yàn)證需求的一致性

自然語(yǔ)言書寫的需求，除了靠人工技術(shù)審查驗(yàn)

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

有其他更好的“測(cè)試”方法。

由于人工審查的效果是沒(méi)有保證的，冗余、遺

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

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

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

述缺點(diǎn)。

3.5.2軟件需求驗(yàn)證方法

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

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

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

術(shù)實(shí)現(xiàn)目標(biāo)系統(tǒng)的可能性。必要的時(shí)候應(yīng)該采用

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

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

3.5.2軟件需求驗(yàn)證方法

3.驗(yàn)證需求的完整性和有效性

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

說(shuō)明書是否完整、準(zhǔn)確地描述了他們的需求。

然而許多用戶只有當(dāng)他們有某種工作著的軟件

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

出他們的需要。

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

3.5.3需求評(píng)審

基線需求文檔

附1需求管理

■需求管理是一組用于幫助項(xiàng)目組在項(xiàng)目進(jìn)展中的

任何時(shí)候去標(biāo)識(shí)、控制和跟蹤需求的活動(dòng)

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

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

中的每個(gè)需求是否都能在后繼工作產(chǎn)品中找到對(duì)應(yīng)點(diǎn)

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

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

需求管理

需求管理

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

?建議變更?確定需求文?定義對(duì)其它?定義需求狀

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

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

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

?合并邊接鏈

?測(cè)量需求的

穩(wěn)定性

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

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

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

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

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

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

□實(shí)例班級(jí)

一個(gè)班級(jí)只有一個(gè)正班長(zhǎng)

一個(gè)班長(zhǎng)只在一個(gè)班中任職

□定義：

如果對(duì)于實(shí)體集A中的每一個(gè)實(shí)體，實(shí)

體集B中至多有一個(gè)（也可以沒(méi)有）實(shí)體班長(zhǎng)

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

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

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

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

□實(shí)例

一個(gè)班級(jí)中有若干名學(xué)生，

每個(gè)學(xué)生只在一個(gè)班級(jí)中學(xué)習(xí)

□定義：

如果對(duì)于實(shí)體集A中的每一個(gè)實(shí)體，實(shí)

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

,對(duì)于實(shí)體集B中的每一個(gè)實(shí)體，實(shí)體集A

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

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

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

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

□實(shí)例

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

一門課程同時(shí)有若干個(gè)學(xué)生選修

一個(gè)學(xué)生可以同時(shí)選修多門課程

□定義：

如果對(duì)于實(shí)體集A中的每一個(gè)實(shí)體，實(shí)體集B

中有n個(gè)實(shí)體（論0）與之聯(lián)系，反之，對(duì)于實(shí)體集

B中的每一個(gè)實(shí)體，實(shí)體集A中也有m個(gè)實(shí)體（m?0

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

，記為m:n。

m:n聯(lián)系

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

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

■兩個(gè)以上實(shí)體型之間一對(duì)多聯(lián)系

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

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

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

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

的。

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

■實(shí)例

課程、教師與參考書三個(gè)實(shí)體型

一門課程可以有若干個(gè)教師講

授，使用若干本參考書，每一個(gè)

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

考書只供一門課程使用。

兩個(gè)以上實(shí)體型間

l:n聯(lián)系

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

■多個(gè)實(shí)體型間的一對(duì)一聯(lián)系

一對(duì)夫婦一個(gè)孩供應(yīng)商

■兩個(gè)以上實(shí)體型間的多對(duì)多聯(lián)系

m

供應(yīng)商、項(xiàng)目、零件三個(gè)實(shí)體型-k

一個(gè)供應(yīng)商可以供給多個(gè)項(xiàng)目多種/供應(yīng)

零件，每個(gè)項(xiàng)目可以使用多個(gè)供應(yīng)商/

供應(yīng)的零件每種零件可由不同供應(yīng)口/

商供給。/

項(xiàng)目零件

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

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

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

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

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

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

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

■實(shí)體型

用矩形表示，矩形框內(nèi)寫明實(shí)體名。

學(xué)生教師

■屬性

用橢圓形表示，并用無(wú)向邊將其與相應(yīng)的實(shí)體連

接起來(lái)

學(xué)生

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

■聯(lián)系

□聯(lián)系本身：

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

別與有關(guān)實(shí)體連接起來(lái)，同時(shí)在無(wú)向邊旁標(biāo)上聯(lián)系的類

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

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

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

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

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

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

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

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

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

課程

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

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

性，則這些屬性也要用無(wú)向邊與該

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

學(xué)生

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

4、一個(gè)實(shí)例

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

■實(shí)體

倉(cāng)庫(kù)：倉(cāng)庫(kù)號(hào)、面積、電話號(hào)碼

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

□供應(yīng)商：供應(yīng)商號(hào)、姓名、地址、電話號(hào)碼、帳號(hào)

□項(xiàng)目：項(xiàng)目號(hào)、預(yù)算、開工日期

□職工：職工號(hào)、姓名、年齡、職稱

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

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

（1）一個(gè)倉(cāng)庫(kù)可存放多種零件，一種零件可以存放在多個(gè)

倉(cāng)庫(kù)中。倉(cāng)庫(kù)和零件具有多對(duì)多的聯(lián)系。用庫(kù)存量來(lái)表示某

種零件在某個(gè)倉(cāng)庫(kù)中的數(shù)量。

（2）一個(gè)倉(cāng)庫(kù)有多個(gè)職工當(dāng)倉(cāng)庫(kù)保管員，一個(gè)職工只能在

一個(gè)倉(cāng)庫(kù)工作，倉(cāng)庫(kù)和職工之間是一對(duì)多的聯(lián)系。職工實(shí)體

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

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

(3)職工之間具有領(lǐng)導(dǎo)-被領(lǐng)導(dǎo)關(guān)系。即倉(cāng)庫(kù)主任領(lǐng)導(dǎo)若

干保管員。

(4)供應(yīng)商、項(xiàng)目和零件三者之間具有多對(duì)多的聯(lián)系。

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

(S)(電話號(hào)碼)

儂應(yīng)商吩3庫(kù)而(ML)@話號(hào)碼)瓢(w)

(W)

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

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

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

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

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

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

■結(jié)構(gòu)化分析方法（簡(jiǎn)稱SA方法）就是面向數(shù)

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

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

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

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

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

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

端著手分析，這是因?yàn)橄到y(tǒng)的目標(biāo)是產(chǎn)生這

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

基本的組成元素。

1、沿?cái)?shù)據(jù)流圖回溯

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

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

■沿?cái)?shù)據(jù)流圖從輸出端往輸入端回溯，應(yīng)該能

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

初步定義了有關(guān)的算法。

1、沿?cái)?shù)據(jù)流圖回溯

■沿?cái)?shù)據(jù)流圖回溯時(shí)常常遇到下述問(wèn)題：

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

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

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

全清楚。

1、沿?cái)?shù)據(jù)流圖回溯

■為了解決這些問(wèn)題，往往需要向用戶和其他

有關(guān)人員請(qǐng)教；

■他們的回答使分析員對(duì)目標(biāo)系統(tǒng)的認(rèn)識(shí)更深

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

出來(lái)了，更多的算法被搞清楚了。

1、沿?cái)?shù)據(jù)流圖回溯

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

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

記錄在IPO圖中。

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

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

2、用戶復(fù)查

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

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

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

■用戶應(yīng)該注意傾聽(tīng)分析員的報(bào)告，并及時(shí)糾

正和補(bǔ)充分析員的認(rèn)識(shí)。復(fù)查過(guò)程驗(yàn)證了已

知的元素，補(bǔ)充了未知的元素，填補(bǔ)了文檔

中的空白。

2、用戶復(fù)查

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

步驟實(shí)質(zhì)上構(gòu)成一個(gè)循環(huán)。

■在分析員對(duì)目標(biāo)系統(tǒng)的認(rèn)識(shí)螺旋式上升的過(guò)

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

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

他們來(lái)回答，分析員對(duì)系統(tǒng)的更深入的認(rèn)識(shí)

必須經(jīng)過(guò)他們的檢驗(yàn)和確認(rèn)。

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

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

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

理，并把它的功能分解成若干個(gè)子功能，

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

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

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

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

■分層細(xì)化的兩條原則：

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

也就是說(shuō)細(xì)化前后對(duì)應(yīng)功能的輸入/輸出數(shù)

據(jù)必須相同；

2.第二，當(dāng)進(jìn)一步細(xì)化將涉及如何具體地實(shí)現(xiàn)

一個(gè)功能時(shí)，就不應(yīng)該再分解了。

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

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

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

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

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

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

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

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

■這張圖稱為頂層圖。

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

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

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

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

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

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

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

的過(guò)程實(shí)際上就是對(duì)這個(gè)加工的分解過(guò)程。

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

可用下述的方法來(lái)確定加工：

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

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

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

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

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

■當(dāng)用戶把若干個(gè)數(shù)據(jù)看作一個(gè)單位來(lái)處理（

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

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

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

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

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

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

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

3.畫加工的內(nèi)部

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