/03-templates/TMPL-NFR-001_NON_FUNCTIONAL_REQUIREMENTS.md — Mẫu tài liệu Yêu cầu Phi chức năng (NFR)

Trường kiểm soát	Giá trị
Artifact ID	`TMPL-NFR-001`
Tên tệp được kiểm soát	`/03-templates/TMPL-NFR-001_NON_FUNCTIONAL_REQUIREMENTS.md`
Tiêu đề Artifact	Mẫu tài liệu Yêu cầu Phi chức năng (Non-Functional Requirements - NFR)
Trạng thái (Status)	`IN_REVIEW`
Phiên bản (Version)	`v0.9.0`
Owner	Principal IT Business Analyst / Technical Curriculum Author
Trách nhiệm của Owner	Duy trì tính toàn vẹn và cấu trúc của template, kiểm soát phiên bản, ghi nhận lịch sử thay đổi, và bảo đảm các tầng (Tier) của template được phân định rõ ràng. Owner chịu trách nhiệm đảm bảo template này nhất quán với các artifact khác trong corpus Nova Foods.
Giới hạn thẩm quyền của Owner	Owner không có quyền tự xác nhận baseline, ghi nhận approval, xác nhận tuân thủ pháp lý (legal/compliance sign-off), quyết định kiến trúc, hoặc xác nhận một yêu cầu phi chức năng cụ thể là phù hợp cho môi trường production. Thẩm quyền xác nhận yêu cầu thuộc về các vai trò chuyên môn liên quan (ví dụ: Architect, Security Officer, Business Owner).
Ngày cập nhật gần nhất	`2026-08-07`
Múi giờ quản trị	`Asia/Ho_Chi_Minh`
Locale áp dụng	`vi-VN`; bối cảnh Việt Nam; đơn vị tiền tệ mô phỏng `VND`
Case-study tham chiếu	Nova Foods Trading & Manufacturing — case study mô phỏng giáo dục.
Phân loại Artifact	Controlled template artifact cho curriculum `IT BUSINESS ANALYST — ZERO TO DELIVERY READY`.
Tham chiếu Baseline	Chưa có baseline reference tại `v0.9.0`. Trạng thái `IN_REVIEW` không được diễn giải là `BASELINED`.
Tham chiếu Phê duyệt	Chưa có approval reference tại `v0.9.0`. Sự tồn tại của template, Owner, hay nội dung review không tạo ra phê duyệt ngầm định từ bất kỳ vai trò nào.
Lịch sử thay đổi	`v0.9.0 (2026-08-07)`: Khởi tạo artifact. Thiết lập metadata quản trị và cấu trúc 4 tầng cho mẫu tài liệu Yêu cầu Phi chức năng (NFR). Đặt trạng thái ban đầu là `IN_REVIEW`.
Ranh giới dữ liệu mô phỏng	Cảnh báo: Mọi dữ liệu, yêu cầu, và quyết định trong phần ví dụ Tier 3 (Fully Completed Nova Foods Case) hoàn toàn là dữ liệu tổng hợp, được tạo ra cho mục đích giáo dục trong bối cảnh mô phỏng của Nova Foods. Chúng không đại diện cho yêu cầu thực tế, quyết định kinh doanh, cấu hình hệ thống, hoặc tình trạng tuân thủ của bất kỳ tổ chức nào. Không được sử dụng làm cơ sở cho các hệ thống production.

1. Tier 1 – Metadata, Purpose, and Governance

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

Mẫu này dùng để ghi nhận Yêu cầu Phi chức năng (Non-Functional Requirements - NFR). NFR định nghĩa hệ thống phải hoạt động tốt thế nào, không phải hệ thống làm gì. Các thuộc tính chất lượng như hiệu năng, bảo mật, tính khả dụng, khả năng tương thích và tính dễ sử dụng là NFR. Mục đích chính: tạo nguồn chân lý duy nhất (single source of truth) được kiểm soát cho mọi ràng buộc phi chức năng. Tài liệu NFR là căn cứ cho thiết kế kiến trúc, triển khai, kiểm thử và nghiệm thu hệ thống.

Quy tắc định danh NFR bắt buộc:

Mọi NFR dự án dùng duy nhất định dạng NFR-<CAT>-<NNN>.

NFR: tiền tố cố định cho yêu cầu phi chức năng.
<CAT>: mã danh mục viết hoa, không chứa dấu gạch nối. Ví dụ: PERF, SEC, AVAIL, COMPAT, USABILITY, A11Y.
<NNN>: số thứ tự ba chữ số trong từng danh mục, từ 001.
Ví dụ hợp lệ: NFR-PERF-001, NFR-SEC-001, NFR-A11Y-001.
Không dùng các định dạng khác, gồm NFR-<XXX>, NFR-SPP-PERF-001, hoặc mã có thêm tiền tố dự án. Mã dự án, nếu cần, thuộc artifact hoặc ngữ cảnh truy vết khác; không thuộc Requirement ID.
Lead Business Analyst cấp và duy trì ID. TRACEABILITY_ID_REGISTRY đăng ký ID để ngăn trùng lặp, giữ liên kết với nguồn gốc, thiết kế, kiểm thử và quyết định phê duyệt.

Khi nào dùng: * Bắt đầu dự án, phân hệ lớn, hoặc thay đổi quan trọng có tác động đến kiến trúc hay thuộc tính chất lượng. * Khi cần đặc tả ràng buộc về hiệu năng (performance), bảo mật (security), tính khả dụng (availability), khả năng tương thích (compatibility), khả năng truy cập (accessibility), và tính dễ sử dụng (usability). * Khi cần tạo test basis rõ ràng cho kiểm thử phi chức năng. * Khi một bên liên quan yêu cầu mức chất lượng, giới hạn kỹ thuật, nghĩa vụ tuân thủ, hoặc tiêu chí đo lường mà hệ thống phải đáp ứng.

Khi nào không dùng: * Ghi nhận yêu cầu chức năng (functional requirements). Dùng template đặc tả yêu cầu chức năng hoặc user story. * Ghi nhận quy tắc nghiệp vụ (business rules). Dùng catalog quy tắc nghiệp vụ chính tắc (CANONICAL_BUSINESS_RULES). * Định nghĩa cấu trúc dữ liệu. Dùng từ điển dữ liệu chính tắc (CANONICAL_DATA_DICTIONARY). * Thay đổi rất nhỏ, không tác động thuộc tính chất lượng đã xác định của hệ thống.

Bảng dưới đây xác định cơ chế quản trị cho tài liệu NFR tạo từ template này trong bối cảnh dự án Nova Foods.

Vai trò / Cơ chế	Trách nhiệm và Quyền hạn
Chủ sở hữu Template	`Principal IT Business Analyst / Technical Curriculum Author`. Duy trì cấu trúc, phiên bản, quy tắc định danh và hướng dẫn dùng template trống. Không quyết định nội dung NFR dự án cụ thể.
Chủ sở hữu Nội dung	`Lead Business Analyst` được phân công cho dự án. Thu thập, phân tích, tài liệu hóa, cấp ID theo `NFR-<CAT>-<NNN>`, đăng ký ID, và lấy xác nhận từ bên liên quan cho NFR dự án.
Đối tượng sử dụng	`Solution Architect`, `Development Team`, `QA Team`, `Project Manager`, `Business Stakeholders`. Họ dùng tài liệu NFR hoàn thiện để thiết kế, lập trình, kiểm thử, quản lý phạm vi và nghiệm thu.
Điều kiện tiên quyết	Phải có trước khi điền template: `Project Charter`, danh sách bên liên quan, yêu cầu chức năng mức cao. `CANONICAL_BUSINESS_RULES` và `CANONICAL_DATA_DICTIONARY` là đầu vào cần thiết khi NFR phụ thuộc quy tắc nghiệp vụ hoặc dữ liệu.
Tài liệu đầu ra	Tài liệu NFR hoàn chỉnh là đầu vào trực tiếp cho `Architecture Design Document`, `Test Plan`, `Test Cases`, và `System Acceptance Criteria`. Mỗi NFR phải có ID ổn định để các artifact đầu ra truy vết đúng đối tượng.
Thẩm quyền phê duyệt	`Business Owner` phê duyệt NFR ảnh hưởng trực tiếp mục tiêu kinh doanh và trải nghiệm người dùng. `Solution Architect` hoặc `Technical Lead` phê duyệt NFR công nghệ, hiệu năng và bảo mật. `QA Lead` xác nhận NFR có tiêu chí chấp nhận và có thể kiểm thử.
Leo thang (Escalation)	Khi NFR mâu thuẫn, `Lead BA` chủ trì họp để làm rõ tác nhân, ưu tiên, trade-off, hậu quả và quyết định cần có. Không đạt đồng thuận: leo thang lên `Project Manager`. Quyết định ảnh hưởng lớn đến ngân sách hoặc tiến độ: leo thang lên `Steering Committee` (Ban chỉ đạo dự án).

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

Phần này xác định định danh chính thức của template, liên kết với artifact quản trị trung tâm của corpus, liệt kê nguồn tri thức và pháp lý đầu vào, và thiết lập quy tắc kiểm soát thay đổi bắt buộc. Tuân thủ các quy tắc này giữ template nhất quán, truy vết được, và phù hợp kiến trúc tổng thể chương trình học.

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

Bảng này ánh xạ định danh template với manifest quản trị của corpus Nova Foods. Mục tiêu: một nguồn chân lý duy nhất về sự tồn tại, vị trí và trạng thái artifact.

Trường Quản trị	Giá trị Canonical	Lý do & Diễn giải
Artifact ID	`TMPL-NFR-001`	Định danh duy nhất, không thay đổi của template trong toàn corpus. Dùng tham chiếu chéo và kiểm tra phụ thuộc.
Tên tệp Canonical	`/03-templates/TMPL-NFR-001_NON_FUNCTIONAL_REQUIREMENTS.md`	Đường dẫn đầy đủ, không thay đổi của tệp nguồn. Mọi bản sao hoặc tệp xuất không phải bản gốc được kiểm soát.
Đăng ký Manifest	`TEMPLATE_MANIFEST`	Template đăng ký chính thức trong `/01-curriculum/TEMPLATE_MANIFEST.md`. Thay đổi trạng thái, phiên bản hoặc sự tồn tại template phải phản ánh trong manifest này.
Registry Định danh	`TRACEABILITY_ID_REGISTRY`	Mọi NFR cụ thể tạo từ template phải dùng `NFR-<CAT>-<NNN>` và đăng ký trong `/01-curriculum/TRACEABILITY_ID_REGISTRY.md`. Ví dụ: `NFR-SEC-001` là NFR bảo mật; `NFR-PERF-001` là NFR hiệu năng. Registry duy trì tính duy nhất của ID và truy vết đầu-cuối.

Bảng 2: Nguồn Tri thức và Pháp lý Đầu vào

NFR phải dựa trên tiêu chuẩn ngành, good practice và quy định pháp luật phù hợp. Template này dùng các nguồn được xác minh sau đây làm đầu vào phân tích; từng NFR phải nêu nguồn áp dụng, quyết định áp dụng, và bằng chứng kiểm thử phù hợp.

Nguồn Tham chiếu	Vai trò trong Template này
`BABOK Guide v3`	Cung cấp định nghĩa nền tảng về Yêu cầu Phi chức năng (Non-Functional Requirements) và vị trí của chúng trong vòng đời phân tích nghiệp vụ.
`ISO/IEC/IEEE 29148:2018`	Cung cấp cấu trúc và hướng dẫn theo tiêu chuẩn quốc tế về kỹ thuật yêu cầu (requirements engineering), gồm cách đặc tả thuộc tính chất lượng.
`OWASP ASVS 5.0` & `API Security Top 10`	Nguồn chính cho yêu cầu bảo mật ứng dụng, ví dụ `NFR-SEC-001`. Bên phân tích dùng nguồn này để xem xét good practice bảo mật; thẩm quyền kỹ thuật xác nhận mức áp dụng.
`WCAG 2.2`	Nguồn quy chuẩn cho yêu cầu khả năng truy cập (accessibility), ví dụ `NFR-A11Y-001`. Nguồn này hỗ trợ xác định điều kiện để sản phẩm có thể được sử dụng bởi người khuyết tật.
`Luật Bảo vệ dữ liệu cá nhân` & `Nghị định 356/2025/NĐ-CP`	Nguồn đầu vào cho NFR về lưu trữ, xử lý và bảo vệ dữ liệu cá nhân, gồm các ràng buộc cần phân tích về mã hóa và lưu giữ.
`Luật Kế toán` & `Nghị định 123/2020/NĐ-CP`	Nguồn đầu vào cho NFR ERP về tính toàn vẹn, tính không thể chối cãi và thời gian lưu trữ chứng từ, hóa đơn điện tử.

Liên kết đến Chương trình học và Nghĩa vụ Kiểm soát Thay đổi

