Bản đồ Artifact Vòng đời

Trường kiểm soát	Giá trị	Diễn giải kiểm soát
Artifact ID	`LIFECYCLE_ARTIFACT_MAP`	Định danh quản trị duy nhất của bản đồ artifact này. Dùng định danh này khi tham chiếu hoặc kiểm tra tính nhất quán giữa các tài liệu.
Tên tệp	`/04-cheatsheets/lifecycle-artifact-map.md`	Đường dẫn canonical (chính thức, duy nhất) của artifact trong corpus tài liệu đào tạo Nova Foods.
Tiêu đề	Bản đồ Artifact Vòng đời	Tên đầy đủ, mô tả mục đích chính của tài liệu là cung cấp một bản đồ tham khảo nhanh về các artifact.
Trạng thái	`IN_REVIEW`	Artifact đang trong quá trình xem xét có kiểm soát và có thể được cập nhật. Trạng thái này không có nghĩa là `APPROVED` (đã phê duyệt), `BASELINED` (đã chuẩn hóa), sẵn sàng cho sản xuất (production-ready), hoặc đã được người dùng chấp thuận.
Phiên bản	`v0.9.0`	Phiên bản kế hoạch hiện hành của artifact tại ngày ghi nhận metadata này. Mọi thay đổi sau đó phải được ghi nhận rõ ràng vào lịch sử phiên bản.
Owner	Principal IT Business Analyst / Technical Curriculum Author	Chủ sở hữu chịu trách nhiệm chính về tính chính xác của bản đồ artifact, quản lý định danh, phiên bản, trạng thái, và các liên kết quản trị.
Trách nhiệm của Owner	Duy trì tính nhất quán, khả năng truy vết của bản đồ artifact. Đảm bảo ánh xạ đúng giữa các artifact khác nhau trong corpus Nova Foods và quản lý lịch sử thay đổi của bản đồ.
Giới hạn thẩm quyền Owner	Owner không có quyền tự thiết lập baseline, ghi nhận approval (phê duyệt), xác nhận nội dung nghiệp vụ, giải thích pháp lý, ra quyết định kế toán, hoặc cấp phép triển khai production cho bất kỳ artifact nào được ánh xạ trong bản đồ.
Last updated date	`2026-08-07`	Ngày cập nhật gần nhất của metadata, được diễn giải theo múi giờ quản trị của toàn bộ corpus.
Múi giờ quản trị	`Asia/Ho_Chi_Minh`	Múi giờ chuẩn được sử dụng để ghi nhận thời điểm thay đổi, đánh giá (review) và các bằng chứng quản trị liên quan đến artifact.
Locale áp dụng	`vi-VN`	Ngôn ngữ chính của nội dung là tiếng Việt. Bối cảnh áp dụng là Việt Nam. Đơn vị tiền tệ mô phỏng cho case study là `VND` (Đồng Việt Nam).
Case study tham chiếu	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, chỉ sử dụng dữ liệu tổng hợp.	Mọi tham chiếu đến Nova Foods đều là giả định cho mục đích học tập và đào tạo. Không phản ánh hoạt động kinh doanh thực tế, cấu hình ERP thực tế hoặc tính tuân thủ pháp lý của một doanh nghiệp có thật.
Phân loại artifact	Cheatsheet / Reference Map	Loại tài liệu này là một "cheatsheet" (tài liệu tóm tắt nhanh) và "reference map" (bản đồ tham chiếu). Nó cung cấp cái nhìn tổng quan về cấu trúc và mối quan hệ của các artifact khác.
Trạng thái baseline	Chưa có baseline reference tại `v0.9.0`.	Trạng thái `IN_REVIEW` không được diễn giải là `BASELINED` (đã chuẩn hóa). Việc baseline yêu cầu một quy trình phê duyệt riêng và rõ ràng.
Trạng thái phê duyệt	Chưa có approval reference tại `v0.9.0`.	Sự tồn tại của Owner hoặc metadata không tạo ra sự phê duyệt ngầm định từ bất kỳ bên liên quan nào (như Business Owner, Legal, Accounting, QA, Architect).
Nguồn gốc dữ liệu	Tích hợp từ các artifact quản trị khác trong corpus (ví dụ: `CHAPTER_MANIFEST.md`, `TRACEABILITY_ID_REGISTRY.md`).	Bản đồ này tổng hợp và ánh xạ thông tin từ nhiều nguồn được kiểm soát khác trong cùng bộ tài liệu.
Mục đích sử dụng	Cung cấp cái nhìn tổng quan có cấu trúc về các artifact chính và mối liên hệ của chúng qua vòng đời dự án giả định Nova Foods.	Dùng làm tài liệu tham khảo nhanh cho người học, giúp định vị và hiểu bối cảnh của các artifact khác trong chương trình đào tạo.
Giới hạn sử dụng	Không thay thế nội dung chi tiết của từng artifact được ánh xạ. Không phải tài liệu phê duyệt pháp lý, kế toán, nghiệp vụ hoặc kỹ thuật.	Bản đồ này chỉ là một công cụ dẫn hướng và tham khảo. Nó không tự nó chứa đựng các quyết định nghiệp vụ hoặc kỹ thuật cuối cùng, hoặc các cam kết pháp lý.

1. Purpose, Scope, and Governance

Đối tượng, Ranh giới Sử dụng và Nguồn Tham chiếu

Đối tượng (Audience) của tài liệu

Tài liệu này hướng dẫn học viên Business Analyst (BA) và các vai trò liên quan trong môi trường giáo dục mô phỏng Nova Foods. Mục đích chính: giúp hiểu cấu trúc artifact, nguồn gốc thông tin.

Đối tượng	Mục đích sử dụng	Ghi chú
Học viên BA	Nắm cấu trúc tài liệu BA, hiểu quy trình tạo artifact, học cách truy vết nguồn.	Tập trung thực hành, hiểu nguyên lý.
Business Analyst	Tra cứu nhanh artifact theo loại, theo pha, kiểm tra dependency.	Nâng cao hiệu suất tìm kiếm, đảm bảo tính nhất quán.
Quality Assurance (QA)	Xác định nguồn kiểm thử, đối chiếu yêu cầu với artifact liên quan.	Hỗ trợ lập kế hoạch kiểm thử, truy vết yêu cầu.
Phát triển viên (Developer)	Hiểu bối cảnh nghiệp vụ, nguồn gốc yêu cầu, dữ liệu.	Giảm thiểu hiểu lầm yêu cầu, tăng chất lượng triển khai.
Quản lý dự án	Kiểm soát phạm vi tài liệu, tiến độ, dependency giữa các artifact.	Tối ưu hóa quy hoạch, phân bổ nguồn lực.

Ranh giới sử dụng và không sử dụng (Use/Not-Use Boundary)

Tài liệu này là bản đồ tra cứu. Không phải tài liệu ra quyết định.

Ranh giới	Diễn giải
Sử dụng để	Tra cứu vị trí artifact, hiểu mối quan hệ giữa các loại artifact, xác định nguồn gốc chuẩn tắc (canonical source) cho thông tin, nắm cơ chế quản trị metadata, truy vết ID artifact.
Không sử dụng để	Đưa ra quyết định pháp lý, kế toán, vận hành thực tế cho Nova Foods. Không thay thế phê duyệt (approval) nghiệp vụ, kỹ thuật hay pháp lý. Không được diễn giải là tài liệu phê duyệt (baseline) chính thức. Không phải tài liệu triển khai sản phẩm (production deployment).

Nguồn tham chiếu (Sources)

Mọi nguồn được liệt kê và giới hạn sử dụng tại /00-research/00_SOURCE_MAP.md. Bản đồ artifact này chỉ tham chiếu nguồn đó.

Loại nguồn	Mục đích	Giới hạn
Pháp lý (Legal)	Nền tảng luật, nghị định Việt Nam (VD: Luật Bảo vệ dữ liệu cá nhân).	Chỉ dùng khi có chỉ định rõ. Cần xác minh bởi chủ sở hữu pháp lý (Legal Owner) trước mọi quyết định. Nova Foods: mô phỏng.
Chuẩn ngành (Industry Standard)	Định nghĩa, kiến thức chung (VD: BABOK, ISO/IEC/IEEE 29148).	Dùng cho khái niệm, quy trình. Không suy diễn thành yêu cầu bắt buộc khi thiếu bối cảnh cụ thể Nova Foods.
Thực hành tốt (Good Practice)	Hướng dẫn, khuyến nghị (VD: OWASP ASVS, OWASP API Security Top 10).	Chỉ là gợi ý. Không phải yêu cầu bắt buộc hay cam kết tuân thủ.
Đặc tả kỹ thuật (Technical Specification)	Quy định cách thức triển khai (VD: OpenAPI Specification, UML, BPMN).	Hướng dẫn chi tiết kỹ thuật. Không tự ý sửa đổi khi dùng.

Điều hướng (Navigation)

Tra cứu artifact qua ID chuẩn. ID quản trị là nguồn duy nhất.

Mục điều hướng	Nguồn quản trị	Lý do
ID artifact	`/01-curriculum/TRACEABILITY_ID_REGISTRY.md`	Định danh chuẩn, duy nhất. Đảm bảo truy vết.
Cấu trúc chương	`/01-curriculum/CHAPTER_MANIFEST.md`	Bản đồ chương, thứ tự học.
Danh mục template	`/01-curriculum/TEMPLATE_MANIFEST.md`	Liệt kê template mẫu, mục đích.
Quy tắc nghiệp vụ	`/01-curriculum/CANONICAL_BUSINESS_RULES.md`	Nguồn duy nhất cho quy tắc nghiệp vụ Nova Foods mô phỏng.
Từ điển dữ liệu	`/01-curriculum/CANONICAL_DATA_DICTIONARY.md`	Định nghĩa dữ liệu chuẩn.

Nova Foods là case study mô phỏng. Mọi dữ liệu là tổng hợp.

Mô hình Nova Foods: Mô phỏng và Giới hạn Thẩm quyền

Trong chương trình đào tạo này, "Nova Foods Trading & Manufacturing" là một mô hình nghiên cứu tình huống (case study) được xây dựng hoàn toàn cho mục đích giáo dục. Đây không phải một doanh nghiệp có thật, đang hoạt động hoặc có bất kỳ hệ thống ERP (Enterprise Resource Planning - Hệ thống hoạch định nguồn lực doanh nghiệp) thực tế nào. Mọi dữ liệu liên quan đến Nova Foods, từ thông tin sản phẩm, quy trình kinh doanh, đến các giao dịch tài chính, đều là dữ liệu tổng hợp (synthetic data) và được tạo ra để phục vụ việc học tập, thực hành kỹ năng Phân tích Nghiệp vụ (Business Analysis - BA) trong một môi trường an toàn và không rủi ro.

Mục tiêu chính của việc sử dụng mô hình Nova Foods là cung cấp một bối cảnh kinh doanh đủ phức tạp và thực tế để học viên có thể áp dụng các kiến thức và kỹ thuật BA đã học. Điều này cho phép học viên phân tích yêu cầu, thiết kế giải pháp và hiểu rõ các ràng buộc nghiệp vụ mà không phải đối mặt với các hậu quả pháp lý, tài chính hoặc vận hành của một dự án thật.

Vì Nova Foods là một mô phỏng, các giới hạn thẩm quyền (authority limits) cần được hiểu rõ:

Khía cạnh	Mô hình Nova Foods trong Khóa học	Ý nghĩa Thực tế ngoài Khóa học	Lý do thiết lập giới hạn
Bản chất doanh nghiệp	Một tình huống mô phỏng để học BA.	Không tồn tại như một pháp nhân kinh doanh.	Ngăn ngừa hiểu lầm về thực thể kinh doanh, tránh các cam kết hoặc diễn giải pháp lý không có thật.
Dữ liệu kinh doanh	Hoàn toàn là dữ liệu tổng hợp (synthetic data).	Không đại diện cho thông tin tài chính, khách hàng hoặc vận hành thực.	Bảo vệ quyền riêng tư, tránh rủi ro bảo mật dữ liệu, và đảm bảo mọi phân tích dựa trên dữ liệu phi nhạy cảm.
Quyết định nghiệp vụ	Các quyết định được đưa ra trong quá trình học là giả định (assumption) và dùng để thực hành.	Không có giá trị ràng buộc pháp lý, kế toán, nghiệp vụ hoặc quyền phê duyệt sản xuất (production approval).	Đảm bảo tính an toàn cho người học khi khám phá các phương án giải pháp mà không cần sự xác nhận của các chuyên gia thực tế (Legal, Accounting, Business Owner).
Quy trình/Quy định	Được thiết kế dựa trên các nguyên tắc chung và nguồn tham khảo đã được xác minh (như BABOK Guide, ISO/IEC/IEEE 29148, luật pháp Việt Nam) để làm nền tảng.	Không phải là quy trình nghiệp vụ thực tế của một công ty nào, và không đảm bảo tuân thủ (compliance) trong môi trường sản xuất.	Hướng dẫn học viên cách diễn giải và áp dụng các tiêu chuẩn ngành, nhưng không đặt gánh nặng về việc xác minh hoặc tuân thủ thực tế cho người học hoặc tài liệu.
Thẩm quyền phê duyệt	Chủ biên chương trình đào tạo có thẩm quyền về cấu trúc, nội dung giáo dục và tính nhất quán của tài liệu này.	Chủ biên không có thẩm quyền phê duyệt pháp lý, kế toán, kiến trúc kỹ thuật hoặc vận hành sản xuất cho bất kỳ doanh nghiệp nào, kể cả Nova Foods nếu nó có thật.	Phân biệt rõ vai trò giáo dục với vai trò ra quyết định thực tế, tránh tạo ra tiền lệ sai hoặc kỳ vọng không chính xác về quyền hạn.

Mọi phân tích, đề xuất hoặc thiết kế giải pháp được trình bày trong chương trình này đều phải được hiểu trong bối cảnh mô phỏng giáo dục. Việc học viên sử dụng các tài liệu này để phát triển kỹ năng BA không tạo ra bất kỳ quyền hạn nào để đưa ra các quyết định có ảnh hưởng đến hoạt động kinh doanh, tài chính, pháp lý hoặc bảo mật trong môi trường thực tế. Mục đích duy nhất là trang bị kiến thức và kinh nghiệm thực hành, giúp học viên chuẩn bị tốt hơn cho vai trò Phân tích Nghiệp vụ trong tương lai, nơi các quyết định thực tế luôn yêu cầu sự xác nhận từ các bên liên quan có thẩm quyền (Business Owner, Legal, Accounting, Technical Architect, Security, QA).

2. Core Reference Map

Phần này định nghĩa các tạo phẩm (artifact) cốt lõi mà một Chuyên viên Phân tích nghiệp vụ (Business Analyst - BA) thường xuyên sử dụng trong vòng đời dự án. Mỗi tạo phẩm có một mục đích và liên kết với các tiêu chuẩn ngành hoặc nguồn chính thức. Các tham chiếu đến Nova Foods là trong bối cảnh mô phỏng giáo dục, dữ liệu tổng hợp.

