需求分析也稱為軟體需求分析、系統需求分析或需求分析工程等，是開發人員經過深入細緻的調研和分析，準確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統必須做什麼的過程。
基本介紹
- 中文名：需求分析
- 外文名：requirement analysis
- 別稱：軟體需求分析
- 定義：通過分析，確定系統功能的過程
- 方法：功能分析法等
- 所屬學科：軟體工程
目標,原則,內容,過程,方法,特點,
目標
需求分析是軟體計畫階段的重要活動，也是軟體生存周期中的一個重要環節，該階段是分析系統在功能上需要“實現什麼”，而不是考慮如何去“實現”。需求分析的目標是把用戶對待開發軟體提出的“要求”或“需要”進行分析與整理，確認後形成描述完整、清晰與規範的文檔，確定軟體需要實現哪些功能，完成哪些工作。此外，軟體的一些非功能性需求(如軟體性能、可靠性、回響時間、可擴展性等)，軟體設計的約束條件，運行時與其他軟體的關係等也是軟體需求分析的目標。
原則
為了促進軟體研發工作的規範化、科學化，軟體領域提出了許多軟體開發與說明的方法，如結構化方法、原型化法、面向對象方法等。這些方法有的很相似。在實際需求分析工作中．每一種需求分析方法部有獨特的思路和表示法，基本都適用下面的需求分析的基本原則。
(1)側重表達理解問題的數據域和功能域。對新系統程式處理的數據，其數據域包括數據流、數據內容和數據結構。而功能域則反映它們關係的控制處理信息。
(2)需求問題應分解細化，建立問題層次結構。可將複雜問題按具體功能、性能等分解並逐層細化、逐一分析。
(3)建立分析模型。模型包括各種圖表，是對研究對象特徵的一種重要表達形式。通過邏輯視圖可給出目標功能和信息處理間關係，而非實現細節。由系統運行及處理環境確定物理視圖，通過它確定處理功能和數據結構的實際表現形式。
內容
需求分析的內容是針對待開發軟體提供完整、清晰、具體的要求，確定軟體必須實現哪些任務。具體分為功能性需求、非功能性需求與設計約束三個方面。
1．功能性需求
功能性需求即軟體必須完成哪些事，必須實現哪些功能，以及為了向其用戶提供有用的功能所需執行的動作。功能性需求是軟體需求的主體。開發人員需要親自與用戶進行交流，核實用戶需求，從軟體幫助用戶完成事務的角度上充分描述外部行為，形成軟體需求規格說明書。
2．非功能性需求
作為對功能性需求的補充，軟體需求分析的內容中還應該包括一些非功能需求。主要包括軟體使用時對性能方面的要求、運行環境要求。軟體設計必須遵循的相關標準、規範、用戶界面設計的具體細節、未來可能的擴充方案等。
3．設計約束
過程
需求分析階段的工作,可以分為四個方面：問題識別、分析與綜合、制訂規格說明、評審。
問題識別：就是從系統角度來理解軟體，確定對所開發系統的綜合要求，並提出這些需求的實現條件，以及需求應該達到的標準。這些需求包括：功能需求(做什麼)、性能需求(要達到什麼指標)、環境需求(如機型、作業系統等)、可靠性需求(不發生故障的機率）、安全保密需求、用戶界面需求、資源使用需求(軟體運行是所需的記憶體、CPU等)、軟體成本消耗與開發進度需求、預先估計以後系統可能達到的目標。
分析與綜合： 逐步細化所有的軟體功能，找出系統各元素間的聯繫，接口特性和設計上的限制，分析他們是否滿足需求，剔除不合理部分，增加需要部分。最后綜合成系統的解決方案，給出要開發的系統的詳細邏輯模型(做什麼的模型)。
制訂規格說明書： 即編制文檔，描述需求的文檔稱為軟體需求規格說明書。請注意，需求分析階段的成果是需求規格說明書，向下一階段提交。
評審： 對功能的正確性，完整性和清晰性，以及其它需求給予評價。評審通過才可進行下一階段的工作,否則重新進行需求分析。
方法
目前，軟體需求的分析與設計方法較多，一些大同小異，而有的則基本思路相差很大。從開發過程及特點出發，軟體開發一般採用軟體生存周期的開發方法，有時採用開發原型以幫助了解用戶需求。在軟體分析與設計時，自上而下由全局出發全面規劃分析，然後逐步設計實現。
從系統分析出發，可將需求分析方法大致分為功能分解方法、結構化分析方法、信息建模法和面向對象的分析方法。
(1)功能分解方法。
將新系統作為多功能模組的組合。各功能義可分解為若干子功能及接口，子功能再繼續分解。便可得到系統的雛形，即功能分解——功能、子功能、功能接口。
(2)結構化分析方法。
結構化分析方法是一種從問題空間到某種表示的映射方法，是結構化方法中重要且被普遍接受的表示系統，由數據流圖和數據詞典構成並表示。此分析法又稱為數據流法。其基本策略是跟蹤數據流，即研究問題域中數據流動方式及在各個環節上所進行的處理，從而發現數據流和加工。結構化分析可定義為數據流、數據處理或加工、數據存儲、端點、處理說明和數據字典。
(3)信息建模方法。
它從數據角度對現實世界建立模型。大型軟體較複雜；很難直接對其分析和設計，常藉助模型。模型是開發中常用工具，系統包括數據處理、事務管理和決策支持。實質上，也可看成由一系列有序模型構成，其有序模型通常為功能模型、信息模型、數據模型、控制模型和決策模型。有序是指這些模型是分別在系統的不同開發階段及開發層次一同建立的。建立系統常用的基本工具是E—R圖。經過改進後稱為信息建模法，後來又發展為語義數據建模方法，並引入了許多面向對象的特點。
信息建模可定義為實體或對象、屬性、關係、父類型/子類型和關聯對象。此方法的核心概念是實體和關係，基本工具是E-R圖，其基本要素由實體、屬性和聯繫構成。該方法的基本策略是從現實中找出實體，然後再用屬性進行描述。
(4)面向對象的分析力法。
面向對象的分析方法的關鍵是識別問題域內的對象，分析它們之間的關係，並建立三類模型，即對象模型、動態模型和功能模型。面向對象主要考慮類或對象、結構與連線、繼承和封裝、訊息通信，只表示面向對象的分析中幾項最重要特徵。類的對象是對問題域中事物的完整映射，包括事物的數據特徵(即屬性)和行為特徵(即服務)。
特點
需求分析的特點及難點，主要體現在以下幾個方面。
(1)確定問題難。主要原因：一是套用領域的複雜性及業務變化，難以具體確定；二是用戶需求所涉及的多因素引起的，比如運行環境和系統功能、性能、可靠性和接口等。
(2)需求時常變化。軟體的需求在整個軟體生存周期，常會隨著時間和業務而有所變化。有的用戶需求經常變化，一些企業可能正處在體制改革與企業重組的變動期和成長期，其企業需求不成熟、不穩定和不規範，致使需求具有動態性。
(3)交流難以達到共識。需求分析涉及的人事物及相關因素多，與用戶、業務專家、需求工程師和項目管理員等進行交流時，不同的背景知識、角色和角度等，使交流共識較難。
(4)獲取的需求難以達到完備與一致。由於不同人員對系統的要求認識不盡相同，所以對問題的表述不夠準確，各方面的需求還可能存在著矛盾。難以消除矛盾，形成完備和一致的定義。
(5)需求難以進行深入的分析與完善。需求理解對不全面準確的分析，客戶環境和業務流程的改變。市場趨勢的變化等。也會隨著分析、設計和實現而不斷深入完善，可能在最後重新修訂軟體需求。分析人員應認識到需求變化的必然性，並採取措施減少需求變更對軟體的影響。對必要的變更需求要經過認真評審、跟蹤和比較分析後才能實施。
