3.1 需求分析
確定系統必須具有的功能和性能，系統要求的運行環境，並且預測系統發展的前景。
即以一種清晰、簡潔、一致且無二義性的方式，對一個待開發系統中各個有意義方面的陳述的一個集合。
需求分析的任務
▪ 建立分析模型【過程第二步】
准確地定義未來系統的目標，確定為了滿足用戶的需求系統必須做什么
內含兩種模型：面向對象、面向過程的模型
▪編寫需求說明【過程第三步】
用《需求規格說明書》規范的形式准確地表達用戶的需求。
需求分析/管理的過程
分為需求確認、需求變更。
需求確認又可以細分為：需求獲取——需求提煉——需求描述——需求驗證。
需求確認
第一步：需求獲取
需求的獲取
也稱為需求抓取、需求發現和需求獲得。
► 軟件需求的來源
►軟件工程師收集這些軟件需求的方法。
需求的類型
功能性需求
描述系統應該做什么，即為用戶和其它系統完成的功能、提供的服務。
非功能需求
必須遵循的標准，外部界面的細節，實現的約束條件，質量屬性等等
需求的來源
-
用戶目標
-
領域知識
-
投資者
-
運行環境
-
組織環境
需求獲取技術
-
采訪
-
設定情景（用例）
-
原型
-
會議
-
觀察商業過程和工作流
需求獲取面臨困難
為什么軟件系統分析員的工資要比普通程序員高？就是因為需求分析困難嘛
- 客戶說不清楚需求
- 需求自身經常變動【沒有一個軟件的需求改動少於三次】
- 分析人員或客戶理解有誤【客戶表達的需求，不同的分析人員可能有不同的理解。——（1）盡可能地分析清楚哪些是穩定的需求，哪些是易變的需求。以便在進行系統設計時，將軟件的核心建築在穩定的需求上。（2）在合同中一定要說清楚“做什么”和“不做什么”。】
獲取需求誘導十原則
- 傾聽
- 有准備的溝通
- 需要有人推動
- 最好當面溝通
- 記錄所有決定
- 保持通力協作
- 聚焦並協調話題
- 采用圖形表示
- 繼續前進原則
- 談判雙贏原則
第二步：需求提煉（需求分析）
▪對應用問題及環境的理解和分析，為問題涉及的信息、功能及系統行為建立模型。
▪將用戶需求精確化、完全化，最終形成下一步的需求規格說明書。
-
該過程的核心在於建立分析模型。
-
采用多種形式描述需求，通過建立需求的多種視圖，揭示出一些更深的問題。
-
還包括與客戶的交流以澄清某些易混淆的問題，並明確哪些需求更為重要，其目的是確保所有風險承擔者盡早地對項目達成共識並對將來的產品有個相同而清晰的認識。
需求分析模型
第三步：需求規格說明書
軟件需求規格說明書（SRS）------軟件系統的需求規格說明，是對待開發系統的行為的完整描述。
它包含了功能性需求和非功能性需求的說明。
需求分析工作完成的一個基本標志是形成了一份完整的、規范的需求規格說明書。
需求規格說明書的編制是為了使用戶和軟件開發者雙方對該軟件的初始規定有一個共同的理解，使之成為整個開發工作的基礎。
一、溝通活動通用任務集
1、識別主要客戶和共同利益者
2、與主要客戶會談“上下文無關的問題”，以確定
①業務需要和商業價值
②最終用戶的特性\需要
③需要的用戶可見輸出
④業務約束
3、寫一頁項目范圍的說明
4、評審范圍說明，並應客戶要求做出相應修改
5、與客戶/最終用戶進行協作，確定：
①采用標准格式記錄客戶可見的使用場景
②輸入和輸出
③重要的軟件特性、功能和行為
④客戶定義的商業風險
6、描述場景、輸入/輸出、特性/功能以及風險
7、與客戶細化場景、輸入/輸出、特性/功能以及風險
8、為每個用戶場景、特性、功能和行為分配客戶定義的優先級
9、回顧搜集的所有信息並修訂
10、為計划活動做准備
二、軟件需求規格說明的原則
-
從現實中分離功能，即描述要“做什么”而不是“怎樣實現”
-
要求使用面向處理的規格說明語言（或稱系統定義語言）
-
如果被開發軟件只是一個大系統中的一個元素，那么整個大系統也包括在規格說明的描述之中
-
規格說明必須包括系統運行環境
-
規格說明必須是一個認識模型
-
規格說明必須是可操作的
-
規格說明必須容許不完備性並允許擴充
-
規格說明必須局部化和松散耦合
三、軟件需求規格說明的結構
（1）引言
a. 需求文檔的目的
b. 文檔約定
c. 預期的讀者和閱讀建議
d. 產品范圍
e. 參考文獻
（2）綜合描述
a. 產品前景
b. 產品功能與優先級
c. 用戶特征
d. 運行環境
e. 設計與實現上的限制
f. 假設和依賴性
（3）需求描述
a. 功能需求
b. 數據需求：與功能有關的數據定義和數據關系
c. 性能需求：響應時間、容量要求、用戶數等
d. 外部接口：用戶界面、軟硬件接口、通信接口
e. 設計約束：軟件支持環境、報表、數據命名等
f. 軟件質量屬性（可維護性、可靠性、可移植性、可用性、安全性等）**
g. 其他需求
這一節需求描述是文檔中最實質性的部分，由於在機構組織的實踐中存在極大的變數，對這一節定義的標准結構可以進行增刪。
（4）附錄（詞匯表、分析模型、待定問題列表）
（5）索引
第四步：需求驗證
需求驗證的重要性：如果在后續的開發或當系統投入使用時才發現需求文檔中的錯誤，就會導致更大代價的返工。
需求驗證的工作
對需求文檔需執行以下類型的檢查：
（1）有效性檢查
檢查不同用戶使用不同功能的有效性。
（2）一致性檢查
在文檔中，需求之間不應該沖突。
（3）完備性檢查
需求文檔應該包括所有用戶想要的功能和約束。
（4）現實性檢查
檢查保證能利用現有技術實現需求。
需求驗證技術
（1）需求評審
（2）利用原型檢驗系統是否符合用戶的真正需要
（3）對每個需求編寫概念性的測試用例。
（4）編寫用戶手冊。用淺顯易懂的語言描述用戶可見的功能。
（5）自動的一致性分析。可用CASE工具檢驗需求模型的一致性。
需求變更
