09 Functional Specification Writing

Trường kiểm soát	Giá trị
Artifact ID	09_FUNCTIONAL_SPECIFICATION_WRITING
Tên tệp được kiểm soát	/02-handbook/09-functional-specification-writing.md
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale	vi-VN; bối cảnh Việt Nam; tiền tệ mô phỏng VND
Owner	Principal IT Business Analyst / Technical Curriculum Author
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, chỉ dữ liệu tổng hợp
Phân loại nguồn	Handbook chapter; không thay thế nguồn pháp lý, chuẩn, quyết định nghiệp vụ, kiến trúc, kế toán, bảo mật hoặc production
Baseline reference	Chưa có baseline reference tại v0.9.0
Approval reference	Chưa có approval reference tại v0.9.0

IN_REVIEW nghĩa là nội dung đang được kiểm soát để xem xét và còn có thể đổi theo truy vết. Trạng thái này không nghĩa APPROVED, BASELINED, phù hợp pháp lý, sẵn sàng production, hoặc được bất kỳ người dùng hay vai trò có thẩm quyền phê duyệt. Owner duy trì cấu trúc, định danh, phiên bản và liên kết corpus; Owner không xác nhận yêu cầu Nova Foods là đúng cho vận hành thực tế.

1. Concept l? g??

Core

Functional Specification là tài liệu đặc tả chức năng. Tài liệu này mô tả hệ thống phải hỗ trợ công việc nghiệp vụ như thế nào để người đọc có thể cùng hiểu một kết quả cần đạt. “Chức năng” không phải tên màn hình, nút bấm, bảng dữ liệu, hay đoạn mã. Chức năng là năng lực hệ thống tạo ra giá trị nghiệp vụ có thể quan sát và kiểm tra.

Từ điểm bắt đầu tuyệt đối: nghiệp vụ có mục tiêu, nhưng máy tính không tự hiểu mục tiêu đó. Ví dụ, người vận hành cần ghi nhận việc nhận hàng. Hệ thống cần biết thông tin nào được nhận, điều kiện nào được kiểm tra, kết quả nào được lưu, và khi nào phải từ chối thao tác. Functional Specification biến hiểu biết nghiệp vụ còn mơ hồ thành mô tả đủ rõ để các vai trò khác thiết kế, xây dựng và kiểm thử mà không tự đoán ý nghĩa.

Tài liệu trả lời trọng tâm: trong tình huống nghiệp vụ xác định, hệ thống nhận thông tin gì, xử lý theo quy tắc nào, tạo kết quả gì, hiển thị hay gửi kết quả cho đâu, và xử lý trường hợp không hợp lệ ra sao. Lý do cần mô tả các phần này: nếu chỉ ghi “hệ thống quản lý nhận hàng”, mỗi người có thể hiểu một khác. Developer có thể tạo màn hình nhập liệu; QA có thể kiểm tra lưu thành công; bộ phận kho lại cần kiểm tra số lượng, lô hàng và trạng thái trước khi nhận. Cùng một câu ngắn tạo nhiều cách làm, nên không tạo được một kết quả kiểm thử thống nhất.

Functional Specification không tự tạo quy tắc nghiệp vụ mới. Nó ghi nhận, cấu trúc hóa và làm rõ quy tắc từ nguồn có thẩm quyền phù hợp. Khi nguồn chưa xác định, tài liệu phải giữ đó là điểm cần xác minh, không chuyển thành yêu cầu bắt buộc bằng suy đoán. Với Nova Foods, mọi ví dụ trong handbook là mô phỏng giáo dục và dùng dữ liệu tổng hợp; không chứng minh ERP thực tế, quy trình thực tế hay tuân thủ pháp lý của tổ chức nào.

Ranh giới khái niệm: Functional Specification tập trung vào hệ thống cần làm gì và kết quả nghiệp vụ cần có. Tài liệu không thay thế thiết kế kỹ thuật chi tiết như cấu trúc cơ sở dữ liệu vật lý, thuật toán, hạ tầng, mã nguồn, cấu hình production, phân quyền thực tế, hoặc quyết định tích hợp. Các nội dung đó cần artifact và thẩm quyền riêng.

Core

Functional Specification là đặc tả chức năng: tài liệu mô tả hệ thống phải làm gì để hỗ trợ nhu cầu nghiệp vụ đã được làm rõ. Nó không phải yêu cầu mơ hồ, không phải mã nguồn, không phải hướng dẫn thao tác, và không tự quyết định giải pháp kỹ thuật chưa thuộc thẩm quyền.

Thuật ngữ	Nghĩa ngắn gọn	Vai trò trong đặc tả chức năng
Actor	Tác nhân khởi phát hoặc tham gia chức năng. Có thể là người dùng, vai trò hệ thống, hoặc hệ thống ngoài.	Xác định ai thực hiện hoặc nhận kết quả. Ví dụ: Nhân viên Kho, không phải tên cá nhân.
Action	Hành động actor yêu cầu hệ thống xử lý.	Diễn đạt bằng động từ rõ: tạo, xác nhận, tra cứu, hủy. Tránh từ mơ hồ như “xử lý”.
Object	Đối tượng nghiệp vụ bị tác động.	Xác định dữ liệu hoặc thực thể: phiếu nhập kho, đơn bán hàng, lô hàng.
Outcome	Kết quả quan sát được sau xử lý.	Nêu trạng thái, dữ liệu tạo ra, thông báo, hoặc thay đổi có thể kiểm tra.
Business Rule	Quy tắc nghiệp vụ.	Điều kiện luôn phải đúng khi chức năng chạy; không phải sở thích giao diện.
Acceptance Criteria	Tiêu chí chấp nhận.	Điều kiện kiểm chứng để đánh giá chức năng đáp ứng mô tả hay chưa.
UI	User Interface, giao diện người dùng.	Cách người dùng tương tác; chỉ mô tả khi cần cho hành vi chức năng.
API	Application Programming Interface, giao diện để hệ thống trao đổi dữ liệu.	Chỉ xác định khi actor là hệ thống khác hoặc khi chức năng cần tích hợp.

Cấu trúc hạt nhân của một chức năng là: actor thực hiện action lên object để tạo outcome. Cấu trúc này buộc câu mô tả trả lời bốn câu hỏi kiểm tra được: ai làm, làm việc gì, tác động lên cái gì, hệ thống phải cho ra kết quả nào.

Ví dụ dữ liệu tổng hợp của Nova Foods Trading & Manufacturing — mô phỏng giáo dục: Nhân viên Kho là actor; xác nhận là action; phiếu nhập kho NF-GRN-00021 là object; phiếu có trạng thái Đã xác nhận và số lượng tồn kho mô phỏng được cập nhật là outcome. Suy luận này dựa trên nghĩa từng thành phần: không có actor thì không xác định quyền hoặc điểm khởi phát; không có object thì không xác định dữ liệu bị đổi; không có outcome thì QA không có kết quả để kiểm tra.

Câu “Hệ thống quản lý nhập kho” chưa phải functional specification. Nó thiếu actor, action cụ thể, object xác định và outcome đo được. Câu này chỉ nêu chủ đề. Một câu đủ tối thiểu là: “Nhân viên Kho xác nhận phiếu nhập kho để hệ thống ghi nhận trạng thái phiếu và cập nhật tồn kho mô phỏng.”

Applied

Ví dụ tối thiểu, Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp. Functional Specification mô tả hệ thống phải làm gì trong một tình huống nghiệp vụ xác định, không tự quyết định chính sách kinh doanh hay thiết kế kỹ thuật. Ví dụ: nhân viên kho cần ghi nhận hàng thành phẩm hoàn tất để tồn kho khả dụng tăng đúng theo lô.

Thành phần	Nội dung ví dụ
Facts	Phiếu hoàn thành sản xuất mô phỏng PRD-REC-0001 có mã hàng NF-THUC-UONG-001, lô LOT-NF-260807-01, số lượng 1.200, đơn vị chai.
Current Behavior	Nhân viên kho nhập số lượng hoàn thành vào ERP; hệ thống chưa có mô tả thống nhất về kiểm tra dữ liệu và kết quả ghi nhận.
Underlying Need	Kho cần biết tồn theo mã hàng và lô sau khi ghi nhận, vì xuất kho tiếp theo cần số liệu tồn khả dụng.
Actor	Người hoặc vai trò khởi phát tương tác. Trong ví dụ: Nhân viên kho.
Action	Thao tác actor yêu cầu hệ thống thực hiện. Trong ví dụ: xác nhận ghi nhận hoàn thành sản xuất.
Object	Đối tượng nghiệp vụ bị tác động. Trong ví dụ: bản ghi thành phẩm theo mã hàng, lô, số lượng và đơn vị tính.
Outcome	Kết quả có thể quan sát sau action. Trong ví dụ: ERP tạo bản ghi nhận kho và cập nhật tồn khả dụng của NF-THUC-UONG-001 cho LOT-NF-260807-01.
Artifact	Functional Specification ghi rõ actor, điều kiện đầu vào, action, object, xử lý, kết quả và lỗi cần thông báo.

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

flowchart TB
    A[Nhân viên kho] --> B[Xác nhận phiếu PRD-REC-0001]
    B --> C{Mã hàng, lô, số lượng và<br/>đơn vị tính hợp lệ theo quy tắc<br/>đã được xác nhận?}
    C -- Có --> D[Tạo bản ghi nhận kho:<br/>NF-THUC-UONG-001<br/>LOT-NF-260807-01 · 1.200 chai]
    D --> E[Cập nhật tồn khả dụng<br/>theo mã hàng và lô]
    E --> F[Hiển thị kết quả ghi nhận]
    C -- Không --> G[Hiển thị lỗi;<br/>không cập nhật tồn]

    H[Canonical rules:<br/>/01-curriculum/CANONICAL_BUSINESS_RULES.md<br/>IN_REVIEW v0.9.0;<br/>không phải baseline/approval]:::note
    I[Canonical data dictionary:<br/>/01-curriculum/CANONICAL_DATA_DICTIONARY.md<br/>IN_REVIEW v0.9.0;<br/>không phải baseline/approval]:::note

    H -. nguồn quy tắc .-> C
    I -. nguồn dữ liệu .-> D

    classDef note fill:#f8f8f8,stroke:#999,color:#333,stroke-dasharray: 5 5

Ranh giới concept: Functional Specification chuyển nhu cầu thành hành vi hệ thống kiểm chứng được. Nó phải nêu điều kiện nào cho phép ghi nhận, dữ liệu nào bị tác động, kết quả nào xuất hiện, và khi dữ liệu sai hệ thống xử lý ra sao. Suy luận: kho cần tồn chính xác để vận hành; vì vậy đặc tả phải mô tả kiểm tra và cập nhật tồn, không dừng ở câu “hệ thống hỗ trợ nhập kho”.

Loại nội dung	Trong phạm vi Functional Specification	Loại trừ hoặc chuyển artifact/vai trò khác
Nghiệp vụ hệ thống	Quy tắc xử lý đã được nguồn có thẩm quyền xác nhận; hành vi thành công và lỗi	Tự tạo chính sách tồn kho, định mức, giá vốn, thuế
Giao diện	Trường cần nhập, thông báo kết quả, điều kiện hiển thị	Màu sắc, layout pixel, component kỹ thuật chi tiết nếu chưa cần
Dữ liệu	Mã hàng, lô, số lượng, đơn vị tính bị đọc hoặc ghi	Kiểu cột DB, index, schema vật lý
Tích hợp	Sự kiện hoặc dữ liệu cần trao đổi ở mức hành vi	API endpoint, HTTP method, payload, xác thực kỹ thuật
Kiểm thử	Kết quả mong đợi đủ làm test basis	Kế hoạch test, test case đầy đủ, kết luận QA
Pháp lý và tuân thủ	Gắn nhãn Verification required khi có ảnh hưởng pháp lý, kế toán, an toàn thực phẩm hoặc dữ liệu cá nhân	Diễn giải luật, xác nhận tuân thủ, cấp phép production

Không suy ra từ ví dụ rằng Nova Foods dùng quy trình, ERP, chính sách lô hay quy tắc tồn kho thực tế. PRD-REC-0001, NF-THUC-UONG-001, LOT-NF-260807-01 chỉ minh họa cấu trúc đặc tả. Mọi rule nghiệp vụ canonical phải giữ traceability tới /01-curriculum/CANONICAL_BUSINESS_RULES.md; mọi định nghĩa dữ liệu canonical phải giữ traceability tới /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Cả hai artifact đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không phải baseline hay approval.

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

Core

Functional Specification là đặc tả chức năng: artifact chuyển nhu cầu nghiệp vụ đã được làm rõ thành hành vi hệ thống có thể xây dựng và kiểm thử. Nó tồn tại để chặn khoảng trống giữa câu nói nghiệp vụ như “nhập kho phải đúng” và quyết định kỹ thuật như kiểm tra gì, khi nào chặn, dữ liệu nào đổi, ai thấy lỗi, kết quả nào được chấp nhận.

Không có đặc tả chức năng, mỗi vai trò tự lấp khoảng trống bằng cách hiểu riêng. Business Owner có thể kỳ vọng chặn giao dịch khi số lượng không hợp lệ. Developer có thể chỉ lưu số nhập. QA có thể kiểm tra màn hình hiển thị thành công. Ba cách hiểu cùng tồn tại nhưng không chứng minh cùng một hành vi. Lỗi chỉ lộ sau khi build hoặc UAT, khi sửa đã ảnh hưởng code, test case, dữ liệu mô phỏng và tài liệu hướng dẫn.

Rủi ro bị ngăn	Cơ chế phòng ngừa của Functional Specification	Hậu quả nếu thiếu
Mơ hồ nghiệp vụ	Nêu điều kiện kích hoạt, dữ liệu đầu vào, xử lý, ngoại lệ và kết quả mong đợi	Cùng một yêu cầu sinh nhiều cách build
Rework	Khóa phạm vi hành vi trước khi developer xây dựng	Sửa code, test, hướng dẫn và dữ liệu sau khi phát hiện lệch
Lỗ hổng traceability	Liên kết nhu cầu, quy tắc, dữ liệu, acceptance criteria và kiểm thử	Không xác định được vì sao chức năng tồn tại hoặc thay đổi gì bị ảnh hưởng
Sai quyền quyết định	Gắn nguồn, owner và trạng thái xác minh cho rule	BA hoặc developer tự biến giả định thành policy
Governance risk	Phân biệt nội dung IN_REVIEW với baseline, approval và production rule	Nội dung học liệu bị hiểu nhầm là quyết định vận hành hoặc tuân thủ

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. Chức năng minh họa: ghi nhận nhận hàng cho PRD-REC-0001, mặt hàng NF-THUC-UONG-001, lô LOT-NF-260807-01.

Nếu chỉ có yêu cầu “hệ thống hỗ trợ nhập kho theo lô”, developer không biết giao dịch nào phải bị chặn. Hệ thống có thể lưu lô dù số lượng bằng 0; QA có thể chỉ xác nhận nút Lưu hoạt động; người dùng mô phỏng sau đó thấy tồn kho được cập nhật từ giao dịch không có giá trị. Đây là lỗi hành vi quan sát được, không cần số liệu bịa đặt để chứng minh rủi ro.

Functional Specification buộc nhóm ghi rõ: khi người dùng gửi nhận hàng, hệ thống kiểm tra mã hàng, mã lô và số lượng; nếu số lượng không lớn hơn 0, không tạo nhận hàng và trả lỗi; nếu hợp lệ, tạo giao dịch và cập nhật tồn theo hành vi đã được xác nhận. Nhờ vậy, developer có ranh giới build, QA có kết quả kiểm tra, reviewer có điểm kiểm soát. Quy tắc tồn kho thực tế vẫn không được tự suy diễn; phải truy vết tới /01-curriculum/CANONICAL_BUSINESS_RULES.md và dữ liệu tới /01-curriculum/CANONICAL_DATA_DICTIONARY.md, đều IN_REVIEW, v0.9.0, ngày 2026-08-07.

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

flowchart TB
    A[Người dùng gửi nhận hàng] --> B{Mã hàng và mã lô hợp lệ?}

    B -- Không hoặc chưa xác định --> C[Hành vi chưa được xác nhận<br/>Cần làm rõ, không tự suy diễn]
    B -- Có --> D{Số lượng lớn hơn 0?}

    D -- Không --> E[Không tạo nhận hàng<br/>Trả lỗi]
    D -- Có --> F[Tạo giao dịch nhận hàng]
    F --> G[Cập nhật tồn theo hành vi đã được xác nhận]

    H["Dữ liệu: /01-curriculum/CANONICAL_DATA_DICTIONARY.md<br/>IN_REVIEW · v0.9.0 · 2026-08-07"] -. Truy vết .-> B
    C -. Truy vết để làm rõ .-> H

    I["Quy tắc: /01-curriculum/CANONICAL_BUSINESS_RULES.md<br/>IN_REVIEW · v0.9.0 · 2026-08-07"] -. Truy vết .-> D
    I -. Truy vết .-> G

Senior Lens

Đặc tả chức năng không thay Business Owner quyết định policy, không thay Legal Owner diễn giải pháp luật, không thay Accounting Owner xác nhận hạch toán, và không thay Architect quyết định thiết kế kỹ thuật. Giá trị của nó là làm lộ quyết định còn thiếu trước khi quyết định đó biến thành code. Khi một rule chưa có nguồn hoặc authority, đặc tả phải giữ trạng thái cần xác minh thay vì viết thành hành vi bắt buộc.

Rủi ro governance tăng mạnh khi một câu mô tả bị sao chép qua ticket, test case và tài liệu đào tạo mà không còn nguồn gốc. Câu đó dần trông như “đã chốt”, dù corpus Nova Foods chưa có baseline hay approval. Functional Specification giảm rủi ro này bằng cách giữ phạm vi, nguồn tham chiếu, trạng thái và owner quyết định cạnh hành vi hệ thống.

Quick Reference

Nguyên tắc	Áp dụng
Viết hành vi, không viết khẩu hiệu	Thay “hệ thống hỗ trợ nhập kho” bằng điều kiện, xử lý, lỗi và kết quả
Không tự lấp khoảng trống	Chuyển quyết định chưa có authority thành điểm cần xác minh
Một thay đổi phải thấy được ảnh hưởng	Liên kết rule, dữ liệu, chức năng và test basis
IN_REVIEW không phải approval	Không gọi nội dung Nova Foods là baseline, compliant hoặc production-ready
Giữ boundary nguồn	Không suy diễn pháp lý, kế toán, thuế, an toàn thực phẩm hoặc dữ liệu cá nhân từ case mô phỏng

Core

Functional Specification là đặc tả chức năng: biến nhu cầu nghiệp vụ thành hành vi ERP có thể xây, kiểm thử và truy vết. Nó tồn tại để chặn tình trạng cùng một câu nói bị hiểu thành nhiều cách. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu đều tổng hợp, trạng thái corpus là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; nội dung không phải cấu hình ERP thực hay quyết định vận hành.

Trước khi có đặc tả, câu “khóa đơn bán hàng cần lấy đúng giá” không nói giá nào, thời điểm nào, nguồn nào, ai xử lý khi thiếu giá. Developer có thể lấy giá hiện tại từ bảng giá. QA có thể kiểm tra giá tại lúc tạo đơn. Kế toán có thể chờ giá được chốt khi giao hàng. Ba cách vẫn cùng nghe hợp lý, nhưng tạo ba hành vi khác nhau.

Applied

Thành phần	Trước có Functional Specification	Sau có Functional Specification	Hệ quả quan sát được
Tình huống mô phỏng	Nhân viên tạo Sales Order SO-SIM-20260807-001 cho khách CUS-SIM-001, mặt hàng FG-SIM-001.	Cùng Sales Order và mặt hàng tổng hợp.	So sánh cùng ngữ cảnh, không suy diễn số liệu thực.
Câu yêu cầu ban đầu	“Lấy giá theo bảng giá khách hàng.”	Đặc tả ghi: ERP tìm bảng giá hiệu lực cho customer_id, item_id, ngày tạo Sales Order; không tìm thấy thì chặn xác nhận đơn và báo lỗi nghiệp vụ.	Developer biết điểm tra cứu và nhánh lỗi.
Thời điểm khóa giá	Không nêu.	Đơn giá được sao chép vào dòng Sales Order khi người dùng xác nhận đơn; thay đổi bảng giá sau đó không tự sửa đơn đã xác nhận.	QA có thời điểm kiểm thử xác định; người dùng thấy đơn đã xác nhận giữ nguyên giá.
Nguồn dữ liệu	Có thể hiểu là bảng giá hiện hành, báo giá, hoặc nhập tay.	Nguồn là Price List logic; trường dòng đơn lưu unit_price_vnd tại thời điểm xác nhận. Cấu trúc vật lý cần đối chiếu CANONICAL_DATA_DICTIONARY.	Truy vết được nguồn và dữ liệu lưu trên giao dịch.
Ngoại lệ	Không nêu người xử lý.	Không có giá hiệu lực: trạng thái đơn không chuyển sang xác nhận; người dùng sửa dữ liệu hoặc chuyển xử lý theo quy trình được đặc tả.	Không phát sinh đơn xác nhận với giá không xác định.
Kiểm thử	QA tự chọn diễn giải.	Test basis kiểm tra: có giá hiệu lực, không có giá hiệu lực, bảng giá đổi sau xác nhận.	Kết quả pass/fail gắn hành vi đã viết.

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

flowchart TB
    A[Người dùng tạo Sales Order mô phỏng] --> B[Người dùng yêu cầu xác nhận Sales Order]
    B --> C[ERP tìm Price List hiệu lực theo customer_id, item_id, ngày tạo Sales Order]
    C -->|Có giá| D[ERP sao chép unit_price_vnd vào dòng đơn]
    D --> E[Sales Order đã xác nhận: giá đã khóa]
    E --> F[Price List thay đổi sau xác nhận]
    F --> G[Không tự sửa unit_price_vnd của đơn đã xác nhận]
    C -->|Không có giá| H[Chặn xác nhận; Sales Order không chuyển sang đã xác nhận]
    H --> I[Báo lỗi nghiệp vụ]
    I --> J[Người dùng sửa dữ liệu hoặc chuyển xử lý theo quy trình đặc tả]

Senior Lens

Khác biệt không nằm ở văn phong dài hơn. Khác biệt nằm ở khả năng loại trừ diễn giải cạnh tranh. “Đúng giá” là mục tiêu; chưa đủ cho build. Đặc tả phải làm rõ đối tượng áp dụng, nguồn dữ liệu, điều kiện, thời điểm, kết quả, ngoại lệ và dữ liệu được lưu. Mỗi điểm làm rõ tạo ranh giới giữa hành vi được phép và hành vi không được phép.

Không được ghi rằng Nova Foods phải giữ giá đơn vì luật, kế toán hay thuế nếu chưa được xác minh với chủ sở hữu chuyên môn. Trong ví dụ này, việc khóa giá là lựa chọn hành vi mô phỏng để minh họa cách đặc tả giảm mơ hồ. Nếu ảnh hưởng hạch toán, hóa đơn hoặc nghĩa vụ pháp lý, cần xác minh với Accounting Owner hoặc Legal Owner; tham chiếu nguồn luật không thay thế kết luận của vai trò có thẩm quyền.

Quick Reference

Dấu hiệu thiếu đặc tả	Hậu quả gần	Nội dung phải bổ sung
“Lấy đúng giá”	Nhiều cách code hợp lý	Nguồn giá, điều kiện hiệu lực, thời điểm tra cứu
“Hệ thống báo lỗi”	UI, API và QA hiểu khác nhau	Điều kiện lỗi, hành động bị chặn, thông điệp nghiệp vụ
“Giá không được đổi”	Không rõ đổi ở đâu và khi nào	Đối tượng khóa, mốc khóa, dữ liệu được lưu
“Theo quy trình hiện tại”	Không có test basis độc lập	Luồng, trạng thái, ngoại lệ, artifact truy vết

Đặc tả tốt làm hậu quả sai hiện ra trước khi code: đơn có thể bị xác nhận sai giá, dữ liệu giao dịch không tái hiện được, QA không có tiêu chí chung. Đặc tả chưa tạo approval hay baseline; chỉ tạo nền tảng để review có kiểm soát.

Phân loại phát biểu trước khi viết Functional Specification

Functional Specification chỉ đáng tin khi mỗi phát biểu có loại bằng chứng rõ. “Đúng” không đủ: BA cần biết điều đó đã được xác minh, do stakeholder cung cấp, đang giả định, đã được người có thẩm quyền quyết định, hay còn phải xác minh. Nếu không gắn loại, đội triển khai dễ biến ý kiến thành quy tắc ERP, biến giả định thành cam kết, hoặc dùng quyết định chưa có thẩm quyền làm cơ sở cấu hình.

Loại phát biểu	Định nghĩa từ gốc	Bằng chứng tối thiểu	Được ghi trong Functional Specification?	Cách diễn đạt bắt buộc
Verified fact	Sự kiện đã kiểm tra được từ nguồn xác định, tại thời điểm xác định	Artifact kiểm soát, dữ liệu mẫu tổng hợp, URL nguồn chính thức, bản ghi hệ thống mô phỏng	Có	Nêu nguồn, ngày kiểm tra, phạm vi
Stakeholder input	Thông tin, nhu cầu hoặc cách hiểu do stakeholder cung cấp	Tên vai trò, cuộc họp hoặc artifact ghi nhận; chưa tự chứng minh đúng	Có	“Stakeholder input từ [vai trò] nêu rằng…”
Project assumption	Điều dự án tạm coi là đúng để tiếp tục phân tích khi chưa đủ bằng chứng	Lý do cần giả định, tác động, owner xác minh, điều kiện hết hiệu lực	Có, phải gắn nhãn	“Project assumption: …”
Decision	Lựa chọn giữa các phương án, có tiêu chí và người có thẩm quyền ghi nhận	Phương án, tiêu chí, authority, artifact quyết định	Có, nếu đã ghi nhận	“Decision: …; Authority: …”
Verification-required claim	Phát biểu có thể ảnh hưởng pháp lý, kế toán, thuế, an toàn thực phẩm, bảo mật hoặc vận hành nhưng chưa được nguồn/thẩm quyền phù hợp xác minh	Thiếu bằng chứng cần thiết hoặc cần xác minh hiệu lực hiện hành	Có, nhưng không thành requirement bắt buộc	“Verification required: …”

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 thái corpus là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không có baseline hay approval được ghi nhận.

ID ghi nhận	Phát biểu Nova Foods	Phân loại	Cầu nối bằng chứng và suy luận	Hành động BA
FSW-02-FACT-001	/01-curriculum/CHAPTER_MANIFEST.md có trạng thái IN_REVIEW, phiên bản v0.9.0.	Verified fact	Metadata artifact upstream ghi trực tiếp trạng thái và phiên bản. Không suy ra approval từ IN_REVIEW.	Dùng làm ràng buộc quản trị tài liệu.
FSW-02-INPUT-001	Warehouse Supervisor muốn ERP chặn xuất hàng khi lô hàng chưa có kết quả kiểm tra chất lượng.	Stakeholder input	Đây là nhu cầu do vai trò nghiệp vụ nêu. Bản thân phát biểu không chứng minh quy trình hiện tại, quyền chặn, hay điều kiện chất lượng.	Ghi nguồn input; hỏi quy trình, ngoại lệ, dữ liệu kiểm tra, owner quyết định.
FSW-02-ASSUMP-001	Project assumption: mỗi lô hàng mô phỏng có một mã lô duy nhất trong phạm vi một nhà máy mô phỏng.	Project assumption	Cần mã lô để mô tả truy vết trong ví dụ. CANONICAL_DATA_DICTIONARY mới là kế hoạch, chưa xác nhận cấu trúc dữ liệu triển khai.	Giữ nhãn giả định; thay bằng fact hoặc decision khi data owner xác minh.
FSW-02-DEC-001	Decision: Functional Specification chỉ mô tả hành vi ERP sau khi điều kiện chặn đã được Business Owner và Quality Owner ghi nhận trong artifact quyết định.	Decision	Lựa chọn này ngăn BA tự chuyển stakeholder input thành business rule. Authority phải được ghi nhận; Owner curriculum không thay thế Business Owner hoặc Quality Owner.	Liên kết artifact quyết định khi tồn tại; nếu chưa có, không viết rule bắt buộc.
FSW-02-VERIFY-001	Verification required: điều kiện lưu giữ dữ liệu truy vết lô hàng có thể chịu tác động của Luật An toàn thực phẩm và quy định liên quan.	Verification-required claim	Verified source seed xác định Luật An toàn thực phẩm là bối cảnh traceability/recall và yêu cầu domain-owner, legal verification. Seed không cung cấp điều khoản hay thời hạn lưu giữ cụ thể.	Không đặt số năm, không gọi là nghĩa vụ; chuyển Legal Owner và domain owner xác minh.

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

