作用
（1）在需求變更、設計變更、代碼變更、測試用例變更時，需求跟蹤矩陣是目前經過實踐檢驗的進行變更波及範圍影響分析的最有效的工具，如果不借助RTM，則發生上述變更時，往往會遺漏某些連鎖變化。
（2）RTM也是驗證需求是否得到了實現的有效工具，借助RTM，可以跟蹤每個需求的狀态：是否設計了，是否實現了，是否測試了。
分類
（1）縱向跟蹤矩陣，包括如下的3種：
需求之間的派生關系，客戶需求到産品需求。
實現與驗證關系：需求到設計，需求到測試用例等。
需求的責任分配關系；需求由誰來實現。
（2）橫向跟蹤矩陣：
需求之間的接口關系。
在實踐中，如何把握該建立哪些RTM（1）在SEI的調查中達成的基本共識是：縱向跟蹤是必須的，如果沒有，則REQM SP1.4無法通過。橫向跟蹤如果不作，則是大部分實施。
（3）對于縱向跟蹤矩陣，必需的：
客戶需求與産品需求的跟蹤。
産品需求與測試用例的跟蹤100%的接口需求需要建立客戶需求-産品需求-設計-編碼-測試用例的跟蹤矩陣。
全局性需求要建立跟蹤矩陣,包括：客戶需求-産品需求-設計-編碼-測試用例的跟蹤矩陣。
核心需求要建立跟蹤矩陣。
并非必需的：
性能需求可以不建立跟蹤矩陣。
不影響系統架構的功能需求。
如何簡化
由于在需求跟蹤矩陣中，需求可能有很多項，設計、測試用例、代碼等都有多項，所以建立和維護RTM的工作量還是比較大、比較煩瑣。對于變化頻繁的項目，更是如此。雖然與信息檢索（IR）方法相比,基于本體的動态需求跟蹤方法能提高跟蹤鍊的精度,但構建一個合理、有效的本體特别是領域本體是一個相當複雜和繁瑣的過程。
在實踐中，為了簡化該RTM的建立與維護工作，有的企業僅僅通過需求與設計、代碼、測試用例的編号來實現跟蹤，如需求為：r1,r2,等編号，而設計的編号為：r1-d1,r1-d2,測試用例的編号為：r1-t1,r1-t2等等。需要注意的是需求與它們之間是多對多的關系，僅通過編号是無法實現這種關系的。
如果不借助DOORS之類的需求管理工具，一般隻能通過EXCEL來維護RTM，工作量就是比較大。要簡化，就要平衡管理的投入與産出，平衡時，可以借鑒上面的問題。
當然也可以考慮增大需求、設計、代碼、測試用例的顆粒度大小，但是那樣RTM的作用就打了折扣，還是一個平衡問題。
在CMM三級中要求軟件團體必須具備需求跟蹤的能力：“在軟件工作産品之間，維護一緻性。工作産品包括軟件計劃，過程描述，分配需求，軟件需求，軟件設計，代碼，測試計劃，以及測試過程。”
需求跟蹤矩陣并沒有規定的實現辦法，每個團體注重的方面不同，所創建的需求跟蹤矩陣也不同，隻要能夠保證需求鍊的一緻性和狀态的跟蹤就達到目的了。
建立角色
有多個角色參與建立RTM。需求開發人員負責客戶需求到産品需求的RTM建立，測試用例的編寫人員負責需求到測試用例的RTM建立，設計人員負責需求到設計的RTM的建立等等。PPQA負責檢查是否建立了RTM，是否所有的需求都被複蓋了。
需求跟蹤矩陣要納入基線管理。納入基線後，每次變更都要申請，RTM的變更一般是和其他配置項的變更一起申請，很少單獨申請變更RTM，除非RTM有錯誤。
