Bỏ qua

Tmpl Val Trace 001 Requirements To Test Traceability Matrix

Trường kiểm soát Giá trị
Artifact ID TMPL-VAL-TRACE-001
Tên tệp được kiểm soát /03-templates/TMPL-VAL-TRACE-001_requirements-to-test-traceability-matrix.md
Tiêu đề artifact Tmpl Val Trace 001 Requirements To Test Traceability Matrix
Status IN_REVIEW
Version v0.9.0
Owner Principal IT Business Analyst / Technical Curriculum Author
Last updated date 2026-08-07
Múi giờ quản trị Asia/Ho_Chi_Minh
Locale vi-VN; bối cảnh Việt Nam; tiền tệ mô phỏng VND
Phân loại artifact Four-tier controlled template: template kiểm soát bốn tầng cho ma trận truy vết từ yêu cầu đến kiểm thử
Case study Nova Foods Trading & Manufacturing — mô phỏng giáo dục
Dữ liệu Chỉ dữ liệu tổng hợp. Mọi tên, mã, ngày, số lượng, tiền tệ, quy trình, vai trò và bằng chứng Nova Foods trong artifact là dữ liệu mô phỏng.
Baseline reference Chưa có baseline reference tại v0.9.0. IN_REVIEW không đồng nghĩa BASELINED.
Approval reference Chưa có approval reference. Metadata, Owner, nội dung mẫu hoặc trạng thái review không tạo phê duyệt ngầm định.

Owner duy trì định danh, đường dẫn, trạng thái, phiên bản, ngày cập nhật và lịch sử thay đổi của artifact. Owner bảo toàn liên kết quản trị với manifest và registry canonical, nhưng không xác nhận yêu cầu Nova Foods là đúng cho vận hành thực tế, không tự thiết lập baseline, không phê duyệt kiểm thử, không xác nhận tuân thủ pháp lý, kế toán, thuế, an toàn thực phẩm, bảo mật hoặc cho phép production.

Ranh giới dữ liệu mô phỏng áp dụng cho toàn bộ bốn tầng. Tier 2 chỉ được dùng chỗ điền mô tả dạng <...>. Tier 3 phải điền đủ dữ liệu tổng hợp Nova Foods, không được diễn giải dữ liệu đó là hồ sơ ERP thật, bằng chứng kiểm thử thật, giao dịch thật hoặc quyết định đã được tổ chức thật phê duyệt. Mọi tham chiếu nguồn pháp lý, chuẩn, đặc tả hoặc good practice chỉ phục vụ học liệu; kết luận áp dụng thực tế cần vai trò có thẩm quyền xác minh.

Phiên bản Ngày Trạng thái Thay đổi
v0.9.0 2026-08-07 IN_REVIEW Khởi tạo /03-templates/TMPL-VAL-TRACE-001_requirements-to-test-traceability-matrix.md; thiết lập metadata quản trị, lịch sử thay đổi khởi tạo và ranh giới dữ liệu Nova Foods mô phỏng.

1. Tier 1 ? Metadata, Purpose, and Governance

Mục đích, điều kiện sử dụng và thẩm quyền

Ma trận truy vết yêu cầu đến kiểm thử (Requirements-to-Test Traceability Matrix, RTM) nối mỗi yêu cầu với bằng chứng kiểm thử. Mục đích: phát hiện yêu cầu chưa có kiểm thử, kiểm thử không có test basis, hoặc thay đổi chưa được đánh giá ảnh hưởng. Trong corpus Nova Foods Trading & Manufacturing mô phỏng, RTM là công cụ học tập có kiểm soát; mọi tên, ID, quy trình và dữ liệu đều tổng hợp, không chứng minh cấu hình ERP, tuân thủ hay quyết định vận hành thực.

Nội dung Quy định áp dụng
Dùng khi Có requirement, business rule, acceptance criterion, data requirement, interface requirement hoặc non-functional requirement cần liên kết tới test condition, test case, test result hay defect. Dùng trước review phạm vi kiểm thử, trước đánh giá thay đổi, và khi bàn giao test basis.
Không dùng khi Chưa có nguồn yêu cầu xác định; chỉ có ý tưởng chưa được ghi nhận; cần mô hình hóa quy trình BPMN; cần đặc tả API OpenAPI; cần quyết định pháp lý, kế toán, thuế, an toàn thực phẩm, bảo mật hoặc vận hành production. RTM không thay thế các artifact và thẩm quyền này.
Owner Principal IT Business Analyst / Technical Curriculum Author duy trì cấu trúc template, tính nhất quán ID, liên kết và lịch sử thay đổi. Owner không được tự xác nhận requirement Nova Foods, baseline, approval, legal/compliance sign-off hay production readiness.
Người dùng Business Analyst lập và cập nhật liên kết; QA/Test Analyst thiết kế, thực thi và ghi kết quả kiểm thử; Business Owner xác nhận ý nghĩa nghiệp vụ; Technical Architect xác nhận ảnh hưởng kỹ thuật; Security, Legal, Accounting, Compliance hoặc Food Safety Owner xác nhận nội dung thuộc chuyên môn tương ứng.
Đầu vào bắt buộc Requirement có ID canonical; nguồn yêu cầu; phiên bản hoặc trạng thái nguồn; acceptance criterion hoặc business rule liên quan; phạm vi release mô phỏng; test basis đủ để thiết kế kiểm thử. Thiếu một đầu vào, ghi khoảng trống và escalation; không tự tạo rule hoặc tiêu chí chấp nhận.
Đầu ra hạ nguồn Test case, test execution evidence, defect log, coverage review, impact assessment và quyết định phạm vi test. Các artifact hạ nguồn phải giữ ID requirement và ID RTM liên quan để truy ngược được.
Tiêu chí đủ dùng Mỗi requirement trong phạm vi có ít nhất một liên kết kiểm thử hoặc có lý do loại trừ được ghi rõ; mỗi test case truy về một test basis; liên kết nêu trạng thái, phiên bản và nguồn. Đây là tiêu chí đầy đủ truy vết, không phải xác nhận chất lượng hay phê duyệt.

RTM không tạo ra yêu cầu mới. Lý do: requirement là nguồn quyết định, còn RTM chỉ ghi quan hệ kiểm soát giữa nguồn đó và kiểm thử. Ví dụ, nếu một test case phát hiện thiếu điều kiện xử lý lô hàng, BA ghi gap và tham chiếu requirement nguồn; không viết mới business rule trong ô truy vết.

Tình huống Thẩm quyền quyết định Hành động RTM
Requirement hoặc ID không khớp nguồn canonical Principal IT Business Analyst / Technical Curriculum Author phối hợp owner nguồn Dừng liên kết bị ảnh hưởng; đối chiếu /01-curriculum/TRACEABILITY_ID_REGISTRY.md; không đổi ID cục bộ.
Business rule mơ hồ hoặc xung đột Business Owner; Legal, Accounting, Compliance hoặc Food Safety Owner khi thuộc lĩnh vực đó Ghi issue, nguồn, tác động test và câu hỏi quyết định; giữ nhãn Verification required nếu chưa xác minh.
Thay đổi API, dữ liệu, tích hợp hoặc kiến trúc Technical Architect Đánh dấu impact assessment; cập nhật liên kết sau quyết định kiến trúc được ghi nhận.
Thiếu test case hoặc kết quả test không đạt QA/Test Analyst; Business Owner khi cần quyết định chấp nhận rủi ro Ghi coverage gap hoặc defect; không đổi requirement để làm kết quả test trông đạt.
Yêu cầu liên quan dữ liệu cá nhân, bảo mật, hóa đơn, kế toán hoặc an toàn thực phẩm Owner chuyên môn tương ứng Escalation trước khi diễn đạt thành nghĩa vụ. Nguồn chuẩn hoặc luật chỉ là căn cứ tham chiếu; không thay thế xác minh chuyên môn.

Escalation bắt buộc khi một liên kết có thể bị hiểu là approval, baseline, kết luận pháp lý, xác nhận compliance hoặc cho phép production. Gói escalation phải nêu ID bị ảnh hưởng, nguồn hiện có, mâu thuẫn hoặc khoảng trống, test bị ảnh hưởng và vai trò cần quyết định. IN_REVIEW và v0.9.0 chỉ cho biết artifact đang được xem xét; không có approval ngầm định.

Ánh xạ manifest, định danh canonical, chương, nguồn và kiểm soát thay đổi

Template này có định danh canonical TMPL-VAL-TRACE-001 và chỉ được kiểm soát tại /03-templates/TMPL-VAL-TRACE-001_requirements-to-test-traceability-matrix.md. “Canonical” nghĩa là bản nguồn duy nhất được dùng để đối chiếu; bản sao, bản xuất PDF hoặc nội dung dán sang công cụ khác không được thay thế tệp này. Cơ sở đối chiếu là TEMPLATE_MANIFEST, vì manifest là danh mục có kiểm soát cho template corpus.

Hạng mục ánh xạ Giá trị phải giữ nguyên Căn cứ và cách dùng
Template ID TMPL-VAL-TRACE-001 ID liên kết requirement, acceptance criterion, test case, kết quả kiểm thử và bằng chứng. Không đổi thành biến thể như TMPL-TRACE-001.
Tệp canonical /03-templates/TMPL-VAL-TRACE-001_requirements-to-test-traceability-matrix.md Đường dẫn xác định đúng artifact cần review. Tên tệp và ID phải cùng trỏ một template.
Manifest identity TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md Manifest xác định template là artifact dự kiến có kiểm soát; không suy diễn rằng template đã baseline hoặc được phê duyệt.
Registry ID TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md Registry quản lý dạng và tính duy nhất của các ID truy vết. Matrix chỉ tham chiếu ID đã đăng ký; không tự tạo ID cạnh tranh.
Quy tắc nghiệp vụ CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md Khi một test kiểm chứng business rule, dòng matrix phải liên kết ID rule canonical, không chép lại rule rồi coi bản chép là nguồn chân lý.
Dữ liệu logic CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md Khi test cần trường dữ liệu, trạng thái hoặc miền giá trị, tham chiếu data element canonical. Không biến matrix thành từ điển dữ liệu thứ hai.
Chương curriculum CHAPTER_MANIFEST tại /01-curriculum/CHAPTER_MANIFEST.md Chỉ dùng chapter ID và đường dẫn chapter đã đăng ký trong manifest. Nếu chưa có entry phù hợp, ghi vấn đề truy vết và escalation; không tự đặt chapter ID.
Kiến trúc học liệu 01_CURRICULUM_ARCHITECTURE tại /01-curriculum/01_CURRICULUM_ARCHITECTURE.md Dùng để kiểm tra chuỗi học từ requirement đến test có đúng dependency. Matrix không tự thay đổi thứ tự học hay phạm vi chapter.

Nguồn phương pháp kiểm thử chính là ISTQB CTFL Syllabus v4.0.1, phân loại nguồn sơ cấp cho thuật ngữ testing và kỹ thuật black-box. Nguồn này hỗ trợ cách gọi requirement, test basis, test condition, test case và kết quả test; không tạo rule ERP Nova Foods. BABOK Guide Version 3 là nguồn sơ cấp nghề nghiệp BA cho thuật ngữ và hoạt động phân tích nghiệp vụ. ISO/IEC/IEEE 29148:2018 là nguồn tiêu chuẩn tham khảo cho thực hành requirements; chỉ dùng thông tin thư mục và abstract đã xác minh, không gán số điều khoản khi chưa kiểm tra văn bản được cấp phép.

Nếu dòng matrix truy vết API, dùng OpenAPI Specification OAS 3.1.1, phân loại nguồn đặc tả chuẩn. Nếu truy vết khả năng tiếp cận, dùng WCAG 2.2, phân loại khuyến nghị chuẩn. Nếu truy vết bảo mật, dùng OWASP ASVS 5.0.0 hoặc OWASP API Security Top 10 2023, phân loại good practice ngành; không diễn đạt các nguồn OWASP là luật Việt Nam. Các nguồn pháp lý Việt Nam chỉ là nguồn pháp lý chính thức; mọi requirement suy ra từ chúng phải giữ nhãn Verification required cho Legal Owner hoặc vai trò chuyên môn phù hợp.

Mỗi thay đổi làm ảnh hưởng ID, đường dẫn, liên kết chapter, nguồn, requirement, rule, data element, test case hoặc bằng chứng phải được ghi nhận trong change history của artifact và được kiểm tra chéo với TEMPLATE_MANIFEST cùng TRACEABILITY_ID_REGISTRY. Không sửa im lặng, không tái sử dụng ID cho nghĩa khác, không thay nguồn canonical bằng bản sao. IN_REVIEW tại v0.9.0 không phải baseline, approval, xác nhận tuân thủ hay quyền dùng production. Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi tên, ID minh họa và dữ liệu trong matrix chỉ dùng dữ liệu tổng hợp.

2. Tier 2 ? Blank Copy-Paste-Ready Template

Dùng mẫu này để lập Requirements-to-Test Traceability Matrix, tức ma trận truy vết từ yêu cầu đến kiểm thử. Mỗi dòng nối một yêu cầu với kiểm tra xác nhận tương ứng. Không điền dữ liệu thực, bí mật, thông tin cá nhân, quyết định pháp lý, kế toán hoặc vận hành chưa được nguồn canonical xác nhận. Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; chỉ dùng dữ liệu tổng hợp.

2.1. Thông tin kiểm soát

Trường Giá trị điền mẫu Hướng dẫn điền
Template ID <ID template canonical, ví dụ theo registry> Dùng ID đã đăng ký trong TRACEABILITY_ID_REGISTRY; không tự tạo biến thể.
Tên tệp được kiểm soát <đường dẫn tệp Markdown canonical> Giữ đúng đường dẫn corpus; không dùng bản sao làm nguồn kiểm soát.
Tiêu đề tài liệu <tên đầy đủ của traceability matrix> Nêu phạm vi nghiệp vụ, hệ thống hoặc phát hành được truy vết.
Status <IN_REVIEW hoặc trạng thái canonical khác được phép> IN_REVIEW không phải APPROVED, BASELINED hoặc quyền dùng production.
Version <phiên bản theo quy ước, ví dụ v0.9.0> Tăng version khi thay đổi nội dung kiểm soát; không sửa im lặng.
Ngày cập nhật <YYYY-MM-DD> Dùng ngày theo Asia/Ho_Chi_Minh.
Múi giờ <IANA timezone> Dùng Asia/Ho_Chi_Minh cho corpus Nova Foods.
Locale <locale> Dùng vi-VN nếu không có phạm vi khác được phê duyệt.
Tiền tệ mô phỏng <mã ISO 4217> Dùng VND khi giá trị tiền thuộc case study.
Owner <vai trò owner, không ghi tên cá nhân nếu không cần> Owner duy trì artifact; không tự xác nhận nghiệp vụ, pháp lý, kế toán, bảo mật hoặc production.
Case study <tên case study và nhãn mô phỏng> Ghi rõ dữ liệu tổng hợp, không phải dữ liệu doanh nghiệp thật.
Phạm vi truy vết <module, quy trình, release hoặc capability> Nêu ranh giới bao gồm và không bao gồm.
Test basis <danh sách artifact nguồn canonical> Test basis là cơ sở kiểm thử: requirement, rule, data dictionary, API contract hoặc tài liệu đã xác định khác.
Nguồn canonical <Artifact ID và đường dẫn nguồn> Không thay bằng bản sao, ảnh chụp hoặc diễn giải không có liên kết nguồn.
Quy tắc đọc matrix <mô tả cách đọc ID và quan hệ> Nêu một requirement có thể có nhiều test case; mỗi test case phải chỉ rõ test basis.

