Bỏ qua

/03-templates/TMPL-REL-001_release-notes.md — Mẫu Ghi chú Phát hành (Release Notes Template)

Metadata quản trị (governance metadata) dưới đây là nguồn xác thực duy nhất về định danh, phiên bản, trạng thái và các quy tắc kiểm soát của mẫu tài liệu này trong corpus học liệu Nova Foods. Mọi bản sao hoặc phiên bản không tham chiếu đến metadata này đều không được kiểm soát.

Trường kiểm soát Giá trị Diễn giải và Hướng dẫn cho người học
Artifact ID TMPL-REL-001 Định danh duy nhất: Đây là mã định danh không thể thay đổi của mẫu tài liệu này. Khi một tài liệu khác cần tham chiếu đến mẫu này, nó sẽ dùng TMPL-REL-001 để đảm bảo tính chính xác và khả năng truy vết (traceability).
Tên tệp được kiểm soát /03-templates/TMPL-REL-001_release-notes.md Vị trí nguồn: Đây là đường dẫn chính thức và duy nhất của tệp gốc trong cấu trúc thư mục của dự án. Mọi thay đổi phải được thực hiện trên tệp này.
Trạng thái (Status) IN_REVIEW Giai đoạn vòng đời: IN_REVIEW có nghĩa là tài liệu đang trong quá trình xem xét, chưa phải là phiên bản cuối cùng và có thể thay đổi. Trạng thái này không đồng nghĩa với APPROVED (đã phê duyệt) hay BASELINED (đã được chốt làm phiên bản nền).
Phiên bản (Version) v0.9.0 Dấu ấn thời gian: Phiên bản v0.9.0 đánh dấu một bộ nội dung cụ thể tại một thời điểm. Mọi thay đổi quan trọng sau khi được phê duyệt sẽ dẫn đến một phiên bản mới (ví dụ: v1.0.0).
Owner Principal IT Business Analyst / Technical Curriculum Author Vai trò chịu trách nhiệm: Owner chịu trách nhiệm duy trì tính toàn vẹn của cấu trúc và metadata của mẫu này, không phải nội dung nghiệp vụ cụ thể điền vào mẫu.
Giới hạn thẩm quyền Owner Owner không có quyền tự phê duyệt nội dung, xác nhận yêu cầu nghiệp vụ, diễn giải pháp lý, quyết định kế toán, hoặc cho phép sử dụng trong môi trường production. Phân định quyền hạn: Điều này làm rõ rằng vai trò Owner chỉ mang tính quản trị tài liệu. Các quyết định nghiệp vụ quan trọng phải đến từ các vai trò có thẩm quyền tương ứng (Business Owner, Legal, v.v.).
Ngày cập nhật gần nhất 2026-08-07 Ngày mà metadata hoặc cấu trúc của mẫu tài liệu được cập nhật lần cuối, theo múi giờ Asia/Ho_Chi_Minh.
Lịch sử thay đổi v0.9.0 (2026-08-07): Khởi tạo mẫu tài liệu ở trạng thái IN_REVIEW. Thiết lập metadata quản trị, cấu trúc 4 tầng và các ranh giới sử dụng. Nhật ký thay đổi: Ghi lại những thay đổi quan trọng qua từng phiên bản, giúp mọi người hiểu tài liệu đã phát triển như thế nào.
Tham chiếu Case study Nova Foods Trading & Manufacturing — mô phỏng giáo dục; chỉ sử dụng dữ liệu tổng hợp (synthetic data). Bối cảnh áp dụng: Mọi ví dụ trong mẫu này sử dụng bối cảnh của công ty giả định Nova Foods cho mục đích học tập.
Phân loại Artifact Controlled Template Đây là một "mẫu tài liệu được kiểm soát", nghĩa là nó được quản lý phiên bản và thay đổi một cách chặt chẽ để đảm bảo tính nhất quán trong toàn bộ dự án.

Ranh giới Dữ liệu Mô phỏng và Miễn trừ Trách nhiệm

Tài liệu này và tất cả các ví dụ liên quan đến "Nova Foods" đều hoàn toàn mang tính chất mô phỏng cho mục đích giáo dục. Mọi tên công ty, dữ liệu, quy trình, và số liệu tài chính đều là dữ liệu tổng hợp (synthetic data), không đại diện cho bất kỳ tổ chức hoặc cá nhân có thật nào. Việc sử dụng mẫu này không cấu thành tư vấn pháp lý, kế toán hay nghiệp vụ. Người dùng chịu trách nhiệm đảm bảo nội dung cuối cùng tuân thủ các quy định và chính sách thực tế tại tổ chức của mình.

1. Tier 1 – Metadata, Purpose, and Governance

Metadata Giá trị Quy tắc quản trị
Artifact ID TMPL-REL-001 Định danh ổn định của template.
Filename /03-templates/TMPL-REL-001_release-notes.md Đường dẫn canonical của artifact nguồn.
Status IN_REVIEW Artifact đang được rà soát. Status này không xác nhận baseline hoặc phê duyệt.
updated Được ghi trong bảng Change History tại phần đầu template khi Owner hợp nhất thay đổi được review. Owner phải cập nhật giá trị updated cùng thay đổi phiên bản và lịch sử thay đổi. Thiếu updated làm mất khả năng xác định thời điểm quản trị gần nhất của template.

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

Tài liệu này xác định mục đích, quy tắc sử dụng và các vai trò liên quan đến template Ghi chú phát hành (Release Notes). Mục tiêu là đảm bảo mọi thay đổi trong hệ thống hoặc tài liệu của dự án Nova Foods được truyền thông một cách nhất quán, có kiểm soát và có thể truy vết được.

Mục đích chính: * Chuẩn hóa giao tiếp: Tạo một định dạng duy nhất để thông báo về các phiên bản mới của phần mềm, tài liệu hoặc các artifact được kiểm soát khác. * Cung cấp bằng chứng: Ghi nhận chính thức rằng một tập hợp các thay đổi đã được hoàn thành, kiểm thử và sẵn sàng để các bên liên-quan (stakeholders) xem xét hoặc sử dụng. * Hỗ trợ truy vết (Traceability): Liên kết rõ ràng từ phiên bản sản phẩm đến các yêu cầu, quy tắc nghiệp vụ, và mục trong backlog đã được hiện thực hóa hoặc sửa lỗi. Điều này là nền tảng của quản lý yêu cầu theo BABOK Guide.

Phạm vi áp dụng:

Khi nào SỬ DỤNG Khi nào KHÔNG SỬ DỤNG
Phát hành phiên bản mới của một artifact đã được baseline (ví dụ: BRD, API-SPEC, DATA-DICT). Gửi báo cáo tiến độ dự án hoặc cập nhật trạng thái không chính thức.
Thông báo một gói tính năng (feature), sửa lỗi (bug fix) hoặc thay đổi đã vượt qua QA. Ghi biên bản họp (Meeting Minutes) hoặc thảo luận các ý tưởng ban đầu.
Cần một bản ghi có kiểm soát về những gì đã được bàn giao cho người dùng hoặc các đội khác. Thay thế cho tài liệu nguồn. Ghi chú phát hành chỉ tóm tắt, không chứa toàn bộ chi tiết.
Kích hoạt các hoạt động tiếp theo như Kiểm thử Chấp nhận của Người dùng (UAT), đào tạo hoặc triển khai. Yêu cầu thay đổi. Yêu cầu thay đổi phải tuân theo quy trình quản lý thay đổi riêng.

Ma trận Quản trị (Governance Matrix):

Thuộc tính Diễn giải và Quy tắc
Chủ sở hữu (Owner) Vai trò chịu trách nhiệm điền thông tin và phát hành một bản ghi cụ thể theo template này (ví dụ: Business Analyst sở hữu Ghi chú phát hành cho một BRD mới). Owner của bản ghi này không có thẩm quyền thay đổi template gốc.
Đối tượng sử dụng (Consumers) Các vai trò nhận và sử dụng thông tin: Quản lý Dự án (Project Manager), Đội Phát triển (Dev Team), Đội Kiểm thử (QA Team), Chủ sở hữu Nghiệp vụ (Business Owner), Đội Vận hành (Ops), Đội Hỗ trợ (Support).
Điều kiện tiên quyết (Prerequisites) 1. Artifact nguồn (ví dụ: TMPL-BRD-001) phải ở trạng thái BASELINED.
2. Số phiên bản mới đã được cấp phát theo quy tắc quản lý phiên bản của dự án.
3. Có bằng chứng các thay đổi đã được xác minh (ví dụ: biên bản nghiệm thu QA).
Artifact đầu ra (Downstream Artifacts) Thông báo phát hành, cập nhật Kế hoạch Kiểm thử (Test Plan), cập nhật Tài liệu Hướng dẫn Người dùng (User Guide), hoặc Yêu cầu Triển khai (Deployment Request).
Thẩm quyền (Authority) Bản ghi này xác nhận việc truyền thông về một thay đổi đã được phê duyệt. Nó không tự cấp thẩm quyền cho thay đổi đó. Thẩm quyền thực sự đến từ quy trình phê duyệt và baseline của artifact nguồn.
Leo thang (Escalation) Mọi tranh chấp về tính chính xác của nội dung phải được leo thang đến Owner của artifact nguồn. Nếu có mâu thuẫn, artifact nguồn (source artifact) luôn được coi là nguồn chân lý (source of truth). Quy trình leo thang tuân thủ theo 01-curriculum/TRACEABILITY_ID_REGISTRY.md.

Định danh Canonical, Nguồn gốc và Nghĩa vụ Kiểm soát Thay đổi

Template này được quản lý chặt chẽ trong corpus học liệu Nova Foods. Mọi tham chiếu, sử dụng hoặc sửa đổi phải tuân thủ các định danh và quy tắc dưới đây để đảm bảo tính nhất quán và khả năng truy vết nguồn gốc (traceability).

Bảng 1: Định danh và Đăng ký Canonical

Bảng này xác định danh tính duy nhất của template trong hệ thống quản trị của corpus.

Trường Quản trị Giá trị Canonical Diễn giải
Artifact ID TMPL-REL-001 Định danh duy nhất, không thay đổi của template. Sử dụng ID này trong mọi liên kết traceability.
Tên tệp Canonical /03-templates/TMPL-REL-001_release-notes.md Đường dẫn tệp gốc được kiểm soát. Mọi bản sao hoặc xuất bản khác đều không phải là nguồn chân lý (source of truth).
Đăng ký tại Manifest /01-curriculum/TEMPLATE_MANIFEST.md Template này được chính thức đăng ký và quản lý trong danh mục template tổng của curriculum.
Registry Định danh /01-curriculum/TRACEABILITY_ID_REGISTRY.md ID TMPL-REL-001 được cấp phát và quản lý bởi registry định danh của corpus.
updated Bảng Change History tại phần đầu template Trường metadata bắt buộc phản ánh lần cập nhật quản trị gần nhất. Owner cập nhật trường này khi thay đổi được review và hợp nhất; trường này không thay thế version hoặc bằng chứng phê duyệt.

Bảng 2: Liên kết Nguồn gốc và Phụ thuộc

Bảng này ánh xạ template với các nguồn tri thức, các học phần liên quan và các artifact khác trong chuỗi công việc của Business Analyst.

Hạng mục Liên kết Tham chiếu Canonical Mục đích và Phạm vi Liên kết
Nguồn lý thuyết BA /00-research/00_SOURCE_MAP.md Cấu trúc và nội dung của Release Notes tuân thủ các good practice về quản lý vòng đời yêu cầu (requirements lifecycle management) và truyền thông tới bên liên quan (stakeholder communication) theo BABOK Guide v3.
Tiêu chuẩn Kỹ thuật /00-research/00_SOURCE_MAP.md Tham chiếu gián tiếp đến ISO/IEC/IEEE 29148 về các yêu cầu đối với tài liệu kỹ thuật trong vòng đời phần mềm, đảm bảo template có cấu trúc chuyên nghiệp.
Chapter Handbook /01-curriculum/CHAPTER_MANIFEST.md Template này là công cụ thực hành chính cho các chapter về Quản lý Vòng đời Yêu cầu, Đánh giá và Xác thực Giải pháp, và Quản lý Thay đổi (Change Management).
Artifact nghiệp vụ /01-curriculum/CANONICAL_BUSINESS_RULES.md
/01-curriculum/CANONICAL_DATA_DICTIONARY.md		 Một Release Note hoàn chỉnh (Tier 3) sẽ ghi nhận các thay đổi cụ thể đối với các quy tắc nghiệp vụ và định nghĩa dữ liệu được quản lý trong hai catalog này.

