07 User Stories And Acceptance Criteria

Trường kiểm soát	Giá trị
Artifact ID	07_USER_STORIES_AND_ACCEPTANCE_CRITERIA
Tên tệp được kiểm soát	/02-handbook/07-user-stories-and-acceptance-criteria.md
Status	IN_REVIEW
Version	v0.9.0
Last updated date	2026-08-07
Timezone	Asia/Ho_Chi_Minh
Locale	vi-VN; 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ữ liệu tổng hợp
Source classification	Học liệu BA; tham chiếu thuật ngữ và thực hành từ BABOK Guide Version 3, ISO/IEC/IEEE 29148:2018 và ISTQB CTFL Syllabus v4.0.1 trong ranh giới nguồn đã xác minh
Baseline reference	Chưa có baseline reference tại v0.9.0
Approval reference	Chưa có approval reference tại v0.9.0
Authority boundary	Artifact không xác nhận requirement vận hành, cấu hình ERP, tuân thủ pháp lý, quyết định kế toán, bảo mật hoặc production use của Nova Foods

1. Concept l? g??

Core - Definitions

User story, tiếng Việt là câu chuyện người dùng, là cách ghi ngắn một nhu cầu theo góc nhìn người nhận giá trị. Nó trả lời ba ý nền: ai cần làm việc gì, trên đối tượng nào, và giá trị nghiệp vụ nào cần nhận. Câu chuyện không phải màn hình, không phải thiết kế kỹ thuật, không phải lời hứa rằng hệ thống đã làm được việc đó. Nó là đơn vị trao đổi để Business Analyst, nghiệp vụ, phát triển và kiểm thử cùng hiểu mục tiêu trước khi chọn cách xây.

Acceptance criteria, tiếng Việt là tiêu chí chấp nhận, là các điều kiện có thể kiểm tra để xác định user story đã đáp ứng đúng nhu cầu hay chưa. User story nói “cần giá trị gì”; acceptance criteria nói “dấu hiệu nào chứng minh giá trị đó đã đạt”. Cặp này cần đi cùng nhau vì câu chuyện ngắn giúp giữ trọng tâm nghiệp vụ, còn tiêu chí cụ thể chặn suy diễn khác nhau giữa người viết, người xây và người kiểm thử.

Từ nguyên lý đầu tiên: một nhu cầu chỉ hữu ích cho delivery khi người thực hiện biết kết quả nào được coi là đúng. Nếu chỉ có câu “quản lý tồn kho”, phạm vi còn mơ hồ: không rõ ai xem, xem hàng nào, tại thời điểm nào, hay điều gì xảy ra khi dữ liệu không có. Nếu chỉ có danh sách điều kiện kỹ thuật mà không có nhu cầu, đội ngũ có thể xây đúng điều kiện nhưng sai giá trị nghiệp vụ. User story giữ lý do; acceptance criteria giữ ranh giới kiểm chứng.

Trong Nova Foods mô phỏng, một nhu cầu có thể là: nhân viên kho cần xem số lượng tồn của một mặt hàng để chuẩn bị xuất hàng. Đây mới là câu chuyện ở mức khái niệm, chưa phải yêu cầu hoàn chỉnh và chưa xác định bảng dữ liệu, API, quyền truy cập, quy tắc giữ hàng, hay cách tính tồn. Các chi tiết đó chỉ được đưa vào khi có bằng chứng từ nguồn canonical phù hợp và vai trò có thẩm quyền xác nhận.

Ranh giới chương này: giải thích cách biểu đạt nhu cầu bằng user story và cách biến nhu cầu đó thành điều kiện chấp nhận có thể kiểm tra. Chương này không tự tạo business rule Nova Foods, không thay thế đặc tả yêu cầu, không thiết kế UI, database, API, BPMN, kiến trúc, test case, hoặc quyết định pháp lý và kế toán. IN_REVIEW chỉ cho biết artifact đang được xem xét có kiểm soát; không phải baseline, approval, hay xác nhận dùng cho production.

Core - Structure And Terms

User story là mô tả ngắn về nhu cầu của một người hoặc vai trò sử dụng hệ thống. Mục đích không phải viết đặc tả kỹ thuật, mà làm rõ giá trị cần đạt để BA, nghiệp vụ, kỹ thuật và kiểm thử cùng hiểu một nhu cầu. Cấu trúc thường dùng: “Với vai trò [actor], tôi muốn [action] trên [object], để [outcome].”

Thuật ngữ	Nghĩa tiếng Việt	Vai trò trong user story	Câu hỏi BA cần làm rõ
User story	Câu chuyện người dùng	Đơn vị mô tả nhu cầu theo góc nhìn người dùng	Ai cần gì, trên đối tượng nào, để tạo giá trị gì?
Actor	Tác nhân; người hoặc hệ thống thực hiện hành vi	Xác định góc nhìn và quyền/ngữ cảnh dùng hệ thống	Actor là vai trò nghiệp vụ, người dùng cụ thể hay hệ thống tích hợp?
Action	Hành động mong muốn	Mô tả việc actor cần làm	Hành động là tạo, xem, sửa, duyệt, hủy, gửi hay tính toán?
Object	Đối tượng tác động	Xác định dữ liệu, chứng từ hoặc thực thể bị xử lý	Actor thao tác trên đơn hàng, phiếu nhập, lô hàng hay báo cáo nào?
Outcome	Kết quả hoặc giá trị mong muốn	Giải thích vì sao hành động cần tồn tại	Kết quả giảm sai sót, ra quyết định, theo dõi trạng thái hay phục vụ khách hàng?
Acceptance criteria	Tiêu chí chấp nhận	Điều kiện kiểm tra được để xác định story hoạt động đúng	Khi nào có thể kết luận nhu cầu đã được đáp ứng?
BA	Business Analyst, Chuyên viên Phân tích Nghiệp vụ	Làm rõ nhu cầu, phạm vi, quy tắc và khả năng kiểm thử	Story có đủ nghĩa nghiệp vụ nhưng chưa tự suy diễn thiết kế chưa?
ERP	Enterprise Resource Planning, hệ thống hoạch định nguồn lực doanh nghiệp	Bối cảnh hệ thống tích hợp nghiệp vụ	Story ảnh hưởng phân hệ, dữ liệu hoặc vai trò ERP nào?

Ví dụ mô phỏng Nova Foods Trading & Manufacturing, chỉ dùng dữ liệu tổng hợp:

Với vai trò Nhân viên kho, tôi muốn ghi nhận số lượng thực nhận trên phiếu nhập kho, để tồn kho sẵn có phản ánh hàng đã nhận.

Trong ví dụ này, Nhân viên kho là actor vì vai trò này thực hiện nghiệp vụ nhận hàng. Ghi nhận số lượng thực nhận là action vì đây là thao tác cần hệ thống hỗ trợ. Phiếu nhập kho là object vì dữ liệu bị cập nhật thuộc chứng từ này. Tồn kho sẵn có phản ánh hàng đã nhận là outcome vì nêu giá trị nghiệp vụ, không chỉ nêu thao tác màn hình.

Quy tắc đọc: actor trả lời “ai hoặc hệ thống nào”; action trả lời “muốn làm gì”; object trả lời “làm trên cái gì”; outcome trả lời “để đạt giá trị nào”. Nếu thiếu outcome, câu có thể chỉ là yêu cầu giao diện. Nếu thiếu actor, không xác định được ngữ cảnh quyền hạn và trách nhiệm. Nếu thiếu object, phạm vi dữ liệu không rõ. Nếu action quá rộng như “quản lý kho”, BA chưa thể tách nhu cầu thành phần có thể phân tích và kiểm thử.

Applied - Nova Foods Scenario

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.

Mục	Nội dung
Facts	Nhân viên bán hàng nhập đơn bán cho khách hàng mô phỏng KH-001. Đơn có mã hàng SP-NUOC-01, số lượng 120, giá trị tạm tính 2.400.000 VND.
Current Behavior	Nhân viên ghi đơn qua bảng tính. Kho không thấy ngay nhu cầu xuất hàng; dễ nhập sai số lượng hoặc bỏ sót đơn.
Underlying Need	Bộ phận bán hàng cần ghi nhận yêu cầu bán; kho cần biết đơn nào chờ kiểm tra tồn. Nhu cầu này tồn tại vì cùng một đơn phải được nhiều vai trò nhìn theo cùng dữ liệu.
Options	Ghi bảng tính; gửi email cho kho; tạo user story cho ERP mô phỏng.
Decision Criteria	Cách chọn phải nêu rõ người dùng, kết quả mong muốn, đối tượng dữ liệu và giới hạn trách nhiệm; không tự biến giả định thành quy tắc vận hành.
Decision	Dùng user story: “Là nhân viên bán hàng, tôi muốn tạo đơn bán hàng cho khách hàng và mặt hàng đã chọn, để kho có thể kiểm tra khả năng đáp ứng đơn.”
Authority	Nội dung là ví dụ học liệu IN_REVIEW, v0.9.0, ngày 2026-08-07; không phải quyết định vận hành Nova Foods thực tế, không có approval hay baseline.
Artifact	User story là mẩu yêu cầu ngắn. Nó ghi nhu cầu và giá trị mong muốn, chưa là màn hình ERP, thiết kế DB, API, quy tắc cấp tín dụng hay lệnh xuất kho.
Consequence if Wrong	Nếu viết “Hệ thống tạo đơn” mà không nêu người dùng và kết quả, đội phát triển có thể xây chức năng kỹ thuật nhưng không giải quyết việc kho cần kiểm tra đơn. Nếu thêm điều kiện tồn kho chưa được xác nhận, ví dụ biến thành quy tắc nghiệp vụ giả.

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

flowchart TB
    A[Nhân viên bán hàng] -->|cần tạo| B[Đơn bán cho khách hàng và mặt hàng đã chọn]
    B -->|để đạt kết quả mong muốn| C[Kho biết đơn nào cần kiểm tra khả năng đáp ứng]

Ranh giới khái niệm: user story mô tả ai cần làm gì với đối tượng nào để đạt kết quả gì. Nó kết nối nhu cầu nghiệp vụ với trao đổi tiếp theo về chi tiết, nhưng không thay thế chi tiết đó.

Loại trừ rõ: không suy ra tồn kho đủ để giao; không tự tạo giá, thuế, hóa đơn, bút toán, quyền truy cập, tích hợp API, tiêu chí chấp nhận, hoặc trạng thái đơn. Các nội dung này cần artifact và thẩm quyền riêng. Bất kỳ yêu cầu nào liên quan thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc phải được gắn Verification required với owner phù hợp; ví dụ này không xác nhận nghĩa vụ pháp lý hay tuân thủ.

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

Core

User story và acceptance criteria tồn tại để chặn yêu cầu bị hiểu khác nhau giữa nghiệp vụ, BA, phát triển và kiểm thử. User story ghi người dùng, việc cần làm và giá trị mong muốn. Acceptance criteria, tức tiêu chí chấp nhận, ghi điều kiện có thể kiểm tra để biết chức năng đã đáp ứng nhu cầu hay chưa.

Không có hai lớp này, câu như “cần quản lý đơn bán hàng” dễ bị biến thành nhiều cách xây khác nhau: đội phát triển hiểu là màn hình tạo đơn; kho hiểu là danh sách đơn cần xử lý; kiểm thử hiểu là lưu được dữ liệu; người dùng mong kiểm tra được đơn trước khi kho xử lý. Mỗi cách hiểu có thể hợp lý riêng, nhưng không cùng một phạm vi. Hệ quả là lỗi phát hiện muộn, làm lại thiết kế, sửa mã, viết lại kiểm thử, hoặc tranh cãi ai chịu trách nhiệm quyết định.

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

flowchart TB
    A[Nhu cầu nghiệp vụ chưa rõ] --> B[Nghiệp vụ, BA, phát triển, kiểm thử và người dùng hiểu khác nhau]
    B --> C[Phát triển sai phạm vi]
    B --> D[Kiểm thử không có chuẩn kiểm tra]
    C --> E[Lỗi phát hiện muộn]
    D --> E
    E --> I[Làm lại: sửa thiết kế, mã và kiểm thử; tranh chấp trách nhiệm]

    A --> F[User story làm rõ người dùng, việc cần làm và giá trị]
    F --> G[Acceptance criteria xác định điều kiện kiểm tra]
    G --> H[Cùng hiểu phạm vi và điều kiện kiểm tra]

Applied

Trong Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, một yêu cầu ngắn “cần tạo đơn bán hàng” không xác định ai thực hiện, đối tượng nào được chọn, kết quả nào có ích, hay điều kiện nào chứng minh chức năng hoạt động. Nếu BA chuyển ngay câu này thành màn hình hoặc ticket kỹ thuật, phạm vi kỹ thuật sẽ thay thế nhu cầu nghiệp vụ. Đây là rủi ro quản trị: quyết định ngầm xuất hiện trong mã nguồn mà không có artifact cho người có thẩm quyền xem xét.

User story buộc nhóm nêu rõ mục tiêu trước: nhân viên bán hàng cần tạo đơn để kho có thể nhận biết đơn cần xử lý. Acceptance criteria buộc nhóm chuyển mục tiêu đó thành điều kiện quan sát được, ví dụ dữ liệu đơn phải được ghi nhận và kho phải thấy đơn theo luồng đã thống nhất. Tiêu chí không tự tạo quy tắc tồn kho, giá, thuế, hóa đơn, tín dụng hay xuất kho. Những nội dung đó cần nguồn, quyết định và thẩm quyền riêng.

Senior Lens

Giá trị lớn nhất không phải mẫu câu “Là…, tôi muốn…, để…”. Giá trị là tạo ranh giới kiểm soát giữa nhu cầu, phạm vi xây dựng và bằng chứng kiểm thử. User story giảm rủi ro xây nhầm vấn đề. Acceptance criteria giảm rủi ro tuyên bố “xong” khi chưa có điều kiện kiểm tra chung.

BA không dùng acceptance criteria để lấp khoảng trống bằng suy đoán. Khi điều kiện ảnh hưởng tài chính, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc, bảo mật hoặc quyền hạn, điều kiện đó phải chờ xác minh từ owner phù hợp. IN_REVIEW tại v0.9.0, ngày 2026-08-07, không phải baseline, approval hay quyền đưa vào production.

Quick Reference

Rủi ro cần chặn	User story hỗ trợ	Acceptance criteria hỗ trợ
Phát triển sai vấn đề	Nêu người dùng, nhu cầu, giá trị	Không đủ nếu chưa có story rõ
Phạm vi trôi dạt	Giữ trọng tâm vào kết quả nghiệp vụ	Giới hạn điều kiện cần đạt
Kiểm thử cảm tính	Cung cấp ngữ cảnh cần kiểm tra	Tạo điều kiện pass/fail quan sát được
Quyết định ngầm trong mã	Lộ nhu cầu để thảo luận	Buộc điều kiện cần quyết định thành artifact
Làm lại muộn	Phát hiện lệch hiểu trước xây dựng	Phát hiện thiếu điều kiện trước kiểm thử

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp. User story (câu chuyện người dùng) và acceptance criteria (tiêu chí chấp nhận) tồn tại để biến nhu cầu ngắn thành hành vi kiểm tra được. Không có hai artifact này, cùng một câu “hệ thống phải chặn xuất kho thiếu tồn” có thể bị Kho hiểu là chặn lúc tạo phiếu, Kế toán hiểu là chặn lúc hạch toán, còn đội phát triển hiểu là chỉ hiện cảnh báo.

Thành phần	Trước: chưa có user story và acceptance criteria rõ	Sau: có user story và acceptance criteria rõ
Facts	Phiếu xuất kho mô phỏng WH-OUT-00017 có yêu cầu xuất 120 thùng SKU NF-MILK-01; tồn khả dụng hiển thị 100 thùng.	Vẫn dùng WH-OUT-00017, SKU NF-MILK-01, yêu cầu 120 thùng, tồn khả dụng 100 thùng. Cùng dữ liệu giúp so sánh hành vi, không đổi bài toán.
Current Behavior	Màn hình cho lưu phiếu; người dùng thấy thông báo “kiểm tra tồn kho”. Trạng thái phiếu sau lưu không được nêu.	Hệ thống từ chối xác nhận xuất; phiếu giữ trạng thái nháp; thông báo nêu SKU, số lượng yêu cầu và tồn khả dụng.
Underlying Need	Nhóm chỉ biết có “cảnh báo thiếu tồn”. Không biết cảnh báo có được phép bỏ qua, thời điểm kiểm tra, hay dữ liệu nào làm căn cứ.	Kho cần ngăn xác nhận xuất vượt tồn khả dụng, nhưng vẫn giữ phiếu để điều chỉnh số lượng hoặc chờ bổ sung tồn.
Options	Không có tiêu chí để so sánh. Đội phát triển tự chọn cảnh báo hoặc chặn.	(1) Chỉ cảnh báo và vẫn xác nhận. (2) Chặn xác nhận, giữ nháp. (3) Tự tạo tồn âm.
Decision Criteria	Không có căn cứ chung để kiểm tra bản build hay giải quyết bất đồng.	Hành vi phải kiểm tra được bằng dữ liệu đầu vào; không tự làm thay đổi tồn; người dùng còn đường sửa phiếu; thông báo phải chỉ ra nguyên nhân.
Decision	Không có quyết định ghi trong artifact. Hành vi thực tế phụ thuộc cách hiểu từng người.	Chọn phương án (2) cho ví dụ học liệu: chặn hành động Xác nhận xuất khi số lượng yêu cầu lớn hơn tồn khả dụng; không chặn lưu nháp.
Authority	Không xác định người có quyền chọn giữa cảnh báo, chặn hay tồn âm.	Quyết định mô phỏng cần Business Owner xác nhận khi chuyển thành yêu cầu dự án; BA ghi traceability, không tự cấp thẩm quyền.
Artifact	Chỉ có yêu cầu ngắn: “Chặn xuất kho thiếu tồn.”	User story và acceptance criteria trong /02-handbook/07-user-stories-and-acceptance-criteria.md; trạng thái corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Dev có thể cho xác nhận phiếu vượt tồn; QA chỉ kiểm tra thông báo xuất hiện; Kho phát hiện sai khác sau thao tác.	Nếu tiêu chí chấp nhận ghi sai thời điểm chặn, build có thể chặn cả lưu nháp, làm người dùng mất khả năng lưu công việc dang dở.

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

flowchart TB
    A[Người dùng nhập phiếu WH-OUT-00017] --> B[Chọn Xác nhận xuất]
    B --> C{Số lượng yêu cầu <= tồn khả dụng?}
    C -->|Có| D[Cho phép tiếp tục xác nhận nếu không có điều kiện chặn khác]
    C -->|Không| E[Từ chối Xác nhận xuất]
    E --> F[Giữ phiếu ở trạng thái nháp]
    F --> G[Không tự trừ tồn kho]
    G --> H[Hiện SKU, số lượng yêu cầu, tồn khả dụng]
    H --> I[Người dùng sửa số lượng hoặc chờ bổ sung tồn]

User story mô phỏng

Là nhân viên Kho, tôi muốn hệ thống kiểm tra tồn khả dụng khi xác nhận phiếu xuất để không xác nhận số lượng vượt tồn.

Acceptance criteria mô phỏng

1. Với WH-OUT-00017, khi NF-MILK-01 yêu cầu 120 thùng và tồn khả dụng là 100 thùng, thao tác Xác nhận xuất bị từ chối.
2. Sau khi bị từ chối, phiếu vẫn ở trạng thái nháp và không tự trừ tồn.
3. Thông báo phải chứa NF-MILK-01, 120 và 100.
4. Khi người dùng sửa số lượng xuống 100 thùng hoặc thấp hơn, hệ thống cho phép tiếp tục xác nhận, nếu không có điều kiện chặn khác.

Khác biệt quan sát được là trước đó mọi bên chỉ kiểm tra “có thông báo”; sau đó Dev, QA và Kho kiểm tra cùng bốn kết quả: điểm kiểm tra, hành động bị chặn, trạng thái phiếu và dữ liệu thông báo. Rework giảm không phải vì BA viết dài hơn, mà vì phạm vi hành vi sai đã bị loại khỏi cách hiểu hợp lệ.

Core

User story là mô tả ngắn nhu cầu của người dùng; acceptance criteria là điều kiện kiểm tra được để xác nhận story đáp ứng nhu cầu. Hai thứ chỉ đáng tin khi từng câu được gắn đúng loại bằng chứng. Không phân loại, nhóm dễ biến ý kiến thành quy tắc ERP, biến giả định thành cam kết, hoặc gọi nội dung IN_REVIEW là đã phê duyệt.

Loại	Nghĩa	Bằng chứng tối thiểu	Cách viết trong artifact
Fact đã xác minh	Thông tin được chứng minh bởi nguồn kiểm soát hoặc quan sát có thể truy lại	URL chính thức, artifact canonical, log quan sát, bản ghi hệ thống mô phỏng	Nêu nguồn, ngày truy cập hoặc vị trí artifact
Stakeholder input	Nhu cầu, cách làm, vấn đề do vai trò liên quan cung cấp	Vai trò, thời điểm, phạm vi phát biểu; chưa tự chứng minh là đúng	Gắn nhãn “Stakeholder input”; không đổi thành rule
Project assumption	Điều tạm coi là đúng để phân tích tiếp	Lý do cần giả định, rủi ro nếu sai, người cần xác minh	Gắn nhãn “Project assumption” và điều kiện đóng
Decision	Lựa chọn đã được ghi nhận theo tiêu chí và thẩm quyền phù hợp	Các lựa chọn, tiêu chí, authority, artifact quyết định	Không gọi là approval nếu chưa có approval reference
Verification-required claim	Mệnh đề có thể ảnh hưởng pháp lý, kế toán, bảo mật, vận hành hoặc cấu hình nhưng chưa đủ bằng chứng	Câu hỏi xác minh, nguồn/owner cần kiểm tra	Gắn nhãn “Verification required”; không tạo acceptance criterion bắt buộc từ mệnh đề này

IN_REVIEW, v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh và phạm vi Nova Foods mô phỏng là fact đã xác minh từ metadata corpus. Chúng không xác nhận business rule, cấu hình ERP, baseline hay approval.

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

flowchart TB
    A[Thông tin đầu vào] --> B{Là Decision đã ghi nhận<br/>có lựa chọn, tiêu chí,<br/>authority và artifact?}
    B -->|Có| C[Decision được ghi nhận]
    C --> D{Approval reference hợp lệ,<br/>đúng phạm vi và xác nhận approval?}
    D -->|Có| E[Được gọi là approval]
    D -->|Không| F[Không gọi là approval]
    E --> G[Soạn story hoặc acceptance criteria]
    F --> G

    B -->|Không| H{Có nguồn kiểm soát<br/>hoặc quan sát truy lại?}
    H -->|Có| I{Nguồn chứng minh<br/>đúng phạm vi nội dung?}
    I -->|Có| J[Fact đã xác minh]
    J --> G
    I -->|Không| K[Giữ nhãn chưa xác minh;<br/>cần xác minh thêm]

    H -->|Không| L{Là phát biểu từ stakeholder?}
    L -->|Có| M[Stakeholder input]
    M --> N[Ghi vai trò, thời điểm<br/>và phạm vi phát biểu]
    N --> O[Làm rõ; không đổi input thành rule]
    O --> P{Đã đủ rõ?}
    P -->|Có| Q[Dùng làm nhu cầu đầu vào cho story;<br/>không tự thành rule hoặc acceptance criterion bắt buộc]
    P -->|Không| R[Giữ nhãn Stakeholder input;<br/>chưa làm rõ]

    L -->|Không| S{Cần tạm dùng<br/>để phân tích?}
    S -->|Có| T[Project assumption]
    T --> U[Ghi lý do cần giả định,<br/>rủi ro nếu sai và người cần xác minh]
    U --> V[Xác minh điều kiện đóng]
    V --> W{Kết quả xác minh?}
    W -->|Có nguồn đúng phạm vi| J
    W -->|Có lựa chọn, tiêu chí,<br/>authority và artifact| C
    W -->|Bị bác bỏ| X[Loại bỏ giả định]
    W -->|Chưa đủ| Y[Giữ nhãn Project assumption;<br/>chưa đóng]

    S -->|Không| Z{Có thể ảnh hưởng pháp lý,<br/>kế toán, bảo mật, vận hành<br/>hoặc cấu hình?}
    Z -->|Có| AA[Verification-required claim]
    AA --> AB[Ghi câu hỏi xác minh<br/>và nguồn hoặc owner cần kiểm tra]
    AB --> AC[Kiểm tra qua nguồn hoặc owner]
    AC --> AD{Đủ bằng chứng<br/>đúng phạm vi?}
    AD -->|Có| J
    AD -->|Không| AE[Giữ nhãn Verification-required claim;<br/>chưa đủ bằng chứng]

    Z -->|Không| AF[Phân loại khác hoặc loại khỏi artifact;<br/>không tạo acceptance criterion bắt buộc<br/>khi chưa có căn cứ]

Applied

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.

Trường	Nội dung
Facts	/01-curriculum/CHAPTER_MANIFEST.md và /01-curriculum/CANONICAL_BUSINESS_RULES.md đều có trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; metadata nêu chưa có baseline reference và approval reference. Đây là fact vì artifact kiểm soát ghi rõ.
Current Behavior	Trong bản nháp story, câu “ERP phải chặn xuất kho khi lô hàng chưa đủ điều kiện truy xuất” xuất hiện như acceptance criterion, nhưng không kèm rule canonical, nguồn pháp lý đã diễn giải, hay quyết định Business Owner.
Underlying Need	Nhân viên kho cần biết lô nào được phép chọn khi tạo phiếu xuất. Nhu cầu này là stakeholder input của case mô phỏng, chưa chứng minh điều kiện chặn cụ thể.
Options	(1) Viết điều kiện chặn như rule bắt buộc; (2) viết story chỉ nêu nhu cầu hiển thị trạng thái truy xuất; (3) giữ điều kiện chặn là Verification required đến khi domain owner và legal owner xác minh.
Decision Criteria	Có nguồn canonical? Có thẩm quyền nghiệp vụ và pháp lý phù hợp? Điều kiện có thể kiểm thử không? Việc sai có thể gây xuất hàng không đúng hoặc tạo ràng buộc ERP không có căn cứ không?
Decision	Chọn (3). Story có thể tiếp tục mô tả nhu cầu nhận biết trạng thái; acceptance criterion không được khẳng định logic chặn.
Authority	Business Owner xác nhận quy trình; Food Safety/Legal Owner xác minh nghĩa vụ và cách diễn giải; Architect xác nhận khả năng thực thi; QA xác nhận test basis. Không vai trò nào được suy ra là đã phê duyệt.
Artifact	Ghi phân loại trong /02-handbook/07-user-stories-and-acceptance-criteria.md; nếu thành business rule, liên kết đúng CANONICAL_BUSINESS_RULES sau khi artifact đó có nội dung và xác minh phù hợp.
Consequence if Wrong	Nếu gọi stakeholder input là fact, team có thể build chặn xuất kho sai. Nếu gọi giả định là decision, QA có thể test theo rule không tồn tại. Nếu bỏ nhãn verification, rủi ro pháp lý và vận hành bị che khuất.

Cách viết an toàn:

Verification required: Điều kiện ERP chặn xuất kho theo trạng thái truy xuất của lô cần Food Safety/Legal Owner xác minh trước khi trở thành business rule hoặc acceptance criterion bắt buộc.

Cách viết không an toàn: “Luật yêu cầu ERP phải chặn xuất kho.” Câu này vừa diễn giải pháp lý, vừa áp đặt thiết kế hệ thống, nhưng không nêu nguồn đã kiểm tra, owner có thẩm quyền hoặc quyết định.

Senior Lens

Fact trả lời “điều gì đã được chứng minh”. Stakeholder input trả lời “ai cần gì hoặc đang làm gì”. Assumption trả lời “nhóm đang tạm dựa vào điều gì”. Decision trả lời “đã chọn gì, theo tiêu chí nào, ai có thẩm quyền ghi nhận”. Verification-required claim trả lời “mệnh đề nào chưa được phép dùng làm sự thật”.

Không dùng số đông để nâng stakeholder input thành fact. Không dùng chức danh Owner để suy ra decision. Không dùng một URL pháp lý để suy ra cách cấu hình ERP; cầu nối còn thiếu là diễn giải của owner phù hợp và quyết định được ghi nhận. Với dữ liệu thuế, kế toán, lao động, dữ liệu cá nhân, an toàn thực phẩm và truy xuất, giữ nhãn Project assumption hoặc Verification required nếu chưa đối chiếu văn bản chính thức hiện hành và chưa có xác minh owner.

Quick Reference

Nếu câu nói là	Nhãn đúng
“Metadata artifact ghi chưa có approval reference.”	Fact đã xác minh
“Kho muốn thấy trạng thái lô trước khi xuất.”	Stakeholder input
“Tạm giả sử mỗi lô có một trạng thái truy xuất.”	Project assumption
“Chọn hiển thị trạng thái, chưa chặn xuất kho.”	Decision, chỉ khi có authority và artifact ghi nhận
“ERP phải chặn xuất kho để tuân thủ quy định.”	Verification required

3. V? tr? trong Lifecycle

Core

User story là câu mô tả nhu cầu theo góc nhìn người dùng; acceptance criteria là điều kiện có thể kiểm tra để xác định nhu cầu đó đã được đáp ứng. Hai thành phần này không xuất hiện độc lập ở lúc lập trình. Chúng đi qua chuỗi Discovery, Analysis, Delivery, Testing, Release và Operations để giữ liên kết giữa vấn đề ban đầu, hành vi hệ thống được xây và bằng chứng kiểm tra.

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

flowchart TB
    D[Discovery<br/>Nêu vấn đề, outcome, giả định]
    A[Analysis<br/>Làm rõ phạm vi, rule, dữ liệu, user story, AC]
    V{Có điểm pháp lý, kế toán,<br/>an toàn thực phẩm hoặc dữ liệu cá nhân<br/>chưa được owner phù hợp xác nhận?}
    Q[Giữ nhãn<br/>Verification required]
    DE[Delivery<br/>Thiết kế, cấu hình hoặc phát triển]
    T[Testing<br/>Kiểm tra theo acceptance criteria]
    F{Phát hiện vấn đề cần quay lại?}
    X{Mọi AC đã có<br/>kết quả ghi nhận?}
    E[Chưa đủ bằng chứng<br/>Kiểm tra và ghi nhận lại]
    Z{Còn ngoại lệ mở?}
    EO[Ngoại lệ còn mở<br/>Được ghi nhận và nhìn thấy]
    R[Release<br/>Đánh giá bằng chứng và ngoại lệ]
    RD{Quyết định phát hành}
    U[IN_REVIEW<br/>Chưa có quyết định,<br/>không phải approval hay baseline]
    O[Operations<br/>Theo dõi sử dụng, sự cố, phản hồi]
    C{Phân loại phản hồi}
    I[Sự cố<br/>Tiếp tục xử lý và theo dõi vận hành]
    P[Cải tiến<br/>Tạo nhu cầu mới]

    D -->|Vấn đề và outcome đã diễn đạt; điểm chưa biết được gắn nhãn| A
    A -->|Story phù hợp fact đã xác minh; AC có điều kiện, hành động, kết quả| V
    V -->|Có| Q
    V -->|Không| DE
    Q -->|Giữ nhãn đến khi owner phù hợp xác nhận| DE
    DE -->|Thay đổi đối chiếu được với story và AC; có thể kiểm tra| T
    T --> F

    F -->|Lỗi triển khai| DE
    F -->|AC thiếu hoặc mơ hồ| A
    F -->|Không| X

    X -->|Không| E
    E --> T
    X -->|Có| Z

    Z -->|Có| EO
    EO -->|Đưa vào đánh giá phát hành| R
    Z -->|Không| R

    R --> RD
    RD -->|Được phát hành; trạng thái và phạm vi được ghi nhận| O
    RD -->|Tạm dừng vì thiếu bằng chứng| T
    RD -->|Từ chối vì yêu cầu hoặc AC cần sửa| A
    RD -->|Chưa có quyết định; giữ IN_REVIEW| U
    U -->|Khi có quyết định theo kiểm soát dự án| RD

    O -->|Phản hồi được ghi nhận| C
    C -->|Sự cố| I
    I -->|Tiếp tục theo dõi và ghi nhận outcome| O
    C -->|Cải tiến| P
    C -->|Nhu cầu mới| D
    P --> D

