/03-templates/TMPL-DISC-001_DISCOVERY_AND_BUSINESS_NEED_CAPTURE.md — Template: Ghi nhận Khai phá và Nhu cầu Nghiệp vụ

1. Tier 1 ? Metadata, Purpose, and Governance

Phần này xác định định danh, lịch sử, quyền sở hữu, trạng thái và quy tắc quản trị của template. Tuân thủ metadata bắt buộc để giữ nhất quán và truy vết nguồn gốc trong corpus học liệu Nova Foods.

Metadata Quản trị Artifact

Bảng này là nguồn chân lý cho thuộc tính quản trị artifact. Mọi tham chiếu, sao chép, cập nhật và kiểm tra phải khớp các giá trị này.

Trường kiểm soát	Giá trị / Diễn giải
Artifact ID	TMPL-DISC-001
Tên tệp được kiểm soát	/03-templates/TMPL-DISC-001_DISCOVERY_AND_BUSINESS_NEED_CAPTURE.md
Tiêu đề Artifact	Template: Ghi nhận Khai phá và Nhu cầu Nghiệp vụ (Discovery and Business Need Capture)
Trạng thái (Status)	IN_REVIEW (Đang trong quá trình xem xét). Trạng thái này không phải BASELINED, không phải phê duyệt, không tạo quyền dùng nội dung làm yêu cầu cuối cùng.
Phiên bản (Version)	v0.9.0
Ngày cập nhật gần nhất	2026-08-07
Múi giờ quản trị	Asia/Ho_Chi_Minh
Owner Artifact	Principal IT Business Analyst / Technical Curriculum Author
Thẩm quyền Owner Artifact	Duy trì cấu trúc template, tính toàn vẹn metadata, phiên bản, lịch sử thay đổi và liên kết corpus. Owner Artifact không tự phê duyệt nhu cầu, phạm vi, ngân sách, giải pháp kỹ thuật, hoặc nội dung nghiệp vụ được điền trong từng bản ghi dùng template.
Tác giả bản ghi sử dụng template	Business Analyst (BA) điền bản ghi discovery cụ thể, thu thập bằng chứng, gán định danh và duy trì truy vết nội dung. BA không có thẩm quyền phê duyệt phạm vi, ngân sách hay quyết định kiến trúc.
Phân loại Artifact	Biểu mẫu có kiểm soát (Controlled Template) cho hoạt động phân tích nghiệp vụ.
Mục đích kiểm soát	Ghi nhận metadata, nhu cầu nghiệp vụ ban đầu, vấn đề, mục tiêu, phạm vi, bên liên quan, giả định, ràng buộc, rủi ro và vấn đề mở theo cấu trúc thống nhất.
Bối cảnh áp dụng	Locale: vi-VN / Khu vực pháp lý: Việt Nam / Đơn vị tiền tệ mô phỏng: VND
Nguồn quản trị phiên bản và trạng thái	/01-curriculum/TEMPLATE_MANIFEST.md là nguồn đăng ký phiên bản và trạng thái template trong corpus.
Nguồn quản trị định danh truy vết	/01-curriculum/TRACEABILITY_ID_REGISTRY.md quản lý định danh dùng cho truy vết.
Tham chiếu Baseline	Chưa có tham chiếu baseline tại phiên bản v0.9.0. Trạng thái IN_REVIEW không được hiểu là BASELINED.
Tham chiếu Phê duyệt	Chưa có tham chiếu phê duyệt (approval reference) được ghi nhận.
Phạm vi cập nhật được phép	Cập nhật cấu trúc Tier 1 và Tier 2 phải qua kiểm soát thay đổi. Nội dung Tier 3 và Tier 4 phải được đánh giá tác động khi cấu trúc template thay đổi.
Bằng chứng cập nhật bắt buộc	Mỗi thay đổi phải có phiên bản, ngày cập nhật, mô tả thay đổi, tác động tới artifact phụ thuộc và cập nhật manifest khi thay đổi được chấp nhận theo quy trình kiểm soát thay đổi.

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

• v0.9.0 (2026-08-07): Khởi tạo template tại trạng thái IN_REVIEW. Thiết lập metadata quản trị ban đầu, xác định cấu trúc 4 cấp (Tier) và mục đích sử dụng trong khuôn khổ case study mô phỏng Nova Foods.

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

CẢNH BÁO QUAN TRỌNG: Template dùng trong môi trường học tập.

• Case study Nova Foods: Mọi thông tin về "Nova Foods Trading & Manufacturing", gồm tên nhân viên, chức danh, quy trình, dữ liệu tài chính và yêu cầu nghiệp vụ, là dữ liệu tổng hợp (synthetic data), hoàn toàn hư cấu.
• Không phải dữ liệu thực: Ví dụ đã điền tại Tier 3 không đại diện cho tổ chức, cá nhân hoặc hoạt động kinh doanh có thật.
• Mục đích giáo dục: Dữ liệu mô phỏng chỉ minh họa cách điền và dùng template chuyên nghiệp. Không phải tư vấn pháp lý, kế toán hoặc vận hành.
• Hệ quả sử dụng: Người dùng không được suy diễn, chuyển đổi hoặc dùng dữ liệu mô phỏng cho production hay quyết định kinh doanh thực tế. Khi dùng template cho bối cảnh thực, BA phải thay dữ liệu mô phỏng bằng bằng chứng hợp lệ của tổ chức và tuân theo thẩm quyền, chính sách, luật cùng quy trình phê duyệt áp dụng.

Mục đích, Phạm vi sử dụng và Vai trò liên quan

Template ghi nhận có cấu trúc kết quả khảo sát và khai phá nhu cầu ban đầu (Discovery and Business Need Capture). BA chuyển trao đổi, phỏng vấn sơ bộ và bằng chứng hiện có từ stakeholder thành bản ghi kiểm soát.

Artifact tạo nguồn tham chiếu ban đầu cho:

• Vấn đề nghiệp vụ cần giải quyết.
• Mục tiêu nghiệp vụ cần đạt.
• Phạm vi cấp cao.
• Bên liên quan, giả định, ràng buộc và rủi ro ban đầu.
• Nguồn đầu vào cho phân tích và định nghĩa yêu cầu chi tiết sau này.

Template không thay thế BRD, đặc tả yêu cầu, quyết định kiến trúc, phê duyệt ngân sách hoặc quyết định triển khai. Nội dung ghi nhận là đầu vào để xác minh, phân tích, xử lý mâu thuẫn và phê duyệt trong artifact chính thức sau đó.

Ranh giới sử dụng

Tiêu chí	Nên sử dụng (Use for)	Không sử dụng (Do not use for)
Giai đoạn dự án	Khởi tạo, khảo sát ban đầu, discovery, trước BRD chính thức.	Thiết kế chi tiết, phát triển, kiểm thử hoặc triển khai sản phẩm.
Mục tiêu	Ghi nhận mô tả vấn đề (problem statement), mục tiêu kinh doanh, phạm vi cấp cao, bên liên quan chính và quy trình hiện hữu (as-is).	Định nghĩa Acceptance Criteria chi tiết, đặc tả kỹ thuật API, UI design hoặc kế hoạch sprint.
Mức độ chi tiết	Tập trung vào “cái gì” (what) cần giải quyết và “tại sao” (why) quan trọng với nghiệp vụ.	Mô tả chi tiết “làm thế nào” (how) đội kỹ thuật thực hiện giải pháp.
Tính cam kết	Bản ghi thảo luận, giả định, bằng chứng và nhu cầu được phát biểu tại thời điểm ghi nhận. Là đầu vào phân tích.	Hợp đồng yêu cầu đã phê duyệt cuối cùng (signed-off requirement).
Thẩm quyền quyết định	BA ghi nhận và đề xuất; stakeholder xác nhận tính đúng của thông tin đã ghi.	BA hoặc Owner Artifact tự phê duyệt phạm vi, chi phí, ngân sách, giải pháp kỹ thuật hoặc thay đổi kiến trúc trọng yếu.
Hệ quả quản trị	Nội dung phải được xử lý, xác minh và truy vết sang artifact chính thức khi dự án tiếp tục.	Không được dùng trạng thái IN_REVIEW làm bằng chứng phê duyệt hoặc baseline.

Vai trò và Trách nhiệm

Vai trò	Hành động, đối tượng và trách nhiệm
Owner Artifact	Principal IT Business Analyst / Technical Curriculum Author: Duy trì template TMPL-DISC-001, metadata, cấu trúc, lịch sử thay đổi và liên kết corpus. Xem xét tác động thay đổi template. Không phê duyệt nội dung nghiệp vụ của từng bản ghi.
Business Analyst (BA)	Điền bản ghi discovery dựa trên trao đổi và bằng chứng từ stakeholder; ghi vấn đề, mục tiêu, phạm vi, giả định, ràng buộc, rủi ro và vấn đề mở; gán ID khi áp dụng; duy trì truy vết. BA phải nêu rõ nguồn, mức độ xác minh và mâu thuẫn.
Project Manager (PM)	Dùng bản ghi để hiểu phạm vi, stakeholder, rủi ro ban đầu và phụ thuộc; điều phối xử lý vấn đề vượt thẩm quyền BA; trình cấp có thẩm quyền khi không thống nhất.
Solution/System Architect	Dùng bối cảnh nghiệp vụ và ràng buộc phi chức năng ban đầu để đánh giá tác động kiến trúc. Không suy diễn template thành đặc tả kỹ thuật đã phê duyệt.
Business Stakeholders/Owner	Xem xét việc BA ghi nhận đúng vấn đề, nhu cầu, mục tiêu và ràng buộc nghiệp vụ. Cung cấp xác nhận hoặc phản hồi; quyết định thuộc thẩm quyền phải được ghi nhận bằng văn bản trong artifact phù hợp.
QA Lead	Dùng bản ghi để nhận diện vùng rủi ro chất lượng, phụ thuộc và luồng cần xác minh sớm. Không coi bản ghi discovery là bộ Acceptance Criteria hoàn chỉnh.
Project Sponsor hoặc Ban chỉ đạo dự án	Ra quyết định cuối cùng khi vấn đề ảnh hưởng phạm vi, chi phí, ngân sách, ưu tiên liên phòng ban hoặc thay đổi trọng yếu vượt thẩm quyền các vai trò bên dưới. Quyết định phải có bằng chứng văn bản và cập nhật artifact liên quan.

Liên kết và Phụ thuộc Artifact

Template tồn tại trong hệ sinh thái tài liệu kiểm soát. Liên kết xác định đầu vào, đầu ra, authority và hệ quả truy vết.

Loại liên kết	Artifact liên quan	Mục đích liên kết và hệ quả
Đầu vào (Prerequisites)	Project Charter hoặc văn bản khởi tạo dự án.	Cung cấp thẩm quyền, bối cảnh kinh doanh và mục tiêu cấp cao cho hoạt động khảo sát. Nếu chưa có, BA phải ghi nhận giới hạn thẩm quyền và rủi ro discovery.
Đầu vào quản trị	/01-curriculum/TEMPLATE_MANIFEST.md	Xác nhận định danh TMPL-DISC-001, phiên bản và trạng thái template trong corpus.
Đầu vào quản trị	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Kiểm tra và đăng ký ID dùng cho yêu cầu, quy tắc, vấn đề và đối tượng truy vết.
Đầu ra (Downstream Artifacts)	Tài liệu yêu cầu nghiệp vụ (Business Requirements Document).	Nội dung discovery là đầu vào để phân tích, xác minh và soạn tài liệu yêu cầu chi tiết hơn. Không chuyển nguyên trạng thành yêu cầu đã phê duyệt nếu chưa xác minh.
Đầu ra (Downstream Artifacts)	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Quy tắc nghiệp vụ phát hiện được đề xuất để đăng ký vào catalog quy tắc chuẩn Nova Foods.
Đầu ra (Downstream Artifacts)	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Khái niệm và thực thể dữ liệu phát hiện được đề xuất cho từ điển dữ liệu chung.
Đầu ra (Downstream Artifacts)	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Yêu cầu, quy tắc và vấn đề được ghi nhận dùng ID như REQ-NF-xxxx, RULE-NF-xxxx để theo dõi vòng đời.

Thẩm quyền và Quy trình xử lý vấn đề (Escalation)

BA có thẩm quyền ghi nhận, tổng hợp và đề xuất nhu cầu nghiệp vụ. Việc điền template không tạo phê duyệt cho phạm vi, ngân sách, chi phí, ưu tiên, giải pháp kỹ thuật hay kiến trúc.

Business Owner, Project Sponsor hoặc cấp quản lý có thẩm quyền quyết định các nội dung thuộc phạm vi trách nhiệm của họ. Project Manager điều phối leo thang. Owner Artifact kiểm soát cấu trúc template, không thay thế thẩm quyền quyết định nghiệp vụ.

Khi có mâu thuẫn, thiếu bằng chứng, yêu cầu trái ngược hoặc vấn đề vượt thẩm quyền BA:

1. Bước 1: BA tổ chức làm rõ với stakeholder trực tiếp. BA ghi vấn đề, các bên có ý kiến, bằng chứng, phương án, trade-off và kết quả vào mục Open Issues của template.
2. Bước 2: Nếu chưa thống nhất, BA leo thang đến Project Manager và Senior BA/BA Lead. BA cung cấp mô tả mâu thuẫn, tác động tới phạm vi hoặc mục tiêu, bằng chứng hiện có, quyết định cần có và hậu quả nếu không quyết định.
3. Bước 3: Nếu vẫn chưa có quyết định, Project Manager trình Business Owner hoặc cấp có thẩm quyền cao hơn. Cấp quyết định phải ghi quyết định bằng văn bản. BA cập nhật quyết định, nguồn quyết định, artifact bị ảnh hưởng và liên kết truy vết.
4. Bước 4: Nếu quyết định làm đổi cấu trúc, metadata hoặc phiên bản template, Owner Artifact xử lý theo Quy trình Kiểm soát Thay đổi. Nếu quyết định chỉ đổi nội dung bản ghi dự án, BA cập nhật artifact dự án liên quan theo quy trình dự án.

3. Định danh Canonical, Liên kết và Kiểm soát Thay đổi

Template là artifact được kiểm soát trong hệ sinh thái học liệu Nova Foods. Định danh, nguồn gốc, trạng thái và quy trình thay đổi được quản lý để giữ nhất quán và traceability.

