/03-templates/TMPL-REQ-001_REQUIREMENT_ELICITATION_LOG.md — Mẫu Ghi nhận Khai thác Yêu cầu (Requirement Elicitation Log)

Metadata Quản trị Artifact

Bảng này định nghĩa các thuộc tính nhận dạng và kiểm soát của mẫu tài liệu này trong kho tài liệu (corpus) của Nova Foods. Việc duy trì các giá trị này đảm bảo tính nhất quán và khả năng truy vết nguồn gốc (traceability) trên toàn bộ dự án.

Trường kiểm soát	Giá trị
Artifact ID	TMPL-REQ-001
Tên tệp được kiểm soát	/03-templates/TMPL-REQ-001_REQUIREMENT_ELICITATION_LOG.md
Tiêu đề	Mẫu Ghi nhận Khai thác Yêu cầu (Requirement Elicitation Log)
Trạng thái (Status)	IN_REVIEW
Phiên bản (Version)	v0.9.0
Chủ sở hữu (Owner)	Principal IT Business Analyst / Technical Curriculum Author
Trách nhiệm của Owner	Chịu trách nhiệm duy trì cấu trúc, tính toàn vẹn và lịch sử phiên bản của mẫu tài liệu này. Owner đảm bảo mẫu tuân thủ kiến trúc curriculum và các quy ước quản trị của corpus.
Giới hạn thẩm quyền của Owner	Owner của mẫu không có thẩm quyền phê duyệt các yêu cầu nghiệp vụ được ghi nhận bên trong một bản log cụ thể. Thẩm quyền này thuộc về các vai trò như Business Owner hoặc Product Owner của dự án Nova Foods.
Ngày cập nhật gần nhất	2026-08-07
Múi giờ quản trị	Asia/Ho_Chi_Minh
Locale áp dụng	vi-VN; bối cảnh Việt Nam; đơn vị tiền tệ mô phỏng VND.
Tham chiếu Case Study	Nova Foods Trading & Manufacturing — case study mô phỏng cho mục đích giáo dục.
Phân loại Artifact	Controlled Template (Mẫu tài liệu được kiểm soát).
Tham chiếu Baseline	Chưa có baseline reference tại v0.9.0. Trạng thái IN_REVIEW không được diễn giải là BASELINED.
Tham chiếu Phê duyệt (Approval)	Chưa có approval reference tại v0.9.0. Sự tồn tại của metadata không tạo ra phê duyệt ngầm định.

Lịch sử Thay đổi (Change History)

• v0.9.0 (2026-08-07): Khởi tạo artifact. Thiết lập metadata quản trị, mục đích, phạm vi và cấu trúc bốn tầng (Tier 1-4) cho mẫu ghi nhận khai thác yêu cầu. Phiên bản này đang ở trạng thái IN_REVIEW để xem xét nội bộ.

Ranh giới Dữ liệu Mô phỏng (Simulated Data Boundary)

Toàn bộ nội dung trong tài liệu này, đặc biệt là các ví dụ điền sẵn trong Tier 3 — Fully Completed Nova Foods Case, đều là dữ liệu tổng hợp (synthetic data) và được tạo ra cho mục đích giáo dục trong bối cảnh case study Nova Foods. Chúng không đại diện cho bất kỳ tổ chức, cá nhân, quy trình nghiệp vụ, dữ liệu tài chính hay quyết định vận hành nào trong thực tế. Không được sử dụng các ví dụ này làm cơ sở cho việc triển khai sản phẩm hoặc suy diễn về hoạt động của một doanh nghiệp có thật.

1. Tier 1 – Metadata, Purpose, and Governance

Metadata Quản trị Artifact

Thuộc tính	Giá trị	Quy tắc kiểm soát
Status	IN_REVIEW	Artifact đang được xem xét. Không phải baseline và chưa được xem là đã phê duyệt.
Version	Được điều phối bởi TEMPLATE_MANIFEST	Phiên bản chính tắc được quản lý trong /01-curriculum/TEMPLATE_MANIFEST.md. Không suy diễn phiên bản từ tên tệp hoặc bản sao.
Owner	Business Analyst (BA)	BA sở hữu việc điền, cập nhật và bảo toàn tính toàn vẹn của log; thẩm quyền về nội dung nghiệp vụ vẫn thuộc Business Owner hoặc SME.
Updated	Được ghi nhận trong ### Lịch sử Thay đổi (Change History)	Mỗi cập nhật phải có bản ghi lịch sử thay đổi để người dùng xác định thời điểm, tác nhân và nội dung thay đổi.

Mục đích, Phạm vi sử dụng và Quản trị

Template này dùng để ghi lại nhật ký quá trình khơi gợi yêu cầu (Requirement Elicitation). "Elicitation" là một thuật ngữ chuyên ngành, không chỉ đơn thuần là "thu thập" (collecting) mà là một quá trình chủ động khơi gợi, tìm hiểu sâu, làm rõ và xác nhận thông tin từ các bên liên quan (stakeholders). Mục đích chính là tạo ra một bản ghi có bằng chứng, cho phép truy vết (traceability) nguồn gốc của mỗi thông tin, từ người cung cấp, thời điểm, đến bối cảnh ban đầu. Đây là nền tảng để xây dựng các tài liệu yêu cầu chính thức sau này cho dự án ERP của Nova Foods.

Tiêu chí	Hướng dẫn sử dụng
Khi nào sử dụng	Dùng template này làm nhật ký trong các hoạt động: • Phỏng vấn (Interviews) với chuyên gia nghiệp vụ. • Tổ chức hội thảo yêu cầu (Requirement Workshops). • Phân tích tài liệu nghiệp vụ có sẵn (Document Analysis). • Quan sát quy trình vận hành thực tế (Observation).
Khi nào KHÔNG sử dụng	Không dùng để thay thế các artifact sau: • Tài liệu đặc tả yêu cầu (Requirement Specification): Log này là đầu vào, không phải sản phẩm cuối cùng. • Kế hoạch dự án (Project Plan): Không dùng để theo dõi tiến độ, nguồn lực hay chi phí. • Nhật ký lỗi (Bug Log): Không dùng để ghi nhận lỗi phần mềm trong quá trình kiểm thử. • Tài liệu yêu cầu đã được baseline: Log ghi lại quá trình, không phải kết quả cuối cùng đã được chốt.

Vai trò & Trách nhiệm	Diễn giải trong phạm vi Template này
Owner (Người sở hữu)	Business Analyst (BA) trực tiếp thực hiện hoạt động khơi gợi yêu cầu. BA chịu trách nhiệm điền, cập nhật và bảo toàn tính toàn vẹn của nhật ký này.
Consumers (Người sử dụng)	• Project Manager (PM): Xem để nắm bắt rủi ro, các điểm chưa rõ ràng và phạm vi có thể thay đổi. • Development Team & Architect: Đọc để có bối cảnh ban đầu về yêu cầu trước khi nhận đặc tả chính thức. • QA Team: Dùng làm cơ sở ban đầu để lập kế hoạch kiểm thử (test planning). • Business Stakeholders: Xem lại để xác nhận các thông tin họ cung cấp đã được ghi nhận chính xác.
Authority (Thẩm quyền)	• Business Analyst: Có thẩm quyền về cấu trúc và nội dung ghi chép trong log. • Business Owner / Subject Matter Expert (SME): Có thẩm quyền cuối cùng về tính đúng đắn của nội dung nghiệp vụ được ghi nhận. BA không tự quyết định yêu cầu.

Luồng Dữ liệu Artifact	Diễn giải
Prerequisites (Điều kiện đầu vào)	Trước khi sử dụng, cần có: • Project Charter hoặc Statement of Work (SOW) để xác định phạm vi tổng thể. • Stakeholder Register (Danh bạ bên liên quan) để biết cần làm việc với ai.
Downstream Artifacts (Artifacts đầu ra)	Nội dung từ log này là nguồn đầu vào cho các tài liệu: • TMPL-REQ-002_BUSINESS_REQUIREMENT_DOCUMENT.md • TMPL-REQ-003_SOFTWARE_REQUIREMENT_SPECIFICATION.md • CANONICAL_BUSINESS_RULES.md • CANONICAL_DATA_DICTIONARY.md
Escalation (Quy trình leo thang)	Khi có mâu thuẫn, yêu cầu ngoài phạm vi, hoặc vấn đề không thể giải quyết ở cấp độ BA và stakeholder, quy trình như sau: 1. BA ghi nhận rõ vấn đề và bằng chứng vào log. 2. BA cố gắng hoà giải trực tiếp giữa các bên. 3. Nếu thất bại, BA leo thang (escalate) vấn đề lên Project Manager. 4. PM sẽ ra quyết định hoặc trình lên ban chỉ đạo dự án (Steering Committee) nếu cần thiết.

Định danh Chính tắc, Nguồn gốc và Nghĩa vụ Kiểm soát

Template này được nhận dạng và quản lý thông qua các định danh và nguồn gốc chính tắc (canonical) sau. Việc tuân thủ các liên kết này là bắt buộc để duy trì tính toàn vẹn của bộ tài liệu (corpus).

Bảng 1: Định danh và Nguồn gốc

Thuộc tính	Giá trị	Diễn giải & Nguồn kiểm soát
Template ID	TMPL-REQ-001	ID chính tắc của template, được đăng ký và quản lý trong TEMPLATE_MANIFEST. Phải được sử dụng nguyên vẹn khi tham chiếu.
Tên tệp Canonical	/03-templates/TMPL-REQ-001_REQUIREMENT_ELICITATION_LOG.md	Đường dẫn nguồn chân lý (source of truth). Mọi bản sao, bản xuất hoặc các tệp có tên tương tự không được xem là phiên bản được kiểm soát.
Tham chiếu Manifest	TEMPLATE_MANIFEST	Sự tồn tại, phiên bản và metadata của template này được điều phối bởi /01-curriculum/TEMPLATE_MANIFEST.md.
Nguồn Tri thức chính	BABOK Guide v3	Cấu trúc và mục đích của việc khơi gợi yêu cầu (requirement elicitation) dựa trên các khu vực tri thức, kỹ thuật và tác vụ được định nghĩa trong /00-research/00_SOURCE_MAP.md.
Nguồn Tiêu chuẩn	ISO/IEC/IEEE 29148:2018	Cung cấp ngữ cảnh về vòng đời yêu cầu (requirements lifecycle) theo tiêu chuẩn quốc tế, được tham chiếu từ /00-research/00_SOURCE_MAP.md.
Chapter Handbook	Tham chiếu đến Chapter về Requirements Elicitation and Lifecycle Management.	Template này là công cụ thực hành cho nội dung lý thuyết trong handbook tương ứng, được định nghĩa trong /01-curriculum/CHAPTER_MANIFEST.md.

Nghĩa vụ Truy vết (Traceability Obligations)

Template này là một công cụ tạo ra khả năng truy vết—khả năng theo dõi một yêu cầu từ nguồn gốc đến khi hoàn thiện. Mọi nhật ký (log) được tạo từ template này phải tuân thủ các nghĩa vụ sau:

• Định danh Yêu cầu: Mọi yêu cầu được ghi nhận (ví dụ REQ-NF-XXXX) phải có định danh duy nhất, được đăng ký và quản lý trong sổ đăng ký chính tắc /01-curriculum/TRACEABILITY_ID_REGISTRY.md.
• Nguồn gốc Yêu cầu: Nguồn gốc của mỗi yêu cầu (stakeholder, buổi workshop, tài liệu pháp lý) phải được ghi nhận rõ ràng, không được suy diễn.
• Quy tắc Nghiệp vụ: Bất kỳ quy tắc nghiệp vụ (RULE-NF-XXXX) nào được trích dẫn làm ràng buộc cho một yêu cầu phải liên kết đến định nghĩa chính tắc của nó trong /01-curriculum/CANONICAL_BUSINESS_RULES.md.
• Thành phần Dữ liệu: Các trường dữ liệu được đề cập trong yêu cầu cần tham chiếu đến định nghĩa logic trong /01-curriculum/CANONICAL_DATA_DICTIONARY.md để đảm bảo tính nhất quán toàn hệ thống.

Bảng 2: Quy tắc Kiểm soát Thay đổi Template

Loại Thay đổi	Tác động Phiên bản Template	Quy trình & Thẩm quyền
Sửa lỗi nhỏ không ảnh hưởng cấu trúc (ví dụ: chính tả, ngữ pháp ở Tier 1, 5, 6).	Tăng bản vá (patch), ví dụ: v0.9.0 → v0.9.1.	Owner của template có thể thực hiện sau khi ghi nhận yêu cầu thay đổi (Change Request - CR).
Thay đổi cấu trúc template (thêm/xóa/sửa cột trong Tier 2).	Tăng bản phụ (minor), ví dụ: v0.9.0 → v0.10.0.	Yêu cầu CR chi tiết, có phân tích tác động. Phải được phê duyệt bởi Owner của /01-curriculum/01_CURRICULUM_ARCHITECTURE.md.
Thay đổi mục đích, governance hoặc phạm vi (Tier 1).	Tăng bản phụ (minor), ví dụ: v0.9.0 → v0.10.0.	Yêu cầu CR chi tiết, có phân tích tác động đến toàn bộ corpus. Phải được phê duyệt bởi Owner của Curriculum Architecture.
Cập nhật nội dung ví dụ Nova Foods (Tier 3 và Tier 4).	Không thay đổi phiên bản của template.	Được xem là một phần của việc soạn thảo nội dung, không phải thay đổi cấu trúc template. Do Owner của template quản lý.

2. Tier 2 – Mẫu Trống Sẵn Sàng để Sao Chép-Dán

Phần này cung cấp một mẫu trống hoàn chỉnh để ghi nhận một yêu cầu duy nhất. Sao chép toàn bộ nội dung từ <!-- Bắt đầu mẫu... đến <!-- Kết thúc mẫu... vào một tệp Markdown mới. Đặt tên tệp theo quy ước REQ-NF-XXXX_Tieu_de_ngan_gon.md.

A. Metadata và Nhận dạng Yêu cầu

Bảng này chứa thông tin quản trị cốt lõi của yêu cầu.

