sys-analysis-design/.claude/skills/sa-2-architecture/templates/quality-scenarios.md

QAS + ASR — Quality Attribute Scenarios & Architecturally Significant Requirements —

Version	1.0
Date	YYYY-MM-DD
Author	(skill sa-2-architecture)
Status	🟡 Draft
Approved by	Tech Lead: — · QA: — · SRE: —
Source	CTX_… v1.0 · OPT_… v1.0 · BRIEF §NFR của BA
Scope
Confidence	🟡

Change Log

Version	Date	Người sửa	Thay đổi	ADR/DEC
1.0			Bản đầu	—

🔴 Tài liệu này là nền của cả GĐ2. Sơ đồ vẽ trước khi có con số ở đây sẽ được bảo vệ bằng mọi giá về sau, kể cả khi con số nói nó sai.

---

PHẦN A — Quality Attribute Scenarios

A1. Tóm tắt

Nhóm thuộc tính	Số QAS	Must	Đã có cách đo	Đã đo thật
Hiệu năng
Thông lượng
Sẵn sàng
Mở rộng
Bảo mật
Bảo trì
Quan sát được

Nhóm không áp dụng: (ghi rõ nhóm nào và vì sao — không được bỏ trống)

A2. Mẫu một QAS

Sáu phần, thiếu phần nào cũng làm QAS không dùng được ở AG3.

QAS-nnn | <tên ngắn>                                     [Must|Should|Could]
  Nguồn kích thích : ai/cái gì gây ra
  Kích thích       : sự kiện gì, với khối lượng bao nhiêu
  Môi trường       : trạng thái hệ thống lúc đó (bình thường / cao điểm / đang lỗi một phần)
  Phản hồi         : hệ thống phải làm gì
  Đo lường         : con số + phân vị + đơn vị
  Đo bằng cách nào : tên bài đo · môi trường · bộ dữ liệu · tần suất chạy
  Ai đo            : vai trò
  Nguồn            : DRV-nn / CON-nn / BR-nnn / NFR-nn của BA

A3. Danh sách QAS

Hiệu năng

ID	Tên	Kích thích + môi trường	Đo lường	Đo bằng cách nào	Ai đo	Mức	Nguồn
QAS-001			p95 ≤ … ms		QA	Must	DRV-01

🔴 Luôn ghi phân vị, không ghi trung bình. Trung bình che giấu đuôi, và người dùng khó chịu nằm ở đuôi.

Thông lượng

ID	Tên	Kích thích + môi trường	Đo lường	Đo bằng cách nào	Ai đo	Mức	Nguồn

🔴 Ghi cả trung bình và đỉnh. Đỉnh mới là thứ định hình kiến trúc.

Sẵn sàng

ID	Mục tiêu	Ngân sách lỗi	Phạm vi tính	Không tính vào	Đo bằng cách nào	Mức
QAS-0nn	99.9%/tháng	43 phút/tháng	API công khai	bảo trì có báo trước ≤ 2h/tháng	uptime check …	Must

🔴 Quy % ra phút. 99.9% và 99.99% nghe giống nhau nhưng chênh 10× về chi phí. Hỏi PO bằng hệ quả: "Hệ thống dừng 43 phút vào ngày chốt sổ thì chuyện gì xảy ra?"

Mở rộng

ID	Tải hôm nay	Tải mục tiêu	Trong bao lâu	Scale bằng cách nào	Giới hạn trên	Mức

Bảo mật

ID	Mối đe doạ	Yêu cầu	Kiểm chứng bằng cách nào	THR-nn liên quan	Mức

Không ghi "bảo mật" như một mục. Mỗi dòng phải nêu một mối đe doạ cụ thể và cách kiểm chứng.

Bảo trì

ID	Kịch bản	Đo lường	Đo bằng cách nào	Mức
QAS-0nn	Dev mới onboard	Sửa được một bug thật ≤ 3 ngày	Đo trên người thật, lần tuyển gần nhất	Should

