02 Stakeholders Domain And Context

Artifact Governance Metadata

Trường kiểm soát	Giá trị
Tên tệp được kiểm soát	/02-handbook/02-stakeholders-domain-and-context.md
Tiêu đề tài liệu	02 Stakeholders Domain And Context
Status	IN_REVIEW
Version	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ quản trị	Asia/Ho_Chi_Minh
Locale	vi-VN
Bối cảnh quốc gia	Việt Nam
Đơn vị tiền tệ mô phỏng	VND
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục
Dữ liệu	Chỉ dữ liệu tổng hợp
Owner	Principal IT Business Analyst / Technical Curriculum Author
Phân loại nguồn	Handbook nội bộ của corpus; tham chiếu thuật ngữ BA trong ranh giới an toàn từ BABOK Guide Version 3
Baseline reference	Chưa có baseline reference tại v0.9.0
Approval reference	Chưa có approval reference tại v0.9.0
Giới hạn thẩm quyền	Nội dung không xác nhận yêu cầu Nova Foods thực tế, không diễn giải pháp lý, kế toán, tuân thủ, bảo mật hoặc cho phép triển khai production.

1. Concept l? g??

Core

Chương này xác định ba lớp cần hiểu trước khi BA thu thập hoặc viết yêu cầu: stakeholder, domain và context. BA không bắt đầu bằng màn hình ERP hay danh sách chức năng. BA bắt đầu bằng câu hỏi: ai bị ảnh hưởng, công việc thuộc lĩnh vực nào, và tình huống nào làm nhu cầu xuất hiện. Ba lớp này tạo khung để phân biệt nhu cầu thật với giải pháp được nêu vội.

Stakeholder là cá nhân, nhóm, tổ chức hoặc hệ thống có lợi ích, trách nhiệm, quyền quyết định hoặc chịu tác động bởi thay đổi. Một người có thể là stakeholder dù không dùng ERP trực tiếp. Ví dụ, bộ phận kho có thể nhập nhận hàng; kế toán cần chứng từ từ giao dịch đó; quản lý vận hành chịu trách nhiệm khi tồn kho sai. Bằng chứng để nhận diện stakeholder là mối liên hệ kiểm chứng được với quyết định, dữ liệu, quy trình, rủi ro hoặc kết quả nghiệp vụ; không phải chức danh nghe có vẻ liên quan.

Domain là lĩnh vực nghiệp vụ có khái niệm, quy tắc, dữ liệu và mục tiêu riêng. Trong ERP, domain có thể là mua hàng, kho, sản xuất, bán hàng hoặc kế toán. Domain không đồng nghĩa với một phòng ban hay một màn hình. Một phòng ban có thể tham gia nhiều domain; một domain có thể đi qua nhiều phòng ban. BA phải hiểu domain đủ để gọi đúng đối tượng, hiểu đúng sự kiện nghiệp vụ và không biến thuật ngữ địa phương thành quy tắc hệ thống.

Context là hoàn cảnh cụ thể bao quanh nhu cầu hoặc thay đổi: mục tiêu, thời điểm, kênh vận hành, hệ thống hiện có, dữ liệu liên quan, ràng buộc, rủi ro và giả định. Cùng một nhu cầu “xem tồn kho” có context khác nhau khi nhân viên kho kiểm tra để xuất hàng, quản lý kiểm tra để lập kế hoạch, hoặc kế toán kiểm tra để đối soát. Vì mục tiêu và hậu quả khác nhau, yêu cầu, quyền truy cập, dữ liệu hiển thị và tiêu chí đúng có thể khác.

Ba khái niệm liên kết theo nguyên tắc: stakeholder cho biết ai có liên quan và vì sao; domain cho biết nghiệp vụ nào đang được nói tới; context cho biết khi nào, ở đâu, dưới ràng buộc nào nhu cầu có ý nghĩa. Nếu thiếu một lớp, BA dễ thu yêu cầu mơ hồ. Nếu người nói không xác định được stakeholder chịu hậu quả, domain chứa quy tắc, hoặc context kích hoạt nhu cầu, phát biểu đó chưa đủ làm cơ sở cho yêu cầu ERP.

Phạm vi chương là hiểu và mô tả khung stakeholder–domain–context ở mức phân tích nghiệp vụ. Chương không xác lập quy tắc Nova Foods, không chọn cấu hình ERP, không phân quyền production, không kết luận tuân thủ pháp lý và không thay thế quyết định của Business Owner, Architect, Security, Accounting, Legal hoặc Compliance.

Core

Thuật ngữ	Nghĩa Việt ngắn gọn	Vai trò khi BA phân tích
Stakeholder	Bên liên quan: người, nhóm hoặc tổ chức bị ảnh hưởng, có ảnh hưởng, hoặc cần thông tin về thay đổi.	Xác định ai cung cấp sự thật nghiệp vụ, ai quyết định, ai dùng kết quả.
Domain	Miền nghiệp vụ: vùng kiến thức và hoạt động mà hệ thống phục vụ, như mua hàng, kho, sản xuất, bán hàng.	Đặt đúng ngữ cảnh; tránh mô tả ERP bằng thuật ngữ kỹ thuật rời nghiệp vụ.
Context	Bối cảnh: điều kiện, ranh giới, tác nhân ngoài, hệ thống liên quan và mục tiêu đang chi phối vấn đề.	Giải thích vì sao cùng một hành động có thể tạo kết quả khác nhau.
Actor	Tác nhân thực hiện hoặc khởi phát hành vi. Có thể là người, vai trò nghiệp vụ, hệ thống, thiết bị hoặc dịch vụ.	Trả lời câu hỏi: ai hoặc cái gì làm việc này? Không mặc định actor là một cá nhân.
Action	Hành động: việc actor thực hiện để thay đổi, kiểm tra, gửi, nhận hoặc quyết định.	Dùng động từ kiểm chứng được: tạo, xác nhận, ghi nhận, xuất, từ chối. Tránh động từ mơ hồ như “xử lý” nếu chưa nói rõ xử lý gì.
Object	Đối tượng: thông tin, chứng từ, hàng hóa hoặc thực thể bị action tác động.	Trả lời câu hỏi: action tác động lên cái gì? Ví dụ: đơn mua hàng, lô nguyên liệu, phiếu nhập kho.
Outcome	Kết quả: trạng thái hoặc giá trị có thể quan sát sau action.	Phân biệt với action. “Ghi nhận phiếu nhập” là action; “tồn kho lô tăng và phiếu có trạng thái Đã ghi nhận” là outcome.
ERP	Enterprise Resource Planning — hệ thống hoạch định nguồn lực doanh nghiệp, kết nối dữ liệu và quy trình giữa nhiều bộ phận.	ERP không tự là quy trình nghiệp vụ; ERP hỗ trợ hoặc kiểm soát quy trình đã được xác định.
Business Analyst (BA)	Chuyên viên phân tích nghiệp vụ, làm rõ nhu cầu, bối cảnh, quy tắc, yêu cầu và bằng chứng quyết định.	BA không tự thay Business Owner quyết định chính sách nghiệp vụ hoặc xác nhận vận hành thực tế.

Công thức tối thiểu để mô tả một mẩu nghiệp vụ: Actor + Action + Object + Outcome. Bốn phần này tạo câu quan sát được. Nếu thiếu actor, không biết trách nhiệm thuộc ai. Nếu thiếu object, phạm vi dữ liệu hoặc hàng hóa bị mơ hồ. Nếu thiếu outcome, không kiểm tra được hành động đã đạt mục tiêu chưa.

Thành phần	Ví dụ Nova Foods mô phỏng, dữ liệu tổng hợp	Bằng chứng phân loại
Actor	Nhân viên kho	Vai trò này thực hiện thao tác nghiệp vụ.
Action	ghi nhận	Đây là động từ thay đổi thông tin.
Object	phiếu nhập kho cho lô nguyên liệu RM-SYN-001	Phiếu và lô là đối tượng bị cập nhật hoặc tham chiếu.
Outcome	tồn kho khả dụng của RM-SYN-001 tăng 500 kg trong dữ liệu mô phỏng	Đây là kết quả có thể đối chiếu sau thao tác.

Câu hoàn chỉnh: “Nhân viên kho ghi nhận phiếu nhập kho cho lô nguyên liệu RM-SYN-001; tồn kho khả dụng tăng 500 kg.” Câu này mô tả một lát cắt nghiệp vụ, chưa phải yêu cầu hệ thống, quy tắc nghiệp vụ, thiết kế màn hình, cấu hình ERP hay bằng chứng tuân thủ.

Ranh giới khái niệm: phần này chỉ chuẩn hóa ngôn ngữ để nhận diện bên liên quan, miền nghiệp vụ và bối cảnh. Không xác định quyền truy cập, luồng phê duyệt, trạng thái chứng từ, công thức tồn kho, quy tắc kế toán, nghĩa vụ pháp lý hoặc cấu hình Nova Foods. Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi tên, mã và số liệu đều là dữ liệu tổng hợp.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi tên và dữ liệu dưới đây là tổng hợp. Ví dụ tối thiểu: Nhân viên kho cần ghi nhận hàng nguyên liệu đến. Actor là người hoặc hệ thống tham gia, ở đây là Nhân viên kho. Action là việc thực hiện, ở đây là ghi nhận. Object là đối tượng bị tác động, ở đây là Phiếu nhận hàng mô phỏng GRN-SIM-0001. Outcome là kết quả mong muốn kiểm chứng được, ở đây là phiếu có trạng thái Recorded để bộ phận mua hàng biết lô hàng đã đến.

Thành phần	Nội dung mô phỏng	Lý do xác định
Facts	Nhà cung cấp giao 100 kg đường; Nhân viên kho nhận hàng tại kho nguyên liệu.	Đây là dữ kiện quan sát được, chưa phải yêu cầu hay quyết định.
Current Behavior	Nhân viên kho ghi số lượng vào bảng tính riêng rồi báo mua hàng qua tin nhắn.	Cùng một sự kiện bị ghi ở hai nơi, nên dễ lệch dữ liệu.
Underlying Need	Có một bản ghi nhận hàng dùng chung, xác định ai ghi nhận, ghi nhận vật gì và kết quả là gì.	Nhu cầu nằm dưới cách làm hiện tại: kiểm soát thông tin, không phải mặc định phải mua ERP hay làm màn hình mới.
Actor	Nhân viên kho.	Vai trò khởi tạo hành động.
Action	Ghi nhận nhận hàng.	Hành vi nghiệp vụ cần mô tả.
Object	Phiếu nhận hàng GRN-SIM-0001, nguyên liệu đường, số lượng 100 kg.	Đối tượng cung cấp phạm vi dữ liệu của hành động.
Outcome	Phiếu được ghi nhận để mua hàng theo dõi trạng thái giao hàng.	Kết quả nêu giá trị cần đạt, không suy diễn cấu hình hệ thống.
Artifact	Mô tả ngữ cảnh actor–action–object–outcome trong /02-handbook/02-stakeholders-domain-and-context.md.	Artifact học liệu ghi nhận cách hiểu; không là requirement đã phê duyệt.
Authority	Business Owner xác nhận nhu cầu nghiệp vụ; Warehouse Owner xác nhận thực tế kho; BA ghi nhận và truy vết.	BA không tự quyết định quy trình vận hành hoặc cấu hình ERP.
Consequence if Wrong	Nếu nhầm Nhân viên mua hàng là actor, quy trình có thể giao sai trách nhiệm; nếu nhầm outcome là “tạo hóa đơn”, phạm vi có thể lấn sang kế toán.	Sai định danh thành phần làm sai stakeholder, requirement và kiểm thử sau này.

Ranh giới concept: Phân tích ngữ cảnh này chỉ trả lời bốn câu hỏi: ai tham gia, làm gì, tác động lên gì, và cần kết quả nào. Nó dùng để tạo hiểu biết chung trước khi chi tiết hóa yêu cầu.

Loại trừ rõ ràng: Không xác định màn hình ERP, trường dữ liệu bắt buộc, API, phân quyền, quy tắc hạch toán, thuế, giá trị tồn kho, tiêu chuẩn an toàn thực phẩm, thiết kế BPMN, hoặc tiêu chí kiểm thử. Các nội dung đó cần artifact và thẩm quyền riêng. Việc nhận hàng có thể liên quan truy xuất nguồn gốc hoặc kế toán, nhưng trong ví dụ này không suy diễn nghĩa vụ pháp lý hay quy tắc vận hành; cần xác minh bởi domain owner và vai trò pháp lý/kế toán có thẩm quyền khi đi vào phạm vi đó.

2. T?i sao concept n?y t?n t?i?

Core

Phân tích stakeholder, domain và context tồn tại để ngăn dự án ERP giải sai vấn đề. Stakeholder là cá nhân, nhóm hoặc vai trò bị ảnh hưởng, cung cấp đầu vào, quyết định hoặc sử dụng kết quả. Domain là miền nghiệp vụ, gồm thuật ngữ, đối tượng và quy trình như mua hàng, kho, sản xuất, bán hàng. Context là ranh giới tình huống: ai làm gì, với đối tượng nào, để đạt kết quả nào.

Không xác định ba phần này trước khi viết yêu cầu, cùng cụm từ có thể mang nghĩa khác giữa các bộ phận. Ví dụ, “nhận hàng” có thể là xác nhận xe đã đến với bộ phận kho, kiểm tra số lượng với mua hàng, hoặc căn cứ ghi nhận chứng từ với kế toán. Nếu BA ghi một yêu cầu chung mà không xác định actor, outcome và ranh giới nghiệp vụ, đội phát triển phải tự chọn nghĩa. Lựa chọn đó là suy diễn kỹ thuật, không phải quyết định nghiệp vụ có thẩm quyền.

Rủi ro chính gồm: yêu cầu mơ hồ, làm lại do sai phạm vi, thiếu stakeholder quyết định, xung đột giữa bộ phận, và mất truy vết từ nhu cầu đến kiểm thử. Rủi ro quản trị xuất hiện khi BA biến ý kiến một người thành quy tắc chung, hoặc dùng artifact học liệu mô phỏng như quyết định vận hành. Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi dữ liệu là tổng hợp, không xác nhận quy trình ERP thực tế.

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

flowchart TB
    A[Stakeholder nêu nhu cầu]

    A --> B[BA xác định stakeholder liên quan:<br/>người bị ảnh hưởng, cung cấp đầu vào,<br/>quyết định hoặc sử dụng kết quả]
    A --> C[BA phân tích domain:<br/>thuật ngữ, đối tượng, quy trình]
    A --> D[BA xác định context:<br/>actor, hành động, đối tượng,<br/>outcome, ranh giới nghiệp vụ]

    B --> E[Phạm vi và cách hiểu chung]
    C --> E
    D --> E

    E --> F[Yêu cầu có owner nghiệp vụ<br/>và ranh giới cụ thể]
    F --> G[Thiết kế theo yêu cầu]
    G --> H[Kiểm thử truy vết<br/>từ nhu cầu qua yêu cầu]

    A -. bỏ sót phân tích .-> I[Thiếu stakeholder, domain hoặc context]

    I --> J[Thiếu stakeholder quyết định]
    J --> K[Quyết định không có thẩm quyền]

    I --> L[Thiếu domain hoặc context]
    L --> M[Diễn giải khác nhau]
    M --> N[Đội phát triển tự chọn nghĩa]
    N --> O[Suy diễn kỹ thuật<br/>không có thẩm quyền]

    L --> P[Yêu cầu mơ hồ hoặc sai phạm vi]
    L --> Q[Xung đột giữa bộ phận]
    M --> R[Làm sai hoặc làm lại]
    P --> R
    Q --> R

    I --> S[Mất truy vết<br/>từ nhu cầu đến kiểm thử]

    A -. chỉ dựa vào ý kiến một người .-> T[BA biến ý kiến một người<br/>thành quy tắc chung]
    A -. dùng sai artifact học liệu .-> U[Dùng artifact mô phỏng<br/>làm quyết định vận hành]

Applied

Trong Nova Foods mô phỏng, Nhân viên kho nói: “Cần ghi nhận nhận hàng nhanh.” Câu này chưa đủ để tạo requirement. Nó không chỉ rõ hàng nào, thời điểm nào, ai xác nhận chênh lệch, hay kết quả nghiệp vụ cần đạt. Nếu đội phát triển tạo màn hình “Nhận hàng” từ câu này, màn hình có thể phục vụ thao tác nhập kho nhưng không phục vụ nhu cầu theo dõi giao hàng của mua hàng. Dự án khi đó phải sửa luồng, dữ liệu hoặc trách nhiệm sau khi bộ phận khác xem xét.

Điểm kiểm soát	Nội dung trong phạm vi item này
Facts	Có một phát biểu nhu cầu từ vai trò Nhân viên kho trong case study mô phỏng.
Current Behavior	Phát biểu chưa nêu actor chịu trách nhiệm cuối, đối tượng nghiệp vụ và outcome.
Underlying Need	Cần làm rõ ngữ cảnh trước khi diễn giải thành yêu cầu ERP.
Options	Ghi ngay thành yêu cầu; hoặc lập mô tả stakeholder–domain–context trước.
Decision Criteria	Giảm diễn giải tự do; xác định đúng người cần xác nhận; giữ phạm vi không lấn sang kế toán, thuế hoặc truy xuất nguồn gốc.
Decision	Dùng phân tích stakeholder, domain và context trước khi chi tiết hóa yêu cầu.
Authority	Business Owner và domain owner xác nhận nhu cầu nghiệp vụ; BA ghi nhận, làm rõ và truy vết.
Artifact	/02-handbook/02-stakeholders-domain-and-context.md ghi nhận khung hiểu chung học liệu.
Consequence if Wrong	Sai actor hoặc outcome làm requirement sai phạm vi; thiết kế, phân quyền và kiểm thử sau đó có thể phải làm lại.

Senior Lens

BA không “thu thập ý kiến rồi viết lại”. BA kiểm tra ý kiến đó thuộc vai trò nào, tác động domain nào, nằm trong ranh giới nào, và ai có quyền quyết định khi có xung đột. Đây là kiểm soát governance: ngăn một người dùng, nhà phát triển hoặc BA tự biến cách hiểu cục bộ thành quyết định toàn dự án.

Ranh giới này đặc biệt quan trọng với ERP vì một thao tác có thể chạm kho, mua hàng, kế toán và chất lượng. Việc một domain có liên quan không đủ để đưa nó vào phạm vi. Chỉ đưa vào khi có nhu cầu, owner và thẩm quyền xác nhận phù hợp. Nội dung pháp lý, kế toán, thuế, an toàn thực phẩm, riêng tư dữ liệu hoặc truy xuất nguồn gốc cần xác minh bởi vai trò có thẩm quyền; handbook không thay thế xác nhận đó.

Quick Reference

Rủi ro cần ngăn	Kiểm soát bằng concept
Cùng từ, nhiều cách hiểu	Xác định thuật ngữ domain và context sử dụng.
Sai người quyết định	Xác định stakeholder, vai trò và authority.
Requirement phình sang domain khác	Nêu actor, object, outcome và ranh giới.
Đội kỹ thuật tự suy diễn nghiệp vụ	Ghi rõ điều chưa được xác nhận, không biến thành rule.
Làm lại thiết kế và kiểm thử	Tạo hiểu biết chung trước khi đặc tả chi tiết.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi tên, chứng từ, hành vi và dữ liệu dưới đây là dữ liệu tổng hợp. Concept stakeholder, domain and context tồn tại để BA không biến câu nói rời rạc thành yêu cầu ERP. Stakeholder là bên chịu tác động, cung cấp đầu vào hoặc có quyền quyết định. Domain là phạm vi nghiệp vụ như bán hàng, kho, sản xuất, kế toán. Context là điều kiện vận hành, dữ liệu, hệ thống và thẩm quyền bao quanh quyết định.

Trạng thái	Tình huống Nova Foods	Hệ quả quan sát được
Trước khi xác định context	Nhân viên kho nói: “Đơn gấp phải xuất trước.” BA ghi yêu cầu “ERP ưu tiên đơn gấp” mà không xác định ai gắn nhãn gấp, kho nào xuất, tồn khả dụng là gì, hay có cần chặn đơn đang giữ hàng cho khách khác.	Dev tạo cờ urgent; Sales tự chọn cờ khi tạo đơn; kho phải hỏi lại Sales trước mỗi lần xuất; QA không có tiêu chí xác định đơn nào phải được ưu tiên.
Sau khi xác định context	BA tách vai trò: Sales tạo yêu cầu ưu tiên; Warehouse Supervisor xác nhận khả năng xuất; Customer Service chịu trách nhiệm thông báo khách. BA ghi phạm vi là Sales Order đến Warehouse Issue, không suy diễn sang giá bán hay hóa đơn.	Mỗi yêu cầu ưu tiên có người tạo, trạng thái và lý do; kho biết điểm kiểm tra; QA có luồng kiểm thử theo trạng thái; tranh chấp ưu tiên được truy về đúng vai trò.

Thành phần Applied case	Nội dung artifact-ready
Facts	Case mô phỏng có Sales, Warehouse và Customer Service. Hành vi hiện tại được mô tả là kho nhận yêu cầu “đơn gấp” qua trao đổi nội bộ.
Current Behavior	Warehouse chọn đơn để xuất dựa trên thông tin nhận được, không có bản ghi ERP chung về lý do hoặc người yêu cầu ưu tiên.
Underlying Need	Cần thấy rõ yêu cầu ưu tiên nào đã vào luồng xử lý kho, ai chịu trách nhiệm thông tin, và khi nào kho được phép xuất.
Options	1. Cho mọi Sales tự đánh dấu urgent. 2. Tạo yêu cầu ưu tiên có trạng thái và người xác nhận kho.
Decision Criteria	Có truy vết người yêu cầu; không tự suy diễn quyền giữ hoặc phân bổ tồn; QA kiểm tra được; không tạo quyết định kế toán, pháp lý hay an toàn thực phẩm.
Decision	Dùng yêu cầu ưu tiên riêng, tách khỏi cờ tự do trên Sales Order, cho mục đích học liệu.
Authority	Business Owner xác nhận ý nghĩa nghiệp vụ của “ưu tiên”; Warehouse Supervisor xác nhận điểm kiểm tra kho; BA ghi nhận và truy vết. Chưa có approval hay baseline tại v0.9.0.
Artifact	Ghi trong /02-handbook/02-stakeholders-domain-and-context.md; khi catalog tương ứng được lập, liên kết dùng đúng ID CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY.
Consequence if Wrong	Nếu nhầm Sales có toàn quyền ưu tiên, ERP có thể đưa đơn vào kho khi kho chưa xác nhận khả năng xuất. Nếu nhầm kho quyết định cam kết khách hàng, Customer Service có thể thông báo sai trạng thái.

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

flowchart TB
    S[Sales tạo yêu cầu ưu tiên<br/>ghi người yêu cầu và lý do]
    S --> W[Warehouse Supervisor kiểm tra khả năng xuất]
    W -->|Xác nhận| U1[Cập nhật trạng thái: đã xác nhận]
    W -->|Không xác nhận| U2[Cập nhật trạng thái: không xác nhận]
    U1 --> C1[Customer Service thông báo khách:<br/>kho đã xác nhận khả năng xuất]
    U2 --> C2[Customer Service thông báo khách:<br/>kho chưa xác nhận khả năng xuất]

Sơ đồ không phải BPMN. Nó chỉ chỉ ra ranh giới trách nhiệm: Sales nêu nhu cầu, kho kiểm tra khả năng thực hiện, Customer Service giao tiếp với khách. Nhờ ranh giới này, thay đổi “thêm ưu tiên đơn hàng” không còn là một câu mơ hồ; nó trở thành tập thông tin, vai trò và điểm kiểm tra có thể quan sát.

Core

Phân loại đúng trạng thái phát biểu ngăn BA biến lời kể thành yêu cầu, hoặc biến giả định thành sự thật. Mỗi phát biểu Nova Foods Trading & Manufacturing là mô phỏng giáo dục, dữ liệu tổng hợp, phải có nhãn và bằng chứng riêng.

Loại	Định nghĩa từ đầu	Bằng chứng tối thiểu	Được dùng để làm gì	Không được suy diễn thành
Fact đã xác minh	Thông tin đã đối chiếu với nguồn xác định, còn truy lại được	URL chính thức, artifact kiểm soát, bản ghi hệ thống mô phỏng, ngày truy cập 2026-08-07	Ràng buộc bối cảnh, traceability	Quyết định Nova Foods đã phê duyệt
Stakeholder input	Ý kiến, mô tả nhu cầu hoặc cách làm do stakeholder cung cấp	Tên vai trò, thời điểm, nội dung ghi nhận	Đầu vào phân tích	Sự thật khách quan hoặc quy tắc bắt buộc
Project assumption	Điều tạm coi đúng để tiếp tục lập kế hoạch khi chưa đủ bằng chứng	Lý do, tác động nếu sai, owner xác minh, hạn xác minh	Giảm khoảng trống tạm thời	Fact, requirement, phê duyệt
Decision	Lựa chọn giữa các phương án theo tiêu chí và thẩm quyền	Phương án, tiêu chí, authority, trạng thái quyết định	Chỉ đạo artifact tiếp theo	Approval nếu chưa có bằng chứng approval
Verification-required claim	Phát biểu có thể ảnh hưởng pháp lý, kế toán, thuế, an toàn thực phẩm, bảo mật hoặc vận hành nhưng chưa được người có thẩm quyền xác minh	Nguồn cần kiểm, vai trò cần xác minh, câu hỏi mở	Cờ escalation, không cho thành rule	Nghĩa vụ tuân thủ hoặc cấu hình production

Applied

Trường	Nội dung ghi nhận cho case Nova Foods mô phỏng
Facts	CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY đều có trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07; các artifact này nói rõ chưa có baseline reference hay approval reference.
Current Behavior	Điều phối viên kho nói: “Lô hàng cần truy được từ thành phẩm về nguyên liệu.” Đây là stakeholder input, vì mới là lời cung cấp từ vai trò; chưa có bằng chứng quy trình, cấu hình ERP hoặc thẩm quyền pháp lý.
Underlying Need	BA cần biết mức truy vết nào phục vụ nghiệp vụ mô phỏng: liên kết lô nguyên liệu, lệnh sản xuất và lô thành phẩm, hay chỉ tra cứu theo chứng từ. Cầu nối suy luận: lời nói nêu mục tiêu truy vết, nhưng không nêu dữ liệu tối thiểu, phạm vi hay tiêu chí chấp nhận.
Options	(1) Ghi phát biểu thành fact. (2) Ghi thành stakeholder input, tạo assumption về liên kết ba loại lô, rồi yêu cầu xác minh. (3) Ghi thành quyết định kỹ thuật.
Decision Criteria	Có nguồn kiểm chứng chưa; phát biểu có chọn phương án chưa; ai có thẩm quyền về vận hành và an toàn thực phẩm; sai khác có làm sai thiết kế dữ liệu không.
Decision	Chọn phương án (2): giữ nguyên phát biểu là stakeholder input; ghi liên kết lô ba tầng là project assumption; gắn Verification required cho phạm vi truy vết liên quan Luật An toàn thực phẩm. Đây là quyết định phân loại của artifact học liệu, không phải quyết định vận hành Nova Foods.
Authority	Business Owner và domain owner xác minh nhu cầu vận hành; Legal Owner xác minh diễn giải nghĩa vụ pháp lý; Architect xác minh khả năng thiết kế; Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì traceability.
Artifact	Ghi trong /02-handbook/02-stakeholders-domain-and-context.md; tham chiếu nguyên dạng CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY; không tạo rule mới.
Consequence if Wrong	Nếu gọi stakeholder input là fact, đội dữ liệu có thể thiết kế quan hệ lô quá mức hoặc thiếu mức truy vết cần thiết. Nếu gọi assumption là decision, reviewer có thể hiểu nhầm đã có thẩm quyền chấp thuận.

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

flowchart TB
    A["Phát biểu của Điều phối viên kho:<br/>“Lô hàng cần truy được từ thành phẩm về nguyên liệu.”"]

    E["CANONICAL_BUSINESS_RULES<br/>CANONICAL_DATA_DICTIONARY<br/>TRACEABILITY_ID_REGISTRY"] --> F["IN_REVIEW · v0.9.0 · 2026-08-07<br/>không có baseline reference<br/>không có approval reference"]
    F --> G["Chỉ chứng minh trạng thái artifact;<br/>không xác minh phát biểu stakeholder"]

    A --> C{"Tiêu chí phân loại:<br/>Có nguồn kiểm chứng?<br/>Phát biểu đã chọn phương án?<br/>Ai có authority?<br/>Sai lệch có ảnh hưởng thiết kế dữ liệu?"}
    G --> C

    C --> P["Quyết định phân loại theo bằng chứng hiện có:<br/>giữ phát biểu là Stakeholder input;<br/>ghi liên kết ba tầng là Project assumption;<br/>giữ phạm vi pháp lý là Verification required"]

    P --> H["Project assumption:<br/>liên kết lô nguyên liệu,<br/>lệnh sản xuất và lô thành phẩm"]
    P --> I["Verification required:<br/>phạm vi truy vết liên quan<br/>Luật An toàn thực phẩm"]
    P --> B["Stakeholder input:<br/>giữ nguyên phát biểu và nguồn vai trò"]

    H --> J["Business Owner và domain owner<br/>xác minh nhu cầu vận hành"]
    H --> K["Architect xác minh<br/>khả năng thiết kế"]
    I --> L["Legal Owner xác minh<br/>diễn giải nghĩa vụ pháp lý"]

    J --> J1["Kết quả vận hành:<br/>xác nhận, bác bỏ hoặc chưa đủ bằng chứng"]
    K --> K1["Kết quả thiết kế:<br/>khả thi, không khả thi hoặc đang chờ"]
    L --> L1["Kết quả pháp lý:<br/>đã xác minh hoặc tiếp tục Verification required"]

    J1 --> M["Theo kết quả xác minh:<br/>giữ hoặc đổi nhãn;<br/>xác nhận hoặc bác bỏ assumption;<br/>cập nhật traceability"]
    K1 --> M
    L1 --> M

    B --> R["Principal IT Business Analyst /<br/>Technical Curriculum Author<br/>chỉ duy trì traceability"]
    M --> R

    R --> Q["Ranh giới:<br/>không tạo business rule mới;<br/>không phải phê duyệt hay quyết định<br/>vận hành Nova Foods"]

    P --> S{"Phân loại sai?"}
    S -->|Có| T["Có thể thiết kế quan hệ lô<br/>quá mức hoặc thiếu mức truy vết"]
    S -->|Có| U["Có thể tạo ấn tượng sai rằng<br/>assumption đã được phê duyệt"]
    S -->|Không| V["Duy trì đúng nhãn, trạng thái xác minh,<br/>authority và traceability"]

