10 Nonfunctional Requirements And Quality Attributes

Trường quản trị	Giá trị
Tên tệp được kiểm soát	/02-handbook/10-nonfunctional-requirements-and-quality-attributes.md
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale	vi-VN; bối cảnh Việt Nam; tiền tệ mô phỏng VND
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục; chỉ dùng dữ liệu tổng hợp
Phân loại	Handbook chapter
Baseline	Chưa có baseline reference tại v0.9.0; IN_REVIEW không phải BASELINED.
Approval	Chưa có approval reference; metadata và nội dung học liệu không tạo phê duyệt ngầm định.
Nguồn tham chiếu	BABOK Guide Version 3; ISO/IEC/IEEE 29148:2018 theo phạm vi nguồn công khai đã xác minh.
Ranh giới thẩm quyền	Nội dung giáo dục, không thay thế quyết định Business Owner, Architect, Security, QA, Legal, Accounting, Compliance hoặc production authority.

1. Concept l? g??

Core

Nonfunctional Requirement (NFR), tiếng Việt là yêu cầu phi chức năng, mô tả chất lượng hoặc điều kiện mà hệ thống phải đạt khi thực hiện chức năng. Nếu yêu cầu chức năng trả lời “hệ thống làm việc gì”, NFR trả lời “hệ thống phải làm việc tốt đến mức nào, trong điều kiện nào, và giới hạn nào không được vượt qua”.

Ví dụ chức năng: ERP cho phép tạo đơn bán hàng. Đây chưa đủ để đội triển khai xây dựng hay kiểm thử đáng tin cậy. Cần biết màn hình phải phản hồi trong bao lâu, ai được xem giá bán, dữ liệu phải được lưu ra sao, hệ thống có tiếp tục phục vụ khi nhiều người cùng dùng không, và người dùng có thể thao tác bằng công cụ hỗ trợ tiếp cận không. Các điều kiện đó là NFR.

Quality attribute, tiếng Việt là thuộc tính chất lượng, là loại chất lượng cần quan tâm. Ví dụ gồm performance (hiệu năng), security (bảo mật), availability (tính sẵn sàng), reliability (độ tin cậy), usability (tính dễ dùng), accessibility (khả năng tiếp cận), maintainability (khả năng bảo trì) và auditability (khả năng kiểm toán). Một quality attribute chỉ là tên nhóm. NFR là phát biểu cụ thể, có thể đánh giá, về nhóm đó.

Cầu nối suy luận: “hiệu năng” không thể kiểm thử vì chưa nêu đối tượng, tải, ngưỡng thời gian hoặc cách đo. “Hệ thống hiển thị kết quả tìm kiếm lô hàng trong không quá 3 giây cho 95% yêu cầu hợp lệ” có thể kiểm thử vì có thao tác, ngưỡng, điều kiện và phép đo. Vì vậy, BA không dừng ở nhãn chất lượng; BA chuyển nhãn thành yêu cầu rõ, đo được và truy vết được.

NFR không phải phần trang trí thêm sau yêu cầu chức năng. Cùng một chức năng có thể đúng về nghiệp vụ nhưng không dùng được nếu chậm, lộ dữ liệu, mất dấu vết thay đổi hoặc không hoạt động trong thời điểm vận hành cần thiết. Chất lượng vì thế là một phần của kết quả mong muốn, không phải lựa chọn kỹ thuật tách rời nhu cầu nghiệp vụ.

Phạm vi chương này là cách nhận biết và diễn đạt yêu cầu phi chức năng cho ERP Nova Foods mô phỏng. Chương không tự tạo cấu hình ERP, không xác nhận tuân thủ pháp luật, không quyết định kiến trúc, không đặt ngưỡng production, và không diễn giải yêu cầu pháp lý thành nghĩa vụ hệ thống. Mọi ví dụ Nova Foods chỉ là dữ liệu tổng hợp phục vụ học tập.

Core

Nonfunctional Requirement (NFR) là yêu cầu phi chức năng: điều kiện chất lượng hoặc ràng buộc mà hệ thống phải đạt khi thực hiện chức năng. NFR không chủ yếu trả lời “hệ thống làm việc gì?”, mà trả lời “hệ thống làm việc tốt đến mức nào, trong điều kiện nào, và bị giới hạn gì?”. Ví dụ, “tạo đơn bán hàng” là chức năng; “màn hình tạo đơn phản hồi trong 2 giây cho 95% yêu cầu hợp lệ” là NFR. Lý do phân biệt: hai hệ thống có thể cùng tạo được đơn, nhưng hệ thống chậm, không an toàn hoặc khó dùng vẫn không đáp ứng nhu cầu vận hành.

Thuật ngữ	Nghĩa ngắn gọn	Vai trò khi BA viết NFR
Quality Attribute (QA)	Thuộc tính chất lượng, như hiệu năng, bảo mật, khả dụng, dễ sử dụng.	Là nhóm phẩm chất cần đánh giá; không phải tự nó là yêu cầu đo được.
Nonfunctional Requirement (NFR)	Yêu cầu đặt mức chất lượng, giới hạn kỹ thuật hoặc điều kiện vận hành.	Phải cụ thể, kiểm chứng được, có phạm vi rõ.
Actor	Tác nhân khởi tạo hoặc chịu tác động: người dùng, hệ thống khác, thiết bị, tiến trình tự động.	Xác định ai hoặc thành phần nào tạo tải, truy cập, nhận kết quả.
Action	Hành động tác nhân thực hiện, như gửi, tìm kiếm, phê duyệt, đồng bộ.	Neo NFR vào tình huống cụ thể; tránh viết chất lượng chung chung.
Object	Đối tượng bị thao tác, như đơn bán hàng, lô hàng, tệp hóa đơn, API.	Xác định dữ liệu, màn hình, dịch vụ hoặc quy trình chịu yêu cầu.
Outcome	Kết quả quan sát được sau hành động.	Là phần đo hoặc kiểm tra được: thời gian phản hồi, tỷ lệ thành công, quyền bị từ chối.
Metric	Chỉ số đo lường, như giây, phần trăm, số giao dịch/phút.	Biến kỳ vọng chất lượng thành bằng chứng kiểm thử.
Threshold	Ngưỡng chấp nhận của chỉ số.	Nêu ranh giới đạt hoặc không đạt, ví dụ ≤ 2 giây.
Scope	Phạm vi áp dụng.	Chỉ rõ môi trường, người dùng, luồng nghiệp vụ, tải hoặc thành phần liên quan.
Constraint	Ràng buộc bắt buộc về công nghệ, pháp lý, tích hợp hoặc vận hành.	Ghi điều kiện giới hạn cách thiết kế; không suy diễn thành quyết định kỹ thuật khi chưa có thẩm quyền.
SLA (Service Level Agreement)	Cam kết mức dịch vụ giữa các bên.	Chỉ gọi là SLA khi có thỏa thuận được quản trị; NFR nội bộ chưa mặc nhiên là SLA.
SLO (Service Level Objective)	Mục tiêu mức dịch vụ đo được.	Có thể là mục tiêu vận hành; cần owner xác nhận trước khi thành cam kết.

Mẫu đọc NFR từ gốc: Actor thực hiện Action trên Object, hệ thống tạo Outcome đạt chỉ số và ngưỡng đã nêu. Cấu trúc này tạo cầu nối kiểm chứng: nếu thiếu actor, không biết tải đến từ đâu; thiếu action hoặc object, không biết kiểm thử luồng nào; thiếu outcome, metric hoặc threshold, không thể kết luận đạt hay không đạt.

Ví dụ Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp: “Nhân viên kinh doanh (actor) tìm kiếm (action) đơn bán hàng (object); ERP trả danh sách kết quả (outcome) trong ≤ 2 giây cho 95% yêu cầu hợp lệ trong giờ vận hành mô phỏng.” Đây là NFR hiệu năng vì nêu chất lượng phản hồi đo được, không mô tả quy tắc tạo đơn hay nội dung danh sách kết quả.

Ranh giới khái niệm: NFR mô tả chất lượng và ràng buộc có thể kiểm tra. NFR không thay thế functional requirement (yêu cầu chức năng), business rule (quy tắc nghiệp vụ), thiết kế kiến trúc, test case, SLA đã ký, hay kết luận tuân thủ pháp lý. “Hệ thống phải nhanh” không phải NFR hoàn chỉnh vì không có actor, action, object, outcome, metric hoặc threshold.

Applied

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp, dùng VND, locale vi-VN, múi giờ Asia/Ho_Chi_Minh. Ví dụ không mô tả ERP thật, không xác nhận cấu hình hiện hữu, không tạo yêu cầu đã phê duyệt.

Thành phần	Nội dung mô phỏng
Facts	Nhân viên kho tạo phiếu nhập lô hàng gồm 20 dòng. Màn hình ERP phải lưu phiếu và trả kết quả cho người dùng.
Current Behavior	Mô tả chức năng chỉ nói: “Hệ thống cho phép lưu phiếu nhập kho.” Câu này nêu action là lưu, object là phiếu nhập kho, nhưng không nêu chất lượng cần đạt.
Underlying Need	Người dùng cần biết thao tác lưu có hoàn tất trong thời gian chấp nhận được, dữ liệu không mất khi mạng lỗi, và chỉ người có quyền mới xem được giá vốn. Đây là nhu cầu về chất lượng của hành vi, không phải thêm chức năng mới.
Options	(1) Chỉ ghi chức năng lưu; (2) ghi yêu cầu chất lượng đo được cho thời gian phản hồi, độ toàn vẹn dữ liệu và phân quyền; (3) yêu cầu “ERP nhanh, an toàn, dễ dùng” không có thước đo.
Decision Criteria	Có thể kiểm thử; có ngưỡng đo; chỉ rõ điều kiện đo; tách nhu cầu người dùng khỏi cách kỹ thuật cụ thể; không vượt thẩm quyền pháp lý, bảo mật hoặc kiến trúc.
Decision	Dùng option (2): “Với phiếu nhập có tối đa 20 dòng, hệ thống phải trả kết quả lưu thành công hoặc lỗi rõ ràng trong không quá 3 giây tại điều kiện tải kiểm thử được thống nhất; nếu lưu thành công, phiếu có mã tham chiếu duy nhất và dữ liệu dòng hàng được lưu cùng phiếu; vai trò không được cấp quyền không được xem giá vốn.”
Authority	Business Owner xác nhận mức chấp nhận nghiệp vụ; Architect xác nhận tính khả thi kỹ thuật; Security Owner xác nhận phân quyền; QA xác nhận cách đo và bằng chứng kiểm thử. BA ghi nhận, truy vết và làm rõ, không tự phê duyệt.
Artifact	Requirement chất lượng có ID theo /01-curriculum/TRACEABILITY_ID_REGISTRY.md; dữ liệu logic tham chiếu /01-curriculum/CANONICAL_DATA_DICTIONARY.md; quy tắc nghiệp vụ tham chiếu /01-curriculum/CANONICAL_BUSINESS_RULES.md khi đã được đăng ký. Các artifact hiện ở IN_REVIEW, v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Nếu chỉ ghi “lưu phiếu”, đội kỹ thuật có thể làm màn hình hoạt động nhưng chậm, mất liên kết dòng hàng, hoặc lộ giá vốn. Chức năng vẫn tồn tại, nhưng outcome nghiệp vụ không đạt.

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

flowchart TB
    A[Nhân viên kho tạo phiếu nhập tối đa 20 dòng] --> B[ERP thực hiện lưu]
    B --> C{Kết quả lưu}

    C -->|Thành công| D[Phiếu và toàn bộ dòng hàng cùng được lưu]
    D --> E[Phiếu có mã tham chiếu duy nhất]
    E --> F["Trả kết quả thành công trong không quá 3 giây<br/>tại tải kiểm thử được thống nhất"]

    C -->|Lỗi mạng| G[Không lưu dở phiếu hoặc dòng hàng]
    G --> H[Giữ dữ liệu người dùng đã nhập]
    H --> I["Trả lỗi rõ ràng trong không quá 3 giây<br/>tại tải kiểm thử được thống nhất"]

    C -->|Lỗi khác| J["Trả lỗi rõ ràng trong không quá 3 giây<br/>tại tải kiểm thử được thống nhất"]

    K[Vai trò không được cấp quyền] --> L[Không xem được giá vốn]

Ranh giới concept: Nonfunctional Requirement, viết tắt NFR, là yêu cầu nêu thuộc tính chất lượng hoặc ràng buộc của sản phẩm/hệ thống khi hỗ trợ outcome. Trong ví dụ, “lưu phiếu nhập” là functional requirement; “không quá 3 giây”, “không mất dữ liệu liên kết”, “không lộ giá vốn” là NFR vì chúng quy định chất lượng, độ tin cậy và bảo mật của hành vi đó.

Loại trừ: NFR không tự quyết định dùng cơ sở dữ liệu nào, API nào, thuật toán nào, hạ tầng cloud nào, hay giao diện nào. Các lựa chọn này là solution design, thuộc thẩm quyền Architect hoặc vai trò kỹ thuật. NFR cũng không tự suy diễn nghĩa vụ pháp lý, kế toán, thuế, an toàn thực phẩm hoặc bảo vệ dữ liệu cá nhân. Khi yêu cầu có liên quan các lĩnh vực này, cần nhãn Verification required và xác nhận từ owner có thẩm quyền.

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

Core

Nonfunctional Requirement, viết tắt NFR, tồn tại để ngăn dự án hiểu nhầm “có chức năng” là “dùng được”. Functional requirement có thể yêu cầu ERP Nova Foods mô phỏng lưu phiếu nhập kho. Nếu không nêu chất lượng cần đạt, đội kỹ thuật vẫn có thể giao màn hình lưu được phiếu nhưng phản hồi chậm, lưu thiếu dữ liệu liên kết, hiển thị dữ liệu nhạy cảm sai quyền, hoặc báo lỗi không thể xử lý. Chức năng tồn tại; outcome vận hành không đạt.

NFR giảm bốn rủi ro chính. Thất bại dự án xảy ra khi hệ thống đã xây xong nhưng không đáp ứng điều kiện sử dụng thực tế. Rework, nghĩa là làm lại, xảy ra khi chất lượng chỉ được nêu sau khi kiến trúc, giao diện hoặc tích hợp đã chọn. Mơ hồ xảy ra khi câu như “hệ thống phải nhanh” không có ngưỡng, phạm vi giao dịch, điều kiện đo hoặc kết quả lỗi. Rủi ro quản trị xảy ra khi không ai biết ai sở hữu quyết định chất lượng, bằng chứng kiểm tra nằm ở đâu, và điều gì cho phép kết luận yêu cầu đã được kiểm chứng.

ISO/IEC/IEEE 29148:2018 là nguồn tham chiếu về engineering yêu cầu ở mức tổng quát. BABOK Guide Version 3 là nguồn thuật ngữ và thực hành BA. Hai nguồn này không tự tạo NFR cho Nova Foods. Nova Foods là case study mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; mọi NFR vẫn cần nguồn, phạm vi, thẩm quyền và cách kiểm chứng riêng.

Applied

Với ERP Nova Foods mô phỏng, luồng “tạo phiếu nhập kho” đi qua người dùng, ứng dụng ERP, xử lý nghiệp vụ và lưu dữ liệu. Nếu chỉ mô tả hành vi “người dùng bấm Lưu, hệ thống tạo phiếu”, khoảng trống chất lượng xuất hiện tại mọi điểm chuyển giao: thời gian phản hồi, xử lý lỗi, tính toàn vẹn dữ liệu và kiểm soát truy cập.

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

flowchart TB
    A[Nhân viên kho nhập phiếu] -->|Gửi yêu cầu lưu| B[ERP nhận yêu cầu]
    B --> C[Kiểm tra dữ liệu và quyền]
    C -->|Dữ liệu không hợp lệ| F["Từ chối; dữ liệu không đổi; nêu lỗi và hướng dẫn sửa"]
    C -->|Không có quyền| H["Từ chối truy cập; dữ liệu không đổi; không lộ thông tin bảo mật"]
    C -->|Hợp lệ và được cấp quyền| D[Lưu phiếu và dòng hàng trong cùng giao dịch]
    D -->|Lưu thành công| E[Xác nhận đã lưu; nêu trạng thái phiếu]
    D -->|Lưu thất bại| G["Hoàn tác toàn bộ giao dịch; dữ liệu không đổi; nêu trạng thái cuối; thử lại không tạo phiếu trùng"]

    B --- N1["Biên phản hồi: từ gửi yêu cầu đến nhận E/F/G/H; điều kiện tải; pass/fail"]
    C --- N2["Biên kiểm tra: bảo mật và quyền truy cập"]
    D --- N3[Biên lưu: toàn vẹn dữ liệu]
    E --- N4[Biên phản hồi thành công: trạng thái rõ ràng]
    F --- N5["Biên từ chối dữ liệu: lỗi xử lý được"]
    H --- N6[Biên từ chối quyền: không lộ thông tin]
    G --- N7["Biên thất bại lưu: hoàn tác và thử lại an toàn"]

    N1 --- T[Test basis: tiêu chí pass/fail và bằng chứng kiểm tra]
    N2 --- T
    N3 --- T
    N4 --- T
    N5 --- T
    N6 --- T
    N7 --- T

Rủi ro khi thiếu NFR	Cơ chế gây lỗi	Hậu quả quan sát được	NFR ngăn rủi ro bằng cách nào
“Nhanh” không được định nghĩa	Không có ngưỡng thời gian, tải giao dịch, điểm bắt đầu và kết thúc đo	Người dùng chờ lâu nhưng đội phát triển nói hệ thống vẫn hoạt động	Ghi ngưỡng đo, phạm vi thao tác, điều kiện thử và phản hồi khi vượt ngưỡng
Lưu dữ liệu không toàn vẹn	Phiếu đầu được lưu nhưng một số dòng hàng hoặc liên kết không được lưu	Người dùng thấy phiếu tồn tại nhưng dữ liệu kho thiếu hoặc sai liên kết	Nêu yêu cầu toàn vẹn, điều kiện thành công và hành vi khi một phần thao tác thất bại
Quyền truy cập bị hiểu theo màn hình	Chỉ mô tả ai mở màn hình, không mô tả dữ liệu nào được xem hoặc thao tác	Người không phù hợp có thể thấy hoặc sửa trường nhạy cảm trong case study	Nêu đối tượng bảo vệ, quyền cần kiểm tra và hành vi khi bị từ chối
Lỗi không có quy tắc	Không xác định thông báo, trạng thái lưu hay khả năng thử lại	Người dùng nhập lại vì không biết phiếu đã được lưu; có thể tạo bản ghi trùng	Nêu trạng thái kết quả, thông báo lỗi và cách hệ thống tránh hiểu nhầm
Không có test basis	NFR chỉ là khẩu hiệu, không có tiêu chí pass/fail	QA không thể kiểm tra nhất quán; tranh luận kéo dài đến cuối dự án	Viết tiêu chí kiểm chứng được và liên kết tới bằng chứng kiểm tra

Senior Lens

Senior BA không biến mọi mong muốn thành NFR. BA hỏi: “Nếu thuộc tính này sai, outcome nào hỏng; ai chịu ảnh hưởng; đo ở đâu; ai có thẩm quyền chọn mức chấp nhận?” Chuỗi lập luận phải rõ: outcome cần bảo vệ, rủi ro cản trở outcome, thuộc tính chất lượng giảm rủi ro, rồi tiêu chí có thể kiểm chứng xác nhận thuộc tính đó.

Không viết NFR như solution design. “Dùng Redis để tăng tốc” là lựa chọn kỹ thuật, không phải nhu cầu chất lượng. “Người dùng hoàn tất lưu phiếu trong giới hạn thời gian đã được quyết định và kiểm chứng” là nhu cầu chất lượng. Architect chọn giải pháp sau khi NFR đủ rõ. Tách hai lớp này ngăn BA khóa kiến trúc quá sớm và giúp thay đổi công nghệ không làm mất intent nghiệp vụ.

NFR cũng không phải nhãn tuân thủ tự động. Nhu cầu liên quan dữ liệu cá nhân, kế toán, hóa đơn hoặc truy xuất nguồn gốc phải giữ ranh giới nguồn và thẩm quyền. Tài liệu pháp lý trong source seed là nguồn chính thức, nhưng diễn giải thành yêu cầu ERP cần Legal Owner, Accounting Owner hoặc domain owner xác minh. Không có xác minh đó, không được gọi hệ thống tuân thủ.

Quick Reference

Quy tắc	Áp dụng
Có chức năng không đủ	Mọi hành vi quan trọng cần xem xét chất lượng, không chỉ luồng màn hình
Không đo được, không kiểm chứng được	NFR cần điều kiện, phạm vi và kết quả pass/fail
Không có owner, không có quyết định	Ghi rõ vai trò có thẩm quyền cho mức chất lượng và trade-off
Không có traceability, dễ rework	Liên kết NFR với outcome, rủi ro, requirement liên quan và bằng chứng kiểm tra
Không biến NFR thành thiết kế	Giữ “cần đạt gì” tách khỏi “xây bằng gì”
Không tự tuyên bố tuân thủ	Nội dung pháp lý, kế toán, bảo mật và an toàn thực phẩm cần xác minh đúng owner

Core

Yêu cầu phi chức năng (Nonfunctional Requirements, NFR) tồn tại để hệ thống không chỉ “làm được”, mà còn làm được trong điều kiện sử dụng, bảo mật, truy vết và vận hành đã xác định. Nova Foods là case study mô phỏng; mọi dữ liệu dưới đây là tổng hợp. Không có NFR rõ, cùng một chức năng “ghi nhận đơn bán hàng” có thể được xây xong nhưng người dùng không biết lúc nào dữ liệu đã lưu, ai được xem, hay khi lỗi tích hợp xảy ra phải xử lý ra sao.

Applied

Trường	Trước khi nêu NFR	Sau khi nêu NFR có thể kiểm tra
Facts	Màn hình tạo đơn hàng hiển thị nút Lưu. Dữ liệu mô phỏng gồm mã đơn, khách hàng và tổng tiền VND.	Giữ cùng chức năng và dữ liệu mô phỏng.
Current Behavior	Người dùng nhấn Lưu; màn hình quay liên tục hoặc trở lại danh sách. Không có quy tắc về thời gian phản hồi, thông báo lỗi hay chống gửi lặp.	Hệ thống phải hiện kết quả lưu hoặc lỗi có thể hành động; hành vi gửi lặp và lỗi dịch vụ phải xác định trước khi test.
Underlying Need	Nhân viên bán hàng cần biết đơn đã được ghi nhận hay chưa để không tạo trùng hoặc bỏ sót đơn.	Trạng thái thao tác phải quan sát được, nhất quán và có bằng chứng để QA kiểm tra.
Options	Chỉ mô tả chức năng: “Hệ thống lưu đơn hàng.”	Bổ sung NFR về phản hồi giao diện, xử lý lỗi, chống gửi lặp và nhật ký sự kiện.
Decision Criteria	Không có tiêu chí; đội phát triển tự chọn hành vi.	Tiêu chí gồm: người dùng thấy kết quả rõ; lỗi không làm mất dữ liệu nhập; QA tạo được tình huống kiểm tra; Architect xác nhận khả thi kỹ thuật.
Decision	Chưa có quyết định được phê duyệt. Nội dung đang IN_REVIEW, v0.9.0, ngày 2026-08-07.	Ghi NFR dự thảo trong artifact kiểm soát, gắn điều kiện xác minh trước khi gọi là requirement áp dụng.
Authority	Không suy diễn người viết tài liệu có quyền quyết định cấu hình ERP.	Business Owner xác nhận nhu cầu vận hành; Architect xác nhận giải pháp; QA xác nhận cách kiểm tra.
Artifact	Mô tả chức năng đơn lẻ không đủ làm test basis.	/02-handbook/10-nonfunctional-requirements-and-quality-attributes.md giải thích; requirement và bằng chứng chính thức phải nằm ở artifact canonical phù hợp khi được tạo.
Consequence if Wrong	Người dùng có thể nhấn Lưu lại vì không thấy kết quả. Hậu quả quan sát được: xuất hiện nhiều bản ghi mô phỏng cùng nội dung hoặc nhân viên phải đối chiếu thủ công.	Nếu ngưỡng phản hồi, lỗi và chống gửi lặp bị ghi sai, test có thể pass theo tài liệu nhưng hành vi vận hành vẫn gây nhầm trạng thái đơn.

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

flowchart TB
    A["Người dùng nhập đơn hàng mô phỏng"] --> B["Nhấn Lưu"]
    B --> C{"Đã xác định phản hồi giao diện,<br/>lỗi có thể hành động<br/>và xử lý gửi lặp?"}

    C -- "Không" --> D["Không rõ thời gian phản hồi và trạng thái lỗi"]
    D --> E["Người dùng có thể gửi lại"]
    E --> F["Đơn trùng hoặc phải đối chiếu thủ công"]

    C -- "Có" --> G["Hiển thị kết quả lưu hoặc lỗi có thể hành động"]
    G --> H["Nếu lỗi, giữ dữ liệu đã nhập"]
    H --> I["QA kiểm tra phản hồi và lỗi"]
    I --> J["QA gửi lại cùng đơn hàng"]
    J --> K["Hệ thống ngăn hoặc xử lý lặp theo quy tắc đã định"]
    K --> L["QA xác minh nguy cơ đơn trùng được kiểm soát"]

Khác biệt không nằm ở việc thêm màn hình. Khác biệt nằm ở khả năng quan sát: trước, không thể kết luận thao tác đầu tiên thành công hay thất bại từ hành vi giao diện; sau, kết quả mong đợi được viết thành điều kiện kiểm tra. Cầu nối suy luận: khi trạng thái lưu không rõ, người dùng có lý do hợp lý để thử lại; khi hệ thống định nghĩa phản hồi và xử lý gửi lặp, QA có đối tượng cụ thể để xác minh.

Senior Lens

Không dùng số liệu bịa đặt như “phản hồi dưới hai giây” nếu chưa có nguồn đo tải, nhu cầu nghiệp vụ hoặc quyết định có thẩm quyền. NFR tốt phải biến rủi ro mơ hồ thành hành vi quan sát được: ai thấy gì, khi nào thấy, lỗi nào được báo, dữ liệu nào còn giữ, và ai xác nhận kết quả.

Quick Reference

Dấu hiệu	Kết luận
Chức năng ghi “lưu đơn” nhưng không nêu kết quả khi lỗi	NFR còn thiếu; không đủ test basis
Người dùng không phân biệt được đã lưu với chưa lưu	Rủi ro gửi lặp và đối chiếu thủ công
Có hành vi, điều kiện kiểm tra và thẩm quyền xác nhận	NFR có thể đi tiếp sang phân tích và kiểm thử

Core

Yêu cầu phi chức năng (Nonfunctional Requirement, NFR) mô tả phẩm chất hệ thống phải đạt, như hiệu năng, bảo mật, khả dụng, truy cập được. BA không được ghi mọi câu nghe được như requirement. Mỗi câu phải mang một trạng thái bằng chứng khác nhau.

Loại	Nghĩa	Bằng chứng tối thiểu	Cách ghi trong artifact
Fact đã xác minh	Thông tin kiểm tra được từ nguồn controlled hoặc nguồn chính thức	URL, artifact ID, phiên bản, ngày truy cập	Nêu nguồn và phạm vi dùng
Stakeholder input	Ý kiến, nhu cầu, vấn đề do người liên quan cung cấp	Vai trò, thời điểm, ngữ cảnh ghi nhận	Không tự nâng thành fact hay quyết định
Project assumption	Điều tạm giả định để phân tích tiếp	Lý do thiếu dữ liệu, owner cần xác minh	Gắn nhãn Project assumption
Decision	Lựa chọn giữa các phương án theo tiêu chí	Phương án, tiêu chí, authority, record	Chỉ hợp lệ khi authority được ghi nhận
Verification-required claim	Khẳng định chưa đủ bằng chứng hoặc thuộc thẩm quyền chuyên môn khác	Câu hỏi xác minh, nguồn/owner cần kiểm tra	Gắn nhãn Verification required

Fact không chứng minh Nova Foods tuân thủ. Ví dụ, OWASP ASVS 5.0.0 là chuẩn xác minh bảo mật ngành theo nguồn 00_SOURCE_MAP, nhưng không phải bằng chứng ERP mô phỏng Nova Foods đã đạt chuẩn đó.

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

flowchart TB
    A[Phát biểu về NFR] --> B{Nguồn controlled hoặc chính thức<br/>có URL hoặc artifact ID,<br/>phiên bản, ngày truy cập<br/>và hỗ trợ nội dung phát biểu?}

    B -- Có --> C[Fact đã xác minh<br/>Ghi nguồn và phạm vi áp dụng<br/>Không chứng minh hệ thống đáp ứng NFR]
    B -- Không --> D{Do stakeholder cung cấp?}

    D -- Có --> E[Stakeholder input<br/>Ghi vai trò, thời điểm<br/>và ngữ cảnh]
    D -- Không --> F{Cần giả định để<br/>tiếp tục phân tích?}

    F -- Có --> G[Project assumption<br/>Ghi lý do thiếu dữ liệu<br/>và owner cần xác minh]
    F -- Không --> H[Verification required<br/>Ghi câu hỏi xác minh<br/>và nguồn hoặc owner cần kiểm tra]

    C --> L{Còn khẳng định thiếu bằng chứng<br/>hoặc thuộc thẩm quyền khác?}
    E --> L
    G --> L

    L -- Có --> M[Gắn nhãn Verification required<br/>Ghi câu hỏi xác minh<br/>và nguồn hoặc owner cần kiểm tra]
    L -- Không --> N[Giữ trạng thái bằng chứng hiện có]

    H --> O[Đánh giá lựa chọn riêng<br/>Không tự nâng trạng thái bằng chứng]
    M --> O
    N --> O

    O --> P{Đủ phương án, tiêu chí,<br/>authority và decision record?}
    P -- Có --> J[Decision<br/>Ghi phương án, tiêu chí, authority và record<br/>Decision record không xác minh fact,<br/>stakeholder input hoặc assumption nền]
    P -- Chưa đủ --> K[Giữ trạng thái bằng chứng<br/>và yêu cầu xác minh phần còn thiếu]

