怎麼樣進行需求分析?

General 更新 2024-11-21

從哪些方面如何具體做好需求分析

1. 訪問並與有潛力的用戶探討

為找出新軟件產品的用戶需求，最直截了當的方法是詢問他們。本章討論如何尋找合適的用戶代表，而在第8章講述從這些代表中獲取需求的技巧。

2. 把對目前的或競爭產品的描述寫成文檔

文檔可以描述一種所必須遵循的標準或產品所必須遵循的政府或工業規則。

3. 系統需求規格說明

一個包含軟、硬件的產品需要一個高檔次的系統需求規格說明以介紹整個產品。系統需求的子集被分配到每個軟件子系統中（ Nelsen 1990）。附加的詳細軟件功能需求將從有關軟件的系統需求裡獲得。

4. 對當前系統的問題報告和增強要求

指導用戶和提供技術支持的工作人員是最有價值的需求來源。他們收集了用戶在使用現有系統過程中所遇到問題的信息，還接受了用戶關於系統改進的想法。

5. 市場調查和用戶問卷調查

調查有助於從廣大有潛力的用戶那裡獲得大量定量的數據，務必調查相關的用戶並詢問一些能產生反響的好問題。

6. 觀察正在工作的用戶

對當前系統的用戶和將來系統的有潛力的用戶，分析員觀察“日常工作”以獲得經驗，這些經驗能提供很有價值的信息。分析員可通過觀察用戶與所關聯的任務環境的工作流程來預見用戶在使用當前系統時所遇到的問題，並能分析新的系統可有效支持工作流程的方面（McGraw and Harbison 1997; Beyer and Holtzblatt 1998）。比起僅僅簡單地詢問用戶，並記下用戶在處理任務時的步驟來說，直接觀察用戶的工作流程可以對他們的活動有更正確的理解。分析員必須抽象和總結用戶的直接活動，以確保所獲得的需求具有普遍性，而不僅僅代表單個用戶。一個富有技巧的分析員還可以為改進用戶的當前事務處理過程提出一些見解。

7. 用戶任務的內容分析

通常通過開發具體的情節（ s c e n a r i o）或活動順序（有時稱作“情節”），可以確定用戶利用系統需要完成的任務，分析員由此可以獲得用戶用於處理任務的必要的功能需求。

如何進行需求分析

