一、軟件需求的目的：

1.準確的理解和描述客戶需要的功能

客戶只知道他不滿意，但怎樣才能使他滿意呢？他不知道，於是就在一點兒一點兒試，於是這種反復變更就這樣發生了。

如果我們明白了這一點，深入地去理解客戶的業務，進而想到客戶的心坎兒上去，最後做出來的東西必然是客戶滿意的。記住，當客戶提出業務變更的時候，我們一定不能被客戶牽著走，客戶說啥就是啥。業務場景是需求之魂，我們要從業務角度深入的去分析，他為什麽提出變更，提得合不合理，我有沒有更合理的方案滿足這個需求。當我們提出更加合理的方案時，客戶是樂於接受的，變更也變得可控了。

2.幫助客戶挖掘需求

他們的需求與我們的需求之間有一些距離，我們的需求僅僅是對方能滿足和達成的一部分，對方有更多的目標和願望需要我們去挖掘和助其達成，而那些潛在需求得到滿足時，這種顯性需求自然而然便被解決。且在挖掘用戶需求時，變陳述句為疑問句是比較關鍵的方法，通過提問，獲得用戶究竟

3.分析客戶需求的可行性：

需求分析的本質在於業務分析，而非技術分析。但我們作為技術人員，需求分析必須實事求是的、基於技術可以實現的角度去考慮。那種“有條件要上，沒有條件創造條件也要上”的魯莽行事，結果必然是悲慘的。所以我們必須要基於技術實現去引導客戶的需求。我們做需求就應當首先理解現有的管理模式，然後站在信息化管理的角度去審視他們的管理模式是否合理，最後一步一步地去引導他們按照更加合理的方式去操作與管理。

需求分析不是一蹴而就的，它應當貫穿整個開發周期，不斷的分析確認的過程。敏捷開發倡導需求反饋。敏捷開發認為，需求分析階段不可能解決所有的需求問題，因此在設計、開發、測試，直到最終交付客戶，這整個過程都應當不停地用開發的成果與客戶交流，及時獲得反饋。只有這樣才能及時糾正需求理解的偏差，保證項目的成功。

二、需求分析分為三個階段

1.需求提出（應當怎樣做需求分析）

主要集中於描述系統目的。需求提出和分析僅僅集中在使用者對系統的觀點上。開發人員和用戶確定一個問題領域，並定義一個描述該問題的系統。這樣的定義稱作系統規格說明，並且它在用戶和開發人員之間充當合同。

需求調研是需求分析最重要的一環，也最集中地體現了需求分析的特點——既是一份體力活兒，更是一份技術活兒。它既要求我們具有一種理解能力、設計能力，更要求我們具有一種與人交往、溝通的能力。

他們為什麽要提出這項需求，提這項需求的目的是什麽？只有經過這樣的分析，我們才能深刻地理解需求，進而運用我們的專業知識，提出更加合理的技術方案。但非常遺憾，我們在需求分析中常常不是這樣做的，甚至當軟件都開發出來了，需求分析人員都說不出客戶為什麽要提出這個需求，更談不上了解業務操作流程。一句經典的話是：

需求捕獲->需求整理->需求驗證->再需求捕獲??????

2.需求描述（需要的設計和文檔）

在問題分析階段分析人員的主要任務是：對用戶的需求進行鑒別、綜合和建模，清除用戶需求的模糊性、歧義性和不一致性，分析系統的數據要求，為原始問題及目標軟件建立邏輯模型。分析人員要將對原始問題的理解與軟件開發經驗結合起來，以便發現哪些要求是由於用戶的片面性或短期行為所導致的不合理要求，哪些是用戶尚未提出但具有真正價值的潛在需求。

采用原文分析法，是在用例說明與流程分析的基礎上進行的業務領域分析，是一項在需求研討會後整理和分析需求的工作。

領域驅動設計，建立模型，需求列表

3.需求評審（應當怎樣做需求確認）

在需求評審階段，分析人員要在用戶和軟件設計人員的配合下對自己生成的需求規格說明和初步的用戶手冊進行復核，以確保軟件需求的完整、準確、清晰、具體，並使用戶和軟件設計人員對需求規格說明和初步的用戶手冊的理解達成一致。一旦發現遺漏或模糊點，必須盡快更正，再行檢查。

理想與現實總是有差距，我們之所以要編寫自己的需求規格說明書，就是要本著實事求是、切實可行的態度，去描述用戶的業務需求。那些不可行的需求被摒棄，或者換成更加可行的解決方案。這就是需求規格說明書的重要作用。

我們說這種需求分析工作不可能完全完成，或者說日後用戶的需求會變，其實並不是毫無規律可循的。通常，用戶對需求的變更只發生在某些固定的範圍內，弄清楚了這些範圍，我們的問題就迎刃而解了。

需求評審會的主要目的就是確認需求，以便以此開始我們的設計開發工作。

參考博文：http://blog.csdn.net/yqmfly/article/details/7679781

關於《軟件需求分析》需要掌握哪些必要的內容的總結與思考