總體上說，我們的需求分析是做了，但是做得很不夠，我們做的需求只解決了我們能做出這樣的項目，但是沒有解決這樣的項目是不是真就是客戶想要的。造成這種狀況的原因主要是下面幾個情況：
客戶本身說不清楚
文物網是這樣，中彰國際更是這樣，但是這不能怪客戶，畢竟客戶在軟件方面的知識要少的多，也沒有相關的經驗，可能心里只有一個想要的軟件的輪廓，于是可能會要求我們去替他們來完整這個輪廓的細節，而我們的能力、我們能否真正站在客戶角度去搜集和整理這些需求，就決定了這個需求的完整性和有效性。
需求自身經常變動
隨著客戶對這個項目越來越深刻的理解，那么可能他的需求也會隨之改變，這些變化的可能性越大項目風險就會越大，我們在需求分析的時候就要充分考慮到哪些需求是相對固定的需求，哪些可能會是產生變動的需求，考慮到他的可變性，這樣設計功能和數據庫的時候不致因為后面的變動而影響整個工程。
分析人員或客戶理解有誤
畢竟，不是每個分析人員都是專業而合格的，為避免這種情況的發生，需求分析必須要有審核制度，公司自己內部要審核一遍，客戶再審一遍，提出意見，修改后雙方共同評審簽字，確認。
由此出現的問題：
a） 需求分析過于籠統，只關注到面上，沒有關注到點上，開發出來的東西在具體的細節上和客戶的理解有誤差，并且無法嚴格界定是否屬于需求變更。中彰的方案就是這樣的。
b） 需求報告只求我們這方評審通過，不去關心客戶的評審，認為只要客戶簽字認可就行。雖然簽字認可能夠給日后出現問題時劃清我們的責任，但是不能保證使項目實施成功。
c） 需求分析中含有技術實施上有難度的功能，一味的求全和盲目按照客戶的設想，受客戶影響過大，畢竟，很多時候，客戶的想法在實際實施過程中是不現實的，或者可以有更為簡便的方法來替代的。如中彰國際的在線交易功能，后臺大批量郵件群發功能。
d）對雙方已經確定的需求，實現以后并不適合客戶使用，需要按照變更手續執行的時候，客戶可能會糾纏，提出“你們是專業人士，你們應該事先能提醒我們可能會出現這種問題”并以此來把責任推給我們，而我們又不好完全按照變更手續執行，因為可能激化雙方的矛盾，比如508的批量處理功能，因為屬于人事管理比較專業的細節問題，需求分析師開始沒有對客戶業務熟悉到如此細致的地步，而客戶也沒有過多關注這些細節，導致軟件的某些功能不合用，較為繁瑣，而重新按著客戶的意見修改的話工作量比較大，導致成本增加、工期延長。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