flowchart TB
    A[Phát biểu đầu vào] --> B{Là lựa chọn đã ghi nhận?}

    B -->|Có| C{Có phương án, tiêu chí, authority và artifact quyết định?}
    C -->|Có| D[Decision]
    D --> D1[Functional Specification: nêu lựa chọn, authority, artifact; liên kết phát biểu gốc]

    C -->|Không| C1[Chưa đủ bằng chứng để phân loại là Decision]
    C1 --> C2{Có thể ảnh hưởng pháp lý, kế toán, thuế, an toàn thực phẩm, bảo mật hoặc vận hành?}
    C2 -->|Có| E[Verification-required claim]
    C2 -->|Không| C3[Theo dõi authority hoặc artifact còn thiếu, hoặc loại khỏi Functional Specification]
    C3 --> C4[Không thành rule bắt buộc]

    E --> E1[Functional Specification: nêu giới hạn tri thức, nguồn hoặc thẩm quyền cần xác minh, owner xác minh]
    E --> E2[Không thành rule bắt buộc khi chưa xác minh phù hợp]

    B -->|Không| F{Nguồn xác định, phù hợp, đủ chứng minh; có ngày và phạm vi kiểm tra?}
    F -->|Có| G[Verified fact]
    G --> G1[Functional Specification: nêu nguồn, ngày kiểm tra, phạm vi]
    G --> G2[Fact có thể xác minh Decision tồn tại; không thay loại Decision]

    F -->|Không| H{Do stakeholder cung cấp?}
    H -->|Có| I[Stakeholder input]
    I --> I1[Functional Specification: nêu vai trò, họp hoặc artifact; giữ nhãn]
    I --> I2[Chưa xác nhận: không thành rule bắt buộc]

    H -->|Không| J{Cần tạm dùng để phân tích?}
    J -->|Có| K[Project assumption]
    K --> K1[Functional Specification: nêu lý do, tác động, owner xác minh, điều kiện hết hiệu lực]

    J -->|Không| L{Có thể ảnh hưởng pháp lý, kế toán, thuế, an toàn thực phẩm, bảo mật hoặc vận hành?}
    L -->|Có| E
    L -->|Không| M[Làm rõ loại phát biểu, xác định bằng chứng còn thiếu, hoặc loại khỏi Functional Specification]

    I -. nguồn đầu vào, giữ nhãn .-> N[Đề xuất lựa chọn]
    K -. nguồn đầu vào, giữ nhãn .-> N
    E -. nguồn đầu vào, giữ nhãn .-> N
    G -. nguồn đầu vào, giữ nhãn .-> N

    N --> O{Có phương án, tiêu chí, authority và artifact quyết định?}
    O -->|Có| D
    O -->|Không| P[Theo dõi xác minh hoặc quyết định; không thành rule bắt buộc]

Quy tắc viết: verified fact mô tả điều đã biết; stakeholder input mô tả ai đã nói gì; project assumption mô tả điều tạm dùng và điều kiện phải kiểm tra; decision mô tả lựa chọn đã ghi nhận cùng authority; verification-required claim mô tả giới hạn tri thức hiện tại. Không đổi nhãn bằng cách viết lại câu theo giọng khẳng định. Một câu như “ERP phải chặn xuất hàng” chỉ là requirement sau khi có decision hoặc nguồn nghiệp vụ được thẩm quyền xác nhận; trước đó nó vẫn là input hoặc claim cần xác minh.

3. V? tr? trong Lifecycle

Core

Functional Specification (đặc tả chức năng) biến nhu cầu nghiệp vụ đã phân tích thành hành vi hệ thống có thể xây, kiểm thử và vận hành. Nó không khởi đầu ở Discovery vì Discovery chỉ tìm vấn đề, mục tiêu và phạm vi. Nó không kết thúc ở Delivery vì mã nguồn chưa chứng minh hệ thống đáp ứng đặc tả.

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi ví dụ và dữ liệu là tổng hợp. Luồng dưới đây dùng trạng thái tài liệu IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh.

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

flowchart TB
    D[Discovery<br/>Nhu cầu và vấn đề]
    A[Analysis<br/>Làm rõ rule, dữ liệu, luồng]
    F[Functional Specification<br/>Trạng thái: IN_REVIEW<br/>Phiên bản: v0.9.0<br/>Ngày: 2026-08-07<br/>Locale: vi-VN<br/>Múi giờ: Asia/Ho_Chi_Minh]
    G{Gate vào Delivery<br/>Hành vi quan sát được; rule; dữ liệu;<br/>ngoại lệ; acceptance criteria;<br/>mục chưa rõ gắn verification-required claim<br/>hoặc project assumption}
    DE[Delivery<br/>Thiết kế và xây dựng]
    T[Testing<br/>Đối chiếu build với test basis]
    GD{Quyết định phát hành của<br/>thẩm quyền phù hợp}
    NR[Không phát hành<br/>Quyết định đã ghi nhận]
    PD[Chưa quyết định<br/>Giữ trạng thái chờ]
    R[Release<br/>Triển khai theo quyết định phát hành]
    O[Operations<br/>Vận hành, sự cố, thay đổi]

    D -->|Entry Analysis:<br/>phạm vi, mục tiêu, câu hỏi mở,<br/>nguồn đầu vào và stakeholder input đã ghi nhận| A
    A -->|Requirement có lý do,<br/>nguồn và phân loại| F
    F --> G
    G -->|Đạt| DE
    G -->|Chưa đạt| A
    DE -->|Entry Testing:<br/>build và Functional Specification<br/>cùng phiên bản tham chiếu| T
    T -->|Kết quả test, lỗi và<br/>sai khác đã ghi nhận| GD
    GD -->|Phát hành| R
    GD -->|Không phát hành| NR
    GD -->|Chưa quyết định| PD
    NR -->|Sửa build theo đặc tả| DE
    NR -->|Sai khác cần phân tích lại| A
    PD -->|Có quyết định| GD
    R -->|Phiên bản, thay đổi và<br/>thông tin vận hành đã ghi nhận| O
    O -->|Cần xác định lại vấn đề,<br/>mục tiêu hoặc phạm vi| D
    O -->|Phạm vi đã rõ,<br/>cần phân tích hành vi| A

Giai đoạn	Entry gate: điều phải có trước khi vào	Vai trò Functional Specification	Exit gate: điều phải có để đi tiếp
Discovery	Vấn đề, mục tiêu hoặc cơ hội được ghi nhận là stakeholder input; chưa gọi là rule hệ thống.	Chưa viết đặc tả; BA giữ ngữ cảnh để tránh giải pháp sớm.	Phạm vi cần phân tích, câu hỏi mở và nguồn đầu vào được ghi nhận.
Analysis	Phạm vi Discovery đủ để phân tích; mỗi phát biểu có nhãn nguồn như verified fact, stakeholder input, project assumption hoặc verification-required claim.	BA xác định trigger, người dùng, dữ liệu, quy tắc, ngoại lệ và kết quả mong đợi.	Mỗi requirement dự kiến có lý do, nguồn và điều chưa biết được gắn nhãn.
Delivery	Functional Specification mô tả hành vi quan sát được, không tự suy diễn cấu hình kỹ thuật.	Là test basis và build basis: đội giao hàng dùng mô tả để thiết kế, cấu hình hoặc lập trình.	Bản build có thể đối chiếu từng hành vi đặc tả; sai khác phải quay lại artifact thay vì sửa im lặng.
Testing	Build và Functional Specification cùng phiên bản tham chiếu; acceptance criteria là tiêu chí chấp nhận có thể kiểm tra.	Cung cấp expected result, điều kiện biên và ngoại lệ cho kiểm thử.	Kết quả test, lỗi và sai khác với đặc tả được ghi nhận; pass không thay thế quyết định phát hành.
Release	Kết quả kiểm thử và quyết định phát hành được ghi nhận bởi thẩm quyền phù hợp.	Là nguồn giải thích phạm vi hành vi được phát hành và giới hạn đã biết.	Phiên bản phát hành, thay đổi liên quan và thông tin vận hành được ghi nhận.
Operations	Hệ thống đang chạy hoặc có phản hồi, sự cố, yêu cầu thay đổi.	Là chuẩn so sánh giữa hành vi vận hành và hành vi đã đặc tả.	Nhu cầu đổi hành vi quay về Discovery hoặc Analysis; không sửa đặc tả để hợp thức hóa hành vi chưa được phân tích.

Applied

Facts: Nova Foods mô phỏng có nhu cầu “không cho xuất hàng khi thiếu thông tin lô”. Đây là stakeholder input, không phải verified fact hay quy tắc bắt buộc. Current Behavior: chưa có bằng chứng cấu hình ERP hoặc hành vi hệ thống hiện hữu. Underlying Need: bảo đảm người dùng biết điều kiện nào làm giao dịch bị chặn và thông báo nào xuất hiện.

Options: (1) viết ngay “ERP phải chặn xuất hàng”; (2) ghi nhận input, xác minh nguồn quy tắc và sau đó viết hành vi có acceptance criteria; (3) để đội Delivery tự chọn hành vi. Decision Criteria: có nguồn kiểm tra được, authority phù hợp, dữ liệu bắt buộc xác định được, và expected result kiểm thử được. Decision: chọn phương án 2 vì seed chỉ nêu Luật An toàn thực phẩm là bối cảnh traceability/recall và yêu cầu domain-owner, legal verification; seed không cung cấp điều khoản để suy ra điều kiện chặn xuất hàng. Authority: Legal Owner và domain owner xác minh nghĩa vụ; Business Owner quyết định quy tắc nghiệp vụ; BA không thay thế các thẩm quyền này. Artifact: Functional Specification giữ nhãn Verification required, liên kết CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY khi nội dung canonical tồn tại. Consequence if Wrong: phương án 1 có thể biến giả định thành chặn giao dịch không có căn cứ; phương án 3 tạo hành vi không có test basis.

Senior Lens

Entry gate không phải cuộc họp đã diễn ra. Entry gate là bằng chứng tối thiểu cho phép giai đoạn sau làm việc mà không đoán. Exit gate không phải “tài liệu đã viết xong”; exit gate là trạng thái trong đó người làm giai đoạn sau có thể đối chiếu đầu vào, phát hiện sai khác và trả lại đúng điểm cần làm rõ.

Functional Specification chỉ đi từ Analysis sang Delivery khi câu mô tả được ba phần: điều kiện kích hoạt, hành vi hệ thống, kết quả quan sát được. Nếu thiếu một phần, Delivery sẽ tự lấp chỗ trống; suy luận này có cơ sở vì mã nguồn và test cần điều kiện đầu vào cùng kết quả mong đợi để quyết định xử lý đúng hay sai.

Quick Reference

Câu hỏi gate	Đạt khi	Không đạt khi
Có được viết requirement bắt buộc chưa?	Có verified fact hoặc decision được ghi nhận với authority phù hợp.	Chỉ có ý kiến, giả định, hoặc claim cần xác minh.
Có được chuyển sang Delivery chưa?	Hành vi, ngoại lệ, dữ liệu liên quan và acceptance criteria đủ để đối chiếu.	Còn câu “hệ thống xử lý phù hợp” hoặc “theo quy định” không có tiêu chí kiểm tra.
Có được đóng Testing chưa?	Test result đối chiếu với cùng phiên bản đặc tả và sai khác được ghi nhận.	Chỉ có xác nhận miệng hoặc test không có expected result.
Có được đổi đặc tả sau Release không?	Có thay đổi được ghi nhận và quay lại lifecycle phù hợp.	Sửa nội dung để khớp hành vi vận hành mà không có truy vết.

Core

Functional Specification (đặc tả chức năng) là điểm bàn giao có kiểm soát giữa nhu cầu nghiệp vụ và cách hệ thống phải hoạt động. Với Nova Foods Trading & Manufacturing là case mô phỏng, BA không tự quyết định quy tắc kinh doanh, thiết kế kỹ thuật, kiểm thử đạt hay phát hành. BA làm rõ, ghi nguồn, liên kết ID, chuyển đúng người có thẩm quyền.

Hướng bàn giao	Owner gửi	Owner nhận	Artifact/handoff	Giới hạn thẩm quyền BA	Escalation
Upstream: Discovery	Business Owner, SME nghiệp vụ	BA	Nhu cầu, vấn đề, mục tiêu, giả định	Không xác nhận nhu cầu là quyết định vận hành	Mục tiêu mâu thuẫn giữa Sales, Kho, Sản xuất
Upstream: Analysis	Business Owner, SME, Data Owner	BA	Quy tắc, dữ liệu, ngoại lệ, thuật ngữ	Không tự tạo hoặc sửa quy tắc canonical	Mâu thuẫn với CANONICAL_BUSINESS_RULES hoặc CANONICAL_DATA_DICTIONARY
Downstream: Delivery	BA	Solution Architect, Developer	Functional Specification, acceptance criteria, traceability	Không chọn kiến trúc, API, DB schema, kiểm soát bảo mật	Yêu cầu đòi quyết định kiến trúc, tích hợp, phân quyền
Downstream: Testing	BA	QA Lead, Tester	Test basis: hành vi, quy tắc, tiêu chí chấp nhận	Không xác nhận test pass hay chất lượng phát hành	Tiêu chí không kiểm thử được hoặc test phát hiện mâu thuẫn
Downstream: Release/Operations	BA, Delivery, QA	Release Manager, Operations Owner	Thay đổi được truy vết, ảnh hưởng vận hành	Không cấp quyền production, không xác nhận sẵn sàng vận hành	Ảnh hưởng dữ liệu cá nhân, kế toán, hóa đơn, an toàn thực phẩm

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

flowchart TB
    BO[Business Owner / SME]
    DO[Data Owner]
    CBR[CANONICAL_BUSINESS_RULES]
    CDD[CANONICAL_DATA_DICTIONARY]
    BA[Business Analyst]
    ARCH[Solution Architect]
    DEV[Developer]
    QA[QA Lead / Tester]
    LEGAL[Legal]
    ACC[Accounting]
    SEC[Security]
    RM[Release Manager]
    OPS[Operations Owner]
    FOOD[Owner an toàn thực phẩm]
    PROD[Sẵn sàng phát hành và vận hành]

    BO -->|Nhu cầu, mục tiêu, quy tắc, ngoại lệ| BA
    DO -->|Định nghĩa dữ liệu| BA
    CBR -->|Nguồn quy tắc canonical| BA
    CDD -->|Nguồn dữ liệu canonical| BA

    BA -->|Functional Specification, traceability| ARCH
    BA -->|Functional Specification, acceptance criteria| DEV
    BA -->|Test basis: hành vi, quy tắc, tiêu chí| QA
    QA -->|Defect, ambiguity, tiêu chí không kiểm thử được, mâu thuẫn test| BA

    BA -->|Mục tiêu mâu thuẫn;<br/>quy tắc xung đột canonical| BO
    BA -->|Dữ liệu xung đột canonical| DO
    BA -->|Dữ liệu cá nhân hoặc pháp lý| LEGAL
    BA -->|Kế toán hoặc hóa đơn| ACC
    BA -->|Bảo mật, phân quyền hoặc quyền production| SEC
    BA -->|Quyết định kiến trúc hoặc tích hợp| ARCH
    BA -->|Ảnh hưởng an toàn thực phẩm| FOOD

    BO -->|Quyết định nghiệp vụ| BA
    DO -->|Quyết định dữ liệu| BA
    LEGAL -->|Quyết định dữ liệu cá nhân hoặc pháp lý| BA
    ACC -->|Quyết định kế toán hoặc hóa đơn| BA
    SEC -->|Quyết định bảo mật hoặc phân quyền| BA
    ARCH -->|Quyết định kiến trúc| BA
    FOOD -->|Quyết định an toàn thực phẩm| BA

    BA -->|Thay đổi có truy vết,<br/>ảnh hưởng vận hành| RM
    DEV -->|Bàn giao delivery có truy vết| RM
    QA -->|Kết quả kiểm thử, thay đổi có truy vết| RM
    BA -->|Thay đổi có truy vết,<br/>ảnh hưởng vận hành| OPS
    DEV -->|Bàn giao delivery có truy vết| OPS
    QA -->|Kết quả kiểm thử, thay đổi có truy vết| OPS

    RM -->|Quyết định phát hành| PROD
    OPS -->|Xác nhận sẵn sàng vận hành| PROD

Applied

Facts: Nova Foods mô phỏng cần hiển thị trạng thái lô hàng trong màn hình xuất kho. Dữ liệu tổng hợp có mã lô LOT-SYN-20260807-01. BA nhận mô tả “chỉ xuất lô đạt chất lượng”.

Current Behavior: Mô tả chưa nêu “đạt chất lượng” do ai xác nhận, trạng thái nào là hợp lệ, hay xử lý khi trạng thái thay đổi sau lúc tạo phiếu.

Underlying Need: Developer cần hành vi xác định. QA cần điều kiện quan sát được. Operations cần biết ai xử lý ngoại lệ. Bằng chứng: cùng câu mô tả có thể tạo nhiều cách hiểu, nên không đủ làm test basis.

Options: (1) BA tự ghi trạng thái APPROVED; (2) BA ghi trạng thái như giả định; (3) BA chuyển câu hỏi cho Quality Owner và giữ nhãn Verification required.

Decision Criteria: Quyết định phải thuộc đúng owner; phải liên kết nguồn canonical; phải kiểm thử được; không được biến giả định thành quy tắc vận hành.

Decision: Chọn phương án (3). Functional Specification ghi: “Trạng thái chất lượng hợp lệ: Verification required từ Quality Owner; không suy diễn từ mô tả hiện có.”

Authority: Quality Owner xác nhận ý nghĩa và chuyển đổi trạng thái. Business Owner quyết định chấp nhận ảnh hưởng quy trình. BA duy trì traceability. Architect quyết định cách trạng thái được tích hợp. QA Lead quyết định phạm vi kiểm thử.

Artifact: Ghi liên kết tới /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md nếu ID đã tồn tại. Nếu chưa có ID canonical, không tự đặt ID như quyết định nghiệp vụ; escalation theo TRACEABILITY_ID_REGISTRY.

Consequence if Wrong: Developer có thể cho xuất lô sai trạng thái; QA không có oracle kiểm thử; Operations xử lý khác nhau. Đây là rủi ro mô phỏng, không kết luận về vận hành thật Nova Foods.

Senior Lens

Escalation không phải chuyển việc. BA phải chuyển gói vấn đề đủ quyết định: fact, nguồn, câu hỏi, lựa chọn, ảnh hưởng, owner cần quyết. Không gửi câu hỏi mơ hồ như “xác nhận giúp”. Ví dụ đúng: “Quality Owner cần xác nhận tập trạng thái được phép xuất kho và owner của chuyển đổi trạng thái; hiện chưa có nguồn canonical. Ảnh hưởng: FS, test basis, phân quyền.”

Ranh giới thẩm quyền giữ corpus an toàn. Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì metadata, traceability, trạng thái IN_REVIEW, version v0.9.0 và nội dung học liệu ngày 2026-08-07 theo Asia/Ho_Chi_Minh. Vai trò này không tạo baseline, approval, legal sign-off, accounting decision, security sign-off hay production authorization.

Quick Reference

Tình huống	BA làm	BA không làm	Owner escalation
Quy tắc nghiệp vụ thiếu	Ghi câu hỏi, bằng chứng, ảnh hưởng	Tự điền giá trị “hợp lý”	Business Owner hoặc SME
Dữ liệu thiếu định nghĩa	So khớp CANONICAL_DATA_DICTIONARY	Tự định nghĩa nghĩa nghiệp vụ	Data Owner
Ảnh hưởng kế toán, thuế, hóa đơn	Gắn Verification required	Diễn giải luật hoặc chốt hạch toán	Accounting Owner, Legal Owner
Dữ liệu cá nhân hoặc phân quyền	Nêu luồng dữ liệu, rủi ro, phạm vi	Xác nhận tuân thủ hoặc chọn kiểm soát	Security Owner, Legal Owner
API, DB, tích hợp	Nêu hành vi cần có	Chọn giải pháp kỹ thuật	Solution Architect
Test fail do yêu cầu mơ hồ	Làm rõ và cập nhật traceability	Tuyên bố defect là do code	Business Owner, QA Lead, Architect theo nguyên nhân

Core

Sơ đồ vòng đời giúp đọc nhanh vị trí Functional Specification: tài liệu nối nhu cầu đã phân tích với build, test, release và vận hành. Nova Foods Trading & Manufacturing là case mô phỏng; mọi dữ liệu là tổng hợp. Sơ đồ không xác nhận quy trình ERP thực, baseline hay phê duyệt.

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

flowchart TB
    D[Discovery<br/>Nhu cầu và vấn đề] --> C1{Kiểm tra: phạm vi đủ rõ?}
    C1 -- Không --> D
    C1 -- Có --> A[Analysis<br/>Yêu cầu, quy tắc, dữ liệu]

    A --> C2{Kiểm tra: requirement đủ kiểm chứng?}
    C2 -- Không --> A
    C2 -- Có --> F[Functional Specification<br/>Hành vi hệ thống cần xây]

    F --> C3{Kiểm tra: đặc tả nhất quán và truy vết được?}
    C3 -- Không --> F
    C3 -- Có --> DL[Delivery<br/>Cấu hình hoặc phát triển]

    DL --> T[Testing<br/>Đối chiếu test basis]
    T --> C4{Kiểm tra: kết quả test đạt tiêu chí?}
    C4 -- Có --> R[Release<br/>Đưa thay đổi theo kiểm soát]
    C4 -- Không --> C5{Phân loại nguyên nhân}
    C5 -- Lỗi cấu hình hoặc phát triển --> DL
    C5 -- Sai hoặc thiếu đặc tả --> F
    C5 -- Test case, dữ liệu hoặc môi trường kiểm thử --> TA[Xử lý tài sản hoặc môi trường test]
    TA --> T

    R --> O[Operations<br/>Vận hành, sự cố, phản hồi]
    O -- Phản hồi hoặc nhu cầu mới --> D

Applied

Mục	Nội dung mô phỏng
Facts	Nova Foods cần ERP chặn tạo phiếu xuất kho khi số lượng yêu cầu lớn hơn tồn khả dụng.
Current Behavior	Nhu cầu mới chỉ là mô tả vấn đề; Delivery chưa có hành vi hệ thống đủ chi tiết để cấu hình hoặc lập trình.
Underlying Need	Functional Specification phải đứng sau Analysis vì điều kiện chặn cần quy tắc, dữ liệu tồn khả dụng và thông báo lỗi xác định trước.
Options	Viết đặc tả ngay từ Discovery; hoặc hoàn tất Analysis rồi lập Functional Specification.
Decision Criteria	Chọn cách giữ truy vết từ nhu cầu đến test basis, giảm suy diễn kỹ thuật và cho phép test kiểm tra kết quả quan sát được.
Decision	Đặt Functional Specification giữa Analysis và Delivery, như sơ đồ.
Authority	Đây là quyết định học liệu IN_REVIEW, v0.9.0, ngày 2026-08-07; không ghi nhận phê duyệt hay baseline.
Artifact	/02-handbook/09-functional-specification-writing.md; nguồn quản trị: CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY.
Consequence if Wrong	Đặc tả lập quá sớm có thể biến giả định thành yêu cầu; lập quá muộn làm Delivery và Testing tự suy diễn khác nhau.

Senior Lens

Mũi tên quay lại không phải lỗi. Nó chỉ ra bằng chứng mới: test phát hiện hành vi xây sai đặc tả, hoặc Operations phát hiện nhu cầu chưa được mô hình hóa. Sơ đồ giữ Functional Specification là điểm kiểm soát trung tâm, không thay thế catalog quy tắc hoặc từ điển dữ liệu canonical. Khi có tác động pháp lý, kế toán, an toàn thực phẩm, riêng tư, bảo mật hoặc kiến trúc, giữ nhãn Verification required và chuyển kết luận cho owner có thẩm quyền.

Quick Reference

Ký hiệu	Nghĩa
Hình chữ nhật	Giai đoạn hoặc artifact chính
Hình thoi Gate	Điểm quyết định: chỉ đi tiếp khi điều kiện đủ
Mũi tên quay lại	Cần sửa artifact trước, không bỏ qua kiểm soát
Functional Specification	Đặc tả chức năng: mô tả hệ thống phải làm gì để đáp ứng yêu cầu đã phân tích

4. Input c?n thi?t

Core

Functional Specification cần đầu vào trước khi viết. Đầu vào là kiến thức, bằng chứng và artifact nguồn giúp BA mô tả hệ thống phải làm gì. Không có đầu vào, câu viết trong đặc tả chỉ là giả định. Với Nova Foods Trading & Manufacturing, mọi ví dụ là mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp.

Người mới không cần biết phần mềm ERP trước. ERP là hệ thống gom dữ liệu và quy trình nghiệp vụ như mua hàng, kho, sản xuất, bán hàng, kế toán vào cùng môi trường. BA không bắt đầu bằng màn hình ERP. BA bắt đầu bằng vấn đề nghiệp vụ, hành vi hiện tại, quy tắc, dữ liệu và người chịu trách nhiệm cung cấp bằng chứng.

Bằng chứng là thứ cho phép người đọc kiểm tra lại nhận định. Ví dụ, câu “hệ thống phải chặn xuất kho khi lô hàng hết hạn” cần liên kết đến nhu cầu nghiệp vụ, quy tắc, định nghĩa dữ liệu lô hàng và nguồn có thẩm quyền. Không dùng lời kể không ghi nhận làm nguồn chân lý.

Canonical ID là định danh chuẩn, ổn định, dùng nguyên chuỗi giữa các artifact. ID giúp liên kết không đổi khi tiêu đề, đoạn văn hoặc vị trí bảng thay đổi. Ví dụ CANONICAL_BUSINESS_RULES luôn chỉ catalog quy tắc nghiệp vụ; không đổi thành “file rules” hoặc “danh sách luật”.

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

flowchart TB
    A[Kiến thức nghiệp vụ] --> E[Functional Specification]
    B[Bằng chứng đã ghi nhận] --> E
    C[Artifact nguồn canonical] -->|được định danh bằng| D[Canonical ID ổn định]
    D -->|duy trì liên kết truy vết cho| E
    E --> F[Hành vi chức năng có truy vết về nhu cầu, quy tắc, định nghĩa dữ liệu và nguồn có thẩm quyền]

Applied

Facts: Nova Foods là case study mô phỏng. Corpus đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Không có baseline hay phê duyệt được ghi nhận.

Current Behavior: Người viết mới có thể đọc một mô tả quy trình rồi tự đặt tên quy tắc, trường dữ liệu hoặc ID mới trong Functional Specification.

Underlying Need: Đặc tả cần dùng đúng nguồn đã kiểm soát để người đọc truy ngược từ hành vi hệ thống về artifact gốc.

Options: Dùng ghi chú tự do không ID; hoặc lập danh mục đầu vào với artifact ID, đường dẫn canonical và mục đích dùng.

Decision Criteria: Chọn cách giữ nguyên ID, không biến kế hoạch học liệu thành yêu cầu vận hành, và phân biệt rõ nguồn quản trị với nguồn nội dung nghiệp vụ.

Decision: Lập inventory đầu vào trước khi viết từng hành vi chức năng. Chỉ tham chiếu artifact bằng ID và đường dẫn canonical đã có.

Authority: Đây là hướng dẫn học liệu IN_REVIEW, v0.9.0. Không phải phê duyệt, baseline, quyết định ERP thực tế hay kết luận pháp lý.

Artifact: /02-handbook/09-functional-specification-writing.md.

Consequence if Wrong: ID bị đổi hoặc nguồn bị nhầm làm Testing, Delivery và reviewer không truy được căn cứ; giả định có thể bị hiểu nhầm thành quy tắc Nova Foods.

