1. 什么是TM(Tracking Matrix)

?????? A Traceability Matrix is a document that co-relates any two-baseline documents that require a many-to-many relationship to check the completeness of the relationship.It is used to track the requirements and to check the current project requirements are met.
?????? 可追溯性矩陣是一個文檔拖叙，它與需要多對多關系的任何兩個基線文檔進行關聯(lián)相寇，以檢查關系的完整性。它用于跟蹤需求并檢查是否滿足當前項目需求。

2. 什么是RTM(Requirement Tracking Matrix)

?????? Requirement Traceability Matrix (RTM) is a document that maps and traces user requirement with test cases. It captures all requirements proposed by the client and requirement traceability in a single document, delivered at the conclusion of the Software devlopement life cycle. The main purpose of Requirement Traceability Matrix is to validate that all requirements are checked via test cases such that no functionality is unchecked during Software testing.

?????? 需求跟蹤矩陣（RTM）是用于通過測試用例映射和跟蹤用戶需求的文檔蓬痒。它在軟件部署生命周期結(jié)束時提供的單個文檔中捕獲了客戶提出的所有需求和需求可追溯性。需求跟蹤矩陣的主要目的是驗證是否通過測試用例檢查了所有需求淑趾，以便在軟件測試期間不取消任何功能吱殉。

?????? 需求跟蹤矩陣，簡稱RTM珊拼；Throughout the project Lifecycle list of project and product deliverables are created and these are developed based on agreed project & product requirements.（在整個項目中食呻，將創(chuàng)建項目和產(chǎn)品可交付成果的生命周期清單，并根據(jù)商定的項目和產(chǎn)品需求來開發(fā)這些清單）

3. 作用

1. 確保100％的測試覆蓋率澎现。
2. 顯示需求/文檔不一致仅胞。
3. 顯示整體缺陷/執(zhí)行狀態(tài)，重點放在業(yè)務需求上剑辫。
4. 如果要更改某些業(yè)務和/或功能要求干旧，則TM可以通過重新測試/重用測試用例來幫助估計或分析對QA團隊工作的影響。

保證了需求到實現(xiàn)的無遺漏和偏離妹蔽。
* 需要注意的重要一點是椎眯，維護和更新需求跟蹤矩陣的方式?jīng)Q定了其使用的有效性挠将。如果不經(jīng)常更新或更新不正確，該工具將成為負擔而不是幫助盅视，并給人留下這樣的印象：該工具本身不值得使用捐名。

4. 分類

4.1 縱向跟蹤矩陣

?????? Vertical traceability identifies the origin of items (e.g., customer needs) and follows these same items as they travel through the hierarchy of the Work Breakdown Structure to the project teams and eventually to the customer. When the requirements are managed well, traceability can be established from the source requirement to its lower level requirements and from the lower level requirements back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements can be traced to a valid source.

?????? “縱向跟蹤”是指從其最初的來源（如：客戶需求），通過不同層次的工作分解結(jié)構(gòu)得以實現(xiàn)同樣的內(nèi)容闹击，并最終交付給客戶的過程镶蹋。在需求被很好的管理的情況下，跟蹤性可以通過從初始需求對應到低級別需求赏半，以及從低級別的需求回溯到其根源來建立贺归。這樣的雙向可追溯性有助于確定所有初始需求已完全實現(xiàn)，并且所有較低級別的需求可以追溯到一個有效的來源上断箫。包括三種關系：

1. 需求之間的派生關系拂酣，客戶需求到產(chǎn)品需求。
2. 實現(xiàn)與驗證關系：需求到設計仲义，需求到測試用例等婶熬。
3. 需求的責任分配關系；需求由誰來實現(xiàn)埃撵。

4.2 橫向跟蹤矩陣

?????? Horizontal traceability is also important and is mentioned in subpractice 3, but it is not required to satisfy bidirectional traceability. Horizontal traceability identifies the relationships among related items across work groups or product components for the purpose of avoiding potential conflicts. It enables the project to anticipate potential problems (and mitigate or solve them) before integration testing. For example, horizontal traceability would follow related requirements across two work groups working on two associated components of a product. The traceability across these two work groups enables the work groups to see when and how a change in a requirement for one of the components may affect the other component. Thus, horizontal traceability enables the project to anticipate potential problems (and mitigate or solve them) before integration testing.

?????? "水平跟蹤”也是很重要的赵颅，在REQM的subpractice 3中提到 ，但它并不是需要滿足雙向可追溯性的必要條件暂刘〗让“水平跟蹤”通過識別相關的工作組、產(chǎn)品組件的關系來避免潛在的沖突谣拣。這使項目可以在集成測試之前預計可能出現(xiàn)的問題（并且減輕或解決這些問題）募寨。例如，同一個產(chǎn)品的兩個相關部件森缠，由兩個工作組根據(jù)同一份需求分別負責拔鹰。當一個組件對應的需求發(fā)生改變時，可能會影響到另一個組件贵涵。橫跨兩個組件的需求跟蹤就能及時發(fā)現(xiàn)列肢、規(guī)避或解決這些問題。因此独悴，“水平跟蹤”使項目可以在集成測試之前預計可能出現(xiàn)的問題（并且減輕或解決這些問題）。

?????? 主要關注的就是“需求之間的接口關系”锣尉。

5. RTM參數(shù)

5.1. 基本參數(shù)

• Requirement ID（需求編號）
• Requirement Type and Description（需求類型和說明）
• Test Cases with Status（具有狀態(tài)的測試用例）

