06 Requirements Foundations

Trường kiểm soát	Giá trị
Artifact ID	06_REQUIREMENTS_FOUNDATIONS
Tên tệp được kiểm soát	/02-handbook/06-requirements-foundations.md
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale	vi-VN; bối cảnh Việt Nam; tiền tệ mô phỏng VND
Owner	Principal IT Business Analyst / Technical Curriculum Author
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp
Phân loại	Handbook chapter; controlled educational artifact
Nguồn nghiệp vụ BA	BABOK Guide, IIBA, Version 3; nguồn sơ cấp đã xác minh trong /00-research/00_SOURCE_MAP.md
Nguồn kỹ thuật yêu cầu	ISO/IEC/IEEE 29148:2018, ISO/IEC/IEEE; chỉ dùng abstract và trạng thái thư mục đã xác minh khi chưa kiểm tra văn bản có bản quyền
Traceability quản trị	/01-curriculum/CHAPTER_MANIFEST.md, CHAPTER_MANIFEST; /01-curriculum/TRACEABILITY_ID_REGISTRY.md, TRACEABILITY_ID_REGISTRY
Baseline	Chưa có baseline reference tại v0.9.0; IN_REVIEW không phải BASELINED
Approval	Chưa có approval reference; metadata và nội dung không tạo phê duyệt ngầm định
Giới hạn thẩm quyền	Owner duy trì nội dung và truy vết học liệu; không xác nhận requirement Nova Foods, không diễn giải pháp lý, kế toán, thuế, compliance, hay cho phép production

1. Concept l? g??

Core

Requirements foundations là nền móng để hiểu requirement trước khi viết tài liệu yêu cầu. Requirement nghĩa là điều cần được đáp ứng: có thể là mục tiêu nghiệp vụ, khả năng người dùng cần, quy tắc hệ thống phải tuân theo, dữ liệu phải lưu, hoặc điều kiện chất lượng phải đạt. Nền móng này trả lời trước câu hỏi “cần làm gì và vì sao cần”, không nhảy ngay sang câu hỏi “lập trình bằng cách nào”.

Business Analyst, viết tắt BA, là người phân tích vấn đề giữa bên nghiệp vụ và bên kỹ thuật. BA không tự biến ý kiến thành requirement. BA thu thập bằng chứng, tách nhu cầu khỏi giải pháp được đề xuất, làm rõ phạm vi, ghi nhận quyết định thuộc đúng thẩm quyền, rồi tạo artifact có thể kiểm tra và truy vết. Lý do: cùng câu nói “ERP phải kiểm soát đơn hàng” có thể chứa nhiều nghĩa khác nhau nếu chưa xác định người dùng, hành động, đối tượng và kết quả cần đạt.

Một requirement rõ từ mức cơ bản có bốn thành phần tư duy. Actor là tác nhân thực hiện hoặc chịu tác động, ví dụ nhân viên kinh doanh hoặc hệ thống ERP. Action là hành động cần làm, ví dụ tạo, kiểm tra, phê duyệt hoặc xuất dữ liệu. Object là đối tượng hành động, ví dụ đơn bán hàng, lô hàng, khách hàng hoặc báo cáo. Outcome là kết quả mong muốn có thể quan sát hoặc kiểm tra, ví dụ đơn được ghi nhận với trạng thái phù hợp để bộ phận kho tiếp tục xử lý. Bốn thành phần này chưa tự tạo thành requirement hoàn chỉnh, nhưng giúp BA phát hiện phần thiếu trước khi chuyển thành đặc tả.

Requirement không đồng nghĩa với solution. “Cần cảnh báo khi tồn kho không đủ” mô tả nhu cầu hoặc kết quả. “Phải dùng nút màu đỏ và JavaScript” mô tả thiết kế giải pháp. Bằng chứng phân biệt nằm ở khả năng thay thế: nếu đổi công nghệ, màn hình hoặc nhà cung cấp mà mục tiêu vẫn giữ nguyên, nội dung đó thuộc nhu cầu; nếu mục tiêu không đổi nhưng cách thực hiện thay đổi, nội dung đó thuộc giải pháp. BA cần giữ hai lớp này tách biệt để đội kỹ thuật còn không gian đánh giá phương án.

Trong Nova Foods Trading & Manufacturing, đây là case study mô phỏng giáo dục với dữ liệu tổng hợp. Ví dụ tối thiểu: nhân viên kinh doanh cần biết đơn bán hàng có thể tiếp tục xử lý hay không khi số lượng đặt vượt số lượng khả dụng được hệ thống cung cấp. Actor là nhân viên kinh doanh; action là tạo hoặc cập nhật đơn; object là dòng hàng của đơn bán hàng; outcome là hệ thống cung cấp trạng thái đủ thông tin để nhân viên không tiếp tục dựa trên phỏng đoán. Ví dụ này chỉ minh họa cách nhận diện requirement; không xác nhận quy trình ERP thực tế, quy tắc tồn kho, quyền phê duyệt, cấu hình hệ thống, hay quyết định vận hành của Nova Foods.

Ranh giới chương này là khái niệm và ngôn ngữ nền tảng để đọc, hỏi và phân biệt requirement. Chương này không xác lập business rule, acceptance criteria, quy trình BPMN, mô hình dữ liệu, thiết kế giao diện, API, kiểm thử, ưu tiên backlog, hay phê duyệt phạm vi. Các nội dung đó cần đầu vào, artifact và thẩm quyền riêng ở phần sau.

Core

Requirement là yêu cầu: mô tả nhu cầu, điều kiện hoặc năng lực cần được thỏa mãn. BA không bắt đầu bằng màn hình hay câu hỏi “hệ thống làm gì”; BA bắt đầu bằng thay đổi nghiệp vụ cần đạt. Câu requirement tốt tách được ai làm, làm gì, với đối tượng nào, và kết quả nào. Bốn phần này tạo đơn vị nghĩa tối thiểu để người nghiệp vụ, kỹ thuật và kiểm thử cùng hiểu một việc.

Thuật ngữ	Nghĩa tiếng Việt	Vai trò trong requirement	Câu hỏi kiểm tra
Actor	Tác nhân: người, vai trò, hệ thống hoặc sự kiện khởi phát hành động	Xác định chủ thể chịu trách nhiệm hoặc gửi yêu cầu	Ai hoặc cái gì khởi phát?
Action	Hành động: việc actor thực hiện	Xác định năng lực cần có, không mặc định cách xây dựng	Actor cần làm việc gì?
Object	Đối tượng: dữ liệu, hồ sơ, đơn hàng, lô hàng hoặc tài nguyên bị tác động	Xác định phạm vi dữ liệu/nghiệp vụ	Hành động tác động lên cái gì?
Outcome	Kết quả: trạng thái hoặc giá trị mong muốn sau hành động	Xác định lý do requirement tồn tại và cơ sở kiểm tra	Sau hành động, điều gì phải đúng?
Business need	Nhu cầu nghiệp vụ: vấn đề hoặc cơ hội cần giải quyết	Là bằng chứng cho việc requirement cần tồn tại	Không làm việc này thì tổn thất hoặc rủi ro gì?
Stakeholder	Bên liên quan: cá nhân hoặc nhóm bị ảnh hưởng, cung cấp thông tin, hoặc có quyền quyết định	Không phải mọi stakeholder đều là actor	Ai dùng, bị ảnh hưởng, kiểm tra hoặc quyết định?
Business rule	Quy tắc nghiệp vụ: điều kiện quyết định hoặc ràng buộc nghiệp vụ	Ràng buộc action và outcome; không tự là một màn hình	Trong điều kiện nào được phép, bị cấm, hoặc phải xử lý khác?
Acceptance criteria	Tiêu chí chấp nhận: điều kiện quan sát được để xác nhận requirement đáp ứng	Biến outcome thành điều kiện kiểm thử được	Bằng chứng nào cho thấy kết quả đã đạt?

Ví dụ tổng hợp của Nova Foods Trading & Manufacturing — mô phỏng giáo dục: actor là Nhân viên Kho; action là ghi nhận số lượng nhận; object là dòng nhận hàng của phiếu mua mô phỏng; outcome là tồn kho dự kiến được cập nhật để bộ phận Mua hàng thấy chênh lệch. Cấu trúc này không nói phải dùng nút bấm, API, bảng dữ liệu hay ERP nào. Lý do: đó là lựa chọn thiết kế kỹ thuật, chỉ được xem sau khi nhu cầu và ràng buộc đã rõ.

Công thức đọc nhanh: Actor thực hiện Action lên Object để đạt Outcome. Nếu thiếu actor, không rõ trách nhiệm. Nếu thiếu object, không rõ dữ liệu/phạm vi. Nếu thiếu outcome, không chứng minh được giá trị hay điều kiện kiểm thử. Nếu chỉ có câu “cần màn hình nhận hàng”, câu đó mô tả giải pháp giả định, chưa chứng minh nhu cầu nghiệp vụ.

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. Ví dụ tối thiểu: nhân viên kho cần ghi nhận hàng thành phẩm nhập kho sau sản xuất. Đây là nhu cầu nghiệp vụ: tổ chức cần biết số lượng thành phẩm sẵn có để điều phối bán hàng và tồn kho. Nó chưa phải màn hình, API, cấu trúc bảng DB, hay quyết định cấu hình ERP.

Thành phần	Giá trị trong ví dụ	Lý do nhận diện
Actor	Nhân viên kho	Người khởi phát và chịu trách nhiệm thao tác nghiệp vụ
Action	Ghi nhận nhập kho	Việc nghiệp vụ cần xảy ra
Object	120 thùng NF-MANGO-1L từ lệnh sản xuất mô phỏng MO-SIM-20260807-01	Đối tượng chịu tác động của hành động
Outcome	Tồn khả dụng tăng 120 thùng tại kho mô phỏng WH-FG-HCM	Kết quả nghiệp vụ có thể kiểm tra
Evidence	Phiếu bàn giao thành phẩm mô phỏng, số lượng thực nhận, mã lệnh sản xuất	Bằng chứng nối sự kiện thực tế với dữ liệu ERP

Facts: ngày 2026-08-07, kho mô phỏng WH-FG-HCM nhận 120 thùng thành phẩm NF-MANGO-1L. Dữ liệu này không đại diện giao dịch thật, tồn kho thật, hay cấu hình ERP thật.

Current Behavior: nếu chỉ dùng bảng tính riêng, bán hàng có thể thấy số tồn cũ. Bằng chứng là số lượng mới nhận chưa đi vào nguồn dữ liệu dùng chung.

Underlying Need: hệ thống phải ghi nhận việc nhận thành phẩm theo lệnh sản xuất và làm tồn kho khả dụng phản ánh đúng sự kiện đã xác nhận. Suy luận này xuất phát từ khoảng cách giữa sự kiện kho đã nhận và số tồn mà bộ phận khác cần dùng.

Options: ghi nhận thủ công trong bảng tính; ghi nhận một giao dịch nhập kho trong ERP; hoặc tự động tạo giao dịch từ hệ thống sản xuất. Ba lựa chọn khác nhau ở cách thực hiện, không làm thay đổi nhu cầu gốc.

Decision Criteria: dữ liệu phải truy được tới lệnh sản xuất; số lượng không âm; người ghi nhận có quyền phù hợp; kết quả tồn kho kiểm tra được; cách làm không tự tạo nghĩa vụ pháp lý, kế toán, hay an toàn thực phẩm chưa được vai trò có thẩm quyền xác minh.

Decision: trong phạm vi ví dụ học liệu, chọn khái niệm “ghi nhận giao dịch nhập kho thành phẩm có tham chiếu lệnh sản xuất”. Đây là quyết định mô tả requirement ở mức nghiệp vụ, chưa chọn giao diện hay tích hợp.

Authority: Business Owner xác nhận nhu cầu và kết quả nghiệp vụ; Warehouse Owner xác nhận quy trình kho; Architect quyết định thiết kế ERP/tích hợp; Accounting Owner và Legal Owner xác minh hệ quả kế toán hoặc pháp lý nếu phạm vi sau này kích hoạt. Không có approval hay baseline tại IN_REVIEW, v0.9.0.

Artifact: BA có thể ghi nhận requirement dự thảo trong artifact kiểm soát sau này, liên kết tới TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, và CANONICAL_DATA_DICTIONARY khi các mục canonical được đăng ký. Không tự tạo ID, business rule, hay định nghĩa dữ liệu canonical trong ví dụ này.

Consequence if Wrong: nếu nhầm actor thành hệ thống, team có thể bỏ kiểm soát quyền thao tác; nếu nhầm outcome là “hiện thông báo thành công”, tồn kho vẫn có thể sai; nếu nhầm object là toàn bộ lệnh sản xuất, hệ thống có thể cập nhật sai mã hàng hoặc sai kho.

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

flowchart TB
    A[Phiếu bàn giao thành phẩm mô phỏng<br/>Số lượng thực nhận: 120 thùng<br/>MO-SIM-20260807-01] -->|Chứng minh| B[Sự kiện nhận 120 thùng<br/>NF-MANGO-1L tại WH-FG-HCM]

    C[Nhân viên kho] -->|Ghi nhận| D[Giao dịch nhập kho thành phẩm]
    B -->|Là cơ sở ghi nhận| D
    D -->|Tham chiếu| E[MO-SIM-20260807-01]

    D --> F{Đủ điều kiện ghi nhận?}
    E --> F
    F --- G[Tham chiếu MO-SIM-20260807-01<br/>Số lượng thực nhận = 120 thùng<br/>Quyền phù hợp<br/>Giao dịch được xác nhận]

    F -->|Có| H[Tồn khả dụng WH-FG-HCM<br/>tăng 120 thùng]
    F -->|Không: thiếu tham chiếu,<br/>số lượng không hợp lệ,<br/>thiếu quyền hoặc chưa xác nhận| I[Không cập nhật tồn]

Ranh giới khái niệm: requirement trả lời “ai cần làm gì với đối tượng nào để đạt kết quả nào, trong điều kiện nào và vì sao”. Requirement không tự quyết định nút bấm, tên bảng DB, endpoint, thuật toán, quyền chi tiết, sơ đồ tích hợp, bút toán kế toán, nghĩa vụ hóa đơn, truy xuất thực phẩm, hay tuân thủ pháp luật. Các nội dung đó chỉ được thêm khi có phạm vi rõ, nguồn phù hợp, và xác minh từ vai trò có thẩm quyền.

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

Core

Requirement tồn tại để biến nhu cầu mơ hồ thành phạm vi có thể xây, kiểm tra và truy vết. Nếu không có requirement rõ, Business Owner nói về kết quả, nhân viên nói về thao tác hiện tại, đội kỹ thuật tự chọn cách làm. Ba cách hiểu có thể cùng đúng theo góc nhìn riêng nhưng tạo ra một hệ thống sai mục tiêu.

Rủi ro chính là rework: đội phát triển hoàn thành chức năng theo cách hiểu kỹ thuật, rồi phát hiện người dùng cần kết quả khác. Rủi ro thứ hai là ambiguity, nghĩa là một câu có nhiều cách diễn giải nhưng không chỉ rõ cách nào đúng. Rủi ro thứ ba là governance: không xác định được ai có thẩm quyền quyết định, nguồn nào chứng minh yêu cầu, hoặc thay đổi nào tác động đến quy tắc, dữ liệu và kiểm thử.

Requirement không ngăn thay đổi nghiệp vụ. Requirement làm thay đổi trở nên nhìn thấy được: thay đổi gì, vì sao thay đổi, ai quyết định, artifact nào bị ảnh hưởng, và điều gì phải kiểm tra lại. Không có chuỗi này, team dễ sửa màn hình nhưng quên rule, dữ liệu, quyền hoặc test case liên quan.

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; dữ liệu sau dùng dữ liệu tổng hợp. Nhân viên kho ghi nhận 120 thùng NF-MANGO-1L vào kho thành phẩm WH-FG-HCM, tham chiếu MO-SIM-20260807-01.

Current Behavior: yêu cầu miệng là “nhập kho xong phải thấy tồn tăng”. Câu này không nêu thời điểm tăng, kho nào tăng, điều kiện thành công, xử lý bản ghi trùng, hay ai được thực hiện. Developer có thể tăng tồn ngay khi người dùng bấm lưu; QA có thể kiểm tra chỉ có thông báo thành công; kho có thể kỳ vọng tồn khả dụng tăng sau khi xác nhận.

Underlying Need: kho cần số tồn khả dụng phản ánh đúng hàng thành phẩm đã được ghi nhận cho đúng mã hàng, số lượng và kho. Lý do: kế hoạch bán hàng và thao tác kho sau đó sẽ dùng số tồn này.

Mục	Không có requirement rõ	Có requirement rõ
Phạm vi xây dựng	Team tự suy ra “lưu phiếu nhập” là đủ	Team xác định outcome cần kiểm tra: tồn khả dụng của NF-MANGO-1L tại WH-FG-HCM tăng 120 thùng
Kiểm thử	QA chỉ kiểm tra thao tác lưu	QA kiểm tra đối tượng, số lượng, kho, điều kiện ghi nhận và kết quả tồn
Thay đổi	Sửa lỗi sau demo có thể tác động không rõ phạm vi	BA truy vết artifact bị ảnh hưởng trước khi thay đổi
Trách nhiệm	Tranh luận “ai hiểu sai”	Phân biệt nhu cầu, quyết định, thiết kế và kiểm tra
Governance	Không có căn cứ xác định người quyết định	Quyết định gắn đúng thẩm quyền và trạng thái IN_REVIEW

Options: Option 1 ghi requirement như câu miệng và để team tự suy luận. Option 2 mô tả actor, đối tượng, điều kiện, kết quả nghiệp vụ và ranh giới chưa quyết định.

Decision Criteria: cách chọn phải giảm số cách diễn giải, cho phép QA tạo kiểm tra quan sát được, không tự quyết định thiết kế ERP, và giữ quyền quyết định cho vai trò đúng thẩm quyền.

Decision: dùng Option 2. Requirement cần mô tả kết quả tồn kho mong muốn; không ghi trước tên màn hình, bảng DB, API, hoặc cơ chế đồng bộ.

Authority: Business Owner xác nhận kết quả nghiệp vụ; Warehouse Owner xác nhận thao tác kho; Architect quyết định thiết kế ERP hoặc tích hợp; QA xác nhận khả năng kiểm thử. IN_REVIEW, v0.9.0 không phải approval hay baseline.

Artifact: nội dung sau này cần được quản lý trong artifact kiểm soát, liên kết TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, và CANONICAL_DATA_DICTIONARY khi mục canonical đã được đăng ký. Ví dụ này không tạo ID, rule hay định nghĩa dữ liệu mới.

Consequence if Wrong: nếu team hiểu “tồn tăng” là tồn tổng thay vì tồn khả dụng tại WH-FG-HCM, người dùng thấy số liệu khác kỳ vọng dù chức năng đã chạy. Nếu QA chỉ kiểm tra thông báo lưu thành công, lỗi cập nhật nhầm kho có thể không bị phát hiện. Nếu BA tự chọn giải pháp tích hợp, quyết định kiến trúc bị đưa ra sai thẩm quyền.

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

flowchart TB
    A["Tình huống đầu vào<br/>Nhân viên kho ghi nhận 120 thùng<br/>NF-MANGO-1L tại WH-FG-HCM<br/>Tham chiếu MO-SIM-20260807-01"]

    A --> B["Requirement draft — IN_REVIEW<br/>v0.9.0"]

    B --> C["Outcome mong muốn<br/>Tồn khả dụng của NF-MANGO-1L<br/>tại WH-FG-HCM tăng 120 thùng"]

    B --> D["Open issue<br/>Tiêu chí ghi nhận thành công"]
    B --> E["Open issue<br/>Xử lý bản ghi trùng"]
    B --> F["Open issue<br/>Quyền thực hiện"]

    D --> G["Chưa sẵn sàng<br/>triển khai hoặc kiểm thử"]
    E --> G
    F --> G

    C --> H["Kiểm tra QA dự kiến<br/>mã hàng, 120 thùng, kho,<br/>tham chiếu và kết quả tồn"]
    G -. "phải làm rõ trước" .-> H

    C --> I{"Diễn giải đúng<br/>loại tồn và kho?"}
    I -->|"Tồn khả dụng<br/>tại WH-FG-HCM"| J["Outcome có thể đối chiếu"]
    I -->|"Tồn tổng hoặc<br/>sai kho"| K["Số liệu khác kỳ vọng<br/>dù chức năng đã chạy"]

    B --> L["Ranh giới requirement<br/>Không quyết định màn hình, DB,<br/>API hoặc cơ chế đồng bộ"]

    M["Business Owner"] -->|"xác nhận kết quả nghiệp vụ"| C
    N["Warehouse Owner"] -->|"xác nhận thao tác kho"| B
    O["QA"] -->|"xác nhận khả năng kiểm thử"| H
    P["Architect"] -->|"quyết định"| Q["Thiết kế ERP hoặc tích hợp<br/>ngoài requirement"]

    B --> R["IN_REVIEW và v0.9.0<br/>không phải approval hoặc baseline"]

Senior Lens

Requirement tốt không phải câu dài. Requirement tốt giảm tập hợp cách hiểu hợp lý xuống mức team có thể xây và kiểm tra cùng một kết quả. Khi chưa đủ thông tin, BA không lấp khoảng trống bằng phỏng đoán. BA ghi rõ khoảng trống, tác động và vai trò cần quyết định.

Dấu hiệu cần làm rõ ngay: một câu chứa từ “nhanh”, “đúng”, “tự động”, “kịp thời”, “đủ”, hoặc “theo quy định” nhưng không có tiêu chí quan sát được. Các từ này không sai; chúng thiếu ngữ cảnh để thiết kế và kiểm thử.

Quick Reference

Rủi ro	Requirement phòng ngừa bằng cách nào
Xây sai nhu cầu	Nêu outcome nghiệp vụ thay vì để team đoán
Rework muộn	Làm rõ điều kiện và phạm vi trước khi xây
Test sai mục tiêu	Tạo kết quả quan sát được cho QA
Scope creep	Phân biệt nhu cầu với thiết kế và thay đổi mới
Sai thẩm quyền	Gắn quyết định với Business Owner, Architect, QA hoặc owner phù hợp
Mất truy vết	Liên kết requirement với rule, dữ liệu và artifact kiểm soát khi được đăng ký

Core

Requirements foundations tồn tại để biến câu nói nghiệp vụ thành đầu vào kiểm soát được: biết hệ thống phải làm gì, ai quyết định, bằng chứng nào kiểm tra. Nếu thiếu, cùng một câu có thể sinh nhiều cách build; lỗi chỉ lộ khi demo, test hoặc vận hành mô phỏng. 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.

Applied

Mục	Trước khi làm rõ requirement	Sau khi làm rõ requirement
Yêu cầu được nói	“Kho bán hàng phải chặn xuất hàng khi không đủ tồn.”	“Khi người dùng xác nhận phiếu xuất bán, ERP kiểm tra tồn khả dụng của từng dòng hàng tại kho được chọn. Nếu bất kỳ dòng nào thiếu, hệ thống không tạo giao dịch xuất kho và hiển thị mã hàng, số lượng yêu cầu, số lượng khả dụng.”
Cách build quan sát được	Developer có thể chặn khi tạo đơn bán, khi in phiếu, hoặc khi xác nhận xuất. Mỗi cách đổi thời điểm phát hiện lỗi.	Điểm kiểm tra là hành động xác nhận phiếu xuất bán. Điều kiện và kết quả thất bại xác định.
Hậu quả quan sát được	Nhân viên tạo đơn bán được nhưng đến kho mới phát hiện thiếu hàng; hoặc đơn bị chặn quá sớm dù hàng có thể được điều chuyển trước lúc xuất. QA không có một kết quả kỳ vọng duy nhất để kiểm tra.	Nhân viên biết chính xác dòng thiếu tại thời điểm xuất. QA tạo được ca kiểm thử: một dòng đủ, một dòng thiếu; kỳ vọng giao dịch xuất kho không được tạo.
Quản trị thay đổi	Tranh luận “hệ thống làm sai” không chỉ ra requirement nào, thời điểm nào, dữ liệu nào.	Thay đổi được đánh giá vào điều kiện kiểm tra, thông điệp lỗi và quy trình kho trước khi sửa build.

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

flowchart TB
    A[Người dùng xác nhận phiếu xuất bán] --> B[ERP kiểm tra tồn khả dụng của từng dòng tại kho được chọn]
    B --> C{Mọi dòng đủ tồn?}
    C -- Có --> D[Tạo giao dịch xuất kho]
    C -- Không --> E[Không tạo giao dịch xuất kho]
    E --> F[Hiển thị mã hàng, số lượng yêu cầu, số lượng khả dụng]

Senior Lens

Khác biệt không phải văn phong dài hơn. Khác biệt là bỏ điểm mơ hồ có thể tạo hành vi khác nhau. “Chặn xuất hàng” phải gắn hành động kích hoạt, dữ liệu kiểm tra, phạm vi kho, điều kiện đạt, điều kiện thất bại và hậu quả. Không tự suy ra “tồn khả dụng” nghĩa là tồn vật lý, tồn đã giữ chỗ, hay công thức khác. Nếu khái niệm chưa có định nghĩa canonical trong CANONICAL_DATA_DICTIONARY, BA ghi nhận khoảng trống và không biến suy đoán thành logic ERP.

Quick Reference

Thành phần cần đối chiếu	Dấu hiệu trước	Dấu hiệu sau
Thời điểm xử lý	“Khi xuất hàng”	“Khi xác nhận phiếu xuất bán”
Điều kiện	“Không đủ tồn”	“Bất kỳ dòng hàng có tồn khả dụng thấp hơn số lượng yêu cầu”
Kết quả	“Chặn”	“Không tạo giao dịch xuất kho; hiển thị mã hàng, số lượng yêu cầu, số lượng khả dụng”
Khả năng kiểm thử	Tester tự đoán	Có dữ liệu đầu vào và kết quả kỳ vọng
Hậu quả sai	Rework ở build, test, demo	Lỗi được phát hiện tại review requirement

Core

BA phải phân loại từng phát biểu trước khi biến nó thành yêu cầu. Nếu không, ý kiến bị ghi thành sự thật, giả định bị triển khai như quyết định, và claim cần xác minh bị hiểu là nghĩa vụ bắt buộc. Hậu quả là backlog sai nguồn, test không có căn cứ, và không rõ ai phải chịu trách nhiệm xác nhận.

Loại	Định nghĩa	Bằng chứng tối thiểu	Cách ghi trong artifact	Không được suy diễn thành
Verified fact — sự thật đã xác minh	Thông tin khớp nguồn kiểm soát, quan sát hệ thống, hoặc dữ liệu đã kiểm tra	URL chính thức, log, ảnh chụp màn hình, artifact có kiểm soát	Nêu nguồn, ngày truy cập 2026-08-07, phạm vi	Quyết định triển khai
Stakeholder input — đầu vào stakeholder	Nhu cầu, vấn đề, ý kiến từ vai trò liên quan	Người nói, vai trò, thời điểm, bối cảnh	Ghi rõ nguồn là stakeholder input	Sự thật hoặc phê duyệt
Project assumption — giả định dự án	Điều tạm coi đúng để tiếp tục phân tích khi chưa đủ bằng chứng	Lý do cần giả định, rủi ro, owner xác minh	Gắn nhãn Project assumption	Business rule bắt buộc
Decision — quyết định	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í, người có thẩm quyền, artifact ghi nhận	Ghi authority và trạng thái	Approval nếu chưa có bằng chứng approval
Verification-required claim — claim cần xác minh	Phát biểu có thể ảnh hưởng pháp lý, kế toán, bảo mật, vận hành, hoặc thiết kế nhưng chưa đủ chứng cứ	Nguồn cần kiểm tra và vai trò xác minh	Gắn Verification required	Requirement đã xác nhận

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

flowchart TB
    A[Phát biểu mới] --> B{Bản chất phát biểu?}

    B -- Sự thật về hiện trạng hoặc dữ liệu --> C{Có nguồn kiểm soát,<br/>quan sát hệ thống hoặc dữ liệu đã kiểm tra?}
    C -- Có --> D[Verified fact<br/>Ghi nguồn, ngày truy cập, phạm vi]
    C -- Không --> E[Verification required<br/>Ghi nguồn cần kiểm tra<br/>và vai trò xác minh]
    E --> F[Thu thập nguồn và bằng chứng<br/>Owner: vai trò xác minh]
    F --> C

    B -- Ý kiến hoặc nhu cầu stakeholder --> G[Stakeholder input<br/>Ghi người nói, vai trò,<br/>thời điểm, bối cảnh]
    G -.-> GN[Lưu ý: bằng chứng chỉ xác minh<br/>người đó đã phát biểu,<br/>không xác minh nội dung]

    B -- Điều tạm coi đúng để tiếp tục phân tích --> H[Project assumption<br/>Ghi lý do, rủi ro,<br/>owner xác minh]

    B -- Lựa chọn giữa các phương án --> I{Có đúng authority?}
    I -- Không --> J{Có stakeholder<br/>đã phát biểu?}
    J -- Có --> G
    J -- Không --> K[Đề xuất chờ quyết định]
    I -- Có --> L{Có phương án, tiêu chí<br/>và artifact ghi nhận?}
    L -- Có --> M[Decision<br/>Ghi authority và trạng thái]
    M -.-> MN[Lưu ý: không suy diễn thành Approval<br/>nếu chưa có bằng chứng approval]
    L -- Không --> N[Thu thập phương án, tiêu chí<br/>và artifact ghi nhận]
    N --> L

    B -- Claim chưa đủ chứng cứ có thể ảnh hưởng<br/>pháp lý, kế toán, bảo mật,<br/>vận hành hoặc thiết kế --> E

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục. Mọi dữ liệu dưới đây là synthetic data.

