Tmpl Req 002 Requirement Specification

Artifact Governance Metadata

Trường kiểm soát	Giá trị được kiểm soát	Diễn giải kiểm soát
Artifact ID	TMPL-REQ-002	Định danh canonical của template Requirement Specification (đặc tả yêu cầu). Mọi liên kết, lịch sử thay đổi và kiểm tra truy vết phải dùng đúng chuỗi này, không dùng biến thể dịch thuật hoặc tên rút gọn.
Tên tệp được kiểm soát	/03-templates/TMPL-REQ-002_REQUIREMENT_SPECIFICATION.md	Đây là vị trí canonical của artifact trong corpus. Bản sao, bản xuất hoặc nội dung trích dẫn không thay thế tệp được kiểm soát này.
Tiêu đề tài liệu	Tmpl Req 002 Requirement Specification	Tên hiển thị chính thức của template bốn tầng: Tier 1 quản trị, Tier 2 mẫu trống, Tier 3 tình huống Nova Foods hoàn chỉnh và Tier 4 cổng chất lượng Senior BA.
Status	IN_REVIEW	Artifact đang được xem xét có kiểm soát. Trạng thái này không có nghĩa là APPROVED, BASELINED, sẵn sàng production, tuân thủ pháp luật hoặc đã được người dùng chấp thuận.
Version	v0.9.0	Phiên bản kế hoạch hiện hành. Mọi sửa đổi sau thời điểm này phải tạo dòng lịch sử thay đổi mới; không được sửa im lặng làm thay đổi ý nghĩa kiểm soát của phiên bản.
Owner	Principal IT Business Analyst / Technical Curriculum Author	Owner duy trì định danh, đường dẫn, cấu trúc template, metadata và lịch sử thay đổi. Owner không có thẩm quyền tự xác lập baseline, ghi nhận approval, xác nhận yêu cầu vận hành thực tế, diễn giải pháp lý hoặc cho phép triển khai production.
Last updated date	2026-08-07	Ngày cập nhật metadata hiện hành, được diễn giải theo múi giờ quản trị Asia/Ho_Chi_Minh.
Ngôn ngữ, locale và tiền tệ	vi-VN; Việt Nam; VND	Nội dung hướng dẫn viết bằng tiếng Việt. VND chỉ là đơn vị tiền tệ của tình huống học liệu mô phỏng, không xác nhận dữ liệu tài chính thực tế.
Múi giờ quản trị	Asia/Ho_Chi_Minh	Chuẩn thời gian để ghi nhận thay đổi, review và bằng chứng quản trị trong corpus.
Phân loại artifact	Controlled four-tier template	Đây là template được kiểm soát gồm bốn tầng; không phải đặc tả đã được phê duyệt cho một dự án, hệ thống hoặc doanh nghiệp thực tế.
Baseline reference	Chưa có baseline reference tại v0.9.0	Không được gọi tài liệu này là baseline chỉ vì có số phiên bản, metadata hoặc nội dung case study.
Approval reference	Chưa có approval reference tại v0.9.0	Không có phê duyệt ngầm định từ Owner, trạng thái IN_REVIEW, việc hoàn thành trường dữ liệu hoặc sự tồn tại của nội dung Nova Foods.

Change History

Version	Ngày	Người ghi nhận	Thay đổi được ghi nhận	Trạng thái sau thay đổi
v0.9.0	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Khởi tạo metadata quản trị cho TMPL-REQ-002; cố định Artifact ID, tên tệp, trạng thái IN_REVIEW, ranh giới dữ liệu mô phỏng và cơ chế không suy diễn baseline hoặc approval.	IN_REVIEW

Ranh giới dữ liệu mô phỏng

Nova Foods Trading & Manufacturing là tình huống giáo dục mô phỏng. Toàn bộ tên người, phòng ban, mã yêu cầu, quy trình ERP, số lượng, ngày tháng, số tiền VND, dữ liệu khách hàng, dữ liệu nhà cung cấp và bằng chứng xuất hiện trong template này phải là dữ liệu tổng hợp. Lý do kiểm soát là template dùng để dạy cách cấu trúc Requirement Specification, không dùng để tái hiện hoặc xác nhận hoạt động của một tổ chức có thật.

Không được đưa vào artifact dữ liệu cá nhân thật, bí mật thương mại, thông tin tài khoản, thông tin xác thực hệ thống, dữ liệu production hoặc tài liệu nội bộ không được phép công bố. Nếu một nội dung có vẻ là nghĩa vụ pháp lý, kế toán, thuế, an toàn thực phẩm, bảo vệ dữ liệu cá nhân hoặc bảo mật, nội dung đó chỉ được giữ dưới nhãn giả định dự án hoặc Verification required cho đến khi vai trò có thẩm quyền xác minh theo nguồn chính thức.

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

Requirement Specification (đặc tả yêu cầu) là artifact dùng để chuyển một nhu cầu, vấn đề hoặc cơ hội nghiệp vụ đã có căn cứ thành tập yêu cầu có thể được đọc, kiểm tra, truy vết và chuyển giao cho thiết kế, phát triển và kiểm thử. Template TMPL-REQ-002 không tự tạo ra quyết định nghiệp vụ: nó ghi nhận quyết định, giả định, ngoại lệ, quy tắc và bằng chứng theo cấu trúc kiểm soát. Cơ sở của ranh giới này là một yêu cầu chỉ có giá trị để triển khai khi người đọc phân biệt được điều gì cần thay đổi, vì sao cần thay đổi, ai chịu ảnh hưởng, điều kiện nào chứng minh kết quả đạt yêu cầu và nội dung nào còn cần xác minh.

Nội dung quản trị	Quy định áp dụng cho TMPL-REQ-002
Mục đích sử dụng	Soạn một đặc tả yêu cầu hoàn chỉnh cho phạm vi Nova Foods Trading & Manufacturing mô phỏng; liên kết nhu cầu nghiệp vụ với yêu cầu chức năng, yêu cầu phi chức năng, quy tắc nghiệp vụ, dữ liệu, ngoại lệ, tiêu chí chấp nhận và bằng chứng truy vết.
Khi sử dụng	Dùng khi đã xác định được vấn đề hoặc mục tiêu nghiệp vụ, có phạm vi ban đầu, có vai trò cung cấp thông tin và cần một nguồn đọc chung trước khi tạo thiết kế, backlog triển khai, kịch bản kiểm thử hoặc kế hoạch chuyển đổi. Ví dụ mô phỏng: cần đặc tả thay đổi kiểm soát trạng thái lô hàng trước khi đội phát triển và QA mô phỏng diễn giải khác nhau về cùng một luồng xử lý.
Khi không sử dụng	Không dùng thay cho biên bản phê duyệt, hợp đồng, thiết kế kiến trúc, sơ đồ BPMN chuẩn, đặc tả API OpenAPI, kế hoạch kiểm thử, hướng dẫn vận hành production hoặc kết luận pháp lý/kế toán. Không dùng khi nhu cầu mới chỉ là ý tưởng chưa xác định vấn đề, chủ thể ảnh hưởng hoặc kết quả cần đạt; khi đó phải làm rõ discovery trước, vì điền chi tiết vào template sẽ biến suy đoán thành yêu cầu có vẻ xác định.
Owner	Principal IT Business Analyst / Technical Curriculum Author duy trì cấu trúc template, tính nhất quán định danh, lịch sử thay đổi và traceability của học liệu. Owner không có thẩm quyền xác nhận yêu cầu là đúng cho vận hành thực tế, không tự baseline, không ghi nhận approval và không cấp phép production.
Người tiêu thụ	Business Analyst dùng để phân tích và quản lý phạm vi; Business Owner dùng để xem tác động nghiệp vụ; Solution Architect và Technical Lead dùng để đánh giá khả thi kỹ thuật; QA dùng làm test basis (cơ sở để thiết kế kiểm thử); UX, Security, Data và Operations dùng để nhận diện tác động thuộc chuyên môn của mình. Mỗi bên đọc cùng một đặc tả để giảm rủi ro một yêu cầu bị diễn giải thành nhiều hành vi hệ thống khác nhau.
Điều kiện tiên quyết	Phải có: vấn đề hoặc mục tiêu được mô tả; phạm vi trong/ngoài phạm vi; stakeholder hoặc vai trò cung cấp thông tin; nguồn gốc của từng nhận định; các thuật ngữ chưa rõ được gắn nhãn; và liên kết phù hợp tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY hoặc TRACEABILITY_ID_REGISTRY khi nội dung thuộc quy tắc, dữ liệu hoặc định danh. Nếu chưa có bằng chứng đủ mạnh, ghi rõ giả định dự án hoặc Verification required, không chuyển giả định thành quy tắc bắt buộc.
Artifact hạ nguồn	Đặc tả đã được hoàn thiện là đầu vào cho backlog hoặc hạng mục triển khai, thiết kế giải pháp, mô hình dữ liệu, đặc tả giao diện/API khi phù hợp, tiêu chí chấp nhận, test case, ma trận truy vết và kế hoạch triển khai mô phỏng. Quan hệ là quan hệ đầu vào có truy vết, không phải bằng chứng rằng các artifact hạ nguồn đã được phê duyệt hoặc triển khai.

Quy tắc đủ điều kiện soạn đặc tả: bắt đầu dùng template khi có thể trả lời tối thiểu bốn câu hỏi: vấn đề nào cần giải quyết, ai chịu ảnh hưởng, kết quả nghiệp vụ nào cần quan sát và căn cứ nào hỗ trợ nhận định đó. Lý do là không thể kiểm thử hoặc truy vết một câu như “hệ thống cần tốt hơn” vì câu này không nêu hành vi, điều kiện, kết quả hay nguồn chứng minh. Ngược lại, một yêu cầu có thể được soạn khi nó được tách thành điều kiện đầu vào, xử lý mong đợi, kết quả quan sát được và ngoại lệ đã biết hoặc được đánh dấu cần xác minh.

Thẩm quyền quyết định: Business Owner là nơi xác nhận ý định và ưu tiên nghiệp vụ trong phạm vi mô phỏng; Solution Architect hoặc Technical Lead đánh giá ràng buộc kiến trúc và tích hợp; QA đánh giá khả năng kiểm thử; Security Owner đánh giá yêu cầu bảo mật; Legal/Compliance Owner đánh giá diễn giải liên quan pháp luật; Accounting Owner đánh giá nội dung kế toán, thuế hoặc chứng từ; Data Owner đánh giá định nghĩa và chất lượng dữ liệu. Việc một vai trò cung cấp thông tin không tự động tạo phê duyệt; chỉ tham chiếu phê duyệt được ghi nhận minh bạch trong artifact kiểm soát mới có thể được gọi là approval.

Escalation (chuyển cấp xử lý) phải được kích hoạt khi có mâu thuẫn giữa nguồn, khi một yêu cầu ảnh hưởng đồng thời nghiệp vụ và pháp lý/kế toán/bảo mật, khi không xác định được chủ sở hữu quyết định, hoặc khi chi tiết được đề xuất có thể bị hiểu là cấu hình ERP hay nghĩa vụ production. Owner lập gói vấn đề gồm nội dung mâu thuẫn, nguồn liên quan, tác động, lựa chọn đang xem xét và câu hỏi cần quyết định; sau đó chuyển đúng vai trò có thẩm quyền. Trong thời gian chờ, đặc tả giữ trạng thái Verification required hoặc giả định dự án, không suy diễn kết luận thay cho vai trò chuyên môn.

Ánh xạ Manifest, Định danh Canonical, Nguồn và Nghĩa vụ Kiểm soát Thay đổi

Template này được nhận diện theo tên tệp được kiểm soát /03-templates/TMPL-REQ-002_REQUIREMENT_SPECIFICATION.md và Artifact ID canonical TMPL-REQ-002. Cơ sở suy luận là mã TMPL-REQ-002 xuất hiện nguyên dạng trong tên tệp; vì vậy mọi liên kết, bảng truy vết và yêu cầu thay đổi phải dùng đúng chuỗi này, không đổi thành tên dịch, mã rút gọn hoặc mã tự đặt. Template thuộc danh mục dự kiến tại /01-curriculum/TEMPLATE_MANIFEST.md, có Artifact ID TEMPLATE_MANIFEST; manifest là nguồn kiểm soát danh mục, không phải bằng chứng rằng template đã được baseline hoặc phê duyệt.

Hạng mục ánh xạ	Giá trị canonical	Bằng chứng hoặc lập luận áp dụng	Ranh giới sử dụng
Artifact đang soạn	TMPL-REQ-002	Mã được bảo toàn từ tên tệp /03-templates/TMPL-REQ-002_REQUIREMENT_SPECIFICATION.md.	Không tạo mã thay thế như REQ-SPEC-002 hoặc TMPL-REQ-2.
Manifest danh mục template	TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md	Dependency trực tiếp xác định đây là controlled planning artifact quản lý danh mục template.	Manifest không thay thế nội dung Requirement Specification và không tạo approval.
Manifest chapter	CHAPTER_MANIFEST tại /01-curriculum/CHAPTER_MANIFEST.md	Manifest này là nguồn authoritative cho cấu trúc 26 handbook chapter; template chỉ được liên kết tới chapter khi manifest hoặc artifact kiểm soát ghi nhận liên kết đó.	Không tự gán số hoặc tên handbook chapter khi chưa có liên kết canonical.
Registry định danh và truy vết	TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Registry là nguồn kiểm soát ID và quy tắc traceability giữa requirement, rule, data, test và artifact liên quan.	Không tự tạo ID requirement, rule, data field, interface hoặc test case ngoài quy tắc registry.
Catalog quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md	Requirement Specification có thể tham chiếu quy tắc nghiệp vụ, nên phải giữ ID quy tắc do catalog quản lý.	Không biến ví dụ Nova Foods thành quy tắc vận hành thực tế.
Từ điển dữ liệu	CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Field, thực thể, định nghĩa dữ liệu và chất lượng dữ liệu phải có nguồn canonical để tránh nhiều “nguồn chân lý”.	Không dùng template để tự định nghĩa lại data element đã có nguồn canonical.
Nguồn nghiên cứu	00_SOURCE_MAP tại /00-research/00_SOURCE_MAP.md	Source Map phân loại nguồn chính thức, phạm vi dùng an toàn và giới hạn diễn giải.	Không trích dẫn điều khoản, số trang hoặc nghĩa vụ chi tiết nếu nguồn seed không xác minh nội dung đó.

Bốn chương nội bộ của template phải được giữ đúng mục đích kiểm soát: Tier 1 xác lập metadata, mục đích và governance; Tier 2 là mẫu trống có thể sao chép với placeholder mô tả đặt trong dấu ngoặc nhọn; Tier 3 là hồ sơ Nova Foods hoàn chỉnh bằng dữ liệu tổng hợp; Tier 4 là cổng chất lượng Senior BA. Sự phân tầng này ngăn người học nhầm dữ liệu ví dụ với cấu trúc mẫu, đồng thời ngăn nội dung mô phỏng bị diễn giải là quyết định production.

Nguồn phương pháp cho cách mô tả requirement và truy vết là BABOK Guide Version 3 và ISO/IEC/IEEE 29148:2018, theo ranh giới an toàn được ghi trong 00_SOURCE_MAP: BABOK dùng cho thuật ngữ, nhiệm vụ và năng lực Business Analysis; ISO/IEC/IEEE 29148 chỉ dùng theo abstract và trạng thái thư mục công khai khi chưa kiểm tra văn bản được cấp phép. Khi requirement chạm đến quy trình, mô hình hoặc kiểm thử, chỉ dùng BPMN 2.0.2, UML 2.5.1 và ISTQB CTFL Syllabus v4.0.1 trong đúng phạm vi nguồn. Yêu cầu về API, accessibility hoặc security chỉ được liên kết tương ứng tới OpenAPI Specification 3.1.1, WCAG 2.2, OWASP ASVS 5.0.0 hoặc OWASP API Security Top 10 2023; OWASP là good practice ngành, không phải luật Việt Nam.

