【摘要】在軟體開發專案中，需求分析是關乎軟體專案開發成敗的重要因素。現在的軟體專案中返工開銷佔了總開銷很大比例，而導致返工的主要原因是需求分析不明確。針對這一情況，文章闡述了軟體開發中需求分析任務、需求分析過程、需求分析方法、需求分析變更問題，以及如何確保需求分析質量的措施。

【關鍵詞】軟體開發;需求分析;原型法;需求變更

隨著全球經濟、科技的快速發展和社會資訊化程序的加快，計算機被廣泛應用於各行業中，各種應用軟體應運而生，各行業的管理或生產日趨專一化、數字化、快捷化。從而使用者對計算機軟體的要求更加複雜和嚴格。軟體需求分析正是解決使用者這種需求，軟體需求分析是關乎軟體專案開發成敗的重要因素。有資料表明，現在的軟體專案中返工開銷幾乎佔了總開發的一半，而導致返工的主要原因是需求分析不明確，甚至有些人不知道需求分析是什麼，從而引發專案開發中的一系列更改。這些更改可能導致浪費大量資源、軟體專案無法按時完成等嚴重問題。所以，需求分析是軟體設計和實現的基礎，是軟體專案邁向成功的第一步!

一、軟體需求分析的任務

一個軟體專案的開發主要分為五個階段：需求分析階段、設計階段、編碼階段、測試階段和維護階段。而需求分析階段所得到的結果，是軟體專案開發中其他四個階段的必備條件。從以往的經驗來看，需求分析中的一個小的偏差，就可能導致整個專案無法達到預期的效果，或者說最終開發出的產品不是使用者所需要的。何謂軟體需求分析。先舉個例子來說明，對於建造房子這個問題相信大多數人都知道，使用者要建一幢房子，建房者一定會與使用者詳細討論各種細節，樓層高多少?構架如何?圖紙樣式等等，每個環節都有詳細的過程文件，雙方都明白假如完工後修改帶來的損失以及變更細節的危害性。同樣在軟體需求分析中也需要有詳細的文件，軟體開發者要從使用者的業務中提取出軟體系統能夠幫助使用者解決的業務問題，通過對使用者業務問題的分析，規劃出開發者的軟體產品。這個步驟是對使用者業務需求的一個昇華，是一個把使用者業務管理流程優化，轉化為軟體產品，從而提升管理而實現質的飛躍，這一步是否成功，直接關係到開發出來的軟體產品能否得到使用者認可，順利交付給客戶，客戶能否真正運用開發者的產品幫助他解決業務或管理問題。

軟體需求分析的任務不是確定系統怎樣完成的工作，而是確定系統必須完成那些工作，也就是對目標系統提出完整、準確、清晰、具體的要求。它所做的工作是深入描述軟體的功能和效能，確定軟體設計的限制和軟體同其他系統的介面細節，定義軟體的其他有效性要求。

軟體需求分析的任務就是藉助於當前系統的邏輯模型匯出目標系統的邏輯模型，解決目標系統的“做什麼”的問題。其實現步驟是：(1)獲得當前系統的物理模型;(2)抽象出當前系統的邏輯模型;(3)建立目標系統的邏輯模型。如圖1所示:

二、軟體需求分析的過程

軟體需求分析的過程具體可分為對問題的識別、分析與綜合、制定規格說明和評審。

問題識別是指系統分析人員研究可行性分析報告和軟體專案實施計劃，確定目標系統的綜合要求，並提出這些需求實現條件，以及需求應達到的標準。這些需求分為：功能性需求+非功能性需求，其具體包括：(1)功能需求：列舉出所開發軟體在職能上應做什麼。(2)效能需求：給出所開發軟體的技術性能指標，如儲存容量限制、執行時間限制、安全保密性等。(3)環境需求：軟體系統執行時所處環境的要求，如硬體方面：機型、外部裝置、資料通訊介面;軟體方面：系統軟體，包括作業系統、網路軟體、資料庫管理系統方面;使用方面：使用部門在制度上，操作人員上的技術水平上應具備怎樣的條件。(4)可靠性需求：對所開發軟體在投入執行後不發生故障的概率，按實際的執行環境提出要求。所以對於重要的軟體，或是執行失效會造成嚴重後果的軟體，應提出較高的可靠性要求。(5)安全保密要求：應當在這方面恰當地做出規定，對所開發的軟體給予特殊的設計，使其在執行中，其安全保密方面的效能得到必要的保證。(6)使用者介面需求：為使用者介面細緻地規定到達的要求。(7)資源使用需求：開發的軟體在執行時和開發時所需要的各種資源。(8)軟體成本消耗與開發進度需求：在軟體專案立項後，要根據合同規定，對軟體開發的進度和各步驟的費用提出要求，作為開發管理的依據。(9)預先估計以後系統可能達到的目標，這樣可以比較容易對系統進行必要的補充和修改。 除了這些必需的需求，問題識別的另一個工作是建立分析所需要的通訊途徑，以保證能順利地對問題進行分析。

