軟件--需求管理

一個好的軟件件必定離不開嚴格的需求管理過程！

今天給你們介紹的就是需求管理！

衆所周知，軟件並非憑空產生的，有了需求，纔會催生出相應的軟件產品！全部生產軟件的項目組纔會如此的重視軟件的需求管理過程，這一個過程叫作需求工程。

1、瞭解軟件需求工程的過程

需求工程流程圖

 SRS（軟件需求規格說明書）：軟件需求說明書的編制是爲了使用戶和軟件開發者雙方對該軟件的初始規定有一個共同的理解， 使之成爲整個開發工做的基礎。包含硬件、功能、性能、輸入輸出、接口需求、警示信息、保密安全、數據與數據庫、文檔和法規的要求等等。

 

可行性分析過程

需求導出和分析過程

這之中的需求檢查過程尤其重要，需求檢查的內容以下

1. 有效性檢查
根據不一樣的用戶須要肯定不一樣的功能，因此要在不一樣用戶中協商系統功能，保證功能的有效性。
2. 一致性 檢查
在文檔中不該該有衝突，即同一個功能在同一系統中不能有不一樣描述或相互
矛盾的約束。
3. 完備性 檢查
需求文檔中應該包含全部用戶所須要的功能和約束。
4. 現實性檢查 ：
對已有技術的瞭解，檢查需求以保證能利用現有技術實現。
5. 可檢驗性檢查：
爲了不減小客戶和開發商的爭議，開發的系統應該能夠設計一些能夠檢驗交付的系統是否知足需求。

 

需求管理

①得到對需求的理解。在初步整理需求的基礎上，項目小組和用戶表明經過初步的分析討論，對當前
項目的需求達成共識，並在需求列表中做相應記錄。
②獲取需求承諾。經過項目參與者的書面承諾，創建各方或各項工做的基準。
③管理需求變動。維護變動歷史，爲調整與控制提供數據。
④在需求變動後維護對需求的雙向可追溯性。從軟件可維護性的角度提出管理要求。
⑤標識項目工做(包括計劃和產品)與需求的不一致性。若發現不一致性，即啓動糾正措施。

 

2、需求評審會議

開需求評審的目的是爲了更快捷高效的討論並解決軟件需求的相關問題，便於後期的軟件開發工做。

參與會議的人員以下圖

參與人員並非固定的，根據公司具體要求配置（一般都包含需求、開發、測試人員）

 需求評審會議的流程

 

 

3、測試需求分析---測試人員的工做

瞭解測試軟件產品的質量標準：GB/T（推薦性國家標準）；ISO（國際標準）

 

軟件產品的質量模型：一組特性及特性之間的關係，它提供規定質量需求和評價軟件產品質量的基礎。

 

 測試需求分析：瞭解軟件質量特性，測試工程師需進行需求分析定義測試範圍，明確測試項和測試子項，以便後續設計測試用例

測試需求分析的過程：
1.根據需求規格提取獨立的功能點，肯定測試範圍；
2.對獨立功能進行分析，肯定各獨立功能的測試點；
3.對業務場景即功能組合進行分析，提供業務場景的測試點；
4.對非功能特性進行分析，瞭解須要測試的非功能特性；
5.針對系統級接口進行分析，瞭解被測試對象、測試規格。
分析可測性，肯定測試方法、工具。

 

測試需求分析的方法：

三步法：調用原始測試需求分析-->編寫測試項---->編寫測試子項

 

測試項、測試子項的概念：

測試項：做爲測試對象的工做版本。

測試子項：是對測試項的細分。

舉例

 

 

4、需求跟蹤矩陣（RTM）

定義：是一種主要管理需求變動和驗證需求是否獲得了實現的有效工具，能夠跟蹤每一個需求的狀態。

做用：

（1） 在需求變動、設計變動、代碼變動、測試用例變動時，需求跟蹤矩陣是目前通過實踐檢驗的進行變動波及範圍影響分析的最有效的工具，若是不借助RTM，則發生上述變動時，每每會遺漏某些連鎖變化。
（2） RTM也是驗證需求是否獲得了實現的有效工具，藉助RTM，能夠跟蹤每一個需求的狀態：是否設計了，是否實現了，是否測試了。