Entry gate là điều kiện tối thiểu để một pha được phép bắt đầu; exit gate là bằng chứng tối thiểu để pha đó được phép bàn giao. Gate không phải lời hứa rằng giải pháp đã đúng tuyệt đối. Gate ngăn nhóm chuyển tiếp khi chưa có đầu vào đủ để giảm suy đoán. Ví dụ, không thể kiểm tra “hệ thống hiển thị trạng thái lô” nếu acceptance criteria chưa nêu trạng thái nào, ở màn hình nào, cho vai trò nào và điều kiện quan sát nào.

Pha	User story và acceptance criteria làm gì	Entry gate chính xác	Exit gate chính xác
Discovery	Ghi nhận vấn đề, người chịu ảnh hưởng, outcome mong muốn và giả định. Chưa viết chi tiết hành vi hệ thống.	Có tín hiệu nhu cầu hoặc vấn đề vận hành được ghi nhận.	Vấn đề và outcome được diễn đạt; điểm chưa biết được gắn Project assumption hoặc Verification required.
Analysis	Chuyển nhu cầu thành user story; tách acceptance criteria thành điều kiện quan sát và kiểm tra được.	Có vấn đề từ Discovery; phạm vi ban đầu đủ để thảo luận.	Story không mâu thuẫn với fact đã xác minh; AC có điều kiện, hành động và kết quả; điểm thuộc pháp lý, kế toán, an toàn thực phẩm hoặc dữ liệu cá nhân vẫn giữ nhãn xác minh khi chưa có owner phù hợp xác nhận.
Delivery	Dùng story và AC làm giới hạn cho thiết kế, cấu hình hoặc mã nguồn.	Story và AC đạt exit gate Analysis.	Thay đổi có thể đối chiếu về story và AC; không tự thêm rule ngoài phạm vi đã ghi nhận.
Testing	Dùng AC làm test basis, tức cơ sở để thiết kế và đánh giá kiểm thử.	Bản build hoặc cấu hình có thể kiểm tra; AC vẫn đọc được và không mơ hồ.	Mỗi AC có kết quả kiểm tra được ghi nhận; lỗi hoặc thiếu AC quay về Analysis, không tự sửa nghĩa của yêu cầu trong test.
Release	Dùng kết quả kiểm tra để đánh giá thay đổi có đủ bằng chứng phát hành theo quy trình dự án hay không.	Kết quả Testing được ghi nhận; các ngoại lệ còn mở nhìn thấy được.	Trạng thái phát hành và phạm vi thay đổi được ghi nhận theo kiểm soát dự án. IN_REVIEW không phải approval hay baseline.
Operations	So sánh hành vi đang dùng với outcome và AC đã phát hành; ghi nhận sự cố hoặc nhu cầu mới.	Thay đổi đã được phát hành theo quy trình dự án mô phỏng.	Phản hồi được phân loại thành sự cố, cải tiến hoặc nhu cầu mới; nhu cầu mới quay lại Discovery thay vì sửa ngầm story cũ.

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. Corpus đang ở IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Metadata dependency nêu chưa có baseline reference và chưa có approval reference. Vì vậy, không thể gọi một user story là đã phê duyệt hoặc đã baseline.

Current Behavior: Nhóm mô phỏng nhận câu nói: “Kho cần thấy trạng thái truy xuất của lô trước khi xuất.” Câu này mới nêu nhu cầu người dùng. Nó chưa xác định trạng thái hợp lệ, nguồn dữ liệu, hành vi khi trạng thái bất thường, hoặc tiêu chí kiểm tra.

Underlying Need: Biến nhu cầu kho thành chuỗi bằng chứng có thể đi từ Discovery đến Operations mà không biến ý kiến thành business rule hay nghĩa vụ pháp lý. Cầu nối cần thiết là story, AC và nhãn xác minh cho phần chưa được chứng minh.

Options:
1. Đưa câu nói thẳng vào Delivery. Nhanh nhưng Delivery phải tự đoán hành vi.
2. Viết user story nhưng không có AC. Có mục tiêu nhưng Testing không có điều kiện đánh giá rõ.
3. Giữ câu nói ở Discovery, làm rõ tại Analysis, rồi chỉ chuyển Delivery khi AC kiểm tra được.

Decision Criteria: Chọn cách giảm suy đoán; giữ traceability; cho phép Testing kiểm tra độc lập; không diễn giải quy định an toàn thực phẩm thành chặn ERP khi chưa có xác minh phù hợp.

Decision: Chọn Option 3. Đây là quyết định phương pháp học liệu cho case mô phỏng, không phải quyết định vận hành Nova Foods.

Authority: Việc xác nhận một rule về truy xuất hoặc chặn xuất kho thuộc phạm vi xác minh của Food Safety/Legal Owner phù hợp; nội dung hiện tại không ghi nhận xác nhận đó. BA chỉ bảo toàn câu hỏi, nhãn Verification required và liên kết artifact.

Artifact: Trong Analysis, story có thể được ghi theo dạng: “Là nhân viên kho, tôi muốn xem trạng thái truy xuất của lô trên giao dịch xuất kho để nhận biết lô cần được xử lý thêm trước khi hoàn tất thao tác.” AC chỉ được thêm khi có fact hoặc quyết định có thẩm quyền. Ví dụ AC “hiển thị trạng thái truy xuất” cần xác định danh sách trạng thái từ nguồn canonical; nếu danh sách chưa được xác minh, AC chưa qua exit gate Analysis.

Consequence if Wrong: Nếu chuyển câu nói sang Delivery như rule đã chốt, nhóm có thể cấu hình chặn xuất kho không có căn cứ, hoặc Testing xác nhận một hành vi không giải quyết nhu cầu thật. Nếu đưa thay đổi đó vào Release, Operations phải xử lý gián đoạn kho và truy vết ngược khó vì thiếu AC gốc.

Senior Lens

Lifecycle không tuyến tính tuyệt đối; vòng quay lại là kiểm soát bình thường. Lỗi ở Testing có thể chứng minh AC mơ hồ, nên quay về Analysis. Phản hồi ở Operations có thể chứng minh outcome không đạt, nên tạo nhu cầu mới ở Discovery. Không sửa ngầm AC để làm kết quả test thành đạt; hành động đó phá bằng chứng lịch sử giữa nhu cầu, thay đổi và kiểm tra.

Dùng “đủ để chuyển pha”, không dùng “viết nhiều để an toàn”. Một AC đủ cho Testing khi người kiểm thử biết điều kiện ban đầu, thao tác hoặc sự kiện, và kết quả quan sát được. Một AC chưa đủ khi chứa từ như “nhanh”, “thân thiện”, “đúng quy định” mà không có tiêu chí đo, nguồn xác minh hoặc owner có thẩm quyền.

Quick Reference

Câu hỏi gate	Đạt khi	Không đạt khi
Có được rời Discovery?	Vấn đề, outcome và điểm chưa biết đã được ghi nhận.	Nhu cầu chỉ là khẩu hiệu không có bối cảnh.
Có được rời Analysis?	Story và AC có thể hiểu, xây và kiểm tra; claim chưa chứng minh được gắn nhãn.	AC ép hệ thống chặn, tính tiền hoặc tuân thủ mà không có căn cứ và xác minh phù hợp.
Có được rời Delivery?	Bản build hoặc cấu hình đối chiếu được về story và AC.	Có hành vi được thêm vì suy đoán nhưng không có traceability.
Có được rời Testing?	Kết quả cho từng AC được ghi nhận; sai lệch nhìn thấy được.	Test chỉ nói “đã test” mà không chỉ ra AC nào.
Có được rời Release?	Bằng chứng test và ngoại lệ được ghi nhận theo kiểm soát dự án.	IN_REVIEW bị diễn giải thành approval hoặc baseline.
Operations làm gì?	Tạo phản hồi có phân loại để quay lại Discovery khi cần.	Sửa trực tiếp story cũ mà không giữ lịch sử.

Core

User story và acceptance criteria đi qua nhiều vai trò; mỗi vai trò chỉ quyết định phần thuộc thẩm quyền. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dữ liệu tổng hợp, trạng thái corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. BA không tự biến nhu cầu thành cam kết nghiệp vụ, kết luận pháp lý, thiết kế kỹ thuật, kết quả kiểm thử hay quyết định phát hành. Lý do: mỗi kết luận cần người sở hữu rủi ro và quyền quyết định tương ứng.

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

flowchart TB
    BO[Business Owner<br/>Nêu mục tiêu, ưu tiên] -->|Mục tiêu, vấn đề, ưu tiên,<br/>phạm vi giả định| BA[Business Analyst<br/>Soạn user story và acceptance criteria]
    BA -->|User story, acceptance criteria,<br/>câu hỏi mở, ràng buộc đã biết,<br/>rule links nếu đã có| ARCH[Architect / Technical Lead]
    ARCH -->|Thiết kế khả thi,<br/>giới hạn kỹ thuật| DEV[Delivery Team]
    BA -->|Acceptance criteria, dữ liệu mô phỏng,<br/>ngoại lệ đã biết, rule links| QA[QA Lead / Tester]
    DEV -->|Bản xây dựng,<br/>thay đổi kỹ thuật| QA
    QA -->|Kết quả xác minh, lỗi,<br/>rủi ro còn lại| BA
    QA -->|Kết quả xác minh, lỗi,<br/>rủi ro còn lại| BO
    BA -->|Điểm mơ hồ, xung đột,<br/>thay đổi phạm vi| BO
    BO -->|Quyết định phát hành<br/>và chấp nhận rủi ro còn lại| DEV
    BA -->|Câu hỏi, bằng chứng, ảnh hưởng story,<br/>nguồn chính thức; Verification required| SPEC[Legal / Accounting / Security / Domain Owner]
    SPEC -->|Kết luận chuyên môn<br/>có thẩm quyền| BO
    SPEC -->|Kết luận chuyên môn<br/>để truy vết| BA

Handoff	Upstream owner	Downstream owner	Nội dung bàn giao	BA được làm	BA không được làm
Nhu cầu đến story	Business Owner	BA	Mục tiêu, vấn đề, ưu tiên, phạm vi giả định	Diễn đạt nhu cầu thành user story có thể kiểm tra	Tự chọn chính sách nghiệp vụ khi Business Owner chưa quyết
Story đến kỹ thuật	BA	Architect / Technical Lead	User story, acceptance criteria, liên kết tới CANONICAL_BUSINESS_RULES hoặc CANONICAL_DATA_DICTIONARY nếu đã có	Nêu hành vi cần đạt, câu hỏi mở, ràng buộc đã biết	Chọn kiến trúc, API, schema, phân quyền kỹ thuật
Story đến kiểm thử	BA	QA Lead / Tester	Acceptance criteria làm test basis, dữ liệu mô phỏng, ngoại lệ đã biết	Làm rõ ý nghĩa nghiệp vụ khi QA hỏi	Tự xác nhận kiểm thử đạt
Kết quả kiểm thử đến quyết định	QA Lead / Tester	Business Owner, BA	Kết quả xác minh, lỗi, rủi ro còn lại	Ghi tác động lỗi lên story và traceability	Tự chấp nhận rủi ro phát hành
Vấn đề chuyên ngành	BA	Legal, Accounting, Security, Domain Owner	Câu hỏi, bằng chứng, ảnh hưởng story, nguồn chính thức	Giữ nhãn Verification required	Diễn giải luật, kế toán, bảo mật thành kết luận cuối

Applied

Facts: Case mô phỏng Nova Foods có nhu cầu: nhân viên kho ghi nhận chênh lệch số lượng khi nhận nguyên liệu. Dữ liệu là tổng hợp; không khẳng định quy trình ERP thực tế hay nghĩa vụ pháp lý.

Current Behavior: Business Owner nói cần “kiểm soát chênh lệch”. Câu này chưa chỉ rõ ngưỡng chênh lệch, người quyết định, cách xử lý lô hàng, hay yêu cầu truy xuất.

Underlying Need: Cần story và acceptance criteria đủ rõ để Delivery Team xây đúng, QA kiểm thử được, nhưng không tự đặt quy tắc chất lượng hoặc kế toán.

Options: BA có thể: (1) tự đặt ngưỡng chênh lệch; (2) ghi acceptance criteria chung chung; (3) giữ ngưỡng là quyết định mở, chuyển Business Owner và Domain Owner xác định.

Decision Criteria: Chọn phương án nào bảo toàn thẩm quyền, cho phép kiểm thử hành vi xác định, không suy diễn quy định an toàn thực phẩm hoặc kế toán từ nguồn chưa được xác minh.

Decision: Chọn phương án 3. BA soạn story mô tả việc ghi nhận chênh lệch và trạng thái chờ xử lý; ngưỡng, người duyệt, tác động tồn kho mang nhãn Verification required đến khi owner có thẩm quyền kết luận.

Authority: Business Owner quyết định ưu tiên và xử lý nghiệp vụ. Domain Owner xác nhận ý nghĩa vận hành kho và truy xuất. Accounting Owner xác nhận tác động hạch toán nếu có. Legal Owner xác minh nghĩa vụ pháp lý nếu story chạm dữ liệu cá nhân, hóa đơn hoặc an toàn thực phẩm. Architect quyết định khả thi kỹ thuật. QA Lead xác nhận chiến lược và kết quả kiểm thử.

Artifact: BA cập nhật /02-handbook/07-user-stories-and-acceptance-criteria.md bằng liên kết nguồn tới /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md và /01-curriculum/TRACEABILITY_ID_REGISTRY.md khi các artifact này chứa mục tương ứng. Nếu chưa có mục canonical, BA ghi câu hỏi quyết định; không tạo ID mới ngoài registry.

Consequence if Wrong: BA tự đặt ngưỡng có thể làm Delivery Team xây sai kiểm soát kho, QA kiểm thử sai test basis, hoặc tạo diễn giải kế toán, pháp lý, an toàn thực phẩm ngoài thẩm quyền. Story nhìn có vẻ hoàn chỉnh nhưng không có chủ sở hữu quyết định.

Senior Lens

Escalation không phải dấu hiệu BA yếu. Escalation là cơ chế chặn suy diễn khi bằng chứng không đủ hoặc quyền quyết định nằm nơi khác. Escalate ngay khi có xung đột giữa Business Owner và Architect; acceptance criterion thay đổi số liệu tài chính; dữ liệu có thể là dữ liệu cá nhân; yêu cầu chạm truy xuất hoặc thu hồi thực phẩm; hoặc một quy tắc chưa có nguồn canonical nhưng bị yêu cầu viết như bắt buộc.

BA gửi gói escalation ngắn: câu hỏi quyết định, các lựa chọn, tác động từng lựa chọn, artifact bị ảnh hưởng, owner cần trả lời, nhãn Verification required. Không gửi kết luận thay owner. Evidence bridge: nguồn chính thức chỉ cho biết ranh giới dùng nguồn; chúng không tự xác định cấu hình Nova Foods mô phỏng.

Quick Reference

Tình huống	Owner quyết định	BA bàn giao	Escalate khi
Mục tiêu, ưu tiên, ngoại lệ nghiệp vụ	Business Owner	Story và lựa chọn đã phân tích	Hai owner yêu cầu hành vi trái nhau
Quy tắc kho, chất lượng, truy xuất	Domain Owner	Câu hỏi, dữ liệu mô phỏng, tác động	Quy tắc bị suy diễn từ thực hành cũ
Hạch toán, chứng từ, thuế	Accounting Owner, Legal Owner khi cần	Điều kiện nghiệp vụ và điểm cần xác minh	Story tạo hoặc thay đổi tác động tài chính
API, kiến trúc, bảo mật kỹ thuật	Architect / Security Owner	Hành vi cần đạt, ràng buộc nghiệp vụ	Giải pháp ảnh hưởng quyền truy cập hoặc dữ liệu
Kiểm thử và lỗi	QA Lead / Tester	Acceptance criteria, rule links	Kết quả kiểm thử mâu thuẫn cách hiểu story
Chấp nhận rủi ro phát hành	Business Owner theo governance dự án	Tác động nghiệp vụ và traceability	Lỗi còn mở hoặc acceptance criteria chưa xác minh

Core

Bản đồ vòng đời làm rõ user story (câu chuyện người dùng) và acceptance criteria (tiêu chí chấp nhận) biến đổi qua các pha, không phải sơ đồ phê duyệt. Nó giúp người mới thấy cùng một nhu cầu được làm rõ dần: Discovery ghi nhận vấn đề; Analysis diễn đạt nhu cầu kiểm thử được; Delivery biến nội dung đã làm rõ thành công việc; Testing dùng tiêu chí làm test basis; Release đóng gói phạm vi; Operations ghi nhận phản hồi để quay lại Discovery. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

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

flowchart LR
    D[Discovery<br/>Nhu cầu và vấn đề] --> A[Analysis<br/>User story và acceptance criteria]
    A --> DE[Delivery<br/>Công việc triển khai]
    DE --> T[Testing<br/>Kiểm thử theo acceptance criteria]
    T --> R[Release<br/>Phạm vi phát hành]
    R --> O[Operations<br/>Phản hồi vận hành]
    O --> D

    D -. bối cảnh .-> A
    A -. tiêu chí kiểm thử .-> T
    T -. kết quả kiểm thử .-> R
    O -. nhu cầu thay đổi .-> D

Sơ đồ dùng mũi tên liền cho luồng công việc và mũi tên nét đứt cho thông tin truy vết. Lý do: đội có thể hoàn tất Delivery nhưng vẫn phải chứng minh Testing đối chiếu đúng acceptance criteria đã viết tại Analysis; nếu chỉ xem luồng công việc, liên kết kiểm thử dễ bị mất.

Applied

Mục	Nội dung mô phỏng Nova Foods
Facts	Nhân viên kho cần biết đơn bán nào cần ưu tiên soạn trước trong ngày.
Current Behavior	Discovery ghi nhận phản ánh “khó biết đơn nào cần xử lý trước”; chưa là user story và chưa thể kiểm thử.
Underlying Need	Phân biệt vấn đề nghiệp vụ với cách xây màn hình: cần quy tắc hiển thị ưu tiên trước khi mô tả hành vi người dùng.
Options	Viết user story ngay; hoặc làm rõ tiêu chí ưu tiên rồi viết user story.
Decision Criteria	Tiêu chí chọn phải tạo được hành vi quan sát được và ca kiểm thử có kết quả xác định.
Decision	Làm rõ tiêu chí ưu tiên trước, rồi tạo user story và acceptance criteria tại Analysis.
Authority	Đây là ví dụ học liệu IN_REVIEW, v0.9.0; không xác nhận quyết định vận hành, baseline, approval hay cấu hình ERP.
Artifact	User story và acceptance criteria được quản trị trong /02-handbook/07-user-stories-and-acceptance-criteria.md; định danh và quy tắc canonical chỉ được tham chiếu từ /01-curriculum/TRACEABILITY_ID_REGISTRY.md và /01-curriculum/CANONICAL_BUSINESS_RULES.md.
Consequence if Wrong	Nếu chuyển câu phản ánh thẳng thành tiêu chí, Testing có thể xác nhận giao diện hiển thị nhưng không xác nhận đúng quy tắc ưu tiên.

Senior Lens

Không đọc sơ đồ như chuỗi một chiều tuyệt đối. Operations có thể phát hiện lỗi, dữ liệu thiếu hoặc nhu cầu mới; thông tin đó quay lại Discovery vì nó chưa tự động sửa user story đang tồn tại. Suy luận này dựa trên khác biệt bản chất: phản hồi vận hành là bằng chứng về thực tế quan sát được, còn user story là mô tả phạm vi cần phân tích và kiểm thử. Hai thứ liên quan nhưng không thay thế nhau.

Không gắn yêu cầu pháp lý, kế toán, thuế, an toàn thực phẩm hoặc bảo vệ dữ liệu cá nhân vào sơ đồ này như một kết luận. Khi nhu cầu chạm các miền đó, chỉ ghi Verification required và giữ tham chiếu nguồn chính thức; Legal Owner, Accounting Owner hoặc domain owner mới có thẩm quyền kết luận nội dung chuyên môn.

Quick Reference

Pha	User story hoặc acceptance criteria ở trạng thái nào
Discovery	Chưa hình thành; chỉ có nhu cầu, vấn đề và bối cảnh.
Analysis	Được viết, làm rõ và dùng làm nguồn cho Delivery, Testing.
Delivery	Được dùng để hiểu hành vi cần xây.
Testing	Được dùng làm test basis, không bị thay bằng kết quả test.
Release	Được đối chiếu với phạm vi phát hành.
Operations	Có thể nhận phản hồi tạo nhu cầu phân tích mới.

4. Input c?n thi?t

Core

User story cần đầu vào trước khi viết. Đầu vào là thông tin BA dùng để hiểu ai gặp vấn đề, đang làm gì, cần thay đổi gì và bằng chứng nào hỗ trợ nhận định đó. Người mới không cần biết phần mềm: ERP là hệ thống quản lý dữ liệu và quy trình như bán hàng, kho, mua hàng, sản xuất, kế toán.

Bằng chứng không phải kết luận. Ví dụ, một bảng tồn kho mô phỏng cho thấy cùng mã hàng có hai số lượng khác nhau là bằng chứng về chênh lệch dữ liệu; nó chưa chứng minh nguyên nhân là lỗi người dùng, lỗi tích hợp hay quy tắc hệ thống. BA phải giữ cầu nối suy luận: quan sát được gì, lấy từ artifact nào, suy ra nhu cầu phân tích nào.

Artifact nguồn là tệp hoặc tài liệu có thể truy lại. Với Nova Foods Trading & Manufacturing, mọi dữ liệu là mô phỏng giáo dục và tổng hợp. Artifact nguồn không tự tạo ra phê duyệt, baseline, quy tắc vận hành thật hoặc kết luận pháp lý.

Canonical ID là định danh chuẩn, giữ nguyên chuỗi qua nhiều artifact. ID giúp người đọc biết hai tham chiếu đang nói về cùng một đối tượng. Không đổi TRACEABILITY_ID_REGISTRY thành tên dịch, không rút /01-curriculum/CANONICAL_BUSINESS_RULES.md thành “file rule”, vì liên kết có thể mất khả năng truy vết.

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

flowchart TB
    A[Quan sát mô phỏng] --> B[Artifact nguồn]
    B --> C[Bằng chứng có thể truy lại]
    C --> D[Phân tích BA]
    D --> E[User story dự thảo]

    W[Bằng chứng không phải kết luận<br/>Không chứng minh nguyên nhân] -.-> C

    F[Canonical ID<br/>Giữ nguyên chuỗi] --- B
    F --- E

    H[Giới hạn artifact nguồn<br/>Không tự tạo phê duyệt, baseline,<br/>quy tắc vận hành thật hoặc kết luận pháp lý] -.-> B

Applied

Facts: Nova Foods là case study mô phỏng. Một nhân viên kho mô phỏng báo rằng số lượng “Hạt điều rang 500g” trên màn hình không khớp phiếu xuất kho mô phỏng. Có thể ghi nhận báo cáo này, nhưng chưa biết số liệu nào đúng.

Current Behavior: Người kho đối chiếu màn hình và phiếu thủ công. Báo cáo nói có chênh lệch, chưa nêu thời điểm ghi nhận, nguồn tạo phiếu, quy tắc làm tròn hay luồng cập nhật tồn kho.

Underlying Need: BA cần đủ đầu vào để mô tả nhu cầu kiểm soát chênh lệch tồn kho, không được viết ngay “hệ thống phải sửa tồn kho”.

Nhóm đầu vào	Giá trị Nova Foods mô phỏng	Artifact/ID canonical	BA dùng để làm gì
Bối cảnh tổ chức	Nova Foods Trading & Manufacturing, case study giáo dục	CHAPTER_MANIFEST	Giữ ranh giới mô phỏng, không suy ra vận hành thật.
Khái niệm BA	User story, acceptance criteria, stakeholder	00_SOURCE_MAP; BABOK Guide Version 3	Dùng thuật ngữ nhất quán; không gán số trang hoặc điều khoản chưa xác minh.
Vấn đề quan sát	Nhân viên kho mô phỏng thấy tồn màn hình khác phiếu xuất mô phỏng	Chưa có artifact nguồn được cung cấp	Xác định điểm cần thu thập bằng chứng, chưa kết luận nguyên nhân.
Quy tắc nghiệp vụ	Quy tắc trừ tồn sau xuất kho	CANONICAL_BUSINESS_RULES	Chỉ tham chiếu catalog; không tự đặt quy tắc mới.
Dữ liệu logic	Mã hàng, kho, lô hàng, số lượng, thời điểm ghi nhận	CANONICAL_DATA_DICTIONARY	Xác định dữ liệu phải làm rõ trước khi viết tiêu chí chấp nhận.
Định danh truy vết	ID cho story, rule, dữ liệu, test và artifact	TRACEABILITY_ID_REGISTRY	Bảo toàn liên kết; không tự chế ID ngoài registry.
Giới hạn pháp lý	Bối cảnh truy xuất thực phẩm có thể liên quan Luật An toàn thực phẩm	00_SOURCE_MAP; https://vanban.chinhphu.vn/?docid=96032&pageid=27160	Gắn Verification required; domain owner và Legal Owner xác minh.

Options: Viết story từ báo cáo miệng; hoặc chờ artifact nguồn và ID canonical. Phương án đầu nhanh hơn nhưng biến giả định thành phạm vi. Phương án sau chậm hơn nhưng giữ được bằng chứng và truy vết.

Decision Criteria: Chọn phương án chỉ khi nhận định có nguồn truy lại, thuật ngữ dữ liệu không mơ hồ, và ID tham chiếu tồn tại trong artifact canonical.

Decision: Chưa viết acceptance criteria cho chênh lệch tồn kho. Chỉ ghi nhu cầu phân tích: xác định nguồn số lượng, thời điểm cập nhật và quy tắc trừ tồn.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì artifact và traceability. Business Owner xác nhận nhu cầu nghiệp vụ. Domain owner và Legal Owner xác minh nội dung an toàn thực phẩm hoặc pháp lý. Không có approval được ghi nhận tại v0.9.0.

Artifact: /02-handbook/07-user-stories-and-acceptance-criteria.md tham chiếu /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/CANONICAL_DATA_DICTIONARY.md.

Consequence if Wrong: Nếu BA coi báo cáo miệng là quy tắc, đội Delivery có thể xây sai thời điểm trừ tồn. Testing khi đó chỉ kiểm thử hành vi được viết, không phát hiện giả định nguồn ban đầu sai.

Senior Lens

Không nhầm “có tài liệu” với “có bằng chứng đủ”. Tệp có tên rõ vẫn có thể chỉ là bản mô phỏng, bản nháp hoặc mô tả chưa được xác nhận. Suy luận này xuất phát từ mục đích khác nhau: artifact giữ thông tin, còn bằng chứng phải cho phép người khác kiểm tra lại thông tin đó.

Canonical ID không làm nội dung đúng hơn. Nó làm nội dung truy được. Khi rule, dữ liệu và story dùng cùng chuỗi tham chiếu chuẩn, BA có thể chỉ ra quan hệ giữa chúng mà không tuyên bố chúng đã được phê duyệt.

Quick Reference

Cần có trước khi viết story	Ý nghĩa
Vấn đề quan sát được	Biết điều gì đang cần phân tích.
Artifact nguồn	Có nơi truy lại thông tin.
Dữ liệu hoặc quy tắc liên quan	Không mô tả hành vi bằng thuật ngữ mơ hồ.
Canonical ID	Giữ liên kết nhất quán giữa artifact.
Ranh giới thẩm quyền	Không biến phân tích BA thành quyết định nghiệp vụ, pháp lý hoặc kế toán.

Core

Đầu vào cho User Story và Acceptance Criteria phải đủ tin cậy để biến nhu cầu thành điều kiện kiểm thử được. “Chất lượng đầu vào” nghĩa là BA kiểm được nguồn gốc, nội dung, thời điểm còn hiệu lực, người chịu trách nhiệm và giới hạn thẩm quyền. Thiếu một phần, BA không được tự điền bằng suy đoán.

Kiểm tra	Câu hỏi kiểm	Đạt khi	Không đạt
Định danh	Artifact ID, đường dẫn, version có khớp nguồn canonical không?	Giữ nguyên ID, filename, IN_REVIEW, v0.9.0	Dừng dùng nội dung đó làm cơ sở rule hoặc acceptance criterion
Phân loại nguồn	Đây là nguồn sơ cấp đã xác minh, artifact kiểm soát, giả định dự án hay cần xác minh?	Nhãn nguồn rõ	Gắn Verification required; không diễn đạt thành fact
Tính mới	Ngày cập nhật và trạng thái còn phù hợp ngày 2026-08-07 không?	Có ngày, version, trạng thái	Không suy ra requirement hiện hành
Ownership	Ai sở hữu nội dung và ai có thẩm quyền kết luận?	Owner và giới hạn thẩm quyền rõ	Escalation đúng vai trò
Nhất quán	Nội dung có mâu thuẫn nguồn canonical khác không?	Không mâu thuẫn, hoặc mâu thuẫn đã ghi nhận	Dừng phân rã story đến khi xử lý
Kiểm chứng	Fact có evidence truy vết được không?	Có URL chính thức hoặc artifact canonical	Không tạo acceptance criterion bắt buộc

Phân loại nguồn quyết định mức chắc chắn của câu viết. Verified primary source là nguồn chính thức có URL và trạng thái được kiểm. Controlled upstream artifact là artifact nội bộ có ID, đường dẫn, version và trạng thái kiểm soát. Project assumption là giả định học liệu, không phải quy tắc vận hành. Verification required là điểm chưa đủ bằng chứng hoặc cần người có thẩm quyền chuyên môn xác nhận.

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

flowchart TB
    BA[BA kiểm tra đầu vào] --> A[Nhận đầu vào]
    A --> C{Xác định được loại nguồn?}

    C -- Không --> V0[Verification required: xác minh loại nguồn]
    C -- Verified primary source --> P1{Có URL chính thức và trạng thái đã kiểm?}
    P1 -- Không --> V1[Verification required: xác minh nguồn và trạng thái]
    P1 -- Có --> T1{Có ngày cập nhật, version, trạng thái phù hợp ngày 2026-08-07?}

    C -- Controlled upstream artifact --> U1{Có ID, đường dẫn, version, trạng thái kiểm soát?}
    U1 -- Không --> V2[Verification required: xác minh artifact kiểm soát]
    U1 -- Có --> T2{Có ngày cập nhật, version, trạng thái phù hợp ngày 2026-08-07?}

    C -- Project assumption --> A1[Không dùng làm quy tắc vận hành]
    C -- Verification required --> V3[Không diễn đạt thành fact]

    V0 --> V3
    V1 --> V3
    V2 --> V3
    V3 --> S5[Không tạo acceptance criterion bắt buộc]
    A1 --> S5

    T1 -- Không --> S2[Không suy ra requirement hiện hành]
    T2 -- Không --> S2
    S2 --> S5

    T1 -- Có --> N1{Nhất quán với nguồn canonical?}
    T2 -- Có --> N1
    N1 -- Không --> S3[STOP: dừng phân rã story đến khi xử lý mâu thuẫn]
    N1 -- Có --> O{Owner và giới hạn thẩm quyền rõ?}
    O -- Không --> S4[Escalation đúng vai trò]
    O -- Có --> E{Có evidence truy vết được?}
    E -- Không --> S5
    E -- Có --> H[Dùng làm evidence cho User Story và Acceptance Criteria]