分析與綜合的目標是給出目標系統的詳細邏輯模型。在此步驟中，分析和綜合工作需反覆地進行。

對於編制需求分析的文件，我們稱描述需求分析文件為軟體需求規格說明書，除了編寫軟體需求規格說明書之外，還要制定資料要求說明書以及編寫初步的使用者手冊。

需求分析評審是指在需求分析的最後一步，對系統功能的正確性、完整性和清晰性，以及其他需求給予評價。

三、軟體需求分析方法

軟體需求分析方法很多，如傳統方法、原型方法、模型驅動方法、面向資料結構的結構化資料系統開發方法等，選擇那種方法要根據哪些資源在什麼時間對開發人員有效，不能盲目套用。這裡著重闡述原型方法。

傳統的軟體工程方法強調自頂向下分階段開發，要求在進入實際開發期之前必須預先對需求嚴格定義。但實踐表明，在系統建立起來之前很難緊緊依靠分析就確定出一套完整、一致、有效的應用需求，並且這種預先定義的策略更不能適應使用者需求不斷變化的情況。由此，原型法應運而生，它一反傳統的自頂向下的開發模式，是目前較流行的使用開發模式。

(一)原型的概念

原型最早使用在製造業和機械產品設計中，先做出產品的基本模型，然後進行完善和改進，最後得到符合要求的產品。在軟體工程中，原型是指要開發的軟體系統的原始模型，是軟體早期一個可執行的版本，它反映最終系統的某些重要特性(如軟體介面與佈局、功能等)。在獲得一組最基本的需求說明後，通過分析構造出一個小型的簡約軟體系統，滿足使用者的基本要求，然後不斷演化得到較高質量的產品。原型法克服了傳統軟體生命週期法的一些弊端，具有快速靈活、互動式等特點，方法核心是用互動、快速建立起來的原型取代了不太明確的需求規格說明，使用者通過在計算機上實際執行和試用原型系統得到親身感受並受到啟發，通過反應和評價向開發者提供真實的反饋意見。然後開發者根據使用者的意見對原型加以改進，通過“原型構造-試用執行-評價反饋-分析修改”的多次反覆,從而提高最終產品的質量。如圖2所示：

(二)原型分類

由於建立原型的目的不同，實現原型的途徑也有所不同，通常有以下三種類型：(1)探索型。這種原型目的是要弄清除客戶對目標系統的要求，確定所希望的特性，並探討多種方案的可行性。(2)實驗性。這種原型用於大規模開發和實現之前，考核方案是否合適，規格說明是否可靠。(3)進化型。這種原型的目的不在於改進規格說明，而是將系統建造得容易處理變化，在改進原型的過程中，逐步將原型進化成最終系統。

(三)原型建立技術

原型建立技術：(1)可執行規格說明。它是基於需求規格說明的一種自動化技術，使用這種方法，人們可以直接觀察用語言規定的任何系統的功能和行為。(2)基於指令碼的設計。指令碼是使用者介面的原型。一個指令碼用來模擬在系統執行期間使用者經歷的事件。它提供了輸入——處理——輸出的螢幕格式和有關對話的模型。因此，軟體開發者能夠給使用者顯示系統的逼真的檢視，使使用者得以判斷是否符合他的意圖。(3)自動程式設計在程式自動生成環境的支援下，利用計算機實現軟體的開發。它可以自動地或半自動地把使用者的非過程式問題規格說明轉換為某種高階語言程式。(4)專用語言。專用語言是應用領域的模型化語言。在原型開發中使用專用語言，可方便使用者和軟體開發者對系統特性進行交流。(5)可複用的軟體。利用可複用的模組，通過適當的組合，構造的原型系統。為了快速地構造原型，這些模組首先必須有簡單而清晰的介面;其次它們應當儘量不依賴其它的模組或資料結構;最後，它們應具有一些通用的功能。(6)簡化假設。 簡化假設使設計者迅速得到一個簡化的系統。儘管這些假設可能實際上並不能成立，但它們可以使開發者的注意力集中在一些主要的方面。在修改一個檔案時，可以假設這個檔案確實存在。 在存取檔案時，待存取的記錄總是存在。一旦計劃中的系統滿足使用者所有的要求，就可以撤消這些假設，並追加一些細節。

