需求跟蹤矩陣(需求跟蹤矩陣實例)

什么是需求跟蹤矩陣RTM

需求跟蹤矩陣是一種主要管理需求變更和驗證需求是否得到了實現的有效工具，借助RTM，可以跟蹤每個需求的狀態。

需求跟蹤矩陣是把產品需求從其來源連接到能滿足需求的可交付成果的一種表格。使用需求跟蹤矩陣， 可以把每個需求與業務目標或項目目標聯系起來， 有助于確保每個需求都具有商業價值。

需求跟蹤矩陣提供了在整個項目生命周期中跟蹤需求的一種方法，有助于確保需求文件中被批準的每項需求在項目結束的時候都能交付。最后， 需求跟蹤矩陣還為管理產品范圍變更提供了框架。

擴展資料

需求跟蹤矩陣的作用主要包括：

1、在需求變更、設計變更、代碼變更、測試用例變更時，需求跟蹤矩陣是目前經過實踐檢驗的進行變更波及范圍影響分析的最有效的工具。如果不借助需求跟蹤矩陣，則發生上述變更時，往往會遺漏某些連鎖變化；

2、需求跟蹤矩陣也是驗證需求是否得到實現的有效工具?？梢愿櫭總€需求的狀態，是否設計了，是否實現了，是否測試了；

3、如果建立了需求跟蹤矩陣，我們對照需求跟蹤矩陣進行測試用例的評審，則會更加方便。同時，作者本人很容易在評審之前就發現未被測試用例覆蓋的需求。

參考資料來源：百度百科-需求跟蹤矩陣

需求跟蹤矩陣更新的時機

需求跟蹤矩陣更新的時機：在相關階段評審結束后更新。

使用需求跟蹤矩陣跟蹤需求需要遵循的檢查和步驟：

1、瀏覽矩陣中的需求數目和需求文檔中的需求，確保矩陣中列出了所有的需求，沒有遺漏。

2、為確保在矩陣中列出的所有程序在最終的軟件中都是必要的，并且沒有冗余的代碼，必須在矩陣中指出每個程序、類和其他單元。

3、通過確保功能需求沒有空白列來檢查需求的實現。

4、對每個性能需求，都應該設計一些測試用例。

5、集成和系統測試用例可以和矩陣一起進行交叉檢查，以此來保證需求的所有條件都包含在系統測試用例中。

需求跟蹤矩陣模板：

需求跟蹤矩陣的分類

（1） 縱向跟蹤矩陣，包括如下的3種：
需求之間的派生關系，客戶需求到產品需求
實現與驗證關系：需求到設計，需求到測試用例等
需求的責任分配關系；需求由誰來實現
（2） 橫向跟蹤矩陣：
需求之間的接口關系
在實踐中，如何把握該建立哪些RTM
（1） 在SEI的調查中達成的基本共識是：縱向跟蹤是必須的，如果沒有，則 REQM SP1.4無法通過。橫向跟蹤如果不作，則是大部分實施。
（2） 對于縱向跟蹤矩陣：
必需的：
客戶需求與產品需求的跟蹤
產品需求與測試用例的跟蹤 100%的接口需求需要建立客戶需求-產品需求-設計-編碼-測試用例的跟蹤矩陣
全局性需求要建立跟蹤矩陣,包括：客戶需求-產品需求-設計-編碼-測試用例的跟蹤矩陣
核心需求要建立跟蹤矩陣
并非必需的：
性能需求可以不建立跟蹤矩陣
不影響系統架構的功能需求

需求跟蹤矩陣的如何簡化

由于在需求跟蹤矩陣中，需求可能有很多項，設計、測試用例、代碼等都有多項，所以建立和維護RTM的工作量還是比較大、比較煩瑣。對于變化頻繁的項目，更是如此。 在實踐中，為了簡化該RTM的建立與維護工作，有的企業僅僅通過需求與設計、代碼、測試用例的編號來實現跟蹤，如需求為：r1,r2,……等編號，而設計 的編號為：r1-d1,r1-d2,…….,測試用例的編號為：r1-t1,r1-t2等等。需要注意的是需求與它們之間是多對多的關系，僅通過編號是無 法實現這種關系的。 如果不借助DOORS之類的需求管理工具，一般只能通過EXCEL來維護RTM，工作量就是比較大。要簡化，就要平衡管理的投入與產出，平衡時，可以借鑒 上面的問題3。
當然也可以考慮增大需求、設計、代碼、測試用例的顆粒度大小，但是那樣RTM的作用就打了折扣，還是一個平衡問題。
在CMM三級中要求軟件團體必須具備需求跟蹤的能力：“在軟件工作產品之間，維護一致性。工作產品包括軟件計劃，過程描述，分配需求，軟件需求，軟件設計，代碼，測試計劃，以及測試過程?！?br />需求跟蹤矩陣并沒有規定的實現辦法，每個團體注重的方面不同，所創建的需求跟蹤矩陣也不同，只要能夠保證需求鏈的一致性和狀態的跟蹤就達到目的了。

如何制定一份有效需求跟蹤矩陣表

以下是我目前準備重新制定需求跟蹤矩陣設計的時候分析:
說明：需求階段，我們的輸出產物為：業務需求說明書、用戶需求說明書、功能設計說明書
1、相關涉眾：項目經理、需求分析師、設計師、軟件工程師、測試工程師、客戶
2、用例統計：需求總數、模塊總數、變更總數、用例總數
3、需求變更類型：新增、遺漏、修改
4、需求跟蹤矩陣表中的設計元素：（以對應角色關注點列出，有部分共同關注點沒有單獨列出）
項目經理：返工量評估、評估變更風險、質量影響、糾正措施、跟蹤結果、跟蹤人
需求分析師：需求用例ID、用戶需求說明書、需求穩定性、需求優先級、變更相關涉眾（一般指客戶）、關聯模塊、需求維護人（具體需求分析師，針對變更）、需求 變更類型、驗收標準
設計師：功能設計ID、功能設計說明書、技術難度（評估）、設計維護人
開發工程師：工作量反饋、修改人、單元測試用例ID（鏈接）
測試工程師：測試用例ID（鏈接）、測試用例說明書、用例維護人
以上字段是我打算設計使用的字段，請大家幫忙指點，看是否有遺漏或不妥之處。
此次交流期望：想得到一份比較簡單但執行效率高的需求跟蹤矩陣。