Trường	Nội dung artifact-ready
Facts	CHAPTER_MANIFEST và CANONICAL_BUSINESS_RULES có trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07. Metadata nêu rõ chưa có baseline reference và chưa có approval reference. Đây là verified fact vì có artifact nguồn kiểm soát.
Current Behavior	Nhân viên Kho mô phỏng nói: “ERP nên chặn xuất kho khi lô hàng chưa có thông tin hạn dùng.” Đây là stakeholder input, chưa phải rule đã xác minh.
Underlying Need	Kho cần tránh giao hàng thiếu dữ liệu truy xuất. Suy luận: nếu thiếu hạn dùng, người dùng khó kiểm tra lô trước xuất; nhưng mức chặn, ngoại lệ và trường dữ liệu bắt buộc chưa được xác nhận.
Options	1. Chặn hoàn toàn mọi xuất kho thiếu hạn dùng. 2. Cảnh báo nhưng cho phép supervisor vượt qua. 3. Chỉ ghi nhận thiếu dữ liệu để xử lý ngoài ERP.
Decision Criteria	Nguồn quy định hiện hành; quy trình kho được Business Owner xác nhận; khả năng dữ liệu nguồn; ảnh hưởng giao hàng; quyền override; bằng chứng test.
Decision	Chưa có quyết định. Ghi Verification required: “Cần Business Owner, Food Safety Owner và Legal Owner xác minh điều kiện xuất kho liên quan hạn dùng cho case mô phỏng.”
Authority	Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì traceability. Không có thẩm quyền tự chọn phương án, xác nhận food-safety compliance, baseline hay approval.
Artifact	Ghi claim trong artifact phân tích của /02-handbook/06-requirements-foundations.md; liên kết quản trị tới CANONICAL_BUSINESS_RULES, TRACEABILITY_ID_REGISTRY và nguồn Luật An toàn thực phẩm tại https://vanban.chinhphu.vn/?docid=96032&pageid=27160. Không diễn giải luật thành rule ERP khi chưa có domain-owner và legal verification.
Consequence if Wrong	Nếu stakeholder input bị ghi thành verified fact, đội kỹ thuật có thể xây chặn xuất kho không có authority. Nếu claim pháp lý bị ghi thành decision, QA có thể test sai basis và governance có thể tưởng nhầm requirement đã được phê duyệt.

Senior Lens

Một câu có thể chứa nhiều loại thông tin. Tách câu thay vì gắn một nhãn cho cả câu. Ví dụ: “Kho hiện nhập hạn dùng thủ công nên hệ thống phải chặn xuất kho” gồm: “nhập thủ công” là verified fact chỉ khi quan sát hoặc log chứng minh; “hệ thống phải chặn” là stakeholder input hoặc proposed option; lý do chặn theo an toàn thực phẩm là verification-required claim nếu chưa được role có thẩm quyền xác minh.

Không dùng trạng thái artifact làm bằng chứng nghiệp vụ. IN_REVIEW chứng minh artifact đang review, không chứng minh nội dung đúng, đã baseline, đã approved, compliant, hay production-ready. Không nâng nhãn chỉ vì phát biểu xuất hiện trong tài liệu có ID canonical.

Quick Reference

Câu hỏi kiểm tra	Nhãn đúng
“Nguồn nào chứng minh điều này?”	Verified fact, nếu nguồn kiểm tra được
“Ai nói họ cần điều này?”	Stakeholder input
“Điều gì đang tạm coi đúng để phân tích tiếp?”	Project assumption
“Ai chọn phương án nào, theo tiêu chí nào?”	Decision
“Điều gì có tác động cao nhưng chưa đủ căn cứ?”	Verification required

3. V? tr? trong Lifecycle

Core

Lifecycle là vòng đời biến một nhu cầu chưa rõ thành thay đổi có thể vận hành. Requirement không “xong” khi được viết. Nó đi qua các cổng vào và cổng ra để giảm dần bất định: Discovery xác định vấn đề; Analysis biến vấn đề thành yêu cầu kiểm chứng được; Delivery xây thay đổi; Testing kiểm tra thay đổi với test basis; Release đưa thay đổi vào môi trường vận hành; Operations quan sát kết quả thực tế và ghi nhận tín hiệu thay đổi mới.

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi dữ liệu là tổng hợp. IN_REVIEW của artifact chỉ nói nội dung đang được xem xét. Nó không chứng minh requirement đã baseline, approved, compliant hoặc production-ready.

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

flowchart TB
    S{Có tín hiệu vấn đề,<br/>cơ hội hoặc rủi ro;<br/>nguồn được ghi và phân loại?}
    N[Chưa khởi tạo lifecycle]
    D[Discovery<br/>Làm rõ outcome, phạm vi ban đầu<br/>và câu hỏi chưa có bằng chứng]

    GDA{Vấn đề được diễn đạt theo outcome;<br/>phạm vi ban đầu và điểm chưa rõ<br/>được phân loại?}

    A[Analysis<br/>Phân tích quy trình, dữ liệu, business rule,<br/>ngoại lệ, rủi ro và acceptance criteria]

    GAV{Requirement và acceptance criteria<br/>đủ rõ để kiểm thử;<br/>dependency, assumption và verification required<br/>còn mở được ghi riêng;<br/>traceability dùng ID canonical?}

    V[Delivery<br/>Thiết kế, cấu hình hoặc xây thay đổi;<br/>không tự diễn giải điểm legal, accounting,<br/>security hoặc architecture]

    GVT{Thay đổi được nhận diện và có thể kiểm thử;<br/>chênh lệch với requirement được ghi?}

    T[Testing<br/>Kiểm tra hành vi, ngoại lệ và dữ liệu biên;<br/>phân biệt defect với thay đổi requirement]

    GTR{Kết quả test, defect và phạm vi chưa kiểm tra<br/>được ghi nhận;<br/>không gọi đạt khi thiếu test basis?}

    R[Release readiness<br/>Kiểm tra package, tác động vận hành,<br/>rollback hoặc kiểm soát áp dụng]

    GR{Có bằng chứng testing theo quy trình;<br/>quyết định phát hành đúng thẩm quyền;<br/>package, rollback hoặc kiểm soát áp dụng<br/>đã sẵn sàng?}

    F[Thực hiện phát hành<br/>Ghi trạng thái thực tế;<br/>không suy ra approval từ deploy]

    GF{Thay đổi đã được phát hành<br/>theo trạng thái thực tế?}

    O[Operations<br/>Theo dõi lỗi, phản hồi người dùng,<br/>chỉ số vận hành và nhu cầu mới]

    GOD{Có tín hiệu mới?<br/>Ghi thành input Discovery mới;<br/>không sửa requirement cũ im lặng}

    S -->|Có| D
    S -->|Chưa có| N

    D --> GDA
    GDA -->|Đủ| A
    GDA -->|Chưa đủ| D

    A --> GAV
    GAV -->|Đủ build basis| V
    GAV -->|Chưa đủ| A

    V --> GVT
    GVT -->|Có thay đổi kiểm thử được và test basis| T
    GVT -->|Chưa đủ| V

    T --> GTR
    GTR -->|Đủ| R
    GTR -->|Thiếu bằng chứng test| T

    R --> GR
    GR -->|Đủ điều kiện| F
    GR -->|Package, rollback, kiểm soát hoặc ghi nhận chưa đủ| R

    F --> GF
    GF -->|Đã phát hành| O
    GF -->|Chưa phát hành| R

    O --> GOD
    GOD -->|Có| D
    GOD -->|Không| O

Giai đoạn	Entry gate: điều kiện được vào	Công việc requirement	Exit gate: điều kiện được ra
Discovery	Có tín hiệu vấn đề, cơ hội hoặc rủi ro; nguồn tín hiệu được ghi là stakeholder input, verified fact, project assumption hoặc verification required	Làm rõ ai bị ảnh hưởng, kết quả cần đạt, phạm vi ban đầu và câu hỏi chưa có bằng chứng	Vấn đề được diễn đạt theo outcome; phạm vi ban đầu và các điểm chưa rõ được phân loại
Analysis	Có vấn đề và phạm vi ban đầu từ Discovery	Phân tích quy trình, dữ liệu, business rule, ngoại lệ, rủi ro và acceptance criteria; nối nguồn với nhận định để thấy reasoning bridge	Requirement đủ rõ để kiểm thử; dependency, assumption và verification required còn mở được ghi riêng; traceability dùng ID canonical từ TRACEABILITY_ID_REGISTRY
Delivery	Có requirement và acceptance criteria làm build basis; điểm thuộc legal, accounting, security hoặc architecture chưa được tự diễn giải	Chuyển requirement thành thiết kế, cấu hình hoặc mã; giữ liên kết với requirement thay vì thay rule bằng suy đoán kỹ thuật	Thay đổi nhận diện được và có thể đưa vào kiểm thử; chênh lệch so với requirement được ghi
Testing	Có thay đổi kiểm thử được và test basis từ Analysis	Kiểm tra hành vi mong đợi, ngoại lệ và dữ liệu biên; phân biệt defect với thay đổi requirement	Kết quả test, defect và phạm vi chưa kiểm tra được ghi; không gọi “đạt” khi test basis thiếu
Release	Có bằng chứng testing theo quy trình dự án và quyết định phát hành thuộc đúng thẩm quyền	Kiểm tra package phát hành, tác động vận hành, rollback hoặc kiểm soát áp dụng	Thay đổi được ghi nhận là phát hành theo trạng thái thực tế; không suy ra approval từ việc deploy
Operations	Thay đổi đã được phát hành theo trạng thái thực tế	Theo dõi lỗi, phản hồi người dùng, chỉ số vận hành và nhu cầu mới	Tín hiệu mới được ghi thành input Discovery; không sửa requirement cũ im lặng để khớp thực tế

Applied

Trường	Nội dung mô phỏng Nova Foods
Facts	Phiếu xuất kho mô phỏng NF-OUT-SYN-014 có trường hạn dùng được nhập thủ công. Đây chỉ là synthetic observation trong case study, chưa là bằng chứng quy trình production.
Current Behavior	Discovery ghi nhận đề xuất: cảnh báo khi người dùng chọn lô có hạn dùng gần. Analysis chưa có ngưỡng ngày, định nghĩa “gần”, hay nguồn rule được xác minh.
Underlying Need	Giảm nguy cơ chọn lô không phù hợp, đồng thời tránh chặn xuất kho bằng quy tắc chưa đủ căn cứ. Reasoning: có thao tác thủ công và có đề xuất cảnh báo, nhưng chưa có business rule xác minh.
Options	(1) Hiển thị cảnh báo không chặn; (2) chặn xuất kho theo ngưỡng cấu hình; (3) giữ hành vi hiện tại và thu thập thêm bằng chứng.
Decision Criteria	Có rule được xác minh; ảnh hưởng an toàn thực phẩm; tác động giao hàng; khả năng kiểm thử; thẩm quyền domain, legal và vận hành.
Decision	Trong trạng thái hiện tại, chỉ ghi verification required cho ngưỡng hạn dùng. Không chuyển sang Delivery với logic chặn.
Authority	BA có thể phân loại bằng chứng và ghi gate. BA không có thẩm quyền xác nhận quy tắc an toàn thực phẩm, quyết định chặn xuất kho hoặc diễn giải luật.
Artifact	Phân tích phải liên kết CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY; các artifact đều IN_REVIEW, v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Nếu Analysis cho qua với rule chưa xác minh, Delivery có thể xây chặn xuất kho sai; Testing sẽ kiểm tra theo basis sai; Release tạo tác động vận hành không có căn cứ.

Senior Lens

Entry gate không phải cuộc họp, tài liệu hay trạng thái ticket. Entry gate là tập điều kiện tối thiểu để công việc giai đoạn sau không phải đoán đầu vào. Ví dụ, một user story có câu “cảnh báo lô sắp hết hạn” chưa đủ entry cho Delivery vì chưa có định nghĩa dữ liệu, điều kiện kích hoạt và hành vi khi cảnh báo xuất hiện.

Exit gate không phải lời xác nhận chung chung như “đã xong”. Exit gate cần bằng chứng phù hợp giai đoạn. Analysis chỉ ra được khi requirement có thể kiểm thử và điểm chưa rõ được gắn nhãn; không cần đợi code. Testing chỉ ra được khi có kết quả kiểm tra được ghi; không tự biến kết quả đó thành quyết định Release.

Khi Operations phát hiện hành vi không đạt, quay về Discovery hoặc Analysis theo loại tín hiệu. Không sửa acceptance criteria sau khi test thất bại để biến kết quả thất bại thành đạt. Lý do: thay đổi test basis sau sự kiện làm mất traceability giữa nhu cầu, build và bằng chứng kiểm thử.

Quick Reference

Nếu thấy	Đặt tại giai đoạn	Gate tối thiểu
“Người dùng nói cần chức năng”	Discovery	Ghi nguồn phát biểu và vấn đề cần giải quyết
“Hệ thống phải làm gì, khi nào, với dữ liệu nào”	Analysis	Có acceptance criteria và điểm chưa rõ được phân loại
“Đã cấu hình hoặc viết mã”	Delivery	Liên kết được thay đổi với requirement
“Đã chạy kiểm tra”	Testing	Có test basis và kết quả ghi nhận
“Đã đưa lên môi trường vận hành”	Release	Ghi trạng thái phát hành thực tế, không suy ra approval
“Người dùng báo lỗi hoặc nhu cầu mới”	Operations rồi Discovery	Ghi tín hiệu thành input mới, giữ lịch sử requirement cũ

Core

Trong Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, handoff là bàn giao trách nhiệm kèm artifact kiểm tra được. Handoff không phải gửi tài liệu rồi đổi owner. Owner trước xác nhận đầu vào đủ; owner sau xác nhận artifact dùng được cho bước mình. Status corpus vẫn IN_REVIEW, version v0.9.0, ngày 2026-08-07; trạng thái này không cấp quyền quyết định nghiệp vụ hay production.

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

flowchart TB
    D[Discovery<br/>Business Owner] -->|Nhu cầu, vấn đề, phạm vi| A[Analysis<br/>BA]
    A -->|Yêu cầu, tiêu chí nghiệm thu, rule, truy vết| DL[Delivery<br/>Architect + Delivery Lead]
    DL -->|Build increment & bằng chứng kỹ thuật| T[Testing<br/>QA Lead]
    T -->|Kết quả test & bằng chứng defect| R[Release<br/>Release Manager]
    R -->|Bản ghi release & ghi chú vận hành| O[Operations<br/>Operations Owner]

    A -. Mâu thuẫn hoặc ảnh hưởng đặc thù<br/>(pháp lý, kế toán, bảo mật, ATTP) .-> E[Escalation<br/>Cấp có thẩm quyền]
    DL -. Tác động kiến trúc/bảo mật .-> E
    T -. Build sai, defect chặn,<br/>hoặc tranh chấp nghiệm thu .-> E
    R -. Rủi ro vận hành<br/>hoặc cần rollback .-> E

Handoff	Upstream owner	Downstream owner	Artifact bàn giao	Quyền quyết định bị giới hạn	Điểm escalation
Nhu cầu sang phân tích	Business Owner	BA	Mục tiêu, pain point, phạm vi giả định	Business Owner nêu cần gì; không tự chọn thiết kế ERP	Mục tiêu mâu thuẫn giữa đơn vị nghiệp vụ
Phân tích sang delivery	BA	Architect, Delivery Lead	Requirement, acceptance criteria, liên kết CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY khi đã có nội dung phù hợp	BA làm rõ và truy vết; không quyết định kiến trúc, bảo mật, kế toán, pháp lý	Rule ảnh hưởng pháp lý, kế toán, dữ liệu cá nhân, an toàn thực phẩm, bảo mật
Delivery sang testing	Delivery Lead	QA Lead	Build increment, cấu hình môi trường, bằng chứng kỹ thuật, test basis	Delivery Lead không tự kết luận chất lượng đạt; QA không sửa ý nghĩa nghiệp vụ	Build khác requirement hoặc thiếu bằng chứng triển khai
Testing sang release	QA Lead	Release Manager	Kết quả test, defect còn mở, rủi ro đã ghi nhận	QA báo bằng chứng chất lượng; không tự cho phép phát hành	Defect chặn, tiêu chí chấp nhận tranh chấp, rủi ro chưa có owner
Release sang operations	Release Manager	Operations Owner	Release record, hướng dẫn vận hành, known issue đã ghi nhận	Release Manager không quyết định chấp nhận rủi ro vận hành; Operations Owner không đổi rule qua miệng	Ảnh hưởng vận hành, truy vết thực phẩm, dữ liệu cá nhân, rollback cần thiết

Applied

Facts: Nova Foods mô phỏng có yêu cầu hiển thị số tài khoản ngân hàng nhà cung cấp trong màn hình duyệt thanh toán. Dữ liệu là tổng hợp. BA nhận yêu cầu từ Business Owner và phát hiện trường này có thể là dữ liệu cá nhân hoặc dữ liệu nhạy cảm theo ngữ cảnh sử dụng.

Current Behavior: Yêu cầu chỉ ghi “Finance xem thông tin nhà cung cấp”, chưa nêu vai trò được xem, mục đích xem, thời hạn lưu hay kiểm soát truy cập.

Underlying Need: Finance cần đối chiếu người thụ hưởng trước thanh toán; nhu cầu này không tự chứng minh mọi người dùng Finance được xem toàn bộ số tài khoản.

Options: Che toàn bộ số tài khoản; hiển thị đầy đủ cho mọi vai trò Finance; che một phần và chỉ cấp đầy đủ cho vai trò được Security và Business Owner xác định.

Decision Criteria: Đủ cho đối chiếu thanh toán; giảm lộ dữ liệu; phù hợp phân quyền; có owner chịu trách nhiệm xác nhận; không biến giả định học liệu thành kết luận pháp lý.

Decision: BA ghi requirement theo phương án che một phần, kèm nhãn Verification required cho phân loại dữ liệu và quyền xem. Đây là quyết định phân tích tạm thời để giữ traceability, không phải quyết định tuân thủ hay cấu hình production.

Authority: Business Owner xác nhận nhu cầu nghiệp vụ; Security Owner xác nhận kiểm soát truy cập; Legal/Compliance Owner xác nhận diễn giải pháp lý nếu áp dụng; Architect xác nhận khả thi kỹ thuật. BA không thay các vai trò này.

Artifact: Requirement và câu hỏi mở phải liên kết đúng /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md khi artifact đó chứa mục tương ứng. Không tạo ID mới trong handoff.

Consequence if Wrong: Cấp quyền quá rộng có thể lộ dữ liệu; che quá mức làm Finance không đối chiếu được; BA tự kết luận pháp lý làm đứt ranh giới thẩm quyền và tạo requirement không có bằng chứng.

Senior Lens

Escalate khi vấn đề đổi ai có quyền quyết định, không chỉ đổi câu chữ. Dấu hiệu rõ: hai owner đưa chỉ dẫn trái nhau; requirement chạm luật, kế toán, thuế, bảo mật hoặc an toàn thực phẩm; Architect nói không khả thi; QA không dựng được test basis từ acceptance criteria; Operations nhận rủi ro chưa có owner. BA đóng gói escalation bằng facts, artifact nguồn, tác động, lựa chọn và câu hỏi quyết định. BA không tự chọn thay owner có thẩm quyền.

Quick Reference

Kiểm tra trước handoff	Đạt khi
Owner nguồn	Có tên vai trò chịu trách nhiệm nội dung
Owner nhận	Biết artifact dùng vào quyết định hay công việc nào
Ranh giới quyền	Không gán BA quyền phê duyệt nghiệp vụ, pháp lý, kế toán, bảo mật, kiến trúc hoặc release
Escalation	Có trigger, owner cần quyết định và bằng chứng kèm theo
Traceability	Giữ nguyên ID, filename, phân loại nguồn; không suy diễn approval từ IN_REVIEW

Core

Bản đồ vòng đời giúp người học thấy requirement đi qua các pha nào trước khi đọc chi tiết gate, owner hoặc handoff. 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, Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07.

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 --> DV[Delivery<br/>Xây dựng cấu hình hoặc phần mềm]
    DV --> T[Testing<br/>Kiểm thử]
    T --> R[Release<br/>Phát hành]
    R --> O[Operations<br/>Vận hành và phản hồi]

    D -. bối cảnh, mục tiêu .-> A
    A -. requirement, rule, acceptance criteria .-> DV
    DV -. bản xây dựng, cấu hình, log kỹ thuật .-> T
    T -. kết quả kiểm thử, lỗi, bằng chứng .-> R
    R -. phiên bản phát hành, hướng dẫn dùng .-> O
    O -. sự cố, phản hồi, số liệu dùng .-> D

Mũi tên liền biểu thị luồng công việc chính. Mũi tên nét đứt biểu thị loại thông tin được chuyển tiếp. Vòng từ Operations về Discovery cho thấy lifecycle không kết thúc khi phát hành: phản hồi vận hành có thể tạo nhu cầu phân tích mới. Sơ đồ là flowchart Mermaid, không phải BPMN; BPMN 2.0.2 của OMG mới là nguồn chuẩn cho ký pháp BPMN.

Applied

Mục	Nội dung mô phỏng Nova Foods
Facts	Nhân viên kho ghi nhận có lô hàng thành phẩm cần tra cứu khiếu nại khách hàng.
Current Behavior	Nhu cầu được mô tả bằng lời, chưa cho thấy nó trở thành yêu cầu, bản xây dựng, kiểm thử hay phản hồi vận hành.
Underlying Need	Cần nhìn một chuỗi chung để không nhầm “đã nêu vấn đề” với “đã phát hành thay đổi”.
Options	Dùng đoạn văn dài; dùng bảng pha; dùng sơ đồ Mermaid.
Decision Criteria	Người mới quét được thứ tự; mỗi pha có đầu ra dễ nhận biết; sơ đồ hiển thị được trong Markdown.
Decision	Dùng sơ đồ Mermaid sáu pha và gắn nhãn thông tin chuyển tiếp. Lý do: sơ đồ giữ thứ tự cùng dấu vết thông tin trên một khung nhìn.
Authority	Đây là ví dụ học liệu IN_REVIEW; không xác nhận quy trình ERP thực, không tạo approval hay baseline.
Artifact	/02-handbook/06-requirements-foundations.md, section 03-lifecycle.
Consequence if Wrong	Nếu đặt Testing trước Delivery, người học có thể hiểu sai test basis; nếu bỏ Operations, phản hồi thực tế không quay lại chuỗi phân tích.

Senior Lens

Sơ đồ lifecycle không thay thế requirement, business rule, test case hoặc release record. Nó chỉ trả lời câu hỏi “thông tin đi qua đâu”. Evidence bridge: mỗi pha tạo loại thông tin khác nhau, nên một sơ đồ gắn nhãn đầu ra làm lộ chỗ đứt traceability trước khi tài liệu chi tiết được soạn.

Không suy diễn nghĩa vụ pháp lý, kế toán, thuế, bảo vệ dữ liệu hay an toàn thực phẩm từ sơ đồ này. Khi một thay đổi có tác động các lĩnh vực đó, cần giữ nhãn Verification required và chuyển phần kết luận cho owner có thẩm quyền.

Quick Reference

Ký hiệu	Nghĩa
Discovery	Làm rõ vấn đề, mục tiêu, bối cảnh.
Analysis	Chuyển nhu cầu thành requirement có thể xây và kiểm thử.
Delivery	Tạo cấu hình, mã nguồn hoặc thành phần kỹ thuật.
Testing	Đối chiếu kết quả với test basis.
Release	Đưa thay đổi đã chuẩn bị vào trạng thái phát hành.
Operations	Dùng, theo dõi, ghi nhận phản hồi và sự cố.

4. Input c?n thi?t

Core

Input là thứ BA nhận trước khi viết requirement. Người mới không cần biết ERP, API hay cơ sở dữ liệu để bắt đầu. Cần phân biệt bốn loại:

Loại input	Trả lời câu hỏi	Ví dụ Nova Foods mô phỏng
Kiến thức nền	Đang phân tích lĩnh vực nào?	ERP ghi nhận mua hàng, tồn kho, sản xuất, bán hàng và kế toán trong cùng hệ thống.
Evidence (bằng chứng)	Điều gì cho thấy vấn đề hoặc nhu cầu tồn tại?	Bảng tổng hợp dữ liệu mô phỏng cho thấy cùng một mã nguyên liệu xuất hiện dưới hai cách viết.
Source artifact (artifact nguồn)	Thông tin đang nằm trong tệp kiểm soát nào?	/01-curriculum/CANONICAL_DATA_DICTIONARY.md
Canonical ID (định danh chuẩn)	Làm sao tham chiếu đúng cùng một đối tượng qua nhiều tài liệu?	CANONICAL_DATA_DICTIONARY

ERP (Enterprise Resource Planning, hệ thống hoạch định nguồn lực doanh nghiệp) không phải một “phần mềm biết mọi thứ”. Nó chỉ lưu, xử lý và liên kết dữ liệu theo quy tắc được xác định. Nếu BA nhận yêu cầu “sửa tồn kho”, BA cần biết tồn kho nào, dữ liệu nào chứng minh vấn đề, và artifact nào là nguồn tham chiếu. Không có ba điểm này, requirement thành suy đoán.

Canonical ID là chuỗi định danh giữ nguyên qua phiên bản, đường dẫn và người đọc. Tên hiển thị có thể dịch hoặc đổi cách trình bày; canonical ID không đổi tùy tiện. Evidence bridge: hai tài liệu cùng tham chiếu TRACEABILITY_ID_REGISTRY thì người đọc kiểm tra được chúng đang nói về cùng registry, không phải hai danh sách ID khác nhau.

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

flowchart TB
    K[Kiến thức nền] --> P[Xác định tồn kho hoặc phạm vi cần phân tích]
    E[Evidence] --> D[Xác nhận vấn đề hoặc nhu cầu bằng dữ liệu]
    S[Source artifact] --> A[Xác định artifact nguồn tham chiếu]
    I[Canonical ID] --> N[Nối cùng đối tượng qua nhiều tài liệu]

    P --> R[Requirement có căn cứ và traceability]
    D --> R
    A --> R
    N --> R

Applied

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục. Toàn bộ giá trị dưới đây là dữ liệu tổng hợp, không mô tả doanh nghiệp thật hay cấu hình ERP thật.

Mục bắt buộc	Nội dung
Facts	Learner nhận yêu cầu mô phỏng: “Cần tránh tạo trùng nguyên liệu khi nhập mua hàng.” Dữ liệu minh họa có Đường trắng 50kg và Duong trang 50 KG.
Current Behavior	Hai cách viết có thể được người dùng xem là cùng nguyên liệu, nhưng chưa có evidence cho biết ERP mô phỏng đang cho phép tạo hai mã hàng hay chỉ hiển thị hai nhãn.
Underlying Need	Phân biệt vấn đề dữ liệu, quy tắc đặt tên, tìm kiếm hay kiểm soát tạo mới trước khi viết requirement.
Options	(1) Viết ngay rule cấm trùng tên. (2) Đối chiếu evidence với data dictionary và ID registry trước.
Decision Criteria	Giữ được nguồn gốc kết luận; không biến ví dụ dữ liệu thành quy tắc vận hành; dùng đúng artifact canonical.
Decision	Chọn phương án (2). Evidence bridge: yêu cầu chỉ nêu kết quả mong muốn; chưa nêu trường dữ liệu, tiêu chí trùng hay owner quyết định quy tắc.
Authority	Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì học liệu IN_REVIEW; không xác nhận rule Nova Foods, không tạo baseline, không thay Business Owner hoặc Data Owner.
Artifact	CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md; TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md.
Consequence if Wrong	Nếu BA tự kết luận “trùng tên” nghĩa là “trùng nguyên liệu”, hệ thống có thể chặn hai nguyên liệu khác nhau có tên gần giống hoặc vẫn bỏ lọt bản ghi trùng theo mã nhà cung cấp.

Danh mục input tối thiểu cho ví dụ này:

Canonical ID	Tệp nguồn canonical	Input cần lấy	Vai trò phân tích
CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Đường dẫn chapter, phạm vi handbook, trạng thái IN_REVIEW, version v0.9.0.	Xác định đây là học liệu, không phải requirement production.
TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Quy tắc đăng ký và tham chiếu ID.	Ngăn BA tự tạo ID hoặc đổi ID theo ý.
CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Khái niệm dữ liệu logic, tên trường và ý nghĩa dữ liệu khi đã được catalog.	Kiểm tra “nguyên liệu”, “mã”, “tên” là các khái niệm khác nhau.
CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Rule đã được catalog ở mức kế hoạch.	Không biến nhận xét từ ví dụ thành rule canonical.
00_SOURCE_MAP	/00-research/00_SOURCE_MAP.md	Nguồn chuẩn, URL chính thức và ranh giới dùng nguồn.	Tách kiến thức nghề BA khỏi kết luận pháp lý hoặc vận hành.

Senior Lens

Không gọi một cuộc trao đổi miệng là evidence đủ để khóa requirement. Nó có thể là tín hiệu cần phân tích, nhưng chưa chứng minh định nghĩa dữ liệu, quy tắc hoặc hành vi hệ thống. Evidence bridge: requirement cần được xây và kiểm thử; nếu nguồn không chỉ rõ đối tượng, điều kiện và kết quả, người xây lẫn người kiểm thử sẽ diễn giải khác nhau.