(四)原型分析優點

原型分析優點有：(1)增進軟體開發者和使用者對需求的理解，使比較含糊的具有不確定性的軟體需求(主要功能性的需求)明確化。(2)軟體原型化方法提供了一種有力的學習手段。(3)使用原型化方法，可以容易地確定系統的效能，確認系統主要服務的可應用性，確認系統設計的可行性，確認系統最終作為產品。(4)軟體原型的最終版本，有的可以原封不動地稱為產品，有的略加修改就可以成為最終系統的一個組成部分，這樣有利於建成最終系統。

四、需求變更

在開發專案過程中，使用者隨時會提出一些新的需求，要求開發人員解決，這些需求的提出，有時在開發階段中有時在開發階段後。這種在需求分析的兩個相鄰子階段中，或者在迭代週期的需求分析中，後一段或週期的需求分析結果與前一次不一致， 我們把這種不一致稱為需求變更。產生需求變更的原因主要有以下幾個方面：(1)在需求分析階段，開發人員與使用者的溝通不夠。在需求分析階段，開發方與使用者沒有很好的交流，開發方就根據使用者提供的大概資訊，自己推匯出使用者的需求。通過這種需求分析得出的需求往往會和使用者的實際需求相差甚遠，導致使用者提出更改需求。(2)專案的實施週期過長。隨著時間的推移，使用者對整個系統的瞭解也越來越深入。他們會對模組的介面、功能和效能方面提出更高更多的要求。(3)技術更新過快。由於技術的快速更新， 企業可能引進一些新的裝置， 而這些裝置可能就會與我們的目標系統有直接的關係， 由於這一變化可能發生在解決使用者原先問題之前或者之中， 那麼開發人員不得不加入這一新的需求。

為了儘可能地避免發生需求變更，以及保證需求分析的高穩定性，可以採用以下方法：(1)對開發人員進行專業培訓。因為，開發人員對所開發系統的領域不一定了解，為了開發人員能更好理解使用者的需求，在做需求分析的初始階段對開發人員進行該領域相關知識的培訓。(2)開發方與使用者進行協作和交流。在使用者提出需求變更時開發人員應該認真聽取使用者的要求並加以整理和分析。分析需求變更的原因並提出可行的替代方案;同時向用戶說明這些需求變更會對整個專案的開發帶來的不良後果。(3)合同約束。由於需求變更可能會對整個項(下接第85頁)(上接第77頁)目產生影響，所以，開發方和使用者在簽定專案合同時，可以對需求變更增加一些相關的合同條款。(4)建立需求文件並進行版本控制。需求分析的最終成果是一份客戶和開發人員對所開發的產品達成共識的文件。有了這份文件， 即使開發人員的角色有所變動，也不會對需求分析的前期工作有所影響。對每次的需求變更都用一個新的版本來標識。(5)需求評審和設立需求基線。為了讓開發方詳細瞭解使用者的需求，讓不同人員從不同的角度對需求進行驗證，作為需求的提出者， 在需求評審過程中，使用者往往能提出許多有價值的意見。同時，也是使用者對需求進行最後確認的機會，可以有效減少需求變更的發生。需求在通過正式評審和批准之後，應該確定需求基線，進一步的需求變更將在此基線的基礎上，依照專案定義的變更過程進行。設定需求基線可以將變更引起的麻煩減至最小。

五、結語

本文通過對軟體需求分析的詳細闡述，來說明軟體需求分析是軟體設計及實現的基礎，對於整個軟體專案來說至關重要。如果能科學地進行需求分析，採用一些技術來避免可能導致需求分析失敗的情況，能圓滿地完成軟體需求分析任務，為後續軟體開發打下堅實的基礎。