什麼是需求跟蹤矩陣RTM

2009-03-19 10:32

今天開會中聽到這個詞,一直對這種正規的軟體公司的流程,規範,管理都不是很了解,轉篇文章友善以後查閱.

1（）有什麼作用？

　　（1） 在需求變更、設計變更、代碼變更、

　　（2） RTM也是驗證需求是否得到了實作的有效工具，借助RTM，可以跟蹤每個需求的狀态：是否設計了，是否實作了，是否測試了。

　　2 需求跟蹤矩陣分為哪幾類？

　　（1） 縱向跟蹤矩陣，包括如下的3種：

　　需求之間的派生關系，客戶需求到産品需求

　　實作與驗證關系：需求到設計，需求到測試用例等

　　需求的責任配置設定關系；需求由誰來實作

　　（2） 橫向跟蹤矩陣：

　　需求之間的接口關系

　　3 在實踐中，如何把握該建立哪些RTM？

　　（1） 在SEI的調查中達成的基本共識是：縱向跟蹤是必須的，如果沒有，則 REQM SP1.4無法通過。橫向跟蹤如果不作，則是大部分實施。

　　（2） 對于縱向跟蹤矩陣：

　　必需的：

　　客戶需求與産品需求的跟蹤

　　産品需求與測試用例的跟蹤

　　100%的接口需求需要建立客戶需求-産品需求-設計-編碼-測試用例的跟蹤矩陣

　　全局性需求要建立跟蹤矩陣,包括：客戶需求-産品需求-設計-編碼-測試用例的跟蹤矩陣

　　核心需求要建立跟蹤矩陣

　　并非必需的：

　　性能需求可以不建立跟蹤矩陣

　　不影響系統架構的功能需求

　　4 需求跟蹤矩陣由誰來建立？

　　有多個角色參與建立RTM。需求開發人員負責客戶需求到産品需求的RTM建立，測試用例的編寫人員負責需求到測試用例的RTM建立，設計人員負責需求到設計的RTM的建立等等。PPQA負責檢查是否建立了RTM，是否所有的需求都被覆寫了。

　　5 RTM是否納入基線管理？

　　RTM要納入基線管理。納入基線後，每次變更都要申請，RTM的變更一般是和

　　6 如何簡化RTM的

　　由于在RTM中，需求可能有很多項，設計、測試用例、代碼等都有多項，是以建立和維護RTM的工作量還是比較大、比較煩瑣。對于變化頻繁的項目，更是如此。在實踐中，為了簡化該RTM的建立與維護工作，有的企業僅僅通過需求與設計、代碼、測試用例的編号來實作跟蹤，如需求為：r1,r2,……等編号，而設計的編号為：r1-d1,r1-d2,…….,測試用例的編号為：r1-t1,r1-t2等等。需要注意的是需求與它們之間是多對多的關系，僅通過編号是無法實作這種關系的。如果不借助DOORS之類的

　　當然也可以考慮增大需求、設計、代碼、測試用例的顆粒度大小，但是那樣RTM的作用就打了折扣，還是一個平衡問題。