Tmpl Ux 001 Ux Requirements Specification

Trường kiểm soát	Giá trị
Artifact ID	`TMPL-UX-001`
Tên tệp được kiểm soát	`/03-templates/TMPL-UX-001_UX_REQUIREMENTS_SPECIFICATION.md`
Tiêu đề artifact	`Tmpl Ux 001 Ux Requirements Specification`
Status	`IN_REVIEW`
Version	`v0.9.0`
Owner	Principal IT Business Analyst / Technical Curriculum Author
Last updated date	`2026-08-07`
Múi giờ quản trị	`Asia/Ho_Chi_Minh`
Locale	`vi-VN`; bối cảnh Việt Nam; tiền tệ mô phỏng `VND`
Phân loại artifact	Controlled four-tier UX requirements specification template
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục
Dữ liệu	Chỉ dữ liệu tổng hợp; không chứa dữ liệu cá nhân, khách hàng, nhân sự, tài chính, cấu hình ERP, giao dịch, thông tin vận hành hoặc bí mật thương mại thực
Baseline reference	Chưa có baseline reference tại `v0.9.0`
Approval reference	Chưa có approval reference tại `v0.9.0`

1. Tier 1 ? Metadata, Purpose, and Governance

IN_REVIEW nghĩa là artifact đang được xem xét có kiểm soát. Trạng thái này cho phép ghi nhận và truy vết thay đổi, nhưng không có nghĩa APPROVED, BASELINED, production-ready, compliant, hay được người dùng chấp thuận. Bằng chứng quản trị: TMPL-UX-001 đang mang Version v0.9.0; cả TEMPLATE_MANIFEST, CHAPTER_MANIFEST và TRACEABILITY_ID_REGISTRY cùng trạng thái IN_REVIEW tại ngày 2026-08-07.

Owner duy trì định danh, đường dẫn, metadata, version và lịch sử thay đổi của artifact. Owner không được tự tạo baseline, ghi nhận approval, xác nhận yêu cầu UX là đúng cho Nova Foods thực, diễn giải nghĩa vụ pháp lý, hay cho phép triển khai production. Khi nội dung cần quyết định nghiệp vụ, pháp lý, kế toán, bảo mật, kiến trúc hoặc kiểm thử, quyết định đó phải thuộc vai trò có thẩm quyền; metadata Owner không thay thế thẩm quyền này.

Version	Ngày	Thay đổi	Trạng thái kiểm soát
`v0.9.0`	`2026-08-07`	Khởi tạo artifact `TMPL-UX-001`; thiết lập H1, định danh tệp, metadata quản trị, lịch sử thay đổi khởi tạo và ranh giới dữ liệu mô phỏng.	`IN_REVIEW`; chưa baseline; chưa có approval reference

Ranh giới Nova Foods là bắt buộc: mọi tên người, vai trò, đơn vị, mã hồ sơ, sản phẩm, số tiền VND, ngày tháng, hành vi người dùng, màn hình, luồng ERP và bằng chứng trong template chỉ phục vụ học liệu. Dữ liệu tổng hợp có thể minh họa cách phân tích, nhưng không chứng minh Nova Foods là doanh nghiệp có thật, đang dùng ERP cụ thể, đã chấp nhận thiết kế UX, hay tuân thủ pháp luật hoặc tiêu chuẩn nào.

Không sửa im lặng TMPL-UX-001. Mọi thay đổi sau v0.9.0 phải giữ Artifact ID và tên tệp canonical, tăng version phù hợp, thêm dòng lịch sử thay đổi, cập nhật ngày theo Asia/Ho_Chi_Minh, và bảo toàn nhãn dữ liệu mô phỏng. 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 tại /03-templates/TMPL-UX-001_UX_REQUIREMENTS_SPECIFICATION.md.

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

Template UX Requirements Specification ghi nhận yêu cầu trải nghiệm người dùng, gọi tắt là UX (User Experience), theo cấu trúc kiểm soát để đội dự án hiểu người dùng nào thực hiện việc gì, tại điểm chạm nào, với thông tin, phản hồi, lỗi và tiêu chí tiếp cận nào. Template biến nhu cầu nghiệp vụ thành đầu vào có thể kiểm tra cho thiết kế, phát triển và kiểm thử; không tự biến nhu cầu đó thành quyết định triển khai hoặc phê duyệt Nova Foods.

Nội dung	Quy định áp dụng
Mục đích	Chuẩn hóa việc mô tả người dùng, mục tiêu tác vụ, luồng thao tác, trạng thái giao diện, nội dung hiển thị, xử lý lỗi, khả năng tiếp cận và acceptance criteria (tiêu chí chấp nhận).
Dùng khi	Có thay đổi màn hình ERP, biểu mẫu, dashboard, luồng phê duyệt, thông báo, tra cứu, thao tác di động hoặc API ảnh hưởng trực tiếp cách người dùng thực hiện tác vụ.
Không dùng khi	Chỉ cần quyết định quy tắc nghiệp vụ không có tác động giao diện; chỉ cần định nghĩa trường dữ liệu; chỉ cần đặc tả API; hoặc cần kết luận pháp lý, kế toán, thuế, an toàn thực phẩm, bảo mật hay kiến trúc production. Các việc này phải dùng artifact và owner chuyên môn tương ứng.
Owner	`Principal IT Business Analyst / Technical Curriculum Author` duy trì cấu trúc, phiên bản, traceability và ranh giới sử dụng template. Owner không xác nhận UX là đúng cho vận hành thực, không phê duyệt release và không cấp quyền production.
Consumers	Business Analyst dùng để phân tích; UX/UI Designer dùng để thiết kế; Developer dùng để xây dựng; QA dùng làm test basis; Product Owner hoặc Business Owner dùng để review phạm vi nghiệp vụ. Việc nhận tài liệu để review không tạo approval.
Điều kiện đầu vào	Phải có vấn đề nghiệp vụ hoặc requirement đã định danh, vai trò người dùng, phạm vi quy trình, quy tắc nghiệp vụ liên quan, dữ liệu hoặc giả định dữ liệu, và nguồn truy vết. Nếu thiếu, ghi rõ giả định mô phỏng hoặc chuyển vấn đề về artifact nguồn.
Đầu ra hạ nguồn	UX/UI design, backlog refinement, user story, acceptance criteria, test scenario, test case, accessibility review, API hoặc data requirement liên quan. Đầu ra hạ nguồn phải giữ liên kết ngược về requirement UX; không sao chép rồi sửa mất nguồn gốc.

Nguyên tắc dùng. Dùng template khi câu hỏi cần trả lời là: “Người dùng nào hoàn thành tác vụ nào, trong bối cảnh nào, hệ thống phải phản hồi ra sao, và QA kiểm tra bằng chứng nào?” Ví dụ mô phỏng Nova Foods: nhân viên Kho cần xác nhận chênh lệch số lượng khi nhận hàng. UX requirement phải nêu vai trò, điều kiện kích hoạt, dữ liệu hiển thị, hành động cho phép, lỗi nhập liệu, trạng thái thành công và tiêu chí kiểm tra. Không được tự suy ra ngưỡng chênh lệch, quyền phê duyệt hay nghĩa vụ pháp lý nếu chưa có nguồn canonical và owner có thẩm quyền.

Ranh giới Nova Foods. Nova Foods Trading & Manufacturing là case study giáo dục mô phỏng. Mọi tên người dùng, đơn hàng, sản phẩm, số tiền VND, dữ liệu cá nhân, quy trình ERP và tình huống lỗi trong template chỉ là dữ liệu tổng hợp. Nội dung không chứng minh hệ thống Nova Foods tồn tại, không xác nhận tuân thủ, không phải hướng dẫn vận hành production và không thay thế xác nhận của Business Owner, Legal Owner, Accounting Owner, Security Owner, Architect hoặc QA.

Quyết định hoặc xung đột	Thẩm quyền quyết định	Hành động escalation
Mục tiêu tác vụ, ưu tiên nghiệp vụ, ngoại lệ vận hành	Business Owner hoặc Product Owner có thẩm quyền được ghi nhận	Đóng gói câu hỏi, tác động UX, lựa chọn và traceability; không tự chọn thay.
Quy tắc thuế, kế toán, hóa đơn hoặc lưu trữ chứng từ	Accounting Owner và Legal Owner	Giữ nhãn `Verification required`; không diễn đạt thành nghĩa vụ bắt buộc.
Dữ liệu cá nhân, quyền truy cập, bảo mật hoặc hiển thị dữ liệu nhạy cảm	Security Owner, Legal/Compliance Owner	Dừng chi tiết giải pháp khi chưa có quyết định; chỉ ghi rủi ro và câu hỏi cần xác minh.
Khả năng kỹ thuật, tích hợp, hiệu năng hoặc kiến trúc	Solution Architect hoặc Technical Architect	Không cam kết cơ chế kỹ thuật trong UX requirement khi chưa được xác nhận.
Tiêu chí kiểm thử và mức độ bằng chứng	QA Owner	Liên kết requirement với test basis; không tự tuyên bố đã kiểm thử hoặc đạt chất lượng.

Escalation xảy ra khi requirement mâu thuẫn nguồn canonical, thiếu owner quyết định, tác động nhiều vai trò thẩm quyền, hoặc có thể bị hiểu là cam kết pháp lý hay vận hành thực. Owner template phải giữ nguyên vấn đề, bằng chứng, giả định và liên kết truy vết; không xóa mâu thuẫn bằng cách tạo quy tắc Nova Foods mới.

Ánh xạ Manifest, Định danh Canonical, Nguồn và Nghĩa vụ Thay đổi

Template này có định danh canonical TMPL-UX-001; tệp kiểm soát là /03-templates/TMPL-UX-001_UX_REQUIREMENTS_SPECIFICATION.md. TMPL nghĩa là template, mẫu tài liệu có cấu trúc kiểm soát; UX nghĩa là User Experience, trải nghiệm người dùng; 001 phân biệt mẫu này với template UX khác. Không đổi, dịch, rút gọn hoặc tái sử dụng ID này cho tệp khác. Bằng chứng: quy ước manifest yêu cầu ID template, đường dẫn tệp và dependency được giữ nguyên để traceability, tức khả năng truy ngược từ nội dung đến nguồn và artifact liên quan.

Hạng mục ánh xạ	Giá trị canonical	Quy tắc áp dụng
Manifest chủ quản	`TEMPLATE_MANIFEST`	`/01-curriculum/TEMPLATE_MANIFEST.md` là nguồn danh mục kiểm soát cho template dự kiến.
Định danh template	`TMPL-UX-001`	Dùng nguyên chuỗi trong liên kết, bảng traceability, lịch sử thay đổi và QA.
Tệp template	`/03-templates/TMPL-UX-001_UX_REQUIREMENTS_SPECIFICATION.md`	Bản sao, bản xuất PDF hoặc tên tệp biến thể không thay thế tệp kiểm soát.
Manifest chapter	`CHAPTER_MANIFEST`	`/01-curriculum/CHAPTER_MANIFEST.md` kiểm soát danh mục 26 handbook chapter; chỉ liên kết chapter đã đăng ký tại đây.
Registry ID	`TRACEABILITY_ID_REGISTRY`	`/01-curriculum/TRACEABILITY_ID_REGISTRY.md` kiểm soát dạng, phạm vi và việc dùng ID truy vết.
Quy tắc nghiệp vụ	`CANONICAL_BUSINESS_RULES`	`/01-curriculum/CANONICAL_BUSINESS_RULES.md` là điểm tham chiếu cho business rule canonical; template không tự tạo rule canonical.
Dữ liệu logic	`CANONICAL_DATA_DICTIONARY`	`/01-curriculum/CANONICAL_DATA_DICTIONARY.md` là điểm tham chiếu cho tên và nghĩa dữ liệu logic; template không tự xác nhận schema triển khai.
Nguồn nghiên cứu	`00_SOURCE_MAP`	`/00-research/00_SOURCE_MAP.md` phân loại nguồn, URL chính thức và giới hạn dùng nguồn.

Liên kết chapter phải nêu ID chapter đúng nguyên dạng từ CHAPTER_MANIFEST, mục tiêu học tập liên quan và lý do liên kết. Không suy diễn số chapter, tên chapter hoặc dependency khi manifest chưa đăng ký rõ. Lý do: chapter manifest là nguồn chân lý cấu trúc; tự đặt ID tạo hai nguồn chân lý và làm đứt kiểm tra liên tệp.

Nhóm nguồn	Nguồn đã xác minh	Vai trò hợp lệ trong `TMPL-UX-001`	Giới hạn
BA và yêu cầu	BABOK Guide Version 3; ISO/IEC/IEEE 29148:2018	Thuật ngữ BA, cấu trúc và chất lượng yêu cầu	Không bịa số trang hoặc điều khoản từ văn bản có thể cần giấy phép.
UX, mô hình hóa, accessibility	OMG BPMN 2.0.2; OMG UML 2.5.1; WCAG 2.2	Phân biệt ký pháp BPMN/UML; yêu cầu accessibility có căn cứ	Không gọi sơ đồ activity PlantUML là BPMN; claim tiêu chí WCAG phải khớp nguồn.
API, test, security	OAS 3.1.1; ISTQB CTFL v4.0.1; OWASP ASVS 5.0.0; OWASP API Security Top 10 2023	Mô tả API, test basis, kiểm tra security	OWASP là chuẩn ngành, không phải luật Việt Nam.
Pháp lý Việt Nam	Luật 91/2025/QH15; Nghị định 356/2025/NĐ-CP; Luật 88/2015/QH13; Nghị định 123/2020/NĐ-CP; Luật 55/2010/QH12	Bối cảnh cần kiểm chứng privacy, kế toán, hóa đơn, an toàn thực phẩm	Mọi requirement suy ra phải gắn `Verification required` và chuyển Legal Owner, Accounting Owner hoặc domain owner xác nhận.

Mọi thay đổi làm ảnh hưởng TMPL-UX-001, ID truy vết, liên kết chapter, nguồn, rule hoặc dữ liệu phải ghi change record: ngày theo Asia/Ho_Chi_Minh, phạm vi thay đổi, artifact bị ảnh hưởng, lý do, bằng chứng và trạng thái kiểm tra liên tệp. Không sửa im lặng. IN_REVIEW và v0.9.0 không phải baseline, approval, xác nhận tuân thủ hoặc quyền dùng production. Nova Foods Trading & Manufacturing là case học tập mô phỏng; mọi tên, quy trình, ID và dữ liệu trong template chỉ là dữ liệu tổng hợp.

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

Dùng Tier 2 để tạo bản đặc tả UX mới. Thay mọi chuỗi <...> bằng thông tin cụ thể trước khi chuyển sang Tier 3. Không dùng placeholder chung như <nội dung>. Nova Foods Trading & Manufacturing chỉ là case mô phỏng giáo dục; chỉ ghi dữ liệu tổng hợp.

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