Applied

Mục	Nội dung
Facts	Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dữ liệu tổng hợp. /01-curriculum/CHAPTER_MANIFEST.md, CHAPTER_MANIFEST, trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07, là controlled upstream artifact.
Current Behavior	Người học thấy câu “ERP cần truy xuất lô hàng” nhưng chưa có bằng chứng quy trình, rule đã xác minh hoặc owner nghiệp vụ xác nhận.
Underlying Need	Tách nhu cầu có thể hợp lý khỏi requirement có thể kiểm thử. Reasoning: acceptance criterion sai sẽ tạo test sai, rồi đội delivery có thể xây sai.
Options	1. Viết criterion bắt buộc từ câu nêu trên. 2. Ghi là Project assumption. 3. Ghi là Verification required và dừng chi tiết hóa.
Decision Criteria	Có nguồn canonical, evidence truy vết, freshness đến 2026-08-07, owner có thẩm quyền, không vượt ranh giới pháp lý hoặc an toàn thực phẩm.
Decision	Chọn phương án 3. Chưa đủ evidence để xác định phạm vi truy xuất, thời gian đáp ứng, vai trò dùng hay dữ liệu lô bắt buộc.
Authority	Business Owner xác nhận nhu cầu vận hành; Food Safety Owner và Legal Owner xác minh nghĩa vụ liên quan; Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì traceability.
Artifact	Ghi điểm mở trong /02-handbook/07-user-stories-and-acceptance-criteria.md; tham chiếu nguồn quản trị CHAPTER_MANIFEST. Không tạo business rule mới.
Consequence if Wrong	Nếu viết “hệ thống phải truy xuất lô” như fact, team có thể chọn sai phạm vi, sai dữ liệu, sai acceptance test và diễn giải nhầm nghĩa vụ pháp lý.

Senior Lens

Freshness không chỉ là ngày tài liệu. BA kiểm cả version, trạng thái và khả năng thay thế. Ví dụ, nguồn pháp lý có URL chính thức nhưng chi tiết requirement vẫn cần Legal Owner xác minh; URL chứng minh nguồn tồn tại, không tự chứng minh cách áp dụng cho Nova Foods mô phỏng.

Dừng phân tích khi gặp một trong các điều kiện: ID hoặc filename không khớp nguồn canonical; nguồn mâu thuẫn; nội dung pháp lý, kế toán, thuế, an toàn thực phẩm, bảo mật hoặc kiến trúc bị viết như kết luận nhưng chưa có owner phù hợp; hoặc giả định bị yêu cầu chuyển thành acceptance criterion bắt buộc. Dừng là kiểm soát chất lượng, không phải chậm tiến độ.

Quick Reference

Nhãn dùng trong ghi chú BA	Ý nghĩa	Hành động
Verified primary source	Nguồn chính thức đã kiểm URL, phiên bản hoặc trạng thái	Dùng làm evidence trong giới hạn safe use boundary
Controlled upstream artifact	Artifact nội bộ canonical, có metadata kiểm soát	Giữ nguyên ID, filename, status, version
Project assumption	Giả định phục vụ case Nova Foods mô phỏng	Không gọi là rule, fact hoặc approval
Verification required	Chưa đủ evidence hoặc thiếu thẩm quyền kết luận	Escalation; không viết criterion bắt buộc
STOP	Input không đủ điều kiện phân rã	Không tạo User Story hoặc Acceptance Criteria từ input đó

Core

Bảng đầu vào Nova Foods dưới đây dùng cho User Story và Acceptance Criteria. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi giá trị là dữ liệu tổng hợp. IN_REVIEW không phải phê duyệt, baseline, hay cấu hình ERP thực tế.

Nhóm input	Giá trị mô phỏng	ID / tệp canonical	Phân loại nguồn	Trạng thái xác minh	Mục đích cho User Story và Acceptance Criteria
Bối cảnh case study	Nova Foods Trading & Manufacturing; Việt Nam; vi-VN; Asia/Ho_Chi_Minh; VND	CHAPTER_MANIFEST /01-curriculum/CHAPTER_MANIFEST.md	Controlled planning artifact	IN_REVIEW, v0.9.0, 2026-08-07	Giữ thuật ngữ, locale, tiền tệ và ranh giới mô phỏng nhất quán.
Quy tắc nghiệp vụ	Chưa có quy tắc Nova Foods đã được xác nhận cho vận hành thực	CANONICAL_BUSINESS_RULES /01-curriculum/CANONICAL_BUSINESS_RULES.md	Controlled planning artifact	Verification required	Không viết acceptance criterion như nghĩa vụ bắt buộc khi chưa có rule canonical được xác minh.
Dữ liệu nghiệp vụ	Mã hàng mô phỏng RM-SUGAR-001; số lượng mô phỏng 500 kg; kho mô phỏng WH-HCM-01	CANONICAL_DATA_DICTIONARY /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Controlled planning artifact	Verification required: field, kiểu dữ liệu, khóa và vòng đời chưa được xác nhận	Tạo ví dụ cụ thể, không suy diễn schema ERP thật.
Định danh truy vết	ID requirement, rule, data và test phải tra từ registry	TRACEABILITY_ID_REGISTRY /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Controlled planning artifact	IN_REVIEW; không có baseline reference	Ngăn User Story tạo ID tự phát hoặc tham chiếu đứt chuỗi.
Mẫu artifact	User Story, Acceptance Criteria, traceability template dự kiến	TEMPLATE_MANIFEST /01-curriculum/TEMPLATE_MANIFEST.md	Controlled planning artifact	IN_REVIEW; tên template cụ thể chưa được xác nhận	Chỉ dùng cấu trúc đã đăng ký; không coi manifest là nội dung đã phê duyệt.
Thuật ngữ BA	User Story: mô tả nhu cầu từ góc nhìn người dùng. Acceptance Criteria: điều kiện kiểm tra để xác nhận hành vi mong muốn.	BABOK Guide https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/	Primary external standard reference	Version 3; truy cập 2026-08-07	Dùng thuật ngữ BA; không gán số trang hoặc điều khoản chưa kiểm tra licensed text.
Cách kiểm thử điều kiện	Điều kiện có thể quan sát và kiểm tra độc lập	ISTQB CTFL Syllabus v4.0.1 https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf	Primary external standard reference	Xác minh nguồn; không tạo test case production	Chuyển nhu cầu thành điều kiện kiểm thử được.
Bối cảnh pháp lý dữ liệu cá nhân	Không có dữ liệu cá nhân thật trong ví dụ	Luật 91/2025/QH15 https://vanban.chinhphu.vn/?classid=1&docid=214590&pageid=27160&typegroup=	Official legal source	Verification required từ Legal Owner nếu requirement có dữ liệu cá nhân	Không suy diễn nghĩa vụ pháp lý từ ví dụ học liệu.
Bối cảnh an toàn thực phẩm và truy xuất	Nhu cầu truy xuất lô hàng chỉ là giả định học liệu	Luật 55/2010/QH12 https://vanban.chinhphu.vn/?docid=96032&pageid=27160	Official legal source	Verification required từ domain owner và Legal Owner	Không biến giả định truy xuất thành rule bắt buộc.

Applied

Facts: Người học nhận ví dụ mô phỏng: nhân viên kho muốn ghi nhận nhận 500 kg RM-SUGAR-001 vào WH-HCM-01.

Current Behavior: Không có artifact nào trong đầu vào xác nhận quy trình nhận hàng, vai trò thực, trường dữ liệu, quy tắc số lượng, hay quyền cập nhật kho.

Underlying Need: Cần phân biệt fact mô phỏng với requirement đã xác minh. Bằng chứng là CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY đều IN_REVIEW; do đó chúng chưa xác nhận hành vi ERP.

Options: Viết User Story như yêu cầu bắt buộc; hoặc ghi User Story là ví dụ học liệu có nhãn xác minh.

Decision Criteria: Chọn cách không tạo rule vận hành mới, giữ ID canonical, không khẳng định compliance hay approval.

Decision: Dùng câu: “Là nhân viên kho mô phỏng, tôi muốn ghi nhận số lượng nguyên liệu nhận vào kho để có dữ liệu tồn kho mô phỏng.” Không thêm Acceptance Criteria về phê duyệt, cập nhật tồn, truy xuất lô, hay hạch toán.

Authority: Business Owner xác nhận nhu cầu nghiệp vụ; Data Owner xác nhận dữ liệu; Architect xác nhận hành vi hệ thống; Legal Owner xác nhận nghĩa vụ pháp lý. Principal IT Business Analyst / Technical Curriculum Author chỉ giữ traceability.

Artifact: Nguồn đầu vào ghi tại CHAPTER_MANIFEST, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY.

Consequence if Wrong: Nếu gắn nhãn giả định thành rule đã xác nhận, acceptance criteria có thể kiểm tra sai hành vi, tạo nợ truy vết và bị hiểu nhầm là quyết định vận hành Nova Foods.

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

flowchart TB
    A["Fact mô phỏng:<br/>nhận 500 kg RM-SUGAR-001<br/>vào WH-HCM-01"]
    U["Đầu vào chưa xác nhận:<br/>quy trình nhận hàng, vai trò,<br/>trường dữ liệu, quy tắc số lượng,<br/>quyền cập nhật kho"]

    B["User Story ví dụ học liệu — cần xác minh:<br/>“Là nhân viên kho mô phỏng, tôi muốn ghi nhận<br/>số lượng nguyên liệu nhận vào kho để có dữ liệu<br/>tồn kho mô phỏng.”"]

    A --> B
    U --> B

    CM["CHAPTER_MANIFEST<br/>ghi nguồn đầu vào"]
    BR["CANONICAL_BUSINESS_RULES<br/>IN_REVIEW"]
    DI["CANONICAL_DATA_DICTIONARY<br/>IN_REVIEW"]
    TR["TRACEABILITY_ID_REGISTRY<br/>quản lý ID canonical"]

    CM --> D
    BR --> D
    DI --> D
    B --> D

    D{"Có bằng chứng xác nhận<br/>đúng phạm vi, trạng thái và thẩm quyền<br/>cho nội dung cần viết?"}

    D -->|Hiện tại: Không<br/>hai nguồn canonical còn IN_REVIEW| N["Giữ nhãn cần xác minh<br/>Giữ User Story ở mức ví dụ học liệu"]
    D -->|Có| V["Chỉ dùng nội dung đã xác minh"]

    N --> O["Không thêm Acceptance Criteria về:<br/>phê duyệt, cập nhật tồn,<br/>truy xuất lô hoặc hạch toán"]

    V --> E["Tạo Acceptance Criteria<br/>cho nội dung đã xác minh"]
    E --> L["Liên kết ID canonical"]
    TR -.-> L

    subgraph AUTH["Thẩm quyền theo loại nội dung"]
        BO["Nhu cầu nghiệp vụ<br/>Business Owner"]
        DO["Dữ liệu<br/>Data Owner"]
        AR["Hành vi hệ thống<br/>Architect"]
        LO["Nghĩa vụ pháp lý nếu có<br/>Legal Owner"]
    end

    BO -.-> D
    DO -.-> D
    AR -.-> D
    LO -.-> D

    T["Principal IT Business Analyst /<br/>Technical Curriculum Author<br/>chỉ giữ traceability"] -.-> L

    N -.-> R["Nếu bỏ nhãn cần xác minh:<br/>fact mô phỏng bị hiểu thành<br/>rule vận hành đã xác nhận"]
    R --> K["Acceptance Criteria kiểm tra sai hành vi ERP,<br/>tạo nợ truy vết và gây hiểu nhầm<br/>về quyết định vận hành Nova Foods"]

Senior Lens

“Complete” nghĩa là đủ hàng input cần ghi nhận trong phạm vi hiện có, không nghĩa là mọi nội dung đã đúng hoặc đã được chấp thuận. Ô Verification required là dữ liệu quản trị hợp lệ: nó nêu rõ khoảng trống và chặn BA biến suy đoán thành requirement.

Quick Reference

Nhãn	Ý nghĩa dùng trong bảng
IN_REVIEW	Đang xem xét; có thể thay đổi; không phải baseline hay approval.
Controlled planning artifact	Artifact quản trị corpus; không tự xác nhận nghiệp vụ Nova Foods.
Primary external standard reference	Nguồn chuẩn dùng cho thuật ngữ hoặc phương pháp; không tự tạo rule Nova Foods.
Official legal source	Nguồn pháp lý chính thức; requirement áp dụng cần Legal Owner xác minh.
Verification required	Chưa đủ bằng chứng để viết thành hành vi bắt buộc hoặc acceptance criterion khẳng định.

5. Step-by-step BA Activities

Core

BA biến nhu cầu chưa cấu trúc thành User Story và Acceptance Criteria có thể kiểm tra. User Story mô tả ai cần gì và giá trị nhận được. Acceptance Criteria là điều kiện quan sát được để xác nhận hành vi mong đợi. BA không tự xác nhận rule, pháp lý, kế toán, bảo mật hay kiến trúc; BA ghi nguồn, mức xác minh và chuyển đúng thẩm quyền.

Applied

Quy trình dưới áp dụng cho Nova Foods Trading & Manufacturing, case study mô phỏng, dữ liệu tổng hợp. Status corpus IN_REVIEW, version v0.9.0, ngày 2026-08-07; không có baseline hoặc approval được ghi nhận.

Bước	Actor	Action	Object	Evidence produced	Decision rule	Quality gate	Escalation route
1. Chuẩn bị phạm vi	BA	Đọc phạm vi story, source classification và dependency trước khi viết.	Input từ CHAPTER_MANIFEST, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY.	Danh sách input, ID canonical, nhãn IN_REVIEW hoặc Verification required.	Chỉ dùng ID, filename và source classification đã có trong artifact canonical.	Không có ID tự tạo, không gọi input là baseline hay approved.	Mâu thuẫn ID hoặc source canonical: Principal IT Business Analyst / Technical Curriculum Author.
2. Tách fact khỏi suy đoán	BA	Ghi từng phát biểu thành fact, current behavior, need hoặc assumption.	Ghi chú trao đổi và artifact đầu vào.	Bảng phân loại bằng chứng.	Fact phải có nguồn; assumption phải ghi Verification required.	Không biến suy đoán thành business rule hoặc acceptance criterion bắt buộc.	Nội dung pháp lý: Legal Owner. Kế toán: Accounting Owner. An toàn thực phẩm: domain owner và Legal Owner.
3. Xác định người dùng và giá trị	BA cùng Business Owner	Xác định actor nghiệp vụ, mục tiêu và giá trị của thay đổi.	Need đã phân loại.	Câu User Story dạng “Là [vai trò], tôi muốn [khả năng], để [giá trị].”	Vai trò phải là người hay hệ thống thực hiện mục tiêu trong phạm vi mô phỏng; giá trị phải giải thích vì sao cần khả năng đó.	Story không chứa giải pháp kỹ thuật, không gộp nhiều mục tiêu độc lập.	Tranh chấp ưu tiên hoặc giá trị: Business Owner.
4. Xác định hành vi và biên	BA cùng SME nghiệp vụ	Mô tả trigger, dữ liệu vào, kết quả, ngoại lệ và hành vi không được phép.	User Story và fact có nguồn.	Danh sách scenario theo Given-When-Then hoặc điều kiện kiểm tra tương đương.	Mỗi scenario phải liên kết một need hoặc rule; thiếu rule phải gắn Verification required.	Có ít nhất luồng chính, lỗi dự kiến và biên dữ liệu liên quan.	Luồng liên phòng ban: Business Owner. Tích hợp: Architect.
5. Viết Acceptance Criteria	BA	Viết tiêu chí rõ, quan sát được, kiểm tra được và không mơ hồ.	Scenario đã xác định.	Acceptance Criteria gắn User Story và nguồn.	Một tiêu chí kiểm tra một kết quả; dùng dữ liệu tổng hợp, định dạng vi-VN, thời gian Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND khi liên quan.	QA có thể suy ra expected result mà không cần đoán ý BA.	Không thể xác định expected result: trả về SME hoặc Business Owner để làm rõ need.
6. Kiểm tra rule, data, quyền và rủi ro	BA cùng reviewer chuyên môn	Đối chiếu criteria với rule canonical, data dictionary, phân quyền và source boundary.	Draft User Story, Acceptance Criteria, artifact canonical.	Ma trận traceability tối thiểu: story, criterion, nguồn, trạng thái xác minh.	Rule hoặc data chưa xác minh không được diễn đạt là bắt buộc. Requirement liên quan dữ liệu cá nhân cần Legal Owner và Security review.	Không có requirement pháp lý, kế toán, bảo mật hoặc kiến trúc bị BA tự kết luận.	Legal Owner, Accounting Owner, Security, Architect theo loại quyết định.
7. Review chéo	BA, Business Owner, QA reviewer, SME phù hợp	Review tính đúng nhu cầu, khả năng kiểm thử, nhất quán thuật ngữ và truy vết.	Gói draft và evidence.	Nhận xét review có người nêu ý kiến, ngày và kết quả xử lý.	Comment chỉ đóng khi có evidence hoặc quyết định từ vai trò có thẩm quyền.	Không ghi “đã phê duyệt” nếu artifact không có approval reference.	Comment không giải quyết được: ghi issue, giữ IN_REVIEW, chuyển Owner chuyên môn.
8. Handoff có kiểm soát	BA	Bàn giao bản review cho consumer, giữ liên kết source và điểm mở.	User Story, Acceptance Criteria, traceability, issue log.	Gói handoff nêu version v0.9.0, status IN_REVIEW, nguồn và Verification required.	Consumer nhận nội dung để review hoặc lập test basis, không suy diễn thành production instruction.	Không mất ID canonical, source boundary, trạng thái hoặc ngoại lệ mở.	Consumer cần thay đổi scope: quay lại Business Owner; cần thay đổi kiến trúc: Architect; cần xác minh tuân thủ: owner chuyên môn.

Facts: CHAPTER_MANIFEST, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY đều là controlled planning artifact ở IN_REVIEW. Nova Foods là mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp.

Current Behavior: Đầu vào có thể ghi một mong muốn như “theo dõi lô hàng”, nhưng chưa tự chứng minh định nghĩa lô, rule truy xuất, quyền xem dữ liệu hay nghĩa vụ pháp lý.

Underlying Need: BA cần chuyển mong muốn thành hành vi có thể kiểm tra, nhưng phải giữ khoảng trống xác minh thay vì tự tạo rule Nova Foods.

Options: Viết criterion như rule bắt buộc; hoặc ghi criterion có nguồn và gắn Verification required cho điều chưa có bằng chứng.

Decision Criteria: Chọn cách giữ traceability, không vượt thẩm quyền, cho QA xác định expected result, và không biến source pháp lý thành diễn giải pháp lý của BA.

Decision: Dùng User Story và Acceptance Criteria có liên kết artifact canonical; mọi rule chưa được nguồn và owner phù hợp xác minh giữ nhãn Verification required.

Authority: Business Owner xác nhận nhu cầu và ưu tiên. QA reviewer kiểm tra testability. Legal Owner, Accounting Owner, Security, Architect hoặc domain owner xác minh nội dung thuộc thẩm quyền tương ứng. BA duy trì cấu trúc, evidence và traceability.

Artifact: Draft User Story, Acceptance Criteria, bảng evidence, ma trận traceability và issue log trong phạm vi /02-handbook/07-user-stories-and-acceptance-criteria.md.

Consequence if Wrong: Criterion có thể kiểm tra sai hành vi, QA suy đoán expected result, team hiểu nhầm assumption là rule đã xác nhận, hoặc nội dung mô phỏng bị dùng như chỉ dẫn vận hành hay tuân thủ thực tế.

Senior Lens

Quy trình tốt không tối đa số lượng criterion. Nó giảm khoảng cách giữa need, evidence, decision và test. Nếu BA không chỉ ra nguồn của một câu, câu đó chưa đủ điều kiện thành requirement bắt buộc. Nếu reviewer không thể xác định ai quyết định, BA chưa hoàn thành escalation route.

Quick Reference

Kiểm tra trước handoff	Đạt khi
User Story	Có actor, capability và business value.
Acceptance Criteria	Quan sát được, kiểm tra được, có expected result.
Traceability	Liên kết source hoặc nhãn Verification required.
Governance	Giữ IN_REVIEW, v0.9.0, không tuyên bố baseline hoặc approval.
Thẩm quyền	Vấn đề pháp lý, kế toán, bảo mật, kiến trúc và nghiệp vụ được chuyển đúng owner.

Core

Quy trình này dùng cho Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, IN_REVIEW, v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh. User story là mô tả nhu cầu theo góc nhìn người dùng; acceptance criteria là điều kiện kiểm tra được để xác định story có đáp ứng nhu cầu không. BA không tự xác nhận nghiệp vụ, pháp lý, kế toán, bảo mật hay kiến trúc. BA tạo bằng chứng, nêu điểm cần quyết định, chuyển đúng chủ thể có thẩm quyền.

Bước	Actor	Action	Object	Evidence produced	Decision rule	Quality gate	Escalation route
1. Chuẩn bị nguồn	BA	Thu thập và lập danh sách nguồn canonical trước khi viết.	Quy trình hiện tại, vấn đề, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY.	Danh sách nguồn, phân loại nguồn, khoảng trống đã ghi nhận.	Chỉ dùng nguồn có đường dẫn hoặc ID canonical; thông tin chưa xác minh giữ nhãn Verification required hoặc project assumption.	Mỗi nhận định có nguồn hoặc nhãn giả định; không biến mô tả miệng thành business rule.	Nguồn mâu thuẫn: Principal IT Business Analyst / Technical Curriculum Author lập gói vấn đề; nội dung nghiệp vụ chuyển Business Owner.
2. Tách nhu cầu	BA cùng Business Owner	Phân biệt facts, current behavior và underlying need.	Vấn đề nghiệp vụ được nêu.	Bảng facts và nhu cầu gốc.	Fact phải quan sát, truy vết được; need phải giải thích tác động mong muốn, không nhảy thẳng sang giải pháp.	Không có giải pháp ERP bị viết thành nhu cầu; mỗi inference nêu fact làm căn cứ.	Need ảnh hưởng vận hành, giá, tồn kho hoặc chính sách: Business Owner quyết định.
3. Soạn user story	BA	Viết story theo vai trò, mục tiêu và giá trị; giới hạn đúng một outcome nghiệp vụ.	Need đã làm rõ.	Bản user story và liên kết tới nguồn.	Story đủ nhỏ để kiểm tra độc lập; không chứa thiết kế màn hình, API hoặc cấu hình khi chưa có quyết định kiến trúc.	Vai trò tồn tại trong bối cảnh mô phỏng; mục tiêu đo được hoặc quan sát được; giá trị không trùng mục tiêu.	Tranh chấp vai trò hoặc ưu tiên: Business Owner; phụ thuộc hệ thống: Architect.
4. Soạn acceptance criteria	BA cùng QA reviewer	Chuyển rule và tình huống thành điều kiện Given-When-Then kiểm tra được.	User story, rule, dữ liệu logic.	Danh sách acceptance criteria, dữ liệu mẫu tổng hợp, liên kết rule.	Mỗi criterion có tiền điều kiện, hành động, kết quả; kết quả không mơ hồ như “nhanh”, “đúng”, “thân thiện”.	QA reviewer xác định được test basis mà không suy diễn rule mới; dữ liệu không chứa dữ liệu cá nhân thật.	Criterion liên quan bảo mật: Security; pháp lý dữ liệu cá nhân: Legal/Compliance Owner; kế toán: Accounting Owner.
5. Kiểm tra khả thi và traceability	BA cùng Architect, QA reviewer	Kiểm tra story và criteria không mâu thuẫn dữ liệu, tích hợp, rule hoặc giới hạn kỹ thuật.	Story, criteria, nguồn canonical.	Ma trận truy vết nguồn–need–story–criterion; danh sách xung đột.	Không có criterion nào thiếu nguồn, owner quyết định hoặc nhãn xác minh.	Không trùng ID, không đổi nghĩa source canonical, không gọi nội dung là baseline hoặc approved.	Tích hợp hoặc dữ liệu: Architect; chất lượng kiểm thử: QA reviewer; mâu thuẫn rule: Business Owner.
6. Review và handoff có kiểm soát	BA	Gửi gói review, ghi nhận kết quả review và chuyển test basis đúng phạm vi.	Story, criteria, traceability, điểm mở.	Gói handoff, log review, danh sách điểm mở và owner.	Chỉ handoff nội dung có trạng thái rõ; IN_REVIEW không được diễn giải là approved, baselined hay sẵn sàng production.	Tệp, nguồn, phiên bản v0.9.0, ngày 2026-08-07 và trạng thái nhất quán.	Review không kết luận được: giữ IN_REVIEW, không tự đóng; chuyển owner thẩm quyền theo loại quyết định.

Applied

Facts: Nova Foods mô phỏng ghi nhận nhân viên kho có thể chọn lô nguyên liệu hết hạn trên màn hình xuất kho. Bằng chứng là mô tả current behavior trong phạm vi học liệu; không có log production và không có dữ liệu thật.

Current Behavior: Hệ thống mô phỏng chưa có acceptance criterion chặn xác nhận xuất kho khi ngày hết hạn của lô nhỏ hơn ngày xuất kho.

Underlying Need: Kho cần ngăn xác nhận giao dịch xuất kho dùng lô đã hết hạn. Lý do: fact cho thấy thao tác hiện tại cho phép chọn lô; nếu không có điều kiện kiểm tra, outcome “không xuất lô hết hạn” không thể được kiểm thử.

Options: Chặn tại màn hình xuất kho; chỉ cảnh báo; kiểm tra sau khi ghi nhận giao dịch.

Decision Criteria: Ngăn sai sót trước khi dữ liệu xuất kho được ghi; kết quả kiểm thử xác định; không tự diễn giải nghĩa vụ pháp lý hoặc quy định an toàn thực phẩm.

Decision: BA đề xuất acceptance criterion chặn trước xác nhận, còn quyết định nghiệp vụ thuộc Business Owner. Đây là project assumption cho case mô phỏng; Verification required bởi domain owner và Legal/Compliance Owner nếu dùng cho vận hành thật.

Authority: Business Owner quyết định mức chấp nhận rủi ro vận hành; Architect xác nhận điểm kiểm tra; QA reviewer xác nhận khả năng kiểm thử; Legal/Compliance Owner xác minh diễn giải pháp lý nếu được viện dẫn.

Artifact: User story, acceptance criteria và liên kết tới /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md.

Consequence if Wrong: Chỉ cảnh báo khi nghiệp vụ cần chặn có thể cho phép xuất lô không phù hợp; chặn khi nghiệp vụ chỉ cần cảnh báo có thể làm gián đoạn kho. Vì hai hậu quả khác nhau, BA không tự chọn thay Business Owner.

Senior Lens

Evidence không phải ý kiến đồng thuận. Một câu “kho muốn chặn” chỉ là input; rule chỉ đủ mạnh khi nguồn, owner và phạm vi áp dụng rõ. Acceptance criterion tốt biến quyết định thành kiểm tra; nó không tự tạo quyết định.

Quick Reference

Mỗi bước phải trả lời đủ bảy điểm: ai làm, làm gì, trên object nào, tạo bằng chứng gì, quyết định theo rule nào, qua quality gate nào, và bế tắc chuyển ai. Thiếu một điểm thì traceability đứt hoặc thẩm quyền bị lẫn.

Core

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Bảng thực thi biến một User Story thành bằng chứng kiểm tra được: mỗi hành động phải có đối tượng, tiêu chí quyết định và tuyến escalation. Sơ đồ chỉ mô tả luồng đề xuất trong trạng thái IN_REVIEW, không xác nhận cấu hình ERP, baseline hay phê duyệt.

Applied

Case mô phỏng: Nhân viên bán hàng cần giữ đơn khi khách yêu cầu giao sau, để kho không xuất nhầm. Nhu cầu suy ra từ hành vi hiện tại: đơn giao sau vẫn có thể đi vào luồng chuẩn bị xuất; vì vậy phải có trạng thái giữ đơn và điều kiện mở giữ rõ ràng.

Thành phần	Nội dung thực thi
Facts	Đơn bán hàng tổng hợp SO-NF-20260807-001 trị giá 12.500.000 VND; ngày giao yêu cầu là 2026-08-12; nhân viên tạo đơn ngày 2026-08-07 tại Asia/Ho_Chi_Minh.
Current Behavior	Đơn có thể được kho nhìn thấy như đơn sẵn sàng xử lý ngay khi được tạo. Bằng chứng cần kiểm tra: màn hình danh sách đơn và nhật ký trạng thái của ERP mô phỏng.
Underlying Need	Tách “đơn đã ghi nhận” khỏi “đơn được phép xuất kho”. Lý do: ngày giao trong tương lai không tự chứng minh hàng được phép xuất ngay.
Options	(1) Chặn tạo đơn giao sau; (2) tạo đơn nhưng đặt trạng thái giữ; (3) tạo đơn và để kho tự đọc ngày giao.
Decision Criteria	Không mất đơn bán; kho nhận tín hiệu không xuất; trạng thái có thể truy vết; không tự diễn giải quy định kế toán, thuế hay pháp lý.
Decision	Chọn phương án (2): đơn giao sau nhận trạng thái ON_HOLD; chỉ chuyển READY_FOR_FULFILLMENT khi điều kiện mở giữ được xác nhận trong rule catalog.
Authority	Business Owner xác nhận chính sách giao hàng; Warehouse Lead xác nhận điểm kiểm soát kho; Architect xác nhận trạng thái và tích hợp; QA xác nhận test basis. BA không tự quyết định thay các vai trò này.
Artifact	User Story, Acceptance Criteria, decision log và traceability link trong /02-handbook/07-user-stories-and-acceptance-criteria.md; nguồn rule tham chiếu /01-curriculum/CANONICAL_BUSINESS_RULES.md, hiện IN_REVIEW, v0.9.0.
Consequence if Wrong	Kho có thể chuẩn bị hoặc xuất sai ngày; khách nhận sai cam kết; dữ liệu vận hành mất khả năng giải thích. Không suy ra vi phạm pháp lý từ case mô phỏng này.

