風險一般指由於在從事某項特定活動過程中存在的不確定性而產生的經濟與財務損失、自然破壞或損傷的可能性。軟件工程項目中同樣充滿着風險，因此軟件工程產生了風險管理的概念。業界經驗表明，在系統生命周期的需求階段發現錯誤與在維護階段發現錯誤的費用支出比為1：200，而且需求錯誤一般是項目中所發現的最大一類，占總數的4l％-56％，為此返工所需開銷占項目總費用的45％。由此可見，需求分析階段的風險最大。
換個角度來看，需求分析階段卻又是最能提高開發效益的時機。軟件項目如果不能滿足用戶的需求，就不能算作成功，而正是在需求分析階段，用戶和開發人員雙方就需要什么樣的應用系統或軟件產品達成一致。所以，如果此時開發者運用溝通技巧與用戶交流，同時進行批判思考，並在理解業務的基礎上盡可能將需求細化量化，就能夠檢查出系統缺陷，徹底降低軟件項目的成本和失敗率。
那么，采用什么手段能夠規避需求分析中的風險?本文將從與用戶溝通、業務建模以及需求測試三個方面進行探討。
一、與用戶溝通
軟件項目的成功有賴於用戶和開發者對於需要什么樣的應用系統達成共識，所以需求分析首先是一個軟件開發者與用戶溝通交流的過程。開發人員可以通過區分用戶類型、提供候選方案，減少語言二義性，聲明需求變更成本等方法促進交流，取得實效。
如何調動用戶的積極性，使他們參與到需求調研和確保需求質量的工作中來？ 開發人員應針對不同用戶不同需求與用戶溝通。實際上，系統開發者面對的用戶總是處於機構中不同的行政和業務層次上，他們關注的“焦點”並不相同，所以在探討需求之前，有必要先進行用戶細分。
另外，由於出發點和利益不同，系統開發者與用戶對於同一問題常有不同看法，在一場場漫無目的的爭論中，需求分析的風險逐漸加大 。開發人員可以利用以往成功案例的經驗，帶着自己擬定好的多個解決方案供用戶選擇定奪，即給用戶出“選擇題”。例如，開發人員設計界面時可以先提出幾種風格的方案，用戶針對特定的對象“審美”，很快就會定下需要的方案或者指出改進的方向。
但是，即使與用戶最初的溝通很順利，開發人員也不能輕易樂觀。因為需求的變化是不可避免的，而需求的一小步變化，也許會使已經完成的工作前功盡棄，不僅造成項目無法按期完工，更使成本飛漲。在現實中需求與設計活動是迭代進行的，此時關鍵在於做好需求變更控制。其中最為重要的是，首先進行需求變更影響分析，並向用戶詳細說明這些影響、相應的成本和工作量。進行需求變更時，可以利用配置管理工具建立基線及其跟蹤表。如果出現較為復雜的需求變更，則應將其納入版本規划。對需求變更的評估包括此項需求的各種屬性描述是否恰當，時間緊迫性，技術風險性，與系統的相關性及其重要程度，需求變更的波動分析，實現需求的資源狀況等等，據此確定其對項目計划安排和其它需求的影響，同時還要明確與變更相關的任務並評估完成這些任務需要的工作量。
在項目結束后進行總結時，尤其應對需求變更跟蹤表“溫故知新”，檢視哪些需求是一以貫之的，哪些是被改變甚至放棄的，哪些是新提出並且不可或缺的，哪些是在原有基礎上深入發展的，開發者可以從中理清需求變更的脈絡，找到需求分析的“關鍵路徑”，建立起一套需求框架。這樣不僅能夠站在新的高度深入理解本項目的需求，而且也能幫助自己在以后的軟件項目中更加貼近用戶視點，達到用戶預期。例如，經過多年的信息化建設，許多單位已積累了大量的數據資源。此時，一個新啟動的軟件項目很大程度上要繼承或利用老系統的數據。在這樣的形勢下，即使需求分析初期用戶沒有提及歷史數據，開發人員也應提前考慮到保護用戶投資的問題，這樣當用戶從初期探討新系統功能轉而提出如何處理遺產系統時，開發人員就能夠拿出恰當的解決方案。
二、業務建模
從熟悉用戶業務到獲得系統需求是一個轉換的過程，在其中可以采用模式、用例、原型以及功能點分析等方法。
開發人員常常並不熟悉行業領域內的專業知識，卻又要在短期內熟悉具體業務，無疑被置於兩難的境地。為快速地深入了解實際業務，可以借助業務調查表來模擬用戶行為，其內容包括：具體業務的名稱、上級業務、下級業務、優先級、發生條件、處理的數據和詳細流程，如處理崗位、處理方式和審核細節等。在掌握業務之后，又如何從中進一步梳理出真正的需求呢?此時，開發人員要從用戶視角轉換到系統視角，將條分縷析的業務流程轉換成用戶與系統的交互。
軟件需求表述的是軟件代表用戶、設備或其他系統所做的事情。尋找軟件需求的第一個地點就是在系統的邊界上觀察“進出”系統的事物，即系統與用戶的交互。因此，最簡單的方法就是將系統看作一個黑盒，然后考慮為了完整地描述這個黑盒的功能開發人員所要做的工作，這里包括輸入、輸出，系統的性能以及系統與環境的交互。相應地，通過定義系統的輸入、輸出、功能、系統的屬性和環境的屬性即可以確定一組完整的軟件需求。
系統的輸入不僅包括輸入的內容，還包括輸入的設備、形式、外觀以及感覺等必要的細節。系統的輸出必須包括對輸出設備的描述，如語音輸出或可視化顯示等，以及系統產生信息的協議和格式。系統的功能是指將輸入映射到輸出，以及它們的不同組合。系統的屬性指一些非行為需求，如可靠性、可維護性，可獲得性以及容量等開發人員必須考慮的因素。系統環境的屬性包括附加的非行為需求，如系統在不同操作約束、負載和操作系統兼容性中運行的能力。
用戶的業務繁多，系統開發者應從何處下手?這時要根據項目目標划出明確的范圍，圍繞系統必須為用戶解決的問題，提取核心、主要、急迫的業務，明晰業務流程。在需求分析過程中，系統開發者可以借鑒一些軟件體系架構方法提煉業務需求，如層模式(Layer)、管道和過濾器模式(PipesandFilters)等，還可以借助偽代碼、有限狀態機、決策樹和決策表、UML語言的用例圖、類圖、活動圖，以及實體關系圖、數據流圖、界面原型等，從不同角度深入挖掘和細化需求。
層(Layer)模式把應用系統分解成子任務組，其中每個子任務組處於一個特定的抽象層次上。每一層為上層服務(ServiceProvider)，同時也作為下層的客戶端。如果我們將一個復雜問題分解成一個層堆棧的實現，由於每一層最多只影響兩層，同時只要給相鄰層提供接口，允許每層用不同的方法實現，這不僅為軟件重用提供了強大的支持，而且為新增和改變需求留出了充足的空間。
管道和過濾器(PipesandFilters)模式是為處理數據流的系統提供的一種模式。每個處理步驟都被封裝在一個過濾器組件中，數據通過相鄰過濾器之間的管道進行傳輸。每個過濾器可以單獨修改，功能單一，並且它們之間的順序可以進行配置。也就是除了輸入和輸出外，過濾器之間不共享任何狀態信息，不相互影響。在需求容易變動的情況下，管道和過濾器模式能夠通過替換或重新排序處理步驟來為將來的靈活性作出規划。
用例方法把系統分成參與者(actor)和用例(usecase)。參與者(actor)表示系統用戶能扮演的角色(role)。參與者可以是人，也可以是另一些相關的軟硬件系統。用例被定義成系統執行的一系列動作，動作執行的結果能被指定的參與者察覺到。用例方法可以捕獲某些用戶可見的需求，實現一個具體的用戶目標。
原型也是探索需求的有效輔助手段，它將存在於大家頭腦中的虛擬系統實實在在地表達出來，促使雙方的理解迅速向一個折衷方案靠攏。原型之后的需求溝通更為務實，由此催生出可以指導研發過程的軟件需求說明書。原型有許多種，如只實現用戶界面的水平原型，以較高的質量實現少量需求的垂直原型，目的在於建立可行性分析，用后即作廢的拋棄型，以及通過發展該原型來構建最終系統的演進型。
用戶的業務各不相同，因此應用系統功能也是各異的，但其本質都是建立行為主體、限制條件、客體對象和操作四種要素之間的關系，即行為主體在一定的限制條件下對客體對象施加某項操作。如果針對某個行業或類型的應用系統開發一些原型產品，或者針對系統中具有共性的部分開發一些組件，如權限管理、菜單和工具條生成器，以及較為通用的界面等，那么與用戶交流需求，尤其在碰到那些對具體需求缺乏明確概念的用戶時，就能夠引導用戶有的放矢，並基於原型迭代產生出真正的需求信息。即使缺乏有關的原型產品，也可以利用直觀的頁面鏈接簡明地示意出上述關系。在使用原型時，可以忽略業務處理過程，但應盡量采用真實的輸入信息並模擬真實的輸出結果，這樣有助於用戶建立感性認識，使之較易接受系統開發者提供的原型。
如果能夠找到軟件項目開發的固定程式，那將是化解風險的最佳方案。雖然沒有“銀彈”，但是人們已總結出了一些軟件過程度量的方法。例如，功能點分析(FPA)是基於軟件功能性來估算和度量應用軟件規模的方法，其重點在於枚舉可視的、用戶可識別的軟件外部性質，並通過權重將它們結合起來，形成軟件規模的復合功能度量。應該說，需求分析分段只能做功能點估算，在軟件項目結束后計算出的功能點才是最准確的，不過卻失去了對本次項目的指導意義。但是，開發人員有必要在項目總結時認真地進行功能點計算，這些數據累積起來就會形成寶貴的經驗，使得新項目的功能點估算愈加准確。
功能點分析方法將應用系統的功能分為數據處理和事務處理。內部邏輯文件(ILF)和外部接口文件(EIF)是數據處理功能的兩種類型。ILF是存儲在系統內並由系統維護的一級信息。EIF是系統和外部應用程序共享的惟一文件。事務處理包括外部輸入(EI)、外部輸出(EO)和外部查詢(EQ)。EI是更新系統內數據的事務。EO是通過邊界離開系統的單一數據或控制輸出。EQ是數據的檢索。每個功能的功能點因其功能類型(ILF、EIF、EI、EO或EQ)和復雜度(簡單、一般、復雜)的不同而不同。每個功能類型按照一定的規則來確定其復雜度。找出的所有功能定為未調整功能點，以計算總的未調整功能點。然后依據需求規格說明書中定義的非功能需求和設計限制因素形成值調整因子(VAF)。VAD乘以未調整功能點便得到功能點數。
執行FPA的每一個步驟都有發現需求缺陷的能力。例如，標識計算功能點數的范圍和應用程序的界限，可能發現系統中對應該包括的功能和不應該包括的功能的誤解。計算數據和事務功能類型能幫助標識出遺漏的需求，如可能發現報告(外部輸出)里面沒有數據源(內部邏輯文件丟失)；還可能發現系統有能力向邏輯數據組增加數據(外部輸入)，但沒有瀏覽數據(外部查詢)或者刪除數據的能力(遺漏了外部輸出)。這種對外部數據(外部接口文件)的標識有可能顯示出外部接口的要求被完全忽略了。另外，對一般系統特點的分析可能提示出以前沒有標識出的設計限制。
三、需求測試
應該從什么時候開始測試軟件項目?有人認為是編碼階段，即編碼的同時進行單元測試，編碼完成后進行系統測試。實際上在現代軟件過程中，測試從需求分析階段就開始了，需求分析是測試計划的輸入和參照，更為重要的是，開發人員可以利用需求測試作為規避需求風險的有效方法。開發人員應時刻警醒：只有當軟件項目的所有需求都可以被測試時，才能夠保證應用系統始終圍繞着用戶的需要，保證軟件過程的成功。
那么，到底什么樣的需求才是可測試的？如果用戶給出這樣一段描述：“我們要用新的系統完成報表自動化處理”，開發人員就要繼續追問報表包括哪些，自動化處理的標准是什么?如果不說明這些細節，那么所做的需求描述就是不可測試的，其含混之處將形成開發過程中的重重陷阱。實際上，描述需求可以稱為“解剖”需求，即將大的任務划分成若干需求，再將每一需求解構成原子粒度的測試項，即給出輸入、處理、輸出的量化指標，包括格式、數據量、容錯性、接口、速度等等。在需求規格說明書中應注意不要出現那些不能被檢驗的詞匯，如“充分或足夠”，而應代之以數量或其他方式的度量。例如，“A應該是用戶友好的”就是不可測試的，將其轉換為可測試的需求描述則為：A應該提供說明控件用途的標簽，字母大小應為0．75~0．05厘米；A的控件位置應該按照使用順序排列(從左到右)；A應該顯示控件選項菜單；A應該顯示用戶下一步動作的提示；A應該使用產品PQR的顯示約定；A應用紅色顯示緊急停止控件。
在進行需求測試時，首先，應從語義和語法上檢查需求文檔的正確性，然后針對系統的輸入、輸出、功能、系統的屬性和環境的屬性，根據已經建立起的一些規則進行同行評審、走查，還可以在某些環節上結合等價類划分、邊界值分析、因果圖、邏輯覆蓋等黑盒與白盒方法設計測試用例，再次驗證相應的需求描述是否“達標”，找出需求規格說明書中遺漏、過度、錯誤、重復，模糊甚至矛盾的內容。
對需求文檔的檢查包括確認定義的所有概念和實現方法是否清楚地表達了用戶的原要求，對功能的描述是否背離其實際要求，是否有不能理解或造成誤解的描述；是否對每一個需求都給出了充分的理由；各個需求之間是否一致，需求定義是否參照了有關標准，算法和規則是否有文獻依據，是否兼容，能否在相應的限制條件下實現；是否對所有的圖形、表格都進行了標號，是否采用了索引和交叉引用表等保證對需求定義的描述易於修改；一項需求是否被定義了多次；是否有需求可以被定義的更細致或更簡單；語言是否無歧義；是否對每一個需求都指定了驗證過程。
對於系統的輸入和輸出，應檢查是否定義了系統的所有輸入並標識清楚了系統輸入的來源，是否標識出了系統的輸出並說明了系統輸入/輸出的類型，以用系統輸入/輸出的值域、單位、精度、格式等，是否說明了如何進行系統輸入的合法性檢查；是否充分定義了關於人機界面的需求。
在功能方面，應檢查需求規格說明書是否清楚明確地描述了所有的功能；所有已描述的功能是否是必須的，是否能滿足系統目標；是否包含了覆蓋了各種操作模式(如正常、非正常、有干擾等)下的情況處理；是否為每個需求指定了軟件失效的結果、特定的失效保護信息、特定的錯誤檢測策略以及錯誤糾正策略；是否標識出了所有與時間因素有關的功能，並說明它們的時間准則，是否定義了最大、最小執行時間；是否清楚地定義了所有的外部/內部接口，所有接口是否必須，各接口間的關系是否一致、正確；所有對其他需求的內部交叉引用是否正確。
對於系統的屬性，應檢查需求規格說明書中是否詳細描述了有關硬件、軟件、操作人員、操作過程等方面的安全性；是否按完成時間、重要性對系統功能、外部接口、性能進行了優先排序；是否包含了所有與需求相關的安裝特性和維護特性；模塊或子程序(過程)間的關系是否是松耦合的；是否精確地描述了所有的性能要求及最低的性能指標；是否指定了處理時間、數據傳輸速率和系統容量。
對於系統環境，應檢查需求規格說明書中是否包含了所有與需求相關的軟硬件環境及兼容性；是否指定了最大/最小內存、最大/最小存儲空間；是否規定了系統在不同負載狀態下的效率；是否說明了本項目對用戶、其他系統及環境的相互影響。
四、結論
綜上所述可以看出，開發人員是能夠在與用戶溝通、業務建模、需求測試三個方面采取有效措施規避需求風險的，這些措施的核心是保證用戶認可開發者所定義的需求，同時保證開發人員正確地理解需求。