Tạo phẩm chính	Thuật ngữ Tiếng Anh	Giải thích cơ bản (Tiếng Việt)	Mục đích BA chính	Tham chiếu tiêu chuẩn/nguồn chính
Yêu cầu	Requirement	Yêu cầu là một điều kiện hoặc khả năng cần thiết mà hệ thống (system) phải có để giải quyết vấn đề nghiệp vụ hoặc đạt được mục tiêu của các bên liên quan (stakeholder). Yêu cầu mô tả mong muốn của người dùng hoặc các điều kiện hoạt động của một giải pháp (solution).	Xác định rõ ràng phạm vi (scope) của dự án và giải pháp. Đảm bảo mọi tính năng, chức năng (functional) và thuộc tính phi chức năng (non-functional) như hiệu suất, bảo mật, khả năng mở rộng, khả năng sử dụng đều được ghi nhận đầy đủ và chính xác.	BABOK Guide (Knowledge Area: Requirements Analysis and Design Definition); ISO/IEC/IEEE 29148 (tiêu chuẩn quốc tế về kỹ thuật yêu cầu hệ thống và phần mềm).
Quy tắc nghiệp vụ	Business Rule	Quy tắc nghiệp vụ là một tuyên bố (statement) định nghĩa hoặc hạn chế một khía cạnh của nghiệp vụ (business). Chúng có thể là chính sách công ty, luật pháp, quy định của ngành, hoặc công thức tính toán. Ví dụ: "Khách hàng phải đủ 18 tuổi để mua rượu".	Đảm bảo tính nhất quán (consistency) và tuân thủ (compliance) trong cách thức vận hành nghiệp vụ. Phản ánh chính sách tổ chức, luật pháp (như Luật Bảo vệ dữ liệu cá nhân của Việt Nam) và các quy định ngành, định hướng cho thiết kế hệ thống.	BABOK Guide (Knowledge Area: Requirements Analysis and Design Definition); `01-curriculum/CANONICAL_BUSINESS_RULES.md` (kế hoạch danh mục quy tắc nội bộ Nova Foods mô phỏng); các luật pháp liên quan của Việt Nam (ví dụ: Luật Bảo vệ dữ liệu cá nhân, Luật Kế toán).
Mô hình quy trình	Process Model	Mô hình quy trình là một biểu diễn đồ họa hoặc mô tả có cấu trúc về một chuỗi các hoạt động (activities) hoặc bước công việc trong nghiệp vụ. Chúng cho thấy ai làm gì, khi nào, và theo trình tự nào.	Hiểu rõ quy trình nghiệp vụ hiện tại (As-Is) và thiết kế quy trình mới hoặc cải tiến (To-Be). Giúp xác định các điểm tắc nghẽn, cơ hội tối ưu hóa, làm rõ trách nhiệm, và là nền tảng cho việc tự động hóa.	BPMN 2.0.2 (Business Process Model and Notation) để mô hình hóa quy trình nghiệp vụ theo tiêu chuẩn quốc tế; BABOK Guide (Kỹ thuật: Mô hình hóa quy trình); UML (Activity Diagrams).
Mô hình dữ liệu	Data Model	Mô hình dữ liệu là một cấu trúc trừu tượng (abstract structure) tổ chức các yếu tố dữ liệu (data elements) và mối quan hệ giữa chúng. Nó xác định loại dữ liệu nào được thu thập, lưu trữ, và cách chúng liên kết với nhau.	Xác định cấu trúc dữ liệu cần thiết để hỗ trợ các yêu cầu nghiệp vụ. Đảm bảo dữ liệu được thu thập, lưu trữ, và sử dụng một cách nhất quán, chính xác, hiệu quả, tránh dư thừa và hỗ trợ phân tích.	UML 2.5.1 (Class Diagrams, Component Diagrams); BABOK Guide (Kỹ thuật: Mô hình hóa dữ liệu); `01-curriculum/CANONICAL_DATA_DICTIONARY.md` (kế hoạch từ điển dữ liệu logic nội bộ Nova Foods mô phỏng).
Trường hợp sử dụng / Câu chuyện người dùng	Use Case / User Story	Trường hợp sử dụng (Use Case): Mô tả cách một người dùng (actor) tương tác với hệ thống để đạt được một mục tiêu cụ thể. Câu chuyện người dùng (User Story): Một mô tả ngắn gọn, đơn giản về một tính năng từ góc độ của người dùng cuối, thường theo cấu trúc "Với tư cách là [người dùng], tôi muốn [mục tiêu] để [lợi ích]".	Ghi nhận yêu cầu chức năng (functional requirements) theo cách dễ hiểu cho cả bên nghiệp vụ và kỹ thuật. Tập trung vào giá trị mà tính năng mang lại cho người dùng và cách hệ thống sẽ hoạt động từ góc độ người dùng.	BABOK Guide (Kỹ thuật: Use Cases and Scenarios, User Stories); ISO/IEC/IEEE 29148 (trong bối cảnh ghi nhận yêu cầu chức năng và hành vi).
Tiêu chí chấp nhận	Acceptance Criteria	Tiêu chí chấp nhận là các điều kiện cụ thể mà một giải pháp (hoặc một tính năng của giải pháp) phải đáp ứng để được các bên liên quan (stakeholder) chấp nhận là hoàn thành. Chúng là các kiểm thử có thể đo lường được và khách quan.	Cung cấp định nghĩa rõ ràng về "hoàn thành" cho một yêu cầu hoặc tính năng. Làm cơ sở cho việc kiểm thử (testing) và xác nhận rằng giải pháp đáp ứng mong đợi của nghiệp vụ một cách chính xác và đầy đủ.	ISTQB CTFL Syllabus (liên quan đến kiểm thử phần mềm, test basis); BABOK Guide (liên quan đến xác định yêu cầu và kiểm thử giải pháp).
Ma trận truy vết	Traceability Matrix	Ma trận truy vết là một tài liệu (document) dạng bảng, liên kết các yêu cầu với các tạo phẩm liên quan khác (như thiết kế, kiểm thử, mã nguồn). Nó cho phép theo dõi mối quan hệ "cha-con" giữa các tạo phẩm qua vòng đời dự án.	Đảm bảo mọi yêu cầu được thiết kế (design), phát triển (develop) và kiểm thử (test) đầy đủ. Giúp đánh giá tác động khi có thay đổi đối với một yêu cầu, duy trì tính nhất quán và kiểm soát chất lượng của giải pháp qua vòng đời (lifecycle) dự án.	BABOK Guide (Knowledge Area: Requirements Lifecycle Management); ISO/IEC/IEEE 29148; `01-curriculum/TRACEABILITY_ID_REGISTRY.md` (kế hoạch đăng ký định danh truy vết nội bộ Nova Foods mô phỏng).

3. Các Thuật ngữ Tiếng Anh Cốt lõi và Giải thích Tiếng Việt

Phần này cung cấp các giải thích từ nguyên tắc đầu tiên cho các thuật ngữ tiếng Anh chuyên ngành thường gặp trong Phân tích nghiệp vụ, được sử dụng xuyên suốt corpus này. Việc hiểu rõ các thuật ngữ này giúp đảm bảo sự đồng nhất trong giao tiếp và phát triển hệ thống ERP mô phỏng Nova Foods. Mỗi thuật ngữ được giải thích bằng tiếng Việt, kèm theo liên kết đến mục đích nghiệp vụ và ví dụ áp dụng.

Thuật ngữ tiếng Anh	Giải thích tiếng Việt	Liên kết nghiệp vụ và Mục đích chính (áp dụng cho Nova Foods)	Bằng chứng / Lý do
Business Analyst (BA)	Chuyên gia Phân tích Nghiệp vụ. Vai trò cầu nối giữa các bên liên quan nghiệp vụ và đội ngũ phát triển công nghệ.	Xác định, phân tích, tài liệu hóa và quản lý yêu cầu (requirement) để xây dựng hệ thống ERP mô phỏng Nova Foods đáp ứng nhu cầu kinh doanh. Đảm bảo mọi giải pháp kỹ thuật đều có cơ sở nghiệp vụ rõ ràng.	IIBA BABOK Guide định nghĩa vai trò cốt lõi.
Requirement	Yêu cầu. Một điều kiện hoặc khả năng cần thiết mà hệ thống phải có để giải quyết vấn đề, đạt được mục tiêu, hoặc thực hiện một nghĩa vụ.	Là nền tảng cho mọi thiết kế, phát triển và kiểm thử của Nova Foods ERP. BA thu thập và quản lý yêu cầu (ví dụ: tính năng quản lý kho, báo cáo tài chính).	IIBA BABOK Guide nhấn mạnh Requirement là trọng tâm của BA.
Stakeholder	Bên liên quan. Cá nhân, nhóm, hoặc tổ chức có ảnh hưởng hoặc bị ảnh hưởng bởi dự án, hệ thống, hoặc giải pháp.	Trong dự án Nova Foods, bao gồm: người dùng cuối (ví dụ: nhân viên kế toán), quản lý cấp cao, đội ngũ IT, hoặc nhà cung cấp. BA phải xác định và hợp tác để hiểu nhu cầu.	IIBA BABOK Guide có Knowledge Area riêng về Stakeholder Engagement.
Artifact	Tạo phẩm. Bất kỳ tài liệu, mô hình, hoặc đầu ra hữu hình nào được sản xuất trong quá trình phân tích nghiệp vụ, thiết kế hoặc phát triển.	Ví dụ các tài liệu như đặc tả yêu cầu, mô hình quy trình BPMN, từ điển dữ liệu (data dictionary), hoặc kế hoạch kiểm thử. Dùng để ghi nhận thông tin, truyền đạt ý tưởng cho hệ thống Nova Foods.	Các tệp `.md` trong corpus này, bao gồm `/04-cheatsheets/lifecycle-artifact-map.md`, đều là các tạo phẩm được quản trị.
Lifecycle	Vòng đời. Chuỗi các giai đoạn hoặc trạng thái mà một đối tượng (như yêu cầu, dự án, hoặc hệ thống) trải qua từ khi khởi tạo đến khi kết thúc hoặc ngừng hoạt động.	Áp dụng cho vòng đời yêu cầu (requirement lifecycle), vòng đời dự án, hoặc vòng đời của chính hệ thống Nova Foods ERP. Giúp quản lý thay đổi và đảm bảo tính nhất quán.	Khái niệm nền tảng trong phát triển phần mềm (SDLC) và quản lý dự án.
Traceability	Khả năng truy vết. Khả năng theo dõi một yếu tố từ nguồn gốc của nó (ví dụ: một yêu cầu nghiệp vụ) qua các giai đoạn phát triển, thiết kế, thực hiện, kiểm thử, và triển khai.	Đảm bảo mọi yêu cầu của Nova Foods được đáp ứng và mọi thành phần giải pháp đều có cơ sở. Cần thiết cho kiểm toán, QA và phân tích tác động khi có thay đổi.	ISTQB CTFL Syllabus nhấn mạnh tầm quan trọng của truy vết. Tham khảo `/01-curriculum/TRACEABILITY_ID_REGISTRY.md`.
Baseline	Đường cơ sở. Một phiên bản đã được phê duyệt và kiểm soát của một tạo phẩm hoặc một tập hợp các tạo phẩm, được dùng làm điểm tham chiếu cố định.	Ngăn chặn phạm vi dự án bị nới rộng (scope creep) và cung cấp một điểm xuất phát ổn định cho các hoạt động tiếp theo trong dự án Nova Foods ERP mô phỏng.	Khái niệm cốt lõi trong quản lý cấu hình (Configuration Management). Mọi artifact đều `IN_REVIEW` cho đến khi `BASELINED`.
Governance	Quản trị. Khung quy tắc, quy trình và cấu trúc trách nhiệm được thiết lập để định hướng, kiểm soát và giám sát hoạt động.	Đảm bảo mọi quyết định liên quan đến Nova Foods ERP được đưa ra có trách nhiệm, tuân thủ các quy định (ví dụ: Luật Bảo vệ dữ liệu cá nhân) và phù hợp với mục tiêu của tổ chức.	Các artifact quản trị như `/01-curriculum/01_CURRICULUM_ARCHITECTURE.md` thể hiện tầm quan trọng của governance.
Scope	Phạm vi. Giới hạn của một dự án, hệ thống hoặc một giai đoạn công việc, xác định rõ những gì sẽ được bao gồm và những gì sẽ bị loại trừ.	Xác định rõ ràng phạm vi của Nova Foods ERP giúp quản lý kỳ vọng, phân bổ nguồn lực hiệu quả và tránh làm việc ngoài các mục tiêu đã đặt ra.	Quản lý phạm vi là một trong mười Knowledge Areas chính của Project Management Body of Knowledge (PMBOK Guide).

Các Tài Liệu Nghiệp Vụ (Artifact) và Vòng Đời Phát Triển

Tài liệu nghiệp vụ (artifact) là sản phẩm hữu hình hoặc vô hình được tạo ra, sửa đổi hoặc sử dụng trong vòng đời phát triển hệ thống hoặc dự án. Artifact cung cấp bằng chứng, thông tin đầu vào, cơ sở ra quyết định và công cụ giao tiếp giữa các bên liên quan. Trạng thái quản trị của các artifact Nova Foods trong mục này là IN_REVIEW; nội dung không phải chuẩn đã phê duyệt hoặc BASELINED. Nova Foods là môi trường mô phỏng; mọi ví dụ dùng dữ liệu tổng hợp.

Các bảng dưới đây định nghĩa, phân loại và ánh xạ artifact theo các giai đoạn vòng đời Business Analyst (BA). BA, chủ sở hữu nghiệp vụ, nhóm giải pháp, nhóm kiểm thử và nhóm vận hành dùng các artifact này để thống nhất phạm vi, yêu cầu, thiết kế, kiểm thử, triển khai và hỗ trợ. Mỗi artifact phải giữ nguồn, định danh, chủ sở hữu, trạng thái và liên kết truy vết phù hợp với ranh giới nguồn trong corpus.

Thuật ngữ tiếng Anh	Giải thích tiếng Việt	Mục đích chính trong Vòng đời BA	Tham chiếu Quản trị / Ví dụ Nova Foods (mô phỏng)
Artifact	`Tài liệu nghiệp vụ` (hoặc `Vật phẩm`) là sản phẩm công việc được tạo ra, sửa đổi hoặc sử dụng khi phát triển hệ thống hoặc giải pháp. Artifact có thể là tài liệu, mô hình, danh sách, đặc tả, nhật ký hoặc ma trận truy vết.	Cung cấp thông tin, bằng chứng, cơ sở ra quyết định và công cụ giao tiếp cho các bên liên quan. Chủ sở hữu artifact cập nhật nội dung; người có thẩm quyền xem xét trước khi artifact được dùng làm đầu vào cho quyết định hoặc công việc tiếp theo.	`/01-curriculum/CANONICAL_DATA_DICTIONARY.md` là artifact quản trị.
Lifecycle	`Vòng đời` là chuỗi giai đoạn mà sản phẩm, hệ thống hoặc dự án trải qua từ hình thành ý tưởng đến ngừng hoạt động.	Cung cấp cấu trúc để BA xác định hoạt động, đầu vào, đầu ra, người chịu trách nhiệm và cổng chất lượng theo từng giai đoạn. Hệ quả của việc bỏ qua giai đoạn hoặc artifact đầu ra là giảm khả năng kiểm soát phạm vi, truy vết và đánh giá tác động thay đổi.	Áp dụng trên toàn bộ corpus Nova Foods, ví dụ các pha trong `/01-curriculum/CHAPTER_MANIFEST.md`.
Mapping	`Ánh xạ` là thiết lập quan hệ hoặc tương ứng giữa các yếu tố thuộc hai hoặc nhiều tập hợp.	Liên kết yêu cầu, quy tắc nghiệp vụ, dữ liệu, thiết kế, kiểm thử và kết quả. BA dùng ánh xạ để xác định một thay đổi ảnh hưởng artifact nào; nhóm dự án dùng kết quả để quyết định cập nhật, kiểm thử lại hoặc leo thang.	Ánh xạ giữa `REQ-NF-001` và `TEST-NF-001` trong Traceability Matrix.
Traceability	`Truy vết` là khả năng theo dõi một mục từ nguồn gốc đến đích đến, hoặc theo chiều ngược lại, qua các giai đoạn vòng đời.	Đảm bảo yêu cầu có nguồn, được diễn giải thành giải pháp và được kiểm thử. Truy vết cũng hỗ trợ phân tích tác động thay đổi; thiếu liên kết truy vết làm giảm khả năng chứng minh phạm vi kiểm thử và quyết định liên quan.	`TRACEABILITY_ID_REGISTRY` là artifact quản lý ID truy vết.
Source Classification	`Phân loại nguồn` là xác định và gắn nhãn loại nguồn thông tin, ví dụ pháp lý, quy tắc nghiệp vụ hoặc chuẩn ngành, cùng độ tin cậy và ranh giới sử dụng của nguồn đó.	Giúp BA đánh giá độ tin cậy thông tin, xác định thẩm quyền quyết định và tránh dùng nguồn tham khảo như nguồn bắt buộc. Người dùng artifact phải kiểm tra nguồn trước khi chuyển nội dung thành yêu cầu, quy tắc hoặc quyết định.	Mục `Source` trong `/00-research/00_SOURCE_MAP.md`.

