需求分析

為了開發出真正滿足用戶需求的軟件產品，首先必須知道用戶的需求。對軟件需求的深人理解是軟件開發工作獲得成功的前提條件，不論人們把設計和編碼工作做得如何出色,不能真正滿足用戶需求的程序只會令用戶失望.給開發者帶來煩惱。

需求分析是軟件定義時期的最后個階段 ,它的基本任務是準確地回答“系統必須做什么”這個問題。

雖然在可行性研究階段已經粗略地了解了用戶的需求，甚至還提出了一些可行的方案,但是，可行性研究的基本目的是用較小的成本在較短的時間內確定是否存在可行的解法，因此許多細節被忽略了。然而在最終的系統中卻不能遺漏任何一個微小的細節，所以可行性研究并不能代替需求分析,它實際上并沒有準確地回答“系統必須做什么”這個問題,

需求分析的任務還不是確定系統怎樣完成它的工作，而僅僅是確定系統必須完成哪些工作，也就是對目標系統提出完整、準確、消晰、具體的要求。

在需求分析階段結束之前，系統分析員應該寫出軟件需求規格說明書，以書面形式準確地描述軟件需求。

在分析軟件需求和書寫軟件需求規格說明書的過程中，分析員和用戶都起著關鍵的必不可少的作用。只有用戶才真正知道自己需要什么，但是他們并不知道怎樣用軟件實現自己的需水,用戶必須把他們對軟件的需求盡量準確、具體地描述出來;分析員知道怎樣用軟件實現人們的需求,但是在需求分析開始時他們對用戶的需求并不+t分清楚,必須通過與用戶溝通獲取用戶對軟件的需求。

需求分析和規格說明是一項十分艱巨復雜的工作。用戶與分析員之間需要溝通的內容非常多，在雙方交流信息的過程中很容易出現誤解或遺漏，也可能存在二義性。因此，不僅在整個需求分析過程中應該采用行之有效的通信技術，集中精力細致工作，而且必須嚴格審查驗證需求分析的結果。

盡管目前有許多不同的用于需求分析的結構化分析方法，但是,所有這些分析方法都遵守下述準則。

(1)必須理解并描述問題的信息域.根據這條準則應該建立數據模型。

(2)必須定義軟件應完成的功能。這條準則要求建立功能模型.

(3)必須描述作為外部事件結果的軟件行為，這條準則要求建立行為模型。

(4)必須對描述信息、功能和行為的模型進行分解，用層次的方式展示細節。

需求分析的任務

確定對系統的綜合要求

雖然功能需求是對軟件系統的一項基本需求，但卻并不是唯一的需求。 通常對軟件系統有下述幾方面的綜合要求。

1.功能需求

這方面的需求指定系統必須提供的服務。通過需求分析應該劃分出系統必須完成的所有功能。

2.性能需求

性能需求指定系統必須滿足的定時約束或容量約束，通常包括速度(響應時間)、信息量速率、主存容量、磁盤容量、安全性等方面的需求。例如，“應力分析程序必須在一分鐘之內生成任何一個梁的應力報告”就是一項性能需求。

3.可靠性和可用性需求

可靠性需求定量地指定系統的可靠性,例如，“機場雷達系統在一個月內不能出現兩次以上故障”。可用性與可靠性密切相關,它量化了用戶可以使用系統的程度。例如，“在任何時候主機或備份機上的機場雷達系統應該至少有一個是可用的，而且在一個月內在任何一-臺計算機上該系統不可用的時間不能超過總時間的2%”。

4.出錯處理需求

這類需求說明系統對環境錯誤應該怎樣響應。例如，如果它接收到從另一個系統發來的違反協議格式的消息,應該做什么?注意，上述這類錯誤并不是由該應用系統本身造成的。在某些情況下，“出錯處理"指的是當應用系統發現它自己犯下一個錯誤時所采取的行動。但是，應該有選擇地提出這類出錯處理需求。人們的目的是開發出正確的系統，而不是用無休止的出錯處理代碼掩蓋自己的錯誤。總之，對應用系統本身錯誤的檢測應該僅限于系統的關鍵部分，而且應該盡可能少。

