03 Discovery Interviewing And Note Taking

Trường kiểm soát	Giá trị
Tên tệp được kiểm soát	/02-handbook/03-discovery-interviewing-and-note-taking.md
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale	vi-VN; Việt Nam; VND
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục; chỉ dữ liệu tổng hợp
Phân loại nguồn	BABOK Guide là nguồn nghề nghiệp cho kiến thức và thuật ngữ BA. ISO/IEC/IEEE 29148:2018 là nguồn chuẩn cho bối cảnh yêu cầu. Nội dung không thay thế văn bản chuẩn có cấp phép.
Baseline	Chưa có baseline reference tại v0.9.0. IN_REVIEW không là BASELINED.
Approval	Chưa có approval reference. Metadata và nội dung không tạo phê duyệt ngầm định.
Giới hạn thẩm quyền	Tài liệu học liệu. Không xác nhận yêu cầu Nova Foods thực tế, không là tư vấn pháp lý, kế toán, vận hành hay chỉ dẫn production.

1. Concept l? g??

Core

Discovery interviewing and note taking là hoạt động BA tìm hiểu vấn đề trước khi đề xuất thay đổi. BA gặp hoặc trao đổi với người biết công việc, đặt câu hỏi có mục đích, nghe câu trả lời, kiểm tra cách hiểu, rồi ghi lại bằng chứng có thể truy vết. Mục tiêu không phải ghi mọi câu đã nói. Mục tiêu là biến thông tin rời rạc thành hiểu biết đủ rõ để xác định vấn đề, phạm vi, quy tắc, dữ liệu, ngoại lệ và điểm cần xác minh.

Từ điểm bắt đầu bằng không: một người nói “quy trình đang chậm” mới là nhận định, chưa là requirement. BA cần biết việc nào chậm, ai thực hiện, dữ liệu nào dùng, kết quả nào bị ảnh hưởng, tần suất ra sao và bằng chứng nào hỗ trợ nhận định. Interview tạo thông tin đầu vào. Note taking bảo toàn thông tin đó để BA, người cung cấp thông tin và người nhận đầu ra sau này có thể kiểm tra cùng một nội dung. Không có ghi chú có cấu trúc, trí nhớ cá nhân dễ thay bằng fact; traceability bị đứt.

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

flowchart TB
    A[Thông tin ban đầu] --> B[BA trao đổi khám phá với người cung cấp thông tin]
    B --> C[BA ghi chú: nội dung, nguồn, Fact, Assumption, Question]
    C --> D{Trạng thái điểm cần xác minh?}

    D -- Cần xác minh trong vòng này --> E[BA hỏi tiếp hoặc đối chiếu nguồn khác]
    E --> C

    D -- Chưa thể xác minh --> F[Giữ trạng thái Question hoặc Assumption và cờ cần theo dõi]
    F --> G[Đầu vào cho phân tích tiếp theo]

    D -- Không còn điểm cần xác minh trong vòng này --> H[BA kiểm tra cách hiểu với người cung cấp thông tin]
    H --> G

    C -. Giả định chưa xác minh bị chuyển thành Fact hoặc business rule .-> I[Requirement hoặc quy tắc sai]

Một ghi chú tốt tách rõ ba lớp. Fact là điều người cung cấp thông tin mô tả hoặc tài liệu chứng minh. Assumption là điều tạm coi đúng khi chưa có bằng chứng đủ. Question là điểm chưa rõ cần hỏi tiếp hoặc đối chiếu nguồn khác. Sự tách lớp này quan trọng vì BA không được nâng assumption thành quy tắc nghiệp vụ chỉ vì nó nghe hợp lý.

Ví dụ tối thiểu, Nova Foods là case mô phỏng: nhân viên kho mô tả rằng phiếu nhập hàng đôi khi phải nhập lại khi số lượng giao thay đổi. Ghi chú khám phá chỉ nên giữ: có tình huống nhập lại; người mô tả là nhân viên kho; đối tượng liên quan là phiếu nhập hàng; cần xác minh nguyên nhân, tần suất và nguồn dữ liệu giao hàng. Ghi chú này chưa kết luận ERP thiếu chức năng, chưa tạo business rule, chưa chọn giải pháp và chưa xác nhận quy trình thực tế.

Ranh giới concept: chương này nói về cách thu nhận và ghi chép hiểu biết ban đầu có kiểm soát. Nó không bao gồm phê duyệt requirement, thiết kế giao diện, thiết kế dữ liệu, cấu hình ERP, kiểm thử, quyết định ngân sách hay diễn giải nghĩa vụ pháp lý. Những hoạt động đó cần đầu vào, vai trò có thẩm quyền và artifact riêng.

Core

Thuật ngữ	Nghĩa ngắn	Vai trò khi phỏng vấn và ghi chép
Discovery	Khám phá có cấu trúc trước khi kết luận vấn đề hay yêu cầu.	BA hỏi, quan sát và đối chiếu bằng chứng để hiểu việc đang diễn ra. Discovery không phải buổi bán giải pháp.
Interview	Phỏng vấn: trao đổi có mục tiêu với người liên quan để thu thập thông tin.	Câu hỏi phải làm rõ ai làm gì, với dữ liệu nào, theo điều kiện nào, và kết quả nào được chấp nhận.
Note taking	Ghi chép: ghi lại phát biểu, quan sát, nguồn và điểm chưa rõ theo cấu trúc.	Ghi chép bảo toàn bằng chứng; không đổi lời kể thành quy tắc hay quyết định chưa được xác nhận.
Actor	Tác nhân: người, vai trò, hệ thống hoặc bộ phận thực hiện hay khởi tạo việc.	Ghi vai trò thay vì tên cá nhân khi mô tả quy trình. Ví dụ: Nhân viên kho, không phải một tên người tổng hợp.
Action	Hành động: việc actor thực hiện.	Dùng động từ kiểm chứng được: tạo, kiểm tra, xác nhận, cập nhật, từ chối. Tránh từ mơ hồ như “xử lý”.
Object	Đối tượng: thứ bị tác động, kiểm tra hoặc thay đổi.	Có thể là phiếu nhập kho, lệnh sản xuất, lô hàng, số lượng, trạng thái hoặc dữ liệu nhà cung cấp.
Outcome	Kết quả: trạng thái, dữ liệu, chứng từ hoặc quyết định sau hành động.	Outcome phải quan sát được. “Phiếu nhập kho có trạng thái Đã ghi nhận” rõ hơn “đã xử lý xong”.
Stakeholder	Người liên quan: cá nhân hoặc nhóm bị ảnh hưởng, cung cấp đầu vào, dùng đầu ra, hoặc có thẩm quyền quyết định.	Stakeholder không luôn là actor. Kế toán có thể dùng dữ liệu nhập kho nhưng không tạo phiếu.
Fact	Sự thật ghi nhận được từ nguồn cụ thể.	Gắn nguồn, thời điểm và ngữ cảnh. Fact không tự chứng minh nguyên nhân hay nhu cầu.
Assumption	Giả định: điều được tạm dùng khi chưa có bằng chứng đủ.	Phải gắn nhãn Project assumption; không ghi thành fact hoặc business rule.
Business rule	Quy tắc nghiệp vụ: điều kiện, ràng buộc hoặc cách quyết định do nghiệp vụ sở hữu.	BA ghi nhận nguồn và owner; không tự tạo quy tắc từ một câu trả lời phỏng vấn.
Requirement	Yêu cầu: nhu cầu hoặc khả năng cần được đáp ứng.	Requirement chỉ hình thành sau khi phân biệt fact, nhu cầu, ràng buộc và quyết định có thẩm quyền.

Công thức ghi nhận tối thiểu: Actor + Action + Object + Outcome. Ví dụ Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dữ liệu tổng hợp: Nhân viên kho xác nhận số lượng thực nhận của phiếu nhập kho; hệ thống lưu số lượng đã xác nhận và trạng thái phiếu. Actor là Nhân viên kho; action là xác nhận; object là số lượng thực nhận của phiếu nhập kho; outcome là số lượng và trạng thái được lưu.

Công thức này không thay thế phân tích. Lý do: cùng một action có thể có outcome khác khi điều kiện khác. Ghi chép đủ điều kiện, nguồn và ngoại lệ trước khi suy ra requirement. Câu “kho kiểm hàng” mới cho biết action; chưa cho biết object cụ thể, tiêu chí kiểm tra, dữ liệu được cập nhật hay ai chịu trách nhiệm khi sai.

Ranh giới khái niệm: discovery interview và note taking thu thập, cấu trúc hóa, truy vết thông tin. Chúng không tự phê duyệt requirement, không tự chọn cấu hình ERP, không xác nhận quy tắc pháp lý, kế toán, thuế, an toàn thực phẩm hay bảo vệ dữ liệu cá nhân. Mọi chi tiết Nova Foods trong chương là mô phỏng, không phải bằng chứng về doanh nghiệp thật hay cấu hình production.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi tên, số lượng và VND dưới đây là dữ liệu tổng hợp. Ví dụ tối thiểu: nhân viên Kho thành phẩm báo rằng khi giao đơn SO-SIM-001, họ phải hỏi Kế toán xem khách có được xuất hàng hay không. BA ghi nhận để hiểu công việc hiện tại, không tự kết luận phải sửa ERP.

Thành phần	Nội dung ghi nhận tối thiểu
Facts	Đơn SO-SIM-001; khách KH-SIM-001; giá trị đơn mô phỏng 12.500.000 VND; Kho phải hỏi Kế toán trước khi xuất.
Current Behavior	Kho mở đơn, gọi Kế toán, chờ trả lời rồi mới quyết định xuất hàng.
Underlying Need	Kho cần biết trạng thái được phép xuất hàng ngay trong lúc xử lý đơn. Bằng chứng: hành động bị dừng vì thông tin nằm ngoài màn hình Kho.
Actor	Nhân viên Kho: người thực hiện hành động.
Action	Kiểm tra: hành động tìm trạng thái trước khi xuất.
Object	Trạng thái được phép xuất hàng của đơn: đối tượng bị kiểm tra.
Outcome	Quyết định xuất hàng hoặc giữ đơn: kết quả nghiệp vụ sau hành động.
Options	Giữ cách gọi Kế toán; cho Kho xem trạng thái; tự động xuất mọi đơn.
Decision Criteria	Giảm thời gian chờ; không trao quyền vượt mức; trạng thái phải có nguồn chịu trách nhiệm.
Decision	Chưa chọn phương án. Discovery chỉ ghi nhận need, options và tiêu chí; quyết định cần Business Owner, Accounting Owner và Architect theo phạm vi ảnh hưởng.
Authority	BA điều phối làm rõ và bảo toàn bằng chứng; không có thẩm quyền đặt quy tắc tín dụng, kế toán hoặc cấu hình ERP.
Artifact	Ghi chú phỏng vấn có nguồn, thời điểm Asia/Ho_Chi_Minh, người nói theo vai trò và câu hỏi mở; chưa là requirement, business rule hay quyết định.
Consequence if Wrong	Nếu hiểu sai “được phép xuất”, ERP có thể chặn đơn hợp lệ hoặc cho xuất đơn không nên xuất; cần xác minh owner trước khi đặc tả.

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

flowchart TB
    subgraph CURRENT["Công việc hiện tại được kể lại"]
        K[Nhân viên Kho] -->|mở và kiểm tra| D[Đơn SO-SIM-001]
        D --> M[Màn hình Kho thiếu trạng thái được phép xuất]
        M --> K2[Nhân viên Kho]
        K2 -->|gọi hỏi trạng thái| KT[Kế toán]
        KT -->|Kho chờ trả lời| W[Đang chờ phản hồi]
        W -->|nhận câu trả lời| R["Phản hồi: được phép xuất,<br/>không được phép xuất hoặc không rõ"]

        R --> Q{"Theo phản hồi được kể lại,<br/>được phép xuất?"}
        Q -->|Có| X[Xuất hàng]
        Q -->|Không| G[Giữ đơn]
        Q -->|Không rõ| U[Chưa quyết định]

        Q -.->|Nếu hiểu sai trạng thái| RK["Rủi ro: chặn đơn hợp lệ<br/>hoặc cho xuất đơn không nên xuất"]
    end

    subgraph DISCOVERY["Ranh giới discovery"]
        N["Ghi chú phỏng vấn:<br/>lời kể cần xác minh"]
        N --> E["Cần Business Owner / Accounting Owner<br/>xác minh bằng chứng trước khi đặc tả"]
        E --> B["BA bảo toàn bằng chứng;<br/>không đặt quy tắc hoặc cấu hình ERP"]
    end

    R -.->|ghi nhận lời kể| N

Ranh giới concept: Discovery interviewing and note taking là hoạt động hỏi, lắng nghe, quan sát và ghi bằng chứng có cấu trúc để làm rõ actor, action, object, outcome, khó khăn và nhu cầu. Nó không phải phiên họp ra quyết định, không phải phê duyệt, không phải thiết kế màn hình, không phải cấu hình ERP, không phải xác nhận quy tắc kế toán hay pháp lý.

Loại trừ: Không suy diễn từ một lời kể thành sự thật toàn doanh nghiệp; không gán cho Nova Foods quy trình vận hành thật; không biến dữ liệu mô phỏng thành hồ sơ khách hàng thật; không trích điều khoản pháp lý, thuế, kế toán hoặc an toàn thực phẩm khi chưa có chủ sở hữu thẩm quyền xác minh. Trạng thái corpus vẫn IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không có baseline hay approval được suy ra từ ví dụ này.

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

Core

Phỏng vấn khám phá và ghi chú có cấu trúc tồn tại để ngăn dự án ERP biến lời kể rời rạc thành yêu cầu, quy tắc hoặc quyết định. Nếu BA chỉ nhớ nội dung họp, cùng câu “đơn cần xử lý gấp” có thể bị hiểu là ưu tiên kho, quyền vượt hạn mức, hay yêu cầu cảnh báo màn hình. Mỗi cách hiểu dẫn tới phạm vi build, kiểm thử và trách nhiệm khác nhau.

Rủi ro chính là mơ hồ nguồn gốc: người phát biểu không nhất thiết là người sở hữu quyết định; hành vi hiện tại không nhất thiết là nhu cầu tương lai; ngoại lệ từng xảy ra không tự thành quy tắc ERP. Ghi chú phải giữ câu hỏi, bối cảnh, vai trò người cung cấp thông tin, thời điểm và điểm chưa rõ. Chuỗi này cho BA quay lại kiểm tra trước khi đội kỹ thuật tạo cấu hình khó đảo ngược.

Rủi ro bị ngăn	Nếu không ghi có cấu trúc	Cơ chế phòng ngừa
Rework	Developer build theo diễn giải riêng; BA phát hiện sai khi demo	Ghi actor, hành động, đối tượng, kết quả mong muốn và ngoại lệ
Scope creep	Một khó khăn cục bộ bị mở rộng thành thay đổi toàn ERP	Ghi phạm vi quy trình, đơn vị áp dụng và điều chưa xác minh
Governance risk	BA ghi “đã quyết định” dù người nói chỉ cung cấp ý kiến	Tách người cung cấp thông tin khỏi Authority quyết định
Test gap	QA không biết điều kiện nào cần kiểm tra	Ghi ví dụ đầu vào, hành vi quan sát được và câu hỏi còn mở
Data-loss risk	Đội build bỏ qua bước đối soát thủ công đang bảo vệ dữ liệu	Ghi current behavior trước khi đề xuất tự động hóa

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 ghi nhận
Facts	Đơn mô phỏng SO-SIM-001 được Nhân viên Kho kiểm tra trước xuất hàng. Màn hình kho không hiển thị lý do Kế toán đang giữ đơn.
Current Behavior	Nhân viên Kho nhắn Kế toán để hỏi trạng thái, rồi xuất hàng hoặc giữ đơn theo câu trả lời nhận được.
Underlying Need	Kho cần biết hành động được phép cho từng đơn mà không suy đoán từ trạng thái thiếu ngữ cảnh.
Options	Hiển thị trạng thái chi tiết; tạo danh sách đơn cần xử lý; giữ cách nhắn tin hiện tại.
Decision Criteria	Đúng quyền truy cập, không lộ thông tin nhạy cảm, giảm hỏi lại, phù hợp quy trình Kế toán và Kho.
Decision	Chưa quyết định. Discovery chỉ làm rõ vấn đề và lựa chọn; không tạo cấu hình ERP.
Authority	Business Owner quyết định nhu cầu vận hành; Accounting Owner xác nhận ý nghĩa giữ đơn; Architect xác nhận cách hiển thị và phân quyền.
Artifact	Ghi chú phỏng vấn có nguồn, vai trò, thời điểm theo Asia/Ho_Chi_Minh, câu hỏi mở và liên kết SO-SIM-001.
Consequence if Wrong	Nếu BA ghi “Kho được xuất khi Kế toán trả lời” thành quy tắc hệ thống, ERP có thể cho phép xuất sai hoặc chặn xuất hợp lệ.

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

flowchart TB
    K[Nhân viên Kho kiểm tra SO-SIM-001]
    M[Màn hình Kho thiếu lý do Kế toán giữ đơn]
    H[Kho hỏi Kế toán]
    A[Câu trả lời Kế toán]
    O[Kho xuất hàng hoặc giữ đơn theo câu trả lời]

    K --> M --> H --> A --> O

    M --> N[Ghi chú discovery: nguồn, vai trò, thời điểm, câu hỏi mở, liên kết SO-SIM-001]
    A --> N
    N --> V[Xác minh nhu cầu, thẩm quyền và ràng buộc]

    BO[Business Owner: quyết định nhu cầu vận hành] --> V
    AO[Accounting Owner: xác nhận ý nghĩa giữ đơn] --> V
    AR[Architect: xác nhận hiển thị và phân quyền] --> V

    V --> C[Tiêu chí: đúng quyền truy cập; không lộ thông tin nhạy cảm; giảm hỏi lại; phù hợp quy trình Kế toán và Kho]
    V --> L[Lựa chọn: hiển thị trạng thái chi tiết]
    V --> Q[Lựa chọn: danh sách đơn cần xử lý]
    V --> T[Lựa chọn: giữ cách nhắn tin hiện tại]

    C --> U[Chưa quyết định]
    L --> U
    Q --> U
    T --> U

    U --> R[Business Owner quyết định sau xác minh]
    R --> E[Discovery không tạo cấu hình ERP]

    A --> X[Rủi ro: biến câu trả lời Kế toán thành quy tắc hệ thống]
    X --> Y[Có thể cho xuất sai hoặc chặn xuất hợp lệ]

Senior Lens

Ghi chú tốt không làm dự án chậm. Nó chuyển chi phí làm rõ từ lúc code, test hoặc vận hành sang lúc thông tin còn rẻ để sửa. BA senior không hỏi “hệ thống cần gì?” rồi chép câu trả lời. BA hỏi ai thực hiện, khi nào, với dữ liệu nào, điều gì xảy ra nếu sai, ai chịu trách nhiệm xác nhận. Mỗi câu trả lời chưa đủ bằng chứng phải giữ là điểm cần làm rõ, không được tự lấp bằng kinh nghiệm.

Quick Reference

• Lời kể phỏng vấn là đầu vào discovery, chưa là requirement.
• Hành vi hiện tại mô tả hiện trạng, chưa chứng minh thiết kế tương lai đúng.
• Người nói có thể biết quy trình nhưng không có Authority quyết định.
• Không ghi “đã phê duyệt”, “đã baseline” hoặc “đã xác nhận” khi corpus còn IN_REVIEW, v0.9.0, ngày 2026-08-07.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi tên giao dịch, vai trò và dữ liệu dưới đây đều tổng hợp. Tình huống: BA phỏng vấn bộ phận Kho và Bán hàng về đơn bán có mặt hàng hết tồn kho, nhưng không ghi rõ thời điểm kiểm tra tồn và người quyết định cho phép giao thiếu.

Thành phần	Trước khi có phỏng vấn và ghi chép có cấu trúc	Sau khi có phỏng vấn và ghi chép có cấu trúc
Facts	Nhân viên nói “còn hàng thì giao”; ghi chú không nêu kho nào, thời điểm nào, hay đơn nào.	Ghi nhận luồng hiện tại: Bán hàng tạo đơn, Kho kiểm tra tồn khả dụng, rồi phản hồi khả năng giao.
Current Behavior	Bán hàng hứa giao đủ với khách trước khi Kho phản hồi. Kho phát hiện thiếu hàng khi chuẩn bị xuất.	Bán hàng chờ trạng thái phản hồi từ Kho trước khi cam kết số lượng giao.
Underlying Need	Cần biết điểm kiểm tra tồn nào làm cơ sở cam kết giao hàng.	Cần một điểm kiểm soát chung giữa đơn bán và phản hồi tồn khả dụng.
Options	Không có lựa chọn được ghi rõ; mỗi nhân viên tự xử lý theo hiểu biết.	Giữ cách hứa trước; hoặc chỉ cam kết sau phản hồi Kho.
Decision Criteria	Không được nêu, nên không thể giải thích vì sao đơn bị giao thiếu hay bị giữ lại.	Ưu tiên tránh cam kết vượt tồn khả dụng, giữ dấu vết người phản hồi và thời điểm phản hồi.
Decision	Không có quyết định ghi nhận; hành vi khác nhau giữa các đơn.	Đề xuất: chỉ phát hành cam kết giao sau phản hồi tồn từ Kho. Đây chưa là quy tắc vận hành được phê duyệt.
Authority	Không xác định ai chịu trách nhiệm chọn cách xử lý thiếu hàng.	Business Owner chịu trách nhiệm quyết định chính sách cam kết giao; Kho xác nhận khả năng xuất; BA ghi nhận và truy vết quyết định.
Artifact	Ghi chú rời rạc, không đủ để đội ERP cấu hình trạng thái đơn hoặc QA lập kiểm thử.	Biên bản phỏng vấn có câu hỏi, câu trả lời, luồng hiện tại, điểm chưa rõ và quyết định cần Business Owner xác nhận.
Consequence if Wrong	Đơn có thể được hứa giao đủ nhưng phiếu xuất chỉ có một phần hàng; Bán hàng phải giải thích lại với khách; đội ERP có thể cấu hình sai thời điểm kiểm tra tồn.	Nếu chọn sai điểm kiểm tra tồn, hệ thống vẫn tạo cam kết không khớp khả năng xuất; QA có cơ sở phát hiện qua kịch bản đơn thiếu hàng trước khi triển khai.

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

flowchart TB
    A[Bán hàng tạo đơn]
    B[Giữ cam kết số lượng giao cho đến khi có phản hồi Kho]
    C[Kho phản hồi số lượng tồn khả dụng, người phản hồi và thời điểm]
    D[BA ghi nhận phản hồi và điểm chưa rõ]
    E[Đề xuất — chờ Business Owner xác nhận:<br/>chỉ cam kết sau phản hồi Kho]
    F[Business Owner xem xét và quyết định chính sách]
    G{Chính sách được phê duyệt?}
    H[Giữ cam kết;<br/>BA ghi nhận điểm chưa rõ]
    I{Tồn khả dụng đủ số lượng đơn?}
    J[Ghi nhận cam kết giao đủ]
    K[Áp dụng chính sách đã phê duyệt:<br/>giao một phần hoặc chờ xử lý]
    L[Ghi nhận cam kết tương ứng]

    A --> B --> C --> D --> E --> F --> G
    G -- Chưa phê duyệt hoặc không chấp thuận --> H
    G -- Đã phê duyệt --> I
    I -- Đủ hàng --> J
    I -- Thiếu hàng --> K --> L

Khác biệt quan sát được không phải là con số hiệu quả giả định. Trước đó, cùng một đơn thiếu hàng có thể dẫn đến lời hứa giao đủ, giao một phần, hoặc chờ xử lý tùy người thực hiện. Sau đó, nhóm có thể chỉ ra đúng điểm khác biệt: trạng thái phản hồi Kho xuất hiện trước cam kết giao. Nhờ vậy, BA không biến câu nói ngắn trong phỏng vấn thành yêu cầu ERP mơ hồ; đội triển khai biết nơi cần làm rõ, còn QA biết hành vi nào phải đối chiếu khi kiểm thử.

Core

Trong phỏng vấn, mỗi câu phải mang nhãn bằng chứng. Không gộp lời nói, suy luận và quyết định thành “yêu cầu”. Gộp sai làm đội dự án xây theo điều chưa chứng minh, rồi phải làm lại khi nguồn có thẩm quyền phủ định.

Nhãn	Nghĩa từ gốc	Điều BA được ghi	Điều BA không được suy ra
Fact đã xác minh	Thông tin có bằng chứng kiểm tra được từ nguồn xác định	Giá trị, nguồn, ngày kiểm tra, người kiểm tra	Ý định tương lai, quy tắc mới, tuân thủ pháp lý
Stakeholder input	Phát biểu hoặc nhu cầu từ người liên quan	Nguyên văn ý nghĩa, vai trò, thời điểm, bối cảnh	Sự thật đã xác minh hoặc quyết định dự án
Project assumption	Giả định tạm để tiếp tục phân tích khi thiếu bằng chứng	Điều giả định, lý do, rủi ro, chủ sở hữu kiểm tra	Requirement đã chốt
Decision	Lựa chọn giữa các phương án theo thẩm quyền rõ	Phương án chọn, tiêu chí, authority, artifact ghi nhận	Approval nếu artifact không ghi approval
Verification-required claim	Khẳng định cần kiểm tra trước khi dùng làm căn cứ	Điều cần kiểm tra, nguồn hoặc vai trò cần xác nhận, hạn xử lý	Quy tắc bắt buộc hay kết luận chuyên môn

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 ghi nhận
Facts	CHAPTER_MANIFEST có Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07. Artifact này nói rõ chưa có baseline reference và approval reference. Đây là fact đã xác minh vì có nguồn canonical, ID và trạng thái đọc được.
Current Behavior	Điều phối viên kho nói: “Cần chặn sửa số lượng sau khi phiếu xuất được xác nhận.” Đây là stakeholder input, không phải fact rằng ERP hiện có chức năng chặn, cũng không phải quyết định.
Underlying Need	Cần biết ai được sửa, trạng thái nào bị chặn, ngoại lệ nào hợp lệ, và bằng chứng kiểm tra nào cần lưu. Suy luận này xuất phát từ động từ “chặn sửa” chưa xác định phạm vi.
Options	1. Chặn mọi sửa đổi sau xác nhận. 2. Cho sửa với quyền quản lý kho. 3. Tạo giao dịch điều chỉnh thay vì sửa phiếu gốc.
Decision Criteria	Khả năng truy vết, tác động vận hành kho, quyền phê duyệt, tác động kế toán, khả năng kiểm thử.
Decision	Chưa có quyết định. BA chỉ ghi ba phương án vì chưa có Business Owner, Accounting Owner và Architect xác nhận.
Authority	Business Owner quyết định vận hành; Accounting Owner xác nhận tác động sổ sách; Architect xác nhận cơ chế hệ thống. BA duy trì traceability, không thay thẩm quyền này.
Artifact	Ghi vào biên bản phỏng vấn với nhãn Stakeholder input; tạo mục Verification required cho tác động kế toán; không ghi thành business rule trong CANONICAL_BUSINESS_RULES.
Consequence if Wrong	Nếu gọi phát biểu kho là fact hoặc decision, đội kỹ thuật có thể khóa sửa sai phạm vi. Kho không xử lý được ngoại lệ hợp lệ, hoặc lịch sử điều chỉnh không đủ để đối chiếu.

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

flowchart TB
    A[Phát biểu trong phỏng vấn] --> B{Có nguồn canonical, ID,<br/>trạng thái đọc được và<br/>nội dung đã đối chiếu?}
    B -- Có --> C[Fact đã xác minh]
    B -- Không --> D{Là ý kiến hoặc nhu cầu<br/>của stakeholder?}

    D -- Không --> F{Cần giả định để<br/>tiếp tục phân tích?}
    F -- Có --> G[Project assumption]
    F -- Không --> H[Verification-required claim]
    G --> U[Giữ nhãn và truy vết<br/>yêu cầu kiểm tra]
    H --> U

    D -- Có --> E[Stakeholder input]
    E --> Q[Ghi Verification required:<br/>tác động kế toán<br/>Owner: Accounting Owner]
    Q --> P[Đánh giá ba phương án:<br/>1. Chặn mọi sửa đổi<br/>2. Cho quản lý kho sửa<br/>3. Tạo giao dịch điều chỉnh]
    P --> O[Tiêu chí: truy vết, vận hành kho,<br/>quyền phê duyệt, kế toán, kiểm thử]

    O --> BO{Business Owner đã chọn<br/>phương án vận hành?}
    BO -- Chưa --> T[Giữ nhãn Stakeholder input<br/>Không ghi vào CANONICAL_BUSINESS_RULES]
    BO -- Có --> AO{Accounting Owner đã xác nhận<br/>tác động sổ sách?}
    AO -- Chưa --> T
    AO -- Có --> L[Lưu nguồn bằng chứng<br/>xác minh kế toán]
    L --> AR{Architect đã xác nhận<br/>cơ chế hệ thống?}
    AR -- Chưa --> T
    AR -- Có --> J[Decision]
    J --> R[Ghi decision record hoặc<br/>canonical artifact phù hợp<br/>kèm approval reference]

    E -. Nâng sai thành Fact hoặc Decision .-> K[Khóa sửa sai phạm vi;<br/>không xử lý được ngoại lệ hợp lệ;<br/>thiếu lịch sử điều chỉnh để đối chiếu]