Lý do: Các thuật ngữ artifact, lifecycle, mapping, traceability và source classification xác định cách người học đọc, tạo, liên kết và kiểm tra tài liệu nghiệp vụ. Hiểu sai một thuật ngữ có thể làm BA dùng nhầm artifact, gán sai thẩm quyền hoặc không phát hiện tác động của thay đổi. Mỗi định nghĩa kèm tham chiếu corpus để người học phân biệt khái niệm, ví dụ mô phỏng và nguồn quản trị.

Bảng sau ánh xạ các hoạt động Business Analysis với artifact chính theo các giai đoạn điển hình của vòng đời phát triển giải pháp. Bảng không áp đặt một quy trình phát triển duy nhất. Tổ chức có thể lặp lại hoặc thực hiện song song các giai đoạn, nhưng vẫn phải duy trì nguồn, ID, quan hệ truy vết, trạng thái IN_REVIEW và quyết định có thẩm quyền cho artifact được sử dụng.

Giai đoạn Vòng đời BA	Mục đích chính giai đoạn	Các Tài liệu Nghiệp vụ chính được tạo/sử dụng	ID Tham chiếu Quản trị (Corpus Nova Foods)
1. Phân tích Chiến lược (Strategy Analysis)	BA và chủ sở hữu nghiệp vụ xác định bối cảnh, vấn đề, cơ hội, mục tiêu, phạm vi cấp cao và kết quả mong muốn của giải pháp. Người có thẩm quyền dùng thông tin này để quyết định có tiếp tục phân tích hay thay đổi hướng đi.	Business Case (Trường hợp nghiệp vụ), Business Model Canvas (Mô hình nghiệp vụ), Scope Statement (Tuyên bố phạm vi dự án). Các artifact làm rõ lý do đầu tư, phạm vi và đánh đổi cấp cao; chúng không thay thế yêu cầu chi tiết hoặc quyết định phê duyệt.	Liên kết với `CANONICAL_BUSINESS_RULES` cho quy tắc nghiệp vụ cấp cao và `01_CURRICULUM_ARCHITECTURE` cho cấu trúc dự án.
2. Thu thập và Phân tích Yêu cầu (Elicitation & Requirements Analysis)	BA thu thập, phân tích, làm rõ, tổ chức và ưu tiên yêu cầu từ các bên liên quan. Kết quả phải thể hiện nhu cầu, quy tắc, dữ liệu, hành vi, giới hạn và tiêu chí đánh giá phù hợp với nguồn đã phân loại.	Business Requirements Document (BRD) (Tài liệu Yêu cầu Nghiệp vụ), Functional Requirements (Yêu cầu chức năng), Non-functional Requirements (Yêu cầu phi chức năng), Use Case (Ca sử dụng), User Story (Câu chuyện người dùng), Process Model (BPMN) (Mô hình quy trình), Data Dictionary (Từ điển dữ liệu). BA liên kết các artifact với nguồn và ID để nhóm thiết kế, kiểm thử và chủ sở hữu nghiệp vụ có thể kiểm tra phạm vi.	`TEMPLATE_MANIFEST` cho template BRD, Use Case, User Story; `CANONICAL_DATA_DICTIONARY`; `/01-curriculum/CANONICAL_BUSINESS_RULES.md`; `TRACEABILITY_ID_REGISTRY`.
3. Thiết kế Giải pháp (Solution Design)	Nhóm giải pháp diễn giải yêu cầu thành thiết kế chi tiết về cấu trúc, thành phần, dữ liệu, giao diện và tương tác. BA kiểm tra thiết kế vẫn phản ánh yêu cầu, quy tắc nghiệp vụ và giới hạn đã ghi nhận; khác biệt phải được truy vết và xử lý theo thẩm quyền.	System Design Document (SDD) (Tài liệu Thiết kế Hệ thống), Data Model (Mô hình dữ liệu - logical/physical), API Specification (OpenAPI) (Đặc tả API), User Interface Mockups/Wireframes (Mô phỏng/Phác thảo giao diện người dùng). Các artifact thiết kế là đầu vào cho xây dựng và kiểm thử; chúng không tự xác nhận yêu cầu đã được chấp nhận.	`TEMPLATE_MANIFEST` cho template SDD, Data Model; tham chiếu `OpenAPI Specification` từ `00_SOURCE_MAP`.
4. Kiểm thử và Đảm bảo Chất lượng (Testing & Quality Assurance)	Nhóm kiểm thử xác minh giải pháp đáp ứng yêu cầu đã đặc tả và hoạt động theo tiêu chí chấp nhận. BA, nhóm kiểm thử và chủ sở hữu nghiệp vụ dùng kết quả để xác định yêu cầu nào đã được kiểm tra, lỗi nào còn mở và phạm vi nào chịu ảnh hưởng.	Test Plan (Kế hoạch kiểm thử), Test Case (Kịch bản kiểm thử), Defect Log (Nhật ký lỗi), Traceability Matrix (Ma trận truy vết Yêu cầu-Kiểm thử), Acceptance Criteria (Tiêu chí chấp nhận). Traceability Matrix liên kết yêu cầu với kiểm thử; Defect Log ghi nhận lỗi và hậu quả cần xử lý, không thay thế quyết định chấp nhận hoặc từ chối của người có thẩm quyền.	Tham chiếu `ISTQB CTFL` từ `00_SOURCE_MAP`; `TRACEABILITY_ID_REGISTRY` cho ID test case; `CANONICAL_BUSINESS_RULES` cho nguồn quy tắc kiểm thử.
5. Triển khai và Hỗ trợ (Deployment & Support)	Nhóm triển khai và vận hành chuyển giao giải pháp cho người dùng cuối, hướng dẫn sử dụng, tiếp nhận phản hồi và duy trì vận hành. Chủ sở hữu nghiệp vụ và nhóm hỗ trợ dùng phản hồi để xác định vấn đề, tác động và nhu cầu thay đổi tiếp theo.	User Manual (Sổ tay người dùng), Training Materials (Tài liệu đào tạo), Release Notes (Ghi chú phát hành), Support Procedures (Quy trình hỗ trợ), Feedback Log (Nhật ký phản hồi). Các artifact này truyền đạt thay đổi, hướng dẫn hành động và ghi nhận phản hồi; phản hồi cần được phân tích trước khi trở thành yêu cầu hoặc thay đổi được quyết định.	`TEMPLATE_MANIFEST` cho template User Manual; `01_CURRICULUM_ARCHITECTURE` cho giai đoạn chuyển giao.

Lý do: Bảng ánh xạ là công cụ tra cứu để người học xác định artifact cần tạo hoặc sử dụng theo mục tiêu giai đoạn. Mỗi dòng nêu mục đích, tác nhân sử dụng, artifact đầu ra hoặc đầu vào, tham chiếu quản trị và hệ quả kiểm soát. Cấu trúc này hỗ trợ nguyên tắc first-principles lookup: bắt đầu từ giai đoạn và mục tiêu, xác định artifact liên quan, kiểm tra nguồn và ID, rồi đánh giá quan hệ truy vết trước khi dùng artifact cho quyết định hoặc công việc tiếp theo. Các tham chiếu Nova Foods giữ ranh giới mô phỏng; không phải phê duyệt, chuẩn hóa hoặc xác nhận áp dụng trong môi trường thực tế.

3. Applied Nova Foods Reference

Trong phần này, chúng ta sẽ xem xét các ví dụ cụ thể, mô phỏng từ Nova Foods Trading & Manufacturing, để minh họa cách các tài liệu nghiệp vụ được áp dụng thực tế. Mọi dữ liệu về Nova Foods ở đây đều là tổng hợp và chỉ dùng cho mục đích giáo dục, không phản ánh hoạt động kinh doanh thật.

3.1. Ví dụ về Danh sách các bên liên quan (Stakeholder List)

Danh sách các bên liên quan (Stakeholder List) là một tài liệu quan trọng để xác định tất cả các cá nhân, nhóm hoặc tổ chức có ảnh hưởng hoặc bị ảnh hưởng bởi một dự án hoặc hệ thống. Việc nhận diện đầy đủ giúp đảm bảo mọi nhu cầu và kỳ vọng được xem xét. ID quản trị cho loại tài liệu này được đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md với ID STK-LIST.

STK-ID (Mô phỏng)	Vai trò (Role)	Phòng ban (Department)	Tổ chức (Organization)	Mức độ ảnh hưởng (Influence Level)	Mức độ quan tâm (Interest Level)	Yêu cầu chính (Key Needs)
NF-STK-001	Giám đốc Kinh doanh (Sales Director)	Kinh doanh (Sales)	Nova Foods (Simulated)	Cao (High)	Cao (High)	Hệ thống quản lý đơn hàng hiệu quả (Efficient order management system).
NF-STK-002	Trưởng phòng Kế toán (Chief Accountant)	Kế toán (Accounting)	Nova Foods (Simulated)	Cao (High)	Trung bình (Medium)	Báo cáo tài chính chính xác (Accurate financial reports), tuân thủ `Luật Kế toán 88/2015/QH13` (từ `00_SOURCE_MAP`).
NF-STK-003	Quản lý Kho (Warehouse Manager)	Vận hành (Operations)	Nova Foods (Simulated)	Trung bình (Medium)	Cao (High)	Theo dõi hàng tồn kho theo thời gian thực (Real-time inventory tracking).
NF-STK-004	Đại diện Khách hàng (Customer Representative)	(N/A)	Khách hàng Nova Foods (Simulated)	Thấp (Low)	Cao (High)	Quy trình đặt hàng đơn giản (Simple ordering process), thông tin sản phẩm rõ ràng.

Lý do: Ví dụ này cung cấp các bên liên quan cụ thể trong bối cảnh Nova Foods, giúp người học hình dung vai trò và nhu cầu của từng đối tượng. Việc sử dụng STK-ID (Mô phỏng) thể hiện cách chúng ta tạo ra định danh (Identifier) giả định để theo dõi, một kỹ năng cốt lõi trong phân tích nghiệp vụ. Mỗi yêu cầu chính cũng chỉ ra động lực nghiệp vụ cần được giải quyết, đồng thời tham chiếu đến các nguồn chuẩn (ví dụ: Luật Kế toán) khi cần, như đã đăng ký trong 00_SOURCE_MAP.

3.2. Ví dụ về Trường hợp sử dụng (Use Case)

Trường hợp sử dụng (Use Case) mô tả cách một người dùng hoặc một hệ thống bên ngoài tương tác với hệ thống để đạt được một mục tiêu nghiệp vụ cụ thể. Đây là một kỹ thuật phổ biến để đặc tả các yêu cầu chức năng. ID quản trị cho Use Case được đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md với ID UC-SPEC.

UC-ID (Mô phỏng): NF-UC-001 Tên Trường hợp sử dụng: Đặt hàng sản phẩm (Place Product Order) Mô tả: Khách hàng (User) truy cập hệ thống ERP của Nova Foods để tạo một đơn hàng mới, chọn sản phẩm, số lượng và xác nhận thông tin giao hàng. Actor (Tác nhân): Khách hàng (Customer) Tiền điều kiện (Pre-conditions): 1. Khách hàng đã đăng nhập vào hệ thống (giả định cho hệ thống B2B) hoặc đã cung cấp thông tin liên hệ hợp lệ (cho B2C). 2. Sản phẩm và số lượng yêu cầu còn hàng trong kho. Dòng sự kiện chính (Main Flow): 1. Khách hàng chọn "Đặt hàng mới". 2. Hệ thống hiển thị danh mục sản phẩm Nova Foods. 3. Khách hàng tìm kiếm và chọn sản phẩm (ví dụ: "Thịt bò đông lạnh loại A", "Nước ép trái cây tươi"). 4. Khách hàng nhập số lượng cho từng sản phẩm. 5. Hệ thống hiển thị tổng giá trị đơn hàng (tạm tính). 6. Khách hàng xác nhận thông tin giao hàng và thanh toán. 7. Hệ thống tạo Đơn hàng (Order) với ID NF-ORD-YYYYMMDD-XXXX. 8. Hệ thống gửi xác nhận đơn hàng cho Khách hàng. Dòng sự kiện thay thế (Alternate Flows): * NF-UC-001-A1: Sản phẩm hết hàng: Hệ thống thông báo sản phẩm không đủ số lượng, Khách hàng có thể điều chỉnh số lượng hoặc chọn sản phẩm khác. * NF-UC-001-A2: Lỗi xác nhận thanh toán: Hệ thống hiển thị thông báo lỗi, cho phép Khách hàng thử lại hoặc chọn phương thức thanh toán khác. Hậu điều kiện (Post-conditions): 1. Đơn hàng mới được tạo và lưu trữ trong hệ thống với trạng thái Đã đặt hàng (ORDERED). 2. Số lượng hàng tồn kho của sản phẩm đã đặt được cập nhật giảm. 3. Thông báo xác nhận đơn hàng đã được gửi thành công cho Khách hàng.

Lý do: Ví dụ này minh họa cấu trúc chi tiết của một Trường hợp sử dụng, bao gồm tác nhân, dòng sự kiện và các kịch bản thay thế. Nó sử dụng dữ liệu tổng hợp như tên sản phẩm và ID đơn hàng NF-ORD-YYYYMMDD-XXXX để tạo ngữ cảnh Nova Foods. Điều này giúp người học hiểu cách chuyển đổi các yêu cầu nghiệp vụ thành đặc tả chức năng cụ thể cho phát triển phần mềm.

3.3. Ví dụ về Quy tắc nghiệp vụ (Business Rule)

Quy tắc nghiệp vụ (Business Rule) là một định nghĩa hoặc ràng buộc không được phép vi phạm, có tác dụng điều chỉnh hoặc kiểm soát một khía cạnh của nghiệp vụ. Các quy tắc này là nền tảng cho logic xử lý trong hệ thống ERP. Các quy tắc nghiệp vụ của Nova Foods được đăng ký tập trung trong /01-curriculum/CANONICAL_BUSINESS_RULES.md để đảm bảo tính nhất quán.

BR-ID (Mô phỏng)	Mô tả Quy tắc (Rule Description)	Điều kiện kích hoạt (Trigger Condition)	Hành động/Hậu quả (Action/Consequence)	Tham chiếu Nguồn (Source Reference)	Mức độ ưu tiên (Priority)
NF-BR-001	Đơn hàng phải có ít nhất một sản phẩm.	Khi tạo `Đơn hàng (Order)`.	Không cho phép lưu `Đơn hàng` nếu danh sách sản phẩm rỗng.	Phòng ban Kinh doanh Nova Foods (Simulated)	Cao (High)
NF-BR-002	Khách hàng phải có xếp hạng tín dụng (Credit Rating) phù hợp để đặt hàng trả sau.	Khi `Đơn hàng` được tạo với phương thức `Trả sau`.	Kiểm tra `Xếp hạng tín dụng` của Khách hàng từ `CANONICAL_DATA_DICTIONARY` (`NF-DD-CUST-005`). Nếu `Thấp`, yêu cầu phương thức `Thanh toán ngay`.	Phòng ban Kế toán Nova Foods (Simulated), tham khảo `Luật Kế toán 88/2015/QH13`.	Cao (High)
NF-BR-003	Giảm giá 5% cho đơn hàng có tổng giá trị từ 5.000.000 VND trở lên.	Khi tổng giá trị `Đơn hàng` được tính.	Áp dụng giảm giá `5%` vào `Tổng giá trị`.	Phòng ban Marketing Nova Foods (Simulated)	Trung bình (Medium)
NF-BR-004	Không cho phép bán sản phẩm hết hạn sử dụng.	Khi sản phẩm được thêm vào `Đơn hàng`.	Hệ thống kiểm tra `Ngày hết hạn` (`NF-DD-PROD-004`) của sản phẩm. Nếu `Ngày hết hạn` < `Ngày hiện tại`, thông báo lỗi.	Phòng ban Kiểm soát Chất lượng Nova Foods (Simulated), tham khảo `Luật An toàn thực phẩm 55/2010/QH12`.	Rất cao (Very High)