Trường	Giá trị điền	Hướng dẫn điền và kiểm tra
Artifact ID	`<ID artifact theo registry, ví dụ TMPL-UX-001>`	Giữ đúng ID đã đăng ký trong `/01-curriculum/TRACEABILITY_ID_REGISTRY.md`; không tự tạo biến thể.
Tên tệp	`<đường dẫn canonical, ví dụ /03-templates/TMPL-UX-001_UX_REQUIREMENTS_SPECIFICATION.md>`	Dùng đường dẫn corpus đã được kiểm soát.
Tiêu đề	`<tên chức năng hoặc phạm vi UX>`	Nêu đối tượng và mục đích, không dùng tên dự án mơ hồ.
Status	`<DRAFT hoặc IN_REVIEW hoặc BASELINED hoặc RETIRED>`	Chỉ chọn một giá trị. Không ghi `BASELINED` khi chưa có baseline reference.
Version	`<vX.Y.Z>`	Tăng version theo quy tắc kiểm soát thay đổi của corpus.
Ngày cập nhật	`<YYYY-MM-DD>`	Dùng ngày hợp lệ theo `Asia/Ho_Chi_Minh`.
Owner	`<vai trò hoặc tên vai trò chịu trách nhiệm duy trì>`	Owner duy trì tài liệu, không tự tạo approval nghiệp vụ, pháp lý, kế toán hoặc production.
Case study	`<tên case study hoặc Không áp dụng>`	Nếu dùng Nova Foods, ghi `Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp`.
Locale và tiền tệ	`<vi-VN; Asia/Ho_Chi_Minh; VND hoặc phạm vi khác>`	Nêu locale, múi giờ và tiền tệ áp dụng cho màn hình, ngày giờ, số lượng, tiền.
Phạm vi dữ liệu	`<Synthetic only hoặc phân loại dữ liệu được phép>`	Không ghi bí mật, dữ liệu cá nhân thật, token, mật khẩu, khóa API hoặc dữ liệu production.

2.2. Mục tiêu UX và phạm vi

Trường	Giá trị điền	Hướng dẫn điền và kiểm tra
Vấn đề người dùng	`<mô tả trở ngại hiện tại, người bị ảnh hưởng, thời điểm xảy ra>`	Nêu quan sát hoặc đầu vào nguồn. Không suy diễn nhu cầu thành fact khi chưa có căn cứ.
Mục tiêu UX	`<kết quả người dùng hoàn thành được>`	UX là trải nghiệm người dùng. Viết kết quả đo được, không viết giải pháp giao diện trước.
Giá trị nghiệp vụ	`<lợi ích nghiệp vụ kỳ vọng>`	Gắn mục tiêu UX với kết quả nghiệp vụ; ghi rõ đây là giả định nếu chưa được Business Owner xác nhận.
Persona hoặc vai trò	`<vai trò người dùng chính>`	Ghi vai trò, quyền hạn, bối cảnh làm việc và mức hiểu biết hệ thống. Không dùng tên người thật.
Phạm vi bao gồm	`<danh sách khả năng thuộc phạm vi>`	Mỗi dòng là một khả năng kiểm chứng được.
Ngoài phạm vi	`<danh sách khả năng không thuộc phạm vi>`	Nêu ranh giới để tránh mở rộng phạm vi ngầm.
Giả định	`<giả định và điều kiện còn đúng>`	Mỗi giả định phải nêu tác động nếu sai.
Ràng buộc	`<ràng buộc thời gian, nền tảng, quy trình, pháp lý hoặc kỹ thuật>`	Nội dung pháp lý, kế toán, thuế, an toàn thực phẩm hoặc privacy phải gắn `Verification required` nếu chưa có xác nhận vai trò có thẩm quyền.

2.3. Bối cảnh người dùng và luồng nhiệm vụ

Trường	Giá trị điền	Hướng dẫn điền và kiểm tra
Trigger	`<sự kiện bắt đầu tác vụ>`	Nêu sự kiện, nguồn khởi phát và điều kiện trước khi người dùng thao tác.
Tiền điều kiện	`<điều kiện phải đúng trước tác vụ>`	Bao gồm đăng nhập, quyền, dữ liệu tồn tại hoặc trạng thái nghiệp vụ cần thiết.
Tác vụ chính	`<động từ + đối tượng + kết quả mong muốn>`	Ví dụ cấu trúc: `Tạo <đối tượng> để <mục đích>`. Không dùng động từ không kiểm chứng như “xử lý tốt”.
Luồng thành công	`<bước 1>; <bước 2>; <bước 3>`	Mỗi bước nêu actor, hành động, phản hồi hệ thống và trạng thái kết quả.
Kết quả thành công	`<trạng thái dữ liệu và thông báo sau hoàn tất>`	Nêu dữ liệu nào được tạo, đổi hoặc giữ nguyên.
Tần suất	`<số lần/ngày, tuần, tháng hoặc theo sự kiện>`	Dùng dữ liệu tổng hợp hoặc gắn `Project assumption`.
Thiết bị và môi trường	`<desktop, tablet, mobile, kho, văn phòng hoặc môi trường khác>`	Nêu giới hạn kết nối, kích thước màn hình, thiết bị quét hoặc điều kiện vận hành nếu có.

2.4. Yêu cầu UX chi tiết

UX Requirement ID	Yêu cầu	Người dùng/actor	Trigger	Tiền điều kiện	Luồng chính	Kết quả mong đợi	Priority	Acceptance criteria	Hướng dẫn kiểm tra
`<UXR-<mã duy nhất>>`	`<hệ thống hoặc giao diện phải cho phép/hiển thị/cảnh báo gì>`	`<vai trò>`	`<sự kiện>`	`<điều kiện>`	`<các bước người dùng và phản hồi hệ thống>`	`<kết quả quan sát được>`	`<Must hoặc Should hoặc Could hoặc Won't>`	`<Given điều kiện; When hành động; Then kết quả>`	ID không trùng. Yêu cầu chỉ chứa một hành vi chính. Acceptance criteria phải kiểm thử được.
`<UXR-<mã duy nhất>>`	`<yêu cầu UX thứ hai>`	`<vai trò>`	`<sự kiện>`	`<điều kiện>`	`<các bước>`	`<kết quả>`	`<Must hoặc Should hoặc Could hoặc Won't>`	`<Given; When; Then>`	Không dùng “thân thiện”, “nhanh”, “dễ dùng” nếu không có tiêu chí quan sát hoặc đo lường.
`<UXR-<mã duy nhất>>`	`<yêu cầu UX thứ ba>`	`<vai trò>`	`<sự kiện>`	`<điều kiện>`	`<các bước>`	`<kết quả>`	`<Must hoặc Should hoặc Could hoặc Won't>`	`<Given; When; Then>`	Nếu phụ thuộc rule, data field hoặc API, nêu ID canonical tại yêu cầu khi ID đã tồn tại.

2.5. Nội dung màn hình và tương tác

Screen ID	Tên màn hình	Mục đích	Actor được phép	Thành phần giao diện	Hành động người dùng	Phản hồi hệ thống	Trạng thái rỗng, tải, lỗi	Hướng dẫn điền
`<SCR-<mã duy nhất>>`	`<tên màn hình>`	`<nhiệm vụ người dùng hoàn thành tại đây>`	`<vai trò>`	`<trường, bảng, nút, thông báo, bộ lọc>`	`<thêm, sửa, tìm, chọn, gửi hoặc hành động khác>`	`<xác nhận, tính toán, điều hướng, cảnh báo>`	`<nội dung từng trạng thái>`	Mỗi thành phần phải hỗ trợ mục đích màn hình. Không mô tả màu sắc là thay thế duy nhất cho trạng thái hoặc lỗi.
`<SCR-<mã duy nhất>>`	`<tên màn hình>`	`<mục đích>`	`<vai trò>`	`<thành phần>`	`<hành động>`	`<phản hồi>`	`<trạng thái>`	Nếu màn hình không áp dụng, ghi `<Không áp dụng — lý do cụ thể>`.

2.6. Trường dữ liệu giao diện

Field ID	Nhãn hiển thị	Mục đích	Kiểu dữ liệu	Bắt buộc	Nguồn dữ liệu	Quy tắc nhập và hiển thị	Giá trị mặc định	Thông báo lỗi	Quyền xem/sửa	Hướng dẫn điền
`<FLD-<mã duy nhất>>`	`<nhãn tiếng Việt>`	`<người dùng dùng trường để làm gì>`	`<text, number, date, datetime, currency, dropdown, checkbox hoặc loại cụ thể>`	`<Có hoặc Không>`	`<người dùng nhập, hệ thống tính, API hoặc data entity canonical>`	`<độ dài, định dạng, miền giá trị, đơn vị, locale>`	`<giá trị hoặc Không có>`	`<điều kiện lỗi và thông báo hành động được>`	`<vai trò xem; vai trò sửa>`	Không ghi dữ liệu thật. Tiền dùng `VND` khi phạm vi áp dụng.
`<FLD-<mã duy nhất>>`	`<nhãn tiếng Việt>`	`<mục đích>`	`<kiểu>`	`<Có hoặc Không>`	`<nguồn>`	`<quy tắc>`	`<giá trị>`	`<lỗi>`	`<quyền>`	Nếu danh sách chọn, nêu nguồn danh mục và hành vi khi không có giá trị hợp lệ.

2.7. Quy tắc hiển thị và điều kiện

Decision ID	Điều kiện	Hệ thống phải làm gì	Khi điều kiện sai	Chủ sở hữu quyết định	Hướng dẫn điền
`<DEC-<mã duy nhất>>`	`<if điều kiện dữ liệu hoặc quyền>`	`<hiển thị, ẩn, khóa, yêu cầu nhập, tính toán hoặc chặn>`	`<hành vi thay thế và thông báo>`	`<Business Owner, Security Owner, Architect hoặc vai trò phù hợp>`	Điều kiện phải xác định được từ dữ liệu hoặc quyền. Không chuyển giả định thành rule canonical.
`<DEC-<mã duy nhất>>`	`<điều kiện>`	`<hành vi>`	`<hành vi thay thế>`	`<vai trò>`	Nếu quyết định cần xác nhận pháp lý, kế toán hoặc privacy, ghi `Verification required`.

2.8. Placeholder tham chiếu bí mật an toàn

Thành phần cần cấu hình	Giá trị điền an toàn	Không được ghi	Hướng dẫn
API endpoint	`<https://<environment-host>/<path>>`	URL production chưa được phép công bố	Chỉ dùng host mô phỏng hoặc tên môi trường không nhạy cảm.
Secret reference	`<secret://<vault-name>/<secret-name>>`	Mật khẩu, token, API key, private key	Ghi tham chiếu tới kho bí mật, không ghi giá trị bí mật.
Authentication method	`<OAuth 2.0, mTLS, service account hoặc phương thức đã được Architect xác nhận>`	Header `Authorization` chứa token thật	Nêu cơ chế và owner xác nhận; không suy diễn cấu hình bảo mật.
Test account	`<synthetic-role-account-reference>`	Email, số điện thoại, định danh cá nhân thật	Chỉ dùng tài khoản mô phỏng và quyền tối thiểu cần kiểm thử.

Khung kiểm soát quyết định, ngoại lệ, bằng chứng và truy vết

Dùng khối này cho từng UX requirement (yêu cầu trải nghiệm người dùng). Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; chỉ dùng dữ liệu tổng hợp. Mỗi dòng phải có ID canonical đã đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Không suy diễn approval từ trạng thái review.

Trường	Giá trị cần điền	Hướng dẫn và kiểm tra
Artifact ID	`<ID artifact canonical>`	Giữ đúng ID đã đăng ký. Không tự tạo biến thể.
Tên tệp	`/03-templates/TMPL-UX-001_UX_REQUIREMENTS_SPECIFICATION.md`	Giữ đúng đường dẫn canonical.
Status	`IN_REVIEW`	Giá trị hiện hành bị khóa: `IN_REVIEW`. Không ghi `APPROVED` hoặc `BASELINED` khi chưa có tham chiếu kiểm soát.
Version	`v0.9.0`	Giá trị hiện hành bị khóa. Version mới phải có dòng lịch sử thay đổi.
Ngày cập nhật	`2026-08-07`	Định dạng `YYYY-MM-DD`, múi giờ `Asia/Ho_Chi_Minh`.
Locale và tiền tệ	`vi-VN`; `VND`	Dùng tiếng Việt; số tiền mô phỏng ghi rõ `VND`.
Phạm vi case	`Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp`	Không mô tả đây là cấu hình, dữ liệu, quyết định hoặc tuân thủ thực tế.

ID yêu cầu UX	Tên yêu cầu	Loại	Mô tả kiểm chứng được	Vai trò người dùng	Ưu tiên	Trạng thái quyết định
`<UXR-ID canonical>`	`<tên ngắn, động từ + đối tượng>`	`<Functional UX / Usability / Accessibility / Security UX / Data-entry UX>`	`<người dùng làm gì, tại màn hình nào, kết quả nào quan sát được>`	`<vai trò canonical>`	`<Must / Should / Could / Won't>`	`<Proposed / In review / Accepted for baseline / Rejected>`

Quy tắc kiểm tra yêu cầu: ID không trùng; mô tả có chủ thể, hành động, điều kiện và kết quả; ưu tiên dùng đúng bốn giá trị; Accepted for baseline chỉ là quyết định đề xuất nếu chưa có baseline reference. Nếu yêu cầu liên quan dữ liệu cá nhân, kế toán, hóa đơn, an toàn thực phẩm hoặc quyền truy cập, ghi Verification required và liên kết owner chuyên môn.

ID quyết định	Vấn đề cần quyết định	Lựa chọn A	Lựa chọn B	Tiêu chí đánh giá	Lựa chọn hiện tại	Bằng chứng và lý do	Owner quyết định	Trạng thái
`<DEC-ID canonical>`	`<câu hỏi một nghĩa>`	`<phương án A>`	`<phương án B>`	`<ví dụ: giảm lỗi nhập, WCAG, thời gian thao tác>`	`<A / B / Chưa quyết định>`	`<liên kết evidence ID; giải thích bằng chứng hỗ trợ lựa chọn>`	`<Business Owner / Product Owner / Architect / Security Owner>`	`<Open / In review / Decided / Escalated>`

ID ngoại lệ	Điều kiện kích hoạt	Hành vi giao diện bắt buộc	Thông điệp cho người dùng	Dữ liệu được giữ hoặc che	Hành động phục hồi	Owner xử lý	Trạng thái
`<EXC-ID canonical>`	`<điều kiện lỗi, thiếu quyền, xung đột hoặc dữ liệu không hợp lệ>`	`<chặn, cảnh báo, cho sửa, lưu nháp hoặc chuyển hỗ trợ>`	`<thông điệp rõ nguyên nhân và bước tiếp theo>`	`<trường được giữ; trường che bằng mask; không ghi secret>`	`<thao tác người dùng hoặc quy trình escalation>`	`<vai trò chịu trách nhiệm>`	`<Open / In review / Resolved / Escalated>`