Senior Lens

Cùng một câu có thể sinh nhiều bản ghi, nhưng không đổi nhãn để làm tài liệu “gọn”. Ví dụ: “Theo luật phải lưu vết mọi sửa đổi” là stakeholder input nếu người nói là quản lý kho. Đây còn là verification-required claim vì yêu cầu pháp lý chỉ được dùng sau khi Legal Owner kiểm tra văn bản chính thức và phạm vi áp dụng. Nếu nhóm tạm phân tích theo hướng có lưu vết, ghi project assumption riêng. Chỉ khi authority chọn cơ chế cụ thể mới ghi decision.

Cầu nối suy luận phải nhìn thấy được: nguồn nào nói gì, nguồn đó chứng minh được gì, phần nào còn chưa chứng minh. IN_REVIEW chứng minh artifact đang xem xét; không chứng minh nội dung được phê duyệt, baseline, compliant hoặc sẵn sàng production.

Quick Reference

Quy tắc ghi chú	Cách viết đúng	Cách viết sai
Fact	“CHAPTER_MANIFEST ghi Status IN_REVIEW, kiểm tra ngày 2026-08-07.”	“Nova Foods đã phê duyệt quy trình.”
Stakeholder input	“Quản lý kho yêu cầu chặn sửa sau xác nhận.”	“Hệ thống phải chặn sửa sau xác nhận.”
Assumption	“Giả định: có thể cần lưu lịch sử điều chỉnh để phân tích; cần xác minh với Accounting Owner.”	“Lịch sử điều chỉnh là rule đã chốt.”
Decision	“Chưa có decision; chờ authority ghi nhận trong artifact kiểm soát.”	“BA quyết định dùng phương án 3.”
Verification required	“Cần Legal Owner xác minh nghĩa vụ pháp lý trước khi tạo requirement.”	“Luật bắt buộc” khi chưa kiểm tra nguồn và phạm vi áp dụng.

3. V? tr? trong Lifecycle

Core

Discovery là giai đoạn khám phá: BA thu thập vấn đề, mục tiêu và bằng chứng ban đầu. Analysis là phân tích: BA tách nhu cầu thành yêu cầu, quy tắc, dữ liệu và tiêu chí chấp nhận. Delivery là xây dựng hoặc cấu hình. Testing là kiểm thử dựa trên test basis, tức tập đầu vào kiểm thử gồm requirement, acceptance criteria và quy tắc đã truy vết. Release là đưa thay đổi đã đủ điều kiện vào môi trường vận hành. Operations là vận hành, ghi nhận sự cố và tín hiệu thay đổi mới.

Ghi chú phỏng vấn không đi thẳng thành yêu cầu. Cầu nối là: phát biểu stakeholder tạo stakeholder input; BA đối chiếu bằng chứng, phân loại fact, assumption, decision hoặc verification required; chỉ nội dung đủ nguồn và đủ thẩm quyền mới làm đầu vào phân tích. Nova Foods Trading & Manufacturing là case mô phỏng; mọi ví dụ dùng dữ liệu tổng hợp.

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

flowchart TB
    S[Phát biểu stakeholder<br/>nguồn được nhận diện] --> N[BA ghi nguyên ý, ngữ cảnh,<br/>thời điểm và vai trò]
    I[Input Discovery mới<br/>có nguồn và bằng chứng] --> N
    N --> C{BA phân loại}

    C -->|Fact| F{Có bằng chứng<br/>và nguồn?}
    C -->|Decision| D{Có nguồn và xác nhận<br/>đúng thẩm quyền?}
    C -->|Assumption hoặc<br/>verification required| Q[Bản ghi truy vết<br/>giữ nhãn và câu hỏi mở<br/>không dùng làm requirement<br/>hoặc chỉ dẫn build]

    F -->|Có| TR[Bản ghi truy vết đủ điều kiện<br/>làm đầu vào Analysis<br/>có nguồn, loại và liên kết]
    F -->|Không| Q
    D -->|Có| TR
    D -->|Không| Q

    Q -->|Bổ sung bằng chứng hoặc<br/>xác nhận thẩm quyền| C

    TR --> A[Analysis<br/>làm rõ requirement, rule, data<br/>và acceptance criteria]
    A -->|Requirement và acceptance criteria<br/>liên kết về nguồn;<br/>mâu thuẫn được ghi nhận| DE[Delivery<br/>cấu hình hoặc mã]
    DE -->|Thay đổi liên kết với requirement;<br/>chênh lệch được ghi nhận| T[Testing<br/>thực thi test basis]
    T -->|Kết quả test, defect và rủi ro<br/>được ghi nhận| R[Release<br/>gói phát hành]
    R -->|Gói phát hành có truy vết;<br/>nội dung chưa xác minh giữ nhãn| O[Operations<br/>theo dõi, sự cố, phản hồi]
    O -->|Phản hồi có bằng chứng| I

    A -. cập nhật liên kết .-> TR
    DE -. ghi chênh lệch .-> TR
    T -. nêu test basis .-> TR
    R -. giữ truy vết và nhãn .-> TR

Giai đoạn	Entry gate chính xác	Hoạt động ghi chú/phỏng vấn	Exit gate chính xác
Discovery	Có vấn đề hoặc cơ hội được ghi nhận; phạm vi trao đổi ban đầu xác định; nguồn phát biểu nhận diện được	Ghi nguyên ý, ngữ cảnh, thời điểm, vai trò; tách fact khỏi nhận định	Mỗi ghi chú có nguồn, loại thông tin, câu hỏi còn mở; không biến phát biểu thành rule
Analysis	Ghi chú Discovery truy vết được; assumption và verification required còn hiệu lực được nhìn thấy	Làm rõ thuật ngữ, luồng, dữ liệu, ngoại lệ, tiêu chí chấp nhận	Requirement và acceptance criteria có liên kết về nguồn; điểm mâu thuẫn không bị che giấu
Delivery	Phạm vi triển khai liên kết requirement; nội dung chưa xác minh không bị đưa thành chỉ dẫn build	Giải thích ý nghĩa nghiệp vụ khi Delivery hỏi; cập nhật truy vết nếu phát hiện hiểu sai	Thay đổi xây dựng liên kết được với requirement; chênh lệch phát hiện được ghi nhận
Testing	Test basis truy vết được về requirement, rule hoặc acceptance criteria	Làm rõ intent khi test case không phản ánh ghi chú nguồn	Kết quả test nêu test basis; defect không tự đổi requirement
Release	Kết quả Testing và rủi ro còn lại được ghi nhận trong artifact kiểm soát	Bảo đảm ghi chú vận hành không thêm cam kết chưa phân tích	Gói phát hành chỉ chứa nội dung có truy vết; nội dung chưa xác minh giữ nhãn
Operations	Có thay đổi đã phát hành và kênh ghi nhận phản hồi	Thu thập sự cố, câu hỏi, hành vi thực tế như input mới	Phản hồi có bằng chứng quay lại Discovery; không tự coi phản hồi là decision

Applied

Facts: Trong Nova Foods mô phỏng, ghi chú ngày 2026-08-07 nêu: “Nhân viên kho khó biết ai sửa số lượng sau khi phiếu được xác nhận.” Đây là stakeholder input, chưa chứng minh có nghĩa vụ pháp lý hoặc rule ERP.

Current Behavior: Discovery ghi phát biểu, nguồn và ngữ cảnh. Nếu BA viết ngay “hệ thống phải khóa sửa số lượng”, Analysis sẽ nhận một requirement chưa có bằng chứng về phạm vi, ngoại lệ hoặc authority.

Underlying Need: Cần xác định nhu cầu kiểm soát điều chỉnh sau xác nhận, không suy diễn cơ chế khóa vĩnh viễn.

Options: (1) Ghi audit trail cho thay đổi; (2) chặn sửa trực tiếp và tạo điều chỉnh riêng; (3) cho sửa với quyền hạn theo vai trò. Các phương án là lựa chọn phân tích, không phải quyết định Nova Foods.

Decision Criteria: Mỗi phương án phải được đánh giá theo khả năng truy vết, tác động vận hành kho, dữ liệu liên quan, rủi ro và bằng chứng authority.

Decision: Chưa có decision. Exit gate Discovery đạt khi câu hỏi “loại thay đổi nào cần kiểm soát, trong thời gian nào, và ngoại lệ nào tồn tại?” được ghi rõ để Analysis xử lý.

Authority: Chưa ghi nhận authority quyết định. BA không được chọn phương án thay cho Business Owner, Accounting Owner, Security hoặc Legal Owner khi phạm vi thuộc các vai trò này.

Artifact: Ghi chú nguồn chuyển sang requirement draft chỉ sau Analysis; liên kết giữ trong artifact kiểm soát như CANONICAL_BUSINESS_RULES hoặc CANONICAL_DATA_DICTIONARY khi phạm vi phù hợp.

Consequence if Wrong: Nếu bỏ exit gate Discovery, Delivery có thể xây khóa sửa sai phạm vi; Testing không có acceptance criteria đúng; Release đưa rủi ro vận hành vào môi trường dùng thật.

Senior Lens

Entry gate kiểm tra “có đủ đầu vào để bắt đầu chưa”. Exit gate kiểm tra “đầu ra có đủ cấu trúc để giai đoạn sau dùng mà không tự đoán không”. Gate không phải approval. IN_REVIEW tại v0.9.0 ngày 2026-08-07 chỉ cho biết corpus đang được xem xét.

Không dùng vòng đời như thác nước cứng. Operations có thể phát hiện sự cố rồi quay về Discovery. Lý do: sự cố là bằng chứng mới về hành vi hoặc nhu cầu; nó chưa tự chứng minh nguyên nhân, requirement hay giải pháp.

Quick Reference

Quy tắc	Áp dụng
Discovery không tạo rule	Ghi phát biểu là stakeholder input, kèm nguồn và câu hỏi cần xác minh
Analysis không tự sửa nguồn	Giữ liên kết đến ghi chú gốc và nêu cầu nối suy luận
Delivery không nhận assumption như yêu cầu chốt	Chỉ dùng nội dung đã được phân tích, truy vết và kiểm soát
Testing không tự tạo business rule	Kiểm thử theo test basis có nguồn
Operations không là approval	Phản hồi vận hành quay lại Discovery làm input mới

Core

Trong Nova Foods Trading & Manufacturing, case mô phỏng giáo dục dùng dữ liệu tổng hợp, ghi chú phỏng vấn không tự biến thành quyết định. Handoff là bàn giao có kiểm soát giữa vai trò: người gửi nêu факт, nguồn, điểm chưa rõ và câu hỏi; người nhận xác nhận phạm vi xử lý. Lý do: cùng một ghi chú có thể chứa nhu cầu nghiệp vụ, giả định dự án và vấn đề pháp lý; mỗi loại thuộc thẩm quyền khác nhau.

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

flowchart TB
    U[Business Owner hoặc Process Owner<br/>nêu mục tiêu và vấn đề]
    BA[BA<br/>ghi nhận, phân loại, truy vết]
    H[BA bàn giao:<br/>thông tin thực chứng, nguồn,<br/>điểm chưa rõ, câu hỏi]
    C{Loại nội dung<br/>và owner phù hợp?}

    U --> BA --> H --> C

    C -->|Hành vi nghiệp vụ| SME[Domain SME]
    C -->|Khả thi kỹ thuật| ARCH[Solution Architect]
    C -->|Nghĩa vụ pháp lý| LEGAL[Legal/Compliance Owner]
    C -->|Kế toán, thuế| ACC[Accounting Owner]
    C -->|Test basis| QA[QA Owner]
    C -->|Yêu cầu đủ điều kiện| DEL[Delivery Owner]
    C -->|Tác động vận hành| OPS[Operations Owner]

    SME --> S1{Xác nhận phạm vi xử lý?}
    ARCH --> S2{Xác nhận phạm vi xử lý?}
    LEGAL --> S3{Xác nhận phạm vi xử lý?}
    ACC --> S4{Xác nhận phạm vi xử lý?}
    QA --> S5{Xác nhận phạm vi xử lý?}
    DEL --> S6{Xác nhận phạm vi xử lý?}
    OPS --> S7{Xác nhận phạm vi xử lý?}

    S1 -->|Đúng phạm vi| P1[Xử lý hành vi nghiệp vụ]
    S2 -->|Đúng phạm vi| P2[Đánh giá khả thi kỹ thuật]
    S3 -->|Đúng phạm vi| P3[Xác minh nghĩa vụ pháp lý]
    S4 -->|Đúng phạm vi| P4[Xác minh kế toán, thuế]
    S5 -->|Đúng phạm vi| P5[Nhận test basis]
    S6 -->|Đúng phạm vi| P6[Nhận yêu cầu đủ điều kiện]
    S7 -->|Đúng phạm vi| P7[Nhận tác động vận hành]

    S1 -->|Thiếu thông tin| BA
    S2 -->|Thiếu thông tin| BA
    S3 -->|Thiếu thông tin| BA
    S4 -->|Thiếu thông tin| BA
    S5 -->|Thiếu thông tin| BA
    S6 -->|Thiếu thông tin| BA
    S7 -->|Thiếu thông tin| BA

    S1 -->|Sai phạm vi| ESC[Escalation]
    S2 -->|Sai phạm vi| ESC
    S3 -->|Sai phạm vi| ESC
    S4 -->|Sai phạm vi| ESC
    S5 -->|Sai phạm vi| ESC
    S6 -->|Sai phạm vi| ESC
    S7 -->|Sai phạm vi| ESC

    BA -. xung đột, chưa rõ owner<br/>hoặc vượt thẩm quyền .-> ESC

    ESC --> E[Xác định owner có thẩm quyền]
    E --> F{Đã xác định owner?}

    F -->|Có: hành vi nghiệp vụ| SME
    F -->|Có: khả thi kỹ thuật| ARCH
    F -->|Có: nghĩa vụ pháp lý| LEGAL
    F -->|Có: kế toán, thuế| ACC
    F -->|Có: test basis| QA
    F -->|Có: yêu cầu đủ điều kiện| DEL
    F -->|Có: tác động vận hành| OPS
    F -->|Chưa xác định| OPEN[Giữ mở và yêu cầu chỉ định owner]

Điểm bàn giao	Upstream owner	Downstream owner	BA bàn giao	Giới hạn thẩm quyền BA
Ghi nhận nhu cầu	Business Owner hoặc Process Owner	BA	Mục tiêu, vấn đề, ví dụ tổng hợp, người cung cấp thông tin	Không xác nhận nhu cầu là ưu tiên cuối cùng
Làm rõ hành vi hiện tại	BA	Domain SME	Ghi chú có nguồn, câu hỏi mở, diễn giải BA tách riêng	Không thay SME xác nhận quy trình
Đánh giá giải pháp	BA	Solution Architect	Nhu cầu, ràng buộc, dữ liệu bị ảnh hưởng	Không chọn kiến trúc, tích hợp, kiểm soát bảo mật
Xác minh nghĩa vụ	BA	Legal/Compliance Owner, Accounting Owner	Yêu cầu có yếu tố dữ liệu cá nhân, hóa đơn, kế toán, thực phẩm	Không diễn giải luật, thuế, kế toán
Chuẩn bị delivery và test	BA	Delivery Owner, QA Owner	Requirement đã truy vết, tiêu chí chấp nhận, giả định và rủi ro	Không tự chấp nhận build hoặc kết quả test
Chuẩn bị vận hành	BA	Operations Owner	Tác động vai trò, dữ liệu, quy trình, hỗ trợ	Không cho phép release hoặc thay đổi vận hành

Applied

Trường	Nội dung
Facts	Người dùng kho Nova Foods mô phỏng nói “cần khóa sửa số lô sau khi nhập kho”. Ghi chú chỉ có ví dụ tổng hợp, chưa có nguồn quy tắc được xác nhận.
Current Behavior	Hệ thống ERP giả định cho phép nhân viên kho sửa số lô sau khi ghi nhận nhập kho. Đây là mô tả từ phỏng vấn, không phải kết luận cấu hình thực tế.
Underlying Need	Bảo toàn khả năng truy vết lô và giảm sửa nhầm. Suy luận này dựa trên lời mô tả về việc sửa số lô; cần SME xác nhận mục tiêu và phạm vi.
Options	Khóa hoàn toàn; cho sửa theo quyền; tạo giao dịch điều chỉnh có lịch sử.
Decision Criteria	Khả năng truy vết, tác động vận hành kho, quyền truy cập, khả năng kỹ thuật, nghĩa vụ pháp lý cần xác minh.
Decision	Chưa quyết định. BA ghi nhận ba lựa chọn và chuyển đúng owner.
Authority	Process Owner xác nhận nhu cầu; Food Safety/Domain SME xác nhận truy vết; Solution Architect đánh giá thiết kế; Security Owner đánh giá quyền; Legal/Compliance Owner xác minh nghĩa vụ pháp lý.
Artifact	Ghi chú phỏng vấn liên kết TRACEABILITY_ID_REGISTRY, tham chiếu nguồn quy tắc dự kiến CANONICAL_BUSINESS_RULES và dữ liệu dự kiến CANONICAL_DATA_DICTIONARY. Các artifact hiện IN_REVIEW, v0.9.0, chưa baseline, chưa approval.
Consequence if Wrong	Khóa sai có thể chặn sửa lỗi hợp lệ; mở sai có thể làm mất dấu vết lô. Vì hậu quả tác động vận hành và an toàn thực phẩm, BA phải escalation thay vì tự chọn.

Senior Lens

Escalation không phải chuyển việc vô cớ. Escalation kích hoạt khi ghi chú vượt quyền người phỏng vấn, hai nguồn mâu thuẫn, hoặc quyết định chạm pháp lý, kế toán, bảo mật, kiến trúc, chất lượng hay vận hành. Bằng chứng phải đi kèm câu hỏi escalation: “Ai nói gì, ở thời điểm nào, artifact nào bị ảnh hưởng, quyết định nào cần owner trả lời, nếu không quyết định thì rủi ro gì.” Cầu nối reasoning là: có rủi ro chuyên môn đặc thù nên cần người chịu trách nhiệm chuyên môn xác nhận; BA bảo toàn ngữ cảnh và truy vết, không thay kết luận đó.

Không ghi “đã phê duyệt” khi chỉ có người tham gia phỏng vấn đồng ý miệng. IN_REVIEW chỉ nói artifact đang được xem xét. Nó không tạo baseline, approval, tuân thủ, quyền release hay quyền dùng production.

Quick Reference

Tình huống	Handoff hoặc escalation
Người dùng nêu quy tắc giá, chiết khấu, hạn mức	Business Owner hoặc Process Owner xác nhận
Ghi chú chứa cách tính thuế, hạch toán, hóa đơn	Accounting Owner và Legal/Compliance Owner xác minh
Ghi chú yêu cầu phân quyền, nhật ký, dữ liệu cá nhân	Security Owner; Legal/Compliance Owner nếu có nghĩa vụ pháp lý
Ghi chú yêu cầu API, tích hợp, thay đổi dữ liệu	Solution Architect đánh giá
Ghi chú nói hành vi hiện tại mâu thuẫn giữa hai phòng ban	Escalate Process Owner; giữ cả hai nguồn, không tự chọn
Ghi chú ảnh hưởng kiểm thử hoặc tiêu chí chấp nhận	QA Owner nhận test basis sau khi owner nghiệp vụ xác nhận

Core

Bản đồ vòng đời giúp người mới thấy discovery (khám phá nhu cầu) không phải buổi hỏi đáp tách rời. Ghi chú phỏng vấn đi qua các pha, bị làm rõ thành yêu cầu, được chuyển thành cấu hình hoặc phần mềm, rồi trở thành căn cứ kiểm thử và hỗ trợ vận hành. Sơ đồ dùng trạng thái luồng học liệu Nova Foods Trading & Manufacturing, mô phỏng giáo dục, dữ liệu tổng hợp; không xác nhận quy trình ERP thực tế.

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

flowchart TB
    D[Discovery<br/>Thu thập ghi chú phỏng vấn] --> A[Analysis<br/>Làm rõ nhu cầu, quy tắc, dữ liệu]
    A --> DV[Delivery<br/>Cấu hình, phát triển, tài liệu giao nhận]
    DV --> T[Testing<br/>Kiểm tra theo yêu cầu và tiêu chí chấp nhận]
    T --> R[Release<br/>Chuẩn bị phát hành]
    R --> O[Operations<br/>Vận hành, ghi nhận phản hồi]

    A -. yêu cầu chưa rõ hoặc mâu thuẫn<br/>cần làm rõ bằng ghi chú .-> D
    T -. bằng chứng cần đối chiếu lại<br/>yêu cầu, ghi chú, quy tắc .-> A
    O -. phản hồi vận hành cần khám phá .-> D

Mũi tên liền biểu thị dòng chính: đầu ra pha trước trở thành đầu vào pha sau. Mũi tên nét đứt biểu thị vòng phản hồi: không tự sửa suy đoán trong pha sau; quay về pha tạo bằng chứng phù hợp. Ví dụ, lỗi kiểm thử không tự chứng minh yêu cầu sai. Lỗi là bằng chứng cần đối chiếu lại yêu cầu, ghi chú và quy tắc liên quan.

Applied

Trường	Nội dung mô phỏng Nova Foods
Facts	Nhân viên kho nói “cần chặn xuất hàng thiếu tồn”; ghi chú chưa nêu kho nào, thời điểm kiểm tra, hay cách xử lý đơn giao thiếu.
Current Behavior	Discovery chỉ ghi nguyên ý người nói và bối cảnh cuộc trao đổi.
Underlying Need	Analysis cần biến ý nói thành nhu cầu có thể kiểm tra: điều kiện chặn, dữ liệu tồn, ngoại lệ và thông báo.
Options	Giữ ghi chú như nguồn tham khảo; hoặc suy đoán ngay thành quy tắc cấu hình.
Decision Criteria	Có đủ bằng chứng về phạm vi, quy tắc và ngoại lệ; có thể tạo test basis hay không.
Decision	Giữ ghi chú ở Discovery, chuyển câu hỏi chưa rõ sang Analysis; không coi câu nói đơn lẻ là quy tắc ERP.
Authority	Sơ đồ không trao quyền phê duyệt cho BA; thẩm quyền xác nhận nội dung nằm ngoài sơ đồ này.
Artifact	Ghi chú phỏng vấn và liên kết truy vết đến /01-curriculum/CANONICAL_BUSINESS_RULES.md khi quy tắc được quản trị.
Consequence if Wrong	Delivery có thể cấu hình chặn xuất sai phạm vi; Testing không có căn cứ kiểm tra; Operations phát sinh обход quy trình hoặc chậm giao hàng.

Senior Lens

Sơ đồ không nói mỗi pha chỉ xảy ra một lần. Nó nói mỗi loại quyết định cần quay về đúng nơi có bằng chứng. Discovery trả lời “đã nghe gì, từ ai, trong ngữ cảnh nào”; Analysis trả lời “điều đó nghĩa gì cho yêu cầu”. Delivery, Testing, Release và Operations không được biến ghi chú mơ hồ thành sự thật nghiệp vụ. Lý do: ghi chú là bằng chứng thô, không phải yêu cầu đã được xác nhận.

Quick Reference

Ký hiệu	Cách đọc
Mũi tên liền	Chuyển đầu ra học liệu sang pha kế tiếp
Mũi tên nét đứt	Phản hồi để làm rõ, không phải phê duyệt
Discovery → Analysis	Ghi nhận bằng chứng trước, diễn giải sau
Testing → Analysis	Lỗi hoặc thiếu căn cứ kiểm tra cần làm rõ yêu cầu
Operations → Discovery	Phản hồi vận hành tạo nhu cầu khám phá mới

4. Input c?n thi?t

Core

Đầu vào là thứ BA cần có trước khi hỏi, ghi chú và diễn giải. Người mới không cần biết ERP trước: ERP là phần mềm nối dữ liệu giữa mua hàng, kho, sản xuất, bán hàng và kế toán. BA không bắt đầu bằng cấu hình phần mềm. BA bắt đầu bằng tri thức nền, bằng chứng và artifact nguồn.

Tri thức nền tối thiểu gồm: mục tiêu phiên làm việc; từ ngữ nghiệp vụ; đối tượng đang xét; quy trình liên quan; người cung cấp thông tin; giới hạn thẩm quyền. Bằng chứng là nội dung có thể truy về nguồn, như tài liệu kiểm soát, biểu mẫu, dữ liệu mẫu tổng hợp hoặc mô tả công việc. Artifact nguồn là tệp hoặc URL chứa bằng chứng. Không coi trí nhớ BA, lời kể không ghi nhận nguồn, hay suy luận từ phần mềm là bằng chứng.

Canonical ID là mã định danh giữ nguyên giữa các artifact. Mã này ngăn BA nối nhầm tài liệu, quy tắc hay dữ liệu. Ví dụ CANONICAL_BUSINESS_RULES luôn chỉ catalog quy tắc nghiệp vụ; không đổi thành “Rule Catalog” trong liên kết truy vết.

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

flowchart TB
    A["Tri thức nền"] --> D["Chuẩn bị Discovery"]
    B["Artifact nguồn: tệp hoặc URL"] --> C["Bằng chứng truy về nguồn"]
    C --> D
    E["Canonical ID giữ liên kết giữa artifact"] --> D
    D --> F["Ghi chú có truy vết"]
    F --> G["Phân tích sau Discovery"]

Applied

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

Mục	Nội dung
Facts	BA chuẩn bị trao đổi về luồng xuất hàng cho khách bán lẻ mô phỏng. Corpus đã có artifact quản trị và nguồn chuẩn.
Current Behavior	Người mới có thể mở ERP giả định, thấy trường dữ liệu, rồi hỏi người dùng “trường này dùng làm gì”. Cách này lấy màn hình làm nguồn chân lý.
Underlying Need	Ghi nhận nhu cầu xuất hàng dựa trên bằng chứng truy được nguồn, trước khi suy luận về màn hình hay cấu hình.
Options	Dùng lời kể làm nguồn duy nhất; hoặc lập inventory đầu vào có artifact, URL, ID và mục đích sử dụng.
Decision Criteria	Mỗi đầu vào phải trả lời được: biết gì trước khi hỏi, bằng chứng nằm đâu, artifact nào kiểm soát nội dung, và ID nào phải giữ nguyên.
Decision	Dùng inventory bên dưới. Chỉ dùng dữ liệu tổng hợp Nova Foods và artifact đã nêu.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì traceability học liệu; không xác nhận quy tắc vận hành, pháp lý, kế toán hay cấu hình production.
Artifact	Ghi chú Discovery liên kết về đúng artifact nguồn và canonical ID.
Consequence if Wrong	BA có thể ghi nhận quy tắc sai nguồn, nối nhầm requirement với tài liệu khác, hoặc biến giả định màn hình thành nhu cầu nghiệp vụ.

Loại đầu vào	Tri thức hoặc bằng chứng cần có	Artifact nguồn	Canonical ID hoặc định danh giữ nguyên	Vai trò trong Discovery
Bối cảnh corpus	Case study là Nova Foods Trading & Manufacturing, mô phỏng giáo dục, dữ liệu tổng hợp, vi-VN, Asia/Ho_Chi_Minh, VND	/01-curriculum/CHAPTER_MANIFEST.md	CHAPTER_MANIFEST	Ngăn dùng dữ liệu như doanh nghiệp thật hoặc suy diễn production
Cấu trúc học liệu	Chapter này thuộc handbook; tên tệp được kiểm soát là /02-handbook/03-discovery-interviewing-and-note-taking.md	/01-curriculum/CHAPTER_MANIFEST.md	CHAPTER_MANIFEST	Giữ đúng phạm vi Discovery và Note Taking
Định danh truy vết	Registry quản lý ID giữa requirement, rule, data, risk và artifact	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	TRACEABILITY_ID_REGISTRY	Giữ nguyên ID khi ghi liên kết
Quy tắc nghiệp vụ	Catalog quy tắc nghiệp vụ canonical là nơi quản trị quy tắc sau khi đủ bằng chứng và đúng thẩm quyền	/01-curriculum/CANONICAL_BUSINESS_RULES.md	CANONICAL_BUSINESS_RULES	Phân biệt ghi chú thô với quy tắc đã quản trị
Dữ liệu nghiệp vụ	Từ điển dữ liệu logic canonical là nguồn tham chiếu cho tên dữ liệu và ý nghĩa dữ liệu	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	CANONICAL_DATA_DICTIONARY	Hỏi đúng về mã hàng, số lượng, đơn vị tính, kho và trạng thái
Thuật ngữ BA	BABOK Guide dùng cho thuật ngữ, knowledge areas, tasks và competencies của BA	https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/	BABOK Guide, Version 3	Dùng thuật ngữ chuyên môn; không bịa số trang hay điều khoản
Requirement	ISO/IEC/IEEE 29148 dùng cho bối cảnh yêu cầu và đặc tả yêu cầu	https://www.iso.org/standard/72089.html	ISO/IEC/IEEE 29148:2018	Nhắc BA rằng ghi chú Discovery chưa tự thành requirement
Nguồn pháp lý	Luật An toàn thực phẩm là nguồn bối cảnh cho traceability và recall	https://vanban.chinhphu.vn/?docid=96032&pageid=27160	Luật 55/2010/QH12	Không diễn giải nghĩa vụ pháp lý; cần Domain Owner và Legal Owner xác minh

