因此，截至2009年，需求分析不應該只涉及新的需求，而且還應包括對遺留代碼進行數據挖掘，以提取隱藏的業(yè)務規(guī)則和算法。有些工具可以做到這一點，也有很多的維護工作臺可以顯示代碼，并且?guī)椭崛摬氐臉I(yè)務規(guī)則。雖然，清晰的需求是一個值得稱贊的目標，但是對于擁有10000個功能點的軟件應用來說，這個目標只能是個奢望。到目的為止，筆者只觀察到了一個小型項目，它的功能點少于500個。并且該應用的初始需求是清晰的和不變的。

對于大型應用來說，業(yè)務需求是動態(tài)的，并且不可能是一成不變的。網站制作的許多外部事件都會使軟件應用的需求發(fā)生變化，如稅法的變化、企業(yè)結構的變化、業(yè)務流程的再造以及兼并和收的等。另外，大型應用的開發(fā)一般需要幾年的時間，這使得情況變得更加復雜了。一個公司僅僅為了滿足一個軟件項目的需求而凍結其所有的業(yè)務規(guī)則，顯然是不現實的。最典型的情況是處理擁有10000個功能點應用的需求，收集和分析初始的需求將花費數個月。在隨后的設計過程中，每個月的新需求和變更需求將達到2%左右。最終的需求總量將會達到初始需求的50%。在發(fā)布了軟件應用的第一個版本之后。應該終止這些新的和變更的需求，并且在9-12個月之后，在后續(xù)的版本中添加新的需求和變更的需求。對于擁有10000個功能點的項目來說，每個月的需求變更比例稍低于0.5%，累計增量不超過原始需求10%，然而，最大的增量可以達到200%。在設計和編碼階段，每個月需求變更的平均比例在1%-3%之間，而之后的變更劇被添加到了以后的版本中了。

同時使用JAD會議、仔細的需求分析、需求審查以及原型可以使需求過程在技術和管理的控制之下。雖然有時需要數月甚至數年才能看到項目的結果，但是大型軟件項目的成敗在需求階段就已經一口了然了。成功的項目在收集和分析需求上，比失敗項目更完整、更徹底。因此，成功的項目變更很少，以及需求蔓延也很少。 然而，由于大多數新應用都是遺留應用的翻新，因此需求應該包括數據挖掘，以提取遺留應用的潛在業(yè)務規(guī)則和算法。