Không dùng tên tệp gần giống thay canonical ID. Ví dụ, CANONICAL_DATA_DICTIONARY khác CANONICAL_BUSINESS_RULES: tệp thứ nhất nói dữ liệu là gì; tệp thứ hai nói hành vi nào được phép hoặc bắt buộc. Trộn hai loại này làm BA biến định nghĩa thành mệnh lệnh hoặc biến rule thành tên trường.

Quick Reference

Thuật ngữ	Nghĩa ngắn
Input	Thông tin BA nhận để phân tích.
Evidence	Bằng chứng liên kết nhu cầu với sự kiện, dữ liệu hoặc nguồn ghi nhận.
Source artifact	Tệp nguồn được kiểm soát chứa thông tin tham chiếu.
Canonical ID	Định danh chuẩn, giữ nguyên để truy vết đúng đối tượng.
Traceability	Khả năng lần từ requirement về nguồn và lần tiếp đến đầu ra liên quan.
Project assumption	Giả định dùng cho phân tích học liệu; không phải sự thật vận hành.

Core

Input là thông tin BA dùng để hiểu vấn đề trước khi viết yêu cầu. Input chỉ đáng dùng khi kiểm được nguồn, người chịu trách nhiệm, thời điểm còn hiệu lực và giới hạn sử dụng. Với Nova Foods Trading & Manufacturing mô phỏng, mọi dữ liệu là tổng hợp; IN_REVIEW, v0.9.0, ngày 2026-08-07 không phải baseline hay phê duyệt.

Phân loại nguồn	Ý nghĩa	Ví dụ nguồn canonical	Được dùng để	Không được suy ra
Primary source	Nguồn do cơ quan, tổ chức hoặc chủ thể có thẩm quyền phát hành	00_SOURCE_MAP; URL ISO, IIBA, W3C, Quốc hội, Chính phủ đã ghi nhận	Thuật ngữ, trạng thái công bố, phạm vi tham chiếu	Điều khoản chưa kiểm licensed text; nghĩa vụ Nova Foods thực tế
Controlled internal artifact	Tệp corpus có ID, đường dẫn, version, status	TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY	ID canonical, phạm vi, dependency, governance	Quyết định nghiệp vụ, pháp lý, kế toán đã được chấp thuận
Stakeholder evidence	Bằng chứng từ người vận hành hoặc chủ sở hữu nghiệp vụ	Biên bản phỏng vấn mô phỏng, quy trình mô phỏng	Hiểu hành vi hiện tại, vấn đề, ngoại lệ	Quy tắc bắt buộc nếu chưa xác nhận thẩm quyền
Project assumption	Giả định tạm để tiếp tục phân tích	“Nova Foods dùng VND”	Dựng ví dụ và câu hỏi xác minh	Fact, policy, compliance requirement
Verification required	Điểm chưa đủ bằng chứng hoặc cần thẩm quyền chuyên môn	Diễn giải Luật Kế toán, Nghị định 123/2020/NĐ-CP	Lập danh sách cần xác minh	Requirement bắt buộc, acceptance criteria cuối

Kiểm chất lượng từng input bằng năm câu hỏi: (1) Có ID hoặc URL canonical không? (2) Issuer và owner có thẩm quyền cho loại quyết định này không? (3) Nội dung còn mới tại 2026-08-07 không? (4) Nội dung có mâu thuẫn artifact canonical khác không? (5) Có ghi rõ fact, assumption hay Verification required không? Một câu trả lời “không” tại câu 1, 2 hoặc 4 làm input không đủ điều kiện tạo requirement.

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

flowchart TB
    A[Nhận input] --> B{Có ID hoặc URL canonical?}
    B -- Không --> S[STOP: không tạo requirement]
    B -- Có --> C{Issuer và owner đúng thẩm quyền?}
    C -- Không --> E[Escalate đúng owner]
    E --> S
    C -- Có --> D{Mâu thuẫn artifact canonical khác?}
    D -- Có --> M[Không đủ điều kiện tạo requirement]
    M --> S
    D -- Không --> F{Còn hiệu lực?}
    F -- Không --> V[Verification required:<br/>chỉ lập câu hỏi/danh sách xác minh]
    F -- Có --> G{Chưa đủ bằng chứng hoặc cần<br/>thẩm quyền chuyên môn?}
    G -- Có --> V
    V --> S
    G -- Không --> H{Trạng thái input?}
    H -- Fact --> I[Fact có nguồn và thẩm quyền]
    I --> R[Đủ điều kiện phân tích<br/>và làm cơ sở requirement]
    H -- Assumption --> J[Assumption: không làm cơ sở requirement]
    J --> K[Chỉ dùng cho ví dụ<br/>và câu hỏi xác minh]
    H -- Verification required --> V

Applied

Facts: Nova Foods là case mô phỏng giáo dục; locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND. CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY có status IN_REVIEW, version v0.9.0.

Current Behavior: BA nhận một câu “ERP phải xuất hóa đơn đúng luật” từ ghi chú workshop mô phỏng, nhưng ghi chú không có Legal Owner, không có ngày hiệu lực, không dẫn điều khoản pháp lý.

Underlying Need: Phân biệt ý kiến workshop với nguồn pháp lý và ngăn câu chưa xác minh biến thành yêu cầu bắt buộc.

Options: Dùng ngay như business rule; ghi thành project assumption; gắn Verification required và dừng phần yêu cầu pháp lý.

Decision Criteria: Có nguồn official còn hiệu lực; có Legal Owner xác minh diễn giải; có liên kết requirement tới evidence; không vượt thẩm quyền curriculum owner.

Decision: Gắn Verification required; chỉ ghi nhu cầu phân tích hóa đơn, không viết nghĩa vụ tuân thủ cụ thể.

Authority: Legal Owner xác minh pháp lý; Accounting Owner xác minh hạch toán; Business Owner xác nhận nhu cầu nghiệp vụ. Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì traceability.

Artifact: Tham chiếu 00_SOURCE_MAP, URL Nghị định 123/2020/NĐ-CP, và dòng open verification trong artifact yêu cầu tương lai.

Consequence if Wrong: Requirement có thể sai luật hiện hành, sai phạm vi hóa đơn, hoặc bị hiểu nhầm là cam kết production của Nova Foods.

Senior Lens

Freshness là độ mới của input so với quyết định đang phân tích. Không dùng một ngày chung cho mọi loại nguồn. Nguồn pháp lý cần kiểm hiệu lực và sửa đổi trước khi dùng; nguồn tiêu chuẩn cần kiểm version; stakeholder evidence cần ghi ngày ghi nhận; controlled artifact cần khớp version và status. Tại corpus này, ngày truy cập URL là 2026-08-07; ngày đó chứng minh thời điểm kiểm URL, không chứng minh nội dung licensed text đã được đọc.

Owner là người trả lời đúng loại câu hỏi, không phải người đang giữ tệp. Owner của TRACEABILITY_ID_REGISTRY quản trị ID; không có quyền xác nhận rule nghiệp vụ. Legal Owner xác minh diễn giải luật; không tự quyết kiến trúc ERP. Một input có thể có nhiều owner; khi vậy phải tách câu hỏi theo thẩm quyền, không lấy một xác nhận thay cho tất cả.

Quick Reference

Kiểm tra	Pass	Stop condition
Source classification	Có nhãn primary source, controlled internal artifact, stakeholder evidence, project assumption hoặc Verification required	Không rõ nguồn hoặc nhãn bị trộn
Freshness	Có version, effective date, access date hoặc recorded date phù hợp	Nguồn bị thay thế, chưa kiểm hiệu lực, hoặc không có ngày
Ownership	Có vai trò chịu trách nhiệm đúng lĩnh vực	Owner vượt thẩm quyền hoặc chưa xác định
Traceability	Giữ nguyên ID, filename, URL, version, status	ID tự tạo, tên tệp biến thể, URL không kiểm
Conflict	Không mâu thuẫn nguồn canonical; mâu thuẫn được ghi nhận	Mâu thuẫn chưa phân giải nhưng vẫn viết requirement
Legal/accounting/food safety	Có owner chuyên môn xác minh trước khi nêu nghĩa vụ	Diễn giải thành yêu cầu bắt buộc từ nguồn chưa xác minh

Core

Bảng dưới là inventory đầu vào cho Nova Foods Trading & Manufacturing — mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Mỗi dòng giữ ID, tệp nguồn, phân loại và điểm chưa xác minh. IN_REVIEW tại v0.9.0 không phải baseline hay phê duyệt.

Input ID	Đầu vào	Giá trị mô phỏng	Nguồn canonical	Phân loại nguồn	Freshness	Owner ghi nhận	Trạng thái xác minh
INP-NF-001	Bối cảnh doanh nghiệp	Nova Foods bán và sản xuất thực phẩm; tiền tệ VND; locale vi-VN	/01-curriculum/CHAPTER_MANIFEST.md	Controlled planning artifact	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Đã ghi nhận; chỉ là case study
INP-NF-002	Trạng thái quản trị	IN_REVIEW, v0.9.0, Asia/Ho_Chi_Minh	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Controlled planning artifact	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Đã ghi nhận; không suy ra approval
INP-NF-003	Quy tắc nghiệp vụ	Catalog quy tắc chưa là quyết định vận hành	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Controlled planning artifact	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Verification required: Business Owner xác nhận quy tắc thực tế
INP-NF-004	Định nghĩa dữ liệu	Kế hoạch từ điển dữ liệu logic canonical	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Controlled planning artifact	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Verification required: Data Owner xác nhận nghĩa và nguồn dữ liệu
INP-NF-005	ID truy vết	Registry ID canonical cho corpus	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Controlled planning artifact	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Đã ghi nhận; không tự tạo ID thay thế
INP-NF-006	Thuật ngữ BA	BA knowledge areas, tasks, competencies, terminology	https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/	Verified primary source	2026-08-07	IIBA	Đã xác minh URL; licensed text cần truy cập hợp lệ
INP-NF-007	Chất lượng requirements	ISO/IEC/IEEE 29148:2018, Edition 2	https://www.iso.org/standard/72089.html	Verified primary source	2026-08-07	ISO/IEC/IEEE	Verification required: clause cụ thể cần licensed-text verification
INP-NF-008	Nghĩa vụ dữ liệu cá nhân	Luật 91/2025/QH15, hiệu lực 2026-01-01	https://vanban.chinhphu.vn/?classid=1&docid=214590&pageid=27160&typegroup=	Verified legal source	2026-08-07	Quốc hội Việt Nam	Verification required: Legal Owner xác nhận requirement dự án
INP-NF-009	Bối cảnh an toàn thực phẩm	Luật 55/2010/QH12	https://vanban.chinhphu.vn/?docid=96032&pageid=27160	Verified legal source	2026-08-07	Quốc hội Việt Nam	Verification required: Domain Owner và Legal Owner xác nhận áp dụng

Applied

Trường	Nội dung
Facts	INP-NF-003 mô tả catalog quy tắc ở trạng thái IN_REVIEW. INP-NF-008 là nguồn pháp lý đã kiểm URL, nhưng chưa có kết luận Legal Owner cho Nova Foods mô phỏng.
Current Behavior	Người học có thể đọc catalog và nguồn luật, nhưng không được biến nội dung đó thành cấu hình ERP hoặc nghĩa vụ pháp lý.
Underlying Need	Phân biệt bằng chứng đã tồn tại với kết luận chưa có thẩm quyền xác nhận.
Options	Dùng catalog như quy tắc đã chốt; hoặc giữ nhãn Verification required và dừng suy diễn.
Decision Criteria	Có nguồn canonical; nguồn còn mới tại 2026-08-07; đúng owner chuyên môn; không có approval hoặc baseline giả định.
Decision	Giữ INP-NF-003, INP-NF-004, INP-NF-008, INP-NF-009 là đầu vào tham khảo có nhãn chưa xác minh. Không tạo requirement bắt buộc từ các dòng này.
Authority	Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì traceability. Business Owner, Data Owner, Domain Owner, Legal Owner giữ thẩm quyền xác nhận tương ứng.
Artifact	/01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md; 00_SOURCE_MAP.
Consequence if Wrong	Requirement có thể gán sai trách nhiệm, diễn giải sai luật, hoặc tạo rule ERP không có nguồn quyết định hợp lệ.

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

flowchart TB
    A["INP-NF-003<br/>Catalog: IN_REVIEW"] --> U["Đầu vào tham khảo<br/>Verification required"]
    B["INP-NF-004<br/>Chưa xác minh"] --> U
    C["INP-NF-008<br/>URL đã kiểm<br/>Chưa có kết luận Legal Owner"] --> U
    D["INP-NF-009<br/>Chưa xác minh"] --> U

    U --> S{"Nguồn canonical<br/>và còn mới tại 2026-08-07?"}
    S -- "Không" --> T["Giữ traceability và nhãn trạng thái"]
    S -- "Có" --> M{"Miền cần xác nhận?"}

    M -- "Business" --> BO["Business Owner xác nhận<br/>chỉ miền Business"]
    M -- "Data" --> DO["Data Owner xác nhận<br/>chỉ miền Data"]
    M -- "Domain" --> XO["Domain Owner xác nhận<br/>chỉ miền Domain"]
    M -- "Legal" --> LO["Legal Owner xác nhận<br/>chỉ miền Legal"]

    BO --> V["Xác nhận một miền<br/>không xác nhận miền còn lại"]
    DO --> V
    XO --> V
    LO --> V

    V --> G{"Có approval hoặc baseline<br/>được xác nhận?"}
    G -- "Không<br/>Hiện trạng" --> T
    G -- "Có" --> E["Evidence đủ điều kiện<br/>cho quy trình quyết định requirement riêng"]

    P["Principal IT Business Analyst /<br/>Technical Curriculum Author"] -- "Chỉ duy trì traceability;<br/>không xác nhận nội dung" --> T

    T --> F["Không suy diễn requirement bắt buộc"]
    F --> N["Không chuyển thành cấu hình ERP<br/>hoặc nghĩa vụ pháp lý"]

    N -. "Nếu vượt ranh giới" .-> R["Gán sai trách nhiệm<br/>Diễn giải sai luật<br/>Tạo rule ERP không có nguồn quyết định hợp lệ"]

Senior Lens

“Đã có nguồn” khác “đã xác nhận áp dụng”. URL chính thức chứng minh vị trí nguồn; không tự chứng minh điều khoản nào áp dụng cho Nova Foods. Artifact IN_REVIEW chứng minh nội dung đang được quản trị; không chứng minh nội dung đúng cho vận hành. Nhãn chưa xác minh phải ở ngay dòng input, không giấu trong ghi chú cuối bảng.

Quick Reference

Nhãn	Nghĩa dùng trong bảng
Verified primary source	URL và metadata nguồn đã được kiểm tại 2026-08-07; phạm vi dùng bị giới hạn theo source seed.
Verified legal source	Nguồn luật chính thức; cần Legal Owner hoặc owner chuyên môn xác nhận trước khi suy ra requirement.
Controlled planning artifact	Artifact corpus có ID, version, status; không phải bằng chứng vận hành, baseline hay approval.
Verification required	Không đủ bằng chứng hoặc thẩm quyền để kết luận; không được chuyển thành rule, scope hoặc acceptance criterion.

5. Step-by-step BA Activities

Applied

Quy trình này biến input thành requirement có thể review và bàn giao có kiểm soát. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp. IN_REVIEW, v0.9.0, ngày 2026-08-07 không phải baseline, approval, xác nhận pháp lý hay quyết định triển khai.

1. Principal IT Business Analyst / Technical Curriculum Author chuẩn bị phạm vi. Actor đọc mục tiêu thay đổi, artifact upstream, ID canonical và source boundary trước khi phỏng vấn hoặc viết requirement. Object gồm /01-curriculum/CHAPTER_MANIFEST.md, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và 00_SOURCE_MAP. Evidence tạo ra là danh sách input có đường dẫn, version, status, owner và nhãn Verification required nếu thiếu nguồn hoặc thẩm quyền. Decision rule: chỉ dùng input có định danh và nguồn gốc rõ; input mâu thuẫn không được hợp nhất bằng suy đoán. Quality gate: từng input phân biệt rõ Verified primary source, Verified legal source hoặc Controlled planning artifact. Escalation route: xung đột ID sang Principal IT Business Analyst / Technical Curriculum Author; vấn đề luật sang Legal Owner; kế toán sang Accounting Owner; dữ liệu sang Data Owner.

2. BA xác định vấn đề và ranh giới. Actor phân tách triệu chứng quan sát được, nguyên nhân chưa chứng minh, nhu cầu nghiệp vụ và ngoài phạm vi. Object là mô tả thay đổi Nova Foods mô phỏng, ví dụ chênh lệch giữa luồng nhận đơn và thông tin cần cho giao hàng. Evidence tạo ra là problem statement, scope boundary, assumption register và câu hỏi mở. Decision rule: chỉ ghi “Underlying Need” khi Facts và Current Behavior dẫn tới nhu cầu đó bằng lý do nêu rõ; nếu chưa đủ, giữ Verification required. Quality gate: không biến giải pháp mong muốn thành vấn đề; không gọi assumption là fact. Escalation route: tranh chấp ưu tiên hoặc scope sang Business Owner; tác động vận hành sang Domain Owner.

3. BA thu thập và chuẩn hóa evidence. Actor phỏng vấn, quan sát quy trình mô phỏng, đọc artifact và đối chiếu thuật ngữ. Object là fact, rule, data field, actor, trigger, exception và dependency. Evidence tạo ra là ghi chép nguồn, bảng fact-to-source và danh sách điểm chưa xác minh. Decision rule: mỗi fact phải có nguồn, người cung cấp hoặc artifact; phát biểu không truy vết chỉ là giả định. Quality gate: giữ nguyên ID, filename và source classification; không tạo quotation hoặc clause không có văn bản được kiểm. Escalation route: nguồn luật hoặc tuân thủ sang Legal Owner; quy tắc an toàn thực phẩm sang Domain Owner và Legal Owner; rủi ro bảo mật sang Security Owner.

4. BA mô hình hóa hành vi hiện tại và nhu cầu. Actor mô tả luồng hiện tại bằng ngôn ngữ kiểm tra được: trigger, actor, input, xử lý, output, exception và kết quả. Object là Current Behavior và Underlying Need đã có evidence. Evidence tạo ra là process note, danh sách business rule candidate và data impact candidate. Decision rule: một bước chỉ được coi là rule khi có điều kiện và kết quả xác định; nếu là thói quen người dùng, ghi là current practice. Quality gate: mọi suy luận phải nối được theo chuỗi Facts, reasoning, Underlying Need. Escalation route: không thống nhất cách vận hành sang Domain Owner; ảnh hưởng kiến trúc hoặc integration sang Architect.

5. BA tạo và so sánh options. Actor nêu tối thiểu phương án không thay đổi, thay đổi quy trình, hoặc thay đổi hệ thống khi phù hợp với evidence. Object là Options, tác động dữ liệu, chi phí học liệu, rủi ro và dependency. Evidence tạo ra là decision log chứa Decision Criteria. Decision rule: chọn phương án đáp ứng Underlying Need, không vi phạm scope, không giả định nghĩa vụ luật hoặc cấu hình ERP chưa xác minh. Quality gate: tiêu chí gồm giá trị nghiệp vụ, khả năng kiểm thử, dữ liệu cần có, rủi ro và owner quyết định. Escalation route: lựa chọn tác động kiến trúc sang Architect; tác động quyền truy cập sang Security Owner; tác động thuế, hóa đơn hoặc kế toán sang Accounting Owner và Legal Owner.

6. BA viết requirement và acceptance criteria. Actor chuyển Decision thành requirement rõ điều kiện, hành vi mong đợi, dữ liệu, ngoại lệ và tiêu chí chấp nhận. Object là requirement draft liên kết Facts, Current Behavior, Underlying Need, Decision và Artifact nguồn. Evidence tạo ra là requirement record có traceability link. Decision rule: requirement phải độc lập với giải pháp trừ khi Authority đã quyết định giải pháp; nội dung chưa xác minh không được viết dạng bắt buộc. Quality gate: reviewer có thể xác định pass hoặc fail từ acceptance criteria mà không cần hỏi lại tác giả. Escalation route: mơ hồ nghiệp vụ sang Business Owner; thiếu dữ liệu sang Data Owner; không kiểm thử được sang QA Owner.

7. BA điều phối review có kiểm soát. Actor gửi review package cho đúng owner theo loại quyết định, ghi nhận comment và phân loại accepted, rejected hoặc Verification required. Object là requirement draft, decision log, assumption register và traceability. Evidence tạo ra là review record nêu người review, thời điểm theo Asia/Ho_Chi_Minh, comment, phản hồi và unresolved issue. Decision rule: comment chỉ đóng khi có lý do, evidence và owner phù hợp; im lặng không phải approval. Quality gate: không còn mâu thuẫn chưa gắn escalation route; trạng thái artifact vẫn IN_REVIEW nếu chưa có tham chiếu approval được ghi nhận. Escalation route: bất đồng không giải quyết được sang Business Owner; tranh chấp thẩm quyền sang Principal IT Business Analyst / Technical Curriculum Author để lập gói vấn đề, không tự quyết thay owner.

8. BA bàn giao có kiểm soát. Actor phát hành package review cho người tiêu thụ tiếp theo, giữ nguyên ID, filename, version, source classification và trạng thái. Object là requirement record, traceability, unresolved issue list và giới hạn sử dụng. Evidence tạo ra là handoff record nêu artifact gửi đi, phiên bản, người nhận, mục đích sử dụng và điều kiện còn mở. Decision rule: chỉ bàn giao nội dung đủ quality gate; nội dung Verification required phải đi kèm nhãn và không được dùng làm test basis hoặc cấu hình bắt buộc. Quality gate: người nhận truy được từ requirement về evidence và owner quyết định; package không tuyên bố baseline hoặc approval khi chưa có reference. Escalation route: thiếu traceability quay lại BA; phát hiện thay đổi nguồn canonical quay lại owner artifact để kiểm soát version.

Core

Mỗi bước BA phải là đơn vị thực thi và kiểm tra được, không chỉ là động từ như “phân tích” hoặc “xác nhận”. BA ghi đủ bảy thành phần: actor là vai trò thực hiện; action là thao tác; object là artifact, dữ liệu hoặc quyết định bị tác động; evidence produced là bằng chứng tạo ra; decision rule là điều kiện chọn hướng; quality gate là điều kiện cho phép qua bước; escalation route là vai trò nhận vấn đề vượt thẩm quyền. Cấu trúc này biến trao đổi thành traceability, tức khả năng lần ngược từ kết luận về bằng chứng và người chịu trách nhiệm.

Thành phần	Câu hỏi bắt buộc	Không chấp nhận
Actor	Ai làm, ai có thẩm quyền kết luận?	“Nhóm dự án” không phân vai
Action	Người đó làm thao tác nào?	“Xử lý”, “xem xét” không tiêu chí
Object	Tác động lên requirement, rule, dữ liệu hay quy trình nào?	Đối tượng không có ID hoặc nguồn
Evidence produced	Tạo biên bản, bảng đối chiếu, quyết định hay log nào?	Kết luận chỉ dựa trên lời kể
Decision rule	Điều kiện nào dẫn đến chấp nhận, từ chối, giữ mở?	Chọn theo cảm nhận cá nhân
Quality gate	Kiểm tra nào phải đạt trước bước sau?	Chuyển bước khi còn mâu thuẫn trọng yếu
Escalation route	Ai xử lý xung đột hoặc rủi ro ngoài thẩm quyền BA?	BA tự quyết pháp lý, kế toán, kiến trúc, bảo mật

Senior Lens

Evidence không đồng nghĩa approval. Artifact mang IN_REVIEW, v0.9.0, ngày 2026-08-07 chỉ chứng minh nội dung đang được kiểm soát xem xét. Không suy ra baseline, phê duyệt người dùng, tuân thủ pháp lý, cấu hình ERP thực tế hoặc quyền triển khai production. Khi evidence cho thấy câu hỏi liên quan pháp lý, kế toán, an toàn thực phẩm, bảo mật hoặc kiến trúc, BA giữ nguyên nhãn Verification required, lập gói vấn đề và chuyển đúng owner.

Quick Reference

Loại vấn đề	Bằng chứng tối thiểu	Route escalation
Quy tắc nghiệp vụ mâu thuẫn	Bảng so sánh nguồn, ID rule, tác động	Business Owner
Thuế, hóa đơn, hạch toán	Nguồn chính thức, giả định dự án, điểm chưa xác minh	Accounting Owner và Legal Owner
Dữ liệu cá nhân	Trường dữ liệu, mục đích xử lý, luồng truy cập mô phỏng	Legal Owner và Security Owner
API, tích hợp, kiến trúc	Sơ đồ luồng, hệ thống nguồn/đích, lỗi giả định	Architect
Tiêu chí kiểm thử thiếu	Requirement, acceptance criteria, dữ liệu kiểm thử tổng hợp	QA Reviewer

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp. Bảng dưới ghi một lần xử lý yêu cầu ERP về chặn xuất kho khi lô hàng chưa có trạng thái kiểm tra chất lượng phù hợp. Mục tiêu: biến quan sát vận hành thành đối tượng review có thể truy vết; không xác nhận cấu hình production, tuân thủ pháp lý, hay phê duyệt.

Thành phần	Thực thi Nova Foods
Facts	Phiếu xuất kho mô phỏng DO-SIM-2026-081 có mặt hàng NF-MILK-01, lô LOT-SIM-260807-A, số lượng 120 thùng, giá trị mô phỏng 48.000.000 VND. Người dùng kho ghi nhận hệ thống cho tạo phiếu dù trường QC Status trống. Bằng chứng: ảnh màn hình mô phỏng, nhật ký giao dịch tổng hợp, bản ghi workshop ngày 2026-08-07 theo Asia/Ho_Chi_Minh.
Current Behavior	ERP mô phỏng chỉ kiểm tra tồn kho đủ số lượng trước khi xác nhận xuất. Không có điểm kiểm tra QC Status. Suy luận: phiếu xuất được tạo khi trạng thái chất lượng trống; bằng chứng là nhật ký tổng hợp có DO-SIM-2026-081 ở trạng thái Confirmed.
Underlying Need	Kho cần ngăn hàng chưa được đánh giá chất lượng đi vào luồng xuất. Đây là nhu cầu kiểm soát nghiệp vụ, chưa phải kết luận nghĩa vụ pháp lý hay cấu hình bắt buộc.
Options	O1: cho xuất, kiểm tra thủ công bằng bảng tính. O2: ERP chặn xác nhận xuất khi QC Status khác Released. O3: ERP cho xuất nhưng tạo cảnh báo.
Decision Criteria	Ngăn sai sót trước giao hàng; bằng chứng kiểm tra truy vết được; không cho người dùng kho tự bỏ qua kiểm soát; ảnh hưởng xử lý ngoại lệ rõ; không suy diễn quy định an toàn thực phẩm từ nguồn chưa được xác minh.
Decision	Đề xuất O2 cho luồng chuẩn: chỉ QC Status = Released mới xác nhận xuất. Lô Blocked, Pending hoặc trống phải dừng. Ngoại lệ cần Business Owner và Quality Owner xác định trong artifact kiểm soát; chưa ghi nhận ngoại lệ nào.
Authority	Quality Owner xác nhận nghĩa trạng thái chất lượng. Business Owner xác nhận tác động vận hành. Solution Architect xác nhận điểm kiểm tra ERP và tích hợp. Legal/Compliance Owner xác minh nếu yêu cầu được liên hệ nghĩa vụ pháp lý hoặc an toàn thực phẩm. BA giữ traceability, không thay các thẩm quyền này.
Artifact	Bản ghi yêu cầu và quyết định review thuộc /02-handbook/06-requirements-foundations.md, Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07. Thuật ngữ, ID, quy tắc và dữ liệu logic phải đối chiếu TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY trước khi thành artifact canonical.
Consequence if Wrong	Nếu chặn sai, hàng đạt chất lượng có thể bị giữ, gây chậm giao. Nếu không chặn, hàng chưa được đánh giá có thể được xuất, làm mất kiểm soát truy vết và tăng rủi ro vận hành. Nếu BA gọi đây là nghĩa vụ pháp lý khi chưa xác minh, artifact vượt thẩm quyền nguồn.

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

flowchart TB
    A[Luồng chuẩn: không có quyền bỏ qua kiểm soát] --> B[Kho tạo phiếu xuất mô phỏng]
    B --> C{Tồn kho đủ?}
    C -- Không --> D[Chặn xác nhận xuất: thiếu tồn kho]
    C -- Có --> E{QC Status = Released?}
    E -- Có --> F[Xác nhận phiếu xuất]
    E -- Blocked, Pending hoặc trống --> G[Chặn xác nhận xuất]
    G --> H[Quality Owner xác minh trạng thái lô]
    H --> I{QC Status = Released?}
    I -- Có --> F
    I -- Không --> J{Ngoại lệ đã được Business Owner và Quality Owner xác định trong artifact?}
    J -- Không --> K[Ngoại lệ chưa được xác định: giữ phiếu chưa xác nhận]
    J -- Có --> L[Ngoài phạm vi luồng hiện tại]

Sơ đồ là flowchart Mermaid, không phải BPMN. Điểm quyết định QC Status = Released xuất phát từ Facts và Current Behavior: hệ thống mô phỏng hiện cho xuất khi trạng thái trống; O2 thêm kiểm soát ngay trước xác nhận, nơi sai sót còn chặn được.

6. Output thu ???c

Core

Output là artifact được tạo mới hoặc cập nhật sau hoạt động phân tích yêu cầu. Artifact biến trao đổi thành bằng chứng có thể review: ai nêu nhu cầu, BA diễn giải gì, nguồn nào hỗ trợ, ai sở hữu quyết định, thay đổi nào đã xảy ra. 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.