Senior Lens

Cùng một câu có thể chứa nhiều loại, nên không gắn một nhãn cho cả đoạn. Ví dụ: “Kho đang ghi lô trên phiếu, nên ERP phải bắt buộc truy vết theo luật.” Phần “Kho đang ghi lô trên phiếu” là stakeholder input cho đến khi đối chiếu chứng từ mô phỏng. Phần “ERP phải bắt buộc” là verification-required claim vì chưa có quyết định và tiêu chí. Phần “theo luật” cần Legal Owner xác minh với nguồn chính thức; BA không được diễn giải Luật An toàn thực phẩm thành requirement cụ thể.

Quy tắc ghi nhận: fact phải nêu nguồn; input phải nêu người nói và vai trò; assumption phải nêu điều kiện sai; decision phải nêu authority và tiêu chí; verification-required claim phải nêu người xác minh. Không dùng trạng thái IN_REVIEW làm bằng chứng fact về nghiệp vụ, baseline hoặc approval.

Quick Reference

Câu hỏi kiểm tra	Nhãn đúng
“Có tài liệu hoặc nguồn truy lại được không?”	Fact đã xác minh
“Đây có phải điều stakeholder nói hoặc mong muốn không?”	Stakeholder input
“Nhóm đang tạm dựa vào điều này để đi tiếp không?”	Project assumption
“Đã chọn một phương án, có tiêu chí và authority rõ không?”	Decision
“Phát biểu này đụng pháp lý, kế toán, thuế, bảo mật hoặc an toàn thực phẩm nhưng chưa được owner xác minh không?”	Verification-required claim

3. V? tr? trong Lifecycle

Core

Lifecycle là chuỗi giai đoạn biến một nhu cầu chưa rõ thành thay đổi có thể vận hành. Với Nova Foods Trading & Manufacturing, đây là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Concept Stakeholders, Domain And Context đi xuyên sáu giai đoạn vì mỗi giai đoạn cần kiểm tra cùng một câu: ai bị ảnh hưởng, nghiệp vụ nào đổi, dữ liệu nào đi qua, và giới hạn nào không được suy đoán.

Entry gate là điều kiện phải có trước khi bắt đầu giai đoạn. Exit gate là điều kiện tối thiểu phải đạt trước khi chuyển tiếp. Gate không phải approval. IN_REVIEW, Version v0.9.0, ngày 2026-08-07 chỉ cho biết artifact đang xem xét; không xác nhận baseline, phê duyệt, tuân thủ hay sẵn sàng production.

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

flowchart TB
    D[Discovery] --> A[Analysis]
    A --> DE[Delivery]
    DE --> T[Testing]
    T --> R[Release]
    R --> O[Operations]
    O -. phản hồi mới .-> D

    D --- D1[Entry: tín hiệu nhu cầu, vấn đề hoặc thay đổi; nguồn ghi là stakeholder input, fact hoặc project assumption]
    D --- D2[Exit: problem statement; phạm vi ban đầu; stakeholder input tách khỏi fact; claim chưa xác minh giữ nhãn Verification required]

    A --- A1[Entry: output Discovery truy vết được; không dùng lời kể như fact]
    A --- A2[Exit: requirement liên kết nguồn; mâu thuẫn được ghi; assumption nêu điều kiện sai; không biến diễn giải pháp lý thành rule]

    DE --- DE1[Entry: requirement đủ rõ để xây dựng; điểm chưa quyết định không bị che thành certainty]
    DE --- DE2[Exit: thay đổi kỹ thuật liên kết requirement; sai lệch thiết kế so với phân tích được ghi nhận]

    T --- T1[Entry: build deployable; test basis liên kết requirement và acceptance criteria]
    T --- T2[Exit: kết quả test ghi Pass, Fail hoặc Blocked; defect hoặc gap liên kết requirement nguồn]

    R --- R1[Entry: bản ghi thay đổi và kết quả test; điều kiện phát hành được ghi rõ]
    R --- R2[Exit: release record; phạm vi phát hành; giới hạn đã biết; điểm theo dõi được ghi]

    O --- O1[Entry: release record; người vận hành có thông tin thay đổi cần thiết]
    O --- O2[Exit: phản hồi mới thành input Discovery; không tự coi phản hồi là requirement đã quyết định]

Giai đoạn	Entry gate chính xác	Công việc của concept	Exit gate chính xác
Discovery	Có tín hiệu nhu cầu, vấn đề hoặc thay đổi; nguồn được ghi là stakeholder input, fact hoặc project assumption	Xác định bối cảnh nghiệp vụ, nhóm bị ảnh hưởng, thuật ngữ, quy trình hiện tại và câu hỏi chưa biết	Có problem statement; phạm vi ban đầu; stakeholder input tách khỏi fact; claim pháp lý, kế toán, bảo mật hoặc an toàn thực phẩm chưa xác minh giữ nhãn Verification required
Analysis	Output Discovery truy vết được; không dùng lời kể như fact	Chuyển nhu cầu thành requirement, business rule, data need, acceptance criteria và dependency	Mỗi requirement liên kết về nguồn; mâu thuẫn được ghi; assumption nêu điều kiện sai; không biến diễn giải pháp lý thành rule
Delivery	Requirement đủ rõ để xây dựng; điểm chưa quyết định không bị che thành certainty	Dùng context, rule, data và acceptance criteria làm build basis	Thay đổi kỹ thuật liên kết requirement; sai lệch thiết kế so với phân tích được ghi nhận
Testing	Có build deployable; test basis liên kết requirement và acceptance criteria	Kiểm tra hành vi mong đợi, dữ liệu, lỗi và điều kiện biên	Kết quả test ghi Pass, Fail hoặc Blocked; defect hoặc gap liên kết requirement nguồn
Release	Có bản ghi thay đổi và kết quả test; điều kiện phát hành được ghi rõ	Kiểm tra release không làm mất traceability giữa nhu cầu, thay đổi và bằng chứng	Có release record; phạm vi phát hành, giới hạn đã biết và điểm theo dõi được ghi
Operations	Có release record; người vận hành có thông tin thay đổi cần thiết	Quan sát phản hồi, lỗi, ngoại lệ và tác động nghiệp vụ sau phát hành	Phản hồi mới trở thành input Discovery; không tự coi phản hồi là requirement đã quyết định

Applied

Facts: Nova Foods mô phỏng nhận phản ánh rằng kho khó xác định lô hàng khi khách trả sản phẩm. Đây là stakeholder input, chưa phải fact về cấu hình ERP hay nghĩa vụ pháp lý.

Current Behavior: Nhân viên kho ghi mã lô trên phiếu giấy tổng hợp. Bằng chứng cần kiểm tra là mẫu phiếu mô phỏng và luồng dữ liệu hiện có; lời kể đơn lẻ chưa đủ chứng minh.

Underlying Need: Cần biết yêu cầu có phải truy vết lô cho đổi trả, kiểm soát chất lượng, báo cáo nội bộ, hay nghĩa vụ pháp lý. Lý do: mỗi mục tiêu tạo dữ liệu, rule và tiêu chí test khác nhau.

Options: (1) Chỉ ghi mã lô tự do; (2) chọn mã lô từ danh sách ERP; (3) chặn hoàn trả nếu không có mã lô. Mỗi option phải được phân tích sau Discovery, không chọn trong lúc ghi nhận vấn đề.

Decision Criteria: Khả năng xác định lô; ảnh hưởng vận hành kho; dữ liệu sẵn có; lỗi nhập liệu; tác động tích hợp; yêu cầu cần Legal Owner hoặc domain owner xác minh.

Decision: Chưa có decision tại IN_REVIEW. Analysis chỉ được chuyển tiếp khi option được đối chiếu với evidence và tiêu chí.

Authority: Không suy ra authority từ status artifact. Nếu option được nêu là đáp ứng nghĩa vụ an toàn thực phẩm, cần Legal Owner và domain owner xác minh nguồn chính thức trước khi gọi là requirement bắt buộc.

Artifact: Discovery ghi nguồn phản ánh và câu hỏi; Analysis tạo requirement candidate, data fields candidate, acceptance criteria candidate và traceability link.

Consequence if Wrong: Nếu biến phản ánh thành rule bắt buộc quá sớm, Delivery có thể xây chặn giao dịch không cần thiết; Testing sẽ kiểm tra sai test basis; Release có thể gây gián đoạn đổi trả.

Senior Lens

Gate tốt kiểm tra khả năng chuyển giao tri thức, không kiểm tra độ dài tài liệu. Discovery chưa được qua gate nếu câu “kho cần truy vết lô” không chỉ ra ai nói, bối cảnh nào, bằng chứng nào có hoặc thiếu. Analysis chưa được qua gate nếu requirement không phân biệt rule đã quyết định với assumption. Testing chưa được qua gate nếu kết quả Pass không liên kết acceptance criteria. Chuỗi này giữ nguyên reasoning bridge: nguồn tạo input, input được phân tích thành requirement, requirement làm test basis, test result tạo bằng chứng phát hành.

Quick Reference

Gate	Câu hỏi dừng
Discovery exit	Đã tách stakeholder input, fact, assumption và verification-required claim chưa?
Analysis exit	Mỗi requirement có nguồn, bối cảnh và tiêu chí kiểm tra chưa?
Delivery exit	Build có liên kết requirement, không tự thêm rule nghiệp vụ chưa?
Testing exit	Mỗi kết quả test có test basis truy vết được chưa?
Release exit	Bản ghi phát hành có nêu đúng phạm vi và giới hạn đã biết chưa?
Operations exit	Phản hồi vận hành đã quay lại thành input mới, không bị gọi là decision chưa?

Core

Owner thượng nguồn tạo hoặc làm rõ đầu vào. Owner hạ nguồn dùng đầu ra để quyết định, xây dựng, kiểm thử hoặc vận hành. Handoff là điểm chuyển giao có bằng chứng: người giao, người nhận, artifact, phạm vi quyết định, điểm còn mở. Không có handoff rõ, người nhận sẽ tự suy diễn; suy diễn làm đứt traceability.

Luồng	Owner giao	Artifact giao	Owner nhận	Quyền owner giao	Điểm escalation
Nhu cầu nghiệp vụ	Business Owner	Mục tiêu, vấn đề, ưu tiên nghiệp vụ mô phỏng	BA	Xác nhận ý định nghiệp vụ; không tự chốt thiết kế ERP	Mục tiêu mâu thuẫn giữa Sales, Kho, Sản xuất
Phân tích	BA	Requirement, quy tắc, giả định, traceability	Solution Architect, Delivery Lead, QA Lead	Làm rõ và duy trì liên kết; không tự phê duyệt rule hoặc kiến trúc	Rule chạm kế toán, pháp lý, bảo mật, dữ liệu cá nhân
Thiết kế	Solution Architect	Phương án kỹ thuật, interface, ràng buộc tích hợp	Delivery Lead, BA, QA Lead	Quyết định trong boundary kiến trúc được giao; không tự đổi mục tiêu nghiệp vụ	Chi phí, rủi ro, hoặc thiết kế vượt phạm vi đã ghi nhận
Xây dựng	Delivery Lead	Increment, thay đổi kỹ thuật, lỗi hoặc câu hỏi làm rõ	QA Lead, BA	Điều phối delivery; không tự diễn giải requirement mơ hồ thành rule mới	Requirement thiếu acceptance criteria hoặc xung đột thiết kế
Kiểm thử	QA Lead	Test evidence, defect, kết quả đối chiếu	BA, Business Owner, Delivery Lead	Đánh giá theo test basis; không tự chấp nhận thay đổi nghiệp vụ	Defect làm thay đổi rule, dữ liệu, quyền truy cập, báo cáo
Vận hành	Operations Owner	Sự cố, phản hồi, dữ liệu vận hành tổng hợp	Business Owner, BA, Delivery Lead	Quản lý vận hành trong phạm vi được giao; không tự sửa canonical rule	Sự cố ảnh hưởng an toàn thực phẩm, kế toán, bảo mật, dữ liệu cá nhân

Quy tắc thẩm quyền: BA được ghi nhận, phân tích, truy vết và nêu phương án. Business Owner quyết định ưu tiên và ý định nghiệp vụ. Solution Architect quyết định tính phù hợp kỹ thuật. QA Lead xác nhận bằng chứng kiểm thử theo test basis. Legal Owner, Accounting Owner, Security Owner phải xác minh nội dung thuộc chuyên môn tương ứng. IN_REVIEW tại v0.9.0 không là approval, baseline, hay quyền triển khai production.

Applied — Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dữ liệu tổng hợp.

Mục	Nội dung
Facts	Sales đề nghị cho phép sửa đơn bán sau khi kho đã giữ tồn. BA nhận yêu cầu từ Sales Owner.
Current Behavior	Không có artifact canonical trong nguồn được cấp xác nhận thời điểm khóa đơn hoặc quyền sửa tồn.
Underlying Need	Sales cần sửa số lượng giao; Kho cần tránh giữ tồn sai; Kế toán cần tránh suy diễn tác động chứng từ.
Options	Giữ mở quyền sửa; khóa đơn khi giữ tồn; cho phép sửa có workflow phê duyệt.
Decision Criteria	Ảnh hưởng tồn kho, audit trail, quyền truy cập, tác động kế toán, khả năng kiểm thử, owner có thẩm quyền.
Decision	Chưa chọn rule. Ghi Verification required vì thiếu xác nhận Business Owner, Accounting Owner và Solution Architect.
Authority	BA lập vấn đề và traceability; Business Owner quyết định quy tắc; Accounting Owner xác minh tác động kế toán; Solution Architect xác minh thiết kế; Security Owner xác minh quyền sửa.
Artifact	Liên kết tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY; giữ trạng thái IN_REVIEW, version v0.9.0.
Consequence if Wrong	Tồn kho có thể bị giữ sai, đơn giao bị hiểu sai, hoặc thay đổi bị diễn giải nhầm là quyết định kế toán hay production.

Escalation phải xảy ra ngay khi một handoff chứa quyết định thuộc từ hai owner chuyên môn trở lên, khi artifact canonical mâu thuẫn, hoặc khi người nhận không thể thực hiện bước kế tiếp mà không tự tạo rule mới. BA không giải quyết bằng tự chọn phương án; BA đóng gói facts, nguồn, phương án, tác động và owner cần quyết định.

Core

Bản đồ vòng đời giúp người học thấy thứ tự làm việc trước khi đọc chi tiết từng pha. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Sơ đồ này là flowchart Mermaid, không phải BPMN; BPMN 2.0.2 của OMG là nguồn chuẩn khi cần ký pháp BPMN.

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

flowchart LR
    D[Discovery<br/>Khám phá vấn đề] --> A[Analysis<br/>Phân tích nhu cầu]
    A --> DE[Delivery<br/>Xây dựng giải pháp]
    DE --> T[Testing<br/>Kiểm thử]
    T --> R[Release<br/>Phát hành]
    R --> O[Operations<br/>Vận hành]
    O -. phản hồi vận hành .-> D

Mũi tên liền biểu thị luồng tiến chính: hiểu vấn đề, làm rõ nhu cầu, xây dựng, kiểm thử, phát hành, vận hành. Mũi tên nét đứt biểu thị phản hồi: dữ liệu vận hành có thể tạo vấn đề mới và khởi động vòng Discovery tiếp theo. Sơ đồ không khẳng định Nova Foods đang dùng ERP, quy trình, cấu hình hoặc quyết định thực tế nào.

Applied

Trường	Nội dung case mô phỏng
Facts	Nova Foods cần người học định vị một nhu cầu ERP trong chuỗi từ Discovery đến Operations.
Current Behavior	Người mới thường coi Delivery là điểm bắt đầu, rồi không biết vì sao Testing thiếu test basis hoặc Operations nhận thay đổi khó truy vết.
Underlying Need	Cần một bản đồ nhìn nhanh để thấy mỗi pha chỉ có ý nghĩa khi nhận được kết quả từ pha trước.
Options	Dùng đoạn văn tuần tự; dùng bảng; dùng Mermaid flowchart.
Decision Criteria	Phải quét nhanh, hiển thị đủ sáu pha, chạy được trong Markdown hỗ trợ Mermaid, không tạo quy tắc vận hành mới.
Decision	Dùng Mermaid flowchart sáu pha và một vòng phản hồi từ Operations về Discovery.
Authority	Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì học liệu IN_REVIEW v0.9.0; không xác nhận quyết định nghiệp vụ, production, pháp lý, kế toán hoặc phê duyệt.
Artifact	/02-handbook/02-stakeholders-domain-and-context.md, section 03-lifecycle.
Consequence if Wrong	Bỏ hoặc đảo pha làm người học suy diễn sai nguồn gốc requirement, test basis và phản hồi vận hành; traceability giữa artifact bị đứt.

Senior Lens

Sơ đồ vòng đời không phải kế hoạch dự án. Nó chỉ trả lời câu hỏi “nội dung đang ở pha nào trong chuỗi giá trị”. Bằng chứng là tên pha mô tả trạng thái công việc, không chứa ngày, nguồn lực, ngân sách VND, SLA hoặc cam kết triển khai. Vì vậy không dùng sơ đồ này làm bằng chứng baseline, approval, tuân thủ hay quyền phát hành production.

Quick Reference

Ký hiệu	Nghĩa dùng trong sơ đồ
Mũi tên liền	Trình tự chính của công việc.
Mũi tên nét đứt	Phản hồi từ vận hành quay lại khám phá.
Discovery	Nhận diện vấn đề và bối cảnh.
Analysis	Chuyển nhu cầu thành nội dung có thể phân tích.
Delivery	Tạo hoặc cấu hình giải pháp theo nội dung đã phân tích.
Testing	Kiểm tra giải pháp với test basis phù hợp.
Release	Đưa thay đổi đã đủ điều kiện của dự án vào môi trường mục tiêu.
Operations	Theo dõi, sử dụng và ghi nhận phản hồi sau phát hành.

4. Input c?n thi?t

Core

Input là thứ BA phải có trước khi mô tả stakeholder, domain hoặc bối cảnh. Người mới không cần biết ERP trước: ERP là hệ thống giúp nhiều bộ phận dùng cùng dữ liệu để vận hành. BA không bắt đầu bằng ý kiến cá nhân; BA bắt đầu bằng bằng chứng và artifact nguồn.

Bốn nhóm input cần kiểm kê:

Nhóm	Nội dung cần có	Vì sao cần
Kiến thức nền	Mục tiêu học liệu, phạm vi Nova Foods, khái niệm stakeholder, domain, process, data	Giúp hiểu thuật ngữ trước khi diễn giải artifact.
Bằng chứng	Metadata, nguồn chính thức, nội dung đã kiểm soát, ghi nhận giới hạn thẩm quyền	Mỗi nhận định phải truy ngược được về nguồn hoặc phải mang nhãn giả định.
Artifact nguồn	Manifest, registry, catalog, data dictionary, handbook dependency	Artifact xác định tên tệp, phạm vi và quan hệ giữa nội dung.
Canonical ID bền vững	CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY	ID không đổi khi tiêu đề diễn đạt lại; traceability không đứt vì tên gọi.

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục. Mọi tên, vai trò, quy trình và dữ liệu dưới đây là dữ liệu tổng hợp. IN_REVIEW v0.9.0 ngày 2026-08-07 không phải baseline, approval, xác nhận nghiệp vụ, quyết định pháp lý hay quyền dùng production.

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

flowchart TB
    A[Kiến thức nền] --> E[BA kiểm kê và hợp nhất input]
    B[Bằng chứng] --> E
    C[Artifact nguồn] --> E
    D[Canonical ID bền vững] --> E

    E --> F[Kiểm tra nguồn và phạm vi]
    F --> G{Nhận định truy ngược được về nguồn?}
    G -->|Có| H[Nhận định có traceability]
    G -->|Không| I[Gắn nhãn giả định]
    H --> J[Mô tả stakeholder, domain và bối cảnh]
    I --> J

Sơ đồ dùng Mermaid flowchart, không phải BPMN. Nó cho thấy BA cần hợp nhất kiến thức, bằng chứng và artifact; không mô tả quy trình vận hành ERP Nova Foods.

Applied

Facts: Corpus dùng locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND. Artifact đang IN_REVIEW, version v0.9.0, ngày 2026-08-07. Nova Foods chỉ dùng dữ liệu tổng hợp.

Current Behavior: Người học có thể thấy nhiều tệp và tưởng mỗi tệp là nguồn độc lập. Thực tế, manifest, registry, rule catalog và data dictionary có vai trò khác nhau; tên gần giống không đủ để thay thế ID canonical.

Underlying Need: BA cần lập danh mục input trước khi nhận diện ai ảnh hưởng đến ERP và dữ liệu nào thuộc domain. Nếu thiếu danh mục, BA có thể dùng nhầm bản sao, suy diễn rule chưa được xác nhận, hoặc gắn nhầm nguồn cho requirement.

Input Nova Foods mô phỏng	Canonical ID hoặc định danh giữ nguyên	Tệp nguồn canonical	Nội dung BA lấy từ input	Bằng chứng dùng được	Mục chưa xác minh
Cấu trúc chapter handbook	CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Xác định chapter này thuộc handbook và giữ đúng tên tệp.	Metadata ghi IN_REVIEW, v0.9.0, 2026-08-07; Nova Foods là mô phỏng giáo dục.	Không có baseline reference; không được gọi nội dung là đã baseline.
Kiến trúc curriculum	01_CURRICULUM_ARCHITECTURE	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Hiểu chuỗi học từ phân tích đến testing và delivery.	Metadata nêu vi-VN, Asia/Ho_Chi_Minh, VND và giới hạn Owner.	Không xác nhận cấu hình ERP, kế hoạch dự án hoặc quyết định vận hành.
Registry định danh	TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Giữ nguyên ID khi liên kết artifact và kiểm tra traceability.	Registry là nguồn canonical cho định danh trong corpus.	Nội dung chi tiết từng ID ngoài phần được cung cấp cần Verification required.
Catalog quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Phân biệt rule catalog với stakeholder statement hoặc giả định BA.	Catalog quy định Owner không xác nhận rule vận hành thực tế.	Rule Nova Foods cụ thể chưa được xác nhận nghiệp vụ.
Từ điển dữ liệu logic	CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Nhận diện nơi tra cứu khái niệm dữ liệu logic canonical.	Artifact ID và đường dẫn canonical được nêu rõ.	Thuộc tính dữ liệu, cấu trúc DB và mapping integration cần Verification required nếu chưa có mục dữ liệu được kiểm soát.
Source map	00_SOURCE_MAP	/00-research/00_SOURCE_MAP.md	Xác định nguồn chuẩn, pháp lý và ranh giới dùng nguồn.	Nguồn BABOK Guide, ISO/IEC/IEEE 29148, BPMN, UML, pháp luật Việt Nam có URL chính thức.	Điều khoản chính xác trong tài liệu có license cần Verification required.
Quy ước case study	Không tạo ID mới	Các artifact upstream đã nêu	Giữ Nova Foods là simulated educational case study; chỉ dùng synthetic data.	Metadata lặp lại ranh giới mô phỏng trong artifact upstream.	Không có bằng chứng Nova Foods là doanh nghiệp thật hoặc tuân thủ quy định cụ thể.

Options:
1. Dùng tên hiển thị của tệp làm liên kết.
2. Dùng canonical ID và đường dẫn tệp canonical cùng nhau.
3. Tạo ID mới cho từng đoạn handbook.

Decision Criteria: Liên kết phải truy ngược được, không tạo nguồn chân lý mới, không làm đổi ID đã đăng ký, không biến nội dung IN_REVIEW thành approval.

Decision: Dùng phương án 2. Ví dụ, khi cần nói về ID, BA ghi TRACEABILITY_ID_REGISTRY; khi cần chỉ vị trí artifact, BA ghi /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Không tạo ID Nova Foods mới trong section này.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì metadata và liên kết corpus. Vai trò này không xác nhận requirement nghiệp vụ, legal/compliance, kế toán, bảo mật, baseline hay approval.

Artifact: /02-handbook/02-stakeholders-domain-and-context.md, section 04-inputs.

Consequence if Wrong: Dùng tên tệp không canonical hoặc tự tạo ID làm traceability đứt. Dùng rule chưa xác minh như fact làm learner hiểu sai thẩm quyền và có thể biến giả định học liệu thành yêu cầu ERP.

Senior Lens

Evidence không đồng nghĩa với sự thật vận hành. Evidence chỉ chứng minh artifact nói gì, ở trạng thái nào, do ai duy trì và có giới hạn nào. Cầu nối suy luận là: metadata của CHAPTER_MANIFEST ghi IN_REVIEW; vì IN_REVIEW không phải BASELINED hoặc APPROVED, BA chỉ được mô tả nội dung là đang xem xét. Không được nâng trạng thái bằng cách viết lại trong handbook.

Canonical ID khác filename. ID như CANONICAL_BUSINESS_RULES nhận diện artifact qua phiên bản và cách trình bày. Filename như /01-curriculum/CANONICAL_BUSINESS_RULES.md chỉ vị trí artifact canonical trong corpus. Cần cả hai khi người đọc phải tìm đúng nguồn và kiểm tra liên kết.

Quick Reference

Thuật ngữ	Nghĩa thực hành
Prerequisite knowledge	Kiến thức cần có trước khi phân tích; không giả định người học biết ERP.
Evidence	Bằng chứng có thể kiểm tra, như metadata hoặc nguồn chính thức.
Source artifact	Tệp nguồn được kiểm soát, dùng để lấy phạm vi, trạng thái hoặc định danh.
Canonical ID	Định danh chuẩn phải giữ nguyên ký tự khi tham chiếu.
Traceability	Khả năng lần từ nội dung hiện tại về artifact và bằng chứng nguồn.
Synthetic data	Dữ liệu tổng hợp cho học liệu; không phải dữ liệu doanh nghiệp thật.
Verification required	Nội dung chưa đủ bằng chứng hoặc cần vai trò có thẩm quyền xác minh.

Core

Kiểm tra chất lượng đầu vào là xác định nguồn có đủ tin cậy để BA dùng làm bằng chứng hay chưa. BA không biến dữ liệu chưa kiểm tra thành fact, requirement, business rule hay quyết định ERP. Mỗi đầu vào phải ghi: nguồn, phân loại nguồn, ngày hiệu lực hoặc ngày truy cập, Owner, trạng thái xác minh, và giới hạn sử dụng.

Kiểm tra	Đạt khi	Không đạt khi	Hành động
Định danh	Có Artifact ID hoặc URL canonical nguyên dạng	Dùng tên rút gọn, bản sao không kiểm soát	Không trích làm nguồn chính
Trạng thái	Nêu đúng IN_REVIEW, v0.9.0, ngày 2026-08-07 nếu nguồn thuộc corpus	Diễn giải IN_REVIEW thành approved hoặc baselined	Sửa nhãn; dừng kết luận
Tính mới	Ngày hiệu lực, phiên bản hoặc ngày truy cập còn xác định được	Không biết nguồn còn hiệu lực hay đã thay thế	Gắn Verification required
Thẩm quyền	Issuer hoặc Owner phù hợp loại nội dung	BA tự kết luận pháp lý, kế toán, bảo mật, vận hành	Escalate đúng Owner
Ranh giới	Nội dung dùng đúng phạm vi cho phép	Suy diễn điều khoản, cấu hình ERP, nghĩa vụ pháp lý chưa xác minh	Loại suy diễn khỏi artifact
Truy vết	Có liên kết đến ID/tệp/URL nguồn	Không truy ngược được evidence	Không tạo requirement từ đầu vào này

Phân loại nguồn quyết định mức kết luận. Primary source là nguồn gốc do cơ quan, tổ chức chuẩn hoặc artifact canonical phát hành. Controlled internal artifact là tệp corpus có ID, đường dẫn, trạng thái và Owner rõ. Secondary source chỉ giải thích hoặc dẫn hướng; không thay nguồn gốc. Project assumption là giả định học liệu, không phải fact Nova Foods. Verification required là thông tin có thể cần nhưng chưa đủ evidence hoặc chưa có Owner có thẩm quyền xác nhận.

Applied

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi giá trị dưới đây là dữ liệu tổng hợp.

