《軟件詳細(xì)設(shè)計教程》課件第4章

第4章軟件需求工程4.1軟件需求概述4.2需求工程過程4.3需求獲取技術(shù)4.4可行性研究4.5需求建模4.6小結(jié) 4.1軟件需求概述

人們對“軟件需求”這個術(shù)語缺乏統(tǒng)一的描述，客戶所說的“需求”在開發(fā)人員看來是一個較高層次的產(chǎn)品概念，而開發(fā)人員所說的“需求”在用戶看來又像是詳細(xì)設(shè)計。應(yīng)該說，人們從不同的角度和不同的程度反映著各自的要求，形成了不同層次的需求。

《IEEEStandardGlossaryofSoftwareEngineeringTerminology》給出了有關(guān)軟件需求的如下定義：

①用戶解決問題或達(dá)到目標(biāo)所需的條件或能力。

②系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其他正式規(guī)定文檔所需具有的條件或能力。③一種反映上面①或②所描述的條件或能力的文檔說明。

在IEEE的定義中，需求的概念涵蓋了用戶角度(系統(tǒng)的外部行為)和開發(fā)人員角度(系統(tǒng)的內(nèi)部特性)兩個方面，其中的關(guān)鍵在于需求一定要文檔化。

通常，軟件需求可以劃分為業(yè)務(wù)需求、用戶需求、功能需求和非功能需求、系統(tǒng)需求等類型，它們之間的相互關(guān)系如圖4.1所示。圖4.1不同層次的軟件需求及其關(guān)系4.1.1業(yè)務(wù)需求

業(yè)務(wù)需求是組織或客戶對于系統(tǒng)的高層次目標(biāo)要求，定義了項目的遠(yuǎn)景和范圍，即確定軟件產(chǎn)品的發(fā)展方向、功能范圍、目標(biāo)客戶和價值來源。通常，業(yè)務(wù)需求應(yīng)該涵蓋以下內(nèi)容：

●業(yè)務(wù)：產(chǎn)品屬于哪類業(yè)務(wù)范疇？應(yīng)該完成什么功能？需要為什么服務(wù)？

●客戶：產(chǎn)品為誰服務(wù)？目標(biāo)客戶是誰?

●特性：產(chǎn)品區(qū)別于其他競爭產(chǎn)品的特性是什么?

●價值：產(chǎn)品的價值體現(xiàn)在什么方面?

●優(yōu)先級：產(chǎn)品功能特性的優(yōu)先級次序是什么?下面是一些關(guān)于圖書資料管理系統(tǒng)的業(yè)務(wù)需求實例：

●該系統(tǒng)使用計算機(jī)實現(xiàn)圖書資料的日常管理，提高工作效率和服務(wù)質(zhì)量；

●該系統(tǒng)可以讓用戶在網(wǎng)絡(luò)上查詢和瀏覽一些電子資料，改變原有的借閱模式；

●由于版權(quán)的限制，某些電子資料只能讓用戶瀏覽和打印而不能下載。

業(yè)務(wù)需求代表了項目參與者在產(chǎn)品所滿足的業(yè)務(wù)需要和產(chǎn)品所提供的利益上的統(tǒng)一共識，清楚地界定了產(chǎn)品應(yīng)該包括什么和不應(yīng)該包括什么，為后續(xù)詳細(xì)功能需求的確定和需求變更的決策等提供了參考。

項目的遠(yuǎn)景和范圍應(yīng)該以文檔形式描述出來。這種文檔一般比較簡短，可能只有1～5頁，它主要包括業(yè)務(wù)機(jī)會、項目目標(biāo)、產(chǎn)品適用范圍、客戶特點、項目優(yōu)先級和項目成功因素等。下面給出該文檔的一種模板。4.1.2用戶需求

用戶需求是從用戶角度描述的系統(tǒng)功能需求和非功能需求，通常只涉及系統(tǒng)的外部行為，而不涉及系統(tǒng)的內(nèi)部特性。用戶需求的描述應(yīng)該易于用戶的理解，一般不采用技術(shù)性很強(qiáng)的語言，而是采用自然語言和直觀圖形相結(jié)合的方式進(jìn)行描述。

下面給出一個用戶對于圖書資料管理系統(tǒng)提出的需求描述的實例，請指出它有什么問題。

用戶可以通過Internet隨時查詢圖書信息和個人借閱情況，并可以快捷地查找和瀏覽所需要的電子資料。

首先，上面一句話的需求描述顯然包含了3個不同的需求：

(1)用戶可以通過Internet隨時查詢圖書信息；

(2)用戶可以通過Internet隨時查詢個人借閱情況；

(3)用戶可以通過Internet快捷地查找和瀏覽所需要的電子資料。

其次，上面描述中的“隨時”和“快捷”是對系統(tǒng)功能的約束，但十分模糊，不同的人會對它們產(chǎn)生不同的理解。

上面的實例說明，使用自然語言進(jìn)行需求描述容易產(chǎn)生含糊不清和不準(zhǔn)確的問題，而且多個不同的需求往往混合成一個需求提出。因此，清晰的文檔結(jié)構(gòu)和適當(dāng)?shù)恼Z言表達(dá)對于用戶需求的描述是十分重要的。4.1.3功能需求和非功能需求

功能需求描述系統(tǒng)應(yīng)該提供的功能或服務(wù)，通常涉及用戶或外部系統(tǒng)與該系統(tǒng)之間的交互，一般不考慮系統(tǒng)的實現(xiàn)細(xì)節(jié)。

下面是一些關(guān)于圖書資料管理系統(tǒng)的功能需求實例：

●用戶可以從圖書資料庫中查詢或者選擇其中的一個子集；

●系統(tǒng)可以提供適當(dāng)?shù)臑g覽器供用戶閱讀館藏文獻(xiàn)；

●用戶每次借閱圖書應(yīng)該對應(yīng)一個唯一的標(biāo)識號，它被記錄到用戶的賬戶上。注意一下以上的需求描述，“適當(dāng)?shù)臑g覽器”存在著含糊不清的問題。在用戶看來，這個需求意味著瀏覽器可以支持所有格式的文檔。但是，開發(fā)人員可能迫于開發(fā)進(jìn)度的壓力，只實現(xiàn)支持一種文本格式的瀏覽器。

非功能需求是從各個角度對系統(tǒng)的約束和限制，反映了應(yīng)用對軟件系統(tǒng)質(zhì)量和特性的額外要求，例如響應(yīng)時間、數(shù)據(jù)精度、可靠性等。在圖4.2中，非功能需求包括過程需求、產(chǎn)品需求和外部需求等類型，其中過程需求包含軟件交付、實現(xiàn)方法和標(biāo)準(zhǔn)等方面的需求；產(chǎn)品需求包含軟件性能、可用性、存儲空間、可靠性、可移植性、安全性、容錯性等方面的需求；外部需求有道德、法規(guī)、成本、互操作性等需求。圖4.2非功能需求的類型非功能需求的常見問題檢驗起來非常困難，一般采用一些可度量的特性進(jìn)行描述。表4.1給出了一些常用的非功能特性的度量。表4.1常用的非功能特性的度量下面是一些關(guān)于圖書資料管理系統(tǒng)的非功能需求實例：

●系統(tǒng)在20?s之內(nèi)響應(yīng)所有的請求；

●系統(tǒng)應(yīng)該每周7天、每天24小時都可使用；

●對于一個沒有經(jīng)驗的用戶而言，經(jīng)過兩個小時的培訓(xùn)就可以使用系統(tǒng)的所有功能。

4.1.4系統(tǒng)需求

系統(tǒng)需求更加詳細(xì)地描述了系統(tǒng)應(yīng)該做什么，通常包括對象模型、數(shù)據(jù)模型、狀態(tài)模型等許多分析模型。系統(tǒng)需求主要是面向開發(fā)人員進(jìn)行描述的，是開發(fā)人員進(jìn)行軟件設(shè)計的基礎(chǔ)。前面提到，使用自然語言進(jìn)行需求描述容易產(chǎn)生含糊不清和不準(zhǔn)確等問題，因此需要采用適當(dāng)?shù)姆椒ㄐ纬梢恢碌摹⑼陚涞暮蜔o二義性的系統(tǒng)需求描述。通常，系統(tǒng)需求模型的描述有以下3種方法：

(1)結(jié)構(gòu)化語言(PDL)：是介于自然語言和形式語言之間的半形式語言，它試圖把自然語言的非形式化性與程序設(shè)計語言的嚴(yán)格語法和控制結(jié)構(gòu)結(jié)合起來。

(2)可視化模型：使用圖形化符號輔之以文本注釋定義系統(tǒng)模型，如數(shù)據(jù)流圖、UML語言、實體關(guān)系圖等。

(3)形式化方法：基于狀態(tài)機(jī)或集合等數(shù)學(xué)概念描述系統(tǒng)模型，如Z語言、PetriNet等。

4.2需求工程過程

需求工程應(yīng)用已證實有效的原理和方法，通過合適的工具和符號，系統(tǒng)地描述了待開發(fā)系統(tǒng)及其行為特征和相關(guān)約束。在需求工程過程中，開發(fā)人員需要收集和分析來自用戶或市場等各方面的需求，編寫規(guī)格說明文檔，并采用評審和商議等有效手段對其進(jìn)行驗證，最終形成一個需求基線。由于軟件開發(fā)過程中經(jīng)常發(fā)生需求變更的情況，因此，必須有效地管理和控制這些變更。

圖4.3顯示了需求工程的所有過程，包括需求獲取、需求分析、需求規(guī)格說明、需求驗證和需求管理等，并說明了這些過程之間的關(guān)系和需要產(chǎn)生的文檔。圖4.3需求工程過程4.2.1需求獲取

需求獲取是在問題及其最終解決方案之間架設(shè)橋梁的第一步。獲取需求的一個必不可少的結(jié)果是對項目中描述的客戶需求的普遍理解，一旦理解了需求，開發(fā)人員和客戶就能探索出描述這些需求的多種解決方案。

需求獲取應(yīng)該集中在用戶任務(wù)上，而不是集中在用戶接口上，其主要工作內(nèi)容包括：

