系統(tǒng)帶來極大損害的部分，并且以后再對它進行修改也極為困難。
為什么這么說呢，因為在大多數(shù)的軟件系統(tǒng)中，最終用戶可能都不清楚他的需求是什么，這是千真萬確的。如果你的用戶告訴你需求就是這些了，不要相信他，繼續(xù)刨根問底，直到你們都筋疲力盡了。
雖然聽上去有些不可思議，但這是教訓之談，在我從事的項目之中，沒有一個用戶在軟件接近完成的時候打電話對我說，我看了你們的軟件，我想我必須改動一些地方。在那些日子中，我甚至得了一種電話鈴音恐懼癥。
需求風險
下面列出了在做需求分析時一些很危險的做法，如果你發(fā)現(xiàn)你的一些做法與之相似，那么，給自己一些時間，好好思考一下，這些做法會對你的軟件產(chǎn)生致命的影響。
1. 無足夠用戶參與
客戶經(jīng)常不明白為什么收集需求和確保需求質(zhì)量需花費那么多功夫，開發(fā)人員可能也不重視用戶的參與。究其原因：一是因為與用戶合作不如編寫代碼有意思；二是因為開發(fā)人員覺得已經(jīng)明白用戶的需求了。在某些情況下，與實際使用產(chǎn)品的用戶直接接觸很困難，而客戶也不太明白自己的真正需求。但還是應讓具有代表性的用戶在項目早期直接參與到開發(fā)隊伍中，并一同經(jīng)歷整個開發(fā)過程。
最重要的就是用戶必須要重視他的軟件，必須讓他明白：如果失敗，他的損失最大(當然你的損失也不小，但這時候你必須讓他重視這項工作)。如果用戶不夠重視，想辦法解決，否則你就不用再繼續(xù)了。
2. 用戶需求的不斷增加
在開發(fā)中若不斷地補充需求，項目就越變越龐大以致超過其計劃及預算范圍。這使得問題更難解決。實際上，問題根源在于用戶需求的改變和開發(fā)者對新需求所作的修改。要想把需求變更范圍控制到最小，必須一開始就對項目視圖、范圍、目標、約束限制和成功標準給予明確說明，并將此說明作為評價需求變更和新特性的參照框架。說明中包括了對每種變更進行變更影響因素分析的變更控制過程，有助于所有風險承擔者明白業(yè)務決策的合理性，即為何進行某些變更，相應消耗的時間、資源或特性上的折中。
產(chǎn)品開發(fā)中不斷延續(xù)的變更會使其整體結(jié)構(gòu)日漸紊亂，補丁代碼也使得整個程序難以理解和維護。插入補丁代碼使模塊違背強內(nèi)聚、松耦合的設計原則，特別是如果項目配置管理工作不完善的話，收回變更和刪除特性會帶來問題。如果你盡早地區(qū)別這些可能帶來變更的特性，你就能開發(fā)一個更為健壯的結(jié)構(gòu)，并能更好地適應它。這樣設計階段需求變更不會直接導致補丁代碼，同時也有利于減少因變更導致質(zhì)量的下降。
最糟糕的莫過于用戶覺得如果不再加點什么功能就對不起自己。我曾經(jīng)看過一個數(shù)據(jù)倉庫的一期工程，在設計階段沒有很好的定義范圍，當我向項目管理者提出這個問題的時候，他認為都已經(jīng)說好了，合同上也寫清楚了，并沒有加以重視?？墒亲詈?，用戶提出的修改意見已經(jīng)遠遠超出了范圍，項目時間也延長了一倍。整個的項目組成員疲憊不堪，可是卻不斷的接到用戶投訴說項目失敗。