Quy tắc ngoại lệ: Không hiển thị mật khẩu, access token, API key, session ID, số định danh cá nhân đầy đủ hoặc dữ liệu nhạy cảm trong thông điệp, ảnh chụp hay log. Dùng mẫu tham chiếu an toàn: <secret reference: vault://<approved-secret-store>/<secret-name>>. Chỉ ghi tham chiếu, không ghi giá trị secret.

ID bằng chứng	Phân loại nguồn	Artifact hoặc URL nguồn	Phiên bản hoặc trạng thái nguồn	Ngày truy cập	Nội dung được chứng minh	Giới hạn sử dụng
`<EVD-ID canonical>`	`<Primary official / Internal controlled artifact / Project assumption / Verification required>`	`<canonical path hoặc official URL>`	`<version, edition hoặc status>`	`<YYYY-MM-DD>`	`<mệnh đề cụ thể mà nguồn hỗ trợ>`	`<không suy diễn clause, nghĩa vụ pháp lý hoặc approval ngoài nguồn>`

ID liên kết	Loại nguồn	ID nguồn	Loại đích	ID đích	Quan hệ truy vết	Kiểm tra
`<TRC-ID canonical>`	`<Business rule / Data element / Process / Risk / Evidence / Test>`	`<ID canonical nguồn>`	`<UX requirement / Decision / Exception / Acceptance criterion>`	`<ID canonical đích>`	`<derives from / constrains / validates / mitigates / evidenced by>`	`<Pass / Fail / Verification required>`

Cầu nối suy luận: Mỗi liên kết derives from phải chỉ ra bằng chứng: <EVD-ID> hỗ trợ <ID nguồn>; <ID nguồn> tạo ràng buộc nào; ràng buộc đó dẫn tới <ID đích>. Không dùng liên kết để biến project assumption thành quy tắc bắt buộc.

Phiên bản	Ngày	Người ghi nhận	Loại thay đổi	Mô tả thay đổi	ID bị ảnh hưởng	Lý do và bằng chứng	Review cần thiết
`v0.9.0`	`2026-08-07`	`<vai trò hoặc tên mô phỏng>`	`Khởi tạo`	`<mô tả chính xác thay đổi trong phiên bản>`	`<danh sách ID canonical>`	`<EVD-ID hoặc Project assumption>`	`<Senior BA / Business Owner / Architect / QA / Legal / Security>`

ID review	Hạng mục review	Reviewer role	Tiêu chí review	Kết quả	Nhận xét có thể hành động	Ngày	Trạng thái
`<REV-ID canonical>`	`<UXR-ID, DEC-ID, EXC-ID hoặc toàn tài liệu>`	`<vai trò được phân quyền>`	`<đầy đủ, nhất quán, truy vết, khả dụng, accessibility, security>`	`<Pass / Fail / Conditional / Not reviewed>`	`<vấn đề, tác động, hành động cần làm>`	`<YYYY-MM-DD>`	`<Open / Closed / Escalated>`

ID sign-off	Phạm vi sign-off	Vai trò có thẩm quyền	Người ký hoặc tham chiếu hồ sơ	Quyết định	Ngày	Điều kiện hoặc giới hạn	Bằng chứng
`<SIG-ID canonical>`	`<ID hoặc phạm vi được xem xét>`	`<Business Owner / Product Owner / Architect / Security Owner / Legal Owner / QA Owner>`	`<tên mô phỏng hoặc controlled approval reference>`	`<Pending / Approved / Rejected / Not applicable>`	`<YYYY-MM-DD hoặc Chưa ghi nhận>`	`<điều kiện còn mở, nếu có>`	`<approval reference hoặc Chưa có approval reference>`

Pending, Not reviewed, Chưa ghi nhận và Chưa có approval reference là trạng thái hợp lệ khi chưa có quyết định được kiểm soát. Không thay bằng suy đoán, chữ ký giả lập hoặc xác nhận ngầm định.

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

Dùng bảng này khi điền mọi trường trong Tier 2. <...> là chỗ thay bằng giá trị thật của hồ sơ đang soạn; không giữ placeholder khi chuyển sang Tier 3. Mỗi suy luận phải ghi cầu nối: <bằng chứng nguồn> hỗ trợ <nhận định BA> nên đề xuất <yêu cầu/quy tắc>. Không biến giả định dự án thành nghĩa vụ pháp lý, kế toán, an toàn thực phẩm hoặc bảo mật.

Nhóm trường	Placeholder bắt buộc	Hướng dẫn điền	Giá trị hợp lệ	Quy tắc kiểm tra
Nhận diện	`<UXR-ID theo registry canonical>`	Dùng ID đã đăng ký trong `/01-curriculum/TRACEABILITY_ID_REGISTRY.md`; không tự tạo biến thể.	Chuỗi ID canonical đã đăng ký.	Không rỗng; duy nhất trong tài liệu; khớp nguyên dạng registry.
Tiêu đề	`<tên yêu cầu UX ngắn, theo kết quả người dùng>`	Nêu người dùng làm gì và đạt kết quả gì; không mô tả giải pháp trước.	10–120 ký tự; tiếng Việt, giữ thuật ngữ Anh cần thiết.	Không chứa “tốt”, “nhanh”, “thân thiện” nếu không có tiêu chí đo.
Loại yêu cầu	`<functional\|usability\|accessibility\|security-UX\|data-display\|error-handling>`	Chọn loại chính theo hành vi hoặc chất lượng cần kiểm soát.	Sáu giá trị liệt kê.	Chọn đúng một giá trị; nếu nhiều loại, tách yêu cầu hoặc ghi liên kết.
Vai trò người dùng	`<vai trò nghiệp vụ canonical>`	Nêu vai trò, không nêu tên cá nhân.	`<Business Role ID hoặc tên vai trò canonical>`.	Không dùng email, số điện thoại, tên thật, tài khoản production.
Bối cảnh kích hoạt	`<sự kiện, màn hình hoặc bước quy trình>`	Nêu điều kiện trước khi người dùng thấy hoặc dùng chức năng.	Mô tả kiểm chứng được.	Phải xác định được điểm bắt đầu; không dùng “khi cần”.
Dữ liệu hiển thị/nhập	`<tên trường dữ liệu canonical>`	Liên kết đến `/01-curriculum/CANONICAL_DATA_DICTIONARY.md` khi có.	Tên trường canonical hoặc `Verification required`.	Mỗi trường phải nêu nguồn, định dạng, bắt buộc/không bắt buộc và xử lý trống.
Định dạng	`<chuỗi\|số nguyên\|thập phân\|ngày\|giờ\|tiền tệ\|danh sách>`	Khai báo cách nhập, hiển thị và locale.	Giá trị liệt kê.	Tiền tệ dùng `VND`; ngày dùng `dd/MM/yyyy`; thời gian dùng `Asia/Ho_Chi_Minh` nếu có giờ.
Quy tắc UX	`<điều kiện> thì <hệ thống hiển thị/chặn/hướng dẫn> vì <lý do>`	Viết hành vi quan sát được.	Câu điều kiện kiểm thử được.	Có điều kiện, hành động hệ thống, kết quả người dùng; không chỉ ghi mục tiêu.
Thông báo lỗi	`<mã lỗi hoặc thông điệp tiếng Việt>`	Nêu lỗi, cách sửa, dữ liệu không được mất.	Thông điệp không tiết lộ bí mật hoặc cấu trúc nội bộ.	Không hiển thị token, stack trace, chuỗi kết nối, ID nội bộ nhạy cảm.
Tiêu chí chấp nhận	`<Given... When... Then...>`	Given là trạng thái đầu; When là thao tác; Then là kết quả kiểm tra được.	Một hoặc nhiều kịch bản Gherkin.	Mỗi kịch bản có kết quả xác định; không dùng “hoạt động đúng”.
Mức ưu tiên	`<Must\|Should\|Could\|Won't>`	Dùng MoSCoW: Must là điều kiện tối thiểu để đạt mục tiêu; không đồng nghĩa phê duyệt.	`Must`, `Should`, `Could`, `Won't`.	Chọn một; `Won't` phải nêu phạm vi loại trừ.
Trạng thái xác minh	`<Project assumption\|Verification required\|Verified source reference>`	Gắn nhãn theo mức bằng chứng hiện có.	Ba giá trị liệt kê.	Nội dung pháp lý, kế toán, thuế, riêng tư, an toàn thực phẩm chưa đối chiếu văn bản hiện hành phải là `Verification required`.

Điều kiện áp dụng. Chỉ điền <yêu cầu truy cập> khi UX thay đổi theo vai trò, quyền, chi nhánh hoặc trạng thái chứng từ. Chỉ điền <yêu cầu hỗ trợ tiếp cận> khi có thao tác, màu sắc, biểu mẫu, thông báo, thời gian hoặc nội dung cần người dùng cảm nhận; tham chiếu WCAG 2.2 theo phạm vi kiểm chứng, không tự tuyên bố tuân thủ. Chỉ điền <tích hợp/API> khi màn hình gọi dịch vụ khác; mô tả dữ liệu trao đổi, trạng thái lỗi và tác động người dùng, không suy diễn API chưa được đặc tả.

Mẫu tham chiếu bí mật an toàn. Khi trường cần khóa, token, mật khẩu, khóa ký số hoặc chuỗi kết nối, ghi <secret-reference: vault://<môi-trường>/<tên-secret>>, ví dụ cấu trúc <secret-reference: vault://<environment>/<secret-name>>. Không ghi giá trị bí mật, bản mã hóa, ảnh chụp màn hình, token mẫu có thể dùng được, URL nội bộ, IP nội bộ hoặc thông tin định danh cá nhân. <environment> chỉ nhận development, test, staging, production; Tier 2 không xác nhận môi trường nào tồn tại. Nếu chưa có kho bí mật được Architect hoặc Security Owner xác nhận, ghi <secret-reference: Verification required> và mở điểm cần xác minh, không tạo secret giả.

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

Case Nova Foods Trading & Manufacturing là mô phỏng giáo dục. Mọi tên người, giao dịch, mã, ngày, số tiền và dữ liệu dưới đây là dữ liệu tổng hợp; không mô tả ERP, nhân sự hoặc vận hành thực tế.

3.1. Thông tin hồ sơ UX

Trường	Giá trị đã điền
UX Requirement ID	`UXR-NF-SO-001`
Tên yêu cầu	Xác nhận giá bán và chiết khấu trước khi tạo đơn bán hàng
Sản phẩm	Nova Foods ERP
Phân hệ	Sales Order Management
Màn hình	`SO-NEW-01 — Tạo đơn bán hàng`
Trạng thái	`IN_REVIEW`
Phiên bản	`v0.9.0`
Ngày lập	`2026-08-07`
Múi giờ	`Asia/Ho_Chi_Minh`
Locale	`vi-VN`
Tiền tệ	`VND`
Owner tài liệu	Principal IT Business Analyst / Technical Curriculum Author
Business Owner mô phỏng	Nguyễn Minh Khôi — Sales Operations Manager
Decision authority mô phỏng	Trần Gia Hân — Commercial Director
Phân loại nguồn	`Project assumption`
Lý do phân loại	Luồng bán hàng, vai trò, giá và chính sách chiết khấu là dữ liệu case study tổng hợp; chưa phải quy định vận hành Nova Foods thực tế.

3.2. Bối cảnh và giao dịch mô phỏng

Ngày 2026-08-07, nhân viên bán hàng mô phỏng Lê Thanh An tạo đơn SO-20260807-0042 cho khách hàng CUS-NF-0187 — Siêu thị An Phúc Quận 7. Khách đặt 240 thùng SKU-NF-CHILI-500G — Tương Ớt Nova 500g, đơn vị tính THUNG, giá bảng hiện hành 285.000 VND/THUNG.

Hệ thống tính giá trị hàng trước chiết khấu là 68.400.000 VND. Nhân viên nhập chiết khấu 12%, tương đương 8.208.000 VND; giá trị sau chiết khấu là 60.192.000 VND. Mức chiết khấu này vượt ngưỡng tự xử lý mô phỏng 10% của vai trò Sales Executive. Người dùng cần biết ngay đơn có thể gửi xử lý hay phải chờ phê duyệt, vì việc lưu đơn ở trạng thái không rõ làm Sales Operations phải kiểm tra thủ công qua tin nhắn nội bộ.

Đối tượng	ID	Giá trị mô phỏng
Đơn bán hàng	`SO-20260807-0042`	Tạo ngày `2026-08-07 10:18:32`
Khách hàng	`CUS-NF-0187`	Siêu thị An Phúc Quận 7
Kho xuất dự kiến	`WH-HCM-01`	Kho Thành phẩm Hồ Chí Minh
Sản phẩm	`SKU-NF-CHILI-500G`	Tương Ớt Nova 500g
Số lượng	`240 THUNG`	Giá trị nhập bởi Lê Thanh An
Giá bảng	`PL-2026-H2-RETAIL-03`	`285.000 VND/THUNG`
Chiết khấu yêu cầu	`DISC-REQ-20260807-0091`	`12%`, tương đương `8.208.000 VND`
Người tạo đơn	`USR-NF-SEA-014`	Lê Thanh An, Sales Executive
Người duyệt dự kiến	`USR-NF-SOM-003`	Phạm Quốc Bảo, Sales Operations Manager

3.3. Người dùng, mục tiêu và hành vi hiện tại

Sales Executive là nhân viên tạo đơn và nhập chiết khấu theo thỏa thuận thương mại. Mục tiêu là hoàn tất đơn chính xác trong một lần nhập, biết rõ số tiền khách phải trả và biết đơn đang ở trạng thái nào. Bằng chứng mô phỏng là giao dịch SO-20260807-0042 có chiết khấu 12%, vượt ngưỡng 10% được giả định cho vai trò này.

Sales Operations Manager là người kiểm tra ngoại lệ chiết khấu. Mục tiêu là nhận được đơn vượt ngưỡng với số liệu đủ để quyết định, không phải tìm lại giá bảng, số lượng hoặc người tạo đơn. Điều này cần thiết vì quyết định giá sai có thể làm giảm biên lợi nhuận hoặc trì hoãn xác nhận đơn với khách.

Commercial Director là thẩm quyền quyết định cuối cho thay đổi chính sách chiết khấu vượt 15% hoặc ngoại lệ ngoài danh mục khách hàng. Quyền này là giả định dự án. Cần xác minh với Business Owner trước khi dùng cho vận hành thực tế.