(1)聆聽用戶的需求。開發(fā)人員應(yīng)該與各種層次的客戶進(jìn)行充分地交流和溝通，包括決策管理層、使用部門經(jīng)理、具體使用人員、系統(tǒng)維護(hù)人員等，盡量清楚地理解用戶的問題和要求。

(2)分析和整理所獲取的信息。對于用戶提供的各種問題和要求，開發(fā)人員需要對其進(jìn)行歸納和整理，借助一些工具和方法，從用戶一般性的陳述中提取用戶的真正需求，并由此確定軟件的功能、性能、接口關(guān)系、約束條件等。

(3)形成文檔化的描述。不論是用戶提出的問題，還是最終獲取的需求，都應(yīng)該形成文檔化的描述，這種描述需要各種人員的一致理解和認(rèn)同。4.2.2需求分析

需求分析主要是對收集到的需求進(jìn)行提煉、分析和認(rèn)真審查，以確保所有的項目相關(guān)人員都明白其含義，并找出其中的錯誤、遺漏或其他不足的地方，形成完整的分析模型。需求分析的目的在于開發(fā)出高質(zhì)量的、詳細(xì)的需求，從而支持項目估算、軟件設(shè)計、軟件開發(fā)和軟件測試。

需求分析的主要工作內(nèi)容包括：

(1)定義系統(tǒng)的邊界。建立系統(tǒng)與其外部實體間的界限和接口的簡單模型，明確接口處的信息流。

(2)建立軟件原型。當(dāng)開發(fā)人員或用戶遇到需求不確定的問題時，開發(fā)軟件原型是一種最好的解決方法，它將許多概念和可能發(fā)生的事情直觀地顯示出來。用戶通過評價原型，使得項目參與人員能夠進(jìn)一步理解問題，同時找出需求文檔與軟件原型之間的矛盾。

(3)分析需求可行性。在項目成本和性能要求允許的情況下，分析每一個需求實現(xiàn)的可行性，確定與需求實現(xiàn)相聯(lián)系的開發(fā)風(fēng)險，諸如與其他需求的沖突、對外界因素的依賴和技術(shù)障礙等。

(4)確定需求優(yōu)先級。開發(fā)人員通過分析來確定產(chǎn)品特性或每一個需求實現(xiàn)的優(yōu)先級，并以此為基礎(chǔ)確定產(chǎn)品版本將包括哪些特性或需求。由于軟件項目受到時間和資源的限制，一般情況下無法實現(xiàn)軟件功能的每一個細(xì)節(jié)，因此需求優(yōu)先級有助于開發(fā)組織和版本規(guī)劃，以保證在規(guī)定的時間和預(yù)算內(nèi)達(dá)到最好的效果。

(5)建立需求分析模型。建立需求分析模型是需求分析的核心工作，它通過建立需求的多種視圖，例如數(shù)據(jù)流圖、實體關(guān)系圖、狀態(tài)變換圖、類圖、交互圖等，揭示出需求的不正確、不一致、遺漏和冗余等更深的問題。

(6)創(chuàng)建數(shù)據(jù)字典。數(shù)據(jù)字典定義了系統(tǒng)中使用的所有數(shù)據(jù)項及其結(jié)構(gòu)，至少應(yīng)該定義客戶的數(shù)據(jù)項，以確保客戶和開發(fā)人員使用一致的定義和術(shù)語。

多年來，人們提出了許多分析建模的方法，其中占主導(dǎo)地位的是傳統(tǒng)的結(jié)構(gòu)化分析方法和當(dāng)今流行的面向?qū)ο蠓治龇椒ā?.2.3需求規(guī)格說朋

軟件需求規(guī)格說明(SoftwareRequirementSpecification，SRS)是需求開發(fā)的結(jié)果，它精確地闡述了一個軟件系統(tǒng)必須提供的功能和性能，以及它所要考慮的限制條件。

軟件需求規(guī)格說明具有廣泛的使用范圍，并成為用戶、分析人員和設(shè)計人員之間進(jìn)行理解和交流的手段。用戶通過需求規(guī)格說明文檔指定需求，檢查需求描述是否滿足原來的期望；設(shè)計人員通過需求規(guī)格說明文檔了解軟件需要開發(fā)的內(nèi)容，將其作為軟件設(shè)計的基本出發(fā)點；測試人員根據(jù)軟件需求規(guī)格說明中對產(chǎn)品行為的描述，制定測試計劃、測試用例和測試過程；產(chǎn)品發(fā)布人員根據(jù)軟件需求規(guī)格說明和用戶界面設(shè)計編寫用戶手冊和幫助信息等。軟件需求規(guī)格說明在整個開發(fā)過程中具有重要的作用，項目管理人員可以利用它規(guī)劃軟件開發(fā)過程，更加準(zhǔn)確地估計開發(fā)進(jìn)度和成本，控制需求的變更過程，并將其作為最后驗收目標(biāo)系統(tǒng)的可測試標(biāo)準(zhǔn)。

在軟件項目中，開發(fā)組織應(yīng)該采用一種標(biāo)準(zhǔn)的軟件需求規(guī)格說明模板。現(xiàn)在有許多推薦的軟件需求規(guī)格說明模板可以使用，這里介紹一種由IEEE標(biāo)準(zhǔn)830-1998改寫并擴(kuò)充的模板。4.2.4需求驗證

需求驗證用于確保需求說明準(zhǔn)確、完整地表達(dá)必要的質(zhì)量特點。有時人們認(rèn)為軟件需求規(guī)格說明文檔中的需求描述是正確的，但在現(xiàn)實中卻會出現(xiàn)問題；在使用需求規(guī)格說明編寫測試用例時，又有可能發(fā)現(xiàn)二義性和不可驗證的問題。需求驗證通過評審的方式，發(fā)現(xiàn)需求規(guī)格說明中存在的錯誤或缺陷，開發(fā)人員應(yīng)及時進(jìn)行更改和補(bǔ)充，并對修改后的需求規(guī)格說明文檔進(jìn)行再評審。

需求驗證針對那些已編寫成文檔的需求進(jìn)行驗證，而對于那些存在于用戶或開發(fā)人員思維中的沒有表露的、含蓄的需求則不予驗證。一般來說，需求評審由不同代表(如分析人員、客戶、設(shè)計人員、測試人員)組成的評審小組以會議形式進(jìn)行。在評審會議上，分析人員說明軟件產(chǎn)品的總體目標(biāo)、主要功能和性能指標(biāo)等，評審小組對照需求規(guī)格說明文檔及其相關(guān)模型進(jìn)行檢查和評價，并討論軟件驗收的可測試指標(biāo)。

需求驗證主要圍繞需求規(guī)格說明的質(zhì)量特性展開，這些質(zhì)量特性包括正確性、無二義性、完整性、可驗證性、一致性、可修改性和可跟蹤性等。

1．正確性

正確性是指需求規(guī)格說明對系統(tǒng)功能、行為、性能等的描述必須與用戶的期望相吻合，代表了用戶的真正需求。

審查需求的正確性應(yīng)該考慮以下幾方面的問題：

(1)用戶參與需求過程的程度如何?

(2)每一個需求描述是否準(zhǔn)確地反映了用戶的需要?

(3)系統(tǒng)用戶是否已經(jīng)認(rèn)真考慮了每一項描述?

(4)需求可以追溯到來源嗎?

舉例：下面的需求描述正確嗎?

在用戶每次存錢時系統(tǒng)將進(jìn)行信用檢查。

2．無二義性

無二義性是指需求規(guī)格說明中的描述對所有人都只能有一種明確統(tǒng)一的解釋。由于自然語言極易導(dǎo)致二義性，所以應(yīng)盡量把每項需求用簡潔明了的用戶語言表達(dá)出來。

審查需求的無二義性應(yīng)該考慮以下幾方面的問題：

(1)需求規(guī)格說明是否有術(shù)語詞匯表?

(2)具有多重含義或未知含義的術(shù)語是否已經(jīng)定義?

(3)需求描述是否可量化和可驗證?

(4)每一項需求都有測試準(zhǔn)則嗎?

舉例：下面的需求描述是無二義性的嗎?

如果用戶試圖透支，系統(tǒng)將采取適當(dāng)?shù)男袆印?/p>

3．完整性

完整性是指需求規(guī)格說明應(yīng)該包括軟件要完成的全部任務(wù)，不能遺漏任何必要的需求信息。注重用戶的任務(wù)而不是系統(tǒng)的功能將有助于避免不完整性。

審查需求的完整性應(yīng)該考慮以下幾方面的問題：

(1)是否存在遺漏的功能或業(yè)務(wù)過程?

(2)在每個定義的功能之間是否有接口?

(3)是否有信息或消息在所定義的功能之間傳遞?

(4)是否定義了功能的使用者?

(5)是否已經(jīng)清楚地定義了用戶與功能之間的交互?

(6)是否定義了與外部過程和系統(tǒng)之間的接口?

(7)所描述的功能是否可以映射到業(yè)務(wù)過程中?

(8)文檔中是否存在待確定的需求引用?

(9)文檔中是否存在未定義的術(shù)語和引用?

(10)文檔的各個部分都完整嗎?

(11)需求包括非功能屬性的說明嗎?

4．可驗證性

可驗證性是指需求規(guī)格說明中描述的需求都可以運用一些可行的手段對其進(jìn)行驗證和確認(rèn)。

審查需求的可驗證性應(yīng)該考慮以下幾方面的問題：

(1)在需求文檔中是否存在不可驗證的描述，諸如“用戶界面友好”、“容易”、“簡單”、“快速”、“健壯”、“最新技術(shù)”等?

(2)所有描述都是具體的和可測量的嗎?

舉例：下面兩個需求描述中哪一個難以驗證?

①系統(tǒng)將在20?s內(nèi)響應(yīng)所有有效的請求。

②如果用戶試圖透支，系統(tǒng)將采取適當(dāng)?shù)男袆印?/p>

5．一致性

一致性是指需求規(guī)格說明對各種需求的描述不能存在矛盾，如術(shù)語使用沖突、功能和行為特性方面的矛盾以及時序上的不一致等。

審查需求的一致性應(yīng)該考慮以下幾方面的問題：

(1)文檔的組織形式是否易于一致?