Bước	Actor	Action	Object	Evidence produced	Decision rule	Quality gate	Escalation route
1	BA	Đọc đơn và ngày giao	SO-NF-20260807-001	Facts đã ghi nguồn dữ liệu tổng hợp	Ngày giao sau ngày tạo kích hoạt xem xét giữ đơn	Facts khớp ngày, tiền tệ VND, múi giờ Asia/Ho_Chi_Minh	Sai hoặc thiếu dữ liệu: Business Owner
2	BA	Viết User Story	Nhu cầu giữ đơn	Story nêu người dùng, mục tiêu, giá trị	Không gán giải pháp kỹ thuật vào nhu cầu	Người đọc mới phân biệt được nhu cầu với cách làm	Mâu thuẫn quy trình: Business Owner và Warehouse Lead
3	Warehouse Lead	Xác nhận điểm chặn xuất kho	Trạng thái đơn	Xác nhận nghiệp vụ ghi trong review record	ON_HOLD không được tạo yêu cầu xuất kho	Không có đường vòng bỏ qua trạng thái	Xung đột vận hành: Business Owner
4	Architect	Kiểm tra chuyển trạng thái và tích hợp	ERP, luồng kho	Nhận xét kiến trúc có truy vết	Chỉ tích hợp nhận đơn ở READY_FOR_FULFILLMENT	Không thêm trạng thái không có owner hoặc sự kiện	Rủi ro tích hợp: Architect
5	QA	Chuyển tiêu chí thành kiểm tra	Acceptance Criteria	Test basis truy vết về story và rule	Mỗi tiêu chí có kết quả quan sát được	Có kiểm tra cả giữ đơn và mở giữ	Tiêu chí không kiểm thử được: BA và QA
6	BA	Handoff có kiểm soát	Gói story, criteria, quyết định	Link artifact và trạng thái IN_REVIEW	Không gọi là approved hoặc baselined	Đủ owner, nguồn, giả định, điểm xác minh	Thiếu thẩm quyền: Principal IT Business Analyst / Technical Curriculum Author

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

stateDiagram-v2
    direction TB
    [*] --> DRAFT: tạo đơn
    DRAFT --> ON_HOLD: ngày giao sau ngày tạo
    note right of ON_HOLD
        Chặn tích hợp kho:
        không tạo yêu cầu xuất kho
    end note
    ON_HOLD --> READY_FOR_FULFILLMENT: Business Owner/Warehouse Lead xác nhận điều kiện mở giữ trong rule catalog
    note right of READY_FOR_FULFILLMENT
        Luồng kho chỉ nhận đơn
        tại trạng thái này
    end note
    ON_HOLD --> CANCELLED: hủy đơn
    READY_FOR_FULFILLMENT --> FULFILLMENT_IN_PROGRESS: kho nhận xử lý
    FULFILLMENT_IN_PROGRESS --> [*]
    CANCELLED --> [*]

Senior Lens

Không suy luận “ngày giao tương lai” là quy định pháp lý hay kế toán. Đây là project assumption của case mô phỏng. Nếu rule ảnh hưởng hóa đơn, ghi nhận doanh thu, dữ liệu cá nhân hoặc truy xuất thực phẩm, BA giữ nhãn Verification required và escalation tới Accounting Owner, Legal Owner, Security hoặc domain owner phù hợp.

Quick Reference

User Story trả lời ai cần gì và vì sao. Acceptance Criteria trả lời hệ thống phải quan sát được gì để chứng minh story đạt. Decision log giữ lựa chọn, tiêu chí và thẩm quyền; không thay thế approval.

6. Output thu ???c

Core

Output là artifact, tức bằng chứng có cấu trúc BA tạo mới hoặc cập nhật để người sau review cùng một nhu cầu, không phải nhớ lại từ trao đổi miệng. Mọi output Nova Foods là mô phỏng giáo dục, dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND.

Output tạo hoặc cập nhật	Canonical ID / nguồn ID	Owner	Status	Nội dung tối thiểu	Nghĩa vụ lịch sử thay đổi
User Story	ID story phải được cấp theo /01-curriculum/TRACEABILITY_ID_REGISTRY.md; không tự đặt ID ngoài registry	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Persona, nhu cầu, giá trị nghiệp vụ, phạm vi, link rule hoặc assumption, nguồn evidence	Ghi version, ngày 2026-08-07, người sửa, lý do sửa, trường bị ảnh hưởng
Acceptance Criteria	ID criterion phải liên kết ID story và được cấp theo TRACEABILITY_ID_REGISTRY	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Điều kiện đầu vào, hành động hoặc sự kiện, kết quả quan sát được, ngoại lệ, link story	Ghi thay đổi tiêu chí, lý do, tác động tới story, rule, test basis
Traceability link	TRACEABILITY_ID_REGISTRY	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Liên kết evidence, need, story, criterion, rule, assumption, điểm cần xác minh	Không xóa link cũ im lặng; ghi link thay thế và lý do
Business-rule reference	CANONICAL_BUSINESS_RULES	Owner catalog duy trì quản trị; Business Owner xác nhận nghiệp vụ khi cần	IN_REVIEW	Rule ID, diễn giải rule, nguồn, phạm vi, authority, nhãn Verification required nếu chưa xác minh	Ghi thay đổi rule, nguồn thay đổi, tác động tới story và criteria
Data-term reference	CANONICAL_DATA_DICTIONARY	Owner catalog duy trì quản trị; Data Owner hoặc Architect xác minh khi cần	IN_REVIEW	Tên dữ liệu, nghĩa nghiệp vụ, định dạng logic, nguồn, consumer	Ghi thay đổi nghĩa, kiểu dữ liệu logic, tác động tích hợp hoặc báo cáo
Decision record	ID quyết định phải được cấp theo TRACEABILITY_ID_REGISTRY	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Vấn đề, options, tiêu chí, decision, authority, evidence, consequence	Ghi quyết định thay thế, lý do, authority cần xác minh; không sửa đè quyết định cũ

Không có canonical ID riêng cho User Story, Acceptance Criteria hay Decision record trong nguồn đầu vào đã cung cấp. Vì vậy batch này không bịa prefix hoặc số thứ tự. BA phải lấy ID từ TRACEABILITY_ID_REGISTRY trước khi ghi artifact.

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

flowchart TB
    subgraph F["Phạm vi: tạo artifact và traceability"]
        E["Evidence"] --> N["Underlying Need"]
        A["Project assumption<br/>đánh dấu điểm cần xác minh"] --> N
        N --> US["User Story<br/>persona · nhu cầu · giá trị<br/>phạm vi · rule/assumption · evidence"]
        US -->|"Criterion ID liên kết Story ID"| AC["Acceptance Criterion<br/>đầu vào · hành động/sự kiện<br/>kết quả quan sát được · ngoại lệ · story"]

        BR["Business-rule reference<br/>Rule ID · diễn giải · nguồn<br/>phạm vi · authority<br/>Verification required nếu chưa xác minh"] --> US
        DD["Data-term reference<br/>tên · nghĩa nghiệp vụ · định dạng logic<br/>nguồn · consumer"] --> US
        DR["Decision record<br/>vấn đề · options · tiêu chí · decision<br/>authority · evidence · consequence"] -->|"tác động quyết định"| US
        DR -->|"tác động quyết định"| AC

        TL["Traceability link<br/>evidence · need · story · criterion<br/>rule · assumption · điểm cần xác minh"]

        E -.-> TL
        A -.-> TL
        N -.-> TL
        US -.-> TL
        AC -.-> TL
        BR -.-> TL
        DD -.-> TL
        DR -.-> TL
    end

    subgraph IDG["Cấp ID bắt buộc"]
        REG["TRACEABILITY_ID_REGISTRY<br/>không tự đặt ID"]
    end

    REG -->|"cấp Story ID"| US
    REG -->|"cấp Criterion ID"| AC
    REG -->|"cấp Decision ID"| DR

    subgraph GOV["Trạng thái và trách nhiệm"]
        S["Status: IN_REVIEW"]
        O1["Owner User Story · Acceptance Criterion<br/>Traceability link · Decision record:<br/>Principal IT Business Analyst / Technical Curriculum Author"]
        O2["Business-rule reference:<br/>Owner catalog duy trì<br/>Business Owner xác nhận khi cần"]
        O3["Data-term reference:<br/>Owner catalog duy trì<br/>Data Owner hoặc Architect xác minh khi cần"]
    end

    S -.-> US
    S -.-> AC
    S -.-> TL
    S -.-> BR
    S -.-> DD
    S -.-> DR
    O1 -.-> US
    O1 -.-> AC
    O1 -.-> TL
    O1 -.-> DR
    O2 -.-> BR
    O3 -.-> DD

    subgraph HIST["Lịch sử thay đổi theo artifact"]
        HUS["User Story<br/>version · ngày 2026-08-07 · người sửa<br/>lý do · trường bị ảnh hưởng"]
        HAC["Acceptance Criterion<br/>tiêu chí thay đổi · lý do<br/>tác động story · rule · test basis"]
        HTL["Traceability link<br/>không xóa link cũ im lặng<br/>ghi link thay thế · lý do"]
        HBR["Business-rule reference<br/>rule thay đổi · nguồn thay đổi<br/>tác động story · criteria"]
        HDD["Data-term reference<br/>nghĩa hoặc kiểu logic thay đổi<br/>tác động tích hợp · báo cáo"]
        HDR["Decision record<br/>quyết định thay thế · lý do<br/>authority cần xác minh<br/>không sửa đè quyết định cũ"]
    end

    US -.-> HUS
    AC -.-> HAC
    TL -.-> HTL
    BR -.-> HBR
    DD -.-> HDD
    DR -.-> HDR

Applied

Nova Foods mô phỏng cần giữ đơn bán khi ngày giao hàng sau ngày tạo đơn. Evidence là mô tả hành vi hiện tại từ case mô phỏng, không phải quy định pháp lý hay cấu hình ERP thực tế. Underlying Need là ngăn kho nhận xử lý đơn trước thời điểm nghiệp vụ dự kiến. Output cần tạo gồm User Story, Acceptance Criteria, traceability link và Decision record; nếu rule hoặc data term đã tồn tại, chỉ cập nhật liên kết đến CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY.

Thành phần	Nội dung ghi nhận
Facts	Case mô phỏng có ngày tạo đơn và ngày giao hàng; dữ liệu đều tổng hợp.
Current Behavior	Hành vi hiện tại cần được mô tả bằng evidence; không suy diễn từ tên trạng thái.
Underlying Need	Kho chỉ nhận xử lý khi điều kiện mở giữ được thỏa.
Options	Giữ đơn bằng trạng thái ERP; cảnh báo không chặn xử lý; xử lý thủ công ngoài ERP.
Decision Criteria	Có chặn xử lý sớm; kết quả quan sát được; truy vết về need; owner có thẩm quyền.
Decision	Chưa ghi quyết định vận hành. Ghi lựa chọn đang review trong Decision record.
Authority	Business Owner xác nhận quy tắc vận hành; Architect xác nhận tác động trạng thái hoặc tích hợp; QA review khả năng kiểm thử.
Artifact	Story, criteria, link truy vết, Decision record; ID chỉ cấp từ TRACEABILITY_ID_REGISTRY.
Consequence if Wrong	Kho có thể xử lý sớm, hoặc đơn hợp lệ bị giữ sai; test basis mất liên kết tới nhu cầu.

Senior Lens

IN_REVIEW nghĩa artifact đ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 duy trì ID, metadata và lịch sử; Owner không thay Business Owner, Architect, QA, Legal Owner, Accounting Owner hoặc Security xác nhận nội dung thuộc thẩm quyền họ.

Mỗi thay đổi phải giữ cầu nối reasoning: evidence nào đổi, need nào bị ảnh hưởng, artifact nào phải cập nhật, ai cần review. Cầu nối này ngăn “sửa câu chữ” làm đổi rule, data meaning hoặc hành vi hệ thống mà không ai thấy.

Quick Reference

• Canonical registry: TRACEABILITY_ID_REGISTRY.
• Canonical rule catalog: CANONICAL_BUSINESS_RULES.
• Canonical data catalog: CANONICAL_DATA_DICTIONARY.
• Status hiện hành: IN_REVIEW; version v0.9.0; ngày 2026-08-07.
• Không tự tạo ID, không sửa im lặng, không gọi output là approved hoặc baselined.

Core

Output anatomy là cấu trúc đủ trường để người review hiểu yêu cầu, kiểm tra được tiêu chí chấp nhận, lần ngược nguồn và biết thay đổi nào đã xảy ra. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu đều tổng hợp; ID dưới đây là ID canonical của ví dụ học liệu này.

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

flowchart TB
    SRC[Nguồn]
    US[US-NF-SO-001<br/>User Story]
    AC[AC-NF-SO-001-01 đến -03<br/>Acceptance Criteria]
    TR[TR-NF-SO-001<br/>Traceability Record]
    ART[Artifact đích]
    CH[CHG-NF-SO-001-001<br/>Change History]

    US -->|được đặc tả bởi| AC
    SRC -->|được truy vết trong| TR
    US -->|được truy vết trong| TR
    AC -->|được truy vết trong| TR
    TR -->|liên kết tới| ART
    US -->|có thay đổi được ghi nhận trong| CH
    AC -->|có thay đổi được ghi nhận trong| CH

Thành phần	Bắt buộc chứa	Mục đích kiểm tra
User Story	ID, persona, nhu cầu, giá trị, phạm vi, status, version	Xác định ai cần gì và vì sao.
Acceptance Criteria	ID, điều kiện đầu vào, hành động, kết quả quan sát được, ngoại lệ	Biến nhu cầu thành điều kiện kiểm thử được.
Traceability Record	ID liên kết, nguồn, User Story, Acceptance Criteria, artifact đích	Không để requirement mất liên kết khi chuyển sang review hoặc test.
Change History	Change ID, ngày, người ghi nhận, thay đổi, lý do, ảnh hưởng	Ngăn sửa im lặng làm sai hiểu biết của reviewer.

Applied

Mục	Nội dung Nova Foods mô phỏng
Facts	Nhân viên bán hàng nhập đơn cho khách hàng tổng hợp KH-00021. Đơn có mặt hàng SP-TP-001, số lượng 120, đơn giá 85.000 VND.
Current Behavior	Người nhập có thể lưu đơn dù số lượng đặt vượt số lượng khả dụng mô phỏng. Người kho phát hiện chênh lệch sau khi nhận danh sách chuẩn bị hàng.
Underlying Need	Cần báo ngay tại lúc nhập đơn khi số lượng yêu cầu lớn hơn số lượng khả dụng, để giảm đơn không thể chuẩn bị hàng.
Options	Phương án 1: vẫn lưu đơn và chỉ cảnh báo. Phương án 2: chặn lưu toàn bộ đơn. Phương án 3: cho lưu bản nháp nhưng chặn xác nhận đơn.
Decision Criteria	Phải giữ dữ liệu nhập để nhân viên xử lý lại; phải ngăn đơn vượt tồn đi vào bước chuẩn bị hàng; lỗi phải nhìn thấy được; không tự suy diễn quy tắc kế toán hoặc phân bổ tồn thực tế.
Decision	Chọn phương án 3 trong ví dụ học liệu: hệ thống cho lưu Draft, không cho chuyển Confirmed khi một dòng vượt số lượng khả dụng.
Authority	Business Owner quyết định quy tắc vận hành; Inventory Owner xác nhận nghĩa của “số lượng khả dụng”; Principal IT Business Analyst / Technical Curriculum Author ghi nhận artifact. Chưa có quyết định hoặc phê duyệt được ghi nhận.
Artifact	US-NF-SO-001, AC-NF-SO-001-01, AC-NF-SO-001-02, AC-NF-SO-001-03, TR-NF-SO-001, CHG-NF-SO-001-001.
Consequence if Wrong	Nếu cho xác nhận đơn vượt tồn, kho có thể nhận yêu cầu không thể chuẩn bị. Nếu chặn cả lưu nháp, nhân viên mất dữ liệu đã nhập và phải nhập lại.

User Story hoàn chỉnh

Trường	Giá trị
Artifact ID	US-NF-SO-001
Artifact type	User Story
Status	IN_REVIEW
Version	v0.9.0
Date	2026-08-07
Locale	vi-VN, Asia/Ho_Chi_Minh, VND
Persona	Nhân viên bán hàng Nova Foods mô phỏng
Story	Là nhân viên bán hàng, tôi muốn hệ thống kiểm tra số lượng khả dụng khi xác nhận đơn bán, để không chuyển đơn vượt tồn sang bước chuẩn bị hàng.
Scope boundary	Chỉ xử lý kiểm tra số lượng khả dụng mô phỏng tại xác nhận đơn. Không xác định công thức tồn thực tế, phân bổ tồn, giá vốn, thuế, hóa đơn hoặc cấu hình ERP production.
Source classification	Synthetic educational case data
Change-history obligation	Mọi sửa persona, giá trị, phạm vi hoặc liên kết Acceptance Criteria phải có dòng mới trong CHG-NF-SO-001-001 hoặc change record kế tiếp.

Acceptance Criteria hoàn chỉnh

Acceptance Criteria ID	Given	When	Then	Ngoại lệ và bằng chứng
AC-NF-SO-001-01	Đơn SO-NF-00021 ở trạng thái Draft; dòng SP-TP-001 có số lượng đặt 120; số lượng khả dụng mô phỏng là 100.	Nhân viên chọn xác nhận đơn.	Hệ thống không chuyển đơn sang Confirmed; đơn giữ trạng thái Draft.	Hiển thị lỗi gắn với dòng SP-TP-001: Số lượng đặt 120 vượt số lượng khả dụng 100.
AC-NF-SO-001-02	Cùng đơn và dữ liệu của AC-NF-SO-001-01.	Nhân viên sửa số lượng SP-TP-001 từ 120 thành 100, rồi chọn xác nhận đơn.	Hệ thống cho phép chuyển đơn sang Confirmed.	Kết quả chỉ chứng minh điều kiện số lượng mô phỏng của ví dụ; không chứng minh giữ hàng thực tế.
AC-NF-SO-001-03	Đơn SO-NF-00022 ở trạng thái Draft; SP-TP-001 có số lượng đặt 80; số lượng khả dụng mô phỏng là 100.	Nhân viên chọn lưu nháp.	Hệ thống lưu đơn ở trạng thái Draft.	Không cần chạy kiểm tra chặn xác nhận tại thao tác lưu nháp trong phạm vi ví dụ này.

Traceability Record hoàn chỉnh

Traceability ID	Upstream evidence	Requirement link	Downstream target	Boundary
TR-NF-SO-001	Facts và Current Behavior trong Applied case; dữ liệu tổng hợp Nova Foods	US-NF-SO-001	AC-NF-SO-001-01, AC-NF-SO-001-02, AC-NF-SO-001-03	Không liên kết tới quy định pháp lý, kế toán, tồn kho thực tế hoặc cấu hình production.

Change History hoàn chỉnh

Change ID	Date	Người ghi nhận	Thay đổi	Lý do	Ảnh hưởng
CHG-NF-SO-001-001	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Khởi tạo US-NF-SO-001, ba Acceptance Criteria và TR-NF-SO-001 tại v0.9.0.	Tạo ví dụ học liệu về User Story và Acceptance Criteria.	Artifact ở IN_REVIEW; không tạo baseline, approval, xác nhận nghiệp vụ hoặc production readiness.

Senior Lens

Story không phải lời hứa hệ thống sẽ làm mọi thứ. Story chỉ giữ nhu cầu và giá trị. Acceptance Criteria mới đặt ranh giới hành vi quan sát được. Bằng chứng là AC-NF-SO-001-01 nói rõ trạng thái giữ lại là Draft, lỗi phải hiện ở dòng hàng, và không nói hệ thống phải tự phân bổ tồn. Phần không có bằng chứng không được suy diễn thành requirement.

ID phải ổn định khi nội dung thay đổi nhỏ để traceability còn hiệu lực. Nếu thay đổi làm khác persona, giá trị, phạm vi hoặc quyết định, tạo change record mới và đánh giá liệu cần User Story mới. Không đổi ID để che lịch sử; không dùng change history thay cho Acceptance Criteria.

Quick Reference

Kiểm tra anatomy	Đạt khi
Có thể đọc độc lập	Reviewer biết persona, nhu cầu, giá trị, điều kiện và kết quả không cần đoán.
Có thể kiểm thử	Mỗi Acceptance Criterion có đầu vào, hành động và kết quả quan sát được.
Có thể truy vết	TR-NF-SO-001 nối nguồn mô phỏng, story và toàn bộ criteria.
Có thể kiểm tra thay đổi	CHG-NF-SO-001-001 ghi ngày, người ghi nhận, nội dung, lý do và ảnh hưởng.
Giữ đúng boundary	Nội dung chỉ là Nova Foods mô phỏng, dữ liệu tổng hợp; không khẳng định approval, baseline hay sẵn sàng production.

Core

Cổng chất lượng trước downstream review

Quality gate là bộ điều kiện kiểm tra tối thiểu trước khi chuyển artifact sang người xem xét tiếp theo. Gate không phải phê duyệt, baseline, xác nhận đúng nghiệp vụ, xác nhận tuân thủ, hay sẵn sàng production. Bằng chứng: toàn corpus đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; IN_REVIEW không đồng nghĩa APPROVED hoặc BASELINED.

Output cần chuyển review	Điều kiện đạt gate	Bằng chứng bắt buộc	Không được suy diễn
User story	Có actor, mục tiêu, giá trị; phạm vi đủ rõ để reviewer hỏi và phản biện	Canonical ID đã đăng ký; nguồn đầu vào; owner; status IN_REVIEW; change-history entry	User story đã được Business Owner chấp thuận
Acceptance criteria	Mỗi tiêu chí kiểm tra được bằng quan sát hoặc dữ liệu; không mâu thuẫn user story	Liên kết user story; điều kiện đầu vào; kết quả mong đợi; nhãn Verification required nếu chưa xác minh	Tiêu chí đủ để release hoặc production
Traceability record	Liên kết nguồn, user story, acceptance criteria còn nguyên ID; không có liên kết mồ côi	ID nguồn canonical; ID đích canonical; lý do liên kết; ngày 2026-08-07 theo Asia/Ho_Chi_Minh	Liên kết là xác nhận pháp lý, kế toán, bảo mật hoặc vận hành

Gate đạt khi mọi trường bắt buộc có giá trị, ID giữ nguyên dạng canonical, nguồn được phân loại đúng, giả định được gắn nhãn, và lịch sử thay đổi nêu rõ nội dung sửa cùng lý do. Gate không đạt nếu thiếu nguồn, thay ID, dùng dữ liệu thật, biến giả định thành fact, hoặc ghi trạng thái cao hơn IN_REVIEW.

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

flowchart TB
    A[BA soạn hoặc cập nhật output] --> B{Loại output?}

    B -->|User story| US["Kiểm tra: actor, mục tiêu, giá trị, phạm vi;<br/>canonical ID, nguồn, owner, status IN_REVIEW"]
    B -->|Acceptance criteria| AC["Kiểm tra: quan sát hoặc dữ liệu kiểm chứng được, không mâu thuẫn;<br/>liên kết user story, đầu vào, kết quả;<br/>nhãn Verification required nếu chưa xác minh"]
    B -->|Traceability record| TR["Kiểm tra: ID nguồn và đích canonical, lý do liên kết;<br/>ngày 2026-08-07 theo Asia/Ho_Chi_Minh;<br/>liên kết nguyên vẹn, không mồ côi"]

    US --> X
    AC --> X
    TR --> X

    X["Kiểm tra chung: mọi trường bắt buộc có giá trị;<br/>mọi ID liên quan giữ nguyên dạng canonical;<br/>nguồn phân loại đúng, giả định có nhãn;<br/>change history nêu nội dung sửa và lý do"] --> G{Đạt toàn bộ điều kiện gate?}

    G -->|Có| R["Ready for downstream review<br/>status vẫn IN_REVIEW"]
    R --> V[Reviewer xem xét]
    R -.-> L["Giới hạn: đạt gate không đồng nghĩa approval, baseline,<br/>xác nhận đúng nghiệp vụ, tuân thủ<br/>hoặc production readiness"]

    G -->|Không| F["Không đạt: thiếu trường, nguồn hoặc nhãn giả định;<br/>phân loại nguồn sai; change history thiếu nội dung sửa hoặc lý do;<br/>mâu thuẫn; đổi ID; dùng dữ liệu thật;<br/>biến giả định thành fact; status cao hơn IN_REVIEW"]
    F --> D[Sửa artifact]
    D --> B

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. Corpus có status IN_REVIEW, version v0.9.0, locale vi-VN, timezone Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND.

Current Behavior: BA chuyển user story và acceptance criteria khi câu chữ đã viết xong, nhưng không có điều kiện chung kiểm tra traceability, giả định, và change history.

Underlying Need: Reviewer cần biết artifact nào đủ thông tin để review mà không nhầm việc “được chuyển review” với “được phê duyệt”.

Options:
1. Chuyển mọi bản nháp sang review.
2. Chỉ chuyển artifact sau quality gate tối thiểu.
3. Gắn APPROVED khi gate đạt.

Decision Criteria: Giữ traceability; không tạo approval ngầm định; phát hiện thiếu nguồn sớm; không vượt thẩm quyền Business Owner, Legal Owner, Accounting Owner, Security, Architect hoặc QA.

Decision: Chọn phương án 2. Dùng trạng thái diễn đạt Ready for downstream review; status quản trị vẫn IN_REVIEW.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì metadata, ID, liên kết và lịch sử thay đổi. Reviewer chỉ xem xét nội dung trong phạm vi vai trò. Không vai trò nào được suy ra approval từ gate.

Artifact: Với user story có canonical ID đã đăng ký trong TRACEABILITY_ID_REGISTRY, BA chỉ chuyển review khi có liên kết tới nguồn canonical, acceptance criteria mang cùng ngữ cảnh, và dòng change history ghi ngày 2026-08-07. Nếu quy tắc liên quan thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc hóa đơn chưa được xác minh từ nguồn chính thức hiện hành, artifact phải ghi Verification required.

Consequence if Wrong: Reviewer có thể review bản thiếu nguồn; team có thể hiểu sai giả định thành quy tắc ERP; trạng thái review có thể bị hiểu nhầm thành approval, baseline hoặc quyền triển khai production.

Senior Lens

Gate tốt kiểm tra khả năng review, không kiểm tra tính đúng cuối cùng. Hai việc khác nhau: BA kiểm tra artifact có đủ cấu trúc, bằng chứng và traceability; đúng nghiệp vụ hoặc hợp pháp cần người có thẩm quyền xác minh. Khi nguồn canonical mâu thuẫn, dừng chuyển review nội dung kết luận; giữ mâu thuẫn trong artifact và escalation theo vai trò phù hợp.

Quick Reference

Quy tắc	Áp dụng
Ready for downstream review	Nhãn sẵn sàng để reviewer nhận artifact
IN_REVIEW	Status hiện hành, không phải approval
Verification required	Dùng khi fact pháp lý, kế toán, thuế, privacy, food-safety hoặc vận hành chưa được xác minh
Change history bắt buộc	Mọi sửa đổi phải ghi cái gì đổi, vì sao đổi, ngày theo Asia/Ho_Chi_Minh
Không vượt gate	Không dùng APPROVED, BASELINED, compliant, production-ready, hoặc user-approved

7. Who consumes those outputs?

Core

User story là mô tả nhu cầu theo góc nhìn người dùng. Acceptance criteria là điều kiện kiểm tra được để xác định nhu cầu đó có đạt hay không. Hai output này không tự tạo quyết định; chúng làm test basis (cơ sở để thiết kế và đánh giá kiểm thử), thiết kế và ưu tiên nhất quán.

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi tên, quy trình và dữ liệu dưới đây là dữ liệu tổng hợp. Status corpus là IN_REVIEW, version v0.9.0, ngày 2026-08-07; không suy ra baseline, approval hay quyền triển khai production.

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

flowchart TB
    BA["BA"] --> OUT["User story + Acceptance criteria"]

    OUT --> DEV["Developer"]
    OUT --> QA["QA"]
    OUT --> ARC["Architect"]
    OUT --> PO["PM/Product Owner"]
    OUT --> BO["Business Owner"]
    OUT --> OPS["Operations"]
    OUT --> SO["Specialist owner"]

    DEV --> DESIGN["Build/design input"]
    QA --> TEST["Test basis<br/>(cơ sở để thiết kế và đánh giá kiểm thử)"]
    ARC --> ARCH["Architecture fit"]
    PO --> PRIORITY["Priority/scope input"]
    BO --> VALUE["Business value input"]
    OPS --> RUN["Operational fit"]
    SO --> DOMAIN["Domain validation input"]

    OUT -.-> LIMIT["Cung cấp input/test basis<br/>Không biểu thị approval hoặc quyết định triển khai"]

Applied

Facts: BA tạo user story mô phỏng US-INV-001 về ghi nhận lô hàng thành phẩm và acceptance criteria kiểm tra mã lô, ngày sản xuất, trạng thái hàng. ID chỉ được dùng nếu đã đăng ký trong TRACEABILITY_ID_REGISTRY; không được tự tạo ID thay thế.

Current Behavior: Mỗi vai trò đọc cùng artifact nhưng dùng cho mục đích khác. Developer cần biết phải xây gì; QA cần biết phải chứng minh gì; Business Owner cần biết giá trị nghiệp vụ có được phản ánh không. Nếu dùng cùng câu chữ cho các quyết định khác nhau mà thiếu ngữ cảnh, team có thể coi giả định là quy tắc bắt buộc.

Underlying Need: Handoff phải nêu rõ người nhận dùng output nào, giới hạn dùng và kết quả họ cần tạo. Lý do: user story không thay thế thiết kế kỹ thuật, test case, quyết định nghiệp vụ, quy trình vận hành hay kết luận pháp lý.

Consumer	Output được dùng	Cách tiêu thụ	Kết quả họ tạo hoặc cập nhật
Developer	User story, acceptance criteria, liên kết rule/data liên quan	Tách hành vi cần xây thành UI, API, validation, xử lý lỗi và dữ liệu lưu trữ	Thiết kế kỹ thuật, code, ghi chú giới hạn triển khai
QA	Acceptance criteria, ví dụ dữ liệu, quy tắc nghiệp vụ được liên kết	Chuyển điều kiện chấp nhận thành test scenario, test case, dữ liệu kiểm thử và expected result	Test basis, test cases, defect hoặc kết quả kiểm thử
Architect	User story, acceptance criteria phi chức năng nếu có, liên kết dữ liệu/tích hợp	Đánh giá hành vi có phù hợp kiến trúc, phân quyền, tích hợp và ranh giới hệ thống không	Quyết định kiến trúc hoặc yêu cầu làm rõ kiến trúc
PM/Product Owner	User story, business value, acceptance criteria	So sánh giá trị, phạm vi và độ sẵn sàng để xếp thứ tự backlog	Ưu tiên backlog, quyết định phạm vi release trong thẩm quyền
Business Owner	User story, mục tiêu nghiệp vụ, acceptance criteria nghiệp vụ	Kiểm tra nhu cầu mô tả đúng kết quả nghiệp vụ mong muốn	Xác nhận hoặc yêu cầu sửa diễn giải nghiệp vụ trong phạm vi thẩm quyền
Operations	User story, luồng ngoại lệ, acceptance criteria liên quan vận hành	Kiểm tra người vận hành có thể thực hiện, xử lý lỗi và tra cứu thông tin cần thiết không	Phản hồi về quy trình vận hành, đào tạo, hỗ trợ và kiểm soát ngoại lệ
Specialist owner	Story và criteria thuộc chuyên môn như kế toán, pháp lý, privacy, an toàn thực phẩm, bảo mật	Kiểm tra nội dung chuyên ngành có bị diễn giải sai hay vượt thẩm quyền không	Kết luận chuyên môn, yêu cầu Verification required, hoặc điều kiện kiểm soát

Options: Có thể gửi một bản story chung không phân vai trò, hoặc gửi cùng story kèm bảng tiêu thụ output. Bản chung ngắn hơn nhưng không chỉ ra ranh giới quyết định. Bảng tiêu thụ tăng vài dòng nhưng chặn hiểu lầm “QA phê duyệt nghiệp vụ” hoặc “Developer tự quyết quy tắc kế toán”.