Nội dung	Hiện trạng mô phỏng	Nhu cầu nền tảng
Hiển thị tổng tiền	Người dùng tự tính giá trị chiết khấu bằng máy tính hoặc bảng tính.	ERP phải tính nhất quán từ số lượng, giá bảng và tỷ lệ chiết khấu.
Nhận biết ngoại lệ	Sau khi bấm lưu, người dùng chỉ thấy thông báo “Đơn đã lưu”.	Màn hình phải nói rõ đơn được gửi duyệt hay có thể xác nhận ngay.
Kiểm tra quyền	Sales Operations kiểm tra thủ công vai trò người tạo đơn.	Hệ thống phải dùng vai trò đăng nhập để áp dụng ngưỡng phù hợp.
Lý do chiết khấu	Lý do nằm trong tin nhắn nội bộ, không gắn với đơn.	Đơn vượt ngưỡng phải lưu lý do để người duyệt có ngữ cảnh.

3.4. Phạm vi UX đã điền

Trong phạm vi	Ngoài phạm vi
Nhập số lượng, giá bảng, tỷ lệ chiết khấu và lý do chiết khấu trên `SO-NEW-01`.	Tạo hoặc sửa chính sách giá `PL-2026-H2-RETAIL-03`.
Tính tiền hàng, tiền chiết khấu và tổng tiền sau chiết khấu bằng `VND`.	Tính thuế, phát hành hóa đơn, hạch toán kế toán hoặc xác nhận nghĩa vụ thuế.
Hiển thị trạng thái đơn `DRAFT`, `PENDING_DISCOUNT_APPROVAL`, `READY_FOR_CONFIRMATION`, `REJECTED`.	Thay đổi hạn mức tín dụng khách hàng hoặc phân bổ tồn kho.
Gửi đơn vượt ngưỡng vào hàng chờ phê duyệt mô phỏng.	Gửi email, SMS hoặc tích hợp hệ thống bên ngoài.

3.5. Dữ liệu màn hình đã điền

Trường UI	Giá trị hiển thị trong case	Quy tắc nhập hoặc hiển thị
Mã đơn hàng	`SO-20260807-0042`	Chỉ đọc; hệ thống sinh khi lưu nháp lần đầu.
Khách hàng	`CUS-NF-0187 — Siêu thị An Phúc Quận 7`	Bắt buộc.
Kho xuất	`WH-HCM-01 — Kho Thành phẩm Hồ Chí Minh`	Bắt buộc.
Mã hàng	`SKU-NF-CHILI-500G`	Bắt buộc.
Số lượng	`240 THUNG`	Bắt buộc; số nguyên lớn hơn `0`.
Giá bảng	`285.000 VND/THUNG`	Chỉ đọc; lấy từ `PL-2026-H2-RETAIL-03`.
Tiền hàng	`68.400.000 VND`	Chỉ đọc; `240 × 285.000`.
Tỷ lệ chiết khấu	`12%`	Bắt buộc; từ `0%` đến `20%` theo giả định dự án.
Tiền chiết khấu	`8.208.000 VND`	Chỉ đọc; `68.400.000 × 12%`.
Lý do chiết khấu	`Khuyến mại khai trương quầy hàng tháng 08/2026`	Bắt buộc khi tỷ lệ lớn hơn `0%`.
Tổng sau chiết khấu	`60.192.000 VND`	Chỉ đọc; `68.400.000 − 8.208.000`.
Trạng thái xử lý	`PENDING_DISCOUNT_APPROVAL`	Hiển thị sau khi gửi duyệt.

3.6. Kết quả mong muốn

Khi Lê Thanh An nhập chiết khấu 12% và chọn Gửi phê duyệt, hệ thống phải giữ nguyên đơn SO-20260807-0042, hiển thị tổng sau chiết khấu 60.192.000 VND, đổi trạng thái thành PENDING_DISCOUNT_APPROVAL và nêu rõ: Chiết khấu 12% vượt ngưỡng tự xử lý 10% của Sales Executive. Đơn đã được gửi đến Sales Operations Manager.

Nếu hệ thống cho xác nhận trực tiếp đơn này, rủi ro là áp dụng giá chưa được kiểm tra. Nếu hệ thống chặn đơn mà không nói lý do và người xử lý tiếp theo, rủi ro là chậm phản hồi khách hàng. Cả hai hậu quả xuất phát từ cùng nhu cầu: trạng thái, ngưỡng và trách nhiệm phải nhìn thấy được tại thời điểm người dùng ra quyết định.

Hồ sơ UX hoàn chỉnh — Nova Foods mô phỏng

Artifact ID: TMPL-UX-001
Tệp: /03-templates/TMPL-UX-001_UX_REQUIREMENTS_SPECIFICATION.md
Trạng thái: IN_REVIEW
Phiên bản: v0.9.0
Ngày ghi nhận: 2026-08-07
Locale: vi-VN
Múi giờ: Asia/Ho_Chi_Minh
Tiền tệ: VND
Phạm vi: 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.

Trường UX	Giá trị hoàn chỉnh
UX Requirement ID	`UXR-NF-SO-001`
Tên yêu cầu	Cảnh báo tồn kho khả dụng trước khi xác nhận đơn bán hàng
Nhóm chức năng	ERP Sales Order Management
Người dùng chính	`NF-USR-014` — Nguyễn Minh An, Nhân viên Kinh doanh
Người dùng phụ	`NF-USR-022` — Trần Quốc Bảo, Trưởng nhóm Kho miền Nam
Điểm chạm	Màn hình tạo đơn bán hàng `SO-NEW-01`
Kích hoạt	Người dùng nhập sản phẩm, kho giao và số lượng trên dòng đơn bán
Kết quả cần đạt	Người dùng thấy tồn kho khả dụng theo kho trước khi gửi đơn; hệ thống chặn xác nhận khi số lượng yêu cầu vượt tồn kho khả dụng
Nhu cầu gốc	Giảm đơn được xác nhận nhưng không thể giao đủ. Bằng chứng: đơn mô phỏng `SO-NF-20260807-0184` yêu cầu `1.200` thùng `SP-NF-OC-500` từ `WH-HCM-01`, trong khi tồn kho khả dụng là `840` thùng.
Hành vi hiện tại	Màn hình chỉ hiển thị tồn kho tổng `3.450` thùng toàn hệ thống sau khi người dùng lưu nháp. Con số này không trừ giữ hàng tại kho giao và không hỗ trợ quyết định giao ngay.
Hệ quả hiện tại	Nhân viên có thể hứa giao `1.200` thùng dù `WH-HCM-01` chỉ còn `840` thùng khả dụng; kho phải điều chuyển hoặc giao thiếu sau khi khách đã nhận xác nhận.
Độ ưu tiên	Must have. Không có kiểm tra này, luồng xác nhận đơn không bảo vệ cam kết giao hàng mô phỏng.
Phân loại nguồn	`PROJECT_ASSUMPTION` — quy tắc tồn kho và ngưỡng cảnh báo là giả định học liệu, chưa phải cấu hình ERP thực tế.
Liên kết nguồn	`/01-curriculum/CANONICAL_BUSINESS_RULES.md`; `/01-curriculum/CANONICAL_DATA_DICTIONARY.md`; `/01-curriculum/TRACEABILITY_ID_REGISTRY.md`
Giới hạn	Không tính thuế, giá bán, phân bổ lô thực phẩm, điều chuyển kho tự động hoặc phát hành hóa đơn trong yêu cầu UX này.

Khái niệm nền: tồn kho khả dụng là số lượng còn có thể cam kết giao tại kho đã chọn. Công thức trong case mô phỏng: tồn kho khả dụng = tồn thực tế - số lượng đã giữ. Tồn kho tổng không đủ để quyết định giao hàng vì hàng có thể nằm ở kho khác hoặc đã được giữ cho đơn khác.

Dữ liệu dòng đơn	Giá trị
Đơn bán	`SO-NF-20260807-0184`
Khách hàng	`CUS-NF-0187` — Siêu thị An Khang
Sản phẩm	`SP-NF-OC-500` — Nước yến Nova 500 ml, thùng 24 chai
Kho giao	`WH-HCM-01` — Kho TP. Hồ Chí Minh
Số lượng yêu cầu	`1.200` thùng
Tồn thực tế	`1.050` thùng
Số lượng đã giữ	`210` thùng
Tồn kho khả dụng	`840` thùng
Giá bán mô phỏng	`468.000 VND/thùng`
Giá trị dòng đơn	`561.600.000 VND`
Thiếu hụt	`360` thùng
Thời điểm kiểm tra	`2026-08-07T10:15:30+07:00`

Quy tắc	Điều kiện	Hành vi giao diện	Trạng thái
`BR-NF-SO-AVAIL-001`	Số lượng yêu cầu nhỏ hơn hoặc bằng tồn kho khả dụng	Hiển thị nhãn xanh `Có thể giao`; cho phép xác nhận đơn	`AVAILABLE`
`BR-NF-SO-AVAIL-002`	Số lượng yêu cầu lớn hơn tồn kho khả dụng và nhỏ hơn hoặc bằng tồn kho tổng	Hiển thị cảnh báo đỏ, thiếu hụt, kho giao, tồn khả dụng; chặn xác nhận đơn	`INSUFFICIENT_AT_SELECTED_WAREHOUSE`
`BR-NF-SO-AVAIL-003`	Số lượng yêu cầu lớn hơn tồn kho tổng	Hiển thị cảnh báo đỏ `Không đủ tồn kho toàn hệ thống`; chặn xác nhận đơn	`INSUFFICIENT_SYSTEM_WIDE`
`BR-NF-SO-AVAIL-004`	Chưa chọn kho giao hoặc sản phẩm	Không gọi kiểm tra tồn kho; nút xác nhận đơn bị vô hiệu	`INCOMPLETE_INPUT`
`BR-NF-SO-AVAIL-005`	Dịch vụ tồn kho không phản hồi trong `5` giây	Hiển thị lỗi có thể thử lại; không dùng số liệu cũ để xác nhận đơn	`AVAILABILITY_CHECK_FAILED`

Quyết định UX: chọn chặn xác nhận đơn, không chỉ cảnh báo. Lý do: thiếu 360 thùng là dữ kiện kiểm tra được từ 1.200 - 840; cảnh báo có thể bị bỏ qua và tạo cam kết giao không có hàng. Phương án chỉ cảnh báo bị loại vì không ngăn sai lệch. Phương án tự chuyển sang kho khác bị loại vì thay đổi kho giao ảnh hưởng vận hành kho và chưa có quyết định nghiệp vụ mô phỏng cho phép tự động điều chuyển.

Tiêu chí quyết định	Chặn xác nhận	Chỉ cảnh báo	Tự đổi kho
Ngăn cam kết vượt tồn khả dụng	Đạt	Không đạt	Đạt
Giữ quyền quyết định kho cho người dùng có thẩm quyền	Đạt	Đạt	Không đạt
Không tạo tác động vận hành tự động ngoài phạm vi	Đạt	Đạt	Không đạt
Phù hợp phạm vi `UXR-NF-SO-001`	Đạt	Không đạt	Không đạt

Thẩm quyền quyết định: Business Owner mô phỏng của luồng Sales Order quyết định có cho phép xác nhận vượt tồn kho hay không. Warehouse Owner mô phỏng quyết định quy tắc giữ hàng và nguồn tồn kho. UX Designer quyết định cách hiển thị, không tự thay đổi quy tắc nghiệp vụ. Tại IN_REVIEW, các vai trò này chưa ghi nhận phê duyệt.

Payload kiểm tra tồn kho mô phỏng:

{
  "requestId": "AVC-NF-20260807-0042",
  "salesOrderId": "SO-NF-20260807-0184",
  "productId": "SP-NF-OC-500",
  "warehouseId": "WH-HCM-01",
  "requestedQuantity": 1200,
  "unitOfMeasure": "CARTON",
  "requestedAt": "2026-08-07T10:15:30+07:00"
}

{
  "requestId": "AVC-NF-20260807-0042",
  "productId": "SP-NF-OC-500",
  "warehouseId": "WH-HCM-01",
  "onHandQuantity": 1050,
  "reservedQuantity": 210,
  "availableQuantity": 840,
  "requestedQuantity": 1200,
  "shortageQuantity": 360,
  "availabilityState": "INSUFFICIENT_AT_SELECTED_WAREHOUSE",
  "checkedAt": "2026-08-07T10:15:31+07:00"
}

Nội dung hiển thị bắt buộc: Kho TP. Hồ Chí Minh chỉ còn 840 thùng khả dụng. Đơn này thiếu 360 thùng. Không thể xác nhận đơn bán. Nút Xác nhận đơn bị vô hiệu; nút Lưu nháp và Sửa số lượng vẫn hoạt động. Nếu hiển thị sai, người dùng có thể xác nhận giá trị mô phỏng 561.600.000 VND mà không có đủ hàng để giao; hậu quả là sai cam kết khách hàng, phát sinh xử lý kho thủ công và dữ liệu dự báo nhu cầu bị méo.

3.1 Core Record — Quyết định UX xử lý chênh lệch nhận hàng

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ người dùng, giao dịch, mã và giá trị dưới đây là dữ liệu tổng hợp. UX (User Experience) là trải nghiệm người dùng khi hoàn thành công việc. Exception handling là xử lý ngoại lệ khi dữ liệu thực nhận khác dữ liệu đã đặt.

Trường	Giá trị đã điền
Requirement ID	`UXR-NF-001`
Tên yêu cầu	Màn hình quyết định chênh lệch số lượng khi nhận nguyên liệu
Quy trình	Procure-to-Pay, bước nhận hàng kho nguyên liệu
Người dùng chính	Nguyễn Minh Khôi — Nhân viên Kho nguyên liệu, nhân sự mô phỏng `USR-NF-014`
Người quyết định nghiệp vụ	Trần Thu Hà — Procurement Manager, nhân sự mô phỏng `USR-NF-003`
Giao dịch mô phỏng	PO `PO-NF-260807-018`; phiếu nhận `GRN-NF-260807-042`; nhà cung cấp `SUP-NF-011` An Phát Nông Sản
Mặt hàng	`RM-NF-003` Đường tinh luyện 50 kg/bao
Dữ liệu giao dịch	Đặt 200 bao, thực nhận 196 bao, chênh thiếu 4 bao; đơn giá mô phỏng 720.000 VND/bao; giá trị chênh lệch 2.880.000 VND
Trạng thái artifact	`IN_REVIEW`, `v0.9.0`, ngày `2026-08-07`, `Asia/Ho_Chi_Minh`
Phân loại nguồn	Project assumption cho luồng thao tác; `CANONICAL_DATA_DICTIONARY` và `CANONICAL_BUSINESS_RULES` là nguồn canonical dự kiến nhưng chưa xác nhận nội dung vận hành