(2)不同功能的描述之間是否存在矛盾?

(3)是否存在有矛盾的需求描述或術(shù)語?

(4)是否存在矛盾的術(shù)語定義?

(5)文檔中是否存在時序上的不一致?

舉例：下面兩個需求描述是否有矛盾?

①系統(tǒng)允許立即使用所存資金。

②只有在手工驗證所存資金后，系統(tǒng)才能允許使用。

6．可修改性

可修改性是指需求規(guī)格說明的格式和組織方式應(yīng)保證后續(xù)的修改比較容易進(jìn)行和協(xié)調(diào)一致?？梢允褂密浖ぞ呋蛘吣夸洷怼⑺饕拖嗷⒄樟斜淼确椒ㄊ管浖枨笠?guī)格說明更容易修改。

審查需求的可修改性應(yīng)該考慮以下幾方面的問題：

(1)是否存在明顯的需求交叉引用?

(2)是否有內(nèi)容列表和索引?

(3)是否存在冗余需求，即同一個需求的描述出現(xiàn)在文檔的不同地方？如果存在，它們是交叉引用嗎?

7．可跟蹤性

可跟蹤性是指每一項需求都能與其對應(yīng)的來源、設(shè)計、源代碼和測試用例聯(lián)系起來。一方面，每一項需求都可以在早期的文檔中追溯到其來源，例如備忘錄、法規(guī)、會議記錄等；另一方面，每一項需求都有唯一的名稱或索引號，與后期的實現(xiàn)結(jié)果對應(yīng)。

舉例：下面的需求描述記錄了早期的文檔來源。

系統(tǒng)將在20?s內(nèi)響應(yīng)所有有效的請求。

[來自與用戶的面談，備忘錄編號#1234]4.2.5需求管理

軟件需求的最大問題在于難以清楚確定以及不斷發(fā)生的變化，這也是軟件開發(fā)之所以困難的主要根源，因此有效地管理需求是項目成功的基礎(chǔ)。在軟件過程能力成熟度模型(CapabilityMaturityModel，CMM)中，需求管理作為CMM二級所應(yīng)達(dá)到的目標(biāo)能力之一，其目的在于為軟件需求建立一個基線供軟件工程和管理使用，并使軟件計劃、產(chǎn)品和活動與其保持一致。

軟件需求規(guī)格說明通過評審后，就形成了開發(fā)工作的需求基線，這個基線在客戶和開發(fā)人員之間構(gòu)筑了計劃產(chǎn)品功能需求和非功能需求的一個約定。需求管理的任務(wù)是分析變更影響并控制變更過程，主要包括變更控制、版本控制、需求跟蹤和需求狀態(tài)跟蹤等活動，如圖4.4所示。圖4.4需求管理的活動

1．需求變更控制

對許多項目來說，一些需求的改進(jìn)是合理的且不可避免的。瞬息萬變的市場機(jī)會、競爭性的產(chǎn)品、新的開發(fā)技術(shù)和項目目標(biāo)的調(diào)整等都可能產(chǎn)生需求的變更，但是如果不控制這種變更將會導(dǎo)致項目陷入混亂、不能按進(jìn)度執(zhí)行或軟件質(zhì)量低劣等問題。因此，應(yīng)該評估每一項變更建議，將它與項目的視圖和范圍進(jìn)行比較，最終決定是否應(yīng)該采納它。

變更控制是在一定的程序下有效地實施整個變更過程，應(yīng)該包括以下幾部分：

(1)仔細(xì)評估已建議的變更；

(2)挑選合適的人選對變更做出決定；

(3)變更應(yīng)及時通知所有涉及的人員；

(4)項目要按一定的程序?qū)嵤┬枨笞兏?/p>

2．需求文檔的版本控制

版本控制是管理需求的一個必要方面，它保證在需求文檔中記錄和反映所有的需求變化。需求文檔的每一個版本都必須統(tǒng)一確定，組內(nèi)每個成員必須能夠得到需求的當(dāng)前版本，需求變更應(yīng)該及時通知到項目開發(fā)所涉及的人員。每一個公布的需求文檔都應(yīng)該包括一個修正版本的歷史情況，即變更內(nèi)容、變更日期、變更人姓名以及變更原因等。在實際的軟件開發(fā)管理中，商業(yè)需求管理工具是最有力的版本控制方法，這些工具可以跟蹤和報告每個需求的變動歷史，特別是當(dāng)需要恢復(fù)早期的需求時非常有意義。另外，在添加、變動、刪除、拒絕一個需求后，附加一些評語描述變更的原因?qū)罄m(xù)的討論非常有用。

3．需求跟蹤

需求跟蹤幫助人們?nèi)娴胤治鲎兏鼛淼挠绊?，以便做出正確的變更決策。需求跟蹤包括編制每個需求同系統(tǒng)元素之間的聯(lián)系文檔，這些元素包括別的需求、體系結(jié)構(gòu)、其他設(shè)計部件、源代碼模塊、測試、幫助文件、文檔等，從而建立需求的跟蹤聯(lián)系鏈。當(dāng)需求發(fā)生變化時，使用需求跟蹤可以確保不忽略每個受到影響的系統(tǒng)元素，需求變更的正確實施可以降低由此帶給項目的風(fēng)險。表示需求和別的系統(tǒng)元素之間的聯(lián)系鏈的最普遍的方式是使用需求跟蹤能力矩陣。例如，表4.2顯示了某應(yīng)用系統(tǒng)的一個需求跟蹤能力矩陣，說明了每個功能性需求向后連接一個特定的用例，向前連接一個或多個設(shè)計、代碼和測試元素。需求聯(lián)系鏈需要由開發(fā)人員確定，但大量的需求跟蹤信息可以使用特定的工具進(jìn)行管理。表4.2需求跟蹤能力矩陣示例

4．需求狀態(tài)跟蹤

不同類型的需求都有不同的需求狀態(tài)相對應(yīng)，作為需求優(yōu)先級劃分標(biāo)準(zhǔn)的補(bǔ)充說明。通過需求狀態(tài)跟蹤能夠確保需求實現(xiàn)的完整性，其工作包括定義需求狀態(tài)和跟蹤需求狀態(tài)兩部分。然而手工進(jìn)行需求管理很難保持文檔和現(xiàn)實的一致，且無法跟蹤需求的每個狀態(tài)，特別是對大項目而言。因此，選用合適的需求管理工具可以在整個開發(fā)期間有效地管理需求的變動，并使用需求作為設(shè)計、測試和項目管理的基礎(chǔ)。

表4.3列出了一些商業(yè)需求管理工具，主要包括以數(shù)據(jù)庫為核心和以文檔為核心兩類。表4.3商業(yè)需求管理工具實例以數(shù)據(jù)庫為核心的產(chǎn)品(如Caliber-RM和DOORS)將所有的需求、屬性和跟蹤能力信息存儲在數(shù)據(jù)庫中。有些工具可以把每個需求與外部文件相聯(lián)系(如微軟的Word文件、Excel文件、圖形文件等)，以補(bǔ)充需求說明。

以文檔為核心的工具使用Word或Adobe公司的FrameMaker等字處理程序制作和存儲文檔。以RequisitePro為例，這種工具通過允許選擇文檔作為離散需求存儲在數(shù)據(jù)庫中，來加強(qiáng)以文檔為核心的處理方法的能力，同時提供一些機(jī)制來同步數(shù)據(jù)庫和文檔的內(nèi)容。

4.3需求獲取技術(shù)

需求獲取的關(guān)鍵在于通過與用戶的溝通和交流，收集和理解用戶的各項要求。為了確定用戶的真正需求，避免軟件人員與用戶之間的交流障礙、需求不全、意見沖突等問題，一方面需要提高分析人員的知識技能，使其不僅具備較高的技術(shù)水平和豐富的實踐經(jīng)驗，還要具備一定的業(yè)務(wù)基礎(chǔ)知識和較強(qiáng)的人際交往能力；另一方面還要開展大量的調(diào)查研究工作，包括用戶訪談、現(xiàn)場考察、專家咨詢、會議討論等，并對大量的一手資料進(jìn)行分析和整理，從而清楚地理解用戶。

為了更好地理解用戶的需求，可以采用多種不同的技術(shù)進(jìn)行需求獲取，常見的需求獲取技術(shù)包括面談和問卷調(diào)查、需求專題討論會、觀察用戶工作流程、基于用例的方法、原型化方法等，而選擇這些技術(shù)需要根據(jù)應(yīng)用類型、開發(fā)團(tuán)隊技能、用戶性質(zhì)等因素來決定。

4.3.1面談

用戶面談是一種十分重要而直接的需求獲取方法，實際上是一種任何情況下都可以使用的簡單而直接的方法，其基本要點如下：

(1)事先準(zhǔn)備一個合適的與背景無關(guān)的面談，列出一些準(zhǔn)備詢問的問題，并將其記在筆記本上以便面談時參考。

(2)面談前，需要研究一下要面談的風(fēng)險承擔(dān)人或公司的背景資料，不要選擇自己能回答的問題打擾被面談人。

(3)面談過程中，應(yīng)該參考事先準(zhǔn)備的面談模板，以保證提出的問題是正確的。同時，需要建立起和諧的氣氛，并將答案記錄下來。

(4)面談之后，分析總結(jié)面談記錄，找到主要的用戶需求或產(chǎn)品特征。

與背景無關(guān)的面談是通過詢問一些與背景無關(guān)的問題，使開發(fā)人員全面理解用戶的真正問題，以便給出一些有效的解決方法。

下面給出一個用戶面談過程的示例。4.3.2需求專題討論會

需求專題討論會也許是需求獲取的一種最有力的技術(shù)。項目的主要風(fēng)險承擔(dān)人在短暫而緊湊的時間段內(nèi)集中在一起，一般為1～2天，與會者可以在應(yīng)用需求上達(dá)成共識，對操作過程盡快取得統(tǒng)一意見。

專題討論會具有以下優(yōu)點：

●它協(xié)助建立一支高效的團(tuán)隊，圍繞一個目的——項目的成功；

●所有的風(fēng)險承擔(dān)人都暢所欲言；

