軟件需求分析工作是軟件生存期中重要的一步，也是決定性的一步。只有通過軟件需求分析，才能把軟件功能和性能的總體概念描述為具體的軟件需求規格說明，從而奠定軟件開發的基礎。軟件需求分析工作也是一個不斷認識和逐步細化的過程。該過程將軟件設計階段所確定的軟件范圍(工作域)逐步細化到可詳細定義的程度，并分析出各種不同的軟件元素，然后為這些元素找到可行的解決方法。

　　制定軟件的需求規格說明不只是軟件開發人員的事，用戶也起著至關重要的作用。用戶必須對軟件功能和性能提出初步要求，并澄清一些模糊概念。而軟件分析人員則要認真了解用戶的要求，細致地進行調查分析，把用戶“做什么”的要求最終轉換成一個完全的、精細的軟件邏輯模型并寫出軟件的需求規格說明，準確地表達用戶的要求。

　　1.軟件需求分析任務

　　需求分析所要做的工作是深入描述軟件的功能和性能，確定軟件設計的限制和軟件同其他系統元素的接口細節。定義軟件的其他有效性需求。

　　分析員通過需求分析，逐步細化對軟件的要求，描述軟件要處理的數據域，并給軟件開發提供一種可轉化為數據設計、結構設計和過程設計的數據與功能表示。在軟件完成后，制定的軟件需求規格說明還要為評價軟件質量提供依據。

　　需求分析階段研究的對象是軟件項目的用戶要求。需要注意的是，必須理解用戶的各項要求，但又不能全盤接受所有的要求。因為并非所有用戶要求都是合理的。對其中模糊的要求還需要澄清，然后才能決定是否可以采納。對于那些無法實現的要求應向用戶做充分的解釋，以求得諒解。

　　準確地表達所接受的用戶要求，是需求分析的另一個重要方面。只有經過確切描述的軟件需求才能成為軟件設計基礎。

　　通常軟件開發項目是要實現目標系統的物理模型，即確定待開發軟件系統的系統元素，并將功能和數據結構分配到這些系統元素中，它是軟件實現的基礎。但是目標系統的具體物理模型是由它的邏輯模型經實例化，即具體到某個業務領域而得到的。與物理模型不同，邏輯模型忽視實現機制與細節，只描述系統要完成的功能和要處理的數據。作為目標系統的參考，需求分析的任務就是借助于當前系統的邏輯模型導出目標系統的邏輯模型，解決目標系統的“做什么”的問題。

　　(1)獲得當前系統的物理模型。當前系統可能是需要改進的某個已在計算機運行的數據處理系統，也可能是一個人工的數據處理過程。在這一步首先分析、理解當前系統是如何運行的，了解當前系統的組織機構、輸入輸出、資源利用情況和日常數據處理過程，并用一個具體模型來反映自己對當前系統的理解。這一模型應客觀地反映現實世界的實際情況。

　　(2)抽象出當前系統的邏輯模型。在理解當前系統“怎樣做”的基礎上，抽取其“做什么”的本質，從而從當前系統的物理模型抽象出當前系統的邏輯模型。

　　在物理模型中有許多物理因素，隨著分析工作的深入，有些非本質的物理因素就成為不必要的負擔，因而需要對物理模型進行分析，區分出本質的和非本質的因素，去掉那些非本質的因素即可獲得反映系統本質的邏輯模型。

　　(3)建立目標系統的邏輯模型。分析目標系統與當前系統邏輯上的差別，明確目標系統統到底要“做什么”，從當前系統的邏輯模型導出目標系統的邏輯模型。

　　(4)為了對目標系統做完整的描述，還需要對得到的邏輯模型做一些補充。

　?、僬f明目標系統的用戶界面。根據目標系統所處的應用環境及它與外界環境的相互關系，研究所有可能與它發生聯系和作用的部分，從而決定人機界面。

