由于開發人員沒有參與過上一個版本的開發工作，他們對于舊系統并不了解．雖然在閱讀了以前的需求文檔以及使用了軟件之后，大概對系統的功能有了一個初步的認識．但是對于系統中出現的各種邏輯關系并沒有深入了解下去．作為項目經理，在這項工作中，失誤之處在于任務的結果（即輸出）沒有事先定義清楚，從而也就導致無法確認目標是否已經達到，再加上需求文檔描述的也不是十分清晰．最后，只是在開發人員覺得已經理解該系統的基本上，進行了下一步的工作．沒有進行進一步的確認工作，不知道組員進行舊系統已經了解到了什么樣的程度。這個問題的結果，就是直接導致了后期的開發過程中，由于對于原先系統的邏輯關系不是很清楚。對于舊代碼理解和新代碼編寫進行地不是很順利。
B. 對新需求的分析不夠
這還是個老問題，但又不是一個問題．說它是個老問題，因為分析需求要求考慮細致全面，并且能引導客戶，啟發客戶提供更有價值的信息。事實上，需求分析我們做的算是很盡力了，同時客戶把需求一條條的列出來給我們，相對來說需求已經很清楚了。我們在接到這些需求后，不僅研究了新功能，還把他們對于舊系統的影響都做了分析。但還是有些問題沒有能在需求文檔中反映出來，后面的影響也是可想而知的了。我以前的文章中才曾提到過相關的問題，在這里就不再重復了。不過，從另一個角度來看，它又不是一個問題。為什么這么說呢，因為需求實在不是能夠在分析階段就能完全理解透徹的，甚至有的需求客戶也模模糊糊，直到交付以后才提出了改動的要求。軟件開發經過這么多年的發展，大家已經認識到了一點：需求是變化的。要達到能夠擁抱變化的要求，我們要對開發方法進行改進，相關的問題我在后面也會提到。
需求分析階段出現的問題，解決的可操作性不是很大，更多的是從思想或經驗上解決，而后面幾個階段出現的問題都相對具體一些。
2、設計階段
設計階段的問題相對比較明顯――結構設計不合理，或者說還不夠。一個傳統的Ｃ／Ｓ結構的系統，基本結構我們采用了經典的三層模型來劃分系統。由于是在舊有系統上的改進，我們在盡量不改變原有系統的基礎上添加新的功能。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
