CHAPTER_MANIFEST.md — Authoritative Manifest for 26 Handbook Chapters

H1 Title, Artifact Governance Metadata, and Baseline Control

Artifact Governance Metadata

Trường kiểm soát	Giá trị kiểm soát
Artifact ID	CHAPTER_MANIFEST
Đường dẫn tệp được kiểm soát	/01-curriculum/CHAPTER_MANIFEST.md
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Owner	Principal IT Business Analyst / Technical Curriculum Author
Trách nhiệm của Owner	Duy trì tính nhất quán của manifest chapter; kiểm soát định danh artifact, đường dẫn tệp, version và metadata; bảo toàn liên kết quản trị với curriculum architecture; và ghi nhận thay đổi theo cơ chế kiểm soát của corpus Nova Foods.
Giới hạn thẩm quyền của Owner	Owner không có quyền tự thiết lập baseline, ghi nhận approval, phê chuẩn nội dung chapter, xác nhận requirement Nova Foods, diễn giải pháp lý, quyết định kế toán hoặc thuế, xác nhận compliance, hay cho phép sử dụng production.
Ngày cập nhật gần nhất	2026-08-07
Múi giờ quản trị	Asia/Ho_Chi_Minh
Locale áp dụng	vi-VN; bối cảnh Việt Nam; đơn vị tiền tệ mô phỏng VND
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, chỉ sử dụng dữ liệu tổng hợp
Phân loại artifact	Controlled planning artifact cho danh mục và quản trị cấu trúc 26 handbook chapter
Trạng thái tham chiếu baseline	Chưa có baseline reference tại v0.9.0; IN_REVIEW không được diễn giải là BASELINED.
Trạng thái tham chiếu approval	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.

Metadata trên là nguồn kiểm soát nhận diện của chính artifact này tại thời điểm 2026-08-07. Mọi diễn giải vượt quá các trường đã ghi, đặc biệt về phê duyệt, hiệu lực triển khai, nghĩa vụ pháp lý hoặc tính sẵn sàng production, nằm ngoài thẩm quyền của metadata và phải có bằng chứng được ghi nhận trong artifact kiểm soát phù hợp.

Lịch sử thay đổi khởi tạo

Phiên bản	Ngày ghi nhận	Trạng thái	Người ghi nhận	Nội dung thay đổi	Tác động kiểm soát
v0.9.0	2026-08-07	IN_REVIEW	Principal IT Business Analyst / Technical Curriculum Author	Tạo bản kế hoạch ban đầu cho CHAPTER_MANIFEST.md trước giai đoạn soạn thảo nội dung handbook; thiết lập record lịch sử thay đổi đầu tiên để quản lý các sửa đổi tiếp theo có truy vết.	Đây là record khởi tạo, không xác lập baseline, không ghi nhận approval và không xác nhận bất kỳ chapter nào đã được soạn thảo, rà soát chuyên môn hoặc sẵn sàng sử dụng.

Bản ghi v0.9.0 thể hiện thời điểm artifact được tạo dưới dạng planning content before drafting: nội dung phục vụ việc lập kế hoạch có kiểm soát cho handbook Nova Foods Trading & Manufacturing, với dữ liệu mô phỏng giáo dục. Record này chỉ xác định nguồn gốc phiên bản đầu tiên và trạng thái đang được xem xét; không phải bằng chứng rằng nội dung dự kiến trong manifest đã hoàn chỉnh, đúng về chuyên môn, được chấp thuận bởi người dùng, hay phù hợp cho vận hành production.

Các thay đổi về sau phải bổ sung một dòng lịch sử mới thay vì sửa đè record v0.9.0. Mỗi dòng mới phải nêu phiên bản, ngày, trạng thái thực tế, người ghi nhận, nội dung thay đổi và tác động kiểm soát. Nếu thay đổi làm phát sinh hoặc điều chỉnh nội dung liên quan pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc hoặc bảo mật, record thay đổi phải duy trì phân loại nguồn và nhãn Verification required hoặc Project assumption khi chưa có xác minh phù hợp.

Đóng băng bộ tên tệp đề xuất cho 26 handbook chapter

Bộ tên tệp đã được quy hoạch cho 26 handbook chapter, tương ứng các chapter ID từ CH-00 đến CH-25, được đóng băng ở cấp định danh đề xuất trong phạm vi manifest này. “Đóng băng” nghĩa là trong quá trình review, tác giả và các artifact phụ thuộc phải dùng nhất quán đúng tên tệp đã được catalog; không được tự đổi chính tả, đổi kiểu viết hoa/thường, rút gọn, thêm hậu tố phiên bản, đổi đường dẫn, hoặc tạo tệp thay thế để biểu diễn cùng một chapter.

Đối tượng kiểm soát	Quy tắc áp dụng	Ranh giới diễn giải
Bộ 26 tên tệp handbook	Là proposed identifier cố định cho CH-00 đến CH-25; dùng làm khóa liên kết giữa curriculum, chapter, template, traceability và kiểm tra chất lượng.	Tên tệp cố định không xác nhận nội dung chapter đã tồn tại, hoàn chỉnh hoặc đúng chuyên môn.
Sửa tên tệp hoặc đường dẫn	Không được thực hiện ngầm trong chapter text, liên kết chéo, bảng traceability hoặc cấu trúc thư mục.	Một thay đổi tên có thể làm đứt liên kết và phải được xem xét như thay đổi kiểm soát đối với manifest.
Tạo tên thay thế	Không được tạo bản sao với tên gần giống, tên viết tắt hoặc hậu tố như -final, -approved, -v1 để thay thế định danh đã đóng băng.	Sự tồn tại của tệp mới không làm thay đổi định danh đề xuất đã được ghi nhận.
Liên kết tới chapter	Chỉ được tham chiếu theo chapter ID và filename/path đã được catalog trong manifest.	Liên kết không phải là bằng chứng phê duyệt, baseline hoặc sẵn sàng sử dụng production.

Việc đóng băng này chỉ bảo vệ tính ổn định của định danh lập kế hoạch: một chapter được nhận diện nhất quán xuyên suốt corpus Nova Foods Trading & Manufacturing mô phỏng, và các kiểm tra sau này có thể phát hiện tham chiếu sai tệp hoặc sai chapter. Việc này không chuyển bộ filename thành cấu hình phát hành, không tạo cam kết về cấu trúc thư mục triển khai, và không trao quyền thay đổi phạm vi curriculum cho người sử dụng tên tệp.

Tại thời điểm lập manifest, bộ 26 filename vẫn là proposed identifiers. Manifest chưa được phê duyệt và chưa được baseline; vì vậy, không được diễn giải việc đóng băng tên tệp là user approval, phê duyệt nội dung chapter, phê duyệt requirement Nova Foods, hoặc cho phép sử dụng handbook trong production. Chỉ một quyết định phê duyệt và baseline được ghi nhận rõ trong artifact kiểm soát phù hợp mới có thể thay đổi trạng thái này.

Ranh giới hiệu lực của artifact lập kế hoạch được kiểm soát

/01-curriculum/CHAPTER_MANIFEST.md là controlled planning artifact cho corpus mô phỏng Nova Foods Trading & Manufacturing. Artifact này dùng để tổ chức và kiểm soát kế hoạch handbook; nó không tự tạo quyền phê duyệt đối với bất kỳ nội dung nào được liệt kê hoặc tham chiếu. Sự hiện diện của một chapter, tên tệp, định danh, thứ tự dự kiến, mô tả mục tiêu, hoặc liên kết tới artifact khác chỉ thể hiện nội dung đang được quản trị để review.

Đối tượng có thể bị hiểu nhầm là đã được phê duyệt	Trạng thái diễn giải bắt buộc của manifest	Ranh giới hiệu lực
Nội dung của 26 handbook chapter	Đề xuất có kiểm soát để soạn thảo và review	Không xác nhận tính đúng đắn chuyên môn, đầy đủ, khả năng đào tạo, hoặc mức sẵn sàng phát hành của chapter.
Requirement, business rule, acceptance criterion hoặc test basis trong ví dụ	Dữ liệu mô phỏng giáo dục hoặc nội dung cần xác minh theo artifact nguồn	Không phê duyệt requirement cho Nova Foods, không xác nhận business rule, và không thay thế quyết định của Business Owner, Domain Owner hoặc Product Owner.
Nội dung pháp lý, kế toán, thuế, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc hoặc bảo mật	Chỉ được dùng trong phạm vi nguồn và nhãn xác minh phù hợp	Không là legal, accounting, compliance hoặc security sign-off; nội dung chưa được xác minh phải giữ nhãn Verification required hoặc Project assumption.
Tên tệp và cấu trúc handbook	Định danh kế hoạch được kiểm soát trong phạm vi manifest	Không là quyết định phát hành, không xác nhận tệp đã tồn tại đầy đủ nội dung, và không cho phép sử dụng như tài liệu vận hành.
Ví dụ quy trình, dữ liệu, vai trò và giao dịch Nova Foods	Tình huống tổng hợp phục vụ học tập	Không mô tả hệ thống production, không phải hướng dẫn vận hành, và không phải bằng chứng về chính sách thực tế của bất kỳ tổ chức nào.

Quy tắc diễn giải là: chỉ quyết định được ghi nhận rõ ràng trong artifact kiểm soát phù hợp, bởi vai trò có thẩm quyền đối với đúng phạm vi quyết định, mới có thể tạo hiệu lực phê duyệt. IN_REVIEW không tương đương APPROVED, BASELINED, compliant, production-ready hoặc user-approved. Owner của manifest chỉ duy trì tính toàn vẹn quản trị của kế hoạch; Owner không được thay mặt các vai trò có thẩm quyền xác nhận nội dung chapter, yêu cầu nghiệp vụ, diễn giải pháp lý, hạch toán, thiết kế kỹ thuật, kiểm thử chấp nhận hoặc triển khai production.

Vì vậy, manifest không được dùng làm căn cứ để cấu hình ERP, đào tạo vận hành chính thức, ký cam kết, phát hành tài liệu chuẩn, hoặc đóng một điểm cần escalation. Mọi quyết định có tác động đến production phải được đánh giá và phê duyệt trong quy trình, artifact và thẩm quyền áp dụng riêng; manifest chỉ duy trì ranh giới và khả năng truy vết của kế hoạch nội dung.

Manifest Scope, Catalog Rules, and Global Constraints

Phạm vi corpus handbook được kiểm soát

Manifest này áp dụng cho chính xác 26 tệp handbook trong corpus IT BUSINESS ANALYST — ZERO TO DELIVERY READY. Biên phạm vi được xác định bởi tệp mở đầu 00-foundations.md và tệp kết thúc 25-ai-assisted-ba-workflow.md. Số lượng 26 là ràng buộc kiểm soát của corpus, không phải ước lượng về số lượng chapter đã được soạn nội dung.

Thuộc tính phạm vi	Giá trị kiểm soát
Loại đối tượng trong phạm vi	Tệp handbook chapter thuộc corpus đào tạo IT Business Analyst
Số lượng tệp handbook	26
Biên bắt đầu	00-foundations.md
Biên kết thúc	25-ai-assisted-ba-workflow.md
Không gian chỉ mục được dành riêng	00 đến 25, gồm 26 chỉ mục phân biệt
Bối cảnh case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp
Trạng thái quản trị tại thời điểm manifest	IN_REVIEW
Phiên bản	v0.9.0
Ngày kiểm soát	2026-08-07
Locale và tiền tệ mô phỏng	vi-VN, Asia/Ho_Chi_Minh, VND

Công thức kiểm tra số lượng là: 25 - 00 + 1 = 26. Vì vậy, mọi tệp handbook được manifest quản lý phải thuộc tập chỉ mục đóng {00, 01, 02, …, 25}; một tệp ngoài tập này không thuộc phạm vi 26 chapter của manifest hiện hành.

Ranh giới bao gồm và loại trừ ở cấp phạm vi

Quyết định phạm vi	Diễn giải áp dụng
Bao gồm	26 tệp handbook được định danh trong biên 00-foundations.md đến 25-ai-assisted-ba-workflow.md.
Không bao gồm	Template library, glossary, cheatsheet, canonical business rules, canonical data dictionary, traceability registry, competency matrix, QA report và curriculum architecture là artifact phụ thuộc hoặc hỗ trợ, không phải chapter handbook trong số lượng 26.
Không bao gồm	Tài liệu vận hành ERP, cấu hình production, tài liệu pháp lý, quyết định kế toán, bằng chứng compliance hoặc hướng dẫn triển khai thực tế cho Nova Foods.
Ranh giới dữ liệu	Mọi tên tổ chức, quy trình, vai trò, giao dịch, mã định danh và giá trị VND dùng trong handbook là dữ liệu tổng hợp phục vụ đào tạo.
Ranh giới thẩm quyền	Việc một tệp nằm trong phạm vi manifest không xác nhận tệp đó đã hoàn chỉnh, được phê duyệt, baseline, compliant hoặc production-ready.

Các chỉ mục 00 đến 25 chỉ xác định tập chapter được quản lý; chúng không tạo thêm tệp handbook thứ 27, không mở rộng phạm vi sang tài liệu phụ trợ, và không tự xác nhận nội dung của bất kỳ chapter nào. Mọi nội dung liên quan pháp lý, thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc hoặc bảo mật trong các chapter tương lai vẫn phải được phân loại phù hợp là Project assumption hoặc Verification required khi chưa được xác minh bởi nguồn và vai trò có thẩm quyền.

Quy tắc thứ tự số học bất biến cho catalog chapter

Catalog chapter phải được trình bày theo khóa số gồm hai chữ số, tăng dần từ 00 đến 25. Khóa này là phần định danh ổn định của chapter trong cấu trúc handbook; không được sắp xếp theo bảng chữ cái, độ dài nội dung, mức độ ưu tiên, nhóm chủ đề hoặc thời điểm soạn thảo. Việc một chapter đang được rà soát không cho phép di chuyển chapter đó ra khỏi vị trí số học của nó.

Vị trí catalog bắt buộc	Dải số chapter	Điều kiện kiểm tra
Nhóm đầu	00–08	Xuất hiện liên tiếp: 00, 01, 02, 03, 04, 05, 06, 07, 08.
Nhóm giữa	09–17	Tiếp nối ngay sau 08: 09, 10, 11, 12, 13, 14, 15, 16, 17.
Nhóm cuối	18–25	Tiếp nối ngay sau 17: 18, 19, 20, 21, 22, 23, 24, 25.

Chuỗi kiểm tra đầy đủ là: 00 → 01 → 02 → 03 → 04 → 05 → 06 → 07 → 08 → 09 → 10 → 11 → 12 → 13 → 14 → 15 → 16 → 17 → 18 → 19 → 20 → 21 → 22 → 23 → 24 → 25.

Mỗi khóa số chỉ được xuất hiện đúng một lần. Catalog không hợp lệ nếu phát hiện bất kỳ tình huống nào sau đây:

Loại sai lệch	Ví dụ không hợp lệ	Cách xử lý bắt buộc
Bỏ số	00, 01, 03	Khôi phục vị trí 02; không gán nội dung của 02 sang số khác.
Trùng số	Hai entry cùng mang CH-12	Giữ một định danh đang được kiểm soát, tách và định tuyến thay đổi định danh còn lại để review.
Đảo thứ tự	08 được liệt kê trước 07	Đưa entry về thứ tự tăng dần; không suy diễn thay đổi dependency học tập.
Đổi số	CH-14 bị đổi thành CH-15 để chèn nội dung mới	Không thực hiện; số chapter không phải khoảng trống tùy ý để tái sử dụng.
Định dạng không nhất quán	CH-4, CH-04, CH-004 cùng tồn tại	Chỉ dùng dạng hai chữ số chuẩn: CH-04.

Quy tắc đối chiếu máy và người: số lượng khóa duy nhất phải bằng 26; khóa nhỏ nhất phải là 00; khóa lớn nhất phải là 25; mỗi cặp khóa liền kề phải có chênh lệch đúng 1. Nếu một kiểm tra không đạt, catalog phải được coi là có lỗi cấu trúc và không được diễn giải thứ tự hiển thị như trình tự học hợp lệ.

Bộ trường bắt buộc cho từng mục chapter

Mỗi mục chapter phải sử dụng đầy đủ bộ trường dưới đây để manifest có thể kiểm tra được phạm vi học, đầu vào, đầu ra và ranh giới thẩm quyền. Giá trị trường là kế hoạch có kiểm soát cho Nova Foods Trading & Manufacturing, chỉ dùng dữ liệu tổng hợp; không phải nội dung đào tạo chi tiết, requirement đã được xác nhận, hay chỉ thị triển khai.

Trường bắt buộc	Nội dung phải ghi	Quy tắc chất lượng và ranh giới
Title	Tên chapter thể hiện đúng năng lực hoặc chủ đề chính.	Phân biệt rõ với tên artifact, template hoặc ID requirement; không dùng tiêu đề mơ hồ như “Tổng quan”.
Level	Mức năng lực dự kiến: Novice, Intermediate 1, Intermediate 2 hoặc Senior-ready.	Mức phải phù hợp với độ phức tạp của artifact, quyền tự quyết và yêu cầu escalation.
Prerequisites	Kiến thức, kỹ năng và artifact người học phải có trước khi học chapter.	Nêu chapter hoặc artifact đầu vào cụ thể khi có, ví dụ understanding của NEED-SALES-001; không giả định kiến thức chưa được giới thiệu.
Target capability	Hành vi quan sát được mà người học phải thực hiện sau chapter.	Viết theo kết quả có thể đánh giá, ví dụ “liên kết requirement với acceptance criteria và test basis”, không chỉ “hiểu traceability”.
Central mental model	Mô hình tư duy làm nguyên tắc giải quyết vấn đề.	Nêu quan hệ nhân quả hoặc quyết định, ví dụ “need → requirement → acceptance criterion → test evidence”, không chỉ liệt kê thuật ngữ.
Nova Foods scenario	Bối cảnh nghiệp vụ mô phỏng mà chapter sử dụng.	Xác định luồng, vai trò, thực thể hoặc vấn đề hẹp, như tạo đơn bán hàng, kiểm tra tồn kho, quản lý lô hàng; không trình bày đây là vận hành thực tế của doanh nghiệp.
Required artifacts	Danh sách artifact learner phải tạo, cập nhật hoặc dùng làm đầu vào.	Ghi loại artifact và ID mẫu đã có nếu áp dụng, như REQ-FUNC-SALES-012, AC-SALES-012-03, TC-SALES-012-07; không tạo định danh mới ngoài registry.
Diagram types	Loại sơ đồ được phép hoặc bắt buộc dùng.	Phân biệt chuẩn ký pháp: BPMN 2.0.2 cho BPMN, UML 2.5.1 cho UML. Sơ đồ activity PlantUML không được gọi là BPMN.
Source families	Nhóm nguồn làm căn cứ nội dung: chuẩn, luật chính thức, industry good practice, project convention, author recommendation, Project assumption, hoặc Verification required.	Khi nêu nội dung privacy, kế toán, hóa đơn, an toàn thực phẩm, truy xuất nguồn gốc hoặc security, phải chỉ rõ ranh giới xác minh; không suy diễn điều khoản hoặc nghĩa vụ chi tiết ngoài nguồn đã kiểm chứng.
Quality gate	Điều kiện tối thiểu để đánh giá artifact của chapter đạt mức chuyển tiếp.	Gate phải kiểm tra được tính rõ ràng, nhất quán, liên kết và nhãn nguồn; ví dụ requirement có acceptance criterion quan sát được và không che giấu business rule.
Traceability dependencies	Artifact, registry hoặc nguồn chân lý mà chapter phải tham chiếu hoặc cập nhật liên kết.	Nêu hướng liên kết cụ thể, ví dụ NEED-SALES-001 → REQ-FUNC-SALES-012 → AC-SALES-012-03; không sao chép lại data definition hoặc business rule từ canonical artifact.
Independent decisions	Quyết định learner hoặc BA có thể thực hiện trong bài tập mà không cần chuyển cấp.	Chỉ gồm lựa chọn trình bày, phân rã, câu hỏi làm rõ, cấu trúc traceability hoặc đề xuất trong phạm vi mô phỏng; không gồm quyết định pháp lý, kế toán, kiến trúc hoặc production.
Escalation decisions	Quyết định phải chuyển tới vai trò có thẩm quyền.	Ghi trigger và vai trò nhận escalation, như Legal Owner cho applicability của quy định dữ liệu cá nhân, Accounting Owner cho hạch toán, Domain Owner cho rule lô hàng hoặc Architect cho boundary tích hợp.
Explicit exclusions	Những nội dung chapter chủ động không dạy, không quyết định hoặc không tuyên bố.	Loại trừ phải cụ thể, ví dụ không xác nhận tuân thủ pháp luật, không phê duyệt business rule, không cấu hình ERP production, không thay thế legal, accounting hoặc domain authority.

Quy tắc hoàn chỉnh mục chapter: một mục chỉ đủ điều kiện lập kế hoạch khi mọi trường trên có giá trị cụ thể, có thể kiểm tra và không mâu thuẫn nhau. Required artifacts, Quality gate và Traceability dependencies phải tạo được chuỗi bằng chứng; Independent decisions, Escalation decisions và Explicit exclusions phải phân định rõ BA được làm gì, phải hỏi ai, và không được tự quyết điều gì.

Quy tắc quản trị trạng thái IN_REVIEW cho từng chapter entry

Mọi chapter entry trong /01-curriculum/CHAPTER_MANIFEST.md phải hiển thị và duy trì chính xác Status: IN_REVIEW tại Version: v0.9.0, ngày 2026-08-07, múi giờ Asia/Ho_Chi_Minh. Trạng thái này xác định entry là kế hoạch đang được xem xét; không xác nhận nội dung chapter đã đúng, hoàn chỉnh, được baseline, sẵn sàng phát hành, sẵn sàng delivery hoặc có hiệu lực triển khai cho Nova Foods Trading & Manufacturing.

Tình huống kiểm soát	Trạng thái bắt buộc của chapter entry	Cách diễn giải bắt buộc
Tạo mới hoặc cập nhật planning details của chapter	IN_REVIEW	Nội dung là đề xuất có kiểm soát để review.
Bổ sung dependency, artifact dự kiến, quality gate hoặc escalation boundary	IN_REVIEW	Việc bổ sung chi tiết không tạo approval ngầm định.
Có nhận xét từ Owner, SME, reviewer hoặc công cụ kiểm tra	IN_REVIEW	Nhận xét là đầu vào review, không phải bằng chứng user approval.
Có liên kết tới source chính thức, chuẩn ngành hoặc artifact nội bộ	IN_REVIEW	Liên kết nguồn chỉ hỗ trợ traceability; không thay đổi trạng thái quản trị.
Có nội dung gắn Project assumption hoặc Verification required	IN_REVIEW	Nhãn nguồn và mức xác minh không được diễn giải thành quyết định đã được phê duyệt.
Chưa có user approval được ghi nhận rõ ràng cho chapter entry	IN_REVIEW	Không được tự đổi sang APPROVED, BASELINED, FINAL, READY hoặc trạng thái tương đương.

Quy tắc chuyển trạng thái: chỉ user approval được ghi nhận rõ ràng trong artifact kiểm soát phù hợp mới có thể là cơ sở xem xét thay đổi trạng thái của một chapter entry. Sự tồn tại của chapter ID, filename, bảng manifest, version, review comment, source citation, Owner hoặc cập nhật nội dung không thay thế user approval. Không được suy diễn approval từ im lặng, tiếp tục drafting, sử dụng nội bộ, hoặc việc một entry không có lỗi được phát hiện.

Quy tắc bảo toàn bằng chứng: khi chưa có user approval được ghi nhận, tác giả phải giữ nguyên IN_REVIEW; không được thêm approval reference, baseline reference, người phê duyệt, ngày phê duyệt hoặc tuyên bố đã chấp thuận. Nếu có yêu cầu thay đổi trạng thái nhưng bằng chứng approval chưa được ghi nhận, chapter entry vẫn là IN_REVIEW và yêu cầu đó phải được chuyển lại để user xác nhận trong artifact kiểm soát phù hợp.

Ranh giới Manifest: Chỉ Lập Kế Hoạch, Không Soạn Văn Bản Chapter

Manifest là nguồn kiểm soát cho ý định thiết kế của từng chapter, không phải nơi cung cấp nội dung giảng dạy, hướng dẫn thực hành hoàn chỉnh, bài đọc, bài tập, đáp án, kịch bản hội thoại, requirement chi tiết hoặc quyết định vận hành cho Nova Foods Trading & Manufacturing. Mỗi entry phải trả lời câu hỏi: chapter này sẽ dạy gì, dùng bối cảnh nào, tạo artifact nào, dựa vào nguồn nào và phải qua điều kiện chất lượng nào. Entry không được trả lời bằng cách viết thay nội dung mà chapter sẽ triển khai.

Loại thông tin	Được ghi trong manifest	Không được ghi trong manifest
Mục tiêu chapter	Năng lực đích ở dạng kết quả quan sát được, ví dụ: phân biệt business need với functional requirement.	Diễn giải bài học nhiều đoạn về cách elicitation hoặc cách viết requirement.
Bối cảnh Nova Foods	Tên luồng hoặc tình huống mô phỏng cần dùng, ví dụ: xử lý đơn bán hàng, kiểm tra tồn kho, truy xuất lô hàng.	Kịch bản đầy đủ có nhân vật, hội thoại, dữ liệu giao dịch, kết quả xử lý và lời giải.
Artifact đầu ra	Tên artifact, loại cấu trúc, định danh dự kiến và quan hệ dependency, ví dụ: requirement catalogue liên kết với NEED-SALES-001.	Nội dung hoàn chỉnh của requirement, business rule, acceptance criterion, test case, decision table hoặc data dictionary entry.
Mô hình và sơ đồ	Loại sơ đồ cần xuất hiện, mục đích sử dụng và giới hạn ký pháp.	Sơ đồ đã được vẽ kèm diễn giải chi tiết như nội dung chính thức của chapter.
Nguồn và kiểm soát	Source family cần tham chiếu, classification và điểm phải xác minh.	Trích dẫn được tạo ra không có nguồn, diễn giải pháp lý, kết luận kế toán hoặc xác nhận compliance.
Chất lượng và quyết định	Quality gate, điều kiện kiểm tra, quyết định độc lập và điểm cần escalation.	Lời giải quyết định thay Business Owner, Legal Owner, Accounting Owner, Domain Owner hoặc Architect.

Quy tắc kiểm tra biên giới nội dung

1. Nếu một đoạn có thể được sao chép trực tiếp vào phần bài học, hướng dẫn từng bước, ví dụ minh họa hoàn chỉnh hoặc đáp án thực hành của chapter, đoạn đó không thuộc manifest và phải được chuyển sang chapter tương ứng trong giai đoạn drafting.
2. Nếu một câu tạo hoặc sửa nội dung nghiệp vụ cụ thể cho Nova Foods, như quy tắc tính giá, điều kiện xuất hóa đơn, thời hạn lưu dữ liệu cá nhân hoặc điều kiện truy xuất lô, manifest chỉ được ghi nhận đó là chủ đề, dependency hoặc điểm cần xác minh; không được tự đặc tả rule.
3. Nếu cần minh họa, manifest chỉ dùng minh họa ở mức nhãn cấu trúc, chẳng hạn “một requirement mẫu có liên kết need, acceptance criteria và test basis”; không viết câu requirement mẫu hoàn chỉnh.
4. Mọi chi tiết thuộc pháp lý, thuế, kế toán, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc hoặc security chỉ được định tuyến bằng source classification và nhãn Verification required hoặc Project assumption khi chưa được xác minh trong artifact có thẩm quyền.
5. Manifest không thay thế CHAPTER_MANIFEST.md bằng một handbook rút gọn: không chứa mục tiêu bài học theo dạng giáo án, nội dung giải thích khái niệm, câu hỏi tự kiểm tra, đáp án, checklist thực thi hoặc hướng dẫn sử dụng công cụ.

Dấu hiệu rà soát	Kết luận bắt buộc	Hành động kiểm soát
Entry chỉ mô tả phạm vi, output, dependency và gate	Đúng ranh giới planning.	Giữ trong manifest.
Entry chứa các bước “người học phải làm”, giải thích khái niệm hoặc ví dụ có nội dung hoàn chỉnh	Có dấu hiệu chapter prose.	Loại khỏi manifest và định tuyến sang chapter phù hợp khi drafting.
Entry chứa rule Nova Foods chưa có source hoặc owner xác minh	Vượt thẩm quyền planning.	Thay bằng nhãn Verification required, câu hỏi quyết định và dependency cần thiết.
Entry khẳng định compliance, sẵn sàng production hoặc quyết định đã chốt	Không phù hợp với artifact lập kế hoạch.	Gỡ khẳng định; chỉ ghi quality gate hoặc escalation cần thiết.

Ranh giới này bảo đảm manifest giữ vai trò danh mục thiết kế có thể kiểm tra, còn mỗi chapter giữ trách nhiệm độc lập trong việc phát triển kiến thức, ví dụ, bài thực hành và bằng chứng học tập của mình.

Quy tắc định danh tệp bị đóng băng

Tên tệp chapter là định danh bị đóng băng trong /01-curriculum/CHAPTER_MANIFEST.md: tác giả, reviewer và các artifact phụ thuộc phải sao chép chính xác tên đã được đề xuất, gồm tiền tố số, dấu gạch nối, chữ thường và hậu tố .md. Tên tệp không phải nhãn biên tập có thể tự tối ưu; nó là khóa liên kết giữa catalog, liên kết nội bộ, traceability, template, QA và tài liệu curriculum khác.

Thành phần tên tệp	Quy tắc bắt buộc	Ví dụ hợp lệ	Ví dụ không hợp lệ	Lý do từ chối
Tiền tố thứ tự	Giữ đúng hai chữ số theo định danh chapter.	00-foundations.md	0-foundations.md, 00-foundation.md	Làm thay đổi khóa định danh hoặc tên đã đề xuất.
Dấu phân cách	Dùng dấu gạch nối ASCII (-) đúng vị trí đã đề xuất.	25-ai-assisted-ba-workflow.md	25_ai_assisted_ba_workflow.md, 25-ai-assisted-ba-workflow .md	Làm đứt đối sánh tên tệp chính xác.
Kiểu chữ	Giữ chữ thường ASCII như tên đã đề xuất.	00-foundations.md	00-Foundations.md, 25-AI-Assisted-BA-Workflow.md	Hệ thống tệp và liên kết có thể phân biệt chữ hoa/chữ thường.
Hậu tố	Luôn là .md.	25-ai-assisted-ba-workflow.md	25-ai-assisted-ba-workflow.MD, 25-ai-assisted-ba-workflow	Không còn là định danh Markdown đã đăng ký.
Phạm vi đổi tên	Không thêm tiền tố thư mục, phiên bản, ngày hoặc trạng thái vào tên tệp chapter.	00-foundations.md	v0.9.0-00-foundations.md, 00-foundations-IN_REVIEW.md	Version và status thuộc metadata, không thuộc filename.

Hai ranh giới danh mục phải được ghi và tái sử dụng nguyên văn là 00-foundations.md và 25-ai-assisted-ba-workflow.md. Việc dịch tên tệp sang tiếng Việt, rút gọn, sửa ngữ pháp, thay đổi thuật ngữ, hoặc đổi định dạng để “dễ đọc hơn” đều là thay đổi định danh, không phải chỉnh sửa trình bày.

Khi phát hiện filename khác với tên đã đề xuất, người lập manifest phải giữ nguyên tên chuẩn đang được kiểm soát, ghi nhận sai lệch tại điểm sử dụng để xử lý theo kiểm soát thay đổi phù hợp, và không tự tạo alias. Không được suy ra rằng liên kết tới tên gần giống là hợp lệ. Quy tắc này chỉ bảo toàn định danh filename; không tạo approval, baseline hoặc quyền đổi tên chapter.

Chapter Catalog — 00 to 08

CH-00 — 00-foundations.md