　?、谡f明至今尚未詳細考慮的細節。這些細節包括系統的啟動和結束、出錯處理、系統的輸入輸出和系統性能方面的需求。

　?、燮渌?。例如系統的其他必須滿足的性能和限制等等。

　　2.需求分析的過程

　　需求分析階段的工作，可以分成以下4個方面:對問題的識別、分析與綜合、制定規格說明和評審。

　　(1)問題識別

　　首先系統分析人員要研究計劃階段產生的可行性分析報告(如果有的話)和軟件項目實施計劃。主要是從系統的角度來理解軟件并評審用于產生計劃估算的軟件范圍是否恰當。確定對目標系統的綜合要求，即軟件的需求。并提出這些需求實現條件，以及需求Υ锏降謀曜肌R簿褪且?笏??⑷砑?鍪裁矗?齙絞裁闖潭取U廡┬棖蟀??

　　·功能需求:列舉出所開發軟件在職能上應做什么。這是最主要的需求。

　　·性能需求:給出所開發軟件的技術性能指標，包括存儲容量限制、運行時間限制、安全保密性等。

　　·環境需求:這是對軟件系統運行時所處環境的要求。例如在硬件方面，采用什么機型、有什么外部設備、數據通信接口等等。在軟件方面，采用什么支持系統運行的系統軟件(指操作系統、網絡軟件、數據庫管理系統等)。在使用方面，需要使用部門在制度上、操作人員的技術水平上應具備什么樣的條件等等。

　　可靠性需求:各種軟件在運行時，失效的影響各不相同。在需求分析時，應對所開發軟件在投入運行后不發生故障的概率，按實際的運行環境提出要求，對于那些重要的軟件，或是運行失效會造成嚴重后果的軟件，應當提出較高的可靠性要求，以期在開發的過程中采取必要的措施，使軟件能夠高度可靠地穩定運行，避免因運行事故而帶來的損失。

　　·安全保密要求:工作在不同環境的軟件對其安全，保密的要求顯然是不同的。應當把這方面的需求恰當地做出規定，以便對所開發的軟件給予特殊的設計，使其在運行中其安全方面的性能得到必要的保證。

　　·用戶界面需求:軟件與用戶界面的友好性是用戶能夠方便、有效、愉快地使用該軟件的關鍵之一。從市場角度來看，具有友好用戶界面的軟件有很強的競爭力。因此，必須在需求分析時，為用戶界面細致地規定達到的要求。

　　·資源使用需求:這是指所開發軟件運行時所需的數據、軟件、內存空間等各項資源外，軟件開發時所需的人力、支撐軟件、開發設備等則屬于軟件開發的資源，需要在需求分析時加以確定。

　　·軟件成本消耗與開發進度需求:在軟件項目立項后，要根據合同規定，對軟件開發的進度和步驟的費用提出要求，作為開發管理的依據。

　　·預先估計以后系統可能達到的目標。這樣，在開發過程中，可對系統將來可能擴充與修改做準備。一旦需要時，就比較容易進行補充和修改。

　　·功能性需求是人們普遍關注的，但常常忽視對非功能性需求的分析。其實非功能性需求并不是無關緊要的，它們涉及到的方面多而廣，因而容易被忽略。如果在進行需求分析之前沒有做過可行性分析，那么補充完成這部分工作往往是必要的。從問題定義和調查研究入手，與用戶密切聯系，詳細了解問題提出的背景，弄清要解決什么問題。然后從軟件系統特性和用戶目標出發，做市場調查和現場考察。仔細收集信息之后進行數據分析和功能分析，建立系統的高層邏輯模型，再進一步做成本/效益分析。最后提交一份可行性分析報告，從技術、經濟、社會效應等方面論證可行性，以確認軟件開發的目標是否可行。