2.2. Ma trận truy vết trống

Trace ID Requirement ID Loại requirement Tóm tắt yêu cầu Nguồn canonical Rule ID Data element ID Acceptance criterion ID Test condition ID Test case ID Mức kiểm thử Kỹ thuật kiểm thử Kết quả mong đợi Trạng thái truy vết Ghi chú liên kết
<ID dòng truy vết duy nhất> <ID requirement canonical> <Functional hoặc Non-functional hoặc Constraint> <mệnh đề yêu cầu kiểm thử được, không diễn giải lại nguồn> <Artifact ID + heading hoặc mục nguồn> <Business rule ID hoặc N/A có lý do> <Data dictionary ID hoặc N/A có lý do> <Acceptance criterion ID hoặc Verification required> <ID điều kiện kiểm thử> <ID test case canonical> <Unit hoặc Integration hoặc System hoặc UAT> <Equivalence Partitioning hoặc Boundary Value Analysis hoặc Decision Table hoặc State Transition hoặc Exploratory> <quan sát đầu ra, trạng thái, dữ liệu hoặc thông báo có thể xác minh> <Complete hoặc Partial hoặc Gap hoặc Not applicable> <lý do quan hệ một-nhiều, giới hạn hoặc dependency>
<ID dòng truy vết duy nhất> <ID requirement canonical> <Functional hoặc Non-functional hoặc Constraint> <mệnh đề yêu cầu kiểm thử được, không diễn giải lại nguồn> <Artifact ID + heading hoặc mục nguồn> <Business rule ID hoặc N/A có lý do> <Data dictionary ID hoặc N/A có lý do> <Acceptance criterion ID hoặc Verification required> <ID điều kiện kiểm thử> <ID test case canonical> <Unit hoặc Integration hoặc System hoặc UAT> <Equivalence Partitioning hoặc Boundary Value Analysis hoặc Decision Table hoặc State Transition hoặc Exploratory> <quan sát đầu ra, trạng thái, dữ liệu hoặc thông báo có thể xác minh> <Complete hoặc Partial hoặc Gap hoặc Not applicable> <lý do quan hệ một-nhiều, giới hạn hoặc dependency>

2.3. Hướng dẫn điền từng dòng

Trace ID là định danh duy nhất của quan hệ truy vết, không phải ID requirement hay ID test case. Giữ nguyên ID sau khi tạo; nếu quan hệ thay đổi nghĩa, đóng dòng cũ theo cơ chế kiểm soát rồi tạo dòng mới. Không tái sử dụng ID.

Requirement ID phải tham chiếu requirement đã tồn tại trong artifact canonical. Loại requirement chỉ nhận Functional, Non-functional hoặc Constraint. Chọn Constraint khi nội dung giới hạn giải pháp, tiêu chuẩn, môi trường hoặc quy định; không dùng nhãn này để che thiếu yêu cầu.

Tóm tắt yêu cầu phải đủ để reviewer hiểu mục tiêu kiểm thử, nhưng không thay thế requirement gốc. Nguồn canonical phải chỉ ra Artifact ID và vị trí có thể tìm lại. Nếu nguồn là luật, chuẩn hoặc good practice, ghi đúng phân loại nguồn và giữ Verification required khi kết luận cần Legal Owner, Accounting Owner, Security hoặc vai trò chuyên môn khác xác nhận.

Rule ID, Data element ID và Acceptance criterion ID chỉ nhận ID canonical hoặc N/A có lý do. Không để trống. N/A hợp lệ khi requirement không dùng quy tắc, dữ liệu logic hoặc acceptance criterion; ghi lý do cụ thể để phân biệt không áp dụng với thiếu nguồn.

Test condition ID xác định điều kiện cần kiểm tra, ví dụ nhóm đầu vào, trạng thái trước xử lý hoặc nhánh quyết định. Test case ID xác định ca kiểm thử thực thi được. Một requirement có nhiều điều kiện và nhiều test case khi có nhiều nhánh, biên dữ liệu, vai trò hoặc kết quả cần xác minh.

Mức kiểm thử chỉ nhận Unit, Integration, System hoặc UAT. Chọn mức thấp nhất có thể chứng minh yêu cầu mà không bỏ sót tích hợp cần thiết. Kỹ thuật kiểm thử phải nêu kỹ thuật black-box phù hợp; không ghi kỹ thuật nếu không có điều kiện hoặc dữ liệu dùng kỹ thuật đó.

Kết quả mong đợi phải quan sát được và đối chiếu được với test basis. Không ghi nhận xét chủ quan như <hệ thống hoạt động đúng>. Trạng thái truy vết chỉ nhận Complete, Partial, Gap hoặc Not applicable; Complete chỉ dùng khi liên kết requirement, test basis, điều kiện, test case và kết quả mong đợi đều có mặt.

Ghi chú liên kết giải thích quan hệ nhiều-nhiều, dependency hoặc giới hạn. Không ghi secret, token, mật khẩu, khóa API, chuỗi kết nối, số định danh cá nhân hoặc dữ liệu thật. Khi cần tham chiếu bí mật, dùng mẫu <secret reference: vault://<vault-name>/<secret-path>; không ghi secret value>; chỉ ghi đường dẫn tham chiếu được phép công bố.

Ma trận truy vết yêu cầu đến kiểm thử — mẫu bảng đầy đủ

Dùng một dòng cho mỗi liên kết giữa yêu cầu và kiểm thử. Traceability matrix là ma trận truy vết: bằng chứng rằng mỗi yêu cầu có kiểm thử phù hợp, và mỗi kiểm thử có lý do tồn tại. Nova Foods là case mô phỏng giáo dục; chỉ nhập dữ liệu tổng hợp. Không ghi bí mật, mật khẩu, token, khóa API, dữ liệu cá nhân thật hoặc URL nội bộ không được phép.

Trường Giá trị mẫu cần điền Hướng dẫn và quy tắc kiểm tra
Trace ID <TRC-định_danh_duy_nhất> Bắt buộc. Dùng ID canonical đã đăng ký trong TRACEABILITY_ID_REGISTRY. Một ID không dùng lại.
Requirement ID <FR-hoặc-NFR-ID-canonical> Bắt buộc. Tham chiếu yêu cầu chức năng FR hoặc phi chức năng NFR; không tự tạo biến thể ID.
Requirement title <tên_yêu_cầu_ngắn> Bắt buộc. Phải khớp tiêu đề nguồn requirement.
Requirement source <artifact_ID>; <đường_dẫn_tệp>; <mục/ID> Bắt buộc. Nêu nguồn kiểm soát, ví dụ artifact canonical; không dùng ghi nhớ cá nhân làm nguồn.
Source classification <CANONICAL_RULE\|PROJECT_ASSUMPTION\|VERIFICATION_REQUIRED\|EXTERNAL_STANDARD_REFERENCE> Bắt buộc. Chọn đúng một giá trị. VERIFICATION_REQUIRED không được diễn đạt thành nghĩa vụ đã xác nhận.
Business rule ID <BR-ID-canonical hoặc N/A> Điền ID quy tắc từ CANONICAL_BUSINESS_RULES; dùng N/A khi yêu cầu không áp dụng quy tắc nghiệp vụ.
Data reference <entity.field hoặc N/A> Tham chiếu từ CANONICAL_DATA_DICTIONARY; không suy diễn kiểu dữ liệu hay giá trị hợp lệ.
Process reference <BPMN/UML/artifact-ID hoặc N/A> Điền liên kết quy trình hoặc mô hình. Chỉ gọi là BPMN khi nguồn dùng ký pháp BPMN hợp lệ.
Acceptance criteria ID <AC-ID-canonical> Bắt buộc. Mỗi dòng phải có tiêu chí chấp nhận kiểm thử được.
Test case ID <TC-ID-canonical> Bắt buộc. Một yêu cầu có thể liên kết nhiều test case qua nhiều dòng.
Test level <UNIT\|INTEGRATION\|SYSTEM\|UAT\|SECURITY\|ACCESSIBILITY> Bắt buộc. Chọn một mức chính; tách dòng khi cùng test case phục vụ mức khác.
Test technique <EQUIVALENCE_PARTITIONING\|BOUNDARY_VALUE_ANALYSIS\|DECISION_TABLE\|STATE_TRANSITION\|ERROR_GUESSING\|CHECKLIST> Bắt buộc. Kỹ thuật kiểm thử là cách chọn điều kiện kiểm thử; chọn kỹ thuật phù hợp rủi ro.
Preconditions <điều_kiện_trước_khi_kiểm_thử> Bắt buộc. Nêu vai trò, trạng thái dữ liệu và cấu hình mô phỏng cần có.
Test data reference <TESTDATA-ID>; synthetic Bắt buộc. Chỉ dữ liệu tổng hợp. Không ghi giá trị bí mật; tham chiếu <SECRET-REF-ID> nếu có cấu hình nhạy cảm.
Expected result <kết_quả_quan_sát_được> Bắt buộc. Phải đo hoặc xác nhận được; không dùng “hệ thống hoạt động đúng”.
Priority <P1\|P2\|P3\|P4> Bắt buộc. P1 chặn mục tiêu nghiệp vụ, an toàn, bảo mật hoặc nghĩa vụ đã xác minh; P4 có tác động thấp.
Risk ID <RSK-ID-canonical hoặc N/A> Điền rủi ro liên quan. N/A chỉ hợp lệ khi đánh giá rủi ro đã ghi trong nguồn requirement.
Coverage status <NOT_COVERED\|PLANNED\|EXECUTED_PASS\|EXECUTED_FAIL\|BLOCKED\|NOT_APPLICABLE> Bắt buộc. NOT_APPLICABLE cần lý do và reviewer xác nhận trong bảng quyết định.
Defect ID <DEF-ID-canonical hoặc N/A> Điền khi kết quả EXECUTED_FAIL; nếu không có defect, ghi N/A.
Evidence ID <EVD-ID-canonical> Bắt buộc khi EXECUTED_PASS, EXECUTED_FAIL hoặc BLOCKED; PLANNED dùng <EVD-ID-dự_kiến>.
Evidence location <đường_dẫn_kho_lưu_được_phép hoặc URL_được_phép> Chỉ liên kết vị trí kiểm soát. Không nhúng ảnh chụp chứa bí mật hoặc dữ liệu cá nhân.
Evidence hash <SHA-256 hoặc N/A> Điền SHA-256 khi bằng chứng là tệp cố định cần kiểm tra toàn vẹn; nếu không áp dụng ghi N/A.
Executor <vai_trò hoặc định_danh_người_thực_hiện_được_phép> Bắt buộc khi đã thực thi. Không dùng tên cá nhân nếu chính sách dữ liệu không cho phép.
Execution timestamp <YYYY-MM-DDThh:mm:ss+07:00 hoặc N/A> Dùng Asia/Ho_Chi_Minh. Chỉ điền sau thực thi.
Version tested <phiên_bản_build/cấu_hình hoặc N/A> Bắt buộc khi đã thực thi. Phải phân biệt version artifact v0.9.0 với version phần mềm kiểm thử.
Change reference <CR-ID-canonical hoặc N/A> Điền thay đổi làm phát sinh, sửa hoặc hủy liên kết.
Trace decision ID <TD-ID> Bắt buộc. Liên kết quyết định về phạm vi, ngoại lệ hoặc khả năng áp dụng.
Review status <NOT_REVIEWED\|IN_REVIEW\|REWORK_REQUIRED\|REVIEWED> Không dùng APPROVED nếu chưa có bản ghi sign-off hợp lệ.
Review reference <RVW-ID hoặc N/A> Bắt buộc khi trạng thái không phải NOT_REVIEWED.
Sign-off status <NOT_REQUESTED\|PENDING\|RECORDED\|REJECTED\|NOT_APPLICABLE> RECORDED chỉ hợp lệ khi có bản ghi ký xác nhận trong bảng sign-off.
Sign-off reference <SO-ID hoặc N/A> Bắt buộc khi RECORDED hoặc REJECTED.
Trace row version <vX.Y.Z> Bắt buộc. Tăng version khi thay đổi nội dung, liên kết, quyết định hoặc trạng thái.
Last updated <YYYY-MM-DD> Bắt buộc. Dùng ngày theo Asia/Ho_Chi_Minh.
Updated by role <BA\|QA\|Business Owner\|Technical Architect\|Security Reviewer\|Legal Owner\|Accounting Owner> Bắt buộc. Vai trò cập nhật không đồng nghĩa quyền phê duyệt.
Notes <ghi_chú_có_căn_cứ hoặc N/A> Ghi ngắn, có liên kết nguồn; không biến ghi chú thành yêu cầu mới.
Trace decision ID Câu hỏi quyết định Giá trị cho phép Bằng chứng bắt buộc Hành động khi không đạt
<TD-ID> Yêu cầu có test case? YES, NO, PARTIAL Requirement ID, AC ID, Test case ID NO hoặc PARTIAL: tạo khoảng trống truy vết, giữ NOT_COVERED hoặc PLANNED.
<TD-ID> Test case kiểm tra đúng acceptance criteria? YES, NO Bước kiểm thử và expected result NO: không ghi coverage; sửa test hoặc làm rõ AC.
<TD-ID> Ngoại lệ có cần test riêng? YES, NO Điều kiện ngoại lệ, rule, rủi ro YES: tạo dòng trace riêng cho test ngoại lệ.
<TD-ID> Nguồn có cần xác minh chuyên môn? YES, NO Source classification, nguồn chính thức YES: gắn VERIFICATION_REQUIRED, giao đúng owner.
<TD-ID> Có thể dùng NOT_APPLICABLE? YES, NO Lý do, phạm vi, reviewer YES: ghi lý do cụ thể; không dùng để che thiếu coverage.
<TD-ID> Có thể ghi sign-off RECORDED? YES, NO SO-ID, vai trò, ngày, phạm vi NO: giữ PENDING, REJECTED hoặc NOT_REQUESTED.
Exception ID Điều kiện kích hoạt Phân loại Tác động traceability Xử lý bắt buộc Owner cần tham gia Trạng thái
<EXC-ID> <requirement thiếu AC> MISSING_ACCEPTANCE_CRITERIA Không thể xác nhận coverage Giữ NOT_COVERED; yêu cầu làm rõ nguồn Business Owner, BA <OPEN\|RESOLVED\|ESCALATED>
<EXC-ID> <rule có yếu tố pháp lý, thuế, kế toán, dữ liệu cá nhân hoặc an toàn thực phẩm> SPECIALIST_VERIFICATION_REQUIRED Không được suy diễn expected result bắt buộc Gắn VERIFICATION_REQUIRED; escalation đúng owner Legal Owner, Accounting Owner, Compliance Owner <OPEN\|RESOLVED\|ESCALATED>
<EXC-ID> <test cần secret hoặc quyền truy cập nhạy cảm> SECRET_OR_ACCESS_RESTRICTION Bằng chứng không được chứa secret Dùng <SECRET-REF-ID> trỏ kho bí mật được phép; che giá trị nhạy cảm Security Reviewer, Technical Architect <OPEN\|RESOLVED\|ESCALATED>
<EXC-ID> <test bị chặn bởi môi trường hoặc dữ liệu> TEST_BLOCKED Không được ghi EXECUTED_PASS Ghi BLOCKED, EVD-ID và điều kiện gỡ chặn QA, Technical Architect <OPEN\|RESOLVED\|ESCALATED>
<EXC-ID> <nguồn canonical mâu thuẫn với artifact khác> SOURCE_CONFLICT Trace không có nguồn chân lý ổn định Dừng cập nhật kết luận; lập gói escalation kèm các nguồn mâu thuẫn Principal IT Business Analyst / Technical Curriculum Author, owner chuyên môn <OPEN\|RESOLVED\|ESCALATED>
Evidence ID Loại bằng chứng Nội dung tối thiểu Phân loại dữ liệu Kiểm tra hợp lệ
<EVD-ID> <TEST_RUN_LOG\|SCREENSHOT\|API_RESPONSE\|QUERY_RESULT\|DEFECT_RECORD\|REVIEW_RECORD> Trace ID, Test case ID, thời điểm, người hoặc vai trò thực hiện, kết quả <PUBLIC\|INTERNAL\|RESTRICTED> Bằng chứng khớp Version tested, không lộ secret, truy cập được theo quyền.
<SECRET-REF-ID> SECRET_REFERENCE Tên tham chiếu, owner kho bí mật, mục đích sử dụng, ngày hết hạn nếu có RESTRICTED Chỉ ghi tham chiếu, ví dụ <vault://approved-path/secret-name>; không ghi giá trị bí mật.
Trace row version Ngày Loại thay đổi Mô tả thay đổi Change reference Người cập nhật theo vai trò Review reference
<vX.Y.Z> <YYYY-MM-DD> <CREATED\|UPDATED\|RETIRED\|CORRECTED> <mô_tả_thay_đổi_có_thể_kiểm_tra> <CR-ID hoặc N/A> <vai_trò> <RVW-ID hoặc N/A>
Review ID Phạm vi review Reviewer role Tiêu chí review Kết quả Nhận xét có bằng chứng Ngày review
<RVW-ID> <Trace ID hoặc phạm_vi_ma_trận> <BA\|QA\|Business Owner\|Technical Architect\|Security Reviewer\|Legal Owner\|Accounting Owner> <đủ_liên_kết\|đúng_nguồn\|đủ_bằng_chứng\|đúng_phân_loại> <REVIEWED\|REWORK_REQUIRED> <nguồn/ID/lý_do> <YYYY-MM-DD>
Sign-off ID Phạm vi Vai trò có thẩm quyền Quyết định Căn cứ Ngày ghi nhận Giới hạn hiệu lực
<SO-ID> <Trace ID hoặc phạm_vi_ma_trận> <vai_trò_được_ủy_quyền> <RECORDED\|REJECTED> <RVW-ID; EVD-ID; nguồn liên quan> <YYYY-MM-DD> <phạm_vi_cụ_thể; không_suy_diễn_thành_baseline_hoặc_production_approval>