Liên kết Chương trình học: Nội dung và cách dùng template được giảng dạy, tham chiếu trong handbook về Requirements Elicitation, Requirements Analysis and Design Definition, và Solution Evaluation. Các chương được quản lý trong /01-curriculum/CHAPTER_MANIFEST.md.
Nghĩa vụ Kiểm soát Thay đổi:
1. Mọi thay đổi đối với template, kể cả thay đổi nhỏ, phải được ghi trong bảng "Lịch sử thay đổi" (Change History) ở đầu tài liệu.
2. Mọi thay đổi phải tăng phiên bản, ví dụ từ v0.9.0 lên v0.9.1. Cấm sửa đổi im lặng trên cùng phiên bản.
3. Thay đổi cấu trúc, ví dụ thêm mục lớn trong Tier 2 hoặc thay đổi quy tắc NFR-<CAT>-<NNN>, phải được xem xét tính tương thích với /01-curriculum/CURRICULUM_ARCHITECTURE.md và TRACEABILITY_ID_REGISTRY.
4. Lead Business Analyst phải đánh giá tác động thay đổi định dạng ID lên NFR, RTM, ca kiểm thử, tài liệu kiến trúc và tham chiếu chéo hiện có. ID đã cấp không được đổi chỉ vì đổi cách trình bày; đổi ID làm đứt truy vết và phải được xử lý như thay đổi có kiểm soát.
5. Chỉ vai trò được ủy quyền mới được chuyển trạng thái template từ IN_REVIEW sang BASELINED hoặc APPROVED. Owner artifact không có thẩm quyền này. Trạng thái hiện tại của artifact vẫn là IN_REVIEW.

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

Phần này cung cấp một mẫu (template) trống, sẵn sàng để sao chép-dán, dùng để định nghĩa một Yêu cầu phi chức năng (Non-Functional Requirement - NFR). NFR không mô tả hệ thống làm gì (chức năng), mà mô tả hệ thống phải như thế nào khi hoạt động. Ví dụ: hệ thống phải nhanh, bảo mật, dễ sử dụng, hoặc đáng tin cậy. Các yêu cầu này rất quan trọng vì chúng xác định chất lượng và trải nghiệm của sản phẩm cuối cùng.

Mỗi NFR phải được định nghĩa một cách riêng biệt bằng cách điền đầy đủ thông tin vào cấu trúc bên dưới.

Mẫu định nghĩa một Yêu cầu phi chức năng (NFR)

Bảng dưới đây là cấu trúc hoàn chỉnh để đặc tả một NFR. Hãy sao chép toàn bộ khối markdown này cho mỗi yêu cầu mới.

Thuộc tính Yêu cầu (Attribute)	Nội dung (Content)	Hướng dẫn và Diễn giải (Guidance & Explanation)
ID Yêu cầu	`NFR-<CAT>-<NNN>`	Bắt buộc. Mã định danh duy nhất, không thay đổi. CAT là mã viết tắt của loại yêu cầu (ví dụ: `PERF` cho Performance, `SEC` cho Security, `USBL` cho Usability). NNN là số thứ tự có 3 chữ số (ví dụ: `001`). Ví dụ: `NFR-SEC-001`.
Tên Yêu cầu	`<Tên ngắn gọn, mô tả trọng tâm của yêu cầu>`	Bắt buộc. Tóm tắt yêu cầu trong khoảng 5-10 từ để dễ dàng tham chiếu. Ví dụ: "Thời gian phản hồi API tạo đơn hàng", "Mã hóa dữ liệu khách hàng khi lưu trữ".
Loại Yêu cầu (Category)	`<Chọn một trong các giá trị được liệt kê>`	Bắt buộc. Phân loại yêu cầu giúp nhóm và quản lý. Các giá trị được chấp nhận: `Performance` (Hiệu năng), `Security` (Bảo mật), `Usability` (Tính khả dụng), `Reliability` (Độ tin cậy), `Scalability` (Khả năng mở rộng), `Maintainability` (Khả năng bảo trì), `Portability` (Tính tương thích), `Compliance` (Tuân thủ).
Nguồn gốc (Source)	`<ID của nguồn gốc hoặc mô tả>`	Bắt buộc. Chỉ rõ yêu cầu này đến từ đâu. Ví dụ: "Phỏng vấn Kế toán trưởng ngày YYYY-MM-DD", "Luật An toàn thực phẩm 55/2010/QH12", "BR-FIN-001", "Stakeholder: Giám đốc Kinh doanh".
Độ ưu tiên (Priority)	`<Chọn một: Must Have, Should Have, Could Have, Won't Have>`	Bắt buộc. Sử dụng phương pháp MoSCoW để xác định tầm quan trọng của yêu cầu đối với sự thành công của dự án. Must: Bắt buộc phải có. Should: Nên có. Could: Có thể có nếu còn thời gian/nguồn lực. Won't: Sẽ không làm trong phiên bản này.
Mô tả (Description)	`<Mô tả chi tiết yêu cầu dưới dạng mệnh đề "Hệ thống phải...".>`	Bắt buộc. Mô tả rõ ràng, đầy đủ và không mơ hồ về yêu cầu. Ví dụ: "Hệ thống phải mã hóa tất cả dữ liệu định danh cá nhân (PII) của khách hàng trước khi ghi xuống cơ sở dữ liệu."
Lý do/Giá trị nghiệp vụ (Rationale/Business Value)	`<Giải thích tại sao yêu cầu này quan trọng và lợi ích nó mang lại.>`	Bắt buộc. Liên kết yêu cầu kỹ thuật với mục tiêu kinh doanh. Ví dụ: "Để tuân thủ Nghị định 356/2025/NĐ-CP và tránh rủi ro pháp lý, bảo vệ uy tín thương hiệu."
Phạm vi áp dụng (Scope)	`<Liệt kê các module, tính năng, user story, API hoặc thành phần hệ thống bị ảnh hưởng.>`	Bắt buộc. Xác định rõ "ranh giới" của yêu cầu. Ví dụ: "Áp dụng cho các bảng `Customers`, `Suppliers` trong cơ sở dữ liệu và tất cả các API trả về thông tin khách hàng.", "Màn hình Báo cáo Tồn kho".
Tiêu chí Chấp nhận (Acceptance Criteria)	Xem Bảng: Tiêu chí Chấp nhận chi tiết bên dưới.	Bắt buộc. Đây là phần quan trọng nhất, định nghĩa cách để kiểm chứng yêu cầu có được đáp ứng hay không. Các tiêu chí phải SMART (Specific, Measurable, Achievable, Relevant, Time-bound).
Ràng buộc và Giả định (Constraints & Assumptions)	`<Liệt kê các ràng buộc kỹ thuật, ngân sách, hoặc giả định đã được đưa ra khi định nghĩa yêu cầu. Điền "Không có" nếu không áp dụng.>`	Ví dụ: "Ràng buộc: Phải sử dụng thuật toán mã hóa AES-256.", "Giả định: Hạ tầng mạng nội bộ có băng thông tối thiểu 1 Gbps."
Truy vết (Traceability)	`<Liệt kê ID của các artifact liên quan. Điền "Không có" nếu không áp dụng.>`	Liên kết NFR này tới các tài liệu khác để đảm bảo tính nhất quán. Ví dụ: `BR-SEC-004` (Quy tắc nghiệp vụ), `US-115` (User Story), `TC-SEC-010` (Trường hợp kiểm thử), `SRC-LAW-001` (Nguồn tham chiếu).

Bảng: Tiêu chí Chấp nhận (Acceptance Criteria)

Mỗi NFR phải có ít nhất một tiêu chí chấp nhận có thể đo lường được.

Mã Tiêu chí	Nội dung Tiêu chí (Phải đo lường được)	Phương pháp Đo lường/Xác minh	Nguồn Tham chiếu Kỹ thuật (Nếu có)
`AC-NFR-XXX-01`	`<Mô tả tiêu chí cụ thể và có thể đo lường. Ví dụ: "95% các lời gọi API GET /api/v1/products phải hoàn thành trong vòng 250ms.">`	`<Mô tả công cụ hoặc quy trình sẽ được sử dụng để kiểm tra. Ví dụ: "Sử dụng Apache JMeter để chạy load test với 200 người dùng đồng thời trong 15 phút.">`	`<Ví dụ: OWASP ASVS V4.3, WCAG 2.2 SC 1.4.3. Điền "N/A" nếu không áp dụng.>`
`AC-NFR-XXX-02`	`<Mô tả tiêu chí cụ thể và có thể đo lường. Ví dụ: "Mức sử dụng CPU của application server không được vượt quá 80% trong suốt quá trình load test.">`	`<Mô tả công cụ hoặc quy trình. Ví dụ: "Giám sát bằng Prometheus và xem dashboard trên Grafana.">`	`N/A`
`<Thêm dòng nếu cần>`	`<...>`	`<...>`	`<...>`

Bảng: Theo dõi Xem xét và Phê duyệt

Bảng này ghi lại quá trình xem xét và phê duyệt NFR bởi các bên liên quan có thẩm quyền.

Vai trò	Người thực hiện	Ngày	Kết quả (Approved / Rework / Rejected)	Ghi chú (Bắt buộc nếu là Rework/Rejected)
Business Owner	`<Tên hoặc Chức danh>`	`<YYYY-MM-DD>`	`<Chọn một>`	`<Lý do yêu cầu làm lại hoặc từ chối>`
Technical Architect	`<Tên hoặc Chức danh>`	`<YYYY-MM-DD>`	`<Chọn một>`	`<Ghi chú về tính khả thi, ảnh hưởng kỹ thuật>`
QA Lead	`<Tên hoặc Chức danh>`	`<YYYY-MM-DD>`	`<Chọn một>`	`<Ghi chú về khả năng kiểm thử của tiêu chí chấp nhận>`
Security Officer	`<Tên hoặc Chức danh>`	`<YYYY-MM-DD>`	`<Chọn một>`	`<Ghi chú về rủi ro hoặc yêu cầu bảo mật. Chỉ điền khi NFR thuộc loại Security hoặc có liên quan.>`

Cấu trúc Quản trị, Truy vết, và Phê duyệt

Phần này cung cấp các bảng và trường cần thiết để quản lý vòng đời, truy vết nguồn gốc, và ghi nhận phê duyệt cho mỗi Yêu cầu Phi chức năng (Non-Functional Requirement - NFR). Cấu trúc này đảm bảo mọi yêu cầu đều có thể kiểm toán, có bằng chứng và được các bên liên quan xem xét chính thức.

Bảng 1: Metadata và Quản lý Phiên bản

Mỗi NFR phải bắt đầu bằng khối metadata này để định danh và theo dõi trạng thái.

Trường Quản trị	Hướng dẫn và Giá trị
NFR ID	`<Định danh duy nhất, không thay đổi của NFR theo định dạng [CATEGORY]-[NNN], ví dụ: PERF-001, SEC-002, USAB-003>`
Phiên bản	`<Phiên bản của NFR, bắt đầu từ 0.1 cho bản nháp đầu tiên, tăng lên 1.0 khi được phê duyệt lần đầu, ví dụ: 0.1, 1.0, 1.1>`
Trạng thái	`<Trạng thái hiện tại của NFR. Giá trị hợp lệ: DRAFT, IN_REVIEW, APPROVED, REJECTED, DEPRECATED>`
Ngày cập nhật	`<Ngày cập nhật gần nhất theo định dạng YYYY-MM-DD, ví dụ: 2026-09-15>`
Owner	`<Vai trò hoặc cá nhân chịu trách nhiệm chính cho việc định nghĩa và duy trì NFR này, ví dụ: Business Analyst, Technical Architect>`

Bảng 2: Truy vết Nguồn gốc (Traceability)

Bảng này liên kết NFR với các nguồn gốc của nó, như yêu cầu nghiệp vụ, quy định pháp lý, hoặc mục tiêu kinh doanh. Điều này chứng minh tại sao NFR tồn tại.

ID Nguồn	Loại Nguồn	Mô tả liên kết
`<Định danh của artifact nguồn, ví dụ: BR-042, LAW-91/2025/QH15>`	`<Loại artifact nguồn, ví dụ: Business Requirement, Legal Constraint, Architectural Decision>`	`<Giải thích ngắn gọn mối quan hệ, ví dụ: "Yêu cầu mã hóa dữ liệu cá nhân theo Luật 91/2025/QH15.">`
`<Thêm dòng nếu có nhiều nguồn>`	`<...>`	`<...>`

Bảng 3: Bằng chứng Tuân thủ (Evidence)

Sau khi hệ thống được phát triển hoặc cấu hình, bảng này dùng để ghi lại các bằng chứng chứng minh NFR đã được đáp ứng.

ID Bằng chứng	Mô tả Bằng chứng	Tham chiếu (Link/Path)	Trạng thái
`<Định danh cục bộ cho bằng chứng, ví dụ: EVD-PERF-001-01>`	`<Mô tả phương pháp hoặc kết quả, ví dụ: "Báo cáo kiểm thử tải trang đăng nhập với 500 người dùng đồng thời.">`	`<Đường dẫn tới báo cáo, ảnh chụp màn hình, hoặc kết quả log, ví dụ: /test-results/load-test-report-2026-10-20.pdf>`	`<Verified / Not Verified>`
`<Thêm dòng nếu cần>`	`<...>`	`<...>`	`<...>`

Bảng 4: Quản lý Ngoại lệ (Exceptions)

Ghi lại bất kỳ sự sai khác nào được chấp thuận so với NFR gốc. Mọi ngoại lệ đều phải được phê duyệt chính thức.

