傳統需求分析一般以名為“需求規格說明書”（Requirement Specification）的文檔為目標，以固定時長（根據項目規模而定，一般2、3周或者更長）為約束，以完成需求文檔為結束。 那么傳統需求分析究竟面臨那些困境呢？中培偉業《需求分析于管理最佳實踐》培訓專家王老師在這里進行了介紹。

王老師指出，經歷過傳統需求分析過程的分析師和開發人員都會有類似的感覺：

l 無論用多長時間來分析需求，總感覺需求沒有完備

l 無論如何研討，已有的需求總感覺不能百分之百明確

l 至項目開發后期，業務部門和技術部門往往就需求產生糾紛，一般有兩種形式：

1. 技術部門認為頻繁的需求變更不但增加項目壓力，更使已有開發工作浪費

2. 業務部門認為軟件系統不能跟進，影響業務發展

王老師指出，造成上述傳統需求分析方法困境的原因主要有兩點：

l 在項目進行的過程中，業務需求本身也在發展變化，從而引發軟件需求變化。

l 業務人員不可能憑空把所有需求都想清楚，只有看到、用到真實的軟件之后，才能逐漸把自己的需求弄清楚。

雖然一次性需求存在諸多問題，但現實中，技術部門和業務部門往往都希望能在這個階段將所有問題想清楚。促使團隊這樣做的深層原因在于：

l 從管理的角度考慮，軟件項目需要申請預算

l 從軟件開發的角度考慮，需求的每一次變更都需要長的時間和巨大的成本來應對，這是技術部門和業務部門雙方都不愿看到的。為了避免項目中進行可能的風險，雙方都寧可在項目初期盡量把需求凍結。

第一個原因與項目計劃方式有關；第二個原因與其說是對策，不如說是對傳統開發方法缺陷的妥協：對企業級應用系統來說，早期需求凍結不僅是無法做到，而且還會帶來一項隱性的浪費——這種項目開發出來后，可能有20~30%的功能從上線開始，已經不再需要；10~20%的功能的生命周期不超過半年，即費用和人力有相當一部分投入到無用的功能開發中。  

業務部門和開發團隊依賴文檔進行溝通的后果往往是理解出現偏差，開發出的系統的不能滿足業務部門的真正需求，造成浪費。