Applied

Trường	Nội dung Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp
Facts	00_SOURCE_MAP ghi OWASP ASVS 5.0.0 là industry security verification standard; không phải luật Việt Nam. Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP là nguồn pháp lý chính thức, nhưng requirement hệ thống suy ra từ chúng cần Legal Owner xác minh.
Current Behavior	Một ghi chú NFR dự kiến viết: “ERP phải bảo vệ dữ liệu cá nhân theo luật và OWASP ASVS.” Câu này trộn nguồn pháp lý, chuẩn ngành, giải pháp kỹ thuật và trạng thái tuân thủ chưa được xác minh.
Underlying Need	Tách điều cần bảo vệ, căn cứ, người có thẩm quyền và tiêu chí kiểm tra trước khi biến thành requirement có thể test.
Options	1. Ghi nguyên câu chung. 2. Tách thành fact nguồn, stakeholder input, assumption, verification-required claim và decision record.
Decision Criteria	Không tuyên bố tuân thủ khi chưa có bằng chứng; giữ traceability đến nguồn; không để BA thay Legal Owner hoặc Security Owner; đầu ra phải kiểm thử được sau khi authority xác nhận.
Decision	Chọn phương án 2. Câu “bảo vệ dữ liệu cá nhân theo luật” mang nhãn Verification required cho Legal Owner. Câu “dùng OWASP ASVS làm tham chiếu kiểm thử” là stakeholder input hoặc project decision, tùy record authority.
Authority	Legal Owner xác minh diễn giải pháp lý. Security Owner xác định kiểm soát bảo mật. Business Owner quyết định ưu tiên nghiệp vụ. Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì traceability.
Artifact	Ghi trong /02-handbook/10-nonfunctional-requirements-and-quality-attributes.md; liên kết nguồn 00_SOURCE_MAP; giữ trạng thái corpus IN_REVIEW, version v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Gọi assumption là fact có thể tạo requirement sai. Gọi stakeholder input là decision có thể tạo scope không có authority. Gọi chuẩn ngành là nghĩa vụ pháp lý có thể dẫn đến kết luận compliance sai.

Senior Lens

Cầu nối suy luận phải hiện rõ: nguồn chính thức xác nhận nguồn tồn tại và phạm vi của nguồn; nó không tự xác nhận cấu hình ERP. Stakeholder nói “cần đăng xuất phiên làm việc” xác nhận nhu cầu được nêu, không xác nhận ngưỡng thời gian. Nếu chưa có phân tích rủi ro, kiến trúc hoặc Security Owner, ngưỡng phải là Project assumption hoặc Verification required, không phải NFR cuối cùng.

Decision khác fact. “WCAG 2.2 là khuyến nghị truy cập được của W3C” có thể ghi là fact nguồn. “Nova Foods sẽ áp dụng WCAG 2.2 cho cổng nhà cung cấp” chỉ là decision khi có authority và record. Không có approval reference trong corpus hiện tại; IN_REVIEW không được diễn giải là approval, baseline hay production-ready.

Quick Reference

Câu phát biểu	Phân loại đúng
“OWASP ASVS 5.0.0 được 00_SOURCE_MAP liệt kê là security verification standard.”	Fact đã xác minh
“Security Owner đề nghị giới hạn quyền xem dữ liệu nhà cung cấp.”	Stakeholder input
“Project assumption: cổng nhà cung cấp có người dùng dùng bàn phím.”	Project assumption
“Legal Owner cần xác minh nghĩa vụ lưu và hiển thị dữ liệu cá nhân.”	Verification required
“Chọn kiểm thử truy cập được theo phạm vi do Business Owner và Security Owner ghi nhận.”	Decision, chỉ khi có record authority

3. V? tr? trong Lifecycle

Core

Nonfunctional Requirement (NFR, yêu cầu phi chức năng) đi xuyên suốt Lifecycle, không phải hạng mục chỉ kiểm tra cuối dự án. NFR mô tả chất lượng hệ thống như hiệu năng, bảo mật, khả năng truy cập, độ tin cậy, khả năng vận hành. Lý do: quyết định muộn có thể làm kiến trúc, dữ liệu, API hoặc quy trình kiểm thử không còn đáp ứng được mà không tốn chi phí làm lại lớn.

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

flowchart TB
    D[Discovery] -->|Nhu cầu mơ hồ được phân loại: Project assumption hoặc Verification required; chưa là requirement cuối| A[Analysis]
    A -->|NFR đo được, traceable, có acceptance criteria và phương pháp kiểm chứng| DE[Delivery]
    DE -->|Build/configuration record và bằng chứng liên kết NFR| TB[Test basis: NFR, acceptance criteria, môi trường, dữ liệu tổng hợp]
    TB -->|Test basis sẵn sàng| T[Testing]
    T -->|Pass/fail, defect hoặc risk acceptance record| RR{Readiness review}

    T -. Hệ thống chạy được không suy ra test pass .-> NP[Không suy diễn test pass]

    RR -->|Thiếu test, test basis hoặc bằng chứng| T
    RR -->|Defect cần sửa| DE
    RR -->|Kết quả test đạt hoặc failed có risk acceptance record; có monitoring, alert, rollback, quyền vận hành| GD{Governance phê duyệt release?}

    GD -->|Approve release| R[Release]
    GD -->|Reject: cần làm rõ NFR| A
    GD -->|Reject: cần sửa build hoặc cấu hình| DE
    GD -->|Reject: cần kiểm thử lại| T

    R -->|Release record liên kết NFR và known risk| O[Operations]
    R -. IN_REVIEW không phải approval .-> IA[IN_REVIEW không phải approval]
    O -->|Metric, incident, phản hồi hoặc thay đổi tải/rủi ro| D
    O -. Metric xấu không tự tạo quyết định thay đổi .-> MC[Metric xấu cần input cho Discovery hoặc change analysis]

Giai đoạn	Entry gate chính xác	Hoạt động NFR	Exit gate chính xác
Discovery	Có vấn đề nghiệp vụ hoặc rủi ro chất lượng được ghi nhận	Nhận diện tác động: người dùng, dữ liệu, kênh truy cập, thời điểm tải cao, rủi ro bảo mật	Nhu cầu còn mơ hồ được phân loại Project assumption hoặc Verification required; không gọi là requirement cuối
Analysis	Có nhu cầu chất lượng và phạm vi chức năng liên quan	Chuyển nhu cầu thành tiêu chí đo được, điều kiện đo, phạm vi áp dụng, nguồn và traceability	NFR có ID canonical khi registry cho phép, acceptance criteria, phương pháp kiểm chứng và nhãn nguồn đúng
Delivery	NFR đã đủ để đội giao hàng hiểu điều cần xây hoặc cấu hình	Thiết kế, phát triển, cấu hình, logging, monitoring, kiểm soát truy cập theo NFR đã phân tích	Có build/configuration record và bằng chứng nội bộ liên kết NFR; thiếu bằng chứng không được coi là đạt
Testing	Có test basis: NFR, acceptance criteria, môi trường và dữ liệu tổng hợp	Kiểm thử hiệu năng, bảo mật, truy cập được hoặc độ tin cậy theo phạm vi	Kết quả pass/fail, defect hoặc risk acceptance record được ghi; không suy diễn pass từ việc hệ thống chạy được
Release	Có kết quả kiểm thử và quyết định release được ghi nhận theo governance dự án	Kiểm tra readiness: giám sát, cảnh báo, rollback, quyền vận hành	Release record liên kết NFR và known risk; IN_REVIEW không phải release approval
Operations	Hệ thống đã được đưa vào môi trường vận hành theo quyết định có thẩm quyền	Theo dõi metric, incident, phản hồi người dùng, thay đổi tải hoặc rủi ro	Evidence vận hành tạo input cho Discovery hoặc change analysis; metric xấu không tự tạo quyết định thay đổi

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp. Cổng nhà cung cấp mô phỏng cần cho người dùng tra cứu trạng thái đơn mua hàng. Nhu cầu “trang phản hồi nhanh” chưa có ngưỡng thời gian, tải đồng thời, thiết bị hay cách đo.

Current Behavior: Nếu chuyển thẳng nhu cầu này sang Delivery, đội kỹ thuật có thể chọn tối ưu tùy ý. Testing sau đó không có tiêu chí pass/fail. Cầu nối suy luận: không có ngưỡng đo thì không thể so sánh kết quả đo với kỳ vọng.

Underlying Need: Cần đưa nhu cầu qua Analysis để xác định metric, ví dụ thời gian phản hồi, percentile, loại giao dịch, môi trường đo và tải mô phỏng. Đây là điều kiện để Testing tạo bằng chứng thay vì nhận xét cảm tính.

Options: (1) Ghi “nhanh” và giao Delivery tự diễn giải. (2) Ghi NFR đo được nhưng chưa xác minh tải dự kiến. (3) Giữ tải và ngưỡng là Verification required, chỉ chuyển Delivery sau khi đủ đầu vào.

Decision Criteria: Chọn phương án chỉ khi NFR có đơn vị đo, phạm vi, điều kiện đo, nguồn của ngưỡng và cách kiểm chứng. Nếu thiếu một thành phần, Analysis chưa đạt exit gate.

Decision: Chọn phương án (3). Artifact NFR giữ trạng thái IN_REVIEW, version v0.9.0; chưa được gọi baseline, approved hoặc production-ready.

Authority: Batch này không phân bổ owner, handoff hay quyền quyết định. Record quyết định phải tham chiếu authority hợp lệ trước Release; không suy diễn authority từ artifact tồn tại.

Artifact: Requirement record liên kết /01-curriculum/TRACEABILITY_ID_REGISTRY.md, nguồn phân loại từ /00-research/00_SOURCE_MAP.md, và test result record. Không tạo ID mới khi registry chưa đăng ký ID.

Consequence if Wrong: Đưa NFR mơ hồ vào Delivery tạo build không có mục tiêu đo. Đưa kết quả test không có test basis vào Release tạo kết luận chất lượng không chứng minh được. Gọi IN_REVIEW là approval tạo sai lệch governance.

Senior Lens

Entry gate kiểm soát chất lượng đầu vào; exit gate kiểm soát bằng chứng trước khi chuyển giai đoạn. Gate không phải cuộc họp mặc định. Gate là điều kiện kiểm tra được: artifact nào phải có, trạng thái gì, thiếu gì thì dừng ở đâu. Ví dụ, “có NFR” không đủ cho exit Analysis; phải có acceptance criteria và phương pháp kiểm chứng. Lý do: Delivery cần biết phải làm gì, Testing cần biết phải chứng minh điều gì.

NFR vận hành tạo vòng phản hồi. Incident, metric hoặc thay đổi tải là evidence mới, không phải bằng chứng rằng requirement cũ sai ngay lập tức. Evidence phải quay lại Discovery hoặc Analysis để xác định nguyên nhân, phạm vi và thay đổi cần thiết. Điều này tránh vá production bằng yêu cầu chưa được phân tích.

Quick Reference

Gate	Được chuyển tiếp khi	Không được kết luận
Discovery sang Analysis	Có nhu cầu chất lượng và nguồn hoặc nhãn xác minh	Nhu cầu mơ hồ là NFR hoàn chỉnh
Analysis sang Delivery	Có tiêu chí đo, phạm vi, traceability, cách kiểm chứng	Có requirement là đã xây đúng
Delivery sang Testing	Có build/configuration evidence và test basis	Build thành công là đạt NFR
Testing sang Release	Có kết quả đối chiếu acceptance criteria và record rủi ro	Pass kỹ thuật là approval release
Release sang Operations	Có release record và khả năng theo dõi phù hợp phạm vi	Release là kết thúc trách nhiệm NFR
Operations sang Discovery	Có metric, incident hoặc phản hồi làm evidence	Một incident tự xác định solution

Core

Yêu cầu phi chức năng (Nonfunctional Requirement, NFR) cần chủ sở hữu xuyên suốt vì một yêu cầu về hiệu năng, bảo mật, khả năng truy cập hoặc tính sẵn sàng không tự chuyển thành cấu hình, kiểm thử và vận hành. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu đều tổng hợp, trạng thái corpus là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

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

flowchart TB
    BO[Business Owner]
    BA[Business Analyst]
    ARCH[Solution Architect]
    DEV[Delivery Team]
    QA[QA Owner]
    REL[Release Owner]
    OPS[Operations Owner]
    ESC[Escalation Owner]

    BO -->|mục tiêu, mức ưu tiên, hậu quả nếu không đạt| BA
    BA -->|NFR đo được, phạm vi, điều kiện, nguồn, TRACEABILITY_ID_REGISTRY| ARCH
    ARCH -->|quyết định thiết kế, ràng buộc kỹ thuật, cách đo| DEV
    DEV -->|build, cấu hình, dữ liệu tổng hợp, hướng dẫn tái lập| QA
    QA -->|kết quả kiểm thử, lỗi mở, rủi ro còn lại, bằng chứng| REL
    REL -->|runbook, ngưỡng cảnh báo, quan sát, rollback| OPS
    OPS -->|số đo, sự cố, xu hướng, ảnh hưởng nghiệp vụ| BA
    OPS -->|số đo, sự cố, xu hướng, ảnh hưởng nghiệp vụ| BO

    BO -.->|mục tiêu tăng chi phí, giảm phạm vi hoặc mâu thuẫn| ESC
    BA -.->|NFR không đo được, thiếu chủ sở hữu chỉ số hoặc xung đột kiến trúc| ESC
    DEV -.->|thiết kế không đáp ứng NFR hoặc phụ thuộc ngoài kiểm soát| ESC
    DEV -.->|thay đổi ảnh hưởng bảo mật| ESC
    QA -.->|không tái lập được phép đo, môi trường sai điều kiện hoặc lỗi vượt ngưỡng| ESC
    REL -.->|lỗi nghiêm trọng còn mở hoặc thiếu bằng chứng| ESC
    REL -.->|rủi ro nghiệp vụ cần chấp nhận| BO
    REL -.->|rủi ro pháp lý| ESC
    OPS -.->|số đo production khác ngưỡng hoặc không có rollback| ESC
    OPS -.->|sự cố ảnh hưởng dữ liệu hoặc bảo mật| ESC
    OPS -.->|sự cố lặp lại hoặc ngưỡng không phù hợp| ESC
    OPS -.->|cần đổi ưu tiên kinh doanh| BO

Handoff	Upstream owner	Downstream owner	Vật bàn giao tối thiểu	Giới hạn thẩm quyền	Điểm escalation
Mục tiêu chất lượng sang phân tích	Business Owner	BA	Mục tiêu nghiệp vụ, mức ưu tiên, hậu quả nếu không đạt	Business Owner không tự chọn kiến trúc hay ngưỡng kỹ thuật	Mục tiêu làm tăng chi phí, giảm phạm vi hoặc mâu thuẫn mục tiêu khác
NFR sang thiết kế	BA	Solution Architect	NFR có chỉ số đo, phạm vi, điều kiện đo, nguồn và liên kết TRACEABILITY_ID_REGISTRY	BA làm rõ nhu cầu, không phê chuẩn kiến trúc, bảo mật hay tuân thủ pháp lý	Không đo được, thiếu chủ sở hữu chỉ số, hoặc NFR xung đột kiến trúc
Thiết kế sang delivery	Solution Architect	Delivery Team	Quyết định thiết kế, ràng buộc kỹ thuật, cách đo đã chọn	Delivery Team không tự hạ ngưỡng NFR để kịp tiến độ	Thiết kế không đáp ứng NFR, phụ thuộc ngoài kiểm soát, hoặc thay đổi ảnh hưởng bảo mật
Build sang kiểm thử	Delivery Team	QA Owner	Build, cấu hình môi trường, dữ liệu tổng hợp, hướng dẫn tái lập	QA Owner xác nhận bằng chứng kiểm thử, không tự đổi yêu cầu	Không tái lập được phép đo, môi trường khác điều kiện đã quy định, hoặc lỗi vượt ngưỡng
Kiểm thử sang release	QA Owner	Release Owner	Kết quả kiểm thử, lỗi mở, rủi ro còn lại, bằng chứng truy vết	Release Owner điều phối phát hành, không tự chấp nhận rủi ro nghiệp vụ hoặc pháp lý	Lỗi nghiêm trọng còn mở, thiếu bằng chứng, hoặc rủi ro cần Business Owner chấp nhận
Release sang vận hành	Release Owner	Operations Owner	Runbook, ngưỡng cảnh báo, cách quan sát, cách rollback	Operations Owner xử lý vận hành, không sửa NFR canonical	Số đo production khác ngưỡng, không có rollback, hoặc sự cố ảnh hưởng dữ liệu hay bảo mật
Vận hành sang cải tiến	Operations Owner	BA và Business Owner	Số đo, sự cố, xu hướng, ảnh hưởng nghiệp vụ	BA cập nhật phân tích có truy vết, không tự sửa quyết định đã kiểm soát	Sự cố lặp lại, ngưỡng không phù hợp, hoặc cần đổi ưu tiên kinh doanh

Applied

Facts: Nova Foods mô phỏng cần người dùng tạo đơn bán hàng trong giờ cao điểm. Đề xuất NFR: 95% thao tác lưu đơn hoàn tất không quá 2 giây, đo từ lúc người dùng gửi yêu cầu đến khi API trả kết quả thành công. Dữ liệu kiểm thử là tổng hợp; không suy ra năng lực ERP thực tế.

Current Behavior: BA ghi “hệ thống phải nhanh”. Delivery Team không có ngưỡng để tối ưu. QA Owner không biết phép đo nào quyết định đạt hay không đạt. Operations Owner không có ngưỡng cảnh báo tương ứng.

Underlying Need: Cần một cam kết có thể đo, có người nhận bàn giao và có người đủ thẩm quyền giải quyết khi tốc độ, chi phí và phạm vi xung đột. Lý do: từ “nhanh” không tạo được kết quả kiểm thử nhị phân; chỉ số phần trăm, thời lượng và điều kiện đo tạo được.

Options: (1) Giữ mô tả “nhanh”; (2) đặt ngưỡng 2 giây nhưng không nêu phân vị; (3) nêu 95%, 2 giây, thao tác, điểm bắt đầu và kết thúc phép đo.

Decision Criteria: Chọn phương án đo được bởi QA, quan sát được bởi Operations, không để BA tự quyết cấu hình, và liên kết được tới yêu cầu nghiệp vụ trong TRACEABILITY_ID_REGISTRY.

Decision: Chọn phương án (3). BA ghi NFR và tiêu chí đo. Solution Architect xác định cách thiết kế đáp ứng ngưỡng. QA Owner xác minh trên điều kiện đã nêu. Operations Owner theo dõi cùng chỉ số sau release.

Authority: Business Owner quyết định mức ưu tiên và chấp nhận đánh đổi nghiệp vụ. Solution Architect quyết định giải pháp kỹ thuật. QA Owner xác nhận bằng chứng kiểm thử. Release Owner điều phối quyết định phát hành theo bằng chứng và thẩm quyền đã ghi nhận. Nếu ngưỡng ảnh hưởng dữ liệu cá nhân, bảo mật, kế toán, thuế, an toàn thực phẩm hoặc nghĩa vụ pháp lý, phải chuyển Legal Owner, Security Owner, Accounting Owner hoặc domain owner xác minh; không suy diễn từ corpus.

Artifact: Bản ghi NFR phải trỏ đúng CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY khi có quy tắc hoặc dữ liệu liên quan, và TRACEABILITY_ID_REGISTRY cho liên kết định danh. Các artifact này tại IN_REVIEW không phải baseline hay approval.

Consequence if Wrong: Nếu BA tự chốt 2 giây như quyết định kỹ thuật, quyết định vượt thẩm quyền. Nếu QA chỉ kiểm thử trung bình thay vì 95%, hệ thống có thể đạt trung bình nhưng vẫn làm nhiều người dùng chờ lâu. Nếu Operations không nhận ngưỡng, suy giảm sau release không được phát hiện nhất quán.

Senior Lens

Escalation không phải chuyển trách nhiệm. Escalation là khóa quyết định khi người đang xử lý không có quyền chọn giữa các đánh đổi. BA phải gửi gói vấn đề gồm: NFR hiện hành, bằng chứng xung đột, phương án, ảnh hưởng phạm vi-chi phí-rủi ro, owner cần quyết định, và artifact bị ảnh hưởng. Bằng chứng này giữ traceability nhưng không biến BA thành người phê duyệt.

Không cho phép một vai trò tự nhận cả ba quyền: đặt mục tiêu nghiệp vụ, chọn kiểm soát kỹ thuật và chấp nhận rủi ro còn lại. Tách quyền này giúp phát hiện xung đột sớm: Business Owner có thể muốn phát hành nhanh; Security Owner có thể yêu cầu kiểm soát mạnh hơn; Release Owner chỉ điều phối khi đủ quyết định có thẩm quyền, không thay các quyết định đó.

Quick Reference

Tình huống	Owner xử lý đầu tiên	Escalate tới
NFR thiếu chỉ số hoặc điều kiện đo	BA	Business Owner và Solution Architect
NFR không khả thi trong thiết kế hiện tại	Solution Architect	Business Owner quyết định đánh đổi
Kết quả test không đạt ngưỡng	QA Owner	Release Owner, Business Owner khi cần chấp nhận rủi ro
Sự cố sau release vượt ngưỡng vận hành	Operations Owner	Release Owner, Solution Architect, Business Owner
Có dữ liệu cá nhân hoặc nghĩa vụ pháp lý	BA giữ gói truy vết	Legal Owner và Security Owner xác minh
Có ảnh hưởng kế toán hoặc hóa đơn	BA giữ gói truy vết	Accounting Owner và Legal Owner xác minh

Core

Bản đồ vòng đời giúp thấy lúc yêu cầu phi chức năng đi qua các pha mà không biến nó thành quyết định triển khai. Yêu cầu phi chức năng (Nonfunctional Requirement, NFR) mô tả chất lượng hệ thống như hiệu năng, bảo mật, khả dụng, thay vì chức năng nghiệp vụ. Nova Foods Trading & Manufacturing là case mô phỏng; mọi dữ liệu là tổng hợp, trạng thái corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

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

flowchart TB
    D[Discovery<br/>Nêu nhu cầu chất lượng] -->|G-D: vấn đề và đối tượng bị ảnh hưởng rõ| A[Analysis<br/>Làm rõ, đo lường, truy vết]
    A -->|G-A: NFR có tiêu chí kiểm chứng| DE[Delivery<br/>Thiết kế và xây dựng]
    DE -->|G-DE: giải pháp có bằng chứng kỹ thuật| T[Testing<br/>Kiểm tra tiêu chí chất lượng]
    T -->|G-T: kết quả kiểm thử được ghi nhận| R[Release<br/>Đánh giá sẵn sàng phát hành]
    R -->|G-R: quyết định phát hành thuộc thẩm quyền| O[Operations<br/>Theo dõi chất lượng thực tế]
    O -->|Sự cố, số liệu hoặc thay đổi nhu cầu| D

    BA[BA] -.ghi nhận và duy trì truy vết.-> D
    BA -.làm rõ tiêu chí.-> A
    Architect[Architect] -.xác nhận khả thi kỹ thuật.-> DE
    QA[QA] -.xác minh bằng chứng kiểm thử.-> T
    ReleaseOwner[Release Owner] -.quyết định phát hành.-> R
    Operations[Operations] -.cung cấp số liệu vận hành.-> O

G-D, G-A, G-DE, G-T, G-R là cổng kiểm soát, không phải trạng thái phê duyệt. Lý do: artifact đang IN_REVIEW; sơ đồ chỉ chỉ ra nơi cần quyết định và bằng chứng, không tạo approval ngầm định.

Applied

Mục	Nội dung mô phỏng Nova Foods
Facts	Nhóm ERP giả định cần màn hình tạo đơn bán hàng phản hồi nhanh cho nhân viên nội bộ tại Việt Nam.
Current Behavior	Nhu cầu “màn hình phải nhanh” xuất hiện ở Discovery, chưa có thời gian phản hồi đo được.
Underlying Need	Người dùng cần hoàn thành nhập đơn mà không chờ lâu; từ đó BA phải chuyển nhận xét chủ quan thành tiêu chí kiểm chứng.
Options	Giữ mô tả định tính; hoặc phân tích để đặt chỉ số đo, phạm vi giao dịch và điều kiện kiểm thử.
Decision Criteria	Tiêu chí phải đo được, gắn luồng nghiệp vụ, có môi trường kiểm thử xác định và có owner xác minh.
Decision	Đi qua G-A chỉ khi NFR nêu rõ giao dịch, ngưỡng, tải giả định và cách đo; giá trị cụ thể còn cần xác nhận bởi Business Owner, Architect và QA.
Authority	BA quản lý làm rõ và traceability. Architect xác nhận khả thi. QA xác nhận cách kiểm thử. Business Owner quyết định mức chất lượng chấp nhận được.
Artifact	NFR record liên kết requirement, acceptance criteria và test evidence; không tạo ID mới trong sơ đồ này.
Consequence if Wrong	Nếu nhảy từ Discovery sang Delivery, đội kỹ thuật có thể tối ưu sai luồng; QA không có test basis, Release Owner không có bằng chứng để đánh giá rủi ro.

Senior Lens

Không gắn nhãn “đạt” khi chỉ có thiết kế hoặc chỉ có kết quả test. Thiết kế chứng minh hướng xử lý; test chứng minh hành vi trong điều kiện đã định; Operations cho thấy chất lượng sau phát hành. Ba loại bằng chứng khác nhau vì môi trường, tải và dữ liệu có thể khác nhau.

Khi Operations phát hiện suy giảm chất lượng, quay lại Discovery để ghi nhận vấn đề mới hoặc giả định sai. Không sửa im lặng NFR cũ. Giữ liên kết từ sự cố hoặc chỉ số vận hành về requirement và bằng chứng trước đó để phân biệt lỗi xây dựng, lỗi kiểm thử, hoặc thay đổi nhu cầu.

Quick Reference

Pha	Mục đích trên bản đồ	Điều kiện chuyển pha tối thiểu
Discovery	Nhận diện nhu cầu chất lượng	Vấn đề, người bị ảnh hưởng, bối cảnh rõ
Analysis	Chuyển nhu cầu thành tiêu chí kiểm chứng	Có NFR và cách chứng minh
Delivery	Xây dựng phương án đáp ứng	Có bằng chứng kỹ thuật phù hợp
Testing	Kiểm tra tiêu chí đã định	Có kết quả test ghi nhận
Release	Đánh giá sẵn sàng phát hành	Quyết định do đúng owner giữ
Operations	Quan sát chất lượng sau phát hành	Có số liệu hoặc tín hiệu để phản hồi vòng đời

4. Input c?n thi?t

Core

NFR (Nonfunctional Requirement, yêu cầu phi chức năng) mô tả chất lượng hệ thống phải đạt, như hiệu năng, bảo mật, khả năng truy cập. Trước khi viết NFR, BA cần đầu vào chứng minh vì sao chất lượng đó cần tồn tại. Không suy ra từ cảm tính, kinh nghiệm cá nhân, hoặc tên tính năng.

Đầu vào gồm bốn nhóm. Kiến thức nền giúp hiểu khái niệm. Bằng chứng cho biết vấn đề hay nhu cầu có cơ sở. Artifact nguồn giữ nội dung tại nơi kiểm soát. Canonical ID là mã định danh cố định, dùng nguyên dạng để mọi tài liệu trỏ cùng một đối tượng.

Nhóm đầu vào	Câu hỏi BA phải trả lời	Nova Foods mô phỏng: nguồn dùng được
Kiến thức nền	NFR khác chức năng thế nào? Ai chịu ảnh hưởng? Chất lượng được đo ra sao?	BABOK Guide cho thuật ngữ BA; ISO/IEC/IEEE 29148 cho bối cảnh yêu cầu; ISTQB CTFL cho thuật ngữ kiểm thử
Bằng chứng	Nhu cầu chất lượng xuất phát từ dữ kiện nào?	Luồng nghiệp vụ mô phỏng, phản hồi người dùng mô phỏng, sơ đồ tích hợp, giả định dự án có nhãn
Artifact nguồn	Nội dung gốc nằm ở tệp kiểm soát nào?	/01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md
Canonical ID	Mã nào giữ liên kết không đổi giữa artifact?	CHAPTER_MANIFEST, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY

Canonical ID không phải tên hiển thị. Ví dụ, “Từ điển dữ liệu Nova Foods” có thể được viết khác nhau trong câu, nhưng khi liên kết artifact phải dùng đúng CANONICAL_DATA_DICTIONARY. Lý do: tên tự do có thể trùng hoặc đổi; ID cố định giúp QA, Architect và BA truy lại cùng nguồn.

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