Không đo được ⇒ bỏ hẳn, đừng ghi định tính. Một QAS không đo được làm loãng cả danh sách.

Quan sát được

ID	Kịch bản	Đo lường	Đo bằng cách nào	Mức
QAS-0nn	Sự cố 5xx tăng đột biến	Cảnh báo trong ≤ 3 phút	Diễn tập inject lỗi trên stg	Must

Nhóm này bị quên nhiều nhất, và là nhóm quyết định thời gian khôi phục khi có sự cố thật.

A4. QAS xung đột nhau

Thuộc tính chất lượng luôn đánh đổi. Chỗ xung đột phải được nêu và PO chọn, không phải SA âm thầm cân bằng.

QAS A	QAS B	Xung đột ở đâu	Phương án cân bằng	Ai quyết	ADR
QAS-005 độ chính xác tuyệt đối	QAS-001 p95 ≤ 300ms	Kiểm tra đồng bộ làm chậm ghi		PO	ADR-nnn

---

PHẦN B — Architecturally Significant Requirements

B1. Tiêu chí một yêu cầu là ASR

Có ≥ 1 điều sau:

• Ép một cấu trúc (buộc phải có hàng đợi, cache, service riêng…)
• Ép một ràng buộc không đảo ngược (lãnh thổ dữ liệu, vendor, mô hình license)
• Ép một đánh đổi (loại bỏ eventual consistency ở một nhánh)
• Có QAS mức Must đứng sau

Thường 8–15 mục cho một hệ thống trung bình. Danh sách 200 mục nghĩa là chưa lọc.

B2. Danh sách ASR

ID	Phát biểu	Nguồn	Ép ra cấu trúc gì	ADR hiện thực hoá	Trạng thái
ASR-001	Hệ thống phải tiếp tục nhận giao dịch khi POS ngoài mất kết nối ≤ 4 giờ	DRV-01, QAS-007	Hàng đợi bền + cơ chế phát lại	ADR-005	Đã thiết kế
ASR-002	Dữ liệu cá nhân phải lưu trong lãnh thổ …	CON-05 (pháp lý)	Ràng buộc vùng cho mọi dịch vụ lưu trữ	ADR-003	Đã thiết kế

Trạng thái: Đã ghi nhận · Đã thiết kế (ADR tồn tại) · Đã kiểm chứng (có bài đo/FIT)

🔴 ASR không có ADR nào hiện thực hoá ⇒ chặn AG2. Đó là yêu cầu định hình kiến trúc mà không ai quyết định gì về nó.

B3. Ma trận ASR × CMP

Điền sau khi có SAD. Ô đánh dấu = component này tồn tại (một phần) vì ASR đó.

	CMP-01	CMP-02	CMP-03
ASR-001	●		●
ASR-002		●

Component không phục vụ ASR nào ⇒ hỏi lại: nó tồn tại vì lý do gì? Có thể hợp lệ (nhu cầu chức năng thuần), nhưng phải trả lời được.

---

C. Đối chiếu với NFR của bộ BA

NFR của BA	Nội dung gốc	QAS tương ứng	Đã lượng hoá	Hành động
NFR-01	"màn hình phải nhanh"	QAS-001	✅	BA cập nhật SRS tham chiếu QAS-001
NFR-05	"dễ bảo trì"	—	❌	Đề xuất bỏ hoặc đổi thành QAS-0nn đo được

QAS thắng khi lệch (quy tắc ở ../../sa-lifecycle/references/artifact-map.md §7). Mọi dòng lệch phải báo lại cho BA cập nhật SRS.

D. Giả định & Ngoài phạm vi

Giả định:

ID	Giả định	Cách xác minh	Nếu sai thì QAS nào đổi

Ngoài phạm vi:

• (ví dụ: kiến trúc này không nhắm tới tải × 100; ngưỡng phải xét lại là … giao dịch/giờ)

E. Open Questions

ID	Câu hỏi	Hỏi ai	Từ ngày	Chặn gì	Hệ quả nếu trả lời ngược