Nhóm đầu vào	Cần biết hoặc cần có	Artifact nguồn canonical	Canonical ID phải giữ nguyên	Vai trò trong Functional Specification
Bối cảnh học liệu	Nova Foods là mô phỏng giáo dục; dữ liệu tổng hợp; Việt Nam, vi-VN, Asia/Ho_Chi_Minh, VND	/01-curriculum/CHAPTER_MANIFEST.md	CHAPTER_MANIFEST	Giới hạn ngôn ngữ, dữ liệu và cách diễn đạt
Cấu trúc chapter	Chapter này có 12 section; section hiện tại là đầu vào	/01-curriculum/CHAPTER_MANIFEST.md	CHAPTER_MANIFEST	Không viết lẫn nội dung ngoài section
Quy tắc nghiệp vụ	Quy tắc phải có catalog riêng; đặc tả không tự tạo quy tắc	/01-curriculum/CANONICAL_BUSINESS_RULES.md	CANONICAL_BUSINESS_RULES	Liên kết hành vi chức năng với quy tắc
Dữ liệu logic	Tên thực thể, thuộc tính, định nghĩa dữ liệu cần nguồn riêng	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	CANONICAL_DATA_DICTIONARY	Giữ nghĩa dữ liệu nhất quán
Định danh truy vết	ID requirement, rule, data và artifact phải theo registry	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	TRACEABILITY_ID_REGISTRY	Tránh đặt ID trùng, đổi tên hoặc không truy vết
Chuẩn BA	Thuật ngữ và phạm vi công việc BA	https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/	BABOK Guide	Dùng thuật ngữ BA; không bịa tham chiếu trang hay điều khoản
Chuẩn yêu cầu	Khung tư duy về yêu cầu và đặc tả	https://www.iso.org/standard/72089.html	ISO/IEC/IEEE 29148	Dùng thông tin thư mục và abstract công khai; điều khoản chi tiết cần kiểm tra bản được cấp phép
Nguồn pháp lý có thể tác động	Riêng tư, kế toán, hóa đơn, an toàn thực phẩm	Các URL chính thức trong /00-research/00_SOURCE_MAP.md	00_SOURCE_MAP	Chỉ nhận diện nguồn; mọi diễn giải chi tiết giữ nhãn Verification required

Senior Lens

Phân biệt ba thứ. Kiến thức là hiểu biết để đặt câu hỏi đúng. Bằng chứng là tài liệu hoặc ghi nhận cho phép kiểm tra câu trả lời. Artifact nguồn là tệp hoặc URL được kiểm soát chứa bằng chứng. Canonical ID là khóa tham chiếu bền vững giữa các artifact. Cầu suy luận là: artifact nguồn chứa thông tin; BA trích đúng ID; Functional Specification mô tả hành vi dựa trên thông tin đó; reviewer truy ngược được hành vi về nguồn.

Không dùng CANONICAL_BUSINESS_RULES như bằng chứng rằng một quy tắc cụ thể đã đúng. ID này chỉ định danh catalog. Muốn khẳng định nội dung quy tắc, cần bản ghi quy tắc cụ thể trong catalog, bằng chứng liên quan và thẩm quyền phù hợp. Cùng nguyên tắc, tên Nova Foods không chứng minh doanh nghiệp thật, cấu hình ERP thật hay tuân thủ pháp lý.

Quick Reference

Thuật ngữ	Nghĩa thực hành
Input	Thông tin cần có trước khi viết đặc tả
Evidence	Bằng chứng kiểm tra lại được
Source artifact	Tệp hoặc nguồn gốc chứa bằng chứng
Canonical	Chuẩn duy nhất phải dùng nhất quán
Canonical ID	Mã chuẩn ổn định để liên kết artifact
Traceability	Khả năng lần từ hành vi hệ thống về nguồn gốc
Verification required	Chưa đủ căn cứ hoặc chưa có xác nhận từ owner có thẩm quyền

Core

Input cho Functional Specification là bằng chứng dùng để viết hành vi hệ thống, không phải ý kiến chưa kiểm tra. Mỗi input phải có nguồn, owner, thời điểm hiệu lực, định danh ổn định và trạng thái kiểm tra. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp, IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND.

Kiểm tra chất lượng	Điều kiện đạt	Lý do	Không đạt
Nhận diện	Có Artifact ID, đường dẫn canonical, version, status	Truy lại đúng nguồn	Không dùng làm căn cứ
Nguồn gốc	Phân loại nguồn rõ	Phân biệt fact, giả định, diễn giải	Gắn Verification required
Toàn vẹn	Nội dung không mâu thuẫn artifact canonical	Một yêu cầu không có hai sự thật	Dừng viết phần bị ảnh hưởng
Tươi mới	Ngày cập nhật và thời điểm truy cập phù hợp quyết định	Quy định và quy trình có thể đổi	Xác minh lại owner
Thẩm quyền	Owner nguồn có quyền xác nhận loại nội dung	BA không thay Business Owner, Legal, Accounting, Architect	Escalation
Truy vết	Liên kết được ID nguồn đến requirement hoặc rule	Tester, developer kiểm chứng được	Không tạo requirement

Applied

Facts: CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY là artifact canonical trong /01-curriculum/; đều IN_REVIEW, v0.9.0. Evidence: metadata upstream ghi đúng ID, đường dẫn, owner, ngày 2026-08-07.

Current Behavior: người viết có thể đọc artifact kế hoạch rồi diễn đạt thành rule ERP chắc chắn. Evidence: IN_REVIEW chỉ cho biết đang xem xét, không phải baseline hay approval.

Underlying Need: Functional Specification cần phân biệt nguồn chính thức, nguồn tham khảo, giả định dự án và điểm phải xác minh trước khi mô tả hành vi ERP.

Phân loại nguồn	Dùng được cho	Không được suy ra	Owner xác nhận
Canonical internal artifact	ID, filename, status, dependency corpus	Quy tắc vận hành Nova Foods đã hiệu lực	Principal IT Business Analyst / Technical Curriculum Author
Primary official source	Thuật ngữ, trạng thái thư mục, ranh giới nguồn	Điều khoản chi tiết chưa kiểm licensed text	Cơ quan phát hành hoặc owner chuyên môn
Legal official source	Bối cảnh pháp lý và điểm cần kiểm tra	Nghĩa vụ cấu hình ERP cụ thể	Legal Owner
Project assumption	Phương án học liệu có nhãn	Fact, policy, compliance	Business Owner và owner liên quan
Verification required	Câu hỏi mở ảnh hưởng requirement	Quyết định cuối	Vai trò có thẩm quyền

Options: dùng mọi input như fact; chỉ dùng nguồn canonical; hoặc phân loại từng input rồi đặt cổng dừng.

Decision Criteria: giữ traceability; không tạo approval ngầm định; không biến nguồn pháp lý thành diễn giải pháp lý; cho phép người đọc biết ai phải trả lời.

Decision: chọn phân loại từng input và cổng dừng. Một input chỉ thành căn cứ viết requirement khi đạt đủ nhận diện, nguồn gốc, freshness, owner và truy vết.

Authority: BA duy trì log và nêu mâu thuẫn. Business Owner xác nhận nhu cầu nghiệp vụ. Legal Owner, Accounting Owner, Security, Architect, QA xác nhận phần thuộc thẩm quyền. Không vai trò nào được suy ra từ IN_REVIEW.

Artifact: ghi vào input register của Functional Specification: Source ID, Source classification, Fresh as of, Owner, Quality result, Verification status, Stop condition.

Consequence if Wrong: requirement có thể dựa trên rule cũ, sai owner hoặc giả định không được nêu. Development và test sẽ xây đúng theo tài liệu nhưng sai nhu cầu hoặc vượt thẩm quyền.

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

flowchart TB
    A[Nhận input] --> B{Input register đủ:<br/>Source ID, classification, origin/path,<br/>Fresh as of, owner, quality,<br/>verification, traceability, stop condition?}

    B -- Không --> R[BA duy trì hoặc cập nhật input register]
    R --> B
    B -- Có --> C{Classification và origin/path<br/>phù hợp loại nguồn?}

    C -- Không --> E[BA nêu điểm chưa rõ<br/>và escalation đúng owner]
    C -- Có --> D{Fresh as of còn hiệu lực<br/>và owner có thẩm quyền?}

    D -- Không --> E
    D -- Có --> F{Quality result đạt;<br/>verification status và stop condition<br/>cho phép dùng làm evidence?}

    F -- Không --> E
    F -- Có --> G{Traceability đến requirement<br/>và nguồn còn đủ?}

    G -- Không --> R
    G -- Có --> H{Có mâu thuẫn nguồn ảnh hưởng requirement<br/>hoặc vượt thẩm quyền?}

    H -- Có --> E
    H -- Không --> I[Đủ điều kiện làm evidence<br/>và ghi traceability]

    E --> X[Dừng phần bị ảnh hưởng]
    X --> V[Owner có thẩm quyền xác minh hoặc cập nhật:<br/>Business Owner;<br/>Legal, Accounting, Security, Architect hoặc QA<br/>khi thuộc phạm vi]
    V --> B

Senior Lens

Freshness không có một số ngày cố định cho mọi input. Freshness phải khớp rủi ro thay đổi. Metadata corpus tại 2026-08-07 dùng được để tham chiếu trạng thái artifact cùng ngày. Nguồn pháp lý phải kiểm lại trước khi dùng để suy ra yêu cầu hệ thống vì seed nêu rõ cần Legal Owner xác minh. Quy trình nội bộ không có ngày hiệu lực hoặc owner không đủ thẩm quyền là input chưa đạt, dù nội dung nghe hợp lý.

Điều kiện dừng áp dụng ngay: ID chưa đăng ký; filename hoặc status mâu thuẫn nguồn canonical; nguồn IN_REVIEW bị gọi là approved hay baselined; legal, accounting, tax, privacy, food-safety, security hoặc architecture bị diễn đạt như quyết định đã chốt; input thiếu owner; hoặc hai nguồn cho hai hành vi khác nhau. Dừng chỉ phần bị ảnh hưởng, giữ evidence và câu hỏi xác minh; không tự chọn phương án.

Quick Reference

Trường input register	Giá trị ghi nhận tối thiểu
Source ID	CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, hoặc CANONICAL_DATA_DICTIONARY
Canonical path	Đường dẫn đúng từ artifact nguồn, ví dụ /01-curriculum/CHAPTER_MANIFEST.md
Classification	Canonical internal artifact, primary official source, legal official source, project assumption, hoặc Verification required
Fresh as of	2026-08-07, theo Asia/Ho_Chi_Minh, hoặc ngày hiệu lực nguồn
Owner	Vai trò có thẩm quyền xác nhận nội dung
Status	IN_REVIEW nếu nguồn ghi như vậy; không đổi thành approved
Stop condition	Mâu thuẫn, thiếu owner, quá hạn, vượt thẩm quyền, hoặc thiếu traceability

Core

Bảng dưới là inventory đầu vào cho Functional Specification của Nova Foods Trading & Manufacturing, case study mô phỏng, chỉ dùng dữ liệu tổng hợp. Mỗi dòng giữ nguyên Artifact ID và đường dẫn canonical. Giá trị nghiệp vụ chỉ là dữ liệu học liệu, không xác nhận cấu hình ERP, nghĩa vụ pháp lý, quyết định kế toán, hay vận hành thực tế.

Đầu vào	Artifact ID / nguồn canonical	Tệp hoặc URL	Phân loại nguồn	Giá trị tổng hợp dùng trong case	Trạng thái xác minh	Mục chưa giải quyết
Quy tắc quản trị corpus	00_SOURCE_MAP	/00-research/00_SOURCE_MAP.md	Nguồn nội bộ kiểm soát; primary-source map	Status IN_REVIEW; Version v0.9.0; ngày 2026-08-07; vi-VN; Asia/Ho_Chi_Minh; VND	Đã ghi nhận trong artifact	Không có baseline reference
Cấu trúc học liệu	01_CURRICULUM_ARCHITECTURE	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Nguồn nội bộ kiểm soát; curriculum architecture	Nova Foods là case study giáo dục mô phỏng	Đã ghi nhận trong artifact	Không suy diễn thành yêu cầu ERP production
Danh mục chapter	CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Nguồn nội bộ kiểm soát; manifest	Chapter 09 Functional Specification Writing; section 4. Input c?n thi?t	Đã ghi nhận trong artifact	Không có approval reference
Danh mục ID	TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Nguồn nội bộ kiểm soát; registry	ID phải giữ nguyên dạng canonical khi liên kết artifact	Đã ghi nhận trong artifact	VERIFICATION REQUIRED: kiểm tra ID nghiệp vụ cụ thể trước khi đưa vào Functional Specification
Catalog quy tắc	CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Nguồn nội bộ kiểm soát; planned rule catalog	Chưa được baseline; không phải quy tắc vận hành Nova Foods	Đã ghi nhận trong artifact	VERIFICATION REQUIRED: Business Owner xác nhận quy tắc nào đủ điều kiện thành requirement
Từ điển dữ liệu	CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Nguồn nội bộ kiểm soát; planned logical data dictionary	Chỉ định nghĩa dữ liệu logic dự kiến, không phải schema triển khai	Đã ghi nhận trong artifact	VERIFICATION REQUIRED: Architect và Data Owner xác nhận field, kiểu dữ liệu, chủ sở hữu dữ liệu
BABOK Guide	Không có Artifact ID nội bộ	https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/	Nguồn ngoài; primary professional reference	BABOK Guide Version 3; dùng thuật ngữ và thực hành BA	Đã truy cập 2026-08-07	Không trích page hoặc clause chưa có licensed-text verification
ISO/IEC/IEEE 29148	Không có Artifact ID nội bộ	https://www.iso.org/standard/72089.html	Nguồn ngoài; standard bibliographic source	29148:2018, Edition 2; trạng thái marked to be revised in 2026	Đã truy cập 2026-08-07	VERIFICATION REQUIRED: clause chính xác cần licensed text
Luật An toàn thực phẩm	Không có Artifact ID nội bộ	https://vanban.chinhphu.vn/?docid=96032&pageid=27160	Nguồn ngoài; official legal source	Luật 55/2010/QH12; chỉ tạo bối cảnh truy xuất và thu hồi	Đã truy cập 2026-08-07	VERIFICATION REQUIRED: Legal Owner và domain owner xác nhận tác động requirement
Luật Kế toán	Không có Artifact ID nội bộ	https://vanban.chinhphu.vn/?docid=183198&pageid=27160	Nguồn ngoài; official legal source	Luật 88/2015/QH13; không tự diễn giải hạch toán	Đã truy cập 2026-08-07	VERIFICATION REQUIRED: Accounting Owner xác nhận nghiệp vụ và lưu trữ chứng từ

Applied

Facts: Nova Foods mô phỏng cần viết Functional Specification cho luồng ghi nhận lô hàng nguyên liệu. Bằng chứng hiện có là CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, và Luật An toàn thực phẩm.

Current Behavior: Không có rule Nova Foods đã baseline về thời điểm tạo mã lô, đơn vị sở hữu mã lô, hoặc thời hạn lưu truy xuất.

Underlying Need: Functional Specification cần input đủ tin cậy để mô tả hành vi hệ thống mà không biến giả định học liệu thành cam kết vận hành.

Options: Ghi rule cụ thể từ suy đoán; ghi rule như project assumption; dừng phần rule và gắn VERIFICATION REQUIRED.

Decision Criteria: Chỉ ghi rule bắt buộc khi có artifact canonical đủ nội dung, nguồn còn hiệu lực, và xác nhận từ đúng thẩm quyền.

Decision: Giữ yêu cầu truy xuất lô ở mức nhu cầu cần xác minh; không tạo business rule, data field, hay thời hạn lưu giả định.

Authority: Legal Owner xác nhận diễn giải pháp lý; domain owner xác nhận quy trình thực phẩm; Business Owner xác nhận nhu cầu; Architect xác nhận thiết kế; Accounting Owner xác nhận dữ liệu kế toán.

Artifact: /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, 00_SOURCE_MAP.

Consequence if Wrong: Rule sai có thể dẫn tới thiết kế dữ liệu sai, test sai, truy vết sai, hoặc diễn đạt sai nghĩa vụ pháp lý.

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

flowchart TB
    A["Artifact canonical:<br/>Business Rules, Data Dictionary"] --> D["Bảng input Functional Specification"]
    B["Nguồn pháp lý còn hiệu lực"] --> D
    C["00_SOURCE_MAP:<br/>truy vết và kiểm tra hiệu lực nguồn"] --> D

    D --> E{"Đủ nội dung,<br/>nguồn còn hiệu lực,<br/>đúng thẩm quyền?"}
    E -- "Có" --> F["Dùng làm input có truy vết"]
    E -- "Không" --> G["Gắn VERIFICATION REQUIRED"]

    G --> H{"Loại nội dung cần xác minh?"}
    H -- "Diễn giải pháp lý" --> I["Legal Owner xác nhận"]
    H -- "Quy trình thực phẩm" --> J["Domain Owner xác nhận"]
    H -- "Nhu cầu" --> K["Business Owner xác nhận"]
    H -- "Thiết kế" --> L["Architect xác nhận"]
    H -- "Dữ liệu kế toán" --> M["Accounting Owner xác nhận"]

    I --> Q{"Được xác nhận?"}
    J --> Q
    K --> Q
    L --> Q
    M --> Q

    Q -- "Có" --> D
    Q -- "Không" --> N["Chờ xác minh:<br/>không tạo business rule, data field,<br/>hoặc thời hạn lưu giả định"]

    N --> P{"Vẫn tạo rule giả định?"}
    P -- "Không" --> R["Giữ VERIFICATION REQUIRED<br/>cho đến khi có xác nhận"]
    P -- "Có" --> O["Rủi ro: thiết kế dữ liệu sai, test sai,<br/>truy vết sai, hoặc diễn giải sai<br/>nghĩa vụ pháp lý"]

Senior Lens

Bảng input không phải danh sách tài liệu để tham khảo. Nó là ranh giới bằng chứng: mỗi requirement sau này phải chỉ được suy ra từ nguồn xác định, trạng thái xác minh rõ, và thẩm quyền phù hợp. IN_REVIEW cho biết artifact còn xem xét; không nghĩa là approved, baselined, compliant, hay production-ready.

Quick Reference

Nhãn	Nghĩa sử dụng
Đã ghi nhận trong artifact	Nội dung tồn tại trong nguồn canonical, chưa tự động thành approval hoặc baseline
Đã truy cập 2026-08-07	URL được kiểm tra vào ngày corpus quy định
VERIFICATION REQUIRED	Chưa đủ bằng chứng hoặc chưa có xác nhận đúng thẩm quyền; không suy diễn thành requirement bắt buộc
Project assumption	Giả định phục vụ học liệu; không phải fact vận hành Nova Foods

5. Step-by-step BA Activities

Core

Functional Specification là đặc tả chức năng: tài liệu chuyển nhu cầu nghiệp vụ đã có bằng chứng thành hành vi hệ thống có thể xây dựng, kiểm thử và truy vết. BA không tự tạo rule. BA nối nguồn canonical, quyết định đúng thẩm quyền, và mô tả tác động chức năng.

Applied

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục. Mọi dữ liệu là dữ liệu tổng hợp, bối cảnh vi-VN, Asia/Ho_Chi_Minh, VND. Trạng thái corpus hiện hành IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không phải baseline, approval, xác nhận tuân thủ, hay chỉ dẫn production.

1. Actor: BA. Action: Mở phạm vi chức năng và lập danh sách input. Object: Nhu cầu, rule, dữ liệu, nguồn ngoài, dependency từ /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Evidence produced: Bảng input ghi nguồn, trạng thái, owner và điểm chưa xác minh. Decision rule: Chỉ dùng nội dung có nguồn xác định; nội dung thiếu nguồn gắn VERIFICATION REQUIRED. Quality gate: Mỗi input có đường dẫn hoặc URL canonical, ngày truy cập 2026-08-07 nếu là nguồn ngoài. Escalation route: Mâu thuẫn rule chuyển Business Owner; diễn giải pháp lý chuyển Legal Owner; kế toán chuyển Accounting Owner; bảo mật chuyển Security; kiến trúc chuyển Architect.

2. Actor: BA. Action: Tách nhu cầu thành mục tiêu, trigger, actor, precondition, luồng chính, ngoại lệ và kết quả. Object: Một hành vi ERP mô phỏng Nova Foods. Evidence produced: Bản phân rã chức năng liên kết từng thành phần với input. Decision rule: Mỗi hành vi phải trả lời ai khởi tạo, hệ thống làm gì, dữ liệu nào đổi, khi nào từ chối. Quality gate: Không có câu “hệ thống xử lý phù hợp”; mỗi điều kiện phải quan sát hoặc kiểm thử được. Escalation route: Trigger hoặc ngoại lệ chưa rõ chuyển domain owner; tác động liên mô-đun chuyển Architect.

3. Actor: BA. Action: Viết requirement chức năng và acceptance criteria, tức tiêu chí chấp nhận dùng để kiểm tra kết quả. Object: Hành vi đã phân rã. Evidence produced: Requirement có nguồn, điều kiện, hành động, kết quả, lỗi và truy vết. Decision rule: Một requirement chỉ mô tả một kết quả kiểm thử được; rule nghiệp vụ không bị chép lại thành nhiều biến thể. Quality gate: Requirement phân biệt rõ fact, project assumption và VERIFICATION REQUIRED. Escalation route: Rule mới hoặc thay đổi ý nghĩa rule chuyển Business Owner và owner chuyên môn liên quan.

4. Actor: BA. Action: Đặc tả dữ liệu, giao diện và tích hợp trong phạm vi đã có bằng chứng. Object: Trường dữ liệu, trạng thái, quyền, API hoặc trao đổi dữ liệu liên quan. Evidence produced: Mapping từ requirement tới thuật ngữ và dữ liệu trong CANONICAL_DATA_DICTIONARY; điểm tích hợp có hợp đồng nguồn. Decision rule: Không tự đặt tên field, mã trạng thái, endpoint, retention rule hoặc cơ chế xác thực khi chưa có nguồn canonical. Quality gate: Mỗi dữ liệu có mục đích nghiệp vụ, nguồn, nơi dùng và xử lý lỗi; dữ liệu cá nhân hoặc nhạy cảm được gắn rủi ro. Escalation route: Thiết kế API và kiến trúc chuyển Architect; phân loại bảo mật chuyển Security; nghĩa vụ dữ liệu cá nhân chuyển Legal Owner.

5. Actor: BA. Action: Kiểm tra tính nhất quán ngang. Object: Requirement, rule, dữ liệu, acceptance criteria, dependency và thuật ngữ. Evidence produced: Danh sách kiểm tra truy vết và danh sách mâu thuẫn. Decision rule: Không cho hai requirement tạo kết quả khác nhau từ cùng điều kiện; không dùng thuật ngữ khác cho cùng đối tượng dữ liệu. Quality gate: Mọi requirement truy được về ít nhất một input; mọi input áp dụng được phản ánh trong đặc tả hoặc được ghi rõ không áp dụng. Escalation route: ID hoặc nguồn canonical mâu thuẫn chuyển Principal IT Business Analyst / Technical Curriculum Author để lập gói vấn đề, không tự quyết nội dung chuyên môn.

6. Actor: BA và reviewer đúng thẩm quyền. Action: Review đặc tả theo lĩnh vực. Object: Bản Functional Specification và bằng chứng truy vết. Evidence produced: Comment review gắn vị trí, người nêu, loại vấn đề, nguồn và hành động xử lý. Decision rule: Comment chỉ đóng khi có bằng chứng thay đổi hoặc lý do loại bỏ được ghi nhận; IN_REVIEW không được đổi thành approval bằng suy diễn. Quality gate: Không còn mâu thuẫn mở thuộc phạm vi chức năng; vấn đề ngoài thẩm quyền BA còn nhãn VERIFICATION REQUIRED. Escalation route: Vấn đề chưa giải quyết giữ mở, chuyển owner chuyên môn; không chuyển thành requirement bắt buộc.

7. Actor: BA. Action: Đóng gói và handoff có kiểm soát. Object: Functional Specification, bảng truy vết, comment còn mở và dependency. Evidence produced: Gói handoff nêu phiên bản v0.9.0, trạng thái IN_REVIEW, ngày 2026-08-07, phạm vi, thay đổi, rủi ro và điểm cần xác minh. Decision rule: Handoff chỉ truyền thông tin; không tạo baseline, approval hay quyền triển khai. Quality gate: Người nhận có đủ requirement, acceptance criteria, nguồn và vấn đề mở để không tự suy diễn. Escalation route: Thiếu artifact, thiếu truy vết hoặc thiếu owner nhận chuyển Principal IT Business Analyst / Technical Curriculum Author để dừng handoff và sửa gói.

Senior Lens

BA giỏi không viết nhiều. BA giảm suy diễn. Bằng chứng nối tới requirement, requirement nối tới kiểm thử, và điểm chưa đủ thẩm quyền giữ nguyên nhãn xác minh. Handoff tốt giúp đội build và QA biết chính xác điều gì đã biết, điều gì là giả định, điều gì chưa được quyết định.

Quick Reference

Kiểm tra trước handoff	Đạt khi
Nguồn	Có nguồn canonical hoặc URL chính thức đúng boundary
Truy vết	Requirement nối được tới input
Kiểm thử	Có điều kiện và kết quả quan sát được
Thẩm quyền	Legal, Accounting, Security, Architect không bị BA thay quyền
Trạng thái	Giữ IN_REVIEW; không gọi là approved hoặc baselined

Core

Mỗi bước viết Functional Specification phải tạo bằng chứng kiểm tra được. BA không biến giả định thành yêu cầu: dữ kiện phải có nguồn, quyết định phải có thẩm quyền, điểm chưa rõ phải được chuyển cấp.

Bước	Actor	Action	Object	Evidence produced	Decision rule	Quality gate	Escalation route
1. Chuẩn bị	BA	Đọc phạm vi và đăng ký nguồn	/01-curriculum/CHAPTER_MANIFEST.md, TRACEABILITY_ID_REGISTRY, nguồn đầu vào được giao	Danh mục nguồn, phạm vi, câu hỏi mở	Chỉ dùng ID, tên tệp, trạng thái đã có trong nguồn canonical	Mỗi phát biểu phân biệt fact, assumption, Verification required	Nguồn mâu thuẫn hoặc ID thiếu: Principal IT Business Analyst / Technical Curriculum Author
2. Trích xuất hành vi	BA	Tách tác nhân, kích hoạt, dữ liệu vào, xử lý, kết quả	Quy trình hoặc yêu cầu nguồn	Bảng hành vi hiện tại và hành vi cần có	Không suy diễn rule từ ví dụ đơn lẻ	Mỗi hành vi liên kết ít nhất một nguồn hoặc nhãn project assumption	Nghiệp vụ chưa rõ: Business Owner
3. Soạn chức năng	BA	Viết điều hệ thống phải làm, không viết cách code	Functional requirement, business rule, data field	Bản Functional Specification nháp	Câu yêu cầu phải kiểm thử được, nêu điều kiện và kết quả	Không có từ mơ hồ như “nhanh”, “phù hợp”, “tự động” nếu thiếu tiêu chí	Thiết kế kỹ thuật: Architect; dữ liệu: Data Owner
4. Kiểm tra ràng buộc	BA	Đối chiếu dữ liệu, bảo mật, kế toán, pháp lý	Trường dữ liệu, quyền, chứng từ, luồng tích hợp	Danh sách constraint và nhãn Verification required	Không gọi là nghĩa vụ pháp lý khi chưa có Legal Owner xác minh	Không có claim tuân thủ, production-ready hoặc approved	Privacy/pháp lý: Legal Owner; kế toán: Accounting Owner; bảo mật: Security
5. Review liên chức năng	BA	Gửi bản nháp, ghi nhận comment theo nguồn	Bản nháp và comment log	Phiên bản review, quyết định mở/đóng	Chỉ đóng comment khi có bằng chứng hoặc quyết định đúng thẩm quyền	Không tự đóng comment của vai trò khác	Tranh chấp phạm vi: Business Owner; testability: QA Reviewer
6. Handoff có kiểm soát	BA	Chuyển bản có traceability cho vai trò nhận	Functional Specification và bằng chứng liên kết	Handoff record, danh sách điểm mở	IN_REVIEW không được diễn giải là baseline hoặc approval	Người nhận xác nhận đã nhận artifact, không xác nhận phê duyệt nội dung	Thiếu đầu vào test: QA Reviewer; thiếu thiết kế: Architect

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, không xác nhận cấu hình ERP thật.