Bảng 1: Định danh và Liên kết Quản trị của Template

Thuộc tính	Giá trị	Diễn giải và Ràng buộc
Artifact ID	TMPL-DISC-001	Định danh Canonical (Canonical ID): Mã định danh duy nhất, không thay đổi của template. Artifact khác tham chiếu template phải dùng chính xác ID này để giữ truy vết tự động.
Tên tệp	/03-templates/TMPL-DISC-001_DISCOVERY_AND_BUSINESS_NEED_CAPTURE.md	Đường dẫn tệp được kiểm soát trong kho mã nguồn. Bản sao hoặc phiên bản ngoài đường dẫn này không phải nguồn chân lý.
Trạng thái quản trị	IN_REVIEW	Template đang được xem xét. Không được diễn giải trạng thái này thành phê duyệt, baseline hoặc quyền dùng làm chuẩn cuối cùng.
Manifest Nguồn	/01-curriculum/TEMPLATE_MANIFEST.md	Đăng ký tồn tại, phiên bản và trạng thái template. Thay đổi phiên bản hoặc trạng thái phải được phản ánh tại manifest theo quy trình kiểm soát thay đổi.
Registry ID	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	ID TMPL-DISC-001 phải được đăng ký trong sổ định danh chung để tránh trùng lặp và giữ toàn vẹn truy vết toàn cục.
Kiến trúc Quản trị	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Xác định quy tắc quản trị chung, cấu trúc thư mục và nguyên tắc kiểm soát phiên bản áp dụng cho template.

Bảng 2: Liên kết với các Chương Handbook (Giáo trình)

Chapter ID (minh họa)	Tên Chapter (minh họa)	Mối quan hệ với Template này
HB-CH-03	Khơi gợi và Hợp tác (Elicitation and Collaboration)	Template ghi kết quả hoạt động khơi gợi yêu cầu được mô tả trong chapter.
HB-CH-04	Quản lý Vòng đời Yêu cầu (Requirements Life Cycle Management)	Yêu cầu và stakeholder ghi trong template trở thành đối tượng cần quản lý, truy vết và phê duyệt theo quy trình chapter.
HB-CH-05	Phân tích Chiến lược (Strategy Analysis)	Template ghi Nhu cầu Nghiệp vụ (Business Need), là đầu ra cốt lõi của hoạt động phân tích chiến lược.
HB-CH-06	Phân tích Yêu cầu và Định nghĩa Thiết kế (Requirements Analysis and Design Definition)	Yêu cầu thô ghi trong template là đầu vào cho phân tích, mô hình hóa và đặc tả chi tiết.

Bảng 3: Liên kết với Nguồn Chuẩn và Quy định

Nguồn tham chiếu	Mối liên kết và Nghĩa vụ
BABOK Guide v3	Cấu trúc template gồm Nhu cầu nghiệp vụ, Bên liên quan và Phạm vi giải pháp được định hướng bởi Knowledge Areas như Strategy Analysis và Requirements Analysis.
ISO/IEC/IEEE 29148:2018	Template hỗ trợ tạo tài liệu đặc tả yêu cầu dựa trên các khái niệm của tiêu chuẩn này, gồm cấu trúc và thuộc tính yêu cầu tốt.
00-research/00_SOURCE_MAP.md	Nguồn chân lý cho tiêu chuẩn, luật và good practice được phép tham chiếu. Yêu cầu có nguồn gốc từ quy định phải trích dẫn chính xác theo định nghĩa trong 00_SOURCE_MAP.md.

Quy trình Kiểm soát Thay đổi (Change Control Process)

Mọi thay đổi cấu trúc Tier 1 và Tier 2 phải qua kiểm soát thay đổi. Mục tiêu: giữ nhất quán cho người học, template phụ thuộc và case study.

1. Đề xuất thay đổi: Người đề xuất tạo Change Request - CR. CR phải nêu lý do, phạm vi thay đổi, artifact bị ảnh hưởng, trade-off, lợi ích và hậu quả nếu không thay đổi.
2. Xem xét tác động: Owner Artifact xem tác động lên:
3. Ví dụ hoàn thiện Tier 3, gồm case study Nova Foods.
4. Hướng dẫn và bài tập trong Handbook (/02-handbook/).
5. Tiêu chí chất lượng và checklist tại Quality Gate (Tier 5).
6. Metadata, manifest, ID registry và liên kết truy vết liên quan.
7. Quyết định thay đổi: Thẩm quyền quyết định thay đổi cấu trúc template thuộc quy trình quản trị artifact. Quyết định phải được ghi nhận trước khi cập nhật trạng thái hoặc phiên bản. IN_REVIEW vẫn giữ nguyên khi chưa có tham chiếu phê duyệt hoặc baseline được ghi nhận.
8. Thực thi thay đổi: Khi thay đổi được chấp nhận theo quy trình, Owner Artifact cập nhật:
9. Số phiên bản template, ví dụ v0.9.0 thành v0.9.1 cho thay đổi nhỏ hoặc v1.0.0 cho thay đổi lớn.
10. Lịch sử thay đổi trong metadata.
11. /01-curriculum/TEMPLATE_MANIFEST.md để phản ánh phiên bản và trạng thái mới nhất.
12. Artifact phụ thuộc cần tương thích.
13. Đồng bộ và kiểm tra hậu quả: Artifact bị ảnh hưởng, gồm file case study Nova Foods, phải được kiểm tra tương thích. Không tương thích phải được ghi nhận là issue, có owner xử lý, bằng chứng và liên kết truy vết. Không được che giấu không tương thích bằng cách coi template là BASELINED hoặc đã phê duyệt.

2. Tier 2 ? Blank Copy-Paste-Ready Template

Phần này cung cấp một mẫu trống, sẵn sàng để sao chép-dán cho mỗi lần bạn bắt đầu một phân tích nhu cầu nghiệp vụ mới. Hãy điền thông tin vào các mục có dấu ngoặc nhọn, ví dụ: <Điền tên dự án>. Mỗi trường đều có hướng dẫn để giúp bạn hiểu cần cung cấp thông tin gì.

---

BNC-ID: <YYYYMMDD-TênDựÁn-V#>

2.1. Thông tin chung

Trường Thông Tin	Nội dung (Điền vào đây)	Hướng dẫn
Tên Sáng kiến/Dự án	<Tên đầy đủ của sáng kiến hoặc dự án>	Ghi rõ tên gọi chính thức để dễ dàng tham chiếu trong các tài liệu khác.
Người lập	<Tên của Business Analyst và chức danh>	Người chịu trách nhiệm chính trong việc soạn thảo và quản lý tài liệu này.
Ngày lập	<YYYY-MM-DD>	Ngày tài liệu này được tạo ra lần đầu.
Phiên bản	<Ví dụ: v1.0>	Bắt đầu với v1.0 và tăng dần sau mỗi lần có thay đổi quan trọng được phê duyệt.
Business Owner	<Tên và chức danh của người sở hữu quy trình nghiệp vụ>	Người có thẩm quyền quyết định cuối cùng về mặt nghiệp vụ và là người hưởng lợi chính từ dự án.

2.2. Phân tích Nhu cầu Nghiệp vụ (Business Need Analysis)

2.2.1. Bối cảnh và Vấn đề Hiện tại (Current Context and Problem)

<Mô tả chi tiết tình hình hiện tại của doanh nghiệp. Các quy trình nào đang bị ảnh hưởng? Vấn đề hoặc "nỗi đau" (pain point) mà người dùng hoặc doanh nghiệp đang gặp phải là gì? Cung cấp số liệu cụ thể nếu có, ví dụ: "Quy trình đặt hàng thủ công mất 3 giờ mỗi ngày và có tỷ lệ lỗi 15%".>

2.2.2. Cơ hội và Kết quả mong muốn (Opportunity and Desired Outcome)

<Mô tả cơ hội có thể nắm bắt nếu vấn đề được giải quyết. Việc này sẽ mang lại lợi ích gì? Ví dụ: "Tự động hóa quy trình có thể giảm thời gian xử lý xuống còn 30 phút và loại bỏ lỗi nhập liệu, giúp tiết kiệm 50 triệu VND mỗi năm và tăng sự hài lòng của nhà cung cấp". Kết quả cuối cùng mà doanh nghiệp muốn đạt được là gì?>

2.3. Mục tiêu Nghiệp vụ (Business Objectives)

Mục tiêu phải tuân thủ nguyên tắc SMART. Đây là một thuật ngữ tiếng Anh viết tắt cho các tiêu chí giúp mục tiêu trở nên rõ ràng và có thể đạt được. * S - Specific (Cụ thể): Mục tiêu chỉ rõ điều gì cần đạt được. * M - Measurable (Đo lường được): Có chỉ số (metric) để biết khi nào mục tiêu đã hoàn thành. * A - Achievable (Khả thi): Mục tiêu phải thực tế với nguồn lực và thời gian hiện có. * R - Relevant (Liên quan): Mục tiêu phải phù hợp với chiến lược chung của doanh nghiệp. * T - Time-bound (Có thời hạn): Có một mốc thời gian cụ thể để hoàn thành.

Mã Mục tiêu	Mô tả Mục tiêu (theo SMART)	Chỉ số đo lường (Metric)	Nguồn xác minh
OBJ-001	<Ví dụ: Giảm thời gian xử lý đơn đặt hàng từ 3 giờ xuống còn 30 phút trước ngày 2027-01-01>	Thời gian xử lý trung bình (phút)	<Báo cáo hiệu suất hệ thống ERP>
OBJ-002	<Mô tả mục tiêu nghiệp vụ cụ thể thứ hai>	<Chỉ số cụ thể để đo lường thành công>	<Nguồn dữ liệu/báo cáo để kiểm chứng>

2.4. Phạm vi Sáng kiến (Initiative Scope)

Việc xác định rõ ràng phạm vi là cực kỳ quan trọng để quản lý kỳ vọng và tránh "phình phạm vi" (scope creep) - hiện tượng các yêu cầu mới liên tục được thêm vào ngoài kế hoạch.

2.4.1. Trong Phạm vi (In-Scope)

• <Tính năng hoặc quy trình nghiệp vụ cụ thể sẽ được xây dựng/thay đổi. Ví dụ: "Xây dựng module quản lý nhà cung cấp trong hệ thống ERP">
• <Nhóm người dùng nào sẽ sử dụng giải pháp. Ví dụ: "Phòng Mua hàng">
• <Hệ thống hoặc dữ liệu nào sẽ bị ảnh hưởng trực tiếp. Ví dụ: "Cơ sở dữ liệu Nhà cung cấp">

2.4.2. Ngoài Phạm vi (Out-of-Scope)

• <Tính năng hoặc quy trình sẽ không được thực hiện trong dự án này. Ví dụ: "Module quản lý thanh toán cho nhà cung cấp">
• <Các hệ thống liên quan nhưng không thay đổi. Ví dụ: "Hệ thống Kế toán Kho">
• <Bất kỳ điều gì dễ gây nhầm lẫn là có trong phạm vi nhưng thực tế là không. Ví dụ: "Việc di chuyển dữ liệu lịch sử từ trước năm 2020">

2.5. Các Bên liên quan (Stakeholders)

Stakeholder là bất kỳ cá nhân, nhóm hoặc tổ chức nào có thể ảnh hưởng, bị ảnh hưởng hoặc tự cho rằng mình bị ảnh hưởng bởi một quyết định, hoạt động hoặc kết quả của dự án.

Vai trò / Chức danh	Tên	Mức độ Ảnh hưởng (Cao/Trung bình/Thấp)	Mối quan tâm chính trong dự án	Ghi chú
<Ví dụ: Trưởng phòng Mua hàng>	<Tên cụ thể>	<Cao>	<Đảm bảo quy trình mới dễ sử dụng và hiệu quả>	<Cần được tham vấn về tất cả các thay đổi quy trình>
<Vai trò khác, ví dụ: Nhân viên IT>	<Tên cụ thể>	<Trung bình>	<Khả năng tích hợp với hệ thống hiện tại>	<Cần được thông báo về các yêu cầu kỹ thuật>

2.6. Giả định, Ràng buộc và Rủi ro

2.6.1. Giả định (Assumptions)

Là những điều chúng ta tin là đúng khi lập kế hoạch, nhưng chưa được xác minh. Nếu giả định sai, kế hoạch có thể bị ảnh hưởng. * <Ví dụ: "Hạ tầng máy chủ hiện tại đủ khả năng đáp ứng tải của hệ thống mới."> * <Ví dụ: "Nhân viên sẽ có đủ thời gian để tham gia các buổi đào tạo.">

2.6.2. Ràng buộc (Constraints)

Là những giới hạn hoặc yếu tố bắt buộc phải tuân thủ. * <Ví dụ: "Tổng ngân sách dự án không vượt quá 500 triệu VND."> * <Ví dụ: "Hệ thống phải tuân thủ Nghị định 123/2020/NĐ-CP về hóa đơn, chứng từ."> * <Ví dụ: "Dự án phải hoàn thành trước ngày 2027-06-30.">

2.6.3. Rủi ro ban đầu (Initial Risks)

Là các sự kiện không chắc chắn có thể xảy ra và gây tác động tiêu cực đến dự án.

Mã Rủi ro	Mô tả Rủi ro	Khả năng xảy ra (Cao/Trung bình/Thấp)	Mức độ tác động (Cao/Trung bình/Thấp)	Phương án giảm thiểu ban đầu
RSK-001	<Ví dụ: Nhà cung cấp phần mềm không giao sản phẩm đúng hạn.>	<Trung bình>	<Cao>	<Thêm điều khoản phạt trễ vào hợp đồng.>
RSK-002	<Mô tả rủi ro tiềm ẩn khác>	<...>	<...>	<Đề xuất hành động để phòng ngừa hoặc giảm nhẹ>

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

Phiên bản	Ngày	Người xem xét	Chức danh	Hành động (Approved / Rejected / Comments)	Chữ ký (hoặc xác nhận điện tử)
<v1.0>	<YYYY-MM-DD>	<Tên người phê duyệt>	<Business Owner>	<Điền trạng thái phê duyệt>	<Xác nhận>
<...>	<...>	<...>	<...>	<...>	<...>

Các Bảng Theo dõi, Truy vết và Quản trị Tài liệu

