因此，截至2009年，需求分析不應該只涉及新的需求，而且還應包括對遺留代碼進行數據挖掘，以提取隱藏的業務規則和算法。有些工具可以做到這一點，也有很多的維護工作臺可以顯示代碼，并且幫助提取潛藏的業務規則。雖然，清晰的需求是一個值得稱贊的目標，但是對于擁有10000個功能點的軟件應用來說，這個目標只能是個奢望。到目的為止，筆者只觀察到了一個小型項目，它的功能點少于500個。并且該應用的初始需求是清晰的和不變的。
對于大型應用來說，業務需求是動態的，并且不可能是一成不變的。網站制作的許多外部事件都會使軟件應用的需求發生變化，如稅法的變化、企業結構的變化、業務流程的再造以及兼并和收的等。另外，大型應用的開發一般需要幾年的時間，這使得情況變得更加復雜了。一個公司僅僅為了滿足一個軟件項目的需求而凍結其所有的業務規則，顯然是不現實的。最典型的情況是處理擁有10000個功能點應用的需求，收集和分析初始的需求將花費數個月。在隨后的設計過程中，每個月的新需求和變更需求將達到2%左右。最終的需求總量將會達到初始需求的50%。在發布了軟件應用的第一個版本之后。應該終止這些新的和變更的需求，并且在9-12個月之后，在后續的版本中添加新的需求和變更的需求。對于擁有10000個功能點的項目來說，每個月的需求變更比例稍低于0.5%，累計增量不超過原始需求10%，然而，最大的增量可以達到200%。在設計和編碼階段，每個月需求變更的平均比例在1%-3%之間，而之后的變更劇被添加到了以后的版本中了。
同時使用JAD會議、仔細的需求分析、需求審查以及原型可以使需求過程在技術和管理的控制之下。雖然有時需要數月甚至數年才能看到項目的結果，但是大型軟件項目的成敗在需求階段就已經一口了然了。成功的項目在收集和分析需求上，比失敗項目更完整、更徹底。因此，成功的項目變更很少，以及需求蔓延也很少。 然而，由于大多數新應用都是遺留應用的翻新，因此需求應該包括數據挖掘，以提取遺留應用的潛在業務規則和算法。