Quy tắc toàn vẹn: EXECUTED_PASS cần Test case ID, Expected result, Evidence ID, Executor, Execution timestamp và Version tested. EXECUTED_FAIL cần thêm Defect ID hoặc Exception ID. BLOCKED cần Exception ID và điều kiện gỡ chặn. Mọi yêu cầu P1 phải có ít nhất một dòng trace không ở NOT_COVERED. IN_REVIEW, REVIEWED và RECORDED là trạng thái theo bản ghi; không tự tạo baseline, tuân thủ pháp lý, phê duyệt người dùng hoặc quyền triển khai production.

Hướng dẫn trường, giá trị hợp lệ, quy tắc kiểm tra và tham chiếu bí mật an toàn

Mỗi dòng ma trận là một đơn vị truy vết: chứng minh yêu cầu nào được kiểm thử bởi trường hợp kiểm thử nào, bằng chứng nào xác nhận kết quả. Không suy ra liên kết từ tên gần giống. Liên kết chỉ hợp lệ khi dùng ID canonical và có căn cứ nguồn ghi rõ. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu điền vào mẫu là dữ liệu tổng hợp.

Trường mẫu Điền giá trị Giá trị hợp lệ hoặc mẫu Quy tắc kiểm tra
Traceability Row ID <ID dòng truy vết duy nhất, ví dụ RTM-001> ID đã đăng ký trong TRACEABILITY_ID_REGISTRY Bắt buộc; không trùng; không đổi ID khi sửa nội dung.
Requirement ID <ID yêu cầu canonical> ID requirement đã tồn tại trong nguồn canonical Bắt buộc; không dùng tiêu đề requirement thay ID. Nếu chưa có ID, dừng liên kết và ghi vào Open Issue ID.
Requirement Version <phiên bản requirement, ví dụ v0.9.0> Chuỗi version nguồn Bắt buộc; phải khớp phiên bản tại thời điểm review.
Requirement Source <đường dẫn tệp canonical> Đường dẫn corpus bắt đầu bằng / Bắt buộc; không dùng bản sao cục bộ, ảnh chụp, chat hoặc URL không kiểm soát làm nguồn canonical.
Requirement Type <loại yêu cầu> Business, Stakeholder, Functional, Non-functional, Data, Interface, Reporting, Security, Compliance Chọn một loại chính. Nếu một yêu cầu có nhiều loại, giữ loại chính và nêu loại phụ trong Notes.
Business Rule ID <ID quy tắc hoặc N/A> ID trong CANONICAL_BUSINESS_RULES hoặc N/A Chỉ dùng N/A khi requirement không áp dụng quy tắc. Không tự tạo quy tắc từ test case.
Data Element ID <ID phần tử dữ liệu hoặc N/A> ID trong CANONICAL_DATA_DICTIONARY hoặc N/A Bắt buộc với Data, Interface, Reporting, Security; nêu lý do khi dùng N/A.
Test Case ID <ID test case canonical> ID test case duy nhất Bắt buộc; một requirement có thể liên kết nhiều test case qua nhiều dòng.
Test Level <cấp kiểm thử> Unit, Integration, System, System Integration, User Acceptance, Regression, Security, Accessibility Chọn theo mục tiêu kiểm thử, không theo người thực hiện. Unit không đủ làm bằng chứng duy nhất cho requirement nghiệp vụ end-to-end.
Test Technique <kỹ thuật kiểm thử> Equivalence Partitioning, Boundary Value Analysis, Decision Table Testing, State Transition Testing, Use Case Testing, Exploratory Testing, Checklist-based Testing Nêu kỹ thuật khi test có dữ liệu đầu vào hoặc quyết định. Dùng thuật ngữ theo ISTQB CTFL; không tuyên bố tuân thủ chứng chỉ.
Test Status <trạng thái> Not Run, Blocked, Passed, Failed, Retest Passed, Retest Failed, Not Applicable Passed phải có Evidence ID. Not Applicable phải có lý do và reviewer xác nhận. Blocked phải có Dependency hoặc Defect ID.
Coverage Status <trạng thái bao phủ> Covered, Partially Covered, Not Covered, Not Applicable Covered cần ít nhất một test case đạt và đủ acceptance criteria. Partially Covered phải nêu phần chưa kiểm thử.
Acceptance Criteria Reference <ID hoặc mục acceptance criteria> ID canonical hoặc định vị chính xác trong nguồn Bắt buộc nếu requirement có acceptance criteria. Không chép lại nội dung rồi bỏ liên kết nguồn.
Evidence ID <ID bằng chứng hoặc N/A> ID bằng chứng duy nhất Bắt buộc khi Test Status là Passed, Failed, Retest Passed, Retest Failed. N/A chỉ hợp lệ khi Not Run, Blocked, Not Applicable.
Evidence Location <đường dẫn kiểm soát hoặc URL nội bộ an toàn> Đường dẫn repository kiểm soát, hệ thống quản lý test, kho bằng chứng được cấp quyền Không ghi dữ liệu cá nhân, token, mật khẩu, cookie, API key, chuỗi kết nối DB, ảnh chứa bí mật.
Defect ID <ID lỗi hoặc N/A> ID lỗi duy nhất hoặc N/A Bắt buộc khi Test Status là Failed, Retest Failed hoặc Blocked do lỗi.
Risk Level <mức rủi ro> Critical, High, Medium, Low Dựa trên tác động và khả năng xảy ra được ghi trong nguồn rủi ro. Không tự gán Critical chỉ vì lỗi kỹ thuật.
Open Issue ID <ID vấn đề mở hoặc N/A> ID issue duy nhất hoặc N/A Bắt buộc khi thiếu nguồn, xung đột rule, thiếu quyền truy cập, chưa rõ owner, hoặc cần xác minh pháp lý, kế toán, bảo mật.
Owner Role <vai trò chịu trách nhiệm> Business Owner, BA, QA, Developer, Architect, Security Owner, Legal Owner, Accounting Owner, Compliance Owner Ghi vai trò, không ghi nhận approval cá nhân. Owner xử lý việc mở không đồng nghĩa người phê duyệt.
Review Status <trạng thái review> Not Submitted, In Review, Changes Requested, Reviewed, Approved, Rejected Không dùng Approved nếu không có Approval Reference ghi nhận. IN_REVIEW cấp tài liệu không biến từng dòng thành Reviewed.
Approval Reference <tham chiếu phê duyệt hoặc N/A> ID bản ghi phê duyệt kiểm soát hoặc N/A Không điền tên người, email, lời nói, chat hoặc suy đoán. Với corpus hiện hành, dùng N/A trừ khi artifact nguồn ghi nhận rõ.
Last Updated <YYYY-MM-DD HH:mm Asia/Ho_Chi_Minh> Thời điểm ISO cục bộ, múi giờ Asia/Ho_Chi_Minh Bắt buộc; không dùng thời điểm máy cá nhân không có múi giờ.
Notes <lý do, giới hạn, giả định hoặc quyết định> Văn bản ngắn, kiểm chứng được Phải nêu cầu nối suy luận: nguồn nào, nội dung nào, vì sao dẫn đến trạng thái dòng.
Điều kiện Phần điều kiện phải điền Quy tắc quyết định
Requirement liên quan API hoặc tích hợp Interface Reference, Request/Response Evidence, Authentication Method, Error Scenario Không ghi token thật. Liên kết OpenAPI hoặc hợp đồng interface canonical nếu có.
Requirement liên quan dữ liệu cá nhân Data Classification, Privacy Verification Required, Legal Owner Gắn Verification required; không kết luận tuân thủ pháp luật. Tham chiếu nguồn luật chỉ là căn cứ cần xác minh bởi Legal Owner.
Requirement liên quan kế toán, thuế, hóa đơn Accounting/Legal Verification Required, Accounting Owner, Legal Owner Gắn Verification required. Không diễn giải luật thành rule ERP nếu chưa có nguồn canonical và owner có thẩm quyền.
Requirement liên quan an toàn thực phẩm hoặc truy xuất nguồn gốc Food Safety Verification Required, Domain Owner, Legal Owner Gắn Verification required; nêu requirement, rule hoặc nguồn nào tạo nhu cầu xác minh.
Test bị chặn Blocker Description, Dependency ID, Open Issue ID, Owner Role Không dùng Passed hoặc Not Applicable để che trạng thái chặn.
Không áp dụng test Not Applicable Reason, Reviewer Role, Review Status Lý do phải chỉ rõ vì sao requirement không cần test tại cấp đã chọn; không được để trống.
Có ngoại lệ nghiệp vụ Exception ID, Exception Trigger, Expected Handling, Evidence ID Ngoại lệ phải liên kết requirement hoặc business rule; không biến lỗi hệ thống thành ngoại lệ nghiệp vụ.

Mẫu tham chiếu bí mật an toàn. Dùng <secret-reference: vault://<approved-vault-path>#<secret-name>> hoặc <credential-reference: <approved-secret-manager-record-id>>. Chỉ ghi định danh tham chiếu, không ghi giá trị bí mật. Cấm điền mật khẩu, API key, bearer token, private key, cookie phiên, chuỗi kết nối, mã OTP, số tài khoản thật, dữ liệu cá nhân thật vào ma trận, ảnh bằng chứng hoặc Notes. Nếu bằng chứng cần xác minh xác thực, ghi <evidence-redacted-reference: <controlled-evidence-id>>; QA hoặc Security Owner kiểm tra trong kho được cấp quyền.

Kiểm tra dòng trước review. Requirement ID, Test Case ID, Coverage Status, Test Status, Owner Role, Last Updated luôn bắt buộc. Evidence ID bắt buộc khi có kết quả chạy test. Mọi N/A, Partially Covered, Not Covered, Blocked, Failed, Retest Failed phải có lý do truy vết được trong Notes hoặc trường điều kiện. Nếu ID, nguồn, phiên bản hoặc thẩm quyền chưa xác minh, đặt Coverage Status là Not Covered, tạo Open Issue ID, giữ Review Status là In Review; không suy diễn hoàn tất, baseline hay phê duyệt.

3. Tier 3 ? Fully Completed Nova Foods Case: Core Record

Traceability matrix là ma trận liên kết yêu cầu với kiểm thử để biết mỗi nhu cầu có được kiểm tra hay chưa. Case dưới là Nova Foods Trading & Manufacturing mô phỏng giáo dục; toàn bộ người, giao dịch, mã và dữ liệu là tổng hợp.

Trường kiểm soát Giá trị hoàn chỉnh
Artifact ID TMPL-VAL-TRACE-001
Tên tệp /03-templates/TMPL-VAL-TRACE-001_requirements-to-test-traceability-matrix.md
Status IN_REVIEW
Version v0.9.0
Ngày ghi nhận 2026-08-07
Locale và múi giờ vi-VN; Asia/Ho_Chi_Minh
Đơn vị tiền tệ VND
Phạm vi case Xác nhận đơn bán hàng nội địa cho khách hàng đại lý trước khi tạo lệnh giao hàng
Đơn vị mô phỏng Nova Foods Trading & Manufacturing
Transaction ID SO-NF-20260807-0042
Khách hàng mô phỏng Công ty TNHH Phân Phối An Khang
Mã khách hàng CUS-NF-000184
Người lập đơn Nguyễn Minh Khoa, Sales Executive mô phỏng
Người xét duyệt tín dụng Trần Hải Yến, Credit Controller mô phỏng
Kho xuất dự kiến WH-HCM-01 — Kho thành phẩm Hồ Chí Minh
Trạng thái giao dịch hiện tại Credit Hold
Tổng giá trị đơn trước VAT 48.600.000 VND
VAT mô phỏng 4.860.000 VND
Tổng thanh toán 53.460.000 VND
Phân loại nguồn case Nguồn nghiệp vụ mô phỏng; dữ liệu tổng hợp; project assumption
Ranh giới nguồn Không diễn giải luật thuế, kế toán, hóa đơn, dữ liệu cá nhân hoặc an toàn thực phẩm; cần Owner có thẩm quyền xác minh trước khi dùng production.
Approval reference Không có approval reference tại v0.9.0.

Dữ liệu đơn bán hàng mô phỏng

Dòng Mã hàng Tên hàng mô phỏng Đơn vị Số lượng Đơn giá chưa VAT Thành tiền chưa VAT Lô xuất dự kiến
SO-NF-20260807-0042-01 FG-NF-CHOCO-200 Nova Choco Cereal 200g Hộp 600 36.000 VND 21.600.000 VND LOT-NF-260701-A
SO-NF-20260807-0042-02 FG-NF-OAT-400 Nova Oat Drink 400ml Chai 900 30.000 VND 27.000.000 VND LOT-NF-260705-B
Tổng cộng Không áp dụng Không áp dụng Không áp dụng 1.500 Không áp dụng 48.600.000 VND Không áp dụng