項目需求分析是一個項目的開端，也是項目建設的基石。在以往建設失敗的項目中，80％是由於需求分析的不明確而造成的。因此一個項目成功的關鍵因素之一，就是對需求分析的把握程度。在原則上，需求階段監理應尊重承建方的項目管理和項目分析能力；在具體的任務開展上，以不深入、不干擾承建方的自主權為主，除非在項目合作過程中發現承建方的項目管理以及項目分析能力存在很大的差距和不足。為了保證項目的成功，監理方必須加強項目管理和項目分析工作，在具體的操作上可以堅持吸收、同化、貫徹的方法和手段。其中，需求分析是一個項目的開端，也是項目建設的基石。在以往建設失敗的項目中，80％是由於需求分析的不明確而造成的。因此一個項目成功的關鍵因素之一，就是對需求分析的把握程度。而項目的整體風險往往表現在需求分析不明確、業務流程不合理，用戶不習慣或不願意去用承建方的軟件。作為第三方的監理公司，必須提醒承建方、客戶方重視需求分析的重要性，採用必要的手段和方法來進行需求調研，同時監理方也應深入具體的需求調研中去。只有這樣才能切切實實地把握用戶的需求和方向，才能在將來的功能界定、開發範圍上有發言權。需求分析不象偵探推理那樣需從蛛絲馬跡著手，而是應該先了解宏觀的問題，再瞭解細節的問題。一個應用軟件系統（記為S）的涉及面可能很廣，可以按不同的問題域（記為D）分類，每個問題域對應於一個軟件子系統。 S={D1，D2，D3，…Dn} 問題域Di由若干個問題（記為P）組成，每個問題對應於子系統中的一個軟構件。 Di={P1，P2，P3，…Pm} 問題Pj有若干個行為（或功能，記為F），每個行為對應於軟構件中的實現接口。 Pj={F1，F2，F3，…Fk} 需求說明書應該對於那些只想瞭解宏觀需求的領導，和需要了解細節的技術員都合適。在寫需求說明書時應該注意兩個問題： 1.最好為每個需求註釋“為什麼”，這樣可讓程序員瞭解需求的本質，以便選用最合適的技術來實現此需求。 2.需求說明不可有二義性，更不能前後相矛盾。如果有二義性或前後相矛盾，則要重新分析此需求。重點監控需求分析由於項目的特殊性和行業覆蓋的廣闊性，以及需求分析的高風險性，軟件需求分析的重要性是不言而喻的，同時需求分析又的的確確難做。其原因基本是由於以下情況造成的。客戶說不清楚需求有些客戶對需求只有朦朧的感覺，當然說不清楚具體的需求。例如全國各地的很多部門、機構、單位在進行應用系統以及網絡建設時，客戶方的辦公人員大多不清楚計算機網絡有什麼用，更缺乏IT系統建設方面的專家和知識。此時，用戶就會要求軟件系統分析人員替他們設想需求。工程的需求存在一定的主觀性，為項目未來建設埋下了潛在的風險。需求自身經常變動根據以往的歷史經驗，隨著客戶方對信息化建設的認識和自己業務水平的提高，他們會在不同的階段和時期對項目的需求提出新的要求和需求變更。事實上，歷史上沒有一個軟件的需求改動少於三次的！所以必須接受“需求會變動”這個事實，在進行需求分析時要懂得防患於未然，儘可能地分析清楚哪些是穩定的需求，哪些是易變的需求，以便在進行系統設計時，將軟件的核心建築在穩定的需求上，同時留出變更空間。諮詢監理方在需求分析的功能界定上擔任一個中間、公平、公正的角色，所以也必須積極參與到需求分析的準備中來，以便協助客戶方和承建方來界定“做什麼”、“不做什麼”的系統功能界限。分析人員或客戶理解有誤軟件系統分析人員不可能都是全才，更不可能是行業方面的專家。客戶表達的需求，不同的分析人員可能有不同的理解。如果分析人員理解錯了，可能會導致以後的開發工作......

如何進行用戶需求分析

1.概念

需求的定義包括從用戶角度(系統的外部行為),以及從開發者角度(一些內部特性)來闡述需求.

關鍵的問題是一定要編寫需求文檔.我曾經目睹過一個項目中途更換了所有的開發者,客戶被迫與新的需求分析者坐到一起.系統的分析人員說:"我們想與你談談你的需求."客戶的第一反應便是:"我已經將我的要求都告訴你們前任了,現在我要的就是給我編一個系統".

百事通

而實際上,UGGs,需求並未編寫成文檔,因此新的分析人員不得不從頭做起.所以如果只有一堆郵件、會談記錄或一些零碎的未整理的對話,你就確信你已明白用戶的需求,那完全是自欺欺人.

需求的另外一種定義認為需求是"用戶所需要的並能觸發一個程序或系統開發工作的說明".有些需求分析專家拓展了這個概念:"從系統外部能發現系統所具有的滿足於用戶的特點、功能及屬性等".這些定義強調的是產品是什麼樣的,而並非產品是怎樣設計、構造的.而下面的定義則從用戶需要進一步轉移到了系統特性:

需求是指明必須實現什麼的規格說明.它描述了系統的行為、特性或屬性,是在開發過程中對系統的約束.

從上面這些不同形式的定義不難發現:並沒有一個清晰、毫無二義性的"需求"術語存在,真正的"需求"實際上在人們的腦海中,這個人們主要是指客戶,但一般情況下,用戶並不能描述自己的需要,只就需要系統分析人員根據用戶的自己語言的描述整理出相關的需要再進一步和客戶核對.系統分析員和客戶需要確保所有項目風險承擔者在描述需求的那些名詞的理解上務必達成共識.

任何文檔形式的需求(例如如下將要描述的需求規格說明書)僅是一個模型,一種描述.

2.需求分析的任務

開發軟件系統最為困難的部分就是準確說明開發什麼.最為困難的概念性工作便是編寫出詳細技術需求,這包括所有面向用戶、面向機器和其它軟件系統的接口.同時這也是一旦做錯,將最終會給系統帶來極大損害的部分,並且以後再對它進行修改也極為困難.