Senior Lens

Bridge suy luận phải hiện rõ: artifact nguồn nói gì, BA dùng phần nào để chuẩn bị câu hỏi, rồi ghi chú nào cần liên kết ngược về artifact đó. Ví dụ, CANONICAL_DATA_DICTIONARY tồn tại để quản trị dữ liệu logic; vì vậy BA dùng nó để hỏi “mã lô được ghi tại bước nào?”, không được suy ra “ERP phải chặn xuất hàng thiếu mã lô”. Câu sau là yêu cầu hoặc quy tắc tiềm năng, cần bằng chứng và thẩm quyền riêng.

Không đổi tên, dịch tùy ý, hay tự tạo biến thể cho canonical ID. TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY là định danh quản trị; tên hiển thị tiếng Việt có thể giải thích, nhưng liên kết phải giữ chuỗi gốc.

Quick Reference

Khái niệm	Cách hiểu ngắn	Không phải
Tri thức nền	Điều BA cần hiểu để hỏi đúng	Cấu hình ERP đã được xác nhận
Bằng chứng	Nội dung truy được nguồn	Ý kiến nhớ lại không có nguồn
Artifact nguồn	Tệp hoặc URL chứa bằng chứng	Bản sao không kiểm soát
Canonical ID	Mã định danh giữ nguyên	Nhãn tự dịch hoặc tên rút gọn
Ghi chú Discovery	Bản ghi đã nghe, đã thấy, có ngữ cảnh	Quy tắc nghiệp vụ đã xác nhận

Core

Đầu vào phỏng vấn chỉ dùng được khi BA biết nó đến từ đâu, còn mới hay không, ai chịu trách nhiệm nội dung, và lỗi nào buộc phải dừng. Phân loại nguồn là nhãn nói rõ độ tin cậy và ranh giới sử dụng: nguồn primary là tài liệu do tổ chức/nhà phát hành có thẩm quyền công bố; nguồn internal-controlled là artifact corpus có ID, đường dẫn, Status và Version; nguồn stakeholder statement là phát biểu cần đối chiếu bằng bằng chứng; project assumption là giả định học liệu; Verification required là nội dung chưa đủ bằng chứng để dùng làm kết luận.

Kiểm tra chất lượng	Điều kiện đạt	Không đạt thì xử lý
Định danh	Có Artifact ID hoặc URL canonical; tên tệp giữ nguyên	Không tự đặt ID thay thế; ghi Verification required
Phân loại	Có một nhãn nguồn rõ ràng	Không suy diễn phát biểu thành quy tắc
Tính mới	Ngày truy cập/cập nhật xác định; kiểm tra thay đổi pháp lý hoặc version	Dừng dùng làm cơ sở quyết định nếu nguồn quá hạn hoặc không rõ ngày
Owner	Có vai trò chịu trách nhiệm xác nhận nội dung	Escalate khi nội dung vượt thẩm quyền BA
Nhất quán	Không mâu thuẫn nguồn canonical khác	Dừng tổng hợp kết luận đến khi mâu thuẫn được phân giải
Ranh giới	Không biến học liệu mô phỏng thành cấu hình ERP, nghĩa vụ pháp lý, hay phê duyệt	Giữ nhãn giả định hoặc Verification required

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

flowchart TB
    A[Nguồn đầu vào] --> B{Có ID hoặc URL canonical?}
    B -- Không --> S[Dừng sử dụng làm kết luận<br/>Gắn Verification required]
    B -- Có --> C{Phân loại nguồn rõ?}
    C -- Không --> S
    C -- Có --> D{Còn mới và có ngày kiểm tra?}
    D -- Không --> S
    D -- Có --> E{Có Owner đúng thẩm quyền?}
    E -- Không --> X[Escalate đúng vai trò]
    X -- Sau khi xác nhận Owner đúng thẩm quyền --> E
    X -- Không xác nhận được --> S
    E -- Có --> F{Mâu thuẫn nguồn canonical?}
    F -- Có --> S
    F -- Không --> H{Giữ đúng ranh giới sử dụng?<br/>Không biến học liệu mô phỏng thành cấu hình ERP,<br/>nghĩa vụ pháp lý hoặc phê duyệt}
    H -- Không --> I[Chỉ dùng như giả định<br/>hoặc Verification required<br/>Không đủ điều kiện làm kết luận]
    H -- Có --> G[Đủ điều kiện dùng làm đầu vào phỏng vấn]

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 ở IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND.

Current Behavior: BA nhận một ghi chú nói “ERP phải lưu truy xuất lô thực phẩm”. Ghi chú không có Artifact ID, URL, ngày cập nhật, hay tên người có thẩm quyền. Đây là stakeholder statement, không phải requirement hoặc quy tắc đã xác nhận.

Underlying Need: Trước phỏng vấn, BA cần phân biệt câu hỏi cần làm rõ với thông tin đủ sức làm căn cứ. Bằng chứng là CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY đều là artifact canonical nhưng đang IN_REVIEW; vì vậy chúng giữ định danh và traceability, không xác nhận vận hành thực tế.

Options: (1) Dùng ghi chú làm quy tắc ERP; (2) Bỏ ghi chú; (3) Dùng ghi chú để đặt câu hỏi, giữ nhãn Verification required, và đối chiếu nguồn có thẩm quyền.

Decision Criteria: Chọn phương án không tạo yêu cầu giả, không vượt thẩm quyền Legal Owner hoặc Food-safety domain owner, và giữ được nguồn gốc thông tin.

Decision: Chọn phương án 3. Ghi chú là input để khám phá, chưa là kết luận.

Authority: Principal IT Business Analyst / Technical Curriculum Author quản lý artifact và traceability. Xác nhận nghĩa vụ pháp lý hoặc an toàn thực phẩm thuộc Legal Owner và domain owner có thẩm quyền.

Artifact: Tham chiếu /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md; giữ nguyên các ID CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY.

Consequence if Wrong: Nếu BA biến ghi chú thành quy tắc, đội dự án có thể thiết kế chức năng sai, bỏ sót yêu cầu thật, hoặc trình bày giả định học liệu như nghĩa vụ pháp lý.

Senior Lens

Freshness không có nghĩa “tài liệu mới nhất theo cảm giác”. Freshness là điều kiện kiểm tra theo loại nguồn. Với luật, nghị định, tiêu chuẩn, đặc tả và API, kiểm tra version, trạng thái hiệu lực hoặc ngày truy cập trước khi dùng. Với phát biểu stakeholder, ghi thời điểm phát biểu và bối cảnh quy trình. Với artifact controlled, kiểm tra đúng đường dẫn, Status IN_REVIEW, Version v0.9.0 và ngày 2026-08-07. Nguồn cũ vẫn có thể dùng để hiểu lịch sử, nhưng không được dùng một mình để quyết định trạng thái hiện tại.

Điều kiện dừng áp dụng khi thiếu định danh canonical, nguồn mâu thuẫn, owner không đúng thẩm quyền, hoặc nội dung pháp lý, kế toán, thuế, bảo mật, an toàn thực phẩm bị diễn đạt như kết luận khi chưa xác minh. Dừng không phải thất bại. Dừng ngăn BA tạo certainty giả; đầu ra đúng lúc này là vấn đề được gắn nhãn, bằng chứng thiếu, và vai trò cần xác minh.

Quick Reference

Nhãn	Nghĩa	Có thể dùng làm kết luận?
Primary source	Nguồn chính thức từ cơ quan hoặc tổ chức phát hành	Có, trong ranh giới nguồn và thẩm quyền
Internal-controlled	Artifact corpus có ID, đường dẫn, version, status	Có cho quản trị corpus; không tự xác nhận nghiệp vụ
Stakeholder statement	Thông tin người liên quan cung cấp	Chưa; cần đối chiếu
Project assumption	Giả định phục vụ case mô phỏng	Chưa; phải giữ nhãn
Verification required	Thiếu bằng chứng hoặc xác nhận	Không; là điều kiện dừng kết luận

Core

Bảng dưới là bộ đầu vào mô phỏng cho Nova Foods Trading & Manufacturing. Mọi giá trị nghiệp vụ là dữ liệu tổng hợp, không chứng minh cấu hình ERP, hoạt động doanh nghiệp thật, tuân thủ pháp lý, baseline hay phê duyệt.

Nhóm đầu vào	Canonical ID / tên nguồn	Tệp hoặc URL canonical	Phân loại nguồn	Giá trị mô phỏng dùng khi phỏng vấn	Owner nguồn	Độ mới tại 2026-08-07	Trạng thái xác minh
Bối cảnh curriculum	01_CURRICULUM_ARCHITECTURE	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Controlled planning artifact	Locale vi-VN; múi giờ Asia/Ho_Chi_Minh; tiền tệ VND; Nova Foods là case mô phỏng	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07	Có thể dùng làm bối cảnh; không là approval
Danh mục chapter	CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Controlled planning artifact	Chapter 03 Discovery Interviewing And Note Taking; trạng thái IN_REVIEW; version v0.9.0	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07	Có thể dùng cho tên, đường dẫn, phạm vi
Registry định danh	TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Controlled planning artifact	ID phải giữ nguyên dạng canonical khi ghi note và liên kết artifact	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07	Có thể dùng cho truy vết; không tự tạo ID mới
Catalog quy tắc	CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Controlled planning artifact	Chưa có quy tắc Nova Foods được baseline	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07	Chỉ tham chiếu; Cần xác minh trước khi coi là rule
Từ điển dữ liệu	CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Controlled planning artifact	Tên trường, thực thể, mã hàng, lô hàng phải đối chiếu dictionary khi artifact có nội dung chi tiết	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07	Cần xác minh nội dung thực thể và thuộc tính
Nguồn BA	BABOK Guide	https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/	Primary professional source	Dùng thuật ngữ phân tích nghiệp vụ, elicitation và stakeholder	IIBA	Truy cập 2026-08-07	Dùng trong ranh giới overview và errata
Nguồn requirement	ISO/IEC/IEEE 29148:2018	https://www.iso.org/standard/72089.html	Primary standards source	Dùng abstract và trạng thái thư mục để phân biệt requirement với ghi chú chưa xác minh	ISO/IEC/IEEE	Truy cập 2026-08-07	Cần xác minh licensed text nếu cần điều khoản chính xác
Nguồn pháp lý dữ liệu cá nhân	Luật 91/2025/QH15	https://vanban.chinhphu.vn/?classid=1&docid=214590&pageid=27160&typegroup=	Primary legal source	Có thể xuất hiện dữ liệu nhà cung cấp, khách hàng, nhân viên trong phỏng vấn ERP	Quốc hội Việt Nam	Truy cập 2026-08-07	Cần xác minh Legal Owner trước khi suy ra requirement
Nguồn kế toán	Luật 88/2015/QH13	https://vanban.chinhphu.vn/?docid=183198&pageid=27160	Primary legal source	Phỏng vấn có thể chạm giá vốn, tồn kho, chứng từ, VND	Quốc hội Việt Nam	Truy cập 2026-08-07	Cần xác minh Accounting Owner
Nguồn hóa đơn	Nghị định 123/2020/NĐ-CP	https://vanban.chinhphu.vn/?docid=201365&pageid=27160	Primary legal source	Đề cập hóa đơn trong case chỉ là ngữ cảnh khảo sát	Chính phủ Việt Nam	Truy cập 2026-08-07	Cần xác minh sửa đổi hiện hành và Legal/Accounting Owner
Nguồn an toàn thực phẩm	Luật 55/2010/QH12	https://vanban.chinhphu.vn/?docid=96032&pageid=27160	Primary legal source	Lô hàng, truy xuất và thu hồi là ngữ cảnh nghiệp vụ thực phẩm mô phỏng	Quốc hội Việt Nam	Truy cập 2026-08-07	Cần xác minh Legal Owner và domain owner
Bằng chứng nghiệp vụ mô phỏng	Phiếu nhập kho mẫu NF-SIM-GRN-2026-0801	Chưa có tệp canonical trong corpus	Synthetic working evidence	Nhập 120 thùng nguyên liệu giả lập ngày 2026-08-01; giá trị minh họa 18.600.000 VND	Chưa xác định vai trò nghiệp vụ mô phỏng	Ngày dữ liệu 2026-08-01	Cần xác minh: không được dùng làm chứng cứ vận hành
Bằng chứng nghiệp vụ mô phỏng	Báo cáo tồn kho mẫu NF-SIM-INV-2026-0807	Chưa có tệp canonical trong corpus	Synthetic working evidence	Tồn kho minh họa nguyên liệu RM-COCOA-01: 480 thùng	Chưa xác định vai trò nghiệp vụ mô phỏng	Ngày dữ liệu 2026-08-07	Cần xác minh: mã hàng và đơn vị tính chưa có dictionary xác nhận

Applied

Facts: Nova Foods là case mô phỏng; corpus có artifact canonical, nguồn chuẩn và nguồn pháp lý; hai chứng từ NF-SIM-GRN-2026-0801 và NF-SIM-INV-2026-0807 chỉ là dữ liệu tổng hợp.

Current Behavior: BA dùng bảng đầu vào để biết nguồn nào được phép tham chiếu trước phỏng vấn và nguồn nào chỉ tạo câu hỏi làm rõ.

Underlying Need: Ghi note phải tách “fact có nguồn” khỏi “điểm chưa xác minh”. Lý do: một con số tồn kho mô phỏng không đủ biến thành business rule hay quyết định kế toán.

Options: Dùng mọi đầu vào như sự thật; chỉ dùng nguồn luật; hoặc dùng nguồn theo phân loại và giữ nhãn Cần xác minh.

Decision Criteria: Giữ ID canonical, không vượt thẩm quyền, không biến dữ liệu tổng hợp thành fact vận hành, vẫn đủ ngữ cảnh để hỏi đúng người.

Decision: Dùng phương án phân loại nguồn. Artifact controlled planning xác định phạm vi; nguồn primary xác định thuật ngữ hoặc bối cảnh; bằng chứng synthetic chỉ làm vật kích hoạt câu hỏi.

Authority: Principal IT Business Analyst / Technical Curriculum Author quản trị artifact. Legal Owner, Accounting Owner và domain owner xác minh kết luận thuộc chuyên môn tương ứng.

Artifact: Bảng đầu vào section 4 trong /02-handbook/03-discovery-interviewing-and-note-taking.md, trạng thái IN_REVIEW, version v0.9.0.

Consequence if Wrong: Ghi “120 thùng” như tồn kho thật có thể làm sai requirement, test basis, quyết định tồn kho hoặc diễn giải pháp lý.

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

flowchart TB
    A["Đầu vào Nova Foods mô phỏng"] --> B{"Phân loại nguồn"}

    B -->|"Controlled planning artifact"| C["Chỉ xác định ID, phạm vi<br/>IN_REVIEW · v0.9.0"]
    B -->|"Primary source"| D["Chỉ xác định thuật ngữ hoặc bối cảnh"]
    B -->|"Synthetic working evidence"| E["Chỉ kích hoạt câu hỏi làm rõ<br/>Không xác lập fact vận hành"]

    P["Principal IT Business Analyst /<br/>Technical Curriculum Author"] -->|"Quản trị artifact"| C

    C --> F["Metadata truy vết<br/>ID · phạm vi · IN_REVIEW · v0.9.0"]
    D --> G["Fact có nguồn<br/>Giới hạn: thuật ngữ hoặc bối cảnh"]
    E --> H["Cần xác minh<br/>Tách khỏi fact có nguồn"]

    H --> Q["Note phỏng vấn cuối<br/>Tách fact có nguồn khỏi Cần xác minh"]
    H --> I{"Giữ nhãn và chuyển đúng owner?"}

    I -->|"Có"| J["Legal Owner, Accounting Owner<br/>hoặc domain owner xác minh"]
    J --> K{"Kết quả xác minh"}
    K -->|"Được xác nhận"| N["Kết luận đã xác minh<br/>Ghi owner và chuyên môn xác nhận"]
    K -->|"Không được xác nhận"| O["Cập nhật hoặc loại bỏ điểm ban đầu"]

    I -->|"Không: bỏ nhãn hoặc dùng như fact"| L["Synthetic evidence bị dùng làm fact"]
    L --> M["Risk: requirement, kiểm thử, tồn kho<br/>hoặc kết luận pháp lý sai"]

    F --> Q
    G --> Q
    N --> Q
    O --> Q

Senior Lens

“Đầy đủ” không nghĩa là mọi thông tin đã đúng. Đầy đủ nghĩa là từng đầu vào cần dùng đã có dòng truy vết, nguồn, owner, thời điểm và nhãn xác minh. Nếu không tìm được tệp canonical cho chứng từ mô phỏng, BA không bịa đường dẫn; ghi rõ chưa có tệp canonical và không dùng chứng từ đó làm nguồn quyết định.

Quick Reference

Nhãn	Nghĩa thao tác
Có thể dùng làm bối cảnh	Dùng để chuẩn bị câu hỏi và giữ phạm vi
Chỉ tham chiếu	Không suy ra rule hoặc quyết định
Cần xác minh	Giữ nguyên trong note; chuyển đúng owner xác minh
Synthetic working evidence	Dữ liệu tổng hợp để minh họa; không là bằng chứng vận hành

5. Step-by-step BA Activities

Core

Discovery là quá trình BA thu thập, kiểm tra và ghi nhận hiểu biết về vấn đề trước khi biến nó thành requirement. Note phỏng vấn không phải biên bản chép lời. Note phải tách fact (sự kiện được nêu hoặc thấy), inference (suy luận của BA), assumption (giả định dự án) và verification required (cần vai trò có thẩm quyền xác minh). Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là synthetic.

Applied

1. Actor: BA. Action: xác định mục tiêu buổi phỏng vấn, phạm vi quy trình và quyết định cần làm rõ. Object: interview brief. Evidence produced: INT-BRIEF-01 ghi mục tiêu, câu hỏi, người tham gia, nguồn đầu vào và thời lượng. Decision rule: chỉ hỏi nội dung liên quan trực tiếp phạm vi ERP đang khảo sát. Quality gate: mỗi câu hỏi phải truy được về gap, rủi ro hoặc quyết định. Escalation route: phạm vi mâu thuẫn với artifact canonical thì chuyển Principal IT Business Analyst / Technical Curriculum Author để ghi nhận xung đột, không tự mở rộng phạm vi.

2. Actor: BA. Action: phân loại người tham gia theo kiến thức, quyền quyết định và vai trò vận hành. Object: stakeholder list. Evidence produced: dòng participant trong INT-BRIEF-01, gồm tên vai trò, chủ đề biết rõ và giới hạn thẩm quyền. Decision rule: người thực hiện thao tác mô tả current behavior; Business Owner quyết định ưu tiên nghiệp vụ; chuyên gia pháp lý, kế toán, bảo mật xác minh nội dung thuộc chuyên môn. Quality gate: không gán authority chỉ từ chức danh. Escalation route: thiếu đúng owner thì ghi Verification required và chuyển Business Owner chỉ định người phù hợp.

3. Actor: BA và người được phỏng vấn. Action: mở phiên bằng mục tiêu, phạm vi mô phỏng, cách ghi note và ranh giới thẩm quyền. Object: interview session. Evidence produced: timestamp, người tham gia, xác nhận phạm vi trao đổi trong INT-NOTE-01. Decision rule: không diễn đạt nội dung trao đổi là approval, baseline hay quyết định production. Quality gate: note ghi rõ Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh. Escalation route: người tham gia yêu cầu cam kết ngoài thẩm quyền BA thì chuyển Business Owner hoặc owner chuyên môn.

4. Actor: BA. Action: hỏi theo luồng “ai làm gì, khi nào, dùng dữ liệu nào, ngoại lệ nào, hậu quả gì”. Object: current behavior. Evidence produced: từng note có nguồn phát biểu, thời điểm, đối tượng nghiệp vụ và nhãn Fact hoặc Reported behavior. Decision rule: chỉ ghi fact khi người tham gia mô tả hành vi hoặc vật chứng cụ thể; không biến câu nói thành rule. Quality gate: mọi kết luận BA phải có cầu nối: fact nguồn nào, suy luận gì, lý do suy luận. Escalation route: hai người mô tả trái ngược thì giữ cả hai phát biểu, tạo issue, chuyển domain owner phân xử.

5. Actor: BA. Action: tách vấn đề quan sát được khỏi underlying need, tức nhu cầu gốc cần giải quyết. Object: problem statement. Evidence produced: mục Observed problem, Underlying need, Assumption, Verification required trong INT-NOTE-01. Decision rule: một lỗi thao tác không tự động là nhu cầu hệ thống; nhu cầu chỉ được ghi khi có bằng chứng về tác động, tần suất hoặc rủi ro. Quality gate: mỗi underlying need phải liên kết ít nhất một fact và một hậu quả nghiệp vụ. Escalation route: tác động liên quan tiền, sổ sách, dữ liệu cá nhân hoặc an toàn thực phẩm thì chuyển Accounting Owner, Legal Owner hoặc domain owner xác minh.

6. Actor: BA. Action: đọc lại tóm tắt theo từng chủ đề ngay trong phiên. Object: provisional note. Evidence produced: phần Read-back result ghi “khớp”, “sửa”, hoặc “chưa xác minh”. Decision rule: sửa note khi người cung cấp thông tin sửa fact; không sửa suy luận thành fact. Quality gate: mỗi chủ đề có trạng thái rõ ràng, không để câu mơ hồ như “xử lý sau”. Escalation route: nội dung chưa thống nhất trở thành open issue có owner và hạn xác minh theo Asia/Ho_Chi_Minh.

7. Actor: BA. Action: chuẩn hóa note sau phiên, giữ nguyên source classification và liên kết artifact. Object: controlled interview note. Evidence produced: INT-NOTE-01 trong /02-handbook/03-discovery-interviewing-and-note-taking.md, gồm participant role, facts, inferences, issues, decisions pending và traceability. Decision rule: không tạo canonical business rule, data definition hoặc requirement từ note đơn lẻ. Quality gate: ID, filename, status và version giữ đúng corpus; Nova Foods luôn ghi là simulated, synthetic data only. Escalation route: cần ID mới hoặc source canonical chưa rõ thì chuyển Principal IT Business Analyst / Technical Curriculum Author theo TRACEABILITY_ID_REGISTRY.

8. Actor: BA và người nhận handoff. Action: chuyển note, issue log và câu hỏi xác minh cho đúng owner; ghi phạm vi handoff. Object: review package. Evidence produced: INT-HANDOFF-01 chứa link tới INT-BRIEF-01, INT-NOTE-01, danh sách issue, owner, hạn phản hồi và trạng thái IN_REVIEW. Decision rule: handoff hoàn tất khi người nhận xác nhận đã nhận artifact, không phải xác nhận nội dung đúng hoặc được phê duyệt. Quality gate: không còn fact không nguồn, inference không lý do, hay issue không owner. Escalation route: quá hạn hoặc owner từ chối thẩm quyền thì chuyển Business Owner để chỉ định owner mới.

Facts: Nhân viên kho mô phỏng báo rằng phiếu nhập hàng được ghi trước trên giấy rồi nhập ERP cuối ca.

Current Behavior: Một người nhập dữ liệu sau khi hàng đã được dỡ; thời điểm nhận hàng và thời điểm nhập ERP có thể khác nhau.

Underlying Need: Cần xác minh nhu cầu truy vết thời điểm nhận hàng thực tế, không suy luận ngay rằng ERP phải có màn hình mới.

Options: Giữ nhập cuối ca; nhập tại thời điểm nhận; hoặc tích hợp thiết bị quét mã. Đây là phương án khảo sát, chưa là quyết định thiết kế.

Decision Criteria: Tính chính xác thời điểm, khả năng vận hành kho, chi phí thay đổi, dữ liệu cần lưu, rủi ro kiểm toán và yêu cầu pháp lý cần xác minh.

Decision: Chưa quyết định. BA tạo issue xác minh current process và owner dữ liệu thời điểm nhận hàng.

Authority: Domain owner xác nhận quy trình kho; Accounting Owner xác minh tác động chứng từ; Legal Owner xác minh nghĩa vụ pháp lý nếu có; Architect đánh giá phương án tích hợp.

Artifact: INT-NOTE-01, INT-HANDOFF-01, trạng thái IN_REVIEW, version v0.9.0.

Consequence if Wrong: BA có thể viết sai requirement thời điểm ghi nhận, tạo test basis sai, hoặc gán nghĩa vụ kế toán và pháp lý khi chưa có xác minh.

Senior Lens

Senior BA không cố “chốt đáp án” trong phỏng vấn. Giá trị nằm ở việc làm rõ ai biết điều gì, bằng chứng nào hỗ trợ phát biểu đó, điều gì chưa biết và ai có quyền xác minh. Note tốt cho phép reviewer tái dựng đường đi từ phát biểu đến inference mà không cần tin vào trí nhớ BA.

Quick Reference

Nhãn note	Cách ghi
Fact	Nguồn, thời điểm, đối tượng, nội dung quan sát hoặc phát biểu
Inference	Fact nền, suy luận BA, lý do suy luận
Assumption	Giả định dùng tạm, tác động nếu sai
Verification required	Câu hỏi cần xác minh, owner, hạn phản hồi
Handoff received	Đã nhận artifact; không đồng nghĩa approval

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp, IN_REVIEW, v0.9.0, ngày 2026-08-07, bối cảnh vi-VN, Asia/Ho_Chi_Minh, VND. Phỏng vấn khám phá biến lời kể thành bằng chứng truy vết được. BA không coi một phát biểu là requirement khi chưa có nguồn, ngữ cảnh, người chịu trách nhiệm và quy tắc quyết định.