Trường metadata	Kế hoạch kiểm soát
Tên chapter	Nền tảng Business Analysis: từ vấn đề kinh doanh đến artifact kiểm tra được
Filename chuẩn	00-foundations.md
Cấp độ	Foundation / Novice; giả định người học bắt đầu từ 0 về BA và kỹ thuật phần mềm.
Điều kiện tiên quyết	Không có kiến thức BA bắt buộc. Người học cần đọc được bảng, phân biệt dữ kiện với diễn giải, và sử dụng Markdown hoặc công cụ văn bản cơ bản.
Năng lực mục tiêu	Giải thích được vì sao BA không chỉ là “ghi yêu cầu”; tách được problem, need, stakeholder statement, requirement, business rule, assumption, constraint và evidence; lập được bản nháp artifact có nguồn gốc và câu hỏi mở.
Central mental model	BA biến sự mơ hồ có kiểm soát thành quyết định và artifact có thể kiểm tra. Chuỗi suy luận tối thiểu là: tín hiệu vận hành → vấn đề cần hiểu → need mong muốn thay đổi → requirement hoặc rule được đặc tả ở chapter sau → acceptance evidence. Không được nhảy trực tiếp từ một ý kiến sang giải pháp hoặc nghĩa vụ bắt buộc.
Nova Foods educational scenario	Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục, dữ liệu tổng hợp, bối cảnh Việt Nam, vi-VN, Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND. Tín hiệu ban đầu: nhân viên Sales nhận đơn phân phối qua nhiều kênh; thông tin tồn kho khả dụng, lô hàng và trạng thái đơn được đối chiếu thủ công giữa biểu mẫu nội bộ. Learner xác định đây là tín hiệu cần khám phá, không tự kết luận nguyên nhân, không tự chọn ERP module, và không tuyên bố quy tắc pháp lý hoặc vận hành đã được xác nhận.
Artifact đầu ra cấp chapter	1. BA Foundations Glossary cho các thuật ngữ problem, need, requirement, business rule, stakeholder, constraint, assumption, risk, evidence và escalation. 2. Nova Foods Signal-to-Question Sheet ghi tín hiệu, nguồn, điều biết được, điều chưa biết, câu hỏi khám phá và nhãn phân loại nguồn. 3. Fact–Assumption–Verification Register phân biệt fact đã có nguồn, Project assumption, và Verification required. 4. Artifact Lifecycle Map thể hiện quan hệ khái niệm giữa need, requirement, business rule, acceptance criteria, test evidence và change record.
Loại sơ đồ	Context sketch cấp khái niệm; artifact lifecycle map; knowledge map. Đây không phải BPMN và không mô tả quy trình vận hành chi tiết. Nếu dùng ký pháp BPMN ở chapter sau, phải tuân theo BPMN 2.0.2 của OMG; sơ đồ activity bằng công cụ khác không được gọi là BPMN.
Source families	Primary professional source: BABOK Guide Version 3 của IIBA cho thuật ngữ, knowledge area, task và competency BA. Requirements-engineering standard: ISO/IEC/IEEE 29148:2018 chỉ dùng trong giới hạn abstract và trạng thái thư mục công khai; mọi khẳng định theo điều khoản cần xác minh licensed text. Normative modeling sources: OMG BPMN 2.0.2 và UML 2.5.1, chỉ khi chapter giải thích ranh giới ký pháp. Official legal sources: Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật 88/2015/QH13, Nghị định 123/2020/NĐ-CP và Luật 55/2010/QH12 chỉ được định tuyến tới Verification required, không được diễn giải thành nghĩa vụ Nova Foods.
Quality gate	Learner đạt khi mọi dòng trong Nova Foods Signal-to-Question Sheet có: tín hiệu cụ thể; nguồn hoặc nhãn Project assumption; phân biệt observation với interpretation; ít nhất một câu hỏi có thể được stakeholder trả lời; và không chứa requirement, rule, SLA, thiết kế ERP hoặc khẳng định tuân thủ được suy diễn. Fact–Assumption–Verification Register phải có nhãn nguồn cho toàn bộ mục, không để “đã xác nhận” khi chưa có bằng chứng.
Traceability dependencies	Phụ thuộc vào /01-curriculum/01_CURRICULUM_ARCHITECTURE.md để giữ logic năng lực và ranh giới thẩm quyền; /01-curriculum/CHAPTER_MANIFEST.md để giữ chapter ID và filename; TRACEABILITY_ID_REGISTRY.md để sử dụng ID ở các chapter sau; CANONICAL_BUSINESS_RULES.md và CANONICAL_DATA_DICTIONARY.md là nguồn chân lý được tham chiếu khi đã tồn tại, không được tái tạo hoặc tự định nghĩa trong chapter này. Các artifact CH-00 là đầu vào khái niệm cho discovery, scope, requirements, rules, acceptance criteria và testing về sau.
Quyết định learner có thể tự thực hiện	Chọn cách diễn đạt định nghĩa học tập; ghi nhận tín hiệu mô phỏng; lập câu hỏi mở; đánh dấu phát biểu là fact, Project assumption hoặc Verification required; chỉ ra khoảng trống traceability; và đề xuất artifact cần tạo tiếp theo mà không khẳng định nội dung của artifact đó đã đúng.
Quyết định phải escalation	Escalate tới Domain Owner khi cần xác nhận thực tế về đơn hàng, tồn kho, lô, hạn dùng, kho hoặc truy xuất nguồn gốc; tới Legal Owner khi phát biểu có thể tạo diễn giải về dữ liệu cá nhân, hóa đơn, kế toán, an toàn thực phẩm hoặc nghĩa vụ pháp lý; tới Accounting Owner khi ảnh hưởng ghi nhận tiền, chứng từ hoặc hạch toán; tới Solution Architect khi yêu cầu lựa chọn tích hợp, dữ liệu nguồn chuẩn hoặc thiết kế kỹ thuật. Escalation phải nêu artifact bị ảnh hưởng, fact hiện có, nhãn nguồn, câu hỏi quyết định, tác động trì hoãn và vai trò nhận xử lý.
Explicit exclusions	Không khảo sát stakeholder chi tiết; không thực hiện phỏng vấn; không lập BPMN current-state; không xác định scope; không viết requirement, user story, acceptance criterion, business rule, decision table, test case hoặc API contract; không chọn ERP vendor hay kiến trúc; không xác nhận compliance, thuế, kế toán, hóa đơn, privacy, security, an toàn thực phẩm hoặc production readiness. Chapter này không tạo approval, baseline hoặc yêu cầu đã được Nova Foods chấp thuận.

Quy tắc áp dụng cho scenario CH-00: Mệnh đề “Sales đối chiếu thông tin thủ công” là tín hiệu mô phỏng phục vụ học tập. Nó không chứng minh nguyên nhân gốc, không chứng minh dữ liệu tồn kho sai, và không tạo yêu cầu tự động phân bổ tồn kho. Các phát biểu về lô hàng, truy xuất nguồn gốc, hóa đơn, dữ liệu khách hàng hoặc lưu giữ chứng từ chỉ được ghi là Verification required cho đến khi được vai trò có thẩm quyền xác minh từ nguồn phù hợp.

CH-01 — 01-ba-role-lifecycle-and-governance.md

File đích: 01-ba-role-lifecycle-and-governance.md
Định danh chapter: CH-01
Trạng thái bộ soạn thảo: IN_REVIEW
Phiên bản: v0.9.0
Ngày chuẩn: 2026-08-07
Locale: vi-VN
Múi giờ: Asia/Ho_Chi_Minh
Tiền tệ mô phỏng: VND
Case study xuyên suốt: Nova Foods Trading & Manufacturing — dữ liệu tổng hợp, phục vụ giáo dục

Trường metadata bắt buộc	Nội dung kế hoạch cho CH-01
Title	01-ba-role-lifecycle-and-governance.md — Vai trò Business Analyst, vòng đời công việc, và nguyên tắc quản trị artifact
Level	Foundation 1, dành cho người học đã nắm mục tiêu tổng thể của curriculum và cần hiểu BA vận hành như một vai trò kiểm soát luồng thông tin, không phải vai trò “ghi chép yêu cầu” đơn thuần
Prerequisites	Đọc xong 00-foundations.md; hiểu khái niệm artifact, traceability, controlled content, IN_REVIEW, Project assumption, Verification required; biết phân biệt fact, assumption, và decision
Target capability	Xác định phạm vi trách nhiệm BA, giữ ranh giới thẩm quyền, tổ chức vòng đời công việc BA từ intake đến handoff, và quản trị artifact theo cách truy vết được
Central mental model	BA là “bộ điều hợp bằng chứng”: thu nhận thông tin từ stakeholder, chuyển thành artifact có cấu trúc, duy trì traceability, và chỉ escalate khi vượt thẩm quyền hoặc thiếu xác minh
Nova Foods scenario	BA hỗ trợ một sáng kiến mô phỏng của Nova Foods để chuẩn hóa luồng tiếp nhận đơn hàng bán sỉ, xác nhận nhu cầu xử lý chứng từ, và ghi nhận các điểm cần kiểm tra về dữ liệu, kế toán, và truy xuất nguồn gốc ở mức giáo dục
Required artifacts	BA role map, responsibility boundary note, governance checklist, lifecycle swimlane, decision log skeleton, issue/escalation log skeleton, artifact traceability note
Diagram types	RACI-lite table, lifecycle flow, swimlane mô tả các bước BA, boundary diagram giữa BA / Domain Owner / Legal Owner / Accounting Owner / Tech Owner
Source families	BABOK Guide để lấy thuật ngữ vai trò và năng lực BA; ISO/IEC/IEEE 29148 để giữ tư duy đặc tả yêu cầu có kiểm soát; Luật Bảo vệ dữ liệu cá nhân, Nghị định 356/2025/NĐ-CP, Luật Kế toán, Nghị định 123/2020/NĐ-CP, Luật An toàn thực phẩm chỉ dùng làm ranh giới Verification required khi nội dung chạm nghĩa vụ pháp lý hoặc vận hành nhạy cảm
Quality gate	Người học phải chứng minh được ba điều: xác định đúng việc BA được làm; nêu được điều BA không được tự quyết; và mô tả được cách ghi nhận escalation mà không biến giả định thành quyết định
Traceability dependencies	01_CURRICULUM_ARCHITECTURE.md, CHAPTER_MANIFEST.md, TEMPLATE_MANIFEST.md, TRACEABILITY_ID_REGISTRY.md, COMPETENCY_COVERAGE_MATRIX.md
Independent decisions	Cách đặt lịch họp, cách hỏi làm rõ, cách ghi biên bản, cách phân loại artifact, cách đề xuất format làm việc với stakeholder, cách duy trì decision log ở mức chapter
Escalation decisions	Phải escalate khi câu hỏi chạm pháp lý, kế toán, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc, hoặc khi stakeholder yêu cầu BA xác nhận điều ngoài thẩm quyền như phê duyệt nghiệp vụ, xác nhận compliance, hay quyết định thiết kế
Explicit exclusions	Không dạy chi tiết elicitation technique của chapter 03, không dạy current-state mapping của chapter 04, không dạy requirement writing sâu của chapter 06, không dạy user story và acceptance criteria của chapter 07, không dạy business rules và decision analysis của chapter 08

Mạch nội dung dự kiến của chapter

1. Định nghĩa vai trò BA trong hệ thống phân công công việc của Nova Foods: ai cung cấp thông tin, ai quyết định, ai phê duyệt, ai chịu trách nhiệm xác minh.
2. Chu trình sống của một đầu việc BA: intake, clarify, structure, validate, escalate, handoff, archive.
3. Nguyên tắc quản trị artifact: mỗi artifact phải có mục đích, nguồn vào, người chịu trách nhiệm nội dung, và ranh giới sử dụng.
4. Ranh giới thẩm quyền: BA không thay Legal Owner, Accounting Owner, Domain Owner, hoặc Tech Owner; BA chỉ làm rõ, tổ chức, và truy vết.
5. Cách ghi nhận quyết định và bất định: dùng decision log, issue log, assumption log, và escalation note thay vì ghi nhận mơ hồ trong body text.

Sản phẩm đầu ra ở cấp chapter

Loại đầu ra	Mô tả kỳ vọng
Chapter note	Tóm tắt vai trò BA trong bối cảnh Nova Foods, diễn đạt từ first principles, không dùng thuật ngữ trừu tượng khi chưa định nghĩa
Governance checklist	Danh sách kiểm tra để xác nhận artifact nào đang ở trạng thái nháp, đang review, hoặc cần escalation
Boundary table	Bảng phân tách rõ việc BA tự quyết, việc cần tham vấn, và việc phải chuyển cấp
Lifecycle sketch	Sơ đồ vòng đời công việc BA từ nhận yêu cầu đến bàn giao artifact
Traceability note	Đường liên kết tối thiểu từ chapter này sang architecture và các chapter sau trong band nền tảng
Mini exercise prompt	Bài tập mô phỏng một yêu cầu nội bộ của Nova Foods để người học xác định nhiệm vụ BA, nhiệm vụ stakeholder, và điểm escalation

Tiêu chí đạt của chapter

• Nêu đúng rằng BA quản trị luồng thông tin và bằng chứng, không sở hữu toàn bộ quyết định nghiệp vụ.
• Khi gặp nội dung liên quan pháp lý, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc, chapter phải giữ nhãn Verification required hoặc Project assumption.
• Artifact đầu ra phải đủ để người học dùng làm nền cho chapter 02 và chapter 03 mà không phải suy diễn lại vai trò BA từ đầu.
• Không tạo cảm giác rằng IN_REVIEW là phê duyệt, baseline, hoặc cam kết production.

Ghi chú traceability biên soạn

Chapter 01 phải bám chặt 01_CURRICULUM_ARCHITECTURE.md ở mức kiến trúc, đặc biệt là nguyên tắc tách lớp giữa curriculum architecture và chapter text. Nội dung chapter chỉ được mô tả cách BA làm việc trong mô phỏng Nova Foods; không được biến mô phỏng thành nghĩa vụ pháp lý, quy trình vận hành thật, hoặc cam kết triển khai cho tổ chức thực.

CH-02 — 02-stakeholders-domain-and-context.md

Trường metadata	Kế hoạch nội dung được kiểm soát
Chapter ID / tệp	CH-02 / 02-stakeholders-domain-and-context.md
Tiêu đề chapter	Stakeholders, Domain, and Context — Xác định bên liên quan, miền nghiệp vụ và bối cảnh hệ thống
Trạng thái / phiên bản / ngày	IN_REVIEW / v0.9.0 / 2026-08-07
Bối cảnh áp dụng	vi-VN, Việt Nam, Asia/Ho_Chi_Minh, dữ liệu mô phỏng, đơn vị tiền tệ mô phỏng VND
Cấp độ	Foundation → Novice; chapter đầu tiên biến một vấn đề được nêu bằng ngôn ngữ vận hành thành bản đồ người liên quan, thuật ngữ miền và ranh giới hệ thống có thể kiểm tra.
Điều kiện tiên quyết	Hoàn thành 00-foundations.md và 01-ba-role-lifecycle-and-governance.md; hiểu phân biệt fact, Project assumption, Verification required, artifact owner và decision owner.
Năng lực đích	Learner có thể xác định ai cung cấp thông tin, ai ra quyết định, ai chịu tác động; mô tả thực thể và thuật ngữ Nova Foods mà không tự suy diễn chính sách; xác định system-of-interest, hệ thống lân cận, luồng thông tin và điểm chưa rõ cần chuyển cấp.
Mô hình tư duy trung tâm	Bên liên quan không đồng nghĩa chức danh; miền nghiệp vụ không đồng nghĩa màn hình; bối cảnh hệ thống không đồng nghĩa phạm vi đã được phê duyệt. BA phải tách rõ người có tri thức, người có quyền quyết định, người thực hiện, đối tượng chịu tác động và hệ thống trao đổi dữ liệu trước khi thu thập requirement.

Nova Foods educational scenario: Nova Foods Trading & Manufacturing đang mô phỏng nhu cầu cải thiện luồng tiếp nhận đơn bán hàng cho khách hàng đại lý, kiểm tra tồn kho thành phẩm, xác nhận khả năng giao hàng và chuyển dữ liệu cần thiết sang các hoạt động kho, kế toán và hóa đơn. Thông tin ban đầu từ Sales chỉ nêu “cần giảm thời gian xác nhận đơn”; đây là problem statement mô phỏng, không phải requirement, không phải cam kết SLA và không xác nhận thay đổi production. Learner lập bản đồ các vai trò Sales Representative, Sales Manager, Customer Service, Warehouse Supervisor, Inventory Controller, Accounting Owner, Invoice Specialist, IT Application Support, Domain Owner và Legal Owner; đồng thời phân biệt khách hàng đại lý là external stakeholder với người dùng nội bộ.

Artifact outputs bắt buộc ở cấp chapter

Artifact output	Nội dung tối thiểu	Traceability dependency
STAKEHOLDER-MAP-SALES-001	Stakeholder register cho luồng đơn hàng mô phỏng, gồm vai trò, interest, influence, knowledge area, decision authority, engagement need và source classification.	Liên kết đến NEED-SALES-001 khi need này được hình thành ở chapter sau; trước đó chỉ ghi problem context mô phỏng.
GLOSSARY-NOVA-FOUNDATION-001	Tối thiểu các thuật ngữ nghiệp vụ được dùng trong scenario, với trạng thái Project assumption, fact được nguồn nội bộ mô phỏng hỗ trợ, hoặc Verification required.	Phụ thuộc định nghĩa chuẩn hóa tiếp theo tại CANONICAL_DATA_DICTIONARY.md và glossary corpus; không thay thế nguồn chân lý đó.
CTX-SALES-001	Context diagram và context boundary log cho luồng tiếp nhận/xác nhận đơn hàng.	Là đầu vào cho discovery, as-is process mapping và scope analysis ở các chapter tiếp theo.
QLOG-STAKEHOLDER-001	Question log nêu câu hỏi, stakeholder/owner cần trả lời, lý do, tác động nếu chưa rõ và trạng thái.	Câu hỏi về hóa đơn, hạch toán, dữ liệu cá nhân, an toàn thực phẩm, lô/hạn dùng phải liên kết escalation phù hợp.

Loại sơ đồ được phép và mục đích: context diagram mức khái niệm; stakeholder onion diagram hoặc stakeholder map; domain concept map không chuẩn UML. Nếu sử dụng UML, chapter phải gọi đúng là UML và đối chiếu ngữ nghĩa với UML 2.5.1. Không gọi PlantUML activity diagram là BPMN; BPMN 2.0.2 chỉ được dùng khi chapter cần mô tả process notation, không phải thay thế cho context diagram.

Source families và ranh giới sử dụng

Source family	Classification	Cách dùng trong chapter
BABOK Guide Version 3	Nguồn chuẩn nghề nghiệp	Tham chiếu thuật ngữ BA, stakeholder, elicitation context và phân tích; không tạo số trang hoặc điều khoản không được xác minh.
OMG UML 2.5.1; OMG BPMN 2.0.2	Nguồn chuẩn mô hình hóa	Xác định đúng tên và giới hạn ký pháp khi dùng sơ đồ.
Workshop/interview note mô phỏng Nova Foods	Synthetic project evidence	Cung cấp dữ kiện case study; phải gắn rõ là dữ liệu mô phỏng giáo dục.
CANONICAL_DATA_DICTIONARY.md, CANONICAL_BUSINESS_RULES.md, TRACEABILITY_ID_REGISTRY.md	Controlled corpus dependency	Kiểm tra thuật ngữ, rule ID và quy ước ID; không sao chép hoặc tạo lại nguồn chân lý.
Luật, nghị định Việt Nam về dữ liệu cá nhân, kế toán, hóa đơn, an toàn thực phẩm	Official legal source	Chỉ định tuyến điểm cần xác minh tới owner có thẩm quyền; không diễn giải thành nghĩa vụ Nova Foods.

Quality gate — GATE-CH-02-CONTEXT-001: đạt khi bốn artifact output tồn tại, dùng nhất quán thuật ngữ Nova Foods, phân biệt tối thiểu người cung cấp tri thức với người quyết định, nêu system boundary và ít nhất một interface/câu hỏi cần xác minh. Gate không đạt nếu stakeholder map chỉ liệt kê phòng ban; glossary trộn fact với giả định; context diagram biến hệ thống lân cận thành module nội bộ; hoặc một nội dung pháp lý, kế toán, privacy, hóa đơn, lô hàng, hạn dùng hay an toàn thực phẩm bị ghi như rule đã xác nhận mà không có owner/source phù hợp.

Quyết định learner được tự xử lý: chọn cách nhóm stakeholder để chuẩn bị workshop; ghi nhận mâu thuẫn giữa các ghi chú mô phỏng; đề xuất câu hỏi làm rõ; phân loại tạm thời dữ kiện là Project assumption hoặc Verification required; vẽ boundary khám phá có nêu cơ sở và giới hạn.

Quyết định phải escalation: applicability hoặc diễn giải Luật Bảo vệ dữ liệu cá nhân, Nghị định 356/2025/NĐ-CP, Luật Kế toán, Nghị định 123/2020/NĐ-CP hoặc Luật An toàn thực phẩm đến Legal Owner; cách hạch toán và xử lý hóa đơn đến Accounting Owner; quy tắc lô, hạn dùng, truy xuất hoặc thu hồi đến Domain Owner; quyền truy cập, tích hợp, kiến trúc và ownership dữ liệu đến Architect hoặc System Owner. Escalation phải nêu QLOG-STAKEHOLDER-001, fact hiện có, classification, câu hỏi quyết định, tác động và artifact bị ảnh hưởng.

Loại trừ rõ ràng: Chapter này không viết functional requirement, user story, acceptance criteria, business rule, BPMN as-is, data model logic, API contract, thiết kế UI, test case, scope baseline, RACI được phê duyệt hoặc quyết định triển khai. Nội dung chỉ chuẩn bị bằng chứng con người, miền và bối cảnh để các chapter sau thực hiện discovery và modeling trong trạng thái IN_REVIEW.

CH-03 — 03-discovery-interviewing-and-note-taking.md

Thuộc tính	Kế hoạch nội dung cấp chapter
Chapter ID / tệp	CH-03 / 03-discovery-interviewing-and-note-taking.md
Tiêu đề	Khám phá, phỏng vấn và ghi chép có thể truy vết
Cấp độ	Novice đến Intermediate 1
Điều kiện tiên quyết	Hoàn thành các khái niệm nền tảng BA; hiểu mục tiêu của artifact có kiểm soát, phân biệt fact, Project assumption và Verification required; nhận biết các vai trò và điểm quyết định trong vòng đời BA.
Năng lực mục tiêu	Chuẩn bị và thực hiện một phiên khám phá mô phỏng; đặt câu hỏi mở, câu hỏi làm rõ và câu hỏi kiểm tra giả định; ghi nhận phát biểu thành note có nguồn, ngữ cảnh và mức độ tin cậy; tách observation, interpretation, decision, question và follow-up action trước khi chuyển hóa thành need hoặc requirement.
Mô hình tư duy trung tâm	Discovery không phải là “thu thập yêu cầu” bằng cách chép lời người nói. BA chuyển thông tin chưa cấu trúc thành bằng chứng có thể kiểm tra: nguồn nói gì → trong bối cảnh nào → đó là fact, giả định hay điểm cần xác minh → artifact nào bị ảnh hưởng → ai có thẩm quyền quyết định. Note không phải requirement và không được tự nâng thành rule, policy hoặc approval.
Nova Foods educational scenario	Nova Foods Trading & Manufacturing đang mô phỏng cải tiến luồng tiếp nhận đơn hàng của khách hàng bán lẻ. Sales Coordinator cho biết đơn hàng thường đến qua email và điện thoại; Warehouse Supervisor nêu rủi ro xuất nhầm hàng khi Sales chưa thấy tồn khả dụng; Accounting Representative yêu cầu làm rõ thời điểm chuyển dữ liệu đơn hàng sang xử lý chứng từ. Learner lập kế hoạch phỏng vấn ba vai trò, ghi note có cấu trúc, nhận diện mâu thuẫn giữa tốc độ xác nhận đơn và khả năng đáp ứng tồn kho. Mọi tên, sự kiện và dữ liệu là tổng hợp phục vụ giáo dục.
Đầu ra artifact bắt buộc	Interview brief; stakeholder-specific question guide; interview note log; evidence register; danh sách observation và mâu thuẫn; assumption log; open-question register; follow-up action list; discovery summary liên kết sang need, process và rule analysis khi phù hợp. Các định danh chính thức phải lấy từ TRACEABILITY_ID_REGISTRY.md; chapter không tự tạo hoặc thay đổi quy ước ID chuẩn.
Loại sơ đồ	Context sketch đơn giản để định vị người phỏng vấn và luồng thông tin; conversation flow; affinity map hoặc issue map. Các hình này là công cụ khám phá, không được gắn nhãn BPMN nếu không tuân thủ BPMN 2.0.2 của OMG.
Họ nguồn sử dụng	Nguồn sơ cấp nội bộ mô phỏng: transcript, email mẫu, biểu mẫu đơn hàng mô phỏng, demo quy trình và quan sát được ghi nhận. Nguồn chuẩn nghề nghiệp: BABOK Guide Version 3 để định hướng terminology và thực hành elicitation, không viện dẫn số trang hoặc điều khoản không được kiểm chứng. Nguồn chuẩn mô hình hóa: BPMN 2.0.2 hoặc UML 2.5.1 chỉ khi dùng notation tương ứng. Nguồn pháp lý/chuyên ngành: chỉ dùng để định tuyến câu hỏi đến Legal Owner hoặc Domain Owner; không suy diễn nghĩa vụ chi tiết từ note phỏng vấn.
Cổng chất lượng	Mỗi note phải có ngày, người cung cấp thông tin, vai trò, phương pháp thu thập, chủ đề, source classification và liên kết đến câu hỏi hoặc quan sát gốc. Mỗi kết luận phải phân biệt rõ fact được ghi nhận, diễn giải của BA, Project assumption, Verification required và quyết định đã được ghi nhận trong artifact có thẩm quyền. Mâu thuẫn không được “hòa giải” bằng suy đoán; phải được chuyển thành câu hỏi quyết định có owner.
Phụ thuộc truy vết	Tham chiếu CHAPTER_MANIFEST.md để giữ phạm vi chapter; TRACEABILITY_ID_REGISTRY.md để dùng ID chuẩn; CANONICAL_DATA_DICTIONARY.md để kiểm tra tên thực thể như đơn hàng, khách hàng, tồn kho và lô hàng; CANONICAL_BUSINESS_RULES.md để không sao chép hoặc tự tạo business rule; TEMPLATE_MANIFEST.md để chọn template ghi chép; glossary để chuẩn hóa thuật ngữ. Discovery output là đầu vào dự kiến cho need, current-state process, requirement, acceptance criteria và rule analysis ở các chapter phù hợp.
Quyết định learner được tự xử lý	Chọn thứ tự câu hỏi trong phạm vi mục tiêu đã công bố; dùng câu hỏi “cho tôi ví dụ gần nhất” để làm rõ; gắn nhãn note; nhận diện khoảng trống thông tin; ghi nhận mâu thuẫn; đề xuất follow-up; phân loại sơ bộ thông tin là observation, claim, assumption hoặc question. Learner có thể soạn discovery summary nhưng không được trình bày summary như xác nhận nghiệp vụ.
Quyết định phải escalation	Diễn giải hoặc áp dụng quy định về dữ liệu cá nhân, kế toán, hóa đơn/chứng từ, an toàn thực phẩm, truy xuất nguồn gốc; xác nhận chính sách giá, hạn mức tín dụng, quyền sửa đơn, nguyên tắc giữ hàng hoặc quyền truy cập dữ liệu; quyết định owner của quy trình liên phòng ban; xử lý mâu thuẫn ảnh hưởng tiền, tồn kho, chất lượng, lô hàng hoặc nghĩa vụ pháp lý. Escalation phải nêu note nguồn, câu hỏi cần quyết định, tác động nếu trì hoãn, artifact bị ảnh hưởng và vai trò nhận escalation.
Loại trừ rõ ràng	Không viết requirement hoàn chỉnh, user story, acceptance criteria, BPMN current-state đầy đủ, decision table, thiết kế API, thiết kế dữ liệu, test case hoặc cấu hình ERP. Không biến lời kể của người phỏng vấn thành policy Nova Foods; không xác nhận compliance, accounting treatment, legal applicability hoặc production readiness.

Quy tắc ghi chép tối thiểu: Một note đạt yêu cầu phải cho phép người review trả lời bốn câu hỏi: ai cung cấp thông tin, thông tin được thu bằng cách nào, điều gì thực sự được nói hoặc quan sát, và điều gì BA còn phải xác minh. Ví dụ, phát biểu “Sales cần xác nhận đơn nhanh” chỉ là nhu cầu được nêu bởi nguồn; chưa đủ để kết luận thời hạn xử lý, rule phân bổ tồn kho hoặc cam kết dịch vụ. Nếu note đề cập khách hàng, số điện thoại, địa chỉ giao hàng hoặc dữ liệu cá nhân khác, learner chỉ ghi dữ liệu mô phỏng tối thiểu cần cho bài học và gắn Verification required cho mọi yêu cầu xử lý dữ liệu có thể chịu sự điều chỉnh của Luật Bảo vệ dữ liệu cá nhân và văn bản hướng dẫn.

Tiêu chí hoàn thành chapter: Learner nộp một gói discovery cho tình huống đơn hàng Nova Foods, trong đó có ít nhất một mâu thuẫn được giữ nguyên dưới dạng câu hỏi cần quyết định, ít nhất một giả định được gắn Project assumption, và ít nhất một nội dung cần thẩm quyền được gắn Verification required. Gói này phải chứng minh rằng note, evidence, câu hỏi mở và follow-up action liên kết được với nhau mà không tuyên bố đã có approval.

CH-04 — 04-current-state-as-is-and-process-mapping.md

Trường	Nội dung kế hoạch
Chapter ID	CH-04
File	/01-curriculum/04-current-state-as-is-and-process-mapping.md
Title	Current State (As-Is) and Process Mapping
Level	Foundation, nền tảng quan sát và mô hình hóa hiện trạng
Prerequisites	CH-02 Stakeholders, domain and context; CH-03 Discovery, interviewing and note-taking; nhận thức cơ bản về vai trò BA, thuật ngữ quy trình, và cách ghi chú có truy vết
Target capability	Quan sát một quy trình đang vận hành, tách trigger, actor, input, output, exception, handoff và evidence thành mô hình hiện trạng có thể đọc được bởi business và kỹ thuật
Central mental model	Hiện trạng không phải là “cảm giác về cách làm việc”, mà là chuỗi bước có owner, điều kiện bắt đầu, điều kiện kết thúc, ràng buộc và ngoại lệ; nếu một bước không nêu được ai làm, làm khi nào, nhận gì, trả gì thì bước đó chưa đủ chuẩn để đưa vào as-is
Nova Foods scenario	Mô phỏng chuỗi vận hành Nova Foods Trading & Manufacturing từ lúc đại lý gửi đơn hàng, kiểm tra tồn kho, xác nhận khả năng giao, tạo lệnh xuất kho, bàn giao cho vận chuyển, đến xử lý thiếu hàng, hủy một phần, hoặc trả hàng sau giao nhận; toàn bộ dữ liệu là synthetic data chỉ phục vụ giáo dục
Required artifacts	As-is process narrative; process map cấp cao; swimlane theo vai trò; bảng actor-step-input-output; danh mục điểm đau và nút nghẽn; danh mục ngoại lệ và giả định; log câu hỏi mở cần xác minh
Diagram types	BPMN 2.0.2 cho mô hình hóa quy trình nếu dùng ký hiệu chuẩn; swimlane diagram để thể hiện trách nhiệm; flowchart hoặc UML activity diagram khi cần đơn giản hóa, nhưng phải ghi rõ loại sơ đồ và không gọi nhầm PlantUML activity diagram là BPMN
Source families	BABOK cho tư duy BA và nhiệm vụ hiện trạng; BPMN 2.0.2 cho ký hiệu quy trình; UML 2.5.1 cho activity/state nếu cần; ghi chú phỏng vấn tổng hợp nội bộ; quan sát nghiệp vụ tổng hợp của dự án
Quality gate	Mỗi quy trình phải có ranh giới rõ, ít nhất một trigger, một outcome, một owner chính, và một danh sách exception có tác động; không được để bước mơ hồ, không gắn trách nhiệm, hoặc chứa hai hành động khác bản chất trong cùng một node
Traceability dependencies	Phụ thuộc logic vào khung stakeholder và context từ CH-02, dữ liệu discovery từ CH-03, và quy tắc định danh traceability dùng xuyên suốt corpus; mọi bước quan trọng phải có thể nối tới nguồn ghi nhận hoặc câu hỏi mở
Independent decisions	Chọn mức chi tiết của process map; quyết định gộp hay tách bước; xác định điểm bắt đầu và kết thúc của luồng; xác định vai trò nào là executor, reviewer, approver; chọn ngôn ngữ mô tả business hay system-centric cho từng sơ đồ
Escalation decisions	Escalate khi có xung đột giữa lời kể của các bên, không xác định được owner của bước then chốt, không rõ hệ thống nào là system of record, có dấu hiệu liên quan đến dữ liệu cá nhân, hóa đơn, an toàn thực phẩm, truy xuất nguồn gốc, hoặc khi exception vượt khỏi quyền quyết định của BA
Explicit exclusions	Không thiết kế to-be; không viết requirement, user story, business rule hay acceptance criteria; không phân tích nguyên nhân gốc; không đề xuất solution architecture; không cam kết KPI/SLA; không xác nhận tuân thủ pháp lý hay production readiness

Expected chapter-level outputs cho Chapter 04

Output	Mục đích sử dụng	Tiêu chí chấp nhận thực hành
As-is process narrative	Văn bản mô tả chuỗi hiện trạng bằng ngôn ngữ business	Có mở đầu, kết thúc, actor, bước chính và exception; không dùng từ ngữ chung chung như “xử lý rồi”
Process map cấp cao	Nhìn nhanh được toàn bộ luồng vận hành Nova Foods đang được mô phỏng	Thể hiện đúng thứ tự, không bỏ sót handoff quan trọng, và phân biệt bước người làm với bước hệ thống
Swimlane theo vai trò	Làm rõ trách nhiệm giữa sales, kho, vận hành, giao nhận, CS hoặc vai trò tương đương trong case	Mỗi lane có tên rõ ràng, mỗi bước chỉ nằm ở lane hợp lý, không trộn nhiều trách nhiệm vào một lane
Bảng actor-step-input-output	Dùng làm cầu nối sang requirement và traceability ở các chapter sau	Mỗi dòng có actor, step, input, output, exception và evidence tối thiểu
Danh mục pain points	Ghi lại nghẽn, chậm, lặp, thiếu minh bạch hoặc chuyển giao sai	Pain point mô tả được hiện tượng quan sát được, không nhảy ngay sang giải pháp
Exception and assumption log	Tách điều đã thấy, điều chưa thấy và điều phải xác minh	Mỗi giả định phải gắn nhãn Project assumption hoặc Verification required khi thích hợp
Open questions register	Chuẩn bị đầu vào cho discovery tiếp theo và escalation đúng vai trò	Câu hỏi ngắn, một ý, có owner đề xuất và tác động nếu chưa trả lời

Ranh giới nội dung cần giữ chặt trong chapter này

1. Chỉ mô tả hiện trạng đang vận hành trong bối cảnh Nova Foods mô phỏng, không mô tả trạng thái tương lai hoặc quy trình tối ưu hóa.
2. Mọi nội dung liên quan hóa đơn, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc, kế toán hoặc hệ thống vận hành phải được đánh dấu theo ngữ cảnh nguồn phù hợp; nếu chưa xác minh thì ghi Verification required.
3. Process map chỉ có giá trị khi phản ánh được cách làm thật hoặc cách làm được mô tả nhất quán bởi nguồn tin; nếu nguồn xung đột, phải ghi nhận xung đột thay vì tự hợp nhất.

Mẫu câu định hướng cho người học

• “Ai khởi phát bước này?”
• “Đầu vào tối thiểu là gì?”
• “Đầu ra nào chứng minh bước đã xong?”
• “Ngoại lệ nào làm quy trình rẽ nhánh?”
• “Điểm bàn giao nào dễ mất thông tin nhất?”
• “Bước này thuộc người, hệ thống hay kiểm tra đối soát?”

CH-05 — 05-business-needs-objectives-and-scope.md