目前,國內產品的龐雜,一家企業可能有幾個系統並立運行,它們之間接口是系統開發人員最頭痛的問題.

對於商業最終用戶應用程序,企業信息系統和軟件作為一個大系統的一部分的產品是顯而易見的.但是對於我們開發人員來說,並沒有編寫出客戶認可的需求文檔,我們如何知道項目於何時結束?而如果我們不知道什麼對客戶來說是重要的,那我們又如何能使客戶感到滿意呢?

然而,即便並非出於商業目的的軟件需求也是必須的.例如庫、組件和工具這些供開發小組內部使用的軟件.當然你可能偶爾勿需文檔說明就能與其他人意見較為一致,但更常見的是出現重複返工這種不可避免的後果,而重新編制代碼的代價遠遠超過重寫一份需求文檔的代價,這些血的教訓正在國內的軟件開發者身上發生.

近來,我遇到一個開發小組開發包括代碼編輯器在內的一套內部使用的計算機輔助軟件.不幸的是,當他們開發完這個工具後,發現這個工具不能打印出源代碼文件,使用者當然希望有這個功能.結果這個小組只好手工抄寫源代碼文檔以供代碼檢查.這說明那怕需求明確無誤並構思準確,如果我們沒有編寫文檔,軟件達不到期望目標也只能是咎由自取了.

相反的情況,我曾見一個要集成到"錯誤跟蹤系統"中的簡單界面寫了一頁需求說明.而操作系統系統管理員在為處理腳本時發現簡單的一張需求清單竟是如此有用.他們依據需求對系統進行測試時,此係統不僅非常清晰地實現了所有必需功能,而且未發現任何錯誤.

事實上,需求文檔在開發過程中一直起指導作用.

3.需求分析過程

可把整個軟件需求工程......

如何做需求分析

隨著技術的不斷髮展和用戶對網站功能性的需求不斷提高，如今網站項目的設計已經不能再僅僅簡單地利用靜態Html文件來實現，與前幾年網站設計由一兩名網頁設計師自由的創作相比，網站項目的設計和開發越來越像一個軟件工程，也越來越複雜，網站項目的設計和開發進入了需要強調流程和分工的時代，建立規範的、有效的、健壯的開發機制，才能適應用戶不斷變化的需要，達到預期的計劃目標。

網站項目管理（WPM）的含義為Web-based Project Management，即以Web 應用程序為主要表現方式的架構來進行的項目設計及管理，這樣的架構中包含了瀏覽器、網絡和Web

服務器等關鍵主體，主要體現在網站設計、以瀏覽器為客戶端的Web應用程序開發（例如信息類網站、網上商店、虛擬郵局、客戶關係管理。）等項目管理中。

按照筆者的經驗，網站項目管理可以分為以下l六個階段進行控制：

1. 需求分析及變更管理

2. 項目模型及業務流程分析

3. 系統分析及軟件建模

4. 界面設計、交互設計及程序開發

5. 系統測試和文檔編寫

6. 客戶培訓、技術支持和售後服務

需要說明的是，這些階段雖然具有一定的延續性，但是並非完全隔斷的，例如需求變更管理和測試工作、文檔編寫都是貫穿整個項目過程的，許多工作時交叉進行或同時進行的。

（一）如何做好需求分析及變更管理？

業務員與客戶進行的溝通，撰寫需求分析報告是項目展開的基礎。項目是以客戶的需求為中心，而不是為技術而遷就需求。

一：讓客戶暢所欲言，羅列出所有的需求

讓用戶將所有的想法儘可能的闡述清楚，並把所有的要求羅列出來，不要遺漏。這時候不應該害怕“勾引”起客戶的潛在需求而增加設計開發的工作量，從而被今後客戶無止境的變更拖入泥潭，直接明白地跟客戶把問題和要求一條條地列出來，把條理、歸納、分析先都扔到一邊去，將用戶最原始、最完整的要求準確地記錄下來就完成了第一步的工作。

