需求分析是專案開發的基礎，基礎打的牢不牢直接關係到後面所有的工作，是專案實施成敗的關鍵
總體上說，我們的需求分析是做了，但是做得很不夠，我們做的需求只解決了我們能做出這樣的專案，但是沒有解決這樣的專案是不是真就是客戶想要的。造成這種狀況的原因主要是下面幾個情況：
客戶本身說不清楚
文物網是這樣，中彰國際更是這樣，但是這不能怪客戶，畢竟客戶在軟體方面的知識要少的多，也沒有相關的經驗，可能心裡只有乙個想要的軟體的輪廓，於是可能會要求我們去替他們來完整這個輪廓的細節，而我們的能力、我們能否真正站在客戶角度去蒐集和整理這些需求，就決定了這個需求的完整性和有效性。
軟體開發網
需求自身經常變動
隨著客戶對這個專案越來越深刻的理解，那麼可能他的需求也會隨之改變，這些變化的可能性越大專案風險就會越大，我們在需求分析的時候就要充分考慮到哪些需求是相對固定的需求，哪些可能會是產生變動的需求，考慮到他的可變性，這樣設計功能和資料庫的時候不致因為後面的變動而影響整個工程。
分析人員或客戶理解有誤
畢竟，不是每個分析人員都是專業而合格的，為避免這種情況的發生，需求分析必須要有審核制度，公司自己內部要審核一遍，客戶再審一遍，提出意見，修改後雙方共同評審簽字，確認。
由此出現的問題：
a) 需求分析過於籠統，只關注到面上，沒有關注到點上，開發出來的東西在具體的細節上和客戶的理解有誤差，並且無法嚴格界定是否屬於需求變更。中彰的方案就是這樣的。 軟體開發網
b) 需求報告只求我們這方評審通過，不去關心客戶的評審，認為只要客戶簽字認可就行。雖然簽字認可能夠給日後出現問題時劃清我們的責任，但是不能保證使專案實施成功。
d) 對雙方已經確定的需求，實現以後並不適合客戶使用，需要按照變更手續執行的時候，客戶可能會糾纏，提出「你們是專業人士，你們應該事先能提醒我們可能會出現這種問題」並以此來把責任推給我們，而我們又不好完全按照變更手續執行，因為可能激化雙方的矛盾，比如508的批量處理功能，因為屬於人事管理比較專業的細節問題，需求分析師開始沒有對客戶業務熟悉到如此細緻的地步，而客戶也沒有過多關注這些細節，導致軟體的某些功能不合用，較為繁瑣，而重新按著客戶的意見修改的話工作量比較大，導致成本增加、工期延長。
e) 專案的成熟度受客戶預算的限制。大部分客戶在專案投入上都是有預算的，在成本有上限的前提下，專案的功能設計(軟體的成熟度)方面必然受一定影響，畢竟功能越多越完善，相應的開發成本就越高。這種功能上的不完善需要事先告知客戶並得到理解。
f) 此項工作的反覆造成思想上的倦怠，使需求分析最後虎頭蛇尾。需求分析是一項繁瑣枯燥的工作，需要和客戶之間不斷的商討、確認和反覆，另外由於大部分的客戶雖然安排專人負責這項工作，但是該人並不只做這項工作，特別當他被很多其他的事情纏身的時候，而無心細看提交過去的需求報告的時候，他很可能會給你乙個錯覺，讓你認為他已經真正的理解並認可了你的設計。
結論 a) 需求分析是整個專案管理中需要重點控制的幾個關鍵節點之一，首先思想上一定要重視。 軟體開發網
b) 需求分析報告的編寫者要參與到需求的蒐集工作中，準確領會客戶的意圖，並轉化成軟體能夠實現的功能。對於說不清楚需求的客戶，要善於問關鍵問題，引導客戶提出自己的需求。可以採取的措施是事先編制乙個問卷調查之類的文件，詳細列舉需要客戶回答的問題，以便防止遺漏。
軟體專案的需求分析
需求分析 在具體的研究需求分析之前，我們先了解一下軟體工程這個概念。軟體工程分為三個層次，過程層 方法層 工具層。在最基礎的過程層，最重要的就是一組被稱為關鍵過程區域 kpas 的框架 kpa的概念在討論cmm的書中有詳細的概念說明 關鍵過程區域構成了軟體專案的管理控制的基礎，並且確立了上下文各區域...
軟體需求分析方法總結
align center 撰寫優秀的需求 by karl wiegers.bear縮譯 軟體需求常常被寫得很糟且難於遵循。清楚地闡明你的需求將使每位專案參與者獲益。需求說明總的特點 1 它們必須是正確的。2 它們必須是可行的 3 它們必須是對專案來說是必不可少的。4 它們必須是被標明優先次序的。5 ...
軟體專案需求調研總結
一 需求調研準備 在需求調研過程中，應該做好三種準備，保持兩種心態，做到五種提高 三種準備 1 調研前應該將所有專案前期資料進行彙總，與相關的前期銷售人員進行交流，以便對專案有乙個基本輪廓的認識。2 做好調研前使用資料的準備，如需求調研模板，需求調研問題列表等。3 做好不怕一切困難的準備。兩種心態 ...