flowchart TB
    K[Kiến thức nền] --> H[BA hiểu loại nhu cầu chất lượng]
    E[Bằng chứng mô phỏng] --> C[Nhu cầu chất lượng có dữ kiện hỗ trợ]
    A[Artifact nguồn kiểm soát] --> L[Liên kết artifact nguồn bằng Canonical ID]
    I[Canonical ID] --> L
    H --> G[Đủ điều kiện ghi NFR]
    C --> G
    L --> G
    G --> N[BA ghi NFR có cơ sở]

Sơ đồ không tạo requirement mới. Nó cho thấy cầu nối suy luận: BA chỉ ghi NFR khi hiểu khái niệm, có dữ kiện, biết artifact nguồn, và giữ liên kết bằng ID canonical.

Applied

Facts: Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Corpus đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND. Không có baseline hay approval được ghi nhận.

Current Behavior: Người học mới thường thấy câu “hệ thống phải nhanh” rồi viết thành NFR. Câu này chưa chỉ ra người dùng nào, tình huống nào, bằng chứng nào, hay nguồn nào giữ yêu cầu.

Underlying Need: BA cần lập danh mục đầu vào trước khi diễn đạt nhu cầu chất lượng. Mục tiêu là ngăn một yêu cầu về hiệu năng, bảo mật, hoặc khả năng truy cập bị tách khỏi nguồn và lý do tồn tại.

Options:
1. Viết NFR từ nhận định cá nhân.
2. Dùng tài liệu nguồn nhưng không giữ ID.
3. Ghi nhận kiến thức, bằng chứng, artifact nguồn và canonical ID.

Decision Criteria: Chọn cách cho phép người khác truy lại nguồn, phân biệt fact với project assumption, và không biến nội dung học liệu thành quyết định vận hành Nova Foods.

Decision: Dùng lựa chọn 3. Mỗi ghi nhận đầu vào phải liên kết ít nhất một artifact kiểm soát hoặc nguồn chuẩn đã công bố. Khi chưa có dữ kiện Nova Foods, ghi rõ đó là project assumption của case study mô phỏng; không diễn đạt như fact vận hành.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết artifact và ID. Vai trò này không có thẩm quyền xác nhận yêu cầu Nova Foods, diễn giải pháp lý, xác nhận kiến trúc, hay cấp approval.

Artifact: Danh mục đầu vào cho section này tham chiếu các ID và tệp canonical sau.

Canonical ID	Tệp canonical	Vai trò làm đầu vào	Ranh giới sử dụng
CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Xác nhận chapter, filename, trạng thái corpus	Không phải nguồn quyết định NFR vận hành
TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Giữ quy tắc định danh và liên kết truy vết	Không tự cấp approval cho ID hay requirement
CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Phân biệt business rule với nhu cầu chất lượng	IN_REVIEW không phải quy tắc đã áp dụng
CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Hiểu dữ liệu logic có thể ảnh hưởng NFR	Không phải thiết kế DB hay cấu hình ERP
00_SOURCE_MAP	/00-research/00_SOURCE_MAP.md	Xác định nguồn chuẩn và giới hạn trích dẫn	Không bịa số trang, điều khoản, hoặc nội dung licensed text

Consequence if Wrong: Nếu dùng tên tệp thay cho canonical ID, liên kết có thể trỏ sai khi tên hiển thị thay đổi. Nếu dùng project assumption như fact, đội kỹ thuật có thể xây sai mức chất lượng. Nếu dùng trạng thái IN_REVIEW như approval, artifact bị diễn giải vượt thẩm quyền.

Senior Lens

Bằng chứng không cần là tài liệu dài. Một sơ đồ luồng có kiểm soát, một giới hạn tích hợp được mô tả rõ, hoặc một giả định được gắn nhãn đều có thể là đầu vào. Giá trị nằm ở cầu nối: dữ kiện nào dẫn đến nhu cầu nào, và ai có thể kiểm tra lại cầu nối đó.

Không dùng tiêu chuẩn như ISO/IEC/IEEE 29148, WCAG 2.2, hoặc OWASP ASVS để tự tạo nghĩa vụ Nova Foods. Tiêu chuẩn cung cấp ngôn ngữ và khung tham chiếu. Nghĩa vụ áp dụng cho hệ thống mô phỏng chỉ xuất hiện khi artifact ghi nhận nhu cầu, bằng chứng, và thẩm quyền phù hợp.

Quick Reference

Cần có trước khi phân tích NFR	Cách nhận biết
Khái niệm chất lượng	BA giải thích được điều cần bảo vệ hoặc cải thiện
Bằng chứng hoặc giả định có nhãn	Có lý do rõ cho nhu cầu, không dựa vào khẩu hiệu
Artifact nguồn	Có đường dẫn canonical trong corpus
Canonical ID	Có ID nguyên dạng để giữ traceability
Ranh giới thẩm quyền	Không gọi IN_REVIEW là baseline, approval, compliance, hoặc production-ready

Kiểm soát chất lượng, nguồn, độ mới và điều kiện dừng đầu vào

Core

Đầu vào cho yêu cầu phi chức năng chỉ dùng khi BA biết: nguồn nào phát hành, ai chịu trách nhiệm, thông tin còn mới không, và có đủ bằng chứng không. Phân loại nguồn là nhãn cho biết mức thẩm quyền của nguồn. Nguồn chính thức có cơ quan phát hành rõ và URL chính thức; nguồn nội bộ là artifact kiểm soát của corpus; giả định dự án chưa phải sự thật vận hành; mục cần xác minh chưa được dùng làm yêu cầu bắt buộc.

Phân loại	Điều kiện nhận diện	Cách dùng	Không được làm
PRIMARY_OFFICIAL	Cơ quan chuẩn, pháp luật, tổ chức phát hành công bố	Xác định thuật ngữ, bối cảnh nghĩa vụ cần kiểm tra	Suy diễn điều khoản chưa kiểm tra
CONTROLLED_INTERNAL	Artifact canonical, có ID, path, status, version	Truy vết phạm vi, trạng thái, định danh	Gọi là baseline hoặc approval
PROJECT_ASSUMPTION	Giả định mô phỏng có lý do ghi rõ	Làm dữ liệu thảo luận, phân tích phương án	Viết thành rule bắt buộc
VERIFICATION_REQUIRED	Thiếu owner có thẩm quyền, thiếu bản gốc, hoặc có xung đột	Chặn quyết định; lập điểm xác minh	Đưa vào acceptance criteria
SECONDARY_REFERENCE	Tài liệu diễn giải, đào tạo, tóm tắt	Giải thích khái niệm	Thay thế nguồn chính thức

Độ mới là thời điểm bằng chứng còn phù hợp với quyết định. Mỗi input ghi ngày truy cập hoặc cập nhật theo Asia/Ho_Chi_Minh. Nguồn pháp luật, bảo mật, API, kiến trúc có thay đổi nhanh phải kiểm tra lại trước khi biến thành yêu cầu. Trong corpus này, URL nguồn seed được truy cập ngày 2026-08-07; đây là bằng chứng tra cứu, không xác nhận nội dung Nova Foods tuân thủ.

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

flowchart TB
    A[Nhận input] --> T{Có nguồn phát hành và<br/>owner chịu trách nhiệm?}
    T -- Không --> V[VERIFICATION_REQUIRED]
    T -- Có --> D{Có ngày truy cập hoặc cập nhật<br/>theo Asia/Ho_Chi_Minh?}
    D -- Không --> V
    D -- Có --> F{Còn mới và đúng phạm vi?}
    F -- Không --> V
    F -- Có --> B{Phân loại nguồn}

    B -- PRIMARY_OFFICIAL --> P{Có cơ quan phát hành<br/>và URL chính thức?}
    P -- Không --> V
    P -- Có --> P1[Phân tích thuật ngữ và<br/>bối cảnh nghĩa vụ cần kiểm tra]

    B -- CONTROLLED_INTERNAL --> I{Có ID, path,<br/>status và version?}
    I -- Không --> V
    I -- Có --> I1[Truy vết phạm vi,<br/>trạng thái và định danh]

    B -- PROJECT_ASSUMPTION --> A1{Có lý do ghi rõ?}
    A1 -- Không --> V
    A1 -- Có --> A2[Dùng để thảo luận,<br/>phân tích phương án]
    A2 --> X1[Không viết thành<br/>rule bắt buộc]

    B -- SECONDARY_REFERENCE --> R1[Giải thích khái niệm]
    R1 --> X2[Không thay thế<br/>nguồn chính thức]

    B -- VERIFICATION_REQUIRED --> V
    V --> V1[Chặn quyết định;<br/>lập điểm xác minh]
    V1 --> X3[Không đưa vào<br/>acceptance criteria]

    P1 --> H{Nguồn pháp luật, bảo mật,<br/>API hoặc kiến trúc?}
    I1 --> H
    H -- Có --> K{Đã kiểm tra lại trước khi<br/>biến thành yêu cầu?}
    K -- Không --> V
    K -- Có --> G{Có bằng chứng gốc hợp lệ<br/>và không có xung đột?}
    H -- Không --> G

    G -- Không --> V
    G -- Có --> O{Cần xác minh hoặc quyết định<br/>từ owner?}
    O -- Không --> N[Đủ điều kiện phân tích NFR]
    O -- Có --> W{Owner chịu trách nhiệm có<br/>thẩm quyền quyết định?}
    W -- Có --> E[Owner có thẩm quyền xác nhận]
    W -- Không --> C[Escalate đúng owner<br/>có thẩm quyền]
    C --> E
    E --> N

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dữ liệu tổng hợp. Corpus có Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07. 00_SOURCE_MAP, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY là artifact kiểm soát, chưa phải baseline hay approval.

Current Behavior: BA nhận một phát biểu: “ERP phải bảo vệ dữ liệu khách hàng.” Phát biểu không nêu loại dữ liệu, luồng truy cập, tiêu chí kiểm tra, owner bảo mật, hay nguồn pháp lý áp dụng.

Underlying Need: Biến phát biểu mơ hồ thành input có thể phân tích mà không tự tạo nghĩa vụ pháp lý hay quyết định bảo mật.

Options: (1) Viết ngay yêu cầu bảo mật chi tiết. (2) Gắn phát biểu là PROJECT_ASSUMPTION. (3) Gắn VERIFICATION_REQUIRED, liên kết nguồn chuẩn và chuyển đúng owner xác minh.

Decision Criteria: Chọn phương án chỉ khi giữ được traceability, không vượt thẩm quyền, không gọi giả định là compliance, và không cho phép test dựa trên dữ kiện chưa xác minh.

Decision: Chọn phương án (3). Bằng chứng: OWASP ASVS 5.0.0 là chuẩn xác minh bảo mật ngành, không phải luật Việt Nam; Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP cần Legal Owner xác minh trước khi suy ra yêu cầu hệ thống.

Authority: Security Owner xác minh kiểm soát bảo mật; Legal Owner xác minh diễn giải pháp luật; Architect xác minh kiến trúc; Principal IT Business Analyst / Technical Curriculum Author giữ traceability, không thay thế các vai trò này.

Artifact: Ghi điểm xác minh trong /02-handbook/10-nonfunctional-requirements-and-quality-attributes.md; tham chiếu nguồn từ /00-research/00_SOURCE_MAP.md; giữ ID artifact nguyên dạng.

Consequence if Wrong: Nếu BA gọi phát biểu là yêu cầu đã xác nhận, QA có thể test sai, Architect có thể thiết kế sai phạm vi, và corpus có thể ngụ ý Nova Foods mô phỏng đã tuân thủ pháp luật hoặc chuẩn bảo mật.

Senior Lens

Kiểm tra chất lượng input theo năm câu hỏi: nguồn nào, ai sở hữu, mới đến ngày nào, dùng trong phạm vi nào, thiếu gì để quyết định? Một input có URL nhưng không có owner vẫn không đủ để quyết định. Một input có owner nhưng không có nguồn hoặc ngày hiệu lực vẫn không đủ để viết NFR. Mâu thuẫn giữa hai nguồn canonical không được BA tự chọn bên thắng; dừng và escalation vì lựa chọn đó có thể thành quyết định nghiệp vụ, pháp lý, kế toán, bảo mật hoặc kiến trúc.

Điều kiện dừng áp dụng ngay khi có một trong các trạng thái: ID canonical chưa đăng ký; filename hoặc status mâu thuẫn artifact nguồn; nguồn pháp lý bị diễn đạt thành nghĩa vụ khi Legal Owner chưa xác minh; số liệu mô phỏng bị trình bày như dữ liệu thật; nguồn quá cũ so với thay đổi cần quyết định; hoặc owner quyết định chưa xác định. IN_REVIEW chỉ cho phép phân tích có nhãn; không cho phép tuyên bố APPROVED, BASELINED, production-ready hay compliant.

Quick Reference

Kiểm tra	Đạt khi	Không đạt khi	Hành động
Nguồn	Có phân loại và URL/path canonical	Chỉ có lời kể hoặc bản sao không kiểm soát	Gắn VERIFICATION_REQUIRED
Độ mới	Có ngày cập nhật/truy cập 2026-08-07 hoặc ngày phù hợp	Không có ngày hoặc có dấu hiệu thay đổi	Kiểm tra lại nguồn
Ownership	Có vai trò quyết định đúng lĩnh vực	Owner chỉ là người ghi chép	Escalate
Phạm vi	Nêu rõ dùng để giải thích, phân tích, hay xác minh	Dùng nguồn đào tạo làm nghĩa vụ	Hạ phân loại nguồn
Stop condition	Không có điểm chặn	Có thiếu ID, thẩm quyền, hiệu lực hoặc bằng chứng	Dừng soạn yêu cầu

Core

Bảng dưới là inventory đầu vào cho Nonfunctional Requirements (NFR, yêu cầu phi chức năng): yêu cầu về chất lượng như hiệu năng, bảo mật, khả năng dùng, không mô tả chức năng nghiệp vụ. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi giá trị là dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND.

ID đầu vào	Input / giá trị tổng hợp	Artifact hoặc nguồn canonical	Phân loại nguồn	Owner ghi nhận	Tình trạng xác minh
00_SOURCE_MAP	Danh mục nguồn chuẩn, ngày truy cập 2026-08-07	/00-research/00_SOURCE_MAP.md	Nguồn nghiên cứu kiểm soát	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW; không phải approval
01_CURRICULUM_ARCHITECTURE	Phạm vi curriculum, Nova Foods mô phỏng, dữ liệu tổng hợp	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Artifact kế hoạch kiểm soát	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW; không baseline
CHAPTER_MANIFEST	Chapter 10 Nonfunctional Requirements And Quality Attributes	/01-curriculum/CHAPTER_MANIFEST.md	Manifest kiểm soát	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW; không xác nhận NFR vận hành
TRACEABILITY_ID_REGISTRY	Quy tắc giữ nguyên ID khi liên kết artifact	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Registry định danh canonical	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW; Verification required khi cần ID mới
CANONICAL_BUSINESS_RULES	Catalog quy tắc nghiệp vụ dự kiến, không tự suy ra NFR	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Catalog kế hoạch kiểm soát	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW; chưa là rule vận hành
CANONICAL_DATA_DICTIONARY	Kế hoạch từ điển dữ liệu logic cho Nova Foods	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Kế hoạch dữ liệu canonical	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW; Verification required cho phân loại dữ liệu thật
ISO/IEC/IEEE 29148:2018	Nguồn thuật ngữ và khung yêu cầu hệ thống	https://www.iso.org/standard/72089.html	Chuẩn quốc tế, nguồn chính	ISO/IEC/IEEE	Bản đầy đủ cần licensed-text verification
WCAG 2.2	Nguồn chuẩn accessibility, khả năng tiếp cận	https://www.w3.org/TR/WCAG22/	Khuyến nghị chuẩn, nguồn chính	W3C	Verification required trước khi nêu tiêu chí cụ thể
OWASP ASVS 5.0.0	Nguồn tham chiếu kiểm chứng bảo mật ứng dụng	https://owasp.org/www-project-application-security-verification-standard/	Good practice ngành	OWASP Foundation	Không phải luật Việt Nam
Luật 91/2025/QH15	Bối cảnh bảo vệ dữ liệu cá nhân	https://vanban.chinhphu.vn/?classid=1&docid=214590&pageid=27160&typegroup=	Nguồn pháp lý chính thức	Quốc hội Việt Nam	Verification required: Legal Owner cho mọi yêu cầu hệ thống suy ra
Nghị định 356/2025/NĐ-CP	Bối cảnh hướng dẫn bảo vệ dữ liệu cá nhân	https://vanban.chinhphu.vn/?classid=1&docid=216387&pageid=27160	Nguồn pháp lý chính thức	Chính phủ Việt Nam	Verification required: Legal Owner cho diễn giải áp dụng
Luật 55/2010/QH12	Bối cảnh truy xuất nguồn gốc và thu hồi thực phẩm	https://vanban.chinhphu.vn/?docid=96032&pageid=27160	Nguồn pháp lý chính thức	Quốc hội Việt Nam	Verification required: Legal Owner và Domain Owner

Applied

Facts: Nova Foods mô phỏng có dữ liệu khách hàng, đơn hàng, lô hàng và giá trị VND, nhưng không có bằng chứng vận hành ERP thật, SLA thật, kiến trúc thật hoặc quyết định pháp lý đã xác nhận. Current Behavior: corpus có artifact kiểm soát và nguồn chính thức, tất cả ở IN_REVIEW. Underlying Need: BA cần biết input nào được dùng làm bằng chứng, input nào chỉ là tham chiếu, và chỗ nào phải dừng suy luận.

Options: dùng giả định như sự thật; hoặc giữ từng input cùng nguồn, owner và nhãn xác minh. Decision Criteria: không bịa rule Nova Foods, không biến nguồn tham khảo thành nghĩa vụ pháp lý, không làm mất traceability. Decision: dùng bảng trên làm input register cho section NFR; giữ nguyên ID, filename và URL. Authority: Legal Owner xác minh diễn giải pháp lý; Domain Owner xác minh ngữ cảnh thực phẩm; Architect xác minh kiến trúc; Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì artifact. Artifact: /02-handbook/10-nonfunctional-requirements-and-quality-attributes.md. Consequence if Wrong: NFR có thể gắn sai nguồn, bị hiểu nhầm là yêu cầu production hoặc tuyên bố tuân thủ không có thẩm quyền.

Senior Lens

Một URL chính thức chứng minh nguồn tồn tại và phiên bản được ghi nhận; không tự chứng minh Nova Foods phải áp dụng cấu hình ERP cụ thể. Một artifact IN_REVIEW cho phép truy vết thay đổi; không tạo baseline, approval hoặc quyền dùng production. Cầu nối suy luận phải còn thấy được: nguồn pháp lý cần Legal Owner; chuẩn kỹ thuật cần người chịu trách nhiệm kỹ thuật kiểm tra khả năng áp dụng; dữ liệu mô phỏng chỉ dùng để minh họa.

Quick Reference

Nhãn	Nghĩa dùng trong bảng
IN_REVIEW	Đang xem xét có kiểm soát; không phải APPROVED hoặc BASELINED.
Nguồn chính	Nguồn phát hành chuẩn, luật hoặc đặc tả.
Good practice ngành	Tham chiếu chuyên môn; không tự thành nghĩa vụ pháp lý.
Verification required	Chưa đủ thẩm quyền hoặc bằng chứng để kết luận.
Dữ liệu tổng hợp	Dữ liệu mô phỏng giáo dục; không phải dữ liệu Nova Foods thật.

5. Step-by-step BA Activities

Core

Hoạt động BA cho Nonfunctional Requirements (NFR, yêu cầu phi chức năng) biến nhu cầu chất lượng như hiệu năng, bảo mật, khả dụng thành tiêu chí đo được, kiểm tra được và có người chịu trách nhiệm xác minh. BA không tự kết luận tuân thủ pháp lý, kiến trúc hay bảo mật. BA giữ bằng chứng, nêu điểm chưa rõ, chuyển đúng vai trò có thẩm quyền.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp. Thực hiện theo thứ tự sau trong /02-handbook/10-nonfunctional-requirements-and-quality-attributes.md, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

1. Actor: BA. Action: lập phạm vi đánh giá NFR cho một capability ERP. Object: luồng nghiệp vụ, người dùng, dữ liệu, kênh tích hợp và môi trường giả định. Evidence produced: phạm vi NFR ghi rõ chức năng trong/ngoài phạm vi, ví dụ “ghi nhận đơn bán hàng mô phỏng”. Decision rule: chỉ đưa đối tượng có tác động chất lượng có thể quan sát. Quality gate: phạm vi không gán cấu hình production hoặc quy định Nova Foods thật. Escalation route: phạm vi mơ hồ chuyển Business Owner mô phỏng; ranh giới kiến trúc chuyển Architect.

2. Actor: BA. Action: thu thập bằng chứng nguồn và bối cảnh sử dụng. Object: quy trình hiện tại, lỗi quan sát, volume dữ liệu tổng hợp, URL nguồn chính và assumption dự án. Evidence produced: source register liên kết URL, phân loại nguồn và ngày truy cập 2026-08-07. Decision rule: nguồn pháp lý, kế toán, an toàn thực phẩm chỉ tạo nhãn Verification required khi chưa có xác minh đúng thẩm quyền. Quality gate: không diễn giải URL thành điều khoản, nghĩa vụ hay tuyên bố tuân thủ. Escalation route: Legal Owner, Accounting Owner hoặc Domain Owner xác minh nội dung chuyên môn.

3. Actor: BA cùng stakeholder mô phỏng. Action: chuyển nhu cầu chất lượng thành phát biểu NFR. Object: nhu cầu như “người dùng cần thấy trạng thái lưu đơn đủ nhanh để tiếp tục thao tác”. Evidence produced: câu NFR gồm đối tượng, điều kiện, chỉ số đo, ngưỡng, cách đo và ngoại lệ. Decision rule: không dùng từ mơ hồ như “nhanh”, “an toàn”, “dễ dùng” nếu thiếu thước đo. Quality gate: mỗi NFR phải kiểm tra được bằng quan sát, kiểm thử hoặc review có bằng chứng. Escalation route: chỉ số không khả thi chuyển Architect; tiêu chí kiểm thử không rõ chuyển QA Reviewer.

4. Actor: BA. Action: phân loại và liên kết NFR với nguồn tác động. Object: NFR hiệu năng, bảo mật, khả dụng, khả năng truy vết, khả năng truy cập hoặc tích hợp. Evidence produced: bảng traceability liên kết NFR với capability, nguồn, assumption, rủi ro và vai trò xác minh. Decision rule: một NFR có nhiều nguồn vẫn phải ghi từng nguồn, không gộp thành một kết luận không có bằng chứng. Quality gate: giữ nguyên ID và đường dẫn canonical của nguồn được tham chiếu; không tạo ID mới ngoài registry. Escalation route: xung đột nguồn canonical chuyển Principal IT Business Analyst / Technical Curriculum Author để lập gói vấn đề và chuyển đúng owner.

5. Actor: BA cùng Architect, Security Reviewer hoặc QA Reviewer tùy thuộc tính. Action: đánh giá tính khả thi và khả năng xác minh. Object: ngưỡng đo, phương pháp đo, dữ liệu kiểm thử tổng hợp, phụ thuộc kỹ thuật và rủi ro. Evidence produced: ghi nhận feasible, constrained hoặc Verification required, kèm lý do. Decision rule: không giữ ngưỡng nếu không có cách đo hoặc không xác định môi trường đo. Quality gate: NFR không mâu thuẫn functional requirement, business rule hoặc giới hạn nguồn. Escalation route: mâu thuẫn kiến trúc chuyển Architect; rủi ro bảo mật chuyển Security Reviewer; tranh chấp ưu tiên nghiệp vụ chuyển Business Owner mô phỏng.

6. Actor: BA. Action: chuẩn bị gói review có kiểm soát. Object: danh sách NFR, traceability, evidence register, điểm mở và câu hỏi quyết định. Evidence produced: review pack gắn trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND khi có số tiền. Decision rule: chỉ nêu quyết định khi có authority phù hợp; nếu chưa có, ghi Verification required. Quality gate: không ghi baseline, approval hoặc production-ready. Escalation route: thiếu owner review chuyển Principal IT Business Analyst / Technical Curriculum Author để theo dõi, không tự thay thế thẩm quyền.

7. Actor: BA. Action: bàn giao có kiểm soát cho vai trò tiêu thụ. Object: NFR đã được review, điểm mở, nguồn và giới hạn sử dụng. Evidence produced: handoff record nêu người nhận, artifact nguồn, trạng thái, phiên bản và việc cần xác minh tiếp. Decision rule: bàn giao chỉ hoàn tất khi người nhận có đủ artifact và thấy rõ phần chưa xác minh. Quality gate: handoff không biến nội dung mô phỏng thành yêu cầu production. Escalation route: người nhận thiếu đầu vào hoặc phát hiện sai traceability chuyển lại BA; vấn đề thuộc chuyên môn chuyển owner tương ứng.

Senior Lens

Cầu nối suy luận phải rõ: nhu cầu quan sát được tạo giả thuyết NFR; nguồn và vai trò có thẩm quyền kiểm tra giả thuyết; bằng chứng kiểm tra quyết định NFR có giữ được hay phải gắn Verification required. BA quản trị chất lượng quyết định, không thay Architect quyết định giải pháp, không thay Legal Owner diễn giải luật, không thay QA Reviewer xác nhận kiểm thử.

Quick Reference

Thành phần bắt buộc của mỗi bước	Mục đích
Actor	Xác định ai làm và ai chịu trách nhiệm chuyên môn.
Action và Object	Xác định việc làm trên đối tượng cụ thể.
Evidence produced	Tạo dấu vết kiểm tra được.
Decision rule	Chặn suy đoán hoặc ngôn ngữ mơ hồ.
Quality gate	Chặn đầu ra lỗi trước bước sau.
Escalation route	Chuyển vấn đề vượt thẩm quyền BA.

Core

Mỗi bước BA phải tạo bằng chứng kiểm tra được, không chỉ ghi “đã trao đổi”. Actor là vai trò thực hiện; action là thao tác; object là tài liệu, dữ liệu hoặc yêu cầu đang xử lý; evidence là dấu vết lưu được; decision rule là điều kiện chọn kết quả; quality gate là điểm chặn trước khi sang bước; escalation route là nơi chuyển vấn đề vượt thẩm quyền. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; mọi kết luận pháp lý, kế toán, an toàn thực phẩm hoặc bảo mật cần vai trò có thẩm quyền xác minh.

Bước	Actor	Action	Object	Evidence produced	Decision rule	Quality gate	Escalation route
1. Chuẩn bị phạm vi	BA	Lập danh sách thuộc tính chất lượng cần khảo sát: hiệu năng, sẵn sàng, bảo mật, khả năng dùng, khả năng truy vết.	Phạm vi ERP mô phỏng, stakeholder map, source map.	Bảng phạm vi NFR có ngày 2026-08-07, trạng thái IN_REVIEW, version v0.9.0.	Chỉ nhận thuộc tính có quy trình, người dùng, dữ liệu hoặc tích hợp bị ảnh hưởng xác định được.	Mỗi mục phải chỉ ra nguồn hoặc ghi rõ “project assumption”.	Business Owner khi mục tiêu nghiệp vụ mơ hồ; Architect khi phạm vi chạm kiến trúc.
2. Thu thập bối cảnh	BA	Phỏng vấn, quan sát mô phỏng hoặc đọc artifact nguồn để ghi tình huống sử dụng và thất bại cần tránh.	Luồng đặt hàng, xuất kho, hóa đơn, truy vết lô mô phỏng.	Nhật ký phát hiện gồm nguồn, ngày, người cung cấp, fact và giới hạn suy luận.	Fact chỉ hợp lệ khi truy được nguồn; ý kiến không tự thành requirement.	Không có phát biểu nào bị ghi thành cam kết Nova Foods thực tế.	Business Owner khi xung đột vận hành; Legal/Compliance Owner khi dữ liệu cá nhân hoặc nghĩa vụ pháp lý xuất hiện.
3. Chuyển hóa thành NFR	BA	Viết requirement đo được theo điều kiện, đối tượng, chỉ số, ngưỡng, cách đo và ngoại lệ.	Fact đã xác minh, nhu cầu vận hành.	Bản ghi NFR nháp liên kết source ID hoặc nhãn Verification required.	Requirement phải kiểm thử được; “nhanh”, “an toàn”, “dễ dùng” không đủ.	Có đơn vị đo, phạm vi tải, thời điểm đo và tiêu chí đạt/trượt.	Architect khi ngưỡng ảnh hưởng thiết kế; Security Owner khi có xác thực, phân quyền hoặc dữ liệu nhạy cảm.
4. Phân tích lựa chọn	BA cùng Architect, QA và Business Owner	So sánh phương án đáp ứng NFR theo lợi ích, rủi ro, chi phí và khả năng kiểm thử.	NFR nháp, ràng buộc hệ thống, dữ liệu tải mô phỏng.	Ma trận options và lý do chọn hoặc loại.	Không chọn phương án chỉ vì quen thuộc; chọn phương án đạt tiêu chí bắt buộc và có bằng chứng kiểm thử khả thi.	Mỗi phương án có owner, giả định, tác động và rủi ro còn lại.	Architect cho quyết định kỹ thuật; Business Owner cho đánh đổi giá trị; QA Lead cho khả năng xác minh.
5. Kiểm tra chất lượng	BA và QA	Rà soát tính rõ ràng, nhất quán, truy vết, khả năng kiểm thử và không mâu thuẫn.	Bản ghi NFR, business rule, data dictionary, API hoặc integration note nếu có.	Checklist review và danh sách lỗi có ID.	Không chuyển tiếp nếu thiếu nguồn, thiếu metric, dùng thuật ngữ mơ hồ hoặc mâu thuẫn artifact canonical.	Liên kết giữ nguyên CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY khi áp dụng.	Principal IT Business Analyst / Technical Curriculum Author khi ID hoặc source boundary mâu thuẫn; QA Lead khi test basis thiếu.
6. Handoff có kiểm soát	BA	Gói NFR, giả định, câu hỏi mở, rủi ro và traceability cho consumer phù hợp.	NFR đã qua review nội bộ.	Handoff log: tệp, version, trạng thái, người nhận, mục đích dùng.	IN_REVIEW chỉ cho review; không diễn giải thành baseline, approval hoặc quyền triển khai.	Người nhận xác định được phần cần review và thẩm quyền của mình.	Owner phù hợp khi cần quyết định; không chuyển trách nhiệm phê duyệt sang BA.