Hồ sơ tín dụng mô phỏng

Trường Giá trị
Credit Account ID CRD-NF-000184
Hạn mức tín dụng được cấu hình mô phỏng 50.000.000 VND
Dư nợ mở trước đơn hàng 18.750.000 VND
Giá trị đơn chờ xác nhận 48.600.000 VND
Tổng phơi nhiễm sau xác nhận 67.350.000 VND
Mức vượt hạn mức 17.350.000 VND
Điều kiện thanh toán mô phỏng NET15
Ngày đến hạn hóa đơn cũ gần nhất 2026-07-18
Số ngày quá hạn tại ngày đánh giá 2026-08-07 20
Kết quả kiểm tra Không đạt kiểm tra tín dụng
Nguồn phân loại Nguồn nghiệp vụ mô phỏng; dữ liệu tổng hợp; project assumption

Dòng ma trận core record

Requirement ID Requirement Title Business Process Source ID Source Classification Actor Transaction ID Priority Requirement Status Test Case ID Test Status Coverage Status Owner Role Last Updated
REQ-NF-SO-001 Chặn xác nhận đơn khi tổng phơi nhiễm vượt hạn mức tín dụng Order-to-Cash SRC-NF-SIM-001 Nguồn nghiệp vụ mô phỏng; dữ liệu tổng hợp Sales Executive; Credit Controller SO-NF-20260807-0042 High In Review TC-NF-SO-001 Not Run Covered QA Analyst 2026-08-07
REQ-NF-SO-002 Hiển thị lý do chặn và giá trị vượt hạn mức cho Sales Executive Order-to-Cash SRC-NF-SIM-001 Nguồn nghiệp vụ mô phỏng; dữ liệu tổng hợp Sales Executive SO-NF-20260807-0042 Medium In Review TC-NF-SO-002 Not Run Covered QA Analyst 2026-08-07
REQ-NF-SO-003 Chỉ Credit Controller được phép giải tỏa Credit Hold trong case mô phỏng Order-to-Cash SRC-NF-SIM-002 Project assumption; cần Security Owner và Business Owner xác minh nếu dùng production Credit Controller SO-NF-20260807-0042 High In Review TC-NF-SO-003 Not Run Covered Security Reviewer 2026-08-07

Nguồn mô phỏng đã dùng

Source ID Tên nguồn Phân loại Nội dung dữ liệu tổng hợp Chủ sở hữu xác minh khi chuyển sang vận hành thật
SRC-NF-SIM-001 Nova Foods Sales Credit Workshop Notes Nguồn nghiệp vụ mô phỏng Hạn mức 50.000.000 VND, đơn hàng bị chặn khi tổng phơi nhiễm là 67.350.000 VND Business Owner; Credit Owner
SRC-NF-SIM-002 Nova Foods ERP Role Model Draft Project assumption Vai trò Credit Controller được giả định có quyền giải tỏa Credit Hold Security Owner; Business Owner; Architect

Hồ sơ lõi hoàn chỉnh: Ma trận truy vết yêu cầu đến kiểm thử Nova Foods

Phạm vi: Nova Foods Trading & Manufacturing mô phỏng giáo dục; toàn bộ tên người, giao dịch, mã lô, ngày và giá trị là dữ liệu tổng hợp. Artifact trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Ma trận truy vết yêu cầu đến kiểm thử (Requirements-to-Test Traceability Matrix, RTM) nối từng yêu cầu với quy tắc, dữ liệu, điều kiện chấp nhận và kiểm thử. Mục tiêu: không để yêu cầu bị xây nhưng không kiểm thử, hoặc kiểm thử nhưng không có lý do nghiệp vụ.

Trường lõi Giá trị hoàn chỉnh
Matrix ID TMPL-VAL-TRACE-001-NF-CORE-001
Artifact file /03-templates/TMPL-VAL-TRACE-001_requirements-to-test-traceability-matrix.md
Kịch bản Chặn xuất kho thành phẩm sữa yến mạch khi lô hàng chưa đạt trạng thái chất lượng RELEASED
Quy trình PROC-NF-OUTBOUND-001 — Xuất kho thành phẩm cho đơn bán
Giao dịch mô phỏng SO-NF-20260807-0142, khách hàng CUS-NF-0018, giá trị đơn 48.600.000 VND
Mặt hàng FG-OM-01L — Sữa yến mạch Nova 1L
Lô hàng LOT-OM-20260805-A, số lượng yêu cầu xuất 1.200 chai
Tồn khả dụng vật lý 1.500 chai tại kho WH-HCM-FG-01
Trạng thái lô hiện tại PENDING_QA
Chủ sở hữu nghiệp vụ mô phỏng ROLE-NF-WH-MANAGER — Trưởng kho
Chủ sở hữu chất lượng mô phỏng ROLE-NF-QA-MANAGER — Quản lý chất lượng
Người lập yêu cầu mô phỏng ACT-NF-BA-001 — Lê Minh Anh, Business Analyst
Phân loại nguồn Nguồn dự án mô phỏng; giả định nghiệp vụ giáo dục
Ranh giới nguồn Luật An toàn thực phẩm là bối cảnh cho truy xuất và thu hồi; quy tắc chặn xuất cụ thể dưới đây là giả định dự án, không phải diễn giải pháp luật hay cấu hình ERP thực tế.
ID yêu cầu Loại Phát biểu yêu cầu hoàn chỉnh Nhu cầu nền Hậu quả nếu sai Phân loại nguồn
BR-NF-INV-001 Business rule, quy tắc nghiệp vụ Hệ thống chỉ cho phép xác nhận xuất kho đối với lô thành phẩm có qualityStatus = RELEASED. Kho cần ngăn lô chưa kiểm tra hoặc bị giữ đi vào luồng giao khách. Xuất nhầm lô PENDING_QA hoặc BLOCKED; tăng rủi ro thu hồi và sai cam kết giao hàng. Giả định nghiệp vụ giáo dục
FR-NF-OUT-001 Functional requirement, yêu cầu chức năng Khi người dùng xác nhận xuất 1.200 chai của LOT-OM-20260805-A, ERP phải kiểm tra trạng thái chất lượng của đúng lô trước khi giảm tồn kho khả dụng. Kiểm soát phải xảy ra trước thay đổi tồn kho để tránh dữ liệu kho đã giảm rồi mới báo lỗi. Tồn kho sai; cần điều chỉnh thủ công; đơn giao có thể bị ghi nhận sai. Nguồn dự án mô phỏng
FR-NF-OUT-002 Functional requirement Nếu lô không có trạng thái RELEASED, ERP phải từ chối xác nhận xuất, giữ nguyên tồn kho 1.500 chai và hiển thị mã lỗi QA_LOT_NOT_RELEASED. Người dùng cần biết vì sao thao tác bị chặn và hệ thống không được làm mất dữ liệu. Nhân viên lặp thao tác, ghi xuất ngoài hệ thống hoặc không biết lô nào cần xử lý. Nguồn dự án mô phỏng
NFR-NF-AUD-001 Non-functional requirement, yêu cầu phi chức năng ERP phải ghi audit log cho mọi lần kiểm tra bị từ chối: thời gian, người dùng, đơn bán, kho, mã hàng, mã lô, số lượng yêu cầu, trạng thái chất lượng và mã lỗi. Truy vết cần trả lời ai đã thử xuất lô nào, khi nào, với kết quả gì. Không điều tra được sai lệch; không đủ dữ liệu đối chiếu vận hành mô phỏng. Giả định nghiệp vụ giáo dục
AC-NF-OUT-001 Acceptance criterion, tiêu chí chấp nhận Với LOT-OM-20260805-A có qualityStatus = PENDING_QA, xác nhận xuất 1.200 chai phải bị từ chối; không tạo phiếu xuất; tồn khả dụng vẫn là 1.500; audit log được tạo. Tiêu chí biến yêu cầu thành kết quả có thể kiểm tra. Nhóm kiểm thử đánh giá theo diễn giải khác nhau. Dẫn xuất từ BR-NF-INV-001, FR-NF-OUT-001, FR-NF-OUT-002, NFR-NF-AUD-001

Trạng thái và quy tắc chuyển trạng thái

Mã trạng thái Nghĩa Được xuất kho Sự kiện hợp lệ kế tiếp
PENDING_QA Lô chờ kiểm tra chất lượng Không QA_RELEASE, QA_BLOCK
RELEASED Lô đã được bộ phận chất lượng cho phép dùng hoặc xuất trong kịch bản mô phỏng Có QA_BLOCK
BLOCKED Lô bị giữ, không được dùng hoặc xuất Không QA_RELEASE theo quyết định chất lượng mô phỏng
CONSUMED Lô đã xuất hết số lượng khả dụng Không Không có chuyển trạng thái trong phạm vi kịch bản
ID quyết định Phương án Tiêu chí đánh giá Kết quả ghi nhận Thẩm quyền quyết định Lý do
DEC-NF-OUT-001 Chỉ cảnh báo khi lô chưa RELEASED Có ngăn xuất nhầm; bảo toàn tồn kho; hỗ trợ truy vết Không chọn ROLE-NF-WH-MANAGER và ROLE-NF-QA-MANAGER cần xác nhận trong dự án thực Cảnh báo vẫn cho phép người dùng xuất, không đáp ứng BR-NF-INV-001.
DEC-NF-OUT-002 Chặn xác nhận xuất trước giảm tồn kho Có ngăn xuất nhầm; bảo toàn dữ liệu; thông báo rõ lỗi Khuyến nghị cho kịch bản mô phỏng ROLE-NF-WH-MANAGER và ROLE-NF-QA-MANAGER cần xác nhận trong dự án thực Thỏa mọi tiêu chí và tạo điểm kiểm soát trước giao dịch.

Payload kiểm tra xuất kho mô phỏng

{
  "requestId": "REQ-NF-OUT-20260807-0091",
  "requestedAt": "2026-08-07T14:35:20+07:00",
  "requestedBy": "USR-NF-WH-004",
  "salesOrderId": "SO-NF-20260807-0142",
  "warehouseId": "WH-HCM-FG-01",
  "itemId": "FG-OM-01L",
  "lotId": "LOT-OM-20260805-A",
  "requestedQuantity": 1200,
  "uom": "BOT",
  "availableQuantityBefore": 1500,
  "qualityStatus": "PENDING_QA",
  "currency": "VND"
}
Test ID Liên kết yêu cầu Tiền điều kiện Bước kiểm thử Kết quả mong đợi Trạng thái test case
TC-NF-OUT-001 BR-NF-INV-001, FR-NF-OUT-001, AC-NF-OUT-001 Lô LOT-OM-20260805-A có PENDING_QA; tồn 1.500 chai. Xác nhận xuất 1.200 chai cho SO-NF-20260807-0142. Từ chối xuất; không tạo phiếu xuất; tồn vẫn 1.500 chai. NOT_EXECUTED
TC-NF-OUT-002 FR-NF-OUT-002 Điều kiện như TC-NF-OUT-001. Gửi payload REQ-NF-OUT-20260807-0091. Phản hồi chứa QA_LOT_NOT_RELEASED, lotId = LOT-OM-20260805-A, qualityStatus = PENDING_QA. NOT_EXECUTED
TC-NF-OUT-003 NFR-NF-AUD-001 TC-NF-OUT-001 đã tạo một lần từ chối. Tra audit log theo requestId = REQ-NF-OUT-20260807-0091. Có đúng một log chứa đủ người dùng, thời gian, đơn bán, kho, mã hàng, lô, số lượng, trạng thái và mã lỗi. NOT_EXECUTED
TC-NF-OUT-004 BR-NF-INV-001 Đổi trạng thái mô phỏng của LOT-OM-20260805-A thành RELEASED; tồn 1.500 chai. Xác nhận xuất 1.200 chai. Tạo phiếu xuất mô phỏng DO-NF-20260807-0037; tồn còn 300 chai. NOT_EXECUTED

Quy tắc kiểm tra đầy đủ: mỗi FR, BR, NFR trong bảng có ít nhất một AC hoặc TC; mỗi TC nêu dữ liệu đầu vào và kết quả kiểm được; mọi trạng thái lô trong payload thuộc bảng trạng thái. Kết quả NOT_EXECUTED nghĩa là test case đã được thiết kế nhưng chưa có bằng chứng chạy kiểm thử.

Hồ sơ quyết định cốt lõi — chặn xuất kho lô chưa đạt kiểm tra chất lượng

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ người, giao dịch, ngày và số tiền dưới đây là dữ liệu tổng hợp. Tình huống tập trung kiểm soát xuất bán lô thành phẩm sữa hạt khi kết quả kiểm tra chất lượng chưa ở trạng thái đạt. “Traceability” là khả năng lần ngược từ giao dịch đến nguồn chứng cứ; ở hồ sơ này, quyết định phải nối được đơn bán, lệnh xuất, lô hàng và kết quả QC.

Trường Giá trị hoàn chỉnh
Mã hồ sơ quyết định DEC-NF-VAL-001
Trạng thái IN_REVIEW
Phiên bản v0.9.0
Ngày ghi nhận 2026-08-07
Múi giờ Asia/Ho_Chi_Minh
Đơn vị tiền tệ VND
Quy trình Order-to-Cash, kiểm soát lô trước xuất kho
Đơn bán mô phỏng SO-NF-2026-0807-0142
Khách hàng mô phỏng CUS-NF-00318 — Siêu thị An Phú
Mặt hàng FG-ALM-180 — Sữa hạt hạnh nhân 180 ml
Lô thành phẩm LOT-ALM-260806-A
Số lượng yêu cầu xuất 1.200 chai
Đơn giá chưa gồm thuế 18.500 VND/chai
Giá trị hàng dự kiến 22.200.000 VND
Người lập yêu cầu xuất Nguyễn Minh Khôi — Sales Coordinator
Người phụ trách QC mô phỏng Trần Gia Hân — QC Analyst
Nguồn phân loại Mô phỏng nội bộ — dữ liệu tổng hợp; không phải bằng chứng vận hành thực tế
Nhóm phân tích Nội dung
Sự kiện thực tế trong case Ngày 2026-08-07 09:15, kho tạo yêu cầu xuất DN-NF-2026-0807-0067 từ đơn SO-NF-2026-0807-0142. Hệ thống tìm thấy tồn khả dụng 1.480 chai thuộc LOT-ALM-260806-A. Bản ghi QC QC-NF-2026-0806-0091 của cùng lô có trạng thái PENDING_REVIEW, chưa có kết luận PASS hoặc FAIL.
Hành vi hiện tại ERP mô phỏng chỉ kiểm tra tồn kho lớn hơn hoặc bằng số lượng yêu cầu. Vì 1.480 ≥ 1.200, hệ thống cho phép tạo phiếu xuất kho DO-NF-2026-0807-0039 dù trạng thái QC là PENDING_REVIEW.
Bằng chứng và suy luận Cùng mã lô xuất hiện trong yêu cầu xuất và bản ghi QC. Trạng thái QC chưa kết thúc nghĩa là chưa có dữ liệu nội bộ mô phỏng xác nhận lô đạt điều kiện xuất. Vì kiểm tra tồn kho không kiểm tra trạng thái QC, hệ thống có thể xuất lô đang chờ đánh giá.
Nhu cầu nền tảng Kho cần quyết định xuất dựa trên cả số lượng và trạng thái chất lượng. Sales cần biết đơn bị giữ vì lý do nào để không cam kết ngày giao sai. QC cần giữ quyền kết luận chất lượng, không để kho hoặc sales tự diễn giải kết quả kiểm tra.
Hậu quả nếu quyết định sai Nếu cho xuất lô PENDING_REVIEW, Nova Foods mô phỏng có thể giao 22.200.000 VND hàng chưa có kết luận QC; tăng nguy cơ thu hồi, điều chỉnh đơn và sai dấu vết lô. Nếu chặn mọi lô không phân biệt trạng thái, hàng PASS có thể bị giữ sai, làm chậm giao hàng và khóa vốn tồn kho.
Phương án Mô tả Ưu điểm Điểm yếu
OPT-001 Giữ kiểm tra tồn kho hiện tại, cho xuất nếu đủ số lượng Không đổi luồng kho Không kiểm soát trạng thái QC; không đáp ứng nhu cầu đã xác định
OPT-002 Chỉ cho xuất khi QC Status = PASS; chặn PENDING_REVIEW, FAIL, QUARANTINE, hoặc không có bản ghi QC Ngăn xuất khi chưa có kết luận; quy tắc rõ, kiểm thử được Có thể giữ đơn nếu QC chậm cập nhật
OPT-003 Cho Warehouse Supervisor ghi đè chặn QC bằng lý do tự do Xử lý nhanh tình huống gấp Làm mờ thẩm quyền QC; lý do tự do khó kiểm tra và dễ dùng sai
Tiêu chí quyết định Trọng số OPT-001 OPT-002 OPT-003
Không xuất lô chưa có kết luận QC 40% Không đạt Đạt Không đạt
Phân định thẩm quyền QC, kho, sales 25% Không đạt Đạt Không đạt
Có thể kiểm thử bằng trạng thái dữ liệu 20% Không đạt Đạt Đạt một phần
Giảm chậm giao do chặn sai 15% Đạt ngắn hạn Đạt khi QC cập nhật đúng hạn Đạt ngắn hạn

