作用
（1） 在需求變更、設計變更、代碼變更、測試用例變更時，需求跟蹤矩陣是目前經過實踐檢驗的進行變更波及範圍影響分析的最有效的工具，如果不藉助RTM，則發生上述變更時，往往會遺漏某些連鎖變化。
（2） RTM也是驗證需求是否得到了實現的有效工具，藉助RTM，可以跟蹤每個需求的狀態：是否設計了，是否實現了，是否測試了。
分類
（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三級中要求軟體團體必須具備需求跟蹤的能力：“在軟體工作產品之間，維護一致性。工作產品包括軟體計畫，過程描述，分配需求，軟體需求，軟體設計，代碼，測試計畫，以及測試過程。”
需求跟蹤矩陣並沒有規定的實現辦法，每個團體注重的方面不同，所創建的需求跟蹤矩陣也不同，只要能夠保證需求鏈的一致性和狀態的跟蹤就達到目的了。
建立角色
有多個角色參與建立RTM。需求開發人員負責客戶需求到產品需求的RTM建立，測試用例的編寫人員負責需求到測試用例的RTM建立，設計人員負責需求到設計的RTM的建立等等。PPQA負責檢查是否建立了RTM，是否所有的需求都被覆蓋了。
需求跟蹤矩陣是否納入基線管理
需求跟蹤矩陣要納入基線管理。納入基線後，每次變更都要申請，RTM的變更一般是和其他配置項的變更一起申請，很少單獨申請變更RTM，除非RTM有錯誤。