5.接口需求

接口需求描述應用系統與它的環境通信的格式。常見的接 口需求有用戶接口需求:硬件接口需求:軟件接口需求;通信接口需求/例如:“把商品從貨源地運送到目的地所需要的成本，應該一直顯示在“成本 正文框中”。“向運輸公同傳送“需運送的商品'信息的格式是exp<string> ,其中(string)是從商品目錄中選取的字符串”。

上述第一個例子是應用系統與用戶接口的一個需求，第二個例子指定了與其他應用系統通信的信息格式。兩者都是接口需求。

6.約束

設計約束或實現約束描述在設計或實現應用系統時應遵守的限制條件。在需求分析階段提出這類需求.并不是要取代設計(或實現)過程，只是說明用戶或環境強加給項目的限制條件。常見的約束有:精度:工具和語言約束:設計約束:應該使用的標準:應該使用的硬件平臺。

7.逆向需求

逆向需求說明軟件系統不應該做什么。理論上有無限多個逆向需求，人們應該僅選取能澄清真實需求且可消除可能發生的誤解的那些逆向需求。例如,“應力分析程序無須分析橋梁倒塌數據”。

8.將來可能提出的要求

應該明確地列出那些雖然不屬于當前系統開發范疇，但是據分析將來很可能會提出來的要求。這樣做的目的是，在設計過程中對系統將來可能的擴充和修改預做準備，以便一日確實需要時能比較容易地進行這種擴充和修改。

分析系統的數據要求

任何一個軟件系統本質上都是信息處理系統，系統必須處理的信息和系統應該產生的信息在很大程度上決定了系統的面貌，對軟件設計有深遠影響,因此，必須分析系統的數據要求,這是軟件需求分析的一個重要任務。分析系統的數據要求通常采用建立數據模型的方法。

復雜的數據由許多基本的數據元素組成，數據結構表示數據元素之間的邏輯關系。利用數據字典可以全面準確地定義數據,但是數據字典的缺點是不夠形象直觀。為了提高可理解性，常常利用圖形工具輔助描繪數據結構。常用的圖形工具有層次方框圖和Warnier圖，軟件系統經常使用各種長期保存的信息,這些信息通常以定方式組織并 存儲在數據庫或文件中,為減少數據冗余，避免出現插人異常或刪除異常，簡化修改數據的過程，通常需要把數據結構規范化。

導出系統的邏輯模型

綜合上述兩項分析的結果可以導出系統的詳細的邏輯模型.通常用數據流圖、實體-聯系圖、狀態轉換圖、數據字典和主要的處理算法描述這個邏輯模型

修正系統開發計劃

根據在分析過程中獲得的對系統的更深人更具體的了解，可以比較準確地估計系統的成本和進度，修正以前制定的開發計劃。

與用戶溝通獲取需求的方法

訪談

訪談是最早開始使用的獲取用戶需求的技術，也是迄今為止仍然廣泛使用的需求分析技術。

訪談有兩種基本形式，分別是正式的和非正式的訪談。正式訪談時，系統分析員將提出一些事先準備好的具體問題，

例如，向間客戶公司銷售的商品種類、雇用的銷售人員數目以及信息反饋時間應該多快等。在非正式訪談中，分析員將提出一些用戶可以自由回答的開放性問題，以鼓勵被訪問人員說出自己的想法，例如，詢問用戶對目前正在使用的系統有哪些不滿意的地方。當需要調查大量人員的意見時，向被調查人分發調查表是一個十分有效的做法。經過仔細考慮寫出的書面回答可能比被訪者對問題的口頭回答更準確。分析員仔細閱讀收回的調查表，然后再有針對性地訪問些用戶，以便向他們詢問在分析調查表時發現的新問題。

在訪問用戶的過程中使用情景分析技術往往非常有效。

所謂情景分析就是對用戶將來使用目標系統解決某個具體問題的方法和結果進行分析。