Khuyến nghị: chọn OPT-002. Quy tắc đề xuất: khi tạo hoặc xác nhận phiếu xuất, ERP phải đọc QC Status của đúng mã lô. ERP chỉ cho phép xác nhận xuất khi trạng thái là PASS; mọi trạng thái khác phải chặn xác nhận và trả mã lỗi QC_LOT_NOT_RELEASED.

Quyết định và thẩm quyền: DEC-NF-VAL-001 đang ở IN_REVIEW, chưa phải phê duyệt. Business Owner mô phỏng quyết định mức chấp nhận chậm giao; QC Owner mô phỏng xác nhận nghĩa nghiệp vụ của PASS; Solution Architect mô phỏng xác nhận cách ERP đọc trạng thái lô; QA Lead mô phỏng xác nhận tiêu chí kiểm thử. Principal IT Business Analyst / Technical Curriculum Author chỉ ghi nhận phân tích và duy trì truy vết, không thay các thẩm quyền này.

Ranh giới nguồn: nhu cầu kiểm soát lô dựa trên tình huống mô phỏng nội bộ và dữ liệu tổng hợp. Bối cảnh an toàn thực phẩm là Verification required với domain owner và legal owner; hồ sơ này không diễn giải Luật An toàn thực phẩm hoặc xác nhận tuân thủ pháp lý.

4. Tier 3 ? Fully Completed Nova Foods Case: Evidence and Traceability

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi mã, người dùng, lô hàng, thời điểm và bằng chứng dưới đây là dữ liệu tổng hợp. Mục tiêu kiểm soát: ERP không xác nhận xuất kho cho lô có QC Status khác PASS. Lý do: trạng thái QC là dữ liệu quyết định khả năng xuất; nếu bỏ qua trạng thái này, hệ thống không phân biệt lô đã đạt với lô chưa được QC kết luận.

4.1. Ngoại lệ và đường đi phủ định

ID Tình huống phủ định hoặc ngoại lệ Dữ liệu đầu vào tổng hợp Hành vi ERP bắt buộc theo đề xuất OPT-002 Bằng chứng cần lưu Trạng thái
EXC-NF-VAL-001 Lô có QC Status = PENDING Phiếu xuất DO-SIM-260807-001; lô LOT-SIM-MANGO-260801-A; số lượng 120 kg Chặn xác nhận xuất; hiển thị QC_LOT_NOT_RELEASED; không tạo giao dịch xuất kho EVD-NF-VAL-001 Đã ghi nhận mô phỏng
EXC-NF-VAL-002 Lô có QC Status = FAIL Phiếu xuất DO-SIM-260807-002; lô LOT-SIM-MANGO-260801-B; số lượng 80 kg Chặn xác nhận xuất; hiển thị QC_LOT_NOT_RELEASED; không giảm tồn kho khả dụng EVD-NF-VAL-002 Đã ghi nhận mô phỏng
EXC-NF-VAL-003 Lô chưa có bản ghi QC Phiếu xuất DO-SIM-260807-003; lô LOT-SIM-MANGO-260807-C; số lượng 50 kg Chặn xác nhận xuất; hiển thị QC_LOT_NOT_RELEASED; ghi nhật ký lỗi kỹ thuật để truy vết dữ liệu thiếu EVD-NF-VAL-003 Đã ghi nhận mô phỏng
EXC-NF-VAL-004 Người dùng kho thử xác nhận lại sau khi bị chặn warehouse.supervisor.sim; phiếu DO-SIM-260807-001; lô vẫn PENDING Mỗi lần thử vẫn chặn; không cho phép ghi đè bằng lý do tự do; không đổi QC Status EVD-NF-VAL-004 Đã ghi nhận mô phỏng
EXC-NF-VAL-005 QC đổi trạng thái từ PENDING sang PASS trước lần xác nhận lại Lô LOT-SIM-MANGO-260801-A; QC Status = PASS; phiếu DO-SIM-260807-001 Cho phép xác nhận xuất tại lần thử mới; kiểm tra lại trạng thái hiện thời, không dùng kết quả chặn cũ EVD-NF-VAL-005 Đã ghi nhận mô phỏng

QC_LOT_NOT_RELEASED là mã lỗi ứng dụng. Mã này cho người dùng biết điều kiện chặn là trạng thái lô chưa được phát hành, không khẳng định lỗi thuộc QC, kho hay sales. ERP phải chặn trước khi tạo giao dịch giảm tồn kho; nếu chặn sau khi giảm tồn, bằng chứng tồn kho và bằng chứng QC sẽ mâu thuẫn.

4.2. Danh mục bằng chứng mô phỏng

Evidence ID Loại bằng chứng Tham chiếu tình huống Kết quả quan sát Phân loại nguồn Giới hạn sử dụng
EVD-NF-VAL-001 Nhật ký kiểm thử tổng hợp EXC-NF-VAL-001 Xác nhận xuất bị chặn; mã QC_LOT_NOT_RELEASED; tồn kho không đổi Bằng chứng mô phỏng nội bộ Không chứng minh cấu hình ERP thực tế
EVD-NF-VAL-002 Nhật ký kiểm thử tổng hợp EXC-NF-VAL-002 Xác nhận xuất bị chặn khi lô FAIL; tồn kho không đổi Bằng chứng mô phỏng nội bộ Không xác nhận quy trình hủy hoặc trả hàng
EVD-NF-VAL-003 Nhật ký kiểm thử tổng hợp EXC-NF-VAL-003 Thiếu bản ghi QC bị xử lý như chưa phát hành; không phát sinh xuất kho Bằng chứng mô phỏng nội bộ Cần Architect xác nhận cách xử lý lỗi tích hợp
EVD-NF-VAL-004 Nhật ký kiểm thử quyền tổng hợp EXC-NF-VAL-004 Tài khoản kho không thể ghi đè trạng thái QC hoặc xác nhận xuất Bằng chứng mô phỏng nội bộ Không phải đánh giá phân quyền production
EVD-NF-VAL-005 Nhật ký kiểm thử hồi quy tổng hợp EXC-NF-VAL-005 Lần xác nhận mới thành công sau khi trạng thái đúng lô là PASS Bằng chứng mô phỏng nội bộ Cần QA Lead xác nhận bộ hồi quy chính thức

Các EVD-NF-VAL-* là evidence reference, tức tham chiếu bằng chứng để reviewer tìm đúng kết quả kiểm thử. Chúng không phải biên bản phê duyệt, baseline, chứng nhận tuân thủ hay dữ liệu vận hành Nova Foods thật.

4.3. Giả định và mục cần xác minh

ID Nội dung Cầu nối lý do Nhãn Owner xác minh
ASM-NF-VAL-001 Mỗi dòng xuất kho tham chiếu đúng một mã lô. Quy tắc chỉ kiểm tra được QC Status nếu dòng xuất xác định được lô cụ thể. Project assumption Solution Architect mô phỏng
ASM-NF-VAL-002 PASS, PENDING, FAIL là ba trạng thái đủ cho case học liệu này. Case chỉ cần phân biệt được phép xuất, chưa có kết luận, không đạt; không suy diễn vòng đời QC thực tế. Project assumption QC Owner mô phỏng
VR-NF-VAL-001 Cần xác minh thời điểm ERP đọc lại QC Status: lúc tạo phiếu, lúc xác nhận, hoặc cả hai. EXC-NF-VAL-005 chỉ an toàn khi hệ thống dùng trạng thái hiện thời tại điểm xác nhận xuất. Verification required Solution Architect mô phỏng
VR-NF-VAL-002 Cần xác minh yêu cầu lưu vết truy xuất lô theo quy định an toàn thực phẩm hiện hành. Nguồn luật chỉ cung cấp bối cảnh; hồ sơ này không diễn giải nghĩa vụ pháp lý hay xác nhận tuân thủ. Verification required Domain Owner và Legal Owner mô phỏng
VR-NF-VAL-003 Cần xác minh tác động kế toán khi xuất kho bị chặn hoặc được xác nhận. Việc giảm tồn và ghi nhận kế toán có thể liên quan nhưng chưa có quyết định kế toán trong case này. Verification required Accounting Owner mô phỏng

4.4. Escalation records

Escalation ID Điều kiện kích hoạt Vấn đề cần quyết định Người nhận Hành động BA Trạng thái
ESC-NF-VAL-001 QC Status bị thiếu, không hợp lệ, hoặc có giá trị ngoài PASS, PENDING, FAIL. Xác định hợp đồng dữ liệu giữa mô-đun QC và xuất kho; xác định mã lỗi kỹ thuật và cơ chế xử lý dữ liệu lỗi. Solution Architect mô phỏng; QC Owner mô phỏng Gắn EVD-NF-VAL-003, giữ chặn xuất, không tự suy diễn giá trị thay thế. Mở, IN_REVIEW
ESC-NF-VAL-002 Nghiệp vụ yêu cầu xuất lô chưa PASS vì giao gấp. Xác định có tồn tại ngoại lệ được ủy quyền hay không; nếu có, xác định vai trò, kiểm soát và truy vết. Business Owner mô phỏng; QC Owner mô phỏng; Security Owner mô phỏng Giữ OPT-002; không thêm quyền ghi đè tự do từ OPT-003. Mở, IN_REVIEW
ESC-NF-VAL-003 Có yêu cầu gọi quy tắc này là nghĩa vụ pháp lý hoặc an toàn thực phẩm bắt buộc. Xác minh nguồn pháp lý hiện hành và phạm vi áp dụng cho vận hành thật. Legal Owner mô phỏng; Domain Owner mô phỏng Giữ nhãn Verification required; không chuyển giả định thành yêu cầu tuân thủ. Mở, IN_REVIEW

ESC-NF-VAL-002 tồn tại vì nhanh giao hàng không tự tạo thẩm quyền bỏ qua QC. ESC-NF-VAL-003 tồn tại vì bối cảnh Luật An toàn thực phẩm không đủ để suy ra điều khoản, nghĩa vụ hoặc mức tuân thủ cho Nova Foods mô phỏng.

Ma trận truy vết đầu-cuối cho tình huống chặn lô nguyên liệu hết hạn

Tình huống Nova Foods Trading & Manufacturing là mô phỏng giáo dục, dùng dữ liệu tổng hợp: nhân viên Kho tạo phiếu xuất nguyên liệu RM-COCOA-01 từ lô LOT-NF-260801-01 ngày 2026-08-07; ngày hết hạn tổng hợp của lô là 2026-08-06. Chuỗi truy vết nối nhu cầu đến kiểm thử để biết mỗi kiểm thử bảo vệ yêu cầu nào, mỗi trường dữ liệu phục vụ quy tắc nào, và khoảng trống nào chưa đủ căn cứ thành baseline. NEED là nhu cầu; REQ là yêu cầu; BR là business rule, quy tắc nghiệp vụ; AC là acceptance criteria, tiêu chí chấp nhận; TC là test case, ca kiểm thử.

