2. 用戶需求的不斷增加
在開發中若不斷地補充需求，項目就越變越龐大以致超過其計劃及預算范圍。計劃并不總是與項目需求規模與復雜性、風險、開發生產率及需求變更實際情況相一致，這使得問題更難解決。實際上，問題根源在于用戶需求的改變和開發者對新需求所作的修改。
要想把需求變更范圍控制到最小，必須一開始就對項目視圖、范圍、目標、約束限制和成功標準給予明確說明，并將此說明作為評價需求變更和新特性的參照框架。說明中包括了對每種變更進行變更影響因素分析的變更控制過程，有助于所有風險承擔者明白業務決策的合理性，即為何進行某些變更，相應消耗的時間、資源或特性上的折中。
產品開發中不斷延續的變更會使其整體結構日漸紊亂，補丁代碼也使得整個程序難以理解和維護。插入補丁代碼使模塊違背強內聚、松耦合的設計原則，特別是如果項目配置管理工作不完善的話，收回變更和刪除特性會帶來問題。如果你盡早地區別這些可能帶來變更的特性，你就能開發一個更為健壯的結構，并能更好地適應它。這樣設計階段需求變更不會直接導致補丁代碼，同時也有利于減少因變更導致質量的下降。
3. 模棱兩可的需求
模棱兩可是需求規格說明中最為可怕的問題。它的一層含義是指諸多讀者對需求說明產生了不同的理解；另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明。
模棱兩可的需求會使不同的風險承擔者產生不同的期望，它會使開發人員為錯誤問題而浪費時間，并且使測試者與開發者所期望的不一致。一位系統測試人員曾告訴我，她所在的測試組經常對需求理解有誤，以致不得不重寫許多測試用例并重做許多測試。
處理模棱兩可需求的一種方法是組織好負責從不同角度審查需求的隊伍。僅僅簡單瀏覽一下需求文檔是不能解決模棱兩可問題的。如果不同的評審者從不同的角度對需求說明給予解釋，但每個評審人員都真正了解需求文檔，這樣二義性就不會直到項目后期才被發現，那時再發現的話會使得更正代價很大。
4. 不必要的特性
“畫蛇添足”是指開發人員力圖增加一些“用戶欣賞”但需求規格說明中并未涉及的新功能。經常發生的情況是用戶并不認為這些功能性很有用，以致在其上耗費的努力“白搭”了。開發人員應當為客戶構思方案并為他們提供一些具有創新意識的思路，具體提供哪些功能要在客戶所需與開發人員在允許時限內的技術可行性之間求得平衡，開發人員應努力使功能簡單易用，而不要未經客戶同意，擅自脫離客戶要求，自作主張。
同樣，客戶有時也可能要求一些看上去很“酷”，但缺乏實用價值的功能，而實現這些功能只能徒耗時間和成本。為了將“畫蛇添足”的危害盡量減小，應確信：你明白為什么要包括這些功能，以及這些功能的“來龍去脈”，這樣使得需求分析過程始終是注重那些能使用戶完成他們業務任務的核心功能。
5. 過于精簡的規格說明
有時，客戶并不明白需求分析有如此重要，于是只作一份簡略之至的規格說明，僅涉及了產品概念上的內容，然后讓開發人員在項目進展中去完善，結果很可能出現的是開發人員先建立產品的結構之后再完成需求說明。這種方法可能適合于尖端研究性的產品或需求本身就十分靈活的情況。但在大多數情況下，這會給開發人員帶來挫折（使他們在不正確的假設前提和極其有限的指導下工作），也會給客戶帶來煩惱（他們無法得到他們所設想的產品）。
