Bài 32 — Requirements Traceability Matrix (RTM)

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn là BA của một dự án core banking kéo dài 14 tháng. Đến tháng thứ 9, khách hàng họp gấp và hỏi một câu tưởng chừng đơn giản: "Yêu cầu cho khách phải xác thực OTP khi chuyển tiền trên 10 triệu — yêu cầu đó giờ nằm ở đâu? Đã code chưa? Đã test chưa? Ai duyệt nó?" Nếu bạn ấp úng, mở 5 file Excel khác nhau, gọi điện cho dev rồi cho tester mà vẫn không chắc, thì bạn đang thiếu một thứ rất căn bản: Requirements Traceability Matrix (RTM) — ma trận truy vết yêu cầu.

RTM là sợi chỉ đỏ xuyên suốt vòng đời một yêu cầu: từ nhu cầu kinh doanh ban đầu, qua đặc tả chức năng, đến dòng code, đến test case, đến lần build nó được đưa vào, và cuối cùng là trạng thái pass/fail. Trong các bài trước về quản lý vòng đời yêu cầu (KA3) và kiểm soát thay đổi, bạn đã làm việc với từng mảnh ghép. Bài này tập trung duy nhất vào công cụ kết nối toàn bộ các mảnh ghép đó lại với nhau và biến chúng thành một bảng có thể tra cứu, đo lường, kiểm toán được.

Vì sao quan trọng đến vậy? Vì BA bị đánh giá không chỉ qua việc viết yêu cầu hay, mà qua việc đảm bảo không yêu cầu nào bị rơi rớt và không dòng code nào được viết mà không có lý do kinh doanh. RTM chính là bằng chứng cho cả hai điều đó.

Khái niệm cốt lõi

RTM là gì

Requirements Traceability Matrix là một bảng (thường là Excel, hoặc trong công cụ như Jira/Confluence) ánh xạ mối quan hệ giữa các tầng yêu cầu và các tạo phẩm (artifact) liên quan trong suốt dự án. Mỗi dòng đại diện cho một yêu cầu, và các cột cho biết yêu cầu đó liên kết "lên trên" tới nhu cầu kinh doanh nào, và "xuống dưới" tới chức năng, test case, build nào.

Cấu trúc tối thiểu của một RTM thường gồm các cột sau:

• BR-ID (Business Requirement): nhu cầu kinh doanh cấp cao, ví dụ "Giảm thời gian mở tài khoản xuống dưới 5 phút".
• UR-ID (User Requirement): yêu cầu ở góc nhìn người dùng, ví dụ "Khách hàng tự chụp CCCD bằng điện thoại".
• FR-ID (Functional Requirement): chức năng cụ thể hệ thống phải làm, ví dụ "Hệ thống OCR đọc dữ liệu từ ảnh CCCD và điền tự động vào form".
• NFR-ID (Non-Functional Requirement): yêu cầu phi chức năng, ví dụ "OCR trả kết quả trong dưới 3 giây".
• TC-ID (Test Case): mã các test case kiểm chứng yêu cầu.
• Build: phiên bản/sprint mà yêu cầu được triển khai.
• Status: trạng thái hiện tại (Not Started, In Progress, Developed, Passed, Failed, Deferred...).

Ba kiểu truy vết: forward, backward và bidirectional

Đây là phần nhiều BA mới hay nhầm. RTM không chỉ là một bảng tĩnh, nó hỗ trợ ba hướng tra cứu:

• Forward traceability (truy vết xuôi): từ yêu cầu xuống test case và code. Trả lời câu hỏi "Yêu cầu này đã được kiểm thử chưa?". Giúp phát hiện yêu cầu bị bỏ quên, không ai làm.
• Backward traceability (truy vết ngược): từ một dòng code hay test case ngược lên yêu cầu kinh doanh. Trả lời câu hỏi "Chức năng này tồn tại vì lý do gì?". Giúp phát hiện gold-plating — tính năng được làm ra mà không có yêu cầu nào yêu cầu (scope creep).
• Bidirectional traceability (truy vết hai chiều): kết hợp cả hai. Đây là tiêu chuẩn vàng — một RTM tốt cho phép đi cả hai hướng bất kỳ lúc nào.