Mọi thay đổi đối với TMPL-REQ-002 phải ghi rõ lý do, phần bị ảnh hưởng, ID canonical liên quan, nguồn tham chiếu, tác động đến Tier 2–Tier 4 và tác động tới artifact downstream. Nếu thay đổi làm phát sinh hoặc sửa một ID truy vết, phải đối chiếu TRACEABILITY_ID_REGISTRY; nếu thay đổi định nghĩa rule hoặc data, phải chuyển liên kết tới CANONICAL_BUSINESS_RULES hoặc CANONICAL_DATA_DICTIONARY thay vì sửa im lặng trong template. Nếu thay đổi có yếu tố pháp lý, kế toán, thuế, bảo mật, an toàn thực phẩm hoặc dữ liệu cá nhân, nội dung phải giữ nhãn Verification required hoặc giả định dự án cho đến khi vai trò có thẩm quyền xác minh. Toàn bộ Nova Foods Trading & Manufacturing trong template là case study mô phỏng giáo dục, chỉ sử dụng dữ liệu tổng hợp, bối cảnh vi-VN, Asia/Ho_Chi_Minh và VND; không phải bằng chứng về cấu hình, tuân thủ hoặc vận hành ERP thực tế.

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

Cách dùng: Sao chép nguyên khối mẫu dưới đây cho mỗi yêu cầu. Thay toàn bộ chuỗi trong dấu ngoặc nhọn bằng thông tin cụ thể, kiểm chứng được của phạm vi đang phân tích. Không dùng mô tả mơ hồ như “nhanh”, “dễ dùng” hoặc “xử lý phù hợp” nếu chưa nêu tiêu chí đo lường. Mẫu này là Tier 2 của cấu trúc bốn tầng: chỉ dùng placeholder mô tả, không phải requirement đã được xác nhận.

2.1. Thông tin nhận diện requirement

Trường	Nội dung cần điền
Requirement ID	<Mã requirement duy nhất theo TRACEABILITY_ID_REGISTRY, ví dụ định dạng đã đăng ký>
Tên requirement	<Tên ngắn, bắt đầu bằng đối tượng hoặc năng lực cần có>
Loại requirement	<Business Requirement / Stakeholder Requirement / Functional Requirement / Non-functional Requirement / Data Requirement / Integration Requirement / Reporting Requirement / Security Requirement>
Trạng thái	IN_REVIEW
Phiên bản requirement	<Phiên bản của bản ghi requirement, ví dụ v0.x.x>
Ngày tạo	<YYYY-MM-DD theo Asia/Ho_Chi_Minh>
Ngày cập nhật gần nhất	<YYYY-MM-DD theo Asia/Ho_Chi_Minh>
Tác giả	<Họ tên hoặc vai trò người soạn>
Owner nghiệp vụ	<Vai trò chịu trách nhiệm làm rõ nhu cầu nghiệp vụ; không tự suy diễn approval>
Phạm vi hệ thống	<Tên module ERP, chức năng hoặc thành phần bị ảnh hưởng>
Case study	<Tên case study mô phỏng; nếu dùng Nova Foods phải ghi “Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp”>
Mức ưu tiên	<Must / Should / Could / Won't hoặc thang ưu tiên được dự án quy định>
Mức độ rủi ro	<Thấp / Trung bình / Cao>

2.2. Bối cảnh, vấn đề và mục tiêu

Trường	Nội dung cần điền
Bối cảnh hiện tại	<Mô tả tình huống hiện tại, tác nhân, quy trình và điểm đau có quan sát được>
Vấn đề cần giải quyết	<Nêu khoảng cách giữa hiện trạng và kết quả mong muốn; không mô tả sẵn giải pháp kỹ thuật nếu chưa có quyết định>
Tác động nếu không xử lý	<Tác động nghiệp vụ, vận hành, dữ liệu, khách hàng, kiểm soát hoặc rủi ro>
Mục tiêu nghiệp vụ	<Kết quả nghiệp vụ mong muốn, có thể đo lường hoặc kiểm tra>
Lý do đưa ra requirement	<Liên kết logic từ bằng chứng bối cảnh đến mục tiêu và requirement>
Đối tượng hưởng lợi	<Vai trò, bộ phận hoặc nhóm người dùng nhận lợi ích>

2.3. Phát biểu requirement

Trường	Nội dung cần điền
Phát biểu requirement chuẩn	<Chủ thể hệ thống hoặc quy trình> phải <hành động/năng lực bắt buộc> để <kết quả nghiệp vụ> khi <điều kiện kích hoạt>.
Diễn giải nghiệp vụ	<Giải thích bằng ngôn ngữ nghiệp vụ: ai làm gì, với dữ liệu nào, tại thời điểm nào và nhằm mục đích gì>
Giá trị mong đợi	<Lợi ích cụ thể nếu requirement được đáp ứng>
Ranh giới requirement	<Nêu rõ điều requirement này bao gồm và không bao gồm>
Điều kiện kích hoạt	<Sự kiện, thao tác, lịch chạy hoặc trạng thái dữ liệu bắt đầu xử lý>
Kết quả đầu ra	<Bản ghi, thông báo, trạng thái, báo cáo hoặc hành động được tạo ra>

2.4. Người dùng, vai trò và luồng sử dụng

Trường	Nội dung cần điền
Vai trò khởi tạo	<Vai trò được phép bắt đầu thao tác>
Vai trò xử lý	<Vai trò thực hiện bước xử lý chính>
Vai trò phê duyệt hoặc kiểm soát	<Vai trò kiểm tra, phê duyệt hoặc từ chối nếu áp dụng>
Vai trò chỉ xem	<Vai trò được xem nhưng không được sửa hoặc phê duyệt>
Tiền điều kiện	<Trạng thái, quyền, dữ liệu hoặc cấu hình phải tồn tại trước khi thực hiện>
Luồng thành công chính	<Bước 1: ...; Bước 2: ...; Bước 3: ...; viết đầy đủ từng bước theo thứ tự>
Hậu điều kiện thành công	<Trạng thái cuối, dữ liệu được lưu, thông báo hoặc tác động tiếp theo>

2.5. Quy tắc, dữ liệu và phạm vi xử lý

Trường	Nội dung cần điền
Quy tắc nghiệp vụ liên quan	<ID từ CANONICAL_BUSINESS_RULES hoặc mô tả quy tắc đang chờ đăng ký; không tạo rule canonical ngầm định trong ô này>
Dữ liệu đầu vào	<Tên trường dữ liệu, nguồn nhập hoặc nguồn hệ thống; phân biệt dữ liệu bắt buộc và không bắt buộc trong mô tả>
Dữ liệu đầu ra	<Tên trường, bản ghi, báo cáo hoặc thông báo được sinh ra>
Đối tượng dữ liệu bị ảnh hưởng	<Thực thể nghiệp vụ hoặc logical data object; liên kết CANONICAL_DATA_DICTIONARY khi đã có>
Phạm vi tổ chức	<Công ty, đơn vị, kho, phòng ban hoặc kênh bán hàng áp dụng trong case study>
Phạm vi thời gian	<Ngày hiệu lực dự kiến, kỳ xử lý hoặc điều kiện thời gian>
Đơn vị tiền tệ và locale	<VND, vi-VN, Asia/Ho_Chi_Minh nếu áp dụng; nêu rõ cách xử lý khi không áp dụng>

2.6. Tiêu chí chấp nhận sơ bộ

AC ID	Điều kiện ban đầu	Hành động	Kết quả mong đợi
<AC-ID-01>	<Dữ liệu, quyền và trạng thái trước thao tác>	<Thao tác của người dùng hoặc sự kiện hệ thống>	<Kết quả quan sát và kiểm tra được>
<AC-ID-02>	<Dữ liệu, quyền và trạng thái trước thao tác>	<Thao tác của người dùng hoặc sự kiện hệ thống>	<Kết quả quan sát và kiểm tra được>
<AC-ID-03>	<Dữ liệu, quyền và trạng thái trước thao tác>	<Thao tác của người dùng hoặc sự kiện hệ thống>	<Kết quả quan sát và kiểm tra được>

2.7. Phụ thuộc và tác động sơ bộ

Trường	Nội dung cần điền
Phụ thuộc nghiệp vụ	<Quy trình, quyết định, chính sách hoặc vai trò phải được làm rõ trước>
Phụ thuộc dữ liệu	<Master data, dữ liệu giao dịch, mapping hoặc chất lượng dữ liệu cần có>
Phụ thuộc hệ thống	<Module ERP, dịch vụ, báo cáo, batch job hoặc thành phần liên quan>
Tác động ngược	<Requirement, quy trình hoặc hệ thống khác có thể bị ảnh hưởng>
Giả định dự án	<Giả định chưa được xác nhận; ghi rõ lý do đang cần giả định>
Hạn chế đã biết	<Giới hạn nguồn lực, phạm vi, công nghệ, lịch hoặc thẩm quyền>
Điểm cần làm rõ	<Câu hỏi chưa có đủ bằng chứng để quyết định; nêu vai trò cần phản hồi>

2.1. Khung bảng kiểm soát bắt buộc: versioning, review, sign-off, quyết định, ngoại lệ, bằng chứng và truy vết

Khung này là phần lõi của file /03-templates/TMPL-REQ-002_REQUIREMENT_SPECIFICATION.md vì một requirement specification (đặc tả yêu cầu) chỉ hữu ích khi người đọc có thể truy ra ai ghi nhận, ghi nhận khi nào, dựa trên bằng chứng nào, quyết định nào đã được chốt, ngoại lệ nào còn mở và ai chịu trách nhiệm kiểm tra. Trong Nova Foods mô phỏng, mọi giá trị đều là dữ liệu tổng hợp; không được diễn giải thành phê duyệt thật, baseline thật hoặc quyết định vận hành thật.

Nhóm kiểm soát	Trường bắt buộc	Placeholder điền mẫu	Hướng dẫn sử dụng
Versioning (quản lý phiên bản)	Document ID	<REQ-002>	Giữ nguyên định danh tài liệu trong toàn bộ chuỗi traceability (truy vết).
Versioning	Document title	<TÊN ĐẶT ĐÚNG CỦA TÀI LIỆU>	Dùng đúng tiêu đề đã quản trị; không tự đặt lại tên ở từng bản sao.
Versioning	Version	<vX.Y.Z>	Chỉ dùng kiểu phiên bản tăng dần có kiểm soát; mỗi lần sửa nội dung phải có lý do.
Versioning	Status	<DRAFT / IN_REVIEW / APPROVED / SUPERSEDED>	Chỉ chọn một trạng thái. Không dùng “approved” nếu chưa có bằng chứng phê duyệt ở bảng sign-off.
Versioning	Last updated date	<YYYY-MM-DD>	Ghi theo ngày quản trị của corpus; không để trống vì ảnh hưởng đối chiếu lịch sử.
Versioning	Timezone	<Asia/Ho_Chi_Minh>	Dùng nhất quán để tránh lệch thời điểm giữa review, sign-off và evidence.
Versioning	Locale	<vi-VN>	Bảo đảm cách ghi ngày, tiền tệ và ngôn ngữ thống nhất.
Review tracking	Reviewer role	<BA / SME / QA / Architect / Legal / Accounting>	Vai trò phải phù hợp với loại quyết định được xem xét; không gán vai trò không có thẩm quyền.
Review tracking	Reviewer name	<HỌ TÊN HOẶC MÃ NGƯỜI XEM XÉT>	Dùng danh xưng hoặc mã nội bộ theo quy định dự án; không ghi thay cho người khác.
Review tracking	Review date-time	<YYYY-MM-DD HH:mm:ss>	Ghi thời điểm review để phân biệt với thời điểm sign-off.
Review tracking	Review outcome	<COMMENTED / ACCEPTED / REJECTED / NEEDS-CLARIFICATION>	Outcome (kết quả xem xét) phải phản ánh đúng nội dung kiểm tra, không suy diễn thành phê duyệt.
Review tracking	Review comment summary	<TÓM TẮT NHẬN XÉT>	Mỗi nhận xét phải gắn với một field hoặc một requirement cụ thể.
Sign-off tracking	Sign-off role	<Business Owner / Process Owner / QA Lead / Legal Owner / Accounting Owner>	Chỉ điền khi vai trò đó thực sự có thẩm quyền đối với nội dung tương ứng.
Sign-off tracking	Sign-off name	<HỌ TÊN NGƯỜI KÝ XÁC NHẬN>	Tên phải khớp với hệ thống kiểm soát nội bộ hoặc danh sách quyền hạn của dự án.
Sign-off tracking	Sign-off decision	<APPROVED / APPROVED WITH CONDITIONS / NOT APPROVED>	Không được dùng dạng mơ hồ; quyết định phải rõ ràng và kiểm tra được.
Sign-off tracking	Sign-off date-time	<YYYY-MM-DD HH:mm:ss>	Phải sau hoặc bằng thời điểm review cuối cùng liên quan.
Sign-off tracking	Sign-off scope	<PHẦN NỘI DUNG ĐƯỢC XÁC NHẬN>	Chỉ rõ phạm vi được ký; không mặc định là toàn bộ tài liệu nếu thực tế chỉ ký một phần.
Decision fields	Decision ID	<DEC-001>	Mỗi quyết định phải có mã riêng để truy xuất nhanh trong traceability matrix.
Decision fields	Decision statement	<CÂU KẾT LUẬN NGẮN GỌN>	Viết như một quyết định có thể kiểm tra được, không phải mô tả chung chung.
Decision fields	Decision rationale	<LÝ DO DỰA TRÊN DỮ LIỆU / NGUYÊN TẮC / RÀNG BUỘC>	Phải nêu cầu nối từ dữ liệu và bằng chứng sang kết luận.
Decision fields	Decision owner	<VAI TRÒ CHỊU TRÁCH NHIỆM>	Người/role ra quyết định phải đúng thẩm quyền.
Decision fields	Decision date	<YYYY-MM-DD>	Dùng để đối chiếu với yêu cầu, review và sign-off.
Exception log	Exception ID	<EXC-001>	Mỗi ngoại lệ phải có mã riêng, không gộp nhiều ngoại lệ vào một dòng.
Exception log	Exception description	<MÔ TẢ NGOẠI LỆ>	Viết rõ ngoại lệ là gì, xảy ra ở đâu, và vì sao chưa thể chuẩn hóa.
Exception log	Severity	<LOW / MEDIUM / HIGH / CRITICAL>	Mức độ phải phản ánh tác động thật, không dùng cảm tính.
Exception log	Workaround	<CÁCH XỬ LÝ TẠM THỜI>	Nếu có giải pháp tạm, phải ghi để tránh hiểu nhầm là đã đóng ngoại lệ.
Exception log	Resolution owner	<VAI TRÒ PHỤ TRÁCH XỬ LÝ>	Chỉ rõ vai trò chịu trách nhiệm theo dõi đóng ngoại lệ.
Exception log	Target resolution date	<YYYY-MM-DD>	Ngày mục tiêu chỉ là cam kết theo kế hoạch, không phải xác nhận hoàn tất.
Evidence register	Evidence ID	<EVI-001>	Mã bằng chứng phải gắn với nguồn gốc cụ thể trong corpus.
Evidence register	Evidence type	<MEETING_NOTE / SCREENSHOT / LOG / REPORT / EMAIL / SPEC_REFERENCE>	Loại bằng chứng phải đúng bản chất tài liệu; không gán sai loại.
Evidence register	Evidence source	<FILE / SYSTEM / LINK / ATTACHMENT>	Chỉ rõ bằng chứng đến từ đâu để người đọc kiểm tra lại.
Evidence register	Evidence summary	<TÓM TẮT NỘI DUNG BẰNG CHỨNG>	Tóm tắt ngắn, không sao chép dài dòng nội dung nguồn.
Evidence register	Evidence date-time	<YYYY-MM-DD HH:mm:ss>	Ghi đúng thời điểm phát sinh bằng chứng nếu có thể xác định.
Traceability matrix	Requirement ID	<REQ-001>	Mỗi requirement phải là một dòng riêng để bảo toàn truy vết.
Traceability matrix	Source reference	<ID TÀI LIỆU / MỤC / BẢNG / FILE GỐC>	Nêu nguồn gốc từ upstream artifact để chứng minh yêu cầu đến từ đâu.
Traceability matrix	Downstream link	<TEST-001 / RULE-001 / PROCESS-001>	Liên kết sang kiểm thử, quy tắc hoặc quy trình liên quan; nếu chưa có thì ghi rõ là chưa có liên kết được kiểm chứng.
Traceability matrix	Coverage status	<COVERED / PARTIALLY COVERED / NOT COVERED>	Trạng thái bao phủ giúp nhận ra khoảng trống trước khi chuyển sang triển khai.
Traceability matrix	Traceability note	<GHI CHÚ VỀ MỐI LIÊN HỆ>	Chỉ viết điều có thể suy ra trực tiếp từ nguồn và bằng chứng.