Applied

Nova Foods mô phỏng cần NFR cho màn hình xác nhận xuất kho. Facts: luồng dùng dữ liệu tổng hợp, có người vận hành kho và giao dịch xuất hàng; CANONICAL_DATA_DICTIONARY là nguồn canonical cho định nghĩa dữ liệu logic nhưng đang IN_REVIEW. Current Behavior: chưa có ngưỡng thời gian phản hồi hoặc cách đo được ghi nhận. Underlying Need: người vận hành cần biết kết quả xác nhận kịp thời để tránh thao tác lặp. Options: đặt ngưỡng phản hồi cho thao tác thành công; chỉ ghi nhận yêu cầu chung “hệ thống nhanh”. Decision Criteria: đo được, QA kiểm thử được, không tự khẳng định năng lực hạ tầng thực tế. Decision: viết NFR nháp với dữ liệu tải mô phỏng và nhãn project assumption. Authority: Business Owner xác nhận nhu cầu vận hành; Architect xác nhận khả thi kỹ thuật; QA Lead xác nhận phương pháp đo. Artifact: bản ghi NFR liên kết CANONICAL_DATA_DICTIONARY và handoff log. Consequence if Wrong: ngưỡng không thực tế gây thiết kế sai, hoặc ngưỡng mơ hồ khiến QA không kết luận đạt/trượt.

Bước	Thực thi Nova Foods mô phỏng	Evidence	Gate và escalation
1	BA ghi phạm vi: xác nhận xuất kho, người dùng kho, dữ liệu giao dịch tổng hợp.	NFR scope record IN_REVIEW, v0.9.0.	Thiếu actor hoặc sự kiện kích hoạt: hỏi Business Owner.
2	BA tách fact “cần tránh xác nhận lặp” khỏi suy luận “cần phản hồi trong ngưỡng cụ thể”.	Discovery log có nhãn fact và inference.	Không truy được fact về nguồn: giữ là assumption.
3	BA viết: “Trong kiểm thử tải mô phỏng đã xác định, hệ thống phải trả kết quả xác nhận xuất kho trong ngưỡng được Architect và QA Lead xác nhận; đo từ lúc gửi yêu cầu đến lúc nhận phản hồi thành công hoặc lỗi.”	NFR nháp, metric và điểm đo.	Chưa có ngưỡng: không gọi là requirement hoàn chỉnh; escalation Architect và QA Lead.
4	Nhóm so sánh ngưỡng định lượng với câu “phản hồi nhanh”.	Options matrix.	Câu mơ hồ bị loại vì không kiểm thử được.
5	QA kiểm tra có điều kiện tải, điểm đo, kết quả mong đợi và lỗi xử lý.	QA review checklist.	Thiếu một trường: trả BA sửa.
6	BA gửi gói review cho Business Owner, Architect, QA Lead; trạng thái giữ IN_REVIEW.	Handoff log.	Không có approval hoặc baseline được suy diễn từ việc gửi gói.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dữ liệu tổng hợp, IN_REVIEW, v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. BA dùng yêu cầu phi chức năng (Nonfunctional Requirement, NFR) để đo chất lượng vận hành, không mô tả chức năng nghiệp vụ. Ví dụ dưới kiểm tra hiệu năng API tạo đơn bán hàng; API là giao diện để hệ thống trao đổi dữ liệu.

Mục	Thực thi Nova Foods
Facts	Nhân viên bán hàng tạo đơn qua API POST /sales-orders; dữ liệu tổng hợp gồm 50 dòng hàng, tổng giá trị 18.750.000 VND. Môi trường kiểm thử mô phỏng có 100 yêu cầu đồng thời.
Current Behavior	Nhật ký kiểm thử tổng hợp ghi nhận 95/100 phản hồi thành công trong 4 giây; 5 phản hồi vượt 4 giây.
Underlying Need	Người dùng cần nhận kết quả đủ nhanh để tiếp tục nhập đơn; đội kỹ thuật cần ngưỡng đo được để kiểm thử và xử lý suy giảm dịch vụ.
Options	O1: Chấp nhận 4 giây cho mọi phản hồi. O2: Đặt ngưỡng phân vị 95% không quá 3 giây. O3: Đặt ngưỡng trung bình 3 giây.
Decision Criteria	Có thể đo lặp lại; phân biệt trải nghiệm số đông với giá trị trung bình che giấu phản hồi chậm; không tự suy diễn năng lực hạ tầng production.
Decision	Chọn O2: POST /sales-orders phải phản hồi thành công trong không quá 3 giây tại phân vị 95%, với 100 yêu cầu đồng thời trong môi trường kiểm thử mô phỏng. Phân vị 95% nghĩa là ít nhất 95 trên 100 phản hồi không vượt ngưỡng.
Authority	Business Owner xác nhận mức chấp nhận trải nghiệm; Technical Architect xác nhận khả thi kỹ thuật; QA Lead xác nhận phương pháp đo. BA ghi nhận, không tự phê duyệt.
Artifact	Bản ghi NFR mô phỏng: NFR-PERF-001; bằng chứng: báo cáo chạy tải có thời điểm theo Asia/Ho_Chi_Minh, cấu hình dữ liệu tổng hợp, số yêu cầu, phân vị và kết quả.
Consequence if Wrong	Ngưỡng quá lỏng làm chậm thao tác nhưng vẫn bị gọi là đạt. Ngưỡng quá chặt gây chi phí kiến trúc không có bằng chứng nghiệp vụ. Dùng trung bình có thể che 5% phản hồi chậm.
Nguồn và ranh giới	ISTQB CTFL Syllabus v4.0.1 dùng cho thuật ngữ kiểm thử; ISO/IEC/IEEE 29148:2018 dùng cho khái niệm chất lượng yêu cầu. Không suy diễn điều khoản chi tiết từ văn bản cần giấy phép.

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

flowchart TB
    A[BA ghi Facts và Current Behavior]
    B[Business Owner xác nhận mức chấp nhận<br/>Technical Architect xác nhận khả thi<br/>QA Lead xác nhận phương pháp đo<br/>BA ghi nhận phân vị 95%]
    C[Thiết lập POST /sales-orders<br/>50 dòng hàng, 100 yêu cầu đồng thời<br/>môi trường kiểm thử mô phỏng]
    D[QA chạy kiểm thử tải]
    E{Ít nhất 95 trên 100 phản hồi<br/>thành công trong không quá 3 giây?}
    F[Ghi kết quả đạt vào bằng chứng NFR-PERF-001]
    J[Kết quả chỉ xác nhận điều kiện mô phỏng<br/>không xác nhận production, tuân thủ hoặc phê duyệt]
    G[QA phân tích phản hồi chậm<br/>và điều kiện chạy]
    H[QA báo cáo Technical Architect<br/>và Business Owner]
    I{Quyết định xử lý}
    K[Technical Architect điều chỉnh giải pháp]
    L[Business Owner xác nhận lại ngưỡng<br/>Technical Architect xác nhận khả thi<br/>QA Lead xác nhận phương pháp đo<br/>BA ghi nhận]

    A --> B --> C --> D --> E
    E -->|Có| F --> J
    E -->|Không| G --> H --> I
    I -->|Điều chỉnh giải pháp| K --> C
    I -->|Điều chỉnh ngưỡng có căn cứ| L --> C

Bằng chứng dẫn đến quyết định: 5% phản hồi đã vượt 4 giây, nên trung bình không đủ bảo vệ nhóm người dùng bị chậm; phân vị 95% tạo tiêu chí kiểm thử rõ. Kết quả kiểm thử chỉ xác nhận điều kiện mô phỏng, không xác nhận hiệu năng production, tuân thủ hay phê duyệt.

6. Output thu ???c

Core

Output của BA là artifact có kiểm soát: vật chứa quyết định, bằng chứng và liên kết truy vết để người sau không phải đoán lại. Với NFR, tối thiểu tạo hoặc cập nhật ba loại artifact dưới đây. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Artifact	Mục đích	Canonical ID	Owner duy trì	Status hiện hành	Nội dung tối thiểu	Nghĩa vụ lịch sử thay đổi
Bản ghi NFR	Ghi yêu cầu chất lượng đo được	NFR-PERF-001 cho ví dụ hiệu năng; ID khác phải lấy từ TRACEABILITY_ID_REGISTRY	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Thuộc tính chất lượng, phạm vi, chỉ số, ngưỡng, điều kiện đo, nguồn, giả định, authority cần xác nhận	Ghi version, ngày 2026-08-07, người sửa, trường thay đổi, lý do và liên kết artifact bị ảnh hưởng
Liên kết truy vết NFR	Nối NFR với nhu cầu, rule, dữ liệu, thiết kế và kiểm thử	Giữ nguyên NFR-PERF-001; không tạo ID biến thể	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	ID nguồn, ID đích, loại liên kết, lý do liên kết, trạng thái kiểm tra	Mỗi lần thêm, sửa hoặc bỏ liên kết phải ghi lý do; không xóa im lặng
Bằng chứng đánh giá chất lượng dự kiến	Xác định dữ liệu cần có để QA hoặc vai trò chuyên môn kiểm tra NFR	Tham chiếu NFR-PERF-001; không thay thế bản ghi NFR	QA Lead sở hữu phương pháp kiểm tra; BA duy trì liên kết	IN_REVIEW	Cách đo, dữ liệu tổng hợp, môi trường mô phỏng, tiêu chí pass/fail, vai trò chạy kiểm tra	Ghi thay đổi phương pháp đo, điều kiện chạy và lý do để kết quả sau này còn so sánh được

IN_REVIEW nghĩa là nội dung đang được xem xét có kiểm soát. Nó không nghĩa là APPROVED, BASELINED, production-ready, compliant hoặc đã được người dùng chấp thuận.

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

flowchart TB
    A[Nhu cầu nghiệp vụ hoặc risk] --> B[Bản ghi NFR<br/>NFR-PERF-001<br/>Status: IN_REVIEW]

    B --> C[Liên kết truy vết<br/>Giữ nguyên NFR-PERF-001<br/>Status: IN_REVIEW]
    B --> D[Bằng chứng đánh giá chất lượng dự kiến<br/>Tham chiếu NFR-PERF-001<br/>Status: IN_REVIEW]

    B --> BN[Nội dung tối thiểu bản ghi NFR<br/>Thuộc tính chất lượng; phạm vi; chỉ số; ngưỡng;<br/>điều kiện đo; nguồn; giả định;<br/>authority cần xác nhận]

    C -. truy vết tới .-> A
    C --> CN[Trường bắt buộc liên kết<br/>ID nguồn; ID đích; loại liên kết;<br/>lý do liên kết; trạng thái kiểm tra]
    C --> E[Rule]
    C --> F[Dữ liệu]
    C --> G[Thiết kế]
    C --> H[Kiểm thử]

    D --> I[Phương pháp đo<br/>Dữ liệu tổng hợp; môi trường mô phỏng;<br/>tiêu chí pass/fail; vai trò chạy kiểm tra]
    I --> H

    J[Principal IT Business Analyst /<br/>Technical Curriculum Author] -. owner, duy trì .-> B
    J -. owner, duy trì .-> C
    J -. duy trì liên kết .-> D
    K[QA Lead] -. sở hữu .-> I

    LB[Lịch sử thay đổi bản ghi NFR<br/>Version; ngày 2026-08-07; người sửa;<br/>trường thay đổi; lý do;<br/>liên kết artifact bị ảnh hưởng] -. ghi .-> B
    LC[Lịch sử thay đổi liên kết truy vết<br/>Lý do thêm, sửa hoặc bỏ liên kết;<br/>không xóa im lặng] -. ghi .-> C
    LD[Lịch sử thay đổi bằng chứng đánh giá<br/>Thay đổi phương pháp đo, điều kiện chạy<br/>và lý do] -. ghi .-> D

    M[IN_REVIEW<br/>Không phải APPROVED, BASELINED,<br/>production-ready, compliant<br/>hoặc user-accepted] -. giới hạn trạng thái .-> B
    M -. giới hạn trạng thái .-> C
    M -. giới hạn trạng thái .-> D

Applied

Ví dụ Nova Foods mô phỏng dùng NFR-PERF-001. Facts: nhân viên kho cần xác nhận xuất hàng trong giờ cao điểm. Current Behavior: chưa có ngưỡng phản hồi được ghi nhận, nên không thể phân biệt chậm chấp nhận được với lỗi hiệu năng. Underlying Need: biến nhu cầu “nhanh” thành điều kiện đo được. Options: dùng thời gian phản hồi trung bình, dùng phân vị 95%, hoặc chỉ ghi nhận phản hồi cảm nhận. Decision Criteria: tiêu chí phải đo được, tái lập với dữ liệu tổng hợp và không che nhóm phản hồi chậm. Decision: ghi phân vị 95% trong NFR-PERF-001; đây là quyết định học liệu, chưa là yêu cầu vận hành thực. Authority: Business Owner xác nhận giá trị nghiệp vụ, Technical Architect xác nhận khả thi, QA Lead xác nhận phương pháp đo; BA ghi nhận và không tự phê duyệt. Artifact: cập nhật bản ghi NFR-PERF-001, liên kết truy vết và bằng chứng đánh giá dự kiến. Consequence if Wrong: dùng trung bình có thể che phản hồi chậm; thiếu lịch sử thay đổi làm người review không biết ngưỡng đổi vì lý do nào.

Senior Lens

Không dùng tên tệp, ID hoặc trạng thái mới tùy tiện. Evidence: TRACEABILITY_ID_REGISTRY là nguồn quản trị ID canonical; CHAPTER_MANIFEST, TEMPLATE_MANIFEST, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY đều ở IN_REVIEW, v0.9.0, ngày 2026-08-07. Reasoning: output NFR phải giữ cùng cơ chế kiểm soát để liên kết không biến thành nguồn chân lý cạnh tranh.

Mỗi thay đổi phải giữ tối thiểu: version nguồn, ngày theo Asia/Ho_Chi_Minh, người ghi nhận, lý do, phạm vi ảnh hưởng và ID liên quan. Sửa ngưỡng từ 3 giây sang 4 giây mà không ghi lý do sẽ phá truy vết: QA không biết test nào còn phù hợp, Architect không biết giả định nào đã đổi, Business Owner không biết trade-off nào cần xem lại.

Quick Reference

Quy tắc	Áp dụng
Một NFR có một canonical ID	Dùng NFR-PERF-001 nguyên dạng trong mọi liên kết của ví dụ
Một artifact có Owner rõ	Owner duy trì kiểm soát; không tự nhận authority chuyên môn ngoài phạm vi
Status không phải approval	IN_REVIEW chỉ cho phép downstream review có kiểm soát
Lịch sử thay đổi bắt buộc	Không sửa im lặng ID, ngưỡng, nguồn, giả định hoặc liên kết
Dữ liệu Nova Foods là tổng hợp	Không suy diễn cấu hình ERP, nghĩa vụ pháp lý hoặc khả năng production thực tế

Core

Output anatomy là cấu trúc đủ trường để người đọc truy vết: nhu cầu chất lượng nào, áp dụng ở đâu, đo bằng gì, bằng chứng nào kiểm tra được, và giả định nào chưa xác minh. Mỗi dòng phải là một đơn vị kiểm tra được; không gộp hiệu năng, bảo mật và khả năng truy cập vào một câu chung vì mỗi thuộc tính cần cách đo khác nhau.

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

flowchart TB
    Q["Nhu cầu chất lượng"] --> NFR["Yêu cầu NFR kiểm tra được"]
    S["Phạm vi chức năng"] --> NFR
    A["Thuộc tính chất lượng"] --> NFR

    NFR --> O["Phép đo trong phạm vi"]
    L["Tác nhân và tải"] --> O
    T["Điều kiện kích hoạt"] --> O
    O --> M["Chỉ số đo<br/>Đại lượng, ngưỡng, đơn vị, khoảng quan sát"]
    M --> E["Bằng chứng mong đợi<br/>Log, kết quả kiểm thử, báo cáo hoặc cấu hình"]

    NFR --> C["Ràng buộc không được phá vỡ"]
    C --> E

    NFR --> S1["Liên kết nguồn<br/>Artifact canonical, rule hoặc nguồn ngoài"]
    S1 --> S2["Ví dụ nguồn<br/>TRACEABILITY_ID_REGISTRY"]

    NFR --> V["Nhãn xác minh"]
    E --> V
    V --> V1["Fact"]
    V --> V2["Giả định dự án"]
    V --> V3["Cần xác minh"]

Thành phần anatomy	Nội dung bắt buộc	Ví dụ giá trị
Phạm vi chức năng	Quy trình, màn hình, API hoặc báo cáo chịu tác động	Ghi nhận phiếu xuất kho
Thuộc tính chất lượng	Nhóm chất lượng: hiệu năng, bảo mật, khả dụng, truy cập, phục hồi	Hiệu năng
Tác nhân và tải	Ai hoặc hệ thống nào dùng; khối lượng mô phỏng	Nhân viên kho, 50 yêu cầu đồng thời
Điều kiện kích hoạt	Sự kiện bắt đầu phép đo	Người dùng nhấn Lưu phiếu xuất
Chỉ số đo	Đại lượng, ngưỡng, đơn vị, khoảng quan sát	Thời gian phản hồi p95 không quá 3 giây
Ràng buộc	Điều kiện không được phá vỡ khi đạt chỉ số	Không tạo hai chứng từ cùng một mã
Bằng chứng mong đợi	Log, kết quả kiểm thử, báo cáo giám sát hoặc cấu hình cần đối chiếu	Báo cáo kiểm thử tải có p95 và tỷ lệ lỗi
Liên kết nguồn	Artifact canonical, rule hoặc nguồn ngoài làm căn cứ	CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY
Nhãn xác minh	Phân biệt fact, giả định dự án và điểm cần xác minh	Project assumption

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi số liệu dưới đây là dữ liệu tổng hợp, không mô tả ERP thật hay cam kết vận hành thật.

Mục	Nội dung điền mẫu
Facts	Kho mô phỏng có nhân viên lập phiếu xuất cho đơn bán. Dữ liệu tổng hợp giả định 50 nhân viên gửi yêu cầu cùng lúc trong giờ cao điểm.
Current Behavior	Chưa có số đo phản hồi, chưa có tiêu chí tỷ lệ lỗi, chưa có bằng chứng kiểm thử tải. Suy luận: không thể kết luận hệ thống đáp ứng nhu cầu giờ cao điểm khi chưa có chỉ số và bằng chứng.
Underlying Need	Nhân viên kho cần hoàn tất ghi nhận xuất hàng kịp thời để chứng từ mô phỏng không bị chậm so với hoạt động giao hàng.
Options	Đặt ngưỡng thời gian phản hồi trung bình; đặt ngưỡng p95; chỉ yêu cầu hệ thống “nhanh”.
Decision Criteria	Tiêu chí phải đo được, tái lập bằng kiểm thử, phản ánh người dùng chậm hơn thường gặp, và không tự suy diễn cấu hình hạ tầng.
Decision	Dùng p95 không quá 3 giây cho thao tác lưu phiếu xuất với 50 yêu cầu đồng thời; tỷ lệ yêu cầu lỗi không quá 1% trong phiên kiểm thử tải. Đây là project assumption, cần Business Owner và Architect xác minh trước khi dùng làm mục tiêu dự án.
Authority	Business Owner xác nhận mức phục vụ nghiệp vụ; Architect xác nhận khả thi kỹ thuật; QA xác nhận phương pháp đo. Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì truy vết học liệu.
Artifact	Bản ghi NFR mô phỏng liên kết TRACEABILITY_ID_REGISTRY và CANONICAL_DATA_DICTIONARY.
Consequence if Wrong	Ngưỡng quá lỏng có thể làm chậm thao tác kho; ngưỡng quá chặt có thể gây chi phí kỹ thuật không cần thiết hoặc làm sai ưu tiên dự án.

Trường bản ghi NFR mô phỏng	Giá trị đã điền
Nhãn bản ghi	Hiệu năng ghi nhận phiếu xuất kho
Phạm vi	Chức năng lưu phiếu xuất kho trong Nova Foods ERP mô phỏng
Tác nhân	Nhân viên kho
Sự kiện	Người dùng gửi yêu cầu lưu phiếu xuất hợp lệ
Tải mô phỏng	50 yêu cầu đồng thời
Chỉ số chính	Thời gian phản hồi p95
Ngưỡng	Không quá 3 giây
Chỉ số lỗi	Tỷ lệ yêu cầu lỗi trong phiên kiểm thử tải
Ngưỡng lỗi	Không quá 1%
Ràng buộc toàn vẹn	Không được tạo hai chứng từ từ cùng một yêu cầu lưu
Bằng chứng cần có	Kết quả kiểm thử tải, log thời gian phản hồi, số lượng yêu cầu thành công và lỗi
Liên kết dữ liệu	CANONICAL_DATA_DICTIONARY
Liên kết truy vết	TRACEABILITY_ID_REGISTRY
Nguồn phân loại	Project assumption; không phải quy định pháp lý, kế toán, thuế, an toàn thực phẩm hoặc cấu hình production
Dữ liệu case	Synthetic data only; vi-VN, Asia/Ho_Chi_Minh, VND

Senior Lens

“p95” nghĩa là 95% mẫu đo không vượt ngưỡng; chỉ nhìn trung bình có thể che giấu nhóm giao dịch chậm. Ví dụ trung bình 1 giây vẫn có thể chứa nhiều yêu cầu 8 giây. Vì nhân viên kho trải nghiệm từng thao tác, p95 tạo bằng chứng sát trải nghiệm hơn trung bình.

Không biến yêu cầu chất lượng thành thiết kế sớm. Câu “dùng Redis”, “dùng ba máy chủ”, hoặc “dùng API gateway” là lựa chọn kiến trúc, không phải NFR. NFR nêu kết quả đo; Architect chọn cách đạt kết quả sau.

Quick Reference

Kiểm tra anatomy	Đạt khi
Có phạm vi	Nêu rõ chức năng hoặc giao dịch chịu tác động
Có phép đo	Có chỉ số, đơn vị, tải và ngưỡng
Có ràng buộc	Nêu điều không được phá vỡ khi tối ưu chất lượng
Có bằng chứng	QA hoặc reviewer biết cần xem log, báo cáo hay kết quả nào
Có truy vết	Liên kết đúng TRACEABILITY_ID_REGISTRY và artifact liên quan
Có nhãn giả định	Không diễn đạt dữ liệu mô phỏng hay điểm chưa xác minh như fact hoặc nghĩa vụ bắt buộc

Core

Quality gate là cổng kiểm tra chất lượng trước khi artifact được chuyển sang downstream review, tức review bởi vai trò dùng artifact ở bước sau. Gate xác nhận artifact đủ rõ, đủ truy vết, đủ kiểm tra; không xác nhận nội dung đúng tuyệt đối, không tạo approval, baseline, compliance hoặc production readiness. Với Nova Foods Trading & Manufacturing mô phỏng, mọi dữ liệu là tổng hợp.

Điều kiện gate	Bằng chứng phải có	Kết quả nếu thiếu
Nhận diện kiểm soát	Đúng Artifact ID, đường dẫn canonical, IN_REVIEW, v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh	Không chuyển review; reviewer không biết bản nào đang xem
Truy vết nguồn	Mỗi yêu cầu chất lượng liên kết nguồn hoặc ghi rõ project assumption hay Verification required	Không chuyển review; kết luận dễ bị hiểu là nghĩa vụ đã xác minh
Tính kiểm tra được	Có thước đo, ngưỡng, đối tượng đo, điều kiện đo và cách quan sát kết quả	Không chuyển review; QA hoặc Architect không thể đánh giá
Ranh giới thẩm quyền	Nội dung pháp lý, kế toán, bảo mật, kiến trúc được gắn vai trò xác minh tương ứng	Không chuyển review như kết luận chuyên môn
Lịch sử thay đổi	Có dòng change history nêu thay đổi, lý do, ngày, người ghi nhận	Không chuyển review; thay đổi không truy nguyên được
Nhất quán nội bộ	Không mâu thuẫn với CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY	Dừng; cần làm rõ nguồn canonical

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

flowchart TB
    A["Artifact IN_REVIEW"] --> B{"Nhận diện đủ?<br/>Artifact ID · đường dẫn canonical · IN_REVIEW<br/>v0.9.0 · 2026-08-07 · Asia/Ho_Chi_Minh"}
    B -- "Không" --> B1["Không chuyển review<br/>Reviewer không biết bản nào đang xem"]
    B -- "Có" --> C{"Có lịch sử thay đổi?<br/>Thay đổi · lý do · ngày · người ghi nhận"}
    C -- "Không" --> C1["Không chuyển review<br/>Thay đổi không truy nguyên được"]
    C -- "Có" --> D{"Mỗi yêu cầu có truy vết nguồn?<br/>Nguồn · project assumption<br/>hoặc Verification required"}
    D -- "Không" --> D1["Không chuyển review<br/>Kết luận dễ bị hiểu là nghĩa vụ đã xác minh"]
    D -- "Có" --> E{"Yêu cầu kiểm tra được?<br/>Thước đo · ngưỡng · đối tượng · điều kiện<br/>và cách quan sát kết quả"}
    E -- "Không" --> E1["Không chuyển review<br/>QA hoặc Architect không thể đánh giá"]
    E -- "Có" --> F{"Đúng ranh giới thẩm quyền?<br/>Có vai trò xác minh nội dung pháp lý,<br/>kế toán, bảo mật, kiến trúc"}
    F -- "Không" --> F1["Không chuyển review<br/>như kết luận chuyên môn"]
    F -- "Có" --> G{"Nhất quán với nguồn canonical?<br/>CHAPTER_MANIFEST · TRACEABILITY_ID_REGISTRY<br/>CANONICAL_BUSINESS_RULES<br/>CANONICAL_DATA_DICTIONARY"}
    G -- "Không" --> G1["Dừng<br/>Cần làm rõ nguồn canonical"]
    G -- "Có" --> H["Ready for downstream review"]

    B1 --> R["Trả về cập nhật có truy vết"]
    C1 --> R
    D1 --> R
    E1 --> R
    F1 --> R

    N["Ranh giới quality gate<br/>Không xác nhận nội dung đúng tuyệt đối<br/>Không tạo approval, baseline, compliance<br/>hoặc production readiness"]:::constraint
    M["Ranh giới dữ liệu<br/>Nova Foods Trading & Manufacturing là mô phỏng<br/>Mọi dữ liệu là tổng hợp"]:::constraint

    N -.- H
    M -.- A

    classDef constraint fill:#fff7e6,stroke:#9a6700,stroke-dasharray:5 5,color:#3d2b00;

Applied

Facts: Nova Foods mô phỏng cần yêu cầu hiệu năng cho màn hình tra cứu lô hàng; dữ liệu chỉ là tổng hợp. Current Behavior: draft có câu “Màn hình phải nhanh”, không có ngưỡng đo hay điều kiện tải. Underlying Need: QA và Architect cần biết cách kiểm tra cùng một kết quả. Options: giữ câu mô tả; hoặc bổ sung tiêu chí đo được. Decision Criteria: tiêu chí phải đo được, có bối cảnh, không tự khẳng định năng lực production. Decision: chỉ cho downstream review khi draft ghi “Trong dữ liệu mô phỏng, tra cứu một lô hàng trả kết quả trong không quá 3 giây, đo từ lúc người dùng gửi tìm kiếm đến lúc danh sách hiển thị, với 100 yêu cầu tuần tự.” Authority: Architect và QA reviewer xác minh khả năng kỹ thuật và cách đo; Business Owner xác minh giá trị nghiệp vụ; không vai trò nào được suy diễn approval từ gate. Artifact: nội dung được ghi trong artifact NFR đang IN_REVIEW, v0.9.0, kèm nguồn hoặc nhãn project assumption, change history ngày 2026-08-07. Consequence if Wrong: ngưỡng mơ hồ làm QA đo khác nhau; ngưỡng bị diễn giải như cam kết production gây quyết định sai.

Senior Lens

