# 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 | [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 | |---|---|---|---|---|---|