Nghĩa vụ và Quy trình Kiểm soát Thay đổi

  1. Phân biệt Thẩm quyền:

    • Sửa đổi Template: Việc thay đổi cấu trúc của tệp TMPL-REL-001_release-notes.md (ví dụ: thêm, bớt cột trong Tier 2) là một thay đổi có kiểm soát, yêu cầu review từ Owner, cập nhật phiên bản (version), cập nhật trường updated, và ghi nhận trong Change History.
    • Sử dụng Template: Việc tạo một tài liệu Release Note cụ thể cho một dự án của Nova Foods (ví dụ: REL-NOVA-2026-005.md) bằng cách sao chép và điền vào template này là một hoạt động tác nghiệp thông thường của BA, không làm thay đổi template gốc.

  2. Kiểm soát Phiên bản (Versioning):

    • Mọi thay đổi đối với nội dung quản trị (Tier 1) hoặc cấu trúc template trống (Tier 2) phải dẫn đến việc tăng phiên bản phụ (minor version, ví dụ: từ v0.9.0 lên v0.9.1).
    • Mọi thay đổi chỉ giới hạn trong ví dụ Nova Foods (Tier 3, Tier 4) mà không ảnh hưởng cấu trúc sẽ dẫn đến việc tăng phiên bản vá (patch version, ví dụ: từ v0.9.0 lên v0.9.1).
    • Owner phải cập nhật metadata updated để phản ánh lần cập nhật quản trị gần nhất của artifact.
    • Lịch sử thay đổi phải được ghi lại minh bạch trong bảng "Change History" ở ngay phần đầu của template này.

  3. Quy trình Thay đổi: Bất kỳ đề xuất thay đổi nào đối với template gốc phải được tạo thành một issue hoặc change request, được Owner (Principal IT Business Analyst) xem xét và phê duyệt trước khi hợp nhất. Không được phép sửa đổi trực tiếp trên nhánh chính (main branch) mà không có review.

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

Mẫu này để tạo tài liệu ghi chú phát hành (Release Notes) nhất quán. Sao chép toàn bộ nội dung dưới đây vào tệp Markdown mới. Điền thông tin vào các vùng giữ chỗ <...>. Xóa các hướng dẫn trong ngoặc đơn (...) trước khi gửi đi rà soát.

Bảng Metadata Quản trị

Bảng này chứa thông tin nhận dạng cốt lõi của bản phát hành. Điền chính xác.

Trường Quản trị Giá trị Hướng dẫn
Mã Artifact REL-<PROJECT>-<YYYY>-<NNN> Mã định danh duy nhất. Ví dụ: REL-NOVA-WH-2026-001.
Tên Dự án/Module <Tên dự án hoặc module được phát hành> Tên đầy đủ, không viết tắt.
Phiên bản (Version) <Số phiên bản, theo SemVer MAJOR.MINOR.PATCH> Ví dụ: v1.2.0.
Ngày Phát hành <YYYY-MM-DD> Ngày dự kiến phát hành ra môi trường production.
Trạng thái <DRAFT \| IN_REVIEW \| APPROVED \| REJECTED> Trạng thái hiện tại của tài liệu.
Tác giả (Author) <Tên và vai trò của người soạn thảo> Người chịu trách nhiệm chính cho nội dung.
Owner Phát hành <Tên và vai trò của người chịu trách nhiệm phát hành> Người có thẩm quyền quyết định "go/no-go".

1. Tóm tắt Cấp cao (Executive Summary)

Phần này cho các bên liên quan không chuyên kỹ thuật. Viết ngắn gọn, rõ ràng.

1.1. Mục đích Phát hành

1.2. Phạm vi Phát hành

2. Chi tiết Thay đổi

Danh sách đầy đủ các thay đổi. Dùng ID để truy vết.

2.1. Tính năng Mới (New Features)

ID Yêu cầu Mô tả Tính năng & Lợi ích Nghiệp vụ Tham chiếu (Link tới User Story, Requirement Doc)
<BRQ-XXX> <Mô tả tính năng đã hoàn thành. Nhấn mạnh vào lợi ích cho người dùng cuối hoặc quy trình nghiệp vụ.> <Link tới Jira, Confluence, hoặc tài liệu yêu cầu>
<BRQ-YYY> <...> <...>

2.2. Sửa lỗi (Bug Fixes)

ID Lỗi Mô tả Lỗi và Cách sửa Mức độ nghiêm trọng
<BUG-XXX> Lỗi: <Mô tả ngắn gọn hành vi sai của hệ thống.>
Sửa: <Mô tả cách hệ thống hoạt động đúng sau khi sửa.>		 <Critical / High / Medium / Low>
<BUG-YYY> <...> <...>

2.3. Vấn đề đã biết (Known Issues)

Minh bạch về các lỗi còn tồn tại trong bản phát hành. Quản lý kỳ vọng.

ID Vấn đề Mô tả Vấn đề và Tác động Cách xử lý Tạm thời (Workaround) Kế hoạch Sửa
<ISSUE-XXX> <Mô tả vấn đề. Nêu rõ khi nào xảy ra và tác động tới người dùng/hệ thống là gì.> <Hướng dẫn các bước người dùng có thể làm để tránh hoặc khắc phục tạm thời vấn đề. Ghi "Không có" nếu không tồn tại.> <Link tới ticket sửa lỗi hoặc ghi "Dự kiến ở v1.2.1".>

3. Đánh giá Tác động và Hướng dẫn Triển khai

Thông tin cần thiết cho đội vận hành và kỹ thuật.

3.1. Tác động Nghiệp vụ và Vận hành

  • Quy trình:
  • Dữ liệu:
  • Người dùng:

3.2. Tác động Kỹ thuật

  • Cơ sở dữ liệu (DB): <Có thay đổi schema không? Có cần chạy script DB không? Ghi "Không" nếu không có.>
  • API: <API nào mới/thay đổi/bị loại bỏ? Có ảnh hưởng tới hệ thống tích hợp không?>
  • Cấu hình (Configuration): <Có cần thay đổi biến môi trường (environment variables) hoặc file cấu hình không?>

3.3. Hướng dẫn Triển khai

(Phần này thường do đội kỹ thuật hoặc DevOps điền, nhưng BA cần review để đảm bảo tính đầy đủ) 1. <Bước 1: Ví dụ: Sao lưu cơ sở dữ liệu production.> 2. <Bước 2: Ví dụ: Chạy script di chuyển dữ liệu 'migrate_v1-2-0.sql'.> 3. <Bước 3: Ví dụ: Triển khai mã nguồn từ nhánh 'release/v1.2.0'.> 4. <Bước 4: Ví dụ: Xóa cache ứng dụng.>

3.4. Kế hoạch Rollback

(Kế hoạch dự phòng nếu triển khai thất bại. Cần có để đảm bảo an toàn) 1. <Bước 1 để hoàn tác: Ví dụ: Phục hồi cơ sở dữ liệu từ bản sao lưu.> 2. <Bước 2 để hoàn tác: Ví dụ: Triển khai lại phiên bản v1.1.9 từ tag 'v1.1.9'.>

4. Bằng chứng và Truy vết (Evidence & Traceability)

Ma trận này kết nối yêu cầu với bằng chứng kiểm thử. Cực kỳ quan trọng cho QA và audit.

ID Yêu cầu/Lỗi ID Kịch bản Kiểm thử Kết quả (Passed/Failed) Tham chiếu Bằng chứng (Link tới Test Report, Screenshot)
<BRQ-XXX> <TC-XXX-001> Passed <Link tới kết quả kiểm thử>
<BUG-YYY> <TC-YYY-001> Passed <Link tới kết quả kiểm thử>

5. Rà soát và Phê duyệt (Review & Sign-off)

Ghi nhận chính thức việc các bên liên quan đã xem xét và đồng ý với nội dung phát hành.

Vai trò Tên Người rà soát/phê duyệt Ngày Kết quả Ghi chú/Điều kiện
Business Owner <Tên người đại diện nghiệp vụ> <YYYY-MM-DD> <Approved / Rejected / Approved with comments> <Ghi rõ điều kiện phê duyệt nếu có.>
Product Manager <Tên quản lý sản phẩm> <YYYY-MM-DD> <...> <...>
Tech Lead <Tên trưởng nhóm kỹ thuật> <YYYY-MM-DD> <...> <...>
QA Lead <Tên trưởng nhóm kiểm thử> <YYYY-MM-DD> <...> <...>

Cấu trúc Chi tiết cho Truy vết, Phê duyệt, và Quản lý Thay đổi

Phần này cung cấp các bảng biểu trống, sẵn sàng để sao chép, nhằm mục đích ghi nhận đầy đủ vòng đời của một phiên bản phần mềm. Tài liệu này được gọi là Ghi chú Phát hành (Release Notes), một văn bản chính thức tóm tắt các thay đổi, sửa lỗi và các thông tin liên quan trong một phiên bản cụ thể của sản phẩm hoặc hệ thống.

Bảng 2.1: Tóm tắt Các thay đổi Chính Bảng này liệt kê mọi thay đổi có ảnh hưởng. Mỗi dòng phải có một mã định danh duy nhất để truy vết.

Mã Thay đổi (Change ID) Phân loại Mô tả Thay đổi (Description) Mã Yêu cầu liên quan (Requirement ID)
<Mã định danh duy nhất, ví dụ: FEAT-123> <Tính năng, Sửa lỗi, Cải tiến, Kỹ thuật, Bảo mật> <Mô tả ngắn gọn, dễ hiểu về thay đổi từ góc độ người dùng hoặc nghiệp vụ.> <Mã định danh từ hệ thống quản lý yêu cầu, ví dụ: BIZ-REQ-007>
<Mã định danh duy nhất, ví dụ: BUG-456> <Tính năng, Sửa lỗi, Cải tiến, Kỹ thuật, Bảo mật> <Mô tả ngắn gọn, dễ hiểu về thay đổi từ góc độ người dùng hoặc nghiệp vụ.> <Mã định danh từ hệ thống quản lý yêu cầu, ví dụ: BIZ-REQ-008>

Bảng 2.2: Bằng chứng và Truy vết (Traceability) Bảng này đảm bảo tính truy vết (traceability), tức là khả năng liên kết một thay đổi ngược về yêu cầu gốc, kết quả kiểm thử và phê duyệt tương ứng. Đây là yêu cầu cốt lõi trong các môi trường được kiểm soát.

Mã Thay đổi (Change ID) Bằng chứng Yêu cầu (Requirement Evidence) Bằng chứng Kiểm thử (Test Evidence) Bằng chứng Phê duyệt (Approval Evidence)
<Điền lại Change ID từ Bảng 2.1> <Đường dẫn hoặc tham chiếu đến tài liệu đặc tả, user story, hoặc biên bản họp đã chốt yêu cầu.> <Đường dẫn hoặc tham chiếu đến báo cáo kiểm thử, test case đã thực thi thành công (passed).> <Đường dẫn hoặc tham chiếu đến email, bình luận trong hệ thống, hoặc chữ ký xác nhận phê duyệt cho thay đổi này.>
<Điền lại Change ID từ Bảng 2.1> <Đường dẫn hoặc tham chiếu đến tài liệu đặc tả, user story, hoặc biên bản họp đã chốt yêu cầu.> <Đường dẫn hoặc tham chiếu đến báo cáo kiểm thử, test case đã thực thi thành công (passed).> <Đường dẫn hoặc tham chiếu đến email, bình luận trong hệ thống, hoặc chữ ký xác nhận phê duyệt cho thay đổi này.>

Bảng 2.3: Các Vấn đề đã biết và Giải pháp Tạm thời (Known Issues & Workarounds) Liệt kê các lỗi hoặc hạn chế đã biết tồn tại trong phiên bản này. Việc ghi nhận minh bạch giúp quản lý kỳ vọng của người dùng. Một giải pháp tạm thời (workaround) là một hướng dẫn giúp người dùng đạt được mục tiêu của họ dù có lỗi.

Mã Vấn đề (Issue ID) Mô tả Vấn đề Mức độ Ảnh hưởng (Impact) Giải pháp Tạm thời (Workaround)
<Mã lỗi trong hệ thống theo dõi, ví dụ: KNOWN-010> <Mô tả chi tiết vấn đề, bao gồm các bước tái hiện nếu có.> <Cao / Trung bình / Thấp. Mô tả ngắn gọn ảnh hưởng đến người dùng hoặc quy trình nghiệp vụ.> <Mô tả các bước người dùng có thể thực hiện để tránh vấn đề này cho đến khi có bản sửa lỗi chính thức. Nếu không có, ghi "Không có".>

Bảng 2.4: Xem xét và Ký duyệt Phiên bản (Release Review and Sign-off) Bảng này ghi lại sự phê duyệt chính thức (sign-off) từ các bên liên quan có thẩm quyền trước khi phát hành. Đây là cổng kiểm soát chất lượng cuối cùng.