Trường	Nội dung
Facts	Người dùng kho cần ghi nhận lô hàng nhập; nguồn hiện có chỉ xác nhận đây là nhu cầu học liệu, không xác nhận quy trình vận hành thật.
Current Behavior	Chưa có Functional Specification canonical mô tả kiểm tra mã lô khi nhận hàng.
Underlying Need	QA cần điều kiện kiểm thử rõ: khi mã lô trống, hệ thống phải xử lý thế nào.
Options	A: cho lưu mã lô trống. B: chặn lưu và báo lỗi. C: cho lưu tạm với trạng thái chờ bổ sung.
Decision Criteria	Khả năng truy vết, tác động vận hành, quyền quyết định nghiệp vụ, khả năng kiểm thử.
Decision	Ghi Verification required; chưa chọn A, B hoặc C vì nguồn chưa cấp rule canonical.
Authority	Business Owner quyết định luồng nghiệp vụ; QA Reviewer kiểm tra testability; Legal Owner và domain owner xác minh nếu yêu cầu bị diễn giải thành nghĩa vụ an toàn thực phẩm.
Artifact	Ghi điểm mở trong Functional Specification, liên kết CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY khi nội dung được đăng ký.
Consequence if Wrong	Chọn B khi nghiệp vụ cần C có thể chặn nhận hàng; chọn A khi cần kiểm soát lô có thể làm mất khả năng truy vết mô phỏng.

Senior Lens

Evidence là bằng chứng có thể kiểm tra, không phải ý kiến. Decision rule là điều kiện chọn hoặc dừng; quality gate là kiểm tra trước khi sang bước; escalation route là vai trò có quyền giải quyết. Ba mục này tách riêng để BA không dùng review như phê duyệt, hoặc dùng thẩm quyền kỹ thuật để thay quyết định nghiệp vụ.

Quick Reference

Mỗi dòng Functional Specification cần trả lời: ai làm, làm gì, trên đối tượng nào, tạo bằng chứng gì, chọn theo quy tắc nào, qua cổng chất lượng nào, và ai giải quyết khi không đủ căn cứ.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dữ liệu tổng hợp, IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND. Bảng dưới ghi một lần thực thi viết functional specification cho luồng ERP “ghi nhận lô thành phẩm sau sản xuất”. Functional specification là đặc tả chức năng: mô tả hệ thống phải xử lý gì, dữ liệu nào, điều kiện nào và kết quả nào; không tự quyết định cấu hình production.

Thành phần	Nội dung thực thi Nova Foods	Cầu nối bằng chứng và suy luận
Facts	Phiếu hoàn thành sản xuất tổng hợp ghi mã lệnh sản xuất, mã thành phẩm, số lô, số lượng đạt và kho nhận. Một lệnh có thể tạo nhiều lô.	Chứng từ đầu vào có số lô và số lượng. Suy ra đặc tả phải giữ quan hệ lệnh sản xuất–lô–số lượng, không chỉ ghi tổng số lượng.
Current Behavior	Nhân viên kho nhập số lượng thành phẩm vào ERP mô phỏng; dữ liệu lô được ghi tự do, có thể sai định dạng hoặc trùng với lô đã tồn tại.	Hành vi hiện tại cho phép nhập tự do. Rủi ro là truy vết sai giữa lô, tồn kho và chứng từ nguồn.
Underlying Need	ERP phải chỉ tạo giao dịch nhập kho khi lệnh sản xuất hợp lệ, lô chưa tồn tại cho cùng thành phẩm, số lượng đạt lớn hơn 0, và kho nhận được chỉ định.	Đây là điều kiện tối thiểu để dữ liệu nhập kho có nguồn, có định danh lô và có vị trí tồn. Không kết luận đây là quy tắc vận hành thực tế.
Options	Phương án 1: kiểm tra thủ công ngoài ERP. Phương án 2: ERP kiểm tra trường bắt buộc, trạng thái lệnh, trùng lô và số lượng trước khi lưu.	Phương án 1 không tạo bằng chứng kiểm tra trong giao dịch. Phương án 2 tạo kết quả kiểm tra lặp lại được.
Decision Criteria	Chọn phương án nào giữ truy vết lô, chặn dữ liệu không hợp lệ trước khi tăng tồn, cho phép QA kiểm thử từ điều kiện rõ, và không suy diễn nghĩa vụ pháp lý.	Tiêu chí xuất phát từ nhu cầu dữ liệu và khả năng kiểm thử; không dựa vào giả định tuân thủ.
Decision	Chọn Phương án 2 cho đặc tả mô phỏng: kiểm tra trước lưu; lỗi hiển thị theo trường; giao dịch hợp lệ tạo nhận kho và liên kết tới lệnh sản xuất.	Phương án 2 đáp ứng toàn bộ tiêu chí nêu trên. Quyết định chỉ là nội dung đang xem xét, không phải baseline hay phê duyệt.
Authority	Business Owner xác nhận quy trình nghiệp vụ; QA xác nhận khả năng kiểm thử; Architect xác nhận khả năng tích hợp và mô hình dữ liệu; Legal/Compliance Owner xác minh yêu cầu liên quan truy xuất thực phẩm nếu được áp dụng.	Mỗi kết luận nằm trong thẩm quyền riêng. BA duy trì traceability, không thay vai trò chuyên môn.
Artifact	Functional specification liên kết /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md; các artifact này đều IN_REVIEW, v0.9.0.	Dùng đường dẫn canonical có sẵn để tránh tạo nguồn chân lý mới hoặc tự tạo ID.
Consequence if Wrong	Nếu chấp nhận lô trùng hoặc số lượng không hợp lệ, tồn kho mô phỏng sai, truy vết lô sai, QA không có test basis rõ, và đội nghiệp vụ có thể xử lý theo dữ liệu không đáng tin.	Nhập kho tăng tồn và gắn lô. Sai tại điểm kiểm tra sẽ lan sang báo cáo tồn và tra cứu lô.

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

flowchart TB
    A[Nhân viên kho nhập nhận thành phẩm] --> B{Đủ lệnh sản xuất, thành phẩm, lô, kho, số lượng đạt > 0?}
    B -- Không --> E[ERP báo lỗi theo trường; không lưu]
    B -- Có --> C{Trạng thái lệnh sản xuất hợp lệ và lô chưa trùng cho cùng thành phẩm?}
    C -- Không --> F[ERP báo lỗi tại trường lệnh sản xuất hoặc số lô; không lưu]
    C -- Có --> D[Tạo nhận kho và liên kết lệnh sản xuất]
    D --> G[Cập nhật tồn kho theo lô]
    G --> H[Lưu bằng chứng giao dịch để QA truy vết]

Sơ đồ là Mermaid flowchart, không phải BPMN. Nó biến Facts thành điểm kiểm tra: thiếu dữ liệu chặn tại B; lệnh hoặc lô không hợp lệ chặn tại C; chỉ nhánh hợp lệ mới cập nhật tồn. Yêu cầu truy xuất hoặc an toàn thực phẩm là Verification required với domain owner và Legal/Compliance Owner; không suy ra nghĩa vụ từ case mô phỏng.

6. Output thu ???c

Core

Output là artifact, tức vật phẩm công việc có thể kiểm tra, lưu vết và bàn giao. Functional specification tạo hoặc cập nhật các artifact sau. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Artifact	Loại tác động	Owner	Status	Canonical ID / tệp	Nội dung tối thiểu	Lịch sử thay đổi bắt buộc
Functional specification	Tạo hoặc cập nhật	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Tệp: /02-handbook/09-functional-specification-writing.md; Artifact ID chưa được cấp trong nguồn đã cung cấp	Mục tiêu chức năng, phạm vi, hành vi hệ thống, quy tắc, dữ liệu, ngoại lệ, liên kết nguồn	Version, ngày 2026-08-07, múi giờ Asia/Ho_Chi_Minh, người sửa, lý do, artifact bị ảnh hưởng
Registry định danh	Cập nhật khi cần cấp hoặc liên kết ID	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	TRACEABILITY_ID_REGISTRY; /01-curriculum/TRACEABILITY_ID_REGISTRY.md	ID được đăng ký, loại đối tượng, nguồn tạo, liên kết artifact	Không sửa đè ID đã ghi; ghi version, ngày, lý do và liên kết thay đổi
Catalog quy tắc nghiệp vụ	Cập nhật khi functional specification làm rõ quy tắc	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	CANONICAL_BUSINESS_RULES; /01-curriculum/CANONICAL_BUSINESS_RULES.md	Quy tắc, điều kiện áp dụng, ngoại lệ, nguồn, thẩm quyền xác minh	Ghi thay đổi quy tắc, tác động chức năng, nguồn và trạng thái xác minh
Từ điển dữ liệu logic	Cập nhật khi có trường, ý nghĩa hoặc kiểm tra dữ liệu mới	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	CANONICAL_DATA_DICTIONARY; /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tên dữ liệu, nghĩa, kiểu logic, nguồn, kiểm tra và phân loại	Ghi trường thay đổi, lý do, artifact dùng trường đó và ngày sửa

Không tự tạo Artifact ID cho functional specification khi registry chưa cấp ID. Bằng chứng: TRACEABILITY_ID_REGISTRY là nguồn canonical cho định danh; tự đặt ID tạo hai nguồn chân lý. IN_REVIEW chỉ nói artifact đang được xem xét có kiểm soát; không nói đã baseline, được phê duyệt, sẵn sàng production hay tuân thủ.

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

flowchart TB
    R[TRACEABILITY_ID_REGISTRY]
    B[CANONICAL_BUSINESS_RULES]
    D[CANONICAL_DATA_DICTIONARY]
    F[Functional specification]

    R -->|Nguồn ID; không tự cấp ID| F
    B -->|Nguồn quy tắc trước khi mô tả chức năng| F
    D -->|Nguồn dữ liệu và kiểm tra trước khi mô tả chức năng| F

    F --> Q1{Cần cấp hoặc liên kết ID?}
    Q1 -->|Có| R
    Q1 -->|Không| N1[Không cập nhật registry]

    F --> Q2{Làm rõ quy tắc nghiệp vụ?}
    Q2 -->|Có| B
    Q2 -->|Không| N2[Không cập nhật catalog]

    F --> Q3{Có dữ liệu hoặc kiểm tra mới?}
    Q3 -->|Có| D
    Q3 -->|Không| N3[Không cập nhật từ điển]

    F --> HF[Lịch sử riêng: version, ngày 2026-08-07,<br/>Asia/Ho_Chi_Minh, người sửa, lý do,<br/>artifact bị ảnh hưởng]
    R --> HR[Lịch sử riêng: không sửa đè ID;<br/>version, ngày, lý do, liên kết thay đổi]
    B --> HB[Lịch sử riêng: thay đổi quy tắc,<br/>tác động chức năng, nguồn, trạng thái xác minh]
    D --> HD[Lịch sử riêng: trường thay đổi, lý do,<br/>artifact dùng trường, ngày sửa]

    O[Owner mọi artifact:<br/>Principal IT Business Analyst /<br/>Technical Curriculum Author]
    S[Status mọi artifact: IN_REVIEW]
    X[IN_REVIEW và lịch sử thay đổi<br/>không thay thế phê duyệt;<br/>không nói baseline, production hay tuân thủ]

    O -.-> F
    O -.-> R
    O -.-> B
    O -.-> D
    S -.-> F
    S -.-> R
    S -.-> B
    S -.-> D
    HF -.-> X
    HR -.-> X
    HB -.-> X
    HD -.-> X

Sơ đồ là Mermaid flowchart, không phải BPMN. Mỗi liên kết buộc BA chỉ rõ artifact nguồn trước khi mô tả chức năng. Change history giữ bằng chứng ai đổi gì, khi nào và vì sao; nó không thay thế phê duyệt.

Applied

Thành phần	Nova Foods micro-case mô phỏng
Facts	Functional specification mô tả nhận thành phẩm từ lệnh sản xuất vào kho. Dữ liệu dùng mã lệnh, mã thành phẩm, mã lô, kho nhận và số lượng tổng hợp.
Current Behavior	Tài liệu cần liên kết quy tắc kiểm tra lệnh sản xuất, lô hàng và số lượng trước khi tạo giao dịch nhận kho.
Underlying Need	QA, đội kỹ thuật và nghiệp vụ cần đọc cùng một hành vi, cùng nguồn quy tắc và cùng nghĩa dữ liệu. Nếu mỗi nhóm tự chép lại, diễn giải có thể lệch.
Options	Ghi quy tắc và định nghĩa dữ liệu ngay trong functional specification; hoặc liên kết đến catalog canonical.
Decision Criteria	Nguồn phải duy nhất, ID phải truy vết được, thay đổi phải thấy lịch sử, owner không vượt thẩm quyền.
Decision	Functional specification liên kết CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY; không sao chép thành nguồn độc lập.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì artifact và traceability. Business Owner, QA, Architect, Legal/Compliance Owner hoặc Accounting Owner giữ thẩm quyền riêng khi nội dung chạm phạm vi của họ.
Artifact	/02-handbook/09-functional-specification-writing.md, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY; tất cả đang IN_REVIEW, v0.9.0, ngày 2026-08-07.
Consequence if Wrong	ID tự tạo hoặc quy tắc bị chép khác nhau làm QA truy sai nguồn, kỹ thuật xây sai kiểm tra, và thay đổi sau này không xác định được phạm vi ảnh hưởng.

Senior Lens

Owner chịu trách nhiệm duy trì, không tự xác nhận nội dung nghiệp vụ đúng. Lý do: functional specification có thể chạm kế toán, truy xuất thực phẩm, dữ liệu cá nhân, bảo mật hoặc kiến trúc; mỗi miền cần vai trò có thẩm quyền xác minh.

Mọi thay đổi phải ghi ít nhất: artifact bị đổi, vị trí thay đổi, giá trị trước và sau, lý do, nguồn bằng chứng, người ghi nhận, ngày theo Asia/Ho_Chi_Minh, tác động đến artifact liên kết. Không sửa im lặng. Không dùng “đã phê duyệt”, “đã baseline” hoặc “production-ready” khi artifact vẫn IN_REVIEW.

Quick Reference

Quy tắc	Cách làm
Cần ID mới	Kiểm tra và cập nhật TRACEABILITY_ID_REGISTRY trước khi dùng ID.
Cần quy tắc	Liên kết CANONICAL_BUSINESS_RULES; không tạo bản sao làm nguồn mới.
Cần nghĩa dữ liệu	Liên kết CANONICAL_DATA_DICTIONARY; không tự đổi nghĩa trường trong functional specification.
Có thay đổi	Ghi change history đầy đủ, giữ IN_REVIEW cho đến khi có trạng thái khác được ghi nhận minh bạch.

Core

Output anatomy là cấu trúc đủ để người đọc kiểm tra một kết quả BA mà không tự đoán ngữ cảnh. Với Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dữ liệu tổng hợp, mỗi output phải tách rõ: điều quan sát được, quy tắc suy ra, quyết định còn cần thẩm quyền, và liên kết nguồn. Không tạo ID mới ngoài ID canonical đã đăng ký.

Thành phần	Nội dung bắt buộc	Ví dụ điền cho Nova Foods mô phỏng
Output container	Artifact chứa output và đường dẫn canonical	/02-handbook/09-functional-specification-writing.md
Artifact reference	ID artifact nguồn hoặc đích, giữ nguyên chuỗi canonical	CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY
Scope unit	Chức năng hoặc hành vi ERP đang mô tả	Ghi nhận lô sản xuất trước khi nhập tồn kho thành phẩm
Fact	Sự kiện quan sát được, không suy diễn thành rule	Nhân viên ghi mã lô, ngày sản xuất và số lượng hoàn thành
Current Behavior	Hành vi hiện tại hoặc giả định mô phỏng, nêu ranh giới	File theo dõi nội bộ mô phỏng chưa chặn nhập thiếu ngày sản xuất
Need	Lý do nghiệp vụ chuyển thành nhu cầu kiểm soát	Cần dữ liệu lô đủ để truy vết nội bộ mô phỏng khi có sự cố chất lượng
Rule or requirement	Câu kiểm tra được, điều kiện và kết quả	Hệ thống chỉ cho ghi nhận lô khi có mã lô, ngày sản xuất, mã mặt hàng và số lượng lớn hơn 0
Data reference	Khái niệm dữ liệu, không tự tạo schema vật lý	Tham chiếu CANONICAL_DATA_DICTIONARY; chi tiết trường cần được xác minh trong artifact đó
Traceability reference	Liên kết nhu cầu, rule, dữ liệu và test basis	Tham chiếu TRACEABILITY_ID_REGISTRY; không tự gán ID chưa đăng ký
Source classification	Loại nguồn và giới hạn dùng	Primary-source seed: Luật An toàn thực phẩm; chỉ dùng làm bối cảnh truy vết, cần domain-owner và legal verification
Assumption or verification	Điều chưa được nguồn xác minh trực tiếp	Verification required: mã lô và thời gian lưu dữ liệu phù hợp vận hành thực tế
Downstream reading result	Điều đội sau có thể kiểm tra	QA tạo test cho thiếu mã lô, thiếu ngày sản xuất, số lượng bằng 0 và số lượng âm

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

flowchart TB
    A[Nhân viên nhập lô] --> B{Có mã lô, ngày sản xuất, mã mặt hàng<br/>và số lượng lớn hơn 0?}
    B -- Không --> C[Từ chối lưu; báo trường thiếu<br/>hoặc số lượng không hợp lệ]
    B -- Có --> D[Ghi nhận lô mô phỏng]
    D --> E[Liên kết nhu cầu, rule, dữ liệu<br/>qua TRACEABILITY_ID_REGISTRY]
    E --> F[Test basis: thiếu mã lô, thiếu ngày sản xuất,<br/>số lượng bằng 0, số lượng âm]

Applied

Mục	Nội dung điền hoàn chỉnh
Facts	Nova Foods mô phỏng sản xuất trà đóng chai 500 ml. Nhân viên cần ghi nhận một lô hoàn thành để kho có căn cứ nhận hàng. Dữ liệu sử dụng là tổng hợp.
Current Behavior	Quy trình mô phỏng cho phép nhân viên nhập thông tin lô. Chưa có bằng chứng rằng ERP thực tế của bất kỳ tổ chức nào vận hành như vậy.
Underlying Need	Kho và chất lượng cần phân biệt hàng theo lô. Suy luận này dựa trên việc một lô có thể khác lô khác về ngày sản xuất và số lượng; nếu gộp chung, việc đối chiếu nội bộ mô phỏng mất điểm phân biệt.
Options	Phương án 1: chỉ ghi số lượng. Phương án 2: ghi mã lô, ngày sản xuất, mặt hàng và số lượng. Phương án 3: ghi toàn bộ thông tin phương án 2 kèm dữ liệu kiểm nghiệm.
Decision Criteria	Đủ truy vết nội bộ mô phỏng; kiểm tra tự động được; không suy diễn nghĩa vụ pháp lý hoặc cấu hình production; không thêm dữ liệu chưa có nhu cầu chứng minh.
Decision	Chọn phương án 2. Mã lô, ngày sản xuất, mặt hàng và số lượng là bộ tối thiểu cho tình huống học liệu. Phương án 1 không phân biệt được lô. Phương án 3 vượt bằng chứng đầu vào.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì cấu trúc học liệu. Business Owner, Quality Owner và Legal Owner cần xác minh nếu chuyển nội dung sang quyết định vận hành hoặc nghĩa vụ pháp lý.
Artifact	Nội dung chức năng nằm trong /02-handbook/09-functional-specification-writing.md; khái niệm rule, data và traceability lần lượt tham chiếu CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY.
Consequence if Wrong	Nếu cho phép lưu thiếu mã lô, dữ liệu không phân biệt được hàng nào cần đối chiếu. Nếu bắt buộc dữ liệu kiểm nghiệm khi chưa có nhu cầu được chứng minh, phạm vi bị phình và tạo yêu cầu giả.

Senior Lens

Output tốt không phải văn bản dài. Output tốt giữ được chuỗi chứng minh: Fact nói điều biết được; Need giải thích vì sao fact chưa đủ; Decision chọn phương án theo tiêu chí; Artifact ghi nơi đội sau đọc và kiểm tra. Không biến nguồn pháp lý thành rule ERP khi chưa có xác minh từ chủ sở hữu chuyên môn. Luật An toàn thực phẩm trong primary-source seed chỉ hỗ trợ bối cảnh truy vết; không chứng minh trường dữ liệu, thời hạn lưu hoặc luồng phê duyệt cụ thể.

Quick Reference

Kiểm tra anatomy	Đạt khi
Đủ ngữ cảnh	Có Fact, Current Behavior và Underlying Need riêng biệt
Đủ quyết định	Có Options, Decision Criteria và Decision
Đủ ranh giới	Có Authority và nhãn Verification required cho nội dung chưa xác minh
Đủ liên kết	Chỉ dùng CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY và đường dẫn canonical đã biết
Đủ để review sau	Người đọc tạo được kiểm tra thiếu dữ liệu bắt buộc mà không suy đoán rule mới

Core

Quality gate là cổng kiểm tra chất lượng trước khi output được đưa vào downstream review, tức vòng xem xét của vai trò nhận artifact ở bước sau. Gate kiểm tra tính đủ, rõ, truy vết được và đúng ranh giới thẩm quyền; gate không là phê duyệt, baseline, xác nhận tuân thủ, production readiness hay chấp thuận người dùng.

Điều kiện gate	Bằng chứng phải có	Lý do
Đúng identity	Giữ nguyên Artifact ID, filename canonical, Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh	Reviewer phải biết đang xem đúng artifact kiểm soát.
Truy vết được	Mỗi kết luận liên kết nguồn hoặc artifact upstream canonical, như 00_SOURCE_MAP, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY	Không có liên kết, reviewer không kiểm tra được căn cứ.
Đủ để review	Có mục tiêu, phạm vi, input, output, quy tắc, ngoại lệ và điểm cần xác minh phù hợp nội dung output	Thiếu thành phần làm reviewer phải tự suy diễn.
Không vượt thẩm quyền	Nội dung pháp lý, kế toán, thuế, bảo mật, an toàn thực phẩm ghi Verification required hoặc project assumption khi chưa có xác minh chuyên môn	BA không thay Legal Owner, Accounting Owner, Security, Architect hay Business Owner.
Lịch sử đổi rõ	Có dòng change history: phiên bản, ngày, người ghi nhận, thay đổi, lý do	Ngăn sửa im lặng và giữ audit trail.
Không mâu thuẫn	Không xung đột với status, version, source boundary hoặc ID canonical	Mâu thuẫn phá traceability trước khi review bắt đầu.

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

flowchart TB
    A[Output drafted<br/>Status: IN_REVIEW] --> B{Quality gate<br/>Đúng identity<br/>Truy vết được<br/>Đủ để review<br/>Không vượt thẩm quyền<br/>Lịch sử đổi rõ<br/>Không mâu thuẫn}
    B -->|Đạt tất cả điều kiện| C[Ready for downstream review]
    B -->|Thiếu, mâu thuẫn<br/>hoặc vượt thẩm quyền| D[Return for correction]
    C --- E[Status vẫn: IN_REVIEW]

Ready for downstream review chỉ nghĩa là reviewer có đủ vật liệu để kiểm tra. IN_REVIEW giữ nguyên vì chưa có approval reference hay baseline reference.

Applied

Trường	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp
Facts	/02-handbook/09-functional-specification-writing.md là handbook artifact; corpus hiện IN_REVIEW, v0.9.0, ngày 2026-08-07.
Current Behavior	Draft có thể được chuyển review dù thiếu liên kết nguồn hoặc dùng kết luận pháp lý chưa xác minh.
Underlying Need	Reviewer cần phân biệt nội dung đủ để xem xét với nội dung đã được phê duyệt hay sẵn sàng production.
Options	(1) Chỉ kiểm tra chính tả. (2) Kiểm tra metadata, traceability, ranh giới thẩm quyền, lịch sử đổi và tính nhất quán.
Decision Criteria	Option phải cho reviewer kiểm tra căn cứ mà không tạo approval ngầm định.
Decision	Chọn option 2; output qua gate khi toàn bộ điều kiện Core có bằng chứng.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì artifact governance; Legal Owner, Accounting Owner, Security, Architect, QA và Business Owner giữ thẩm quyền chuyên môn riêng.
Artifact	/02-handbook/09-functional-specification-writing.md; tham chiếu canonical: 00_SOURCE_MAP, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY.
Consequence if Wrong	Reviewer có thể xem draft thiếu căn cứ là yêu cầu đã chốt; team có thể suy diễn sai phạm vi, rule hoặc trách nhiệm xác minh.

Senior Lens

Gate tốt chặn lỗi sớm nhất có thể. Ví dụ, requirement nói về dữ liệu cá nhân nhưng chỉ dẫn Luật Bảo vệ dữ liệu cá nhân chưa được Legal Owner xác minh: evidence cho thấy đây là vấn đề thẩm quyền, không phải lỗi câu chữ. Output chỉ đạt gate khi ghi Verification required; không được đổi nhãn thành “tuân thủ”.

Không dùng gate để ép reviewer đồng ý nội dung. Gate xác nhận chất lượng đầu vào cho review; reviewer vẫn có thể trả lại output vì sai nghiệp vụ, sai kỹ thuật, thiếu testability hoặc nguồn mâu thuẫn.

Quick Reference

Kết quả kiểm tra	Xử lý
Đủ metadata, traceability, lịch sử đổi, ranh giới thẩm quyền; không mâu thuẫn	Gắn Ready for downstream review; giữ IN_REVIEW.
Thiếu nguồn, ID sai, thay đổi không có lịch sử, hoặc kết luận vượt thẩm quyền	Trả về sửa; không chuyển review.
Có approval hoặc baseline reference được ghi nhận minh bạch	Xử lý theo artifact governance tương ứng; quality gate không tự tạo reference đó.

7. Who consumes those outputs?

Core

Đặc tả chức năng (Functional Specification) không phải tài liệu để BA lưu trữ. Mỗi output trở thành đầu vào công việc cho vai trò khác. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi tên, ID và dữ liệu dưới đây là dữ liệu tổng hợp.

Output trong Functional Specification	Consumer	Cách consumer sử dụng
Luồng nghiệp vụ, điều kiện bắt đầu, kết quả kết thúc	Developers	Chuyển luồng thành màn hình, xử lý dịch vụ, trạng thái và thứ tự thực thi.
Business rule, tức quy tắc quyết định nghiệp vụ	Developers, QA, Business Owner	Developer mã hóa rule; QA tạo kiểm thử theo rule; Business Owner đối chiếu rule với nhu cầu nghiệp vụ.
Acceptance criteria, tức điều kiện chấp nhận	QA, PM/Product Owner	QA lập test case; PM/Product Owner dùng làm ranh giới kiểm tra phạm vi bàn giao.
Data fields, validation, dữ liệu bắt buộc và giá trị hợp lệ	Developers, QA, Architect	Developer thiết kế nhập liệu và lưu dữ liệu; QA kiểm tra dữ liệu biên; Architect kiểm tra phù hợp mô hình dữ liệu và tích hợp.
API, mapping dữ liệu và lỗi tích hợp	Developers, Architect, Operations	Developer xây dựng giao tiếp; Architect kiểm tra giao kèo kỹ thuật; Operations chuẩn bị giám sát lỗi và xử lý sự cố.
Quyền truy cập và phân tách trách nhiệm	Developers, Architect, Operations, specialist owners	Developer cấu hình quyền; Architect xem xét mô hình bảo mật; Operations vận hành cấp quyền; specialist owners kiểm tra giới hạn chuyên môn như kho, kế toán hoặc chất lượng.
Traceability, tức liên kết giữa requirement, rule, test và thay đổi	QA, PM/Product Owner, Business Owner	QA xác định test basis; PM/Product Owner theo dõi phạm vi; Business Owner truy ngược từ kết quả về nhu cầu ban đầu.

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

