1、Prepared on 22 November 2020軟 件 需 求 分 析軟件需求分析是軟件定義階段的最后一個步驟，它的基木任務是要準 確地回答“系統必須做什么”這個問題，即對目標系統提出完整、準確、 清晰、具體的要求。需求分析的結果是系統開發的基礎，直接影響軟件產 品及一匸程的質量。軟件需求分析是一個不斷進行揭示和判斷的過程。在此過程中我們將 對在軟件可行性研究階段確定的軟件范圍加以提煉使之具體化，并分析各 軟件部件可能采用的解決辦法。在軟件需求分析階段，軟件的開發者和軟 件需求者起著同樣的重要作用。軟件需求者設法把有關軟件功能和性能的 一些模糊的概念加以重述，使之成為具體的細節，而軟件

2、開發者則起著詢 問、顧問和問題解決者的作用。在需求分析中需要大量地交換意見，這其 間充滿著傳錯信息和發生誤解的可能性，而我們的任務就是面對各種矛 盾，協調各種人與人、人與物，物與物之間的關系。需求分析的任務1. 確定系統的綜合要求系統的綜合要求包括下面幾個方面。(1) 確定系統的功能要求。提出系統必須完成的全部所有功能。(2) 確定系統的性能要求。包括系統的響應時間、系統需要的存儲容 量、后援存儲器容量、系統重新啟動、系統的安全性和可靠性等方而的性 能要求。(3) 確定系統的運行要求。主要是指系統運行時所處的環境要求，包圖3-1系統邏輯模型的導出過程括支持系統運行的軟件環境，工具軟件和系統軟件

3、；支持系統運行的硬件 環境，外存儲器、通信接口、輸入和輸出等外部設備。(4) 系統的擴充要求。不屬于當前系統的開發范圍，是將來有可能提 岀的要求，目的是使在現有的設計中為將來的擴充做準備。2. 分析系統的數據要求任何一個軟件系統其本質上都是一個信息處理系統，系統必須處理的 信息和系統應該產生的信息在很大程度上決定了系統的概貌，同時也對軟 件設計有著深遠的影響。因此，分析系統的數據要求，是軟件需求分析的 任務之一。系統的數據來源和去處一般含如下幾個方面。(1) 從系統以外來,(2) 從系統以外來,(3) 從系統內部來,(4) 從系統內部來,再到系統以外去;再到系統內部去;再到系統內部去;再到系統

4、外部去。復雜的數據是由許多基木數據元素組成的，數據元素之間的邏輯關系 形成了數據結構。我們一般用圖形工具輔助描繪數據結構，常用的有層次 方框圖和Warnier圖，將在本章第三節中介紹這兩種工具。3. 建立系統的邏輯模型以上述綜合要求和數據要求的結果為基礎，我們可以導出系統的邏輯 模型，并通過數據流圖、數據字典和主要處理算法來描述這個邏輯模型。具體過程如圖3-1所示。4. 修正系統開發計劃由分析過程而獲得對系統的深層了解之后，我們可以準確地估計系統 的成本及進度，修正以我們所制定的開發計劃。5. 開發模型系統開發模型系統是指在需求分析階段建造軟件樣機。它的目的主要是檢 驗關鍵設計方案的正確性及系

5、統是否能真正滿足用戶的需要。在軟件開發中采用樣機策略的主要困難是成本問題。對于一次設計后 大量生產的產品，設計樣機的費用可分攤到每件產品上，因此每件產品的 成本增加很少。而某些應用軟件，通常一次只開發一件產品，采用樣機策 略則成木增加很多。近年來主張采用樣機策略的人逐漸多起來，樣機法己 逐漸成為開發軟件的一種重要方法，有的書也稱此為原型法。需求分析的方法在軟件工程的需求分析階段，通常采用結構化分析技術、面向對象分 析技術、原型（樣機）開發技術等。下面對這三種分析技術加以介紹。結構化分析技術結構化分析技術是七十年代中期由等人倡導的一種面向數據流的分析 方法。按照的定義，“結構化分析就是用數據流圖