Bước	Actor	Action	Object	Evidence produced	Decision rule	Quality gate	Escalation route
1. Xác định mục tiêu	BA	Ghi mục tiêu, phạm vi, câu hỏi cần làm rõ và giả định ban đầu.	Phiên phỏng vấn quy trình tạo đơn bán hàng mô phỏng.	Interview Brief có mục tiêu, stakeholder, phạm vi vào/ra, rủi ro.	Chỉ phỏng vấn khi mục tiêu gắn một quyết định hoặc khoảng trống tri thức cụ thể.	Mỗi mục tiêu trả lời được: cần biết gì, từ ai, để quyết định gì.	Mục tiêu chạm giá, thuế, kế toán, pháp lý hoặc dữ liệu cá nhân: chuyển Business Owner, Accounting Owner, Legal Owner hoặc Privacy/Security Owner.
2. Chọn người cung cấp thông tin	BA	Lập danh sách người biết việc, người làm việc và người chịu trách nhiệm quyết định.	Stakeholder map.	Danh sách vai trò, trách nhiệm, mức ảnh hưởng và lịch phỏng vấn.	Một quy trình phải có ít nhất nguồn thực hiện và nguồn chịu trách nhiệm nghiệp vụ; không suy từ một vai trò.	Không thiếu người xử lý ngoại lệ, người sở hữu dữ liệu hoặc người quyết định.	Tranh chấp quyền sở hữu quy trình: chuyển Business Owner.
3. Chuẩn bị bằng chứng nền	BA	Đọc artifact upstream, ghi câu hỏi theo bằng chứng đã có và điểm mâu thuẫn.	00_SOURCE_MAP, CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, tài liệu mô phỏng liên quan.	Question Log gồm câu hỏi, lý do hỏi, nguồn hiện có, ID truy vết.	Câu hỏi phải kiểm tra sự kiện, quy tắc, dữ liệu, ngoại lệ hoặc tiêu chí chấp nhận; không hỏi chung chung.	Mỗi câu hỏi có nguồn hoặc giả định khởi đầu ghi rõ.	Canonical ID, source classification hoặc artifact path mâu thuẫn: chuyển Principal IT Business Analyst / Technical Curriculum Author để giữ traceability.
4. Mở phiên và xác lập ranh giới	BA và Interviewee	Xác nhận mục tiêu, thời lượng, phạm vi mô phỏng, cách ghi nhận và giới hạn thẩm quyền.	Agenda và Interview Brief.	Attendance Record, phạm vi xác nhận bằng ghi chú phiên.	Không diễn giải buổi trao đổi là approval, baseline hay quyết định production.	Người tham gia hiểu Nova Foods là mô phỏng, dữ liệu là tổng hợp, nội dung còn IN_REVIEW.	Yêu cầu cam kết vận hành, legal sign-off hoặc approval: chuyển owner có thẩm quyền; BA chỉ ghi nhận yêu cầu.
5. Khai thác luồng hiện tại	BA hỏi, Interviewee mô tả	Dùng câu hỏi mở trước, câu hỏi kiểm chứng sau; truy từng trigger, bước, dữ liệu, ngoại lệ và kết quả.	Current behavior, tức hành vi hiện tại được mô tả.	Raw Interview Notes có timestamp, người nói, fact, inference, open question.	Tách “Facts” là điều người tham gia mô tả hoặc artifact chứng minh khỏi “Underlying Need” là nhu cầu BA suy ra.	Mỗi inference ghi cầu nối: fact nào dẫn đến reasoning nào.	Hai nguồn mô tả khác nhau: giữ cả hai nguồn, không tự chọn; chuyển Business Owner quyết định.
6. Kiểm chứng bằng ví dụ	BA	Yêu cầu walkthrough, tức diễn lại một tình huống, với dữ liệu tổng hợp; kiểm tra happy path và ngoại lệ.	Đơn bán mô phỏng, tồn kho mô phỏng, trạng thái xử lý mô phỏng.	Scenario Evidence gồm input, hành động, kết quả quan sát, ngoại lệ và nguồn.	Chỉ coi quy tắc là ứng viên khi ví dụ cho kết quả lặp lại hoặc owner xác nhận phạm vi áp dụng.	Ví dụ phải đủ input, actor, thời điểm, kết quả; không chứa dữ liệu cá nhân hoặc dữ liệu thật.	Cần truy cập hệ thống thật, log thật hoặc dữ liệu nhạy cảm: dừng thu thập, chuyển Security/Privacy Owner và System Owner.
7. Chuẩn hóa ghi chú	BA	Chuyển ghi chú thô thành fact, rule candidate, data item, pain point, decision và open issue.	Raw Interview Notes.	Structured Interview Notes, Decision Log và Issue Log.	Không đổi lời kể thành business rule canonical khi chưa có authority và nguồn kiểm chứng.	Mọi dòng có nguồn, trạng thái, owner xử lý, ngày ghi nhận 2026-08-07 hoặc thời điểm theo Asia/Ho_Chi_Minh.	Rule liên quan thuế, hóa đơn, kế toán, an toàn thực phẩm hoặc bảo vệ dữ liệu: gắn Verification required; chuyển đúng domain owner.
8. Gửi review có kiểm soát	BA	Gửi bản ghi cấu trúc cho interviewee kiểm tra độ chính xác của fact và ngữ cảnh.	Structured Interview Notes.	Review Request và Review Response được liên kết cùng phiên.	Review xác nhận độ đúng ghi nhận, không tự tạo approval requirement hoặc baseline.	Phản hồi phải chỉ rõ dòng nào đúng, sai, thiếu hoặc chưa rõ; im lặng không được coi là đồng ý.	Không phản hồi trong hạn dự án: ghi open issue, chuyển Project Manager và Business Owner theo cơ chế dự án.
9. Handoff có kiểm soát	BA	Đưa fact đã review, mâu thuẫn, giả định và câu hỏi mở sang artifact kế tiếp bằng ID truy vết.	Interview evidence package.	Handoff Log chứa nguồn, người nhận, trạng thái, giới hạn sử dụng.	Chỉ handoff nội dung có source, phân loại và trạng thái rõ; nội dung chưa xác minh giữ nhãn tương ứng.	Người nhận truy được từ kết luận về evidence gốc mà không cần suy đoán.	Người nhận yêu cầu BA tự quyết thay domain owner: trả về Decision Log, chuyển owner có thẩm quyền.

Quy tắc ghi note: Fact phải nêu ai nói hoặc artifact nào chứng minh; Inference phải nêu reasoning; Decision phải nêu Authority; Open Issue phải nêu owner và điều kiện đóng. Cấu trúc này ngăn ghi chú phỏng vấn biến thành quy tắc Nova Foods chưa được xác minh.

Applied

Nova Foods Trading & Manufacturing là case 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. Bảng dưới ghi mẫu thực thi phỏng vấn về chênh lệch giữa phiếu nhập kho và hóa đơn mua hàng. Đây là bằng chứng khám phá, chưa là requirement đã phê duyệt, baseline, cấu hình ERP hay kết luận kế toán.

Mục	Nội dung thực thi Nova Foods
Facts	Nhân viên Kho ghi nhận phiếu nhập GRN-NF-2026-081 cho 500 kg đường; Kế toán mua hàng nhận hóa đơn tổng hợp ghi 480 kg. Hai số lượng không khớp. Dữ liệu là tổng hợp.
Current Behavior	Kế toán tạm dừng đối chiếu, gửi email hỏi Kho; Kho tra sổ tay; quyết định có thể chậm và không có mã lý do chuẩn. Bằng chứng: ảnh chụp màn hình mô phỏng, email mô phỏng, ghi chú phỏng vấn.
Underlying Need	Cần phân biệt chênh lệch do nhận thiếu, hóa đơn sai, đơn vị tính khác, hoặc nhập liệu sai; cần giữ liên kết giữa chứng từ mua, nhận hàng và hóa đơn để người có thẩm quyền xử lý. Suy luận: hai số lượng khác nhau và luồng hiện tại không có mã lý do, nên không thể phân loại nguyên nhân nhất quán.
Options	1. Cho phép Kế toán tự sửa số lượng hóa đơn. 2. Khóa đối chiếu khi lệch và yêu cầu mã lý do cùng bằng chứng. 3. Tự động khớp mọi chênh lệch trong ngưỡng do dự án giả định đặt ra.
Decision Criteria	Bảo toàn chứng từ gốc; truy vết được người ghi nhận và lý do; không tự suy diễn nghĩa vụ kế toán; xử lý được chênh lệch đơn vị tính; quyền sửa phù hợp vai trò.
Decision	Chọn phương án 2 cho mô hình cần phân tích: hệ thống ghi trạng thái EXCEPTION, bắt buộc mã lý do và tham chiếu chứng từ trước khi chuyển xử lý. Đây là đề xuất BA, chưa là quy tắc canonical.
Authority	Business Owner xác nhận nhu cầu vận hành; Accounting Owner xác nhận xử lý chứng từ và diễn giải kế toán; Solution Architect xác nhận khả thi tích hợp; QA xác nhận test basis. BA không thay các thẩm quyền này.
Artifact	Ghi phát hiện vào biên bản phỏng vấn; liên kết định danh, thuật ngữ và dữ liệu logic với TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY; giữ trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Nếu coi chênh lệch là lỗi nhập liệu mà không xác minh, số liệu đối chiếu có thể sai, chứng từ mất liên kết, truy vết xử lý thiếu. Việc đánh giá ảnh hưởng kế toán cần Accounting Owner xác minh.

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

flowchart TB
    subgraph L["Vòng đời đề xuất BA"]
        BA["BA ghi phát hiện và bằng chứng phỏng vấn"] --> AR["Artifact: IN_REVIEW v0.9.0<br/>Ngày 2026-08-07<br/>Liên kết TRACEABILITY_ID_REGISTRY<br/>CANONICAL_BUSINESS_RULES<br/>CANONICAL_DATA_DICTIONARY"]

        AR --> CK["Ba kiểm tra bắt buộc theo phạm vi<br/>Business Owner: nhu cầu vận hành<br/>Accounting Owner: xử lý chứng từ và diễn giải kế toán<br/>Solution Architect: khả thi tích hợp"]

        CK --> Q{"Đã hoàn tất cả ba kiểm tra?"}
        Q -- "Chưa" --> RW["Yêu cầu làm rõ hoặc làm lại<br/>Tiếp tục IN_REVIEW"]
        RW --> AR

        Q -- "Rồi" --> V{"Đủ căn cứ?<br/>Bảo toàn chứng từ gốc<br/>Truy vết người và lý do<br/>Xử lý đơn vị tính<br/>Quyền sửa phù hợp vai trò"}

        V -- "Chưa đủ" --> RW
        V -- "Đủ" --> DR["Đề xuất BA được ghi nhận:<br/>dùng EXCEPTION khi lệch<br/>Vẫn IN_REVIEW, chưa canonical"]
        DR --> QA["QA xác nhận test basis<br/>cho đề xuất được ghi nhận"]
    end

    subgraph R["Quy tắc runtime được đề xuất — chưa được phê duyệt"]
        K["Kho ghi GRN-NF-2026-081:<br/>500 kg"] --> C{"Số lượng khác nhau?"}
        H["Kế toán nhận hóa đơn:<br/>480 kg"] --> C

        C -- "Không" --> O["Ngoài phạm vi luồng chênh lệch đề xuất"]
        C -- "Có" --> E["Trạng thái EXCEPTION"]
        E --> M["Bắt buộc mã lý do<br/>và tham chiếu chứng từ"]
        M --> P["Chuyển người có thẩm quyền xử lý"]
        P --> W["Chờ phân loại nguyên nhân:<br/>nhận thiếu, hóa đơn sai,<br/>khác đơn vị tính hoặc nhập liệu sai"]

        E -- "Nếu bỏ qua kiểm soát" --> X["Tự kết luận hoặc xử lý<br/>không xác minh"]
        X --> RISK["Nguy cơ: đối chiếu sai,<br/>chứng từ mất liên kết,<br/>truy vết xử lý thiếu"]
    end

    DR -. "Mô tả quy tắc được đề xuất" .-> E

Sơ đồ là flowchart Mermaid, không phải BPMN. Nguồn phương pháp: BABOK Guide Version 3 dùng cho thuật ngữ BA; mọi diễn giải kế toán, pháp lý, thuế, an toàn thực phẩm cần vai trò có thẩm quyền xác minh theo nguồn chính thức hiện hành.

6. Output thu ???c

Core

Output là artifact được tạo mới hoặc cập nhật từ phỏng vấn, không phải kết luận đã được phê duyệt. Mỗi artifact phải giữ bằng chứng nguồn, người chịu trách nhiệm duy trì, trạng thái, phiên bản, ngày cập nhật theo Asia/Ho_Chi_Minh và lịch sử thay đổi. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ dữ liệu dưới đây là tổng hợp.

Artifact tạo hoặc cập nhật	Canonical ID	Owner duy trì	Status	Nội dung tối thiểu	Nghĩa vụ lịch sử thay đổi
Biên bản phỏng vấn có cấu trúc	Chưa có ID được cấp trong TRACEABILITY_ID_REGISTRY	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Người tham gia theo vai trò, thời điểm, phạm vi, fact, câu trả lời được ghi nhận, nguồn bằng chứng, điểm chưa xác minh	Ghi ngày, version, người sửa, nội dung sửa, lý do sửa; không sửa im lặng
Mục truy vết phát hiện	TRACEABILITY_ID_REGISTRY	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Liên kết phát hiện với nguồn phỏng vấn, artifact liên quan, vai trò cần xác minh	Ghi tạo mới, sửa liên kết, thay đổi trạng thái và lý do
Đề xuất quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Điều kiện, hành vi mong muốn, nguồn phát hiện, giả định, owner có thẩm quyền xác minh	Ghi nội dung trước và sau sửa; giữ nguồn của từng thay đổi
Làm rõ thuật ngữ hoặc dữ liệu logic	CANONICAL_DATA_DICTIONARY	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Tên dữ liệu, nghĩa nghiệp vụ, nguồn, phạm vi dùng, điểm cần xác minh	Ghi thay đổi định nghĩa, nguồn và ảnh hưởng truy vết

Không tự đặt chuỗi mới là canonical ID khi registry chưa cấp. Lý do: ID tự đặt có thể trùng hoặc đứt liên kết với artifact kiểm soát. IN_REVIEW chỉ cho phép downstream review; không nghĩa là APPROVED, BASELINED, production-ready, compliant, hay được người dùng chấp thuận.

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

flowchart TB
    A["Phỏng vấn và bằng chứng"] --> B

    subgraph artifacts["Artifacts tạo hoặc cập nhật"]
        direction TB

        B["Biên bản phỏng vấn<br/>Canonical ID: Chưa có ID được cấp trong TRACEABILITY_ID_REGISTRY<br/>Người tham gia theo vai trò, thời điểm, phạm vi<br/>Fact, câu trả lời, nguồn bằng chứng, điểm chưa xác minh<br/>Lịch sử: ngày, version, người sửa, nội dung, lý do"]

        B -->|"giữ liên kết nguồn phỏng vấn"| C["Mục truy vết phát hiện<br/>Canonical ID: TRACEABILITY_ID_REGISTRY<br/>Nguồn phỏng vấn, artifact liên quan, vai trò cần xác minh<br/>Lịch sử: tạo mới, sửa liên kết, đổi trạng thái và lý do"]

        B -->|"giữ liên kết nguồn phát hiện"| D["Đề xuất quy tắc nghiệp vụ<br/>Canonical ID: CANONICAL_BUSINESS_RULES<br/>Điều kiện, hành vi mong muốn, nguồn phát hiện, giả định<br/>Owner có thẩm quyền xác minh<br/>Lịch sử: nội dung trước và sau sửa, nguồn từng thay đổi"]

        B -->|"giữ liên kết nguồn phỏng vấn"| E["Làm rõ thuật ngữ hoặc dữ liệu logic<br/>Canonical ID: CANONICAL_DATA_DICTIONARY<br/>Tên dữ liệu, nghĩa nghiệp vụ, nguồn, phạm vi dùng<br/>Điểm cần xác minh<br/>Lịch sử: định nghĩa, nguồn, ảnh hưởng truy vết"]
    end

    G["Quản trị bắt buộc<br/>Owner: Principal IT Business Analyst / Technical Curriculum Author<br/>Status, version, ngày cập nhật theo Asia/Ho_Chi_Minh<br/>Lịch sử thay đổi"] -.->|"áp dụng"| B
    G -.->|"áp dụng"| C
    G -.->|"áp dụng"| D
    G -.->|"áp dụng"| E

    R["Ràng buộc Canonical ID<br/>Không tự đặt ID khi registry chưa cấp<br/>Khi chưa cấp: ghi Chưa có ID được cấp"] -.-> B

    B --> S
    C --> S
    D --> S
    E --> S

    S{"Mỗi artifact đủ nguồn bằng chứng, owner,<br/>status IN_REVIEW, version, ngày cập nhật<br/>và lịch sử thay đổi?"}
    S -->|"Có"| F["Downstream review<br/>Không đồng nghĩa APPROVED, BASELINED,<br/>production-ready, compliant<br/>hoặc được người dùng chấp thuận"]
    S -->|"Không"| X["Trả lại owner bổ sung metadata bắt buộc<br/>hoặc đặt đúng trạng thái<br/>Không đưa vào downstream review"]

Sơ đồ là flowchart Mermaid, không phải BPMN.

Applied

Trường	Nova Foods mô phỏng, dữ liệu tổng hợp
Facts	Nhân viên kho nói phiếu nhận hàng GRN-NF-2026-081 ghi 500 kg; hóa đơn nhà cung cấp ghi 480 kg.
Current Behavior	Hệ thống ERP mô phỏng chưa ghi rõ trạng thái khi số lượng không khớp.
Underlying Need	Cần giữ số lượng từ hai chứng từ và lý do chênh lệch để người có thẩm quyền xem xét.
Options	Ghi đè số lượng hóa đơn; tự khớp theo số lượng kho; ghi EXCEPTION và giữ cả hai số lượng.
Decision Criteria	Không làm mất bằng chứng; cho phép truy vết; không tự diễn giải kế toán; có thể kiểm thử sau khi quyết định được ghi nhận.
Decision	BA ghi đề xuất EXCEPTION; đây chưa là quy tắc canonical hay quyết định vận hành.
Authority	Business Owner xác nhận nhu cầu; Accounting Owner xác minh xử lý chứng từ; Solution Architect đánh giá khả thi; QA dùng nội dung đã xác minh làm test basis.
Artifact	Cập nhật biên bản phỏng vấn, liên kết phát hiện trong TRACEABILITY_ID_REGISTRY, đề xuất quy tắc trong CANONICAL_BUSINESS_RULES, làm rõ trường số lượng trong CANONICAL_DATA_DICTIONARY. Tất cả giữ IN_REVIEW, v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Nếu ghi đè một số lượng, bằng chứng chênh lệch có thể mất; đối chiếu chứng từ và đánh giá ảnh hưởng kế toán có thể sai.

Senior Lens

Quality gate cho downstream review: artifact có owner, IN_REVIEW, v0.9.0, ngày 2026-08-07; nêu nguồn fact; tách fact khỏi suy luận; liên kết đúng canonical artifact; ghi authority cần xác minh; có dòng change history. Thiếu một mục thì artifact chưa đủ điều kiện review downstream. Gate này không xác nhận nội dung đúng, không tạo approval và không cho phép dùng production.

Quick Reference

Quy tắc	Áp dụng
Fact không biến thành rule	Ghi nguồn phỏng vấn trước; đề xuất rule nằm trong CANONICAL_BUSINESS_RULES.
ID không tự sinh	Chỉ TRACEABILITY_ID_REGISTRY cấp hoặc xác nhận canonical ID.
Sửa không được che lịch sử	Mỗi sửa ghi người sửa, thời điểm, lý do, nội dung đổi.
Owner không thay authority	Owner duy trì artifact; Business, Accounting, Architect, QA xác minh phần thuộc thẩm quyền.

Core

Output phỏng vấn không phải bản ghi chép dài. Nó là gói bằng chứng để người sau kiểm tra được: ai nói gì, quan sát nào được tách khỏi diễn giải, nhu cầu nào hình thành, và nội dung nào còn cần xác minh. 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.

Thành phần	Nội dung bắt buộc	Mục đích kiểm tra
Facts	Sự kiện quan sát được hoặc phát biểu được ghi nhận	Tách bằng chứng khỏi suy luận
Current Behavior	Quy trình hiện tại, tác nhân, đầu vào, đầu ra, ngoại lệ	Hiểu vấn đề trước khi đề xuất thay đổi
Underlying Need	Nhu cầu gốc rút từ Facts và Current Behavior	Tránh biến lời than phiền thành yêu cầu sai
Open Point	Điểm chưa đủ bằng chứng hoặc cần vai trò khác xác minh	Ngăn BA tự quyết thay chuyên gia
Traceability	Liên kết tới nguồn và artifact canonical	Giữ đường truy vết xuyên corpus

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

flowchart TB
    subgraph EB["Bằng chứng — tách khỏi diễn giải"]
        A["Facts<br/>Quan sát hoặc phát biểu được ghi nhận"]
        B["Current Behavior<br/>Quy trình, tác nhân, đầu vào, đầu ra, ngoại lệ"]
    end

    A --> H["BA đối chiếu bằng chứng"]
    B --> H
    H --> C["Underlying Need<br/>Rút ra từ bằng chứng kết hợp"]
    C --> G{"Còn nội dung chưa đủ bằng chứng?"}

    G -->|Không| N["Không có Open Point"]
    G -->|Có| O["Open Point<br/>Nội dung cần xác minh"]
    O --> V["Verification owner<br/>Vai trò chuyên gia phù hợp"]
    V --> R{"Đã xác minh?"}

    R -->|Không| U["Unresolved<br/>Ghi rõ hạn chế"]
    R -->|Có| Q["Kết quả xác minh"]
    Q --> S["Open Point: Resolved"]
    Q -->|Cập nhật quan sát hoặc phát biểu| A
    Q -->|Cập nhật quy trình hoặc ngoại lệ| B

    N --> J["Hội tụ<br/>Underlying Need hiện hành<br/>và trạng thái Open Point"]
    U --> J

    T["Traceability<br/>Liên kết nguồn, kết quả xác minh<br/>và artifact canonical"]
    A --> T
    B --> T
    C --> T
    O --> T
    Q --> T
    S --> T
    U --> T
    N --> T

    J --> X["BA tập hợp Evidence package"]
    T --> X
    X --> K["Evidence package<br/>Facts, Current Behavior, Underlying Need;<br/>Open Point, owner, trạng thái và hạn chế nếu phát sinh"]
    K --> L["Người sau kiểm tra<br/>nguồn, diễn giải, nhu cầu,<br/>kết quả xác minh và hạn chế"]

Applied

Facts: Trong buổi trao đổi mô phỏng ngày 2026-08-07, Nhân viên Kho thành phẩm nói phiếu xuất kho có thể được tạo trước khi ghi đủ mã lô. BA ghi đây là phát biểu nguồn, không kết luận ERP đang cho phép hay cấm hành vi đó.

Current Behavior: Đơn bán hàng mô phỏng được chọn để xuất; nhân viên chọn hàng, nhập số lượng, rồi hoàn thiện thông tin lô trên phiếu xuất. Nếu thông tin lô thiếu, người nhận phiếu phải hỏi lại Kho bằng kênh ngoài hệ thống.

Underlying Need: Bộ phận nhận hàng cần biết lô nào đã xuất để đối chiếu hàng giao. Cầu nối suy luận là: thiếu mã lô trên phiếu làm người nhận không xác định được lô đã giao; vì vậy nhu cầu là thông tin lô phải truy vết được từ chứng từ xuất. Đây chưa phải kết luận nghĩa vụ pháp lý hay cấu hình ERP.

Trường output	Giá trị Nova Foods mô phỏng
Source classification	Interview evidence; dữ liệu tổng hợp
Facts	Nhân viên Kho cho biết có trường hợp hoàn thiện mã lô sau khi tạo phiếu xuất
Current Behavior	Phiếu xuất được tạo, sau đó thông tin lô được hoàn thiện; đối chiếu thiếu thì hỏi lại Kho
Underlying Need	Người nhận phiếu cần truy vết mã lô theo hàng đã xuất
Options	1. Bắt buộc chọn lô trước khi tạo phiếu xuất. 2. Cho tạo phiếu nhưng chặn hoàn tất khi thiếu lô. 3. Giữ quy trình ngoài hệ thống
Decision Criteria	Khả năng truy vết, khối lượng thao tác Kho, khả năng xử lý ngoại lệ, bằng chứng từ vai trò nghiệp vụ
Decision	Chưa chọn phương án. Facts chưa đủ để xác nhận quy tắc vận hành
Authority	Business Owner xác nhận quy trình; Food-safety/Compliance Owner xác minh yêu cầu truy vết; Architect đánh giá khả năng ERP
Artifact	Liên kết nguồn: 00_SOURCE_MAP; quy tắc tương lai nếu được lập phải dùng CANONICAL_BUSINESS_RULES; dữ liệu lô tương lai phải đối chiếu CANONICAL_DATA_DICTIONARY
Consequence if Wrong	Chọn chặn quá sớm có thể làm ngừng xuất hàng hợp lệ; giữ thiếu lô có thể làm giảm khả năng đối chiếu lô

Senior Lens

Không đổi Facts thành “ERP phải bắt buộc mã lô”. Facts là bằng chứng phỏng vấn; “phải” là quy tắc hoặc yêu cầu, cần nguồn, phạm vi và thẩm quyền xác nhận riêng. Không gán mã mới khi TRACEABILITY_ID_REGISTRY chưa ghi nhận mã đó. Giữ liên kết tới artifact canonical thay vì đặt tên tài liệu tự do.

Quick Reference

Kiểm tra anatomy	Đạt khi
Bằng chứng	Facts ghi được điều đã nghe hoặc quan sát, không thêm kết luận
Suy luận	Underlying Need nêu rõ cầu nối từ hành vi tới nhu cầu
Phương án	Mọi phương án nêu cả tác động vận hành
Thẩm quyền	Decision chưa vượt quyền BA hoặc Owner tài liệu
Truy vết	Dùng đúng 00_SOURCE_MAP, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY khi liên quan

Core

Quality gate là cổng kiểm tra chất lượng trước khi artifact được chuyển cho downstream review, tức bước xem xét bởi vai trò dùng artifact làm đầu vào tiếp theo. Gate không xác nhận nội dung đúng về nghiệp vụ, không tạo APPROVED, BASELINED, compliant, production-ready hay user-approved. Bằng chứng: toàn corpus đang IN_REVIEW, v0.9.0, ngày 2026-08-07; metadata hiện hành không có baseline hoặc approval reference.

Mỗi output từ discovery chỉ sẵn sàng review khi đủ các điều kiện sau:

Mã gate	Điều kiện kiểm tra	Bằng chứng bắt buộc	Fail khi
QG-OUT-01	Định danh và vị trí canonical hợp lệ	Artifact ID, filename, version v0.9.0, status IN_REVIEW	Thiếu ID, đổi filename, gọi bản sao là canonical
QG-OUT-02	Nguồn và suy luận tách biệt	Mỗi fact gắn source; mỗi inference nêu fact làm căn cứ	Ý kiến BA bị viết như fact
QG-OUT-03	Traceability không đứt	Liên kết tới ID nguồn, requirement, rule, data hoặc issue liên quan	Một kết luận không truy về evidence
QG-OUT-04	Nội dung tối thiểu hoàn chỉnh	Không còn trường bắt buộc trống; rủi ro, giả định, câu hỏi mở được gắn nhãn	Dùng im lặng để che khoảng trống
QG-OUT-05	Thẩm quyền đúng	Decision, legal, accounting, security, architecture point có authority hoặc Verification required	BA tự kết luận ngoài thẩm quyền
QG-OUT-06	An toàn chuyển tiếp	Không chứa dữ liệu thật; Nova Foods ghi mô phỏng, dữ liệu tổng hợp	Nội dung bị diễn giải thành cấu hình ERP hoặc chỉ dẫn production

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.

Thành phần	Nội dung đã ghi nhận
Facts	Buổi discovery ghi nhận kho cần biết lô nguyên liệu nào đã cấp cho lệnh sản xuất trước khi truy tìm sự cố chất lượng.
Current Behavior	Nhân viên đối chiếu phiếu giấy và bảng tính thủ công.
Underlying Need	Cần truy vết quan hệ giữa lô nguyên liệu, lệnh sản xuất và lô thành phẩm trong ERP mô phỏng.
Options	Ghi quan hệ lô tại lúc cấp phát; ghi cuối ca; chỉ lưu mã lệnh sản xuất.
Decision Criteria	Đủ traceability, giảm nhập lại, không tự suy diễn nghĩa vụ pháp lý hoặc cấu hình ERP thật.
Decision	Artifact ghi nhu cầu cần xác minh khả năng lưu quan hệ lô tại cấp phát. Không chọn cấu hình hệ thống.
Authority	Business Owner xác nhận ưu tiên vận hành; Architect xác minh khả năng ERP; Legal/Food-safety owner xác minh nghĩa vụ áp dụng.
Artifact	CANONICAL_DATA_DICTIONARY được cập nhật ở trạng thái IN_REVIEW, tham chiếu Verification required.
Consequence if Wrong	Nếu quan hệ lô ghi sai, reviewer có thể thiết kế dữ liệu hoặc kiểm thử thiếu dấu vết cần thiết.

Artifact này qua gate khi có nguồn buổi discovery, nêu rõ đây là nhu cầu suy ra từ fact, gắn Verification required cho nghĩa vụ pháp lý và không gọi yêu cầu là đã phê duyệt.

Senior Lens

“Ready for downstream review” chỉ nói artifact đủ rõ để người khác kiểm tra. Nó không nói reviewer đồng ý, không nói rule đúng, không nói hệ thống làm được. Senior BA giữ gate hẹp: kiểm tra khả năng review, không thay quyết định của Business Owner, Architect, QA, Legal, Accounting, Security hoặc Food-safety owner.

Quick Reference

Kết quả gate	Cách ghi đúng	Cách ghi sai
Đủ điều kiện review	IN_REVIEW; ready for downstream review	Approved
Chưa đủ evidence	IN_REVIEW; evidence gap recorded	Bỏ qua khoảng trống
Cần thẩm quyền chuyên môn	Verification required by [role]	BA xác nhận thay vai trò đó
Chưa có baseline	No baseline reference recorded	Baselined

7. Who consumes those outputs?

Core