Mục	Nội dung
Facts	/01-curriculum/TRACEABILITY_ID_REGISTRY.md có Artifact ID TRACEABILITY_ID_REGISTRY, Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07. URL Luật 91/2025/QH15 là nguồn pháp lý chính thức, nhưng diễn giải requirement hệ thống cần Legal Owner xác minh.
Current Behavior	Learner có thể thấy tên luật hoặc tên registry rồi viết ngay rule ERP như fact.
Underlying Need	Phân biệt “có nguồn” với “nguồn đủ thẩm quyền và đủ mới cho kết luận đang viết”.
Options	1. Dùng mọi nguồn như fact. 2. Chỉ dùng nguồn primary/controlled có kiểm tra. 3. Dùng nguồn chưa đủ evidence nhưng gắn Project assumption hoặc Verification required.
Decision Criteria	Giữ traceability; không tạo approval ngầm định; không vượt thẩm quyền Legal, Accounting, Security, Architect hoặc Business Owner; không dùng dữ liệu mô phỏng như dữ liệu vận hành thật.
Decision	Chọn phương án 2 và 3. Chỉ nguồn đạt kiểm tra mới làm evidence. Nguồn chưa đủ điều kiện chỉ nêu nhu cầu xác minh.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì traceability. Legal Owner xác minh diễn giải pháp lý. Accounting Owner xác minh nội dung kế toán. Business Owner xác minh quy tắc vận hành.
Artifact	/00-research/00_SOURCE_MAP.md, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY.
Consequence if Wrong	Rule sai có thể lan sang requirement, acceptance criteria, test basis và cấu hình ERP giả định; người đọc có thể hiểu nhầm học liệu là chỉ dẫn production hoặc nghĩa vụ pháp lý.

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

flowchart TB
    A[Nhận đầu vào] --> B{Có ID canonical, tệp kiểm soát hoặc URL chính thức?}

    B -- Không --> Q{Cách ghi nhận?}
    B -- Có --> D{Biết issuer hoặc Owner<br/>và phạm vi thẩm quyền?}
    D -- Không --> Q
    D -- Có --> E{Loại nguồn?}

    E -- ID canonical --> R{Resolve được artifact<br/>mà ID trỏ tới?}
    R -- Không --> Q
    R -- Có --> F

    E -- Artifact kiểm soát --> F{Version, ngày và Status phù hợp<br/>với kết luận, không tạo phê duyệt ngầm định?}
    F -- Không --> Q
    F -- Có --> J

    E -- URL chính thức --> G{Nguồn còn hiệu lực và có ngày hiệu lực<br/>hoặc ngày truy cập đủ mới?}
    G -- Không --> Q
    G -- Có --> J

    J{Kết luận cần xác minh chuyên môn<br/>hoặc phê duyệt đúng Owner?}
    J -- Không --> I{Là dữ liệu mô phỏng?}
    J -- Có --> H{Loại nội dung cần xác minh?}

    H -- Pháp lý --> L[Legal Owner]
    H -- Kế toán --> AC[Accounting Owner]
    H -- Bảo mật --> SE[Security]
    H -- Kiến trúc --> AR[Architect]
    H -- Vận hành --> BO[Business Owner]

    L --> K{Xác minh được ghi nhận<br/>trong nguồn kiểm soát?}
    AC --> K
    SE --> K
    AR --> K
    BO --> K

    K -- Không --> Q
    K -- Có --> I

    I -- Có --> SIM[Dùng làm evidence có truy vết<br/>chỉ cho học liệu hoặc case study<br/>Không dùng cho vận hành hoặc production]
    I -- Không --> OK[Dùng làm evidence có truy vết]

    Q -- Gắn giả định --> PA[Project assumption<br/>Không dùng làm evidence]
    Q -- Chờ xác minh --> VR[Verification required<br/>Không dùng làm evidence]

Senior Lens

Freshness không nghĩa là nguồn mới nhất theo ngày; nghĩa là nguồn còn phù hợp với quyết định. Ví dụ, ISO/IEC/IEEE 29148:2018 được seed xác nhận có trạng thái “marked to be revised in 2026”. Evidence bridge: trạng thái này cho biết chuẩn có khả năng thay đổi, không cho biết nội dung mới đã có hiệu lực. Vì vậy BA có thể dùng URL chính thức cho mô tả thư mục, nhưng phải gắn Verification required trước khi khẳng định clause cụ thể.

Ownership là trách nhiệm xác minh nội dung, không phải quyền tự động phê duyệt. Owner của CANONICAL_BUSINESS_RULES duy trì ID, version và traceability; Owner này không tự xác nhận rule đúng cho vận hành Nova Foods. Evidence bridge: metadata artifact nêu rõ giới hạn thẩm quyền. Do đó, BA phải tách “quản trị artifact” khỏi “quyết định nghiệp vụ”.

Stop condition kích hoạt khi thiếu một điều kiện tối thiểu làm kết luận không an toàn. Dừng viết rule hoặc requirement khi: nguồn không có định danh/URL canonical; status bị diễn giải sai; evidence mâu thuẫn; nguồn pháp lý bị chuyển thành nghĩa vụ hệ thống chưa có Legal Owner; nội dung kế toán chưa có Accounting Owner; hoặc dữ liệu tổng hợp bị gọi là dữ liệu Nova Foods thật. Dừng không phải bỏ vấn đề; dừng là giữ vấn đề ở nhãn Verification required và bảo toàn traceability.

Quick Reference

Nhãn dùng trong artifact	Khi dùng	Không được suy ra
Primary source	URL chính thức từ issuer có thẩm quyền	Mọi chi tiết đều đã được kiểm tra nếu chỉ đọc overview
Controlled internal artifact	Tệp canonical có ID, path, status, version	Approved, baselined hoặc production-ready
Secondary source	Tài liệu giải thích, đào tạo, tổng hợp	Nguồn chuẩn hoặc căn cứ pháp lý
Project assumption	Giả định cần để mô phỏng Nova Foods tiếp tục	Fact, policy, business rule thật
Verification required	Thiếu freshness, thẩm quyền, evidence hoặc diễn giải	Có thể đưa vào requirement bắt buộc
STOP	Kết luận có nguy cơ sai hoặc vượt thẩm quyền	Vấn đề đã được giải quyết

Core

Bảng dưới là inventory đầu vào cho Nova Foods Trading & Manufacturing, case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Mỗi dòng giữ nguyên Artifact ID, tên tệp và ranh giới nguồn. Verification required nghĩa là thông tin chưa đủ căn cứ để dùng như quy tắc, cấu hình ERP, kết luận pháp lý hoặc quyết định vận hành.

Đầu vào	Artifact ID / nguồn	Tệp hoặc URL canonical	Phân loại nguồn	Giá trị dùng trong case mô phỏng	Trạng thái xác minh
Bối cảnh curriculum	01_CURRICULUM_ARCHITECTURE	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Controlled planning artifact	Locale vi-VN; múi giờ Asia/Ho_Chi_Minh; tiền tệ VND; Nova Foods là case mô phỏng	Đã ghi nhận trong artifact, không phải approval
Danh mục chapter	CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Controlled planning artifact	Chapter hiện hành: /02-handbook/02-stakeholders-domain-and-context.md	Đã ghi nhận trong artifact
Registry định danh	TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Controlled planning artifact	Dùng để giữ ID không đổi giữa handbook, template và QA	Đã ghi nhận; không tạo ID mới ngoài registry
Catalog quy tắc	CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Controlled planning artifact	Nguồn dự kiến cho business rule của ERP mô phỏng	Verification required: nội dung rule cụ thể chưa được xác nhận
Từ điển dữ liệu	CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Controlled planning artifact	Nguồn dự kiến cho tên thực thể, trường dữ liệu, kiểu dữ liệu logic	Verification required: định nghĩa dữ liệu ERP cụ thể chưa được xác nhận
Bản đồ nguồn	00_SOURCE_MAP	/00-research/00_SOURCE_MAP.md	Controlled planning artifact	Phân loại nguồn, ranh giới dùng nguồn, metadata corpus	Đã ghi nhận; không thay thế nguồn gốc
Kiến thức BA	BABOK Guide	https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/	Primary official source	Dùng thuật ngữ BA như stakeholder, requirement, traceability	Chỉ dùng overview và errata; licensed text cần truy cập phù hợp
Chuẩn yêu cầu	ISO/IEC/IEEE 29148	https://www.iso.org/standard/72089.html	Primary official source	Dùng abstract và trạng thái thư mục của chuẩn yêu cầu	Verification required: điều khoản chính xác cần licensed text
Bối cảnh pháp lý dữ liệu cá nhân	Luật 91/2025/QH15	https://vanban.chinhphu.vn/?classid=1&docid=214590&pageid=27160&typegroup=	Primary official legal source	Nhắc nhu cầu có Legal Owner khi ERP xử lý dữ liệu cá nhân mô phỏng	Verification required: áp dụng vào requirement cần Legal Owner
Bối cảnh hóa đơn, chứng từ	Nghị định 123/2020/NĐ-CP	https://vanban.chinhphu.vn/?docid=201365&pageid=27160	Primary official legal source	Gắn rủi ro cho luồng bán hàng và chứng từ mô phỏng	Verification required: sửa đổi hiện hành và diễn giải cần Accounting/Legal Owner
Bối cảnh an toàn thực phẩm	Luật 55/2010/QH12	https://vanban.chinhphu.vn/?docid=96032&pageid=27160	Primary official legal source	Gắn nhu cầu truy xuất lô hàng và thu hồi trong case mô phỏng	Verification required: nghĩa vụ cụ thể cần Domain Owner và Legal Owner
Dữ liệu nghiệp vụ mô phỏng	Nova Foods scenario	Không có nguồn doanh nghiệp thật	Project assumption, synthetic data only	Kho trung tâm mô phỏng tại TP.HCM; sản phẩm mô phỏng: nước ép đóng chai; tiền tệ VND	Verification required: không được diễn giải là dữ liệu Nova Foods thật
Danh sách stakeholder	Chưa có artifact canonical được nêu	Chưa có tệp canonical	Missing controlled input	Cần tên vai trò như Sales, Warehouse, Finance, QA, IT, Legal Owner	Verification required: chưa có danh sách stakeholder được kiểm soát
Quy trình hiện tại	Chưa có artifact canonical được nêu	Chưa có sơ đồ hoặc mô tả canonical	Missing controlled input	Cần luồng nhận đơn, giữ hàng, xuất kho, lập chứng từ, đối soát	Verification required: không suy diễn quy trình thật từ ví dụ học liệu

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

flowchart TB
    A[Controlled planning artifacts] --> D[BA input inventory]
    B[Primary official sources] --> D
    C[Project assumptions: synthetic data only] --> D
    M[Missing controlled input] --> D

    D --> S{Entry status}

    S -->|Recorded| R[Use only for recorded context or traceability]
    R --> N[Not approval evidence]

    S -->|Verification required| E{Evidence type}

    E -->|Canonical business rules or data dictionary| K[Verify canonical artifact content]
    K --> K1{Content verified for stated use?}
    K1 -->|Yes| U[Use only for verified stated purpose]
    K1 -->|No| W[Do not use as ERP rule, configuration, legal conclusion, or operational decision]

    E -->|Licensed BA or standards text| L[Check required licensed source text]
    L --> L1{Required text verified?}
    L1 -->|Yes| U
    L1 -->|No| W

    E -->|Personal-data legal topic| P[Legal Owner reviews applicability and requirements]
    P --> P1{Legal Owner review complete?}
    P1 -->|Yes| U
    P1 -->|No| W

    E -->|Invoice or document legal topic| I[Confirm current amendments]
    I --> I1[Accounting and Legal Owner review interpretation]
    I1 --> I2{Required checks and reviews complete?}
    I2 -->|Yes| U
    I2 -->|No| W

    E -->|Food-safety legal topic| F[Domain Owner and Legal Owner review obligations]
    F --> F1{Required reviews complete?}
    F1 -->|Yes| U
    F1 -->|No| W

    E -->|Nova Foods scenario| X[Confirm synthetic-data boundary]
    X --> Y[Use synthetic scenario data only]
    Y --> Y1[Do not represent as real Nova Foods data]
    Y1 --> Y2{Boundary verified?}
    Y2 -->|Yes| U
    Y2 -->|No| W

    S -->|Missing controlled input| G{Controlled-input gap}

    G -->|Stakeholder list| G1{Canonical stakeholder artifact available?}
    G1 -->|No| G2[Do not infer real stakeholders]
    G1 -->|Yes| D

    G -->|Current process| G3{Canonical current-process artifact available?}
    G3 -->|No| G4[Do not infer real process]
    G3 -->|Yes| D

Applied

Trường	Nova Foods simulated case
Facts	Corpus ở IN_REVIEW, version v0.9.0, ngày 2026-08-07. Có nguồn pháp lý chính thức nhưng chưa có stakeholder register và current-state process canonical.
Current Behavior	Learner có thể thấy “truy xuất lô” và nhầm đó là rule đã xác nhận của ERP.
Underlying Need	Tách bằng chứng nguồn, giả định học liệu và khoảng trống xác minh trước khi mô tả domain.
Options	Dùng mọi thông tin như fact; chỉ dùng artifact kiểm soát; giữ cả nguồn chính thức và gap có nhãn.
Decision Criteria	Không tạo approval ngầm định; không biến nguồn pháp lý thành diễn giải pháp lý; giữ traceability.
Decision	Dùng bảng inventory; mọi dòng thiếu artifact canonical hoặc cần thẩm quyền chuyên môn mang nhãn Verification required.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì traceability; Legal Owner, Accounting Owner, Domain Owner xác minh nội dung thuộc thẩm quyền.
Artifact	/02-handbook/02-stakeholders-domain-and-context.md, section 04-inputs.
Consequence if Wrong	Requirement có thể dựa trên giả định, sai owner, sai phạm vi pháp lý hoặc sai quy trình ERP.

Senior Lens

“Đầy đủ” không nghĩa là mọi ô đã xác minh. Đầy đủ nghĩa là mọi đầu vào cần để hiểu giới hạn hiện tại đều hiện diện, gồm cả khoảng trống. Bằng chứng: registry, catalog và data dictionary tồn tại như planning artifact; nội dung nghiệp vụ cụ thể chưa được cung cấp. Suy luận: BA phải ghi gap thay vì tự điền rule, owner hoặc dữ liệu vận hành.

Quick Reference

Nhãn	Nghĩa dùng trong bảng
Primary official source	Nguồn gốc do tổ chức có thẩm quyền công bố; vẫn phải giữ safe use boundary.
Controlled planning artifact	Tài liệu corpus có quản trị ID, version, status; không phải quyết định vận hành.
Project assumption	Giả định phục vụ học liệu mô phỏng; không phải fact doanh nghiệp.
Missing controlled input	Cần đầu vào nhưng chưa có artifact canonical được cung cấp.
Verification required	Chưa được dùng làm rule, cấu hình, compliance claim hoặc quyết định.

5. Step-by-step BA Activities

Core

Business Analyst (BA, chuyên viên phân tích nghiệp vụ) biến đầu vào rời rạc thành gói hiểu biết có kiểm soát. Mục tiêu không phải tự quyết thay Business Owner, Legal Owner, Accounting Owner, Domain Owner, Security hoặc Architect. Mục tiêu là chỉ rõ ai biết gì, bằng chứng nằm đâu, điểm nào thiếu xác minh, và ai phải quyết định.

1. BA chuẩn bị phạm vi và ranh giới. Actor: Principal IT Business Analyst / Technical Curriculum Author. Action: đọc /01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/CANONICAL_DATA_DICTIONARY.md; lập danh sách stakeholder, domain, artifact và gap cần khảo sát. Object: phạm vi section 05-activities của /02-handbook/02-stakeholders-domain-and-context.md. Evidence produced: working inventory ghi nguồn, status IN_REVIEW, version v0.9.0, ngày 2026-08-07, classification và gap. Decision rule: chỉ dùng ID, filename, status đã có trong nguồn controlled. Quality gate: không có ID mới, không có claim approval, không có rule Nova Foods không có nguồn. Escalation route: xung đột ID hoặc source boundary gửi Principal IT Business Analyst / Technical Curriculum Author.

2. BA phân loại stakeholder theo quyết định và bằng chứng. Actor: BA. Action: gắn từng vai trò vào quyết định họ sở hữu, thông tin họ cung cấp, thông tin họ tiêu thụ và giới hạn thẩm quyền. Object: stakeholder map. Evidence produced: bảng vai trò–trách nhiệm–thẩm quyền–đầu vào–đầu ra. Decision rule: người cung cấp thông tin không tự thành người phê duyệt; owner artifact không tự thành business authority. Quality gate: mỗi kết luận có owner xác minh hoặc nhãn Verification required. Escalation route: điểm giao Legal, Accounting, Security, Architecture hoặc Domain Owner được chuyển đúng owner chuyên môn.

3. BA khảo sát current state. Actor: BA cùng Domain Owner. Action: mô tả hành vi hiện tại từ evidence được cung cấp; tách fact, project assumption và missing controlled input. Object: luồng nghiệp vụ, dữ liệu logic, quy tắc, integration và điểm quyết định. Evidence produced: current-state notes có liên kết artifact nguồn. Decision rule: không suy diễn cấu hình ERP, compliance hoặc quy trình vận hành thực từ case mô phỏng. Quality gate: mọi câu khẳng định có evidence bridge; khoảng trống được ghi rõ. Escalation route: dữ liệu liên quan pháp lý, kế toán, thuế, an toàn thực phẩm hoặc dữ liệu cá nhân chuyển owner có thẩm quyền xác minh.

4. BA phân tích nhu cầu nền. Actor: BA. Action: hỏi “vì sao hành vi hiện tại tồn tại” và nối fact với mục tiêu, rủi ro hoặc constraint. Object: observed behavior và stakeholder concern. Evidence produced: need statement phân biệt underlying need (nhu cầu nền) với option (phương án). Decision rule: chỉ ghi need khi fact hỗ trợ; nếu thiếu fact, ghi project assumption hoặc Verification required. Quality gate: need không chứa sẵn giải pháp, vendor, màn hình hoặc cấu hình. Escalation route: nhu cầu làm đổi phạm vi, authority hoặc risk appetite chuyển Business Owner.

5. BA so sánh phương án và chuẩn bị quyết định. Actor: BA; Business Owner quyết định trong thẩm quyền của họ. Action: lập options, tiêu chí và hệ quả. Object: need statement, constraint, evidence và risk. Evidence produced: decision record draft. Decision rule: không chọn phương án chỉ vì BA ưa thích; chọn phương án đáp ứng tiêu chí đã nêu hoặc ghi unresolved. Quality gate: tiêu chí gồm traceability, authority, khả năng kiểm thử và source boundary. Escalation route: phương án ảnh hưởng architecture chuyển Architect; ảnh hưởng security chuyển Security; ảnh hưởng legal hoặc accounting chuyển owner tương ứng.

6. BA review và handoff có kiểm soát. Actor: BA chủ trì review; stakeholder xác nhận phần thuộc thẩm quyền của họ. Action: kiểm tra completeness, contradiction, source classification, nhãn xác minh và consumer của output; phát hành liên kết tới artifact kiểm soát. Object: stakeholder/domain/context package. Evidence produced: review log, issue list và handoff record. Decision rule: IN_REVIEW không được gọi là approved hoặc baselined. Quality gate: không còn claim không có evidence; issue chưa giải quyết có owner và escalation route. Escalation route: review phát hiện quyết định vượt thẩm quyền thì dừng handoff phần đó và chuyển đúng authority.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ dữ liệu dưới đây là dữ liệu tổng hợp. BA khảo sát nhu cầu liên quan truy vết lô hàng trong ERP, không xác nhận quy trình Nova Foods thực, không diễn giải pháp lý và không tạo rule production.

Mục	Nội dung thực thi
Facts	/01-curriculum/CANONICAL_DATA_DICTIONARY.md và /01-curriculum/CANONICAL_BUSINESS_RULES.md là controlled planning artifact, status IN_REVIEW, version v0.9.0. Nội dung chi tiết về lô hàng, rule truy vết và quy trình vận hành không được cung cấp trong source seed.
Current Behavior	Chỉ xác định được rằng corpus có kế hoạch catalog rule và data dictionary logic. Không có bằng chứng cho màn hình ERP, integration, cấu trúc mã lô hoặc quy trình recall.
Underlying Need	Cần làm rõ stakeholder nào sở hữu quyết định về dữ liệu lô, quy tắc nghiệp vụ, diễn giải an toàn thực phẩm và kiến trúc integration trước khi viết requirement. Lý do: thiếu owner hoặc evidence làm requirement không kiểm thử được và có thể vượt thẩm quyền.
Options	Option 1: BA tự giả định quy trình truy vết. Option 2: BA lập gap register, map authority và chờ xác minh chuyên môn.
Decision Criteria	Giữ source boundary; không tạo legal/compliance claim; giữ traceability; không biến case mô phỏng thành cấu hình ERP thực.
Decision	Chọn Option 2. Ghi mọi chi tiết chưa có nguồn là Verification required; không tạo business rule hoặc data field mới.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì artifact và traceability. Domain Owner xác minh nghiệp vụ; Legal Owner xác minh diễn giải pháp lý; Architect xác minh integration; Security xác minh kiểm soát bảo vệ dữ liệu.
Artifact	Cập nhật nội dung section 05-activities trong /02-handbook/02-stakeholders-domain-and-context.md; tham chiếu canonical giữ nguyên /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
Consequence if Wrong	BA có thể gán sai owner, ghi rule không có bằng chứng, tạo compliance claim sai, hoặc handoff requirement không thể review và kiểm thử.

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

flowchart TB
    A["BA đọc controlled planning artifacts<br/>status IN_REVIEW, version v0.9.0"] --> B["BA lập stakeholder inventory,<br/>evidence inventory và gap register"]

    B --> V["Evidence chưa có<br/>màn hình ERP<br/>integration<br/>cấu trúc mã lô<br/>quy trình recall"]
    V --> C{Có evidence và authority phù hợp?}

    C -- Có --> D["Ghi fact, current behavior<br/>và underlying need"]
    C -- Không --> E["Gắn Verification required<br/>không tạo business rule hoặc data field mới"]

    D --> P["Áp dụng decision criteria<br/>giữ source boundary và traceability<br/>không tạo legal/compliance claim<br/>không biến case thành cấu hình ERP thực"]
    E --> P

    P --> F{Chọn phương án}
    F -- "Option 1: BA tự giả định" --> R["Loại Option 1<br/>không đạt decision criteria"]
    R --> RC["Rủi ro nếu dùng<br/>sai owner, rule không có evidence,<br/>compliance claim sai hoặc requirement<br/>không thể review và kiểm thử"]

    F -- "Option 2" --> O["Lập gap register, map authority<br/>và chờ xác minh chuyên môn"]
    O --> Q["Phân loại từng gap<br/>nghiệp vụ, pháp lý, integration<br/>hoặc bảo vệ dữ liệu"]

    Q --> G{Owner phù hợp với gap?}
    G -- Nghiệp vụ --> H1[Domain Owner xác minh nghiệp vụ]
    G -- Pháp lý --> H2[Legal Owner xác minh diễn giải pháp lý]
    G -- Integration --> H3[Architect xác minh integration]
    G -- "Bảo vệ dữ liệu" --> H4[Security xác minh kiểm soát bảo vệ dữ liệu]

    H1 --> J["BA chờ review từ mọi owner<br/>đã được chỉ định"]
    H2 --> J
    H3 --> J
    H4 --> J

    J --> T["Principal IT Business Analyst / Technical Curriculum Author<br/>duy trì artifact và traceability"]
    T --> K{"Đúng authority, đủ traceability<br/>và không vượt source boundary?"}

    K -- Không --> X["Sửa gap, gắn Verification required<br/>và chỉ định lại owner phù hợp"]
    X --> Q

    K -- Có --> L["Cập nhật section 05-activities<br/>trong /02-handbook/02-stakeholders-domain-and-context.md"]
    L --> M["Giữ tham chiếu canonical<br/>TRACEABILITY_ID_REGISTRY.md<br/>CANONICAL_BUSINESS_RULES.md<br/>CANONICAL_DATA_DICTIONARY.md"]
    M --> N["Controlled handoff<br/>status IN_REVIEW, version v0.9.0"]

Senior Lens

Không có bằng chứng không phải lỗi để che. Nó là kết quả phân tích. Fact là điều artifact nguồn thể hiện. Inference là kết luận nối từ fact tới need. Assumption là điều dùng tạm cho học liệu. BA ghi ba loại riêng để reviewer biết phần nào kiểm tra được ngay, phần nào cần authority xác minh.

Quick Reference

Kiểm tra trước handoff	Đạt khi
Nguồn	Mỗi fact có artifact hoặc official source đã nêu.
Thẩm quyền	Mỗi quyết định có đúng owner; BA không tự phê duyệt.
Gap	Nội dung thiếu được gắn Verification required.
Trạng thái	IN_REVIEW được giữ nguyên; không gọi approved hoặc baselined.
Traceability	ID và filename canonical được giữ nguyên.

Core

Mỗi hoạt động BA phải tạo được bằng chứng để người khác kiểm tra. Không ghi “họp với nghiệp vụ” vì không biết ai làm, kiểm tra gì, dừng khi nào. Dùng bảy trường: actor là vai trò chịu trách nhiệm; action là việc làm; object là đối tượng xử lý; evidence produced là bằng chứng đầu ra; decision rule là điều kiện chọn hướng; quality gate là cổng kiểm tra trước bước sau; escalation route là nơi chuyển vấn đề vượt thẩm quyền.

Bước	Actor	Action	Object	Evidence produced	Decision rule	Quality gate	Escalation route
1. Chuẩn bị	BA	Lập phạm vi trao đổi và danh sách vai trò cần xác nhận	Mục tiêu khảo sát, stakeholder, artifact upstream	Agenda, stakeholder list, câu hỏi có ID nội bộ của phiên làm việc	Chỉ đưa vấn đề thuộc phạm vi stakeholder, domain hoặc context	Nêu rõ dữ liệu Nova Foods là mô phỏng, tổng hợp; không có giả định bị ghi như fact	Principal IT Business Analyst / Technical Curriculum Author khi source boundary hoặc ID mâu thuẫn
2. Thu thập fact	BA, Domain Owner	Ghi nhận sự kiện quan sát được, nguồn và người cung cấp	Quy trình hiện tại, dữ liệu, điểm đau	Fact log có nguồn, ngày 2026-08-07, phân loại fact hoặc assumption	Fact phải có nguồn xác định; thiếu nguồn chuyển thành project assumption	Không dùng lời kể đơn lẻ làm business rule	Domain Owner khi hành vi nghiệp vụ chưa rõ; Legal, Accounting, Security Owner nếu nội dung chạm thẩm quyền chuyên môn
3. Phân tích nhu cầu	BA	Tách current behavior khỏi underlying need	Fact log, mục tiêu nghiệp vụ	Need statement liên kết từng fact	Nhu cầu mô tả kết quả cần đạt, không khóa sớm giải pháp ERP	Mỗi suy luận có cầu nối: fact nào dẫn đến need nào	Business Owner khi ưu tiên hoặc mục tiêu xung đột
4. So sánh lựa chọn	BA, Architect, Domain Owner	Ghi option và tác động từng option	Need statement, ràng buộc dữ liệu và vận hành	Option comparison	Không chọn option khi chi phí, rủi ro, quyền dữ liệu hoặc khả năng tích hợp chưa được nêu	Có ít nhất một tiêu chí đo được cho mỗi option; không gọi option là quyết định	Architect cho kiến trúc hoặc integration; Security Owner cho quyền truy cập và dữ liệu
5. Ghi quyết định có kiểm soát	Decision Authority	Chọn, từ chối hoặc yêu cầu làm rõ option	Option comparison, decision criteria	Decision record nêu authority và trạng thái	Chỉ authority đúng vai trò mới quyết định; IN_REVIEW không là approval	Decision record không dùng từ “đã phê duyệt” nếu không có approval reference	Principal IT Business Analyst / Technical Curriculum Author khi authority chưa xác định
6. Review và handoff	BA, người nhận artifact	Kiểm tra liên kết nguồn, giả định, decision và người nhận	Fact log, need statement, decision record	Review log, handoff record	Chỉ handoff khi người nhận, mục đích dùng và giới hạn sử dụng rõ	Không có broken traceability; không biến nội dung học liệu thành chỉ dẫn production	QA reviewer cho lỗi completeness; đúng owner chuyên môn cho nội dung vượt thẩm quyền

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp, vi-VN, Asia/Ho_Chi_Minh, VND.

Trường	Ghi nhận thực thi
Facts	Domain Owner mô tả đơn hàng bán có thể bị sửa mã khách sau khi kho đã chuẩn bị hàng. Fact log ghi nguồn là phiên khảo sát mô phỏng ngày 2026-08-07; chưa có bằng chứng cấu hình ERP hay quy định vận hành thực tế.
Current Behavior	Nhân viên bán hàng gửi yêu cầu sửa qua trao đổi nội bộ; kho có thể tiếp tục dùng thông tin cũ. Đây là hành vi được mô tả, không phải business rule.
Underlying Need	Cần tránh chênh lệch giữa khách hàng trên đơn hàng và khách hàng trên chứng từ giao hàng. Suy luận dựa trên fact: một đối tượng đơn hàng có thể bị thay đổi sau khi kho dùng dữ liệu đó.
Options	Option 1: cho sửa trực tiếp mọi thời điểm. Option 2: chặn sửa sau khi kho bắt đầu chuẩn bị. Option 3: cho sửa nhưng tạo yêu cầu xử lý lại cho kho.
Decision Criteria	Giảm giao sai; giữ khả năng phục vụ thay đổi hợp lệ; xác định rõ ảnh hưởng tới kho; không tự suy diễn nghĩa vụ hóa đơn, kế toán hay pháp lý.
Decision	Chưa có quyết định. BA ghi IN_REVIEW vì chưa có Business Owner xác nhận ưu tiên giữa tốc độ sửa và kiểm soát giao hàng.
Authority	Business Owner quyết định ưu tiên nghiệp vụ; Domain Owner xác nhận hành vi kho; Architect đánh giá khả năng trạng thái và thông báo; Accounting Owner xác nhận ảnh hưởng chứng từ nếu phát sinh.
Artifact	Fact log, need statement, option comparison, decision record thuộc /02-handbook/02-stakeholders-domain-and-context.md; không tạo baseline hoặc approval.
Consequence if Wrong	Nếu gọi mô tả là rule, đội triển khai có thể chặn sửa đơn hàng không cần thiết hoặc cho phép giao theo khách cũ; cả hai gây sai lệch vận hành mô phỏng.

