H1 Title and Artifact Governance Metadata

H1 title của tài liệu: /00-research/00_SOURCE_MAP.md — Phase 1 Source Map for IT BUSINESS ANALYST — ZERO TO DELIVERY READY

Artifact Governance Metadata

Trường kiểm soát	Giá trị
Artifact ID	00_SOURCE_MAP
Tên tệp	/00-research/00_SOURCE_MAP.md
Tiêu đề	Phase 1 Source Map for IT BUSINESS ANALYST — ZERO TO DELIVERY READY
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Owner	Principal IT Business Analyst / Technical Curriculum Author
Owner role	Principal IT Business Analyst / Technical Curriculum Author
Owner accountability	Owner chịu trách nhiệm cuối cùng trong phạm vi biên tập của artifact: điều phối phạm vi Phase 1, duy trì tính toàn vẹn quản trị, quản lý phiên bản, ghi nhận lịch sử thay đổi, kiểm soát định danh heading và bảo đảm mọi nguồn được gắn nhãn xác minh phù hợp.
Owner authority	Owner được quản lý và cập nhật Source Map trong phạm vi biên tập, phân loại nguồn, ghi nhận trạng thái xác minh và đề xuất thay đổi. Owner không được tự phê duyệt baseline, xác nhận thẩm quyền pháp lý, xác nhận kết luận kế toán hoặc thay thế quyết định của chuyên gia có thẩm quyền.
Owner responsibilities	Owner phải ghi nhận minh bạch mọi thay đổi, duy trì stable ID và ranh giới nguồn, kiểm soát tính nhất quán giữa Source Map với chapter, template, glossary, cheatsheet và QA reporting needs. Owner không được sửa im lặng artifact đã được baseline trong tương lai.
Review responsibility	Người review có thẩm quyền phải kiểm tra các nội dung pháp lý, kế toán, nghiệp vụ chuyên ngành, an ninh và các claim cần xác minh trực tiếp trước khi sử dụng trong handbook. Việc review không được suy diễn thành phê duyệt baseline nếu chưa có ghi nhận phê duyệt riêng.
Approval authority	Chưa xác định người hoặc vai trò phê duyệt baseline trong artifact này. Không có phê duyệt baseline từ người dùng hoặc vai trò có thẩm quyền được ghi nhận tại thời điểm hiện tại.
Escalation boundary	Owner phải chuyển nội dung vượt phạm vi biên tập, gồm diễn giải pháp lý, kế toán, quyền riêng tư, an toàn thực phẩm, an ninh hoặc quyết định production, tới người hoặc vai trò có thẩm quyền trước khi nội dung được dùng như kết luận hoặc yêu cầu bắt buộc.
Giới hạn thẩm quyền của Owner	Việc chỉ định Owner không cấu thành phê duyệt nội dung, phê duyệt baseline, thẩm quyền pháp lý, thẩm quyền kế toán, thẩm quyền quyết định nghiệp vụ hoặc quyền truy cập và quyết định production.
Last updated date	2026-08-07
Phạm vi pha	Chỉ Phase 1 — Research & Source Mapping
Ngôn ngữ nội dung	Tiếng Việt; giữ nguyên tên chính thức bằng tiếng Anh của tiêu chuẩn, đặc tả và tổ chức phát hành khi phù hợp
Phạm vi pháp lý mặc định của case study	Việt Nam
Case study áp dụng	Nova Foods Trading & Manufacturing — mô phỏng giáo dục
Trạng thái baseline	Chưa được baseline
Trạng thái phê duyệt	Chưa có phê duyệt baseline từ người dùng hoặc vai trò có thẩm quyền
Cơ chế thay đổi sau baseline	Chỉ được thay đổi thông qua Change Request được phê duyệt theo quy ước CR-{DOMAIN}-{NNN}

01.00 Phạm vi Phase 1 và trạng thái lập kế hoạch của Source Map

Tài liệu này là source map của Phase 1 cho handbook và template library IT BUSINESS ANALYST — ZERO TO DELIVERY READY. Mục tiêu của artifact là lập danh mục có kiểm soát các nguồn sơ cấp, nguồn chính thức, nguồn thực hành ngành, project convention và author recommendation sẽ được sử dụng hoặc xem xét trong các phase sau.

Phạm vi của artifact này chỉ giới hạn ở Research & Source Mapping. Artifact không tạo, phê duyệt hoặc baseline requirement, business rule, thiết kế giải pháp, cấu hình hệ thống, API, dữ liệu production hoặc quyết định triển khai cho Nova Foods.

Artifact này được lập kế hoạch trước khi soạn thảo catalog nguồn chi tiết. Phiên bản hiện tại thiết lập danh tính tài liệu, trạng thái kiểm soát, ownership, phạm vi Phase 1, nguyên tắc quản trị nguồn và lịch sử thay đổi trước khi các mục nguồn được đưa vào các section catalog tiếp theo.

Nova Foods Co., Ltd., mọi nhân sự, giao dịch, số liệu, quy tắc vận hành và quyết định trong handbook đều là mô phỏng giáo dục. Không được trình bày chúng như dữ kiện của một doanh nghiệp có thật.

01.01 Giới hạn tuyên bố của Artifact Source Map

Source map này không phải là:

• Bản diễn giải pháp lý, kế toán, thuế, lao động, quyền riêng tư hoặc an toàn thực phẩm.
• Bằng chứng rằng một requirement sản phẩm cụ thể đã tuân thủ pháp luật hoặc tiêu chuẩn.
• Bản thay thế cho việc đọc văn bản gốc được cấp phép khi tiêu chuẩn hoặc tài liệu chỉ cho phép truy cập hạn chế.
• Bản phê duyệt kiến trúc, bảo mật, API, quy trình vận hành hoặc triển khai production cho Nova Foods.
• Bản xác nhận rằng mọi nội dung của handbook đã được soạn thảo, rà soát hoặc baselined.

01.02 Lịch sử thay đổi của Artifact Source Map

Phiên bản	Ngày cập nhật	Trạng thái	Owner	Mô tả thay đổi	Tác động đến baseline
v0.9.0	2026-08-07	IN_REVIEW	Principal IT Business Analyst / Technical Curriculum Author	Khởi tạo cấu trúc quản trị cho /00-research/00_SOURCE_MAP.md; xác định H1 title, Owner, phạm vi chỉ thuộc Phase 1, trạng thái kiểm soát, giới hạn tuyên bố, quy ước định danh heading duy nhất và nguyên tắc không tự nhận phê duyệt.	Không có baseline để tác động.

01.03 Tình trạng phê duyệt và kiểm soát baseline của Source Map

Chưa có baseline approval được cấp cho artifact này. Vì vậy:

• IN_REVIEW không đồng nghĩa với BASELINED.
• Không cá nhân, vai trò hoặc tổ chức nào được ngầm hiểu là đã phê duyệt nội dung source map.
• Phiên bản v0.9.0 chỉ là bản kiểm soát để review trước khi baseline.
• Không được tuyên bố rằng Owner đã phê duyệt nội dung chỉ vì Owner được chỉ định trong metadata.
• Khi người dùng hoặc vai trò có thẩm quyền phê duyệt baseline, trạng thái, phiên bản, lịch sử thay đổi và các thay đổi liên quan phải được cập nhật minh bạch; không được sửa im lặng nội dung đã baselined.

01.04 Quy ước định danh heading và chống trùng lặp trong Source Map

Mỗi heading cấp hai và cấp ba trong /00-research/00_SOURCE_MAP.md phải có số section duy nhất và văn bản hiển thị duy nhất trong cùng cấp heading. Số section phải phản ánh vị trí thực tế trong cấu trúc tài liệu; không được tái sử dụng ký hiệu minh họa như 02.xx trong heading được tạo thực tế.

Đối với catalog nguồn, heading cấp hai phải xác định nhóm nguồn và heading cấp ba phải xác định rõ từng nguồn hoặc chính sách áp dụng cho nguồn đó. Khi cần nêu một chủ đề tương tự dưới nhiều mục nguồn, heading phải bao gồm phạm vi hoặc Source ID để không trùng lặp.

Các chủ đề có nguy cơ trùng heading phải áp dụng quy ước đặt tên phân biệt sau:

Chủ đề nội dung	Quy ước heading duy nhất phải áp dụng khi được tạo trong catalog hoặc chính sách nguồn
Quản trị nội dung cho handbook	Dùng heading có Source ID hoặc nhóm nguồn, ví dụ 02.03 Chính sách quản trị nội dung handbook cho SRC-STD-ISTQB-001; hoặc hợp nhất chính sách dùng chung vào một section duy nhất.
Ghi chú xác minh và sử dụng an toàn	Dùng heading có Source ID hoặc phạm vi sử dụng, ví dụ 02.04 Ghi chú xác minh và sử dụng an toàn cho SRC-STD-OAS-001.
Quy tắc xác minh và gắn nhãn bắt buộc	Dùng một heading chính sách dùng chung duy nhất, ví dụ 04.01 Quy tắc kiểm soát xác minh và nhãn phân loại nguồn pháp lý; các mục nguồn pháp lý chỉ được tham chiếu đến section này thay vì lặp lại heading.
Ranh giới sử dụng an toàn trong handbook	Dùng heading có nguồn hoặc phạm vi phân biệt, ví dụ 02.05 Ranh giới sử dụng an toàn của BABOK Guide trong handbook và 02.06 Ranh giới sử dụng an toàn của ISO/IEC/IEEE 29148 trong handbook.
Ranh giới sử dụng trong case study Nova Foods	Dùng một heading cấp hai dùng chung duy nhất, ví dụ 05.01 Ranh giới áp dụng nguồn cho case study Nova Foods mô phỏng; các nguồn liên quan chỉ được tham chiếu đến section này.

Không được tạo hai heading cùng cấp có cùng văn bản hiển thị, kể cả khi nội dung bên dưới khác nhau hoặc heading nằm dưới các Source ID khác nhau. Nếu một chủ đề cần mở rộng, nội dung phải được hợp nhất vào section hiện có hoặc được đổi tên để nêu rõ nguồn, phạm vi, đối tượng sử dụng hoặc chức năng kiểm soát khác biệt.

Quy ước này không thay đổi ý nghĩa nội dung của các chính sách nguồn. Quy ước chỉ bảo đảm cấu trúc tài liệu có thể được tham chiếu, kiểm tra và cập nhật chính xác trong quá trình review Phase 1.

Source Catalog Method, Classification Rules, and Verification Protocol

/00-research/00_SOURCE_MAP.md is a controlled research artifact with Status: IN_REVIEW and Version: v0.9.0. Every source entry must be sufficient to show what was checked, what may safely be taught, and what still requires specialist verification.

Catalog field schema

Field	Required rule
Source ID	Unique internal identifier, for example SRC-STD-BABOK-001. It does not replace the official source title.
Title	Exact official title; Vietnamese explanation may be added in parentheses.
Issuer	Official issuing organization or Vietnamese competent authority, not a reseller, blog, or reposting party.
Edition / Version / Status	Edition, version, document number, publication or effective status only where verified. Do not infer amendment, replacement, or legal validity.
Stable URL	Official, stable issuer or government URL; never a shortened link, search result, or unofficial copy.
Access Date	ISO format YYYY-MM-DD. For the verified primary-source seed, use 2026-08-07.
Authority Classification	Exactly one of: Normative standard, Official Vietnamese law, Industry good practice, Project convention, or Author recommendation.
Intended Curriculum Use	Specific handbook chapters, template families, and learner capability supported by the source. Do not write “whole handbook”.
Verification Status	Exactly one of: Verified, Verification required, or Limited-use caution.
Licensing / Access Caveat	State paywall, licence, abstract-only access, restricted access, or the inspected scope.
Claims That Must Not Be Made	State prohibited claims, especially unverified clauses, page numbers, quotations, legal duties, certification, compliance, or production readiness.

A source may support several chapters or templates, but it has one primary authority classification and one current verification status.

Authority classification rules

Classification	Meaning and permitted use	Must not be claimed
Normative standard	Official technical standard, specification, or recommendation, such as OMG BPMN 2.0.2, OMG UML 2.5.1, OpenAPI Specification 3.1.1, WCAG 2.2, or ISO/IEC/IEEE 29148:2018 where the relevant content is verified. Use for notation, semantics, structure, and technical description within the inspected scope.	That Nova Foods is certified, fully compliant, legally required to implement the source, or production-ready because the source is referenced. PlantUML Activity Diagrams must not be called BPMN.
Official Vietnamese law	Official Vietnamese legal text published by a competent authority, including the listed laws and decrees on personal data protection, accounting, invoices, and food safety. Use to identify compliance context, risks, dependencies, and required escalation.	Final legal interpretation, a definitive obligation for Nova Foods, or confirmation that a design, API, process, record, or configuration is lawful without authorized review.
Industry good practice	Professional guidance, syllabus, framework, or security practice, such as BABOK Guide, ISTQB CTFL, OWASP ASVS, and OWASP API Security Top 10. Use for learning methods, terminology, quality criteria, and risk awareness.	That the practice is Vietnamese law, mandatory for every project, or sufficient to prove security, quality, or compliance.
Project convention	Corpus-specific rules for the Nova Foods simulation, including identifier patterns, vi-VN, Asia/Ho_Chi_Minh, VND, Mermaid and PlantUML usage, and traceability conventions.	That the convention originates from BABOK, ISO, OMG, OWASP, or Vietnamese law.
Author recommendation	Explicit educational heuristic or governance recommendation, such as escalating unresolved approval authority or using a quality gate before UAT.	That it is a law, formal standard, certification condition, or universally applicable rule.

When one artifact combines several kinds of content, each claim must retain its real classification. A project convention must not be presented as a standard requirement, and a good practice must not be promoted to a legal duty.

Verification and access protocol

Status	Assign when	Permitted use	Required limitation
Verified	The official URL, issuer, title, version or status, and the specific content needed for the claim were directly inspected.	Careful explanation of the inspected content, with its authority classification.	Do not infer broader requirements, compliance, certification, legality, security, or production approval.
Verification required	The source, its effective status, amendment history, applicability, or relevant content has not been sufficiently checked; or the claim needs legal, accounting, tax, labor, privacy, food-safety, traceability, or domain authority review.	Identify a risk, dependency, research question, or escalation need.	Do not create a mandatory compliance requirement, business rule, acceptance criterion, architecture decision, or production claim from it.
Limited-use caution	Only metadata, an overview, abstract, errata, or other incomplete public material is available; or the full text is paywalled or access-restricted.	Use only the directly visible bibliographic facts and high-level scope.	Do not cite detailed clauses, pages, definitions, exceptions, tables, figures, or quotations. Convert detailed claims to Verification required.

For a paywalled, abstract-only, or uninspected source, the existence of an official URL does not prove that a detailed claim has been verified. The source may remain in the catalog, but its curriculum use must remain within the visible and inspected evidence.

No clause, article, paragraph, point, page number, table, figure, version status, effective date, or quotation may be invented, guessed, reconstructed from memory, or copied from an unverified secondary summary. If the exact text cannot be checked, either:

1. make only a high-level statement supported by the inspected material;
2. label the matter Verification required; or
3. use a clearly labeled Project assumption for the Nova Foods educational simulation.

High-risk domain boundary

Any unverified detail concerning tax, accounting, labor, privacy, personal-data protection, food safety, food traceability, invoices, records, or retention must be labeled as follows:

Evidence condition	Required label and handling
Synthetic fact used only to teach analysis, modelling, testing, or traceability	Project assumption; it must not be described as a real legal, accounting, or operational obligation.
Official source exists but applicability, detailed requirement, amendment status, or interpretation has not been verified	Verification required; identify the owner who must review before baseline or production use.
Official text has been inspected but applicability to Nova Foods requires professional judgment	State the relevant Official Vietnamese law context and require review by the appropriate legal, accounting, tax, privacy, food-safety, or domain owner.

For example, a simulated rule that refund amounts use integer VND with a minimum increment of 1 VND is a Project assumption unless an applicable authorized requirement establishes otherwise. It is not automatically an accounting, tax, or legal rule.

Intended curriculum use mapping

Intended Curriculum Use is the source-to-curriculum control point. Each entry must identify:

1. Primary chapters where the source is taught or applied;
2. Secondary chapters where it provides supporting context;
3. Template families that operationalize the source; and
4. Learner capability enabled by that use.

Source family	Typical handbook use	Typical template use	Learner capability
BABOK Guide	BA foundations, discovery, elicitation, stakeholder analysis, requirements, governance	BRD, stakeholder map, requirement catalogue, traceability matrix, change log	Perform structured BA work and distinguish needs, requirements, stakeholders, and decisions.
ISO/IEC/IEEE 29148	Requirement quality, specification, validation, traceability, change control	Requirement review checklist, SRS structure, quality gate	Assess whether a requirement is clear, testable, and controlled.
OMG BPMN and UML	Process, domain, state, interaction, and model semantics	Process model, domain model, state model, use-case specification	Select and interpret appropriate modelling notation.
ISTQB CTFL	Testing fundamentals, black-box techniques, defect lifecycle, UAT	Test condition, scenario, case, data sheet, defect log	Derive test coverage from needs, requirements, rules, and acceptance criteria.
OpenAPI Specification	API contract, request and response modelling, integration boundaries	API catalogue, endpoint specification, API test checklist	Specify and review an API contract without inventing implementation details.
WCAG and OWASP sources	Accessibility, security-aware requirements, API risk analysis	Accessibility checklist, security requirement checklist, API risk checklist	Recognize quality and risk questions requiring technical review.
Official Vietnamese law	Compliance discovery, risk boundaries, dependencies, escalation	Privacy dependency log, accounting dependency log, traceability and recall review checklist	Identify where authorized legal, accounting, privacy, tax, or food-safety review is required.
Project conventions and author recommendations	Nova Foods simulation consistency, governance, traceability, escalation	All controlled templates where the convention applies	Produce consistent educational artifacts without mistaking simulation rules for external obligations.

A compliant Intended Curriculum Use statement is specific, for example:

“Primary chapters: requirements quality and BA testing; template families: requirement review checklist, test case, traceability matrix; learner capability: distinguish a business rule from an acceptance criterion and trace both to test coverage.”

The source catalog supports educational content governance only. It does not replace licensed source access, legal advice, accounting advice, domain authority, security approval, or production decision authority.

Normative Standards and Technical Specifications

SRC-STD-BABOK-001 — BABOK Guide

Trường	Giá trị
Source ID	SRC-STD-BABOK-001
Title	A Guide to the Business Analysis Body of Knowledge (BABOK Guide)
Issuer	International Institute of Business Analysis (IIBA)
Edition / Version / Status	Version 3; official overview and errata
Stable URL	https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/
Access Date	2026-08-07
Authority Classification	Industry good practice
Intended Curriculum Use	Primary curriculum use: các chapter về nền tảng BA, business analysis planning, stakeholder engagement, elicitation, requirement life cycle management, strategy analysis, requirement analysis và solution evaluation. Template families: BRD, stakeholder map, elicitation plan, requirement catalogue, traceability matrix, change log và requirement review checklist. Learner capability: nhận diện các nhóm hoạt động BA, phân biệt business need với requirement và solution, xác định stakeholder, tổ chức elicitation, quản lý traceability, và đánh giá kết quả giải pháp trong phạm vi dự án Nova Foods mô phỏng.
Verification Status	Limited-use caution
Licensing / Access Caveat	Trang chính thức của IIBA được dùng để xác minh sự tồn tại, issuer, Version 3, phạm vi overview và thông tin errata. Toàn văn BABOK Guide là nội dung có bản quyền và có thể yêu cầu quyền truy cập hợp lệ hoặc license tổ chức. Source map này không xác nhận rằng toàn văn đã được kiểm tra cho mọi diễn giải chi tiết.
Claims That Must Not Be Made	Không được phát minh hoặc viện dẫn số trang, số mục, số task, số technique, quotation, định nghĩa nguyên văn hoặc yêu cầu chi tiết chưa được kiểm tra từ bản được cấp phép. Không được mô tả BABOK Guide là luật Việt Nam, tiêu chuẩn pháp lý bắt buộc, hoặc bằng chứng rằng Nova Foods tuân thủ một chuẩn BA. Không được khẳng định một quy trình, template hoặc quyết định của handbook là “bắt buộc theo BABOK” nếu không có đối chiếu trực tiếp phần nội dung phù hợp. Không được suy ra rằng việc áp dụng terminology hoặc checklist lấy cảm hứng từ BABOK Guide làm hệ thống production-ready, compliant, được chứng nhận hoặc được IIBA phê duyệt.

Ranh giới sử dụng an toàn trong handbook

Phạm vi định danh riêng: SRC-STD-BABOK-001 — BABOK Guide; chính sách này chỉ áp dụng cho nguồn BABOK Guide trong phần Normative Standards and Technical Specifications, không áp dụng mặc định cho các nguồn khác có heading cùng mẫu. Việc giữ phạm vi nguồn này giúp phân biệt nội dung và tuân thủ quy tắc chống trùng lặp heading tại mục 01.04.

BABOK Guide được dùng như một nguồn Industry good practice để định hướng vocabulary, knowledge areas, task patterns và competency thinking cho người học BA. Người biên soạn có thể dùng nguồn này để giải thích ở mức tổng quát rằng công việc BA bao gồm việc hiểu nhu cầu, làm việc với stakeholder, làm rõ yêu cầu, duy trì vòng đời yêu cầu và đánh giá giải pháp. Kết quả sử dụng là nội dung đào tạo và template mang tính định hướng, không phải quy định bắt buộc.

Các chapter và template không được biến framework này thành quy định tuyệt đối cho mọi tổ chức. Người biên soạn phải ghi rõ nguồn BABOK Guide và giới hạn diễn giải khi đưa khái niệm vào handbook; người học dùng nội dung đó để tham khảo, còn tổ chức hoặc người có thẩm quyền của tổ chức quyết định quy trình thực tế. Nova Foods là case study mô phỏng; cách tổ chức artifact, identifiers, quality gates, approval flow, file structure và thứ tự học trong corpus là Project convention hoặc Author recommendation, trừ khi một mệnh đề cụ thể được xác minh trực tiếp từ nguồn phù hợp. Đánh đổi là handbook giữ được tính thực hành mà không gán thẩm quyền quy phạm cho BABOK Guide; nếu bỏ giới hạn này, người đọc có thể xem framework như yêu cầu bắt buộc và áp dụng sai ngoài phạm vi mô phỏng.

Quy tắc xác minh trước khi dùng nội dung BABOK Guide ở mức chi tiết

Nhu cầu viết nội dung	Cách xử lý bắt buộc
Chỉ cần giới thiệu BABOK Guide là body of knowledge cho BA	Có thể dùng entry này với trạng thái Limited-use caution, diễn đạt ở mức overview và nêu rõ đây là Industry good practice.
Cần mô tả chi tiết một knowledge area, task, input, output, guideline, technique hoặc competency	Phải kiểm tra trực tiếp bản BABOK Guide Version 3 được truy cập hợp lệ cho đúng mệnh đề cần viết. Nếu chưa kiểm tra được, gắn Verification required hoặc chuyển nội dung thành mô tả thực hành của tác giả, không gán trực tiếp cho BABOK Guide.
Cần dùng thuật ngữ hoặc định nghĩa	Người biên soạn phải kiểm tra cách dùng trong bản được cấp phép, ghi rõ nguồn khi cần, và không đặt nội dung diễn giải trong dấu ngoặc kép nếu không có quotation đã được xác minh.
Cần đưa số trang, số mục, số task hoặc citation chi tiết	Chỉ được đưa sau khi kiểm tra trực tiếp bản được cấp phép và bảo đảm citation khớp với mệnh đề. Nếu chưa kiểm tra, không đưa định danh chi tiết đó.
Cần chuyển nội dung thành template, checklist hoặc quality gate	Phải tách rõ phần lấy cảm hứng từ BABOK Guide với phần Project convention hoặc Author recommendation. Actor phê duyệt quy trình thực tế là người có thẩm quyền của tổ chức, không phải Source Map.
Cần dùng nội dung cho Nova Foods	Người biên soạn phải ghi rõ Nova Foods là mô phỏng, xác định artifact và outcome mong muốn, đồng thời không tuyên bố rằng case study đã tuân thủ BABOK Guide hoặc được IIBA xác nhận.
Cần đưa claim vào chapter đã phát hành	Reviewer nội dung phải đối chiếu claim với source record, kiểm tra trạng thái truy cập và ghi nhận kết quả review. Claim chưa đối chiếu phải giữ nhãn Verification required; không được trình bày như kết luận đã xác minh.
Nguồn chính thức chỉ cung cấp overview hoặc errata	Chỉ dùng phần đã được xác minh từ overview và errata. Không suy rộng từ sự tồn tại của trang chính thức thành bằng chứng đã kiểm tra toàn bộ nội dung Version 3.
Không còn quyền truy cập bản phù hợp	Giữ trạng thái Limited-use caution, loại bỏ diễn giải chi tiết chưa xác minh hoặc chuyển thành hướng dẫn nội bộ có nhãn phù hợp. Không tái tạo nội dung có bản quyền từ trí nhớ hoặc nguồn không kiểm soát.

Phân định trách nhiệm: người biên soạn chịu trách nhiệm mô tả đúng phạm vi claim; reviewer chịu trách nhiệm kiểm tra claim và nhãn nguồn; người có thẩm quyền của tổ chức chịu trách nhiệm quyết định quy trình, approval flow và mức áp dụng thực tế. Source Map chỉ cung cấp kiểm soát nguồn và ranh giới sử dụng, không thay thế review nghiệp vụ, pháp lý, bảo mật hoặc quản trị tổ chức.

Kết quả kiểm soát: khi claim overview đã được xác minh, handbook có thể dùng BABOK Guide để định hướng học tập và tạo template tham khảo. Khi claim chi tiết chưa được xác minh, artifact phải giữ Verification required hoặc dùng phân loại Project convention hay Author recommendation với actor, action, object, outcome và authority được ghi rõ. Artifact vẫn giữ trạng thái IN_REVIEW; việc có source record không phải approval, baseline hoặc chứng nhận của IIBA.

i dung thành Author recommendation. | | Cần nêu số trang, số mục, quotation hoặc diễn giải nguyên văn | Chỉ được thực hiện sau khi đối chiếu trực tiếp đúng edition, đúng bản tài liệu và đúng vị trí trích dẫn. | | Cần dùng BABOK Guide để quyết định quy trình Nova Foods | Dùng như input tham khảo; quyết định cụ thể vẫn phải có business owner, Senior BA, PM hoặc authority phù hợp xác nhận theo governance của dự án mô phỏng. | | Cần khẳng định một artifact đáp ứng chuẩn hoặc đủ điều kiện production | Không được suy ra từ việc tham chiếu BABOK Guide. Cần quality gate, review được ghi nhận, approval phù hợp và các bằng chứng độc lập liên quan. |

Giới hạn giáo dục: BABOK Guide hỗ trợ cấu trúc tư duy và thực hành BA. Nó không thay thế kinh nghiệm dự án có giám sát, domain authority, tư vấn pháp lý, thẩm quyền kế toán, quyết định kiến trúc hoặc quyền phê duyệt production.

SRC-STD-ISO29148-001 — ISO/IEC/IEEE 29148:2018 Requirements Engineering

Trường	Giá trị
Source ID	SRC-STD-ISO29148-001
Title	ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life cycle processes — Requirements engineering
Issuer	International Organization for Standardization (ISO), International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers (IEEE)
Edition / Version / Status	ISO/IEC/IEEE 29148:2018, Edition 2. Trang thư mục ISO ghi nhận tiêu chuẩn được xác nhận vào năm 2024 và được đánh dấu sẽ được sửa đổi trong năm 2026.
Stable URL	https://www.iso.org/standard/72089.html
Access Date	2026-08-07
Authority Classification	Normative standard
Intended Curriculum Use	Primary curriculum use: các chapter về business need, stakeholder requirement, system requirement, chất lượng requirement, requirement attributes, acceptance criteria, traceability, baseline, change control, verification và validation. Template families: business requirement document, requirement catalogue, business rule catalogue, acceptance-criteria register, traceability matrix, requirement review checklist, change request và impact-analysis log. Learner capability: phân biệt loại requirement, viết requirement có thể kiểm tra, xác định thuộc tính quản trị requirement, liên kết need → requirement → acceptance criteria → test case, và nhận biết khi một thay đổi cần phân tích tác động hoặc escalation.
Verification Status	Limited-use caution
Licensing / Access Caveat	Trang ISO chính thức được dùng để xác minh title, issuer, mã tiêu chuẩn, edition, năm phát hành và trạng thái thư mục. Toàn văn ISO/IEC/IEEE 29148:2018 là tài liệu có bản quyền và thường yêu cầu quyền truy cập hoặc license hợp lệ. Source map này không xác nhận việc đã kiểm tra toàn văn, các điều khoản chi tiết, phụ lục, bảng biểu hoặc diễn giải normative language của tiêu chuẩn.
Claims That Must Not Be Made	Không được phát minh hoặc trích dẫn số điều, số mục, số trang, bảng, phụ lục, định nghĩa nguyên văn, từ khóa normative như “shall”, hoặc quotation từ ISO/IEC/IEEE 29148:2018 khi chưa đối chiếu trực tiếp bản được cấp phép. Không được khẳng định rằng một requirement, template, quy trình, quality gate hoặc corpus Nova Foods “tuân thủ ISO/IEC/IEEE 29148” chỉ vì có cấu trúc tương tự hoặc được lấy cảm hứng từ tiêu chuẩn. Không được trình bày tiêu chuẩn này là luật Việt Nam, nghĩa vụ pháp lý tự động, chứng nhận, hoặc sự thay thế cho phê duyệt của business owner, Senior BA, PM, Architect, QA lead hoặc authority có thẩm quyền. Không được suy ra rằng status “confirmed 2024” đồng nghĩa mọi nội dung vẫn phù hợp với bản sửa đổi dự kiến năm 2026 hoặc các bối cảnh pháp lý, ngành nghề và dự án cụ thể.

Ranh giới sử dụng an toàn trong handbook

ISO/IEC/IEEE 29148:2018 là Normative standard về requirements engineering. Handbook có thể dựa vào thông tin thư mục chính thức và hiểu biết đã được xác minh hợp lệ để định hướng cách tổ chức nội dung về vòng đời requirement, đặc tính chất lượng, quản trị thay đổi, traceability, verification và validation.

Trong Nova Foods, cấu trúc ID như NEED-SALES-001, REQ-FUNC-SALES-012, AC-SALES-012-03 và TC-SALES-012-07; các trạng thái artifact; quality gate; approval workflow; và cách phân chia chapter là Project convention hoặc Author recommendation. Các cấu phần này không được gọi là yêu cầu nguyên văn của ISO/IEC/IEEE 29148:2018 nếu chưa kiểm tra trực tiếp đúng điều khoản trong toàn văn có license hợp lệ.

Quy tắc xác minh trước khi dùng nội dung ISO/IEC/IEEE 29148:2018 ở mức chi tiết

Nhu cầu viết nội dung	Cách xử lý bắt buộc
Giới thiệu tiêu chuẩn là nguồn normative cho requirements engineering	Có thể dùng entry này, nêu rõ mã tiêu chuẩn, edition và giới hạn rằng handbook chỉ xác minh thông tin thư mục cùng abstract công khai khi áp dụng.
Giải thích tổng quát rằng requirement cần rõ ràng, có thể quản lý và có thể kiểm tra	Có thể diễn đạt như Industry good practice hoặc Author recommendation nếu chưa đối chiếu trực tiếp toàn văn; không gán các đặc tính, tên thuộc tính hoặc wording cụ thể cho ISO/IEC/IEEE 29148:2018.
Liệt kê đặc tính requirement, loại requirement, lifecycle process, information item, activity, input, output hoặc quality criterion như nội dung của tiêu chuẩn	Phải kiểm tra trực tiếp bản ISO/IEC/IEEE 29148:2018 được truy cập hợp lệ và ghi lại bằng chứng trích dẫn chính xác trong artifact phù hợp. Nếu chưa kiểm tra được, gắn Verification required hoặc trình bày rõ là Author recommendation.
Dẫn số điều, số trang, bảng, phụ lục hoặc quotation	Chỉ được thực hiện sau khi đối chiếu trực tiếp đúng Edition 2, đúng vị trí và đúng ngữ cảnh của bản tài liệu được cấp phép.
Đánh giá một BRD, SRS, backlog, traceability matrix hoặc test package là compliant với tiêu chuẩn	Không được kết luận chỉ từ source map hoặc review nội bộ. Cần tiêu chí đánh giá đã được xác minh, bằng chứng kiểm tra artifact và phê duyệt của authority phù hợp.
Dùng tiêu chuẩn để quyết định requirement cho Nova Foods	Xem tiêu chuẩn là input về phương pháp. Quyết định về scope, priority, rule, data, workflow, security, legal compliance, accounting hoặc production release vẫn cần authority phù hợp của dự án mô phỏng xác nhận.

Giới hạn về claim điều khoản: Không có số clause, page number, quotation hoặc diễn giải chi tiết nào của ISO/IEC/IEEE 29148:2018 được suy ra từ trang thư mục ISO. Mọi claim ở mức điều khoản phải ở trạng thái Verification required cho đến khi được đối chiếu với toàn văn được cấp phép.

Giới hạn giáo dục: Việc học và áp dụng các thực hành requirements engineering lấy cảm hứng từ ISO/IEC/IEEE 29148:2018 không thay thế kinh nghiệm delivery có giám sát, phê duyệt dự án, tư vấn pháp lý, thẩm quyền kế toán, domain authority hoặc quyền truy cập production.

SRC-STD-BPMN-001 — Business Process Model and Notation (BPMN) Version 2.0.2