例如：

5.2. 典型軟件開發(fā)項目基本參數(shù)

如上所述晒喷，需求跟蹤矩陣可以:

• 在測試用例數(shù)量中顯示需求覆蓋率
• 特定測試用例的設計狀態(tài)和執(zhí)行狀態(tài)
• 如果用戶要做任何用戶驗收測試，那么 UAT 狀態(tài)也可以在同一矩陣中捕獲访敌。
• 相關的缺陷和當前狀態(tài)也可以在同一矩陣中提及凉敲。

這種矩陣將為所有測試活動提供一站式服務。
除了單獨維護一個 excel寺旺。測試團隊也可以選擇需求跟蹤可用的測試管理工具爷抓。

6. 組成部分

6.1 向前追溯(Forward traceability)

?????? This matrix is used to check whether the project progresses in the desired direction and for the right product. It makes sure that each requirement is applied to the product and that each requirement is tested thoroughly. It maps requirements to test cases.

?????? 該矩陣用于檢查項目是否朝著期望的方向發(fā)展，是否為正確的產(chǎn)品發(fā)展阻塑。它確保每個要求都適用于產(chǎn)品蓝撇，并且每個要求都經(jīng)過徹底測試。它將需求映射到測試用例陈莽。

6.2 向后追溯(Backward or reverse traceability)

?????? It is used to ensure whether the current product remains on the right track. The purpose behind this type of traceability is to verify that we are not expanding the scope of the project by adding code, design elements, test or other work that is not specified in the requirements. It maps test cases to requirements.

?????? 用于確保當前產(chǎn)品是否保持在正確的軌道上渤昌。這種可追溯性背后的目的是驗證我們沒有通過添加代碼、設計元素走搁、測試或其他需求中未指定的工作來擴大項目范圍独柑。它將測試用例映射到需求。

6.3 雙向追溯(Bi-directional traceability)

?????? This traceability matrix ensures that all requirements are covered by test cases. It analyzes the impact of a change in requirements affected by the Defect in a work product and vice versa.

?????? 此可追溯性矩陣確保測試用例涵蓋了所有要求朱盐。它分析了受工作產(chǎn)品缺陷影響的需求變化的影響群嗤，反之亦然。

7. 由誰來創(chuàng)建RTM?

• 需求開發(fā)人員負責客戶需求到產(chǎn)品需求的RTM建立兵琳。
• 測試用例的編寫人員負責需求到測試用例的RTM建立狂秘。
• 設計人員負責需求到設計的RTM的建立等等。
• PPQA（過程與產(chǎn)品質(zhì)量保證）負責檢查是否建立了RTM躯肌，是否所有的需求都被覆蓋了者春。

8. RTM是否納入基線管理？

?????? RTM要納入基線管理清女。納入基線后钱烟，每次變更都要申請，RTM的變更一般是和其他配置項的變更一起申請嫡丙，很少單獨申請變更RTM拴袭，除非RTM有錯誤。

9. 在實踐中曙博，如何把握該建立哪些RTM拥刻？

1. 在SEI的調(diào)查中達成的基本共識是：縱向跟蹤是必須的，如果沒有父泳，則 REQM SP1.4無法通過般哼。橫向跟蹤如果不作吴汪，則是大部分實施。
2. 對于縱向跟蹤矩陣：

• 必需的：
  • 客戶需求與產(chǎn)品需求的跟蹤
  • 產(chǎn)品需求與測試用例的跟蹤
  • 100%的接口需求需要建立客戶需求-產(chǎn)品需求-設計-編碼-測試用例的跟蹤矩陣
  • 全局性需求要建立跟蹤矩陣,包括：客戶需求-產(chǎn)品需求-設計-編碼-測試用例的跟蹤矩陣
  • 核心需求要建立跟蹤矩陣
• 并非必需的：
  • 性能需求可以不建立跟蹤矩陣
  • 不影響系統(tǒng)架構(gòu)的功能需求蒸眠。

10. 如何簡化RTM的工作漾橙？

?????? 由于在RTM中，需求可能有很多項楞卡，設計霜运、測試用例、代碼等都有多項臀晃，所以建立和維護RTM的工作量還是比較大觉渴、比較煩瑣。對于變化頻繁的項目徽惋，更是如此案淋。在實踐中，為了簡化該RTM的建立與維護工作险绘，有的企業(yè)僅僅通過需求與設計踢京、代碼、測試用例的編號來實現(xiàn)跟蹤宦棺。如需求為：r1,r2,……等編號瓣距，而設計的編號為：r1-d1,r1-d2,…….,測試用例的編號為：r1-t1,r1-t2等等。

?????? 需要注意的是需求與它們之間是多對多的關系代咸，僅通過編號是無法實現(xiàn)這種關系的蹈丸。如果不借助DOORS之類的需求管理工具，一般只能通過EXCEL來維護RTM呐芥，工作量就是比較大逻杖。要簡化，就要平衡管理的投入與產(chǎn)出思瘟，平衡時荸百，可以借鑒上面的在實踐中，如何把握該建立哪些RTM滨攻？<br />當然也可以考慮增大需求够话、設計、代碼光绕、測試用例的顆粒度大小女嘲，但是那樣RTM的作用就打了折扣，還是一個平衡問題诞帐。

11. RTM示例

11.1. 需求跟蹤矩陣

11.2. 需求進度管理表

○ ：已完成欣尼，△ ：進行中，×：未開始景埃，N/A：不適合(沒有此項活動)