Mở đầu — vì sao bài này quan trọng
Hãy bắt đầu bằng một câu hỏi mà tôi rất hay đặt cho học viên cũ từng làm Finance: "Khi sếp hỏi vì sao báo cáo doanh thu tháng 3 lệch 12 triệu so với sổ cái, bạn làm gì?" Câu trả lời gần như luôn giống nhau: lần ngược dấu vết. Từ con số tổng trên báo cáo, bạn truy về bút toán, từ bút toán về chứng từ gốc, từ chứng từ về hợp đồng. Đó chính là truy vết (traceability) — và đó là kỹ năng bạn đã làm hàng nghìn lần mà không gọi tên.
Trong nghề BA, có một công cụ vận hành đúng theo logic đó: Requirement Traceability Matrix (RTM) — Ma trận Truy vết Yêu cầu. Nó trả lời câu hỏi sống còn của mọi dự án phần mềm: "Yêu cầu kinh doanh này đã được hiện thực hóa thành tính năng chưa? Tính năng đó đã được kiểm thử chưa? Nếu có lỗi, lỗi đó liên quan đến yêu cầu nào?"
Đây là một trong những bài mà người từ Finance có lợi thế gần như bất công so với các BA xuất thân từ ngành khác. Vì bản chất RTM là đối chiếu và khớp sổ — bạn đã sống cùng tư duy này. Trong khi một BA từ marketing phải học từ đầu khái niệm "mọi thứ phải khớp và có dấu vết kiểm toán", thì bạn đã có nó trong máu từ ngày học nguyên lý kế toán. Bài này dạy bạn cách chuyển hóa kỹ năng đối soát đó thành một tài liệu BA chuẩn mực, được audit và compliance săn đón.
Khái niệm cốt lõi
RTM là gì
RTM là một bảng (thường là spreadsheet hoặc một module trong Jira/Confluence) theo dõi mối quan hệ truy vết hai chiều giữa các tầng của một yêu cầu, từ lúc nó còn là mong muốn kinh doanh cho tới khi nó chạy được trên hệ thống và được xác nhận không lỗi.
Chuỗi truy vết kinh điển gồm 5 mắt xích:
BR → US → AC → TC → Defect
- BR (Business Requirement) — Yêu cầu kinh doanh. Ví dụ: "Hệ thống phải tự động tính thuế GTGT 10% trên mỗi hóa đơn bán hàng."
- US (User Story) — Câu chuyện người dùng, là cách diễn đạt yêu cầu dưới góc nhìn người dùng. Ví dụ: "Là kế toán viên, tôi muốn thuế GTGT được tính tự động để tôi không phải nhập tay."
- AC (Acceptance Criteria) — Tiêu chí chấp nhận, điều kiện cụ thể để US được coi là "xong". Ví dụ: "Khi nhập đơn 1.000.000đ thì dòng thuế hiển thị 100.000đ."
- TC (Test Case) — Ca kiểm thử để xác minh AC. Ví dụ: "TC-045: Nhập đơn 1.000.000đ, kỳ vọng thuế = 100.000đ."
- Defect (D) — Lỗi phát hiện khi TC fail, liên kết ngược về TC và US tương ứng.
Truy vết hai chiều (bidirectional traceability)
Đây là điểm cốt lõi mà nhiều người mới bỏ qua. Truy vết phải đi được cả xuôi lẫn ngược, giống hệt sổ kế toán:
- Truy vết xuôi (forward): Từ một BR, tôi có thể tìm ra mọi US, AC, TC liên quan. Mục đích: đảm bảo mọi yêu cầu kinh doanh đều được hiện thực và kiểm thử — không yêu cầu nào bị bỏ rơi. Giống như đảm bảo mọi hợp đồng đều đã được ghi nhận doanh thu.
- Truy vết ngược (backward): Từ một dòng code, một test case, hay một tính năng, tôi có thể truy về BR nào đẻ ra nó. Mục đích: chống gold-plating — tức là dev tự ý làm thêm tính năng không ai yêu cầu. Giống như khi bạn thấy một bút toán lạ trong sổ và phải tìm chứng từ gốc; nếu không có chứng từ, bút toán đó đáng ngờ.
Cấu trúc bảng RTM chuẩn
Một RTM tối thiểu nên có các cột sau:
| Cột | Ý nghĩa | Ví dụ |
|---|---|---|
| BR ID | Mã yêu cầu kinh doanh | BR-012 |
| Description | Mô tả yêu cầu | Tự động tính thuế GTGT |
| Priority | Độ ưu tiên (MoSCoW) | Must |
| US ID | Mã user story | US-034 |
| AC ID | Mã tiêu chí chấp nhận | AC-034.2 |
| TC ID | Mã ca kiểm thử | TC-045 |
| Test Status | Trạng thái kiểm thử | Pass/Fail/Blocked |
| Defect ID | Mã lỗi (nếu fail) | BUG-118 |
| Status | Trạng thái tổng | Done/In progress |
Vì sao RTM là "quy chuẩn audit"
Trong các dự án thuộc lĩnh vực ngân hàng, fintech, bảo hiểm, y tế — nơi chịu kiểm toán nội bộ và bên ngoài (SBV, ISO 27001, SOC 2, kiểm toán độc lập) — RTM không phải tùy chọn mà là bằng chứng bắt buộc. Khi auditor hỏi "Quy định nghiệp vụ X về hạn mức giao dịch đã được kiểm thử đầy đủ chưa?", BA phải mở RTM, chỉ vào dòng BR tương ứng và trình ra chuỗi US-AC-TC-status. Không có RTM, dự án không có cách nào chứng minh độ phủ (coverage). Đây chính xác là tư duy "không có chứng từ thì không ghi nhận" mà bạn đã quen.
Tình huống thực tế
Ví dụ 1 — Dự án core banking tại một ngân hàng TMCP
Một ngân hàng thương mại cổ phần ở TP.HCM triển khai module tính lãi tiết kiệm mới. Yêu cầu nghiệp vụ có 47 BR, trong đó BR-031 quy định: "Lãi suất tiết kiệm không kỳ hạn được tính theo phương pháp tích số, làm tròn đến đồng, cộng dồn cuối ngày."
Hai tuần trước go-live, kiểm toán nội bộ vào soát. Họ chọn ngẫu nhiên BR-031 và yêu cầu chứng minh độ phủ kiểm thử. BA — vốn là một cựu kế toán ngân hàng — mở RTM ra, lọc theo BR-031 và chỉ ra: BR-031 sinh ra US-052 và US-053, với tổng 6 AC, được phủ bởi 9 TC, trong đó có TC kiểm thử trường hợp làm tròn ở mức 0,5 đồng. Tất cả 9 TC đều Pass. Auditor gật đầu trong 4 phút.
So sánh: một module khác do team thuê ngoài làm, không duy trì RTM. Khi auditor hỏi tương tự, team mất 3 ngày để rà thủ công và phát hiện ra rằng quy tắc làm tròn chưa có TC nào kiểm. Kết quả: hoãn go-live module đó một sprint.
Bài học rút ra: RTM biến câu hỏi "đã đủ chưa?" từ một cuộc tranh luận cảm tính thành một câu trả lời tra cứu được trong vài phút. Đây chính là sức mạnh của "khớp sổ" áp dụng vào phần mềm.
Ví dụ 2 — Phát hiện gold-plating tại một startup fintech (giả định hợp lý)
Tại một ví điện tử đang phát triển nhanh ở Hà Nội, BA Linh (cựu chuyên viên kiểm soát nội bộ) dựng RTM cho tính năng "nạp tiền từ thẻ ngân hàng". Khi đối soát ngược, cô phát hiện một màn hình "lịch sử nạp tiền có xuất file PDF có chữ ký số" mà dev đã làm, nhưng không truy ngược được về BR nào.
Hỏi ra mới biết một bạn dev thấy "hay hay" nên tự làm thêm. Tính năng này tốn 5 ngày công, và quan trọng hơn, chữ ký số liên quan đến quy định pháp lý mà chưa ai phê duyệt — một rủi ro compliance tiềm tàng. Linh đưa vào backlog để Product Owner quyết định: hoặc tạo BR chính thức (kèm review pháp lý), hoặc gỡ bỏ.
Bài học rút ra: Truy vết ngược giống nghiệp vụ soát "bút toán không chứng từ". Mỗi tính năng phải có "hóa đơn gốc" là một BR. Cái gì không có nguồn gốc thì phải chất vấn — không phải để bắt lỗi dev, mà để kiểm soát phạm vi và rủi ro.
Ví dụ 3 — RTM cứu một cuộc họp khủng hoảng tại dự án ERP
Một doanh nghiệp sản xuất ở Bình Dương triển khai ERP, phân hệ kế toán phải khớp với 12 BR về hạch toán chi phí. Sát UAT, khách hàng phản ánh: "Báo cáo giá thành không ra đúng số." Cuộc họp căng thẳng, ai cũng đổ lỗi nhau.
BA mở RTM, lọc nhanh các BR liên quan giá thành. Phát hiện BR-008 ("phân bổ chi phí chung theo giờ máy") có US và AC đầy đủ, nhưng cột Test Status của TC-073 là Blocked — vì dữ liệu giờ máy chưa được import vào môi trường test. Vấn đề không nằm ở logic phần mềm mà ở dữ liệu test. Trong 15 phút, nguyên nhân được khoanh vùng, tránh được việc team dev mất cả tuần "sửa" một thứ không hỏng.
Bài học rút ra: RTM không chỉ chứng minh độ phủ, nó còn là bản đồ chẩn đoán. Khi sự cố nổ ra, người có RTM khoanh vùng được nguyên nhân nhanh gấp nhiều lần người mò mẫm.
Hướng dẫn từng bước
Đây là quy trình dựng và vận hành một RTM thực tế. Tôi khuyến nghị bạn làm trên Google Sheets/Excel trước khi nâng cấp lên Jira (qua plugin như Xray hay Requirements Yogi).
Bước 1 — Liệt kê và đánh mã BR. Lấy danh sách yêu cầu kinh doanh từ BRD/PRD. Gán mỗi BR một ID duy nhất, không tái sử dụng (BR-001, BR-002...). Quy tắc đánh mã giống đánh số chứng từ: không trùng, không nhảy cóc khó hiểu, có quy luật.
Bước 2 — Ánh xạ BR sang US. Một BR có thể đẻ ra nhiều US (quan hệ một-nhiều). Điền cột US ID. Nếu một BR không có US nào, đó là dấu hiệu yêu cầu chưa được phân rã — cờ vàng.
Bước 3 — Gắn AC cho từng US. Mỗi US cần ít nhất một AC. AC chính là "điều kiện nghiệm thu", tương đương các điều khoản trong hợp đồng quyết định khi nào được ghi nhận hoàn thành.
Bước 4 — Liên kết TC tới AC. Đội QA viết test case dựa trên AC. BA đảm bảo mỗi AC có TC phủ. Đây là bước "đối chiếu" quan trọng nhất: AC nào không có TC = rủi ro chưa kiểm thử.
Bước 5 — Cập nhật trạng thái kiểm thử và defect. Khi chạy test, cập nhật Pass/Fail/Blocked. TC fail thì link sang Defect ID. RTM trở thành tài liệu sống, cập nhật theo từng sprint.
Bước 6 — Phân tích độ phủ và đối soát hai chiều. Định kỳ (cuối mỗi sprint), chạy hai phép kiểm:
- Xuôi: Có BR nào chưa có TC Pass không? → công việc còn dang dở.
- Ngược: Có TC/tính năng nào không truy về BR không? → gold-plating cần xử lý.
Lỗi thường gặp & mẹo
Lỗi 1 — Dựng RTM một lần rồi bỏ quên. RTM chết là RTM vô dụng. Nó phải được cập nhật mỗi sprint như bạn cập nhật sổ mỗi ngày. Mẹo: gắn việc cập nhật RTM vào Definition of Done của mỗi US.
Lỗi 2 — Làm RTM quá chi tiết đến mức không ai duy trì nổi. Với dự án nhỏ, không cần đủ 5 mắt xích. Có thể rút gọn còn BR → US → TC. Quy mô tài liệu phải tương xứng quy mô và mức độ chịu kiểm toán của dự án. Dự án fintech chịu audit thì làm đầy đủ; app nội bộ nhỏ thì gọn lại.
Lỗi 3 — Mã ID lộn xộn, trùng lặp. Đây là lỗi "đánh số chứng từ ẩu". Hãy thống nhất quy ước đặt mã ngay từ đầu và viết nó vào trang đầu file. Một khi đã phát hành thì không đổi mã.
Lỗi 4 — Nhầm AC với TC. AC là điều kiện nghiệm thu (góc nhìn nghiệp vụ: "phải đạt cái gì"); TC là kịch bản kiểm thử (góc nhìn QA: "kiểm bằng cách nào"). Một AC thường cần nhiều TC để phủ các biên (giá trị 0, giá trị âm, giá trị lớn nhất...).
Lỗi 5 — Bỏ qua truy vết ngược. Nhiều BA chỉ làm xuôi để chứng minh "đã làm đủ", mà quên chiều ngược để kiểm soát phạm vi. Với người từ Finance, đây là lúc phát huy bản năng "bút toán phải có chứng từ".
Mẹo vàng: Tận dụng đúng tư duy đối soát của bạn. Khi nhìn RTM, hãy tự hỏi đúng câu bạn từng hỏi với bảng cân đối: "Cột nào đang trống mà lẽ ra phải có số? Dòng nào không cân?" Cảm giác khó chịu khi sổ không khớp — hãy giữ lấy nó, nó là tài sản nghề nghiệp của bạn.
Bài tập thực hành
Bài tập 1 — Dựng RTM mini. Cho yêu cầu kinh doanh: "Hệ thống phải khóa tài khoản người dùng sau 5 lần đăng nhập sai liên tiếp trong vòng 10 phút." Hãy:
- Viết BR-001 với mô tả và priority.
- Phân rã thành ít nhất 2 US.
- Viết tối thiểu 3 AC (nhớ cover các biên: lần thứ 4, lần thứ 5, và trường hợp nhập đúng ở lần thứ 3 rồi sai lại).
- Đề xuất 4 TC tương ứng.
- Trình bày tất cả trên một bảng RTM đủ cột.
Bài tập 3 — Phân tích độ phủ. Cho một RTM có 10 BR, trong đó 8 BR có TC Pass đầy đủ, 1 BR có TC nhưng status Blocked, 1 BR chưa có TC nào. Hãy tính test coverage, completion rate, và viết 3 dòng khuyến nghị cho buổi họp sprint review.
Tóm tắt
RTM — Ma trận Truy vết Yêu cầu — là công cụ theo dõi chuỗi BR → US → AC → TC → Defect theo cả hai chiều xuôi và ngược. Truy vết xuôi đảm bảo mọi yêu cầu kinh doanh đều được hiện thực và kiểm thử; truy vết ngược chống gold-plating bằng cách buộc mọi tính năng phải có "chứng từ gốc" là một BR. Đây là tài liệu bắt buộc trong các dự án chịu kiểm toán (ngân hàng, fintech, bảo hiểm), nơi nó trở thành bằng chứng độ phủ trình trước auditor.
Điều then chốt với người chuyển từ Finance: RTM về bản chất là đối soát và khớp sổ — kỹ năng bạn đã thành thạo. Bản năng "không có chứng từ thì không ghi nhận", cảm giác khó chịu khi bảng cân đối lệch một đồng, thói quen đánh số chứng từ ngăn nắp — tất cả chuyển hóa trực tiếp thành năng lực dựng và vận hành RTM. Hãy giữ RTM là một tài liệu sống, cập nhật mỗi sprint, và bạn sẽ thấy mình làm phần việc này tự nhiên hơn hầu hết đồng nghiệp BA xuất thân từ ngành khác.