Danh mục kiểm soát bổ sung	Trường bắt buộc	Placeholder điền mẫu	Hướng dẫn sử dụng
Audit trail (vết kiểm toán)	Action ID	<ACT-001>	Ghi mọi hành động thay đổi quan trọng để phục vụ kiểm tra sau này.
Audit trail	Actor	<NGƯỜI THỰC HIỆN HOẶC HỆ THỐNG>	Phân biệt rõ người và hệ thống tự động.
Audit trail	Action type	<CREATE / UPDATE / REVIEW / SIGN-OFF / REJECT>	Chỉ chọn hành động đúng bản chất sự kiện.
Audit trail	Action timestamp	<YYYY-MM-DD HH:mm:ss>	Phải đủ chính xác để dựng lại chuỗi sự kiện.
Audit trail	Before value	<GIÁ_TRỊ TRƯỚC KHI THAY ĐỔI>	Nếu không có thay đổi thì ghi <N/A> và nêu lý do.
Audit trail	After value	<GIÁ_TRỊ SAU KHI THAY ĐỔI>	Dùng để đối chiếu với before value.
Control note	Safe secret-reference pattern	<REF:ARTIFACT-ID:FIELD-ID>	Khi cần dẫn chiếu an toàn đến bí mật nội bộ hoặc dữ liệu nhạy cảm, chỉ tham chiếu theo mã, không chèn trực tiếp secret.
Control note	Validation rule	<MỌI TRƯỜNG KHÔNG ĐƯỢC ĐỂ TRỐNG NẾU ĐÃ ĐƯỢC ĐÁNH DẤU BẮT BUỘC>	Quy tắc này giúp phát hiện thiếu thông tin trước khi tài liệu được xem xét tiếp.

Nếu một dòng trong bảng chưa có dữ liệu, người soạn phải để đúng placeholder dạng dấu ngoặc nhọn và ghi rõ đó là “chưa điền do chưa có nguồn xác minh”, thay vì xóa dòng. Cách làm này giữ nguyên cấu trúc, giữ traceability và giúp Tier 3 có thể thay toàn bộ placeholder bằng dữ liệu Nova Foods mô phỏng đã hoàn chỉnh mà không làm lệch khung kiểm soát.

Hướng dẫn điền trường, giá trị cho phép, quy tắc kiểm tra và điều kiện áp dụng

Dùng hướng dẫn này khi điền Tier 2. Mỗi chỗ đặt trong dấu ngoặc nhọn <...> là placeholder mô tả, nghĩa là người soạn phải thay bằng dữ liệu cụ thể của yêu cầu đang phân tích; không giữ placeholder trong bản Tier 3. Một trường chỉ được ghi “không áp dụng” khi đã nêu lý do, bằng chứng xem xét và vai trò cần xác nhận. Nova Foods Trading & Manufacturing chỉ là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Nhóm trường	Placeholder bắt buộc và cách điền	Giá trị cho phép	Quy tắc kiểm tra
Định danh	<ID yêu cầu theo registry canonical>; <tiêu đề ngắn, một kết quả nghiệp vụ>	ID phải lấy từ TRACEABILITY_ID_REGISTRY; tiêu đề không dùng từ mơ hồ như “cải thiện”, “tối ưu” nếu chưa định lượng	Không tự tạo biến thể ID. Tiêu đề phải cho biết đối tượng, hành vi và kết quả cần đạt.
Phân loại	<Loại yêu cầu>; <mức ưu tiên>; <trạng thái>	Loại: BUSINESS, STAKEHOLDER, SOLUTION_FUNCTIONAL, SOLUTION_NON_FUNCTIONAL, DATA, REPORTING, INTEGRATION, SECURITY, COMPLIANCE, CONSTRAINT. Ưu tiên: MUST, SHOULD, COULD, WONT_FOR_CURRENT_SCOPE. Trạng thái: DRAFT, IN_REVIEW, BASELINED, RETIRED	Không dùng BASELINED nếu không có baseline reference được ghi nhận. Không dùng ưu tiên để thay thế quyết định phê duyệt phạm vi.
Bối cảnh và mục tiêu	<vấn đề hiện tại>; <mục tiêu đo được>; <đơn vị đo>	Đơn vị đo có thể là VND, %, phút, giờ, ngày, bản ghi, giao dịch	Mỗi mục tiêu phải có giá trị hiện trạng hoặc ghi <chưa có số liệu hiện trạng; cần bằng chứng từ nguồn ...>. Không suy diễn số liệu từ ý kiến đơn lẻ.
Mô tả yêu cầu	<chủ thể hệ thống> phải <hành vi> để <kết quả nghiệp vụ>	Dùng câu khẳng định có thể kiểm thử; một câu chính cho một hành vi	Phải xác định rõ tác nhân, điều kiện kích hoạt, dữ liệu vào, xử lý và kết quả. Tách thành yêu cầu khác nếu có nhiều hành vi độc lập.
Quy tắc nghiệp vụ	<ID quy tắc canonical>; <cách yêu cầu sử dụng quy tắc>	Chỉ tham chiếu ID đã đăng ký trong CANONICAL_BUSINESS_RULES	Không sao chép hoặc tự diễn giải quy tắc thành nghĩa vụ vận hành mới. Nếu quy tắc chưa được catalog, ghi <cần đăng ký/xác minh quy tắc> và nêu owner có thẩm quyền.
Dữ liệu	<thực thể/trường dữ liệu canonical>; <kiểu dữ liệu>; <bắt buộc/không bắt buộc>	Kiểu: text, integer, decimal, date, datetime, boolean, code, identifier, currency. Tính bắt buộc: Bắt buộc, Có điều kiện, Không bắt buộc	Tên logic phải đối chiếu CANONICAL_DATA_DICTIONARY. Với tiền tệ dùng VND; ngày giờ ghi theo Asia/Ho_Chi_Minh; không đưa dữ liệu cá nhân thật vào template.
Tiêu chí chấp nhận	<Given/Cho trước>; <When/Khi>; <Then/Thì>	Dùng cấu trúc Given–When–Then, tức điều kiện ban đầu–hành động/sự kiện–kết quả quan sát được	Mỗi tiêu chí phải kiểm thử được, nêu rõ kết quả thành công hoặc từ chối. Không dùng “hệ thống hoạt động đúng” vì không có điều kiện đo lường.
Ngoại lệ	<điều kiện ngoại lệ>; <phản hồi hệ thống>; <hành động người dùng/owner>	Phân loại: VALIDATION_ERROR, BUSINESS_EXCEPTION, INTEGRATION_FAILURE, ACCESS_DENIED, DATA_CONFLICT	Ngoại lệ phải khác luồng thành công, không làm lộ bí mật, và chỉ rõ liệu giao dịch được chặn, lưu nháp hay chuyển xử lý thủ công.
Bằng chứng	<loại bằng chứng>; <đường dẫn hoặc ID artifact>; <ngày truy cập/xem xét>	Loại: WORKSHOP_NOTE, PROCESS_MODEL, DATA_SAMPLE_SYNTHETIC, POLICY_REFERENCE, OFFICIAL_SOURCE, TEST_EVIDENCE, ASSUMPTION_LOG	Phân loại nguồn phải giữ đúng ranh giới nguồn. Nguồn pháp lý, kế toán, thuế, an toàn thực phẩm hoặc bảo vệ dữ liệu chưa xác minh phải ghi Verification required, không kết luận tuân thủ.
Truy vết	<ID nguồn> → <ID yêu cầu> → <ID quy tắc/thiết kế/test khi có>	Chỉ dùng ID canonical đã có trong registry hoặc placeholder mô tả ở Tier 2	Mỗi mũi tên phải nêu quan hệ: derives from, constrains, verifies, hoặc implements. Không dùng một liên kết chung chung thay cho quan hệ cụ thể.
Review và sign-off	<vai trò reviewer>; <quyết định review>; <ngày theo Asia/Ho_Chi_Minh>; <tham chiếu bằng chứng>	Quyết định: PENDING_REVIEW, ACCEPTED_WITH_COMMENTS, REWORK_REQUIRED, ESCALATED	ACCEPTED_WITH_COMMENTS không phải approval. Không ghi approved, signed off hoặc baseline nếu chưa có tham chiếu kiểm soát xác thực.

Quy tắc cho phần có điều kiện: chỉ hiển thị phần tích hợp khi <Loại yêu cầu> là INTEGRATION; chỉ hiển thị phần hiệu năng, khả dụng hoặc khả năng truy cập khi có yêu cầu SOLUTION_NON_FUNCTIONAL; chỉ hiển thị phần dữ liệu nhạy cảm khi dữ liệu được phân loại cần bảo vệ. Với mỗi phần điều kiện, ghi theo mẫu: <Điều kiện kích hoạt> → <lý do áp dụng> → <bằng chứng hoặc giả định> → <vai trò cần xác minh>. Cầu nối suy luận này giúp người đọc phân biệt điều đã có bằng chứng với giả định dự án.

Mẫu tham chiếu bí mật an toàn: dùng <secret-reference: <tên kho bí mật được kiểm soát>/<tên định danh bí mật>; giá trị không được ghi trong tài liệu> thay vì ghi mật khẩu, API key, token, chuỗi kết nối, khóa riêng hoặc dữ liệu xác thực. Ví dụ cấu trúc hợp lệ: <secret-reference: <controlled-secret-store>/<integration-credential-identifier>; owner: <vai trò quản lý>; access: <nhóm được ủy quyền>>. Không ghi giá trị bí mật, không chụp màn hình bí mật, không đưa bí mật vào bằng chứng, payload, tiêu chí chấp nhận hoặc phụ lục.

Quy tắc quyết định tối thiểu: nếu một trường ảnh hưởng đến pháp lý, thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm, kiến trúc, bảo mật hoặc vận hành production, trường đó phải mang nhãn <Project assumption> hoặc <Verification required> cho đến khi có bằng chứng và xác nhận từ owner có thẩm quyền. Lý do là requirement specification ghi nhận nhu cầu và quyết định cần xác minh; nó không tự tạo thẩm quyền pháp lý, kế toán, bảo mật hay phê duyệt triển khai.

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

Bối cảnh mô phỏng: Nova Foods Trading & Manufacturing là case study giáo dục; toàn bộ tên người, tổ chức, giao dịch, mã định danh, ngày giờ và giá trị tiền tệ dưới đây là dữ liệu tổng hợp. Nội dung ở trạng thái xem xét, không phải cấu hình ERP thực tế, không tạo phê duyệt, baseline hoặc quyền triển khai production.

Trường kiểm soát	Giá trị đã điền
Template ID	TMPL-REQ-002
Tệp được kiểm soát	/03-templates/TMPL-REQ-002_REQUIREMENT_SPECIFICATION.md
Requirement ID	REQ-NF-INV-014
Tên yêu cầu	Chặn xuất kho thành phẩm khi số lượng xuất vượt tồn khả dụng của lô
Loại yêu cầu	FUNCTIONAL
Miền nghiệp vụ	Quản lý kho và truy xuất lô thành phẩm
Hệ thống chịu ảnh hưởng	Nova Foods ERP mô phỏng, phân hệ Inventory Management
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
Locale và tiền tệ	vi-VN; VND
Người ghi nhận	Lê Minh An — Business Analyst mô phỏng
Owner nghiệp vụ dự kiến xác minh	Trần Quốc Huy — Warehouse Operations Manager mô phỏng
Quyền quyết định	Business Owner mô phỏng quyết định nhu cầu nghiệp vụ; Solution Architect mô phỏng xác minh tác động thiết kế; QA Lead mô phỏng xác minh khả năng kiểm thử. Không vai trò nào được ghi nhận đã phê duyệt tại phiên bản này.

Tình huống nghiệp vụ đã ghi nhận: Ngày 2026-08-06 14:18:22 theo Asia/Ho_Chi_Minh, nhân viên kho mô phỏng Phạm Gia Bảo lập phiếu xuất kho GI-NF-20260806-0047 cho đơn bán hàng SO-NF-20260806-0189. Đơn hàng thuộc khách hàng mô phỏng CUS-NF-0321 — Siêu thị An Tâm Quận 7, yêu cầu xuất 360 thùng sản phẩm FG-NF-CHA-180 — Cháo Yến Mạch 180 g, lô LOT-NF-CHA-260801-A. Tồn khả dụng được hệ thống mô phỏng hiển thị là 240 thùng; giá vốn kế hoạch của lô là 186.000 VND/thùng, nên phần chênh lệch 120 thùng tương ứng giá trị tham chiếu 22.320.000 VND.

Đối tượng nghiệp vụ	Mã	Giá trị tổng hợp	Vai trò trong tình huống
Kho xuất	WH-NF-HCM-01	Kho thành phẩm Hồ Chí Minh	Nơi ghi nhận tồn và thực hiện xuất hàng
Mặt hàng	FG-NF-CHA-180	Cháo Yến Mạch 180 g	Sản phẩm cần kiểm tra tồn theo lô
Lô hàng	LOT-NF-CHA-260801-A	Hạn dùng mô phỏng 2027-02-01	Đơn vị truy xuất tồn được chọn để xuất
Đơn bán hàng	SO-NF-20260806-0189	360 thùng, giá bán 245.000 VND/thùng, tổng trước thuế 88.200.000 VND	Nguồn phát sinh nhu cầu giao hàng
Phiếu xuất kho	GI-NF-20260806-0047	360 thùng được nhập yêu cầu xuất	Giao dịch cần bị kiểm soát
Người lập phiếu	USR-NF-WH-014	Phạm Gia Bảo, Warehouse Clerk mô phỏng	Nhập và gửi phiếu xuất
Người nhận hàng	CUS-NF-0321	Siêu thị An Tâm Quận 7 mô phỏng	Bên nhận theo đơn bán hàng

Hiện trạng được mô tả từ dữ liệu mô phỏng: ERP mô phỏng kiểm tra số lượng đặt hàng nhưng không chặn nhất quán tại thời điểm người dùng xác nhận phiếu xuất kho theo từng lô. Trong giao dịch GI-NF-20260806-0047, số lượng yêu cầu xuất 360 thùng lớn hơn tồn khả dụng 240 thùng. Cầu nối suy luận là: vì nghiệp vụ giao hàng làm giảm tồn lô, và lượng giảm dự kiến lớn hơn lượng khả dụng, hệ thống cần ngăn việc ghi nhận xuất kho vượt tồn để tránh tạo số dư lô âm hoặc chứng từ giao hàng không phản ánh được hàng thực có.

Nhu cầu được ghi nhận: Nhân viên kho cần nhận thông báo rõ ràng và không thể hoàn tất xác nhận xuất kho khi tổng số lượng xuất của từng dòng lô vượt tồn khả dụng tại kho được chọn. Nhu cầu này giới hạn ở kiểm soát tồn khả dụng của lô thành phẩm trong giao dịch xuất kho; không tự xác định chính sách đặt hàng, giá bán, thuế, hạch toán kế toán, nguyên tắc hạn dùng hoặc nghĩa vụ pháp lý.

