Requirements Traceability Matrix(RTM)
Bảng nối yêu cầu với nơi nó được hiện thực và nơi nó được kiểm thử, để trả lời hai câu: yêu cầu này đã làm chưa, và nếu sửa chỗ này thì hỏng những gì.
Định nghĩa
Cuối dự án, khách hỏi một câu rất đơn giản: "Cái yêu cầu về hạn mức giao dịch hôm tháng Ba, làm chưa, test chưa". Nếu bạn phải mở bốn file và hỏi ba người mới trả lời được, dự án đó đang thiếu RTM.
RTM là một bảng, mỗi dòng một yêu cầu, các cột nối yêu cầu đó tới thiết kế, tới code, tới test case, tới kết quả UAT. Nghe khô khan, nhưng nó giải quyết đúng hai tình huống đau: chứng minh độ phủ, và đánh giá tác động khi có thay đổi.
Truy vết xuôi để biết yêu cầu đã được làm chưa. Truy vết ngược để biết mỗi dòng code sinh ra vì ai yêu cầu.
Gồm những cột gì
Bản tối thiểu mà vẫn dùng được:
| Cột | Nội dung |
|---|---|
| Mã yêu cầu | FR-PAY-014 |
| Mô tả ngắn | Chặn giao dịch vượt hạn mức ngày |
| Nguồn | Biên bản họp 12/03, phòng Quản lý rủi ro |
| Business requirement liên quan | BR-02 Tuân thủ hạn mức NHNN |
| Hạng mục thiết kế | Sequence diagram SD-07, API POST /transfers |
| Mã test case | TC-PAY-041, TC-PAY-042, TC-PAY-043 |
| Trạng thái | Đã phát triển / Đang test / UAT pass |
Có nơi thêm cột số hiệu CR để biết yêu cầu đến từ thay đổi nào, cột sprint, cột người phụ trách. Thêm gì thì thêm, giữ nguyên tắc: mỗi cột phải có người thật sự dùng, nếu không nó chỉ tốn công cập nhật.
Truy vết còn có chiều dọc giữa các tầng yêu cầu: business requirement dẫn xuống stakeholder requirement, xuống solution requirement. Chiều này ít ai làm ở dự án nhỏ, nhưng ở dự án có kiểm toán thì bắt buộc.
Ví dụ thực tế
Dự án nâng cấp module chuyển khoản của một công ty tài chính, 62 yêu cầu chức năng, 4 tháng, có kiểm toán nội bộ tham gia nghiệm thu.
Cuối giai đoạn SIT, đội mở RTM ra và phát hiện 5 yêu cầu chưa có test case nào trỏ tới. Trong 5 cái đó, 3 cái là luồng ngoại lệ (giao dịch bị treo khi đối tác timeout), 2 cái là yêu cầu ghi log cho kiểm toán. Không có RTM thì 5 lỗ hổng này chỉ lộ ra sau khi lên production, và cái lỗ về log là loại không sửa hồi tố được — dữ liệu không ghi thì mất luôn.
Ở chiều ngược lại: khi khách gửi CR đổi cách tính phí, đội mở RTM lọc theo từ khoá "phí", ra 9 yêu cầu và 23 test case liên quan. Ước lượng tác động mất 35 phút thay vì hai ngày đọc lại tài liệu.
Khi nào RTM là gánh nặng
Ở một dự án Agile ba người làm app nội bộ, duy trì RTM thủ công trong Excel là lãng phí. Backlog trong Jira đã nối story với subtask và test case rồi; thêm một file Excel song song chỉ tạo ra một nghĩa vụ cập nhật mới. Được hai tuần, rồi nó lệch với Jira, và từ lúc lệch thì nó có hại hơn là không có.
RTM đáng làm khi có ít nhất một trong các điều kiện sau:
- Hợp đồng nghiệm thu theo tài liệu, cần chứng minh đã làm đủ.
- Có kiểm toán, thanh tra, hoặc yêu cầu tuân thủ pháp lý.
- Hệ thống lớn, nhiều module phụ thuộc nhau, sửa một chỗ khó biết ảnh hưởng đâu.
- Đội đông và nhân sự thay đổi liên tục, tri thức không nằm trong đầu ai đủ lâu.
Còn nếu bạn vẫn phải làm dù thấy vô ích, hãy giảm chi phí thay vì làm cho có: dùng đúng công cụ quản lý yêu cầu, đặt link giữa Jira issue và test case trong Xray hoặc TestRail, rồi xuất RTM ra khi cần. Bảng tự sinh luôn đúng hơn bảng gõ tay.
Mẹo khi đi làm
Cập nhật RTM theo nhịp, không theo cảm hứng. Chốt một thời điểm cố định, ví dụ cuối mỗi sprint hoặc mỗi lần phát hành bản build cho QC. Bảng cập nhật nửa vời là loại tệ nhất. Người không biết nó cũ sẽ dùng nó để ước lượng, rồi ước lượng sai, rồi không hiểu vì sao.
Và đừng để RTM ở dạng file đính kèm trong email. Ở đâu cũng được, miễn là một đường link duy nhất, ai cũng mở được, có lịch sử thay đổi. Confluence hoặc Google Sheets đều ổn hơn hẳn file rời trôi nổi qua bảy phiên bản v2_final_final.