Trường	Nội dung kế hoạch
Chapter ID	CH-05
Tên tệp chuẩn	/01-curriculum/05-business-needs-objectives-and-scope.md
Tiêu đề chapter	Business Needs, Objectives, and Scope
Level	Foundation to intermediate bridge
Prerequisites	Hoàn thành Chapter 00–04; đã có khái niệm nền tảng BA, vai trò BA, bối cảnh stakeholder, kỹ thuật khám phá, và mô hình hiện trạng đủ để đọc được pain point mà không nhảy sang solution.
Target capability	Biến quan sát rời rạc thành tuyên bố nhu cầu kinh doanh có kiểm chứng, chuyển nhu cầu thành mục tiêu đo được, rồi khóa phạm vi ở mức đủ để tiếp tục sang requirements mà không làm loãng vấn đề.
Central mental model	“Need trước, objective sau, scope cuối cùng.” Một nhu cầu kinh doanh là lý do phải thay đổi; mục tiêu là kết quả mong đợi; phạm vi là ranh giới thực tế của lần thay đổi này. Nếu ba lớp này trộn lẫn, team sẽ viết requirement cho một vấn đề chưa định nghĩa xong.
Nova Foods scenario	Trong running case mô phỏng của Nova Foods Trading & Manufacturing, các bộ phận Sales, Warehouse và Finance ghi nhận tình trạng đối chiếu đơn hàng, xuất kho và hóa đơn chưa đồng nhất giữa điểm bán, kho trung tâm và chi nhánh. Chapter này không giải quyết bằng giải pháp hệ thống ngay lập tức, mà chuẩn hóa thành business need, objective và scope cho một chương trình cải thiện quy trình và ERP support có kiểm soát.
Required artifacts	Business need statement; objective statement có chỉ số đo; scope statement in/out; assumption log; constraint log; stakeholder impact note; high-level business case outline; traceability seed từ need đến mục tiêu và phạm vi.
Diagram types	Scope boundary diagram; simple context sketch; objective-to-need linkage map; in-scope/out-of-scope matrix. Không dùng BPMN chi tiết ở chapter này vì mục tiêu là khóa vấn đề và ranh giới, chưa phải mô tả luồng thao tác.
Source families	BABOK Guide v3 cho khái niệm need/objective/scope và tư duy BA; ISO/IEC/IEEE 29148 cho nguyên tắc diễn đạt nhu cầu và ranh giới; luật và chuẩn Việt Nam chỉ dùng khi phạm vi có dấu hiệu liên quan kế toán, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc; nguồn nội bộ mô phỏng Nova Foods để dựng bối cảnh giáo dục.
Quality gate	Học viên đạt gate khi phân biệt được: 1) triệu chứng vận hành, 2) nhu cầu kinh doanh, 3) mục tiêu đo được, 4) phạm vi triển khai. Một bản nháp đạt yêu cầu phải có câu “không làm gì” rõ ràng, ít nhất một chỉ số thành công, và ít nhất một giả định cần xác minh.
Traceability dependencies	Phụ thuộc ngược lên Chapter 02 để hiểu stakeholder và domain, Chapter 03 để lấy dữ kiện khám phá, Chapter 04 để có trạng thái hiện tại. Đầu ra chapter này là đầu vào trực tiếp cho Chapter 06, nơi requirement foundation bắt đầu dùng các need/objective/scope đã khóa.
Independent decisions	Quyết định ưu tiên vấn đề nào trong các pain point đã phát hiện; quyết định phạm vi pilot hay phased rollout ở mức giáo dục; quyết định chỉ số thành công ở cấp business outcome; quyết định điều gì nằm ngoài phạm vi lần này.
Escalation decisions	Escalate khi nhu cầu có thể chạm đến nghĩa vụ pháp lý, kế toán, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc mà chưa có Verification required; escalate khi stakeholder tranh cãi về ownership của objective; escalate khi scope trùng lấn giữa nhiều bộ phận và không có decision owner.
Explicit exclusions	Không viết functional requirements chi tiết; không chốt business rule; không thiết kế process as-is/to-be đầy đủ; không lập test case; không khẳng định tuân thủ pháp luật; không biến giả định thành fact đã xác minh; không tạo phê duyệt ngầm cho scope.

Đầu ra artifact cấp chapter

1. Một business need statement ngắn, có nguyên nhân, tác động và bối cảnh Nova Foods rõ ràng.
2. Một objective statement đo được, ưu tiên outcome thay vì output.
3. Một scope statement có cả in-scope và out-of-scope, đủ sắc để tránh trôi phạm vi.
4. Một assumption log và constraint log để giữ ranh giới giữa điều đã biết và điều chưa kiểm chứng.
5. Một traceability seed nối need → objective → scope, làm nền cho requirement ở chapter sau.

Nguyên tắc biên soạn

• Viết từ nhu cầu kinh doanh trước khi nghĩ đến giải pháp hệ thống, vì giải pháp chỉ đúng khi vấn đề được định nghĩa đúng.
• Mỗi mục tiêu phải trả lời được câu hỏi “thành công trông như thế nào” chứ không chỉ “sẽ làm gì”.
• Mỗi scope phải có ranh giới loại trừ rõ ràng; nếu không có out-of-scope thì scope chưa đủ dùng cho planning.
• Với mọi chi tiết liên quan quy định Việt Nam chưa được xác minh bằng nguồn chính thức và vai trò có thẩm quyền, phải gắn nhãn Verification required hoặc Project assumption theo contract của corpus.

CH-06 — 06-requirements-foundations.md

Trường metadata	Kế hoạch nội dung
Chapter ID và tệp	CH-06 — 06-requirements-foundations.md
Tiêu đề	Nền tảng yêu cầu: từ business need đến yêu cầu kiểm tra được
Cấp độ	Intermediate 1 — Đặc tả kiểm tra được
Điều kiện tiên quyết	Hoàn thành nền tảng BA, vòng đời và governance, stakeholder/context, discovery, AS-IS process mapping, business need/objective/scope từ CH-00 đến CH-05. Learner phải phân biệt fact đã ghi nhận, Project assumption và Verification required.
Năng lực đích	Phân rã một business need trong phạm vi thành functional requirement, non-functional requirement hoặc constraint; viết yêu cầu đơn nghĩa, có nguồn, phạm vi, điều kiện và khả năng kiểm tra; liên kết yêu cầu với need, rule, data, acceptance criteria và điểm mở.
Mô hình tư duy trung tâm	Requirement không phải là ý tưởng giải pháp hoặc câu ghi chép từ cuộc họp. Requirement là phát biểu có cấu trúc về năng lực, chất lượng hoặc ràng buộc cần được đáp ứng để giải quyết need trong phạm vi xác định. Chuỗi lập luận là: business objective → need → requirement → rule/data dependency → acceptance criteria → test basis.
Nova Foods scenario	Nova Foods Trading & Manufacturing đang mô phỏng việc chuẩn hóa quy trình tiếp nhận đơn bán hàng B2B cho sản phẩm thực phẩm đóng gói. Sales Coordinator hiện ghi đơn qua nhiều kênh; Inventory Controller cần biết khả dụng tồn kho trước khi cam kết; Finance cần nhận diện điểm cần kiểm tra tín dụng. Case chỉ dùng dữ liệu tổng hợp. Việc xác định chính sách tín dụng, hóa đơn, thuế, kế toán, dữ liệu cá nhân, hạn dùng và truy xuất nguồn gốc vẫn là Verification required khi chưa có owner có thẩm quyền xác minh.
Đầu ra artifact bắt buộc	1. Requirement catalog có tối thiểu các trường: ID, loại, câu requirement, rationale, source, source classification, priority, status, dependency, open question và verification method. 2. Bản nháp REQ-FUNC-SALES-012 liên kết với NEED-SALES-001. 3. Danh sách non-functional requirement và constraint được tách khỏi functional requirement. 4. Requirement quality checklist. 5. Traceability slice từ need đến acceptance criterion dự kiến, không tuyên bố approval.
Loại sơ đồ/mô hình	Requirement traceability map; context-to-requirement mapping; bảng phân rã requirement. Có thể dùng UML use-case diagram chỉ khi ký pháp tuân theo UML 2.5.1; không gọi sơ đồ hoạt động PlantUML là BPMN. Chapter này không yêu cầu thiết kế kiến trúc giải pháp hoặc sơ đồ cơ sở dữ liệu vật lý.
Họ nguồn sử dụng	BABOK Guide Version 3 cho thuật ngữ và thực hành BA; ISO/IEC/IEEE 29148:2018 cho định hướng vòng đời và chất lượng yêu cầu ở mức abstract chính thức; ISTQB CTFL Syllabus v4.0.1 cho khái niệm test basis và khả năng kiểm tra. Nguồn pháp luật Việt Nam chỉ được dùng để định tuyến xác minh bởi Legal Owner hoặc Accounting Owner, không suy diễn điều khoản hay nghĩa vụ chi tiết.
Quality gate	Mỗi requirement phải có một mục tiêu hoặc need nguồn; mô tả một ý kiểm tra được; nêu actor hoặc system boundary khi cần; không chứa từ mơ hồ như “nhanh”, “dễ dùng”, “đầy đủ” nếu không có tiêu chí đo hoặc câu hỏi mở; không nhúng business rule chưa xác minh vào requirement; phân loại đúng fact, Project assumption hoặc Verification required; không có requirement mồ côi hoặc mâu thuẫn scope.
Phụ thuộc truy vết	Nhận đầu vào từ scope và need đã lập ở CH-05, discovery evidence từ CH-03, AS-IS model từ CH-04, stakeholder/context từ CH-02. Dùng ID chuẩn từ TRACEABILITY_ID_REGISTRY.md; dùng thuật ngữ và data element đã được kiểm soát trong CANONICAL_DATA_DICTIONARY.md; tham chiếu rule qua CANONICAL_BUSINESS_RULES.md, không sao chép hoặc tự tạo nguồn chân lý mới. Đầu ra là đầu vào cho CH-07 acceptance criteria, CH-08 rule/state/decision analysis và các chapter testing sau này.
Quyết định learner có thể tự thực hiện	Tách requirement theo outcome quan sát được; đề xuất loại requirement; ghi rationale; liên kết requirement với NEED-SALES-001; nêu dependency; đặt câu hỏi làm rõ; đánh dấu một giả định là Project assumption; ghi Verification required khi bằng chứng hoặc thẩm quyền chưa đủ.
Quyết định phải escalation	Escalate đến Product Owner/Business Owner khi có xung đột mục tiêu, thay đổi scope hoặc priority; Domain Owner khi cần xác thực khả dụng tồn kho, lô hàng, hạn dùng hoặc quy trình bán hàng; Accounting Owner/Legal Owner khi requirement có thể tác động hạch toán, hóa đơn, thuế hoặc lưu giữ chứng từ; Legal Owner khi liên quan dữ liệu cá nhân; Security Architect khi nêu quyền truy cập hoặc kiểm soát bảo mật. Escalation phải nêu ID artifact bị ảnh hưởng, fact hiện có, source classification, câu hỏi quyết định, tác động trì hoãn và owner cần phản hồi.
Loại trừ rõ ràng	Không phê duyệt requirement, không xác nhận compliance hay production readiness; không thiết kế UI, API, schema, workflow automation hoặc kiến trúc; không thay thế rule catalog; không viết acceptance criteria chi tiết hoặc test case; không diễn giải luật, chính sách tín dụng, quy định hóa đơn, quy tắc an toàn thực phẩm hay nghĩa vụ truy xuất nguồn gốc.

Ví dụ hạt giống requirement trong running case

Trường	Nội dung mô phỏng có kiểm soát
Need nguồn	NEED-SALES-001 — Giảm việc Sales Coordinator cam kết đơn B2B khi chưa có thông tin khả dụng tồn kho phù hợp.
Requirement draft	REQ-FUNC-SALES-012 — Hệ thống phải cho phép Sales Coordinator gửi yêu cầu kiểm tra khả dụng tồn kho cho từng dòng hàng của đơn bán B2B trước khi đơn được chuyển sang trạng thái chờ xác nhận.
Dependency	Định nghĩa “khả dụng tồn kho”, trạng thái đơn hợp lệ và dữ liệu kho là dependency cần liên kết tới data dictionary và rule catalog.
Source classification	Discovery note và AS-IS observation của case study mô phỏng; không phải quy định pháp lý, không phải quyết định production.
Điểm cần xác minh	Tiêu chí cho phép cam kết một phần, cách xử lý hàng theo lô/hạn dùng, và điều kiện kiểm tra tín dụng là Verification required bởi Domain Owner, Finance/Accounting Owner hoặc Legal Owner phù hợp.
Hướng kiểm tra	Acceptance criteria ở CH-07 phải kiểm tra được kết quả gửi kiểm tra, dữ liệu phản hồi, trạng thái đơn và xử lý khi thông tin khả dụng chưa có; không tự suy ra business rule chưa được xác minh.

CH-07 — 07-user-stories-and-acceptance-criteria.md

Trường metadata	Kế hoạch nội dung kiểm soát
Chapter ID / tệp	CH-07 / 07-user-stories-and-acceptance-criteria.md
Tiêu đề	User Stories và Acceptance Criteria: Biến nhu cầu thành hành vi kiểm tra được
Cấp độ	Intermediate 1 — đặc tả kiểm tra được
Điều kiện tiên quyết	Hoàn thành các khái niệm về stakeholder, phạm vi, business need và requirement foundation; đọc được ID NEED-SALES-001 và REQ-FUNC-SALES-012; phân biệt fact, Project assumption và Verification required.
Năng lực đích	Viết, phân rã và rà soát user story có actor, mục tiêu và giá trị; soạn acceptance criteria thể hiện điều kiện quan sát được, dữ liệu đầu vào, hành vi hệ thống và kết quả; liên kết story/criteria với need, requirement, business rule và test basis mà không suy diễn chính sách chưa được xác minh.
Mô hình tư duy trung tâm	User story trả lời “ai cần đạt giá trị gì”; acceptance criteria xác định “hệ thống được coi là đáp ứng khi hành vi nào quan sát và kiểm tra được”. Story không thay thế requirement, rule, mockup, test case hoặc quyết định kiến trúc.
Nova Foods scenario	Trong running case Nova Foods Trading & Manufacturing, Nhân viên Kinh doanh cần ghi nhận đơn đặt hàng mô phỏng của khách hàng đại lý để bộ phận Kho có căn cứ chuẩn bị hàng. Learner chuyển NEED-SALES-001 thành phần hành vi thuộc REQ-FUNC-SALES-012, trong đó điều kiện kiểm tra phải nêu dữ liệu đơn hàng, phản hồi khi thiếu dữ liệu và trạng thái đơn hàng được ghi nhận. Mọi điều kiện về giá, thuế, hóa đơn, hạn mức tín dụng, lô thực phẩm hoặc dữ liệu cá nhân chỉ là Project assumption hoặc Verification required cho đến khi owner có thẩm quyền xác minh.
Đầu ra artifact bắt buộc	1) Story backlog hẹp cho luồng tạo đơn hàng mô phỏng; 2) bộ acceptance criteria liên kết với REQ-FUNC-SALES-012; 3) bảng phân rã story và câu hỏi làm rõ; 4) traceability slice NEED-SALES-001 → REQ-FUNC-SALES-012 → AC-SALES-012-03 → test basis dự kiến; 5) danh sách assumptions, điểm Verification required và escalation record.
Loại sơ đồ	Story map theo backbone “tiếp nhận đơn hàng → kiểm tra dữ liệu → ghi nhận đơn”; activity diagram PlantUML chỉ để minh họa luồng học tập, không được gọi là BPMN; state sketch cho trạng thái đơn hàng chỉ khi state và transition đã có nguồn xác định.
Họ nguồn sử dụng	Primary professional source: BABOK Guide Version 3 cho thuật ngữ BA và quản lý requirement; primary testing source: ISTQB CTFL Syllabus v4.0.1 cho test basis, điều kiện kiểm tra và kỹ thuật black-box; normative modeling source: OMG UML 2.5.1 khi dùng state semantics; official legal sources: luật/nghị định Việt Nam trong source seed chỉ để định tuyến xác minh, không suy diễn nghĩa vụ chi tiết; project convention: quy ước ID Nova Foods và cấu trúc artifact của corpus; author recommendation: mẫu viết Given/When/Then và tiêu chí chất lượng.
Quality gate	Mỗi story phải có actor xác định, mục tiêu nghiệp vụ, giá trị và phạm vi hẹp đủ trao đổi; mỗi criterion phải chứa điều kiện hoặc dữ liệu tiền đề, hành động/sự kiện, kết quả quan sát được và liên kết ID. Không chấp nhận criterion chỉ lặp lại story, chứa từ mơ hồ như “nhanh”, “đúng”, “thân thiện” mà thiếu thước đo hoặc owner xác nhận, hoặc gộp nhiều hành vi độc lập trong một dòng.
Phụ thuộc traceability	Đọc nguồn định danh từ TRACEABILITY_ID_REGISTRY.md; tham chiếu need/requirement đã tồn tại, gồm NEED-SALES-001 và REQ-FUNC-SALES-012; kiểm tra rule qua CANONICAL_BUSINESS_RULES.md, định nghĩa thực thể/trường dữ liệu qua CANONICAL_DATA_DICTIONARY.md, mẫu đầu ra qua TEMPLATE_MANIFEST.md, và coverage năng lực qua COMPETENCY_COVERAGE_MATRIX.md. Chapter không được tự tạo lại nguồn chân lý của rule, data definition hoặc ID.
Quyết định learner có thể tự thực hiện	Chọn cách tách một story quá rộng theo actor journey hoặc kết quả nghiệp vụ; viết criterion cho happy path, dữ liệu bắt buộc và lỗi nhập liệu mô phỏng; ghi rõ assumption; phát hiện criterion chưa kiểm tra được; đề xuất liên kết từ requirement đến acceptance criterion.
Quyết định phải escalation	Escalate tới Product/Business Owner khi ưu tiên, giá trị, phạm vi hoặc hành vi nghiệp vụ chưa rõ; tới Domain Owner khi liên quan quy trình kho, lô hàng, hạn dùng hoặc truy xuất; tới Accounting Owner/Legal Owner khi criterion tác động hóa đơn, thuế, hạch toán hoặc lưu giữ chứng từ; tới Legal Owner khi có dữ liệu cá nhân; tới Security/Architecture Owner khi story yêu cầu phân quyền, xác thực, tích hợp hoặc kiểm soát bảo mật. Escalation phải nêu ID ảnh hưởng, fact hiện có, nhãn nguồn, câu hỏi quyết định, tác động chờ quyết định và owner nhận xử lý.
Loại trừ rõ ràng	Không dạy backlog tool configuration, estimation, sprint planning, test case chi tiết, API contract, UI specification hoàn chỉnh, thiết kế database, BPMN chuẩn hóa đầy đủ hoặc phê duyệt requirement. Chapter không xác nhận Nova Foods tuân thủ pháp luật, không diễn giải điều khoản pháp lý, kế toán hay an toàn thực phẩm, và không coi artifact IN_REVIEW là baseline hoặc approval.

Ví dụ artifact tối thiểu trong chapter

ID	Loại	Nội dung mô phỏng có kiểm soát	Liên kết và nhãn
US-SALES-012-01	User story	Là Nhân viên Kinh doanh, tôi muốn ghi nhận đơn đặt hàng của đại lý để đơn có thể được chuyển sang bước chuẩn bị hàng.	Liên kết NEED-SALES-001, REQ-FUNC-SALES-012; trạng thái nội dung IN_REVIEW.
AC-SALES-012-03	Acceptance criterion	Given Nhân viên Kinh doanh đã nhập mã đại lý và ít nhất một dòng hàng mô phỏng hợp lệ, When người dùng chọn ghi nhận đơn, Then hệ thống tạo mã đơn duy nhất và hiển thị trạng thái Đã ghi nhận.	Test basis cho test case ở chapter testing; mã trạng thái phải đối chiếu data/rule canonical trước khi dùng.
AC-SALES-012-04	Acceptance criterion	Given đơn hàng chưa có dòng hàng, When người dùng chọn ghi nhận đơn, Then hệ thống không tạo đơn và hiển thị thông báo yêu cầu bổ sung dòng hàng.	Không suy ra nội dung thông báo pháp lý hoặc chính sách nghiệp vụ.
Q-SALES-012-02	Câu hỏi làm rõ	Giá bán, hạn mức tín dụng và điều kiện xuất hàng có được kiểm tra tại thời điểm ghi nhận đơn hay tại bước sau không?	Verification required; escalation Product/Business Owner và Accounting Owner khi có tác động tài chính.

CH-08 — 08-business-rules-state-and-decision-analysis.md

Trường metadata	Kế hoạch nội dung kiểm soát
Chapter ID / tệp	CH-08 / 08-business-rules-state-and-decision-analysis.md
Tiêu đề	Phân tích quy tắc nghiệp vụ, trạng thái và quyết định
Status / Version / ngày	IN_REVIEW / v0.9.0 / 2026-08-07
Cấp độ	Intermediate 1 — đặc tả kiểm tra được
Điều kiện tiên quyết	Hoàn thành khái niệm need, requirement, stakeholder, discovery, as-is process, scope và acceptance criteria từ CH-00 đến CH-07; biết phân biệt fact, Project assumption và Verification required.
Năng lực mục tiêu	Tách business rule khỏi narrative process, user story và functional requirement; biểu diễn rule bằng cấu trúc điều kiện–hành động–kết quả; mô hình hóa trạng thái, chuyển trạng thái và quyết định để tạo test basis có thể kiểm tra.
Mô hình tư duy trung tâm	Requirement nói hệ thống cần đạt điều gì; business rule xác định điều gì được phép, bị cấm hoặc phải xảy ra trong điều kiện nào; state xác định đối tượng đang ở đâu trong vòng đời; decision logic xác định nhánh xử lý từ dữ kiện đầu vào. Không dùng một câu mơ hồ để thay thế bốn lớp này.
Nova Foods running case	Trong luồng đơn hàng đại lý mô phỏng, Nhân viên Kinh doanh ghi nhận đơn chứa sản phẩm, số lượng và đại lý. ERP cần phân biệt trạng thái đơn, điều kiện cho phép chuyển sang chuẩn bị hàng và điều kiện chặn xử lý. Giá bán, hạn mức tín dụng, điều kiện xuất hàng, quy tắc hóa đơn, kế toán, dữ liệu cá nhân, an toàn thực phẩm và truy xuất nguồn gốc chưa có xác minh phù hợp phải giữ nhãn Verification required, không được diễn giải thành nghĩa vụ đã xác nhận.
Chất lượng đầu ra	Mỗi rule có ID, phát biểu nguyên tử, điều kiện, kết quả, nguồn, phân loại nguồn, owner xác minh, trạng thái xác minh, liên kết requirement/acceptance criterion và ngoại lệ. Mỗi state transition nêu state nguồn, event, guard condition, state đích và hành vi khi bị chặn.
Phụ thuộc traceability	Đầu vào tối thiểu: NEED-SALES-001, REQ-FUNC-SALES-012, US-SALES-012-01, AC-SALES-012-03, AC-SALES-012-04, Q-SALES-012-02. Đầu ra liên kết tới CANONICAL_BUSINESS_RULES.md, CANONICAL_DATA_DICTIONARY.md, TRACEABILITY_ID_REGISTRY.md và test basis ở các chapter testing.
Quyết định người học có thể tự thực hiện	Chuẩn hóa câu rule thành điều kiện–kết quả; nhận diện rule bị nhúng trong user story; vẽ state diagram mô phỏng; tạo decision table cho các tổ hợp dữ kiện đã được cung cấp; đánh dấu thiếu bằng chứng.
Quyết định phải escalation	Applicability hoặc diễn giải pháp lý; quy tắc hạch toán, hóa đơn, thuế, hạn mức tín dụng; điều kiện an toàn thực phẩm, lô, hạn dùng, truy xuất/thu hồi; retention hoặc xử lý dữ liệu cá nhân; quyền override và ngưỡng phê duyệt có tác động tiền, tồn kho hay nghĩa vụ tuân thủ.
Loại trừ rõ ràng	Không thiết kế database schema, workflow engine, API, màn hình chi tiết, thuật toán chấm điểm tín dụng, chính sách giá, chính sách thuế, hạch toán, nội dung pháp lý hoặc cấu hình production. Không tuyên bố rule mô phỏng là rule đã được Nova Foods phê duyệt.

Artifact đầu ra bắt buộc	Nội dung tối thiểu và liên kết
Rule catalog	Bản ghi BR-SALES-004 và các rule liên quan, gồm phát biểu rule, scope, điều kiện, kết quả, ngoại lệ, source classification, owner và nhãn xác minh.
State model	State diagram vòng đời đơn hàng mô phỏng với các trạng thái Đã ghi nhận, Chờ xác minh, Sẵn sàng chuẩn bị hàng, Đã hủy; không suy diễn đây là danh mục trạng thái production.
Transition catalog	Bảng transition chứa event, state nguồn, guard, state đích, kết quả chặn và liên kết REQ-FUNC-SALES-012 hoặc acceptance criterion phù hợp.
Decision table	Bảng quyết định cho việc định tuyến đơn sau ghi nhận, phân biệt đầu vào có bằng chứng với trường đang chờ xác minh.
Rule-question register	Các điểm chưa đủ thẩm quyền được ghi bằng ID câu hỏi, tác động, artifact ảnh hưởng, vai trò nhận escalation và nhãn Verification required.

Ví dụ artifact-ready trong Nova Foods	Nội dung mô phỏng có kiểm soát
BR-SALES-004	Nếu đơn hàng không có ít nhất một dòng hàng, thì hệ thống không được chuyển đơn sang trạng thái Đã ghi nhận. Nguồn: AC-SALES-012-04; phân loại: project artifact; trạng thái: IN_REVIEW.
BR-SALES-005	Nếu đơn đã ở trạng thái Đã hủy, thì không cho phép chuyển trực tiếp sang Sẵn sàng chuẩn bị hàng. Nguồn: mô hình vòng đời mô phỏng; phân loại: author recommendation cho bài học; cần Domain Owner xác nhận nếu áp dụng vào vận hành thực tế.
TR-SALES-012-01	State nguồn Đã ghi nhận; event Hoàn tất kiểm tra điều kiện xử lý; guard: kết quả kiểm tra được ghi nhận là đạt; state đích Sẵn sàng chuẩn bị hàng. Tiêu chí “đạt” chưa được định nghĩa về giá, tín dụng hay tồn kho phải liên kết Q-SALES-012-02, nhãn Verification required.

Loại sơ đồ và quy tắc biểu diễn	Mục đích sử dụng
UML state machine diagram	Thể hiện state, event, guard và transition của đơn hàng. Dùng ngữ nghĩa UML theo UML 2.5.1 khi gọi tên là UML.
Decision table	Bao phủ tổ hợp điều kiện và kết quả, giảm bỏ sót nhánh so với mô tả văn xuôi.
Decision tree	Giải thích thứ tự đánh giá điều kiện cho người đọc nghiệp vụ; không thay thế decision table khi cần chứng minh coverage tổ hợp.
BPMN collaboration/process diagram tham chiếu	Chỉ dùng để chỉ vị trí rule trong quy trình nếu đã dùng BPMN 2.0.2 đúng ký pháp; không gọi activity diagram là BPMN.

Họ nguồn và ranh giới sử dụng	Áp dụng trong chapter
Nguồn chuẩn BA	BABOK Guide Version 3: thuật ngữ BA, phân tích rule, traceability và governance; không bịa số trang hoặc điều khoản.
Nguồn mô hình hóa chuẩn	OMG UML 2.5.1 cho state semantics; OMG BPMN 2.0.2 cho BPMN notation thực tế.
Nguồn kiểm thử	ISTQB CTFL Syllabus v4.0.1: decision table testing và test basis; chapter chỉ chuẩn bị đầu vào, không thay thế chapter kiểm thử.
Nguồn pháp lý chính thức	Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật 88/2015/QH13, Nghị định 123/2020/NĐ-CP và Luật 55/2010/QH12 chỉ dùng để định tuyến xác minh. Mọi yêu cầu suy ra cần Legal Owner, Accounting Owner hoặc Domain Owner xác minh.
Nguồn dự án mô phỏng	Discovery notes, process map, requirement và acceptance criteria của Nova Foods là dữ liệu tổng hợp giáo dục; không phải bằng chứng về chính sách vận hành thật.

Quality gate của chapter: learner chỉ đạt khi rule catalog không lẫn requirement, state model không có transition thiếu event hoặc guard, decision table có kết quả cho mọi tổ hợp điều kiện đã khai báo, và mọi rule về tiền, kế toán, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc chưa xác minh đều mang Verification required cùng đường escalation rõ ràng.

Nova Foods Running Case và Đầu ra Artifact theo Chapter 00–08

Running case chung: Nova Foods Trading & Manufacturing là doanh nghiệp mô phỏng tại Việt Nam, bán và phân phối thực phẩm đóng gói qua đội ngũ Sales và kho vận. Vấn đề xuyên suốt là chuẩn hóa luồng xử lý đơn bán hàng trong ERP: từ tiếp nhận đơn, kiểm tra khách hàng và tồn kho, giữ hàng theo lô, phê duyệt ngoại lệ, xuất kho, đến cung cấp dữ liệu đầu vào cho hóa đơn. Mọi tên, dữ liệu, số tiền VND, cá nhân và tình huống đều là dữ liệu tổng hợp phục vụ giáo dục. Nội dung liên quan hóa đơn, kế toán, dữ liệu cá nhân, an toàn thực phẩm, hạn dùng, lô hàng hoặc truy xuất nguồn gốc phải được ghi là Verification required hoặc Project assumption cho đến khi owner có thẩm quyền xác minh.

Chapter / tệp	Nova Foods educational scenario gắn với running case	Expected artifact outputs cấp chapter
CH-00 /00-foundations.md	Learner nhận brief mô phỏng: Sales nhập đơn qua nhiều kênh, kho xác nhận tồn thủ công và các ngoại lệ chưa có nơi ghi nhận tập trung. Learner phân biệt business problem, stakeholder statement, assumption, requirement và solution proposal trước khi đề xuất ERP.	Problem framing note cho vấn đề xử lý đơn; Glossary seed gồm Customer, Sales Order, Inventory, Batch/Lot, Warehouse, Invoice; Assumption log chứa Project assumption và Verification required; sơ đồ chuỗi khái niệm Problem → Need → Requirement → Acceptance Criteria.
CH-01 /01-ba-role-lifecycle-and-governance.md	Nova Foods khởi động discovery cho cải tiến Sales Order. Sales Manager muốn giảm nhập lại đơn; Warehouse Supervisor muốn không cho xuất khi dữ liệu tồn chưa đáng tin; Accounting Owner nêu nhu cầu kiểm soát dữ liệu đầu vào hóa đơn nhưng chưa xác nhận quy tắc pháp lý.	BA engagement charter mô phỏng; RACI working draft cho Sales, Warehouse, Accounting Owner, Domain Owner, Legal Owner và Architect; Decision and escalation log; lifecycle map từ discovery đến handoff; danh sách boundary không thuộc thẩm quyền BA.
CH-02 /02-stakeholders-domain-and-context.md	Learner lập bản đồ các bên tham gia khi một đơn của khách hàng đại lý cần được Sales tạo, kho phân bổ hàng theo lô và Accounting nhận dữ liệu sau xuất kho. Xung đột quan sát được là Sales ưu tiên tốc độ, còn kho ưu tiên tính chính xác của tồn khả dụng.	Stakeholder map; Stakeholder register; Domain context diagram; Business glossary mở rộng; Context questions backlog; sơ đồ system context phân biệt Nova Foods ERP, người dùng Sales, Warehouse và hệ thống/nguồn dữ liệu ngoài phạm vi nếu chưa xác minh.
CH-03 /03-discovery-interviewing-and-note-taking.md	Learner chuẩn bị và mô phỏng phỏng vấn Sales Executive, Warehouse Supervisor và Accounting Owner về một đơn hàng bị chậm do thiếu thông tin khách hàng, tồn kho và điều kiện xuất hàng. Phát biểu của stakeholder chỉ là input cần phân tích, không tự trở thành fact hoặc rule.	Interview plan; Question guide; Structured interview notes; Observation record; Fact–assumption–question register; Issue log; Follow-up question list; Source classification register phân biệt stakeholder input, project assumption và Verification required.
CH-04 /04-current-state-as-is-and-process-mapping.md	Từ ghi chú discovery, learner mô hình hóa as-is: Sales nhận đơn qua điện thoại hoặc email, nhập bảng tính, gọi kho kiểm tra tồn, kho phản hồi thủ công, rồi Sales xác nhận lại với khách. Điểm đau là nhập trùng, không thấy trạng thái đơn thống nhất và khó truy vết lý do không đáp ứng.	As-is process narrative; As-is process map; Swimlane flow cho Sales và Warehouse; Pain-point register; Process exception list; Current-state evidence matrix; Data handoff list. Sơ đồ phải được gọi là flow hoặc activity diagram nếu không sử dụng ký pháp BPMN 2.0.2 đúng chuẩn.
CH-05 /05-business-needs-objectives-and-scope.md	Nova Foods cần quyết định phạm vi đợt cải tiến đầu tiên: quản lý tạo đơn và kiểm tra khả dụng hàng cho kênh đại lý, không mở rộng ngay sang tối ưu tuyến giao hàng hoặc thay đổi chính sách giá. Learner chuyển pain point đã quan sát thành need và mục tiêu đo được ở mức mô phỏng.	NEED-SALES-001 business need draft; Business objectives register; Scope statement; In-scope / out-of-scope matrix; Success measures draft; Business case hypothesis; Scope risk and dependency log; Decision questions cho Sponsor và Domain Owner.
CH-06 /06-requirements-foundations.md	Dựa trên NEED-SALES-001, learner xác định yêu cầu ERP cần hỗ trợ Sales tạo đơn, kiểm tra dữ liệu bắt buộc và hiển thị trạng thái xử lý. Learner tách functional requirement, data requirement, constraint, rule candidate và non-functional concern thay vì viết một câu bao trùm mọi ý.	Requirements catalogue gồm REQ-FUNC-SALES-012 ở trạng thái nháp; Requirement specification card; Requirement classification matrix; Requirement quality checklist; Open requirement questions; Source-to-requirement trace draft; Requirement ambiguity log.
CH-07 /07-user-stories-and-acceptance-criteria.md	Learner chuyển một phần REQ-FUNC-SALES-012 thành user story cho Sales Executive tạo đơn đại lý và xác định các điều kiện quan sát được: dữ liệu bắt buộc, kết quả lưu thành công, thông báo lỗi và trạng thái đơn. Không coi user story là thay thế cho rule, data definition hoặc quyết định chính sách.	User story backlog; user story liên kết REQ-FUNC-SALES-012; AC-SALES-012-03 acceptance criterion draft; Acceptance-criteria examples cho luồng hợp lệ và lỗi; Story refinement notes; Story-to-requirement trace matrix; Testability questions register.
CH-08 /08-business-rules-state-and-decision-analysis.md	Nova Foods cần làm rõ điều kiện một đơn được chuyển từ Draft sang Submitted, Reserved, Ready for Dispatch hoặc Rejected. Learner phân tích rule candidate về tồn khả dụng, dữ liệu bắt buộc và quyền xử lý ngoại lệ; quy tắc về lô, hạn dùng, hóa đơn hoặc nghĩa vụ pháp lý không được tự xác nhận.	Business rule catalogue với BR-SALES-004 là rule candidate; Order state model; Decision table cho kiểm tra điều kiện tạo/gửi đơn; Rule source register; Rule conflict log; Rule verification queue; liên kết BR-SALES-004 với REQ-FUNC-SALES-012 và AC-SALES-012-03.

Quy tắc liên kết tối thiểu trong band: output của CH-00 đến CH-04 cung cấp bằng chứng và câu hỏi cho NEED-SALES-001; CH-05 định tuyến need vào phạm vi; CH-06 tạo REQ-FUNC-SALES-012; CH-07 tạo AC-SALES-012-03; CH-08 tách BR-SALES-004 và trạng thái đơn khỏi câu requirement. Các liên kết này là traceability mô phỏng phục vụ học tập, không phải quyết định triển khai Nova Foods, baseline, hay phê duyệt.

Chapter Catalog — 09 to 17

CH-09 — Functional Specification Writing