ID Ngoại lệ	Mô tả Ngoại lệ	Lý do & Tác động	Người phê duyệt	Ngày phê duyệt
`<Định danh duy nhất, ví dụ: EXC-SEC-002-01>`	`<Mô tả rõ phần nào của NFR không được đáp ứng, ví dụ: "Trường dữ liệu 'ghi chú nội bộ' không được mã hóa khi lưu trữ.">`	`<Lý do: Dữ liệu không nhạy cảm, chi phí kỹ thuật cao. Tác động: Rủi ro lộ thông tin vận hành thấp.>`	`<Vai trò phê duyệt, ví dụ: Head of IT, Business Owner>`	`<YYYY-MM-DD>`
`<Thêm dòng nếu cần>`	`<...>`	`<...>`	`<...>`	`<...>`

Bảng 5: Lịch sử Review và Phê duyệt (Sign-off)

Đây là hồ sơ chính thức ghi lại quyết định của các bên liên quan. Một NFR chỉ có hiệu lực khi được các vai trò có thẩm quyền phê duyệt.

Vai trò Review	Người Review	Ngày Review	Quyết định	Ghi chú / Tham chiếu Ticket
`Business Owner`	`<Tên hoặc ID của người có thẩm quyền nghiệp vụ>`	`<YYYY-MM-DD>`	`<Approved / Rejected / Approved with Comments>`	`<Ghi chú nếu có, hoặc ID của ticket yêu cầu chỉnh sửa>`
`Technical Architect`	`<Tên hoặc ID của kiến trúc sư trưởng>`	`<YYYY-MM-DD>`	`<Approved / Rejected / Approved with Comments>`	`<Ghi chú về tính khả thi kỹ thuật hoặc đề xuất thay đổi>`
`QA Lead`	`<Tên hoặc ID của trưởng nhóm đảm bảo chất lượng>`	`<YYYY-MM-DD>`	`<Approved / Rejected / Approved with Comments>`	`<Ghi chú về khả năng kiểm thử và tiêu chí chấp nhận>`
`Security Officer`	`<Tên hoặc ID của người phụ trách an toàn thông tin>`	`<YYYY-MM-DD>`	`<Approved / Rejected / Approved with Comments>`	`<Ghi chú về tuân thủ bảo mật>`
`Legal/Compliance`	`<Tên hoặc ID của người phụ trách pháp chế/tuân thủ>`	`<YYYY-MM-DD>`	`<Approved / Rejected / Approved with Comments>`	`<Ghi chú về tuân thủ quy định pháp luật>`

Hướng dẫn, Quy tắc và Các mẫu điền Template

Phần này cung cấp hướng dẫn chi tiết để điền vào template Yêu cầu Phi chức năng (Non-Functional Requirement - NFR). Việc tuân thủ các quy tắc này đảm bảo tính nhất quán, rõ ràng và có thể kiểm chứng được cho tất cả các NFR trong dự án.

1. Hướng dẫn điền các trường chính và giá trị cho phép

Mỗi trường trong template có một mục đích cụ thể. Bảng dưới đây quy định các giá trị được phép và định dạng để đảm bảo dữ liệu đầu vào nhất quán.

Tên trường (Field Name)	Hướng dẫn điền	Giá trị/Định dạng cho phép (Allowed Values/Format)	Ví dụ
`Requirement ID`	Mã định danh duy nhất cho NFR. Phải được đăng ký trong `TRACEABILITY_ID_REGISTRY.md` để đảm bảo truy vết.	`NFR-` + `XXX` (số thứ tự 3 chữ số). Ví dụ: `NFR-001`.	`NFR-015`
`Category`	Phân loại NFR theo tiêu chuẩn ngành, ví dụ như ISO/IEC 29148.	`Performance`, `Security`, `Reliability`, `Usability`, `Maintainability`, `Portability`.	`Performance`
`Priority`	Mức độ ưu tiên của yêu cầu, quyết định thứ tự thực hiện và mức độ quan trọng khi có xung đột tài nguyên.	`Critical`, `High`, `Medium`, `Low`.	`High`
`Status`	Trạng thái hiện tại của NFR trong vòng đời của nó.	`Draft`, `In Review`, `Approved`, `Rejected`, `Implemented`.	`In Review`
`Source`	Nguồn gốc của yêu cầu (stakeholder, tài liệu pháp lý, chính sách công ty). Ghi rõ ID của nguồn nếu có.	Tham chiếu đến ID stakeholder (`STAKE-XXX`), văn bản pháp lý (`SRC-LEGAL-XXX`), hoặc tài liệu khác.	`STAKE-004: Head of Operations`

2. Quy tắc xác thực (Validation Rules) và các mục có điều kiện

Để đảm bảo chất lượng, một số trường và mục có quy tắc xác thực và điều kiện hiển thị riêng.

Quy tắc #1: Metric phải đo lường được. Một NFR không có chỉ số đo lường (Metric) và tiêu chí chấp nhận (Acceptance Criteria) rõ ràng sẽ không được Approved. Metric phải tuân thủ nguyên tắc SMART (Specific, Measurable, Achievable, Relevant, Time-bound).
- SAI: Hệ thống phải phản hồi nhanh.
- ĐÚNG: Thời gian phản hồi của API GET /api/v1/orders phải < 300ms ở phân vị thứ 95 (95th percentile) với 500 người dùng đồng thời.
Quy tắc #2: Yêu cầu bảo mật phải có phân loại dữ liệu. Nếu trường Category là Security, mục con Data Classification là bắt buộc.
- Phân loại dữ liệu: Public, Internal, Confidential, Restricted.
- Lý do: Điều này tuân thủ nguyên tắc bảo vệ dữ liệu theo chiều sâu và các tiêu chuẩn như OWASP ASVS (V1: Architecture, Design and Threat Modeling Requirements), giúp xác định mức độ kiểm soát an ninh cần thiết.
Quy tắc #3: Liên kết bằng chứng. Mọi quyết định, đặc biệt là Approved hoặc Rejected, phải có bằng chứng được ghi nhận trong bảng Review and Sign-off History.

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

CẢNH BÁO BẢO MẬT: TUYỆT ĐỐI KHÔNG ghi trực tiếp mật khẩu, API key, token, chuỗi kết nối cơ sở dữ liệu hoặc bất kỳ thông tin nhạy cảm nào vào tài liệu yêu cầu. Các tài liệu này thường được chia sẻ rộng rãi và không phải là nơi lưu trữ bí mật an toàn.

Thay vào đó, sử dụng mẫu tham chiếu đến một hệ thống quản lý bí mật (secret management system) như HashiCorp Vault, Azure Key Vault, hoặc AWS Secrets Manager.

Loại Bí mật	Mẫu tham chiếu	Diễn giải
API Key	`VAULT_REF:nova-foods/erp-dev/sap-connector:api_key`	Tham chiếu đến bí mật `api_key` được lưu trữ tại đường dẫn `nova-foods/erp-dev/sap-connector` trong Vault.
Mật khẩu DB	`AZ_KV_REF:nf-prod-db-credentials/password`	Tham chiếu đến bí mật `password` trong Azure Key Vault có tên `nf-prod-db-credentials`.
Token xác thực	`ENV_VAR:THIRD_PARTY_AUTH_TOKEN`	Yêu cầu hệ thống đọc giá trị từ biến môi trường (environment variable) tên là `THIRD_PARTY_AUTH_TOKEN` khi triển khai.

Việc áp dụng các mẫu này giúp tách biệt yêu cầu chức năng/phi chức năng khỏi dữ liệu nhạy cảm, giảm thiểu rủi ro lộ thông tin và tuân thủ các thực hành tốt nhất về bảo mật ứng dụng, ví dụ như OWASP API Security Top 10 (API7:2023 - Server Side Request Forgery, có thể bị lạm dụng nếu URL chứa credentials bị lộ).

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

Phần này trình bày ví dụ hoàn chỉnh tài liệu Yêu cầu phi chức năng (NFR - Non-Functional Requirement). Mọi dữ liệu, vai trò, yêu cầu và quyết định đều mô phỏng cho case study Nova Foods; không đại diện dự án thực tế.

Trạng thái artifact: IN_REVIEW. Business Owner, Technical Owner, Pháp chế và cấp có thẩm quyền phải xem xét bằng chứng, tiêu chí chấp nhận, rủi ro và quyết định trước khi dùng nội dung này làm đầu vào triển khai.

Bối cảnh: Nova Foods triển khai phân hệ mới trên ERP tên "Cổng Thông tin Nhà Cung cấp" (Supplier Portal). Phân hệ cho phép nhà cung cấp tải hóa đơn, theo dõi trạng thái thanh toán và quản lý thông tin liên hệ. NFR dưới đây xác định tiêu chí hiệu năng, bảo mật, độ tin cậy và khả dụng. Mỗi NFR nêu actor chịu trách nhiệm, hành vi hệ thống, đối tượng áp dụng, kết quả đo được, nguồn thẩm quyền hoặc bằng chứng, artifact kiểm tra và hậu quả nếu không đạt.

Bản ghi Yêu cầu Phi chức năng Chính

Thuộc tính	Giá trị
Artifact ID	`NFR-NF-SPP-001`
Trạng thái	`IN_REVIEW`
Tên Dự án / Tính năng	Dự án Cổng Thông tin Nhà Cung cấp (Supplier Portal) - Nova Foods
Phiên bản tài liệu	`1.0`
Ngày tạo	`2026-08-07`
Business Owner	Bà Nguyễn Thị Mai - Trưởng phòng Mua hàng. Bà Mai xác nhận nhu cầu nghiệp vụ, tác động đến nhà cung cấp và mức chấp nhận nghiệp vụ.
Technical Owner	Ông Trần Văn Hùng - Giám đốc Công nghệ thông tin. Ông Hùng xác nhận tính khả thi kỹ thuật, năng lực vận hành và bằng chứng kiểm thử.
Mô tả & Bối cảnh	Cổng Thông tin Nhà Cung cấp là giao diện web số hóa và tự động hóa quy trình nhận, xử lý hóa đơn từ đối tác. Mục tiêu: giảm sai sót nhập liệu thủ công, tăng tốc xử lý thanh toán và cung cấp minh bạch về công nợ. Hệ thống phải ổn định, an toàn, nhanh để nhà cung cấp dùng cổng thay cho gửi hóa đơn qua email. Không đạt NFR có thể làm gián đoạn tiếp nhận hóa đơn, tăng xử lý thủ công, giảm niềm tin đối tác hoặc tạo rủi ro truy cập trái phép.
Ranh giới áp dụng	Áp dụng cho Supplier Portal, API được nêu trong tiêu chí chấp nhận, dữ liệu người dùng nhà cung cấp và phiên làm việc trên máy tính để bàn. Không tự mở rộng sang các phân hệ ERP khác trừ khi thay đổi được đánh giá, phê duyệt và truy vết riêng.
Artifact bằng chứng tối thiểu	Kế hoạch kiểm thử hiệu năng, kết quả JMeter, nhật ký giám sát uptime, thông báo bảo trì, kết quả kiểm thử hết hạn phiên, kết quả code review, kết quả kiểm tra cơ sở dữ liệu và biên bản kiểm thử tương thích trình duyệt.

Danh sách Yêu cầu Phi chức năng (NFRs)

Bảng dưới liệt kê NFR cụ thể cho Cổng Thông tin Nhà Cung cấp. Business Owner xác nhận lý do nghiệp vụ. Technical Owner tổ chức kiểm thử và lưu artifact bằng chứng. Nhóm dự án chỉ ghi nhận đạt khi kết quả đo khớp tiêu chí chấp nhận.