Sự kiện và hành vi hiện tại. Kho nhận 196 bao, nhưng ERP mô phỏng chỉ cho xác nhận toàn bộ 200 bao hoặc hủy phiếu nhận. Bằng chứng là phiếu GRN-NF-260807-042 không có trường nhập số lượng thực nhận, lý do chênh lệch, người xử lý hay trạng thái chờ quyết định. Nhân viên Kho phải nhắn tin ngoài hệ thống cho Procurement Manager. Dữ liệu tồn kho, công nợ dự kiến và hồ sơ tranh chấp vì thế không cùng một nguồn ghi nhận.

Nhu cầu nền tảng. Người dùng cần ghi nhận số lượng thực nhận tại thời điểm kiểm đếm, giữ phiếu ở trạng thái kiểm soát, rồi chuyển người có thẩm quyền quyết định. Lý do: nhận đủ theo PO khi thực nhận thiếu sẽ làm tồn kho tăng sai 4 bao và có thể làm đối soát nhà cung cấp dựa trên số liệu sai; hủy phiếu làm mất bằng chứng nhận hàng đã xảy ra. Nhu cầu này là yêu cầu UX và kiểm soát dữ liệu mô phỏng, không phải kết luận kế toán, thuế hay pháp lý.

Phương án	Mô tả	Đánh giá theo tiêu chí	Kết quả
OPT-01	Cho Kho sửa số lượng PO thành 196 bao	Nhanh, nhưng sửa chứng từ mua ban đầu; mất dấu vết mức đặt 200 bao	Loại
OPT-02	Cho Kho xác nhận 196 bao, bắt buộc chọn lý do, chuyển chờ quyết định	Giữ PO gốc, ghi bằng chứng thực nhận, phân tách quyền nhập và quyền quyết định	Khuyến nghị
OPT-03	Chỉ cho Procurement Manager tạo phiếu nhận	Kiểm soát cao, nhưng chậm ghi nhận hàng tại cửa kho và tạo nút thắt vận hành	Loại

Tiêu chí quyết định	Ngưỡng áp dụng	OPT-02 đáp ứng
Toàn vẹn dữ liệu	Không sửa số lượng đặt trên `PO-NF-260807-018`	Có; lưu riêng số lượng đặt 200 và thực nhận 196
Khả năng truy vết	Có mã giao dịch, thời điểm, người nhập, lý do, trạng thái	Có; gắn `GRN-NF-260807-042`, `USR-NF-014`, thời điểm mô phỏng `2026-08-07 10:18`
Phân quyền	Kho nhập thực tế; Procurement quyết định xử lý chênh lệch	Có
Hiệu quả thao tác	Nhập xong trong một màn hình, không cần kênh ngoài hệ thống	Có
Phòng ngừa sai sót	Không cho hoàn tất khi thực nhận khác đặt mà thiếu lý do	Có

Quyết định đề xuất. Chọn OPT-02: màn hình hiển thị PO, số lượng đặt, số lượng thực nhận, chênh lệch tự tính, lý do chênh lệch và ghi chú. Khi Khôi nhập 196 bao, hệ thống tính chênh lệch -4, yêu cầu lý do SHORT_DELIVERY, rồi đặt GRN-NF-260807-042 ở trạng thái PENDING_PROCUREMENT_DECISION. Kho không thể chuyển sang POSTED. Procurement Manager có thể chọn ACCEPT_SHORT_DELIVERY hoặc REQUEST_SUPPLIER_FOLLOW_UP; quyền quyết định thuộc Trần Thu Hà trong case mô phỏng. Quyết định này vẫn IN_REVIEW; không phải phê duyệt vận hành.

Quy tắc UX	Kết quả bắt buộc
Thực nhận bằng số lượng đặt	Cho phép trạng thái `POSTED` nếu các kiểm tra khác đạt
Thực nhận thấp hơn số lượng đặt	Bắt buộc lý do và ghi chú; trạng thái `PENDING_PROCUREMENT_DECISION`
Thực nhận cao hơn số lượng đặt	Chặn hoàn tất; hiển thị “Số lượng thực nhận vượt số lượng đặt. Cần Procurement Manager xử lý.”
Lý do trống khi có chênh lệch	Chặn lưu; đặt focus vào trường lý do
Người không thuộc Procurement mở phiếu chờ quyết định	Chỉ xem; không thấy nút quyết định

Nếu chọn sai phương án hoặc bỏ quy tắc, Nova Foods mô phỏng có thể ghi nhận tồn kho sai, không xác định được ai đã ghi nhận chênh lệch, và xử lý nhà cung cấp bằng dữ liệu không đủ bằng chứng. Liên kết truy vết: /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md; nội dung chi tiết các artifact này vẫn cần xác minh trước khi dùng ngoài học liệu.

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

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ dữ liệu dưới đây là dữ liệu tổng hợp. Phạm vi bằng chứng áp dụng cho phiếu nhận hàng GRN-NF-260807-042: Khôi, nhân viên kho mô phỏng, nhận 196 bao nguyên liệu so với 200 bao trên PO. Chênh lệch -4 bao tạo trạng thái PENDING_PROCUREMENT_DECISION; không được ghi nhận POSTED trước quyết định Procurement.

Tình huống ngoại lệ hoặc negative path	Dữ liệu kích hoạt	Hành vi bắt buộc	Bằng chứng phải lưu	Chủ sở hữu xử lý
Thiếu hàng	Đặt `200`, thực nhận `196`	Tự tính chênh lệch `-4`; bắt buộc chọn `SHORT_DELIVERY`, nhập ghi chú; chặn `POSTED`	PO mô phỏng, GRN, lý do, ghi chú, thời điểm, người nhập	Khôi nhập; Trần Thu Hà quyết định Procurement
Vượt số lượng đặt	Thực nhận `201`	Chặn hoàn tất; hiển thị “Số lượng thực nhận vượt số lượng đặt. Cần Procurement Manager xử lý.”	Giá trị đã nhập, thông báo chặn, thời điểm	Procurement Manager
Chênh lệch nhưng lý do trống	Thực nhận `196`; lý do rỗng	Chặn lưu; đặt focus vào trường lý do	Lỗi kiểm tra trường bắt buộc trong phiên làm việc	Khôi
Chênh lệch nhưng ghi chú trống	Thực nhận `196`; lý do `SHORT_DELIVERY`; ghi chú rỗng	Chặn lưu; hiển thị yêu cầu mô tả nguyên nhân	Lỗi kiểm tra trường bắt buộc trong phiên làm việc	Khôi
Người không thuộc Procurement quyết định	Khôi mở GRN chờ quyết định	Chỉ xem; không hiển thị nút `ACCEPT_SHORT_DELIVERY` hoặc `REQUEST_SUPPLIER_FOLLOW_UP`	Vai trò phiên đăng nhập, màn hình chỉ đọc	Procurement Manager
Không tìm thấy PO mô phỏng liên kết	GRN không có PO hợp lệ	Chặn tạo hoặc lưu GRN; không suy đoán PO	Thông báo lỗi liên kết PO và nhật ký lỗi ứng dụng nếu có	Warehouse Supervisor và Procurement Manager

Giả định dự án. 200 bao là số lượng đặt hợp lệ của PO mô phỏng liên kết với GRN-NF-260807-042. Cầu nối suy luận: case đã xác định chênh lệch 196 - 200 = -4; vì vậy UX cần giữ đồng thời số lượng đặt, thực nhận, chênh lệch, lý do và ghi chú để người quyết định có dữ liệu kiểm tra. Giả định này không xác nhận cấu hình ERP thực, chính sách nhận hàng thực, cách hạch toán, nghĩa vụ thuế, hay tuân thủ pháp lý.

Hạng mục cần xác minh	Lý do cần xác minh	Vai trò có thẩm quyền	Trạng thái
Có cho phép `ACCEPT_SHORT_DELIVERY` chuyển GRN sang `POSTED` hay không	Case chỉ nêu lựa chọn quyết định, chưa nêu hậu quả tồn kho hoặc kế toán	Business Owner, Accounting Owner	Verification required
Có cần đính kèm ảnh, biên bản giao nhận hoặc chứng từ nhà cung cấp không	Chưa có nguồn canonical nêu loại bằng chứng bắt buộc	Procurement Owner, Food-safety Owner	Verification required
Thời hạn Procurement xử lý GRN chờ quyết định	Chưa có SLA mô phỏng được đăng ký	Procurement Owner	Verification required
Quyền xem ghi chú chênh lệch	Ghi chú có thể chứa thông tin vận hành; quyền truy cập chưa được xác định	Security Owner, Procurement Owner	Verification required

Bằng chứng tham chiếu	Phân loại nguồn	Vai trò trong case	Ranh giới sử dụng
`/01-curriculum/CANONICAL_BUSINESS_RULES.md`	Canonical-rule catalog plan, `IN_REVIEW`	Nơi phải kiểm tra quy tắc chênh lệch và quyền quyết định trước khi gọi là quy tắc canonical	Không chứng minh quy tắc đã baseline hoặc được phê duyệt
`/01-curriculum/CANONICAL_DATA_DICTIONARY.md`	Canonical logical-data plan, `IN_REVIEW`	Nơi phải kiểm tra định nghĩa PO, GRN, số lượng đặt, thực nhận, lý do và ghi chú	Không phải đặc tả DB hoặc API production
`/01-curriculum/TRACEABILITY_ID_REGISTRY.md`	Canonical identifier registry plan, `IN_REVIEW`	Nơi phải kiểm tra ID family trước khi tạo liên kết NEED, REQ, BR, AC, DATA/API, TC, DEF hoặc CR	Không tự cấp ID canonical
`https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/`	Nguồn chính thức, BABOK Guide Version 3 overview và errata	Tham chiếu thuật ngữ BA: requirement, stakeholder, traceability	Không suy diễn trang hoặc điều khoản chưa truy cập
`https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf`	Nguồn chính thức, ISTQB CTFL Syllabus v4.0.1	Tham chiếu tư duy kiểm thử negative path và kiểm thử điều kiện biên	Không tuyên bố test case đã chạy

Escalation record. Escalation là chuyển vấn đề vượt thẩm quyền của người ghi nhận đến vai trò có quyền quyết định. Với GRN-NF-260807-042, Principal IT Business Analyst / Technical Curriculum Author phải ghi nhận vấn đề “Hậu quả của ACCEPT_SHORT_DELIVERY đối với tồn kho và kế toán chưa được xác minh”, kèm số lượng đặt 200, thực nhận 196, chênh lệch -4, trạng thái PENDING_PROCUREMENT_DECISION, và các artifact tham chiếu trên. Gói escalation gửi Business Owner, Procurement Owner và Accounting Owner. Không được tự đổi trạng thái GRN sang POSTED, tự đặt thời hạn xử lý, hoặc gọi quyết định là đã phê duyệt.

4.1 Ma trận truy vết đầu-cuối cho kịch bản tạo phiếu yêu cầu xuất kho

Kịch bản Nova Foods là mô phỏng giáo dục, dùng dữ liệu tổng hợp: nhân viên kho tạo phiếu yêu cầu xuất 120 thùng NF-NUOC-330 cho đơn bán SO-NF-2026-0817. Truy vết đầu-cuối nối nhu cầu (NEED), yêu cầu (REQ), quy tắc nghiệp vụ (BR), tiêu chí chấp nhận (AC), dữ liệu/giao diện lập trình ứng dụng (DATA/API), ca kiểm thử (TC), lỗi (DEF) và yêu cầu thay đổi (CR). Liên kết chứng minh vì sao một kiểm thử tồn tại và phạm vi tác động khi yêu cầu đổi; không xác nhận baseline, phê duyệt, cấu hình ERP thực tế hay tuân thủ pháp lý.

Family / ID	Nội dung kiểm soát đã điền đủ	Liên kết xuống	Bằng chứng và cầu nối suy luận	Trạng thái
`NEED-NF-001`	Kho cần chặn tạo phiếu xuất vượt tồn khả dụng, tránh cam kết số lượng không thể xuất.	`REQ-NF-001`	Nhu cầu xuất phát từ rủi ro giao hàng thiếu. Hệ thống phải biết tồn khả dụng trước khi nhận phiếu.	`IN_REVIEW`
`REQ-NF-001`	Màn hình tạo phiếu phải kiểm tra `requestedQuantity` không lớn hơn `availableQuantity` của cùng `itemCode` và `warehouseCode` trước khi lưu.	`BR-NF-001`, `AC-NF-001`, `DATA-NF-001`, `API-NF-001`, `TC-NF-001`, `TC-NF-002`	REQ chuyển NEED thành hành vi kiểm tra được. So sánh hai số lượng là điều kiện tối thiểu để chặn vượt tồn.	`IN_REVIEW`
`BR-NF-001`	Chỉ cho lưu khi `requestedQuantity` là số nguyên lớn hơn 0 và không vượt `availableQuantity`; giá trị bằng tồn khả dụng được phép.	`AC-NF-001`, `AC-NF-002`	Quy tắc nghiệp vụ là điều kiện quyết định. Điều kiện bằng được phép vì không làm tồn khả dụng âm. Đây là giả định dự án mô phỏng, cần Business Owner xác minh nếu dùng ngoài học liệu.	`IN_REVIEW`
`AC-NF-001`	Với `NF-NUOC-330`, kho `KHO-HCM-01`, tồn khả dụng `120`, nhập yêu cầu `120`, hệ thống lưu phiếu `WR-NF-2026-00017` và hiển thị trạng thái `DRAFT`.	`TC-NF-001`	AC biến BR thành kết quả quan sát được. Giá trị biên bằng `availableQuantity` kiểm tra nhánh được phép.	`IN_REVIEW`
`AC-NF-002`	Với cùng mặt hàng và kho, tồn khả dụng `120`, nhập yêu cầu `121`, hệ thống không lưu phiếu và hiển thị `Số lượng yêu cầu vượt tồn khả dụng 120`.	`TC-NF-002`, `DEF-NF-001`	AC kiểm tra nhánh từ chối của BR. Không có bản ghi mới là bằng chứng chặn dữ liệu sai.	`IN_REVIEW`
`DATA-NF-001`	Logical data: `WarehouseRequest.requestId`, `salesOrderCode`, `itemCode`, `warehouseCode`, `requestedQuantity`, `availableQuantity`, `status`; `requestedQuantity` và `availableQuantity` là số nguyên, đơn vị thùng.	`API-NF-001`, `TC-NF-001`, `TC-NF-002`	Dữ liệu là đầu vào và đầu ra của so sánh trong REQ. Tham chiếu quản trị: `CANONICAL_DATA_DICTIONARY`, chưa có baseline.	`IN_REVIEW`
`API-NF-001`	`POST /warehouse-requests` nhận `salesOrderCode`, `itemCode`, `warehouseCode`, `requestedQuantity`; trả `201` khi hợp lệ, `422` khi vượt tồn hoặc số lượng không hợp lệ.	`TC-NF-001`, `TC-NF-002`	API là hợp đồng tích hợp mô phỏng để thực hiện REQ. Mã `422` phân biệt dữ liệu hợp lệ về cấu trúc nhưng không thỏa quy tắc nghiệp vụ.	`IN_REVIEW`
`TC-NF-001`	Gửi `POST /warehouse-requests` với `SO-NF-2026-0817`, `NF-NUOC-330`, `KHO-HCM-01`, `requestedQuantity: 120`; dữ liệu tồn mô phỏng là `120`; kỳ vọng `201`, `requestId: WR-NF-2026-00017`, `status: DRAFT`.	`REQ-NF-001`, `BR-NF-001`, `AC-NF-001`, `DATA-NF-001`, `API-NF-001`	Ca kiểm thử hộp đen kiểm chứng đầu vào biên hợp lệ và kết quả đã nêu trong AC.	`IN_REVIEW`
`TC-NF-002`	Gửi cùng dữ liệu, thay `requestedQuantity: 121`; kỳ vọng `422`, thông báo đúng `Số lượng yêu cầu vượt tồn khả dụng 120`, không tạo `requestId`.	`REQ-NF-001`, `BR-NF-001`, `AC-NF-002`, `DATA-NF-001`, `API-NF-001`, `DEF-NF-001`	Ca kiểm thử hộp đen kiểm chứng nhánh âm. Kiểm tra không tạo phiếu ngăn lỗi bị che bởi thông báo giao diện.	`IN_REVIEW`
`DEF-NF-001`	Lỗi mô phỏng: phiên bản kiểm thử lưu phiếu khi `requestedQuantity: 121`; mức độ `High`; phát hiện bởi `TC-NF-002`; chưa có bản sửa được xác nhận.	`REQ-NF-001`, `BR-NF-001`, `AC-NF-002`, `TC-NF-002`	DEF nối kết quả sai với điều kiện bị vi phạm. Không suy diễn nguyên nhân kỹ thuật khi chưa có bằng chứng điều tra.	`IN_REVIEW`
`CR-NF-001`	Đề nghị mô phỏng: hiển thị `availableQuantity` cạnh trường nhập số lượng. Phạm vi tác động dự kiến: `REQ-NF-001`, `AC-NF-001`, `AC-NF-002`, `DATA-NF-001`, `API-NF-001`, `TC-NF-001`, `TC-NF-002`.	Các ID liệt kê trong phạm vi tác động	CR là thay đổi trải nghiệm người dùng, không đổi BR. Liệt kê tác động vì hiển thị dữ liệu cần hợp đồng dữ liệu và kiểm thử hồi quy. Chưa có baseline hay phê duyệt thay đổi.	`IN_REVIEW`