Mã nguồn	Phân loại nguồn	Ngày nguồn	Nội dung được phép sử dụng cho requirement	Giới hạn sử dụng
SRC-NF-SYN-OPS-014	SYNTHETIC_BUSINESS_OBSERVATION	2026-08-06	Ghi nhận tình huống phiếu GI-NF-20260806-0047 yêu cầu xuất vượt tồn lô	Là quan sát mô phỏng, không chứng minh quy trình hay dữ liệu của doanh nghiệp thật
SRC-NF-SYN-INT-009	SYNTHETIC_STAKEHOLDER_INTERVIEW_NOTE	2026-08-07	Nêu nhu cầu nhân viên kho cần bị chặn trước khi hoàn tất xuất kho vượt tồn	Là ghi chú phỏng vấn tổng hợp, không phải phê duyệt của Business Owner
SRC-NF-SYN-DATA-021	SYNTHETIC_TRANSACTION_DATASET	2026-08-07	Cung cấp các mã giao dịch, số lượng, giá vốn và giá bán mô phỏng trong core record	Chỉ dùng làm dữ liệu học tập, không dùng cho kiểm toán hoặc quyết toán
CANONICAL_DATA_DICTIONARY	CONTROLLED_INTERNAL_PLAN	2026-08-07	Tham chiếu cách gọi logic cho kho, lô, mặt hàng, phiếu xuất và tồn khả dụng	Artifact đang IN_REVIEW; không phải schema triển khai
CANONICAL_BUSINESS_RULES	CONTROLLED_INTERNAL_PLAN	2026-08-07	Dùng làm ranh giới tham chiếu khi quy tắc nghiệp vụ được chuẩn hóa ở giai đoạn phù hợp	Không suy diễn quy tắc chưa được ghi nhận hoặc chưa được xác minh
Luật Kế toán 88/2015/QH13	OFFICIAL_LEGAL_SOURCE	2026-08-07	Cung cấp bối cảnh rằng chứng từ và số liệu kế toán có thể bị ảnh hưởng bởi giao dịch kho	Không diễn giải yêu cầu này là quy định kế toán; cần Accounting Owner xác minh nếu phát sinh tác động hạch toán
Luật An toàn thực phẩm 55/2010/QH12	OFFICIAL_LEGAL_SOURCE	2026-08-07	Cung cấp bối cảnh tham khảo cho truy xuất lô trong miền thực phẩm	Không xác nhận thiết kế này đáp ứng nghĩa vụ truy xuất; cần domain owner và Legal Owner xác minh

Phân loại thông tin: Mã khách hàng, tên người dùng mô phỏng và dữ liệu giao dịch trong record này được gắn INTERNAL-SYNTHETIC. Lý do là chúng mô tả hoạt động bán hàng, kho và người thực hiện trong case study; tuy nhiên chúng là dữ liệu tổng hợp, không phải dữ liệu cá nhân hay dữ liệu thương mại của cá nhân hoặc tổ chức có thật. Không có mật khẩu, khóa bí mật, token, thông tin thanh toán hoặc dữ liệu định danh cá nhân thực trong requirement này.

Bản ghi yêu cầu lõi đã điền đầy đủ: kiểm soát xuất kho theo lô và hạn dùng

Bối cảnh: Đây là artifact mô phỏng giáo dục của Nova Foods Trading & Manufacturing, chỉ dùng dữ liệu tổng hợp. Tài liệu thuộc /03-templates/TMPL-REQ-002_REQUIREMENT_SPECIFICATION.md, Artifact ID TMPL-REQ-002, 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, locale vi-VN, tiền tệ VND.

Trường lõi	Giá trị đã điền
Requirement ID	REQ-NF-INV-001
Tên yêu cầu	Kiểm soát lô và hạn dùng trước khi xác nhận phiếu xuất kho
Phạm vi	Phân hệ Kho của ERP mô phỏng Nova Foods
Ngoài phạm vi	Tính giá vốn, hạch toán thuế, tự động mua hàng và quyết định thu hồi sản phẩm
Actor chính	USR-NF-WH-017 — Nguyễn Minh An, Nhân viên kho mô phỏng
Actor kiểm soát	USR-NF-SUP-004 — Trần Bảo Linh, Trưởng ca kho mô phỏng
Đối tượng dữ liệu	Sản phẩm SKU-NF-CHL-500, lô LOT-NF-260701-A, hạn dùng 2026-09-30
Giao dịch mẫu	Phiếu xuất DO-NF-260807-0042, khách hàng mô phỏng CUS-NF-0028
Số lượng và giá trị	240 chai; đơn giá mô phỏng 38.000 VND; tổng giá trị 9.120.000 VND
Mục tiêu xử lý	Không cho xác nhận xuất nếu lô đã hết hạn, bị khóa hoặc không đủ số lượng khả dụng
Chủ sở hữu nghiệp vụ	Trưởng bộ phận Kho mô phỏng; chưa có phê duyệt vận hành thực tế
Phân loại dữ liệu	INTERNAL-SYNTHETIC cho người dùng, khách hàng, sản phẩm, lô và giao dịch

Hành vi hiện tại trong mô phỏng: Nhân viên kho nhập mã phiếu DO-NF-260807-0042, chọn sản phẩm SKU-NF-CHL-500, chọn lô LOT-NF-260701-A và nhập số lượng 240. Hệ thống hiện cho phép chuyển phiếu từ DRAFT sang READY_TO_SHIP nếu số lượng tồn kho tổng đáp ứng, nhưng chưa kiểm tra đồng thời hạn dùng, trạng thái khóa lô và số lượng khả dụng của chính lô được chọn. Đây là mô tả hiện trạng tổng hợp cho bài học, không phải khẳng định về ERP đang vận hành.

Trạng thái hợp lệ của phiếu xuất:

Mã trạng thái	Tên trạng thái	Điều kiện chuyển vào	Điều kiện chuyển ra
DRAFT	Nháp	Tạo phiếu với mã duy nhất	Nhân viên lưu đủ dòng hàng và chọn lô
LOT_CHECK_FAILED	Kiểm tra lô không đạt	Có ít nhất một quy tắc lô bị vi phạm	Sửa lô, số lượng hoặc thông tin phiếu
READY_TO_SHIP	Sẵn sàng xuất	Tất cả dòng hàng đạt kiểm tra	Trưởng ca xác nhận xuất hoặc hủy phiếu
SHIPPED	Đã xuất	Trưởng ca xác nhận và hệ thống trừ tồn đúng lô	Không cho sửa dòng hàng
CANCELLED	Đã hủy	Người có quyền hủy ghi nhận lý do	Không được khôi phục trực tiếp

Quy tắc nghiệp vụ hoàn chỉnh:

Rule ID	Quy tắc	Kết quả khi đúng	Kết quả khi sai
BR-NF-INV-001	expiry_date phải lớn hơn hoặc bằng ngày vận hành 2026-08-07	Cho qua kiểm tra hạn dùng	Gán LOT_CHECK_FAILED, mã lỗi LOT_EXPIRED
BR-NF-INV-002	lot_status phải bằng AVAILABLE	Cho phép tiếp tục kiểm tra	Chặn xác nhận, mã lỗi LOT_BLOCKED
BR-NF-INV-003	requested_qty phải lớn hơn 0 và không vượt available_qty của cùng lô	Cho phép chuyển READY_TO_SHIP	Chặn xác nhận, mã lỗi INSUFFICIENT_LOT_QTY
BR-NF-INV-004	Mỗi dòng phải có sku_id, lot_id, uom, requested_qty và unit_price	Dòng hợp lệ	Chặn lưu phiếu, mã lỗi MISSING_REQUIRED_FIELD
BR-NF-INV-005	Tổng tiền dòng bằng requested_qty × unit_price và dùng VND, không làm tròn sai đơn vị	Ghi nhận 9.120.000 VND	Chặn xác nhận, mã lỗi LINE_AMOUNT_MISMATCH
BR-NF-INV-006	Phiếu chỉ chuyển READY_TO_SHIP khi toàn bộ dòng đạt PASS	Hiển thị nút xác nhận cho Trưởng ca	Giữ trạng thái LOT_CHECK_FAILED

Dữ liệu đầu vào và kết quả kiểm tra mẫu:

Trường	Giá trị tổng hợp
document_id	DO-NF-260807-0042
document_date	2026-08-07
warehouse_id	WH-NF-HCM-01
sku_id	SKU-NF-CHL-500
product_name	Nước trái cây cam 500 ml
lot_id	LOT-NF-260701-A
lot_status	AVAILABLE
expiry_date	2026-09-30
available_qty	600 chai
requested_qty	240 chai
uom	chai
unit_price	38.000 VND
line_amount	9.120.000 VND
validation_result	PASS
next_state	READY_TO_SHIP

Payload mô phỏng cho thao tác kiểm tra lô:

{
  "request_id": "REQ-NF-INV-001",
  "document_id": "DO-NF-260807-0042",
  "warehouse_id": "WH-NF-HCM-01",
  "operation_date": "2026-08-07",
  "lines": [
    {
      "sku_id": "SKU-NF-CHL-500",
      "lot_id": "LOT-NF-260701-A",
      "lot_status": "AVAILABLE",
      "expiry_date": "2026-09-30",
      "available_qty": 600,
      "requested_qty": 240,
      "uom": "chai",
      "unit_price_vnd": 38000
    }
  ]
}

Quyết định thiết kế: Chọn phương án chặn chuyển trạng thái tại bước READY_TO_SHIP, thay vì chỉ hiển thị cảnh báo, vì phương án này ngăn giao dịch sai tiếp tục sang SHIPPED. Trưởng ca kho mô phỏng USR-NF-SUP-004 là vai trò quyết định xác nhận xuất; nhân viên kho USR-NF-WH-017 chỉ được sửa dữ liệu và chạy lại kiểm tra. Nếu quy tắc bị triển khai sai, phiếu có thể xuất nhầm lô, làm sai số lượng tồn mô phỏng và phá vỡ khả năng kiểm tra lịch sử giao dịch; do đó nội dung này vẫn là yêu cầu đang xem xét, không phải hướng dẫn production hoặc kết luận tuân thủ pháp lý.

Phân tích vấn đề và quyết định đề xuất cho REQ-NF-AP-014 — Kiểm soát chênh lệch hóa đơn mua nguyên liệu

Bối cảnh mô phỏng: Nova Foods Trading & Manufacturing là case học liệu mô phỏng; mọi dữ liệu dưới đây là dữ liệu tổng hợp. Bản ghi yêu cầu REQ-NF-AP-014 có trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, áp dụng vi-VN, múi giờ Asia/Ho_Chi_Minh và tiền tệ VND. Mục tiêu là kiểm soát việc ghi nhận hóa đơn mua nguyên liệu có chênh lệch so với đơn mua hàng và phiếu nhập kho trước khi chuyển sang trạng thái sẵn sàng thanh toán.

Nhóm phân tích	Nội dung hoàn chỉnh	Phân loại nguồn	Cầu nối bằng chứng và suy luận
Sự thật quan sát được	Ngày 2026-07-28, nhân viên phải trả lập hóa đơn INV-SYN-260728-041 cho nhà cung cấp mô phỏng SUP-SYN-018, tham chiếu đơn mua PO-SYN-260721-115 và phiếu nhập GRN-SYN-260724-089. Đơn mua và phiếu nhập đều ghi 1.000 kg bột ca cao với đơn giá 86.000 VND/kg, tổng trước thuế 86.000.000 VND. Hóa đơn ghi 1.000 kg với đơn giá 91.000 VND/kg, tổng trước thuế 91.000.000 VND; chênh lệch là 5.000.000 VND.	Bằng chứng giao dịch mô phỏng, dữ liệu tổng hợp	Cùng một mã nguyên liệu RM-COCOA-01, cùng số lượng và cùng nhà cung cấp cho phép so sánh đơn giá theo ba chứng từ. Chênh lệch không xuất phát từ số lượng mà từ đơn giá hóa đơn cao hơn đơn mua 5.000 VND/kg.
Hành vi hiện tại	Hệ thống hiện chỉ kiểm tra sự tồn tại của mã đơn mua và phiếu nhập; nếu cả hai tồn tại, người dùng có thể đặt hóa đơn ở trạng thái READY_FOR_PAYMENT dù giá hóa đơn khác giá đơn mua. Không có lý do chênh lệch bắt buộc, không có tác vụ xử lý cho bộ phận mua hàng và không có người chịu trách nhiệm được chỉ định.	Quan sát quy trình mô phỏng	Vì hóa đơn chênh 5.000.000 VND vẫn có thể sẵn sàng thanh toán, kiểm tra đối chiếu ba chứng từ hiện hữu mới dừng ở liên kết tham chiếu, chưa kiểm soát giá trị tài chính.
Nhu cầu gốc	Bộ phận Kế toán phải trả cần ngăn hóa đơn có chênh lệch giá vượt ngưỡng vận hành khỏi luồng thanh toán, đồng thời Bộ phận Mua hàng cần nhận được thông tin đủ để xác nhận hoặc từ chối chênh lệch. “Đối chiếu ba chứng từ” là việc so sánh đơn mua, phiếu nhập kho và hóa đơn để xác định các điểm không khớp trước thanh toán.	Nhu cầu nghiệp vụ mô phỏng	Khi giá hóa đơn có thể vượt giá đã đặt mua mà không có quyết định xử lý, tổ chức không thể phân biệt lỗi nhập liệu với thay đổi giá hợp lệ. Do đó, cần một trạng thái kiểm soát và luồng phân công rõ ràng.
Giả định dự án cần xác minh	Ngưỡng chênh lệch đề xuất là 1% tổng giá trị trước thuế của đơn mua, tối đa 2.000.000 VND cho mỗi dòng hóa đơn. Đây là giả định kiểm soát vận hành phục vụ case học liệu, không phải quy định kế toán, thuế hoặc pháp luật.	Giả định dự án mô phỏng; cần Accounting Owner và Business Owner xác minh	Ngưỡng giúp phân biệt sai lệch nhỏ có thể xử lý nhanh với sai lệch đáng kể cần quyết định. Tuy nhiên, mức ngưỡng ảnh hưởng ghi nhận công nợ và chi phí nên không được BA tự xác lập như quy định chính thức.

Phương án	Mô tả	Ưu điểm	Hạn chế và hệ quả
OPT-NF-AP-014-A	Cho phép mọi hóa đơn có đủ số đơn mua và phiếu nhập đi thẳng đến READY_FOR_PAYMENT.	Ít thay đổi quy trình, thời gian nhập liệu ngắn.	Không ngăn được hóa đơn giá cao hơn thỏa thuận; rủi ro thanh toán sai 5.000.000 VND trong giao dịch mô phỏng vẫn tồn tại.
OPT-NF-AP-014-B	Chặn toàn bộ hóa đơn có bất kỳ chênh lệch nào và yêu cầu tạo lại hóa đơn.	Kiểm soát chặt, quy tắc dễ hiểu.	Không phân biệt chênh lệch hợp lệ và lỗi; có thể làm chậm thanh toán với sai khác nhỏ hoặc thay đổi giá đã được thương lượng hợp lệ.
OPT-NF-AP-014-C	Tự động so sánh giá trị trước thuế theo từng dòng; hóa đơn vượt đồng thời ngưỡng phần trăm hoặc ngưỡng VND chuyển sang PRICE_VARIANCE_REVIEW, tạo tác vụ cho Mua hàng; chỉ được chuyển sang READY_FOR_PAYMENT sau quyết định xử lý được ghi nhận.	Cân bằng kiểm soát tài chính và vận hành; giữ được dấu vết lý do, người xử lý và kết quả.	Cần cấu hình trạng thái, ngưỡng và phân quyền; ngưỡng phải được chủ sở hữu nghiệp vụ và kế toán xác minh trước khi dùng ngoài mô phỏng.