Trường metadata	Giá trị kế hoạch được kiểm soát
Chapter ID	CH-09
Tên tệp chuẩn	/09-functional-specification-writing.md
Tiêu đề chapter	Functional Specification Writing
Status	IN_REVIEW
Version	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale và tiền tệ mô phỏng	vi-VN; Việt Nam; VND
Owner	Principal IT Business Analyst / Technical Curriculum Author
Phân loại	Controlled curriculum chapter plan; nội dung đào tạo BA, không phải functional specification được phê duyệt cho production
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, chỉ sử dụng dữ liệu tổng hợp
Mục tiêu năng lực	Người học chuyển một requirement đã có định danh thành functional specification có phạm vi rõ, hành vi quan sát được, quy tắc tham chiếu, dữ liệu vào/ra, ngoại lệ, tiêu chí chấp nhận và liên kết test basis.
Đầu vào bắt buộc	NEED-SALES-001, REQ-FUNC-SALES-012, AC-SALES-012-03, BR-SALES-004; các định nghĩa dữ liệu, trạng thái và ID phải được đọc từ artifact nguồn chân lý khi các artifact đó tồn tại.
Đầu ra dự kiến	Functional specification draft cho luồng tạo và gửi đơn đại lý Nova Foods; requirement-to-specification matrix; exception catalogue; open-question register; traceability record tới acceptance criterion và test basis.
Ranh giới nội dung	Chapter dạy cách đặc tả hành vi hệ thống; không tự quyết định chính sách bán hàng, hạn mức tín dụng, hạch toán, thuế, hóa đơn, xử lý dữ liệu cá nhân, truy xuất lô hay điều kiện an toàn thực phẩm.
Baseline reference	Chưa có baseline reference tại v0.9.0.
Approval reference	Chưa có approval được ghi nhận; IN_REVIEW không là xác nhận nghiệp vụ, pháp lý, kiến trúc hoặc production.
Change history	Khởi tạo kế hoạch chapter CH-09 tại v0.9.0, ngày 2026-08-07; xác định metadata, artifact dự kiến, source boundary và traceability dependencies.

Phạm vi giảng dạy. Functional specification trả lời từ nguyên lý đầu tiên: hệ thống phải làm gì khi actor thực hiện một hành động trong ngữ cảnh dữ liệu và trạng thái xác định; hệ thống phản hồi thế nào khi điều kiện hợp lệ hoặc không hợp lệ; và bằng chứng nào cho phép kiểm thử hành vi đó. Specification không được chỉ lặp lại câu requirement. Ví dụ, từ REQ-FUNC-SALES-012, learner phải phân rã thành actor Sales Executive, precondition đơn ở trạng thái Draft, trigger gửi đơn, dữ liệu bắt buộc, kiểm tra rule tham chiếu BR-SALES-004, kết quả trạng thái, thông báo lỗi và hậu điều kiện audit phù hợp với phạm vi mô phỏng.

Nhóm artifact bắt buộc	Artifact dự kiến trong chapter	Quy tắc chất lượng và ranh giới
Functional specification	FS-SALES-012 bản nháp cho hành vi tạo, lưu và gửi đơn đại lý	Mỗi hành vi có ID, mục đích, actor, trigger, precondition, main flow, alternate/exception flow, postcondition và liên kết requirement.
Use-case specification	Use case “Tạo và gửi đơn đại lý”	Không dùng use case để che giấu rule; rule được tham chiếu bằng BR-SALES-004 và diễn giải chưa xác minh giữ nhãn phù hợp.
Business-rule reference list	Danh sách rule được gọi trong từng bước xử lý	Không sao chép rule thành nhiều bản. Nội dung về giá, tồn kho, lô, hạn dùng, hóa đơn hoặc pháp lý phải nêu Project assumption hoặc Verification required khi thiếu xác minh có thẩm quyền.
Data interaction matrix	Ma trận trường dữ liệu: tên hiển thị, định danh dữ liệu chuẩn, nguồn nhập, bắt buộc, kiểm tra, kết quả sử dụng	Không tự định nghĩa lại master data; tham chiếu CANONICAL_DATA_DICTIONARY.md khi artifact này cung cấp định nghĩa chuẩn.
Exception catalogue	Các ngoại lệ như thiếu mã đại lý, số lượng không hợp lệ, đơn không còn ở Draft, không thỏa điều kiện rule	Mỗi ngoại lệ nêu điều kiện kích hoạt, thông báo kỳ vọng, thay đổi trạng thái, dữ liệu không được ghi và ID acceptance criterion liên quan.
Open-question and escalation register	Câu hỏi chưa đủ bằng chứng về quyền vượt ngoại lệ, điều kiện giữ hàng, dữ liệu khách hàng hoặc chứng từ	Mỗi dòng phải có fact hiện có, nhãn source classification, câu hỏi quyết định, tác động, vai trò nhận escalation và artifact bị ảnh hưởng.
Traceability matrix	NEED-SALES-001 → REQ-FUNC-SALES-012 → FS-SALES-012 → AC-SALES-012-03 → test basis dự kiến	Traceability chứng minh nguồn gốc và khả năng kiểm tra; không chứng minh approval hoặc compliance.

Loại sơ đồ cần có	Mục đích sử dụng trong CH-09	Chuẩn và hạn chế
UML use-case diagram	Hiển thị ranh giới hệ thống mô phỏng, actor Sales Executive và use case tạo/gửi đơn	Dùng ngữ nghĩa UML 2.5.1 khi gọi là UML; không coi sơ đồ minh họa không tuân ngữ nghĩa là UML chuẩn.
UML activity diagram hoặc flowchart có nhãn rõ	Trình bày luồng chính và nhánh lỗi của việc gửi đơn	Nếu dùng PlantUML activity diagram, phải gọi đúng là UML activity diagram hoặc flowchart, không gọi là BPMN.
State transition diagram	Liên kết hành vi specification với trạng thái Draft, Submitted, Reserved, Ready for Dispatch, Rejected đã được quy hoạch ở CH-08	Không tạo trạng thái hoặc transition mới mà không có rule/source record.
Sequence diagram mức logic	Làm rõ thứ tự tương tác giữa UI, order service, rule evaluation và persistence boundary	Làm rõ đây là mô hình logic; không khẳng định API contract, kiến trúc triển khai hoặc cơ chế tích hợp đã được quyết định.

Source family	Phân loại nguồn	Cách sử dụng được phép trong chapter
BABOK Guide v3	Nguồn nghề nghiệp BA chính	Dùng thuật ngữ và định hướng thực hành về requirements analysis, traceability, stakeholder communication; không tạo số trang hoặc trích dẫn chi tiết không được xác minh.
ISO/IEC/IEEE 29148:2018	Tiêu chuẩn requirements engineering; chỉ xác nhận thư mục và abstract công khai	Dùng để định hướng thuộc tính specification rõ ràng, nhất quán, truy vết và kiểm tra được; xác minh licensed text trước khi nêu clause cụ thể.
UML 2.5.1 và BPMN 2.0.2	Nguồn chuẩn notation	Dùng theo đúng loại sơ đồ đã công bố; BPMN chỉ áp dụng khi sơ đồ dùng ký pháp BPMN thực sự.
ISTQB CTFL Syllabus v4.0.1	Nguồn thuật ngữ kiểm thử chính	Dùng để kết nối specification với test basis, test condition và hành vi kiểm tra được; không viết test case đầy đủ thay cho phạm vi chapter.
Canonical corpus artifacts	Nguồn nội bộ có kiểm soát	TRACEABILITY_ID_REGISTRY.md, CANONICAL_BUSINESS_RULES.md, CANONICAL_DATA_DICTIONARY.md, glossary và template manifest là nguồn ID, thuật ngữ, rule và định nghĩa dữ liệu khi được thiết lập.
Nova Foods case evidence	Dữ liệu mô phỏng giáo dục	Chỉ dùng NEED-SALES-001, REQ-FUNC-SALES-012, AC-SALES-012-03, BR-SALES-004 và dữ kiện tổng hợp; không suy diễn đây là quy trình thực tế của doanh nghiệp.
Legal và regulatory sources	Nguồn pháp luật chính thức, cần owner xác minh applicability	Nếu specification chạm dữ liệu cá nhân, kế toán, hóa đơn, thực phẩm, lô hoặc truy xuất, chỉ ghi Verification required hoặc Project assumption cho tới khi Legal Owner, Accounting Owner hoặc Domain Owner xác minh.

Quy tắc traceability tối thiểu. Mỗi section hành vi trong FS-SALES-012 phải mang một liên kết ngược tới REQ-FUNC-SALES-012; mỗi điều kiện chấp nhận áp dụng phải tham chiếu AC-SALES-012-03; mỗi điểm ra quyết định nghiệp vụ phải tham chiếu BR-SALES-004 hoặc được ghi là câu hỏi mở; mỗi trường dữ liệu phải có định danh hoặc đường dẫn tới data dictionary; mỗi ngoại lệ phải cung cấp test basis dự kiến. Nếu một mô tả cần quyết định về giá trị tiền VND, tồn kho, hóa đơn, thông tin khách hàng, lô hàng hoặc hạn dùng nhưng nguồn chưa đủ, learner không được tự hoàn tất bằng quy tắc tưởng định mà phải tạo bản ghi Verification required có escalation owner phù hợp.

CH-10 — 10-nonfunctional-requirements-and-quality-attributes.md

Trường metadata	Giá trị lập kế hoạch
Chapter ID	CH-10
Tên tệp được kiểm soát	10-nonfunctional-requirements-and-quality-attributes.md
Vị trí dự kiến	/02-handbook/10-nonfunctional-requirements-and-quality-attributes.md
Tiêu đề chapter	Nonfunctional Requirements and Quality Attributes
Status	IN_REVIEW
Version	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ, locale, tiền tệ	Asia/Ho_Chi_Minh; vi-VN; bối cảnh Việt Nam; VND cho dữ liệu Nova Foods mô phỏng
Owner	Principal IT Business Analyst / Technical Curriculum Author
Phân loại	Handbook chapter plan; controlled educational artifact
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp
Mục đích	Hướng dẫn chuyển các kỳ vọng chất lượng như hiệu năng, tính sẵn sàng, bảo mật, khả năng sử dụng, khả năng truy vết, khả năng bảo trì và khả năng quan sát thành nonfunctional requirement (NFR) đo được, có phạm vi, tiêu chí kiểm chứng và đường truy vết.
Ranh giới nội dung	Chapter giải thích cách đặc tả và phân tích NFR; không tự xác nhận kiến trúc, ngưỡng production, tuân thủ pháp luật, mức bảo mật phù hợp, SLA với nhà cung cấp, hoặc phê duyệt chất lượng cho Nova Foods.
Điều kiện đầu vào	Need, functional requirement, acceptance criterion và thuật ngữ định danh từ các chapter requirements trước đó; các ID phải tuân thủ /01-curriculum/CHAPTER_MANIFEST.md và TRACEABILITY_ID_REGISTRY.md.
Đầu ra học tập dự kiến	NFR catalog, quality-attribute scenario, quality-risk register, verification approach, assumption log và traceability links từ need hoặc requirement chức năng đến NFR và test basis.
Change history hiện hành	v0.9.0 ngày 2026-08-07, IN_REVIEW: khởi tạo kế hoạch metadata, phạm vi, artifact, nguồn và dependency cho CH-10; chưa có baseline reference hoặc approval reference.

Thành phần nội dung hoặc artifact bắt buộc	Mức chi tiết phải có trong chapter
NFR catalog	Mỗi dòng có NFR-{DOMAIN}-{NNN}, tên thuộc tính chất lượng, mô tả điều kiện, phạm vi chức năng hoặc dịch vụ, chỉ số đo, ngưỡng mục tiêu, phương pháp đo, source classification, owner cần xác minh, trạng thái và liên kết requirement.
Quality-attribute scenario	Dùng cấu trúc: tác nhân hoặc nguồn kích hoạt, stimulus, môi trường, artifact chịu tác động, phản hồi quan sát được, chỉ số phản hồi. Ví dụ mô phỏng phải ghi rõ Project assumption nếu ngưỡng chưa được xác minh.
Quality-risk register	Nêu rủi ro, nguyên nhân, tác động business, tín hiệu phát hiện, NFR giảm thiểu, dependency và vai trò escalation; không thay thế risk decision của Architect, Security Owner, Legal Owner hoặc Domain Owner.
Verification matrix	Liên kết NFR với inspection, analysis, demonstration hoặc test; xác định test basis dự kiến thay vì tuyên bố đã kiểm thử.
Assumption và verification log	Tách riêng fact có nguồn, Project assumption và Verification required. Nội dung về dữ liệu cá nhân, hóa đơn, kế toán, an toàn thực phẩm, truy xuất nguồn gốc hoặc bảo mật phải giữ nhãn phù hợp khi chưa có xác minh có thẩm quyền.
Ví dụ Nova Foods	Có thể dùng tình huống tra cứu tồn kho, tạo đơn hàng, đồng bộ dữ liệu đối tác hoặc truy vết lô hàng mô phỏng; không gán ngưỡng thời gian, retention, quyền truy cập hay nghĩa vụ pháp lý như fact nếu chỉ là giả định học tập.

Loại diagram yêu cầu	Mục đích và giới hạn
Quality-attribute scenario map	Trực quan hóa quan hệ stimulus, hệ thống hoặc thành phần chịu tác động, response và measure; không phải sơ đồ kiến trúc được phê duyệt.
Context-and-boundary diagram	Xác định người dùng, hệ thống Nova Foods mô phỏng, external actor và ranh giới nơi NFR áp dụng; dùng notation được chú thích rõ.
Traceability graph	Thể hiện chuỗi NEED-* hoặc REQ-FUNC-* → NFR-* → AC-* hoặc test basis dự kiến; không gọi liên kết là bằng chứng pass test.
Quality-risk heat map	Minh họa ưu tiên phân tích theo impact và uncertainty; thang đo phải được định nghĩa trong chapter là quy ước học tập.

Source family	Phân loại và ranh giới sử dụng
BABOK Guide v3	Nguồn phương pháp BA và thuật ngữ; không tạo trích dẫn trang hoặc nội dung licensed text chưa được xác minh.
ISO/IEC/IEEE 29148:2018	Nguồn chuẩn cho định hướng đặc tả requirements; chỉ dùng abstract và trạng thái thư mục chính thức khi không có quyền kiểm tra toàn văn điều khoản.
WCAG 2.2	Nguồn normative cho accessibility; claim về success criterion phải khớp nguồn W3C, không suy diễn mức tuân thủ cho Nova Foods.
OWASP ASVS 5.0.0 và OWASP API Security Top 10 2023	Industry security verification và awareness source; không phải luật Việt Nam, không tự biến thành security control đã được chấp thuận.
ISTQB CTFL Syllabus v4.0.1	Nguồn thuật ngữ testing và kỹ thuật black-box cho verification approach.
Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP	Nguồn pháp lý chính thức về bảo vệ dữ liệu cá nhân; mọi NFR suy ra cần Verification required và Legal Owner xác minh applicability, diễn giải, phạm vi.
Luật 88/2015/QH13, Nghị định 123/2020/NĐ-CP, Luật 55/2010/QH12	Nguồn pháp lý chính thức liên quan kế toán, hóa đơn và an toàn thực phẩm; chapter chỉ định tuyến câu hỏi xác minh, không diễn giải nghĩa vụ vận hành hoặc pháp lý.

Dependency và quy tắc traceability	Yêu cầu lập kế hoạch
Upstream	CH-08, CH-09, CANONICAL_BUSINESS_RULES.md, CANONICAL_DATA_DICTIONARY.md, TRACEABILITY_ID_REGISTRY.md, glossary và source register cung cấp need, requirement, rule, thực thể, thuật ngữ và ID hợp lệ.
Downstream	CH-12 dùng NFR liên quan API, reliability và security; CH-14 dùng usability và accessibility; CH-15 dùng reporting performance và data-quality expectation; CH-17 dùng quality-risk, assumption và verification gap cho handoff.
Chuỗi ID tối thiểu	Một NFR phải liên kết ít nhất một trong các nguồn NEED-*, REQ-FUNC-*, BR-*, risk hoặc source record; khi có test basis, dùng chuỗi NFR-* → AC-* hoặc TC-* theo registry, không tự tạo định dạng ID khác.
Quy tắc chất lượng	Không viết “nhanh”, “an toàn”, “dễ dùng” hoặc “ổn định” mà thiếu phạm vi, điều kiện đo và cách kiểm chứng. Ngưỡng chưa có bằng chứng phải ghi Project assumption hoặc Verification required, kèm vai trò cần quyết định.

CH-11 — 11-data-modeling-and-master-data.md

Trường metadata	Giá trị kiểm soát
Chapter ID	CH-11
Tên tệp được kiểm soát	/11-data-modeling-and-master-data.md
Tiêu đề chapter	Data Modeling and Master Data
Status	IN_REVIEW
Version	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale và tiền tệ mô phỏng	vi-VN; Việt Nam; VND
Owner	Principal IT Business Analyst / Technical Curriculum Author
Phân loại	Controlled curriculum chapter plan
Bối cảnh áp dụng	Nova Foods Trading & Manufacturing; dữ liệu tổng hợp phục vụ giáo dục
Mục tiêu	Hướng dẫn learner chuyển khái niệm nghiệp vụ thành mô hình dữ liệu có cấu trúc, phân biệt master data, transaction data, reference data và audit data; đồng thời mô tả ownership, chất lượng, vòng đời và liên kết requirement có thể kiểm tra.
Điều kiện đầu vào	Learner đã biết viết need, functional requirement, acceptance criterion và nhận diện business rule; ví dụ chuỗi NEED-SALES-001 → REQ-FUNC-SALES-012 → AC-SALES-012-03.
Đầu ra dự kiến	Data glossary, logical data model, master-data catalog, field-level data dictionary draft, data-quality rule register, ownership matrix và traceability links.
Ranh giới	Chapter lập kế hoạch và đào tạo BA, không phê duyệt schema vật lý, không quyết định kiến trúc cơ sở dữ liệu, retention, phân quyền production, hạch toán, thuế, hóa đơn hoặc nghĩa vụ pháp lý.
Baseline reference	Chưa có baseline reference tại v0.9.0.
Approval reference	Chưa có approval reference tại v0.9.0; IN_REVIEW không là xác nhận nghiệp vụ, pháp lý, kế toán, bảo mật hoặc production.

Nội dung phải được soạn trong chapter. Learner phải mô hình hóa các thực thể Nova Foods ở mức logic trước khi đề xuất bảng hoặc API. Mỗi thực thể cần có business definition, khóa nhận diện, thuộc tính bắt buộc, quan hệ, owner, lifecycle state và nguồn tạo/cập nhật. Phân loại dữ liệu phải rõ: sản phẩm, khách hàng, nhà cung cấp, kho và đơn vị tính là master data; đơn bán hàng, phiếu nhập kho và giao dịch điều chỉnh là transaction data; danh mục trạng thái và loại đơn vị tính là reference data. Lịch sử thay đổi giá trị, người thay đổi và thời điểm thay đổi được xem là audit data; retention và quyền truy cập của audit data là Verification required khi chưa có xác minh từ Security Owner, Legal Owner hoặc owner có thẩm quyền.

Artifact type bắt buộc	Nội dung tối thiểu và tiêu chí dùng được
Business data glossary	Định nghĩa không trùng nghĩa cho thuật ngữ như sản phẩm, lô hàng, kho, khách hàng và đơn vị tính; nêu synonym bị cấm nếu gây nhầm lẫn.
Logical data model	Entity, attribute, primary business identifier, cardinality, quan hệ bắt buộc hoặc tùy chọn, và giả định mô hình. Không gọi logical model là physical database design.
Master-data catalog	Mỗi domain có data owner, steward dự kiến, hệ thống nguồn dự kiến, quy tắc tạo/sửa/ngừng dùng và consumer chính. Ownership chưa được xác nhận phải gắn Project assumption.
Data dictionary draft	Tên trường nghiệp vụ, định nghĩa, data type logic, format, allowed values, mandatory condition, sensitivity classification, ví dụ dữ liệu tổng hợp và traceability ID.
Data-quality rule register	Quy tắc completeness, uniqueness, validity, consistency và timeliness; mỗi rule nêu dữ liệu kiểm tra, điều kiện lỗi, tác động và owner xử lý.
CRUD and lifecycle matrix	Liên kết vai trò nghiệp vụ với Create, Read, Update, Retire cho master data; phân biệt retire với xóa lịch sử. Quyền thực tế là Verification required cho đến khi Security Owner xác nhận.
Mapping and reconciliation worksheet	Mô tả mapping nguồn–đích ở mức business field, transformation rule, xử lý giá trị thiếu, reject path và đối soát tổng số bản ghi; không khẳng định cơ chế tích hợp kỹ thuật.

Diagram type bắt buộc	Mục đích và giới hạn biểu đạt
Entity-relationship diagram mức logic	Thể hiện thực thể và quan hệ, ví dụ Product–Unit of Measure, Product–Lot, Warehouse–Inventory Balance; ký pháp phải được giải thích trong legend.
Master-data lifecycle diagram	Thể hiện các trạng thái đề xuất như tạo, chờ kiểm tra, đang hoạt động, ngừng dùng; trạng thái thực tế của Nova Foods chỉ được ghi sau xác minh Domain Owner.
Data lineage diagram	Thể hiện nguồn nghiệp vụ, nơi tiêu thụ và điểm kiểm soát chất lượng cho một trường quan trọng; không thay thế data-flow kỹ thuật hoặc thiết kế API.
Data ownership swimlane	Làm rõ trách nhiệm tạo, xác minh, cập nhật, ngừng dùng và xử lý lỗi dữ liệu giữa Business Owner, Data Steward, BA và các owner liên quan.

Source family	Phân loại nguồn	Cách sử dụng và boundary
/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Controlled planning artifact	Nguồn cho thứ tự năng lực, ranh giới thẩm quyền, trạng thái IN_REVIEW và quy tắc không nâng assumption thành fact.
CHAPTER_MANIFEST.md	Controlled manifest	Nguồn cho chapter ID, filename, phạm vi catalog và metadata của chapter.
CANONICAL_DATA_DICTIONARY.md	Canonical internal source	Nguồn chân lý dự kiến cho định nghĩa dữ liệu, tên trường và phân loại dữ liệu; chapter không tự tạo định nghĩa cạnh tranh.
TRACEABILITY_ID_REGISTRY.md	Canonical internal source	Nguồn chân lý cho định danh traceability; mọi ID mới phải theo registry, không tự đặt định danh như nguồn chuẩn.
CANONICAL_BUSINESS_RULES.md	Canonical internal source	Nguồn để liên kết validation, lifecycle và quality rule với business rule đã quản trị; không sao chép hoặc đổi nghĩa rule.
BABOK Guide Version 3	Primary professional source	Dùng thuật ngữ và cách tiếp cận BA về information management, elicitation và analysis; không tạo số trang hoặc điều khoản không được xác minh.
Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15 và Nghị định 356/2025/NĐ-CP	Official legal source	Chỉ định tuyến các câu hỏi về dữ liệu cá nhân, mục đích xử lý, lưu giữ và quyền truy cập tới Legal Owner; không tự diễn giải nghĩa vụ chi tiết.
Luật Kế toán 88/2015/QH13, Nghị định 123/2020/NĐ-CP và Luật An toàn thực phẩm 55/2010/QH12	Official legal source	Dùng để nhận diện nhu cầu xác minh cho dữ liệu kế toán, hóa đơn, lô hàng, truy xuất và thu hồi; yêu cầu cụ thể phải có Accounting Owner, Legal Owner hoặc Domain Owner xác minh.

Phụ thuộc traceability bắt buộc: mỗi định nghĩa dữ liệu hoặc data-quality rule phải liên kết ngược đến need, requirement, acceptance criterion hoặc business rule đang giải thích; liên kết xuôi đến test basis khi có. Chuỗi mẫu hợp lệ là NEED-SALES-001 → REQ-FUNC-SALES-012 → AC-SALES-012-03 → thuộc tính và quality rule trong data dictionary → TC-SALES-012-07. Nếu thiếu requirement hoặc rule nguồn, mục dữ liệu phải được ghi là Project assumption hoặc Verification required, nêu câu hỏi cần quyết định và owner nhận escalation; không được suy diễn yêu cầu Nova Foods từ tên trường hoặc sơ đồ.

CH-12 — 12-api-and-integration-analysis.md

Trường kiểm soát	Giá trị kế hoạch
Chapter ID	CH-12
Tên tệp được kiểm soát	12-api-and-integration-analysis.md
Vị trí dự kiến	/01-curriculum/12-api-and-integration-analysis.md
Tiêu đề chapter	API and Integration Analysis
Status	IN_REVIEW
Version	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale và tiền tệ mô phỏng	vi-VN; Việt Nam; VND
Owner	Principal IT Business Analyst / Technical Curriculum Author
Phân loại	Controlled curriculum chapter plan; nội dung đào tạo BA về phân tích API và tích hợp
Bối cảnh thực hành	Nova Foods Trading & Manufacturing; dữ liệu tổng hợp, chỉ dùng cho mục đích giáo dục
Mục tiêu học tập	Người học chuyển một nhu cầu liên hệ thống thành integration requirement kiểm tra được: xác định hệ thống nguồn/đích, trigger, dữ liệu trao đổi, hợp đồng API, mapping, lỗi, idempotency, bảo mật, quan sát vận hành và liên kết traceability.
Ranh giới chapter	Phân tích và đặc tả tích hợp ở góc nhìn BA. Không thay Architect quyết định kiến trúc đích, không thay Security Owner phê duyệt cơ chế bảo mật, không tự diễn giải nghĩa vụ pháp lý về dữ liệu cá nhân, hóa đơn, kế toán hoặc truy xuất thực phẩm.
Đầu vào bắt buộc	Need, functional requirement, business rule, acceptance criterion và định nghĩa dữ liệu đã có định danh; các điểm chưa xác minh phải giữ nhãn Project assumption hoặc Verification required.
Đầu ra bắt buộc	Integration context, interface inventory, API requirement, event/message contract draft, field mapping, error-handling matrix, dependency/risk register entry và liên kết từ requirement đến tiêu chí kiểm tra.
Baseline reference	Chưa có baseline reference tại v0.9.0.
Approval reference	Chưa có approval được ghi nhận. IN_REVIEW không xác nhận thiết kế tích hợp, hợp đồng API hoặc quyền xử lý dữ liệu.
Change-history record	v0.9.0 — 2026-08-07 — IN_REVIEW — Principal IT Business Analyst / Technical Curriculum Author — khởi tạo kế hoạch metadata cho CH-12 — không tác động baseline vì chưa có baseline reference.

Nhóm artifact phải được dạy và lập kế hoạch	Định danh hoặc cấu trúc tối thiểu	Quy tắc chất lượng
Interface inventory	INT-{DOMAIN}-{NNN}; hệ thống nguồn, hệ thống đích, mục đích, kiểu trao đổi, owner, trạng thái	Một dòng mô tả một interface có ranh giới rõ; không gộp API đồng bộ và file batch thành một interface.
API requirement	Liên kết REQ-FUNC-* → INT-*; method, endpoint hoặc operation dự kiến, trigger, request, response, lỗi nghiệp vụ	Requirement mô tả kết quả cần đạt, không giả định endpoint là quyết định kiến trúc đã được phê duyệt.
Contract draft	OAS 3.1.1 draft hoặc bảng request/response schema; trường, kiểu dữ liệu, bắt buộc, nullability, mã lỗi	Nếu dùng OpenAPI, phân biệt rõ contract draft giáo dục với API triển khai; không tuyên bố endpoint hoạt động.
Data mapping	MAP-{DOMAIN}-{NNN}; source field, target field, biến đổi, default, rule, owner xác minh	Mọi trường phải tham chiếu định nghĩa trong CANONICAL_DATA_DICTIONARY.md; không tự đặt lại nghĩa của mã khách hàng, mã hàng, lô hoặc tiền tệ.
Error-handling matrix	timeout, validation error, duplicate request, unavailable dependency, business rejection, retry/escalation	Phân biệt lỗi kỹ thuật với từ chối nghiệp vụ; mỗi lỗi phải có phản hồi quan sát được và chủ sở hữu xử lý dự kiến.
Integration risk/escalation record	giả định, bằng chứng hiện có, câu hỏi quyết định, tác động, vai trò nhận escalation	Privacy, security, accounting, e-invoice, food safety và traceability chưa được xác minh phải gắn Verification required.

Loại sơ đồ bắt buộc	Mục đích phân tích	Ký pháp và giới hạn
System context diagram	Xác định Nova Foods ERP, hệ thống ngoài, actor và boundary trao đổi dữ liệu	Dùng sơ đồ ngữ cảnh có chú giải; không biểu diễn như BPMN nếu không dùng ký pháp BPMN 2.0.2.
Sequence diagram	Làm rõ thứ tự request, response, callback hoặc thông báo lỗi giữa các thành phần	Có thể dùng UML sequence diagram, tham chiếu UML 2.5.1; phải nêu trigger và điểm kết thúc giao dịch.
Data-flow diagram	Chỉ ra dữ liệu nào đi từ nguồn sang đích, qua đâu và ở trạng thái nào	Không suy ra phân loại pháp lý của dữ liệu nếu chưa có Legal Owner xác minh.
Event-flow diagram	Mô tả event producer, consumer, payload và xử lý giao nhận bất đồng bộ	Nêu rõ delivery assumption, thứ tự event và xử lý trùng lặp là Project assumption nếu chưa được quyết định.

Source family	Nguồn dự kiến	Ranh giới sử dụng
BA và yêu cầu	BABOK Guide v3; ISO/IEC/IEEE 29148:2018	Dùng thuật ngữ phân tích requirement, stakeholder, traceability và chất lượng đặc tả; không tạo tham chiếu điều khoản hoặc trang không được xác minh.
Hợp đồng HTTP API	OpenAPI Specification 3.1.1 — https://spec.openapis.org/oas/v3.1.1.html	Nguồn chuẩn cho mô tả API HTTP và cấu trúc OAS; không biến ví dụ schema thành API production.
Mô hình hóa	UML 2.5.1; BPMN 2.0.2 khi cần mô tả process liên quan	Sequence diagram tuân theo ngữ nghĩa UML; BPMN chỉ dùng khi thực sự dùng notation BPMN.
Security good practice	OWASP ASVS 5.0.0; OWASP API Security Top 10 2023	Dùng để nhận diện câu hỏi bảo mật và verification need; không trình bày là luật Việt Nam hoặc xác nhận hệ thống an toàn.
Pháp lý và domain có điều kiện	Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật Kế toán, Nghị định 123/2020/NĐ-CP, Luật An toàn thực phẩm	Chỉ định tuyến vấn đề tới Legal Owner, Accounting Owner hoặc Domain Owner; mọi yêu cầu diễn giải phải là Verification required trước khi xác minh phù hợp.
Canonical corpus	CANONICAL_BUSINESS_RULES.md, CANONICAL_DATA_DICTIONARY.md, TRACEABILITY_ID_REGISTRY.md	Là nguồn nội bộ cho rule ID, định nghĩa dữ liệu và quy ước ID; chapter không được tạo nguồn chân lý cạnh tranh.

Phụ thuộc traceability	Liên kết cần duy trì	Ví dụ mô phỏng hợp lệ
Nhu cầu đến interface	NEED-* → REQ-FUNC-* → INT-*	NEED-SALES-001 → REQ-FUNC-SALES-012 → INT-SALES-001
Rule đến mapping	BR-* → MAP-* → API field hoặc event field	BR-SALES-004 → MAP-SALES-001 → trường trạng thái đơn hàng trong payload mô phỏng
Dữ liệu đến contract	data element trong CANONICAL_DATA_DICTIONARY.md → schema field	Mã hàng, số lượng, đơn vị tính và tiền tệ phải giữ nghĩa canonical; VND là tiền tệ mô phỏng của corpus.
Requirement đến kiểm thử	REQ-FUNC-* → AC-* → TC-*	REQ-FUNC-SALES-012 → AC-SALES-012-03 → TC-SALES-012-07; test basis kiểm tra response và xử lý lỗi, không chỉ kiểm tra HTTP 200.
Điểm chưa quyết định đến escalation	INT-* hoặc MAP-* → escalation record	Payload có dữ liệu cá nhân hoặc dữ liệu hóa đơn chưa xác minh phải ghi câu hỏi, tác động và owner cần tham gia; không tự đóng quyết định.

Quy tắc ví dụ Nova Foods: một ví dụ tích hợp có thể mô phỏng ERP gửi yêu cầu đồng bộ đơn hàng sang hệ thống ngoài, nhưng phải ghi rõ hệ thống ngoài, URL, mã khách hàng, payload, token và kết quả xử lý đều là dữ liệu tổng hợp. Không gán cho Nova Foods một nhà cung cấp, hợp đồng, endpoint thật, chính sách bảo mật đã xác nhận hoặc nghĩa vụ pháp lý đã được phê duyệt.

CH-13 — Thiết kế quy trình, workflow và cơ chế phê duyệt

Trường metadata	Giá trị kiểm soát
Chapter ID	CH-13
Tệp được kiểm soát	/01-curriculum/13-process-design-workflows-and-approvals.md
Tiêu đề chapter	Process Design, Workflows, and Approvals
Vị trí curriculum	Chapter 13 trong dải 09–17; nối requirement và business rule với mô hình quy trình có trạng thái, vai trò, điều kiện chuyển bước và ngoại lệ
Mục đích	Dạy người học chuyển yêu cầu và rule đã được nhận diện thành quy trình có thể đọc, kiểm tra, truy vết và bàn giao cho các vai trò phân tích, thiết kế hoặc triển khai tiếp theo
Case study	Nova Foods Trading & Manufacturing; dữ liệu tổng hợp phục vụ giáo dục, không đại diện cho quy trình production
Status	IN_REVIEW
Version	v0.9.0
Ngày lập kế hoạch	2026-08-07
Locale và đơn vị	vi-VN; Việt Nam; Asia/Ho_Chi_Minh; VND
Chủ trì nội dung	Principal IT Business Analyst / Technical Curriculum Author
Ranh giới thẩm quyền	Không tự phê duyệt quy trình Nova Foods, không xác nhận phân quyền thực tế, không quyết định chính sách kế toán, pháp lý, an toàn thực phẩm, bảo mật hoặc triển khai production

Phạm vi năng lực và kết quả đầu ra

Người học phải biết phân biệt business process, workflow trạng thái, approval step, business rule, role lane, exception path và system task. Một quy trình đạt yêu cầu phải nêu được điểm bắt đầu, tác nhân hoặc sự kiện kích hoạt, dữ liệu đầu vào, các hoạt động theo thứ tự, điều kiện rẽ nhánh, người hoặc vai trò chịu trách nhiệm, kết quả đầu ra, trạng thái kết thúc và đường xử lý lỗi. Không được dùng sơ đồ để che giấu rule chưa rõ hoặc biến một giả định thành quyết định đã được xác nhận.