6、、數據字典、結構化英 語、判定表和判定樹等工具，來建立一種新的、稱為結構化說明書的目標 文檔。”其中結構化說明書就是需求規格說明書。結構化分析技術將軟件系統抽象為一系列的邏輯加工單元，各單元之 間以數據流發生聯系。關于數據流圖的細化、定義、加工、小說明的描述 前而已經介紹過，在此不再贅述。下而我們通過房產管理系統這個實例， 具體看一看結構化分析的過程。1. 項目說明房產計算機管理系統包括住房分析、調整和計租等。用戶可以查詢住 房情況和房租金額，房產部門也可以對房產進行統計，輸出需要的統計 表。在房產計算機管理系統中我們把住戶的要求分為三類，即分房要求， 調房要求，退房要求。把查詢要求分為：查詢

7、住房情況，查詢房租和查詢 全局住房情況三種。對以上要求又具體規定如下：分房要求：可根據分房單進行住房分配，分配住房要從房產文件中讀 岀相應的空房信息。如房號、面積、單位而積房租等。然后把相應的住房 信息，如戶主姓名、部門、住房分數、家庭人口等再寫回房產文件中去， 同時還要寫入到住房文件中去。最后輸出分配后的住房單。與此項要求有聯系和影響的工作是房租計算，計算好新分配房的房租 后寫入到房租文件中去。調房要求和退房要求與分房要求大體類似，這里不再敘述。查詢住房情況要求：根據住戶名從住房文件中讀出該住戶的住房情況 并打印。查詢房租要求：從房租文件讀出該住戶的信息并輸岀。查詢全局住房情況要求：根據統計

8、要求作統計處理后輸出報表。2. 分層細化數據流圖，見圖3-2, 3-3, 3-4, 3-5所示。圖3-3第二層數據流圖3. 數據字典(1) 數據流住戶要求二戶主+ 分房要求丨調房要求丨退房要求查詢二戶主+ 住房情況查詢I房租查詢I統計要求統計表二住房面積+己分住房數丨空房數住房情況二部門+職稱+戶主+家庭人口 +住房而積+房租分房要求二部門+職稱+家庭人口 +住房分數+要求住房而積調房要求二部門+職稱+家庭人口 +住房分數+原居住面積+要求調房而積退房要求二部門+房號分房單二部門+房主+職稱+住房分數+要求住房而積調房單二部門+戶主+職稱+住房分數+原住房而積+原房號+要求調房而積退房單二戶主

9、+房號+部門圖3-4第三層數據流圖圖3-5第四層數據流圖住房單二戶主+房號+部門+住房面積+租金房號二樓號+房號房租二住房而積X單位租金(2) 文件房產文件二房號+住房面積+分配標志+單位租金按房號為關鍵字排序住房文件二部門+戶主+職稱+家庭人口 +房號+住房面積以戶主名為關鍵字排序房租文件二房號+戶主+住房而積+租金+繳納情況以戶主名為關鍵字排 序(3) 加工說明加工編號：1加工名：檢查合法性加工邏輯：檢查住戶要求和住房查詢的合法性，對不合法的要求或查 詢給予拒絕。有關信息：有輸入時執行此加工。加工編號：加工名：要求類型分類加工邏輯：根據住戶要求，選擇分房、調房、退房處理。有關信息：住戶要求

10、合法時執行此加工，處理結果輸出分房單或調房 單或退房單。加工編號：加工名：分配住房加工邏輯：從房產文件中讀出合理記錄，把分房單有關信息拼成住房 文件記錄寫入到住房文件中去，在房產文件的相應記錄中填入己分標志到 分配標志字段中。有關信息：收到分房單時執行此加工，輸出住房單。加工編號：加工名：房租計算加工邏輯：依住房計算房租寫入房租文件。有關信息：收到住房單時執行此加工。加工編號：加工名：調房處理加工邏輯：對住房、房產文件進行讀、寫操作，修改有關字段內容和 有關記錄內容。有關信息：收到調房單時執行此加工，輸出住房單和退房單。加工編號：加工名：房租核計加工邏輯：依據住房單和退房單進行房租的核算寫入房