●它促進(jìn)風(fēng)險承擔(dān)人和開發(fā)團(tuán)隊之間達(dá)成共識；

●它能夠揭露和解決那些妨礙項目成功的行政問題；

●能夠很快產(chǎn)生初步的系統(tǒng)定義。

(1)專題討論會的準(zhǔn)備。充分的準(zhǔn)備是專題討論會成功的關(guān)鍵。首先，應(yīng)向參加討論的人員宣傳專題討論會的好處，使其對專題討論會充滿信心；第二，確定真正的風(fēng)險承擔(dān)人并保證使其參與；第三，做好后勤保障是十分必要的；第四，在專題討論會之前分發(fā)資料，便于與會者進(jìn)行準(zhǔn)備，可以提高專題討論會的效率。

(2)安排日程。專題討論會的議程應(yīng)建立在具體項目需求和所討論的開發(fā)內(nèi)容的基礎(chǔ)上，大多數(shù)會議可以遵循一種比較標(biāo)準(zhǔn)的形式。表4.4是一個典型的議程。表4.4專題討論會議程

(3)舉行專題討論會。專題討論會上可能出現(xiàn)行政人員間的責(zé)備或沖突，會議主持人應(yīng)該能夠掌握討論會氣氛并控制會場，避免挑起項目相關(guān)人員之間的矛盾(過去的、現(xiàn)在的或?qū)淼?。

專題討論會最重要的部分就是自由討論階段，這種技術(shù)非常符合專題討論會的氣氛，并能營造一種創(chuàng)造性的、積極的氛圍，同時可以獲得所有風(fēng)險承擔(dān)人的意見。

在專題討論會上，主持人應(yīng)該分配會議時間，記錄所有言論。

會議結(jié)束后，使項目成功的責(zé)任就落到開發(fā)團(tuán)隊的身上。4.3.3觀察用戶工作流程

有時客戶可能無法有效地表達(dá)或只能片面地表達(dá)自己的需求，開發(fā)人員很難通過面談和會議獲得完整的信息。這種情況下，觀察用戶的工作流程是一種比較好的解決方法。

觀察用戶工作流程有兩種形式：

(1)被動觀察：開發(fā)人員可以在不受干擾或直接干預(yù)的情況下觀察用戶的業(yè)務(wù)活動。為了避免用戶受影響，可以使用攝像機(jī)等設(shè)備幫助進(jìn)行觀察。

(2)主動觀察：開發(fā)人員直接參與到用戶的業(yè)務(wù)活動中，有效地成為其中的一部分。觀察用戶工作流程需要一段較長的時間，而且需要涉及各種不同的業(yè)務(wù)階段。需要說明的是，用戶在被觀察的過程中可能表現(xiàn)出與平常不同的行為，從而隱藏了一些現(xiàn)實的工作情況。

4.3.4原型化方法

一個軟件原型是所開發(fā)系統(tǒng)的部分實現(xiàn)，它比開發(fā)人員常用的技術(shù)術(shù)語更易于理解。原型化方法是需求獲取過程中一種常用的方法，它通過使系統(tǒng)全部或者系統(tǒng)一部分可視化來獲得客戶的反饋，從而有效地解決在系統(tǒng)開發(fā)的早期階段需求不確定的問題。在構(gòu)造原型之前，需要充分與客戶交流，結(jié)合軟件的應(yīng)用領(lǐng)域、應(yīng)用復(fù)雜性、客戶特點和項目特點等因素，決定在評價完原型之后是拋棄掉原型還是將其進(jìn)化為最終產(chǎn)品的一部分，這里分別將它們稱為拋棄式原型和演化式原型。

(1)拋棄式原型。拋棄式原型首先選擇適當(dāng)?shù)难菔竟δ埽⒚枋鱿鄳?yīng)的用戶界面，然后構(gòu)造軟件原型；用戶對所構(gòu)造的軟件原型進(jìn)行評估，提出反饋意見；在達(dá)到預(yù)期目的后，拋棄所建立的原型系統(tǒng)。

(2)演化式原型。與拋棄式原型相對應(yīng)，在已經(jīng)清楚地定義了需求的情況下，該原型并不被拋棄，而是演化成最終系統(tǒng)的一部分，從而為開發(fā)漸增式產(chǎn)品提供了堅實的構(gòu)造基礎(chǔ)。從原型的用途可以看出，建造軟件原型不同于最終系統(tǒng)，它需要花最小的代價盡快實現(xiàn)，因此，只要能夠體現(xiàn)原型的作用和滿足評價的要求，可以忽略一切暫時不關(guān)心的部分。正是由于這種忽略，演化型原型進(jìn)化為最終系統(tǒng)時需要十分小心，否則會對后期的開發(fā)造成很大問題。4.3.5基于用例的方法

隨著面向?qū)ο蠹夹g(shù)的發(fā)展，基于用例的方法在需求獲取和建模方面應(yīng)用得越來越普遍。這種方法是以任務(wù)和用戶為中心的，可以使用戶更清楚地認(rèn)識到新系統(tǒng)允許他們做什么。另外，用例有助于開發(fā)人員理解用戶的業(yè)務(wù)和應(yīng)用領(lǐng)域，并可以運用面向?qū)ο蟮姆治龊驮O(shè)計方法將用例轉(zhuǎn)化為對象模型。

在用例模型中，只是關(guān)心系統(tǒng)所應(yīng)實現(xiàn)的功能，而不關(guān)心內(nèi)部的具體實現(xiàn)細(xì)節(jié)。一般來說，用例模型的建立是由開發(fā)者和客戶共同協(xié)商完成的，通過反復(fù)討論需求的規(guī)格說明達(dá)成共識，明確系統(tǒng)的基本功能，為后續(xù)階段打下基礎(chǔ)。

(1)確定參與者。參與者代表著與系統(tǒng)交互的人或事。通過確認(rèn)系統(tǒng)功能的使用者和維護(hù)者以及與系統(tǒng)接口的其他系統(tǒng)或硬件設(shè)備等，可以有效地識別出系統(tǒng)的參與者。

(2)確定用例。用例描述了系統(tǒng)完成的動作序列，產(chǎn)生對參與者有價值的結(jié)果。一個完整的系統(tǒng)包含若干個用例，每個用例都具體說明了應(yīng)完成的功能。識別用例首先要確定系統(tǒng)所能反映的外部事件，并把這些事件與參與的執(zhí)行者和特定的使用實例聯(lián)系起來，最終繪制出用例圖。

(3)描述用例。單純地使用用例圖不能提供用例所具有的全部信息，因此，需要使用文字描述那些不能反映到圖形上的信息。用例描述實際上是關(guān)于參與者與系統(tǒng)如何交互的規(guī)格說明，要求清晰明確，沒有二義性。

4.4可?行?性?研?究

4.4.1意義

可行性研究又叫可行性分析，它是所有工程項目在開始階段必須進(jìn)行的一項工作。可行性研究是指在項目正式開發(fā)之前，先投入一定的精力，通過一套準(zhǔn)則，從經(jīng)濟(jì)、技術(shù)、社會等方面對項目的必要性、可能性、合理性以及項目所面臨的重大風(fēng)險進(jìn)行分析和評價，得出項目是否可行的結(jié)論。

可行性研究的結(jié)果無非有三種情況：

①可行，按計劃進(jìn)行；

②基本可行，對項目要求或方案做必要修改；

③不可行，不立項或終止項目。可行性研究一般需要從經(jīng)濟(jì)、技術(shù)、社會等方面進(jìn)行綜合分析，把這三個方面的分析工作稱為經(jīng)濟(jì)可行性、技術(shù)可行性和社會可行性。經(jīng)濟(jì)可行性分析一般要對項目進(jìn)行成本和效益估算，要求效益大于成本。同時，需要綜合進(jìn)行比較，對一個項目應(yīng)該提出幾種方案，選擇其中投入最小而收益最大的方案。對信息系統(tǒng)項目的效益分析時應(yīng)該注意它的社會效益。除了經(jīng)濟(jì)可行之外，還需要從技術(shù)上進(jìn)行論證。要論證項目所涉及到的關(guān)鍵技術(shù)是否已經(jīng)成熟，是否還存在重大的技術(shù)風(fēng)險。只有排除了重大技術(shù)風(fēng)險的項目才能夠立項開發(fā)。最后還要從社會角度論證項目的可行性。社會可行性包括的范圍比較廣泛，例如項目所要求的社會環(huán)境是否具備，項目的開發(fā)對社會公益是否會帶來負(fù)面影響，是否存在與社會道德、法律、制度等有相抵觸的地方。對于信息系統(tǒng)來講，還需要考慮企業(yè)員工的信息知識素養(yǎng)、企業(yè)管理水平、人們的社會生活習(xí)慣等方面的因素。經(jīng)濟(jì)、技術(shù)和社會三方面互有聯(lián)系，需要綜合考慮，不可偏執(zhí)一面。

信息系統(tǒng)可行性研究工作更為重要和復(fù)雜。首先對制定的信息系統(tǒng)總體規(guī)劃要進(jìn)行可行性論證；其次，要對在信息系統(tǒng)建設(shè)過程中，各次投入開發(fā)的信息系統(tǒng)項目進(jìn)行可行性分析；此外，隨著環(huán)境、需求和技術(shù)的發(fā)展變化，還要及時根據(jù)變化對信息系統(tǒng)建設(shè)帶來的影響進(jìn)行可行性分析。

信息系統(tǒng)規(guī)劃的可行性研究主要分析所制定的信息系統(tǒng)規(guī)劃是否符合企業(yè)發(fā)展的實際。信息系統(tǒng)規(guī)劃的可行性研究也是從經(jīng)濟(jì)、技術(shù)和社會等方面進(jìn)行分析，但需要更多地考慮所制定的信息系統(tǒng)規(guī)劃是否符合企業(yè)戰(zhàn)略目標(biāo)的需要，是否存在近期無法排除的重大風(fēng)險，規(guī)劃的安排是否符合企業(yè)現(xiàn)狀等方面的問題。由于信息系統(tǒng)規(guī)劃是企業(yè)信息系統(tǒng)建設(shè)的總綱領(lǐng)，它要指導(dǎo)企業(yè)信息系統(tǒng)長遠(yuǎn)建設(shè)，因此，對信息系統(tǒng)規(guī)劃的可行性研究必須慎之又慎。