Artifact tạo/cập nhật	Canonical ID hoặc định danh kiểm soát	Owner	Status	Nội dung tối thiểu	Nghĩa vụ lịch sử thay đổi
Bản ghi yêu cầu nền tảng	/02-handbook/06-requirements-foundations.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Phát biểu nhu cầu, phạm vi, nguồn, giả định, ràng buộc, tiêu chí review, liên kết rule và data	Ghi version, ngày 2026-08-07, người ghi nhận, nội dung thay đổi, lý do, artifact bị ảnh hưởng
Registry định danh truy vết	TRACEABILITY_ID_REGISTRY	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	ID canonical, loại đối tượng, quy tắc đặt ID, liên kết artifact	Không đổi ID im lặng; ghi ID cũ, ID mới nếu được thẩm quyền cho phép, lý do và ảnh hưởng traceability
Catalog quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Quy tắc, nguồn hoặc giả định, điều kiện áp dụng, owner xác minh, liên kết requirement	Ghi thay đổi câu chữ, điều kiện, nguồn, ngày và tác động tới requirement liên kết
Từ điển dữ liệu logic	CANONICAL_DATA_DICTIONARY	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Tên dữ liệu, định nghĩa, kiểu logic, giá trị hợp lệ, owner dữ liệu, liên kết rule	Ghi trường thêm, sửa, ngừng dùng; nêu lý do và artifact chịu tác động
Nguồn và ranh giới sử dụng	00_SOURCE_MAP	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	URL chính thức, issuer, version/status, ngày truy cập, safe use boundary	Ghi nguồn thêm hoặc thay; không đổi phân loại primary-source thành kết luận nghiệp vụ
Kiến trúc curriculum và manifest chapter	01_CURRICULUM_ARCHITECTURE, CHAPTER_MANIFEST	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Phạm vi chapter, dependency, filename, trạng thái và giới hạn thẩm quyền	Ghi thay đổi phạm vi, dependency hoặc filename; kiểm tra liên kết chapter bị ảnh hưởng

IN_REVIEW nghĩa là đang được xem xét có kiểm soát. Nó không nghĩa APPROVED, BASELINED, production-ready, compliant, hay được người dùng chấp thuận. Owner giữ cấu trúc, version và traceability; Owner không thay Business Owner, Quality Owner, Solution Architect, Legal/Compliance Owner, Accounting Owner hoặc QA xác nhận nội dung chuyên môn.

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

flowchart TB
    A["Hoạt động BA"] --> B["Tạo hoặc cập nhật artifact<br/>với nội dung tối thiểu"]
    B --> C["Gắn canonical ID<br/>để truy vết"]
    C --> D["Ghi nguồn<br/>issuer, version/status, ngày truy cập<br/>và safe use boundary"]
    D --> E["Ghi version và lịch sử thay đổi"]
    E --> F["Chuyển nội dung cần xác minh tới vai trò phù hợp:<br/>Business Owner, Quality Owner, Solution Architect,<br/>Legal/Compliance Owner, Accounting Owner hoặc QA"]
    F --> G{"Reviewer có đủ nội dung, nguồn,<br/>canonical ID, version, lịch sử thay đổi<br/>và owner phù hợp?"}
    G -->|Có| H["Downstream reviewer xác định được<br/>phiên bản và bằng chứng để review"]
    G -->|Thiếu thành phần| I["Downstream reviewer không xác định được<br/>phiên bản hoặc bằng chứng review"]

    B -. "Trạng thái artifact" .-> S["IN_REVIEW<br/>Đang được xem xét có kiểm soát<br/>Không chứng minh đầy đủ, phê duyệt hoặc baseline"]

    B -. "Trách nhiệm duy trì" .-> O["Principal IT Business Analyst /<br/>Technical Curriculum Author<br/>duy trì cấu trúc, version và traceability<br/>không xác nhận nội dung chuyên môn"]

Sơ đồ là flowchart Mermaid, không phải BPMN. Chuỗi này cần thiết vì downstream reviewer phải thấy cùng lúc nội dung, nguồn, định danh và thay đổi; thiếu một phần thì reviewer không biết đang review phiên bản nào hoặc dựa trên bằng chứng nào.

Applied

Thành phần	Nova Foods mô phỏng, dữ liệu tổng hợp
Facts	Kho mô phỏng có thể xác nhận phiếu xuất khi QC Status của lô trống. Bản ghi trước đã xác định rủi ro xuất lô chưa được đánh giá.
Current Behavior	Điểm xác nhận xuất chỉ kiểm tra tồn kho đủ; chưa kiểm tra QC Status = Released.
Underlying Need	Cần biểu diễn nhu cầu kiểm soát trước xác nhận xuất, không tự diễn giải thành nghĩa vụ pháp lý hay cấu hình ERP thực tế.
Options	O1: nhắc người dùng bằng hướng dẫn. O2: chặn xác nhận nếu QC Status khác Released.
Decision Criteria	Chặn sai sót trước khi xuất; giữ traceability lô; xác định rõ owner xác minh trạng thái; không vượt thẩm quyền BA.
Decision	Ghi O2 là phương án được phân tích cho review: chỉ cho xác nhận xuất khi QC Status = Released. Đây chưa là quyết định vận hành hay production.
Authority	Quality Owner xác minh nghĩa trạng thái chất lượng. Business Owner xác nhận tác động vận hành. Solution Architect xác nhận điểm kiểm tra ERP. BA giữ traceability.
Artifact	Cập nhật /02-handbook/06-requirements-foundations.md; liên kết CANONICAL_BUSINESS_RULES cho quy tắc sau khi được đăng ký canonical; liên kết CANONICAL_DATA_DICTIONARY cho QC Status; kiểm tra định danh qua TRACEABILITY_ID_REGISTRY. Tất cả Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Nếu không ghi owner và nguồn, BA có thể biến giả định thành quy tắc. Nếu không ghi lịch sử thay đổi, reviewer không biết kiểm tra theo phiên bản nào. Nếu dùng ID không canonical, liên kết requirement, rule và data có thể đứt.

Senior Lens

Không tạo artifact mới khi artifact canonical hiện có đủ chỗ ghi nhận. Ví dụ, không tạo “danh sách QC Status riêng” nếu CANONICAL_DATA_DICTIONARY đã là nguồn dữ liệu logic. Artifact trùng làm hai nguồn chân lý; mỗi nguồn có thể đổi khác nhau và tạo lỗi review.

Lịch sử thay đổi không phải nhật ký chung chung. Mỗi dòng phải trả lời: thay đổi cái gì, vì sao, do ai ghi nhận, lúc nào theo Asia/Ho_Chi_Minh, ảnh hưởng artifact nào. Không ghi “cập nhật nội dung” vì reviewer không thể đánh giá tác động.

Quick Reference

Quy tắc	Áp dụng
Giữ ID nguyên dạng	Dùng đúng TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, 00_SOURCE_MAP
Giữ source boundary	Nguồn pháp lý chỉ là bối cảnh cho đến khi Legal/Compliance Owner xác minh áp dụng
Giữ status đúng nghĩa	IN_REVIEW không tạo approval, baseline hay quyền production
Ghi thay đổi đầy đủ	Version, ngày, người ghi nhận, lý do, tác động
Sẵn sàng downstream review	Nội dung tối thiểu, owner, status, ID, nguồn và change history đều hiện diện

Core

Output requirement là gói bằng chứng để người đọc hiểu cùng một nhu cầu, không tự suy diễn. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu đều tổng hợp. Một gói đầy đủ phải nối được bảy phần: sự kiện nguồn, hành vi hiện tại, nhu cầu gốc, yêu cầu, quy tắc, dữ liệu, tiêu chí chấp nhận.

Phần anatomy	Nội dung phải điền	Ví dụ giá trị
Bối cảnh	Quy trình, điểm đau, phạm vi	Nhập kho nguyên liệu từ Purchase Order
Facts	Quan sát kiểm chứng được, không suy đoán	Nhân viên nhập số lô bằng tay từ phiếu giao hàng
Current Behavior	Hệ thống hoặc quy trình đang làm gì	ERP cho lưu Lot Number rỗng khi nhận hàng
Underlying Need	Kết quả nghiệp vụ cần đạt	Truy vết nguyên liệu theo lô khi kiểm tra chất lượng
Requirement	Hành vi hệ thống cần có	ERP phải bắt buộc Lot Number trước khi hoàn tất Goods Receipt
Business Rule	Điều kiện nghiệp vụ tách khỏi màn hình	Một dòng Goods Receipt chỉ hoàn tất khi có Lot Number không rỗng
Data	Tên dữ liệu, kiểu, nguồn, ràng buộc	Lot Number: chuỗi, nguồn phiếu giao hàng, bắt buộc
Acceptance Criteria	Điều kiện kiểm tra được	Thiếu Lot Number thì không thể hoàn tất chứng từ
Traceability	Liên kết nguồn, rule, data, test basis	CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY
Change record	Điều đổi, lý do, ngày, người ghi nhận	Tạo mới nội dung mô phỏng ngày 2026-08-07

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

flowchart TB
    A["Phiếu giao hàng nhà cung cấp"] --> B["Nhân viên nhập kho nhập Lot Number cho từng dòng Goods Receipt"]
    B --> C{"ERP: Mỗi dòng có Lot Number không rỗng?"}
    C -- Có --> D["ERP hoàn tất Goods Receipt"]
    C -- Không --> E["ERP báo lỗi và chặn hoàn tất"]
    E --> F["Nhân viên nhập kho sửa Lot Number của dòng thiếu"]
    F --> C

Applied

Facts: Trong case Nova Foods mô phỏng, kho nhận nguyên liệu RM-SUGAR-001. Phiếu giao hàng tổng hợp ghi lô SUP-260807-A. Nhân viên có thể lưu Goods Receipt mà không nhập lô.

Current Behavior: ERP mô phỏng nhận Goods Receipt có Lot Number rỗng. Vì dòng nhận hàng vẫn hoàn tất, dữ liệu tồn kho không nối chắc chắn với lô nhà cung cấp.

Underlying Need: Bộ phận Quality cần biết nguyên liệu nào thuộc lô nào. Suy luận: truy vết cần khóa nối giữa dòng nhận hàng và lô; Lot Number rỗng làm khóa nối không tồn tại.

Options:

Phương án	Cách làm	Hệ quả
A	Cho phép lô rỗng, bổ sung sau	Có nguy cơ tồn kho chưa truy vết được
B	Bắt buộc lô trước khi hoàn tất	Chặn dữ liệu thiếu tại điểm phát sinh
C	Tự sinh lô nội bộ khi lô nguồn rỗng	Có thêm quy tắc đối chiếu cần xác minh

Decision Criteria: Giữ được lô từ chứng từ nguồn; chặn dữ liệu thiếu; không tự tạo quy tắc truy vết mới chưa được xác minh.

Decision: Chọn B cho ví dụ học liệu. Lý do: lô phải tồn tại trước khi tạo quan hệ truy vết; phương án B kiểm soát ngay lúc Goods Receipt hoàn tất.

Authority: Đây là quyết định phân tích cho Nova Foods mô phỏng, chưa phải quyết định vận hành. Business Owner và Quality Owner phải xác nhận nhu cầu nghiệp vụ; Legal Owner phải xác minh nghĩa vụ pháp lý nếu áp dụng quy định an toàn thực phẩm.

Artifact: Gói nội dung đã điền đầy đủ:

Trường	Giá trị
Artifact tham chiếu quy tắc	CANONICAL_BUSINESS_RULES
Artifact tham chiếu dữ liệu	CANONICAL_DATA_DICTIONARY
Artifact tham chiếu ID	TRACEABILITY_ID_REGISTRY
Tệp nguồn quản trị	/01-curriculum/CANONICAL_BUSINESS_RULES.md
Tệp dữ liệu canonical	/01-curriculum/CANONICAL_DATA_DICTIONARY.md
Nhu cầu	Truy vết nguyên liệu theo lô tại bước Goods Receipt
Requirement	ERP phải yêu cầu Lot Number có giá trị trước khi hoàn tất Goods Receipt cho nguyên liệu có quản lý lô
Rule	Nếu mặt hàng được đánh dấu quản lý lô, Goods Receipt không hoàn tất khi Lot Number rỗng
Data field	Lot Number
Data type	Chuỗi ký tự
Source value	SUP-260807-A từ phiếu giao hàng tổng hợp
Example item	RM-SUGAR-001
Positive acceptance criterion	Với RM-SUGAR-001, nhập SUP-260807-A thì Goods Receipt đủ dữ liệu để hoàn tất
Negative acceptance criterion	Với RM-SUGAR-001, để trống Lot Number thì hệ thống hiển thị lỗi và không hoàn tất Goods Receipt
Assumption	RM-SUGAR-001 thuộc nhóm nguyên liệu quản lý lô trong case mô phỏng
Verification required	Cách định nghĩa hàng quản lý lô, quy tắc truy vết và nhu cầu pháp lý thực tế
Change history entry	2026-08-07, tạo ví dụ học liệu tổng hợp tại v0.9.0, trạng thái IN_REVIEW

Consequence if Wrong: Nếu ép nhập lô cho mặt hàng không quản lý lô, kho bị chặn sai. Nếu cho hoàn tất khi lô rỗng, dữ liệu truy vết có khoảng trống. Hai khả năng đều cần được phát hiện qua review nghiệp vụ và kiểm tra tiêu chí chấp nhận.

Senior Lens

Không viết “cần truy vết” rồi dừng. Câu đó là nhu cầu, chưa là requirement kiểm tra được. BA phải tách: đối tượng nào cần lô, tại thời điểm nào phải có lô, điều gì bị chặn, trường nào lưu giá trị, và kết quả nào chứng minh được. Liên kết đến CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY giữ rule và định nghĩa dữ liệu ở nguồn canonical, tránh chép nhiều bản rồi lệch nhau.

Quick Reference

Kiểm tra anatomy	Đạt khi
Facts khác Need	Facts mô tả bằng chứng; Need mô tả kết quả cần đạt
Requirement kiểm tra được	Có điều kiện, hành động hệ thống, kết quả
Rule tách UI	Rule không phụ thuộc tên nút hay vị trí màn hình
Data đủ dùng	Có field, kiểu, nguồn và ràng buộc
Ví dụ không suy diễn pháp lý	Mọi nghĩa vụ pháp lý ghi Verification required
Traceability rõ	Dùng đúng CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY

Core

Cổng chất lượng là tập điều kiện kiểm tra trước khi artifact được chuyển sang downstream review, tức xem xét bởi vai trò dùng artifact làm đầu vào tiếp theo. Cổng này kiểm tra khả năng review, không xác nhận nội dung đúng tuyệt đối, không tạo approval, baseline, compliance hay production readiness. Bằng chứng: mọi artifact nguồn trong corpus đang IN_REVIEW, v0.9.0, ngày 2026-08-07; các nguồn này nói rõ IN_REVIEW không đồng nghĩa APPROVED hay BASELINED.

Điều kiện cổng	Bằng chứng cần có	Kết quả đạt
Nhận dạng kiểm soát	Canonical Artifact ID, đường dẫn tệp, Status: IN_REVIEW, Version: v0.9.0	Reviewer biết đúng artifact cần xem
Phạm vi rõ	Nội dung thuộc phạm vi artifact; không biến giả định thành quy tắc vận hành	Reviewer không phải suy đoán ranh giới
Nguồn truy vết được	Liên kết tới source hoặc upstream artifact canonical; phân loại nguồn giữ nguyên	Reviewer kiểm tra được cơ sở lập luận
Nhãn xác minh đủ	Nội dung pháp lý, kế toán, thuế, bảo mật, an toàn thực phẩm chưa đối chiếu đầy đủ mang nhãn Verification required hoặc giả định dự án	Reviewer không hiểu nhầm thành nghĩa vụ đã xác nhận
Thay đổi truy được	Version, ngày 2026-08-07, lý do thay đổi và tác động được ghi trong change history	Reviewer biết nội dung nào đang được xem xét
Không vượt thẩm quyền	Không ghi approval, baseline, sign-off, quyết định ERP thực tế hoặc sẵn sàng production	Review không bị diễn giải thành quyết định có thẩm quyền

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

flowchart TB
    A[Artifact soạn hoặc cập nhật] --> B{Có Canonical Artifact ID, đường dẫn tệp,<br/>Status: IN_REVIEW, Version: v0.9.0?}
    B -- Không --> X[Bổ sung metadata] --> B
    B -- Có --> C{Nội dung thuộc phạm vi artifact<br/>và không biến giả định thành quy tắc vận hành?}
    C -- Không --> Y[Làm rõ phạm vi hoặc giả định] --> C
    C -- Có --> D{Có liên kết tới source hoặc upstream artifact canonical<br/>và giữ nguyên phân loại nguồn?}
    D -- Không --> Z[Làm rõ traceability hoặc phân loại nguồn] --> D
    D -- Có --> E{Nội dung chưa đối chiếu đủ về pháp lý, kế toán, thuế,<br/>bảo mật, an toàn thực phẩm có nhãn<br/>Verification required hoặc giả định dự án?}
    E -- Không --> G[Gắn nhãn xác minh] --> E
    E -- Có --> H{Change history có Version, ngày 2026-08-07,<br/>lý do thay đổi và tác động?}
    H -- Không --> I[Bổ sung change history] --> H
    H -- Có --> L{Không ghi approval, baseline, sign-off,<br/>quyết định ERP thực tế hoặc production readiness?}
    L -- Không --> M[Xóa hoặc sửa tuyên bố vượt thẩm quyền] --> L
    L -- Có --> J[Sẵn sàng cho downstream review;<br/>không phải approval hoặc baseline]
    J --> K[Giữ trạng thái IN_REVIEW]

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Artifact CANONICAL_BUSINESS_RULES có trạng thái IN_REVIEW, version v0.9.0; Owner là Principal IT Business Analyst / Technical Curriculum Author.

Current Behavior: Reviewer nhận catalog nhưng không biết một rule có dựa vào nguồn pháp lý đã xác minh hay chỉ là giả định học liệu. Hệ quả là reviewer có thể đọc nhầm nội dung mô phỏng thành yêu cầu ERP thật.

Underlying Need: Tạo điều kiện tối thiểu để reviewer kiểm tra đúng artifact, nguồn và giới hạn thẩm quyền trước khi đưa phản hồi.

Options:

Option	Cách làm	Rủi ro
A	Chuyển artifact ngay khi có nội dung	Không kiểm được nguồn, thay đổi, giới hạn
B	Chỉ chuyển khi đạt cổng chất lượng review	Tốn bước kiểm tra ngắn, giữ được traceability

Decision Criteria: Option phải giữ canonical ID, không tạo approval ngầm định, chỉ rõ nội dung cần xác minh, và cho phép reviewer truy đến artifact nguồn.

Decision: Chọn B. CANONICAL_BUSINESS_RULES chỉ sẵn sàng cho downstream review khi metadata IN_REVIEW/v0.9.0 còn nguyên, change history ghi nhận thay đổi, và mọi rule có nguồn hoặc nhãn giả định/Verification required.

Authority: Principal IT Business Analyst / Technical Curriculum Author kiểm tra tính đầy đủ quản trị. Business Owner, Legal Owner, Accounting Owner, Security, Architect và QA giữ thẩm quyền kết luận thuộc chuyên môn của họ.

Artifact: /01-curriculum/CANONICAL_BUSINESS_RULES.md, Artifact ID CANONICAL_BUSINESS_RULES, IN_REVIEW, v0.9.0, 2026-08-07, Asia/Ho_Chi_Minh.

Consequence if Wrong: Nếu gọi artifact là approved hoặc production-ready sau cổng này, người dùng sau có thể triển khai theo nội dung chưa được role có thẩm quyền xác nhận; traceability không sửa được sai lệch thẩm quyền đó.

Senior Lens

Cổng chất lượng không hỏi “reviewer có đồng ý không?”. Cổng hỏi “reviewer có đủ vật liệu để phản biện có căn cứ không?”. Hai việc khác nhau: đạt cổng chỉ mở quyền xem xét; approval phải có quyết định, người có thẩm quyền, thời điểm và tham chiếu approval được ghi rõ. Thiếu một trong các bằng chứng đó, trạng thái vẫn là IN_REVIEW.

Không dùng cổng chất lượng để che thiếu nguồn. Nếu artifact nêu yêu cầu liên quan Luật Bảo vệ dữ liệu cá nhân, Luật Kế toán, hóa đơn, an toàn thực phẩm hoặc bảo mật, nhưng chưa được owner chuyên môn xác minh, phải giữ Verification required. Lý do: nguồn seed chỉ cho phép dùng ranh giới an toàn; không cho phép suy diễn điều khoản hay nghĩa vụ vận hành.

Quick Reference

Câu hỏi trước khi chuyển review	Đạt khi
Đây có đúng artifact không?	Có canonical ID và đường dẫn kiểm soát
Đây là bản nào?	Có v0.9.0, IN_REVIEW, ngày 2026-08-07
Lập luận dựa vào đâu?	Có nguồn/upstream artifact và cầu nối lập luận
Điều gì chưa chắc?	Có nhãn giả định hoặc Verification required
Ai được kết luận?	Thẩm quyền reviewer và Owner không bị đánh tráo
Có được triển khai chưa?	Không; cổng chỉ cho downstream review

7. Who consumes those outputs?

Core

Đầu ra requirements không phải tài liệu để BA “bàn giao xong”. Mỗi đầu ra là vật liệu quyết định cho vai trò downstream. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi tên, dữ liệu và luồng dưới đây là dữ liệu tổng hợp.

Đầu ra requirements	Developer	QA	Architect	PM/Product Owner	Business Owner	Operations	Specialist owner
Problem statement, mục tiêu và phạm vi	Hiểu vấn đề cần giải bằng phần mềm; tránh build tính năng ngoài phạm vi	Xác định mục tiêu kiểm thử cấp hành trình	Kiểm tra phạm vi có kéo theo thay đổi nền tảng không	Sắp xếp ưu tiên delivery và phạm vi release	Đối chiếu mục tiêu với kết quả nghiệp vụ mong muốn	Chuẩn bị thay đổi quy trình, hướng dẫn và hỗ trợ	Nhận diện phần thuộc chuyên môn như kế toán, an toàn thực phẩm, bảo mật
Stakeholder needs, nhu cầu stakeholder	Chuyển nhu cầu thành hành vi hệ thống có thể xây	Chuyển nhu cầu thành test scenario	Xác định nhu cầu nào ảnh hưởng tích hợp, hiệu năng, bảo mật	So sánh nhu cầu để quản lý backlog	Kiểm tra nhu cầu phản ánh đúng giá trị kinh doanh	Xác định tác động đến người vận hành hằng ngày	Kiểm tra thuật ngữ và ràng buộc chuyên môn
Functional requirements, yêu cầu chức năng	Xây màn hình, xử lý, API và quy tắc ứng dụng	Thiết kế test case theo hành vi mong đợi	Đánh giá phân rã dịch vụ, tích hợp và giới hạn kỹ thuật	Theo dõi scope item trong backlog	Hiểu năng lực nghiệp vụ hệ thống sẽ hỗ trợ	Chuẩn bị quy trình làm việc khi chức năng được đưa vào dùng	Đối chiếu chức năng với chuyên môn phụ trách
Business rules, quy tắc nghiệp vụ	Mã hóa điều kiện, tính toán và chặn dữ liệu	Tạo test dương, âm và biên	Kiểm tra nơi thực thi rule: ứng dụng, API, DB hay hệ thống ngoài	Quản lý thay đổi rule theo ưu tiên	Xem rule có phản ánh chính sách nghiệp vụ mô phỏng không	Áp dụng rule trong hướng dẫn vận hành	Xác minh rule thuộc kế toán, pháp lý, chất lượng hoặc bảo mật
Data requirements và data dictionary	Tạo field, validation, mapping và lưu trữ	Chuẩn bị dữ liệu kiểm thử tổng hợp	Đánh giá ownership dữ liệu, tích hợp và phân loại dữ liệu	Quản lý phạm vi dữ liệu của release	Kiểm tra dữ liệu phục vụ báo cáo và quyết định	Chuẩn bị nhập liệu, sửa lỗi và tra cứu	Kiểm tra định nghĩa dữ liệu chuyên ngành
Process model, mô hình quy trình	Hiểu trình tự xử lý và điểm kích hoạt chức năng	Thiết kế test theo luồng đầu-cuối	Nhận diện điểm tích hợp, bất đồng bộ và dependency	Điều phối release theo thay đổi quy trình	So sánh quy trình mục tiêu với cách làm mong muốn	Dùng làm nền cho SOP, đào tạo và xử lý ngoại lệ	Kiểm tra bước thuộc kiểm soát chuyên môn
Non-functional requirements, yêu cầu phi chức năng	Thiết kế đáp ứng hiệu năng, bảo mật, khả dụng, accessibility	Thiết kế kiểm thử phi chức năng	Chọn kiến trúc đáp ứng ràng buộc	Cân bằng chi phí, rủi ro và giá trị release	Hiểu mức dịch vụ ảnh hưởng vận hành	Chuẩn bị giám sát, hỗ trợ và xử lý sự cố	Xác minh ràng buộc bảo mật, pháp lý hoặc chất lượng
Acceptance criteria, tiêu chí chấp nhận	Biết điều kiện hoàn thành từng hạng mục	Dùng làm test basis, cơ sở thiết kế và đánh giá kiểm thử	Kiểm tra tiêu chí không trái kiến trúc	Theo dõi completion và scope	Đọc được kết quả nghiệp vụ cần quan sát	Xác định điều kiện vận hành sẵn sàng	Kiểm tra tiêu chí chuyên môn cần xác nhận
Traceability, liên kết truy vết	Tìm nguồn của code change	Liên kết test với requirement và rule	Theo dõi tác động xuyên thành phần	Theo dõi coverage scope	Truy về mục tiêu và nhu cầu ban đầu	Tìm tác động đến quy trình vận hành	Truy về nguồn chuyên môn và điểm cần xác minh

Cầu nối lập luận: requirement nêu “hệ thống phải làm gì”; consumer dùng nó để tạo một loại công việc khác. Developer tạo giải pháp kỹ thuật, QA tạo bằng chứng kiểm thử, Operations tạo năng lực vận hành. Nếu không chỉ rõ consumer và cách dùng, cùng một requirement có thể bị đọc như mô tả màn hình bởi Developer nhưng bị đọc như quy trình nghiệp vụ bởi Operations.

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

flowchart TB
    R[Requirements outputs<br/>goals and scope<br/>stakeholder needs<br/>functional requirements and rules<br/>data and process models<br/>non-functional requirements<br/>acceptance criteria and traceability]

    R --> D[Developer<br/>build screens, processing, APIs<br/>and application rules]
    R --> Q[QA<br/>create test scenarios, cases<br/>and test evidence]
    R --> A[Architect<br/>decide service decomposition, integrations,<br/>data ownership, execution location and constraints]
    R --> P[PM/Product Owner<br/>manage backlog scope, priority<br/>and release trade-offs]
    R --> B[Business Owner<br/>validate goals, expected value, policy,<br/>reporting and observable outcomes]
    R --> O[Operations<br/>prepare SOP, training, monitoring,<br/>support, exceptions and operational readiness]
    R --> S[Specialist owner<br/>validate accounting, legal, food-safety,<br/>quality, security and domain constraints]

Applied

Facts: Nova Foods mô phỏng có requirement cho luồng nhận hàng nguyên liệu, gồm process model, data requirements, business rules và acceptance criteria. Dữ liệu lô hàng, nhà cung cấp và số lượng đều là tổng hợp.

Current Behavior: Developer đọc data requirements để tạo trường nhập; QA đọc acceptance criteria để lập kiểm thử; Operations đọc process model để biết thời điểm ghi nhận nhận hàng.

Underlying Need: Cùng một đầu ra phải đến đúng consumer vì mỗi vai trò biến nó thành deliverable khác nhau, không phải bản sao tài liệu.

Options: Gửi một tài liệu requirements chung cho mọi vai trò; hoặc duy trì một nguồn requirements có liên kết rõ từng output với consumer sử dụng.

Decision Criteria: Phương án phù hợp phải giữ một nguồn sự thật, cho phép mỗi role tìm đúng phần cần dùng, và không biến BA thành người diễn giải thay chuyên môn kỹ thuật hay chuyên ngành.

Decision: Dùng nguồn requirements chung, kèm bảng consumer-to-output trong handoff. Không tạo bản rule riêng cho Developer, QA và Operations vì nhiều bản sao làm tăng nguy cơ lệch nội dung.

Authority: BA duy trì liên kết và ngôn ngữ requirement. Developer, QA, Architect, PM/Product Owner, Business Owner, Operations và specialist owner dùng output trong phạm vi vai trò của mình. Nội dung thuộc pháp lý, kế toán, an toàn thực phẩm, bảo mật cần Verification required từ owner chuyên môn phù hợp.

Artifact: Tham chiếu canonical giữ nguyên: CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md; CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md; TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Các artifact đều IN_REVIEW, v0.9.0, ngày 2026-08-07; không phải baseline hoặc approval.

Consequence if Wrong: Nếu QA chỉ nhận user story mà không nhận business rule và acceptance criteria, test có thể pass theo màn hình nhưng sai điều kiện nghiệp vụ. Nếu Operations chỉ nhận màn hình thay vì process model, vận hành có thể làm đúng thao tác nhưng sai thời điểm hoặc sai người chịu trách nhiệm.

Senior Lens

