需求分析是一項軟體工程的活動，其目的包括以下幾點：
完整地獲取使用者要求，清楚地理解索要解決的問題；
描述清楚軟體的功能和效能；
指明軟體與其他系統元素的介面；
建立軟體必須滿足的約束（如執行環境等）。
需求分析是研究使用者要求，以得到目標系統的需求定義的過程。需求分析的基本任務是軟體開發人員和使用者一起完全弄清使用者對系統的確切要求。具體步驟包括下面幾點。
調查研究的方法有訪談、分發調查表或開會等。
（1）訪談 ：正式訪談和非正式訪談 。
（2）分發調查表：調查表中列出需要的內容，讓使用者書面回答問題。
（3）開會 ：可採用開會-討論-確認的方法進行調查。
需求分析建立起來的模型為日後的軟體設計提供了可被翻譯成資料、體系結構、介面和處理過程設計的模型。
1)．業務需求（business requirement）反映了組織機構或客戶對系統、產品高層次的目標要求，它們在專案檢視與範圍文件中予以說明。
2)．使用者需求(user requirement) 文件描述了使用者使用產品必須要完成的任務，這在使用例項（usecase）文件或方案指令碼說明中予以說明。
3)．功能需求(functional requirement) 定義了開發人員必須實現的軟體功能，使得使用者能完成他們的任務，從而滿足了業務需求。
4). 非功能需求(non-functional requirement) 作為功能需求的補充，軟體需求規格說明還應包括非功能需求，它描述了系統展現給使用者的行為和執行的操作等。它包括產品必須遵從的標準、規範和合約；外部介面的具體細節；效能要求；設計或實現的約束條件及質量屬性。所謂約束是指對開發人員在軟體產品設計和構造上的限制。質量屬性是通過多種角度對產品的特點進行描述，從而反映產品功能。多角度描述產品對使用者和開發人員都極為重要。常見的非功能需求如表所示。
產品要求
效能要求
實時性；響應時間、處理時間、包傳送時間等時間要求；資源配置要求；精確度、速度；處理量等要求
可靠性有效性；資料完整性
安全保密
安全性；保密性
執行要求
使用頻度、執行期限；控制方式；對操作員要求
物理要求
系統規模
過程要求
開發型別
實用性開發或試驗性開發
專案估算
開發工作量估算
開發方法
質量控制標準；里程表和評審；驗收標準
優先順序
權衡各種質量目標要求，排定優先實現次序
可維護性
可理解性、可測試性、可移植性、可修改性
下面以乙個字處理程式為例來說明需求的不同種類。業務需求可能是：「使用者能有效地糾正文件中的拼寫錯誤」，該產品的包裝盒封面上可能會標明這是個滿足業務需求的拼寫檢查器。而對應的使用者需求可能是「找出文件中的拼寫錯誤並通過乙個提供的替換項列表來供選擇替換拼錯的詞」。同時，該拼寫檢查器還有許多功能需求，如找到並高亮度提示錯詞的操作；顯示提供替換詞的對話方塊以及實現整個文件範圍的替換。
(1) sa（structure analysis）：面向資料流的結構化分析方法。
(2) jsd（jackson system development）：面向資料結構的jackson方法。
(3) dssd（data structure system development）：面向資料結構的結構化資料系統開發方法。
(4) ooa（object-oriented analysis）：物件導向的分析方法。
功能模型：dfd資料流圖
描述資料在系統中如何被傳送或者變換，以及描述如何對資料進行變換的功能（子功能）。
資料模型：erd實體-關係圖
描述資料物件及資料物件之間的關係。
行為模型：std狀態-遷移圖
描述系統對外部事件如何響應，如何動作以及系統的各種行為模式和不同狀態的轉換。
結構化分析遵循的三條基本原則：分解、抽象、對映
三個主要目標：
描述使用者需要
建立建立軟體設計的基礎
定義軟體完成後可被確認的一組需求
需求規格說明書可以簡單理解為由可行性分析、需求建模等內容組成，它為開發人員和使用者提供軟體開發完成時質量評價的依據。
需求分析研究的物件是使用者的需求，必須全面理解使用者的各項要求，準確表達被接受的使用者要求。只有經過確切描述的軟體需求才能成為軟體設計的基礎。
在需求評審階段，分析人員要在使用者和軟體設計人員的配合下對自己生成的需求規格說明和初步的使用者手冊進行複核，以確保軟體需求的完整、準確、清晰、具體，並使使用者和軟體設計人員對需求規格說明和初步的使用者手冊的理解達成一致。一旦發現遺漏或模糊點，必須盡快更正，再行檢查。
由系統分析員和使用者一起對需求分析結果進行嚴格的審查，確保軟體需求的一致性，完整性和正確性。審查內容有：實體-關係圖、詳細的資料流圖、資料字典、狀態轉換圖和一些簡明的演算法描述等。
a．無歧義性
對最終產品的每乙個特性用某一術語描述；若某一術語在某一特殊的行文中使用時具有多種含義，那麼應對該術語的每種含義做出解釋並指出其適用場合。
b．完整性
需求分析報告應該包括全部有意義的需求，無論是關係到功能的、效能的、設計約束的、還是關係到外部介面方面的需求；對所有可能出現的輸入資料的響應予以定義，要對合法和非合法的輸入值的響應做出規定；填寫全部插圖、表、圖示標記等；定義全部術語和度量單位。
c．可驗證性
需求分析報告描述的每乙個需求應是可以驗證的。可以通過乙個有限處理過程來檢查軟體產品是否滿足需求。
d．一致性
在需求分析報告中的各個需求的描述不能互相矛盾。
e．可修改性
需求分析報告應具有乙個有條不紊、易於使用的內容組織；沒有冗餘，即同一需求不能在需求分析報告中出現多次。
f．可追蹤性
每乙個需求的源流必須清晰，在進一步產生和改變檔案編制時，可以方便地引證每乙個需求。
g．執行和維護階段的可使用性
需求分析報告必須滿足執行和維護階段的需要。在需求分析報告要寫明功能的**和目的。
外部介面需求怎麼寫 軟體需求規約怎麼寫
軟體需求規約是專案方和需求方共同協商的專案規則和標準，通過 的描述，使雙方達成書面一致。需求方可以是公司自有專案，也可以是外部客戶。無論是哪種型別，在專案開始前都要對需求進行理順，才能更好的開展專案工作。軟體專案的需求會經常涉及到變更，所以當有需求變動的時候還要輸出需求跟蹤矩陣，對照原始需求對新需求...
怎麼做需求分析
如果將需求分析階段的工作歸結為編寫需求規格說明書，這種簡化的做法往往是導致專案後期層出不窮問題的罪魁禍首。建議採用以下步驟形成軟體需求 獲取使用者需求 分析使用者需求 編寫需求文件 評審需求文件 管理需求。下面我們先來討論前兩個步驟 獲取使用者需求 分析使用者需求 的做法。獲取使用者需求 這是該階段...
怎麼做需求分析
乙個成功專案的關鍵在於需求做的怎麼樣！做專案需求可以是對涉及的各個部門人員分別做調查，相對來講，這樣做的需求分析，才更能體現實際，切實了解到客戶基層遇到哪些困難 需要解決哪些問題 以及操作的整個流程，但，並不是每個部門的每個人員都願意配合工作 專案成功可能會導致某些人丟職位 也可以是只對相關領導和關...