Senior Lens

Escalation không phải đẩy việc. BA escalation khi bằng chứng không đủ để suy luận an toàn, hai source mâu thuẫn, hoặc quyết định chạm legal, accounting, security, architecture hay production authority. Gói escalation phải chứa object đang tranh luận, fact log, assumption, option, tác động và câu hỏi quyết định; BA không tự thay kết luận chuyên môn.

Quick Reference

Kiểm tra trước chuyển bước	Đạt khi
Actor rõ	Có vai trò, không chỉ có tên cá nhân
Evidence rõ	Người review tìm được artifact và nguồn
Decision rule rõ	Biết điều kiện chọn, chặn hoặc làm rõ
Quality gate rõ	Có tiêu chí pass/fail trước bước sau
Escalation rõ	Có đúng owner khi vượt thẩm quyền

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Bảng dưới diễn tả một lượt thực thi xác định stakeholder cho luồng ERP “ghi nhận lô thành phẩm nhập kho”. BA không suy ra quy tắc pháp lý hay cấu hình production; mọi điểm liên quan truy xuất thực phẩm phải được Domain Owner và Legal Owner xác minh.

Thành phần	Thực thi Nova Foods mô phỏng	Cầu nối bằng chứng và suy luận
Facts	Xưởng hoàn tất lô FG-SN-260807-01; Kho cần biết mã hàng, số lượng, lô và vị trí; QA cần trạng thái kiểm tra trước khi hàng sẵn sàng xuất bán.	Phiếu ghi nhận xưởng, danh sách vai trò kho và QA là bằng chứng đầu vào tổng hợp. Vì ba nhóm tạo hoặc dùng dữ liệu khác nhau, cả ba là stakeholder trực tiếp.
Current Behavior	Nhân viên xưởng gửi bảng tính qua email; thủ kho nhập lại số lượng; QA báo kết quả kiểm tra riêng. Cùng một mã lô có thể bị gõ khác nhau.	Ba bản ghi tách rời tạo nguy cơ lệch dữ liệu. Đây là quan sát quy trình mô phỏng, không phải kết luận về Nova Foods thực tế.
Underlying Need	Một bản ghi lô dùng chung, có trạng thái kiểm tra rõ, truy được người tạo và người cập nhật.	Nhu cầu xuất phát từ lỗi nhập lại và phụ thuộc giữa xưởng, kho, QA; không tự biến thành yêu cầu pháp lý.
Options	1. Giữ bảng tính và đối chiếu thủ công. 2. ERP tạo phiếu nhập kho chờ QA. 3. ERP tự động cho phép xuất bán ngay khi xưởng ghi nhận.	Phương án 1 không loại bỏ nhập lại. Phương án 3 bỏ qua điểm kiểm soát QA. Phương án 2 giữ dữ liệu chung và trạng thái kiểm soát.
Decision Criteria	Không nhập lại mã lô; Kho chỉ nhận số lượng đã đối chiếu; QA kiểm soát trạng thái; có dấu vết thay đổi; không tự khẳng định nghĩa vụ tuân thủ.	Tiêu chí liên kết trực tiếp với Facts và Underlying Need. Tiêu chí pháp lý hoặc an toàn thực phẩm cần nguồn chính thức cùng xác minh chuyên môn.
Decision	Chọn phương án 2 cho phạm vi mô phỏng: xưởng tạo phiếu nhập lô, Kho xác nhận số lượng, QA đổi trạng thái sau kiểm tra.	Phương án 2 thỏa toàn bộ tiêu chí mô phỏng. Quyết định là đề xuất phân tích, trạng thái IN_REVIEW, không phải baseline hay approval.
Authority	Business Owner quyết định ưu tiên nghiệp vụ; Warehouse Manager xác nhận vận hành kho; QA Manager xác nhận điểm kiểm tra; Legal Owner xác minh diễn giải pháp lý; Architect xác nhận khả thi ERP.	BA tổng hợp bằng chứng và giữ truy vết, không thay quyền các vai trò này.
Artifact	Stakeholder map, context diagram, decision log và traceability entry liên kết /01-curriculum/TRACEABILITY_ID_REGISTRY.md, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY.	Các artifact canonical đang IN_REVIEW, v0.9.0, ngày 2026-08-07; liên kết không tạo baseline hoặc approval.
Consequence if Wrong	Bỏ sót QA có thể cho phép hàng chưa kiểm tra được gắn trạng thái sẵn sàng. Bỏ sót Kho có thể tạo quy trình không khả thi tại điểm nhận hàng. Gán Legal Owner quyền quyết định vận hành có thể sai thẩm quyền.	Hệ quả suy ra từ dữ liệu mỗi vai trò tạo, kiểm soát hoặc sử dụng. Escalate khi có xung đột thẩm quyền hoặc yêu cầu diễn giải luật.

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

flowchart TB
    X[Nhân viên xưởng<br/>Ghi nhận lô thành phẩm] --> E[ERP<br/>Phiếu nhập lô: Chờ xác nhận kho]
    E --> K[Thủ kho<br/>Đối chiếu số lượng và vị trí]
    K --> Q[QA<br/>Ghi kết quả kiểm tra]
    Q -->|Đạt theo quy tắc đã xác minh| R[ERP<br/>Trạng thái: Sẵn sàng]
    Q -->|Không đạt hoặc thiếu bằng chứng| H[ERP<br/>Trạng thái: Giữ kiểm tra]
    H --> D[Business Owner, QA Manager, Warehouse Manager<br/>Làm rõ quyết định]
    D --> Q

Sơ đồ là Mermaid flowchart, không phải BPMN. Nó mô tả luồng thông tin và trạng thái mô phỏng để kiểm tra đủ stakeholder: xưởng tạo dữ liệu, kho xác nhận thực nhận, QA kiểm soát chất lượng, Business Owner xử lý điểm quyết định nghiệp vụ.

6. Output thu ???c

Core

Output là artifact được tạo mới hoặc cập nhật sau khi BA xác định stakeholder, phạm vi domain và bối cảnh. Artifact biến thông tin rời rạc thành nội dung có định danh, Owner, trạng thái và lịch sử thay đổi để người review truy được nguồn. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Artifact tạo hoặc cập nhật	Canonical ID / tệp canonical	Owner quản trị	Status	Nội dung tối thiểu	Nghĩa vụ lịch sử thay đổi
Stakeholder map	STAKEHOLDER_MAP / /02-handbook/02-stakeholders-domain-and-context.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Vai trò, nhóm stakeholder, lợi ích, ảnh hưởng, quyền quyết định, ranh giới thẩm quyền, kênh liên hệ mô phỏng	Ghi version, ngày 2026-08-07, người ghi nhận, nội dung đổi, lý do, artifact bị ảnh hưởng
Context diagram	CONTEXT_DIAGRAM / /02-handbook/02-stakeholders-domain-and-context.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Ranh giới ERP, actor ngoài hệ thống, luồng dữ liệu mức ngữ cảnh, giả định, điểm cần xác minh	Không sửa đè luồng cũ; ghi thay đổi actor, interface, dữ liệu hoặc ranh giới
Decision log	DECISION_LOG / /02-handbook/02-stakeholders-domain-and-context.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Vấn đề, lựa chọn, tiêu chí, quyết định đang ghi nhận, Authority cần xác nhận, bằng chứng, hệ quả	Mỗi thay đổi quyết định phải giữ quyết định trước, lý do đổi và Authority liên quan
Traceability entry	TRACEABILITY_ID_REGISTRY / /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Liên kết stakeholder, context, rule, data và artifact nguồn	Ghi ID liên kết thêm, sửa, bỏ; không tái sử dụng ID đã ghi nhận
Business-rule reference	CANONICAL_BUSINESS_RULES / /01-curriculum/CANONICAL_BUSINESS_RULES.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	ID rule, nguồn, trạng thái xác minh, Owner nghiệp vụ cần xác nhận	Ghi nguồn thay đổi, mức xác minh và tác động tới stakeholder hoặc quy trình
Data-reference entry	CANONICAL_DATA_DICTIONARY / /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Tên dữ liệu, nghĩa nghiệp vụ, nguồn tạo, nơi dùng, Owner dữ liệu	Ghi thay đổi nghĩa, nguồn, owner hoặc phân loại dữ liệu

IN_REVIEW nghĩa là đang được xem xét có kiểm soát. Nó không nghĩa APPROVED, BASELINED, tuân thủ pháp lý, sẵn sàng production hoặc đã được người dùng chấp thuận. Owner quản trị giữ định danh và truy vết; Owner không thay Business Owner, QA Manager, Legal Owner, Accounting Owner, Security hoặc Architect xác nhận nội dung thuộc thẩm quyền họ.

Applied

Thành phần	Nova Foods mô phỏng, dữ liệu tổng hợp
Facts	Xưởng ghi nhận lô thành phẩm; Kho đối chiếu số lượng; QA ghi kết quả kiểm tra. Ba vai trò tạo dữ liệu khác nhau.
Current Behavior	Thông tin vai trò và luồng phiếu nhập lô nằm trong trao đổi rời rạc. Không có một điểm liên kết canonical.
Underlying Need	Cần xác định ai tạo, kiểm tra và dùng dữ liệu lô để BA không gán nhầm quyền quyết định. Nhu cầu suy ra từ việc mỗi vai trò kiểm soát một phần bằng chứng khác nhau.
Options	Ghi một bảng vai trò không ID; tạo stakeholder map và context diagram có ID; ghi trực tiếp thành quy tắc ERP.
Decision Criteria	Truy được nguồn; giữ ranh giới thẩm quyền; không biến giả định mô phỏng thành rule vận hành; liên kết được registry canonical.
Decision	Tạo STAKEHOLDER_MAP, CONTEXT_DIAGRAM, DECISION_LOG; cập nhật liên kết trong TRACEABILITY_ID_REGISTRY.
Authority	Warehouse Manager xác nhận thực tế kho; QA Manager xác nhận điểm kiểm tra; Business Owner xác nhận nhu cầu nghiệp vụ; Architect xác nhận khả thi ERP. BA chỉ tổng hợp và truy vết.
Artifact	/02-handbook/02-stakeholders-domain-and-context.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md; tham chiếu CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY.
Consequence if Wrong	Gán QA quyền xác nhận số lượng kho có thể làm sai trách nhiệm. Gán BA quyền diễn giải pháp lý có thể vượt thẩm quyền. Mất ID liên kết làm reviewer không truy được nguồn quyết định.

Senior Lens

Canonical ID là chuỗi nhận diện ổn định, không phải tên gọi thuận miệng. Ví dụ TRACEABILITY_ID_REGISTRY phải giữ nguyên đúng chuỗi khi liên kết. Lý do: tên hiển thị có thể dịch hoặc đổi, còn ID giữ được đường truy vết giữa artifact.

Lịch sử thay đổi phải ghi tối thiểu: version, ngày theo Asia/Ho_Chi_Minh, người ghi nhận, phần đổi, lý do, nguồn hoặc evidence, artifact ảnh hưởng và Authority cần review. Không ghi “cập nhật nội dung” vì reviewer không biết thay đổi nào tác động quyết định nào.

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

flowchart TB
    S[Stakeholder và bằng chứng mô phỏng]
    M[STAKEHOLDER_MAP]
    C[CONTEXT_DIAGRAM]
    T[TRACEABILITY_ID_REGISTRY]
    R[CANONICAL_BUSINESS_RULES]
    D[CANONICAL_DATA_DICTIONARY]
    L[DECISION_LOG]
    N["Liên kết chỉ phục vụ truy vết và tham chiếu<br/>Không tạo baseline hoặc approval"]

    S -->|đầu vào cho| M
    S -->|đầu vào cho| C
    M -->|đăng ký ID truy vết| T
    C -->|đăng ký ID truy vết| T
    T -->|tham chiếu rule canonical| R
    T -->|tham chiếu định nghĩa dữ liệu canonical| D
    M -->|ghi quyết định liên quan| L
    C -->|ghi quyết định liên quan| L
    T --- N

Sơ đồ là Mermaid flowchart, không phải BPMN. Nó cho thấy artifact nguồn được liên kết tới registry và catalog canonical; liên kết không tạo baseline hay approval.

Quick Reference

Quy tắc	Áp dụng
Giữ ID và filename canonical	Dùng đúng TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và đường dẫn đã đăng ký.
Ghi Owner quản trị và Authority nội dung riêng	Owner quản trị artifact không tự xác nhận nghiệp vụ, pháp lý, kế toán, bảo mật hay kiến trúc.
Giữ IN_REVIEW	Không đổi trạng thái chỉ vì artifact đã được viết hoặc gửi review.
Ghi change history cho mọi sửa đổi có nghĩa	Không sửa im lặng ID, nguồn, vai trò, ranh giới hoặc quyết định.
Giữ ranh giới nguồn	Chi tiết pháp lý, kế toán, an toàn thực phẩm và compliance chưa xác minh phải ghi Verification required hoặc giả định dự án.

Core

Output anatomy là cấu trúc tối thiểu để người đọc hiểu cùng một kết quả BA, truy ngược được căn cứ và không tự điền khoảng trống bằng giả định. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu đều tổng hợp; VND, vi-VN, Asia/Ho_Chi_Minh chỉ là bối cảnh học liệu.

Thành phần anatomy	Nội dung phải ghi	Lý do
Mục tiêu	Quyết định hoặc câu hỏi mà output làm rõ	Ngăn tài liệu thành danh sách thông tin không dùng được
Phạm vi	Quy trình, đơn vị, dữ liệu và thời điểm được xét	Phân biệt điều quan sát với điều chưa quan sát
Căn cứ	Fact, nguồn và phân loại nguồn: primary, assumption, Verification required	Tách bằng chứng khỏi suy luận
Stakeholder	Vai trò, lợi ích, quyền quyết định, điểm đau	Cho biết ai bị ảnh hưởng và ai có thẩm quyền
Hiện trạng	Hành vi đang xảy ra, kích hoạt, dữ liệu vào và kết quả	Tạo baseline phân tích, không phải baseline quản trị
Nhu cầu gốc	Kết quả nghiệp vụ cần đạt, không ép sẵn giải pháp	Giữ lựa chọn thiết kế mở
Lựa chọn	Các phương án khả thi cùng giới hạn	Cho phép so sánh minh bạch
Tiêu chí quyết định	Điều kiện đo hoặc kiểm tra phương án	Biến ý kiến thành đánh giá có căn cứ
Quyết định đề xuất	Phương án được đề xuất và lý do	Cho downstream biết điểm cần review
Thẩm quyền	Vai trò cần xác nhận từng loại quyết định	BA không thay Business Owner, Accounting Owner, Legal Owner hay Architect
Hệ quả sai	Rủi ro nếu hiểu hoặc thực hiện sai	Làm rõ mức ưu tiên review
Liên kết	ID canonical đã có, tệp nguồn canonical, phạm vi liên kết	Giữ traceability, không tạo nguồn chân lý thứ hai

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

flowchart TB
    G[Mục tiêu] -. chi phối .-> F
    G -. chi phối .-> C
    G -. chi phối .-> N
    G -. chi phối .-> O
    G -. chi phối .-> K
    G -. chi phối .-> P
    G -. chi phối .-> X
    G -. chi phối .-> D
    G -. chi phối .-> L

    S[Phạm vi] -. giới hạn .-> F
    S -. giới hạn .-> C
    S -. giới hạn .-> N
    S -. giới hạn .-> O
    S -. giới hạn .-> K
    S -. giới hạn .-> P
    S -. giới hạn .-> X
    S -. giới hạn .-> D
    S -. giới hạn .-> L

    F[Căn cứ<br/>fact · nguồn · primary · assumption · Verification required] --> C[Hiện trạng<br/>kích hoạt · dữ liệu vào · kết quả]
    C --> N[Nhu cầu gốc<br/>kết quả nghiệp vụ cần đạt]
    N --> O[Các lựa chọn<br/>phương án khả thi · giới hạn]
    O --> K[Tiêu chí quyết định<br/>điều kiện đo hoặc kiểm tra]
    K --> P[Quyết định đề xuất<br/>phương án · lý do]

    H[Stakeholder<br/>lợi ích · quyền quyết định · điểm đau] -. review .-> P
    H -. quyền quyết định .-> A
    Q[Hệ quả sai<br/>rủi ro khi hiểu hoặc thực hiện sai · ưu tiên review] -. ưu tiên review .-> X
    P --> X[Xác nhận bởi owner phù hợp loại quyết định]
    A[Thẩm quyền<br/>Business Owner · Accounting Owner · Legal Owner · Architect] -. căn cứ chọn owner .-> X
    X --> D[Quyết định đã xác nhận]
    D --> L[Liên kết<br/>ID canonical · tệp nguồn canonical · phạm vi liên kết]

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi tên, số lượng và giá trị dưới đây là dữ liệu tổng hợp.

Trường	Nova Foods micro-example
Facts	Kho mô phỏng WH-HCM-01 nhận 120 thùng nguyên liệu RM-COCOA-01 cho lệnh mua mô phỏng PO-SIM-260807-01. Nhân viên kho ghi ngày hết hạn trên bảng tính cục bộ; bộ phận Kế hoạch không xem được dữ liệu này trong cùng ngày.
Current Behavior	Khi lập kế hoạch xuất nguyên liệu, Kế hoạch hỏi Kho qua tin nhắn nội bộ. Kho trả lời số lượng còn lại, nhưng không có một danh sách dùng chung thể hiện lô, ngày nhận và ngày hết hạn.
Underlying Need	Kế hoạch cần thấy tồn kho theo lô và ngày hết hạn để ưu tiên lô phù hợp khi đề xuất xuất kho. Nhu cầu này xuất phát từ fact: dữ liệu hết hạn đang nằm ngoài luồng dùng chung.
Options	1. Giữ bảng tính và gửi thủ công mỗi ngày. 2. Ghi lô và ngày hết hạn trong ERP mô phỏng, cho Kế hoạch xem tồn theo lô. 3. Chỉ ghi tổng tồn trong ERP, giữ ngày hết hạn ở bảng tính.
Decision Criteria	Có dữ liệu lô và ngày hết hạn tại điểm nhận hàng; Kế hoạch xem được không cần hỏi thủ công; không suy diễn nghĩa vụ pháp lý hoặc cấu hình production; quyền sửa dữ liệu giới hạn cho vai trò Kho.
Decision	Đề xuất Option 2 cho phạm vi mô phỏng: nhận hàng ghi Mã lô, Ngày nhận, Ngày hết hạn, Số lượng; Kế hoạch chỉ xem danh sách tồn theo lô. Option 2 đáp ứng toàn bộ tiêu chí. Option 1 và 3 vẫn phụ thuộc trao đổi thủ công hoặc tách nguồn dữ liệu.
Authority	Business Owner xác nhận ưu tiên nghiệp vụ; Warehouse Manager xác nhận hành vi kho; Solution Architect xác nhận khả năng ERP; Security Owner xác nhận quyền xem và sửa; Legal hoặc Food Safety Owner xác minh yêu cầu pháp lý nếu dự án diễn giải truy xuất nguồn gốc thành nghĩa vụ.
Artifact	Phân tích được liên kết tới /01-curriculum/CANONICAL_DATA_DICTIONARY.md cho định nghĩa dữ liệu, /01-curriculum/CANONICAL_BUSINESS_RULES.md cho quy tắc và /01-curriculum/TRACEABILITY_ID_REGISTRY.md cho ID canonical. Không tạo mã canonical mới trong ví dụ này.
Consequence if Wrong	Nếu Kế hoạch chọn lô không phù hợp do thiếu ngày hết hạn, dữ liệu mô phỏng có thể dẫn đến đề xuất xuất kho sai. Nếu nhầm ví dụ học liệu thành yêu cầu pháp lý, nhóm có thể giao sai thẩm quyền cho BA.

Senior Lens

Không biến “cần theo dõi hạn dùng” thành rule hoặc nghĩa vụ tuân thủ khi chưa có nguồn và chủ thể có thẩm quyền xác minh. Fact chỉ chứng minh dữ liệu đang phân tán; suy luận hợp lệ là cần một nguồn dùng chung cho quyết định kế hoạch. Suy luận này chưa chứng minh ERP phải dùng trường, màn hình hay workflow cụ thể.

Quick Reference

Kiểm tra anatomy	Đạt khi
Fact và inference tách riêng	Mỗi quyết định có fact dẫn đến lý do rõ
Nhu cầu không đóng khung giải pháp	Có thể nêu từ hai lựa chọn khả thi
Thẩm quyền rõ	BA chỉ đề xuất và duy trì traceability
Liên kết canonical	Dùng đúng CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES, TRACEABILITY_ID_REGISTRY
Ranh giới mô phỏng rõ	Không diễn giải ví dụ Nova Foods thành cấu hình, tuân thủ hay quyết định vận hành thực tế

Core

Quality gate là cổng kiểm tra chất lượng trước khi output đi vào downstream review, tức xem xét bởi vai trò nhận artifact ở bước sau. Gate không phải phê duyệt, baseline, xác nhận tuân thủ, sẵn sàng production, hay chấp thuận người dùng. Bằng chứng: toàn corpus đang IN_REVIEW, v0.9.0, ngày 2026-08-07; manifest quy định các trạng thái này không tạo approval ngầm định.

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

stateDiagram-v2
    direction TB

    [*] --> Draft
    Draft --> Gate_Check: Gửi kiểm tra quality gate
    Rework --> Draft: Sửa và ghi lịch sử thay đổi

    state Gate_Check <<choice>>
    Gate_Check --> Rework: Thiếu ít nhất một điều kiện
    Gate_Check --> Ready_for_Downstream_Review: Đạt toàn bộ điều kiện

    note right of Gate_Check
        Sáu nhóm điều kiện:
        - Định danh và vị trí canonical
        - Liên kết nguồn
        - Không vượt thẩm quyền
        - Nội dung nhất quán
        - Lịch sử thay đổi
        - Không có dữ liệu thật
    end note

    Ready_for_Downstream_Review --> Downstream_Review: Chỉ cho phép downstream review
    Downstream_Review --> Rework: Reviewer phát hiện lỗi
    Downstream_Review --> [*]: Kết thúc review

    note right of Ready_for_Downstream_Review
        Không tạo approval,
        baseline, compliance
        hoặc production readiness
    end note

Điều kiện gate	Cách kiểm tra	Lý do đủ cho review, chưa đủ cho approval
Đúng định danh và vị trí canonical	ID, filename, đường dẫn giữ nguyên theo manifest hoặc registry	Reviewer biết nguồn cần xem xét; chưa quyết định nội dung đúng nghiệp vụ
Đủ liên kết nguồn	Mỗi fact, giả định, rule hoặc ràng buộc có nguồn, nhãn Project assumption hoặc Verification required	Reviewer truy ngược được căn cứ; chưa xác nhận căn cứ hợp lệ cho vận hành
Không vượt thẩm quyền	Không biến nguồn pháp lý, kế toán, bảo mật thành kết luận khi chưa có owner chuyên môn xác minh	Tránh BA tự quyết ngoài quyền; review còn cần Legal, Accounting, Security hoặc Business Owner
Nội dung nhất quán	Thuật ngữ Nova Foods, status, version, ngày, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND không mâu thuẫn	Giảm lỗi giao tiếp; chưa chứng minh ERP thực thi được
Có lịch sử thay đổi	Ghi thay đổi, ngày 2026-08-07, người ghi nhận và ảnh hưởng traceability	Reviewer thấy khác biệt; chưa tạo baseline
Không có dữ liệu thật	Chỉ dùng Nova Foods mô phỏng, dữ liệu tổng hợp	Đúng boundary case study; chưa xác nhận quyền dùng dữ liệu hoặc compliance

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; dữ liệu tổng hợp. Artifact output đang mang IN_REVIEW, v0.9.0.

Current Behavior: BA chuẩn bị output để reviewer đọc nhưng chưa ghi gate rõ ràng. Hệ quả: người nhận có thể nhầm “đủ để review” với “đã được phê duyệt”.

Underlying Need: Tách kiểm tra tính sẵn sàng cho review khỏi quyết định nghiệp vụ, pháp lý, kiến trúc, kế toán, bảo mật và production.

Options:
| Option | Đánh giá | |---|---| | Gắn APPROVED khi đủ nội dung | Loại. Sai trạng thái và vượt thẩm quyền. | | Không có gate, gửi bản nháp tự do | Loại. Reviewer không biết thiếu gì. | | Gate kiểm tra metadata, traceability, boundary và change history | Chọn. Đủ bằng chứng để review, không giả lập approval. |

Decision Criteria: Gate phải kiểm tra được, áp dụng cho mọi output, giữ canonical ID và không đòi hỏi xác nhận ngoài thẩm quyền BA.

Decision: Chỉ chuyển trạng thái làm việc sang Ready for Downstream Review khi toàn bộ điều kiện Core đạt. Status quản trị artifact vẫn là IN_REVIEW.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì metadata và traceability. Business Owner, Legal Owner, Accounting Owner, Security, Architect, QA reviewer giữ thẩm quyền kết luận chuyên môn tương ứng.

Artifact: Output kèm checklist gate hoàn tất, reference nguồn, nhãn Project assumption hoặc Verification required khi cần, và change-history entry ngày 2026-08-07 theo Asia/Ho_Chi_Minh.

Consequence if Wrong: Gắn nhầm approval có thể khiến downstream consumer dùng nội dung mô phỏng như quyết định ERP, pháp lý hoặc vận hành thật.

Senior Lens

Gate tốt kiểm tra khả năng review, không kiểm tra tính đúng cuối cùng. Hai việc khác nhau: khả năng review cần artifact đọc được, truy được và biết giới hạn; tính đúng cuối cùng cần người có thẩm quyền đánh giá nội dung. Nếu nguồn canonical mâu thuẫn, ID chưa đăng ký, hoặc claim pháp lý chưa được xác minh, gate phải fail và trả về Rework; không sửa bằng suy đoán.

Quick Reference

Kết quả gate	Ý nghĩa được phép nói	Ý nghĩa không được nói
Pass	Sẵn sàng cho downstream review	Đã phê duyệt, đã baseline, compliant, production-ready
Fail	Cần rework trước review	Artifact vô giá trị hoặc yêu cầu đã bị từ chối
Review finding	Cần ghi nhận và xử lý theo change history	Reviewer đã approval nội dung

7. Who consumes those outputs?

Core

Output của phần stakeholder, domain và context không dành riêng cho BA. Mỗi vai trò dùng cùng một nguồn để làm việc khác nhau. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi tên, ID và dữ liệu dưới đây là dữ liệu tổng hợp. Status corpus là IN_REVIEW, version v0.9.0, ngày 2026-08-07; không output nào là baseline, approval hay cấu hình ERP production.

Consumer	Output tiêu thụ	Cách dùng cụ thể	Kết quả công việc tạo ra
Developers	stakeholder map, domain glossary, context diagram, business-rule reference	Xác định actor, dữ liệu vào/ra, biên hệ thống và thuật ngữ không được hiểu khác	Thiết kế component, API contract, logic xử lý
QA	stakeholder map, process/context boundary, domain glossary, rule reference	Xây test basis: ai thực hiện luồng nào, dữ liệu nào hợp lệ, hệ thống nào nằm ngoài phạm vi	Test scenario, test data, traceability từ requirement đến test
Architect	context diagram, integration boundary, data classification	Xác định hệ thống nguồn/đích, ownership dữ liệu, điểm tích hợp, rủi ro kiến trúc	Architecture decision, integration pattern, security review input
PM/Product Owner	stakeholder map, value/problem context, scope boundary	Ưu tiên backlog theo giá trị, phụ thuộc và nhóm bị ảnh hưởng	Scope decision, release plan, backlog ordering
Business Owner	domain model, glossary, stakeholder impact	Kiểm tra thuật ngữ, outcome nghiệp vụ và phạm vi có phản ánh hoạt động mong muốn	Business direction và quyết định nghiệp vụ thuộc thẩm quyền
Operations	process context, actor responsibility, system boundary	Chuẩn bị thay đổi vận hành, hỗ trợ người dùng, xử lý ngoại lệ và handover	Runbook draft, training input, support model
Specialist owners	data classification, domain terms, rule/context reference	Legal, Accounting, Security, Food Safety hoặc Compliance đánh giá phần thuộc chuyên môn	Kết luận chuyên môn, finding, Verification required khi chưa đủ căn cứ

Developer không dùng stakeholder map để tự quyết định quy tắc kinh doanh. Map chỉ cho biết ai bị ảnh hưởng và ai tương tác. Logic tính giá, hạch toán, bảo vệ dữ liệu hoặc truy xuất thực phẩm chỉ được xây khi có rule canonical và owner chuyên môn phù hợp.

QA không dùng context diagram như test case hoàn chỉnh. Diagram chỉ xác định biên và luồng cấp cao. Test phải bổ sung điều kiện đầu vào, expected result và dữ liệu kiểm thử từ artifact requirement hoặc rule có truy vết.

Applied

Facts: Nova Foods mô phỏng có luồng “Sales Order” nhận đơn từ nhân viên bán hàng, kiểm tra tồn kho trong ERP và gửi yêu cầu giao hàng sang kho. Context diagram ghi Sales, ERP và Warehouse Operations là các participant; không ghi hệ thống vận chuyển bên thứ ba trong phạm vi.