Phần này cung cấp cấu trúc hoàn chỉnh để quản lý phiên bản, theo dõi phê duyệt, truy vết yêu cầu, quản lý bằng chứng và các vấn đề mở. Đây là các thành phần cốt lõi để đảm bảo tính minh bạch và kiểm soát được của tài liệu ghi nhận yêu cầu.

Lịch sử phiên bản (Version History)

Bảng này ghi lại mọi thay đổi quan trọng đối với tài liệu, đảm bảo mọi người đều làm việc trên phiên bản mới nhất và hiểu được lịch sử phát triển của nó.

Phiên bản (Version)	Ngày cập nhật	Người thực hiện	Tóm tắt thay đổi chính
<v0.1.0>	<YYYY-MM-DD>	<Tên của bạn>	<Mô tả ngắn gọn về các thay đổi trong phiên bản này, ví dụ: "Thêm yêu cầu về báo cáo tồn kho">
<...>	<...>	<...>	<...>

Theo dõi Review và Phê duyệt (Review and Sign-off Tracking)

Ghi lại quá trình xem xét và phê duyệt từ các bên liên quan (stakeholders). Một "sign-off" chính thức xác nhận rằng các bên liên quan đã đồng ý với nội dung được trình bày.

Vai trò (Role)	Người thực hiện	Ngày	Kết quả	Ghi chú / Tham chiếu
<Tên vai trò, ví dụ: Business Owner>	<Tên người review>	<YYYY-MM-DD>	<Đồng ý / Yêu cầu thay đổi / Đồng ý với điều kiện>	<Ghi chú cụ thể hoặc ID của yêu cầu thay đổi nếu có>
<Tên vai trò, ví dụ: Technical Architect>	<Tên người review>	<YYYY-MM-DD>	<Đồng ý / Yêu cầu thay đổi / Đồng ý với điều kiện>	<Ghi chú cụ thể về các ràng buộc kỹ thuật>
<...>	<...>	<...>	<...>	<...>

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

Truy vết (traceability) là khả năng theo dõi một yêu cầu từ nguồn gốc (ví dụ: một mục tiêu kinh doanh) đến khi nó được triển khai và kiểm thử. Ma trận này giúp đảm bảo mọi yêu cầu đều có giá trị và không có gì bị bỏ sót.

ID Yêu cầu	Loại liên kết	ID Nguồn / Đích	Mô tả liên kết
<REQ-XXX-NNN>	Bắt nguồn từ (Derives from)	<ID của mục tiêu kinh doanh, ví dụ: BIZ-OBJ-01>	Yêu cầu này hỗ trợ trực tiếp mục tiêu "Giảm thời gian xử lý đơn hàng 15%".
<REQ-XXX-NNN>	Kiểm chứng bởi (Verified by)	<ID của test case, ví dụ: TC-ORD-005>	Test case này sẽ xác nhận chức năng tính tổng giá trị đơn hàng hoạt động chính xác.
<REQ-XXX-NNN>	Phụ thuộc vào (Depends on)	<REQ-YYY-MMM>	Yêu cầu này chỉ có thể thực hiện sau khi giao diện đăng nhập (REQ-YYY-MMM) hoàn thành.
<...>	<...>	<...>	<...>

Các loại liên kết phổ biến: * Bắt nguồn từ (Derives from): Yêu cầu được sinh ra từ một đối tượng khác ở cấp cao hơn (ví dụ: quy tắc nghiệp vụ, luật định). * Đáp ứng (Satisfies): Yêu cầu thực hiện hóa một mục tiêu hoặc nhu cầu kinh doanh. * Kiểm chứng bởi (Verified by): Một test case hoặc tiêu chí chấp nhận sẽ dùng để kiểm tra yêu cầu này. * Phụ thuộc vào (Depends on): Yêu cầu này cần một yêu cầu khác được hoàn thành trước.

Danh mục Bằng chứng và Tài liệu đính kèm (Evidence and Attachments)

Liệt kê tất cả các tài liệu, email, biên bản họp, hoặc các bằng chứng khác được sử dụng làm cơ sở để xác định yêu cầu.

ID Bằng chứng	Tên / Mô tả	Loại tài liệu	Đường dẫn hoặc Vị trí lưu trữ
<EV-001>	Biên bản họp với phòng Kinh doanh ngày 2026-08-10	Biên bản họp	<Đường dẫn tới SharePoint/Confluence hoặc tên file đính kèm>
<EV-002>	Email xác nhận từ Kế toán trưởng về quy trình đối soát công nợ	Email	<ID của email hoặc file .msg/.eml>
<...>	<...>	<...>	<...>

Danh sách Vấn đề mở và Ngoại lệ (Open Issues and Exceptions)

Theo dõi các câu hỏi, điểm chưa rõ ràng, hoặc các quyết định đang chờ xử lý liên quan đến phạm vi và yêu cầu.

ID Vấn đề	Mô tả vấn đề	Người báo cáo	Ngày báo cáo	Trạng thái	Người xử lý	Ghi chú / Giải pháp
<ISS-001>	Chưa rõ quy trình xử lý cho khách hàng VIP yêu cầu giao hàng ngoài giờ hành chính.	<Tên của bạn>	<YYYY-MM-DD>	<Mới>	<Tên Business Owner>	<Cần tổ chức cuộc họp để xác định chính sách và chi phí liên quan.>
<...>	<...>	<...>	<...>	<...>	<...>	<...>

Trạng thái vấn đề: Mới, Đang phân tích, Chờ quyết định, Đã giải quyết, Đã hủy.

Hướng dẫn điền trường, quy tắc xác thực và mẫu tham chiếu

Phần này cung cấp hướng dẫn điền dữ liệu, quy tắc xác thực và các mẫu chuẩn để đảm bảo tính nhất quán và chất lượng cho tài liệu.

Bảng hướng dẫn ký hiệu placeholder

Bảng này giải thích các ký hiệu placeholder được dùng trong mẫu.

Ký hiệu placeholder	Diễn giải và quy tắc
<ID duy nhất>	Điền ID đã đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md. ID phải tuân thủ định dạng PREFIX-NNN. Ví dụ: REQ-001.
<Mô tả ngắn gọn>	Viết một câu duy nhất, súc tích, mô tả đối tượng. Tránh biệt ngữ. Mục đích là để người đọc hiểu ngay lập tức.
<YYYY-MM-DD>	Sử dụng định dạng ngày tháng ISO 8601. Mọi thời điểm đều được hiểu theo múi giờ Asia/Ho_Chi_Minh trừ khi có ghi chú khác.
[Lựa chọn]	Chọn một giá trị từ danh sách các giá trị được phép đã định nghĩa trước. Không điền giá trị tùy ý.
<Lý do nghiệp vụ>	Giải thích "tại sao" cần điều này. Tập trung vào giá trị hoặc vấn đề nghiệp vụ được giải quyết, không phải giải pháp kỹ thuật.

Quy tắc xác thực và giá trị được phép

Tất cả các trường phải tuân thủ các quy tắc xác thực chung sau đây.

Loại quy tắc	Mô tả chi tiết	Ví dụ áp dụng cho Nova Foods
ID-CANONICAL	Định danh phải tồn tại và khớp với định dạng đã đăng ký trong TRACEABILITY_ID_REGISTRY.md.	BR-SALES-005, UC-INV-002
DATE-ISO8601	Định dạng chuỗi YYYY-MM-DD.	2026-08-07
ENUM(...)	Giá trị phải là một trong các chuỗi được liệt kê trong ngoặc đơn, phân tách bằng dấu phẩy. Phân biệt chữ hoa/thường.	ENUM(High, Medium, Low)
CURRENCY-VND	Giá trị số nguyên dương, không chứa ký hiệu tiền tệ hoặc dấu phân cách hàng nghìn. Đại diện cho đơn vị Đồng.	15000000 (tương đương 15,000,000 VND)
TEXT-NOT-EMPTY	Trường văn bản không được để trống hoặc chỉ chứa khoảng trắng.	Trường "Tên yêu cầu" phải có nội dung.
REF-LEGAL	Tham chiếu phải trỏ đến một nguồn pháp lý đã được xác minh trong /00-research/00_SOURCE_MAP.md.	Luật Kế toán 88/2015/QH13, Điều 18

Quy tắc hiển thị có điều kiện

Một số phần trong tài liệu chỉ bắt buộc khi một điều kiện cụ thể được thỏa mãn. Luôn kiểm tra các quy tắc này.

• Ví dụ 1: NẾU trường [Phân loại yêu cầu] có giá trị là Yêu cầu Pháp lý / Tuân thủ THÌ mục "3.5. Tham chiếu Nguồn Pháp lý và Tuân thủ" là bắt buộc phải điền.
• Ví dụ 2: NẾU trường [Tích hợp hệ thống bên ngoài] có giá trị là Có THÌ mục "4.2. Đặc tả giao diện (API)" là bắt buộc phải điền.

Mẫu tham chiếu bí mật an toàn (Safe Secret Reference)

Không bao giờ ghi trực tiếp thông tin nhạy cảm như mật khẩu, API key, hoặc chuỗi kết nối vào tài liệu. Sử dụng mẫu tham chiếu an toàn sau.

Mẫu: SECRET_REF(<Tên kho chứa bí mật>/<Tên định danh của bí mật>)

Diễn giải: * SECRET_REF: Từ khóa cho biết đây là một tham chiếu đến bí mật. * <Tên kho chứa bí mật>: Tên của hệ thống quản lý bí mật (ví dụ: Azure Key Vault, AWS Secrets Manager, HashiCorp Vault). Ví dụ: NovaFoods-ERP-Vault-PROD. * <Tên định danh của bí mật>: Tên khóa (key) của bí mật được lưu trong kho. Ví dụ: ErpSystem-SapS4Hana-ApiUser-Password.

Ví dụ sử dụng: * SAI: API Key: "abc123xyz789-this-is-a-real-key" * ĐÚNG: API Key: SECRET_REF(NovaFoods-ERP-Vault-PROD/Partner-GHTK-ApiKey)

Cách làm này tuân thủ các khuyến nghị bảo mật hàng đầu như OWASP ASVS (V6: Stored Cryptography) và OWASP API Security Top 10, giúp tách biệt mã nguồn/tài liệu khỏi dữ liệu nhạy cảm.

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

Phần này là ví dụ hoàn chỉnh, điền đầy đủ dữ liệu mô phỏng cho Nova Foods dựa trên mẫu trống ở Tier 2. Mọi dữ liệu về tên, ngày, số liệu, vai trò, ID và quyết định trong phần này là dữ liệu mô phỏng phục vụ học tập.

Trạng thái artifact: IN_REVIEW
Phạm vi source boundary: Chỉ ghi nhận dữ liệu mô phỏng Nova Foods trong Tier 3. Không dùng làm bằng chứng vận hành, phê duyệt thật, căn cứ pháp lý hoặc quyết định triển khai thật.

---

Bản ghi nhu cầu nghiệp vụ: Tích hợp trạng thái giao hàng GHTK

Mã định danh (Requirement ID): NF-REQ-LOG-2026-003

Trường thông tin	Nội dung chi tiết (Dữ liệu mô phỏng Nova Foods)	Phân loại nguồn
Tiêu đề	Tự động hóa cập nhật trạng thái giao hàng từ Giao Hàng Tiết Kiệm (GHTK) vào ERP SAP S/4HANA.	SRC-CLASS-DERIVED
Người yêu cầu	Nguyễn Thị Lan (Vai trò: Trưởng phòng Kinh doanh). Chị Lan yêu cầu giảm việc tra cứu trạng thái đơn thủ công để nhân viên kinh doanh có dữ liệu trả lời khách hàng.	SRC-CLASS-STAKEHOLDER
Business Analyst	Trần Văn Minh. BA ghi nhận nhu cầu, tách dữ kiện nguồn với nhận định phân tích, xác định phạm vi và chuyển yêu cầu sang bước review.	SRC-CLASS-META
Ngày ghi nhận	2026-07-20	SRC-CLASS-META
Phân loại yêu cầu	Yêu cầu nghiệp vụ (Business Requirement). Yêu cầu mô tả kết quả kinh doanh cần đạt; chưa phê duyệt kiến trúc, nhà cung cấp tích hợp hoặc thiết kế kỹ thuật.	SRC-CLASS-BA-JUDGEMENT
Độ ưu tiên	Cao. Lý do: trạng thái giao hàng ảnh hưởng trực tiếp hoạt động chăm sóc khách hàng và năng suất nhân viên kinh doanh.	SRC-CLASS-STAKEHOLDER
Mô tả vấn đề	Quy trình hiện tại thủ công. Hai nhân viên kinh doanh đăng nhập cổng GHTK, tìm từng đơn hàng, sao chép trạng thái và dán vào ghi chú đơn hàng trong SAP. Quy trình dùng khoảng 2 giờ/ngày, gây chậm thông tin, sai sót nhập liệu và tăng số cuộc gọi khách hàng hỏi tình trạng đơn. Hậu quả: nhân viên dùng dữ liệu cũ để phản hồi; khách hàng không nhận được trạng thái nhất quán giữa GHTK và SAP.	SRC-CLASS-WORKSHOP (Buổi họp khám phá ngày 2026-07-18)
Nhu cầu nghiệp vụ	Nova Foods cần cơ chế đồng bộ trạng thái đơn hàng từ GHTK về SAP S/4HANA gần thời gian thực. Giải pháp phải truy vấn API GHTK theo mã đơn Nova Foods và cập nhật trường DeliveryStatus trên đối tượng SalesOrder khi trạng thái nguồn hợp lệ. Kết quả mong muốn: giảm thao tác tra cứu và nhập trạng thái thủ công, giảm sai lệch dữ liệu, cung cấp trạng thái kịp thời cho nhân viên và khách hàng.	SRC-CLASS-STAKEHOLDER (Phỏng vấn chị Lan ngày 2026-07-18)
Lợi ích dự kiến	Định lượng: Tiết kiệm 40 giờ công/tháng, ước tính khoảng 15.000.000 VND/tháng. Mục tiêu giảm 30% cuộc gọi đến bộ phận chăm sóc khách hàng liên quan trạng thái đơn. Định tính: Tăng khả năng phản hồi khách hàng, giảm rủi ro sai trạng thái do nhập tay, tăng khả năng truy vết lần cập nhật. Các giá trị này là ước tính phân tích, cần được xác minh bằng dữ liệu vận hành trước quyết định đầu tư.	SRC-CLASS-BA-ANALYSIS
Giả định	1. GHTK cung cấp API ổn định, được tài liệu hóa, cho phép truy vấn trạng thái theo mã đơn Nova Foods. 2. Nova Foods có năng lực kỹ thuật nội bộ hoặc đối tác để phát triển, vận hành và xử lý lỗi tích hợp. 3. Mã đơn dùng tại GHTK có thể liên kết duy nhất với SalesOrder trong SAP. Nếu giả định không đúng, cơ chế đồng bộ không thể xác định đúng đơn cần cập nhật.	SRC-CLASS-ASSUMPTION
Ràng buộc	1. Giải pháp phải tuân thủ chính sách bảo mật dữ liệu của Nova Foods. 2. API key GHTK phải lưu trong kho bí mật công ty, tham chiếu bằng SECRET_REF(NovaFoods-ERP-Vault-PROD/Partner-GHTK-ApiKey), không ghi trực tiếp trong mã nguồn, tài liệu vận hành hoặc log. 3. Ngân sách phát triển và triển khai không vượt quá 500.000.000 VND. 4. Mốc hoàn thành mục tiêu là Quý 4 năm 2026. Nếu vượt ngân sách hoặc mốc thời gian, người có thẩm quyền phải quyết định giảm phạm vi, đổi phương án hoặc dừng sáng kiến.	SRC-CLASS-CONSTRAINT

