在軟體工程中，需求分析指的是在建立乙個新的或改變乙個現存的電腦系統時描寫新系統的目的、範圍、定義和功能時所要做的所有的工作。需求分析是軟體工程中的乙個關鍵過程。在這個過程中，系統分析員和軟體工程師確定顧客的需要。只有在確定了這些需要後他們才能夠分析和尋求新系統的解決方法。
在軟體工程的歷史中，很長時間裡人們一直認為需求分析是整個軟體工程中最簡單的乙個步驟，但在過去十年中越來越多的人認識到它是整個過程中最關鍵的 乙個過程。假如在需求分析時分析者們未能正確地認識到顧客的需要的話，那麼最後的軟體實際上不可能達到顧客的需要，或者軟體無法在規定的時間裡完工。
順利地完成需求分析是乙個艱鉅的挑戰。首先要確認所有持有關鍵資訊的人本身就不容易，然後還要從這些人獲得可用的資訊，把這些資訊轉化為清晰的和完整的形式。同時分析者還要考慮到可能的限制。除此之外他們還要考慮乙個專案的
乙個新專案開始的時候人們往往還非常興奮，往往試圖輕視需求分析的必要性。但對過去專案的分析證明乙個徹底的和無情的需求分析可以降低乙個專案的耗費和降低其技術風險。
隨著工程師對需求分析的越來越重視，今天我們對需求分析的主要困難也理解得比較清楚：
顧客有可能防止需求分析順利進行有以下幾種可能性：
但是軟體開發者也有他們的責任。由於軟體開發者收錢來開發他們的軟體，他們的責任就更加不可推脫了。由軟體開發者導致的困難有：
解決這些困難的乙個方法是使用專業的作業或系統分析員，這些專業人員通過專門訓練來填補商業和電腦世界之間的鴻溝的。這個方法可以達到一定的效果， 但從顧客方面來說要找到相應的有類似技巧的人就相當困難了。此外今天為需求分析所使用的方法依然還有很大的缺陷，它們還不夠有效。
2023年代以來新的技術有製作原型、統一建模語言、用例和敏捷軟體開發等方法。
需求分析有可能在乙個專案中成為乙個漫長、艱鉅的工作。需求分析專家與他們的顧客交談、記錄他們的交談結果、分析他們收集的資訊，從中提取互相矛盾 的地方，總結出乙個總體觀念，然後再與顧客交談他們發現的問題。這個過程可以不斷重複，在有些專案中這個過程可以伴隨著整個在有些專案中這個過程可以伴隨 著整個生命週期。
新系統很可能改變人之間的關係和人的工作環境，因此認定誰是重要的資訊持有者是非常重要得。只有這樣在需求分析的過程中才能夠將顧客所有的需要都紀錄下來，只有這樣才能保證他們認識到新的系統對他們來說帶來怎樣的變化。出於下述原因這個要求往往達不到：
為了使所有這些討論有條理、有組織和有效地被記錄下來，這些討論的過程和其內容的演化也必須被記錄下來。
分析員可以使用不同的技術來從顧客手中獲得需求。比較老的方式有採訪顧客，或者與顧客一起開座談會，列舉顧客的需求。比較新的技術有建立模型和使用用例。在最佳狀態下在採納了不同的技術後他們可以完全理解顧客的需要和與持重要資訊的人建立了必要的聯絡。
採訪持重要資訊的人是需求分析中乙個必不可少的過程。但在乙個大的系統中許多人必須被採訪，這需要許多時間和金錢，但最重要的是這個過程最可能顯示 現有的業務流程與新系統中的業務流程之間的差別。不同的顧客有可能有不同的或甚至相對的需求，在這種情況下分析員必須協調各方的需要。
出於上述原因一般假如乙個系統非常複雜的話需求分析最常用的方法是召開需求工作會，在需求工作會上分析員和持重要資訊的人一起分析系統的需要和發展解決方案。
這樣的工作會最好不要再採訪物件的工作場進行，這樣採訪物件不會被打擾。工作會有乙個負責人來保持會議的程序，乙個記錄員來記錄會議的討論，投影儀和相應的軟體是常用的工具。一般需要進行多次會議後才能得到最終結果。
一般認為需求工作會可以節省不少時間，因此是乙個非常有用的工具，但是往往很難同時將所有的持重要資訊的人聚集到一起。
乙個常見的缺陷是一些持重要資訊者在這樣的會議上不十分積極，因此他們的需求沒有獲得必要的重視。這樣得到的解決方案必然有限。此外需求工作會是乙個很好的分析現有系統的工具，但用它來尋求解決方案就不是十分有用了。
最常見的紀錄需求分析的方式是將顧客需求列入乙個合同式的表。乙個複雜的系統的檔案可以數百頁長。現代的分析員不願使用這樣的列表，因為它們被證明相當無用，但它們依然相當常見。
優點：缺點：
顧客和開發者對這個列表的理解往往完全不同。
這樣的合同式的列表給顧客乙個錯誤的安全的感覺，好像他們的要求都已列入了。但是由於這些列表本身對細節問題不能細述因此許多關鍵的細節問題實際 上並未列出和解決。這些問題一直到後來軟體開發時才被發現。那時開發者一般要與顧客再次討論這些問題並試圖按他們的意願和條件來解決這些問題。
這個列表對此後的系統設計不提供任何幫助，它們的結構無法直接進入新軟體。
從2023年代中開始，越來越多的人將作原型看作是解決需求分析的困難的辦法。原型模擬最終軟體的螢幕顯示，這樣使用者可以看到最終軟體將是什麼樣， 而實際上在這些螢幕顯示的背後還一切都空著呢。這樣顧客可以在系統還沒有建立之前就做出設計決定。當原型首次被使用的時候它們的效果被視為非常驚人。引入 原型往往提高顧客與開發者之間的資訊交換。原型的螢幕顯示後來往往很少被改變，因此可以大大地降低費用。
但此後十多年的實際應用證明雖然原型是一種有用的技術，但它也有它的缺陷：
用例是一種紀錄新系統或軟體更換時的需求的技術。每個用例包含乙個系統在作業時與使用者或與其它系統之間交換資訊的場景。一般用例避免使用術語，而盡量使用顧客、使用者或他們的專家的語言。一般用例由軟體開發者和顧客一起寫成。
在2023年代中用例很快地成為了紀錄需求分析的最主要的方式。尤其在它的發源地，在物件導向的程式設計中它的普及性非常高。但用例不僅可以用在物件導向的程式設計系統中，實際上用例本身並非物件導向的。
每個用例集中於描寫如何來完成乙個作業目標或任務。對傳統的軟體工程來說每個用例描寫系統的乙個特點。對大多數軟體專案來說乙個新的系統有多個（往往十幾個）用例。不同的軟體專案的格式或專案的進展都可能影響用例的細節性。
用例描述系統在執行時與外部執行者之間的資訊交換。外部執行者是任何系統外的、與系統交換資訊的物件或人物。它們可以是使用者、使用者的角色或其它系統。
用例將系統當作乙個「黑匣子」，它從外部來看與系統之間的資訊交換（包括系統的回答）。這樣它簡化對系統的需求的描寫而且防止對系統的工作方式作任何過早的假設。
每個用例應該符合下述條件：
在描寫功能需求時用例非常好用，但它們不適合描寫非功能需求。
從2023年代開始確認持關鍵資訊者被確定為乙個非常關鍵的過程。它同時也是需求分析的第一步。此前經理人員往往被認為是持關鍵資訊者。許多系統是按照這些經理人員的設想設計的，而實際的使用者很少或根本沒有對設計做任何貢獻。這樣的系統往往是大失敗。因此在2023年代和2023年代在軟體工程師中漸漸地持關鍵資訊者的概念擴充套件到主要使用者，後來還擴充套件到次要使用者。在2023年代中工程師們更加從乙個系統整體的觀念上來確定持關鍵資訊者。他們漸漸認識到不但在僱傭他們的顧客中有持關鍵資訊者，其他持關鍵資訊者包括：
成功地確認持關鍵資訊者是完整地完成需求分析的基礎。
需求分析，分析需求
1.何為需求 我們吧需求兩個漢字拆分開來看 需 需要 求 要求 即需要的要求，表示想要某種東西的堅定願望 這裡插入乙個小故事，某個小男孩在上小學二年級的時候，不經意間接觸到了一種叫psp的神奇玩具，就下定決心回家找家長要，一開始小孩的父親不贊同給小孩買那個東西，後來在小孩的再三請求，甚至為此寫了份保...
需求分析的介面需求 需求分析
本篇不是為業務分析人員寫的，不會細緻講解需求分析的方方面面，業務分析師可以看徐鋒的 軟體需求最佳實踐 或者王海鵬翻譯的 掌握需求過程 本篇立足於架構師視角，講解需求分析過程中應了解的過程和方法，以及需要特別關注的點。開發者拿到的往往是乙個個的方案，方案來自於需求，那麼開發者拿到的需求是怎麼來的？乙個...
需求分析 什麼是需求分析？
需求分析學習目錄 乙個使用者解決乙個問題或實現乙個目標所需的條件或能力 為了滿足乙個合同 標準 規範 或其它正是文件要求，乙個系統或系統構件必須具備或擁有的條件或能力。所有的需求共同形成系統或構件開發的基礎 一種反應1 2所描述的條件或能力的文件說明。在本人所上的軟體需求分析課程中，乙個軟體需求是指...