Current Behavior: Developer đọc diagram và dự kiến gọi API đơn vị vận chuyển. QA tạo test cho nhãn vận chuyển. Architect chưa nhận integration boundary. Đây là suy luận vượt artifact vì context diagram chỉ nêu ba participant và không có endpoint, owner hay luồng sang đơn vị vận chuyển.

Underlying Need: Các consumer cần dùng đúng output để không biến khoảng trống phân tích thành phạm vi kỹ thuật.

Options: Giữ phạm vi ERP-to-Warehouse; thêm đơn vị vận chuyển vào context sau khi có nguồn; hoặc ghi nhận đây là integration ngoài phạm vi hiện tại.

Decision Criteria: Chỉ mở rộng context khi có stakeholder liên quan, business outcome, data flow, system ownership và nguồn truy vết. Thiếu một yếu tố thì không đủ căn cứ thêm participant.

Decision: Developer dùng context diagram để giới hạn build ở ERP và Warehouse Operations. QA dùng cùng diagram để loại trừ test integration đơn vị vận chuyển khỏi test basis hiện tại. Architect dùng diagram làm input xác định điểm cần làm rõ, không tự tạo interface.

Authority: Business Owner quyết định outcome và phạm vi nghiệp vụ. Architect quyết định kiến trúc sau khi phạm vi rõ. Specialist owner kết luận phần pháp lý, kế toán, bảo mật hoặc an toàn thực phẩm thuộc chuyên môn. BA duy trì traceability, không thay các thẩm quyền này.

Artifact: Context diagram, stakeholder map và glossary thuộc /02-handbook/02-stakeholders-domain-and-context.md; các tham chiếu canonical phải giữ đúng ID và filename từ registry hoặc catalog tương ứng.

Consequence if Wrong: Build integration không có phạm vi làm tăng chi phí, tạo test không có requirement, và có thể đưa dữ liệu mô phỏng sang boundary chưa được Security hoặc Business Owner xem xét.

Senior Lens

Một output có nhiều consumer không có nghĩa mọi consumer có cùng quyền sửa hoặc quyết định. Cùng một context diagram, Developer đọc để biết boundary build, QA đọc để biết boundary test, Architect đọc để biết boundary integration, Business Owner đọc để kiểm tra business scope. Evidence chung là artifact có nguồn, version, trạng thái và traceability; mục đích dùng khác nhau theo vai trò.

Không chuyển output IN_REVIEW thành “đã chốt” khi handoff. Cách gọi đúng là “input cho downstream review”. Lý do: metadata corpus ghi IN_REVIEW, chưa có baseline reference và chưa có approval reference.

Quick Reference

Output	Consumer chính	Consumer phụ	Không được suy ra
Stakeholder map	PM/Product Owner, Business Owner	Developers, QA, Operations	Quyền phê duyệt hoặc business rule mới
Domain glossary	Developers, QA, specialist owners	Business Owner, Operations	Định nghĩa pháp lý hoặc kế toán chưa xác minh
Context diagram	Architect, Developers, QA	PM/Product Owner, Operations	API, protocol, field mapping hoặc SLA chưa được mô tả
Scope boundary	PM/Product Owner, Business Owner	Architect, QA, Developers	Cam kết release hoặc production readiness
Data classification reference	Security và specialist owners	Architect, Developers, QA	Kết luận tuân thủ pháp lý

Core

Mỗi vai trò chỉ quyết định trong thẩm quyền mình. BA cung cấp gói bằng chứng, không tự thay quyết định. Nova Foods là case mô phỏng, dữ liệu tổng hợp, trạng thái corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không có baseline hay phê duyệt được ghi nhận.

Người tiêu thụ	Có thể quyết định	Bằng chứng cần có	Phải escalation khi
Developer	Cách hiện thực trong ràng buộc đã xác nhận; xử lý lỗi kỹ thuật	Quy tắc từ CANONICAL_BUSINESS_RULES, trường dữ liệu từ CANONICAL_DATA_DICTIONARY, acceptance criteria	Rule mơ hồ, dữ liệu thiếu nguồn chân lý, yêu cầu làm lộ dữ liệu cá nhân
QA	Phạm vi kiểm thử, test condition, kết quả pass/fail theo test basis	Requirement, rule, luồng, dữ liệu biên, tiêu chí chấp nhận	Tiêu chí không đo được, expected result mâu thuẫn rule, lỗi có rủi ro mất dữ liệu
Architect	Ranh giới hệ thống, tích hợp, mẫu bảo mật, quyết định kỹ thuật liên hệ thống	Context, data flow, API contract, non-functional requirement	Thay đổi kiến trúc, quyền truy cập, dữ liệu nhạy cảm, phụ thuộc hệ thống ngoài
PM/Product Owner	Ưu tiên, phạm vi release, trade-off thời gian và giá trị	Mục tiêu, dependency, effort estimate, rủi ro, tác động người dùng	Trade-off làm đổi business rule, compliance, ngân sách hoặc cam kết ngoài phạm vi
Business Owner	Ý nghĩa nghiệp vụ, ngoại lệ nghiệp vụ, mức chấp nhận kết quả	Facts, process hiện tại, KPI, tác động vận hành	Quyết định liên quan kế toán, thuế, pháp lý, quyền hạn tổ chức
Operations	Cách chạy quy trình, kiểm soát ngoại lệ, nhu cầu hỗ trợ	Quy trình, role matrix, error scenario, SLA giả định	Thay đổi ca vận hành, phân quyền, khả năng khôi phục hoặc truy vết
Specialist owner	Diễn giải chuyên môn thuộc pháp lý, kế toán, bảo mật, chất lượng thực phẩm	Nguồn chính thức, dữ liệu ảnh hưởng, phương án và rủi ro	Nội dung vượt chuyên môn BA hoặc nguồn pháp lý chưa được xác minh hiện hành

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

flowchart TB
    N["TRẠNG THÁI HIỆN TẠI<br/>Nova Foods · corpus IN_REVIEW · v0.9.0 · 2026-08-07"]
    S["QUY TRÌNH MỤC TIÊU"]
    N -.->|Corpus hiện tại chưa phải baseline và chưa ghi nhận phê duyệt cho quy trình mục tiêu| S

    S --> BA["BA cung cấp gói bằng chứng<br/>không tự thay quyết định"]
    BA --> C["Vai trò tiêu thụ<br/>quyết định trong thẩm quyền theo bảng"]
    C --> A{"Bằng chứng đủ và quyết định<br/>đúng thẩm quyền?"}

    A -->|Có| G["Ghi nhận quyết định hoặc xác minh<br/>cùng bằng chứng"]
    A -->|Không hoặc có rủi ro| E{"Phân loại điều kiện escalation"}

    E -->|Ý nghĩa hoặc ngoại lệ nghiệp vụ;<br/>business rule; tiêu chí không đo được<br/>hoặc mâu thuẫn rule| EBO["Business Owner xem xét"]

    E -->|Kiến trúc; ranh giới; tích hợp;<br/>quyền truy cập; phụ thuộc hệ thống ngoài| EA["Architect xem xét"]

    E -->|Ưu tiên; phạm vi release;<br/>trade-off thời gian và giá trị| EPM["PM/Product Owner xem xét"]

    E -->|Pháp lý; thuế; kế toán; bảo mật;<br/>dữ liệu cá nhân hoặc nhạy cảm;<br/>chất lượng thực phẩm; nguồn hoặc chuyên môn chưa xác minh| ESP["Specialist owner tương ứng<br/>xác minh nguồn và rủi ro"]

    E -->|Đổi ca vận hành; phân quyền;<br/>khả năng khôi phục hoặc truy vết| EOPS["Operations xem xét"]

    E -->|Thiếu nguồn chân lý; nguy cơ mất dữ liệu;<br/>ngân sách; cam kết ngoài phạm vi;<br/>quyền hạn tổ chức| EU["Xác định owner dữ liệu, nghiệp vụ<br/>hoặc owner có thẩm quyền theo bằng chứng nguồn"]

    EBO --> V{"Đã quyết định hoặc xác minh<br/>trong đúng thẩm quyền?"}
    EA --> V
    EPM --> V
    ESP --> V
    EOPS --> V
    EU --> V

    V -->|Có| G
    V -->|Chưa| OPEN["Giữ mở<br/>ghi nhận điểm thiếu, rủi ro<br/>và owner cần xử lý"]

    G --> BA
    OPEN --> BA

    classDef current fill:#fff4e5,stroke:#b26a00,stroke-width:2px,stroke-dasharray:5 5;
    classDef open fill:#fff0f0,stroke:#b42318,stroke-width:2px;
    class N current;
    class OPEN open;

Applied

Facts: Nova Foods mô phỏng cần chặn xuất kho khi lô hàng không có ngày hết hạn. Current Behavior: tài liệu chỉ nói “kiểm tra hạn dùng”. Underlying Need: Developer và QA cần biết chặn ở thời điểm nào, dữ liệu nào là nguồn kiểm tra, ai xử lý ngoại lệ. Options: chặn khi tạo phiếu xuất; chặn khi xác nhận xuất kho. Decision Criteria: kiểm soát rủi ro hàng hết hạn, ảnh hưởng vận hành kho, khả năng truy vết lô. Decision: chưa chọn phương án vì evidence chưa chỉ ra thời điểm nghiệp vụ. Authority: Business Owner quyết định luồng nghiệp vụ; specialist owner về an toàn thực phẩm xác minh yêu cầu chuyên môn; Architect xác minh tác động tích hợp. Artifact: ghi câu hỏi và bằng chứng liên quan trong artifact đang IN_REVIEW; tham chiếu CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY khi nội dung được đăng ký. Consequence if Wrong: Developer có thể chặn sai bước; QA kiểm thử sai expected result; Operations có thể bị gián đoạn xuất kho.

Senior Lens

Evidence không phải ý kiến truyền miệng. Evidence phải nêu nguồn, phiên bản, phạm vi, người sở hữu thẩm quyền và điều kiện áp dụng. Khi evidence chỉ là giả định dự án, gắn nhãn “giả định dự án”; không chuyển nó thành rule bắt buộc. Nội dung về pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm phải escalation đến owner chuyên môn, vì IN_REVIEW không xác nhận tuân thủ hay hiệu lực vận hành.

Quick Reference

Câu làm rõ chính xác khi handoff:

Hiểu nhầm phổ biến	Câu hỏi làm rõ
“Kiểm tra hạn dùng” đủ cho Developer	“Hệ thống kiểm tra ngày hết hạn tại thao tác nào, dùng trường dữ liệu nào, và kết quả nào được phép khi ngày hết hạn trống?”
QA tự suy ra expected result	“Expected result này xuất phát từ rule hoặc acceptance criteria nào; ai sở hữu quyết định nếu hai nguồn mâu thuẫn?”
PM/Product Owner quyết định nội dung chuyên môn	“Đây là ưu tiên phạm vi hay là diễn giải pháp lý, kế toán, bảo mật hoặc an toàn thực phẩm cần owner chuyên môn xác minh?”
Architect tự chốt quyền truy cập nghiệp vụ	“Vai trò nào được phép xem, sửa và duyệt dữ liệu; Business Owner đã cung cấp bằng chứng quyền hạn nghiệp vụ chưa?”

Core

Bàn giao lỗi khi người nhận đọc artifact (tài liệu đầu ra có kiểm soát) như quyết định đã được xác nhận, trong khi IN_REVIEW chỉ nghĩa là đang xem xét. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, mọi cách hiểu phải quay về nguồn canonical: /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, TRACEABILITY_ID_REGISTRY và artifact chứa yêu cầu. Nếu nguồn không trả lời trực tiếp, BA ghi câu hỏi; không tự lấp khoảng trống bằng giả định.

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

flowchart TB
    A[Artifact IN_REVIEW] --> B[Không coi là quyết định đã xác nhận]
    B --> C{"CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY,<br/>TRACEABILITY_ID_REGISTRY hoặc artifact chứa yêu cầu<br/>có trả lời trực tiếp và đúng thẩm quyền?"}
    C -- Có --> D[Diễn giải theo nguồn canonical]
    D --> G[Ghi kết quả vào artifact kiểm soát]
    C -- Không --> E[BA ghi câu hỏi làm rõ]
    E --> F[Không tự lấp khoảng trống bằng giả định]
    F --> H[Escalation đúng owner]
    H --> I{Owner có thẩm quyền đã trả lời trực tiếp câu hỏi?}
    I -- Có --> G
    I -- Chưa --> J[Câu hỏi vẫn mở]
    J --> K[Artifact không được coi là quyết định đã xác nhận]

Applied

Thành phần	Nội dung
Facts	Artifact Nova Foods đang ở IN_REVIEW, version v0.9.0, ngày 2026-08-07. Không có baseline reference hoặc approval reference.
Current Behavior	Developer hiểu câu “hệ thống chặn sửa số lượng sau khi tạo phiếu” là khóa tuyệt đối. QA viết test cho mọi trạng thái.
Underlying Need	Làm rõ phạm vi “sau khi tạo”: trạng thái nào, vai trò nào, dữ liệu nào, có ngoại lệ nghiệp vụ hay không. Câu ngắn không đủ chứng cứ cho hành vi hệ thống.
Options	1. Khóa mọi phiếu sau tạo. 2. Cho sửa theo trạng thái. 3. Cho sửa theo quyền và lưu vết.
Decision Criteria	Cần nguồn quy tắc nghiệp vụ canonical, trạng thái quy trình, quyền truy cập, yêu cầu audit và owner có thẩm quyền.
Decision	Chưa chọn option. Evidence hiện có chỉ chứng minh artifact đang review; không chứng minh quy tắc khóa sửa.
Authority	Business Owner quyết định nghiệp vụ; Architect xác nhận tác động thiết kế; Security Owner xác nhận quyền; QA chuyển quyết định đã ghi nhận thành test basis.
Artifact	Ghi câu hỏi và kết quả truy vết trong artifact yêu cầu liên quan; không sửa im lặng /01-curriculum/CANONICAL_BUSINESS_RULES.md.
Consequence if Wrong	Khóa quá mức làm dừng vận hành mô phỏng; mở quá mức làm sai kiểm soát dữ liệu. Cả hai không thể được xác nhận đúng chỉ từ câu mô tả ban đầu.

Senior Lens

Hiểu nhầm bàn giao	Vì sao sai	Câu hỏi làm rõ chính xác	Escalation
“Đã có trong tài liệu” nghĩa là “đã được phê duyệt”.	IN_REVIEW không phải APPROVED hoặc BASELINED.	“Nội dung này có baseline reference hoặc approval reference nào được ghi nhận không?”	Owner quản trị artifact; không tự gán approval.
“Không được sửa” nghĩa là cấm mọi sửa đổi.	Thiếu đối tượng, trạng thái, quyền và ngoại lệ.	“Không được sửa trường nào, từ trạng thái nào, bởi vai trò nào, và ngoại lệ nào phải lưu vết?”	Business Owner; Security Owner nếu liên quan quyền.
“Tích hợp đồng bộ” nghĩa là thời gian thực.	“Đồng bộ” không xác định cơ chế, tần suất, chiều dữ liệu hay xử lý lỗi.	“Đồng bộ một chiều hay hai chiều, kích hoạt bởi sự kiện nào, độ trễ chấp nhận được là bao lâu, và bản ghi lỗi được xử lý ở đâu?”	Architect; Operations owner.
“QA kiểm tra đầy đủ” nghĩa là QA tự suy ra expected result.	Test cần test basis và kết quả mong đợi có chứng cứ.	“Quy tắc hoặc acceptance criteria nào xác định kết quả mong đợi cho trường hợp này?”	Business Owner nếu thiếu quy tắc; BA bảo toàn traceability.
“Theo quy định” nghĩa là đã có yêu cầu hệ thống cụ thể.	Nguồn pháp lý cần xác minh bởi Legal Owner; không tự chuyển thành cấu hình ERP.	“Nguồn chính thức nào áp dụng, điều khoản nào đã được Legal Owner xác minh, và yêu cầu hệ thống suy ra là gì?”	Legal Owner; Accounting Owner hoặc domain owner khi phù hợp.
“Dữ liệu khách hàng” nghĩa là được phép hiển thị cho mọi người dùng nội bộ.	Loại dữ liệu không tự xác định mục đích truy cập hay quyền.	“Vai trò nào cần truy cập trường nào, cho mục đích nào, và có yêu cầu che giấu hoặc nhật ký truy cập không?”	Security Owner; Legal Owner.

Quick Reference

Quy tắc bàn giao: câu hỏi phải nêu rõ đối tượng, điều kiện, phạm vi, ngoại lệ, nguồn chứng cứ và người có thẩm quyền. Không hỏi “ý này nghĩa là gì?”; hỏi “Trường X có được sửa khi chứng từ ở trạng thái Y bởi vai trò Z không; nếu có, hệ thống phải lưu vết nào?”

Evidence thiếu không phải lỗi của người nhận. Evidence thiếu là điều kiện escalation. BA ghi nhận khoảng trống và liên kết nguồn; Developer, QA, Architect hoặc Operations không tự biến khoảng trống thành quyết định Nova Foods.

8. Detailed Worked Example

Core

Ví dụ này thuộc Nova Foods Trading & Manufacturing, case study mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Trạng thái corpus: IN_REVIEW; phiên bản: v0.9.0; ngày: 2026-08-07; locale: vi-VN; múi giờ: Asia/Ho_Chi_Minh; tiền tệ: VND. Nội dung không phải quyết định vận hành, cấu hình ERP, xác nhận tuân thủ, hay phê duyệt của bất kỳ vai trò nào.

Applied

Facts — sự kiện có chứng cứ trong kịch bản mô phỏng. Nova Foods bán thành phẩm sữa hạt đóng chai cho khách hàng đại lý. Ngày 2026-08-07, nhân viên Kinh doanh nhận đơn qua email: khách hàng yêu cầu 1.200 chai Sữa hạt óc chó 250 ml, giao ngày 2026-08-10, đơn giá đề nghị 28.000 VND/chai, chưa gồm thuế. Kho hiện có 1.000 chai thành phẩm khả dụng theo báo cáo kho nội bộ. Nhà máy dự kiến hoàn tất thêm 500 chai vào 2026-08-09, nhưng kế hoạch sản xuất chưa được đối chiếu với đơn khách hàng trong cùng hệ thống.

Nhóm fact	Dữ liệu tổng hợp	Chứng cứ trong kịch bản	Giới hạn suy luận
Nhu cầu khách hàng	1.200 chai	Email đơn hàng mô phỏng ngày 2026-08-07	Email chưa phải đơn bán được phê duyệt
Tồn kho khả dụng	1.000 chai	Báo cáo kho nội bộ mô phỏng	Chưa xác minh hàng đã được giữ cho đơn khác
Sản xuất dự kiến	500 chai	Lịch sản xuất nội bộ mô phỏng	“Dự kiến” không chứng minh chắc chắn hoàn thành
Ngày giao yêu cầu	2026-08-10	Email đơn hàng mô phỏng	Chưa xác nhận năng lực vận chuyển
Giá đề nghị	28.000 VND/chai	Email đơn hàng mô phỏng	Chưa xác nhận bảng giá hay thẩm quyền chiết khấu

Tổng giá trị hàng theo giá khách hàng đề nghị là 1.200 × 28.000 = 33.600.000 VND, chưa gồm thuế. Đây là phép tính dữ liệu mô phỏng, không phải giá trị hóa đơn, doanh thu ghi nhận, nghĩa vụ thuế hoặc quyết định kế toán.

Current Behavior — cách xử lý hiện tại. Nhân viên Kinh doanh chuyển email cho Kho qua ứng dụng chat. Kho trả lời số lượng đang nhìn thấy tại thời điểm tra cứu, không tạo giữ hàng có định danh. Nhân viên Kinh doanh sau đó thông báo miệng cho khách hàng rằng “có thể giao đủ”. Kế hoạch sản xuất nằm trong bảng tính riêng; nhân viên Kho phải hỏi Điều độ sản xuất nếu thiếu hàng. Không có bản ghi chung nối nhu cầu 1.200 chai, tồn kho 1.000 chai, phần thiếu 200 chai và mốc giao 2026-08-10.

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

flowchart TB
    A[Khách hàng gửi email: 1.200 chai, giao 2026-08-10] --> B[Nhân viên Kinh doanh gửi chat hỏi Kho]
    B --> C[Kho tra cứu báo cáo: hiển thị 1.000 chai; chưa xác minh đã giữ cho đơn khác]
    C --> D[Nhu cầu 1.200 - báo cáo tồn 1.000 = thiếu 200 chai]
    D --> E[Kho hỏi Điều độ sản xuất]
    E --> F[Xem lịch sản xuất riêng: dự kiến 500 chai ngày 2026-08-09]
    F --> G[500 chai chỉ dự kiến; chưa đối chiếu với đơn và chưa tạo giữ hàng]
    G --> H[Kho phản hồi qua chat: báo cáo kho hiển thị 1.000 chai]
    H --> I[Nhân viên Kinh doanh thông báo miệng: có thể giao đủ]
    I --> J[Chưa đủ căn cứ cam kết giao đủ ngày 2026-08-10]

Cầu nối suy luận: nhu cầu là 1.200 chai, còn tồn kho báo cáo là 1.000 chai; vì 1.200 - 1.000 = 200, đơn không thể được xác nhận chỉ bằng dữ liệu tồn kho hiện tại. Lịch sản xuất có thể bù 200 chai, nhưng đó là dữ liệu dự kiến và chưa có liên kết kiểm soát với cam kết giao hàng. Vì vậy, vấn đề quan sát được là thiếu một nguồn dữ liệu chung để nhân viên biết số lượng nào đã khả dụng, số lượng nào chỉ dự kiến, và cam kết nào đã được xác nhận.

Senior Lens

Không đổi nhãn “dự kiến sản xuất” thành “đủ hàng”. Hai trạng thái có ý nghĩa khác nhau: tồn kho khả dụng là hàng đang có thể phân bổ; sản xuất dự kiến là kế hoạch có rủi ro thay đổi. BA ghi nhận khoảng cách này bằng fact và current behavior trước khi nêu nhu cầu hay đề xuất giải pháp.

Nguồn của ví dụ là dữ liệu Nova Foods tổng hợp. Không có trích dẫn pháp lý, điều khoản tiêu chuẩn, giá bán thực tế, khách hàng thực tế, hay bằng chứng rằng Nova Foods vận hành quy trình này.

Quick Reference

Thành phần	Nội dung đã xác lập trong micro-batch
Phạm vi tình huống	Đơn bán 1.200 chai so với tồn kho 1.000 chai
Điểm lệch	Thiếu 200 chai tại thời điểm Kho tra cứu
Dữ liệu liên quan	Email đơn hàng, báo cáo kho, lịch sản xuất, trao đổi chat
Rủi ro hiện tại	Cam kết giao đủ khi chưa nối tồn kho khả dụng với sản xuất dự kiến
Artifact quản trị liên quan	TRACEABILITY_ID_REGISTRY, CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES

Applied

Bối cảnh: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ dữ liệu tổng hợp. Kịch bản NF-SCN-08-01 xử lý đơn bán thành phẩm sắp hết hạn tại kho Bình Tân, TP.HCM, ngày 2026-08-07, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND.

Bước phân tích	Nội dung hoàn chỉnh	Bằng chứng hoặc cầu nối suy luận
Facts	Mặt hàng FG-NUD-500 là mì gói Nova Noodle 500g. Lô LOT-NUD-260815-A còn 1.200 gói, hạn dùng 2026-08-15. Giá bán chuẩn 8.000 VND/gói. Khách hàng CUS-MT-018 đặt 900 gói qua Sales Order SO-260807-018. Kho Bình Tân có 2 lô khả dụng: LOT-NUD-260815-A còn 1.200 gói, hết hạn sau 8 ngày; LOT-NUD-261130-B còn 2.000 gói, hết hạn sau 115 ngày.	Dữ liệu là fact mô phỏng vì là số tồn, hạn dùng, đơn hàng và giá tại thời điểm xử lý. Fact chưa chứng minh chính sách vận hành thực tế hay nghĩa vụ pháp lý.
Current Behavior	Nhân viên kho chọn lô bằng cách nhìn danh sách tồn, không có thứ tự hệ thống bắt buộc. Trong kịch bản này, nhân viên chọn LOT-NUD-261130-B vì nằm đầu danh sách. LOT-NUD-260815-A vẫn còn 1.200 gói sau khi giao đơn.	Hành vi hiện tại cho thấy hệ thống chỉ hiển thị tồn theo lô, không áp dụng quy tắc cấp phát. Việc lô mới xuất trước làm lô gần hết hạn tiếp tục nằm kho.
Underlying Need	Cần cấp phát hàng theo FEFO (First Expired, First Out — lô hết hạn sớm xuất trước) khi lô còn đủ điều kiện bán. Mục tiêu là giảm nguy cơ hết hạn trong kho, vẫn chặn lô đã hết hạn, và giữ người có thẩm quyền quyền xử lý ngoại lệ.	Nếu đơn 900 gói lấy từ lô hết hạn 2026-08-15, lô này còn 300 gói thay vì 1.200 gói. Do đó nhu cầu không phải “chọn lô cũ hơn” theo cảm tính, mà là áp dụng tiêu chí hạn dùng có kiểm soát.
Options	OPT-01: giữ chọn lô thủ công. OPT-02: ERP đề xuất lô theo FEFO, nhân viên kho được đổi lô không cần lý do. OPT-03: ERP đề xuất lô theo FEFO; đổi sang lô khác phải nhập lý do, lưu người thao tác và chuyển ngoại lệ cho Quản lý Kho khi lô FEFO vẫn hợp lệ.	OPT-01 không ngăn hành vi hiện tại. OPT-02 có đề xuất nhưng mất truy vết ngoại lệ. OPT-03 giảm rủi ro tồn cận hạn và tạo bằng chứng kiểm tra sau này.
Decision Criteria	Chấm 1 thấp đến 5 cao. Tiêu chí: giảm rủi ro hết hạn trong kho 40%; truy vết ngoại lệ 25%; tác động thao tác kho 20%; khả năng cấu hình ERP 15%.	Trọng số ưu tiên rủi ro hàng cận hạn vì đây là nguyên nhân trực tiếp của kịch bản. Đây là giả định dự án mô phỏng, không phải chính sách Nova Foods thực tế.
Decision	Khuyến nghị BA: chọn OPT-03. ERP sắp lô khả dụng theo ngày hết hạn tăng dần; chỉ xét lô có expiry_date >= posting_date; cấp phát theo số lượng cần giao; ghi override_reason khi đổi lô.	OPT-03 đạt tổng điểm cao nhất 4,55/5, cao hơn OPT-02 là 3,80/5 và OPT-01 là 2,15/5. Khuyến nghị chưa là quyết định được phê duyệt.
Authority	Business Owner chịu trách nhiệm quyết định quy tắc cấp phát bán hàng. Warehouse Manager xác nhận khả thi thao tác kho. QA Owner xác nhận test basis. Legal/Compliance Owner phải xác minh yêu cầu liên quan truy xuất, an toàn thực phẩm hoặc lưu giữ dữ liệu nếu phạm vi triển khai chạm các nghĩa vụ đó.	Tại v0.9.0, trạng thái corpus là IN_REVIEW; không có baseline reference hoặc approval reference. Vì vậy không vai trò nào trong ví dụ này được ghi là đã phê duyệt.
Artifact	BA ghi nhận đề xuất trong /02-handbook/02-stakeholders-domain-and-context.md, mục 08-worked-example, kịch bản NF-SCN-08-01. Quy tắc dự kiến phải được liên kết tới CANONICAL_BUSINESS_RULES; trường dữ liệu dự kiến phải được liên kết tới CANONICAL_DATA_DICTIONARY; ID và liên kết phải kiểm tra với TRACEABILITY_ID_REGISTRY.	Ba artifact canonical nêu trên đang IN_REVIEW, v0.9.0. Liên kết là truy vết học liệu, không tạo rule production hay cấu hình ERP.
Consequence if Wrong	Nếu chọn OPT-01, lô LOT-NUD-260815-A có thể hết hạn trước khi xuất. Nếu chọn OPT-02, nhân viên có thể đổi lô mà không giải thích được nguyên nhân. Nếu tự gọi OPT-03 là đã phê duyệt, BA vượt thẩm quyền Business Owner và làm sai trạng thái quản trị IN_REVIEW.	Sai quy tắc gây rủi ro tồn hủy. Sai truy vết gây khó điều tra. Sai thẩm quyền gây rủi ro governance.

Option	Rủi ro hết hạn 40%	Truy vết 25%	Thao tác kho 20%	Cấu hình ERP 15%	Tổng
OPT-01 Chọn thủ công	1	1	5	5	2,15
OPT-02 FEFO, đổi tự do	4	2	4	4	3,80
OPT-03 FEFO, đổi có lý do	5	5	3	4	4,55

Quy tắc đề xuất BR-PROP-FEFO-01: Khi tạo phiếu xuất cho Sales Order, hệ thống chỉ đưa vào danh sách cấp phát các lô có tồn khả dụng lớn hơn 0 và expiry_date >= posting_date. Hệ thống sắp các lô này theo expiry_date tăng dần. Nếu người dùng thay lô được đề xuất trong khi lô đó vẫn đủ điều kiện, hệ thống bắt buộc lưu lý do thay lô và định danh người thao tác. Đây là đề xuất học liệu; cần đăng ký và xác nhận trong artifact canonical trước khi dùng làm requirement.

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