Vai trò (Role) Tên người thực hiện (Reviewer Name) Quyết định (Decision) Ngày (Date) Ghi chú / Tham chiếu Chữ ký
<Business Owner> <Tên đầy đủ của người có thẩm quyền về mặt nghiệp vụ> <Approved / Changes Requested / Rejected> <YYYY-MM-DD> <Ghi chú ngắn gọn hoặc tham chiếu đến bằng chứng phê duyệt.>
<Product Manager> <Tên đầy đủ của người quản lý sản phẩm> <Approved / Changes Requested / Rejected> <YYYY-MM-DD> <Ghi chú ngắn gọn hoặc tham chiếu đến bằng chứng phê duyệt.>
<QA Lead> <Tên đầy đủ của người đứng đầu nhóm kiểm thử> <Approved / Changes Requested / Rejected> <YYYY-MM-DD> <Ghi chú ngắn gọn hoặc tham chiếu đến bằng chứng phê duyệt.>
<Technical Lead> <Tên đầy đủ của người đứng đầu nhóm kỹ thuật> <Approved / Changes Requested / Rejected> <YYYY-MM-DD> <Ghi chú ngắn gọn hoặc tham chiếu đến bằng chứng phê duyệt.>

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

Phần này cung cấp hướng dẫn và quy tắc cụ thể để điền các trường trong mẫu Ghi chú phát hành. Việc tuân thủ đảm bảo tính nhất quán, chính xác và dễ truy vết cho mọi bản phát hành.

Hướng dẫn cho các trường Metadata

Metadata cung cấp bối cảnh cốt lõi cho bản phát hành. Phải điền chính xác theo các quy tắc sau.

Tên trường (Field Name) Hướng dẫn và quy tắc xác thực (Guidance & Validation Rules)
Release Version Bắt buộc. Sử dụng hệ thống phiên bản ngữ nghĩa (Semantic Versioning - SemVer) theo định dạng MAJOR.MINOR.PATCH.
- MAJOR: Tăng khi có thay đổi phá vỡ tương thích (breaking change) với API hoặc chức năng hiện có.
- MINOR: Tăng khi thêm chức năng mới nhưng vẫn tương thích ngược (backwards-compatible).
- PATCH: Tăng khi sửa lỗi và vá lỗ hổng, tương thích ngược.
Status Bắt buộc. Chỉ được sử dụng một trong các giá trị sau: DRAFT, IN_REVIEW, APPROVED, RELEASED.
- DRAFT: Đang soạn thảo, chưa sẵn sàng để xem xét.
- IN_REVIEW: Đã hoàn tất và đang chờ các bên liên quan xem xét.
- APPROVED: Đã được tất cả các bên yêu cầu phê duyệt, sẵn sàng phát hành.
- RELEASED: Đã được triển khai lên môi trường production.
Release Date Bắt buộc. Ngày dự kiến hoặc ngày phát hành thực tế. Sử dụng định dạng YYYY-MM-DD theo tiêu chuẩn ISO 8601.

Hướng dẫn cho Bảng danh sách thay đổi (Items)

Bảng này liệt kê chi tiết từng thay đổi trong bản phát hành. Mỗi dòng là một mục công việc hoàn thành.

Tên cột (Column Name) Hướng dẫn và quy tắc xác thực (Guidance & Validation Rules)
ID Bắt buộc. Định danh duy nhất của mục công việc từ hệ thống quản lý (ví dụ: Jira, Azure DevOps). Ví dụ: NFP-1701.
Type Bắt buộc. Phân loại thay đổi. Giá trị hợp lệ:
- Feature: Chức năng mới mang lại giá trị cho người dùng.
- Fix: Sửa một lỗi đã được ghi nhận.
- Chore: Công việc kỹ thuật nền tảng, không ảnh hưởng trực tiếp đến người dùng cuối (ví dụ: nâng cấp thư viện, tái cấu trúc mã - refactoring).
- Security: Vá một lỗ hổng bảo mật đã được xác định.
Title Bắt buộc. Tiêu đề ngắn gọn, mô tả rõ ràng thay đổi. Viết ở dạng mệnh lệnh. Ví dụ: "Thêm trường đơn vị tính cho sản phẩm" thay vì "Đã thêm trường..."
Traceability ID Bắt buộc. Định danh truy vết liên kết đến yêu cầu nghiệp vụ (BR-), yêu cầu phi chức năng (NFR-), hoặc quy tắc nghiệp vụ (RULE-) gốc trong TRACEABILITY_ID_REGISTRY. Việc này rất quan trọng để kiểm toán và xác minh phạm vi.

Hướng dẫn cho các mục có điều kiện

Một số mục chỉ áp dụng cho các bản phát hành có chứa loại thay đổi cụ thể. - Ví dụ: Database Migration Scripts, API Breaking Changes. - Quy tắc: Nếu một mục có điều kiện không áp dụng cho bản phát hành hiện tại, hãy điền giá trị Không áp dụng. vào mục đó. Không xóa mục khỏi template để duy trì cấu trúc nhất quán.

Hướng dẫn tham chiếu bằng chứng và bí mật

Mọi thay đổi lớn cần có bằng chứng. Tham chiếu phải an toàn và rõ ràng.

  • Loại bằng chứng (Evidence Type): Sử dụng các giá trị như Test Plan, QA Sign-off Report, Architectural Decision Record (ADR), Security Scan Report, Pull Request. ADR là một tài liệu ghi lại một quyết định kiến trúc quan trọng cùng bối cảnh và hậu quả của nó.
  • Tham chiếu an toàn (Safe Secret Reference): Khi cần tham chiếu đến thông tin nhạy cảm hoặc tài liệu kiểm soát truy cập (như kế hoạch triển khai chi tiết, khóa API), không bao giờ dùng URL trực tiếp. Thay vào đó, sử dụng định dạng tham chiếu an toàn đã được thống nhất:
  • Cú pháp: [SECRET:<TÊN_KHO_LƯU_TRỮ>/<ĐƯỜNG_DẪN_TỚI_BÍ_MẬT>]
  • Ví dụ: [SECRET:CORP_VAULT/release-plans/q3-erp-api-key-rotation]

Hướng dẫn cho Bảng xét duyệt (Sign-off)

Bảng này ghi lại sự phê duyệt chính thức từ các bên liên quan có thẩm quyền.

Tên cột (Column Name) Hướng dẫn và quy tắc xác thực (Guidance & Validation Rules)
Role Bắt buộc. Chức danh của người xét duyệt, ví dụ: Product Owner, QA Lead, Tech Architect.
Name / ID Bắt buộc. Tên hoặc định danh của người xét duyệt.
Decision Bắt buộc. Quyết định của người xét duyệt. Giá trị hợp lệ:
- Approved: Đồng ý hoàn toàn với việc phát hành.
- Approved with Comments: Đồng ý phát hành nhưng có các ghi chú/điều kiện cần các bên lưu ý hoặc xử lý sau.
- Rejected: Từ chối phát hành. Bản phát hành phải được xem xét và sửa đổi.
Date Bắt buộc. Ngày đưa ra quyết định, theo định dạng YYYY-MM-DD.

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

Đây là ví dụ hoàn chỉnh cách điền mẫu Ghi chú Phát hành (Release Notes). Toàn bộ bối cảnh, dữ liệu, tên tổ chức và định danh trong Tier 3 là mô phỏng cho Nova Foods Trading & Manufacturing, chỉ dùng đào tạo. Trạng thái mọi hồ sơ dưới đây là IN_REVIEW; không hồ sơ nào là bản chuẩn hóa hoặc đã được phê duyệt triển khai.

Ghi nhận Cốt lõi của Bản phát hành (Core Release Record)

Bảng này chứa metadata quản trị cốt lõi cho bản phát hành mô phỏng REL-2026-Q3-014.

Trường thông tin Giá trị cho bản phát hành mô phỏng
Release ID REL-2026-Q3-014
Hệ thống / Module NovaFoods ERP / Purchasing & Payables
Ngày phát hành dự kiến 2026-09-15
Trạng thái quản trị IN_REVIEW
Chủ sở hữu Nghiệp vụ Phạm Thị Mai Lan (Trưởng phòng Mua hàng)
Chủ sở hữu Sản phẩm Lê Minh Tuấn
Trưởng nhóm Kỹ thuật Nguyễn Văn Dũng
Mục đích chính Tích hợp nhà cung cấp hóa đơn điện tử (HĐĐT) theo Nghị định 123/2020/NĐ-CP. Sửa lỗi tính thuế Giá trị gia tăng (GTGT) cho đơn hàng áp dụng chiết khấu toàn phần.
Đầu ra cần đạt Người dùng nghiệp vụ có thể phát hành HĐĐT tự động cho đơn đặt hàng đủ điều kiện; hệ thống tính GTGT trên giá trị sau chiết khấu; đội vận hành có bằng chứng kiểm tra sau triển khai.
Thẩm quyền hiện tại Chủ sở hữu Nghiệp vụ, Chủ sở hữu Sản phẩm và Trưởng nhóm Kỹ thuật rà soát phạm vi, rủi ro, bằng chứng và kế hoạch triển khai. Quyết định triển khai chưa được ghi nhận.

Tóm tắt các thay đổi

Bảng này liệt kê hạng mục công việc thuộc phạm vi REL-2026-Q3-014.

ID hạng mục Loại Tóm tắt thay đổi Tham chiếu Yêu cầu / Quy tắc Tác nhân, hành động, kết quả
NF-4321 Feature Tích hợp API FPT eInvoice để tự động phát hành HĐĐT cho đơn đặt hàng đã được duyệt. BR-PUR-025 NovaFoods ERP gửi dữ liệu hóa đơn cho FPT eInvoice; hệ thống lưu mã giao dịch và trạng thái phản hồi để Kế toán theo dõi.
NF-4355 Bug Fix Sửa logic tính GTGT 10% trên tổng giá trị sau chiết khấu thay vì trước chiết khấu. BR-ACC-012 NovaFoods ERP tính lại thuế cho đơn hàng có chiết khấu toàn phần; Kế toán nhận giá trị thuế theo quy tắc nghiệp vụ đã tham chiếu.
NF-4360 Technical Debt Nâng cấp thư viện HTTP client để hỗ trợ TLS 1.3 theo yêu cầu bảo mật mới. SEC-GEN-004 Thành phần tích hợp dùng kết nối TLS 1.3 khi môi trường và nhà cung cấp hỗ trợ; đội Kỹ thuật kiểm tra kết nối trước triển khai.

Tác động Nghiệp vụ và Đánh giá Rủi ro

  • Tác động tích cực dự kiến:
  • Tuân thủ: Bản phát hành hỗ trợ quy trình HĐĐT được thiết kế theo bối cảnh Nghị định 123/2020/NĐ-CP. Đội Kế toán vẫn chịu trách nhiệm xác minh nghĩa vụ áp dụng thực tế.
  • Hiệu quả: Tự động phát hành HĐĐT giảm bước nhập và gửi thủ công của Kế toán cho giao dịch đủ điều kiện.
  • Chính xác: Sửa NF-4355 giảm nguy cơ tính GTGT sai khi đơn hàng có chiết khấu toàn phần.

  • Truy vết: Mã giao dịch nhà cung cấp và trạng thái HĐĐT được lưu trong purchase_invoices, giúp Kế toán và đội hỗ trợ đối chiếu sự cố.

  • Rủi ro, hậu quả và giảm thiểu:

Rủi ro Tác nhân chịu ảnh hưởng Hậu quả Kiểm soát / giảm thiểu Chủ sở hữu kiểm soát
API FPT eInvoice không phản hồi hoặc ngừng hoạt động Kế toán Thanh toán, Mua hàng, nhà cung cấp Hệ thống không phát hành HĐĐT tự động; xử lý hóa đơn có thể chậm. ERP tạo bản nháp hóa đơn, gửi thông báo cho Kế toán xử lý qua portal nhà cung cấp, ghi trạng thái PENDING, và giám sát phản hồi API. Nguyễn Văn Dũng
Token production không truy xuất được Đội vận hành, Kế toán Tích hợp không xác thực được với nhà cung cấp. Lưu token tại [SECRET:NOVA_VAULT/erp/einvoice-prod-token]; chỉ người có quyền vận hành truy xuất; xác minh quyền truy xuất trước cửa sổ triển khai. Nguyễn Văn Dũng
Migration schema thất bại Đội DBA, người dùng Purchasing & Payables Ứng dụng mới có thể không đọc hoặc ghi được dữ liệu HĐĐT. DBA chạy migration trong cửa sổ triển khai, xác minh cột mới trước deploy, dừng rollout nếu migration lỗi. Đội DBA
Logic GTGT sau sửa không khớp dữ liệu kiểm thử Kế toán Thanh toán Số tiền thuế và đối chiếu hóa đơn có thể sai. Chạy smoke test với đơn hàng có chiết khấu toàn phần; Kế toán kiểm tra năm giao dịch thực tế đầu ngày 2026-09-15. Phạm Thị Mai Lan và Kế toán
Rollback dữ liệu không đầy đủ Đội vận hành, Kế toán Trạng thái giao dịch có thể không khớp giữa ERP và portal nhà cung cấp. Trước rollback, đội vận hành lập danh sách giao dịch đã gửi nhà cung cấp, đối chiếu mã e_invoice_provider_transaction_id, rồi thực hiện xử lý thủ công cho giao dịch cần thiết. Lê Minh Tuấn, Nguyễn Văn Dũng

