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的作用就打了折扣，還是乙個平衡問題。
關於需求跟蹤矩陣
x朋友問 做了幾年需求跟蹤，最開始用exl表，後來用工具，但是，感覺需求跟蹤和需求編寫質量 粒度等有很大關係。想請問各位，是否有跟蹤矩陣做得好的，真正用上了的。我知道哪個矩陣是有用的，但是維護和使用中容易做不下去，想看看各位都是怎麼用好它的。有什麼經驗？乙個朋友推薦 也許解決方案應該是，在詳細設計之...
需求分解與需求跟蹤矩陣
需求分解是將需求分解成乙個個的功能點。先寫出大的模組，然後子模組，然後細分成各個功能點，模組的個數名稱，子模組的層數，名稱，功能點均可維護。同時每個功能點後面還有開發人員和維護人員的記錄。開發人員和維護人員可以根據不同時期疊加。模組名稱 子模組名稱1 子模組名稱2 功能點開發人員 維護人員 備註 需...
需求分解與需求跟蹤矩陣
需求分解是將需求分解成乙個個的功能點。先寫出大的模組，然後子模組，然後細分成各個功能點，模組的個數名稱，子模組的層數，名稱，功能點均可維護。同時每個功能點後面還有開發人員和維護人員的記錄。開發人員和維護人員可以根據不同時期疊加。模組名稱 子模組名稱1 子模組名稱2 功能點 開發人員 維護人員 備註 ...