flowchart TB
    A[SO-260807-018: cần giao 900 gói] --> B[Lấy các lô có tồn khả dụng > 0]
    B --> C{Còn lô chưa kiểm tra?}
    C -- Có --> D[Kiểm tra lô tiếp theo]
    D --> E{expiry_date >= posting_date?}
    E -- Không --> F[Loại lô khỏi danh sách cấp phát]
    F --> C
    E -- Có --> G[Giữ lô trong danh sách cấp phát]
    G --> C
    C -- Không --> H[Sắp lô đủ điều kiện theo expiry_date tăng dần]
    H --> I{Còn số lượng cần giao?}
    I -- Không --> J[Hoàn tất cấp phát]
    I -- Có --> K{Còn lô FEFO đủ điều kiện?}
    K -- Không --> L[Báo thiếu tồn khả dụng]
    K -- Có --> M[Đề xuất lô FEFO kế tiếp]
    M --> N{Lô FEFO vẫn đủ điều kiện?}
    N -- Không --> O[Bỏ qua lô mất điều kiện]
    O --> K
    N -- Có --> P{Người dùng đổi lô?}
    P -- Không --> Q[Cấp phát số lượng khả dụng, tối đa số lượng còn cần, từ lô FEFO]
    Q --> R[Cập nhật số lượng còn cần]
    R --> I
    P -- Có --> S[Nhập override_reason và lưu người thao tác]
    S --> T{Lô được chọn có tồn khả dụng > 0 và expiry_date >= posting_date?}
    T -- Không --> U[Từ chối lô được chọn]
    U --> M
    T -- Có --> V[Chuyển ngoại lệ cho Warehouse Manager]
    V --> W[Chờ xử lý ngoại lệ]

Payload minh họa khi đổi lô:

{
  "sales_order_id": "SO-260807-018",
  "item_id": "FG-NUD-500",
  "suggested_lot_id": "LOT-NUD-260815-A",
  "selected_lot_id": "LOT-NUD-261130-B",
  "quantity": 900,
  "posting_date": "2026-08-07",
  "override_reason": "Khách hàng yêu cầu lô có hạn dùng dài hơn",
  "operator_id": "USR-WH-014",
  "currency": "VND"
}

override_reason là dữ liệu cần truy vết nghiệp vụ, không phải bằng chứng rằng ngoại lệ đã được Warehouse Manager chấp thuận.

Applied

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; toàn bộ dữ liệu dưới đây là dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Các ID là định danh tham chiếu của ví dụ này, không phải baseline, cấu hình ERP production, hay quyết định đã được phê duyệt.

Loại	ID	Giá trị đầy đủ
Kịch bản	SCN-NF-08-001	Lô thành phẩm sữa hạt điều UHT bị chặn xuất kho vì thiếu kết quả kiểm nghiệm chất lượng
Khách hàng	CUS-NF-001	Siêu thị An Phú, Hà Nội
Đơn bán hàng	SO-NF-20260807-001	1.200 thùng SP-NF-CAUHT-180
Sản phẩm	SP-NF-CAUHT-180	Sữa hạt điều UHT 180 ml, 24 hộp/thùng
Lệnh sản xuất	MO-NF-20260806-014	Sản xuất 1.500 thùng tại nhà máy mô phỏng Bình Dương
Lô sản xuất	LOT-NF-CA-260806-A	1.500 thùng; ngày sản xuất 2026-08-06; hạn dùng 2027-02-06
Phiếu kiểm nghiệm	QC-NF-20260807-009	Trạng thái PENDING_REVIEW; chưa có kết luận đạt hoặc không đạt
Phiếu xuất kho dự kiến	DO-NF-20260807-003	Dự kiến xuất 1.200 thùng lúc 14:00 ngày 2026-08-07
Kho	WH-NF-BD-FG01	Kho thành phẩm mô phỏng Bình Dương
Vai trò quyết định nghiệp vụ	ROLE-NF-QA-MANAGER	QA Manager
Artifact ghi nhận	ART-NF-08-001	/02-handbook/02-stakeholders-domain-and-context.md, section 08-worked-example

Quy tắc tham chiếu của ví dụ

Rule ID	Quy tắc	Phân loại nguồn	Ranh giới sử dụng
BR-NF-08-001	Hệ thống chỉ cho phép phân bổ và xuất kho lô có qcReleaseStatus = RELEASED.	Project assumption	Cần Business Owner và QA Owner xác nhận trước khi thành quy tắc Nova Foods.
BR-NF-08-002	Lô có qcReleaseStatus = PENDING_REVIEW phải giữ trạng thái tồn kho QUALITY_HOLD.	Project assumption	Không suy diễn đây là nghĩa vụ pháp lý.
BR-NF-08-003	Người dùng Sales không được tự đổi trạng thái kiểm soát chất lượng của lô.	Khuyến nghị kiểm soát truy cập	Security Owner và Architect phải xác nhận quyền thực tế.
BR-NF-08-004	Hệ thống phải lưu người đổi trạng thái, thời điểm, trạng thái cũ, trạng thái mới và lý do.	Khuyến nghị audit trail	Không khẳng định đáp ứng Luật Kế toán hay luật dữ liệu cá nhân.
VR-NF-08-001	Cách lưu, thời hạn lưu và quyền truy cập dữ liệu kiểm nghiệm cần Legal Owner, QA Owner và Security Owner xác minh.	Verification required	Không dùng làm kết luận tuân thủ Luật An toàn thực phẩm hoặc Luật Bảo vệ dữ liệu cá nhân.

Payload hiện trạng cần hệ thống nhận biết

{
  "salesOrderId": "SO-NF-20260807-001",
  "deliveryOrderId": "DO-NF-20260807-003",
  "warehouseId": "WH-NF-BD-FG01",
  "productId": "SP-NF-CAUHT-180",
  "requestedQuantity": 1200,
  "uom": "CARTON",
  "allocation": [
    {
      "lotId": "LOT-NF-CA-260806-A",
      "allocatedQuantity": 1200,
      "inventoryStatus": "QUALITY_HOLD",
      "qcReleaseStatus": "PENDING_REVIEW",
      "qcRecordId": "QC-NF-20260807-009"
    }
  ],
  "requestedShipAt": "2026-08-07T14:00:00+07:00",
  "currency": "VND"
}

Payload cho thấy toàn bộ 1.200 thùng dự kiến giao lấy từ một lô đang QUALITY_HOLD. Bằng chứng là allocatedQuantity bằng requestedQuantity, đồng thời qcReleaseStatus là PENDING_REVIEW. Theo BR-NF-08-001 và BR-NF-08-002, hệ thống phải chặn xác nhận xuất kho; đây là suy luận từ giá trị trạng thái, không phải giả định rằng lô đã không đạt chất lượng.

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

flowchart TB
    subgraph LOT["Lô LOT-NF-CA-260806-A — trạng thái đồng thời trong payload"]
        INV["inventoryStatus<br/>QUALITY_HOLD"]
        QC["qcReleaseStatus<br/>PENDING_REVIEW"]
        INV ---|"BR-NF-08-002:<br/>PENDING_REVIEW phải QUALITY_HOLD"| QC
    end

    QC -.->|"Khuyến nghị IN_REVIEW:<br/>ROLE-NF-QA-MANAGER đổi trạng thái<br/>có audit trail"| RELEASED["qcReleaseStatus<br/>RELEASED"]
    QC -.->|"Khuyến nghị IN_REVIEW:<br/>ROLE-NF-QA-MANAGER đổi trạng thái<br/>có audit trail"| REJECTED["qcReleaseStatus<br/>REJECTED"]

    QC --> CHECK{"Xác nhận xuất<br/>DO-NF-20260807-003:<br/>qcReleaseStatus = RELEASED?"}
    RELEASED --> CHECK
    REJECTED --> CHECK

    CHECK -- "Không: PENDING_REVIEW hoặc REJECTED" --> DENY["Từ chối xác nhận xuất<br/>Không cho phân bổ và xuất"]
    CHECK -- "Có: RELEASED" --> ALLOW["Cho phép phân bổ<br/>và xác nhận xuất"]

    ALLOW --> SHIP["Xác nhận xuất<br/>DO-NF-20260807-003"]

Phương án	Xử lý DO-NF-20260807-003	Tiêu chí đánh giá	Kết quả phân tích
OPT-NF-08-001	Sales xuất hàng ngay, ghi chú chờ QA bổ sung sau.	Giao đúng giờ, kiểm soát chất lượng, truy vết.	Không đạt kiểm soát chất lượng và audit trail; loại.
OPT-NF-08-002	Hệ thống chặn xuất; QA Manager quyết định RELEASED hoặc REJECTED.	Phân tách thẩm quyền, truy vết, ngăn xuất lô chưa có kết luận.	Đạt các tiêu chí của ví dụ; là khuyến nghị.
OPT-NF-08-003	Sales yêu cầu quản lý kho bỏ chặn thủ công.	Kiểm soát quyền, truy vết, tính nhất quán trạng thái.	Không đạt BR-NF-08-003; loại.

Loại kết luận	Nội dung	Thẩm quyền và trạng thái
Khuyến nghị BA	Chọn OPT-NF-08-002: ERP chặn xác nhận xuất khi qcReleaseStatus khác RELEASED; chỉ ROLE-NF-QA-MANAGER được gửi thay đổi trạng thái có audit trail.	Khuyến nghị phân tích trong ART-NF-08-001; IN_REVIEW, v0.9.0.
Quyết định được ủy quyền	Chưa có. Không có baseline reference, approval reference, hay xác nhận từ QA Manager, Business Owner, Security Owner hoặc Architect.	Không được diễn đạt khuyến nghị là quyết định Nova Foods.
Hậu quả nếu sai	Nếu cho xuất lúc PENDING_REVIEW, 1.200 thùng có thể rời kho khi kết quả kiểm nghiệm chưa được kết luận; truy vết giao hàng và trách nhiệm xử lý sự cố bị yếu đi. Nếu chặn cả lô RELEASED, giao hàng bị trì hoãn không cần thiết.	Rủi ro vận hành mô phỏng; không phải kết luận pháp lý hoặc chất lượng thực tế.

9. Related Concepts & Dependencies

Core

Phụ thuộc (dependency) là quan hệ một artifact cần dữ liệu, định nghĩa, ID hoặc quyết định từ artifact khác để giữ đúng nghĩa. Nguồn chân lý canonical là tệp được chỉ định duy nhất để sở hữu nội dung đó. Chapter này chỉ lập bản đồ liên kết; không chép lại rule, định nghĩa dữ liệu, ID hay nội dung template.

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Mọi artifact dưới đây có trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND. Không có baseline hoặc approval reference.

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

flowchart TB
    subgraph U["Upstream canonical"]
        SM["00_SOURCE_MAP<br/>Nguồn, URL chính thức, safe use boundary"]
        CA["01_CURRICULUM_ARCHITECTURE<br/>Cấu trúc curriculum, dependency kiến trúc"]
        CM["CHAPTER_MANIFEST<br/>Tên chapter, đường dẫn, phạm vi"]
        TM["TEMPLATE_MANIFEST<br/>Danh mục template"]
        ID["TRACEABILITY_ID_REGISTRY<br/>ID persistent, quy tắc cấp và dùng ID"]
        BR["CANONICAL_BUSINESS_RULES<br/>Rule nghiệp vụ canonical"]
        DD["CANONICAL_DATA_DICTIONARY<br/>Định nghĩa dữ liệu logic canonical"]
    end

    subgraph C["Chapter tiêu thụ"]
        H["/02-handbook/02-stakeholders-domain-and-context.md<br/>Section 9"]
    end

    subgraph D["Downstream artifact"]
        A["Artifact phân tích"]
        T["Template hoàn chỉnh"]
        X["Test artifact tương lai"]
    end

    SM -->|"tham chiếu; không sao chép nội dung canonical"| H
    CA -->|"tham chiếu; không sao chép nội dung canonical"| H
    CM -->|"tham chiếu; không sao chép nội dung canonical"| H
    TM -->|"tham chiếu; không sao chép nội dung canonical"| H
    ID -->|"tham chiếu; không sao chép nội dung canonical"| H
    BR -->|"tham chiếu; không sao chép nội dung canonical"| H
    DD -->|"tham chiếu; không sao chép nội dung canonical"| H

    H -->|"kế thừa ID và link canonical; không sửa ngược source"| A
    H -->|"kế thừa ID và link canonical; không sửa ngược source"| T
    H -->|"kế thừa ID và link canonical; không sửa ngược source"| X

Hướng	Artifact canonical	Nội dung sở hữu	Chapter này dùng thế nào
Upstream	/00-research/00_SOURCE_MAP.md — 00_SOURCE_MAP	Phân loại nguồn, URL chính thức, safe use boundary	Dẫn nguồn theo đúng phân loại; không tự diễn giải điều khoản pháp lý.
Upstream	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md — 01_CURRICULUM_ARCHITECTURE	Cấu trúc curriculum, dependency cấp kiến trúc	Kiểm tra chapter có đúng vai trò trong chuỗi học.
Upstream	/01-curriculum/CHAPTER_MANIFEST.md — CHAPTER_MANIFEST	Tên chapter, đường dẫn, phạm vi	Giữ nguyên /02-handbook/02-stakeholders-domain-and-context.md; không đổi tên hoặc tạo chapter thay thế.
Upstream	/01-curriculum/TEMPLATE_MANIFEST.md — TEMPLATE_MANIFEST	Danh mục template dự kiến	Chỉ tham chiếu template đã đăng ký; không tạo ID template mới tại chapter.
Upstream	/01-curriculum/TRACEABILITY_ID_REGISTRY.md — TRACEABILITY_ID_REGISTRY	ID persistent, quy tắc cấp và dùng ID	Giữ nguyên DO-NF-20260807-003, BR-NF-08-003, ROLE-NF-QA-MANAGER, ART-NF-08-001.
Upstream	/01-curriculum/CANONICAL_BUSINESS_RULES.md — CANONICAL_BUSINESS_RULES	Rule nghiệp vụ canonical	Link tới rule; không chép rule thành bản thứ hai.
Upstream	/01-curriculum/CANONICAL_DATA_DICTIONARY.md — CANONICAL_DATA_DICTIONARY	Định nghĩa dữ liệu logic canonical	Tham chiếu qcReleaseStatus; không tự thêm kiểu dữ liệu, enum hay nghĩa mới.
Downstream	Artifact phân tích, template hoàn chỉnh, test artifact tương lai	Bằng chứng sử dụng dependency	Kế thừa ID và link về canonical source; không sửa ngược source trong artifact tiêu thụ.

Applied

Facts: DO-NF-20260807-003 là delivery order mô phỏng gồm 1.200 thùng. Ví dụ trước dùng qcReleaseStatus, BR-NF-08-003, ROLE-NF-QA-MANAGER và ART-NF-08-001.

Current Behavior: Nếu từng artifact tự viết lại trạng thái QC hoặc tự đổi ID rule, cùng một delivery order có thể có hai nghĩa khác nhau.

Underlying Need: Người đọc cần biết nơi tìm định nghĩa chính thức của ID, rule và dữ liệu trước khi dùng chúng trong stakeholder analysis.

Options: (1) Chép toàn bộ rule và data field vào chapter; (2) chỉ ghi ID không có đường dẫn canonical; (3) ghi ID, mục đích sử dụng và artifact canonical.

Decision Criteria: Không tạo hai nguồn chân lý; ID vẫn truy vết được; người đọc tìm được owner artifact; thay đổi được kiểm soát một chỗ.

Decision: Chọn phương án 3. Chapter ghi: qcReleaseStatus thuộc CANONICAL_DATA_DICTIONARY; BR-NF-08-003 thuộc CANONICAL_BUSINESS_RULES; cấu trúc ID thuộc TRACEABILITY_ID_REGISTRY.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết quản trị. Owner không xác nhận rule Nova Foods, không baseline, không approval, không thay QA Manager, Business Owner, Architect, Legal Owner hay Security Owner.

Artifact: Ghi liên kết tại /02-handbook/02-stakeholders-domain-and-context.md, section 09-dependencies; không sửa nội dung canonical source.

Consequence if Wrong: Nếu BR-NF-08-003 bị chép và sửa âm thầm trong chapter, artifact khác vẫn tham chiếu bản canonical cũ. Người học có thể phân tích cùng ID theo hai rule khác nhau; review, test design và quyết định mô phỏng mất cùng một basis.

Senior Lens

ID persistent là mã không đổi để nối cùng đối tượng qua nhiều artifact. Tên hiển thị có thể đổi để rõ tiếng Việt; ID không đổi vì ID là khóa truy vết. Ví dụ, không đổi DO-NF-20260807-003 thành DONF003 chỉ để ngắn hơn. Bằng chứng: registry là nơi sở hữu quy tắc ID; chapter chỉ là artifact tiêu thụ.

Không dùng link đơn lẻ thay cho source boundary. Link phải kèm artifact ID, đường dẫn và loại nội dung sở hữu. Cách này phân biệt “chapter đang giải thích cách dùng” với “catalog đang định nghĩa nội dung”. Khi canonical source chưa có nội dung chi tiết, giữ nhãn kế hoạch IN_REVIEW; không bù khoảng trống bằng rule Nova Foods tự tạo.

Quick Reference

Quy tắc	Làm	Không làm
Rule	Tham chiếu CANONICAL_BUSINESS_RULES bằng ID rule.	Chép rule thành phiên bản local.
Data	Tham chiếu CANONICAL_DATA_DICTIONARY cho field và nghĩa.	Tự suy ra giá trị hợp lệ từ ví dụ.
ID	Dùng nguyên chuỗi từ TRACEABILITY_ID_REGISTRY.	Rút gọn, dịch, tái sử dụng hoặc cấp ID mới.
Template	Kiểm tra TEMPLATE_MANIFEST trước khi link template.	Tạo template chưa đăng ký.
Chapter	Giữ filename và scope từ CHAPTER_MANIFEST.	Đổi tên file hoặc mở rộng scope không kiểm soát.
Nguồn	Dùng boundary từ 00_SOURCE_MAP.	Trình bày nguồn pháp lý, kế toán, chất lượng như kết luận vận hành Nova Foods.

Core

Traceability là liên kết có kiểm soát giữa nhu cầu và bằng chứng kiểm thử. Mỗi loại ID giữ một chức năng: NEED nêu vấn đề hoặc giá trị cần đạt; REQ nêu yêu cầu; BR nêu quy tắc nghiệp vụ; AC nêu điều kiện chấp nhận; DATA/API nêu dữ liệu hoặc giao diện tích hợp; TC nêu ca kiểm thử. Không chép lại nội dung canonical vào bảng này. Bảng chỉ giữ ID, quan hệ và vị trí nguồn thật. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là tổng hợp.

Liên kết	ID nguồn	ID đích	Quan hệ kiểm soát	Nguồn canonical hoặc artifact tham chiếu	Lý do truy vết
Need đến requirement	NEED-NF-001	REQ-NF-001	satisfied-by	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Nhu cầu biết tồn kho lô nguyên liệu phải có yêu cầu hệ thống đáp ứng.
Requirement đến business rule	REQ-NF-001	BR-NF-001	constrained-by	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Yêu cầu tra cứu tồn kho bị ràng buộc bởi quy tắc chỉ hiển thị lô còn hiệu lực theo giả định học liệu.
Business rule đến acceptance criteria	BR-NF-001	AC-NF-001	verified-by	Artifact requirement/acceptance criteria được đăng ký theo TRACEABILITY_ID_REGISTRY	Tiêu chí chấp nhận biến quy tắc thành kết quả quan sát được.
Requirement đến dữ liệu	REQ-NF-001	DATA-NF-001	uses	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tra cứu lô cần thực thể logic InventoryLot, không tự tạo bản sao định nghĩa trường.
Requirement đến API	REQ-NF-001	API-NF-001	implemented-by	Đặc tả API được đăng ký theo TRACEABILITY_ID_REGISTRY; mô tả HTTP theo OpenAPI Specification OAS 3.1.1 khi được tạo	UI hoặc dịch vụ cần giao diện lấy danh sách lô; ID API không thay thế OpenAPI canonical.
Acceptance criteria đến test case	AC-NF-001	TC-NF-001	tested-by	Test artifact được đăng ký theo TRACEABILITY_ID_REGISTRY	Test xác minh kết quả nêu trong AC, không suy diễn thêm quy tắc.
Dữ liệu đến test case	DATA-NF-001	TC-NF-001	test-data-for	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	TC cần dữ liệu tổng hợp đúng kiểu dữ liệu, ví dụ mã lô LOT-RM-202608-001.
API đến test case	API-NF-001	TC-NF-001	exercised-by	Đặc tả API được đăng ký theo TRACEABILITY_ID_REGISTRY	TC kiểm tra hành vi giao diện, gồm đầu vào, đầu ra và lỗi được đặc tả.

Applied

Mục	Nội dung
Facts	Kho nguyên liệu mô phỏng Nova Foods cần nhân viên tra cứu lô bột mì trước khi lập lệnh sản xuất. Dữ liệu tổng hợp gồm LOT-RM-202608-001, trạng thái Available, số lượng 500 kg.
Current Behavior	Người dùng tra cứu theo mã nguyên liệu nhưng chưa có chuỗi liên kết chứng minh requirement, quy tắc lô, dữ liệu và test cùng nói về một phạm vi.
Underlying Need	NEED-NF-001: giảm rủi ro chọn nhầm lô trong bài học ERP mô phỏng. Bằng chứng: thao tác chọn lô chỉ đáng tin khi ID lô, trạng thái lô và điều kiện hiển thị có nguồn chung.
Options	Ghi nội dung quy tắc vào từng REQ và TC; hoặc tham chiếu BR-NF-001 một lần từ nguồn canonical.
Decision Criteria	Chọn cách không tạo hai nguồn chân lý, truy được từ NEED đến TC, và không biến ví dụ học liệu thành cấu hình ERP thực tế.
Decision	Tham chiếu ID canonical. REQ-NF-001 không lặp nội dung BR-NF-001; TC-NF-001 kiểm tra AC-NF-001, dùng dữ liệu thuộc DATA-NF-001.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết và metadata. Business Owner, Architect, QA Owner, Legal Owner hoặc Accounting Owner xác nhận phần thuộc thẩm quyền họ khi phát sinh. Không có approval được suy ra.
Artifact	Registry ID canonical: /01-curriculum/TRACEABILITY_ID_REGISTRY.md; quy tắc: /01-curriculum/CANONICAL_BUSINESS_RULES.md; dữ liệu: /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Tất cả IN_REVIEW, v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Nếu TC-NF-001 trỏ nhầm AC, test có thể pass nhưng không chứng minh NEED-NF-001. Nếu API dùng trường không thuộc DATA-NF-001, tích hợp có thể hiểu khác kiểu, tên hoặc ý nghĩa dữ liệu.

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

flowchart TB
    SCOPE["Phạm vi: truy vết và trách nhiệm quản trị"]

    subgraph TRACE["Chuỗi truy vết"]
        N["NEED-NF-001"] -->|"được cụ thể hóa bởi"| R["REQ-NF-001"]
        R -->|"tham chiếu canonical"| B["BR-NF-001"]
        B -->|"được kiểm chứng bằng"| A["AC-NF-001"]
        A -->|"được kiểm tra bởi"| T["TC-NF-001"]
        R -->|"dùng dữ liệu"| D["DATA-NF-001"]
        R -->|"liên kết interface"| P["API-NF-001"]
        D -->|"định nghĩa trường dữ liệu"| P
        D -->|"cung cấp dữ liệu test"| T
        P -->|"được kiểm tra bởi"| T
    end

    subgraph EVIDENCE["Nguồn canonical và metadata vật chứng"]
        REG["Registry ID canonical<br/>/01-curriculum/TRACEABILITY_ID_REGISTRY.md"]
        RULES["Quy tắc canonical<br/>/01-curriculum/CANONICAL_BUSINESS_RULES.md"]
        DICT["Từ điển dữ liệu canonical<br/>/01-curriculum/CANONICAL_DATA_DICTIONARY.md"]
        META["IN_REVIEW · v0.9.0 · 2026-08-07"]

        REG -->|"đăng ký ID"| N
        REG -->|"đăng ký ID"| R
        REG -->|"đăng ký ID"| B
        REG -->|"đăng ký ID"| A
        REG -->|"đăng ký ID"| D
        REG -->|"đăng ký ID"| P
        REG -->|"đăng ký ID"| T
        RULES -->|"nguồn canonical"| B
        DICT -->|"nguồn canonical"| D
        REG -.-> META
        RULES -.-> META
        DICT -.-> META
    end

    subgraph GOV["Ranh giới trách nhiệm"]
        M["Principal IT Business Analyst /<br/>Technical Curriculum Author"]
        O["Business Owner<br/>Architect<br/>QA Owner<br/>Legal Owner<br/>Accounting Owner"]
        AUTH["Xác nhận phần thuộc thẩm quyền<br/>khi phát sinh"]
        G["Không suy ra approval"]

        M -->|"duy trì chuỗi liên kết"| N
        M -->|"duy trì metadata"| META
        O -->|"thực hiện"| AUTH
        AUTH -->|"không đồng nghĩa approval"| G
    end

    subgraph RISK["Hậu quả nếu sai"]
        W["TC-NF-001 trỏ nhầm AC"] --> C1["Test pass nhưng không chứng minh NEED-NF-001"]
        X["API-NF-001 dùng trường ngoài DATA-NF-001"] --> C2["Sai khác kiểu, tên hoặc ý nghĩa dữ liệu"]
    end

    SCOPE -.-> N
    SCOPE -.-> G
    T -.->|"nếu kiểm tra nhầm"| W
    P -.->|"nếu dùng trường ngoài nguồn canonical"| X

Senior Lens

Một ID không chứng minh nội dung đúng; ID chỉ chứng minh liên kết được ghi nhận. Bằng chứng nội dung nằm ở artifact canonical, trạng thái, phiên bản và nguồn được phép dùng. Khi BR-NF-001 đổi, rà toàn bộ liên kết đi tới AC-NF-001, REQ-NF-001 và TC-NF-001; không sửa im lặng ID hoặc diễn giải cũ. Nếu thay đổi làm AC không còn kiểm tra đúng quy tắc, TC pass không còn là bằng chứng hợp lệ.

Quick Reference

Loại	Câu hỏi kiểm tra
NEED	Vấn đề hoặc giá trị nào cần giải quyết?
REQ	Hệ thống hoặc quy trình phải làm gì?
BR	Ràng buộc nghiệp vụ nào giới hạn REQ?
AC	Kết quả quan sát nào chứng minh REQ đạt?
DATA/API	Dữ liệu, giao diện nào làm REQ khả thi?
TC	Ca kiểm thử nào tạo bằng chứng cho AC?

Core

Thay đổi lan truyền khi một artifact nguồn đổi nội dung, định danh, trạng thái hoặc ý nghĩa, rồi làm các artifact đang tham chiếu nó không còn đúng. “Lan truyền” không phải sao chép lại nội dung nguồn; nó là kiểm tra lại mọi liên kết đến nguồn. Nova Foods Trading & Manufacturing là case study mô phỏng, chỉ dùng dữ liệu tổng hợp.

Thay đổi im lặng là thay đổi không có version, lịch sử thay đổi, đánh giá tác động hoặc thông báo cho owner artifact phụ thuộc. Ví dụ, CANONICAL_DATA_DICTIONARY đổi ý nghĩa trường dữ liệu nhưng đặc tả API, requirement và test case vẫn dùng nghĩa cũ. Bằng chứng lỗi nằm ở mâu thuẫn giữa nguồn canonical mới và artifact phụ thuộc cũ, không nằm ở việc một tệp vẫn mở được.

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

flowchart TB
    A[Canonical artifact thay đổi] --> B[Tạo version và ghi lịch sử thay đổi]
    B --> C[Phân tích liên kết phụ thuộc]
    C --> D[Cập nhật hoặc đánh dấu artifact bị ảnh hưởng]
    D --> E[Thông báo owner artifact phụ thuộc]
    E --> F[Review theo thẩm quyền]
    F --> G[Giữ traceability nhất quán]

    A -. thay đổi im lặng: không version, lịch sử, đánh giá tác động hoặc thông báo owner .-> H[REQ, API, TC vẫn dùng ý nghĩa cũ]
    H --> I[Mâu thuẫn với nguồn canonical mới]
    I --> J[Lỗi build, test sai hoặc vận hành sai]

Applied

Mục	Nội dung
Facts	CANONICAL_DATA_DICTIONARY tại v0.9.0, IN_REVIEW, là nguồn canonical cho định nghĩa dữ liệu logic Nova Foods. Một trường mô phỏng được đổi từ “ngày dự kiến giao” sang “ngày giao thực tế”.
Current Behavior	Artifact phụ thuộc vẫn diễn đạt trường đó là ngày dự kiến. API trả dữ liệu theo nghĩa mới, còn test case kiểm tra theo nghĩa cũ.
Underlying Need	Giữ cùng một nghĩa dữ liệu xuyên suốt requirement, thiết kế tích hợp và kiểm thử; tránh một tên trường có hai cách hiểu.
Options	(1) Sửa im lặng dictionary. (2) Ghi thay đổi có kiểm soát, xác định artifact bị ảnh hưởng, rồi cập nhật từng artifact.
Decision Criteria	Có giữ được ID canonical, version, lịch sử thay đổi, nguồn sự thật duy nhất, quyền review và khả năng chứng minh vì sao test thay đổi không.
Decision	Chọn (2). Không tạo bản sao định nghĩa trường trong artifact phụ thuộc; artifact phụ thuộc chỉ tham chiếu CANONICAL_DATA_DICTIONARY và ghi tác động riêng của nó.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết và lịch sử. Business Owner xác nhận nghĩa nghiệp vụ; Architect xác nhận hợp đồng API; QA xác nhận test basis. Không vai trò nào được suy diễn approval từ trạng thái IN_REVIEW.
Artifact	/01-curriculum/CANONICAL_DATA_DICTIONARY.md; các artifact phụ thuộc phải ghi phiên bản nguồn đã dùng và trạng thái đánh giá tác động.
Consequence if Wrong	Báo cáo có thể gọi ngày giao thực tế là ngày cam kết; API consumer tính SLA sai; TC có thể “pass” nhưng xác nhận hành vi không đúng; truy vết không chứng minh được lỗi bắt đầu từ đâu.