例如，假設目標系統是一一個制定減肥計劃的軟件，當給出某個肥胖癥患者的年齡、性別身高、體重、腰圍及其他數據時，就出現了一個可能的情景描述。系統分析員根據自己對目標系統應具備的功能的理解，給出適用于該患者的菜單。客戶公司的飲食專家可能指出，某些菜單對于有特殊飲食需求的患者(例如，糖尿病人、素食者)是不合適的。這就使分析員認識到，目標系統在制定菜單之前還應該先詢問患者的特殊飲食需求。系統分析員利月情最分析技術，往往能夠獲知用戶的具體需求。

情景分析技術的用處主要體現在下述兩個方面：

①它能在某種程度上演示目標系統的行為，從而便于用戶理解.而且還可能進一步揭示出一些分析員目前還不知道的需求。

②由于情景分析較易為用戶所理解,使用這種技術能保證用戶在需求分析過程中始終扮演一個積極主動的角色。需求分析的目標是獲知用戶的真實需求，而這一信息的唯一來源是用戶.因此，讓用戶起積極主動的作用對需求分析工作獲得成功是至關重要的。

面向數據流自頂向下求精

軟件系統本質上是信息處理系統，而任何信息處理系統的基本功能都是把輸人數據轉變成需要的輸出信息。數據決定了需要的處理和算法、看來數據顯然是需求分析的出發點。在可行性研究階段許多實際的數據元素被忽略了，當時分析員還不需要考慮這些細節，現在是定義這些數據元素的時候了。

結構化分析方法就是面向數據流自頂向下逐步求精進行需求分析的方法。

通過可行性研究已經得出了目標系統的高層數據流圖，需求分析的目標之就是把數據流和數據存儲定義到元素級。

為了達到這個目標，通常從數據流圖的輸出端著手分析,這是因為系統的基本功能是產生這些輸出，輸出數據決定了系統必須具有的最基本的組成元素。輸出數據是由哪此元索組成的呢?通過調查訪問不難搞清這個問題。

那么，每個輸出數據元素又是從哪里來的呢?既然它們是系統的輸出，顯然它們或者是從外面輸入到系統中來的,或者是通過計算由系統中產生出來的。沿數據流圖從輸出端往輸入端回溯應該能夠確定每個數據元素的來源，與此同時也就初步定義了有關的算法。

但是,可行性研究階段產生的是高層數據流圖.許多具體的細節沒有包括在里面，因此沿數據流圖回溯時常常遇到下述問題:

為了得到某個數據元素需要用到數據流圖中目前還沒有的數據元素,或者得出這個數據元素需要用的算法尚不完全清楚。

為了解決這些問題，往往需要向用戶和其他有關人員請教.他們的回答使分析員對目標系統的認識更深人更具體了，系統中更多的數據元素被劃分出來了,更多的算法被搞清楚了。通常把分析過程中得到的有關數據元素的信息記錄在數據字典中，把對算法的簡明描述記錄在IPO圖中。通過分析而補充的數據流、數據存儲和處理，應該添加到數據流圖的適當位置上。

必須請用戶對上述分析過程中得出的結果仔細地復查,數據流圖是幫助復查的極好工具。從輸入端開始，分析員借助數據流圖、數據字典和IP0圖向用戶解釋輸人數據是怎樣一步一步地轉變成輸出數據的。

這些解釋集中反映了通過前面的分析工作分析員所獲得的對目標系統的認識。

這些認識正確嗎?有沒有遺漏?用戶應該注意傾聽分析員的報告,并及時糾正和補充分析員的認識。

復查過程驗證了e知的元素,補充了未知的元素,填補了文檔中的空白。反復進行上述分析過程,分析員越來越深人地定義了系統中的數據和系統應該完成的功能。為了追蹤更詳細的數據流，分析員應該把數據流圖擴展到更低的層次。通過功能分解可以完成數據流圖的細化。