Loại ID Nội dung đã liên kết Nguồn/phân loại Liên kết xuôi Cầu nối suy luận và trạng thái
NEED NEED-NF-INV-001 Kho cần ngăn nguyên liệu quá hạn đi vào phiếu xuất kho để giảm rủi ro dùng sai lô. Nova Foods mô phỏng; PROJECT_ASSUMPTION REQ-NF-INV-001 Nhu cầu mô tả mục tiêu nghiệp vụ, chưa phải cam kết vận hành thật. Chưa có baseline.
REQ REQ-NF-INV-001 ERP phải từ chối xác nhận xuất kho khi expiryDate của lô nhỏ hơn ngày nghiệp vụ postingDate. Suy ra từ NEED-NF-INV-001; PROJECT_ASSUMPTION BR-NF-INV-001, AC-NF-INV-001, DATA-NF-LOT-001, API-NF-ISSUE-001, TC-NF-INV-001 Nếu không so sánh ngày hết hạn với ngày hạch toán, hệ thống không có điều kiện kỹ thuật để chặn lô quá hạn. Ngưỡng so sánh cần Business Owner và QA xác minh.
BR BR-NF-INV-001 Chỉ cho xác nhận xuất khi expiryDate >= postingDate; cùng ngày hết hạn vẫn được phép. PROJECT_ASSUMPTION; cần xác minh nghiệp vụ an toàn thực phẩm AC-NF-INV-001, AC-NF-INV-002, TC-NF-INV-001, TC-NF-INV-002 Dấu >= biến quy tắc thành quyết định kiểm thử được. Luật An toàn thực phẩm là bối cảnh tham khảo; không dùng để khẳng định chi tiết quy tắc ERP này.
AC AC-NF-INV-001 Given lô có expiryDate là 2026-08-06 và postingDate là 2026-08-07, when nhân viên xác nhận xuất, then hệ thống không tạo chứng từ xuất và hiển thị LOT_EXPIRED. Dẫn xuất từ BR-NF-INV-001; PROJECT_ASSUMPTION TC-NF-INV-001 Tiêu chí biến quy tắc thành kết quả quan sát được: không tạo chứng từ và trả mã lỗi.
AC AC-NF-INV-002 Given lô có expiryDate là 2026-08-07 và postingDate là 2026-08-07, when nhân viên xác nhận xuất, then hệ thống cho phép tạo chứng từ xuất. Dẫn xuất từ BR-NF-INV-001; PROJECT_ASSUMPTION TC-NF-INV-002 Ca biên kiểm tra dấu bằng trong >=; thiếu ca này có thể che lỗi dùng toán tử >.
DATA DATA-NF-LOT-001 Thực thể logic InventoryLot: lotId, itemCode, expiryDate, availableQuantity, uom. /01-curriculum/CANONICAL_DATA_DICTIONARY.md; IN_REVIEW, chưa baseline API-NF-ISSUE-001, TC-NF-INV-001, TC-NF-INV-002 lotId, expiryDate là dữ liệu tối thiểu để nhận diện lô và so sánh hạn dùng. Kiểu dữ liệu, múi giờ, quy tắc sửa ngày hết hạn: VERIFICATION_REQUIRED.
API API-NF-ISSUE-001 POST /inventory-issues nhận postingDate, lines[].lotId, lines[].quantity; phản hồi lỗi 409 với mã LOT_EXPIRED khi vi phạm BR-NF-INV-001. Đặc tả minh họa Nova Foods; OAS 3.1.1 chỉ là nguồn thuật ngữ HTTP/API; PROJECT_ASSUMPTION TC-NF-INV-001, TC-NF-INV-002 API cần nhận ngày nghiệp vụ và ID lô; thiếu một trong hai đầu vào thì không thể áp dụng quy tắc. Mã HTTP cần Architect và API Owner xác minh.
TC TC-NF-INV-001 Gửi lô LOT-NF-260801-01, expiryDate=2026-08-06, postingDate=2026-08-07, quantity=10; kỳ vọng 409, LOT_EXPIRED, không có số phiếu xuất. Kiểm thử hộp đen theo ISTQB CTFL; dữ liệu tổng hợp Xác minh REQ-NF-INV-001, BR-NF-INV-001, AC-NF-INV-001 Đây là phân vùng không hợp lệ: ngày hết hạn trước ngày nghiệp vụ.
TC TC-NF-INV-002 Gửi lô LOT-NF-260807-01, expiryDate=2026-08-07, postingDate=2026-08-07, quantity=10; kỳ vọng 201, tạo một phiếu xuất tổng hợp. Kiểm thử hộp đen theo ISTQB CTFL; dữ liệu tổng hợp Xác minh BR-NF-INV-001, AC-NF-INV-002 Đây là giá trị biên hợp lệ. Số phiếu xuất cụ thể không được quy định khi chưa có thiết kế đánh số.
DEF/CR Không có bản ghi Chưa có lỗi (DEF) hoặc yêu cầu thay đổi (CR) được ghi nhận cho chuỗi này. IN_REVIEW; chưa baseline Không áp dụng Không tạo DEF hoặc CR giả để lấp ma trận. Khi phát hiện kết quả thực tế khác AC, tạo ID theo /01-curriculum/TRACEABILITY_ID_REGISTRY.md và liên kết ngược đến TC, AC, BR, REQ.
Hướng kiểm tra Chuỗi bắt buộc Kết quả
Xuôi NEED-NF-INV-001 → REQ-NF-INV-001 → BR-NF-INV-001 → AC-NF-INV-001 và AC-NF-INV-002 → TC-NF-INV-001 và TC-NF-INV-002 Đủ liên kết cho tình huống mô phỏng.
Ngược TC-NF-INV-001 → AC-NF-INV-001 → BR-NF-INV-001 → REQ-NF-INV-001 → NEED-NF-INV-001 Mỗi ca kiểm thử có lý do nghiệp vụ truy ngược được.
Dữ liệu/API DATA-NF-LOT-001 → API-NF-ISSUE-001 → TC-NF-INV-001, TC-NF-INV-002 Đầu vào kiểm thử có nguồn dữ liệu logic rõ.
Baseline và thẩm quyền Toàn bộ chuỗi IN_REVIEW, v0.9.0, ngày 2026-08-07; không phải baseline, không có phê duyệt. Business Owner, QA, Food Safety Owner và Architect phải xác minh các mục gắn PROJECT_ASSUMPTION hoặc VERIFICATION_REQUIRED.

4.3 Gói dữ liệu và bảng quyết định kiểm thử phân bổ lô thành phẩm

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ mã, lô hàng, số lượng và giá trị dưới đây là dữ liệu tổng hợp. Gói này minh họa luồng phân bổ lô thành phẩm cho đơn bán SO-NF-20260807-001. Sơ đồ hoạt động là biểu diễn Mermaid, không phải BPMN. Payload là dữ liệu JSON gửi qua API; bảng quyết định là bảng liệt kê mọi tổ hợp điều kiện và kết quả mong đợi. Các ID NEED-NF-001, REQ-NF-001, BR-NF-001, AC-NF-001, DATA-NF-001, API-NF-001, TC-NF-001 là liên kết làm việc IN_REVIEW tại v0.9.0, không phải baseline.

TMPL-VAL-TRACE-001_requirements-to-test-traceability-matrix — diagram 1

Source mermaid — có thể chỉnh sửa
flowchart TD
    A[Nhân viên tạo yêu cầu phân bổ<br/>SO-NF-20260807-001] --> B[ERP nhận payload API-NF-001]
    B --> C{Lô tồn tại?}
    C -- Không --> X[Trả ALLOCATION_BATCH_NOT_FOUND]
    C -- Có --> D{Trạng thái lô = RELEASED?}
    D -- Không --> Y[Trả ALLOCATION_BATCH_NOT_RELEASED]
    D -- Có --> E{Tồn khả dụng đủ?}
    E -- Không --> Z[Trả ALLOCATION_INSUFFICIENT_AVAILABLE_QTY]
    E -- Có --> F[Giảm availableQuantity]
    F --> G[Tạo batchAllocationId]
    G --> H[Trả phân bổ thành công]
Trường payload Giá trị tổng hợp Liên kết Lý do kiểm soát
salesOrderId SO-NF-20260807-001 DATA-NF-001 Khóa đơn bán cần nhận hàng.
productId FG-NF-COFFEE-250G DATA-NF-001 Xác định thành phẩm cần phân bổ.
batchId BAT-NF-COFFEE-20260801-A DATA-NF-001 Xác định lô xuất kho.
requestedQuantity 120 BR-NF-001 Số lượng yêu cầu phải so với tồn khả dụng.
uom BAG DATA-NF-001 Đơn vị đo phải thống nhất khi so sánh số lượng.
requestedAt 2026-08-07T09:15:00+07:00 API-NF-001 Dùng Asia/Ho_Chi_Minh theo governance corpus.
{
  "salesOrderId": "SO-NF-20260807-001",
  "productId": "FG-NF-COFFEE-250G",
  "batchId": "BAT-NF-COFFEE-20260801-A",
  "requestedQuantity": 120,
  "uom": "BAG",
  "requestedAt": "2026-08-07T09:15:00+07:00",
  "requestedBy": "USR-NF-SALES-001"
}
Batch ID Product ID Batch status Available quantity UOM Kết quả dùng trong bảng quyết định
BAT-NF-COFFEE-20260801-A FG-NF-COFFEE-250G RELEASED 150 BAG Đủ điều kiện phân bổ 120 BAG.
BAT-NF-COFFEE-20260801-B FG-NF-COFFEE-250G QUARANTINED 150 BAG Không được phân bổ vì chưa RELEASED.
BAT-NF-COFFEE-20260801-C FG-NF-COFFEE-250G RELEASED 80 BAG Không đủ cho yêu cầu 120 BAG.
Quy tắc quyết định Lô tồn tại batchStatus = RELEASED availableQuantity >= requestedQuantity Kết quả ERP Liên kết kiểm thử
D01 Có Có Có Tạo BA-NF-20260807-001; tồn khả dụng từ 150 giảm còn 30 BAG. TC-NF-001
D02 Có Có Không Không tạo phân bổ; trả ALLOCATION_INSUFFICIENT_AVAILABLE_QTY. TC-NF-002
D03 Có Không Có Không tạo phân bổ; trả ALLOCATION_BATCH_NOT_RELEASED. TC-NF-003
D04 Có Không Không Không tạo phân bổ; trả ALLOCATION_BATCH_NOT_RELEASED. Trạng thái lô chặn trước kiểm tra số lượng. TC-NF-004
D05 Không Không áp dụng Không áp dụng Không tạo phân bổ; trả ALLOCATION_BATCH_NOT_FOUND. TC-NF-005

BR-NF-001: ERP chỉ phân bổ khi lô tồn tại, có trạng thái RELEASED, và tồn khả dụng không nhỏ hơn số lượng yêu cầu. Cơ sở suy luận: ba điều kiện trong bảng quyết định là điều kiện tối thiểu để ERP xác định đúng lô, tránh xuất lô chưa được giải phóng, và tránh tồn khả dụng âm trong dữ liệu mô phỏng.

5. Tier 4 ? Senior BA Quality Gate

Quality Gate là cổng kiểm soát trước baseline: Senior BA kiểm tra requirement, quy tắc, dữ liệu và liên kết kiểm thử có đủ bằng chứng để chuyển sang vòng review tiếp theo. Cổng này không tạo APPROVED, BASELINED, xác nhận tuân thủ, hay quyền triển khai production. Phạm vi Nova Foods Trading & Manufacturing là mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; trạng thái corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND.

ID kiểm tra Hạng mục Điều kiện PASS Điều kiện FAIL STOP Escalation
QG-001 Tính đầy đủ Mỗi requirement có ID canonical, mô tả kết quả, điều kiện, ngoại lệ, owner và liên kết test. Thiếu một trường bắt buộc nhưng còn xác định được nội dung cần bổ sung. Thiếu ID, thiếu requirement gốc, hoặc không xác định được phạm vi. Senior BA lập issue; Business Owner làm rõ phạm vi và ưu tiên.
QG-002 Tính nhất quán ID, tên thực thể, trạng thái, đơn vị đo và giá trị dùng thống nhất giữa requirement, rule, payload, bảng quyết định và test. Có lệch thuật ngữ hoặc giá trị, chưa tạo tác động quyết định. Hai nguồn canonical cho kết quả trái ngược. Senior BA giữ nguyên bằng chứng; Owner của nguồn canonical quyết định nguồn đúng.
QG-003 Tính kiểm thử được Mỗi requirement có tiền điều kiện, dữ liệu đầu vào, hành động, kết quả mong đợi quan sát được và mã lỗi hoặc thay đổi dữ liệu khi phù hợp. Kết quả mong đợi mơ hồ nhưng có thể viết lại không đổi ý nghiệp vụ. Không thể xác định cách phân biệt pass/fail. QA Reviewer và Business Owner xác định acceptance criteria.
QG-004 Traceability Mỗi requirement nối được hai chiều tới business rule, nguồn, test case và bằng chứng dự kiến. “Hai chiều” nghĩa là từ requirement tìm ra test, và từ test tìm lại requirement. Thiếu một liên kết nhưng ID còn hợp lệ. Test không có requirement, hoặc requirement không có test basis. Senior BA sửa ma trận; QA Reviewer kiểm tra lại coverage.
QG-005 Thẩm quyền nguồn Nguồn được phân loại đúng: quy tắc mô phỏng, nguồn chuẩn, nguồn pháp lý, giả định dự án, hoặc Verification required. Nguồn có URL hoặc tên nhưng thiếu phân loại hoặc ngày truy cập. Diễn đạt giả định như nghĩa vụ pháp lý, kế toán, thuế, bảo mật hoặc vận hành thực. Legal Owner, Accounting Owner, Security Owner hoặc Domain Owner theo loại nội dung.
QG-006 Ownership Requirement, rule, test và issue có owner chịu trách nhiệm làm rõ hoặc review; Owner artifact không bị gán quyền phê duyệt ngoài thẩm quyền. Thiếu người review phụ nhưng vẫn xác định được owner chính. Không có vai trò có thẩm quyền quyết định nội dung. Business Owner chỉ định owner; không tự suy diễn người phê duyệt.
QG-007 Biên giới bảo mật Dữ liệu nhạy cảm, quyền truy cập, xác thực, phân quyền, log và lỗi không tiết lộ dữ liệu vượt nhu cầu nghiệp vụ mô phỏng. Thiếu mức phân loại dữ liệu hoặc mô tả kiểm soát. Payload, test hoặc requirement cho phép truy cập trái phân quyền, lộ bí mật, hoặc bỏ kiểm soát xác thực. Security Owner; tham chiếu OWASP ASVS 5.0.0 hoặc OWASP API Security Top 10 2023 khi phù hợp.
QG-008 Biên giới riêng tư và pháp lý Nội dung liên quan dữ liệu cá nhân hoặc nghĩa vụ pháp lý gắn nhãn Verification required nếu chưa được owner có thẩm quyền xác minh văn bản hiện hành. Có nhãn nhưng thiếu phạm vi dữ liệu hoặc mục đích xử lý. Khẳng định tuân thủ Luật 91/2025/QH15 hoặc Nghị định 356/2025/NĐ-CP mà không có xác minh Legal Owner. Legal/Privacy Owner. Tài liệu học liệu không thay thế tư vấn pháp lý.
QG-009 Biên giới kế toán Quy tắc ảnh hưởng hạch toán, chứng từ, thuế, giá vốn hoặc khóa sổ chỉ nêu giả định hoặc Verification required khi chưa có xác nhận chuyên môn. Thiếu nhãn giả định hoặc thiếu owner kế toán. Requirement tự quyết định bút toán, thuế hoặc hiệu lực chứng từ. Accounting Owner và Legal Owner; kiểm tra nguồn Luật 88/2015/QH13, Nghị định 123/2020/NĐ-CP trước dùng production.
QG-010 Biên giới an toàn thực phẩm và truy xuất Rule về lô, RELEASED, QUARANTINED, recall hoặc truy xuất phân biệt rõ dữ liệu mô phỏng với nghĩa vụ thực tế. Thiếu nguồn hoặc owner chuyên môn cho quy tắc an toàn thực phẩm. Gọi trạng thái lô mô phỏng là bằng chứng tuân thủ hoặc chỉ dẫn recall thực. Food-safety Domain Owner và Legal Owner; kiểm tra Luật 55/2010/QH12.
QG-011 Tác động thay đổi Mọi thay đổi requirement chỉ rõ ID bị ảnh hưởng, rule, test, dữ liệu, API, báo cáo, quyền truy cập và tài liệu liên quan. Có mô tả thay đổi nhưng thiếu một nhóm tác động. Thay đổi rule hoặc trạng thái làm invalid test, payload hoặc traceability mà không có đánh giá tác động. Senior BA mở change record; Architect, QA, Security, Accounting hoặc Legal review theo phạm vi.
QG-012 Trạng thái quản trị Artifact giữ đúng IN_REVIEW, v0.9.0, ngày 2026-08-07; không có câu chữ ngầm xác nhận baseline hay user approval. Metadata thiếu một giá trị kiểm soát nhưng không mâu thuẫn. Gắn APPROVED, BASELINED, compliant hoặc production-ready không có tham chiếu kiểm soát. Principal IT Business Analyst / Technical Curriculum Author sửa metadata; vai trò có thẩm quyền xử lý approval nếu có.

Quy tắc quyết định cổng: PASS khi toàn bộ QG-001 đến QG-012 đạt PASS. FAIL khi có lỗi sửa được, chưa chạm điều kiện STOP; trả về tác giả để sửa và review lại các ID bị ảnh hưởng. STOP khi một điều kiện STOP xuất hiện; không baseline, không mở rộng phạm vi, không suy diễn rule thay thế. Escalation khi nội dung vượt thẩm quyền Senior BA hoặc có xung đột nguồn canonical; gói escalation phải giữ ID, bằng chứng, nguồn, tác động và câu hỏi quyết định.