Quy tắc nghiệp vụ (Business Rules)

Các quy tắc sau chi phối hành vi giải pháp. Quy tắc chỉ có hiệu lực thiết kế sau review và quyết định theo quy trình quản trị artifact. Artifact hiện IN_REVIEW.

Mã quy tắc	Mô tả quy tắc	Nguồn gốc
BR-LOG-005	Hệ thống phải gọi API GHTK để lấy trạng thái mới cho mọi SalesOrder đang có trạng thái Đang vận chuyển trong SAP. Tần suất truy vấn mỗi đơn không dày hơn 15 phút/lần nhằm tránh vượt giới hạn API. Hệ thống phải ghi nhận thời điểm truy vấn và kết quả để đội IT xác định đơn nào chưa được đồng bộ.	SRC-CLASS-STAKEHOLDER / SRC-CLASS-CONSTRAINT
BR-LOG-006	Hệ thống phải ánh xạ trạng thái GHTK sang enum SAP S/4HANA theo bảng ánh xạ được kiểm soát dưới đây. Trạng thái GHTK mới, rỗng, sai định dạng hoặc chưa có ánh xạ không được tự động cập nhật DeliveryStatus. Hệ thống phải tạo cảnh báo cho đội IT kèm mã đơn, trạng thái nguồn, thời điểm nhận và lý do từ chối cập nhật. Hậu quả được kiểm soát: SAP giữ trạng thái hợp lệ gần nhất thay vì ghi dữ liệu không xác định.	SRC-CLASS-WORKSHOP
BR-LOG-007	Mỗi lần thay đổi trạng thái thành công phải ghi một bản ghi trong SalesOrder_StatusHistory, gồm mã đơn, thời gian cập nhật, trạng thái cũ, trạng thái mới và nguồn cập nhật GHTK_API. Mục đích: kiểm tra và truy vết thay đổi. Liên hệ với yêu cầu truy vết theo Luật An toàn thực phẩm 55/2010/QH12 là nội dung cần xác minh; artifact này không khẳng định luật đó bắt buộc bảng hoặc trường dữ liệu nêu trên.	SRC-CLASS-LEGAL (Yêu cầu truy vết theo Luật An toàn thực phẩm 55/2010/QH12 - cần xác minh)

Bảng ánh xạ trạng thái (BR-LOG-006 chi tiết)

Trạng thái GHTK (chuỗi)	Trạng thái SAP S/4HANA (enum)	Ghi chú và hậu quả
chua_lay_hang	AWAITING_PICKUP	Đợi GHTK lấy hàng. Đơn chưa bắt đầu vận chuyển.
da_lay_hang	IN_TRANSIT	GHTK đã nhận hàng. Đơn tiếp tục thuộc tập đơn cần đồng bộ.
dang_giao_hang	IN_TRANSIT	Đang trên đường giao. SAP duy trì trạng thái vận chuyển.
da_giao_hang	DELIVERED	Giao thành công. Đơn không còn thuộc tập truy vấn của BR-LOG-005.
da_doi_soat	DELIVERED	Đã đối soát sau giao. SAP vẫn biểu diễn kết quả giao thành công.
khong_giao_duoc	DELIVERY_FAILED	Giao thất bại. Bộ phận nghiệp vụ cần xử lý đơn theo quy trình hiện hành.
dang_chuyen_hoan	RETURN_IN_TRANSIT	Hàng đang hoàn trả về kho.
da_chuyen_hoan	RETURNED	Hàng hoàn đã về. Đơn không còn thuộc tập truy vấn vận chuyển.

Bản ghi lõi đã điền - Case Study Cải tiến Quy trình Mua hàng Nova Foods

Phần này điền đầy đủ mẫu Tier 2 bằng dữ liệu mô phỏng Nova Foods. Kịch bản: cải tiến quy trình tạo Đơn Mua Hàng (Purchase Order - PO) cho nguyên vật liệu. Bản ghi này là case riêng về mua hàng; không thay thế, không gộp ID và không thay đổi phạm vi của NF-REQ-LOG-2026-003.

Trạng thái artifact: IN_REVIEW
ID Yêu cầu Thay đổi: RFC-2026-041
Ngày ghi nhận: 2026-08-07
Người ghi nhận: An Nguyen, Senior IT Business Analyst

---

1. Bối cảnh và Vấn đề (Context & Problem Statement)

Quy trình tạo PO hiện thủ công. Nhân viên dùng Excel tổng hợp yêu cầu, dùng Word tạo PO và trao đổi qua email nội bộ. Mua hàng, Kho và Kế toán dùng dữ liệu phân mảnh. Hậu quả: chậm tạo PO, sai mã hàng hoặc đơn giá, khó đối chiếu dữ liệu và khó truy xuất thông tin lô hàng.

Nhu cầu truy xuất nguồn gốc lô hàng có liên hệ với Luật An toàn thực phẩm 55/2010/QH12 trong bối cảnh case study. Phạm vi nghĩa vụ pháp lý cụ thể, dữ liệu bắt buộc và cách chứng minh tuân thủ cần bộ phận Pháp chế xác minh. Bản ghi không khẳng định luật quy định thiết kế PO cụ thể.

• Bằng chứng: Phỏng vấn Trưởng phòng Mua hàng (INT-NF-003), phân tích 50 PO gần nhất ghi nhận 8 PO có sai sót mã hàng hoặc đơn giá, tỷ lệ 16% (A-TICKET-8812).
• Actor bị ảnh hưởng: Nhân viên Mua hàng tạo PO; Kho dùng PO để chuẩn bị nhận hàng; Kế toán Phải trả dùng PO để đối chiếu hóa đơn; Quản lý Sản xuất phụ thuộc lịch giao nguyên vật liệu.
• Hậu quả nếu không thay đổi: Sai PO tiếp tục lan sang nhận hàng, đối chiếu hóa đơn hoặc kế hoạch nguyên vật liệu; bộ phận phải xử lý ngoại lệ sau khi dữ liệu đã được dùng.

2. Nhu cầu Nghiệp vụ (Business Need)

• ID Nhu cầu: B-NEED-023
• Phát biểu nhu cầu: Nova Foods cần quy trình tích hợp để tạo, phê duyệt và quản lý PO trên ERP. Quy trình phải bảo đảm dữ liệu PO chính xác, nhất quán, liên kết với tồn kho và công nợ phải trả, đồng thời cho phép truy vết từ PO đến lô hàng nhập kho.
• Kết quả nghiệp vụ: Người dùng tạo PO từ dữ liệu gốc được kiểm soát; người có thẩm quyền phê duyệt PO theo quy tắc áp dụng; Kho và Kế toán nhận dữ liệu PO cùng một nguồn; người kiểm tra có thể tra PO tới lô hàng nhập kho.
• Trade-off: Số hóa tăng kiểm soát và truy vết nhưng cần thay đổi cách làm, đào tạo người dùng và xử lý dữ liệu gốc sai trước khi vận hành.

3. Các Bên liên quan chính (Key Stakeholders)

ID Stakeholder	Vai trò	Tên (Mô phỏng)	Hành động hoặc trách nhiệm	Mối quan tâm chính	Mức độ ảnh hưởng
STAKE-031	Trưởng phòng Mua hàng	Nguyễn Thị Lan	Chủ quy trình nghiệp vụ; cung cấp yêu cầu vận hành và review quy trình PO.	Giảm thời gian xử lý, tăng hiệu quả, có báo cáo.	Cao
STAKE-032	Kế toán Phải trả	Trần Văn Minh	Dùng dữ liệu PO để đối chiếu hóa đơn; phản hồi lỗi dữ liệu ảnh hưởng công nợ.	Dữ liệu PO chính xác, giảm nhập liệu tay.	Cao
STAKE-033	Quản lý Kho	Lê Hoàng Anh	Dùng PO và ngày giao dự kiến để xếp lịch nhận hàng, liên kết nhận hàng với PO.	Thông tin PO và ngày giao chính xác.	Trung bình
STAKE-034	Quản lý Sản xuất	Phạm Thu Hà	Dùng thông tin PO để điều phối kế hoạch nguyên vật liệu.	Nguyên vật liệu về đúng hạn, đủ số lượng.	Cao
STAKE-035	IT ERP Manager	Bùi Quang Huy	Đánh giá khả thi kỹ thuật, bảo mật, tích hợp và vận hành ERP.	Tích hợp, bảo mật hệ thống, khả năng hỗ trợ.	Trung bình

4. Mục tiêu Nghiệp vụ (Business Objectives)

Các mục tiêu SMART dưới đây là mục tiêu case study. Baseline và target cần được chủ sở hữu dữ liệu xác nhận trong review trước khi dùng làm tiêu chí nghiệm thu.

ID Mục tiêu	Mục tiêu (Objective)	Thước đo (Metric)	Giá trị Hiện tại (Baseline)	Giá trị Mục tiêu (Target)	Chủ sở hữu đo lường
OBJ-011	Giảm thời gian từ lúc có yêu cầu đến lúc gửi PO.	Thời gian xử lý PO (PO Cycle Time).	48 giờ	< 8 giờ làm việc	Trưởng phòng Mua hàng
OBJ-012	Giảm sai sót nhập liệu trên PO.	Tỷ lệ PO có lỗi (PO Error Rate).	16%	< 1%	Trưởng phòng Mua hàng và Kế toán Phải trả
OBJ-013	Tăng khả năng truy xuất PO với lô nhập kho.	Tỷ lệ PO liên kết được với lô nhập kho.	70% (tra cứu thủ công)	100% (liên kết tự động)	Quản lý Kho
OBJ-014	Tăng năng suất xử lý PO.	Số PO xử lý trên nhân viên mỗi ngày.	10	> 25	Trưởng phòng Mua hàng

5. Phạm vi Giải pháp (Solution Scope)

Phân loại	Mục	Actor, action, object, outcome	Ghi chú
Trong phạm vi (In-Scope)	Quy trình Yêu cầu - Phê duyệt - Tạo PO cho nguyên vật liệu sản xuất.	Nhân viên Mua hàng tạo PO nguyên vật liệu; người phê duyệt xử lý PO theo quy tắc đã được xác nhận; kết quả là PO có trạng thái được kiểm soát.	Chỉ áp dụng cho NVL, không áp dụng tài sản hoặc dịch vụ.
Trong phạm vi (In-Scope)	Tích hợp PO với phân hệ Kho và Kế toán Phải trả của ERP.	ERP ghi nhận cam kết PO, cập nhật trạng thái nhận hàng và cung cấp dữ liệu PO cho đối chiếu hóa đơn.	Không mở rộng sang xử lý thanh toán.
Trong phạm vi (In-Scope)	Gửi PO tự động đến Nhà cung cấp qua email dạng PDF.	Hệ thống gửi PO đã đủ điều kiện phát hành; Nhà cung cấp nhận bản PDF qua email.	ponytail: assumes email PDF is enough. upgrade to EDI/API integration when supplier capability confirmed.
Ngoài phạm vi (Out-of-Scope)	Quản lý hợp đồng và báo giá từ nhà cung cấp (Sourcing).	Quy trình sourcing hoàn tất trước khi người dùng tạo PO.	Không xây chức năng quản lý hợp đồng hoặc lựa chọn báo giá trong RFC này.
Ngoài phạm vi (Out-of-Scope)	Thanh toán hóa đơn nhà cung cấp.	Kế toán Phải trả xử lý thanh toán theo quy trình riêng; giải pháp chỉ cung cấp dữ liệu PO cần thiết.	Giảm rủi ro mở rộng phạm vi sang tài chính.
Ngoài phạm vi (Out-of-Scope)	Mua sắm tài sản cố định hoặc chi phí hoạt động (non-inventory).	Các yêu cầu này tiếp tục dùng quy trình mua sắm riêng.	Không dùng mục tiêu hoặc rule của RFC này để thay đổi quy trình đó.

6. Giả định và Ràng buộc (Assumptions and Constraints)

ID	Loại	Nội dung	Nguồn/Căn cứ	Hậu quả nếu không đúng
ASMP-007	Giả định	Dữ liệu gốc về nhà cung cấp và mã nguyên vật liệu đã tồn tại, chính xác trong ERP.	Xác nhận từ IT ERP Manager.	PO mới vẫn có thể sai nếu dữ liệu gốc sai; cần làm sạch dữ liệu trước vận hành.
ASMP-008	Giả định	Quy tắc phê duyệt PO theo giá trị và loại hàng đã được cấp quản lý định nghĩa và phê duyệt.	Yêu cầu xác minh với Giám đốc Tài chính.	Không thể cấu hình luồng phê duyệt có thẩm quyền rõ ràng; PO có thể bị chậm hoặc phê duyệt sai cấp.
CONS-015	Ràng buộc	Giải pháp phải xây trên nền tảng công nghệ ERP hiện tại.	Quyết định từ Ban Giám đốc về chiến lược CNTT.	Không chọn sản phẩm hoặc nền tảng độc lập làm phương án thay thế trong phạm vi RFC này.
CONS-016	Ràng buộc	Thông tin trên PO phải được Pháp chế đánh giá theo Nghị định 123/2020/NĐ-CP và Luật Kế toán 88/2015/QH13.	Yêu cầu xác minh từ bộ phận Pháp chế.	Không được khẳng định tuân thủ hoặc phát hành thiết kế pháp lý cho đến khi có kết quả xác minh.
CONS-017	Ràng buộc	Ngân sách dự án không vượt quá 2.500.000.000 VND.	Biên bản họp Hội đồng Quản trị BOM-MTG-2026-Q2.	Phạm vi, lộ trình hoặc phương án phải được điều chỉnh nếu ước tính vượt ngân sách.