Artifact bắt buộc ở planning level	Nội dung tối thiểu	Tiêu chí kiểm tra
Process inventory	Mã quy trình mô phỏng, tên, mục tiêu, trigger, owner dự kiến, phạm vi bắt đầu và kết thúc	Không trộn nhiều mục tiêu nghiệp vụ vào một quy trình; trạng thái owner ghi rõ là đề xuất nếu chưa có xác minh
BPMN process diagram	Pool/lane, start event, task, gateway, sequence flow, end event, message flow khi có tương tác giữa participant	Chỉ gọi là BPMN khi dùng notation BPMN 2.0.2; mọi gateway phải có điều kiện hoặc câu hỏi quyết định tương ứng
Workflow state model	Danh sách trạng thái, sự kiện chuyển trạng thái, điều kiện, vai trò thực hiện, trạng thái lỗi và hành động khôi phục	Mỗi transition có nguồn từ requirement hoặc rule; không tạo trạng thái chỉ vì tên màn hình
Approval matrix	Đối tượng cần duyệt, điều kiện kích hoạt, vai trò đề xuất, vai trò duyệt, quyền từ chối, quyền gửi lại, bằng chứng quyết định	Vai trò mô phỏng phải ghi là Project assumption nếu chưa có source hoặc domain owner xác minh
Exception catalogue	Ngoại lệ dữ liệu thiếu, vượt ngưỡng, từ chối, hết hạn, lỗi tích hợp hoặc không đủ thẩm quyền	Mỗi ngoại lệ có kết quả quan sát được, người xử lý và hướng escalation; không tự đóng vấn đề pháp lý hoặc kế toán
Process-to-requirement trace table	Liên kết process step, requirement, rule, acceptance criterion và downstream test basis	ID phải giữ nguyên, không tạo biến thể tên hoặc liên kết không có bằng chứng

Diagram types và quy tắc lựa chọn

Loại sơ đồ	Dùng cho	Không được diễn giải thành
BPMN 2.0.2 collaboration hoặc process diagram	Luồng công việc, participant, lane, message, event, gateway và kết quả quy trình	Không được gọi PlantUML activity diagram là BPMN
UML activity diagram	Bổ trợ mô tả activity, control flow và object flow khi mục tiêu là ngữ nghĩa UML	Không thay thế BPMN nếu artifact yêu cầu participant, message hoặc event theo BPMN
State machine diagram	Trạng thái của chứng từ hoặc đối tượng workflow và các transition hợp lệ	Không phải approval matrix và không tự chứng minh quyền truy cập
Decision table	Điều kiện phê duyệt, từ chối, chuyển cấp hoặc xử lý ngoại lệ	Không được dùng thay cho toàn bộ process flow khi cần mô tả thứ tự hoạt động

Source families và ranh giới sử dụng

Source family	Phân loại	Cách sử dụng trong CH-13
BABOK Guide, IIBA, Version 3, https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/	Primary professional source; access date 2026-08-07	Dùng cho thuật ngữ, task và tư duy phân tích quy trình; không tự tạo page hoặc clause reference
BPMN 2.0.2, OMG, https://www.omg.org/spec/BPMN/2.0.2/About-BPMN/	Normative notation source; access date 2026-08-07	Dùng để kiểm soát tên và ngữ nghĩa phần tử BPMN
UML 2.5.1, OMG, https://www.omg.org/spec/UML/2.5.1/About-UML/	Normative modeling source; access date 2026-08-07	Dùng cho activity và state modeling theo UML
Quy trình, vai trò và dữ liệu Nova Foods	Synthetic case source; project convention	Chỉ dùng làm dữ liệu mô phỏng; điểm chưa có bằng chứng phải gắn Project assumption
Luật Kế toán, Nghị định 123/2020/NĐ-CP, Luật An toàn thực phẩm và các nguồn pháp lý liên quan	Official legal source family; access date 2026-08-07	Chỉ ghi bối cảnh cần xác minh; yêu cầu hoặc workflow mang ý nghĩa pháp lý, hóa đơn, kế toán, truy xuất, thu hồi phải gắn Verification required nếu chưa được Legal Owner, Accounting Owner hoặc Domain Owner xác nhận

Traceability dependencies

CH-13 nhận đầu vào từ requirement và business-rule artifacts đã được định tuyến trong curriculum, trong đó chuỗi minh họa phải giữ nguyên ID: NEED-SALES-001 → REQ-FUNC-SALES-012 → BR-SALES-004 và AC-SALES-012-03. Traceability table phải chỉ ra requirement nào được thực hiện bởi step nào, rule nào quyết định gateway hoặc approval, acceptance criterion nào kiểm tra được kết quả, và điểm nào còn là Project assumption hoặc Verification required. Chapter này cung cấp process model, workflow state, approval matrix và exception catalogue cho các artifact downstream; nó không tự tạo test evidence, không thay thế data dictionary, không xác nhận API contract và không tuyên bố quy trình đã được người dùng hoặc Nova Foods phê duyệt.

CH-14 — 14-wireframes-screen-behavior-and-ui-rules.md: Wireframe, Hành vi Màn hình và Quy tắc UI

Trường metadata	Giá trị kế hoạch được kiểm soát
Chapter ID	CH-14
Tên tệp được kiểm soát	/01-curriculum/14-wireframes-screen-behavior-and-ui-rules.md
Tiêu đề chapter	Wireframes, Screen Behavior, and UI Rules
Mục đích học tập	Hướng dẫn BA chuyển functional requirement, business rule, data definition và acceptance criterion thành đặc tả giao diện có thể review, build và test; phân biệt wireframe với thiết kế hình ảnh hoàn chỉnh hoặc quyết định kiến trúc frontend.
Status	IN_REVIEW
Version	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ và locale	Asia/Ho_Chi_Minh; vi-VN; bối cảnh Việt Nam; tiền tệ mô phỏng VND
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp
Owner dự kiến	Principal IT Business Analyst / Technical Curriculum Author
Phân loại	Controlled curriculum chapter plan; không phải UI specification được phê duyệt, không phải design system production, không phải xác nhận accessibility hoặc compliance.
Baseline reference	Chưa có baseline reference tại v0.9.0.
Approval reference	Chưa có approval reference tại v0.9.0; nội dung IN_REVIEW không thể hiện chấp thuận của Business Owner, UX/UI Owner, Technical Owner, Security Owner, Legal Owner hoặc người dùng.
Change-history record	v0.9.0 ngày 2026-08-07, IN_REVIEW: khởi tạo kế hoạch chapter CH-14, xác định artifact đầu ra, nguồn, dependency và ranh giới thẩm quyền.

Thành phần kế hoạch	Nội dung bắt buộc trong chapter
Artifact types	Wireframe độ trung thực thấp cho màn hình Nova Foods; screen inventory; screen specification; field catalogue theo màn hình; UI behavior matrix; validation-message catalogue; state-and-permission matrix; navigation map; annotation package liên kết requirement; review checklist cho BA, UX/UI, domain và technical roles.
Diagram types	Wireflow để biểu diễn điều hướng giữa màn hình; screen-state diagram cho trạng thái tải, rỗng, lỗi, không có quyền và thành công; UML state machine chỉ khi cần mô tả trạng thái đối tượng giao diện theo ngữ nghĩa UML; sequence diagram chỉ khi hành vi màn hình phụ thuộc chuỗi tương tác người dùng–UI–API. Không gọi flowchart hoặc PlantUML activity diagram là BPMN.
Ví dụ artifact Nova Foods	Màn hình mô phỏng Tạo đơn bán hàng: vùng header, dòng hàng, chọn khách hàng, chọn kho, số lượng, tổng tiền hiển thị VND, nút Lưu nháp và Gửi duyệt. Mỗi trường phải nêu nguồn dữ liệu, điều kiện hiển thị, trạng thái sửa được, validation, kết quả khi lỗi và ID liên kết; wireframe không tự xác định giá bán, hạn mức tín dụng, tồn khả dụng hoặc quyền phê duyệt khi chưa có rule và owner xác minh.
Quy tắc phân rã	Một annotation phải mô tả một hành vi quan sát được: điều kiện kích hoạt, input, xử lý mong đợi, output hoặc thông báo, và liên kết nguồn. Không dùng nhãn mơ hồ như “xử lý phù hợp”, “giao diện thân thiện” hoặc “kiểm tra đầy đủ”.
Quy tắc dữ liệu	Nhãn trường, định dạng ngày giờ, đơn vị, giá trị rỗng, trường bắt buộc, giá trị mặc định và cách che dữ liệu phải tham chiếu CANONICAL_DATA_DICTIONARY.md khi đã có định nghĩa. Không sao chép hoặc tự đổi nghĩa customer, product, warehouse, batch, expiry date, order hoặc user.
Quy tắc quyền và trạng thái	UI chỉ hiển thị, cho sửa, cho gửi hoặc cho phê duyệt theo requirement, business rule, workflow state và permission source đã được nhận diện. Nếu nguồn quyền chưa xác định, ghi Verification required, nêu tác động và chuyển câu hỏi tới Domain Owner hoặc Technical Owner phù hợp.
Quy tắc accessibility	Chapter sử dụng WCAG 2.2 của W3C làm source chuẩn cho việc định tuyến accessibility review. Mỗi claim về tiêu chí thành công cụ thể phải đối chiếu nguồn chính thức; wireframe đơn thuần không chứng minh sản phẩm đạt accessibility.
Quy tắc dữ liệu cá nhân	Màn hình chứa thông tin định danh, liên hệ hoặc dữ liệu cá nhân mô phỏng phải đánh dấu phạm vi xử lý dữ liệu và nhu cầu xác minh. Mọi yêu cầu suy ra từ Luật Bảo vệ dữ liệu cá nhân hoặc Nghị định 356/2025/NĐ-CP giữ nhãn Verification required cho đến khi Legal Owner xác minh applicability và diễn giải.

Source family	Phân loại nguồn	Mục đích sử dụng và ranh giới
BABOK Guide Version 3	Nguồn chuyên môn BA	Thuật ngữ BA, elicitation, requirements analysis, design definition và traceability; không tạo trích dẫn trang hoặc điều khoản không được kiểm chứng.
ISO/IEC/IEEE 29148:2018	Chuẩn requirements	Định hướng chất lượng, cấu trúc và khả năng kiểm tra của đặc tả; điều khoản chính xác cần licensed-text verification.
WCAG 2.2 Recommendation	Khuyến nghị chuẩn accessibility	Định tuyến tiêu chí accessibility cho screen behavior và interaction; không tuyên bố tuân thủ chỉ dựa trên wireframe.
UML 2.5.1	Chuẩn mô hình hóa	Ngữ nghĩa cho UML state machine hoặc sequence diagram khi được dùng.
CANONICAL_DATA_DICTIONARY.md	Canonical internal source	Nguồn chân lý cho định nghĩa dữ liệu, format, sensitivity và ownership; chapter không thay thế nguồn này.
CANONICAL_BUSINESS_RULES.md	Canonical internal source	Nguồn chân lý cho điều kiện, ngoại lệ và quyết định nghiệp vụ hiển thị trên UI; chapter không biến annotation thành business rule mới.
TRACEABILITY_ID_REGISTRY.md	Canonical internal source	Nguồn cấp và kiểm soát ID; không tự tạo hoặc đổi định danh requirement, rule, acceptance criterion, screen hoặc test artifact.

Dependency traceability	Quan hệ bắt buộc ở mức planning
Upstream requirement	Wireframe annotation liên kết REQ-FUNC-{DOMAIN}-{NNN}; requirement xác định mục tiêu hành vi, không phải wireframe tự suy diễn phạm vi.
Upstream acceptance criterion	Hành vi màn hình liên kết AC-{DOMAIN}-{NNN}-{NN} để tester quan sát được điều kiện, thao tác và kết quả.
Upstream business rule	Validation, visibility, calculation display, warning, trạng thái nút và routing liên kết BR-{DOMAIN}-{NNN}; rule pháp lý, kế toán, hóa đơn, an toàn thực phẩm hoặc privacy chưa xác minh phải giữ Verification required.
Upstream data definition	Mỗi trường quan trọng liên kết data element canonical, gồm kiểu dữ liệu, format, mandatory status và classification khi đã được định nghĩa.
Downstream testing	Screen specification cung cấp test basis cho test condition và test case; expected result phải kiểm tra được cả happy path, validation boundary, error state, permission state và state transition.
Downstream implementation/handoff	Handoff package nhận screen inventory, wireflow, annotation, unresolved-decision log và traceability matrix; UX/UI hoặc Technical Owner vẫn phải xác nhận feasibility trong artifact thẩm quyền của họ.

Ranh giới chapter: CH-14 dạy cách đặc tả giao diện để giảm diễn giải giữa business, UX/UI, development và testing. Chapter không phê duyệt visual design, không quyết định framework, không xác nhận security control, không diễn giải nghĩa vụ pháp lý, và không thay thế usability testing với người dùng. Mọi mâu thuẫn giữa wireframe với requirement, rule, data dictionary hoặc workflow phải được ghi thành câu hỏi có ID traceability và escalation tới owner phù hợp, thay vì sửa ngầm giao diện.

CH-15 — 15-reporting-biometrics-and-kpi-definition.md

Trường metadata	Giá trị kế hoạch được kiểm soát
Chapter ID	CH-15
Tên tệp chuẩn	15-reporting-biometrics-and-kpi-definition.md
Vị trí tệp dự kiến	/01-curriculum/15-reporting-biometrics-and-kpi-definition.md
Tiêu đề chapter	Reporting, Biometrics, and KPI Definition
Mục đích	Hướng dẫn BA xác định nhu cầu báo cáo, phân biệt metric với KPI, đặc tả công thức và ngữ cảnh dữ liệu, đồng thời xử lý dữ liệu sinh trắc học như một miền dữ liệu nhạy cảm cần kiểm soát và xác minh thẩm quyền.
Status	IN_REVIEW
Version	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ và locale	Asia/Ho_Chi_Minh; vi-VN; bối cảnh Việt Nam; tiền tệ mô phỏng VND
Owner	Principal IT Business Analyst / Technical Curriculum Author
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp
Phân loại	Controlled curriculum chapter plan; không phải KPI catalogue đã được Nova Foods phê duyệt, không phải cấu hình BI và không phải tư vấn pháp lý về dữ liệu cá nhân.
Baseline reference	Chưa có baseline reference tại v0.9.0.
Approval reference	Chưa có approval reference tại v0.9.0; IN_REVIEW không xác nhận chấp thuận KPI, quyền truy cập báo cáo hoặc xử lý dữ liệu sinh trắc học.
Change-history record	v0.9.0 — 2026-08-07 — IN_REVIEW — Principal IT Business Analyst / Technical Curriculum Author — khởi tạo kế hoạch chapter về reporting, biometrics và KPI — không tác động baseline vì chưa có baseline.

Hạng mục	Nội dung phải được soạn trong chapter
Kết quả học tập	Learner lập được reporting requirement có audience, business question, phạm vi thời gian, dimension, filter, refresh expectation, định nghĩa metric, nguồn dữ liệu, điều kiện hiển thị và tiêu chí kiểm tra. Learner không được gọi một số liệu là KPI nếu chưa nêu mục tiêu, công thức, ngưỡng hoặc cách diễn giải.
Artifact types bắt buộc	Reporting requirement catalogue; KPI definition card; metric glossary; report inventory; data-lineage matrix; report access matrix; mock dashboard annotation; data-quality rule list; exception and reconciliation log; danh sách Project assumption và Verification required.
Diagram types bắt buộc	Context diagram cho luồng dữ liệu nguồn đến báo cáo; data lineage diagram; KPI decomposition tree; mock dashboard wireframe có chú thích hành vi; access-flow diagram cho người xem, người xuất và người quản trị báo cáo. Các sơ đồ chỉ là mô hình phân tích, không mặc định là thiết kế BI hoặc thiết kế bảo mật đã được phê duyệt.
Ví dụ Nova Foods bắt buộc	KPI mô phỏng KPI-SALES-001 “Doanh thu thuần theo ngày”; metric mô phỏng METRIC-SALES-001 “Giá trị đơn hàng trước chiết khấu”; báo cáo RPT-SALES-001 “Tổng hợp bán hàng ngày”. Công thức, nguồn dữ liệu và ngưỡng minh họa phải mang nhãn Project assumption nếu chưa có Domain Owner và Accounting Owner xác minh.
Boundary sinh trắc học	Chapter phải phân biệt dữ liệu sinh trắc học với dữ liệu chấm công, định danh nhân sự và dữ liệu vận hành thông thường. Không được suy luận rằng Nova Foods thu thập, lưu, đối soát hoặc dùng dữ liệu sinh trắc học. Mọi yêu cầu có liên quan đến mục đích xử lý, quyền truy cập, lưu giữ, chia sẻ, nhà cung cấp hoặc căn cứ pháp lý phải gắn Verification required và chuyển Legal Owner, Security Owner cùng HR/Domain Owner xác minh.
Quy tắc KPI	Mỗi KPI phải có: ID, tên, business objective, owner, công thức, tử số, mẫu số khi áp dụng, đơn vị, chiều thời gian, grain, dimension, filter, nguồn hệ thống, quy tắc làm mới, ngưỡng, ngoại lệ, dữ liệu thiếu, cách làm tròn và liên kết requirement. Không dùng “thời gian thực”, “chính xác”, “tăng trưởng tốt” hoặc “hiệu quả” nếu không có định nghĩa đo lường được.
Tiêu chí chất lượng	Một báo cáo chỉ đủ test basis khi hai người đọc có thể xác định cùng tập bản ghi đầu vào, cùng công thức, cùng timezone, cùng filter mặc định và cùng hành vi khi dữ liệu bị thiếu hoặc bị trễ. Báo cáo tài chính, hóa đơn hoặc số liệu kế toán chỉ được mô tả là ví dụ mô phỏng; cách hạch toán và đối soát cần Accounting Owner xác minh.

Source family	Phân loại nguồn	Mục đích và ranh giới sử dụng
BABOK Guide Version 3	Primary professional reference	Dùng thuật ngữ BA, phân tích requirement, stakeholder và traceability; không tạo trích dẫn trang hoặc điều khoản không được xác minh.
ISO/IEC/IEEE 29148:2018	Primary standards reference	Dùng định hướng chất lượng và cấu trúc requirement; không khẳng định điều khoản chi tiết khi chưa kiểm tra văn bản được cấp phép.
Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15 và Nghị định 356/2025/NĐ-CP	Official legal source	Dùng để định tuyến yêu cầu sinh trắc học và dữ liệu cá nhân đến xác minh pháp lý; không tự diễn giải nghĩa vụ, ngoại lệ hoặc thời hạn.
Luật Kế toán 88/2015/QH13 và Nghị định 123/2020/NĐ-CP	Official legal source	Dùng làm bối cảnh cần xác minh đối với KPI, báo cáo và đối soát liên quan kế toán hoặc hóa đơn; không thay thế quyết định của Accounting Owner hoặc Legal Owner.
CANONICAL_DATA_DICTIONARY.md	Internal canonical source	Nguồn chân lý cho định nghĩa thực thể, trường dữ liệu, grain và phân loại dữ liệu đã được corpus ghi nhận. Chapter không được tự đổi định nghĩa dữ liệu.
CANONICAL_BUSINESS_RULES.md	Internal canonical source	Nguồn tham chiếu cho rule ảnh hưởng công thức, trạng thái đơn hàng, chiết khấu, hoàn trả và ngoại lệ; rule chưa có phải được ghi nhận là khoảng trống hoặc Verification required, không tự tạo rule.
TRACEABILITY_ID_REGISTRY.md	Internal canonical source	Nguồn định dạng và kiểm soát ID; chapter chỉ dùng ID đã đăng ký hoặc ID mô phỏng được đánh dấu theo quy ước registry.

Traceability dependency	Quan hệ bắt buộc ở cấp kế hoạch
Need → reporting requirement	Một business need phải liên kết ít nhất một reporting requirement, ví dụ NEED-SALES-001 → REQ-RPT-SALES-001; requirement nêu người dùng, câu hỏi kinh doanh và quyết định được hỗ trợ.
Reporting requirement → KPI/metric	REQ-RPT-SALES-001 phải liên kết tới KPI hoặc metric dùng để trả lời câu hỏi, ví dụ KPI-SALES-001 và METRIC-SALES-001; không liên kết trực tiếp từ biểu đồ tới kết luận kinh doanh khi thiếu định nghĩa.
KPI/metric → data element and rule	Mỗi thành phần công thức phải truy về data element trong CANONICAL_DATA_DICTIONARY.md và rule liên quan trong CANONICAL_BUSINESS_RULES.md; trường hoặc rule không có nguồn phải mang Verification required.
KPI/report → acceptance criteria and test basis	Mỗi KPI hoặc báo cáo quan trọng phải có acceptance criteria về công thức, filter, quyền xem, dữ liệu thiếu, freshness và kết quả hiển thị; các liên kết test chi tiết được chuyển sang chapter testing theo registry.
Biometrics requirement → authority verification	Bất kỳ REQ-PRIV-* hoặc reporting requirement nào chứa dữ liệu sinh trắc học phải liên kết tới câu hỏi xác minh cho Legal Owner, Security Owner và HR/Domain Owner; không được tạo trạng thái compliant hoặc approved.

CH-16 — 16-solution-options-tradeoffs-and-recommendations.md

Trường metadata	Giá trị kiểm soát
Chapter ID	CH-16
Tên tệp được kiểm soát	16-solution-options-tradeoffs-and-recommendations.md
Đường dẫn dự kiến	/02-handbook/16-solution-options-tradeoffs-and-recommendations.md
Tiêu đề chapter	Solution Options, Trade-offs, and Recommendations
Status	IN_REVIEW
Version	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ và locale	Asia/Ho_Chi_Minh; vi-VN; Việt Nam; VND
Owner	Principal IT Business Analyst / Technical Curriculum Author
Phân loại	Handbook chapter plan; controlled educational artifact
Bối cảnh áp dụng	Nova Foods Trading & Manufacturing; case study mô phỏng giáo dục; chỉ dùng dữ liệu tổng hợp
Mục tiêu học tập	Hướng dẫn learner biến một vấn đề đã có requirement, rule, dữ liệu và ràng buộc thành các phương án có thể so sánh; nêu rõ đánh đổi, bằng chứng, giả định, rủi ro và khuyến nghị có điều kiện.
Ranh giới thẩm quyền	Chapter không phê duyệt phương án, không chọn nhà cung cấp, không xác nhận ngân sách, kiến trúc, tuân thủ pháp lý, hạch toán hoặc khả năng triển khai production cho Nova Foods.
Baseline và approval	Chưa có baseline reference và chưa có approval reference. IN_REVIEW chỉ biểu thị nội dung đang được xem xét.

Artifact bắt buộc trong chapter

Artifact type	Nội dung tối thiểu và quy tắc sử dụng
Option statement	Mỗi phương án phải mô tả vấn đề cần giải quyết, phạm vi bao phủ, thay đổi quy trình hoặc hệ thống, dependency, giới hạn và kết quả dự kiến. Không gọi một phương án là “tốt nhất” nếu chưa có tiêu chí và bằng chứng so sánh.
Decision criteria catalog	Liệt kê tiêu chí theo nhóm: giá trị nghiệp vụ, phù hợp functional requirement, chất lượng phi chức năng, dữ liệu, tích hợp, vận hành, chi phí, thời gian, rủi ro và khả năng thay đổi. Mỗi tiêu chí phải có định nghĩa đo được, owner đánh giá và nguồn bằng chứng.
Trade-off matrix	So sánh tối thiểu ba hướng: cấu hình ERP hiện có, phát triển mở rộng có kiểm soát và thay đổi quy trình để giảm nhu cầu phát triển. Điểm số minh họa là Project assumption cho mục đích học tập, không phải quyết định Nova Foods.
Recommendation brief	Nêu phương án khuyến nghị, lý do, điều kiện tiên quyết, tác động còn lại, quyết định cần xin, câu hỏi mở và đường escalation. Khuyến nghị phải phân biệt fact đã có nguồn, Project assumption và Verification required.
Decision log entry	Ghi vấn đề, phương án đã xem xét, tiêu chí, bằng chứng, rủi ro, owner quyết định dự kiến và artifact bị ảnh hưởng. Không ghi trạng thái approved khi không có bằng chứng phê duyệt trong artifact kiểm soát phù hợp.
Escalation package	Bắt buộc khi phương án tác động dữ liệu cá nhân, hóa đơn, kế toán, an toàn thực phẩm, truy xuất nguồn gốc, bảo mật hoặc cam kết vận hành. Package nêu câu hỏi cần quyết định, tác động trì hoãn và vai trò nhận escalation.

Diagram types dự kiến

Diagram type	Mục đích	Ranh giới notation
Decision tree	Thể hiện điều kiện loại trừ hoặc chọn phương án, ví dụ mức độ phù hợp cấu hình, mức độ thay đổi quy trình và dependency tích hợp.	Sơ đồ quyết định phục vụ phân tích; không trình bày là BPMN.
Option comparison map	Trực quan hóa quan hệ giữa phương án, capability ERP, hệ thống ngoài, dữ liệu chủ và nhóm vận hành Nova Foods.	Có thể dùng sơ đồ khối; không thay thế UML component diagram nếu cần ngữ nghĩa UML chính thức.
Impact heat map	Thể hiện mức tác động tương đối lên Sales, Warehouse, Finance, Quality và IT Operations.	Mức màu hoặc ký hiệu phải có legend; không suy ra mức rủi ro pháp lý từ màu sắc.
Cost–value–risk quadrant	Hỗ trợ thảo luận ưu tiên giữa giá trị giả định, chi phí giả định và rủi ro delivery.	Mọi dữ liệu tiền tệ dùng VND mô phỏng và mang nhãn Project assumption nếu chưa có nguồn chi phí.

Source families, phân loại và giới hạn sử dụng

Source family	Phân loại	Cách dùng trong CH-16	Giới hạn bắt buộc
BABOK Guide Version 3	Primary professional source	Dùng thuật ngữ BA về đánh giá phương án, stakeholder, risk và recommendation.	Không tạo số trang, điều khoản hoặc trích dẫn nguyên văn không được xác minh.
ISO/IEC/IEEE 29148:2018	Primary standards source	Tham chiếu ở mức nguyên tắc về chất lượng requirement và tính truy vết của tiêu chí đánh giá phương án.	Chỉ dùng abstract và bibliographic status công khai; điều khoản chính xác cần licensed-text verification.
OpenAPI Specification OAS 3.1.1; OMG UML 2.5.1; OMG BPMN 2.0.2	Primary technical standards sources	Dùng khi phương án có tác động API, mô hình kỹ thuật hoặc workflow notation.	Không gọi PlantUML activity diagram là BPMN; không suy diễn thiết kế tích hợp hoàn chỉnh từ một option map.
OWASP ASVS 5.0.0; OWASP API Security Top 10 2023	Industry good-practice sources	Định hướng câu hỏi đánh đổi security và API exposure.	Không trình bày là luật Việt Nam hoặc bằng chứng hệ thống tuân thủ security.
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	Official legal sources	Nhận diện các phương án cần Legal Owner, Accounting Owner hoặc Domain Owner xác minh.	Mọi diễn giải applicability, nghĩa vụ, thời hạn, ngoại lệ hoặc thiết kế kiểm soát phải gắn Verification required cho đến khi vai trò có thẩm quyền xác minh.
Nova Foods synthetic case artifacts	Project educational source	Cung cấp vấn đề, giả định, requirement, rule, dữ liệu và ràng buộc để learner lập phương án.	Không chuyển dữ liệu mô phỏng thành fact vận hành, ngân sách, cam kết vendor hoặc quyết định production.

Traceability dependencies ở mức lập kế hoạch

Dependency	CH-16 sử dụng để	Liên kết đầu ra bắt buộc
/01-curriculum/CHAPTER_MANIFEST.md	Xác nhận CH-16, filename, vị trí curriculum và quy tắc quản trị chapter.	Metadata chapter phải khớp manifest; không tự đổi ID hoặc filename.
/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Giữ ranh giới curriculum, capability senior-ready và quy tắc escalation.	Recommendation brief phải phân biệt đề xuất học tập với quyết định delivery.
CANONICAL_BUSINESS_RULES.md	Đánh giá phương án có làm thay đổi, vi phạm hoặc cần xác minh business rule hay không.	Mỗi tác động rule tham chiếu business-rule ID hiện hữu; rule chưa xác minh giữ nhãn Verification required.
CANONICAL_DATA_DICTIONARY.md	Đánh giá tác động lên master data, dữ liệu giao dịch, ownership, chất lượng và dữ liệu nhạy cảm.	Option statement chỉ rõ entity hoặc data element bị tác động bằng ID hiện hữu khi có.
TRACEABILITY_ID_REGISTRY.md	Duy trì định dạng và tính duy nhất của ID cho decision, risk, assumption, requirement hoặc escalation record.	Không tự tạo quy ước ID ngoài registry; liên kết phải truy ngược được về nguồn.
Requirement, acceptance criteria và NFR đã được kiểm soát	So sánh mức độ đáp ứng của từng phương án với outcome và quality constraint.	Trade-off matrix liên kết tiêu chí với requirement/acceptance-criteria/NFR ID hiện hữu, không chép lại hoặc thay thế nguồn gốc.
Integration, process, UI và reporting artifacts có liên quan	Xác định phạm vi tác động liên miền trước khi đưa khuyến nghị.	Recommendation brief nêu artifact bị ảnh hưởng, dependency và owner cần tham gia review.

Quy tắc chất lượng riêng cho chapter: một khuyến nghị chỉ hợp lệ về mặt học tập khi người đọc có thể truy ra vấn đề nguồn, tiêu chí so sánh, bằng chứng hoặc giả định, tác động của phương án không chọn và quyết định còn cần được xác minh. Khi thiếu owner có thẩm quyền hoặc nguồn chính thức, chapter phải dừng ở Verification required, không bù khoảng trống bằng kết luận pháp lý, kế toán, bảo mật hay vận hành.

CH-17 — 17-implementation-readiness-and-handoff-pack.md

Trường metadata	Giá trị kế hoạch được kiểm soát
Chapter ID	CH-17
Tên tệp chuẩn	17-implementation-readiness-and-handoff-pack.md
Vị trí dự kiến	/01-curriculum/17-implementation-readiness-and-handoff-pack.md
Tiêu đề chapter	Implementation Readiness and Handoff Pack
Status	IN_REVIEW
Version	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale và tiền tệ	vi-VN; Việt Nam; VND cho dữ liệu mô phỏng
Owner	Principal IT Business Analyst / Technical Curriculum Author
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp
Mục tiêu học tập	Hướng dẫn learner kiểm tra mức sẵn sàng của một BA delivery pack trước khi bàn giao cho delivery, QA, technical và business stakeholder; phân biệt rõ artifact hoàn chỉnh về cấu trúc với nội dung đã được phê duyệt, tuân thủ pháp luật hoặc sẵn sàng production.
Phạm vi	Tổng hợp và kiểm tra tính liên kết của scope, requirements, business rules, data, integration, workflow, UI, reporting, decision record, risk và traceability; lập handoff register nêu rõ recipient, mục đích sử dụng, trạng thái bằng chứng và điểm cần escalation.
Ngoài phạm vi	Không phê duyệt release, không xác nhận UAT pass, không xác nhận security/compliance, không quyết định kiến trúc, không diễn giải luật, thuế, kế toán hoặc an toàn thực phẩm, và không thay thế kế hoạch triển khai production.
Đầu vào bắt buộc	Các artifact đã lập kế hoạch từ CH-09 đến CH-16; canonical business rules, canonical data dictionary, traceability ID registry, glossary, template manifest và competency coverage matrix theo dependency được quản lý của corpus.
Đầu ra học tập	Một Implementation Readiness Checklist, Handoff Pack Index, Artifact Handoff Register, Open Decision and Escalation Register, Assumption Register và Traceability Coverage Summary cho phạm vi Nova Foods mô phỏng.
Điều kiện hoàn thành chapter	Learner chứng minh được mỗi hạng mục bàn giao có ID, owner nhận, mục đích, nguồn gốc, trạng thái kiểm tra và liên kết tới requirement hoặc quyết định liên quan; các khoảng trống phải được ghi nhận, không được che giấu bằng nhận định sẵn sàng.
Baseline và approval	Chưa có baseline reference; chưa có approval reference. IN_REVIEW chỉ thể hiện nội dung đang được xem xét.
Change-history record	v0.9.0 ngày 2026-08-07, IN_REVIEW: khởi tạo kế hoạch chapter CH-17, metadata, ranh giới handoff và dependency traceability.

Nhóm artifact phải được dạy và lập kế hoạch	Nội dung tối thiểu có thể kiểm tra	Ranh giới kiểm soát
Handoff Pack Index	Danh mục artifact, ID/tên tệp, phiên bản, status, owner, recipient và đường dẫn tham chiếu.	Index là chỉ mục bàn giao, không phải bằng chứng artifact được phê duyệt.
Implementation Readiness Checklist	Kiểm tra scope, requirement, rule, data, API, workflow, UI, reporting, test basis, risk, assumption và escalation.	Mỗi dòng phải có kết quả Đủ bằng chứng, Thiếu bằng chứng hoặc Verification required; không dùng kết luận mơ hồ.
Artifact Handoff Register	Artifact nguồn, artifact nhận, mục đích sử dụng, dependency, người nhận theo vai trò và điều kiện sử dụng.	Recipient được nêu theo vai trò, không suy ra rằng vai trò đã nhận hoặc đồng ý.
Open Decision and Escalation Register	Câu hỏi quyết định, fact đã biết, Project assumption hoặc Verification required, tác động, artifact bị ảnh hưởng và vai trò cần xử lý.	Không tạo quyết định, lời xác nhận hoặc phát biểu thay cho Legal Owner, Accounting Owner, Domain Owner hay Architect.
Traceability Coverage Summary	Liên kết ví dụ NEED-SALES-001 → REQ-FUNC-SALES-012 → AC-SALES-012-03 → TC-SALES-012-07; liên kết rule, data element và interface khi áp dụng.	Liên kết là bằng chứng coverage dự kiến, không phải bằng chứng test đã thực thi hoặc UAT đã đạt.
Release-readiness boundary note	Phân biệt “ready for controlled handoff” với “ready for production”; ghi các điều kiện còn mở.	Không được gắn nhãn production-ready, compliant, approved hoặc baselined khi chưa có artifact kiểm soát tương ứng.

Loại sơ đồ hoặc biểu diễn bắt buộc	Mục đích trong chapter	Chuẩn hoặc cách gọi đúng
Handoff dependency map	Thể hiện artifact nào là đầu vào cho delivery, QA, technical design và stakeholder review.	Có thể dùng sơ đồ phụ thuộc có hướng; không gọi là BPMN nếu không dùng ký pháp BPMN 2.0.2.
Requirement-to-delivery traceability matrix	Hiển thị chuỗi need, requirement, acceptance criteria, rule, data, interface, test basis và handoff item.	Bảng truy vết là artifact chính; mỗi liên kết phải dùng ID đã tồn tại.
Readiness decision flow	Mô tả logic: kiểm tra bằng chứng, phân loại khoảng trống, tạo escalation hoặc cho phép controlled handoff.	Có thể dùng UML activity diagram theo UML 2.5.1 hoặc flowchart được gắn nhãn đúng loại.
Escalation routing diagram	Chỉ ra Legal Owner, Accounting Owner, Domain Owner, Architect và QA/Test lead theo loại câu hỏi.	Sơ đồ vai trò không thay thế phân quyền hoặc approval record.