Lý do: Bảng này minh họa cách các quy tắc nghiệp vụ được định nghĩa rõ ràng với ID, mô tả, điều kiện, hành động và nguồn gốc. Việc liên kết đến CANONICAL_BUSINESS_RULES.md và CANONICAL_DATA_DICTIONARY.md (qua NF-DD-CUST-005, NF-DD-PROD-004) cho thấy khả năng truy vết và kiểm soát phiên bản trong một hệ thống tài liệu BA toàn diện. Các tham chiếu đến luật pháp (Luật Kế toán, Luật An toàn thực phẩm) từ 00_SOURCE_MAP thể hiện sự kết nối giữa yêu cầu nghiệp vụ và các ràng buộc pháp lý bên ngoài, một yếu tố quan trọng trong ERP.

3.4. Ví dụ về Phần tử dữ liệu (Data Element)

Phần tử dữ liệu (Data Element) là đơn vị nhỏ nhất có ý nghĩa của dữ liệu, được định nghĩa rõ ràng về tên, mô tả, kiểu dữ liệu, định dạng và các ràng buộc. Đây là nền tảng cho việc xây dựng Mô hình dữ liệu (Data Model) và từ điển dữ liệu (Data Dictionary). Từ điển dữ liệu logic của Nova Foods được quản lý trong /01-curriculum/CANONICAL_DATA_DICTIONARY.md.

DD-ID (Mô phỏng)	Tên Phần tử (Element Name)	Mô tả (Description)	Kiểu dữ liệu (Data Type)	Định dạng (Format)	Ràng buộc (Constraints)	Ghi chú (Notes)
NF-DD-CUST-001	CustomerID	Mã định danh duy nhất của khách hàng.	Chuỗi (String)	`CUST-NNNNN`	Duy nhất (Unique), Bắt buộc (Mandatory)	ID nội bộ của Nova Foods.
NF-DD-CUST-002	CustomerName	Tên đầy đủ của khách hàng.	Chuỗi (String)	(Tối đa 100 ký tự)	Bắt buộc (Mandatory)	Tên dùng trong giao dịch.
NF-DD-PROD-001	ProductCode	Mã sản phẩm duy nhất.	Chuỗi (String)	`PROD-NNNNN`	Duy nhất (Unique), Bắt buộc (Mandatory)	Mã SKU (Stock Keeping Unit) nội bộ.
NF-DD-PROD-002	ProductName	Tên sản phẩm.	Chuỗi (String)	(Tối đa 200 ký tự)	Bắt buộc (Mandatory)	Tên hiển thị trên catalog.
NF-DD-PROD-003	UnitPrice	Đơn giá của sản phẩm.	Số thực (Decimal)	`VND` (2 chữ số thập phân)	Lớn hơn 0 (Greater than 0)	Đơn vị tiền tệ `VND` theo `01_CURRICULUM_ARCHITECTURE`.
NF-DD-PROD-004	ExpirationDate	Ngày hết hạn sử dụng của sản phẩm.	Ngày (Date)	`YYYY-MM-DD`	Ngày trong tương lai (Future date) hoặc `NULL` (nếu không áp dụng).	Quan trọng cho sản phẩm thực phẩm theo `Luật An toàn thực phẩm`.
NF-DD-ORD-001	OrderID	Mã định danh duy nhất của đơn hàng.	Chuỗi (String)	`ORD-YYYYMMDD-NNNNN`	Duy nhất (Unique), Bắt buộc (Mandatory)	ID do hệ thống ERP Nova Foods tạo.
NF-DD-ORD-002	OrderDate	Ngày đơn hàng được tạo.	Ngày (Date)	`YYYY-MM-DD`	Không thể trong tương lai (Not future date)
NF-DD-CUST-005	CreditRating	Xếp hạng tín dụng của khách hàng.	Chuỗi (String)	(ví dụ: `CAO`, `TRUNG_BINH`, `THAP`)	Danh sách giá trị cho phép	Ảnh hưởng đến phương thức thanh toán. Tham khảo `NF-BR-002`.

Lý do: Bảng này cung cấp các ví dụ về cách định nghĩa chi tiết từng phần tử dữ liệu, làm rõ kiểu, định dạng và các ràng buộc của chúng. Việc sử dụng DD-ID (Mô phỏng) như NF-DD-CUST-001 và liên kết với CANONICAL_DATA_DICTIONARY.md đảm bảo tính nhất quán và khả năng truy vết từ cấp độ yêu cầu đến thiết kế cơ sở dữ liệu. Các tham chiếu chéo đến quy tắc nghiệp vụ (NF-BR-002) và luật pháp (Luật An toàn thực phẩm) củng cố sự liên kết giữa các loại artifact khác nhau.

3.5. Ví dụ về Bước quy trình (Process Step)

Bước quy trình (Process Step) là một hành động hoặc chuỗi hành động cụ thể trong một quy trình nghiệp vụ tổng thể. Việc mô tả rõ ràng các bước này giúp hình thành các Mô hình quy trình (Process Model) như BPMN (Business Process Model and Notation) để hiểu và tối ưu hóa luồng công việc. ID quản trị cho Process Model được đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md với ID PROC-MODEL.

Ví dụ: Trích đoạn Quy trình "Xử lý đơn hàng bán hàng" của Nova Foods (Mô phỏng)

PROC-STEP-ID (Mô phỏng)	Tên Bước (Step Name)	Actor (Tác nhân)	Mô tả chi tiết (Detailed Description)	Đầu vào (Input)	Đầu ra (Output)	Quy tắc nghiệp vụ liên quan (Related Business Rules)
NF-PS-001	Tiếp nhận Đơn hàng	Hệ thống ERP	Hệ thống tự động tiếp nhận `Đơn hàng (Order)` từ kênh bán hàng trực tuyến hoặc nhập thủ công từ phòng kinh doanh.	`Đơn hàng` chưa xử lý (`UNPROCESSED_ORDER`)	`Đơn hàng` đã tiếp nhận (`RECEIVED_ORDER`)	`NF-BR-001` (Đơn hàng phải có ít nhất một sản phẩm)
NF-PS-002	Kiểm tra Tồn kho	Hệ thống ERP	Hệ thống kiểm tra số lượng `Sản phẩm` trong kho có đủ để đáp ứng `Đơn hàng` hay không.	`RECEIVED_ORDER`, Dữ liệu `Tồn kho`	`Đơn hàng` đủ kho (`STOCK_OK_ORDER`) hoặc `Đơn hàng` thiếu kho (`STOCK_SHORT_ORDER`)	`NF-BR-004` (Không bán sản phẩm hết hạn)
NF-PS-003	Xác minh Tín dụng	Hệ thống ERP	Đối với `Đơn hàng` trả sau, hệ thống kiểm tra `Xếp hạng tín dụng` của Khách hàng.	`STOCK_OK_ORDER`, Dữ liệu `Khách hàng` (Credit Rating)	`Đơn hàng` tín dụng hợp lệ (`CREDIT_OK_ORDER`) hoặc `Đơn hàng` cần thanh toán ngay (`PAY_NOW_ORDER`)	`NF-BR-002` (Kiểm tra xếp hạng tín dụng)
NF-PS-004	Áp dụng Chính sách Giá/Giảm giá	Hệ thống ERP	Hệ thống tính toán tổng giá trị `Đơn hàng` và áp dụng các chính sách giảm giá hiện hành.	`CREDIT_OK_ORDER`	`Đơn hàng` với giá đã tính (`PRICED_ORDER`)	`NF-BR-003` (Giảm giá 5% cho đơn hàng >= 5.000.000 VND)

Lý do: Bảng này cung cấp một cái nhìn chi tiết về các bước trong một quy trình nghiệp vụ, minh họa cách các hành động được phân công cho hệ thống hoặc người dùng, các đầu vào/đầu ra và các quy tắc nghiệp vụ điều khiển chúng. Việc sử dụng PROC-STEP-ID (Mô phỏng) và liên kết với TRACEABILITY_ID_REGISTRY.md giúp theo dõi các thành phần quy trình. Quan trọng hơn, nó cho thấy sự tích hợp giữa các artifact khác nhau (quy trình, quy tắc nghiệp vụ, dữ liệu) để tạo ra một bức tranh toàn diện về yêu cầu của hệ thống ERP Nova Foods. Việc tham chiếu BPMN (Business Process Model and Notation) giải thích ý nghĩa của Process Model.

3.1. Ánh xạ Tác nhân, Tài liệu, Định danh, Quyết định và Cổng chất lượng trong Nova Foods (Mô phỏng)

Phần này ánh xạ các thành phần cốt lõi của vòng đời phát triển hệ thống (System Development Life Cycle - SDLC) vào bối cảnh mô phỏng của Nova Foods. Mỗi yếu tố được gán một định danh (ID) duy nhất để đảm bảo khả năng truy vết (traceability).

Giải thích thuật ngữ:

Tác nhân (Actor): Là cá nhân hoặc vai trò có tương tác, trách nhiệm trong hệ thống hoặc quy trình ERP Nova Foods. Tác nhân không chỉ là người dùng cuối mà còn là các bên liên quan, quản lý, nhóm phát triển.
Tài liệu/Sản phẩm công việc (Artifact): Là đầu ra cụ thể, hữu hình từ các hoạt động trong vòng đời dự án ERP. Chúng có thể là văn bản, mô hình, mã nguồn, báo cáo.
Định danh (ID - Identifier): Là mã duy nhất dùng để nhận diện và truy vết một cách rõ ràng các tác nhân, tài liệu, quyết định hoặc các thành phần khác trong hệ sinh thái dự án Nova Foods.
Quyết định (Decision): Là điểm mà tại đó một sự lựa chọn chính thức được đưa ra, thường liên quan đến việc thay đổi hướng đi, phê duyệt một tài liệu hoặc giải pháp. Quyết định thường được gắn với một hoặc nhiều tác nhân chịu trách nhiệm.
Cổng chất lượng (Quality Gate): Là điểm kiểm tra bắt buộc trong tiến trình dự án, nơi mà một tập hợp các tiêu chí định trước phải được đáp ứng trước khi dự án được phép chuyển sang giai đoạn tiếp theo. Cổng chất lượng giúp đảm bảo sản phẩm đạt tiêu chuẩn.

Bảng ánh xạ Tác nhân Nova Foods:

Tác nhân Nova Foods	Vai trò chính trong vòng đời ERP (Mô phỏng)	Tham chiếu nguồn/chuẩn
Chủ nghiệp vụ Nova Foods (Business Owner)	Xác định nhu cầu nghiệp vụ, phê duyệt yêu cầu, chấp nhận giải pháp cuối cùng.	`SRC-READY-010`
Chuyên viên Phân tích nghiệp vụ CNTT Nova Foods (IT BA)	Phân tích yêu cầu, mô hình hóa quy trình, thiết kế chức năng, duy trì truy vết.	`BABOK Guide`, `ISO/IEC/IEEE 29148`
Nhà phát triển ERP Nova Foods (ERP Developer)	Thiết kế kỹ thuật chi tiết, lập trình, cấu hình hệ thống, phát triển tích hợp.	`UML`, `OpenAPI Specification`
Chuyên viên Kiểm thử QA Nova Foods (QA Analyst)	Lập kế hoạch kiểm thử, thiết kế trường hợp kiểm thử, thực thi kiểm thử, báo cáo lỗi.	`ISTQB CTFL`
Chuyên viên Pháp lý Nova Foods (Legal Counsel)	Đánh giá tuân thủ pháp luật (ví dụ: Luật Bảo vệ dữ liệu cá nhân, Luật An toàn thực phẩm).	`Luật Bảo vệ dữ liệu cá nhân`, `Luật An toàn thực phẩm`
Quản lý Kế toán Nova Foods (Accounting Manager)	Xác nhận tính đúng đắn kế toán của các chức năng ERP, đảm bảo tuân thủ `Luật Kế toán`.	`Luật Kế toán`, `Nghị định 123/2020/NĐ-CP`
Quản lý Dự án Nova Foods (Project Manager)	Lập kế hoạch, theo dõi tiến độ, quản lý rủi ro, điều phối tài nguyên.	`01_CURRICULUM_ARCHITECTURE`

Bảng ánh xạ Tài liệu/Sản phẩm công việc Nova Foods:

Artifact ID	Tên Artifact (Mô phỏng Nova Foods)	Mô tả ngắn gọn	Nguồn chuẩn / Tham chiếu quản trị
`REQ-NF-20260807-001`	Đặc tả Yêu cầu nghiệp vụ (Business Requirement Spec.)	Tập hợp các yêu cầu chức năng, phi chức năng cho mô-đun quản lý kho hàng.	`ISO/IEC/IEEE 29148`
`SOL-NF-20260807-003`	Thiết kế Giải pháp Kỹ thuật (Technical Solution Design)	Mô tả kiến trúc, luồng dữ liệu, tích hợp cho mô-đun bán hàng online.	`UML`, `OpenAPI Specification`
`TST-NF-20260807-005`	Kế hoạch Kiểm thử Chấp nhận (User Acceptance Test Plan)	Định nghĩa kịch bản, dữ liệu, tiêu chí chấp nhận cho mô-đun Kế toán.	`ISTQB CTFL`
`DDICT-NF-20260807-007`	Từ điển Dữ liệu Logic (Logical Data Dictionary)	Định nghĩa các thực thể, thuộc tính và mối quan hệ dữ liệu cốt lõi của ERP Nova Foods.	`/01-curriculum/CANONICAL_DATA_DICTIONARY.md`
`BR-NF-20260807-009`	Quy tắc Nghiệp vụ Chuẩn (Canonical Business Rules)	Tập hợp các quy tắc chi phối nghiệp vụ, ví dụ: chính sách chiết khấu, hạn mức tín dụng.	`/01-curriculum/CANONICAL_BUSINESS_RULES.md`

Bảng ánh xạ Quyết định và Cổng chất lượng Nova Foods:

ID Quyết định/Cổng	Tên Quyết định/Cổng (Mô phỏng Nova Foods)	Tác nhân chính chịu trách nhiệm	Đầu vào (Artifacts)	Đầu ra (Artifacts/Trạng thái)	Tiêu chí/Nguồn
`DEC-NF-BRD-001`	Phê duyệt Đặc tả Yêu cầu nghiệp vụ (BRD Approval)	Chủ nghiệp vụ Nova Foods	`REQ-NF-20260807-001`	`REQ-NF-20260807-001` (Trạng thái: Đã phê duyệt)	`BR-NF-20260807-009`
`QGATE-NF-DES-002`	Cổng chất lượng Thiết kế Giải pháp (Design Quality Gate)	Chuyên viên Phân tích nghiệp vụ CNTT Nova Foods, Nhà phát triển ERP Nova Foods	`SOL-NF-20260807-003`	`SOL-NF-20260807-003` (Trạng thái: Sẵn sàng phát triển)	Quy tắc thiết kế nội bộ, `UML`
`QGATE-NF-SEC-003`	Cổng chất lượng Bảo mật (Security Quality Gate)	Chuyên viên Pháp lý Nova Foods, Chuyên viên Bảo mật CNTT	`REQ-NF-20260807-001`, `SOL-NF-20260807-003`, Báo cáo đánh giá lỗ hổng (tổng hợp)	Báo cáo Đánh giá Bảo mật (Security Assessment Report)	`OWASP ASVS`, `OWASP API Security Top 10`, `Luật Bảo vệ dữ liệu cá nhân`
`DEC-NF-UAT-004`	Chấp nhận Kiểm thử UAT (UAT Acceptance)	Chủ nghiệp vụ Nova Foods, Quản lý Kế toán	`TST-NF-20260807-005`, Báo cáo Kiểm thử UAT (tổng hợp)	`TST-NF-20260807-005` (Trạng thái: Đã chấp nhận)	Tiêu chí chấp nhận nghiệp vụ, `ISTQB CTFL`
`DEC-NF-DEP-005`	Phê duyệt Triển khai (Deployment Approval)	Chủ nghiệp vụ Nova Foods, Quản lý Dự án Nova Foods, Giám đốc CNTT	Báo cáo kiểm thử, Báo cáo đánh giá bảo mật, Hướng dẫn vận hành	Quyết định triển khai ERP	Tất cả các cổng chất lượng đã thông qua.

