軟件需求
軟件需求：是指用戶對系統在功能、行為、性能、設計約束等方面的期望。是指用戶解決問題或達到目的所需要的條件或者能力，是系統或系統部件要滿足合同、標準、規范或其他正式規定文檔所需具有的條件或者能力，以及放映這些條件或能力的文檔說明。
軟件需求管理分為需求開發和需求管理兩大過程。
業務需求：
用戶需求：
系統需求：
1）功能需求：
2）非功能需求：
3）設計約束：
質量功能部署（QFD）是
需求獲取
需求獲取是一個確定和理解不同的項目干系人的需求和約束的過程。
常見的需求后去方法包括：
1）用戶訪談：
2）問卷調查：
3）采樣
4）情節串聯版
5）聯合需求計劃（JRP）
6）需求記錄技術
需求分析
需求分析：一個好的需求應該具有無二性、完整性、一致性、可測試性、確定性、可跟蹤性、正確性、必要性等特性，因此，需求分析人員要把雜亂無章的用戶要求和期望轉化為用戶需求，這就是需求分析的工作。
需求分析的任務
1）繪制系統上下文范圍關系圖
2）創建用戶界面原型
3）分析需求的可行性
4）確定需求優先級
5）為需求建立模型
6）創建數據字典
7）使用QFD（質量功能部署）
結構化的需求分析
結構化特點：自頂向下、逐步分解、面向數據。
三大模型：功能模型（數據流圖）、行為模型（狀態轉化圖）、數據模型（E-R圖）以及數據字典。
狀態流轉圖STD
數據流圖描述數據在系統中如何被傳送或變化，以及如何對數據流進行變化的功能或子功能，用于對功能建模，數據流圖相關概念如圖：
數據流圖是可以分層的，從頂層（即上下文無關數據流）到0層、1層等，頂層數據流圖只含有一個加工處理整個管理信息系統，描述了系統的輸入和輸出，以及和外部實體的數據交互。數據流圖示例如下：
1）對象
2）類
3）抽象
4）封裝
5）繼承
6）多態
7）接口
8）消息
9）覆蓋
10）函數重載
11）綁定
面向對象的分析
面向對象的分析是為了確定問題域，理解問題。包含五個活動：認定對象、組織對象、描述對象間的相互作用、確定對象的操作、定義對象的內部信息。
面向相對需求建模：
統一建模語言UML
UML（統一建模語言）是一種可視化的建模語言，而非程序設計語言，支持從需求分析開始的軟件開發的全過程
從總體上來看，UML的結構包括結構塊、規則和公共機制三個部分。
1）構造塊：UML有三種接觸的構造塊，分別是事物、關系和圖。事物是UML的重要組成部分，關系把事物緊密聯系在一起，圖是過個相互關聯的事物的集合。
2）公共機制：公共機制是指達到特定目標的公共UML方法。
3）規則：規則是構造塊如何放在一起的規定。
事物分為：
結構事物
行為事物
分組事物
注釋事務
關系：
依賴
關聯
泛化
實現
UML 4+1視圖
1）邏輯視圖：邏輯視圖也稱為設計視圖，它表示了設計模型中在架構方面具有重要意義的部分，即類、子系統、包和用例實現的子集。
2）進程視圖：進程視圖是可行性線程和進程作為活動類的建模，它是邏輯視圖的一次執行實例，描述了并發和同步結構。
3）實現視圖：實現視圖對組成基于系統的物理代碼的文件和構建進行建模。
4）部署視圖：部署視圖把構件部署到一組物理節點上，表示軟件到硬件的映射和分部結構。
5）用例視圖：用例視圖就是最基本的需求分析模型。
需求定義
需求定義（軟件需求規格說明書SRS）是需求開發活動的產物，編制該文檔的目的是使項目干系人與開發團隊對系統的初始規定有一個共同的理解，使之成為整個開發工作的基礎。SRS是軟件開發過程中最重要的文檔之一，對于任何規模和性質的軟件項目都不應該缺少。
需求定義方法：
1）嚴格定義也稱為預先定義，需要的嚴格定義建立在以下基本假設之上。所有需求都能夠被預先定義。開發人員與用戶之間能夠準確且清晰地交流，采用圖形或文字可以充分體現最終系統
2）原型方法：迭代的循環型開發方式。需要注意的問題：并非所有的需求都能夠在系統開發前被準確地說明。項目干系人之間通常存在交流上的困難，原型提供了克服空難的一個手段。特點：需要實際的，可供用戶參考的系統模型。有合適的系統開發方法環境。反復是完全需求和值得提倡的，需求一旦確定就應遵從嚴格的方法。
需求驗證
需求驗證也稱為需求確認，目的是與用戶一起確認需求無誤。對需求規格說明書SAS進行評審和測試，包括兩個步驟：
1）需求評審：正式評審和非正式評審
2）需求測試：設計概念測試用例
需求驗收通過后要請用戶簽字確認，作為驗收標準之一，此時，這個需求規格說明書就是需求基線，不可以隨意更新，如果需要更改必須要走需求變更流程。
需求管理
定義需求基線：通過了評審的需求說明書就是需求基線。
需求變更和風險：主要關系需求變更過程中的需求風險管理，帶有風險的做法有：無足夠用戶參與、忽略了用戶分類、用戶需求的不斷增加、模棱兩可的需求、不必要的特性、過于精簡的SRS、不確定的估算。
變更產生的原因：外部環境的變化，需求和設計做的不夠完整、新技術的出現、公司機構重組造成業務流程的變化。
變更控制委員會CCB：也稱為變更控制委員會，其任務是對建議的配置變更做出評價、審批，以及監督已經批準變更的實施。
需求跟蹤
雙向跟蹤兩個層次如下：
正向跟蹤表示用戶原始需求是否都實現了，反向跟蹤表示軟件實現的是否都是用戶要求的，不多不少，可以用原始需求和用例表格（需求跟蹤矩陣）來表示。