Trường Metadata	Giá trị / Hướng dẫn
ID Yêu cầu	<Mã yêu cầu duy nhất, ví dụ: REQ-NF-0001> Định danh không đổi. Phải được đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md.
Tiêu đề Yêu cầu	<Tiêu đề ngắn gọn, mô tả chức năng. Ví dụ: Tạo Đơn Đặt Hàng tự động từ nhu cầu nguyên vật liệu>
Loại Yêu cầu	<Chọn một: Business, Stakeholder, Solution (Functional/Non-Functional)> Business*: Mục tiêu nghiệp vụ. Stakeholder: Nhu cầu người dùng. Solution*: Hệ thống phải làm gì (Chức năng/Phi chức năng).
Trạng thái	<Chọn một: Draft, In Review, Approved, Rejected, Implemented, Canceled> Luôn bắt đầu với Draft.
Mức ưu tiên	<Chọn một: Critical, High, Medium, Low> Xác định mức độ khẩn cấp cùng với Chủ sở hữu Nghiệp vụ (Business Owner).
Ngày ghi nhận	<YYYY-MM-DD, ví dụ: 2026-08-15>
Người ghi nhận (BA)	<Tên của Business Analyst>
Nguồn gốc	<Nguồn phát sinh yêu cầu. Ví dụ: Workshop với Phòng Mua hàng ngày 2026-08-14, Điều 5 Nghị định 123/2020/NĐ-CP>
Bên liên quan chính	<Tên và Chức danh người yêu cầu chính. Ví dụ: Nguyễn Văn A, Trưởng phòng Mua hàng>

B. Mô tả Chi tiết Yêu cầu

1. Mô tả Yêu cầu (User Story Format)

Sử dụng định dạng User Story để mô tả yêu cầu từ góc nhìn người dùng cuối.

Là một <Vai trò người dùng, ví dụ: Nhân viên mua hàng>, Tôi muốn <Hành động/Chức năng, ví dụ: hệ thống tự động tạo brouillon Đơn Đặt Hàng cho các nguyên vật liệu dưới ngưỡng tồn kho tối thiểu>, Để <Giá trị/Lợi ích nghiệp vụ, ví dụ: giảm thiểu sai sót thủ công và đảm bảo không gián đoạn sản xuất do thiếu hụt nguyên vật liệu>.

2. Bối cảnh và Lý do Nghiệp vụ (Business Rationale)

Giải thích tại sao yêu cầu này quan trọng. Nêu rõ vấn đề hiện tại, cơ hội cải tiến, và giá trị mang lại cho Nova Foods.

<Mô tả vấn đề nghiệp vụ cần giải quyết. Ví dụ: Quy trình tạo đơn đặt hàng hiện tại hoàn toàn thủ công, dễ bỏ sót nguyên vật liệu sắp hết, dẫn đến nguy cơ dừng dây chuyền sản xuất. Tự động hóa quy trình này giúp tăng hiệu suất 20% và giảm 90% lỗi đặt hàng sai số lượng, đảm bảo tính liên tục của sản xuất.>

3. Tiêu chí Chấp nhận (Acceptance Criteria)

Đây là danh sách các điều kiện có thể kiểm thử (testable conditions) để xác nhận yêu cầu đã được hoàn thành đúng. Cú pháp Gherkin (Given/When/Then) được khuyến khích để đảm bảo rõ ràng.

AC ID	Tiêu chí Chấp nhận
<REQ-ID>.AC.01	Given <Bối cảnh/Điều kiện tiên quyết>, When <Hành động của người dùng/sự kiện hệ thống>, Then <Kết quả mong đợi có thể xác minh được>.
<REQ-ID>.AC.02	Given <...>, When <...>, Then <...>
<REQ-ID>.AC.03	<Mô tả tiêu chí chấp nhận khác nếu không theo dạng Gherkin, ví dụ: Giao diện phải tuân thủ hướng dẫn trong Brand Guideline v2.1.>
...	Thêm các dòng cần thiết. Không có yêu cầu nào được chấp nhận mà không có ít nhất một AC rõ ràng.

C. Phạm vi, Giả định và Ràng buộc

1. Trong phạm vi (In-Scope)

• <Chức năng cụ thể được bao gồm trong yêu cầu này. Ví dụ: Hệ thống quét kho và tạo brouillon đơn hàng.>
• <Hệ thống/module bị ảnh hưởng. Ví dụ: Module Quản lý Kho (Inventory), Module Mua hàng (Purchasing).>

2. Ngoài phạm vi (Out-of-Scope)

• <Chức năng liên quan nhưng sẽ không được thực hiện trong yêu cầu này. Ví dụ: Quy trình phê duyệt Đơn Đặt Hàng (được xử lý trong REQ-NF-0002).>
• <Bất kỳ mục nào bị loại trừ có chủ đích để tránh hiểu nhầm. Ví dụ: Tích hợp với nhà cung cấp qua API.>

3. Giả định (Assumptions)

• <Điều kiện được cho là đúng nhưng chưa được xác minh. Ví dụ: Dữ liệu định mức tồn kho tối thiểu (min stock level) cho mỗi nguyên vật liệu đã có và chính xác.>
• Mỗi giả định phải có kế hoạch xác minh.

4. Ràng buộc (Constraints)

• <Hạn chế về kỹ thuật, ngân sách, thời gian, pháp lý. Ví dụ: Phải tương thích với hệ thống ERP hiện tại (SAP S/4HANA). Phải tuân thủ Luật Kế toán 88/2015/QH13. Giao diện phải tuân thủ WCAG 2.2 mức AA.>

D. Truy vết và Liên kết (Traceability)

Bảng này liên kết yêu cầu với các thành phần khác. Mục đích là quản lý tác động khi có thay đổi.

Loại liên kết	ID Tham chiếu	Mô tả liên kết
Bị chi phối bởi (Parent)	<ID của Yêu cầu nghiệp vụ/Feature cấp cao hơn>	Yêu cầu này giúp hiện thực hóa yêu cầu cha nào.
Chi phối (Child)	<ID của yêu cầu con/task kỹ thuật>	Yêu cầu con nào được tạo ra để thực hiện yêu cầu này.
Liên quan đến (Related)	<ID của yêu cầu liên quan khác>	Yêu cầu có mối quan hệ nhưng không phải cha-con.
Quy tắc Nghiệp vụ	<RULE-NF-XXXX>	Tuân thủ quy tắc từ /01-curriculum/CANONICAL_BUSINESS_RULES.md.
Thành phần Dữ liệu	<DATA-NF-XXXX>	Sử dụng hoặc tác động đến dữ liệu từ /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
Trường hợp Sử dụng	<UC-NF-XXXX>	Được mô tả chi tiết trong Use Case này.
Trường hợp Kiểm thử	<TC-NF-XXXX>	Được kiểm thử bởi Test Case này.

E. Lịch sử Xem xét và Phê duyệt

Bảng này ghi lại quá trình xem xét và phê duyệt yêu cầu từ các bên liên quan.

Ngày	Người xem xét	Vai trò	Quyết định	Ghi chú / Lý do
<YYYY-MM-DD>	<Tên người xem xét>	<Business Owner, Architect, QA Lead...>	<Pending, Approved, Rejected, Approved with comments>	<Ghi chú cụ thể, ví dụ: Cần làm rõ AC.02 về điều kiện lỗi khi không kết nối được DB.>
...	...	...	...	...

Cấu trúc Ghi nhận Chi tiết, Truy vết và Quản trị

Các bảng dưới đây cung cấp một cấu trúc hoàn chỉnh để ghi nhận, theo dõi và quản trị một yêu cầu trong suốt vòng đời của nó. Việc điền đầy đủ các bảng này đảm bảo tính minh bạch, khả năng kiểm toán và giảm thiểu rủi ro hiểu sai.

B. Lịch sử Phiên bản Yêu cầu

Bảng này theo dõi các thay đổi đối với bản ghi yêu cầu này, không phải toàn bộ tài liệu. Nó rất quan trọng để kiểm toán (audit trail), cho phép mọi người hiểu được yêu cầu đã phát triển như thế nào theo thời gian.

Phiên bản	Ngày	Người thay đổi	Tóm tắt thay đổi
v1.0	<YYYY-MM-DD>	<Tên người khởi tạo>	Khởi tạo yêu cầu.
<v1.1>	<YYYY-MM-DD>	<Tên người thay đổi>	<Mô tả ngắn gọn thay đổi, ví dụ: "Cập nhật AC.03 để bao gồm trường hợp lỗi hết hạn token".>

C. Bằng chứng Thu thập (Evidence Log)

Yêu cầu phải dựa trên bằng chứng, không phải giả định. Bảng này liên kết yêu cầu với các tạo tác nguồn (source artifacts) của nó như biên bản họp, email, hoặc tài liệu quy trình.

ID Bằng chứng	Loại	Mô tả	Vị trí / Liên kết
<EV-REQ-XXXXX-01>	<Email, Biên bản họp, Mockup, Tài liệu pháp lý...>	<Nội dung bằng chứng chứng minh điều gì.>	<Đường dẫn tệp, URL, hoặc tham chiếu an toàn như "Vault: secret/nova-foods/doc-ref-123".>
<EV-REQ-XXXXX-02>	<Phỏng vấn người dùng>	<Ghi âm hoặc bản ghi cuộc phỏng vấn với [Tên/Vai trò] xác nhận nhu cầu về tính năng X.>	<Link đến bản ghi âm trên SharePoint / ID file.

D. Nhật ký Quyết định (Decision Log)

Ghi lại các quyết định quan trọng liên quan đến yêu cầu này để tránh tranh cãi trong tương lai. Một quyết định không được ghi lại có thể bị lãng quên hoặc diễn giải sai.

Ngày	Vấn đề cần quyết định	Quyết định được đưa ra	Người quyết định (Vai trò)	Lý do
<YYYY-MM-DD>	<Câu hỏi cần làm rõ, ví dụ: "Hệ thống nên xử lý thế nào khi API đối tác không phản hồi sau 3 giây?">	<Quyết định cuối cùng, ví dụ: "Hệ thống sẽ ghi nhận lỗi, trả về thông báo chờ và thử lại sau 5 phút.">	<Tên người có thẩm quyền> (<Business Owner>)	<Lý do ngắn gọn cho quyết định, ví dụ: "Ưu tiên trải nghiệm người dùng không bị gián đoạn.">

E. Ghi nhận Ngoại lệ (Exception Log)

Chỉ sử dụng khi một yêu cầu cụ thể được cấp phép đi chệch khỏi một quy tắc, tiêu chuẩn hoặc quy trình chung đã được thiết lập. Việc ghi lại ngoại lệ đảm bảo sự quản trị chặt chẽ.

Ngày ghi nhận	Nội dung yêu cầu ngoại lệ	Người phê duyệt (Vai trò)	Thời hạn hiệu lực	Lý do & Tác động đã biết
<YYYY-MM-DD>	<Mô tả quy trình chuẩn và đề xuất đi chệch cho trường hợp này.>	<Tên người có thẩm quyền> (<Technical Architect>)	<Vĩnh viễn / Đến hết Q4 2026 / Cho phiên bản này...>	<Giải thích tại sao cần ngoại lệ và các tác động (chi phí, rủi ro, kỹ thuật) đã được chấp nhận.>

F. Ma trận Truy vết (Traceability Matrix)

Truy vết yêu cầu (requirements traceability) là một kỹ thuật cốt lõi trong phân tích nghiệp vụ, được yêu cầu bởi các tiêu chuẩn như ISO/IEC/IEEE 29148. Nó kết nối yêu cầu này với các yếu tố khác trong dự án, đảm bảo không có gì bị bỏ sót và mọi thứ đều được kiểm thử.

Loại liên kết	ID Tham chiếu	Mô tả / Ghi chú
Bao hàm bởi (Parent)	<REQ-NF-XXXX>	Yêu cầu này là một phần chi tiết hóa của yêu cầu cấp cao nào.
Chi phối (Child)	<TASK-NF-YYYY>	Task kỹ thuật hoặc yêu cầu con nào được tạo ra để thực hiện yêu cầu này.
Liên quan đến (Related)	<REQ-NF-ZZZZ>	Yêu cầu khác có mối quan hệ logic nhưng không phải cha-con.
Quy tắc Nghiệp vụ	<RULE-NF-AAAA>	Tuân thủ hoặc thực thi quy tắc nghiệp vụ nào từ /01-curriculum/CANONICAL_BUSINESS_RULES.md.
Thành phần Dữ liệu	<DATA-NF-BBBB>	Sử dụng hoặc tác động đến thực thể dữ liệu nào từ /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
Trường hợp Sử dụng	<UC-NF-CCCC>	Là một phần của kịch bản/trường hợp sử dụng nào.
Trường hợp Kiểm thử	<TC-NF-DDDD>	Được xác minh bởi trường hợp kiểm thử nào.

G. Lịch sử Xem xét và Phê duyệt (Review & Approval History)

Đây là bằng chứng chính thức về việc các bên liên quan đã xem xét và chấp thuận (hoặc từ chối) yêu cầu.

Ngày	Người xem xét	Vai trò	Quyết định	Ghi chú / Lý do
<YYYY-MM-DD>	<Tên người xem xét>	<Business Owner, Architect, QA Lead...>	<Pending, Approved, Rejected, Approved with comments>	<Ghi chú cụ thể, ví dụ: "Cần làm rõ AC.02 về điều kiện lỗi khi không kết nối được DB.">
<YYYY-MM-DD>	<Tên người xem xét>	<Legal Advisor>	<Approved>	Nội dung tuân thủ Nghị định 356/2025/NĐ-CP.

Hướng dẫn điền trường, quy tắc xác thực và giá trị hợp lệ

Các bảng dưới đây quy định cách điền thông tin, các giá trị được chấp nhận và quy tắc xác thực cho từng trường trong biểu mẫu nhật ký yêu cầu. Tuân thủ nghiêm ngặt để đảm bảo tính nhất quán, khả năng truy vết và chất lượng của tài liệu yêu cầu.

Bảng 1: Hướng dẫn cho các trường Metadata

