軟件需求分析的思考

馮阿芳 石 研

（哈爾濱學院數學與計算機學院，黑龍江 哈爾濱 150086）

1 什么是軟件需求

一般可以從用戶角度（即系統的外部行為）和從開發者角度（即系統的內部特性）兩個方面來闡述軟件需求的定義。

從用戶角度一般認為軟件需求是“指明系統必須實現什么的規格說明”。它描述了系統的行為、特性或屬性，是在開發過程中對系統的約束。

從開發者角度可以認為需求是“用戶所需要的并能觸發一個程序或系統開發工作的說明”。有些需求分析專家拓展了這個概念：“從系統外部能發現系統所具有的滿足于用戶的特點、功能及屬性等”。

從上面這些不同形式的定義不難發現：這些定義都強調產品是什么樣的，而并非產品是怎樣設計和構造的。很難給軟件需求一個準確的定義，真正的“需求”實際上在客戶的腦海里，但一般情況下，用戶并不能描述自己的需要，只就需要系統分析人員根據用戶的自己語言的描述整理出相關的需要再進一步和客戶核對。

2 軟件需求的類型

軟件需求包括三個不同的層次：業務需求、用戶需求和功能需求（也包括非功能需求）。

業務需求：反映了組織機構或客戶對系統、產品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明。

用戶需求：文檔描述了用戶使用產品必須要完成的任務，這在使用實例文檔或方案腳本說明中予以說明。

功能需求和非功能需求：功能需求定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業務需求。作為功能需求的補充，軟件需求規格說明還應包括非功能需求，它描述了系統展現給用戶的行為和執行的操作等。它包括產品必須遵從的標準、規范和合約；外部界面的具體細節；性能要求；設計或實現的約束條件及質量屬性。所謂約束是指對開發人員在軟件產品設計和構造上的限制。質量屬性是通過多種角度對產品的特點進行描述，從而反映產品功能。多角度描述產品對用戶和開發人員都極為重要。

下面通過與文字處理系統相關的部分需求來說明需求的分類。業務需求是：“用戶能有效地糾正文檔中的拼寫錯誤”，該產品的包裝盒封面上可能會標明這是個滿足業務需求的拼寫檢查器。而對應的用戶需求可能是“找出文檔中的拼寫錯誤并通過一個提供的替換項列表來供選擇替換拼錯的詞”。同時，該拼寫檢查器還有許多功能需求，如找到并高亮度提示錯詞的操作；顯示提供替換詞的對話框以及實現整個文檔范圍的替換。

3 需求分析的任務

開發軟件系統最為困難的部分就是準確說明開發什么。最為困難的概念性工作便是編寫出軟件需求規格說明，所謂軟件需求規格說明是軟件應滿足的全部需求，并可以用文檔的方式完整和精確地陳述這些需求，包括所有面向用戶、面向機器和其它軟件系統的接口。這項工作非常關鍵，一旦做錯，將最終會給系統帶來極大損害，并且以后再對它進行修改也極為困難。一個質量較高的軟件需求規格說明通常應具備完整性、正確性、可行性、無二義性等基本特征。

4 需求分析過程

可把整個軟件需求工程研究領域劃分為需求開發和需求管理兩部分。需求開發可進一步分為：問題獲取、分析、編寫規格說明和驗證四個階段。這些子項包括軟件類產品中需求收集、評價、編寫文檔等所有活動。需求開發活動包括以下幾個方面：確定產品所期望的用戶類別；獲取每個用戶類的需求；了解實際用戶任務和目標以及這些任務所支持的業務需求；分析源于用戶的信息以區別用戶任務需求、功能需求、業務規則、質量屬性、建議解決方法和附加信息；將系統級的需求分為幾個子系統，并將需求中的一部份分配給軟件組件；了解相關質量屬性的重要性；與客戶商討實施優先級的劃分；將所收集的用戶需求編寫成文檔和模型；評審需求規格說明，確保對用戶需求達到共同的理解與認識，并在整個開發小組接受說明之前將問題都弄清楚。

需求管理需要建立并維護在軟件工程中同客戶達成的合同。這種合同都包含在編寫的需求文檔與模型中，客戶的接受僅是需求成功的一半，開發人員也必須能夠接受他們，并真正把需求應用到產品中。通常的需求管理活動包括：定義需求基線（迅速制定需求文檔的主體）；評審提出的需求變更、評估每項變更的可能影響從而決定是否實施它；以某種可控制的方式將需求變更融入到項目中；使當前的項目計劃與需求一致；估計變更需求所產生影響并在此基礎上協商新的承諾，并體現在項目解決方案上；讓每項需求都能與其對應的設計、源代碼和測試用例聯系起來以實現跟蹤；在整個項目過程中跟蹤需求狀態及其變更情況。

以上幾點說明是根據國內外的一些系統實施的相關成功經驗，進行了總結。

5 需求分析的過程中應注意的若干問題

不重視需求分析過程將會給項目的開發帶來失敗的風險，為盡量減少項目風險，在需求分析的過程中應注意以下幾個問題帶來的風險。

5.1 無足夠用戶參與

在實施項目時，若無足夠的用戶參與，系統人員獲得的需求是片面的，不完整的，這樣系統在需求之初就埋下風險。應讓具有代表性的用戶在項目早期直接參與到開發隊伍中，并一同經歷整個開發過程。客戶和開發人員應積極合作，共同開發項目需求。有時開發人員覺得已經明白用戶的需求了，但是在某些情況下，而客戶并不太明白自己的真正需求。

5.2 用戶需求的不斷增加

在開發中若不斷地補充需求，項目就越變越龐大以致超過其計劃及預算范圍。計劃并不總是與項目需求規模與復雜性、風險、開發生產率及需求變更實際情況相一致，這使得問題更難解決。實際上，問題根源在于用戶需求的改變和開發者對新需求所作的修改。

要想把需求變更范圍控制到最小，必須一開始就對項目視圖、范圍、目標、約束限制和成功標準給予明確說明，并將此說明作為評價需求變更和新特性的參照框架。說明中包括了對每種變更進行變更影響因素分析的變更控制過程，有助于所有風險承擔者明白業務決策的合理性，即為何進行某些變更，相應消耗的時間、資源或特性上的折衷。

5.3 模棱兩可的需求

模棱兩可是需求規格說明中最為可怕的問題。它的一層含義是指諸多讀者對需求說明產生了不同的理解；另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明。

模棱兩可的需求會使不同的風險承擔者產生不同的期望，它會使開發人員為錯誤問題而浪費時間，并且使測試者與開發者所期望的不一致。處理模棱兩可需求的一種方法是組織好負責從不同角度審查需求的隊伍。僅僅簡單瀏覽一下需求文檔是不能解決模棱兩可問題的。如果不同的評審者從不同的角度對需求說明給予解釋，但每個評審人員都真正了解需求文檔，這樣二義性就不會直到項目后期才被發現，那時再發現的話會使得更正代價很大。

5.4 過于精簡的規格說明

有時，客戶所作的規格說明過于精簡，僅涉及了產品概念上的內容，然后讓開發人員在項目進展中去完善，結果很可能出現的是開發人員先建立產品的結構之后再完成需求說明。這種方法可能適合于尖端研究性的產品或需求本身就十分靈活的情況。但在大多數情況下，這會使開發人員在不正確的前提和有限的指導下工作，也會使客戶無法得到他們所設想的產品。

[1]徐賽華.軟件需求分析研究[J].吉林師范大學學報(自然科學版)，2006-02-10.