ID Yêu cầu	Hạng mục	Tuyên bố Yêu cầu	Lý do Nghiệp vụ (Rationale)	Tiêu chí Chấp nhận (Metric)	Nguồn
NFR-SPP-PERF-001	Hiệu năng (Performance)	Supplier Portal phải tải hoàn chỉnh dashboard nhà cung cấp trong vòng 3 giây dưới tải trọng thông thường. Technical Owner phải bảo đảm API dashboard đáp ứng ngưỡng này.	Phản hồi chậm gây trải nghiệm tiêu cực; nhà cung cấp có thể quay lại gửi hóa đơn qua email. Hậu quả: giảm hiệu quả đầu tư, tăng nhập liệu thủ công và giảm minh bạch trạng thái thanh toán.	95th percentile (phân vị thứ 95) thời gian phản hồi API `GET /api/v1/portal/dashboard` phải ≤ 3000ms. Technical Owner đo bằng JMeter với 100 người dùng đồng thời và lưu kết quả chạy kiểm thử. Không đạt khi P95 vượt 3000ms.	`Phỏng vấn, Bà Nguyễn Thị Mai, 2026-07-15`
NFR-SPP-AVAIL-001	Tính Sẵn sàng (Availability)	Supplier Portal phải đạt độ sẵn sàng 99.5% trong giờ hành chính, 08:00-17:00 từ Thứ Hai đến Thứ Sáu. Đội vận hành phải giám sát và xử lý dừng ngoài kế hoạch.	Nhà cung cấp chủ yếu gửi hóa đơn trong giờ hành chính. Không khả dụng trong khung này làm gián đoạn hoạt động hai bên, chậm tiếp nhận hóa đơn và chậm xử lý thanh toán.	Uptime = `(Tổng thời gian theo lịch - Thời gian dừng ngoài kế hoạch) / Tổng thời gian theo lịch ≥ 0.995`. Đội vận hành lưu nhật ký uptime và downtime. Bảo trì có kế hoạch phải được thông báo trước 48 giờ và thực hiện ngoài giờ hành chính.	`Yêu cầu vận hành, Ông Trần Văn Hùng, 2026-07-20`
NFR-SPP-SEC-001	Bảo mật (Security)	Hệ thống phải tự động hết hạn phiên đăng nhập sau 15 phút không hoạt động. Hệ thống phải hủy token phiên và yêu cầu người dùng đăng nhập lại trước hành động tiếp theo.	Giảm rủi ro truy cập trái phép vào tài khoản nhà cung cấp khi người dùng quên đăng xuất trên máy tính dùng chung hoặc không được bảo vệ.	Sau 15 phút (+/- 30 giây) không có bất kỳ yêu cầu nào từ client, hệ thống phải hủy token phiên. Hành động tiếp theo phải yêu cầu đăng nhập lại. Nhóm kiểm thử lưu thời điểm yêu cầu cuối, thời điểm hết hạn và kết quả hành động sau hết hạn.	`OWASP ASVS 5.0 - V2.2.1`
NFR-SPP-SEC-002	Bảo mật (Security)	Dữ liệu định danh cá nhân (PII - Personally Identifiable Information) của người dùng gồm tên, email, số điện thoại phải được mã hóa khi lưu trữ (encryption at rest). Technical Owner phải xác nhận cơ chế mã hóa trước triển khai dữ liệu thật.	Bảo vệ thông tin nhạy cảm đối tác, giảm rủi ro lộ dữ liệu và hỗ trợ đánh giá nghĩa vụ bảo vệ dữ liệu áp dụng cho Nova Foods.	Dữ liệu trong cột cơ sở dữ liệu tương ứng phải được mã hóa bằng AES-256 hoặc tương đương. Technical Owner phải cung cấp kết quả code review và kiểm tra trực tiếp cơ sở dữ liệu. Bộ phận Pháp chế phải đánh giá riêng nguồn pháp lý được nêu trước khi dùng nguồn này làm cơ sở tuân thủ.	`Luật Bảo vệ dữ liệu cá nhân (91/2025/QH15) - Cần xác minh bởi bộ phận Pháp chế`
NFR-SPP-USE-001	Tính Khả dụng (Usability)	Giao diện phải tương thích và hoạt động đầy đủ trên hai (2) phiên bản ổn định mới nhất của Google Chrome và Mozilla Firefox trên máy tính để bàn.	Chrome và Firefox phổ biến trong môi trường doanh nghiệp. Không tương thích có thể ngăn nhà cung cấp đăng nhập, tải hóa đơn hoặc theo dõi thanh toán.	Tất cả chức năng chính gồm đăng nhập, tải hóa đơn, xem danh sách hóa đơn và đăng xuất phải hoạt động không có lỗi hiển thị hoặc chức năng mức `major` trên trình duyệt mục tiêu. Nhóm kiểm thử lưu phiên bản trình duyệt, ca kiểm thử và kết quả.	`Quy định phát triển phần mềm nội bộ NF-DEV-STD-004`

Bảng Yêu cầu Phi chức năng (NFR) cho ERP Nova Foods

Yêu cầu Phi chức năng (Non-Functional Requirement - NFR) mô tả cách hệ thống chạy, không phải cái hệ thống làm. Nó xác định thuộc tính chất lượng như hiệu năng (Performance), độ sẵn sàng (Availability), bảo mật (Security) và tính khả dụng (Usability). Bảng dưới là ví dụ điền đầy đủ cho ERP Nova Foods; dữ liệu mô phỏng. Các NFR này thuộc phạm vi ERP lõi, khác phạm vi Supplier Portal ở bảng trên.

ID Yêu cầu	Hạng mục	Tên Yêu cầu	Nội dung Yêu cầu	Tiêu chí Đo lường & Chấp nhận	Nguồn gốc / Lý do
`NFR-PERF-001`	Performance (Hiệu năng)	Thời gian phản hồi của Giao dịch Tạo Đơn hàng	Hệ thống ERP phải xử lý và xác nhận yêu cầu tạo mới một đơn bán hàng trong vòng 3 giây.	Đo từ lúc người dùng, vai trò Nhân viên Bán hàng, nhấn nút "Lưu" đến khi giao diện hiển thị thông báo thành công hoặc mã lỗi. Phải đạt cho 95% số giao dịch (P95) trong giờ cao điểm 9:00-11:00 sáng, GMT+7, với tải giả lập 50 người dùng đồng thời. Artifact: kết quả kiểm thử tải và nhật ký thời gian phản hồi. Không đạt khi P95 vượt 3 giây.	Nguồn: `BIZ-REQ-015` (Xử lý đơn hàng hiệu quả). Lý do: Giảm thời gian chờ cho nhân viên bán hàng, tăng tốc phục vụ khách hàng và xử lý thông lượng đơn hàng cao trong đợt khuyến mãi.
`NFR-AVAIL-001`	Availability (Độ sẵn sàng)	Độ sẵn sàng của Hệ thống ERP trong giờ hành chính	Hệ thống ERP phải đạt độ sẵn sàng 99.5% trong giờ làm việc, Thứ 2 - Thứ 6, 8:00-17:00, GMT+7.	Tổng downtime không được vượt quá 2.25 giờ mỗi tháng trong khung giờ quy định. Đội vận hành đo uptime, lưu downtime và phân loại bảo trì có kế hoạch. Bảo trì có kế hoạch phải thông báo trước 48 giờ và thực hiện ngoài giờ làm việc.	Nguồn: `STAKEHOLDER-REQ-042` (Hoạt động kinh doanh không gián đoạn). Lý do: Bảo đảm bán hàng, quản lý kho, kế toán không bị gián đoạn; tránh thất thoát doanh thu và giảm năng suất.
`NFR-SEC-001`	Security (Bảo mật)	Tự động đăng xuất phiên làm việc không hoạt động	Phiên làm việc người dùng trên ERP phải tự động hết hạn và yêu cầu đăng nhập lại sau 30 phút không hoạt động.	Hệ thống phải chuyển hướng người dùng đến trang đăng nhập sau 30 phút (+/- 60 giây) không có click chuột, gõ phím hoặc yêu cầu API từ client đến server. Artifact: kịch bản kiểm thử, thời điểm hoạt động cuối và kết quả sau hết hạn.	Nguồn: `OWASP ASVS V2.2.1` (Session Timeout Verification Requirements). Lý do: Giảm rủi ro truy cập trái phép nếu người dùng quên đăng xuất trên máy tính dùng chung hoặc không được giám sát.
`NFR-USAB-001`	Usability (Tính khả dụng)	Hỗ trợ ngôn ngữ Tiếng Việt	Toàn bộ UI, thông báo lỗi và nhãn dữ liệu ERP phải hiển thị đầy đủ, chính xác bằng Tiếng Việt có dấu theo Unicode (UTF-8).	Kiểm tra thủ công mọi màn hình chính của phân hệ Bán hàng, Kho và Kế toán. Không được có văn bản chưa dịch, lỗi font hoặc thuật ngữ tiếng Anh chưa Việt hóa, trừ tên riêng hoặc mã định danh đã thống nhất trong từ điển dữ liệu `CANONICAL_DATA_DICTIONARY`. Artifact: danh sách màn hình kiểm thử và kết quả kiểm thử.	Nguồn: Giả định yêu cầu từ các bên liên quan tại Nova Foods Việt Nam. Lý do: Bảo đảm nhân viên dùng hệ thống hiệu quả, giảm lỗi do hiểu sai thuật ngữ và không yêu cầu trình độ tiếng Anh.

Phân tích và Cây quyết định cho Yêu cầu Phi chức năng

Phân tích này làm rõ bối cảnh, nhu cầu nghiệp vụ, phương án, trade-off, thẩm quyền và hậu quả cho NFR-AVAIL-001 trong ERP Nova Foods. Đây là phân tích phục vụ IN_REVIEW, không phải phê duyệt đầu tư hay phê duyệt nhà cung cấp.

NFR ID: NFR-AVAIL-001
Tên Yêu cầu: Tính Sẵn Sàng (Availability) của Hệ thống ERP Lõi
Định nghĩa: Availability là khả năng hệ thống truy cập được và hoạt động đúng chức năng trong khoảng thời gian xác định; thường biểu diễn bằng tỷ lệ phần trăm. Với NFR này, phạm vi đo là giờ làm việc Thứ 2 - Thứ 6, 8:00-17:00, GMT+7.

1. Hiện trạng và Nhu cầu Nghiệp vụ

Hạng mục	Thực tế hiện tại (Facts & Current Behavior)	Nhu cầu Nghiệp vụ (Underlying Need)	Nguồn bằng chứng	Hậu quả nếu không xử lý
Hệ thống	`ERP-LEGACY-01` (on-premise) gặp trung bình 3 sự cố/tháng.	Bảo đảm hoạt động kinh doanh liên tục, đặc biệt chức năng tài chính và logistics.	`INCIDENT-LOG-2026-Q1`, `INCIDENT-LOG-2026-Q2`	Sự cố lặp lại làm gián đoạn giao dịch và tăng khối lượng xử lý khắc phục.
Thời gian ngừng	Thời gian khắc phục trung bình 4 giờ/sự cố. Sự cố thường xảy ra vào 3 ngày làm việc cuối tháng.	Kế toán cần chốt sổ và lập báo cáo tài chính đúng hạn theo yêu cầu của `Luật Kế toán`.	Phỏng vấn Kế toán trưởng, `BA-ITW-FIN-003`	Chậm chốt sổ, chậm báo cáo và tăng rủi ro vận hành cuối kỳ.
Tác động kinh doanh	Gây trì hoãn xuất hóa đơn, chậm giao hàng cho nhà phân phối lớn.	Giảm rủi ro phạt hợp đồng do giao hàng trễ và tránh mất uy tín thương hiệu Nova Foods.	Phỏng vấn Trưởng phòng Logistics, `BA-ITW-LOG-001`	Tăng nguy cơ trễ giao hàng, khiếu nại đối tác và thiệt hại thương mại.
Hỗ trợ kỹ thuật	Đội IT nội bộ quá tải, không có cam kết thời gian khắc phục sự cố (SLA).	Cần cơ chế hỗ trợ cam kết rõ thời gian phản hồi và khắc phục.	Báo cáo hiệu suất đội IT, `IT-PERF-REPORT-2026-H1`	Không có cơ sở đo trách nhiệm xử lý, khó quản trị sự cố và truyền thông nghiệp vụ.

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

Nhóm dự án xem xét bốn phương án. So sánh này ghi nhận trade-off, không xác nhận báo giá, SLA hợp đồng hoặc kết luận tuân thủ pháp lý.

Tiêu chí Quyết định	Phương án 1: Giữ nguyên	Phương án 2: Nâng cấp hạ tầng on-premise	Phương án 3: Chuyển sang Cloud IaaS	Phương án 4: Triển khai SaaS ERP mới
Tổng chi phí sở hữu (TCO) 5 năm	Thấp nhất, chỉ chi phí vận hành; đổi lại giữ rủi ro sự cố hiện hữu.	Trung bình, gồm đầu tư máy chủ mới; vẫn cần đội nội bộ vận hành.	Cao, gồm chi phí thuê bao hàng tháng; giảm nhu cầu đầu tư hạ tầng vật lý nội bộ.	Cao nhất, gồm license, triển khai và đào tạo.
Cam kết Mức độ Dịch vụ (SLA)	Không có SLA cam kết.	SLA nội bộ, không ràng buộc pháp lý; mục tiêu 99.5%.	Có thể đạt 99.9% từ nhà cung cấp, phải được xác nhận bằng điều khoản dịch vụ trước quyết định.	Có thể đạt 99.95%+ từ nhà cung cấp, phải được xác nhận bằng điều khoản dịch vụ trước quyết định.
Thời gian triển khai	0 ngày; không giải quyết nguyên nhân hạ tầng.	3 tháng.	6 tháng.	18-24 tháng.
Mức độ gián đoạn nghiệp vụ	Liên tục nhưng sự cố không lường trước vẫn xảy ra.	Thấp; gián đoạn chủ yếu lúc chuyển đổi.	Trung bình; có gián đoạn trong di chuyển dữ liệu.	Rất cao; phải đào tạo lại toàn bộ nhân viên và thay đổi quy trình.
Tuân thủ (`Luật Bảo vệ dữ liệu cá nhân`)	Rủi ro cao do hạ tầng cũ.	Phụ thuộc năng lực đội nội bộ.	Bộ phận Pháp chế và Technical Owner phải đánh giá vị trí trung tâm dữ liệu, luồng dữ liệu và điều kiện chuyển dữ liệu xuyên biên giới của nhà cung cấp trước ký kết.	Bộ phận Pháp chế và Technical Owner phải thực hiện đánh giá tương tự Phương án 3 trước ký kết.
Tác động đến NFR-AVAIL-001	Không tạo cơ chế mới để đạt mục tiêu 99.5%.	Có thể hỗ trợ mục tiêu 99.5%, phụ thuộc năng lực vận hành nội bộ.	Có thể hỗ trợ mục tiêu 99.5% và tăng khả năng nhận SLA nhà cung cấp; phụ thuộc kết quả thẩm định và hợp đồng.	Có thể vượt mục tiêu 99.5%; đổi lại thời gian, chi phí và gián đoạn cao.

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