Tiêu chí quyết định	Trọng số	OPT-NF-AP-014-A	OPT-NF-AP-014-B	OPT-NF-AP-014-C	Lý do chấm điểm
Ngăn thanh toán sai giá trị	40%	1/5	5/5	5/5	Phương án A không tạo điểm chặn; B và C không cho thanh toán khi chênh lệch chưa xử lý.
Duy trì tốc độ xử lý hóa đơn hợp lệ	25%	5/5	2/5	4/5	A nhanh nhưng thiếu kiểm soát; B chặn cả chênh lệch nhỏ; C chỉ đưa trường hợp vượt ngưỡng vào xem xét.
Khả năng truy vết quyết định	20%	1/5	3/5	5/5	C lưu trạng thái, lý do và vai trò xử lý; A không yêu cầu ghi nhận; B chỉ ghi nhận việc chặn.
Khả năng cấu hình và vận hành	15%	5/5	4/5	3/5	C phức tạp hơn vì có ngưỡng và tác vụ, nhưng vẫn phù hợp phạm vi ERP mô phỏng.
Tổng điểm có trọng số	100%	2,60/5	3,85/5	4,45/5	C đạt điểm cao nhất vì đáp ứng đồng thời kiểm soát, tốc độ và truy vết.

Khuyến nghị: chọn OPT-NF-AP-014-C. Với hóa đơn INV-SYN-260728-041, chênh lệch 5.000.000 VND tương đương 5,81% giá trị đơn mua và vượt cả 1% lẫn 2.000.000 VND. Hệ thống phải đặt hóa đơn vào trạng thái PRICE_VARIANCE_REVIEW, không cho chuyển sang READY_FOR_PAYMENT, và tạo tác vụ TASK-SYN-AP-260728-041 cho vai trò Buyer. Người xử lý phải chọn một trong ba kết quả: ACCEPTED_WITH_JUSTIFICATION, REJECTED_FOR_CREDIT_NOTE, hoặc CORRECTED_INVOICE_RECEIVED; mỗi kết quả phải có lý do nghiệp vụ cụ thể và thời điểm ghi nhận theo Asia/Ho_Chi_Minh.

Thẩm quyền quyết định: Business Owner chịu trách nhiệm quyết định có chấp nhận quy trình kiểm soát và ngưỡng vận hành hay không; Accounting Owner xác minh ảnh hưởng đến ghi nhận công nợ, chi phí và thanh toán; Procurement Manager xác minh quy trình xử lý chênh lệch với nhà cung cấp; Solution Architect xác minh tính khả thi của trạng thái, tác vụ và phân quyền ERP. Principal IT Business Analyst / Technical Curriculum Author chỉ ghi nhận khuyến nghị, duy trì tính nhất quán của yêu cầu và không tự quyết định ngưỡng hoặc cho phép vận hành production.

Hệ quả nếu quyết định sai: nếu chọn phương án A hoặc đặt ngưỡng quá cao, Nova Foods mô phỏng có thể thanh toán vượt 5.000.000 VND cho hóa đơn trên mà không có căn cứ xử lý. Nếu chọn phương án B hoặc đặt ngưỡng quá thấp, các hóa đơn hợp lệ có thể bị giữ lại không cần thiết, làm chậm công nợ và quan hệ nhà cung cấp. Nếu phân quyền sai, người lập hóa đơn có thể tự xử lý chênh lệch của chính mình, làm suy yếu nguyên tắc phân tách trách nhiệm.

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

Trong bối cảnh Nova Foods là mô phỏng giáo dục và chỉ dùng dữ liệu tổng hợp, phần này ghi nhận exception (ngoại lệ), negative path (luồng âm), evidence (bằng chứng), assumption (giả định), mục cần verification required (cần xác minh), và escalation (chuyển cấp) cho cùng một tình huống hóa đơn INV-SYN-260728-041 có chênh lệch giá. Lý do nghiệp vụ từ đầu tiên là: nếu hệ thống phát hiện chênh lệch 5.000.000 VND vượt ngưỡng kiểm soát 1% và vượt ngưỡng tuyệt đối 2.000.000 VND, thì không thể cho qua như hóa đơn hợp lệ vì dấu hiệu rủi ro chưa được xử lý. Từ đó suy ra hệ thống phải giữ trạng thái kiểm tra, ghi nhận tác vụ cho Buyer, và tách riêng luồng đúng khỏi luồng sai để bảo toàn traceability (khả năng truy vết) từ dữ liệu đầu vào đến quyết định nghiệp vụ.

Mã ngoại lệ / luồng âm	Điều kiện kích hoạt	Dấu hiệu phát hiện	Xử lý bắt buộc trong mô hình	Bằng chứng tham chiếu	Lý do truy vết
EX-NF-AP-014-01	Hóa đơn có giá trị lệch so với PO nhưng vượt đồng thời ngưỡng 1% và 2.000.000 VND	price_variance_amount = 5.000.000 VND, variance_pct = 5,81%	Đặt hóa đơn ở PRICE_VARIANCE_REVIEW, không cho sang READY_FOR_PAYMENT	INV-SYN-260728-041, PO-SYN-260728-041, TASK-SYN-AP-260728-041	Vì mức lệch vượt cả hai ngưỡng, nên lý do duy nhất đủ an toàn là giữ lại để kiểm tra, tránh thanh toán sai
EX-NF-AP-014-02	Nhà cung cấp chưa phản hồi chứng từ điều chỉnh	Không có credit note hoặc invoice sửa	Ghi trạng thái WAITING_SUPPLIER_RESPONSE và mở hạn theo dõi	CASELOG-SYN-AP-260728-041-01	Vì chưa có tài liệu hiệu chỉnh nên hệ thống không có căn cứ để tự kết thúc ngoại lệ
NP-NF-AP-014-01	Người xử lý cố gắng bấm duyệt thanh toán khi còn chênh lệch	Nút duyệt bị chặn bởi rule	Từ chối hành động, hiển thị lý do “variance unresolved”	UILOG-SYN-AP-260728-041-01	Vì kiểm soát phải chặn ở điểm thao tác, không chỉ chặn ở báo cáo cuối kỳ
NP-NF-AP-014-02	Người tạo hóa đơn đồng thời tự xử lý ngoại lệ của chính mình	Trùng vai trò tạo và duyệt	Không cho xác nhận xử lý, bắt buộc chuyển cấp	ROLECHECK-SYN-AP-260728-041-01	Vì phân tách trách nhiệm là điều kiện tối thiểu để giảm rủi ro thao túng
NP-NF-AP-014-03	Dữ liệu PO thiếu đơn giá chuẩn để so sánh	Trường unit_price rỗng	Đưa hồ sơ vào DATA_INCOMPLETE và yêu cầu bổ sung	PO-SYN-260728-041, DATA-ERR-SYN-AP-041	Vì không có dữ liệu gốc thì mọi kết luận về chênh lệch đều không đủ căn cứ

Nhóm	Nội dung đã ghi nhận	Mức độ tin cậy	Cần xác minh thêm	Vì sao cần xác minh
Giả định nghiệp vụ	Ngưỡng 1% và 2.000.000 VND là ngưỡng kiểm soát của case học tập này	Trung bình	Legal/Accounting/Procurement owner xác nhận đây chỉ là ngưỡng mô phỏng	Vì ngưỡng thật trong vận hành phải dựa trên chính sách được phê duyệt, không được suy diễn từ ví dụ
Giả định dữ liệu	INV-SYN-260728-041 và PO-SYN-260728-041 là dữ liệu tổng hợp, không gắn với nhà cung cấp thực	Cao	Không cần xác minh danh tính thật, chỉ cần xác minh tính nhất quán nội bộ	Vì dữ liệu synthetic chỉ phục vụ học liệu và test basis
Giả định quy trình	Chỉ Buyer được xử lý TASK-SYN-AP-260728-041, không cho Supplier tự duyệt	Cao	Solution Architect xác minh phân quyền trong mô hình ERP	Vì quyền sai sẽ làm mất nguyên tắc kiểm soát chéo
Giả định pháp lý	Các nội dung thuế, kế toán, hóa đơn điện tử, và dữ liệu cá nhân chỉ là nhãn kiểm soát, chưa phải kết luận pháp lý	Cao	Legal/Accounting owner xác minh trước khi dùng cho tài liệu vận hành	Vì nguồn pháp lý cần đối chiếu văn bản hiện hành và thẩm quyền chuyên môn

Mã kiểm chứng	Nội dung cần xác minh	Nguồn tham chiếu an toàn	Người/nhóm cần xác minh	Trạng thái hiện tại
VRF-AP-014-01	Ngưỡng chênh lệch nào được phép áp dụng cho hóa đơn chờ thanh toán	Luật Kế toán, Nghị định 123/2020/NĐ-CP	Accounting Owner	Chưa xác minh
VRF-AP-014-02	Có cần lưu nhật ký xử lý ngoại lệ theo thời hạn nội bộ nào không	BABOK Guide cho traceability, chính sách nội bộ mô phỏng	Business Owner, BA Lead	Chưa xác minh
VRF-AP-014-03	Trường dữ liệu nào là bắt buộc để kết luận chênh lệch giá	CANONICAL_DATA_DICTIONARY khi được liên kết ở lô sau	Solution Architect, Data Owner	Chưa xác minh
VRF-AP-014-04	Quy tắc giữ hồ sơ và bằng chứng xử lý ngoại lệ có cần phân loại bảo mật không	OWASP ASVS, Luật Bảo vệ dữ liệu cá nhân	Security Owner, Legal Owner	Chưa xác minh

Mã escalation	Lý do chuyển cấp	Đối tượng nhận	Bằng chứng kèm theo	Thời điểm ghi nhận
ESC-NF-AP-014-01	Chênh lệch vượt ngưỡng và chưa có căn cứ chấp nhận	Buyer Lead	INV-SYN-260728-041, PO-SYN-260728-041, TASK-SYN-AP-260728-041	2026-08-07T09:15:00+07:00
ESC-NF-AP-014-02	Cần xác minh ảnh hưởng kế toán trước khi cho phép tiếp tục	Accounting Owner	CASELOG-SYN-AP-260728-041-01, DATA-ERR-SYN-AP-041	2026-08-07T09:18:00+07:00
ESC-NF-AP-014-03	Cần xác minh phân quyền để tránh người tạo tự duyệt	Solution Architect	ROLECHECK-SYN-AP-260728-041-01	2026-08-07T09:20:00+07:00
ESC-NF-AP-014-04	Cần xác minh tính hợp lệ của nhãn pháp lý và lưu trữ bằng chứng	Legal Owner, Security Owner	VRF-AP-014-01, VRF-AP-014-04	2026-08-07T09:22:00+07:00

Kết luận truy vết cho lô này là: mọi ngoại lệ đều quay về cùng một gốc dữ liệu, đó là chênh lệch giá của INV-SYN-260728-041; mọi luồng âm đều chứng minh điều không được phép xảy ra là thanh toán khi chưa xử lý chênh lệch; mọi bằng chứng đều phải gắn ID synthetic rõ ràng để không nhầm với dữ liệu thật; và mọi điểm chưa đủ thẩm quyền đều phải chuyển cấp thay vì tự kết luận. Điều này bảo đảm corpus Nova Foods giữ đúng nguyên tắc: mô phỏng, có kiểm soát, và không biến giả định học liệu thành quy tắc vận hành thực tế.

4.3 Ma trận truy vết đầu-cuối cho nhu cầu AP-014 của Nova Foods mô phỏng

Truy vết (traceability) nghĩa là nối được một nhu cầu từ gốc đến từng yêu cầu, quy tắc nghiệp vụ, tiêu chí chấp nhận, dữ liệu/API, ca kiểm thử và bằng chứng, để người đọc thấy rõ “vì sao có mục này” và “mục này được xác minh bằng gì”. Với kịch bản Nova Foods mô phỏng về chênh lệch giá hóa đơn mua hàng, chuỗi dưới đây chỉ dùng dữ liệu tổng hợp, không tạo baseline và không ngụ ý phê duyệt vận hành thực tế.

Family	Canonical ID	Nội dung kiểm soát	Nguồn gốc trong corpus	Lý do liên kết
NEED	NEED-NF-AP-014	Không cho phép thanh toán khi hóa đơn mua hàng có chênh lệch giá chưa được xác minh	/03-templates/TMPL-REQ-002_REQUIREMENT_SPECIFICATION.md	Đây là nhu cầu nghiệp vụ gốc của kịch bản; mọi thành phần khác phải quy về nhu cầu này để tránh sinh rule rời rạc.
REQ	REQ-NF-AP-014-01	Hệ thống phải chặn bước thanh toán nếu trạng thái đối soát giá = PENDING	Cùng bộ template Nova Foods, phần Core Record	Đây là yêu cầu chức năng trực tiếp chuyển nhu cầu thành hành vi hệ thống có thể kiểm tra.
REQ	REQ-NF-AP-014-02	Hệ thống phải ghi nhận lý do chặn theo mã chuẩn PRICE_VARIANCE_PENDING	Cùng bộ template Nova Foods, phần Core Record	Yêu cầu này tạo dấu vết kiểm soát để BA, QA và nghiệp vụ nhìn thấy nguyên nhân chặn, không cần suy diễn.
BR	BR-NF-AP-014-01	Chỉ cho thanh toán khi chênh lệch giá đã được xác minh bởi vai trò có thẩm quyền	Nguồn tổng hợp từ quy ước nghiệp vụ mô phỏng Nova Foods	Quy tắc này là logic quyết định nền, là cầu nối giữa nhu cầu “không cho thanh toán” và hành vi chặn cụ thể.
BR	BR-NF-AP-014-02	Một chứng từ chỉ được đi tiếp khi có quyết định rõ: APPROVED, REJECTED, hoặc RETURNED_FOR_FIX	Nguồn tổng hợp từ quy ước nghiệp vụ mô phỏng Nova Foods	Quy tắc này ngăn trạng thái mơ hồ; nếu không có kết quả rõ thì hệ thống không được tự mở khóa thanh toán.
AC	AC-NF-AP-014-01	Khi đối soát giá chưa xong, nút Submit Payment bị vô hiệu và hiển thị thông báo chặn	Cùng bộ template Nova Foods, phần Acceptance	Đây là tiêu chí chấp nhận kiểm tra được bằng quan sát giao diện và trạng thái nghiệp vụ.
AC	AC-NF-AP-014-02	Nhật ký xử lý phải lưu invoice_id, po_id, variance_amount, decision_code	Cùng bộ template Nova Foods, phần Acceptance	Tiêu chí này đảm bảo bằng chứng đủ để kiểm thử, kiểm toán và truy vết sau sự kiện.
DATA	DATA-NF-AP-014-01	invoice_id=INV-SYN-260728-041, po_id=PO-SYN-260728-041, variance_amount=150000	Dữ liệu mô phỏng đã dùng trong micro-batch trước	Đây là bộ dữ liệu đầu vào cụ thể để làm cho traceability không trừu tượng.
API	API-NF-AP-014-01	POST /api/ap/payments/submit	Bộ thiết kế API mô phỏng của scenario Nova Foods	Endpoint là điểm thực thi nơi yêu cầu và quy tắc được kiểm tra trong luồng hệ thống.
TC	TC-NF-AP-014-01	Ca kiểm thử “chặn thanh toán khi variance pending”	Bộ ca kiểm thử mô phỏng của scenario Nova Foods	Ca kiểm thử xác nhận chuỗi NEED → REQ → BR → AC chạy đúng trên dữ liệu tổng hợp.
DEF/CR	DEF-NF-AP-014-01	DECLINED_DUE_TO_PRICE_VARIANCE / CR- chưa phát sinh ở lô này	Nhật ký lỗi mô phỏng và quy ước thay đổi của corpus	Mã lỗi giúp phân biệt từ chối hợp lệ với lỗi kỹ thuật; chưa có CR vì chưa bước sang lô quản trị thay đổi.

Chuỗi truy vết chuẩn của lô này là: NEED-NF-AP-014 → REQ-NF-AP-014-01/REQ-NF-AP-014-02 → BR-NF-AP-014-01/BR-NF-AP-014-02 → AC-NF-AP-014-01/AC-NF-AP-014-02 → DATA-NF-AP-014-01 → API-NF-AP-014-01 → TC-NF-AP-014-01 → DEF-NF-AP-014-01. Suy luận ở đây rất thẳng: nếu nhu cầu là “không cho thanh toán khi chưa xác minh chênh lệch giá”, thì yêu cầu phải biến nó thành chặn hệ thống, quy tắc phải nói rõ điều kiện mở khóa, tiêu chí chấp nhận phải đo được, dữ liệu phải có mã chênh lệch cụ thể, còn test case phải chứng minh hành vi đó trên endpoint thật của mô phỏng. Vì Nova Foods là mô phỏng giáo dục, mọi ID, payload và mã lỗi trên đều là synthetic data và chưa tạo baseline.

