INFOCHIEF ACADEMY · IT PROJECT MANAGEMENT KNOWLEDGE SERIES

Quản lý yêu cầu và khả năng truy xuất bằng Requirements Traceability Matrix.

RTM nối yêu cầu với nguồn, phần thực hiện và bằng chứng kiểm chứng. Truy xuất hai chiều giúp phát hiện khoảng trống, đánh giá tác động thay đổi và giữ căn cứ cho nghiệm thu, chuyển giao.

Biên soạn: Infochief Academy · Chuyên đề: Quản lý dự án IT

← Trở về thư viện bài viết

Minh họa biên tập: chuyên viên yêu cầu và chất lượng nối các thẻ yêu cầu với thiết kế, kiểm thử.

Khi một yêu cầu thay đổi, câu hỏi khó thường không phải ai sẽ sửa mà là phải sửa những gì. Trong một tình huống giả định, quy tắc phê duyệt đơn hàng được điều chỉnh. Đội phát triển sửa màn hình chính, nhưng báo cáo, hướng dẫn và kịch bản kiểm thử vẫn theo quy tắc cũ. Mỗi nhóm có một bản danh sách riêng nên không ai nhìn thấy toàn bộ chuỗi tác động.

Requirements Traceability Matrix, viết tắt RTM, là ma trận liên kết yêu cầu với nguồn, phần thực hiện và bằng chứng kiểm chứng liên quan. Khả năng truy xuất hai chiều giúp đi từ nhu cầu đến sản phẩm, đồng thời đi từ sản phẩm hoặc kết quả kiểm tra trở lại yêu cầu. Ma trận có ích khi trả lời một quyết định thực tế, thay vì chỉ chứng minh dự án có đủ tài liệu.

Xác định những câu hỏi ma trận phải trả lời

Trước khi lập cột, người quản lý nên xác định mục đích sử dụng. Dự án có thể cần biết yêu cầu nào chưa có giải pháp, yêu cầu nào chưa được kiểm tra hoặc phần nào bị tác động khi quy tắc đổi. Nhu cầu ở từng giai đoạn có thể khác nhau. Một ma trận được tạo quá rộng từ đầu dễ có nhiều cột không ai cập nhật.

RTM cần giữ mã yêu cầu ổn định, nguồn và phiên bản. Một số thứ tự tự thay đổi khi chèn dòng sẽ làm các liên kết cũ mất ý nghĩa. Mã không cần phức tạp, nhưng phải nhận diện được cùng yêu cầu xuyên suốt quá trình. Nếu yêu cầu bị tách hoặc thay thế, cần giữ quan hệ lịch sử để biết công việc trước đó phục vụ điều gì.

Nguồn cần đủ cụ thể: tài liệu nghiệp vụ, điều kiện hợp đồng hoặc yêu cầu kiểm soát được xác nhận. Không nên chỉ ghi tên một phòng ban rồi cho rằng đã truy xuất được. Người quản lý cũng cần biết ai có quyền xác nhận nghĩa và ưu tiên của yêu cầu. Khi có tranh luận, nguồn và chủ sở hữu giúp đưa câu hỏi đến đúng nơi.

Năng lực quản lý dự án IT hỗ trợ việc giữ những liên kết này trong một cơ sở chung. Sau khi biết cần trả lời câu hỏi nào, đội phải kiểm tra chất lượng yêu cầu; một liên kết đầy đủ không làm yêu cầu mơ hồ trở nên đúng.

Làm rõ yêu cầu trước khi gắn vào thiết kế và kiểm thử

Một yêu cầu như hệ thống phải dễ dùng khó được xác minh nếu không có bối cảnh và tiêu chí phù hợp. Cần mô tả người sử dụng, việc phải làm và điều kiện chấp nhận. Những yêu cầu gộp nhiều nghĩa nên được xem xét tách để có thể theo dõi. Nếu một dòng chứa cả chức năng, hiệu năng và quyền truy cập, trạng thái đạt có thể che phần chưa đáp ứng.

Yêu cầu chức năng và phi chức năng đều cần được nhìn thấy khi có ý nghĩa đối với mục tiêu. Hiệu năng, bảo mật, phục hồi hoặc lưu giữ dữ liệu có thể ảnh hưởng thiết kế và bằng chứng kiểm tra. Không nên giữ chúng ở một tài liệu phụ rồi bỏ khỏi ma trận chỉ vì khó nối với màn hình. Phương pháp kiểm chứng có thể là thử nghiệm, phân tích, xem xét hoặc trình diễn phù hợp, không phải luôn là một test case giao diện.