Trường	Giá trị
Source ID	SRC-STD-BPMN-001
Title	Business Process Model and Notation (BPMN), Version 2.0.2
Issuer	Object Management Group (OMG)
Edition / Version / Status	BPMN 2.0.2
Stable URL	https://www.omg.org/spec/BPMN/2.0.2/About-BPMN/
Access Date	2026-08-07
Authority Classification	Normative standard
Intended Curriculum Use	Primary curriculum use: các chapter về discovery, AS-IS/TO-BE process analysis, stakeholder handoff, workflow, exception flow, approval flow, process boundary, process improvement và process validation. Template families: process inventory, process scope statement, AS-IS workflow, TO-BE workflow, gap analysis, workflow requirement catalogue, approval matrix, exception register và process-review checklist. Learner capability: xác định phạm vi một quy trình, phân biệt hoạt động, sự kiện, gateway, luồng tuần tự, message flow, participant và lane khi thực sự mô hình hóa bằng BPMN; dùng mô hình quy trình để phát hiện handoff, decision point, ngoại lệ, kiểm soát và requirement còn thiếu.
Verification Status	Verified
Licensing / Access Caveat	Trang OMG chính thức được dùng để xác minh title, issuer, phiên bản BPMN 2.0.2 và URL nguồn. Việc sử dụng, sao chép, diễn giải chi tiết hoặc trích dẫn nội dung specification phải tuân theo điều kiện bản quyền, license và quyền truy cập do OMG công bố. Source map này không xác nhận rằng toàn bộ specification, các điều khoản chi tiết, phụ lục, sơ đồ ví dụ hoặc conformance requirement đã được kiểm tra.
Claims That Must Not Be Made	Không được gọi bất kỳ sơ đồ nào là “BPMN” nếu sơ đồ đó không sử dụng BPMN notation và semantics thực tế. Đặc biệt, PlantUML Activity Diagram có swimlane là UML Activity Diagram, không phải BPMN 2.0.2. Không được khẳng định rằng Mermaid flowchart, Mermaid state diagram, sequence diagram, sơ đồ ASCII, bảng bước xử lý hoặc mô tả văn bản là BPMN. Không được phát minh hoặc trích dẫn số điều, số trang, bảng, phụ lục, ký hiệu, quy tắc conformance, định nghĩa nguyên văn hoặc quotation từ BPMN 2.0.2 khi chưa đối chiếu trực tiếp specification. Không được tuyên bố workflow, template, hệ thống ERP, quy trình Nova Foods hoặc tài liệu handbook “BPMN 2.0.2 compliant” chỉ vì có các bước, lane, approval hoặc gateway tương tự. Không được trình bày BPMN là luật Việt Nam, nghĩa vụ pháp lý, tiêu chuẩn kế toán, tiêu chuẩn an toàn thực phẩm hoặc sự thay thế cho phê duyệt của business owner, process owner, Senior BA, Architect, QA lead hay authority có thẩm quyền.

Ranh giới sử dụng BPMN trong handbook

BPMN 2.0.2 là Normative standard chỉ khi handbook sử dụng BPMN notation và semantics thực tế để mô hình hóa quy trình nghiệp vụ. Khi điều kiện này được đáp ứng, handbook có thể dùng BPMN như một ngôn ngữ chuẩn hóa để trao đổi về participant, process, event, activity, gateway, sequence flow, message flow và các thành phần BPMN khác sau khi nội dung chi tiết đã được xác minh từ specification phù hợp.

Trong Nova Foods, các quy ước như màu hex #E3F2FD, #E8F5E9, #FFEBEE, #FFFDE7, #FFE0B2, #F3E5F5; tên lane; cách đặt tên bước; cấu trúc ID như REQ-FUNC-SALES-012; mức độ chi tiết của workflow; và quyết định mô hình hóa quy trình nào là Project convention hoặc Author recommendation. Không được gán các quy ước này cho OMG BPMN 2.0.2.

Handbook mặc định sử dụng PlantUML Activity Diagram với swimlane cho cross-functional workflow theo diagramming standards của corpus. Vì vậy, các sơ đồ này phải được gọi là UML Activity Diagram, cross-functional workflow, hoặc workflow diagram; không được gọi là BPMN. BPMN chỉ được nêu hoặc sử dụng ở chapter/artifact có notation BPMN thực tế và có kiểm tra phù hợp.

Quy tắc gọi tên và chọn loại sơ đồ

Nhu cầu mô hình hóa trong Nova Foods	Loại biểu diễn được phép gọi tên	Có được gọi là BPMN 2.0.2 không?	Quy tắc bắt buộc
Minh họa luồng liên phòng ban từ Sales đến Warehouse, Finance và Approval bằng PlantUML có swimlane	UML Activity Diagram hoặc cross-functional workflow	Không	Dùng PlantUML Activity Diagram; mô tả lane là trách nhiệm hoặc vai trò trong quy ước dự án; không gán BPMN semantics cho ký pháp PlantUML.
Mô tả trao đổi API giữa Web Client, API Gateway, ERP Service và database	Mermaid sequenceDiagram hoặc sequence/API flow	Không	Dùng sequence diagram; không gọi message trao đổi kỹ thuật là BPMN message flow.
Thể hiện trạng thái Sales Order hoặc Work Order	Mermaid stateDiagram-v2 hoặc UML state transition diagram khi phù hợp	Không	Phân biệt state lifecycle của entity với BPMN process flow.
Mô hình hóa quy trình nghiệp vụ bằng BPMN event, activity, gateway, flow và participant theo notation BPMN thực tế	BPMN diagram / BPMN 2.0.2 process model	Có, sau khi xác minh notation và semantics	Phải dùng notation BPMN thực tế, kiểm tra syntax/semantics bằng công cụ hoặc reviewer phù hợp khi có thể, và không tuyên bố conformance tổng thể nếu chưa có bằng chứng.
Liệt kê bước xử lý trong bảng, user story, acceptance criteria hoặc test scenario	Bảng quy trình, textual flow hoặc test scenario	Không	Không dùng nhãn BPMN cho mô tả bảng hoặc văn bản.
Phân tích chênh lệch AS-IS và TO-BE	Gap analysis, process analysis hoặc workflow comparison	Không, trừ khi hai mô hình đầu vào là BPMN thực tế	Nêu rõ notation của từng artifact đầu vào; không suy ra rằng gap analysis tự động là BPMN-based.

Áp dụng có kiểm soát cho case study Nova Foods

Ví dụ, luồng “Sales tạo đơn B2B, hệ thống kiểm tra hạn mức tín dụng, cấp quản lý phê duyệt ngoại lệ chiết khấu, Warehouse xuất hàng và Finance ghi nhận công nợ” có thể được biểu diễn bằng PlantUML Activity Diagram có swimlane để phục vụ học viên đọc trách nhiệm liên phòng ban. Đây là một Project convention về visualization của handbook, không phải BPMN 2.0.2.

Nếu một chapter lựa chọn dạy BPMN thực tế, chapter đó phải:

1. Nêu rõ sơ đồ sử dụng BPMN notation, không phải PlantUML Activity Diagram hoặc Mermaid flowchart.
2. Xác định rõ mục tiêu mô hình hóa, phạm vi process và participant liên quan trong case Nova Foods.
3. Phân biệt các fact mô phỏng của Nova Foods với semantics của notation.
4. Không phát minh rule, biểu tượng, conformance level hoặc diễn giải chuẩn BPMN chưa được đối chiếu.
5. Không dùng mô hình notation để thay thế quyết định của process owner về quy trình TO-BE.

Quy tắc xác minh trước khi đưa claim BPMN vào handbook

Nhu cầu viết nội dung	Cách xử lý bắt buộc
Nêu BPMN 2.0.2 là nguồn normative cho BPMN notation thực tế	Có thể dùng entry này và URL OMG chính thức; giới hạn claim ở title, issuer, version và ranh giới sử dụng đã xác minh.
Gọi một sơ đồ PlantUML có swimlane là BPMN	Không được phép. Đổi nhãn thành UML Activity Diagram hoặc cross-functional workflow.
Dạy hoặc mô tả chính xác ý nghĩa, ký hiệu, quy tắc dùng event, gateway, message flow, collaboration, choreography, conversation, artifact hoặc conformance	Phải đối chiếu trực tiếp BPMN 2.0.2 specification và xác minh đúng ngữ cảnh trước khi gán claim cho OMG. Nếu chưa kiểm tra, dùng diễn đạt Verification required hoặc chuyển thành Author recommendation mà không quy gán cho BPMN.
Dẫn số điều, số trang, bảng, phụ lục, hình minh họa hoặc quotation	Chỉ được thực hiện sau khi kiểm tra trực tiếp đúng version 2.0.2, đúng vị trí và đúng ngữ cảnh của specification.
Đánh giá sơ đồ Nova Foods là BPMN-valid hoặc BPMN-compliant	Cần tiêu chí được xác minh, sơ đồ dùng notation BPMN thực tế, kết quả kiểm tra bằng công cụ hoặc review phù hợp, và bằng chứng được ghi trong QA artifact. Source map đơn lẻ không đủ để đưa ra kết luận này.
Dùng BPMN để quyết định workflow, quyền phê duyệt, segregation of duties, credit limit, release, accounting posting hoặc xử lý lô hàng	BPMN chỉ là ngôn ngữ mô hình hóa. Quyết định nghiệp vụ vẫn cần business owner, process owner, Senior BA, Architect, Finance authority, legal reviewer hoặc domain authority phù hợp xác nhận.

Giới hạn notation: Một sơ đồ có lane, mũi tên, hình chữ nhật hoạt động hoặc điểm quyết định không tự động trở thành BPMN. Tên gọi “BPMN” chỉ được dùng khi notation và semantics BPMN thực tế được áp dụng.

Giới hạn claim: Source map không chứng minh rằng toàn bộ corpus, bất kỳ workflow Nova Foods nào, hoặc bất kỳ công cụ sơ đồ nào tuân thủ BPMN 2.0.2. Claim về conformance, ký pháp hoặc semantics chi tiết phải được đối chiếu trực tiếp với BPMN 2.0.2 và có bằng chứng review phù hợp.

Giới hạn giáo dục: Việc học process analysis hoặc BPMN không thay thế kinh nghiệm delivery có giám sát, thẩm quyền của process owner, tư vấn pháp lý, tư vấn kế toán, domain authority hoặc quyền truy cập production.

SRC-STD-UML-001 — Unified Modeling Language (UML) Version 2.5.1

Trường	Giá trị
Source ID	SRC-STD-UML-001
Title	Unified Modeling Language (UML), Version 2.5.1
Issuer	Object Management Group (OMG)
Edition / Version / Status	UML 2.5.1
Stable URL	https://www.omg.org/spec/UML/2.5.1/About-UML/
Access Date	2026-08-07
Authority Classification	Normative standard
Intended Curriculum Use	Primary curriculum use: các chapter về requirements analysis, domain modeling, process/behavior modeling, data relationships, sequence logic, state lifecycle, traceability, solution communication, and review of model consistency. Template families: use case notes, class/data relationship notes, sequence interaction notes, state transition notes, analysis model checklist, traceability matrix, and model review checklist. Learner capability: hiểu semantics UML ở mức áp dụng cho phân tích và mô hình hóa trong handbook; phân biệt khi nào một artifact đang diễn tả cấu trúc, hành vi, tương tác, hay trạng thái; dùng UML như ngôn ngữ phân tích để làm rõ phạm vi, đối tượng, quan hệ, luồng tương tác và vòng đời của thực thể Nova Foods.
Verification Status	Verified
Licensing / Access Caveat	Trang OMG chính thức được dùng để xác minh title, issuer, version UML 2.5.1 và URL nguồn. Việc đọc, sao chép, trích dẫn hoặc diễn giải chi tiết specification phải tuân theo điều kiện bản quyền, license và quyền truy cập do OMG công bố. Source map này không xác nhận rằng toàn bộ specification, mọi diagram kind, notation detail, semantics clause, example, hay conformance rule đã được đối chiếu trực tiếp.
Claims That Must Not Be Made	Không được phát minh hoặc trích dẫn số điều, số trang, bảng, phụ lục, định nghĩa nguyên văn hoặc quotation từ UML 2.5.1 khi chưa đối chiếu trực tiếp specification. Không được khẳng định rằng mọi sơ đồ trong handbook đều “UML-compliant” chỉ vì chúng nhìn giống sơ đồ phân tích. Không được gọi Mermaid sequence diagram, Mermaid state diagram, Mermaid flowchart, bảng mô tả, hay văn bản bước xử lý là UML nếu chapter không chủ ý dùng UML semantics cho artifact đó. Không được suy ra rằng PlantUML activity diagram, BPMN, hoặc bất kỳ notation nào khác tự động kế thừa toàn bộ semantics hoặc conformance của UML 2.5.1 nếu chưa xác minh riêng. Không được trình bày UML 2.5.1 như luật Việt Nam, chuẩn kế toán, chuẩn an toàn thực phẩm, hay sự thay thế cho phê duyệt của business owner, architect, QA lead, senior BA, hoặc domain authority.

Ranh giới sử dụng UML trong handbook

UML 2.5.1 là Normative standard cho semantics UML khi handbook cần mô hình hóa hoặc diễn giải một đối tượng, hành vi, tương tác, hoặc trạng thái theo ngôn ngữ UML. Trong corpus Nova Foods, UML được dùng như nền tảng phân tích để giúp học viên hiểu:

• đối tượng nghiệp vụ là gì;
• quan hệ giữa các thực thể ra sao;
• một tương tác diễn ra theo thứ tự nào;
• một entity chuyển trạng thái như thế nào;
• vì sao một yêu cầu cần được biểu diễn theo cấu trúc hay hành vi.

Tuy nhiên, trong corpus này, việc một diagram được vẽ bằng PlantUML hoặc Mermaid không tự động biến nó thành UML. Chỉ khi chapter hoặc artifact đó chủ đích dùng UML semantics và mô tả rõ notation tương ứng thì mới được gắn UML một cách chính xác.

Quy tắc gọi tên và phạm vi áp dụng

Nhu cầu mô hình hóa trong Nova Foods	Cách gọi đúng	Có được coi là UML 2.5.1 chỉ vì hình thức giống UML không?	Ghi chú bắt buộc
Diễn tả luồng tương tác giữa Client, Gateway, ERP Service và DB	Sequence / API flow hoặc UML sequence interaction nếu chapter tuyên bố dùng UML semantics	Không tự động	Phải nói rõ diagram đó đang mô tả tương tác, không được suy diễn conformance nếu chưa kiểm tra.
Diễn tả vòng đời Sales Order hoặc Work Order	State transition / UML state machine nếu chapter tuyên bố dùng UML semantics	Không tự động	Phải phân biệt trạng thái đối tượng với quy trình nghiệp vụ nhiều bước.
Diễn tả cấu trúc dữ liệu, quan hệ entity, association, multiplicity	Data model / class-style analysis / UML class semantics nếu chapter tuyên bố dùng UML semantics	Không tự động	Không được trộn lẫn mô hình dữ liệu vật lý với mô hình khái niệm mà không nói rõ mức trừu tượng.
Diễn tả quy trình liên phòng ban	Cross-functional workflow hoặc UML activity semantics nếu chapter chọn UML semantics	Không tự động	Nếu dùng swimlane PlantUML, phải gọi đúng là UML Activity Diagram hoặc workflow diagram theo quy ước dự án.
Ghi chú use case, actor, boundary, goal và main flow	Use case analysis notes hoặc UML use case semantics nếu chapter tuyên bố dùng UML semantics	Không tự động	Không được xem mọi user story hoặc process note là UML use case nếu chưa có cấu trúc UML rõ ràng.

Quy tắc xác minh trước khi đưa claim UML vào handbook

Nhu cầu viết nội dung	Cách xử lý bắt buộc
Nêu UML 2.5.1 là nguồn normative cho semantics UML	Có thể dùng entry này và URL OMG chính thức; giới hạn claim ở title, issuer, version và ranh giới sử dụng đã xác minh.
Dẫn số điều, số trang, bảng, phụ lục, hình minh họa hoặc quotation	Chỉ được thực hiện sau khi kiểm tra trực tiếp đúng version 2.5.1, đúng vị trí và đúng ngữ cảnh của specification.
Khẳng định một artifact Nova Foods là UML-valid hoặc UML-compliant	Cần có notation hoặc semantics UML thực tế, tiêu chí review được mô tả rõ, và bằng chứng kiểm tra phù hợp trong QA artifact. Source map đơn lẻ không đủ để kết luận.
Dùng UML để quyết định business rule, approval, credit limit, accounting posting, traceability, hoặc legal interpretation	UML chỉ là ngôn ngữ mô hình hóa. Quyết định nghiệp vụ và pháp lý vẫn cần authority phù hợp xác nhận.
Trộn UML với BPMN, Mermaid, PlantUML hoặc văn bản quy trình mà không phân biệt semantics	Phải ghi rõ notation, mục đích sử dụng và mức độ khớp với UML; không được mặc định tất cả là cùng một chuẩn.

Giới hạn semantics: UML 2.5.1 cung cấp ngôn ngữ mô hình hóa chuẩn để diễn tả cấu trúc và hành vi, nhưng source map này không xác nhận rằng mọi diagram trong handbook đã được kiểm tra đầy đủ theo specification.
Giới hạn claim: Không được nói “UML-compliant”, “UML-conformant”, hay “standard UML” cho một artifact nếu chưa có kiểm tra notation/semantics phù hợp.
Giới hạn giáo dục: UML giúp người học hiểu và trao đổi thiết kế, nhưng không thay thế kinh nghiệm delivery có giám sát, thẩm quyền domain, tư vấn pháp lý, tư vấn kế toán, hay quyền truy cập production.

SRC-STD-ISTQB-001 — ISTQB Certified Tester Foundation Level (CTFL) Syllabus v4.0.1

Trường	Giá trị
Source ID	SRC-STD-ISTQB-001
Title	ISTQB Certified Tester Foundation Level Syllabus, Version 4.0.1
Issuer	ISTQB
Edition / Version / Status	CTFL Syllabus v4.0.1
Stable URL	https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf
Access Date	2026-08-07
Authority Classification	Normative standard
Intended Curriculum Use	Primary curriculum use: chapter về testing fundamentals for BA, black-box testing, acceptance criteria design, test condition identification, test scenario and test case derivation, defect reporting, regression thinking, and UAT preparation trong Nova Foods. Template families: test strategy notes, test condition matrix, equivalence partitioning worksheet, boundary value worksheet, decision table worksheet, state transition worksheet, traceability from requirement to AC to TC, defect log, and UAT sign-off checklist. Learner capability: hiểu terminology testing ở mức đủ để BA viết acceptance criteria rõ ràng, chuyển requirement thành testable conditions, áp dụng black-box techniques có kỷ luật, và phối hợp với QA/UAT trong quy trình delivery của Nova Foods.
Verification Status	Verified
Licensing / Access Caveat	Đây là syllabus chính thức do ISTQB công bố và được dùng làm nguồn chuẩn cho thuật ngữ và kỹ thuật black-box ở mức foundation. Bản PDF và mọi nội dung cụ thể bên trong có thể chịu điều kiện truy cập, bản quyền hoặc sử dụng do ISTQB/nhà phân phối công bố. Source map này chỉ xác nhận title, issuer, version, URL và mục đích sử dụng an toàn; không khẳng định đã đối chiếu trực tiếp mọi bảng, định nghĩa, ví dụ, learning objective, glossary term, hay section của syllabus.
Claims That Must Not Be Made	Không được phát minh hoặc trích dẫn số trang, số mục, bảng, glossary entry, learning objective, hay quotation nguyên văn từ CTFL v4.0.1 nếu chưa kiểm tra trực tiếp file PDF. Không được nói rằng handbook “dạy đầy đủ ISTQB CTFL” hoặc “đảm bảo đỗ chứng chỉ ISTQB”; đây là tài liệu vận hành BA, không phải đề cương luyện thi. Không được dùng syllabus này để suy diễn rằng mọi test case của Nova Foods đều là “ISTQB compliant” nếu chưa có review chất lượng và ngữ cảnh dự án. Không được trình bày ISTQB như luật, chuẩn pháp lý, chuẩn kế toán, chuẩn an toàn thực phẩm, hay thay thế cho quyết định của QA lead, senior BA, PM, architect, hoặc business owner. Không được dùng syllabus này để khẳng định một kỹ thuật black-box là bắt buộc trong mọi tình huống; việc chọn kỹ thuật phải dựa trên rủi ro, mục tiêu kiểm thử, dữ liệu, và ràng buộc dự án.

Ranh giới sử dụng ISTQB CTFL trong handbook

ISTQB CTFL v4.0.1 là Normative standard cho thuật ngữ kiểm thử nền tảng và kỹ thuật black-box mà handbook dùng để xây dựng tư duy kiểm thử cho BA trong Nova Foods. Nguồn này phù hợp khi handbook cần:

• định nghĩa chính xác các khái niệm như test condition, test scenario, test case, defect, regression, confirmation testing;
• hướng dẫn BA chuyển requirement và acceptance criteria thành điều kiện kiểm thử;
• áp dụng các kỹ thuật black-box như equivalence partitioning, boundary value analysis, decision table testing, state transition testing, và use case testing;
• phân biệt rõ trách nhiệm giữa BA, QA, dev, và UAT stakeholder.

Tuy nhiên, ISTQB CTFL chỉ là khung kiến thức kiểm thử. Nó không tự động quyết định quy trình nội bộ của Nova Foods, không thay thế kiểm soát chất lượng dự án, và không cung cấp kết luận pháp lý hay nghiệp vụ cho hệ thống ERP.

Quy tắc áp dụng trong corpus Nova Foods

Nhu cầu viết nội dung	Cách xử lý bắt buộc
Dùng thuật ngữ test trong chapter BA	Có thể dựa trên ISTQB CTFL để chuẩn hóa ngôn ngữ và logic kiểm thử.
Mô tả kỹ thuật black-box	Có thể đưa vào phần testing fundamentals, nhưng phải gắn với bối cảnh requirement/AC/TC của Nova Foods.
Kết luận rằng requirement đã “đủ testable”	Không được dựa riêng vào ISTQB; cần thêm review của BA/QA và độ rõ của requirement.
Trích dẫn định nghĩa chính xác hoặc learning objective	Chỉ được làm sau khi đối chiếu trực tiếp PDF CTFL v4.0.1.
Gọi một checklist nội bộ là “ISTQB standard”	Không được tự động gán nhãn; phải phân biệt rõ giữa tiêu chuẩn, thực hành tốt, và convention của dự án.

Ghi chú xác minh và sử dụng an toàn

Hạng mục	Quy tắc
Xác minh nguồn	URL chính thức đã được ghi nhận; mọi claim chi tiết khác vẫn phải đối chiếu trực tiếp với bản PDF CTFL v4.0.1.
Phạm vi an toàn	Dùng cho thuật ngữ kiểm thử nền tảng, black-box techniques, và hỗ trợ BA viết acceptance criteria/testable requirements.
Phạm vi không an toàn	Không dùng để tuyên bố tuân thủ chứng chỉ, không dùng để thay thế QA strategy của dự án, và không dùng làm căn cứ pháp lý hay kỹ thuật sản phẩm.
Độ tin cậy trong source map	Verified cho metadata và mục đích curriculum; Verification required cho mọi câu trích dẫn, số mục, hoặc diễn giải chi tiết vượt quá metadata đã xác nhận.

Câu lệnh quản trị nội dung cho handbook

• Khi handbook nhắc đến testing terminology, ưu tiên dùng ISTQB CTFL v4.0.1 làm chuẩn ngôn ngữ.
• Khi handbook trình bày black-box techniques, phải gắn với mục tiêu kiểm thử thực tế của Nova Foods và mối liên hệ Requirement → Acceptance Criteria → Test Case.
• Khi cần câu chữ mang tính chuẩn mực chi tiết, phải ghi rõ là cần Verification required nếu chưa đối chiếu trực tiếp syllabus PDF.
• Khi người đọc cần ra quyết định dự án, phải nhấn mạnh rằng ISTQB là nguồn học thuật/chuyên môn về testing, không phải thẩm quyền duy nhất của dự án.

SRC-STD-OAS-001 — OpenAPI Specification 3.1.1

Trường	Giá trị
Source ID	SRC-STD-OAS-001
Title	OpenAPI Specification, Version 3.1.1
Issuer	OpenAPI Initiative
Edition / Version / Status	OAS 3.1.1, published 2024-10-24
Stable URL	https://spec.openapis.org/oas/v3.1.1.html
Access Date	2026-08-07
Authority Classification	Normative standard
Intended Curriculum Use	Primary curriculum use: các chapter về API requirement analysis, integration discovery, API contract specification, request/response modeling, error handling, authentication boundary analysis, API acceptance criteria, API payload testing, and integration traceability trong Nova Foods ERP. Template families: API specification, API contract review checklist, integration context map, endpoint inventory, request/response payload catalogue, API error catalogue, API test-condition matrix, and requirement-to-API traceability matrix. Learner capability: BA có thể đọc, cấu trúc, review và trao đổi về một HTTP API contract cho các tích hợp Nova Foods, ví dụ giữa Web ERP, API Gateway, CRM, POS, hệ thống kế toán legacy, đối tác giao hàng hoặc cổng thanh toán giả lập; BA không được tự nhận vai trò quyết định implementation architecture hoặc security architecture.
Verification Status	Verified
Licensing / Access Caveat	Đây là specification chính thức do OpenAPI Initiative công bố tại URL nêu trên. Source map xác nhận title, issuer, version, publication date, URL và ranh giới sử dụng an toàn từ verified seed. Việc sử dụng các schema, object, field, keyword, semantic constraint, serialization rule, hoặc example cụ thể của OAS 3.1.1 trong handbook phải được đối chiếu trực tiếp với specification hiện hành. Khả năng công cụ hỗ trợ OAS 3.1.1 có thể khác nhau giữa API gateway, code generator, validator, documentation generator và nền tảng vận hành; không được suy diễn rằng một công cụ bất kỳ hỗ trợ đầy đủ toàn bộ OAS 3.1.1.
Claims That Must Not Be Made	Không được phát minh section number, clause, quotation, object definition, field behavior, JSON Schema compatibility claim, serialization rule, security-scheme behavior, hoặc validation outcome từ OAS 3.1.1. Không được nói một OpenAPI document tự động làm API an toàn, đúng nghiệp vụ, tương thích ngược, có hiệu năng tốt, hoặc sẵn sàng production. Không được mô tả OpenAPI như một implementation framework, một database schema, một giao thức xác thực, một kiến trúc microservices, hay một công cụ thay thế API gateway. Không được khẳng định endpoint của Nova Foods “OAS compliant” nếu chưa có validation bằng công cụ phù hợp và review của architect, developer, QA, security owner và business owner khi cần. Không được dùng OAS 3.1.1 làm căn cứ pháp lý, kế toán, thuế, quyền riêng tư, an toàn thực phẩm, hoặc thẩm quyền phê duyệt production integration.

Ranh giới sử dụng OpenAPI Specification 3.1.1 trong handbook

OpenAPI Specification 3.1.1 là Normative standard cho việc mô tả hợp đồng HTTP API bằng OpenAPI Description. Trong corpus Nova Foods, nguồn này được dùng để chuẩn hóa cách BA và nhóm delivery biểu đạt giao diện tích hợp có cấu trúc, bao gồm API path, operation, parameter, request body, response, media type, schema, error response và security declaration ở mức mô tả contract.

Nguồn này phù hợp khi handbook cần hướng dẫn người học:

• phân biệt API contract với code implementation, database model và business process;
• chuyển một nhu cầu tích hợp thành endpoint và operation có phạm vi rõ ràng;
• mô tả request và response cho tình huống Nova Foods, chẳng hạn tạo đơn hàng B2B, truy vấn tồn kho theo kho và lô, đồng bộ customer master data, hoặc gửi dữ liệu hóa đơn sang hệ thống tích hợp giả lập;
• làm rõ input, output, HTTP status, error condition, data validation expectation và traceability giữa REQ-FUNC-xxx, AC-xxx, API-xxx và TC-xxx;
• hỗ trợ QA xây dựng test condition cho boundary, mandatory field, invalid payload, authorization expectation và idempotency expectation khi các expectation này đã được requirement hoặc architect xác định;
• review API contract với developer, architect, QA, security owner và business stakeholder.

OpenAPI không tự tạo ra business rule. Ví dụ, BR-SALES-004 về giới hạn số tiền hoàn trả phải được xác định và phê duyệt trong artifact nghiệp vụ trước. API chỉ diễn đạt cách một consumer gửi refund request, cách service phản hồi, và cách error được mô tả nếu request không thỏa rule đã được hệ thống hóa.

Quy tắc áp dụng cho API của Nova Foods

Nhu cầu viết nội dung	Cách xử lý bắt buộc
Mô tả HTTP endpoint cho Nova Foods	Dùng cấu trúc OpenAPI 3.1.1 sau khi xác định rõ business need, requirement, business rule, actor, boundary và owner của integration.
Viết API payload mẫu	Dùng dữ liệu tổng hợp của Nova Foods; liên kết payload với entity và data dictionary đã được kiểm soát. Không dùng dữ liệu cá nhân hoặc credential thật.
Mô tả response thành công và lỗi	Chỉ định ý nghĩa nghiệp vụ, điều kiện kích hoạt, cấu trúc response và traceability tới requirement/AC. HTTP status cụ thể phải được architect hoặc API convention của dự án xác nhận.
Thiết kế authentication hoặc authorization	BA ghi nhận business access need và security requirement; architect/security owner quyết định cơ chế, trust boundary, token handling, secret management và enforcement design.
Dùng OpenAPI để suy ra database design	Không được. API contract và data model liên quan nhưng không đồng nhất; mọi mapping phải được architect/developer và data owner review.
Gọi tài liệu endpoint là “production-ready”	Chỉ được dùng khi tài liệu đã qua quality gate, validation tooling phù hợp, security review cần thiết và quy trình phê duyệt dự án.
Khẳng định một tool hỗ trợ OAS 3.1.1	Chỉ được nêu sau khi kiểm tra documentation và phiên bản cụ thể của tool. Không suy diễn từ việc tool hỗ trợ một phiên bản OpenAPI khác.

Phân định trách nhiệm khi dùng OpenAPI trong delivery

Vai trò	Trách nhiệm phù hợp trong ngữ cảnh OAS 3.1.1
Business Analyst	Làm rõ mục tiêu nghiệp vụ, actor, trigger, data need, business rule, acceptance criteria, error expectation, ownership và traceability của API contract.
Solution Architect / API Architect	Quyết định integration architecture, API style, versioning strategy, security architecture, protocol boundary, resilience pattern, observability expectation và compatibility approach.
Developer	Hiện thực endpoint theo contract đã được review; đề xuất thay đổi khi contract không khả thi, không rõ hoặc mâu thuẫn với implementation constraint.
QA Engineer	Xây dựng và thực thi test condition/test case cho contract, payload, response, error handling và integration behavior theo risk-based test approach.
Security Owner	Review các rủi ro về identity, authorization, sensitive data exposure, secret handling, transport protection, logging và threat model.
Business Owner / Product Owner	Xác nhận API hỗ trợ đúng business outcome, ownership, policy và ưu tiên delivery; không thay thế review kỹ thuật hoặc security review.

Ghi chú xác minh và sử dụng an toàn

Hạng mục	Quy tắc
Xác minh nguồn	Metadata của OAS 3.1.1, issuer, ngày công bố và URL đã được ghi nhận từ verified seed. Mọi diễn giải chi tiết về keyword, object, schema, validation, serialization hoặc security mechanism phải được kiểm tra trực tiếp tại specification.
Phạm vi an toàn	Dùng để tổ chức và review HTTP API description, API contract artifacts, payload examples và traceability cho các tích hợp mô phỏng của Nova Foods.
Phạm vi không an toàn	Không dùng để tự quyết định API architecture, cryptographic control, token lifecycle, privacy classification, production deployment, data retention, legal compliance hoặc compatibility guarantee.
Độ tin cậy trong source map	Verified cho metadata nguồn và ranh giới curriculum. Verification required cho mọi claim kỹ thuật chi tiết không được xác nhận trực tiếp từ OAS 3.1.1 hoặc chưa được architect/security owner review trong ngữ cảnh dự án.

Câu lệnh quản trị nội dung cho handbook

• Khi handbook dạy cách mô tả HTTP API, dùng OpenAPI Specification 3.1.1 làm nguồn chuẩn cho cấu trúc của API description, nhưng phân biệt rõ API contract với API implementation.
• Mọi API artifact trong Nova Foods phải trace được về business need, requirement và acceptance criteria; một endpoint không được tồn tại chỉ vì “có thể xây được”.
• Các ví dụ API chỉ được dùng dữ liệu tổng hợp và safe secret reference như ${ACCESS_TOKEN}; không được đưa API key, password, bearer token hoặc thông tin cá nhân thật.
• Mọi yêu cầu về authorization, privacy, accounting integration, invoice data, food traceability hoặc retention phải được gắn nhãn Verification required hoặc Project assumption nếu chưa có căn cứ hiện hành và review của thẩm quyền phù hợp.
• Khi cần tuyên bố chi tiết rằng một OpenAPI document hợp lệ theo OAS 3.1.1, phải thực hiện validation bằng công cụ thích hợp, lưu kết quả trong artifact QA liên quan, và không thay thế review của architect hoặc security owner.

SRC-STD-WCAG-001 — WCAG 2.2 Recommendation