Phân tích Nhu cầu, Phương án và Quyết định

Phần này ghi nhận phân tích cho nhu cầu BNEED-PROC-001. Nhu cầu này tập trung quản lý hợp đồng nhà cung cấp, khác B-NEED-023 về tạo PO. Cả hai cùng thuộc case Nova Foods nhưng phải được quản trị như hai nhu cầu có phạm vi và truy vết riêng. Dữ liệu là mô phỏng.

1. Hiện trạng và Nhu cầu Cốt lõi

Hạng mục	Mô tả chi tiết	Nguồn bằng chứng
ID Nhu cầu	BNEED-PROC-001: Tự động hóa quy trình quản lý hợp đồng nhà cung cấp.	INT-PROC-001 (Phỏng vấn Trưởng phòng Mua hàng, 2026-07-20)
Quy trình hiện tại	Phòng Mua hàng soạn hợp đồng bằng Word, gửi email lấy phê duyệt nội bộ, in để ký và lưu bản cứng. Dữ liệu nhà cung cấp được nhập tay vào Excel dùng chung.	OBS-PROC-003 (Quan sát quy trình làm việc tại Phòng Mua hàng, 2026-07-22)
Các bên liên quan	Phòng Mua hàng sở hữu quy trình; Phòng Pháp chế review điều khoản; Phòng Kế toán thiết lập thanh toán; Ban Giám đốc phê duyệt cuối cùng theo quy trình áp dụng.	Sơ đồ tổ chức Nova Foods, v1.2
Điểm yếu	Hoàn tất hợp đồng mất trung bình 18 ngày làm việc. Dữ liệu nhà cung cấp như MST và tài khoản ngân hàng có thể sai lệch giữa Excel và hợp đồng gốc. Trạng thái phê duyệt, lịch sử phiên bản, ngày hết hạn và việc gia hạn không có nguồn tập trung.	LOG-ERR-FIN-005 (Báo cáo lỗi thanh toán Q2/2026)
Nhu cầu cốt lõi	Giảm thời gian hoàn tất hợp đồng xuống tối đa 5 ngày; tạo nguồn dữ liệu nhà cung cấp nhất quán giữa hợp đồng và ERP; tự động hóa luồng phê duyệt và nhắc gia hạn.	REQ-PROC-015 (Yêu cầu từ Trưởng phòng Mua hàng)

2. Phân tích Phương án và Tiêu chí Quyết định

Phương án	Mô tả	Ưu điểm	Nhược điểm, trade-off và hậu quả
PA-1: Giữ nguyên	Không thay đổi quy trình hiện tại.	Không tốn chi phí triển khai; không cần đào tạo hoặc thay đổi hệ thống.	Chậm trễ, sai dữ liệu, thiếu truy vết và rủi ro vận hành tiếp diễn. Không đáp ứng mục tiêu tự động hóa.
PA-2: Tối ưu thủ công	Chuẩn hóa mẫu Word, checklist phê duyệt giấy và kiểm tra chéo Excel.	Chi phí thấp; triển khai nhanh; cải thiện tính nhất quán tài liệu ở mức hạn chế.	Vẫn phụ thuộc con người, không có nguồn dữ liệu tập trung, khó mở rộng và không loại bỏ gốc rễ của lỗi nhập liệu hoặc chậm phê duyệt.
PA-3: Xây dựng Module ERP	Phát triển module trong ERP hiện tại để khởi tạo hợp đồng từ mẫu, phê duyệt điện tử, lưu trữ số và đồng bộ dữ liệu nhà cung cấp.	Tự động hóa cao; giảm nhập tay; lịch sử thay đổi tập trung; tích hợp Kế toán và Kho; mở rộng được.	Chi phí và nỗ lực triển khai cao nhất; ước tính phát triển 3 tháng; cần đào tạo và kiểm soát chuyển đổi dữ liệu.

Tiêu chí Quyết định

Tiêu chí	Trọng số	Lý do chọn	Hệ quả đánh đổi
Giảm thời gian xử lý	30%	Ảnh hưởng trực tiếp tính linh hoạt chuỗi cung ứng và khả năng chốt điều kiện mua hàng.	Phương án nhanh triển khai nhưng ít tự động hóa có thể không đạt mục tiêu dài hạn.
Tính chính xác dữ liệu	30%	Dữ liệu sai có thể gây lỗi thanh toán và sai lệch vận hành.	Cần đầu tư kiểm soát dữ liệu gốc và tích hợp.
Chi phí triển khai	20%	Ngân sách giới hạn phạm vi và tính khả thi thực tế.	Phương án rẻ hơn giữ lại nhiều thao tác thủ công.
Khả năng mở rộng	10%	Giải pháp cần hỗ trợ tăng trưởng công ty trong 3-5 năm tới.	Giải pháp tùy biến sâu có thể tăng chi phí bảo trì.
Mức độ chấp nhận người dùng	10%	Giải pháp khó dùng có nguy cơ không được áp dụng đầy đủ.	Cần đào tạo, hướng dẫn và phản hồi người dùng trước vận hành.

3. Đề xuất, Thẩm quyền và Hậu quả

• Đề xuất phân tích: Ưu tiên PA-3: Xây dựng Module ERP để đưa vào review. Phương án này phù hợp nhất với nhu cầu giảm nhập liệu thủ công, tạo lịch sử tập trung và đồng bộ dữ liệu nhà cung cấp với ERP. Đề xuất không phải phê duyệt đầu tư hoặc phê duyệt triển khai.
• Cơ sở đề xuất: PA-1 không xử lý vấn đề. PA-2 giảm một phần lỗi biểu mẫu nhưng giữ dữ liệu phân mảnh và phụ thuộc con người. PA-3 có chi phí và thời gian cao hơn nhưng là phương án duy nhất trong ba phương án bao phủ toàn bộ nhu cầu về luồng phê duyệt, lưu trữ số, truy vết và đồng bộ.
• Thẩm quyền quyết định: Ông Nguyễn Văn Hùng, Giám đốc Chuỗi Cung ứng (Chief Supply Chain Officer), là người có thẩm quyền quyết định cuối cùng cho đề xuất này sau khi tham vấn Giám đốc Tài chính và Giám đốc CNTT. Artifact hiện IN_REVIEW; chưa có ghi nhận phê duyệt.
• Hành động review bắt buộc: Giám đốc Tài chính xác minh ASMP-008, bộ phận Pháp chế xác minh CONS-016, IT ERP Manager đánh giá khả thi PA-3, Trưởng phòng Mua hàng xác nhận baseline và target. Các kết quả phải được ghi vào artifact quản trị liên quan trước khi chuyển trạng thái.
• Hậu quả nếu chọn PA-1 hoặc PA-2: Nova Foods tiếp tục chịu chi phí xử lý lỗi thanh toán được ước tính 250.000.000 VND/năm trong case study, mất cơ hội hợp đồng do chậm trễ, khó kiểm soát vòng đời hợp đồng và giảm độ tin cậy với nhà cung cấp chiến lược.
• Hậu quả nếu chọn PA-3 nhưng không quản trị chuyển đổi: Dữ liệu gốc sai, rule phê duyệt chưa xác minh hoặc người dùng chưa được đào tạo có thể làm số hóa lỗi hiện hữu. Vì vậy triển khai chỉ được xem xét sau khi các giả định, ràng buộc và trách nhiệm nêu trên được review.

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, rủi ro, và các điểm cần làm rõ để đảm bảo yêu cầu được hiểu đúng và đầy đủ. Đây là nền tảng để quản lý phạm vi và chất lượng trong các giai đoạn sau. Mọi thông tin trong phần này đều là dữ liệu mô phỏng cho case study Nova Foods.

4.1. Bằng chứng và Tham chiếu (Evidence and References)

Bảng này liên kết nhu cầu nghiệp vụ với các nguồn thông tin hoặc quy định cụ thể, thiết lập khả năng truy vết nguồn gốc (traceability).

ID Truy vết	Hạng mục	Nguồn Tham chiếu	Lý do / Diễn giải
NEED-001	Tự động hóa đối soát và thanh toán hợp đồng nhà cung cấp.	TMPL-DISC-001_DISCOVERY_AND_BUSINESS_NEED_CAPTURE.md, Mục 3	Đây là nhu cầu kinh doanh cốt lõi đã được phân tích và đề xuất trong tài liệu này.
BR-PAY-001	Hóa đơn phải hợp lệ, có định dạng XML chuẩn theo quy định của Tổng cục Thuế.	Nghị định 123/2020/NĐ-CP	Đảm bảo tuân thủ pháp luật về hóa đơn, chứng từ điện tử tại Việt Nam.
REQ-NF-001	Dữ liệu hợp đồng và chứng từ thanh toán phải được lưu trữ tối thiểu 10 năm.	Luật Kế toán 88/2015/QH13, Điều 41	Tuân thủ yêu cầu pháp lý về thời hạn lưu trữ tài liệu kế toán.
BR-PROC-003	Quy trình phê duyệt thanh toán phải có ít nhất hai cấp (Kế toán viên và Kế toán trưởng).	Quy định nội bộ của Nova Foods: NF-FIN-POL-002	Áp dụng nguyên tắc bốn mắt (four-eyes principle) để giảm thiểu rủi ro sai sót và gian lận.

4.2. Giả định (Assumptions)

Đây là những điều kiện được cho là đúng để bản phân tích có hiệu lực. Nếu các giả định này sai, kế hoạch dự án có thể cần điều chỉnh.

ID Giả định	Nội dung Giả định	Mức độ Ảnh hưởng (Nếu sai)	Hành động Giảm thiểu / Xác minh
ASMP-DISC-001	Hệ thống ERP hiện tại (mô phỏng SAP S/4HANA) có các API đủ mạnh và sẵn sàng để tích hợp module mới.	Cao	Yêu cầu Kiến trúc sư Kỹ thuật (Technical Architect) xác minh khả năng của API trước khi bắt đầu giai đoạn thiết kế.
ASMP-DISC-002	Phần lớn nhà cung cấp chiến lược (80%+) có khả năng xuất và gửi hóa đơn điện tử định dạng XML chuẩn.	Trung bình	Phòng Mua hàng thực hiện khảo sát nhanh với 10 nhà cung cấp lớn nhất. Xây dựng phương án dự phòng cho việc nhập liệu thủ công.
ASMP-DISC-003	Đội ngũ kế toán thanh toán có thể làm chủ quy trình mới sau 2 tuần đào tạo tập trung.	Trung bình	Lên kế hoạch đào tạo chi tiết, có bài kiểm tra cuối khóa. Bố trí nhân sự hỗ trợ tại chỗ (on-site support) trong 1 tháng đầu sau khi go-live.
ASMP-DISC-004	Ngân sách 2.5 tỷ VND được phê duyệt cho Phương án 3 đã bao gồm chi phí cho bản quyền, hạ tầng và một khoản dự phòng 15%.	Cao	Yêu cầu Giám đốc Tài chính (CFO) xác nhận lại cơ cấu chi tiết của ngân sách đã duyệt.

4.3. Luồng Tiêu cực và Ngoại lệ (Negative Paths & Exceptions)

Bảng này mô tả các tình huống không mong muốn và cách hệ thống/quy trình phải xử lý chúng.

ID Ngoại lệ	Tình huống	Hành vi Mong muốn của Hệ thống / Quy trình	Vai trò chịu trách nhiệm Xử lý
EXCP-DISC-001	Hóa đơn của nhà cung cấp không khớp với điều khoản thanh toán trên hợp đồng (sai số tiền, sai ngày).	Hệ thống tự động từ chối hóa đơn, tạo một task "Đối soát thủ công" trong hệ thống và gửi thông báo cho người dùng được phân công.	Kế toán Thanh toán
EXCP-DISC-002	API của ngân hàng đối tác không phản hồi yêu cầu kiểm tra trạng thái thanh toán.	Hệ thống ghi nhận trạng thái giao dịch là "Chờ xác nhận", tự động thử lại sau mỗi 15 phút. Sau 3 lần thất bại, hệ thống tạo cảnh báo mức độ cao cho IT Support.	IT Support
EXCP-DISC-003	Nhà cung cấp gửi hóa đơn sai mã số thuế của Nova Foods.	Hệ thống xác thực mã số thuế với dữ liệu gốc. Nếu sai, hệ thống từ chối và gửi email tự động cho nhà cung cấp, nêu rõ lý do.	Nhà cung cấp (tự sửa), Kế toán (theo dõi)
EXCP-DISC-004	Hợp đồng gốc trong hệ thống hết hạn nhưng vẫn có yêu cầu thanh toán phát sinh.	Hệ thống chặn việc tạo yêu cầu thanh toán. Gửi cảnh báo đến Phòng Mua hàng để gia hạn hoặc chấm dứt hợp đồng.	Phòng Mua hàng

4.4. Các hạng mục cần xác minh (Items Requiring Verification)

Đây là những điểm chưa rõ ràng hoặc nằm ngoài thẩm quyền của BA, cần được xác nhận bởi các bên liên quan có chuyên môn.

ID Xác minh	Hạng mục Cần Xác minh	Vai trò Cần Xác minh (Role to Verify With)	Trạng thái / Hạn chót
VER-DISC-001	Yêu cầu pháp lý chính xác về chữ ký số trên chứng từ thanh toán điện tử khi thực hiện qua module ERP.	Trưởng phòng Pháp chế (Head of Legal)	Cần xác minh trước 2026-08-21
VER-DISC-002	Chi phí và thời gian cần thiết để đội ngũ kỹ thuật nội bộ phát triển các API cần thiết trên hệ thống ERP lõi.	Kiến trúc sư Kỹ thuật (Technical Architect)	Cần xác minh trước 2026-08-18
VER-DISC-003	Quy trình nghiệp vụ chuẩn (SOP) để xử lý các tranh chấp thanh toán với nhà cung cấp khi hệ thống báo lỗi.	Kế toán trưởng (Chief Accountant)	Cần xác minh trước 2026-08-25