Các quyết định chính đã được đưa ra

ID Quyết định Tóm tắt quyết định Lý do và tiêu chí Thẩm quyền / trạng thái Đánh đổi và hậu quả
ADR-0018 Chọn FPT eInvoice làm nhà cung cấp HĐĐT mô phỏng cho giai đoạn 2026-2028. Bối cảnh case ghi nhận chi phí cạnh tranh, tài liệu API rõ ràng, hỗ trợ kỹ thuật 24/7 và SDK Java. Lê Minh Tuấn, Phạm Thị Mai Lan, Nguyễn Văn Dũng; IN_REVIEW. Giảm công sức tự xây lớp phát hành hóa đơn; tăng phụ thuộc vào API, token và khả năng sẵn sàng của nhà cung cấp.
ADR-0019 Không xây giao diện tùy chỉnh để sửa HĐĐT đã phát hành trong phạm vi release này. Case ghi nhận rủi ro pháp lý cao và nhu cầu xử lý hóa đơn sai bằng hóa đơn thay thế hoặc điều chỉnh theo quy trình nghiệp vụ được Kế toán quản lý. Lê Minh Tuấn, Kế toán trưởng; IN_REVIEW. Giảm phạm vi và rủi ro thay đổi dữ liệu hóa đơn; Kế toán phải xử lý trường hợp sửa hóa đơn theo quy trình ngoài giao diện mới.

Thay đổi về Dữ liệu, Schema hoặc API

Bảng sau ghi nhận thay đổi tầng dữ liệu vật lý cho REL-2026-Q3-014.

Tên đối tượng Loại thay đổi Chi tiết Tham chiếu Từ điển Dữ liệu Tác động và kiểm soát
purchase_invoices (Table) ADD COLUMN e_invoice_provider_transaction_id VARCHAR(255) NULL lưu mã giao dịch nhà cung cấp HĐĐT. CDD-PI-015 Kế toán dùng mã này đối chiếu ERP với phản hồi nhà cung cấp; giá trị có thể NULL khi hóa đơn chưa gửi hoặc gửi lỗi.
purchase_invoices (Table) ADD COLUMN e_invoice_status VARCHAR(50) NOT NULL DEFAULT 'PENDING' theo dõi trạng thái HĐĐT. CDD-PI-016 Ứng dụng phải ghi trạng thái phản hồi; đội hỗ trợ dùng trạng thái để nhận diện giao dịch cần xử lý.
vendors (Table) ADD COLUMN requires_e_invoice BOOLEAN NOT NULL DEFAULT true đánh dấu nhà cung cấp yêu cầu HĐĐT. CDD-VEND-041 Mua hàng và Kế toán xác minh cấu hình nhà cung cấp trước phát hành hóa đơn.

API tích hợp thuộc phạm vi NF-4321. NovaFoods ERP là bên gọi, FPT eInvoice là bên nhận. Đầu vào là dữ liệu hóa đơn của đơn đặt hàng đã được duyệt. Đầu ra cần lưu là mã giao dịch nhà cung cấp và trạng thái HĐĐT. Token production không xuất hiện trong release note, log ứng dụng hoặc bằng chứng chia sẻ rộng rãi.

Cấu hình, Phụ thuộc và Kế hoạch Triển khai

  • Phụ thuộc bên ngoài:
  • API endpoint FPT eInvoice production phải được cung cấp và hoạt động trong cửa sổ kiểm tra tích hợp.
  • Token production phải được lưu tại [SECRET:NOVA_VAULT/erp/einvoice-prod-token].
  • Đội vận hành xác minh quyền truy xuất secret mà không sao chép giá trị token vào ticket, email, log hoặc tài liệu đào tạo.

  • FPT eInvoice phải trả phản hồi cho giao dịch smoke test; nếu không có phản hồi, đội triển khai kích hoạt quy trình dự phòng thay vì xác nhận tự động hóa hoạt động.

  • Kế hoạch triển khai (Rollout Plan):

  • Thời gian: 22:00 Thứ Bảy, 2026-09-13.
  • DBA chạy script cập nhật schema DB cho purchase_invoices và vendors, sau đó xác minh ba cột mới tồn tại với thuộc tính đã ghi trong CDD-PI-015, CDD-PI-016, CDD-VEND-041.
  • Đội Kỹ thuật deploy mã nguồn mới lên production sau khi DBA xác nhận migration thành công.
  • Đội Kỹ thuật và Kế toán chạy smoke test với một đơn hàng thử nghiệm đã được duyệt, kiểm tra trạng thái HĐĐT, mã giao dịch nhà cung cấp và kết quả tính GTGT.
  • Kế toán và Mua hàng kiểm tra năm giao dịch thực tế đầu tiên ngày 2026-09-15, đối chiếu dữ liệu ERP, phản hồi nhà cung cấp và chứng từ nghiệp vụ.

  • Quản lý phát hành ghi kết quả từng bước vào bằng chứng release. Trạng thái release vẫn là IN_REVIEW cho đến khi người có thẩm quyền ghi nhận kết quả rà soát theo quy trình quản trị áp dụng.

  • Điều kiện dừng rollout:

  • Migration schema lỗi.
  • Ứng dụng không tạo được bản nháp hóa đơn.
  • Smoke test không nhận được mã giao dịch hoặc trạng thái từ nhà cung cấp.

  • Kết quả tính GTGT trong smoke test không khớp quy tắc BR-ACC-012.

  • Kế hoạch trả về:

  • Đội vận hành dừng phát hành HĐĐT tự động.
  • Đội Kỹ thuật trả ứng dụng về phiên bản trước rollout.
  • DBA chỉ hoàn tác schema khi kế hoạch rollback đã xác minh an toàn dữ liệu; nếu không, giữ schema tương thích và rollback ứng dụng.
  • Kế toán xử lý giao dịch PENDING qua portal nhà cung cấp và đối chiếu mã giao dịch đã phát sinh trước rollback.
  • Quản lý phát hành ghi nguyên nhân, giao dịch bị ảnh hưởng, hành động khôi phục và kết quả đối chiếu vào hồ sơ release.

Phần Lõi Ghi Chú Phát Hành - Case Study Nova Foods v1.2.5

Ghi chú phát hành là tài liệu kỹ thuật được phân phối cùng phiên bản phần mềm. Tài liệu thông báo thay đổi, sửa lỗi, tính năng mới, vấn đề đã biết, tác động, bằng chứng và trạng thái quản trị cho người dùng, đội vận hành và bên liên quan.

Ví dụ dưới đây là hồ sơ mô phỏng riêng cho NOVA-ERP v1.2.5. Hồ sơ này giữ trạng thái IN_REVIEW; trạng thái không xác nhận phê duyệt hoặc triển khai.

Bảng Metadata Ghi Chú Phát Hành

Trường Metadata Giá trị Diễn giải
ID Phiên bản REL-2026-08-15-001 Định danh duy nhất cho bản phát hành mô phỏng trong hệ thống theo dõi.
Phiên bản phần mềm v1.2.5 Số hiệu phiên bản NOVA-ERP sau cập nhật.
Ngày phát hành 2026-08-15 Ngày dự kiến triển khai lên môi trường Production.
Loại phát hành Minor Release Bao gồm sửa lỗi và cải tiến nhỏ, không phải thay đổi lớn.
Quản lý phát hành Lê Minh Tuấn (PM-LMT) Người điều phối chuẩn bị, bằng chứng và truyền thông release.
Trạng thái phê duyệt IN_REVIEW Bên có thẩm quyền đang rà soát phạm vi, kiểm thử, rủi ro và kế hoạch triển khai. Chưa có phê duyệt triển khai.
Hệ thống/Module NOVA-ERP / Modules: Purchasing, Supplier Management Thành phần bị ảnh hưởng.
Chủ sở hữu nghiệp vụ Nguyễn Thị Bích (Trưởng phòng Mua hàng) và Trần Văn Hùng (Kế toán trưởng) Người xác nhận tác động quy trình mua hàng và kế toán.
Bằng chứng cần có Kết quả migration, smoke test, kiểm tra phân quyền PO, kiểm tra MST, danh sách vấn đề đã biết Đầu vào bắt buộc cho vòng rà soát trạng thái IN_REVIEW.

Tóm Tắt Thay Đổi

Phiên bản v1.2.5 tập trung hai mục tiêu:

  1. Sửa lỗi quy trình phê duyệt PO để PO có giá trị chính xác 500000000 VND không bỏ qua cấp duyệt Trưởng phòng.
  2. Bổ sung trường supplier_tax_code cho hồ sơ nhà cung cấp và biểu mẫu PO để tăng khả năng truy xuất dữ liệu phục vụ đối chiếu, báo cáo thuế và xử lý hóa đơn.

Chi Tiết Các Thay Đổi

ID Tác vụ Loại Mô tả thay đổi và lý do nghiệp vụ Module bị ảnh hưởng Chủ sở hữu nghiệp vụ Kết quả cần kiểm tra
NF-TICK-4591 Sửa lỗi (Bug Fix) Sửa logic phê duyệt PO > 500 triệu VND. Lỗi dùng điều kiện amount < 500000000 thay vì amount <= 500000000, làm PO có giá trị chính xác 500000000 VND bỏ qua cấp duyệt Trưởng phòng. Sửa lỗi để hệ thống áp dụng BR-PROCURE-005. Purchasing Nguyễn Thị Bích (Trưởng phòng Mua hàng) Nhân viên Mua hàng tạo PO trị giá 500000000 VND; hệ thống phải gửi PO đến cấp duyệt Trưởng phòng thay vì tự động bỏ qua cấp này.
NF-TICK-4217 Tính năng mới (Feature) Bổ sung supplier_tax_code cho cơ sở dữ liệu và giao diện. Người dùng phải nhập trường này khi tạo hoặc cập nhật hồ sơ nhà cung cấp. PO mới tự điền MST từ hồ sơ nhà cung cấp. Thay đổi hỗ trợ dữ liệu đầu vào cho hóa đơn, chứng từ theo bối cảnh Nghị định 123/2020/NĐ-CP. Supplier Management, Purchasing Trần Văn Hùng (Kế toán trưởng) Người dùng tạo hoặc cập nhật nhà cung cấp không có MST; hệ thống chặn lưu và hiển thị thông báo xác thực. PO mới của nhà cung cấp có MST phải hiển thị đúng giá trị đã lưu.

Thông Tin Triển Khai

Hạng mục Chi tiết
Khung thời gian triển khai 22:00 2026-08-15 đến 02:00 2026-08-16 (giờ Việt Nam, Asia/Ho_Chi_Minh)
Thời gian hệ thống gián đoạn Dự kiến gián đoạn 2 giờ cho Purchasing và Supplier Management. Module khác hoạt động bình thường theo kế hoạch mô phỏng.
Yêu cầu tiên quyết DBA chạy thành công V1.2.5__add_supplier_tax_code.sql trước deploy mã nguồn.
Trách nhiệm triển khai DBA thực thi và xác minh migration; đội Kỹ thuật deploy ứng dụng; Mua hàng và Kế toán chạy kiểm tra nghiệp vụ; Quản lý phát hành lưu bằng chứng.
Kiểm tra sau triển khai Kiểm tra PO trị giá 500000000 VND đi qua cấp duyệt Trưởng phòng; kiểm tra tạo nhà cung cấp bắt buộc MST; kiểm tra PO mới tự điền supplier_tax_code.
Kế hoạch trả về (Rollback Plan) Khi lỗi nghiêm trọng ảnh hưởng phê duyệt PO hoặc lưu nhà cung cấp, đội vận hành trả ứng dụng về v1.2.4. Bản sao lưu DB tạo lúc 21:30 2026-08-15 là đầu vào khôi phục. DBA xác minh ảnh hưởng dữ liệu phát sinh trong cửa sổ triển khai trước khi khôi phục.
Trạng thái sau kiểm tra IN_REVIEW; kết quả kiểm tra là bằng chứng cho vòng rà soát, không phải xác nhận phê duyệt.

Các Vấn Đề Đã Biết (Known Issues)

  1. ID: NF-KI-031
  2. Mô tả: Trường MST mới chưa hiển thị trên báo cáo mua hàng cũ tạo trước 2026-08-15.
  3. Tác động: Kế toán hoặc Mua hàng xem báo cáo cũ có thể không thấy MST dù hồ sơ nhà cung cấp hiện có dữ liệu.
  4. Giải pháp tạm thời: Người dùng xuất dữ liệu thô và đối chiếu MST từ màn hình quản lý nhà cung cấp khi cần gấp.
  5. Hạng mục theo dõi: NF-TASK-4602 cập nhật dữ liệu cho báo cáo cũ trong bản phát hành bảo trì riêng.
  6. Chủ sở hữu: Trần Văn Hùng (Kế toán trưởng) xác nhận nhu cầu báo cáo; Lê Minh Tuấn theo dõi phạm vi phát hành bảo trì.

