《軟件詳細設計教程》課件第4章

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

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

《IEEEStandardGlossaryofSoftwareEngineeringTerminology》給出了有關軟件需求的如下定義：

①用戶解決問題或達到目標所需的條件或能力。

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

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

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

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

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

●客戶：產品為誰服務？目標客戶是誰?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.1.4系統(tǒng)需求

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

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

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

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

4.2需求工程過程

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

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

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

需求獲取應該集中在用戶任務上，而不是集中在用戶接口上，其主要工作內容包括：

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

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

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

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

需求分析的主要工作內容包括：

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

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

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

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

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

(6)創(chuàng)建數(shù)據(jù)字典。數(shù)據(jù)字典定義了系統(tǒng)中使用的所有數(shù)據(jù)項及其結構，至少應該定義客戶的數(shù)據(jù)項，以確?？蛻艉烷_發(fā)人員使用一致的定義和術語。

多年來，人們提出了許多分析建模的方法，其中占主導地位的是傳統(tǒng)的結構化分析方法和當今流行的面向對象分析方法。4.2.3需求規(guī)格說朋

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

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

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

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

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

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

1．正確性

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

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

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

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

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

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

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

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

2．無二義性

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

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

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

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

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

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

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

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

3．完整性

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

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

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

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

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

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

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

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

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

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

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

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

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

4．可驗證性

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

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

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

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

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

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

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

5．一致性

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

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

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

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

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

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

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

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

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

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

6．可修改性

可修改性是指需求規(guī)格說明的格式和組織方式應保證后續(xù)的修改比較容易進行和協(xié)調一致?？梢允褂密浖ぞ呋蛘吣夸洷?、索引和相互參照列表等方法使軟件需求規(guī)格說明更容易修改。

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

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

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

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

7．可跟蹤性

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

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

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

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

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

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

1．需求變更控制

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

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

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

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

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

(4)項目要按一定的程序實施需求變更。

2．需求文檔的版本控制

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

3．需求跟蹤

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

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

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

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

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

4.3需求獲取技術

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

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

4.3.1面談

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

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

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

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

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

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

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

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

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

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

●所有的風險承擔人都暢所欲言；

●它促進風險承擔人和開發(fā)團隊之間達成共識；

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

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

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

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

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

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

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

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

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

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

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

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

4.3.4原型化方法

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

(1)拋棄式原型。拋棄式原型首先選擇適當?shù)难菔竟δ埽⒚枋鱿鄳挠脩艚缑?，然后構造軟件原型；用戶對所構造的軟件原型進行評估，提出反饋意見；在達到預期目的后，拋棄所建立的原型系統(tǒng)。

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

隨著面向對象技術的發(fā)展，基于用例的方法在需求獲取和建模方面應用得越來越普遍。這種方法是以任務和用戶為中心的，可以使用戶更清楚地認識到新系統(tǒng)允許他們做什么。另外，用例有助于開發(fā)人員理解用戶的業(yè)務和應用領域，并可以運用面向對象的分析和設計方法將用例轉化為對象模型。

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

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

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

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

4.4可?行?性?研?究

4.4.1意義

可行性研究又叫可行性分析，它是所有工程項目在開始階段必須進行的一項工作?？尚行匝芯渴侵冈陧椖空介_發(fā)之前，先投入一定的精力，通過一套準則，從經濟、技術、社會等方面對項目的必要性、可能性、合理性以及項目所面臨的重大風險進行分析和評價，得出項目是否可行的結論。

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

①可行，按計劃進行；

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

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

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

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

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

1．經濟可行性

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

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

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

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

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

③效益和成本基本持平。

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

2．技術可行性

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

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

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

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

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

3．社會可行性

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

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

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

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

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

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

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

4.4.3可行性研究報告

可行性研究完成之后要編寫可行性研究報告?？尚行匝芯繄蟾姘ㄐ畔⑾到y(tǒng)概要介紹、可行性研究過程和可行性研究結論等內容。下面給出了可行性研究報告的簡要提綱。 4.5需求建模

4.5.1需求建模方法

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

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

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

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

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

1．數(shù)據(jù)對象

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

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

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

數(shù)據(jù)對象只封裝了數(shù)據(jù)而沒有對作用于數(shù)據(jù)上的操作進行引用，這是數(shù)據(jù)對象與面向對象范型中的“類”或“對象”的顯著區(qū)別。

2．屬性

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

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

3．關系

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

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

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

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