Gate tốt kiểm tra khả năng review, không kiểm tra kết quả review. Bằng chứng là IN_REVIEW chỉ mô tả trạng thái xem xét; các dependency governance đều nêu trạng thái này không phải APPROVED, BASELINED, compliant hay production-ready. Vì vậy câu kết luận hợp lệ là “sẵn sàng để downstream review”, không phải “đã được chấp thuận” hoặc “sẵn sàng production”.

Nếu yêu cầu dẫn chiếu Luật Bảo vệ dữ liệu cá nhân, Luật Kế toán, Luật An toàn thực phẩm, Nghị định 123/2020/NĐ-CP hoặc Nghị định 356/2025/NĐ-CP, gate phải giữ Verification required cho đến khi Legal Owner, Accounting Owner hoặc domain owner có thẩm quyền xác minh. Nguồn luật tạo nhu cầu kiểm tra, không tự biến draft học liệu thành kết luận pháp lý.

Quick Reference

Gate outcome	Nghĩa chính xác	Không có nghĩa
Ready for downstream review	Artifact đủ bằng chứng để reviewer bắt đầu đánh giá	Đã phê duyệt, đã baseline, đúng nghiệp vụ, compliant, production-ready
Return for update	Thiếu thông tin hoặc truy vết cần bổ sung	Artifact bị từ chối vĩnh viễn
Escalate	Cần vai trò có thẩm quyền quyết định hoặc xác minh	BA được phép tự kết luận thay vai trò đó

7. Who consumes those outputs?

Core

Đầu ra của phân tích yêu cầu phi chức năng (Nonfunctional Requirements, NFR) không chỉ để “tham khảo”. Mỗi vai trò dùng một phần đầu ra để ra quyết định khác nhau. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi ví dụ và dữ liệu đều tổng hợp, trạng thái artifact là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Consumer	Đầu ra họ dùng	Cách dùng trong công việc
Developers	NFR đo được, acceptance criteria, giới hạn lỗi, yêu cầu tích hợp	Chuyển yêu cầu thành thiết kế kỹ thuật, cấu hình, mã nguồn và xử lý lỗi. Ví dụ: giới hạn phản hồi màn hình tra cứu lô hàng quyết định cách phân trang, lập chỉ mục dữ liệu hoặc gọi API.
QA	NFR đo được, tiêu chí chấp nhận, dữ liệu kiểm thử, traceability	Tạo test basis, tức cơ sở để thiết kế kiểm thử. QA đo kết quả thực tế so với ngưỡng đã ghi, không tự đổi ngưỡng theo cách hiểu cá nhân.
Architect	NFR ưu tiên, ràng buộc bảo mật, hiệu năng, khả dụng, tích hợp	Chọn hoặc đánh giá kiến trúc. Ví dụ: yêu cầu truy vết lô hàng xuyên kho ảnh hưởng thiết kế dữ liệu, API và cơ chế lưu audit log.
PM/Product Owner	NFR, mức ưu tiên, phạm vi ảnh hưởng, dependency	Cân bằng phạm vi, thời gian, chi phí và giá trị sản phẩm. Product Owner dùng NFR để sắp thứ tự backlog; PM dùng để nhận diện rủi ro delivery.
Business Owner	Mục tiêu chất lượng, tác động nghiệp vụ, tiêu chí chấp nhận nghiệp vụ	Đánh giá liệu mức chất lượng dự kiến còn bảo vệ được hoạt động bán hàng, sản xuất, kho hay không. Không dùng tài liệu NFR để tự xác nhận thiết kế kỹ thuật.
Operations	Yêu cầu khả dụng, giám sát, sao lưu, khôi phục, hỗ trợ sự cố	Chuẩn bị vận hành hệ thống: dashboard, cảnh báo, runbook và cách xử lý khi dịch vụ suy giảm.
Specialist owners	NFR thuộc chuyên môn: Security, Legal, Accounting, Food-safety, Accessibility	Rà soát phần thuộc thẩm quyền chuyên môn. Ví dụ: Security review kiểm soát truy cập; Legal Owner xác minh yêu cầu có liên hệ Luật Bảo vệ dữ liệu cá nhân; Accessibility specialist đối chiếu WCAG 2.2 khi phạm vi giao diện cần tiếp cận.

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

flowchart TB
    NFR["Artifact NFR<br/>NFR đo được · acceptance criteria · giới hạn lỗi · tích hợp<br/>Trạng thái: IN_REVIEW"]

    NFR -. "dùng để ra quyết định; không phải bàn giao hay phê duyệt" .-> DEV["Developers<br/>Thiết kế kỹ thuật, cấu hình, mã nguồn, xử lý lỗi"]
    NFR -.-> QA["QA<br/>Tạo test basis; đo kết quả so với ngưỡng đã ghi"]
    NFR -.-> ARC["Architect<br/>Chọn hoặc đánh giá kiến trúc"]
    NFR -.-> PO["PM/Product Owner<br/>Ưu tiên backlog; nhận diện rủi ro delivery"]
    NFR -.-> BO["Business Owner<br/>Đánh giá mức chất lượng bảo vệ hoạt động nghiệp vụ"]
    NFR -.-> OPS["Operations<br/>Chuẩn bị dashboard, cảnh báo, runbook, xử lý suy giảm"]
    NFR -.-> SPO["Specialist owners<br/>Rà soát phần thuộc thẩm quyền chuyên môn"]

    BO --- BOUNDARY["Ranh giới<br/>Không tự xác nhận thiết kế kỹ thuật"]
    QA --- BOUNDARY2["Ranh giới<br/>Không tự đổi ngưỡng theo cách hiểu cá nhân"]

Sơ đồ không thể hiện chuỗi phê duyệt. Lý do: cùng một artifact có thể được nhiều vai trò đọc, nhưng việc đọc hoặc review không tạo approval. IN_REVIEW chỉ cho biết nội dung đang được xem xét có kiểm soát.

Applied

Output NFR mô phỏng	Consumer chính	Cách tiêu thụ cụ thể
Yêu cầu thời gian phản hồi cho tra cứu tồn kho	Developers, QA, Architect	Developers xác định điểm cần tối ưu; QA tạo kiểm thử tải; Architect kiểm tra liệu thiết kế API và dữ liệu chịu được tải dự kiến.
Yêu cầu audit log cho điều chỉnh tồn kho	Developers, QA, Operations, Security owner	Developers ghi nhận sự kiện; QA kiểm tra sự kiện được tạo; Operations theo dõi log; Security owner rà soát quyền truy cập log.
Yêu cầu khôi phục sau lỗi dịch vụ	Architect, Operations, PM	Architect đánh giá phương án phục hồi; Operations chuẩn bị runbook; PM đánh giá ảnh hưởng lịch triển khai và nguồn lực.
Yêu cầu giao diện dễ tiếp cận	Developers, QA, Accessibility specialist, Product Owner	Developers xây giao diện; QA kiểm tra tiêu chí; specialist rà soát theo WCAG 2.2 khi áp dụng; Product Owner cân bằng ưu tiên trải nghiệm và phạm vi.
Yêu cầu bảo vệ dữ liệu cá nhân	Architect, Developers, Security owner, Legal Owner	Architect xác định điểm xử lý dữ liệu; Developers áp dụng kiểm soát đã được quyết định; Security owner đánh giá kiểm soát; Legal Owner xác minh diễn giải pháp lý.

Senior Lens

Một output tốt phải nói rõ ai dùng nó để làm gì. Nếu NFR chỉ ghi “hệ thống phải nhanh”, Developers không biết tối ưu phần nào, QA không có ngưỡng để đo, Architect không biết tải nào cần thiết kế, PM không biết chi phí đổi phạm vi. Vì vậy BA nối mỗi yêu cầu với consumer và hành động downstream.

Không gom tất cả consumer thành “team kỹ thuật”. Nhóm này có mục tiêu khác nhau: Developers cần điều kiện xây dựng; QA cần điều kiện kiểm chứng; Architect cần ràng buộc hệ thống; Operations cần điều kiện vận hành; specialist owner cần phạm vi để rà soát chuyên môn. Cùng một yêu cầu “lưu audit log” có thể đúng về kỹ thuật nhưng vẫn chưa đủ cho Operations nếu thiếu thông tin cần giám sát.

Các nguồn như OWASP ASVS 5.0.0, OWASP API Security Top 10 2023 và WCAG 2.2 hỗ trợ nhận diện nội dung cần rà soát. Chúng không tự tạo nghĩa vụ pháp lý cho Nova Foods mô phỏng. Bất kỳ yêu cầu nào suy ra từ luật, kế toán, hóa đơn, an toàn thực phẩm hoặc dữ liệu cá nhân vẫn cần nhãn Verification required hoặc project assumption cho đến khi owner có thẩm quyền xác minh.

Quick Reference

Khi output nói về	Consumer phải nhận bản phù hợp
Hiệu năng, tải, độ trễ	Developers, QA, Architect, PM/Product Owner
Bảo mật, phân quyền, API, log	Developers, QA, Architect, Operations, Security owner
Khả dụng, sao lưu, khôi phục	Architect, Operations, QA, PM
Quy tắc nghiệp vụ ảnh hưởng chất lượng dịch vụ	Business Owner, Product Owner, Developers, QA
Dữ liệu cá nhân, kế toán, hóa đơn, truy xuất thực phẩm	Specialist owner có thẩm quyền, Business Owner, Architect, QA; giữ Verification required khi chưa xác minh

Core

Mỗi output NFR (Nonfunctional Requirement, yêu cầu phi chức năng) chỉ hữu ích khi người nhận biết ba ranh giới: quyết định được phép đưa ra, bằng chứng cần kiểm tra, điểm phải chuyển cấp. Nova Foods là case mô phỏng, chỉ dùng dữ liệu tổng hợp. Mọi artifact còn IN_REVIEW, v0.9.0, ngày 2026-08-07, chưa là baseline hay phê duyệt.

Consumer	Có thể quyết định	Bằng chứng cần có	Phải escalation khi
Developers	Cách hiện thực trong ranh giới NFR đã rõ; chọn cơ chế retry, timeout, validation, logging phù hợp kiến trúc được định	Requirement đo được; acceptance criteria; API contract; data classification; giới hạn hiệu năng	NFR mâu thuẫn API, schema, quyền truy cập, chi phí hoặc cần đổi kiến trúc
QA	Test basis; test case; dữ liệu test tổng hợp; ngưỡng pass/fail theo requirement	Requirement có metric, điều kiện tải, môi trường, expected result, traceability	Không có ngưỡng đo; môi trường test không đại diện; lỗi ảnh hưởng an toàn, bảo mật, dữ liệu hoặc pháp lý
Architect	Tính khả thi kỹ thuật; pattern tích hợp; capacity; ranh giới service và dữ liệu	NFR ưu tiên; volume giả định; integration diagram; dependency; rủi ro kỹ thuật	Trade-off làm đổi mục tiêu nghiệp vụ, ngân sách, compliance hoặc ownership
PM/Product Owner	Ưu tiên backlog; phạm vi release; chấp nhận trade-off thời gian, chi phí, giá trị	Impact analysis; estimate; risk; dependency; tiêu chí release	Trade-off làm giảm nghĩa vụ pháp lý, bảo mật, an toàn thực phẩm, độ đúng kế toán hoặc cam kết nghiệp vụ
Business Owner	Mức dịch vụ nghiệp vụ cần thiết; mức gián đoạn chấp nhận được; ưu tiên outcome	Quy trình nghiệp vụ; thiệt hại khi gián đoạn; peak period; acceptance criteria	Quyết định cần diễn giải pháp lý, kế toán, thuế, an toàn thực phẩm hoặc vượt ngân sách được giao
Operations	Monitoring, alert threshold, runbook, backup/restore rehearsal và lịch vận hành	SLO/SLI nếu đã xác định; log mẫu; alert rule; recovery objective; operational dependency	Không đạt khả năng phục hồi; thiếu quyền vận hành; alert tạo rủi ro bỏ sót hoặc quá tải
Specialist owner: Security	Control bảo mật, threat treatment, verification approach	Data classification; trust boundary; access model; OWASP ASVS hoặc OWASP API Security Top 10 tham chiếu phù hợp	Có dữ liệu cá nhân, lỗ hổng nghiêm trọng, thay đổi quyền, secret, encryption hoặc nghĩa vụ pháp lý
Specialist owner: Legal/Privacy	Diễn giải nghĩa vụ pháp lý và privacy requirement	Loại dữ liệu; mục đích xử lý; lưu trữ; chia sẻ; nguồn luật chính thức	Requirement được trình bày như nghĩa vụ pháp lý nhưng chưa có xác nhận Legal/Privacy
Specialist owner: Accounting/Food Safety	Rule liên quan chứng từ, số liệu, truy xuất hoặc thu hồi	Business rule; data lineage; nguồn luật hoặc quy trình được ủy quyền	Rule ảnh hưởng sổ sách, hóa đơn, traceability hoặc recall; cần thẩm quyền chuyên môn

Applied

Facts: Nova Foods mô phỏng có NFR: màn hình tạo đơn bán hàng phải phản hồi trong 3 giây tại tải giả định 100 người dùng đồng thời; lỗi tích hợp tồn kho phải được ghi log có correlation ID; dữ liệu khách hàng không được hiện đầy đủ cho vai trò không có quyền.

Current Behavior: BA ghi ba câu trên trong artifact NFR nhưng chưa nêu môi trường đo, percentile, mẫu tải, retention log hoặc ma trận quyền.

Underlying Need: Developer không thể biết tối ưu phần nào; QA không có điều kiện pass/fail; Operations không biết alert nào cần cấu hình; Security owner không thể đánh giá mức lộ dữ liệu.

Options:
1. Giữ requirement hiện tại.
2. BA bổ sung giả định kỹ thuật tự quyết.
3. Tách điểm thiếu thành decision log và chuyển đúng owner.

Decision Criteria: Requirement phải đo được; bằng chứng phải tái lập; quyết định không vượt thẩm quyền BA; giả định pháp lý, bảo mật, kế toán và an toàn thực phẩm phải giữ nhãn Verification required khi chưa được owner xác nhận.

Decision: Chọn phương án 3. BA ghi rõ: “3 giây” cần điều kiện đo; “100 người dùng” là tải giả định; “không hiện đầy đủ” cần ma trận quyền và quy tắc masking; retention log chưa được quyết định.

Authority: Architect xác nhận môi trường và metric hiệu năng. QA xác nhận cách đo pass/fail. Operations xác nhận log và alert khả thi. Security owner xác nhận masking, access control và retention. PM/Product Owner ưu tiên phạm vi nếu chi phí tăng.

Artifact: NFR specification liên kết decision log, acceptance criteria và traceability đến CANONICAL_DATA_DICTIONARY khi trường dữ liệu được xác định. Không tự tạo canonical ID mới.

Consequence if Wrong: QA có thể pass hệ thống trong môi trường nhẹ nhưng production-like load thất bại. Log có thể thiếu dữ liệu điều tra. Màn hình có thể lộ dữ liệu khách hàng ngoài quyền cho phép.

Senior Lens

Bằng chứng không phải ý kiến vai trò. “Developer thấy nhanh” không chứng minh hiệu năng; cần số đo, môi trường, tải và ngưỡng. “Business muốn an toàn” không chứng minh control bảo mật; cần phân loại dữ liệu, threat boundary và xác nhận Security owner. Khi một NFR chạm nhiều owner, BA không chọn thay. BA giữ câu hỏi, nguồn, giả định, tác động và người có thẩm quyền trong cùng traceability chain.

Escalation cần chứa đủ gói quyết định: NFR đang tranh chấp, artifact nguồn, dữ liệu tổng hợp dùng minh họa, lựa chọn, tác động mỗi lựa chọn, bằng chứng còn thiếu, owner cần quyết định. Escalation không phải chuyển trách nhiệm mơ hồ.

Quick Reference

Dấu hiệu	Hành động
Có metric nhưng thiếu điều kiện đo	Chuyển Architect và QA xác định test basis
Có yêu cầu privacy hoặc security	Chuyển Security owner; chuyển Legal/Privacy owner nếu có nghĩa vụ pháp lý
Có ảnh hưởng hóa đơn, sổ sách hoặc số liệu tài chính	Chuyển Accounting owner; không tự diễn giải Luật Kế toán hoặc Nghị định 123/2020/NĐ-CP
Có traceability, recall hoặc an toàn thực phẩm	Chuyển Food Safety/domain owner; giữ Verification required nếu nguồn chưa được xác nhận
Trade-off đổi scope, cost hoặc release	Chuyển PM/Product Owner và Business Owner
Requirement không thể test lặp lại	Không đánh dấu ready for QA; bổ sung evidence và acceptance criteria

Core

Handoff là chuyển artifact từ người tạo sang người dùng. Sai không nằm ở việc “đã gửi tệp”, mà ở việc người nhận suy diễn phần chưa được ghi. Với Nova Foods Trading & Manufacturing mô phỏng, mọi dữ liệu là tổng hợp; artifact trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07 không phải baseline hay phê duyệt.

Applied

Mục	Nội dung
Facts	NFR ghi: “ERP phải phản hồi nhanh khi tạo đơn bán hàng.” Không có ngưỡng thời gian, số người dùng đồng thời, điểm bắt đầu/kết thúc đo, môi trường đo, hay loại đơn hàng.
Current Behavior	Developer hiểu “nhanh” là dưới 3 giây ở giao diện. QA đo API dưới 3 giây. Operations giả định giờ cao điểm cuối tháng. Ba cách hiểu khác nhau vì artifact không định nghĩa phép đo.
Underlying Need	Cần biến cảm nhận “nhanh” thành tiêu chí kiểm chứng được: giao dịch nào, phân vị nào, tải nào, điểm đo nào, và ngoại lệ nào.
Options	Giữ mô tả định tính; hỏi làm rõ trước khi thiết kế; tự chọn ngưỡng kỹ thuật.
Decision Criteria	Chọn phương án giữ được nhu cầu nghiệp vụ, tạo được test basis, không tự tạo quyết định hiệu năng, và truy được nguồn xác nhận.
Decision	Hỏi làm rõ trước. Không để Developer hoặc QA tự chọn ngưỡng.
Authority	Business Owner xác nhận mức phục vụ nghiệp vụ; PM/Product Owner xác nhận ưu tiên/phạm vi; Architect xác nhận khả thi kỹ thuật; QA xác nhận đo được; Operations xác nhận cửa sổ tải vận hành.
Artifact	Ghi câu hỏi và câu trả lời có thẩm quyền vào artifact NFR cùng liên kết tới /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Không đổi trạng thái thành baseline.
Consequence if Wrong	Có thể giao hệ thống “đạt” theo API nhưng người dùng vẫn chờ lâu trên giao diện; hoặc thiết kế quá mức cho tải không có bằng chứng.

Các hiểu nhầm thường gặp và câu hỏi phải ghi nguyên nghĩa:

Hiểu nhầm khi bàn giao	Vì sao sai	Câu hỏi làm rõ chính xác
“99,9% availability” nghĩa là hệ thống không được dừng	Availability là tỷ lệ trong khoảng thời gian xác định; không tự nói rõ giờ tính, thành phần tính, hay bảo trì có loại trừ không.	“Tỷ lệ 99,9% được đo cho thành phần nào, trong khoảng thời gian nào, theo múi giờ Asia/Ho_Chi_Minh, và cửa sổ bảo trì có được loại trừ không?”
“Chỉ Finance xem được giá vốn” nghĩa là kiểm tra quyền ở giao diện đủ	Ẩn giao diện không chứng minh API, xuất dữ liệu, báo cáo, hay quyền quản trị bị chặn.	“Yêu cầu hạn chế giá vốn áp dụng cho giao diện, API, báo cáo, tệp xuất, tích hợp và tài khoản quản trị nào?”
“Đồng bộ tồn kho thời gian thực” nghĩa là gọi API đồng bộ	“Thời gian thực” có thể là đồng bộ tức thời, gần thời gian thực, hay theo lô; lựa chọn kiến trúc khác nhau.	“Độ trễ tối đa chấp nhận được từ khi thay đổi tồn kho đến khi kênh nhận hiển thị thay đổi là bao lâu, đo từ sự kiện nào đến sự kiện nào?”
“Dữ liệu phải lưu 10 năm” nghĩa là đội kỹ thuật tự cấu hình xóa sau 10 năm	Thời hạn, phạm vi dữ liệu, điểm bắt đầu tính và căn cứ pháp lý chưa được xác nhận.	“Đây là project assumption hay yêu cầu đã được Legal Owner và Accounting Owner xác minh; dữ liệu nào thuộc phạm vi, thời điểm bắt đầu tính là gì, và có hold ngăn xóa không?”
“Hệ thống phải an toàn” nghĩa là dùng đăng nhập mật khẩu	“An toàn” không xác định rủi ro, dữ liệu, đối tượng tấn công, hay tiêu chí kiểm chứng.	“Loại dữ liệu nào cần bảo vệ, rủi ro nào cần giảm, và Security Owner yêu cầu bằng chứng kiểm chứng nào theo OWASP ASVS 5.0.0?”

Senior Lens

Không thay câu hỏi bằng giả định kỹ thuật. Cụm từ mơ hồ như “nhanh”, “an toàn”, “dễ dùng”, “ổn định”, “thời gian thực” chỉ là tín hiệu cần làm rõ, chưa là NFR kiểm thử được. Bằng chứng nối suy luận là: nếu hai vai trò có thể đo khác nhau từ cùng câu, requirement chưa đủ làm nguồn kiểm thử hay thiết kế.

Nếu câu trả lời đụng pháp lý, kế toán, thuế, an toàn thực phẩm, bảo mật, kiến trúc hoặc vận hành, ghi Verification required và chuyển đúng specialist owner. BA duy trì câu hỏi, nguồn, phiên bản và traceability; BA không thay thẩm quyền kết luận.

Quick Reference

• Handoff tốt: người nhận biết phải xây hoặc kiểm thử gì, đo ở đâu, và ai xác nhận phần còn mở.
• Handoff lỗi: artifact dùng tính từ không có phép đo, phạm vi, ngoại lệ, hoặc nguồn quyết định.
• Câu hỏi tốt: chỉ rõ đối tượng, điều kiện, đơn vị đo, điểm đo, owner và bằng chứng cần nhận.
• Không coi IN_REVIEW trong /02-handbook/10-nonfunctional-requirements-and-quality-attributes.md là đủ quyền để chốt yêu cầu Nova Foods mô phỏng.

8. Detailed Worked Example

Core

Ví dụ này dùng Nova Foods Trading & Manufacturing, doanh nghiệp mô phỏng giáo dục, dữ liệu tổng hợp. NFR (Nonfunctional Requirement, yêu cầu phi chức năng) mô tả chất lượng hệ thống như hiệu năng, bảo mật, khả dụng; không mô tả chức năng nghiệp vụ như “tạo đơn hàng”. Trước khi viết NFR, BA phải tách sự kiện quan sát được khỏi suy đoán về nguyên nhân.

Applied

Phạm vi tình huống: nhân viên kinh doanh tạo Sales Order trên Nova Foods ERP tại giờ chốt đơn ngày 2026-08-07, múi giờ Asia/Ho_Chi_Minh. Đây là facts và current behavior; chưa là quyết định thiết kế, yêu cầu được phê duyệt, hay cam kết production.

Trường	Giá trị mô phỏng
Tổ chức	Nova Foods Trading & Manufacturing — mô phỏng giáo dục
Locale và tiền tệ	vi-VN; VND
Kênh sử dụng	Web ERP nội bộ qua trình duyệt desktop
Vai trò	Sales Executive
Chức năng đang quan sát	Tạo Sales Order, kiểm tra tồn kho khả dụng, tính giá bán
Thời gian quan sát	16:45–17:15 ngày 2026-08-07, Asia/Ho_Chi_Minh
Phân loại nguồn	Dữ liệu quan sát mô phỏng và dữ liệu giao dịch tổng hợp; không phải log production
Status corpus	IN_REVIEW
Version corpus	v0.9.0

Facts — sự thật đã ghi nhận. Trong khoảng quan sát, có 30 Sales Executive đang mở màn hình tạo Sales Order. Mỗi người tạo tối đa một đơn tại một thời điểm. Mỗi đơn có từ 1 đến 20 dòng hàng. Dữ liệu mẫu gồm khách hàng KH-SYN-001, kho KHO-HCM-01, mặt hàng SP-SYN-1001, số lượng 120, đơn giá 185000 VND. Người dùng nhấn nút “Kiểm tra tồn kho” trước khi lưu đơn.

Lần đo mô phỏng	Số người dùng đồng thời	Số dòng đơn	Thời gian từ nhấn nút đến màn hình có kết quả
1	30	1	2,8 giây
2	30	5	4,9 giây
3	30	10	8,7 giây
4	30	20	16,4 giây

Payload mô phỏng được gửi khi người dùng kiểm tra tồn kho:

{
  "customerCode": "KH-SYN-001",
  "warehouseCode": "KHO-HCM-01",
  "currencyCode": "VND",
  "lines": [
    {
      "itemCode": "SP-SYN-1001",
      "quantity": 120,
      "unitOfMeasure": "THUNG"
    }
  ]
}

Kết quả mô phỏng khi đủ tồn kho:

{
  "availabilityStatus": "AVAILABLE",
  "warehouseCode": "KHO-HCM-01",
  "lines": [
    {
      "itemCode": "SP-SYN-1001",
      "requestedQuantity": 120,
      "availableQuantity": 450,
      "unitOfMeasure": "THUNG"
    }
  ]
}

Current Behavior — hành vi hiện tại. Web ERP gửi một yêu cầu kiểm tra cho từng dòng hàng, tuần tự theo thứ tự dòng trên màn hình. Sau khi nhận đủ phản hồi tồn kho, hệ thống mới gọi tính giá bán và chỉ khi tính giá hoàn tất mới bật nút “Lưu đơn”. Vì vậy đơn 20 dòng tạo 20 lần kiểm tra tồn kho tuần tự rồi một lần tính giá. Bằng chứng suy luận là: thời gian đo tăng từ 2,8 giây ở 1 dòng lên 16,4 giây ở 20 dòng; mức tăng gần tỷ lệ với số dòng, phù hợp hành vi gọi tuần tự. Đây là suy luận từ dữ liệu mô phỏng, không khẳng định nguyên nhân kỹ thuật đã được Architect xác nhận.

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

sequenceDiagram
    autonumber
    actor SE as Sales Executive
    participant ERP as Web ERP
    participant INV as Inventory Service
    participant PRC as Pricing Service

    SE->>ERP: Nhấn kiểm tra tồn kho
    loop Mỗi dòng hàng tuần tự
        ERP->>INV: Kiểm tra mặt hàng và kho
        INV-->>ERP: Số lượng khả dụng
    end
    ERP->>PRC: Tính giá toàn đơn
    PRC-->>ERP: Đơn giá và chiết khấu
    ERP-->>SE: Hiển thị kết quả, bật Lưu đơn

Ranh giới facts. Không có bằng chứng trong tình huống này về nguyên nhân gốc tại mạng, cơ sở dữ liệu, mã ứng dụng, cấu hình hạ tầng, năng lực Inventory Service, hay Pricing Service. Không có xác nhận rằng 30 người dùng là tải cao nhất, 16,4 giây là không chấp nhận được, hoặc dữ liệu khách hàng và tồn kho có thuộc phạm vi nghĩa vụ pháp lý cụ thể. Các kết luận đó cần bước phân tích tiếp theo và owner có thẩm quyền.

Senior Lens

Facts ghi “20 dòng mất 16,4 giây”; không ghi “API chậm” hay “cần cache”. “API chậm” là diễn giải kỹ thuật chưa có bằng chứng. BA giữ nguyên số đo, điều kiện đo, payload và luồng hiện tại để Architect, QA và Business Owner đánh giá cùng một nguồn sự thật.

Quick Reference

Thành phần	Đã có trong ví dụ	Chưa được suy diễn
Bối cảnh	Vai trò, thời gian, tải đồng thời, dữ liệu tổng hợp	Tải đỉnh production
Hành vi	Gọi kiểm tra tồn kho tuần tự từng dòng, rồi tính giá	Lỗi thiết kế hay lỗi hạ tầng
Bằng chứng	Bốn lần đo, payload, sơ đồ luồng	Ngưỡng hiệu năng chấp nhận được
Governance	IN_REVIEW, v0.9.0, mô phỏng giáo dục	Approval, baseline, quyết định triển khai

Applied

Bối cảnh mô phỏng: Nova Foods Trading & Manufacturing, dữ liệu tổng hợp, vi-VN, Asia/Ho_Chi_Minh, VND. Kịch bản SCN-NFR-08-01: nhân viên kho xác nhận xuất 500 thùng sản phẩm cho đơn bán hàng SO-SYN-20260807-001 qua màn hình ERP. Mục tiêu chất lượng là không để thao tác xác nhận thành công khi hệ thống chưa ghi đủ dấu vết truy xuất lô.