4.5. Ghi nhận Leo thang (Escalation Records)

Ghi lại các vấn đề nghiêm trọng không thể giải quyết ở cấp độ nhóm dự án và cần sự can thiệp từ cấp quản lý cao hơn.

ID Leo thang	Vấn đề	Phân tích Tác động	Người nhận Leo thang	Trạng thái
ESC-DISC-001	Mâu thuẫn giữa yêu cầu của nghiệp vụ (cập nhật trạng thái thanh toán từ ngân hàng theo thời gian thực) và giới hạn kỹ thuật (API của ngân hàng chỉ hỗ trợ cập nhật theo lô mỗi giờ).	Nếu không giải quyết, hệ thống không thể đáp ứng mong đợi về tính tức thời của dữ liệu, có thể ảnh hưởng đến quyết định của bộ phận tài chính.	Giám đốc CNTT (CIO), Giám đốc Tài chính (CFO)	Đang chờ quyết định

Ma trận truy vết yêu cầu (Requirements Traceability Matrix - RTM)

Ma trận Truy vết Yêu cầu (Requirements Traceability Matrix - RTM) liên kết các artifact trong vòng đời phát triển. Nó cung cấp khả năng truy vết hai chiều: * Truy vết xuôi (Forward traceability): Từ nhu cầu (NEED) đến yêu cầu (REQ) và đến kiểm thử (TC). Trả lời câu hỏi: "Chúng ta có đang xây dựng đúng thứ không?" * Truy vết ngược (Backward traceability): Từ kiểm thử (TC) ngược về yêu cầu (REQ). Trả lời câu hỏi: "Chúng ta có đang xây dựng đủ chưa?"

Ma trận này là bằng chứng cho việc mọi yêu cầu đều được xem xét, triển khai và kiểm thử. Nó cũng hỗ trợ phân tích tác động khi có thay đổi. Bảng dưới đây là một ví dụ cho kịch bản "Xử lý hóa đơn nhà cung cấp" của Nova Foods (dữ liệu mô phỏng).

Bảng Truy vết End-to-End cho REQ-PROC-001

Bảng này ghi nhận liên kết giữa các định danh (ID) đã được đăng ký tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md.

ID Truy Vết	Loại Artifact	Mô tả ngắn gọn	Liên kết ngược (Upstream)	Liên kết xuôi (Downstream)
NEED-FIN-001	Business Need	Tự động hóa quy trình đối chiếu công nợ phải trả với NCC để giảm sai sót và tăng tốc độ thanh toán.	(Nguồn gốc nghiệp vụ)	REQ-PROC-001
REQ-PROC-001	Requirement	Hệ thống phải cho phép Kế toán Công nợ tải lên file hóa đơn (PDF/ảnh) và tự động trích xuất các thông tin chính.	NEED-FIN-001	AC-PROC-001.1, AC-PROC-001.2, BR-VALID-015, API-POST-INVOICES-UPLOAD
BR-VALID-015	Business Rule	Hóa đơn nhà cung cấp chỉ hợp lệ nếu Tổng tiền trước thuế + Thuế GTGT = Tổng tiền thanh toán.	REQ-PROC-001	TC-VALID-015-FAIL
AC-PROC-001.1	Acceptance Criterion	Khi tải lên file PDF hóa đơn hợp lệ, hệ thống trích xuất chính xác 100% các trường và hiển thị trong 5 giây.	REQ-PROC-001	TC-PROC-001-PASS
AC-PROC-001.2	Acceptance Criterion	Khi tải lên file định dạng không được hỗ trợ (vd: .docx), hệ thống trả về lỗi INVALID_FILE_TYPE và không xử lý.	REQ-PROC-001	TC-PROC-001-FAIL-01
DATA-INV-001	Data Element	supplier_code: Mã nhà cung cấp.	API-POST-INVOICES-UPLOAD	(Trường dữ liệu)
DATA-INV-002	Data Element	invoice_number: Số hóa đơn của nhà cung cấp.	API-POST-INVOICES-UPLOAD	(Trường dữ liệu)
DATA-INV-003	Data Element	subtotal_amount: Tổng tiền hàng trước thuế.	API-POST-INVOICES-UPLOAD	(Trường dữ liệu)
API-POST-INVOICES-UPLOAD	API Endpoint	POST /api/v1/invoices/upload: Endpoint để tải lên và xử lý hóa đơn.	REQ-PROC-001	DATA-INV-001, DATA-INV-002, DATA-INV-003, TC-PROC-001-PASS, TC-PROC-001-FAIL-01
TC-PROC-001-PASS	Test Case	Tải lên hóa đơn PDF hợp lệ từ NCC "Thực Phẩm An Bình", xác minh các trường được trích xuất chính xác.	AC-PROC-001.1, API-POST-INVOICES-UPLOAD	(Kết quả kiểm thử)
TC-PROC-001-FAIL-01	Test Case	Tải lên một file invoice.docx, xác minh hệ thống trả về mã lỗi INVALID_FILE_TYPE với HTTP status 415.	AC-PROC-001.2, API-POST-INVOICES-UPLOAD	(Kết quả kiểm thử)
TC-VALID-015-FAIL	Test Case	Tải lên hóa đơn PDF có tổng tiền bị sai lệch (tổng tiền các dòng không khớp tổng thanh toán), xác minh hệ thống trả về lỗi VALIDATION_ERROR_INVOICE_TOTAL.	BR-VALID-015	(Kết quả kiểm thử)

Quản trị dữ liệu Truy vết

Việc duy trì ma trận này là một hoạt động quản trị có kiểm soát.

Hạng mục quản trị	Giá trị
Mục đích	Đảm bảo tính toàn vẹn và khả năng kiểm tra của quy trình phân tích yêu cầu trong case study Nova Foods.
Owner dữ liệu	Vai trò Business Analyst (trong bối cảnh dự án mô phỏng).
Tần suất cập nhật	Cập nhật ngay khi một artifact mới (REQ, AC, TC...) được tạo hoặc thay đổi.
Quy tắc xác minh	Một yêu cầu (REQ) chỉ được coi là "hoàn thành" khi có liên kết xuôi đến ít nhất một Test Case cho mỗi Tiêu chí Chấp nhận (AC).

Bằng chứng Kỹ thuật: Payload Mẫu và Bảng Quyết định

Phần này cung cấp các bằng chứng kỹ thuật cụ thể hỗ trợ trực tiếp cho nhu cầu nghiệp vụ NEED-NF-001. Các bằng chứng này bao gồm một payload mẫu và một bảng quyết định, giúp làm rõ dữ liệu trao đổi và logic xử lý. Một "payload" là gói dữ liệu mà một hệ thống phần mềm gửi cho một hệ thống khác, thường ở định dạng JSON (JavaScript Object Notation), chứa thông tin có cấu trúc. Một "bảng quyết định" (Decision Table) là công cụ được chuẩn hóa bởi IIBA (trong BABOK Guide) và ISTQB, dùng để mô tả các quy tắc nghiệp vụ phức tạp một cách trực quan, liệt kê tất cả các tổ hợp điều kiện có thể xảy ra và hành động tương ứng cho mỗi tổ hợp.

Payload Mẫu cho Biên bản Giao hàng Điện tử (ePOD)

Đây là một ví dụ về payload JSON mà "Hệ thống Quản lý Giao hàng NovaShip" (mô phỏng) sẽ gửi đến hệ thống ERP của Nova Foods khi một đơn hàng được giao thành công. Payload này chứa tất cả dữ liệu cần thiết để ERP tiến hành đối soát công nợ.

• Định danh Dữ liệu (Data ID): DATA-NF-ePOD-001
• Nguồn: API của Hệ thống NovaShip
• Mô tả: Gói dữ liệu xác nhận tình trạng giao hàng, bao gồm thông tin chi tiết về sản phẩm và số lượng thực tế được giao.

{
  "deliveryConfirmationId": "DCNF-20260807-98B3C1",
  "salesOrderId": "SO-2026-07-1125",
  "invoiceId": "INV-2026-07-1350",
  "customerId": "CUS-BHX-001",
  "deliveryTimestamp": "2026-08-07T14:30:15+07:00",
  "status": "COMPLETED",
  "recipientName": "Nguyen Van An",
  "recipientSignatureId": "SIG-STORAGE-REF-AEB33409",
  "deliveredItems": [
    {
      "productCode": "NF-FRZ-FISH-001",
      "productName": "Cá Tuyết Phi Lê Đông Lạnh",
      "quantityExpected": 50,
      "quantityDelivered": 50,
      "unit": "kg"
    },
    {
      "productCode": "NF-FRZ-SHRIMP-002",
      "productName": "Tôm Sú Đông Lạnh (Size L)",
      "quantityExpected": 100,
      "quantityDelivered": 100,
      "unit": "kg"
    }
  ],
  "deliveryNotes": "Khách hàng đã kiểm tra và xác nhận đủ số lượng, chất lượng hàng hóa. Giao hàng đúng giờ."
}

Bảng Quyết định cho Quy trình Đối soát Công nợ Tự động

Bảng quyết định này diễn giải các quy tắc nghiệp vụ (Business Rules) để xử lý payload từ NovaShip. Mỗi dòng đại diện cho một kịch bản có thể xảy ra và hành động mà hệ thống ERP phải thực hiện, đảm bảo tính nhất quán và đầy đủ trong xử lý.

Mã Quy tắc (Rule ID)	Điều kiện 1: delivery.status	Điều kiện 2: quantityDelivered vs quantityExpected	Điều kiện 3: recipientSignatureId	Hành động (Action)	Traceability
BR-NF-AR-001	COMPLETED	Tất cả sản phẩm khớp	Tồn tại (Not Null)	1. Cập nhật trạng thái Hóa đơn (invoice.status) thành RECONCILED_OK. 2. Kích hoạt quy trình thanh toán.	REQ-NF-AR-001, AC-NF-AR-001.1, TC-NF-AR-001
BR-NF-AR-002	COMPLETED	Có ít nhất 1 sản phẩm không khớp (thiếu/thừa)	Tồn tại (Not Null)	1. Cập nhật trạng thái Hóa đơn thành DISCREPANCY_QUANTITY. 2. Tạo một ticket "Chênh lệch giao hàng" cho bộ phận Kế toán & Sales.	REQ-NF-AR-002, AC-NF-AR-002.1, TC-NF-AR-002
BR-NF-AR-003	REJECTED	(Không áp dụng)	(Không áp dụng)	1. Cập nhật trạng thái Hóa đơn thành DELIVERY_REJECTED. 2. Gửi thông báo khẩn đến bộ phận Sales và Kho vận.	REQ-NF-AR-003, AC-NF-AR-003.1, TC-NF-AR-003
BR-NF-AR-004	PARTIAL	Có ít nhất 1 sản phẩm quantityDelivered < quantityExpected	Tồn tại (Not Null)	1. Cập nhật trạng thái Hóa đơn thành DISCREPANCY_PARTIAL. 2. Gắn cờ chờ xử lý tạo bút toán ghi nợ (credit note) cho phần hàng thiếu.	REQ-NF-AR-002, AC-NF-AR-002.2, TC-NF-AR-004
BR-NF-AR-005	COMPLETED	Tất cả sản phẩm khớp	Không tồn tại (Null)	1. Cập nhật trạng thái Hóa đơn thành PENDING_SIGNATURE_VERIFICATION. 2. Gửi cảnh báo cho bộ phận Giám sát Giao nhận.	REQ-NF-AR-004, AC-NF-AR-004.1, TC-NF-AR-005

5. Tier 4 – Cổng Chất lượng BA Cấp cao

Cổng này dùng để rà soát tài liệu Khám phá và Ghi nhận Nhu cầu Nghiệp vụ (TMPL-DISC-001) trước khi đề xuất baseline. Mục tiêu là xác nhận tài liệu đủ chất lượng, rõ ràng, và an toàn để làm cơ sở cho các giai đoạn sau.

5.1. Danh mục Kiểm tra Chất lượng (Quality Checklist)

Senior BA sử dụng danh mục này để đánh giá tài liệu. Mỗi mục có tiêu chí Đạt, Hỏng, và hành động xử lý tương ứng.