Đầu ra discovery không phải “tài liệu để BA giữ”. Mỗi đầu ra là test basis, tức cơ sở để vai trò khác hiểu cùng một nhu cầu và thực hiện phần việc của họ. Trong Nova Foods Trading & Manufacturing mô phỏng, chỉ dùng dữ liệu tổng hợp; mọi artifact ở trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Đầu ra discovery	Developer	QA	Architect	PM/Product Owner	Business Owner	Operations	Specialist owner
Discovery notes có nguồn	Đọc ngữ cảnh và từ ngữ người dùng	Đọc ví dụ nghiệp vụ để tạo tình huống test	Nhận tín hiệu về hệ thống, dữ liệu, tích hợp	Đọc vấn đề và mức ưu tiên sơ bộ	Đối chiếu cách làm được ghi nhận với vận hành	Đối chiếu thao tác hiện trường	Đọc phần thuộc chuyên môn
Process map	Xác định màn hình, trạng thái, điểm nhập liệu	Xác định luồng chính, ngoại lệ, điểm kiểm thử	Xác định ranh giới hệ thống và tích hợp	Xem phạm vi hành trình người dùng	Xác nhận quy trình phản ánh mục tiêu nghiệp vụ	Xác nhận bước vận hành thực tế	Xác nhận điểm kiểm soát chuyên ngành
Requirement draft	Chuyển thành hành vi phần mềm	Chuyển thành điều kiện kiểm thử	Kiểm tra tác động kiến trúc	Sắp xếp backlog, tức danh sách việc sản phẩm	Kiểm tra nhu cầu có tạo giá trị	Kiểm tra khả năng dùng khi vận hành	Kiểm tra nội dung thuộc kế toán, pháp lý, chất lượng, bảo mật
Business-rule candidate	Lập trình điều kiện và thông báo lỗi	Thiết kế test biên và test âm	Kiểm tra nơi đặt rule: ERP, dịch vụ hay tích hợp	So sánh giá trị với chi phí và ưu tiên	Làm rõ ý định nghiệp vụ	Kiểm tra rule có làm tắc thao tác	Xác minh rule chuyên ngành
Data field list	Tạo model, API, mapping dữ liệu	Chuẩn bị dữ liệu test	Kiểm tra chủ sở hữu dữ liệu, luồng dữ liệu	Nhìn phạm vi dữ liệu cần giao	Kiểm tra dữ liệu có phục vụ quyết định	Kiểm tra dữ liệu có nhập và tra cứu được	Xác minh nghĩa, định dạng, lưu giữ dữ liệu
Open question log	Tránh tự giả định khi code	Tránh tự suy diễn expected result	Nhận điểm chưa rõ ảnh hưởng thiết kế	Theo dõi rủi ro phạm vi	Trả lời câu hỏi nghiệp vụ	Bổ sung chi tiết thao tác	Trả lời phần thuộc thẩm quyền

Developer dùng đầu ra để biến nhu cầu thành hành vi kỹ thuật. QA dùng cùng đầu ra để kiểm tra hành vi đó, không dùng suy đoán riêng. Architect dùng đầu ra để xem các thành phần ERP, API và dữ liệu có thể phối hợp hay không. PM/Product Owner dùng đầu ra để quản lý phạm vi và thứ tự làm việc. Business Owner dùng đầu ra để kiểm tra giá trị nghiệp vụ. Operations dùng đầu ra để kiểm tra thao tác có chạy được trong ca vận hành. Specialist owner là chủ sở hữu chuyên môn như Accounting Owner, Legal Owner, Food-safety owner hoặc Security owner; họ chỉ kiểm tra phần thuộc thẩm quyền của mình.

Applied

Trường	Nội dung
Facts	Discovery note mô phỏng ghi: kho nhận thành phẩm theo mã lô; bộ phận bán hàng cần xem lô khi lập đơn xuất.
Current Behavior	Nhân viên tra cứu lô qua bảng tính nội bộ trước khi nhập đơn.
Underlying Need	Cần hiển thị lô phù hợp trong luồng đơn xuất để giảm tra cứu ngoài ERP.
Options	Hiển thị mọi lô; chỉ hiển thị lô còn số lượng; lấy lô từ hệ thống kho qua API.
Decision Criteria	Dữ liệu lô phải đúng nguồn, thao tác không tạo xuất vượt tồn, tích hợp không làm chậm giao dịch vượt ngưỡng đã xác minh.
Decision	Chưa có quyết định; artifact chỉ đưa lựa chọn sang review.
Authority	Business Owner xem giá trị; Architect xem tích hợp; Operations xem thao tác kho; Food-safety owner xác minh nội dung truy xuất lô nếu áp dụng.
Artifact	Discovery note, process map, requirement draft, data field list và open question log ở IN_REVIEW.
Consequence if Wrong	Developer có thể lọc sai lô; QA kiểm thử sai kỳ vọng; Operations không xuất được hàng; specialist owner không thấy điểm cần xác minh.

Developer đọc requirement draft để biết cần hiển thị lô ở đâu. QA đọc process map và rule candidate để tạo ca chọn lô hợp lệ, lô hết số lượng và lô không tồn tại. Architect đọc data field list để xác định nguồn Lot, số lượng và API. PM/Product Owner đọc discovery note để thấy phạm vi tác động giữa bán hàng và kho. Business Owner đọc underlying need để kiểm tra lợi ích. Operations đọc current behavior để so sánh thao tác mới với ca xuất hàng. Food-safety owner đọc phần truy xuất lô vì đây là điểm chuyên môn; mô tả nghĩa vụ pháp lý vẫn là Verification required.

Senior Lens

Một output có nhiều người dùng, nhưng mỗi người dùng nó theo câu hỏi khác nhau. Cùng một process map không tự là thiết kế màn hình, test case, quyết định kiến trúc hay xác nhận nghiệp vụ. BA giữ một nguồn ghi nhận thống nhất và gắn rõ output nào phục vụ vai trò nào. Điều này ngăn Developer coi ghi chú phỏng vấn là yêu cầu cuối cùng, hoặc QA coi mockup là rule nghiệp vụ.

Quick Reference

Consumer	Câu hỏi họ dùng output để trả lời
Developer	Hệ thống phải làm gì và nhận dữ liệu nào?
QA	Hành vi nào phải kiểm thử trong luồng chính và ngoại lệ?
Architect	Thành phần, dữ liệu và tích hợp nào bị tác động?
PM/Product Owner	Phạm vi nào cần được ưu tiên và theo dõi?
Business Owner	Nhu cầu này có tạo giá trị nghiệp vụ không?
Operations	Người vận hành có thực hiện được trong quy trình thực tế không?
Specialist owner	Nội dung nào cần kiểm tra theo chuyên môn được giao?

Core

Đầu ra phỏng vấn chỉ giúp người nhận ra quyết định; không tự tạo thẩm quyền quyết định. Nova Foods là case mô phỏng, chỉ dùng dữ liệu tổng hợp; mọi artifact đang IN_REVIEW, v0.9.0, ngày 2026-08-07, chưa là baseline hay approval.

Consumer	Có thể quyết định	Bằng chứng cần có	Phải escalation khi
Developer	Cách hiện thực, kiểm tra khả thi kỹ thuật, ước lượng tác động mã nguồn	Luồng hiện tại, business rule, dữ liệu đầu vào/đầu ra, tiêu chí chấp nhận, ràng buộc tích hợp	Rule mơ hồ, API nguồn không xác định, thay đổi phá vỡ dữ liệu hoặc quyền truy cập
QA	Test basis, phạm vi kiểm thử, dữ liệu test tổng hợp, điều kiện pass/fail	Requirement truy vết được, ví dụ hợp lệ/lỗi, expected result, rủi ro	Không có expected result, hai nguồn mâu thuẫn, không xác định owner chấp nhận lỗi
Architect	Phương án kiến trúc, tích hợp, bảo mật, hiệu năng, khả năng vận hành	Context system, volume giả định, dependency, data classification, interface constraint	Quyết định ảnh hưởng nhiều hệ thống, dữ liệu cá nhân, bảo mật, chi phí hoặc kiến trúc chuẩn
PM/Product Owner	Ưu tiên, phạm vi release, trade-off thời gian/chi phí/giá trị	Underlying Need, tác động người dùng, dependency, ước lượng, rủi ro	Trade-off làm đổi business outcome, phạm vi vượt mục tiêu, owner nghiệp vụ chưa xác nhận
Business Owner	Ý nghĩa nghiệp vụ, ưu tiên giá trị, ngoại lệ nghiệp vụ	Facts, Current Behavior, tác động doanh thu/chi phí/rủi ro, Options, Decision Criteria	Quy tắc có thể là kế toán, thuế, pháp lý, an toàn thực phẩm hoặc vượt quyền đơn vị
Operations	Khả năng chạy hằng ngày, phân quyền vận hành, xử lý lỗi, hỗ trợ người dùng	Luồng ngoại lệ, SLA giả định, màn hình/biểu mẫu, dữ liệu vận hành tổng hợp	Thay đổi ca làm, kiểm soát kho, quy trình thực địa, dữ liệu không thể khôi phục
Specialist owner	Kết luận chuyên môn trong vùng sở hữu: Accounting, Legal, Security, Food Safety	Nguồn chính thức, giả định dự án, data flow, rule đang tranh chấp	Có yêu cầu diễn giải luật, hạch toán, bảo vệ dữ liệu, truy xuất/thu hồi thực phẩm hoặc kiểm soát bảo mật

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

flowchart TB
    N[Interview note] --> B[BA package: facts, evidence, open decision]
    B --> C{Decision within consumer authority?}
    C -->|Yes| D[Consumer-scope decision]
    C -->|No| E[Specialist or owner review]
    E --> F{Within specialist or owner authority?}
    F -->|Yes| G[Specialist or owner decision]
    F -->|No, conflict, or escalation condition| X[Escalation record]
    D --> R[Traceable requirement, risk, or decision]
    G --> R
    X --> R
    R --> S[IN_REVIEW v0.9.0<br/>Not baseline or approval]

Applied

Facts: Phiếu phỏng vấn tổng hợp ghi nhận kho Nova Foods muốn chặn xuất hàng khi lô hàng không có ngày hết hạn. Current Behavior: Nhân viên kiểm tra bằng mắt trên phiếu kho; ERP mô phỏng chưa có điểm kiểm tra được xác định. Underlying Need: Giảm nguy cơ xuất nhầm lô thiếu thông tin truy xuất. Facts chỉ chứng minh vấn đề vận hành; chưa chứng minh quy tắc pháp lý hay cấu hình ERP bắt buộc.

Thành phần	Nội dung
Options	Chặn tạo phiếu xuất; cảnh báo nhưng cho phép tiếp tục; giữ kiểm tra thủ công
Decision Criteria	Mức giảm rủi ro, tác động giao hàng, dữ liệu lô hiện có, quyền override, khả năng audit
Decision	Chưa chọn phương án. Ghi nhận cần quyết định nghiệp vụ và xác minh chuyên môn trước khi biến thành requirement
Authority	Business Owner quyết định trade-off nghiệp vụ; Food Safety owner xác minh ngữ cảnh truy xuất; Architect đánh giá điểm kiểm tra và audit; QA xác định test basis sau khi rule rõ
Artifact	Interview note, decision log và liên kết dự kiến tới CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY
Consequence if Wrong	Developer có thể chặn đơn giao hợp lệ; QA không có expected result; Operations phải dùng workaround; rủi ro truy xuất bị xử lý sai

Senior Lens

Evidence phải đủ để người nhận kiểm tra lại kết luận mà không cần tin BA. Chuỗi suy luận tối thiểu: fact quan sát được, nguồn fact, tác động, lựa chọn, tiêu chí, owner quyết định. Thiếu một mắt xích, ghi là open decision; không đổi thành business rule.

Escalation không phải chuyển trách nhiệm. BA đóng gói câu hỏi, bằng chứng mâu thuẫn, lựa chọn và tác động; role có thẩm quyền kết luận phần thuộc phạm vi mình. Với nội dung pháp lý, kế toán, thuế, bảo vệ dữ liệu hoặc an toàn thực phẩm, giữ nhãn Verification required đến khi specialist owner xác minh theo nguồn chính thức.

Quick Reference

Tình huống	Hành động BA
Developer hỏi “có được override không?”	Không tự trả lời. Đưa Business Owner quyết định; Architect và Security owner tham gia nếu override đổi quyền truy cập hoặc audit
QA hỏi “kết quả đúng là gì?”	Yêu cầu rule, ví dụ và owner xác nhận expected result; không dùng suy đoán từ lời kể
PM muốn đưa vào release	Cung cấp dependency, rủi ro và quyết định còn mở; PM/Product Owner ưu tiên, không tự xác nhận rule chuyên môn
Specialist owner nhận yêu cầu luật/kế toán	Gắn Verification required, dẫn nguồn chính thức phù hợp, chờ kết luận thẩm quyền

Core

Nhầm lẫn bàn giao xảy ra khi người nhận đọc cùng một ghi chú nhưng gán nghĩa khác nhau. Ghi chú phỏng vấn chỉ là bằng chứng lời nói; nó không tự thành quy tắc nghiệp vụ, quyết định kiến trúc, tiêu chí kiểm thử hay phê duyệt. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp; mọi điểm chưa xác minh phải giữ trạng thái cần làm rõ.

Hiểu nhầm phổ biến	Rủi ro	Câu hỏi làm rõ chính xác
Developer hiểu “chặn đơn vượt hạn mức” là kiểm tra khi bấm Lưu. Business Owner có thể muốn kiểm tra khi Gửi duyệt.	Sai thời điểm kiểm soát, đơn hợp lệ bị chặn hoặc đơn rủi ro lọt qua.	“Hệ thống phải kiểm tra hạn mức tại thao tác nào: Lưu nháp, Gửi duyệt, Phê duyệt hay Phát hành đơn?”
QA hiểu “hiển thị cảnh báo” là điều kiện pass. PM/Product Owner chỉ coi đó là gợi ý giao diện.	Test sai mức bắt buộc; lỗi nghiệp vụ không bị chặn.	“Cảnh báo này có cho phép người dùng tiếp tục không? Nếu có, vai trò nào được tiếp tục và hệ thống phải lưu lý do nào?”
Architect hiểu “tự động đồng bộ” là đồng bộ thời gian thực. Operations có thể chấp nhận chạy theo lịch.	Thiết kế tích hợp quá mức hoặc chậm dữ liệu vận hành.	“Dữ liệu cần xuất hiện ở hệ thống nhận chậm nhất bao lâu sau sự kiện nguồn: ngay lập tức, theo phút, theo giờ hay cuối ngày?”
Specialist owner nói “đúng hóa đơn” nhưng không nêu nguồn pháp lý hoặc thẩm quyền diễn giải.	BA biến nhận định chuyên môn thành yêu cầu pháp lý.	“Quy tắc này là giả định dự án, quy trình nội bộ hay yêu cầu pháp lý? Ai là Legal Owner hoặc Accounting Owner xác nhận nguồn và cách áp dụng?”
Operations nói “cần truy vết lô” nhưng Developer chỉ lưu mã lô trên đơn bán.	Không đủ dữ liệu điều tra, thu hồi hoặc đối soát.	“Truy vết cần đi qua các đối tượng nào: nguyên liệu, lệnh sản xuất, thành phẩm, kho, giao hàng, trả hàng? Điểm bắt đầu và điểm kết thúc là gì?”
PM/Product Owner nói “ưu tiên nhanh” nhưng không nêu tiêu chí hoàn thành.	Scope trôi; đội giao chức năng không dùng được.	“Kết quả tối thiểu để coi hạng mục sẵn sàng sử dụng là gì, ai kiểm tra, và bằng chứng hoàn thành là màn hình, báo cáo, API hay kịch bản?”

Applied

Facts: Trong ghi chú phỏng vấn mô phỏng, nhân viên bán hàng Nova Foods nói: “Đơn khách vượt hạn mức cần báo ngay.” Không có thời điểm kiểm tra, mức chặn, vai trò ngoại lệ, nguồn hạn mức, hay người quyết định được ghi nhận.

Current Behavior: Developer có thể dựng cảnh báo khi nhập tổng tiền đơn. QA có thể viết test mong cảnh báo xuất hiện. Hai cách hiểu đều có bằng chứng là câu nói trên, nhưng thiếu điều kiện quyết định nên không chứng minh cách hiểu nào đúng.

Underlying Need: Cần phân biệt “báo” là thông tin, “chặn” là kiểm soát bắt buộc, và “ngoại lệ” là quyền vượt kiểm soát. Bằng chứng cần bổ sung là luồng xử lý đơn, nguồn dữ liệu hạn mức, vai trò phê duyệt và hậu quả khi vượt hạn mức.

Options: (1) Chỉ cảnh báo, vẫn cho gửi đơn. (2) Chặn gửi đơn, chỉ quản lý tín dụng được duyệt ngoại lệ. (3) Cho gửi đơn nhưng giữ trạng thái chờ duyệt tín dụng.

Decision Criteria: Business Owner đánh giá tác động doanh thu và quan hệ khách hàng. Specialist owner về tín dụng xác nhận nguồn hạn mức và quyền ngoại lệ. QA cần trạng thái, dữ liệu biên và kết quả mong đợi có thể kiểm thử. Architect cần biết có gọi dịch vụ tín dụng hay không, đồng bộ hay bất đồng bộ.

Decision: Chưa có quyết định. Ghi nhận phát biểu là Verification required; không chuyển thành business rule trong CANONICAL_BUSINESS_RULES.

Authority: Business Owner và specialist owner tín dụng quyết định chính sách nghiệp vụ. Architect quyết định khả năng tích hợp sau khi chính sách rõ. QA xác nhận khả năng kiểm thử, không tự chọn chính sách.

Artifact: Ghi câu hỏi làm rõ vào ghi chú phỏng vấn và liên kết tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY khi các artifact này có nội dung được kiểm soát. Giữ nguyên trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Consequence if Wrong: Chọn cảnh báo thay vì chặn có thể tạo đơn vượt kiểm soát. Chọn chặn thay vì chờ duyệt có thể làm gián đoạn bán hàng. Không vai trò nào được suy diễn thay quyết định chưa có bằng chứng.

Senior Lens

Dùng câu hỏi đóng để chốt thuộc tính kiểm thử được: thời điểm, điều kiện, vai trò, dữ liệu, trạng thái, ngoại lệ, bằng chứng. Dùng câu hỏi mở khi chưa biết phạm vi: “Điều gì xảy ra sau khi vượt hạn mức?” Sau đó đổi thành câu hỏi chính xác: “Nếu vượt hạn mức, đơn chuyển sang trạng thái nào và ai được chuyển tiếp?”

Không hỏi “Anh/chị có đồng ý không?” vì câu này dễ tạo cảm giác phê duyệt không được ghi nhận. Hỏi: “Ai có thẩm quyền quyết định điểm này, và artifact nào ghi nhận quyết định?” Nếu câu trả lời liên quan pháp lý, kế toán, thuế, an toàn thực phẩm, dữ liệu cá nhân hoặc bảo mật, escalation tới owner chuyên môn; BA chỉ giữ bằng chứng, câu hỏi và traceability.

Quick Reference

Khi nghe cụm từ	Phải làm rõ
“tự động”	Sự kiện kích hoạt, thời hạn xử lý, cơ chế chạy lại khi lỗi
“ngay”	Thời lượng đo được, múi giờ Asia/Ho_Chi_Minh, ngoại lệ quá hạn
“đúng”	Nguồn chuẩn, người có thẩm quyền, dữ liệu đối chiếu
“được duyệt”	Vai trò duyệt, điều kiện duyệt, trạng thái trước và sau duyệt
“bảo mật”	Dữ liệu nào, ai truy cập, hành động nào bị cấm, owner bảo mật
“theo quy định”	Văn bản nguồn, phiên bản hiệu lực, Legal Owner xác minh

8. Detailed Worked Example

Core

Ví dụ này thuộc Nova Foods Trading & Manufacturing, mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Mục tiêu: BA ghi nhận đúng sự kiện và luồng hiện tại trước khi suy luận nhu cầu hay đề xuất thay đổi. Trạng thái corpus: IN_REVIEW; phiên bản v0.9.0; ngày 2026-08-07; locale vi-VN; múi giờ Asia/Ho_Chi_Minh; tiền tệ VND.

Applied

Kịch bản: Nhân viên kinh doanh tạo đơn bán sữa hạt đóng chai cho khách hàng đại lý. Đơn có giá trị vượt hạn mức tín dụng nội bộ đang theo dõi bằng bảng tính.

Nhóm fact	Giá trị tổng hợp được ghi nhận	Bằng chứng ghi chú
Khách hàng	CUS-DF-018, Đại lý Minh Phát, quận Bình Tân, TP. Hồ Chí Minh	Nhân viên kinh doanh đọc từ danh sách khách hàng ERP
Đơn bán	SO-20260807-014, tạo lúc 2026-08-07 10:15:00	Email nội bộ mô phỏng kèm ảnh chụp màn hình đơn
Mặt hàng	FG-NUT-330ML-ORIG, Sữa hạt nguyên bản 330 ml	Dòng hàng trên đơn
Số lượng	1.200 chai	Dòng hàng trên đơn
Đơn giá	18.500 VND/chai, chưa gồm VAT	Dòng hàng trên đơn
Giá trị hàng	22.200.000 VND	1.200 × 18.500
Công nợ đang mở	135.000.000 VND	Bảng tính công nợ do Kế toán công nợ cập nhật ngày 2026-08-07
Hạn mức đang theo dõi	150.000.000 VND	Cột “Hạn mức” trong cùng bảng tính
Tổng phơi nhiễm sau đơn	157.200.000 VND	135.000.000 + 22.200.000
Mức vượt	7.200.000 VND	157.200.000 - 150.000.000
Kho xuất dự kiến	WH-HCM-01	Nhân viên kho nhận yêu cầu qua email nội bộ mô phỏng
Trạng thái ERP hiện thấy	Confirmed	Nhân viên kinh doanh xác nhận đơn sau khi lưu
Phạm vi dữ liệu	Dữ liệu tổng hợp, không phải dữ liệu khách hàng thật	Ranh giới case study Nova Foods mô phỏng

Facts (sự kiện quan sát được): Đơn SO-20260807-014 được xác nhận trong ERP dù tổng phơi nhiễm tín dụng là 157.200.000 VND, cao hơn hạn mức đang theo dõi 7.200.000 VND. Bằng chứng tính toán là số dư mở 135.000.000 VND cộng giá trị hàng 22.200.000 VND. Hạn mức không nằm trong ERP; Kế toán công nợ giữ trong bảng tính riêng. Đây là fact vì có nguồn ghi nhận và phép tính kiểm tra được, không phải ý kiến về đúng hoặc sai.

Current Behavior (hành vi hiện tại): Nhân viên kinh doanh tra bảng tính công nợ trước khi xác nhận đơn nếu nhớ thực hiện bước này. ERP không hiển thị số dư mở, hạn mức, tổng phơi nhiễm hoặc mức vượt tại màn hình xác nhận đơn. Khi đơn đã ở trạng thái Confirmed, yêu cầu xuất hàng được gửi qua email cho kho WH-HCM-01. Nhân viên kho kiểm tra tồn kho và chuẩn bị hàng, không có dữ liệu hạn mức tín dụng trong yêu cầu nhận được.

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

flowchart TB
    A[Nhân viên kinh doanh tạo SO-20260807-014] --> B{Nhớ tra bảng tính công nợ?}
    B -- Có --> C[Tra bảng tính công nợ thủ công]
    B -- Không --> E[Xác nhận đơn trong ERP: Confirmed]
    G[Kế toán công nợ cập nhật bảng tính<br/>CUS-DF-018: công nợ mở 135.000.000 VND<br/>Hạn mức: 150.000.000 VND] --> C
    C --> E
    E --> F[Gửi email yêu cầu xuất hàng<br/>Không chứa dữ liệu hạn mức tín dụng]
    F --> H[Kho WH-HCM-01 kiểm tra tồn kho và chuẩn bị hàng]
    I[Đối chiếu fact của case study<br/>135.000.000 + 22.200.000 = 157.200.000 VND<br/>Vượt hạn mức 7.200.000 VND] -. phép tính kiểm chứng .-> E
    J[ERP không hiển thị<br/>công nợ mở, hạn mức, tổng phơi nhiễm, mức vượt] -. tại bước xác nhận .-> E

Ranh giới ghi nhận: ví dụ chưa khẳng định việc chặn đơn, duyệt ngoại lệ, xuất hóa đơn, ghi sổ kế toán, tuân thủ tín dụng hoặc nghĩa vụ pháp lý. Các điểm này chưa có quyết định có thẩm quyền trong artifact hiện hành.

Senior Lens

Phân biệt “ERP không hiển thị hạn mức” với “ERP phải chặn đơn”. Câu đầu là quan sát về hành vi hiện tại, có thể kiểm tra bằng màn hình và luồng thao tác

Applied

Bối cảnh: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp, vi-VN, Asia/Ho_Chi_Minh, VND. Tình huống: Nhân viên kho nhận 120 thùng sữa hạt, phát hiện 8 thùng móp vỏ ngoài. BA phỏng vấn để làm rõ cách ERP ghi nhận hàng nhận có vấn đề.

Bước phân tích	Nội dung đã ghi nhận	Bằng chứng hoặc cầu nối suy luận
Facts	Phiếu nhận hàng mô phỏng GRN-NF-20260807-001 nhận từ nhà cung cấp SUP-NF-014; mặt hàng FG-NF-ALM-1L; số lượng đặt 120 thùng; số lượng nhận vật lý 120 thùng; 8 thùng móp vỏ; giá trị đơn vị 288.000 VND/thùng.	Ghi chú phỏng vấn mô phỏng ngày 2026-08-07: thủ kho đọc số lượng từ phiếu giao, kiểm tra trực quan trước khi nhập kho.
Current Behavior	Thủ kho nhập đủ 120 thùng vào kho khả dụng. Sau đó gửi ảnh qua nhóm chat nội bộ để mua hàng làm việc với nhà cung cấp. ERP không lưu số lượng móp, ảnh, trạng thái xử lý hoặc liên kết khiếu nại.	Có một lần nhập kho duy nhất. Không có trường dữ liệu hoặc trạng thái riêng cho hàng cần kiểm tra. Vì vậy 8 thùng móp được tính vào tồn khả dụng.
Underlying Need	Cần tách “đã nhận vật lý” khỏi “được phép xuất bán hoặc sản xuất”. Cần truy vết 8 thùng từ lúc phát hiện đến quyết định trả hàng, giảm giá hoặc chấp nhận dùng.	Nếu ERP chỉ có số lượng nhận 120, kế hoạch cung ứng thấy 120 thùng khả dụng dù 8 thùng chưa được đánh giá. Sai khác nằm ở trạng thái chất lượng, không nằm ở phép cộng số lượng.
Options	O1: Nhập 120 thùng khả dụng, ghi chú tự do về hư hỏng. O2: Nhập 120 thùng vào trạng thái PENDING_INSPECTION; tách 8 thùng QUARANTINED; 112 thùng AVAILABLE sau kiểm tra trực quan. O3: Từ chối toàn bộ 120 thùng ngay tại cổng nhận hàng.	O1 giữ quy trình cũ nhưng không chặn xuất nhầm. O2 giữ bằng chứng số lượng nhận và cô lập phần có rủi ro. O3 chỉ phù hợp khi chính sách nhận hàng hoặc bằng chứng chất lượng yêu cầu từ chối toàn bộ; đầu vào hiện có chưa chứng minh điều đó.
Decision Criteria	C1: Không cho phép 8 thùng móp được cấp phát tự động. C2: Bảo toàn số lượng nhận vật lý 120 thùng. C3: Có người chịu trách nhiệm đổi trạng thái. C4: Có thể đối chiếu với phiếu nhận và bằng chứng ảnh. C5: Không tự diễn giải nghĩa vụ pháp lý, kế toán hoặc an toàn thực phẩm.	C1 và C2 giải quyết sai lệch tồn kho. C3 và C4 tạo khả năng truy vết. C5 giữ đúng ranh giới: tình huống học liệu không thay thế kết luận của Accounting Owner, Legal Owner hoặc Food Safety Owner.
Decision	Khuyến nghị BA: chọn O2. Khi tạo phiếu nhận, hệ thống ghi nhận 120 thùng; 112 thùng được chuyển AVAILABLE; 8 thùng được chuyển QUARANTINED; cả hai cùng liên kết GRN-NF-20260807-001. Không phải quyết định đã được ủy quyền: chưa có tham chiếu approval hoặc baseline tại v0.9.0, trạng thái corpus là IN_REVIEW.	O2 đáp ứng C1 đến C4 mà không kết luận phải trả hàng, hủy hàng hay hạch toán giảm giá. Các kết luận đó cần vai trò có thẩm quyền.
Authority	Warehouse Supervisor xác nhận số lượng vật lý và vị trí cách ly. Quality Owner xác nhận kết quả kiểm tra chất lượng và quyết định RELEASE, RETURN hoặc DISPOSE. Procurement Owner xử lý yêu cầu với nhà cung cấp. Accounting Owner xác nhận tác động chứng từ, giá trị và hạch toán.	Mỗi quyết định thuộc chuyên môn khác nhau. BA ghi nhận, phân tích và liên kết; BA không tự đổi trạng thái chất lượng, không quyết định xử lý tài chính.
Artifact	Ghi vào ghi chú phỏng vấn và backlog trong /02-handbook/03-discovery-interviewing-and-note-taking.md; liên kết quản trị tới TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY. Payload mẫu dưới đây là dữ liệu tổng hợp.	Artifact biến lời kể thành dữ liệu kiểm tra được: số lượng, trạng thái, chủ thể, bằng chứng và quyết định còn chờ thẩm quyền.
Consequence if Wrong	Nếu chọn O1, ERP có thể cấp phát 120 thùng cho đơn bán hoặc lệnh sản xuất; 8 thùng móp có thể rời kho trước khi Quality Owner đánh giá. Nếu chọn O3 khi chưa đủ căn cứ, Nova Foods mô phỏng có thể ghi nhận sai số lượng nhận và gây tranh chấp giả định với nhà cung cấp. Nếu BA gọi O2 là “đã phê duyệt”, traceability sai vì corpus không có approval reference.	Mỗi lỗi đều xuất phát từ nhầm lẫn giữa sự kiện quan sát được, khuyến nghị BA và quyết định thuộc thẩm quyền.