Vì sao mỗi tầng yêu cầu phải có ID riêng

Sức mạnh của RTM nằm ở hệ thống mã định danh nhất quán. Một BR có thể đẻ ra nhiều UR; một UR có thể cần nhiều FR; một FR có thể được kiểm bởi nhiều TC. Quan hệ là một-nhiều ở mọi tầng. Nếu không đánh ID rõ ràng, bạn không thể nào lần theo được khi mọi thứ phình to. Quy ước đặt mã (như BR-01, FR-12) chính là "khóa ngoại" liên kết các bảng dữ liệu yêu cầu lại với nhau — tư duy rất giống quan hệ trong cơ sở dữ liệu.

RTM khác gì với Backlog hay danh sách yêu cầu thường

Một danh sách yêu cầu chỉ cho biết "có những gì". RTM cho biết "mỗi thứ liên kết với cái gì và đang ở trạng thái nào trong vòng đời". Backlog trong Agile trả lời "làm gì tiếp theo"; RTM trả lời "mọi thứ đã được phủ kín chưa và bằng chứng đâu". Trong môi trường có kiểm toán (ngân hàng, bảo hiểm, y tế), RTM gần như bắt buộc, còn backlog thì không đủ.

Tình huống thực tế

Tình huống 1 — Ngân hàng VPBank: yêu cầu OTP bị rơi rớt

Một dự án nâng cấp internet banking giả định tại VPBank có hơn 240 functional requirement. Trong một lần review trước UAT, team QA dùng RTM lọc cột Status và phát hiện 7 FR có trạng thái "Developed" nhưng cột TC-ID để trống — nghĩa là đã code nhưng chưa hề có test case nào. Một trong số đó là FR-188: "Hệ thống yêu cầu OTP khi giao dịch vượt hạn mức 100 triệu/ngày."

Nhờ RTM, BA truy ngược lên thấy FR-188 gắn với BR-04 ("Tuân thủ quy định chống rửa tiền của NHNN") — một yêu cầu mang tính tuân thủ, không thể bỏ. Team lập tức bổ sung 4 test case, chạy lại và phát hiện một bug nghiêm trọng: ngưỡng đang để 1 tỷ thay vì 100 triệu.

Bài học: Nếu không có RTM với cột Status và TC-ID, lỗ hổng tuân thủ này có thể đã lọt ra production và khiến ngân hàng bị phạt. RTM không phải thủ tục giấy tờ — nó là lưới an toàn.

Tình huống 2 — Sàn TMĐT Tiki: phát hiện gold-plating nhờ backward traceability

Trong một dự án giả định làm tính năng "ví thưởng" cho Tiki, đội phát triển đã xây thêm một màn hình lịch sử quy đổi điểm khá công phu, tốn gần 2 sprint. Khi BA rà soát RTM theo hướng backward (từ FR ngược lên BR/UR), phát hiện FR cho màn hình này không gắn với bất kỳ BR hay UR nào — không ai từng yêu cầu nó. Một dev đã tự thêm vào vì "nghĩ là hữu ích".

BA mang phát hiện này ra họp với Product Owner. Kết luận: tính năng có thể hữu ích nhưng không nằm trong scope sprint hiện tại, nên đưa vào backlog đánh giá lại độ ưu tiên sau, và 2 sprint đó lẽ ra nên dành cho yêu cầu có độ ưu tiên Must.

Bài học: Backward traceability giúp BA bảo vệ ngân sách và tiến độ. Mỗi dòng code không gắn được lên một yêu cầu là một dấu hỏi cần trả lời.

Tình huống 3 — Insurtech: RTM cứu kỳ kiểm toán