信息系統(tǒng)建設(shè)是一個漫長的過程，需要分階段、分步驟完成。對每一個時期計劃開發(fā)的信息系統(tǒng)項目，也需要進(jìn)行可行性分析。這是因為，信息系統(tǒng)規(guī)劃的可行性研究是立足于長遠(yuǎn)和宏觀的信息系統(tǒng)總體建設(shè)，每一時期所要開發(fā)的信息系統(tǒng)項目則比較具體，需要對本項目的可行性進(jìn)行深入細(xì)致的分析。對于不可行的項目就要提前改換目標(biāo)、需求或方案，否則，便會終止項目開發(fā)，以至于造成無謂的損失。4.4.2可行性研究的內(nèi)容

1．經(jīng)濟(jì)可行性

經(jīng)濟(jì)可行性分析(EconomicFeasibility)也叫投資/效益分析或成本效益分析，它用來分析信息系統(tǒng)項目所需要的花費和項目開發(fā)成功之后所能帶來的經(jīng)濟(jì)效益。通俗地講，分析信息系統(tǒng)的經(jīng)濟(jì)可行性，就是分析該信息是否值得開發(fā)。顯然，在可行性分析中，經(jīng)濟(jì)可行性應(yīng)該是最重要的，企業(yè)所追求的目的就是效益和利潤，如果收益小于支出，企業(yè)顯然不會做這種虧本生意。投資/效益分析需要確定出所要開發(fā)的信息系統(tǒng)的總成本和總收益，然后對總成本和總收益進(jìn)行比較，當(dāng)總收益大于總成本時，這個項目才值得開發(fā)。信息系統(tǒng)的總成本包括開發(fā)總費用和運行管理總費用，信息系統(tǒng)總效益包括直接經(jīng)濟(jì)效益和間接社會效益。

信息系統(tǒng)總成本包括信息系統(tǒng)開發(fā)成本和運行成本。信息系統(tǒng)開發(fā)成本是指從立項到投入運行所花費的所有費用；而運行成本則是指信息系統(tǒng)投入使用之后，系統(tǒng)運行、管理和維護(hù)所花費的費用。例如，新建一個圖書館，需要規(guī)劃、設(shè)計和施工，還需要購買所有的建筑材料。假設(shè)整個圖書館的建設(shè)成本需要8000萬元人民幣。圖書館一旦建成投入使用，要保證日常運行，還需要管理、操作和維護(hù)費用，像水電費、管理費、維護(hù)費和人員費用等。每年圖書館的運行管理費用也可能只是整個開發(fā)成本的一個零頭，但在圖書館的使用期中，每年都需要操作管理費，所以，累計的操作管理費不一定比建設(shè)費用少。

信息系統(tǒng)的效益包括直接經(jīng)濟(jì)效益和間接社會效益。直接經(jīng)濟(jì)效益是信息系統(tǒng)能夠直接獲取的，并且能夠用資金度量的效益。如降低的成本、提高的資金周轉(zhuǎn)率、減少的人員成本以及減少的消耗等都是信息系統(tǒng)的直接經(jīng)濟(jì)效益，它們可以用資金進(jìn)行計算。間接社會效益是能夠整體地提高企業(yè)信譽(yù)和形象，提高企業(yè)的管理水平，但不能簡單地或無法用資金計算的那部分效益。間接社會效益常常需要系統(tǒng)分析員根據(jù)本企業(yè)的狀況和不同企業(yè)之間的類比進(jìn)行概括估計。通過比較成本和效益，就可以決定將要立項的信息系統(tǒng)是不是值得開發(fā)。一般比較的結(jié)論有三個：

①效益大于成本，開發(fā)對企業(yè)有價值；

②成本大于效益，不值得開發(fā)；

③效益和成本基本持平。

在進(jìn)行成本/效益分析時不要忽視信息系統(tǒng)給企業(yè)帶來的間接社會效益，對信息系統(tǒng)開發(fā)尤其要注意間接社會效益。簡單地從經(jīng)濟(jì)角度看，有些信息系統(tǒng)可能投入大于直接效益，但是它給企業(yè)帶來的間接效益很大，這類系統(tǒng)仍然要立項開發(fā)。

2．技術(shù)可行性

技術(shù)可行性(TechnicalFeasibility)分析用來在特定條件下，技術(shù)資源的可用性和這些技術(shù)資源用于解決信息系統(tǒng)問題的可能性和現(xiàn)實性。在進(jìn)行技術(shù)可行性分析時，一定要注意下述幾方面問題：

(1)應(yīng)該全面考慮信息系統(tǒng)開發(fā)過程中所涉及的所有技術(shù)問題。信息系統(tǒng)開發(fā)過程涉及多方面的技術(shù)、開發(fā)方法、軟硬件平臺、網(wǎng)絡(luò)結(jié)構(gòu)、系統(tǒng)布局和結(jié)構(gòu)、輸入輸出技術(shù)、系統(tǒng)相關(guān)技術(shù)等，應(yīng)該全面和客觀地分析信息系統(tǒng)開發(fā)所涉及的技術(shù)以及這些技術(shù)的成熟度和現(xiàn)實性。

(2)盡可能采用成熟技術(shù)。成熟技術(shù)是被多人采用并被反復(fù)證明行之有效的技術(shù)，因此采用成熟技術(shù)一般具有較高的成功率。另外，成熟技術(shù)經(jīng)過長時間、大范圍使用、補(bǔ)充和優(yōu)化，其精細(xì)程度、優(yōu)化程度、可操作性、經(jīng)濟(jì)性要比新技術(shù)好。鑒于以上原因，在開發(fā)信息系統(tǒng)過程中，在可以滿足系統(tǒng)開發(fā)需要、能夠適應(yīng)系統(tǒng)發(fā)展、保證開發(fā)成本的條件下，應(yīng)該盡量采用成熟技術(shù)。

(3)慎重引入先進(jìn)技術(shù)。在信息系統(tǒng)開發(fā)過程中，有時為了解決系統(tǒng)的一些特定問題，為了使所開發(fā)的信息系統(tǒng)具有更好的適應(yīng)性，也需要采用某些先進(jìn)或前沿技術(shù)。在選用先進(jìn)技術(shù)時，需要全面分析所選技術(shù)的成熟程度。有許多報道的先進(jìn)技術(shù)和科研成果實際上仍處在實驗室階段，其實用性和適應(yīng)性并沒有得到完全解決，也沒有經(jīng)過大量實踐驗證，在選擇這種技術(shù)時必須慎重。例如，在許多文章上已經(jīng)報道了指紋識別技術(shù)，而且市場上也有實驗性產(chǎn)品，但指紋識別技術(shù)至今仍有許多重大技術(shù)難題沒有突破，離實用仍有一定距離。因此，在項目開發(fā)中就要謹(jǐn)慎選用這種技術(shù)。如果不加分析，在項目中盲目采用了指紋識別技術(shù)，在應(yīng)用中肯定會出現(xiàn)許多難以解決的具體問題。

(4)著眼于具體的開發(fā)環(huán)境和開發(fā)人員。許多技術(shù)總的來看可能是成熟和可行的，但是在你的開發(fā)隊伍中如果沒有人掌握這種技術(shù)，而且在項目組中又沒有引進(jìn)掌握這種技術(shù)的人員，那么這種技術(shù)對本系統(tǒng)的開發(fā)仍然是不可行的。例如，分布對象技術(shù)是分布式系統(tǒng)的一種通用技術(shù)，但是如果在你的開發(fā)隊伍中沒有人掌握這種技術(shù)，那么從技術(shù)可行性上看就是不可行的。

3．社會可行性

社會可行性(SocietyFeasibility)具有比較廣泛的內(nèi)容，它需要從政策、法律、道德、制度、管理、人員等社會因素論證信息系統(tǒng)開發(fā)的可能性和現(xiàn)實性。例如，對信息系統(tǒng)所服務(wù)的行業(yè)以及應(yīng)用領(lǐng)域，國家和地方已經(jīng)頒布的法律和行政法規(guī)是否與所開發(fā)的系統(tǒng)相抵觸?企業(yè)的管理制度與信息系統(tǒng)開發(fā)是否存在矛盾的地方?人員的素質(zhì)和人員的心理是否為信息系統(tǒng)開發(fā)和運行提供了準(zhǔn)備?諸如此類問題都屬于社會可行性需要研究的問題。社會可行性還需要考慮操作可行性(OperationalFeasibility)。操作可行性是指分析和測定給定信息系統(tǒng)在確定環(huán)境中能夠有效地從事工作并被用戶方便使用的程度和能力。

操作可行性需要考慮以下方面：

①問題域的手工業(yè)務(wù)流程、新系統(tǒng)的流程、兩種流程的相近程度和差距；

②系統(tǒng)業(yè)務(wù)的專業(yè)化程度；

③系統(tǒng)對用戶的使用要求；

④系統(tǒng)界面的友好程度以及操作的方便程度；

⑤用戶的實際能力。分析操作可行性必須立足于實際操作和使用信息系統(tǒng)的用戶環(huán)境。例如，A公司的全體收款員都能夠熟練地運用收款電腦進(jìn)行收款業(yè)務(wù)，并不意味著B公司的收款員也就必然能做同樣的事情?？尚行匝芯康膬?nèi)容之一就是要判斷B公司收款員當(dāng)前所具有的能力，以便于下一步為他們的改變做出適中的決定。

4.4.3可行性研究報告

可行性研究完成之后要編寫可行性研究報告。可行性研究報告包括信息系統(tǒng)概要介紹、可行性研究過程和可行性研究結(jié)論等內(nèi)容。下面給出了可行性研究報告的簡要提綱。 4.5需求建模

4.5.1需求建模方法