ID	Hạng mục Kiểm tra	Tiêu chí "Đạt" (Pass Criteria)	Tiêu chí "Hỏng / Dừng" (Fail / Stop Criteria)	Hành động khi "Hỏng / Dừng"
QG-C-01	Tính đầy đủ (Completeness)	Mọi mục trong template đã được điền. Không còn placeholder <...> hoặc ghi chú TBD. Mọi phụ lục được tham chiếu đều tồn tại.	Thiếu thông tin trọng yếu (như mục tiêu, bên liên quan chính). Dữ liệu bị bỏ trống làm tắc nghẽn công việc của các nhóm sau (ví dụ: thiếu user story để đội phát triển ước tính).	Hỏng: Trả lại cho BA soạn thảo. Đánh dấu các phần còn thiếu và yêu cầu bổ sung trong vòng lặp tiếp theo.
QG-C-02	Tính nhất quán (Consistency)	Thuật ngữ được dùng thống nhất trong toàn bộ tài liệu và khớp với Từ điển Dữ liệu (CANONICAL_DATA_DICTIONARY). Sơ đồ quy trình (ví dụ: BPMN) khớp với mô tả bằng lời. Các quy tắc nghiệp vụ không mâu thuẫn nhau.	Dùng nhiều thuật ngữ khác nhau cho cùng một khái niệm (ví dụ: "Khách hàng" vs "Đối tác"). Logic trong sơ đồ mâu thuẫn với tiêu chí nghiệm thu (AC).	Hỏng: Liệt kê các điểm không nhất quán. Yêu cầu BA soạn thảo hợp nhất và chọn một nguồn chân lý (single source of truth) duy nhất.
QG-C-03	Tính kiểm thử được (Testability)	Mọi yêu cầu (REQ-) có Tiêu chí Nghiệm thu (Acceptance Criteria - AC) rõ ràng, cụ thể, đo lường được. Tester có thể dựa vào AC để viết test case mà không cần hỏi lại.	AC mơ hồ, mang tính chủ quan (ví dụ: "giao diện phải thân thiện", "hệ thống phải nhanh"). Không thể xác minh một cách khách quan là Đạt hay Hỏng.	Hỏng: Yêu cầu viết lại AC theo định dạng có cấu trúc (ví dụ: Gherkin Given-When-Then) hoặc theo mẫu hành vi người dùng cụ thể.
QG-C-04	Khả năng truy vết (Traceability)	Mọi yêu cầu (REQ-) có thể truy vết ngược về một nhu cầu nghiệp vụ hoặc mục tiêu đã nêu. Mọi quy tắc nghiệp vụ (BR-), AC, và thành phần dữ liệu có thể truy vết tới một yêu cầu cụ thể.	Tồn tại yêu cầu "mồ côi" không rõ nguồn gốc. Chuỗi truy vết bị đứt, không thể liên kết từ mục tiêu kinh doanh đến test case.	Hỏng: Yêu cầu BA soạn thảo lập Ma trận Truy vết Yêu cầu (Requirements Traceability Matrix - RTM). Gắn nhãn các yêu cầu thiếu liên kết.
QG-C-05	Thẩm quyền nguồn (Source Authority)	Mọi quy tắc nghiệp vụ (BR-) đều có trích dẫn nguồn (ví dụ: Luật Kế toán 88/2015/QH13, quyết định của Giám đốc Kinh doanh). Mọi quyết định được ghi nhận với đúng vai trò có thẩm quyền.	Quy tắc nghiệp vụ là do BA tự suy diễn mà không có nguồn xác minh. Giả định nghiệp vụ được trình bày như một sự thật đã được phê duyệt.	Hỏng: Gắn nhãn VERIFICATION_REQUIRED. Chuyển cho chủ sở hữu nghiệp vụ (Business Owner) hoặc chuyên gia tương ứng để xác nhận.
QG-C-06	Ranh giới & Tuân thủ (Boundaries & Compliance)	Các yêu cầu liên quan đến pháp lý (Luật Bảo vệ dữ liệu cá nhân), kế toán (Nghị định 123/2020/NĐ-CP), bảo mật (OWASP) được xác định rõ ràng và gắn nhãn cần xác minh từ chủ sở hữu chuyên môn.	Xử lý dữ liệu cá nhân nhạy cảm (PII) mà không tham chiếu luật. Đề xuất luồng nghiệp vụ vi phạm quy định kế toán hoặc an toàn thực phẩm.	DỪNG (STOP): Dừng ngay lập tức mọi công việc liên quan. Chuyển vấn đề cho chủ sở hữu Pháp lý, Kế toán hoặc Bảo mật. Đây là rủi ro cao, không được tiếp tục cho đến khi có kết luận chính thức.
QG-C-07	Tác động thay đổi (Change Impact)	Tài liệu xác định rõ các hệ thống, quy trình, và vai trò người dùng hiện tại sẽ bị ảnh hưởng bởi thay đổi. Mức độ tác động được mô tả (ví dụ: cần đào tạo lại, cần di chuyển dữ liệu).	Bỏ qua các hệ thống tích hợp. Giả định thay đổi chỉ ảnh hưởng đến một module mà không xem xét tác động lan truyền.	Hỏng: Yêu cầu thực hiện phân tích tác động thay đổi (Impact Analysis). Tổ chức buổi làm việc với các chủ sở hữu hệ thống và quy trình bị ảnh hưởng.

5.2. Tiêu chí Quyết định Tổng thể

Dựa trên kết quả từ danh mục kiểm tra ở mục 5.1, Senior BA đưa ra một trong các quyết định sau:

• PASS (Đạt): Tất cả các hạng mục kiểm tra đều đạt. Tài liệu được xem là đủ chất lượng để đề xuất đưa vào trạng thái BASELINED.
• REWORK (Làm lại): Có ít nhất một hạng mục bị "Hỏng", nhưng không có mục nào bị "Dừng". Tài liệu được trả về cho BA soạn thảo cùng với danh sách các điểm cần sửa.
• STOP (Dừng): Có ít nhất một hạng mục bị "Dừng". Mọi công việc trên tài liệu này phải tạm dừng. Vấn đề phải được chuyển khẩn cấp lên các bên liên quan có thẩm quyền (ví dụ: Pháp lý, Bảo mật, Quản lý cấp cao) để giải quyết. Không tiến hành bất kỳ thay đổi nào cho đến khi có chỉ đạo rõ ràng.

Danh mục kiểm tra chất lượng (Quality Gate Checklist)

Danh mục này định nghĩa các tiêu chí để một Senior Business Analyst (BA) xem xét và đánh giá chất lượng của tài liệu "Ghi nhận Khám phá và Nhu cầu nghiệp vụ" trước khi đề xuất baseline. Mỗi hạng mục có tiêu chí rõ ràng để xác định trạng thái Đạt (Pass), Lỗi cần sửa (Fail), hoặc Dừng để làm rõ (Stop/Escalate).

Hạng mục kiểm tra	Tiêu chí kiểm tra & Điều kiện Đạt/Lỗi/Dừng	Nguồn tham chiếu / Cơ sở lý luận
Tính đầy đủ (Completeness)	Đạt: Mọi mục trong template Tier 2 đều được điền đầy đủ tại Tier 3. Không có placeholder <...> hoặc ghi chú "TBD". Mọi yêu cầu đều có định danh duy nhất. Lỗi: Có mục còn trống hoặc chứa placeholder. Dừng: Thiếu một phần thông tin cốt lõi (vd: Business Owner) làm cho việc xem xét các mục khác không thể tiếp tục.	BABOK Guide: Requirements Life Cycle Management. ISO/IEC/IEEE 29148:2018.
Tính nhất quán (Consistency)	Đạt: Thuật ngữ nghiệp vụ, định danh dữ liệu thống nhất và khớp với CANONICAL_DATA_DICTIONARY. Logic quy tắc nghiệp vụ không mâu thuẫn với CANONICAL_BUSINESS_RULES. Lỗi: Sử dụng nhiều tên cho cùng một khái niệm (vd: "Khách hàng" vs. "Đối tác"). Quy tắc mâu thuẫn nhau. Dừng: Phát hiện mâu thuẫn giữa yêu cầu trong tài liệu và nguồn canonical (từ điển dữ liệu, catalog quy tắc).	CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES của corpus.
Tính khả kiểm (Testability)	Đạt: Mỗi yêu cầu và tiêu chí chấp nhận (Acceptance Criteria) được viết đủ rõ ràng, cụ thể, không mơ hồ để có thể thiết kế một hoặc nhiều ca kiểm thử (test case) để xác minh. Lỗi: Yêu cầu mang tính chủ quan (vd: "giao diện phải thân thiện") mà không có tiêu chí đo lường cụ thể (vd: "hoàn thành tác vụ X trong dưới 30 giây"). Dừng: Yêu cầu cốt lõi không thể kiểm thử về mặt kỹ thuật hoặc logic.	ISTQB CTFL Syllabus: Test Analysis and Design.
Khả năng truy vết (Traceability)	Đạt: Mọi yêu cầu (REQ-), quy tắc (BR-), mục tiêu (GOAL-) đều có thể truy vết ngược về một nhu cầu nghiệp vụ cấp cao hơn hoặc một nguồn bên ngoài (vd: luật định). Mọi định danh đều tồn tại trong TRACEABILITY_ID_REGISTRY. Lỗi: Yêu cầu "mồ côi", không rõ nguồn gốc. ID không có trong registry. Dừng: Một yêu cầu có tác động lớn nhưng không truy vết được về một mục tiêu chiến lược hoặc bên liên quan có thẩm quyền.	TRACEABILITY_ID_REGISTRY. BABOK Guide: Traceability.
Thẩm quyền nguồn (Source Authority)	Đạt: Các yêu cầu bắt nguồn từ luật pháp, quy định kế toán, hoặc chính sách an toàn thực phẩm phải ghi rõ nguồn và đi kèm nhãn "Cần xác minh" (Verification Required) bởi vai trò có thẩm quyền (Pháp chế, Kế toán). Lỗi: Trích dẫn yêu cầu pháp lý nhưng không ghi rõ điều khoản/luật. Dừng: Diễn giải một quy định pháp luật như một yêu cầu hệ thống chắc chắn mà không có nhãn "Cần xác minh", có nguy cơ gây hiểu nhầm về tính tuân thủ.	Luật Bảo vệ dữ liệu cá nhân, Luật Kế toán, Nghị định 123/2020/NĐ-CP.
Quyền sở hữu (Ownership)	Đạt: Mỗi nhóm yêu cầu hoặc quy tắc nghiệp vụ quan trọng đều xác định rõ ràng "Business Owner" – người có quyền quyết định cuối cùng về nội dung và sự thay đổi của nó. Lỗi: Thiếu thông tin Business Owner cho một yêu cầu chức năng chính. Dừng: Có sự tranh chấp hoặc không rõ ràng về quyền sở hữu đối với một yêu cầu có ảnh hưởng liên phòng ban.	BABOK Guide: Stakeholder Analysis.
Ranh giới (Boundaries)	Đạt: Phân định rõ các yêu cầu thuộc về an ninh (Security), quyền riêng tư (Privacy), pháp lý (Legal), kế toán (Accounting). Dữ liệu nhạy cảm được đánh dấu. Yêu cầu bảo mật có tham chiếu đến tiêu chuẩn (vd: OWASP). Lỗi: Một yêu cầu liên quan đến thanh toán nhưng không được đánh dấu để vai trò Kế toán xem xét. Dừng: Một yêu cầu đề xuất xử lý dữ liệu cá nhân nhưng không tham chiếu đến Luật Bảo vệ dữ liệu cá nhân hoặc không có đánh giá tác động ban đầu.	Luật Bảo vệ dữ liệu cá nhân, OWASP ASVS, OWASP API Security Top 10.
Tác động thay đổi (Change Impact)	Đạt: Tài liệu mô tả ở mức độ cao các hệ thống, quy trình hoặc nhóm người dùng khác có thể bị ảnh hưởng bởi các yêu cầu được đề xuất. Lỗi: Một yêu cầu thay đổi lớn về quy trình kho mà không đề cập đến tác động tới bộ phận kế toán hoặc bán hàng. Dừng: Yêu cầu có khả năng gây gián đoạn hoạt động kinh doanh trên diện rộng nhưng phần phân tích tác động bị bỏ trống.	BABOK Guide: Strategy Analysis.

Áp dụng Checklist Chất lượng cho Case Study Nova Foods

Bảng dưới đây ghi nhận kết quả áp dụng checklist chất lượng lên ví dụ hoàn chỉnh của Nova Foods tại Mục 3 và Mục 4. Ghi nhận này không cấu thành phê duyệt. Dữ liệu và định danh là mô phỏng.

Hạng mục Kiểm tra	Kết quả	Ghi nhận & Bằng chứng (Dựa trên dữ liệu mô phỏng Nova Foods tại Mục 3 và 4)
Tính Toàn vẹn (Completeness)	ĐẠT	Mọi trường trong mẫu Tier 2 được điền đủ ở Tier 3. Yêu cầu REQ-NF-008 (Quản lý Khuyến mãi) có đủ bối cảnh, quy tắc nghiệp vụ liên quan (BR-NF-012), và tiêu chí chấp nhận. Không có mục nào ghi TBD hay bỏ trống.
Tính Nhất quán (Consistency)	ĐẠT, CÓ LƯU Ý	Thuật ngữ "Lô sản phẩm" được dùng nhất quán. Tuy nhiên, REQ-NF-005 dùng "PO" trong khi REQ-NF-006 dùng "Đơn Mua Hàng". Hành động: Thống nhất dùng "Đơn Mua Hàng (PO)" lần đầu, sau đó dùng "PO". Tác động nhỏ.
Tính Khả kiểm (Testability)	ĐẠT	Tiêu chí chấp nhận (AC - Acceptance Criteria) cho REQ-NF-015 (Truy xuất nguồn gốc) có thể kiểm thử được. Ví dụ: AC-NF-015-01: "Hệ thống phải trả về lịch sử di chuyển của lô [LOT-ID] trong vòng 5 giây". Các biến số cụ thể, đo lường được. Điều này tuân thủ nguyên tắc từ syllabus ISTQB CTFL.
Tính Truy vết (Traceability)	ĐẠT	Liên kết truy vết hai chiều (bidirectional traceability) được thiết lập. Ví dụ: STAKE-CONCERN-04 (Quan ngại của Giám đốc Vận hành) -> REQ-NF-015 (Yêu cầu hệ thống) -> BR-NF-007 (Quy tắc nghiệp vụ). ID TRACE-NF-STAKE-04-REQ-015 được ghi nhận đúng cấu trúc trong TRACEABILITY_ID_REGISTRY.
Thẩm quyền Nguồn (Source Authority)	CẦN XÁC MINH	REQ-NF-015 tham chiếu đúng Luật An toàn thực phẩm 55/2010/QH12 làm nguồn. Tốt. Nhưng việc diễn giải điều luật thành yêu cầu hệ thống "phải hoàn tất truy xuất trong 4 giờ" là diễn giải của BA. Hành động: Cần xác nhận diễn giải này với vai trò Legal Owner trước khi baseline.
Quyền sở hữu (Ownership)	ĐẠT	Mỗi yêu cầu (REQ-NF-*) đều có Business Owner được chỉ định rõ ràng. Ví dụ, REQ-NF-011 (Báo cáo Tồn kho) có Owner là "Giám đốc Chuỗi Cung ứng". Điều này đảm bảo có người ra quyết định khi có thay đổi phạm vi.
Ranh giới (Boundaries)	CẦN LÀM RÕ	REQ-NF-021 (Quản lý thông tin nhà cung cấp) xác định Số tài khoản ngân hàng là dữ liệu nhạy cảm (D-CLASS-CONFIDENTIAL), tham chiếu Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15. Tốt. Nhưng yêu cầu chỉ nói "phải được mã hóa", không rõ mã hóa khi lưu trữ (at-rest) hay trên đường truyền (in-transit). Đây là quyết định kiến trúc. Hành động: Chuyển cho Architect để làm rõ, tham chiếu OWASP ASVS V4.3 (Data Protection).
Tác động Thay đổi (Change Impact)	CẦN CẢI THIỆN	Tài liệu xác định các phòng ban bị ảnh hưởng (Kho, Mua hàng, Kế toán). Nhưng chưa lượng hóa tác động. Ví dụ: "giảm thời gian làm báo cáo" nhưng không ước tính lợi tức đầu tư (ROI - Return on Investment). Hành động: Bổ sung ước tính sơ bộ để giúp Business Owner đánh giá ROI tốt hơn. Không phải lỗi chặn (blocker).

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