很明顯，假如客戶的需求做的都不完整，隨時可能會產生意想之外的變更，甚至這個變更會破壞已經做的模型及結構，那麼這個項目從開始就註定了會失敗；比如站點所有的功能都實現了，本地測試起來也沒有什麼問題了，但是你卻不知道客戶的系統是要承受每天100萬獨立IP的訪問，而你原來想當然的以為了不起就是1萬獨立IP訪問的訪問流量，稍微有經驗的開發人員都會明白這樣的設計是個災難，無論是應用服務器、數據庫還是程序全部要重新開發！

二：透過現象分析潛在的需求

很多情況下客戶並非專業人士，在他們滔滔不絕的描述中不能指望他們幫助我們整理出重點和技術難關，這需要我們去為客戶進行分析、歸納和整理，尤其是客戶談的不多卻又是技術上實現難度和強度很高的地方特別值得注意。

客戶往往對需求的概念是非常模糊的，大多時候給出的需求都是籠統而且尺度難以控制的，這就要求業務人員在傾聽了客戶的詳細說明以後，幫助客戶進行整理和分析，同時預測客戶在開發過程中變更及今後應用中可能進行修改升級的潛在需求。

比如在為客戶設計辦公自動化系統的時候，也許就要為客戶預留將來與他們的業務單位進行交互的通道；在設計郵件系統的時候要考慮可能會需要廣告管理服務器；設計網絡電子商店時今後增加庫存產品進銷存統計分析等等；限於時間財力的考慮，客戶通常能夠接受分階段實施的開發過程，在需求分析時，提早為客戶設想到今後的需求變更除了使項目開發更加順利以外，也為今後業務的進一步深入打下......

需求分析的作用及如何進行需求分析

通過對應問題及其環境的理解與分析，為問題涉及的信息、功能及系統行為建立模型，將用戶需求精確化、完全化，最終形成需求規格說明，這一系列的活動即構成軟件開發生命週期的需求分析階段。

需求分析是介於系統分析和軟件設計階段之間的橋樑。一方面，需求分析以系統規格說明和項目規劃作為分析活動的基本出發點，並從軟件角度對它們進行檢查與調整；另一方面，需求規格說明又是軟件設計、實現、測試直至維護的主要基礎。良好的分析活動有助於避免或儘早剔除早期錯誤，從而提高軟件生產率，降低開發成本，改進軟件質量。

需求工程是隨著計算機的發展而發展的，在計算機發展的初期，軟件規模不大，軟件開發所關注的是代碼編寫，需求分析很少受到重視。後來軟件開發引入了生命週期的概念，需求分析成為其第一階段。隨著軟件系統規模的擴大，需求分析與定義在整個軟件開發與維護過程中越來越重要，直接關係到軟件的成功與否。人們逐漸認識到需求分析活動不再僅限於軟件開發的最初階段，它貫穿於系統開發的整個生命週期。80年代中期，形成了軟件工程的子領域——需求工程(requirementengineering,RE)。進入90年代以來，需求工程成為研究的熱點之一。從1993年起每兩年舉辦一次需求工程國際研討會(ISRE)，自1994年起每兩年舉辦一次需求工程國際會議(ICRE)，在1996年Springer-Verlag發行了一新的刊物——《RequirementsEngineering》。一些關於需求工程的工作小組也相繼成立，如歐洲的RENOIR(RequirementsEngineeringNetworkofInternationalCooperatingResearchGroups)，並開始開展工作。　　需求工程是指應用已證實有效的技術、方法進行需求分析，確定客戶需求，幫助分析人員理解問題並定義目標系統的所有外部特徵的一門學科。它通過合適的工具和記號系統地描述待開發系統及其行為特徵和相關約束，形成需求文檔，並對用戶不斷變化的需求演進給予支持。RE可分為系統需求工程（如果是針對由軟硬件共同組成的整個系統）和軟件需求工程（如果僅是專門針對純軟件部分）。軟件需求工程是一門分析並記錄軟件需求的學科，它把系統需求分解成一些主要的子系統和任務，把這些子系統或任務分配給軟件，並通過一系列重複的分析、設計、比較研究、原型開發過程把這些系統需求轉換成軟件的需求描述和一些性能參數。