Phân tích và Quyết định Thay đổi

Bối cảnh và Hiện trạng (Facts & Current Behavior)

Nhân viên Mua hàng có thể tạo và gửi Đơn Mua hàng (Purchase Order - PO) để phê duyệt mà không bắt buộc nhập Mã số thuế nhà cung cấp. Người dùng kiểm tra thủ công thông tin trên hợp đồng hoặc báo giá. Case mô phỏng ghi nhận khoảng 20% PO tại Trace Ref: NF-METRIC-PO-COMPL-2026Q2 thiếu hoặc sai MST. Hậu quả là Kế toán Thanh toán phải đối chiếu bổ sung khi xử lý Hóa đơn GTGT, làm chậm thanh toán và tăng nguy cơ nhập liệu thủ công sai.

Nhu cầu Nghiệp vụ (Underlying Need)

Kế toán cần MST hợp lệ trên PO để hỗ trợ đối chiếu hóa đơn đầu vào và báo cáo. Mua hàng cần hệ thống chặn hồ sơ nhà cung cấp thiếu MST thay vì chuyển trách nhiệm kiểm tra sang bước sau. Đối tượng kiểm soát là dữ liệu nhà cung cấp và PO mới. Kết quả cần đạt là PO dùng dữ liệu MST nhất quán từ hồ sơ nhà cung cấp, Kế toán có thể truy vết dữ liệu nguồn, và ngoại lệ dữ liệu thiếu được phát hiện khi người dùng nhập liệu.

Các Phương án Đã xem xét (Options Considered)

Buổi làm việc mô phỏng ngày 2026-07-15 có Trưởng phòng Mua hàng và Kế toán trưởng đánh giá ba phương án.

ID Phương án Mô tả phương án Ưu điểm Nhược điểm Hậu quả vận hành
PA-01 Giữ nguyên hiện trạng, không thay đổi hệ thống. Không có chi phí phát triển. Dữ liệu MST tiếp tục phụ thuộc kiểm tra thủ công. Kế toán tiếp tục xử lý thiếu dữ liệu sau khi PO đã được tạo.
PA-02 Kế toán Thanh toán kiểm tra MST trên mọi PO trước khi Trưởng phòng Mua hàng phê duyệt. Tăng kiểm tra dữ liệu mà không đổi code. Thêm bước thủ công, làm chậm chu trình duyệt PO, phụ thuộc con người. Nút thắt chuyển sang Kế toán; Mua hàng chờ xác minh từng PO.
PA-03 Bắt buộc MST trên hệ thống, kiểm tra định dạng cơ bản 10 hoặc 13 chữ số, tự điền MST vào PO mới. Kiểm soát tại nguồn, giảm thiếu dữ liệu, giảm xử lý thủ công sau tạo PO. Có chi phí phát triển, migration và đào tạo người dùng. Người dùng phải có MST trước khi lưu hồ sơ nhà cung cấp; dữ liệu PO mới nhất quán hơn.

Tiêu chí Quyết định (Decision Criteria)

Tiêu chí Trọng số PA-01 PA-02 PA-03
Giảm thiểu rủi ro tuân thủ thuế 5 (Rất cao) 1 (Kém) 3 (Trung bình) 5 (Tốt)
Tăng tốc độ xử lý thanh toán 4 (Cao) 1 (Kém) 2 (Dưới trung bình) 5 (Tốt)
Giảm nỗ lực xử lý thủ công 4 (Cao) 1 (Kém) 1 (Kém) 5 (Tốt)
Chi phí triển khai 2 (Thấp) 5 (Tốt) 5 (Tốt) 3 (Trung bình)
Tổng điểm có trọng số - 34 40 59

Quyết định và Thẩm quyền (Decision & Authority)

  • Quyết định được đề xuất: Chọn PA-03.
  • Lý do: PA-03 có tổng điểm cao nhất, kiểm soát dữ liệu tại điểm nhập, giảm phụ thuộc bước kiểm tra thủ công và hỗ trợ Kế toán đối chiếu PO với hóa đơn.
  • Đánh đổi: Nova Foods chấp nhận chi phí phát triển, migration, kiểm thử và thay đổi thao tác nhập liệu để đổi lấy kiểm soát dữ liệu nguồn.
  • Thẩm quyền rà soát:
  • Nguyễn Thị Lan, Kế toán trưởng (EMP-ID: NF0012) — Business Owner.
  • Trần Văn Minh, Trưởng phòng Mua hàng (EMP-ID: NF0085) — Process Owner.
  • Trạng thái: IN_REVIEW. Hai người trên là bên có thẩm quyền nghiệp vụ trong case mô phỏng; hồ sơ không ghi nhận phê duyệt triển khai.

Hậu quả nếu Quyết định Sai (Consequence if Wrong)

  1. Tài chính và tuân thủ: Nếu PA-01 được giữ, dữ liệu thiếu hoặc sai có thể làm Kế toán mất thêm công đối chiếu chứng từ, tăng rủi ro xử lý hóa đơn không đầy đủ dữ liệu và rủi ro thuế cần chuyên môn xác minh.
  2. Vận hành: Chu trình thanh toán có thể kéo dài vì Kế toán phải liên hệ lại Mua hàng hoặc nhà cung cấp để bổ sung MST.
  3. Nhân sự: Nhân viên Kế toán và Mua hàng tiếp tục dùng thời gian cho kiểm tra và nhập lại dữ liệu thay vì xử lý ngoại lệ thực sự.
  4. Dữ liệu: PO mới có thể không truy vết được MST từ hồ sơ nhà cung cấp, làm giảm khả năng đối chiếu và báo cáo.
  5. Khách hàng nội bộ: Người phê duyệt PO nhận hồ sơ thiếu dữ liệu đầu vào cần thiết, khiến quyết định phê duyệt dựa trên thông tin không đầy đủ.

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

Phần này cung cấp các bằng chứng, giả định, và phân tích truy vết hỗ trợ cho quyết định PA-03 đã chọn ở mục trước. Traceability (Truy vết yêu cầu) là khả năng liên kết một yêu cầu từ nguồn gốc ban đầu qua quá trình phát triển cho đến khi hoàn thành và được kiểm thử. Việc lập hồ sơ này đảm bảo tính minh bạch, quản lý được rủi ro và tạo cơ sở cho việc kiểm thử và triển khai.

4.1. Bảng truy vết yêu cầu (Traceability Matrix)

Bảng này liên kết nhu cầu nghiệp vụ với các yêu cầu, quy tắc và tiêu chí chấp nhận cụ thể, đảm bảo mọi cấu phần của giải pháp đều phục vụ một mục đích đã được xác định.

Hạng mục (Item) ID tham chiếu (Reference ID) Mô tả Nguồn (Source)
Business Need NEED-001 Tuân thủ 100% quy định về hóa đơn, chứng từ điện tử theo Nghị định 123/2020/NĐ-CP và giảm thiểu rủi ro tài chính liên quan. Quyết định DEC-001
Functional Requirement REQ-003 Hệ thống ERP phải tự động xác thực tính hợp lệ của mọi hóa đơn điện tử đầu vào từ nhà cung cấp thông qua cổng tra cứu của Tổng cục Thuế. NEED-001
Business Rule BR-FIN-001 Hóa đơn điện tử đầu vào chỉ được đưa vào quy trình thanh toán nếu có trạng thái "Hợp lệ" sau khi tra cứu trên hệ thống của cơ quan thuế. REQ-003, Nghị định 123/2020/NĐ-CP
Acceptance Criterion AC-005 GIVEN một hóa đơn điện tử được tải lên hệ thống, WHEN hệ thống thực hiện tra cứu tự động, THEN trạng thái hóa đơn phải được cập nhật thành VALID (hợp lệ), INVALID (không hợp lệ), hoặc PENDING_VERIFICATION (chờ xác minh) trong vòng 60 giây. REQ-003, BR-FIN-001
Acceptance Criterion AC-006 GIVEN trạng thái hóa đơn là INVALID hoặc PENDING_VERIFICATION, WHEN quy trình xử lý ngoại lệ được kích hoạt, THEN một thông báo email phải được tự động gửi đến người tạo yêu cầu thanh toán và bộ phận kế toán. REQ-003

4.2. Ngoại lệ và Luồng tiêu cực (Exceptions and Negative Paths)

Negative Path (Luồng tiêu cực) là các kịch bản trong đó hệ thống không hoạt động như mong đợi do lỗi đầu vào, lỗi hệ thống hoặc các điều kiện không lường trước. Việc xác định trước các luồng này rất quan trọng để xây dựng một hệ thống mạnh mẽ.

ID Tình huống (Scenario) Hành vi hệ thống mong muốn (Expected System Behavior) Hành động khắc phục / Thông báo (Remediation / Notification)
EX-01 API tra cứu của Tổng cục Thuế không phản hồi (timeout). Hệ thống tự động thử lại 3 lần, mỗi lần cách nhau 5 phút. Sau 3 lần thất bại, hóa đơn được chuyển sang trạng thái API_UNAVAILABLE. Gửi cảnh báo đến nhóm quản trị hệ thống và thông báo cho người dùng chờ xử lý sau.
EX-02 API tra cứu trả về mã lỗi hệ thống (ví dụ: HTTP 500, 503). Xử lý tương tự như EX-01. Tương tự như EX-01. Ghi lại chi tiết mã lỗi để phân tích.
EX-03 Mã tra cứu hóa đơn không tồn tại trên hệ thống của Tổng cục Thuế. Hệ thống cập nhật trạng thái hóa đơn thành INVALID_CODE (Mã không hợp lệ). Tự động gửi email cho người yêu cầu thanh toán và kế toán, nêu rõ "Mã tra cứu hóa đơn không tồn tại", yêu cầu liên hệ nhà cung cấp để nhận hóa đơn chính xác. Chặn hóa đơn khỏi quy trình thanh toán.
EX-04 Thông tin trên hóa đơn (Mã số thuế, tên công ty, tổng tiền) không khớp với thông tin Nhà cung cấp hoặc Đơn đặt hàng (PO) trong ERP. Hệ thống cập nhật trạng thái hóa đơn thành DATA_MISMATCH. Tạo một tác vụ (task) review trong ERP cho bộ phận kế toán, đính kèm hóa đơn và đánh dấu các trường dữ liệu không khớp để kiểm tra thủ công.
EX-05 Hóa đơn có chữ ký số không hợp lệ hoặc hết hạn. Hệ thống cập nhật trạng thái hóa đơn thành INVALID_SIGNATURE. Chặn hóa đơn và gửi thông báo tương tự như EX-03, yêu cầu nhà cung cấp phát hành lại hóa đơn với chữ ký số hợp lệ.

4.3. Giả định và Hạng mục cần xác minh (Assumptions and Verification-Required Items)

Assumption (Giả định) là một yếu tố được cho là đúng mà không có bằng chứng chắc chắn, nhưng cần thiết để tiếp tục công việc. Các giả định cần được ghi lại để quản lý rủi ro.

ID Loại Nội dung Lý do / Tác động Kế hoạch giảm thiểu / xác minh
ASM-001 Giả định kỹ thuật API tra cứu của Tổng cục Thuế có độ sẵn sàng cao (uptime > 99.5%) và thời gian phản hồi đủ nhanh cho quy trình tự động. Nếu giả định sai, quy trình thanh toán sẽ bị tắc nghẽn, ảnh hưởng đến hoạt động và quan hệ với nhà cung cấp. Xây dựng cơ chế thử lại (retry) và quy trình xử lý thủ công dự phòng khi API gặp sự cố kéo dài. Giám sát SLA của API.
ASM-002 Giả định quy trình Tất cả nhà cung cấp của Nova Foods đều có khả năng và sẵn sàng chuyển đổi sang sử dụng hóa đơn điện tử hợp lệ theo Nghị định 123. Nếu có nhà cung cấp chiến lược không thể tuân thủ, việc chặn thanh toán có thể gây đứt gãy chuỗi cung ứng. Giao phòng Mua hàng làm việc với các nhà cung cấp về lộ trình chuyển đổi. Xem xét các phương án xử lý tạm thời (mục VER-002).
VER-001 Cần xác minh Endpoint API, cấu trúc request/response, và các mã lỗi cụ thể của cổng tra cứu hóa đơn của Tổng cục Thuế. Yêu cầu này là bắt buộc để đội ngũ kỹ thuật có thể phát triển tính năng một cách chính xác. Owner: Technical Lead. Thời hạn: 2026-08-21. Hành động: Liên hệ với nhà cung cấp giải pháp VAN-Taxis (nếu có) hoặc nghiên cứu tài liệu kỹ thuật chính thức.
VER-002 Cần xác minh Phê duyệt chính thức về quy trình xử lý ngoại lệ đối với các nhà cung cấp chiến lược không thể cung cấp hóa đơn hợp lệ ngay lập tức. Quyết định này mang tính cân đối giữa rủi ro tuân thủ và rủi ro vận hành, vượt quá thẩm quyền của nhóm dự án. Đây là một điểm cần escalation (leo thang). Owner: Kế toán trưởng, Trưởng phòng Mua hàng. Thời hạn: 2026-08-28. Hành động: Trình bày các phương án (ví dụ: chấp nhận rủi ro trong 3 tháng, yêu cầu cam kết bằng văn bản từ NCC) để ban lãnh đạo phê duyệt.

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