Decision Criteria: Chọn cách bàn giao khi mỗi vai trò xác định được: input nhận, mục đích sử dụng, output phải tạo, và giới hạn thẩm quyền. Tiêu chí này dựa trên bằng chứng rằng các vai trò tạo output khác nhau từ cùng user story.

Decision: Dùng một user story và acceptance criteria làm nguồn chung, kèm mapping consumer theo bảng trên. Không nhân bản rule vào code note, test case hay ticket mà mất liên kết canonical.

Authority: BA duy trì traceability và làm rõ cấu trúc artifact. Developer không quyết định quy tắc nghiệp vụ; QA không quyết định ưu tiên; Architect không tự xác nhận nghĩa vụ pháp lý; specialist owner không tự đổi phạm vi product. Nội dung thuế, kế toán, dữ liệu cá nhân, hóa đơn, an toàn thực phẩm phải giữ nhãn Verification required nếu chưa có xác minh từ nguồn chính thức hiện hành và owner có thẩm quyền.

Artifact: User story, acceptance criteria, liên kết tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY khi các artifact đó chứa mục liên quan. Không suy diễn rằng liên kết tồn tại nghĩa là nội dung đã được phê duyệt.

Consequence if Wrong: Developer có thể build hành vi khác ý định; QA chỉ kiểm tra happy path; Architect phát hiện tích hợp muộn; Operations nhận quy trình không chạy được; specialist owner phát hiện rủi ro chuyên môn sau khi build.

Senior Lens

Một output tốt không phải output mà mọi người “đều hiểu giống nhau” ngay lập tức. Output tốt cho phép từng vai trò tạo ra quyết định hoặc artifact đúng phạm vi, rồi giữ được truy vết ngược về cùng nhu cầu. Cùng acceptance criterion “hệ thống lưu mã lô” có nghĩa khác nhau theo consumer: Developer cần kiểu dữ liệu và validation; QA cần input và expected result; Operations cần biết khi mã lô không đọc được; specialist owner an toàn thực phẩm cần đánh giá tính phù hợp chuyên môn. Khác cách dùng không phải mâu thuẫn; thiếu ranh giới mới là mâu thuẫn.

Quick Reference

Output	Consumer chính	Không thay thế
User story	PM/Product Owner, Business Owner, Developer	Quyết định kiến trúc, quy định pháp lý, thiết kế chi tiết
Acceptance criteria	QA, Developer, Operations	Toàn bộ test plan hoặc hướng dẫn vận hành đầy đủ
Liên kết business rule	Business Owner, QA, specialist owner	Kết luận kế toán, pháp lý hoặc compliance chưa xác minh
Liên kết data dictionary	Developer, QA, Architect	Schema vật lý hoặc cấu hình production
Traceability link	BA, PM/Product Owner, QA	Approval, baseline hoặc production authorization

Core

Trong Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, mỗi đầu ra User Story và Acceptance Criteria là bằng chứng để ra quyết định, không phải lệnh phê duyệt. IN_REVIEW, v0.9.0, ngày 2026-08-07 nghĩa là nội dung còn có thể đổi; không vai trò nào được suy ra đã phê duyệt, baseline hoặc cho phép production.

Consumer	Có thể quyết định	Bằng chứng cần có	Phải escalation khi
Developers	Ước lượng, chia nhỏ công việc, xác định khả thi kỹ thuật trong phạm vi story	User Story có actor, mục tiêu, phạm vi; Acceptance Criteria có điều kiện kiểm tra; tham chiếu đúng CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY nếu có	Criterion mâu thuẫn rule; thiếu dữ liệu đầu vào/đầu ra; cần đổi kiến trúc, API, quyền truy cập hoặc cơ chế bảo mật
QA	Thiết kế test basis, test case và xác định điều kiện pass/fail	Acceptance Criteria kiểm chứng được; dữ liệu mẫu tổng hợp; trạng thái, ngoại lệ, quy tắc tính toán được nêu rõ	Không xác định được kết quả mong đợi; criterion không đo được; rule nghiệp vụ có hai cách hiểu
Architect	Chọn hoặc bác bỏ hướng kỹ thuật cấp kiến trúc	Ràng buộc tích hợp, dữ liệu, hiệu năng, bảo mật, khả dụng; tác động liên hệ thống	Story đòi thay đổi kiến trúc, mô hình dữ liệu canonical, tích hợp, phân quyền hoặc rủi ro bảo mật
PM/Product Owner	Sắp thứ tự ưu tiên, quản lý phạm vi release, chấp nhận rủi ro kế hoạch	Giá trị nghiệp vụ, dependency, ước lượng, mức sẵn sàng của Acceptance Criteria	Có xung đột ưu tiên, phạm vi vượt release, dependency chưa giải quyết hoặc thay đổi làm mất giá trị mục tiêu
Business Owner	Xác nhận ý nghĩa nghiệp vụ và trade-off vận hành trong mô phỏng	Mục tiêu nghiệp vụ, Current Behavior, Underlying Need, tác động người dùng, hậu quả nếu chọn sai	Cần đổi chính sách nghiệp vụ, ngưỡng quyết định, quyền phê duyệt hoặc ưu tiên kinh doanh
Operations	Đánh giá khả năng vận hành, hỗ trợ sự cố và kiểm soát chuyển đổi	Luồng vận hành, trạng thái lỗi, thông tin cần tra cứu, ảnh hưởng dữ liệu và thời gian xử lý	Thiếu cách xử lý lỗi, thiếu khả năng truy vết, tăng tải hỗ trợ hoặc tạo rủi ro gián đoạn
Specialist owners	Kết luận trong vùng chuyên môn: kế toán, pháp lý, dữ liệu cá nhân, an toàn thực phẩm, bảo mật	Nguồn chính thức, rule liên quan, loại dữ liệu, báo cáo hoặc chứng từ bị ảnh hưởng	Story diễn giải nghĩa vụ pháp lý, kế toán, thuế, dữ liệu cá nhân, truy xuất nguồn gốc hoặc compliance mà chưa có xác minh chủ sở hữu chuyên môn

Quy tắc bằng chứng: BA nối mỗi quyết định với artifact canonical, ID ổn định và nguồn phân loại đúng. Ví dụ, thay đổi trường dữ liệu phải đối chiếu CANONICAL_DATA_DICTIONARY; thay đổi logic nghiệp vụ phải đối chiếu CANONICAL_BUSINESS_RULES; không dùng ghi chú họp hoặc suy đoán làm nguồn chân lý thay thế.

Escalation không phải lỗi giao tiếp. Escalation xảy ra khi người nhận đầu ra phải quyết định ngoài thẩm quyền, khi bằng chứng mâu thuẫn, hoặc khi quyết định có thể tạo tác động pháp lý, kế toán, bảo mật, kiến trúc hay vận hành. BA ghi vấn đề, bằng chứng, lựa chọn và người có thẩm quyền; BA không tự thay kết luận chuyên môn.

Common Handoff Misunderstandings And Exact Clarification Questions

Handoff là chuyển giao output giữa vai trò. Lỗi thường không nằm ở user story (câu chuyện người dùng) hay acceptance criteria (tiêu chí chấp nhận) đơn lẻ, mà ở cách người nhận suy diễn phần chưa được ghi. Với Nova Foods Trading & Manufacturing mô phỏng, chỉ dùng dữ liệu tổng hợp, không vai trò nào được biến suy diễn thành quy tắc, thiết kế hay phê duyệt.

Hiểu nhầm khi bàn giao	Dấu hiệu trong artifact	Rủi ro	Câu hỏi làm rõ phải ghi nguyên văn	Escalation
Developer hiểu “phê duyệt” là một nút đổi trạng thái	User story chỉ ghi “quản lý phê duyệt phiếu điều chỉnh tồn kho”	Bỏ kiểm tra quyền, lý do, thời điểm, audit trail	“Trạng thái nào được phép chuyển sang APPROVED, ai có quyền chuyển, và hệ thống phải lưu những trường bằng chứng nào?”	Business Owner quyết định quy trình; Architect quyết định audit và phân quyền kỹ thuật
QA hiểu ví dụ là toàn bộ luật	Acceptance criteria chỉ có một ví dụ lượng điều chỉnh 10	Không test số âm, bằng 0, vượt tồn khả dụng, thao tác lặp	“Ví dụ 10 là giá trị minh họa hay ngưỡng nghiệp vụ? Hãy nêu tập giá trị hợp lệ, không hợp lệ và kết quả mong đợi cho từng tập.”	Business Owner xác nhận luật; QA giữ test basis
Architect hiểu tích hợp đã được quyết định	Story nói “gửi dữ liệu sang kế toán” nhưng không có hợp đồng giao tiếp	Tự chọn API, batch, đồng bộ hoặc bất đồng bộ	“Hệ thống đích, sự kiện kích hoạt, dữ liệu tối thiểu, thời hạn xử lý, cơ chế xử lý lỗi và chủ sở hữu giao diện là gì?”	Architect và specialist owner của hệ thống đích
PM/Product Owner hiểu estimate là cam kết phạm vi	Developer ước lượng theo acceptance criteria hiện có	Phát sinh phạm vi ngầm sau sprint	“Estimate này bao gồm chính xác acceptance criteria, quy tắc và dependency nào; nội dung nào đang là giả định cần quyết định trước khi cam kết?”	PM/Product Owner quản lý phạm vi; Business Owner quyết định ưu tiên
Business Owner hiểu “lưu dữ liệu” là đủ cho truy vết	Story không nêu ai sửa, sửa gì, khi nào, lý do	Không điều tra được chênh lệch kho	“Khi sửa hoặc hủy giao dịch, cần giữ giá trị trước và sau, người thực hiện, thời điểm, lý do và liên kết chứng từ nào?”	Operations owner, specialist owner; cần Legal/Accounting owner nếu diễn giải nghĩa vụ
Operations hiểu điều kiện bình thường cũng áp dụng khi mất kết nối	Story không mô tả ngoại lệ thiết bị quét mã hoặc mạng kho	Nhân viên dừng xử lý hoặc tạo giao dịch trùng	“Khi thiết bị quét hoặc kết nối thất bại, nhân viên dùng quy trình thay thế nào, ai đối soát, và khi khôi phục hệ thống xử lý bản ghi trùng ra sao?”	Operations owner quyết định vận hành; Architect quyết định cơ chế kỹ thuật
Specialist owner hiểu trường dữ liệu có nghĩa hiển nhiên	Field ghi Lot Number nhưng không có định nghĩa, nguồn tạo, định dạng	Nhầm lô sản xuất, lô nhà cung cấp, hoặc mã truy xuất	“Lot Number là định danh do hệ thống nào tạo, có duy nhất theo phạm vi nào, định dạng nào, và được sửa sau khi ghi nhận không?”	Specialist owner; đối chiếu CANONICAL_DATA_DICTIONARY
BA hiểu tham chiếu nguồn là bằng chứng quyết định	Artifact gắn URL pháp lý nhưng không có owner kết luận áp dụng	Biến nguồn tham khảo thành yêu cầu bắt buộc	“Yêu cầu này là giả định dự án hay yêu cầu đã được chủ sở hữu pháp lý, kế toán hoặc an toàn thực phẩm xác minh? Bằng chứng xác minh nằm tại artifact nào?”	Legal, Accounting hoặc domain owner; giữ nhãn Verification required đến khi có bằng chứng

Cầu nối suy luận: câu mơ hồ không cho biết điều kiện, dữ liệu, kết quả và thẩm quyền. Thiếu một trong bốn phần này, mỗi vai trò sẽ điền phần trống theo chuyên môn riêng. Vì vậy BA phải ghi câu hỏi cụ thể vào luồng làm rõ, liên kết lại user story và acceptance criteria; không tự chốt thay Business Owner, Architect, Operations hay specialist owner.

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

flowchart TB
    A[User story và acceptance criteria] --> B{Đủ điều kiện, dữ liệu,<br/>kết quả, thẩm quyền?}
    B -- Có --> C[Đủ cơ sở bàn giao:<br/>không biến suy diễn thành quy tắc,<br/>thiết kế hoặc phê duyệt]
    B -- Không --> D[BA ghi câu hỏi làm rõ nguyên văn]
    D --> E{Loại quyết định<br/>hoặc xác minh?}

    E -- Quy trình, luật,<br/>ưu tiên nghiệp vụ --> F[Business Owner quyết định]
    E -- Phạm vi, giả định<br/>trước cam kết --> G[PM/Product Owner quản lý<br/>phạm vi và cam kết]
    E -- Tập giá trị, kết quả<br/>nghiệp vụ --> H[Business Owner xác nhận luật;<br/>QA duy trì test basis<br/>và kiểm tra độ bao phủ]
    E -- Kiến trúc, tích hợp,<br/>audit, phân quyền kỹ thuật --> I[Architect quyết định<br/>hướng kỹ thuật]
    E -- Quy trình khi lỗi thiết bị<br/>hoặc mất kết nối --> J[Operations owner quyết định<br/>quy trình vận hành]
    E -- Nghĩa, nguồn, định dạng<br/>hoặc phạm vi dữ liệu --> K[Domain hoặc specialist owner<br/>xác định nghĩa dữ liệu]
    E -- Nghĩa vụ pháp lý<br/>hoặc kế toán --> L[Legal hoặc Accounting owner<br/>xác minh áp dụng]

    F --> M[Có quyết định hoặc<br/>xác minh ghi nhận?]
    G --> M
    H --> M
    I --> M
    J --> M
    K --> M
    L --> M

    M -- Có --> N[Cập nhật user story và acceptance criteria;<br/>liên kết câu hỏi, câu trả lời,<br/>owner và quyết định truy vết]
    M -- Không --> O[Giữ giả định hoặc nhãn<br/>Verification required;<br/>không ghi như quyết định đã chốt]
    O --> A
    N --> A

Không dùng câu “hệ thống xử lý phù hợp”, “có quyền hợp lệ”, “gửi thành công” hoặc “theo quy định” nếu chưa có tiêu chí kiểm chứng. Thay bằng điều kiện quan sát được, kết quả mong đợi, bằng chứng cần lưu và owner quyết định. Trạng thái artifact Nova Foods hiện là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; nội dung không tạo baseline, approval hay quyết định production.

8. Detailed Worked Example

Core

Ví dụ này dùng Nova Foods Trading & Manufacturing, mô phỏng giáo dục, dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. “Fact” là sự kiện hoặc dữ liệu có nguồn xác định. “Current Behavior” là cách quy trình đang vận hành trước thay đổi. BA tách hai phần vì mong muốn của người dùng không tự chứng minh hệ thống hiện làm gì.

Applied

Kịch bản thống nhất: Nhân viên kho nhận lô nguyên liệu bột cacao cho kho nguyên liệu. Bộ phận QC cần chặn nhập kho khả dụng khi chưa có kết quả kiểm tra chất lượng.

Trường kịch bản	Giá trị mô phỏng
Tổ chức	Nova Foods Trading & Manufacturing
Kho nhận hàng	Kho nguyên liệu RM-HCM-01
Nguyên liệu	Bột cacao, mã hiển thị RM-COCOA-01
Nhà cung cấp	Green Bean Ingredients Co., dữ liệu tổng hợp
Phiếu mua hàng	PO-2026-0807-014
Lần nhận hàng	GRN-2026-0807-006
Lô nhà cung cấp	GBI-COC-260801-A
Số lượng nhận	500 kg
Ngày sản xuất	2026-08-01
Hạn dùng	2027-08-01
Thời điểm nhận	2026-08-07 09:15
Người nhận	Nhân viên kho mô phỏng WH-01
Trạng thái kiểm tra QC lúc nhận	Chưa có kết quả
Phân loại nguồn	Project assumption; Verification required với Business Owner và Quality Owner trước production

Facts

Fact	Bằng chứng mô phỏng	Diễn giải BA
Phiếu mua hàng yêu cầu 500 kg bột cacao	PO-2026-0807-014 ghi số lượng đặt 500 kg	Nhận hàng phải đối chiếu với chứng từ mua, không suy ra số lượng từ lời nói kho.
Lô có mã lô, ngày sản xuất và hạn dùng	Nhãn lô mô phỏng GBI-COC-260801-A, 2026-08-01, 2027-08-01	Ba dữ liệu này là dữ liệu truy vết lô; thiếu chúng, người dùng không phân biệt được hàng nào đã nhận.
QC chưa trả kết quả tại thời điểm nhận	Không có bản ghi kết quả QC trong dữ liệu kịch bản lúc 2026-08-07 09:15	“Chưa có kết quả” khác “không cần kiểm tra”. BA không được biến khoảng trống dữ liệu thành kết luận nghiệp vụ.
Kho cần biết vị trí vật lý hàng đang chờ	Hàng được dỡ tại khu vực chờ kiểm tra của RM-HCM-01	Hệ thống cần biểu diễn tồn kho chờ kiểm tra riêng với tồn kho có thể cấp phát.
Nguyên liệu có thể đi vào sản xuất thực phẩm	Tên nguyên liệu trong kịch bản là bột cacao	Bối cảnh này tạo nhu cầu truy vết để phân tích tiếp. Không phải kết luận tuân thủ pháp luật hay quy định an toàn thực phẩm.

Current Behavior

Hiện tại, nhân viên kho nhận hàng bằng bảng tính cục bộ. Sau khi đếm đủ 500 kg, nhân viên ghi một dòng nhận hàng và tăng tồn kho tổng của RM-COCOA-01. Bảng tính không có trường trạng thái QC bắt buộc, không tách lượng “chờ QC” khỏi lượng “có thể dùng”, và không kiểm tra trùng mã lô trong cùng lần nhận.

Bước hiện tại	Vai trò	Dữ liệu dùng	Kết quả hiện tại	Lỗ hổng quan sát được
1. Đối chiếu số lượng	Nhân viên kho	PO-2026-0807-014, hàng thực nhận	Xác nhận 500 kg	Không ghi nhận trạng thái QC cùng giao dịch nhận.
2. Ghi nhận bảng tính	Nhân viên kho	Mã hàng, số lượng, mã lô	Tăng tồn kho tổng thêm 500 kg	Tồn kho tổng không nói hàng đã đạt QC hay chưa.
3. Gửi mẫu kiểm tra	Nhân viên kho, QC	Mã lô nhà cung cấp	QC nhận thông tin qua trao đổi thủ công	Không có liên kết hệ thống giữa lần nhận và kết quả QC.
4. Cấp phát nguyên liệu	Điều phối sản xuất	Tồn kho tổng của RM-COCOA-01	Có thể thấy đủ 500 kg	Người cấp phát không nhìn thấy cảnh báo hàng đang chờ QC.

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

flowchart TB
    A[Nhận 500 kg bột cacao] --> B[Nhân viên kho: Đếm và đối chiếu PO-2026-0807-014]
    B --> C[Nhân viên kho: Nhập mã lô]
    C --> D[Không kiểm tra trùng mã lô trong cùng lần nhận]
    C --> E[Nhân viên kho: Ghi bảng tính cục bộ]
    E --> F[Tăng tồn kho tổng RM-COCOA-01]
    E --> G[Nhân viên kho: Gửi thông tin lô cho QC thủ công]
    G --> H[Trao đổi thủ công: không liên kết hệ thống lần nhận và kết quả QC]
    G --> I[QC: Chưa có kết quả tại thời điểm nhận]
    F --> K[Điểm hội tụ: tồn kho tổng không có trạng thái QC]
    I --> K
    K --> J[Điều phối sản xuất: Xem tồn kho tổng]
    J --> L[Không phân biệt chờ QC và có thể dùng]

Cầu nối suy luận: fact “QC chưa có kết quả” kết hợp với current behavior “tăng tồn kho tổng” cho thấy hệ thống hiện không mang thông tin trạng thái chất lượng đến người cấp phát. Đây là quan sát từ kịch bản mô phỏng, chưa là yêu cầu, quy tắc được phê duyệt, quyết định vận hành hoặc xác nhận tuân thủ.

Senior Lens

Không gọi mã lô là “đã truy xuất được” chỉ vì kho có ghi mã lô. Truy vết chỉ hữu ích khi mã lô liên kết được với lần nhận, số lượng, vị trí, trạng thái và các giao dịch sau đó. Với kịch bản này, bằng chứng hiện chỉ xác nhận bảng tính có mã lô; khả năng liên kết end-to-end cần được kiểm tra trong artifact sau.

Quick Reference

Phân biệt	Câu hỏi kiểm tra
Fact	Dữ liệu hoặc sự kiện nào chứng minh điều này?
Current Behavior	Người dùng đang làm gì, bằng công cụ nào, và hệ thống đang tạo kết quả nào?
Project assumption	Điều nào mới là giả định học liệu, chưa được owner xác nhận?
Verification required	Ai phải xác minh trước khi biến nội dung thành yêu cầu hoặc quy tắc vận hành?

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp. Kịch bản: nhân viên kho nhận 480 thùng NF-MILK-1L tại kho WH-HCM-01, nhưng số lượng thực nhận thấp hơn đơn mua. Mục tiêu BA: biến quan sát vận hành thành user story và acceptance criteria có thể kiểm thử, không tự quyết định cấu hình ERP.

Bước	Nội dung hoàn chỉnh	Bằng chứng hoặc suy luận
Facts	Đơn mua PO-SIM-20260807-001 đặt 500 thùng NF-MILK-1L; nhà cung cấp mô phỏng SUP-SIM-001; kho nhận WH-HCM-01; phiếu giao mô phỏng DN-SIM-20260807-014 ghi 480 thùng; người nhận ghi nhận lúc 2026-08-07 10:15:00 theo Asia/Ho_Chi_Minh.	Chênh lệch số lượng = 500 - 480 = 20 thùng. Dữ kiện chứng minh có khác biệt giữa đơn mua và nhận hàng.
Current Behavior	Nhân viên kho nhập 500 thùng vì màn hình nhận hàng tự sao chép số lượng từ đơn mua. Sau đó nhân viên gửi email tự do cho mua hàng về chênh lệch 20 thùng. Không có mã trạng thái, lý do, liên kết chứng từ hoặc hàng đợi xử lý trong ERP.	Tồn kho hệ thống tăng 500, tồn kho thực tăng 480. Email nằm ngoài dữ liệu giao dịch nên không tạo truy vết ERP.
Underlying Need	Kho cần ghi nhận số thực nhận tại thời điểm nhận. Mua hàng cần thấy chênh lệch để xử lý với nhà cung cấp. Kế toán chỉ cần dữ liệu nhận hàng đã được kiểm soát làm đầu vào đối chiếu, không tự suy diễn nghĩa vụ thanh toán.	Nếu hệ thống giữ 500 thay vì 480, số liệu tồn kho sai 20 thùng; các bước mua hàng và kế toán dùng dữ liệu sai.
Options	O1: luôn tự điền số lượng đơn mua. O2: cho nhập số thực nhận, cảnh báo chênh lệch nhưng vẫn hoàn tất không trạng thái. O3: cho nhập số thực nhận; khi khác số lượng đơn mua, tạo trạng thái QTY_VARIANCE, bắt buộc lý do và gửi tác vụ cho mua hàng.	O1 giữ lỗi hiện tại. O2 ghi nhận sự kiện nhưng thiếu kiểm soát xử lý. O3 giữ số thực, phân biệt ngoại lệ và tạo truy vết.
Decision Criteria	DC-01: tồn kho phải phản ánh số thực nhận. DC-02: chênh lệch phải truy vết được tới đơn mua và phiếu giao. DC-03: kho không được tự quyết tranh chấp nhà cung cấp. DC-04: luồng phải kiểm thử được bằng dữ liệu đầu vào và trạng thái đầu ra.	Bốn tiêu chí xuất phát trực tiếp từ chênh lệch 20 thùng, nhu cầu phân vai và yêu cầu test basis.
Decision	Khuyến nghị O3. Khi receivedQty != orderedQty, ERP lưu số thực nhận, đặt trạng thái QTY_VARIANCE, yêu cầu varianceReason, tạo tác vụ mua hàng. Đây là khuyến nghị BA trong artifact IN_REVIEW, chưa là quyết định được ủy quyền.	O3 thỏa DC-01 đến DC-04; O1 không thỏa DC-01; O2 không thỏa đầy đủ DC-02 và DC-03.
Authority	Business Owner quyết định chấp nhận quy trình ngoại lệ. Procurement Owner quyết định mã lý do và cách xử lý nhà cung cấp. Accounting Owner xác nhận cách dùng dữ liệu nhận hàng cho đối chiếu. Principal IT Business Analyst / Technical Curriculum Author chỉ ghi nhận traceability.	Các quyết định này ảnh hưởng vận hành và kế toán; không thuộc thẩm quyền tự phê duyệt của tác giả học liệu.
Artifact	User story, acceptance criteria, quy tắc dự kiến và payload minh họa dưới đây. Liên kết quản trị dùng CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY; các artifact này đều IN_REVIEW, v0.9.0, ngày 2026-08-07.	Artifact biến nhu cầu thành đầu vào có cấu trúc cho thiết kế và kiểm thử; không tạo baseline hay approval.
Consequence if Wrong	Nếu lưu 500 thùng, tồn kho báo cao 20 thùng. Nếu không có QTY_VARIANCE, mua hàng không có hàng đợi xử lý. Nếu kho được phép tự đóng ngoại lệ, phân tách trách nhiệm bị mờ. Nếu diễn đạt đây là quyết định đã phê duyệt, governance của corpus bị sai.	Mỗi hậu quả đối ứng trực tiếp với DC-01 đến DC-04 và giới hạn Authority.

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

flowchart TB
    T["Luồng dự kiến — IN_REVIEW"]

    subgraph WH["Nhân viên kho"]
        A["Mở PO-SIM-20260807-001"]
        B["Nhập receivedQty thực nhận"]
        V["Nhập varianceReason"]
    end

    subgraph ERP["ERP"]
        C0{"receivedQty >= 0?"}
        X0["Từ chối hoàn tất<br/>Lỗi: receivedQty không hợp lệ"]
        C{"receivedQty khác orderedQty?"}
        E["Hiển thị yêu cầu varianceReason"]
        F{"varianceReason có giá trị?"}
        X["Từ chối hoàn tất<br/>Lỗi: varianceReason bắt buộc"]
        S1["Lưu receivedQty thực nhận"]
        D["Đặt trạng thái RECEIVED"]
        S2["Lưu receivedQty thực nhận<br/>Liên kết PO-SIM-20260807-001<br/>và DN-SIM-20260807-014"]
        Q["Đặt trạng thái QTY_VARIANCE"]
        I["Cập nhật tồn kho theo receivedQty"]
        G["Tạo tác vụ cho Procurement Owner"]
    end

    subgraph PROC["Procurement Owner"]
        N["Nhận tác vụ xử lý ngoại lệ"]
        PC["Xử lý ngoại lệ với nhà cung cấp"]
    end

    subgraph GOV["Ranh giới governance — IN_REVIEW"]
        BO["Business Owner xác nhận<br/>quy trình ngoại lệ và quyền chuyển RESOLVED"]
        PO["Procurement Owner xác nhận<br/>danh mục mã lý do và cách xử lý"]
        AO["Accounting Owner xác nhận<br/>cách dùng dữ liệu nhận hàng cho đối chiếu"]
        PR["Quy tắc dự kiến:<br/>Nhân viên kho không được chuyển<br/>QTY_VARIANCE sang RESOLVED"]
    end

    T --> A
    A --> B
    B --> C0
    C0 -->|Không| X0
    X0 -->|Sửa và nhập lại| B
    C0 -->|Có| C
    C -->|Không| S1
    S1 --> D
    D --> I
    C -->|Có| E
    E --> V
    V --> F
    F -->|Không| X
    X -->|Bổ sung lý do| E
    F -->|Có| S2
    S2 --> Q
    Q --> I
    Q --> G
    G --> N
    N --> PC

    Q -. quy tắc dự kiến .-> PR
    PR -. chờ xác nhận .-> BO
    E -. danh mục mã lý do .-> PO
    S2 -. dữ liệu nhận hàng .-> AO

User story dự kiến

Với vai trò Nhân viên kho, tôi muốn nhập số lượng thực nhận khác số lượng đơn mua và ghi lý do chênh lệch, để tồn kho phản ánh hàng thực nhận và mua hàng có dữ liệu xử lý ngoại lệ.

ID tham chiếu dự kiến	Acceptance criteria
AC-SIM-PO-001	Với orderedQty = 500 và receivedQty = 480, khi nhân viên kho lưu nhận hàng, hệ thống phải lưu receivedQty = 480; không được thay bằng orderedQty = 500.
AC-SIM-PO-002	Với receivedQty != orderedQty, khi nhân viên kho chưa nhập varianceReason, hệ thống phải từ chối hoàn tất nhận hàng và hiển thị lỗi trường bắt buộc.
AC-SIM-PO-003	Với orderedQty = 500, receivedQty = 480 và varianceReason = SHORT_DELIVERY, khi lưu thành công, hệ thống phải tạo trạng thái QTY_VARIANCE và liên kết PO-SIM-20260807-001, DN-SIM-20260807-014.
AC-SIM-PO-004	Với trạng thái QTY_VARIANCE, hệ thống phải tạo một tác vụ xử lý cho vai trò Procurement Owner; nhân viên kho không có quyền tự đổi trạng thái sang RESOLVED.

{
  "purchaseOrderId": "PO-SIM-20260807-001",
  "deliveryNoteId": "DN-SIM-20260807-014",
  "warehouseId": "WH-HCM-01",
  "itemCode": "NF-MILK-1L",
  "orderedQty": 500,
  "receivedQty": 480,
  "uom": "CASE",
  "varianceReason": "SHORT_DELIVERY",
  "receiptStatus": "QTY_VARIANCE",
  "receivedAt": "2026-08-07T10:15:00+07:00",
  "currency": "VND"
}

Quy tắc dự kiến: receivedQty phải lớn hơn hoặc bằng 0; nếu receivedQty khác orderedQty, varianceReason bắt buộc và receiptStatus phải là QTY_VARIANCE. Đây là giả định dự án mô phỏng, cần Business Owner và Procurement Owner xác nhận trước khi ghi vào CANONICAL_BUSINESS_RULES.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi tên, ID, số lượng, giá và dữ liệu dưới đây là tổng hợp. Scenario SCN-US-001: nhân viên Kho thành phẩm ghi nhận xuất kho cho đơn bán SO-NF-20260807-001, gồm 120 thùng sản phẩm FG-NF-CHILI-500G, từ kho WH-HCM-FG-01. Giá trị thương mại mô phỏng: 72.000 VND/thùng, tổng 8.640.000 VND. Case không xác nhận cấu hình ERP thực, nghĩa vụ pháp lý, hạch toán hay tuân thủ truy xuất nguồn gốc.