11、租文件。有關信息：收到住房單和退房單時執行此加工。加工編號：加工名：退房處理加工邏輯：從住房文件讀出有關記錄，輸出退房單，刪除該記錄，對 房產文件中的相應記錄修改。有關信息：收到退房單執行此加工。加工編號：加工名：消去房租加工邏輯：由退房單對房租文件進行修改刪除。有關信息：收到退房單時執行此加工。加工編號：加工名：查詢類別處理加工邏輯：根據查詢要求，選擇住房查詢或房租查詢或統計房產要 求。有關信息：當有查詢要求時執行此加工，處理結果輸出查詢住房情況 要求或查詢房租要求或統計要求。加工編號：加工名：住房查詢加工邏輯：由查詢要求從住房文件中讀出相應記錄。有關信息：有查詢住房情況要求時執行此加工，輸

12、出住房記錄。加工編號：加工名：房租查詢加工邏輯：由房租查詢要求，從房租文件中讀岀相應記錄信息。有關信息：有查詢房租要求時，執行此加工。加工編號：加工名：統計房產加工邏輯：讀房產文件，統計房屋分配情況，輸出統計表。有關信息：有統計要求時執行此加工。加工編號：4加工名：打印處理加工邏輯：把住房記錄或房租記錄打印出來。有關信息：收到住房記錄和房租記錄時執行此加工。4. 復審分析工作的最后一步是按照結束標準對分析階段的工作成果進行正式 的技術審查，以數據流圖作為基本文檔，在數據字典、算法描述及其他有 關文檔的輔助下，仔細分析研究需求分析階段的結果，目的是發現錯誤和 遺漏。審查小組通常由四人組成，組長由

13、一名沒有參加這個項目的有經驗的 系統分析員擔任，組員由本系統的分析員和兩名用戶代表構成。若審查合 格，那么審查小組成員應該在正式的審查表上簽字，若有問題應提出并限 期修改，改正后再進行審查，直到合格為止。但要注意，在進入下階段工 作之前，要進行管理復審，只有在使用部門的負責人審查修正后的成本和 進度是可接受的，開發工程才能繼續進行。面向對象的概念是在七十年代程序設計方法學的抽象數據類型中產生 的。它在軟件工程中的應用是即美國XEROX公司于1980年研制出而向對象 的程序設計語言Smalltalk-80之后。面向對象的分析技術以模塊封裝和內 部信息隱蔽為主要特征。面向對象語言具有易編程、易修改

14、、易維護，能 大幅度提高軟件生產率和質量等特點，二者的結合是軟件產業中的一次革 命。面向對象的分析，是抽取和整理用戶需求并建立問題精確模型的 過程。通常，面向對象分析過程從分析陳述用戶需求的文件開始，發現和 改正原始陳述中的二義性和不一致性，補充遺漏的內容，使需求變得完整 準確。接下來分析員要深入理解用戶需求，抽象出目標系統的木質屬性， 并用模型準確地表示出來。面向對象建模得到的模型包括對象的三個要素，即靜態結構（對象模型） 表示靜態的、結構化的系統的“數據”性質，它是對模擬客觀世界實 體的對象以及對象彼此間的關系的映射；交互次序（動態模型）一一表示瞬 時的、行為化的系統的“控制”性質，它規定

15、了對象模型中的對象的合法 變化序列；數據變換（功能模型）一一表示變化的系統的“功能”性質，它 指明了系統應該“做什么”，更直接地反映了用戶對目標系統的需求。復雜問題的對象模型由五個層次組成，即主題層、對象層、結構層、 屬性層和服務層。這五個層次一層比一層顯現出對象模型的更多細節，而 且這五個層次對應著在而向對象分析過程中建立對象模型的五項主要活 動，即標識對象（類），標識結構，標識主題，定義屬性，定義服務。下面 我們以實時空運系統為例，介紹面向對象分析技術的步驟一一五個主要活 動的內容。1. 標識對象（類）對象是所有數據及可對這些數據施加的操作結合在一起所構成的獨立 單位的總稱。類是對一組具有