Minh họa Luồng Nghiệp vụ và Ánh xạ Hiện vật trong Nova Foods

Để minh họa cách các hiện vật (artifacts), tác nhân (actors), quyết định (decisions) và cổng chất lượng (quality gates) được ánh xạ vào một quy trình nghiệp vụ thực tế (nhưng mô phỏng) trong bối cảnh ERP của Nova Foods, chúng ta sẽ xem xét luồng xử lý yêu cầu nhập nguyên liệu. Đây là một ví dụ có thể thực thi được về cách một nhà phân tích nghiệp vụ hình dung và tài liệu hóa một quy trình.

Mỗi bước trong quy trình nghiệp vụ cần được liên kết rõ ràng với các hiện vật tài liệu liên quan như yêu cầu (requirements), quy tắc nghiệp vụ (business rules), định danh truy xuất (traceability IDs) và các điểm kiểm tra chất lượng. Sơ đồ dưới đây trình bày một luồng nghiệp vụ đơn giản sử dụng ký hiệu kiểu Sơ đồ Hoạt động (Activity Diagram), thường được gọi là Ký hiệu Mô hình Quy trình Nghiệp vụ (BPMN - Business Process Model and Notation) ở cấp độ trừu tượng cao để dễ hiểu, nhưng không phải là một biểu đồ BPMN hoàn chỉnh theo tiêu chuẩn OMG.

lifecycle-artifact-map — diagram 1

Source plantuml — có thể chỉnh sửa

@startuml
skinparam handwritten true
skinparam monochrome true
skinparam packageStyle rectangle
skinparam defaultFontName "Arial"
skinparam defaultFontSize 14

title **Luồng Nghiệp vụ: Xử lý Yêu cầu Nhập Nguyên liệu (Nova Foods - Mô phỏng)**

start
:Bộ phận Sản xuất tạo Yêu cầu Nhập Nguyên liệu;
note right
  **Hiện vật:** Yêu cầu Nhập Nguyên liệu
  **Định danh Truy xuất:** `NF-REQ-IM-001`
end note

:Bộ phận Kế hoạch tiếp nhận;
:Kiểm tra tồn kho thực tế + số lượng đang đặt
so với ngưỡng tồn kho tối thiểu;

if (Tồn kho thực tế + số lượng đang đặt\n< ngưỡng tối thiểu theo `NF-BR-005`?) then (Có)
  :Trạng thái Đề xuất Mua hàng: chưa được phê duyệt;

  repeat
    :Bộ phận Mua hàng tạo/chỉnh sửa Đề xuất Mua hàng;
    note right
      **Hiện vật:** Đề xuất Mua hàng
      **Định danh Truy xuất:** `NF-PUR-PROP-001`
      Liên kết với `NF-REQ-IM-001`
    end note

    :Quản lý Mua hàng phê duyệt Đề xuất Mua hàng;
    if (Quản lý Mua hàng phê duyệt?) then (Có)
      if (Giá trị Đề xuất Mua hàng > 50.000.000 VND?) then (Có)
        :Kế toán trưởng phê duyệt Đề xuất Mua hàng;
        if (Kế toán trưởng phê duyệt?) then (Có)
          :Trạng thái Đề xuất Mua hàng: đã được phê duyệt;
        else (Không)
          :Trạng thái Đề xuất Mua hàng: chưa được phê duyệt;
          :Trả Đề xuất Mua hàng cho Bộ phận Mua hàng
          để chỉnh sửa/làm rõ;
        endif
      else (Không)
        :Trạng thái Đề xuất Mua hàng: đã được phê duyệt;
      endif
    else (Không)
      :Trạng thái Đề xuất Mua hàng: chưa được phê duyệt;
      :Trả Đề xuất Mua hàng cho Bộ phận Mua hàng
      để chỉnh sửa/làm rõ;
    endif

    :Cổng Chất lượng `NF-QG-002`:\nXác nhận Đề xuất Mua hàng đã được phê duyệt;
    note right
      Hai cấp phê duyệt khi giá trị
      > 50.000.000 VND:
      Quản lý Mua hàng và Kế toán trưởng
    end note
  repeat while (Trạng thái Đề xuất Mua hàng:\nchưa được phê duyệt?) is (Có)

  repeat
    :Bộ phận Mua hàng tạo/chỉnh sửa Đơn đặt hàng;
    note right
      **Hiện vật:** Đơn đặt hàng
      **Định danh Truy xuất:** `NF-PO-001`
    end note

    :Nhập Đơn đặt hàng vào hệ thống ERP;
    :Cổng Chất lượng `NF-QG-003`:\nKiểm tra dữ liệu PO và kết quả ghi nhận ERP;
    note right
      Kiểm tra `NF-BR-012`,
      `DD-PO-ITEM-QUANTITY`,
      và kết quả ghi nhận ERP
    end note

    if (Dữ liệu PO hợp lệ và ghi nhận ERP thành công?) then (Có)
      :Bộ phận Mua hàng gửi Đơn đặt hàng cho Nhà cung cấp;
      :Hoàn tất xử lý yêu cầu nhập nguyên liệu;
      end
    else (Không)
      :PO không được ghi nhận vào ERP;
      :Thông báo lỗi nhập liệu cho Bộ phận Mua hàng;
    endif
  repeat while (Dữ liệu PO chưa hợp lệ hoặc\nERP chưa ghi nhận thành công?) is (Có)

else (Không)
  :Không phát sinh nhu cầu mua do tồn kho + lượng đang đặt
  đạt/vượt ngưỡng tối thiểu;
  note right
    **Quyết định:** Dựa trên Quy tắc Nghiệp vụ `NF-BR-005`
  end note
  stop
endif

@enduml

Ánh xạ Hiện vật và Quyết định vào Luồng Nghiệp vụ Nova Foods (Dữ liệu tổng hợp)

Bảng sau đây chỉ ra cách các hiện vật tài liệu và điểm kiểm soát từ lộ trình học tập được liên kết với các bước cụ thể trong luồng nghiệp vụ mô phỏng ở trên. Mỗi hiện vật có một định danh (ID) duy nhất và liên kết với các tài liệu chuẩn hóa trong curriculum.

Loại Hiện vật	Định danh	Mô tả Bước/Quyết định trong Luồng	Chi tiết Áp dụng/Nội dung Mô phỏng	Liên kết Tài liệu Chuẩn (Canonical Source Link)
Yêu cầu (Requirement)	`NF-REQ-IM-001`	Bộ phận Sản xuất tạo Yêu cầu Nhập Nguyên liệu: Định nghĩa cấu trúc, các trường dữ liệu cần thiết của yêu cầu nhập, bao gồm loại nguyên liệu, số lượng, ngày cần.	Ví dụ: Yêu cầu `REQ-IM-001` cho 5000kg "Tinh bột khoai mì (Tapioca Starch)" mã `RM-TS-001`, cần trước `2026-09-15`.	`/01-curriculum/05-requirements-definition.md` (mô phỏng)
Quy tắc Nghiệp vụ (Business Rule)	`NF-BR-005`	Quyết định "Tồn kho hiện tại đủ cho sản xuất theo kế hoạch?": Xác định ngưỡng tồn kho tối thiểu cho mỗi loại nguyên liệu. Nếu tồn kho thực tế + số lượng đặt hàng < ngưỡng tối thiểu, mới được phép tạo yêu cầu mua.	`BR-005: Tồn kho nguyên liệu chính (RM-TS-001) < 1000kg` -> Cho phép tạo yêu cầu mua. Ngược lại, yêu cầu bị từ chối.	`/01-curriculum/CANONICAL_BUSINESS_RULES.md`
Định danh Truy xuất (Traceability ID)	`NF-PUR-PROP-001`	Bộ phận Mua hàng tạo Đề xuất Mua hàng: Cung cấp định danh duy nhất cho Đề xuất Mua hàng để theo dõi từ yêu cầu ban đầu đến đơn đặt hàng cuối cùng.	`NF-PUR-PROP-001` liên kết ngược về `NF-REQ-IM-001`, thể hiện một đề xuất cụ thể cho yêu cầu đã phát sinh.	`/01-curriculum/TRACEABILITY_ID_REGISTRY.md`
Cổng Chất lượng (Quality Gate)	`NF-QG-002`	Quyết định "Đề xuất được phê duyệt?": Quy định số lượng và cấp độ phê duyệt cần thiết cho một đề xuất mua hàng có giá trị trên một ngưỡng nhất định.	`QG-002: Đề xuất mua hàng > 50.000.000 VND` yêu cầu 2 cấp phê duyệt (Quản lý Mua hàng & Kế toán trưởng).	`/01-curriculum/12-quality-assurance.md` (mô phỏng)
Hiện vật (Artifact)	Đơn đặt hàng (PO)	Bộ phận Mua hàng gửi Đơn đặt hàng cho NCC: Mô tả cấu trúc, các trường dữ liệu bắt buộc và định dạng của Đơn đặt hàng gửi cho nhà cung cấp.	Đơn đặt hàng `NF-PO-001` có các thông tin nhà cung cấp, chi tiết mặt hàng, số lượng, giá, điều khoản thanh toán theo chuẩn Nova Foods.	`/01-curriculum/10-solution-design.md` (mô phỏng)
Quy tắc Nghiệp vụ (Business Rule)	`NF-BR-012`	Ghi nhận Đơn đặt hàng vào hệ thống ERP: Đảm bảo rằng dữ liệu của Đơn đặt hàng tuân thủ các quy tắc dữ liệu chính của hệ thống, ví dụ mã nguyên liệu phải tồn tại.	`BR-012: Mã nguyên liệu trong PO phải có trong danh mục master data của hệ thống ERP Nova Foods.`	`/01-curriculum/CANONICAL_BUSINESS_RULES.md`
Từ điển Dữ liệu (Data Dictionary)	`DD-PO-ITEM-QUANTITY`	Trường "Số lượng" trong Đơn đặt hàng: Định nghĩa kiểu dữ liệu, giới hạn giá trị và đơn vị đo lường cho các trường dữ liệu quan trọng trong Đơn đặt hàng.	Kiểu dữ liệu: `DECIMAL(10,3)`, Đơn vị: `kg`, Phạm vi: `>0`. Không chấp nhận số lượng âm hoặc không phải là số.	`/01-curriculum/CANONICAL_DATA_DICTIONARY.md`
Cổng Chất lượng (Quality Gate)	`NF-QG-003`	Quyết định "Dữ liệu Đơn đặt hàng hợp lệ và ghi nhận thành công?": Kiểm tra tính toàn vẹn và nhất quán của dữ liệu Đơn đặt hàng khi nhập vào hệ thống ERP.	`QG-003: Xác minh thành công` nếu PO vượt qua kiểm tra `NF-BR-012` và các quy tắc ràng buộc toàn vẹn dữ liệu khác của hệ thống.	`/01-curriculum/12-quality-assurance.md` (mô phỏng)

4. Senior Decision and Escalation Reference

4.1. Đánh đổi (Trade-offs) và Ra quyết định

Đánh đổi (Trade-offs) là các lựa chọn cần thực hiện khi các yêu cầu hoặc mục tiêu của dự án xung đột nhau, khiến việc đáp ứng đầy đủ tất cả trở nên bất khả thi hoặc quá tốn kém. Trong bối cảnh phân tích nghiệp vụ (Business Analysis - BA), chuyên viên BA có trách nhiệm nhận diện các xung đột này, phân tích tác động của từng phương án và trình bày rõ ràng cho các bên liên quan để ra quyết định. Việc này đảm bảo giải pháp tối ưu nhất được chọn dựa trên các ưu tiên nghiệp vụ tổng thể của Nova Foods, không chỉ đơn thuần là kỹ thuật. Theo BABOK Guide (Khu vực Kiến thức Phân tích Chiến lược), đánh đổi là một phần cốt lõi của việc định hình phạm vi giải pháp.

Loại Đánh đổi	Ví dụ (Nova Foods - mô phỏng)	Lý do phát sinh	Vai trò thẩm quyền chính
Tính năng vs. Thời gian	Thêm tính năng "Dự báo nhu cầu nâng cao" (`NF-FEAT-FCST-003`) làm tăng độ chính xác nhưng kéo dài thời gian triển khai 3 tháng.	Tài nguyên và thời gian dự án hữu hạn.	Giám đốc Dự án, Giám đốc Kinh doanh, Giám đốc Điều hành
Chi phí vs. Chất lượng	Sử dụng giải pháp mã nguồn mở (`NF-TECH-OS-001`) cho module quản lý kho để giảm chi phí cấp phép, nhưng có thể yêu cầu phát triển tùy chỉnh nhiều hơn và rủi ro bảo mật tiềm ẩn.	Nguồn ngân sách hạn chế, cần cân bằng giữa mức đầu tư ban đầu và tổng chi phí sở hữu, mức độ tuân thủ bảo mật (`OWASP ASVS`).	Giám đốc Tài chính, Giám đốc IT, Giám đốc Chuỗi cung ứng
Phức tạp vs. Dễ sử dụng	Triển khai giao diện người dùng (User Interface - UI) nhiều tùy chỉnh cho kế toán (`NF-UI-ACC-001`) để xử lý các nghiệp vụ đặc thù, nhưng làm tăng độ phức tạp cho người dùng mới và chi phí đào tạo.	Nhu cầu nghiệp vụ chuyên sâu đối lập với nguyên tắc trải nghiệm người dùng đơn giản.	Trưởng phòng Kế toán, Trưởng phòng Đào tạo, Trưởng phòng IT

4.2. Ngoại lệ (Exceptions) trong Quy trình và Dữ liệu

Ngoại lệ (Exceptions) là các trường hợp đặc biệt không tuân thủ quy trình nghiệp vụ (Business Process Flow) tiêu chuẩn hoặc quy tắc dữ liệu đã định. Mặc dù các quy trình được thiết kế để xử lý phần lớn các tình huống, ngoại lệ vẫn phát sinh và cần được định nghĩa rõ ràng, có điều kiện áp dụng cụ thể để đảm bảo sự linh hoạt mà vẫn duy trì kiểm soát. Việc không xác định rõ ngoại lệ có thể dẫn đến sự không nhất quán, lỗi hệ thống, hoặc rủi ro tuân thủ. Chuẩn ISO/IEC/IEEE 29148 nhấn mạnh tầm quan trọng của việc phân loại và quản lý yêu cầu, trong đó bao gồm cả các điều kiện đặc biệt.

Loại Ngoại lệ	Ví dụ (Nova Foods - mô phỏng)	Điều kiện áp dụng	Thẩm quyền phê duyệt quy tắc ngoại lệ
Quy trình nghiệp vụ	Yêu cầu phê duyệt cho các đơn hàng mua nguyên liệu vượt mức giới hạn chi tiêu thông thường.	Đơn hàng (`NF-PO-005`) có giá trị > 200.000.000 VND và nguyên liệu là "hàng hiếm" (`NF-ITEM-RARE-001`) cần 2 cấp phê duyệt thay vì 1.	Trưởng phòng Mua hàng, Giám đốc Chuỗi cung ứng
Quy tắc dữ liệu	Cho phép nhập giá bán sản phẩm (`NF-PROD-PRICE-001`) thấp hơn giá vốn trong một số trường hợp cụ thể.	Sản phẩm `NF-PROD-EXPIRED-002` cận date hoặc "hàng tồn kho lâu ngày" (`NF-INV-SLOW-001`) được phép bán phá giá tối đa 10% trong chương trình khuyến mãi đã duyệt.	Trưởng phòng Kinh doanh, Giám đốc Tài chính
Truy cập hệ thống	Cấp quyền truy cập tạm thời vào dữ liệu kế toán (`NF-DATA-ACC-003`) cho một kiểm toán viên bên ngoài.	Chỉ trong thời gian kiểm toán (`NF-AUDIT-2026`) từ `2026-09-01` đến `2026-09-15` và chỉ cho các báo cáo tài chính đã chọn, tuân thủ `Luật Kế toán` (`Luật 88/2015/QH13`).	Giám đốc Tài chính, Giám đốc IT, Trưởng phòng An ninh thông tin