Hạng mục	Chi tiết
Phương án được đề xuất	Phương án 3: Chuyển hệ thống `ERP-LEGACY-01` lên nền tảng đám mây IaaS (Infrastructure as a Service). Đề xuất chỉ có hiệu lực để xem xét; trạng thái vẫn là `IN_REVIEW`.
Lý do đề xuất	Phương án 3 cân bằng chi phí, thời gian và rủi ro tốt hơn các phương án còn lại theo dữ liệu case study. Phương án này hướng tới SLA cao từ nhà cung cấp chuyên nghiệp mà không thay đổi rộng quy trình nghiệp vụ và không cần đào tạo lại toàn bộ người dùng như Phương án 4. Trade-off: tăng chi phí thuê bao, cần di chuyển dữ liệu và cần thẩm định nhà cung cấp.
Điều kiện trước quyết định	Technical Owner phải đánh giá khả năng đáp ứng `NFR-AVAIL-001`, cơ chế hỗ trợ sự cố và bằng chứng SLA của nhà cung cấp. Bộ phận Pháp chế phải đánh giá các yêu cầu áp dụng cho dữ liệu và việc chuyển dữ liệu. CFO phải đánh giá TCO. Không chuyển dữ liệu hoặc ký cam kết dịch vụ trước khi các đánh giá này được hoàn thành và được cấp có thẩm quyền xem xét.
Thẩm quyền	Người đề xuất: Trưởng phòng IT, Kế toán trưởng. Người xem xét: Bà Nguyễn Thị Mai, Ông Trần Văn Hùng, Bộ phận Pháp chế, CFO. Người ra quyết định cuối cùng: Giám đốc Tài chính (CFO), Tổng Giám đốc (CEO). Artifact quyết định: Bản ghi `NFR-AVAIL-001`, bằng chứng đánh giá kỹ thuật, đánh giá pháp chế và đánh giá TCO.
Kết quả mong đợi nếu chấp thuận	Hệ thống có cơ sở kỹ thuật và vận hành để hướng tới mục tiêu sẵn sàng 99.5% trong giờ hành chính. Đội vận hành có cơ chế giám sát, ghi nhận downtime và đối chiếu cam kết hỗ trợ với nhà cung cấp.
Hậu quả nếu giữ nguyên Phương án 1	Thiệt hại do phạt hợp đồng, mất doanh thu, chậm xuất hóa đơn và giảm năng suất có thể tiếp tục tăng. Sự cố cuối tháng vẫn gây rủi ro cho kế toán, logistics và giao hàng.
Hậu quả nếu chọn sai nhà cung cấp IaaS	Có thể phát sinh rủi ro an ninh mạng, rò rỉ dữ liệu, không đáp ứng nghĩa vụ bảo vệ dữ liệu áp dụng và hiệu năng hoặc độ sẵn sàng không cải thiện như kỳ vọng. Nova Foods vẫn chịu tác động nghiệp vụ dù đã phát sinh chi phí di chuyển và thuê bao.
Tiêu chí đóng xem xét	CFO và CEO chỉ quyết định sau khi nhận đủ kết quả đánh giá kỹ thuật, pháp chế và TCO; các artifact phải chỉ rõ người lập, người xem xét, ngày thực hiện, phạm vi đánh giá và kết luận. Trước thời điểm đó, `NFR-AVAIL-001` và đề xuất Phương án 3 giữ trạng thái `IN_REVIEW`.

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, mục cần xác minh, và quy trình xử lý ngoại lệ liên quan đến yêu cầu phi chức năng NFR-SYS-001 (Tính sẵn sàng của hệ thống) đã được định nghĩa trong trường hợp nghiệp vụ mô phỏng của Nova Foods.

4.1. Xử lý Ngoại lệ và Kịch bản Tiêu cực (Negative Paths)

Bảng này xác định các hành động cụ thể khi hệ thống không đạt được mục tiêu sẵn sàng 99.95%. Đây là các "kịch bản tiêu cực" (negative paths) đã được lường trước.

ID Ngoại lệ	Kịch bản ngoại lệ	Ngưỡng kích hoạt & Hành động tức thời	Vai trò chịu trách nhiệm
`NFR-EXC-001`	Tính sẵn sàng trong tháng thấp hơn 99.95% nhưng vẫn trên 99.0%.	Ngưỡng: Báo cáo cuối tháng từ công cụ giám sát. Hành động: Trưởng phòng IT phân tích nguyên nhân gốc rễ và yêu cầu bồi thường tín dụng dịch vụ (service credit) từ nhà cung cấp IaaS theo hợp đồng.	Trưởng phòng IT
`NFR-EXC-002`	Tính sẵn sàng trong tháng thấp hơn 99.0%.	Ngưỡng: Báo cáo cuối tháng từ công cụ giám sát. Hành động: Như `NFR-EXC-001`, cộng với việc Trưởng phòng IT phải trình bày báo cáo đánh giá rủi ro nhà cung cấp cho Giám đốc Tài chính (CFO).	Trưởng phòng IT, CFO
`NFR-EXC-003`	Hệ thống ngừng hoạt động hoàn toàn (total outage) quá 60 phút liên tục.	Ngưỡng: Cảnh báo tự động từ công cụ giám sát. Hành động: Kích hoạt quy trình leo thang `NFR-ESC-002`. Mở cuộc họp khẩn ("war room") với đội hỗ trợ kỹ thuật cấp cao của nhà cung cấp.	Đội vận hành IT, Trưởng phòng IT

4.2. Giả định, Yêu cầu Xác minh và Quy trình Leo thang

Để đạt được NFR-SYS-001, các giả định (assumptions) cần được làm rõ, các mục quan trọng cần được xác minh (verification-required), và quy trình leo thang (escalation) phải được định nghĩa.

ID Tham chiếu	Hạng mục	Mô tả và Lý do	Phân loại	Kế hoạch xác minh / Quy trình leo thang
`NFR-ASMP-001`	Cam kết SLA của nhà cung cấp	Giả định rằng cam kết SLA 99.95% của nhà cung cấp IaaS trong tài liệu marketing là điều khoản ràng buộc pháp lý trong hợp đồng.	Giả định (Assumption)	Kế hoạch xác minh: Bộ phận pháp chế và Trưởng phòng IT phải kiểm tra và xác nhận điều khoản SLA trong hợp đồng trước khi ký.
`NFR-VER-001`	Tuân thủ lưu trữ dữ liệu	Yêu cầu pháp lý từ `Luật Bảo vệ dữ liệu cá nhân` (Luật 91/2025/QH15) có thể yêu cầu dữ liệu cá nhân phải được lưu trữ tại Việt Nam.	Yêu cầu xác minh (Verification Required)	Kế hoạch xác minh: Yêu cầu nhà cung cấp IaaS cung cấp chứng nhận chính thức về vị trí đặt trung tâm dữ liệu (data center) xử lý dữ liệu của Nova Foods.
`NFR-VER-002`	Độ chính xác của công cụ giám sát	Việc đo lường SLA phụ thuộc hoàn toàn vào công cụ giám sát. Công cụ phải được cấu hình đúng để phản ánh chính xác thời gian hoạt động.	Yêu cầu xác minh	Kế hoạch xác minh: Đội vận hành IT phải thực hiện kiểm thử "khô" (dry run), mô phỏng một sự cố và xác nhận hệ thống cảnh báo, ghi nhận log và xuất báo cáo hoạt động chính xác.
`NFR-ESC-001`	Quy trình leo thang khi có cảnh báo tự động	Cảnh báo tự động về hiệu năng suy giảm hoặc gián đoạn nhỏ cần được xử lý ngay để không trở thành sự cố lớn.	Leo thang (Escalation)	1. Hệ thống tự động gửi cảnh báo tới kênh chat của đội Vận hành IT. 2. Kỹ sư trực ca mở một phiếu (ticket) hỗ trợ với nhà cung cấp trong vòng 15 phút. 3. Báo cáo Trưởng phòng IT nếu vấn đề không được giải quyết trong 1 giờ.
`NFR-ESC-002`	Quy trình leo thang khi có sự cố nghiêm trọng	Sự cố ngừng hoạt động toàn bộ (`NFR-EXC-003`) đòi hỏi phản ứng ngay lập tức từ nhiều cấp quản lý.	Leo thang	1. Hệ thống tự động gọi điện và gửi SMS tới đội Vận hành IT, Trưởng phòng IT, và Kế toán trưởng. 2. Trưởng phòng IT liên hệ quản lý tài khoản cấp cao (dedicated account manager) của nhà cung cấp, yêu cầu hỗ trợ khẩn cấp. 3. Trưởng phòng IT cập nhật tình hình cho CFO và CEO mỗi 30 phút.

4.3. Ma trận Truy vết Nguồn gốc (Traceability Matrix)

Bảng này đảm bảo yêu cầu NFR-SYS-001 có thể được truy vết ngược về nhu cầu nghiệp vụ ban đầu và xuôi đến các hạng mục kiểm thử. Truy vết nguồn gốc (traceability) là một năng lực cốt lõi của Business Analyst để đảm bảo mọi việc được làm đều có lý do.

ID Yêu cầu	Liên kết tới (Loại)	ID Liên kết	Mô tả của hạng mục được liên kết
`NFR-SYS-001`	Nhu cầu nghiệp vụ (Business Need)	`NEED-FIN-002`	Giảm thiểu rủi ro tài chính từ các khoản phạt do vi phạm SLA trong hợp đồng với khách hàng.
`NFR-SYS-001`	Quy tắc nghiệp vụ (Business Rule)	`BR-SLA-001`	Hệ thống ERP phải đảm bảo tính sẵn sàng để các bộ phận (bán hàng, kho vận) có thể xử lý đơn hàng đúng hạn cam kết.
`NFR-SYS-001`	Yêu cầu thay đổi (Change Request)	`CR-INFRA-003`	Yêu cầu thay đổi phê duyệt việc di chuyển hệ thống ERP `ERP-LEGACY-01` lên nền tảng IaaS.
`NFR-SYS-001`	Trường hợp kiểm thử (Test Case)	`TC-INFRA-015`	Kiểm thử độ bền (endurance test): Đo lường tính sẵn sàng của hệ thống trên môi trường staging trong 72 giờ liên tục dưới tải mô phỏng.
`NFR-SYS-001`	Dữ liệu (Data/API)	`DATA-LOG-005`	Dữ liệu log thời gian hoạt động của máy chủ được xuất từ API của công cụ giám sát `Zabbix-Prod-01`.

Ma trận Truy vết Yêu cầu (RTM) cho NFR-PERF-001

Truy vết yêu cầu (traceability) liên kết mọi thứ từ nhu cầu nghiệp vụ đến mã nguồn và kiểm thử. Việc này đảm bảo không yêu cầu nào bị bỏ sót và giúp phân tích tác động khi có thay đổi. Ma trận Truy vết Yêu cầu (Requirements Traceability Matrix - RTM) là công cụ để trực quan hóa các liên kết này.

Bảng dưới đây minh họa chuỗi truy vết từ đầu đến cuối (end-to-end) cho yêu cầu phi chức năng về hiệu năng NFR-PERF-001 trong bối cảnh mô phỏng của Nova Foods. Tất cả các định danh (ID) đều tuân thủ kế hoạch tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md và các artifact liên quan đang ở trạng thái IN_REVIEW.

ID	Loại Artifact	Mô tả	Liên kết ngược (Upstream)	Liên kết xuôi (Downstream)
`NEED-004`	Nhu cầu Nghiệp vụ (Business Need)	Giảm thời gian xử lý đơn mua hàng (PO). Tăng hiệu suất kho vận. Giảm chi phí vận hành.	Nguồn: Phỏng vấn Trưởng phòng Mua hàng (mô phỏng)	`REQ-SYS-015`
`REQ-SYS-015`	Yêu cầu Hệ thống (System Requirement)	API tạo Đơn Mua hàng phải phản hồi dưới 200ms ở phân vị thứ 95 (P95). Đây là một instance của `NFR-PERF-001`.	`NEED-004`	`AC-NFR-PERF-001-01`, `BR-PERF-002`
`BR-PERF-002`	Quy tắc Nghiệp vụ (Business Rule)	Bất kỳ tương tác API nào liên quan đến giao dịch tài chính cốt lõi phải hoàn thành trong ngưỡng hiệu năng đã định để đảm bảo hệ thống ổn định.	`REQ-SYS-015`	`AC-NFR-PERF-001-01`
`AC-NFR-PERF-001-01`	Tiêu chí Chấp thuận (Acceptance Criterion)	KHI gửi một payload POST hợp lệ đến endpoint `/api/v1/purchase-orders` dưới tải mô phỏng 100 người dùng đồng thời, THÌ 95% yêu cầu phải nhận được phản hồi HTTP `201 Created` trong vòng 200ms.	`REQ-SYS-015`, `BR-PERF-002`	`TC-NFR-PERF-001-01`, `DATA-PO`
`DATA-PO`	Đối tượng Dữ liệu (Data Object)	Tham chiếu đối tượng `PurchaseOrder` trong `/01-curriculum/CANONICAL_DATA_DICTIONARY.md`. Tốc độ ghi các trường này ảnh hưởng trực tiếp đến hiệu năng.	`AC-NFR-PERF-001-01`	`TC-NFR-PERF-001-01`
`TC-NFR-PERF-001-01`	Ca Kiểm thử (Test Case)	Kịch bản kiểm thử hiệu năng dùng Apache JMeter. 100 luồng (threads) gửi 10,000 yêu cầu tạo PO trong 10 phút. Đo và xác minh thời gian phản hồi P95 < 200ms.	`AC-NFR-PERF-001-01`	`DEF-1023` (nếu thất bại)
`DEF-1023`	Lỗi (Defect)	Kết quả kiểm thử ngày `2026-08-06`: thời gian phản hồi P95 là 452ms. `Severity: Major`. Nguyên nhân gốc: câu lệnh SQL join nhiều bảng không hiệu quả.	`TC-NFR-PERF-001-01`	`CR-055`
`CR-055`	Yêu cầu Thay đổi (Change Request)	Đề xuất tái cấu trúc (refactor) câu lệnh SQL trong `PurchaseOrderService` và thêm chỉ mục (index) vào bảng `po_items` để khắc phục `DEF-1023`.	`DEF-1023`	`TASK-842` (mô phỏng)