需求工程是一個不斷反覆的需求定義、文檔記錄、需求演進的過程，並最終在驗證的基礎上凍結需求。80年代，HerbKrasner定義了需求工程的五階段生命週期：需求定義和分析、需求決策、形成需求規格、需求實現與驗證、需求演進管理。近來，MatthiasJarke和KlausPohl提出了三階段週期的說法：獲取、表示和驗證。

綜合了幾種觀點，可以把需求工程的活動劃分為以下5個獨立的階段：

（1）需求獲取：通過與用戶的交流，對現有系統的觀察及對任務進行分析，從而開發、捕獲和修訂用戶的需求；

（2）需求建模：為最終用戶所看到的系統建立一個概念模型，作為對需求的抽象描述，並儘可能多的捕獲現實世界的語義；

（3）形成需求規格：生成需求模型構件的精確的形式化的描述，作為用戶和開發者之間的一個協約；

（4）需求驗證：以需求規格說明為輸入，通過符號執行、模擬或快速原型等途徑，分析需求規格的正確性和可行性；

（5）需求管理：支持系統的需求演進，如需求變化和可跟蹤性問題。...

如何進行測試需求分析

測試需求分析流程測試需求分析要點要素分析1、界面元素是否滿足自定義的質量標準或行業通行標準或常用使用標準等2、公司部門制定的Web元素描述規範數據分析1、輸入域的數據2、已顯數據的來源3、數據的輸出4、數據關聯流程分析1、常用的或規定的業務流程2、各業務流程分支的遍歷3、明確規定不可使用的業務流程4、沒有明確規定但是應該不可以執行的業務流程功能交互分析1、結合數據分析，流程分析，但是側重點是功能實現。2、操作入口明確、合理“操作入口”，指的是產品內部不同模塊之間的轉接元素，例如在Web產品中，按鈕控件、輸入框、文字鏈等都屬於操作入口；“明確”指的是入口的視覺感是清晰的、可識別的；“合理”是指入口的出現是符合用戶操作邏輯的，適時的。3、實現功能的步驟簡潔明確“實現功能的步驟”指的是系統界面上實現業務功能的實際操作步驟，例如：註冊用戶時，輸入優惠代碼，點擊“應用”按鈕，再點擊“提交”。“簡潔明確”是指步驟符合實際業務邏輯並足夠簡潔，並且不會產生步驟上的混亂。4、交互執行的結果正確完整按系統操作步驟執行交互響應後的界面結果或其他功能的前置條件。用戶場景分析1、現在的軟件幾乎都是由事件觸發來控制流程的，事件觸發時的情景便形成了場景，而統一事件不同的觸發順序和處理結果就行成了事件流。2、模擬實際業務中形成某一事件的場景，轉變成系統中該事件觸發時的情景。從而檢驗該場景的正確性。質量模型分析1、度量需求定義的指標1）每條用戶需求的定義都正確反映了用戶的要求2）在第一層基礎上的完整性和一致性要求，即用戶的所有要求都有定義且不能相互矛盾2、一套結構化的根據指標對需求定義進行度量的方法過程方法分析1、組織結構關係分析2、業務流程展開模型

怎麼做好一個需求分析師？

看看下面這個故事吧，也許看完了你就能明白了。。

先來看一個老掉牙的故事：福特說，我在設計汽車之前，到處去問人們“需要一個什麼樣的更好的交通工具？”，幾乎所有人的答案都是 ── 一匹“更快的馬”。

“更好的交通工具”代表用戶的“需求”；“更快的”是用戶對於解決這個“需求”的“期望值”；“馬”是用戶對於解決這個“需求”的自假設“功能”。

一個初級的設計者，被用戶牽著鼻子走。聽到“更快的馬”以後，會馬上去設計一匹“馬”。這個時候，無論在“馬”上如何做創新，思路已經框死，結果很難突破。最終只能出來平庸的設計，很難長久很容易被模仿和超越，實現不了多大的商業價值。

一個合格的設計者，和用戶一起走。聽到“更快的馬”以後，會考慮“更快的”這個“期望值”，圍繞著它突破“馬”的侷限，去做設計。最終可能會出來很好的設計，但他們把“需求”本身拋到了腦後，最終只能簡單的滿足需求達到期望，而無法引導需求。他們績以做出來成功的產品，但隨著用戶期望的增長，這樣的產品很難有取得用戶的長久青睞，也很難取得商業上長久的成功。

