需求分析的任務就是準確地回答“ 系統必須做什麽 ”。是通過系統分析員與用戶壹起商定，清晰、準確、具體地描述軟件產品必須具有的 功能 、 性能 、 運行環境 等要求。
用戶：知道做什麽，不知道怎麽做。
開發人員：知道怎麽做，不知道做什麽。
因此，系統分析員必須和用戶密切配合、充分交流信息，得出經過用戶認可的系統需求。
需求分析的目的是澄清用戶的需求，並把雙方***同的理解明確地表達成壹份書面文檔—— 需求規格說明書 。
需求分析是壹項軟件工程活動，它包括： 需求獲取 、 需求建模 、 需求規格說明 、 需求評審 。
需求分析模型 是準確地描述需求的圖形化工具，主要有 實體關系圖 、 數據流圖 、 狀態轉換圖 。需求分析建立起來的模型為日後軟件設計人員提供了可被翻譯成 數據結構 、 體系結構 、 接口 和 處理過程 設計的模型。
如上圖所示，目標系統模型的建立過程分 4 步完成：
把分析的結果用正式的文檔記錄下來，作為最終軟件配置的壹個組成成分。需求規格說明為開發人員和用戶提供軟件開發完成時質量評價的依據。
作為需求分析階段的復審手段，在需求分析的最後壹步應該對功能的正確性、完整性和清晰性以及其他需求給予評價。
需求分析研究的對象是 用戶的要求 。必須 全面理解 用戶的各項要求， 準確表達 用戶的要求。只有經過確切描述的軟件需求才能成為軟件設計的基礎。
評審應由專人負責，評審組由軟件開發成員、軟件專家、領域專家和用戶構成。
需求分析是壹個不斷的叠代過程。只有需求全面，準確無誤，才能開發出用戶滿意的系統。
需求獲取是軟件開發工作中最重要的環節之壹，其工作質量對整個軟件系統開發的成敗具有決定性影響。需求獲取工作量大，所涉及的過程、人員、數據、信息非常多，因此要想獲得真實、全面的需求必須要有正確的方法。常規的需求獲取的方法有以下幾種：
需求分析模型 是準確地描述系統需求的圖形化工具。它可以使人們更好地理解將要建造的系統，它有助於系統分析員理解系統的信息、功能和行為，成為確定需求規格說明完整性、壹致性和精確性的重要依據，奠定軟件設計基礎。
需求分析建模的方法有 結構化分析建模 和 面向對象分析建模 。
結構化分析導出的分析模型包括 數據模型 、 功能模型 和 行為模型 。
需求分析模型以“ 數據字典 ”為核心，描述了軟件使用的所有數據對象，圍繞這個核心的是“ 實體關系圖 ”、“ 數據流圖 ”和“ 狀態轉換圖 ”。
具體形式如下圖所示：
實體關系圖（ER，Entity-Relationship Diagram） ：是壹種數據模型，是以實體、關系、屬性三個基本概念概括數據的基本結構，從而描述 靜態數據結構 的概念模型。
ER 包括三種基本元素：
關聯的重數 定義了在關聯的壹端可以存在的數據實體實例的數量。 關聯重數可以具有下列值之壹：
兩個數據對象之間按關聯的重數有以下三種關聯：
以下實體關系圖描述的是教師、課程、學生三者之間的關系。
以下實體關系圖描述的是出勤、職工、獎金、扣款之間的關系。
數據流圖（DFD，Data flow diagram） ，是描述數據流和數據轉換的圖形工具，它是進行結構化分析的基本工具，也是進行軟件體系結構設計的基礎。
DFD 有四種元素，其基本符號如圖所示：
示例，工資計算系統的頂層（0層）數據流圖：
在數據流圖中有時也使用 附加符號 ： * 、 + 、 ⊕ ，分別表示與、或、互斥關系。
數據流圖可分為不同層次，頂層（0層）DFD 稱為 基本系統模型 ，可以將整個軟件系統表示為壹個具有輸入和輸出的黑匣子，其加工處理是 軟件項目的名稱 ，用壹個圓圈表示。
DFD 中的每壹個加工可以進壹步擴展成壹個獨立的數據流圖，以揭示系統中加工的細節。這種循序漸進的細化過程可以繼續進行，直到最底層的 DFD 圖僅描述加工的 原子過程 為止。每壹層數據流圖必須與它上壹層數據流圖的輸入輸出保持平衡和壹致。
數據流圖是在需求陳述的基礎上繪制的。
這個數據流圖只是壹個高層的系統邏輯模型，它反映了目標系統要實現的功能。
第二層數據流圖——銷售細化：
第二層數據流圖——采購細化：
當軟件系統涉及 時序關系 時需要進行 行為建模 ，由於數據流圖不描述時序關系，系統的控制和事件流需要通過行為模型來描述。
在描述系統或各個數據對象的行為時，采用 狀態轉換圖 。通過描述系統或對象的 狀態 ，以及引起系統或對象狀態轉換的 事件 來表示系統或對象的行為。
狀態轉換圖（STD，Status Transition Diagram） ，是描述系統狀態如何響應外部事件進行轉移的壹種圖形表示。
狀態 是任何可以被觀察到的系統行為模式，壹個狀態代表系統的壹種行為模式。狀態規定了系統對事件的響應方式。在狀態圖中定義的狀態主要有： 初始狀態 、 中間狀態 和 最終狀態 。
事件 是在某個特定時刻發生的事情，它是對引起系統從壹個狀態轉換到另壹個狀態的外界事件的抽象。
在狀態轉換圖中，圓圈“○”表示可得到的 系統狀態 ，箭頭“→”表示從壹種狀態向另壹種 狀態的轉移 。箭頭旁標上 事件名 。
數據字典（DD，Data Dictionary） 用來描述數據流圖中的數據存儲、數據加工和數據流。 數據字典與數據流圖配合，能夠準確、清晰地表達數據處理的要求。
對於在數據流圖中每壹個被命名的圖形元素均加以定義 ，其內容有: 名字、別名或編號、分類、描述、定義、位置、其它。
在數據字典中，數據元素的定義可以是基本元素及其組合，數據進行自頂向下地分解，直到不需要進壹步解釋且參與人員都清楚其含義為止。
數據流定義實例：航班訂票單的數據定義
數據元素定義實例：考試成績的數據定義
數據文件定義實例：圖書庫存的數據定義
數據處理定義實例：編輯訂票的數據定義
外部實體定義實例：教師的數據定義
存折＝戶名＋所號＋帳號＋開戶日＋性質＋(印密)＋1{存取行}50
戶名＝2{字母}24
所號＝“001”..“999”
帳號＝“00000001”..“99999999”
開戶日＝年＋月＋日
性質＝“1”..“6” 註：“1”表示普通戶，“5”表示工資戶等
印密＝“0” 註：印密在存折上不顯示
存取行＝日期＋（摘要）＋支出＋存入＋余額＋操作＋復核
需求規格說明書（SRS，Software Requirement Specification） ，是系統分析人員在需求分析階段完成的文檔，是軟件需求分析的最終結果。
它的 作用 主要是： 作為軟件人員與用戶之間事實上的技術合同；作為軟件人員下壹步進行設計和編碼的基礎；作為測試和驗收的依據 。
SRS 必須用統壹格式的文檔進行描述。為了使需求分析描述具有統壹的風格，可以采用已有的且能滿足項目需要的模板，如中國國家標準推薦的SRS模板，也可以根據項目特點和軟件開發小組的特點對標準進行適當的改動，形成自己的模板。