Trường	Giá trị
Source ID	SRC-STD-WCAG-001
Title	Web Content Accessibility Guidelines (WCAG) 2.2
Issuer	World Wide Web Consortium (W3C)
Edition / Version / Status	WCAG 2.2 Recommendation, 2024-12-12 edition
Stable URL	https://www.w3.org/TR/WCAG22/
Access Date	2026-08-07
Authority Classification	Normative standard
Intended Curriculum Use	Nguồn chuẩn cho các chapter và template liên quan đến accessibility trong thiết kế nghiệp vụ và delivery của Nova Foods, bao gồm: cấu trúc tài liệu dễ đọc, tiêu đề và thứ bậc nội dung, mô tả biểu mẫu và thông báo lỗi, yêu cầu hỗ trợ bàn phím, độ tương phản màu, khả năng phóng to văn bản, thông báo trạng thái, nội dung phi văn bản, và các nguyên tắc giúp người dùng có hạn chế về thị giác, vận động hoặc nhận thức vẫn sử dụng được hệ thống. Nguồn này đặc biệt hữu ích khi handbook bàn về BA review cho màn hình nhập đơn, tra cứu tồn kho, phê duyệt chiết khấu, form customer master, dashboard báo cáo, và các artifact mô tả giao diện người dùng.
Verification Status	Verified
Licensing / Access Caveat	Đây là Recommendation chính thức của W3C và có thể truy cập công khai tại URL nêu trên. Source map chỉ xác nhận metadata nguồn, không suy diễn rằng toàn bộ handbook hoặc toàn bộ giao diện Nova Foods đã tuân thủ WCAG 2.2. Khi handbook sử dụng các tiêu chí hoặc kỹ thuật từ WCAG, câu chữ phải đối chiếu trực tiếp với nội dung hiện hành của tài liệu chính thức. Việc tuân thủ thực tế còn phụ thuộc vào thiết kế UI, implementation, kiểm thử, nội dung, framework và cấu hình nền tảng.
Claims That Must Not Be Made	Không được phát minh số điều, số clause, số section, số success criterion, wording nguyên văn, hay diễn giải chính xác của bất kỳ tiêu chí nào nếu chưa đối chiếu trực tiếp với nguồn. Không được khẳng định một màn hình, trang, report, PDF, email, hay API response của Nova Foods “complies with WCAG 2.2” nếu chưa có review và kiểm thử phù hợp. Không được dùng WCAG như căn cứ pháp lý Việt Nam, thay thế cho luật, hoặc suy luận rằng tuân thủ WCAG tự động bảo đảm tuân thủ tất cả yêu cầu về pháp lý, bảo mật, quyền riêng tư, hoặc trải nghiệm người dùng. Không được suy diễn rằng mọi tiêu chí WCAG đều áp dụng nguyên xi cho mọi artifact phi-web mà không đánh giá bối cảnh sử dụng.

Ranh giới sử dụng WCAG 2.2 trong handbook

WCAG 2.2 là Normative standard cho accessibility của nội dung số. Trong corpus Nova Foods, nguồn này được dùng để hướng dẫn BA và nhóm delivery mô tả các yêu cầu dễ tiếp cận cho giao diện web ERP, tài liệu hướng dẫn, biểu mẫu điện tử, trang báo lỗi, thông báo trạng thái, và các màn hình nghiệp vụ mà người dùng nội bộ hoặc đối tác sẽ thao tác.

Nguồn này phù hợp khi handbook cần chỉ ra cách:

• viết requirement liên quan đến khả năng truy cập của giao diện người dùng, ví dụ nhãn trường nhập liệu rõ ràng, thứ tự tab hợp lý, và thông báo lỗi dễ hiểu;
• review màn hình Nova Foods để phát hiện rủi ro về độ tương phản, kích thước chữ, khả năng dùng bằng bàn phím, và khả năng nhận biết trạng thái;
• đặt acceptance criteria cho form nghiệp vụ như tạo đơn hàng B2B, duyệt giảm giá, xác nhận xuất kho, hoặc tra cứu công nợ;
• phân biệt giữa yêu cầu accessibility ở mức business need, yêu cầu thiết kế UI, và kiểm thử kỹ thuật do QA hoặc UX specialist thực hiện;
• bảo đảm handbook không trình bày accessibility như một khẩu hiệu chung chung mà gắn với artifact có thể kiểm tra được.

WCAG không tự động biến một giao diện thành “accessible”. Ví dụ, một màn hình nhập đơn của Nova Foods có thể có đủ field và logic nghiệp vụ, nhưng vẫn thất bại nếu chỉ dùng màu sắc để báo lỗi, không hỗ trợ bàn phím, hoặc không có cấu trúc nhãn và heading rõ ràng. Vì vậy, WCAG chỉ là nguồn chuẩn để mô tả và kiểm tra yêu cầu accessibility, không phải bằng chứng hoàn tất chất lượng.

Quy tắc áp dụng cho handbook và template

Hạng mục	Quy tắc bắt buộc
Viết yêu cầu accessibility	Gắn với một user need hoặc requirement cụ thể, ví dụ form phê duyệt hoặc màn hình tra cứu. Không viết “system must be accessible” như một câu chung chung không kiểm tra được.
Viết tiêu chí nghiệm thu	Nêu quan sát được, kiểm tra được, và gắn với bối cảnh sử dụng Nova Foods. Nếu tiêu chí chưa đối chiếu trực tiếp với WCAG 2.2 thì đánh dấu Verification required.
Mô tả màu sắc, icon, trạng thái	Không dựa vào màu đơn lẻ để truyền tải nghĩa nghiệp vụ quan trọng. Cần có text, label, hoặc trạng thái bổ sung.
Mô tả form và lỗi nhập liệu	Thông báo lỗi phải chỉ rõ trường nào sai, vì sao sai, và người dùng cần làm gì tiếp theo.
Mô tả tài liệu PDF/biểu mẫu	Cấu trúc phải có heading, thứ bậc rõ ràng, và nội dung có thể đọc bằng công nghệ hỗ trợ ở mức phù hợp với bối cảnh dự án.
Dùng WCAG để tuyên bố tuân thủ	Chỉ được tuyên bố sau khi có review và kiểm thử accessibility phù hợp. BA không tự quyết định kết luận compliance nếu không có dữ liệu kiểm thử và thẩm quyền liên quan.

Phân định trách nhiệm khi dùng WCAG 2.2 trong Nova Foods

Vai trò	Trách nhiệm phù hợp
Business Analyst	Ghi nhận business need liên quan đến khả năng sử dụng, mô tả nhu cầu của người dùng, và chuyển thành requirement/acceptance criteria có thể kiểm tra.
UX / UI Designer	Thiết kế cấu trúc, luồng tương tác, trạng thái lỗi, điều hướng và trình bày đáp ứng yêu cầu accessibility.
Developer	Hiện thực markup, keyboard behavior, focus management, semantic structure, và các điều kiện cần thiết khác theo thiết kế và requirement đã duyệt.
QA Engineer	Kiểm tra các tiêu chí accessibility đã được chọn cho phạm vi dự án bằng test condition và test case phù hợp.
Product / Business Owner	Xác nhận mức ưu tiên và phạm vi hỗ trợ người dùng mà dự án cần đạt.
Legal / Compliance / Domain Owner	Chỉ tham gia khi accessibility gắn với nghĩa vụ pháp lý, chính sách nội bộ, hoặc tiêu chuẩn bắt buộc khác.

Ghi chú kiểm soát thuật ngữ

• Dùng “WCAG 2.2 Recommendation” như một nguồn chuẩn về accessibility của nội dung web.
• Không gọi WCAG là luật.
• Không gán cho WCAG quyền quyết định về privacy, security, accounting, invoice compliance, hay food-traceability.
• Nếu handbook đề cập đến tiêu chí accessibility nào chưa được kiểm tra trực tiếp từ nguồn chính thức, phải ghi Verification required.
• Khi viết ví dụ Nova Foods, chỉ dùng dữ liệu tổng hợp và mô tả nghiệp vụ giả lập; không dùng dữ liệu cá nhân thật hoặc thông tin sản xuất thật.

Kết luận sử dụng an toàn

Trong source map của handbook, WCAG 2.2 được xem là nguồn chuẩn để định hướng cách viết yêu cầu và kiểm thử liên quan đến khả năng tiếp cận của các artifact số trong Nova Foods. Nguồn này hỗ trợ chất lượng giao diện và tài liệu, nhưng không thay thế review thiết kế, kiểm thử thực tế, hoặc quyết định quản trị của các vai trò có thẩm quyền.

SRC-STD-BABOK-001 — BABOK Guide (IIBA)

Trường	Giá trị
Source ID	SRC-STD-BABOK-001
Title	A Business Analysis Body of Knowledge® (BABOK® Guide)
Issuer	International Institute of Business Analysis (IIBA)
Edition / Version / Status	Version 3; official overview and errata available from IIBA
Stable URL	https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/
Access Date	2026-08-07
Authority Classification	Normative standard
Intended Curriculum Use	Nguồn nền cho hệ thống khái niệm BA trong handbook Nova Foods: định nghĩa business analysis, vocabulary chung, knowledge areas, tasks, underlying competencies, stakeholder analysis, requirements lifecycle thinking, solution evaluation thinking, and traceability-oriented reasoning. Dùng để chuẩn hóa thuật ngữ và khung tư duy BA ở mức tổng quan cho toàn bộ corpus, đặc biệt trong các chapter về discovery, requirements, stakeholder management, validation, and solution evaluation.
Verification Status	Verified đối với metadata nguồn chính thức và phạm vi sử dụng ở mức overview; Verification required nếu handbook cần trích dẫn wording chính xác, page reference, task detail, hoặc clause-like claims từ full licensed text.
Licensing / Access Caveat	Trang chính thức của IIBA cung cấp overview, metadata, và điều hướng đến BABOK Guide, nhưng nội dung đầy đủ có thể yêu cầu quyền truy cập/licensing. Source map này chỉ xác nhận nguồn chuẩn để định hướng curriculum; không khẳng định rằng toàn bộ handbook được phép sao chép, tái bản, hay diễn giải chi tiết từng task/technique như thể đã đối chiếu toàn văn bản được cấp phép. Khi viết handbook, các nhận định dựa trên BABOK phải được diễn đạt ở mức khái quát phù hợp với access có sẵn; nếu cần wording chính xác hoặc chi tiết nội dung, phải đánh dấu Verification required.
Claims That Must Not Be Made	Không được phát minh số chương, số trang, tên mục con, câu chữ nguyên văn, hay “BABOK says...” kèm diễn giải chi tiết nếu chưa đối chiếu trực tiếp với bản đầy đủ hợp lệ. Không được suy luận rằng mọi technique trong BABOK đều bắt buộc áp dụng cho mọi dự án Nova Foods. Không được dùng BABOK như luật, tiêu chuẩn pháp lý, hay quy định kế toán/thuế/pháp lý. Không được khẳng định BABOK tự động bảo đảm chất lượng delivery, governance, compliance, hoặc project success. Không được mô tả các task/competency như thể là mệnh lệnh cứng của tổ chức; trong handbook chúng phải được trình bày như khung tham chiếu nghề nghiệp và thực hành tốt.

Ranh giới sử dụng BABOK Guide trong handbook

BABOK Guide là nguồn chuẩn về nghề phân tích nghiệp vụ, không phải tài liệu kỹ thuật triển khai hệ thống và cũng không phải văn bản pháp lý. Trong corpus Nova Foods, nguồn này được dùng để:

• chuẩn hóa thuật ngữ BA, tránh dùng từ mơ hồ hoặc nội bộ hóa quá mức;
• định vị các hoạt động như elicitation, analysis, specification, validation, traceability, stakeholder collaboration, và solution evaluation;
• xây dựng competency map và learning path từ zero tới delivery-ready;
• làm khung tham chiếu cho template, checklist, và quality gate của BA;
• giải thích vì sao một số quyết định cần escalation thay vì tự xử lý ở cấp BA.

Quy tắc áp dụng an toàn

Hạng mục	Quy tắc bắt buộc
Dùng trong chapter	Chỉ dùng để định nghĩa khái niệm, framing quy trình BA, và tiêu chuẩn tư duy nghề nghiệp.
Dùng trong template	Có thể tham chiếu cho metadata, checklist, và quality gate của artifact BA.
Dùng trong ví dụ Nova Foods	Chỉ diễn giải ở mức quy trình và vai trò BA; không gán BABOK cho luật, policy kỹ thuật, hay quyết định domain-specific.
Dùng để trích dẫn	Không trích nguyên văn hoặc dẫn page/section nếu chưa được xác minh từ bản hợp lệ.
Dùng để đánh giá tuân thủ	Chỉ xem như benchmark nghề nghiệp; không dùng để tuyên bố “compliant” theo nghĩa pháp lý hay contractual.

Lưu ý về ngôn ngữ và diễn giải trong corpus

Khi handbook nhắc đến BABOK Guide, câu chữ nên ưu tiên:

• “theo khung tham chiếu BABOK” thay vì “BABOK bắt buộc”;
• “một thực hành BA phù hợp” thay vì “cách duy nhất đúng”;
• “cần xác minh từ bản đầy đủ” nếu đi vào chi tiết kỹ thuật nội dung;
• “phù hợp cho mục tiêu curriculum” thay vì “được phép suy rộng thành quy tắc dự án”.

Kết luận sử dụng cho Phase 1

BABOK Guide là nguồn chuẩn nền tảng để xây dựng ngôn ngữ BA thống nhất cho toàn bộ handbook Nova Foods. Nguồn này đủ mạnh để định hướng competency map, chapter design, template structure, và reasoning patterns, nhưng mọi chi tiết đặc thù, câu chữ chính xác, hoặc trích dẫn sâu phải được đánh dấu Verification required nếu chưa đối chiếu trực tiếp với bản đầy đủ hợp lệ.

Official Vietnamese Law and Regulatory Sources

SRC-LAW-PRIVACY-001 — Luật Bảo vệ dữ liệu cá nhân

Trường	Giá trị
Source ID	SRC-LAW-PRIVACY-001
Title	Luật Bảo vệ dữ liệu cá nhân
Issuer	Quốc hội Việt Nam
Version / Status	Luật số 91/2025/QH15; có hiệu lực từ ngày 2026-01-01
Official URL	https://vanban.chinhphu.vn/?classid=1&docid=214590&pageid=27160&typegroup=
Access Date	2026-08-07
Authority Classification	Official Vietnamese law
Intended Curriculum Use	Dùng làm nguồn pháp lý chính thức để định hướng các chapter và template có liên quan đến việc nhận diện dữ liệu cá nhân, mục đích xử lý dữ liệu, trách nhiệm và ranh giới quản trị dữ liệu trong hệ thống Web ERP mô phỏng của Nova Foods. Các bối cảnh học tập có thể bao gồm CRM và Customer Master Data, thông tin liên hệ khách hàng, dữ liệu người dùng nội bộ, phân quyền truy cập, nhật ký thao tác, tích hợp API và báo cáo có chứa dữ liệu nhận diện cá nhân. Nguồn này chỉ cung cấp căn cứ để yêu cầu người học nhận diện nhu cầu xem xét pháp lý; không tự động tạo ra một thiết kế privacy, data-retention policy, security control hoặc production requirement cụ thể. Template families: data inventory, data classification note, privacy-impact question set, access-control requirement, API data-field review, consent or lawful-basis analysis note khi được legal owner xác nhận, và traceability matrix cho các requirement liên quan đến dữ liệu cá nhân. Learner capability: biết phát hiện khi một yêu cầu nghiệp vụ có thể liên quan đến dữ liệu cá nhân, ghi nhận câu hỏi cần legal/privacy review, phân biệt fact mô phỏng với nghĩa vụ pháp lý, và escalation đúng thẩm quyền trước khi đưa yêu cầu vào baseline hoặc production.
Verification Status	Verified đối với metadata nguồn, số luật, issuer, ngày hiệu lực và URL chính thức theo verified source seed. Verification required đối với mọi diễn giải về phạm vi áp dụng, định nghĩa, quyền của chủ thể dữ liệu, nghĩa vụ của tổ chức, căn cứ xử lý, chuyển dữ liệu, lưu trữ, thông báo, xử phạt hoặc yêu cầu kỹ thuật cụ thể.
Licensing / Access Caveat	URL trên là nguồn pháp lý chính thức do Cổng Thông tin điện tử Chính phủ công bố. Việc sử dụng toàn văn, bản hợp nhất, văn bản sửa đổi, văn bản hướng dẫn và cách diễn giải phải được kiểm tra theo văn bản hiện hành tại thời điểm sử dụng. Source map này không xác nhận rằng toàn bộ nội dung của luật, các văn bản hướng dẫn liên quan hoặc tình trạng sửa đổi sau ngày truy cập đã được rà soát đầy đủ.
Claims That Must Not Be Made	Không được phát minh số điều, khoản, điểm, định nghĩa, thời hạn, ngưỡng, điều kiện áp dụng, chế tài, quyền hoặc nghĩa vụ cụ thể. Không được trích dẫn nguyên văn hoặc khẳng định một diễn giải pháp lý nếu chưa đối chiếu trực tiếp văn bản hiện hành và bối cảnh áp dụng. Không được nói rằng hệ thống Nova Foods, một template, một API, một data model, một security control hoặc một quy trình trong handbook “tuân thủ Luật Bảo vệ dữ liệu cá nhân” chỉ vì có tham chiếu đến nguồn này. Không được xem source entry này là căn cứ đủ để xác định lawful basis, consent flow, retention period, cross-border transfer requirement, data-subject request process, breach response hoặc access-control design. Không được trình bày luật này như một tiêu chuẩn kỹ thuật, hướng dẫn kiến trúc, thay thế cho tư vấn pháp lý, hoặc bằng chứng rằng Nova Foods là một tổ chức có thật đang tuân thủ luật.

Ranh giới sử dụng trong case study Nova Foods

Nova Foods là doanh nghiệp mô phỏng phục vụ giáo dục. Các customer record, employee account, supplier contact, sales transaction, API payload và audit log được tạo trong handbook phải là dữ liệu tổng hợp. Việc một trường dữ liệu có vẻ nhận diện cá nhân trong ví dụ không tự động xác định nghĩa vụ pháp lý cụ thể; người học phải ghi nhận câu hỏi cần xác minh thay vì tự kết luận.

Trong handbook, nguồn này có thể hỗ trợ các câu hỏi phân tích ban đầu như:

• Dữ liệu nào trong CRM, Customer Master Data hoặc user account có thể liên quan đến cá nhân?
• Mục đích nghiệp vụ của từng trường dữ liệu là gì?
• Ai được phép truy cập, sửa, xuất hoặc xem dữ liệu?
• Dữ liệu có được truyền qua API, báo cáo, file export hoặc hệ thống tích hợp hay không?
• Có cần legal/privacy review trước khi baseline requirement hoặc triển khai hay không?

Các câu trả lời cụ thể phải được ghi nhận trong artifact phù hợp và được authority có thẩm quyền xác nhận. Không được biến câu hỏi phân tích thành kết luận pháp lý mặc định.

Quy tắc xác minh trước khi đưa nội dung vào handbook

Nhu cầu viết nội dung	Cách xử lý bắt buộc
Ghi nhận rằng privacy là một mối quan tâm cần xem xét trong CRM, user management, API và reporting	Có thể dùng entry này ở mức định hướng và phải phân biệt rõ đây là yêu cầu governance của handbook với nghĩa vụ pháp lý cụ thể.
Nêu định nghĩa, quyền, nghĩa vụ, căn cứ xử lý, thời hạn, điều kiện hoặc chế tài theo luật	Phải đối chiếu trực tiếp văn bản hiện hành; nếu chưa kiểm tra, gắn Verification required và không đưa ra kết luận áp dụng.
Chuyển một yêu cầu nghiệp vụ thành privacy requirement hoặc security requirement	BA có thể ghi nhận nhu cầu và câu hỏi cần xác minh; legal/privacy owner và security owner phải review nội dung trước khi baseline.
Thiết kế consent, notice, data-subject request, retention, deletion, anonymization hoặc breach process	Không tự quyết định từ source map. Cần legal/privacy review và technical/security review phù hợp.
Đánh giá một API, database schema, report hoặc access-control model là compliant	Không được kết luận chỉ từ việc có trường dữ liệu, phân quyền hoặc tham chiếu đến luật. Cần bằng chứng kiểm tra và phê duyệt của authority phù hợp.
Dùng dữ liệu trong ví dụ Nova Foods	Chỉ dùng synthetic personal data hoặc safe tokens như ${ACCESS_TOKEN}. Không dùng thông tin cá nhân thật, dữ liệu khách hàng thật, credential thật hoặc dữ liệu có thể xác định một cá nhân thực tế.

Giới hạn pháp lý: Luật Bảo vệ dữ liệu cá nhân là nguồn pháp lý chính thức, nhưng một source entry không thay thế việc đọc văn bản hiện hành, rà soát văn bản hướng dẫn và đánh giá bối cảnh cụ thể.

Yêu cầu thẩm quyền: Mọi diễn giải pháp lý và mọi quyết định có thể tạo nghĩa vụ privacy cho hệ thống Nova Foods phải được review bởi legal/privacy owner được ủy quyền. BA không được tự tuyên bố compliance hoặc quyết định cách áp dụng luật trong production.

Giới hạn giáo dục: Handbook chỉ giúp người học nhận diện rủi ro, đặt câu hỏi, tạo artifact phân tích và biết khi nào cần escalation. Handbook không thay thế tư vấn pháp lý, đánh giá privacy chuyên nghiệp, security assessment, phê duyệt production hoặc domain authority.

SRC-LAW-PRIVACY-002 — Nghị định hướng dẫn bảo vệ dữ liệu cá nhân

Trường	Giá trị
Source ID	SRC-LAW-PRIVACY-002
Title	Nghị định hướng dẫn bảo vệ dữ liệu cá nhân
Issuer	Chính phủ Việt Nam
Version / Status	Nghị định số 356/2025/NĐ-CP; có hiệu lực từ ngày 2026-01-01
Official URL	https://vanban.chinhphu.vn/?classid=1&docid=216387&pageid=27160
Access Date	2026-08-07
Authority Classification	Official Vietnamese law
Intended Curriculum Use	Dùng làm nguồn pháp lý chính thức ở mức định hướng để hỗ trợ các chapter và template về privacy governance trong Web ERP mô phỏng của Nova Foods. Các bối cảnh có thể cần nhận diện và escalation gồm: CRM & Customer Master Data; hồ sơ tài khoản người dùng nội bộ; thông tin liên hệ của khách hàng, nhà cung cấp và người phê duyệt; phân quyền; audit log; xuất báo cáo; tích hợp API; lưu trữ dữ liệu; và xử lý yêu cầu liên quan đến dữ liệu cá nhân. Nguồn này giúp người học hiểu rằng quy định dưới luật có thể chi phối cách một nghĩa vụ privacy được vận hành, nhưng không cho phép BA tự chuyển hóa thành control kỹ thuật hoặc requirement production cụ thể. Template families: privacy-impact question set, data inventory, data classification note, data-flow review, access-control requirement, API payload review, retention/deletion question set, legal-review record, escalation log và traceability matrix. Learner capability: biết phát hiện khi requirement, workflow, report hoặc integration có thể cần đối chiếu quy định privacy hiện hành; ghi nhận giả định, câu hỏi và dependency; đồng thời chuyển escalation đến legal/privacy owner và security owner trước khi baseline hoặc triển khai.
Verification Status	Verified đối với tên nguồn, issuer, số nghị định, ngày hiệu lực và URL chính thức theo verified source seed. Verification required đối với mọi nội dung về phạm vi điều chỉnh, đối tượng áp dụng, định nghĩa, quy trình, hồ sơ, thời hạn, điều kiện, trách nhiệm, ngoại lệ, biện pháp bảo vệ, chuyển dữ liệu, báo cáo, kiểm tra, xử lý vi phạm hoặc control kỹ thuật được suy ra từ nghị định.
Licensing / Access Caveat	URL là nguồn pháp lý chính thức do Cổng Thông tin điện tử Chính phủ công bố. Source map này không xác nhận việc đã rà soát toàn văn nghị định, văn bản sửa đổi, văn bản hợp nhất, văn bản hướng dẫn thi hành, tài liệu áp dụng của cơ quan có thẩm quyền hoặc các thay đổi có hiệu lực sau ngày truy cập. Khi sử dụng cho production, phải kiểm tra văn bản hiện hành trực tiếp từ nguồn chính thức và lưu bằng chứng review theo quy trình pháp lý của tổ chức.
Claims That Must Not Be Made	Không được phát minh số điều, khoản, điểm, biểu mẫu, thời hạn, ngưỡng, điều kiện, thủ tục, nghĩa vụ, ngoại lệ, chế tài hoặc yêu cầu kỹ thuật. Không được trích dẫn nguyên văn, diễn giải như kết luận pháp lý, hoặc khẳng định một flow consent, notice, data-subject request, retention, deletion, data transfer, breach response, audit log hay access control là bắt buộc theo nghị định nếu chưa kiểm tra trực tiếp văn bản hiện hành. Không được tuyên bố Nova Foods, handbook, template, API, database schema, report, workflow hoặc security control “tuân thủ Nghị định 356/2025/NĐ-CP” chỉ vì đã tham chiếu entry này. Không được dùng entry này để thay thế tư vấn pháp lý, privacy impact assessment, security assessment, phê duyệt của business owner hoặc quyết định production.

Ranh giới sử dụng trong case study Nova Foods

Nova Foods là case study mô phỏng; không phải doanh nghiệp thật, không đại diện cho một kết luận áp dụng pháp luật đối với bất kỳ tổ chức thực tế nào. Mọi customer profile, employee account, supplier contact, sales order, refund record, approval history, API request, audit event và báo cáo trong handbook phải dùng dữ liệu tổng hợp.

Nghị định này có thể được dùng để nhắc người học rằng các thiết kế có liên quan đến dữ liệu cá nhân cần được phân tích dưới cả góc độ nghiệp vụ, dữ liệu, bảo mật và pháp lý. Tuy nhiên, entry này không cho phép mặc định rằng tất cả dữ liệu trong ERP đều là dữ liệu cá nhân hoặc mọi control kỹ thuật đều là nghĩa vụ pháp lý.

Các tình huống phân tích hợp lệ trong handbook gồm:

• Xác định trường dữ liệu nào trong CRM, user management, supplier contact hoặc workflow approval có thể cần privacy review.
• Lập data-flow question set cho dữ liệu đi từ Web Client qua API Gateway, ERP Service, cơ sở dữ liệu, công cụ BI hoặc hệ thống tích hợp.
• Ghi nhận owner của dữ liệu, mục đích nghiệp vụ, nhóm người dùng được truy cập và rủi ro khi export dữ liệu.
• Đưa legal/privacy review thành dependency hoặc quality gate trước khi baseline một requirement có rủi ro cao.
• Phân biệt rõ Project convention, Author recommendation, Industry good practice, Verification required và nghĩa vụ pháp lý đã được legal owner xác nhận.

Quy tắc xác minh và gắn nhãn bắt buộc

Loại nội dung dự kiến trong handbook hoặc artifact Nova Foods	Cách gắn nhãn và xử lý bắt buộc
Nhận diện privacy là mối quan tâm trong CRM, account management, reporting, API và audit logging	Có thể trình bày như hướng dẫn phân tích hoặc governance của handbook. Không được gọi đây là nghĩa vụ pháp lý chi tiết của nghị định nếu chưa đối chiếu toàn văn.
Nêu yêu cầu cụ thể về consent, thông báo, quyền yêu cầu, lưu giữ, xóa, chia sẻ, chuyển dữ liệu, phản hồi sự cố hoặc hồ sơ chứng minh	Phải đối chiếu trực tiếp văn bản pháp lý hiện hành và được legal/privacy owner review. Nếu chưa có bằng chứng review, gắn Verification required.
Đề xuất mã hóa, masking, role-based access control, least privilege, audit log, tokenization hoặc API filtering	Gắn Industry good practice hoặc Author recommendation theo nguồn phù hợp; không được mô tả là yêu cầu bắt buộc của Nghị định 356/2025/NĐ-CP nếu chưa có xác minh pháp lý.
Đặt thời hạn retention, deletion, phản hồi yêu cầu hoặc lưu audit trail	Gắn Project assumption nếu phục vụ mô phỏng học tập mà không có xác minh trực tiếp. Không được trình bày giả định này như thời hạn luật định.
Chuyển business need thành privacy requirement	BA được phép ghi nhận need, phạm vi dữ liệu, rủi ro và câu hỏi. Legal/privacy owner xác nhận diễn giải pháp lý; security/architecture owner xác nhận tính khả thi của control; business owner xác nhận trade-off nghiệp vụ.
Đánh giá API, database, report hoặc workflow là compliant	Không được kết luận từ source map, checklist hoặc sự hiện diện của một control. Cần bằng chứng kiểm tra, phạm vi đánh giá xác định, review của authority phù hợp và phê duyệt theo governance dự án.
Dùng thông tin cá nhân trong completed artifact hoặc test data	Chỉ dùng synthetic personal data. Không sử dụng dữ liệu thật của khách hàng, nhân viên, nhà cung cấp, credential, số định danh hoặc dữ liệu có thể xác định một cá nhân thực tế.

Yêu cầu thẩm quyền: Diễn giải Nghị định 356/2025/NĐ-CP, xác định nghĩa vụ của tổ chức và phê duyệt requirement có hệ quả privacy phải do legal/privacy owner được ủy quyền thực hiện. BA có trách nhiệm chuẩn bị facts, data flow, business purpose, options, decision log và escalation record; BA không tự ban hành kết luận pháp lý.

Ranh giới kỹ thuật: Một control kỹ thuật hợp lý, chẳng hạn phân quyền hoặc nhật ký thao tác, không tự chứng minh legal compliance. Requirement kỹ thuật cần traceability đến business need, risk, decision authority và bằng chứng review phù hợp.

Giới hạn giáo dục: Entry này chỉ hỗ trợ người học nhận diện rủi ro và thực hiện escalation đúng lúc. Nó không thay thế tư vấn pháp lý, tư vấn privacy, kiểm toán tuân thủ, đánh giá bảo mật, thẩm quyền kế toán hoặc phê duyệt production.

SRC-LAW-ACCT-001 — Luật Kế toán

Trường	Giá trị
Source ID	SRC-LAW-ACCT-001
Title	Luật Kế toán
Issuer	Quốc hội Việt Nam
Version / Status	Luật số 88/2015/QH13; có hiệu lực từ ngày 2017-01-01
Official URL	https://vanban.chinhphu.vn/?docid=183198&pageid=27160
Access Date	2026-08-07
Authority Classification	Official Vietnamese law
Intended Curriculum Use	Dùng làm nguồn pháp lý chính thức để định hướng các chapter và template liên quan đến finance, accounting integration, receivables, invoice/ledger reasoning, audit trail, chứng từ, và kiểm soát dữ liệu kế toán trong Web ERP mô phỏng Nova Foods. Nguồn này giúp người học nhận diện rằng các requirement về ghi nhận giao dịch, đối soát, lưu trữ chứng từ, kiểm tra sổ sách, kiểm soát sửa đổi và báo cáo tài chính có thể chịu ràng buộc pháp lý hoặc quy trình kiểm toán. Template families: accounting-process question set, invoice/ledger traceability matrix, transaction evidence register, finance integration requirement note, accounting data dictionary, approval-and-control checklist, exception log, legal-review record, and regression/UAT mapping for finance flows. Learner capability: biết phát hiện khi requirement, workflow, report, API, database field, hoặc control tài chính cần kế toán review; ghi nhận facts, data flow, pending questions, and escalation path; không tự diễn giải nghĩa vụ kế toán thành control production khi chưa có xác nhận của thẩm quyền phù hợp.
Verification Status	Verified đối với tên nguồn, issuer, số luật, ngày hiệu lực và URL chính thức theo verified source seed. Verification required đối với mọi nội dung về nguyên tắc ghi sổ, chứng từ, lưu trữ, kiểm tra, báo cáo, trách nhiệm, thẩm quyền, thời hạn, cấu phần hồ sơ, quy trình sửa đổi, hay yêu cầu kiểm soát cụ thể nếu chưa đối chiếu trực tiếp toàn văn luật và văn bản hướng dẫn hiện hành.
Licensing / Access Caveat	URL là nguồn pháp lý chính thức do Cổng Thông tin điện tử Chính phủ công bố. Source map này không xác nhận việc đã rà soát toàn văn luật, văn bản sửa đổi, văn bản hợp nhất, nghị định hướng dẫn, thông tư hướng dẫn, hoặc tài liệu giải thích có thẩm quyền. Trước khi sử dụng cho production hoặc baseline requirement, phải kiểm tra văn bản hiện hành trực tiếp từ nguồn chính thức và lưu bằng chứng review theo quy trình governance của tổ chức.
Claims That Must Not Be Made	Không được phát minh điều, khoản, điểm, biểu mẫu, thời hạn, ngưỡng, nguyên tắc ghi nhận, điều kiện, ngoại lệ, trách nhiệm, chế tài, hay yêu cầu kiểm soát kế toán. Không được trích dẫn nguyên văn hoặc diễn giải như kết luận pháp lý nếu chưa kiểm tra trực tiếp văn bản hiện hành. Không được khẳng định một workflow, ledger, report, invoice flow, reconciliation process, audit trail, hay accounting integration trong Nova Foods “tuân thủ Luật Kế toán” chỉ vì đã tham chiếu entry này. Không được dùng entry này để thay thế tư vấn kế toán, tư vấn pháp lý, kiểm toán, hoặc phê duyệt của business owner/authorized accounting role.

Ranh giới sử dụng trong case study Nova Foods

Nova Foods là case study mô phỏng; không đại diện cho bất kỳ kết luận pháp lý hay kế toán áp dụng cho một doanh nghiệp thực tế nào. Mọi invoice, journal entry, receipt, payment record, inventory valuation, cost allocation, approval history, reconciliation output, và financial report trong handbook phải dùng dữ liệu tổng hợp, synthetic, và phục vụ mục đích giáo dục.

Luật Kế toán có thể được dùng để nhắc người học rằng các thiết kế liên quan đến finance và accounting trong ERP cần được phân tích dưới góc độ nghiệp vụ, dữ liệu, kiểm soát, và thẩm quyền phê duyệt. Tuy nhiên, entry này không cho phép BA tự suy ra cách ghi nhận kế toán, mô hình sổ sách, chuẩn lưu trữ chứng từ, hay yêu cầu audit cụ thể nếu chưa có bằng chứng review từ người có thẩm quyền.