Khả năng truy vết (traceability) là khả năng theo dõi một yêu cầu trong suốt vòng đời của nó, từ nguồn gốc ban đầu đến khi được triển khai và kiểm thử. Một Ma trận Truy vết (Traceability Matrix) là công cụ trực quan hóa các mối liên kết này. Nó đảm bảo rằng mọi yêu cầu nghiệp vụ đều được đáp ứng bởi một giải pháp kỹ thuật, và mọi thành phần của giải pháp đều có thể được truy ngược về một yêu cầu nghiệp vụ cụ thể. Việc này cực kỳ quan trọng để phân tích tác động khi có thay đổi, phục vụ kiểm toán (audit), và chứng minh rằng hệ thống làm đúng những gì được mong đợi.

Bảng dưới đây là một ví dụ cụ thể cho case study Nova Foods, minh họa chuỗi truy vết cho việc triển khai một quy tắc nghiệp vụ mới trong hệ thống ERP. Kịch bản là: Hệ thống phải xác thực rằng nhà cung cấp được chọn khi tạo Đơn Mua hàng (Purchase Order) phải là nhà cung cấp đã được phê duyệt và đang hoạt động. Yêu cầu này được ghi nhận trong Change Request CR-2026-042.

Ma trận này liên kết các đối tượng từ nguồn (upstream – các yêu cầu, nhu cầu ở cấp cao hơn) đến đích (downstream – các giải pháp, tiêu chí chấp nhận, ca kiểm thử ở cấp thấp hơn).

Loại & ID Nguồn (Upstream) Mô tả Nguồn Loại & ID Đích (Downstream) Mô tả Đích Loại Liên kết
CR-2026-042 (Change Request) Yêu cầu bổ sung chức năng xác thực Nhà cung cấp (NCC) khi tạo Đơn Mua hàng (PO) để giảm rủi ro tài chính. NEED-001 (Business Need) Cần giảm thiểu rủi ro thanh toán cho các nhà cung cấp chưa được phê duyệt hoặc không còn hợp tác. Satisfies (Đáp ứng)
NEED-001 (Business Need) Giảm rủi ro thanh toán sai đối tượng. REQ-PUR-015 (Requirement) Hệ thống phải ngăn chặn việc tạo PO cho NCC có trạng thái "Ngừng hoạt động" hoặc "Chưa phê duyệt". Refines (Làm rõ)
REQ-PUR-015 (Requirement) Ngăn chặn tạo PO cho NCC không hợp lệ. BR-PUR-S03 (Business Rule) Một NCC phải có trạng thái (Supplier.status) là 'Active' VÀ 'Approved' để được chọn trên một PO mới. Constrains (Ràng buộc bởi)
REQ-PUR-015 (Requirement) Ngăn chặn tạo PO cho NCC không hợp lệ. AC-PUR-015.1 (Acceptance Criterion) Kịch bản thành công: Khi tạo PO với NCC hợp lệ (Active, Approved), hệ thống cho phép tạo và lưu PO thành công. Verifies (Xác minh)
REQ-PUR-015 (Requirement) Ngăn chặn tạo PO cho NCC không hợp lệ. AC-PUR-015.2 (Acceptance Criterion) Kịch bản thất bại: Khi tạo PO với NCC không hợp lệ (ví dụ: 'Inactive'), hệ thống hiển thị thông báo lỗi "Nhà cung cấp không hợp lệ hoặc đã ngừng hoạt động" và không tạo PO. Verifies (Xác minh)
DATA-API-PUR-PO-CREATE (Data/API) API Endpoint POST /api/v1/purchase-orders và payload chứa supplierId. REQ-PUR-015 (Requirement) Logic xác thực của yêu cầu này phải được áp dụng tại endpoint API này trước khi ghi dữ liệu vào CSDL. Implements (Triển khai)
AC-PUR-015.1 (Acceptance Criterion) Kịch bản thành công. TC-PUR-015-POS-01 (Test Case) Kiểm thử tạo PO thành công với NCC có ID SUP-0078 (trạng thái 'Active', 'Approved'). Derived from (Bắt nguồn từ)
AC-PUR-015.2 (Acceptance Criterion) Kịch bản thất bại. TC-PUR-015-NEG-01 (Test Case) Kiểm thử tạo PO thất bại với NCC có ID SUP-0192 (trạng thái 'Inactive'), xác nhận hệ thống trả về mã lỗi 400 Bad Request và thông báo lỗi chính xác. Derived from (Bắt nguồn từ)

Các định danh (ID) như CR-XXXX, NEED-XXX, REQ-XXX, BR-XXX, AC-XXX, và TC-XXX được quản lý tập trung trong Sổ Đăng ký Định danh Truy vết (/01-curriculum/TRACEABILITY_ID_REGISTRY.md). Việc này đảm bảo tính duy nhất, nhất quán và cho phép tự động hóa việc kiểm tra độ bao phủ của yêu cầu trên toàn bộ dự án mô phỏng Nova Foods. Ma trận này cung cấp bằng chứng rõ ràng rằng tính năng được phát hành trong TMPL-REL-001 này đáp ứng đúng nhu cầu nghiệp vụ ban đầu, được định nghĩa rõ ràng và đã được kiểm thử đầy đủ.

Bằng chứng Kỹ thuật: Bảng Quyết định, Dữ liệu Kiểm thử và API Payload

Phần này cung cấp các bằng chứng kỹ thuật cụ thể để làm rõ và xác minh quy tắc nghiệp vụ BR-PUR-004. Các bằng chứng này phục vụ nhiều mục đích: giúp đội phát triển hiểu rõ logic, hỗ trợ đội kiểm thử (QA) thiết kế kịch bản kiểm thử, và tạo ra một tài liệu tham chiếu không mơ hồ cho tất cả các bên liên quan. Chúng ta sẽ sử dụng Bảng Quyết định (Decision Table), Dữ liệu Kiểm thử (Test Data) và một ví dụ về Tải trọng API (API Payload).

Một Bảng Quyết định là một công cụ phân tích nghiệp vụ được chuẩn hóa (theo IIBA BABOK Guide) để trình bày các quy tắc nghiệp vụ phức tạp một cách có cấu trúc. Bảng này liệt kê tất cả các điều kiện có thể xảy ra và hành động tương ứng cho mỗi tổ hợp điều kiện, giúp loại bỏ sự mơ hồ.

Bảng Quyết định cho Quy tắc BR-PUR-004

Quy tắc nghiệp vụ: Chỉ được phép tạo Đơn Mua hàng (PO) cho Nhà Cung cấp (NCC) có trạng thái 'Hoạt động' (Active) và 'Đã phê duyệt' (Approved).

Điều kiện / Hành động Quy tắc 1 Quy tắc 2 Quy tắc 3 Quy tắc 4
Điều kiện
1. Trạng thái NCC là 'Active' Có Có Không -
2. Tình trạng phê duyệt NCC là 'Approved' Có Không - -
Hành động
1. Cho phép tạo Đơn Mua hàng X
2. Từ chối và trả về lỗi SUPPLIER_NOT_APPROVED X
3. Từ chối và trả về lỗi SUPPLIER_NOT_ACTIVE X X