Ma trận này nối nhu cầu kinh doanh tới yêu cầu kỹ thuật cụ thể. Đây là bằng chứng sống cho thấy mọi thứ được kết nối. Khi CR-055 được hoàn thành, TC-NFR-PERF-001-01 phải được thực thi lại để xác nhận lỗi DEF-1023 đã được khắc phục và tiêu chí chấp thuận AC-NFR-PERF-001-01 được thỏa mãn.

Bằng chứng kỹ thuật: Cấu trúc Payload và Dữ liệu thử nghiệm

Trong ngữ cảnh API (Application Programming Interface - Giao diện Lập trình Ứng dụng), payload là khối dữ liệu thực tế được gửi trong một yêu cầu (request) hoặc nhận về trong một phản hồi (response). Đây là "hàng hóa" mà API vận chuyển. Đối với yêu cầu tạo mới một Đơn Mua hàng (POST /api/v1/purchase-orders) trong hệ thống ERP của Nova Foods, payload phải chứa tất cả thông tin cần thiết để hệ thống xử lý. Dữ liệu này thường được định dạng bằng JSON (JavaScript Object Notation) vì tính gọn nhẹ và dễ đọc cho cả người và máy.

Dưới đây là một ví dụ hoàn chỉnh về cấu trúc payload cho việc tạo một đơn mua hàng mới, sử dụng dữ liệu mô phỏng cho Nova Foods.

Ví dụ Payload cho POST /api/v1/purchase-orders

{
  "purchaseOrderId": "PO-2026-08-1123",
  "issueDate": "2026-08-07T14:30:00Z",
  "supplierId": "VDR-NCC-0045",
  "supplierName": "Công ty TNHH Thực phẩm ABC (mô phỏng)",
  "currency": "VND",
  "deliveryAddress": "Kho Nova Foods, Lô C4-1, KCN Tân Thuận, Quận 7, TP. HCM",
  "expectedDeliveryDate": "2026-08-21",
  "paymentTerms": "NET_30",
  "notes": "Ưu tiên giao hàng trước 16:00. Vui lòng liên hệ Quản lý kho, SĐT 090xxxx123.",
  "lineItems": [
    {
      "lineNumber": 1,
      "productId": "PROD-1102",
      "productDescription": "Bột mì đa dụng cao cấp - Bao 25kg",
      "quantity": 200,
      "unit": "BAG",
      "unitPrice": 350000
    },
    {
      "lineNumber": 2,
      "productId": "PROD-2305",
      "productDescription": "Đường tinh luyện Biên Hòa - Bao 50kg",
      "quantity": 150,
      "unit": "BAG",
      "unitPrice": 980000
    }
  ],
  "totalAmount": 217000000
}

Để xác minh yêu cầu phi chức năng NFR-PERF-001 (liên quan đến hiệu năng hệ thống), một tập hợp dữ liệu thử nghiệm (test data) đa dạng là bằng chứng không thể thiếu. Tập dữ liệu này không chỉ bao gồm các trường hợp thông thường mà còn phải bao quát các trường hợp biên và kịch bản tiêu cực để đảm bảo hệ thống ổn định dưới nhiều điều kiện tải khác nhau. Bảng dưới đây định nghĩa các loại dữ liệu cần được tạo ra để phục vụ cho việc kiểm thử hiệu năng.

Bảng định nghĩa bộ dữ liệu thử nghiệm cho NFR-PERF-001

ID Dữ liệu Thử nghiệm	Mô tả Kịch bản	Tham số chính & Giá trị	Liên kết Traceability
`TD-PERF-001`	Kịch bản cơ bản (Baseline): Một đơn hàng nhỏ và điển hình, phản ánh phần lớn các giao dịch hàng ngày.	`lineItems.length`: 1-5	`NFR-PERF-001`, `AC-PERF-001.1`
`TD-PERF-002`	Kịch bản tải lớn (Stress test): Một đơn hàng rất lớn để kiểm tra hiệu năng tại giới hạn trên của logic xử lý và tài nguyên hệ thống.	`lineItems.length`: 100 (giá trị biên)	`NFR-PERF-001`, `AC-PERF-001.1`, `TC-PERF-BOUNDARY-01`
`TD-PERF-003`	Kịch bản tiêu cực (Negative path): Một đơn hàng chứa dữ liệu không hợp lệ, ví dụ mã sản phẩm không tồn tại, để đo thời gian phản hồi lỗi.	`productId`: 'PROD-9999' (không tồn tại trong hệ thống)	`NFR-PERF-001`, `AC-PERF-001.2`, `TC-PERF-NEGATIVE-01`
`TD-PERF-004`	Kịch bản tải đồng thời (Concurrent load): Mô phỏng nhiều người dùng cùng tạo đơn hàng một lúc để đo lường độ trễ và khả năng chịu tải.	100 yêu cầu đồng thời, sử dụng hỗn hợp 80% dữ liệu loại `TD-PERF-001` và 20% dữ liệu loại `TD-PERF-002`.	`NFR-PERF-001`, `AC-PERF-001.1`

5. Tier 4 – Senior BA Quality Gate

Cổng chất lượng này là một danh mục kiểm tra (checklist) dành cho Senior BA để đánh giá chất lượng của tài liệu Yêu cầu Phi chức năng (NFR) đã hoàn thiện cho case study Nova Foods. Mục tiêu là đảm bảo tài liệu đạt các tiêu chuẩn tối thiểu về tính rõ ràng, đầy đủ và nhất quán trước khi được xem xét đưa vào trạng thái BASELINED. Việc đánh giá không cấu thành phê duyệt (approval) mà chỉ là một bước kiểm soát chất lượng nội bộ của nhóm BA.

Bảng dưới đây định nghĩa các hạng mục kiểm tra, tiêu chí đánh giá, và các quy tắc xử lý khi phát hiện vấn đề.

Bảng danh mục kiểm tra chất lượng (Quality Gate Checklist) cho tài liệu NFR

Hạng mục kiểm tra	Tiêu chí đánh giá chi tiết	Tiêu chí ĐẠT (PASS)	Tiêu chí DỪNG (STOP)	Điều kiện Leo thang (ESCALATION)
1. Tính đầy đủ (Completeness)	Tất cả các phần của template (đặc biệt là Tier 3) phải được điền đầy đủ, không còn sót placeholder như `<example>` hoặc `[description]`. Mọi quyết định phải được ghi nhận rõ ràng.	Mọi trường, bảng, ID, và liên kết traceability trong Tier 3 đều chứa dữ liệu mô phỏng cụ thể của Nova Foods. Không có mục nào bị bỏ trống hoặc ghi "TBD".	Còn tồn tại bất kỳ placeholder nào trong phần nội dung đã hoàn thiện. Thiếu quyết định tại các điểm rẽ nhánh logic quan trọng.	Không áp dụng. Đây là lỗi cơ bản, yêu cầu người soạn thảo phải tự hoàn thiện.
2. Tính nhất quán (Consistency)	Thuật ngữ, ID, và quy tắc nghiệp vụ phải nhất quán trong toàn bộ tài liệu và khớp với các artifact quản trị khác như `CANONICAL_DATA_DICTIONARY`, `CANONICAL_BUSINESS_RULES`, và `TRACEABILITY_ID_REGISTRY`.	ID `NFR-SEC-001` trong tài liệu này khớp với định nghĩa trong registry. Tên trường dữ liệu "Mã nhà cung cấp" khớp với từ điển dữ liệu.	ID `NFR-SEC-001` được sử dụng nhưng không được đăng ký. Một quy tắc nghiệp vụ mâu thuẫn với quy tắc trong `CANONICAL_BUSINESS_RULES`.	Khi hai nguồn canonical (ví dụ, hai tài liệu quản trị) mâu thuẫn với nhau. Leo thang lên Owner của corpus để giải quyết xung đột nguồn.
3. Khả năng kiểm thử (Testability)	Mỗi NFR phải có ít nhất một Tiêu chí Chấp nhận (Acceptance Criterion - AC) có thể kiểm chứng được. AC phải cụ thể, đo lường được và có kết quả Đạt/Lỗi rõ ràng.	AC `AC-PERF-001.1` ghi rõ: "Thời gian phản hồi của API phải <= 500ms với 100 người dùng đồng thời". Đây là một mệnh đề có thể kiểm chứng bằng công cụ.	AC ghi: "Hệ thống phải nhanh". "Nhanh" là một tính từ chủ quan, không đo lường được và do đó không thể kiểm thử.	Khi một NFR được cho là "không thể kiểm thử" do giới hạn kỹ thuật hoặc nghiệp vụ. Leo thang lên Technical Architect và QA Lead để xác nhận.
4. Khả năng truy vết (Traceability)	Mỗi NFR phải được truy vết ngược về một nguồn (ví dụ: yêu cầu nghiệp vụ, quy định pháp luật) và truy vết xuôi tới các AC và test case liên quan.	NFR `NFR-COMP-002` có liên kết rõ ràng đến `Luật Kế toán 88/2015/QH13` và `Nghị định 123/2020/NĐ-CP` làm nguồn gốc yêu cầu.	Một NFR về bảo mật được tạo ra mà không có nguồn gốc rõ ràng (không trích dẫn luật, chuẩn ngành như OWASP, hay yêu cầu từ Business Owner).	Khi một NFR có thể bị diễn giải là quyết định pháp lý hoặc kế toán nhưng thiếu sự xác nhận từ Legal/Accounting Owner.
5. Thẩm quyền nguồn (Source Authority)	Các yêu cầu có nguồn gốc từ pháp luật, kế toán, hoặc bảo mật phải trích dẫn đúng nguồn và không được diễn giải bởi BA. Phải phân biệt rõ giữa "yêu cầu" và "giả định".	NFR về lưu trữ dữ liệu cá nhân trích dẫn `Luật 91/2025/QH15` và ghi rõ: "Yêu cầu xác minh bởi Legal Owner".	BA tự diễn giải một điều luật và viết ra yêu cầu chi tiết thay vì chỉ trích dẫn và yêu cầu xác minh. Ví dụ: "Hệ thống phải mã hóa XYZ bằng thuật toán ABC vì luật yêu cầu".	Bất kỳ diễn giải nào về luật, thuế, hoặc chuẩn mực kế toán. Leo thang ngay lập tức tới Legal Owner hoặc Accounting Owner tương ứng.
6. Quyền sở hữu (Ownership)	Các quyết định quan trọng, đặc biệt là những quyết định vượt ra ngoài thẩm quyền của BA (ví dụ: kiến trúc, pháp lý) phải được ghi nhận rõ ràng cùng với vai trò đã ra quyết định.	Ghi chú trong tài liệu: "Quyết định sử dụng OAuth 2.0 cho xác thực được xác nhận bởi Technical Architect vào ngày 2026-08-01".	Một quyết định về kiến trúc được đưa ra mà không ghi nhận ai là người quyết định.	Khi một quyết định cần thiết bị tồn đọng và không có Owner nào chịu trách nhiệm. Leo thang lên Project Manager hoặc người có thẩm quyền điều phối.
7. Ranh giới (Boundaries)	BA không được vượt ranh giới chuyên môn. Tài liệu không được chứa các quyết định thiết kế cấp thấp, chi tiết kế toán, hoặc diễn giải pháp lý.	Yêu cầu ghi: "Hệ thống phải tuân thủ các quy định về hóa đơn điện tử theo Nghị định 123/2020/NĐ-CP".	Yêu cầu ghi: "Bảng `Invoices` trong cơ sở dữ liệu phải có trường `eInvoiceCode` kiểu `VARCHAR(50)`". Đây là quyết định thiết kế.	Khi yêu cầu của BA lấn sang phạm vi thiết kế database, cấu hình hạ tầng, hoặc quy trình kiểm toán chi tiết. Leo thang tới Architect, DevOps, hoặc Accounting Owner.
8. Tác động thay đổi (Change Impact)	Tài liệu phải xác định (dù ở mức cao) các hệ thống, quy trình hoặc vai trò khác có thể bị ảnh hưởng bởi NFR được đề xuất.	NFR về thay đổi API đơn hàng có ghi nhận "Ảnh hưởng đến hệ thống Kho vận (WMS) và hệ thống Kế toán".	Một NFR rõ ràng làm thay đổi luồng dữ liệu liên hệ thống nhưng phần phân tích tác động lại bị bỏ trống.	Khi tác động thay đổi lớn và ảnh hưởng đến nhiều bên nhưng chưa được phân tích đầy đủ. Leo thang lên Business Owner và Project Manager để tổ chức buổi đánh giá tác động.

Tiêu chí Chất lượng của Senior BA