Senior Lens

Không phải mọi thay đổi đều cùng mức nguy hiểm. Đổi chính tả mô tả có thể chỉ cần review biên tập. Đổi ID, nghĩa business rule, kiểu dữ liệu, giá trị cho phép, quyền truy cập, điều kiện acceptance hoặc HTTP contract có thể làm đứt liên kết giữa nhu cầu, requirement, API và test. Lý do: các artifact sau dùng artifact trước làm test basis hoặc nguồn diễn giải.

Loại thay đổi nguồn	Kiểm tra bắt buộc	Nếu bỏ qua
Đổi persistent ID	Tất cả liên kết đến ID cũ, registry và lịch sử thay đổi	Liên kết chết hoặc trỏ nhầm đối tượng
Đổi nghĩa business rule	Requirement, acceptance criteria, test case và tài liệu vận hành mô phỏng	Build đúng kỹ thuật nhưng sai nghiệp vụ
Đổi trường hoặc kiểu dữ liệu	Data dictionary, API contract, mapping, validation và TC	Mất dữ liệu, lỗi tích hợp hoặc kiểm thử sai
Đổi trạng thái nguồn từ IN_REVIEW	Không tự nâng mức tin cậy của artifact phụ thuộc	Nhầm review với baseline hoặc approval
Đổi nguồn pháp lý hoặc chuẩn	Nhãn Verification required, owner có thẩm quyền và các requirement dẫn xuất	Diễn đạt giả định như nghĩa vụ pháp lý hay tuân thủ

Quick Reference

Quy tắc	Áp dụng
Nguồn canonical đổi trước, artifact phụ thuộc đánh giá sau	Không copy định nghĩa sang nhiều tệp
Không sửa im lặng	Ghi version, ngày 2026-08-07, trạng thái và lý do thay đổi theo Asia/Ho_Chi_Minh
Không dùng IN_REVIEW làm bằng chứng phê duyệt	IN_REVIEW không phải baseline, approval hay production-ready
Không suy diễn chuyên môn ngoài thẩm quyền	Legal, Accounting, Security, Architect, QA và Business Owner xác nhận phần thuộc vai trò họ
Không thể đánh giá tác động thì dừng	Giữ nhãn Verification required; không biến khoảng trống thành rule Nova Foods

10. Common Mistakes & Anti-patterns

Core

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp. Sai lầm BA mới và delivery team thường không nằm ở việc thiếu tài liệu, mà ở việc tài liệu không giúp người nhận biết phải xây gì, ai quyết định, hoặc kiểm thử theo điều kiện nào.

Sai lầm cụ thể	Red flag quan sát được	Nguyên nhân gốc	Hành động sửa
Ghi nhu cầu như giải pháp	“Cần thêm nút duyệt đơn” nhưng không nêu vấn đề nghiệp vụ	Nhầm yêu cầu nghiệp vụ với thiết kế giao diện	Viết lại theo cấu trúc: vấn đề, người bị ảnh hưởng, kết quả cần đạt, tiêu chí đo
Gom nhiều quyết định vào một requirement	Một dòng chứa tạo đơn, duyệt tín dụng, xuất kho và in hóa đơn	Muốn viết nhanh, không tách phạm vi quyết định	Tách requirement theo hành vi kiểm chứng được; liên kết dependency giữa chúng
Dùng từ không đo được	“Hệ thống chạy nhanh”, “dễ dùng”, “đủ bảo mật”	Thiếu tiêu chí quan sát hoặc ngưỡng chấp nhận	Đổi thành điều kiện đo được, ví dụ thời gian phản hồi, vai trò truy cập, thông báo lỗi
Sao chép mô tả giữa nhiều artifact	Cùng một rule xuất hiện khác chữ trong BRD, API và test case	Không xác định nguồn canonical	Giữ rule tại nguồn canonical; artifact khác chỉ tham chiếu ID và phiên bản
Chuyển assumption thành fact	“Nova Foods bắt buộc lưu dữ liệu trong 10 năm” không có nguồn và owner xác nhận	Suy diễn từ kinh nghiệm cũ hoặc nguồn không kiểm chứng	Gắn Verification required, ghi nguồn cần kiểm tra, chuyển cho Legal hoặc Accounting Owner
Bỏ qua người dùng ngoại lệ	Flow chỉ có nhân viên bán hàng thành công; không có đơn bị từ chối hoặc mất kết nối	Tập trung happy path, tức luồng thành công lý tưởng	Bổ sung luồng lỗi, điều kiện chặn, thông báo và chủ thể xử lý tiếp
Viết acceptance criteria sau khi build	Dev hỏi lại nhiều lần, QA tự đoán expected result	Requirement không đủ làm test basis	Viết acceptance criteria cùng requirement, trước khi cam kết build
Gọi review là approval	Tài liệu ghi IN_REVIEW nhưng team nói “đã được chốt”	Không hiểu khác biệt giữa trạng thái tài liệu và quyết định có thẩm quyền	Giữ đúng IN_REVIEW; chỉ ghi approval khi có bằng chứng được ghi nhận từ vai trò có thẩm quyền

Cảnh báo: Sai requirement về duyệt tín dụng hoặc xuất kho có thể cho phép giao hàng vượt kiểm soát mô phỏng. Không dùng tài liệu IN_REVIEW làm lệnh cấu hình ERP, quyết định kế toán, hoặc xác nhận pháp lý.

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

flowchart TB
    A[Rà soát requirement và evidence]

    A --> B{Red flag hoặc thiếu sót nào?}

    B -- "Ghi nhu cầu như giải pháp" --> C[Viết lại: vấn đề, người bị ảnh hưởng,<br/>kết quả cần đạt, tiêu chí đo]
    B -- "Gom nhiều quyết định" --> D[Tách theo hành vi kiểm chứng được<br/>và liên kết dependency]
    B -- "Không đo được" --> E[Đổi thành điều kiện<br/>và ngưỡng chấp nhận đo được]
    B -- "Thiếu acceptance criteria;<br/>Dev hỏi lại, QA tự đoán" --> F[Viết acceptance criteria<br/>trước khi cam kết build]
    B -- "Rule bị sao chép khác chữ" --> G[Giữ rule tại nguồn canonical;<br/>nơi khác tham chiếu ID và phiên bản]
    B -- "Assumption không có nguồn<br/>và owner xác nhận" --> H[Gắn Verification required]
    H --> I[Chuyển Legal hoặc Accounting Owner<br/>theo nội dung cần xác minh]
    B -- "Bỏ qua luồng ngoại lệ" --> J[Bổ sung luồng lỗi, điều kiện chặn,<br/>thông báo và chủ thể xử lý tiếp]
    B -- "Không phát hiện thiếu sót" --> L[Giữ requirement cùng dependency,<br/>test basis và artifact áp dụng]

    C --> U[Cập nhật artifact liên quan]
    D --> U
    E --> U
    F --> U
    I --> U
    J --> U

    A --> M{Có bằng chứng approval<br/>từ vai trò có thẩm quyền?}
    M -- Có --> N[Ghi nhận approval]
    M -- Không --> O[Giữ trạng thái IN_REVIEW]
    O --> P[Không dùng để cấu hình ERP,<br/>quyết định kế toán<br/>hoặc xác nhận pháp lý]

    A --> Q{Requirement duyệt tín dụng<br/>hoặc xuất kho sai?}
    Q -- Có --> R[Rủi ro: giao hàng vượt<br/>kiểm soát mô phỏng]
    Q -- Không --> S[Tiếp tục rà soát]

Applied

Trường	Nội dung
Facts	Trong case Nova Foods mô phỏng, requirement ghi: “ERP tự động duyệt đơn bán hàng khách hàng tốt.”
Current Behavior	Developer không biết “khách hàng tốt” là gì; QA không tạo được expected result; Sales tự hiểu theo doanh số tháng.
Underlying Need	Sales cần giảm thời gian xử lý đơn, nhưng vẫn chặn đơn có rủi ro tín dụng theo quyết định nghiệp vụ có thẩm quyền.
Options	1. Build theo cách hiểu của developer. 2. Chờ làm rõ điều kiện và owner. 3. Gắn một ngưỡng tiền cụ thể do BA tự chọn.
Decision Criteria	Điều kiện phải quan sát được; có Business Owner xác nhận; không suy diễn chính sách tín dụng; QA tạo được test data tổng hợp.
Decision	Chọn phương án 2. Giữ requirement ở trạng thái chưa đủ điều kiện triển khai; ghi câu hỏi làm rõ và Verification required.
Authority	Business Owner quyết định chính sách nghiệp vụ; Accounting Owner hoặc vai trò tín dụng phù hợp xác nhận ngưỡng; BA duy trì traceability.
Artifact	Requirement, decision log và liên kết tới CANONICAL_BUSINESS_RULES khi rule được đăng ký hợp lệ.
Consequence if Wrong	Đơn có thể được duyệt sai, hàng mô phỏng bị xuất sai, báo cáo công nợ mô phỏng sai và test case kiểm tra nhầm hành vi.

Ranh giới khôi phục an toàn: không sửa thầm câu requirement rồi tiếp tục build. Dừng phần quyết định bị thiếu, giữ dữ liệu tổng hợp, ghi evidence hiện có, xác định owner quyết định và đánh giá artifact phụ thuộc trước khi thay đổi.

Senior Lens

Senior BA tìm dấu hiệu “không thể kiểm chứng” thay vì chỉ sửa câu chữ. Nếu developer, QA và business đọc cùng requirement nhưng đưa ra ba hành vi khác nhau, requirement chưa đủ làm nguồn chung. Evidence là khác biệt cách diễn giải; kết luận là cần làm rõ trước khi tạo cam kết delivery.

Không dùng kinh nghiệm dự án trước để lấp chỗ trống Nova Foods. Kinh nghiệm chỉ tạo giả thuyết cần kiểm tra. Nó không tạo rule, approval, baseline, nghĩa vụ pháp lý, quyết định kế toán hoặc quyền thay đổi production.

Quick Reference

Quy tắc	Cách áp dụng
Mỗi requirement phải kiểm chứng được	Nêu điều kiện, hành vi và kết quả quan sát được
Không biết owner quyết định thì không chốt nội dung	Ghi Verification required và chuyển đúng vai trò
Một thay đổi phải có điểm truy vết	Kiểm tra requirement, rule, data, API và test artifact bị ảnh hưởng
IN_REVIEW không phải approval	Không dùng trạng thái tài liệu thay cho bằng chứng thẩm quyền
Không đoán thay business	BA ghi rõ lựa chọn và evidence; owner có thẩm quyền quyết định

Core

[!WARNING] Chỉ dùng cảnh báo khi lỗi có thể gây sai dữ liệu, dừng vận hành, vi phạm phân quyền, mất dấu truy vết hoặc phát hành sai. Cảnh báo giả làm người đọc bỏ qua cảnh báo thật.

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dữ liệu tổng hợp. Cảnh báo phải nêu đủ: sự kiện nguy hiểm, dữ liệu hoặc quyết định bị ảnh hưởng, ranh giới khôi phục an toàn, vai trò có thẩm quyền xác nhận tiếp tục. Không viết cảnh báo cho lỗi trình bày, ưu tiên cá nhân hoặc nội dung chưa hoàn chỉnh nhưng chưa tạo rủi ro vận hành.

Mức	Dấu hiệu dùng	Hành động bắt buộc
WARNING	Có thể ghi sai, xóa sai, phát hành sai, lộ dữ liệu, mất traceability	Chặn bước chịu ảnh hưởng; giữ bằng chứng; chuyển đúng owner
Ghi chú thường	Cần làm rõ nhưng chưa tạo tác động không đảo ngược	Ghi câu hỏi và theo dõi trong artifact
Không ghi cảnh báo	Khác biệt văn phong hoặc bố cục	Sửa trực tiếp theo quy ước tài liệu

Applied

Facts: Trong mô phỏng Nova Foods, BA ghi “ERP tự động xuất phiếu xuất kho khi đơn bán hàng được xác nhận”. Không có Artifact ID, nguồn quyết định, quy tắc nghiệp vụ canonical, hay xác nhận từ Business Owner và Accounting Owner.

Current Behavior: Dev chuẩn bị nối trạng thái xác nhận đơn bán hàng với lệnh xuất kho. QA dùng câu trên làm test basis. Đây là điểm phát hành có thể tạo giao dịch kho sai.

Underlying Need: Cần ngăn phát hành luồng tự động khi quyền quyết định, điều kiện tồn kho và điều kiện chứng từ chưa được xác minh.

Options:

Option	Lợi ích	Rủi ro
Tiếp tục theo câu mô tả	Nhanh	Tạo xuất kho sai từ giả định chưa được xác nhận
Chuyển thành cảnh báo có chặn	Bảo toàn dữ liệu và traceability	Chậm bước phát hành chịu ảnh hưởng
Xóa câu mô tả	Loại bỏ suy diễn	Mất vấn đề cần xử lý

Decision Criteria: Chọn phương án nào ngăn ghi dữ liệu vận hành từ nội dung IN_REVIEW, giữ được nguồn gốc quyết định, không tự gán thẩm quyền nghiệp vụ hoặc kế toán.

Decision: Dùng WARNING; chặn cấu hình hoặc test phát hành cho luồng xuất kho tự động. Giữ câu mô tả như giả định cần xác minh, không đổi thành business rule.

Authority: Business Owner xác nhận chính sách xuất kho; Accounting Owner xác nhận tác động chứng từ; Architect xác nhận thiết kế tích hợp; QA xác nhận test basis. Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì traceability.

Artifact: Ghi vấn đề vào /02-handbook/02-stakeholders-domain-and-context.md; liên kết đúng CANONICAL_BUSINESS_RULES, TRACEABILITY_ID_REGISTRY và trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07.

Consequence if Wrong: Hệ thống mô phỏng có thể tạo xuất kho khi chưa đủ điều kiện. Khôi phục an toàn chỉ gồm: dừng job hoặc endpoint chịu ảnh hưởng, cô lập giao dịch tổng hợp chưa phát hành, đối chiếu log với dữ liệu kho mô phỏng, và chờ owner có thẩm quyền quyết định xử lý. Không tự xóa, tự đảo giao dịch, hoặc tuyên bố đã tuân thủ pháp lý hay kế toán.

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

flowchart TB
    A[Phát hiện giả định ảnh hưởng phát hành] --> B{Có thể ghi sai dữ liệu vận hành hoặc mất traceability?}
    B -- Không --> C[Ghi chú thường và theo dõi]
    B -- Có --> D[WARNING: chặn cấu hình hoặc test phát hành cho luồng xuất kho tự động]

    D --> E[Ghi vấn đề vào /02-handbook/02-stakeholders-domain-and-context.md<br/>Trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07]
    E --> F[Giữ nội dung là giả định cần xác minh<br/>Liên kết CANONICAL_BUSINESS_RULES và TRACEABILITY_ID_REGISTRY]

    F --> BO[Business Owner xác nhận chính sách xuất kho]
    F --> AO[Accounting Owner xác nhận tác động chứng từ]
    F --> AR[Architect xác nhận thiết kế tích hợp]
    F --> QA[QA xác nhận test basis]

    BO --> G{Đủ điều kiện phát hành?<br/>Có Artifact ID và nguồn quyết định<br/>Đã xác minh điều kiện tồn kho và chứng từ<br/>Đủ xác nhận của Business Owner, Accounting Owner, Architect và QA}
    AO --> G
    AR --> G
    QA --> G

    G -- Chưa đủ --> D
    G -- Đủ --> H[Cập nhật traceability và kiểm tra lại]
    H --> I{Kiểm tra lại đạt đủ điều kiện?}
    I -- Không --> D
    I -- Có --> J[Cho phép cấu hình hoặc test phát hành cho luồng xuất kho tự động]

    J -. Nếu quyết định sai .-> R[Có thể tạo xuất kho khi chưa đủ điều kiện]
    R --> S[Dừng job hoặc endpoint chịu ảnh hưởng]
    S --> U[Chỉ cô lập giao dịch tổng hợp chưa phát hành<br/>Đối chiếu log với dữ liệu kho mô phỏng]
    U --> K[Chờ owner có thẩm quyền quyết định cách xử lý]
    K --> T[Không tự xóa hoặc tự đảo giao dịch<br/>Không tuyên bố đã tuân thủ pháp lý hoặc kế toán]

Senior Lens

Ranh giới khôi phục không phải kế hoạch sửa toàn hệ thống. Mục tiêu đầu tiên là ngăn tác động mở rộng và giữ bằng chứng. Nếu lỗi đã đi qua ranh giới không đảo ngược, như đã phát hành chứng từ hoặc đã đồng bộ sang hệ khác, BA không được tự quy định cách đảo giao dịch. Escalate theo thẩm quyền nghiệp vụ, kế toán, pháp lý hoặc kỹ thuật.

[!WARNING] Không gọi IN_REVIEW là đã phê duyệt, đã baseline, compliant hoặc sẵn sàng production. Suy diễn này có thể biến tài liệu học liệu thành chỉ dẫn vận hành không có thẩm quyền.

Quick Reference

Kiểm tra trước khi viết WARNING	Đạt khi
Rủi ro thật?	Có hậu quả cụ thể nếu tiếp tục
Phạm vi chặn rõ?	Nêu job, API, cấu hình, test hoặc phát hành bị dừng
Khôi phục an toàn?	Nêu cô lập, đối chiếu, bằng chứng và escalation
Thẩm quyền rõ?	Không gán quyết định cho BA hoặc Owner artifact
Traceability giữ nguyên?	Dùng đúng ID, filename, status và version canonical

Core

Năm lỗi phải tách riêng vì mỗi lỗi cần cách sửa và người xác nhận khác nhau. Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; không có nội dung nào dưới đây là rule vận hành hay xác nhận tuân thủ.

Loại lỗi	Dấu hiệu quan sát được	Vì sao lỗi	Sửa trong artifact
Mơ hồ (ambiguity)	“Duyệt đơn nhanh”, “lô gần hết hạn”, “quản lý xác nhận”	Từ ngữ có nhiều cách hiểu, không có điều kiện đo được	Thay bằng actor, điều kiện, dữ liệu, thời hạn và kết quả
Không đầy đủ (incompleteness)	Có happy path nhưng không có lỗi, ngoại lệ, đầu vào bắt buộc hoặc đầu ra	Nhóm mới chỉ mô tả việc thường xảy ra	Bổ sung trigger, precondition, alternate flow, error flow, dữ liệu và acceptance criteria
Khẳng định thẩm quyền không có bằng chứng	“Legal đã yêu cầu”, “Kế toán đã phê duyệt” nhưng không có record	BA biến suy luận hoặc trao đổi miệng thành quyết định	Gắn Verification required, nêu owner có thẩm quyền và tham chiếu record khi có
Dùng sai ký pháp (notation misuse)	Gọi sơ đồ PlantUML là BPMN; mũi tên không rõ event hay data flow	Người đọc suy diễn sai hành vi hệ thống	Ghi đúng loại sơ đồ, legend, phạm vi; dùng BPMN 2.0.2 chỉ khi tuân thủ ký pháp BPMN
Đứt truy vết (traceability break)	Requirement không nối nguồn, rule, test basis hoặc quyết định	ID bị đổi, copy nội dung không giữ liên kết canonical	Giữ ID nguyên dạng, liên kết artifact canonical, ghi trạng thái nguồn

Quy tắc viết requirement: một câu phải trả lời được “ai làm gì, khi nào, với dữ liệu nào, hệ thống phản hồi gì”. Ví dụ mơ hồ: “ERP cảnh báo lô sắp hết hạn.” Ví dụ kiểm tra được: “Khi người dùng tạo phiếu xuất kho, hệ thống hiển thị cảnh báo nếu ExpiryDate của lô được chọn sớm hơn ngày xuất dự kiến; ngưỡng cảnh báo là Verification required từ Business Owner và Food-safety Owner.” Bằng chứng cho nhãn này: seed nguồn chỉ nêu Luật An toàn thực phẩm là bối cảnh truy xuất/thu hồi và yêu cầu xác minh domain-owner, không cung cấp ngưỡng ngày cho Nova Foods.

[!WARNING] Khẳng định “đã được Legal, Kế toán hoặc Business Owner phê duyệt” khi không có approval reference tạo rủi ro quyết định sai và che mất người chịu trách nhiệm. IN_REVIEW tại v0.9.0, ngày 2026-08-07, không phải APPROVED hoặc BASELINED.

Applied

Facts: Trong Nova Foods mô phỏng, ghi chú REQ-INV-014 nêu: “Chỉ xuất lô còn hạn và quản lý kho duyệt.” Artifact hiện có là /01-curriculum/CANONICAL_BUSINESS_RULES.md, trạng thái IN_REVIEW, v0.9.0; chưa có baseline reference hoặc approval reference.

Current Behavior: Team vẽ PlantUML activity diagram, ghi tiêu đề “BPMN xuất kho”, rồi nối REQ-INV-014 trực tiếp tới test case. Sơ đồ không nêu ngày xuất dự kiến, cách xác định “còn hạn”, manager nào, hay hành vi khi không còn lô hợp lệ.

Underlying Need: Cần tách rule logic, thẩm quyền duyệt và ký pháp sơ đồ để QA có test basis, Architect không suy diễn integration, Business Owner không bị gán quyết định chưa xác nhận.

Mục	Nội dung xử lý
Options	1. Giữ nguyên ghi chú. 2. Viết requirement có nhãn Verification required. 3. Tuyên bố rule đã được phê duyệt
Decision Criteria	Kiểm tra được; giữ đúng nguồn canonical; không vượt thẩm quyền; không gọi sai notation
Decision	Chọn option 2
Authority	Business Owner xác nhận chính sách xuất kho; Food-safety Owner xác nhận tiêu chí hạn dùng; Legal Owner xác minh nghĩa vụ pháp lý nếu rule viện dẫn luật; BA duy trì liên kết và trạng thái
Artifact	REQ-INV-014; /01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md; sơ đồ PlantUML ghi rõ “activity diagram, không phải BPMN”
Consequence if Wrong	Kho có thể chặn xuất hàng không có căn cứ, hoặc cho phép xuất lô sai chính sách; test pass vẫn không chứng minh rule đúng

Biểu diễn truy vết tối thiểu:

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

flowchart TB
    S["Nguồn quan sát được:<br/>ghi chú workshop mô phỏng"] --> R["REQ-INV-014<br/>Status: Verification required"]
    R --> B["/01-curriculum/CANONICAL_BUSINESS_RULES.md<br/>IN_REVIEW v0.9.0"]
    R --> T["/01-curriculum/TRACEABILITY_ID_REGISTRY.md<br/>duy trì ID và liên kết truy vết"]

    B --> BS["Baseline reference:<br/>chưa tồn tại"]
    B --> AS["Approval reference:<br/>chưa tồn tại"]
    R --> AC["Acceptance criteria / test basis:<br/>chưa được tạo"]

    R --> Q["Câu hỏi quyết định cần xác minh"]
    Q --> Q1["Ngày xuất dự kiến là ngày nào?"]
    Q --> Q2["Xác định còn hạn theo tiêu chí nào?"]
    Q --> Q3["Manager nào có thẩm quyền duyệt?"]
    Q --> Q4["Làm gì khi không còn lô hợp lệ?"]

    Q1 --> BO["Business Owner<br/>xác nhận chính sách xuất kho"]
    Q3 --> BO
    Q4 --> BO
    Q2 --> FS["Food-safety Owner<br/>xác nhận tiêu chí hạn dùng"]

    BO --> C["Tổng hợp trạng thái xác nhận<br/>từ Business Owner và Food-safety Owner"]
    FS --> C
    C --> V{"Đủ xác nhận<br/>từ cả hai owner?"}

    V -->|"Chưa / không xác nhận"| VF["Giữ IN_REVIEW<br/>không tạo acceptance criteria / test basis<br/>không suy diễn chính sách xuất kho"]
    VF --> R

    V -->|"Đủ xác nhận"| LAW{"Rule có viện dẫn luật?"}
    LAW -->|"Không"| LC["Kiểm tra pháp lý:<br/>không áp dụng"]
    LAW -->|"Có"| LO["Legal Owner<br/>xác minh nghĩa vụ pháp lý"]
    LO --> LD{"Nghĩa vụ pháp lý<br/>được đáp ứng?"}

    LD -->|"Không"| LF["Ghi nhận điểm chưa đáp ứng<br/>giữ IN_REVIEW và yêu cầu xử lý"]
    LF --> R
    LD -->|"Có"| LC

    LC --> G["Nội dung đã được xác nhận<br/>và không còn điểm pháp lý chưa đáp ứng"]
    G --> W["Chờ quy trình phê duyệt hoặc baseline<br/>được xác định bằng căn cứ có thẩm quyền"]

    BA["BA<br/>duy trì liên kết và trạng thái;<br/>không phê duyệt nội dung"] -. "duy trì requirement" .-> R
    BA -. "duy trì trạng thái artifact" .-> B
    BA -. "duy trì ID và liên kết" .-> T
    BA -. "chỉ ghi nhận khi có bằng chứng<br/>từ quy trình có thẩm quyền" .-> AS
    BA -. "chỉ ghi nhận khi có bằng chứng<br/>từ quy trình có thẩm quyền" .-> BS

    R --> X["Ranh giới an toàn:<br/>không suy đoán ngưỡng hạn dùng;<br/>không đổi ID để che liên kết hỏng;<br/>không tạo approval reference"]
    X --> K["Nếu suy diễn hoặc xác nhận sai:<br/>chặn xuất hàng không có căn cứ,<br/>hoặc cho xuất lô sai chính sách;<br/>test pass không chứng minh rule đúng"]

Ranh giới phục hồi an toàn: không sửa ngưỡng hạn dùng bằng suy đoán; không đổi REQ-INV-014 để che liên kết hỏng; không tạo approval reference. Khôi phục bằng cách ghi nguồn thực tế quan sát được, tách câu mơ hồ thành câu hỏi quyết định, gắn Verification required, rồi gửi đúng owner.

Senior Lens

“Mơ hồ” khác “không đầy đủ”. Mơ hồ có dữ kiện nhưng nhiều nghĩa, như “quản lý kho”. Không đầy đủ thiếu dữ kiện bắt buộc, như không có hành vi khi lô hết hạn. Sửa mơ hồ bằng định nghĩa; sửa không đầy đủ bằng coverage flow và data condition.

“Khẳng định thẩm quyền không có bằng chứng” không phải lỗi thiếu chi tiết. Đây là lỗi governance. Câu “theo luật phải lưu 10 năm” phải giữ Verification required nếu chưa đối chiếu văn bản hiện hành và chưa có Legal hoặc Accounting Owner xác nhận. Verified source seed cho phép dùng Luật Kế toán làm nguồn pháp lý, nhưng không trao cho BA quyền diễn giải thời hạn lưu giữ.

“Ký pháp sai” không tự làm business rule sai, nhưng làm người dùng đọc sai artifact. BPMN 2.0.2 là nguồn normative cho BPMN; PlantUML activity diagram là sơ đồ hoạt động, không được gắn nhãn BPMN. Nếu cần mô tả nhanh luồng học liệu, dùng PlantUML hoặc Mermaid và ghi đúng tên. Nếu cần BPMN cho delivery, tạo BPMN hợp lệ và review notation riêng.

“Đứt truy vết” thường xuất hiện sau copy-paste: requirement đổi tên, rule giữ ID cũ, test chỉ còn text tự do. Bằng chứng truy vết đạt là liên kết kiểm tra được giữa nguồn, requirement, rule, acceptance criteria và test basis; không phải việc các tài liệu dùng từ giống nhau.

Quick Reference

Kiểm tra trước khi ghi artifact	Đạt khi
Câu có thể test?	Có actor, trigger, điều kiện, kết quả
Nội dung có đủ?	Có ngoại lệ và lỗi liên quan, không chỉ happy path
Có claim authority?	Có approval reference hợp lệ, hoặc giữ Verification required
Tên sơ đồ đúng?	BPMN chỉ dùng cho BPMN; Mermaid/PlantUML ghi đúng loại
ID còn canonical?	Giữ nguyên REQ-INV-014, artifact ID và đường dẫn đã đăng ký
Trạng thái bị diễn giải sai?	IN_REVIEW vẫn được ghi là IN_REVIEW; không gọi baseline hay approval

11. Senior BA Notes & Rules of Thumb

Senior Lens

Senior BA không chọn phương án “được nhiều người thích nhất”. Senior BA chọn khuyến nghị có bằng chứng đủ mạnh, đúng thẩm quyền, rủi ro còn lại được thấy rõ. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi ví dụ dùng dữ liệu tổng hợp, không xác nhận cấu hình ERP hay quyết định vận hành thực.