Không đo chất lượng handoff bằng số file đã gửi. Đo bằng khả năng consumer tạo được deliverable downstream mà không tự bịa ý nghĩa. Developer cần tính khả thi để build; QA cần hành vi quan sát được để test; Architect cần boundary để thiết kế; Operations cần bước vận hành để chạy. Một requirement tốt nhưng không được đóng gói theo cách consumer dùng vẫn gây rework.

Không gọi IN_REVIEW là “đã sẵn sàng triển khai”. Trạng thái chỉ cho biết artifact đang được xem xét có kiểm soát. Nova Foods là mô phỏng; không suy diễn requirement thành cấu hình ERP thật, nghĩa vụ pháp lý hay quyết định vận hành thật.

Quick Reference

Consumer	Đầu ra dùng trực tiếp	Deliverable downstream
Developer	Functional requirements, rules, data, acceptance criteria	Code, API, validation
QA	Requirements, rules, process, acceptance criteria	Test scenario, test case, test evidence
Architect	NFR, data, process, integration needs	Architecture decision, integration design
PM/Product Owner	Mục tiêu, scope, needs, acceptance criteria	Backlog, release scope
Business Owner	Mục tiêu, needs, rules, process	Đánh giá business fit
Operations	Process, data, exception flow	SOP, training, support readiness
Specialist owner	Rules, data, NFR chuyên ngành	Xác minh chuyên môn

Core

Mỗi output yêu cầu chỉ có giá trị khi người nhận dùng nó để quyết định trong đúng phạm vi thẩm quyền. Bằng chứng là IN_REVIEW tại v0.9.0 chưa phải baseline hay approval; vì vậy người nhận được kiểm tra, làm rõ, phản biện và đề xuất thay đổi, không tự chuyển nội dung thành quyết định vận hành Nova Foods. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp.

Consumer	Có thể quyết định	Bằng chứng cần đọc	Phải escalation khi
Developer	Cách hiện thực, kiểm tra kỹ thuật, lỗi xử lý được	Requirement, acceptance criteria, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY	Rule mơ hồ; dữ liệu thiếu; yêu cầu làm đổi phạm vi; cách hiện thực làm yếu bảo mật
QA	Test basis, test condition, mức bao phủ, lỗi cần báo	Requirement, acceptance criteria, luồng nghiệp vụ, dữ liệu mẫu tổng hợp	Không có tiêu chí kiểm thử được; expected result mâu thuẫn rule; defect chạm quyết định nghiệp vụ
Architect	Ràng buộc tích hợp, dữ liệu, bảo mật, hiệu năng, kiến trúc	Interface boundary, data classification, volume assumption, risk	Thay đổi ảnh hưởng hệ thống khác, quyền truy cập, API, dữ liệu cá nhân, chi phí hay vận hành
PM/Product Owner	Ưu tiên, phạm vi release, trade-off thời gian-chi phí-giá trị	Mục tiêu, dependency, rủi ro, effort estimate, acceptance criteria	Trade-off làm đổi business outcome, cam kết bên ngoài, ngân sách hoặc deadline đã quản trị
Business Owner	Ý nghĩa nghiệp vụ, rule, ngoại lệ nghiệp vụ, mức chấp nhận kết quả	Facts, policy nguồn, quy trình hiện hành, tác động KPI	Nội dung là pháp lý, thuế, kế toán, an toàn thực phẩm hoặc vượt quyền business
Operations	Tính chạy được hằng ngày, quyền thao tác, xử lý sự cố, báo cáo	As-is/to-be flow, exception, workload, training impact	Thay đổi làm gián đoạn vận hành, cần quy trình khẩn cấp, thay đổi phân quyền hoặc dữ liệu lịch sử
Specialist owner	Kết luận chuyên môn trong miền phụ trách: Legal, Accounting, Security, Food Safety	Nguồn chính thức, phân loại dữ liệu, hồ sơ nghiệp vụ, giả định dự án	Nguồn chưa xác minh; diễn giải luật; xung đột giữa chuyên môn và requirement

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

flowchart TB
    R[Output yêu cầu<br/>IN_REVIEW v0.9.0] --> C[Consumer kiểm tra bằng chứng phù hợp]
    C --> D{Đủ thẩm quyền<br/>và không có điều kiện escalation?}
    D -->|Có| P[Consumer quyết định trong phạm vi thẩm quyền<br/>có truy vết]
    D -->|Không: rule mơ hồ, dữ liệu thiếu,<br/>nguồn chưa xác minh, rủi ro hoặc tác động vượt phạm vi| E[Escalation đúng owner]
    E --> F{Cần làm rõ requirement<br/>hay quyết định thuộc thẩm quyền khác?}
    F -->|Làm rõ requirement| G[Nội dung requirement được làm rõ hoặc sửa đổi]
    G --> R
    F -->|Quyết định chuyên môn hoặc cấp có thẩm quyền| H[Owner có thẩm quyền ra quyết định<br/>có truy vết]

Applied

Facts: Requirement mô phỏng nêu ERP Nova Foods phải giữ lịch sử thay đổi đơn giá mua.
Current Behavior: Chưa có bằng chứng về nguồn giá, thời điểm hiệu lực, quyền sửa hay thời hạn lưu.
Underlying Need: Developer cần model dữ liệu; QA cần expected result; Operations cần biết ai sửa giá.
Options: Ghi đè giá hiện hành; lưu phiên bản giá theo thời điểm hiệu lực.
Decision Criteria: Khả năng truy vết, tác động báo cáo, quyền truy cập, khối lượng dữ liệu, quy tắc kế toán.
Decision: Không chọn option trong handbook. Evidence chưa đủ để chọn.
Authority: Business Owner xác nhận ý nghĩa nghiệp vụ; Accounting Owner xác nhận tác động hạch toán; Architect xác nhận model và tích hợp.
Artifact: Liên kết rule với CANONICAL_BUSINESS_RULES, trường dữ liệu với CANONICAL_DATA_DICTIONARY, ID với TRACEABILITY_ID_REGISTRY.
Consequence if Wrong: Developer có thể mất lịch sử; QA kiểm thử sai expected result; Operations không truy được người đổi giá; báo cáo có thể sai. Đây là project assumption, Verification required.

Senior Lens

Escalation không phải đẩy việc đi. Escalation là đóng gói điểm không thể tự quyết: câu hỏi, artifact nguồn, dữ kiện, các phương án, tác động từng phương án, owner cần quyết định, hạn quyết định. Nếu yêu cầu chạm dữ liệu cá nhân, tham chiếu Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP chỉ là nguồn cần Legal Owner xác minh; không diễn giải thành nghĩa vụ Nova Foods. Nếu chạm kế toán hoặc hóa đơn, Accounting Owner và Legal Owner phải xác minh theo nguồn chính thức.

Quick Reference

Tín hiệu	Hành động
Consumer chọn cách làm trong rule đã rõ	Ghi quyết định và traceability
Hai artifact canonical mâu thuẫn	Dừng suy diễn, escalation
Acceptance criteria không cho QA xác định pass/fail	Trả về làm rõ requirement
Rule cần diễn giải luật, thuế, kế toán, bảo mật	Escalation specialist owner
IN_REVIEW bị gọi là approved hoặc baselined	Sửa trạng thái, giữ nguyên IN_REVIEW

Core

Bàn giao lỗi khi người nhận suy luận phần chưa viết. Requirement, rule, acceptance criteria và data dictionary là bằng chứng; trao đổi miệng không thay thế artifact. Nova Foods Trading & Manufacturing là case mô phỏng, chỉ dùng dữ liệu tổng hợp. IN_REVIEW, v0.9.0, ngày 2026-08-07 nghĩa là nội dung còn xem xét, không phải baseline hay phê duyệt.

Hiểu nhầm bàn giao	Rủi ro	Câu hỏi làm rõ chính xác
Developer đọc “chặn đơn vượt hạn mức” thành chặn lúc nhập đơn.	Có thể phải chặn ở lúc duyệt, xuất kho hoặc lập hóa đơn; đặt sai điểm kiểm soát làm sai luồng.	“Hệ thống kiểm tra hạn mức tại thời điểm nào: tạo đơn, gửi duyệt, duyệt đơn, xuất kho hay lập hóa đơn?”
QA xem ví dụ dữ liệu là toàn bộ tập kiểm thử.	Thiếu biên dưới, biên trên, dữ liệu rỗng, quyền truy cập và trạng thái lỗi.	“Ví dụ này minh họa rule hay là acceptance criteria đầy đủ? Những giá trị biên và trạng thái không hợp lệ nào phải kiểm thử?”
Architect hiểu tên trường nghiệp vụ là cấu trúc DB.	Logical data dictionary mô tả nghĩa dữ liệu, chưa quyết định bảng, khóa, API hay lưu trữ.	“Tên trường này là khái niệm logic hay đã có quyết định physical schema? Artifact nào ghi quyết định kiến trúc?”
PM/Product Owner hiểu “cần nhanh” là cam kết thời gian phản hồi.	Team tự đặt KPI, không có tải dự kiến hay cách đo.	“'Nhanh' đo bằng chỉ số nào, tại màn hình hoặc API nào, với số người dùng đồng thời và dữ liệu tổng hợp nào?”
Business Owner coi workflow minh họa là chính sách vận hành.	Mô hình học liệu bị dùng làm rule thật.	“Đây là project assumption hay quy tắc đã được Business Owner có thẩm quyền xác nhận trong artifact kiểm soát?”
Operations hiểu tích hợp được mô tả là lịch chạy thật.	Sai lịch đồng bộ, thiếu xử lý lỗi và đối soát.	“Tích hợp này dùng sự kiện, API hay batch? Khi đích không nhận được dữ liệu, ai đối soát và nguồn nào là canonical?”
Specialist owner coi nhãn pháp lý là kết luận tuân thủ.	Sai thẩm quyền về kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc hóa đơn.	“Yêu cầu này là project assumption hay đã được Legal Owner, Accounting Owner hoặc domain owner xác minh theo nguồn chính thức hiện hành?”

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

flowchart TB
    A[Artifact IN_REVIEW] --> B[Người nhận đọc artifact]
    B --> C{Thiếu điểm kiểm soát, dữ liệu hoặc thẩm quyền?}
    C -- Không --> D[Tiếp tục đánh giá trong phạm vi artifact]
    D --> E[Kết thúc vòng làm rõ; artifact vẫn IN_REVIEW, chưa là baseline hay phê duyệt]
    C -- Có --> F[Đặt câu hỏi làm rõ bằng văn bản]
    F --> G{Cần owner có thẩm quyền hoặc chuyên môn xác nhận?}
    G -- Không --> H[BA ghi bằng chứng, quyết định làm rõ và tác động traceability]
    G -- Có --> I[Yêu cầu Business Owner, Legal Owner, Accounting Owner hoặc domain owner xác nhận]
    I --> J{Kết quả xác nhận}
    J -- Xác nhận --> K[BA cập nhật bằng chứng xác nhận, quyết định làm rõ và tác động traceability]
    J -- Bác bỏ --> L[BA sửa hoặc loại bỏ nội dung bị bác bỏ, ghi bằng chứng quyết định và tác động traceability]
    J -- Yêu cầu bổ sung --> F
    H --> M[Artifact IN_REVIEW được cập nhật]
    K --> M
    L --> M
    M --> N{Còn điểm chưa rõ?}
    N -- Có --> F
    N -- Không --> D

Applied

Facts: Nova Foods mô phỏng có câu “đơn bán vượt hạn mức tín dụng cần được chặn”. Không có thời điểm kiểm tra, công thức hạn mức, ngoại lệ, vai trò duyệt hay nguồn dữ liệu dư nợ.

Current Behavior: Developer có thể chặn nút lưu đơn; QA có thể kiểm thử đúng một đơn vượt hạn mức; Operations có thể chờ batch cập nhật dư nợ. Ba cách hiểu khác nhau vì câu requirement chưa chứa điều kiện kiểm tra.

Underlying Need: Cần biến câu ngắn thành quyết định kiểm chứng được: sự kiện kích hoạt, dữ liệu đầu vào, kết quả chặn, ngoại lệ và owner quyết định. Bằng chứng là các thành phần này quyết định màn hình, API, test case và vận hành đối soát khác nhau.

Options: (1) Chặn khi tạo đơn. (2) Cho tạo đơn, chặn khi gửi duyệt. (3) Cho tạo đơn và duyệt, chặn khi xuất kho.

Decision Criteria: Chọn theo điểm nghiệp vụ cần ngăn cam kết bán hàng, độ mới dữ liệu dư nợ, quyền override và tác động đơn đang xử lý. Không suy ra từ ví dụ đơn lẻ.

Decision: Chưa quyết định. Artifact hiện IN_REVIEW không đủ bằng chứng để chọn một option.

Authority: Business Owner quyết định điểm kiểm soát nghiệp vụ; Accounting Owner xác minh cách tính dư nợ nếu có tác động kế toán; Architect xác nhận khả năng lấy dữ liệu; Operations xác nhận xử lý lỗi đồng bộ.

Artifact: Ghi câu hỏi và phản hồi vào artifact kiểm soát liên quan, giữ liên kết CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY; không tự tạo ID.

Consequence if Wrong: Chặn quá sớm làm mất đơn hợp lệ; chặn quá muộn tạo cam kết không thể thực hiện; QA kiểm sai test basis; Operations thiếu cách xử lý đơn kẹt.

Senior Lens

Escalate khi câu trả lời làm đổi rule, owner, dữ liệu canonical, quyền override, điểm tích hợp, nghĩa vụ pháp lý hoặc xử lý tiền hàng. BA không chọn thay owner. BA ghi: câu hỏi, artifact nguồn, phần chưa có bằng chứng, các option, tác động từng option và vai trò cần quyết định. Không ghi “đã phê duyệt” nếu artifact không có approval reference.

Quick Reference

Khi nghe câu này	Không được suy luận	Hỏi ngay
“Dùng số dư mới nhất”	“Mới nhất” là thời gian thực	“Nguồn số dư nào là canonical, độ trễ chấp nhận được bao nhiêu, và khi nguồn lỗi thì xử lý thế nào?”
“Manager có thể override”	Mọi manager đều có quyền	“Vai trò nào được override, giới hạn nào áp dụng, lý do có bắt buộc, và audit trail cần giữ gì?”
“Không lộ dữ liệu khách hàng”	Cách che dữ liệu cụ thể	“Loại dữ liệu nào cần hạn chế, ai được xem, kênh nào bị ảnh hưởng, và Legal Owner xác minh yêu cầu nào?”

8. Detailed Worked Example

Core

Ví dụ làm việc chi tiết biến thông tin rời rạc thành hiểu biết có thể kiểm tra. 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, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Artifact corpus hiện IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không có baseline hay approval reference.

Applied

Bối cảnh nhất quán: Nhân viên Sales nhập đơn bán chịu cho khách hàng tại màn hình ERP. Sales nói đơn bị giữ không nhất quán khi khách đã thanh toán gần đây. Đây là quan sát đầu vào, chưa phải yêu cầu hay quy tắc đã được ủy quyền.

Thành phần	Sự kiện tổng hợp hiện có	Phân loại nguồn
Khách hàng	CUS-NF-000184, tên hiển thị Công ty TNHH Thực phẩm An Phát	Dữ liệu mô phỏng trong case
Đơn bán	SO-NF-20260807-0142, tạo 2026-08-07 09:12:00	Dữ liệu mô phỏng trong case
Giá trị đơn	128.500.000 VND	Dữ liệu mô phỏng trong case
Hạn mức tín dụng hiển thị	300.000.000 VND	Dữ liệu mô phỏng trong case
Dư nợ hiển thị cho Sales	245.000.000 VND	Dữ liệu mô phỏng trong case
Thanh toán gần nhất	80.000.000 VND, ghi nhận tại hệ thống thu tiền lúc 2026-08-07 08:55:00	Dữ liệu mô phỏng trong case
Dư nợ tại thời điểm ghi nhận thanh toán	165.000.000 VND nếu giảm đủ 80.000.000 VND từ số dư 245.000.000 VND	Suy luận số học: 245.000.000 - 80.000.000
Trạng thái đơn hiện thấy	ON_HOLD_CREDIT	Dữ liệu mô phỏng trong case
Kho dữ liệu Sales đang dùng	Bản sao dữ liệu dư nợ, thời điểm đồng bộ cuối 2026-08-07 08:30:00	Dữ liệu mô phỏng trong case
Nguồn số dư canonical	Chưa được xác định trong artifact cung cấp	Khoảng trống cần truy vết, không được tự chọn

Facts: Sales nhập SO-NF-20260807-0142 lúc 09:12:00. Màn hình dùng dư nợ 245.000.000 VND, đồng bộ cuối lúc 08:30:00. Giao dịch thu tiền 80.000.000 VND có thời điểm 08:55:00, muộn hơn lần đồng bộ 25 phút. Bằng chứng thời gian cho thấy màn hình chưa chắc đã chứa giao dịch thu tiền; điều này chưa chứng minh lỗi tích hợp hoặc lỗi nghiệp vụ.

Current Behavior: Hệ thống lấy dư nợ hiển thị 245.000.000 VND, cộng giá trị đơn 128.500.000 VND, ra tổng tiếp xúc tín dụng 373.500.000 VND. Tổng này cao hơn hạn mức hiển thị 300.000.000 VND là 73.500.000 VND, nên đơn có trạng thái ON_HOLD_CREDIT.

Phép tính hành vi hiện tại	Giá trị
Dư nợ màn hình	245.000.000 VND
Giá trị đơn SO-NF-20260807-0142	128.500.000 VND
Tổng tiếp xúc tín dụng hiện dùng	373.500.000 VND
Hạn mức hiển thị	300.000.000 VND
Phần vượt hạn mức	73.500.000 VND
Kết quả hiện tại	ON_HOLD_CREDIT

Nếu thanh toán 80.000.000 VND đã hợp lệ để giảm dư nợ trước khi kiểm tra đơn, phép tính giả định sẽ là 165.000.000 + 128.500.000 = 293.500.000 VND. Kết quả giả định thấp hơn hạn mức 6.500.000 VND. Đây là đối chiếu dữ liệu để phát hiện chênh lệch; không phải kết luận rằng đơn phải được nhả giữ.

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

flowchart TB
    A["Sales tạo SO-NF-20260807-0142<br/>09:12"] --> B["ERP Sales đọc dư nợ đồng bộ<br/>245.000.000 VND"]
    B --> C["Cộng giá trị đơn<br/>128.500.000 VND"]
    C --> D{"Tổng tiếp xúc tín dụng 373.500.000 VND<br/>> hạn mức hiển thị 300.000.000 VND?"}
    D -->|Có| E["Đặt ON_HOLD_CREDIT"]

    N["Đồng bộ cuối 08:30<br/>Thu tiền 80.000.000 VND lúc 08:55<br/>Chênh lệch 25 phút<br/>Chưa có bằng chứng bản sao Sales chứa giao dịch"] -.ghi chú rủi ro dữ liệu cũ.-> B

Senior Lens

Không gọi thanh toán là “đã hợp lệ” chỉ vì có bản ghi mô phỏng. Cần biết trạng thái thu tiền, nguồn dư nợ canonical, độ trễ đồng bộ được chấp nhận và thời điểm kiểm tra hạn mức. Các nội dung đó thuộc CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY; artifact cung cấp không cho phép tự tạo hoặc gán ID mới.

Quick Reference

Ranh giới	Kết luận được phép
Có bằng chứng	Dữ liệu Sales lúc 09:12:00 có thể cũ hơn giao dịch thu tiền lúc 08:55:00.
Chưa có bằng chứng	Thanh toán đã hoàn tất, đủ điều kiện giảm dư nợ, hoặc ERP phải nhả giữ đơn.
Không được suy luận	Nguồn canonical, quy tắc hạn mức, quyền override, quyết định nghiệp vụ.

Applied

Bối cảnh: 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, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Tình huống: chặn xuất kho nguyên liệu khi lô đã hết hạn dùng.

Bước phân tích	Nội dung đã làm rõ	Bằng chứng hoặc cầu nối suy luận
Facts	Nguyên liệu RM-MILK-001 có lô LOT-MILK-260701-A, ngày hết hạn 2026-08-05. Phiếu xuất kho GI-20260807-014 lập lúc 2026-08-07 09:15:00. Số lượng yêu cầu: 120 kg. Kho WH-HCM-RM còn 450 kg của lô này.	Ngày lập phiếu sau ngày hết hạn 2 ngày. Tồn kho dương không chứng minh lô còn được phép dùng.
Current Behavior	ERP mô phỏng kiểm tra available_quantity >= requested_quantity. Hệ thống không kiểm tra expiry_date khi người dùng xác nhận xuất kho. Phiếu được tạo trạng thái POSTED.	Điều kiện tồn kho đạt: 450 >= 120. Không có điều kiện hạn dùng nên giao dịch vẫn qua.
Underlying Need	Cần ngăn giao dịch xuất kho dùng lô hết hạn trước khi ghi nhận giảm tồn. Nhu cầu cốt lõi không phải “thêm cảnh báo”, mà là bảo vệ trạng thái tồn kho và truy xuất lô khỏi dữ liệu sai.	Cảnh báo vẫn cho phép bỏ qua. Nếu đã POSTED, số dư lô và lịch sử tiêu thụ đã thay đổi.
Options	O1: hiện cảnh báo, vẫn cho xác nhận. O2: chặn toàn bộ phiếu nếu có bất kỳ dòng hết hạn. O3: chặn riêng dòng hết hạn; cho phép các dòng hợp lệ tiếp tục.	O1 không đáp ứng nhu cầu ngăn giao dịch. O2 an toàn hơn nhưng có thể chặn nguyên liệu hợp lệ trên cùng phiếu. O3 kiểm soát đúng đơn vị rủi ro là từng dòng lô.
Decision Criteria	C1 ngăn ghi nhận dữ liệu sai; C2 giữ truy xuất theo lô; C3 giảm gián đoạn xuất kho hợp lệ; C4 có thông báo để người dùng sửa; C5 kiểm thử được bằng dữ liệu đầu vào xác định.	Tiêu chí xuất phát từ hậu quả của việc ghi nhận POSTED sai, không phải từ sở thích giao diện.
Decision	Khuyến nghị BA: chọn O3. Khi transaction_date > expiry_date, hệ thống từ chối dòng xuất kho của lô đó, giữ nguyên tồn kho, trả lỗi có mã. Các dòng khác chỉ được xử lý nếu luồng nghiệp vụ hỗ trợ tách dòng; giả định này cần Architect và Business Owner xác minh.	O3 đạt C1, C2, C4, C5; chỉ đạt C3 khi hệ thống hỗ trợ xử lý theo dòng.
Authority	Business Owner quyết định có cho tách dòng hay chặn cả phiếu. Food Safety/Quality Owner xác nhận cách diễn giải ngày hết hạn cho vận hành. Architect xác nhận điểm kiểm tra và tính nhất quán giao dịch. QA xác nhận test basis. Principal IT Business Analyst / Technical Curriculum Author chỉ ghi nhận khuyến nghị và truy vết.	IN_REVIEW và v0.9.0 không tạo phê duyệt, baseline, thẩm quyền vận hành hay xác nhận tuân thủ.
Artifact	Requirement, business rule, payload lỗi, sơ đồ xử lý và test scenario bên dưới. Các artifact này là bản nháp học liệu trong /02-handbook/06-requirements-foundations.md.	Artifact biến suy luận thành đối tượng có thể review, test và truy vết.
Consequence if Wrong	Nếu chỉ cảnh báo hoặc kiểm tra sau khi POSTED, 120 kg có thể bị ghi nhận là đã dùng dù lô hết hạn. Tồn kho, truy xuất lô, báo cáo tiêu thụ và quyết định chất lượng sau đó có thể sai.	Sai ở điểm kiểm soát tạo dữ liệu sai lan sang các bước phụ thuộc.

Quy tắc đề xuất để review, chưa phải quyết định được ủy quyền:

Rule ID	Quy tắc
BR-INV-EXP-001	Hệ thống phải từ chối dòng xuất kho khi transaction_date > expiry_date của lô được chọn.
BR-INV-EXP-002	Khi từ chối theo BR-INV-EXP-001, hệ thống không được giảm available_quantity, không được tạo bút toán tồn kho, không được đặt dòng thành POSTED.
BR-INV-EXP-003	Hệ thống phải trả mã lỗi INV_LOT_EXPIRED cùng lot_id, expiry_date và transaction_date.

Payload lỗi đề xuất:

{
  "error_code": "INV_LOT_EXPIRED",
  "message": "Lô không thể xuất kho vì đã hết hạn dùng.",
  "lot_id": "LOT-MILK-260701-A",
  "item_id": "RM-MILK-001",
  "expiry_date": "2026-08-05",
  "transaction_date": "2026-08-07",
  "requested_quantity": 120,
  "uom": "kg"
}

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

flowchart TB
    A[Người dùng gửi dòng xuất kho] --> B{available_quantity >= requested_quantity?}

    B -- Không --> C[Dừng dòng<br/>Hành vi/mã lỗi cần xác minh]

    B -- Có --> D{transaction_date > expiry_date?}

    D -- Có --> E[Từ chối dòng xuất kho<br/>Trả INV_LOT_EXPIRED]
    E --> F[Payload gồm:<br/>lot_id<br/>expiry_date<br/>transaction_date]
    F --> G[available_quantity không đổi<br/>Không tạo bút toán tồn kho<br/>Dòng không POSTED]

    D -- Không --> H[Tiếp tục xử lý theo các quy tắc nghiệp vụ khác<br/>Chưa mặc định POSTED]

    I[Điểm điều phối chung:<br/>Architect xác minh thứ tự kiểm tra<br/>và ưu tiên lỗi khi vừa thiếu tồn vừa hết hạn]
    I -. xác minh .-> B
    I -. xác minh .-> D

    J[Boundary O3 theo từng dòng:<br/>Architect xác minh hỗ trợ tách dòng;<br/>Business Owner quyết định tách dòng hoặc chặn cả phiếu]
    J -. áp dụng cho .-> A

    K[Quality Owner xác minh<br/>diễn giải ngày hết hạn]
    K -. liên quan điều kiện .-> D

Scenario ID	Dữ liệu vào	Kết quả mong đợi
SC-INV-EXP-001	transaction_date=2026-08-07; expiry_date=2026-08-05; available_quantity=450; requested_quantity=120	Trả INV_LOT_EXPIRED; tồn kho vẫn 450 kg; dòng không là POSTED.
SC-INV-EXP-002	transaction_date=2026-08-05; expiry_date=2026-08-05; available_quantity=450; requested_quantity=120	Không kích hoạt BR-INV-EXP-001; xử lý tiếp theo quy tắc tồn kho và thẩm quyền Quality Owner cần xác minh.

Applied

Kịch bản SCN-NF-REQ-001: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp. Kho thành phẩm Bình Dương cần chặn xuất lô sữa hạt khi ngày hết hạn quá gần ngày giao dự kiến.

Thành phần	Giá trị đầy đủ
Scenario ID	SCN-NF-REQ-001
Requirement ID	REQ-NF-INV-001
Rule ID	BR-NF-INV-001
Decision ID	DEC-NF-INV-001
Artifact ID	ART-NF-INV-001
Hệ thống phạm vi	Nova Foods ERP mô phỏng
Đơn vị kho	WH-BD-01 — Kho thành phẩm Bình Dương
Sản phẩm	FG-NF-ALM-180 — Sữa hạt hạnh nhân 180 ml
Lô hàng	LOT-ALM-260801-A
Ngày sản xuất	2026-08-01
Ngày hết hạn	2026-08-15
Đơn bán hàng	SO-NF-260807-0142
Ngày giao dự kiến	2026-08-12
Số lượng yêu cầu	480 chai
Đơn vị tiền tệ	VND
Phân loại nguồn	Project assumption; không phải quy định pháp lý, kế toán hay quyết định vận hành thực tế

Quy tắc BR-NF-INV-001: ERP chỉ được phân bổ lô cho đơn bán khi expiryDate >= plannedDeliveryDate + minimumRemainingShelfLifeDays. Giá trị giả định cho minimumRemainingShelfLifeDays là 5 ngày. Quy tắc bảo vệ khả năng sử dụng của hàng sau giao; bằng chứng là đơn SO-NF-260807-0142 giao ngày 2026-08-12, nên lô hợp lệ phải hết hạn từ 2026-08-17 trở đi. Lô LOT-ALM-260801-A hết hạn 2026-08-15, không đạt điều kiện.

Dữ liệu đầu vào	Giá trị	Kết quả tính
plannedDeliveryDate	2026-08-12	Ngày giao
minimumRemainingShelfLifeDays	5	Ngày tối thiểu còn lại
Ngày hết hạn tối thiểu	2026-08-17	2026-08-12 + 5 ngày
expiryDate của lô	2026-08-15	Sớm hơn 2 ngày
Kết quả rule	REJECTED	Không được phân bổ

Payload kiểm tra phân bổ của REQ-NF-INV-001:

{
  "requestId": "REQ-NF-INV-001",
  "salesOrderId": "SO-NF-260807-0142",
  "warehouseId": "WH-BD-01",
  "productId": "FG-NF-ALM-180",
  "lotId": "LOT-ALM-260801-A",
  "quantity": 480,
  "uom": "BOTTLE",
  "plannedDeliveryDate": "2026-08-12",
  "expiryDate": "2026-08-15",
  "minimumRemainingShelfLifeDays": 5,
  "currency": "VND",
  "sourceClassification": "PROJECT_ASSUMPTION"
}

Payload phản hồi mong đợi:

