不重視需求過程的項目隊伍將自食其果。需求工程中的缺陷將給項目成功帶來極大風險，這里的“成功”是指推出的產(chǎn)品能以合理的價格、及時限在功能、質量上完全滿足用戶的期望。
下面將討論一些需求風險。不適當?shù)男枨筮^程所引起的一些風險
• 用戶不多導致產(chǎn)品無法被接受。
• 用戶需求的增加帶來過度的耗費和降低產(chǎn)品的質量。
• 模棱兩可的需求說明可能導致時間的浪費和返工。
• 用戶增加一些不必要的特性和開發(fā)人員畫蛇添足( g o l d - p l a t i n g )。
• 過分簡略的需求說明以致遺漏某些關鍵需求。
• 忽略某類用戶的需求將導致眾多客戶的不滿。
• 不完善的需求說明使得項目計劃和跟蹤無法準確進行。
1. 無足夠用戶參與
客戶經(jīng)常不明白為什么收集需求和確保需求質量需花費那么多功夫，開發(fā)人員可能也不重視用戶的參與。究其原因：一是因為與用戶合作不如編寫代碼有意思；二是因為開發(fā)人員覺得已經(jīng)明白用戶的需求了。在某些情況下，與實際使用產(chǎn)品的用戶直接接觸很困難，而客戶也不太明白自己的真正需求。但還是應讓具有代表性的用戶在項目早期直接參與到開發(fā)隊伍中，并一同經(jīng)歷整個開發(fā)過程。
2. 用戶需求的不斷增加
在開發(fā)中若不斷地補充需求，項目就越變越龐大以致超過其計劃及預算范圍。計劃并不總是與項目需求規(guī)模與復雜性、風險、開發(fā)生產(chǎn)率及需求變更實際情況相一致，這使得問題更難解決。實際上，問題根源在于用戶需求的改變和開發(fā)者對新需求所作的修改。要想把需求變更范圍控制到最小，必須一開始就對項目視圖、范圍、目標、約束限制和成功標準給予明確說明，并將此說明作為評價需求變更和新特性的參照框架。說明中包括了對每種變更進行變更影響因素分析的變更控制過程，有助于所有風險承擔者明白業(yè)務決策的合理性，即為何進行某些變更，相應消耗的時間、資源或特性上的折中。產(chǎn)品開發(fā)中不斷延續(xù)的變更會使其整體結構日漸紊亂，補丁代碼也使得整個程序難以理解和維護。插入補丁代碼使模塊違背強內(nèi)聚、松耦合的設計原則，特別是如果項目配置管理工作不完善的話，收回變更和刪除特性會帶來問題。如果你盡早地區(qū)別這些可能帶來變更的特性，你就能開發(fā)一個更為健壯的結構，并能更好地適應它。這樣設計階段需求變更不會直接導致補丁代碼，同時也有利于減少因變更導致質量的下降。
3. 模棱兩可的需求
模棱兩可是需求規(guī)格說明中最為可怕的問題(Lawrence 1996)。它的一層含義是指諸多讀者對需求說明產(chǎn)生了不同的理解；另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明。模棱兩可的需求會使不同的風險承擔者產(chǎn)生不同的期望，它會使開發(fā)人員為錯誤問題而浪費時間，并且使測試者與開發(fā)者所期望的不一致。一位系統(tǒng)測試人員曾告訴我，她所在的測試組經(jīng)常對需求理解有誤，以致不得不重寫許多測試用例并重做許多測試。模棱兩可的需求帶來不可避免的后果便是返工—重做一些你認為已做好的事情。返工會耗費開發(fā)總費用的4 0 %，而7 0 %～8 5 %的重做是由于需求方面的錯誤所導致的（ l e ff i n g w e l l1 9 9 7）。想像一下如果你能減少一半的返工會是怎樣的情況？你能更快地開發(fā)出產(chǎn)品，在同樣的時間內(nèi)開發(fā)更多、更好的產(chǎn)品，甚至能偶爾回家休息休息。處理模棱兩可需求的一種方法是組織好負責從不同角度審查需求的隊伍。僅僅簡單瀏覽一下需求文檔是不能解決模棱兩可問題的。如果不同的評審者從不同的角度對需求說明給予解釋，但每個評審人員都真正了解需求文檔，這樣二義性就不會直到項目后期才被發(fā)現(xiàn)，那時