Họ nguồn	Phân loại nguồn	Cách sử dụng được phép trong CH-17
BABOK Guide v3	Nguồn nghề nghiệp BA chính	Dùng thuật ngữ về lifecycle management, traceability, stakeholder engagement và handoff; không bịa số trang hoặc điều khoản.
ISO/IEC/IEEE 29148:2018	Tiêu chuẩn requirements, chỉ dùng phạm vi công khai đã xác minh	Định hướng đặc tính của requirement information và kiểm soát yêu cầu; chi tiết điều khoản cần kiểm tra văn bản được cấp phép.
ISTQB CTFL Syllabus v4.0.1	Nguồn testing chính	Dùng thuật ngữ test basis, test condition, test case, defect và evidence khi xác định đầu vào bàn giao cho testing.
OMG BPMN 2.0.2 và UML 2.5.1	Nguồn ký pháp chuẩn	Kiểm soát cách gọi sơ đồ workflow, activity và mô hình; không đồng nhất sơ đồ minh họa với ký pháp chuẩn.
Luật và nghị định Việt Nam trong source seed	Nguồn pháp lý chính thức	Chỉ định tuyến vấn đề privacy, kế toán, hóa đơn, thực phẩm và truy xuất nguồn gốc tới Verification required và owner có thẩm quyền.
OWASP ASVS 5.0.0, OWASP API Security Top 10 2023, WCAG 2.2	Industry standard hoặc recommendation	Dùng để lập câu hỏi kiểm tra readiness về security, API và accessibility; không trình bày là luật Việt Nam hoặc bằng chứng compliance.
Canonical artifacts của corpus	Nguồn nội bộ có kiểm soát	Là nguồn chân lý cho ID, business rule, data definition, glossary và traceability; chapter không sao chép rồi tạo nguồn chân lý thứ hai.

Quy tắc traceability và bàn giao: mọi hạng mục CH-17 phải truy ngược về ít nhất một artifact đầu vào có định danh ổn định. Ví dụ, nếu handoff register nêu REQ-FUNC-SALES-012, register phải chỉ ra acceptance criteria liên quan như AC-SALES-012-03, các business rule hoặc data dependency áp dụng nếu đã tồn tại trong canonical artifacts, và test-basis link TC-SALES-012-07 khi đã được lập. Nếu liên kết chưa tồn tại, trạng thái đúng là Thiếu bằng chứng, không phải suy luận rằng requirement đã bao phủ đầy đủ.

Tiêu chí quyết định controlled handoff: chỉ cho phép đánh dấu một gói là “đủ để chuyển review có kiểm soát” khi index đầy đủ, dependency không mâu thuẫn, assumption được tách khỏi fact, và mọi nội dung pháp lý, kế toán, privacy, hóa đơn, an toàn thực phẩm, truy xuất nguồn gốc hoặc security chưa xác minh đều có Verification required cùng vai trò escalation. Kết quả này không cấu thành approval, baseline, xác nhận tuân thủ hay quyết định triển khai cho Nova Foods.

Ma trận artifact, sơ đồ, nguồn và phụ thuộc truy vết cho CH-09 đến CH-17

Ma trận này quy định đầu ra dự kiến ở cấp lập kế hoạch cho các chapter specification-to-design. “Required” nghĩa là chapter phải hướng dẫn người học tạo, đọc, rà soát hoặc liên kết loại artifact đó; không xác nhận artifact Nova Foods đã hoàn chỉnh, được phê duyệt hoặc sẵn sàng production. Mọi dữ liệu là mô phỏng giáo dục; các nội dung pháp lý, kế toán, dữ liệu cá nhân, an toàn thực phẩm và truy xuất nguồn gốc chưa được xác minh phải mang nhãn Verification required hoặc Project assumption.

Chapter / tệp chuẩn	Loại artifact bắt buộc ở mức lập kế hoạch	Loại sơ đồ bắt buộc hoặc được đối chiếu	Họ nguồn được phép sử dụng và phân loại	Phụ thuộc truy vết tối thiểu
CH-09 / 09-functional-specification-writing.md	Functional requirement, acceptance criteria, business-rule reference, exception scenario, requirement review checklist	Use-case diagram UML khi cần thể hiện actor–mục tiêu; không thay thế đặc tả bằng sơ đồ	BABOK Guide (nguồn thực hành BA); ISO/IEC/IEEE 29148 (nguồn chuẩn requirement, xác minh licensed text khi cần chi tiết); project convention; Nova Foods synthetic case	NEED-* → REQ-FUNC-* → AC-*; REQ-FUNC-* tham chiếu BR-*, data element trong CANONICAL_DATA_DICTIONARY.md, và test basis tương lai TC-*
CH-10 / 10-nonfunctional-requirements-and-quality-attributes.md	NFR catalog, quality-attribute scenario, measurable constraint, verification-method matrix, risk and assumption record	Quality attribute scenario map; deployment/context diagram ở mức khái niệm, không phải kiến trúc được chấp thuận	ISO/IEC/IEEE 29148 (nguồn chuẩn); WCAG 2.2 (khuyến nghị accessibility); OWASP ASVS 5.0.0 (industry security verification); project assumption	NEED-* hoặc risk → REQ-NFR-* → verification method; liên kết screen/API/process liên quan và Verification required cho claim security, privacy hoặc compliance chưa có owner xác minh
CH-11 / 11-data-modeling-and-master-data.md	Conceptual/logical data model, master-data catalog, data dictionary entry, data ownership matrix, validation-rule reference	ERD; data lifecycle/state diagram khi trạng thái dữ liệu ảnh hưởng xử lý	UML 2.5.1 (nguồn chuẩn ký pháp khi dùng UML); CANONICAL_DATA_DICTIONARY.md (nguồn chân lý nội bộ); CANONICAL_BUSINESS_RULES.md; legal source family chỉ để định tuyến xác minh	REQ-FUNC-* / BR-* → entity, attribute, code set, owner trong CANONICAL_DATA_DICTIONARY.md; data element → API field, screen field, report metric và test data sau này
CH-12 / 12-api-and-integration-analysis.md	Integration context, interface inventory, API contract outline, field mapping, error-handling matrix, reconciliation question log	System context diagram; sequence diagram UML; interface/data-flow diagram. Không gọi sơ đồ tự do là BPMN hoặc OpenAPI	OpenAPI Specification 3.1.1 (nguồn chuẩn HTTP API description); UML 2.5.1 (nguồn chuẩn sequence semantics); OWASP API Security Top 10 2023 (industry awareness); project convention	REQ-FUNC-* / REQ-NFR-* / BR-* → interface INT-* → endpoint/message → data element trong dictionary → AC và test condition; integration uncertainty phải vào escalation record
CH-13 / 13-process-design-workflows-and-approvals.md	To-be process specification, workflow rule mapping, approval matrix, exception path, role-responsibility matrix	BPMN 2.0.2 collaboration/process diagram; decision table hoặc decision tree cho rule phức tạp	BPMN 2.0.2 (nguồn chuẩn notation); CANONICAL_BUSINESS_RULES.md (nguồn chân lý rule); BABOK Guide (thực hành BA); Nova Foods synthetic case	NEED-* → process activity → REQ-FUNC-* / BR-* → approval role → state transition → AC-*; quyền phê duyệt mô phỏng không được diễn giải là thẩm quyền vận hành thực tế
CH-14 / 14-wireframes-screen-behavior-and-ui-rules.md	Wireframe, screen behavior specification, field-rule matrix, navigation map, UI validation and error-message catalog	Wireflow; state-transition diagram; screen-navigation diagram. Wireframe không phải visual design đã chấp thuận	WCAG 2.2 (khuyến nghị accessibility); UML 2.5.1 (nguồn chuẩn state semantics khi dùng UML); CANONICAL_DATA_DICTIONARY.md; project convention	REQ-FUNC-* / AC-* / BR-* → screen SCR-* → field/data element → validation behavior → test condition; accessibility claim chi tiết phải đối chiếu đúng nguồn trước khi khẳng định
CH-15 / 15-reporting-biometrics-and-kpi-definition.md	Report specification, KPI definition card, metric formula, dimensional breakdown, data-lineage matrix, refresh and access assumption	KPI tree; report mockup; data-lineage diagram; dashboard navigation map	CANONICAL_DATA_DICTIONARY.md và CANONICAL_BUSINESS_RULES.md (nguồn chân lý nội bộ); Luật Kế toán và Nghị định 123/2020/NĐ-CP (nguồn pháp lý chính thức, chỉ định tuyến xác minh); project assumption	Business question / NEED-* → KPI-* hoặc RPT-* → formula → source entity/attribute → BR-* → acceptance criterion; chỉ số có yếu tố tài chính, hóa đơn hoặc dữ liệu cá nhân cần Verification required và owner phù hợp
CH-16 / 16-solution-options-tradeoffs-and-recommendations.md	Option catalog, decision criteria, weighted trade-off matrix, recommendation record, assumption/risk/dependency register	Option context diagram; decision tree; impact map; không dùng sơ đồ để che giấu tiêu chí hoặc trọng số	BABOK Guide (thực hành đánh giá giải pháp); ISO/IEC/IEEE 29148 (nguồn chuẩn liên quan requirement); OWASP ASVS 5.0.0 và WCAG 2.2 khi tiêu chí có security/accessibility; project convention	Problem / NEED-* + REQ-* + constraints → option OPT-* → criterion/evidence → recommendation REC-*; mọi criterion thiếu bằng chứng được liên kết risk, assumption hoặc escalation, không được biến thành quyết định đã phê duyệt
CH-17 / 17-implementation-readiness-and-handoff-pack.md	Handoff checklist, requirement package index, traceability status, open-item register, readiness assessment, BA-to-delivery handoff summary	Artifact dependency map; release/readiness flow; traceability coverage diagram	ISTQB CTFL v4.0.1 (nguồn thuật ngữ testing); BABOK Guide (thực hành BA); TRACEABILITY_ID_REGISTRY.md; source family của từng artifact được kế thừa, không tái phân loại	NEED-* → REQ-* → BR-* / data / process / UI / interface / report → AC-* → test basis; open item → owner → affected IDs → escalation. Handoff chỉ ghi mức sẵn sàng được đánh giá, không tuyên bố approval, compliance hoặc production readiness

Quy tắc liên kết chung

1. Định danh requirement, rule, data, interface, screen, report, KPI, option và test phải dùng registry tương ứng trong TRACEABILITY_ID_REGISTRY.md; chapter không tự đặt lại nghĩa của ID đã tồn tại.
2. CANONICAL_BUSINESS_RULES.md là nguồn chân lý cho BR-*; CANONICAL_DATA_DICTIONARY.md là nguồn chân lý cho định nghĩa dữ liệu. Chapter chỉ tham chiếu và giải thích cách dùng, không tạo bản sao cạnh tranh.
3. Sơ đồ BPMN chỉ được gắn nhãn BPMN khi tuân theo BPMN 2.0.2; sơ đồ UML chỉ được gắn nhãn UML khi dùng đúng ngữ nghĩa UML 2.5.1. Sơ đồ minh họa đơn giản phải được gọi đúng loại, như flowchart hoặc wireflow.
4. Nguồn luật Việt Nam chỉ là nguồn chính thức để xác minh applicability và diễn giải thuộc thẩm quyền Legal Owner, Accounting Owner hoặc Domain Owner phù hợp. Không một chapter nào trong dải này được suy ra nghĩa vụ pháp lý, công thức kế toán, rule hóa đơn hay yêu cầu truy xuất nguồn gốc từ ví dụ Nova Foods tổng hợp.

Chapter Catalog — 18 to 25

CH-18 — Testing Fundamentals for BA

Trường metadata	Giá trị kế hoạch được kiểm soát
Chapter ID	CH-18
Tên tệp được kiểm soát	18-testing-fundamentals-for-ba.md
Đường dẫn dự kiến	/02-handbook/18-testing-fundamentals-for-ba.md
Tiêu đề chapter	Testing Fundamentals for BA
Status	IN_REVIEW
Version	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ và locale	Asia/Ho_Chi_Minh; vi-VN; Việt Nam; dữ liệu mô phỏng sử dụng VND
Owner	Principal IT Business Analyst / Technical Curriculum Author
Phân loại	Planned handbook chapter; controlled educational artifact; Nova Foods synthetic-data case study
Mục tiêu học tập	Giải thích từ nguyên lý đầu tiên vì sao kiểm thử cần một test basis rõ ràng; chuyển business need, requirement, business rule và acceptance criterion thành test condition có thể quan sát; phân biệt test case, test data, expected result, actual result, defect, retest và acceptance evidence.
Vị trí năng lực	Mở đầu mini-book kiểm thử dành cho BA. Learner đã có khả năng đọc NEED-*, REQ-*, BR-* và AC-*; chapter tạo nền để thiết kế kỹ thuật test, UAT, quản lý defect, regression và delivery readiness ở các chapter kế tiếp.
Đầu vào bắt buộc	Requirement package, acceptance criteria, business-rule reference, process/data/interface context, traceability ID registry và open-item status. Khi nguồn rule hoặc dữ liệu chưa được xác minh, đầu vào phải giữ nhãn Project assumption hoặc Verification required.
Đầu ra dự kiến	Test-basis map; test-condition register; cấu trúc test case tối thiểu; defect lifecycle map; retest/acceptance evidence checklist; ví dụ traceability Nova Foods có định danh tham chiếu.
Nguồn chính	ISTQB CTFL Syllabus v4.0.1 — primary testing syllabus cho thuật ngữ kiểm thử và tư duy test basis; BABOK Guide Version 3 — nguồn cho BA terminology và thực hành liên kết requirement.
Ranh giới sử dụng nguồn	Không tạo số trang, điều khoản hoặc trích dẫn không được xác minh. ISTQB CTFL Syllabus v4.0.1 hỗ trợ thuật ngữ testing, không thay thế quyết định release của Nova Foods. BABOK Guide không phải nguồn để xác nhận yêu cầu pháp lý, kế toán, privacy hoặc vận hành production.
Liên kết case study	Nova Foods Trading & Manufacturing là bối cảnh đào tạo tổng hợp. Ví dụ có thể dùng NEED-SALES-001 → REQ-FUNC-SALES-012 → AC-SALES-012-03 → TC-SALES-012-07; các ID chỉ là traceability mẫu và không phải requirement được phê duyệt cho hệ thống thực tế.
Phụ thuộc nguồn chân lý	TRACEABILITY_ID_REGISTRY.md quản lý cú pháp và ý nghĩa ID; CANONICAL_BUSINESS_RULES.md là nguồn chân lý cho BR-*; CANONICAL_DATA_DICTIONARY.md là nguồn chân lý cho định nghĩa dữ liệu. Chapter không sao chép hoặc tái định nghĩa các nguồn này.
Điều kiện đánh giá learner	Learner phải chứng minh được mỗi test condition có test basis xác định, expected result quan sát được và liên kết ngược về ID nguồn. Không đạt nếu chỉ viết bước thao tác mà thiếu kết quả mong đợi, không nêu dữ liệu kiểm thử, hoặc ghi defect khi chưa chứng minh actual result khác expected result.
Giới hạn chapter	Không thay Legal Owner, Accounting Owner, Security Owner hoặc Domain Owner xác nhận nghĩa vụ hay rule. Không xác nhận release, UAT sign-off, baseline, compliance hoặc production readiness. Không dạy kỹ thuật black-box chi tiết, lập kế hoạch UAT, quyết định change control hoặc đánh giá capstone trong chapter này.
Escalation boundary	Khi test basis chứa rule về dữ liệu cá nhân, thuế, kế toán, hóa đơn, an toàn thực phẩm, truy xuất nguồn gốc hoặc security nhưng chưa có nguồn và owner có thẩm quyền xác minh, BA phải ghi Verification required, nêu ID bị ảnh hưởng và chuyển câu hỏi cho owner phù hợp; không tự suy diễn expected result mang tính pháp lý.
Change history	v0.9.0 ngày 2026-08-07, IN_REVIEW: khởi tạo metadata kế hoạch cho CH-18, phạm vi foundation testing, dependency nguồn và boundary thẩm quyền. Chưa có baseline reference hoặc approval reference.

Yêu cầu liên kết với mô-đun kiểm thử chuyên sâu: CH-18 phải lập kế hoạch ở cấp chapter sao cho thuật ngữ, cấu trúc test basis và trạng thái defect nhất quán với mô-đun kiểm thử chuyên sâu. Chapter này giải thích nguyên nhân của chuỗi kiểm chứng, còn mô-đun chuyên sâu sẽ phát triển kỹ thuật thiết kế và vận hành kiểm thử mà không thay đổi nguồn chân lý của requirement hay business rule.

Mắt xích kiểm thử	Nội dung tối thiểu phải dạy	Bằng chứng traceability
Business need	Nhu cầu giải thích giá trị cần đạt, chưa đủ để chạy test trực tiếp.	NEED-SALES-001
Requirement và rule	Requirement xác định hành vi; rule xác định điều kiện hoặc giới hạn áp dụng.	REQ-FUNC-SALES-012; tham chiếu BR-* khi có
Acceptance criterion	Điều kiện quan sát được để biết requirement đáp ứng hay không.	AC-SALES-012-03
Test case	Tập bước, dữ liệu, precondition và expected result kiểm tra một test condition.	TC-SALES-012-07
Defect	Bản ghi chỉ được tạo khi actual result có bằng chứng khác expected result; phải liên kết test case và ID nguồn bị ảnh hưởng.	DEF-* theo registry áp dụng
Retest	Thực thi lại test case hoặc test condition liên quan sau khi có thay đổi được cung cấp để kiểm tra defect đã được xử lý theo expected result.	Liên kết DEF-* → TC-* → actual retest evidence
Acceptance	Bằng chứng kết quả được đánh giá theo tiêu chí đã xác định; không tự đồng nghĩa approval, baseline hay cho phép production release.	Liên kết acceptance evidence với AC-*, test case và trạng thái open item

Quy tắc nội dung bắt buộc: Ví dụ Nova Foods phải chỉ rõ khác biệt giữa “hệ thống cho phép tạo đơn hàng” và expected result kiểm thử. Chẳng hạn, TC-SALES-012-07 chỉ kiểm tra được khi nêu precondition, dữ liệu đơn hàng tổng hợp, thao tác, expected result theo AC-SALES-012-03 và bằng chứng actual result. Nếu điều kiện về giá, tồn kho, hóa đơn hoặc dữ liệu khách hàng chưa được xác minh, test case phải ghi rõ Project assumption hoặc Verification required; không được biến giả định thành business rule hoặc kết luận defect do hệ thống vi phạm nghĩa vụ pháp lý.

CH-19 — 19-black-box-testing-techniques-for-ba.md

Trường metadata	Giá trị kế hoạch được kiểm soát
Chapter ID	CH-19
Tên tệp được kiểm soát	19-black-box-testing-techniques-for-ba.md
Đường dẫn dự kiến	/02-handbook/19-black-box-testing-techniques-for-ba.md
Tiêu đề chapter	Black-Box Testing Techniques for Business Analysts
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale và tiền tệ mô phỏng	vi-VN; Việt Nam; VND
Owner	Principal IT Business Analyst / Technical Curriculum Author
Phân loại	Planned handbook chapter; controlled educational content
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp
Baseline reference	Chưa có baseline reference tại v0.9.0.
Approval reference	Chưa có approval được ghi nhận; IN_REVIEW không biểu thị phê duyệt, sẵn sàng production hoặc xác nhận UAT.
Change-history record	v0.9.0, 2026-08-07, IN_REVIEW, Principal IT Business Analyst / Technical Curriculum Author: lập kế hoạch metadata cho chapter về kỹ thuật kiểm thử hộp đen dành cho BA; chưa tạo baseline.

Thành phần kế hoạch	Nội dung phải có trong chapter
Mục tiêu học tập	Giải thích từ test basis đến test condition và test case; chọn kỹ thuật hộp đen phù hợp thay vì chỉ tạo happy-path test; diễn đạt expected result có thể quan sát, đối chiếu và lưu bằng chứng.
Phạm vi kỹ thuật	Equivalence partitioning, boundary value analysis, decision table testing, state transition testing và use-case testing theo thuật ngữ của ISTQB CTFL Syllabus v4.0.1. Chapter phải phân biệt kỹ thuật kiểm thử với business rule, requirement và quyết định thiết kế.
Đầu vào bắt buộc	Requirement, acceptance criteria, business rule, data definition, process/model liên quan và traceability ID đã tồn tại. Nếu đầu vào thiếu hoặc mâu thuẫn, BA ghi câu hỏi làm rõ hoặc escalation, không tự tạo rule để hoàn tất test case.
Đầu ra dự kiến	Test condition, test case, bộ dữ liệu kiểm thử mô phỏng, expected result, liên kết traceability và danh sách điểm cần xác minh. Test case không là bằng chứng rằng chức năng đã được kiểm thử thành công.
Ví dụ Nova Foods	Dùng chuỗi đã định danh NEED-SALES-001 → REQ-FUNC-SALES-012 → AC-SALES-012-03 → TC-SALES-012-07 để minh họa chuyển một nhu cầu thành điều kiện kiểm thử. Giá trị đơn hàng, ngưỡng chiết khấu, trạng thái tồn kho và kết quả xử lý chỉ là dữ liệu mô phỏng khi chưa có canonical rule hoặc data definition xác nhận.
Tiêu chí hoàn thành học tập	Learner phải nêu được partition hợp lệ/không hợp lệ, biên cần kiểm tra, tổ hợp quyết định hoặc trạng thái chuyển tiếp; mỗi expected result phải truy được về test basis và không đưa ra diễn giải pháp lý, kế toán, thuế, privacy hoặc an toàn thực phẩm chưa được xác minh.

Quy tắc traceability và lập kế hoạch kiểm thử
Chapter phải được lập kế hoạch đồng bộ ở cấp chapter với deep testing module: thuật ngữ, cấu trúc test artifact, mức độ chi tiết và điểm bàn giao không được mâu thuẫn với module kiểm thử chuyên sâu. CH-19 chỉ lập nền tảng kỹ thuật hộp đen cho BA; không thay thế kế hoạch UAT, quản lý defect, regression hay quyết định acceptance thuộc chapter/module được phân công riêng.
Chuỗi kiểm soát bắt buộc là business need → requirement/acceptance criterion → test condition → test case → execution evidence → defect khi actual result khác expected result → retest → acceptance decision. Không được bỏ qua liên kết nguồn, không suy ra defect chỉ vì test case tồn tại, và không gọi retest là acceptance.
Với TC-SALES-012-07, learner phải chỉ ra test basis cụ thể là REQ-FUNC-SALES-012 và AC-SALES-012-03; nếu expected result phụ thuộc BR-SALES-004 hoặc định nghĩa dữ liệu canonical, chapter phải dẫn chiếu ID đó thay vì chép lại hoặc sửa nghĩa rule.
Nội dung liên quan hóa đơn, hạch toán, dữ liệu cá nhân, truy xuất lô thực phẩm, hạn dùng hoặc nghĩa vụ pháp lý phải mang Verification required khi chưa được Legal Owner, Accounting Owner hoặc Domain Owner xác minh. Không dùng kỹ thuật kiểm thử để suy diễn nghĩa vụ tuân thủ.

| Nguồn và ranh giới sử dụng | |---|---| | Primary source: ISTQB CTFL Syllabus v4.0.1, ISTQB, URL chính thức đã xác minh ngày 2026-08-07: https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf. Dùng cho thuật ngữ và kỹ thuật kiểm thử hộp đen; không gán nội dung chapter là trích dẫn nguyên văn hoặc điều khoản của syllabus khi chưa đối chiếu. | | Nguồn hỗ trợ BA: BABOK Guide Version 3, IIBA, URL chính thức đã xác minh ngày 2026-08-07: https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/. Dùng cho bối cảnh công việc BA, traceability và thuật ngữ; không tạo số trang hoặc điều khoản không có xác minh. | | Nguồn nội bộ corpus: TRACEABILITY_ID_REGISTRY.md, CANONICAL_BUSINESS_RULES.md, CANONICAL_DATA_DICTIONARY.md và artifact requirement/acceptance criteria có ID đã tồn tại. Các nguồn này là ranh giới định danh và nội dung canonical trong corpus, không phải bằng chứng phê duyệt Nova Foods. |

Boundary thẩm quyền
Owner chapter duy trì nội dung học tập, cấu trúc traceability và lịch sử thay đổi; không có quyền xác nhận test passed, chấp thuận UAT, baseline requirement, xác nhận defect closure, phê duyệt triển khai hoặc diễn giải pháp lý/kế toán.
Khi test basis mâu thuẫn, expected result tác động tiền, tồn kho, hóa đơn, dữ liệu cá nhân hoặc truy xuất nguồn gốc, chapter phải yêu cầu escalation package gồm ID bị ảnh hưởng, fact đã biết, Project assumption hoặc Verification required, câu hỏi quyết định, tác động và vai trò owner cần tham gia.

CH-20 — 20-uat-planning-defects-and-regression.md: Kế hoạch UAT, quản lý defect và regression

Trường metadata	Giá trị kế hoạch được kiểm soát
Chapter ID	CH-20
Tên tệp được kiểm soát	20-uat-planning-defects-and-regression.md
Đường dẫn chapter dự kiến	/02-handbook/20-uat-planning-defects-and-regression.md
Tiêu đề chapter	UAT Planning, Defects and Regression
Status	IN_REVIEW
Version	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ quản trị	Asia/Ho_Chi_Minh
Locale và tiền tệ mô phỏng	vi-VN; Việt Nam; VND
Owner	Principal IT Business Analyst / Technical Curriculum Author
Phân loại	Controlled chapter-planning record; nội dung handbook dự kiến, chưa phải test plan hoặc quyết định triển khai Nova Foods
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp
Vị trí trong hành trình học	Chapter delivery-readiness, sau các chapter về testing fundamentals và black-box techniques; chuẩn bị learner tạo UAT evidence, defect record và quyết định regression có truy vết
Mục tiêu học tập	Learner lập được UAT plan phạm vi hẹp, xác định vai trò và entry/exit criteria, ghi defect có bằng chứng tái lập, đánh giá tác động regression và duy trì chuỗi truy vết từ nhu cầu đến acceptance.
Đầu vào bắt buộc	Business need, requirement, business rule, acceptance criteria, process/data context, test condition và test case đã có định danh ổn định.
Đầu ra chính	UAT plan, UAT scenario, execution log, defect record, defect triage view, regression selection record, retest evidence và acceptance-status summary.
Dependency định danh	NEED-SALES-001, REQ-FUNC-SALES-012, AC-SALES-012-03, TC-SALES-012-07; các ID chỉ là mẫu traceability mô phỏng, không phải yêu cầu đã được Nova Foods phê duyệt.
Nguồn chính	ISTQB CTFL Syllabus v4.0.1 — primary testing syllabus cho thuật ngữ testing, test basis, defect, retest và regression; BABOK Guide Version 3 — nguồn thuật ngữ và thực hành BA.
Ranh giới nguồn	Không suy diễn điều khoản, trang hoặc quy định chi tiết ngoài nguồn đã xác minh. Nội dung thuế, kế toán, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc và bảo mật xuất hiện trong UAT phải được gắn Verification required hoặc Project assumption cho đến khi owner có thẩm quyền xác minh.
Baseline reference	Chưa có baseline reference tại v0.9.0.
Approval reference	Chưa có approval được ghi nhận; IN_REVIEW không xác nhận UAT readiness, acceptance, production readiness hoặc chấp thuận của Nova Foods.

Phạm vi nội dung dự kiến. Chapter phải phân biệt UAT là hoạt động xác nhận mức phù hợp với nhu cầu nghiệp vụ và tiêu chí chấp nhận đã được làm test basis, không phải cơ chế để người dùng tự tạo requirement mới, thay đổi rule không kiểm soát hoặc xác nhận diễn giải pháp lý. UAT plan tối thiểu phải nêu phạm vi requirement, môi trường mô phỏng, dữ liệu tổng hợp, vai trò thực hiện, lịch chạy, entry criteria, exit criteria, cách ghi bằng chứng, luồng triage defect và điều kiện escalation. Chapter phải hướng dẫn phân biệt defect với change request: hành vi không khớp requirement/acceptance criterion đã có là ứng viên defect; nhu cầu thay đổi phạm vi hoặc tiêu chí đã có phải được ghi nhận để đánh giá theo quản trị thay đổi, không được tự sửa test expected result.

Chuỗi traceability bắt buộc	Bằng chứng cần liên kết	Quy tắc kiểm soát
Business need → requirement	NEED-SALES-001 → REQ-FUNC-SALES-012	Test không được tự suy ra business need mới.
Requirement → acceptance criterion → test case	REQ-FUNC-SALES-012 → AC-SALES-012-03 → TC-SALES-012-07	Expected result phải kiểm tra được và có nguồn từ acceptance criterion hoặc rule đã định danh.
Test case → defect	TC-SALES-012-07 → DEF-SALES-001 khi actual result không khớp expected result	Defect phải có precondition, bước tái lập, actual result, expected result, evidence reference và mức độ tác động được ghi nhận.
Defect → retest → regression → acceptance	DEF-SALES-001 → RT-SALES-001 → regression selection → acceptance-status summary	Retest xác nhận sửa lỗi cụ thể; regression kiểm tra tác động ngoài lỗi đã sửa; không được coi defect “đóng” là bằng chứng acceptance tự động.

Căn chỉnh với deep testing module. Metadata chapter phải quy định rõ đây là chapter UAT và delivery-readiness, được lập kế hoạch đồng bộ với deep testing module thay vì lặp lại hoặc thay thế module đó. Chapter này áp dụng thuật ngữ, kỹ thuật thiết kế test và cách xác định test condition từ deep testing module vào bối cảnh UAT; trọng tâm là điều phối business representative, bằng chứng chấp nhận, triage, retest và regression. Khi test case thiếu test basis, dữ liệu, expected result hoặc owner xác nhận rule, learner phải ghi gap và escalation thay vì tự hoàn thiện bằng giả định.

Quyết định hoặc sự kiện	Owner/đích escalation dự kiến	Boundary bắt buộc
Rule về giá, tồn kho, lô hàng, hạn dùng hoặc quy trình giao nhận chưa rõ	Domain Owner	Giữ Project assumption hoặc Verification required; không tự xác nhận rule vận hành.
Hành vi liên quan hóa đơn, hạch toán, thuế hoặc chứng từ	Accounting Owner và/hoặc Legal Owner	Không kết luận tính hợp lệ kế toán hoặc pháp lý từ kết quả UAT.
Dữ liệu người dùng, phân quyền hoặc dấu hiệu security concern	Security Owner, Privacy Owner hoặc Legal Owner phù hợp	Không dùng dữ liệu cá nhân thật; dùng dữ liệu tổng hợp và ghi rõ giới hạn xác minh.
Defect làm thay đổi phạm vi, acceptance criterion hoặc business rule	Change-control path; tham chiếu CR-{DOMAIN}-{NNN} khi baseline được thiết lập	Không đổi requirement hoặc expected result để làm test pass.

Change history hiện hành: v0.9.0, 2026-08-07, IN_REVIEW, Principal IT Business Analyst / Technical Curriculum Author — khởi tạo metadata kế hoạch cho CH-20, xác định UAT, defect, retest và regression traceability; chưa tạo baseline, approval hoặc xác nhận triển khai.

CH-21 — 21-change-control-traceability-and-baselining.md: Quản lý thay đổi, truy vết và thiết lập baseline

Trường metadata	Giá trị kiểm soát
Chapter ID	CH-21
Tên tệp được kiểm soát	21-change-control-traceability-and-baselining.md
Vị trí dự kiến	/02-handbook/21-change-control-traceability-and-baselining.md
Tiêu đề chapter	Change Control, Traceability, and Baselining
Status	IN_REVIEW
Version	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale và tiền tệ mô phỏng	vi-VN, Việt Nam, VND
Owner	Principal IT Business Analyst / Technical Curriculum Author
Phân loại	Planned handbook chapter; controlled educational artifact
Case study	Nova Foods Trading & Manufacturing; mô phỏng giáo dục, dữ liệu tổng hợp
Mục đích	Dạy learner kiểm soát thay đổi đối với requirement, business rule, data definition, acceptance criterion và test basis; duy trì truy vết hai chiều; phân biệt bản đang review với baseline được thiết lập hợp lệ.
Đầu vào bắt buộc	Need, requirement, acceptance criterion, business rule, data definition, process/model và test artifact đã có ID chuẩn trong corpus.
Đầu ra dự kiến	Change Request, impact assessment, traceability matrix, baseline register, change decision record và escalation package có liên kết ID.
Điều kiện hoàn thành	Learner lập được chuỗi tác động, xác định owner quyết định phù hợp, giữ nguyên nhãn Project assumption hoặc Verification required khi bằng chứng chưa đủ, và không gọi artifact IN_REVIEW là baseline hoặc approval.

Phạm vi nội dung dự kiến	Quy tắc triển khai trong chapter
Change control từ nguyên lý đầu tiên	Thay đổi là chênh lệch có chủ đích giữa nội dung đang được kiểm soát và nội dung đề xuất. Chapter phải phân biệt rõ: yêu cầu thay đổi, phân tích tác động, quyết định có thẩm quyền, cập nhật artifact và xác nhận liên kết sau thay đổi.
Traceability hai chiều	Mỗi liên kết phải đi xuôi từ business need đến delivery evidence và đi ngược từ một artifact về nguồn thay đổi. Ví dụ mô phỏng: NEED-SALES-001 → REQ-FUNC-SALES-012 → AC-SALES-012-03 → TC-SALES-012-07. Khi thay đổi REQ-FUNC-SALES-012, impact assessment phải kiểm tra toàn bộ ID liên quan thay vì chỉ sửa một câu requirement.
Baselining	Baseline là tập artifact được xác định rõ phiên bản, phạm vi và thời điểm, sau một quyết định được ghi nhận bởi vai trò có thẩm quyền trong artifact kiểm soát phù hợp. IN_REVIEW tại v0.9.0 ngày 2026-08-07 không phải baseline, không phải approval và không là chỉ thị triển khai.
Phân tích tác động	Phân tích tối thiểu gồm tác động business, process, data, rule, interface, test, training, operations, risk, owner quyết định và các điểm cần xác minh. Không được suy luận chi phí, lịch triển khai hoặc mức ưu tiên khi chưa có dữ liệu được ghi nhận.
Escalation boundary	Nội dung về dữ liệu cá nhân, kế toán, thuế, hóa đơn, an toàn thực phẩm, truy xuất nguồn gốc hoặc bảo mật phải được chuyển đúng owner khi chưa có xác minh. Chapter chỉ hướng dẫn đóng gói câu hỏi và bằng chứng; không diễn giải thay Legal Owner, Accounting Owner, Domain Owner hoặc Security Owner.

