關於需求跟蹤矩陣的6個問題

2021-08-24 22:18:41 字數 1395 閱讀 7069

1 需求跟蹤矩陣(rtm)有什麼作用?

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

(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的變更一般是和其他配置項的變更一起申請,很少單獨申請變更rtm,除非rtm有錯誤。

6 如何簡化rtm的工作?

由於在rtm中,需求可能有很多項,設計、測試用例、**等都有多項,所以建立和維護rtm的工作量還是比較大、比較煩瑣。對於變化頻繁的專案,更是如此。在實踐中,為了簡化該rtm的建立與維護工作,有的企業僅僅通過需求與設計、**、測試用例的編號來實現跟蹤,如需求為:r1,r2,……等編號,而設計的編號為:r1-d1,r1-d2,…….,測試用例的編號為:r1-t1,r1-t2等等。需要注意的是需求與它們之間是多對多的關係,僅通過編號是無法實現這種關係的。 如果不借助doors之類的需求管理工具,一般只能通過excel來維護rtm,工作量就是比較大。要簡化,就要平衡管理的投入與產出,平衡時,可以借鑑上面的問題3。

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

關於需求跟蹤矩陣的6個問題

1 需求跟蹤矩陣 rtm 有什麼作用?1 在需求變更 設計變更 變更 測試用例變更時,需求跟蹤矩陣是目前經過實踐檢驗的進行變更波及範圍影響分析的最有效的工具,如果不借助rtm,則發生上述變更時,往往會遺漏某些連鎖變化。2 rtm也是驗證需求是否得到了實現的有效工具,借助rtm,可以跟蹤每個需求的狀態...

關於需求跟蹤矩陣

x朋友問 做了幾年需求跟蹤,最開始用exl表,後來用工具,但是,感覺需求跟蹤和需求編寫質量 粒度等有很大關係。想請問各位,是否有跟蹤矩陣做得好的,真正用上了的。我知道哪個矩陣是有用的,但是維護和使用中容易做不下去,想看看各位都是怎麼用好它的。有什麼經驗?乙個朋友推薦 也許解決方案應該是,在詳細設計之...

例說需求跟蹤矩陣的作用

9月21日,我作為外部的專家參加了乙個客戶的測試用例評審會議,該測試用例文件在開此評審會議之前曾經在測試組進行了內部評審。與會的評審專家包括了 2個專案的需求與開發人員,3個測試人員,2名qa人員,1名外部的諮詢顧問。會議開始,由作者對照測試用例文件開始講解每個測試用例,會議的專家對這些用例進行評判...