Thành phần	ID/giá trị đầy đủ	Phân loại nguồn	Ý nghĩa trong scenario
User story	US-NF-INV-001	Artifact học liệu, IN_REVIEW	Người dùng kho cần xác nhận xuất kho theo lô để Sales biết hàng có thể giao
Acceptance criteria	AC-NF-INV-001 đến AC-NF-INV-005	Artifact học liệu, IN_REVIEW	Điều kiện quan sát được để kiểm tra story
Sales order	SO-NF-20260807-001	Dữ liệu mô phỏng	Nhu cầu xuất 120 thùng
Warehouse	WH-HCM-FG-01	Dữ liệu mô phỏng	Kho thành phẩm tại TP.HCM
Product	FG-NF-CHILI-500G	Dữ liệu mô phỏng	Sốt ớt Nova Foods 500 g
Inventory lot 1	LOT-NF-CHILI-20260720-A	Dữ liệu mô phỏng	Tồn khả dụng 80 thùng, hạn dùng 2027-07-20
Inventory lot 2	LOT-NF-CHILI-20260725-B	Dữ liệu mô phỏng	Tồn khả dụng 70 thùng, hạn dùng 2027-07-25
Shipment	SHP-NF-20260807-001	Dữ liệu mô phỏng	Chứng từ giao nội bộ được tạo sau khi xuất hợp lệ
Rule catalog	CANONICAL_BUSINESS_RULES	Kế hoạch canonical, IN_REVIEW	Nơi phải đăng ký rule trước baseline
Data dictionary	CANONICAL_DATA_DICTIONARY	Kế hoạch canonical, IN_REVIEW	Nơi phải định nghĩa trường và kiểu dữ liệu
Traceability registry	TRACEABILITY_ID_REGISTRY	Kế hoạch canonical, IN_REVIEW	Nơi phải duy trì liên kết ID

Quy tắc đề xuất, chưa phải quyết định được thẩm quyền phê chuẩn:

Rule ID	Quy tắc đầy đủ	Bằng chứng trong case	Trạng thái
BR-NF-INV-001	Hệ thống chỉ cho xác nhận xuất khi tổng quantityToIssue theo từng productId không vượt tổng availableQuantity của các lô được chọn trong cùng warehouseId.	Đơn cần 120; hai lô có 80 + 70 = 150 thùng khả dụng.	Recommendation
BR-NF-INV-002	Mỗi dòng xuất phải lưu salesOrderId, warehouseId, productId, lotId, quantityIssued, issuedAt, issuedByUserId.	Không lưu lotId thì không nối được 120 thùng đã xuất với hai lô cụ thể.	Recommendation
BR-NF-INV-003	Với cùng sản phẩm và kho, hệ thống đề xuất lô có expiryDate sớm hơn trước; người dùng chỉ đổi lô khi ghi overrideReason.	2027-07-20 sớm hơn 2027-07-25; đề xuất lần lượt 80, rồi 40 thùng.	Recommendation
BR-NF-INV-004	Một lần xác nhận xuất thành công phải giảm tồn khả dụng và tạo shipment trong cùng giao dịch hoặc cơ chế bù trừ tương đương.	Chỉ giảm tồn mà không tạo shipment tạo lệch trạng thái đơn; chỉ tạo shipment mà không giảm tồn tạo tồn ảo.	Recommendation

Payload kiểm thử cho API nội bộ giả định POST /api/v1/inventory/issues. Đây là ví dụ đặc tả dữ liệu, không xác nhận API production hay kiến trúc được phê duyệt.

{
  "issueId": "ISS-NF-20260807-001",
  "salesOrderId": "SO-NF-20260807-001",
  "warehouseId": "WH-HCM-FG-01",
  "issuedAt": "2026-08-07T14:30:00+07:00",
  "issuedByUserId": "USR-NF-WH-014",
  "lines": [
    {
      "productId": "FG-NF-CHILI-500G",
      "lotId": "LOT-NF-CHILI-20260720-A",
      "quantityIssued": 80,
      "uom": "CTN"
    },
    {
      "productId": "FG-NF-CHILI-500G",
      "lotId": "LOT-NF-CHILI-20260725-B",
      "quantityIssued": 40,
      "uom": "CTN"
    }
  ]
}

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

flowchart TB
    A["Nhân viên kho<br/>Gửi POST /api/v1/inventory/issues<br/>ISS-NF-20260807-001"] --> B["ERP<br/>Kiểm tra SO, kho, sản phẩm và dữ liệu bắt buộc"]
    B --> C{"ERP<br/>Dữ liệu hợp lệ?"}

    C -- "Không" --> R0["ERP<br/>Từ chối: dữ liệu không hợp lệ"]
    C -- "Có" --> D{"INV<br/>Mọi dòng có lotId?"}
    D -- "Không" --> R1["INV<br/>Từ chối: thiếu lô xuất"]
    D -- "Có" --> E{"INV<br/>Số lượng từng dòng<br/>không vượt tồn lô?"}
    E -- "Không" --> R2["INV<br/>Từ chối: vượt tồn lô"]
    E -- "Có" --> F{"INV<br/>Tổng xuất theo sản phẩm<br/>không vượt 150 CTN khả dụng?"}
    F -- "Không" --> R3["INV<br/>Từ chối: vượt tồn khả dụng"]
    F -- "Có" --> G{"INV<br/>Có đổi thứ tự lô đề xuất?<br/>Ví dụ: lô B 70 + lô A 50"}
    G -- "Không<br/>Lô A 80 + lô B 40" --> TX1
    G -- "Có" --> H{"INV<br/>Có overrideReason?"}
    H -- "Không" --> R4["INV<br/>Từ chối: yêu cầu lý do đổi thứ tự lô"]
    H -- "Có" --> TX1

    R0 --> REND["ERP<br/>Không giảm tồn<br/>Không tạo shipment"]
    R1 --> REND
    R2 --> REND
    R3 --> REND
    R4 --> REND
    REND --> RWH["Nhân viên kho<br/>Nhận lỗi; không nhận trạng thái thành công"]

    subgraph TX["Ranh giới giao dịch hoặc cơ chế bù trừ tương đương"]
        TX1["INV<br/>Giảm tồn trong giao dịch<br/>hoặc giảm tồn kèm cơ chế bù trừ"] --> TX2["SHP<br/>Tạo SHP-NF-20260807-001"]
        TX2 --> TX3{"SHP<br/>Tạo shipment thành công?"}
        TX3 -- "Có" --> TX4["ERP<br/>Hoàn tất giảm tồn và shipment"]
        TX3 -- "Không" --> TX5["INV<br/>Rollback hoặc chạy cơ chế bù trừ"]
        TX5 --> TX6{"INV<br/>Tồn đã được khôi phục?"}
    end

    TX4 --> S["ERP<br/>Lô A còn 0 CTN<br/>Lô B còn 30 CTN<br/>Shipment đã tạo"]
    S --> OK["Nhân viên kho<br/>Nhận xác nhận xuất thành công"]

    TX6 -- "Có" --> FAIL["ERP<br/>Lô A còn 80 CTN<br/>Lô B còn 70 CTN<br/>Không có shipment"]
    FAIL --> NOOK["Nhân viên kho<br/>Không nhận trạng thái thành công"]

    TX6 -- "Không hoặc chưa xác nhận" --> RISK["ERP<br/>Không xác nhận tồn đã khôi phục<br/>Không có shipment"]
    RISK --> NOOK2["Nhân viên kho<br/>Không nhận trạng thái thành công"]

Test scenario	Input	Kết quả mong đợi	Liên kết
TS-NF-INV-001	Payload trên, tổng xuất 120 thùng	Thành công; lô A còn 0, lô B còn 30; tạo SHP-NF-20260807-001.	US-NF-INV-001, AC-NF-INV-001, BR-NF-INV-001, BR-NF-INV-002, BR-NF-INV-004
TS-NF-INV-002	Lô A 80, lô B 71; tổng 151 thùng	Từ chối; không giảm tồn; không tạo shipment; báo vượt tồn khả dụng 150 thùng.	AC-NF-INV-002, BR-NF-INV-001, BR-NF-INV-004
TS-NF-INV-003	Xuất 120 thùng nhưng thiếu lotId ở một dòng	Từ chối; không giảm tồn; không tạo shipment; báo thiếu lô xuất.	AC-NF-INV-003, BR-NF-INV-002
TS-NF-INV-004	Chọn lô B 120 thùng khi lô A còn 80; không có overrideReason	Từ chối; yêu cầu lý do đổi thứ tự lô.	AC-NF-INV-004, BR-NF-INV-003
TS-NF-INV-005	Giảm tồn thành công nhưng tạo shipment lỗi giả lập	Hoàn tác giảm tồn hoặc chạy cơ chế bù trừ; không trả trạng thái thành công.	AC-NF-INV-005, BR-NF-INV-004

Phân biệt thẩm quyền: bảng rule và payload là recommendation của BA để review. Không có Authorized Decision trong case vì CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY đều IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Business Owner phải quyết định ưu tiên lô; Architect quyết định giao dịch hoặc bù trừ; QA Owner xác nhận test basis; Legal/Food-safety Owner phải xác minh yêu cầu truy xuất nếu dùng ngoài học liệu.

9. Related Concepts & Dependencies

Core

Dependency (phụ thuộc) là quan hệ trong đó artifact này cần thông tin, định danh hoặc quyết định từ artifact khác để giữ đúng nghĩa. Traceability (truy vết) là khả năng lần ngược từ nội dung đang đọc đến nguồn quản trị của nó. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, user story không tự tạo lại business rule, định nghĩa dữ liệu, tên template hay ID. Nó chỉ tham chiếu nguồn canonical (nguồn chân lý được kiểm soát).

Nhóm phụ thuộc	Nguồn canonical	Dùng trong user story và acceptance criteria	Không được làm
Cấu trúc chapter	/01-curriculum/CHAPTER_MANIFEST.md	Xác định chapter, filename và dependency liên chapter	Tự đổi tên file hoặc tạo chapter ID khác
Template	/01-curriculum/TEMPLATE_MANIFEST.md	Xác định template dự kiến cho user story, acceptance criteria, traceability	Chép nội dung template thành nguồn chuẩn thứ hai
Định danh bền vững	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Kiểm tra format, tính duy nhất, vòng đời US-NF-INV-001, AC-NF-INV-001	Tái dùng ID cho nghĩa khác hoặc tự cấp ID chưa đăng ký
Quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Tham chiếu BR-NF-INV-001 đến BR-NF-INV-004 khi criterion cần rule	Viết lại rule rồi để hai bản lệch nhau
Dữ liệu logic	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tham chiếu khái niệm lotId, số lượng xuất, tồn khả dụng	Tự định nghĩa kiểu dữ liệu, độ dài, tính bắt buộc khác nguồn canonical
Nguồn nghiên cứu	/00-research/00_SOURCE_MAP.md	Giữ phân loại nguồn và giới hạn sử dụng chuẩn, pháp lý, good practice	Biến nguồn học liệu thành quyết định pháp lý hoặc production

Quy tắc ngắn: artifact tiêu thụ ghi ID + đường dẫn canonical + mục đích dùng; artifact sở hữu mới sửa nội dung chuẩn. Điều này giảm hai bản cùng nói về một rule nhưng cho hai kết quả khác nhau.

Applied

Facts: US-NF-INV-001 mô tả Warehouse Staff xuất 120 thùng theo lô. AC-NF-INV-001 đến AC-NF-INV-005 dùng các rule BR-NF-INV-001 đến BR-NF-INV-004. Payload mô phỏng có lotId; test scenario dùng TS-NF-INV-001 đến TS-NF-INV-005. Các ID và catalog canonical đều IN_REVIEW, v0.9.0, ngày 2026-08-07.

Current Behavior: Chapter này giữ liên kết tới registry, rule catalog và data dictionary. Chapter không chép lại định nghĩa đầy đủ của “tồn khả dụng”, “ưu tiên lô”, lotId hay cơ chế hoàn tác giao dịch.

Underlying Need: Người đọc cần biết một acceptance criterion dựa vào đâu, nhưng chỉ một artifact được quyền là nguồn chân lý cho mỗi loại nội dung.

Options: (1) Chép toàn bộ rule và field vào user story; (2) chỉ ghi ID mà không nêu nguồn; (3) ghi ID, nguồn canonical và vai trò phụ thuộc.

Decision Criteria: Giữ một nguồn sửa đổi; người mới lần được nguồn; thay đổi rule phát hiện được nơi bị ảnh hưởng; không ngầm biến nội dung IN_REVIEW thành approved.

Decision: Chọn phương án 3. US-NF-INV-001 tham chiếu BR-NF-INV-001 đến BR-NF-INV-004 tại /01-curriculum/CANONICAL_BUSINESS_RULES.md; field lotId tham chiếu /01-curriculum/CANONICAL_DATA_DICTIONARY.md; ID tham chiếu /01-curriculum/TRACEABILITY_ID_REGISTRY.md.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết và metadata. Business Owner quyết định rule nghiệp vụ. Architect quyết định cơ chế giao dịch hoặc bù trừ. QA Owner xác nhận test basis. Legal, Accounting, Food-safety Owner xác minh nội dung thuộc thẩm quyền. Không có approval hay baseline được ghi nhận.

Artifact: /02-handbook/07-user-stories-and-acceptance-criteria.md là artifact tiêu thụ; các catalog trong bảng Core là artifact sở hữu nội dung canonical.

Consequence if Wrong: Nếu BR-NF-INV-003 bị chép thành rule khác trong user story, Warehouse Staff có thể bị yêu cầu chọn lô sai thứ tự; test vẫn có thể pass theo bản sao sai; defect chỉ lộ khi tích hợp hoặc vận hành mô phỏng.

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

flowchart TB
    CR["Tiêu chí<br/>Một nguồn sửa đổi<br/>Truy nguồn được<br/>Phát hiện ảnh hưởng<br/>Không biến IN_REVIEW thành approved"]
    DEC{"Chọn cách liên kết<br/>US, AC, TS, rule, field"}
    O1["(1) Chép rule và field<br/>vào user story"]
    O2["(2) Chỉ ghi ID<br/>không nêu nguồn"]
    O3["(3) Ghi ID, nguồn canonical<br/>và vai trò phụ thuộc"]

    CR --> DEC
    DEC -->|"Loại"| O1
    DEC -->|"Loại"| O2
    DEC -->|"Chọn"| O3

    subgraph CAN["Nguồn canonical"]
        direction TB
        META["IN_REVIEW · v0.9.0 · 2026-08-07<br/>Không có approval hoặc baseline"]
        IDR["/01-curriculum/TRACEABILITY_ID_REGISTRY.md"]
        BR["/01-curriculum/CANONICAL_BUSINESS_RULES.md"]
        DD["/01-curriculum/CANONICAL_DATA_DICTIONARY.md"]

        META --> IDR
        META --> BR
        META --> DD
    end

    subgraph CHAPTER["Artifact tiêu thụ"]
        direction TB
        CH["/02-handbook/07-user-stories-and-acceptance-criteria.md"]
        US["US-NF-INV-001<br/>Warehouse Staff xuất 120 thùng theo lô<br/>IN_REVIEW · v0.9.0 · 2026-08-07"]
        AC["AC-NF-INV-001 đến AC-NF-INV-005<br/>IN_REVIEW · v0.9.0 · 2026-08-07"]
        TS["TS-NF-INV-001 đến TS-NF-INV-005<br/>Payload có lotId<br/>IN_REVIEW · v0.9.0 · 2026-08-07"]

        CH -->|"chứa"| US
        CH -->|"chứa"| AC
        CH -->|"chứa"| TS
    end

    O3 -->|"dùng"| IDR
    O3 -->|"dùng"| BR
    O3 -->|"dùng"| DD

    IDR -->|"quản lý ID US, AC, TS"| US
    IDR -->|"quản lý ID US, AC, TS"| AC
    IDR -->|"quản lý ID US, AC, TS"| TS
    IDR -->|"quản lý ID BR"| BR

    BR -->|"US tham chiếu BR-NF-INV-001 đến BR-NF-INV-004"| US
    BR -->|"là basis của AC"| AC
    DD -->|"định nghĩa field lotId"| TS

    subgraph AUTH["Authority"]
        direction TB
        PBA["Principal IT Business Analyst /<br/>Technical Curriculum Author"]
        BO["Business Owner"]
        ARCH["Architect"]
        QA["QA Owner"]
        VERIFY["Legal, Accounting, Food-safety Owner"]
        TX["Cơ chế giao dịch hoặc bù trừ<br/>Chapter không định nghĩa"]

        PBA -->|"duy trì liên kết và metadata"| CH
        BO -->|"quyết định rule nghiệp vụ"| BR
        ARCH -->|"quyết định"| TX
        QA -->|"xác nhận test basis"| TS
        VERIFY -->|"xác minh nội dung thuộc thẩm quyền"| CH
    end

    COPY["Chép BR-NF-INV-003 khác<br/>vào user story"]
    WRONG["Warehouse Staff chọn lô<br/>sai thứ tự"]
    PASS["Test vẫn có thể pass<br/>theo bản sao sai"]
    DEFECT["Defect lộ khi tích hợp<br/>hoặc vận hành mô phỏng"]

    O1 --> COPY
    COPY --> WRONG
    COPY --> PASS
    WRONG --> DEFECT
    PASS --> DEFECT

Senior Lens

Phụ thuộc upstream là nguồn phải tồn tại trước khi story có nghĩa: registry cấp nghĩa cho ID, rule catalog cấp nghĩa cho rule, data dictionary cấp nghĩa cho field. Phụ thuộc downstream là artifact dùng story làm đầu vào, như test basis và đặc tả giao diện hoặc API khi được tạo ở chapter phù hợp. Evidence bridge: AC-NF-INV-003 nói thiếu lotId phải bị từ chối; vì criterion kiểm tra field, định nghĩa field phải nằm ở data dictionary, không nằm trong prose của criterion.

Silent change (thay đổi im lặng) là sửa rule, field, ID hoặc filename mà không tăng version, không ghi lịch sử và không rà ảnh hưởng. Nếu lotId đổi thành optional trong data dictionary nhưng AC-NF-INV-003 không được rà lại, criterion và dữ liệu canonical mâu thuẫn. Nếu ID bị tái dùng, một link có thể trỏ sang nghĩa khác. Nếu filename canonical đổi không cập nhật manifest, người đọc tìm sai artifact. Mọi thay đổi phải bắt đầu tại artifact sở hữu, giữ ID hoặc ghi mapping thay thế, rồi rà các artifact tiêu thụ trước khi mô tả thay đổi là hợp lệ.

Quick Reference

Cần ghi trong chapter tiêu thụ	Mẫu ghi đúng
Rule	BR-NF-INV-002 tại /01-curriculum/CANONICAL_BUSINESS_RULES.md
Data field	lotId tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md
ID governance	US-NF-INV-001 theo /01-curriculum/TRACEABILITY_ID_REGISTRY.md
Template location	Theo /01-curriculum/TEMPLATE_MANIFEST.md
Chapter/file control	Theo /01-curriculum/CHAPTER_MANIFEST.md

Không đổi canonical ID, filename, source classification hoặc nội dung nguồn từ chapter này. Nova Foods là case mô phỏng giáo dục; toàn bộ dữ liệu là tổng hợp; IN_REVIEW không phải baseline, approval hay xác nhận dùng production.

Core

Traceability là liên kết kiểm tra được giữa nhu cầu, yêu cầu, quy tắc, tiêu chí chấp nhận, dữ liệu/API và kiểm thử. Mục tiêu không phải chép lại nội dung nguồn. Mục tiêu là trả lời: hạng mục này tồn tại vì nhu cầu nào, bị ràng buộc bởi quy tắc nào, dùng dữ liệu nào, và được kiểm tra bằng test case nào.

Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. ID dưới đây là liên kết học liệu trong ví dụ; ID canonical phải đối chiếu /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Nội dung quy tắc canonical thuộc /01-curriculum/CANONICAL_BUSINESS_RULES.md; định nghĩa dữ liệu canonical thuộc /01-curriculum/CANONICAL_DATA_DICTIONARY.md.

Loại	ID	Liên kết đến	Mục đích kiểm tra
NEED	NEED-NF-001	REQ-NF-001	Nhu cầu nghiệp vụ gốc
REQ	REQ-NF-001	BR-NF-001, AC-NF-001, DATA-NF-001, API-NF-001, TC-NF-001	Yêu cầu hệ thống cần thực hiện
BR	BR-NF-001	REQ-NF-001, AC-NF-001, TC-NF-002	Quy tắc nghiệp vụ giới hạn cách hệ thống xử lý
AC	AC-NF-001	REQ-NF-001, BR-NF-001, TC-NF-001	Điều kiện chấp nhận được quan sát
DATA	DATA-NF-001	REQ-NF-001, API-NF-001, TC-NF-003	Trường dữ liệu, ý nghĩa, kiểu và ràng buộc logic
API	API-NF-001	REQ-NF-001, DATA-NF-001, TC-NF-003	Giao diện trao đổi dữ liệu
TC	TC-NF-001	AC-NF-001	Chứng minh tiêu chí chấp nhận đạt hoặc không đạt
TC	TC-NF-002	BR-NF-001	Chứng minh quy tắc được áp dụng
TC	TC-NF-003	DATA-NF-001, API-NF-001	Chứng minh dữ liệu và tích hợp đúng hợp đồng

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

flowchart TB
    NEED[NEED-NF-001<br/>Cần kiểm soát hạn dùng lô] --> REQ[REQ-NF-001<br/>ERP chặn xuất lô quá hạn]
    REQ --> BR[BR-NF-001<br/>Không xác nhận xuất khi expiry_date trước ngày xuất]
    REQ --> AC[AC-NF-001<br/>Hiện lỗi và không tạo xác nhận]
    BR --> AC
    REQ --> DATA[DATA-NF-001<br/>Lot.expiry_date]
    REQ --> API[API-NF-001<br/>POST /inventory-issues]
    DATA --> API
    REQ --> TC1[TC-NF-001]
    AC --> TC1
    BR --> TC2[TC-NF-002]
    DATA --> TC3[TC-NF-003]
    API --> TC3

Applied

Facts: Kho Nova Foods mô phỏng xuất lô LOT-SYN-20260807-01 có expiry_date tổng hợp là 2026-08-06. Người dùng tạo phiếu xuất ngày 2026-08-07, múi giờ Asia/Ho_Chi_Minh.

Current Behavior: Yêu cầu mới chỉ nói “hệ thống kiểm tra hạn dùng khi xuất kho”. Câu này chưa đủ để QA kết luận. Chưa nêu trường dữ liệu, thời điểm kiểm tra, phản hồi API, hay hành vi khi lô quá hạn.

Underlying Need: NEED-NF-001 là ngăn xuất lô quá hạn trong luồng kho mô phỏng. Bằng chứng suy luận: nếu hệ thống chỉ lưu hạn dùng nhưng vẫn xác nhận xuất, dữ liệu tồn kho có thể ghi nhận giao dịch trái với mục tiêu kiểm soát hạn dùng.

Options: Phương án 1 cảnh báo nhưng cho phép tiếp tục. Phương án 2 chặn xác nhận xuất. Phương án 3 bỏ kiểm tra tại ERP và để nhân viên tự kiểm tra.

Decision Criteria: Nhu cầu dùng từ “ngăn”; kết quả phải kiểm thử được; lỗi phải nhất quán giữa màn hình và API; không được tự suy diễn nghĩa vụ pháp lý hay cấu hình production.

Decision: Dùng Phương án 2 trong học liệu. REQ-NF-001: ERP không xác nhận phiếu xuất khi Lot.expiry_date < issue_date. BR-NF-001 là nguồn quy tắc; AC-NF-001 diễn đạt hành vi quan sát; DATA-NF-001 định nghĩa Lot.expiry_date; API-NF-001 mô tả phản hồi tích hợp; TC-NF-001 đến TC-NF-003 kiểm tra từng liên kết.

Authority: Business Owner xác nhận nhu cầu và quyết định nghiệp vụ. Data Owner xác nhận nghĩa trường expiry_date. Architect xác nhận hợp đồng API. QA xác nhận phạm vi test. Legal, Food-safety hoặc Compliance Owner phải xác minh nếu dự án biến ví dụ này thành yêu cầu tuân thủ thực tế.

Artifact: Ghi nội dung canonical tại /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Ghi ID, loại liên kết, trạng thái và lịch sử đổi tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md. User story chỉ tham chiếu ID, không sao chép quy tắc đầy đủ.

Consequence if Wrong: Nếu AC-NF-001 liên kết nhầm sang BR-NF-002, QA có thể test sai quy tắc nhưng vẫn báo đạt. Nếu DATA-NF-001 đổi tên trường im lặng, API có thể gửi dữ liệu rỗng hoặc dùng ngày sai. Nếu TC-NF-003 không nối với API, lỗi tích hợp không có bằng chứng truy vết.

Senior Lens

Không suy ra liên kết chỉ từ tên giống nhau. Mỗi liên kết cần lý do: REQ-NF-001 dùng BR-NF-001 vì quy tắc xác định điều kiện chặn; AC-NF-001 dùng TC-NF-001 vì test phải quan sát đúng thông báo và trạng thái không xác nhận; API-NF-001 dùng DATA-NF-001 vì hợp đồng API phải dùng định nghĩa dữ liệu thống nhất.

Một REQ có thể có nhiều AC và TC. Một BR có thể chi phối nhiều REQ. Không đảo chiều sở hữu: TC không trở thành nguồn định nghĩa BR; API không tự quyết định NEED. Khi nguồn canonical chưa có nội dung xác nhận, ghi Verification required, không nâng suy luận thành fact hay approval.

Quick Reference

Kiểm tra	Đạt khi
NEED đến REQ	Mỗi REQ có nhu cầu hoặc nguồn hợp lệ
REQ đến BR	REQ bị ràng buộc có ID BR rõ
REQ đến AC	AC mô tả kết quả quan sát được
REQ đến DATA/API	Có liên kết khi yêu cầu dùng dữ liệu hoặc tích hợp
AC/BR/DATA/API đến TC	Có test case chứng minh từng điều kiện áp dụng
Nguồn canonical	Nội dung đầy đủ chỉ nằm tại registry, rule catalog hoặc data dictionary phù hợp
Trạng thái	Mọi artifact hiện là IN_REVIEW, v0.9.0, ngày 2026-08-07; không phải baseline hay approval

Core

Phụ thuộc là quan hệ trong đó artifact sau dùng nội dung, định danh hoặc cấu trúc của artifact trước. Khi nguồn trước đổi, mọi liên kết sau phải được đánh giá lại; đây là lan truyền thay đổi (change propagation). Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; mọi artifact đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, không phải baseline hay xác nhận vận hành.

Thay đổi im lặng là sửa nội dung canonical nhưng không ghi lịch sử, không thông báo consumer và không đánh giá liên kết phụ thuộc. Hậu quả không nằm ở câu chữ đổi, mà ở việc các artifact sau vẫn diễn giải dữ liệu cũ. Ví dụ: đổi định nghĩa trường dữ liệu trong /01-curriculum/CANONICAL_DATA_DICTIONARY.md nhưng acceptance criteria vẫn kiểm tra định dạng cũ. Đội phát triển có thể xây đúng theo tiêu chí cũ, QA có thể kết luận sai theo test cũ, còn tích hợp có thể gửi dữ liệu không còn khớp hợp đồng API.

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

flowchart TB
    N[Nova Foods: mọi artifact đều IN_REVIEW<br/>v0.9.0, 2026-08-07<br/>chưa phải baseline hay xác nhận vận hành]
    N -. Phạm vi toàn sơ đồ .-> A

    A[Canonical artifact thay đổi] --> B{Đã ghi lịch sử, thông báo consumer<br/>và đánh giá liên kết phụ thuộc?}

    B -->|Có| C[Xác định artifact phụ thuộc và ảnh hưởng]
    C --> D[Cập nhật liên kết, AC, test basis,<br/>định nghĩa dữ liệu hoặc hợp đồng API]
    D --> E[Review theo thẩm quyền]
    E --> F[Artifact phụ thuộc đã đồng bộ]

    B -->|Không / thiếu một bước| G[Artifact sau tiếp tục dùng giả định cũ]
    G --> H[REQ, AC, định nghĩa dữ liệu,<br/>hợp đồng API hoặc TC lệch nhau]
    H --> I[Đội phát triển xây theo AC cũ<br/>nhưng sai canonical mới]
    H --> J[QA kết luận sai theo test cũ]
    H --> K[Tích hợp gửi dữ liệu không khớp<br/>hợp đồng API]
    H --> L[Mất traceability]

Applied

Mục	Nội dung
Facts	Một trường logic CustomerTaxCode trong /01-curriculum/CANONICAL_DATA_DICTIONARY.md được đổi mô tả từ “bắt buộc” sang “Verification required”. Acceptance criteria trong handbook vẫn nói hệ thống phải chặn lưu khi trường rỗng.
Current Behavior	Người viết user story dùng acceptance criteria cũ; QA tạo test case bắt buộc nhập; đội API giả định trường luôn có giá trị.
Underlying Need	Phân biệt quy tắc đã xác minh với giả định dự án. Từ điển dữ liệu là nguồn cho nghĩa và trạng thái trường; handbook không được tự giữ bản sao cạnh tranh.
Options	Giữ acceptance criteria cũ; tự sửa acceptance criteria mà không tham chiếu nguồn; ghi nhận thay đổi, đánh giá ảnh hưởng rồi cập nhật artifact bị ảnh hưởng.
Decision Criteria	Chọn phương án giữ đúng nguồn canonical, giữ traceability, không biến giả định thành nghĩa vụ pháp lý hoặc vận hành.
Decision	Dừng dùng tiêu chí “bắt buộc” cho đến khi nguồn canonical và thẩm quyền phù hợp xác nhận. Cập nhật acceptance criteria thành điều kiện có nhãn Verification required nếu còn cần nêu.
Authority	Principal IT Business Analyst / Technical Curriculum Author giữ liên kết và lịch sử. Business Owner xác nhận nhu cầu nghiệp vụ. Legal hoặc Accounting Owner xác nhận khi thay đổi liên quan nghĩa vụ pháp lý hoặc kế toán.
Artifact	Nguồn: /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Registry liên kết: /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Quy tắc nghiệp vụ, nếu có: /01-curriculum/CANONICAL_BUSINESS_RULES.md.
Consequence if Wrong	REQ có thể yêu cầu dữ liệu không còn được xác minh; AC và TC kiểm tra sai; API consumer xử lý sai dữ liệu rỗng; báo cáo truy vết không chứng minh được vì sao quyết định đổi.

Senior Lens

Không sửa im lặng để “đồng bộ nhanh”. Một thay đổi nhỏ có thể đổi nghĩa của nhiều loại liên kết: quy tắc nghiệp vụ đổi làm requirement lệch; requirement đổi làm acceptance criteria lệch; acceptance criteria đổi làm test case lệch; dữ liệu hoặc API đổi làm tích hợp lệch. Bằng chứng cho chuỗi này là mỗi artifact sau dùng artifact trước làm test basis hoặc nguồn diễn giải. Vì vậy, trước khi cập nhật nội dung phụ thuộc, phải xác định thay đổi thuộc loại nào: nghĩa dữ liệu, điều kiện nghiệp vụ, hành vi chức năng, giao diện API, hay tiêu chí kiểm thử.

Nếu không xác định được nguồn canonical hoặc thẩm quyền quyết định, giữ trạng thái IN_REVIEW, gắn Verification required, không nâng giả định thành quy tắc Nova Foods. Không thay ID, tên tệp hoặc phân loại nguồn chỉ để làm liên kết trông nhất quán; các giá trị đó do registry và manifest kiểm soát.

Quick Reference

Dấu hiệu	Điều bị vỡ nếu bỏ qua	Hành động tối thiểu
Đổi nghĩa trường dữ liệu	AC, API mapping, TC dùng nghĩa cũ	Kiểm tra /01-curriculum/CANONICAL_DATA_DICTIONARY.md và consumer
Đổi quy tắc nghiệp vụ	REQ và AC mâu thuẫn	Kiểm tra /01-curriculum/CANONICAL_BUSINESS_RULES.md
Đổi ID hoặc liên kết	Traceability đứt, không truy được nguồn	Kiểm tra /01-curriculum/TRACEABILITY_ID_REGISTRY.md
Đổi trạng thái nguồn pháp lý	Giả định cũ bị diễn đạt thành bắt buộc	Gắn Verification required; chuyển đúng owner
Không có lịch sử thay đổi	Không phân biệt được bản nào là căn cứ	Ghi thay đổi tại artifact kiểm soát, rồi đánh giá ảnh hưởng