　　問題識別的另一項工作是建立分析所需要的通信途徑，以保證能順利地對問題進行分析。分析員必須與用戶、軟件開發機構的管理部門、軟件開發組的人員建立聯系。項目負責人在此過程中起協調人的作用。分析員通過這種通信途徑與各方商討，以便能滿足用戶的要求。

　　(2)分析與綜合

　　需求分析的第二步工作是問題分析和方案的綜合。分析員需從數據流和數據結構出發，逐步細化所有的軟件功能，找出系統各元素之間的聯系、接口特性和設計上的限制分析它們是否滿足功能要求，是否合理。依據功能需求、性能需求、運行特性和設計上的限制分析它們是否滿足功能要求，是否合理。依據功能需求、性能需求、運行環境需求等，剔除其不合理的部分，增加其需要的部分。最終綜合成系統的解決方案，給出目標系統的詳細邏輯模型。

　　在這個步驟中，分析和綜合工作反復地進行。在對現行問題和期望的信息(輸入和輸出)進行分析的基礎上，分析員開始綜合出一個或幾個解決方案，然后檢查這些方案是否符合軟件計劃中規定的范圍等等，再進行修改。總之，對問題進行分析和綜合的過程將一直持續到分析員與用戶雙方都感到有把握正確地制定該軟件的規格說明為止。

　　常用的分析方法有面向數據流的結構化分析方法(簡稱SA)、面向數據結構的Jackson方法(簡稱JSD)、面向對象的分析方法(簡稱OOA)等，以及用于建立動態、模型的狀態遷移圖或Petri網等。這些方法都采用圖文結合的方式，可以直觀地描述軟件的邏輯模型。

　　(3)編制需求分析的文檔

　　已經確定的需求應當得到清晰準確的描述。通常把描述需求的文檔叫做軟件需求規格說明書。同時，為了確切表達用戶對軟件的輸入輸出要求，還需要制定數據要求說明書及編寫初步的用戶手冊，著重反映被開發軟件的用戶界面和用戶使用的具體要求。

　　此外，依據在需求分析階段對系統的進一步分析，從目標系統的精細模型出發，可以更確切地估計所開發項目的成本與進度，從而修改、完善與確定軟件開發的實施計劃。

　　(4)需求分析評審

　　作為需求分析階段工作的復查手段，在需求分析的最后一步，應該對功能的正確性、完整性和清晰性，以及其他需求給予評價。評審的主要內容是:

　　·系統定義的目標是否與用戶的要求一致;

　　·系統需求分析階段提供的文檔資料是否齊全;

　　·文檔中的所有描述是否完整、清晰、準確所反映用戶要求;

　　·與所在其他系統成分的重要接口是否都已經描述;

　　·所開發項目的數據流與數據結構是否足夠、確定;

　　·所有圖表是否清楚，在不補充說明時能否理解;

　　·主要功能是否已包括在規定的軟件范圍之內，是否都已充分說明;

　　·設計的約束條件或限制條件是否符合實際;

　　·開發的技術風險是什么;

　　·是否考慮過軟件需求的其他方案;

　　·是否考慮過將來可能會提出的軟件需求;

　　·是否詳細制定了檢驗標準，它們能否對系統定義是否成功進行確認;

　　·有沒有遺漏、重復或不一致的地方;

　　·用戶是否審查了初步的用戶手冊;

　　·軟件開發計劃中的估算是否受到了影響。

　　為保證軟件需求定義的質量，評審應以專門指定的人員負責，并按規程嚴格進行。評審結束應有評審負責人的結論意見及簽字。除分析員之外，用戶，開發部門的管理者，軟件設計、實現、測試的人員都應當參加評審工作。通常，評審的結果都包括了一些修改意見，待修改完成后再經評審通過，才可進入設計階段。

　　3.軟件需求分析的原則

　　近年來已提出了許多軟件分析與說明的方法，雖然各種分析方法都有其獨特的描述方法，但總的看來，所有分析方法還是有它們共同適用的基本原則。