4.3. Cờ đỏ (Red Flags) trong Phân tích Nghiệp vụ

Cờ đỏ (Red Flags) là những dấu hiệu cảnh báo sớm, cho thấy có những vấn đề tiềm ẩn nghiêm trọng có thể ảnh hưởng đến thành công của dự án, tính khả thi của giải pháp, hoặc sự tuân thủ quy định. Việc nhận diện và xử lý kịp thời các cờ đỏ này là rất quan trọng để tránh rủi ro lớn hơn về sau. Chuyên viên BA phải luôn cảnh giác và có khả năng nhận biết các dấu hiệu này từ giai đoạn sớm nhất của chu kỳ dự án.

Mã Cờ đỏ	Dấu hiệu nhận biết (Nova Foods - mô phỏng)	Tác động tiềm ẩn	BA cần làm gì ngay lập tức
`NF-RF-001`	Yêu cầu nghiệp vụ (`NF-REQ-001`) thay đổi liên tục và không có ghi nhận bằng văn bản chính thức (`NF-DOC-005`) cho từng phiên bản.	Phạm vi dự án không ổn định, lãng phí công sức, giải pháp không đúng nhu cầu thực tế.	Yêu cầu các bên liên quan xác nhận phạm vi (`NF-SCOPE-001`), ghi lại thay đổi vào nhật ký thay đổi (`NF-CHANGELOG-001`), và escalation cho Quản lý dự án.
`NF-RF-002`	Thiếu người ra quyết định (Business Owner) rõ ràng cho một yêu cầu quan trọng (`NF-REQ-002`).	Quyết định bị trì hoãn, xung đột giữa các bên, không có người chịu trách nhiệm cuối cùng.	Xác định và liên hệ với các bên liên quan cấp cao để chỉ định Business Owner chính thức, ghi nhận vào `TRACEABILITY_ID_REGISTRY.md`.
`NF-RF-003`	Dữ liệu nhạy cảm của khách hàng (`NF-DATA-CUSTOMER-001`) hoặc công thức sản xuất (`NF-DATA-RECIPE-002`) được thảo luận qua kênh không bảo mật (ví dụ: email cá nhân không mã hóa).	Vi phạm `Luật Bảo vệ dữ liệu cá nhân` (`Luật 91/2025/QH15`), rò rỉ thông tin độc quyền, tổn hại danh tiếng và pháp lý Nova Foods.	Dừng ngay cuộc thảo luận không an toàn, báo cáo cho Security Officer (`SEC_OFF`), và đảm bảo tuân thủ chính sách bảo mật dữ liệu của Nova Foods.
`NF-RF-004`	Các tài liệu đặc tả yêu cầu (Software Requirements Specification - SRS) (`NF-SRS-001`) không có sự đồng thuận hoặc phê duyệt chính thức từ các bên liên quan cốt lõi.	Giải pháp xây dựng không phản ánh đúng nhu cầu, dẫn đến rework lớn hoặc không được chấp nhận khi triển khai.	Tổ chức cuộc họp xác nhận yêu cầu, ghi nhận sự đồng thuận và phê duyệt chính thức, đảm bảo các bên liên quan ký xác nhận.

4.4. Thẩm quyền (Authority) Ra Quyết Định

Thẩm quyền (Authority) là quyền chính thức để đưa ra, phê duyệt, từ chối, hoặc yêu cầu thay đổi đối với các yêu cầu, thiết kế, quy trình, hoặc tài liệu dự án. Việc xác định rõ ràng người có thẩm quyền là yếu tố then chốt để dự án được triển khai một cách hiệu quả, tránh các tranh chấp và đảm bảo rằng các quyết định quan trọng được đưa ra bởi người phù hợp nhất. Chuyên viên BA phải hiểu rõ cấu trúc thẩm quyền của Nova Foods để biết ai cần được tham vấn, ai cần phê duyệt và ai là người ra quyết định cuối cùng cho từng loại quyết định.

Loại Quyết định	Ví dụ (Nova Foods - mô phỏng)	Vai trò có thẩm quyền chính	Lý do thẩm quyền	Tham chiếu Artifact (mô phỏng)
Thay đổi Quy trình	Thay đổi quy trình đặt hàng nhà cung cấp (`NF-PROC-PO-001`) để tích hợp hệ thống ERP (Enterprise Resource Planning) mới.	Giám đốc Chuỗi cung ứng (`SC_DIR`), Trưởng phòng Mua hàng (`PUR_LEAD`), Trưởng phòng Kế toán (`ACC_LEAD`).	Ảnh hưởng đến hoạt động mua sắm, thanh toán và quản lý tồn kho.	`/01-curriculum/CANONICAL_BUSINESS_RULES.md`
Phê duyệt Tính năng	Phê duyệt tính năng báo cáo doanh thu theo khu vực mới (`NF-FEAT-SALES-005`).	Giám đốc Kinh doanh (`SALES_DIR`), Giám đốc Tài chính (`CFO`).	Liên quan trực tiếp đến chiến lược kinh doanh và báo cáo tài chính.	`/01-curriculum/CHAPTER_MANIFEST.md` (chương liên quan)
Quy tắc Nghiệp vụ	Thiết lập quy tắc giảm giá tối đa cho các chương trình khuyến mãi.	Trưởng phòng Kinh doanh (`SALES_LEAD`), Trưởng phòng Marketing (`MKT_LEAD`).	Quyết định ảnh hưởng đến doanh thu, lợi nhuận và chiến lược thị trường.	`/01-curriculum/CANONICAL_BUSINESS_RULES.md` (`NF-BR-015`)
Phân loại Dữ liệu	Phân loại dữ liệu khách hàng là "nhạy cảm" (`NF-DATA-CLASS-001`) theo `Luật Bảo vệ dữ liệu cá nhân`.	Security Officer (`SEC_OFF`), Legal Officer (`LEGAL_OFF`).	Quyết định có ý nghĩa pháp lý và an ninh thông tin nghiêm trọng, yêu cầu tuân thủ `Luật 91/2025/QH15`.	`/01-curriculum/TRACEABILITY_ID_REGISTRY.md` (Mục phân loại thông tin)

Phân Biệt Sự Thật, Giả Định, Đề Xuất và Quyết Định

Để quản lý rủi ro và đảm bảo minh bạch trong mọi giai đoạn dự án, chuyên viên Phân tích nghiệp vụ (Business Analyst - BA) phải phân biệt rõ ràng bốn loại thông tin cốt lõi: Sự thật (Fact), Giả định (Assumption), Đề xuất (Recommendation), và Quyết định (Decision). Sự phân biệt này là nền tảng cho việc ra quyết định sáng suốt, quản lý kỳ vọng của các bên liên quan và kích hoạt quy trình leo thang (escalation) phù hợp khi cần. Dưới đây là hướng dẫn cụ thể trong bối cảnh Nova Foods mô phỏng.

Khái niệm (Concept)	Định nghĩa (Definition)	Đặc điểm chính (Key Characteristics)	Nguồn/Bằng chứng (Source/Evidence Type)	Bối cảnh Nova Foods (Simulated Nova Foods Context)
Sự thật (Fact)	Thông tin đã được xác minh, quan sát trực tiếp, hoặc được ghi nhận từ nguồn đáng tin cậy không thể nghi ngờ. Đây là yếu tố nền tảng khách quan.	Khách quan; có thể kiểm tra lại (verifiable); có bằng chứng rõ ràng; được đồng thuận rộng rãi hoặc chấp nhận là đúng.	Dữ liệu hệ thống hiện hành (VD: Nova Foods ERP log truy cập), tài liệu pháp lý đã ban hành (Luật 91/2025/QH15 - Luật Bảo vệ dữ liệu cá nhân), chuẩn ngành đã công bố (OAS 3.1.1 từ OpenAPI Specification), kết quả quan sát trực tiếp được ghi nhận, hoặc xác nhận của Chủ sở hữu nghiệp vụ (Business Owner) về hiện trạng vận hành.	Trong ngữ cảnh mô phỏng giáo dục, "sự thật" thường liên quan đến các đặc tả kỹ thuật của chuẩn ngành (VD: cú pháp API theo OAS 3.1.1) hoặc thông tin quản trị artifact (VD: trạng thái `Status: IN_REVIEW` được ghi nhận trong `/00-research/00_SOURCE_MAP.md`). Mọi "sự thật" về nghiệp vụ Nova Foods phải được gắn nhãn "dữ liệu tổng hợp" và không đại diện cho hoạt động kinh doanh thực, theo điều khoản `SRC-READY-010` trong `/00-research/00_SOURCE_MAP.md`.
Giả định (Assumption)	Một yếu tố được chấp nhận là đúng mà không có bằng chứng xác thực tại thời điểm hiện tại, nhằm mục đích tiến hành phân tích, kế hoạch hoặc thiết kế, nhưng cần được xác minh trong tương lai.	Có thể sai; mang rủi ro tiềm ẩn; cần được xác minh sau; thường được ghi nhận để kiểm soát và quản lý rủi ro.	Thiếu thông tin hoặc chờ xác nhận chính thức từ bên có thẩm quyền. Ví dụ: "Nova Foods dự kiến mở rộng quy trình sản xuất sản phẩm đóng gói chân không vào Q4/2027" (chưa có phê duyệt ngân sách hoặc kế hoạch kinh doanh chính thức).	Mọi yêu cầu hoặc quy tắc nghiệp vụ liên quan đến tương lai của Nova Foods (ví dụ: mở rộng thị trường, tính năng mới) mà không có nguồn tham chiếu baseline hoặc approval rõ ràng từ `/01-curriculum/CANONICAL_BUSINESS_RULES.md` đều là giả định. Chúng là cần thiết cho các bài tập trong curriculum nhưng phải được ghi nhãn rõ để tránh hiểu lầm, phù hợp với nguyên tắc "chưa có baseline/approval" của `CANONICAL_BUSINESS_RULES`.
Đề xuất (Recommendation)	Một gợi ý về hành động, giải pháp, hoặc phương pháp tiếp cận được đề xuất sau khi phân tích các lựa chọn khả thi và đánh giá ưu nhược điểm.	Cần được xem xét, thảo luận và phê duyệt bởi bên có thẩm quyền; thường kèm theo phân tích lợi ích/chi phí (cost/benefit analysis) hoặc các đánh đổi (trade-offs) khác.	Kết quả phân tích yêu cầu nghiệp vụ, nghiên cứu giải pháp công nghệ, đánh giá hệ thống, hoặc báo cáo khả thi. Ví dụ: "Đề xuất triển khai module quản lý kho tự động cho Nova Foods để tối ưu quy trình nhận hàng dựa trên các hướng dẫn của ISTQB CTFL về kiểm thử."	Các giải pháp hoặc phương án mà BA trình bày cho Nova Foods (mô phỏng) đều là đề xuất. Chúng dựa trên các "giả định" hoặc "sự thật" đã có nhưng chưa phải là "quyết định" cho đến khi có sự "phê duyệt" rõ ràng từ một vai trò có thẩm quyền (mô phỏng).
Quyết định (Decision)	Một sự lựa chọn cuối cùng về một phương án hành động, được đưa ra bởi người hoặc tổ chức có thẩm quyền, đòi hỏi cam kết về tài nguyên và nguồn lực.	Có ràng buộc (binding); có tác động trực tiếp đến dự án và nghiệp vụ; cần được ghi lại rõ ràng để làm bằng chứng truy vết (traceability); yêu cầu thẩm quyền phê duyệt chính thức.	Biên bản cuộc họp phê duyệt, email xác nhận từ cấp quản lý cao nhất, hoặc tài liệu baseline đã được ký và thông qua. Các artifact quản trị như `/01-curriculum/01_CURRICULUM_ARCHITECTURE.md` và `/01-curriculum/CHAPTER_MANIFEST.md` đều ghi rõ `Chưa có baseline reference tại v0.9.0` và `Chưa có approval reference`. Điều này ngụ ý các nội dung trong các artifact này không phải là "quyết định" vận hành thực tế.	Trong curriculum này, "quyết định" chỉ mang tính mô phỏng. Mọi "quyết định" về quy tắc nghiệp vụ, kiến trúc hệ thống hoặc yêu cầu chức năng cho Nova Foods (simulated) phải được gán cho một vai trò giả định có thẩm quyền (VD: "Phê duyệt bởi Ban Giám đốc Nova Foods mô phỏng") và không được xem là đã được thực hiện hoặc có ràng buộc pháp lý/nghiệp vụ. `/01-curriculum/01_CURRICULUM_ARCHITECTURE.md` khẳng định rõ: `Owner không có quyền tự xác nhận baseline, approval`.

Việc phân biệt chính xác các khái niệm trên giúp BA xây dựng tài liệu vững chắc, quản lý kỳ vọng của bên liên quan một cách hiệu quả, và biết khi nào cần leo thang vấn đề (escalate issues) để có được thông tin xác thực hoặc quyết định từ các cấp có thẩm quyền. Trong môi trường Nova Foods mô phỏng, mỗi thông tin cần được gắn nhãn phù hợp để đảm bảo tính giáo dục và tránh hiểu lầm về thẩm quyền hoặc trạng thái phê duyệt thực tế.

Kích hoạt và Chủ sở hữu Leo thang (Escalation Triggers and Owners)

Leo thang vấn đề (escalation) là đưa vấn đề không giải quyết được lên cấp thẩm quyền cao hơn. Trong Nova Foods (mô phỏng), escalation đảm bảo quyết định quan trọng do vai trò giả định có năng lực chuyên môn đưa ra, duy trì tính toàn vẹn học liệu. Principal IT Business Analyst / Technical Curriculum Author (Tác giả Chương trình giảng dạy/Phân tích Nghiệp vụ CNTT Chính) chuẩn bị gói thông tin escalation, không thay thế thẩm quyền quyết định vai trò chuyên môn. Yếu tố kích hoạt escalation dựa trên nguyên tắc phân chia thẩm quyền, rủi ro, phù hợp /01-curriculum/TRACEABILITY_ID_REGISTRY.md và /01-curriculum/CANONICAL_BUSINESS_RULES.md.