10. Common Mistakes & Anti-patterns

Core

User story là mô tả nhu cầu theo góc nhìn người dùng; acceptance criteria là điều kiện quan sát và kiểm thử được để xác định hành vi đạt yêu cầu. Sai lầm thường gặp không nằm ở câu chữ ngắn hay dài, mà ở việc người đọc không thể xác định: ai làm gì, trong điều kiện nào, dữ liệu nào bị tác động, ai có quyền quyết định, và QA sẽ kiểm tra kết quả bằng cách nào.

Nhóm lỗi	Sai lầm cụ thể	Red flag quan sát được	Nguyên nhân gốc	Hành động sửa
Mơ hồ	Viết “hệ thống xử lý đơn hàng nhanh”	Không có ngưỡng thời gian, trạng thái đầu vào, kết quả đầu ra	Nhầm mong muốn chung với điều kiện kiểm thử	Hỏi rõ điểm bắt đầu, kết thúc, đơn vị đo, ngoại lệ; viết AC đo được
Thiếu thông tin	Story nêu tạo phiếu xuất kho nhưng không nêu lô hàng, số lượng, trạng thái tồn	QA phải tự đoán dữ liệu test; developer hỏi lại	BA tách story khỏi quy tắc và dữ liệu phụ thuộc	Liên kết requirement với /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/CANONICAL_DATA_DICTIONARY.md; ghi rõ dữ liệu bắt buộc
Claim sai thẩm quyền	Ghi “theo luật, bắt buộc khóa sửa hóa đơn” nhưng không có xác minh Legal hoặc Accounting	Không có nguồn chính thức, người quyết định, hoặc Verification required	BA biến giả định dự án thành nghĩa vụ pháp lý	Giữ là giả định; chuyển Legal Owner và Accounting Owner xác minh; không đưa thành AC bắt buộc trước khi có căn cứ
Dùng sai ký pháp	Gọi sơ đồ hoạt động PlantUML là BPMN	Sơ đồ không có phần tử BPMN 2.0.2 nhưng tài liệu tuyên bố là BPMN	Nhầm công cụ vẽ với chuẩn mô hình hóa	Đổi nhãn thành “PlantUML activity diagram”, hoặc lập BPMN đúng theo OMG BPMN 2.0.2
Đứt truy vết	AC tham chiếu “quy tắc tồn kho” không có ID, nguồn, hoặc artifact canonical	Không truy được từ AC về rule, data, test basis	Sao chép nội dung giữa tệp thay vì liên kết nguồn kiểm soát	Giữ nguyên ID canonical; kiểm tra /01-curriculum/TRACEABILITY_ID_REGISTRY.md; sửa liên kết trước khi sửa câu chữ
Gộp nhiều hành vi	Một story chứa tạo đơn, duyệt tín dụng, xuất kho, phát hành hóa đơn	Nhiều vai trò, nhiều trạng thái, nhiều lỗi có thể xảy ra trong một AC	Chia theo màn hình thay vì giá trị nghiệp vụ và rủi ro	Tách theo hành vi có thể kiểm thử độc lập; giữ liên kết nghiệp vụ giữa các story
Viết giải pháp thay nhu cầu	“Thêm nút màu xanh gọi API X”	Không nêu người dùng cần quyết định gì; API bị chốt khi chưa có Architect	Nhảy từ vấn đề sang thiết kế	Viết outcome nghiệp vụ trước; để kiến trúc và UI là quyết định của vai trò có thẩm quyền

Cảnh báo: Claim sai thẩm quyền có thể biến học liệu mô phỏng thành chỉ dẫn pháp lý, kế toán, an toàn thực phẩm hoặc production. Nova Foods là case mô phỏng, chỉ dùng dữ liệu tổng hợp. Ranh giới an toàn: gắn Verification required, giữ IN_REVIEW, chuyển đúng Legal Owner, Accounting Owner, Business Owner, Security hoặc Architect; không tự xác nhận tuân thủ.

Applied

Facts: Nova Foods mô phỏng có story: “Là nhân viên kho, tôi muốn xuất nguyên liệu cho lệnh sản xuất để sản xuất không bị gián đoạn.” AC đính kèm ghi: “Hệ thống tự chọn lô gần hết hạn và xuất kho đúng quy định.”

Current Behavior: Developer không biết “gần hết hạn” là bao nhiêu ngày, có được xuất lô bị khóa không, có cho phép số lượng xuất vượt tồn không. QA không tạo được expected result. Business Owner chưa xác nhận quy tắc chọn lô.

Underlying Need: Người dùng cần cấp nguyên liệu hợp lệ cho lệnh sản xuất, đồng thời giữ khả năng truy nguồn lô. Đây là nhu cầu; thuật toán chọn lô là cách đáp ứng, chưa tự là requirement.

Thành phần	Nội dung kiểm tra
Options	1. Chọn lô có hạn dùng sớm nhất. 2. Cho người dùng chọn lô. 3. Hệ thống gợi ý lô, người dùng xác nhận.
Decision Criteria	Có nguồn quy tắc nghiệp vụ; dữ liệu lot, hạn dùng, trạng thái lô tồn tại trong data dictionary; quyền override; khả năng kiểm thử; ảnh hưởng truy xuất lô
Decision	Chưa chọn option. Lý do: seed không cung cấp quy tắc Nova Foods đã được xác nhận cho thuật toán chọn lô. Ghi Verification required.
Authority	Business Owner xác nhận nhu cầu và ngoại lệ vận hành; Food-safety/domain owner xác nhận ngữ cảnh truy xuất; Architect xác nhận cách thực hiện; QA xác nhận testability.
Artifact	Story và AC trong /02-handbook/07-user-stories-and-acceptance-criteria.md; rule tại /01-curriculum/CANONICAL_BUSINESS_RULES.md; dữ liệu tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md; liên kết ID tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md.
Consequence if Wrong	Xuất nhầm lô, mất khả năng truy vết mô phỏng, test case mâu thuẫn, hoặc team triển khai thuật toán không có thẩm quyền quyết định.

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

flowchart TB
    A["Story nêu nhu cầu xuất nguyên liệu"] --> O["Đánh giá 3 option:<br/>1. Chọn lô có hạn dùng sớm nhất<br/>2. Người dùng chọn lô<br/>3. Hệ thống gợi ý, người dùng xác nhận"]
    O --> B{"Có rule canonical đã xác nhận<br/>về chọn lô?"}

    B -- "Không" --> D["Giữ Verification required<br/>và IN_REVIEW; chưa chọn option"]
    D --> E["Business Owner xác nhận theo evidence:<br/>quy tắc chọn lô, lô bị khóa,<br/>xuất vượt tồn và quyền override"]
    E --> F["Food-safety/domain owner xác nhận<br/>ngữ cảnh truy xuất lô"]
    F --> G{"Quyết định đã được ghi vào<br/>artifact canonical phù hợp?"}
    G -- "Không" --> R["Giữ Verification required<br/>và IN_REVIEW; không chốt hành vi"]
    G -- "Có" --> H

    B -- "Có" --> H["Đối chiếu<br/>CANONICAL_BUSINESS_RULES.md"]
    H --> I["Đối chiếu lot, hạn dùng, trạng thái lô<br/>trong CANONICAL_DATA_DICTIONARY.md"]
    I --> J["Đối chiếu ID và liên kết<br/>trong TRACEABILITY_ID_REGISTRY.md"]
    J --> T{"AC còn dùng<br/>“gần hết hạn”?"}
    T -- "Có" --> U{"Ý nghĩa “gần hết hạn”<br/>đã được xác nhận trong rule?"}
    U -- "Không" --> X["Giữ Verification required<br/>và IN_REVIEW; không chốt AC"]
    U -- "Có" --> K
    T -- "Không" --> K["Kiểm tra lô bị khóa, xuất vượt tồn,<br/>quyền override và ảnh hưởng truy xuất lô"]
    K --> Q["QA xác nhận khả năng kiểm thử"]
    Q --> L{"Đủ rule, dữ liệu, liên kết,<br/>ngoại lệ, quyền override,<br/>truy xuất lô và testability?"}

    L -- "Không" --> X
    L -- "Có" --> M["Chốt AC theo rule<br/>và dữ liệu canonical"]
    M --> N["Architect xác nhận cách thực hiện<br/>sau khi AC được chốt"]
    M -. "Nếu chốt sai" .-> Z["Xuất nhầm lô; mất khả năng truy vết;<br/>test case mâu thuẫn; hoặc triển khai<br/>quyết định không đúng thẩm quyền"]

Senior Lens

Không chữa mơ hồ bằng cách BA tự thêm quy tắc. Bằng chứng cần thiết là nguồn canonical, dữ liệu đủ nghĩa, và vai trò có thẩm quyền. Nếu thiếu một trong ba, AC có thể rõ về câu chữ nhưng vẫn sai về quyết định.

Không chữa traceability break bằng ID tự đặt hoặc đổi tên tệp. ID, filename, phân loại nguồn do manifest và registry kiểm soát. Sửa đúng là tìm artifact canonical, khôi phục liên kết, rồi đánh giá consumer như requirement, AC, test case và API mapping.

Quick Reference

Khi thấy	Kết luận làm việc	Sửa ngay
“nhanh”, “đúng”, “tự động”, “phù hợp”	Mơ hồ nếu không có điều kiện đo và nguồn nghĩa	Thêm điều kiện, dữ liệu, kết quả quan sát được
“theo luật” nhưng không có owner xác minh	Claim không được hỗ trợ	Gắn Verification required; chuyển đúng owner
Sơ đồ PlantUML bị gọi BPMN	Notation misuse	Đổi nhãn hoặc vẽ BPMN đúng chuẩn
QA hỏi expected result	AC thiếu test basis	Bổ sung precondition, action, expected result và ngoại lệ
Không lần được AC về rule hoặc data	Traceability break	Kiểm tra registry và artifact canonical

Core

[!WARNING] Rủi ro thật: User story sai có thể cho phép xuất kho lô đã bị chặn chất lượng, sai hạn dùng, hoặc sai chứng từ. Với Nova Foods Trading & Manufacturing là mô phỏng giáo dục, dữ liệu đều tổng hợp; tình huống vẫn mô tả hậu quả delivery có thể kiểm thử.

Cảnh báo chỉ dùng khi lỗi có thể gây mất kiểm soát nghiệp vụ, dữ liệu, tài chính, an toàn thực phẩm, bảo mật, hoặc phát hành sai. Không dùng cảnh báo cho lỗi câu chữ nhỏ. “Safe recovery boundary” là ranh giới phục hồi an toàn: dừng thao tác gây hại, giữ bằng chứng, sửa artifact có truy vết, rồi kiểm thử lại; không tự sửa dữ liệu production, không tự kết luận pháp lý, kế toán hay tuân thủ.

Tình huống Nova Foods mô phỏng	Dấu hiệu quan sát được	Thiệt hại thực tế có thể xảy ra	Phục hồi an toàn
Story xuất kho ghi “hệ thống kiểm tra lô hợp lệ”	Không có trạng thái lô, thời điểm kiểm tra, người chặn	Lô QC_HOLD có thể được chọn giao khách	Dừng test case phát hành; ghi rõ trạng thái kiểm soát cần xác nhận; liên kết lại story và acceptance criteria; QA kiểm thử trạng thái sau khi Business Owner xác nhận
Acceptance criteria cho hoàn tiền ghi “hoàn tiền nhanh”	Không có ngưỡng tiền, điều kiện, quyền phê duyệt	Nhân viên sai quyền có thể tạo giao dịch VND không hợp lệ	Khóa phạm vi tự động hóa trong backlog; yêu cầu Accounting Owner và Business Owner xác nhận rule; không suy diễn ngưỡng VND
Bảng ví dụ ghi “đã tuân thủ luật dữ liệu cá nhân”	Không có xác minh Legal Owner, không có nguồn quyết định	Nhóm delivery hiểu sai là compliance sign-off	Đổi thành Verification required; tách yêu cầu kỹ thuật khỏi kết luận pháp lý; escalation đến Legal Owner
Sơ đồ PlantUML bị gọi là BPMN	Không có ký hiệu BPMN 2.0.2 nhưng nhãn “BPMN”	Dev, QA hiểu sai event, gateway, trách nhiệm	Đổi nhãn thành “PlantUML activity diagram”; chỉ dùng BPMN khi mô hình đúng BPMN 2.0.2 và được kiểm tra ký pháp

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

flowchart TB
    A[Phát hiện story hoặc acceptance criteria có rủi ro] --> B{Có thể gây mất kiểm soát nghiệp vụ, dữ liệu, tài chính, an toàn thực phẩm, bảo mật hoặc phát hành sai?}

    B -- Không --> C[Sửa rõ artifact có truy vết]
    C --> Q[QA kiểm thử lại]
    Q --> R[Artifact đã làm rõ và kiểm thử lại]

    B -- Có --> D[Dừng thao tác hoặc test case gây hại]
    D --> E[Guardrail: không tự sửa dữ liệu production; không tự kết luận pháp lý, kế toán hoặc tuân thủ]
    E --> F[Giữ ID, phiên bản, bằng chứng và liên kết nguồn]
    F --> G{Rule cần Owner nào xác nhận?}

    G -- Nghiệp vụ --> H[Business Owner xác nhận rule]
    G -- Hoàn tiền hoặc ngưỡng VND --> I[Business Owner và Accounting Owner xác nhận rule]
    G -- Pháp lý hoặc tuân thủ --> J[Legal Owner xác nhận rule]

    H --> K{Approval đã được ghi nhận?}
    I --> K
    J --> K

    K -- Không --> L[Giữ Status IN_REVIEW và chờ Owner ghi nhận approval]
    L --> K
    K -- Có --> M[Cập nhật story và acceptance criteria có truy vết]
    M --> Q

Applied

Facts: Nova Foods mô phỏng có story US-INV-014: “Là nhân viên kho, tôi muốn chọn lô khi xuất kho để giao đúng hàng.” Acceptance criterion viết: “Chỉ hiển thị lô hợp lệ.”

Current Behavior: Dev diễn giải “hợp lệ” là tồn kho lớn hơn 0. QA tạo test chỉ kiểm tra số lượng. Không có kiểm tra QC_HOLD, hạn dùng, hoặc quyền override.

Underlying Need: Kho cần tránh chọn lô không được phép xuất. Đây là nhu cầu kiểm soát giao hàng, không phải yêu cầu “hiển thị danh sách lô” đơn thuần.

Options:

Phương án	Nội dung	Rủi ro
A	Giữ cụm “lô hợp lệ”	Mỗi nhóm tự định nghĩa khác nhau
B	BA tự định nghĩa mọi trạng thái lô	Vượt thẩm quyền chất lượng và vận hành
C	Ghi điều kiện cần xác nhận, chặn phát hành rule chưa xác nhận	Chậm refinement nhưng giữ kiểm soát

Decision Criteria: Chọn phương án giữ được traceability, không tạo rule không có thẩm quyền, cho QA viết test xác định, và không cho phép xuất kho theo giả định.

Decision: Chọn C. Cập nhật US-INV-014 thành: “Hệ thống chỉ cho phép chọn lô có trạng thái xuất kho được Business Owner và Quality Owner xác nhận.” Acceptance criteria phải dùng danh sách trạng thái từ nguồn canonical sau khi được ghi nhận; trước thời điểm đó gắn Verification required.

Authority: Business Owner xác nhận nhu cầu xuất kho; Quality Owner xác nhận trạng thái chất lượng; Architect xác nhận cơ chế kiểm soát; QA xác nhận khả năng kiểm thử. Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì artifact và traceability.

Artifact: Cập nhật trong /02-handbook/07-user-stories-and-acceptance-criteria.md; tham chiếu định danh và trạng thái từ /01-curriculum/TRACEABILITY_ID_REGISTRY.md, quy tắc từ /01-curriculum/CANONICAL_BUSINESS_RULES.md, dữ liệu trạng thái lô từ /01-curriculum/CANONICAL_DATA_DICTIONARY.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 test theo “tồn kho lớn hơn 0”, release có thể cho xuất lô bị giữ chất lượng. Ranh giới phục hồi: không sửa số liệu kho, không bỏ qua nhật ký, không đóng lỗi bằng diễn giải miệng; sửa acceptance criteria, xác nhận authority, rồi chạy lại test.

Senior Lens

Cảnh báo tốt nêu đủ ba phần: hành vi nguy hiểm, hậu quả, điểm dừng. Ví dụ: “Không chạy xuất kho tự động khi trạng thái lô chưa được xác nhận; có thể giao lô bị chặn; dừng tại bước chọn lô và chuyển Quality Owner.” Cảnh báo không thay thế requirement. Requirement vẫn phải nêu điều kiện, kết quả mong đợi, dữ liệu và authority.

Không viết “đã phê duyệt”, “đã tuân thủ”, “đúng luật”, “đạt chuẩn kế toán” nếu artifact chỉ có IN_REVIEW. Evidence bridge: nguồn quản trị xác nhận IN_REVIEW không đồng nghĩa APPROVED hay BASELINED; vì vậy câu khẳng định authority không có bằng chứng và phải bỏ hoặc đổi thành Verification required.

Quick Reference

Khi gặp	Làm ngay	Không làm
Rủi ro giao sai, mất dữ liệu, lộ dữ liệu, sai tiền	Dừng hành vi gây hại, giữ evidence, escalation đúng Owner	Tự tạo rule để “mở blocker”
Rule chưa được xác nhận	Gắn Verification required, giữ story ở IN_REVIEW	Gọi là approved hoặc compliant
Sơ đồ không phải BPMN	Gọi đúng là PlantUML activity diagram	Gắn nhãn BPMN 2.0.2
Acceptance criteria chưa test được	Bổ sung điều kiện, kết quả, dữ liệu và authority cần xác nhận	Đẩy QA tự suy diễn

Core

Năm lỗi khác nhau, không gộp thành “yêu cầu chưa rõ”. Mơ hồ (ambiguity) là một câu có nhiều cách hiểu hợp lý. Thiếu hoàn chỉnh (incompleteness) là thiếu điều kiện để xây dựng hoặc kiểm thử. Khẳng định thẩm quyền không có bằng chứng là gọi một giả định là quyết định, phê duyệt, quy định pháp lý hoặc baseline. Dùng sai ký pháp (notation misuse) là gắn tên chuẩn cho sơ đồ không tuân chuẩn đó. Đứt truy vết (traceability break) là không nối được yêu cầu với nguồn, quy tắc, tiêu chí chấp nhận và kiểm thử.

Loại lỗi	Red flag quan sát được	Nguyên nhân gốc	Sửa đúng
Mơ hồ	“Hệ thống kiểm tra tồn kho kịp thời”	Không định nghĩa thời điểm, dữ liệu, kết quả	Nêu sự kiện kích hoạt, nguồn tồn, ngưỡng, phản hồi
Thiếu hoàn chỉnh	Có luồng thành công, không có tồn kho âm hoặc lỗi kết nối	Viết theo màn hình, không theo biến thể nghiệp vụ	Bổ sung điều kiện trước, ngoại lệ, dữ liệu đầu ra, owner xử lý
Thẩm quyền không có bằng chứng	“Nova Foods đã phê duyệt quy tắc” nhưng không có approval reference	Nhầm IN_REVIEW với phê duyệt	Gắn nhãn giả định hoặc Verification required; chỉ rõ vai trò cần xác nhận
Dùng sai ký pháp	Gọi sơ đồ PlantUML activity là BPMN	Dùng tên chuẩn như nhãn trang trí	Gọi đúng loại sơ đồ; chỉ gọi BPMN khi tuân BPMN 2.0.2
Đứt truy vết	US-INV-014 không có nguồn, rule, acceptance criteria hoặc test basis	Sao chép story qua nhiều tệp	Khôi phục liên kết bằng ID canonical, không tạo ID thay thế

[!WARNING] Khẳng định sai thẩm quyền có thể biến học liệu mô phỏng thành chỉ dẫn vận hành hoặc pháp lý giả. Nova Foods là case mô phỏng, dữ liệu tổng hợp; IN_REVIEW v0.9.0 ngày 2026-08-07 không phải APPROVED hay BASELINED.

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

flowchart TB
    P["Phạm vi sơ đồ:<br/>Đứt truy vết và thẩm quyền không có bằng chứng<br/>Mơ hồ, thiếu hoàn chỉnh, dùng sai ký pháp: xem bảng năm lỗi"]

    P --> S["Nguồn / bằng chứng"]

    S --> QSR{"Có canonical ID và liên kết<br/>nguồn–quy tắc?"}
    QSR -->|Không| XSR["Đứt truy vết nguồn–quy tắc<br/>Khôi phục ID hoặc liên kết<br/>Owner: cần xác định"]
    XSR -->|Sau khi khôi phục| QSR
    QSR -->|Có| R["Quy tắc nghiệp vụ"]

    R --> QC{"Có tuyên bố về quyết định,<br/>phê duyệt, quy định pháp lý<br/>hoặc baseline?"}
    QC -->|Không| QRS
    QC -->|Có| CE{"Có evidence reference<br/>với canonical ID và liên kết?"}

    CE -->|Có| EV{"Evidence xác nhận đúng tuyên bố,<br/>đúng trạng thái và do vai trò<br/>có thẩm quyền ban hành?"}
    EV -->|Có| M["Tuyên bố có căn cứ"]
    M --> QRS
    EV -->|Không| N["Không đủ căn cứ<br/>Không ghi APPROVED hoặc BASELINED"]
    CE -->|Không| N

    N -->|Gắn nhãn| G["Giả định"]
    G --> QRS
    N -->|Cần xác minh| H{"Đã xác định vai trò<br/>có thẩm quyền xác nhận?"}

    H -->|Có| V["Verification required<br/>Owner: vai trò có thẩm quyền<br/>Không ghi APPROVED hoặc BASELINED"]
    V -->|Bổ sung evidence reference| CE

    H -->|Không| W["Verification required<br/>Owner: cần xác định<br/>Không ghi APPROVED hoặc BASELINED"]
    W -->|Xác định vai trò| H

    QRS{"Có canonical ID và liên kết<br/>quy tắc–user story?"}
    QRS -->|Không| XRS["Đứt truy vết quy tắc–user story<br/>Khôi phục ID hoặc liên kết<br/>Owner: cần xác định"]
    XRS -->|Sau khi khôi phục| QRS
    QRS -->|Có| U["User story"]

    U --> QUA{"Có canonical ID và liên kết<br/>user story–acceptance criteria?"}
    QUA -->|Không| XUA["Đứt truy vết story–acceptance criteria<br/>Khôi phục ID hoặc liên kết<br/>Owner: cần xác định"]
    XUA -->|Sau khi khôi phục| QUA
    QUA -->|Có| A["Acceptance criteria"]

    A --> QAT{"Có canonical ID và liên kết<br/>acceptance criteria–test basis?"}
    QAT -->|Không| XAT["Đứt truy vết acceptance criteria–test basis<br/>Khôi phục ID hoặc liên kết<br/>Owner: cần xác định"]
    XAT -->|Sau khi khôi phục| QAT
    QAT -->|Có| T["Test basis<br/>Chuỗi truy vết đầy đủ"]

Applied

Facts: Story mô phỏng US-INV-014: “Là nhân viên kho, tôi muốn chặn xuất hàng khi tồn kho không đủ để tránh xuất âm.” Artifact đang xét: /02-handbook/07-user-stories-and-acceptance-criteria.md; trạng thái corpus IN_REVIEW, version v0.9.0.

Current Behavior: Bản nháp ghi acceptance criterion: “Khi thiếu hàng, ERP cảnh báo ngay.” Câu này không nêu “thiếu” theo tồn khả dụng nào, tại thời điểm nào, cảnh báo có chặn lưu hay không, ai xử lý phần thiếu.

Underlying Need: Người dùng cần ngăn xác nhận xuất vượt số lượng được phép theo quy tắc nghiệp vụ có thẩm quyền. Bằng chứng hiện có chỉ là story mô phỏng; không có tham chiếu rule đã xác nhận trong CANONICAL_BUSINESS_RULES, không có approval reference.

Options	Decision Criteria	Decision
Giữ nguyên câu cảnh báo	Có thể kiểm thử duy nhất không	Loại: nhiều diễn giải
Viết “ERP phải chặn xuất âm theo quy định Nova Foods”	Có rule canonical và thẩm quyền xác nhận không	Loại: claim không có bằng chứng
Ghi giả định, tách câu hỏi xác minh, giữ traceability	Trung thực nguồn; QA lập được test basis; không suy diễn thẩm quyền	Chọn

Authority: Business Owner xác nhận chính sách xuất thiếu; Accounting Owner xác nhận ảnh hưởng hạch toán nếu có; Architect xác nhận nguồn số tồn và thời điểm đồng bộ. BA không thay các vai trò này.

Artifact: Ghi trong story: Assumption: Quy tắc chặn xác nhận xuất khi số lượng yêu cầu vượt tồn khả dụng là giả định học liệu; Verification required từ Business Owner. Liên kết nguồn quản trị bằng ID nguyên dạng CANONICAL_BUSINESS_RULES, không nói rule đã baseline. Nếu dùng PlantUML activity, nhãn là “PlantUML activity diagram”, không phải BPMN.

Consequence if Wrong: QA có thể test thông báo nhưng bỏ qua việc hệ thống vẫn cho xác nhận xuất. Delivery team có thể cấu hình chặn sai thời điểm. Tệ hơn, câu “theo quy định Nova Foods” bị hiểu là quyết định vận hành đã được phê duyệt.

Senior Lens

Ranh giới khôi phục an toàn: BA được sửa câu chữ, thêm câu hỏi, thêm nhãn Verification required, và nối lại ID tới artifact canonical. BA không được tự điền ngưỡng tồn, tự xác nhận luật, tự đổi IN_REVIEW thành approved, hoặc tạo “quy định Nova Foods” từ ví dụ. Nếu không có bằng chứng, giữ khoảng trống quyết định minh bạch; không bù bằng suy đoán.

Quick Reference

Kiểm tra trước khi giữ story	Đạt khi
Một người đọc có thể hiểu khác không?	Không; thuật ngữ, điều kiện, kết quả đã xác định
QA viết được test pass và fail không?	Có dữ liệu đầu vào, hành vi, kết quả mong đợi
Câu có nói “đã phê duyệt”, “bắt buộc”, “theo luật” không?	Có evidence và đúng authority; nếu không, gắn Verification required
Tên sơ đồ có đúng chuẩn không?	BPMN chỉ dùng cho BPMN; PlantUML gọi đúng PlantUML
ID còn nối tới nguồn và đầu ra không?	Giữ nguyên ID canonical, đường dẫn, source classification

11. Senior BA Notes & Rules of Thumb

Senior Lens

Senior BA không chọn phương án “nghe hợp lý nhất”. Senior BA tách fact (sự kiện có thể kiểm tra), assumption (giả định), decision (quyết định cần thẩm quyền) và recommendation (khuyến nghị có điều kiện). Lý do: user story và acceptance criteria có thể thành test basis, cấu hình ERP hoặc hướng dẫn vận hành; một suy đoán bị viết như fact sẽ lan thành lỗi delivery. Nova Foods là case study mô phỏng, chỉ dùng dữ liệu tổng hợp; IN_REVIEW tại v0.9.0 không phải approval hay baseline.

Tình huống xung đột	Trade-off cần phân tích	Evidence cần có	Authority quyết định	BA được làm
Sales muốn cho xác nhận đơn dù thiếu tồn; Warehouse muốn chặn	Doanh thu tức thời so với rủi ro giao thiếu, hủy đơn và sai tồn khả dụng	Mẫu đơn tổng hợp, luồng hiện tại, tỷ lệ lỗi mô phỏng, định nghĩa tồn khả dụng	Business Owner quyết định chính sách bán; Warehouse Owner xác nhận khả thi vận hành	Viết hai phương án, nêu hậu quả từng phương án, giữ rule là Verification required
Finance yêu cầu sửa số tiền sau khi phát hành chứng từ; Operations muốn sửa nhanh	Tốc độ sửa lỗi so với tính toàn vẹn sổ sách và truy vết	Loại chứng từ, trạng thái nghiệp vụ, quy trình điều chỉnh hiện có, ý kiến Accounting Owner	Accounting Owner; Legal Owner nếu có diễn giải pháp lý	Không tự viết acceptance criteria cho phép sửa; ghi câu hỏi và escalation
Security yêu cầu phân quyền theo vai trò; Business muốn mọi nhân viên xem dữ liệu khách hàng	Tiện thao tác so với giảm lộ dữ liệu	Ma trận vai trò, loại dữ liệu, mục đích truy cập, đánh giá Security	Security Owner và Business Owner cùng quyết định	Mô tả quyền tối thiểu như option; không tuyên bố compliance
Architect muốn xử lý đồng bộ; Operations chấp nhận cập nhật chậm	Tính tức thời so với độ bền tích hợp, chi phí lỗi và khả năng khôi phục	Tần suất giao dịch tổng hợp, điểm thất bại, SLA đã được xác nhận nếu có	Architect quyết định kiến trúc; Business Owner quyết định mức chấp nhận chậm	Ghi rõ dependency, trạng thái đồng bộ và owner của quyết định

Chất lượng evidence quyết định mức mạnh của câu viết. Evidence mạnh gồm artifact có ID canonical, nguồn gốc rõ, ngày ghi nhận, phạm vi áp dụng và người chịu trách nhiệm xác nhận. Ví dụ, CANONICAL_BUSINESS_RULES đang IN_REVIEW chỉ chứng minh nơi quản trị rule; không chứng minh rule đã đúng hay đã được phê duyệt. Nguồn pháp lý từ Verified primary-source seed chỉ là căn cứ để nhận diện nhu cầu xác minh; BA không tự diễn giải thành nghĩa vụ cấu hình ERP khi chưa có Legal Owner hoặc Accounting Owner xác nhận.

Ngoại lệ cho quy tắc “mỗi story phải có acceptance criteria đầy đủ” xuất hiện khi quyết định nền chưa có authority. Không tạo tiêu chí giả để lấp chỗ trống. Ví dụ, chưa có Business Owner xác nhận cách xử lý thiếu tồn thì story chỉ nên mô tả phạm vi cần quyết định, các option và dependency; không viết “hệ thống phải chặn” như rule Nova Foods. Ngược lại, không dùng nhãn Verification required để trì hoãn một fact đã có bằng chứng rõ và đúng owner.

Red flag: stakeholder dùng từ “luôn”, “bắt buộc”, “theo luật”, “đã chốt”, nhưng không chỉ ra artifact, nguồn hoặc người có thẩm quyền. Red flag khác: hai vai trò cùng quyết định một điều nhưng mục tiêu trái nhau; acceptance criteria chứa ngưỡng số lượng hoặc thời gian không có nguồn; hoặc BA bị yêu cầu gọi nội dung APPROVED khi artifact vẫn IN_REVIEW. Escalate khi quyết định ảnh hưởng tiền, dữ liệu cá nhân, an toàn thực phẩm, chứng từ, phân quyền, kiến trúc tích hợp, hoặc khi conflict không thể giải bằng evidence hiện có.