Các tình huống phân tích hợp lệ trong handbook gồm:

• Xác định trường dữ liệu nào trong sales-to-cash, procurement-to-pay, inventory movement, hoặc production costing có thể cần kế toán review.
• Lập question set cho luồng dữ liệu từ Web Client qua API Gateway, ERP Service, database, BI reports, và export file liên quan đến finance.
• Ghi nhận business purpose của chứng từ, người tạo, người duyệt, người kiểm tra, và mức độ truy vết cần thiết.
• Đưa accounting review thành dependency hoặc quality gate trước khi baseline requirement có tác động đến số liệu tài chính.
• Phân biệt rõ Project convention, Author recommendation, Industry good practice, Verification required, và nghĩa vụ pháp lý đã được authorized accounting/legal reviewer xác nhận.

Quy tắc xác minh và gắn nhãn bắt buộc

Loại nội dung dự kiến trong handbook hoặc artifact Nova Foods	Cách gắn nhãn và xử lý bắt buộc
Nhận diện rằng một requirement, report, API, hoặc workflow có tác động đến kế toán	Có thể trình bày như phân tích nghiệp vụ hoặc governance của handbook. Không được gọi đây là nghĩa vụ pháp lý chi tiết nếu chưa đối chiếu toàn văn luật và văn bản hướng dẫn hiện hành.
Nêu yêu cầu cụ thể về ghi sổ, chứng từ, lưu trữ, đối chiếu, kiểm soát sửa đổi, hoặc hồ sơ kiểm toán	Phải đối chiếu trực tiếp văn bản pháp lý hiện hành và được authorized accounting/legal review. Nếu chưa có bằng chứng review, gắn Verification required.
Đề xuất workflow approval, audit trail, locking, versioning, reconciliation, segregation of duties, hoặc evidence capture	Gắn Industry good practice hoặc Author recommendation theo nguồn phù hợp; không được mô tả là yêu cầu bắt buộc của Luật Kế toán nếu chưa có xác minh pháp lý.
Đặt thời hạn lưu trữ, chính sách hủy, hoặc tiêu chuẩn kiểm soát hồ sơ	Gắn Project assumption nếu phục vụ mô phỏng học tập mà không có xác minh trực tiếp. Không được trình bày giả định này như thời hạn luật định.
Chuyển business need thành accounting requirement	BA được phép ghi nhận need, phạm vi dữ liệu, rủi ro, và câu hỏi. Accounting/legal reviewer xác nhận diễn giải pháp lý; architect/security xác nhận tính khả thi; business owner xác nhận trade-off nghiệp vụ.
Đánh giá một invoice flow, ledger, report, hoặc ERP integration là compliant	Không được kết luận từ source map, checklist, hoặc sự tồn tại của một control. Cần bằng chứng kiểm tra, phạm vi đánh giá xác định, review của authority phù hợp, và phê duyệt theo governance dự án.
Dùng thông tin trong completed artifact hoặc test data	Chỉ dùng synthetic data. Không sử dụng dữ liệu thật của khách hàng, nhân viên, nhà cung cấp, chứng từ thật, số tài khoản, mã số thuế, hoặc dữ liệu có thể xác định một cá nhân hay tổ chức thực tế.

Yêu cầu thẩm quyền: Diễn giải Luật Kế toán, xác định nghĩa vụ của tổ chức, và phê duyệt requirement có hệ quả kế toán phải do authorized accounting/legal role thực hiện. BA có trách nhiệm chuẩn bị facts, process context, data flow, options, decision log, và escalation record; BA không tự ban hành kết luận pháp lý hay kết luận kế toán.

Ranh giới kỹ thuật: Một control kỹ thuật hợp lý, chẳng hạn audit log hoặc approval workflow, không tự chứng minh compliance kế toán. Requirement kỹ thuật cần traceability đến business need, risk, decision authority, và bằng chứng review phù hợp.

Giới hạn giáo dục: Entry này chỉ hỗ trợ người học nhận diện rủi ro và thực hiện escalation đúng lúc. Nó không thay thế tư vấn kế toán, tư vấn pháp lý, kiểm toán, đánh giá kiểm soát nội bộ, hoặc phê duyệt production.

SRC-LAW-INV-001 — Nghị định 123/2020/NĐ-CP về hóa đơn, chứng từ

Trường	Giá trị
Source ID	SRC-LAW-INV-001
Title	Nghị định 123/2020/NĐ-CP về hóa đơn, chứng từ
Issuer	Chính phủ Việt Nam
Version / Status	Nghị định số 123/2020/NĐ-CP; có hiệu lực từ ngày 2022-07-01
Official URL	https://vanban.chinhphu.vn/?docid=201365&pageid=27160
Access Date	2026-08-07
Authority Classification	Official Vietnamese law
Intended Curriculum Use	Dùng làm nguồn pháp lý chính thức để nhận diện các ràng buộc nghiệp vụ và dữ liệu có thể liên quan đến hóa đơn, chứng từ, luồng phát hành chứng từ, lưu vết giao dịch, đối soát doanh thu, và tích hợp giữa sales, finance, accounting, và reporting trong Web ERP mô phỏng Nova Foods. Nguồn này đặc biệt hữu ích cho các chapter và template liên quan đến order-to-cash, invoice lifecycle, return/refund flows, accounting integration, document evidence, approval workflow, traceability, audit-oriented logging, exception handling, và UAT cho các nghiệp vụ có phát sinh chứng từ. Template families: invoice process discovery sheet, invoice data field catalog, invoice-state transition specification, accounting handoff checklist, legal-review question log, exception/void/correction matrix, sales-to-invoice traceability matrix, API contract note for invoice-related endpoints, and finance regression test mapping. Learner capability: biết phát hiện khi một requirement, workflow, screen, report, API payload, batch job, export file, hoặc integration event có thể chạm vào nghĩa vụ về hóa đơn/chứng từ; biết gắn Verification required, chuẩn bị câu hỏi cho accounting/legal reviewer, và không tự chuyển nhận thức nghiệp vụ thành khẳng định tuân thủ pháp lý.
Verification Status	Verified đối với tên nguồn, issuer, số nghị định, ngày hiệu lực và URL chính thức theo verified source seed. Verification required đối với mọi diễn giải chi tiết về loại hóa đơn/chứng từ, điều kiện phát hành, cấu phần nội dung, định dạng dữ liệu, thời điểm lập, xử lý sai sót, thay thế, điều chỉnh, hủy, lưu trữ, truyền nhận điện tử, trách nhiệm các bên, hoặc mọi nghĩa vụ cụ thể khác nếu chưa đối chiếu trực tiếp toàn văn nghị định và văn bản sửa đổi/bổ sung/hướng dẫn hiện hành.
Licensing / Access Caveat	URL là nguồn pháp lý chính thức do Cổng Thông tin điện tử Chính phủ công bố. Source map này không xác nhận rằng toàn văn nghị định, mọi văn bản sửa đổi, văn bản hợp nhất, nghị định liên quan, thông tư hướng dẫn, hay diễn giải có thẩm quyền đã được rà soát đầy đủ. Vì verified source seed đã nêu rõ “verify later amendments before production use”, mọi sử dụng cho production, baseline requirement, compliance claim, hoặc legal sign-off phải kiểm tra lại văn bản hiện hành trực tiếp từ nguồn chính thức và lưu bằng chứng review.
Claims That Must Not Be Made	Không được phát minh điều, khoản, điểm, biểu mẫu, ngưỡng, thời hạn, trạng thái xử lý, ngoại lệ, trách nhiệm pháp lý, hay tiêu chuẩn dữ liệu của hóa đơn/chứng từ. Không được khẳng định một invoice flow, refund note, debit/credit adjustment, document numbering logic, approval rule, archival policy, API integration, hay reporting output trong Nova Foods là “tuân thủ Nghị định 123/2020/NĐ-CP” chỉ vì đã tham chiếu entry này. Không được suy diễn rằng mọi yêu cầu e-invoice, cancellation, replacement, adjustment, tax data handling, hay transmission flow đã đúng pháp luật nếu chưa có authorized accounting/legal review. Không được dùng entry này để thay thế tư vấn pháp lý, tư vấn thuế, tư vấn kế toán, hoặc phê duyệt production.

Ranh giới sử dụng trong case study Nova Foods

Nova Foods là case study mô phỏng phục vụ đào tạo; mọi invoice, receipt, return document, shipment evidence, payment reference, adjustment note, report extract, và audit log trong handbook phải là synthetic data, không đại diện cho hồ sơ pháp lý của bất kỳ doanh nghiệp thực tế nào.

Entry này cho phép handbook hướng dẫn người học cách nhận diện những điểm giao cắt giữa nghiệp vụ bán hàng, tài chính, kế toán, dữ liệu, API, và kiểm soát chứng từ. Ví dụ, BA có thể học cách đặt câu hỏi về thời điểm phát sinh chứng từ, ai là người tạo/duyệt/phát hành, trường dữ liệu nào cần lưu để đối soát, hay luồng nào cần traceability từ order đến payment đến invoice artifact. Tuy nhiên, entry này không cho phép BA tự xác định nội dung bắt buộc của hóa đơn, chính sách đánh số, quy tắc phát hành điện tử, xử lý sai sót, hay nghĩa vụ lưu trữ mà không có xác minh trực tiếp từ văn bản hiện hành và review của role có thẩm quyền.

Các tình huống phân tích hợp lệ trong handbook gồm:

• Xác định nơi nào trong sales order flow, fulfillment flow, return/refund flow, receivables flow, hoặc accounting integration có thể phát sinh nhu cầu tạo hoặc tham chiếu hóa đơn/chứng từ.
• Lập danh sách câu hỏi cho accounting/legal reviewer về dữ liệu bắt buộc, trạng thái chứng từ, dependency giữa order state và invoice state, hoặc bằng chứng cần giữ lại.
• Thiết kế traceability giữa business need, requirement, business rule, acceptance criteria, test case, và document evidence mà không tự tuyên bố giá trị pháp lý của artifact.
• Mô tả các control kỹ thuật như audit logging, immutable event trail, approval capture, version history, và exception queue dưới nhãn Industry good practice, Project convention, hoặc Author recommendation khi chưa có xác minh pháp lý trực tiếp.
• Đưa accounting/legal review thành quality gate bắt buộc trước khi baseline bất kỳ requirement nào có tác động đến invoice/document generation, tax-facing data, hoặc chứng từ tài chính.

Quy tắc xác minh và gắn nhãn bắt buộc

Loại nội dung dự kiến trong handbook hoặc artifact Nova Foods	Cách gắn nhãn và xử lý bắt buộc
Nhận diện rằng một flow bán hàng, trả hàng, thanh toán, hay công nợ có thể liên quan đến hóa đơn/chứng từ	Có thể trình bày như phân tích nghiệp vụ và traceability context. Không được suy ra nghĩa vụ pháp lý chi tiết nếu chưa đối chiếu văn bản hiện hành.
Nêu yêu cầu cụ thể về thời điểm lập hóa đơn, nội dung hóa đơn, xử lý sai sót, thay thế, điều chỉnh, hủy, truyền nhận, hoặc lưu trữ chứng từ	Phải được đối chiếu trực tiếp với văn bản pháp lý hiện hành và có authorized accounting/legal review. Nếu chưa có bằng chứng review, gắn Verification required.
Mô tả số chứng từ, trạng thái chứng từ, numbering pattern, locking, audit log, versioning, retry queue, hoặc reconciliation workflow trong ERP	Nếu không được dẫn xuất trực tiếp từ văn bản đã xác minh, gắn Project convention, Industry good practice, hoặc Author recommendation theo nguồn phù hợp; không gọi đó là yêu cầu pháp lý bắt buộc.
Đề xuất field mapping giữa sales order, delivery, payment, invoice, tax report, hoặc BI report	Có thể dùng cho mục đích phân tích hệ thống và data design trong case study. Nếu field được mô tả là “bắt buộc theo luật”, phải có xác minh trực tiếp; nếu chưa có, gắn Verification required.
Thiết lập rule cho refund, return, void, correction, hoặc replacement document	BA chỉ được mô tả fact pattern, state transitions, option set, và impact analysis. Mọi kết luận về hình thức chứng từ hợp lệ phải do authorized accounting/legal reviewer xác nhận.
Đánh giá một API, screen, report, export file, hay integration với external invoicing service là compliant	Không được kết luận chỉ từ source map, test results nội bộ, hay sự tồn tại của control kỹ thuật. Cần phạm vi đánh giá rõ ràng, kiểm tra văn bản hiện hành, và phê duyệt của authority phù hợp.
Dùng dữ liệu invoice/chứng từ trong completed artifacts, examples, test data, hoặc screenshots	Chỉ dùng synthetic data. Không dùng hóa đơn thật, mã số thuế thật, tên pháp nhân thật, địa chỉ thật, mã giao dịch thật, hoặc dữ liệu có thể liên hệ đến cá nhân/tổ chức thực tế.

Yêu cầu thẩm quyền: Diễn giải Nghị định 123/2020/NĐ-CP, xác định nghĩa vụ pháp lý về hóa đơn/chứng từ, và phê duyệt requirement có ảnh hưởng đến thuế/kế toán/chứng từ phải do authorized accounting/legal role thực hiện. BA có trách nhiệm chuẩn bị facts, process maps, data flows, option analysis, dependency log, và escalation record; BA không tự ban hành kết luận pháp lý.

Ràng buộc production: Verified source seed đã xác định rõ phải kiểm tra các sửa đổi về sau trước khi dùng cho production. Vì vậy, mọi requirement, template, test case, API contract note, hoặc completed artifact có chạm đến hóa đơn/chứng từ phải xem entry này là điểm bắt đầu cho escalation và verification, không phải bằng chứng đầy đủ để triển khai.

Quy tắc gắn nhãn bắt buộc: Mọi chi tiết về thuế, kế toán, hóa đơn điện tử, thời hạn, định dạng chứng từ, labor, privacy, và food-traceability nếu không được đối chiếu trực tiếp với văn bản chính thức hiện hành phải gắn Project assumption hoặc Verification required. Không được xóa hoặc hạ nhãn những cảnh báo này một cách im lặng.

Giới hạn giáo dục: Entry này hỗ trợ người học nhận diện rủi ro, dependency, và điểm cần review trong các luồng order-to-cash và finance integration của Nova Foods. Nó không thay thế tư vấn pháp lý, tư vấn thuế, tư vấn kế toán, đánh giá tuân thủ, hay phê duyệt production.

Luật An toàn thực phẩm (Quốc hội Việt Nam)

Trường	Giá trị
Source ID	SRC-LAW-FS-001
Title	Luật An toàn thực phẩm
Issuer	Quốc hội Việt Nam
Version / Status	Luật số 55/2010/QH12; nguồn pháp lý chính thức theo verified source seed
Official URL	https://vanban.chinhphu.vn/?docid=96032&pageid=27160
Access Date	2026-08-07
Authority Classification	Official Vietnamese law
Intended Curriculum Use	Dùng làm nguồn pháp lý chính thức để nhận diện các điểm giao cắt giữa yêu cầu an toàn thực phẩm và thiết kế quy trình/nghiệp vụ trong case study Nova Foods, đặc biệt ở các chapter và template liên quan đến procurement, warehouse, inventory lot/batch tracking, production planning, manufacturing execution, quality control, recall/exception handling, traceability, supplier qualification, receiving inspection, storage conditions, and operational reporting. Nguồn này giúp người học biết nơi nào cần đặt câu hỏi về nguồn gốc nguyên liệu, lô/batch, hạn dùng, điều kiện bảo quản, truy vết dòng chảy hàng hóa, bằng chứng kiểm tra chất lượng, và điểm escalation tới business owner, QA, hoặc legal reviewer.
Verification Status	Verified đối với tên nguồn, issuer, số luật, và URL chính thức theo verified source seed. Verification required đối với mọi diễn giải chi tiết về nghĩa vụ an toàn thực phẩm, điều kiện sản xuất/kinh doanh, truy xuất nguồn gốc, thu hồi sản phẩm, ghi nhãn, hồ sơ lưu trữ, kiểm nghiệm, điều kiện bảo quản, vận chuyển, trách nhiệm của các bên, hoặc mọi yêu cầu kỹ thuật/tuân thủ khác nếu chưa đối chiếu trực tiếp với toàn văn hiện hành và văn bản hướng dẫn/sửa đổi liên quan.
Licensing / Access Caveat	URL là nguồn pháp lý chính thức được cung cấp trong verified source seed. Source map này không xác nhận rằng toàn văn luật hiện hành, mọi văn bản sửa đổi, nghị định hướng dẫn, thông tư liên quan, hoặc diễn giải có thẩm quyền đã được rà soát đầy đủ. Vì case study Nova Foods chỉ là mô phỏng giáo dục, mọi sử dụng cho baseline requirement, production design, compliance claim, hoặc sign-off phải kiểm tra lại văn bản hiện hành trực tiếp từ nguồn chính thức và lưu bằng chứng review bởi role có thẩm quyền.
Claims That Must Not Be Made	Không được phát minh điều, khoản, điểm, thuật ngữ chuyên ngành, ngưỡng an toàn, thời hạn, quy trình kiểm nghiệm, tiêu chuẩn ghi nhãn, quy tắc truy xuất, yêu cầu thu hồi, điều kiện bảo quản, hoặc trách nhiệm pháp lý cụ thể của Luật An toàn thực phẩm. Không được khẳng định một quy trình procurement, receiving, storage, batch tracking, production, QA, recall flow, API, report, hay control trong Nova Foods là “tuân thủ Luật An toàn thực phẩm” chỉ vì đã tham chiếu entry này. Không được suy diễn rằng mọi rule về traceability, shelf life, lot control, hygiene control, supplier approval, hoặc product recall đã đúng pháp luật nếu chưa có legal/QA review được ủy quyền. Không được dùng entry này thay thế tư vấn pháp lý, tư vấn an toàn thực phẩm, tư vấn QA, hoặc phê duyệt production.

Ranh giới sử dụng trong case study Nova Foods

Nova Foods là case study mô phỏng phục vụ đào tạo; mọi nguyên liệu, lô hàng, biên bản kiểm tra, phiếu nhập kho, phiếu xuất kho, record sản xuất, record QA, báo cáo thu hồi, và log truy xuất trong handbook phải là synthetic data, không đại diện cho hồ sơ pháp lý hay dữ liệu vận hành thực tế của bất kỳ doanh nghiệp nào.

Entry này cho phép handbook hướng dẫn người học cách nhận diện các điểm giao cắt giữa nghiệp vụ và an toàn thực phẩm trong chuỗi Nova Foods. Ví dụ, BA có thể học cách xác định nơi nào cần lưu lot/batch, hạn dùng, điều kiện bảo quản, nguồn cung, biên bản kiểm tra đầu vào, hoặc dấu vết truy xuất từ nhà cung cấp đến sản xuất đến phân phối. Tuy nhiên, entry này không cho phép BA tự kết luận nghĩa vụ pháp lý cụ thể về nội dung hồ sơ, ngưỡng an toàn, tiêu chuẩn kiểm nghiệm, hay quy trình thu hồi mà không đối chiếu trực tiếp với văn bản hiện hành và review từ role có thẩm quyền.

Các tình huống phân tích hợp lệ trong handbook gồm:

• Xác định điểm nào trong procurement, receiving, warehouse, production, QA, distribution, hoặc recall flow có thể phát sinh yêu cầu về an toàn thực phẩm hoặc truy xuất nguồn gốc.
• Lập danh sách câu hỏi cho legal reviewer, QA owner, hoặc business owner về hồ sơ lô/batch, điều kiện lưu kho, chứng cứ kiểm tra, và trách nhiệm phê duyệt.
• Thiết kế traceability giữa business need, requirement, business rule, acceptance criteria, test case, và evidence artifact mà không tự tuyên bố giá trị pháp lý của tài liệu.
• Mô tả các control kỹ thuật như lot tracking, immutable audit log, chain-of-custody record, exception queue, approval capture, và recall trace dưới nhãn Industry good practice, Project convention, hoặc Author recommendation khi chưa có xác minh pháp lý trực tiếp.
• Đặt QA review và legal review làm quality gate trước khi baseline bất kỳ requirement nào có tác động đến nhận hàng, sản xuất, bảo quản, truy xuất, hoặc thu hồi sản phẩm.

Quy tắc xác minh và gắn nhãn bắt buộc

Loại nội dung dự kiến trong handbook hoặc artifact Nova Foods	Cách gắn nhãn và xử lý bắt buộc
Nhận diện rằng một quy trình mua hàng, nhập kho, sản xuất, lưu kho, phân phối, hoặc thu hồi có thể liên quan đến an toàn thực phẩm	Có thể trình bày như phân tích nghiệp vụ và traceability context. Không được suy ra nghĩa vụ pháp lý chi tiết nếu chưa đối chiếu văn bản hiện hành.
Nêu yêu cầu cụ thể về tiêu chuẩn an toàn, điều kiện kiểm nghiệm, hồ sơ kiểm tra, ghi nhãn, bảo quản, vận chuyển, truy xuất, hoặc thu hồi	Phải được đối chiếu trực tiếp với văn bản pháp lý hiện hành và có review bởi legal/QA role có thẩm quyền. Nếu chưa có bằng chứng review, gắn Verification required.
Mô tả lot/batch number, shelf-life logic, storage conditions, inspection status, hold/release, recall status, hoặc chain-of-custody trong ERP	Nếu không được dẫn xuất trực tiếp từ văn bản đã xác minh, gắn Project convention, Industry good practice, hoặc Author recommendation theo nguồn phù hợp; không gọi đó là yêu cầu pháp lý bắt buộc.
Đề xuất field mapping giữa supplier, receiving, inventory, production, QA, recall, hoặc reporting	Có thể dùng cho mục đích phân tích hệ thống và data design trong case study. Nếu field được mô tả là “bắt buộc theo luật”, phải có xác minh trực tiếp; nếu chưa có, gắn Verification required.
Đánh giá một API, screen, report, export file, hay integration là compliant về an toàn thực phẩm	Không được kết luận chỉ từ source map, test results nội bộ, hay sự tồn tại của control kỹ thuật. Cần phạm vi đánh giá rõ ràng, kiểm tra văn bản hiện hành, và phê duyệt của authority phù hợp.
Dùng dữ liệu an toàn thực phẩm, lô hàng, kiểm nghiệm, hoặc thu hồi trong completed artifacts, examples, test data, hoặc screenshots	Chỉ dùng synthetic data. Không dùng hồ sơ thật, mã lô thật, tên nhà cung cấp thật, địa chỉ thật, số chứng từ thật, hoặc dữ liệu có thể liên hệ đến cá nhân/tổ chức thực tế.

Yêu cầu thẩm quyền: Diễn giải Luật An toàn thực phẩm, xác định nghĩa vụ pháp lý liên quan đến truy xuất nguồn gốc, kiểm soát chất lượng, lưu kho, vận chuyển, thu hồi, và phê duyệt requirement có tác động đến an toàn thực phẩm phải do legal/QA role có thẩm quyền thực hiện. BA có trách nhiệm chuẩn bị facts, process maps, data flows, option analysis, dependency log, và escalation record; BA không tự ban hành kết luận pháp lý.

Ràng buộc production: Verified source seed xác định nguồn này là nguồn pháp lý chính thức nhưng không thay thế rà soát văn bản hiện hành và các văn bản hướng dẫn/sửa đổi liên quan trước khi dùng cho production. Vì vậy, mọi requirement, template, test case, API contract note, hoặc completed artifact có chạm đến an toàn thực phẩm phải xem entry này là điểm khởi đầu cho escalation và verification, không phải bằng chứng đầy đủ để triển khai.

Quy tắc gắn nhãn bắt buộc: Mọi chi tiết về thuế, kế toán, hóa đơn, labor, privacy, và food-traceability nếu không được đối chiếu trực tiếp với văn bản chính thức hiện hành phải gắn Project assumption hoặc Verification required. Không được xóa hoặc hạ nhãn những cảnh báo này một cách im lặng.

Giới hạn giáo dục: Entry này hỗ trợ người học nhận diện rủi ro, dependency, và điểm cần review trong các luồng procurement, warehouse, production, QA, recall, và reporting của Nova Foods. Nó không thay thế tư vấn pháp lý, tư vấn an toàn thực phẩm, đánh giá tuân thủ, hay phê duyệt production.

Danh mục nguồn pháp lý và quy định chính thức của Việt Nam

Source ID	Title	Issuer	Version / Status	Official URL	Access Date	Authority Classification	Intended Curriculum Use	Verification Status	Licensing / Access Caveat	Claims That Must Not Be Made
SRC-LAW-PRIV-001	Luật Bảo vệ dữ liệu cá nhân	Quốc hội Việt Nam	Luật số 91/2025/QH15; có hiệu lực từ 2026-01-01 theo verified source seed	https://vanban.chinhphu.vn/?classid=1&docid=214590&pageid=27160&typegroup=	2026-08-07	Official Vietnamese law	Dùng để xác định các điểm cần phân tích và escalation về dữ liệu cá nhân trong các chapter/template Nova Foods liên quan đến CRM, customer master data, sales order, loyalty/promotion, user account, approval workflow, audit log, reporting, API, integration, security, testing và change governance.	Verified đối với tên nguồn, issuer, số luật, ngày hiệu lực và URL theo verified source seed. Verification required đối với mọi yêu cầu hệ thống, diễn giải nghĩa vụ, phân loại dữ liệu, căn cứ xử lý, quyền chủ thể dữ liệu, thời hạn, biểu mẫu, thủ tục, ngoại lệ, chuyển dữ liệu, biện pháp bảo vệ hoặc trách nhiệm cụ thể chưa được đối chiếu trực tiếp với toàn văn hiện hành và review có thẩm quyền.	URL là nguồn chính thức được cung cấp trong verified source seed. Source map không xác nhận rằng toàn văn, văn bản sửa đổi, văn bản hướng dẫn thi hành, bản hợp nhất hoặc diễn giải có thẩm quyền đã được rà soát đầy đủ. Không suy diễn quyền sử dụng, tái xuất bản hoặc cấp phép nội dung ngoài phạm vi truy cập nguồn chính thức.	Không được phát minh điều, khoản, điểm, định nghĩa, thời hạn, ngưỡng, thủ tục, ngoại lệ hoặc nghĩa vụ cụ thể. Không được tuyên bố CRM, ERP, API, data model, consent flow, audit log, report hoặc control của Nova Foods “tuân thủ Luật Bảo vệ dữ liệu cá nhân” chỉ từ entry này. Không được dùng entry thay cho tư vấn pháp lý, privacy assessment, phê duyệt của data/privacy owner hoặc production compliance sign-off.
SRC-DEC-PRIV-001	Nghị định hướng dẫn bảo vệ dữ liệu cá nhân	Chính phủ Việt Nam	Nghị định số 356/2025/NĐ-CP; có hiệu lực từ 2026-01-01 theo verified source seed	https://vanban.chinhphu.vn/?classid=1&docid=216387&pageid=27160	2026-08-07	Official Vietnamese law	Dùng để nhận diện các dependency pháp lý cần kiểm tra khi chuyển hóa privacy concern thành requirement, business rule, consent/notice workflow, access-control requirement, integration control, retention requirement, test condition hoặc UAT evidence trong case study Nova Foods.	Verified đối với tên nguồn, issuer, số nghị định, ngày hiệu lực và URL theo verified source seed. Verification required đối với mọi diễn giải về cơ chế hướng dẫn, hồ sơ, biểu mẫu, trình tự, trách nhiệm tổ chức/cá nhân, deadline, ngoại lệ, biện pháp kỹ thuật hoặc nghĩa vụ vận hành chưa được đối chiếu trực tiếp với văn bản hiện hành và các nguồn pháp lý liên quan.	URL là nguồn chính thức được cung cấp trong verified source seed. Source map không chứng minh nghị định là văn bản duy nhất điều chỉnh chủ đề bảo vệ dữ liệu cá nhân, cũng không xác nhận rằng mọi cập nhật, sửa đổi, thay thế, bản hợp nhất hoặc hướng dẫn có thẩm quyền đã được rà soát.	Không được âm thầm dựa vào giả định privacy cũ hoặc giả định rằng một cơ chế consent, access control, data export, deletion, retention, notification hay vendor integration của Nova Foods đáp ứng nghị định. Không được gán điều khoản, quy trình, biểu mẫu, deadline hoặc nghĩa vụ cụ thể nếu chưa xác minh trực tiếp. Không được xem đây là tư vấn pháp lý hoặc căn cứ duy nhất cho production release.
SRC-LAW-ACCT-001	Luật Kế toán	Quốc hội Việt Nam	Luật số 88/2015/QH13; có hiệu lực từ 2017-01-01 theo verified source seed	https://vanban.chinhphu.vn/?docid=183198&pageid=27160	2026-08-07	Official Vietnamese law	Dùng làm nguồn nhận diện khu vực cần review về accounting records, document integrity, accounting integration, receivables, journal/interface design, approval, auditability, reporting, data retention và reconciliation trong các chapter/template Nova Foods liên quan đến finance, accounting integration, API, data model, testing, UAT và governance.	Verified đối với tên nguồn, issuer, số luật, ngày hiệu lực và URL theo verified source seed. Verification required đối với mọi diễn giải về chứng từ kế toán, sổ sách, thời hạn lưu trữ, chữ ký, định khoản, phương pháp ghi nhận, điều kiện hợp lệ, trách nhiệm kế toán, báo cáo tài chính, audit requirement hoặc dữ liệu bắt buộc chưa được kiểm tra trực tiếp với văn bản hiện hành và role có thẩm quyền.	URL là nguồn chính thức được cung cấp trong verified source seed. Source map không xác nhận rằng luật đã được rà soát cùng toàn bộ văn bản sửa đổi, hướng dẫn, chuẩn mực, chế độ kế toán, quy định thuế hoặc quy định ngành có liên quan. Nội dung có thể truy cập công khai không đồng nghĩa với quyền tái xuất bản toàn văn trong handbook.	Không được khẳng định chart of accounts, journal posting, receivable flow, reconciliation rule, accounting API, export file, report, retention configuration hoặc test case của Nova Foods “đúng Luật Kế toán” chỉ vì có entry này. Không được tự suy diễn định khoản, thời điểm ghi nhận, biểu mẫu chứng từ, thời hạn lưu trữ hoặc trách nhiệm pháp lý cụ thể. Không được dùng entry thay cho review của authorized accounting/legal role.
SRC-DEC-INVOICE-001	Nghị định 123/2020/NĐ-CP về hóa đơn, chứng từ	Chính phủ Việt Nam	Nghị định số 123/2020/NĐ-CP; có hiệu lực từ 2022-07-01 theo verified source seed	https://vanban.chinhphu.vn/?docid=201365&pageid=27160	2026-08-07	Official Vietnamese law	Dùng để xác định các điểm cần legal/accounting/tax escalation trong nghiệp vụ sales order, invoice request, invoice issuance, adjustment, cancellation/replacement, receivables, accounting integration, document storage, report/export, API integration, QA và UAT của Nova Foods.	Verified đối với tên nguồn, issuer, số nghị định, ngày hiệu lực và URL theo verified source seed. Verification required đối với mọi yêu cầu chi tiết về hóa đơn điện tử, chứng từ, ký số, mã, dữ liệu bắt buộc, thời điểm lập, điều chỉnh, thay thế, hủy, truyền nhận dữ liệu, lưu trữ, xử lý lỗi, báo cáo, nghĩa vụ thuế hoặc ảnh hưởng của sửa đổi sau này.	URL là nguồn chính thức được cung cấp trong verified source seed. Seed yêu cầu kiểm tra các sửa đổi sau này trước khi sử dụng production. Source map không xác nhận tình trạng đầy đủ của mọi văn bản sửa đổi, hướng dẫn thực hiện, quy định kỹ thuật, tích hợp cơ quan quản lý hoặc diễn giải thuế/kế toán hiện hành.	Không được tuyên bố invoice workflow, invoice number generation, signing flow, invoice payload, adjustment flow, cancellation flow, archive, integration, report hoặc test result của Nova Foods là compliant. Không được phát minh deadline, điều kiện lập hóa đơn, trường dữ liệu, quy trình điều chỉnh/thay thế/hủy, nghĩa vụ truyền dữ liệu hoặc quy tắc thuế. Không được dùng entry này thay thế review của legal, tax hoặc accounting authority.
SRC-LAW-FS-001	Luật An toàn thực phẩm	Quốc hội Việt Nam	Luật số 55/2010/QH12; nguồn pháp lý chính thức theo verified source seed	https://vanban.chinhphu.vn/?docid=96032&pageid=27160	2026-08-07	Official Vietnamese law	Dùng để nhận diện các điểm giao cắt cần review trong procurement, supplier management, receiving, inventory lot/batch tracking, warehouse, production planning, manufacturing execution, quality control, traceability, recall handling, reporting, API, data model, test planning và UAT của Nova Foods.	Verified đối với tên nguồn, issuer, số luật và URL theo verified source seed. Verification required đối với mọi diễn giải về nghĩa vụ an toàn thực phẩm, điều kiện sản xuất/kinh doanh, truy xuất nguồn gốc, thu hồi, ghi nhãn, hồ sơ, kiểm nghiệm, bảo quản, vận chuyển, trách nhiệm các bên hoặc yêu cầu kỹ thuật/tuân thủ chưa được đối chiếu với toàn văn hiện hành và văn bản hướng dẫn/sửa đổi liên quan.	URL là nguồn chính thức được cung cấp trong verified source seed. Source map không xác nhận rằng toàn văn hiện hành, văn bản hướng dẫn, tiêu chuẩn liên quan, quy định theo nhóm sản phẩm hoặc diễn giải có thẩm quyền đã được rà soát đầy đủ. Nội dung công khai không đồng nghĩa với quyền tái xuất bản toàn văn.	Không được phát minh điều, khoản, tiêu chuẩn an toàn, ngưỡng, thời hạn, quy trình kiểm nghiệm, quy tắc ghi nhãn, truy xuất, thu hồi, bảo quản hoặc trách nhiệm pháp lý cụ thể. Không được khẳng định lot tracking, shelf-life rule, storage control, supplier approval, QA record, recall flow, API, report hoặc control của Nova Foods “tuân thủ Luật An toàn thực phẩm” chỉ vì có entry này. Không được dùng entry thay cho legal, food-safety, QA hoặc production approval có thẩm quyền.