Tài liệu NASA về quản lý yêu cầu nhấn mạnh việc giữ liên kết và quản lý thay đổi. Khi áp dụng vào IT doanh nghiệp, đội nên chọn mức chi tiết đủ để kiểm soát hệ quả. Một yêu cầu có thể liên kết nhiều phần thiết kế và nhiều kiểm tra; một kiểm tra cũng có thể cung cấp bằng chứng cho nhiều yêu cầu. Quan hệ không nhất thiết là một đối một.

Chuyên gia quản lý an toàn thông tin nên xác nhận những yêu cầu thuộc trách nhiệm của họ. Người quản lý dự án không cần tự viết mọi tiêu chí, nhưng phải bảo đảm yêu cầu quan trọng có người làm rõ và phương pháp kiểm chứng được thống nhất trước khi sản phẩm hoàn tất.

Thiết kế ma trận gọn và giữ liên kết đến bằng chứng

Một cấu trúc ban đầu có thể gồm mã, mô tả ngắn, nguồn, chủ sở hữu, phần thực hiện, kiểm chứng, phiên bản và trạng thái. Không nhất thiết đưa toàn bộ nội dung tài liệu vào từng ô. Có thể giữ liên kết tới hồ sơ chi tiết để ma trận phục vụ định hướng và kiểm tra. Điều quan trọng là liên kết còn hoạt động và đúng phiên bản được sử dụng.

Bảng sau minh họa một phần RTM cho dự án đơn hàng giả định. Các mã và nội dung chỉ nhằm thể hiện cách nối thông tin, không phải yêu cầu chung cho mọi hệ thống.

Yêu cầu giả định	Phần thực hiện liên quan	Bằng chứng cần theo dõi
R-01: Phê duyệt theo vai trò đã thống nhất	Quy tắc quyền, màn hình và luồng phê duyệt	T-01 và T-02: đúng vai trò, sai vai trò
R-02: Ghi lịch sử quyết định	Cơ chế nhật ký và báo cáo	T-03: nội dung, thời điểm, người quyết định
R-03: Xử lý đơn bị trả lại	Luồng sửa và gửi lại	T-04: ngoại lệ và trạng thái sau sửa

Trong hồ sơ thực tế, T-01 không chỉ là một cái tên; nó phải dẫn đến kịch bản và kết quả của phiên bản cụ thể. Một test case tồn tại chưa chứng minh yêu cầu đã đạt. Ma trận nên phân biệt đã thiết kế kiểm tra, đã thực hiện và đã đủ bằng chứng chấp nhận. Nếu dùng một cột trạng thái chung, phải có quy ước để tránh hiểu sai.

Đội Quản Lý Dịch Vụ IT – ITSM có thể bổ sung liên kết đến hướng dẫn và điều kiện hỗ trợ đối với yêu cầu vận hành. Khi RTM bao quát phần sử dụng, tác động của thay đổi sẽ không dừng ở mã nguồn và kịch bản kiểm thử.

Dùng hai chiều để phát hiện thiếu sót và công việc ngoài phạm vi

Đi từ yêu cầu xuống, đội kiểm tra mỗi yêu cầu đã có phần thực hiện và cách chứng minh chưa. Khoảng trống có thể là chưa thiết kế, chưa giao công việc hoặc chưa có dữ liệu kiểm tra. Cần phân biệt các nguyên nhân để xử lý đúng. Không nên gắn một thiết kế bất kỳ chỉ để mọi dòng đều có liên kết.

Đi từ sản phẩm hoặc kiểm tra lên, đội hỏi nó phục vụ yêu cầu nào. Một chức năng không có nguồn có thể là phần hỗ trợ hợp lệ chưa được ghi rõ, hoặc phần việc tự phát cần xem xét. Một kiểm tra không liên kết có thể là kiểm tra rủi ro hữu ích, nhưng cần ghi lý do. Truy xuất giúp làm rõ chứ không buộc mọi hoạt động phải bị loại nếu thiếu một liên kết ban đầu.