{
  "requestId": "REQ-NF-INV-001",
  "allocationStatus": "REJECTED",
  "ruleId": "BR-NF-INV-001",
  "requiredExpiryDate": "2026-08-17",
  "actualExpiryDate": "2026-08-15",
  "reasonCode": "INSUFFICIENT_REMAINING_SHELF_LIFE",
  "message": "Lô LOT-ALM-260801-A không đủ 5 ngày hạn dùng còn lại sau ngày giao dự kiến.",
  "manualOverrideAllowed": false
}

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

flowchart TB
    A[Đơn SO-NF-260807-0142<br/>cần 480 chai] --> B[ERP nhận lô ứng viên<br/>LOT-ALM-260801-A]
    B --> C[ERP tính requiredExpiryDate<br/>2026-08-12 + 5 ngày = 2026-08-17]
    C --> D{expiryDate 2026-08-15<br/>>= requiredExpiryDate 2026-08-17?}
    D -->|Có / Đạt ngưỡng| E[ERP cho phép phân bổ kho]
    D -->|Không| F[ERP chặn phân bổ]
    F --> G[REJECTED:<br/>INSUFFICIENT_REMAINING_SHELF_LIFE]
    G --> H[manualOverrideAllowed: false]
    H --> I[Không tạo phân bổ kho]

Phương án	Mô tả	Đánh giá theo BR-NF-INV-001
OPT-NF-INV-001	ERP chỉ cảnh báo, người dùng vẫn phân bổ lô	Không khuyến nghị. Cảnh báo không ngăn giao lô không đạt ngưỡng giả định.
OPT-NF-INV-002	ERP chặn phân bổ và không cho ghi đè thủ công	Khuyến nghị BA. Kiểm soát nhất quán, có bằng chứng rule rõ.
OPT-NF-INV-003	ERP chặn phân bổ nhưng cho Quản lý kho ghi đè	Không khuyến nghị tại v0.9.0. Cần policy, audit trail và thẩm quyền vận hành chưa có.

Tiêu chí quyết định	OPT-NF-INV-001	OPT-NF-INV-002	OPT-NF-INV-003
Ngăn lô không đạt ngưỡng	Không	Có	Có
Có ngoại lệ thủ công	Có, không kiểm soát	Không	Có
Cần policy ngoại lệ bổ sung	Không	Không	Có
Phù hợp phạm vi học liệu hiện tại	Không	Có	Không

Loại ghi nhận	Nội dung	Trạng thái
Khuyến nghị BA	Chọn OPT-NF-INV-002: chặn phân bổ khi không đạt BR-NF-INV-001.	RECOMMENDED
Quyết định có thẩm quyền	Chưa có. DEC-NF-INV-001 không được ghi là approved, baselined hoặc authorized.	IN_REVIEW
Authority cần quyết định	Business Owner xác nhận ngưỡng nghiệp vụ; Warehouse Operations Owner xác nhận tác động vận hành; Food Safety/Legal Owner xác minh yêu cầu pháp lý hoặc an toàn thực phẩm nếu áp dụng.	PENDING_AUTHORITY
Artifact đầu ra	/02-handbook/06-requirements-foundations.md, ART-NF-INV-001; liên kết REQ-NF-INV-001, BR-NF-INV-001, DEC-NF-INV-001.	IN_REVIEW

Nếu ghi sai rule thành cảnh báo thay vì chặn, ERP có thể phân bổ lô hết hạn trước ngưỡng giao hàng giả định. Hậu quả là kho xử lý đơn dựa trên dữ liệu không đạt tiêu chí đã nêu, còn QA không có test basis rõ để kiểm tra kết quả REJECTED.

9. Related Concepts & Dependencies

Core

Dependency là quan hệ phụ thuộc: artifact này cần thông tin ổn định từ artifact khác để giữ cùng nghĩa. Traceability là khả năng lần ngược từ một nội dung về nguồn quản trị của nó. Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; vì vậy liên kết không biến kế hoạch học liệu thành cấu hình ERP, quyết định nghiệp vụ hay xác nhận tuân thủ.

Nguồn chân lý canonical là tệp được chỉ định duy nhất để sở hữu một loại nội dung. Chương handbook chỉ giải thích và tham chiếu, không chép lại catalog rule, data dictionary hoặc registry ID. Lý do: nếu một rule xuất hiện ở hai nơi rồi chỉ sửa một nơi, learner và QA sẽ đọc hai nghĩa khác nhau.

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

flowchart TB
    H["/02-handbook/06-requirements-foundations.md<br/>Chỉ giải thích và tham chiếu<br/>Không sao chép nội dung canonical"]

    CM["/01-curriculum/CHAPTER_MANIFEST.md<br/>Tên chapter, section, filename"]
    TM["/01-curriculum/TEMPLATE_MANIFEST.md<br/>Template và phạm vi"]
    BR["/01-curriculum/CANONICAL_BUSINESS_RULES.md<br/>Quy tắc nghiệp vụ"]
    DD["/01-curriculum/CANONICAL_DATA_DICTIONARY.md<br/>Thuật ngữ và dữ liệu"]
    IR["/01-curriculum/TRACEABILITY_ID_REGISTRY.md<br/>ID persistent"]
    SM["/00-research/00_SOURCE_MAP.md<br/>Nguồn chuẩn, pháp lý, good practice"]

    H -->|"lần ngược tên chapter, section, filename"| CM
    H -->|"lần ngược template và phạm vi"| TM
    H -->|"lần ngược quy tắc nghiệp vụ"| BR
    H -->|"lần ngược thuật ngữ và dữ liệu"| DD
    H -->|"lần ngược ID persistent"| IR
    H -->|"lần ngược nguồn chuẩn"| SM

    C["Sao chép nội dung canonical"]
    R["Rủi ro: bản sao lệch phiên bản<br/>Learner và QA đọc khác nghĩa"]

    C -->|"gây"| R

Nội dung cần dùng	Nguồn canonical	Phân loại nguồn	Cách chương này dùng
Tên chapter, vị trí section, filename	/01-curriculum/CHAPTER_MANIFEST.md	Controlled planning artifact	Giữ đúng /02-handbook/06-requirements-foundations.md; không tự đổi tên hoặc số section
Template dự kiến và phạm vi template	/01-curriculum/TEMPLATE_MANIFEST.md	Controlled planning artifact	Tham chiếu template đã đăng ký; không tạo template thay thế
Quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Canonical rule catalog plan	Nêu ID rule và diễn giải học liệu; không tạo bản sao rule canonical
Thuật ngữ, trường dữ liệu, ý nghĩa dữ liệu	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Canonical logical data dictionary plan	Dùng tên dữ liệu đã kiểm soát; không tự định nghĩa kiểu dữ liệu hoặc mã trường
ID persistent	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Canonical identifier registry plan	Giữ nguyên chuỗi ID; không tái sử dụng hoặc đổi tiền tố
Nguồn chuẩn, pháp lý, good practice	/00-research/00_SOURCE_MAP.md	Verified primary-source map	Giữ phân loại nguồn và giới hạn dùng; không suy diễn điều khoản chưa xác minh

Applied

Facts: Case mô phỏng Nova Foods có BR-NF-INV-001, REQ-NF-INV-001, DEC-NF-INV-001 và ART-NF-INV-001. BR-NF-INV-001 nêu điều kiện lô hàng phải đạt ngưỡng hạn dùng giả định trước khi phân bổ. Evidence: các ID này đã xuất hiện trong artifact học liệu trước đó và phải giữ nguyên để liên kết không đứt.

Current Behavior: Người soạn có thể chép nguyên nội dung BR-NF-INV-001 vào nhiều chapter, template và test note. Khi ngưỡng thay đổi, một bản sao có thể được sửa nhưng bản khác không sửa. Kết quả: cùng ID nhưng hai mô tả khác nhau.

Underlying Need: Cần một nơi sở hữu mỗi loại sự thật: registry sở hữu ID, rule catalog sở hữu rule, data dictionary sở hữu nghĩa dữ liệu, manifest sở hữu filename và cấu trúc. Handbook sở hữu phần giải thích cách BA dùng các nguồn đó.

Options: (1) Chép toàn bộ nội dung canonical vào chapter; (2) chỉ ghi ID, đường dẫn canonical và phần diễn giải cần cho bài học; (3) tạo ID mới trong chapter cho cùng khái niệm.

Decision Criteria: Phương án phải giữ một nguồn cập nhật, cho phép reviewer tìm nguồn gốc, không làm mất ID persistent, không vượt thẩm quyền Owner, và không ngầm tạo approval hay baseline.

Decision: Chọn phương án (2). Trong chapter, viết BR-NF-INV-001 kèm đường dẫn artifact canonical khi cần. Chỉ trích phần tối thiểu để giải thích; không sửa nghĩa rule trong bản trích.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết và metadata. Business Owner, Warehouse Operations Owner, Food Safety/Legal Owner, Architect hoặc QA Owner giữ thẩm quyền xác minh nội dung thuộc chuyên môn của họ. Tại IN_REVIEW, chưa có baseline hay approval.

Artifact: /02-handbook/06-requirements-foundations.md tham chiếu /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md và /01-curriculum/TRACEABILITY_ID_REGISTRY.md. ART-NF-INV-001 giữ liên kết tới BR-NF-INV-001, REQ-NF-INV-001, DEC-NF-INV-001.

Consequence if Wrong: Nếu chapter tự đổi BR-NF-INV-001 thành rule cảnh báo thay vì chặn, learner có thể hiểu sai hành vi mong muốn. Nếu registry bị bỏ qua và ID mới được tạo, reviewer không chứng minh được hai mô tả có phải cùng một đối tượng hay không.

Senior Lens

Quy tắc kiểm tra nhanh: một câu trả lời câu hỏi “giá trị chính xác hiện hành là gì?” chỉ được lấy từ một artifact canonical. Chapter được phép giải thích “vì sao dùng giá trị đó”, nhưng không được trở thành nơi quyết định lại giá trị.

ID persistent phải bất biến theo vòng đời đối tượng. Sửa câu chữ, thêm evidence hoặc đổi trạng thái không được tự đổi BR-NF-INV-001 thành ID khác. Chỉ registry quyết định cấp, thay thế hoặc ngừng dùng ID. Lý do: ID là khóa liên kết giữa requirement, rule, dữ liệu, API, kiểm thử và quyết định, không phải nhãn trang trí.

Dependency ngược cũng cần được nhìn thấy. /02-handbook/06-requirements-foundations.md phụ thuộc manifest để giữ đúng vị trí và filename; template, artifact thực hành và chapter sau có thể phụ thuộc giải thích trong chapter này. Thay đổi canonical phải đánh giá nơi tiêu thụ trước khi công bố thay đổi, dù artifact vẫn ở IN_REVIEW.

Quick Reference

Quy tắc	Thực hiện
Một loại sự thật, một chủ sở hữu	Rule ở CANONICAL_BUSINESS_RULES; dữ liệu ở CANONICAL_DATA_DICTIONARY; ID ở TRACEABILITY_ID_REGISTRY
Giữ ID nguyên dạng	Dùng BR-NF-INV-001, không dịch, không rút gọn, không tự cấp biến thể
Giữ filename canonical	Dùng đúng đường dẫn đã đăng ký trong manifest
Phân biệt tham chiếu và sao chép	Tham chiếu ID, đường dẫn, phiên bản; chỉ trích tối thiểu để giải thích
Giữ source boundary	Nguồn pháp lý, chuẩn và good practice chỉ dùng theo /00-research/00_SOURCE_MAP.md
Không suy diễn trạng thái	IN_REVIEW không phải APPROVED, BASELINED hoặc production-ready

Core

Traceability (truy vết) là liên kết có kiểm soát từ nhu cầu đến bằng chứng kiểm thử. Mỗi liên kết dùng ID canonical trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md; bảng này chỉ ghi quan hệ, không tạo lại nội dung nguồn. Nova Foods Trading & Manufacturing là case mô phỏng, dữ liệu tổng hợp, IN_REVIEW, v0.9.0, ngày 2026-08-07.

Loại ID	Vai trò	Nguồn canonical	Liên kết tối thiểu
NEED	Vấn đề hoặc kết quả nghiệp vụ cần đạt	Backlog/need register được đăng ký	NEED liên kết ít nhất một REQ
REQ	Requirement: yêu cầu hệ thống hoặc nghiệp vụ có thể kiểm tra	Requirement artifact được đăng ký	REQ liên kết NEED, BR nếu có, và AC
BR	Business Rule: quy tắc nghiệp vụ quyết định hành vi	/01-curriculum/CANONICAL_BUSINESS_RULES.md	BR liên kết các REQ áp dụng
AC	Acceptance Criteria: điều kiện chấp nhận	Requirement artifact chứa REQ	AC liên kết một REQ, rồi đến TC
DATA	Thuật ngữ, thực thể, trường hoặc ràng buộc dữ liệu	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	DATA liên kết REQ, BR, API khi dùng
API	Hợp đồng giao tiếp hệ thống	API specification được đăng ký	API liên kết REQ, DATA, TC
TC	Test Case: ca kiểm thử tạo bằng chứng	Test artifact được đăng ký	TC liên kết ít nhất một AC

Applied

Facts: Nova Foods mô phỏng cần chặn tạo phiếu xuất kho khi số lượng yêu cầu lớn hơn tồn khả dụng của lô hàng. Current Behavior: người dùng có thể nhập số lượng xuất; hành vi chặn chưa được xác định trong corpus. Underlying Need: tránh ghi nhận xuất kho vượt lượng có thể dùng theo dữ liệu tồn kho mô phỏng.

Chuỗi truy vết	ID và quan hệ	Bằng chứng liên kết	Ranh giới nguồn
Nhu cầu	NEED-NF-INV-001	Cần ngăn xuất vượt tồn khả dụng	Need register canonical
Yêu cầu	REQ-NF-INV-001 thỏa NEED-NF-INV-001	Hệ thống phải từ chối xác nhận xuất khi requestedQty > availableQty	Requirement artifact canonical
Quy tắc	BR-NF-INV-001 áp dụng cho REQ-NF-INV-001	Chỉ số lượng tồn khả dụng được phép xuất	CANONICAL_BUSINESS_RULES; nội dung chi tiết không sao chép tại đây
Điều kiện chấp nhận	AC-NF-INV-001 kiểm tra REQ-NF-INV-001	Với requestedQty=120 và availableQty=100, hệ thống không xác nhận xuất và hiển thị lỗi nghiệp vụ	Requirement artifact canonical
Dữ liệu	DATA-NF-INV-001 hỗ trợ BR-NF-INV-001	requestedQty, availableQty, lotId, đơn vị tính	CANONICAL_DATA_DICTIONARY; kiểu dữ liệu chưa được suy diễn
API	API-NF-INV-001 thực hiện REQ-NF-INV-001 khi có tích hợp	Endpoint xuất kho phải trả kết quả từ chối cho dữ liệu vượt tồn	Chỉ áp dụng nếu API được đăng ký
Kiểm thử	TC-NF-INV-001 chứng minh AC-NF-INV-001	Input tổng hợp: lô LOT-SIM-001, yêu cầu 120, khả dụng 100; kỳ vọng: không tạo giao dịch xuất	Test artifact canonical

Options: liên kết TC trực tiếp với REQ, hoặc liên kết TC với AC và giữ AC liên kết REQ. Decision Criteria: kiểm thử phải chứng minh tiêu chí quan sát được; thay đổi câu chữ REQ không được làm mất kỳ vọng kiểm thử; một REQ có thể có nhiều AC. Decision: TC phải liên kết trực tiếp với AC; AC liên kết với REQ. Lý do: AC chuyển yêu cầu thành điều kiện kiểm chứng được, nên tạo cầu nối rõ giữa phân tích và QA.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì ID và liên kết. Business Owner xác nhận nhu cầu; QA Owner xác nhận mức đủ của TC; Architect xác nhận API; Data Owner xác nhận DATA; các vai trò này chưa ghi nhận approval tại v0.9.0. Artifact: ID, trạng thái và quan hệ kiểm soát tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md; quy tắc tại /01-curriculum/CANONICAL_BUSINESS_RULES.md; dữ liệu tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Consequence if Wrong: nếu TC-NF-INV-001 chỉ nối REQ nhưng không nối AC, QA có thể kiểm tra một hành vi khác với điều kiện chấp nhận; hệ thống có thể qua test nhưng vẫn cho xuất vượt tồn.

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

flowchart TB
    subgraph Q["Quyết định liên kết kiểm thử"]
        O1["Phương án 1<br/>TC liên kết AC; AC liên kết REQ"]
        O2["Phương án 2<br/>TC liên kết trực tiếp REQ; không liên kết AC"]
        C["Tiêu chí<br/>kiểm tra điều kiện quan sát được<br/>giữ kỳ vọng khi câu chữ REQ thay đổi<br/>một REQ có thể có nhiều AC"]
        DEC{"Chọn phương án"}
        SEL["Chọn phương án 1"]
        REJ["Loại phương án 2"]
        RISK["Rủi ro<br/>QA kiểm tra khác điều kiện chấp nhận<br/>hệ thống có thể qua test nhưng vẫn xuất vượt tồn"]

        O1 --> DEC
        O2 --> DEC
        C --> DEC
        DEC -->|chọn| SEL
        DEC -->|loại| REJ
        REJ --> RISK
    end

    subgraph M["Chuỗi truy vết được chọn"]
        N["NEED-NF-INV-001<br/>ngăn xuất vượt tồn khả dụng"]
        R["REQ-NF-INV-001<br/>từ chối xác nhận xuất khi<br/>requestedQty > availableQty"]
        A["AC-NF-INV-001<br/>120 > 100<br/>không xác nhận xuất<br/>hiển thị lỗi nghiệp vụ"]
        T["TC-NF-INV-001<br/>LOT-SIM-001; yêu cầu 120; khả dụng 100<br/>kỳ vọng: không tạo giao dịch xuất"]
        B["BR-NF-INV-001"]
        D["DATA-NF-INV-001<br/>requestedQty, availableQty, lotId, đơn vị tính"]
        P["API-NF-INV-001<br/>chỉ áp dụng nếu API được đăng ký"]

        N -->|được thỏa bởi| R
        R -->|được kiểm tra bởi| A
        A -->|được chứng minh bởi| T
        B -->|áp dụng cho| R
        D -->|hỗ trợ| B
        P -.->|thực hiện khi API được đăng ký| R
    end

    SEL -.->|áp dụng| A
    SEL -.->|TC liên kết trực tiếp AC| T

    subgraph SRC["Ranh giới nguồn canonical"]
        REG["TRACEABILITY_ID_REGISTRY.md<br/>ID, trạng thái và quan hệ"]
        RULES["CANONICAL_BUSINESS_RULES.md<br/>nội dung chi tiết BR<br/>không sao chép tại đây"]
        DICT["CANONICAL_DATA_DICTIONARY.md<br/>nội dung chi tiết DATA<br/>không suy diễn kiểu dữ liệu"]
    end

    REG -.-> N
    REG -.-> R
    REG -.-> A
    REG -.-> T
    REG -.-> B
    REG -.-> D
    REG -.-> P
    RULES -.-> B
    DICT -.-> D

    subgraph OWN["Trách nhiệm và trạng thái approval"]
        BA["Principal IT Business Analyst /<br/>Technical Curriculum Author"]
        BO["Business Owner"]
        QA["QA Owner"]
        AR["Architect"]
        DO["Data Owner"]
        V["v0.9.0<br/>chưa ghi nhận approval"]

        BA -->|duy trì ID và liên kết| REG
        BO -->|xác nhận nhu cầu| N
        QA -->|xác nhận mức đủ của TC| T
        AR -->|xác nhận API| P
        DO -->|xác nhận DATA| D

        BO -.->|chưa ghi nhận approval| V
        QA -.->|chưa ghi nhận approval| V
        AR -.->|chưa ghi nhận approval| V
        DO -.->|chưa ghi nhận approval| V
    end

Senior Lens

Không suy ra liên kết chỉ vì hai artifact cùng nói về “xuất kho”. Liên kết hợp lệ cần bằng chứng: cùng ID, tham chiếu ID trong artifact nguồn, hoặc quyết định liên kết được ghi nhận bởi owner đúng thẩm quyền. Ví dụ, DATA-NF-INV-001 chỉ được nối API-NF-INV-001 khi hợp đồng API thực sự truyền hoặc trả các trường đã đăng ký; tên trường gần giống không đủ bằng chứng.

Một BR có thể phục vụ nhiều REQ, nhưng không nhân bản câu quy tắc vào từng yêu cầu. Nhân bản tạo nhiều nguồn chân lý: khi BR đổi, các bản sao có thể lệch nhau. Requirement chỉ ghi Applies: BR-NF-INV-001; người đọc mở catalog canonical để xem nội dung rule hiện hành và trạng thái xác minh.

API là liên kết có điều kiện. Nếu chưa có tích hợp được đăng ký, ghi Không áp dụng trong phạm vi hiện tại, không tạo endpoint giả để hoàn chỉnh bảng. Đây là suy luận từ phạm vi: traceability chứng minh thứ đang tồn tại trong phạm vi, không lấp khoảng trống bằng thiết kế chưa được quyết định.

Quick Reference

Kiểm tra	Đạt khi	Lỗi cần chặn
Bao phủ nhu cầu	Mỗi NEED có ít nhất một REQ hoặc lý do loại trừ được ghi nhận	Nhu cầu không biến thành yêu cầu
Bao phủ kiểm thử	Mỗi AC có ít nhất một TC trước khi nói có bằng chứng test	REQ có test nhưng AC không có test
Quy tắc dùng lại	REQ tham chiếu BR canonical, không chép lại rule	Hai phiên bản cùng một rule
Dữ liệu nhất quán	Mỗi trường nghiệp vụ tham chiếu DATA canonical	Tên trường khác nhau cho cùng khái niệm
API đúng phạm vi	API chỉ xuất hiện khi có contract được đăng ký	Endpoint, payload hoặc mã lỗi tự bịa
Trạng thái quản trị	Mọi liên kết giữ IN_REVIEW, v0.9.0, 2026-08-07	Diễn giải liên kết là baseline hoặc approval

Core

Thay đổi lan truyền khi artifact nguồn đổi ý nghĩa, cấu trúc, ID, trạng thái hoặc ràng buộc; artifact phụ thuộc phải được đánh giá lại trước khi dùng tiếp. IN_REVIEW tại v0.9.0, ngày 2026-08-07, không phải baseline hay phê duyệt. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Thay đổi im lặng là sửa artifact nguồn nhưng không ghi lịch sử, không thông báo consumer, không kiểm tra liên kết. Lỗi nguy hiểm không nằm ở câu chữ mới; lỗi nằm ở consumer vẫn vận hành theo câu chữ, ID hoặc cấu trúc cũ. Ví dụ, đổi định nghĩa trường dữ liệu trong CANONICAL_DATA_DICTIONARY nhưng không đánh giá đặc tả API, requirement, acceptance criterion hay test case có thể làm cùng một tên trường mang hai nghĩa khác nhau.

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

flowchart TB
    A["Nguồn canonical đổi<br/>CANONICAL_BUSINESS_RULES<br/>CANONICAL_DATA_DICTIONARY<br/>TRACEABILITY_ID_REGISTRY"] --> B["Ghi thay đổi<br/>version, lịch sử, lý do"]
    B --> C["Phân tích tác động"]
    C --> N["Thông báo consumer bị ảnh hưởng"]
    N --> D["Artifact phụ thuộc<br/>handbook, template, requirement,<br/>acceptance criterion, mapping dữ liệu,<br/>API, test"]
    D --> G{"Cần cập nhật<br/>liên kết hoặc artifact?"}
    G -->|Có| U["Cập nhật liên kết hoặc artifact<br/>kèm bằng chứng"]
    G -->|Không| K["Giữ nguyên<br/>kèm bằng chứng"]
    U --> R["Owner hoặc vai trò có thẩm quyền review"]
    K --> R
    R --> Q{"Review chấp nhận?"}
    Q -->|Không| X["Yêu cầu sửa"]
    X --> C
    Q -->|Có| Y["Cho phép dùng tiếp<br/>sau đánh giá và review"]

Dependency đổi im lặng	Artifact phụ thuộc có thể hỏng	Hậu quả kiểm soát
ID trong TRACEABILITY_ID_REGISTRY bị đổi	Liên kết traceability, báo cáo coverage	Liên kết cũ không tìm được nguồn; báo cáo thiếu hoặc gán sai đối tượng
Quy tắc trong CANONICAL_BUSINESS_RULES bị đổi	Requirement, acceptance criterion, test basis	Build và test kiểm tra hai quy tắc khác nhau
Thuộc tính trong CANONICAL_DATA_DICTIONARY bị đổi	Mapping dữ liệu, API contract, dữ liệu test	Sai kiểu dữ liệu, sai nghĩa, mất dữ liệu hoặc tích hợp lỗi
Filename hoặc phân loại nguồn bị đổi	Tham chiếu handbook, template, review evidence	Reader dùng bản sao không kiểm soát hoặc nguồn sai thẩm quyền
Trạng thái IN_REVIEW bị diễn đạt thành approved	Quyết định triển khai, sign-off, đào tạo	Tạo ảo giác thẩm quyền; vượt ranh giới Owner

Applied

Facts: /01-curriculum/CANONICAL_DATA_DICTIONARY.md đổi định nghĩa logic của một trường dùng trong ví dụ Nova Foods. 06-requirements-foundations.md và artifact API/test có thể tham chiếu trường đó. Bằng chứng là các artifact cùng thuộc corpus và data dictionary là nguồn canonical cho nghĩa dữ liệu, không phải handbook.

Current Behavior: Người soạn handbook sao chép định nghĩa cũ vào ví dụ. Nhóm API dùng bản sao này làm mapping. Nhóm test tạo dữ liệu theo mapping đó. Không có ghi nhận thay đổi hoặc phân tích tác động.

Underlying Need: Giữ một nghĩa dữ liệu duy nhất, nhưng không chép lại nguồn canonical vào mọi artifact. Mỗi artifact chỉ giữ liên kết, phiên bản đã kiểm tra và tác động cục bộ.

Options: (1) Sửa im lặng mọi bản sao; (2) Giữ bản sao cũ; (3) Ghi thay đổi tại nguồn canonical, tìm consumer, đánh giá từng liên kết và cập nhật có kiểm soát.

Decision Criteria: Bảo toàn ID; truy được lý do thay đổi; phân biệt thay đổi nội dung với thay đổi trình bày; không suy diễn approval; có owner đúng thẩm quyền cho quyết định nghiệp vụ, kỹ thuật hoặc kiểm thử.

Decision: Chọn phương án 3. CANONICAL_DATA_DICTIONARY giữ nghĩa dữ liệu. Handbook chỉ giải thích cách phát hiện tác động và dẫn chiếu artifact nguồn. Không tạo lại định nghĩa canonical trong handbook.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì metadata, liên kết và gói tác động. Business Owner, Architect, QA, Legal Owner, Accounting Owner hoặc Security xác nhận phần thuộc thẩm quyền họ. Không vai trò nào được suy ra approval từ trạng thái IN_REVIEW.

Artifact: Ghi thay đổi trong artifact nguồn, cập nhật liên kết bị ảnh hưởng, lưu kết quả đánh giá trong lịch sử kiểm soát liên quan. Giữ nguyên CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY, status IN_REVIEW, version v0.9.0, locale vi-VN, timezone Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND.

Consequence if Wrong: API có thể gửi trường đúng tên nhưng sai nghĩa; test vẫn pass theo dữ liệu cũ; báo cáo traceability vẫn hiện liên kết nhưng liên kết không còn chứng minh đúng nội dung. Đây là lỗi traceability giả: có đường dẫn, nhưng mất tính đúng đắn.

Senior Lens

Không phải mọi thay đổi đều cần sửa mọi consumer. Tách ba mức: thay đổi trình bày không đổi nghĩa; thay đổi kỹ thuật có thể đổi consumer kỹ thuật; thay đổi nghĩa nghiệp vụ phải đánh giá mọi consumer diễn giải nghĩa đó. Cầu nối suy luận: consumer chỉ bị ảnh hưởng khi nó dùng phần đã đổi, nên phạm vi tác động phải dựa trên liên kết thực, không dựa trên phỏng đoán.

Dừng dùng artifact phụ thuộc khi không xác định được nguồn canonical, ID không còn hợp lệ, hoặc thay đổi có thể chạm pháp lý, kế toán, bảo mật, an toàn thực phẩm hay vận hành thực. Với nội dung pháp lý Việt Nam, phải ghi Verification required và chuyển đúng owner; handbook giáo dục không thay kết luận pháp lý hay production authority.

Quick Reference

Quy tắc	Thao tác
Một nguồn chân lý	Sửa tại artifact canonical, không sửa bản sao để thay nguồn
Không đổi im lặng	Ghi version, lịch sử, lý do, phạm vi tác động
Không tin liên kết mù	Kiểm tra ID, nghĩa nội dung, consumer và trạng thái
Không suy ra approval	IN_REVIEW vẫn là đang xem xét
Không tự quyết vượt thẩm quyền	Escalation khi tác động chạm Business, Architect, QA, Legal, Accounting hoặc Security

10. Common Mistakes & Anti-patterns

Core

Anti-pattern là cách làm lặp lại nhưng tạo requirement yếu, khó kiểm thử hoặc sai nguồn. Dấu hiệu phải quan sát được trong artifact, không dựa vào cảm giác người viết.