　　(1)必須能夠表達和理解問題的數據域和功能域

　　所有軟件定義與開發工作最終是為了解決數據處理問題，就是將一種形式的數據轉換成另一種形式的數據。其轉換過程必定經歷輸入、加工數據和產生結果數據等步驟。對于計算機程序處理的數據，其數據域應包括數據流、數據內容和數據結構。

　　數據流即數據通過一個系統時的數據存儲(如磁盤文件或內存緩沖區)中引入附加數據。對數據進行轉換是程序中應有的功能或子功能。兩個轉換功能之間的數據傳遞就確定了功能間的接口。

　　數據內容即數據項。例如，學生名冊包含了班級、人數、每個學生的學號、姓名、性別、各科成績等。學生名冊的內容由它所包含的項定義。為了理解對學生名冊的處理，必須要理解它的數據內容。

　　數據結構即各種數據項的邏輯組織。數據是組織成表格，還是組織成有層次的樹型結構?在結構中數據項與其他哪些數據項相關?所有數據是在一個數據結構中，還是在幾個數據結構中?一個結構中的數據與其他結構中的數據如何聯系?這些問題都由數據結構分析來解決。

　　(2)必須按自項向下、逐層分解的方式對問題進行分解和不斷細化

　　如果將軟件要處理的問題作為一個整體來看，顯得太大太復雜很難理解。如果把問題以某種方式分解為幾個較易理解的部分，并確定各部分間的接口，從而實現整體功能。

　　在需求分析階段，軟件的功能域和信息域都能做進一步的分解。這種分解可以是同一層次上的，稱為橫向分解;也可以是多層次的縱向分解。

　　例如，把一個功能分解成幾個子功能，并確定這些子功能與父功能的接口，就屬于橫向分解。但如果繼續分解，把某些子功能又分解為小的子功能，某個小的子功能又分解為更小的功能，這就屬于縱向分解了。

　　(3)要給出系統的邏輯視圖和物理視圖

　　給出系統的邏輯視圖(邏輯模型)和物理視圖(物理模型)，這對系統滿足處理需求所提出的邏輯限制條件和系統中其他成分提出的物理限制條件是必不可少的。軟件需求的邏輯視圖給出軟件要達到的功能和要處理的數據之間的關系，而不是實現的細節。例如，一個商店的銷售處理系統要從顧客那里獲取訂單，系統讀取訂單的功能并不關心訂單數據的物理形式和用什么設計讀入，也就是說無需關心輸入的機制，只是讀取顧客的訂單而已。類似的，系統中檢查庫存的功能只關心庫存文件的數據結構，而不關心在計算機中的具體存儲方式。軟件需求的邏輯描述是軟件設計的基礎。

　　軟件需求的物理視圖給出處理功能和數據結構的實際表示形式，這往往是由設備決定的，如一些軟件靠終端鍵盤輸入數據，另一些軟件靠模擬數據轉換設備提供數據。分析員必須弄清系統元素對軟件的限制并考慮功能和信息結構的物理表示。

　　4.軟件需求分析方法

　　需求分析方法由對軟件的數據域和功能域的系統分析過程及其表示方法組成。大多數的需求分析方法是由數據驅動的，也就是說，這些方法提供了一種表示數據域的機制。分析員根據這種表示，確定軟件功能及其他特性，最終建立一個待開發軟件的抽象模型，即目標系統的邏輯模型。數據域具有3種屬性:數據流、數據內容和數據結構。通常，一種需求分析方法總要利用其中的一種或幾種屬性。

　　目前已經出現了許多需求分析方法，每一種分析方法都引入了不同的記號和分析策略。但是它們仍具有以下的共性:

　　(1)支持數據域分析的機制