Bộ metadata của change record mô phỏng	Giá trị hoặc quy tắc bắt buộc
Change Request ID	Theo quy ước CR-{DOMAIN}-{NNN}; ví dụ CR-SALES-001. Không tạo ID trùng với registry kiểm soát.
Trạng thái yêu cầu thay đổi	IN_REVIEW tại thời điểm lập kế hoạch; không tự gán APPROVED, BASELINED hoặc IMPLEMENTED.
Nguồn khởi phát	Ghi source classification: fact đã xác minh, Project assumption, hoặc Verification required.
Artifact bị ảnh hưởng	Ghi filename chuẩn và ID cụ thể, ví dụ REQ-FUNC-SALES-012, AC-SALES-012-03, TC-SALES-012-07.
Mô tả thay đổi	Nêu trạng thái trước, thay đổi đề xuất, lý do business và hành vi quan sát được sau thay đổi.
Quyết định cần có	Nêu câu hỏi quyết định, vai trò có thẩm quyền cần tham gia và hậu quả nếu chưa quyết định.
Evidence và liên kết	Liên kết đến requirement, rule, data definition, test case, defect hoặc operational artifact liên quan; không dùng nhận định không truy ngược được làm bằng chứng.
Baseline impact	Ghi rõ “chưa có baseline reference” nếu chưa được thiết lập; không tạo baseline reference giả định.

Nguồn và ranh giới sử dụng: Chapter dự kiến dùng BABOK Guide Version 3 cho thuật ngữ và thực hành BA ở mức tổng quát; dùng ISO/IEC/IEEE 29148:2018 theo abstract và thông tin thư mục chính thức cho bối cảnh requirements engineering. Không được tạo số trang, điều khoản hoặc trích dẫn chi tiết từ nội dung có giấy phép mà chưa xác minh. Các quy tắc Nova Foods về giá bán, tồn kho, hóa đơn, dữ liệu cá nhân, lô hàng hoặc truy xuất nguồn gốc chỉ là dữ liệu mô phỏng; nếu được nêu như nghĩa vụ pháp lý hoặc vận hành thực tế, phải gắn Verification required và định tuyến escalation phù hợp.

Ranh giới governance: Chapter không được sửa canonical ID, filename, rule catalog, data dictionary hoặc registry truy vết bằng nội dung diễn giải. Mọi ví dụ phải bảo toàn định danh hiện có, ghi rõ artifact nguồn và không tuyên bố bất kỳ thay đổi nào đã được người dùng, Nova Foods hoặc owner chuyên môn phê duyệt.

CH-22 — 22-operations-support-and-post-go-live-analysis.md

Trường metadata	Giá trị được lập kế hoạch
Chapter ID	CH-22
Tên tệp được kiểm soát	/02-handbook/22-operations-support-and-post-go-live-analysis.md
Tiêu đề chapter	Operations Support and Post-Go-Live Analysis
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ và locale	Asia/Ho_Chi_Minh; vi-VN; bối cảnh Việt Nam; tiền tệ mô phỏng VND
Owner	Principal IT Business Analyst / Technical Curriculum Author
Phân loại	Handbook chapter plan; controlled educational artifact
Case study	Nova Foods Trading & Manufacturing; dữ liệu tổng hợp phục vụ đào tạo
Mục đích	Hướng dẫn BA chuyển giao từ delivery sang vận hành có kiểm soát: tiếp nhận phản hồi sau go-live, phân loại sự cố và yêu cầu thay đổi, phân tích tác động, duy trì traceability, hỗ trợ quyết định escalation và ghi nhận bài học sau triển khai.
Baseline và approval	Chưa có baseline reference và chưa có approval reference. IN_REVIEW không xác nhận vận hành production, tuân thủ pháp lý, hay chấp thuận của Nova Foods.

Thành phần nội dung bắt buộc	Quy tắc lập kế hoạch và đầu ra dự kiến
Mục tiêu học tập	Learner phân biệt được incident, service request, defect, enhancement và change request; xác định được bằng chứng cần thu thập trước khi kết luận nguyên nhân; lập được post-go-live review có truy vết và ranh giới thẩm quyền rõ ràng.
Đầu vào bắt buộc	Requirement, acceptance criteria, business rule, data definition, test evidence, UAT evidence, release/handoff summary và risk/change record đã tồn tại trong corpus. Chapter không tự tạo lại nguồn chân lý cho các nội dung này.
Artifact thực hành	Incident analysis log, operational issue triage record, post-go-live observation register, impact-assessment note, escalation package và lessons-learned summary cho Nova Foods.
Chuỗi truy vết tối thiểu	Một vấn đề vận hành phải liên kết đến bằng chứng quan sát được, ví dụ REQ-FUNC-SALES-012 → AC-SALES-012-03 → TC-SALES-012-07 → record sự cố hoặc phát hiện sau go-live. Nếu chưa xác định được liên kết, record phải nêu rõ “chưa xác định test basis” và câu hỏi cần điều tra; không được tự kết luận defect.
Tình huống Nova Foods	Ví dụ mô phỏng có thể dùng đơn hàng bán, tồn kho, lô hàng hoặc thông tin giao nhận. Không được gán nguyên nhân cho quy tắc thuế, hạch toán, hóa đơn, dữ liệu cá nhân, chất lượng thực phẩm hoặc truy xuất nguồn gốc khi chưa có bằng chứng và owner có thẩm quyền xác minh.
Tiêu chí hoàn thành	Learner nêu được fact quan sát, giả định, tác động, artifact bị ảnh hưởng, vai trò cần tham gia, quyết định cần có và hành động tiếp theo; không thay thế bằng nhận định chung như “hệ thống lỗi” hoặc “cần sửa gấp”.

Quy tắc phân loại và xử lý	Ranh giới áp dụng
Incident	Sự gián đoạn hoặc suy giảm dịch vụ quan sát được sau triển khai. BA ghi nhận thời điểm, người báo cáo, hành vi thực tế, tác động nghiệp vụ, dữ liệu/bằng chứng có sẵn và mức độ khẩn cấp do vai trò vận hành xác định. BA không tự cam kết thời gian khôi phục.
Defect	Hành vi quan sát được khác với test basis đã xác định. Record phải chỉ ra requirement, acceptance criterion, rule hoặc expected result liên quan. Không có test basis không đồng nghĩa không có vấn đề; đây là khoảng trống traceability cần điều tra.
Service request	Yêu cầu hỗ trợ hoặc quyền truy cập không làm thay đổi hành vi đã được đặc tả. Không được gắn nhãn defect chỉ vì người dùng cần hướng dẫn thao tác.
Enhancement hoặc change	Nhu cầu mới hoặc thay đổi hành vi/scope so với basis hiện hữu. Khi controlled baseline được thiết lập trong tương lai, thay đổi phải theo định danh CR-{DOMAIN}-{NNN}; tại phiên bản này chỉ được ghi nhận đề xuất, không tuyên bố thay đổi đã được phê duyệt.
Escalation	Chuyển cấp khi tác động liên quan legal, accounting, tax, invoice, privacy, security, food safety, traceability, dữ liệu lô/hạn dùng hoặc quyết định production. Package phải nêu fact, source classification, câu hỏi quyết định, tác động trì hoãn, artifact bị ảnh hưởng và owner nhận xử lý.

Nguồn và phân loại sử dụng	Phạm vi sử dụng an toàn trong chapter
BABOK Guide, IIBA, Version 3	Nguồn thuật ngữ và thực hành BA về đánh giá giải pháp, quản lý thay đổi và stakeholder collaboration; không viện dẫn số trang hoặc điều khoản chưa được kiểm chứng.
ISTQB CTFL Syllabus v4.0.1	Nguồn thuật ngữ testing để phân biệt test basis, defect và evidence; không dùng để xác nhận SLA vận hành hoặc quyết định release cho Nova Foods.
ISO/IEC/IEEE 29148:2018	Nguồn tham chiếu cấp cao về requirements engineering và tính truy vết; chỉ dùng abstract/bibliographic status nếu không có licensed text.
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	Nguồn pháp lý chính thức chỉ để định tuyến nội dung nhạy cảm tới Legal Owner, Accounting Owner hoặc Domain Owner. Mọi diễn giải yêu cầu hệ thống vẫn là Verification required cho đến khi được vai trò có thẩm quyền xác minh.
Project convention	Cấu trúc log, ví dụ ID, tiêu chí triage và Nova Foods terminology là quy ước đào tạo, không phải quy trình vận hành thực tế hoặc cam kết dịch vụ.

Kiểm soát chất lượng metadata	Quy tắc bắt buộc
Tính nhất quán định danh	Chỉ dùng CH-22 và tên tệp 22-operations-support-and-post-go-live-analysis.md; không đổi tên, tự tạo chapter thay thế hoặc suy diễn ID artifact chưa được registry xác nhận.
Source boundary	Phân biệt rõ fact có nguồn, Project assumption và Verification required. Không tạo trích dẫn, điều khoản, lời xác nhận từ user, hoặc kết luận chuyên môn không có bằng chứng.
Governance boundary	Chapter dạy cách chuẩn bị thông tin cho quyết định; không trao cho BA quyền phê duyệt change, xác nhận hạch toán, diễn giải pháp luật, chấp nhận rủi ro bảo mật hoặc quyết định vận hành production.
Change history dự kiến	v0.9.0 ngày 2026-08-07: khởi tạo metadata kế hoạch cho CH-22 ở trạng thái IN_REVIEW; tác động kiểm soát: chưa tạo baseline và chưa tạo approval.

CH-23 — 23-capstone-nova-foods-delivery-pack.md: Tích hợp gói bàn giao Nova Foods

Trường metadata	Giá trị được lập kế hoạch
Chapter ID	CH-23
Tên tệp được kiểm soát	23-capstone-nova-foods-delivery-pack.md
Tiêu đề chapter	Capstone Nova Foods Delivery Pack
Vị trí trong handbook	Chapter 23/25; thuộc capstone workflow, sau các nội dung yêu cầu, rule, mô hình, traceability, kiểm thử và readiness liên quan.
Status	IN_REVIEW
Version	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ quản trị	Asia/Ho_Chi_Minh
Locale và tiền tệ mô phỏng	vi-VN; Việt Nam; VND
Owner	Principal IT Business Analyst / Technical Curriculum Author
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp.
Phân loại nguồn	Nội dung hướng dẫn do tác giả biên soạn; dùng BABOK Guide Version 3 cho thuật ngữ BA; dùng ISTQB CTFL Syllabus v4.0.1 cho thuật ngữ testing; dùng các nguồn pháp lý chính thức chỉ để định tuyến Verification required, không diễn giải thay Legal Owner.
Mục đích	Hướng dẫn người học tích hợp các artifact BA đã có thành một gói bàn giao nhất quán cho một phạm vi Nova Foods hẹp, để người nhận có thể xác định phạm vi, quyết định còn mở, liên kết truy vết, bằng chứng kiểm thử và điểm cần chuyển cấp.
Không phải	Không phải phê duyệt delivery, baseline, xác nhận UAT, xác nhận tuân thủ, quyết định kiến trúc, quyết định kế toán, hoặc xác nhận sẵn sàng production.

Thành phần bắt buộc của delivery pack mô phỏng	Nội dung tối thiểu và quy tắc liên kết
Delivery scope summary	Nêu mục tiêu nghiệp vụ, in-scope, out-of-scope, actor, quy trình và giới hạn mô phỏng; không mở rộng scope bằng suy luận từ requirement.
Need và requirement register	Bao gồm các ID đã tồn tại, chẳng hạn NEED-SALES-001 và REQ-FUNC-SALES-012; mỗi requirement phải giữ source classification, priority, trạng thái và liên kết đến acceptance criteria.
Business-rule package	Tham chiếu ID rule chuẩn như BR-SALES-004, decision logic liên quan và nhãn Project assumption hoặc Verification required khi nguồn hoặc owner chưa xác minh. Không sao chép lại hoặc đổi nghĩa canonical rule.
Model và data reference	Liên kết tới process model, data dictionary và interface/API artifact hiện có; chỉ rõ điểm nào là mô hình hỗ trợ phân tích, không gọi activity diagram là BPMN nếu không tuân thủ BPMN 2.0.2.
Traceability matrix	Chứng minh chuỗi tối thiểu NEED-SALES-001 → REQ-FUNC-SALES-012 → AC-SALES-012-03 → TC-SALES-012-07; nếu có defect, nối tiếp đến DEF-<DOMAIN>-<NNN>, retest evidence và trạng thái acceptance.
Test và defect evidence	Liệt kê test basis, test case, expected result, actual result, evidence location, severity/priority theo quy ước được công bố và trạng thái retest. Defect chưa retest không được trình bày như đã giải quyết.
Change, risk và decision log	Ghi nhận change request theo mẫu CR-{DOMAIN}-{NNN} khi có tác động tới phạm vi hoặc artifact được kiểm soát; tách fact, decision cần có owner và assumption.
Handoff summary	Nêu người nhận dự kiến, artifact được bàn giao, open item, rủi ro, dependency, câu hỏi escalation và điều kiện không đủ để kết luận readiness.

Kết quả học tập dự kiến: Người học có thể hợp nhất artifact mà không phá vỡ định danh hoặc nguồn chân lý; phát hiện một liên kết đứt giữa requirement, acceptance criterion và test case; phân biệt evidence hiện có với kết luận chưa được xác minh; và lập escalation package có câu hỏi quyết định, tác động, owner cần tham gia cùng artifact bị ảnh hưởng.

Tiêu chí hoàn thành chapter: Delivery pack phải có ít nhất một chuỗi truy vết hoàn chỉnh từ business need đến acceptance; mọi mục Verification required phải nêu rõ vai trò nhận xác minh; mọi Project assumption phải được phân biệt với fact; và không có tuyên bố ngầm rằng Nova Foods đã phê duyệt, baseline, triển khai hoặc tuân thủ pháp lý. Nội dung liên quan dữ liệu cá nhân, kế toán, hóa đơn, an toàn thực phẩm, truy xuất nguồn gốc hoặc bảo mật phải giữ ranh giới escalation tới Legal Owner, Accounting Owner, Domain Owner hoặc Security Owner phù hợp.

CH-24 — 24-capstone-review-and-evaluation.md: Metadata kế hoạch hoàn chỉnh

Trường metadata	Giá trị kế hoạch được kiểm soát
Chapter ID	CH-24
Tên tệp chuẩn	24-capstone-review-and-evaluation.md
Đường dẫn dự kiến	/02-handbook/24-capstone-review-and-evaluation.md
Tiêu đề chapter	Capstone Review and Evaluation
Status	IN_REVIEW
Version	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale và tiền tệ mô phỏng	vi-VN; Việt Nam; VND
Owner	Principal IT Business Analyst / Technical Curriculum Author
Phân loại	Planned handbook chapter; controlled educational artifact; Nova Foods data tổng hợp
Vị trí curriculum	Chapter kết thúc luồng capstone, đánh giá chất lượng và khả năng bàn giao của delivery pack Nova Foods trước khi learner chuyển sang thực hành workflow có hỗ trợ AI.
Mục tiêu học tập	Learner thực hiện review độc lập, có cấu trúc đối với Nova Foods delivery pack; đối chiếu tính đầy đủ, nhất quán, kiểm tra được và truy vết của các artifact; phân biệt lỗi nội dung, lỗ hổng bằng chứng, project assumption và mục cần Verification required; lập escalation package khi vấn đề vượt thẩm quyền BA.
Đầu vào bắt buộc	Nova Foods capstone delivery pack từ CH-23; canonical IDs từ TRACEABILITY_ID_REGISTRY.md; business rules từ CANONICAL_BUSINESS_RULES.md; định nghĩa dữ liệu từ CANONICAL_DATA_DICTIONARY.md; phạm vi và tiêu chí năng lực từ COMPETENCY_COVERAGE_MATRIX.md.
Đầu ra dự kiến	Capstone review checklist; traceability review log; bảng phát hiện theo mức độ; evaluation rubric; danh sách gap; escalation package; handoff recommendation ở trạng thái đánh giá, không phải quyết định triển khai.
Chuỗi traceability tối thiểu cần kiểm tra	NEED-SALES-001 → REQ-FUNC-SALES-012 → AC-SALES-012-03 → TC-SALES-012-07 → bằng chứng thực thi mô phỏng → defect hoặc kết quả retest nếu có. Mỗi liên kết thiếu phải được ghi là finding, không được tự điền bằng suy luận.
Tiêu chí đánh giá	Mỗi requirement có nguồn gốc, phạm vi và acceptance criteria; mỗi business rule có ID, nguồn phân loại và owner xác minh phù hợp; mỗi test case có test basis, dữ liệu kiểm thử mô phỏng, expected result và evidence; mỗi defect có liên kết tới test case, mức độ, trạng thái retest và ảnh hưởng artifact.
Ranh giới đánh giá	Review xác định chất lượng artifact và các điểm cần quyết định; không xác nhận legal compliance, hạch toán, thuế, hóa đơn, an toàn thực phẩm, privacy, security, tính đúng vận hành hoặc production readiness của Nova Foods.
Quy tắc nguồn	BABOK Guide Version 3 được dùng cho thuật ngữ, task và năng lực BA; ISTQB CTFL Syllabus v4.0.1 được dùng cho thuật ngữ testing. Các luật, nghị định và nguồn ngành chỉ được dẫn chiếu theo phân loại nguồn đã xác minh; diễn giải áp dụng cho Nova Foods phải giữ nhãn Verification required cho đến khi vai trò có thẩm quyền xác minh.
Source classification	Primary standard: BABOK Guide, ISTQB CTFL Syllabus v4.0.1. Official legal source: 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. Mọi áp dụng chi tiết vẫn cần xác minh theo owner phù hợp.
Quy tắc governance	Không thay đổi canonical ID, requirement, rule, data definition hoặc baseline giả định trong lúc review. Finding phải nêu artifact bị ảnh hưởng, ID liên quan, fact quan sát được, source classification, tác động, người cần xử lý và quyết định hoặc xác minh còn thiếu.
Quy tắc escalation	Escalate tới Legal Owner khi finding có thể tạo diễn giải pháp lý hoặc nghĩa vụ privacy; Accounting Owner cho hạch toán, thuế, hóa đơn; Domain Owner cho chất lượng thực phẩm, lô, hạn dùng, truy xuất hoặc thu hồi; Security Owner cho kiểm soát bảo mật; Product Owner hoặc Sponsor cho ưu tiên, scope và trade-off.
Không được suy diễn	IN_REVIEW không phải baseline, approval, acceptance, sign-off, compliance confirmation hoặc quyết định go-live. Evaluation rubric không thay thế thẩm quyền của các owner chuyên môn.
Change-history record hiện hành	v0.9.0 — 2026-08-07 — IN_REVIEW — Principal IT Business Analyst / Technical Curriculum Author — khởi tạo metadata kế hoạch cho CH-24, xác định review evidence, traceability, governance và escalation boundaries.
Baseline và approval reference	Chưa có baseline reference; chưa có approval reference.

CH-25 — 25-ai-assisted-ba-workflow.md: Metadata kế hoạch đầy đủ

Trường metadata	Giá trị kế hoạch được kiểm soát
Chapter ID	CH-25
Tên tệp được kiểm soát	25-ai-assisted-ba-workflow.md
Vị trí dự kiến	/02-handbook/25-ai-assisted-ba-workflow.md
Tiêu đề chapter	AI-Assisted BA Workflow — Quy trình BA có hỗ trợ AI với kiểm soát bằng chứng
Status	IN_REVIEW
Version	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ quản trị	Asia/Ho_Chi_Minh
Locale và tiền tệ mô phỏng	vi-VN; Việt Nam; VND
Owner	Principal IT Business Analyst / Technical Curriculum Author
Phân loại artifact	Controlled handbook chapter plan; nội dung đào tạo, chưa là quy trình vận hành production
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp
Vị trí trong lộ trình	Chapter cuối của capstone workflow; hướng dẫn dùng AI để tăng tốc phân tích mà không thay thế phán đoán, ownership hoặc thẩm quyền BA
Mục tiêu học tập	Learner biết phân rã một tác vụ BA thành prompt có ngữ cảnh, đầu vào được kiểm soát, đầu ra cần kiểm tra và bước rà soát của con người; nhận diện khi AI output không đủ bằng chứng hoặc vượt boundary thẩm quyền.
Đầu vào tối thiểu	Requirement, acceptance criteria, business rule, glossary, data dictionary, traceability record và issue/escalation record đã tồn tại trong corpus Nova Foods.
Đầu ra dự kiến	Prompt brief; AI-output review log; danh sách phát hiện cần xác minh; bản nháp artifact có traceability; escalation package khi AI output chạm nội dung pháp lý, kế toán, privacy, security, an toàn thực phẩm hoặc quyết định production.
Capability evidence	Learner liên kết được AI-assisted draft với ID nguồn, ví dụ NEED-SALES-001 → REQ-FUNC-SALES-012 → AC-SALES-012-03 → TC-SALES-012-07, đồng thời ghi rõ phần nào là fact nguồn, Project assumption, Verification required hoặc nội dung do AI đề xuất.
Phụ thuộc chính	/01-curriculum/CHAPTER_MANIFEST.md; /01-curriculum/01_CURRICULUM_ARCHITECTURE.md; TRACEABILITY_ID_REGISTRY.md; CANONICAL_BUSINESS_RULES.md; CANONICAL_DATA_DICTIONARY.md; glossary và các artifact capstone Nova Foods liên quan.
Artifact không được thay thế	AI không thay thế source of truth, Business Owner, Domain Owner, Legal Owner, Accounting Owner, Security Owner, Test Lead, Architect hoặc quyết định của người có thẩm quyền.
Baseline reference	Chưa có baseline reference tại v0.9.0.
Approval reference	Chưa có approval reference tại v0.9.0; IN_REVIEW không là bằng chứng chấp thuận sử dụng AI, phê duyệt requirement hoặc chấp thuận triển khai.
Change-history record	v0.9.0 — 2026-08-07 — IN_REVIEW — Principal IT Business Analyst / Technical Curriculum Author — khởi tạo metadata kế hoạch cho CH-25 và các boundary kiểm soát AI-assisted BA workflow.

Phạm vi nội dung dự kiến	Quy tắc biên bắt buộc
Chuẩn bị prompt	Prompt phải nêu mục tiêu BA, artifact đầu vào, ID nguồn, phạm vi Nova Foods, định dạng đầu ra, tiêu chí kiểm tra và điều AI không được suy đoán. Không đưa dữ liệu cá nhân thật, dữ liệu khách hàng thật, bí mật vận hành hoặc thông tin production vào ví dụ đào tạo.
Sinh bản nháp	AI output chỉ là bản nháp hỗ trợ phân tích. Mỗi rule, số liệu, định nghĩa, luồng xử lý hoặc claim phải được đối chiếu với artifact nguồn trước khi đưa vào deliverable.
Rà soát chất lượng	Reviewer kiểm tra tối thiểu: đúng ID, nhất quán thuật ngữ, không mất ngoại lệ, không thêm fact không có nguồn, không chuyển assumption thành requirement, và không tạo trích dẫn hoặc approval giả.
Traceability	Mọi output được giữ lại phải ghi Source artifact, Source classification, Related IDs, Reviewer action và Open question. AI không được tự tạo canonical ID, đổi tên file chuẩn hoặc sửa source classification.
Escalation	Khi output liên quan nghĩa vụ pháp lý, hóa đơn, hạch toán, dữ liệu cá nhân, security, chất lượng thực phẩm, truy xuất nguồn gốc hoặc quyết định kiến trúc, learner phải gắn Verification required và lập escalation package cho owner có thẩm quyền.
Giới hạn quyết định	AI có thể đề xuất câu hỏi, cấu trúc bảng, test condition hoặc điểm mâu thuẫn. AI không thể xác nhận tính đúng pháp lý, compliance, hạch toán, an toàn thực phẩm, mức chấp nhận UAT hoặc production readiness.

Nguồn dự kiến	Source classification	Cách dùng và giới hạn
BABOK Guide Version 3	Primary professional source	Dùng thuật ngữ BA, knowledge area, task và competency ở mức nguồn cho phép; không tạo page reference hoặc clause reference không được kiểm chứng.
ISO/IEC/IEEE 29148:2018	Primary standards source	Dùng abstract và bibliographic status để định hướng chất lượng requirement; exact clause chỉ dùng khi có kiểm tra licensed text.
Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP	Official legal source	Chỉ định tuyến câu hỏi về dữ liệu cá nhân đến Legal Owner; mọi yêu cầu áp dụng cụ thể phải mang Verification required trước khi được xác minh.
OWASP ASVS 5.0.0 và OWASP API Security Top 10 2023	Industry security good practice	Dùng để nhận diện câu hỏi security cần escalation; không trình bày là luật Việt Nam hoặc bằng chứng compliance.
Canonical artifact của Nova Foods	Internal controlled corpus source	Là nguồn duy nhất cho ID, business rule, data definition và giả định case study; dữ liệu vẫn là dữ liệu tổng hợp phục vụ giáo dục.

Quy tắc bảo toàn governance: metadata và nội dung dự kiến của CH-25 phải duy trì ranh giới giữa AI-generated suggestion, evidence từ source artifact và quyết định của người có thẩm quyền. Nếu AI output làm thay đổi scope, requirement, business rule, data definition, test basis hoặc escalation status, thay đổi phải được ghi nhận trong artifact kiểm soát liên quan; không được coi output đó là baseline, approval hoặc chỉ thị triển khai.

Liên kết lập kế hoạch chương kiểm thử với mô-đun kiểm thử chuyên sâu và chuỗi bằng chứng

Các chương 18-testing-fundamentals-for-ba.md, 19-black-box-testing-techniques-for-ba.md và 20-uat-planning-defects-and-regression.md phải được lập kế hoạch như một mini-book kiểm thử thống nhất, đồng thời căn chỉnh ở cấp chapter với mô-đun kiểm thử chuyên sâu. Căn chỉnh không có nghĩa lặp lại toàn bộ kỹ thuật chuyên sâu; mỗi chapter phải xác định rõ phần kiến thức nền, kỹ thuật hoặc bằng chứng mà learner sẽ nhận từ mô-đun đó, rồi áp dụng vào artifact Nova Foods Trading & Manufacturing mô phỏng. Thuật ngữ kiểm thử và kỹ thuật black-box phải tham chiếu ranh giới sử dụng an toàn của ISTQB CTFL Syllabus v4.0.1; không suy diễn phương pháp kiểm thử thành xác nhận chất lượng production.

Chapter	Vai trò trong chuỗi kiểm thử	Căn chỉnh bắt buộc với mô-đun kiểm thử chuyên sâu	Đầu ra truy vết dự kiến
18-testing-fundamentals-for-ba.md	Thiết lập test basis, test condition, mức kiểm thử, vai trò BA trong chuẩn bị và đánh giá bằng chứng.	Dùng mô-đun chuyên sâu để thống nhất thuật ngữ test basis, test case, defect, retest và regression; chapter này tập trung cách BA chuyển requirement thành điều kiện kiểm thử quan sát được.	Liên kết từ need, requirement và acceptance criterion đến test condition và test case.
19-black-box-testing-techniques-for-ba.md	Hướng dẫn chọn kỹ thuật black-box phù hợp với rule, biên dữ liệu, trạng thái và ngoại lệ.	Mô-đun chuyên sâu là nguồn học sâu về kỹ thuật; chapter chỉ định tiêu chí chọn kỹ thuật và cách ghi bằng chứng áp dụng vào rule Nova Foods.	Test case có dữ liệu vào, bước thực hiện, expected result, kỹ thuật được dùng và liên kết requirement/rule.
20-uat-planning-defects-and-regression.md	Điều phối UAT, ghi nhận defect, quyết định retest/regression và tập hợp evidence cho acceptance.	Mô-đun chuyên sâu cung cấp nguyên tắc vòng đời defect và phạm vi regression; chapter áp dụng vào kế hoạch UAT, ownership và điều kiện đóng evidence.	UAT scenario, defect record, kết quả retest, phạm vi regression và trạng thái acceptance có điều kiện.

Chuỗi truy vết tối thiểu phải được giữ nguyên từ nhu cầu nghiệp vụ đến bằng chứng chấp nhận:

Điểm chuỗi	ID ví dụ Nova Foods mô phỏng	Nội dung tối thiểu	Quy tắc kiểm soát
Business need	NEED-SALES-001	Vấn đề hoặc kết quả kinh doanh cần đạt.	Need không phải test case và không tự xác nhận giải pháp.
Functional requirement	REQ-FUNC-SALES-012	Hành vi hệ thống cần thực hiện trong phạm vi đã mô tả.	Requirement phải là test basis; không thay business rule bằng diễn giải của tester.
Acceptance criterion	AC-SALES-012-03	Điều kiện quan sát được để đánh giá requirement.	Criterion phải có kết quả có thể kiểm tra, không chỉ lặp lại requirement.
Test case	TC-SALES-012-07	Preconditions, dữ liệu tổng hợp, bước, expected result và liên kết test basis.	Mỗi test case phải chỉ rõ requirement và acceptance criterion được kiểm tra.
Defect	DEF-SALES-012-001	Chênh lệch có bằng chứng giữa actual result và expected result.	Defect không được đóng chỉ vì có thay đổi mã; phải giữ evidence và liên kết test case.
Retest	RT-SALES-012-001	Chạy lại test case bị lỗi sau khi có bản sửa khả dụng.	Retest xác nhận defect cụ thể; không mặc định bao phủ tác động lân cận.
Regression	RG-SALES-012-001	Tập test được chọn để kiểm tra tác động của thay đổi.	Phạm vi regression phải nêu lý do chọn theo requirement, rule, interface hoặc dữ liệu bị ảnh hưởng.
Acceptance evidence	UAT-SALES-012-001	Kết quả UAT, defect còn mở, quyết định cần có và giới hạn bằng chứng.	Evidence hỗ trợ đánh giá acceptance, không tự tạo approval hoặc baseline.

Ví dụ chuỗi mô phỏng: NEED-SALES-001 liên kết REQ-FUNC-SALES-012, được kiểm tra qua AC-SALES-012-03 và TC-SALES-012-07. Nếu actual result không khớp expected result, ghi DEF-SALES-012-001; sau bản sửa, thực hiện RT-SALES-012-001 và xác định RG-SALES-012-001 theo tác động đã biết. Chỉ khi evidence UAT được ghi nhận đầy đủ trong UAT-SALES-012-001 thì artifact mới có thể trình bày trạng thái bằng chứng chấp nhận; mọi quyết định vượt thẩm quyền BA, còn mơ hồ về rule, pháp lý, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc phải giữ nhãn Verification required và được escalation tới owner phù hợp.

Ràng buộc quản trị, truy vết và escalation cho nhóm Capstone và AI Workflow

Metadata dự kiến của các chapter capstone và AI workflow phải giữ nguyên ranh giới giữa nội dung đào tạo, artifact mô phỏng Nova Foods Trading & Manufacturing và quyết định có thẩm quyền ngoài phạm vi handbook. Mọi ví dụ sử dụng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND; trạng thái kế hoạch hiện hành là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Các metadata này không tạo baseline, approval, xác nhận tuân thủ, hoặc quyền triển khai production.

Chapter ID	Tệp được kiểm soát	Yêu cầu bảo toàn governance trong metadata	Yêu cầu traceability	Ngưỡng escalation bắt buộc
CH-23	23-capstone-nova-foods-delivery-pack.md	Xác định delivery pack là bộ artifact mô phỏng phục vụ đánh giá năng lực BA; Owner curriculum chỉ quản trị cấu trúc và lịch sử thay đổi, không xác nhận nghiệp vụ, pháp lý, kế toán hoặc production readiness.	Mỗi artifact trong capstone phải tham chiếu ID nguồn đã có, như NEED-SALES-001, REQ-FUNC-SALES-012, AC-SALES-012-03, BR-SALES-004 và TC-SALES-012-07, khi các ID này được áp dụng.	Escalate khi thiếu owner quyết định, có mâu thuẫn giữa requirement và rule, hoặc có claim liên quan privacy, hóa đơn, kế toán, an toàn thực phẩm, truy xuất nguồn gốc hay security chưa được xác minh.
CH-24	24-capstone-review-and-evaluation.md	Phân biệt đánh giá chất lượng artifact học tập với approval dự án. Kết quả review chỉ ghi nhận phát hiện, bằng chứng, quyết định cần làm rõ và trạng thái xử lý; không suy diễn learner, reviewer hoặc Owner đã phê duyệt delivery pack.	Rubric đánh giá phải kiểm tra tính liên kết từ business need đến requirement, acceptance criteria, rule, test evidence, change record và handoff summary. Mỗi phát hiện phải nêu artifact hoặc ID bị ảnh hưởng.	Escalate khi phát hiện không thể phân loại nguồn là fact đã xác minh, Project assumption hoặc Verification required; hoặc khi việc chấm yêu cầu diễn giải pháp lý, kế toán hay domain ngoài thẩm quyền reviewer.
CH-25	25-ai-assisted-ba-workflow.md	Metadata phải nêu AI là công cụ hỗ trợ tạo nháp, kiểm tra nhất quán và đề xuất câu hỏi; AI không phải source of truth, không có quyền phê duyệt, không thay thế owner nghiệp vụ hoặc vai trò kiểm soát.	Mọi đầu ra AI được đưa vào Nova Foods phải liên kết tới input artifact, source classification, người rà soát, ngày rà soát và ID artifact đích. Nội dung không truy được nguồn phải giữ là bản nháp hoặc câu hỏi mở.	Escalate khi AI tạo claim không có nguồn, làm thay đổi ID chuẩn, suy diễn nghĩa vụ pháp lý, tiết lộ hoặc yêu cầu dữ liệu cá nhân thật, hoặc đề xuất quyết định vượt thẩm quyền BA.

Quy tắc metadata dùng chung

1. Trường source classification phải phân biệt tối thiểu: nguồn chính thức, nguồn chuẩn/industry, project convention, Project assumption và Verification required. Không được chuyển nhãn chỉ vì nội dung xuất hiện trong capstone hoặc do AI tạo.
2. Trường traceability phải giữ liên kết hai chiều giữa artifact đầu vào, artifact được tạo hoặc review, phát hiện, quyết định cần có và escalation record. Không được thay ID, tên tệp chuẩn hoặc source boundary để làm liên kết có vẻ hoàn chỉnh.
3. Trường escalation phải ghi câu hỏi quyết định, tác động nếu chưa quyết định, vai trò nhận escalation và artifact bị ảnh hưởng. Legal Owner, Accounting Owner, Domain Owner, Security Owner hoặc Architecture Owner chỉ xác minh trong phạm vi thẩm quyền tương ứng.
4. Khi metadata cho thấy bằng chứng chưa đủ, chapter phải dừng ở Verification required hoặc Project assumption; không được gọi delivery pack là compliant, approved, baselined hoặc production-ready.

Cross-File Checks, Self-Review, Open Issues, and Escalation Needs

Kiểm tra chéo số lượng và dải tên tệp chapter

Mục tiêu của kiểm tra này là xác nhận catalog chapter trong manifest và tập tệp chapter dự kiến dùng cùng một tập gồm đúng 26 phần tử. Phạm vi kiểm tra chỉ bao gồm số lượng, chỉ số thứ tự và tên tệp canonical; không đánh giá nội dung đào tạo, trường metadata, dependency hoặc chất lượng từng chapter.