flowchart TB
    FS["Functional Specification"]

    FLOW["Luồng nghiệp vụ,<br/>điều kiện bắt đầu,<br/>kết quả kết thúc"]
    RULE["Business rule"]
    AC["Acceptance criteria"]
    DATA["Data fields và validation"]
    API["API, mapping dữ liệu<br/>và lỗi tích hợp"]
    ACCESS["Quyền truy cập và<br/>phân tách trách nhiệm"]
    TRACE["Traceability"]

    FS --> FLOW
    FS --> RULE
    FS --> AC
    FS --> DATA
    FS --> API
    FS --> ACCESS
    FS --> TRACE

    FLOW --> FLOW_DEV["Developers:<br/>màn hình, xử lý dịch vụ,<br/>trạng thái và thứ tự thực thi"]

    RULE --> RULE_DEV["Developers:<br/>mã hóa rule"]
    RULE --> RULE_QA["QA:<br/>tạo kiểm thử theo rule"]
    RULE --> RULE_BO["Business Owner:<br/>đối chiếu rule với nhu cầu nghiệp vụ"]

    AC --> AC_QA["QA:<br/>lập test case"]
    AC --> AC_PM["PM/Product Owner:<br/>dùng làm ranh giới kiểm tra<br/>phạm vi bàn giao"]

    DATA --> DATA_DEV["Developers:<br/>thiết kế nhập liệu và lưu dữ liệu"]
    DATA --> DATA_QA["QA:<br/>kiểm tra dữ liệu biên"]
    DATA --> DATA_ARC["Architect:<br/>kiểm tra mô hình dữ liệu<br/>và tích hợp"]

    API --> API_DEV["Developers:<br/>xây dựng giao tiếp"]
    API --> API_ARC["Architect:<br/>kiểm tra giao kèo kỹ thuật"]
    API --> API_OPS["Operations:<br/>chuẩn bị giám sát lỗi<br/>và xử lý sự cố"]

    ACCESS --> ACCESS_DEV["Developers:<br/>cấu hình quyền"]
    ACCESS --> ACCESS_ARC["Architect:<br/>xem xét mô hình bảo mật"]
    ACCESS --> ACCESS_OPS["Operations:<br/>vận hành cấp quyền"]
    ACCESS --> ACCESS_SO["Specialist owners:<br/>kiểm tra giới hạn chuyên môn:<br/>kho, kế toán hoặc chất lượng"]

    TRACE --> TRACE_QA["QA:<br/>xác định test basis"]
    TRACE --> TRACE_PM["PM/Product Owner:<br/>theo dõi phạm vi"]
    TRACE --> TRACE_BO["Business Owner:<br/>truy ngược từ kết quả<br/>về nhu cầu ban đầu"]

Applied

Mục	Nội dung case Nova Foods mô phỏng
Facts	FR-ORD-014 mô tả đơn bán hàng chỉ được chuyển sang trạng thái READY_TO_PICK khi đủ thông tin kho xuất và phương thức giao hàng.
Current Behavior	Functional Specification ghi luồng trạng thái, trường warehouse_id, delivery_method, validation và acceptance criteria.
Underlying Need	Cùng một output phải giúp đội phát triển tạo kiểm tra dữ liệu, QA kiểm thử chặn trạng thái sai, và Operations nhận biết đơn bị dừng trước khi xuất kho.
Options	Tách ba tài liệu riêng theo vai trò; hoặc dùng một Functional Specification làm nguồn chung, mỗi vai trò đọc phần liên quan.
Decision Criteria	Không nhân bản rule; giữ một điểm truy vết; mỗi consumer xác định được phần cần dùng.
Decision	Dùng một Functional Specification liên kết rule, dữ liệu, luồng và acceptance criteria; phân phối theo bảng consumer ở phần Core.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì cấu trúc học liệu; thẩm quyền nghiệp vụ, kiến trúc, kiểm thử và vận hành vẫn thuộc vai trò chuyên môn tương ứng.
Artifact	/02-handbook/09-functional-specification-writing.md; liên kết canonical: TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY.
Consequence if Wrong	Developer có thể cho phép chuyển trạng thái thiếu dữ liệu; QA có thể không kiểm thử đường chặn; Operations nhận đơn lỗi quá muộn.

Senior Lens

Consumer không “đọc toàn bộ để biết”. Consumer dùng output để tạo công việc kế tiếp. Vì vậy, một rule không có điều kiện dữ liệu sẽ khó cho Developer mã hóa; acceptance criteria không nêu kết quả quan sát được sẽ khó cho QA kiểm thử; mapping tích hợp không nêu lỗi trả về sẽ không đủ cho Operations chuẩn bị xử lý.

Specialist owners là chủ thể nghiệp vụ chuyên ngành, ví dụ owner kho, kế toán, chất lượng hoặc logistics trong case Nova Foods mô phỏng. Họ tiêu thụ Functional Specification để kiểm tra ngôn ngữ hệ thống có làm lệch thuật ngữ, luồng thao tác hoặc giới hạn chuyên ngành hay không. Họ không mặc nhiên thay Architect quyết định thiết kế hay thay QA xác nhận chất lượng kiểm thử.

Quick Reference

Vai trò	Đọc trước	Sản phẩm công việc tạo ra
Developers	Luồng, rule, dữ liệu, lỗi	Mã nguồn, cấu hình, API
QA	Acceptance criteria, rule, dữ liệu biên	Test case, test result
Architect	Data model, API, quyền, tích hợp	Nhận xét thiết kế kỹ thuật
PM/Product Owner	Phạm vi, traceability, acceptance criteria	Theo dõi delivery và phạm vi
Business Owner	Luồng, rule, kết quả nghiệp vụ	Đối chiếu giá trị nghiệp vụ
Operations	Lỗi, trạng thái, quyền, tích hợp	Runbook vận hành, giám sát
Specialist owners	Thuật ngữ và rule chuyên ngành	Nhận xét nghiệp vụ chuyên môn

Core

Đầu ra Functional Specification là test basis: căn cứ để thiết kế, kiểm tra, quyết định và vận hành. Mỗi vai trò chỉ quyết định trong thẩm quyền mình. Bằng chứng phải truy được về requirement, business rule, data definition, acceptance criterion, giả định hoặc điểm Verification required. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; trạng thái corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07 không tạo baseline hay phê duyệt.

Consumer	Có thể quyết định	Cần bằng chứng	Phải escalation khi
Developers	Cách hiện thực, chia nhỏ kỹ thuật, xử lý lỗi, API contract trong phạm vi kiến trúc đã có	Luồng chính/ngoại lệ, field bắt buộc, rule, acceptance criterion, mapping tới CANONICAL_DATA_DICTIONARY	Rule mâu thuẫn, thiếu trạng thái, dữ liệu nhạy cảm, thay đổi API liên hệ thống, yêu cầu làm lệch kiến trúc
QA	Test condition, test case, dữ liệu kiểm thử tổng hợp, phạm vi regression	Acceptance criterion đo được, expected result, business rule, trạng thái trước/sau, traceability	Criterion không kiểm thử được, expected result thiếu, rule có nhiều cách hiểu, defect có thể là thay đổi requirement
Architect	Phù hợp kiến trúc, integration pattern, giới hạn hiệu năng, bảo mật, phân quyền kỹ thuật	Context system, interface, volume giả định, data classification, ràng buộc non-functional	Thay đổi system boundary, dữ liệu cá nhân, cơ chế xác thực, tích hợp mới, rủi ro bảo mật hoặc tính sẵn sàng
PM/Product Owner	Ưu tiên, phạm vi release, trade-off thời gian và giá trị	Mục tiêu nghiệp vụ, dependency, effort estimate, rủi ro, acceptance criterion	Thay đổi business outcome, scope vượt release, xung đột ưu tiên, quyết định cần Business Owner
Business Owner	Ý nghĩa nghiệp vụ, ngoại lệ nghiệp vụ, mức chấp nhận kết quả	Rule source, ví dụ dữ liệu tổng hợp, tác động quy trình, hậu quả sai	Quy tắc liên quan pháp lý, kế toán, thuế, thực phẩm, hoặc vượt quyền quyết định đơn vị
Operations	Khả năng vận hành, xử lý sự cố, quyền thao tác, báo cáo và cutover	Operational flow, exception path, SLA giả định, audit need, hướng dẫn xử lý	Thay đổi quy trình vận hành thực, quyền production, retention, backup, hoặc thao tác gây mất dữ liệu
Specialist owners: Legal, Accounting, Security, Food-safety	Diễn giải chuyên môn thuộc lĩnh vực mình	Nguồn chính thức, phạm vi áp dụng, data flow, rule draft, giả định được gắn nhãn	Nguồn chưa xác minh, xung đột nguồn, yêu cầu bị diễn đạt như nghĩa vụ pháp lý hoặc compliance đã xác nhận

Lý do escalation: Functional Specification mô tả hành vi cần có, không trao quyền đổi luật nghiệp vụ, kết luận pháp lý, quyết định kế toán hay chấp thuận kiến trúc. Nếu bằng chứng chỉ là giả định, người nhận có thể thiết kế đúng giả định nhưng sai nhu cầu thật. Vì vậy BA giữ liên kết tới artifact canonical như CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY; chuyên gia có thẩm quyền kết luận phần thuộc lĩnh vực mình.

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

flowchart TB
    FS[Functional Specification<br/>IN_REVIEW v0.9.0]

    FS --> DEV[Developers]
    FS --> QA[QA]
    FS --> ARC[Architect]
    FS --> PO[PM/Product Owner]
    FS --> BO[Business Owner]
    FS --> OPS[Operations]
    FS --> SO[Specialist owners]

    DEV -->|rule mâu thuẫn; thiếu trạng thái; dữ liệu nhạy cảm;<br/>API liên hệ thống; lệch kiến trúc| ESC[Escalation package<br/>quyết định bị chặn; artifact/vị trí; bằng chứng;<br/>lựa chọn; tác động nếu sai; vai trò cần kết luận]
    QA -->|criterion không kiểm thử được; expected result thiếu;<br/>rule nhiều cách hiểu; defect có thể đổi requirement| ESC
    ARC -->|đổi system boundary; dữ liệu cá nhân; xác thực;<br/>tích hợp mới; rủi ro bảo mật hoặc tính sẵn sàng| ESC
    PO -->|đổi business outcome; scope vượt release;<br/>xung đột ưu tiên; cần Business Owner| ESC
    BO -->|rule pháp lý, kế toán, thuế, thực phẩm;<br/>vượt quyền đơn vị| ESC
    OPS -->|đổi quy trình vận hành thực; quyền production;<br/>retention, backup, hoặc thao tác mất dữ liệu| ESC
    SO -->|nguồn chưa xác minh; xung đột nguồn;<br/>nghĩa vụ pháp lý hoặc compliance chưa xác nhận| ESC

    ESC --> BA[BA duy trì traceability<br/>tới artifact canonical]
    BA --> AUTH[Vai trò có thẩm quyền kết luận]
    AUTH -->|nguồn và thẩm quyền đủ| REC[Quyết định và tham chiếu<br/>phê duyệt được ghi nhận]
    AUTH -->|nguồn hoặc thẩm quyền chưa đủ| VR[Verification required<br/>bổ sung hoặc xác minh bằng chứng]
    VR --> ESC

Gói escalation tối thiểu gồm: quyết định đang bị chặn; artifact và vị trí liên quan; bằng chứng nguồn; các lựa chọn; tác động nếu chọn sai; vai trò cần kết luận; nhãn Verification required nếu nguồn chính thức hoặc thẩm quyền chưa đủ. Không ghi “đã phê duyệt” khi chưa có tham chiếu phê duyệt được ghi nhận.

Core

Handoff là chuyển giao đầu ra Functional Specification cho người dùng tiếp theo. Lỗi phổ biến: người nhận đọc câu mô tả như quyết định đã chốt. Bằng chứng phản bác: /02-handbook/09-functional-specification-writing.md và artifact nguồn đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; trạng thái này không là baseline, approval, cấu hình ERP hay quyền triển khai.

Hiểu nhầm khi bàn giao	Rủi ro	Câu hỏi làm rõ chính xác
“Hệ thống kiểm tra tồn kho” đủ để lập trình.	Developer tự chọn thời điểm kiểm tra, kho áp dụng, phản hồi lỗi.	“Kiểm tra tồn kho tại lúc lưu đơn, lúc xác nhận đơn, hay cả hai; dùng số lượng khả dụng nào; khi thiếu hàng hệ thống chặn hay cảnh báo?”
Acceptance criteria là test case.	QA bỏ thiếu dữ liệu, biên và trạng thái lỗi.	“Tiêu chí này mô tả kết quả nghiệp vụ nào; dữ liệu đầu vào, tiền điều kiện, kết quả mong đợi và điều kiện ngoại lệ là gì?”
Sơ đồ tích hợp xác nhận API đã tồn tại.	Architect hoặc Developer giả định endpoint, xác thực, chủ sở hữu.	“Đây là luồng nghiệp vụ hay hợp đồng API; có OpenAPI Specification OAS 3.1.1 được kiểm soát không; hệ thống nào sở hữu dữ liệu nguồn?”
Nhãn “tuân thủ” là yêu cầu đã xác minh.	Đội triển khai biến giả định thành nghĩa vụ pháp lý.	“Yêu cầu này dựa trên nguồn pháp lý nào; Legal Owner đã xác minh chưa; nếu chưa, có phải gắn Verification required không?”
Ví dụ Nova Foods là dữ liệu production.	Lộ lọt hoặc suy diễn sai vận hành thực.	“Giá trị này là dữ liệu tổng hợp của Nova Foods mô phỏng hay dữ liệu vận hành; có được dùng làm cấu hình không?”

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

flowchart TB
    A["Bàn giao Functional Specification<br/>trạng thái IN_REVIEW"] --> B["Người nhận phát hiện điểm mơ hồ"]
    B --> C["Đặt câu hỏi có điều kiện<br/>và yêu cầu bằng chứng"]
    C --> D{"BA phân loại nội dung"}
    D -- "Giả định" --> E["Ghi giả định trong artifact<br/>và duy trì truy vết"]
    D -- "Vấn đề cần xác minh" --> F["Gắn Verification required<br/>và ghi bằng chứng cần bổ sung"]
    E --> G{"Cần chuyển cấp<br/>cho owner chuyên môn?"}
    F --> G
    G -- "Không" --> H["BA làm rõ bằng bằng chứng<br/>thuộc phạm vi"]
    G -- "Có" --> I["BA chuyển cấp đến owner chuyên môn<br/>phù hợp với vấn đề"]
    I --> J["Owner chuyên môn xác minh<br/>bằng nguồn bằng chứng"]
    H --> K{"Đã xác minh?"}
    J --> K
    K -- "Đã xác minh" --> L["BA cập nhật kết quả<br/>và truy vết trong artifact"]
    K -- "Chưa" --> M["Giữ Verification required<br/>và ghi bằng chứng còn thiếu"]
    L --> N["Tiếp tục review và handoff"]
    M --> O["Tiếp tục review và handoff<br/>không dùng như yêu cầu đã xác minh"]
    N --> P["Artifact vẫn IN_REVIEW"]
    O --> P
    P --> Q["Không tạo baseline, approval,<br/>cấu hình ERP hay quyền triển khai"]

Applied

Facts: Functional Specification mô phỏng ghi: “Đơn bán chỉ được xác nhận khi tồn kho đủ.” Dữ liệu Nova Foods là tổng hợp; chưa có baseline hoặc approval.

Current Behavior: Developer hiểu “tồn kho” là số lượng vật lý. QA hiểu là số lượng khả dụng. Hai cách hiểu tạo hai kết quả khác nhau khi hàng đã được giữ cho đơn khác.

Underlying Need: Cùng một quy tắc phải cho một kết quả có thể kiểm tra, không để người nhận tự phát minh logic.

Options: Dùng tồn kho vật lý; dùng tồn kho khả dụng; hoặc giữ quy tắc ở trạng thái chưa xác định và yêu cầu quyết định.

Decision Criteria: Có định nghĩa canonical trong CANONICAL_DATA_DICTIONARY; có quy tắc liên quan trong CANONICAL_BUSINESS_RULES; có Business Owner xác nhận ý nghĩa nghiệp vụ; có Architect xác nhận dữ liệu nguồn.

Decision: Không chọn cách tính trong Functional Specification khi chưa có bằng chứng canonical. Gắn giả định hoặc Verification required, rồi nêu câu hỏi: “Với đơn bán Nova Foods mô phỏng, ‘tồn kho đủ’ dùng tồn kho vật lý, tồn kho khả dụng, hay số lượng sau khi trừ giữ hàng; nguồn dữ liệu nào là canonical?”

Authority: Business Owner quyết định ý nghĩa nghiệp vụ. Architect xác nhận nguồn dữ liệu và khả năng tích hợp. BA ghi nhận câu trả lời, traceability và trạng thái; BA không tự quyết định.

Artifact: Tham chiếu đúng CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES và /01-curriculum/TRACEABILITY_ID_REGISTRY.md; không tạo ID, rule, API hay approval mới.

Consequence if Wrong: Developer có thể chặn đơn hợp lệ hoặc cho xác nhận đơn không thể đáp ứng. QA kiểm tra sai test basis. Operations nhận cam kết giao hàng sai.

Senior Lens

Escalate khi câu trả lời thay đổi tiền, sổ sách, dữ liệu cá nhân, an toàn thực phẩm, quyền truy cập, kiến trúc, hoặc vận hành. Lý do: các miền này cần thẩm quyền chuyên môn; handbook chỉ là học liệu Nova Foods mô phỏng. Không đổi câu hỏi làm rõ thành khẳng định pháp lý, kế toán hoặc tuân thủ.

Quick Reference

Khi thấy	Hỏi
Động từ mơ hồ: kiểm tra, xử lý, đồng bộ	“Kích hoạt khi nào, dữ liệu nào, kết quả nào, ngoại lệ nào?”
Danh từ mơ hồ: tồn kho, khách hàng, phê duyệt	“Định nghĩa canonical nằm ở artifact nào?”
Quyết định chưa rõ owner	“Ai có thẩm quyền quyết định, bằng chứng nào xác nhận?”
Yêu cầu nhạy cảm	“Có cần Legal Owner, Accounting Owner, Security, Architect hoặc Operations xác minh không?”

8. Detailed Worked Example

Core

Ví dụ worked example là tình huống xuyên suốt để BA biến quan sát thành Functional Specification. Phần đầu chỉ ghi Facts (sự kiện có bằng chứng) và Current Behavior (hành vi hệ thống hiện tại). Không suy diễn nhu cầu, không đề xuất giải pháp, không gọi đó là quyết định đã được phê duyệt.

Applied

Bối cảnh: Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục. Toàn bộ tổ chức, người dùng, mã hàng, số lượng và tiền tệ dưới đây là dữ liệu tổng hợp. Locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Không có baseline hoặc approval tại v0.9.0, trạng thái IN_REVIEW.

Kịch bản thống nhất: Nhân viên Kinh doanh tạo đơn bán hàng cho khách hàng phân phối. ERP hiện cho lưu đơn dù một dòng hàng chưa đủ số lượng tại kho giao.

Nhóm fact	Giá trị quan sát được
Thời điểm ghi nhận	2026-08-07 09:15:00 Asia/Ho_Chi_Minh
Người thao tác mô phỏng	Nhân viên Kinh doanh
Khách hàng mô phỏng	Siêu thị Ánh Dương
Kho giao mô phỏng	Kho Bình Dương
Hàng hóa dòng 1	Nước ép cam Nova 1L
Số lượng khách đặt dòng 1	120 thùng
Số lượng hệ thống hiển thị tại Kho Bình Dương	80 thùng
Hàng hóa dòng 2	Sữa hạt Nova 180ml
Số lượng khách đặt dòng 2	60 thùng
Số lượng hệ thống hiển thị tại Kho Bình Dương	60 thùng
Đơn giá mô phỏng dòng 1	420.000 VND/thùng
Đơn giá mô phỏng dòng 2	180.000 VND/thùng
Giá trị tính từ dữ liệu nhập	(120 × 420.000) + (60 × 180.000) = 61.200.000 VND
Bằng chứng hiện có	Màn hình tạo đơn hiển thị số lượng kho theo từng dòng; người dùng có thể chọn lưu đơn
Bằng chứng chưa có	Chưa có định nghĩa canonical cho “tồn kho đủ”, chưa có quy tắc giữ hàng, chưa có quy tắc chặn hoặc cảnh báo

Facts: Dòng 1 yêu cầu 120 thùng nhưng màn hình hiển thị 80 thùng. Chênh lệch quan sát được là 40 thùng, tính bằng 120 - 80. Dòng 2 yêu cầu đúng 60 thùng và màn hình hiển thị 60 thùng. Hai dòng cùng một đơn, cùng kho giao, nên chênh lệch không thể được che bởi việc dòng 2 đủ hàng. Đây là dữ kiện số học từ dữ liệu mô phỏng, không phải kết luận về khả năng đáp ứng thực tế.

Current Behavior: Khi người dùng nhấn lưu, hệ thống lưu đơn với cả hai dòng và không hiển thị thông báo khác biệt giữa số lượng đặt với số lượng kho đang hiển thị. Hệ thống cũng không ghi nhận trên màn hình liệu 80 thùng là tồn kho vật lý, tồn kho khả dụng, hay số lượng đã trừ giữ hàng. Vì không có bằng chứng về nguồn tính hoặc thời điểm đồng bộ, BA phải ghi “Verification required” thay vì gọi số 80 là số lượng có thể giao.

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

flowchart TB
    A[Nhân viên Kinh doanh nhập đơn] --> B[Đơn bán hàng<br/>Kho giao: Kho Bình Dương]
    B --> C[Dòng 1: Nước ép cam Nova 1L<br/>Đặt: 120 thùng]
    B --> D[Dòng 2: Sữa hạt Nova 180ml<br/>Đặt: 60 thùng]
    C --> E[Màn hình hiển thị: 80 thùng]
    D --> F[Màn hình hiển thị: 60 thùng]
    E --> G[Chênh lệch quan sát: 40 thùng<br/>120 - 80]
    F --> H[Chênh lệch quan sát: 0 thùng<br/>60 - 60]
    G --> I[Người dùng nhấn lưu]
    H --> I
    I --> J[Đơn được lưu với cả hai dòng]
    J --> K[Không có cảnh báo hoặc chặn quan sát được]
    E -.-> L[Verification required:<br/>80 thùng chưa xác định là tồn kho nào]

Ranh giới ghi nhận: sơ đồ mô tả hành vi quan sát trong case study mô phỏng, không phải BPMN và không mô tả tích hợp ERP, cơ chế phân bổ kho, chứng từ kế toán, hóa đơn, hay yêu cầu pháp lý.

Senior Lens

Tách fact khỏi diễn giải. “Hiển thị 80 thùng” là fact có thể kiểm tra lại. “Kho không đủ giao” là diễn giải, vì chưa biết định nghĩa tồn kho và chưa biết đơn khác có đang giữ hàng. Senior BA giữ cả dữ liệu nguồn, phép tính và khoảng trống xác minh để bước sau không biến giả định thành business rule.

Quick Reference

Thành phần	Cách ghi đúng	Không ghi
Fact	“Màn hình hiển thị 80 thùng; khách đặt 120 thùng.”	“Kho chắc chắn thiếu hàng.”
Current Behavior	“Nhấn lưu, đơn được lưu, không quan sát thấy cảnh báo.”	“Hệ thống cho phép bán vượt tồn kho.”
Khoảng trống	“Verification required: ý nghĩa và nguồn của số lượng hiển thị.”	“80 thùng là tồn kho khả dụng.”
Phạm vi	Nova Foods mô phỏng; dữ liệu tổng hợp.	Khẳng định cấu hình ERP hoặc vận hành thực tế.

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. Tình huống: ERP chặn xuất kho lô nguyên liệu đã quá hạn cho lệnh sản xuất.

Bước	Nội dung đầy đủ	Bằng chứng hoặc cầu nối suy luận
Facts	Ngày 2026-08-07, kho WH-HCM-RM có lô RM-SUG-260701-A, mặt hàng Đường tinh luyện, tồn khả dụng 500 kg, ngày hết hạn 2026-08-05. Lệnh sản xuất MO-20260807-014 cần 300 kg ngày 2026-08-07. Giá trị tham chiếu nội bộ: 18.000 VND/kg; giá trị lô 9.000.000 VND.	Ngày hiện tại sau ngày hết hạn 2 ngày. Lô còn đủ số lượng nên kiểm tra tồn kho đơn thuần vẫn cho phép cấp phát.
Current Behavior	Nhân viên kho tạo phiếu xuất nguyên liệu, ERP chỉ kiểm tra available_quantity >= requested_quantity. Hệ thống không so sánh expiry_date với ngày hạch toán phiếu xuất. Lô quá hạn vẫn được chọn và trừ tồn.	Quy tắc hiện tại kiểm tra số lượng, không kiểm tra trạng thái sử dụng của lô. Vì 500 >= 300, phiếu xuất được tạo.
Underlying Need	Hệ thống cần ngăn cấp phát lô có expiry_date < posting_date, giữ bằng chứng lý do chặn, và buộc người dùng chọn lô hợp lệ khác. Đây là nhu cầu kiểm soát nghiệp vụ, không phải kết luận pháp lý hay xác nhận tuân thủ an toàn thực phẩm.	Chỉ sửa giao diện cảnh báo không đủ vì người dùng vẫn có thể lưu phiếu. Cần kiểm soát tại điểm hệ thống xác nhận cấp phát.
Options	O1: hiện cảnh báo nhưng vẫn cho lưu. O2: chặn lưu mọi dòng dùng lô quá hạn. O3: tự động đổi sang lô hợp lệ theo FEFO (First Expired, First Out — ưu tiên lô hết hạn sớm nhất) rồi cho lưu.	O1 không loại rủi ro xuất nhầm. O3 thay đổi lựa chọn vật lý của kho và cần quy tắc ưu tiên, vị trí, chất lượng, ngoại lệ chưa có nguồn quyết định.
Decision Criteria	C1: không cho xuất lô quá hạn. C2: không tự đổi lô khi chưa có xác nhận kho. C3: thông báo nêu rõ lô, ngày hết hạn, ngày phiếu. C4: giữ nguyên dữ liệu tồn kho khi chặn. C5: phạm vi thay đổi nhỏ, không tạo quy tắc kế toán hay pháp lý mới.	C1 xử lý nguyên nhân. C2 tránh ERP tự quyết thay nhân viên kho. C3 giúp sửa đúng dòng. C4 ngăn mất dữ liệu hoặc trừ tồn sai.
Decision	Khuyến nghị BA: chọn O2. Khi người dùng lưu hoặc xác nhận phiếu xuất nguyên liệu, ERP từ chối từng dòng có expiry_date < posting_date; không tạo bút toán tồn kho, không giảm tồn, không tự thay lô.	O2 đạt đủ C1–C5. Đây mới là khuyến nghị trong artifact IN_REVIEW, không phải quyết định đã được phê duyệt.
Authority	Business Owner quyết định chấp nhận quy tắc vận hành. Warehouse Manager xác nhận quy trình kho và cách xử lý lô bị chặn. QA/Food Safety Owner xác nhận tiêu chí “quá hạn” phù hợp chính sách chất lượng. Solution Architect xác nhận điểm kiểm soát ERP. Legal Owner xác minh nghĩa vụ pháp lý nếu quy tắc được tuyên bố là yêu cầu tuân thủ.	Principal IT Business Analyst / Technical Curriculum Author chỉ ghi nhận, truy vết và soạn đặc tả; không có thẩm quyền tự phê duyệt. Tại v0.9.0, không có authorized decision được ghi nhận.
Artifact	Bổ sung requirement, business rule, acceptance criteria và test basis vào /02-handbook/09-functional-specification-writing.md; tham chiếu governance: CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY. Các artifact này đều IN_REVIEW, v0.9.0, ngày 2026-08-07.	Tách requirement khỏi quyết định thẩm quyền. Không gán ID canonical mới khi registry chưa ghi nhận ID đó.
Consequence if Wrong	Nếu chọn O1, kho có thể xuất 300 kg lô quá hạn; tồn hệ thống giảm còn 200 kg dù vật tư không nên được cấp phát. Nếu chọn O3 khi chưa có thẩm quyền, ERP có thể cấp sai lô, sai vị trí hoặc phá vỡ kiểm soát kho. Nếu diễn đạt đây là nghĩa vụ pháp lý, tài liệu vượt thẩm quyền và cần Legal Owner xác minh.	Sai quyết định gây rủi ro chất lượng, truy vết và tồn kho; sai thẩm quyền gây rủi ro governance.

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