ID Kích hoạt	Sự kiện Kích hoạt (Escalation Trigger)	Mô tả Chi tiết (Detailed Description)	Chủ sở hữu Leo thang (Escalation Owner) (Nova Foods mô phỏng)	Tham chiếu Nguồn (Source Reference)
ESCAL-001	Xung đột Thẩm quyền Chuyên môn	Đề xuất/giải pháp ảnh hưởng hai+ lĩnh vực chuyên môn (nghiệp vụ, pháp lý, kế toán, bảo mật, kỹ thuật); bên liên quan không thống nhất.	Business Owner (Nghiệp vụ), Legal Owner (Pháp lý), Accounting Owner (Kế toán), Security Owner (Bảo mật), Technical Architect (Kiến trúc Sư Kỹ thuật) - theo lĩnh vực ảnh hưởng.	`/01-curriculum/TRACEABILITY_ID_REGISTRY.md` (SRC-TRC-005): "khi một đề xuất đồng thời thuộc từ hai vai trò trở lên"
ESCAL-002	Mâu thuẫn Nguồn Chân lý (Canonical Source Conflict)	Artifact học liệu mâu thuẫn trực tiếp nguồn chân lý đã xác minh (ví dụ: Luật Bảo vệ dữ liệu cá nhân Việt Nam `Luật 91/2025/QH15`, `OWASP ASVS 5.0.0`, `Luật 88/2015/QH13`).	Legal Owner (Pháp lý), Accounting Owner (Kế toán), Security Owner (Bảo mật), Technical Architect (Kiến trúc Sư Kỹ thuật) - theo nguồn chân lý mâu thuẫn.	`/01-curriculum/TRACEABILITY_ID_REGISTRY.md` (SRC-TRC-005): "khi nguồn canonical mâu thuẫn với cách hiểu của artifact"
ESCAL-003	Quyết định có Ngụ ý Pháp lý/Vận hành	BA cần ra/đề xuất quyết định (ví dụ: chọn ID giao dịch, định nghĩa trường dữ liệu bắt buộc); lựa chọn đó diễn giải thành quyết định pháp lý, kế toán, bảo mật, kiến trúc hệ thống, hoặc vận hành production thực tế Nova Foods (mô phỏng).	Business Owner (Nghiệp vụ), Legal Owner (Pháp lý), Accounting Owner (Kế toán), Security Owner (Bảo mật), Technical Architect (Kiến trúc Sư Kỹ thuật) - theo bản chất quyết định.	`/01-curriculum/TRACEABILITY_ID_REGISTRY.md` (SRC-TRC-005): "khi việc chọn ID có thể bị diễn giải thành quyết định pháp lý, kế toán, kiến trúc, bảo mật hay vận hành thực tế"
ESCAL-004	Thiếu Thông tin Quyết định Quan trọng	BA không thể tiếp tục phân tích do thiếu thông tin nghiệp vụ cốt lõi, yêu cầu kỹ thuật rõ ràng, hoặc không đồng thuận cần thiết từ bên liên quan chính Nova Foods (mô phỏng). Ảnh hưởng tiến độ, chất lượng.	Business Owner (Nghiệp vụ), Project Manager (Quản lý Dự án).	Nguyên tắc quản lý dự án cơ bản: ngăn chặn tắc nghẽn.
ESCAL-005	Thay đổi Phạm vi (Scope Change) Không được Phê duyệt	Yêu cầu thay đổi phạm vi dự án/sản phẩm không tuân thủ quy trình kiểm soát thay đổi Nova Foods (mô phỏng). Thay đổi có tác động lớn ngân sách, thời gian, tài nguyên.	Project Manager (Quản lý Dự án), Business Owner (Nghiệp vụ).	Nguyên tắc quản lý phạm vi `BABOK Guide` (`Strategy Analysis`, `Requirements Life Cycle Management`).

Principal IT Business Analyst / Technical Curriculum Author (tác giả chương trình giảng dạy) khởi xướng escalation. Chuẩn bị gói vấn đề rõ ràng (vấn đề, phương án xem xét, tác động, bên liên quan, yêu cầu quyết định) và đảm bảo truy vết (traceability). Mục đích: Chủ sở hữu Leo thang có đủ thông tin, ra quyết định hiệu quả, có thẩm quyền.

5. Quick Checks and Cross-File QA

Đây là danh sách kiểm tra nhanh (quick-reference checklist) để đảm bảo tính nhất quán và chất lượng giữa các artifact (tài liệu hoặc sản phẩm công việc) trong corpus (tập hợp tài liệu) Nova Foods (mô phỏng). Kiểm tra này tập trung vào các quy tắc quản trị cơ bản và tính toàn vẹn của dữ liệu mô phỏng theo hợp đồng đóng băng v0.9.0 ngày 2026-08-07.

Mục kiểm tra nhanh	Mô tả kiểm tra và Lý do	Tham chiếu hoặc Kết quả mong đợi
1. Định danh Artifact (Artifact ID Consistency)	Xác minh `Artifact ID` trong phần metadata của tài liệu khớp chính xác với đường dẫn tệp chuẩn (canonical filename path) và các tham chiếu nội bộ. Lý do: Đảm bảo truy vết (traceability) và liên kết chính xác giữa các tài liệu, tránh nhầm lẫn giữa các phiên bản hoặc tài liệu liên quan.	Ví dụ: Tệp `/01-curriculum/TRACEABILITY_ID_REGISTRY.md` phải có `Artifact ID: TRACEABILITY_ID_REGISTRY` trong metadata của chính nó.
2. Trạng thái & Phiên bản (Status & Version Alignment)	Kiểm tra `Status` của artifact phải là `IN_REVIEW` và `Version` là `v0.9.0` theo đúng hợp đồng đóng băng. Lý do: Tránh hiểu lầm về mức độ hoàn thiện, mức độ phê duyệt (approval) và sẵn sàng cho môi trường sản xuất (production).	Không có `Status: APPROVED` hoặc `BASELINED` (đường nền, phiên bản được chấp thuận chính thức) được chấp nhận ở giai đoạn này. Luôn tham chiếu metadata `Status` và `Version` của artifact.
3. Nhãn Nova Foods Mô phỏng (Nova Foods Simulation Label)	Đảm bảo mọi đề cập đến "Nova Foods Trading & Manufacturing" đều kèm theo nhãn "mô phỏng giáo dục, dữ liệu tổng hợp" hoặc chuỗi tương đương xác nhận tính chất giả định. Lý do: Nhấn mạnh tính chất case study giáo dục, ngăn chặn mọi suy diễn về hoạt động kinh doanh thực tế hoặc tình trạng tuân thủ pháp luật của Nova Foods.	Tham chiếu quy tắc `SRC-READY-010` từ `/00-research/00_SOURCE_MAP.md`: "Nova Foods được giữ đúng tính chất mô phỏng".
4. Giới hạn Thẩm quyền Owner (Owner Authority Limits)	Xác nhận các đoạn `Giới hạn thẩm quyền Owner` trong phần metadata của từng artifact được ghi nhận nhất quán và rõ ràng. `Owner` (chủ sở hữu tài liệu) không có quyền tự phê duyệt pháp lý, kế toán, vận hành, hoặc thiết lập đường nền (baseline) cho artifact. Lý do: Làm rõ vai trò, trách nhiệm, và phạm vi quyền hạn của `Owner`, tránh vượt quyền.	Ví dụ: "Owner không có quyền tự xác nhận baseline, approval, legal/compliance sign-off, quyết định kế toán, quyết định vận hành Nova Foods hoặc quyết định triển khai production." từ `/01-curriculum/01_CURRICULUM_ARCHITECTURE.md`.
5. Múi giờ & Locale Chuẩn (Standard Timezone & Locale)	Kiểm tra `Timezone` (múi giờ) là `Asia/Ho_Chi_Minh` và `Locale` (vùng/ngôn ngữ) là `vi-VN` (với `VND` cho đơn vị tiền tệ mô phỏng). Lý do: Chuẩn hóa bối cảnh địa lý, văn hóa, và định dạng dữ liệu cho toàn bộ corpus, đảm bảo tính thống nhất trong ghi nhận thời gian và định dạng số.	Luôn tham chiếu metadata `Timezone` và `Locale` của artifact.
6. Tham chiếu Nguồn Canonical (Canonical Source Reference)	Mọi nguồn bên ngoài được tham chiếu (ví dụ: `BABOK Guide`, `Luật Kế toán`) phải được liệt kê đầy đủ và mô tả rõ ràng giới hạn sử dụng trong tài liệu `/00-research/00_SOURCE_MAP.md`. Lý do: Đảm bảo tính hợp lệ của nguồn và tuân thủ giới hạn sử dụng đã định nghĩa, tránh sử dụng nguồn sai mục đích hoặc vượt thẩm quyền.	Kiểm tra URL, `Safe use boundary` (ranh giới sử dụng an toàn) trong `/00-research/00_SOURCE_MAP.md` cho từng nguồn.
7. Không có Approval Ngầm định (No Implicit Approval)	Xác minh không có ngôn ngữ hoặc ý nghĩa nào ngụ ý phê duyệt (approval) hoặc thiết lập đường nền (baseline) chỉ từ sự tồn tại của artifact, metadata, hoặc vai trò `Owner`. Lý do: Ngăn chặn hiểu lầm về trạng thái phê duyệt; mọi phê duyệt phải được ghi nhận minh bạch và có tham chiếu cụ thể đến quyết định của vai trò có thẩm quyền.	Ví dụ: "Chưa có approval reference tại `v0.9.0`; không có approval ngầm định từ việc Owner duy trì artifact hoặc từ sự tồn tại của metadata này." từ `/01-curriculum/CHAPTER_MANIFEST.md`.

3. Kiểm Tra Liên Kết Chéo và Nguồn Chuẩn

Mục này cung cấp hướng dẫn kiểm tra tính toàn vẹn của các liên kết chéo (cross-links) trong corpus Nova Foods và xác minh các nguồn chuẩn (canonical sources). Việc này đảm bảo thông tin nhất quán, đáng tin cậy và có khả năng truy vết (traceability) cao, đặc biệt quan trọng trong môi trường hệ thống hoạch định tài nguyên doanh nghiệp (ERP - Enterprise Resource Planning) mô phỏng.

3.1. Nguồn Chuẩn và Giới Hạn Sử Dụng

Bảng sau liệt kê các nguồn chuẩn được tham chiếu trong corpus Nova Foods, cùng với phiên bản, URL chính thức và giới hạn sử dụng an toàn. Mọi tham chiếu đến các nguồn này phải tuân thủ nghiêm ngặt các giới hạn đã nêu. Việc sử dụng sai mục đích hoặc vượt quá giới hạn có thể dẫn đến suy diễn sai lệch trong case study Nova Foods mô phỏng, vì Nova Foods chỉ là một doanh nghiệp mô phỏng giáo dục, mọi dữ liệu là dữ liệu tổng hợp (synthetic data).

Nguồn	Tổ chức phát hành	Phiên bản/Trạng thái	URL chính thức	Mục đích sử dụng chính	Giới hạn sử dụng an toàn
BABOK Guide	IIBA	Version 3; official overview and errata	https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/	Khung kiến thức BA: lĩnh vực kiến thức, nhiệm vụ, năng lực và thuật ngữ chuyên ngành (terminology).	Không tự ý tạo số trang hoặc điều khoản. Toàn văn yêu cầu cấp phép.
ISO/IEC/IEEE 29148	ISO/IEC/IEEE	29148:2018, Edition 2; confirmed 2024 and marked to be revised in 2026	https://www.iso.org/standard/72089.html	Tóm tắt và trạng thái thư mục chuẩn kỹ thuật phần mềm và hệ thống (systems and software engineering).	Các điều khoản chính xác cần xác minh với văn bản có bản quyền.
BPMN	OMG	BPMN 2.0.2	https://www.omg.org/spec/BPMN/2.0.2/About-BPMN/	Quy cách chuẩn mực (normative source) cho ký hiệu Mô hình và Ký hiệu Quy trình Nghiệp vụ (Business Process Model and Notation) thực tế.	Không gọi sơ đồ hoạt động PlantUML là BPMN.
UML	OMG	UML 2.5.1	https://www.omg.org/spec/UML/2.5.1/About-UML/	Quy cách chuẩn mực cho ngữ nghĩa Ngôn ngữ Mô hình Hợp nhất (Unified Modeling Language).
ISTQB CTFL	ISTQB	CTFL Syllabus v4.0.1	https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf	Giáo trình Kiểm thử (Testing) chính cho thuật ngữ và kỹ thuật hộp đen (black-box techniques).
OpenAPI Specification	OpenAPI Initiative	OAS 3.1.1, published 2024-10-24	https://spec.openapis.org/oas/v3.1.1.html	Quy cách chuẩn mực cho tính năng Đặc tả OpenAPI (OpenAPI Specification) 3.1 và mô tả Giao diện lập trình ứng dụng HTTP (HTTP API descriptions).
WCAG	W3C	WCAG 2.2 Recommendation, 2024-12-12 edition	https://www.w3.org/TR/WCAG22/	Khuyến nghị chuẩn mực về khả năng tiếp cận nội dung Web (Web Content Accessibility Guidelines).	Yêu cầu về tiêu chí thành công phải khớp chính xác với nguồn.
OWASP ASVS	OWASP Foundation	ASVS 5.0.0 listed as latest stable	https://owasp.org/www-project-application-security-verification-standard/	Tiêu chuẩn xác minh bảo mật ứng dụng (Application Security Verification Standard) ngành.	Không coi đây là luật pháp Việt Nam.
OWASP API Security Top 10	OWASP Foundation	2023 edition	https://owasp.org/API-Security/editions/2023/en/0x11-t10/	Thực hành tốt và nhận thức ngành về bảo mật API.	Không phải tiêu chuẩn pháp lý bắt buộc.
Luật Bảo vệ dữ liệu cá nhân	Quốc hội Việt Nam	Luật 91/2025/QH15; effective 2026-01-01	https://vanban.chinhphu.vn/?classid=1&docid=214590&pageid=27160&typegroup=	Nguồn pháp lý chính thức về bảo vệ dữ liệu cá nhân.	Yêu cầu pháp lý cần xác minh bởi chủ sở hữu pháp lý.
Nghị định hướng dẫn bảo vệ dữ liệu cá nhân	Chính phủ Việt Nam	Nghị định 356/2025/NĐ-CP; effective 2026-01-01	https://vanban.chinhphu.vn/?classid=1&docid=216387&pageid=27160	Nguồn pháp lý chính thức.	Xác minh sửa đổi bổ sung trước khi áp dụng vào thực tế.
Luật Kế toán	Quốc hội Việt Nam	Luật 88/2015/QH13; effective 2017-01-01	https://vanban.chinhphu.vn/?docid=183198&pageid=27160	Nguồn pháp lý chính thức về kế toán.	Diễn giải kế toán cần vai trò kế toán/pháp lý có thẩm quyền.
Hóa đơn, chứng từ	Chính phủ Việt Nam	Nghị định 123/2020/NĐ-CP; effective 2022-07-01	https://vanban.chinhphu.vn/?docid=201365&pageid=27160	Nguồn pháp lý chính thức về hóa đơn, chứng từ.	Xác minh sửa đổi bổ sung trước khi áp dụng vào thực tế.
Luật An toàn thực phẩm	Quốc hội Việt Nam	Luật 55/2010/QH12	https://vanban.chinhphu.vn/?docid=96032&pageid=27160	Nguồn pháp lý chính thức về an toàn thực phẩm.	Cần xác minh bởi chủ nghiệp vụ và chủ sở hữu pháp lý.
Lưu ý: Ngày truy cập cho tất cả các URL là `2026-08-07`.

3.2. Quy Tắc Kiểm Tra Liên Kết Chéo Nội Bộ Nova Foods

Mọi liên kết chéo trong corpus Nova Foods phải tuân thủ các quy tắc sau để đảm bảo tính nhất quán quản trị và tránh hiểu lầm trong bối cảnh giáo dục mô phỏng.