(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關系

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

4．實體-關系圖的符號

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

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

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

1．數(shù)據(jù)流圖符號

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

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

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

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

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

2．數(shù)據(jù)流圖例子

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

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

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

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

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

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

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

注意，并不是所有數(shù)據(jù)存儲和數(shù)據(jù)流都能直接從問題描述中提取出來。例如，“當某種零件的庫存數(shù)量少于庫存量臨界值時就應該再次訂貨”，這個事實意味著必須在某個地方有零件庫存量和庫存量臨界值這樣的數(shù)據(jù)。因為這些數(shù)據(jù)元素的存在時間看來應該比單個事務的存在時間長，所以認為有一個數(shù)據(jù)存儲來保存庫存清單數(shù)據(jù)是合理的。表4.5列出了上面分析的結果，其中加星號標記的是在問題描述中隱含的成分。表4.5組成數(shù)據(jù)流圖的元素可以從描述問題的信息中提取一旦把數(shù)據(jù)流圖的四種成分分離出來，就可以著手畫數(shù)據(jù)流圖了。但是要注意，數(shù)據(jù)流圖是系統(tǒng)的邏輯模型，而任何計算機系統(tǒng)實質上都是信息處理系統(tǒng)，也就是說計算機系統(tǒng)本質上都是把輸入數(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)的信息非常有限。下一步應該把基本系統(tǒng)模型細化，描繪系統(tǒng)的主要功能。由表4.5可知，“產生報表”和“處理事務”是系統(tǒng)必須完成的兩個主要功能，它們將代替圖4.11中的“訂貨系統(tǒng)”。此外，細化后的數(shù)據(jù)流圖中還增加了兩個數(shù)據(jù)存儲：處理事務需要“庫存清單”數(shù)據(jù)；產生報表和處理事務在不同時間，因此需要存儲“訂貨信息”。除了表4.5中列出的兩個數(shù)據(jù)流之外還有另外兩個數(shù)據(jù)流，它們與數(shù)據(jù)存儲相同。這是因為從一個數(shù)據(jù)存儲中取出來的或放進去的數(shù)據(jù)通常和原來存儲的數(shù)據(jù)相同，也就是說，數(shù)據(jù)存儲和數(shù)據(jù)流只不過是同樣數(shù)據(jù)的兩種不同形式。在圖4.12中給處理和數(shù)據(jù)存儲都加了編號，這樣做的目的是便于引用和追蹤。圖4.12訂貨系統(tǒng)的功能級數(shù)據(jù)流圖接下來應該對功能級數(shù)據(jù)流圖中描繪的系統(tǒng)主要功能進一步細化?？紤]通過系統(tǒng)的邏輯數(shù)據(jù)流，當發(fā)生一個事務時必須首先接收它，隨后按照事務的內容修改庫存清單，如果更新后的庫存量少于庫存量臨界值，則應該再次訂貨，也就是需要處理訂貨信息。因此，把“處理事務”這個功能分解為下述三個步驟：“接收事務”、“更新庫存清單”和“處理訂貨”(見圖4.13)，這在邏輯上是合理的。圖4.13把處理事務的功能進一步分解后的數(shù)據(jù)流圖我們?yōu)槭裁床贿M一步分解“產生報表”這個功能呢？因為訂貨報表中需要的數(shù)據(jù)在存儲的訂貨信息中全都有，產生報表只不過是按一定順序排列這些信息，再按一定格式打印出來。然而這些考慮純屬具體實現(xiàn)的細節(jié)，不應該在數(shù)據(jù)流圖中表現(xiàn)。同樣道理，對“接收事務”或“更新庫存清單”等功能也沒有必要進一步細化?？傊?，當進一步分解將涉及如何具體地實現(xiàn)一個功能時，就不應該再分解了。

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

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

3．命名

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

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

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

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

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

(2)為處理命名。

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

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

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

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

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

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

1．狀態(tài)

狀態(tài)是任何可以被觀察到的系統(tǒng)行為模式，一個狀態(tài)代表系統(tǒng)的一種行為模式。狀態(tài)規(guī)定了系統(tǒng)對事件的響應方式，系統(tǒ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)單程生命期。當描繪循環(huán)運行過程時，通常并不關心循環(huán)是怎樣啟動的；當描繪單程生命期時，需要標明初始狀態(tài)(系統(tǒng)啟動時進入初始狀態(tài))和最終狀態(tài)(系統(tǒng)運行結束時到達最終狀態(tài))。

2．事件

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

3．符號

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

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

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

其中，“事件名”可以是任何事件的名稱。在活動表中經常使用下述3種標準事件：entry、exit和do。entry事件指定進入該狀態(tài)的動作，exit事件指定退出該狀態(tài)的動作，而do事件則指定在該狀態(tài)下的動作。需要時可以為事件指定參數(shù)表?；顒颖碇械膭幼鞅磉_式描述應做的具體動作。

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

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

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

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

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

圖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ù)字典正是用來完成這項任務的。

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

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