16、相同數據結構和相同操作的對象的描述。為了標識對象，我們應從問題空間的結構、與其他系統的相互作用、設 備、記住的事件、發揮的作用、地點和組織單位等方而進行尋找。一旦分析員發現了一個候選 對象，應該考慮需要的記憶，需要的服務，多于一個屬性，公共屬性，公共服務，基本要求 等。對確定的對象要設立一個對象名，一般用名詞或形容詞+名詞來表示。實時空運系統包括7個對象。如圖3-6所示。其中對象Aircraft（飛機） 和Radar （雷達）為其他系統,對象Mission （飛行任務）、Flight （航班）、 Cargo Item（貨物）和Aircraft Failure （飛機故障）為需記憶的事件,對象

17、Passenger （乘客）為扮演的角色。2. 標識結構面向對象分析方法中有兩種結構類型一一分類結構和組裝結構。其中 分類結構表示一般和特殊的關系，這一關系描述了一個對象類是另一對象 類的子類/超類。組裝結構表示組裝、容納、包含關系，它描述了一個對象 是由另外一個或多個稱之為成分的對象組成的。在實時空運系統的7個對象中，Shipment Item為分類結構，如圖36中的半圓所示，它是由兩個子類Passenger和Cargo Item組成的一個超類。對象Mission和Flight為組裝結構，對象Flight和Shipment Item為組 裝結構。圖36中三角形指岀了上述組裝結構，兩端標記指出

18、了各對象之間的實例約束。一項Mission可以沒有任何Flight的情況下存在，而一 個Flight至多是一個Mission的組成部分。Flight和Shipment可以獨立 存在或以任何數量的整體與部分關系存在。3. 標識主題主題的個數一般是7個左右，統計數據表明，通常人們認為在一個時 間內短期記憶限制在7±2個事件內，稱為“7±2”規則。定義主題的方法是：對每個結構增加一個相應的主題，對每個對象增 加一個相應的主題。當由此產生的主題個數超過7個左右時，需要進一步 提煉主題（依據主題的耦合情況），以得到一個更好的模型概觀。最后列出 主題及主題層上各主題之間的消息連接。4.

19、 定義屬性屬性是描述對象或分類結構實例的數據單元，定義屬性分以下幾步。(1) 標識屬性分析員要與用戶交流，在問題空間中找出適用于這個對象或分類結構 的所有實例的屬性。 (2)屬性定位利用分類結構中的繼承機制確定屬性的位置。把通用屬性放在結構的 高層，特殊屬性放在低層。如果某個屬性可適用于絕大多數的特殊情況， 則可將其放在通用的位置上，然后在不需要它的特殊地方覆蓋掉。如果某 個屬性常常有“不可適用的”值出現，則進一步找出其附加結構。(3) 標識和定義實例連接實例連接就是一個實例與另一個實例的映射關系，它反映問題空間的 對應性，以獲得最少的必要的連接集合。如果連接適合于所有實例，則在 分類結構的通

20、用層相連接，否則在特殊的專用層連接。定義多重性：在每一個方向上建立單重或多重的連接。定義參與性：在每一個方向上定義連接是任選的還是強制性的，特殊 情況作特殊處理。(4) 修訂對象隨著屬性的增加，需要重新修訂一些對象或分類結構，通常從以下幾 個角度來檢驗1) 帶有“非法”值的屬性。如果某些屬性不適合于一個對象的所有實 例或分類結構的某個特定的實例，則應考慮引入附加的分類結構。2) 單個屬性。如果對象或分類結構的實例只有一個屬性，則應修改模 型以反映更高一層的抽象，將單個屬性直接放入與該屬性所描述的對象相 關連的對象，然后刪除這個多余的對象。3）屬性值的冗余。當一個對象實例的某個屬性可能有多個重復

21、值時， 應考慮增加新的對象。4）適應性參數。對尚無著落的適應性變化參數可作為屬性。5）說明屬性和實例連接的約束。用名字和描述來說明屬性，還可以增 加一定的屬性約束，而且每個屬性都可以歸類成描述性的、定義性的、通常可導出的、偶 爾可導出的。屬性作為一個對象（類）的另一重要部分，它連同對象（類）名字和服務組成一 個完整的對象（類）表示。實時空運系統各對象（類）的屬性說明如圖3-7所示。圖3-7實時空運系統各對象（類）的屬性說明5. 定義服務一個服務就是收到一條消息之后所執行的處理。定義服務的中心問題 是為每個對象和分類結構定義所需要的行為。定義服務的第二個問題是確 定對象實例之間必要的通訊。定義服