Yêu cầu review có thẩm quyền đối với diễn giải pháp lý và kế toán

Các entry SRC-LAW-PRIV-001, SRC-DEC-PRIV-001, SRC-LAW-ACCT-001, SRC-DEC-INVOICE-001 và SRC-LAW-FS-001 chỉ giúp handbook nhận diện nguồn cần tham chiếu và điểm cần escalation. Chúng không tự tạo ra kết luận pháp lý, kế toán, thuế, quyền riêng tư, hóa đơn hoặc an toàn thực phẩm cho Nova Foods.

Loại quyết định hoặc kết luận	Vai trò có thẩm quyền phải review	Vai trò của BA trong Nova Foods	Điều không được tự suy diễn hoặc phê duyệt
Diễn giải nghĩa vụ từ Luật Bảo vệ dữ liệu cá nhân hoặc Nghị định số 356/2025/NĐ-CP	Legal counsel được tổ chức ủy quyền và privacy/data owner có thẩm quyền	Ghi nhận business context, data flow, entity, actor, purpose, integration, risk, requirement candidate và câu hỏi cần quyết định; gắn Verification required cho nội dung chưa được review.	BA không được tự kết luận căn cứ xử lý dữ liệu, nghĩa vụ consent/notice, quyền của chủ thể dữ liệu, retention, deletion, data transfer, incident handling hoặc mức độ tuân thủ của hệ thống.
Diễn giải nghĩa vụ kế toán từ Luật Kế toán	Authorized accounting role và legal counsel được tổ chức ủy quyền	Phân tích luồng nghiệp vụ, chứng từ, sự kiện ghi nhận, reconciliation need, interface, audit trail và báo cáo; chuyển các điểm chưa được xác minh thành assumption hoặc câu hỏi escalation.	BA không được tự phê duyệt định khoản, thời điểm ghi nhận, chứng từ hợp lệ, chữ ký, lưu trữ, reporting obligation, chart of accounts hoặc kết luận rằng accounting integration đáp ứng luật.
Diễn giải yêu cầu hóa đơn, chứng từ và nghĩa vụ liên quan từ Nghị định số 123/2020/NĐ-CP	Authorized tax role, authorized accounting role và legal counsel được tổ chức ủy quyền	Mô hình hóa sales, return, refund, invoice request, adjustment, replacement, cancellation, integration và test evidence; bảo đảm requirement chỉ dùng nội dung đã được business owner và các role có thẩm quyền xác nhận.	BA không được tự xác định thời điểm lập hóa đơn, trường dữ liệu bắt buộc, quy tắc ký số, đánh số, truyền nhận, xử lý sai sót, điều chỉnh, thay thế, hủy hoặc nghĩa vụ thuế.
Diễn giải nghĩa vụ an toàn thực phẩm, truy xuất và thu hồi từ Luật An toàn thực phẩm	Legal counsel, food-safety/domain owner, QA owner và production authority được tổ chức ủy quyền	Làm rõ lot/batch flow, supplier-to-customer traceability, quality record, recall scenario, data lineage và báo cáo vận hành; nêu rõ dependency cần xác minh trước khi baseline hoặc triển khai.	BA không được tự xác định tiêu chuẩn chất lượng, ngưỡng an toàn, điều kiện sản xuất/kinh doanh, thời hạn, yêu cầu ghi nhãn, kiểm nghiệm, bảo quản, vận chuyển, thu hồi hoặc kết luận lot-tracking solution tuân thủ pháp luật.
Quyết định production release có tác động pháp lý, kế toán, thuế, privacy hoặc food safety	Authorized business owner cùng các role chuyên môn có thẩm quyền theo governance của dự án	Cung cấp traceability từ business need đến requirement, rule, acceptance criteria, test evidence, risk và open issue; ghi nhận người quyết định, phạm vi quyết định và tác động trong artifact phù hợp.	BA không được dùng test pass, UAT sign-off thông thường, source-map entry hoặc project convention để thay thế compliance sign-off, legal opinion, accounting approval hoặc production authority approval.

Quy tắc vận hành: Khi một requirement, business rule, API field, data-retention setting, workflow state, report, test case hoặc quyết định triển khai của Nova Foods phụ thuộc vào diễn giải pháp lý hoặc kế toán, BA phải:

1. Gắn nhãn Verification required nếu chưa có đối chiếu trực tiếp với văn bản hiện hành và review của role có thẩm quyền.
2. Ghi rõ câu hỏi cần quyết định, phạm vi nghiệp vụ bị ảnh hưởng, source ID liên quan, assumption đang dùng và rủi ro nếu assumption sai.
3. Escalate tới legal counsel, authorized accounting role, authorized tax role, privacy/data owner, food-safety/domain owner hoặc production authority phù hợp.
4. Chỉ chuyển nội dung thành requirement hoặc business rule đã được xác nhận khi quyết định, authority và bằng chứng review được ghi nhận theo artifact governance của dự án.
5. Không mô tả một thiết kế, cấu hình, payload, report, test result hoặc quy trình Nova Foods là “compliant”, “đúng luật”, “hợp lệ về kế toán” hoặc “đáp ứng yêu cầu thuế” nếu chưa có xác nhận rõ ràng từ role có thẩm quyền.

Review có thẩm quyền là một hoạt động ra quyết định của tổ chức; không phải là việc BA tự diễn giải văn bản, cũng không được thay thế bằng nội dung giáo dục của handbook, source map, template, ví dụ mô phỏng, kiểm thử phần mềm hoặc quyền truy cập production.

Quy tắc gắn nhãn cho nội dung thuế, kế toán, lao động, quyền riêng tư và truy xuất thực phẩm chưa được xác minh trực tiếp

Mọi chi tiết trong handbook, template, diagram, API example, data model, business rule, acceptance criteria, test case hoặc simulated artifact của Nova Foods liên quan đến thuế, kế toán, lao động, quyền riêng tư, an toàn thực phẩm hoặc truy xuất nguồn gốc không được trình bày như nghĩa vụ pháp lý, nghĩa vụ tuân thủ hoặc quy tắc bắt buộc nếu chưa được đối chiếu trực tiếp với văn bản chính thức hiện hành và chưa có review của vai trò có thẩm quyền.

Nhãn bắt buộc	Khi phải sử dụng	Cách diễn đạt được phép trong handbook	Cách diễn đạt bị cấm	Hành động BA bắt buộc
Project assumption	Chi tiết mô phỏng cần thiết để Nova Foods vận hành case study, nhưng không được khẳng định là quy định pháp luật hoặc chính sách thực tế của Việt Nam.	“Project assumption: Nova Foods lưu mã lô hàng trên phiếu xuất kho để phục vụ truy vết nội bộ trong case study.”	“Pháp luật yêu cầu Nova Foods phải lưu mã lô hàng theo cấu trúc này.”	Ghi assumption trong artifact phù hợp; xác định owner cần xác nhận nếu assumption ảnh hưởng solution scope, cost, timeline, integration hoặc test scope.
Verification required	Nội dung có thể phụ thuộc vào văn bản pháp luật hiện hành, văn bản hướng dẫn, sửa đổi, diễn giải chuyên môn, hồ sơ ngành nghề hoặc quyết định của cơ quan có thẩm quyền nhưng chưa được kiểm tra trực tiếp.	“Verification required: Cần legal counsel và privacy/data owner xác nhận retention period áp dụng cho dữ liệu khách hàng trước khi baseline REQ-NFR-CRM-xxx.”	“Hệ thống tuân thủ thời hạn lưu trữ dữ liệu theo luật.”	Gắn source ID liên quan khi có; ghi câu hỏi cần xác minh, phạm vi ảnh hưởng, rủi ro và vai trò escalation. Không baseline requirement như một compliance requirement trước khi có xác nhận.
Author recommendation	Khuyến nghị thiết kế, quản trị hoặc kiểm thử do tác giả đưa ra nhằm giảm rủi ro, nhưng không xuất phát trực tiếp từ nghĩa vụ pháp lý đã xác minh.	“Author recommendation: Thiết kế audit trail cho thay đổi hạn mức tín dụng theo actor, timestamp và lý do thay đổi.”	“Luật bắt buộc audit trail phải có chính xác các trường này.”	Tách rõ recommendation khỏi legal requirement; để business owner, architect hoặc chuyên gia được ủy quyền quyết định áp dụng.
Project convention	Quy ước nhất quán nội bộ của corpus hoặc simulation, không đại diện cho luật, chuẩn ngành bắt buộc hoặc chính sách thực tế của doanh nghiệp.	“Project convention: Nova Foods sử dụng thời gian Asia/Ho_Chi_Minh và định dạng tiền tệ VND trong ví dụ mô phỏng.”	“Việt Nam bắt buộc mọi hệ thống phải triển khai theo quy ước này.”	Áp dụng nhất quán trong artifact; không dùng project convention làm bằng chứng compliance.

Lĩnh vực	Nội dung phải gắn nhãn khi chưa được xác minh trực tiếp	Nhãn mặc định	Nguồn hoặc thẩm quyền cần escalation	Giới hạn trình bày trong case Nova Foods
Thuế	Thuế suất, thời điểm phát sinh nghĩa vụ thuế, phương pháp tính thuế, khấu trừ, kê khai, quyết toán, xử lý hoàn tiền có tác động thuế, nghĩa vụ truyền dữ liệu đến cơ quan nhà nước.	Verification required	Authorized tax role, authorized accounting role và legal counsel.	Có thể mô phỏng giá trị tiền tệ và workflow invoice/refund; không được kết luận cách tính hoặc xử lý mô phỏng là đúng thuế.
Kế toán	Định khoản, thời điểm ghi nhận, chart of accounts, chứng từ hợp lệ, chữ ký, lưu trữ, đối soát, báo cáo tài chính, xử lý sai sót chứng từ hoặc kết luận về tính hợp lệ kế toán.	Verification required	Authorized accounting role và legal counsel; tham chiếu phạm vi phù hợp tới SRC-LAW-ACCT-001 và SRC-DEC-INVOICE-001.	Có thể mô hình hóa accounting integration, receivable, payment và reconciliation như business flow mô phỏng; không được gọi ledger entry hoặc invoice flow là compliant.
Lao động	Điều kiện hợp đồng, thời giờ làm việc, tiền lương, làm thêm giờ, nghỉ phép, bảo hiểm, kỷ luật, dữ liệu nhân sự, quyền và nghĩa vụ của người lao động.	Verification required	Legal counsel, HR owner và labor specialist được tổ chức ủy quyền.	Không suy diễn quy định lao động từ case study. Nếu workforce scheduling xuất hiện trong production planning, chỉ mô tả năng lực vận hành hoặc Project assumption.
Quyền riêng tư và bảo vệ dữ liệu cá nhân	Căn cứ xử lý dữ liệu, consent, privacy notice, quyền của chủ thể dữ liệu, phân loại dữ liệu, retention, deletion, chia sẻ dữ liệu, chuyển dữ liệu, incident response và kết luận tuân thủ.	Verification required	Legal counsel và privacy/data owner; tham chiếu phạm vi phù hợp tới SRC-LAW-PRIV-001 và SRC-DEC-PRIV-001.	Có thể dùng dữ liệu cá nhân tổng hợp để mô phỏng và dùng synthetic personal data; không được khẳng định field, consent flow hoặc retention setting đáp ứng luật nếu chưa review.
An toàn thực phẩm và truy xuất nguồn gốc	Tiêu chuẩn chất lượng, ngưỡng an toàn, yêu cầu kiểm nghiệm, ghi nhãn, bảo quản, vận chuyển, điều kiện sản xuất/kinh doanh, thời hạn lưu hồ sơ, thu hồi và nghĩa vụ traceability.	Verification required	Legal counsel, food-safety/domain owner, QA owner và production authority; tham chiếu phạm vi phù hợp tới SRC-LAW-FS-001.	Có thể mô phỏng lot/batch, expiry date, quarantine, recall workflow và supplier-to-customer traceability; không được khẳng định các field, trạng thái hoặc báo cáo là đầy đủ theo pháp luật.

Quy tắc diễn đạt bắt buộc trong artifact:

1. Nếu nội dung chỉ tồn tại để làm ví dụ học tập hoặc hoàn chỉnh workflow Nova Foods, dùng Project assumption và nêu rõ đó là giả định của case study.
2. Nếu nội dung có thể ảnh hưởng đến nghĩa vụ pháp lý, thuế, kế toán, quyền riêng tư, lao động hoặc an toàn thực phẩm mà chưa có đối chiếu văn bản hiện hành, dùng Verification required.
3. Không thay Verification required bằng các cụm từ tạo cảm giác đã được xác nhận như “theo quy định”, “đúng luật”, “hợp lệ”, “bắt buộc”, “compliant”, “đạt chuẩn”, “đáp ứng nghĩa vụ” hoặc “được phép”.
4. Không dùng một source-map entry, test case pass, UAT sign-off thông thường, diagram, API schema hoặc dữ liệu mô phỏng làm bằng chứng rằng Nova Foods tuân thủ pháp luật hoặc quy định chuyên ngành.
5. Khi một Project assumption được xác nhận bởi role có thẩm quyền, artifact phải ghi nhận quyết định, người có authority, ngày xác nhận, source hoặc evidence được kiểm tra và impacted IDs trước khi thay đổi trạng thái kiểm soát.
6. Khi chưa có xác nhận, requirement hoặc business rule chịu ảnh hưởng phải giữ nhãn Verification required; mọi thiết kế, estimate, test scope và release decision phụ thuộc vào nó phải ghi nhận rủi ro tương ứng.

Industry Good Practice, Project Conventions, and Author Recommendations

Các nguồn dưới đây được xếp loại Industry good practice. Chúng hỗ trợ thiết kế và đánh giá kiểm soát bảo mật, API và quy trình BA trong handbook Nova Foods, nhưng không phải là luật Việt Nam, không thay thế review pháp lý, và không được dùng để khẳng định tuân thủ pháp luật.

SRC-OWASP-ASVS-001 — OWASP Application Security Verification Standard (ASVS)

Trường	Giá trị
Source ID	SRC-OWASP-ASVS-001
Title	OWASP Application Security Verification Standard (ASVS)
Issuer	OWASP Foundation
Version / Status	ASVS 5.0.0; listed as latest stable in verified source seed
Official URL	https://owasp.org/www-project-application-security-verification-standard/
Access Date	2026-08-07
Authority Classification	Industry good practice
Intended Curriculum Use	Dùng làm khung tham chiếu thực hành để hướng dẫn người học nhận diện và đặc tả các yêu cầu kiểm soát bảo mật ở mức ứng dụng cho Nova Foods, đặc biệt trong các chapter về requirements, security, API design, authentication/authorization, session handling, input validation, logging, testing, UAT, và governance. Nguồn này hữu ích khi BA cần chuyển một business need thành security-oriented requirement, quality gate, hoặc checklist xác minh trước baseline.
Verification Status	Verified đối với title, issuer, version/status, URL và access date theo verified source seed. Verification required đối với phạm vi mức kiểm soát chi tiết, mức độ áp dụng cho từng loại hệ thống, và mọi kết luận rằng một requirement hay control cụ thể “đạt ASVS” nếu chưa có review chuyên môn phù hợp.
Licensing / Access Caveat	Nguồn công khai của OWASP. Nội dung có thể được cập nhật theo thời gian trên website chính thức. Source map này chỉ xác nhận mức độ phù hợp để tham khảo học thuật và thực hành; không xác nhận quyền suy diễn pháp lý, quyền công bố lại toàn văn, hay quyền tuyên bố chứng nhận tuân thủ.
Claims That Must Not Be Made	Không được nói rằng ASVS là luật, nghị định, hay chuẩn bắt buộc của Việt Nam. Không được khẳng định Nova Foods “compliant”, “certified”, hay “đạt chuẩn pháp lý” chỉ vì có đối chiếu với ASVS. Không được phát minh mức kiểm soát, ngưỡng đánh giá, hoặc clause/page reference nếu chưa kiểm tra trực tiếp tài liệu hiện hành. Không được dùng ASVS thay cho security review, architecture review, hoặc approval của authority có thẩm quyền.

Ranh giới sử dụng trong case study Nova Foods

ASVS có thể được dùng như một khung tư duy để người học hỏi cách đặt câu hỏi về bảo mật trong hệ thống Web ERP của Nova Foods, ví dụ:

• Có cần xác thực mạnh hơn cho các vai trò duyệt giá, duyệt chiết khấu, duyệt hoàn tiền, hoặc duyệt credit limit không?
• Dữ liệu nhạy cảm nào cần được bảo vệ khi đi qua API Gateway, ERP Service, database, report export, hoặc integration?
• Có cần kiểm tra input, output encoding, session timeout, audit logging, hoặc access control ở các điểm nào?

Tuy nhiên, các câu hỏi này chỉ là hướng dẫn phân tích. Bất kỳ yêu cầu bảo mật cụ thể nào vẫn phải được xác nhận theo governance của dự án và authority phù hợp.

---

SRC-OWASP-API-TOP10-001 — OWASP API Security Top 10 (2023)

| Trường | Giá trị | |---|---|---| | Source ID | SRC-OWASP-API-TOP10-001 | | Title | OWASP API Security Top 10 | | Issuer | OWASP Foundation | | Version / Status | 2023 edition | | Official URL | https://owasp.org/API-Security/editions/2023/en/0x11-t10/ | | Access Date | 2026-08-07 | | Authority Classification | Industry good practice | | Intended Curriculum Use | Dùng làm tài liệu định hướng thực hành để giúp người học nhận diện rủi ro thường gặp trong API của Nova Foods, đặc biệt ở các chapter về API specification, integration, authentication/authorization, data exposure, rate limiting, error handling, logging, testing, và security review. Nguồn này hỗ trợ BA đặt câu hỏi đúng khi mô hình hóa request/response, payload, boundary, dependency, và test condition cho các API trong hệ thống ERP mô phỏng. | | Verification Status | Verified đối với title, issuer, edition, URL và access date theo verified source seed. Verification required đối với việc diễn giải mức độ ưu tiên rủi ro, phạm vi áp dụng trong từng kiến trúc, và mọi tuyên bố rằng một API cụ thể đã “được bảo mật đúng theo OWASP” nếu chưa có kiểm chứng chuyên môn. | | Licensing / Access Caveat | Nguồn công khai của OWASP. Nội dung là tài liệu tham khảo thực hành, có thể thay đổi theo thời gian. Source map này không xác nhận đây là chuẩn pháp lý, không xác nhận quyền tái xuất bản toàn văn trong handbook, và không cho phép dùng như bằng chứng tuân thủ pháp luật hoặc chứng nhận an ninh. | | Claims That Must Not Be Made | Không được nói rằng OWASP API Security Top 10 là luật, chuẩn bắt buộc, hoặc tiêu chuẩn pháp lý của Việt Nam. Không được khẳng định một endpoint, payload, workflow, hay control API của Nova Foods “compliant” chỉ vì có tham chiếu đến tài liệu này. Không được phát minh thứ hạng rủi ro, điều khoản, hoặc yêu cầu kỹ thuật cụ thể nếu chưa kiểm tra trực tiếp tài liệu hiện hành. Không được dùng tài liệu này để thay thế threat modeling, security architecture review, hoặc approval của authority có thẩm quyền. |

Ranh giới sử dụng trong case study Nova Foods

OWASP API Security Top 10 có thể giúp BA của Nova Foods nhận diện các câu hỏi phân tích quan trọng cho API và integration, ví dụ:

• Endpoint nào có nguy cơ lộ dữ liệu khách hàng, giá bán, hạn mức công nợ, hoặc thông tin kho?
• Có cần xác thực và phân quyền riêng cho từng hành động như tạo đơn hàng, duyệt giảm giá, hoàn tiền, hay sửa master data không?
• Cần kiểm tra lỗi, retry, pagination, filtering, object reference, và logging ở đâu?

Các điểm này chỉ là gợi ý phân tích. BA không được dùng tài liệu này để tự kết luận mức an toàn của hệ thống hay thay thế đánh giá bảo mật chính thức.

---

Quy tắc phân loại áp dụng cho các nguồn trong mục này

Nguồn	Nhãn phân loại bắt buộc	Ghi chú sử dụng
OWASP ASVS	Industry good practice	Dùng để tham chiếu kiểm soát bảo mật ứng dụng và hỗ trợ phân tích yêu cầu an ninh.
OWASP API Security Top 10	Industry good practice	Dùng để nhận diện rủi ro API phổ biến và hỗ trợ thiết kế/test/security review.

Các giới hạn chung cho nguồn Industry good practice

1. Không được trình bày các nguồn này như văn bản pháp luật hoặc quy định bắt buộc.
2. Không được dùng chúng làm căn cứ duy nhất để tuyên bố compliance cho Nova Foods.
3. Không được tự phát minh clause, page number, hoặc trích dẫn nguyên văn nếu chưa kiểm tra tài liệu gốc.
4. Nếu một yêu cầu, control, hoặc API behavior chỉ dựa vào nguồn thực hành tốt, phải ghi rõ đó là Industry good practice hoặc Author recommendation, không phải nghĩa vụ pháp lý.

Quy ước dự án áp dụng riêng cho mô phỏng Nova Foods

Các mục dưới đây là Project convention, được thiết lập để giữ cho toàn bộ handbook, template library, ví dụ đã điền, sơ đồ và test case nhất quán trong phạm vi đào tạo. Đây không phải là nguồn chuẩn bên ngoài, không phải quy định pháp luật, và không mô tả sự kiện, con người, giao dịch hoặc quyết định có thật của bất kỳ doanh nghiệp nào.

Convention ID	Nhãn phân loại	Quy ước Nova Foods	Phạm vi áp dụng trong handbook	Chủ thể cần xác nhận hoặc escalation khi áp dụng dự án thực tế
PC-NOVA-001	Project convention	Toàn bộ nội dung sử dụng duy nhất case study mô phỏng Nova Foods Trading & Manufacturing; pháp nhân mô phỏng là Nova Foods Co., Ltd.	Tất cả chapter, template, requirement, API, database schema, diagram, test case, defect và change request	Business Owner và PM xác nhận case study hoặc domain thực tế thay thế
PC-NOVA-002	Project convention	Bối cảnh mặc định là SME kinh doanh và sản xuất FMCG/thực phẩm tại Việt Nam; AS-IS gồm Excel/POS, phần mềm kế toán legacy, sổ kho thủ công, biểu mẫu sản xuất bán thủ công và báo cáo rời rạc	Ví dụ discovery, AS-IS/TO-BE, gap analysis, process modeling, requirements và roadmap	Business Owner, Domain Owner và Senior BA xác nhận hiện trạng thực tế
PC-NOVA-003	Project convention	TO-BE mặc định là Web ERP tích hợp CRM, sales, pricing/promotion, procurement, inventory/lot/batch/multi-warehouse, manufacturing, finance/accounting integration, approval workflow và BI/reporting	Scope model, context diagram, architecture example, backlog, data model, API, testing và UAT	Sponsor, Product Owner, Enterprise Architect và PM xác nhận phạm vi đầu tư thực tế
PC-NOVA-004	Project convention	Ngôn ngữ trình bày là tiếng Việt; thuật ngữ chuẩn tiếng Anh như Business Requirement, Acceptance Criteria, API, Entity hoặc Baseline được giữ lại khi cần và giải thích từ nền tảng	Handbook, glossary, template, diagram label, API documentation và QA report	Curriculum Owner hoặc Documentation Owner xác nhận quy ước ngôn ngữ dự án
PC-NOVA-005	Project convention	Locale mặc định là vi-VN; múi giờ là Asia/Ho_Chi_Minh; tiền tệ minh họa là VND	Date/time field, report, test data, API example, database example và business rule example	Product Owner, Finance Owner và Solution Architect xác nhận locale, timezone và currency thực tế
PC-NOVA-006	Project convention	Mọi dữ liệu về khách hàng, nhân viên, nhà cung cấp, đơn hàng, giá, số tiền, tồn kho, lô hàng, quyết định phê duyệt và chỉ số vận hành đều là dữ liệu tổng hợp mô phỏng	Completed artifact Tier 3, sample payload, SQL, report, test data, defect và UAT evidence	Data Owner và Privacy/Legal Owner phê duyệt dữ liệu phi sản xuất hoặc dữ liệu đã được che giấu khi triển khai thật
PC-NOVA-007	Project convention	Không dùng dữ liệu cá nhân thật, mật khẩu thật, private key, access token thật hoặc thông tin môi trường production. Ví dụ bí mật chỉ được biểu diễn bằng token an toàn như ${ACCESS_TOKEN}, ${API_KEY_ENV} hoặc ${DB_PASSWORD}	API examples, configuration examples, integration examples, test execution notes và security-related templates	Security Owner, DevOps Owner và Data Protection Owner xác nhận cơ chế secret management thực tế
PC-NOVA-008	Project convention	Identifier được dùng nhất quán theo registry: NEED-{DOMAIN}-{NNN}, REQ-FUNC-{DOMAIN}-{NNN}, REQ-NFR-{DOMAIN}-{NNN}, BR-{DOMAIN}-{NNN}, AC-{DOMAIN}-{REQ_NUMBER}-{NN}, API-{DOMAIN}-{NNN}, DATA-{DOMAIN}-{NNN}, TC-{DOMAIN}-{REQ_NUMBER}-{NN}, DEF-{DOMAIN}-{NNN}, CR-{DOMAIN}-{NNN}	Mọi artifact có traceability, bao gồm requirement, business rule, acceptance criteria, API, data model, test case, defect và change request	BA Lead hoặc Configuration Manager quản trị registry và phê duyệt ID mới
PC-NOVA-009	Project convention	DOMAIN code hợp lệ phải được định nghĩa và đóng băng trong TRACEABILITY_ID_REGISTRY.md; các ví dụ dự kiến gồm SALES, CRM, INV, MFG, FIN, ACCT và PROD	ID registry, traceability matrix, template và completed artifact	BA Lead, Domain Owner và Configuration Manager xác nhận domain boundary thực tế
PC-NOVA-010	Project convention	Artifact được quản trị theo trạng thái DRAFT, IN_REVIEW, BASELINED, SUPERSEDED; baseline không đồng nghĩa với bất biến, nhưng thay đổi baseline phải đi qua CR-{DOMAIN}-{NNN} đã được phê duyệt	Metadata của controlled artifact, change log, traceability, QA report và release review	Authorized approver theo governance dự án, thường là Business Owner, PM hoặc Change Authority
PC-NOVA-011	Project convention	Trong Phase 1 và Phase 2, artifact có trạng thái IN_REVIEW, version v0.9.0, ngày cập nhật 2026-08-07; không được tuyên bố đã baseline hoặc được phê duyệt khi chưa có phê duyệt rõ ràng từ user hoặc authorized role	/00-research/, /01-curriculum/ và báo cáo tiến độ liên quan	User hoặc authorized role thực hiện review và quyết định baseline
PC-NOVA-012	Project convention	PlantUML activity diagram có swimlane được gọi là UML Activity Diagram with swimlanes, không được gọi là BPMN trừ khi sử dụng đúng BPMN notation và semantics	Chapter về process, workflow, approval, handoff và operational procedure	BA Lead, Process Owner hoặc BPMN specialist xác nhận notation cần dùng cho dự án thật
PC-NOVA-013	Project convention	Màu hex trong diagram là quy ước trình bày dự án: #E3F2FD, #E8F5E9, #FFEBEE, #FFFDE7, #FFE0B2, #F3E5F5	PlantUML swimlane, flowchart, architecture diagram và các hình trực quan liên quan	Documentation Owner hoặc Design System Owner xác nhận chuẩn trực quan thực tế
PC-NOVA-014	Project convention	Sơ đồ được chọn theo mục đích: workflow liên phòng ban dùng PlantUML activity diagram with swimlanes; API flow dùng Mermaid sequenceDiagram; ERD dùng Mermaid erDiagram; state transition dùng Mermaid stateDiagram-v2; system context/architecture dùng PlantUML component hoặc Mermaid flowchart	Chapter về process, integration, data, state, architecture và testing	Solution Architect, BA Lead và Technical Writer xác nhận notation/toolchain của dự án thật
PC-NOVA-015	Project convention	Ví dụ hoàn chỉnh phải thể hiện chuỗi suy luận: Facts → Current Behavior → Underlying Need → Options → Decision Criteria → Decision → Authority → Artifact → Consequence if Wrong	Section 8 của mỗi handbook chapter và các completed artifact cần diễn giải quyết định	Senior BA, Product Owner, Architect hoặc Business Owner xác nhận decision authority thực tế
PC-NOVA-016	Project convention	Mọi ví dụ refund áp dụng giả định dữ liệu tiền tệ là số nguyên VND, minimum increment là 1 VND, trừ khi requirement cụ thể nêu khác; rule minh họa BR-SALES-004 dùng biểu thức 0 < Refund Amount <= Paid Amount	Chapter testing, business rule, acceptance criteria, test data và test case cho refund	Finance Owner, Accounting Owner và Product Owner xác nhận quy tắc hoàn tiền thực tế
PC-NOVA-017	Project convention	Nội dung handbook là tài liệu tự học có giám sát: người học có thể thực hiện các tác vụ BA phổ biến theo procedure, template và quality gate, nhưng phải escalation các quyết định về pháp lý, kế toán, thuế, quyền riêng tư, an toàn thực phẩm, kiến trúc production và domain authority	Metadata chapter, escalation guidance, template quality gate, QA và disclaimer	Legal Owner, Accounting Owner, Security Owner, Domain Owner, Architect và Production Operations Owner

Quy tắc vận hành các quy ước dự án

1. Mỗi quy ước chỉ có hiệu lực trong corpus đào tạo Nova Foods cho đến khi được thay đổi có kiểm soát.
2. Thay đổi đối với một quy ước ảnh hưởng đến identifier, canonical rule, canonical entity, state, locale, diagram notation hoặc governance phải được ghi nhận trong change log và liên kết với một CR-{DOMAIN}-{NNN} phù hợp sau khi artifact đã được baseline.
3. Các ví dụ có số liệu VND, tên cá nhân, tên tổ chức phụ trợ, mã đơn hàng, mã lô hàng, giá, tồn kho hoặc quyết định phê duyệt chỉ phục vụ mục tiêu học tập; chúng không được suy diễn thành dữ kiện thị trường, thực hành bắt buộc hoặc chính sách thật của Nova Foods.
4. Khi một dự án thực tế có quy định khác với các quy ước trên, requirement thực tế phải được xác nhận bởi owner có thẩm quyền; handbook không cho phép tự động chuyển quy ước mô phỏng thành quyết định production.

Khuyến nghị của tác giả khi không có tiêu chuẩn bên ngoài áp dụng trực tiếp

Các mục trong bảng này được gắn nhãn Author recommendation. Chúng là hướng dẫn biên soạn và phán đoán thực hành cho corpus đào tạo Nova Foods, được dùng khi không có một tiêu chuẩn, quy định pháp luật hoặc nguồn chính thức đã kiểm chứng quy định trực tiếp mức độ chi tiết cần trình bày. Chúng không thay thế quyết định của Business Owner, Domain Owner, Architect, Security Owner, Legal Owner hoặc Accounting Owner trong dự án thực tế.