對數據流圖細化之后得到一組新的數據流圖,不同的系統元素之間的關系變得更清楚了。對這組新數據流圖的分析追蹤可能產生新的問題，這些問題的答案可能又在數據字典中增加一些新條目,并且可能導致新的或精化的算法描述。隨著分析過程的進展，經過提問和解答的反復循環,分析員越來越深人具體地定義了目標系統最終得到對系統數據和功能要求的滿意
了解。

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

簡易的應用規格說明技術

使用傳統的訪談或面向數據流自頂向下求精方法定義需求時,用戶處于被動地位而且往往有意無意地與開發者區分"彼此”。由于不能像同一個團隊的人那樣齊心協力地識別和精化需求，這兩種方法的效果有時并不理想(經常發生誤解，還可能遺漏重要的信息)。

為了解決上述問題，人們研究出一.種面向團隊的需求收集法，稱為簡易的應用規格說明技術。這種方法提倡用戶與開發者密切合作，共同標識問題，提出解決方案要素，商討不同方案并指定基本需求。今天,簡易的應用規格說明技術已經成為信息系統領域使用的主流技術。

使用簡易的應用規格說明技術分析需求的典型過程如下:

首先進行初步的訪談，通過用戶對基本問題的回答，初步確定待解決的問題的范圍和解決方案。然后開發者和用戶分別寫出“產品需求”。選定會議的時間和地點,并選舉一個負責主持會議的協調人。邀請開發者和用戶雙方組織的代表出席會議，并在開會前預先把寫好的產品需求分發給每位與會者。

要求每位與會者在開會的前幾天認真審查產品需求，并且列出作為系統環境組成部分的對象、系統將產生的對象以及系統為了完成自己的功能將使用的對象。此外,還要求每位與會者列出操作這些對象或與這些對象交互的服務(即處理或功能)。最后還應該列出約束條件(例如成本、規模、完成日期)和性能標準(例如速度、容量)。并不期望每位與會者列出的內容都是毫無遺漏的，但是，希望能準確地表達出每個人對目標系統的認識。

會議開始后,討論的第一個問題是,是否需要這個新產品，一旦大家都同意確實需要這個新產品,每位與會者就應該把他們在會前準備好的列表展示出來供大家討論。可以
把這些列表抄寫在大紙上釘在墻上，或者寫在白板上掛在墻上。理想的情況是,表中每一項都能單獨移動,這樣就能方便地刪除或增添表項，或組合不同的列表。在這個階段，嚴格禁止批評與爭論。

在展示了每個人針對某個議題的列表之后，大家共同創建張組合列表。 在組合列表中消去了冗余項，加人了在展示過程中產生的新想法,但是并不刪除任何實質性內容。在針對每個議題的組合列表都建立起來之后，由協調人主持討論這些列表。組合列表將被縮短、加長或重新措辭,以便更準確地描述將被開發的產品。討論的目標是，針對每個議題(對象、服務、約束和性能)都創建出一張意見致的列表。一旦得出了意見一 致的列表 ,就把與會者分成更小的小組，每個小組的工作目標是為每張列表中的項目制定小型規格說明。小型規格說明是對列表中包含的單詞或短語的準確說明。然后,每個小組都向全體與會者展示他們制定的小型規格說明，供大家討論。通過討論可能會增加或刪除一些內容 ，也可能進一步 做些精化工作。在完成了小型規格說明之后,每個與會者都制定出產品的一整套確認標準，并把自己制定的標準提交會議討論，以創建出意見致的確認標準。 最后,由一名或多名與會 者根據會議成果起草完整的軟件需求規格說明書。

簡易的應用規格說明技術并不是解決需求分析階段遇到的所有問題的“萬能靈藥”，但是，這種面向團隊的需求收集方法確實有許多突出優點:開發者與用戶不分彼此,齊心協力，密切合作;即時討論并求精;有能導出規格說明的具體步驟。

快速建立軟件原型

快速建立軟件原型是最準確、最有效、最強大的需求分析技術。快速原型就是快速建立起來的旨在演示目標系統主要功能的可運行的程序。構建原型的要點是，它應該實現用戶看得見的功能(例如屏幕顯示或打印報表)，省略日標系統的“隱含”功能(例如修改文件)。