Sai lầm	Red flag quan sát được	Nguyên nhân gốc	Hành động sửa
Ghi giải pháp thay vì nhu cầu	“Hệ thống phải có nút Export Excel” nhưng không nêu ai dùng, quyết định gì	Nhầm yêu cầu nghiệp vụ với thiết kế giao diện	Viết lại nhu cầu, người dùng, quyết định và kết quả; để cách làm cho Architect hoặc UX đánh giá
Dùng từ không đo được	“Nhanh”, “dễ dùng”, “đầy đủ”, “tự động”	Không xác định tiêu chí kiểm tra	Thay bằng điều kiện, dữ liệu vào, kết quả mong đợi, thời điểm và ngoại lệ
Gộp nhiều ý trong một requirement	Một dòng chứa tạo đơn, duyệt tín dụng, xuất kho và gửi email	Muốn ghi nhanh theo lời kể quy trình	Tách từng hành vi có thể kiểm thử; giữ liên kết cùng quy trình
Bỏ ngoại lệ	Chỉ mô tả luồng đơn hàng thành công	Phỏng vấn chỉ hỏi “thường làm thế nào”	Hỏi điều gì xảy ra khi dữ liệu thiếu, quyền không đủ, tồn kho không đủ hoặc tích hợp lỗi
Sao chép lời họp thành requirement	Requirement chứa “chị Lan nói cần làm ngay”	Không phân biệt bằng chứng với quyết định	Lưu lời họp làm nguồn tham khảo; chỉ ghi requirement sau khi xác định nhu cầu và owner có thẩm quyền
Sửa bản sao thay vì nguồn canonical	Cùng một quy tắc khác nhau trong nhiều tệp	Không xác định nguồn chân lý	Tra cứu CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY; sửa tại artifact canonical theo kiểm soát thay đổi
Đánh đồng IN_REVIEW với đã chấp thuận	Tài liệu ghi “đã thống nhất” nhưng metadata là IN_REVIEW	Nhầm trạng thái soạn thảo với approval	Giữ đúng trạng thái IN_REVIEW; không suy ra baseline hay approval

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

flowchart TB
    A[Requirement có red flag] --> B{Loại red flag?}

    B -->|Giải pháp thay nhu cầu| C[Viết nhu cầu, người dùng, quyết định, kết quả]
    C --> D[Architect hoặc UX đánh giá cách làm]

    B -->|Từ không đo được| E[Thay bằng điều kiện, dữ liệu vào, kết quả, thời điểm, ngoại lệ]

    B -->|Gộp nhiều hành vi| F[Tách từng hành vi có thể kiểm thử]
    F --> G[Giữ liên kết cùng quy trình]

    B -->|Bỏ ngoại lệ| H[Bổ sung dữ liệu thiếu, quyền không đủ, tồn kho không đủ, tích hợp lỗi]

    B -->|Sao chép lời họp| I[Lưu lời họp làm nguồn tham khảo]
    I --> J[Xác định nhu cầu và owner có thẩm quyền]
    J --> K[Ghi requirement]

    B -->|Sửa bản sao| L[Tra cứu CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY]
    L --> M[Sửa artifact canonical theo kiểm soát thay đổi]

    B -->|Nhầm IN_REVIEW là đã chấp thuận| N[Giữ trạng thái IN_REVIEW khi chưa có approval]

Applied

Trường	Nội dung
Facts	Nova Foods là case mô phỏng giáo dục, dữ liệu tổng hợp. Một bản nháp ghi: “ERP phải tự động xuất kho ngay khi tạo đơn bán hàng.”
Current Behavior	Câu không nêu điều kiện tồn kho, trạng thái đơn, người chịu trách nhiệm, trường hợp lỗi hay kết quả kiểm tra.
Underlying Need	Bộ phận kho cần biết khi nào được phép chuẩn bị hàng cho đơn bán; đây là nhu cầu kiểm soát quy trình, chưa chứng minh “xuất kho ngay” là giải pháp đúng.
Options	Giữ nguyên câu giải pháp; viết lại thành nhu cầu và điều kiện; tách thành requirement về điều kiện chuẩn bị hàng, quy tắc xuất kho và thông báo lỗi.
Decision Criteria	Mỗi câu phải có hành vi kiểm thử được, không tự đặt quyết định vận hành, và liên kết được nguồn canonical khi có rule.
Decision	Tách requirement; giữ “tự động” là giả định cần xác minh, không ghi như quy tắc Nova Foods đã hiệu lực.
Authority	Business Owner xác nhận nhu cầu vận hành; Architect đánh giá cơ chế ERP; QA kiểm tra khả năng kiểm thử. Principal IT Business Analyst / Technical Curriculum Author không tự xác nhận quyết định này.
Artifact	Ghi liên kết đến CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY khi các artifact này có mục tương ứng; hiện đều ở trạng thái IN_REVIEW, phiên bản v0.9.0.
Consequence if Wrong	Hệ thống có thể xuất hàng trước kiểm tra cần thiết; đội test không biết trường hợp nào phải chặn; tài liệu vẫn dài nhưng không chứng minh được hành vi cần xây.

Senior Lens

BA mới thường cố làm requirement nghe “chi tiết”. BA senior kiểm tra chi tiết đó có bằng chứng, có thẩm quyền và có thể kiểm thử không. Cầu nối suy luận: nếu người đọc khác nhau có thể xây hai hành vi khác nhau từ cùng một câu, câu đó chưa đủ chính xác để giao delivery.

Sửa lỗi nhỏ nhất trước: làm rõ chủ thể, sự kiện kích hoạt, dữ liệu, điều kiện và kết quả. Không thêm bảng, ID mới hoặc quy trình mới nếu chưa cần. Khi thiếu thông tin, ghi khoảng trống cần xác minh; không lấp bằng giả định rồi gọi là fact.

Quick Reference

Kiểm tra nhanh	Đạt khi
Một câu, một hành vi	Có thể viết test riêng cho câu đó
Có điều kiện	Nêu rõ khi nào hành vi xảy ra hoặc bị chặn
Có kết quả	Nêu được hệ thống, người dùng hoặc quy trình nhận gì
Có nguồn đúng	Không thay bản sao thành nguồn canonical
Có trạng thái đúng	IN_REVIEW không bị diễn giải là baseline hoặc approval

Core

Cảnh báo — rủi ro thật: Nếu requirement Nova Foods mô phỏng bị đưa vào phát triển khi chưa xác định người có thẩm quyền quyết định, ERP có thể ghi nhận sai giá trị tài chính, trạng thái tồn kho hoặc dữ liệu cá nhân. Dừng triển khai phần bị ảnh hưởng; không tự suy diễn quy tắc thay thế.

“Phục hồi an toàn” là đưa artifact về trạng thái có thể kiểm tra, không phải sửa câu chữ cho có vẻ hoàn chỉnh. Ranh giới an toàn: BA được làm rõ phạm vi, ghi bằng chứng, đánh dấu giả định và chuyển đúng owner; BA không được tự xác nhận pháp lý, kế toán, thuế, an toàn thực phẩm, bảo mật, baseline hay approval. IN_REVIEW tại v0.9.0 ngày 2026-08-07 chỉ cho biết artifact đang được xem xét.

Dấu hiệu lỗi Nova Foods mô phỏng	Rủi ro thực tế	Phục hồi an toàn	Không được làm
“Hệ thống tự tính đúng VAT” nhưng không có nguồn, công thức, thời điểm hiệu lực hoặc Accounting Owner	Sai hóa đơn, sổ sách, báo cáo	Gắn nhãn Verification required; tách thành câu hỏi quyết định cho Accounting Owner và Legal Owner; giữ nguyên bằng chứng nguồn	Gọi đây là “đúng luật” hoặc tự chọn mức thuế
“Kho được phép xuất thiếu” nhưng không có giới hạn, vai trò, trạng thái đơn hàng	Âm tồn kho mô phỏng, sai cam kết giao hàng	Chặn use case khỏi build; ghi điều kiện còn thiếu và Business Owner cần quyết định	Đặt giá trị mặc định bằng 0 hoặc “cho phép mọi trường hợp”
Tài liệu nói “đã được phê duyệt” nhưng không có approval reference	Đội triển khai hiểu nhầm thẩm quyền	Sửa về trạng thái thực: IN_REVIEW; liên kết artifact kiểm soát nếu có	Suy diễn approval từ Owner, cuộc họp, email không được ghi nhận hoặc metadata
Sơ đồ PlantUML activity được ghi là BPMN	Dev, QA hiểu sai semantics và gateway	Đổi nhãn thành “PlantUML activity diagram”; dùng BPMN 2.0.2 chỉ khi tạo BPMN hợp lệ	Trích OMG BPMN để hợp thức hóa sơ đồ không phải BPMN
Requirement không liên kết nguồn, rule, acceptance criteria hoặc test basis	Không chứng minh được vì sao phải xây và kiểm thử gì	Khôi phục liên kết về artifact canonical; nếu chưa có, ghi khoảng trống và dừng claim	Tạo ID, rule hoặc nguồn giả để lấp bảng

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; dữ liệu tổng hợp. Một yêu cầu ghi: “ERP cho phép chỉnh ngày sản xuất sau khi lô đã nhập kho để sửa lỗi nhập liệu.” Không có quy tắc nghiệp vụ canonical, không có quyết định từ Business Owner, Food-safety Owner hoặc Legal Owner.

Current Behavior: Delivery team chuẩn bị tạo màn hình sửa trực tiếp ngày sản xuất. QA chỉ nhận câu “người dùng có thể sửa”.

Underlying Need: Có thể cần sửa lỗi nhập liệu, nhưng chưa biết sửa ở trạng thái nào, ai được sửa, có cần lịch sử thay đổi, hay có ảnh hưởng truy xuất lô. Bằng chứng là requirement chỉ nêu hành động, không nêu điều kiện, thẩm quyền hoặc hậu quả.

Options: (1) Cho sửa trực tiếp mọi lúc; (2) chặn chức năng đến khi có quyết định; (3) thiết kế yêu cầu thay đổi có lưu lịch sử, nhưng chỉ sau khi owner xác định rule.

Decision Criteria: Bảo toàn khả năng truy vết; không tạo kết luận pháp lý hoặc an toàn thực phẩm chưa xác minh; xác định rõ owner; có test basis kiểm tra được.

Decision: Chọn (2). Ghi Verification required cho quy tắc sửa ngày sản xuất. Không phát hành requirement chức năng để build.

Authority: Business Owner quyết định nhu cầu vận hành; Food-safety Owner và Legal Owner xác minh nghĩa vụ truy xuất hoặc lưu vết nếu áp dụng. BA duy trì câu hỏi, bằng chứng và traceability.

Artifact: Cập nhật requirement draft trong /02-handbook/06-requirements-foundations.md bằng trạng thái mở cần xác minh; tham chiếu canonical artifact khi nội dung đã tồn tại. Không tạo canonical ID mới trong lúc xử lý lỗi.

Consequence if Wrong: Sửa trực tiếp có thể làm mất dấu giá trị ban đầu trong dữ liệu lô mô phỏng. QA không có tiêu chí để kiểm tra lịch sử, quyền sửa hoặc trạng thái cho phép. Đội delivery có thể nhầm ví dụ học liệu với quy tắc ERP production.

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

flowchart TB
    A[Phát hiện requirement có rủi ro] --> B["BA gắn Verification required / IN_REVIEW"]
    B --> Q[Dừng phát hành requirement và build phần bị ảnh hưởng]
    Q --> C[BA duy trì câu hỏi, bằng chứng và traceability]
    C --> D[BA chuyển câu hỏi cho đúng owner]

    D --> E{Business Owner quyết định cách xử lý sửa ngày sản xuất}
    E -- Cho phép --> E1[Ghi nhận điều kiện cho phép sửa]
    E -- Hạn chế --> E2[Ghi nhận trạng thái, quyền và điều kiện hạn chế]
    E -- Từ chối --> E3[Ghi nhận không cho phép sửa]
    E1 --> F
    E2 --> F
    E3 --> F

    F{Food-safety Owner xác minh nghĩa vụ truy xuất hoặc lưu vết}
    F -- Có áp dụng --> F1[Ghi nhận nghĩa vụ áp dụng]
    F -- Không áp dụng --> F2[Ghi nhận xác minh không áp dụng]
    F1 --> G
    F2 --> G

    G{Legal Owner xác minh nghĩa vụ truy xuất hoặc lưu vết}
    G -- Có áp dụng --> G1[Ghi nhận nghĩa vụ áp dụng]
    G -- Không áp dụng --> G2[Ghi nhận xác minh không áp dụng]
    G1 --> H
    G2 --> H

    H{Đã ghi nhận đủ quyết định của Business Owner và xác minh của hai owner?}
    H -- Chưa --> I["Giữ Verification required / IN_REVIEW và tiếp tục chặn"]
    I --> C

    H -- Rồi --> J[BA cập nhật requirement draft theo quyết định đã ghi nhận]
    J --> K[Soạn điều kiện kiểm tra cho phép, hạn chế hoặc từ chối sửa]
    K --> L{Quyết định đã ghi nhận có yêu cầu lưu lịch sử thay đổi?}
    L -- Có --> L1[Thêm yêu cầu lưu lịch sử thay đổi]
    L -- Không --> L2[Không thêm yêu cầu lưu lịch sử]
    L1 --> M[Liên kết artifact nguồn và test basis]
    L2 --> M

    M --> N{Canonical artifact đã tồn tại?}
    N -- Có --> O[Tham chiếu canonical artifact]
    N -- Không --> P[Không tạo canonical ID mới khi xử lý lỗi]
    O --> R[Requirement đã xác minh đủ điều kiện phát hành để build]
    P --> R

    A -. Luồng sai .-> X[Cho sửa trực tiếp hoặc phát hành requirement khi chưa xác minh]
    X --> S1[Có thể mất dấu giá trị ban đầu của lô]
    X --> S2[QA không có test basis kiểm tra được]
    X --> S3[Delivery có thể nhầm ví dụ học liệu với quy tắc ERP production]

Senior Lens

Warning callout chỉ dùng khi sai sót có thể gây mất dữ liệu, sai báo cáo, sai quyền truy cập, sai tuân thủ, sai truy xuất hoặc khiến delivery xây nhầm. Không dùng warning để nhấn mạnh mẹo viết câu. Cảnh báo cần nêu đủ: đối tượng bị ảnh hưởng, hành động chặn ngay, bằng chứng thiếu, owner cần quyết định và ranh giới BA không được vượt.

Một recovery tốt không “đóng” khoảng trống bằng giả định. Nó biến khoảng trống thành quyết định có thể quản trị: ai quyết định, dựa trên nguồn nào, artifact nào phải cập nhật, điều gì chưa được phép build. Đây là cầu nối từ phát hiện rủi ro sang kiểm soát delivery.

Quick Reference

Khi gặp	Làm ngay	Điểm dừng
Claim “đã phê duyệt” không có reference	Đổi về trạng thái thực tế, ghi thiếu bằng chứng	Không dùng claim đó làm cơ sở build
Rule có tác động pháp lý, kế toán, thuế, dữ liệu cá nhân hoặc an toàn thực phẩm	Gắn Verification required, chuyển owner chuyên môn	Không diễn giải nguồn thành nghĩa vụ dự án
Sơ đồ bị gọi sai notation	Sửa nhãn hoặc thay bằng notation hợp lệ	Không gọi PlantUML là BPMN
Requirement có nguy cơ mất traceability	Khôi phục link về artifact canonical hoặc ghi khoảng trống	Không tạo link, ID hoặc rule giả

Core

Năm lỗi phải tách riêng vì cách sửa khác nhau. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; IN_REVIEW, v0.9.0 ngày 2026-08-07 không phải phê duyệt hay baseline.

Loại lỗi	Dấu hiệu quan sát được	Nguyên nhân gốc	Hành động sửa an toàn
Mơ hồ (ambiguity)	“Hệ thống xử lý nhanh”, “đơn lớn”, “quản lý duyệt”	Từ không có ngưỡng, vai trò hoặc điều kiện	Thay bằng điều kiện đo được, đơn vị, nguồn dữ liệu, vai trò và kết quả
Thiếu thông tin (incompleteness)	Có luồng tạo đơn nhưng không có hủy, lỗi tích hợp, dữ liệu bắt buộc	Chỉ khảo sát happy path, luồng thành công	Bổ sung ngoại lệ, trạng thái, dữ liệu đầu vào/ra, quy tắc lỗi và tiêu chí chấp nhận
Khẳng định thẩm quyền không có chứng cứ	“Luật bắt buộc”, “Kế toán đã duyệt”, “Business Owner chấp thuận” nhưng không có tham chiếu	BA suy diễn từ trao đổi, nguồn thứ cấp hoặc metadata	Gắn Verification required; nêu vai trò phải xác minh; không biến thành requirement bắt buộc
Dùng sai ký pháp (notation misuse)	Gọi sơ đồ PlantUML activity là BPMN; dùng mũi tên không có nghĩa trạng thái	Nhầm công cụ vẽ với chuẩn mô hình	Ghi đúng loại sơ đồ; dùng BPMN 2.0.2 khi tuyên bố BPMN; ghi chú giới hạn ngữ nghĩa
Đứt truy vết (traceability break)	Requirement không nối nguồn, rule, acceptance criteria hoặc test basis	ID tự đặt, đổi tên im lặng, sao chép bảng	Giữ canonical ID; liên kết artifact canonical; ghi thay đổi có kiểm soát

Mơ hồ khác thiếu thông tin. “Đơn lớn cần duyệt” mơ hồ vì đã có ý định nhưng thiếu ngưỡng và người duyệt. “Không mô tả đơn bị từ chối qua API” thiếu thông tin vì nhánh xử lý chưa tồn tại. Không được “sửa” bằng cách tự chọn ngưỡng hay tự gán thẩm quyền.

[!WARNING] Không ghi “đáp ứng Luật Bảo vệ dữ liệu cá nhân” hoặc “đúng Luật Kế toán” khi chưa có xác minh từ Legal Owner hoặc Accounting Owner. Nguồn luật xác nhận bối cảnh cần xem xét, không tự tạo diễn giải hay phê duyệt cho Nova Foods mô phỏng.

Applied

Facts: Bản nháp mô phỏng REQ-SO-014 ghi: “ERP tự động chặn đơn bán vượt hạn mức tín dụng và quản lý phê duyệt đơn lớn.” Bản nháp không nêu hạn mức, vai trò quản lý, trạng thái đơn, hành vi khi dịch vụ tín dụng lỗi, hay nguồn xác nhận quy tắc.

Current Behavior: Không thể thiết kế màn hình, API, test case hoặc phân quyền từ câu này. Tester không biết giá trị nào phải kiểm tra; Developer không biết chặn, cảnh báo hay gửi duyệt.

Underlying Need: Kiểm soát rủi ro bán chịu và cho phép xử lý ngoại lệ có thẩm quyền.

Options:

Phương án	Nội dung	Rủi ro
A	Tự ghi ngưỡng 500.000.000 VND và vai trò Sales Manager	Fabricated rule; tạo quyết định nghiệp vụ giả
B	Chỉ đổi “đơn lớn” thành “đơn vượt hạn mức”	Giảm mơ hồ một phần; vẫn thiếu nguồn hạn mức, người duyệt và lỗi
C	Tách requirement hệ thống khỏi rule chưa xác minh	Giữ đúng boundary; cần quyết định từ Business Owner và Finance Owner

Decision Criteria: Không tự tạo business rule; mỗi trạng thái phải có tác nhân và điều kiện; mỗi claim thẩm quyền phải có evidence; mô hình phải truy vết tới artifact canonical.

Decision: Chọn C. Viết REQ-SO-014 ở mức có thể kiểm chứng: “Khi dịch vụ tín dụng trả về trạng thái vượt hạn mức, ERP phải ngăn xác nhận đơn và hiển thị lý do từ phản hồi dịch vụ.” Ngưỡng tín dụng, quyền override, vai trò duyệt và xử lý khi dịch vụ không phản hồi được ghi Verification required.

Authority: Business Owner quyết định chính sách bán hàng; Finance Owner xác nhận hạn mức và quyền vượt hạn mức; Architect xác nhận hành vi tích hợp; QA chuyển requirement đã rõ thành test basis. Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì truy vết, không xác nhận các quyết định này.

Artifact: Liên kết REQ-SO-014 tới /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md và, nếu có dữ liệu tín dụng, /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Không tạo ID thay thế hoặc gọi các artifact này là baseline.

Consequence if Wrong: Ngưỡng tự bịa có thể chặn đơn hợp lệ hoặc cho phép bán chịu vượt chính sách. Claim “đã duyệt” không có chứng cứ làm người triển khai tin sai phạm vi quyết định.

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

flowchart TB
    A["REQ-SO-014 draft"] --> E["Phần đã xác nhận:<br/>Khi dịch vụ tín dụng trả trạng thái vượt hạn mức,<br/>ngăn xác nhận đơn và hiển thị lý do từ phản hồi"]

    E --> B{"Business Owner có evidence<br/>cho chính sách bán hàng?"}
    B -- "Chưa" --> B0["Giữ Verification required<br/>Không triển khai chính sách giả định"]
    B -- "Có" --> B1["Đặc tả chính sách bán hàng<br/>theo evidence"]
    B0 --> C
    B1 --> C

    C{"Finance Owner có evidence<br/>cho hạn mức và quyền override?"}
    C -- "Chưa" --> C0["Giữ Verification required<br/>Không triển khai ngưỡng hoặc override giả định"]
    C -- "Có" --> C1["Đặc tả hạn mức và quyền override<br/>theo evidence"]
    C0 --> D
    C1 --> D

    D{"Owner tương ứng có evidence<br/>cho vai trò duyệt và trạng thái đơn?"}
    D -- "Chưa" --> D0["Giữ Verification required<br/>Không triển khai vai trò hoặc trạng thái giả định"]
    D -- "Có" --> D1["Đặc tả vai trò duyệt và trạng thái đơn<br/>theo evidence"]
    D0 --> X
    D1 --> X

    X{"Architect đã xác nhận hành vi<br/>khi dịch vụ lỗi hoặc không phản hồi?"}
    X -- "Chưa" --> X0["Giữ Verification required<br/>Không triển khai hành vi tích hợp giả định"]
    X -- "Có" --> X1["Đặc tả hành vi tích hợp<br/>theo evidence"]
    X0 --> F
    X1 --> F

    F["Sau khi kiểm tra riêng từng claim:<br/>chỉ triển khai claim có evidence;<br/>phần vượt hạn mức đã xác nhận vẫn được giữ"] --> G["Principal IT Business Analyst /<br/>Technical Curriculum Author<br/>chỉ duy trì truy vết;<br/>không xác nhận quyết định nghiệp vụ"]

    G --> H["Liên kết REQ-SO-014 tới:<br/>CANONICAL_BUSINESS_RULES.md<br/>TRACEABILITY_ID_REGISTRY.md<br/>CANONICAL_DATA_DICTIONARY.md khi có dữ liệu tín dụng<br/>Không tạo ID thay thế"]
    H --> I["QA chuyển phần requirement đã xác nhận<br/>thành test basis"]

    F -. "Nếu vi phạm boundary" .-> R["Rủi ro:<br/>chặn đơn hợp lệ;<br/>cho phép bán chịu vượt chính sách;<br/>claim “đã duyệt” không có evidence"]

Senior Lens

Ký pháp không thay thế nội dung. PlantUML activity diagram mô tả luồng ở mức dễ đọc, nhưng không được gọi là BPMN. Khi artifact yêu cầu BPMN, dùng phần tử BPMN 2.0.2 và giữ semantics BPMN; khi chỉ cần giải thích logic, ghi rõ “PlantUML activity diagram, không phải BPMN”.

Đứt traceability thường bắt đầu từ thay đổi nhỏ: đổi câu requirement nhưng không cập nhật rule, đổi tên file, hoặc tạo bản sao bảng rồi để hai bản cùng là “nguồn thật”. Recovery boundary: dừng dùng artifact bị đứt làm test basis hoặc quyết định triển khai; xác định artifact canonical; nối lại liên kết; ghi rõ phần nào còn IN_REVIEW. Không hồi tố claim approval hoặc baseline.

Quick Reference

Kiểm tra trước khi giữ requirement	Đạt khi
Có thể kiểm tra?	Có điều kiện, kết quả, dữ liệu và ngoại lệ đủ rõ
Có đủ thông tin?	Có luồng chính, lỗi, trạng thái và boundary liên quan
Có đúng thẩm quyền?	Claim có evidence hoặc mang nhãn Verification required
Có đúng ký pháp?	Tên sơ đồ khớp chuẩn được dùng; không gán nhãn BPMN/UML sai
Có truy vết?	Canonical ID, filename và source classification giữ nguyên; liên kết không tự tạo 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” mà chọn phương án có bằng chứng, đúng thẩm quyền, kiểm chứng được và làm rõ hệ quả. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là dữ liệu tổng hợp. Vì vậy, một đề xuất chỉ là giả định dự án cho đến khi artifact kiểm soát ghi nhận nguồn, người có thẩm quyền và trạng thái phù hợp. IN_REVIEW tại v0.9.0 ngày 2026-08-07 không phải baseline, approval hay quyền triển khai.

Trade-off là đánh đổi: đạt một lợi ích nhưng chịu một chi phí, rủi ro hoặc giới hạn khác. Ví dụ, Sales muốn cho sửa giá sau khi đơn hàng được xác nhận để xử lý khách hàng lớn; Accounting cần giá đã ghi nhận ổn định để đối soát; Security cần giới hạn ai được sửa. Ba nhu cầu cùng hợp lý, nhưng không cùng quyết định một người. BA tách chúng thành: nhu cầu nghiệp vụ, rủi ro kiểm soát, dữ liệu bị ảnh hưởng, và chủ thể có quyền quyết định.

Điểm phân tích	Câu hỏi Senior BA phải trả lời	Bằng chứng cần có	Thẩm quyền quyết định
Giá trị nghiệp vụ	Sửa giá giải quyết trường hợp nào, tần suất bao nhiêu?	Dữ liệu tổng hợp về số đơn, loại ngoại lệ, tác động doanh thu	Business Owner
Tính đúng dữ liệu	Giá nào là giá nguồn cho hóa đơn, công nợ, báo cáo?	Data model, rule catalog, quy trình đối soát	Accounting Owner và Business Owner
Kiểm soát truy cập	Ai được sửa, sửa đến trạng thái nào, có cần lưu lịch sử?	Risk assessment, security requirement, quyền hệ thống	Security và Architect
Tác động kỹ thuật	Thay đổi có làm sai integration, audit trail, báo cáo không?	Interface contract, data lineage, thiết kế hiện hành	Architect
Kiểm thử	Điều kiện nào chứng minh thay đổi không phá luồng cũ?	Acceptance criteria, test basis	QA và Business Owner

Ngoại lệ không phải lỗi trong rule. Ngoại lệ là tình huống hợp lệ nhưng cần điều kiện riêng. Normal rule: không sửa đơn sau trạng thái xác nhận. Exception chỉ nên tồn tại khi có nguyên nhân nghiệp vụ rõ, điều kiện kích hoạt, quyền thực hiện, dữ liệu lưu vết và hậu quả khi dùng sai. Nếu Sales nói “khách quan trọng thì cần linh hoạt”, câu này chưa đủ làm requirement vì “khách quan trọng” chưa có định nghĩa, ngưỡng, nguồn dữ liệu hoặc người chịu trách nhiệm.

Stakeholder conflict không được giải bằng cách BA tự dung hòa thành rule mới. BA ghi riêng từng vị trí, chỉ ra điểm xung đột và chuẩn bị quyết định. Với REQ-SO-014, Sales có thể đề nghị sửa giá trước giao hàng; Accounting có thể yêu cầu tạo điều chỉnh thay vì sửa trực tiếp; Architect có thể cảnh báo integration chỉ nhận một giá xác nhận. Suy luận là: nếu sửa trực tiếp giá đã gửi sang hệ thống khác, hai hệ thống có thể giữ giá khác nhau. Bằng chứng phải là contract integration hoặc mô tả dữ liệu hiện hành, không phải suy đoán từ chức danh người phát biểu.

Phương án mô phỏng cho REQ-SO-014	Lợi ích	Chi phí hoặc rủi ro	Điều kiện để xem xét
Cấm sửa giá sau xác nhận	Dữ liệu ổn định, dễ đối soát	Giảm linh hoạt xử lý ngoại lệ	Phù hợp khi chưa có luồng điều chỉnh được xác minh
Cho sửa trực tiếp theo quyền	Xử lý nhanh	Rủi ro lệch audit trail, integration, báo cáo	Chỉ xem xét khi Security, Accounting Owner và Architect xác nhận kiểm soát
Tạo yêu cầu điều chỉnh giá riêng	Có lịch sử trước và sau thay đổi	Tăng bước xử lý và yêu cầu phát triển	Phù hợp khi cần truy vết điều chỉnh nhưng quy trình thật chưa được xác minh

Chất lượng evidence quyết định độ mạnh của khuyến nghị. Evidence mạnh là artifact canonical có version, nguồn chính thức hoặc dữ liệu quan sát có thể kiểm tra lại. Evidence yếu là ý kiến không có ví dụ, ảnh chụp màn hình không rõ môi trường, bản sao không xác định nguồn, hoặc câu “hệ thống hiện làm vậy”. Evidence yếu vẫn được ghi nhận, nhưng chỉ hỗ trợ câu hỏi cần xác minh; không đủ để biến thành business rule hay ràng buộc pháp lý.

Senior BA dùng ngôn ngữ chính xác khi chưa đủ certainty. Ghi: “Khuyến nghị chọn phương án tạo điều chỉnh giá riêng vì giảm nguy cơ mất lịch sử thay đổi; kết luận phụ thuộc xác minh interface contract và xác nhận của Accounting Owner.” Không ghi: “Nova Foods bắt buộc dùng điều chỉnh giá” khi chưa có nguồn và thẩm quyền. Câu đầu nêu phương án, lý do, khoảng trống evidence và người quyết định; câu sau tạo certainty không có căn cứ.