Trường (Field)	Hướng dẫn & Quy tắc xác thực	Giá trị hợp lệ / Ví dụ
REQ-ID	Định danh duy nhất, không thể thay đổi sau khi tạo. Phải tuân theo định dạng [MÃ DỰ ÁN]-[LĨNH VỰC]-[SỐ THỨ TỰ]. Mã này phải được đăng ký trong TRACEABILITY_ID_REGISTRY để đảm bảo không trùng lặp.	NFE-INV-001 (Nova Foods ERP - Inventory - 001)
Requirement Title	Tiêu đề ngắn gọn, súc tích, mô tả chính xác mục đích của yêu cầu. Bắt đầu bằng động từ mạnh.	Hệ thống cho phép tạo phiếu nhập kho từ đơn hàng nhà cung cấp.
Status	Trạng thái hiện tại của yêu cầu trong vòng đời phát triển. Chỉ được cập nhật theo quy trình review.	DRAFT, IN_REVIEW, APPROVED, REJECTED, DEFERRED, IMPLEMENTED
Priority	Mức độ ưu tiên theo phương pháp MoSCoW (Must, Should, Could, Won't) để hỗ trợ lập kế hoạch. MUST_HAVE là bắt buộc cho lần ra mắt.	MUST_HAVE, SHOULD_HAVE, COULD_HAVE
Source	Nguồn gốc phát sinh yêu cầu. Ghi rõ tên người, chức danh, tài liệu, hoặc buổi họp. Nếu có, tham chiếu đến ID truy vết tương ứng.	Phỏng vấn chị Mai (Kế toán trưởng) ngày 2026-08-10, Tham chiếu: MEET-ACC-003

Bảng 2: Hướng dẫn cho Nội dung Yêu cầu và Tiêu chí Chấp nhận

Trường (Field)	Hướng dẫn & Quy tắc xác thực	Ví dụ
Requirement Statement	Diễn giải đầy đủ, rõ ràng, đơn nhất và có thể kiểm thử. Xác định rõ "ai", "làm gì", và "kết quả mong muốn". Tránh các từ ngữ chủ quan như "nhanh", "linh hoạt", "dễ sử dụng".	Là một người dùng thuộc vai trò "Thủ kho", tôi muốn tìm kiếm sản phẩm bằng mã SKU hoặc tên sản phẩm để có thể xác định nhanh chóng thông tin tồn kho.
Rationale	Lý do nghiệp vụ đằng sau yêu cầu. Giải thích giá trị mà nó mang lại. Kết nối trực tiếp đến mục tiêu dự án hoặc vấn đề cần giải quyết.	Giảm thời gian xử lý đơn hàng tại kho. Hạn chế sai sót khi tra cứu sản phẩm thủ công. Tăng hiệu suất công việc cho thủ kho.
Acceptance Criteria (AC)	Các điều kiện cụ thể, có thể kiểm chứng, mà khi thỏa mãn thì yêu cầu được xem là hoàn thành. Sử dụng cấu trúc GIVEN-WHEN-THEN (Bối cảnh - Hành động - Kết quả). Mỗi AC là một kịch bản kiểm thử nguyên tử.	AC-01: GIVEN người dùng đã đăng nhập VÀ đang ở trang quản lý kho WHEN người dùng nhập một mã SKU hợp lệ vào ô tìm kiếm VÀ nhấn "Tìm" THEN hệ thống phải hiển thị chính xác thông tin sản phẩm tương ứng trong vòng 2 giây.

Bảng 3: Hướng dẫn cho Truy vết, Phụ thuộc và Tham chiếu nhạy cảm

Trường (Field)	Hướng dẫn & Quy tắc xác thực	Ví dụ
Traceability Links	Liên kết đến các artifact liên quan như quy tắc nghiệp vụ (BR-ID), ca sử dụng (UC-ID), hoặc tài liệu kiến trúc. Sử dụng ID đã được đăng ký chính thức.	Quy tắc nghiệp vụ liên quan: BR-INV-012 Ca sử dụng: UC-WH-005
Dependencies	Liệt kê các REQ-ID khác phải được hoàn thành trước khi yêu cầu này có thể bắt đầu. Giúp xác định thứ tự triển khai.	Phụ thuộc vào: REQ-AUTH-001 (Chức năng đăng nhập)
Assumptions	Ghi lại các giả định được đưa ra khi phân tích yêu cầu này. Nếu giả định sai, yêu cầu có thể cần được xem xét lại.	Giả định rằng dữ liệu sản phẩm đã được đồng bộ từ hệ thống quản lý sản phẩm (PIM).

Các phần có điều kiện và mẫu tham chiếu an toàn

• Yêu cầu phi chức năng (Non-Functional Requirements - NFRs): Phần này chỉ được điền khi yêu cầu có ràng buộc cụ thể về hiệu năng, bảo mật, khả năng sử dụng, hoặc độ tin cậy. Nếu không có, để trống hoặc ghi "Không có". Ví dụ: Thời gian phản hồi tìm kiếm phải dưới 2 giây khi cơ sở dữ liệu có 1 triệu sản phẩm.

• Mẫu tham chiếu thông tin nhạy cảm: Tuyệt đối không ghi mật khẩu, API key, hoặc bất kỳ thông tin nhạy cảm nào trực tiếp vào tài liệu này. Thay vào đó, sử dụng một định dạng tham chiếu đến một kho chứa bí mật an toàn (secure vault). Điều này đảm bảo tài liệu yêu cầu có thể được chia sẻ mà không làm lộ thông tin bí mật.

  • Định dạng: [TÊN_KHO_CHỨA:TÊN_KHÓA_BÍ_MẬT]
  • Ví dụ: Hệ thống phải sử dụng API key được lấy từ [SECRET_VAULT:ZALOPAY_GW_API_KEY] để xác thực với cổng thanh toán ZaloPay.

3. Tier 3 – Fully Completed Nova Foods Case: Core Record

Phần này trình bày hai bản ghi yêu cầu đã điền đầy đủ cho tình huống mô phỏng Nova Foods: REQ-WH-007 về nhận hàng tại kho và REQ-NF-001 về khởi tạo Nhà Cung Cấp (NCC). Mọi tên, ID, ngày tháng, giá trị, quyết định và kết quả trong Tier 3 là dữ liệu mô phỏng phục vụ học tập. Cả hai bản ghi giữ trạng thái IN_REVIEW; chưa bản ghi nào được phê duyệt hoặc baselined.

Bảng Nhật Ký Khai Thác Yêu Cầu (Requirement Elicitation Log)

Trường Dữ Liệu	Giá trị (Tình huống Mô phỏng Nova Foods)
Requirement ID	REQ-WH-007
Requirement Name	Tự động tạo Phiếu Nhập Kho (Goods Receipt Note - GRN) từ Đơn Mua Hàng (Purchase Order - PO) qua thiết bị di động.
Date Recorded	2026-08-07
Recorded By	BA-02 (Lê Minh Khang)
Version	1.0
Status	IN_REVIEW
Priority	High
Source	Phỏng vấn trực tiếp với Trưởng Kho ngày 2026-08-05. ID buổi phỏng vấn: ELC-INT-20260805-01. Trưởng Kho xác nhận luồng nhận hàng, điểm kiểm soát đối chiếu PO và hậu quả của cập nhật tồn kho chậm.
Stakeholders	STK-05: Nguyễn Văn An (Trưởng Kho), Business Owner cho vận hành nhận hàng. STK-09: Trần Thị Bích (Kế toán Kho), Subject Matter Expert cho chứng từ và đối soát. STK-12: Hoàng Gia Huy (Nhân viên Kho), End User thực hiện quét PO và ghi nhận số lượng thực nhận.
Business Need	Nova Foods cần giảm nhập liệu thủ công và sai sót ghi chép tay GRN. Nhân viên Kho phải cập nhật số lượng thực nhận ngay khi hàng về để bộ phận Kế hoạch Sản xuất dùng tồn kho thực tế khi lập kế hoạch. Kết quả cần đạt: tồn kho trên ERP phản ánh GRN được xác nhận thay vì chờ Kế toán Kho nhập lại cuối ngày.
Current State (As-Is)	1. Nhân viên Kho nhận hàng cùng chứng từ giấy từ nhà cung cấp. 2. Nhân viên Kho đối chiếu thủ công chứng từ với bản in PO. 3. Nhân viên Kho viết tay GRN và ký nhận. 4. Cuối ngày, Kế toán Kho nhập lại dữ liệu từ phiếu giấy vào file Excel. Vấn đề: Tồn kho cập nhật trễ 8–24 tiếng. Sai sót nhập liệu chiếm khoảng 3% tổng số phiếu. Kho, Kế toán và Kế hoạch Sản xuất khó xác định chứng từ nguồn khi có chênh lệch số lượng.
Future State (To-Be)	1. Nhân viên Kho dùng mobile app quét barcode trên chứng từ nhà cung cấp hoặc trên PO của Nova Foods. 2. Hệ thống tìm PO tương ứng và hiển thị thông tin PO để Nhân viên Kho đối chiếu. 3. Nhân viên Kho nhập số lượng thực nhận cho từng mặt hàng. 4. Hệ thống kiểm tra PO hợp lệ, còn hiệu lực và dữ liệu sản phẩm có sẵn. 5. Hệ thống tạo GRN điện tử, lưu người tạo và thời điểm tạo. 6. Hệ thống cập nhật tồn kho trong ERP sau khi GRN được tạo. Kết quả: Kế hoạch Sản xuất nhận dữ liệu tồn kho đã ghi nhận; Kế toán Kho có chứng từ điện tử để đối soát.
Scope (In / Out)	Trong phạm vi (In-Scope): - Quét barcode PO từ chứng từ nhà cung cấp hoặc bản in PO của Nova Foods. - Hiển thị PO tương ứng trên mobile app. - Nhập số lượng thực nhận theo từng mặt hàng PO. - Tạo GRN điện tử dựa trên PO hợp lệ và còn hiệu lực. - Cập nhật tức thì vào module Quản lý Tồn kho (Inventory Management). - Lưu vết người tạo, thời điểm tạo và PO nguồn của GRN. Ngoài phạm vi (Out-of-Scope): - Xử lý hàng hỏng, hàng trả lại; nội dung này thuộc REQ-WH-009. - Tích hợp cân điện tử. - Quản lý nhiều địa điểm/vị trí (bin location) trong kho.
Traceability Links	Quy tắc nghiệp vụ liên quan: BR-WH-003: GRN phải được tạo dựa trên một PO hợp lệ và còn hiệu lực. Hệ thống không tạo GRN nếu không xác định được PO nguồn. BR-ACC-005: Định dạng và thông tin trên GRN phải tuân thủ Nghị định 123/2020/NĐ-CP. Cơ sở áp dụng chi tiết cần được xác minh bởi bộ phận có thẩm quyền. Ca sử dụng liên quan: UC-WH-005 (Nhận hàng từ Nhà cung cấp).
Dependencies	REQ-MDM-002: Master Data cho Sản phẩm và Nhà cung cấp phải hoàn chỉnh để hệ thống hiển thị đúng dữ liệu PO và ghi nhận tồn kho. REQ-PUR-004: Module Quản lý Mua hàng (Purchasing) phải hoạt động và tạo được PO để GRN có chứng từ nguồn.
Assumptions	- Kho có kết nối Wi-Fi ổn định tại điểm nhận hàng. - Nhân viên Kho có thiết bị di động với camera hoạt động. - Nhà cung cấp cung cấp chứng từ giao hàng có barcode PO; nếu không có, Nhân viên Kho quét barcode từ bản in PO của Nova Foods. - PO hiển thị trên mobile app thuộc dữ liệu mà Nhân viên Kho được phép sử dụng cho nghiệp vụ nhận hàng.
Review Outcome	BA-02 đã ghi nhận yêu cầu từ ELC-INT-20260805-01. STK-05, STK-09 và STK-12 cần xem xét tính phù hợp của luồng To-Be, điều kiện PO hợp lệ và nội dung GRN trước quyết định tiếp theo. Artifact giữ IN_REVIEW; chưa có phê duyệt.
Trade-off and Consequence	Giải pháp ưu tiên cập nhật tồn kho sớm và truy vết GRN thay vì tiếp tục dùng phiếu giấy làm nguồn nhập liệu chính. Đổi lại, Nova Foods phụ thuộc vào Wi-Fi, thiết bị di động, dữ liệu PO và Master Data. Nếu các phụ thuộc không sẵn sàng, Nhân viên Kho không thể hoàn tất luồng tạo GRN điện tử theo phạm vi này; tồn kho sẽ không có cập nhật tức thì từ quy trình mục tiêu.

3. Ví dụ hoàn chỉnh cho Case Study Nova Foods: Hồ sơ cốt lõi

Bảng dưới đây là bản ghi yêu cầu hoàn chỉnh cho yêu cầu khởi tạo NCC của Nova Foods. Mọi định danh, tên người và chi tiết nghiệp vụ là giả định phục vụ học tập. Artifact giữ IN_REVIEW; nội dung là đầu vào xem xét, không phải quyết định đã phê duyệt.

Trường Dữ liệu	Giá trị
Định danh Yêu cầu (ID)	REQ-NF-001
Tên Yêu cầu	Tự động hóa Quy trình Khởi tạo Nhà Cung Cấp (NCC) Mới
Nguồn gốc	Bà Lê Thị Minh, Trưởng phòng Mua hàng. Bà Minh nêu nhu cầu giảm thời gian chờ tạo NCC để Nhân viên Mua hàng có thể tạo PO.
Ngày ghi nhận	2026-08-07
Mức độ ưu tiên	Cao
Trạng thái	IN_REVIEW

3.1. Các bên liên quan (Stakeholders)

Tên	Chức vụ	Vai trò trong dự án	Mối quan tâm chính
Bà Lê Thị Minh	Trưởng phòng Mua hàng	Business Owner (Chủ sở hữu nghiệp vụ)	Giảm thời gian chờ tạo NCC để không lỡ cơ hội mua hàng. Bà Minh xác nhận nhu cầu nghiệp vụ và đánh giá tác động đến Mua hàng.
Ông Trần Văn Hùng	Kế toán trưởng	Subject Matter Expert (Chuyên gia nghiệp vụ)	Đảm bảo dữ liệu NCC chính xác, hỗ trợ kiểm soát thuế và kế toán. Ông Hùng xem xét quy tắc MST, dữ liệu ngân hàng và điều kiện duyệt.
Chị Nguyễn Thu Trang	Kế toán Công nợ	End User (Người dùng cuối)	Giảm nhập liệu thủ công, tránh sai sót khi đối soát và thanh toán. Chị Trang rà soát, duyệt hoặc từ chối bản ghi NCC chờ duyệt.
Anh Phạm Tuấn Anh	Nhân viên Mua hàng	End User (Người dùng cuối)	Có công cụ tạo NCC nhanh, dễ dùng, phản hồi lỗi tức thì. Anh Tuấn Anh nhập và gửi thông tin NCC mới.

3.2. Mô tả chi tiết

Bối cảnh: Phòng Mua hàng cần bổ sung NCC mới để tìm nguồn nguyên liệu đa dạng và giá cạnh tranh. Quy trình hiện tại chậm tạo NCC trong ERP, làm chậm tạo PO. Đối tượng nghiệp vụ là bản ghi NCC; kết quả mong muốn là NCC được duyệt, có trạng thái ACTIVE, và có thể chọn khi tạo PO.

Quy trình hiện tại (As-Is Process): 1. Nhân viên Mua hàng điền thông tin NCC vào tệp Excel F-PUR-05_New_Supplier_Form.xlsx. 2. Nhân viên Mua hàng gửi tệp Excel qua email đến Phòng Kế toán. 3. Kế toán Công nợ nhận email, mở tệp và nhập thủ công từng trường vào ERP. 4. Kế toán Công nợ liên hệ lại Nhân viên Mua hàng khi thiếu hoặc sai thông tin, nhất là MST và số tài khoản ngân hàng. 5. NCC chỉ sẵn sàng để tạo PO sau khi Kế toán Công nợ hoàn tất nhập liệu và kiểm tra.

Vấn đề hiện trạng: Quy trình mất 2–3 ngày làm việc khi email bị trôi, người phụ trách bận hoặc thông tin sai cần xác nhận lại. Dữ liệu đi qua Excel, email và ERP. Mỗi lần sao chép thủ công tăng nguy cơ sai dữ liệu NCC, làm chậm PO, đối soát và thanh toán.

Nhu cầu nghiệp vụ (Business Need): Nova Foods cần giảm thời gian từ khi có thông tin NCC đến khi NCC sẵn sàng tạo PO trên ERP xuống dưới 4 giờ làm việc. Quy trình phải loại bỏ lỗi sao chép thủ công giữa Mua hàng và Kế toán. Hệ thống phải lưu được ai tạo, ai duyệt hoặc từ chối, thời điểm thực hiện và trạng thái NCC.

Quy trình mục tiêu (To-Be Process): 1. Nhân viên Mua hàng chọn chức năng “Tạo Nhà Cung Cấp” trên ERP. 2. Hệ thống hiển thị form nhập dữ liệu NCC. 3. Nhân viên Mua hàng nhập thông tin NCC và gửi bản ghi. 4. Hệ thống kiểm tra MST hoặc Tên NCC đã tồn tại để ngăn bản ghi trùng. 5. Hệ thống kiểm tra dữ liệu nhập tại màn hình, gồm định dạng MST và định dạng email. 6. Nếu dữ liệu hợp lệ, hệ thống tạo bản ghi NCC với trạng thái PENDING_APPROVAL. 7. Hệ thống gửi thông báo cho nhóm Kế toán Công nợ. 8. Kế toán Công nợ rà soát bản ghi, chọn “Duyệt” hoặc “Từ chối”, và ghi kết quả trên ERP. 9. Nếu duyệt, hệ thống chuyển NCC sang ACTIVE; Nhân viên Mua hàng có thể chọn NCC khi tạo PO. 10. Nếu từ chối, hệ thống giữ kết quả từ chối để Nhân viên Mua hàng biết bản ghi chưa thể dùng cho PO.

Ràng buộc và hậu quả: Giải pháp dùng ERP hiện có làm nguồn dữ liệu NCC duy nhất thay vì duy trì Excel và email làm kênh xử lý chính. Đổi lại, ERP phải có form nhập, kiểm tra dữ liệu, trạng thái và thông báo cho Kế toán Công nợ. Nếu thiếu các kiểm soát này, Nova Foods tiếp tục đối mặt với NCC trùng, PO chậm và dữ liệu khó truy vết.

3.3. Quy tắc nghiệp vụ liên quan (Business Rules)

ID Quy tắc	Tên Quy tắc	Mô tả	Nguồn tham chiếu / Lý do
BR-NF-ACC-003	Mã số thuế là bắt buộc và phải hợp lệ	Hệ thống không cho phép lưu bản ghi NCC nếu trường Mã số thuế (MST) bị bỏ trống. Định dạng MST phải là 10 hoặc 13 chữ số. NCC không thể được duyệt nếu thiếu MST. Actor thực hiện kiểm tra là hệ thống; Kế toán Công nợ dùng kết quả kiểm tra khi rà soát.	Yêu cầu từ Kế toán trưởng để hỗ trợ kiểm soát dữ liệu thuế và kế toán. Tham chiếu được ghi nhận: Nghị định 123/2020/NĐ-CP về hóa đơn, chứng từ. Verification required: bộ phận có thẩm quyền cần xác minh cơ sở áp dụng và yêu cầu dữ liệu chi tiết trước phê duyệt.
BR-NF-VEN-001	Chặn tạo NCC trùng lặp	Trước khi hiển thị form tạo mới, hệ thống kiểm tra MST hoặc Tên NCC đã tồn tại trong cơ sở dữ liệu. Nếu có kết quả trùng, hệ thống hiển thị cảnh báo và không cho phép tạo bản ghi mới. Nhân viên Mua hàng phải dùng bản ghi hiện có hoặc làm rõ dữ liệu với Kế toán Công nợ.	Yêu cầu từ Kế toán trưởng để duy trì Master Data sạch, tránh sai sót công nợ, thanh toán và chọn nhầm NCC khi tạo PO.

3.4. Lợi ích & Tác động

• Lợi ích kỳ vọng:
• Giảm thời gian xử lý trung bình từ 2 ngày xuống dưới 4 giờ làm việc.
• Loại bỏ lỗi sao chép thủ công giữa biểu mẫu Excel, email và ERP.
• Tăng truy vết: ERP lưu người tạo, người duyệt hoặc từ chối, thời điểm và trạng thái NCC.
• Chuyển thời gian của Kế toán Công nợ từ nhập lại dữ liệu sang rà soát, kiểm soát và phân tích.

• Cho phép Mua hàng dùng NCC ACTIVE để tạo PO sau khi Kế toán Công nợ duyệt.

• Tác động đến các bên liên quan:

• Nhân viên Mua hàng chịu trách nhiệm nhập dữ liệu đầy đủ và xử lý thông báo lỗi từ ERP.
• Kế toán Công nợ chịu trách nhiệm rà soát và quyết định duyệt hoặc từ chối bản ghi PENDING_APPROVAL.
• Kế toán trưởng có quyền xem xét quy tắc kiểm soát dữ liệu và bằng chứng xác minh liên quan.

• Phòng Mua hàng nhận NCC có thể dùng cho PO; không được dùng NCC chưa ACTIVE.

• Hậu quả nếu không thực hiện:

• Nova Foods tiếp tục dùng nguồn lực cho nhập liệu thủ công, giá trị thấp.
• Sai dữ liệu NCC có thể ảnh hưởng thanh toán, đối soát và báo cáo thuế.
• Quy trình nội bộ chậm có thể làm Mua hàng bỏ lỡ cơ hội mua hàng chiến lược.
• Dữ liệu phân tán giữa Excel, email và ERP tiếp tục làm giảm khả năng truy vết trách nhiệm.

Phân tích chi tiết và Cây quyết định (Elicitation Details and Decision Tree)

Phần này ghi lại phân tích cho REQ-NF-001. Phạm vi phân tích là khởi tạo NCC mới trên ERP, không phải tự động hóa toàn bộ quy trình PO. PO là kết quả nghiệp vụ phụ thuộc: NCC phải ACTIVE trước khi Nhân viên Mua hàng có thể chọn NCC để tạo PO.

Bối cảnh: Phòng Mua hàng xử lý thông tin NCC qua Excel và email; Kế toán Công nợ nhập lại dữ liệu vào ERP. Chậm trễ, sai dữ liệu và thiếu trạng thái tập trung làm các bên không biết chính xác NCC đã được tạo, đang chờ duyệt hay bị từ chối.

1. Phân tích Hiện trạng (As-Is) và Nhu cầu (To-Be)

Tiêu chí phân tích	Hiện trạng (As-Is)	Nhu cầu (To-Be / Underlying Need)
Khởi tạo NCC	Nhân viên Mua hàng nhập thông tin vào F-PUR-05_New_Supplier_Form.xlsx, rồi gửi email cho Kế toán.	Nhân viên Mua hàng tạo bản ghi NCC trực tiếp trên ERP. ERP là nơi lưu bản ghi nguồn.
Kiểm tra dữ liệu	Kế toán Công nợ phát hiện thiếu hoặc sai MST, email, số tài khoản sau khi nhận email.	ERP kiểm tra dữ liệu tại màn hình nhập; Kế toán Công nợ rà soát bản ghi hợp lệ trước duyệt.
Kiểm tra trùng lặp	Người dùng dựa vào trao đổi thủ công và kinh nghiệm để phát hiện NCC đã tồn tại.	ERP kiểm tra MST hoặc Tên NCC trước tạo mới; hệ thống chặn bản ghi trùng.
Phê duyệt	Kế toán Công nợ nhập dữ liệu và xác nhận qua trao đổi email. Trạng thái xử lý không tập trung.	ERP tạo trạng thái PENDING_APPROVAL; Kế toán Công nợ duyệt hoặc từ chối trên ERP.
Theo dõi trạng thái	Nhân viên Mua hàng gọi điện hoặc gửi email hỏi Kế toán.	Nhân viên Mua hàng xem trạng thái bản ghi trên ERP; trạng thái ACTIVE xác định NCC có thể dùng tạo PO.
Truy vết và kiểm soát	Excel và email chứa thông tin rời rạc; khó xác định ai xử lý tại từng thời điểm.	ERP lưu bản ghi, trạng thái, người tạo, hành động duyệt hoặc từ chối và thời điểm hành động.
Rủi ro sai sót	Cao do sao chép thủ công, bản tệp sai phiên bản và trao đổi không tập trung.	Giảm do dữ liệu nhập một lần, có kiểm tra và có quyết định duyệt trên hệ thống.

2. Các phương án đã xem xét (Options Analysis)

Phương án	Mô tả tóm tắt	Ưu điểm	Nhược điểm
1. Tối ưu quy trình hiện tại	Giữ F-PUR-05_New_Supplier_Form.xlsx, bổ sung macro và quy trình xử lý trên SharePoint/Shared Drive.	Chi phí triển khai thấp; thay đổi thói quen người dùng ít hơn.	Vẫn duy trì dữ liệu ngoài ERP, không loại bỏ hoàn toàn sao chép thủ công, khó kiểm soát trạng thái và truy vết.
2. Mua phần mềm NCC chuyên dụng	Mua giải pháp bên thứ ba để quản lý NCC và tích hợp với ERP.	Có thể có chức năng chuyên sâu về quản lý NCC.	Tăng chi phí bản quyền, tích hợp và vận hành; tạo thêm rủi ro đồng bộ dữ liệu giữa hai hệ thống.
3. Xây dựng trong ERP (Đề xuất)	Bổ sung chức năng tạo, kiểm tra, duyệt và quản lý trạng thái NCC trong ERP của Nova Foods.	ERP trở thành nguồn dữ liệu NCC duy nhất; giảm nhập lại dữ liệu; hỗ trợ truy vết; NCC ACTIVE sẵn sàng dùng cho PO.	Chi phí phát triển ban đầu cao hơn phương án 1; cần phân tích kỹ dữ liệu, phân quyền, trạng thái và quy tắc kiểm tra.

3. Tiêu chí và Quyết định

Tiêu chí quyết định	Trọng số	Đánh giá Phương án 3 (Xây dựng trong ERP)
Chi phí sở hữu toàn bộ (TCO)	Rất cao	Tốt hơn về dài hạn vì tránh duy trì luồng nhập lại và giảm chi phí tích hợp hệ thống riêng.
Mức độ tích hợp dữ liệu	Rất cao	Tốt nhất vì dữ liệu NCC, trạng thái duyệt và khả năng dùng cho PO cùng nằm trong ERP.
Khả năng truy vết & Kiểm toán	Cao	Tốt nhất vì hệ thống lưu hành động tạo, duyệt hoặc từ chối trên một bản ghi NCC tập trung.
Trải nghiệm người dùng	Trung bình	Tốt vì Mua hàng và Kế toán dùng giao diện ERP thay vì truyền tệp và email.
Thời gian triển khai ban đầu	Thấp	Chậm hơn phương án 1 vì cần phát triển, kiểm tra quy tắc dữ liệu và cấu hình quyền xử lý.

• Quyết định được đề xuất: Chọn Phương án 3: Xây dựng chức năng khởi tạo NCC trong ERP.
• Thẩm quyền quyết định: Ban chỉ đạo dự án ERP (ERP Project Steering Committee).
• Trạng thái quyết định: Đề xuất phục vụ xem xét. Chưa có bằng chứng về phê duyệt của Ban chỉ đạo dự án ERP. REQ-NF-001 giữ IN_REVIEW.
• Lý do chính: Phương án 3 giải quyết dữ liệu NCC rời rạc, nhập lại thủ công, thiếu trạng thái và thiếu truy vết. Phương án này dùng ERP làm nguồn dữ liệu NCC chính tắc, đồng thời tạo kiểm soát trước khi NCC được dùng cho PO.
• Trade-off: Nova Foods chấp nhận nỗ lực phân tích và phát triển ban đầu cao hơn để đổi lấy dữ liệu tập trung, kiểm tra tại điểm nhập và luồng duyệt có kiểm soát.

4. Hậu quả nếu lựa chọn sai (Consequence of Incorrect Decision)

• Nếu chọn Phương án 1: Nova Foods tiếp tục có rủi ro nhập liệu sai, thiếu minh bạch trạng thái và dữ liệu NCC phân tán. ERP vẫn nhận dữ liệu qua bước nhập lại. Thời gian tạo NCC và PO có thể vẫn phụ thuộc email và năng lực của từng người xử lý.
• Nếu chọn Phương án 2: Nova Foods phát sinh chi phí tích hợp và duy trì đồng bộ dữ liệu NCC. Khi ERP hoặc phần mềm NCC thay đổi, kết nối có thể bị ảnh hưởng. Mua hàng, Kế toán và PO có thể dùng dữ liệu không đồng nhất nếu đồng bộ không kịp thời.
• Nếu không chọn phương án nào: Quy trình Excel-email-ERP giữ nguyên. Kế toán Công nợ tiếp tục nhập lại dữ liệu; Mua hàng tiếp tục chờ 2–3 ngày làm việc; sai dữ liệu NCC và khó truy vết tiếp tục ảnh hưởng PO, đối soát và thanh toán.

4. Tier 3 – Fully Completed Nova Foods Case: Evidence and Traceability

Phần này ghi lại các bằng chứng, giả định, và các điểm cần xác minh liên quan đến yêu cầu REQ-NF-PO-001. Đây là các yếu tố hỗ trợ, làm rõ bối cảnh và giảm rủi ro cho yêu cầu.

4.1 Bằng chứng và Nguồn gốc (Evidence)

Bằng chứng củng cố sự cần thiết của yêu cầu.

ID Bằng chứng	Mô tả	Nguồn (Mô phỏng)	Loại Nguồn
EVD-NF-PO-001	Tỷ lệ lỗi nhập liệu cao trong quy trình PO thủ công.	MoM-20260715-ProcurementWorkshop	Biên bản họp
EVD-NF-PO-002	Yêu cầu về dấu vết kiểm toán (audit trail) tích hợp và không thể sửa đổi cho các giao dịch mua hàng.	AUD-NF-Q2-2026-InternalAuditReport	Báo cáo Kiểm toán Nội bộ
EVD-NF-PO-003	Phòng Kế toán báo cáo trễ trong việc đối chiếu công nợ do thiếu liên kết giữa PO và hóa đơn.	SRV-202607-AcctDeptFeedback	Khảo sát ý kiến

4.2 Các trường hợp ngoại lệ và luồng tiêu cực (Exceptions and Negative Paths)

Hệ thống phải xử lý các tình huống không mong muốn. Đây là các kịch bản quan trọng để đảm bảo tính toàn vẹn.

ID Kịch bản	Tình huống	Phản hồi Hệ thống Dự kiến	Mục đích Nghiệp vụ
NEG-NF-PO-001	Người dùng tạo PO với nhà cung cấp không tồn tại trong dữ liệu chủ (master data).	Từ chối lưu, hiển thị lỗi: "Nhà cung cấp không hợp lệ. Vui lòng chọn từ danh sách hoặc yêu cầu tạo mới."	Ngăn thanh toán cho nhà cung cấp chưa được phê duyệt.
NEG-NF-PO-002	Người dùng thêm một mặt hàng vào PO không có trong dữ liệu chủ về sản phẩm.	Từ chối thêm dòng, hiển thị lỗi: "Mã hàng không tồn tại."	Đảm bảo tính nhất quán dữ liệu kho và kế toán.
NEG-NF-PO-003	Tổng giá trị PO vượt quá hạn mức phê duyệt của người dùng hiện tại.	Chặn hành động "Gửi duyệt", chuyển trạng thái PO thành "Chờ phê duyệt cấp cao hơn" và gửi thông báo cho quản lý trực tiếp.	Tuân thủ chính sách kiểm soát chi tiêu nội bộ POL-NF-FIN-002.
NEG-NF-PO-004	Người dùng cố gắng nhập số lượng âm hoặc bằng không cho một mặt hàng.	Ngăn chặn nhập liệu, hiển thị lỗi: "Số lượng phải là số dương."	Bảo vệ tính toàn vẹn logic của đơn hàng.

4.3 Các giả định (Assumptions)

Các điều kiện được cho là đúng để yêu cầu này có thể thực hiện. Nếu sai, kế hoạch phải thay đổi.

ID Giả định	Nội dung Giả định	Lý do	Tác động nếu sai
ASM-NF-PO-001	Dữ liệu chủ về nhà cung cấp và sản phẩm sẽ được làm sạch, chuẩn hóa và nạp đầy đủ vào ERP trước khi module PO đi vào hoạt động (go-live).	Chức năng tìm kiếm, tạo PO và ánh xạ tài chính phụ thuộc vào dữ liệu này.	Chức năng cốt lõi thất bại. Dự án bị trì hoãn để xử lý dữ liệu.
ASM-NF-PO-002	Hệ thống tài khoản kế toán (Chart of Accounts) đã được Kế toán trưởng chốt và cấu hình trong ERP.	Các dòng trên PO cần được ánh xạ chính xác tới tài khoản chi phí hoặc tài sản tương ứng.	Phải làm lại (rework) phần tích hợp tài chính của module.
ASM-NF-PO-003	Quy trình phê duyệt PO theo cấp bậc đã được định nghĩa và ký duyệt bởi Trưởng phòng Mua hàng và Giám đốc Tài chính.	Logic luồng công việc (workflow) trong hệ thống cần tuân theo quy trình đã được thống nhất này.	Logic phê duyệt trong hệ thống sai. Rủi ro gian lận hoặc chi tiêu sai quy định.

4.4 Các mục cần xác minh (Verification-Required Items)

Các điểm yêu cầu xác nhận từ chuyên gia hoặc người có thẩm quyền để đảm bảo tuân thủ và tính chính xác.

ID Xác minh	Nội dung cần xác minh	Người/Vai trò xác minh	Nguồn tham chiếu/Tiêu chuẩn
VRF-NF-PO-001	Logic tính thuế GTGT (VAT) áp dụng cho từng loại hàng hóa và dịch vụ.	Kế toán trưởng	Nghị định 123/2020/NĐ-CP về hóa đơn, chứng từ.
VRF-NF-PO-002	Thời gian lưu trữ bắt buộc đối với chứng từ điện tử là Đơn đặt hàng.	Trưởng phòng pháp chế, Kế toán trưởng	Luật Kế toán 88/2015/QH13.
VRF-NF-PO-003	Các trường dữ liệu truy xuất nguồn gốc bắt buộc trên PO đối với nguyên liệu thực phẩm (ví dụ: số lô, ngày sản xuất).	Trưởng phòng Quản lý Chất lượng (QA/QC)	Luật An toàn thực phẩm 55/2010/QH12.
VRF-NF-PO-004	Các trường thông tin trên PO có phải là Dữ liệu Cá nhân theo định nghĩa của luật hay không (ví dụ: thông tin liên hệ của nhà cung cấp là cá nhân).	Trưởng phòng pháp chế	Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15.

4.5 Ghi nhận các vấn đề leo thang (Escalation Records)

Ghi lại các vấn đề quan trọng cần quyết định từ cấp cao hơn.

ID Leo thang	Vấn đề	Ngày leo thang	Leo thang tới	Quyết định	Ngày quyết định
ESC-NF-PO-001	Lựa chọn giữa "Tự xây dựng module PO", "Mua giải pháp bên thứ ba" và "Giữ quy trình thủ công".	2026-07-28	Ban chỉ đạo dự án ERP	Phê duyệt phương án "Tự xây dựng module PO trong ERP" để đảm bảo tích hợp dữ liệu và quy trình tối đa.	2026-08-04

Ma trận Truy vết Yêu cầu (Traceability Matrix)

Truy vết là liên kết. Từ nhu cầu nghiệp vụ, qua yêu cầu, đến thiết kế và kiểm thử. Mục đích để đảm bảo mọi thứ được xây dựng đều có lý do và được kiểm tra. Việc này giúp phân tích tác động khi có thay đổi. Đây là một kỹ thuật cốt lõi trong phân tích nghiệp vụ, được định nghĩa trong BABOK Guide là Requirement Traceability.

Ma trận dưới đây thể hiện truy vết hai chiều (tiến và lùi) cho yêu cầu REQ-PROC-001. Nó cho thấy yêu cầu này bắt nguồn từ đâu (truy vết lùi về NEED) và nó được hiện thực hóa, chi tiết hóa và kiểm thử như thế nào (truy vết tiến tới BR, AC, TC).

Bảng Ma trận Truy vết cho REQ-PROC-001

ID Gốc (Source ID)	Loại Gốc	ID Đích (Target ID)	Loại Đích	Ghi chú & Diễn giải liên kết	Trạng thái Liên kết
NEED-PURCH-001	Nhu cầu (Need)	REQ-PROC-001	Yêu cầu (Requirement)	Yêu cầu này được tạo ra để đáp ứng nhu cầu số hóa và kiểm soát quy trình mua hàng.	Derived
REQ-PROC-001	Yêu cầu (Requirement)	BR-PROC-003	Quy tắc nghiệp vụ (Business Rule)	Quy tắc này chi tiết hóa một phần của yêu cầu, xác định ngưỡng giá trị cần phê duyệt đặc biệt.	Satisfied by
REQ-PROC-001	Yêu cầu (Requirement)	BR-AUTH-005	Quy tắc nghiệp vụ (Business Rule)	Quy tắc này ràng buộc yêu cầu, chỉ cho phép chọn các nhà cung cấp đã được xác minh.	Satisfied by
REQ-PROC-001	Yêu cầu (Requirement)	AC-PROC-001.01	Tiêu chí chấp nhận (Acceptance Criterion)	Tiêu chí này kiểm chứng quyền truy cập vào chức năng được yêu cầu.	Verified by
REQ-PROC-001	Yêu cầu (Requirement)	AC-PROC-001.02	Tiêu chí chấp nhận (Acceptance Criterion)	Tiêu chí này kiểm chứng việc tuân thủ quy tắc BR-AUTH-005.	Verified by
REQ-PROC-001	Yêu cầu (Requirement)	AC-PROC-001.04	Tiêu chí chấp nhận (Acceptance Criterion)	Tiêu chí này kiểm chứng việc tuân thủ quy tắc BR-PROC-003.	Verified by
AC-PROC-001.02	Tiêu chí chấp nhận (Acceptance Criterion)	TC-FUNC-025	Ca kiểm thử (Test Case)	Ca kiểm thử TC-FUNC-025 được thiết kế để xác minh rằng tiêu chí AC-PROC-001.02 được đáp ứng.	Tested by
AC-PROC-001.04	Tiêu chí chấp nhận (Acceptance Criterion)	TC-FUNC-026	Ca kiểm thử (Test Case)	Ca kiểm thử TC-FUNC-026 được thiết kế để xác minh rằng tiêu chí AC-PROC-001.04 được đáp ứng.	Tested by
REQ-PROC-001	Yêu cầu (Requirement)	DATA-ENTITY-015	Thực thể dữ liệu (Data Entity)	Yêu cầu này ảnh hưởng và sử dụng cấu trúc dữ liệu PurchaseOrder được định nghĩa trong từ điển dữ liệu.	Impacts
REQ-PROC-001	Yêu cầu (Requirement)	API-POST-004	API Endpoint	Chức năng tạo Đơn Mua hàng được triển khai thông qua endpoint POST /api/v1/purchase-orders.	Implemented by

Ma trận hoàn chỉnh. Không có lỗ hổng truy vết. Các liên kết đến DEF (Defect - Lỗi) hoặc CR (Change Request - Yêu cầu thay đổi) hiện chưa có. Điều này bình thường vì dự án đang trong giai đoạn phân tích, chưa có sản phẩm để kiểm thử và tìm ra lỗi, cũng như chưa có yêu cầu thay đổi nào được ghi nhận. Ma trận này là một tài liệu sống, sẽ được cập nhật khi các artifact liên quan thay đổi.

Phụ lục A: Payload API và Bảng Dữ liệu cho REQ-PROC-001

Payload là khối dữ liệu chính gửi đi trong một yêu cầu API (Application Programming Interface - Giao diện Lập trình Ứng dụng). Nó chứa thông tin cần thiết để máy chủ thực hiện một hành động. Payload này định nghĩa cấu trúc dữ liệu để tạo một Đơn Mua Hàng (Purchase Order - PO) mới cho Nova Foods, hiện thực hóa yêu cầu REQ-PROC-001.

Endpoint API: POST /api/v1/purchase-orders

A.1. Ví dụ Payload API (Yêu cầu Tạo Đơn Mua Hàng)

Dữ liệu JSON sau là một ví dụ hoàn chỉnh, mô phỏng yêu cầu từ nhân viên mua hàng để tạo một đơn hàng mới từ nhà cung cấp Đà Lạt Farm.

{
  "externalReferenceId": "PO-2026-08-15-001",
  "supplierId": "SUPP-DLF-001",
  "requestedDeliveryDate": "2026-09-01",
  "currency": "VND",
  "notes": "Lô hàng ưu tiên, cần giao trước 9:00 sáng. Kiểm tra kỹ chất lượng cà rốt theo tiêu chuẩn VietGAP.",
  "items": [
    {
      "productId": "PROD-VEG-015",
      "productName": "Cà rốt Đà Lạt loại 1",
      "quantity": 500,
      "unit": "kg",
      "unitPrice": 18000
    },
    {
      "productId": "PROD-VEG-021",
      "productName": "Bắp cải tím Đà Lạt",
      "quantity": 250,
      "unit": "kg",
      "unitPrice": 15500
    }
  ],
  "requesterId": "USR-PUR-007",
  "costCenter": "CC-PROD-NORTH"
}

A.2. Bảng Mô tả Trường Dữ liệu

Bảng này giải thích từng trường trong payload để đảm bảo tính rõ ràng và là cơ sở cho việc xác thực dữ liệu đầu vào.

Trường (Field)	Kiểu Dữ liệu	Bắt buộc?	Mô tả / Quy tắc Nghiệp vụ
externalReferenceId	String	Không	Mã tham chiếu của đối tác hoặc hệ thống cũ. Hệ thống phải đảm bảo tính duy nhất nếu được cung cấp.
supplierId	String	Có	Mã định danh nhà cung cấp. Phải là một ID hợp lệ trong DATA-REF-SUPPLIER.
requestedDeliveryDate	String (Date)	Có	Ngày giao hàng mong muốn, định dạng YYYY-MM-DD. Phải là một ngày trong tương lai.
currency	String	Có	Đơn vị tiền tệ, tuân theo ISO 4217. Mặc định là VND cho các giao dịch tại Việt Nam.
notes	String	Không	Ghi chú cho nhà cung cấp hoặc bộ phận kho vận. Tối đa 500 ký tự.
items	Array[Object]	Có	Danh sách các mặt hàng cần mua. Mảng không được rỗng.
items.productId	String	Có	Mã sản phẩm. Phải là một ID hợp lệ trong DATA-REF-PRODUCT.
items.productName	String	Không	Tên sản phẩm, chỉ phục vụ mục đích hiển thị, không phải nguồn dữ liệu chính.
items.quantity	Number	Có	Số lượng đặt hàng. Phải là số dương.
items.unit	String	Có	Đơn vị tính (ví dụ: kg, thùng, tấn). Phải khớp với đơn vị chuẩn của sản phẩm.
items.unitPrice	Number	Có	Đơn giá dự kiến. Phải lớn hơn hoặc bằng 0.
requesterId	String	Có	Mã người dùng tạo yêu cầu. Phải là nhân viên có quyền mua hàng.
costCenter	String	Có	Mã trung tâm chi phí (Cost Center) chịu trách nhiệm thanh toán cho đơn hàng này.

A.3. Liên kết Truy vết (Traceability)

Payload và bảng dữ liệu này là bằng chứng kỹ thuật cụ thể hóa cho yêu cầu nghiệp vụ REQ-PROC-001. Chúng là cơ sở để xây dựng các hạng mục sau: * Đặc tả API: DATA-API-002: Create Purchase Order * Ca kiểm thử: TC-PROC-001: Tạo thành công Đơn Mua Hàng với dữ liệu hợp lệ

5. Tier 4 — Senior BA Quality Gate

Phần này định nghĩa Cổng Chất lượng (Quality Gate), một điểm kiểm soát chính thức do BA cấp cao (Senior BA) thực hiện. Mục đích là để xác minh chất lượng, tính đầy đủ và sự sẵn sàng của các yêu cầu đã được ghi nhận trong nhật ký (Requirement Elicitation Log) trước khi xem xét đưa vào baseline. Việc kiểm tra này không phải là phê duyệt nghiệp vụ mà là một bước rà soát kỹ thuật và quy trình.

Bảng dưới đây là danh sách kiểm tra chi tiết. Mỗi yêu cầu trong nhật ký phải được đánh giá theo các tiêu chí này.

Bảng 5.1: Danh sách kiểm tra chất lượng yêu cầu (Senior BA Review Checklist)

Mã kiểm tra	Hạng mục	Nội dung kiểm tra chi tiết	Tiêu chí ĐẠT (Pass)	Tiêu chí LỖI (Fail)
QG-REQ-01	Tính đầy đủ (Completeness)	Tất cả các trường siêu dữ liệu (metadata) của yêu cầu (ID, nguồn, người liên quan, độ ưu tiên) đã được điền đầy đủ.	Mọi trường bắt buộc trong template đều có giá trị.	Thiếu hoặc để trống thông tin bắt buộc.
QG-REQ-02	Tính rõ ràng (Clarity & Unambiguity)	Nội dung yêu cầu được diễn đạt rõ ràng, đơn nghĩa, không cho phép nhiều cách hiểu khác nhau.	Một người đọc (BA, Dev, QA) không có bối cảnh trước vẫn hiểu được yêu cầu.	Yêu cầu sử dụng từ ngữ mơ hồ ("nhanh", "dễ dùng", "cải thiện") mà không có định lượng cụ thể.
QG-REQ-03	Tính nhất quán (Consistency)	Yêu cầu không mâu thuẫn với các yêu cầu khác đã được ghi nhận hoặc các quy tắc nghiệp vụ đã có trong CANONICAL_BUSINESS_RULES.	Không có xung đột logic được phát hiện. Thuật ngữ tuân thủ CANONICAL_DATA_DICTIONARY.	Yêu cầu này trái ngược trực tiếp với một yêu cầu hoặc quy tắc khác.
QG-REQ-04	Tính kiểm thử được (Testability)	Yêu cầu có thể xác minh được. Có thể viết được ít nhất một tiêu chí chấp nhận (Acceptance Criterion) cụ thể từ yêu cầu này.	Yêu cầu mô tả một kết quả có thể quan sát, đo lường được. Ví dụ: "Hệ thống phải hiển thị lỗi X khi người dùng nhập Y".	Yêu cầu mô tả một cảm tính chủ quan hoặc một trạng thái không thể kiểm chứng. Ví dụ: "Hệ thống phải tạo cảm giác tin cậy".
QG-REQ-05	Khả năng truy vết (Traceability)	Yêu cầu có định danh duy nhất (REQ-ID) theo chuẩn của TRACEABILITY_ID_REGISTRY và có liên kết rõ ràng đến nguồn gốc (ví dụ: biên bản họp MEETING-LOG-XYZ, email).	REQ-ID hợp lệ và tồn tại. Có ít nhất một liên kết đến bằng chứng nguồn.	Thiếu REQ-ID hoặc ID sai định dạng. Không có tham chiếu đến nguồn.
QG-REQ-06	Thẩm quyền nguồn (Source Authority)	Người/tài liệu cung cấp yêu cầu có đủ thẩm quyền và là nguồn đáng tin cậy cho lĩnh vực nghiệp vụ đó.	Nguồn cung cấp yêu cầu là Business Owner hoặc chuyên gia được ủy quyền trong lĩnh vực đó.	Yêu cầu về kế toán đến từ bộ phận Kho, hoặc yêu cầu về pháp lý đến từ nhân viên kinh doanh.
QG-REQ-07	Ranh giới pháp lý & bảo mật	Yêu cầu có liên quan đến Dữ liệu Cá nhân (Personally Identifiable Information - PII), dữ liệu tài chính, hoặc các quy định pháp luật khác không?	Nếu có, yêu cầu được gắn cờ Verification Required: Legal/Security và chưa đưa ra giải pháp cụ thể.	Yêu cầu đề xuất xử lý PII hoặc dữ liệu nhạy cảm mà không gắn cờ cần xác minh.
QG-REQ-08	Ranh giới kế toán	Yêu cầu có ảnh hưởng đến hạch toán, báo cáo thuế, hoặc quy trình tài chính-kế toán đã được kiểm toán không?	Nếu có, yêu cầu được gắn cờ Verification Required: Accounting và chưa tự định nghĩa logic hạch toán.	Yêu cầu định nghĩa cách ghi nhận doanh thu/chi phí mà không có cờ xác minh từ bộ phận Kế toán.
QG-REQ-09	Phân tách "Cái gì" và "Như thế nào"	Yêu cầu tập trung mô tả "cái gì" (what) hệ thống cần làm, không áp đặt giải pháp kỹ thuật "như thế nào" (how).	Yêu cầu mô tả nhu cầu nghiệp vụ. Ví dụ: "Cần xem báo cáo tồn kho theo ngày".	Yêu cầu chỉ định công nghệ cụ thể. Ví dụ: "Phải dùng database X và button màu xanh".

Tiêu chí quyết định chung

Dựa trên kết quả từ bảng trên, Senior BA sẽ đưa ra một trong ba kết luận sau cho toàn bộ nhật ký yêu cầu:

1. Sẵn sàng Baseline (Baseline Ready):

   • Điều kiện: Tất cả các yêu cầu đều đạt ĐẠT (Pass) ở tất cả các hạng mục kiểm tra.
   • Hành động tiếp theo: Nhật ký yêu cầu được đề xuất để Business Owner xem xét và phê duyệt baseline.

2. Cần làm lại (Rework Required):

   • Điều kiện: Có ít nhất một yêu cầu bị LỖI (Fail) ở một hoặc nhiều hạng mục, nhưng các lỗi này nằm trong phạm vi BA có thể tự sửa chữa (ví dụ: viết lại cho rõ ràng, bổ sung ID, thêm liên kết truy vết).
   • Hành động tiếp theo: Gửi trả lại nhật ký cho người soạn thảo kèm theo ghi chú cụ thể về các điểm cần sửa.

3. Dừng và Leo thang (Stop and Escalate):

   • Điều kiện: Xảy ra một trong các trường hợp sau:
     • Phát hiện mâu thuẫn nghiêm trọng giữa các yêu cầu mà không thể hòa giải ở cấp độ BA.
     • Yêu cầu vượt quá phạm vi dự án đã thống nhất một cách đáng kể.
     • Yêu cầu liên quan đến các vấn đề pháp lý, bảo mật, hoặc kế toán phức tạp cần sự can thiệp và quyết định từ các Owner chuyên trách (Legal, Security, Accounting).
     • Các bên liên quan chính (key stakeholders) đưa ra các định hướng trái ngược nhau.
   • Hành động tiếp theo: Tạm dừng việc xử lý yêu cầu. Senior BA có trách nhiệm tổng hợp vấn đề, bằng chứng và leo thang lên Quản lý dự án (Project Manager) và/hoặc Business Owner để có quyết định.

Tiêu chí Chất lượng cho Yêu cầu

Bảng này định nghĩa các tiêu chí chất lượng cho một yêu cầu trước khi đưa vào baseline. Việc rà soát dựa trên các tiêu chí này nhằm đảm bảo yêu cầu rõ ràng, nhất quán và khả thi, không phải để thay thế thẩm quyền phê duyệt của Business Owner.

Hạng mục Kiểm tra	Mô tả & Tiêu chí "Đạt" (Pass)	Rủi ro & Cờ đỏ "Dừng/Leo thang" (Stop/Escalate)	Nguồn tham chiếu / Công cụ
Tính đầy đủ (Completeness)	Yêu cầu chứa đủ các thành phần cốt lõi: định danh (REQ-ID), mô tả, lý do nghiệp vụ (business rationale), tiêu chí chấp nhận (acceptance criteria), nguồn gốc và owner.	- Thiếu tiêu chí chấp nhận. - Lý do nghiệp vụ chỉ ghi "theo yêu cầu của A" hoặc "cần cho hệ thống". - Không có owner được chỉ định.	BABOK Guide: Requirements Attributes
Tính nhất quán (Consistency)	Yêu cầu không mâu thuẫn với các yêu cầu khác trong cùng một bộ, hoặc với các quy tắc nghiệp vụ đã được định nghĩa trong catalog chính thức (CANONICAL_BUSINESS_RULES).	- REQ-011 yêu cầu thanh toán bằng USD trong khi BR-FIN-002 quy định mọi giao dịch của Nova Foods phải bằng VND. - Hai yêu cầu định nghĩa logic tính khuyến mãi khác nhau cho cùng một sản phẩm.	/01-curriculum/CANONICAL_BUSINESS_RULES.md
Tính khả kiểm (Testability)	Tiêu chí chấp nhận phải cụ thể, đo lường được, không mơ hồ, cho phép viết một kịch bản kiểm thử (test case) để xác minh "đúng/sai" một cách khách quan.	- Tiêu chí: "Hệ thống phải chạy nhanh", "Giao diện phải thân thiện với người dùng". - Yêu cầu không thể kiểm chứng được trong môi trường kiểm thử (ví dụ: "Hệ thống phải hoạt động 100% thời gian").	ISTQB CTFL Syllabus
Khả năng truy vết (Traceability)	Yêu cầu phải có liên kết rõ ràng ngược về nguồn gốc (ví dụ: mục tiêu kinh doanh, yêu cầu từ bên liên quan, quy định pháp luật) và xuôi tới các cấu phần khác (thiết kế, mã nguồn, kịch bản kiểm thử).	- Yêu cầu không có định danh nguồn (SRC-ID). - Nguồn gốc được ghi là một cuộc trò chuyện không có biên bản. - Không thể xác định yêu cầu này hỗ trợ cho mục tiêu nghiệp vụ nào.	/01-curriculum/TRACEABILITY_ID_REGISTRY.md
Thẩm quyền nguồn (Source Authority)	Nguồn cung cấp yêu cầu phải là vai trò có thẩm quyền quyết định về mặt nghiệp vụ đối với phạm vi đó (ví dụ: Kế toán trưởng cho yêu cầu về báo cáo tài chính).	- Một Lập trình viên (Developer) yêu cầu thay đổi một quy tắc tính giá vốn hàng bán. - Yêu cầu thay đổi pháp lý đến từ bộ phận Marketing thay vì bộ phận Pháp chế.	Sơ đồ tổ chức, ma trận RACI của dự án
Quyền sở hữu (Ownership)	Mỗi yêu cầu phải có một và chỉ một Owner chịu trách nhiệm cuối cùng về nội dung và việc chấp nhận kết quả. Owner là một vai trò, không phải một nhóm.	- Owner được ghi là "Phòng Kinh doanh" hoặc "Đội dự án". - Ghi nhiều Owner cho cùng một yêu cầu, dẫn đến xung đột khi cần ra quyết định.	BABOK Guide: Stakeholder Analysis
Ranh giới (Boundaries)	Yêu cầu phải tôn trọng và tuân thủ các ranh giới về pháp lý, bảo mật, quyền riêng tư, và kế toán. Phải gắn cờ VERIFICATION_REQUIRED khi chạm đến các lĩnh vực này.	- Yêu cầu lưu trữ mật khẩu dạng văn bản thô. - Yêu cầu thu thập dữ liệu cá nhân nhạy cảm không có cơ sở pháp lý rõ ràng theo Luật Bảo vệ dữ liệu cá nhân. - Thay đổi logic ghi nhận doanh thu mà không có cờ ACCOUNTING_VERIFICATION_REQUIRED.	OWASP ASVS, OWASP API Security Top 10, các văn bản pháp luật liên quan (Luật Kế toán, Luật BV Dữ liệu cá nhân).
Tác động thay đổi (Change Impact)	Mức độ ảnh hưởng của yêu cầu lên các quy trình, hệ thống, hoặc vai trò người dùng khác phải được phân tích và ghi nhận.	- Yêu cầu thay đổi mã SKU sản phẩm nhưng không ghi nhận tác động đến hệ thống Kho, máy quét mã vạch, và cổng thông tin Nhà cung cấp. - Thay đổi một API mà không xem xét các hệ thống khác đang sử dụng API đó.	Sơ đồ kiến trúc hệ thống, sơ đồ quy trình nghiệp vụ (BPMN).

5.1 Áp dụng Quality Gate cho bản ghi Nova Foods đã hoàn tất tại Tier 3

Bản ghi được rà soát là ví dụ Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp tại Tier 3 của tệp /03-templates/TMPL-REQ-001_REQUIREMENT_ELICITATION_LOG.md. Việc rà soát diễn ra ngày 2026-08-07 theo Asia/Ho_Chi_Minh, trong trạng thái artifact IN_REVIEW, phiên bản v0.9.0. “Pass” nghĩa là bằng chứng trong bản ghi đủ để kiểm tra; “Fail” nghĩa là có điểm không đạt nhưng có thể sửa rõ ràng; “Stop” nghĩa là không được đưa bản ghi vào baseline vì thiếu xác minh thuộc thẩm quyền chuyên môn. Kết quả review không phải là phê duyệt.

Hạng mục quality gate	Bằng chứng đọc từ bản ghi Tier 3	Lập luận kiểm tra	Kết quả	Finding và hành động bắt buộc
Đầy đủ (completeness)	Bản ghi có vấn đề nghiệp vụ, yêu cầu, quy tắc, ngoại lệ, tiêu chí chấp nhận, stakeholder, nguồn và liên kết truy vết.	Một requirement chỉ có thể được bàn giao cho thiết kế và kiểm thử nếu trả lời được “ai cần gì, trong điều kiện nào, hệ thống phải làm gì và không làm gì”. Các trường cốt lõi đã hiện diện.	Pass có điều kiện	Cần giữ nguyên tất cả trường bắt buộc khi sửa các finding bên dưới; không được rút gọn thành mô tả tự do.
Nhất quán (consistency)	Luồng yêu cầu, ngoại lệ và tiêu chí chấp nhận cùng mô tả một kết quả nghiệp vụ; đơn vị tiền tệ sử dụng là VND; ngữ cảnh là Việt Nam, vi-VN.	Kiểm tra chéo không phát hiện mâu thuẫn nội bộ giữa kết quả mong đợi và điều kiện ngoại lệ. Tuy nhiên, tính nhất quán nội bộ không xác nhận rằng quy tắc phù hợp vận hành thực tế.	Pass có điều kiện	Mọi thay đổi thuật ngữ, trạng thái hoặc dữ liệu phải được cập nhật đồng thời tại requirement, acceptance criteria và traceability link.
Khả năng kiểm thử (testability)	Tiêu chí chấp nhận nêu điều kiện đầu vào, hành vi hệ thống mong đợi và kết quả quan sát được cho luồng chính và ngoại lệ.	Kiểm thử hộp đen (black-box testing) kiểm tra hành vi từ đầu vào đến đầu ra mà không cần biết mã nguồn. Tiêu chí có thể chuyển thành test case vì có kết quả quan sát được.	Pass	QA chỉ được tạo test case từ các tiêu chí hiện có; không tự suy diễn ngưỡng nghiệp vụ, quyền truy cập hoặc nghĩa vụ pháp lý chưa được xác minh.
Truy vết (traceability)	Bản ghi liên kết tới nguồn ghi nhận, stakeholder, quy tắc nghiệp vụ và tiêu chí chấp nhận trong chính template.	Chuỗi truy vết tối thiểu phải cho phép đi từ nhu cầu đến requirement rồi đến cách kiểm tra. Chuỗi này tồn tại ở mức template.	Fail	Liên kết tới nguồn canonical chưa thể hiện tham chiếu xác định đến /01-curriculum/CANONICAL_BUSINESS_RULES.md hoặc /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Senior BA phải bổ sung liên kết khi các catalog đó có nội dung tương ứng; không được tự tạo rule canonical trong log.
Thẩm quyền nguồn (source authority)	Nguồn của ví dụ là workshop/phỏng vấn mô phỏng và dữ liệu tổng hợp Nova Foods. Các nguồn pháp lý và chuẩn chỉ được liệt kê như ranh giới tham khảo.	Nguồn mô phỏng phù hợp cho mục tiêu đào tạo nhưng không thể chứng minh quyết định vận hành, diễn giải pháp lý hoặc nghĩa vụ kế toán. Do đó, requirement có thể được học và review, nhưng không thể được xem là xác thực cho production.	Stop	Giữ nhãn SIMULATED và VERIFICATION_REQUIRED. Nếu nội dung được dùng ngoài học liệu, Business Owner phải xác nhận nhu cầu; Legal Owner, Accounting Owner hoặc Compliance Owner phải xác minh phần thuộc thẩm quyền của mình.
Ownership	Bản ghi phân biệt người yêu cầu nghiệp vụ, người làm rõ, người thực hiện review và các vai trò cần xác minh.	Ownership là một cá nhân hoặc vai trò có quyền quyết định rõ ràng, không phải tên phòng ban chung chung. Bản ghi có phân vai cho hoạt động elicitation nhưng chưa tạo bằng chứng quyết định nghiệp vụ có thẩm quyền.	Fail	Senior BA phải yêu cầu Business Owner được chỉ định xác nhận phạm vi quyết định nghiệp vụ. Không được ghi nhận “đã xác nhận” hoặc thay thế quyết định đó bằng ý kiến của BA.
Bảo mật và quyền riêng tư	Bản ghi có tác động tới dữ liệu giao dịch và thông tin người dùng; không ghi mật khẩu, mã bí mật hoặc dữ liệu cá nhân thô trong log.	Không lưu dữ liệu nhạy cảm trong requirement log là kiểm soát tối thiểu. Tuy nhiên, yêu cầu có dữ liệu cá nhân hoặc phân quyền cần cơ sở xử lý, mục đích, thời hạn lưu trữ và quyền truy cập được chuyên gia xác minh.	Stop	Gắn SECURITY_VERIFICATION_REQUIRED và PRIVACY_VERIFICATION_REQUIRED. Security Owner đánh giá kiểm soát truy cập; Legal/Privacy Owner xác minh việc áp dụng Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15 và Nghị định 356/2025/NĐ-CP. Không diễn giải các nguồn này thành kết luận tuân thủ.
Ranh giới pháp lý, kế toán và an toàn thực phẩm	Bản ghi chạm đến giao dịch ERP có thể ảnh hưởng chứng từ, doanh thu, tồn kho hoặc truy xuất lô hàng.	Các ảnh hưởng này vượt thẩm quyền của Senior BA vì cần diễn giải luật và chính sách doanh nghiệp. Luật Kế toán 88/2015/QH13, Nghị định 123/2020/NĐ-CP và Luật An toàn thực phẩm 55/2010/QH12 là nguồn tham chiếu chính thức, nhưng nội dung áp dụng cụ thể chưa được xác minh trong case mô phỏng.	Stop	Gắn ACCOUNTING_VERIFICATION_REQUIRED, LEGAL_VERIFICATION_REQUIRED và FOOD_SAFETY_VERIFICATION_REQUIRED khi requirement tác động chứng từ, ghi nhận kế toán hoặc truy xuất thực phẩm. Escalate tới Accounting Owner, Legal Owner và Food Safety Domain Owner; chỉ các vai trò này được kết luận phạm vi áp dụng.
Tác động thay đổi (change impact)	Bản ghi nhận diện tác động tới quy trình bán hàng, kho, dữ liệu sản phẩm và các tích hợp ERP liên quan.	Một thay đổi ERP không chỉ ảnh hưởng màn hình nhập liệu; nó có thể làm thay đổi dữ liệu dùng chung, quyền truy cập, API và kiểm thử hồi quy. Bản ghi đã nhận diện vùng tác động nhưng chưa có xác nhận kiến trúc.	Fail	Architect phải đánh giá interface, dữ liệu dùng chung, khả năng tương thích ngược và phạm vi regression test. Không được coi danh sách tác động trong log là quyết định kiến trúc.

Kết luận review: bản ghi Tier 3 đủ làm ví dụ học tập và đủ đầu vào để tiếp tục làm rõ, nhưng kết quả tổng hợp là STOP — VERIFICATION AND OWNERSHIP ESCALATION REQUIRED. Căn cứ dừng là ba nhóm ranh giới chưa có xác minh có thẩm quyền: nguồn nghiệp vụ thực tế, bảo mật/quyền riêng tư, và kế toán/pháp lý/an toàn thực phẩm. Trạng thái này không phủ định chất lượng cấu trúc của ví dụ mô phỏng; nó ngăn việc diễn giải dữ liệu tổng hợp thành requirement đã được baseline, đã được phê duyệt, tuân thủ pháp luật hoặc sẵn sàng triển khai production.

6. Cross-File Checks, Open Issues, and Escalation

6.1. Ma trận kiểm tra mâu thuẫn liên tệp

Kiểm tra liên tệp (cross-file check) là đối chiếu một bản ghi elicitation với các nguồn kiểm soát khác để phát hiện cùng một khái niệm nhưng có ID, trạng thái, phạm vi hoặc ý nghĩa khác nhau. Việc đối chiếu này cần thiết vì Requirement Elicitation Log chỉ ghi nhận thông tin được khai thác và lập luận ban đầu; log không phải nguồn có thẩm quyền thay thế manifest, registry định danh, catalog quy tắc hay từ điển dữ liệu. Case Nova Foods Trading & Manufacturing là mô phỏng giáo dục và toàn bộ dữ liệu trong bảng dưới đây là dữ liệu tổng hợp.

Nhóm kiểm tra	Artifact/source canonical cần đối chiếu	Tiêu chí đối chiếu cụ thể	Kết quả áp dụng cho TMPL-REQ-001	Kết luận kiểm soát
Manifest template	/01-curriculum/TEMPLATE_MANIFEST.md	ID template, tên tệp, phạm vi template, trạng thái, phiên bản và ranh giới thẩm quyền phải trùng khớp.	Template được nhận diện là TMPL-REQ-001 tại /03-templates/TMPL-REQ-001_REQUIREMENT_ELICITATION_LOG.md; trạng thái phải giữ IN_REVIEW, phiên bản phải giữ v0.9.0.	Không được đổi tên tệp, đổi ID hoặc diễn giải nội dung đã review thành baseline hay approval.
Manifest chapter	/01-curriculum/CHAPTER_MANIFEST.md	Template chỉ hỗ trợ chuỗi học về khai thác requirement, truy vết và test basis; không được tự trở thành chapter quy định vận hành ERP.	Nội dung log ghi nhận nhu cầu, bằng chứng, câu hỏi và giả định của Nova Foods mô phỏng; không tạo business rule vận hành có hiệu lực.	Phù hợp ranh giới curriculum nếu mọi kết luận nghiệp vụ tiếp tục được gắn nguồn và trạng thái xác minh.
Registry định danh	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Mỗi ID phải đúng loại, duy nhất, giữ nguyên tiền tố và không dùng ID để giả định thẩm quyền phê duyệt.	TMPL-REQ-001 là ID template; các ID requirement, rule, data, interface, risk hoặc test chỉ được tham chiếu theo dạng đã đăng ký trong registry.	Không tạo biến thể như REQ-001-NF, NF-REQ-001 hoặc dùng ID template thay cho ID requirement.
Quy tắc nghiệp vụ canonical	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Log có thể ghi nhận phát biểu về quy tắc, nhưng không được biến phát biểu đó thành quy tắc canonical nếu chưa có catalog, nguồn và owner phù hợp.	Một ý kiến như “chỉ xuất kho khi đơn hàng hợp lệ” trong Tier 3 chỉ là nội dung elicitation mô phỏng cho đến khi được đối chiếu với rule ID canonical và nguồn chứng cứ.	Không gọi phát biểu trong log là business rule đã xác nhận, đã phê duyệt hoặc bắt buộc cho production.
Từ điển dữ liệu canonical	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tên thực thể, thuộc tính, định dạng, đơn vị đo, mã trạng thái và ý nghĩa dữ liệu phải không mâu thuẫn với định nghĩa logic canonical.	Các thuật ngữ như khách hàng, đơn hàng bán, lô hàng, tồn kho và sản phẩm chỉ được dùng theo nghĩa mô tả trong log; không được tự suy ra tên bảng vật lý, API field hoặc cấu hình ERP.	Nếu cùng một dữ liệu có hai tên hoặc hai định nghĩa, từ điển dữ liệu canonical là điểm đối chiếu bắt buộc; log phải giữ liên kết truy vết thay vì tự chọn nghĩa.
Bản đồ nguồn	/00-research/00_SOURCE_MAP.md	Phân loại nguồn phải đúng: tiêu chuẩn, đặc tả, nguồn pháp lý hoặc good practice không được biến thành bằng chứng rằng Nova Foods tuân thủ.	BABOK Guide hỗ trợ thuật ngữ BA; ISO/IEC/IEEE 29148 hỗ trợ bối cảnh requirements; nguồn pháp lý Việt Nam chỉ là nguồn tham chiếu cần xác minh phạm vi áp dụng.	Không ghi nhận yêu cầu pháp lý, kế toán, hóa đơn, quyền riêng tư hoặc an toàn thực phẩm như kết luận đã được xác nhận nếu chưa có vai trò có thẩm quyền xác minh.
Downstream consumer	Các artifact tiếp nhận như đặc tả requirement, acceptance criteria, traceability matrix và test basis theo kiến trúc curriculum	Đầu ra từ log phải giữ nguyên ID, phân loại nguồn, mức độ tin cậy và nhãn Verification required khi chuyển tiếp.	Downstream consumer chỉ được dùng bản ghi elicitation làm đầu vào phân tích; không được tự nâng câu trả lời phỏng vấn mô phỏng thành acceptance criterion, test case pass condition hoặc quyết định kiến trúc.	Chuỗi truy vết phải thể hiện “evidence hoặc elicitation note → phân tích → requirement/rule/data definition → kiểm thử”, không được bỏ qua bước phân tích và xác minh.

6.2. Quy tắc phát hiện mâu thuẫn

Một mâu thuẫn được ghi nhận khi cùng một ID có hai ý nghĩa, một tên nghiệp vụ có hai định nghĩa dữ liệu, một câu phát biểu vừa bị gắn là giả định vừa bị dùng như requirement đã xác nhận, hoặc trạng thái IN_REVIEW bị diễn giải thành APPROVED hay BASELINED. Lý do là ID xác định đối tượng cần truy vết, còn trạng thái xác định mức độ kiểm soát; hai thông tin này không thay thế cho nhau. Ví dụ, TMPL-REQ-001 xác định template nhưng không chứng minh bất kỳ requirement Nova Foods nào đã được Business Owner, Legal Owner, Accounting Owner, Architect, Security Owner hoặc QA phê chuẩn.

Khi phát hiện khác biệt giữa log và nguồn canonical, thứ tự đối chiếu là: manifest kiểm soát đường dẫn, phạm vi và trạng thái artifact; registry kiểm soát loại và cấu trúc ID; catalog quy tắc kiểm soát quy tắc nghiệp vụ; từ điển dữ liệu kiểm soát nghĩa dữ liệu; và source map kiểm soát cách sử dụng nguồn. Requirement Elicitation Log phải giữ lại nguyên văn ý nghĩa của bằng chứng mô phỏng và liên kết đến nguồn kiểm soát tương ứng, thay vì tự sửa ý nghĩa để tạo cảm giác nhất quán giả tạo.

6.3. Sổ đăng ký vấn đề mở, giả định dự án và hạng mục cần xác minh

Vấn đề mở (open issue) là điểm chưa thể kết luận vì thiếu quyết định hoặc bằng chứng có thẩm quyền; giả định dự án (project assumption) là điều tạm dùng để mô phỏng luồng học liệu nhưng không được nâng thành quy tắc vận hành; cần xác minh (verification required) là phát biểu phải được vai trò chuyên môn đối chiếu nguồn hiện hành trước khi sử dụng. Bảng dưới đây là danh sách đầy đủ trong phạm vi TMPL-REQ-001 tại v0.9.0, trạng thái IN_REVIEW, cho Nova Foods Trading & Manufacturing là case mô phỏng giáo dục với dữ liệu tổng hợp. Cơ sở ghi nhận là các artifact nguồn đều nêu rõ chưa có baseline hoặc approval; vì vậy không mục nào được diễn giải là quyết định ERP thực tế.

Mã theo dõi	Phân loại	Nội dung và cầu nối bằng chứng/suy luận	ID và artifact bị ảnh hưởng	Owner chịu trách nhiệm xử lý	Tác động nếu chưa xử lý	Hành động kế tiếp cụ thể
OI-REQ-001	Vấn đề mở	Chưa có bằng chứng rằng Business Owner đã xác nhận nội dung requirement được ghi trong log. Suy luận: CHAPTER_MANIFEST, TEMPLATE_MANIFEST và TRACEABILITY_ID_REGISTRY đều ghi IN_REVIEW không phải approval.	TMPL-REQ-001; CHAPTER_MANIFEST; TEMPLATE_MANIFEST; TRACEABILITY_ID_REGISTRY	Business Owner của case mô phỏng Nova Foods	Requirement có thể bị người học hiểu sai là nhu cầu nghiệp vụ đã được chấp thuận.	Business Owner mô phỏng xem xét từng bản ghi Tier 3, ghi kết luận xác nhận, từ chối hoặc yêu cầu làm rõ trong evidence của log; Principal IT Business Analyst chỉ cập nhật truy vết kết quả.
OI-REQ-002	Vấn đề mở	Chưa xác định bộ requirement Nova Foods nào đủ điều kiện làm test basis, tức cơ sở để QA thiết kế kiểm thử. Suy luận: curriculum architecture yêu cầu chuỗi requirement, acceptance criteria, traceability đến testing nhưng không cho phép testing tự suy diễn quy tắc.	TMPL-REQ-001; 01_CURRICULUM_ARCHITECTURE; CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY	QA Reviewer và Business Owner mô phỏng	Test case có thể kiểm tra một diễn giải không có nguồn requirement hoặc tiêu chí chấp nhận tương ứng.	QA Reviewer lập danh sách requirement có liên kết evidence, rule, data field và acceptance criteria; các bản ghi thiếu một liên kết phải giữ nhãn IN_REVIEW, không dùng làm test basis.
ASM-REQ-001	Giả định dự án	Nova Foods Trading & Manufacturing chỉ là tổ chức mô phỏng; mọi tên quy trình, vai trò, mã và giá trị VND là dữ liệu tổng hợp. Bằng chứng: metadata của manifest và registry cùng giới hạn case study cho mục đích giáo dục.	TMPL-REQ-001; CHAPTER_MANIFEST; TEMPLATE_MANIFEST; TRACEABILITY_ID_REGISTRY	Principal IT Business Analyst / Technical Curriculum Author	Nếu bỏ nhãn, người đọc có thể nhầm ví dụ thành cấu hình hoặc dữ liệu doanh nghiệp thật.	Giữ nhãn “mô phỏng giáo dục, dữ liệu tổng hợp” tại mọi bản ghi Tier 3 có nhắc Nova Foods; không thay nhãn này bằng tuyên bố triển khai, tuân thủ hoặc vận hành thực tế.
ASM-REQ-002	Giả định dự án	Các trường ngày tháng dùng Asia/Ho_Chi_Minh, ngôn ngữ vi-VN và tiền tệ VND chỉ là quy ước nhất quán cho case. Suy luận: đây là locale được metadata corpus quy định, không phải quyết định cấu hình ERP production.	TMPL-REQ-001; 01_CURRICULUM_ARCHITECTURE; TEMPLATE_MANIFEST	Principal IT Business Analyst / Technical Curriculum Author	Có nguy cơ suy diễn sai định dạng, múi giờ hoặc tiền tệ mô phỏng thành yêu cầu kỹ thuật đã xác nhận.	Ghi rõ locale tại bản ghi có dữ liệu thời gian hoặc giá trị tiền; Architect chỉ xác định cấu hình kỹ thuật khi có đầu vào được thẩm quyền phù hợp xác nhận.
VR-REQ-001	Cần xác minh	Các yêu cầu liên quan dữ liệu cá nhân chưa được Legal Owner đối chiếu Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP hiện hành. Bằng chứng: source seed quy định mọi requirement suy ra từ nguồn này phải có xác minh của legal owner.	TMPL-REQ-001; 00_SOURCE_MAP; CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY	Legal Owner	Gắn nhãn pháp lý hoặc thiết kế thu thập, lưu trữ, truy cập dữ liệu cá nhân thiếu căn cứ chuyên môn.	Legal Owner xác minh từng phát biểu pháp lý, phạm vi dữ liệu và điều kiện áp dụng; kết quả phải liên kết URL nguồn chính thức và không được gán số điều, khoản khi chưa kiểm tra văn bản được cấp phép.
VR-REQ-002	Cần xác minh	Các requirement về hóa đơn, chứng từ, thuế và hạch toán chưa có kết luận của Accounting Owner hoặc Legal Owner. Bằng chứng: source seed giới hạn Luật Kế toán và Nghị định 123/2020/NĐ-CP cho mục đích tham chiếu, đồng thời yêu cầu kiểm tra sửa đổi trước khi dùng production.	TMPL-REQ-001; 00_SOURCE_MAP; CANONICAL_BUSINESS_RULES	Accounting Owner, phối hợp Legal Owner	Một ví dụ ERP có thể bị hiểu nhầm là quy tắc hạch toán, thuế hoặc hóa đơn bắt buộc.	Accounting Owner phân loại từng phát biểu là ví dụ học liệu hoặc requirement cần xác minh; Legal Owner kiểm tra hiệu lực pháp lý; log chỉ cập nhật trạng thái bằng chứng, không tự kết luận nghĩa vụ.
VR-REQ-003	Cần xác minh	Các yêu cầu truy xuất nguồn gốc, thu hồi và an toàn thực phẩm chưa được Food Safety Domain Owner và Legal Owner xác minh. Bằng chứng: source seed nêu Luật An toàn thực phẩm chỉ cung cấp bối cảnh và yêu cầu xác minh theo chuyên môn lĩnh vực/pháp lý.	TMPL-REQ-001; 00_SOURCE_MAP; CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY	Food Safety Domain Owner, phối hợp Legal Owner	Sai phạm vi dữ liệu lô hàng, sự kiện truy vết hoặc quy trình thu hồi trong ví dụ Nova Foods.	Food Safety Domain Owner xác định dữ liệu nghiệp vụ tối thiểu cho case mô phỏng; Legal Owner kiểm tra phát biểu có hàm ý nghĩa vụ pháp lý; các nội dung chưa xác minh giữ nhãn Verification required.
VR-REQ-004	Cần xác minh	Các kiểm soát API, phân quyền và bảo mật chỉ mới có nguồn tham chiếu OWASP; chưa có quyết định kiến trúc hoặc xác nhận Security Owner. Suy luận: OWASP ASVS và OWASP API Security Top 10 là chuẩn/good practice ngành, không phải luật Việt Nam và không tự tạo cấu hình bắt buộc.	TMPL-REQ-001; 00_SOURCE_MAP; CANONICAL_DATA_DICTIONARY	Security Owner và Solution Architect	Có thể biến khuyến nghị bảo mật thành yêu cầu kỹ thuật tuyệt đối hoặc thiết kế sai cơ chế kiểm soát.	Security Owner đánh giá rủi ro mô phỏng; Solution Architect xác định tính khả thi kiến trúc; requirement chỉ được liên kết tới kiểm soát cụ thể sau khi hai vai trò ghi nhận kết luận riêng.
VR-REQ-005	Cần xác minh	Thuật ngữ, ký pháp và tiêu chí kiểm thử tham chiếu BABOK, BPMN, UML, ISTQB, OpenAPI hoặc WCAG cần được dùng đúng ranh giới nguồn. Bằng chứng: source seed phân biệt rõ nguồn chuẩn, phạm vi sử dụng và cấm gọi sơ đồ hoạt động PlantUML là BPMN.	TMPL-REQ-001; 00_SOURCE_MAP; 01_CURRICULUM_ARCHITECTURE	Principal IT Business Analyst / Technical Curriculum Author, phối hợp QA Reviewer và Solution Architect khi áp dụng	Sai thuật ngữ làm đứt liên kết giữa requirement, mô hình, API description và kiểm thử.	Đối chiếu mỗi tham chiếu với URL nguồn chính thức, ghi loại nguồn và mục đích sử dụng; không tạo trích dẫn, số trang, điều khoản hoặc tuyên bố tuân thủ khi chưa được xác minh.

Quy tắc bàn giao cuối và lan truyền thay đổi có kiểm soát

Bàn giao có kiểm soát là việc chuyển một gói thông tin đủ ngữ cảnh cho vai trò hoặc artifact nhận xử lý, đồng thời không làm thay đổi thẩm quyền quyết định. Với /03-templates/TMPL-REQ-001_REQUIREMENT_ELICITATION_LOG.md, bàn giao chỉ xác nhận rằng nội dung được chuyển để xem xét tiếp; không xác nhận yêu cầu đúng, không tạo baseline và không được hiểu là phê duyệt của người dùng. Căn cứ là toàn bộ artifact quản trị nguồn đều ở IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, theo Asia/Ho_Chi_Minh; do đó mọi nội dung Nova Foods Trading & Manufacturing vẫn là mô phỏng giáo dục với dữ liệu tổng hợp.

Thành phần gói bàn giao	Nội dung phải giữ nguyên	Vai trò nhận hoặc sử dụng	Giới hạn sử dụng
Artifact nguồn	/03-templates/TMPL-REQ-001_REQUIREMENT_ELICITATION_LOG.md; TMPL-REQ-001; IN_REVIEW; v0.9.0	Principal IT Business Analyst / Technical Curriculum Author điều phối review	Không đổi tên tệp, ID, status hoặc version chỉ để thuận tiện khi sao chép.
Liên kết quản trị	/01-curriculum/TEMPLATE_MANIFEST.md; TEMPLATE_MANIFEST	Người duy trì manifest template	Dùng để đối chiếu vị trí và phạm vi template, không phải nguồn phê duyệt requirement.
Liên kết định danh	/01-curriculum/TRACEABILITY_ID_REGISTRY.md; TRACEABILITY_ID_REGISTRY	Người quản trị traceability	Chỉ registry quyết định quy tắc định danh canonical; template không tự cấp ID mới.
Liên kết quy tắc và dữ liệu	/01-curriculum/CANONICAL_BUSINESS_RULES.md; CANONICAL_BUSINESS_RULES; /01-curriculum/CANONICAL_DATA_DICTIONARY.md; CANONICAL_DATA_DICTIONARY	Business Owner, Architect, Accounting Owner, Legal Owner, Security hoặc QA theo nội dung ảnh hưởng	Template chỉ ghi nhận nguồn, giả định, câu hỏi và liên kết; không tự kết luận quy tắc nghiệp vụ, cấu trúc dữ liệu hay nghĩa vụ pháp lý.
Bối cảnh nguồn	/00-research/00_SOURCE_MAP.md; 00_SOURCE_MAP	Người review nguồn và tác giả curriculum	Chỉ dùng nguồn theo safe use boundary; không suy diễn điều khoản pháp lý, kế toán hoặc tuân thủ chưa được chủ thể có thẩm quyền xác minh.

Khi một thay đổi được đề xuất, người ghi nhận phải bảo toàn traceability (khả năng lần theo quan hệ từ thay đổi đến nguồn, requirement, rule, dữ liệu và đầu ra bị ảnh hưởng). Đề xuất phải nêu rõ nội dung trước và sau thay đổi, lý do, bằng chứng đang có, ID bị ảnh hưởng, artifact bị ảnh hưởng, vai trò cần xem xét và trạng thái xác minh. Lý do “để đồng bộ” không đủ để sửa nội dung canonical, vì đồng bộ hình thức không chứng minh rằng ý nghĩa nghiệp vụ, pháp lý, kế toán, bảo mật hoặc kiến trúc vẫn đúng.

Loại thay đổi	Hành động lan truyền bắt buộc	Người có thể thực hiện	Người phải kết luận nội dung
Sửa câu hỏi khai thác, nguồn bằng chứng hoặc diễn đạt hướng dẫn trong TMPL-REQ-001	Cập nhật liên kết traceability và lịch sử thay đổi của artifact khi thay đổi có ý nghĩa; giữ IN_REVIEW.	Principal IT Business Analyst / Technical Curriculum Author	Reviewer được phân công cho chất lượng học liệu; không tạo approval nghiệp vụ.
Đề xuất ID mới, đổi ID hoặc thay quan hệ ID	Chuyển đề xuất đến TRACEABILITY_ID_REGISTRY; không tự dùng biến thể ID trong template.	Principal IT Business Analyst / Technical Curriculum Author lập gói thay đổi	Vai trò quản trị registry theo cơ chế của TRACEABILITY_ID_REGISTRY.
Đề xuất sửa business rule hoặc data element	Gắn liên kết đến CANONICAL_BUSINESS_RULES hoặc CANONICAL_DATA_DICTIONARY; dừng việc diễn đạt thay đổi như sự thật vận hành.	BA ghi nhận bằng chứng và tác động	Business Owner, Architect, Accounting Owner, Legal Owner, Security hoặc QA tùy bản chất thay đổi.
Thay đổi có nội dung thuế, kế toán, dữ liệu cá nhân, hóa đơn, an toàn thực phẩm hoặc truy xuất nguồn gốc	Giữ nhãn Verification required; nêu nguồn chính thức cần kiểm tra; không chuyển nhãn này thành yêu cầu bắt buộc trong template.	BA điều phối và bảo toàn liên kết nguồn	Legal Owner, Accounting Owner, Compliance Owner hoặc domain owner có thẩm quyền.
Thay đổi ảnh hưởng thiết kế kỹ thuật, API, phân quyền hoặc kiểm thử	Chuyển tác động đã mô tả sang artifact nhận phù hợp; không tự suy ra cấu hình ERP, API hay test result.	BA chuẩn bị gói tác động	Architect, Security và QA theo phạm vi chuyên môn.

Quy tắc lan truyền là thay đổi chỉ đi từ nguồn có thẩm quyền sang artifact phụ thuộc sau khi nguồn đó ghi nhận quyết định hoặc trạng thái xác minh phù hợp. Artifact phụ thuộc không được “đẩy ngược” một diễn giải thành quy tắc canonical chỉ vì diễn giải đã xuất hiện trong template. Ví dụ, nếu một mục elicitation đề cập thời hạn lưu chứng từ mô phỏng, mục đó phải tiếp tục là giả định dự án hoặc Verification required cho đến khi Accounting Owner hoặc Legal Owner xác minh theo nguồn chính thức hiện hành; Principal IT Business Analyst / Technical Curriculum Author chỉ cập nhật liên kết và lịch sử thay đổi, không tự kết luận thời hạn.

Mọi bàn giao cuối của template phải kèm câu trạng thái sau: “Gói bàn giao thuộc Nova Foods Trading & Manufacturing — mô phỏng giáo dục, 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. Gói này không phải baseline, không phải approval, không phải xác nhận tuân thủ và không cho phép sử dụng production.” Chỉ khi một artifact kiểm soát ghi nhận minh bạch tham chiếu baseline hoặc approval bởi đúng vai trò có thẩm quyền thì mới được sử dụng các thuật ngữ “đã baseline” hoặc “đã phê duyệt”; cho đến thời điểm đó, mọi bên nhận phải giữ nguyên ranh giới thẩm quyền này.