Bảng quyết định hoàn chỉnh — Xác nhận xuất kho theo đơn bán Nova Foods

Bảng quyết định chuyển quy tắc giao diện thành các tổ hợp đầu vào hữu hạn. Người học đọc mỗi cột như một tình huống: điều kiện đúng hoặc sai quyết định hệ thống cho phép xác nhận xuất kho hay chặn thao tác. Nova Foods là case mô phỏng; toàn bộ mã đơn, lô hàng, số lượng và tiền tệ dưới đây là dữ liệu tổng hợp.

Điều kiện / Hành động	R1	R2	R3	R4	R5	R6
Người dùng có quyền `WAREHOUSE_CONFIRM`	Có	Có	Có	Có	Không	Có
Đơn bán `SO-NF-260807-001` ở trạng thái `READY_TO_PICK`	Có	Có	Có	Không	Có	Có
Kho `WH-HCM-01` còn đủ `120` thùng `NF-MANGO-500`	Có	Không	Có	Có	Có	Có
Lô `LOT-MG-260801-A` còn hạn dùng tại ngày xác nhận `2026-08-07`	Có	Có	Không	Có	Có	Có
Số lượng nhập `120` lớn hơn `0` và không vượt số lượng cần xuất	Có	Có	Có	Có	Có	Không
Hiển thị nút `Xác nhận xuất kho`	Có	Có	Có	Có	Không	Có
Cho phép gửi yêu cầu xác nhận	Có	Không	Không	Không	Không	Không
Kết quả giao diện	Tạo xác nhận xuất kho	Chặn, báo thiếu tồn kho	Chặn, báo lô hết hạn	Chặn, báo trạng thái đơn không hợp lệ	Ẩn thao tác xác nhận	Chặn, báo số lượng không hợp lệ
Thông báo tiếng Việt	`Đã xác nhận xuất 120 thùng NF-MANGO-500 từ lô LOT-MG-260801-A.`	`Không đủ tồn kho khả dụng. Cần 120 thùng, hiện có 95 thùng.`	`Lô LOT-MG-260801-A hết hạn ngày 2026-08-06, không thể xuất ngày 2026-08-07.`	`Đơn SO-NF-260807-001 chưa sẵn sàng để xuất kho.`	`Bạn không có quyền xác nhận xuất kho.`	`Số lượng xuất phải lớn hơn 0 và không vượt 120 thùng.`

Quy tắc R1 là đường thành công duy nhất vì mọi điều kiện kiểm soát đều đạt. R2 đến R6 là đường âm, tức thao tác bị từ chối có chủ đích để ngăn ghi nhận xuất kho sai. Giao diện phải giữ nguyên dữ liệu đã nhập sau khi chặn, trừ khi người dùng tự sửa; lý do là người dùng cần sửa đúng điều kiện lỗi mà không nhập lại mã hàng, lô và số lượng.

Bộ dữ liệu kiểm thử tổng hợp	Giá trị
Người dùng hợp lệ	`USR-NF-WH-001`, vai trò `Warehouse Operator`, quyền `WAREHOUSE_CONFIRM`
Người dùng không hợp lệ	`USR-NF-SALES-001`, vai trò `Sales Clerk`, không có quyền `WAREHOUSE_CONFIRM`
Đơn bán	`SO-NF-260807-001`
Khách hàng	`CUS-NF-RET-001 — Cửa hàng Minh An`
Kho	`WH-HCM-01 — Kho Thành phẩm Hồ Chí Minh`
Mã hàng	`NF-MANGO-500 — Nước xoài Nova 500 ml`
Đơn vị tính	`THUNG`
Số lượng cần xuất	`120`
Tồn khả dụng cho R1	`120`
Tồn khả dụng cho R2	`95`
Lô hợp lệ	`LOT-MG-260801-A`, hạn dùng `2026-08-20`
Lô hết hạn	`LOT-MG-260731-X`, hạn dùng `2026-08-06`
Số lượng không hợp lệ	`0` hoặc `121`
Thời điểm mô phỏng xác nhận	`2026-08-07 10:15:00`, `Asia/Ho_Chi_Minh`
Giá trị tiền tệ hiển thị nếu có	`VND`; không dùng dữ liệu khách hàng hoặc giao dịch thật

5. Tier 4 ? Senior BA Quality Gate

Quality Gate là cổng kiểm soát trước baseline: Senior BA kiểm tra đặc tả đủ để các vai trò khác đọc cùng một nghĩa, kiểm thử được và truy ngược được. Kết quả chỉ là ghi nhận review tại IN_REVIEW, không tạo baseline, approval, xác nhận tuân thủ hoặc quyền triển khai production.

Mã kiểm tra	Hạng mục	PASS	FAIL	STOP	Escalation
QG-UX-001	Tính đầy đủ	Có mục tiêu, phạm vi, actor, luồng chính, luồng lỗi, dữ liệu, quy tắc, tiêu chí chấp nhận và ngoại lệ cho từng chức năng.	Thiếu một phần nhưng không làm đổi nghĩa chức năng.	Thiếu luồng, quy tắc hoặc ngoại lệ làm QA không thể lập test basis.	Business Owner khi thiếu quyết định nghiệp vụ; Senior BA lập danh sách khoảng trống.
QG-UX-002	Tính nhất quán	ID, tên chức năng, actor, trạng thái, dữ liệu và thuật ngữ khớp trong cùng artifact và artifact canonical.	Sai khác cách viết không làm đổi đối tượng hay hành vi.	Một ID hoặc quy tắc có hai nghĩa, hoặc mâu thuẫn nguồn canonical.	Principal IT Business Analyst / Technical Curriculum Author; chuyển Business Owner nếu phải chọn nghĩa nghiệp vụ.
QG-UX-003	Tính kiểm thử	Mỗi acceptance criterion có điều kiện đầu vào, thao tác, kết quả mong đợi và kết quả chặn đo được.	Có tiêu chí nhưng thiếu dữ liệu kiểm thử tổng hợp cụ thể.	Tiêu chí dùng từ chủ quan như “nhanh”, “dễ dùng”, “đúng” mà không có ngưỡng hoặc quan sát được.	QA Reviewer xác định testability; Business Owner quyết định ngưỡng nghiệp vụ.
QG-UX-004	Traceability	Mỗi requirement, rule, dữ liệu, UI state và acceptance criterion có liên kết ID nguồn hợp lệ.	Liên kết có nhưng mô tả quan hệ chưa rõ.	Requirement không truy được về nguồn, hoặc ID không thuộc registry canonical.	Owner của `/01-curriculum/TRACEABILITY_ID_REGISTRY.md`; không tự tạo hoặc đổi canonical ID trong review.
QG-UX-005	Thẩm quyền nguồn	Nguồn được phân loại đúng: nghiệp vụ, pháp lý, kế toán, bảo mật, chuẩn hoặc giả định dự án. Suy luận nêu bằng chứng và cầu nối lý do.	Nguồn đúng nhưng ngày truy cập, version hoặc giới hạn dùng chưa ghi đủ.	Nội dung pháp lý, kế toán hoặc kỹ thuật bị trình bày như kết luận bắt buộc khi chưa có nguồn hoặc xác minh thẩm quyền.	Legal Owner, Accounting Owner, Security Owner hoặc Architect theo loại quyết định.
QG-UX-006	Ownership	Mỗi quyết định, dữ liệu chủ và điểm phê duyệt tương lai có owner vai trò rõ; Owner tài liệu không bị gán quyền ngoài thẩm quyền.	Vai trò có tên nhưng trách nhiệm giao cắt chưa phân định.	Không có người chịu trách nhiệm cho quy tắc, dữ liệu hoặc ngoại lệ có ảnh hưởng vận hành.	Business Owner phân công; Principal IT Business Analyst / Technical Curriculum Author chỉ điều phối truy vết.
QG-UX-007	Bảo mật và riêng tư	Quyền truy cập, actor, dữ liệu hiển thị, thao tác bị từ chối và audit need được nêu; dữ liệu Nova Foods là tổng hợp.	Có kiểm soát quyền nhưng thiếu tình huống từ chối hoặc ranh giới dữ liệu.	Có dữ liệu cá nhân, secret, quyền nhạy cảm hoặc API exposure mà không có đánh giá Security/Privacy.	Security Owner và Legal/Privacy Owner; tham chiếu OWASP chỉ là good practice, không phải luật Việt Nam.
QG-UX-008	Ranh giới pháp lý, kế toán, thực phẩm	Mọi chi tiết thuộc Luật Bảo vệ dữ liệu cá nhân, Luật Kế toán, hóa đơn chứng từ hoặc an toàn thực phẩm được ghi là `Verification required` hay giả định dự án nếu chưa được xác minh chính thức.	Có nhãn nhưng chưa nêu owner xác minh.	Đặc tả tự diễn giải luật, thuế, hạch toán, hóa đơn hoặc truy xuất thực phẩm thành rule production.	Legal Owner, Accounting Owner, Compliance Owner và domain owner tương ứng.
QG-UX-009	Tác động thay đổi	Mỗi thay đổi nêu requirement, UI, dữ liệu, rule, test, tài liệu và vai trò bị ảnh hưởng.	Có phạm vi thay đổi nhưng thiếu một liên kết phụ thuộc.	Thay đổi rule hoặc dữ liệu chủ có thể phá traceability, kiểm thử hoặc kiểm soát mà chưa đánh giá tác động.	Change Owner triệu tập Business Owner, QA, Architect, Security, Legal hoặc Accounting theo tác động.
QG-UX-010	Trạng thái quản trị	Artifact ghi `IN_REVIEW`, `v0.9.0`, ngày `2026-08-07`, `vi-VN`, `Asia/Ho_Chi_Minh`, `VND` và Nova Foods mô phỏng, dữ liệu tổng hợp.	Một metadata trình bày chưa nhất quán nhưng không tạo sai nghĩa kiểm soát.	Ghi `APPROVED`, `BASELINED`, production-ready hoặc tuyên bố tuân thủ khi không có tham chiếu kiểm soát hợp lệ.	Principal IT Business Analyst / Technical Curriculum Author sửa metadata; không được tự ghi approval.

Quy tắc quyết định: PASS khi mọi kiểm tra đạt và không có STOP. FAIL yêu cầu sửa, liên kết lại bằng chứng hoặc làm rõ trước vòng review kế tiếp. STOP chặn baseline candidate vì lỗi làm thay đổi nghĩa requirement, vượt thẩm quyền, gây rủi ro dữ liệu hoặc làm mất khả năng kiểm thử. Escalation là chuyển gói vấn đề gồm ID, bằng chứng, tác động, câu hỏi quyết định và owner cần trả lời; không phải tự suy diễn câu trả lời thay vai trò có thẩm quyền.

Phạm vi kiểm tra chất lượng chuyên sâu