Số liệu bao phủ cần giải thích đơn vị và điều kiện. Tỷ lệ yêu cầu có kịch bản khác với tỷ lệ yêu cầu đã đủ bằng chứng. Những yêu cầu bị hoãn, thay thế hoặc loại bỏ phải được quản lý trạng thái để không làm mẫu số thiếu nhất quán. Một con số cao có thể che yêu cầu quan trọng chưa đạt nếu mọi dòng được xem có trọng lượng như nhau.

Nên ưu tiên khoảng trống theo tác động. Một yêu cầu phục hồi dữ liệu chưa được kiểm chứng có thể cần chú ý trước một số chức năng ít sử dụng. Người quản lý cần đặt kết quả ma trận cạnh mức rủi ro và mốc dự án. RTM giúp nhìn thấy khoảng trống; quyền chấp nhận hoặc điều chỉnh vẫn phải được thực hiện qua cơ chế quản trị.

Kiểm tra chuỗi tác động trước khi chấp thuận thay đổi

Khi quy tắc phê duyệt đổi, đội đi từ yêu cầu đến phần thiết kế, cấu hình, kiểm tra, tài liệu và sản phẩm liên quan. Những liên kết trực tiếp là điểm bắt đầu, nhưng vẫn cần chuyên gia xem tác động gián tiếp. Ma trận không tự biết mọi quan hệ kỹ thuật nếu chúng chưa được ghi. Một cuộc rà ngắn với các đầu mối giúp kiểm tra độ đầy đủ của kết quả truy xuất.

Phần việc bị tác động cần được ước lượng và đưa vào hồ sơ thay đổi. Nếu yêu cầu đã được phê duyệt, cập nhật phiên bản liên quan cùng bằng chứng. Nếu chưa phê duyệt, giữ trạng thái đề xuất để đội không thực hiện lẫn với phiên bản hiện hành. Lịch sử cần cho biết điều gì đã đổi và vì sao, đặc biệt khi sản phẩm cũ đã được kiểm tra.

Vai trò của Giám Đốc Dự Án IT là bảo đảm các hệ quả được đưa vào lựa chọn điều hành. Không nên cho rằng phần cập nhật RTM là việc hành chính sau quyết định; chính nó cung cấp một phần căn cứ để đánh giá quyết định. Những bên chịu tác động phải nhìn cùng phiên bản khi xác nhận.

Nếu dùng công cụ quản lý yêu cầu, tự động hóa có thể giảm việc sao chép nhưng vẫn cần người sở hữu dữ liệu. Nếu dùng bảng tính, cần quy ước cập nhật và kiểm tra liên kết. Công cụ nào cũng phải có cơ chế ngăn nhiều bản riêng cùng được dùng như bản chính. Mức quản lý nên phù hợp quy mô nhưng không bỏ trách nhiệm phiên bản.

Giữ RTM sống đến nghiệm thu và chuyển giao

Trước nghiệm thu, đội cần rà các yêu cầu quan trọng chưa có kết quả, có kết quả không đạt hoặc còn ngoại lệ. Người có quyền chấp nhận cần thấy phần nào đã đủ bằng chứng và phần nào đang được đề nghị xử lý khác. Không nên đổi trạng thái thành hoàn tất chỉ vì dự án sắp đóng. Những tồn đọng được chấp nhận phải có trách nhiệm và điều kiện riêng.

Khi chuyển vận hành, ma trận hoặc phần trích phù hợp giúp đội biết sản phẩm phục vụ yêu cầu nào và bằng chứng nằm ở đâu. Cần giữ phiên bản bàn giao, tài liệu liên quan và người tiếp nhận. Các liên kết tới công cụ của nhà cung cấp phải được xem xét khả năng truy cập sau kết thúc hợp tác. Một đường dẫn không còn quyền sử dụng sẽ không tạo được truy xuất bền vững.

Với quy tắc đơn hàng ở mở bài, hãy chọn một yêu cầu và đi cả hai chiều qua thiết kế, kiểm tra và tài liệu. Sửa những khoảng trống trước khi nhân rộng cấu trúc cho toàn dự án. RTM có giá trị khi một thay đổi hoặc câu hỏi nghiệm thu được trả lời bằng chuỗi bằng chứng, để đội bớt phải dựa vào trí nhớ và các danh sách riêng lẻ.