需求分析是解決軟件做什么的問題，即定義要解決的問題，而不涉及怎么做的問題。需求分析建立的系統(tǒng)模型是用軟件工程的“語言”來描述要開發(fā)項目的數(shù)據(jù)、功能和控制需求的。在結(jié)構(gòu)化分析設(shè)計中它們是下一步設(shè)計的基礎(chǔ)。需求分析要產(chǎn)生軟件運行特征的規(guī)約，指明軟件和其他系統(tǒng)元素的接口并建立軟件必須滿足的約束，還要為軟件提供一份系統(tǒng)建成后評估其質(zhì)量的依據(jù)。書寫文檔是系統(tǒng)分析規(guī)約的方式，只有變成規(guī)約文檔才能消除歧義。但是計算機(jī)需求的最好表示方式是文檔和圖表相結(jié)合，這樣不但容易理解，而且更重要的是可以直接通過評審正確性、完整性和一致性的方式來描述數(shù)據(jù)、功能和行為的需求。

形式化的語言，甚至一些計算機(jī)術(shù)語都使用戶難以理解，因此，用文字表達(dá)很難清楚展現(xiàn)系統(tǒng)的體系結(jié)構(gòu)，表示系統(tǒng)的需求。而采用圖表的形式，可以使用戶比較容易看懂，很容易和用戶交流，有利于需求分析的評審。用圖表來表示系統(tǒng)需求，其本身就是一個建模過程。在技術(shù)層次上，軟件工程是從一系列建模任務(wù)開始的，這些任務(wù)的完成才定義了將被建立的軟件的完整需求。換句話說，所謂建模，實際上就是使用圖表的形式來表示系統(tǒng)的各個方面以及各個視圖。

常用的系統(tǒng)分析建模方法有兩種：一種是結(jié)構(gòu)化分析方法，一種是面向?qū)ο蟮姆治龇椒?。結(jié)構(gòu)化的系統(tǒng)分析方法是傳統(tǒng)的建模方法。所謂結(jié)構(gòu)化分析，就是有規(guī)則地進(jìn)行分析，有規(guī)則地表達(dá)出來。結(jié)構(gòu)化分析從數(shù)據(jù)流進(jìn)行分析，用數(shù)據(jù)流程圖把要開發(fā)的軟件功能結(jié)構(gòu)表示出來，這種圖形就是軟件的功能模型，所以它是一種建?；顒印＝Y(jié)構(gòu)化分析的“結(jié)構(gòu)化”表現(xiàn)在把要解決的問題抽象出來，抓住本質(zhì)的東西，忽略細(xì)節(jié)，逐層分解到可理解的程度，越高層的抽象級別越高，這就是常說的自頂向下的分解。而表達(dá)的工具就是數(shù)據(jù)流程圖、實體關(guān)系圖和數(shù)據(jù)字典。結(jié)構(gòu)化分析的核心就是自頂向下的分解和自底向上的抽象。

術(shù)語結(jié)構(gòu)化分析最初由DouglassRoss提出，DeMarco對其進(jìn)行了推廣，引入了使得分析員可以創(chuàng)建信息流模型的關(guān)鍵圖形符號，提出了使用這些符號建立模型的方法。以后結(jié)構(gòu)化系統(tǒng)分析方法又被擴(kuò)展，引入了適用于實時系統(tǒng)的行為模型、狀態(tài)圖等。4.5.2實體—關(guān)系圖

數(shù)據(jù)模型包含三種相互關(guān)聯(lián)的信息：數(shù)據(jù)對象、描述數(shù)據(jù)對象的屬性及數(shù)據(jù)對象彼此間相互連接的關(guān)系。

1．?dāng)?shù)據(jù)對象

數(shù)據(jù)對象是對軟件必須理解的復(fù)合信息的表示。所謂復(fù)合信息，是指具有一系列不同性質(zhì)或?qū)傩缘氖挛?，因此僅有單個值的事物(例如寬度)不是數(shù)據(jù)對象。

數(shù)據(jù)對象可以是外部實體(例如產(chǎn)生或使用信息的任何事物)、事物(例如報表或屏幕顯示)、行為(例如打電話)或事件(例如響警報)、角色(例如銷售員)、單位(例如會計科)以及地點(例如倉庫)或結(jié)構(gòu)(例如文件)等。例如，教師、學(xué)生、課程和汽車等都可以認(rèn)為是數(shù)據(jù)對象，因為它們都可以由一組屬性來定義?！皵?shù)據(jù)對象描述”中包含了數(shù)據(jù)對象及其所有屬性。

數(shù)據(jù)對象彼此間是有關(guān)聯(lián)的，例如，教師“教”課程，學(xué)生“學(xué)”課程，教或?qū)W的關(guān)系表示教師和課程或?qū)W生和課程之間的一種特定的連接。

數(shù)據(jù)對象只封裝了數(shù)據(jù)而沒有對作用于數(shù)據(jù)上的操作進(jìn)行引用，這是數(shù)據(jù)對象與面向?qū)ο蠓缎椭械摹邦悺被颉皩ο蟆钡娘@著區(qū)別。

2．屬性

屬性定義了數(shù)據(jù)對象的性質(zhì)。屬性可以具有下述三種不同的特性之一，也就是說，可以用屬性來：①為數(shù)據(jù)對象的實例命名；②描述該實例；③引用另一個數(shù)據(jù)對象的實例。此外，必須把一個或多個屬性定義為“標(biāo)識符”，即當(dāng)我們希望找到數(shù)據(jù)對象的一個實例時，標(biāo)識符屬性成為“關(guān)鍵字”。

應(yīng)該根據(jù)對所要解決的問題的理解，來確定特定數(shù)據(jù)對象的一組合適的屬性。例如，為了開發(fā)機(jī)動車管理系統(tǒng)，描述汽車的屬性應(yīng)該是制造商、品牌、型號、發(fā)動機(jī)號碼、車體類型、顏色、車主姓名、住址、駕駛證號碼、生產(chǎn)日期以及購買日期等。但是，為了開發(fā)設(shè)計汽車的CAD系統(tǒng)，用上述這些屬性描述汽車就不合適了，其中車主姓名、住址、駕駛證號碼、生產(chǎn)日期和購買日期等屬性都應(yīng)該刪去，而描述汽車技術(shù)指標(biāo)的大量屬性應(yīng)該增添進(jìn)來。

3．關(guān)系

數(shù)據(jù)對象彼此之間相互連接的方式稱為關(guān)系，也稱為聯(lián)系。

客觀世界中的事物彼此間往往是有聯(lián)系的。例如，教師與課程間存在“教”這種聯(lián)系，而學(xué)生與課程間則存在“學(xué)”這種聯(lián)系。聯(lián)系可分為以下三類。

(1)一對一聯(lián)系(1∶1)。如果對于實體集A中的每一個實體，實體集B中至多有一個(也可以沒有)實體與之聯(lián)系，反之亦然，則稱實體集A與實體集B具有一對一聯(lián)系，記為1∶1。

例如，一個部門有一個經(jīng)理，而每個經(jīng)理只在一個部門任職，則部門與經(jīng)理的聯(lián)系是一對一的，如圖4.5所示。圖4.51∶1關(guān)系

(2)一對多聯(lián)系(1∶N)。如果對于實體集A中的每一個實體，實體集B中有N個實體(N≥0)與之聯(lián)系，反之，對于實體集B中的每一個實體，實體集A中至多只有一個實體與之聯(lián)系，則稱實體集A與實體集B有一對多聯(lián)系，記為1∶N。

例如，某校教師與課程之間存在一對多的聯(lián)系“教”，即每位教師可以教多門課程，但是每門課程只能由一位教師來教，如圖4.6所示。圖4.61∶N關(guān)系

(3)多對多聯(lián)系(M∶N)。如果對于實體集A中的每一個實體，實體集B中有N個實體(N≥0)與之聯(lián)系，反之，對于實體集B中的每一個實體，實體集A中也有M個實體(M≥0)與之聯(lián)系，則稱實體集A與實體集B具有多對多聯(lián)系，記為M∶N。

例如，圖4.7表示學(xué)生與課程間的聯(lián)系“學(xué)”是多對多的，即一個學(xué)生可以學(xué)多門課程，而每門課程可以有多個學(xué)生來學(xué)。圖4.7M∶N關(guān)系如圖4.8所示，聯(lián)系也可能有屬性。例如，學(xué)生“學(xué)”某門課程所取得的成績，既不是學(xué)生的屬性也不是課程的屬性。由于“成績”既依賴于某名特定的學(xué)生又依賴于某門特定的課程，所以這是學(xué)生與課程之間的聯(lián)系“學(xué)”的屬性。圖4.8聯(lián)系的屬性

4．實體-關(guān)系圖的符號

通常，使用實體-關(guān)系圖(EntityRelationshipDiagram)來建立數(shù)據(jù)模型，我們常把實體-關(guān)系圖簡稱為E-R圖，相應(yīng)地，用E-R圖描繪的數(shù)據(jù)模型也稱為E-R模型。

E-R圖中包含了實體(即數(shù)據(jù)對象)、關(guān)系和屬性等三種基本成分。通常用矩形框代表實體，用連接相關(guān)實體的菱形框表示關(guān)系，用橢圓形或圓角矩形表示實體(或關(guān)系)的屬性，并用無向邊把實體(或關(guān)系)與其屬性連接起來。例如，圖4.9是某校教學(xué)管理的E-R圖。圖4.9某校教學(xué)管理的E-R圖4.5.3數(shù)據(jù)流圖

當(dāng)信息在軟件中移動時，它將被一系列“變換”所修改。數(shù)據(jù)流圖(DFD)是一種圖形化技術(shù)，它描繪信息流和數(shù)據(jù)從輸入移動到輸出的過程中所經(jīng)受的變換。在數(shù)據(jù)流圖中沒有任何具體的物理元素，它只是描繪信息在軟件中流動和被處理的情況。因為數(shù)據(jù)流圖是系統(tǒng)邏輯功能的圖形表示，即使不是專業(yè)的計算機(jī)技術(shù)人員也容易理解它，所以它是分析員與用戶之間極好的通信工具。此外，設(shè)計數(shù)據(jù)流圖時只需考慮系統(tǒng)必須完成的基本邏輯功能，完全不需考慮怎樣具體地實現(xiàn)這些功能，因此，它也是今后進(jìn)行軟件設(shè)計的很好的出發(fā)點?？梢栽谌魏纬橄髮哟紊?，使用數(shù)據(jù)流圖表示系統(tǒng)或軟件。事實上，可以分層次地畫數(shù)據(jù)流圖，層次越低表現(xiàn)出的信息流細(xì)節(jié)和功能細(xì)節(jié)也越多。數(shù)據(jù)流圖既提供了功能建模機(jī)制，也提供了信息流建模機(jī)制。