flowchart TB
    A[O2: khuyến nghị BA<br/>Business Owner chưa phê duyệt] --> B[Nhân viên kho chọn lô]
    B --> C[Lưu hoặc xác nhận phiếu]
    C --> D[ERP nhận ngày phiếu và ngày hết hạn]
    D --> E{expiry_date < posting_date?}

    E -- Có --> F[Từ chối dòng dùng lô quá hạn]
    F --> G[Lưu bằng chứng lý do chặn]
    F --> H[Hiện lô, ngày hết hạn, ngày phiếu]
    F --> I[Phiếu chưa xác nhận]
    F --> J[Tồn không đổi, không tạo giao dịch tồn kho]
    F --> K[Không tự thay lô]
    H --> L[Yêu cầu chọn lô hợp lệ khác]
    L --> B

    E -- Không --> M[Kiểm tra tồn khả dụng]
    M --> N{available_quantity >= requested_quantity?}
    N -- Có --> O[Cho phép tiếp tục lưu hoặc xác nhận theo thao tác]
    N -- Không --> P[Chặn do thiếu tồn]

Thành phần đặc tả	Nội dung đề xuất để review
Business rule	Khi xác nhận xuất nguyên liệu, ERP phải chặn dòng phiếu nếu lot.expiry_date < issue.posting_date.
Thông báo lỗi	Không thể xuất lô RM-SUG-260701-A: ngày hết hạn 2026-08-05 trước ngày phiếu 2026-08-07.
Dữ liệu tối thiểu	lot_id, item_id, expiry_date, available_quantity, posting_date, requested_quantity, warehouse_id.
Payload kiểm tra	{"warehouse_id":"WH-HCM-RM","lot_id":"RM-SUG-260701-A","item_id":"SUGAR-REFINED","expiry_date":"2026-08-05","posting_date":"2026-08-07","available_quantity_kg":500,"requested_quantity_kg":300,"currency":"VND"}
Kết quả mong đợi	HTTP/API hay giao diện ERP phải trả lỗi nghiệp vụ; phiếu chưa xác nhận; tồn khả dụng vẫn 500 kg; không sinh giao dịch tồn kho.
Verification required	QA/Food Safety Owner xác minh cách xác định ngày hết hạn; Legal Owner xác minh khi liên hệ Luật An toàn thực phẩm 55/2010/QH12.

Senior Lens

Facts không tự tạo quyết định. Facts cho thấy lỗ hổng: lô quá hạn vẫn qua vì kiểm tra hiện tại chỉ xét số lượng. Need nêu kết quả cần bảo vệ. Options tránh khóa giải pháp quá sớm. Decision chỉ thành authorized decision sau khi vai trò có thẩm quyền ghi nhận rõ trong artifact kiểm soát.

Quick Reference

Facts → Current Behavior → Underlying Need → Options → Decision Criteria → Decision → Authority → Artifact → Consequence if Wrong

Khuyến nghị hiện tại: O2, chặn lô quá hạn. Trạng thái: IN_REVIEW, v0.9.0; chưa có approval, baseline, hay production authority.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp. Bảng dưới là gói đặc tả hoàn chỉnh cho luồng giữ hàng tồn kho khi tạo đơn bán SO-20260807-001; không phải quyết định vận hành thật, không phải cấu hình production.

Loại	ID canonical	Giá trị
Functional requirement	FR-SD-001	ERP phải chỉ xác nhận đơn bán khi tồn khả dụng đủ cho toàn bộ dòng hàng.
Business rule	BR-INV-001	Tồn khả dụng = tồn vật lý đã nhập kho − số lượng đã giữ − số lượng đã xuất.
Business rule	BR-INV-002	Hệ thống không được giữ số lượng vượt tồn khả dụng tại thời điểm xác nhận.
Data entity	SalesOrder	Đơn bán; khóa salesOrderId.
Data entity	SalesOrderLine	Dòng đơn bán; khóa salesOrderLineId.
Data entity	InventoryBalance	Số dư tồn theo kho và mã hàng.
Data entity	InventoryReservation	Bản ghi giữ hàng theo dòng đơn.
API	POST /api/v1/sales-orders/SO-20260807-001/confirm	Xác nhận đơn bán và tạo giữ hàng.
Artifact	/02-handbook/09-functional-specification-writing.md	Tài liệu học liệu chứa ví dụ.
Rule source boundary	CANONICAL_BUSINESS_RULES	Catalog kế hoạch quy tắc canonical; IN_REVIEW, v0.9.0.
Data source boundary	CANONICAL_DATA_DICTIONARY	Từ điển dữ liệu logic kế hoạch; IN_REVIEW, v0.9.0.

Dữ liệu đầu vào của scenario SC-SD-001:

Trường	Giá trị
salesOrderId	SO-20260807-001
customerId	CUS-000128
warehouseId	WH-HCM-01
orderDate	2026-08-07T09:15:00+07:00
currencyCode	VND
productId dòng 1	SKU-NF-CHILI-500
orderedQuantity dòng 1	120
productId dòng 2	SKU-NF-FISH-500
orderedQuantity dòng 2	80

Trạng thái tồn trước xác nhận:

warehouseId	productId	Tồn vật lý	Đã giữ	Đã xuất	Tồn khả dụng theo BR-INV-001
WH-HCM-01	SKU-NF-CHILI-500	500	350	0	150
WH-HCM-01	SKU-NF-FISH-500	200	130	0	70

Dòng SKU-NF-CHILI-500 đủ: 150 >= 120. Dòng SKU-NF-FISH-500 thiếu: 70 < 80. Bằng chứng này dẫn tới kết luận: đơn không thể được xác nhận toàn phần nếu áp dụng BR-INV-002.

Khuyến nghị BA: trả 409 Conflict, không tạo bất kỳ InventoryReservation nào. Khuyến nghị giữ tính nguyên tử: hoặc giữ đủ mọi dòng, hoặc không giữ dòng nào. Lý do: giữ riêng dòng đủ tạo đơn dở dang; bộ phận kho và chăm sóc khách hàng phải xử lý trạng thái giao hàng không nhất quán.

Quyết định được ủy quyền: chưa có. CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, mọi requirement và ví dụ Nova Foods đều IN_REVIEW, v0.9.0; không có baseline reference hay approval reference. Business Owner quyết định chính sách giao một phần. Architect xác nhận giao dịch nguyên tử. QA Owner xác nhận test basis. BA chỉ ghi rõ khuyến nghị và truy vết.

Payload yêu cầu:

{
  "salesOrderId": "SO-20260807-001",
  "warehouseId": "WH-HCM-01",
  "confirmedAt": "2026-08-07T09:15:00+07:00",
  "currencyCode": "VND"
}

Payload phản hồi khi áp dụng khuyến nghị:

{
  "salesOrderId": "SO-20260807-001",
  "status": "PENDING_CONFIRMATION",
  "reasonCode": "INSUFFICIENT_AVAILABLE_STOCK",
  "failedLines": [
    {
      "salesOrderLineId": "SOL-20260807-001-02",
      "productId": "SKU-NF-FISH-500",
      "requestedQuantity": 80,
      "availableQuantity": 70,
      "shortageQuantity": 10
    }
  ],
  "reservationCreated": false
}

sequenceDiagram
    participant U as Nhân viên bán hàng
    participant ERP as Nova Foods ERP
    participant INV as InventoryBalance
    U->>ERP: Confirm SO-20260807-001
    ERP->>INV: Đọc tồn khả dụng cho 2 dòng
    INV-->>ERP: Chili=150; Fish=70
    ERP->>ERP: So sánh với 120 và 80
    ERP-->>U: 409 INSUFFICIENT_AVAILABLE_STOCK
    Note over ERP,INV: Không tạo InventoryReservation

Nếu đặc tả sai và hệ thống vẫn giữ 120 chai SKU-NF-CHILI-500, tồn khả dụng chai ớt giảm từ 150 xuống 30 dù đơn chưa xác nhận. Hậu quả: đơn khác có thể bị từ chối sai, kho thấy hàng bị khóa không có đơn hợp lệ, báo cáo tồn khả dụng sai. Điều kiện kiểm thử phải kiểm tra cả phản hồi 409 lẫn số bản ghi InventoryReservation = 0 cho SO-20260807-001.

9. Related Concepts & Dependencies

Core

Dependency là quan hệ phụ thuộc: artifact này cần artifact khác làm nguồn đầu vào, hoặc artifact khác cần đầu ra của artifact này. Canonical source of truth là nguồn duy nhất được quyền chứa nội dung gốc đang kiểm soát. Functional Specification không sao chép lại định nghĩa rule, trường dữ liệu, ID hay cấu trúc template từ nguồn canonical. Nó chỉ tham chiếu đúng Artifact ID, đường dẫn, phiên bản và vị trí nội dung cần dùng.

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi dữ liệu là tổng hợp. Tại IN_REVIEW, v0.9.0, ngày 2026-08-07, liên kết không chứng minh baseline, approval, cấu hình ERP thật hay thẩm quyền production.

Loại phụ thuộc	Nguồn canonical	Functional Specification dùng gì	Không được tự tạo lại
Cấu trúc chapter	CHAPTER_MANIFEST tại /01-curriculum/CHAPTER_MANIFEST.md	Tên chapter, filename, phạm vi chapter	Chapter ID, đường dẫn chuẩn
Cấu trúc template	TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md	Template phù hợp để ghi đặc tả	Bản template cạnh tranh
Định danh truy vết	TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md	ID đã đăng ký và quy tắc đặt ID	ID mới, biến thể ID, ID dịch thuật
Quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md	Tham chiếu rule áp dụng và phiên bản	Bản sao rule trong đặc tả
Dữ liệu logic	CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tên trường, nghĩa, kiểu logic, phân loại dữ liệu	Định nghĩa dữ liệu khác nghĩa
Nguồn nghiên cứu	00_SOURCE_MAP tại /00-research/00_SOURCE_MAP.md	Phân loại nguồn và safe use boundary	Trích dẫn pháp lý hay chuẩn không xác minh

Lý do không sao chép: hai bản cùng nói về một rule sẽ có thể lệch nhau sau sửa đổi. Khi người đọc thấy CANONICAL_BUSINESS_RULES là nguồn rule, họ biết phải kiểm tra một nơi. Functional Specification giữ vai trò ghép rule, luồng, dữ liệu và hành vi hệ thống cho một chức năng; nó không chiếm quyền sở hữu nguồn gốc.

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

flowchart TB
    SM["00_SOURCE_MAP<br/>Nguồn và safe use boundary"]
    CM["CHAPTER_MANIFEST<br/>Tên chapter, filename, phạm vi"]
    TM["TEMPLATE_MANIFEST<br/>Template phù hợp để ghi đặc tả"]
    IR["TRACEABILITY_ID_REGISTRY<br/>ID đã đăng ký, quy tắc đặt ID"]
    BR["CANONICAL_BUSINESS_RULES<br/>Rule áp dụng, phiên bản"]
    DD["CANONICAL_DATA_DICTIONARY<br/>Tên trường, nghĩa, kiểu logic, phân loại"]

    FS["Functional Specification<br/>Ghép rule, luồng, dữ liệu, hành vi<br/>Tham chiếu, không sao chép"]

    QA["Test artifact<br/>downstream artifact"]
    DEV["Build/API artifact<br/>downstream artifact"]

    SM -->|phân loại nguồn, boundary| FS
    CM -->|cung cấp cấu trúc chapter| FS
    TM -->|cung cấp template phù hợp| FS
    IR -->|cung cấp ID đã đăng ký| FS
    BR -->|cung cấp rule canonical| FS
    DD -->|cung cấp dữ liệu canonical| FS

    FS -->|làm đầu vào kiểm thử| QA
    FS -->|làm đầu vào build/API| DEV

Applied

Facts: SO-20260807-001 có hai dòng hàng; trường salesOrderId, warehouseId, confirmedAt và currencyCode đã xuất hiện trong ví dụ xác nhận đơn bán. currencyCode có giá trị tổng hợp VND. Corpus kiểm soát ID tại TRACEABILITY_ID_REGISTRY và định nghĩa dữ liệu logic tại CANONICAL_DATA_DICTIONARY.

Current Behavior: BA có thể chép định nghĩa currencyCode vào từng Functional Specification để người đọc đỡ phải mở nguồn khác. Cách này tạo nhiều bản định nghĩa cho cùng trường dữ liệu.

Underlying Need: Người đọc cần biết chức năng xác nhận đơn bán dùng trường nào, nhưng phải tìm được nơi quyết định nghĩa chuẩn, kiểu dữ liệu và thay đổi của trường đó.

Options:
1. Chép đầy đủ định nghĩa currencyCode vào Functional Specification.
2. Chỉ ghi tên trường không có nguồn.
3. Ghi trường trong payload và tham chiếu CANONICAL_DATA_DICTIONARY là nguồn định nghĩa.

Decision Criteria: Một lựa chọn tốt phải giữ một nguồn gốc duy nhất, cho phép QA và development truy ngược, không tạo ID hay nghĩa dữ liệu mới, và không diễn giải VND thành quyết định kế toán thật.

Decision: Chọn phương án 3. Functional Specification ghi currencyCode là trường payload dùng trong luồng xác nhận đơn; định nghĩa canonical nằm tại CANONICAL_DATA_DICTIONARY. ID liên quan chỉ dùng nếu đã có trong TRACEABILITY_ID_REGISTRY.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết artifact và ID. Accounting Owner hoặc Legal Owner phải xác minh mọi diễn giải kế toán, thuế hay pháp lý. Owner không tự phê duyệt nội dung.

Artifact: /02-handbook/09-functional-specification-writing.md tham chiếu /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, CHAPTER_MANIFEST và TEMPLATE_MANIFEST; không chép catalog vào handbook.

Consequence if Wrong: Nếu đặc tả định nghĩa currencyCode khác data dictionary, development có thể gửi mã tiền tệ theo một nghĩa còn QA kiểm theo nghĩa khác. Nếu ID tự đặt không được registry quản lý, downstream artifact không truy được về nguồn và thay đổi sau này không biết phải sửa nơi nào.

Senior Lens

Phân biệt tham chiếu với sao chép. Tham chiếu tối thiểu gồm Artifact ID, đường dẫn canonical, phiên bản đang dùng và đối tượng được dùng. Ví dụ: “Payload dùng currencyCode; xem CANONICAL_DATA_DICTIONARY, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, v0.9.0, IN_REVIEW.” Câu này đủ để truy nguồn mà không tạo định nghĩa thứ hai.

Dependency upstream cung cấp ràng buộc trước khi viết đặc tả: manifest giữ phạm vi, registry giữ ID, rule catalog giữ rule, data dictionary giữ nghĩa dữ liệu, source map giữ boundary nguồn. Dependency downstream nhận đầu ra: QA dùng hành vi và điều kiện để lập kiểm thử; development và integration dùng payload, lỗi, trạng thái và liên kết canonical để xây dựng. Functional Specification đứng giữa, không thay thế artifact hai phía.

Không gọi nội dung là “đã phê duyệt” vì IN_REVIEW chỉ là trạng thái xem xét. Không suy ra nghĩa pháp lý, kế toán, thuế, bảo mật hay an toàn thực phẩm từ ví dụ Nova Foods. Khi dependency thiếu, mâu thuẫn, hoặc ID chưa đăng ký, ghi nhận khoảng trống và dừng diễn giải; không bù bằng rule tự tạo.

Quick Reference

Quy tắc	Cách làm
Một khái niệm, một nguồn gốc	Liên kết nguồn canonical; không chép lại định nghĩa
Một ID, một registry	Dùng nguyên chuỗi ID từ TRACEABILITY_ID_REGISTRY
Một filename, một manifest	Dùng đường dẫn từ CHAPTER_MANIFEST hoặc TEMPLATE_MANIFEST
Rule không nằm trong đặc tả	Tham chiếu CANONICAL_BUSINESS_RULES
Dữ liệu không tự định nghĩa	Tham chiếu CANONICAL_DATA_DICTIONARY
Nguồn chuẩn và pháp lý có boundary	Kiểm tra 00_SOURCE_MAP trước khi diễn giải
Trạng thái kiểm soát	Giữ IN_REVIEW, v0.9.0, 2026-08-07; không suy ra baseline hay approval

Core

Traceability là khả năng lần từ nhu cầu đến kiểm thử bằng ID ổn định. Mỗi dòng chỉ lưu liên kết và trạng thái liên kết; nội dung đầy đủ vẫn thuộc artifact canonical. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Loại	Ý nghĩa	Nguồn canonical cần tham chiếu	Liên kết tối thiểu
NEED	Nhu cầu vấn đề cần giải quyết	Backlog nhu cầu đã đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md	NEED liên kết ít nhất một REQ
REQ	Requirement, yêu cầu hệ thống có thể kiểm tra	Functional specification	REQ liên kết NEED, BR, AC, DATA/API, TC khi áp dụng
BR	Business Rule, quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md	BR liên kết REQ chịu tác động
AC	Acceptance Criteria, điều kiện chấp nhận có thể quan sát	Functional specification hoặc artifact acceptance criteria canonical	AC liên kết đúng một REQ
DATA/API	Thuộc tính dữ liệu hoặc hợp đồng giao tiếp hệ thống	/01-curriculum/CANONICAL_DATA_DICTIONARY.md hoặc OpenAPI artifact được kiểm soát	Liên kết REQ dùng, tạo, đọc hoặc gửi dữ liệu
TC	Test Case, ca kiểm thử xác minh hành vi	Test artifact được kiểm soát	TC liên kết AC và REQ kiểm thử

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

flowchart TB
    NEED[NEED: nhu cầu] --> REQ[REQ: yêu cầu]
    BR[BR: quy tắc nghiệp vụ] --> REQ
    REQ --> AC[AC: điều kiện chấp nhận]
    REQ --> DATA[DATA/API: dữ liệu hoặc giao tiếp]
    REQ --> TC[TC: ca kiểm thử]
    AC --> TC

Applied

Trường	Nội dung case mô phỏng Nova Foods
Facts	Người dùng kho cần ghi nhận lô hàng thành phẩm trước khi xuất kho. Dữ liệu lô là dữ liệu tổng hợp.
Current Behavior	Chưa có bằng chứng artifact canonical xác nhận hành vi ERP hiện tại. Không được suy diễn cấu hình production.
Underlying Need	Cần truy vết lô thành phẩm trong luồng xuất kho mô phỏng.
Options	Liên kết REQ trực tiếp với TC; hoặc liên kết đủ NEED–REQ–BR–AC–DATA/API–TC.
Decision Criteria	Chuỗi phải chỉ rõ nguồn nghiệp vụ, điều kiện kiểm tra và trường dữ liệu; không nhân bản nội dung quy tắc trong specification.
Decision	Dùng chuỗi đầy đủ khi requirement có quy tắc, dữ liệu hoặc tích hợp.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết; Business Owner, QA, Architect và domain owner xác nhận phần thuộc thẩm quyền. Chưa có approval.
Artifact	Traceability matrix trong functional specification tham chiếu /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
Consequence if Wrong	TC có thể kiểm tra màn hình nhưng bỏ sót quy tắc lô hoặc trường dữ liệu; lỗi truy vết chỉ lộ khi kiểm thử tích hợp.

NEED	REQ	BR	AC	DATA/API	TC	Bằng chứng liên kết
ID đã đăng ký trong TRACEABILITY_ID_REGISTRY	ID đã đăng ký trong TRACEABILITY_ID_REGISTRY	ID trong CANONICAL_BUSINESS_RULES	ID trong artifact AC canonical	ID trường trong CANONICAL_DATA_DICTIONARY hoặc operation ID OpenAPI canonical	ID trong test artifact canonical	Mỗi ô chứa ID nguyên dạng, đường dẫn artifact và version tham chiếu
Nhu cầu truy vết lô thành phẩm mô phỏng	Yêu cầu ghi nhận mã lô khi xuất kho mô phỏng	Quy tắc kiểm tra mã lô, nếu đã được đăng ký	Điều kiện chấp nhận yêu cầu mã lô hợp lệ	LotCode, nếu đã định nghĩa canonical	Ca kiểm thử nhập mã lô hợp lệ và không hợp lệ	Không tạo ID cục bộ trong handbook; tra registry trước khi ghi

Senior Lens

Không dùng bảng traceability làm nguồn chân lý mới. BR chỉ trỏ đến CANONICAL_BUSINESS_RULES; tên trường chỉ trỏ đến CANONICAL_DATA_DICTIONARY; API chỉ trỏ đến OpenAPI artifact canonical. Lý do: sao chép nội dung tạo hai bản có thể lệch nhau, còn ID và đường dẫn giữ một nguồn kiểm soát.

Liên kết REQ đến TC chưa đủ nếu requirement bị chi phối bởi dữ liệu hoặc quy tắc. Bằng chứng: test chỉ biết kết quả mong đợi từ AC; nếu AC không trỏ BR và DATA/API, QA không biết điều kiện hay trường nào tạo kết quả đó. Với dữ liệu cá nhân, kế toán, thuế, an toàn thực phẩm hoặc tích hợp ngoài, giữ nhãn Verification required cho đến khi owner có thẩm quyền xác nhận nguồn áp dụng.

Quick Reference

Kiểm tra trước khi ghi liên kết	Đạt khi
ID tồn tại	ID tra được trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md hoặc artifact canonical được chỉ định
Nguồn đúng	BR không bị chép vào specification; dữ liệu không bị chép thành data dictionary mới
Testability	Mỗi REQ có AC; mỗi AC có ít nhất một TC khi requirement cần kiểm thử
Dữ liệu và tích hợp	REQ dùng trường hoặc API phải trỏ DATA/API tương ứng
Governance	Mọi tham chiếu giữ IN_REVIEW, v0.9.0, 2026-08-07; không diễn giải thành baseline hoặc approval

Core

Thay đổi phụ thuộc phải lan truyền có kiểm soát. Phụ thuộc là artifact, dữ liệu, quy tắc, giao diện hoặc định danh mà Functional Specification dùng làm đầu vào. Khi nguồn thay đổi, mọi nội dung đã diễn giải từ nguồn phải được rà soát; không được tự giả định nội dung cũ còn đúng.

Thay đổi im lặng là sửa nội dung, cấu trúc, giá trị dữ liệu, tên trường, trạng thái hoặc ID nhưng không ghi nhận version, lịch sử thay đổi, phạm vi ảnh hưởng và liên kết cần rà soát. Hậu quả không chỉ là lỗi tài liệu. Requirement có thể mô tả dữ liệu không còn tồn tại; API có thể gửi trường sai; test case kiểm tra hành vi cũ; đội phát triển tạo cấu hình trái quy tắc nguồn.

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

flowchart TB
    A[Dependency canonical thay đổi] --> B[Mở change record và version nháp]
    B --> C[Phân tích phạm vi ảnh hưởng]

    C --> D[Rà soát Functional Specification]
    C --> E[Rà soát API và Data mapping]
    C --> F[Rà soát Acceptance Criteria và Test Case]

    D --> G[Hoàn tất cập nhật mọi nội dung bị ảnh hưởng]
    E --> G
    F --> G

    G --> H[Review theo thẩm quyền]
    H --> I{Được phê duyệt?}
    I -->|Không| C
    I -->|Có| J[Cập nhật liên kết truy vết]
    J --> K[Chốt version và lịch sử thay đổi]

Applied

Facts. Nova Foods là case study mô phỏng, chỉ dùng dữ liệu tổng hợp. /01-curriculum/CANONICAL_DATA_DICTIONARY.md đổi tên logic trường từ delivery_address sang shipping_address. Functional Specification đang mô tả màn hình tạo Sales Order bằng tên cũ.

Current Behavior. Tài liệu Functional Specification vẫn ghi delivery_address; API mapping và test case có thể tiếp tục dùng chuỗi này nếu không nhận được thông báo thay đổi.

Underlying Need. Giữ cùng một nghĩa nghiệp vụ “địa chỉ giao hàng” xuyên suốt tài liệu, giao diện, API và kiểm thử, đồng thời chỉ có một nguồn chân lý cho định nghĩa dữ liệu.

Options.

Lựa chọn	Cách làm	Rủi ro
Giữ tên cũ trong Functional Specification	Không sửa artifact phụ thuộc	Tạo lệch dữ liệu với nguồn canonical
Sao chép định nghĩa mới vào Functional Specification	Chép đầy đủ định nghĩa trường	Tạo nguồn chân lý thứ hai, dễ lệch ở lần đổi sau
Tham chiếu canonical và cập nhật điểm dùng	Giữ mô tả chức năng, liên kết đến CANONICAL_DATA_DICTIONARY	Cần phân tích đầy đủ phạm vi ảnh hưởng

Decision Criteria. Chọn phương án giữ một nguồn chân lý, bảo toàn ID và đường dẫn canonical, truy được nội dung bị ảnh hưởng, không tự xác nhận quyết định kiến trúc hay production.

Decision. Chọn tham chiếu CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md; cập nhật mọi chỗ dùng delivery_address thành shipping_address sau khi kiểm tra phạm vi. Functional Specification không chép lại định nghĩa canonical của trường.

Authority. Principal IT Business Analyst / Technical Curriculum Author duy trì truy vết và ghi nhận thay đổi. Ý nghĩa dữ liệu, hợp đồng API, bảo mật hoặc quyết định triển khai cần review bởi Data Owner, Architect, Security hoặc vai trò có thẩm quyền tương ứng. IN_REVIEW tại v0.9.0 không phải baseline hoặc approval.

Artifact. Ghi một dòng change-impact trong Functional Specification: nguồn thay đổi là CANONICAL_DATA_DICTIONARY; đối tượng bị ảnh hưởng là mô tả trường, API mapping và kiểm thử; trạng thái xử lý là IN_REVIEW; ngày ghi nhận 2026-08-07, múi giờ Asia/Ho_Chi_Minh.

Consequence if Wrong. Nếu đổi tên im lặng, giao diện có thể hiển thị nhãn đúng nhưng gửi payload sai. API có thể trả lỗi hợp đồng hoặc bỏ qua trường. Test case vẫn xanh vì kiểm tra key cũ trong dữ liệu giả. Báo cáo hoặc tích hợp sau đó thiếu địa chỉ giao hàng dù requirement tưởng như đã được đáp ứng.

Senior Lens

Không phải mọi thay đổi đều có cùng mức ảnh hưởng. Đổi chính tả nhãn hiển thị có thể chỉ ảnh hưởng UI và accessibility. Đổi kiểu dữ liệu, giá trị bắt buộc, enum trạng thái, khóa định danh hoặc ý nghĩa trường có thể ảnh hưởng validation, API, migration, phân quyền và test data. Suy luận này dựa trên việc các thành phần đó thay đổi dữ liệu máy xử lý, không chỉ câu chữ người đọc thấy.

Dấu hiệu phải dừng và escalation: ID canonical biến mất, hai nguồn ghi nghĩa khác nhau cho cùng trường, thay đổi chạm dữ liệu cá nhân, hoặc Functional Specification phải tự quyết định hợp đồng API. Không thay ID cũ bằng ID mới theo suy đoán. Giữ liên kết cũ để điều tra, ghi nhận xung đột, rồi chờ nguồn có thẩm quyền làm rõ.

Quick Reference

Phụ thuộc đổi im lặng	Cái dễ vỡ	Kiểm soát tối thiểu
Tên hoặc kiểu trường dữ liệu	Mapping, validation, API payload	Rà soát mọi chỗ dùng trường
Quy tắc nghiệp vụ	Logic xử lý, thông báo lỗi, test	So sánh điều kiện trước và sau
Trạng thái quy trình	Workflow, quyền thao tác, báo cáo	Kiểm tra transition và ngoại lệ
ID hoặc đường dẫn canonical	Traceability, link review	Giữ ID nguyên dạng, không tự thay thế
Phiên bản nguồn	Bằng chứng review, khả năng tái lập	Ghi version, ngày, phạm vi ảnh hưởng

10. Common Mistakes & Anti-patterns

Core

Functional Specification là đặc tả chức năng: mô tả hệ thống phải làm gì, với dữ liệu nào, điều kiện nào, kết quả nào và cách kiểm chứng. Lỗi mới học thường xuất hiện khi người viết ghi lại ý kiến họ nghe được nhưng chưa biến thành hành vi có thể xây dựng và kiểm thử.