{
  "goodsReceiptId": "GRN-NF-20260807-001",
  "supplierId": "SUP-NF-014",
  "itemId": "FG-NF-ALM-1L",
  "receivedQuantity": 120,
  "unit": "thung",
  "unitValueVND": 288000,
  "inventoryDisposition": [
    {
      "quantity": 112,
      "status": "AVAILABLE",
      "reason": "Bao bi ngoai quan sat khong hu hong"
    },
    {
      "quantity": 8,
      "status": "QUARANTINED",
      "reason": "Thung mop vo ngoai; cho Quality Owner danh gia",
      "evidence": "Anh kiem tra tong hop dinh kem phieu nhan"
    }
  ],
  "decisionStatus": "RECOMMENDED_NOT_AUTHORIZED"
}

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

flowchart TB
    R["Đề xuất BA — RECOMMENDED_NOT_AUTHORIZED<br/>Corpus: IN_REVIEW; chưa có approval reference"]
    A["Nhận vật lý: 120 thùng<br/>GRN-NF-20260807-001"]
    W["Warehouse Supervisor xác nhận<br/>số lượng vật lý"]
    B["120 thùng: PENDING_INSPECTION"]
    C["Kiểm tra trực quan"]
    D["112 thùng: AVAILABLE"]
    E["8 thùng móp: QUARANTINED"]
    Q["Warehouse Supervisor xác nhận<br/>vị trí cách ly"]
    P["Ảnh kiểm tra tổng hợp<br/>liên kết GRN-NF-20260807-001"]
    F["Quality Owner đánh giá"]
    G["RELEASE<br/>8 thùng chuyển AVAILABLE"]
    H["RETURN<br/>8 thùng không được cấp phát"]
    I["DISPOSE<br/>8 thùng không được cấp phát"]
    J["Hệ thống chỉ cho phép cấp phát<br/>số lượng AVAILABLE"]
    K["QUARANTINED không được cấp phát,<br/>dùng cho sản xuất hoặc chuyển kho<br/>trước khi Quality Owner đổi trạng thái"]
    X["Nếu bỏ qua kiểm soát: 8 thùng móp<br/>có thể được cấp phát trước đánh giá"]
    L["Procurement Owner xử lý<br/>với nhà cung cấp"]
    M["Accounting Owner xác nhận tác động<br/>chứng từ, giá trị, hạch toán khi áp dụng"]

    R --> A --> W --> B --> C
    C --> D --> J
    C --> E
    E --> Q
    E --- P
    P --- F
    E -. kiểm soát .-> K
    K -. nếu bỏ qua .-> X
    E --> F
    F --> G --> J
    F --> H --> L
    H --> M
    F --> I --> M

Quy tắc đề xuất để thẩm quyền xem xét: Số lượng có trạng thái QUARANTINED không được hệ thống cấp phát cho đơn bán, lệnh sản xuất hoặc chuyển kho cho đến khi Quality Owner đổi trạng thái. Đây là khuyến nghị phân tích, không phải quy tắc Nova Foods đã được phê duyệt.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ dữ liệu dưới đây là tổng hợp, dùng vi-VN, Asia/Ho_Chi_Minh, VND. Artifact liên quan đang IN_REVIEW, v0.9.0, ngày 2026-08-07; không có baseline hay phê duyệt được ghi nhận.

Loại	ID	Nội dung đầy đủ	Phân loại nguồn
Kịch bản phỏng vấn	SCN-DISC-RECEIPT-001	Thủ kho nhận 500 kg bột mì lô LOT-WHT-260807-01; phát hiện 35 kg bao rách sau khi phiếu nhập đã hoàn tất.	Dữ liệu mô phỏng
Buổi phỏng vấn	INT-DISC-001	2026-08-07 09:00; Người ghi: BA mô phỏng; vai trò được hỏi: Thủ kho nguyên liệu.	Ghi chú mô phỏng
Quy tắc đề xuất	BR-REC-001	Không được tăng tồn kho khả dụng khi lô hàng chưa hoàn tất kiểm tra chất lượng.	Khuyến nghị BA; chưa là quy tắc canonical
Yêu cầu đề xuất	FR-REC-001	ERP phải lưu riêng số lượng nhận, số lượng chờ kiểm tra, số lượng đạt, số lượng từ chối theo từng lô.	Khuyến nghị BA; chưa được ủy quyền
Payload minh họa	PAY-REC-001	Dữ liệu API nhận hàng bên dưới.	Dữ liệu mô phỏng

Facts — sự kiện quan sát được: Thủ kho nhập phiếu nhận hàng trước, rồi ghi số bao rách vào sổ giấy. Sổ giấy không có liên kết bắt buộc tới mã lô ERP. ERP hiện chỉ có một trường receivedQuantityKg; không có trạng thái kiểm tra chất lượng. Bằng chứng là payload hiện tại không chứa qualityStatus, acceptedQuantityKg, rejectedQuantityKg hoặc damageReason.

{
  "receiptId": "GRN-260807-001",
  "supplierCode": "SUP-SYN-014",
  "materialCode": "RM-WHEAT-001",
  "lotCode": "LOT-WHT-260807-01",
  "receivedQuantityKg": 500,
  "unit": "KG",
  "receivedAt": "2026-08-07T08:42:00+07:00",
  "warehouseCode": "WH-HCM-RM-01"
}

Current Behavior — hành vi hiện tại: Sau khi lưu GRN-260807-001, ERP cộng đủ 500 kg vào tồn kho dùng được. Bộ phận sản xuất có thể cấp phát 500 kg dù 35 kg đang hỏng. Suy luận này dựa trên hai fact: chỉ có một số lượng nhận và không có trạng thái chất lượng; vì vậy hệ thống không có dữ liệu để chặn phần hàng chưa đạt.

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

flowchart TB
    A[Thủ kho nhận 500 kg] --> B[Thủ kho lưu GRN-260807-001]
    B --> C[ERP tăng tồn khả dụng 500 kg]
    B --> D[Thủ kho ghi 35 kg bao rách vào sổ giấy]
    B --> H[ERP chỉ lưu receivedQuantityKg; không có trạng thái chất lượng]
    D --> E[Sổ giấy không liên kết mã lô ERP]
    E --> G[ERP không có dữ liệu để chặn 35 kg chưa đạt]
    H --> G
    C --> F[Sản xuất có thể cấp phát toàn bộ 500 kg]
    G --> F

Underlying Need — nhu cầu gốc: Cần tách “đã nhận vật lý” khỏi “được phép dùng”. Đây không phải nhu cầu tạo thêm màn hình vì có sổ giấy; cần nguồn dữ liệu ERP liên kết theo lô để quyết định cấp phát dùng cùng dữ liệu với nhận hàng. Nhu cầu không tự khẳng định nghĩa vụ pháp lý hoặc an toàn thực phẩm; việc đối chiếu Luật An toàn thực phẩm cần Domain Owner và Legal Owner xác minh.

Phương án	Mô tả	Lợi ích	Hạn chế
OPT-REC-001	Giữ sổ giấy, sửa tồn kho thủ công cuối ngày.	Không đổi ERP.	Lệch thời điểm; không chặn cấp phát ngay.
OPT-REC-002	Thêm trường ghi chú hư hỏng vào phiếu nhận.	Ít thay đổi dữ liệu.	Không tách số lượng dùng được; ghi chú không hỗ trợ kiểm soát số lượng.
OPT-REC-003	Lưu số lượng theo lô và trạng thái PENDING_QC, ACCEPTED, REJECTED; chỉ ACCEPTED tăng tồn khả dụng.	Truy vết, chặn cấp phát, đối chiếu được.	Cần luồng kiểm tra chất lượng.

Tiêu chí quyết định	Trọng số	OPT-REC-001	OPT-REC-002	OPT-REC-003
Chặn dùng hàng chưa kiểm tra	5	1	1	5
Truy vết theo mã lô	5	2	2	5
Dữ liệu cho đối chiếu tồn kho	4	2	3	5
Ít thay đổi vận hành	2	5	4	3
Tổng có trọng số		33	35	68

Decision — kết luận phân tích: Khuyến nghị OPT-REC-003. Điểm 68 cao nhất vì đáp ứng hai rủi ro chính được fact chứng minh: cấp phát nhầm và mất liên kết lô. Đây là khuyến nghị BA, không phải quyết định đã được ủy quyền.

Trạng thái quyết định	Nội dung	Authority — thẩm quyền
Khuyến nghị	Chọn OPT-REC-003; áp dụng BR-REC-001.	BA mô phỏng ghi nhận và truy vết.
Quyết định được ủy quyền	Chưa có.	Business Owner quyết định quy trình; Quality Owner xác nhận trạng thái chất lượng; Architect xác nhận thiết kế; không được suy diễn phê duyệt từ IN_REVIEW.

Artifact — đầu ra ghi nhận: Ghi nội dung vào /02-handbook/03-discovery-interviewing-and-note-taking.md với liên kết tới INT-DISC-001, SCN-DISC-RECEIPT-001, BR-REC-001, FR-REC-001, OPT-REC-003, PAY-REC-001. Các ID này là ID mô phỏng cục bộ của ví dụ, không thay thế TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES hoặc CANONICAL_DATA_DICTIONARY.

{
  "receiptId": "GRN-260807-001",
  "lotCode": "LOT-WHT-260807-01",
  "receivedQuantityKg": 500,
  "qualityStatus": "PENDING_QC",
  "acceptedQuantityKg": 0,
  "rejectedQuantityKg": 0,
  "availableQuantityKg": 0,
  "damageReport": {
    "damagedQuantityKg": 35,
    "reason": "Rách bao khi nhận hàng"
  }
}

Consequence if Wrong — hậu quả nếu kết luận sai: Nếu chọn OPT-REC-002, ERP vẫn có thể coi 500 kg là dùng được; 35 kg hỏng chỉ nằm trong ghi chú. Nếu quy tắc chất lượng bị diễn giải như yêu cầu pháp lý khi chưa xác minh, corpus vượt thẩm quyền Legal Owner. Nếu gọi khuyến nghị là quyết định được ủy quyền, traceability sai trạng thái và che mất người chịu trách nhiệm phê duyệt.

9. Related Concepts & Dependencies

Core

Dependency là quan hệ phụ thuộc: artifact này cần dữ kiện, ID, cấu trúc hoặc quyết định từ artifact khác để giữ nghĩa nhất quán. Upstream là nguồn đi trước; downstream là nơi dùng kết quả sau đó. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu đều tổng hợp; IN_REVIEW, v0.9.0, ngày 2026-08-07 không phải baseline hay phê duyệt.

Nguồn chân lý canonical là nơi duy nhất sở hữu nội dung gốc. Handbook chỉ liên kết, tóm tắt mục đích và ghi tác động; không chép lại rule, định nghĩa trường dữ liệu, ID registry hoặc metadata. Lý do: hai bản cùng chứa một rule có thể lệch nhau sau thay đổi, làm người đọc dùng nhầm bản.

Loại nội dung	Nguồn canonical	Handbook được làm gì	Handbook không được làm gì
Cấu trúc chapter, filename	/01-curriculum/CHAPTER_MANIFEST.md	Liên kết chapter liên quan	Đổi tên hoặc tự tạo chapter ID
Template dự kiến	/01-curriculum/TEMPLATE_MANIFEST.md	Nêu template cần dùng	Tạo template canonical mới
Persistent ID — ID bền vững	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Dùng nguyên ID đã đăng ký	Đổi tiền tố, tái sử dụng ID
Business rule — quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Trỏ tới rule, ghi ngữ cảnh phỏng vấn	Chép rule thành nguồn thứ hai
Data definition — định nghĩa dữ liệu	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Ghi tên dữ liệu cần làm rõ	Tự định nghĩa kiểu, độ dài, miền giá trị
Nguồn và giới hạn sử dụng	/00-research/00_SOURCE_MAP.md	Giữ phân loại nguồn và nhãn xác minh	Nâng good practice thành nghĩa vụ pháp lý

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

flowchart TB
    A["/01-curriculum/CHAPTER_MANIFEST.md<br/>chapter structure, filename"] -->|canonical source| H
    B["/01-curriculum/TEMPLATE_MANIFEST.md<br/>planned template"] -->|canonical source| H
    C["/01-curriculum/TRACEABILITY_ID_REGISTRY.md<br/>persistent ID"] -->|use registered ID| H
    D["/01-curriculum/CANONICAL_BUSINESS_RULES.md<br/>business rule"] -->|canonical rule source| H
    E["/01-curriculum/CANONICAL_DATA_DICTIONARY.md<br/>data definition"] -->|canonical data source| H
    F["/00-research/00_SOURCE_MAP.md<br/>source classification, verification label"] -->|keep limits| H

    H["Handbook chapter<br/>links, purpose, impacts<br/>not canonical source"]

    H -->|context for| I["Interview note"]
    H -->|trace context for| J["Requirement artifact"]
    H -->|test context for| K["Test basis"]

    H -.->|must not copy metadata| A
    H -.->|must not copy metadata| B
    H -.->|must not copy ID registry| C
    H -.->|must not copy| D
    H -.->|must not copy| E

    R["Copied rule, definition, ID registry, or metadata<br/>creates second source and drift risk"]
    H -.->|copying causes| R

    L["Do not turn good practice<br/>into legal obligation"]
    F -.->|limit| L

Applied

Facts — sự kiện: Buổi phỏng vấn mô phỏng INT-DISC-001 ghi nhận 500 kg nguyên liệu có lotCode LOT-WHT-260807-01, trạng thái PENDING_QC, và 35 kg hỏng. Ví dụ trước dùng BR-REC-001, FR-REC-001, PAY-REC-001; các ID này là cục bộ cho ví dụ và không thay thế registry canonical.

Current Behavior — hành vi hiện tại: Người ghi chú có thể sao chép qualityStatus, quy tắc cấp phát và tên trường JSON vào nhiều note, requirement, test case. Bằng chứng là cùng một thông tin xuất hiện ở interview note, payload và rule thảo luận. Suy luận: khi mỗi nơi tự sửa, cùng thuật ngữ có nhiều nghĩa.

Underlying Need — nhu cầu gốc: Cần nối note với nguồn sở hữu từng loại thông tin, để learner biết phải hỏi ai và sửa ở đâu. Điều này không đòi tạo catalog mới; registry, rule catalog và data dictionary đã là nguồn được quy hoạch.

Options — lựa chọn:

Option	Cách làm	Rủi ro
OPT-DEP-001	Chép toàn bộ rule và field vào interview note	Lệch bản, không rõ nguồn gốc
OPT-DEP-002	Chỉ ghi ID, filename, vai trò dependency và câu hỏi mở	Cần mở artifact canonical khi cần chi tiết
OPT-DEP-003	Đặt lại ID riêng trong handbook cho mọi dependency	Trùng hoặc xung đột registry

Decision Criteria — tiêu chí: Giữ một nguồn chân lý; không đổi persistent ID; phân biệt fact phỏng vấn với rule đã xác minh; không suy diễn approval; cho phép truy ngược từ note đến artifact sở hữu nội dung.

Decision — quyết định: Khuyến nghị OPT-DEP-002. Interview note ghi INT-DISC-001 là evidence mô phỏng, tham chiếu /01-curriculum/TRACEABILITY_ID_REGISTRY.md khi cần ID bền vững, /01-curriculum/CANONICAL_BUSINESS_RULES.md khi cần rule, và /01-curriculum/CANONICAL_DATA_DICTIONARY.md khi cần nghĩa trường dữ liệu.

Authority — thẩm quyền: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết và metadata. Business Owner xác nhận nghiệp vụ; Quality Owner xác nhận trạng thái chất lượng; Architect xác nhận thiết kế tích hợp. Không có xác nhận nào được suy diễn từ trạng thái IN_REVIEW.

Artifact — đầu ra: Dependency index cục bộ trong /02-handbook/03-discovery-interviewing-and-note-taking.md.

Upstream / downstream	Vai trò	Liên kết cần giữ	Chủ sở hữu canonical
Upstream	Định danh chapter	/01-curriculum/CHAPTER_MANIFEST.md	CHAPTER_MANIFEST
Upstream	ID bền vững	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	TRACEABILITY_ID_REGISTRY
Upstream	Rule cấp phát và chất lượng	/01-curriculum/CANONICAL_BUSINESS_RULES.md	CANONICAL_BUSINESS_RULES
Upstream	lotCode, qualityStatus, quantity	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	CANONICAL_DATA_DICTIONARY
Downstream	Note phỏng vấn	INT-DISC-001	Artifact interview note
Downstream	Scenario nhận hàng	SCN-DISC-RECEIPT-001	Artifact scenario mô phỏng

Consequence if Wrong — hậu quả nếu sai: Nếu handbook đổi qualityStatus thành trạng thái khác nhưng data dictionary không đổi, developer và QA có thể dùng hai miền giá trị. Nếu BR-REC-001 được chép rồi sửa im lặng, rule gốc và note mâu thuẫn. Nếu ID cục bộ bị gọi là persistent ID, traceability có thể trỏ nhầm artifact.

Senior Lens

Senior BA không hỏi “thông tin này có ích không?” trước. Hỏi “ai sở hữu nghĩa của thông tin này?” lotCode là tên dữ liệu, nên nghĩa thuộc data dictionary; điều kiện “không cấp phát khi chờ QC” là rule, nên thuộc rule catalog; câu “35 kg rách bao” là evidence mô phỏng, nên thuộc interview note. Ba thứ có thể liên quan nhưng không được nhập làm một.

Khi chưa có nội dung canonical chi tiết, ghi Verification required cùng owner cần xác minh. Không tự điền kiểu dữ liệu, điều kiện pháp lý, logic API hoặc quy tắc vận hành để làm bảng trông hoàn chỉnh. Đây là kiểm soát phạm vi, không phải thiếu sót.

Quick Reference

Quy tắc	Áp dụng
Một nghĩa, một chủ sở hữu	Rule ở rule catalog; data ở data dictionary; ID ở registry
Link thay vì copy	Handbook giữ đường dẫn, ID, mục đích, tác động
Giữ nguyên chuỗi ID	Không dịch, rút gọn, tái dùng hoặc tự đánh số canonical ID
Phân loại rõ	Fact phỏng vấn khác assumption, recommendation, rule và decision
Không suy diễn trạng thái	IN_REVIEW không phải APPROVED hay BASELINED
Đổi dependency phải được thấy	Cập nhật nguồn canonical, rồi rà downstream link và nghĩa bị ảnh hưởng

Core

Traceability (truy vết) nối mỗi nhu cầu với requirement, rule, tiêu chí chấp nhận, dữ liệu/API và test case. Mục đích: chứng minh vì sao mục tồn tại, đâu là nguồn canonical, và test nào kiểm tra nó. Nova Foods Trading & Manufacturing là case mô phỏng; mọi dữ liệu dưới đây là tổng hợp.

Loại liên kết	Ý nghĩa	Nguồn canonical	Đích sử dụng	Quy tắc ghi nhận
NEED	Nhu cầu nghiệp vụ, mô tả vấn đề hoặc kết quả cần đạt	Nguồn ghi chú phỏng vấn đã kiểm soát	REQ, BR, AC	Không biến lời ghi chú thành requirement khi chưa phân tích
REQ	Requirement, yêu cầu hệ thống hoặc nghiệp vụ cần đáp ứng	Requirement artifact được kiểm soát	BR, AC, DATA/API, TC	Mỗi requirement giữ ID registry cấp
BR	Business Rule, quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES	REQ, AC, TC	Không sao chép nội dung rule sang bảng traceability
AC	Acceptance Criteria, điều kiện chấp nhận	Requirement artifact được kiểm soát	TC	AC phải quan sát, kiểm tra được
DATA/API	Trường dữ liệu, thực thể hoặc hợp đồng giao tiếp API	CANONICAL_DATA_DICTIONARY hoặc API specification được kiểm soát	REQ, AC, TC	Dùng ID/trường canonical, không tự đổi tên
TC	Test Case, ca kiểm thử	Test artifact được kiểm soát	Bằng chứng kiểm tra AC	TC không tự tạo business rule mới

Lập luận: NEED nêu lý do; REQ nêu khả năng cần có; BR giới hạn cách xử lý; AC nêu kết quả chấp nhận; DATA/API xác định dữ liệu hoặc giao tiếp; TC tạo kiểm chứng. Thiếu một mắt xích làm mất khả năng giải thích hoặc kiểm thử.

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

flowchart TB
    NEED[NEED: nhu cầu]
    REQ[REQ: requirement]
    BR[BR: business rule]
    DATA[DATA/API: dữ liệu hoặc hợp đồng API]
    AC[AC: acceptance criteria]
    TC[TC: test case]

    NEED -->|truy vết tới| REQ
    NEED -->|truy vết tới| BR
    NEED -->|truy vết tới| AC

    REQ -->|truy vết tới| BR
    REQ -->|xác định| AC
    REQ -->|truy vết tới| DATA
    REQ -->|truy vết tới| TC

    BR -->|ràng buộc| REQ
    BR -->|truy vết tới| AC
    BR -->|truy vết tới| TC

    DATA -->|xác định dữ liệu/giao tiếp cho| REQ
    DATA -->|truy vết tới| AC
    DATA -->|truy vết tới| TC

    AC -->|được kiểm tra bởi| TC

Applied

Trường	Nội dung
Facts	Ghi chú phỏng vấn mô phỏng nêu nhân viên kho cần nhận biết lô hàng khi lập phiếu nhập.
Current Behavior	Chưa có requirement, rule, trường dữ liệu, API hay test case được xác nhận trong micro-batch này.
Underlying Need	Cần truy vết đầy đủ từ nhu cầu nhận biết lô đến kiểm thử; bằng chứng là thao tác kho phụ thuộc mã lô nhưng không thể kiểm thử nếu thiếu dữ liệu và AC.
Options	Liên kết bằng bảng văn bản tự do; hoặc dùng ID canonical qua registry.
Decision Criteria	Không trùng nguồn chân lý; liên kết kiểm tra được; ID ổn định; không diễn giải thành cấu hình ERP thật.
Decision	Dùng ID do /01-curriculum/TRACEABILITY_ID_REGISTRY.md cấp; nội dung rule tham chiếu /01-curriculum/CANONICAL_BUSINESS_RULES.md; trường dữ liệu tham chiếu /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
Authority	Principal IT Business Analyst / Technical Curriculum Author quản trị traceability; Business Owner, QA, Architect và owner chuyên môn xác nhận phần thuộc thẩm quyền. Không có phê duyệt được ghi nhận.
Artifact	/02-handbook/03-discovery-interviewing-and-note-taking.md, Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh.
Consequence if Wrong	TC có thể kiểm tra nhầm requirement; dữ liệu lô có thể bị gọi bằng tên khác; team tưởng rule đã được xác nhận dù nguồn canonical chưa nói vậy.

Senior Lens

Bảng traceability không phải nơi viết lại requirement hay business rule. Nó là chỉ mục liên kết. Cột liên kết phải chứa ID canonical, còn diễn giải đầy đủ ở artifact chủ sở hữu. Lý do: một rule đổi tại nhiều bản sao sẽ tạo mâu thuẫn; một rule đổi tại một nguồn canonical giữ lịch sử và phạm vi thay đổi rõ.

Khi chưa có ID được đăng ký, ghi nhận thiếu liên kết như vấn đề quản trị trong artifact phù hợp; không tự đặt ID có vẻ hợp lệ. IN_REVIEW chỉ nói artifact đang xem xét. Nó không chứng minh NEED, REQ, BR, AC, DATA/API hay TC đã được baseline hoặc phê duyệt.

Quick Reference

Kiểm tra	Đạt khi
NEED tới REQ	Requirement trả lời đúng nhu cầu nào
REQ tới BR	Rule áp dụng được tham chiếu, không chép lại
REQ tới AC	Mỗi yêu cầu có kết quả chấp nhận kiểm tra được
AC tới TC	Mỗi tiêu chí có ca kiểm thử tương ứng
DATA/API tới REQ hoặc AC	Tên dữ liệu, field, endpoint dùng nguồn canonical
ID và nguồn	ID lấy từ TRACEABILITY_ID_REGISTRY; rule và dữ liệu giữ đúng artifact canonical

Core

Phụ thuộc là quan hệ: artifact sau dùng ý nghĩa, ID, cấu trúc dữ liệu, quy tắc, hoặc quyết định từ artifact trước. Thay đổi phải lan truyền khi đầu vào đổi. Ví dụ, CANONICAL_DATA_DICTIONARY đổi nghĩa trường “Mã lô” thì requirement, API, tiêu chí chấp nhận và test dùng trường này phải được rà soát. Lý do: cùng tên trường nhưng nghĩa khác tạo lỗi dù hệ thống vẫn chạy.

Thay đổi im lặng là sửa artifact canonical nhưng không ghi version, lịch sử thay đổi, phạm vi ảnh hưởng và người cần xem xét. Nó phá nguồn chân lý: tài liệu phỏng vấn còn hiểu cũ, đặc tả hiểu mới, QA kiểm thử theo hiểu khác. IN_REVIEW tại v0.9.0 không là baseline hay approval; không được coi thay đổi là đã được chấp thuận.

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

flowchart TB
    A[Artifact canonical đổi] --> B[Ghi version và lịch sử thay đổi]
    B --> C[Phân tích phạm vi ảnh hưởng, artifact phụ thuộc và người cần xem xét]
    C --> D[Cập nhật requirement, API, tiêu chí chấp nhận và test bị ảnh hưởng]
    D --> E[Review theo thẩm quyền]
    E --> Q{Đã là baseline hoặc được chấp thuận?}
    Q -->|Có| F[Kiểm tra liên kết với ID, cấu trúc dữ liệu, quy tắc và nguồn chân lý]
    Q -->|Không: IN_REVIEW v0.9.0| R[Hoàn thiện artifact và review lại]
    R --> E
    A -. Không ghi version, lịch sử, phạm vi ảnh hưởng hoặc người cần xem xét .-> G[Hiểu lệch giữa artifact]
    G --> H[Build, test hoặc vận hành sai]

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. Một ghi chú phỏng vấn tham chiếu trường “Mã lô” từ /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Catalog này đổi định nghĩa từ “mã lô nhà cung cấp” sang “mã lô nội bộ”. Bằng chứng ảnh hưởng: hai giá trị có nguồn tạo khác nhau; không thể thay thế bằng đổi nhãn hiển thị.

Current Behavior: Requirement, API contract và test case vẫn diễn giải “Mã lô” là mã do nhà cung cấp cấp. Giao diện có thể nhận chuỗi hợp lệ, nhưng truy xuất nguồn gốc mô phỏng nối sang sai thực thể.

Underlying Need: Giữ cùng một nghĩa dữ liệu xuyên suốt discovery, requirement, thiết kế, tích hợp và kiểm thử. Nhu cầu này không tạo quy tắc vận hành Nova Foods thật.

Hạng mục đổi	Artifact nguồn	Phụ thuộc có thể vỡ nếu không lan truyền	Hậu quả
Nghĩa nghiệp vụ của trường	CANONICAL_DATA_DICTIONARY	Ghi chú phỏng vấn, requirement, AC, API mapping, TC	Sai nguồn dữ liệu
Tên hoặc format trường	CANONICAL_DATA_DICTIONARY	Payload API, validation, dữ liệu test	Lỗi tích hợp hoặc test giả xanh
Quy tắc áp dụng	CANONICAL_BUSINESS_RULES	REQ, AC, TC	Hệ thống xử lý khác ý định
ID hoặc quan hệ traceability	TRACEABILITY_ID_REGISTRY	Liên kết NEED, REQ, BR, AC, DATA/API, TC	Không chứng minh được nguồn và phạm vi đổi