Mã kiểm tra	Đối tượng so sánh	Quy tắc đạt	Điều kiện không đạt
XFC-CH-COUNT-001	Các chapter entry tại các catalog chapter của manifest	Có đúng 26 entry, tương ứng một entry cho mỗi chỉ số nguyên từ 00 đến 25.	Tổng entry nhỏ hơn hoặc lớn hơn 26; một chỉ số xuất hiện nhiều lần; hoặc tồn tại chỉ số ngoài dải 00–25.
XFC-CH-SEQ-002	Prefix hai chữ số của filename canonical	Tập prefix phải bằng chính xác {00, 01, 02, …, 25}; khi sắp xếp tăng dần, mỗi prefix kế tiếp tăng đúng một đơn vị.	Thiếu bất kỳ prefix nào trong dải; ví dụ có 00, 01, 03 nhưng không có 02; hoặc có prefix lặp như hai entry 08.
XFC-CH-FIRST-003	Entry đầu dải	Filename của chapter 00 phải là chính xác 00-foundations.md.	Entry 00 không tồn tại, dùng khác tên, sai chữ thường/chữ hoa, sai dấu gạch nối, hoặc sai phần mở rộng .md.
XFC-CH-LAST-004	Entry cuối dải	Filename của chapter 25 phải là chính xác 25-ai-assisted-ba-workflow.md.	Entry 25 không tồn tại, dùng khác tên, sai chữ thường/chữ hoa, sai dấu gạch nối, hoặc sai phần mở rộng .md.
XFC-CH-NAME-005	Filename của toàn bộ 26 entry	Mỗi filename khớp tuyệt đối với filename canonical đã công bố tại catalog chapter tương ứng; đối chiếu phân biệt ký tự, dấu gạch nối và phần mở rộng.	Filename bị đổi slug, thêm hậu tố phiên bản, dùng khoảng trắng, đổi .md thành phần mở rộng khác, hoặc thay thế bằng tên mô tả không canonical.
XFC-CH-EXTRA-006	Tập filename chapter được khai báo hoặc tham chiếu	Không có filename chapter ngoài tập 26 filename canonical từ 00 đến 25.	Có tệp hoặc entry như 26-*.md, 00-foundations-v2.md, draft-*.md, hoặc một filename không thuộc dải canonical nhưng được trình bày như chapter.

Thủ tục thực hiện

1. Trích xuất toàn bộ chapter entry từ ba phần catalog của manifest, giữ nguyên filename trong dấu backtick.
2. Sắp xếp entry theo prefix số hai chữ số, không sắp xếp theo title hoặc theo vị trí hiển thị.
3. Đếm số entry duy nhất theo filename và số prefix duy nhất. Cả hai kết quả phải bằng 26.
4. Kiểm tra prefix đầu là 00, prefix cuối là 25, và không có chênh lệch lớn hơn một giữa hai prefix liền kề sau khi sắp xếp.
5. Đối chiếu chính xác hai boundary filename: 00-foundations.md và 25-ai-assisted-ba-workflow.md.
6. Đối chiếu từng filename còn lại với entry canonical cùng chỉ số trong catalog; không được suy luận filename từ title, dịch title sang tiếng Việt, hoặc tự chuẩn hóa slug.
7. Lập một record kiểm tra với kết quả PASS chỉ khi tất cả mã XFC-CH-COUNT-001 đến XFC-CH-EXTRA-006 đều đạt. Chỉ một lỗi cũng cho kết quả FAIL — MANIFEST CATALOG CORRECTION REQUIRED.

Ranh giới kiểm soát: Dải 00–25 là dải chapter duy nhất của handbook trong manifest này. Tệp hỗ trợ, template, glossary, cheatsheet, QA report hoặc artifact Nova Foods không được đếm như chapter và không được dùng để bù cho chapter entry bị thiếu. Việc một tệp tồn tại trong repository không chứng minh filename đó là canonical; canonical status chỉ đến từ entry tương ứng trong catalog manifest.

Kết quả kiểm tra ở giai đoạn này chỉ là bằng chứng lập kế hoạch cho /01-curriculum/CHAPTER_MANIFEST.md. Artifact vẫn ở trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không baseline, không approval và không xác nhận sẵn sàng drafting.

Kiểm tra đủ trường bắt buộc trên từng Chapter Entry

Áp dụng một Field-Completeness Gate cho từng entry chapter trong catalog của manifest trước khi entry đó được dùng làm đầu vào drafting. Một entry chỉ đạt khi có đủ 14 trường dưới đây, mỗi trường có nội dung xác định được, phù hợp phạm vi giáo dục Nova Foods Trading & Manufacturing, và không dùng dữ liệu ngoài tổng hợp. Giá trị rỗng, chỉ ghi tên trường, hoặc thay bằng nhận xét chung không được tính là đã có trường.

Trường bắt buộc	Nội dung tối thiểu phải ghi trong entry	Tiêu chí đạt có thể kiểm tra	Lỗi chặn
title	Tên chapter phản ánh đúng năng lực hoặc chủ đề chính cần học.	Một tên duy nhất, có ý nghĩa đào tạo, không dùng tên tạm hoặc tên mơ hồ như “Khái niệm khác”.	Thiếu tên, trùng vai trò rõ rệt với chapter khác, hoặc tên mâu thuẫn phạm vi chapter.
level	Mức năng lực dự kiến của learner tại chapter, theo logic novice, intermediate hoặc senior-ready của curriculum architecture.	Mức nêu rõ và tương thích với độ khó của artifact đầu ra.	Gán mức senior-ready cho nội dung chưa có prerequisite nền tảng hoặc hạ mức một chapter đòi hỏi phán đoán escalation.
prerequisites	Kiến thức, kỹ năng, chapter hoặc artifact learner cần có trước khi học.	Mỗi prerequisite chỉ tới năng lực hay đầu ra đã được giới thiệu trước đó trong chuỗi học.	Prerequisite mơ hồ, tự tham chiếu, hoặc đòi hỏi khái niệm chưa có điểm giới thiệu.
target capability	Hành vi BA quan sát được mà learner phải thực hiện được sau chapter.	Dùng động từ có thể đánh giá, nêu đối tượng và kết quả, ví dụ phân tách requirement, rule và acceptance criterion.	Chỉ ghi mục tiêu kiểu “hiểu”, “biết thêm”, hoặc cam kết năng lực không có đầu ra quan sát được.
central mental model	Một khung tư duy dẫn dắt việc phân tích, như tách vấn đề, need, requirement, rule, dữ liệu và bằng chứng.	Diễn đạt được quan hệ hoặc cách ra quyết định, không chỉ là danh sách thuật ngữ.	Trùng nguyên văn mental model của chapter khác nhưng không có vai trò bổ sung rõ ràng.
Nova Foods scenario	Tình huống mô phỏng cụ thể thuộc Nova Foods Trading & Manufacturing, dùng dữ liệu tổng hợp và bối cảnh Việt Nam.	Có actor, sự kiện hoặc đối tượng nghiệp vụ đủ để thực hành; tiền tệ mô phỏng là VND khi có giá trị tiền.	Đưa dữ liệu cá nhân thật, khách hàng thật, tổ chức thật, hoặc mô tả như vận hành production đã xác nhận.
required artifacts	Danh sách artifact learner phải tạo, cập nhật hoặc dùng làm đầu vào.	Mỗi artifact có loại đầu ra rõ, ví dụ requirement package, rule catalog, decision table, traceability link hoặc test case.	Gọi một ghi chú chung là artifact, hoặc yêu cầu artifact không có chapter nào cung cấp tiền đề.
diagram types	Loại sơ đồ được phép hoặc bắt buộc dùng để diễn đạt nội dung chapter.	Phân biệt đúng notation: BPMN chỉ dùng khi tuân theo BPMN 2.0.2; UML chỉ dùng theo UML 2.5.1; PlantUML activity diagram không được gọi là BPMN.	Gắn sai tên notation, không nêu loại sơ đồ khi chapter yêu cầu mô hình hóa, hoặc yêu cầu sơ đồ không phục vụ capability.
source families	Nhóm nguồn được phép dùng làm nền tảng nội dung: nguồn chuẩn, nguồn pháp lý chính thức, industry good practice, project convention, author recommendation, Project assumption, hoặc Verification required.	Phân loại nguồn rõ; các chủ đề pháp lý, kế toán, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm và truy xuất nguồn gốc có đường xác minh phù hợp.	Trình bày industry good practice như luật, suy diễn điều khoản không được xác minh, hoặc thiếu nhãn Verification required cho nội dung cần owner xác nhận.
quality gate	Điều kiện review tối thiểu để đánh giá đầu ra chapter đủ chất lượng học tập.	Có tiêu chí kiểm tra được đối với tính rõ ràng, nhất quán, khả năng truy vết hoặc khả năng kiểm thử.	Gate chỉ nói “đạt chất lượng tốt”, không nêu bằng chứng, hoặc yêu cầu xác nhận production.
traceability dependencies	Artifact, ID registry hoặc nguồn chuẩn mà chapter phải tham chiếu để giữ liên kết.	Nêu dependency theo đúng tên controlled artifact, gồm khi phù hợp TRACEABILITY_ID_REGISTRY.md, CANONICAL_BUSINESS_RULES.md, CANONICAL_DATA_DICTIONARY.md, COMPETENCY_COVERAGE_MATRIX.md hoặc template manifest.	Tự tạo canonical ID, thay thế source of truth, hoặc không chỉ ra dependency cho chapter có artifact liên kết.
independent decisions	Những lựa chọn learner hoặc tác giả được phép tự quyết trong phạm vi giáo dục.	Giới hạn vào lựa chọn trình bày, mô hình hóa, giả định được gắn nhãn hoặc phương án phân tích không vượt thẩm quyền.	Cho phép tự xác nhận legal applicability, accounting treatment, security control, kiến trúc kỹ thuật hoặc policy Nova Foods.
escalation decisions	Các quyết định không được tự chốt và cần chuyển vai trò có thẩm quyền.	Nêu loại vấn đề và owner cần tham gia, như Legal Owner với nghĩa vụ pháp lý hoặc Technical Architect với quyết định integration.	Không có điểm chuyển cấp đối với chapter chạm privacy, accounting, food safety, security, hóa đơn hoặc kiến trúc.
explicit exclusions	Nội dung chapter chủ động không dạy, không quyết định hoặc không tuyên bố.	Nêu ranh giới chống scope creep, ví dụ không thay legal advice, không xác nhận compliance, không tạo requirement production.	Exclusion phủ định mục tiêu chapter, hoặc không loại trừ các quyết định vượt quyền.

Thủ tục kiểm tra entry: reviewer đối chiếu từng chapter entry với bảng trên và ghi kết quả PASS hoặc BLOCKED cho từng trường. PASS chỉ được ghi khi trường có nội dung riêng, kiểm tra được và không mâu thuẫn boundary nguồn. Chỉ cần một trường BLOCKED, entry phải được trả về để bổ sung hoặc làm rõ; không được suy đoán nội dung từ title, chapter lân cận, hoặc từ artifact khác để lấp trường thiếu.

Quy tắc phân biệt đầy đủ với hợp lệ: có đủ 14 trường mới là điều kiện đầy đủ cấu trúc; tính đúng đắn chuyên môn, pháp lý, kỹ thuật hoặc nghiệp vụ vẫn phải giữ đúng source classification. Với nội dung chưa được nguồn và owner có thẩm quyền xác minh, entry phải ghi Verification required hoặc Project assumption; việc hoàn tất Field-Completeness Gate không chuyển nội dung đó thành fact, requirement đã chấp thuận, hay quyết định vận hành Nova Foods.

Ma trận đối chiếu liên artifact trước khi soạn thảo

Việc đối chiếu được thực hiện trên manifest ở trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, theo bối cảnh vi-VN, Asia/Ho_Chi_Minh, VND và Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục với dữ liệu tổng hợp. Mục tiêu là xác nhận mỗi định hướng chapter có chỗ đứng trong kiến trúc curriculum, có năng lực cần đạt, có định danh truy vết hợp lệ, có ranh giới nguồn phù hợp và không chuyển giả định mô phỏng thành fact, nghĩa vụ pháp lý hoặc quyết định production.

Đối tượng đối chiếu	Bằng chứng phải đối chiếu	Tiêu chí đạt trong CHAPTER_MANIFEST.md	Điều kiện không đạt
Curriculum architecture	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md, đặc biệt chuỗi học từ foundations đến delivery-ready, capability gate và boundary thẩm quyền	Vai trò, prerequisite, target capability và artifact đầu ra của từng chapter phải giữ đúng logic tiến trình; requirement phải có trước test basis, business rule không bị thay bằng requirement, và capstone chỉ tích hợp các năng lực đã được giới thiệu.	Một chapter yêu cầu learner dùng concept, ID hoặc artifact chưa có điểm giới thiệu; hoặc đưa nội dung pháp lý, kế toán, security hay kiến trúc ra ngoài thẩm quyền BA học tập.
Competency coverage	COMPETENCY_COVERAGE_MATRIX.md	Mỗi target capability và quality gate của chapter phải ánh xạ được tới competency quan sát được; chuỗi ví dụ phải hỗ trợ năng lực biến need thành requirement, acceptance criteria, traceability và test evidence.	Manifest nêu năng lực nhưng không có bằng chứng chapter hoặc gate tương ứng; hoặc cùng một năng lực bị gán mâu thuẫn giữa cấp độ novice, intermediate và senior-ready.
Traceability registry	TRACEABILITY_ID_REGISTRY.md	Mọi ID minh họa phải dùng đúng namespace đã công bố, như NEED-SALES-001, REQ-FUNC-SALES-012, AC-SALES-012-03, TC-SALES-012-07, BR-SALES-004 và quy ước change request CR-{DOMAIN}-{NNN} khi áp dụng. Quan hệ dự kiến phải giữ được chuỗi need → requirement → acceptance criterion → test case.	Tạo namespace mới, đổi nghĩa ID chuẩn, dùng một ID cho nhiều thực thể, hoặc mô tả liên kết không thể truy ngược về registry.
Source policy	Verified primary-source seed và source policy upstream hiện hành	BABOK Guide chỉ dùng cho kiến thức, task, competency và thuật ngữ BA; BPMN 2.0.2 chỉ dùng khi gọi notation là BPMN; UML 2.5.1 chỉ dùng cho ngữ nghĩa UML; OAS 3.1.1, WCAG 2.2 và ISTQB CTFL v4.0.1 được dùng trong đúng phạm vi chuyên môn. Không ghi page, clause hoặc yêu cầu chi tiết khi chưa kiểm chứng văn bản được cấp phép hoặc nguồn chính thức tương ứng.	Gán tính chuẩn tắc sai nguồn; gọi PlantUML activity diagram là BPMN; trình bày OWASP ASVS hoặc OWASP API Security Top 10 như luật Việt Nam; hoặc tạo trích dẫn, điều khoản và nghĩa vụ không có nguồn xác minh.
Ranh giới pháp lý và domain	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 trong Verified primary-source seed	Nội dung về dữ liệu cá nhân, kế toán, hóa đơn, an toàn thực phẩm, truy xuất nguồn gốc, thu hồi và lưu giữ dữ liệu chỉ được định hướng dưới nhãn Verification required hoặc Project assumption nếu chưa có xác minh phù hợp.	Manifest mô tả chi tiết như một nghĩa vụ tuân thủ, rule kế toán, chính sách thuế hoặc quy trình pháp lý đã xác nhận.
Simulated Nova Foods constraints	Terminology và scenario xuyên suốt curriculum architecture	Các scenario giữ nhất quán với Nova Foods Trading & Manufacturing; số tiền minh họa dùng VND; dữ liệu là synthetic; ví dụ phục vụ học tập, không đại diện dữ liệu khách hàng, hóa đơn thật, lô hàng thật hoặc quyết định vận hành thực tế.	Đổi tên tổ chức, làm sai bối cảnh Việt Nam, dùng dữ liệu nhận diện cá nhân thật, hoặc tuyên bố artifact mô phỏng là cấu hình ERP hay tài liệu sẵn sàng production.

Quy tắc ghi nhận kết quả đối chiếu: mỗi dòng chapter chỉ được xem là phù hợp khi có thể chỉ ra artifact nguồn, trường manifest bị kiểm tra, ID hoặc thuật ngữ liên quan, và kết quả PASS hoặc BLOCK. BLOCK giữ nguyên nhãn nguồn và nhãn xác minh hiện có; không được xử lý bằng cách tự tạo rule Nova Foods, đổi ID chuẩn, hoặc suy luận thẩm quyền từ nội dung đào tạo.

Tiêu chí tự rà soát cấu trúc và tính nhất quán của từng chapter entry

Tác giả manifest tự rà soát từng chapter entry trước khi chuyển sang bước kiểm tra liên artifact. Mục tiêu là phát hiện lỗi cấu trúc ngay tại nguồn: một entry thiếu thông tin làm drafting không có ranh giới; hai entry cùng vai trò làm trùng coverage; level hoặc thứ tự sai làm người học gặp kiến thức chưa được chuẩn bị. Việc rà soát dùng nội dung manifest và các định danh chuẩn đã được cấp, không tự tạo ID, filename, source hoặc quyết định Nova Foods mới.

Nhóm lỗi cần phát hiện	Cách tự rà soát cụ thể	Điều kiện đạt	Điều kiện không đạt và xử lý trong manifest
Thiếu trường bắt buộc	Đọc theo từng entry và đối chiếu lần lượt các nhãn: title, level, prerequisites, target capability, central mental model, Nova Foods scenario, required artifacts, diagram types, source families, quality gate, traceability dependencies, independent decisions, escalation decisions, explicit exclusions.	Mỗi nhãn có giá trị cụ thể, có thể dùng để định hướng drafting và không chỉ là câu chung chung như “học BA”.	Một nhãn vắng mặt, rỗng, hoặc không tạo được ranh giới soạn thảo là lỗi chặn. Bổ sung nội dung ở đúng trường; không chuyển chi tiết còn chưa xác minh thành fact.
Trùng vai trò chapter	So sánh target capability, central mental model, required artifacts và quality gate của entry đang rà soát với các entry liền trước và liền sau.	Mỗi chapter có một đóng góp chính khác biệt trong chuỗi từ foundations đến delivery-ready; artifact có thể được tái sử dụng nhưng mục tiêu học không bị lặp.	Hai chapter cùng dạy một thao tác, tạo cùng loại artifact ở cùng mức độ sâu và dùng cùng gate mà không có bước phát triển năng lực rõ ràng. Phân tách phạm vi, tăng độ sâu hợp lý, hoặc hợp nhất vai trò trong kế hoạch.
Level không nhất quán	Kiểm tra level có tương xứng với prerequisites, độ phức tạp artifact, mức độ tự chủ và loại quyết định được giao hay không.	Chapter ở mức đầu không yêu cầu learner tự đánh giá kiến trúc, compliance hoặc trade-off chưa được dạy; chapter mức cao hơn kế thừa được artifact và kỹ năng đã giới thiệu.	Level ghi thấp nhưng yêu cầu phân tích liên miền hoặc quyết định vượt thẩm quyền; hoặc level ghi cao nhưng chỉ lặp lại thao tác cơ bản. Điều chỉnh level, prerequisite hoặc phạm vi capability, không thay đổi năng lực curriculum một cách ngầm định.
Naming mismatch	Đối chiếu chapter ID, filename, title, artifact ID mẫu, traceability dependency và tên Nova Foods với định danh đã có trong corpus.	Tên tệp dùng đúng canonical filename; tên artifact, ID như NEED-SALES-001, REQ-FUNC-SALES-012, AC-SALES-012-03, TC-SALES-012-07 được giữ nguyên ý nghĩa và định dạng khi được tham chiếu.	Một entry dùng biến thể như đổi tiền tố ID, đổi chữ hoa-thường có ý nghĩa định danh, hoặc gọi cùng một thực thể Nova Foods bằng hai tên khác nhau. Sửa về canonical naming; không tạo alias không được registry kiểm soát.
Đứt trình tự học	Lần theo prerequisite → target capability → required artifacts → quality gate của entry, rồi xác định chapter trước đã cung cấp đầu vào tối thiểu chưa.	Người học nhận được khái niệm, dữ liệu mô phỏng, ID, kỹ thuật mô hình hóa và artifact nền trước khi phải sử dụng chúng để tạo đầu ra mới.	Entry yêu cầu viết test case trước khi có requirement và acceptance criteria; yêu cầu decision table trước khi giới thiệu business rule; hoặc yêu cầu escalation judgment khi chưa phân biệt fact, Project assumption và Verification required. Sửa thứ tự dependency hoặc thu hẹp đầu ra chapter.
Ranh giới thẩm quyền không rõ	Đọc independent decisions, escalation decisions và explicit exclusions như một bộ ba kiểm soát.	Entry chỉ cho learner tự quyết định nội dung thuộc kỹ thuật BA và mô phỏng giáo dục; nội dung pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc hoặc production vẫn được giới hạn rõ.	Entry cho phép tự kết luận nghĩa vụ pháp lý, quyết định hạch toán, xác nhận compliance hoặc phê duyệt thiết kế. Chuyển nội dung thành câu hỏi cần xác minh và giữ nhãn Verification required hoặc Project assumption phù hợp.
Chất lượng gate không kiểm tra được	Kiểm tra quality gate có nêu bằng chứng quan sát được từ required artifacts hay không.	Gate chỉ ra được đặc điểm có thể kiểm: liên kết ID, điều kiện đầu vào, kết quả mong đợi, ngoại lệ, nguồn hoặc trạng thái nhãn.	Gate dùng các nhận xét chủ quan như “đủ tốt”, “hoàn chỉnh” hoặc “chuyên nghiệp” mà không chỉ ra evidence. Viết lại gate theo tiêu chí kiểm tra được.

Quy tắc quyết định tự rà soát: một chapter entry chỉ được xem là nhất quán nội bộ khi không còn lỗi chặn ở sáu nhóm đầu tiên và quality gate có evidence cụ thể. Nếu phát hiện mâu thuẫn, tác giả sửa entry gây mâu thuẫn hoặc dependency liên quan; không che lấp vấn đề bằng cách đổi tên canonical, bỏ prerequisite, hoặc diễn giải dữ liệu mô phỏng Nova Foods thành quyết định vận hành thực tế.

Sổ đăng ký vấn đề mở cấp chapter tại thời điểm lập Manifest

Các vấn đề dưới đây chưa thể đóng chỉ bằng lập kế hoạch manifest vì cần bằng chứng, quyết định phạm vi hoặc nội dung chi tiết từ artifact phụ thuộc. Mỗi vấn đề giữ nguyên nhãn phân loại nguồn và không được chuyển thành fact, requirement Nova Foods, quy tắc pháp lý hoặc quyết định thiết kế. Dữ liệu và tình huống Nova Foods Trading & Manufacturing đều là mô phỏng giáo dục, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND.

Open Issue ID	Chapter bị ảnh hưởng	Điểm mơ hồ chưa thể giải quyết	Ranh giới quyết định tại manifest	Nhãn bắt buộc	Điều kiện đóng
OI-MAN-001	CH-00 đến CH-25	Danh mục định danh canonical có thể chứa ID được dùng minh họa xuyên chapter, như NEED-SALES-001, REQ-FUNC-SALES-012, AC-SALES-012-03 và TC-SALES-012-07, nhưng phạm vi liên kết đầy đủ của từng ID chưa được xác định trong manifest.	Manifest chỉ dành chỗ cho traceability dependency; không tự tạo, đổi nghĩa hoặc cấp thêm canonical ID.	Verification required đối với quan hệ ID chưa có trong TRACEABILITY_ID_REGISTRY.md.	TRACEABILITY_ID_REGISTRY.md xác định ID, loại artifact, nguồn gốc và liên kết hợp lệ.
OI-MAN-002	CH-11, CH-12, CH-24, CH-25	Ranh giới giữa business rule mô phỏng, project assumption và nội dung có thể chịu ảnh hưởng của thuế, kế toán, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc chưa thể xác định theo từng tình huống chapter.	Không diễn giải Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật 88/2015/QH13, Nghị định 123/2020/NĐ-CP hoặc Luật 55/2010/QH12 thành rule Nova Foods.	Verification required hoặc Project assumption, tùy nguồn của từng ví dụ.	CANONICAL_BUSINESS_RULES.md và nguồn chính thức phù hợp ghi rõ source classification, phạm vi và trạng thái xác minh.
OI-MAN-003	CH-13 đến CH-17	Mức chi tiết dữ liệu cho khách hàng, địa chỉ giao hàng, lô hàng, hạn dùng và dữ liệu nhận diện cá nhân chưa đủ để xác định mô hình dữ liệu, quyền truy cập hoặc retention minh họa.	Chapter chỉ được lập kế hoạch dùng thực thể tổng hợp và không được suy ra schema production, chính sách lưu giữ hay nghĩa vụ privacy.	Project assumption cho dữ liệu mô phỏng; Verification required cho mọi yêu cầu privacy hoặc retention.	CANONICAL_DATA_DICTIONARY.md xác định định nghĩa, phân loại và quan hệ dữ liệu được phép dùng trong corpus.
OI-MAN-004	CH-18 đến CH-21	Hợp đồng tích hợp giả định giữa ERP Nova Foods và hệ thống ngoài chưa xác định endpoint, authentication, ownership, error contract hoặc dữ liệu trao đổi.	Manifest chỉ xác định nhu cầu học phân tích integration; không công bố API contract, không suy luận chuẩn bảo mật, và không gọi sơ đồ hoạt động là BPMN.	Project assumption cho bối cảnh tích hợp mô phỏng; Verification required cho claim liên quan OAS, OWASP hoặc kiến trúc.	Artifact kiến trúc kỹ thuật hoặc API exercise được kiểm soát xác định phạm vi mô phỏng và source family áp dụng.
OI-MAN-005	CH-22, CH-23, CH-25	Bộ test basis và bằng chứng UAT chưa xác định mức bao phủ tối thiểu cho happy path, ngoại lệ, state transition, rule boundary và dữ liệu biên của từng capability.	Manifest không tự đặt pass rate, defect severity, tiêu chuẩn nghiệm thu hoặc bằng chứng production.	Project assumption cho tiêu chí học tập; Verification required nếu diễn giải thuật ngữ hoặc kỹ thuật theo ISTQB CTFL.	COMPETENCY_COVERAGE_MATRIX.md và artifact assessment liên quan xác định quan sát năng lực, evidence và tiêu chí đánh giá.
OI-MAN-006	CH-24, CH-25	Khái niệm “delivery-ready” có thể bị hiểu nhầm là sẵn sàng triển khai, tuân thủ pháp luật hoặc đã được business chấp nhận.	Trong manifest, “delivery-ready” chỉ là mức năng lực học tập: pack mô phỏng nhất quán, có traceability và nêu rõ điểm chưa xác minh.	Verification required cho mọi kết luận compliance, production readiness hoặc acceptance thực tế.	Nội dung chapter định nghĩa rõ evidence học tập, explicit exclusions và giới hạn thẩm quyền theo curriculum architecture.

Quy tắc xử lý vấn đề mở: Một vấn đề chỉ được đóng khi artifact phụ thuộc cung cấp căn cứ truy vết được; việc tác giả chọn một ví dụ, hoàn thành một bảng manifest hoặc tiếp tục drafting không phải căn cứ đóng vấn đề. Trong khi còn mở, chapter liên quan phải bảo toàn canonical ID, filename chuẩn và source classification; mọi nội dung chưa xác minh tiếp tục được ghi là Verification required hoặc Project assumption phù hợp.

Nhu cầu Escalation và Tuyến Chuyển Cấp Theo Vai Trò

Escalation được tạo khi người lập manifest không có thẩm quyền, bằng chứng chưa đủ, hoặc một quyết định có thể làm thay đổi phạm vi, trình tự học, nguồn chân lý, tính khả thi kỹ thuật, khả năng kiểm thử, nghĩa vụ pháp lý hoặc cách mô phỏng Nova Foods Trading & Manufacturing. Escalation không phải là yêu cầu phê duyệt và không cho phép tự đóng điểm chưa rõ. Nội dung chưa được quyết định vẫn phải giữ nhãn Project assumption hoặc Verification required phù hợp.

Vai trò nhận escalation	Chuyển cấp khi	Câu hỏi quyết định tối thiểu	Bằng chứng/đầu vào phải kèm
Senior BA	Một chapter chưa phân định được ranh giới giữa need, requirement, business rule, acceptance criterion, process hoặc test basis; hoặc traceability dependency tạo vòng lặp, đứt chuỗi hay trùng nguồn chân lý.	Artifact nào là nguồn chính cho khái niệm hoặc ID? Quan hệ truy vết nào phải được giữ giữa các chapter?	Chapter ID, filename chuẩn, field bị ảnh hưởng, ID liên quan như NEED-SALES-001, REQ-FUNC-SALES-012, AC-SALES-012-03, source classification và tác động tới learner progression.
Curriculum Owner	Đề xuất làm đổi mục tiêu năng lực, cấp độ chapter, thứ tự 00–25, vai trò độc lập của chapter, hoặc phạm vi của handbook so với template library.	Thay đổi có làm lệch kiến trúc 26 chapter, competency coverage hoặc capability gate không? Có cần điều chỉnh curriculum architecture trước khi drafting không?	Chapter ID, filename, mô tả xung đột với /01-curriculum/01_CURRICULUM_ARCHITECTURE.md, capability bị tác động và phương án giữ nguyên hoặc điều chỉnh.
Technical Architect	Chapter nêu integration, API, data model, security boundary, performance, deployment, event flow hoặc quyết định kỹ thuật mà BA không thể tự giả định.	Ràng buộc kỹ thuật nào là fact, assumption hay cần xác minh? Quyết định nào thuộc kiến trúc thay vì nội dung đào tạo?	Diagram type dự kiến, interface hoặc data entity liên quan, tham chiếu OpenAPI/OAS, UML, OWASP khi phù hợp; không suy diễn cấu hình hoặc kiểm soát production.
QA Reviewer	Quality gate, acceptance criterion, traceability tới test case, hoặc tiêu chí đánh giá learner không thể quan sát, không kiểm thử, mâu thuẫn hoặc thiếu test basis.	Điều kiện nào chứng minh được bằng evidence? Liên kết requirement → acceptance criterion → test evidence có đủ để kiểm tra không?	Requirement/rule/acceptance ID, expected observable result, exception boundary, test artifact dự kiến và tham chiếu ISTQB CTFL khi dùng thuật ngữ kiểm thử.
Legal/Compliance Owner	Nội dung có thể được hiểu là nghĩa vụ về dữ liệu cá nhân, kế toán, hóa đơn/chứng từ, thuế, an toàn thực phẩm, truy xuất nguồn gốc, lưu giữ dữ liệu hoặc trách nhiệm pháp lý.	Quy định có áp dụng cho tình huống mô phỏng không? Diễn giải nào được phép dùng trong curriculum và nội dung nào phải giữ Verification required?	Phát biểu đang tranh luận, luật hoặc nguồn chính thức liên quan, source classification, phạm vi Nova Foods mô phỏng và rủi ro nếu diễn giải sai. Không được nêu điều khoản cụ thể nếu chưa kiểm tra văn bản được cấp phép hoặc nguồn chính thức hiện hành.
Business Owner	Scenario Nova Foods, thuật ngữ vận hành, quyền quyết định, ngoại lệ nghiệp vụ, ưu tiên quy trình, lô hàng, hạn dùng, tồn kho, đơn hàng hoặc mục tiêu kinh doanh không có owner xác nhận.	Quy trình nào cần được mô phỏng cho mục đích học tập? Ai sở hữu quyết định nghiệp vụ và tiêu chí thành công nào phản ánh đúng bối cảnh?	Chapter ID, Nova Foods scenario bị ảnh hưởng, giả định hiện tại, các lựa chọn nghiệp vụ, tác động đến artifact dự kiến và câu hỏi quyết định đơn nghĩa.

Mỗi escalation record phải xác định: artifact bị ảnh hưởng là /01-curriculum/CHAPTER_MANIFEST.md; chapter ID và filename chuẩn nếu đã được phân bổ; field manifest liên quan; fact đã biết; Project assumption hoặc Verification required; câu hỏi cần quyết định; vai trò nhận; tác động nếu trì hoãn; và dependency bị ảnh hưởng. Record không được thay thế bằng nhận định của tác giả, không được tạo trích dẫn hay xác nhận giả định, và không được chuyển một quyết định chuyên môn thành quyết định pháp lý hoặc kỹ thuật.

Xác nhận cuối cùng về trạng thái lập kế hoạch và giới hạn hiệu lực

/01-curriculum/CHAPTER_MANIFEST.md tại ngày 2026-08-07, phiên bản v0.9.0, múi giờ Asia/Ho_Chi_Minh, locale vi-VN, bối cảnh Việt Nam và dữ liệu mô phỏng Nova Foods Trading & Manufacturing, là artifact lập kế hoạch phục vụ việc tổ chức 26 chapter trước khi soạn thảo nội dung handbook. Trạng thái kiểm soát hiện hành và duy nhất là IN_REVIEW.

Nội dung được xác nhận	Diễn giải kiểm soát bắt buộc
Mục đích artifact	Manifest xác định kế hoạch danh mục chapter, không phải nội dung chapter hoàn chỉnh, requirement triển khai, quyết định vận hành hoặc hướng dẫn production.
Trạng thái	IN_REVIEW cho biết nội dung đang được xem xét có kiểm soát và vẫn có thể thay đổi theo cơ chế quản trị artifact.
Baseline	Không có baseline reference tại v0.9.0; không được gọi manifest, chapter entry, filename, dependency hoặc quyết định trong manifest là baseline.
Approval	Không có approval reference được ghi nhận. Sự tồn tại của manifest, metadata, bảng, ID, vai trò Owner hoặc nội dung review không tạo ra approval ngầm định từ Senior BA, curriculum owner, technical architect, QA reviewer, legal/compliance owner, business owner hoặc bất kỳ vai trò nào khác.
Phạm vi Nova Foods	Mọi tên tổ chức, quy trình, ID, ví dụ và dữ liệu Nova Foods là mô phỏng giáo dục, dữ liệu tổng hợp; không chứng minh cấu hình ERP thực tế, quyết định nghiệp vụ thực tế hoặc tính tuân thủ.
Nội dung nhạy cảm thẩm quyền	Nội dung về pháp lý, thuế, kế toán, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc và bảo mật vẫn phải được phân loại phù hợp là Project assumption hoặc Verification required khi chưa có xác minh có thẩm quyền.

Quy tắc diễn giải: không được suy ra rằng việc hoàn tất kiểm tra manifest, sự ổn định tạm thời của tên tệp từ 00-foundations.md đến 25-ai-assisted-ba-workflow.md, hay việc chuẩn bị cho drafting đã biến nội dung thành baseline hoặc nội dung được phê duyệt. Mọi thay đổi sau thời điểm này vẫn phải được ghi nhận có truy vết theo quản trị artifact áp dụng. Manifest chỉ có thể được dùng như đầu vào lập kế hoạch cho hoạt động review và drafting tiếp theo; không được dùng làm bằng chứng chấp thuận, cam kết pháp lý, quyết định kiến trúc, quyết định kế toán hoặc xác nhận sẵn sàng triển khai.