Recommendation ID	Nhãn phân loại	Khuyến nghị của tác giả	Cơ sở sử dụng trong corpus đào tạo	Phạm vi curriculum dự kiến	Ranh giới và điều không được tuyên bố
AR-BA-001	Author recommendation	Viết requirement theo cấu trúc gồm mục tiêu nghiệp vụ, phạm vi, trigger, precondition, luồng chính, ngoại lệ, business rule, acceptance criteria, dependency và traceability ID.	Giúp người học chuyển từ yêu cầu mơ hồ sang artifact có thể review, implement và test. Cấu trúc chi tiết là lựa chọn biên soạn, không phải mẫu bắt buộc phổ quát.	Chapter về discovery, elicitation, requirement specification, acceptance criteria, traceability; template BRD, SRS, user story, requirement catalogue và RTM.	Không được tuyên bố đây là cấu trúc bắt buộc theo pháp luật Việt Nam, BABOK Guide, ISO/IEC/IEEE 29148 hoặc mọi phương pháp Agile.
AR-BA-002	Author recommendation	Tách rõ Fact, Assumption, Constraint, Decision và Open Issue trong mọi phân tích có ảnh hưởng đến scope, chi phí, thời hạn, compliance hoặc solution design.	Giảm nguy cơ trình bày giả định như sự thật và hỗ trợ escalation đúng lúc.	Chapter về stakeholder analysis, discovery, scope, requirement, risk, governance và change control; template assumption log, decision log, issue log và risk register.	Không được khẳng định việc phân loại này tự động tạo ra phê duyệt, loại bỏ rủi ro hoặc thay thế xác nhận của owner có thẩm quyền.
AR-BA-003	Author recommendation	Mỗi business rule có tác động vận hành nên được ghi bằng cấu trúc: điều kiện, toán tử, dữ liệu đầu vào, đơn vị, độ chính xác, owner, ngoại lệ, thông điệp lỗi và consequence khi vi phạm.	Hỗ trợ xây dựng rule có thể kiểm thử, đặc biệt cho pricing, credit limit, approval, inventory và refund của Nova Foods.	Chapter về business rules, state, data, requirements và testing; template business-rule catalogue, decision table, test-condition catalogue và test-case specification.	Không được tuyên bố đây là cú pháp chuẩn bắt buộc của BPMN, UML, SQL, OpenAPI hoặc bất kỳ luật thuế, kế toán, thực phẩm nào.
AR-BA-004	Author recommendation	Với requirement có trạng thái, phải mô tả state hợp lệ, transition hợp lệ, trigger, actor hoặc system action, guard condition và hành vi khi transition không hợp lệ.	Giúp tránh các luồng thiếu kiểm soát như sửa đơn hàng đã giao, hoàn tiền vượt khoản đã thanh toán hoặc đóng work order sai điều kiện.	Chapter về process, business rules, state transition, data model, API và testing; template state model, workflow specification, API contract và state-transition test design.	Không được suy diễn state model minh họa thành chính sách vận hành, chính sách kế toán hoặc quy định pháp lý bắt buộc cho doanh nghiệp thực tế.
AR-BA-005	Author recommendation	Mỗi API example trong handbook nên thể hiện request, response thành công, response lỗi nghiệp vụ, response lỗi xác thực hoặc phân quyền phù hợp, correlation ID và quy tắc không đưa secret thật vào payload hoặc header mẫu.	Giúp BA hiểu API contract như một thỏa thuận liên chức năng có thể review và test, thay vì chỉ là URL kỹ thuật.	Chapter về integration, API, NFR, security awareness, testing; template API specification, interface catalogue, API test case và defect report.	Không được tuyên bố payload mẫu là thiết kế production an toàn, chứng nhận bảo mật hoặc thay thế security review, penetration test hay threat modeling.
AR-BA-006	Author recommendation	Khi chưa có target NFR đã được business và technical owner xác nhận, requirement phải dùng trạng thái Verification required hoặc project assumption thay vì tự đặt SLA, RPO, RTO, throughput, retention period hay availability target.	Ngăn người học biến ví dụ đào tạo thành cam kết production không có cơ sở.	Chapter về NFR, architecture collaboration, integration, security, operations và governance; template NFR catalogue, architecture decision record, risk register và approval record.	Không được tuyên bố các con số minh họa về hiệu năng, khôi phục dữ liệu, lưu trữ hay khả dụng là industry benchmark, nghĩa vụ pháp lý hoặc cam kết của Nova Foods.
AR-BA-007	Author recommendation	Với dữ liệu nhạy cảm hoặc có thể nhận diện cá nhân, BA nên lập data classification tối thiểu gồm mục đích sử dụng, owner, nguồn, người tiêu thụ, mức nhạy cảm, retention assumption, access role và điểm cần legal/privacy review.	Tạo thói quen nhận diện dữ liệu cần escalation trước khi thiết kế báo cáo, API, tích hợp hoặc test data.	Chapter về data analysis, NFR, security awareness, integration, reporting, testing và governance; template data dictionary, data-flow record, access matrix và privacy-review checklist.	Không được tuyên bố classification này đáp ứng Luật Bảo vệ dữ liệu cá nhân, Nghị định hướng dẫn, quy định xuyên biên giới hoặc nghĩa vụ privacy cụ thể nếu chưa được kiểm chứng và phê duyệt.
AR-BA-008	Author recommendation	Test case nên tách riêng test condition, test scenario, test data, precondition, steps, expected result, actual result, execution evidence, defect link, retest result và regression decision.	Làm rõ chuỗi từ requirement đến bằng chứng kiểm thử, đặc biệt trong mini-book testing dành cho BA.	Part testing, UAT, defect management và traceability; template test-condition catalogue, test scenario, test case, test-data set, defect report và UAT acceptance record.	Không được khẳng định template này là chứng nhận chất lượng, thay thế test strategy của QA Lead hoặc bảo đảm coverage đầy đủ cho production release.
AR-BA-009	Author recommendation	Mọi ví dụ quyết định quan trọng nên trình bày chuỗi: Facts → Current Behavior → Underlying Need → Options → Decision Criteria → Decision → Authority → Artifact → Consequence if Wrong.	Dạy người học phân biệt giữa mô tả hiện trạng, nhu cầu, phương án và quyết định có thẩm quyền.	Toàn bộ Section 8 của handbook; template decision log, option assessment, BRD, change request và architecture decision record.	Không được trình bày chuỗi suy luận này như một chuẩn quốc tế được chứng nhận, cơ chế phê duyệt pháp lý hoặc bằng chứng rằng quyết định là đúng cho mọi bối cảnh.
AR-BA-010	Author recommendation	Khi phát hiện thay đổi ảnh hưởng đến baseline, BA nên lập change impact analysis chứa lý do thay đổi, IDs bị ảnh hưởng, artifact/file bị ảnh hưởng, tác động scope/schedule/cost/risk/test/UAT và authority cần phê duyệt trước khi cập nhật nội dung.	Hỗ trợ kiểm soát thay đổi và propagation trong corpus có traceability dài hạn.	Chapter về governance, traceability, change control, QA và delivery; template change request, impact assessment, traceability matrix và release checklist.	Không được tuyên bố phân tích này cấu thành phê duyệt thay đổi, hợp đồng sửa đổi, chấp thuận ngân sách hoặc quyền tự động sửa artifact đã baseline.

Điều kiện sử dụng và kiểm soát khuyến nghị của tác giả

1. Mỗi mục AR-BA-xxx phải được trình bày rõ là Author recommendation tại nơi được sử dụng; không được đổi nhãn thành Normative standard, Official Vietnamese law hoặc Industry good practice.
2. Khuyến nghị của tác giả chỉ hướng dẫn cách học, cách cấu trúc artifact và cách đặt câu hỏi phân tích. Chúng không tạo nghĩa vụ pháp lý, kế toán, thuế, lao động, quyền riêng tư, an toàn thực phẩm, an ninh mạng hoặc vận hành production.
3. Nếu một khuyến nghị chạm đến dữ liệu cá nhân, kế toán, hóa đơn, thuế, truy xuất nguồn gốc, thu hồi thực phẩm, kiểm soát truy cập, mã hóa, retention hoặc cam kết dịch vụ, nội dung áp dụng cho dự án thật phải được gắn Verification required hoặc Project assumption cho đến khi owner có thẩm quyền xác nhận.
4. Không được trích dẫn các mục AR-BA-xxx như bằng chứng rằng một framework, tiêu chuẩn, cơ quan nhà nước, khách hàng, Nova Foods hoặc ngành FMCG bắt buộc phải áp dụng cách làm đó.
5. Các khuyến nghị có thể được thay thế hoặc supersede bởi requirement đã phê duyệt, quy định hiện hành đã được kiểm chứng, quyết định kiến trúc được phê duyệt hoặc project convention chính thức của dự án thực tế.

Nhãn phân loại bắt buộc cho từng mục nguồn và hướng dẫn

Mỗi mục được ghi trong phần này phải mang đúng một nhãn phân loại chính trong trường Authority classification. Nhãn cho biết bản chất thẩm quyền của nguồn hoặc hướng dẫn; không phản ánh mức độ hữu ích, mức độ phổ biến, hay việc nội dung có phù hợp với một dự án thực tế hay không.

Nhãn phân loại chính xác	Áp dụng cho	Ý nghĩa kiểm soát	Cách hiển thị bắt buộc trong source entry
Industry good practice	Nguồn công khai từ tổ chức chuyên môn hoặc cộng đồng có uy tín, cung cấp hướng dẫn thực hành nhưng không phải luật Việt Nam và không phải tiêu chuẩn pháp lý bắt buộc áp dụng cho mọi dự án.	Có thể dùng để định hướng câu hỏi, checklist, tiêu chí review và nhận diện rủi ro. Việc áp dụng vào Nova Foods hoặc dự án thực tế cần được xác nhận theo bối cảnh, risk appetite và authority phù hợp.	Ghi nguyên văn Authority classification: Industry good practice.
Project convention	Quy ước được thiết lập riêng cho corpus đào tạo Nova Foods, bao gồm cách đặt ID, cấu trúc artifact, cách dùng màu sơ đồ, dữ liệu mô phỏng, locale và quy tắc traceability.	Chỉ kiểm soát tính nhất quán bên trong handbook, template library và case study mô phỏng. Không tạo nghĩa vụ cho doanh nghiệp thật hoặc dự án ngoài corpus.	Ghi nguyên văn Authority classification: Project convention.
Author recommendation	Hướng dẫn biên soạn hoặc phán đoán thực hành do tác giả handbook đề xuất khi không có nguồn bên ngoài áp dụng trực tiếp cho mức độ chi tiết cần dạy.	Có thể hỗ trợ người học thực hiện BA delivery task có cấu trúc, nhưng phải được thay thế, điều chỉnh hoặc escalation khi dự án có requirement, luật, policy hoặc quyết định đã phê duyệt.	Ghi nguyên văn Authority classification: Author recommendation.

Danh mục phân loại các mục nguồn và hướng dẫn trong phần này

Source / Guidance ID	Tên mục	Issuer hoặc chủ thể thiết lập	Authority classification	Lý do gắn nhãn	Phạm vi sử dụng dự kiến trong corpus
SRC-OWASP-ASVS-001	OWASP Application Security Verification Standard	OWASP Foundation	Industry good practice	Là khung tham chiếu công khai về kiểm chứng bảo mật ứng dụng, hữu ích để nhận diện các chủ đề security requirement và review, nhưng không phải luật Việt Nam.	Chapter về NFR, security awareness, requirement quality, API, architecture collaboration, QA và governance; template NFR catalogue, security-review checklist, risk register và API specification.
SRC-OWASP-API-2023-001	OWASP API Security Top 10 — 2023	OWASP Foundation	Industry good practice	Là tài liệu nhận diện rủi ro và thực hành an toàn API phổ biến; không phải tiêu chuẩn pháp lý, hợp đồng hoặc chứng nhận an ninh.	Chapter về integration, API, authentication and authorization awareness, NFR, test design, defect analysis và governance; template API specification, interface catalogue, API test case và risk register.
PC-NOVA-001	Quy ước định danh traceability của Nova Foods	Corpus governance của handbook	Project convention	Các pattern như NEED-{DOMAIN}-{NNN}, REQ-FUNC-{DOMAIN}-{NNN}, BR-{DOMAIN}-{NNN}, AC-{DOMAIN}-{REQ_NUMBER}-{NN} và TC-{DOMAIN}-{REQ_NUMBER}-{NN} được thiết lập để giữ liên kết nhất quán trong corpus mô phỏng.	Toàn bộ chapter có artifact ID; TRACEABILITY_ID_REGISTRY.md, requirement catalogue, business-rule catalogue, test artifacts, defect report, change request và QA report.
PC-NOVA-002	Quy ước case study mô phỏng Nova Foods	Corpus governance của handbook	Project convention	Nova Foods Co., Ltd., nhân sự, giao dịch, số liệu, quyết định và dữ liệu cá nhân trong handbook đều là mô phỏng giáo dục tại Việt Nam, dùng locale vi-VN, múi giờ Asia/Ho_Chi_Minh và tiền tệ VND.	Toàn bộ handbook, template library, diagrams, API examples, database schemas, test data, cheatsheets và glossary.
PC-NOVA-003	Quy ước biểu diễn sơ đồ Nova Foods	Corpus governance của handbook	Project convention	Quy định PlantUML Activity Diagram có swimlane cho workflow liên chức năng, Mermaid cho sequence/API flow, ERD và state transition; mã màu hex chỉ là quy ước trình bày của corpus.	Chapter về process, workflow, state, data, architecture, integration, API, testing và cheatsheets về sơ đồ.
PC-NOVA-004	Quy ước governance và baseline artifact	Corpus governance của handbook	Project convention	Trạng thái DRAFT, IN_REVIEW, BASELINED, SUPERSEDED, versioning, change history và CR impact propagation là cơ chế quản trị nội dung của corpus.	Chapter về governance, traceability, change control, delivery readiness và QA; template change request, decision log, traceability matrix, approval record và QA checklist.
AR-BA-001 đến AR-BA-010	Các khuyến nghị cấu trúc requirement, decision, rule, API, NFR, data classification, testing và change impact analysis	Tác giả handbook	Author recommendation	Đây là các hướng dẫn sư phạm và thực hành được tạo để giúp người học thực hiện công việc BA theo trình tự rõ ràng khi không có chuẩn bên ngoài quy định trực tiếp cấu trúc artifact cần dùng.	Chapter về discovery, requirements, business rules, data, API, NFR, testing, traceability, governance và change control; các template liên quan được liệt kê trong từng khuyến nghị.

Quy tắc áp dụng nhãn trong nội dung handbook và template

1. Khi OWASP ASVS hoặc OWASP API Security Top 10 được tham chiếu, nội dung phải gắn nhãn Industry good practice; không được đổi thành Normative standard, Official Vietnamese law hoặc cụm từ có hàm ý bắt buộc pháp lý.

2. Khi sử dụng quy ước Nova Foods như ID pattern, tên domain, cấu trúc folder, màu hex, trạng thái artifact, hoặc dữ liệu mô phỏng, nội dung phải gắn nhãn Project convention. Không được trình bày quy ước này như quy định của IIBA, ISO, OMG, OWASP, cơ quan nhà nước Việt Nam hoặc một doanh nghiệp thực tế.

3. Khi sử dụng một mục AR-BA-xxx, nội dung phải gắn nhãn Author recommendation. Nếu một khuyến nghị được áp dụng vào tình huống có tác động pháp lý, kế toán, thuế, quyền riêng tư, an toàn thực phẩm, truy xuất nguồn gốc, kiểm soát bảo mật hoặc vận hành production, nội dung phải đồng thời được đánh dấu Verification required hoặc Project assumption cho đến khi có xác nhận từ owner có thẩm quyền.

4. Một source entry không được nhận nhiều nhãn phân loại chính để tránh che mờ nguồn thẩm quyền. Nếu một nội dung tham chiếu đồng thời OWASP, một quy ước Nova Foods và một khuyến nghị của tác giả, từng phần phải được tách thành các nhận định riêng và mang nhãn tương ứng.

5. Nhãn phân loại phải xuất hiện nhất quán trong source map, chapter text, template metadata, glossary, cheatsheet và QA_REPORT.md khi nội dung được dùng làm cơ sở cho requirement, checklist, decision criterion hoặc quality gate.

Quy tắc không suy diễn thẩm quyền pháp lý hoặc tư cách luật Việt Nam

Các mục được phân loại là Industry good practice, Project convention hoặc Author recommendation trong phần này chỉ được dùng làm hướng dẫn thực hành, cơ chế nhất quán nội bộ hoặc gợi ý sư phạm. Chúng không phải là Official Vietnamese law, không thay thế văn bản pháp luật chính thức, và không tạo ra nghĩa vụ tuân thủ pháp lý độc lập cho Nova Foods hoặc bất kỳ tổ chức thực tế nào.

Nhóm mục	Các mục áp dụng trong phần này	Có thể khẳng định	Không được khẳng định
Industry good practice	SRC-OWASP-ASVS-001; SRC-OWASP-API-2023-001	OWASP cung cấp các chủ đề, rủi ro và thực hành tham khảo hữu ích để BA nhận diện security requirement, câu hỏi làm rõ, tiêu chí review và test condition.	“OWASP là luật Việt Nam”; “tuân thủ OWASP mặc nhiên đồng nghĩa tuân thủ pháp luật”; “OWASP ASVS hoặc OWASP API Security Top 10 là chứng nhận bắt buộc”; “một control OWASP là đủ để hệ thống hợp pháp hoặc an toàn.”
Project convention	PC-NOVA-001 đến PC-NOVA-004	Quy ước Nova Foods kiểm soát tính nhất quán của corpus mô phỏng, ví dụ ID traceability, cấu trúc artifact, cách biểu diễn sơ đồ, trạng thái baseline và dữ liệu mô phỏng.	“Pattern ID của Nova Foods là quy định pháp luật”; “màu hex hoặc loại sơ đồ được pháp luật Việt Nam bắt buộc”; “trạng thái BASELINED tương đương phê duyệt pháp lý, kế toán hoặc production.”
Author recommendation	AR-BA-001 đến AR-BA-010	Khuyến nghị tác giả giúp người học có trình tự phân tích, lập tài liệu, kiểm thử và quản trị thay đổi khi chưa có quy định dự án chi tiết hơn.	“Khuyến nghị tác giả là yêu cầu pháp lý”; “một template hoặc checklist của handbook bảo đảm tuân thủ”; “người học có thể tự đưa ra kết luận pháp lý, thuế, kế toán hoặc an toàn thực phẩm chỉ dựa trên handbook.”

Quy tắc sử dụng trong requirement, decision và quality gate

1. Không được chuyển trực tiếp một khuyến nghị từ OWASP, quy ước Nova Foods hoặc khuyến nghị tác giả thành yêu cầu mang tính pháp lý bằng các cụm như “theo luật”, “bắt buộc theo quy định Việt Nam”, “đương nhiên tuân thủ”, hoặc “được cơ quan có thẩm quyền yêu cầu”, trừ khi nhận định đó được đối chiếu với nguồn Official Vietnamese law hiện hành và được owner có thẩm quyền xác nhận.

2. Khi một security control được đề xuất dựa trên SRC-OWASP-ASVS-001 hoặc SRC-OWASP-API-2023-001, BA phải diễn đạt nguồn gốc chính xác, ví dụ: “Industry good practice: tham chiếu OWASP để giảm rủi ro truy cập trái phép vào API.” Không được diễn đạt thành: “Luật Việt Nam yêu cầu control này” nếu chưa có nguồn luật chính thức và xác nhận pháp lý tương ứng.

3. Khi một quy ước PC-NOVA-xxx được dùng trong artifact, phải xác định đây là quy ước của corpus mô phỏng. Ví dụ, REQ-FUNC-SALES-012 là định danh phục vụ traceability của handbook, không phải mã biểu mẫu, mã hồ sơ, mã hóa đơn hay mã pháp lý được cơ quan nhà nước quy định.

4. Khi một AR-BA-xxx ảnh hưởng đến dữ liệu cá nhân, hóa đơn, hạch toán, thuế, điều kiện an toàn thực phẩm, truy xuất nguồn gốc, lưu trữ hồ sơ, phân quyền production hoặc xử lý sự cố bảo mật, nhận định phải được gắn thêm một trong hai trạng thái sau cho đến khi được kiểm chứng:

5. Verification required: cần đối chiếu nguồn chính thức hiện hành và xin xác nhận từ vai trò có thẩm quyền.

6. Project assumption: giả định phục vụ mô phỏng Nova Foods, không được dùng làm kết luận áp dụng cho môi trường thực tế.

7. Industry good practice có thể hỗ trợ xác định rủi ro, option và acceptance criterion kỹ thuật; nhưng không tự quyết định risk appetite, ngân sách, kiến trúc mục tiêu, mức kiểm soát bắt buộc, hoặc việc chấp nhận rủi ro còn lại. Các quyết định này thuộc authority của Business Owner, Architect, Security Owner, PM hoặc vai trò được ủy quyền trong dự án thực tế.

8. Project convention chỉ có hiệu lực trong phạm vi handbook và case study Nova Foods. Nếu được tái sử dụng cho dự án khác, quy ước phải được dự án đó tiếp nhận, điều chỉnh và phê duyệt theo governance riêng; không được giả định rằng quy ước đã được khách hàng, nhà cung cấp, kiểm toán viên hoặc cơ quan nhà nước chấp thuận.

9. Author recommendation chỉ là điểm xuất phát để người học áp dụng có giám sát. Khi mâu thuẫn với luật hiện hành, hợp đồng, policy nội bộ đã được phê duyệt, kiến trúc đã baseline, quyết định của Business Owner, hoặc hướng dẫn từ chuyên gia có thẩm quyền, các nguồn có thẩm quyền cao hơn phải được ưu tiên và khuyến nghị tác giả phải được ghi nhận là không áp dụng hoặc cần điều chỉnh.

Mẫu diễn đạt an toàn bắt buộc

Tình huống	Diễn đạt được phép	Diễn đạt bị cấm
Đề xuất kiểm soát API	“Industry good practice: Nova Foods tham chiếu OWASP API Security Top 10 để nhận diện rủi ro kiểm soát truy cập ở endpoint hoàn tiền.”	“OWASP API Security Top 10 là luật Việt Nam bắt buộc endpoint hoàn tiền phải triển khai theo cách này.”
Dùng ID requirement	“Project convention: Requirement được gán ID REQ-FUNC-SALES-012 để truy vết tới business need, acceptance criteria và test case trong corpus.”	“REQ-FUNC-SALES-012 là mã requirement theo quy định pháp luật Việt Nam.”
Dùng checklist BA	“Author recommendation: BA nên thực hiện change impact analysis trước khi đề xuất sửa business rule đã baseline.”	“Pháp luật yêu cầu mọi thay đổi business rule phải dùng đúng checklist này.”
Nêu yêu cầu liên quan dữ liệu cá nhân	“Verification required: Việc xác định thời hạn lưu trữ và điều kiện xử lý dữ liệu cá nhân phải được Legal Owner xác nhận theo văn bản chính thức hiện hành.”	“Theo OWASP, Nova Foods đã tuân thủ toàn bộ nghĩa vụ pháp lý về dữ liệu cá nhân.”
Nêu yêu cầu liên quan hóa đơn hoặc kế toán	“Project assumption: Ví dụ hạch toán trong case study chỉ phục vụ minh họa luồng tích hợp; Accounting Owner cần xác nhận trước khi dùng cho production.”	“Template hạch toán của handbook đáp ứng mặc định mọi quy định kế toán và hóa đơn tại Việt Nam.”

Các quy tắc trên áp dụng cho mọi nhận định dẫn chiếu SRC-OWASP-ASVS-001, SRC-OWASP-API-2023-001, PC-NOVA-001 đến PC-NOVA-004, và AR-BA-001 đến AR-BA-010 trong handbook, template library, cheatsheet, glossary và báo cáo QA.

Lưu ý về giấy phép và quyền truy cập đối với nguồn công khai nhưng không mang tính quy phạm

Các nguồn Industry good practice công khai có thể được truy cập để học tập, tham chiếu và xây dựng câu hỏi phân tích; tuy nhiên, “công khai trên web” không đồng nghĩa với “không có bản quyền”, “được phép sao chép không giới hạn”, “được phép sửa đổi”, hoặc “được phép gắn thương hiệu của tổ chức phát hành”. BA, người biên soạn handbook và người dùng template phải tôn trọng điều khoản sử dụng, quyền tác giả, nhãn hiệu, phiên bản và phạm vi truy cập của từng nguồn.

ID nguồn hoặc nhóm tài liệu	Phân loại	Tình trạng truy cập tại thời điểm lập Source Map	Lưu ý giấy phép và quyền sử dụng	Cách sử dụng an toàn trong handbook và artifact
SRC-OWASP-ASVS-001 — OWASP Application Security Verification Standard	Industry good practice	Trang dự án OWASP được công khai tại URL đã xác minh; nội dung có thể được cập nhật theo phiên bản dự án.	Nội dung OWASP vẫn thuộc phạm vi bản quyền, điều khoản cấp phép và quyền nhãn hiệu của OWASP Foundation hoặc chủ thể liên quan. Không được giả định mọi bản sao, bản dịch, trích xuất bảng kiểm hoặc bản sửa đổi đều được phép nếu chưa kiểm tra điều khoản của phiên bản đang dùng. Không được sử dụng tên hoặc logo OWASP theo cách hàm ý OWASP chứng nhận Nova Foods, handbook hoặc hệ thống mô phỏng.	Dẫn liên kết chính thức, nêu đúng tên nguồn và phiên bản quan sát được. Diễn giải bằng ngôn ngữ riêng của handbook; chỉ trích dẫn ngắn, chính xác và trong phạm vi được phép sau khi kiểm tra điều khoản áp dụng. Không sao chép nguyên bảng kiểm, không đóng gói lại toàn bộ tài liệu, không gắn logo OWASP vào artifact Nova Foods.
SRC-OWASP-API-2023-001 — OWASP API Security Top 10, 2023 Edition	Industry good practice	Trang ấn bản 2023 được công khai tại URL đã xác minh; nội dung trực tuyến có thể được bổ sung, sửa liên kết hoặc thay đổi cách trình bày.	Việc nguồn có thể đọc công khai không loại bỏ nghĩa vụ tuân thủ bản quyền, điều khoản sử dụng và quy tắc về nhãn hiệu OWASP. Không được coi danh sách Top 10 là tài sản công cộng không điều kiện, không được tái bản toàn văn hoặc tạo bản dịch thương mại khi chưa kiểm tra điều khoản cấp phép hiện hành.	Sử dụng như nguồn tham khảo để đặt tên nhóm rủi ro, xây dựng câu hỏi discovery hoặc test condition ở mức khái quát. Liên kết về trang ấn bản chính thức; ghi rõ “tham chiếu OWASP API Security Top 10, 2023 edition”. Tự viết ví dụ Nova Foods thay vì sao chép ví dụ, mô tả hoặc hình minh họa của OWASP.
PC-NOVA-001 đến PC-NOVA-004 — quy ước corpus Nova Foods	Project convention	Là nội dung nội bộ của corpus mô phỏng, được tạo cho handbook; không phải tài liệu do tổ chức tiêu chuẩn hoặc cơ quan nhà nước phát hành.	Các quy ước này không được suy diễn là có giấy phép mở, giấy phép tái sử dụng tự động hoặc quyền sử dụng tên “Nova Foods” cho một tổ chức thực tế. “Nova Foods Co., Ltd.”, dữ liệu, vai trò, giao dịch và artifact trong handbook là mô phỏng giáo dục.	Có thể tái sử dụng cấu trúc với điều kiện người dùng thay thế tên case study, xác lập owner, version control, quyền truy cập và governance phù hợp cho dự án của mình. Không được trình bày dữ liệu mô phỏng như dữ liệu khách hàng, nhà cung cấp, nhân viên hoặc giao dịch thực tế.
AR-BA-001 đến AR-BA-010 — khuyến nghị tác giả	Author recommendation	Được công bố như một phần của handbook và template library; quyền sử dụng phụ thuộc vào điều khoản phân phối của sản phẩm hoặc repository chứa handbook.	Không mặc định cho phép sao chép, phân phối lại, chỉnh sửa, bán lại hoặc đưa vào sản phẩm thương mại. Nếu handbook không công bố giấy phép rõ ràng, người dùng phải xin phép chủ sở hữu quyền tác giả trước khi tái sử dụng ngoài phạm vi đọc, học tập hoặc sử dụng được cho phép.	Dùng như hướng dẫn sư phạm trong corpus. Khi đưa vào tài liệu dự án thực tế, BA phải điều chỉnh theo hợp đồng, policy nội bộ, quyền sở hữu trí tuệ và quy trình phê duyệt của tổ chức tiếp nhận.

Quy tắc kiểm soát truy cập và tái sử dụng

1. Chỉ URL chính thức đã được ghi nhận trong Source Map mới được dùng làm điểm tham chiếu mặc định. Không thay thế bằng bản sao không rõ nguồn gốc, ảnh chụp màn hình không có ngữ cảnh, bản dịch không xác định người chịu trách nhiệm hoặc tài liệu được tải lại bởi bên thứ ba.

2. Khi cần sử dụng nội dung vượt quá việc tham chiếu ở mức khái quát, người biên soạn phải kiểm tra điều khoản cấp phép, thông báo bản quyền, điều kiện trích dẫn và quy tắc nhãn hiệu của đúng phiên bản nguồn tại thời điểm sử dụng. Nếu không kiểm tra được, trạng thái sử dụng phải là Verification required.

3. Không được sao chép nguyên văn toàn bộ chương, bảng kiểm, sơ đồ, hình minh họa, logo hoặc tài liệu tải xuống từ OWASP vào handbook, template hoặc tài liệu Nova Foods chỉ vì nguồn được truy cập công khai.

4. Không được tuyên bố, ám chỉ hoặc thiết kế trình bày khiến người đọc hiểu rằng OWASP Foundation đã tài trợ, phê duyệt, chứng nhận, kiểm toán hoặc xác nhận handbook “IT BUSINESS ANALYST — ZERO TO DELIVERY READY”, corpus Nova Foods, template library hoặc hệ thống ERP mô phỏng.

5. Nếu một nguồn công khai bị thay đổi, gỡ bỏ, chuyển sang hạn chế truy cập hoặc thay đổi điều khoản sử dụng, bản tham chiếu cũ không tự động tiếp tục hợp lệ. Người phụ trách artifact phải ghi nhận thay đổi, kiểm tra tác động đến nội dung đã dùng và cập nhật trạng thái xác minh khi cần.

6. Các quy ước PC-NOVA-xxx và khuyến nghị AR-BA-xxx chỉ được xem là nội dung của corpus hoặc handbook. Việc tái sử dụng ở môi trường thực tế phải được tổ chức tiếp nhận xác định rõ quyền sở hữu, quyền sửa đổi, quyền phân phối và điều kiện bảo mật riêng.

7. Mọi bản dịch tiếng Việt do handbook tự diễn giải từ nguồn tiếng Anh phải được ghi nhận là diễn giải sư phạm, không phải bản dịch chính thức, trừ khi nguồn phát hành xác nhận rõ bản dịch đó là chính thức.

Các tuyên bố bị cấm hoặc phải được giới hạn đối với hướng dẫn bảo mật, kiến trúc và quy trình

Các nguồn Industry good practice, Project convention và Author recommendation chỉ hỗ trợ nhận diện rủi ro, cấu trúc hóa phân tích, thiết kế câu hỏi kiểm tra và lựa chọn thực hành phù hợp với bối cảnh mô phỏng Nova Foods. Chúng không tự tạo ra nghĩa vụ pháp lý, không thay thế quyết định của người có thẩm quyền, và không chứng minh một giải pháp đủ an toàn, tuân thủ hoặc sẵn sàng vận hành production.

Phạm vi hướng dẫn	Nguồn hoặc nhãn áp dụng	Tuyên bố không được đưa ra	Cách diễn đạt được phép trong handbook
Bảo mật ứng dụng	SRC-OWASP-ASVS-001 — Industry good practice	Không được tuyên bố ERP Nova Foods “tuân thủ OWASP ASVS”, “được OWASP chứng nhận”, “an toàn tuyệt đối”, “không có lỗ hổng”, hoặc “đạt chuẩn production” chỉ vì đã đối chiếu một phần yêu cầu hay checklist.	“Các yêu cầu bảo mật này tham chiếu OWASP ASVS như một thực hành kiểm chứng bảo mật của ngành; phạm vi áp dụng, mức xác minh, bằng chứng kiểm thử và quyết định chấp nhận rủi ro phải do Security Owner xác nhận.”
Bảo mật API	SRC-OWASP-API-2023-001 — Industry good practice	Không được tuyên bố một API “an toàn” hoặc “không bị tấn công” chỉ vì có authentication, authorization, rate limiting, HTTPS, schema validation hoặc các test case mô phỏng. Không được khẳng định OWASP API Security Top 10 là danh mục đầy đủ của mọi rủi ro API.	“API-xxx áp dụng các kiểm soát được chọn để giảm rủi ro phù hợp với các nhóm rủi ro được OWASP API Security Top 10 nêu để tham khảo; cần threat modeling, kiểm thử bảo mật và phê duyệt rủi ro riêng trước production.”
Phân quyền và dữ liệu cá nhân	SRC-OWASP-ASVS-001, SRC-OWASP-API-2023-001, PC-NOVA-xxx	Không được suy diễn rằng role-based access control, masking, audit log hoặc consent field trong ví dụ Nova Foods tự động đáp ứng pháp luật Việt Nam về bảo vệ dữ liệu cá nhân, lưu trữ dữ liệu hoặc chuyển dữ liệu.	“Cơ chế phân quyền, masking và audit log là giả định thiết kế hoặc thực hành bảo mật tham khảo. Mọi yêu cầu pháp lý về dữ liệu cá nhân phải được Legal Owner hoặc Privacy Owner xác minh theo văn bản pháp luật hiện hành.”
Kiến trúc hệ thống	PC-NOVA-001 đến PC-NOVA-004 — Project convention	Không được gọi kiến trúc Web ERP mô phỏng là “enterprise-grade”, “scalable by design”, “highly available”, “fault tolerant”, “cloud-ready” hoặc “phù hợp production” nếu chưa có yêu cầu đo lường, thiết kế chi tiết, kiểm thử tải, kiểm thử phục hồi và quyết định kiến trúc được phê duyệt.	“Sơ đồ kiến trúc mô tả một phương án học tập cho Nova Foods. Các thuộc tính chất lượng như hiệu năng, khả năng mở rộng, sẵn sàng cao và phục hồi sau sự cố chỉ được xác nhận bằng yêu cầu NFR, bằng chứng kiểm thử và quyết định của Architect/Operations Owner.”
Lựa chọn công nghệ	AR-BA-xxx — Author recommendation	Không được tuyên bố một công nghệ, pattern, database, message queue, gateway hoặc API style là lựa chọn “tốt nhất”, “bắt buộc”, “phổ quát”, hoặc phù hợp cho mọi doanh nghiệp.	“Đây là khuyến nghị tác giả nhằm minh họa tiêu chí ra quyết định. Dự án thực tế phải đánh giá năng lực đội ngũ, chi phí, bảo mật, khả năng vận hành, hệ sinh thái, hợp đồng và ràng buộc tổ chức.”
Tích hợp và API	SRC-OWASP-API-2023-001, PC-NOVA-xxx, AR-BA-xxx	Không được khẳng định payload mẫu, HTTP status code, idempotency key, retry policy hoặc sơ đồ sequence là hợp đồng tích hợp đã được đối tác chấp thuận. Không được xem một ví dụ OpenAPI hoặc API test pass là bằng chứng liên thông production thành công.	“Payload và sequence là hợp đồng mô phỏng để học phân tích API. Hợp đồng tích hợp thực tế cần được System Owner, đối tác tích hợp, Architect, Security Owner và QA xác nhận, version hóa và kiểm thử trong môi trường được kiểm soát.”
Quy trình nghiệp vụ và workflow	PC-NOVA-xxx — Project convention; AR-BA-xxx — Author recommendation	Không được tuyên bố workflow phê duyệt tín dụng, giảm giá, hoàn tiền, sản xuất hoặc thu hồi lô hàng là quy trình chuẩn ngành, quy trình bắt buộc theo luật, hoặc quy trình đã được Nova Foods thực tế phê duyệt.	“Workflow là quy ước mô phỏng phục vụ học tập. Quyền quyết định, ngưỡng phê duyệt, segregation of duties, SLA và ngoại lệ phải được Business Owner xác nhận cho từng tổ chức thực tế.”
Quản trị chất lượng và QA	AR-BA-xxx, PC-NOVA-xxx	Không được tuyên bố traceability matrix đầy đủ, review checklist đã tick, UAT pass hoặc không còn defect mở đồng nghĩa với “không có lỗi”, “đảm bảo chất lượng tuyệt đối”, hoặc “được phép go-live”.	“Các artifact QA cung cấp bằng chứng trong phạm vi kiểm tra xác định. Quyết định release/go-live phụ thuộc vào tiêu chí chấp nhận đã phê duyệt, rủi ro tồn đọng, mức độ nghiêm trọng defect, readiness vận hành và thẩm quyền release.”
Hiệu năng, khả năng chịu tải và vận hành	AR-BA-xxx, PC-NOVA-xxx	Không được khẳng định hệ thống đáp ứng số lượng người dùng, số đơn hàng, thời gian phản hồi, RTO, RPO hoặc uptime nếu các chỉ số đó chỉ xuất hiện trong case study hay ví dụ test.	“Các chỉ số trong Nova Foods là dữ liệu mô phỏng hoặc project assumption. Chúng chỉ trở thành cam kết vận hành khi được ghi thành REQ-NFR-xxx, có phương pháp đo, môi trường đo, ngưỡng chấp nhận và bằng chứng kiểm thử được phê duyệt.”
Kế toán, thuế, an toàn thực phẩm và truy xuất nguồn gốc	PC-NOVA-xxx, AR-BA-xxx, cùng các nguồn công nghiệp khi có liên quan	Không được tuyên bố rule hoàn tiền, ghi nhận doanh thu, hóa đơn, lot tracking, expiry handling, recall workflow hoặc báo cáo quản trị là hợp pháp, đúng kế toán, đúng thuế hoặc đáp ứng đầy đủ yêu cầu an toàn thực phẩm chỉ vì chúng hợp lý về mặt quy trình.	“Rule này là project assumption hoặc mô hình học tập. Cần đánh dấu Verification required và yêu cầu Accounting Owner, Tax Advisor, Legal Owner, Food Safety Owner hoặc Domain Owner xác nhận trước khi dùng ngoài corpus.”