1．?dāng)?shù)據(jù)流圖符號

如圖4.10(a)所示，數(shù)據(jù)流圖有四種基本符號：正方形(或立方體)表示數(shù)據(jù)的源點或終點；圓角矩形(或圓形)代表變換數(shù)據(jù)的處理；開口矩形(或兩條平行橫線)代表數(shù)據(jù)存儲；箭頭表示數(shù)據(jù)流，即特定數(shù)據(jù)的流動方向。注意，數(shù)據(jù)流與程序流程圖中用箭頭表示的控制流有本質(zhì)不同，千萬不要混淆。熟悉程序流程圖的初學(xué)者在畫數(shù)據(jù)流圖時，往往試圖在數(shù)據(jù)流圖中表現(xiàn)分支條件或循環(huán)，殊不知這樣做將造成混亂，畫不出正確的數(shù)據(jù)流圖。在數(shù)據(jù)流圖中應(yīng)該描繪所有可能的數(shù)據(jù)流向，而不應(yīng)該描繪出現(xiàn)某個數(shù)據(jù)流的條件。圖4.10數(shù)據(jù)流圖的符號(a)基本符號的含義；(b)附加符號的含義處理并不一定是一個程序。一個處理框可以代表一系列程序、單個程序或者程序的一個模塊；它甚至可以代表用穿孔機(jī)穿孔或目視檢查數(shù)據(jù)正確性等人工處理過程。一個數(shù)據(jù)存儲也并不等同于一個文件，它可以表示一個文件、文件的一部分、數(shù)據(jù)庫的元素或記錄的一部分等，數(shù)據(jù)可以存儲在磁盤、磁帶、磁鼓、主存、微縮膠片、穿孔卡片及其他任何介質(zhì)上(包括人腦)。

數(shù)據(jù)存儲和數(shù)據(jù)流都是數(shù)據(jù)，它們的區(qū)別僅是所處的狀態(tài)不同。數(shù)據(jù)存儲是處于靜止?fàn)顟B(tài)的數(shù)據(jù)，數(shù)據(jù)流是處于運動中的數(shù)據(jù)。

通常在數(shù)據(jù)流圖中忽略出錯處理，也不包括諸如打開或關(guān)閉文件之類的內(nèi)務(wù)處理，數(shù)據(jù)流圖的基本要點是描繪“做什么”，而不考慮“怎樣做”。有時數(shù)據(jù)的源點和終點相同，這時如果只用一個符號代表數(shù)據(jù)的源點和終點，則將有兩個箭頭和這個符號相連(一個進(jìn)一個出)，可能其中一條箭頭線相當(dāng)長，這將降低數(shù)據(jù)流圖的清晰度。另一種表示方法是再重復(fù)畫一個同樣的符號(正方形或立方體)表示數(shù)據(jù)的終點。有時數(shù)據(jù)存儲也需要重復(fù)，以增加數(shù)據(jù)流圖的清晰程度。為了避免可能引起的誤解，如果代表同一個事物的同樣符號在圖中出現(xiàn)在n個地方，則在這個符號的一個角上畫n-1條短斜線做標(biāo)記。

除了上述四種基本符號之外，有時也使用幾種附加符號。星號(*)表示數(shù)據(jù)流之間是“與”關(guān)系(同時存在)；加號(+)表示“或”關(guān)系；

號表示只能從中選一個(互斥的關(guān)系)。圖4.10(b)所示為這些附加符號的含義。

2．?dāng)?shù)據(jù)流圖例子

下面通過一個簡單的例子來具體說明怎樣畫數(shù)據(jù)流圖。

假設(shè)一家工廠的采購部每天需要一張訂貨報表，報表按零件編號排序，表中列出所有需要再次訂貨的零件。對于每個需要再次訂貨的零件應(yīng)該列出下述數(shù)據(jù)：零件編號、零件名稱、定貨數(shù)量、目前價格、主要供應(yīng)者和次要供應(yīng)者。零件入庫或出庫稱為事務(wù)，通過放在倉庫中的CRT終端把事務(wù)報告給訂貨系統(tǒng)。當(dāng)某種零件的庫存數(shù)量少于庫存量臨界值時就應(yīng)該再次訂貨。

數(shù)據(jù)流圖有四種成分：源點或終點、處理、數(shù)據(jù)存儲和數(shù)據(jù)流。因此，畫出上述訂貨系統(tǒng)的數(shù)據(jù)流圖可采用以下步驟：

(1)從問題描述中提取數(shù)據(jù)流圖的四種成分。首先考慮數(shù)據(jù)的源點和終點，從上面對系統(tǒng)的描述可以知道“采購部每天需要一張訂貨報表”，“通過放在倉庫中的CRT終端把事務(wù)報告給訂貨系統(tǒng)”，所以采購員是數(shù)據(jù)終點，而倉庫管理員是數(shù)據(jù)源點。

(2)考慮處理。再一次閱讀問題描述：“采購部需要報表”，顯然他們還沒有這種報表，因此必須有一個用于產(chǎn)生報表的處理。事務(wù)的后果是改變零件庫存量，而任何改變數(shù)據(jù)的操作都是處理，因此對事務(wù)進(jìn)行的加工是另一個處理。注意，在問題描述中并沒有明顯地提到需要對事務(wù)進(jìn)行處理，但是通過分析可以看出這種需要。

(3)考慮數(shù)據(jù)流和數(shù)據(jù)存儲。系統(tǒng)把訂貨報表送給采購部，因此訂貨報表是一個數(shù)據(jù)流；事務(wù)需要從倉庫送到系統(tǒng)中，顯然事務(wù)是另一個數(shù)據(jù)流。產(chǎn)生報表和處理事務(wù)這兩個處理在時間上明顯不匹配——每當(dāng)有一個事務(wù)發(fā)生時立即處理它，然而每天只產(chǎn)生一次定貨報表。

因此，用來產(chǎn)生定貨報表的數(shù)據(jù)必須存放一段時間，也就是應(yīng)該有一個數(shù)據(jù)存儲。

注意，并不是所有數(shù)據(jù)存儲和數(shù)據(jù)流都能直接從問題描述中提取出來。例如，“當(dāng)某種零件的庫存數(shù)量少于庫存量臨界值時就應(yīng)該再次訂貨”，這個事實意味著必須在某個地方有零件庫存量和庫存量臨界值這樣的數(shù)據(jù)。因為這些數(shù)據(jù)元素的存在時間看來應(yīng)該比單個事務(wù)的存在時間長，所以認(rèn)為有一個數(shù)據(jù)存儲來保存庫存清單數(shù)據(jù)是合理的。表4.5列出了上面分析的結(jié)果，其中加星號標(biāo)記的是在問題描述中隱含的成分。表4.5組成數(shù)據(jù)流圖的元素可以從描述問題的信息中提取一旦把數(shù)據(jù)流圖的四種成分分離出來，就可以著手畫數(shù)據(jù)流圖了。但是要注意，數(shù)據(jù)流圖是系統(tǒng)的邏輯模型，而任何計算機(jī)系統(tǒng)實質(zhì)上都是信息處理系統(tǒng)，也就是說計算機(jī)系統(tǒng)本質(zhì)上都是把輸入數(shù)據(jù)變換成輸出數(shù)據(jù)。因此，任何系統(tǒng)的基本模型都由若干個數(shù)據(jù)源點/終點以及一個處理組成，這個處理就代表了系統(tǒng)對數(shù)據(jù)加工變換的基本功能。對于上述的訂貨系統(tǒng)可以畫出如圖4.11所示的基本系統(tǒng)模型。

圖4.11訂貨系統(tǒng)的基本系統(tǒng)模型從基本系統(tǒng)模型這樣非常高的抽象層次開始畫數(shù)據(jù)流圖是一個好辦法。在這個高層次的數(shù)據(jù)流圖上是否列出了所有給定的數(shù)據(jù)源點/終點是一目了然的，因此它是很有價值的通信工具。然而，圖4.11畢竟太抽象了，從這張圖上所能了解到的訂貨系統(tǒng)的信息非常有限。下一步應(yīng)該把基本系統(tǒng)模型細(xì)化，描繪系統(tǒng)的主要功能。由表4.5可知，“產(chǎn)生報表”和“處理事務(wù)”是系統(tǒng)必須完成的兩個主要功能，它們將代替圖4.11中的“訂貨系統(tǒng)”。此外，細(xì)化后的數(shù)據(jù)流圖中還增加了兩個數(shù)據(jù)存儲：處理事務(wù)需要“庫存清單”數(shù)據(jù)；產(chǎn)生報表和處理事務(wù)在不同時間，因此需要存儲“訂貨信息”。除了表4.5中列出的兩個數(shù)據(jù)流之外還有另外兩個數(shù)據(jù)流，它們與數(shù)據(jù)存儲相同。這是因為從一個數(shù)據(jù)存儲中取出來的或放進(jìn)去的數(shù)據(jù)通常和原來存儲的數(shù)據(jù)相同，也就是說，數(shù)據(jù)存儲和數(shù)據(jù)流只不過是同樣數(shù)據(jù)的兩種不同形式。在圖4.12中給處理和數(shù)據(jù)存儲都加了編號，這樣做的目的是便于引用和追蹤。圖4.12訂貨系統(tǒng)的功能級數(shù)據(jù)流圖接下來應(yīng)該對功能級數(shù)據(jù)流圖中描繪的系統(tǒng)主要功能進(jìn)一步細(xì)化?？紤]通過系統(tǒng)的邏輯數(shù)據(jù)流，當(dāng)發(fā)生一個事務(wù)時必須首先接收它，隨后按照事務(wù)的內(nèi)容修改庫存清單，如果更新后的庫存量少于庫存量臨界值，則應(yīng)該再次訂貨，也就是需要處理訂貨信息。因此，把“處理事務(wù)”這個功能分解為下述三個步驟：“接收事務(wù)”、“更新庫存清單”和“處理訂貨”(見圖4.13)，這在邏輯上是合理的。圖4.13把處理事務(wù)的功能進(jìn)一步分解后的數(shù)據(jù)流圖我們?yōu)槭裁床贿M(jìn)一步分解“產(chǎn)生報表”這個功能呢？因為訂貨報表中需要的數(shù)據(jù)在存儲的訂貨信息中全都有，產(chǎn)生報表只不過是按一定順序排列這些信息，再按一定格式打印出來。然而這些考慮純屬具體實現(xiàn)的細(xì)節(jié)，不應(yīng)該在數(shù)據(jù)流圖中表現(xiàn)。同樣道理，對“接收事務(wù)”或“更新庫存清單”等功能也沒有必要進(jìn)一步細(xì)化?？傊?，當(dāng)進(jìn)一步分解將涉及如何具體地實現(xiàn)一個功能時，就不應(yīng)該再分解了。

