需求分析在我看來無疑是整個軟體工程活動中最為重要的一步，因為這決定了整個軟體系統的功能、效能，為整個軟體的完成打下了最重要的基礎。最最最重要的是，你面對的使用者可能啥都不懂，所以，這就需要需求分析工作加以引導。

需求分析的基本概念

需求分析確定系統必須具有的功能和效能（非功能性需求），系統要求的執行環境，並且預測系統發展的前景。

• 功能性需求：描述系統應該實現的功能和提供的服務。
• 非功能性需求：遵循的標準，實現的約束條件，質量屬性等。限定了選擇解決問題方案的範圍，如執行平臺、實現技術、程式語言和工具等。

這兒有一個簡單的例子說明了什麼功能性需求和非功能性需求

將飛機訂票系統中的以下方面做如下的劃分，F代表“功能性”，NF代表“非功能性”，X代表“不應當是需求”。簡要的說明功能性或非功能性需求的種類。對於不應當是需求的方面，說明其原因。

• 如何輸入有關航班、乘客及訂票資訊。 F：輸入
• 什麼資訊要出現在機票和報告中。 F：輸出
• 如何計算乘機費用。 F：計算
• 什麼資訊必須儲存在旅行社和其他人訪問的資料庫中。 F：儲存
• 這個系統應該設計成可以處理常旅客計劃。 NF：可擴充套件性
• 這個系統在任何時候都必須是可用的。一週中只允許有2分鐘當機時間。 NF：有效性
• 必須使用某排序演算法根據離開時間對航班排序。 X：這是一個設計要求

需求分析的作用

• 因為需求分析的錯誤和變更是導致軟體失敗的重要原因
• 希望對開發進行指導
• 希望開發人員對使用者的要求進行理解
• 希望使用者理解開發人員
• 測試部門有理可依

下面開始具體的瞭解需求分析

需求分析的任務和步驟

需求分析的任務

• 建立分析模型
  準確地定義未來系統的目標，確定為了滿足使用者的需求系統必須做什麼。
• 編寫需求說明
  用《需求規格說明書》規範的形式準確地表達使用者的需求。

需求分析的步驟

需求獲取
需求提煉
需求描述（撰寫需求規格說明書）
需求驗證

需求獲取

主要包含：

• 需求的來源
• 收集這些需求的方法

需求來源	需求來源
使用者目標 領域知識 投資者 執行環境 組織環境	採訪 設定情景（用例） 原型 會議 觀察商業過程和工作流

需求獲取面臨的挑戰

• 使用者說不清需求。
• 需求易變性。
• 問題的複雜性和對問題空間理解的不完備性和不一致性。

需求提煉（需求分析）

對應用問題和環境的理解和分析
將問題涉及的資訊、功能及系統行為建立模型
將使用者需求精確化、完全化
最終形成《需求規格說明書》

• 需求分析的核心在於建立分析模型。
• 需求分析採用多種形式描述需求，通過建立需求的多種檢視，揭示出一些更深的問題。
• 需求分析還包括與客戶的交流以澄清某些易混淆的問題，並明確哪些需求更為重要，其目的是確保所有風險承擔者儘早地對專案達成共識並對將來的產品有個相同而清晰的認識。

需求建模的圖形工具

型別	程式導向的需求分析	物件導向的需求分析
資料模型	實體-聯絡圖（ERD） 資料字典（DD）	類圖、類關係圖
功能模型	資料流圖（DFD）	用例圖
行為模型	狀態變遷圖（STD）	活動圖、時序圖、狀態圖

目前需求分析建模，我一般使用微軟的visio，可以自行網上搜尋下載，然後可以下載“KMSpico”這個工具進行破解。

在這些建模圖形工具中資料流圖和用例圖是最為重要的兩個需求分析建模工具。

需求規格說明書

軟體系統的需求規格說明，是對待開發系統的行為的完整描述。它包含了功能性需求和非功能性需求。

• 需求分析工作完成的一個基本標誌是形成了一份完整的、規範的需求規格說明書。
• 需求規格說明書的編制是為了使使用者和軟體開發者雙方對該軟體的初始規定有一個共同的理解，使之成為整個開發工作的基礎。

軟體需求規格說明的原則

• 從現實中分離功能，即描述要“做什麼”而不是“怎樣實現”
• 要求使用面向處理的規格說明語言（或稱系統定義語言）
• 如果被開發軟體只是一個大系統中的一個元素，那麼整個大系統也包括在規格說明的描述之中
• 規格說明必須包括系統執行環境
• 規格說明必須是一個認識模型
• 規格說明必須是可操作的
• 規格說明必須容許不完備性並允許擴充
• 說明必須區域性化和鬆散耦合

需求驗證

需求驗證的重要性：如果在後續的開發或當系統投入使用時才發現需求文件中的錯誤，就會導致更大代價的返工。

對需求文件需執行以下型別的檢查：

• 有效性檢查：檢查不同使用者使用不同功能的有效性。
• 一致性檢查：在文件中，需求之間不應該衝突。
• 完備性檢查：需求文件應該包括所有使用者想要的功能和約束。
• 現實性檢查：檢查保證能利用現有技術實現需求。