一個卓越的設計者，自己會作為用戶的一部分深入瞭解他們，並帶著用戶一起走。聽到“更快的馬”以後，他們會先去考慮需求是“更好的交通”工具，然後再結合 “更快的”這個主要期望。用對用戶最有價值的方式在的滿足需求超越期望(把“馬”這件事拋到腦後)，從而引導需求，並獲取更豐厚更長久的商業利益，和用戶雙贏。

不可否認，史玉柱是一個商業的天才。

他發現了“送禮”這個大需求，並發現了送禮的期望在於“面子”而非“ 實用”。於是他通過“廣告”在推廣的同時增加產品的“價值”，而非在產品質量上增加“價值”。春節，杭州人告訴我：“我們春節送禮都是送保健品，廣告播什麼就買什麼，因為有知名度”。但他忘記了，這樣是否可以給用戶帶來真正的長期價值。生活層次相對較高的行州人又告訴我“我們不買腦白金和黃金酒，那些都是騙人的檔次低。我們買靈芝、鹿茸、人蔘、...”。

他發現了“砍人”的需求，並發現了“花再多錢也要砍死他”這個期望，最終使用了“網遊”這個功能，用最簡單粗暴的商業設計獲取暴利。但他忘記了，這樣做不能給人帶來真正的價值，於是最後他在利用互聯網社區引導需求的時候遇到了問題 ...

福特是一個商業的天才，更是產品的天才。

他可以發現人們需要“更好的交通工具”這個大需求，並肯定了這個需求的渴望程度會隨著社會交往的擴大會越來越強。同時他肯定了“更快的”這個用戶的首要期望，結合這個期望開始思考。然後，他又判斷出汽車比火車有更低的成本，而且對於用戶更有價值，會替代火車。最後，他用“汽車”而不是“馬”來滿足需求、達到並超越期望，同時引導用戶往下的進一步需求和期望... 於是，他的商業回報自然而然的產生了。

用戶的真正需求是什麼？》用戶的期望值是什麼？》如何做才對用戶最有價值，並讓企業獲利？》如何超越期望並引導需求，獲取更高更長久的商業利益？

這是一個必然思考邏輯，違背這個邏輯出來的產品勢必難以獲取長久的成功。從某種程度上來說，產品模式是“用戶真正需要的是什麼？”，產品設計是“主要滿足什麼期望值，給用戶帶去什麼價值？”，商業模式是“用什麼功能，如何賺錢？”，創新設計是“如何超越期望，獲取更高更長久的利益？”。

所以，我在同意邵亦波所說“創業者更應該注重‘產品’”的同時，主張一個產品的主導者甚至是一個企業的領導者，更應該注重：

產品模式的設計：用戶真正需要滿足的需求是什麼？

產品的設計：讓用戶達到什麼樣的期望？給他們帶去什麼價值？......

如何做需求分析

看你是問什麼？公司還是個人

如何進行非功能需求分析？

按照常規的需求分析理論，需求可分為功能需求和肺功能需求，其中非功能需求又可分為質量和約束。一般來說，對於功能需求，我們仔細一點，多和用戶溝通的話，是比較好分析的。而對於非功能需求，我們有時會覺得心有餘而力不足，或者說不知如何是好。在很多情況下，項目組乾脆就不去分析非功能需求了，所有的這些非功能需求只是停留在項目經理或者某些成員的腦子裡。這種情況存在著非常大的隱患，如果產品發佈了，我們沒有對這些非功能需求進行測試和驗證，導致我們的產品中存在許多定時炸彈。這些炸彈在某些場景下就有可能爆炸，炸了用戶，也可能炸了自己。對於以上問題，業界有一定分析工具可以有效的解決該問題，即“目標-場景-對策”分析法。舉例來說：目標場景決策性能客戶端頻繁訪問頁面，WEB服務器負荷大代理服務器客戶端大量訪問後臺圖片圖片服務器程序頻繁訪問IO，磁盤壓力大數據庫拆分以上舉了我們對非功能需求中的“性能”大類進行了分析，比如對月客戶端大量訪問後臺圖片的場景，我們採取了圖片服務器的應對策略。這種分析方法和原有的“存而不論”的方法相比，有以下優點：1、它在流程上就規定了分析人員必須對產品中的非功能需求進行分析；2、它針對非功能需求的目標進行了歸類整理；3、對於每個目標中可能發生的場景進行了梳理；4、最後就是比較關鍵的一條就是，對於每種場景，我們都仔細思考了針對性的決策分析，這些決策為後續的設計起到了指導作用。