快速原型應該具備的第--個特性是“快速”。快速原型的目的是盡快向用戶提供一個可在計算機上運行的目標系統的模型,以便使用戶和開發者在目標系統應該“做什么”這個問題上盡可能快地達成共識。因此，原型的某此缺陷是可以忽略的，只要這些缺陷不嚴重地損害原型的功能，不會使用戶對產品的行為產生誤解,就不必管它們。

快速原型應該具備的第二個特性是“容易修改”。如果原型的第一版不是用戶所需要的，就必須根據用戶的意見迅速地修改它，構建出原型的第二版,以更好地滿足用戶需求。在實際開發軟件產品時，原型的“修改一試用一反饋"過程可能重復多遍，如果修改耗時過多，勢必延誤軟件開發時間。

為了快速地構建和修改原型,通常使用下述3種方法和工具。

(1)第四代技術

第四代技術包括眾多數據庫查詢和報表語言、程序和應用系統生成器以及其他非常高級的非過程語言。第四代技術使得軟件工程師能夠快速地生成可執行的代碼，因此,它們是較理想的快速原型工具。

(2)可重用的軟件構件

另外一種快速構建原型的方法，是使用-組已有的軟件構件(也稱為組件)來裝配(而不是從頭構造)原型。軟件構件可以是數據結構(或數據庫)，或軟件體系結構構件(即程序),或過程構件(即模塊)。必須把軟件構件設計成能在不知其內部工作細節的條件下重用。應該注意，現有的軟件可以被用作“新的或改進的”產品的原型。

(3)形式化規格說明和原型環境

在過去的20多年中，人們已經研究出許多形式化規格說明語言和工具,用于替代自然語言規格說明技術。今天,形式化語言的倡導者正在開發交互式環境，以便可以調用自動工具把基于形式語言的規格說明翻譯成可執行的程序代碼,用戶能夠使用可執行的原型代碼去進一步精化形式化的規格說明。

分析建模與規格說明

分析建模

為了更好地理解復雜事物，人們常常采用建立事物模型的方法。所謂模型，就是為了理解事物而對事物作出的一種抽象 是對事物的一種無歧義的書面描述。 通常.模型由組圖形符號和組織這些符號的規則組成。

結構化分析實質上是一種創建模型的活動。為了開發出復雜的軟件系統，系統分析員應該從不同角度抽象出目標系統的特性，使用精確的表示方法構造系統的模型，驗證模型是否滿足用戶對目標系統的需求，并在設計過程中逐漸把和實現有關的細節加進模型中,直至最終用程序實現模型。

結構化分析準則，需求分析過程應該建立3種模型,它們分別是數據模型、功能模型和行為模型。

實體聯系圖，描繪數據對象及數據對象之間的關系,是用于建立數據模型的圖形。

數據流圖，描繪當數據在軟件系統中移動時被變換的邏輯過程，指明系統具有的變換數據的功能，因此，數據流圖是建立功能模型的基礎。

狀態轉換圖(簡稱為狀態圖)，指明了作為外部事件結果的系統行為。為此，狀態轉換圖描繪了系統的各種行為模式(稱為“狀態”)和在不同狀態間轉換的方式。狀態轉換圖是行為建模的基礎。

軟件需求規格說明

通過需求分析除了創建分析模型之外，還應該寫出軟件需求規格說明書,它是需求分析階段得出的最主要的文檔。

通常用自然語言完整、準確、具體地描述系統的數據要求功能需求、性能需求、可靠性和可用性要求、出錯處理需求、接口需求、約束、逆向需求以及將來可能提出的要求。自 然語言的規格說明具有容易書寫、容易理解的優點，為大多數人所歡迎和采用。為了消除用自然語言書寫的軟件需求規格說明書中可能存在的不一致、歧義、含糊、不完整及抽象層次混亂等問題，有些人主張用形式化方法描述用戶對軟件系統的需求。