Ma trận kiểm tra chất lượng Senior BA: tám chiều kiểm soát trước baseline

Kiểm tra chất lượng không hỏi “tài liệu có dài không”, mà hỏi mỗi yêu cầu có đủ thông tin để đúng người xây, kiểm thử, vận hành và chịu trách nhiệm hay không. Với Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, mọi dữ liệu dưới đây là dữ liệu tổng hợp; trạng thái tài liệu vẫn là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Kết quả kiểm tra không tạo baseline, approval, xác nhận tuân thủ hay quyền dùng production.

Chiều kiểm tra Câu hỏi Senior BA phải trả lời PASS FAIL STOP / escalation
Đầy đủ (completeness) Requirement có mục tiêu, phạm vi, actor, dữ liệu vào/ra, quy tắc, ngoại lệ, tiêu chí chấp nhận và liên kết test không? Mọi trường bắt buộc có giá trị cụ thể; không có placeholder ở Tier 3. Thiếu ngoại lệ, dữ liệu đầu ra hoặc tiêu chí chấp nhận. Dừng nếu thiếu thông tin làm thay đổi nghiệp vụ, số tiền VND, dữ liệu cá nhân hoặc bút toán. Escalate Business Owner, Accounting Owner hoặc Legal Owner theo loại khoảng trống.
Nhất quán (consistency) Requirement, business rule, data dictionary, test case và nguồn có cùng thuật ngữ, trạng thái, đơn vị và logic không? Cùng một khái niệm dùng một tên; ví dụ VND dùng nhất quán, không đổi sang đơn vị khác. Một artifact nói cho sửa số lô sau xác nhận, artifact khác nói khóa số lô. Dừng nếu mâu thuẫn tạo hai nguồn chân lý. Giữ nguyên mâu thuẫn, lập gói vấn đề, escalate Owner của nguồn canonical.
Khả năng kiểm thử (testability) Có thể tạo test quan sát được, với dữ liệu vào, hành động, kết quả kỳ vọng và điều kiện pass/fail không? Tiêu chí đo được; ví dụ hệ thống từ chối lưu khi mã lô trống và hiển thị lỗi xác định. Dùng từ mơ hồ như “nhanh”, “dễ dùng”, “hợp lệ” nhưng không có ngưỡng hoặc quy tắc. Dừng nếu QA không thể xác định kết quả đúng. Escalate Business Owner để chốt outcome; Architect khi cần ngưỡng kỹ thuật.
Truy vết (traceability) Mỗi requirement liên kết ngược đến nguồn và xuôi đến rule, data, test, defect hoặc change không? Liên kết giữ nguyên ID canonical và đường dẫn nguồn, gồm TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY khi áp dụng. Chỉ có mô tả văn bản, không có ID hoặc liên kết đứt. Dừng nếu requirement về kiểm soát lô, hóa đơn, dữ liệu cá nhân hoặc phân quyền không truy được nguồn và test. Escalate Principal IT Business Analyst / Technical Curriculum Author để sửa ma trận, không tự tạo ID.
Thẩm quyền nguồn (source authority) Nguồn nào có quyền xác định nội dung: quyết định nghiệp vụ, luật, chuẩn, hay giả định dự án? Nguồn được phân loại rõ: primary source, project assumption hoặc Verification required. Dùng OWASP như luật Việt Nam; dùng tài liệu học liệu như quyết định kế toán. Dừng nếu requirement pháp lý, kế toán, thuế hoặc an toàn thực phẩm không có owner có thẩm quyền xác minh. Escalate Legal Owner, Accounting Owner hoặc domain owner.
Ownership Ai quyết định nội dung, ai xây, ai test, ai vận hành và ai xác nhận boundary? Mỗi quyết định có một owner chịu trách nhiệm; BA giữ traceability, không nhận thay thẩm quyền. Gán “Senior BA” làm người phê duyệt luật, bút toán hoặc bảo mật. Dừng nếu owner vắng mặt hoặc hai owner đưa quyết định đối nghịch. Escalate sponsor hoặc governance owner để phân định quyền quyết định.
Bảo mật, riêng tư, pháp lý, kế toán Requirement có nhận diện dữ liệu cá nhân, quyền truy cập, audit trail, chứng từ, lưu trữ và giới hạn diễn giải không? Nêu loại dữ liệu, vai trò truy cập, rủi ro, nguồn tham chiếu và nhãn Verification required khi chưa có xác minh chuyên môn. Ghi “tuân thủ đầy đủ” mà không có kiểm chứng; để lộ dữ liệu cá nhân trong test payload. Dừng ngay khi có xử lý dữ liệu cá nhân, hóa đơn/chứng từ, số liệu kế toán hoặc dữ liệu recall mà chưa có Security, Legal, Accounting hoặc domain-owner review. Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật 88/2015/QH13, Nghị định 123/2020/NĐ-CP và Luật 55/2010/QH12 chỉ là nguồn cần đối chiếu theo thẩm quyền.
Ảnh hưởng thay đổi (change impact) Nếu sửa rule, field, trạng thái hoặc quyền, những requirement, test, báo cáo, tích hợp và owner nào bị ảnh hưởng? Có danh sách artifact bị ảnh hưởng, lý do và quyết định cập nhật trước khi sửa. Sửa business rule nhưng không rà test hoặc data dictionary. Dừng nếu thay đổi chạm dữ liệu cá nhân, luồng chứng từ, số tiền, tồn kho theo lô hoặc API mà chưa phân tích ảnh hưởng. Escalate Architect, Security, Accounting, Legal hoặc Business Owner theo phạm vi.

Áp dụng cho bản Nova Foods đã hoàn thiện ở Tier 3: kiểm tra chỉ ghi nhận được phép dựa trên nội dung hiện có trong ma trận và artifact canonical, không suy diễn quy định vận hành thực. Các liên kết tới TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY phải giữ nguyên định danh và chỉ được xem là bằng chứng cấu trúc khi nguồn đó còn IN_REVIEW.

Kết quả ghi nhận Nova Foods mô phỏng Bằng chứng và cầu nối suy luận Kết quả chất lượng Hành động bắt buộc trước baseline
Ranh giới nguồn pháp lý và chuẩn Source seed phân biệt nguồn chính thức, chuẩn ngành và giới hạn dùng; Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP yêu cầu Legal Owner xác minh requirement suy ra. PASS có điều kiện Giữ nhãn Verification required cho mọi chi tiết pháp lý chưa được Legal Owner xác minh.
Ranh giới kế toán và hóa đơn Luật 88/2015/QH13 và Nghị định 123/2020/NĐ-CP được ghi là nguồn chính thức, nhưng source seed cấm diễn giải kế toán không có vai trò được ủy quyền. PASS có điều kiện Accounting Owner xác minh mọi rule về bút toán, chứng từ, thuế và số tiền VND trước baseline.
Ranh giới an toàn thực phẩm và truy xuất lô Luật 55/2010/QH12 được dùng cho bối cảnh traceability/recall; source seed yêu cầu domain-owner và legal verification. PASS có điều kiện Domain Owner và Legal Owner xác minh rule lô, recall và lưu vết trước baseline.
Ownership của template TEMPLATE_MANIFEST xác định Owner duy trì governance nhưng không có quyền baseline, approval, legal, accounting hoặc production. PASS Không đổi Owner thành approver; ghi nhận reviewer có thẩm quyền ở artifact kiểm soát khi có.
Trạng thái và thay đổi Các artifact upstream thống nhất IN_REVIEW, v0.9.0, 2026-08-07; chưa có baseline reference hoặc approval reference. PASS Không dùng từ “đã phê duyệt”, “đã baseline”, “compliant” hoặc “production-ready”.
Testability và traceability của nội dung Tier 3 Mọi hàng Tier 3 phải có requirement, rule, dữ liệu, expected result và test link; thiếu một liên kết làm QA không tái tạo được kiểm tra. FAIL nếu phát hiện hàng thiếu liên kết Dừng baseline cho hàng lỗi; sửa tại nguồn canonical hoặc ma trận liên kết, không tạo ID thay thế.

Áp dụng Quality Gate cho Nova Foods mô phỏng

Phạm vi review: Tier 3 trong /03-templates/TMPL-VAL-TRACE-001_requirements-to-test-traceability-matrix.md, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp. Review này ghi nhận chất lượng trước baseline, không tạo approval, baseline, xác nhận tuân thủ, hay quyền dùng production.

Mã kiểm Nội dung đối chiếu Bằng chứng và cầu nối suy luận Kết quả Finding và xử lý
QG-APP-001 Đủ liên kết requirement đến test Tier 3 có phần Core Record và Evidence and Traceability; ma trận cần nối requirement, acceptance criteria, test case, evidence để chứng minh mỗi yêu cầu có cách kiểm tra. PASS có điều kiện Cấu trúc phù hợp mục đích traceability. Giữ từng liên kết trong cùng dòng; không dùng mô tả chung thay ID liên kết.
QG-APP-002 Nhất quán trạng thái quản trị Artifact corpus đều ghi IN_REVIEW, v0.9.0, ngày 2026-08-07; IN_REVIEW không đồng nghĩa APPROVED hay BASELINED. PASS Không ghi “đã phê duyệt”, “đã baseline”, “đạt tuân thủ”, hoặc “sẵn sàng production” trong kết luận ma trận.
QG-APP-003 Testability, tức khả năng kiểm thử Một requirement chỉ testable khi có điều kiện đầu vào, hành vi mong đợi, kết quả quan sát được và tiêu chí pass/fail. Evidence phải kiểm chứng được kết quả test. PASS có điều kiện Mỗi dòng Tier 3 phải giữ đủ test case và expected result cụ thể. Nếu evidence chỉ là nhận xét người review, đổi kết quả sang FAIL vì không tái kiểm được.
QG-APP-004 Nguồn và thẩm quyền CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY là artifact canonical theo dependency. Chúng đang IN_REVIEW; không phải nguồn xác nhận vận hành hay pháp lý. PASS Giữ nguyên ID, filename, status và source classification. Không nâng artifact curriculum thành quyết định Business Owner, Legal Owner, Accounting Owner, Security hoặc Architect.
QG-APP-005 Boundary bảo mật, dữ liệu cá nhân Seed có Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP. Seed quy định requirement suy ra từ luật cần Legal Owner xác minh. Case chỉ dùng dữ liệu tổng hợp. STOP Nếu Tier 3 diễn đạt nghĩa vụ bảo vệ dữ liệu cá nhân như kết luận pháp lý đã xác nhận, dừng baseline. Escalate Legal Owner; ghi Verification required; chỉ tiếp tục sau khi nguồn luật hiện hành và diễn giải áp dụng được xác minh.
QG-APP-006 Boundary kế toán, hóa đơn Luật 88/2015/QH13 và Nghị định 123/2020/NĐ-CP là nguồn pháp lý; seed yêu cầu Accounting Owner hoặc Legal Owner xác minh diễn giải và amendment trước production. STOP Không dùng test pass để kết luận bút toán, hóa đơn hoặc thuế hợp pháp. Escalate Accounting Owner và Legal Owner nếu Tier 3 chứa rule hạch toán, chứng từ, thuế, thời hạn lưu trữ hoặc kết luận compliance.
QG-APP-007 Ownership, tức người chịu trách nhiệm quyết định Owner corpus là Principal IT Business Analyst / Technical Curriculum Author; dependency nêu rõ vai trò này không có quyền phê duyệt, legal sign-off, accounting decision, security sign-off hay production release. PASS Ma trận phân biệt owner duy trì traceability với owner quyết định nội dung. Không gán Senior BA quyền thay thế vai trò chuyên môn.
QG-APP-008 Change impact, tức ảnh hưởng thay đổi Thay đổi requirement, rule, field, source hoặc test phải được lần ngược qua liên kết requirement–test–evidence. Không có baseline reference tại v0.9.0. PASS có điều kiện Mọi thay đổi sau review phải cập nhật dòng traceability liên quan và lịch sử thay đổi; không sửa im lặng. Nếu thay đổi tác động privacy, accounting, security hoặc food traceability, mở escalation đúng owner.

Kết luận review: Tier 3 phù hợp làm ví dụ traceability cho Nova Foods mô phỏng khi giữ dữ liệu tổng hợp, ID canonical và trạng thái IN_REVIEW. Hai điều kiện STOP còn hiệu lực cho mọi diễn giải privacy, kế toán, hóa đơn, thuế hoặc compliance chưa có xác minh thẩm quyền. Kết quả này là finding trước baseline; không ghi nhận approval.

6. Cross-File Checks, Open Issues, and Escalation

6.1 Kiểm tra chéo artifact và mâu thuẫn

Kiểm tra chéo xác nhận một dòng trong Requirements To Test Traceability Matrix phải giữ cùng định danh, nghĩa và trạng thái với nguồn canonical. “Canonical” nghĩa là nguồn chuẩn duy nhất để đối chiếu; ma trận không tự tạo requirement, business rule, trường dữ liệu hay kết luận kiểm thử mới. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Mã kiểm tra Đối tượng đối chiếu Bằng chứng và cầu nối suy luận Tiêu chí không mâu thuẫn Kết quả tại v0.9.0
XFC-001 /01-curriculum/TEMPLATE_MANIFEST.md TEMPLATE_MANIFEST là manifest kiểm soát template; metadata ghi IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND, Nova Foods mô phỏng. Tệp này là /03-templates/TMPL-VAL-TRACE-001_requirements-to-test-traceability-matrix.md. Tiêu đề, ID TMPL-VAL-TRACE-001, đường dẫn, trạng thái, phiên bản và phạm vi mô phỏng phải khớp manifest. PASS có điều kiện: dùng đúng tên tệp và trạng thái IN_REVIEW; không diễn giải template là baseline hoặc approval.
XFC-002 /01-curriculum/CHAPTER_MANIFEST.md và /01-curriculum/01_CURRICULUM_ARCHITECTURE.md Hai artifact xác định chuỗi học từ requirement, acceptance criteria, traceability đến test basis. “Test basis” là cơ sở kiểm thử: requirement, rule, dữ liệu, acceptance criteria đã được ghi nhận. Ma trận chỉ nối requirement–test–evidence; không thay chapter bằng quy trình vận hành ERP, không biến test pass thành quyết định nghiệp vụ. PASS: chức năng ma trận khớp controlled handoff của curriculum.
XFC-003 /01-curriculum/TRACEABILITY_ID_REGISTRY.md TRACEABILITY_ID_REGISTRY là registry định danh canonical. Registry nêu ID phải giữ nguyên chuỗi; bản sao hoặc tên rút gọn không thay thế nguồn kiểm soát. Mọi Requirement ID, Rule ID, Data ID, Test Case ID và Evidence ID trong Tier 3 phải có ID đã đăng ký; không đổi tiền tố, không tái sử dụng ID cho nghĩa khác. PASS có điều kiện: TMPL-VAL-TRACE-001 giữ nguyên; ID nghiệp vụ trong dòng Tier 3 phải được đối chiếu registry trước khi gọi là canonical.
XFC-004 /01-curriculum/CANONICAL_BUSINESS_RULES.md CANONICAL_BUSINESS_RULES là catalog quy tắc nghiệp vụ canonical. Owner chỉ duy trì quản trị; không xác nhận rule đúng cho vận hành thực tế. Mô tả test phải kiểm tra rule đã tham chiếu, không viết lại rule với điều kiện, ngưỡng, ngoại lệ hoặc kết luận pháp lý mới. PASS có điều kiện: liên kết rule giữ source boundary; rule liên quan pháp lý, kế toán, thuế, privacy hoặc an toàn thực phẩm không được xem là đã xác minh.
XFC-005 /01-curriculum/CANONICAL_DATA_DICTIONARY.md CANONICAL_DATA_DICTIONARY là nguồn chuẩn cho nghĩa dữ liệu logic. Requirement và test chỉ có thể kiểm tra cùng một field nếu tên, kiểu, định nghĩa và phân loại dữ liệu cùng nguồn. Không dùng tên trường tự dịch, kiểu dữ liệu tự suy diễn hoặc giá trị VND giả định như cấu hình ERP thực. PASS có điều kiện: dữ liệu Nova Foods trong ma trận là synthetic data; mọi field phải truy về Data Dictionary trước khi dùng làm test data hoặc evidence.
XFC-006 /00-research/00_SOURCE_MAP.md và verified primary-source seed Source Map phân loại nguồn pháp lý, chuẩn, đặc tả và good practice; seed giới hạn cách dùng từng URL. Ví dụ ISTQB CTFL hỗ trợ thuật ngữ kiểm thử, không tạo nghĩa vụ pháp lý; BPMN không cho phép gọi PlantUML activity diagram là BPMN. Test terminology, source classification và claim compliance phải đúng safe use boundary. Không gán số điều, trích dẫn hoặc nghĩa vụ chưa xác minh. PASS: ma trận dùng traceability, không tự tuyên bố Nova Foods tuân thủ luật, chuẩn hoặc production-ready.
XFC-007 Template liên quan và consumer hạ nguồn Consumer hạ nguồn gồm QA review, test design, evidence review và change-impact review trong corpus. Consumer cần đọc được liên kết, nhưng không có quyền thay nguồn canonical. Một consumer không được sửa ngược requirement, rule, data definition hoặc source classification chỉ từ kết quả test. PASS: ma trận là bản đồ liên kết; nguồn quyết định vẫn là artifact canonical và vai trò có thẩm quyền.
XFC-008 Metadata quản trị toàn corpus Upstream artifact nhất quán: IN_REVIEW, v0.9.0, 2026-08-07, Asia/Ho_Chi_Minh, vi-VN, Việt Nam, VND, Nova Foods mô phỏng. Suy ra metadata khác giá trị này là contradiction quản trị, dù nội dung test có vẻ hợp lý. Không có dòng, tiêu đề, evidence hoặc kết luận nào dùng APPROVED, BASELINED, production, compliance hoặc user-approved. PASS: ma trận phải giữ nguyên authority boundary của corpus.