Options: Giữ nghĩa cũ trong artifact phụ thuộc; đổi toàn bộ sang nghĩa mới; hoặc dừng liên kết đang mơ hồ để xác minh owner dữ liệu. Giữ nghĩa cũ chỉ hợp lệ nếu catalog canonical ghi rõ hai trường riêng biệt. Đổi toàn bộ chỉ hợp lệ sau khi phạm vi ảnh hưởng được ghi nhận. Dừng là lựa chọn đúng khi nguồn canonical mâu thuẫn hoặc thẩm quyền chưa rõ.

Decision Criteria: Ưu tiên nghĩa trong artifact canonical, version đang kiểm soát, bằng chứng nguồn tạo dữ liệu, và thẩm quyền Data Owner hoặc Business Owner. Không chọn theo tên quen thuộc, ghi chú cũ, hoặc suy đoán của BA.

Decision: Ghi nhận thay đổi, rà soát mọi artifact tham chiếu “Mã lô”, rồi cập nhật hoặc đánh dấu cần xác minh. Không tự tạo field thay thế, không sửa im lặng, không gọi nội dung là approved.

Authority: Principal IT Business Analyst / Technical Curriculum Author giữ traceability và lịch sử artifact. Data Owner hoặc Business Owner xác nhận nghĩa nghiệp vụ. Architect xác nhận tác động API. QA xác nhận test basis. Đây là phân vai mô phỏng, không là thẩm quyền vận hành thật.

Artifact: /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, CANONICAL_BUSINESS_RULES, cùng các artifact phụ thuộc đang IN_REVIEW, v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh.

Consequence if Wrong: API gửi mã nhà cung cấp vào trường chờ mã nội bộ; test vẫn pass nếu fixture dùng cùng chuỗi; báo cáo truy xuất lô mô phỏng trả quan hệ sai. Lỗi nguy hiểm vì cú pháp, HTTP status và màn hình có thể đều hợp lệ.

Senior Lens

Không sửa bản sao để “khớp nhanh” với artifact mới. Bản sao không là nguồn chân lý. Ghi rõ: cái gì đổi, từ nghĩa nào sang nghĩa nào, artifact nào bị ảnh hưởng, liên kết nào cần kiểm tra, ai có thẩm quyền review, và trạng thái xác minh. Nếu không xác định được phạm vi, giữ nhãn Verification required và dừng quyết định phụ thuộc.

Phân biệt đổi trình bày với đổi ngữ nghĩa. Sửa chính tả không đổi nghĩa thường chỉ cần kiểm tra liên kết hiển thị. Đổi định nghĩa, tập giá trị, nguồn dữ liệu, quy tắc tính, quyền truy cập, hoặc API field là đổi ngữ nghĩa; phải phân tích tác động xuyên chuỗi. Sự im lặng làm mất bằng chứng, không làm giảm tác động.

Quick Reference

Tín hiệu	Hành động tối thiểu
Canonical artifact đổi nghĩa	Rà soát mọi tham chiếu và test basis
ID đổi hoặc bị thay thế	Kiểm tra liên kết traceability, không tái dùng ID sai nghĩa
API field đổi tên hoặc format	Kiểm tra contract, mapping, validation, dữ liệu test
Quy tắc đổi	Kiểm tra REQ, AC và TC liên quan
Không rõ owner hoặc nguồn mâu thuẫn	Gắn Verification required, escalation, không suy diễn
Thay đổi không có lịch sử	Xem là rủi ro quản trị; không coi bản sao là đúng

10. Common Mistakes & Anti-patterns

Core

Sai lầm khi phỏng vấn và ghi chép không chỉ là “ghi thiếu”. Nó làm sai chuỗi bằng chứng từ phát biểu, nhu cầu, yêu cầu, tiêu chí chấp nhận đến kiểm thử. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi ví dụ và dữ liệu dưới đây là tổng hợp.

Nhóm lỗi	Sai lầm cụ thể	Dấu hiệu quan sát được	Nguyên nhân gốc	Hành động sửa
Mơ hồ	Ghi “hệ thống xử lý nhanh”	Không có người dùng, thời điểm, khối lượng, điều kiện đo	BA không hỏi tiếp từ tính từ chung chung sang điều kiện kiểm chứng	Hỏi: ai thao tác, trong bước nào, dữ liệu nào, thời gian bao lâu, ngoại lệ nào
Không đầy đủ	Chỉ ghi luồng thành công	Không có lỗi nhập liệu, hủy, sửa, thiếu quyền, mất kết nối	Nhóm vội chốt giải pháp trước khi khám phá ngoại lệ	Rà soát happy path và alternate/exception flow riêng
Suy diễn thẩm quyền	Ghi “Kế toán đã chấp thuận” khi người nói chỉ là nhân viên nhập liệu	Ghi chú không có tên vai trò, nguồn quyết định, hoặc bằng chứng	Nhầm người cung cấp thông tin với người có quyền quyết định	Đổi thành “Nhân viên Kế toán báo cáo”; xác định Accounting Owner cần xác minh
Dùng sai ký pháp	Gọi sơ đồ hoạt động PlantUML là BPMN	Sơ đồ không dùng đúng phần tử BPMN nhưng tài liệu tuyên bố là BPMN	Chọn công cụ trước khi xác định chuẩn cần dùng	Gọi đúng tên sơ đồ; dùng BPMN 2.0.2 khi cần BPMN chuẩn
Đứt truy vết	Requirement tách khỏi ghi chú nguồn	Không truy được requirement xuất phát từ cuộc trao đổi, artifact hay rule nào	Ghi chép tự do, không gắn định danh nguồn	Liên kết requirement với note, nguồn, giả định, quyết định và trạng thái xác minh
Trộn fact với diễn giải	Ghi “cần chặn xuất kho” nhưng không biết đây là câu nói hay kết luận BA	Không có nhãn Facts hay Underlying Need	Ghi biên bản theo trí nhớ sau cuộc họp	Tách nguyên ý quan sát được, diễn giải BA và câu hỏi mở
Chốt giải pháp quá sớm	Ghi “thêm nút duyệt” ngay khi nghe vấn đề	Không có lựa chọn khác hoặc tiêu chí chọn	Nhóm lấy giao diện làm requirement	Ghi nhu cầu trước; chỉ so sánh giải pháp sau khi rõ ràng ràng buộc
Ghi dữ liệu nhạy cảm không cần thiết	Chép số điện thoại, tài khoản, dữ liệu cá nhân vào note học liệu	Note có dữ liệu định danh không phục vụ phân tích	Không phân loại dữ liệu tại điểm ghi nhận	Dùng dữ liệu tổng hợp; bỏ dữ liệu không cần; escalation khi cần xử lý dữ liệu thật

Cảnh báo: Không biến phát biểu của một người tham gia thành quyết định nghiệp vụ, pháp lý, kế toán hoặc vận hành. Trong Nova Foods mô phỏng, câu “phải giữ chứng từ 10 năm” không đủ để thành rule. Cần ghi nguồn phát biểu, xác định Legal Owner hoặc Accounting Owner phù hợp, và gắn Verification required. Không tự diễn giải luật từ ghi chú phỏng vấn.

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

flowchart TB
    A[Phát biểu trong phỏng vấn] --> B[Ghi Facts: ai nói, bối cảnh, thời điểm, nguồn]
    B --> C[BA phân tích: Current Behavior và Underlying Need]
    C --> D[Đánh dấu Underlying Need là diễn giải BA]
    D --> E{Cần bổ sung nguồn hoặc bằng chứng?}

    E -- Có --> F[Question log: thiếu thông tin hoặc cần xác minh]
    F --> G[Xác định owner phù hợp khi cần: Legal Owner hoặc Accounting Owner]
    G --> H[Thu thập hoặc bổ sung bằng chứng]
    H --> I{Kết quả xác minh}

    E -- Không --> I

    I -- Đã xác minh --> J[Requirement candidate]
    I -- Owner xác nhận quyết định --> K[Decision candidate]
    I -- Chưa xác minh --> L[Giữ mở: Verification required]
    I -- Bị bác bỏ --> M[Không chuyển thành requirement hoặc rule]

    L -. Tái xác minh khi có bằng chứng mới .-> F

    J --> O[Liên kết truy vết: note, nguồn, artifact, giả định, trạng thái xác minh]
    K --> O
    L --> O
    M --> O

Applied

Facts: Trong buổi trao đổi mô phỏng về xuất kho, Nhân viên Kho nói: “Đơn gấp thì quản lý cho xuất trước, chứng từ bổ sung sau.” Note ban đầu ghi: “ERP cho phép xuất kho không cần chứng từ.”

Current Behavior: Người dùng mô tả một ngoại lệ vận hành do quản lý xử lý. Phát biểu không nêu loại chứng từ, điều kiện “đơn gấp”, giới hạn thời gian bổ sung, quyền của người phê duyệt, hay cách ghi nhận trên ERP.

Underlying Need: Kho cần xử lý đơn khẩn mà vẫn truy được ai cho phép, lô nào được xuất và chứng từ nào còn thiếu. Cầu nối suy luận: “xuất trước” cho thấy cần giảm chậm trễ; “quản lý cho xuất” cho thấy có kiểm soát thẩm quyền; “bổ sung sau” cho thấy có trạng thái thiếu chứng từ cần theo dõi.

Options: (1) Cho mọi người xuất kho không kiểm tra chứng từ. (2) Chặn mọi xuất kho đến khi đủ chứng từ. (3) Tạo ngoại lệ xuất kho có người có thẩm quyền, lý do và trạng thái theo dõi chứng từ còn thiếu.

Decision Criteria: Khả năng phục vụ đơn khẩn; truy vết lô mô phỏng; phân quyền; khả năng kiểm thử; nhu cầu xác minh với owner có thẩm quyền.

Decision: Không chọn option nào như quyết định Nova Foods. Ghi option 3 là phương án cần xác minh vì giữ cả tốc độ vận hành và dấu vết kiểm soát, nhưng chưa có bằng chứng đủ để xác định rule.

Authority: Business Owner xác nhận ưu tiên vận hành; Warehouse Manager xác nhận quy trình kho; Accounting Owner và Legal Owner xác minh yêu cầu chứng từ. BA chỉ ghi nhận, phân tích và bảo toàn truy vết.

Artifact: Biên bản phỏng vấn tách Facts, Underlying Need, Open Questions, Options và Verification required; liên kết tới /01-curriculum/CANONICAL_BUSINESS_RULES.md nếu rule được đăng ký sau review.

Consequence if Wrong: Nếu ghi thẳng “cho phép xuất kho không cần chứng từ”, đội phát triển có thể mở quyền rộng. Test chỉ xác nhận thao tác xuất thành công, nhưng không phát hiện thiếu người phê duyệt, thiếu lý do và thiếu dấu vết chứng từ.

Senior Lens

Dấu hiệu đỏ mạnh nhất là note nghe có vẻ hoàn chỉnh nhưng không trả lời được: ai nói, họ biết bằng cách nào, đây là hiện trạng hay mong muốn, ai có quyền quyết định, và điều gì chứng minh yêu cầu có thể kiểm thử. Một câu không có các điểm này chưa là requirement; nó là dữ liệu khám phá.

Sửa an toàn theo ranh giới nhỏ nhất. Không xóa phát biểu gốc để làm note “sạch”. Giữ Facts, thêm câu hỏi làm rõ, ghi người cần xác minh, rồi chặn các quyết định phụ thuộc. Không nâng IN_REVIEW thành approved, baselined, compliant hoặc production-ready.

Quick Reference

Khi thấy	Làm ngay
Từ “nhanh”, “đủ”, “linh hoạt”, “đơn gấp”	Hỏi điều kiện, ngưỡng, người dùng, ngoại lệ
Một người nói “ban lãnh đạo yêu cầu”	Ghi đây là claim; xác định owner và bằng chứng
Note chỉ có giải pháp giao diện	Quay lại Current Behavior và Underlying Need
Sơ đồ bị gọi sai chuẩn	Đổi nhãn hoặc vẽ lại theo chuẩn phù hợp
Requirement không có nguồn	Dừng chuyển giao; khôi phục liên kết traceability
Yêu cầu liên quan luật, thuế, kế toán, dữ liệu cá nhân	Gắn Verification required; escalation đúng owner

Core

[!WARNING] Cảnh báo chỉ dùng khi sai sót có thể gây mất dữ liệu, sai quyết định có thẩm quyền, phát hành yêu cầu không kiểm thử được, hoặc tạo rủi ro an toàn thực phẩm, tài chính, bảo mật. Cảnh báo không thay cho ghi chú “cần làm rõ”.

Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Khi ghi nhận phỏng vấn, BA phải tách rủi ro thực khỏi chi tiết chưa hoàn chỉnh. Ví dụ, câu “cần xác nhận đơn vị tính” là điểm mở; chưa đủ căn cứ để đặt cảnh báo. Ngược lại, câu “cho phép xuất kho khi lô hàng chưa có kết quả kiểm tra chất lượng” là rủi ro thực vì có thể làm sai truy vết lô và quyết định xuất hàng.

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

flowchart TB
    A[BA ghi chú phỏng vấn] --> B{Có bằng chứng hậu quả nghiêm trọng nếu hiểu sai?}
    B -->|Không| C[Ghi điểm cần làm rõ trong artifact]
    B -->|Có| D[Đặt WARNING kèm bằng chứng]
    D --> E[Xác định authority có thẩm quyền]
    E --> F[Khóa quyết định bị ảnh hưởng khỏi yêu cầu triển khai]
    F --> G[Authority xác minh hoặc ra quyết định thuộc thẩm quyền]
    G --> H[Cập nhật quyết định hoặc yêu cầu]
    C --> I[Cập nhật ghi chú và traceability]
    H --> I

Applied

Trường	Nội dung case Nova Foods mô phỏng
Facts	Ghi chú ngày 2026-08-07 nói: “Kho vẫn xuất hàng khi QC chưa trả kết quả nếu khách cần gấp.” Không có tên người quyết định, điều kiện ngoại lệ, bằng chứng quy trình hoặc rule ID.
Current Behavior	BA mới ghi thành yêu cầu: “ERP cho phép xuất hàng khẩn cấp không cần QC.”
Underlying Need	Cần phân biệt nhu cầu đáp ứng đơn gấp với quyền bỏ qua kiểm soát chất lượng. Bằng chứng: câu ghi chú chỉ mô tả hành vi được kể lại, không xác nhận policy hay thẩm quyền.
Options	1. Giữ yêu cầu cho phép bỏ QC. 2. Ghi là giả định. 3. Đặt cảnh báo, chặn quyết định thiết kế và yêu cầu xác minh bởi Business Owner cùng Quality Owner.
Decision Criteria	Chọn phương án chỉ khi có nguồn quy trình được kiểm soát, authority phù hợp, điều kiện áp dụng và hậu quả truy vết được xác định.
Decision	Chọn phương án 3. Không tạo rule ERP từ ghi chú này.
Authority	Business Owner và Quality Owner xác nhận vận hành; Legal Owner xác minh nếu diễn giải liên quan nghĩa vụ pháp lý. BA chỉ ghi nhận và truy vết.
Artifact	Ghi trong /02-handbook/03-discovery-interviewing-and-note-taking.md như rủi ro phỏng vấn; liên kết quản trị đến CANONICAL_BUSINESS_RULES chỉ sau khi có rule được ghi nhận đúng thẩm quyền.
Consequence if Wrong	Nếu cấu hình cho xuất kho không kiểm tra, ERP có thể mất chốt kiểm soát lô. Không được kết luận đây là vi phạm pháp luật; cần xác minh theo nguồn chính thức và owner có thẩm quyền.

[!WARNING] Không dùng câu “đã được quản lý xác nhận”, “đã phê duyệt”, “đúng quy định” khi artifact không có bằng chứng authority và approval reference. IN_REVIEW tại v0.9.0 ngày 2026-08-07 không phải APPROVED hay BASELINED.

Ranh giới phục hồi an toàn: dừng việc chuyển ghi chú rủi ro thành requirement, configuration hoặc test pass criterion; giữ nguyên câu gốc, người cung cấp thông tin nếu đã ghi nhận, thời điểm Asia/Ho_Chi_Minh, và trạng thái “Verification required”. Không sửa im lặng để biến phát biểu chưa xác minh thành quyết định.

Senior Lens

Cảnh báo tốt phải trả lời đủ bốn điểm: nguy cơ gì, bằng chứng nào kích hoạt cảnh báo, ai có quyền quyết định, và việc nào bị chặn cho đến khi xác minh. Nếu thiếu một điểm, cảnh báo dễ thành cảm tính hoặc bị dùng để ép quyết định.

Không gắn cảnh báo vào mọi điểm thiếu dữ liệu. Lạm dụng cảnh báo làm đội delivery bỏ qua cảnh báo thật. Quy tắc thực dụng: dùng ghi chú mở cho câu hỏi có thể đóng bằng dữ liệu; dùng cảnh báo khi câu trả lời sai có thể thay đổi quyền, kiểm soát, tiền, dữ liệu, an toàn hoặc khả năng truy vết.

Quick Reference

Tình huống	Có dùng WARNING?	Hành động an toàn
Chưa biết màn hình hiển thị ngày theo vi-VN	Không	Ghi câu hỏi làm rõ.
Chưa xác định ai được sửa giá sau khi đơn đã xác nhận	Có	Chặn rule và cấu hình; xác minh Business Owner.
Ghi chú nói “kế toán đã đồng ý” nhưng không có authority hay artifact	Có	Không tuyên bố approval; yêu cầu bằng chứng Accounting Owner.
Nghi ngờ bỏ kiểm tra QC để giao hàng gấp	Có	Không cấu hình ngoại lệ; xác minh Quality Owner và truy vết quyết định.
Thiếu ví dụ dữ liệu VND trong buổi phỏng vấn	Không	Bổ sung dữ liệu tổng hợp trong lần làm rõ kế tiếp.

Core

Năm lỗi khác loại. Tách đúng loại trước khi sửa, vì mỗi loại cần bằng chứng và người quyết định khác nhau. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi ví dụ dưới đây dùng dữ liệu tổng hợp.

Loại lỗi	Dấu hiệu quan sát được	Ví dụ Nova Foods mô phỏng	Nguyên nhân gốc	Hành động sửa
Mơ hồ (ambiguity)	Một câu có từ “nhanh”, “đủ”, “tự động”, “kịp thời” nhưng không có ngưỡng	“ERP cảnh báo tồn kho thấp kịp thời.”	Người ghi chép giữ nguyên ngôn ngữ hội thoại, chưa hỏi điều kiện đo được	Hỏi ngưỡng, thời điểm, đối tượng nhận, kênh và ngoại lệ. Ghi câu chưa rõ là câu hỏi mở, không tự đổi thành rule.
Thiếu thông tin (incompleteness)	Có luồng chính nhưng thiếu điều kiện đầu vào, ngoại lệ, dữ liệu, đầu ra hoặc owner	Có bước “tạo phiếu điều chuyển” nhưng không nêu kho nguồn, kho đích, quyền tạo, trạng thái lỗi	Phỏng vấn chỉ bám happy path, tức luồng thành công thông thường	Lập danh sách phần bắt buộc: trigger, input, rule, exception, output, owner, bằng chứng. Phỏng vấn bổ sung đúng khoảng trống.
Khẳng định thẩm quyền không có bằng chứng	Ghi “Finance đã chốt”, “pháp luật bắt buộc”, “Business Owner phê duyệt” nhưng không có nguồn hoặc quyết định được ghi nhận	Note ghi “hóa đơn phải khóa sửa sau 24 giờ theo luật”	BA suy diễn từ trao đổi, nhầm ý kiến cá nhân thành quyết định	Đổi nhãn thành Project assumption hoặc Verification required; dẫn URL nguồn chính thức nếu có; chuyển Legal Owner hoặc Accounting Owner xác minh.
Dùng sai ký pháp (notation misuse)	Gọi sơ đồ PlantUML là BPMN, dùng hình thoi làm “người thực hiện”, dùng mũi tên không rõ điều kiện	Activity diagram ghi nhãn “BPMN kho lạnh”	Chọn công cụ vẽ trước khi chọn ngôn ngữ mô hình	Ghi đúng loại sơ đồ. Dùng BPMN 2.0.2 khi cần BPMN; gọi PlantUML activity diagram đúng tên khi dùng PlantUML.
Đứt truy vết (traceability break)	Requirement, note, rule, data field hoặc test không liên kết nguồn canonical	REQ-INV-014 tham chiếu “file note cuối” thay vì artifact kiểm soát	Sao chép giữa tệp, đổi tên tự do, không kiểm tra ID	Giữ nguyên ID canonical; liên kết tới /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md hoặc /01-curriculum/CANONICAL_DATA_DICTIONARY.md khi phù hợp. Không tạo ID thay thế.

Mơ hồ khác thiếu thông tin. “Cảnh báo sớm” là mơ hồ vì có nội dung nhưng nhiều cách hiểu. “Không nêu ai nhận cảnh báo” là thiếu thông tin vì thiếu thành phần bắt buộc. Cả hai chưa phải business rule. Business rule chỉ được ghi khi câu có điều kiện, hành vi, dữ liệu liên quan, ngoại lệ và nguồn hoặc thẩm quyền xác minh phù hợp.

[!WARNING] Không biến câu nói trong phỏng vấn thành quyết định pháp lý, kế toán, an toàn thực phẩm, bảo mật hoặc vận hành. Nguồn seed chỉ xác nhận tồn tại và phạm vi nguồn; không tự cung cấp diễn giải clause. Với yêu cầu liên quan Luật Bảo vệ dữ liệu cá nhân, Luật Kế toán, hóa đơn hoặc truy xuất thực phẩm, ghi Verification required cho đến khi owner có thẩm quyền xác minh.

Applied

Trường	Nội dung
Facts	Ngày 2026-08-07, note phỏng vấn mô phỏng ghi: “Kho Bình Dương cần cảnh báo sớm khi nguyên liệu sắp hết; quản lý kho đã đồng ý.”
Current Behavior	Câu không nêu mã kho, mặt hàng, mức tồn, thời điểm chạy kiểm tra, người nhận hoặc bằng chứng đồng ý.
Underlying Need	Nhóm cần biết khi nào ERP phải tạo cảnh báo để tránh thiếu nguyên liệu cho lệnh sản xuất mô phỏng. Đây là suy luận có căn cứ từ cụm “nguyên liệu sắp hết”; chưa đủ căn cứ để xác định ngưỡng hay người quyết định.
Options	1. Ghi ngay rule “cảnh báo khi tồn dưới 10%”. 2. Giữ nguyên như requirement đã xác nhận. 3. Ghi là phát hiện mơ hồ và lập câu hỏi làm rõ.
Decision Criteria	Không tự tạo ngưỡng; không gán approval không có bằng chứng; giữ được liên kết tới note; câu sau làm rõ phải kiểm thử được.
Decision	Chọn 3. Ghi note nguồn là phát biểu phỏng vấn mô phỏng; trạng thái nội dung Verification required. Câu hỏi: “Mỗi mã nguyên liệu dùng ngưỡng tồn nào, đơn vị tính nào, lịch kiểm tra nào, ai nhận cảnh báo, ai có quyền đổi ngưỡng?”
Authority	Business Owner xác nhận nhu cầu vận hành; Warehouse Manager cung cấp thực tế kho; Architect xác nhận cơ chế cảnh báo; không vai trò nào trong note tự tạo approval đã ghi nhận.
Artifact	Giữ liên kết artifact nguồn theo /01-curriculum/TRACEABILITY_ID_REGISTRY.md; rule chỉ được liên kết tới CANONICAL_BUSINESS_RULES sau khi có nội dung và thẩm quyền xác minh.
Consequence if Wrong	Ngưỡng tự bịa có thể tạo quá nhiều cảnh báo hoặc bỏ sót thiếu hàng. Ghi “đã đồng ý” sai làm đội triển khai tưởng có approval, rồi cấu hình ERP mô phỏng theo quyết định không tồn tại.

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

flowchart TB
    A["Note phỏng vấn mô phỏng<br/>Giữ nguyên nguồn và liên kết ID nguồn"] --> B{"Rule đủ kiểm thử?<br/>Có mã kho, mã nguyên liệu, ngưỡng tồn, đơn vị tính,<br/>lịch kiểm tra, người nhận, quyền đổi ngưỡng và ngoại lệ?"}

    B -- "Không" --> C["Gắn mơ hồ hoặc thiếu thông tin"]
    C --> Q["Lập câu hỏi làm rõ:<br/>mã kho, mã nguyên liệu, ngưỡng, đơn vị tính,<br/>lịch kiểm tra, người nhận, ngoại lệ,<br/>ai có quyền quyết định hoặc đổi ngưỡng?"]
    Q --> R["Giữ trạng thái Verification required"]
    R --> N["Không cấu hình hoặc kiểm thử như rule đã xác nhận"]
    N --> W{"Nếu vẫn dùng như rule đã xác nhận"}
    W --> W1["Cảnh báo quá mức"]
    W --> W2["Bỏ sót thiếu hàng"]
    W --> W3["Cấu hình ERP theo approval không tồn tại"]

    B -- "Có" --> V["Xác minh độc lập theo từng phạm vi<br/>Không phải chuỗi phê duyệt"]

    V --> BO["Business Owner<br/>xác minh nhu cầu vận hành"]
    V --> WM["Warehouse Manager<br/>xác minh thực tế kho"]
    V --> AR["Architect<br/>xác minh cơ chế cảnh báo"]
    V --> AU["Xác minh chủ thể có quyền<br/>quyết định hoặc đổi ngưỡng"]

    BO --> S["Tổng hợp bằng chứng theo từng phạm vi"]
    WM --> S
    AR --> S
    AU --> S

    S --> X{"Nội dung từng phạm vi đã được xác minh<br/>và có bằng chứng thẩm quyền phù hợp?"}
    X -- "Không" --> R
    X -- "Có" --> J["Liên kết rule tới CANONICAL_BUSINESS_RULES"]
    J --> K["Ghi đúng trạng thái hiện tại của artifact"]
    K --> L{"Trạng thái là IN_REVIEW?"}
    L -- "Có" --> M["Tiếp tục xác minh<br/>Không gọi approved hoặc baselined"]
    M --> S
    L -- "Không" --> P["Chỉ dùng trạng thái có bằng chứng tương ứng"]

Biên phục hồi an toàn: được sửa wording, thêm câu hỏi, gắn nhãn Project assumption hoặc Verification required, và khôi phục liên kết ID. Không được sửa ngược note để làm nó giống quyết định; không được xóa nguồn trái ý; không được gọi IN_REVIEW là approved hay baselined.

Senior Lens

Senior BA kiểm tra “bằng chứng nói gì” trước “hệ thống nên làm gì”. Ví dụ, sơ đồ có swimlane “Kế toán” chỉ cho biết trách nhiệm được mô hình hóa; nó không chứng minh Accounting Owner đã quyết định rule. Tương tự, một URL luật chính thức chứng minh nguồn tồn tại, không chứng minh diễn giải nghiệp vụ cụ thể nếu chưa kiểm tra văn bản hiện hành và owner có thẩm quyền.

Ký pháp là hợp đồng đọc hiểu. BPMN 2.0.2 là nguồn chuẩn cho BPMN. PlantUML activity diagram có thể diễn tả luồng học liệu, nhưng không được gắn nhãn BPMN. Khi sơ đồ chỉ mô tả luồng trao đổi, tên đúng là “activity diagram”; khi cần mô hình BPMN, dùng công cụ và phần tử BPMN tương ứng. Sai nhãn làm reviewer áp sai quy tắc và phá bằng chứng mô hình.

Traceability không phải danh sách link đẹp. Nó trả lời được: nội dung này đến từ đâu, ai phải xác minh, nó ảnh hưởng rule nào, dữ liệu nào, acceptance criteria nào và test basis nào. Nếu một thay đổi không lần được về artifact kiểm soát, dừng sử dụng nội dung đó cho quyết định delivery.

Quick Reference

Kiểm tra trước khi ghi nhận	Đạt khi	Không đạt thì
Câu có thể kiểm thử?	Có điều kiện, kết quả, dữ liệu và ngoại lệ đủ rõ	Gắn mơ hồ hoặc thiếu thông tin
Ai có quyền quyết?	Vai trò và bằng chứng được ghi nhận, không suy diễn	Gắn Verification required, escalation đúng owner
Sơ đồ là gì?	Tên sơ đồ khớp ký pháp dùng	Đổi nhãn hoặc vẽ lại
ID có canonical không?	ID và đường dẫn giữ nguyên registry/artifact nguồn	Không tạo ID tự phát; khôi phục liên kết
Trạng thái có bị nói quá không?	IN_REVIEW vẫn là đang review	Xóa từ “approved”, “baselined”, “đã chốt” nếu thiếu bằng chứng

11. Senior BA Notes & Rules of Thumb

Senior Lens

Senior BA không chọn ý kiến nhiều người nhất. Senior BA chọn phương án có bằng chứng đủ mạnh, đúng thẩm quyền và làm rõ hậu quả. Trong Nova Foods Trading & Manufacturing mô phỏng, mọi ví dụ là dữ liệu tổng hợp; IN_REVIEW, v0.9.0, ngày 2026-08-07 không chứng minh approval, baseline hay quyết định vận hành.