Tình huống xung đột	Trade-off cần thấy	Bằng chứng cần kiểm tra	Ai quyết định	Cách ghi nhận
Kho muốn cho phép sửa số lượng sau khi xuất kho; Finance muốn khóa	Linh hoạt sửa lỗi đối đầu audit trail và đối soát tồn kho	Luồng hiện tại, lỗi thực tế đã ghi nhận, tác động sổ sách, khả năng reversal	Business Owner và Accounting Owner; Architect xác nhận khả năng kỹ thuật	Ghi hai option, rủi ro từng option, Verification required cho diễn giải kế toán
Sales muốn API trả toàn bộ thông tin khách hàng cho đối tác giao hàng	Tốc độ tích hợp đối đầu giảm thiểu dữ liệu và bảo mật	Data field list, mục đích sử dụng, đối tượng nhận, quyền truy cập, đánh giá Security/Legal	Security Owner và Legal Owner; Business Owner xác nhận mục đích	Không gọi là “tuân thủ”; ghi nguồn luật tham chiếu và chờ xác minh chuyên môn
QA yêu cầu chặn tạo hóa đơn khi thiếu mã lô; Operations muốn cho phép nhập sau	Chặn lỗi sớm đối đầu gián đoạn vận hành	Mức độ bắt buộc của mã lô, điểm phát sinh dữ liệu, tình huống ngoại lệ, khả năng truy vết	Food-safety/domain owner; Legal Owner khi có nghĩa vụ pháp lý	Tách rule nghiệp vụ, giả định dự án và câu hỏi cần xác minh

Chất lượng bằng chứng quyết định độ mạnh của khuyến nghị. Quan sát một người dùng thao tác là bằng chứng về hành vi đang thấy, không đủ để kết luận đó là quy tắc toàn doanh nghiệp. Báo cáo lỗi có timestamp và mẫu giao dịch giúp chứng minh tần suất. Văn bản từ nguồn chính thức hỗ trợ bối cảnh pháp lý, nhưng BA không tự suy diễn nghĩa vụ chi tiết nếu chưa có Legal Owner, Accounting Owner hoặc domain owner xác nhận. IN_REVIEW tại v0.9.0 ngày 2026-08-07 chỉ nói artifact đang được xem xét; không phải baseline, approval hay quyền áp dụng production.

Khi stakeholder mâu thuẫn, Senior BA không “hòa giải” bằng cách trộn hai yêu cầu thành câu mơ hồ. Tách rõ: fact đã quan sát, lợi ích từng bên, rủi ro, assumption, quyết định cần có và người có decision authority, tức thẩm quyền ra quyết định. Ví dụ: “Kho nói cần sửa trực tiếp” là stakeholder input; “ERP phải cho sửa trực tiếp” chưa là requirement. Cầu nối hợp lệ là bằng chứng cho lỗi cần sửa, phạm vi giao dịch, tác động tồn kho, và xác nhận của người sở hữu quyết định.

Ngoại lệ áp dụng khi quy tắc bình thường làm tăng rủi ro lớn hơn lợi ích. Quy tắc bình thường là không thiết kế ngoại lệ trước khi hiểu happy path. Không áp dụng quy tắc này nếu failure mode có hậu quả cao: mất traceability lô hàng, lộ dữ liệu cá nhân, sai lệch sổ sách, hoặc mất dữ liệu không thể khôi phục. Khi đó, Senior BA yêu cầu mô tả exception trước: trigger, quyền kích hoạt, dữ liệu được đổi, audit log, rollback hoặc reversal, và người chịu trách nhiệm.

Khuyến nghị phòng thủ được khi người đọc kiểm tra lại được đường suy luận. Mẫu ghi nhận ngắn: “Khuyến nghị chọn Option B: khóa sửa trực tiếp sau xuất kho, cho phép reversal có quyền. Bằng chứng: Finance nêu nhu cầu đối soát; Operations nêu lỗi nhập nhầm; chưa có bằng chứng xác nhận sửa trực tiếp là bắt buộc. Rủi ro còn lại: thời gian xử lý reversal. Cần Accounting Owner và Business Owner quyết định. Trạng thái: Verification required.” Cách viết này nói rõ điều chưa biết, không bịa chắc chắn, không gán approval cho bất kỳ vai trò nào.

Senior Lens

Senior BA review theo bốn câu hỏi: bằng chứng có truy nguyên được không, người nêu ý kiến có thẩm quyền quyết định không, tác động sai có đảo ngược được không, và quy tắc có vượt ranh giới pháp lý, kế toán, an toàn thực phẩm, bảo mật hoặc kiến trúc không. Ví dụ, quản lý kho nói “phải chặn xuất hàng khi thiếu lô”. Đây là bằng chứng về vấn đề vận hành, chưa đủ chứng minh quy tắc ERP. Cần đối chiếu mẫu phiếu xuất, tỷ lệ lỗi, luồng phê duyệt và ý kiến Business Owner. Suy luận là: nhiều nguồn độc lập cùng chỉ ra cùng rủi ro thì độ tin cậy tăng; một ý kiến đơn lẻ chỉ là giả thuyết cần xác minh.

Tín hiệu review	Heuristic senior	Red flag	Ngưỡng escalation	Ngoại lệ không áp dụng quy tắc thường
Nguồn yêu cầu	Ưu tiên artifact có ID, ngày, owner, phiên bản và bối cảnh sử dụng.	Ảnh chụp màn hình, trao đổi miệng, bảng tính không rõ owner bị gọi là “nguồn chân lý”.	Hai nguồn canonical mâu thuẫn, hoặc không xác định được owner.	Sự cố vận hành khẩn cấp cần ghi nhận tạm thời; vẫn phải gắn Verification required và chuyển quyết định cho đúng owner.
Thẩm quyền	Người hiểu công việc không mặc nhiên có quyền quyết định chính sách.	BA nhận “đồng ý” từ người dùng rồi ghi thành phê duyệt.	Quyết định ảnh hưởng giá, hạch toán, dữ liệu cá nhân, truy xuất lô, quyền truy cập hoặc tích hợp.	Prototype học liệu Nova Foods mô phỏng có thể nêu giả định, không được gọi là rule vận hành.
Phạm vi tác động	Kiểm tra tác động xuyên quy trình trước khi chốt yêu cầu cục bộ.	Một màn hình sửa được quy tắc dùng bởi kho, bán hàng và kế toán.	Tác động từ hai domain trở lên, hoặc thay đổi API, dữ liệu canonical, phân quyền.	Thay đổi chỉ là nhãn giao diện, không đổi dữ liệu, hành vi, báo cáo hay truy vết.
Chất lượng bằng chứng	Tách fact, giả định, suy luận và quyết định.	“Người dùng luôn làm vậy” không có mẫu giao dịch hay số liệu.	Bằng chứng không lặp lại được, dữ liệu thiếu kỳ, hoặc mẫu quá nhỏ để đại diện.	Không cần số liệu lịch sử khi yêu cầu là lỗi kỹ thuật có log tái tạo được.
Rủi ro sai	Quy tắc càng khó đảo ngược, chuẩn chứng minh càng cao.	Ghi đè lịch sử, xóa chứng từ, mở quyền rộng, tự động hạch toán.	Có thể mất dữ liệu, sai số tiền VND, lộ dữ liệu, mất khả năng truy xuất hoặc vi phạm nghĩa vụ cần xác minh.	Không áp dụng “đi nhanh” nếu hậu quả sai không thể sửa bằng bút toán, audit trail hoặc quy trình phục hồi.

Không dùng quy tắc “đa số stakeholder đồng ý thì chốt” khi vấn đề thuộc quyền chuyên môn hoặc quyền kiểm soát riêng. Ví dụ, đa số vận hành muốn hiển thị toàn bộ số điện thoại khách hàng cho kho để gọi giao hàng. Nhu cầu giao hàng là hợp lý, nhưng phạm vi dữ liệu và quyền truy cập cần Security, Legal/Privacy Owner xác minh theo nguồn pháp lý hiện hành; ý kiến đa số không thay thế thẩm quyền này. Với Nova Foods mô phỏng, ghi nhận đây là Verification required, không kết luận tuân thủ.

Escalation phải kích hoạt khi có một trong các điều kiện: không có người quyết định được chỉ định; stakeholder yêu cầu BA chọn thay chính sách; hai vai trò có mục tiêu đối nghịch không tự giải quyết được; đề xuất sửa canonical ID, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY hoặc nguồn nghiệp vụ canonical; hoặc yêu cầu bị diễn đạt như nghĩa vụ pháp lý, kế toán, thuế, an toàn thực phẩm hay bảo mật nhưng chưa có xác minh từ owner có thẩm quyền. BA lập issue log gồm câu hỏi quyết định, lựa chọn, bằng chứng, tác động, owner cần quyết và hạn chót; BA không tự gán kết quả.

Senior Lens

Senior BA không viết “đã xác nhận” khi bằng chứng chỉ là trao đổi miệng, ảnh chụp màn hình không định danh, hoặc suy luận từ quy trình cũ. Thay vào đó, ghi rõ mức chắc chắn, nguồn, khoảng trống và người có quyền quyết định. Ví dụ Nova Foods là case mô phỏng, dữ liệu tổng hợp: “Giả định dự án: đơn giá mua vượt 50.000.000 VND cần phê duyệt cấp quản lý. Bằng chứng hiện có: bảng tính mô phỏng NF-PRC-01 ngày 2026-08-07 nêu ngưỡng này. Chưa có quy tắc canonical trong CANONICAL_BUSINESS_RULES; cần Business Owner xác nhận trước khi dùng làm yêu cầu.” Câu này phân biệt fact, assumption và quyết định cần xác nhận; không biến giả định thành sự thật.

Khuyến nghị có thể bảo vệ được phải nối đủ chuỗi: quan sát, tác động, lựa chọn, tiêu chí, giới hạn thẩm quyền. Không viết “nên dùng phê duyệt hai cấp vì an toàn”. Viết: “Current Behavior mô phỏng cho thấy mọi đơn mua đều được một người duyệt. Rủi ro suy ra: đơn giá cao không có kiểm tra độc lập. Khuyến nghị: đánh giá phê duyệt hai cấp cho đơn vượt ngưỡng do Business Owner xác định. Lý do: giảm rủi ro quyết định đơn lẻ; chi phí đổi lại là thời gian xử lý dài hơn. Architect xác nhận khả năng cấu hình; Business Owner quyết định ngưỡng; Accounting Owner xác nhận tác động kiểm soát tài chính.” Suy luận nằm sau bằng chứng, không thay bằng chứng.

Trường ghi nhận	Cách ghi defensible	Không được ghi
Fact	“Bảng tính mô phỏng NF-PRC-01, dòng 14, ghi 50.000.000 VND.”	“Ngưỡng chuẩn là 50.000.000 VND.”
Uncertainty	“Chưa xác minh bảng tính là nguồn canonical.”	“Có lẽ đã được duyệt.”
Assumption	“Giả định dự án, chỉ dùng để minh họa luồng.”	“Quy định Nova Foods yêu cầu.”
Recommendation	“Khuyến nghị đánh giá Option B theo tiêu chí dưới đây.”	“Bắt buộc chọn Option B.”
Authority	“Business Owner quyết định chính sách; Architect xác nhận khả thi.”	“BA phê duyệt cấu hình.”
Status	“IN_REVIEW, v0.9.0, chưa có baseline hoặc approval reference.”	“Đã chốt.”

Khi dữ liệu mâu thuẫn, Senior BA không lấy ý kiến nhiều người làm đa số rồi gọi là quyết định. Ví dụ Procurement Lead mô phỏng muốn ngưỡng 50.000.000 VND để giảm chậm đơn; Finance Lead mô phỏng muốn 20.000.000 VND để tăng kiểm soát. Đây là xung đột mục tiêu, không phải lỗi ghi chép. Record phải nêu hai nguồn, tác động mỗi phương án và authority giải quyết. Nếu ngưỡng ảnh hưởng kiểm soát kế toán hoặc nghĩa vụ pháp lý, nhãn phải là Verification required; BA không diễn giải Luật Kế toán hoặc quy định thuế thay Accounting Owner hoặc Legal Owner.

Mục	Ghi nhận mô phỏng, dữ liệu tổng hợp
Facts	NF-PRC-01 nêu 50.000.000 VND; ghi chú Finance mô phỏng nêu 20.000.000 VND. Cả hai chưa là nguồn canonical.
Uncertainty	Chưa biết ngưỡng nào phù hợp loại hàng, giá trị rủi ro và thời gian xử lý mục tiêu.
Options	A: 20.000.000 VND; B: 50.000.000 VND; C: ngưỡng theo nhóm hàng.
Decision Criteria	Giảm rủi ro tài chính, thời gian phê duyệt, khả năng cấu hình ERP, khả năng kiểm toán.
Recommendation	Không khóa ngưỡng trong requirement tại IN_REVIEW. Dùng cấu hình có giá trị thử nghiệm, nếu Architect xác nhận khả thi.
Authority	Business Owner quyết định chính sách; Accounting Owner xác nhận kiểm soát tài chính; Architect xác nhận cấu hình.
Artifact	Ghi issue và liên kết traceability trong /01-curriculum/CANONICAL_BUSINESS_RULES.md; giữ IN_REVIEW, v0.9.0.
Consequence if Wrong	Ngưỡng thấp gây chậm mua hàng; ngưỡng cao làm yếu kiểm soát; ngưỡng sai nhưng ghi là fact làm test và cấu hình ERP dựa trên tiền đề không xác minh.

Mẫu câu Senior BA dùng: “Dựa trên [nguồn định danh], có bằng chứng cho [fact]. Chưa đủ bằng chứng để kết luận [điều chưa xác minh]. Khuyến nghị [hành động có điều kiện] vì [tiêu chí và tác động]. Quyết định thuộc [vai trò]. Trước khi quyết định, cần [bằng chứng cụ thể].” Mẫu này giữ recommendation hữu ích, vẫn trung thực với giới hạn chứng cứ và authority.

12. Associated Template Reference & Completed Artifact

Core

Template là mẫu cấu trúc tái sử dụng. Manifest là danh mục kiểm soát mẫu. Với chương này, nguồn template được xác minh là TEMPLATE_MANIFEST; nguồn này lập kế hoạch template, không phải bằng chứng rằng template đã được tạo, baseline hoặc phê duyệt. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dùng là dữ liệu tổng hợp.

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

flowchart TB
    A[Chapter 02] --> B[Nguồn template được xác minh]
    B --> C[TEMPLATE_MANIFEST]
    C --> D[Danh mục kiểm soát<br/>lập kế hoạch template]
    C -. không chứng minh .-> E[Không suy ra:<br/>template đã tạo, baseline<br/>hoặc phê duyệt]

Applied

Thành phần	Nội dung mô phỏng, dữ liệu tổng hợp
Facts	Canonical dependency cung cấp TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md, Status IN_REVIEW, Version v0.9.0, Owner Principal IT Business Analyst / Technical Curriculum Author. Không có ID template riêng cho Chapter 02 được cung cấp trong nguồn đầu vào.
Current Behavior	Chapter 02 phải dùng manifest để tra template được đăng ký, tránh tự đặt ID, filename hoặc cấu trúc template mới.
Underlying Need	Learner cần biết template nào điều khiển cấu trúc artifact và ai có quyền duy trì nó. Evidence bridge: manifest được phân loại là controlled planning artifact cho template manifest của corpus.
Options	A: tự tạo template Chapter 02; B: dùng ID hoặc filename suy đoán; C: tham chiếu TEMPLATE_MANIFEST và chỉ dùng template đã đăng ký tại đó.
Decision Criteria	Giữ canonical ID, không tạo nguồn chân lý thứ hai, truy vết được owner, không diễn giải IN_REVIEW thành approval.
Decision	Chọn C. Không lập template mới trong chapter này vì chưa có ID và filename template Chapter 02 được xác minh.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì manifest. Business Owner, Legal Owner, Accounting Owner, Security, Architect và QA giữ thẩm quyền nội dung thuộc chuyên môn của họ.
Artifact	/01-curriculum/TEMPLATE_MANIFEST.md, Artifact ID TEMPLATE_MANIFEST, Status IN_REVIEW, Version v0.9.0.
Consequence if Wrong	ID hoặc filename tự đặt làm hỏng traceability, khiến learner dùng nhầm mẫu, và có thể bị hiểu sai là artifact đã được kiểm soát hoặc phê duyệt.

Senior Lens

Không gọi manifest là completed template. Lý do: metadata nguồn nêu đây là planned template manifest và không có baseline reference hay approval reference tại v0.9.0. Không sao chép registry template vào chapter vì registry là nguồn canonical; chapter chỉ cần chỉ đường tới nguồn đó.

Quick Reference

Template ID / Artifact ID	Tệp canonical	Dùng khi	Không dùng khi	Owner	Consumers	Quality gate
TEMPLATE_MANIFEST	/01-curriculum/TEMPLATE_MANIFEST.md	Cần tra ID, filename, phạm vi, dependency hoặc trạng thái template đã đăng ký cho corpus.	Cần xác nhận requirement Nova Foods, approval, baseline, legal compliance hoặc production readiness.	Principal IT Business Analyst / Technical Curriculum Author	Handbook author, template author, QA reviewer, curriculum maintainer	ID và filename phải khớp manifest; Status phải giữ IN_REVIEW; Version phải giữ v0.9.0; không thêm template chưa đăng ký.
CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Cần xác nhận Chapter 02 tồn tại trong cấu trúc handbook và giữ đúng filename chapter.	Cần chọn nội dung trường dữ liệu của template.	Principal IT Business Analyst / Technical Curriculum Author	Handbook author, QA reviewer, curriculum maintainer	Không đổi chapter ID, đường dẫn hoặc phạm vi section ngoài manifest.
TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Cần kiểm tra định danh truy vết được phép dùng trong artifact liên quan.	Cần tự cấp ID mới hoặc coi ID là phê duyệt nội dung.	Principal IT Business Analyst / Technical Curriculum Author	BA, QA reviewer, template author, curriculum maintainer	Giữ nguyên chuỗi ID canonical; escalation khi ID mâu thuẫn nguồn canonical hoặc chạm thẩm quyền chuyên môn.
CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Cần liên kết business rule đã được catalog hóa cho ví dụ stakeholder hoặc domain.	Cần tự xác nhận rule là chính sách vận hành thực tế, pháp lý hay kế toán.	Principal IT Business Analyst / Technical Curriculum Author	BA, Business Owner, QA reviewer, template author	Giữ nhãn IN_REVIEW; rule có tác động pháp lý, kế toán hoặc vận hành phải được owner chuyên môn xác minh.
CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Cần dùng tên thực thể, thuộc tính hoặc thuật ngữ dữ liệu logic đã được kiểm soát.	Cần suy diễn schema triển khai, cấu hình ERP hoặc dữ liệu doanh nghiệp thật.	Principal IT Business Analyst / Technical Curriculum Author	BA, Architect, QA reviewer, template author	Không đổi tên logical data element; dữ liệu Nova Foods phải là mô phỏng, dữ liệu tổng hợp.

Core

Completed artifact của chương này nằm tại /02-handbook/02-stakeholders-domain-and-context.md. Đây là handbook artifact đã điền nội dung cho case Nova Foods Trading & Manufacturing, mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Không diễn giải vị trí tệp này là baseline, approval, cấu hình ERP thực tế hay bằng chứng tuân thủ.

Lookup checklist nghĩa là danh sách điểm tra cứu trước khi dùng hoặc cập nhật chapter. Mục đích: người học tìm đúng nguồn chân lý trước, vì cùng một thuật ngữ như “stakeholder”, “business rule” hoặc “data field” có thể xuất hiện ở nhiều tệp nhưng chỉ một tệp giữ thẩm quyền canonical cho từng loại thông tin.

#	Cần tra cứu	Tệp canonical hoặc artifact liên quan	Kiểm tra cụ thể	Lý do và bằng chứng
1	Định danh chapter, tên tệp, dependency	/01-curriculum/CHAPTER_MANIFEST.md	Xác nhận chapter này là /02-handbook/02-stakeholders-domain-and-context.md; giữ nguyên tên và vị trí tệp.	Manifest là danh mục authoritative cho 26 handbook chapter; đổi tên cục bộ làm đứt liên kết curriculum.
2	Mục tiêu học, vị trí trong chuỗi đào tạo	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Đối chiếu chapter về stakeholder, domain và context với chuỗi học đã lập kế hoạch.	Architecture kiểm soát thứ tự học; chapter không tự thêm phạm vi delivery hoặc production.
3	Trạng thái, version, giới hạn thẩm quyền	/00-research/00_SOURCE_MAP.md	Kiểm tra IN_REVIEW, v0.9.0, ngày 2026-08-07, Nova Foods là mô phỏng.	Metadata nguồn xác định ranh giới quản trị corpus; IN_REVIEW không phải BASELINED hay approved.
4	ID dùng trong ví dụ, liên kết traceability	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Chỉ dùng ID đã đăng ký; không tự tạo biến thể ID trong chapter.	Registry là nguồn canonical của identifier; ID mới có thể bị hiểu sai thành yêu cầu, rule hoặc quyết định.
5	Quy tắc nghiệp vụ được viện dẫn	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Kiểm tra rule có tồn tại, trạng thái và owner thẩm quyền trước khi tham chiếu.	Catalog rule tách rule khỏi diễn giải của chapter; ví dụ học liệu không được nâng thành quy tắc vận hành Nova Foods.
6	Thuật ngữ dữ liệu, entity, field	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	So khớp tên logical data, định nghĩa và phân loại dữ liệu trước khi mô tả stakeholder dùng dữ liệu.	Data dictionary là nguồn canonical cho nghĩa dữ liệu; tránh một field có hai định nghĩa giữa handbook và artifact dữ liệu.
7	Template dự kiến và quan hệ template-chapter	/01-curriculum/TEMPLATE_MANIFEST.md	Chỉ tra cứu template đã được manifest ghi nhận; không sao chép registry vào chapter.	Template manifest giữ danh mục template; chapter chỉ cần liên kết tra cứu đúng vị trí.
8	Nguồn chuẩn BA, testing, API, accessibility, security	/00-research/00_SOURCE_MAP.md	Kiểm tra issuer, version và safe use boundary trước khi nêu chuẩn hoặc thuật ngữ.	Source map giới hạn cách dùng nguồn; không được bịa điều khoản, số trang hoặc trích dẫn.
9	Nội dung pháp lý, kế toán, thuế, an toàn thực phẩm, dữ liệu cá nhân	/00-research/00_SOURCE_MAP.md và nguồn chính thức được liệt kê	Gắn Verification required khi nội dung chưa đối chiếu văn bản chính thức hiện hành và chưa có owner thẩm quyền xác nhận.	Seed nguồn nêu rõ các suy luận pháp lý và chuyên môn phải được xác minh; handbook giáo dục không thay thế tư vấn pháp lý hoặc quyết định vận hành.
10	Tính nhất quán cuối chapter	/02-handbook/02-stakeholders-domain-and-context.md	Kiểm tra 12 H2 blueprint, thuật ngữ Nova Foods, nhãn mô phỏng, dữ liệu tổng hợp, ID và đường dẫn.	Artifact hoàn chỉnh là điểm tích hợp; lỗi tại đây làm người đọc dùng sai nguồn hoặc suy diễn thành ERP thật.

Quy tắc dùng checklist: tra cứu theo thứ tự bảng trước khi sửa nội dung. Nếu chapter và nguồn canonical khác nhau, giữ nguyên thông tin canonical, ghi nhận mâu thuẫn để review; không sửa nguồn canonical từ trong handbook. Nếu không tìm thấy ID, rule, field hoặc template trong artifact canonical, không thay bằng nội dung tự suy đoán. Đây là suy luận từ việc các manifest và registry được mô tả là controlled planning artifact, còn chapter là học liệu phụ thuộc chúng.

Ranh giới tra cứu: checklist này chỉ chỉ vị trí cần xem, không thay thế /01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/TEMPLATE_MANIFEST.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md hoặc /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Không chép toàn bộ registry vào chapter, vì bản sao sẽ nhanh lỗi version và tạo hai nguồn chân lý.

Quick Reference

Core

Tự rà soát liên tệp kiểm tra cùng một khái niệm có giữ nguyên ID, trạng thái, version, đường dẫn và giới hạn thẩm quyền hay không. Lý do: một chapter có thể đúng riêng lẻ nhưng sai corpus nếu gọi IN_REVIEW là đã phê duyệt, đổi tên artifact canonical, hoặc biến dữ liệu Nova Foods mô phỏng thành quy tắc vận hành thật.

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

flowchart TB
    A[02-handbook/02-stakeholders-domain-and-context.md] --> B[Kiểm tra liên tệp: ID, trạng thái, version, đường dẫn, giới hạn thẩm quyền]

    B --> C[ID<br/>TRACEABILITY_ID_REGISTRY]
    B --> D[Trạng thái, version, đường dẫn<br/>CHAPTER_MANIFEST và TEMPLATE_MANIFEST]
    B --> E[Artifact canonical và quy tắc nghiệp vụ<br/>CANONICAL_BUSINESS_RULES]
    B --> F[Dữ liệu và thuật ngữ canonical<br/>CANONICAL_DATA_DICTIONARY]

    C --> G[So sánh cùng một khái niệm giữa các tệp]
    D --> G
    E --> G
    F --> G

    G --> H[Kiểm tra ngoại lệ:<br/>`IN_REVIEW` không phải đã phê duyệt;<br/>không đổi tên artifact canonical;<br/>dữ liệu Nova Foods mô phỏng không thành quy tắc thật]

    H --> I{Có mâu thuẫn hoặc cần thẩm quyền?}
    I -- Không --> J[Handoff chapter kèm bằng chứng review]
    I -- Có --> K[Escalation đúng owner]

Applied

Trường	Nội dung
Facts	/02-handbook/02-stakeholders-domain-and-context.md đang IN_REVIEW, v0.9.0, ngày 2026-08-07; Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp.
Current Behavior	Chapter tham chiếu stakeholder, domain và context; các artifact nguồn giữ canonical ID và chưa có baseline hoặc approval reference.
Underlying Need	Handoff chapter phải không tạo ngụ ý rằng requirement, legal interpretation, accounting treatment, security control hoặc cấu hình ERP Nova Foods đã được xác nhận.
Options	(1) Handoff khi chỉ đọc lại chapter. (2) Handoff sau đối chiếu với artifact canonical liên quan.
Decision Criteria	Chọn phương án giữ traceability, không đổi source classification, không vượt thẩm quyền, và ghi rõ việc còn phải xác minh.
Decision	Chọn phương án (2). Bằng chứng: CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY đều là IN_REVIEW v0.9.0 và không tạo approval ngầm định.
Authority	Principal IT Business Analyst / Technical Curriculum Author điều phối review; không thay Business Owner, Legal Owner, Accounting Owner, Security, Architect hoặc QA.
Artifact	Ghi kết quả review trong chapter handoff record, liên kết đúng đường dẫn canonical, không sao chép registry hoặc catalog.
Consequence if Wrong	ID lệch làm đứt traceability; diễn đạt pháp lý hoặc kế toán quá mức tạo rủi ro đào tạo sai; gọi artifact là approved tạo sai trạng thái quản trị.

Senior Lens

Hạng mục đối chiếu	Bằng chứng cần thấy	Kết quả hiện tại	Hành động nếu sai	Escalation owner
Trạng thái và version	IN_REVIEW, v0.9.0, ngày 2026-08-07 nhất quán	Phải xác minh trước handoff	Dừng handoff, sửa metadata tại nguồn kiểm soát	Principal IT Business Analyst / Technical Curriculum Author
Canonical filename và ID	Giữ nguyên /01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/TEMPLATE_MANIFEST.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Phải xác minh trước handoff	Không tự tạo ID thay thế hoặc đường dẫn rút gọn	Principal IT Business Analyst / Technical Curriculum Author
Nguồn luật Việt Nam	Chỉ nêu bối cảnh; không diễn giải nghĩa vụ chưa kiểm chứng	Verification required	Gắn nhãn Verification required; không biến thành requirement bắt buộc	Legal Owner
Kế toán, thuế, hóa đơn	Không suy diễn hạch toán, thuế hoặc chứng từ từ case mô phỏng	Verification required	Loại kết luận nghiệp vụ chưa có thẩm quyền	Accounting Owner
Dữ liệu cá nhân, bảo mật	Không kết luận tuân thủ Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, OWASP ASVS hoặc OWASP API Security Top 10	Verification required	Tách claim thành giả định dự án hoặc mục cần xác minh	Legal Owner; Security
Domain thực phẩm và truy xuất	Không gọi quy trình mô phỏng là đáp ứng Luật An toàn thực phẩm	Verification required	Yêu cầu xác nhận ngữ cảnh và trách nhiệm nghiệp vụ	Business Owner; Legal Owner
Kiến trúc hoặc tích hợp ERP	Không suy diễn API, phân quyền, hệ thống nguồn hoặc cấu hình production	Open issue	Ghi phạm vi chưa xác định, không viết thiết kế thay kiến trúc	Architect
Khả năng kiểm thử	Không gọi ví dụ là test basis hoàn chỉnh khi thiếu rule, data và acceptance criteria	Open issue	Chuyển điểm thiếu thành input cho chapter sau, không tự bịa tiêu chí	QA reviewer

Open issues trước handoff: stakeholder thực tế của Nova Foods không tồn tại trong corpus vì đây là mô phỏng; ranh giới hệ thống ERP, API và ownership dữ liệu chưa được xác nhận; chi tiết pháp lý, kế toán, hóa đơn, riêng tư và an toàn thực phẩm chưa có kết luận chuyên môn. Các mục này không chặn giá trị học liệu về phương pháp BA, nhưng chặn mọi claim vận hành, compliance, production-ready, baseline hoặc approval.

Quick Reference

Điều kiện handoff: mọi tham chiếu liên tệp dùng đúng ID và filename; mọi suy luận có cầu nối bằng chứng; mọi nội dung ngoài nguồn chính thức được gắn project assumption hoặc Verification required; không có câu nào nói Nova Foods đã áp dụng, đã phê duyệt hoặc đã tuân thủ. Nếu phát hiện một mục đồng thời chạm legal, accounting, security, architecture hoặc business operation, Principal IT Business Analyst / Technical Curriculum Author lập gói vấn đề; owner chuyên môn tương ứng quyết định nội dung.