　　盡管每種方法進行數據域分析的方式不同，但它們仍有一些共同點。所有的方法都直接或間接地涉及到數據流、數據內容或數據結構域的屬性。在多數情況下，數據流特征是用將輸入轉換成輸出的變換(功能)過程來描述的，數據內容可以用數據詞典機制明確表示，或者通過描述數據或數據對象的層次結構隱含地表示。

　　(2)功能表示的方法

　　功能一般用數據變換或加工來表示，每項功能可用規定的記號(圓圈或方框)標識。功能的說明可以用自然語言文本來表達，也可以用形式化的規格說明語言來表達，還可以用上述的兩種方式的混合方式———結構化語言來描述。

　　(3)接口的定義

　　接口的說明通常是數據表示和功能表示的直接產物。某個具體功能的流進和流出數據流應是其他相關功能的流出或流入的數據流。因此，通過數據流的分析可以確定功能間的接口。

　　(4)問題分解的機制以及對抽象的支持

　　問題分解和抽象主要依靠分析員在不同抽象層次上表示數據域和功能域，以逐層細化的手段建立分層結構來實現。例如，無論使用哪種分析方法，都能表示“計算職工每月工資”之類的功能，并在這個抽象層次上操縱這個功能。另外，所有的分析方法都提供逐層分解的機制，把“計算職工每月工資”功能劃分成一些子功能，如計算房租、計算用電費、計算用水費、計算養老保險費等等。其中，每項子功能還可以在更低的一級抽象層次上表示。

　　(5)邏輯視圖和物理視圖

　　大多數方法允許分析員在著手問題的邏輯解決方案之前先分析物理視圖。通常，同一種表示法既可用來表示邏輯視圖，也可用來表示物理視圖。

　　(6)系統抽象模型

　　為了能夠比較精確地定義軟件需求，可以建立待開發軟件的一個抽象的模型，用基于抽象模型的術語來描述軟件系統的功能和性能，形成軟件需求規格說明。這種抽象的模型是從外部現實世界的問題領域抽象而來，在高級層次上描述和定義系統的服務。

　　對于比較簡單的問題，不必建立抽象系統模型?；蛘呖梢哉J為，系統模型在分析員頭腦中形成，直接由分析員寫成規格說明。但對于比較復雜的問題，僅有在頭腦中想象的模型是不夠的，必須建立適當的比較形式化的抽象系統模型，才能準確全面地反映問題領域中各種復雜的要求。不同類型的問題有不同的需要解決的中心問題，因而要建立不同類型的系統模型。對于數學軟件，設計的中心問題是算法，軟件人員主要力量要花在數學模式算法的考慮上。對于數據通信軟件，中心問題是數據傳送和過程控制，實現算法簡單，采用數據流模型比較合適。對于涉及大量數據的數據處理軟件，中心問題是數據處理，包括數據的采集、數據的傳送、存儲、變換、輸出等，一旦了解了數據結構，與它相關的算法就很簡單了。如果系統要求有數據支持，通過數據庫獲取和存放信息，還需要考慮數據在數據庫中的組織方式和存取方法，建立數據庫模型。因此，在分析過程中數據模型是首先要集中精力考慮的問題。

　　系統模型的建立是對現實世界中存在的有關實體和活動的抽象和精化，其建立過程包括觀察分析、模型表示和模型檢查3個階段。

　　首先，分析員和用戶合作，從各方面觀察現實世界中的有關實體和活動，建立理解的共同基準，分清哪些概念與系統相關，必須納入系統模型，哪些是系統模型不必關心的，分析員和用戶在共同理解的基礎上，建立系統模型，包括系統提供的各種系統服務，模型表示的細節應有:系統輸入、系統輸出、系統數據處理、系統控制等。

　　建立系統模型以后，還要進行檢查。除了靜態檢查之外，系統描述可以部分地模擬執行，將執行情況與對外部現實世界系統觀察得到的系統跟蹤信息進行對照，檢查模型是否符合要求。這種建立系統模型并模擬執行和檢查的方法叫做系統原型開發。