Bước	Nội dung có thể kiểm chứng	Bằng chứng hoặc suy luận
Facts	Đơn SO-SYN-20260807-001 có một dòng ITEM-SYN-NUOCMAM-500ML, số lượng 500 thùng. Kho chọn hai lô tổng hợp: LOT-SYN-260701-A là 300, LOT-SYN-260705-B là 200.	Tổng số phân bổ lô 300 + 200 = 500; dữ liệu lô cần cho truy xuất thực phẩm trong case study.
Current Behavior	ERP hiện cho nút Xác nhận xuất kho trả thành công ngay sau khi kiểm tra tổng số lượng bằng 500; ghi lô chạy bất đồng bộ sau đó. Nếu tiến trình ghi lô lỗi, phiếu xuất vẫn ở trạng thái POSTED.	Thành công nghiệp vụ đang dựa vào số lượng, không dựa vào lưu thành công liên kết lô.
Underlying Need	Hệ thống cần tính tính toàn vẹn giao dịch: một lần xác nhận chỉ thành công khi số lượng xuất và toàn bộ liên kết lô cùng được lưu; nếu không, toàn bộ giao dịch không được ghi nhận.	Nếu POSTED tồn tại mà thiếu lô, người dùng thấy xuất kho hoàn tất nhưng không thể truy ngược hàng đã xuất.
Options	OPT-NFR-08-01-A: giữ ghi lô bất đồng bộ. OPT-NFR-08-01-B: ghi phiếu xuất và phân bổ lô trong một giao dịch DB. OPT-NFR-08-01-C: cho xác nhận trước, bắt buộc người dùng bổ sung lô sau.	Ba lựa chọn khác nhau ở thời điểm bảo đảm dữ liệu và khả năng phát sinh phiếu thiếu lô.
Decision Criteria	DC-NFR-08-01-01: không có POSTED thiếu lô. DC-NFR-08-01-02: lỗi lưu lô không làm giảm tồn kho. DC-NFR-08-01-03: phản hồi xác nhận không quá 3 giây tại tải mô phỏng 20 yêu cầu đồng thời. DC-NFR-08-01-04: thông báo lỗi không lộ chi tiết DB.	Tiêu chí 1–2 bảo vệ dữ liệu; tiêu chí 3 bảo vệ vận hành; tiêu chí 4 bảo vệ thông tin kỹ thuật.
Decision	Khuyến nghị BA, chưa được phê duyệt: chọn OPT-NFR-08-01-B. API xác nhận dùng một giao dịch DB; chỉ trả 201 Created sau khi tạo phiếu xuất và tất cả dòng phân bổ lô. Lỗi tại bất kỳ bước nào phải rollback toàn bộ.	OPT-NFR-08-01-B thỏa DC-NFR-08-01-01 và DC-NFR-08-01-02 theo cơ chế nguyên tử; cần kiểm thử tải mới xác nhận DC-NFR-08-01-03.
Authority	Business Owner xác nhận chấp nhận gián đoạn thao tác khi lỗi. Solution Architect xác nhận cơ chế transaction và giới hạn hiệu năng. QA Lead xác nhận test basis. Legal/Compliance Owner xác minh nghĩa vụ truy xuất thực phẩm nếu áp dụng thực tế.	Không có approval, baseline, hay production authorization tại IN_REVIEW, v0.9.0.
Artifact	Ghi vào /02-handbook/10-nonfunctional-requirements-and-quality-attributes.md; liên kết quản trị tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY.	Các artifact canonical giữ nguồn chân lý cho rule, dữ liệu và ID; ví dụ này không thay thế chúng.
Consequence if Wrong	Chọn OPT-NFR-08-01-A hoặc OPT-NFR-08-01-C có thể tạo phiếu POSTED thiếu lô, giảm tồn kho sai, làm chậm truy xuất khi có khiếu nại hoặc thu hồi. Chọn transaction nhưng không kiểm thử tải có thể làm xác nhận kho chậm hoặc timeout.	Hậu quả suy ra trực tiếp từ khoảng cách giữa trạng thái phiếu, tồn kho và dữ liệu lô.

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

sequenceDiagram
    autonumber
    participant U as Nhân viên kho
    participant API as ERP API
    participant DB as ERP Database
    participant SA as Solution Architect
    participant QA as QA Lead
    participant BO as Business Owner
    participant LC as Legal/Compliance Owner

    Note over API,DB: OPT-NFR-08-01-B: khuyến nghị BA, IN_REVIEW<br/>Chưa phê duyệt hoặc cho phép production
    Note over SA,LC: Governance, không phải luồng runtime<br/>SA: xác nhận cơ chế transaction và giới hạn hiệu năng<br/>QA: xác nhận test basis<br/>BO: xác nhận chấp nhận gián đoạn khi lỗi<br/>LC: xác minh nghĩa vụ truy xuất thực phẩm nếu áp dụng thực tế

    U->>API: POST /warehouse-issues/confirm
    Note over U,API: ITEM-SYN-NUOCMAM-500ML: 500 THUNG<br/>LOT-SYN-260701-A: 300 + LOT-SYN-260705-B: 200 = 500
    API->>API: Với mọi dòng: sum(lotAllocations.quantity) = item.quantity

    alt Tổng phân bổ lô không hợp lệ
        API-->>U: Mã lỗi nghiệp vụ, phiếu không POSTED
    else Tổng phân bổ lô hợp lệ
        API->>DB: BEGIN TRANSACTION
        API->>DB: Create warehouse issue, status POSTED
        API->>DB: Create all lot allocations
        API->>DB: Reduce inventory

        alt Mọi ghi dữ liệu thành công
            API->>DB: COMMIT
            API-->>U: 201 Created, status POSTED
        else Lỗi ghi phiếu, lô hoặc tồn kho
            API->>DB: ROLLBACK toàn bộ transaction
            API-->>U: Mã lỗi nghiệp vụ, phiếu không POSTED
            Note over API,DB: Không tạo POSTED<br/>Không giảm tồn kho<br/>Không lưu liên kết lô một phần
            Note over API,U: Không trả chi tiết DB hoặc stack trace
        end
    end

    Note over API,DB: Chưa xác minh: phản hồi có thể chậm hoặc timeout<br/>nếu chưa đạt <= 3 giây tại 20 yêu cầu đồng thời

Payload mô phỏng bắt buộc cho kịch bản:

{
  "salesOrderId": "SO-SYN-20260807-001",
  "warehouseId": "WH-SYN-HCM-01",
  "items": [
    {
      "itemId": "ITEM-SYN-NUOCMAM-500ML",
      "quantity": 500,
      "uom": "THUNG",
      "lotAllocations": [
        { "lotId": "LOT-SYN-260701-A", "quantity": 300 },
        { "lotId": "LOT-SYN-260705-B", "quantity": 200 }
      ]
    }
  ]
}

Quy tắc chất lượng đề xuất NFR-SYN-08-01: POSTED chỉ hợp lệ khi mọi dòng xuất có tổng lotAllocations.quantity đúng bằng items.quantity; lỗi ghi phiếu hoặc lô phải rollback; lỗi trả cho người dùng dùng mã nghiệp vụ, không trả stack trace. Đây là khuyến nghị học liệu mô phỏng. Xác minh pháp lý, kiến trúc, hiệu năng và vận hành cần chủ thể có thẩm quyền trước khi dùng ngoài corpus.

Applied

Phạm vi case: Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp. Kịch bản kiểm tra chất lượng API tồn kho khi tạo phiếu xuất nguyên liệu. Locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Trạng thái tài liệu và mọi artifact dưới đây: IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không phải baseline, không có approval.

Loại	ID	Giá trị đầy đủ	Phân loại
Scenario	SCN-NFR-001	Tạo phiếu xuất nguyên liệu MO-20260807-001 từ kho WH-HCM-RM-01 cho lệnh sản xuất MO-20260807-001.	Synthetic scenario
Requirement	NFR-PERF-001	API kiểm tra tồn khả dụng phải trả kết quả trong không quá 2 giây tại percentile 95, với tải đồng thời 50 yêu cầu hợp lệ.	Recommendation
Requirement	NFR-AVAIL-001	Dịch vụ kiểm tra tồn phải đạt khả dụng tháng tối thiểu 99,5%, không gồm bảo trì đã thông báo trước.	Recommendation
Requirement	NFR-SEC-001	API phải xác thực bearer token và chỉ cho phép vai trò WarehouseOperator hoặc ProductionPlanner đọc tồn kho.	Recommendation; tham chiếu good practice OWASP ASVS 5.0.0, không phải kết luận tuân thủ
Business rule	BR-INV-001	availableQuantity = onHandQuantity - reservedQuantity - qualityHoldQuantity. Chỉ cho phép xuất khi requestedQuantity <= availableQuantity.	Project assumption; cần Business Owner và Inventory Owner xác minh
Data object	INV-AVL-001	Bản ghi tồn khả dụng cho một cặp warehouseId và materialId.	Logical data
API operation	API-INV-AVL-001	POST /api/v1/inventory/availability/check	Proposed interface

Payload yêu cầu hoàn chỉnh cho API-INV-AVL-001:

{
  "requestId": "REQ-20260807-0001",
  "requestedAt": "2026-08-07T09:15:00+07:00",
  "warehouseId": "WH-HCM-RM-01",
  "materialId": "RM-SUGAR-001",
  "requestedQuantity": 1200,
  "uom": "KG",
  "productionOrderId": "MO-20260807-001"
}

Payload phản hồi thành công hoàn chỉnh:

{
  "requestId": "REQ-20260807-0001",
  "checkedAt": "2026-08-07T09:15:01+07:00",
  "warehouseId": "WH-HCM-RM-01",
  "materialId": "RM-SUGAR-001",
  "uom": "KG",
  "onHandQuantity": 5000,
  "reservedQuantity": 2500,
  "qualityHoldQuantity": 400,
  "availableQuantity": 2100,
  "requestedQuantity": 1200,
  "canIssue": true,
  "ruleId": "BR-INV-001"
}

Tiêu chí quyết định	Mục tiêu đo	Bằng chứng kiểm tra	Ngưỡng
Hiệu năng	Thời gian phản hồi	100 lần gọi hợp lệ, 50 yêu cầu đồng thời	P95 ≤ 2 giây
Khả dụng	Thời gian hoạt động tháng	Log giám sát dịch vụ	≥ 99,5%
Bảo mật	Kiểm soát truy cập	Gọi API bằng token thiếu vai trò	HTTP 403
Toàn vẹn tồn kho	Công thức tồn khả dụng	So sánh payload với BR-INV-001	5000 - 2500 - 400 = 2100
Quyết định xuất	Kết quả cấp tồn	So sánh 1200 với 2100	canIssue = true

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

flowchart TB
    W["Warehouse Operator"] --> E["Nova Foods ERP"]
    E --> R["POST /api/v1/inventory/availability/check"]

    R --> T{"Bearer token hợp lệ?"}
    T -->|Không| J["Từ chối yêu cầu xác thực"]
    T -->|Có| A{"Có vai trò WarehouseOperator<br/>hoặc ProductionPlanner?"}
    A -->|Không| X["HTTP 403<br/>Từ chối đọc tồn kho"]
    A -->|Có| I["Inventory Service"]

    I --> D["Inventory Data"]
    D --> V["onHand = 5000 KG<br/>reserved = 2500 KG<br/>qualityHold = 400 KG"]
    V --> C["BR-INV-001<br/>availableQuantity = 5000 - 2500 - 400 = 2100 KG"]
    C --> Q{"requestedQuantity 1200 KG<br/>≤ availableQuantity 2100 KG?"}
    Q -->|Có| Y["canIssue = true<br/>Cho phép tiếp tục tạo phiếu xuất"]
    Q -->|Không| N["canIssue = false<br/>Không cho phép xuất vượt tồn khả dụng"]

    I -.-> P["NFR-PERF-001<br/>100 lần gọi hợp lệ<br/>50 yêu cầu đồng thời<br/>Đo P95 ≤ 2 giây"]
    I -.-> U["NFR-AVAIL-001<br/>Log giám sát dịch vụ theo tháng<br/>Khả dụng ≥ 99,5%<br/>Loại trừ bảo trì đã thông báo trước"]

    J --> S["Trạng thái chung<br/>IN_REVIEW · v0.9.0 · 2026-08-07<br/>Chưa có approval"]
    X --> S
    Y --> S
    N --> S
    P --> S
    U --> S

    S --> G1["BR-INV-001 chưa được xác minh<br/>Cần Business Owner và Inventory Owner"]
    S --> G2["Ngưỡng, API, vai trò và vận hành chưa được xác nhận<br/>Cần owner có thẩm quyền: Business Owner, Architect,<br/>Security Owner, QA Owner, Inventory Owner"]

    G1 --> Z["Rủi ro nếu chọn sai ngưỡng, công thức, API, vai trò hoặc vận hành<br/>Xuất vượt tồn · chặn xuất hợp lệ · gián đoạn sản xuất<br/>Lộ số liệu tồn cho vai trò không được phép"]
    G2 --> Z

Khuyến nghị: ghi NFR-PERF-001, NFR-AVAIL-001, NFR-SEC-001 vào artifact dự kiến /01-curriculum/CANONICAL_BUSINESS_RULES.md và liên kết dữ liệu với /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Đây là đề xuất BA để review.

Quyết định có thẩm quyền: chưa có. IN_REVIEW tại v0.9.0 không xác nhận Business Owner, Architect, Security Owner, QA Owner hoặc Inventory Owner đã chấp thuận ngưỡng, công thức, API, vai trò hay vận hành Nova Foods. Nếu chọn sai ngưỡng hoặc công thức, ERP có thể cho xuất vượt tồn khả dụng, chặn xuất hợp lệ, làm gián đoạn sản xuất, hoặc lộ số liệu tồn cho vai trò không được phép.

9. Related Concepts & Dependencies

Core

Yêu cầu phi chức năng phụ thuộc nhiều nguồn nhưng không được sao chép thành nhiều nguồn chân lý. Nguồn chân lý canonical là artifact được kiểm soát, giữ nội dung gốc và ID ổn định. Chapter này chỉ giữ liên kết, phạm vi ảnh hưởng và lý do phụ thuộc.

Nova Foods là case study mô phỏng, chỉ dùng dữ liệu tổng hợp. Mọi artifact dưới đây có trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không phải baseline, approval hay cấu hình ERP production.

Loại phụ thuộc	Artifact canonical	Vai trò với NFR	Không làm trong chapter này
Cấu trúc chapter	/01-curriculum/CHAPTER_MANIFEST.md (CHAPTER_MANIFEST)	Giữ filename, thứ tự chapter, phạm vi học liệu	Đổi tên chapter hoặc tạo chapter mới
Danh mục template	/01-curriculum/TEMPLATE_MANIFEST.md (TEMPLATE_MANIFEST)	Xác định template nào ghi NFR, tiêu chí đo, evidence	Tạo ID template thay manifest
Định danh truy vết	/01-curriculum/TRACEABILITY_ID_REGISTRY.md (TRACEABILITY_ID_REGISTRY)	Cấp và giữ ID như NFR-PERF-001, NFR-SEC-001	Tự đặt lại ID đã đăng ký
Quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md (CANONICAL_BUSINESS_RULES)	Giữ công thức, điều kiện nghiệp vụ, ngưỡng nghiệp vụ	Chép lại hoặc sửa BR-INV-001
Dữ liệu logic	/01-curriculum/CANONICAL_DATA_DICTIONARY.md (CANONICAL_DATA_DICTIONARY)	Giữ nghĩa, kiểu, đơn vị và phân loại dữ liệu	Tự định nghĩa lại onHand, reserved, qualityHold
Nguồn nghiên cứu	/00-research/00_SOURCE_MAP.md (00_SOURCE_MAP)	Giữ phân loại nguồn và ranh giới dùng nguồn	Suy diễn nghĩa vụ pháp lý ngoài nguồn đã xác minh

Quy tắc: ghi ID + đường dẫn canonical + mục đích liên kết. Không dán bản sao đầy đủ của rule, data field, API contract hay template vào NFR. Bản sao lệch phiên bản làm reviewer thấy hai câu trả lời khác nhau cho cùng một câu hỏi.

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

flowchart TB
    M["CHAPTER_MANIFEST<br/>/01-curriculum/CHAPTER_MANIFEST.md<br/>filename, thứ tự, phạm vi chapter"]
    T["TEMPLATE_MANIFEST<br/>/01-curriculum/TEMPLATE_MANIFEST.md<br/>template ghi NFR, tiêu chí đo, evidence"]
    R["TRACEABILITY_ID_REGISTRY<br/>/01-curriculum/TRACEABILITY_ID_REGISTRY.md<br/>cấp và giữ ID NFR ổn định"]
    B["CANONICAL_BUSINESS_RULES<br/>/01-curriculum/CANONICAL_BUSINESS_RULES.md<br/>liên kết quy tắc nghiệp vụ"]
    D["CANONICAL_DATA_DICTIONARY<br/>/01-curriculum/CANONICAL_DATA_DICTIONARY.md<br/>liên kết nghĩa, kiểu, đơn vị dữ liệu"]
    S["00_SOURCE_MAP<br/>/00-research/00_SOURCE_MAP.md<br/>nguồn nghiên cứu và ranh giới sử dụng"]

    M --> H["Chapter NFR<br/>chỉ tham chiếu artifact canonical<br/>giữ phạm vi ảnh hưởng và lý do phụ thuộc"]
    T --> H
    R --> H
    B --> H
    D --> H
    S --> H

    H --> O["NFR liên kết<br/>không sao chép nội dung gốc<br/>không tạo nhiều nguồn chân lý"]

Applied

Facts: Ví dụ mô phỏng Nova Foods kiểm tra tồn khả dụng dùng onHand=5000 KG, reserved=2500 KG, qualityHold=400 KG; API dự kiến là POST /api/v1/inventory/availability/check. Nội dung trước đó tham chiếu BR-INV-001 và đề xuất NFR-PERF-001, NFR-AVAIL-001, NFR-SEC-001.

Current Behavior: Chapter NFR mô tả mục tiêu đo được, như P95 ≤ 2 giây và HTTP 403 khi token thiếu vai trò. Chapter không sở hữu công thức tồn, nghĩa field, hay API schema.

Underlying Need: QA, Architect và BA cần lần ngược từ NFR đến rule và data gốc. Evidence: hiệu năng chỉ đo đúng khi payload dùng cùng nghĩa onHand, reserved, qualityHold; bảo mật chỉ kiểm tra đúng khi quyền API có nguồn quyết định rõ.

Options:
1. Chép công thức và field vào NFR.
2. Chỉ ghi tên nghiệp vụ không có ID.
3. Liên kết ID và artifact canonical.

Decision Criteria: Chọn cách giữ một nguồn chân lý, cho phép tìm ngược, không làm lệch version, không biến chapter học liệu thành API specification.

Decision: Chọn phương án 3. NFR ghi BR-INV-001, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY và đường dẫn canonical. Nội dung gốc vẫn nằm trong registry, rule catalog, data dictionary hoặc API artifact khi artifact đó tồn tại.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết và metadata. Business Owner sở hữu quyết định nghiệp vụ; Architect sở hữu quyết định kiến trúc/API; Security Owner sở hữu quyết định bảo mật; QA Owner sở hữu chiến lược kiểm thử. Chưa có quyết định được ghi nhận.

Artifact: /02-handbook/10-nonfunctional-requirements-and-quality-attributes.md tham chiếu, không thay thế:

Thành phần	Liên kết phải giữ nguyên	Lý do
Rule tồn khả dụng	BR-INV-001 trong /01-curriculum/CANONICAL_BUSINESS_RULES.md	Công thức nghiệp vụ có một chủ sở hữu
Field tồn kho	onHand, reserved, qualityHold trong /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Đơn vị KG và nghĩa field không bị diễn giải khác
ID NFR	NFR-PERF-001, NFR-AVAIL-001, NFR-SEC-001 trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md	ID không đổi khi chapter được biên tập
API	POST /api/v1/inventory/availability/check	API chỉ là tham chiếu minh họa; schema canonical phải thuộc artifact API được kiểm soát
Template	/01-curriculum/TEMPLATE_MANIFEST.md	Tránh tạo biểu mẫu ngoài danh mục

Consequence if Wrong: Nếu BR-INV-001 đổi công thức nhưng NFR giữ bản chép cũ, test hiệu năng có thể chạy payload hợp lệ về kỹ thuật nhưng sai nghiệp vụ. Nếu data dictionary đổi đơn vị KG mà API example không cập nhật, kết quả canIssue=true có thể bị hiểu sai. Nếu ID bị đổi im lặng, link từ requirement sang test và defect mất điểm neo truy vết.

Senior Lens

Phụ thuộc không phải danh sách link. Phụ thuộc là cam kết rằng thay đổi ở nguồn A có thể làm nội dung B sai, dù B không đổi chữ nào. BA phải xác định hướng phụ thuộc trước khi viết: NFR phụ thuộc rule, data, security decision và interface boundary; rule không phụ thuộc vào câu văn diễn giải trong chapter NFR.

Dấu hiệu nguồn bị nhân bản: cùng công thức xuất hiện ở rule catalog, NFR chapter và test note; cùng field có ba mô tả kiểu dữ liệu; cùng ID có hai tên khác nhau. Xử lý: giữ một bản canonical, thay bản còn lại bằng liên kết định danh. Không hợp nhất artifact chỉ để giảm số file; artifact có owner và thẩm quyền khác nhau cần giữ ranh giới.

Nếu nguồn canonical chưa có nội dung hoàn chỉnh, không bịa nội dung để lấp chỗ trống. Ghi rõ liên kết dự kiến, trạng thái IN_REVIEW, và vai trò cần xác nhận. Với dữ liệu cá nhân, kế toán, hóa đơn hoặc an toàn thực phẩm, mọi suy diễn thành yêu cầu triển khai cần Legal Owner, Accounting Owner hoặc domain owner xác minh theo nguồn chính thức.

Quick Reference

Khi cần biết	Xem artifact	Ghi trong NFR
ID nào hợp lệ	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	ID nguyên dạng
Rule nghiệp vụ ở đâu	/01-curriculum/CANONICAL_BUSINESS_RULES.md	ID rule và đường dẫn
Field nghĩa gì	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tên field nguyên dạng và liên kết
Template nào được phép dùng	/01-curriculum/TEMPLATE_MANIFEST.md	Tên template, không tự tạo template
Chapter có đúng phạm vi không	/01-curriculum/CHAPTER_MANIFEST.md	Liên kết chapter, không đổi manifest
Nguồn nào được dùng an toàn	/00-research/00_SOURCE_MAP.md	Nguồn và safe use boundary

Core

Truy vết (traceability) là liên kết có kiểm soát giữa nhu cầu và bằng chứng kiểm tra. Chuỗi tối thiểu: NEED (nhu cầu) giải thích lý do; REQ (yêu cầu) nêu hệ thống phải làm gì; BR (business rule, quy tắc nghiệp vụ) giới hạn cách xử lý; AC (acceptance criteria, tiêu chí chấp nhận) xác định kết quả quan sát được; DATA/API xác định dữ liệu hoặc giao diện tích hợp; TC (test case, ca kiểm thử) chứng minh kết quả. ID từng bản ghi phải sao chép nguyên dạng từ /01-curriculum/TRACEABILITY_ID_REGISTRY.md; handbook không cấp ID mới, không thay registry.

Loại liên kết	Nguồn canonical	Đích dùng trong NFR	Câu hỏi kiểm soát
NEED	TRACEABILITY_ID_REGISTRY	Lý do cần thuộc tính chất lượng, như bảo mật hoặc hiệu năng	Không có NEED, NFR phục vụ giá trị nào?
REQ	Requirement artifact có ID registry	Diễn đạt kết quả chất lượng đo được	REQ có đơn vị đo, ngưỡng và điều kiện đo?
BR	CANONICAL_BUSINESS_RULES	Ràng buộc xử lý nghiệp vụ tác động NFR	BR có giới hạn quyền truy cập, lưu giữ, khóa sổ hay truy xuất?
AC	Requirement artifact có ID registry	Điều kiện nghiệm thu cho REQ	AC có thể quan sát và kiểm tra độc lập?
DATA/API	CANONICAL_DATA_DICTIONARY hoặc OpenAPI artifact được kiểm soát	Trường dữ liệu, phân loại dữ liệu, endpoint, HTTP contract	Dữ liệu nào đi qua giao diện và ai được phép thấy?
TC	Test artifact có ID registry	Bằng chứng kiểm thử cho AC và REQ	TC kiểm tra đúng ngưỡng, dữ liệu và điều kiện của AC?

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

flowchart LR
    NEED[NEED: Giá trị hoặc rủi ro] --> REQ[REQ: Thuộc tính chất lượng]
    BR[BR: Ràng buộc nghiệp vụ] --> REQ
    REQ --> AC[AC: Điều kiện chấp nhận]
    DATA[DATA/API: Hợp đồng dữ liệu hoặc tích hợp] --> AC
    AC --> TC[TC: Ca kiểm thử]
    DATA --> TC

Applied

Mục	Nội dung mô phỏng Nova Foods, dữ liệu tổng hợp
Facts	ERP có API đồng bộ đơn hàng với hệ thống bên ngoài mô phỏng. API xử lý dữ liệu khách hàng tổng hợp.
Current Behavior	Yêu cầu NFR chỉ ghi “API phải an toàn”; không liên kết AC, trường dữ liệu hay TC.
Underlying Need	NEED canonical cần được nối tới REQ để đội delivery biết bảo vệ giá trị nào; “an toàn” không tự tạo được phép đo hoặc bằng chứng.
Options	(1) Giữ mô tả tự do. (2) Liên kết REQ với NEED, BR nếu có, AC, DATA/API và TC bằng ID canonical.
Decision Criteria	Không tạo ID ngoài registry; mỗi liên kết có nguồn canonical; AC kiểm tra được; DATA/API nêu đúng trường và phân loại đã đăng ký.
Decision	Chọn phương án 2. Bảng truy vết chỉ chứa ID canonical và vị trí artifact; nội dung chi tiết vẫn nằm ở nguồn gốc.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết. Security, Architect, QA, Business Owner hoặc Legal Owner xác nhận phần thuộc thẩm quyền họ khi được kích hoạt.
Artifact	/01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md và requirement/test artifact được kiểm soát.
Consequence if Wrong	TC có thể kiểm tra endpoint sai hoặc thiếu trường nhạy cảm; REQ có vẻ hoàn tất nhưng không chứng minh được NEED; thay đổi API có thể phá kiểm thử hoặc kiểm soát truy cập mà không bị phát hiện.

Senior Lens

Không suy ra BR từ REQ bảo mật. REQ “chỉ người có quyền được xem dữ liệu” cần BR hoặc quyết định quyền truy cập làm nguồn. Không suy ra nghĩa vụ pháp lý từ tên trường dữ liệu. Nếu liên kết chạm dữ liệu cá nhân, lưu giữ, kế toán, hóa đơn hoặc an toàn thực phẩm, ghi Verification required và chuyển đúng owner có thẩm quyền.

Một REQ có thể liên kết nhiều TC vì cần kiểm thử ngưỡng, lỗi và quyền truy cập. Một TC không được tự tạo phạm vi mới: TC chỉ kiểm tra AC và REQ đã tồn tại. Evidence bridge: NEED nêu giá trị; REQ chuyển giá trị thành cam kết đo được; AC nêu điều kiện đạt; TC tạo bằng chứng tái lập.

Quick Reference

Kiểm tra trước khi ghi liên kết	Đạt khi
ID	Sao chép nguyên dạng từ TRACEABILITY_ID_REGISTRY; không tự đặt tiền tố hoặc số thứ tự
Nguồn chân lý	BR chỉ trỏ CANONICAL_BUSINESS_RULES; dữ liệu chỉ trỏ CANONICAL_DATA_DICTIONARY hoặc OpenAPI artifact
Đủ chuỗi	NFR có NEED, REQ, AC và TC; thêm BR, DATA/API khi NFR bị ràng buộc nghiệp vụ hoặc tích hợp
Kiểm thử	TC trỏ AC cụ thể, có dữ liệu tổng hợp và kết quả mong đợi
Trạng thái	Mọi artifact hiện IN_REVIEW, v0.9.0, ngày 2026-08-07; không diễn giải là baseline hoặc phê duyệt

Core

Thay đổi lan truyền khi nguồn phụ thuộc đổi nội dung, cấu trúc, trạng thái, ID hoặc cách diễn giải. Ví dụ, CANONICAL_DATA_DICTIONARY đổi tên trường dữ liệu hoặc CANONICAL_BUSINESS_RULES đổi điều kiện nghiệp vụ. Artifact hạ nguồn vẫn giữ nội dung cũ sẽ tạo lệch giữa nhu cầu, yêu cầu, API, kiểm thử và hướng dẫn. “Thay đổi im lặng” là sửa nguồn canonical không có lịch sử thay đổi, đánh giá ảnh hưởng, thông báo hoặc cập nhật liên kết truy vết.

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Tại IN_REVIEW, version v0.9.0, ngày 2026-08-07, không artifact nào được xem là baseline, approved hoặc cấu hình ERP production.

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

flowchart TB
    A["Nguồn canonical<br/>CANONICAL_BUSINESS_RULES"] --> B["Requirement và AC"]
    C["Nguồn canonical<br/>CANONICAL_DATA_DICTIONARY"] --> D["Định nghĩa trường dữ liệu"]
    N["Nhu cầu"] --> B
    B --> E["DATA/API contract"]
    D --> E
    B --> F["Test case"]
    E --> F
    B --> J["Hướng dẫn"]
    E --> J
    F --> K["Kết quả kiểm thử"]

    A -. thay đổi im lặng .-> L["Thiếu lịch sử thay đổi<br/>đánh giá ảnh hưởng, thông báo<br/>và cập nhật liên kết truy vết"]
    C -. thay đổi im lặng .-> L
    L -. để lại nội dung cũ .-> M["Lệch nhu cầu, REQ/AC<br/>API/data contract, kiểm thử, hướng dẫn"]
    A -. rule đổi .-> I["API đọc, gửi hoặc xử lý sai"]
    C -. trường đổi .-> I