Sai lầm	Red flag quan sát được	Nguyên nhân gốc	Hành động sửa
Viết mục tiêu thay cho chức năng	“Hệ thống hỗ trợ quản lý đơn hàng hiệu quả” nhưng không có thao tác, điều kiện hay kết quả	Nhầm business goal với functional requirement	Tách mục tiêu khỏi chức năng; viết luồng, dữ liệu vào, xử lý, kết quả và acceptance criteria
Dùng từ không đo được	Có các từ “nhanh”, “đúng”, “dễ dùng”, “tự động”	Không xác định tiêu chí kiểm chứng	Thay bằng điều kiện quan sát được, ví dụ: “Hiển thị lỗi khi số lượng giao lớn hơn số lượng còn có thể giao”
Gộp nhiều hành vi vào một yêu cầu	Một câu chứa tạo đơn, duyệt giá, trừ tồn kho và xuất hóa đơn	Muốn viết ngắn nhưng che mất điểm quyết định	Tách theo hành vi hoặc bước xử lý; giữ liên kết cùng use case
Chỉ mô tả happy path	Không có lỗi nhập liệu, hủy, trùng dữ liệu, thiếu quyền	Chưa xem người dùng, hệ thống và dữ liệu có thể thất bại	Bổ sung alternate flow và exception flow; nêu điều kiện kích hoạt cùng phản hồi hệ thống
Chép màn hình thay cho logic	Specification có ảnh UI nhưng không nêu validation hoặc rule	Nhầm giao diện với chức năng	Giữ UI như minh họa; mô tả logic độc lập với vị trí nút hoặc màu sắc
Để developer tự đoán dữ liệu	Có trường “Ngày giao”, không nêu bắt buộc, định dạng, nguồn giá trị	Không dùng data dictionary khi viết	Liên kết trường tới CANONICAL_DATA_DICTIONARY; ghi rõ kiểu, bắt buộc, validation và hành vi khi lỗi
Viết lỗi chung chung	“Thông báo lỗi phù hợp”	Không xác định tình huống lỗi	Ghi điều kiện lỗi, thông điệp dự kiến, dữ liệu giữ lại và thao tác được phép tiếp tục
Sửa requirement nhưng không rà ảnh hưởng	Rule đổi nhưng test case, mockup và mapping không đổi	Delivery team làm việc theo tệp riêng	Ghi impact analysis trước khi sửa; cập nhật mọi artifact liên kết trong cùng change record

[!WARNING] Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Nếu Functional Specification bỏ qua kiểm tra số lượng có thể giao, hệ thống mô phỏng có thể xác nhận giao 120 thùng khi tồn khả dụng chỉ 100 thùng. Không tự “sửa số tồn” trong dữ liệu để làm luồng chạy. Biên phục hồi an toàn: dừng xác nhận, giữ dữ liệu đơn, hiển thị lý do, chuyển người dùng về bước điều chỉnh số lượng hoặc chọn phương án giao phù hợp.

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

flowchart TB
    A[Phát hiện requirement không kiểm thử được] --> B[Ghi red flag và phạm vi ảnh hưởng]
    B --> C[Đối chiếu luồng, dữ liệu, rule và acceptance criteria]
    C --> D{Đủ thông tin để sửa?}

    D -- Không --> E[Ghi câu hỏi làm rõ<br/>Giữ trạng thái IN_REVIEW]
    E --> F[Nhận câu trả lời làm rõ]
    F --> C

    D -- Có --> G[Ghi impact analysis trước khi sửa]
    G --> H[Cập nhật Functional Specification]
    H --> I[Cập nhật artifact liên kết<br/>trong cùng change record]
    I --> J[QA rà soát lại test basis,<br/>test case, mockup và mapping]
    J --> K{Artifact liên kết đã nhất quán?}

    K -- Không --> G
    K -- Có --> L[Hoàn tất: Functional Specification,<br/>artifact liên kết và test basis nhất quán<br/>trong cùng change record]

Applied

Facts. Trong Functional Specification mô phỏng Nova Foods, câu viết là: “Hệ thống tự động kiểm tra tồn kho trước khi xác nhận đơn bán.” Dữ liệu tổng hợp gồm đơn SO-SIM-001, mặt hàng FG-SIM-CHA-01, số lượng yêu cầu 120 thùng và số lượng có thể giao 100 thùng.

Current Behavior. Developer có thể hiểu “kiểm tra” là chỉ hiển thị số tồn. QA có thể hiểu “kiểm tra” là chặn xác nhận. Hai cách hiểu cùng khớp câu hiện có vì câu không nêu kết quả khi thiếu hàng.

Underlying Need. Người dùng cần tránh xác nhận số lượng vượt mức có thể giao. Suy luận này dựa trên chênh lệch giữa 120 thùng yêu cầu và 100 thùng có thể giao: nếu vẫn xác nhận toàn bộ, dữ liệu cam kết giao không phản ánh khả năng đáp ứng đang mô phỏng.

Options.

Phương án	Hành vi
A	Hiển thị cảnh báo, vẫn cho xác nhận 120 thùng
B	Chặn xác nhận khi số lượng yêu cầu lớn hơn số lượng có thể giao
C	Tự giảm số lượng từ 120 xuống 100 thùng

Decision Criteria. Cần bảo toàn số lượng người dùng đã nhập, ngăn dữ liệu cam kết vượt khả năng giao, và cho người dùng thấy lý do không thể tiếp tục. Tiêu chí này loại C vì hệ thống tự thay đổi ý định người dùng. Tiêu chí này ưu tiên B hơn A vì A vẫn tạo xác nhận vượt mức.

Decision. Viết lại chức năng: “Khi người dùng chọn Xác nhận đơn bán và tổng số lượng yêu cầu của FG-SIM-CHA-01 là 120 thùng, trong khi số lượng có thể giao là 100 thùng, hệ thống không tạo xác nhận đơn; hệ thống giữ số lượng đã nhập và hiển thị thông báo Số lượng yêu cầu vượt số lượng có thể giao.”

Authority. Đây là quyết định đặc tả trong case mô phỏng, chưa là approval, baseline, quy tắc vận hành thực tế hay cấu hình ERP production. Nếu có ngoại lệ cho phép bán vượt tồn, Business Owner và vai trò vận hành phù hợp phải làm rõ trước khi Functional Specification ghi hành vi.

Artifact. Ghi thay đổi trong /02-handbook/09-functional-specification-writing.md; liên kết dữ liệu tới CANONICAL_DATA_DICTIONARY; liên kết rule khi rule đã tồn tại trong CANONICAL_BUSINESS_RULES.

Consequence if Wrong. Nếu chọn A khi nhu cầu cần B, đơn mô phỏng có thể được xác nhận vượt khả năng giao. Nếu chọn C, số lượng khách yêu cầu bị thay đổi mà không có thao tác người dùng. Cả hai lỗi làm QA không có kết quả kỳ vọng duy nhất.

Senior Lens

Senior BA tìm lỗi bằng dấu vết có thể quan sát, không bằng cảm giác “câu này chưa ổn”. Một requirement tốt phải cho mỗi vai trò cùng kết quả: developer biết logic cần xây, QA biết điều kiện cần kiểm tra, UX biết trạng thái cần hiển thị, và business reviewer biết hậu quả nghiệp vụ.

Đừng sửa bằng cách thêm nhiều chữ. Sửa bằng dữ kiện thiếu nhỏ nhất: tác nhân, điều kiện, dữ liệu, hành động hệ thống, kết quả, lỗi hoặc ngoại lệ. Nếu thêm một điều kiện làm thay đổi phạm vi, quyền, accounting, legal, privacy hoặc integration, dừng tại điểm đó và ghi nhu cầu làm rõ; không tự tạo quy tắc mới.

Quick Reference

Kiểm tra trước khi giao Functional Specification	Đạt khi
Hành vi	Có tác nhân, điều kiện kích hoạt, xử lý và kết quả
Dữ liệu	Trường quan trọng có nguồn, định dạng, bắt buộc và validation
Ngoại lệ	Có phản hồi khi dữ liệu sai, thiếu, trùng hoặc không đủ điều kiện
Khả năng kiểm thử	QA viết được kết quả mong đợi mà không hỏi lại người viết
Ảnh hưởng	Thay đổi chức năng có rà soát luồng, dữ liệu, rule và test basis liên quan

Core

[!WARNING] Cảnh báo chỉ dùng khi lỗi có thể gây mất dữ liệu, hạch toán sai, truy xuất lô sai, lộ dữ liệu hoặc phát hành sai. Không dùng cảnh báo cho lỗi câu chữ hay sở thích trình bày. Cảnh báo phải nêu điều kiện kích hoạt, tác hại, người dừng xử lý và ranh giới khôi phục.

Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Functional Specification phải ghi ranh giới khôi phục an toàn: dữ liệu nào được sửa, dữ liệu nào phải giữ làm bằng chứng, ai có thẩm quyền quyết định. “Sửa đơn bán” không đủ. Cần ghi trạng thái đơn, giao dịch phát sinh sau đơn, tác động tồn kho, hóa đơn và log kiểm toán.

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

flowchart TB
    A[Phát hiện lỗi] --> B{Lỗi có thể gây mất dữ liệu, hạch toán sai, truy xuất lô sai, lộ dữ liệu hoặc phát hành sai?}
    B -- Không --> C[Ghi defect thường]
    B -- Có --> D[Functional Specification định danh: Người dừng xử lý, Người phê duyệt khôi phục, Người kiểm tra]

    D --> E{Có giao dịch, dữ liệu, hạch toán hoặc truy xuất lô bị ảnh hưởng?}
    E -- Có --> F[Người dừng xử lý chặn phần bị ảnh hưởng]
    E -- Không --> G{Có nguy cơ lộ dữ liệu?}
    F --> G

    G -- Có --> H[Người dừng xử lý thu hồi phiên hoặc quyền, khóa truy cập và xác nhận phạm vi lộ dữ liệu]
    G -- Không --> I{Có nguy cơ phát hành sai?}
    H --> I

    I -- Có --> J[Người dừng xử lý dừng phát hành bị ảnh hưởng]
    I -- Không --> K[Giữ nguyên bằng chứng: ID, thời điểm, log; cấm sửa hoặc xóa]
    J --> K

    K --> L[Đánh giá trạng thái đơn, giao dịch sau đơn, tồn kho, hóa đơn, hạch toán, truy xuất lô, phạm vi lộ dữ liệu, phát hành và log kiểm toán]
    L --> M{Có hậu quả cần đảo, điều chỉnh, xử lý truy cập hoặc xử lý phát hành?}

    M -- Không --> N[Người phê duyệt khôi phục phê duyệt bản ghi, trường và khoảng thời gian được sửa]
    M -- Có --> O[Người phê duyệt khôi phục phê duyệt xử lý hậu quả và ranh giới bản ghi, trường, khoảng thời gian được sửa]

    N --> P[Chỉ sửa dữ liệu được phê duyệt; giữ nguyên dữ liệu ngoài phạm vi và bằng chứng]
    O --> P

    P --> Q[Người kiểm tra kiểm tra: đơn, tồn kho, hóa đơn, hạch toán, truy xuất lô, truy cập, phát hành và log kiểm toán]
    Q --> R{Kết quả kiểm tra đạt?}
    R -- Không --> L
    R -- Có --> S[Đóng sự cố: liên kết defect, quyết định, thay đổi dữ liệu và log kiểm toán]

Applied

Mục	Nội dung artifact-ready
Facts	Đơn bán mô phỏng SO-NF-2026-0817 có dòng hàng RM-COCO-01, số lượng 500 kg. Sau khi kho đã tạo phiếu xuất mô phỏng DO-NF-2026-0441, người dùng sửa đơn thành 50 kg.
Current Behavior	Đặc tả ghi: “Người dùng có thể sửa số lượng đơn bán.” Không nêu trạng thái khóa, kiểm tra giao dịch sau đơn, hay cách khôi phục.
Underlying Need	Cần cho phép sửa trước khi phát sinh giao dịch phụ thuộc; sau đó phải bảo toàn dấu vết và tránh lệch giữa đơn, xuất kho, doanh thu mô phỏng.
Options	1. Cho sửa mọi lúc. 2. Khóa toàn bộ đơn sau tạo. 3. Cho sửa khi chưa có phiếu xuất; khi đã có phiếu xuất, tạo yêu cầu điều chỉnh có liên kết giao dịch gốc.
Decision Criteria	Không làm mất lịch sử; không tạo chênh lệch số lượng; có thể kiểm tra bằng ID giao dịch; phân quyền rõ; không tự suy diễn quy tắc kế toán.
Decision	Chọn phương án 3 cho mô hình học liệu. Quy tắc này là project assumption, không phải cấu hình ERP thật.
Authority	Business Owner xác nhận chính sách sửa đơn. Accounting Owner xác nhận xử lý chứng từ và ảnh hưởng hạch toán. QA xác nhận test basis. BA không tự xác nhận các quyết định này.
Artifact	Ghi trong /02-handbook/09-functional-specification-writing.md; liên kết ID đơn SO-NF-2026-0817 và phiếu xuất DO-NF-2026-0441; trạng thái corpus vẫn IN_REVIEW, version v0.9.0.
Consequence if Wrong	Nếu cho sửa trực tiếp sau xuất kho, đơn ghi 50 kg nhưng phiếu xuất giữ 500 kg. Báo cáo mô phỏng lệch 450 kg; truy vết sự cố không biết số nào là ý định gốc.

[!WARNING] Không xóa hoặc ghi đè SO-NF-2026-0817 để “sửa cho khớp”. Hành động này phá bằng chứng. Ranh giới khôi phục an toàn: giữ đơn gốc, phiếu xuất gốc, thời điểm phát hiện và lý do; chỉ tạo bản điều chỉnh sau khi người có thẩm quyền xác nhận. Không tự đảo chứng từ, tự đổi tồn kho hoặc tự kết luận ảnh hưởng kế toán.

Senior Lens

Cảnh báo tốt phải kiểm tra được. Mẫu tối thiểu: kích hoạt “đã có phiếu xuất”; hành động chặn “không sửa trực tiếp số lượng”; bằng chứng giữ lại “ID đơn và ID phiếu xuất”; đường khôi phục “tạo yêu cầu điều chỉnh”; thẩm quyền “Business Owner và Accounting Owner”. Thiếu một phần thì người giao hàng vẫn có thể xử lý sai dưới áp lực vận hành.

Không gọi nội dung là “tuân thủ pháp luật” chỉ vì có cảnh báo. Luật Kế toán, Luật An toàn thực phẩm, Luật Bảo vệ dữ liệu cá nhân và văn bản liên quan cần Legal Owner, Accounting Owner hoặc domain owner xác minh trước khi biến thành requirement. Nguồn corpus tại IN_REVIEW không tạo baseline, approval hay quyền production.

Quick Reference

Rủi ro thật	Dùng cảnh báo	Khôi phục an toàn
Xóa lịch sử đơn sau xuất kho	Có	Giữ bản gốc; tạo điều chỉnh liên kết giao dịch gốc
Lộ số điện thoại khách hàng mô phỏng qua API	Có	Chặn endpoint, giữ log truy cập, Security xác nhận cách sửa
Sai định dạng tiêu đề bảng	Không	Ghi review comment thường
Thiếu người nhận thông báo trong mô tả màn hình	Không, trừ khi bỏ sót gây phát hành sai hoặc mất dữ liệu	Bổ sung requirement trước build

Core

Năm lỗi khác nhau cần tách riêng vì mỗi lỗi cần cách sửa và thẩm quyền khác nhau. Mơ hồ là câu có nhiều cách hiểu. Thiếu hoàn chỉnh là chưa đủ thông tin để xây, kiểm thử hoặc vận hành. Khẳng định thẩm quyền không có chứng cứ là gán trạng thái phê duyệt, baseline, nghĩa vụ pháp lý hoặc quyết định nghiệp vụ khi artifact không ghi nhận bằng chứng. Dùng sai ký pháp là gọi sai loại sơ đồ hoặc dùng ký hiệu làm người đọc hiểu sai. Đứt truy vết là requirement không liên kết được về nguồn, rule, quyết định, acceptance criteria hoặc test basis.

Loại lỗi	Red flag quan sát được	Vì sao sai	Sửa an toàn
Mơ hồ	“Hệ thống xử lý nhanh”, “duyệt khi cần”	Không đo được thời gian, actor, điều kiện, kết quả	Ghi actor, trigger, điều kiện, dữ liệu vào/ra, kết quả đo được
Thiếu hoàn chỉnh	Có luồng thành công nhưng không có lỗi, hủy, trùng dữ liệu	Dev và QA phải tự đoán nhánh còn lại	Thêm alternate flow, exception flow, validation, trạng thái cuối
Khẳng định thẩm quyền không có chứng cứ	“Đã được Legal phê duyệt”, “tuân thủ Luật” nhưng không có approval reference	Biến giả định học liệu thành cam kết	Gắn Verification required, nêu owner cần xác nhận, không gọi approved hoặc compliant
Dùng sai ký pháp	PlantUML activity diagram bị ghi là BPMN	Người đọc tin nhầm mức chuẩn hóa và semantics	Gọi đúng tên sơ đồ; BPMN chỉ dùng khi ký pháp phù hợp OMG BPMN 2.0.2
Đứt truy vết	FR-NF-001 xuất hiện nhưng không có nguồn hoặc acceptance criteria	Không chứng minh lý do tồn tại, không đánh giá được tác động thay đổi	Liên kết ID canonical tới source, rule, decision, AC và test basis

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

flowchart TB
    A[Kiểm tra requirement draft] --> B{Nghĩa rõ một cách?}

    B -- Không --> C[Ghi nhận: mơ hồ<br/>Người soạn bổ sung actor, trigger, điều kiện,<br/>dữ liệu vào ra và kết quả đo được]
    B -- Có --> D{Đủ happy path, lỗi, hủy,<br/>dữ liệu, validation và trạng thái cuối?}
    C --> D

    D -- Không --> E[Ghi nhận: thiếu hoàn chỉnh<br/>Người soạn bổ sung alternate flow,<br/>exception flow, validation và trạng thái cuối]
    D -- Có --> F{Có khẳng định về phê duyệt, baseline,<br/>nghĩa vụ pháp lý hoặc quyết định nghiệp vụ?}
    E --> F

    F -- Không --> H{Artifact có dùng sơ đồ hoặc ký hiệu?}
    F -- Có --> F2{Có approval reference<br/>hoặc owner đã xác minh?}
    F2 -- Không --> G[Ghi nhận: khẳng định thẩm quyền không có chứng cứ<br/>Đánh dấu Verification required<br/>Chuyển Business Owner, Legal Owner hoặc domain owner xác minh]
    F2 -- Có --> H
    G --> H

    H -- Không --> J{Đủ các liên kết bắt buộc tới source, rule,<br/>decision, acceptance criteria và test basis?}
    H -- Có --> H2{Tên sơ đồ và ký hiệu<br/>được dùng đúng?}
    H2 -- Không --> I[Ghi nhận: dùng sai ký pháp<br/>Người soạn artifact gọi đúng tên sơ đồ<br/>và sửa ký hiệu gây hiểu sai]
    H2 -- Có --> J
    I --> J

    J -- Không --> K[Ghi nhận: đứt truy vết<br/>Người soạn liên kết requirement tới source, rule,<br/>decision, acceptance criteria và test basis]
    J -- Có --> M{Có lỗi nào đã ghi nhận<br/>trong năm loại?}
    K --> M

    M -- Không --> L[Không phát hiện năm loại lỗi<br/>trong lần kiểm tra này]
    M -- Có --> N[Chuyển từng lỗi tới owner tương ứng<br/>để sửa và review lại]
    N -- Sau khi sửa --> A

Cảnh báo: Với Nova Foods mô phỏng, câu “ERP phải lưu truy xuất lô theo Luật An toàn thực phẩm” không tự thành requirement bắt buộc. Nguồn luật cho bối cảnh, nhưng nội dung áp dụng cần Business Owner, Legal Owner và domain owner xác minh. Ranh giới phục hồi: chỉ ghi project assumption hoặc Verification required; không tự đặt cấu hình production, thời hạn lưu, hay kết luận tuân thủ.

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dữ liệu tổng hợp. Functional specification ghi: “Kho chặn xuất hàng nếu lô sắp hết hạn và tự động báo quản lý.”

Current Behavior: Câu không nêu “sắp hết hạn” là bao nhiêu ngày, quản lý nào nhận báo, kênh báo, trạng thái phiếu xuất, hay có ngoại lệ cho hàng đã được phê duyệt.

Underlying Need: Ngăn xuất hàng có rủi ro chất lượng, nhưng chưa có rule canonical, nguồn quyết định, hoặc thẩm quyền xác nhận ngưỡng ngày.

Options:

Phương án	Nội dung	Rủi ro
A	Tự đặt ngưỡng 30 ngày	BA tự tạo rule nghiệp vụ
B	Viết “theo chính sách hiện hành”	Mơ hồ, không kiểm thử được
C	Ghi requirement có biến quyết định và nhãn xác minh	Chưa thể build final, nhưng không bịa rule

Decision Criteria: Chỉ chọn phương án giữ được nguồn sự thật, không tạo approval ngầm định, và cho phép QA biết điều gì chưa kiểm thử được.

Decision: Chọn C. Viết: “Khi ngày hết hạn của Lot nhỏ hơn hoặc bằng ngưỡng ExpiryBlockThresholdDays được Business Owner và Quality Owner xác nhận, hệ thống chuyển Delivery Order sang trạng thái BLOCKED_EXPIRY và tạo thông báo cho vai trò được xác nhận. Verification required: giá trị ngưỡng, vai trò nhận thông báo, quyền override, audit trail.”

Authority: Business Owner và Quality Owner xác nhận quy tắc vận hành. Legal Owner xác minh nếu yêu cầu được diễn đạt là nghĩa vụ pháp lý. Principal IT Business Analyst / Technical Curriculum Author chỉ giữ traceability, không xác nhận nội dung.

Artifact: Functional specification liên kết tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, và TRACEABILITY_ID_REGISTRY; các artifact đều IN_REVIEW, v0.9.0, ngày 2026-08-07. Không có baseline reference hoặc approval reference.

Consequence if Wrong: Ngưỡng tự bịa có thể chặn giao hàng hợp lệ hoặc cho xuất lô không phù hợp. Gọi sơ đồ activity là BPMN làm team hiểu sai notation. Mất liên kết ID làm không thể xác định test nào cần sửa khi rule đổi.

Senior Lens

Không “sửa câu” trước khi phân loại lỗi. Cùng câu có thể vừa mơ hồ vừa thiếu hoàn chỉnh, nhưng không được dùng nhãn “thiếu thông tin” thay cho vấn đề thẩm quyền. Evidence bridge phải lộ rõ: nguồn nào nói gì, ai có quyền quyết, artifact nào lưu quyết định, ID nào liên kết requirement.

Dùng từ “phải” chỉ khi nguồn hoặc quyết định có thẩm quyền được tham chiếu rõ. Với nguồn chuẩn như BABOK Guide, ISO/IEC/IEEE 29148, BPMN 2.0.2, UML 2.5.1, OpenAPI Specification 3.1.1, WCAG 2.2 hoặc OWASP ASVS, nêu phạm vi dùng của nguồn; không bịa số trang, clause hoặc tuyên bố Nova Foods đã tuân thủ.

Quick Reference

Kiểm tra trước khi đưa requirement vào review	Đạt khi
Một nghĩa	Actor, điều kiện, hành động, kết quả không có hai cách đọc hợp lý
Đủ thông tin	Có main flow, alternate/exception flow, dữ liệu, validation, trạng thái
Đúng authority	Approval, baseline, legal hoặc accounting claim có evidence reference; nếu không, dùng Verification required
Đúng notation	Tên sơ đồ khớp notation thực dùng và nguồn chuẩn được phân loại đúng
Liên tục traceability	ID canonical liên kết được về source, rule hoặc decision và đi tới acceptance criteria/test basis

11. Senior BA Notes & Rules of Thumb

Senior Lens

Senior BA không chọn phương án “đẹp nhất” trên giấy. Senior BA chọn phương án có lợi ích, chi phí, rủi ro và thẩm quyền rõ nhất trong bối cảnh quyết định. Với Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp — Functional Specification chỉ đang IN_REVIEW, v0.9.0, ngày 2026-08-07; không có baseline reference hoặc approval reference. Vì vậy, câu kết luận phải phân biệt giữa fact, project assumption, Verification required và quyết định có thẩm quyền.

Góc nhìn	Trade-off cần phân tích	Evidence bridge cần ghi	Ai quyết
Nghiệp vụ	Giảm thời gian xuất kho có thể giảm số bước kiểm tra lô hàng	Số bước hiện tại, lỗi vận hành ghi nhận, nhu cầu kiểm soát chất lượng	Business Owner và Process Owner
Kỹ thuật	Rule ở ERP giảm lệch xử lý; rule ở giao diện có thể phản hồi nhanh hơn	System boundary, dữ liệu đầu vào, điểm tích hợp, lỗi nếu client bị bỏ qua	Architect và Technical Owner
Dữ liệu	Bắt buộc mã lô tăng truy vết; có thể chặn giao dịch thiếu dữ liệu đầu kỳ	Trường dữ liệu, nguồn tạo mã, tỷ lệ bản ghi thiếu, cách xử lý exception	Data Owner và Business Owner
Bảo mật	Phân quyền chi tiết giảm lộ dữ liệu; tăng công sức quản trị quyền	Vai trò, dữ liệu truy cập, rủi ro, nguồn OWASP phù hợp	Security Owner
Pháp lý, kế toán, an toàn thực phẩm	Rule có thể ảnh hưởng lưu chứng từ, dữ liệu cá nhân hoặc truy xuất lô	URL nguồn chính thức, phạm vi áp dụng, điểm chưa xác minh	Legal Owner, Accounting Owner hoặc Domain Owner

Exception không phải lỗi cần xóa. Exception là tình huống hợp lệ nhưng khác main flow. Ví dụ, người dùng đề nghị cho phép xuất kho khi thiếu mã lô để tránh dừng giao hàng. Lợi ích là tránh gián đoạn giao hàng. Rủi ro là mất liên kết truy vết giữa hàng xuất và lô. Senior BA không tự viết “hệ thống cho phép” hoặc “hệ thống cấm” khi chưa rõ authority. Ghi nhận hai option: chặn giao dịch; hoặc cho phép override có lý do, người có quyền và audit trail. Nếu yêu cầu liên quan Luật An toàn thực phẩm, Luật Kế toán, Luật Bảo vệ dữ liệu cá nhân hoặc Nghị định liên quan, nhãn đúng là Verification required; BA không diễn giải thành nghĩa vụ triển khai khi chưa có xác nhận từ owner chuyên môn.

Stakeholder conflict thường xuất hiện khi mỗi bên tối ưu một mục tiêu. Kho vận muốn ít bước, QA muốn giữ kiểm soát lô, Finance muốn chứng từ nhất quán, IT muốn giới hạn thay đổi, Security muốn hạn chế quyền override. Không giải quyết conflict bằng biểu quyết không có quyền hạn. Tách từng claim, nối claim với evidence, rồi chuyển đúng decision owner. BA sở hữu chất lượng phân tích và traceability; BA không sở hữu quyết định nghiệp vụ, kiến trúc, pháp lý, kế toán hoặc bảo mật.

Chất lượng evidence	Ví dụ	Cách dùng trong Functional Specification
Mạnh	Quyết định được ghi nhận bởi owner có thẩm quyền, source canonical có ID và ngày	Có thể ghi decision, authority, artifact reference
Trung bình	Demo hệ thống, log lỗi, số liệu tổng hợp, workshop notes chưa được xác nhận	Dùng để mô tả fact hoặc hypothesis; không suy ra rule bắt buộc
Yếu	Ý kiến một cá nhân, ảnh chụp màn hình không rõ môi trường, truyền miệng	Ghi nguồn gốc và Verification required; không làm acceptance criterion
Không dùng được	“Hệ thống cũ luôn làm vậy” nhưng không có artifact, owner hoặc dữ liệu kiểm chứng	Không chuyển thành requirement

Ngưỡng escalation là khi option ảnh hưởng quyền truy cập, dữ liệu cá nhân, hạch toán, thuế, truy xuất an toàn thực phẩm, tích hợp liên hệ thống, hoặc làm thay đổi trách nhiệm kiểm soát. Escalate cũng khi hai source canonical mâu thuẫn, khi source không xác định owner, hoặc khi stakeholder yêu cầu BA xác nhận compliance. Lý do: chọn sai ở các điểm này không còn là lỗi câu chữ; nó có thể tạo rủi ro vận hành, bảo mật hoặc pháp lý.

Khuyến nghị phòng thủ được ghi theo mẫu: “Dựa trên [evidence reference], phương án [X] đáp ứng [decision criterion] tốt hơn [Y]. Rủi ro còn lại là [risk]. [Authority role] cần xác nhận [open decision]. Cho đến khi có xác nhận, trạng thái là IN_REVIEW và điểm này là Verification required.” Mẫu này nêu rõ suy luận nhưng không bịa chắc chắn, không gán approval, và giữ đường truy vết tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY hoặc TRACEABILITY_ID_REGISTRY khi các artifact đó là nguồn canonical phù hợp.