Bảng dưới đây định nghĩa các tiêu chí kiểm tra chất lượng mà một Senior BA sử dụng để đánh giá tài liệu yêu cầu phi chức năng trước khi trình baseline. Mục đích là đảm bảo các yêu cầu được định nghĩa một cách đầy đủ, nhất quán, có thể kiểm chứng và tuân thủ các ràng buộc của dự án, tránh việc các lỗi logic hoặc thiếu sót lan truyền sang các giai đoạn sau như thiết kế, lập trình và kiểm thử.

Mã Tiêu chí	Hạng mục	Nội dung kiểm tra	Tiêu chí ĐẠT (PASS)	Tiêu chí DỪNG (STOP)
`NFR-QG-01`	Tính đầy đủ (Completeness)	Yêu cầu có đủ các thuộc tính cốt lõi (ID, mô tả, lý do nghiệp vụ, thước đo, mục tiêu) theo template không?	Mọi trường bắt buộc trong template được điền đầy đủ thông tin có ý nghĩa và không có giá trị giữ chỗ (placeholder) như `<chưa xác định>`.	Thiếu ID duy nhất từ `TRACEABILITY_ID_REGISTRY`, thiếu lý do nghiệp vụ, hoặc thiếu thước đo/mục tiêu có thể đo lường.
`NFR-QG-02`	Tính nhất quán (Consistency)	Yêu cầu này có mâu thuẫn với yêu cầu chức năng, yêu cầu phi chức năng khác, hoặc một quy tắc trong `CANONICAL_BUSINESS_RULES.md` không?	Không có mâu thuẫn trực tiếp. Mọi xung đột tiềm ẩn được ghi nhận trong mục "Open Issues" và có kế hoạch giải quyết.	Tồn tại mâu thuẫn trực tiếp với một quy tắc nghiệp vụ đã được xác thực hoặc một yêu cầu khác đã được baseline mà không có giải trình.
`NFR-QG-03`	Tính khả kiểm (Testability)	Yêu cầu có được diễn đạt một cách khách quan, định lượng để có thể xác minh được không? (Tham chiếu định nghĩa của ISTQB).	Có thước đo (metric) và mục tiêu (target) cụ thể, không mơ hồ. Ví dụ: "Thời gian phản hồi API `GET /api/v1/orders/{id}` phải ≤ 500ms ở P95".	Sử dụng từ ngữ chủ quan, không thể đo lường. Ví dụ: "Hệ thống phải phản hồi nhanh", "giao diện phải thân thiện với người dùng".
`NFR-QG-04`	Khả năng truy vết (Traceability)	Yêu cầu có liên kết rõ ràng tới nguồn gốc của nó (ví dụ: mục tiêu kinh doanh, luật định, yêu cầu của stakeholder) không?	Có ID hợp lệ và mã nguồn tham chiếu được ghi nhận trong mục "Evidence and Traceability", liên kết được tới một artifact nguồn như `CANONICAL_BUSINESS_RULES`.	Yêu cầu không có nguồn gốc ("orphan requirement"), không thể truy vết về lý do tại sao nó tồn tại.
`NFR-QG-05`	Thẩm quyền nguồn (Source Authority)	Nguồn được trích dẫn có đủ thẩm quyền cho loại yêu cầu này không? (Tham chiếu chéo với `00-research/00_SOURCE_MAP.md`).	Nguồn pháp lý là văn bản luật chính thức (ví dụ: `Luật Kế toán 88/2015/QH13`). Nguồn kiến trúc là từ Architect. Nguồn nghiệp vụ là từ Business Owner.	Dùng nguồn không chính thống cho yêu cầu có ràng buộc cao (ví dụ: dùng một bài blog để diễn giải yêu cầu tuân thủ `Nghị định 123/2020/NĐ-CP`).
`NFR-QG-06`	Ranh giới và Tuân thủ (Boundaries)	Yêu cầu có tôn trọng các ranh giới về bảo mật (Security), quyền riêng tư (Privacy), pháp lý (Legal), và kế toán (Accounting) không? Vai trò owner cần phê duyệt đã được xác định chưa?	Ghi rõ các yêu cầu tuân thủ liên quan (ví dụ: `Luật Bảo vệ dữ liệu cá nhân`, `OWASP ASVS`) và xác định đúng vai trò (Legal Owner, Security Owner) cần xem xét.	Một yêu cầu xử lý dữ liệu cá nhân nhưng không tham chiếu luật định hoặc không xác định Legal Owner là người xem xét.
`NFR-QG-07`	Tác động thay đổi (Change Impact)	Phân tích tác động của việc thực thi yêu cầu này lên các hệ thống, quy trình, hoặc người dùng khác đã được thực hiện và ghi nhận chưa?	Có một mục ghi nhận các thành phần/hệ thống/quy trình bị ảnh hưởng và mức độ tác động dự kiến (cao, trung bình, thấp).	Yêu cầu có phạm vi ảnh hưởng rộng (ví dụ: thay đổi cơ chế xác thực toàn hệ thống) nhưng không có bất kỳ ghi nhận nào về phân tích tác động.

Một kết quả DỪNG (STOP) trên bất kỳ tiêu chí nào đòi hỏi tài liệu phải được điều chỉnh và đệ trình lại để xem xét. Quy trình này ngăn chặn các thiếu sót bị lan truyền vào các giai đoạn sau của vòng đời phát triển phần mềm.

Kết quả áp dụng Checklist lên Case Study Nova Foods

Áp dụng checklist chất lượng lên nội dung Tier 3 (Mục 3 và 4) của tài liệu này, phiên bản v0.9.0. Ghi nhận này là một phần của quy trình Quality Gate (Cổng chất lượng) của Senior BA, không phải là phê duyệt baseline. Mục đích là xác định các khoảng trống trọng yếu trước khi chính thức hóa yêu cầu. Case study Nova Foods là mô phỏng, dữ liệu là tổng hợp.

Hạng mục kiểm tra	ID Tham chiếu	Kết quả (Pass/Fail)	Ghi nhận & Bằng chứng	Hành động đề xuất
Tính đầy đủ	QG-NFR-01	Fail	`NFR-PERF-001` đặt mục tiêu thời gian phản hồi < 2 giây nhưng không nêu rõ tải (user load) và loại giao dịch (transaction mix). Yêu cầu không đủ chi tiết để thiết kế hoặc kiểm thử.	Bổ sung ngữ cảnh tải: số người dùng đồng thời, loại giao dịch, và kịch bản sử dụng. Giao cho BA Lead.
Tính nhất quán	QG-NFR-02	Fail	Mục 3 sử dụng `Hệ thống Quản lý Kho` trong khi Mục 4 tham chiếu đến `Hệ thống WMS`. Thuật ngữ không nhất quán và không có định nghĩa trong từ điển dữ liệu (`CANONICAL_DATA_DICTIONARY`).	Thống nhất một thuật ngữ duy nhất. Cập nhật tất cả các lần xuất hiện. Bổ sung vào `CANONICAL_DATA_DICTIONARY`.
Khả năng kiểm thử	QG-NFR-03	Fail	`NFR-USAB-002` yêu cầu "giao diện phải thân thiện với người dùng". Đây là một tuyên bố chủ quan, không thể đo lường và xác minh một cách khách quan theo tiêu chuẩn ISTQB.	Định nghĩa lại yêu cầu bằng một thước đo cụ thể, ví dụ: "Đạt điểm SUS (System Usability Scale) tối thiểu 75 sau khóa đào tạo" hoặc "Người dùng mới hoàn thành Tác vụ X trong vòng 90 giây".
Khả năng truy vết	QG-NFR-04	Fail	`NFR-SEC-005` yêu cầu mã hóa AES-256 cho dữ liệu tại chỗ (data-at-rest) nhưng không có liên kết ngược (traceability link) đến một yêu cầu tuân thủ, rủi ro đã xác định, hoặc yêu cầu từ bên liên quan.	Thêm ID truy vết đến nguồn gốc yêu cầu (ví dụ: `RISK-042` hoặc `COMP-PL-003` từ Luật Bảo vệ dữ liệu cá nhân). Nếu không có, đánh dấu là giả định của dự án cần Business Owner phê duyệt.
Thẩm quyền nguồn	QG-NFR-05	Pass	`NFR-COMP-001` (liên quan đến hóa đơn điện tử) đã tham chiếu chính xác đến `Nghị định 123/2020/NĐ-CP`. Nhãn `Verification required` được giữ lại, cho thấy BA hiểu đúng ranh giới thẩm quyền.	Không cần hành động. Giữ nguyên nhãn `Verification required` và vai trò Legal Owner.
Quyền sở hữu	QG-NFR-06	Fail	`NFR-AVAIL-001` đặt mục tiêu độ sẵn sàng 99.9% nhưng chưa có Business Owner được chỉ định để xác nhận chấp nhận chi phí/lợi ích của yêu cầu này.	Chỉ định một Business Owner. Owner phải thực hiện phân tích tác động và chính thức chấp nhận yêu cầu và chi phí liên quan.
Ranh giới	QG-NFR-07	Fail	`NFR-AUDIT-004` quy định "dữ liệu giao dịch phải được lưu trữ trong 7 năm". Yêu cầu này có thể ảnh hưởng đến quy định kế toán và pháp lý, nhưng không có ghi nhận escalade cho Accounting Owner hay Legal Owner.	Gắn thẻ `Escalation required`. Chuyển yêu cầu này đến Accounting Owner và Legal Owner để xác minh và phê duyệt.
Tác động thay đổi	QG-NFR-08	Pass	`NFR-I18N-001` yêu cầu hỗ trợ Unicode (UTF-8) trên toàn hệ thống. Mục 4 đã ghi nhận chính xác tác động lên cơ sở dữ liệu, API và giao diện người dùng, cùng với ước tính ban đầu về nỗ lực.	Không cần hành động. Phân tích tác động được ghi nhận là đủ cho giai đoạn này.

Tổng kết cổng chất lượng:

Trạng thái: STOP — REWORK REQUIRED
Lý do: Nhiều lỗi nghiêm trọng được phát hiện (5/8 hạng mục Fail). Các lỗi này liên quan đến tính đầy đủ, khả năng kiểm thử, truy vết, và quyền sở hữu. Tài liệu chưa sẵn sàng cho baseline.
Hành động tiếp theo:
1. BA chịu trách nhiệm cập nhật tài liệu để giải quyết tất cả các điểm Fail.
2. Các hành động Escalation required hoặc yêu cầu Owner xác nhận phải được thực hiện.
3. Tài liệu phải được trình lại qua Quality Gate sau khi tất cả các điểm đã được giải quyết.

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

6.1. Kiểm tra đối chiếu với các nguồn Canonical

Mục này ghi lại kết quả kiểm tra đối chiếu tài liệu Yêu cầu phi chức năng (NFR) này với các nguồn tham chiếu chính tắc (canonical sources) trong corpus dự án Nova Foods. Mục đích là để đảm bảo tính nhất quán, tránh mâu thuẫn và xác định sớm các sai lệch trước khi chuyển sang giai đoạn sau. Một nguồn canonical, hay "nguồn chân lý" (source of truth), là một artifact được kiểm soát mà mọi người phải tuân theo để đảm bảo tất cả các thành phần của dự án nói cùng một ngôn ngữ. Việc kiểm tra này là một bước quan trọng trong quản trị thông tin (Information Governance).

Bảng dưới đây tổng hợp các điểm kiểm tra, kết quả và hành động cần thiết. Trạng thái IN_REVIEW và kết quả STOP — REWORK REQUIRED từ Quality Gate ở mục 5 yêu cầu phải thực hiện và ghi nhận việc kiểm tra này một cách chi tiết.

Bảng kết quả kiểm tra đối chiếu (Cross-Reference Check Result) Ngày thực hiện: 2026-08-07