Khuyến nghị senior phải có cấu trúc kiểm chứng được: “Dựa trên [evidence], khuyến nghị [option] để đạt [mục tiêu]; còn [uncertainty] cần [authority] xác nhận trước khi rule thành acceptance criterion.” Câu này không bịa certainty, vẫn giúp team biết việc nào được làm tiếp và việc nào phải dừng. BA giữ traceability tới TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES hoặc CANONICAL_DATA_DICTIONARY bằng ID nguyên dạng; BA không thay owner ra quyết định.

Senior Lens

Senior BA không chấm User Story theo câu chữ hay độ dài. Senior BA kiểm tra khả năng biến nhu cầu thành quyết định, Acceptance Criteria và kiểm thử mà không tự suy diễn quy tắc. Với Nova Foods Trading & Manufacturing là case mô phỏng, dữ liệu tổng hợp, một story đạt mức review khi người đọc xác định được: ai chịu tác động, hành vi nào đổi, điều kiện nào kích hoạt, kết quả nào kiểm chứng được, và ai có quyền quyết định phần còn tranh chấp.

Heuristic review	Bằng chứng cần thấy	Red flag	Ngưỡng escalation	Không áp dụng quy tắc thường khi
Một story phục vụ một outcome nghiệp vụ	Outcome đo được hoặc quan sát được; phạm vi rõ	Story gom tạo đơn, duyệt giá, xuất hóa đơn trong cùng item	Tách hoặc đưa Product Owner/Business Owner quyết định nếu tách làm đổi luồng vận hành	Các bước chỉ là thao tác kỹ thuật không tạo outcome độc lập
Acceptance Criteria phải kiểm thử được	Given, When, Then hoặc điều kiện đầu vào, hành động, kết quả cụ thể	Dùng “nhanh”, “đúng”, “thân thiện”, “đầy đủ” không có tiêu chí	Escalate QA và Business Owner nếu hai người kiểm thử có thể cho hai kết quả khác nhau	Yêu cầu khám phá ban đầu chưa đủ bằng chứng; ghi là discovery, không gọi là acceptance criterion
Quy tắc nghiệp vụ có nguồn canonical	Tham chiếu đúng CANONICAL_BUSINESS_RULES khi rule đã tồn tại	Copy rule vào nhiều story, tạo nhiều bản sự thật	Escalate khi rule mới ảnh hưởng giá, tồn kho, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc truy vết	Rule chỉ là giả định học liệu; gắn nhãn project assumption, không diễn đạt như quy định vận hành
Dữ liệu có nghĩa và biên rõ	Trường, trạng thái, đơn vị VND, điều kiện null hoặc lỗi được nêu	“Hệ thống lưu thông tin khách hàng” không nêu dữ liệu nào	Escalate Architect, Security hoặc Data Owner nếu thay đổi dữ liệu dùng chung hay quyền truy cập	Prototype dùng dữ liệu giả không lưu; vẫn không được suy ra thiết kế production
Thẩm quyền khớp loại quyết định	Business Owner quyết outcome; Architect quyết kiến trúc; QA quyết testability; Legal/Accounting quyết diễn giải chuyên môn	BA tự chốt thuế, hóa đơn, phân quyền hoặc retention	Escalate ngay khi một quyết định thuộc từ hai vai trò chuyên môn trở lên	Không có quyết định cần chốt; BA chỉ ghi nhận câu hỏi và dependency

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

flowchart TB
    A[Review User Story] --> B{Tách story có làm mất<br/>kiểm soát giao dịch?}

    B -- Có --> B0{Có bằng chứng từ luồng hiện tại,<br/>ràng buộc dữ liệu và đánh giá Architect?}
    B0 -- Không --> B2[Giữ IN_REVIEW;<br/>bổ sung bằng chứng cần thiết]
    B2 --> Z
    B0 -- Có --> B1[Giữ cùng story;<br/>nêu ranh giới, lỗi và rollback kiểm thử được]
    B1 --> C

    B -- Không --> B3[Xác nhận không cần giữ cùng story<br/>vì kiểm soát giao dịch]
    B3 --> C{Story chỉ phục vụ một outcome,<br/>với phạm vi rõ?}

    C -- Không --> C2{Mỗi phần tạo outcome độc lập<br/>và tách không làm đổi luồng vận hành?}
    C2 -- Có --> C3[Tách thành các story,<br/>mỗi story phục vụ một outcome]
    C3 --> A
    C2 -- Không --> C4{Tách có làm đổi<br/>luồng vận hành?}
    C4 -- Có --> C5[Product Owner hoặc Business Owner<br/>quyết định cách tách]
    C5 --> Q
    C4 -- Không --> C1[Trả về làm rõ outcome và phạm vi]
    C1 --> A

    C -- Có --> D{Acceptance Criteria kiểm thử được?}

    D -- Không --> E{Đây là yêu cầu discovery?}
    E -- Có --> E1[Gắn nhãn discovery;<br/>không gọi là Acceptance Criterion]
    E1 --> Z
    E -- Không --> E2{Hai người kiểm thử có thể<br/>cho kết quả khác nhau?}
    E2 -- Có --> E3{Khác biệt thuộc testability<br/>hay diễn giải nghiệp vụ?}
    E3 -- Testability --> E5[QA quyết định testability]
    E3 -- "Outcome hoặc diễn giải nghiệp vụ" --> E6[Business Owner quyết định outcome<br/>hoặc cách diễn giải nghiệp vụ]
    E5 --> Q
    E6 --> Q
    E2 -- Không --> E4[Trả về làm rõ đầu vào,<br/>hành động và kết quả]
    E4 --> A

    D -- Có --> F{Story chứa quy tắc nghiệp vụ?}

    F -- Có --> G{Quy tắc đã có trong<br/>CANONICAL_BUSINESS_RULES?}
    G -- Có --> H{Story tham chiếu đúng<br/>quy tắc canonical?}
    H -- Không --> H1[Trả về sửa tham chiếu canonical]
    H1 --> A
    H -- Có --> J{Dữ liệu có ý nghĩa và biên rõ?}

    G -- Không --> I{Chỉ là giả định học liệu?}
    I -- Có --> I1[Gắn nhãn project assumption;<br/>không diễn đạt như quy tắc vận hành]
    I1 --> J
    I -- Không --> K[Rule mới cần quyết định có thẩm quyền]
    K --> L

    F -- Không --> J

    J -- Không --> J1[Trả về làm rõ trường, trạng thái,<br/>đơn vị, null, lỗi và quyền truy cập]
    J1 --> A
    J -- Có --> K0{Có quyết định cần chốt<br/>hoặc phần còn tranh chấp?}

    K0 -- Không --> R[Đạt mức review:<br/>actor, hành vi, điều kiện, kết quả<br/>và nguồn rule xác định được nếu có]
    K0 -- Có --> L{Nếu chọn sai, hậu quả có thể ảnh hưởng<br/>giá, tồn kho, kế toán, dữ liệu cá nhân,<br/>an toàn thực phẩm, truy vết, kiến trúc,<br/>dữ liệu dùng chung hoặc quyền truy cập?}

    L -- Không --> M{Vai trò có thẩm quyền<br/>đã được xác định?}
    M -- Không --> M1[Giữ IN_REVIEW;<br/>xác định decision authority]
    M1 --> Z
    M -- Có --> Q{Đã có quyết định hoặc<br/>artifact có thẩm quyền?}

    L -- Có --> N{Quyết định thuộc từ hai vai trò<br/>chuyên môn trở lên?}
    N -- Có --> N1[Escalate ngay tới<br/>các owner liên quan]
    N1 --> Q
    N -- Không --> O{Hậu quả thuộc miền nào?}

    O -- "Outcome, giá, tồn kho,<br/>an toàn thực phẩm, truy vết" --> O1[Business Owner hoặc owner miền liên quan quyết định]
    O -- "Kiến trúc" --> O2[Architect quyết định]
    O -- "Dữ liệu dùng chung,<br/>dữ liệu cá nhân, quyền truy cập" --> O3[Security hoặc Data Owner đánh giá tác động<br/>và quyết định thay đổi hoặc quyền truy cập]
    O -- "Kế toán hoặc pháp lý" --> O4[Accounting hoặc Legal Owner<br/>xác minh và quyết định diễn giải]

    O1 --> Q
    O2 --> Q
    O3 --> Q
    O4 --> Q

    Q -- Không --> Q1[Giữ IN_REVIEW;<br/>chờ quyết định hoặc artifact có thẩm quyền]
    Q1 --> Z
    Q -- Có --> Q2[Cập nhật story, Acceptance Criteria,<br/>nguồn rule và decision authority]
    Q2 --> A

    Z[Giữ trạng thái IN_REVIEW] -- "Khi có đủ bằng chứng" --> A

Ngưỡng escalation không dựa vào mức tự tin của BA. Ngưỡng dựa vào hậu quả nếu chọn sai. Ví dụ, story “Nhân viên bán hàng sửa đơn sau khi giao hàng” có thể tác động doanh thu, chứng từ và tồn kho. Bằng chứng là cùng một thay đổi chạm nhiều miền nghiệp vụ. Senior BA không tự đặt rule khóa sửa; phải chuyển câu hỏi tới Business Owner, Accounting Owner và vai trò liên quan. Luật Kế toán, Nghị định 123/2020/NĐ-CP và nguồn pháp lý khác chỉ là boundary tham khảo; diễn giải áp dụng cần legal hoặc accounting owner xác minh.

Red flag mạnh nhất là acceptance criterion chứa quyết định ẩn. Câu “Hệ thống chỉ cho sửa đơn trong ngày” nhìn như tiêu chí kiểm thử, nhưng thực chất chứa policy về thời hạn sửa. Nếu artifact không chỉ ra nguồn rule và decision authority, tiêu chí này chưa đủ cơ sở. Senior BA trả nó về dạng câu hỏi quyết định, thay vì để Development hoặc QA biến giả định thành hành vi ERP.

Quy tắc “story nhỏ, độc lập” không áp dụng máy móc khi tách story làm mất kiểm soát giao dịch. Ví dụ, xác nhận xuất kho và ghi nhận lô hàng có thể cần được xử lý cùng một giao dịch để tránh trạng thái một phần. Bằng chứng cần từ luồng hiện tại, ràng buộc dữ liệu và đánh giá Architect. Senior BA không ép tách vì chuẩn Agile; Senior BA chỉ yêu cầu ranh giới, lỗi và hành vi rollback được kiểm thử.

Khi evidence yếu, không nâng giả định thành fact. Ghi rõ loại bằng chứng: quan sát quy trình mô phỏng, dữ liệu tổng hợp, ý kiến stakeholder, hay nguồn canonical. Evidence từ một stakeholder chỉ chứng minh góc nhìn người đó; không tự chứng minh policy toàn tổ chức. Story giữ trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07, cho đến khi artifact có thẩm quyền cung cấp căn cứ rõ hơn.

Senior Lens

Senior BA không biến thiếu bằng chứng thành khẳng định. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, khuyến nghị phải tách rõ fact (sự kiện có nguồn), assumption (giả định dự án), verification required (cần xác minh) và decision (quyết định thuộc thẩm quyền). Cầu nối suy luận phải nêu được: bằng chứng nào dẫn đến nhận định nào, còn khoảng trống nào, ai chịu quyền quyết định khoảng trống đó.

Trường ghi trong user story hoặc decision log	Nội dung mẫu có thể bảo vệ
Observation	Hai bên liên quan mô tả khác nhau về thời điểm khóa sửa số lượng lô hàng.
Evidence	Biên bản workshop nội bộ mô phỏng ngày 2026-08-07 ghi nhận ý kiến Sales và Warehouse; chưa có quy tắc canonical trong CANONICAL_BUSINESS_RULES.
Confidence	Thấp; bằng chứng là ý kiến, chưa phải quy tắc được xác nhận.
Assumption	Giả định dự án: chỉ Warehouse Manager có thể yêu cầu mở lại giao dịch đã xác nhận, để tiếp tục phân tích luồng.
Impact	Quy tắc này ảnh hưởng quyền sửa, audit trail và acceptance criteria.
Recommendation	Không chốt acceptance criterion bắt buộc. Giữ story ở IN_REVIEW; đề nghị Business Owner quyết định chính sách nghiệp vụ, Security/Architect xem xét quyền và lưu vết nếu có thay đổi thiết kế.
Decision authority	Business Owner quyết định chính sách; Architect quyết định khả thi kỹ thuật; Security đánh giá kiểm soát truy cập. BA ghi nhận và truy vết, không thay quyền.
Traceability	Tham chiếu TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, /02-handbook/07-user-stories-and-acceptance-criteria.md, status IN_REVIEW, version v0.9.0, ngày 2026-08-07.

Cách viết không phòng thủ: “Dựa trên hai ý kiến workshop nội bộ mô phỏng, khả năng cao cần hạn chế sửa giao dịch sau xác nhận. Tuy nhiên, chưa có nguồn canonical xác định thời điểm khóa, vai trò có quyền mở lại và yêu cầu lưu vết. Khuyến nghị tách các điểm này thành quyết định chờ Business Owner, Architect và Security xác nhận; không diễn giải giả định này là quy tắc Nova Foods đã phê duyệt.”

Không viết: “Hệ thống phải khóa tuyệt đối sau xác nhận” khi chưa có bằng chứng và thẩm quyền. Cũng không viết “người dùng đã đồng ý” nếu chỉ có trao đổi, ghi chú hoặc sự im lặng. Nếu quyết định liên quan pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm hoặc hóa đơn, ghi Verification required; chuyển đúng Legal Owner, Accounting Owner, Compliance hoặc domain owner. Handbook này mang tính giáo dục, không thay thế thẩm quyền pháp lý, kế toán hay production.

12. Associated Template Reference & Completed Artifact

Quick Reference

Template là mẫu cấu trúc dùng lặp lại để ghi nhận story, acceptance criteria và liên kết kiểm thử nhất quán. Mẫu không tạo ra requirement đúng. Requirement chỉ đủ điều kiện dùng khi có bằng chứng nguồn, chủ sở hữu quyết định phù hợp và truy vết đến artifact canonical. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Template ID / tệp canonical	Dùng khi	Không dùng khi	Owner ghi nhận	Consumer	Quality gate trước khi tham chiếu
TEMPLATE_MANIFEST /01-curriculum/TEMPLATE_MANIFEST.md	Cần xác định template nào đã được đăng ký, phạm vi và vị trí dự kiến	Muốn dùng manifest làm user story, business rule hoặc bằng chứng approval	Principal IT Business Analyst / Technical Curriculum Author	BA, curriculum author, QA reviewer	ID và filename khớp manifest; trạng thái vẫn IN_REVIEW; không gọi template là baseline hay approved
TRACEABILITY_ID_REGISTRY /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Cần kiểm tra ID story, rule, requirement, acceptance criterion hoặc liên kết liên artifact	Tự tạo ID mới ngoài registry hoặc đổi ID để dễ đọc	Principal IT Business Analyst / Technical Curriculum Author duy trì registry; BA lập liên kết	BA, QA, Architect, Business Owner	ID giữ nguyên dạng canonical; một liên kết chỉ trỏ một đối tượng xác định; xung đột ID phải escalation
CANONICAL_BUSINESS_RULES /01-curriculum/CANONICAL_BUSINESS_RULES.md	Acceptance criterion phụ thuộc quy tắc nghiệp vụ đã được catalog	Suy diễn rule từ ví dụ, workshop note hoặc mong muốn kỹ thuật chưa xác nhận	Principal IT Business Analyst / Technical Curriculum Author duy trì catalog; Business Owner quyết định nghiệp vụ	BA, QA, Developer, Business Owner	Rule được tham chiếu đúng ID; trạng thái và bằng chứng được đọc cùng rule; điểm chưa xác nhận giữ Verification required
CANONICAL_DATA_DICTIONARY /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Story hoặc criterion nêu field, trạng thái dữ liệu, định dạng, mã hoặc quan hệ logic	Dùng làm schema triển khai, API contract hoặc quyết định database vật lý	Principal IT Business Analyst / Technical Curriculum Author duy trì dictionary; Architect quyết định kỹ thuật	BA, QA, Developer, Architect	Tên dữ liệu, nghĩa và phân loại khớp dictionary; dữ liệu cá nhân hoặc nhạy cảm cần Security/Legal Owner xác minh
/02-handbook/07-user-stories-and-acceptance-criteria.md	Cần hướng dẫn học và artifact hoàn chỉnh của chương về user story và acceptance criteria	Dùng handbook thay nguồn canonical của rule, data, legal hoặc approval	Principal IT Business Analyst / Technical Curriculum Author	Learner, BA, QA reviewer	Story nêu actor, need, value; criterion kiểm thử được; giả định tách khỏi fact; không tuyên bố phê duyệt
00_SOURCE_MAP /00-research/00_SOURCE_MAP.md	Cần kiểm tra nguồn chuẩn, nguồn pháp lý hoặc ranh giới dùng nguồn	Trích dẫn thành điều khoản, nghĩa vụ pháp lý hoặc xác nhận tuân thủ khi chưa kiểm chứng văn bản đầy đủ	Principal IT Business Analyst / Technical Curriculum Author	BA, Legal Owner, Compliance, QA reviewer	URL và phân loại nguồn khớp source map; chi tiết pháp lý, kế toán, thuế, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm ghi Verification required nếu chưa xác minh trực tiếp

Quy tắc dùng mẫu: template chỉ giảm lỗi cấu trúc; không thay thẩm quyền. Ví dụ, acceptance criterion nói về quyền sửa giao dịch sau xác nhận cần tham chiếu rule và dữ liệu liên quan. Bằng chứng là quyền sửa tác động chính sách nghiệp vụ, kiểm soát truy cập và audit trail. Vì vậy Business Owner quyết định chính sách, Architect đánh giá khả thi, Security đánh giá kiểm soát; BA chỉ ghi nhận, nối traceability và giữ trạng thái IN_REVIEW.

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

flowchart TB
    S["User story và acceptance criterion"] --> BA["BA ghi nhận và nối traceability<br/>Không phê duyệt chính sách, kiến trúc, bảo mật hoặc pháp lý"]

    BA --> M["TEMPLATE_MANIFEST"]
    BA --> R["TRACEABILITY_ID_REGISTRY"]
    BA --> B["CANONICAL_BUSINESS_RULES"]
    BA --> D["CANONICAL_DATA_DICTIONARY"]
    BA --> X["00_SOURCE_MAP"]

    M -->|"Đăng ký template, phạm vi, vị trí và filename"| G["Gate tối thiểu"]
    R -->|"ID canonical và xung đột ID"| G
    B -->|"Rule ID, trạng thái và bằng chứng đi cùng rule"| G
    X -->|"Phân loại nguồn và ranh giới nguồn pháp lý"| G

    D -->|"Tên, nghĩa và phân loại dữ liệu"| DS{"Dữ liệu cá nhân<br/>hoặc nhạy cảm?"}
    DS -->|"Không"| G
    DS -->|"Có"| SL["Security hoặc Legal Owner xác minh"]
    SL --> G

    G --> C{"Đã kiểm tra:<br/>ID và filename canonical;<br/>fact, assumption, Verification required;<br/>IN_REVIEW không phải approval;<br/>dữ liệu mô phỏng không phải cấu hình ERP thật;<br/>nguồn hướng dẫn không phải quyết định<br/>pháp lý, kế toán, bảo mật hoặc vận hành?"}

    C -->|"Đạt, không còn điểm chưa xác minh"| U["Được phép tham chiếu trong chapter<br/>Trạng thái IN_REVIEW, không phải approval"]
    C -->|"Còn điểm chưa xác minh"| V{"Đã ghi rõ Verification required,<br/>không trình bày như fact<br/>và không vượt ranh giới thẩm quyền?"}
    V -->|"Có"| U

    C -->|"Xung đột ID"| RM["Principal IT Business Analyst /<br/>Technical Curriculum Author xử lý registry"]
    C -->|"Chính sách nghiệp vụ"| BO["Business Owner quyết định"]
    C -->|"Khả thi kỹ thuật"| A["Architect đánh giá"]
    C -->|"Kiểm soát bảo mật"| SEC["Security đánh giá"]
    C -->|"Vấn đề pháp lý"| L["Legal Owner xác minh"]
    C -->|"Kế toán hoặc vận hành chưa rõ owner"| O["Xác định owner phù hợp"]

    V -->|"Không: xung đột ID"| RM
    V -->|"Không: chính sách nghiệp vụ"| BO
    V -->|"Không: khả thi kỹ thuật"| A
    V -->|"Không: bảo mật hoặc dữ liệu nhạy cảm"| SEC
    V -->|"Không: pháp lý, thuế hoặc hóa đơn"| L
    V -->|"Không: kế toán, vận hành hoặc an toàn thực phẩm chưa rõ owner"| O

    RM --> Z{"Đã giải quyết, quyết định,<br/>đánh giá hoặc xác minh?"}
    BO --> Z
    A --> Z
    SEC --> Z
    L --> Z
    O --> Z

    Z -->|"Có"| G
    Z -->|"Chưa"| N["Không dùng trong chapter"]

Quality gate tối thiểu trước khi dùng bất kỳ liên kết nào trong chapter: giữ nguyên ID và filename canonical; phân biệt fact, assumption và Verification required; không biến template hoặc status IN_REVIEW thành approval; không dùng dữ liệu mô phỏng để khẳng định cấu hình ERP thật; và không biến nguồn hướng dẫn thành quyết định pháp lý, kế toán, bảo mật hoặc vận hành.

Quick Reference

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi dữ liệu là tổng hợp. Artifact đã điền của chương nằm trong chính tệp /02-handbook/07-user-stories-and-acceptance-criteria.md, tại H2 8. Detailed Worked Example. Không suy diễn tệp template đã hoàn tất tại /03-templates/ khi không có đường dẫn canonical được cung cấp.

Mục cần tra	Vị trí tra chính xác	Kiểm tra đạt
Mục tiêu chương	H2 1. Concept l? g?? đến H2 3. V? tr? trong Lifecycle	User story, acceptance criteria và vị trí trong lifecycle không bị trình bày như hợp đồng hay phê duyệt.
Đầu vào	H2 4. Input c?n thi?t	Mỗi story có nguồn business need, rule, data hoặc process; không tự tạo yêu cầu Nova Foods.
Cách BA làm	H2 5. Step-by-step BA Activities	Story nêu persona, nhu cầu, giá trị; acceptance criteria nêu điều kiện kiểm tra được.
Đầu ra	H2 6. Output thu ???c	ID, liên kết nguồn và trạng thái IN_REVIEW nhất quán.
Người dùng đầu ra	H2 7. Who consumes those outputs?	Người đọc phân biệt consumer với người có quyền approval.
Artifact Nova Foods đã điền	/02-handbook/07-user-stories-and-acceptance-criteria.md, H2 8. Detailed Worked Example	Facts, Current Behavior, Underlying Need, Options, Decision Criteria, Decision, Authority, Artifact, Consequence if Wrong đầy đủ; Authority không bị diễn đạt thành approval.
Phụ thuộc canonical	H2 9. Related Concepts & Dependencies	ID giữ nguyên: CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY.
Sai lỗi cần loại	H2 10. Common Mistakes & Anti-patterns	Không biến acceptance criteria thành solution design, legal claim, accounting conclusion hoặc production instruction.
Quy tắc senior	H2 11. Senior BA Notes & Rules of Thumb	Mọi suy luận có evidence/reasoning bridge; điểm chưa xác minh giữ nhãn Verification required hoặc project assumption.
Tham chiếu cuối chương	H2 12. Associated Template Reference & Completed Artifact	Chỉ dùng lookup này để tìm artifact; không sao chép canonical registry vào chapter.

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

flowchart TB
    A[Đọc user story và acceptance criteria] --> B{Story có persona,<br/>nhu cầu và giá trị?}
    B -- Không --> R[Trả story để bổ sung]
    B -- Có --> C{Acceptance criteria có<br/>điều kiện kiểm tra được?}
    C -- Không --> R
    C -- Có --> D{Story có nguồn business need,<br/>rule, data hoặc process?}

    D -- Không có --> R
    D -- Chưa rõ --> V[Gắn Verification required;<br/>không suy diễn yêu cầu Nova Foods]
    D -- Có --> E[Tra dependency canonical:<br/>CHAPTER_MANIFEST,<br/>TRACEABILITY_ID_REGISTRY,<br/>CANONICAL_BUSINESS_RULES,<br/>CANONICAL_DATA_DICTIONARY]
    V --> E

    E --> F[Tra artifact đã điền:<br/>H2 8 trong chính chapter]
    F --> G[TEMPLATE_MANIFEST là planned manifest;<br/>không là bằng chứng template/artifact hoàn tất]
    G --> H{Suy luận có<br/>evidence/reasoning bridge?}
    H -- Chưa có --> I[Gắn Verification required<br/>hoặc project assumption]
    H -- Có --> J[Kiểm anti-pattern:<br/>AC không thành solution design,<br/>legal claim, accounting conclusion<br/>hoặc production instruction]
    I --> J

    J --> K[Phân biệt consumer với người<br/>có quyền approval]
    K --> L[Authority trong worked example<br/>không diễn đạt thành approval]
    L --> M[Giữ trạng thái IN_REVIEW]
    M --> N[IN_REVIEW không là approval;<br/>không tạo baseline hoặc approval]

Bằng chứng vị trí: CHAPTER_MANIFEST là manifest canonical cho handbook chapters; vì vậy tên tệp chapter là điểm tra cứu chapter. TEMPLATE_MANIFEST chỉ là planned template manifest; vì vậy không được gọi một template chưa có đường dẫn canonical là artifact đã điền. IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh và VND áp dụng cho lookup này; không tạo baseline hoặc approval.

Core

Trước handoff chương, kiểm tra chéo tệp để chứng minh mỗi user story, acceptance criterion và tham chiếu Nova Foods không tự tạo rule, ID, trạng thái hay thẩm quyền. Bằng chứng: CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY đều IN_REVIEW, v0.9.0, ngày 2026-08-07; không có baseline hoặc approval. Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp.

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

flowchart TB
    A[Soát chapter] --> B[Đối chiếu ID, filename và tham chiếu Nova Foods]
    B --> C[Đối chiếu rule và data]
    C --> D[Kiểm tra 5 nguồn: CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY]
    D --> E[Kiểm tra tất cả là IN_REVIEW, v0.9.0, 2026-08-07]
    E --> F[Kiểm tra nhãn Verification required cho nội dung chưa được nguồn xác nhận]
    F --> G[Kiểm tra: chưa có baseline hoặc approval; Nova Foods là case mô phỏng, dùng dữ liệu tổng hợp]
    G --> H{Có mâu thuẫn hoặc vượt thẩm quyền?}
    H -- Không --> I[Handoff trạng thái IN_REVIEW]
    H -- Có --> J{Owner có được nguồn chuẩn xác nhận?}
    J -- Không --> K[Gắn Verification required; không tự tạo owner]
    K --> L[Chặn handoff; giữ IN_REVIEW]
    J -- Có --> M[Escalation tới owner được xác nhận]
    M --> N[Owner xử lý hoặc xác nhận]
    N --> B

Applied

Mục	Nội dung
Facts	Chapter thuộc /02-handbook/07-user-stories-and-acceptance-criteria.md; corpus dùng vi-VN, Asia/Ho_Chi_Minh, VND; Nova Foods là mô phỏng.
Current Behavior	Artifact nguồn đang là kế hoạch kiểm soát, chưa xác nhận rule ERP, compliance, baseline hay approval.
Underlying Need	Handoff cần giữ traceability và ngăn acceptance criterion biến thành cam kết pháp lý, kế toán, bảo mật hoặc vận hành thực.
Options	Handoff không kiểm tra; kiểm tra nội bộ chapter; kiểm tra chéo với artifact canonical và escalation.
Decision Criteria	Giữ đúng ID/path; không suy diễn ngoài nguồn; nhãn xác minh còn nguyên; owner chuyên môn nhận đúng vấn đề.
Decision	Kiểm tra chéo với năm artifact canonical trước handoff. Mở issue khi thiếu bằng chứng hoặc conflict.
Authority	Principal IT Business Analyst / Technical Curriculum Author điều phối và ghi nhận; không thay quyết định Business Owner, Legal Owner, Accounting Owner, Security, Architect, QA.
Artifact	/02-handbook/07-user-stories-and-acceptance-criteria.md, trạng thái IN_REVIEW, phiên bản v0.9.0.
Consequence if Wrong	Learner hiểu nhầm nội dung mô phỏng là rule ERP thật, approval, nghĩa vụ pháp lý hoặc test basis đã đủ.

Senior Lens

Kiểm tra chéo	Bằng chứng cần thấy	Open issue hoặc Verification required	Escalation owner
Định danh và đường dẫn	ID, filename, liên kết chapter khớp /01-curriculum/CHAPTER_MANIFEST.md và /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Verification required nếu story, rule, data element hoặc criterion dùng ID chưa đăng ký	Principal IT Business Analyst / Technical Curriculum Author
Quy tắc nghiệp vụ	Rule chỉ tham chiếu CANONICAL_BUSINESS_RULES; không viết rule mới như fact Nova Foods	Open issue: catalog là kế hoạch IN_REVIEW; rule chưa có baseline không được gọi bắt buộc	Business Owner; Principal IT Business Analyst / Technical Curriculum Author
Dữ liệu	Thuật ngữ, field, phân loại dữ liệu khớp CANONICAL_DATA_DICTIONARY	Verification required nếu criterion chứa dữ liệu cá nhân, retention, quyền truy cập, field hoặc validation chưa canonical	Security Owner; Legal Owner; Principal IT Business Analyst / Technical Curriculum Author
Pháp lý và compliance	Claim pháp lý có URL official source, nhãn phạm vi và nhãn xác minh	Open issue: diễn giải Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật Kế toán, Nghị định 123/2020/NĐ-CP, Luật An toàn thực phẩm cần owner chuyên môn xác minh trước production use	Legal Owner; Accounting Owner; Compliance Owner
Testability	Acceptance criterion có điều kiện, hành động, kết quả quan sát được; không giả định UI hay integration chưa xác nhận	Verification required nếu criterion cần API, authorization, audit log, performance hoặc integration behavior	QA Owner; Technical Architect; Security Owner
Quản trị template	Không gọi template planned là completed artifact hoặc approved form	Open issue: TEMPLATE_MANIFEST là planning artifact IN_REVIEW; không suy ra template instance đã tồn tại	Principal IT Business Analyst / Technical Curriculum Author

Không handoff như “ready for baseline” khi còn bất kỳ dòng Open issue hoặc Verification required. Handoff hợp lệ chỉ là chuyển chapter để review tiếp ở IN_REVIEW, kèm issue, evidence path, ngày 2026-08-07 và owner escalation.

Quick Reference

Checklist trước handoff:

• [ ] Đã đối chiếu /01-curriculum/CHAPTER_MANIFEST.md.
• [ ] Đã đối chiếu /01-curriculum/TRACEABILITY_ID_REGISTRY.md.
• [ ] Đã đối chiếu /01-curriculum/CANONICAL_BUSINESS_RULES.md.
• [ ] Đã đối chiếu /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
• [ ] Đã đối chiếu /01-curriculum/TEMPLATE_MANIFEST.md.
• [ ] Không có claim baseline, approval, compliance hoặc production readiness.
• [ ] Nova Foods luôn ghi là mô phỏng giáo dục, dữ liệu tổng hợp.
• [ ] Mọi vấn đề pháp lý, kế toán, bảo mật, kiến trúc, QA có escalation owner đúng thẩm quyền.