7.3 KiB
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ó
QASmứ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 |
|---|