Applied

Mục	Nội dung
Facts	Một quy tắc trong /01-curriculum/CANONICAL_BUSINESS_RULES.md thay đổi điều kiện xử lý đơn hàng mô phỏng. Requirement, acceptance criteria và test case liên kết vẫn dùng điều kiện trước đó.
Current Behavior	Người viết cập nhật rule tại nguồn canonical nhưng không kiểm impact sang requirement, DATA/API, acceptance criteria và test case.
Underlying Need	Mọi consumer phải biết nội dung nào đổi, liên kết nào bị ảnh hưởng, ai phải xem xét và bằng chứng nào xác nhận đã đồng bộ.
Options	1. Sửa từng artifact khi phát hiện lỗi. 2. Ghi thay đổi tại nguồn canonical, truy vấn liên kết truy vết, lập impact list rồi cập nhật có kiểm soát.
Decision Criteria	Không nhân bản nguồn chân lý; giữ ID ổn định; xác định đầy đủ artifact hạ nguồn; không ngầm gọi thay đổi là approved; giữ bằng chứng review.
Decision	Chọn option 2. Nguồn canonical chỉ ghi thay đổi của chính nó. Artifact hạ nguồn chỉ giữ liên kết và nội dung cần thiết cho mục đích riêng.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì traceability. Business Owner, Architect, QA, Legal, Accounting hoặc Security xem xét phần thuộc thẩm quyền. Không có approval ngầm định.
Artifact	/01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, cùng artifact requirement, API và test liên kết.
Consequence if Wrong	Requirement thực thi rule cũ; API xử lý dữ liệu không khớp; test “pass” sai test basis; báo cáo hoặc kiểm soát mô phỏng có thể mâu thuẫn. Lỗi phát hiện muộn làm tăng rework và che mất nguồn gây lỗi.

Senior Lens

Chuỗi thay đổi phải đi từ nguồn canonical đến consumer, không đi từ bản sao ngược về nguồn. Khi rule đổi, BA kiểm tra NEED, REQ, BR, AC, DATA/API và TC nếu các loại liên kết này tồn tại trong registry. Không tự tạo ID mới để “sửa nhanh”; ID cũ cần giữ để bảo toàn lịch sử, còn trạng thái liên kết phải phản ánh còn hiệu lực, cần cập nhật hoặc không còn áp dụng theo cơ chế registry.

Dependency đổi im lặng	Thành phần vỡ	Dấu hiệu	Kiểm soát tối thiểu
BR đổi điều kiện	REQ, AC, TC	AC và TC xác nhận hành vi khác nhau	Impact review theo liên kết BR
Data definition đổi kiểu, tên, ý nghĩa	DATA/API, mapping, TC	Payload hợp lệ kỹ thuật nhưng sai nghĩa nghiệp vụ	Review contract và test dữ liệu biên
API contract đổi request hoặc response	Consumer, TC tích hợp	Lỗi validation, dữ liệu rỗng hoặc mapping sai	Version/change log và compatibility review
Source classification đổi	Nội dung handbook, claim tuân thủ	Nội dung dùng nguồn không còn phù hợp	Kiểm tra /00-research/00_SOURCE_MAP.md
Status/version artifact đổi	Liên kết quản trị, quyết định sử dụng	Người dùng hiểu nhầm IN_REVIEW là approved	Giữ metadata canonical, không sao chép trạng thái thiếu ngữ cảnh

Suy luận: một TC chỉ chứng minh đúng với test basis mà nó tham chiếu. Nếu BR hoặc DATA/API đã đổi nhưng TC không đổi, kết quả pass chỉ chứng minh hệ thống khớp phiên bản cũ. Vì vậy, pass không bù được traceability bị đứt.

Quick Reference

Quy tắc	Hành động
Canonical source đổi	Ghi lịch sử thay đổi tại artifact chủ quản.
Có liên kết hạ nguồn	Lập impact list từ registry trước khi sửa consumer.
Không xác định được owner	Escalate; không tự suy diễn quyết định nghiệp vụ, pháp lý, kế toán, bảo mật hoặc kiến trúc.
Consumer chưa cập nhật	Gắn trạng thái cần xem xét; không tuyên bố đồng bộ hoặc approved.
Thay đổi có dữ liệu/API	Kiểm tra cả nghĩa dữ liệu, cấu trúc payload và TC tích hợp.

10. Common Mistakes & Anti-patterns

Core

Yêu cầu phi chức năng, hay Nonfunctional Requirement (NFR), mô tả chất lượng hệ thống phải đạt, như thời gian phản hồi, tính sẵn sàng, bảo mật, khả năng sử dụng và khả năng truy vết. Lỗi phổ biến không nằm ở việc quên viết một câu NFR; lỗi nằm ở việc viết câu không thể đo, không thể kiểm thử, hoặc không gắn vào hành vi nghiệp vụ cụ thể.

Sai lầm	Dấu hiệu quan sát được	Nguyên nhân gốc	Hành động sửa
Viết “hệ thống phải nhanh”	Không có thời lượng, tải, màn hình hay giao dịch	Nhầm mong muốn chung với yêu cầu kiểm thử được	Ghi ngưỡng, phạm vi, điều kiện tải, cách đo
Gán một con số không có bằng chứng	NFR ghi 100 ms nhưng không có dữ liệu quy trình hoặc giới hạn kỹ thuật	Sao chép số từ dự án khác	Gắn nguồn, giả định dự án hoặc yêu cầu xác minh
Chỉ xét giao diện	API, batch, import và báo cáo không có mục tiêu chất lượng	BA chỉ quan sát luồng người dùng	Liệt kê mọi điểm chạm: UI, API, job, báo cáo, tích hợp
Đặt NFR sau khi build	QA không có test basis, kiến trúc đã khóa	NFR bị xem là việc kiểm thử cuối dự án	Đưa NFR vào phạm vi discovery và review cùng requirement chức năng
Dùng “ổn định”, “dễ dùng”, “an toàn” làm tiêu chí nghiệm thu	Tester và đội phát triển hiểu khác nhau	Không chuyển tính từ sang điều kiện quan sát được	Xác định người dùng, tác vụ, ngưỡng, phép đo, kết quả pass/fail
Gom nhiều chất lượng vào một câu	Một câu vừa nói hiệu năng, bảo mật, availability	Muốn viết ngắn nhưng mất khả năng sở hữu và kiểm thử	Tách từng thuộc tính chất lượng thành requirement riêng

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

flowchart TB
    A[Nhu cầu nghiệp vụ] --> B[Xác định điểm chạm]
    B --> C[Chọn thuộc tính chất lượng]
    C --> D[Ghi ngưỡng, phạm vi, tải và cách đo]
    D --> E{Có nguồn hoặc giả định được ghi rõ?}
    E -->|Có| F[Test basis cho QA và Architect]
    E -->|Không| G[Xác minh nguồn hoặc ghi giả định]
    G --> H[Cập nhật ngưỡng và cách đo]
    H --> E

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp.

Trường	Nội dung
Facts	Nhân viên kho dùng màn hình xác nhận xuất hàng trong giờ cao điểm cuối ngày. Dữ liệu mô phỏng ghi nhận 40 người dùng đồng thời và 120 yêu cầu xác nhận trong 10 phút.
Current Behavior	Requirement hiện có ghi: “Màn hình xuất hàng phải phản hồi nhanh.”
Underlying Need	Nhân viên kho cần biết xác nhận đã được ghi nhận trước khi xử lý kiện hàng tiếp theo; phản hồi chậm làm tăng nguy cơ bấm lặp.
Options	(1) Giữ câu mô tả chung. (2) Đặt NFR có thời gian phản hồi, tải mô phỏng và tiêu chí đo.
Decision Criteria	QA phải tạo được kiểm thử; Architect phải đánh giá được tải; Business Owner phải hiểu tác động vận hành; số liệu phải có nguồn hoặc nhãn giả định.
Decision	Chọn phương án 2: “Trong tải mô phỏng 40 người dùng đồng thời, 95% yêu cầu xác nhận xuất hàng trả kết quả thành công hoặc lỗi nghiệp vụ hợp lệ trong không quá 3 giây, đo từ lúc người dùng gửi yêu cầu đến lúc UI nhận phản hồi.” Đây là project assumption cho học liệu, không phải cam kết production.
Authority	Business Owner xác nhận mức chấp nhận vận hành; Architect xác nhận khả thi kỹ thuật; QA xác nhận cách đo. Artifact IN_REVIEW không chứng minh các xác nhận này đã xảy ra.
Artifact	Requirement NFR liên kết với requirement xuất hàng, acceptance criteria và test case hiệu năng trong artifact kiểm soát tương ứng.
Consequence if Wrong	Nếu ghi “nhanh”, QA không có ngưỡng pass/fail. Nếu tự đặt 3 giây như quyết định đã được chấp thuận, đội có thể thiết kế sai năng lực hệ thống và hiểu sai thẩm quyền.

Suy luận: 40 người dùng đồng thời và 120 yêu cầu trong 10 phút là bằng chứng về bối cảnh tải mô phỏng. Chúng chưa đủ để kết luận 3 giây là mức phù hợp. Vì vậy, 3 giây phải mang nhãn project assumption cho đến khi vai trò có thẩm quyền xác nhận.

Senior Lens

Senior BA không biến mọi ý kiến thành NFR. Câu “người dùng muốn nhanh hơn” là tín hiệu cần khám phá, chưa phải requirement. Hỏi tiếp: tác vụ nào chậm, ai bị ảnh hưởng, chậm bao lâu gây lỗi vận hành, tải nào xảy ra, và ai sở hữu mức chấp nhận. Mỗi câu trả lời tạo cầu nối từ nhu cầu đến điều kiện kiểm thử.

Không dùng NFR để che thiếu sót thiết kế. Ví dụ, “không được mất dữ liệu” không thay thế yêu cầu xác định thời điểm lưu, xử lý lỗi, cơ chế chống gửi lặp và cách người dùng biết kết quả. NFR nêu chất lượng mong muốn; requirement chức năng và thiết kế nêu hành vi cần thực hiện.

Cảnh báo: Đừng hạ ngưỡng chất lượng chỉ để test pass khi chưa xác định tác động nghiệp vụ. Với Nova Foods mô phỏng, giảm mục tiêu phản hồi từ 3 giây xuống 10 giây có thể làm giảm lỗi kỹ thuật trên báo cáo nhưng tăng nguy cơ nhân viên kho gửi lặp. Recovery an toàn: giữ kết quả đo, ghi impact, đưa lại cho Business Owner, Architect và QA xem xét; không sửa requirement im lặng.

Quick Reference

Quy tắc	Kiểm tra trước khi ghi NFR
Có thể đo	Có đơn vị đo, ngưỡng và cách đo
Có phạm vi	Nêu rõ tác vụ, kênh UI/API/batch và điều kiện tải
Có test basis	QA có thể viết pass/fail mà không tự đoán
Có bằng chứng	Số liệu có nguồn, hoặc ghi rõ project assumption
Có owner đúng	Mức chấp nhận thuộc vai trò nghiệp vụ và kỹ thuật phù hợp
Không hứa quá mức	IN_REVIEW không phải approved, baselined hay production-ready

Core

Cảnh báo chỉ dùng cho rủi ro có hậu quả cụ thể: mất dữ liệu, sai sổ vết, lộ dữ liệu, gián đoạn vận hành, hoặc diễn giải sai nghĩa vụ pháp lý. Không dùng cảnh báo để nhấn mạnh mẹo viết tài liệu. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp, không xác nhận cấu hình ERP thật.

[!WARNING] Không khôi phục bằng cách sửa trực tiếp dữ liệu nghiệp vụ hoặc chạy lại tích hợp không kiểm soát. Hành động này có thể tạo giao dịch trùng, phá vỡ dấu vết kiểm toán, hoặc che mất nguyên nhân lỗi.

Failure example Nova Foods mô phỏng	Dấu hiệu quan sát	Hậu quả thật	Ranh giới khôi phục an toàn
Job đồng bộ đơn bán hàng gửi lại cùng một yêu cầu sau lỗi mạng	Hai chứng từ có cùng mã tham chiếu nguồn, thời điểm gần nhau, cùng giá trị VND	Ghi nhận đơn trùng; tồn kho và công nợ mô phỏng sai	Dừng job, cô lập bản ghi nghi trùng, giữ log yêu cầu và phản hồi, đối soát với nguồn trước khi có người có thẩm quyền quyết định xử lý
Người dùng sửa số lô hàng sau khi lỗi truy xuất	Mã lô trên chứng từ khác mã lô trong lịch sử giao dịch	Đứt chuỗi truy vết lô; không xác định được phạm vi ảnh hưởng khi thu hồi mô phỏng	Khóa sửa, sao lưu bằng chứng hiện có, lập danh sách bản ghi ảnh hưởng; không tự suy diễn mã lô thay thế
Tài liệu gọi một sơ đồ PlantUML là BPMN	Sơ đồ không dùng ký pháp BPMN 2.0.2 nhưng được gắn nhãn BPMN	Đội delivery hiểu sai gateway, event hoặc trách nhiệm quy trình	Đổi nhãn thành “PlantUML activity diagram”, hoặc vẽ lại bằng ký pháp BPMN 2.0.2 được xác minh

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

flowchart TB
    A[Phát hiện giao dịch nghi trùng] --> B[Dừng xử lý tự động liên quan]
    B --> C[Cô lập bản ghi nghi trùng, không sửa dữ liệu nghiệp vụ]
    C --> D[Giữ log và bản ghi hiện trạng]
    D --> E[Đối soát với nguồn giao dịch]
    E --> F{Có thẩm quyền quyết định xử lý?}
    F -- Không --> G[Chuyển bằng chứng cho người có thẩm quyền]
    G --> H[Chờ quyết định xử lý]
    H --> F
    F -- Có --> I[Thực hiện phương án do người có thẩm quyền quyết định và lưu dấu vết]
    I --> J[Xác minh không tạo giao dịch trùng, trạng thái sau xử lý và dấu vết được lưu giữ]

Applied

Trường	Nội dung
Facts	Trong Nova Foods mô phỏng, tích hợp đơn bán hàng báo lỗi kết nối sau khi gửi yêu cầu tạo đơn trị giá 12.500.000 VND. Job tự chạy lại. Hệ thống đích có hai đơn cùng mã tham chiếu nguồn.
Current Behavior	Nhân viên đề xuất xóa một đơn trực tiếp để “làm sạch dữ liệu”.
Underlying Need	Khôi phục số liệu mô phỏng đúng mà vẫn giữ được bằng chứng về lỗi, lần chạy lại và quyết định xử lý.
Options	1. Xóa trực tiếp đơn nghi trùng. 2. Dừng job, giữ log, đánh dấu bản ghi nghi trùng, đối soát nguồn, rồi chuyển người có thẩm quyền quyết định.
Decision Criteria	Không mất bằng chứng; không tạo thêm đơn; truy vết được nguyên nhân; không biến BA thành người quyết định kế toán hoặc vận hành.
Decision	Chọn phương án 2. Không xóa, sửa, hoặc chạy lại job cho đến khi đối soát hoàn tất và quyết định được ghi nhận bởi vai trò có thẩm quyền.
Authority	BA duy trì bằng chứng và traceability. Business Owner quyết định nghiệp vụ. Accounting Owner xác nhận ảnh hưởng ghi nhận. Architect hoặc đội kỹ thuật quyết định cơ chế chống gửi trùng.
Artifact	Ghi nhận trong /02-handbook/10-nonfunctional-requirements-and-quality-attributes.md; liên kết quản trị dùng TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, và CANONICAL_DATA_DICTIONARY khi các artifact đó có nội dung được kiểm soát.
Consequence if Wrong	Xóa trực tiếp có thể làm mất bằng chứng, che lỗi idempotency, và khiến số liệu mô phỏng không còn giải thích được.

Senior Lens

Cảnh báo tốt phải nêu rõ điều gì không được làm, vì sao không được làm, và điểm dừng trước khi cần thẩm quyền khác. “Đã tuân thủ”, “đã được phê duyệt”, hoặc “đúng luật” không phải căn cứ khôi phục. IN_REVIEW và v0.9.0 chỉ nói trạng thái artifact; không tạo baseline, approval, legal sign-off, hoặc quyền production.

[!WARNING] Yêu cầu liên quan dữ liệu cá nhân, kế toán, hóa đơn, an toàn thực phẩm, hoặc truy xuất nguồn gốc không được tự chuyển thành cấu hình ERP từ tài liệu học liệu. Cần xác minh nguồn chính thức hiện hành và quyết định từ Legal Owner, Accounting Owner, Business Owner hoặc vai trò chuyên môn phù hợp.

Quick Reference

Rủi ro	Làm ngay	Không làm
Giao dịch nghi trùng	Dừng xử lý liên quan, giữ log, đối soát nguồn	Xóa bản ghi, chạy lại không kiểm soát
Sai dữ liệu truy vết	Khóa sửa, bảo toàn hiện trạng, escalation	Sửa mã lô theo suy đoán
Cảnh báo pháp lý hoặc tuân thủ	Gắn Verification required, chuyển đúng owner	Gọi là nghĩa vụ đã xác nhận
Lỗi ký pháp mô hình	Sửa nhãn hoặc dùng đúng chuẩn nguồn	Gọi sơ đồ không chuẩn là BPMN

Core

Năm lỗi khác nhau, không gộp chung thành “yêu cầu chưa rõ”:

Loại lỗi	Dấu hiệu quan sát được	Nguyên nhân gốc	Cách sửa trong artifact
Mơ hồ (ambiguity)	“nhanh”, “đủ”, “phù hợp”, “kịp thời” không có thước đo	Người viết dùng ngôn ngữ hội thoại thay tiêu chí kiểm chứng	Thay bằng điều kiện, đơn vị đo, ngưỡng, thời điểm đo
Thiếu thông tin (incompleteness)	Có tác nhân và hành động, thiếu ngoại lệ, dữ liệu vào, kết quả hoặc lỗi	Nhóm giả định người đọc biết bối cảnh	Liệt kê luồng chính, ngoại lệ, dữ liệu, trạng thái, kết quả
Khẳng định sai thẩm quyền	Viết “pháp luật yêu cầu”, “Business Owner đã duyệt” nhưng không có bằng chứng canonical	Nhầm nguồn tham khảo với quyết định có thẩm quyền	Gắn Verification required, nêu vai trò cần xác nhận, không nâng thành quy tắc
Dùng sai ký pháp (notation misuse)	Gọi sơ đồ PlantUML là BPMN; dùng mũi tên không có chú giải trạng thái	Chọn hình thức trước khi xác định mục đích mô hình	Gắn đúng loại sơ đồ, ký hiệu, phạm vi; dùng nguồn OMG khi gọi là BPMN hoặc UML
Đứt truy vết (traceability break)	NFR không liên kết nguồn, requirement, acceptance criterion hay test basis	ID bị tự đặt, thay đổi không cập nhật liên kết	Dùng ID đã đăng ký trong TRACEABILITY_ID_REGISTRY; ghi artifact nguồn và liên kết kiểm tra

Nguyên tắc kiểm tra: một câu chỉ kiểm chứng được khi người đọc xác định được ai, làm gì, trong điều kiện nào, đầu vào nào, kết quả nào, và đo bằng cách nào. Thiếu một phần không luôn là mơ hồ; thiếu ngoại lệ là thiếu thông tin, còn có nhiều cách hiểu cho cùng câu là mơ hồ.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là tổng hợp.

Trường	Nội dung
Facts	Bản nháp NFR ghi: “ERP phải đồng bộ tồn kho nhanh và tuân thủ pháp luật Việt Nam.” Không có ngưỡng thời gian, luồng đồng bộ, nguồn pháp lý đã kiểm tra, hoặc người có thẩm quyền xác nhận.
Current Behavior	QA không thể lập test pass/fail. Architect không biết đồng bộ đồng bộ hay bất đồng bộ. Legal/Compliance không thể xác nhận câu “tuân thủ”.
Underlying Need	Người dùng cần biết tồn kho sau khi giao dịch được xử lý đủ sớm để quyết định bán hàng, nhưng mức chậm chấp nhận được chưa được quyết định.
Options	1. Giữ câu tổng quát. 2. Tự chọn ngưỡng 5 giây. 3. Ghi requirement đo được nhưng gắn giả định và điểm xác nhận thẩm quyền.
Decision Criteria	Có test được; không tự tạo cam kết pháp lý; không tự quyết định kiến trúc; giữ liên kết đến nguồn và người quyết định.
Decision	Chọn 3. Viết: “Project assumption: Với giao dịch xuất kho đã được ERP chấp nhận, số lượng tồn kho hiển thị cho người dùng bán hàng được cập nhật trong không quá 60 giây, đo từ thời điểm giao dịch có trạng thái POSTED đến thời điểm API truy vấn trả về số lượng mới. Ngoại lệ lỗi tích hợp phải tạo bản ghi lỗi có thể truy vết.”
Authority	Business Owner xác nhận nhu cầu vận hành và ngưỡng chấp nhận. Architect xác nhận cơ chế tích hợp. Legal/Compliance Owner xác nhận nghĩa vụ pháp lý nếu có. QA xác nhận tính kiểm thử. Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì artifact và traceability.
Artifact	NFR draft liên kết TRACEABILITY_ID_REGISTRY, nguồn nghiệp vụ được chỉ định, acceptance criterion và test basis. Không gán ID mới ngoài registry.
Consequence if Wrong	Ngưỡng tự chọn có thể làm tăng chi phí kiến trúc vô ích hoặc khiến tồn kho hiển thị muộn. Câu “tuân thủ pháp luật” không có xác minh có thể bị hiểu sai thành cam kết pháp lý hoặc approval.

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

flowchart TB
    A[Giao dịch xuất kho] --> B{Trạng thái POSTED?}
    B -- Không --> C[Không tính thời gian NFR]
    B -- Có --> D[Ghi mốc thời gian POSTED]
    D --> E[Cập nhật số lượng tồn kho]
    E -- Lỗi tích hợp --> J[Tạo bản ghi lỗi có thể truy vết]
    E -- Thành công --> F[API truy vấn trả về số lượng mới]
    F --> G{Thời gian <= 60 giây?}
    G -- Có --> H[Đạt acceptance criterion]
    G -- Không --> I[Không đạt: tạo evidence cho QA]

[!WARNING] Không thay Project assumption bằng “đã tuân thủ Luật Bảo vệ dữ liệu cá nhân” hoặc “đã được Business Owner phê duyệt”. IN_REVIEW, version v0.9.0, ngày 2026-08-07 không tạo baseline hay approval. Phục hồi an toàn: hạ câu khẳng định xuống Verification required, giữ nguyên evidence hiện có, rồi chuyển đúng Owner xác nhận. Không xóa liên kết hoặc sửa lịch sử để làm artifact trông như đã được duyệt.

Senior Lens

Phân loại sai dẫn đến sửa sai. Với câu “hệ thống phải bảo mật”, lỗi chính là mơ hồ vì “bảo mật” chưa có thuộc tính kiểm chứng. Với câu “API phải mã hóa nhưng chưa nói dữ liệu nào, giao thức nào, khi nào”, lỗi chính là thiếu thông tin. Với câu “OWASP ASVS bắt buộc Nova Foods dùng MFA”, lỗi là khẳng định sai thẩm quyền: OWASP ASVS là chuẩn thực hành ngành, không tự là luật Việt Nam. Với câu “sơ đồ dưới đây là BPMN” nhưng sơ đồ là Mermaid flowchart, lỗi là dùng sai ký pháp; gọi đúng là flowchart Mermaid, không gọi BPMN.

Đứt truy vết khác với thiếu nguồn. Một NFR có thể có nguồn nhưng vẫn đứt nếu liên kết trỏ tới tên file không canonical, ID không đăng ký, hoặc requirement thay đổi mà acceptance criterion cũ không được xem xét. Bằng chứng phải đi theo chuỗi: nguồn hoặc giả định, requirement, acceptance criterion, test basis, kết quả kiểm tra. Chuỗi này cho biết vì sao nội dung tồn tại và ai cần xác nhận; nó không tự tạo thẩm quyền.

Quick Reference

Khi gặp câu	Phân loại	Sửa tối thiểu
“Giao diện phải dễ dùng”	Mơ hồ	Nêu tác vụ, nhóm người dùng, tiêu chí quan sát hoặc tiêu chí accessibility phù hợp
“Lưu audit log”	Thiếu thông tin	Nêu sự kiện, trường log, thời hạn, quyền xem, lỗi ghi log
“Nghị định yêu cầu lưu 10 năm” không có kiểm tra chính thức	Khẳng định sai thẩm quyền	Gắn Verification required; chuyển Legal/Compliance hoặc Accounting Owner
“BPMN” cho sơ đồ không dùng BPMN 2.0.2	Dùng sai ký pháp	Đổi nhãn sơ đồ hoặc lập BPMN đúng ký pháp OMG
NFR không có liên kết nguồn và test	Đứt truy vết	Liên kết artifact canonical, ID registry, acceptance criterion, test basis

11. Senior BA Notes & Rules of Thumb

Senior Lens

NFR là ràng buộc chất lượng, không phải khẩu hiệu “hệ thống phải nhanh” hoặc “hệ thống phải an toàn”. Senior BA tách nhu cầu thành tác vụ, đối tượng, ngưỡng đo, điều kiện tải, cách kiểm tra và người quyết định. Suy luận: nếu không có ngưỡng và phương pháp đo, QA không thể kết luận đạt hay không đạt; vì vậy câu NFR chưa đủ làm test basis.

Nova Foods Trading & Manufacturing là case study mô phỏng; mọi ví dụ dùng dữ liệu tổng hợp. Khi Kho vận yêu cầu màn hình xuất kho phản hồi dưới 2 giây, còn Architect nêu giới hạn tích hợp ERP, Senior BA không chọn bên “đúng” bằng chức danh. BA ghi trade-off: ngưỡng thấp hơn có thể giảm thời gian thao tác, nhưng tăng chi phí hạ tầng hoặc loại trừ thời gian phản hồi từ dịch vụ ngoài. Cần tách thời gian hệ thống Nova Foods kiểm soát khỏi thời gian mạng, trình duyệt và API bên thứ ba trước khi đề xuất ngưỡng.

Điểm cần xét	Câu hỏi Senior BA	Bằng chứng cần có	Thẩm quyền quyết định
Giá trị nghiệp vụ	Chậm bao nhiêu gây lỗi, mất doanh thu hoặc dừng vận hành?	Số liệu tác vụ, lỗi, thời gian chờ mô phỏng	Business Owner
Khả thi kỹ thuật	Ngưỡng có đạt trong kiến trúc dự kiến không?	Ước lượng kỹ thuật, giới hạn tích hợp, kết quả thử nghiệm nếu có	Architect
Khả năng kiểm tra	QA đo bằng dữ liệu, tải và môi trường nào?	Acceptance criterion, test basis, công cụ và điều kiện đo	QA Owner
Bảo mật và dữ liệu cá nhân	NFR có tạo rủi ro truy cập trái phép hoặc xử lý dữ liệu cá nhân không?	Phân loại dữ liệu, luồng truy cập, đánh giá Security	Security Owner; Legal/Compliance Owner khi áp dụng
Kế toán, thuế, an toàn thực phẩm	NFR có diễn giải nghĩa vụ pháp lý hoặc thời hạn lưu trữ không?	Nguồn chính thức đã kiểm tra, ý kiến chuyên môn được ghi nhận	Accounting Owner, Legal/Compliance Owner, domain owner

Quy tắc thường dùng: ưu tiên NFR đo được, có phạm vi hẹp, và truy vết được về nguồn hoặc giả định. Ngoại lệ: chưa áp ngưỡng số ngay khi bằng chứng chỉ là nhận định ban đầu. Khi đó ghi rõ Project assumption hoặc Verification required, nêu dữ liệu còn thiếu và người phải xác nhận. Không thay nhãn này bằng số liệu nghe hợp lý. Số “99,9% availability” không đáng tin nếu chưa xác định giờ phục vụ, planned maintenance, thành phần được tính và cách đo.

Mâu thuẫn stakeholder thường là mâu thuẫn mục tiêu, không phải lỗi giao tiếp. Ví dụ Sales muốn phiên tạo đơn không hết hạn để tránh mất đơn; Security muốn thời gian hết hạn ngắn để giảm rủi ro chiếm quyền phiên. Senior BA mô tả hai hậu quả, phương án trung gian như cảnh báo trước khi hết hạn hoặc lưu nháp, rồi chuyển quyết định rủi ro bảo mật cho Security Owner và quyết định chấp nhận ảnh hưởng nghiệp vụ cho Business Owner. BA không tự tuyên bố một phương án “tuân thủ” hoặc “được phê duyệt”.