在對數(shù)據(jù)流圖分層細(xì)化時必須保持信息連續(xù)性。也就是說，當(dāng)把一個處理分解為一系列處理時，分解前和分解后的輸入/輸出數(shù)據(jù)流必須相同。例如，圖4.11和圖4.12所示的輸入/輸出數(shù)據(jù)流都是“事務(wù)”和“訂貨報表”；圖4.13中“處理事務(wù)”這個處理框的輸入/輸出數(shù)據(jù)流是“事務(wù)”、“庫存清單”和“訂貨信息”，分解成“接收事務(wù)”、“更新庫存清單”和“處理訂貨”三個處理之后，它們的輸入/輸出數(shù)據(jù)流仍然是“事務(wù)”、“庫存清單”和“訂貨信息”。

此外還應(yīng)該注意在圖4.13中對處理進(jìn)行編號的方法。處理1.1、1.2和1.3是更高層次的數(shù)據(jù)流圖(見圖4.12)中處理1的組成元素。如果處理2被進(jìn)一步分解，它的組成元素的編號將是2.1，2.2……如果把處理1.1進(jìn)一步分解，則將得到編號為1.1.1，1.1.2……的處理。

3．命名

數(shù)據(jù)流圖中每個成分的命名是否恰當(dāng)，直接影響數(shù)據(jù)流圖的可理解性。因此，給這些成分起名字時應(yīng)該仔細(xì)推敲。下面講述在命名時應(yīng)注意的問題。

(1)為數(shù)據(jù)流(或數(shù)據(jù)存儲)命名。

①名字應(yīng)代表整個數(shù)據(jù)流(或數(shù)據(jù)存儲)的內(nèi)容，而不是僅僅反映它的某些成分。

②不要使用空洞的、缺乏具體含義的名字(如“數(shù)據(jù)”、“信息”、“輸入”之類)。

③如果在為某個數(shù)據(jù)流(或數(shù)據(jù)存儲)起名字時遇到了困難，則很可能是因為對數(shù)據(jù)流圖分解不恰當(dāng)造成的，應(yīng)該試試重新分解，看是否能克服這個困難。

(2)為處理命名。

①通常先為數(shù)據(jù)流命名，然后再為與之相關(guān)聯(lián)的處理命名。這樣命名比較容易，而且體現(xiàn)了人類習(xí)慣的“由表及里”的思考過程。

②名字應(yīng)該反映整個處理的功能，而不是它的一部分功能。

③名字最好由一個具體的及物動詞，加上一個具體的賓語組成。應(yīng)該盡量避免使用“加工”、“處理”等空洞籠統(tǒng)的動詞作名字。

④通常名字中僅包括一個動詞。如果必須用兩個動詞才能描述整個處理的功能，則把這個處理再分解成兩個處理可能更恰當(dāng)些。⑤如果在為某個處理命名時遇到困難，則很可能是發(fā)現(xiàn)了分解不當(dāng)?shù)嫩E象，應(yīng)考慮重新分解。

數(shù)據(jù)源點/終點并不需要在開發(fā)目標(biāo)系統(tǒng)的過程中設(shè)計和實現(xiàn)，它并不屬于數(shù)據(jù)流圖的核心內(nèi)容，只不過是目標(biāo)系統(tǒng)的外圍環(huán)境部分(可能是人員、計算機(jī)外部設(shè)備或傳感器裝置)。通常，為數(shù)據(jù)源點/終點命名時采用它們在問題域中習(xí)慣使用的名字(如“采購員”、“倉庫管理員”等)。4.5.4狀態(tài)轉(zhuǎn)換圖

狀態(tài)轉(zhuǎn)換圖(簡稱狀態(tài)圖)通過描繪系統(tǒng)的狀態(tài)及引起系統(tǒng)狀態(tài)轉(zhuǎn)換的事件，來表示系統(tǒng)的行為。此外，狀態(tài)圖還指出了作為特定事件的結(jié)果系統(tǒng)將做哪些動作(例如處理數(shù)據(jù))。因此，狀態(tài)圖提供了行為建模機(jī)制，可以滿足第3條分析準(zhǔn)則的要求。

1．狀態(tài)

狀態(tài)是任何可以被觀察到的系統(tǒng)行為模式，一個狀態(tài)代表系統(tǒng)的一種行為模式。狀態(tài)規(guī)定了系統(tǒng)對事件的響應(yīng)方式，系統(tǒng)對事件的響應(yīng)既可以是做一個(或一系列)動作，也可以是僅僅改變系統(tǒng)本身的狀態(tài)，還可以是既改變狀態(tài)又做動作。在狀態(tài)圖中定義的狀態(tài)主要有初態(tài)(即初始狀態(tài))、終態(tài)(即最終狀態(tài))和中間狀態(tài)。在一張狀態(tài)圖中只能有一個初態(tài)，而終態(tài)則可以有0至多個。

狀態(tài)圖既可以表示系統(tǒng)循環(huán)動作過程，也可以表示系統(tǒng)單程生命期。當(dāng)描繪循環(huán)運行過程時，通常并不關(guān)心循環(huán)是怎樣啟動的；當(dāng)描繪單程生命期時，需要標(biāo)明初始狀態(tài)(系統(tǒng)啟動時進(jìn)入初始狀態(tài))和最終狀態(tài)(系統(tǒng)運行結(jié)束時到達(dá)最終狀態(tài))。

2．事件

事件是在某個特定時刻發(fā)生的事情，它是對引起系統(tǒng)做動作或(和)從一個狀態(tài)轉(zhuǎn)換到另一個狀態(tài)的外界事件的抽象。例如，內(nèi)部時鐘表明某個規(guī)定的時間段已經(jīng)過去，用戶移動或點擊鼠標(biāo)等都是事件。簡而言之，事件就是引起系統(tǒng)做動作或(和)轉(zhuǎn)換狀態(tài)的控制信息。

3．符號

在狀態(tài)圖中，初態(tài)用實心圓表示，終態(tài)用一對同心圓(內(nèi)圓為實心圓)表示。

中間狀態(tài)用圓角矩形表示，可以用兩條水平橫線把它分成上、中、下3個部分。上面部分為狀態(tài)的名稱，這部分是必須有的；中間部分為狀態(tài)變量的名字和值，這部分是可選的；下面部分是活動表，這部分也是可選的。活動表的語法格式如下：

事件名(參數(shù)表)/動作表達(dá)式

其中，“事件名”可以是任何事件的名稱。在活動表中經(jīng)常使用下述3種標(biāo)準(zhǔn)事件：entry、exit和do。entry事件指定進(jìn)入該狀態(tài)的動作，exit事件指定退出該狀態(tài)的動作，而do事件則指定在該狀態(tài)下的動作。需要時可以為事件指定參數(shù)表。活動表中的動作表達(dá)式描述應(yīng)做的具體動作。

狀態(tài)圖中兩個狀態(tài)之間帶箭頭的連線稱為狀態(tài)轉(zhuǎn)換，箭頭指明了轉(zhuǎn)換方向。狀態(tài)變遷通常是由事件觸發(fā)的，在這種情況下應(yīng)在表示狀態(tài)轉(zhuǎn)換的箭頭線上標(biāo)出觸發(fā)轉(zhuǎn)換的事件表達(dá)式；如果在箭頭線上未標(biāo)明事件，則表示在源狀態(tài)的內(nèi)部活動執(zhí)行完之后自動觸發(fā)轉(zhuǎn)換。事件表達(dá)式的語法如下：

事件說明[守衛(wèi)條件]?/?動作表達(dá)式

其中，事件說明的語法為：事件名(參數(shù)表)。

守衛(wèi)條件是一個布爾表達(dá)式。如果同時使用事件說明和守衛(wèi)條件，則當(dāng)且僅當(dāng)事件發(fā)生且布爾表達(dá)式為真時，狀態(tài)轉(zhuǎn)換才發(fā)生；如果只有守衛(wèi)條件沒有事件說明，則只要守衛(wèi)條件為真，狀態(tài)轉(zhuǎn)換就發(fā)生。

動作表達(dá)式是一個過程表達(dá)式，當(dāng)狀態(tài)轉(zhuǎn)換開始時執(zhí)行該表達(dá)式。

圖4.14所示為狀態(tài)圖中使用的主要符號。圖4.14狀態(tài)圖中使用的主要符號

4．狀態(tài)圖例子

為了具體說明怎樣用狀態(tài)圖建立系統(tǒng)的行為模型，下面舉一個例子。圖4.15是人們非常熟悉的電話系統(tǒng)的狀態(tài)圖。圖4.15電話系統(tǒng)的狀態(tài)圖4.5.5數(shù)據(jù)字典

如前所述，分析模型包括數(shù)據(jù)模型、功能模型和行為模型。在上述任何一種模型中，數(shù)據(jù)對象或控制信息都有重要作用。因此，需要有一種系統(tǒng)化的方式來表示每個數(shù)據(jù)對象和控制信息的特性，數(shù)據(jù)字典正是用來完成這項任務(wù)的。

數(shù)據(jù)字典是在描述結(jié)構(gòu)化分析過程中定義對象的內(nèi)容時所使用的一種半形式化的工具。下面是對這個重要的建模工具的定義。

數(shù)據(jù)字典是所有與系統(tǒng)相關(guān)的