Quality gate là cổng kiểm tra trước baseline: Senior BA kiểm tra requirement đủ, nhất quán, kiểm thử được và có căn cứ; không thay vai trò Business Owner, Legal Owner, Accounting Owner, Security, Architect hoặc QA. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp, trạng thái tài liệu vẫn IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Trục kiểm tra	Câu hỏi kiểm tra từ nguyên lý	Bằng chứng phải có trong Tier 3	Ranh giới quyết định
Tính đầy đủ	Mỗi nhu cầu có actor, điều kiện bắt đầu, luồng chính, ngoại lệ, dữ liệu vào, dữ liệu ra và kết quả nghiệp vụ chưa? Requirement thiếu một phần không cho người xây dựng biết phải tạo gì hoặc xử lý khi nào.	Core Record hoàn chỉnh; danh sách business rule; acceptance criteria; ngoại lệ; payload hoặc màn hình mô phỏng; liên kết dữ liệu.	BA ghi nhận khoảng trống; Business Owner xác nhận ý nghĩa nghiệp vụ.
Tính nhất quán	Cùng một khái niệm có cùng tên, ID, trạng thái, đơn vị đo, tiền tệ và quy tắc ở mọi bảng chưa? Mâu thuẫn làm cùng một yêu cầu tạo ra hai hành vi ERP khác nhau.	Đối chiếu với `CANONICAL_BUSINESS_RULES`, `CANONICAL_DATA_DICTIONARY`, `TRACEABILITY_ID_REGISTRY`; dùng `vi-VN`, `Asia/Ho_Chi_Minh`, `VND`.	Không tự đổi canonical ID, thuật ngữ hoặc quy tắc tại template.
Tính kiểm thử được	Mỗi acceptance criterion có điều kiện đầu vào, thao tác, kết quả quan sát được và dữ liệu tổng hợp cụ thể chưa? “Hệ thống dễ dùng” không kiểm thử được vì thiếu thước đo.	Kịch bản kiểm thử hộp đen; dữ liệu Nova Foods tổng hợp; kết quả mong đợi; xử lý lỗi; quyền truy cập liên quan. Thuật ngữ black-box testing là kiểm thử theo đầu vào và đầu ra, không cần biết mã nguồn.	QA xác nhận cách kiểm thử; BA không tự xác nhận test pass.
Truy vết	Mỗi requirement truy ngược đến nguồn, nhu cầu hoặc quy tắc nào; truy xuôi đến acceptance criterion, dữ liệu và test basis nào? Traceability là khả năng lần theo liên kết hai chiều để biết vì sao requirement tồn tại và thay đổi gì bị ảnh hưởng.	Liên kết nguồn → requirement → business rule/data field → acceptance criterion → test basis; giữ nguyên ID canonical và tên tệp nguồn.	Không tạo liên kết giả khi nguồn chỉ là giả định dự án.
Thẩm quyền nguồn	Nguồn có đủ quyền quyết định loại nội dung đang được nêu không? Tài liệu chuẩn hỗ trợ thuật ngữ; luật là nguồn pháp lý; ý kiến vận hành không tự thành nghĩa vụ pháp lý.	Phân loại `primary`, `normative`, `official legal`, `project assumption` hoặc `Verification required`; URL chính thức và ngày truy cập `2026-08-07` khi có nguồn ngoài corpus.	Chỉ Legal Owner diễn giải nghĩa vụ pháp lý; chỉ Accounting Owner diễn giải kế toán; không suy diễn điều khoản chưa kiểm chứng.
Ownership	Mỗi quyết định, dữ liệu, phê duyệt chuyên môn và hoạt động vận hành có owner rõ chưa? Không có owner thì thay đổi không có nơi quyết định cuối.	Vai trò chịu trách nhiệm nội dung, vai trò tham vấn, vai trò xác minh; giới hạn thẩm quyền Owner của artifact được nêu rõ.	`Principal IT Business Analyst / Technical Curriculum Author` chỉ quản trị artifact, không cấp approval hay baseline.
Bảo mật và riêng tư	Requirement có xác định dữ liệu cá nhân, quyền xem/sửa, mục đích xử lý, che giấu dữ liệu và điểm truyền dữ liệu chưa? Bảo mật không chỉ là đăng nhập; phải giới hạn hành động sai quyền.	Phân loại dữ liệu; actor và quyền; trường dữ liệu cần che; nhật ký thao tác; tham chiếu OWASP ASVS 5.0.0 hoặc OWASP API Security Top 10 2023 khi phù hợp.	Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP cần Legal Owner xác minh trước khi diễn đạt thành nghĩa vụ hệ thống.
Pháp lý, kế toán, hóa đơn	Requirement có vô tình biến giả định học liệu thành kết luận pháp lý, thuế, kế toán hoặc hóa đơn không? ERP có thể ghi nhận dữ liệu, nhưng ý nghĩa hạch toán thuộc thẩm quyền chuyên môn.	Nhãn `project assumption` hoặc `Verification required`; nguồn `Luật Kế toán` 88/2015/QH13 và Nghị định 123/2020/NĐ-CP khi liên quan.	Accounting Owner và Legal Owner xác minh; template không xác nhận tuân thủ hay cấu hình production.
An toàn thực phẩm và truy xuất	Nếu requirement chạm lô hàng, hạn dùng, thu hồi hoặc truy xuất, có xác định dữ liệu lô và chủ sở hữu nghiệp vụ chưa? Thiếu liên kết lô làm truy vết không thể tái dựng.	Liên kết lô nguyên liệu, lô thành phẩm, chứng từ mô phỏng và ngoại lệ; nguồn Luật An toàn thực phẩm 55/2010/QH12 được gắn `Verification required` cho diễn giải chi tiết.	Domain Owner và Legal Owner quyết định nghĩa vụ nghiệp vụ/pháp lý.
Tác động thay đổi	Khi đổi requirement, rule, trường dữ liệu, quyền hoặc tích hợp, artifact nào bị ảnh hưởng? Change impact là tập hợp phần phải xem lại để không sửa một nơi nhưng để lỗi ở nơi khác.	Danh sách requirement, rule, data field, acceptance criterion, test basis, quyền, báo cáo và nguồn bị ảnh hưởng; version và lịch sử thay đổi.	Không sửa im lặng; thay đổi sau baseline chỉ theo cơ chế kiểm soát được ghi nhận.

Quy tắc đọc kết quả: evidence chỉ chứng minh artifact có căn cứ và đủ để review. Evidence không chứng minh Nova Foods tuân thủ pháp luật, đã cấu hình ERP, đã kiểm thử production, đã baseline hoặc đã được phê duyệt.

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

Đối tượng rà soát: Tier 3 trong /03-templates/TMPL-UX-001_UX_REQUIREMENTS_SPECIFICATION.md; Nova Foods Trading & Manufacturing là case học liệu mô phỏng, chỉ dùng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Rà soát ngày 2026-08-07, trạng thái hồ sơ IN_REVIEW, phiên bản v0.9.0. Kết quả dưới đây là finding kiểm tra, không phải baseline, approval, xác nhận tuân thủ, hay cho phép triển khai production.

Mã kiểm tra	Hạng mục áp dụng	Bằng chứng và cầu nối suy luận	Kết quả	Finding và hành động trước baseline
QG-UX-001	Đủ nội dung	Tier 3 có Core Record và Evidence and Traceability theo cấu trúc tài liệu sáu phần. Mỗi UX requirement cần mục tiêu, người dùng, luồng, dữ liệu, ngoại lệ và acceptance criteria để QA kiểm tra được.	PASS có điều kiện	Giữ kiểm tra từng trường bắt buộc khi tổng hợp full file; không suy diễn trường thiếu từ ngữ cảnh.
QG-UX-002	Nhất quán quản trị	`IN_REVIEW`, `v0.9.0`, ngày `2026-08-07`, Việt Nam, `vi-VN`, `Asia/Ho_Chi_Minh`, `VND` khớp metadata corpus trong `TEMPLATE_MANIFEST`, `CHAPTER_MANIFEST` và `TRACEABILITY_ID_REGISTRY`.	PASS	Không đổi status thành `BASELINED` hoặc `APPROVED`.
QG-UX-003	Kiểm thử được	Acceptance criteria chỉ kiểm thử được khi nêu điều kiện đầu vào, thao tác, kết quả quan sát và ngoại lệ. ISTQB CTFL là nguồn thuật ngữ kiểm thử; không tự tạo kết luận test pass khi chưa có test execution.	PASS có điều kiện	QA phải lập test case từ từng acceptance criterion; kết quả chạy test nằm ngoài UX specification.
QG-UX-004	Truy vết	Liên kết phải trỏ đúng artifact canonical: `CANONICAL_BUSINESS_RULES`, `CANONICAL_DATA_DICTIONARY`, `TRACEABILITY_ID_REGISTRY` và `/00-research/00_SOURCE_MAP.md`. Artifact nguồn đang `IN_REVIEW`; vì vậy liên kết chứng minh nguồn tham chiếu, không chứng minh rule đã được xác nhận vận hành.	PASS có điều kiện	Giữ nguyên ID và đường dẫn canonical. Dừng nếu Tier 3 dùng ID không có trong registry hoặc đổi tên artifact nguồn.
QG-UX-005	Thẩm quyền nguồn	BABOK Guide dùng cho thuật ngữ BA; ISO/IEC/IEEE 29148 dùng cho khái niệm yêu cầu; WCAG 2.2 dùng cho accessibility; OWASP dùng cho thực hành bảo mật. Các nguồn này không thay Legal Owner, Accounting Owner hoặc Business Owner.	PASS có điều kiện	Không diễn đạt chuẩn quốc tế là luật Việt Nam hoặc phê duyệt nghiệp vụ Nova Foods.
QG-UX-006	Ownership	Principal IT Business Analyst / Technical Curriculum Author sở hữu tính toàn vẹn tài liệu, không có quyền chấp thuận requirement, legal, accounting, security hoặc production.	PASS	Owner tiếp tục ghi nhận finding và traceability; không ghi nhận approval thay vai trò chuyên môn.
QG-UX-007	Bảo mật và riêng tư	Luồng UX có thể xử lý thông tin người dùng hoặc dữ liệu giao dịch. Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP là nguồn pháp lý chính thức, nhưng requirement suy ra từ chúng cần Legal Owner xác minh.	ESCALATE	Gửi Legal Owner và Security Owner xác minh phân loại dữ liệu, mục đích xử lý, quyền truy cập, hiển thị và lưu vết. Không gắn nhãn compliant trước phản hồi có thẩm quyền.
QG-UX-008	Ranh giới kế toán	Giá trị tiền hiển thị bằng `VND` là dữ liệu mô phỏng. Luật 88/2015/QH13 và Nghị định 123/2020/NĐ-CP cần Accounting Owner hoặc Legal Owner diễn giải trước khi UX ảnh hưởng hạch toán, hóa đơn hoặc chứng từ.	ESCALATE	Không coi định dạng, tổng tiền hoặc trạng thái chứng từ trong case là quy tắc kế toán thật.
QG-UX-009	Ranh giới an toàn thực phẩm và truy xuất	Nova Foods là bối cảnh thực phẩm mô phỏng. Luật 55/2010/QH12 tạo bối cảnh truy xuất và thu hồi, nhưng không đủ để tự xác nhận trường dữ liệu, thời hạn lưu hay quy trình vận hành.	ESCALATE	Gửi Domain Owner và Legal Owner xác minh mọi yêu cầu liên quan lô hàng, truy xuất hoặc thu hồi.
QG-UX-010	Ảnh hưởng thay đổi	Sửa UX requirement có thể ảnh hưởng rule, data field, API, test case, quyền truy cập và tài liệu đào tạo. Traceability là cầu nối phát hiện ảnh hưởng trước thay đổi.	PASS có điều kiện	Mọi sửa đổi phải rà `TRACEABILITY_ID_REGISTRY`, `CANONICAL_BUSINESS_RULES`, `CANONICAL_DATA_DICTIONARY` và test basis liên quan.

Kết luận ghi nhận: Không có finding FAIL từ metadata và source boundary đã cung cấp. Ba finding ESCALATE giữ hồ sơ ở IN_REVIEW: QG-UX-007, QG-UX-008, QG-UX-009. Không chuyển baseline, không ghi approval, không dùng nội dung này làm quyết định pháp lý, kế toán, bảo mật hoặc vận hành Nova Foods thực tế.

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

6.1 Ma trận kiểm tra chéo

Kiểm tra chéo xác nhận cùng một sự thật quản trị giữa các tệp kiểm soát trước khi bàn giao. Manifest là danh mục có thẩm quyền về tệp và phạm vi; ID registry là danh mục định danh canonical; catalog rule và data dictionary là nguồn cho quy tắc và dữ liệu. Nếu UX specification ghi khác nguồn này, UX specification phải sửa hoặc giữ trạng thái cần xác minh; không được tự tạo nguồn chân lý thứ hai.

Điểm kiểm tra	Nguồn canonical phải đối chiếu	Giá trị phải khớp trong `TMPL-UX-001`	Kết quả kiểm tra tại `v0.9.0`	Quy tắc xử lý mâu thuẫn
Danh mục template và tên tệp	`/01-curriculum/TEMPLATE_MANIFEST.md`	Template ID `TMPL-UX-001`; tệp `/03-templates/TMPL-UX-001_UX_REQUIREMENTS_SPECIFICATION.md`; phạm vi UX requirements specification	Không thấy mâu thuẫn trong đầu vào đã cung cấp.	Manifest thắng. Không đổi ID, tên tệp hoặc phạm vi bằng nội dung UX.
Danh mục chapter liên quan	`/01-curriculum/CHAPTER_MANIFEST.md`	UX requirement chỉ liên kết chapter đã được manifest quản lý; không biến template thành chapter hoặc yêu cầu production	Không có bằng chứng trong đầu vào cho phép gán chapter ID mới.	Không thêm chapter ID, dependency hoặc tên chapter chưa có trong manifest.
Định danh truy vết	`/01-curriculum/TRACEABILITY_ID_REGISTRY.md`	ID requirement, rule, data, API, test, security và traceability phải dùng ID đã đăng ký	Registry là nguồn duy nhất để xác minh ID canonical.	ID chưa đăng ký không được dùng như ID chính thức; giữ nhãn cần xác minh tại điểm tham chiếu.
Quy tắc nghiệp vụ	`/01-curriculum/CANONICAL_BUSINESS_RULES.md`	UX hiển thị, ràng buộc nhập liệu, trạng thái và thông báo lỗi không được đổi nghĩa business rule	Catalog đang `IN_REVIEW`; không xác nhận rule Nova Foods vận hành thật.	Catalog thắng. UX chỉ diễn đạt trải nghiệm của rule đã có, không tự lập rule mới.
Dữ liệu logic	`/01-curriculum/CANONICAL_DATA_DICTIONARY.md`	Tên trường, nghĩa dữ liệu, kiểu logic, phân loại và quan hệ dữ liệu	Dictionary là nguồn canonical cho nghĩa dữ liệu; UX không phải đặc tả schema triển khai.	Dictionary thắng. Không suy diễn cột DB, payload API hoặc retention từ màn hình.
Metadata corpus	`/00-research/00_SOURCE_MAP.md`, `/01-curriculum/01_CURRICULUM_ARCHITECTURE.md`	`IN_REVIEW`, `v0.9.0`, ngày `2026-08-07`, `vi-VN`, `Asia/Ho_Chi_Minh`, `VND`, Nova Foods mô phỏng, dữ liệu tổng hợp	Khớp contract micro-batch.	Metadata nguồn thắng; không gọi nội dung là baseline, approved, compliant hoặc production-ready.
Consumer hạ nguồn	Test basis, API specification, UI build, training material và QA evidence có liên kết traceability hợp lệ	Consumer chỉ dùng requirement đã truy vết tới rule, data và nguồn phù hợp	Không có đầu vào xác nhận consumer nào đã được phê duyệt hoặc triển khai.	Consumer không được suy diễn quyết định pháp lý, kế toán, bảo mật hay vận hành từ UX template.

6.2 Tiêu chí phát hiện mâu thuẫn