Một công ty bảo hiểm số giả định triển khai hệ thống bồi thường tự động. Sáu tháng sau go-live, đơn vị kiểm toán độc lập vào rà soát và yêu cầu chứng minh rằng mọi quy tắc nghiệp vụ về điều kiện chi trả đều đã được kiểm thử và phê duyệt. BA xuất RTM, lọc theo nhóm BR liên quan tới "điều kiện loại trừ bảo hiểm", và trong vòng nửa ngày trình ra được bảng đầy đủ: mỗi BR → FR → TC-ID → Build → ngày test pass → người phê duyệt.

Kiểm toán viên hài lòng vì có bằng chứng truy vết end-to-end. Đối thủ cùng đợt không có RTM phải mất 3 tuần dựng lại bằng chứng từ email và Jira rời rạc.

Bài học: Trong ngành chịu quản lý (regulated), RTM là tài sản kiểm toán. Đầu tư duy trì nó trong dự án rẻ hơn rất nhiều so với dựng lại sau sự cố.

Hướng dẫn từng bước

Đây là quy trình tôi khuyên bạn áp dụng để xây và duy trì một RTM thực dụng.

Bước 1 — Định nghĩa quy ước đặt mã (ID scheme). Trước khi viết yêu cầu đầu tiên, hãy thống nhất prefix: BR-, UR-, FR-, NFR-, TC-. Dùng số tăng dần không tái sử dụng. Khi một yêu cầu bị xóa, đừng dùng lại mã của nó cho yêu cầu khác — để giữ tính bất biến cho lịch sử.

Bước 2 — Chọn cấp độ truy vết phù hợp với dự án. Dự án nhỏ Agile có thể chỉ cần map User Story → Test Case → Status. Dự án ngân hàng/bảo hiểm cần đủ tầng BR → UR → FR/NFR → TC → Build. Đừng over-engineer: ma trận quá nhiều cột mà không ai cập nhật còn tệ hơn không có.

Bước 3 — Xây bộ khung cột. Tối thiểu nên có: ID yêu cầu, mô tả ngắn, ID cha (liên kết lên), TC-ID, Build/Sprint, Status, và Priority (MoSCoW). Cân nhắc thêm cột Owner và Change Reference để liên kết tới các change request.

Bước 4 — Điền liên kết lên (backward links) ngay khi viết yêu cầu. Mỗi khi viết một FR, hãy ghi ngay nó thuộc UR nào, BR nào. Làm tại thời điểm viết thì dễ; để dồn lại cuối dự án thì gần như không truy được.

Bước 5 — Liên kết test case khi QA viết test. Phối hợp với tester: mỗi test case khi tạo phải ghi rõ kiểm yêu cầu nào. Đây là điểm forward traceability được hoàn thiện.

Bước 6 — Cập nhật Status và Build theo nhịp dự án. Sau mỗi sprint hoặc mỗi lần build, cập nhật trạng thái. RTM chỉ có giá trị khi nó phản ánh hiện tại, không phải ảnh chụp 3 tháng trước.

Bước 7 — Rà soát coverage định kỳ. Trước mỗi cột mốc (UAT, go-live), lọc tìm: FR không có TC (lỗ hổng test), FR không có BR/UR cha (gold-plating), yêu cầu Must còn Status "Not Started" (rủi ro scope). Đây là lúc RTM trả lại giá trị lớn nhất.

Bước 8 — Liên kết với quy trình kiểm soát thay đổi. Khi có change request được duyệt, cập nhật RTM: thêm/sửa/đánh dấu deprecated yêu cầu, và ghi mã change vào cột Change Reference để giữ vết audit.

Lỗi thường gặp & mẹo

Lỗi 1 — Tạo RTM rồi bỏ đó. Đây là lỗi phổ biến nhất. RTM tĩnh, lỗi thời còn nguy hiểm hơn không có vì nó tạo ảo giác kiểm soát. Mẹo: gắn việc cập nhật RTM vào Definition of Done của mỗi sprint, biến nó thành thói quen chứ không phải sự kiện.