Red flag	Ngưỡng escalation	Nơi chuyển quyết định
NFR viện dẫn luật nhưng chưa kiểm tra văn bản chính thức hiện hành	Ngay khi được viết như nghĩa vụ bắt buộc	Legal/Compliance Owner; Accounting Owner hoặc domain owner khi phù hợp
Một requirement đồng thời thay đổi bảo mật, kiến trúc và quy trình nghiệp vụ	Ngay khi có hơn một thẩm quyền chuyên môn	Business Owner, Architect, Security Owner
Ngưỡng chất lượng không có cách đo hoặc môi trường đo	Trước khi đưa vào acceptance criterion	QA Owner và Architect
Nguồn là ý kiến cá nhân, ticket không kiểm soát hoặc bản trình bày không có owner	Trước khi dùng làm căn cứ quyết định	Owner của nguồn; Business Owner nếu cần ưu tiên
NFR ảnh hưởng dữ liệu cá nhân, log, quyền truy cập hoặc API	Ngay khi phát hiện phạm vi ảnh hưởng	Security Owner; Legal/Compliance Owner

Khuyến nghị có thể phòng vệ phải nêu mức chắc chắn. Mẫu ghi nhận: “Khuyến nghị chọn phương án B cho màn hình xuất kho mô phỏng vì dữ liệu tác vụ cho thấy thao tác chờ là điểm nghẽn, còn Architect xác nhận phạm vi đo không gồm API hãng vận chuyển. Mức tin cậy: trung bình; thiếu kiểm thử tải ở môi trường mục tiêu. Quyết định cuối cùng thuộc Business Owner sau khi Architect và QA Owner xác nhận khả thi, khả năng đo.” Câu này ghi cầu nối giữa bằng chứng và kết luận, giữ phần chưa biết, và không biến đề xuất BA thành quyết định có thẩm quyền.

Senior Lens

Senior BA rà từng NFR bằng chuỗi: mục tiêu nghiệp vụ, rủi ro nếu không đạt, bằng chứng đo được, người có quyền quyết định. Không chấp nhận câu “hệ thống phải nhanh” vì không có ngưỡng, bối cảnh tải, cách đo, hay chủ sở hữu quyết định.

Heuristic rà soát	Dấu hiệu tốt	Red flag	Ngưỡng escalation	Không áp dụng quy tắc thường khi
Đo được	Có chỉ số, điểm đo, tập dữ liệu tổng hợp, điều kiện tải	“Nhanh”, “dễ dùng”, “an toàn” không có tiêu chí kiểm chứng	Không xác định được cách kiểm thử độc lập	Giai đoạn khám phá chỉ cần giả thuyết; ghi Verification required, không biến thành cam kết
Gắn rủi ro	NFR nối với mất doanh thu, gián đoạn, sai dữ liệu, lộ dữ liệu	Chọn ngưỡng theo sở thích cá nhân	Rủi ro ảnh hưởng dữ liệu cá nhân, tài chính, an toàn thực phẩm, hoặc truy xuất nguồn gốc	Quy định pháp lý, kế toán, an toàn thực phẩm cần Legal Owner, Accounting Owner hoặc domain owner xác minh; BA không tự suy diễn
Đúng phạm vi	Nêu rõ kênh, vai trò, giao dịch, tích hợp bị ảnh hưởng	Một ngưỡng áp cho mọi màn hình và API	NFR làm thay đổi kiến trúc, tích hợp, mô hình phân quyền, hoặc chi phí đáng kể	Thành phần nội bộ ít dùng có thể dùng ngưỡng khác nếu rủi ro và lý do được ghi rõ
Có chủ sở hữu	Business Owner chốt mức dịch vụ; Architect chốt khả thi kỹ thuật	BA tự chọn SLA hoặc tự tuyên bố tuân thủ	Hai vai trò có quyết định trái ngược; không có authority được chỉ định	Quyết định chỉ là giả định học liệu; giữ trạng thái IN_REVIEW, không gắn nhãn approved
Kiểm chứng được	Acceptance criteria nêu công cụ, dữ liệu, kết quả pass/fail	Chỉ có ý kiến demo hoặc ảnh chụp không tái lập	Bằng chứng không tái lập, dữ liệu test khác bối cảnh, hoặc kết quả mâu thuẫn	Không chạy performance test trước khi luồng và dữ liệu logic đủ ổn định; ghi giới hạn bằng chứng

Với Nova Foods mô phỏng, ví dụ NFR “tra cứu lô hàng trong 2 giây” chỉ đáng tin khi artifact nêu: người dùng nào, tra cứu bằng dữ liệu gì, tải đồng thời bao nhiêu, đo từ điểm nào đến điểm nào, và ai chấp nhận đánh đổi chi phí. Nếu thiếu một phần, Senior BA ghi đây là yêu cầu chưa đủ kiểm chứng, không tự điền số liệu tổng hợp để tạo cảm giác chắc chắn.

Escalation bắt buộc khi một NFR xung đột mục tiêu khác: Sales cần phản hồi nhanh nhưng Security yêu cầu kiểm soát truy cập mạnh; Operations cần màn hình đơn giản nhưng Compliance cần nhật ký truy vết; Finance cần dữ liệu bất biến nhưng người dùng cần sửa lỗi. BA phải tách xung đột thành lựa chọn, hậu quả và authority. Architect quyết định phương án kỹ thuật; Business Owner quyết định ưu tiên nghiệp vụ; Security quyết định chấp nhận rủi ro bảo mật; Legal Owner, Accounting Owner và domain owner xác minh diễn giải thuộc lĩnh vực của họ. Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì traceability, không thay vai trò chuyên môn.

Tình huống	Khuyến nghị Senior BA	Escalate đến
Mục tiêu phản hồi dưới 2 giây nhưng chưa có lưu lượng dự kiến	Ghi giả định, yêu cầu số liệu tải hoặc kịch bản tải tổng hợp	Business Owner, Architect
API trả dữ liệu có thông tin cá nhân	Phân loại dữ liệu, nêu nhu cầu kiểm soát; không tuyên bố tuân thủ pháp luật	Security, Legal Owner
Nhật ký audit làm giảm tốc độ xử lý	So sánh rủi ro mất truy vết với chi phí hiệu năng	Business Owner, Architect, Accounting Owner khi liên quan chứng từ
Yêu cầu “không mất dữ liệu”	Làm rõ loại dữ liệu, điểm khôi phục, thời gian khôi phục, lỗi được bao phủ	Business Owner, Architect, Operations
Nguồn luật hoặc chuẩn chưa kiểm chứng đủ	Gắn Verification required; không chuyển thành clause hoặc nghĩa vụ Nova Foods	Legal Owner, Compliance Owner, domain owner

Senior Lens

Không chắc chắn không phải lỗi cần che. Nó là trạng thái thiếu bằng chứng để chốt một yêu cầu phi chức năng (nonfunctional requirement, NFR), như hiệu năng, bảo mật, khả dụng hoặc khả năng truy vết. Senior BA tách rõ ba phần: fact là dữ kiện đã quan sát hoặc có nguồn; assumption là giả định dự án chưa kiểm chứng; recommendation là phương án đề xuất dựa trên fact và assumption. Không viết “hệ thống phải đáp ứng” nếu ngưỡng chưa có chủ sở hữu thẩm quyền xác nhận.

Với Nova Foods Trading & Manufacturing, đây là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Ví dụ: nhóm kỹ thuật nói màn hình tồn kho “cần nhanh”, nhưng chưa có đo tải, số người dùng đồng thời, hay ngưỡng chấp nhận từ Business Owner. Cầu nối suy luận là: từ mô tả “nhanh” không suy ra được số giây; thiếu số giây thì QA không tạo được kiểm thử pass/fail; vì vậy chưa thể ghi NFR bắt buộc.

Trường ghi nhận	Nội dung artifact-ready
Vấn đề	Ngưỡng thời gian phản hồi tra cứu tồn kho chưa xác định.
Fact	Có yêu cầu định tính “nhanh” từ trao đổi dự án; chưa có biên bản quyết định, dữ liệu tải, hoặc tiêu chí nghiệm thu.
Assumption	Dữ liệu mô phỏng dự kiến gồm tối đa 50.000 dòng tồn kho; giả định này chưa xác minh cho vận hành thực.
Uncertainty	Chưa biết tải đồng thời, phạm vi màn hình, mạng sử dụng, và percentile đo hiệu năng.
Recommendation	Giữ yêu cầu ở trạng thái cần quyết định; đề xuất đo phản hồi tại tải mô phỏng sau khi Architect xác định kiến trúc và Business Owner xác định mức chấp nhận.
Decision owner	Business Owner quyết định mức phục vụ nghiệp vụ; Architect xác nhận khả thi kỹ thuật; QA xác nhận cách đo và test basis.
Traceability	Liên kết quyết định với TRACEABILITY_ID_REGISTRY; không tự tạo ID ngoài registry.
Status	IN_REVIEW, version v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh.

Ngôn ngữ khuyến nghị phải nêu giới hạn: “Dựa trên dữ liệu mô phỏng hiện có, khuyến nghị chưa chốt ngưỡng phản hồi. Cần Business Owner xác định mức chấp nhận và Architect xác nhận khả thi trước khi biến thành acceptance criterion.” Câu này không biến giả định thành fact, không gán thẩm quyền cho BA, không nói đã được phê duyệt.

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

flowchart TB
    A[Fact có nguồn hoặc quan sát] --> B[Ghi assumption và uncertainty]
    B --> C[Khuyến nghị dựa trên bằng chứng hiện có; nêu giới hạn, tác động khi sai và điều kiện cập nhật]
    C --> D[Chuyển đến các vai trò liên quan]

    D --> E[Business Owner chốt mức chấp nhận]
    D --> F[Architect xác nhận khả thi kỹ thuật]
    D --> G[QA xác nhận cách đo và test basis]

    E --> H{Đã có mức chấp nhận, xác nhận khả thi và test basis?}
    F --> H
    G --> H

    H -- Chưa --> I[Giữ NFR ở IN_REVIEW; bổ sung bằng chứng hoặc thông tin còn thiếu]
    I --> B
    H -- Rồi --> J[Chốt ngưỡng thành acceptance criterion kiểm thử được]
    J --> K[Liên kết quyết định với TRACEABILITY_ID_REGISTRY; không tự tạo ID]
    K --> L[Ghi trạng thái theo quyết định thực tế; không ghi approval nếu chưa có xác nhận]

Khuyến nghị vẫn có thể hữu ích khi chưa đủ chắc chắn, nếu ghi rõ bằng chứng, phần chưa biết, tác động khi sai, người quyết định, và điều kiện cập nhật. CANONICAL_BUSINESS_RULES hay CANONICAL_DATA_DICTIONARY ở IN_REVIEW chỉ là nguồn quản trị đang xem xét; không là bằng chứng rằng quy tắc, dữ liệu, baseline, compliance hoặc approval đã tồn tại.

12. Associated Template Reference & Completed Artifact

Core

Template là biểu mẫu chuẩn để ghi nhận cùng loại thông tin theo cấu trúc lặp lại. Template không thay thế nguồn canonical. Nó chỉ chứa hoặc tham chiếu dữ liệu từ nguồn đó. Với Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, mọi dữ liệu dùng trong template là dữ liệu tổng hợp, trạng thái corpus là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND.

Không tự tạo Template ID hay filename. Bằng chứng: TEMPLATE_MANIFEST là nguồn quản trị danh mục template dự kiến; extract hiện có không cung cấp ID template hoặc tệp template cụ thể cho chapter này. Suy ra chapter chỉ được liên kết template khi ID và đường dẫn đã được đăng ký trong /01-curriculum/TEMPLATE_MANIFEST.md.

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

flowchart TB
    A[Chapter NFR] --> B[Kiểm tra TEMPLATE_MANIFEST]
    B --> C{Có Template ID và filename hoặc đường dẫn đã đăng ký?}
    C -- Có --> D[Tham chiếu đúng Template ID và filename hoặc đường dẫn]
    D --> E[Owner kiểm tra quality gate]
    E --> F[Template được liên kết với chapter]
    C -- Không --> G[Không tạo Template ID hoặc filename mới]
    G --> H[Chưa liên kết template cho chapter]
    H --> I[Giữ liên kết nguồn canonical]

Applied

Mục	Nội dung
Facts	TEMPLATE_MANIFEST tồn tại tại /01-curriculum/TEMPLATE_MANIFEST.md; extract được xác minh không nêu Template ID hoặc filename riêng cho NFR. CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY là artifact canonical có ID và đường dẫn xác định.
Current Behavior	Chapter NFR có thể tham chiếu artifact nguồn, nhưng không có căn cứ để gắn một template NFR cụ thể.
Underlying Need	Người viết cần biết dùng nguồn nào để ghi NFR, traceability và rule/data liên quan mà không biến artifact kế hoạch thành template đã tồn tại.
Options	1. Tự đặt Template ID và filename. 2. Chỉ trỏ tới TEMPLATE_MANIFEST để tìm template đã đăng ký. 3. Dùng artifact canonical như template thay thế.
Decision Criteria	Không đổi ID canonical; không bịa filename; giữ phân loại nguồn; không làm IN_REVIEW thành baseline hoặc approval.
Decision	Chọn phương án 2. Dùng artifact canonical làm nguồn tham chiếu, không gọi chúng là template.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết quản trị. Business Owner, Architect, QA, Legal Owner, Accounting Owner hoặc Security Owner xác nhận nội dung thuộc thẩm quyền tương ứng.
Artifact	/01-curriculum/TEMPLATE_MANIFEST.md là nơi tra Template ID và filename.
Consequence if Wrong	Template không đăng ký làm đứt traceability; filename sai dẫn người dùng tới nguồn không kiểm soát; gọi artifact IN_REVIEW là approved tạo kết luận quản trị sai.

Senior Lens

Quality gate là điểm kiểm soát chất lượng trước khi tham chiếu artifact. Gate tối thiểu gồm: ID đúng nguyên dạng, đường dẫn đúng, source classification đúng, owner đúng thẩm quyền, và trạng thái không bị diễn giải quá mức. Ví dụ, CANONICAL_BUSINESS_RULES có thể cung cấp rule nguồn cho NFR nghiệp vụ, nhưng không xác nhận rule đó đã đúng cho vận hành thực tế vì vẫn IN_REVIEW.

Không dùng template khi nhu cầu là quyết định pháp lý, kế toán, thuế, an toàn thực phẩm, kiến trúc, bảo mật hoặc vận hành thực tế chưa có owner chuyên môn xác nhận. Lý do: template chuẩn hóa cách ghi; không cấp thẩm quyền xác nhận nội dung. Các yêu cầu suy ra từ Luật Bảo vệ dữ liệu cá nhân, Luật Kế toán, Nghị định 123/2020/NĐ-CP hoặc Luật An toàn thực phẩm phải giữ nhãn Verification required đến khi Legal Owner, Accounting Owner hoặc domain owner xác minh nguồn hiện hành.

Quick Reference

Template ID / Artifact ID	Filename	Phân loại nguồn	Dùng khi	Không dùng khi	Owner quản trị	Consumer	Quality gate
TEMPLATE_MANIFEST	/01-curriculum/TEMPLATE_MANIFEST.md	Controlled planning artifact; danh mục template dự kiến	Cần tra Template ID, filename, dependency và phạm vi template đã đăng ký	Cần nội dung NFR canonical hoặc quyết định nghiệp vụ	Principal IT Business Analyst / Technical Curriculum Author	Handbook author, template author, QA reviewer	ID/filename phải được manifest đăng ký; IN_REVIEW không là baseline hay approval
TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Canonical identifier registry plan	Cần kiểm tra ID traceability đã được cấp và quy tắc escalation	Cần tự tạo ID mới trong chapter	Principal IT Business Analyst / Technical Curriculum Author	BA, QA reviewer, curriculum reviewer	Giữ nguyên ID; escalation khi ID tác động legal, accounting, security, architecture hoặc operations
CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Canonical rule catalog plan	NFR phụ thuộc business rule, điều kiện xử lý hoặc giới hạn nghiệp vụ	Xác nhận rule đã áp dụng production hoặc đã được phê duyệt	Principal IT Business Analyst / Technical Curriculum Author; nội dung do owner chuyên môn xác nhận	BA, Business Owner, QA, Architect	Rule phải giữ status nguồn; rule pháp lý/kế toán cần owner thẩm quyền xác minh
CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Canonical logical data dictionary plan	NFR liên quan dữ liệu, phân loại dữ liệu, trường dữ liệu hoặc chất lượng dữ liệu	Suy diễn schema triển khai, quyền truy cập thực tế hoặc compliance	Principal IT Business Analyst / Technical Curriculum Author; Security/Architect xác nhận phần thuộc thẩm quyền	BA, Architect, Security, QA	Không đổi tên dữ liệu; phân loại bảo mật và kiểm soát truy cập cần xác minh
Chưa có ID được cung cấp	Chưa có filename được cung cấp	Template NFR chưa xác minh trong extract hiện có	Chỉ liên kết sau khi TEMPLATE_MANIFEST đăng ký ID và file	Không tự đặt tên như NFR_TEMPLATE hoặc tạo file giả định	Principal IT Business Analyst / Technical Curriculum Author	Handbook author, QA reviewer	Không có ID/file đã đăng ký thì không ghi liên kết template cụ thể

Quick Reference

Checklist này tìm đúng nguồn cho từng phần chương, không sao chép registry canonical. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Trạng thái corpus: IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Mục cần tra trong chương	Nơi tra cứu canonical	Bằng chứng cần thấy trước khi dùng	Không được suy ra
Khái niệm NFR, Quality Attribute	BABOK Guide; ISO/IEC/IEEE 29148	Thuật ngữ dùng nhất quán với nguồn; không nêu số trang hay điều khoản chưa kiểm tra licensed text	NFR là yêu cầu đã được duyệt hoặc bắt buộc cho ERP thật
Mục tiêu chất lượng, trade-off	/01-curriculum/CHAPTER_MANIFEST.md	Phạm vi chapter 10 và dependency không mâu thuẫn curriculum	Quyết định kiến trúc, ngân sách, SLA production
ID requirement, ID rule, liên kết truy vết	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	ID tồn tại đúng chuỗi canonical; quan hệ traceability có nguồn	Tạo ID mới bằng biến thể tự đặt
Quy tắc nghiệp vụ ảnh hưởng NFR	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Rule được gắn nhãn trạng thái và authority phù hợp	Rule mô phỏng là quy định Nova Foods thật
Thuộc tính dữ liệu, phân loại dữ liệu	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tên entity, field, sensitivity và định nghĩa khớp artifact canonical	Schema vật lý, quyền DB, cấu hình ERP
API, tích hợp, HTTP	OpenAPI Specification OAS 3.1.1	Chỉ dùng khi ví dụ có API; HTTP behavior phải mô tả được kiểm thử	API contract đã tồn tại hoặc endpoint production
Bảo mật ứng dụng và API	OWASP ASVS 5.0.0; OWASP API Security Top 10 2023	Biện pháp có threat, phạm vi và Verification required khi chưa có authority	OWASP là luật Việt Nam hoặc xác nhận compliance
Khả năng truy cập	WCAG 2.2	Tiêu chí nêu đúng nguồn khi claim mức thành công cụ thể	Giao diện đã đạt WCAG nếu chưa có test evidence
Kiểm thử NFR	ISTQB CTFL Syllabus v4.0.1	Test basis, expected result, dữ liệu tổng hợp và tiêu chí pass/fail rõ	Test case đã chạy hoặc chất lượng đã được xác nhận
Dữ liệu cá nhân, kế toán, hóa đơn, an toàn thực phẩm	Nguồn luật trong /00-research/00_SOURCE_MAP.md	Mọi diễn giải ghi Verification required và có Legal Owner, Accounting Owner hoặc domain owner	Nghĩa vụ pháp lý, thuế, kế toán, truy xuất thực phẩm đã được kết luận

Artifact Nova Foods đã điền của chapter nằm tại /02-handbook/10-nonfunctional-requirements-and-quality-attributes.md, mục 8. Detailed Worked Example. Đây là vị trí đọc case đầy đủ gồm facts, hành vi hiện tại, nhu cầu nền, phương án, tiêu chí quyết định, quyết định mô phỏng, authority, artifact và hậu quả khi sai. Vị trí này là học liệu IN_REVIEW; không phải baseline, approval, cấu hình ERP, bằng chứng test hay quyết định vận hành.

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

flowchart TB
    A[Đọc claim NFR trong chapter] --> B{Claim thuộc loại nào?}

    B -->|ID, rule, data| C[Tra artifact canonical trong /01-curriculum/]
    B -->|Mục tiêu chất lượng, trade-off| M[Tra /01-curriculum/CHAPTER_MANIFEST.md]
    B -->|BABOK, ISO, OAS, WCAG hoặc ISTQB| D[Tra primary source phù hợp]
    B -->|Bảo mật ứng dụng hoặc API| S[Tra OWASP ASVS 5.0.0 hoặc OWASP API Security Top 10 2023]
    B -->|Pháp lý, dữ liệu cá nhân, kế toán, an toàn thực phẩm| E[Tra /00-research/00_SOURCE_MAP.md]

    C --> F[Đối chiếu case Nova Foods tại mục 8]
    M --> F
    D --> F

    S --> T{Có authority, threat và phạm vi?}
    T -->|Có| F
    T -->|Chưa đủ| U[Gắn Verification required; nêu threat, phạm vi và authority cần xác minh]
    U --> F

    E --> L[Gắn Verification required; ghi Legal Owner, Accounting Owner hoặc domain owner phù hợp]
    L --> F

    F --> Q{Đủ điều kiện dùng claim?}
    Q -->|Nguồn xác định được<br/>Phạm vi nguồn khớp claim<br/>Case không vượt thẩm quyền mô phỏng| R[Giữ claim trong học liệu và case]
    Q -->|Thiếu ID, file hoặc bằng chứng nguồn| X[Loại khỏi nội dung sử dụng; không tự suy diễn hoặc tạo ID, file, bằng chứng thay thế]
    Q -->|Phạm vi không khớp hoặc vượt thẩm quyền mô phỏng| X

    R --> V[Giữ trạng thái IN_REVIEW; không là approval, baseline, test evidence hoặc quyết định vận hành]

Quy tắc dùng checklist: claim chỉ được giữ khi nguồn xác định được, phạm vi nguồn khớp claim, và ví dụ Nova Foods không vượt thẩm quyền mô phỏng. Không tìm thấy ID, file hoặc bằng chứng nguồn thì không thay bằng nội dung tự suy diễn.

Core

Rà soát liên tệp kiểm tra cùng một thông tin giữa các nguồn canonical trước bàn giao chapter. Mục tiêu: phát hiện mâu thuẫn về ID, đường dẫn, trạng thái, version, source boundary và thẩm quyền. Bằng chứng: CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY đều ghi IN_REVIEW, v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh, Nova Foods là mô phỏng giáo dục và dữ liệu tổng hợp. Chapter không được nâng các giá trị này thành baseline, approval, compliance hay production-ready.

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

flowchart TB
    A[Rà soát chapter trước bàn giao] --> B[Đối chiếu CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY]
    B --> C[Kiểm tra ID, đường dẫn, trạng thái, version, source boundary, thẩm quyền]
    C --> D[Kiểm tra IN_REVIEW, v0.9.0, 2026-08-07, Asia/Ho_Chi_Minh]
    D --> E[Kiểm tra Nova Foods là mô phỏng giáo dục và dữ liệu tổng hợp]
    E --> F{Chapter có nâng dữ liệu thành baseline, approval, compliance hoặc production-ready?}
    F -- Có --> G[Không bàn giao chapter]
    F -- Không --> H{Mọi thông tin canonical có khớp?}
    H -- Không --> G
    H -- Có --> I[Bàn giao chapter ở trạng thái IN_REVIEW]

Applied

Facts: Chapter thuộc /02-handbook/10-nonfunctional-requirements-and-quality-attributes.md; Nova Foods Trading & Manufacturing là case mô phỏng; mọi dữ liệu là tổng hợp; corpus đang IN_REVIEW, v0.9.0, ngày 2026-08-07.

Current Behavior: NFR có thể tham chiếu bảo mật, khả dụng, hiệu năng, accessibility và dữ liệu cá nhân. Các chủ đề này vượt thẩm quyền một mình của BA khi biến thành yêu cầu triển khai hoặc kết luận tuân thủ.

Underlying Need: Bàn giao cần giữ traceability nhưng không biến giả định học liệu thành cam kết ERP thực tế.

Options: (1) Chỉ kiểm tra chapter; (2) kiểm tra chapter với artifact canonical liên quan; (3) tự kết luận thay owner chuyên môn. Chọn (2), vì (1) bỏ sót mâu thuẫn liên tệp, còn (3) vi phạm ranh giới thẩm quyền.

Decision Criteria: Giữ đúng ID và filename canonical; không gán approval; phân biệt project assumption với Verification required; escalation đúng vai trò.

Decision: Thực hiện bảng kiểm dưới đây trước handoff. Bất kỳ dòng “Không khớp” hoặc “Verification required” nào phải giữ trong chapter hoặc gói escalation.

Authority: Principal IT Business Analyst / Technical Curriculum Author điều phối review và traceability. Legal Owner, Accounting Owner, Security Owner, Architect, QA Reviewer, Business Owner giữ thẩm quyền kết luận chuyên môn theo phạm vi.

Artifact: /02-handbook/10-nonfunctional-requirements-and-quality-attributes.md, section 12, trạng thái IN_REVIEW, version v0.9.0.

Consequence if Wrong: Sai ID làm đứt truy vết; gọi IN_REVIEW là approved tạo sai quản trị; tự diễn giải luật hoặc chuẩn tạo rủi ro pháp lý, kế toán, bảo mật hoặc vận hành.

Senior Lens

Hạng mục review	Bằng chứng phải đối chiếu	Kết quả cần ghi	Escalation owner khi lỗi
Metadata chapter	CHAPTER_MANIFEST; /01-curriculum/CHAPTER_MANIFEST.md	Status IN_REVIEW; Version v0.9.0; ngày 2026-08-07	Principal IT Business Analyst / Technical Curriculum Author
Template hoặc artifact được nêu	TEMPLATE_MANIFEST; /01-curriculum/TEMPLATE_MANIFEST.md	Không đổi ID, filename, phân loại nguồn	Principal IT Business Analyst / Technical Curriculum Author
Traceability	TRACEABILITY_ID_REGISTRY; /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Không tạo biến thể ID; liên kết giữ ID canonical	Principal IT Business Analyst / Technical Curriculum Author
Business rule	CANONICAL_BUSINESS_RULES; /01-curriculum/CANONICAL_BUSINESS_RULES.md	Không diễn đạt rule mô phỏng thành rule vận hành	Business Owner; Principal IT Business Analyst / Technical Curriculum Author
Data và privacy	CANONICAL_DATA_DICTIONARY; Luật 91/2025/QH15; Nghị định 356/2025/NĐ-CP	Gắn Verification required cho diễn giải nghĩa vụ pháp lý	Legal Owner; Compliance Owner
Security NFR	OWASP ASVS 5.0.0; OWASP API Security Top 10 2023	Không gọi good practice là luật hoặc compliance chứng nhận	Security Owner
API, architecture, integration	OpenAPI Specification OAS 3.1.1; UML 2.5.1	Không xác nhận thiết kế hoặc triển khai ERP	Architect
Quality và testability	ISTQB CTFL Syllabus v4.0.1; ISO/IEC/IEEE 29148:2018	NFR phải kiểm thử được hoặc gắn verification method	QA Reviewer
Accessibility	WCAG 2.2	Không tuyên bố đạt WCAG khi chưa có bằng chứng kiểm thử	Accessibility Owner; QA Reviewer
Accounting, invoice, tax	Luật 88/2015/QH13; Nghị định 123/2020/NĐ-CP	Không suy diễn nghĩa vụ accounting hoặc hóa đơn	Accounting Owner; Legal Owner
Food safety, recall, traceability	Luật 55/2010/QH12	Không xác nhận tuân thủ an toàn thực phẩm	Food Safety Domain Owner; Legal Owner

Open issues trước handoff: chưa có baseline reference; chưa có approval reference; ISO/IEC/IEEE 29148 exact clauses cần licensed-text verification; mọi yêu cầu bắt nguồn từ luật Việt Nam cần Legal Owner xác minh; mọi chỉ tiêu hiệu năng, availability, recovery, retention và security control của Nova Foods chỉ là giả định học liệu nếu chưa có Business Owner, Architect, Security Owner hoặc QA Reviewer xác nhận.

Verification-required items: hiệu lực sửa đổi sau Nghị định 123/2020/NĐ-CP; áp dụng thực tế của Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP; ngưỡng NFR có thể đo; dữ liệu nào là dữ liệu cá nhân; cơ chế kiểm thử WCAG 2.2; phạm vi OWASP ASVS 5.0.0; thiết kế API theo OAS 3.1.1. Không đóng các điểm này bằng suy luận từ case mô phỏng.

Quick Reference

Điều kiện handoff	Đạt khi	Không đạt khi
Cross-file consistency	ID, filename, status, version, locale và source classification khớp artifact canonical	Có biến thể ID, đường dẫn không canonical, hoặc trạng thái bị nâng cấp
Source boundary	Chuẩn dùng đúng safe use boundary; luật có nhãn Verification required khi chưa có owner xác minh	Gán clause, nghĩa vụ pháp lý, compliance hoặc certification không có bằng chứng
Open issue register	Open issue, verification-required item và escalation owner được ghi rõ	Im lặng bỏ qua điểm chưa xác minh
Handoff state	Chapter vẫn là IN_REVIEW; Nova Foods vẫn là mô phỏng, dữ liệu tổng hợp	Ghi approved, baselined, production-ready hoặc user-approved