Decision authority là quyền ra quyết định, không phải người nói nhiều nhất hoặc người tham dự họp cao cấp nhất. BA sở hữu việc làm rõ, phân tích, ghi traceability và nêu hệ quả. Business Owner quyết định ưu tiên nghiệp vụ. Accounting Owner quyết định diễn giải kế toán trong phạm vi được giao. Legal Owner xác minh yêu cầu pháp lý. Security quyết định chấp nhận kiểm soát bảo mật. Architect quyết định phù hợp kiến trúc. Nếu một quyết định chạm nhiều quyền, giữ các kết luận tách biệt và không gộp thành “đã thống nhất” khi chưa có ghi nhận từ các vai trò cần thiết.

Senior Lens

Senior BA review không chỉ kiểm tra requirement có đủ câu chữ. Senior BA kiểm tra quyết định có đứng vững khi bị hỏi: bằng chứng nào hỗ trợ, ai có quyền chọn, tác động nào chưa đo được. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu đều tổng hợp; IN_REVIEW tại v0.9.0 ngày 2026-08-07 không phải baseline, phê duyệt, hay quyền triển khai.

Heuristic review	Kiểm tra cụ thể	Red flag	Ngưỡng escalation	Ngoại lệ không áp dụng quy tắc thường
Một nguồn chân lý	Rule, thuật ngữ, ID và dữ liệu có tham chiếu đúng artifact canonical như CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY	Hai artifact ghi khác nhau cho cùng khái niệm nhưng không nói artifact nào ưu tiên	Escalate ngay khi khác biệt có thể đổi dữ liệu, luồng xử lý, báo cáo hoặc test	Bản nháp khám phá được phép chứa giả thuyết, nhưng phải gắn là giả thuyết; không được trình bày như rule
Bằng chứng trước ý kiến	Mỗi yêu cầu phải chỉ ra nguồn, quan sát quy trình, dữ liệu mẫu tổng hợp, hoặc quyết định có thẩm quyền	“Người dùng nói” nhưng không có vai trò, thời điểm, phạm vi, hay vật chứng	Escalate khi yêu cầu ảnh hưởng tiền, dữ liệu cá nhân, an toàn thực phẩm, hóa đơn, sổ sách hoặc quyền truy cập mà thiếu bằng chứng kiểm chứng	Khám phá sớm có thể dùng phỏng vấn làm tín hiệu ban đầu; chưa được dùng làm kết luận tuân thủ
Tách nhu cầu khỏi giải pháp	Nêu mục tiêu nghiệp vụ trước; sau đó mới so sánh cấu hình ERP, thay đổi quy trình hoặc tích hợp	Requirement khóa sẵn màn hình, API, bảng DB khi chưa chứng minh cần thiết	Escalate đến Architect khi giải pháp chạm kiến trúc, tích hợp, hiệu năng, bảo mật hoặc dữ liệu dùng chung	Nếu giao diện hoặc API bị ràng buộc bởi hợp đồng đã được ghi nhận trong artifact kiểm soát, có thể giữ ràng buộc đó
Quyền quyết định đúng vai trò	Business Owner quyết định ưu tiên nghiệp vụ; Architect quyết định kiến trúc; Legal, Accounting, Security xác nhận phần thuộc chuyên môn	BA hoặc nhóm dự án tự chọn cách diễn giải pháp lý, kế toán, thuế hoặc kiểm soát bảo mật	Escalate ngay khi một đề xuất đồng thời thuộc từ hai thẩm quyền trở lên	Senior BA được tổng hợp lựa chọn và tác động; không thay thế quyết định chuyên môn
Tác động hai chiều	Truy từ nhu cầu đến requirement, acceptance criteria, test basis; truy ngược từ thay đổi đến stakeholder và artifact bị ảnh hưởng	Requirement không có tiêu chí kiểm thử, hoặc thay đổi data field không kiểm tra báo cáo và tích hợp	Escalate khi không xác định được phạm vi tác động trước khi cam kết lịch hoặc chi phí	Spike kỹ thuật có thể chưa đủ traceability hoàn chỉnh, nhưng phải giới hạn mục tiêu và không thành cam kết delivery
Chi phí sai lầm	Ưu tiên kiểm tra phần có hậu quả lớn trước: tiền, tồn kho, truy xuất lô, quyền truy cập, dữ liệu cá nhân	Nhóm dành nhiều thời gian chỉnh thuật ngữ nhưng chưa làm rõ điều kiện chặn xuất kho hay sửa chứng từ	Escalate khi hậu quả sai có thể gây mất dữ liệu, sai số tài chính, lộ dữ liệu hoặc ngừng vận hành	Lỗi trình bày nhỏ có thể xử lý sau nếu không đổi nghĩa, quyền, tính toán hay khả năng tiếp cận

Quy tắc thường là “đủ bằng chứng rồi mới chốt”. Không áp dụng quy tắc này khi cần quyết định tạm để giảm rủi ro khẩn cấp, như chặn quyền truy cập nghi ngờ sai. Khi đó, Senior BA phải giới hạn quyết định theo phạm vi nhỏ nhất, ghi rõ đây là biện pháp tạm thời, và chuyển xác nhận cho Security hoặc vai trò có thẩm quyền. Không dùng tình trạng khẩn cấp để né kiểm tra nguồn hay hợp thức hóa thay đổi lớn.

Red flag mạnh gồm: số liệu VND không có công thức hoặc nguồn; từ “tuân thủ”, “bắt buộc”, “đúng luật” không có Legal Owner xác minh; rule kế toán không có Accounting Owner; yêu cầu tích hợp không có chủ sở hữu hệ thống nguồn và đích; dữ liệu cá nhân được đưa vào ví dụ mà không nêu phân loại và quyền truy cập; stakeholder yêu cầu “làm giống hệ thống cũ” nhưng không giải thích mục tiêu cần giữ. Mỗi red flag là tín hiệu dừng suy luận, không phải lỗi để BA tự sửa bằng phỏng đoán.

Escalation phải chứa tối thiểu: vấn đề cần quyết định, artifact và đoạn bị ảnh hưởng, bằng chứng đang có, mâu thuẫn còn lại, hậu quả của từng lựa chọn, vai trò có thẩm quyền, và quyết định cần nhận. Ví dụ, nếu quy tắc xuất kho của Nova Foods mô phỏng mâu thuẫn giữa nhu cầu giao hàng nhanh và yêu cầu giữ truy xuất lô, Senior BA không chọn bên thắng theo cấp bậc người phát biểu. Senior BA chuyển vấn đề tới Business Owner và domain owner phù hợp, vì mâu thuẫn là cân bằng mục tiêu vận hành với kiểm soát chất lượng; BA bảo toàn facts, tác động và traceability.

Senior Lens

Senior BA không biến thiếu bằng chứng thành kết luận. Khuyến nghị phải tách rõ fact (sự kiện có nguồn), assumption (giả định dự án chưa kiểm chứng), inference (suy luận từ fact) và verification required (cần vai trò có thẩm quyền xác minh). Chuỗi này giúp người đọc kiểm tra vì sao BA đề xuất lựa chọn, không nhầm đề xuất với quyết định đã phê duyệt.

Trường ghi trong artifact	Cách ghi defensible	Không được ghi
Fact	“CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY đều có trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07.”	“Quy tắc và dữ liệu đã được chốt.”
Nguồn	“Nguồn quản trị: /01-curriculum/CANONICAL_BUSINESS_RULES.md; nguồn dữ liệu: /01-curriculum/CANONICAL_DATA_DICTIONARY.md.”	“Theo hệ thống Nova Foods.”
Inference	“Vì hai nguồn canonical chưa baseline, requirement dẫn chiếu chúng chưa đủ cơ sở để coi là cấu hình ERP cuối cùng.”	“ERP chắc chắn phải xử lý như vậy.”
Uncertainty	“Chưa xác minh owner nghiệp vụ có chấp nhận ngoại lệ cho lô hàng thu hồi.”	“Owner đồng ý ngoại lệ.”
Recommendation	“Đề xuất giữ requirement ở trạng thái cần review, không viết acceptance criteria mang tính bắt buộc trước khi có quyết định đúng thẩm quyền.”	“Phê duyệt requirement này.”
Authority	“Business Owner quyết định ưu tiên nghiệp vụ; Legal Owner xác minh nghĩa vụ pháp lý; Accounting Owner xác minh diễn giải kế toán.”	“Senior BA xác nhận tuân thủ.”

Ví dụ ghi nhận cho Nova Foods Trading & Manufacturing là mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp:

Mục	Nội dung ghi nhận
Vấn đề	Requirement yêu cầu chặn xuất kho khi mã lô không có thông tin truy xuất.
Fact	Luật An toàn thực phẩm là nguồn bối cảnh cho truy xuất và thu hồi; source seed yêu cầu domain-owner và legal verification.
Inference	Vì source seed không xác nhận chi tiết rule ERP hoặc điều kiện chặn xuất kho, không thể suy ra mức chặn bắt buộc cho mọi giao dịch.
Uncertainty	Chưa có xác nhận từ Business Owner về tác động giao hàng; chưa có xác minh Legal Owner về nghĩa vụ cụ thể.
Recommendation	Ghi requirement là Verification required; mô tả hai phương án: chặn giao dịch hoặc cảnh báo kèm luồng phê duyệt ngoại lệ.
Decision authority	Business Owner chọn tác động vận hành; Legal Owner xác minh nghĩa vụ; Architect xác minh cơ chế kiểm soát.
Trạng thái	Không gọi là approved, baselined, compliant hoặc production-ready khi artifact vẫn IN_REVIEW.

Mẫu câu senior: “Dựa trên nguồn X, có bằng chứng cho Y. Chưa có bằng chứng cho Z. Vì Z quyết định mức kiểm soát và rủi ro vận hành, khuyến nghị chưa cố định rule; chuyển gói quyết định cho vai trò A. Nếu A chọn phương án 1, cập nhật traceability và acceptance criteria sau.” Câu này nêu đủ bằng chứng, giới hạn, lý do và người quyết định; không gán chắc chắn giả tạo.

12. Associated Template Reference & Completed Artifact

Core

Template là biểu mẫu chuẩn để ghi nhận cùng loại thông tin theo cấu trúc lặp lại. Template không tự tạo requirement, quyết định, approval hoặc baseline. Tại v0.9.0, trạng thái IN_REVIEW, Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; vì vậy chỉ dùng template để luyện truy vết và kiểm tra chất lượng.

Applied

Trường	Nội dung Nova Foods mô phỏng
Facts	Nguồn đã xác minh nêu TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md, TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md, CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md, CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Không có template ID GEN-TMPL-{NNN} hay file template cụ thể được cung cấp trong phạm vi micro-batch này.
Current Behavior	BA tra manifest trước khi chọn biểu mẫu; không tự tạo ID, tên file, hoặc bản sao được gọi là canonical.
Underlying Need	Requirement cần liên kết đúng rule, dữ liệu, định danh và nguồn để người review kiểm tra được bằng chứng.
Options	Dùng template đã đăng ký; dùng artifact canonical làm nguồn tra cứu; tự tạo template cục bộ.
Decision Criteria	ID và file phải có trong manifest; owner phải rõ; consumer phải xác định; quality gate phải kiểm tra được; không vượt thẩm quyền pháp lý, kế toán, bảo mật.
Decision	Chỉ tham chiếu artifact đã có ID và đường dẫn xác minh. Không dùng template ID hoặc file chưa được TEMPLATE_MANIFEST đăng ký.
Authority	Principal IT Business Analyst / Technical Curriculum Author quản trị manifest. Business Owner, Legal Owner, Accounting Owner, Security Owner, Architect, QA Reviewer xác minh nội dung thuộc thẩm quyền tương ứng.
Artifact	Bảng tham chiếu trong mục ### Quick Reference của chapter này.
Consequence if Wrong	ID tự tạo làm đứt traceability; file không canonical làm reviewer kiểm sai nguồn; rule pháp lý hoặc kế toán có thể bị diễn đạt vượt bằng chứng.

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

flowchart TB
    A[BA cần biểu mẫu hoặc artifact] --> B{ID và file có trong TEMPLATE_MANIFEST do Principal IT Business Analyst / Technical Curriculum Author quản trị?}
    B -- Có --> C{Owner, consumer, quality gate rõ và kiểm tra được?}
    B -- Không --> D{Artifact canonical có ID và đường dẫn đã xác minh?}
    D -- Có --> H[Dùng artifact đã xác minh cho phân tích IN_REVIEW]
    D -- Không --> X[Dừng sử dụng nguồn]
    C -- Không --> E[Dừng sử dụng đến khi owner, consumer, quality gate được xác minh]
    C -- Có --> F{Cần owner chuyên môn xác minh?}
    F -- Không --> H
    F -- Có --> G[Business Owner, Legal Owner, Accounting Owner, Security Owner, Architect hoặc QA Reviewer xác minh theo phạm vi]
    G --> I{Chấp thuận?}
    I -- Có --> H
    I -- Yêu cầu sửa --> J[Sửa nội dung theo phản hồi]
    J --> G
    I -- Từ chối --> X
    X --> R[Rủi ro tránh được: đứt traceability, reviewer kiểm sai nguồn, diễn đạt vượt bằng chứng pháp lý, kế toán hoặc bảo mật]

Senior Lens

Không suy luận “có manifest” thành “đã có template hoàn chỉnh”. Bằng chứng hiện có chỉ xác nhận TEMPLATE_MANIFEST là controlled planning artifact. Vì nội dung chi tiết của GEN-TMPL-{NNN} không nằm trong nguồn được cung cấp, việc điền ID cụ thể sẽ là bịa định danh. Senior BA giữ ô tham chiếu ở mức “chưa xác minh trong phạm vi nguồn”, rồi truy vấn manifest trước handoff.

Quick Reference

Template hoặc nguồn liên kết	ID / file canonical	Dùng khi	Không dùng khi	Owner	Consumer	Quality gate
Template manifest	TEMPLATE_MANIFEST — /01-curriculum/TEMPLATE_MANIFEST.md	Cần xác nhận template ID, file, dependency, phạm vi và trạng thái đăng ký	Cần chứng minh rule nghiệp vụ, định nghĩa dữ liệu, hay approval	Principal IT Business Analyst / Technical Curriculum Author	BA, curriculum author, QA reviewer	ID/file phải khớp manifest; IN_REVIEW không được gọi baseline hoặc approved
Registry định danh	TRACEABILITY_ID_REGISTRY — /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Cần kiểm tra ID requirement, rule, data, risk hoặc liên kết truy vết	Cần tạo ID mới ngoài registry	Principal IT Business Analyst / Technical Curriculum Author	BA, QA reviewer, Architect	Giữ nguyên canonical ID; mâu thuẫn ID phải escalation
Catalog rule	CANONICAL_BUSINESS_RULES — /01-curriculum/CANONICAL_BUSINESS_RULES.md	Requirement cần tham chiếu business rule	Cần tự xác nhận rule là vận hành thật hoặc compliant	Principal IT Business Analyst / Technical Curriculum Author; nội dung do owner chuyên môn xác minh	BA, Business Owner, QA reviewer	Rule phải có nguồn, trạng thái và authority; legal/accounting rule cần owner tương ứng
Từ điển dữ liệu	CANONICAL_DATA_DICTIONARY — /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Cần thống nhất tên trường, ý nghĩa logic, kiểu dữ liệu hoặc phân loại dữ liệu	Cần suy ra schema triển khai hoặc quyền production	Principal IT Business Analyst / Technical Curriculum Author; Architect/Security xác minh phần thuộc thẩm quyền	BA, Architect, QA reviewer, Security Owner	Tên dữ liệu phải khớp canonical; dữ liệu cá nhân cần Legal Owner và Security Owner xác minh
Template cụ thể	Chưa xác minh ID/file trong phạm vi nguồn micro-batch	Chỉ dùng sau khi TEMPLATE_MANIFEST xác nhận ID và file	Không tự đặt GEN-TMPL-{NNN}, không tạo file giả canonical	Owner ghi trong manifest	Consumer ghi trong manifest	Có ID, file, owner, consumer, dependency, quality gate trong manifest

Quick Reference

Tra cứu chapter này theo thứ tự. Mục tiêu: tìm đúng bằng chứng requirement, không chép lại registry canonical, không biến ví dụ Nova Foods thành quyết định vận hành thật.

Mục	Cần tra cứu	Bằng chứng phải thấy	Vị trí
1. Concept l? g??	Định nghĩa requirement, business rule, stakeholder need	Thuật ngữ phân biệt rõ; không đồng nhất nhu cầu với giải pháp	/02-handbook/06-requirements-foundations.md, H2 1
2. T?i sao concept n?y t?n t?i?	Lý do cần requirements foundation	Chuỗi lý do từ vấn đề nghiệp vụ đến kiểm soát thay đổi	Cùng tệp, H2 2
3. V? tr? trong Lifecycle	Vị trí trong vòng đời phân tích, xây dựng, kiểm thử	Input trước và output sau không mâu thuẫn	Cùng tệp, H2 3
4. Input c?n thi?t	Nguồn đầu vào, giới hạn nguồn	Nguồn phân loại đúng; giả định có nhãn	Cùng tệp, H2 4
5. Step-by-step BA Activities	Hoạt động BA theo bước	Mỗi bước có mục đích, bằng chứng, người liên quan	Cùng tệp, H2 5
6. Output thu ???c	Deliverable, tức đầu ra có thể kiểm tra	Output liên kết được với input và consumer	Cùng tệp, H2 6
7. Who consumes those outputs?	Vai trò dùng output	Mỗi consumer có quyết định hoặc hành động rõ	Cùng tệp, H2 7
8. Detailed Worked Example	Case Nova Foods đã điền	Facts, Current Behavior, Underlying Need, Options, Decision Criteria, Decision, Authority, Artifact, Consequence if Wrong đủ	Cùng tệp, H2 8
9. Related Concepts & Dependencies	Dependency với rule, data, traceability, test basis	Không tạo nguồn chân lý thứ hai	Cùng tệp, H2 9
10. Common Mistakes & Anti-patterns	Lỗi thường gặp	Có dấu hiệu nhận biết và hậu quả	Cùng tệp, H2 10
11. Senior BA Notes & Rules of Thumb	Quy tắc phán đoán senior	Nêu giới hạn thẩm quyền và điều kiện escalation	Cùng tệp, H2 11
12. Associated Template Reference & Completed Artifact	Liên kết template và artifact đã điền	Đường dẫn, ID, trạng thái, version khớp metadata corpus	Cùng tệp, H2 12

Artifact Nova Foods đã điền của chapter nằm tại /02-handbook/06-requirements-foundations.md, mục 8. Detailed Worked Example. Đây là case study Nova Foods Trading & Manufacturing mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; không phải cấu hình ERP, rule vận hành, bằng chứng tuân thủ, baseline hay approval.

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

flowchart TB
    A["Nhu cầu tra cứu requirement"] --> B{"Cần loại bằng chứng nào?"}

    B -->|"Khái niệm, lý do, lifecycle, input"| C["Tra H2 1-4"]
    B -->|"Hoạt động BA, output, consumer"| D["Tra H2 5-7"]
    B -->|"Ví dụ đã điền"| E["Tra H2 8: artifact Nova Foods"]
    B -->|"Dependency, lỗi, quy tắc senior"| F["Tra H2 9-11"]

    C --> G["Đối chiếu nhu cầu, giải pháp, rule và giả định"]
    D --> G
    F --> G

    E --> H["Chỉ dùng dữ liệu tổng hợp để học"]
    H --> I["Không dùng làm cấu hình ERP, rule vận hành, bằng chứng tuân thủ, baseline hoặc approval"]
    I --> G

    G --> J{"Ví dụ Nova Foods có nêu nghĩa vụ pháp lý, kế toán, thuế, an toàn thực phẩm, dữ liệu cá nhân hoặc bảo mật?"}
    J -->|"Không"| L["Tra H2 12: template link, artifact ID, trạng thái, version"]
    J -->|"Có"| K{"Owner có thẩm quyền đã xác minh?"}
    K -->|"Chưa"| Q["Giữ nhãn Verification required hoặc project assumption"]
    Q --> L
    K -->|"Đã xác minh"| R["Chỉ bỏ nhãn khi có xác minh owner có thẩm quyền"]
    R --> L

    L --> M{"Template link, artifact ID, trạng thái, version, đường dẫn và metadata đúng?"}
    M -->|"Đúng"| N["/02-handbook/06-requirements-foundations.md<br/>IN_REVIEW · v0.9.0 · 2026-08-07<br/>vi-VN · Asia/Ho_Chi_Minh · VND"]
    N --> O["Hoàn tất tra cứu"]
    M -->|"Sai hoặc thiếu"| P["Không hoàn tất: sửa tham chiếu, artifact hoặc metadata"]
    P --> L

Checklist hoàn tất khi mọi tham chiếu dùng đúng /02-handbook/06-requirements-foundations.md; metadata vẫn là IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND. Nếu example nêu nghĩa vụ pháp lý, kế toán, thuế, an toàn thực phẩm, dữ liệu cá nhân hoặc bảo mật, chỉ dùng nhãn Verification required hoặc project assumption cho đến khi owner có thẩm quyền xác minh.

Core

Tự rà soát liên tệp trước handoff kiểm tra cùng một sự thật quản trị xuất hiện nhất quán ở các artifact phụ thuộc. Mục tiêu không phải tự phê duyệt. Mục tiêu là chặn mâu thuẫn ID, đường dẫn, trạng thái, version, phạm vi nguồn và thẩm quyền trước khi section 12 được chuyển review.

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

flowchart TB
    A[Section 12 draft] --> B[Đối chiếu metadata: Status IN_REVIEW; Version v0.9.0; ngày 2026-08-07; locale vi-VN; múi giờ Asia/Ho_Chi_Minh]
    B --> C[Đối chiếu ID và đường dẫn canonical]
    C --> D[Đối chiếu source boundary: Nova Foods là case mô phỏng, chỉ dùng dữ liệu tổng hợp; nhãn Verification required]
    D --> E[Đối chiếu artifact: /00-research/00_SOURCE_MAP.md]
    E --> E2[Đối chiếu artifact: /01-curriculum/CHAPTER_MANIFEST.md]
    E2 --> E3[Đối chiếu artifact: /01-curriculum/TEMPLATE_MANIFEST.md]
    E3 --> E4[Đối chiếu artifact: /01-curriculum/TRACEABILITY_ID_REGISTRY.md]
    E4 --> E5[Đối chiếu artifact: /01-curriculum/CANONICAL_BUSINESS_RULES.md]
    E5 --> E6[Đối chiếu artifact: /01-curriculum/CANONICAL_DATA_DICTIONARY.md]
    E6 --> F{Có mâu thuẫn hoặc quyết định ngoài thẩm quyền?}
    F -- Không --> G[Đính kèm phiếu self-review]
    G --> H[Handoff sang review, giữ Status IN_REVIEW]
    F -- Có --> I[Ghi hoặc cập nhật open issue]
    I --> J[Giữ Status IN_REVIEW]
    J --> K[Escalate đúng owner được quy định trong artifact canonical]
    K --> L[Owner xử lý issue hoặc quyết định]
    L --> M[Đối chiếu lại metadata, ID, đường dẫn, source boundary và artifact canonical]
    M --> N{Mâu thuẫn đã được xử lý và quyết định đã được owner có thẩm quyền chốt?}
    N -- Có --> G
    N -- Không --> I

Kiểm tra bắt buộc: Status phải là IN_REVIEW; Version phải là v0.9.0; ngày phải là 2026-08-07; locale phải là vi-VN; múi giờ phải là Asia/Ho_Chi_Minh; Nova Foods là case mô phỏng, chỉ dùng dữ liệu tổng hợp. Bằng chứng là metadata cùng quy định trong /00-research/00_SOURCE_MAP.md, /01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/TEMPLATE_MANIFEST.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/CANONICAL_DATA_DICTIONARY.md.

Applied

Facts: Section 12 của /02-handbook/06-requirements-foundations.md chuẩn bị handoff review. Corpus chưa có baseline reference hay approval reference. Các artifact nguồn đều mang IN_REVIEW, v0.9.0, ngày 2026-08-07.

Current Behavior: Người soạn đối chiếu metadata, ID và source boundary; không suy diễn approval từ Owner, review hay tồn tại artifact.

Underlying Need: Handoff cần cho reviewer biết điểm nào đã khớp, điểm nào còn mở, ai có quyền kết luận. Nếu không tách ba nhóm này, một giả định học liệu có thể bị hiểu sai thành quy tắc ERP hoặc nghĩa vụ pháp lý.

Options: (1) Handoff không ghi issue; (2) ghi issue nhưng không chỉ owner; (3) ghi từng issue, bằng chứng, trạng thái và escalation owner.

Decision Criteria: Giữ traceability; không tạo approval ngầm định; không vượt thẩm quyền Principal IT Business Analyst / Technical Curriculum Author; bảo toàn ranh giới nguồn pháp lý, kế toán, bảo mật và kiến trúc.

Decision: Chọn phương án 3.

Authority: Principal IT Business Analyst / Technical Curriculum Author điều phối phiếu review và traceability. Legal Owner, Accounting Owner, Business Owner, Security Owner, Architect và QA Reviewer kết luận trong phạm vi chuyên môn của họ.

Artifact: Phiếu tự rà soát gắn với /02-handbook/06-requirements-foundations.md, tham chiếu artifact canonical, giữ IN_REVIEW, v0.9.0.

Consequence if Wrong: Sai owner escalation có thể biến nội dung mô phỏng thành kết luận pháp lý, kế toán, bảo mật hoặc vận hành; sai trạng thái có thể bị hiểu nhầm là baseline hay approval.

Kiểm tra liên tệp	Bằng chứng phải đối chiếu	Kết quả ghi trước handoff	Escalation owner nếu lỗi
Metadata quản trị	Sáu artifact nguồn nêu trên	IN_REVIEW, v0.9.0, 2026-08-07, vi-VN, Asia/Ho_Chi_Minh phải đồng nhất	Principal IT Business Analyst / Technical Curriculum Author
ID và đường dẫn	CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY	Không đổi ID canonical hoặc filename bằng tên tự đặt	Principal IT Business Analyst / Technical Curriculum Author
Business rule	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Không gọi rule mô phỏng là rule vận hành đã xác nhận	Business Owner
Data meaning	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Không suy diễn field, mã, retention hoặc cấu trúc triển khai	Architect
Pháp lý, thuế, kế toán	Nguồn chính thức trong /00-research/00_SOURCE_MAP.md	Giữ nhãn Verification required cho diễn giải chưa được nguồn hiện hành xác minh	Legal Owner; Accounting Owner
Bảo mật và privacy	OWASP, Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP trong source map	Không tuyên bố compliant hoặc production-ready	Security Owner; Legal Owner
Testability	ISTQB CTFL trong source map; requirement và acceptance criteria liên quan	Không tự xác nhận test coverage đầy đủ	QA Reviewer

Senior Lens

Open issue không phải lỗi bị che. Open issue là chênh lệch còn tồn tại, có bằng chứng và owner xử lý. Ghi issue theo mẫu: mã issue, mô tả trung tính, artifact bị ảnh hưởng, bằng chứng, rủi ro diễn giải, owner escalation, trạng thái. Không ghi “đã xử lý” khi chưa có bằng chứng cập nhật trong artifact kiểm soát.

Mã	Open issue hoặc Verification required	Bằng chứng	Owner escalation	Trạng thái trước handoff
OI-06RF-001	Chưa có baseline reference cho handbook và artifact phụ thuộc	Metadata IN_REVIEW trong các artifact nguồn	Principal IT Business Analyst / Technical Curriculum Author	Mở
OI-06RF-002	Chưa có approval reference; không được suy diễn user approval	CHAPTER_MANIFEST và TEMPLATE_MANIFEST nêu chưa có approval reference	Business Owner	Mở
VR-06RF-001	Mọi diễn giải về bảo vệ dữ liệu cá nhân cho Nova Foods cần xác minh legal-owner	Source map giới hạn nguồn pháp lý; case study là mô phỏng	Legal Owner	Verification required
VR-06RF-002	Mọi diễn giải kế toán, thuế, hóa đơn cần xác minh chuyên môn trước production use	Source map yêu cầu authorized accounting/legal role	Accounting Owner; Legal Owner	Verification required
VR-06RF-003	Mọi yêu cầu tích hợp, dữ liệu kỹ thuật hoặc kiến trúc ERP cần xác minh	CANONICAL_DATA_DICTIONARY là logical plan, không phải cấu hình triển khai	Architect	Verification required
VR-06RF-004	Mọi kết luận kiểm thử cần test basis và review QA	ISTQB CTFL là nguồn thuật ngữ; chưa có xác nhận coverage	QA Reviewer	Verification required

Quick Reference

Quy tắc handoff: đính kèm bảng self-review; giữ mọi OI-* và VR-* còn hiệu lực; nêu đúng escalation owner; giữ IN_REVIEW. Không đổi thành APPROVED, BASELINED, compliant hoặc production-ready.

Handoff bị chặn khi có ID không canonical, nguồn pháp lý bị diễn đạt thành nghĩa vụ chưa xác minh, hoặc một issue đồng thời cần nhiều thẩm quyền nhưng chưa escalate đến đủ owner. Principal IT Business Analyst / Technical Curriculum Author chỉ điều phối gói issue và traceability; không thay kết luận Legal Owner, Accounting Owner, Business Owner, Security Owner, Architect hoặc QA Reviewer.