Mâu thuẫn tồn tại khi cùng một ID có hai nghĩa khác nhau, cùng một data field có hai tên hoặc phân loại khác nhau, UX yêu cầu hành vi trái canonical business rule, hoặc consumer dùng nội dung IN_REVIEW như quyết định đã phê duyệt. Ví dụ, màn hình ghi số tiền VND chỉ là dữ liệu tổng hợp của Nova Foods mô phỏng; suy ra quy tắc hạch toán, hóa đơn hoặc thuế từ cách hiển thị này là mâu thuẫn thẩm quyền. Bằng chứng là /01-curriculum/01_CURRICULUM_ARCHITECTURE.md và các artifact canonical đều giới hạn Owner, không trao quyền kế toán, pháp lý hoặc production.

6.3 Kết quả kiểm tra phạm vi micro-batch

Không có mâu thuẫn metadata hoặc source boundary trong tập đầu vào đã cung cấp. Tuy vậy, kết quả này không xác nhận đầy đủ nội dung của TMPL-UX-001 vì TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY được cung cấp dưới dạng dependency rút gọn, không chứa toàn bộ bản ghi ID, rule và field để đối chiếu từng dòng. Vì vậy, mọi liên kết UX cụ thể phải được kiểm tra lại với bản controlled đầy đủ tại các đường dẫn canonical trước khi consumer hạ nguồn dùng làm test basis hoặc build input.

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

Sổ này ghi nhận các điểm chưa đủ bằng chứng để biến thành yêu cầu UX (User Experience, trải nghiệm người dùng) có tính bắt buộc. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp. IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND vẫn áp dụng. Không dòng nào xác nhận phê duyệt, baseline, tuân thủ pháp lý, cấu hình ERP hay quyền đưa vào production.

Loại	ID bị ảnh hưởng	Nội dung và cầu nối bằng chứng	Owner quyết định	Tác động nếu chưa xử lý	Hành động kế tiếp
Vấn đề mở	`TMPL-UX-001`, `TRACEABILITY_ID_REGISTRY`	Chưa có bằng chứng trong đầu vào đã cung cấp về tập ID yêu cầu UX cấp trường, màn hình, hành trình hay tiêu chí chấp nhận dành riêng cho `TMPL-UX-001`. Registry là nguồn canonical cho ID; template không được tự tạo ID rồi coi là đã đăng ký.	Principal IT Business Analyst / Technical Curriculum Author ghi gói vấn đề; Owner của registry xác nhận đăng ký; Business Owner xác nhận ý nghĩa nghiệp vụ khi có nội dung case.	Traceability từ UX sang rule, data, test có thể đứt hoặc trùng ID.	Lập yêu cầu đăng ký ID trong `/01-curriculum/TRACEABILITY_ID_REGISTRY.md`; chỉ liên kết ID đã tồn tại và còn `IN_REVIEW`.
Vấn đề mở	`TMPL-UX-001`, `CANONICAL_BUSINESS_RULES`	Chưa có quy tắc Nova Foods đã được chủ thể nghiệp vụ xác nhận về quyền đổi trạng thái, ngoại lệ phê duyệt, thời hạn giữ dữ liệu, hay điều kiện chặn thao tác. Catalog rule nêu rõ Owner tài liệu không được xác nhận quy tắc vận hành thực.	Business Owner cho quy tắc nghiệp vụ; Legal Owner, Accounting Owner, Security hoặc Architect tham gia khi rule chạm thẩm quyền tương ứng.	UI có thể hiển thị nút, cảnh báo hoặc luồng xác nhận sai thẩm quyền.	Giữ nội dung UX ở mức mô tả học liệu; gắn từng rule chưa xác minh là `Verification required`; không diễn đạt thành bắt buộc vận hành.
Vấn đề mở	`TMPL-UX-001`, `CANONICAL_DATA_DICTIONARY`	Chưa có bằng chứng về thuộc tính dữ liệu canonical cho người dùng, chứng từ, lô hàng, khách hàng hay phân loại dữ liệu cá nhân trong phạm vi UX này. Data dictionary là nguồn định nghĩa logic; template UX không thay thế dictionary.	Data Owner xác nhận nghĩa, nguồn và chất lượng dữ liệu; Security Owner xác nhận phân loại và hiển thị; Architect xác nhận khả năng kỹ thuật.	Nhãn trường, định dạng ngày giờ, số tiền `VND`, lỗi nhập liệu và che dữ liệu có thể không nhất quán.	Chỉ dùng ví dụ tổng hợp đã ghi rõ mô phỏng; đối chiếu từng trường với `/01-curriculum/CANONICAL_DATA_DICTIONARY.md` trước khi đưa vào Tier 3.
Giả định dự án	`TMPL-UX-001`	Giả định người học đọc tiếng Việt theo `vi-VN`, xem thời điểm theo `Asia/Ho_Chi_Minh`, và xem tiền mô phỏng bằng `VND`. Cầu nối bằng chứng: metadata corpus thống nhất ba giá trị này. Giả định này là ngữ cảnh học liệu, không xác nhận locale cấu hình ERP thật.	Principal IT Business Analyst / Technical Curriculum Author duy trì nhãn; Business Owner và Architect xác minh nếu chuyển thành sản phẩm thật.	Ví dụ UX có thể bị dùng nhầm như quyết định quốc tế hóa hoặc cấu hình production.	Ghi rõ ngữ cảnh tại mọi ví dụ Tier 3; mở xác minh kiến trúc nếu xuất hiện múi giờ, ngôn ngữ hoặc tiền tệ khác.
Giả định dự án	`TMPL-UX-001`, `WCAG 2.2`	Giả định accessibility (khả năng tiếp cận) là tiêu chí thiết kế cần xem xét. Bằng chứng: WCAG 2.2 là nguồn chuẩn khuyến nghị trong source seed. Không có bằng chứng hiện có cho mức tuân thủ, phạm vi đối tượng dùng hay tiêu chí thành công cụ thể của Nova Foods.	Accessibility/UX Owner; Architect xác nhận nền tảng; QA Owner xác nhận cách kiểm thử.	Câu chữ có thể bị hiểu sai thành tuyên bố đạt chuẩn WCAG.	Mô tả nhu cầu như khả năng kiểm thử; chỉ nêu tiêu chí WCAG cụ thể sau khi đối chiếu văn bản nguồn và xác định phạm vi.
Mục cần xác minh	`TMPL-UX-001`, `Luật 91/2025/QH15`, `Nghị định 356/2025/NĐ-CP`	UX có thể xử lý dữ liệu cá nhân qua tên, số điện thoại, địa chỉ hoặc lịch sử giao dịch mô phỏng. Source seed xác nhận nguồn luật và nghị định, nhưng nêu rõ mọi requirement suy ra cần Legal Owner xác minh.	Legal Owner quyết định diễn giải; Privacy Owner và Security Owner xác nhận biện pháp; BA giữ traceability.	Hiển thị, tìm kiếm, tải xuống hoặc che dữ liệu có thể thành yêu cầu pháp lý suy diễn.	Gắn `Verification required` cho mọi yêu cầu privacy; chuyển gói gồm mục đích xử lý, vai trò truy cập, loại dữ liệu và luồng UX cho Legal Owner.
Mục cần xác minh	`TMPL-UX-001`, `Luật 88/2015/QH13`, `Nghị định 123/2020/NĐ-CP`	Nếu UX hiển thị hóa đơn, chứng từ, giá trị tiền hoặc trạng thái hạch toán, cách gọi và hành vi phải do Accounting Owner xác nhận. Source seed không cấp diễn giải kế toán hay xác nhận sửa đổi pháp lý hiện hành.	Accounting Owner; Legal Owner xác minh hiệu lực văn bản; Business Owner xác nhận luồng nghiệp vụ.	Màn hình có thể tạo ấn tượng sai về chứng từ hợp lệ, khóa sổ hoặc nghĩa vụ hóa đơn.	Không gán ý nghĩa pháp lý cho ví dụ chứng từ tổng hợp; lập xác minh riêng trước khi tạo acceptance criteria liên quan.
Mục cần xác minh	`TMPL-UX-001`, `Luật 55/2010/QH12`	Nếu UX mô tả truy xuất lô, thu hồi hoặc cảnh báo an toàn thực phẩm, nguồn luật chỉ hỗ trợ bối cảnh. Source seed yêu cầu Domain Owner và Legal Owner xác minh.	Food Safety Domain Owner; Legal Owner; Business Owner.	Luồng UX mô phỏng có thể bị hiểu sai là quy trình thu hồi thực tế.	Giữ nhãn mô phỏng và dữ liệu tổng hợp; chuyển danh sách trạng thái lô, bằng chứng truy xuất và điều kiện cảnh báo cho xác minh chuyên ngành.
Mục cần xác minh	`TMPL-UX-001`, `OWASP ASVS 5.0.0`, `OWASP API Security Top 10 2023`	Các hành vi UX như phân quyền, hết phiên, lỗi truy cập, tải tệp và thông báo lỗi có tác động bảo mật. OWASP là good practice ngành, không phải luật Việt Nam và không tự tạo yêu cầu kiến trúc.	Security Owner quyết định kiểm soát; Architect xác nhận thiết kế; QA Owner xác nhận kiểm thử.	UI có thể che giấu lỗi bảo mật hoặc hứa hẹn kiểm soát không có ở API.	Chỉ ghi rủi ro và câu hỏi xác minh; không cam kết cơ chế xác thực, phân quyền hay mã hóa khi chưa có quyết định chuyên môn.

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

Bàn giao có kiểm soát là chuyển gói thông tin cho vai trò hoặc artifact kế tiếp mà không biến nội dung đang xem xét thành quyết định đã phê duyệt. /03-templates/TMPL-UX-001_UX_REQUIREMENTS_SPECIFICATION.md giữ IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND; Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Không người nhận nào được suy diễn trạng thái này là baseline, approval, cấu hình ERP, xác nhận tuân thủ, hoặc quyền triển khai production.

Thành phần bàn giao	Nội dung bắt buộc	Người nhận dùng để làm gì	Ranh giới thẩm quyền
UX requirements specification	Màn hình, luồng người dùng, tiêu chí chấp nhận, ngoại lệ, liên kết truy vết đã ghi trong `TMPL-UX-001`	Architect đánh giá khả thi; QA lập test basis; Business Owner review giá trị nghiệp vụ	Không tự xác nhận yêu cầu đúng cho vận hành thực
`TRACEABILITY_ID_REGISTRY`	ID canonical và quan hệ truy vết	Kiểm tra ID không bị đổi nghĩa, tái dùng sai, hoặc tạo biến thể	Registry Owner không phê duyệt nghiệp vụ, pháp lý, kế toán, bảo mật
`CANONICAL_BUSINESS_RULES`	Nguồn quy tắc nghiệp vụ được liên kết	Đối chiếu hành vi UX với quy tắc	Business Owner quyết định nghiệp vụ; Legal, Accounting xác nhận phạm vi chuyên môn
`CANONICAL_DATA_DICTIONARY`	Tên trường logic, kiểu dữ liệu, nghĩa dữ liệu	Đối chiếu nhãn, nhập liệu, hiển thị, kiểm tra dữ liệu UX	Architect quyết định thiết kế kỹ thuật; Data Owner xác nhận nghĩa dữ liệu
Downstream consumer	Test case, backlog kỹ thuật, thiết kế API, thiết kế UI, tài liệu đào tạo khi được tạo	Nhận liên kết truy vết, không sao chép thành nguồn chân lý mới	Consumer không được sửa ngược requirement mà không có thay đổi được ghi nhận

Quy tắc nguồn chân lý: TMPL-UX-001 mô tả nhu cầu và hành vi UX; không thay thế CANONICAL_BUSINESS_RULES cho quy tắc, CANONICAL_DATA_DICTIONARY cho dữ liệu, TRACEABILITY_ID_REGISTRY cho ID, hay nguồn luật và chuẩn cho diễn giải chuyên môn. Nếu hai artifact khác nhau, người soạn không chọn theo cảm tính. Ghi nhận mâu thuẫn, giữ nguyên ID hiện có, chuyển gói bằng chứng cho Owner và vai trò có thẩm quyền.

Loại thay đổi	Hành động lan truyền bắt buộc	Vai trò quyết định	Điều cấm
Đổi ID hoặc quan hệ truy vết	Cập nhật trước tại `TRACEABILITY_ID_REGISTRY`; sau đó cập nhật mọi liên kết trong `TMPL-UX-001` và consumer	Registry Owner quản trị ID; Owner điều phối	Không đổi chuỗi ID cũ bằng sửa im lặng
Đổi quy tắc nghiệp vụ	Cập nhật hoặc xác minh tại `CANONICAL_BUSINESS_RULES`; đánh giá lại màn hình, luồng, tiêu chí chấp nhận, test basis	Business Owner; Legal, Accounting, Compliance khi thuộc phạm vi	Không biến giả định thành quy tắc bắt buộc
Đổi nghĩa, kiểu, phân loại dữ liệu	Cập nhật hoặc xác minh tại `CANONICAL_DATA_DICTIONARY`; rà soát trường nhập, hiển thị, quyền truy cập, API và kiểm thử	Data Owner, Architect, Security khi phù hợp	Không tự suy diễn dữ liệu thật Nova Foods
Đổi UI hoặc luồng nhưng không đổi rule/data	Cập nhật `TMPL-UX-001`, liên kết truy vết và consumer bị ảnh hưởng	Business Owner xác nhận giá trị; Architect đánh giá khả thi; QA đánh giá kiểm thử	Không gọi thay đổi là approved
Nội dung có pháp lý, thuế, kế toán, an toàn thực phẩm, riêng tư hoặc bảo mật	Giữ nhãn `Verification required` hoặc `Project assumption`; chuyển đúng Owner chuyên môn	Legal, Accounting, Compliance, Security, domain owner	Không diễn giải nguồn thành nghĩa vụ production

Mỗi thay đổi phải ghi: artifact nguồn, ID bị ảnh hưởng, lý do và bằng chứng, artifact nhận lan truyền, người điều phối, thời điểm theo Asia/Ho_Chi_Minh, trạng thái xác minh, và quyết định của đúng thẩm quyền khi có. “Lan truyền” nghĩa là kiểm tra ảnh hưởng rồi cập nhật liên kết hoặc ghi rõ không ảnh hưởng; không nghĩa là sao chép nguyên văn sang mọi tệp.

Handoff hoàn tất kỹ thuật khi gói bàn giao có đường dẫn canonical, phiên bản, trạng thái IN_REVIEW, liên kết truy vết và nhãn xác minh còn hiệu lực. Handoff không tạo baseline hay approval. Chỉ artifact kiểm soát có tham chiếu baseline hoặc approval được ghi nhận minh bạch mới được dùng các trạng thái đó.