22、務分四步：（1）標識服務基本策略對每一個對象或分類結構考慮三類基木服務：Occur服務為隱含服務，完成實例的增加、修改、刪除和選擇。Calculate服務為某個實例或代表另一個實例的計算結果。Monitor服務為執行對外界系統、設備或用戶的運行監控。（2）標識服務一一輔助策略通過對象或分類結構以后發生的事件，由基木服務出發，檢查每一步的演變，增加基木序列，增加服務，把這些附加的服務名放入模型圖中。（3）標識消息連接消息連接用于適應服務的需要，表示發出一條消息，也表示接收到一 個響應，在考慮消息連接時，首先在己存在實例連接的對象和分類結構之 間增加消息連接，然后再對屬性尋找服務。消息連接在圖形中

23、用箭頭表 示，它從發送者指向接收者，如圖38所示。（4）詳細說明服務為了建立所有服務的細節文檔，對服務的規格說明分為以下幾部分：1）集中于所需要的外部可見的行為；2）使用一個模板；3）增加圖示以簡化服務說明；4）增加支持的表；5）建立服務的文字敘述。實時空系統的服務層如圖3-8所示。圖3-8實時空運系統服務層傳統的生存周期方法學強調自頂向下分段開發，在進入實際的開發時 期之前必須預先對需求嚴格定義。但是，在系統建立起來之前很難僅僅依 靠分析就確定出一套完整、一致、有效的應用需求，特別是它不適應用戶 需求不斷變化的情況。原型開發技術打破了傳統的自頂向下開發模式，是 目前比較流行的實用開發方法之一

24、。原型開發技術要求在獲得一組基木需求說明后，就快速地使其“實 現”，通過原型反饋加深對系統的理解，并對需求說明進行補充和精化， 原型開發技術一般包括以下五個方面的內容。1. 實現原型的途徑建立原型的目的不同，實現原型的途徑也有所不同，通常有以下三種 類型。(1) 用于驗證軟件需求的原型確定了軟件需求之后，從中選擇某些應著重驗證的功能和性能，用適 當的工具快速構造出可運行的原型系統，由用戶來試用和評價。這類原型往往用后就丟掉，因此構造它們所用的工具不必與目標系統 的生產環境集成在一起，通常使用簡潔而易于修改的超高級語言對原型進 行編碼。(2) 用于驗證設計方案的原型為確保軟件產品質量，在總體設計

25、或詳細設計過程中，用原型來驗證 總體結構或某些關鍵算法。若驗證完設計方案之后就棄掉，則構造原型所 用的工具不必與目標系統的生產環境集成在一起。反之，如果想把原型作 為最終產品的一部分，則必須把原型的生產環境與目標系統的生產環境集 成在一起。原型和目標系統也可以使用同樣的程序設計語言編寫。(3) 用于演進出目標系統的原型不經過實踐不能預先定義所有需求，看來比較合理的辦法是經過初步 分析獲得一組基本需之后，就迅速地用原型加以實現，作為溝通各方的基 礎和實踐場所。隨著用戶和開發人員對系統理解逐漸加深，不斷對原型進行修改和擴充，直到用戶感到滿 意為止。力圖用正常的迭代來避免不正常的反復。如果用戶希望從

26、滿意的原型直接轉成實用 的目標系統，則必須把原型的生產環境和目標系統的生產環境集成在一起，當原型與目標系 統使用不同的語言時，要改進原型，進行翻譯。2. 功能選擇要恰當選擇原型實現的功能。原型它不同于最終的軟件系統，兩者在 功能范圍上是有區別的，主要表現在：(1) 最終系統是軟件需求全部功能的實現，而原型只實現所選擇的部 分功能；(2) 最終系統對每個軟件需求都要求詳細實現，而原型僅僅是為試驗 和演示用的，部分功能需求可以忽略，或者模擬實現。3. 構造原型在構造一個原型時，應強調著眼于預期的評估，而不是為了正規的長 期使用。一般采用超高級語言來實現原型系統，可以大大減少系統原型的 開發成本。4