Quy tắc phát hiện mâu thuẫn: coi là mâu thuẫn khi cùng một ID có hai nghĩa; cùng một field có hai định nghĩa; test tham chiếu rule không có trong catalog canonical; evidence kết luận vượt phạm vi test; hoặc consumer dùng trạng thái IN_REVIEW như phê duyệt. Khi phát hiện, giữ nguyên nguồn gốc, ghi nhận liên kết bị ảnh hưởng và không tự sửa nguồn canonical trong ma trận.

Sổ vấn đề mở, giả định dự án và mục cần xác minh

Sổ này là đầu vào handoff có kiểm soát cho TMPL-VAL-TRACE-001. “Vấn đề mở” là điểm chưa thể quyết định từ bằng chứng hiện có. “Giả định dự án” là điều kiện tạm dùng để minh họa case mô phỏng. “Cần xác minh” là nội dung chỉ được kết luận bởi vai trò có thẩm quyền. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp, không dùng cho production.

Loại ID mục ID bị ảnh hưởng Nội dung và cầu nối bằng chứng Owner xử lý Ảnh hưởng Hành động kế tiếp
Vấn đề mở OI-VAL-001 TMPL-VAL-TRACE-001, TRACEABILITY_ID_REGISTRY Chưa có bằng chứng trong đầu vào rằng các ID requirement, rule, test case và defect cụ thể đã được cấp cho case Nova Foods. Registry là nguồn kiểm soát ID, nhưng trích đoạn chỉ xác nhận governance, không cung cấp tập ID triển khai. Principal IT Business Analyst / Technical Curriculum Author Không thể ghi liên kết Tier 3 như fact vận hành. Nguy cơ tạo ID ngoài registry. Lập danh sách ID đề nghị; đối chiếu /01-curriculum/TRACEABILITY_ID_REGISTRY.md; chỉ thêm ID sau khi registry ghi nhận.
Vấn đề mở OI-VAL-002 TMPL-VAL-TRACE-001, CHAPTER_MANIFEST, TEMPLATE_MANIFEST Manifest đều ở IN_REVIEW, v0.9.0, chưa có baseline và approval reference. Vì vậy không có căn cứ gọi ma trận là baseline hoặc dùng làm test basis production. Principal IT Business Analyst / Technical Curriculum Author Handoff chỉ phục vụ review học liệu. Không được kích hoạt kiểm thử, triển khai hay sign-off thực tế. Giữ nhãn IN_REVIEW; chờ baseline hoặc approval reference được ghi rõ trong artifact có thẩm quyền.
Giả định dự án PA-VAL-001 TMPL-VAL-TRACE-001, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY Dùng vi-VN, Asia/Ho_Chi_Minh, VND và dữ liệu tổng hợp vì metadata corpus nhất quán nêu các giá trị này. Đây là bối cảnh học liệu, không chứng minh cấu hình ERP thật. Principal IT Business Analyst / Technical Curriculum Author Quy định cách ghi ngày giờ, ngôn ngữ và tiền tệ trong ví dụ ma trận. Gắn nhãn “mô phỏng giáo dục, dữ liệu tổng hợp” cho mọi dòng Nova Foods; chuyển thành yêu cầu triển khai chỉ khi Business Owner và Architect xác nhận.
Giả định dự án PA-VAL-002 TMPL-VAL-TRACE-001, CANONICAL_BUSINESS_RULES Rule nghiệp vụ được liên kết từ catalog canonical thay vì sao chép vào ma trận. Lý do: catalog được chỉ định là nguồn canonical; ma trận chỉ chứng minh liên kết requirement-to-test. Principal IT Business Analyst / Technical Curriculum Author Giảm hai nguồn chân lý cho cùng rule. Không xác nhận rule đúng cho vận hành. Mỗi dòng traceability chỉ lưu ID rule canonical và phiên bản artifact; sửa nội dung rule tại catalog, không sửa ngầm trong ma trận.
Cần xác minh VR-VAL-001 TMPL-VAL-TRACE-001, CANONICAL_BUSINESS_RULES Bất kỳ rule nào suy ra từ Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15 hoặc Nghị định 356/2025/NĐ-CP cần Legal Owner xác minh. Seed chỉ cho phép dùng nguồn chính thức; không cấp diễn giải áp dụng ERP. Legal Owner Gán nhầm nghĩa vụ pháp lý có thể làm requirement, test và kết luận compliance sai. Legal Owner xác minh điều khoản áp dụng, phạm vi dữ liệu và nghĩa vụ; ghi kết quả vào artifact canonical trước khi tạo test compliance.
Cần xác minh VR-VAL-002 TMPL-VAL-TRACE-001, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY Nội dung thuế, kế toán, hóa đơn và chứng từ cần Accounting Owner hoặc Legal Owner xác minh theo Luật Kế toán 88/2015/QH13 và Nghị định 123/2020/NĐ-CP, kể cả sửa đổi còn hiệu lực. Seed nêu rõ không được tự diễn giải. Accounting Owner; Legal Owner Test về số tiền, chứng từ, lưu trữ hoặc phát hành hóa đơn không có thẩm quyền nếu chưa xác minh. Xác minh văn bản hiện hành và quyết định áp dụng; liên kết ID rule đã xác minh vào ma trận.
Cần xác minh VR-VAL-003 TMPL-VAL-TRACE-001, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY Yêu cầu truy xuất, thu hồi hoặc dữ liệu an toàn thực phẩm cần Domain Owner và Legal Owner xác minh theo Luật An toàn thực phẩm 55/2010/QH12. Seed chỉ xác nhận ngữ cảnh traceability/recall, không cung cấp rule chi tiết. Food Safety Domain Owner; Legal Owner Không được mô tả luồng lot, recall hoặc retention như nghĩa vụ pháp lý đã chốt. Xác định phạm vi nghiệp vụ mô phỏng, dữ liệu cần truy vết và căn cứ pháp lý; cập nhật catalog trước khi lập test case.
Cần xác minh VR-VAL-004 TMPL-VAL-TRACE-001, CANONICAL_DATA_DICTIONARY Phân loại dữ liệu, quyền truy cập, API và kiểm thử bảo mật cần Security Owner cùng Architect xác minh. OWASP ASVS 5.0.0 và OWASP API Security Top 10 2023 là good practice, không phải luật Việt Nam; OAS 3.1.1 chỉ là chuẩn mô tả API. Security Owner; Architect Không được gọi test security là chứng nhận an toàn hoặc compliance. Xác định boundary hệ thống, dữ liệu, quyền và API mô phỏng; chọn control/test có căn cứ; ghi nguồn và giới hạn kết luận.
Cần xác minh VR-VAL-005 TMPL-VAL-TRACE-001 Tiêu chí kiểm thử accessibility cần đối chiếu WCAG 2.2 đúng success criterion; tiêu chí test chức năng cần dùng thuật ngữ và kỹ thuật phù hợp ISTQB CTFL v4.0.1. Seed không cho phép gán số criterion hay clause khi chưa kiểm tra nguồn đầy đủ. QA Owner; Accessibility Specialist Test case có thể tham chiếu sai chuẩn hoặc kết luận vượt bằng chứng. QA Owner xác minh từng tham chiếu chuẩn trước khi điền cột test evidence hoặc expected result.

Không đóng các mục trên bằng suy đoán. Principal IT Business Analyst / Technical Curriculum Author duy trì ID, lịch sử và liên kết; Legal Owner, Accounting Owner, Food Safety Domain Owner, Security Owner, Architect, QA Owner giữ thẩm quyền kết luận chuyên môn tương ứng.

Bàn giao có kiểm soát và quy tắc lan truyền thay đổi

Bàn giao có kiểm soát là chuyển artifact cùng ngữ cảnh, trạng thái và giới hạn thẩm quyền để người nhận dùng làm đầu vào review, không phải xác nhận đúng đắn nghiệp vụ hay cho phép triển khai. Bản ghi ma trận này giữ IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND; Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. IN_REVIEW không là BASELINED, APPROVED, compliant hay production-ready.

Nội dung bàn giao Nguồn kiểm soát Người nhận sử dụng Giới hạn sử dụng
Ma trận truy vết yêu cầu đến kiểm thử /03-templates/TMPL-VAL-TRACE-001_requirements-to-test-traceability-matrix.md BA, QA reviewer, Technical Architect, curriculum reviewer Dùng tìm liên kết requirement, rule, data, acceptance criteria và test; không tự xác nhận requirement Nova Foods.
ID và quy tắc đặt ID /01-curriculum/TRACEABILITY_ID_REGISTRY.md BA, QA reviewer, curriculum owner Giữ nguyên ID canonical; không tạo lại, đổi nghĩa hoặc tái sử dụng ID đã có.
Quy tắc nghiệp vụ canonical /01-curriculum/CANONICAL_BUSINESS_RULES.md Business Owner, BA, QA reviewer Chỉ là catalog đang review; Business Owner giữ thẩm quyền xác nhận nghiệp vụ.
Từ điển dữ liệu canonical /01-curriculum/CANONICAL_DATA_DICTIONARY.md Data reviewer, Architect, QA reviewer Không suy diễn schema, migration, quyền truy cập hay cấu hình ERP production.
Danh mục template /01-curriculum/TEMPLATE_MANIFEST.md curriculum owner, template author Xác nhận vị trí và phạm vi template dự kiến; không tạo baseline.
Danh mục chapter /01-curriculum/CHAPTER_MANIFEST.md handbook author, curriculum reviewer Dùng điều phối dependency học liệu; không thay nguồn rule, data hay quyết định nghiệp vụ.

Mọi thay đổi phải bắt đầu từ nguồn canonical, nghĩa là artifact được chỉ định giữ nghĩa gốc của dữ liệu, ID hoặc quy tắc. Ví dụ, nếu nghĩa của một business rule đổi, cập nhật đề xuất phải bắt đầu tại CANONICAL_BUSINESS_RULES; ma trận chỉ cập nhật liên kết bị ảnh hưởng sau khi thay đổi nguồn được ghi nhận. Lý do: sửa trực tiếp ở ma trận tạo hai nguồn chân lý và làm QA không xác định được test đang kiểm tra phiên bản rule nào.

Loại thay đổi Điểm khởi tạo bắt buộc Lan truyền bắt buộc Không được làm
Đổi ID requirement, rule, data element hoặc test /01-curriculum/TRACEABILITY_ID_REGISTRY.md Cập nhật mọi liên kết trong TMPL-VAL-TRACE-001, chapter, template và test consumer dùng ID đó Đổi ID trong một hàng ma trận mà không cập nhật registry.
Đổi nghĩa hoặc điều kiện rule /01-curriculum/CANONICAL_BUSINESS_RULES.md Rà lại requirement, acceptance criteria, test case, exception và liên kết rule-test Gọi thay đổi là quyết định Business Owner khi chưa có ghi nhận từ vai trò này.
Đổi định nghĩa dữ liệu, kiểu dữ liệu hoặc phân loại dữ liệu /01-curriculum/CANONICAL_DATA_DICTIONARY.md Rà lại rule, mapping, validation, test data và kiểm soát bảo mật liên quan Suy diễn cấu trúc DB, API payload hoặc quyền production.
Đổi cấu trúc, tên tệp hoặc phạm vi template /01-curriculum/TEMPLATE_MANIFEST.md Rà lại CHAPTER_MANIFEST, liên kết template và consumer downstream Đổi filename controlled hoặc Artifact ID không có thay đổi quản trị tương ứng.
Đổi mục tiêu hoặc dependency chapter /01-curriculum/CHAPTER_MANIFEST.md Rà lại curriculum architecture, template dependency và đầu vào testing Biến dependency học liệu thành requirement ERP.

Người gửi bàn giao phải ghi: artifact nguồn, version, status, ngày theo Asia/Ho_Chi_Minh, ID bị ảnh hưởng, lý do thay đổi, liên kết cần rà lại và vai trò cần review. Người nhận phải giữ nguyên nhãn IN_REVIEW, không xóa lịch sử thay đổi, không diễn đạt dữ liệu mô phỏng là dữ liệu thật, và không thay nhãn “project assumption” hoặc “Verification required” bằng kết luận bắt buộc.

Principal IT Business Analyst / Technical Curriculum Author điều phối traceability, version và lịch sử thay đổi. Business Owner quyết định nghiệp vụ; Legal Owner xác minh diễn giải pháp lý; Accounting Owner xác minh kế toán và thuế; Security xác minh kiểm soát bảo mật; Technical Architect quyết định kiến trúc; QA reviewer đánh giá đủ bằng chứng kiểm thử. Khi một thay đổi chạm từ hai thẩm quyền trở lên, dừng lan truyền kết luận và gửi gói vấn đề cho các vai trò liên quan. Ma trận chỉ ghi nhận liên kết và trạng thái review sau đó; không thay thế quyết định của bất kỳ vai trò nào.