4.3 Bảng quyết định, payload và dữ liệu kiểm thử mô phỏng cho chặn thanh toán chênh lệch giá

Bảng quyết định (decision table — bảng liệt kê tổ hợp điều kiện và kết quả hệ thống) dưới đây là bằng chứng có thể thực thi cho REQ-NF-AP-014-01, REQ-NF-AP-014-02, BR-NF-AP-014-01, BR-NF-AP-014-02 và AC-NF-AP-014-01/AC-NF-AP-014-02. Cầu nối suy luận là: NEED-NF-AP-014 yêu cầu không thanh toán khi chênh lệch giá chưa được xác minh; vì vậy hệ thống phải đọc đồng thời trạng thái hóa đơn và trạng thái priceVariance, rồi chỉ tạo lệnh thanh toán khi cả hai điều kiện mở khóa đều đúng. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ mã và số tiền VND dưới đây là dữ liệu tổng hợp, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Quy tắc quyết định	Invoice status	Price variance status	Điều kiện cho phép thanh toán	Kết quả endpoint API-NF-AP-014-01	Mã kết quả mô phỏng
DT-NF-AP-014-01	APPROVED	RESOLVED	Đúng	Tạo payment request với trạng thái PENDING_PAYMENT	PAYMENT_REQUEST_CREATED
DT-NF-AP-014-02	APPROVED	PENDING	Sai	Không tạo payment request; giữ hóa đơn ở APPROVED	DECLINED_DUE_TO_PRICE_VARIANCE
DT-NF-AP-014-03	IN_REVIEW	RESOLVED	Sai	Không tạo payment request; giữ hóa đơn ở IN_REVIEW	DECLINED_DUE_TO_INVOICE_STATUS
DT-NF-AP-014-04	IN_REVIEW	PENDING	Sai	Không tạo payment request; giữ hóa đơn ở IN_REVIEW	DECLINED_DUE_TO_INVOICE_STATUS

Payload yêu cầu dưới đây là dữ liệu đầu vào hoàn chỉnh cho trường hợp DT-NF-AP-014-02, được dùng bởi TC-NF-AP-014-01. Số varianceAmountVnd được tính từ invoicedUnitPriceVnd - purchaseOrderUnitPriceVnd = 58.000 - 55.000 = 3.000 VND mỗi đơn vị; với quantity = 120, tổng chênh lệch là 360.000 VND. Bằng chứng tính toán này giải thích vì sao priceVariance.status là PENDING và vì sao kết quả phải bị chặn theo bảng quyết định.

{
  "requestId": "PAYREQ-NF-AP-014-001",
  "invoiceId": "INV-NF-202608-014",
  "supplierId": "SUP-NF-008",
  "purchaseOrderId": "PO-NF-202607-031",
  "currency": "VND",
  "invoiceStatus": "APPROVED",
  "paymentAmountVnd": 6960000,
  "priceVariance": {
    "varianceId": "PVAR-NF-202608-014",
    "purchaseOrderUnitPriceVnd": 55000,
    "invoicedUnitPriceVnd": 58000,
    "quantity": 120,
    "varianceAmountVnd": 360000,
    "status": "PENDING"
  },
  "requestedAt": "2026-08-07T10:15:00+07:00",
  "requestedByUserId": "USR-NF-AP-021"
}

Thành phần dữ liệu kiểm thử	Giá trị tổng hợp	Liên kết kiểm chứng
invoiceId	INV-NF-202608-014	Định danh hóa đơn đầu vào cho TC-NF-AP-014-01.
paymentAmountVnd	6.960.000	Giá trị yêu cầu thanh toán bằng VND; không phải giá trị tài chính thực tế.
purchaseOrderUnitPriceVnd	55.000	Giá đơn vị từ PO mô phỏng PO-NF-202607-031.
invoicedUnitPriceVnd	58.000	Giá đơn vị trên hóa đơn mô phỏng.
quantity	120	Số lượng dùng để tái lập phép tính chênh lệch.
varianceAmountVnd	360.000	Kết quả (58.000 − 55.000) × 120; phải khớp payload.
Kết quả mong đợi	DECLINED_DUE_TO_PRICE_VARIANCE	Xác nhận AC-NF-AP-014-01: không tạo payment request khi variance còn PENDING.
Payment request được tạo	false	Bằng chứng trực tiếp cho BR-NF-AP-014-01 và BR-NF-AP-014-02.

Sơ đồ logic kiểm thử của TC-NF-AP-014-01 là: INV-NF-202608-014 (APPROVED) → đọc PVAR-NF-202608-014 (PENDING, 360.000 VND) → áp dụng DT-NF-AP-014-02 → trả DECLINED_DUE_TO_PRICE_VARIANCE → paymentRequestCreated = false. Đây là sơ đồ luồng quyết định nội bộ của case mô phỏng, không được gọi là BPMN và không xác nhận cấu hình ERP, quy tắc kế toán hoặc phê duyệt vận hành thực tế.

5. Tier 4 ? Senior BA Quality Gate

/03-templates/TMPL-REQ-002_REQUIREMENT_SPECIFICATION.md dùng “Tier 4 ? Senior BA Quality Gate” như một quality gate (cổng chất lượng) trước baseline: đây là điểm kiểm tra bắt buộc để Senior BA xem xét một bản yêu cầu đã đủ chín để đi tiếp hay chưa, dựa trên bằng chứng trong artifact chứ không dựa trên cảm giác. “Pass” nghĩa là đạt ngưỡng chấp nhận của checklist; “Fail” nghĩa là chưa đạt nhưng còn có thể sửa trong phạm vi BA; “Stop” nghĩa là dừng ngay vì có rủi ro sai thẩm quyền, sai nguồn, sai pháp lý hoặc đứt traceability (khả năng truy vết); “Escalation” nghĩa là chuyển cấp cho vai trò có thẩm quyền phù hợp vì vấn đề vượt quyền BA hoặc chạm nhiều miền chuyên môn.

Mã kiểm tra	Hạng mục	Tiêu chí Pass	Tiêu chí Fail	Tiêu chí Stop	Tiêu chí Escalation
QG-01	Tính đầy đủ của yêu cầu	Mỗi yêu cầu có ID ổn định, mô tả rõ, điều kiện áp dụng, đầu vào, đầu ra, ngoại lệ và ràng buộc; không có ô trống quan trọng.	Thiếu một phần có thể bổ sung bằng chỉnh sửa nội dung mà không đổi bản chất nghiệp vụ.	Thiếu trường trọng yếu làm mất nghĩa xác định của yêu cầu, ví dụ không biết đối tượng, hành vi hoặc kết quả.	Khi thiếu dữ liệu cần Business Owner, SME hoặc legal/accounting owner xác nhận.
QG-02	Tính nhất quán nội bộ	Thuật ngữ, số liệu, trạng thái, ID và luồng xử lý không mâu thuẫn giữa các phần của cùng một artifact và các file liên quan.	Có mâu thuẫn nhỏ có thể sửa bằng làm sạch nội dung và chuẩn hóa thuật ngữ.	Mâu thuẫn làm một yêu cầu có hai nghĩa loại trừ nhau, hoặc số liệu không thể cùng đúng.	Khi mâu thuẫn chạm sang kiến trúc, dữ liệu, bảo mật hoặc vận hành.
QG-03	Tính kiểm thử được	Mỗi yêu cầu có thể chuyển thành test case, tiêu chí mong đợi rõ ràng, quan sát được và đo được.	Mô tả có thể hiểu nhưng chưa đủ để viết test case trực tiếp.	Yêu cầu mơ hồ đến mức không thể xác minh bằng quan sát hoặc dữ liệu kiểm thử.	Khi cần ISTQB-style test design (thiết kế kiểm thử theo ISTQB) hoặc test owner xác nhận thêm.
QG-04	Tính truy vết	Mỗi yêu cầu có liên kết ngược đến nguồn, bản ghi tham chiếu hoặc rule gốc; có thể lần theo từ requirement đến evidence.	Traceability có nhưng chưa đủ chặt, cần bổ sung ID hoặc liên kết.	Không truy được nguồn gốc hoặc nguồn bị mất ranh giới, làm yêu cầu trở thành suy diễn không kiểm soát.	Khi cần QA lead, repository owner hoặc source owner xác nhận đường truy vết.
QG-05	Thẩm quyền nguồn	Nguồn được gắn đúng loại: chuẩn, luật, tài liệu dự án, hay synthetic case; không dùng nguồn ngoài phạm vi như thể là luật.	Nguồn có nhưng cách diễn đạt chưa đúng mức độ thẩm quyền.	Biến nguồn tham khảo thành nghĩa vụ bắt buộc mà chưa có xác minh pháp lý hoặc owner hợp lệ.	Khi chạm luật Việt Nam, kế toán, thuế, bảo mật, an toàn thực phẩm hoặc production control.
QG-06	Ownership	Owner, reviewer, approver reference và giới hạn thẩm quyền được ghi rõ; không ngầm suy ra approval từ metadata.	Có owner nhưng vai trò phụ hoặc phạm vi trách nhiệm chưa rõ.	Không xác định được ai có quyền sửa, ai có quyền xác nhận, hoặc ai chịu trách nhiệm nội dung.	Khi cần quyết định của Business Owner, Legal, Accounting, Security, Architect hoặc QA.
QG-07	Biên giới bảo mật, riêng tư, pháp lý, kế toán	Nội dung phân biệt rõ điều gì là yêu cầu nghiệp vụ, điều gì là ràng buộc pháp lý hoặc kiểm soát bảo mật; phần vượt thẩm quyền được gắn “Verification required” hoặc tương đương.	Có nhắc đến lĩnh vực nhạy cảm nhưng chưa khóa ranh giới diễn giải.	Diễn giải luật, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc kiểm soát bảo mật như kết luận cuối cùng khi chưa có thẩm quyền xác nhận.	Khi yêu cầu có thể tác động dữ liệu cá nhân, chứng từ, hóa đơn, thanh toán, lưu trữ, truy cập hoặc an toàn thực phẩm.
QG-08	Phạm vi thay đổi	Mọi thay đổi được mô tả là thay đổi nội dung, không mạo nhận là baseline hay approval; tác động lan sang file khác phải được nhận diện.	Có thay đổi nhưng phạm vi tác động chưa được mô tả đầy đủ.	Thay đổi làm đổi nghĩa chuẩn, đổi ID canonical, đổi filename hoặc phá vỡ governance của corpus.	Khi thay đổi ảnh hưởng nhiều artifact, nhiều chapter, hoặc nhiều vai trò kiểm soát.
QG-09	Tính đóng gói của Nova Foods mô phỏng	Nova Foods luôn được ghi là mô phỏng giáo dục, dữ liệu tổng hợp, không phải chứng cứ vận hành thật.	Có nhắc Nova Foods nhưng chưa nhấn mạnh tính synthetic data only.	Gán cho Nova Foods tính chất thực tế, pháp lý hoặc vận hành như thể đã xác minh.	Khi người soạn muốn chuyển từ mô phỏng sang quy tắc production hoặc compliance thực.
QG-10	Sẵn sàng cho review cấp cao	Artifact đủ sạch để Senior BA tiếp tục review mà không phải tự đoán nguồn, vai trò hay nghĩa của yêu cầu.	Còn một số điểm cần chỉnh trước khi chuyển sang review sâu hơn.	Chưa đủ nền tảng để review vì thiếu nguồn, thiếu cấu trúc hoặc thiếu thẩm quyền.	Khi cần hội ý liên phòng ban hoặc gói vấn đề phải được chuyển sang vai trò cao hơn.

Quy tắc quyết định của cổng này là: nếu chỉ một tiêu chí Fail nhưng không chạm Stop thì có thể sửa nội dung trong phạm vi BA và review lại; nếu có bất kỳ tiêu chí Stop nào thì phải dừng ngay để tránh biến giả định thành yêu cầu; nếu có xung đột liên vai trò, liên miền thẩm quyền hoặc liên quan luật và kiểm soát nhạy cảm thì phải escalation (chuyển cấp) theo đúng owner có thẩm quyền, không được tự kết luận. Điều này giữ cho /03-templates/TMPL-REQ-002_REQUIREMENT_SPECIFICATION.md ở trạng thái kiểm soát chặt, không trộn lẫn review nghiệp vụ với phê duyệt, và không làm mờ ranh giới giữa tài liệu học liệu Nova Foods mô phỏng với quyết định vận hành thực tế.

5.1 Khung kiểm tra Senior BA cho biên bản yêu cầu trước baseline

Khung này dùng để rà soát bản hoàn chỉnh của /03-templates/TMPL-REQ-002_REQUIREMENT_SPECIFICATION.md trước khi đi tiếp sang bước kiểm tra chéo. “Completeness” (độ đầy đủ) là câu hỏi: mọi trường bắt buộc, mọi dòng dữ liệu, mọi payload, mọi quyết định và mọi liên kết truy vết đã có mặt chưa; nếu còn chỗ trống thì chưa được coi là sẵn sàng. “Consistency” (tính nhất quán) là câu hỏi: cùng một ID, cùng một thuật ngữ, cùng một trạng thái và cùng một logic có được dùng thống nhất giữa các section, bảng và phụ lục không; nếu một quy tắc bị diễn đạt hai kiểu khác nhau thì phải dừng để sửa. “Testability” (khả năng kiểm thử) là câu hỏi: requirement có quan sát được, đo được và có thể tạo test case hay không; nếu không thể chuyển thành tiêu chí kiểm thử thì requirement còn mơ hồ. “Traceability” (khả năng truy vết) là câu hỏi: mỗi yêu cầu, rủi ro, ngoại lệ, dữ liệu và quyết định có nối về nguồn xác minh hoặc nguồn mô phỏng Nova Foods hay không; nếu đứt chuỗi thì không được coi là đạt. Mọi đánh giá ở đây chỉ là đánh giá chất lượng học liệu mô phỏng, không phải phê duyệt baseline và không phải xác nhận vận hành thực tế.