Mục này kiểm tra tính nhất quán của tài liệu này (TMPL-DISC-001_DISCOVERY_AND_BUSINESS_NEED_CAPTURE) so với các artifact quản trị trung tâm trong corpus dự án Nova Foods. Mục đích là để phát hiện và sửa chữa các mâu thuẫn, đảm bảo nguyên tắc chỉ có một nguồn chân lý (single source of truth) được duy trì. Mỗi tài liệu không tồn tại độc lập; nó phải khớp với kiến trúc tổng thể. Việc kiểm tra chéo này là một bước kiểm soát chất lượng quan trọng trước khi chuyển giao cho các bên liên quan khác (ví dụ: đội phát triển, đội kiểm thử).

Bảng dưới đây ghi lại các hạng mục kiểm tra, artifact được dùng để đối chiếu, kết quả phân tích, và trạng thái cuối cùng.

Hạng mục kiểm tra	Artifact đối chiếu (Nguồn chân lý)	Kết quả & Bằng chứng	Trạng thái
Metadata quản trị	/01-curriculum/TEMPLATE_MANIFEST.md	Metadata của tài liệu này (Artifact ID: TMPL-DISC-001, Version: v0.9.0, Status: IN_REVIEW) khớp hoàn toàn với mục tương ứng trong bản kê template (TEMPLATE_MANIFEST). Không có xung đột về phiên bản hay trạng thái, đảm bảo tính toàn vẹn quản trị của corpus.	ĐẠT
Định dạng và Đăng ký ID	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Các định danh truy vết được sử dụng trong tài liệu này (ví dụ: REQ-NF-015, BR-NF-007, STAKE-NF-04) tuân thủ đúng cấu trúc PREFIX-{PROJECT}-{NNN} đã được định nghĩa trong TRACEABILITY_ID_REGISTRY.md. Điều này đảm bảo khả năng truy vết (traceability) từ yêu cầu đến các thành phần khác không bị phá vỡ.	ĐẠT
Định nghĩa Quy tắc nghiệp vụ (Business Rule)	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Phát hiện mâu thuẫn. Mục 3 của tài liệu này định nghĩa BR-NF-007 là "Hóa đơn phải có chữ ký số của người bán". Tuy nhiên, nguồn canonical CANONICAL_BUSINESS_RULES.md định nghĩa quy tắc này là "Hóa đơn điện tử phải tuân thủ Nghị định 123/2020/NĐ-CP". Định nghĩa trong tài liệu này là một diễn giải quá hẹp, không bao quát hết các yêu cầu pháp lý của Nghị định, gây rủi ro tuân thủ.	MÂU THUẪN
Định nghĩa Thuộc tính dữ liệu	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Nhất quán. Mục 5 của tài liệu này đề cập Số tài khoản ngân hàng là dữ liệu nhạy cảm (D-CLASS-CONFIDENTIAL). Từ điển dữ liệu canonical (CANONICAL_DATA_DICTIONARY) cũng xác nhận phân loại này và liên kết nó với nguồn Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15. Không có sai lệch về phân loại dữ liệu.	ĐẠT
Tương thích với các chương/template sau (Downstream Consumers)	/01-curriculum/CHAPTER_MANIFEST.md	Đạt. Tài liệu này cung cấp đầy đủ các yêu cầu (REQ-NF-*) và tiêu chí chấp nhận, là đầu vào cần thiết cho HB-BA-08 ("From Requirements to Specifications") và các template đặc tả chi tiết. Nó tạo ra một cơ sở kiểm thử (test basis) rõ ràng cho các hoạt động trong HB-QA-02, khớp với kiến trúc chương trình học.	ĐẠT

Tổng kết và Hành động: Bốn trên năm hạng mục kiểm tra đạt. Một mâu thuẫn nghiêm trọng được phát hiện với quy tắc nghiệp vụ BR-NF-007. Tài liệu này không được phép diễn giải lại một quy tắc đã được định nghĩa ở nguồn canonical.

Hành động khắc phục: Cập nhật ngay lập tức mô tả của BR-NF-007 trong tài liệu này để tham chiếu trực tiếp đến định nghĩa canonical ("Tuân thủ Nghị định 123/2020/NĐ-CP"), thay vì diễn giải lại. Điều này duy trì một nguồn chân lý duy nhất và tránh rủi ro cho các nhóm làm việc sau này.

Danh sách các vấn đề mở, giả định và hạng mục cần xác minh

Bảng này ghi nhận mọi điểm chưa được giải quyết tại thời điểm 2026-08-07. Việc ghi nhận này đảm bảo không có giả định hoặc diễn giải chưa được xác minh nào bị chuyển giao sang giai đoạn sau như một yêu cầu đã được phê duyệt. Tài liệu này giữ trạng thái IN_REVIEW cho đến khi tất cả các mục "Cao" và "Trung bình" trong bảng này được giải quyết và có bằng chứng ghi nhận.

ID Vấn đề	Loại	Mô tả chi tiết	Artifact/ID bị ảnh hưởng	Mức độ ảnh hưởng	Owner chịu trách nhiệm	Hành động tiếp theo
OI-DISC-001-01	Cần xác minh	Yêu cầu RQ-NF-FN-003 (truy xuất nguồn gốc) và RQ-NF-FN-004 (thu hồi sản phẩm) tham chiếu Luật An toàn thực phẩm và Nghị định 356/2025/NĐ-CP. Diễn giải này do BA thực hiện và chưa có xác nhận từ bộ phận pháp chế.	RQ-NF-FN-003, RQ-NF-FN-004	Cao. Rủi ro pháp lý nếu triển khai sai diễn giải, dẫn đến phạt hoặc đình chỉ hoạt động.	Legal Owner	BA phải đóng gói các yêu cầu này cùng nguồn tham chiếu và gửi cho Legal Owner để xác minh và phê duyệt bằng văn bản.
OI-DISC-001-02	Giả định	Giả định rằng hệ thống Kế toán nội bộ cũ (LEGACY-ACC-SYS) có API ổn định để tích hợp dữ liệu Hóa đơn điện tử theo yêu cầu RQ-NF-ACC-007. Khả năng kỹ thuật chưa được kiểm chứng.	RQ-NF-ACC-007	Trung bình. Nếu không có API, cần giải pháp thay thế (middleware, nhập liệu thủ công), ảnh hưởng đến chi phí và tiến độ dự án.	Technical Architect	Technical Architect thực hiện một Spike (nghiên cứu kỹ thuật giới hạn thời gian) để đánh giá khả năng tích hợp và đề xuất giải pháp kiến trúc trong 5 ngày làm việc.
OI-DISC-001-03	Vấn đề Mở	Quy trình BP-NF-SAL-002 (Xử lý hàng bán bị trả lại) chưa có sự đồng thuận giữa Kinh doanh và Kho vận về điều kiện chấp nhận hàng trả (ví dụ: lý do, tình trạng bao bì).	BP-NF-SAL-002, UC-NF-SAL-004	Trung bình. Gây mâu thuẫn trong logic cấu hình ERP cho module Quản lý kho và Bán hàng, có thể dẫn đến rework sau khi go-live.	Sales Business Owner, Warehouse Business Owner	BA tổ chức một Workshop (buổi làm việc tập trung) với hai Business Owner để thống nhất quy trình. Cập nhật BP-NF-SAL-002 trong vòng 7 ngày làm việc.
OI-DISC-001-04	Cần xác minh	Định nghĩa cho trường dữ liệu Customer.loyaltyStatus trong CANONICAL_DATA_DICTIONARY (ví dụ: Bronze, Silver, Gold) được đề xuất nhưng chưa có phê duyệt chính thức từ Business Owner. Yêu cầu RQ-NF-MKT-001 đang phụ thuộc vào trường này.	CANONICAL_DATA_DICTIONARY, RQ-NF-MKT-001	Thấp. Rủi ro thấp, dễ dàng cập nhật. Tuy nhiên, cần hoàn tất để đảm bảo tính nhất quán của dữ liệu và logic khuyến mãi.	Marketing Business Owner	BA gửi định nghĩa đề xuất kèm tiêu chí phân hạng cho Marketing Business Owner để review và xác nhận qua email trong 3 ngày làm việc.

Quy tắc Chuyển giao, Lan truyền Thay đổi và Ranh giới Thẩm quyền

Tài liệu này, với trạng thái IN_REVIEW, được chuyển giao có kiểm soát cho các bên liên quan để lấy ý kiến phản hồi, chuẩn bị cho các giai đoạn tiếp theo (như phân tích kỹ thuật, viết kịch bản kiểm thử), nhưng không đồng nghĩa với việc phê duyệt để triển khai. Trạng thái IN_REVIEW khẳng định tài liệu đã hoàn chỉnh về mặt cấu trúc và đủ thông tin để xem xét, chứ không phải đã được xác nhận là đúng hoặc được chấp thuận cuối cùng. Mọi hoạt động phải tuân thủ nghiêm ngặt các ranh giới thẩm quyền và quy trình lan truyền thay đổi dưới đây.

Bảng Phân định Ranh giới Thẩm quyền khi Chuyển giao

Bảng này xác định rõ các hành động được phép và bị cấm đối với từng vai trò khi tương tác với tài liệu ở trạng thái IN_REVIEW. Việc tuân thủ bảng này là bắt buộc để bảo toàn tính toàn vẹn quản trị và tránh các quyết định vượt cấp.

Vai trò	Hành động được phép trong phạm vi thẩm quyền	Hành động bị cấm (Vượt thẩm quyền)
IT Business Analyst (Owner tài liệu)	Xác nhận tài liệu hoàn chỉnh về cấu trúc và có thể truy vết tới các nguồn đã nêu. Điều phối quá trình review. Tổng hợp các vấn đề mở và yêu cầu xác minh. Ghi nhận quyết định từ các vai trò có thẩm quyền.	Tự phê duyệt yêu cầu nghiệp vụ. Tự xác nhận tính tuân thủ pháp lý, tài chính hoặc bảo mật. Cam kết về giải pháp kỹ thuật hoặc khối lượng công việc triển khai. Ghi nhận một yêu cầu là "đã phê duyệt" mà không có bằng chứng từ Business Owner.
Business Owner / Subject Matter Expert (SME)	Xác minh tính chính xác và đầy đủ của các quy trình và quy tắc nghiệp vụ mô tả trong tài liệu. Phê duyệt hoặc từ chối các yêu cầu nghiệp vụ (business requirements) thuộc phạm vi của mình.	Quyết định về kiến trúc hệ thống, lựa chọn công nghệ, hoặc mức độ nỗ lực phát triển. Phê duyệt các yêu cầu không thuộc lĩnh vực của mình.
Technical Architect / Lead Developer	Đánh giá tính khả thi về mặt kỹ thuật. Ước tính sơ bộ khối lượng công việc. Đề xuất các phương án giải pháp kỹ thuật dựa trên các yêu cầu được trình bày.	Thay đổi hoặc diễn giải lại một quy tắc nghiệp vụ. Cam kết triển khai một yêu cầu chưa được Business Owner phê duyệt. Bỏ qua các yêu cầu phi chức năng (non-functional requirements) như bảo mật hoặc hiệu năng.
QA Lead / Tester	Sử dụng tài liệu làm cơ sở kiểm thử (test basis) để soạn thảo kế hoạch kiểm thử (test plan) và kịch bản kiểm thử (test cases) sơ bộ. Báo cáo sự không nhất quán, mơ hồ hoặc thiếu sót trong các yêu cầu.	Định nghĩa các tiêu chí chấp nhận (acceptance criteria) mới không có trong tài liệu. Thực hiện kiểm thử chấp nhận (acceptance testing) và ký duyệt (sign-off) một chức năng khi tài liệu còn ở trạng thái IN_REVIEW.
Legal / Compliance Owner	Xem xét và xác nhận các diễn giải liên quan đến pháp luật (ví dụ: Luật Bảo vệ dữ liệu cá nhân, Luật Kế toán) và các quy định tuân thủ khác được đề cập trong tài liệu.	Phê duyệt quy trình vận hành nghiệp vụ. Quyết định về luồng dữ liệu kỹ thuật.

Quy trình Lan truyền Thay đổi (Change Propagation) trong Trạng thái IN_REVIEW

Mọi thay đổi đối với tài liệu này trong khi vẫn giữ trạng thái IN_REVIEW phải tuân theo quy trình được kiểm soát để đảm bảo tất cả các bên liên quan đều làm việc trên thông tin nhất quán.

1. Đề xuất Thay đổi: Mọi đề xuất thay đổi phải được ghi nhận vào bảng "Danh sách các vấn đề mở" (Mục 6.2), nêu rõ ID của hạng mục bị ảnh hưởng, lý do thay đổi, và tác động dự kiến.
2. Phân loại và Chuyển hướng: Owner tài liệu (IT Business Analyst) phân loại đề xuất (sửa lỗi nhỏ, làm rõ, thay đổi phạm vi) và chuyển đến đúng vai trò có thẩm quyền để xem xét (ví dụ: thay đổi quy tắc nghiệp vụ phải được Business Owner xem xét).
3. Ghi nhận Quyết định: Quyết định (chấp thuận/từ chối) của vai trò có thẩm quyền phải được ghi nhận lại, kèm theo lý do.
4. Cập nhật Tài liệu: Nếu được chấp thuận, Owner tài liệu sẽ cập nhật nội dung. Lịch sử thay đổi của tài liệu phải được cập nhật tương ứng, ghi rõ nội dung thay đổi và người phê duyệt. Những thay đổi quan trọng có thể yêu cầu tăng phiên bản phụ (ví dụ: từ v0.9.0 lên v0.9.1).
5. Thông báo: Sau khi cập nhật, Owner tài liệu có trách nhiệm thông báo cho tất cả các bên đã nhận bản review trước đó, chỉ rõ phiên bản mới và các điểm thay đổi chính để đảm bảo không ai sử dụng phiên bản đã lỗi thời. Việc chuyển giao phải kèm thông báo rõ ràng: "Đây là phiên bản cập nhật, dùng để review. Tài liệu vẫn ở trạng thái IN_REVIEW và chưa được baseline."