如何做好需求分析，需求調研

轉載以下資料供參考

從廣義上理解：需求分析包括需求的獲取、分析、規格說明、變更、驗證、管理的一系列需求工程。

狹義上理解需求分析指需求的分析、定義過程。

原因

需求分析就是分析軟件用戶的需求是什麼。如果投入大量的人力，物力、財力、時間，開發出的軟件卻沒人要，那所有的投入都是徒勞。如果費了很大的精力，開發一個軟件，最後卻不滿足用戶的要求，從而要重新開發過，這種返工是讓人痛心疾首的(相信大家都有體會)。比如：用戶需要一個for linux的軟件，而你在軟件開發前期忽略了軟件的運行環境，忘了向用戶詢問這個問題，而想當然的認為是開發for windows的軟件。當你千辛萬苦地開發完成向用戶提交時才發現出了問題，那時候你是欲哭無淚了，恨不得找塊豆腐一頭撞死。

需求分析之所以重要，就因為他具有決策性、方向性、策略性的作用，他在軟件開發的過程中具有舉足輕重的地位，大家一定要對需求分析具有足夠的重視。在一個大型軟件系統的開發中，他的作用要遠遠大於程序設計。

任務

簡言之，需求分析的任務就是解決“做什麼"的問題，就是要全面地理解用戶的各項要求，並準確地表達所接受的用戶需求。

過程

需求分析階段的工作,可以分為四個方面：問題識別、分析與綜合、制訂規格說明、評審。

問題識別：就是從系統角度來理解軟件，確定對所開發系統的綜合要求，並提出這些需求的實現條件，以及需求應該達到的標準。這些需求包括：功能需求(做什麼)、性能需求(要達到什麼指標)、環境需求(如機型、操作系統等)、可靠性需求(不發生故障的概率）、安全保密需求、用戶界面需求、資源使用需求(軟件運行是所需的內存、CPU等)、軟件成本消耗與開發進度需求、預先估計以後系統可能達到的目標。

分析與綜合：逐步細化所有的軟件功能，找出系統各元素間的聯繫，接口特性和設計上的限制，分析他們是否滿足需求，剔除不合理部分，增加需要部分。最後綜合成系統的解決方案，給出要開發的系統的詳細邏輯模型(做什麼的模型)。

制訂規格說明書：即編制文檔，描述需求的文檔稱為軟件需求規格說明書。請注意，需求分析階段的成果是需求規格說明書，向下一階段提交。

評審：對功能的正確性，完整性和清晰性，以及其它需求給予評價。評審通過才可進行下一階段的工作,否則重新進行需求分析。

方法

需求分析的方法有很多，這裡只強調原型化方法，其它的方法如：結構化方法、動態分析法等，從來沒用過這些方法在此不討論。

原型化方法是十分重要的，原型就是軟件的一個早期可運行的版本，它實現了目標系統的某些或全部功能。

原型化方法就是儘可能快地建造一個粗糙的系統，這系統實現了目標系統的某些或全部功能。但是這個系統可能在可靠性、界面的友好性或其他方面上存在缺陷。建造這樣一個系統的目的是為了考察某一方面的可行性，如算法的可行性、技術的可行性或考察是否滿足用戶的需求等。如：為了考察是否滿足用戶的要求，可以用某些軟件工具快速的建造一個原型系統，這個系統只是一個界面，然後聽取用戶的意見，改進這個原型。以後的目標系統就在原型系統的基礎上開發。

原型主要有三種類型：探索型、實驗型、進化型。

探索型：目的是要弄清楚對目標系統的要求，確定所希望的特性，並探討多種方案的可行性。

實驗型：用於大規模開發和實現前，考核方案是否合適，規格說明是否可靠。