Hạng mục kiểm tra	Tiêu chí Pass	Tiêu chí Fail	Tiêu chí Stop / Escalation	Bằng chứng tối thiểu phải nhìn thấy	Nguồn thẩm quyền áp dụng
Completeness (độ đầy đủ)	Tất cả mục bắt buộc của section đã có, không còn ô trống, không còn dòng thiếu, không còn phần phụ thuộc chưa gắn.	Thiếu trường, thiếu dòng, thiếu định danh, thiếu điều kiện, thiếu ngoại lệ hoặc thiếu trace link.	Dừng ngay nếu thiếu làm cho requirement không thể hiểu đúng hoặc không thể kiểm thử.	Bảng dữ liệu đầy đủ, danh sách ngoại lệ đầy đủ, ID ổn định, filename đúng.	Cấu trúc template của corpus, nguồn seed đã xác minh, artifact cha trong /03-templates/.
Consistency (tính nhất quán)	Thuật ngữ, trạng thái, ngày tháng, mã định danh và cách gọi vai trò đồng nhất giữa các phần.	Một khái niệm nhưng dùng nhiều tên, một ID nhưng gán nhiều nghĩa, một trạng thái nhưng mô tả trái nhau.	Escalation nếu mâu thuẫn chạm tới nguồn canonical, metadata quản trị hoặc thay đổi ý nghĩa nghiệp vụ.	So sánh chéo giữa section, bảng, heading, metadata, traceability links.	TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY.
Testability (khả năng kiểm thử)	Có tiêu chí kiểm thử quan sát được, dữ liệu đầu vào rõ, đầu ra hoặc kết quả chấp nhận được có thể xác minh.	Câu chữ chung chung như “phù hợp”, “đủ tốt”, “nhanh”, “thân thiện” nhưng không có ngưỡng.	Stop nếu requirement không thể chuyển thành test case, vì khi đó không thể xác minh chất lượng một cách khách quan.	Tiêu chí chấp nhận, ví dụ dữ liệu synthetic, điều kiện biên, trường hợp lỗi.	ISTQB CTFL cho ngôn ngữ kiểm thử; BABOK cho phân rã requirement thành tiêu chí rõ.
Traceability (khả năng truy vết)	Mỗi yêu cầu có nguồn, mỗi quyết định có lý do, mỗi ngoại lệ có nơi phát sinh và nơi xử lý.	Yêu cầu không gắn nguồn; nguồn có nhưng không biết dùng vào đâu; ngoại lệ không có đường đi ngược về nguồn.	Escalation nếu trace link chạm tới legal, accounting, security hoặc source canonical bị xung đột.	Ma trận truy vết, ID nguồn, filename nguồn, liên kết tới section gốc.	/00-research/00_SOURCE_MAP.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md.
Source authority (thẩm quyền nguồn)	Nguồn được phân loại đúng: normative, legal, good practice, internal plan, hay simulated example; dùng đúng ranh giới của nó.	Dùng nguồn tham khảo như thể là luật bắt buộc; dùng kế hoạch như thể là xác nhận vận hành.	Stop nếu một nguồn chưa được xác minh nhưng đang bị viết thành nghĩa vụ bắt buộc.	Nhãn nguồn, version, trạng thái, safe use boundary, access date.	Verified primary-source seed; luật Việt Nam chỉ dùng khi có Verification required hoặc legal-owner xác minh.
Ownership (trách nhiệm sở hữu)	Có người/role chịu trách nhiệm duy trì nội dung, nhưng vai trò đó không bị hiểu nhầm là quyền phê duyệt.	Ownership bị viết lẫn với approval, baseline, sign-off hoặc quyền vận hành.	Escalation khi tài liệu ngầm trao quyền cho người không có thẩm quyền pháp lý, kế toán, bảo mật hoặc business owner.	Metadata Owner, giới hạn thẩm quyền, lịch sử thay đổi.	Governance metadata của corpus; nguyên tắc trong 00_SOURCE_MAP và CHAPTER_MANIFEST.
Security / Privacy / Legal / Accounting boundaries (ranh giới bảo mật, dữ liệu cá nhân, pháp lý, kế toán)	Dữ liệu cá nhân, dữ liệu nhạy cảm, chứng từ, số liệu kế toán và nội dung pháp lý đều được đánh dấu ranh giới; mọi kết luận ngoài phạm vi đều ghi Verification required.	Viết yêu cầu như thể đã có xác nhận pháp lý/kế toán/bảo mật khi thực tế chưa có; trộn dữ liệu mô phỏng với dữ liệu thật.	Stop ngay nếu requirement đòi quyền truy cập production, quyết định pháp lý, quyết định kế toán, hay diễn giải luật như kết luận bắt buộc.	Nhãn synthetic data only, giới hạn truy cập, role boundary, ghi chú Verification required.	Luật Bảo vệ dữ liệu cá nhân, Nghị định 356/2025/NĐ-CP, Luật Kế toán, OWASP ASVS, OWASP API Security Top 10.
Change impact (tác động thay đổi)	Mỗi thay đổi có mô tả ảnh hưởng đến dữ liệu, quy trình, kiểm thử, traceability và nguồn liên quan.	Sửa một chỗ nhưng làm gãy ID, đổi nghĩa thuật ngữ, hoặc mất liên kết với section trước sau.	Escalation nếu thay đổi lan sang nhiều role hoặc nhiều artifact, hoặc chạm đến baseline giả định.	Change note, danh sách artifact bị ảnh hưởng, logic trước/sau thay đổi.	Quy tắc quản trị phiên bản v0.9.0, trạng thái IN_REVIEW, và chain trace của corpus Nova Foods mô phỏng.

Mẫu quyết định đọc nhanh cho Senior BA là: nếu thiếu sót chỉ là lỗi trình bày nhưng không làm sai nghĩa, ghi FAIL và yêu cầu sửa; nếu thiếu sót làm mất khả năng hiểu, kiểm thử, truy vết hoặc làm đụng ranh giới thẩm quyền thì ghi STOP và chuyển ESCALATION; nếu nội dung đủ, nhất quán, kiểm thử được, truy vết được, nguồn đúng thẩm quyền, ownership rõ, ranh giới bảo mật/pháp lý/kế toán được giữ, và tác động thay đổi đã được ghi nhận thì chỉ mới kết luận “qua chất lượng vòng rà soát”, không được viết thành “đã phê duyệt” hay “đã baseline”.

Ứng dụng bộ kiểm tra Senior BA lên ví dụ Nova Foods đã hoàn thành

Áp dụng cho ví dụ Nova Foods đã được điền đầy đủ ở phần trước của cùng tài liệu /03-templates/TMPL-REQ-002_REQUIREMENT_SPECIFICATION.md, với bối cảnh mô phỏng giáo dục và dữ liệu tổng hợp בלבד, tôi ghi nhận kết quả theo nguyên tắc: chỉ dựa trên nội dung đang có trong corpus, không suy diễn thêm nghiệp vụ thật, không coi việc kiểm tra là phê duyệt, và không dùng kết quả này để nói rằng đã baseline. Bảng dưới đây là ghi nhận rà soát chất lượng của Senior BA cho đúng mục đích “pre-baseline review”.

Hạng mục kiểm tra	Quan sát trên ví dụ Nova Foods đã hoàn thành	Chứng cứ và cầu nối suy luận	Kết quả	Ghi chú hành động
Tính đầy đủ	Các trường, hàng, payload, quyết định, ngoại lệ và liên kết truy vết trong ví dụ Nova Foods ở Tier 3 đã được điền bằng dữ liệu tổng hợp, không còn chỗ trống kiểu mẫu.	Vì mục tiêu của Tier 3 là “fully completed case”, nên khi không còn ô trống và mỗi mục có nội dung cụ thể thì có thể kết luận là đủ để đọc và rà soát.	PASS	Giữ nguyên cấu trúc; không thêm placeholder mới.
Tính nhất quán	Thuật ngữ Nova Foods, 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, và tiền tệ mô phỏng VND được dùng đồng bộ.	Khi cùng một định danh và bối cảnh xuất hiện nhất quán qua các phần, người đọc không bị lệch nghĩa giữa metadata, nội dung và traceability.	PASS	Không đổi tên viết tắt, không trộn lẫn ngữ cảnh thật và mô phỏng.
Tính kiểm thử được	Các yêu cầu, quyết định và ngoại lệ trong ví dụ đủ cụ thể để có thể chuyển thành test case mức nghiệp vụ hoặc kiểm thử chấp nhận.	Một yêu cầu chỉ kiểm thử được khi có đối tượng kiểm tra, điều kiện và kết quả mong đợi đủ rõ; ví dụ Nova Foods đã đáp ứng mức mô tả này bằng dữ liệu cụ thể thay vì câu chung chung.	PASS	Khi sang phần test design, phải tách riêng test basis và expected result.
Tính truy vết	Mỗi phần của ví dụ đã gắn với nguồn xác minh hoặc nhãn Verification required khi chưa đủ thẩm quyền.	Khi có thể lần ngược từ nội dung sang nguồn gốc hoặc nhãn xác minh, ta biết artefact không “rơi khỏi chuỗi chân lý” của corpus.	PASS	Không tự nâng nhãn xác minh thành xác nhận pháp lý hoặc vận hành.
Thẩm quyền nguồn	Nguồn nền đã dùng đúng biên: BABOK, ISO/IEC/IEEE 29148, ISTQB, OpenAPI, WCAG, OWASP, và các nguồn luật Việt Nam chỉ ở mức official source, không diễn giải quá mức.	Vì mỗi loại nguồn có biên sử dụng khác nhau, nên chỉ được kết luận trong phạm vi mà nguồn cho phép; ví dụ luật phải qua owner pháp lý/kế toán khi đi vào nghĩa vụ bắt buộc.	PASS có điều kiện	Gắn nhãn Verification required cho mọi điểm luật, thuế, kế toán chưa đối chiếu văn bản gốc hiện hành.
Ownership	Vai trò Owner của corpus được ghi rõ là duy trì quản trị, không phải phê duyệt nội dung hay quyết định vận hành.	Khi quyền hạn được viết tách bạch, người đọc hiểu rằng việc hoàn thành nội dung không tự động sinh quyền phê duyệt.	PASS	Không viết ngầm ý rằng Owner đã đồng ý hay đã xác nhận production.
Ranh giới bảo mật, riêng tư, pháp lý, kế toán	Ví dụ có nhắc các biên như dữ liệu cá nhân, kế toán, hóa đơn, an toàn thực phẩm, nhưng chưa vượt sang kết luận pháp lý hay kế toán bắt buộc.	Vì các chủ đề này thuộc thẩm quyền chuyên trách, chỉ mô tả biên và yêu cầu xác minh là an toàn; nếu biến thành nghĩa vụ bắt buộc mà chưa kiểm chứng thì phải dừng.	PASS với điểm cần giữ nhãn	Không biến tài liệu học liệu thành quy định tuân thủ thực tế.
Tác động thay đổi	Mọi thay đổi trong ví dụ có thể làm ảnh hưởng đến traceability, test basis và nguồn đối chiếu; vì vậy cần ghi change note nếu chỉnh sửa tiếp.	Nếu sửa một trường mà làm đổi nghĩa liên kết, người rà soát sẽ mất khả năng so sánh trước/sau; do đó tác động thay đổi đã được nhận diện đúng ở mức quản trị.	PASS	Mọi sửa sau này phải đi kèm mô tả ảnh hưởng và artefact bị tác động.

Kết luận rà soát cho micro-batch này là: ví dụ Nova Foods đã hoàn thành đạt mức đủ để rà soát chất lượng theo checklist Senior BA ở phạm vi pre-baseline, nhưng ghi nhận này chỉ là kết quả kiểm tra nội bộ của template, không phải phê duyệt, không phải baseline, và không thay thế xác nhận từ vai trò có thẩm quyền cho các miền pháp lý, kế toán, bảo mật hoặc vận hành.

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

6.1. Ma trận kiểm tra nhất quán liên tệp

Mục tiêu của kiểm tra liên tệp (cross-file check) là đối chiếu cùng một yêu cầu với các nguồn quản trị, nguồn định danh, quy tắc dữ liệu, tài liệu liên quan và nơi tiêu thụ đầu ra. Kết quả dưới đây chỉ là kiểm tra nhất quán nội bộ cho corpus Nova Foods mô phỏng, sử dụng dữ liệu tổng hợp; kết quả PASS không có nghĩa là nội dung đã được baseline, phê duyệt hoặc cho phép dùng trong production.

Phạm vi đối chiếu	Artifact canonical phải dùng	Cách kiểm tra và cầu nối lập luận	Kết quả kiểm tra
Manifest chương	/01-curriculum/CHAPTER_MANIFEST.md với ID CHAPTER_MANIFEST	Đối chiếu trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, bối cảnh vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND và phạm vi Nova Foods. Vì template hiện hành cũng dùng cùng bộ metadata, không có dấu hiệu lệch governance.	PASS trong phạm vi seed được cung cấp
Manifest template	/01-curriculum/TEMPLATE_MANIFEST.md với ID TEMPLATE_MANIFEST	Kiểm tra template /03-templates/TMPL-REQ-002_REQUIREMENT_SPECIFICATION.md có được diễn giải là template có kiểm soát, không phải phê duyệt yêu cầu. Quy tắc này phù hợp với giới hạn Owner và điều kiện dừng của manifest.	PASS
Registry định danh	/01-curriculum/TRACEABILITY_ID_REGISTRY.md với ID TRACEABILITY_ID_REGISTRY	Mọi liên kết phải giữ nguyên ID canonical, không tự đổi tên thành “registry truy vết” hoặc tạo ID thay thế. Khi một trường trong requirement tham chiếu rule, data hoặc test basis, phải truy nguyên về ID đã đăng ký; không dùng tên hiển thị làm định danh thay thế.	PASS về nguyên tắc định danh
Catalog quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md với ID CANONICAL_BUSINESS_RULES	Requirement chỉ được tham chiếu quy tắc đã có trong catalog hoặc ghi rõ là nội dung mô phỏng cần xem xét. Lý do: catalog là nguồn canonical cho rule, còn template không có thẩm quyền tự biến suy luận của BA thành quy định vận hành Nova Foods.	PASS về source boundary
Từ điển dữ liệu	/01-curriculum/CANONICAL_DATA_DICTIONARY.md với ID CANONICAL_DATA_DICTIONARY	Kiểm tra tên trường, ý nghĩa, kiểu dữ liệu logic và quan hệ dữ liệu trong requirement không mâu thuẫn với dictionary. Nếu yêu cầu thêm trường hoặc đổi nghĩa trường, đó là thay đổi nguồn dữ liệu canonical, không được sửa riêng trong template để che khuất khác biệt.	PASS về nguyên tắc kiểm soát
Kiến trúc curriculum	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md với ID 01_CURRICULUM_ARCHITECTURE	Đối chiếu chuỗi requirement → acceptance criteria → traceability → test basis. Vì kiến trúc cấm để testing tự suy diễn business rule, template phải cung cấp đủ căn cứ hoặc giữ nhãn cần xác minh, không tự bổ sung rule ở bước kiểm thử.	PASS
Source map	/00-research/00_SOURCE_MAP.md với ID 00_SOURCE_MAP	Kiểm tra mọi tuyên bố về tiêu chuẩn, pháp luật, kế toán, thuế, riêng tư, an toàn thực phẩm và truy xuất nguồn gốc giữ đúng phân loại nguồn. Nguồn tổng hợp chỉ hỗ trợ học liệu; không được viết thành trích dẫn điều khoản hoặc nghĩa vụ pháp lý nếu chưa xác minh văn bản gốc.	PASS với ranh giới xác minh bắt buộc
Chapter, template liên quan và downstream consumer	Các đường dẫn do CHAPTER_MANIFEST, TEMPLATE_MANIFEST và 01_CURRICULUM_ARCHITECTURE kiểm soát; không tự tạo tên tệp ngoài registry	Kiểm tra tính tương thích của đầu vào và đầu ra: requirement của /03-templates/TMPL-REQ-002_REQUIREMENT_SPECIFICATION.md phải cung cấp căn cứ cho acceptance criteria, traceability và test basis ở các artifact downstream. Không gọi PlantUML là BPMN, không để template ghi đè nguồn canonical, và không suy diễn cấu hình ERP thực tế từ ví dụ Nova Foods.	PASS ở mức hợp đồng giao diện; không tạo định danh ngoài seed

6.2. Quy tắc kết luận kiểm tra

Một dòng chỉ được ghi PASS khi tên tệp, Artifact ID, trạng thái, phiên bản, source boundary và thẩm quyền đều nhất quán với nguồn canonical. Nếu một artifact dùng ID khác, gọi bản sao là nguồn chính, biến IN_REVIEW thành APPROVED hoặc BASELINED, hoặc chuyển dữ liệu tổng hợp Nova Foods thành sự kiện thực tế, phải đánh dấu mâu thuẫn và không tiếp tục truyền kết quả sang downstream consumer. Cơ sở của quy tắc này là các manifest và registry đều quy định Owner chỉ duy trì quản trị; do đó việc hoàn tất kiểm tra không tạo approval, baseline, kết luận pháp lý, quyết định kế toán, xác nhận bảo mật hay quyền triển khai production.

6.3. Ràng buộc truy vết khi phát hiện khác biệt

Mọi khác biệt được phát hiện trong lần đối chiếu phải giữ đồng thời: Artifact ID của nguồn bị ảnh hưởng, đường dẫn tệp canonical, phiên bản v0.9.0, ngày kiểm tra 2026-08-07, trường hoặc liên kết bị lệch và artifact downstream có nguy cơ nhận dữ liệu sai. Không sửa im lặng nội dung đã ghi nhận; phải bảo toàn nhãn IN_REVIEW, dùng dữ liệu tổng hợp và chuyển khác biệt theo cơ chế kiểm soát thay đổi của corpus.