Ghi chú: Dấu gạch ngang (-) có nghĩa là "không quan tâm" (don't care), tức là giá trị của điều kiện đó không ảnh hưởng đến kết quả của quy tắc.

Dữ liệu Kiểm thử Mô phỏng cho Nova Foods

Dữ liệu kiểm thử được tạo ra để xác minh từng quy tắc trong bảng quyết định. Đây là cơ sở để thực thi các kịch bản kiểm thử (Test Case) đã được định danh trong ma trận truy vết.

ID Dữ liệu ID NCC Trạng thái Tình trạng Phê duyệt Kịch bản Kiểm thử Liên quan Kết quả Mong đợi
TD-PUR-001 SUP-0078 Active Approved TC-PUR-015-POS-01 Thành công: Tạo Đơn Mua hàng thành công.
TD-PUR-002 SUP-0192 Inactive Approved TC-PUR-015-NEG-01 Thất bại: Hệ thống trả về lỗi 400 Bad Request với mã lỗi SUPPLIER_NOT_ACTIVE.
TD-PUR-003 SUP-0451 Active Rejected TC-PUR-015-NEG-02 Thất bại: Hệ thống trả về lỗi 400 Bad Request với mã lỗi SUPPLIER_NOT_APPROVED.
TD-PUR-004 SUP-0310 Pending Not Submitted TC-PUR-015-NEG-03 Thất bại: Hệ thống trả về lỗi 400 Bad Request với mã lỗi SUPPLIER_NOT_ACTIVE (logic coi Pending là không hoạt động).

Ví dụ về Tải trọng API (API Payload Example)

Đây là một ví dụ về API Payload—dữ liệu được gửi trong một yêu cầu API—để tạo một Đơn Mua hàng mới. Yêu cầu này mô phỏng kịch bản thành công (TC-PUR-015-POS-01) bằng cách sử dụng nhà cung cấp hợp lệ SUP-0078. Định dạng JSON này là tiêu chuẩn cho các API hiện đại.

Yêu cầu: POST /api/v1/purchase-orders

{
  "supplierId": "SUP-0078",
  "orderDate": "2026-08-15",
  "expectedDeliveryDate": "2026-09-01",
  "currency": "VND",
  "notes": "Yêu cầu giao hàng trước 16:00. Lô hàng cho kho Bình Dương.",
  "lineItems": [
    {
      "productId": "NF-FRZ-VEG-0012",
      "productName": "Đậu Hà Lan đông lạnh (Hạt)",
      "quantity": 500,
      "unit": "kg",
      "unitPrice": 45000
    },
    {
      "productId": "NF-FRZ-VEG-0025",
      "productName": "Ngô ngọt đông lạnh (Hạt)",
      "quantity": 750,
      "unit": "kg",
      "unitPrice": 38000
    }
  ]
}

5. Tier 4 — Senior BA Quality Gate

Cổng chất lượng này là chốt chặn cuối cùng do một Business Analyst (BA) cấp cao thực hiện trước khi một tài liệu yêu cầu (requirement artifact) được xem xét để đưa vào baseline—phiên bản chính thức được kiểm soát. Mục tiêu là đảm bảo tài liệu đủ chất lượng, giảm thiểu rủi ro và chi phí làm lại ở các giai đoạn sau.

Bảng dưới đây là danh sách kiểm tra (checklist) chi tiết, định nghĩa các tiêu chí Đạt (Pass), Không Đạt (Fail), và các điều kiện kích hoạt Dừng (Stop) hoặc Leo thang (Escalate). "Dừng" có nghĩa là tài liệu phải được trả lại cho người soạn để sửa chữa ngay lập tức. "Leo thang" có nghĩa là vấn đề cần được báo cáo lên các vai trò có thẩm quyền cao hơn (ví dụ: Chủ sở hữu Nghiệp vụ, Kiến trúc sư, Pháp lý) để giải quyết.

Bảng Tiêu chí Đánh giá Chất lượng của Senior BA

Hạng mục Kiểm tra Tiêu chí Đạt (Pass Criteria) Tiêu chí Không Đạt (Fail Criteria) Điều kiện Dừng/Leo thang (Stop/Escalate Condition)
Tính Hoàn chỉnh (Completeness) Mọi mục, trường, bảng trong template đã được điền. Không có placeholder TBD, TODO hoặc bị bỏ trống. Metadata quản trị đầy đủ. Thiếu nội dung ở các phần bắt buộc. Dùng placeholder chung chung. Thiếu dữ liệu ví dụ cần thiết để làm rõ yêu cầu. DỪNG: Thiếu một phần (section) quan trọng hoặc thiếu toàn bộ metadata quản trị. Tài liệu không thể được review một cách có ý nghĩa.
Tính Nhất quán (Consistency) Thuật ngữ, định danh (ID), phiên bản, định dạng dữ liệu được dùng nhất quán trong toàn bộ tài liệu và khớp với các tài liệu liên quan trong corpus. Sử dụng các thuật ngữ khác nhau cho cùng một khái niệm (ví dụ: "Đơn Mua hàng" và "Purchase Order"). Dữ liệu ví dụ mâu thuẫn. LEO THANG: Xung đột định danh canonical (ví dụ: tài liệu này ghi NF-FRZ-VEG-0012 nhưng Data Dictionary ghi khác). Cần có quyết định từ người quản lý corpus.
Tính Khả thi Kiểm thử (Testability) Mỗi yêu cầu hoặc tiêu chí chấp nhận (acceptance criterion) đều rõ ràng, cụ thể, có thể đo lường được, và có thể viết một test case để xác minh Đạt/Không Đạt. Tiêu chí chấp nhận mơ hồ, mang tính chủ quan (ví dụ: "giao diện thân thiện với người dùng", "xử lý nhanh"). DỪNG: Một yêu cầu cốt lõi không thể kiểm thử được về mặt kỹ thuật hoặc nghiệp vụ. Yêu cầu BA làm lại cho đến khi có thể kiểm thử.
Khả năng Truy vết (Traceability) Mọi yêu cầu đều có liên kết ngược (trace) tới một nguồn nghiệp vụ hoặc mục tiêu dự án. Mọi thay đổi đều được ghi nhận trong lịch sử phiên bản. Tồn tại yêu cầu "mồ côi" không rõ nguồn gốc hoặc lý do. Không thể truy vết từ yêu cầu tới thiết kế hoặc kiểm thử. DỪNG: Chuỗi truy vết bị đứt gãy nghiêm trọng (ví dụ: không có liên kết nào từ yêu cầu chức năng đến mục tiêu kinh doanh). Phạm vi của tài liệu không được xác minh.
Thẩm quyền Nguồn (Source Authority) Nguồn tham chiếu (pháp lý, tiêu chuẩn ngành) được trích dẫn chính xác. Các giả định nghiệp vụ được ghi rõ và đánh dấu "Cần xác minh". Trích dẫn sai luật, sai phiên bản tiêu chuẩn. Diễn giải một giả định như một sự thật đã được xác nhận mà không có bằng chứng. DỪNG & LEO THANG: Diễn giải sai một quy định pháp lý, kế toán, hoặc bảo mật quan trọng. Báo cáo ngay cho chủ sở hữu pháp lý/kế toán/bảo mật.
Quyền sở hữu (Ownership) Mỗi quy tắc nghiệp vụ, quyết định, hoặc vùng dữ liệu đều có một vai trò sở hữu (Owner) rõ ràng được xác định. Một quyết định quan trọng được ghi nhận mà không nêu rõ ai là người ra quyết định hoặc chịu trách nhiệm về nó. LEO THANG: Một quyết định được ghi nhận là do một vai trò không có thẩm quyền đưa ra (ví dụ: BA quyết định kiến trúc kỹ thuật). Cần chuyển cho đúng Owner.
Ranh giới (Boundaries) Xác định rõ ranh giới hệ thống. Tôn trọng ranh giới thẩm quyền về pháp lý, kế toán, bảo mật và quyền riêng tư (privacy). Yêu cầu mô tả chức năng vi phạm chính sách bảo mật của công ty hoặc luật pháp (ví dụ: Luật Bảo vệ dữ liệu cá nhân). DỪNG & LEO THANG NGAY LẬP TỨC: Phát hiện yêu cầu vi phạm pháp luật, quy định kế toán trọng yếu, hoặc tạo ra lỗ hổng bảo mật nghiêm trọng (tham chiếu OWASP).
Tác động Thay đổi (Change Impact) Phân tích tác động thay đổi (impact analysis) xác định đầy đủ các quy trình, hệ thống, và nhóm người dùng bị ảnh hưởng. Đánh giá tác động hời hợt, bỏ sót các bên liên quan hoặc hệ thống phụ thuộc quan trọng. DỪNG: Một thay đổi có tác động lan rộng trên toàn tổ chức nhưng lại được ghi nhận là "tác động thấp". Yêu cầu thực hiện lại việc phân tích tác động.

Bảng kiểm Cổng Chất lượng (Quality Gate) của Senior BA

Bộ tiêu chí kiểm tra cuối cùng trước khi xem xét baseline. Mục đích: đảm bảo chất lượng, nhất quán, khả thi. Không phải phê duyệt nghiệp vụ. Một mục rơi vào "Dừng/Làm lại" -> toàn bộ artifact bị chặn, trả lại cho Owner để sửa.

Hạng mục Nội dung kiểm tra Định nghĩa "Đạt" (Pass) Định nghĩa "Dừng/Làm lại" (Stop/Rework)
Tính đầy đủ (Completeness) Tất cả các phần bắt buộc trong Tier 3 của template đã được điền đủ chưa? Không còn placeholder? Mọi trường dữ liệu, bảng, mô tả trong Phần 3 và Phần 4 được điền với dữ liệu mô phỏng Nova Foods. Không còn placeholder <...> hoặc ghi chú TBD. Còn sót placeholder, trường bắt buộc bị bỏ trống, hoặc sử dụng dữ liệu chung chung không thuộc case study Nova Foods.
Tính nhất quán (Consistency) Thuật ngữ, ID, quy tắc nghiệp vụ có nhất quán trong toàn tài liệu và khớp với các nguồn canonical (TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES) không? Các ID (RQ-NF-XXX), tên trường, trạng thái (IN_REVIEW) khớp với các artifact quản trị trung tâm. Thuật ngữ dùng đồng nhất. Mâu thuẫn ID, định nghĩa thuật ngữ không nhất quán, hoặc dùng một giá trị dữ liệu theo nhiều cách khác nhau.
Khả năng kiểm thử (Testability) Tiêu chí chấp nhận (Acceptance Criteria - AC) có đủ rõ ràng để QA viết test case không? Mỗi AC là một câu lệnh đơn, có thể kiểm chứng pass/fail rõ ràng. Ví dụ: "Hệ thống từ chối quantity < 1 với lỗi ERR_INVALID_QTY." (Dựa trên ISTQB). AC mơ hồ ("giao diện thân thiện"), gộp nhiều điều kiện, hoặc không thể đo lường ("phản hồi nhanh").
Khả năng truy vết (Traceability) Mọi yêu cầu, quy tắc có thể truy ngược về nguồn gốc nghiệp vụ không? Không có yêu cầu "mồ côi"? Mọi RQ-NF-XXX liên kết ngược tới một NEED-ID-XXX hoặc nguồn gốc được ghi nhận. Mọi thay đổi trong release notes liên kết tới một CHANGE-ID-XXX. Tồn tại yêu cầu hoặc quy tắc không rõ nguồn gốc, không có ID truy vết, không liên kết tới mục tiêu nghiệp vụ nào.
Thẩm quyền nguồn (Source Authority) Yêu cầu pháp lý/kế toán/bảo mật có trích dẫn đúng nguồn (00_SOURCE_MAP.md) và được đánh dấu "Cần xác minh" không? Yêu cầu tuân thủ có tham chiếu nguồn chính thức và ghi rõ cần Legal/Accounting/Security Owner xác nhận. BA tự diễn giải luật hoặc tiêu chuẩn và trình bày như sự thật đã xác nhận. Thiếu nhãn "cần xác minh".
Quyền sở hữu (Ownership) Mỗi quy tắc nghiệp vụ (business rule), phần tử dữ liệu, yêu cầu có Owner nghiệp vụ rõ ràng không? Mỗi RULE-NF-XXX và RQ-NF-XXX đều có một Business Owner được chỉ định, chịu trách nhiệm ra quyết định. Tồn tại quy tắc hoặc yêu cầu không có Owner. Không rõ ai trả lời khi có xung đột.
Ranh giới vai trò (Role Boundaries) Tài liệu có lấn sân sang quyết định của Kiến trúc sư, Pháp lý, Kế toán, hay Bảo mật không? Tài liệu tập trung vào "CÁI GÌ" (what), không phải "LÀM THẾ NÀO" (how). Không đặc tả công nghệ, cấu trúc DB, thuật toán, hay diễn giải thuế. Tham chiếu rủi ro OWASP API Security Top 10 nhưng không thiết kế giải pháp. Tài liệu chứa sơ đồ triển khai, lựa chọn ngôn ngữ lập trình, định nghĩa schema database chi tiết, tính toán thuế thay cho kế toán.
Tác động thay đổi (Change Impact) Phân tích tác động thay đổi đã xác định đủ hệ thống, quy trình, và nhóm người dùng bị ảnh hưởng chưa? Phần phân tích tác động liệt kê cụ thể các module ERP (ví dụ: Inventory), quy trình (ví dụ: Quy trình nhập kho), và vai trò người dùng (ví dụ: Nhân viên kho) bị ảnh hưởng. Chỉ mô tả tính năng mới mà không phân tích nó ảnh hưởng đến ai và cái gì. Ghi "Không có tác động" mà không có bằng chứng.

Áp dụng Checklist vào Ví dụ Nova Foods

Bảng dưới đây ghi nhận kết quả rà soát ví dụ Nova Foods hoàn chỉnh (Mục 3 và 4) theo checklist chất lượng được định nghĩa ở mục trên. Kết quả này mang tính tham khảo cho mục đích học tập và không cấu thành phê duyệt.

Mã kiểm tra Hạng mục Kiểm tra Kết quả Ghi chú / Bằng chứng
QG-REL-01 Tính đầy đủ: Các trường trong Core Record (Mục 3) được điền đủ, không có TBD/TODO. ĐẠT Mọi trường bắt buộc như Release ID, Version, Status, Release Date đều có giá trị cụ thể, phù hợp với yêu cầu của template. Ví dụ, Release ID: REL-2027-Q1-003.
QG-REL-02 Tính nhất quán: Thông tin phiên bản, trạng thái và ngày tháng nhất quán giữa các mục. ĐẠT Phiên bản v1.5.0 và trạng thái READY_FOR_UAT trong ví dụ khớp với các chi tiết được mô tả trong các phần liên quan, không có mâu thuẫn.
QG-REL-03 Tính kiểm thử: Các tiêu chí chấp nhận (Acceptance Criteria) có thể kiểm thử được, rõ ràng và không mơ hồ. CẦN LÀM RÕ Tiêu chí AC-PO-045: "Hệ thống phải phản hồi nhanh". Thuật ngữ "nhanh" không đo lường được, vi phạm nguyên tắc SMART. Cần định lượng cụ thể (ví dụ: "phản hồi trong vòng 2 giây với 50 người dùng đồng thời"). Tham chiếu ISTQB CTFL Syllabus v4.0.1 về testability.
QG-REL-04 Tính truy vết (Traceability): Các yêu cầu, quy tắc nghiệp vụ và mục trong backlog có ID hợp lệ, tham chiếu về nguồn gốc. ĐẠT Các mã như BR-INV-007 và REQ-PUR-021 được liệt kê có định dạng hợp lệ, cho phép truy vết về các artifact tương ứng như CANONICAL_BUSINESS_RULES.md và backlog sản phẩm (giả định).
QG-REL-05 Thẩm quyền nguồn (Source Authority): Các yêu cầu liên quan đến pháp lý, kế toán, thuế có ghi rõ cần xác minh bởi người có thẩm quyền. ĐẠT Yêu cầu REQ-FIN-012 về định dạng hóa đơn điện tử có ghi chú "Cần xác minh bởi bộ phận Kế toán theo Nghị định 123/2020/NĐ-CP". Điều này phân định rõ thẩm quyền của BA và chủ sở hữu nghiệp vụ.
QG-REL-06 Ranh giới Bảo mật/Riêng tư: Tác động đến dữ liệu cá nhân (PII) và các khía cạnh bảo mật được xác định và đánh giá. CẦN LÀM RÕ Mục Security & Privacy Impact ghi "Không có tác động". Tuy nhiên, tính năng thay đổi thông tin nhà cung cấp có thể chứa dữ liệu của người liên hệ (tên, email, SĐT) là PII. Cần xác nhận lại theo Luật 91/2025/QH15. Tham chiếu CANONICAL_DATA_DICTIONARY.md để xác định các trường PII.
QG-REL-07 Tác động thay đổi: Phân tích tác động đến các quy trình và hệ thống liên quan (upstream/downstream) đã đầy đủ. ĐẠT Bảng Upstream/Downstream Impact đã liệt kê tác động đến Hệ thống Quản lý Kho (WMS) và quy trình Đối soát Công nợ cuối tháng. Phân tích này là phù hợp với phạm vi thay đổi.

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

Kiểm tra chéo bảo đảm tính nhất quán giữa Ghi chú phát hành và artifact nguồn. Mọi artifact trong corpus tuân thủ nguồn quản trị trung tâm, gọi là Nguồn chân lý duy nhất (Single Source of Truth). Mâu thuẫn giữa tài liệu gây lỗi triển khai, hiểu sai yêu cầu, quyết định nghiệp vụ thiếu căn cứ và tác động hạ nguồn chưa được kiểm soát.

Bảng dưới đây ghi nhận kiểm tra chéo cho Ghi chú phát hành mô phỏng REL-NF-2408-001 trong bối cảnh Nova Foods. QA, Development và Business Owner dùng kết quả để rà soát trước khi nhận tài liệu để xem xét. Mỗi dòng đối chiếu một thông tin trong release notes với nguồn canonical có thẩm quyền.

Bảng kiểm tra tính nhất quán liên tệp cho REL-NF-2408-001

Hạng mục kiểm tra Nguồn chân lý (Canonical Source) Tiêu chí chấp nhận Giá trị thực tế trong REL-NF-2408-001 Kết quả Hành động khắc phục
Metadata quản trị /01-curriculum/01_CURRICULUM_ARCHITECTURE.md version phải là v0.9.0. status phải là IN_REVIEW. version: v0.9.0, status: IN_REVIEW ĐẠT Không cần.
Định danh yêu cầu /01-curriculum/TRACEABILITY_ID_REGISTRY.md Mọi ID yêu cầu, gồm REQ-PUR-021 và REQ-ACC-045, phải được đăng ký trong registry. Đề cập REQ-PUR-021 và REQ-ACC-045. ĐẠT Không cần.
Định danh Quy tắc nghiệp vụ /01-curriculum/CANONICAL_BUSINESS_RULES.md ID BR-INV-007 phải tồn tại và mô tả trong release notes phải khớp catalog quy tắc. Mô tả BR-INV-007 là “Nhà cung cấp phải có mã số thuế hợp lệ”. ĐẠT Không cần.
Định danh Dữ liệu /01-curriculum/CANONICAL_DATA_DICTIONARY.md Mọi trường dữ liệu được đề cập phải khớp định nghĩa từ điển dữ liệu. Đề cập trường supplier_id. ĐẠT Không cần.
Mâu thuẫn định danh /01-curriculum/TRACEABILITY_ID_REGISTRY.md Không dùng ID chưa đăng ký hoặc sai định dạng. Đề cập tính năng mới PUR-099. ID này không theo định dạng ID yêu cầu đã nêu. KHÔNG ĐẠT BA sửa tham chiếu PUR-099 thành REQ-PUR-022 nếu REQ-PUR-022 đã đăng ký và mô tả đúng thay đổi. Nếu thay đổi là yêu cầu mới, Owner yêu cầu đăng ký ID trong TRACEABILITY_ID_REGISTRY.md trước khi BA cập nhật release notes. Không dùng PUR-099 trong bản sửa.
Mâu thuẫn định nghĩa dữ liệu /01-curriculum/CANONICAL_DATA_DICTIONARY.md Release notes phải mô tả payment_term là String (ENUM) với giá trị NET30, NET60, EOM. Release notes mô tả payment_term là số nguyên biểu thị số ngày. KHÔNG ĐẠT BA sửa mô tả trường thành String (ENUM) và chỉ nêu các giá trị NET30, NET60, EOM. Development và QA rà soát payload, mapping và test case dùng payment_term để tránh gửi hoặc kiểm tra giá trị số nguyên.
Tác động hạ nguồn (Downstream) Đặc tả tích hợp hệ thống WMS mô phỏng Release notes phải phản ánh tác động tới hệ thống phụ thuộc dùng dữ liệu thay đổi. Release notes ghi “Không ảnh hưởng đến hệ thống quản lý kho (WMS)”, trong khi WMS dùng supplier_status để đồng bộ trạng thái nhà cung cấp. KHÔNG ĐẠT BA cập nhật mục tác động hạ nguồn: thay đổi supplier_status tác động đồng bộ WMS. Owner tích hợp WMS nhận thông báo, xác nhận mapping trường và kiểm tra luồng đồng bộ trước khi release notes được chuyển giao để xem xét.
Tham chiếu nguồn pháp lý /00-research/00_SOURCE_MAP.md Mọi nguồn pháp lý được trích dẫn phải có trong danh sách nguồn đã xác minh. Trích dẫn Nghị định 123/2020/NĐ-CP về hóa đơn. ĐẠT Không cần.

Các dòng KHÔNG ĐẠT là chênh lệch cần xử lý trong artifact liên quan. REL-NF-2408-001 vẫn giữ trạng thái IN_REVIEW; bảng không tạo phê duyệt, không tạo baseline và không cho phép triển khai.

Các Vấn Đề Mở, Giả Định, và Yêu Cầu Xác Minh

Bảng sau theo dõi vấn đề mở, giả định dự án và mục cần xác minh liên quan bản phát hành. Mỗi mục ghi rõ owner, artifact bị ảnh hưởng, hậu quả và hành động. Các mục phải có kết quả xác nhận tại artifact nguồn trước khi bất kỳ vai trò có thẩm quyền nào xem xét thay đổi trạng thái artifact nguồn. Release notes này vẫn là IN_REVIEW.

ID Theo Dõi Phân Loại Mô Tả Chi Tiết ID/Artifact Bị Ảnh Hưởng Owner Chịu Trách Nhiệm Mức Độ Ảnh Hưởng Hành Động Tiếp Theo
VER-REL-001-01 Verification Required Cần xác minh công thức tính thuế GTGT cho mặt hàng nông sản chưa qua chế biến bán cho khách hàng doanh nghiệp theo quy định hiện hành. BR-FIN-025 mới mô tả nguyên tắc chung, chưa nêu công thức áp dụng. BR-FIN-025, CANONICAL_BUSINESS_RULES.md Accounting Owner Cao. Công thức sai có thể gây rủi ro tuân thủ thuế và phạt tài chính. BA tổ chức họp với Accounting Owner trước 2026-08-15. Accounting Owner xác nhận công thức và điều kiện áp dụng tại artifact nguồn. BA cập nhật BR-FIN-025, truy vết liên quan và nội dung release notes sau khi có xác nhận.
ASMP-REL-001-01 Project Assumption Giả định API bên thứ ba của hãng vận chuyển “Tốc Hành Logistics” xử lý 500 yêu cầu tạo đơn hàng mỗi phút trong giờ cao điểm 09:00–11:00. SLA hiện tại không nêu năng lực chịu tải. INT-API-004 (Đặc tả tích hợp Tốc Hành Logistics) Technical Architect Trung bình. API quá tải làm trễ tạo đơn hàng vận chuyển và ảnh hưởng thời gian giao hàng cam kết. Technical Architect lập kế hoạch kiểm thử tải tại Staging trong Sprint kế tiếp. Kiểm thử đo ngưỡng xử lý và thời gian phản hồi trung bình dưới tải nặng. Owner cập nhật INT-API-004 bằng kết quả đo; BA cập nhật tác động triển khai nếu kết quả không hỗ trợ giả định 500 yêu cầu mỗi phút.
ISSUE-REL-001-01 Open Issue BR-LOG-011 (“Ưu tiên các lô hàng khẩn cấp”) chưa định nghĩa tiêu chí xác định lô hàng khẩn cấp. Diễn giải tùy ý có thể gây xử lý kho không nhất quán. BR-LOG-011, CANONICAL_BUSINESS_RULES.md, Quy trình vận hành kho Business Owner (Logistics) Trung bình. Nhân viên kho khó xác định thứ tự xử lý; đơn hàng quan trọng có thể bị trễ. BA tổ chức workshop với Business Owner (Logistics) trước 2026-08-20. Business Owner quyết định tiêu chí nghiệp vụ, gồm điều kiện khách hàng, giá trị đơn hàng hoặc cờ ưu tiên thủ công nếu được chấp nhận tại quy trình vận hành. BA ghi tiêu chí đã quyết định vào BR-LOG-011 và cập nhật truy vết.
VER-REL-001-02 Verification Required Cần xác minh định dạng XML cuối cùng cho Hóa đơn điện tử theo Nghị định 123/2020/NĐ-CP và thông tư hướng dẫn được áp dụng trong artifact nguồn. Payload mẫu đã có nhưng chưa có xác nhận từ bộ phận pháp chế. TMPL-FIN-003_e-invoice-payload.xml, CHAPTER 18 - INVOICING Legal/Compliance Owner Cao. Định dạng không tuân thủ có thể làm hóa đơn không hợp lệ, tạo rủi ro pháp lý và gián đoạn kinh doanh. BA gửi TMPL-FIN-003_e-invoice-payload.xml cùng đặc tả liên quan cho Legal/Compliance Owner trước 2026-08-18. Legal/Compliance Owner ghi kết luận rà soát bằng văn bản hoặc email xác nhận. BA chỉ cập nhật release notes theo kết luận đã được ghi nhận.
ASMP-REL-001-02 Project Assumption Giả định bộ phân quyền trong CHAPTER 11 - ACCESS CONTROL đủ cho kế toán, nhân viên kho và nhân viên bán hàng trong lần go-live đầu tiên. CHAPTER 11 - ACCESS CONTROL, USER-ROLE-MATRIX.xlsx Product Owner Trung bình. Quyền thiếu hoặc thừa có thể làm lộ dữ liệu hoặc chặn tác vụ vận hành cần thiết. Product Owner tổ chức UAT theo từng vai trò. QA ghi kết quả từng luồng vào bằng chứng UAT; Product Owner xác nhận quyền cần sửa trong USER-ROLE-MATRIX.xlsx; BA cập nhật release notes khi thay đổi quyền có tác động người dùng hoặc vận hành.

Quy tắc chuyển giao và lan truyền thay đổi

Tài liệu và nội dung trong phần này giữ trạng thái IN_REVIEW. “Chuyển giao” (handoff) nghĩa là cung cấp release notes cho QA Lead, Architect, Business Owner hoặc owner liên quan để xem xét chéo. Chuyển giao không phải lệnh triển khai, không phải chấp nhận người dùng, không phải cho phép sử dụng production và không thay thế phê duyệt tại artifact nguồn.

Mã Quy Tắc Quy Tắc Diễn Giải và Ranh Giới Thẩm Quyền
REL-HANDOFF-01 Chuyển giao chỉ để xem xét QA Lead, Architect và Business Owner đối chiếu release notes với artifact thuộc quyền quản lý của họ. Người nhận ghi nhận mâu thuẫn, tác động và bằng chứng cần bổ sung. Việc nhận tài liệu không cấu thành chỉ thị thực thi.
REL-HANDOFF-02 Bảo toàn trạng thái IN_REVIEW Chuyển giao không đổi trạng thái của TMPL-REL-001. TMPL-REL-001 không được đánh dấu APPROVED hoặc BASELINED chỉ vì có người nhận, rà soát hoặc phản hồi.
REL-HANDOFF-03 Phê duyệt phải ở nguồn Owner có thẩm quyền phê duyệt tại artifact gốc, như tài liệu yêu cầu REQ-NF-INV-005. Release notes chỉ tổng hợp trạng thái, quyết định và tham chiếu; không thay thế chữ ký, email xác nhận hoặc phê duyệt tại nguồn.
REL-HANDOFF-04 Mâu thuẫn chặn nội dung bị ảnh hưởng Khi kiểm tra chéo có kết quả KHÔNG ĐẠT, BA không mô tả mục bị ảnh hưởng như đã sẵn sàng triển khai. Owner artifact nguồn phải sửa hoặc xác nhận quyết định tại nguồn; BA cập nhật release notes theo artifact nguồn đã cập nhật.
REL-HANDOFF-05 Tác động hạ nguồn phải có owner Khi thay đổi dữ liệu, schema, API, quy tắc hoặc cấu hình tác động hệ thống phụ thuộc, BA ghi hệ thống, dữ liệu bị ảnh hưởng, owner nhận thông báo và hành động kiểm tra. Owner hệ thống phụ thuộc chịu trách nhiệm xác nhận artifact thuộc phạm vi của họ.

Lan truyền thay đổi được kiểm soát theo artifact nguồn. Khi artifact nguồn được liệt kê trong release notes, như quy tắc trong /01-curriculum/CANONICAL_BUSINESS_RULES.md, thay đổi nội dung tại nguồn làm v0.9.0 không còn đồng bộ đối với nội dung bị ảnh hưởng. Owner artifact nguồn thông báo thay đổi cho Owner của TMPL-REL-001, kèm ID, phạm vi và hậu quả đã biết. Owner của TMPL-REL-001 tạo phiên bản kế tiếp, như v0.9.1, cập nhật nội dung bị ảnh hưởng và ghi lý do thay đổi trong lịch sử phiên bản. Phiên bản mới vẫn giữ IN_REVIEW cho đến khi quy trình quản trị tại artifact nguồn hoàn tất theo thẩm quyền.

Khi phát hiện mâu thuẫn hoặc vấn đề vượt thẩm quyền của Principal IT Business Analyst, BA dừng quyết định trong release notes và leo thang tới owner có thẩm quyền, gồm Legal, Accounting, Security hoặc Architecture. Quy tắc định tuyến theo /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Release notes chỉ ghi nhận ID vấn đề, artifact bị ảnh hưởng, owner tiếp theo, hành động yêu cầu và hậu quả nếu chưa xử lý. Release notes không tự đặt quy tắc pháp lý, công thức kế toán, quyết định bảo mật, quyết định kiến trúc hoặc quyết định thay owner có thẩm quyền.