27、. 評價和確認通過運行原型，對軟件需求規格說明進行評價和確認。在用戶參與的 評價活動中，要注意來自用戶的反饋信息。5. 進一步使用根據原型實現的特點和環境，原型既可以作為試驗的工具，也可以全 部或部分地成為最終系統的組成部分。原型開發與原型運行和評價兩者間 需要反復進行多次，才能得到經過確認的需求規格說明系統的原型開發， 因此原型系統必占總開銷成木的一部分。一個軟件是否要開發原型系統，應視軟件規模與復雜程度而定。原型 開發技術的開發過程如圖3-9所示。圖3-9原型開發過程需求分析階段的圖形工具用圖形工具來描述數據結構，比文字敘述更直觀，木節介紹三種需求 分析階段所使用的圖形工具。層次方框圖是用

28、樹形結構的一系列多層次的矩形框描繪數據的層次結 構。樹形結構的頂層是一個單獨的矩形框，它代表完整的數據結構。下面 各層的矩形框代表這個數據的子集，最低層的各個框代表組成這個數據的 實際數據元素（不可再分割）。例描繪一家計算機公司全部產品的數據結構可用圖3-10表示。圖3-10層次方框圖實例隨著結構的分解，層次方框圖對數據結構的描述也越來越詳細。這種 方式很適合于結構化分析。用Warnier圖可以表明信息的邏輯組織，指出一類或一個信息是重復 出現的，也可表示特定信息的有條件出現，它很容易變成軟件設計的工 具。下面給出用Warnier圖描述軟件產品的一個例子，見圖311所示。軟件產品系統軟件操作系

29、統(P1)編譯程序(P 2)軟件工具 編譯程序(P 3)圖形生成程序(P 4)應用軟件圖3-llWarnier圖實例在Warnier圖中花括號用來區分數據結構的層次，在一個花括號內的 所有名字都屬于同一類信息；符號 表示在其上、下方的名字中的一個名 字；名字右邊圓扌舌號中的符號表示這個名字在信息類中重復岀現的次數。圖3-10中系統軟件和應用軟件只能出現一種；系統軟件中包括P1種 操作系統，P2種編譯程序，軟件工具中包括P3種編譯程序，P4種圖形生成程序。IP0圖是輸入/處理/輸出圖的簡稱，它是由美國IBM公司發展完善起來 的一種圖形工具，可以方便地表示輸入數據、數據處理和輸出數據三者之 間的關

30、系。IP0圖包括三個矩形框，它的基本形式如圖312所示。左邊框列出所有輸入數據，中間框列岀主要處理及出現的順序，暗示了執行的順序， 右邊框列出輸出數據。三個框中間用粗箭頭指出數據通信情況。圖 3-12IP0 圖我們在軟件設計中比較常用的是一種改進的IPO圖，其基木格式如圖3 13所示。包括了系統名稱、作者、日期、模塊名、調用與被調用模塊清 單、注解、以及本模塊使用的局部數據元素等。圖3-13改進的IPO圖驗證軟件需求為了提高軟件的質量，確保軟件開發成功，降低軟件開發成本，我們 一般從四個方面進行軟件需求的驗證。一致性。在所有需求中，任何一條需求不能和其他需求互相矛盾。完整性。軟件規格說明書必須包括用戶需求的每一個功能或性能。現實性。指定的需求應該是用現有的硬件技術和軟件技術基木上可以 實現的。有效性。軟件需求確實能解決用戶所而對的問題。用計算機輔助人工需求分析，可使軟件開發更趨于工程化和標準化。 七十年代末以來，國外己開發了多種用于需求分析的軟件工具，我國在這 方而也取得了很大成就，青鳥系統I型和I【型就是這項工作的代表。一般 來講，這些軟件工具符合下述標準。1. 有形式化語法，可用計算機自動處理；2. 使用這個軟件工具能導岀詳細的文檔；3. 提供分析（測試）規格說明書的不一致性和冗余性的手段，能夠產生 -組報告指明對完整性分析的結果;4.