Khi khác biệt liên quan REQ-NF-AP-014-01, người lập biên bản phải ghi đầy đủ requirement: hệ thống phải chặn tạo hoặc phát hành thanh toán cho hóa đơn mua nguyên liệu khi đơn giá hoặc tổng giá trị hóa đơn khác dữ liệu đối chiếu được phê duyệt; hệ thống phải lưu lý do chặn, dữ liệu nguồn đối chiếu, người xử lý và quyết định ngoại lệ. Artifact downstream chỉ được nhận trạng thái thanh toán sau khi người có thẩm quyền xử lý chênh lệch theo cơ chế kiểm soát thay đổi.

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

Danh mục này là tập hợp đầy đủ các điểm chưa thể kết luận trong phạm vi TMPL-REQ-002 tại ngày 2026-08-07. “Vấn đề mở” là điểm thiếu quyết định hoặc đầu vào; “giả định dự án” là điều tạm dùng để minh họa luồng học liệu nhưng chưa phải quy tắc vận hành; “cần xác minh” là nội dung chỉ được kết luận bởi vai trò có thẩm quyền hoặc bằng nguồn chính thức phù hợp. Mọi ví dụ Nova Foods Trading & Manufacturing trong bảng là mô phỏng giáo dục, dùng dữ liệu tổng hợp, trạng thái chung vẫn là IN_REVIEW.

Loại	Nội dung chưa kết luận hoặc giả định	ID/tệp bị ảnh hưởng	Owner chịu trách nhiệm xử lý	Tác động nếu chưa xử lý	Hành động kế tiếp cụ thể
Vấn đề mở	Chưa có tham chiếu baseline hoặc approval cho requirement specification; vì vậy không thể gọi bất kỳ requirement, acceptance criterion hoặc quyết định nào trong template là đã được phê duyệt.	TMPL-REQ-002; /03-templates/TMPL-REQ-002_REQUIREMENT_SPECIFICATION.md; TEMPLATE_MANIFEST	Principal IT Business Analyst / Technical Curriculum Author duy trì hồ sơ; Business Owner hoặc vai trò được chỉ định mới có thể xác nhận nội dung nghiệp vụ.	Downstream consumer có thể hiểu sai tài liệu học liệu là đầu vào triển khai đã chấp thuận.	Giữ nhãn IN_REVIEW, ghi nhận yêu cầu review trong lịch sử thay đổi và chỉ bổ sung tham chiếu approval khi artifact kiểm soát ghi nhận rõ người có thẩm quyền, phạm vi và thời điểm.
Vấn đề mở	Chưa có quyết định nghiệp vụ có thẩm quyền về quy tắc ERP thực tế của Nova Foods, gồm chính sách giá, phê duyệt đơn hàng, hạn mức tín dụng, định mức tồn kho và xử lý ngoại lệ.	TMPL-REQ-002; CANONICAL_BUSINESS_RULES; CHAPTER_MANIFEST	Business Owner đối với quyết định nghiệp vụ; Principal IT Business Analyst / Technical Curriculum Author chỉ bảo toàn truy vết.	Không được chuyển ví dụ case study thành business rule bắt buộc, acceptance criterion production hoặc cấu hình ERP.	Duy trì mọi quy tắc Nova Foods trong template ở phạm vi minh họa tổng hợp; khi có nội dung nghiệp vụ thực, lập liên kết đến rule ID đã được ghi nhận trong CANONICAL_BUSINESS_RULES.
Giả định dự án	vi-VN, Asia/Ho_Chi_Minh và VND được dùng thống nhất cho dữ liệu minh họa, ngày giờ và giá trị tiền tệ trong case study. Giả định này xuất phát từ metadata chung của manifest và không xác nhận cấu hình ERP thực tế.	TMPL-REQ-002; CHAPTER_MANIFEST; TEMPLATE_MANIFEST; TRACEABILITY_ID_REGISTRY	Principal IT Business Analyst / Technical Curriculum Author	Nếu diễn giải là cấu hình thật, learner hoặc downstream consumer có thể áp dụng sai locale, múi giờ hoặc tiền tệ vào môi trường khác.	Gắn rõ “mô phỏng giáo dục, dữ liệu tổng hợp” cho mọi payload và ví dụ; Architect hoặc Business Owner xác nhận riêng nếu sau này có yêu cầu cấu hình thực.
Cần xác minh	Mọi yêu cầu có liên quan đến dữ liệu cá nhân phải được Legal Owner hoặc Compliance Owner xác minh theo Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP hiện hành; source seed chỉ xác nhận nguồn và hiệu lực được nêu, không thay thế diễn giải pháp lý.	TMPL-REQ-002; CANONICAL_DATA_DICTIONARY; SRC-READY-010	Legal Owner hoặc Compliance Owner	Không được mô tả yêu cầu về thu thập, hiển thị, lưu giữ, chia sẻ hoặc xóa dữ liệu là nghĩa vụ pháp lý đã xác nhận.	Đánh dấu từng requirement có dữ liệu cá nhân là Verification required; Legal Owner hoặc Compliance Owner đối chiếu nguồn chính thức và ghi kết luận vào artifact kiểm soát phù hợp.
Cần xác minh	Mọi yêu cầu về hạch toán, chứng từ, hóa đơn, thuế hoặc lưu trữ kế toán cần Accounting Owner và Legal Owner xác minh; Luật Kế toán và Nghị định 123/2020/NĐ-CP trong source seed không tự tạo quy tắc cấu hình.	TMPL-REQ-002; CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY	Accounting Owner; Legal Owner khi có diễn giải pháp luật	Acceptance criterion tài chính có thể bị hiểu nhầm là hướng dẫn hạch toán, hóa đơn hoặc tuân thủ thực tế.	Không đưa công thức, thời hạn, loại chứng từ hoặc bút toán mô phỏng thành điều kiện bắt buộc; chuyển nội dung cần dùng sang vòng xác minh của Accounting Owner và Legal Owner.
Cần xác minh	Mọi yêu cầu truy xuất nguồn gốc, thu hồi hoặc thông tin an toàn thực phẩm phải được domain owner và Legal Owner kiểm chứng. Việc source seed có Luật An toàn thực phẩm chỉ cung cấp bối cảnh nguồn, không chứng minh quy trình Nova Foods mô phỏng đáp ứng yêu cầu pháp lý.	TMPL-REQ-002; CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY	Food Safety Domain Owner; Legal Owner	Không thể kết luận mã lô, lịch sử truy vết hoặc luồng thu hồi minh họa là đầy đủ cho vận hành hay pháp lý.	Giữ các trường lô và truy vết ở vai trò dữ liệu tổng hợp phục vụ học; lập yêu cầu xác minh riêng khi chuyển sang đặc tả nghiệp vụ hoặc thiết kế vận hành.
Cần xác minh	Mọi yêu cầu xác thực, phân quyền, nhật ký, API hoặc bảo vệ dữ liệu cần Security Owner và Architect xác minh. OWASP ASVS 5.0.0 và OWASP API Security Top 10 2023 chỉ là chuẩn thực hành và nguồn nhận thức rủi ro, không phải luật Việt Nam hay approval bảo mật.	TMPL-REQ-002; CANONICAL_DATA_DICTIONARY; TRACEABILITY_ID_REGISTRY	Security Owner; Architect	Không được suy diễn role matrix, cơ chế token, lưu log, mã hóa hoặc API contract từ template thành thiết kế bảo mật đã xác nhận.	Gắn nhãn Verification required cho mọi security requirement; Security Owner xác định mục tiêu kiểm soát, Architect xác định khả thi kỹ thuật, rồi mới liên kết đến requirement hoặc test basis có ID hợp lệ.
Giả định dự án	Thuật ngữ BA, requirement, traceability và quality gate được sử dụng theo phạm vi giáo dục của corpus; BABOK Guide, ISO/IEC/IEEE 29148 và ISTQB CTFL được dùng làm nguồn thuật ngữ hoặc định hướng, không được gán số trang, điều khoản hoặc trích dẫn không có văn bản được cấp phép.	TMPL-REQ-002; 00_SOURCE_MAP; 01_CURRICULUM_ARCHITECTURE	Principal IT Business Analyst / Technical Curriculum Author	Sai nguồn hoặc trích dẫn vượt safe use boundary làm suy yếu khả năng kiểm tra và độ tin cậy của học liệu.	Chỉ giữ tên nguồn, phiên bản và URL đã xác minh trong source seed; mọi diễn giải chi tiết cần đối chiếu văn bản chính thức hoặc văn bản được cấp phép trước khi ghi là yêu cầu chuẩn.

Mỗi dòng trên chưa được đóng chỉ vì đã có Owner hoặc hành động kế tiếp. Điều kiện đóng là bằng chứng được ghi trong artifact canonical tương ứng, vẫn truy được Artifact ID, tệp kiểm soát, phiên bản và ngày cập nhật; đồng thời kết luận không vượt thẩm quyền của Principal IT Business Analyst / Technical Curriculum Author. Trước điều kiện đó, TMPL-REQ-002 chỉ là template bốn tầng đang xem xét, không phải quyết định nghiệp vụ, pháp lý, kế toán, bảo mật hoặc triển khai production.

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

Bàn giao (handoff) là việc chuyển một gói thông tin có thể truy vết cho người hoặc artifact nhận để họ tiếp tục kiểm tra, sử dụng làm đầu vào, hoặc đánh giá tác động; bàn giao không phải là phê duyệt, baseline hay cho phép triển khai. Gói bàn giao của TMPL-REQ-002 phải giữ nguyên 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, đơn vị tiền tệ mô phỏng VND, và nhãn Nova Foods Trading & Manufacturing là case study mô phỏng với dữ liệu tổng hợp. Lý do là các artifact nguồn đều xác định IN_REVIEW không tương đương APPROVED hoặc BASELINED; vì vậy người nhận chỉ được dùng nội dung như đầu vào review có kiểm soát, không suy diễn thành quyết định ERP, pháp lý, kế toán, bảo mật hay vận hành thực tế.

Thành phần bàn giao bắt buộc	Giá trị hoặc cách xử lý kiểm soát	Mục đích truy vết
Artifact được bàn giao	/03-templates/TMPL-REQ-002_REQUIREMENT_SPECIFICATION.md với Artifact ID TMPL-REQ-002	Xác định chính xác template được nhận, tránh thay thế bằng bản sao hoặc tên rút gọn.
Trạng thái và phiên bản	IN_REVIEW, v0.9.0, ngày 2026-08-07	Ngăn người nhận diễn giải nhầm nội dung review thành bản đã ổn định.
Nguồn quản trị liên kết	CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, 00_SOURCE_MAP, 01_CURRICULUM_ARCHITECTURE	Cho phép kiểm tra lại ID, phạm vi, quy tắc canonical, dữ liệu logic và nguồn trước khi tái sử dụng nội dung.
Phạm vi sử dụng	Học liệu bốn tầng cho Nova Foods mô phỏng; chỉ dùng dữ liệu tổng hợp	Bảo toàn ranh giới giữa ví dụ đào tạo và yêu cầu của doanh nghiệp thật.
Điểm chưa được chuyển giao như kết luận	Không có baseline reference, approval reference, legal sign-off, accounting decision, security approval, architecture decision hoặc production authorization	Bảo toàn thẩm quyền của Business Owner, Legal Owner, Accounting Owner, Security, Architect, QA và vai trò phê duyệt được chỉ định.

Quy tắc lan truyền thay đổi (change propagation) áp dụng khi một thay đổi làm thay đổi ý nghĩa, định danh, nguồn, điều kiện kiểm tra hoặc ranh giới sử dụng của TMPL-REQ-002. Người phát hiện phải ghi nhận thay đổi tại artifact nguồn có thẩm quyền trước, sau đó liên kết thay đổi đến các artifact phụ thuộc; không được sửa nội dung đích để “khớp” mà không giữ được nguồn thay đổi. Ví dụ, nếu TRACEABILITY_ID_REGISTRY thay đổi quy ước ID, TMPL-REQ-002 chỉ cập nhật cách tham chiếu sau khi registry được cập nhật có kiểm soát; template không tự tạo ID thay thế. Nếu CANONICAL_BUSINESS_RULES hoặc CANONICAL_DATA_DICTIONARY thay đổi nội dung canonical, phần yêu cầu, dữ liệu, acceptance criteria và traceability liên quan trong template phải được rà soát tác động, nhưng Principal IT Business Analyst / Technical Curriculum Author không được tự xác nhận tính đúng đắn nghiệp vụ hoặc vận hành của thay đổi đó.

Sự kiện thay đổi	Artifact nguồn quyết định hoặc ghi nhận	Hành động lan truyền đối với TMPL-REQ-002	Ranh giới thẩm quyền
Đổi ID, đường dẫn hoặc quy tắc đặt tên	TRACEABILITY_ID_REGISTRY hoặc manifest áp dụng	Cập nhật liên kết đúng chuỗi canonical; kiểm tra mọi tham chiếu trong template	Owner duy trì liên kết, không tự cấp ID ngoài registry.
Đổi cấu trúc template hoặc vị trí template trong corpus	TEMPLATE_MANIFEST và CHAPTER_MANIFEST khi có dependency chapter	Rà soát tiêu đề, phạm vi, liên kết học tập và người tiêu thụ downstream	Owner không tự xác nhận curriculum đã được phê duyệt.
Đổi quy tắc nghiệp vụ hoặc thuật ngữ nghiệp vụ	CANONICAL_BUSINESS_RULES	Đánh dấu các requirement, exception, acceptance criteria và traceability bị ảnh hưởng để review lại	Business Owner và vai trò chuyên môn phù hợp xác nhận ý nghĩa nghiệp vụ; BA chỉ điều phối và truy vết.
Đổi tên trường, kiểu dữ liệu, định nghĩa dữ liệu hoặc phân loại dữ liệu	CANONICAL_DATA_DICTIONARY	Rà soát field, payload, validation và ví dụ Nova Foods tổng hợp liên quan	Data, Security, Architect hoặc owner được chỉ định xác nhận phần thuộc chuyên môn của họ.
Đổi nguồn, trạng thái nguồn hoặc safe use boundary	00_SOURCE_MAP	Gỡ mọi diễn đạt vượt giới hạn nguồn; giữ nhãn “Verification required” khi chưa có xác minh phù hợp	Không tự suy diễn điều khoản pháp lý, chuẩn kỹ thuật hoặc nghĩa vụ tuân thủ.
Phát hiện tác động đến kiểm thử hoặc consumer downstream	Artifact nhận phải ghi nhận liên kết ngược về TMPL-REQ-002 và artifact canonical liên quan	Cập nhật test basis hoặc tài liệu nhận sau khi nguồn thay đổi được truy vết	QA xác nhận chiến lược và kết quả kiểm thử; template không tuyên bố đã kiểm thử đạt.

Mỗi lần bàn giao hoặc lan truyền thay đổi phải bảo toàn tối thiểu chuỗi bằng chứng gồm: Artifact ID, đường dẫn tệp kiểm soát, trạng thái, phiên bản, ngày theo Asia/Ho_Chi_Minh, nguồn của thay đổi, phần bị ảnh hưởng, người chịu trách nhiệm xử lý và liên kết trở về artifact canonical. Việc người nhận đã tiếp nhận gói chỉ xác nhận khả năng tiếp tục review, không xác nhận họ đồng ý nội dung. Khi thay đổi có thể ảnh hưởng pháp luật về dữ liệu cá nhân, kế toán, hóa đơn chứng từ, an toàn thực phẩm, bảo mật, kiến trúc hoặc vận hành, việc lan truyền phải dừng ở trạng thái ghi nhận tác động và chuyển đến owner có thẩm quyền; không được biến nhãn IN_REVIEW thành kết luận tuân thủ hoặc quyết định production.