Senior Lens

Senior BA review đặc tả theo câu hỏi: “Người xây, kiểm thử và vận hành có thể ra cùng một kết quả từ cùng dữ kiện không?” Nếu không, requirement chưa đủ rõ. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu đều tổng hợp; IN_REVIEW tại v0.9.0 ngày 2026-08-07 không phải baseline, approval hay quyền triển khai.

Heuristic review	Kiểm tra cụ thể	Red flag	Ngưỡng escalation	Ngoại lệ không áp dụng quy tắc thường
Một nguồn chân lý	Mỗi rule, field, trạng thái trỏ về một artifact canonical như CANONICAL_BUSINESS_RULES hoặc CANONICAL_DATA_DICTIONARY	Cùng khái niệm có hai định nghĩa khác nhau trong hai tài liệu	Escalate khi khác biệt làm đổi kết quả tính, quyền, trạng thái hoặc test case	Prototype học tập có thể ghi giả định cục bộ, nhưng phải ghi rõ không phải nguồn canonical
Rule kiểm thử được	Rule nêu trigger, điều kiện, xử lý, kết quả và lỗi	“Hệ thống kiểm tra hợp lệ” không nêu tiêu chí hợp lệ	Escalate khi QA không thể tạo expected result xác định	Requirement khám phá có thể giữ nhiều phương án, nhưng không được chuyển sang build
Dữ liệu có nghĩa	Field có định nghĩa, kiểu, nguồn, owner, mandatory/optional và quy tắc kiểm tra	Dùng “mã khách hàng” nhưng không biết lấy từ đâu, có duy nhất không	Escalate khi field ảnh hưởng tài chính, truy xuất nguồn gốc, dữ liệu cá nhân hoặc tích hợp	Field hiển thị thuần UI có thể chưa cần mapping vật lý, nếu chưa có quyết định thiết kế
Ngoại lệ có chủ đích	Luồng lỗi và quyền override nêu ai được làm, khi nào, lưu gì	“Quản lý có thể sửa” nhưng không có scope, audit hoặc giới hạn	Escalate khi override đổi giá trị VND, tồn kho, chứng từ, traceability hoặc quyền truy cập	Không thêm override nếu nghiệp vụ chưa chứng minh cần; từ chối hợp lệ tốt hơn quyền sửa mơ hồ
Ngôn ngữ không suy diễn	“Phải” gắn owner quyết định, phạm vi và evidence	Đặc tả biến project assumption thành nghĩa vụ pháp lý hoặc kế toán	Escalate ngay khi nội dung chạm pháp lý, thuế, kế toán, bảo mật, an toàn thực phẩm hay dữ liệu cá nhân	Không áp dụng rule “BA tự làm rõ” cho kết luận thuộc Legal Owner, Accounting Owner, Security hoặc Architect

Red flag mạnh: requirement dùng từ tuyệt đối như “luôn”, “ngay”, “đúng”, “tự động” nhưng không có điều kiện biên; acceptance criteria mâu thuẫn business rule; API field không khớp CANONICAL_DATA_DICTIONARY; role được cấp quyền rộng hơn nhiệm vụ; hoặc tài liệu gọi nội dung APPROVED dù artifact chỉ là IN_REVIEW. Evidence yếu gồm ý kiến miệng không có người xác nhận, ảnh chụp màn hình không có bối cảnh, email không nêu quyết định, và suy luận từ hệ thống cũ. Evidence mạnh hơn khi có rule được định danh, mẫu dữ liệu tổng hợp, kết quả walkthrough liên chức năng, hoặc quyết định ghi rõ authority.

Escalate trước khi chốt đặc tả khi có một trong các điều kiện: hai stakeholder yêu cầu kết quả đối nghịch; chênh lệch làm thay đổi số tiền VND; requirement ảnh hưởng dữ liệu cá nhân; interface cần đổi contract; một exception không có owner; hoặc source pháp lý cần diễn giải. BA ghi vấn đề, các phương án, impact và evidence; đúng authority quyết định. BA không tự chọn thay Legal Owner, Accounting Owner, Business Owner, Security, Architect hoặc QA.

Quy tắc thường là “đóng requirement khi đủ điều kiện kiểm thử”. Không áp dụng khi discovery còn thiếu dữ kiện quyết định, khi quyết định kiến trúc chưa có, hoặc khi luật hiện hành cần Legal Owner xác minh. Khi đó, giữ requirement ở trạng thái chưa chốt trong artifact kiểm soát, nêu phạm vi bị chặn và không biến giả định thành hành vi ERP.

Senior Lens

Senior BA không biến khoảng trống bằng chứng thành kết luận. “Chưa biết” là trạng thái thông tin, không phải lỗi. Với Nova Foods mô phỏng, dữ liệu tổng hợp, ghi rõ điều đã quan sát, nguồn của điều đó, suy luận nối từ bằng chứng đến đề xuất, phần chưa xác minh và người có quyền quyết định. IN_REVIEW tại v0.9.0 ngày 2026-08-07 không phải baseline, approval hay xác nhận vận hành.

Trường ghi nhận trong functional specification	Nội dung mẫu có thể bảo vệ
Facts (sự kiện)	Ba đơn mua hàng tổng hợp có giá trị lần lượt 45.000.000 VND, 78.000.000 VND, 120.000.000 VND; tài liệu đầu vào chưa nêu ngưỡng phê duyệt.
Evidence (bằng chứng)	Dữ liệu ví dụ trong functional specification; không có rule đã xác minh trong CANONICAL_BUSINESS_RULES.
Uncertainty (điều chưa chắc)	Chưa xác minh ngưỡng có áp dụng cho mọi loại hàng, mọi đơn vị hay chỉ nhóm mua hàng cụ thể.
Recommendation (khuyến nghị)	Thiết kế trạng thái Pending Approval và cấu hình ngưỡng ngoài mã nguồn; chưa gán giá trị ngưỡng.
Reasoning bridge (cầu suy luận)	Vì giá trị đơn có thể khác nhau và chưa có rule canonical, cố định một ngưỡng trong logic sẽ biến giả định thành quy tắc nghiệp vụ.
Decision authority (thẩm quyền quyết định)	Business Owner quyết định chính sách phê duyệt; Accounting Owner xác minh ảnh hưởng kiểm soát tài chính nếu có; Architect quyết định cơ chế cấu hình.
Verification required	Xác minh chính sách phê duyệt hiện hành trước khi đặt acceptance criteria có ngưỡng số.
Consequence if wrong	Đơn có thể bị duyệt sai cấp, chặn mua hàng hợp lệ, hoặc tạo kiểm soát tài chính không được chủ sở hữu xác nhận.

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

flowchart TB
    A[Evidence: dữ liệu tổng hợp và artifact kiểm soát] --> B{Evidence đủ để đánh giá rule?}
    B -->|Không| C[Ghi uncertainty và Verification required]
    B -->|Có| D[Đánh giá rule, nguồn, phạm vi và khoảng trống quyết định]
    C --> E[Đề xuất lựa chọn không khóa giả định]
    D --> E
    E --> F[Business Owner quyết định chính sách]
    E --> G{Có ảnh hưởng kiểm soát tài chính?}
    G -->|Có| H[Accounting Owner xác minh ảnh hưởng kiểm soát tài chính]
    G -->|Không| I[Không cần xác minh Accounting Owner]
    E --> J[Architect quyết định cơ chế cấu hình]
    F --> K{Các xác minh và quyết định bắt buộc đã hoàn tất?}
    H --> K
    I --> K
    J --> K
    K -->|Chưa| L[Giữ IN_REVIEW: không phải approval hoặc baseline]
    L --> M[Tiếp tục xác minh và quyết định]
    M --> B
    K -->|Có| N{Artifact ghi authority, căn cứ và trạng thái phù hợp?}
    N -->|Không| O[Cập nhật artifact kiểm soát]
    O --> K
    N -->|Có| P{Artifact có trạng thái baseline phù hợp?}
    P -->|Có| Q[Ghi rule, nguồn, phạm vi, authority và baseline]
    P -->|Không| R[Ghi quyết định, nguồn, phạm vi và authority; chưa là baseline]
    E --> S[Rủi ro giả định sai: duyệt sai cấp, chặn mua hợp lệ, hoặc tạo kiểm soát tài chính chưa được xác nhận]

Câu viết an toàn: “Khuyến nghị dùng ngưỡng cấu hình được vì functional specification chưa có bằng chứng xác minh cho một giá trị VND cố định; Business Owner cần quyết định ngưỡng và phạm vi áp dụng.” Không viết: “Nova Foods yêu cầu phê duyệt từ 50.000.000 VND” khi con số chỉ là ví dụ hoặc suy đoán.

Senior BA tách “recommendation” khỏi “decision”. Khuyến nghị là phương án có lý do và rủi ro; quyết định chỉ tồn tại khi artifact kiểm soát ghi nhận người có thẩm quyền, căn cứ và trạng thái phù hợp. Nếu Legal, Accounting, Security hoặc Architect phải kết luận, BA giữ traceability đến /01-curriculum/CANONICAL_BUSINESS_RULES.md hoặc artifact nguồn liên quan, ghi Verification required, không tự nâng giả định thành compliance hay production rule.

12. Associated Template Reference & Completed Artifact

Core

Functional specification cần tham chiếu template để người viết dùng đúng cấu trúc, đúng nguồn chân lý, đúng người kiểm tra. Template không tạo quyết định nghiệp vụ. Template chỉ giữ thông tin nhất quán, gồm requirement, business rule, dữ liệu, acceptance criteria và traceability.

Bằng chứng hiện có chỉ xác nhận artifact manifest TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md. Seed không cung cấp dòng template riêng cho Functional Specification, nên không được tự tạo GEN-TMPL-{NNN}, Template ID, hoặc filename mới. Việc đoán ID làm đứt canonical traceability.

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

flowchart TB
    A[Functional Specification draft] --> B[Kiểm tra TEMPLATE_MANIFEST]
    B --> C{Có Template ID và filename đã đăng ký?}
    C -->|Có| D[Dùng đúng Template ID, filename, owner và quality gate]
    C -->|Không| E[Không tạo ID suy đoán]
    E --> F[Tham chiếu TEMPLATE_MANIFEST]
    F --> G[Giữ IN_REVIEW và yêu cầu đăng ký canonical entry]

Applied

Trường	Nội dung
Facts	Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Corpus có TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY, đều IN_REVIEW, v0.9.0, ngày 2026-08-07.
Current Behavior	Functional Specification phải liên kết artifact canonical nhưng không có bằng chứng trong seed về Template ID riêng hoặc filename template đã đăng ký cho chapter này.
Underlying Need	Người viết cần biết tệp nào kiểm soát cấu trúc template và artifact nào kiểm soát ID, rule, dữ liệu.
Options	Dùng ID suy đoán; tạo filename mới; hoặc chỉ tham chiếu artifact đã xác minh.
Decision Criteria	ID phải tồn tại trong nguồn canonical; filename phải đúng đường dẫn kiểm soát; owner phải thuộc thẩm quyền phù hợp; quality gate không được diễn giải thành approval.
Decision	Chỉ map artifact có ID và filename được seed xác minh. Không map template cá thể chưa được đăng ký.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì manifest và traceability. Business Owner, Architect, QA, Legal Owner, Accounting Owner hoặc Security quyết định phần nội dung thuộc chuyên môn của họ.
Artifact	/01-curriculum/TEMPLATE_MANIFEST.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
Consequence if Wrong	Người viết có thể dùng mẫu không kiểm soát, gán sai ID, biến giả định thành rule, hoặc gọi nội dung IN_REVIEW là đã phê duyệt.

Senior Lens

Senior BA kiểm tra hai lớp. Lớp một: template có được đăng ký không. Lớp hai: nội dung điền vào template có nguồn và thẩm quyền không. Lý do: template hợp lệ vẫn có thể chứa rule, dữ liệu hoặc quyết định không hợp lệ.

IN_REVIEW nghĩa là đang xem xét có kiểm soát. Nó không nghĩa APPROVED, BASELINED, compliant, production-ready, hoặc được người dùng chấp thuận. Vì vậy quality gate ở giai đoạn này kiểm tra tính đầy đủ, đúng ID, đúng liên kết và nhãn Verification required; không xác nhận vận hành ERP Nova Foods.

Quick Reference

Template hoặc artifact ID	Filename kiểm soát	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 cho template manifest	Cần xác minh template đã đăng ký, filename, dependency và giới hạn dùng	Cần tự tạo Template ID hoặc xác nhận nội dung nghiệp vụ	Principal IT Business Analyst / Technical Curriculum Author	BA author, curriculum author, reviewer	ID và filename phải có trong manifest; IN_REVIEW không là approval
TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Canonical identifier registry plan	Cần kiểm tra định danh requirement, rule, data, interface hoặc security reference	Cần quyết định business rule, kiến trúc, pháp lý hoặc kế toán	Principal IT Business Analyst / Technical Curriculum Author	BA, QA, Architect, reviewer	Giữ nguyên canonical ID; escalation khi ID gây diễn giải sai thẩm quyền
CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Canonical rule catalog plan	Cần tham chiếu business rule trong Functional Specification	Cần tự xác nhận rule là vận hành thật hoặc đã phê duyệt	Principal IT Business Analyst / Technical Curriculum Author	BA, Business Owner, QA, Accounting Owner	Rule phải giữ nguồn, authority và Verification required khi chưa xác minh
CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Canonical logical data dictionary plan	Cần tham chiếu field, entity, định nghĩa dữ liệu logic	Cần suy ra schema vật lý, API contract hoặc quyền production	Principal IT Business Analyst / Technical Curriculum Author	BA, Architect, QA, data reviewer	Không đổi tên field hoặc ý nghĩa dữ liệu ngoài nguồn canonical
Chưa có Template ID cá thể được seed xác minh	Chưa có filename template cá thể được seed xác minh	Không đủ bằng chứng để phân loại	Chỉ dùng sau khi được đăng ký trong TEMPLATE_MANIFEST	Không tạo ID, file hoặc completed template suy đoán	Principal IT Business Analyst / Technical Curriculum Author quản trị đăng ký	BA author và reviewer sau khi đăng ký	Dừng mapping cá thể; giữ IN_REVIEW; không gọi là completed hoặc approved

Core

Tra cứu chapter là kiểm tra có chủ đích giữa nội dung đang viết và artifact canonical, để người học không dùng một ví dụ Nova Foods mô phỏng như nguồn quy tắc độc lập. Bằng chứng: CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY đều có trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Suy ra: chỉ được liên kết đúng ID và đường dẫn đã đăng ký; không gọi nội dung là baseline, approved hoặc quy định vận hành.

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

flowchart TB
    A[Người học: Tra cứu chapter]
    S[Trạng thái chung: IN_REVIEW<br/>Phiên bản: v0.9.0<br/>Ngày: 2026-08-07]

    A --> B[CHAPTER_MANIFEST]
    A --> C[TEMPLATE_MANIFEST]
    A --> D[TRACEABILITY_ID_REGISTRY]
    A --> E[CANONICAL_BUSINESS_RULES]
    A --> F[CANONICAL_DATA_DICTIONARY]

    S --- B
    S --- C
    S --- D
    S --- E
    S --- F

    B --> G[Kiểm tra chapter ID và đường dẫn]
    C --> H[Kiểm tra template]
    D --> I[Kiểm tra ID đã đăng ký]
    E --> J[Kiểm tra tham chiếu business rule]
    F --> K[Kiểm tra tham chiếu data dictionary]

    G --> L[Chỉ liên kết ID và đường dẫn đã đăng ký]
    H --> L
    I --> L
    J --> L
    K --> L

    L --> M[Không gọi nội dung là baseline,<br/>approved hoặc quy định vận hành]

Applied

Mục	Nội dung
Facts	Chapter hiện hành là /02-handbook/09-functional-specification-writing.md; corpus Nova Foods là mô phỏng giáo dục, chỉ dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND.
Current Behavior	Chapter viết functional specification phải dẫn người đọc đến template và artifact đã điền, nhưng không được tự tạo tên tệp, template ID hoặc rule ID.
Underlying Need	Người học cần biết nơi tra cứu đầy đủ để kiểm tra tính nhất quán trước khi dùng functional specification làm đầu vào cho thiết kế, build hoặc test.
Options	Tra cứu từng tệp rời rạc; hoặc dùng checklist chapter có đường dẫn canonical.
Decision Criteria	Không mất traceability; không sao chép registry; không bịa location; giữ boundary IN_REVIEW.
Decision	Dùng checklist dưới đây. Filled Nova Foods artifact chỉ được nêu khi TEMPLATE_MANIFEST đăng ký ID và đường dẫn.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết corpus; không có quyền xác nhận business, legal, accounting, security hoặc production.
Artifact	/02-handbook/09-functional-specification-writing.md, section 12; nguồn lookup canonical nằm trong /01-curriculum/.
Consequence if Wrong	Người đọc có thể dùng sai template, tạo ID trùng, hoặc diễn giải dữ liệu mô phỏng thành yêu cầu ERP thật.

Senior Lens

Kiểm tra bắt buộc	Nơi tra cứu canonical	Điều kiện đạt
Chapter identity	/01-curriculum/CHAPTER_MANIFEST.md	Xác nhận chapter tương ứng với /02-handbook/09-functional-specification-writing.md; không đổi filename hoặc section blueprint.
Template identity	/01-curriculum/TEMPLATE_MANIFEST.md	Chỉ dùng template ID, filename, dependency và planned usage đã đăng ký.
Traceability ID	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Requirement, rule, data, interface, test hoặc risk ID giữ nguyên chuỗi canonical; không tự sinh biến thể.
Business rule reference	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Rule được tham chiếu đúng nguồn; rule chưa xác minh vẫn giữ nhãn Verification required hoặc project assumption.
Logical data reference	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tên dữ liệu, nghĩa dữ liệu và boundary logic không bị suy diễn thành schema ERP thực.
Source boundary	/00-research/00_SOURCE_MAP.md	Nguồn pháp lý, chuẩn và good practice chỉ dùng trong safe use boundary đã ghi.
Governance metadata	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Giữ IN_REVIEW, v0.9.0, 2026-08-07, Asia/Ho_Chi_Minh, Nova Foods mô phỏng và dữ liệu tổng hợp.
Filled Nova Foods artifact location	/01-curriculum/TEMPLATE_MANIFEST.md	Nguồn seed chưa cung cấp template ID hoặc đường dẫn artifact đã điền cho chapter này. Không được bịa location. Tra cứu manifest trước khi chèn liên kết.

Quick Reference

Checklist tra cứu hoàn chỉnh trước khi dùng artifact đã điền:

• [ ] Mở /01-curriculum/CHAPTER_MANIFEST.md; xác nhận chapter file là /02-handbook/09-functional-specification-writing.md.
• [ ] Mở /01-curriculum/TEMPLATE_MANIFEST.md; tìm template được liên kết với functional specification writing.
• [ ] Ghi nguyên văn template ID và filename nếu manifest đã đăng ký.
• [ ] Ghi location artifact Nova Foods đã điền chỉ từ entry manifest tương ứng.
• [ ] Nếu manifest chưa có entry filled artifact, ghi trạng thái “chưa xác định từ nguồn canonical được cung cấp”; không thay bằng đường dẫn tự đặt.
• [ ] Mở /01-curriculum/TRACEABILITY_ID_REGISTRY.md; kiểm tra mọi ID tham chiếu giữ đúng format canonical.
• [ ] Mở /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/CANONICAL_DATA_DICTIONARY.md; kiểm tra rule và data reference không biến thành quyết định vận hành.
• [ ] Giữ nhãn Nova Foods mô phỏng, dữ liệu tổng hợp, IN_REVIEW, v0.9.0, ngày 2026-08-07.
• [ ] Không sao chép toàn bộ registry vào chapter; chapter chỉ chứa lookup path, ID cần dùng và lý do liên kết.

Senior Lens

Trước handoff, BA kiểm tra chéo giữa các artifact để phát hiện mâu thuẫn trước khi lỗi thành requirement, test case hoặc cấu hình ERP. Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; vì vậy kiểm tra xác nhận tính nhất quán học liệu, không xác nhận vận hành thật, tuân thủ pháp lý hay approval.

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

flowchart TB
    A["BA kiểm tra Functional specification draft"] --> B["Đối chiếu CHAPTER_MANIFEST"]
    B --> C["Đối chiếu TRACEABILITY_ID_REGISTRY"]
    C --> D["Đối chiếu CANONICAL_BUSINESS_RULES"]
    D --> E["Đối chiếu CANONICAL_DATA_DICTIONARY"]
    E --> F["Đối chiếu 00_SOURCE_MAP"]
    F --> G["Kiểm tra testability của acceptance criteria, business rule và data condition"]
    G --> H["Kiểm tra metadata:<br/>v0.9.0, 2026-08-07, vi-VN,<br/>Asia/Ho_Chi_Minh, VND"]

    H --> I{"Đủ điều kiện handoff?<br/>Lỗi chặn đã log<br/>Mục chưa xác minh có Verification required<br/>Owner đã nêu theo vai trò<br/>Metadata nhất quán"}

    I -->|Có| W["Handoff Functional specification<br/>ở trạng thái IN_REVIEW"]
    W --> X["Ranh giới: không tạo approval, baseline,<br/>legal sign-off, accounting sign-off<br/>hoặc quyền production"]

    I -->|Không| K["Log open issue hoặc lỗi chặn<br/>kèm evidence và reasoning"]
    K --> L{"Loại vấn đề?"}

    L -->|Phạm vi chapter| M["Dừng handoff phần bị ảnh hưởng<br/>Xóa hoặc chuyển nội dung vượt phạm vi<br/>Escalate Principal IT Business Analyst / Technical Curriculum Author"]
    M --> MC{"Nội dung đã đúng phạm vi chapter?"}
    MC -->|Có| U["Đóng issue với evidence và traceability"]
    MC -->|Không| V["Giữ issue open và IN_REVIEW<br/>Nêu escalation owner theo vai trò"]

    L -->|ID canonical| N["Dừng handoff phần bị ảnh hưởng<br/>Dùng đúng chuỗi canonical, không tạo ID mới<br/>Escalate Principal IT Business Analyst / Technical Curriculum Author"]
    N --> NC{"Mọi ID đã khớp TRACEABILITY_ID_REGISTRY?"}
    NC -->|Có| U
    NC -->|Không| V

    L -->|Quy tắc nghiệp vụ| O["Giữ Verification required<br/>Escalate Business Owner"]
    O --> OC{"Quyết định đã được ghi trong<br/>artifact canonical và có traceability?"}
    OC -->|Có| U
    OC -->|Không| VR["Giữ issue open, IN_REVIEW<br/>và Verification required<br/>Nêu escalation owner theo vai trò"]

    L -->|Dữ liệu logic| P["Giữ Verification required<br/>Escalate Data Owner và Solution Architect"]
    P --> PC{"Field, định nghĩa, kiểu dữ liệu và owner<br/>đã khớp CANONICAL_DATA_DICTIONARY?"}
    PC -->|Có| U
    PC -->|Không| VR

    L -->|Nguồn hoặc claim pháp lý| Q["Không gọi claim là nghĩa vụ<br/>Giữ Verification required<br/>Escalate Legal Owner hoặc Compliance Owner"]
    Q --> QC{"Nguồn có classification đúng và claim<br/>không vượt safe use boundary?"}
    QC -->|Có| U
    QC -->|Không| VR

    L -->|Testability| R["Giữ IN_REVIEW và Verification required<br/>Escalate QA Lead"]
    R --> RC{"Acceptance criteria, business rule và data condition<br/>đã liên kết đủ để QA tạo test basis không suy diễn?"}
    RC -->|Có| U
    RC -->|Không| VR

    L -->|Metadata| S["Sửa metadata về giá trị bắt buộc<br/>Giữ issue open và IN_REVIEW"]
    S --> SC{"Metadata đã khớp toàn bộ giá trị bắt buộc?"}
    SC -->|Có| U
    SC -->|Không| V

    L -->|Lưu giữ lịch sử giá VND| AA["Giữ Verification required<br/>Escalate Business Owner và Accounting Owner"]
    AA --> AAC{"Quyết định thời hạn lưu giữ đã được ghi<br/>trong artifact canonical và có traceability?"}
    AAC -->|Có| U
    AAC -->|Không| VR

    L -->|Phân loại dữ liệu cá nhân| AB["Giữ Verification required<br/>Escalate Legal Owner và Privacy/Compliance Owner"]
    AB --> ABC{"Phân loại dữ liệu và cách xử lý<br/>đã được owner có thẩm quyền xác nhận?"}
    ABC -->|Có| U
    ABC -->|Không| VR

    L -->|API chưa có contract| AC["Giữ IN_REVIEW và Verification required<br/>Escalate Solution Architect và Security Owner"]
    AC --> ACC{"Contract đã ghi rõ method, schema, lỗi, phân quyền<br/>và security verification scope?"}
    ACC -->|Có| U
    ACC -->|Không| VR

    L -->|Trạng thái tồn kho chưa canonical| AD["Giữ Verification required<br/>Escalate Business Owner, Data Owner và QA Lead"]
    AD --> ADC{"Trạng thái Available, Reserved, Blocked<br/>và rule đã được canonical hóa?"}
    ADC -->|Có| U
    ADC -->|Không| VR

    U --> A
    V --> A
    VR --> A

Kiểm tra chéo	Evidence cần đối chiếu	Điều kiện đạt	Nếu không đạt
Định danh	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Mọi ID giữ đúng chuỗi canonical; không tự tạo ID mới	Dừng handoff phần bị ảnh hưởng; escalation Principal IT Business Analyst / Technical Curriculum Author
Quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Functional behavior không biến giả định thành business rule canonical	Gắn Verification required; escalation Business Owner nếu cần quyết định nghiệp vụ
Dữ liệu logic	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Field, định nghĩa, kiểu dữ liệu, owner không mâu thuẫn dictionary	Gắn Verification required; escalation Data Owner và Solution Architect
Phạm vi chapter	/01-curriculum/CHAPTER_MANIFEST.md	Nội dung đúng mục tiêu chapter; không lấn sang quyết định production	Xóa hoặc chuyển nội dung vượt phạm vi; escalation Principal IT Business Analyst / Technical Curriculum Author
Nguồn và pháp lý	/00-research/00_SOURCE_MAP.md	Nguồn có classification đúng; claim pháp lý không vượt safe use boundary	Không gọi là nghĩa vụ; escalation Legal Owner hoặc Compliance Owner
Testability	Acceptance criteria, business rule, data condition liên kết được	QA có thể tạo test basis mà không suy diễn	Escalation QA Lead; giữ trạng thái IN_REVIEW

Open issue hoặc Verification required	Evidence và reasoning bridge	Escalation owner	Điều kiện đóng
Quy tắc giữ lịch sử giá bán VND chưa có nguồn quyết định	Functional spec có thể mô tả luồng, nhưng thời hạn lưu giữ là quyết định nghiệp vụ và có thể liên quan kế toán	Business Owner; Accounting Owner	Quyết định được ghi trong artifact canonical, có traceability
Trường dữ liệu khách hàng có thuộc dữ liệu cá nhân chưa xác minh	Tên trường và mục đích xử lý quyết định nghĩa vụ bảo vệ; source seed yêu cầu legal-owner verification	Legal Owner; Privacy/Compliance Owner	Phân loại dữ liệu và cách xử lý được xác nhận bởi owner có thẩm quyền
API đồng bộ đơn bán hàng chưa có contract	Luồng nghiệp vụ không đủ xác định HTTP method, schema, lỗi và phân quyền	Solution Architect; Security Owner	Contract kỹ thuật được ghi nhận; security verification scope rõ
Acceptance criterion về tồn kho chưa có trạng thái kho canonical	Tiêu chí “đủ hàng” không test được nếu trạng thái Available, Reserved, Blocked chưa được định nghĩa	Business Owner; Data Owner; QA Lead	Trạng thái và rule liên kết được canonical hóa hoặc giữ Verification required

Handoff chỉ diễn ra khi mọi lỗi chặn được log, mọi mục chưa xác minh giữ nhãn Verification required, và escalation owner đã được nêu tên theo vai trò. IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND phải giữ nhất quán. Không có mục nào trong kiểm tra này tạo baseline, approval, legal sign-off, accounting sign-off hoặc quyền production.