Lỗi 2 — Ma trận quá chi tiết, bất khả thi để duy trì. Một số BA cố truy vết tới từng dòng code hay từng commit. Với hầu hết dự án, điều đó là quá sức. Mẹo: truy tới cấp test case là đủ trong đa số trường hợp; chỉ đi sâu hơn khi có yêu cầu tuân thủ bắt buộc.

Lỗi 3 — Mã ID bị tái sử dụng hoặc đặt lung tung. Khi mã không nhất quán, toàn bộ liên kết sụp đổ. Mẹo: khóa quy ước ID ngay từ đầu và ghi vào tài liệu chuẩn dự án.

Lỗi 4 — Chỉ làm forward, quên backward. Nhiều BA chỉ kiểm "yêu cầu đã test chưa" mà quên kiểm "chức năng này có yêu cầu không". Mẹo: mỗi lần rà soát, chạy cả hai chiều.

Lỗi 5 — Dùng Excel khi dự án đã đủ lớn cho công cụ. Excel ổn cho dự án vừa, nhưng với hàng trăm yêu cầu thay đổi liên tục, nó dễ vỡ. Mẹo: cân nhắc Jira (link issue) + plugin như Xray/Zephyr để tự sinh ma trận truy vết, giảm cập nhật thủ công.

Mẹo vàng: Hãy coi RTM như một sản phẩm sống, không phải tài liệu nộp một lần. BA giỏi mở RTM mỗi tuần, không phải mỗi quý.

Bài tập thực hành

Bài tập 1 — Dựng RTM nhỏ. Cho nhu cầu kinh doanh: "Khách hàng có thể đặt lại mật khẩu mà không cần gọi tổng đài." Hãy phân rã thành ít nhất 1 BR, 2 UR, 3 FR, 1 NFR, và viết 4 test case tương ứng. Lập một bảng RTM đầy đủ 7 cột như mẫu trong bài. Đảm bảo mỗi FR đều truy lên được một UR và mỗi UR truy lên BR.

Bài tập 2 — Săn lỗ hổng. Lấy bảng RTM bạn vừa làm, cố ý xóa liên kết của 1 FR (để trống cột cha) và xóa TC-ID của 1 FR khác. Sau đó đóng vai người rà soát: viết ra bạn phát hiện hai vấn đề gì (gold-plating và gap test coverage) và bạn sẽ xử lý mỗi vấn đề thế nào.

Bài tập 3 — Tình huống thay đổi. Khách hàng yêu cầu thêm: "Đặt lại mật khẩu phải xác thực qua OTP gửi SMS." Hãy cập nhật RTM của bạn: thêm FR/NFR mới, gắn test case, đặt Status, và ghi một mã Change Reference giả định (ví dụ CR-007). Mô tả những dòng nào trong RTM bị ảnh hưởng — đây chính là một bài impact analysis mini.

Tóm tắt

Requirements Traceability Matrix là sợi chỉ đỏ kết nối nhu cầu kinh doanh với chức năng, test case, build và trạng thái — cho phép BA trả lời tức thì câu hỏi "yêu cầu này ở đâu, vì sao tồn tại, đã test chưa". Cấu trúc cốt lõi gồm các cột BR-ID, UR-ID, FR-ID, NFR-ID, TC-ID, Build và Status, được liên kết qua một hệ thống mã định danh nhất quán. Sức mạnh thật sự của RTM nằm ở truy vết hai chiều: forward để phát hiện yêu cầu bị bỏ quên hoặc chưa test, backward để phát hiện gold-plating và bảo vệ scope. Qua ba tình huống — OTP bị rơi rớt ở ngân hàng, gold-plating trên sàn TMĐT, và RTM cứu kỳ kiểm toán bảo hiểm — bạn thấy RTM không phải thủ tục giấy tờ mà là lưới an toàn và tài sản kiểm toán. Nguyên tắc sống còn: RTM phải là tài liệu sống, được cập nhật theo nhịp sprint, không phải ảnh chụp một lần rồi quên. Một BA chuyên nghiệp đo lường chất lượng công việc của mình một phần qua việc RTM của họ luôn đầy đủ, cập nhật và truy được cả hai chiều.