Tình huống	Đánh đổi	Bằng chứng cần xem	Thẩm quyền quyết định	Cách ghi nhận
Kho vận muốn cho sửa số lượng sau khi xuất kho; Kế toán muốn khóa	Linh hoạt sửa lỗi đối nghịch khả năng đối soát	Log lỗi, mẫu giao dịch, thời điểm ghi sổ, ảnh hưởng tồn kho mô phỏng	Business Owner quyết nhu cầu; Accounting Owner xác minh ảnh hưởng kế toán	Ghi hai nhu cầu, giả định, phương án khóa hoặc điều chỉnh bù trừ; không tự gọi phương án là compliant
Sales muốn xem dữ liệu khách hàng rộng hơn; Security phản đối	Tốc độ phục vụ đối nghịch nguyên tắc giới hạn truy cập	Ma trận vai trò, loại dữ liệu, luồng truy cập, rủi ro lộ dữ liệu	Security Owner quyết kiểm soát; Business Owner quyết mức cần dùng	Gắn Verification required cho diễn giải nghĩa vụ pháp lý; liên kết nguồn chính thức, không suy diễn luật thành rule ERP
Nhà máy nói “luôn cần” truy xuất lô; IT nói dữ liệu nguồn chưa có	Giá trị truy xuất đối nghịch chi phí và chất lượng dữ liệu	Mẫu phiếu nhập, mã lô hiện có, tỷ lệ thiếu mã, luồng recall mô phỏng	Food-safety/domain owner xác minh nhu cầu; Architect đánh giá khả thi	Tách fact, inference và assumption; nêu dữ liệu thiếu trước khi viết requirement

Chất lượng bằng chứng có cấp bậc. Bản ghi hệ thống có thời điểm, tài liệu chính thức đang hiệu lực và quan sát lặp lại mạnh hơn ký ức của một người trong một cuộc họp. Tuy vậy, bằng chứng mạnh không thay quyền quyết định. Log ERP có thể cho thấy 37 giao dịch tổng hợp bị sửa sau xuất kho; log không quyết định được có nên cấm sửa hay không. Cầu nối suy luận phải ghi rõ: “37 giao dịch bị sửa” là fact; “cần kiểm soát điều chỉnh” là inference vì sửa trực tiếp làm giảm khả năng đối soát; loại kiểm soát là quyết định chờ owner đúng thẩm quyền.

Ngoại lệ không phải lỗi cần xóa. Quy tắc “ghi requirement theo điều kiện và kết quả” không áp dụng nguyên xi khi điều kiện chưa được xác minh, nguồn mâu thuẫn hoặc quyết định thuộc Legal Owner, Accounting Owner, Security Owner hay Architect. Khi đó, BA ghi câu hỏi quyết định, giới hạn ảnh hưởng và điều kiện xác minh. Không biến khoảng trống thành business rule Nova Foods.

Dấu hiệu đỏ	Ngưỡng escalation	Hành động BA
Một stakeholder dùng “luật bắt buộc” nhưng không có diễn giải được owner xác minh	Escalation ngay	Gắn Verification required; chuyển Legal Owner; giữ URL nguồn chính thức làm tham chiếu, không tạo kết luận pháp lý
Hai owner yêu cầu kết quả đối nghịch trên cùng dữ liệu hoặc cùng trạng thái	Escalation ngay	Lập decision record: xung đột, phương án, tác động, người có quyền quyết
Ý kiến chỉ dựa trên “hệ thống cũ làm vậy”	Không dùng làm rule cho đến khi có bằng chứng bổ sung	Yêu cầu mẫu giao dịch, mục tiêu nghiệp vụ, ngoại lệ và hậu quả
Yêu cầu chạm phân quyền, dữ liệu cá nhân, tích hợp hoặc số liệu kế toán	Escalation trước khi chốt requirement	Xác định Security, Architect hoặc Accounting Owner; BA không thay kết luận chuyên môn
Không xác định được ai chịu hậu quả nếu chọn sai	Dừng khuyến nghị cuối cùng	Làm rõ owner, phạm vi và chi phí sai trước khi ưu tiên phương án

Ngôn ngữ senior phải chính xác về độ chắc chắn. Dùng “bằng chứng hiện có cho thấy”, “khuyến nghị có điều kiện”, “cần xác minh bởi” thay cho “đã chốt”, “chắc chắn đúng” hoặc “được phê duyệt”. Một khuyến nghị phòng thủ được cần ghi: fact có nguồn, inference có lý do, option bị loại có tiêu chí, rủi ro còn lại, authority cần quyết và trạng thái hiện tại. Ví dụ: “Khuyến nghị không cho sửa trực tiếp số lượng sau xuất kho trong phạm vi mô phỏng. Fact: log tổng hợp ghi giao dịch sửa sau xuất kho. Inference: cần bảo toàn dấu vết điều chỉnh để đối soát. Authority: Business Owner và Accounting Owner xác minh. Status: IN_REVIEW; chưa có approval.”

Senior Lens

Senior BA rà từng ghi chú theo ba câu hỏi: có bằng chứng trực tiếp không, bằng chứng còn đúng tại thời điểm quyết định không, và người cung cấp bằng chứng có thẩm quyền cho loại quyết định đó không. Ý kiến một người dùng là tín hiệu khám phá, chưa là quy tắc ERP. Ví dụ, “kho luôn chặn xuất hàng khi thiếu hạn dùng” chỉ thành yêu cầu sau khi đối chiếu quan sát quy trình, mẫu chứng từ tổng hợp, dữ liệu mô phỏng và xác nhận của Process Owner; nếu liên quan an toàn thực phẩm hoặc truy xuất, cần nhãn Verification required và chuyển Domain Owner cùng Legal Owner xem xét.

Heuristic review	Dấu hiệu đủ	Red flag	Ngưỡng escalation	Ngoại lệ không áp dụng quy tắc thường
Tách fact khỏi diễn giải	Fact có nguồn, thời điểm, người cung cấp	Ghi “hệ thống phải” từ một câu kể	Fact ảnh hưởng tiền, tồn kho, dữ liệu cá nhân, an toàn thực phẩm hoặc hóa đơn nhưng chưa có nguồn kiểm chứng	Interview chỉ dùng để lập câu hỏi tiếp, không dùng để chốt rule
Kiểm tra mâu thuẫn	Hai nguồn cùng mô tả một hành vi	Sales nói cho sửa giá sau duyệt, Finance nói cấm	Mâu thuẫn làm thay đổi trạng thái chứng từ, số tiền VND, quyền truy cập hoặc dữ liệu traceability	Không ép đồng thuận trong buổi phỏng vấn; ghi hai phương án và escalte đúng Owner
Kiểm tra thẩm quyền	Decision Owner rõ theo loại quyết định	Người thực hiện tự quyết chính sách, BA tự chọn kiến trúc	Đề xuất chạm legal, accounting, security, architecture hoặc vận hành liên phòng ban	Không dùng chức danh cao hơn làm thay bằng chứng chuyên môn; cần đúng Owner
Kiểm tra phạm vi	Trigger, actor, dữ liệu, ngoại lệ rõ	“Áp dụng cho mọi đơn hàng” không định nghĩa đơn hàng	Ngoại lệ có thể tạo giao dịch không đảo được hoặc mất dữ liệu	Không chuẩn hóa sớm khi quy trình đang thay đổi theo mùa, kênh bán, hoặc pilot
Kiểm tra khả năng kiểm thử	Có điều kiện đầu vào và kết quả quan sát được	“Giao diện thân thiện”, “xử lý nhanh”	Requirement không viết được acceptance criteria hoặc không truy được nguồn	Không ép định lượng khi chưa có dữ liệu đo; ghi giả định, dữ liệu cần thu và Owner xác nhận

Escalation là chuyển vấn đề kèm bằng chứng đến người có quyền quyết định, không phải chuyển trách nhiệm ghi chép. Senior BA escalation ngay khi: hai stakeholder có thẩm quyền ngang nhau đưa quyết định đối nghịch; một rule có thể vi phạm ranh giới pháp lý, kế toán, bảo mật, dữ liệu cá nhân hoặc an toàn thực phẩm; quyết định làm mất khả năng truy vết; hoặc chưa xác định được Owner trước khi thiết kế, build hay test tiếp. Với Nova Foods mô phỏng, mọi chi tiết pháp lý, thuế, kế toán, dữ liệu cá nhân và truy xuất thực phẩm chưa kiểm chứng trực tiếp phải giữ nhãn Verification required, không biến thành nghĩa vụ hệ thống.

Quy tắc “ưu tiên quy trình hiện tại” không áp dụng khi current behavior tồn tại do workaround, lỗi hệ thống, thiếu quyền truy cập, hoặc thực hành không có Owner xác nhận. Quy tắc “đa số quyết định” cũng không áp dụng cho kiểm soát tài chính, bảo mật, pháp lý và an toàn thực phẩm; các lĩnh vực này cần quyết định từ đúng thẩm quyền, không theo biểu quyết. Quy tắc “chốt nhanh để giữ tiến độ” không áp dụng khi hậu quả sai không thể đảo ngược, như phát hành hóa đơn, xóa dữ liệu, thay đổi số dư, hoặc công khai dữ liệu cá nhân.

Mẫu ghi nhận escalation trong note:

Trường	Nội dung mẫu tổng hợp
Issue ID	DISC-ISS-011
Fact đã quan sát	Nhân viên kho mô tả có thể sửa lô sau khi xác nhận xuất; Finance mô tả số lượng xuất phải giữ nguyên sau ghi nhận.
Evidence	Ghi chú phỏng vấn tổng hợp ngày 2026-08-07, Asia/Ho_Chi_Minh; chưa có chứng từ hoặc cấu hình mô phỏng đối chiếu.
Unknown	Chưa xác định trạng thái nào khóa sửa lô và Owner nào quyết định ngoại lệ.
Risk	Sai lô có thể làm đứt traceability và sai tồn kho mô phỏng.
Recommendation	Không đặc tả hành vi sửa lô như rule. Mở decision cần Process Owner, Inventory Owner và Domain Owner xem xét; gắn Verification required.
Decision authority	Process Owner quyết định vận hành; Domain Owner xác nhận ngữ cảnh traceability; Legal Owner xem xét nếu có nghĩa vụ pháp lý áp dụng.
Artifact link	/01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md; TRACEABILITY_ID_REGISTRY
Status	IN_REVIEW, không phải approval hoặc baseline

Senior Lens

Senior BA không biến khoảng trống bằng chứng thành kết luận. Khuyến nghị phải tách rõ: Fact là điều quan sát hoặc tài liệu nguồn xác nhận; Assumption là giả định dự án cần kiểm chứng; Inference là suy luận nối từ Fact đến tác động; Decision required là điểm cần người có thẩm quyền chọn. Cách tách này giúp người đọc kiểm tra từng bước thay vì tin vào uy tín người viết.

Ví dụ Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Trong biên bản phỏng vấn, nhân viên kho nói đơn giao thiếu cần “chờ quản lý duyệt”, nhưng không có ảnh màn hình ERP, quy trình được kiểm soát, log hay quy tắc canonical xác nhận. Senior BA ghi: “Fact: một người được phỏng vấn mô tả có bước chờ quản lý duyệt. Inference: có khả năng tồn tại kiểm soát trước khi hoàn tất giao thiếu. Uncertainty: chưa biết kiểm soát áp dụng cho mọi đơn hay chỉ đơn vượt ngưỡng; chưa xác định vai trò, ngưỡng hoặc cấu hình ERP. Recommendation: chưa viết requirement bắt buộc; lập câu hỏi xác minh với Business Owner và đối chiếu quy trình, cấu hình hoặc log mô phỏng. Decision required: Business Owner xác nhận phạm vi nghiệp vụ; Architect xác nhận khả năng cấu hình nếu có thay đổi hệ thống.” Câu này không tuyên bố Nova Foods đang vận hành rule đó.

Trường ghi nhận	Nội dung phải có	Ví dụ ghi nhận defensible
Claim ID	ID truy vết đã đăng ký, không tự đặt ID canonical mới	Tham chiếu TRACEABILITY_ID_REGISTRY để lấy ID hợp lệ
Fact và nguồn	Ai nói gì, tài liệu nào, ngày nào, phạm vi nào	Phỏng vấn Điều phối kho, 2026-08-07, dữ liệu tổng hợp; chưa có tài liệu quy trình kèm theo
Mức bằng chứng	Mạnh khi có nguồn kiểm soát và đối chiếu; yếu khi chỉ có một lời kể	Yếu: một lời kể, chưa đối chiếu
Inference	Lý do từ fact đến nhận định, không nhảy cóc	Lời kể về chờ duyệt cho thấy khả năng có điểm kiểm soát, không chứng minh rule toàn cục
Điều chưa biết	Biến số có thể đổi quyết định	Ngưỡng, vai trò duyệt, ngoại lệ, hệ thống thực hiện
Khuyến nghị	Hành động tạm thời, tiêu chí chọn, giới hạn	Giữ trạng thái Verification required; không đưa vào CANONICAL_BUSINESS_RULES như rule xác nhận
Decision authority	Vai trò quyết định theo loại vấn đề	Business Owner cho chính sách nghiệp vụ; Architect cho thiết kế; Legal/Accounting Owner cho diễn giải thuộc lĩnh vực đó
Consequence if wrong	Hậu quả cụ thể nếu suy luận sai	Cấu hình chặn giao hàng sai phạm vi hoặc bỏ qua kiểm soát cần thiết

Dùng ngôn ngữ xác suất có căn cứ: “bằng chứng hiện có hỗ trợ giả thuyết”, “chưa đủ bằng chứng để kết luận”, “khuyến nghị có điều kiện”, “cần xác minh trước khi chuyển thành requirement”. Không dùng “chắc chắn”, “đã thống nhất”, “đã phê duyệt”, “tuân thủ” khi artifact vẫn IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, chưa có tham chiếu approval hay baseline.

Khuyến nghị có thể bảo vệ được khi người khác tái tạo được đường đi: nguồn nào, mức tin cậy nào, suy luận nào, lựa chọn nào bị loại và ai phải quyết định. Nếu bằng chứng mâu thuẫn, Senior BA không lấy ý kiến cấp cao hơn làm “sự thật” tự động; ghi cả hai nguồn, mô tả tác động khác biệt, nêu câu hỏi phân xử và chuyển đúng authority. Nếu vấn đề có thể tác động pháp lý, kế toán, dữ liệu cá nhân, an toàn thực phẩm, bảo mật hoặc production, giữ nhãn Verification required; BA điều phối bằng chứng, không thay kết luận của Legal Owner, Accounting Owner, Security, Architect hoặc Business Owner.

12. Associated Template Reference & Completed Artifact

Core

Template là mẫu biểu có cấu trúc lặp lại để BA ghi nhận cùng loại bằng chứng theo cách nhất quán. Template không tự tạo sự thật nghiệp vụ, không thay thế quyết định của Business Owner, và không biến ghi chú phỏng vấn thành requirement đã xác nhận. Với Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, mọi dữ liệu chỉ là dữ liệu tổng hợp.

TEMPLATE_MANIFEST là nguồn kiểm soát đã xác minh cho danh mục template dự kiến:

Template ID / Artifact ID	Tệp canonical	Phân loại nguồn	Dùng khi	Không dùng khi	Owner	Consumer	Quality gate
TEMPLATE_MANIFEST	/01-curriculum/TEMPLATE_MANIFEST.md	Controlled planning artifact; template manifest	Cần kiểm tra template ID, tên tệp, phạm vi, dependency và trạng thái trước khi liên kết template vào chapter	Cần ghi nội dung phỏng vấn, quyết định nghiệp vụ, requirement hay approval	Principal IT Business Analyst / Technical Curriculum Author	Handbook author, template author, QA reviewer	ID và đường dẫn phải có trong manifest; trạng thái hiện hành phải là IN_REVIEW; không diễn giải là baseline hay approval

Không có template ID và tệp template cấp chi tiết nào được cung cấp trong nguồn đã xác minh của micro-batch này. Vì vậy chapter không được tự tạo ID dạng TMPL-*, không đoán tên tệp dưới /03-templates/, và không gắn một mẫu chưa đăng ký vào artifact Nova Foods. Bằng chứng là nguồn TEMPLATE_MANIFEST chỉ xác nhận artifact manifest, trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07; nguồn không cung cấp bản ghi template cấp chi tiết để trích dẫn chính xác.

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

flowchart TB
    A[Handbook author tra TEMPLATE_MANIFEST]
    A --> B{Có bản ghi template cấp chi tiết?}
    B -- Không, micro-batch hiện tại --> C[Không liên kết template]
    C --> D[Không tự tạo ID hoặc đường dẫn]
    D --> E[Không gắn mẫu chưa đăng ký vào artifact Nova Foods]
    B -- Có --> F{Quality gate: ID, tên tệp, đường dẫn canonical, phạm vi, dependency, owner, consumer và trạng thái IN_REVIEW khớp manifest?}
    F -- Không --> C
    F -- Có --> G[Liên kết đúng ID, tệp, owner và consumer]
    G --> H[Chỉ dùng như artifact IN_REVIEW]
    H --> I[Không diễn giải là baseline hoặc approval]

Applied

Facts: Nova Foods là mô phỏng giáo dục, dữ liệu tổng hợp; corpus có TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md; trạng thái corpus là IN_REVIEW, version v0.9.0, ngày 2026-08-07. Current Behavior: chapter cần tham chiếu mẫu biểu cho discovery interviewing và note taking nhưng nguồn đầu vào không chứa template ID cấp chi tiết hay tên tệp dưới /03-templates/. Underlying Need: người học cần biết mẫu nào là nguồn hợp lệ để tránh ghi nhầm tên tệp hoặc dùng template chưa được đăng ký. Options: dùng ID giả định; liên kết TEMPLATE_MANIFEST như catalog kiểm soát; hoặc không ghi liên kết nào. Decision Criteria: giữ đúng ID và filename đã xác minh, không tạo traceability giả, không ngụ ý approval. Decision: chỉ tham chiếu TEMPLATE_MANIFEST; chưa nêu template cấp chi tiết. Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì manifest; Owner của template cụ thể phải được manifest ghi nhận trước khi template được liên kết. Artifact: /01-curriculum/TEMPLATE_MANIFEST.md, Artifact ID TEMPLATE_MANIFEST. Consequence if Wrong: template ID hoặc đường dẫn bịa ra có thể làm BA ghi bằng chứng vào tệp không kiểm soát, phá traceability và khiến người đọc hiểu sai rằng mẫu đã được phê duyệt.

Senior Lens

Senior BA phân biệt “template manifest” với “completed artifact”. Manifest trả lời mẫu nào tồn tại trong danh mục kiểm soát; completed artifact chứa dữ liệu đã được ghi nhận theo mẫu. Hai thứ không thay thế nhau. Khi manifest chưa cung cấp template cấp chi tiết, quyết định đúng là giữ liên kết ở mức manifest, không bù khoảng trống bằng sáng tạo tên file.

Quality gate tối thiểu trước khi một template được gắn vào chapter: template ID xuất hiện nguyên dạng trong nguồn canonical; filename khớp nguyên dạng; owner và consumer rõ; mục đích dùng không vượt thẩm quyền; trạng thái không bị diễn giải thành APPROVED hoặc BASELINED. Nếu template chứa dữ liệu cá nhân, quy tắc kế toán, thuế, an toàn thực phẩm, bảo mật hoặc quyết định production, phải giữ nhãn Verification required và chuyển nội dung cho owner chuyên môn tương ứng.

Quick Reference

Tham chiếu	Dùng	Không dùng	Owner	Consumer	Quality gate
TEMPLATE_MANIFEST — /01-curriculum/TEMPLATE_MANIFEST.md	Tra cứu template được đăng ký và ranh giới quản trị	Ghi thay nội dung interview note, requirement, quyết định hoặc approval	Principal IT Business Analyst / Technical Curriculum Author	Handbook author, template author, QA reviewer	Giữ IN_REVIEW, v0.9.0, 2026-08-07; không suy ra baseline hay approval
Template ID cấp chi tiết	Chỉ dùng sau khi ID và filename xuất hiện trong nguồn canonical	Không tự đặt ID, tên tệp hoặc vị trí /03-templates/	Owner được manifest chỉ định	BA, reviewer, consumer được manifest chỉ định	ID, filename, owner, consumer và phạm vi phải khớp manifest

Quick Reference

Chapter lookup checklist. Mục tiêu: tìm đúng artifact đã điền cho Nova Foods, không suy diễn từ tên tệp gần giống. Nova Foods Trading & Manufacturing là case mô phỏng; mọi dữ liệu chỉ là dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND.

Mục kiểm	Phải tìm	Vị trí canonical	Kết quả đạt
1. Nhận diện chapter	Đúng chapter 03 Discovery Interviewing And Note Taking, section 12-templates-reference	/02-handbook/03-discovery-interviewing-and-note-taking.md	Không nhầm với chapter discovery khác.
2. Xác nhận chapter entry	Filename, dependency, template liên kết được manifest công nhận	/01-curriculum/CHAPTER_MANIFEST.md	Chỉ dùng filename và liên kết ghi trong manifest.
3. Tìm template đã đăng ký	Template ID, planned filename, phạm vi và dependency	/01-curriculum/TEMPLATE_MANIFEST.md	Có ID canonical; không đặt ID tự do.
4. Kiểm ID truy vết	ID template, ID interview, ID note, ID requirement liên quan	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Mỗi ID giữ nguyên chuỗi canonical.
5. Kiểm quy tắc được nhắc	Quy tắc nghiệp vụ được ghi nhận riêng, nếu artifact tham chiếu	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Không biến ghi chú phỏng vấn thành business rule canonical.
6. Kiểm thuật ngữ dữ liệu	Tên thực thể, thuộc tính, mã dữ liệu được dùng trong artifact	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Không tự đổi nghĩa trường dữ liệu hoặc mã.
7. Kiểm nguồn chứng cứ	Phân loại nguồn, giới hạn suy luận, ngày truy cập	/00-research/00_SOURCE_MAP.md	Không diễn giải nguồn chuẩn hoặc pháp lý vượt safe use boundary.
8. Kiểm trạng thái quản trị	IN_REVIEW, v0.9.0, ngày 2026-08-07	Metadata artifact tương ứng	Không gọi artifact là approved, baselined hoặc production-ready.
9. Xác định artifact điền sẵn	Filled-artifact filename và path được TEMPLATE_MANIFEST đăng ký	/01-curriculum/TEMPLATE_MANIFEST.md	Dùng đúng path đã đăng ký.

Vị trí artifact Nova Foods đã điền: nguồn đầu vào hiện có chưa cung cấp template ID, filename hoặc đường dẫn filled artifact cho chapter này. Vì vậy, không có path canonical nào được phép ghi tại đây. Điểm tra cứu bắt buộc là /01-curriculum/TEMPLATE_MANIFEST.md; chỉ sau khi manifest ghi rõ filled-artifact path mới được liên kết từ chapter. Không tạo /03-templates/ filename suy đoán, không sao chép registry đầy đủ, không coi bản nháp cục bộ là artifact canonical.

Core

Rà soát liên tệp là đối chiếu một ghi chú phỏng vấn với nguồn kiểm soát khác trước bàn giao chapter. Mục tiêu: tránh biến lời kể, giả định, hoặc ví dụ Nova Foods mô phỏng thành fact, quy tắc, approval, baseline, hay nghĩa vụ pháp lý. Corpus đang IN_REVIEW, v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh; mọi dữ liệu Nova Foods là tổng hợp.

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

flowchart TB
    A[Ghi chú phỏng vấn] --> B[Đối chiếu ID, tên tệp, trạng thái corpus]
    B --> C[Đối chiếu fact, quy tắc, approval, baseline, nghĩa vụ pháp lý và ranh giới nguồn]
    C --> D[Kiểm tra corpus: IN_REVIEW, v0.9.0, 2026-08-07, Asia/Ho_Chi_Minh; Nova Foods là dữ liệu tổng hợp]
    D --> E{Mâu thuẫn, chưa xác minh hoặc cần thẩm quyền?}
    E -- Không, mọi đối chiếu đạt --> F[Đánh dấu sẵn sàng handoff chapter]
    E -- Mâu thuẫn hoặc cần quyết định --> G[Lập open issue]
    E -- Chưa đủ bằng chứng --> H[Đánh dấu verification-required]
    G --> I[Escalation owner nguồn kiểm soát]
    H --> I
    I --> J[Owner xác minh và cập nhật nguồn kiểm soát hoặc ghi chú]
    J --> K[Giữ IN_REVIEW, không tự kết luận]
    K --> B

Applied

Trường	Nội dung artifact-ready
Facts	Ghi chú tổng hợp nói nhân viên kho muốn ERP chặn xuất hàng khi thiếu mã lô. CANONICAL_DATA_DICTIONARY là nguồn canonical cho định nghĩa dữ liệu; CANONICAL_BUSINESS_RULES là nguồn canonical cho quy tắc. Cả hai đang IN_REVIEW.
Current Behavior	Ghi chú chỉ ghi nhu cầu kiểm soát; không có rule ID, data field đã xác nhận, hay bằng chứng cấu hình ERP.
Underlying Need	Phân biệt nhu cầu truy xuất nguồn gốc với rule bắt buộc. Lý do: Luật An toàn thực phẩm là nguồn bối cảnh, nhưng diễn giải áp dụng cần domain-owner và legal verification.
Options	Ghi là giả định học liệu; tạo issue xác minh; hoặc tự viết rule chặn xuất hàng.
Decision Criteria	Chọn cách giữ traceability, không vượt thẩm quyền, không tạo quy tắc vận hành từ ghi chú đơn lẻ.
Decision	Tạo Verification required: xác minh điều kiện xuất hàng, phạm vi mã lô, ngoại lệ, owner nghiệp vụ, và căn cứ pháp lý nếu có. Không tạo rule mới trong chapter.
Authority	Business Owner xác nhận nhu cầu; Food Safety/Compliance Owner xác nhận bối cảnh truy xuất; Legal Owner xác nhận diễn giải pháp lý; Architect xác nhận khả năng ERP; Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết và issue.
Artifact	Ghi chú liên kết /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md; trạng thái giữ IN_REVIEW.
Consequence if Wrong	Chapter có thể dạy một kiểm soát giả định như nghĩa vụ bắt buộc, làm sai traceability, thiết kế dữ liệu, trách nhiệm phê duyệt, và test basis.

Senior Lens

Checklist self-review trước handoff:

Kiểm tra	Bằng chứng cần thấy	Kết quả khi thiếu	Escalation owner
ID và đường dẫn canonical	ID giữ nguyên, tệp tồn tại trong manifest/registry	Không tự đặt ID hoặc đổi tên tệp	Principal IT Business Analyst / Technical Curriculum Author
Trạng thái và version	IN_REVIEW, v0.9.0, 2026-08-07 nhất quán	Dừng handoff nếu artifact bị gọi là approved hoặc baselined	Principal IT Business Analyst / Technical Curriculum Author
Rule nghiệp vụ	Claim liên kết CANONICAL_BUSINESS_RULES hoặc ghi rõ giả định	Không biến interview note thành rule	Business Owner
Data term	Thuật ngữ, field, mã định danh liên kết CANONICAL_DATA_DICTIONARY	Không suy diễn schema hoặc mandatory field	Data Owner
Pháp lý, kế toán, thuế	Nguồn official và nhãn Verification required khi chưa có diễn giải được ủy quyền	Không trình bày như nghĩa vụ production	Legal Owner; Accounting Owner khi liên quan
Bảo mật, quyền truy cập, API	Có phạm vi, rủi ro, và nguồn OWASP/OAS khi phù hợp	Không tự xác nhận compliance hay kiến trúc	Security Owner; Architect
Kiểm thử	Acceptance criterion và test basis không tự tạo từ suy đoán	Không cho QA kiểm thử rule chưa xác nhận	QA Owner; Business Owner

Open issues trước handoff: chưa có bằng chứng canonical xác nhận rule chặn xuất hàng thiếu mã lô; chưa có xác nhận data field mã lô; chưa có kết luận pháp lý về phạm vi truy xuất; chưa có quyết định kiến trúc ERP về điểm chặn. Tất cả là Verification required, không phải lỗi đã được giải quyết.

Quick Reference

Handoff chỉ được ghi “đã rà soát liên tệp” khi từng claim có nguồn, giả định, hoặc issue rõ ràng. Không ghi “đã phê duyệt”, “đã baseline”, “tuân thủ”, hoặc “sẵn sàng production”. Principal IT Business Analyst / Technical Curriculum Author gửi gói issue gồm: claim gốc, artifact liên quan, lý do mâu thuẫn hoặc thiếu bằng chứng, owner escalation, và trạng thái IN_REVIEW.