Artifact được kiểm tra đối chiếu	Thành phần được kiểm tra	Trạng thái kỳ vọng (từ nguồn Canonical)	Trạng thái quan sát (trong tài liệu NFR này)	Kết quả	Hành động khắc phục
`/01-curriculum/TRACEABILITY_ID_REGISTRY.md`	Định danh yêu cầu `NFR-AUDIT-004`	Mọi ID phải được đăng ký trong registry. ID liên quan đến pháp lý hoặc kế toán phải có ghi nhận về vai trò Owner tương ứng (Legal, Accounting).	`NFR-AUDIT-004` yêu cầu lưu trữ dữ liệu 7 năm. Đây là một yêu cầu có hàm ý pháp lý và kế toán nhưng không có tham chiếu đến sự phê duyệt của Legal/Accounting Owner.	FAIL	Gắn cờ `Escalation required`. Vấn đề này phải được chuyển cho các vai trò Legal Owner và Accounting Owner để xác minh. Cập nhật registry sau khi có quyết định.
`/01-curriculum/CANONICAL_DATA_DICTIONARY.md`	Thuật ngữ "Dữ liệu giao dịch" (Transaction Data)	Từ điển dữ liệu phải định nghĩa rõ cấu trúc, kiểu dữ liệu, ràng buộc và vòng đời (data lifecycle) của các thực thể dữ liệu quan trọng.	Tài liệu NFR này đề cập đến việc lưu trữ "dữ liệu giao dịch" nhưng không tham chiếu đến một định nghĩa chuẩn. Việc này tạo ra sự mơ hồ: "dữ liệu giao dịch" bao gồm những gì? Hóa đơn, nhật ký hệ thống, hay cả hai?	FAIL	BA chịu trách nhiệm phải làm việc với Data Architect và Business Owner để định nghĩa rõ thuật ngữ này trong `CANONICAL_DATA_DICTIONARY.md`. Sau đó, cập nhật tài liệu này để sử dụng định nghĩa đã được chuẩn hóa.
`/01-curriculum/CANONICAL_BUSINESS_RULES.md`	Quy tắc nghiệp vụ về độ sẵn sàng hệ thống	Catalog quy tắc nghiệp vụ `CANONICAL_BUSINESS_RULES` (kế hoạch) dự kiến chứa quy tắc chuẩn, ví dụ: `BR-SYS-AVAIL-STD: "Hệ thống nội bộ cấp 2 phải có độ sẵn sàng 99.5% trong giờ hành chính."`	`NFR-AVAIL-001` yêu cầu độ sẵn sàng 99.9% cho hệ thống ERP (được xem là hệ thống cấp 1) mà không có phân tích tác động chi phí hoặc phê duyệt từ Business Owner. Yêu cầu này mâu thuẫn với nguyên tắc "chi phí phải được chấp thuận".	CONFLICT	Yêu cầu `NFR-AVAIL-001` phải được xem xét lại. Business Owner phải xác nhận mức độ sẵn sàng này sau khi được cung cấp phân tích chi phí/lợi ích từ đội kỹ thuật. Kết quả phải được ghi nhận là một ngoại lệ hoặc một quy tắc mới trong catalog.
`/01-curriculum/TEMPLATE_MANIFEST.md`	Phạm vi và mục đích của `TMPL-NFR-001`	Manifest định nghĩa template này là một công cụ để "ghi nhận, xác minh và truy vết các yêu cầu phi chức năng".	Tài liệu này đã thực hiện đúng chức năng đó. Cấu trúc 4 tầng (Tier 1-4) và các mục kiểm tra chất lượng tuân thủ đúng với mô tả trong manifest.	PASS	Không cần hành động. Tài liệu phù hợp với mục đích đã đăng ký trong manifest.
Người tiêu thụ hạ nguồn (Downstream Consumers) - ví dụ: Test Team	Tính khả kiểm (Testability) của `NFR-SEC-005`	Theo `01_CURRICULUM_ARCHITECTURE.md`, mọi yêu cầu phải có tiêu chí chấp nhận (acceptance criteria) rõ ràng để làm cơ sở cho việc kiểm thử (test basis).	`NFR-SEC-005` yêu cầu "hệ thống phải có khả năng chống lại các cuộc tấn công phổ biến". Đây là một yêu cầu không thể kiểm thử trực tiếp vì quá mơ hồ. Quality Gate ở mục 5 đã xác định lỗi này.	FAIL	Yêu cầu này phải được viết lại. Thay vì một câu chung chung, nó cần được phân rã thành các yêu cầu cụ thể, có thể kiểm chứng được, tham chiếu đến một tiêu chuẩn như OWASP ASVS. Ví dụ: "Hệ thống phải xác thực tất cả đầu vào phía máy chủ theo danh sách cho phép (allow-list validation) để chống lại tấn công Injection (OWASP ASVS V4.1.1)."

Danh sách Vấn đề Mở, Giả định và Yêu cầu Xác minh

Bảng dưới đây ghi lại các hạng mục cần được làm rõ, xác nhận hoặc giải quyết trước khi tài liệu này có thể được baseline. Đây là một công cụ quản trị rủi ro và đảm bảo tính nhất quán của yêu cầu. * Vấn đề Mở (Open Issue): Một câu hỏi hoặc xung đột đã được xác định nhưng chưa có giải pháp. * Giả định Dự án (Project Assumption): Một điều được coi là đúng khi soạn thảo tài liệu nhưng chưa được chứng minh hoặc xác nhận chính thức. Giả định sai có thể ảnh hưởng lớn đến dự án. * Yêu cầu Xác minh (Verification Required): Một yêu cầu hoặc dữ liệu cụ thể cần được xác nhận bởi một vai trò có thẩm quyền (ví dụ: Chủ sở hữu Nghiệp vụ, Phòng Pháp lý) để đảm bảo tính chính xác.

ID	Phân loại	Mô tả Vấn đề / Giả định / Yêu cầu	ID / Artifact Bị ảnh hưởng	Mức độ Ảnh hưởng	Owner chịu trách nhiệm	Hành động Tiếp theo (Next Action)
`ISSUE-NFR-001`	Yêu cầu Xác minh / Giả định Dự án	Các yêu cầu phi chức năng về quyền riêng tư (`NFR-SEC-004`, `NFR-CMP-001`) được soạn thảo dựa trên diễn giải sơ bộ về Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP. Giả định rằng diễn giải này là đầy đủ và chính xác cho hệ thống ERP Nova Foods.	`NFR-SEC-004`, `NFR-CMP-001`, `TMPL-NFR-001`, `00_SOURCE_MAP.md`	Cao	Legal Owner, Principal IT BA	Lên lịch một buổi rà soát chính thức với Legal Owner để thẩm định tất cả các yêu cầu liên quan đến quyền riêng tư trước khi baseline. Kết quả thẩm định phải được ghi nhận bằng văn bản.
`ISSUE-NFR-002`	Vấn đề Mở	Ranh giới giữa một quy tắc nghiệp vụ (`business rule`) liên quan đến bảo mật và một yêu cầu phi chức năng về bảo mật chưa rõ ràng. Ví dụ, quy tắc về định dạng mật khẩu có thể tồn tại trong cả `CANONICAL_BUSINESS_RULES.md` và `NFR-SEC-002` của tài liệu này, tạo ra hai nguồn chân lý (source of truth) mâu thuẫn.	`NFR-SEC-002`, `CANONICAL_BUSINESS_RULES.md`, `TRACEABILITY_ID_REGISTRY.md`	Trung bình	Principal IT BA, Technical Architect	Xác định quy tắc phân định rõ ràng: NFR chỉ định thuộc tính chất lượng (VD: "Hệ thống phải thực thi mật khẩu mạnh"), trong khi Catalog Quy tắc Nghiệp vụ xác định các tham số cụ thể của quy tắc đó (VD: "tối thiểu 12 ký tự, 1 chữ hoa..."). Cập nhật cả hai tài liệu để phản ánh quy tắc phân định này.
`ISSUE-NFR-003`	Yêu cầu Xác minh	Yêu cầu về hiệu năng `NFR-PRF-001` (ví dụ: "Thời gian phản hồi API <2 giây ở P95 với 500 người dùng đồng thời") được đưa ra dựa trên thông lệ ngành chứ chưa được xác nhận dựa trên kỳ vọng nghiệp vụ thực tế hoặc phân tích tác động người dùng tại Nova Foods.	`NFR-PRF-001`	Trung bình	Business Owner, Principal IT BA	Tổ chức một buổi workshop với Business Owner và các bên liên quan chính để xác định và phê duyệt các chỉ số hiệu năng cụ thể, có thể biện minh được cho các hành trình người dùng quan trọng.
`ISSUE-NFR-004`	Giả định Dự án	Tài liệu giả định rằng tất cả giao diện người dùng của ERP Nova Foods phải tuân thủ Web Content Accessibility Guidelines (WCAG) 2.2 ở Mức AA, như nêu trong `NFR-USA-001`. Đây là một giả định dựa trên "good practice", chưa phải là một yêu cầu tuân thủ được chỉ định chính thức từ Business Owner.	`NFR-USA-001`	Trung bình	Business Owner, Principal IT BA	Lấy xác nhận chính thức (sign-off) từ Business Owner về tiêu chuẩn khả năng truy cập mục tiêu và mức độ tuân thủ (conformance level). Nếu không được yêu cầu, cần điều chỉnh lại phạm vi để tránh "scope creep" (phình phạm vi).

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 (TMPL-NFR-001, phiên bản v0.9.0) đang ở trạng thái IN_REVIEW. Trạng thái này có nghĩa là tài liệu là một bản nháp có kiểm soát, chưa được phê duyệt (approved) hay chốt phiên bản nền (baselined). Mọi hoạt động phải tuân thủ các quy tắc chuyển giao và ranh giới thẩm quyền dưới đây để đảm bảo tính toàn vẹn của quy trình.

Quy trình Chuyển giao để Xem xét (Handoff for Review)

Việc chuyển giao tài liệu từ người soạn thảo sang các vai trò xem xét được thực hiện theo quy trình có kiểm soát để đảm bảo tất cả các bên liên quan có đủ thông tin.

Vai trò Gửi (Sending Role)	Vai trò Nhận (Receiving Role)	Điều kiện Kích hoạt (Trigger)	Gói Bàn giao Tối thiểu (Minimum Package)
Principal IT Business Analyst (Owner)	1. QA Reviewer 2. Technical Architect	Hoàn tất soạn thảo nội dung các mục 1-5 và mục 6.1, 6.2. Sẵn sàng cho cổng chất lượng (Quality Gate) đầu tiên.	1. Đường dẫn trực tiếp đến tệp `/03-templates/TMPL-NFR-001_NON_FUNCTIONAL_REQUIREMENTS.md` phiên bản `v0.9.0`. 2. Danh sách các vấn đề còn tồn đọng và giả định dự án đã ghi nhận tại mục 6.2. 3. Tuyên bố rõ ràng rằng tài liệu đang ở trạng thái `IN_REVIEW`.

Quy tắc Lan truyền Thay đổi (Change Propagation)

Khi có thay đổi đối với tài liệu này hoặc các artifact nguồn của nó, các quy tắc sau được áp dụng để quản lý tác động lan truyền.

Nguồn thay đổi: Thay đổi được kích hoạt bởi một trong các sự kiện sau:
- Phản hồi (feedback) có yêu cầu hành động từ QA Reviewer hoặc Technical Architect.
- Một artifact nguồn có liên quan thay đổi (ví dụ: CANONICAL_BUSINESS_RULES cập nhật một quy tắc ảnh hưởng đến yêu cầu hiệu năng).
- Một quyết định từ Business Owner yêu cầu điều chỉnh.
Quy trình thực hiện thay đổi:
- Bước 1: Owner (Principal IT Business Analyst) phải tạo một phiên bản mới cho artifact (ví dụ: tăng từ v0.9.0 lên v0.9.1). Mọi thay đổi phải được ghi lại trong lịch sử thay đổi của tài liệu.
- Bước 2: Áp dụng các thay đổi vào nội dung, duy trì liên kết truy vết (traceability) từ nguồn yêu cầu thay đổi đến phần nội dung được cập nhật.
- Bước 3: Owner thông báo cho các bên tiêu thụ hạ nguồn (downstream consumers) đã xác định. Ví dụ, nếu một yêu cầu về hiệu năng thay đổi, người soạn thảo Kế hoạch Kiểm thử (Test Plan) phải được thông báo.
- Bước 4: Trạng thái tài liệu vẫn là IN_REVIEW sau khi cập nhật. Việc cập nhật không tự động hàm ý phê duyệt.

Ma trận Ranh giới Thẩm quyền

Để tránh các quyết định vượt cấp, thẩm quyền của mỗi vai trò trong vòng đời của tài liệu yêu cầu phi chức năng (Non-Functional Requirement - NFR) được phân định rõ ràng. Mọi quyết định vận hành cho case study mô phỏng Nova Foods phải tuân thủ ma trận này.

Vai trò (Role)	Thẩm quyền trong Phạm vi Artifact	Giới hạn và Điều cấm
Principal IT BA (Owner)	Soạn thảo, tổng hợp, và duy trì nội dung artifact. Quản lý phiên bản, lịch sử thay đổi và tính nhất quán với các manifest của corpus.	Không được tự phê duyệt nội dung. Không được tự thiết lập baseline. Không được thay mặt Business Owner, Architect, hay Legal để xác nhận yêu cầu.
QA Reviewer	Xem xét các yêu cầu về tính rõ ràng, đầy đủ, nhất quán và khả năng kiểm thử (testability). Ghi nhận các khiếm khuyết (defect) hoặc điểm cần làm rõ.	Không phê duyệt phạm vi nghiệp vụ. Không định nghĩa yêu cầu mới. Không chấp nhận rủi ro kỹ thuật hoặc nghiệp vụ.
Technical Architect	Xem xét các yêu cầu về tính khả thi kỹ thuật, tác động hiệu năng, bảo mật và sự phù hợp với kiến trúc hệ thống tổng thể.	Không phê duyệt mục tiêu kinh doanh hoặc chức năng. Không thay mặt Business Owner để chấp nhận đánh đổi giữa chi phí và chất lượng.
Business Owner	Là nguồn xác thực và là người phê duyệt cuối cùng cho các yêu cầu nghiệp vụ được định lượng hóa thành NFR (ví dụ: thời gian phản hồi, khả năng chịu tải).	Việc phê duyệt phải được ghi nhận tường minh, chính thức (ví dụ: qua email, trong một biên bản họp hoặc một hệ thống quản lý yêu cầu), và được tham chiếu trong metadata của artifact. Không chấp nhận phê duyệt ngầm định.

Việc chuyển tài liệu này sang trạng thái BASELINED hoặc APPROVED đòi hỏi một hành động phê duyệt chính thức từ các vai trò có thẩm quyền (ví dụ: Business Owner, Technical Architect) và phải được ghi nhận tại một artifact quản trị trung tâm của dự án. Bản thân tài liệu này không phải là bằng chứng cho sự phê duyệt đó.