Sử dụng Định danh Canonical (Canonical ID) cho tạo tác:
- Nguyên tắc: Mọi tham chiếu đến một tạo tác (artifact) nội bộ Nova Foods (ví dụ: 00_SOURCE_MAP, CHAPTER_MANIFEST, GEN-REQ-001, NF-DD-005) phải sử dụng Định danh Canonical (Canonical ID) của tạo tác đó, không dùng tên tệp rút gọn hoặc tên gợi nhớ.
- Lý do: Đảm bảo khả năng truy vết (traceability) rõ ràng đến nguồn gốc duy nhất được đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Tránh nhầm lẫn khi tên tệp có thể thay đổi hoặc có nhiều bản sao trong quá trình phát triển học liệu.
- Ví dụ sai: "Xem bản đồ nguồn."
- Ví dụ đúng: "Tham khảo 00_SOURCE_MAP tại /00-research/00_SOURCE_MAP.md."
Xác minh Phiên bản (Version) và Trạng thái (Status) của tạo tác được liên kết:
- Nguyên tắc: Khi liên kết chéo, phải ghi rõ phiên bản (v0.9.0) và trạng thái (IN_REVIEW, BASELINED, APPROVED) của tạo tác được tham chiếu.
- Lý do: Trạng thái IN_REVIEW (đang xem xét) không có nghĩa là APPROVED (đã phê duyệt) hoặc BASELINED (đã có đường cơ sở). Mọi nội dung Nova Foods mô phỏng đang ở trạng thái IN_REVIEW chỉ là kế hoạch học liệu, không phải quy định vận hành hoặc yêu cầu thực tế đã được chấp thuận. Tham khảo trường Status và Version trong siêu dữ liệu quản trị của các tạo tác phụ thuộc như /01-curriculum/01_CURRICULUM_ARCHITECTURE.md, /01-curriculum/CHAPTER_MANIFEST.md hoặc /01-curriculum/TEMPLATE_MANIFEST.md.
- Ví dụ sai: "Yêu cầu nghiệp vụ được mô tả trong tài liệu yêu cầu (phiên bản mới nhất)."
- Ví dụ đúng: "Yêu cầu NF-REQ-001 (từ /02-handbook/03-requirements.md v0.9.0, trạng thái IN_REVIEW) quy định..."
Tuân thủ Giới hạn Thẩm quyền Owner của tạo tác:
- Nguyên tắc: Khi trích dẫn nội dung từ một tạo tác, phải đảm bảo rằng nội dung đó nằm trong giới hạn thẩm quyền (authority boundary) của Owner (người chịu trách nhiệm) tạo tác đó. Ví dụ, Owner là "Principal IT Business Analyst / Technical Curriculum Author" không có thẩm quyền phê duyệt pháp lý, kế toán, bảo mật hoặc vận hành ERP thực tế.
- Lý do: Ngăn chặn việc suy diễn sai thẩm quyền hoặc biến nội dung giáo dục mô phỏng thành quyết định nghiệp vụ thực tế. Tham khảo trường Giới hạn thẩm quyền của Owner trong tất cả các tạo tác phụ thuộc (ví dụ: /00-research/00_SOURCE_MAP.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md).
- Ví dụ sai: "Owner đã phê duyệt quy tắc nghiệp vụ NF-BR-005 về tính thuế cho Nova Foods."
- Ví dụ đúng: "Quy tắc nghiệp vụ NF-BR-005 (từ /01-curriculum/CANONICAL_BUSINESS_RULES.md, v0.9.0, trạng thái IN_REVIEW) mô tả logic tính thuế, cần xác nhận từ Legal/Accounting Owner (chủ sở hữu pháp lý/kế toán)."
Nhấn mạnh tính Mô phỏng của Nova Foods:
- Nguyên tắc: Mọi thông tin liên quan đến Nova Foods (tên tổ chức, quy trình, ID, ví dụ và dữ liệu) phải luôn được hiểu là mô phỏng giáo dục và chỉ sử dụng dữ liệu tổng hợp (synthetic data).
- Lý do: Ngăn chặn mọi hiểu lầm rằng Nova Foods là một doanh nghiệp có thật, có cấu hình ERP thực tế hoặc đã đạt tuân thủ (compliance) các quy định đã được xác nhận. Tham khảo SRC-READY-010 trong /00-research/00_SOURCE_MAP.md và trường Case study trong các siêu dữ liệu quản trị của mọi tạo tác.
- Ví dụ sai: "Hệ thống ERP của Nova Foods đang xử lý hóa đơn theo Nghị định 123/2020/NĐ-CP."
- Ví dụ đúng: "Case study Nova Foods mô phỏng việc xử lý hóa đơn theo các nguyên tắc từ Nghị định 123/2020/NĐ-CP (như nguồn chuẩn đã nêu)."
Yêu cầu Xác minh Pháp lý, Kế toán, Bảo mật rõ ràng:
- Nguyên tắc: Bất kỳ yêu cầu hoặc quy tắc nghiệp vụ nào được suy ra từ các nguồn pháp lý, kế toán hoặc bảo mật (ví dụ: Luật Bảo vệ dữ liệu cá nhân, Luật Kế toán, OWASP ASVS) đều phải được gắn nhãn Verification required (cần xác minh) hoặc Project assumption (giả định dự án) trừ khi có bằng chứng rõ ràng về sự xác nhận từ vai trò có thẩm quyền (Legal Owner, Accounting Owner, Security Owner).
- Lý do: Tránh việc diễn giải sai các quy định pháp lý/chuẩn mực thành yêu cầu hệ thống bắt buộc mà không có sự kiểm tra từ chuyên gia. Tham khảo Quy tắc kích hoạt chung trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md và giới hạn trong bảng nguồn chuẩn.

3.3. Quy Tắc Lan Truyền Thay Đổi

Khi một nguồn chuẩn (canonical source) hoặc một tạo tác nội bộ Nova Foods được tham chiếu thay đổi phiên bản, trạng thái hoặc nội dung, mọi tạo tác liên kết chéo (cross-linked artifacts) cần được đánh giá lại.

Đánh giá: Kiểm tra xem sự thay đổi có ảnh hưởng đến tính hợp lệ hoặc ngữ cảnh của tham chiếu hiện tại không.
Cập nhật: Nếu có ảnh hưởng, tạo tác liên kết cần được cập nhật để phản ánh phiên bản, trạng thái hoặc nội dung mới, đồng thời cập nhật siêu dữ liệu quản trị liên quan.
Ghi nhận: Ghi lại việc đánh giá và cập nhật trong lịch sử thay đổi của tạo tác liên quan, bao gồm ngày và lý do thay đổi.

Việc tuân thủ các quy tắc này là bắt buộc để duy trì tính chính xác và tin cậy của toàn bộ corpus Nova Foods, đặc biệt quan trọng cho mục tiêu giáo dục của chương trình.

5.3. Vấn đề xác minh đang mở và Quy tắc lan truyền thay đổi

Tài liệu này xác định các "vấn đề xác minh đang mở" (open verification issues) cần hành động bổ sung để đạt trạng thái "baseline" (thiết lập chuẩn gốc) hoặc "phê duyệt" (approval) chính thức. Đồng thời, nó phác thảo "quy tắc lan truyền thay đổi" (change-propagation rules) nhằm đảm bảo tính toàn vẹn và nhất quán của tập tài liệu Nova Foods (simulated Nova Foods ERP corpus) khi có thay đổi. Mục tiêu là duy trì "traceability" (khả năng truy vết) và "governance" (quản trị) chặt chẽ trong suốt vòng đời phát triển curriculum.

Vấn đề xác minh đang mở

Các tài liệu kiểm soát chính của curriculum hiện đang ở trạng thái IN_REVIEW (đang xem xét). Trạng thái này NGHIÊM CẤM suy diễn rằng tài liệu đã được "phê duyệt", "baseline", "sẵn sàng cho sản xuất" (production-ready), "tuân thủ" (compliant) hoặc đã được người dùng chấp thuận. Mọi yêu cầu nghiệp vụ Nova Foods (simulated Nova Foods business requirements) hay dữ liệu chi tiết phải được xác minh chính thức.

Bảng 1: Danh mục Vấn đề xác minh đang mở của tập tài liệu Nova Foods

Mã vấn đề	Artifact ảnh hưởng	Trạng thái hiện tại	Lý do cần xác minh (tham chiếu nguồn)	Cơ chế xác minh đề xuất
VER-001	`/00-research/00_SOURCE_MAP.md`	`IN_REVIEW`, `v0.9.0`	Nguồn cấp cho toàn bộ corpus chưa có "baseline reference" (tham chiếu chuẩn gốc) hoặc "approval reference" (tham chiếu phê duyệt). Không có thẩm quyền pháp lý, kế toán, nghiệp vụ. (Tham chiếu: `/00-research/00_SOURCE_MAP.md`, metadata `Trạng thái baseline`, `Trạng thái phê duyệt`)	Cần "legal owner" (chủ sở hữu pháp lý), "accounting owner" (chủ sở hữu kế toán) và "business owner" (chủ sở hữu nghiệp vụ) phê duyệt nguồn pháp lý, kế toán, nghiệp vụ.
VER-002	`/01-curriculum/01_CURRICULUM_ARCHITECTURE.md`	`IN_REVIEW`, `v0.9.0`	Kiến trúc curriculum chưa được phê duyệt, có thể tạo ra "mâu thuẫn chuỗi học" (learning chain conflict) hoặc "đứt traceability" (đứt truy vết). (Tham chiếu: `/01-curriculum/01_CURRICULUM_ARCHITECTURE.md`, mục `Điều kiện dừng`)	"Curriculum Owner" và "Senior BA" cần xem xét và phê duyệt kiến trúc, đảm bảo tính toàn vẹn của "learning path" (lộ trình học).
VER-003	`/01-curriculum/CHAPTER_MANIFEST.md`	`IN_REVIEW`, `v0.9.0`	Danh mục chương (chapter manifest) và nội dung dự kiến chưa có "baseline" hoặc "approval". (Tham chiếu: `/01-curriculum/CHAPTER_MANIFEST.md`, metadata `Trạng thái tham chiếu baseline`, `Trạng thái tham chiếu approval`)	"Curriculum Owner" cần phê duyệt danh mục và phạm vi các chương.
VER-004	`/01-curriculum/TEMPLATE_MANIFEST.md`	`IN_REVIEW`, `v0.9.0`	Danh mục template và yêu cầu output của chúng chưa có "baseline" hoặc "approval". (Tham chiếu: `/01-curriculum/TEMPLATE_MANIFEST.md`, metadata `Baseline reference`, `Approval reference`)	"Curriculum Owner" và "Technical Architect" cần phê duyệt cấu trúc và nội dung của các template.
VER-005	`/01-curriculum/TRACEABILITY_ID_REGISTRY.md`	`IN_REVIEW`, `v0.9.0`	Hệ thống định danh truy vết (traceability ID registry) và quy tắc "escalation" (leo thang vấn đề) chưa được phê duyệt chính thức. (Tham chiếu: `/01-curriculum/TRACEABILITY_ID_REGISTRY.md`, metadata `Status`)	Cần "Principal IT BA" và "Project Manager" phê duyệt registry và quy trình escalation.
VER-006	`/01-curriculum/CANONICAL_BUSINESS_RULES.md`	`IN_REVIEW`, `v0.9.0`	"Catalog quy tắc nghiệp vụ" (canonical business rules catalog) chưa có "baseline" hoặc "approval" cho bất kỳ quy tắc nào của Nova Foods. (Tham chiếu: `/01-curriculum/CANONICAL_BUSINESS_RULES.md`, metadata `Status`, `Quy tắc quyết định`)	"Business Owner", "Legal Owner", "Accounting Owner" cần phê duyệt từng quy tắc nghiệp vụ.
VER-007	`/01-curriculum/CANONICAL_DATA_DICTIONARY.md`	`IN_REVIEW`, `v0.9.0`	"Từ điển dữ liệu logic canonical" (canonical logical data dictionary) chưa có "baseline" hoặc "approval" cho cấu trúc dữ liệu của Nova Foods. (Tham chiếu: `/01-curriculum/CANONICAL_DATA_DICTIONARY.md`, metadata `Status`)	"Technical Architect" và "Business Owner" cần phê duyệt cấu trúc và định nghĩa dữ liệu.

Các vấn đề trên yêu cầu sự tham gia và phê duyệt từ các "stakeholder" (bên liên quan) có thẩm quyền để chuyển trạng thái IN_REVIEW thành BASELINED hoặc APPROVED. Việc không có "baseline" hay "approval" có nghĩa là mọi nội dung liên quan đến nghiệp vụ, pháp lý, kế toán hay kỹ thuật của Nova Foods vẫn chỉ là "kế hoạch học liệu mô phỏng" (simulated learning material plan).

Quy tắc lan truyền thay đổi

Mọi thay đổi đối với các artifact đã được xác minh hoặc sắp được xác minh phải tuân thủ quy trình kiểm soát thay đổi nghiêm ngặt để đảm bảo "tính toàn vẹn" (integrity) của toàn bộ "corpus" (tập tài liệu). "Traceability" là yêu cầu bắt buộc.

Bảng 2: Quy tắc lan truyền thay đổi và yêu cầu hành động

Mã quy tắc	Mô tả quy tắc	Kích hoạt hành động	Artifact bị ảnh hưởng	Hành động bắt buộc
CHG-001	Thay đổi "nguồn canonical" (canonical source)	Nguồn tham chiếu pháp lý, chuẩn mực, hoặc dữ liệu nền tảng thay đổi (ví dụ: Luật Bảo vệ dữ liệu cá nhân).	`/00-research/00_SOURCE_MAP.md` và mọi artifact tham chiếu.	1. Cập nhật `/00-research/00_SOURCE_MAP.md`. 2. Xác định các artifact phụ thuộc. 3. Đánh giá tác động và cập nhật các artifact liên quan (ví dụ: `CANONICAL_BUSINESS_RULES.md`). 4. "Escalate" (leo thang) đến các "owner" (chủ sở hữu) liên quan.
CHG-002	Mâu thuẫn "traceability" (truy vết)	Sự thay đổi trong một artifact làm đứt gãy liên kết truy vết với các artifact khác (ví dụ: một yêu cầu bị xóa nhưng các tiêu chí chấp nhận, kịch bản kiểm thử vẫn tồn tại).	Tất cả các artifact trong "chuỗi truy vết" (traceability chain).	Đặt trạng thái `STOP — PLAN REWORK REQUIRED` cho artifact có mâu thuẫn. Phải fix "dependency" (phụ thuộc) và "consistency" (nhất quán) trước khi tiếp tục. (Tham chiếu: `/01-curriculum/01_CURRICULUM_ARCHITECTURE.md`, mục `Điều kiện dừng`)
CHG-003	Thay đổi trong "kiến trúc curriculum" (curriculum architecture)	Cấu trúc tổng thể của các chương, module hoặc "learning objective" (mục tiêu học tập) thay đổi.	`/01-curriculum/01_CURRICULUM_ARCHITECTURE.md`, `/01-curriculum/CHAPTER_MANIFEST.md`.	Cập nhật kiến trúc, manifest chương. Đánh giá tác động lên các "learning path" và "assessment" (đánh giá). Yêu cầu phê duyệt từ "Curriculum Owner".
CHG-004	Thay đổi "quy tắc nghiệp vụ" (business rule) Nova Foods	Một quy tắc nghiệp vụ của Nova Foods (ví dụ: chính sách giảm giá, điều kiện thanh toán) được sửa đổi hoặc bổ sung.	`/01-curriculum/CANONICAL_BUSINESS_RULES.md` và mọi "requirement" (yêu cầu), "acceptance criteria" (tiêu chí chấp nhận) phụ thuộc.	1. Cập nhật `CANONICAL_BUSINESS_RULES.md`. 2. Xác định và cập nhật các yêu cầu, tiêu chí chấp nhận, "test case" (trường hợp kiểm thử) liên quan. 3. Yêu cầu phê duyệt từ "Business Owner".
CHG-005	Thay đổi "định nghĩa dữ liệu" (data definition) Nova Foods	Cấu trúc, kiểu dữ liệu, ràng buộc của một trường dữ liệu (ví dụ: giới hạn độ dài tên sản phẩm) thay đổi.	`/01-curriculum/CANONICAL_DATA_DICTIONARY.md` và mọi "UI/UX specification" (đặc tả giao diện người dùng/trải nghiệm người dùng), "API specification" (đặc tả API), "database schema" (lược đồ cơ sở dữ liệu) phụ thuộc.	1. Cập nhật `CANONICAL_DATA_DICTIONARY.md`. 2. Xác định và cập nhật các đặc tả liên quan. 3. Yêu cầu phê duyệt từ "Technical Architect" và "Business Owner".

Cơ chế Escalation

"Escalation" là hành động "leo thang" vấn đề khi một đề xuất thay đổi hoặc một phát hiện mâu thuẫn đồng thời ảnh hưởng đến thẩm quyền của từ hai "vai trò chuyên môn" (specialized roles) trở lên (ví dụ: pháp lý và kế toán, nghiệp vụ và bảo mật). Hoặc khi "nguồn canonical" (canonical source) mâu thuẫn với cách hiểu trong artifact hiện hành. Hoặc khi việc quyết định một "ID" (định danh) có thể bị diễn giải thành quyết định pháp lý, kế toán, kiến trúc, bảo mật hoặc vận hành thực tế. (Tham chiếu: /01-curriculum/TRACEABILITY_ID_REGISTRY.md, mục Quy tắc kích hoạt chung). "Principal IT Business Analyst / Technical Curriculum Author" có trách nhiệm lập gói vấn đề, bảo toàn "traceability", nhưng không được phép đưa ra kết luận chuyên môn thay thế các vai trò trên.