Quy tắc ngôn ngữ bắt buộc khi trình bày hướng dẫn không mang tính quy phạm

1. Không dùng các cụm từ khẳng định tuyệt đối như “đảm bảo”, “chắc chắn”, “luôn luôn an toàn”, “đầy đủ tuân thủ”, “chuẩn bắt buộc”, “đạt chứng nhận”, “sẵn sàng production” hoặc “không thể xảy ra lỗi”, trừ khi artifact có bằng chứng, phạm vi, chủ thể phê duyệt và thẩm quyền tương ứng được ghi nhận riêng.

2. Không dùng Industry good practice để thay thế cho Normative standard, văn bản pháp luật Việt Nam, chính sách nội bộ đã ban hành, hợp đồng, quyết định kiến trúc đã phê duyệt hoặc yêu cầu của cơ quan quản lý.

3. Không trình bày PC-NOVA-xxx như thông lệ phổ quát của ngành FMCG, sản xuất thực phẩm, ERP, thương mại B2B hoặc bán lẻ B2C. Mọi ngưỡng tiền tệ, trạng thái nghiệp vụ, luồng phê duyệt, vai trò, dữ liệu và số liệu trong Nova Foods đều là mô phỏng giáo dục.

4. Không trình bày AR-BA-xxx như yêu cầu của BABOK Guide, ISO/IEC/IEEE 29148, OWASP, OMG, W3C, ISTQB, OpenAPI Initiative hoặc cơ quan nhà nước nếu không có đối chiếu trực tiếp, chính xác với nguồn tương ứng.

5. Với mọi guidance về security, architecture hoặc process có khả năng ảnh hưởng đến quyền riêng tư, tài chính, tính liên tục kinh doanh, an toàn thực phẩm hoặc nghĩa vụ pháp lý, handbook phải nêu rõ người có thẩm quyền quyết định: Business Owner, Architect, Security Owner, Legal Owner, Privacy Owner, Accounting Owner, QA Lead hoặc Operations Owner.

6. Khi chưa có bằng chứng xác minh trực tiếp từ nguồn chính thức hiện hành hoặc từ quyết định dự án được phê duyệt, nội dung phải được gắn nhãn chính xác là Project convention, Author recommendation, Project assumption hoặc Verification required; không được nâng cấp ngầm thành cam kết tuân thủ hay cam kết kỹ thuật.

Ánh xạ mục đích sử dụng trong curriculum: yêu cầu, bảo mật, API, workflow, QA và quản trị

Bảng này quy định phạm vi sử dụng dự kiến của các nguồn Industry good practice, Project convention và Author recommendation trong handbook. Ánh xạ là kế hoạch Phase 1, không phải phê duyệt áp dụng cho production. Tên chapter và filename chính thức sẽ chỉ được khóa trong CHAPTER_MANIFEST.md ở Phase 2; các filename đã xác định trong kế hoạch hiện hành được giữ nguyên.

Lĩnh vực curriculum	Chapter hoặc artifact đích dự kiến	Nguồn/nhãn được phép dùng	Mục đích sử dụng trong handbook	Ranh giới sử dụng bắt buộc
Khám phá nhu cầu, phạm vi và yêu cầu	Các chapter về Business Need, stakeholder analysis, elicitation, scope, functional requirement, NFR, acceptance criteria; template BRD, backlog, requirement specification và traceability matrix	AR-BA-xxx — Author recommendation; PC-NOVA-xxx — Project convention	Minh họa cách phân rã nhu cầu Nova Foods từ vấn đề AS-IS thành NEED-xxx, REQ-FUNC-xxx, REQ-NFR-xxx, BR-xxx và AC-xxx; hướng dẫn chọn mức chi tiết, tiêu chí sẵn sàng review và cách đặt câu hỏi làm rõ.	Không được trình bày cấu trúc requirement, Definition of Ready, Definition of Done, mức ưu tiên hoặc ngưỡng chấp nhận của case study là yêu cầu của luật, BABOK Guide, ISO/IEC/IEEE 29148 hoặc thông lệ bắt buộc cho mọi dự án.
Yêu cầu bảo mật và kiểm soát truy cập	Các chapter về NFR, bảo mật ứng dụng, phân quyền, auditability, dữ liệu nhạy cảm và risk-based requirement review; template security requirement checklist, NFR specification và risk register	SRC-OWASP-ASVS-001 — Industry good practice; SRC-OWASP-API-2023-001 — Industry good practice; AR-BA-xxx	Hỗ trợ BA chuyển các rủi ro bảo mật phổ biến thành câu hỏi elicitation, requirement có thể kiểm thử, acceptance criteria, test condition và escalation item; ví dụ gồm xác thực, phân quyền, kiểm soát truy cập theo vai trò, validation, logging và xử lý lỗi.	OWASP chỉ được dùng như tài liệu tham khảo về thực hành kiểm chứng và nhận diện rủi ro. Không được suy diễn rằng requirement hoặc checklist dựa trên OWASP tự động đáp ứng pháp luật Việt Nam, hợp đồng, chính sách nội bộ, pentest hoặc tiêu chí release.
Phân tích và đặc tả API	Các chapter về integration analysis, API requirement, API contract, error handling, versioning và API testing; template API specification và sequence-flow artifact	SRC-OWASP-API-2023-001 — Industry good practice; SRC-OWASP-ASVS-001 — Industry good practice; PC-NOVA-xxx; AR-BA-xxx	Hướng dẫn nhận diện rủi ro API trong các luồng Nova Foods như tạo đơn hàng, kiểm tra hạn mức tín dụng, đồng bộ khách hàng, cập nhật tồn kho và tích hợp kế toán; hỗ trợ thiết kế câu hỏi về authorization, object-level access, payload validation, rate limiting, audit log, idempotency và error response.	Không được dùng OWASP để xác định giao thức, payload, HTTP status code, SLA, retry policy hoặc ownership như một chuẩn hợp đồng bắt buộc. Các API API-xxx trong handbook là hợp đồng mô phỏng và cần được các bên tích hợp xác nhận riêng trong dự án thực tế.
Workflow, approval và process control	Các chapter về process analysis, AS-IS/TO-BE workflow, approval workflow, business rules, state transition và exception handling; gồm 08-business-rules-state.md và template process map, approval matrix, state model	PC-NOVA-xxx — Project convention; AR-BA-xxx; SRC-OWASP-ASVS-001 khi workflow có kiểm soát truy cập hoặc audit trail	Mô phỏng cách thiết kế và phân tích workflow phê duyệt hạn mức tín dụng, giảm giá, hoàn tiền, phát hành lệnh sản xuất, điều chỉnh tồn kho và xử lý thu hồi lô hàng; làm rõ decision authority, segregation of duties, trạng thái, ngoại lệ và bằng chứng audit.	Không được khẳng định ngưỡng phê duyệt, vai trò, SLA, trạng thái hoặc luồng ngoại lệ của Nova Foods là quy trình chuẩn ngành, quy định pháp luật hoặc thực tế đã được doanh nghiệp phê duyệt.
QA, test design và UAT	Các chapter testing dành cho BA, đặc biệt Part 18, Part 19 và Part 20; template test condition, test scenario, test case, defect report, UAT plan và traceability matrix	AR-BA-xxx; PC-NOVA-xxx; SRC-OWASP-ASVS-001; SRC-OWASP-API-2023-001	Hướng dẫn liên kết NEED-xxx → REQ-xxx → BR-xxx → AC-xxx → TC-xxx; xác định test condition cho authorization, input validation, API payload, workflow exception và audit evidence; minh họa cách chọn kiểm thử hồi quy theo tác động thay đổi.	Không được mô tả checklist, test case pass, UAT sign-off mô phỏng hoặc traceability đầy đủ là bằng chứng hệ thống không có lỗi, đã đạt mức bảo mật yêu cầu, hoặc đủ điều kiện go-live. Quyết định release cần thẩm quyền và bằng chứng dự án thực tế.
Quản trị artifact, thay đổi và quality gate	Các chapter về traceability, baseline, change control, review, governance, delivery readiness và AI-assisted BA workflow; template change request, decision log, traceability matrix, review checklist và QA report	PC-NOVA-xxx; AR-BA-xxx	Xác lập quy ước corpus cho identifier, trạng thái artifact, versioning, baseline, change impact analysis, owner, escalation và quality gate; minh họa việc một CR-xxx phải liệt kê ID và file bị ảnh hưởng.	Đây là cơ chế quản trị nội dung và dự án mô phỏng. Không được trình bày nó như hệ thống quản lý chất lượng được chứng nhận, cơ chế kiểm soát nội bộ đầy đủ, hoặc thay thế cho chính sách doanh nghiệp, kiểm toán, phê duyệt pháp lý hay phê duyệt release.
Foundations và tư duy BA từ đầu	00-foundations.md; các chapter về mental model, stakeholder communication, decision-making và escalation	AR-BA-xxx; PC-NOVA-xxx	Cung cấp cách giải thích từ nền tảng về ranh giới trách nhiệm BA, cách phân biệt fact, assumption, rule, requirement, decision và risk; dùng Nova Foods để minh họa khi nào BA có thể đề xuất và khi nào phải escalation.	Khuyến nghị tác giả chỉ phục vụ mục tiêu sư phạm. Không được diễn giải chúng như điều kiện tuyển dụng, tiêu chuẩn năng lực được chứng nhận, lời khuyên pháp lý hoặc quyền ra quyết định thay cho Business Owner, Architect, Security Owner, Legal Owner hay Accounting Owner.

Quy tắc áp dụng khi liên kết source với chapter và template

1. Mỗi chapter hoặc template sử dụng SRC-OWASP-ASVS-001 hoặc SRC-OWASP-API-2023-001 phải gắn nhãn Industry good practice tại phần source note, quality gate hoặc rationale phù hợp.

2. Mỗi workflow, role, threshold, state, giả định dữ liệu hoặc quyết định thiết kế chỉ tồn tại trong Nova Foods phải gắn nhãn Project convention hoặc Project assumption theo đúng bản chất của nội dung.

3. Mỗi heuristic do handbook đề xuất nhưng không được truy vết trực tiếp tới nguồn bên ngoài phải gắn nhãn Author recommendation, nêu rõ mục tiêu học tập và không được diễn đạt như nghĩa vụ tuân thủ.

4. Khi một chapter đồng thời dùng OWASP, quy ước Nova Foods và khuyến nghị tác giả, chapter phải phân biệt rõ nguồn của từng kết luận: rủi ro tham khảo từ OWASP, chi tiết case study từ PC-NOVA-xxx, và phương pháp phân tích từ AR-BA-xxx.

5. Các chapter về requirements, security, API, workflow, QA và governance không được dùng nguồn không quy phạm này để kết luận về tuân thủ pháp lý Việt Nam, tuân thủ thuế hoặc kế toán, bảo vệ dữ liệu cá nhân, an toàn thực phẩm, hoặc production readiness. Các kết luận đó phải được đối chiếu với nguồn pháp lý chính thức hiện hành và xác nhận bởi owner có thẩm quyền.

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

Mục này thiết lập các kiểm tra đối chiếu chéo giữa Source Map và các artifact kế hoạch liên quan trước khi bắt đầu viết nội dung Markdown thật. Phạm vi chỉ bao gồm việc xác nhận độ khớp giữa các file kế hoạch; chưa đi vào danh sách nguồn cần Verification required, chưa đi vào open issues, và chưa đi vào escalation cụ thể.

1) Phạm vi đối chiếu chéo bắt buộc

Nhóm file đích	Mục tiêu đối chiếu	Cách dùng trong Source Map	Kết quả mong đợi trước khi drafting
CHAPTER_MANIFEST.md và kế hoạch chapter trong /02-handbook/	Bảo đảm mỗi nhóm nguồn có chỗ đứng rõ ràng trong curriculum	Gắn mỗi nguồn với chapter dự kiến sử dụng, loại lập luận được phép, và ranh giới sử dụng	Không có nguồn “mồ côi” không gắn được vào chapter nào
TEMPLATE_MANIFEST.md và kế hoạch template trong /03-templates/	Bảo đảm nguồn được dùng nhất quán khi tạo template blank và completed artifact	Gắn nguồn vào template type phù hợp: BRD, SRS, RTM, risk log, API spec, test pack, governance artifact	Không có template nào viện dẫn nguồn ngoài phạm vi mục đích của nó
ba-glossary.md	Bảo đảm thuật ngữ dùng trong Source Map không xung đột với glossary	Chuẩn hóa cách dùng thuật ngữ: normative standard, industry good practice, project convention, author recommendation, verification required	Mọi thuật ngữ thẩm quyền có định nghĩa thống nhất
diagram-cheatsheets.md và technical-cheatsheets.md	Bảo đảm quy tắc sơ đồ và kỹ thuật không mâu thuẫn với nguồn chuẩn	Gắn đúng nguồn cho notation, validation, accessibility, API, testing, and workflow conventions	Không có cheat sheet nào làm sai bản chất của nguồn gốc chuẩn
lifecycle-artifact-map.md	Bảo đảm nguồn được đặt đúng vị trí theo vòng đời BA	Ánh xạ nguồn vào discovery, analysis, specification, validation, testing, governance, operations	Mỗi nguồn có lifecycle placement rõ ràng, không trùng lặp tùy tiện
QA_REPORT.md	Bảo đảm có tiêu chí kiểm tra xuyên suốt từ Source Map sang QA	Ghi nhận mức xác minh, trạng thái kiểm tra, và điều kiện chấp nhận của từng nhóm nguồn	QA có thể chứng minh nguồn nào đã được dùng và theo ranh giới nào

2) Ma trận kiểm tra liên file cho Source Map

Kiểm tra chéo	Nguồn dữ liệu đầu vào	File đích cần khớp	Tiêu chí đạt
Đối chiếu authority classification	Danh sách nguồn đã xác minh và nhãn phân loại bắt buộc	CHAPTER_MANIFEST.md, TEMPLATE_MANIFEST.md, ba-glossary.md	Mỗi nguồn chỉ có đúng một nhãn chính: Normative standard, Official Vietnamese law, Industry good practice, Project convention, hoặc Author recommendation
Đối chiếu intended curriculum use	Trường “intended curriculum use” của từng nguồn	CHAPTER_MANIFEST.md, lifecycle-artifact-map.md	Mục đích sử dụng của nguồn phải khớp với chapter hoặc artifact được chỉ định
Đối chiếu licensing/access caveat	Trường “licensing/access caveat”	QA_REPORT.md, technical-cheatsheets.md	Không có hướng dẫn nào khiến người đọc hiểu nhầm rằng công khai trên web đồng nghĩa với quyền sao chép, sửa đổi hoặc tái bản vô điều kiện
Đối chiếu claims that must not be made	Trường “claims that must not be made”	CHAPTER_MANIFEST.md, TEMPLATE_MANIFEST.md, ba-glossary.md	Mọi chapter/template liên quan phải tránh phát ngôn bị cấm đúng như Source Map quy định
Đối chiếu legal vs non-legal boundaries	Nguồn pháp lý, chuẩn kỹ thuật, và nguồn thực hành tốt	CHAPTER_MANIFEST.md, QA_REPORT.md, lifecycle-artifact-map.md	Nguồn pháp lý không bị lẫn với nguồn good practice hoặc author recommendation
Đối chiếu Nova Foods conventions	PC-NOVA-xxx và AR-BA-xxx	TEMPLATE_MANIFEST.md, lifecycle-artifact-map.md, diagram-cheatsheets.md	Mọi quy ước mô phỏng được ghi rõ là quy ước corpus, không bị trình bày như luật hay chuẩn bắt buộc
Đối chiếu notation rule	Nguồn OMG, Mermaid/PlantUML conventions, and project conventions	diagram-cheatsheets.md, CHAPTER_MANIFEST.md	PlantUML swimlane không bị gọi nhầm là BPMN khi không dùng BPMN notation thật
Đối chiếu QA traceability needs	Nguồn kiểm thử, nguồn pháp lý, nguồn thực hành tốt	QA_REPORT.md, TEMPLATE_MANIFEST.md	QA report có thể truy vết nguồn, ranh giới sử dụng, và trạng thái xác minh của từng nhóm nội dung

3) Kiểm tra khớp giữa Source Map và kế hoạch chapter

Để tránh sai lệch khi bước sang Phase 2 và Phase 4, Source Map phải được kiểm tra với kế hoạch chapter theo các điểm sau:

1. Mỗi nguồn phải có nơi dùng rõ ràng.
   Ví dụ: nguồn về BABOK, ISO/IEC/IEEE 29148, BPMN, UML, ISTQB, OpenAPI, WCAG, OWASP và luật Việt Nam không được chỉ “liệt kê” mà phải gắn với chapter hoặc template phù hợp.

2. Không chapter nào được dựa trên nguồn vượt ranh giới.
   Nếu chapter chỉ là foundation hoặc glossary, nó không được biến thành nơi suy diễn pháp lý, diễn giải clause, hay claim tuân thủ.

3. Chapter về workflow, state, API, testing và governance phải được gắn nguồn chuẩn đúng loại.

4. Workflow/state: UML, BPMN, project convention
5. API: OpenAPI, OWASP API Security Top 10
6. Testing: ISTQB CTFL, project convention, author recommendation
7. Accessibility: WCAG

8. Governance/change control: project convention và author recommendation

9. Mỗi chapter phải có phạm vi nguồn phù hợp với mục tiêu học tập.
   Nguồn normatively strong không được dùng để tạo cảm giác “tất cả đều bắt buộc”; nguồn non-normative không được viết như luật.

4) Kiểm tra khớp giữa Source Map và kế hoạch template

Các template trong /03-templates/ cần được đối chiếu với Source Map theo các quy tắc sau:

1. Template về requirements và traceability
   Phải trỏ đúng tới nguồn về BABOK, ISO/IEC/IEEE 29148, project conventions, và author recommendations liên quan đến cấu trúc requirement và traceability.

2. Template về API specification
   Phải dùng nguồn OpenAPI và OWASP API Security Top 10 ở đúng vai trò của chúng, không biến chúng thành chuẩn pháp lý hay cam kết an ninh tuyệt đối.

3. Template về test case, defect, UAT, regression
   Phải gắn với ISTQB CTFL, project conventions và author recommendations về test design và traceability.

4. Template về governance, change request, decision log, baseline control
   Phải phản ánh rõ quy ước corpus Nova Foods, trạng thái artifact, versioning và change control.

5. Template completed artifact
   Phải đảm bảo mọi claim xuất phát từ nguồn nào đều có nhãn phù hợp, nhất là khi một artifact đồng thời dùng nguồn chuẩn, quy ước mô phỏng và khuyến nghị tác giả.

5) Kiểm tra khớp giữa Source Map và glossary / cheatsheets

Source Map chỉ có giá trị khi thuật ngữ và cheatsheet đi cùng nó dùng cùng một ngôn ngữ quản trị. Vì vậy cần đối chiếu:

• Glossary phải định nghĩa thống nhất các thuật ngữ: authority classification, verification status, project convention, normative standard, project assumption, baseline, traceability, escalation, and claim boundary.
• Diagram cheatsheet phải tách rõ PlantUML swimlane, Mermaid sequenceDiagram, Mermaid erDiagram, Mermaid stateDiagram-v2, và system context/architecture.
• Technical cheatsheet phải giữ đúng ranh giới giữa tiêu chuẩn, thực hành tốt, và quy ước Nova Foods.
• Lifecycle artifact map phải cho thấy nguồn nào phục vụ discovery, analysis, specification, validation, testing, governance, hoặc operations.

Nếu một thuật ngữ xuất hiện trong Source Map nhưng không có định nghĩa/ghi chú tương ứng trong glossary hoặc cheatsheet, đó là điểm không khớp cần sửa trước khi drafting.

6) Kiểm tra khớp giữa Source Map và QA reporting needs

QA báo cáo cuối cùng phải có thể kiểm tra được các điều sau:

• Nguồn nào đã được xác minh.
• Nguồn nào vẫn phải để Verification required.
• Nguồn nào là luật, nguồn nào là chuẩn, nguồn nào là good practice, nguồn nào là quy ước, và nguồn nào là khuyến nghị tác giả.
• Nguồn nào có caveat về bản quyền, quyền truy cập, hoặc điều kiện sử dụng.
• Nguồn nào bị giới hạn sử dụng vì liên quan pháp lý, kế toán, thuế, privacy, food safety, security, hoặc architecture.

Nói cách khác, QA report phải là nơi xác nhận rằng Source Map không chỉ “đúng nội dung”, mà còn đúng cách dùng trong toàn bộ corpus.

7) Quy tắc dừng trước khi viết Markdown thật

Trước khi chuyển sang viết artifact thực tế, tất cả các đối chiếu chéo trên phải đạt các điều kiện sau:

• Mỗi nguồn có ít nhất một vị trí sử dụng dự kiến rõ ràng.
• Mỗi nhãn authority classification được dùng nhất quán xuyên suốt.
• Không có nguồn nào bị gán nhầm sang luật, chuẩn hay best practice khác bản chất.
• Không có chapter, template, glossary entry, cheat sheet, hoặc QA note nào dùng nguồn vượt ranh giới được phép.
• Tất cả file kế hoạch liên quan có thể đọc như một hệ thống nhất quán, không xung đột thuật ngữ và không xung đột authority.

8) Kết luận kiểm tra chéo

Phần đối chiếu chéo này bảo đảm Source Map không đứng một mình mà phải liên kết được với toàn bộ kế hoạch curriculum, template, glossary, cheatsheet và QA reporting. Đây là bước kiểm soát cấu trúc trước khi viết artifact chi tiết, giúp giữ nguyên ranh giới giữa:

• nguồn chuẩn và nguồn tham khảo,
• quy ước mô phỏng và thực tế dự án,
• hướng dẫn sư phạm và cam kết vận hành,
• mô tả nội dung và tuyên bố thẩm quyền.

Ở micro-batch tiếp theo, tài liệu mới được phép xử lý các mục còn lại của section 6 theo đúng thứ tự đã lập kế hoạch.

9) Self-review checklist: đầy đủ, không trùng lặp và nhất quán phân loại

Checklist này được áp dụng cho toàn bộ các entry nguồn đã được lập kế hoạch trong /00-research/00_SOURCE_MAP.md. Mục tiêu là phát hiện thiếu trường thông tin, nguồn bị ghi lặp, hoặc cùng một nguồn bị phân loại khác nhau giữa các phần của corpus.

ID kiểm tra	Hạng mục tự rà soát	Câu hỏi phải trả lời	Bằng chứng cần xem	Tiêu chí đạt
SRC-REV-001	Đủ entry nguồn	Mỗi nguồn đã được xác định trong phạm vi curriculum có một entry riêng chưa?	Danh mục nguồn và các entry trong Source Map	Mỗi nguồn có đúng một entry chính hoặc một entry thay thế có liên kết rõ ràng
SRC-REV-002	Đủ trường catalog	Entry có title, issuer, edition/version hoặc status, stable URL, access date, authority classification, intended curriculum use, verification status, licensing/access caveat và claims that must not be made chưa?	Bảng catalog nguồn	Không thiếu trường bắt buộc; trường không xác minh được phải ghi Verification required, không được bỏ trống
SRC-REV-003	Tính chính xác định danh	Title, issuer và version/status có phản ánh đúng verified seed không?	Verified primary-source seed	Không tự đổi tên tổ chức ban hành, số hiệu văn bản, phiên bản, ngày hiệu lực hoặc tên tiêu chuẩn
SRC-REV-004	Ngày truy cập thống nhất	Mọi URL trong Source Map có ghi ngày truy cập thống nhất không?	Cột access date của toàn bộ entry	Tất cả access date là 2026-08-07
SRC-REV-005	URL có tính ổn định	URL có trỏ đến trang chính thức, trang specification chính thức hoặc trang phát hành chính thức không?	Stable URL của từng entry	URL phù hợp issuer được ghi; không thay URL chính thức bằng blog, bản sao không rõ nguồn gốc hoặc kết quả tìm kiếm
SRC-REV-006	Không trùng lặp nguồn	Có hai entry mô tả cùng một nguồn, cùng edition/version và cùng mục đích mà không có lý do tách entry không?	Toàn bộ catalog; title, issuer, version, URL	Không có entry trùng; nếu cần tách do phạm vi sử dụng khác nhau, entry phải nêu rõ quan hệ tham chiếu thay vì tạo nguồn mới giả tạo
SRC-REV-007	Không trùng lặp claim	Cùng một claim có bị gán cho nhiều nguồn theo cách làm mờ nguồn gốc chính không?	Intended curriculum use và claim boundary	Mỗi claim có nguồn chính rõ ràng; nhiều nguồn chỉ được ghi khi chúng bổ sung, không phải khi chúng bị dùng thay thế tùy tiện
SRC-REV-008	Phân loại chuẩn tắc	Nguồn có được gắn đúng một authority classification chính không?	Cột authority classification	Chỉ dùng một trong năm nhãn: Normative standard, Official Vietnamese law, Industry good practice, Project convention, Author recommendation
SRC-REV-009	Phân biệt chuẩn và luật	Tiêu chuẩn kỹ thuật, khuyến nghị accessibility và luật Việt Nam có được phân biệt rõ không?	Entry BABOK, ISO/IEC/IEEE 29148, OMG, ISTQB, OpenAPI, WCAG và văn bản pháp luật Việt Nam	Không gọi tiêu chuẩn kỹ thuật là luật; không gọi luật là good practice; không diễn giải WCAG hoặc OWASP như quy định pháp luật Việt Nam
SRC-REV-010	Phân biệt good practice	OWASP ASVS và OWASP API Security Top 10 có được ghi là Industry good practice không?	Các entry OWASP	Không trình bày OWASP như luật Việt Nam, tiêu chuẩn pháp lý bắt buộc, hoặc bảo đảm an toàn tuyệt đối
SRC-REV-011	Phân biệt quy ước dự án	Nova Foods conventions có được gắn Project convention thay vì gán cho BABOK, ISO, OMG, ISTQB hoặc luật không?	Các ghi chú quy ước corpus và simulation	Quy ước ID, màu hex, naming, trạng thái artifact và dữ liệu mô phỏng được nhận diện là quy ước dự án/corpus
SRC-REV-012	Phân biệt khuyến nghị tác giả	Nội dung hướng dẫn thực hành không có nguồn chuẩn trực tiếp có được gắn Author recommendation không?	Các entry hoặc note khuyến nghị	Không “mượn uy tín” của nguồn chuẩn cho một khuyến nghị do tác giả tổng hợp
SRC-REV-013	Nhất quán verification status	Trạng thái kiểm chứng có tương ứng với mức tiếp cận thực tế của nguồn không?	Verification status, URL, access caveat	Nguồn đã kiểm tra trực tiếp trong verified seed được ghi phù hợp; nội dung cần full licensed text, bản sửa đổi hiện hành hoặc chuyên gia xác nhận không được ghi là đã xác minh hoàn toàn
SRC-REV-014	Ranh giới nguồn có license	Nguồn paywalled, licensed hoặc chỉ có overview/abstract có caveat rõ ràng không?	Licensing/access caveat của BABOK và ISO/IEC/IEEE 29148	Không suy diễn clause, trang, bảng biểu, hoặc trích dẫn nguyên văn từ phần chưa được kiểm tra hợp lệ
SRC-REV-015	Cấm bịa dẫn chiếu	Có entry, note hoặc mapping nào chứa clause number, page number hoặc quotation không được verified seed xác nhận không?	Toàn bộ Source Map	Không có số điều, khoản, trang, mục, trích dẫn nguyên văn hoặc diễn giải như trích dẫn nếu chưa kiểm tra trực tiếp nguồn hợp lệ
SRC-REV-016	Ranh giới pháp lý	Các entry luật có nêu rằng system requirement suy ra từ luật cần legal-owner hoặc authorized accounting review không?	Entry 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	Không có entry pháp lý nào bị dùng như tư vấn pháp lý tự động hoặc kết luận compliance cho Nova Foods
SRC-REV-017	Ranh giới curriculum use	Intended curriculum use có nói rõ nguồn được dùng để dạy khái niệm, notation, kỹ thuật, template hay quality gate nào không?	Cột intended curriculum use	Mỗi entry có ít nhất một use case sư phạm cụ thể; không dùng mô tả chung chung như “tham khảo toàn bộ handbook”
SRC-REV-018	Ranh giới claim	Mỗi entry có nêu các claim không được phép phát biểu không?	Cột claims that must not be made	Claim boundary phản ánh đúng loại nguồn, khả năng truy cập và phạm vi nội dung nguồn
SRC-REV-019	Nhất quán thuật ngữ	Các nhãn authority classification và verification status có viết đúng, thống nhất chính tả và không có biến thể nghĩa tương đương không?	Toàn bộ heading, bảng và chú thích	Dùng thống nhất: Normative standard, Official Vietnamese law, Industry good practice, Project convention, Author recommendation, Verified, Verification required, Limited-use caution
SRC-REV-020	Ranh giới mô phỏng	Mọi tham chiếu đến Nova Foods có được nhận diện là tình huống mô phỏng giáo dục không?	Intended curriculum use, convention notes và ví dụ nguồn	Không nguồn nào bị dùng để ngụ ý rằng Nova Foods là tổ chức thật, đã tuân thủ pháp luật, hoặc đã được kiểm toán
SRC-REV-021	Nhất quán với manifest	Nguồn được gắn vào chapter/template có đúng vai trò phân loại và claim boundary của nó không?	CHAPTER_MANIFEST.md, TEMPLATE_MANIFEST.md và Source Map	Không có manifest nào nâng cấp good practice thành luật, hoặc dùng project convention như normative standard
SRC-REV-022	Không có khoảng trống thẩm quyền	Khi một nội dung cần nguồn pháp lý, chuyên môn kế toán, thuế, privacy, food safety hoặc security chuyên sâu, Source Map có tránh gắn nhầm một nguồn không đủ thẩm quyền không?	Authority classification, intended use và claim boundary	Không lấp khoảng trống bằng suy đoán; nội dung ngoài phạm vi phải được giữ ở trạng thái Verification required hoặc project assumption theo policy
SRC-REV-023	Khả năng audit	Một reviewer độc lập có thể lần từ claim curriculum về entry nguồn, URL, ngày truy cập, phân loại và ranh giới sử dụng không?	Toàn bộ trường catalog và mapping	Chuỗi truy vết đủ để kiểm tra lại mà không cần đoán nguồn hoặc ý định sử dụng
SRC-REV-024	Kiểm tra ngôn ngữ tuyên bố	Ngôn ngữ của entry có phản ánh đúng mức thẩm quyền không?	Title, intended use, caveat và claim boundary	Dùng “tham chiếu”, “hướng dẫn”, “áp dụng trong mô phỏng”, “cần xác minh”; tránh “bắt buộc theo luật” hoặc “đạt compliance” khi chưa có xác nhận phù hợp

Quy tắc kết luận self-review

Một entry nguồn chỉ được coi là đạt self-review khi đồng thời thỏa mãn các điều kiện sau:

1. Có đầy đủ các trường catalog bắt buộc và access date là 2026-08-07.
2. Có đúng một authority classification chính.
3. Không trùng với entry khác về nguồn, version/status và mục đích sử dụng.
4. Verification status phù hợp với mức độ kiểm tra thực tế và caveat truy cập.
5. Intended curriculum use không vượt quá phạm vi thẩm quyền của nguồn.
6. Claims that must not be made được ghi rõ để ngăn diễn giải quá mức.
7. Không chứa citation, clause number, page number hoặc quotation không được kiểm chứng.
8. Không làm mờ ranh giới giữa luật Việt Nam, tiêu chuẩn, industry good practice, project convention và author recommendation.
9. Không biến tình huống Nova Foods mô phỏng thành bằng chứng thực tế, tuyên bố tuân thủ hoặc tư vấn chuyên môn có thẩm quyền.

10) Open issues: các nguồn cần giữ trạng thái Verification required

Danh sách dưới đây ghi nhận các nguồn hoặc phạm vi sử dụng chưa đủ cơ sở để phát biểu như đã kiểm chứng đầy đủ trong corpus. Metadata và URL được lấy từ Verified primary-source seed với access date thống nhất là 2026-08-07; trạng thái Verification required phản ánh giới hạn về quyền truy cập, phạm vi kiểm tra, khả năng có sửa đổi mới hoặc nhu cầu xác nhận chuyên môn trước khi sử dụng cho nội dung cụ thể.

Issue ID	Source / issuer	Version/status theo seed	Official URL	Access date	Phạm vi đang cần xác minh	Ràng buộc sử dụng trước khi đóng issue
SRC-OI-001	BABOK Guide — IIBA	Version 3; official overview and errata	https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/	2026-08-07	Toàn văn licensed text, định nghĩa chi tiết, task, competency, cấu trúc nội dung và mọi mapping yêu cầu số trang hoặc đoạn trích	Chỉ sử dụng overview và errata đã có trong seed cho các phát biểu tổng quát. Không ghi page number, quotation, clause hoặc diễn giải như trích dẫn nguyên văn khi chưa kiểm tra bản được cấp phép
SRC-OI-002	ISO/IEC/IEEE 29148 — ISO/IEC/IEEE	29148:2018, Edition 2; confirmed 2024 and marked to be revised in 2026	https://www.iso.org/standard/72089.html	2026-08-07	Toàn văn tiêu chuẩn, nội dung điều khoản cụ thể và tình trạng phiên bản thay thế hoặc sửa đổi trong tương lai	Chỉ dùng abstract và bibliographic status đã xác nhận. Mọi claim gắn với clause, shall statement, biểu mẫu hoặc yêu cầu tuân thủ phải giữ Verification required cho đến khi kiểm tra bản văn hợp lệ
SRC-OI-003	Luật Bảo vệ dữ liệu cá nhân — Quốc hội Việt Nam	Luật 91/2025/QH15; effective 2026-01-01	https://vanban.chinhphu.vn/?classid=1&docid=214590&pageid=27160&typegroup=	2026-08-07	Việc chuyển từng nghĩa vụ pháp lý thành requirement về dữ liệu khách hàng, nhân viên, consent, retention, access, deletion, transfer hoặc incident handling của Nova Foods	Không kết luận Nova Foods compliant hoặc không compliant. Mọi requirement pháp lý cụ thể phải được đối chiếu văn bản hiện hành và xác nhận bởi legal owner có thẩm quyền
SRC-OI-004	Nghị định hướng dẫn bảo vệ dữ liệu cá nhân — Chính phủ Việt Nam	Nghị định 356/2025/NĐ-CP; effective 2026-01-01	https://vanban.chinhphu.vn/?classid=1&docid=216387&pageid=27160	2026-08-07	Phạm vi áp dụng, nghĩa vụ vận hành, hồ sơ, biện pháp bảo vệ, xử lý dữ liệu và quan hệ với các văn bản hướng dẫn hoặc sửa đổi liên quan	Không dùng các giả định privacy cũ để thay thế văn bản này. Chi tiết triển khai trong API, database, workflow hoặc audit log phải ghi Verification required nếu chưa được legal-owner review
SRC-OI-005	Luật Kế toán — Quốc hội Việt Nam	Luật 88/2015/QH13; effective 2017-01-01	https://vanban.chinhphu.vn/?docid=183198&pageid=27160	2026-08-07	Cách diễn giải quy định kế toán thành yêu cầu cho sổ sách, chứng từ, kỳ kế toán, phê duyệt, đối soát, lưu trữ và tích hợp Finance/Accounting của Nova Foods	Không tự xác định thiết kế accounting treatment hoặc kết luận hệ thống đáp ứng luật. Các nội dung kế toán phải được authorized accounting hoặc legal role xác nhận
SRC-OI-006	Hóa đơn, chứng từ — Chính phủ Việt Nam	Nghị định 123/2020/NĐ-CP; effective 2022-07-01	https://vanban.chinhphu.vn/?docid=201365&pageid=27160	2026-08-07	Sửa đổi sau ngày ban hành, yêu cầu hóa đơn điện tử, thời điểm lập, dữ liệu bắt buộc, điều chỉnh, thay thế, hủy và tích hợp với Finance/Accounting	Phải kiểm tra amendment và hướng dẫn hiện hành trước khi dùng cho production design. Không trình bày ví dụ invoice của Nova Foods là tư vấn thuế hoặc bằng chứng compliance
SRC-OI-007	Luật An toàn thực phẩm — Quốc hội Việt Nam	Luật 55/2010/QH12	https://vanban.chinhphu.vn/?docid=96032&pageid=27160	2026-08-07	Yêu cầu hiện hành về lot/batch tracking, nguồn gốc, thu hồi, lưu trữ hồ sơ, trách nhiệm doanh nghiệp và khả năng áp dụng cho hoạt động trading/manufacturing của Nova Foods	Chỉ dùng cho bối cảnh giáo dục ở mức traceability/recall cần xác minh. Không suy ra đầy đủ nghĩa vụ ngành hàng, quy trình kiểm soát hoặc kết luận food-safety compliance nếu chưa có domain-owner và legal review
SRC-OI-008	OWASP ASVS — OWASP Foundation	ASVS 5.0.0 listed as latest stable	https://owasp.org/www-project-application-security-verification-standard/	2026-08-07	Phiên bản kiểm soát cụ thể cần áp dụng cho kiến trúc Web ERP, API, authentication, authorization, session, logging và verification gate	Có thể dùng như Industry good practice để thiết kế checklist. Không gọi ASVS là luật Việt Nam, chứng nhận pháp lý hoặc bảo đảm hệ thống an toàn tuyệt đối; control cụ thể cần được security reviewer xác nhận
SRC-OI-009	OWASP API Security Top 10 — OWASP Foundation	2023 edition	https://owasp.org/API-Security/editions/2023/en/0x11-t10/	2026-08-07	Việc chuyển các nhóm rủi ro API thành threat scenarios, abuse cases, test conditions và quality gates phù hợp với phạm vi Nova Foods	Chỉ dùng cho awareness và good-practice guidance. Không dùng như danh sách đầy đủ mọi rủi ro, không thay thế threat modeling, security testing hoặc yêu cầu pháp lý
SRC-OI-010	WCAG — W3C	WCAG 2.2 Recommendation, 2024-12-12 edition	https://www.w3.org/TR/WCAG22/	2026-08-07	Success criteria cụ thể được chọn cho các màn hình Web ERP, cách kiểm thử, mức conformance và khả năng áp dụng theo người dùng hoặc bối cảnh triển khai	Chỉ phát biểu success-criterion claim sau khi đối chiếu trực tiếp Recommendation. Không tuyên bố Nova Foods đạt accessibility compliance chỉ từ việc tham chiếu WCAG
SRC-OI-011	OpenAPI Specification — OpenAPI Initiative	OAS 3.1.1, published 2024-10-24	https://spec.openapis.org/oas/v3.1.1.html	2026-08-07	Cách ánh xạ endpoint, schema, validation, error response, security scheme và versioning của API Nova Foods vào OAS 3.1.1	Cần kiểm tra trực tiếp specification khi viện dẫn feature hoặc validation behavior cụ thể. Không tuyên bố một API đạt security hoặc production readiness chỉ vì có OpenAPI document
SRC-OI-012	ISTQB CTFL — ISTQB	CTFL Syllabus v4.0.1	https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf	2026-08-07	Thuật ngữ, phạm vi và cách trình bày các black-box techniques trong các chương testing của handbook, đặc biệt khi cần trích dẫn chính xác hoặc mapping chi tiết	Có thể dùng syllabus làm nguồn chính cho thuật ngữ và kỹ thuật. Mọi trích dẫn, số mục hoặc diễn giải vượt quá nội dung đã kiểm tra phải giữ Verification required

Quy tắc đóng một open issue

Một issue chỉ được chuyển khỏi trạng thái Verification required khi có bằng chứng kiểm tra phù hợp với phạm vi claim dự kiến: bản văn hoặc specification đã được truy cập hợp lệ, phiên bản và tình trạng hiệu lực đã được đối chiếu, URL và access date được ghi nhận, đồng thời mọi giới hạn diễn giải đã được cập nhật trong entry nguồn. Khi chưa đạt điều kiện này, nội dung liên quan phải được giữ ở mức Verification required hoặc ghi rõ là project assumption, không được trình bày như nghĩa vụ pháp lý, yêu cầu chuẩn tắc, kết luận compliance hoặc quyết định production của Nova Foods.

11) Nhu cầu escalation đối với diễn giải pháp lý, nghiệp vụ chuyên ngành và an ninh

Mọi nội dung dưới đây phải được escalation trước khi chuyển từ ví dụ đào tạo hoặc project assumption thành requirement, business rule, acceptance criterion, cấu hình, thiết kế tích hợp, quyết định vận hành hoặc tuyên bố compliance cho Nova Foods. Việc escalation không đồng nghĩa với phê duyệt; quyết định chỉ có hiệu lực khi được ghi nhận bởi người có thẩm quyền của dự án.

Lĩnh vực	Open issue liên quan	Khi nào BA phải escalation	Vai trò nhận escalation	Đầu ra cần được xác nhận	Giới hạn BA không được tự quyết
Pháp lý tổng quát	SRC-OI-003, SRC-OI-004, SRC-OI-005, SRC-OI-006, SRC-OI-007	Khi requirement được mô tả là bắt buộc theo luật, nghị định, quy định cơ quan nhà nước, điều kiện kinh doanh hoặc nghĩa vụ tuân thủ	Legal owner được ủy quyền; khi cần, Business Owner và PM	Văn bản diễn giải áp dụng cho Nova Foods, phạm vi áp dụng, rủi ro, quyết định chấp nhận hoặc thay đổi requirement, người phê duyệt và ngày hiệu lực	Không diễn giải luật, xác định nghĩa vụ pháp lý, kết luận compliant hoặc xác nhận mức phạt, thời hạn pháp lý hay ngoại lệ pháp lý
Kế toán	SRC-OI-005	Khi thiết kế liên quan đến hạch toán, kỳ kế toán, đối soát, số dư phải thu, khóa sổ, điều chỉnh chứng từ, lưu trữ dữ liệu kế toán hoặc mapping sang phần mềm kế toán	Authorized accounting role; Legal owner khi có nội dung pháp lý; Finance Owner	Accounting treatment, chart-of-accounts mapping, nguyên tắc đối soát, quyền phê duyệt, retention requirement và tiêu chí UAT tài chính	Không tự chọn bút toán, tài khoản kế toán, phương pháp ghi nhận doanh thu/chi phí hoặc xác nhận sổ sách đáp ứng quy định
Thuế và hóa đơn/chứng từ	SRC-OI-006	Khi có logic về thuế suất, thời điểm lập hóa đơn, điều chỉnh, thay thế, hủy, dữ liệu hóa đơn, kết nối nhà cung cấp hóa đơn điện tử hoặc báo cáo liên quan thuế	Tax owner hoặc tư vấn thuế được ủy quyền; Authorized accounting role; Legal owner khi cần	Quy tắc nghiệp vụ đã xác nhận, nguồn hiệu lực được kiểm tra, quyết định cấu hình, trường dữ liệu bắt buộc, ngoại lệ và test evidence cần có	Không tự xác định thuế suất, nghĩa vụ khai/nộp thuế, thời điểm hợp pháp để lập hóa đơn hoặc kết luận tích hợp hóa đơn điện tử tuân thủ
Quyền riêng tư và dữ liệu cá nhân	SRC-OI-003, SRC-OI-004	Khi xử lý dữ liệu khách hàng, người liên hệ nhà cung cấp, nhân viên, tài khoản người dùng, consent, truy cập, chia sẻ, retention, deletion, export, audit log, incident hoặc dữ liệu qua API	Legal owner; Privacy/Data Protection Owner; Security Owner; Business Owner nếu thay đổi mục đích xử lý	Cơ sở và mục đích xử lý được phê duyệt, data classification, quyền truy cập, retention/deletion decision, yêu cầu audit và quyết định về dữ liệu chia sẻ với bên thứ ba	Không tự kết luận loại dữ liệu nào được phép xử lý, thời hạn lưu giữ, điều kiện consent, quyền chủ thể dữ liệu hoặc tính hợp pháp của luồng dữ liệu
An toàn thực phẩm, truy xuất nguồn gốc và thu hồi	SRC-OI-007	Khi requirement đề cập đến lot/batch, hạn dùng, nguyên liệu, thành phẩm, truy xuất nguồn gốc, cách ly hàng, thu hồi, tiêu hủy hoặc bằng chứng kiểm soát chất lượng	Food Safety/Quality Owner; Manufacturing Owner; Warehouse Owner; Legal owner khi requirement được gắn với nghĩa vụ pháp lý	Phạm vi traceability, cấp độ lot/batch, dữ liệu bắt buộc, quy trình recall, trách nhiệm quyết định hold/release và tiêu chí kiểm thử nghiệp vụ	Không tự xác định Nova Foods thuộc diện nghĩa vụ nào, thời hạn lưu hồ sơ, điều kiện thu hồi, ngưỡng chất lượng hoặc quy trình an toàn thực phẩm hợp pháp
An ninh ứng dụng và API	SRC-OI-008, SRC-OI-009, SRC-OI-011	Khi requirement hoặc thiết kế có authentication, authorization, role/permission, API token, secret, encryption, logging, session, rate limit, exposure của dữ liệu cá nhân, vulnerability, penetration test hoặc acceptance security gate	Security Owner hoặc Application Security Reviewer; Solution Architect; Privacy Owner nếu có dữ liệu cá nhân	Threat-model decision, security control scope, residual-risk decision, ownership của remediation, security-test approach và điều kiện release	Không tự tuyên bố hệ thống “an toàn”, “không có lỗ hổng”, đạt chuẩn OWASP, đủ điều kiện production hoặc chấp nhận residual risk thay mặt Security Owner
Kiến trúc ảnh hưởng đến tuân thủ	SRC-OI-003, SRC-OI-004, SRC-OI-006, SRC-OI-008, SRC-OI-009, SRC-OI-011	Khi lựa chọn kiến trúc làm thay đổi nơi lưu dữ liệu, hệ thống tích hợp, quyền truy cập liên hệ thống, cơ chế log, sao lưu, khôi phục, quản lý secret hoặc ranh giới trách nhiệm với nhà cung cấp	Solution Architect; Security Owner; Legal/Privacy Owner theo loại dữ liệu; PM	Architecture decision record, data-flow boundary, control owner, tác động đến requirement/test case và CR nếu thay đổi baseline	Không tự phê duyệt kiến trúc, mô hình chia sẻ dữ liệu, lựa chọn kiểm soát an ninh hoặc ngoại lệ kiến trúc có ảnh hưởng compliance

Quy tắc escalation trong artifact Nova Foods

1. BA phải ghi rõ trạng thái của nội dung là Verification required hoặc project assumption cho đến khi nhận được quyết định có thẩm quyền.
2. Escalation phải nêu tối thiểu: ID bị ảnh hưởng, mô tả quyết định cần xác nhận, nguồn liên quan, bối cảnh Nova Foods, rủi ro nếu diễn giải sai, lựa chọn đang cân nhắc và deadline quyết định.
3. Nếu escalation làm thay đổi business rule, entity, state, requirement, acceptance criterion, API contract hoặc test case đã baselined, thay đổi phải đi qua CR phù hợp và liệt kê đầy đủ impacted IDs/files.
4. Các vai trò chuyên môn xác nhận nội dung chuyên ngành; BA chịu trách nhiệm chuyển quyết định đã xác nhận thành artifact rõ ràng, truy vết được và có thể kiểm thử, không thay thế thẩm quyền của các vai trò đó.

12) Những điều không thể được khẳng định chỉ từ Source Map

/00-research/00_SOURCE_MAP.md là catalog nguồn và ranh giới sử dụng nguồn cho handbook. Artifact này ghi nhận nguồn dự kiến, cơ quan ban hành, phiên bản hoặc tình trạng, URL chính thức, ngày truy cập và giới hạn diễn giải. Nó không phải là bản phân tích chuyên môn, bản diễn giải pháp luật, thiết kế giải pháp, hay bằng chứng kiểm thử cho Nova Foods.

Nội dung	Source Map có thể khẳng định	Source Map không thể tự khẳng định
Sự tồn tại và nhận diện nguồn	Một nguồn đã được ghi nhận với issuer, version/status, URL và access date theo verified seed.	Toàn bộ nội dung nguồn đã được đọc, hiểu, đối chiếu đầy đủ hoặc còn hiệu lực cho mọi tình huống cụ thể.
Thẩm quyền nguồn	Nguồn được phân loại là normative standard, official Vietnamese law, industry good practice, project convention hoặc author recommendation theo quy tắc catalog.	Một standard, luật hoặc tài liệu good practice tự động áp dụng đầy đủ cho Nova Foods, một dự án cụ thể, hoặc một quyết định triển khai cụ thể.
Yêu cầu pháp lý	Một văn bản pháp luật chính thức có liên quan tiềm năng đến dữ liệu cá nhân, kế toán, hóa đơn/chứng từ hoặc an toàn thực phẩm.	Nova Foods có nghĩa vụ pháp lý cụ thể nào, thuộc ngoại lệ nào, đã đáp ứng nghĩa vụ nào, hoặc đang compliant với pháp luật Việt Nam.
Kế toán và thuế	Luật Kế toán và Nghị định 123/2020/NĐ-CP là các nguồn cần được xem xét khi xây dựng ví dụ liên quan.	Cách hạch toán, thuế suất, thời điểm lập hóa đơn, cách điều chỉnh chứng từ, nghĩa vụ khai nộp thuế hoặc tính đúng đắn của một cấu hình tài chính.
Dữ liệu cá nhân và quyền riêng tư	Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP là nguồn chính thức cần được kiểm tra khi thiết kế xử lý dữ liệu cá nhân.	Cơ sở pháp lý xử lý dữ liệu, điều kiện consent, quyền của chủ thể dữ liệu, thời hạn lưu giữ, điều kiện chia sẻ dữ liệu hoặc tính hợp pháp của một API/data flow cụ thể.
An toàn thực phẩm và truy xuất	Luật An toàn thực phẩm là bối cảnh nguồn cho các chủ đề lot/batch, truy xuất và thu hồi.	Mức độ truy xuất bắt buộc, hồ sơ phải lưu, điều kiện hold/release, tiêu chuẩn chất lượng, trigger thu hồi hoặc quy trình vận hành hợp pháp cho Nova Foods.
Security	OWASP ASVS và OWASP API Security Top 10 là industry good practice phục vụ nhận diện rủi ro và xây dựng câu hỏi kiểm tra.	Hệ thống ERP Nova Foods an toàn, không có lỗ hổng, đạt OWASP ASVS, đủ điều kiện production, hoặc đáp ứng bất kỳ nghĩa vụ pháp lý nào về security.
API và kiến trúc	OpenAPI Specification 3.1.1 cung cấp chuẩn mô tả HTTP API; UML và BPMN cung cấp ngữ nghĩa notation trong phạm vi áp dụng.	Một API contract, authorization model, integration design, data architecture hoặc sơ đồ đã đúng, khả thi, an toàn và được phê duyệt để triển khai.
Testing và chất lượng	ISTQB CTFL v4.0.1 hỗ trợ thuật ngữ và kỹ thuật kiểm thử; WCAG 2.2 hỗ trợ định hướng accessibility.	Test case đã đủ coverage, hệ thống đã pass UAT, giao diện accessible, hoặc một release đáp ứng tiêu chí chấp nhận thực tế.
Nội dung handbook	Các chủ đề có thể được định hướng bởi nguồn đã catalog và phải mang classification phù hợp.	Ví dụ mô phỏng, business rule, requirement, acceptance criterion, test data hoặc quyết định Nova Foods là sự kiện thật, quyết định thật, hay yêu cầu đã được phê duyệt.

Vì vậy, không được dùng Source Map đơn lẻ làm bằng chứng để tuyên bố rằng Nova Foods hoặc bất kỳ giải pháp nào:

• tuân thủ pháp luật Việt Nam, chuẩn quốc tế, OWASP, WCAG, BPMN, UML, OpenAPI hoặc ISTQB;
• có nghĩa vụ pháp lý, thuế, kế toán, quyền riêng tư, lao động, an toàn thực phẩm hoặc truy xuất nguồn gốc cụ thể;
• được phép xử lý, lưu trữ, chia sẻ, xóa hoặc xuất một loại dữ liệu cá nhân cụ thể;
• có thiết kế kiến trúc, API, quy trình nghiệp vụ, mô hình dữ liệu hoặc kiểm soát an ninh phù hợp để production;
• đã được Business Owner, Legal Owner, Finance Owner, Security Owner, Solution Architect, QA Lead hoặc bất kỳ authorized role nào phê duyệt;
• đã hoàn tất kiểm thử, đạt chất lượng, không có defect, không có lỗ hổng hoặc chấp nhận được residual risk;
• có số liệu, giao dịch, con người, chính sách nội bộ hoặc quyết định vận hành là sự thật ngoài đời thực.

Mọi kết luận vượt quá việc nhận diện nguồn và ranh giới sử dụng nguồn phải dựa trên văn bản hiện hành đã được kiểm tra, phạm vi áp dụng được xác nhận, quyết định có thẩm quyền, artifact có truy vết và bằng chứng phù hợp với ngữ cảnh dự án.

13) Xác nhận ngày truy cập thống nhất cho verified source seed

Tất cả URL trong verified primary-source seed của /00-research/00_SOURCE_MAP.md được ghi nhận với cùng một ngày truy cập: 2026-08-07. Ngày này là dữ liệu kiểm soát nguồn được cung cấp trong seed đã xác minh và phải được giữ nguyên, nhất quán trong mọi mục catalog nguồn của Phase 1.

Nhóm nguồn	Nguồn được áp dụng	Ngày truy cập bắt buộc
BA, requirements và terminology	BABOK Guide; ISO/IEC/IEEE 29148	2026-08-07
Notation và modeling	OMG BPMN 2.0.2; OMG UML 2.5.1	2026-08-07
Testing, API và accessibility	ISTQB CTFL v4.0.1; OpenAPI Specification 3.1.1; WCAG 2.2	2026-08-07
Security good practice	OWASP ASVS 5.0.0; OWASP API Security Top 10 2023	2026-08-07
Pháp luật Việt Nam	Luật 91/2025/QH15; Nghị định 356/2025/NĐ-CP; Luật 88/2015/QH13; Nghị định 123/2020/NĐ-CP; Luật 55/2010/QH12	2026-08-07

Quy tắc áp dụng:

1. Mỗi source entry được tạo từ verified seed phải hiển thị chính xác Access date: 2026-08-07.
2. Không được thay thế ngày này bằng ngày sinh nội dung, ngày cập nhật handbook, ngày hiệu lực văn bản hoặc ngày người học đọc handbook.
3. Last updated date: 2026-08-07 của artifact và Access date: 2026-08-07 của nguồn là hai trường quản trị khác nhau, dù có cùng giá trị ngày trong Phase 1.
4. Nếu một nguồn được kiểm tra lại sau ngày này trong một change request được phê duyệt, entry phải ghi ngày truy cập mới, lý do kiểm tra lại, version artifact mới và các file hoặc ID bị ảnh hưởng.
5. Không được suy diễn rằng ngày truy cập 2026-08-07 tự chứng minh văn bản còn hiệu lực, đã được đọc toàn văn, áp dụng cho Nova Foods, hoặc đã được Legal Owner, Finance Owner hay authorized role xác nhận.

14) Giới hạn đào tạo và thẩm quyền chuyên môn

Handbook “IT BUSINESS ANALYST — ZERO TO DELIVERY READY” và case study mô phỏng Nova Foods Trading & Manufacturing là tài liệu tự học có mục đích đào tạo. Nội dung cung cấp quy trình BA, mẫu biểu, ví dụ mô phỏng, tiêu chí chất lượng và cách nhận diện điểm cần escalte; nội dung không tạo ra thẩm quyền chuyên môn, quyền phê duyệt, quyền truy cập hệ thống production hoặc kết luận có giá trị pháp lý.

Phạm vi	Handbook có thể hỗ trợ người học	Handbook không thay thế
Pháp lý	Nhận diện khi requirement, business rule, dữ liệu cá nhân, hóa đơn hoặc truy xuất nguồn gốc có thể chịu điều chỉnh pháp luật; ghi nhận giả định, rủi ro và nhu cầu xác minh.	Ý kiến pháp lý, diễn giải luật, xác nhận hiệu lực văn bản, đánh giá tuân thủ, hoặc quyết định nghĩa vụ pháp lý của Nova Foods hay bất kỳ tổ chức nào.
Kế toán và thuế	Mô tả luồng nghiệp vụ mô phỏng, dữ liệu cần trao đổi với hệ thống kế toán và các câu hỏi cần làm rõ với Finance Owner.	Hạch toán chính thức, tư vấn thuế, xác nhận phương pháp kế toán, kê khai, quyết toán, phát hành hóa đơn hoặc phê duyệt số liệu tài chính.
Production và vận hành	Dạy cách xác định requirement, acceptance criteria, test case, kiểm soát thay đổi, rollback consideration và escalation.	Kinh nghiệm vận hành production, quyền triển khai, quyền truy cập dữ liệu thật, quyền xử lý sự cố, hoặc quyền chấp nhận rủi ro vận hành.
Thẩm quyền miền nghiệp vụ	Mô phỏng quyết định về bán hàng, tồn kho, lô hàng, sản xuất, hoàn tiền và phê duyệt của Nova Foods để minh họa kỹ thuật BA.	Quyết định của Business Owner, Process Owner, Quality Owner, Food Safety Owner, Credit Owner, Finance Owner hoặc bất kỳ domain authority được ủy quyền nào.
Bảo mật	Giới thiệu security requirement, threat-aware questioning và nguồn industry good practice như OWASP.	Đánh giá bảo mật được chứng nhận, penetration test, xác nhận tuân thủ bảo mật, hoặc chấp thuận mức rủi ro bảo mật.

Quy tắc áp dụng xuyên suốt handbook:

1. Mọi ví dụ về Nova Foods, bao gồm con người, vai trò, giao dịch, số liệu, chính sách và quyết định, đều là mô phỏng giáo dục.
2. Người học có thể sử dụng handbook để chuẩn bị artifact, nêu câu hỏi, phân tích phương án và đề xuất quyết định có căn cứ; người học không được suy diễn rằng handbook tự trao quyền phê duyệt hoặc quyền áp dụng quyết định đó vào môi trường thực tế.
3. Khi một requirement hoặc business rule liên quan đến pháp lý, thuế, kế toán, lao động, quyền riêng tư, an toàn thực phẩm, truy xuất nguồn gốc, bảo mật hoặc vận hành production, BA phải ghi rõ owner có thẩm quyền và thực hiện escalation phù hợp.
4. Không được trình bày template, worked example, acceptance criteria, test case hoặc source map như bằng chứng rằng một tổ chức đã tuân thủ pháp luật, chuẩn ngành, yêu cầu kiểm toán hoặc chính sách nội bộ.
5. Mọi quyết định triển khai thực tế phải được xác nhận trong cơ chế governance của dự án bởi đúng vai trò được ủy quyền; handbook chỉ hỗ trợ chất lượng phân tích và khả năng giao tiếp của BA.

15) Tiêu chí sẵn sàng trước khi soạn thảo artifact Markdown chính thức

Chỉ được bắt đầu soạn thảo phiên bản Markdown chính thức của /00-research/00_SOURCE_MAP.md khi tất cả tiêu chí bắt buộc dưới đây đạt trạng thái Đạt. Nếu một tiêu chí chưa đạt, artifact phải duy trì trạng thái IN_REVIEW; phần thông tin chưa đủ căn cứ phải được gắn nhãn Verification required hoặc Project assumption theo đúng phạm vi áp dụng.

Mã tiêu chí	Tiêu chí sẵn sàng	Bằng chứng bắt buộc trước khi viết	Trạng thái đạt
SRC-READY-001	Xác định đúng phạm vi artifact	Xác nhận artifact chỉ là Phase 1 Source Map, phục vụ lập bản đồ nguồn cho handbook và template library; không phải tài liệu diễn giải pháp lý, đặc tả hệ thống hoặc xác nhận tuân thủ.	Mục tiêu, phạm vi và giới hạn của source map được ghi rõ.
SRC-READY-002	Có metadata quản trị artifact đầy đủ	Có Status: IN_REVIEW, Version: v0.9.0, Owner, ngày cập nhật 2026-08-07, change history và tuyên bố chưa được baseline approval.	Không có trường metadata bắt buộc bị thiếu hoặc tự nhận đã được phê duyệt.
SRC-READY-003	Có danh mục nguồn tối thiểu theo phạm vi curriculum	Danh mục bao phủ BA, requirements, BPMN/UML, testing, OpenAPI, accessibility, security good practice và các nguồn pháp lý Việt Nam liên quan đến case study Nova Foods.	Mỗi nhóm kiến thức trọng yếu có ít nhất một nguồn phù hợp hoặc được ghi nhận là khoảng trống cần xác minh.
SRC-READY-004	Mỗi nguồn có đủ trường catalog	Mỗi entry có: title, issuer, edition/version hoặc status, stable URL, access date, authority classification, intended curriculum use, verification status, licensing/access caveat và claims that must not be made.	Không có source entry chỉ chứa URL hoặc tên nguồn mà thiếu ranh giới sử dụng.
SRC-READY-005	Phân loại thẩm quyền nhất quán	Mỗi entry được phân loại rõ là Normative standard, Official Vietnamese law, Industry good practice, Project convention hoặc Author recommendation.	Không gán nhầm industry good practice thành luật, không gán project convention thành tiêu chuẩn quốc tế.
SRC-READY-006	Trạng thái xác minh được quyết định minh bạch	Mỗi source entry được gắn một trạng thái phù hợp: Verified, Verification required hoặc Limited-use caution.	Không sử dụng nguồn chưa kiểm tra như căn cứ chắc chắn cho claim chi tiết.
SRC-READY-007	Có ranh giới claim an toàn	Với nguồn chỉ có abstract, overview, trang giới thiệu, nội dung bị paywall hoặc chưa đọc toàn văn, source map nêu rõ không được trích dẫn clause, page, requirement chi tiết hoặc quotation.	Không có clause number, page number, quotation hoặc diễn giải chi tiết nào không được xác minh từ văn bản nguồn.
SRC-READY-008	Các nội dung nhạy cảm được đặt đúng luồng xác minh	Chi tiết về thuế, kế toán, lao động, privacy, dữ liệu cá nhân, an toàn thực phẩm và truy xuất nguồn gốc được định tuyến tới owner có thẩm quyền hoặc được gắn Project assumption/Verification required.	Không có requirement mô phỏng nào được trình bày như nghĩa vụ pháp lý đã được xác nhận.
SRC-READY-009	Liên kết sử dụng trong curriculum có thể thực hiện	Mỗi nguồn có intended curriculum use đủ cụ thể để sau này liên kết tới chapter, template, glossary entry, cheatsheet hoặc QA check tương ứng.	Không có nguồn được đưa vào catalog mà không nêu lý do sử dụng trong corpus.
SRC-READY-010	Nova Foods được giữ đúng tính chất mô phỏng	Phạm vi sử dụng nguồn pháp lý, chuẩn và good practice được diễn đạt cho case study mô phỏng Nova Foods Trading & Manufacturing.	Không khẳng định Nova Foods là doanh nghiệp có thật, đang áp dụng quy định cụ thể hoặc đã đạt tuân thủ.
SRC-READY-011	Không có xung đột với governance của corpus	Tên file, trạng thái artifact, version và nguyên tắc source boundary phù hợp với /01-curriculum/, /02-handbook/, /03-templates/, /04-cheatsheets/, /05-glossary/ và /06-qa/.	Không tạo identifier, baseline, approval hoặc quyết định thay đổi ngoài thẩm quyền của Phase 1.
SRC-READY-012	Quyết định dừng hoặc tiếp tục được ghi nhận	Nếu mọi tiêu chí từ SRC-READY-001 đến SRC-READY-011 đạt, có thể soạn thảo artifact Markdown chính thức ở trạng thái IN_REVIEW. Nếu chưa đạt, chỉ được hoàn thiện kế hoạch, bổ sung xác minh hoặc escalte.	Trạng thái sẵn sàng được nêu rõ là READY FOR IN_REVIEW DRAFTING hoặc NOT READY FOR DRAFTING.

Quy tắc quyết định: READY FOR IN_REVIEW DRAFTING không đồng nghĩa với BASELINED, APPROVED, hợp pháp để triển khai production, hay đã được legal/accounting/domain authority xác nhận. Nó chỉ xác nhận rằng cấu trúc source map đã đủ kiểm soát để bắt đầu viết artifact nghiên cứu có truy vết, có giới hạn claim và có cơ chế gắn cờ nội dung cần xác minh.