genneral/sys-analysis-design
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

init git

Browse Source
This commit is contained in:
Leonard-ThindPad-P50
2026-09-08 10:26:21 +07:00
commit c81f249920
169 changed files with 38726 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

208
.claude/skills/ba-2-analysis/templates/business-rules.md Normal file
View File

@@ -0,0 +1,208 @@
# BR — Business Rules — <Tên module>
| | |
|---|---|
| **Version** | 1.0 |
| **Date** | YYYY-MM-DD |
| **Author** | <BA> (skill ba-2-analysis) |
| **Status** | 🟡 Draft |
| **Approved by** | — |
| **Source** | |
| **Scope** | |
## Change Log
| Version | Date | Người sửa | Thay đổi | CR |
|---|---|---|---|---|
---
## 1. Danh sách quy tắc
> **Rule sống độc lập với user story.** Cùng một rule thường chi phối nhiều US; nhét rule
> vào mô tả US thì sửa một chỗ sẽ quên chín chỗ.
### BR-001 — <tên ngắn>
| | |
|---|---|
| **Loại** | Ràng buộc dữ liệu / Điều kiện hành động / Tính toán / Quy trình-phê duyệt |
| **Nguồn** | 🔴 Quy định pháp luật / 🟠 Hợp đồng-chính sách / 🟢 Thói quen nội bộ |
| **Người chốt** | STK-nn, ngày… |
| **RQ** | RQ-007 |
| **US áp dụng** | US-011, US-013 |
| **Khi vi phạm** | Chặn / Cảnh báo cho qua / Chỉ ghi log |
| **Có ngoại lệ** | Không / Có — ai được cho phép: … |
| **Có thể đổi trong 1 năm** | Có / Không |
**Phát biểu:**
> *(một câu, một quy tắc — quy tắc W1)*
**Điều kiện áp dụng:** *(khi nào rule này có hiệu lực)*
**Ví dụ đúng / sai:**
| Trường hợp | Dữ liệu | Kết quả mong đợi |
|---|---|---|
| Hợp lệ | | Cho qua |
| Vi phạm | | Chặn, báo `E-XXX-0001` |
| Biên | | |
---
**Cột `Nguồn` quyết định độ cứng của rule:**
| Nguồn | Được đề xuất bỏ/sửa không |
|---|---|
| 🔴 Quy định pháp luật | Không. Chỉ tuân thủ, và phải ghi rõ điều khoản nào |
| 🟠 Hợp đồng / chính sách công ty | Có, nhưng phải qua cấp ký hợp đồng/chính sách |
| 🟢 Thói quen nội bộ | Có — và **nên hỏi** khi nó đang cản trở, vì thường không ai nhớ vì sao có |
## 2. Bảng tổng hợp
| ID | Tên | Loại | Nguồn | US áp dụng | Khi vi phạm | Mã lỗi (GĐ3) |
|---|---|---|---|---|---|---|
| BR-001 | | | 🔴 | US-011 | Chặn | E-STL-0001 |
## 3. Vòng đời trạng thái
*Bắt buộc với mọi thực thể có trạng thái (quy tắc W6).*
### Thực thể: `<tên>`
**Bốn câu phải trả lời:**
| Câu hỏi | Trả lời |
|---|---|
| Trạng thái khởi tạo | |
| Trạng thái cuối (không đi tiếp được) | |
| Từ trạng thái cuối quay lại được không | |
| Trạng thái nào cho phép xoá | |
**Sơ đồ:**
```mermaid
stateDiagram-v2
state "Nháp" as Nhap
state "Chờ duyệt" as ChoDuyet
state "Đã duyệt" as DaDuyet
state "Đã đóng" as DaDong
[*] --> Nhap
Nhap --> ChoDuyet: gửi duyệt (đủ trường bắt buộc)
ChoDuyet --> DaDuyet: duyệt
ChoDuyet --> Nhap: từ chối
DaDuyet --> DaDong: đóng (có ghi chú lý do)
DaDong --> [*]
```
*ID trạng thái không dấu, nhãn có dấu — xem `../../ba-lifecycle/references/diagram-rules.md` §1.*
**Bảng chuyển trạng thái:**
| # | Nguồn | Sự kiện | Điều kiện | Đích | Ai được làm | BR | Ghi vết |
|---|---|---|---|---|---|---|---|
| 1 | Nháp | Gửi duyệt | Đã điền đủ trường bắt buộc | Chờ duyệt | Người tạo | BR-005 | ✅ |
**Chuyển trạng thái KHÔNG được phép** *(ghi ra để dev biết mà chặn):*
| Từ | Sang | Vì sao cấm |
|---|---|---|
| Đã đóng | Nháp | Mất dấu vết đối soát |
## 4. Mô hình dữ liệu khái niệm (ERD)
🔴 **Mục bắt buộc khi US có từ 2 thực thể trở lên.** Không có nó, dev tự suy ra quan hệ giữa
các thực thể từ những bảng field rời rạc của từng màn hình — và mỗi người suy một kiểu.
```mermaid
erDiagram
CUA_HANG ||--o{ GIAO_DICH : "phát sinh"
GIAO_DICH ||--o| CHENH_LECH : "sinh ra khi lệch"
NGUOI_DUNG ||--o{ CHENH_LECH : "xử lý"
CUA_HANG {
string ma_cua_hang PK "3-20 ký tự"
string ten
enum trang_thai
}
GIAO_DICH {
bigint id PK
string ma_cua_hang FK
decimal so_tien "VND"
datetime thoi_diem "UTC"
}
CHENH_LECH {
bigint id PK
bigint giao_dich_id FK
decimal so_tien "VND"
enum trang_thai
}
```
*Tên thực thể **không dấu, viết hoa**; tên tiếng Việt để ở bảng §4.1. Ký hiệu lực lượng:
`||--o{` một-nhiều · `||--||` một-một · `||--o|` một-không hoặc một · `}o--o{` nhiều-nhiều.*
🔴 **Đây là mô hình khái niệm, không phải schema.** Nêu thực thể, quan hệ, khoá nghiệp vụ.
**Không** nêu kiểu dữ liệu vật lý, index, bảng trung gian, chiến lược phân mảnh — đó là việc
của Solution Architect và dev.
### 4.1 Bảng thực thể *(bắt buộc đi kèm sơ đồ — quy tắc W13)*
| Thực thể | Tên nghiệp vụ | Khoá nghiệp vụ | Số bản ghi hiện có | Ai tạo | Vòng đời | BR |
|---|---|---|---|---|---|---|
| `CUA_HANG` | Cửa hàng | `ma_cua_hang` | ~1.200 | Admin | §3 | BR-021 |
**Khoá nghiệp vụ** là thứ người dùng dùng để nhận biết, không phải id kỹ thuật. Nó quyết
định quy tắc chống trùng — thiếu cột này thì rule "không được trùng" không có nghĩa.
### 4.2 Quan hệ cần làm rõ
*Sơ đồ chỉ vẽ được lực lượng. Bốn câu sau phải trả lời bằng chữ:*
| Quan hệ | Xoá bên "một" thì bên "nhiều" ra sao | Bắt buộc có quan hệ? | Đổi được sang bên khác? | BR |
|---|---|---|---|---|
| `CUA_HANG` → `GIAO_DICH` | Chặn xoá nếu còn giao dịch | ✅ giao dịch luôn thuộc 1 cửa hàng | ❌ | BR-006 |
### 4.3 Thực thể ngoài phạm vi
*Thực thể có nhắc tới nhưng do hệ thống khác sở hữu — nêu rõ để không ai định tạo bảng cho nó.*
| Thực thể | Ai sở hữu | Lấy về bằng cách nào | Cache không |
|---|---|---|---|
## 5. Công thức tính toán
| ID | Đại lượng | Công thức | Đơn vị | Làm tròn | Nguồn dữ liệu | Ví dụ |
|---|---|---|---|---|---|---|
| BR-0nn | Chênh lệch | tổng POS − tổng hệ thống | VND | Tới đơn vị, làm tròn xuống | | 1.234.567 − 1.234.000 = 567 |
🔴 Ghi rõ: **thứ tự phép tính**, **làm tròn ở bước nào** (làm tròn từng dòng rồi cộng ≠ cộng
rồi làm tròn), **múi giờ** với mọi mốc thời gian, **tiền tệ** với mọi số tiền.
## 6. Kiểm tra mâu thuẫn giữa các rule
*Đối chiếu từng cặp rule cùng tác động lên một thực thể.*
| # | Rule A | Rule B | Mâu thuẫn ở đâu | Trạng thái |
|---|---|---|---|---|
| 1 | BR-003 | BR-011 | | 🔴 Chờ PO quyết — OQ-0nn |
Không tự chọn bên nào. Đưa PO quyết, ghi vào `DEC-nn`.
## 7. Rule của hệ thống hiện tại bị thay đổi
*Chỉ dùng khi làm enhancement.*
| Rule cũ | Đang áp dụng ở đâu | Đổi thành | Dữ liệu cũ theo rule cũ xử lý sao |
|---|---|---|---|
## 8. Open Questions
| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì |
|---|---|---|---|---|
## 9. Ngoài phạm vi
- Thông điệp lỗi hiển thị nguyên văn → GĐ3 `SRS` §bảng mã lỗi
- Ai được thực hiện hành động → `RBAC_…md`

137
.claude/skills/ba-2-analysis/templates/impact-analysis.md Normal file
View File

@@ -0,0 +1,137 @@
# IMPACT — Phân tích tác động — <US / Module>
| | |
|---|---|
| **Version** | 1.0 |
| **Date** | YYYY-MM-DD |
| **Author** | <BA> (skill ba-2-analysis) |
| **Status** | 🟡 Draft |
| **Approved by** | — *(cần Tech Lead xác nhận)* |
| **Source** | |
| **Scope** | |
## Change Log
| Version | Date | Người sửa | Thay đổi | CR |
|---|---|---|---|---|
---
## 0. Kết luận
| | |
|---|---|
| **Mức tác động tổng thể** | 🔴 Lớn / 🟠 Trung bình / 🟢 Nhỏ |
| **Số hạng mục 🔴** | |
| **Cần migrate dữ liệu** | Có / Không |
| **Cần phối hợp bên thứ ba** | Có / Không — bên nào |
| **Rủi ro lớn nhất** | |
*Viết mục này sau cùng. Đây là mục Tech Lead và PM đọc.*
---
## 1. Sáu trục rà soát
> Rà đủ sáu trục. Trục nào không có tác động vẫn phải ghi *"đã rà, không phát hiện"* kèm
> phạm vi đã rà. **"Đã rà và không thấy" khác hoàn toàn "chưa rà".**
### 1.1 Màn hình / chức năng hiện có
| Màn hình/chức năng | Đường dẫn | Tác động | Mức | Phương án | Ai xác nhận |
|---|---|---|---|---|---|
| | | | 🔴/🟠/🟢 | | |
*Cách kiểm tra: tra bản đồ màn hình, grep route/tên component, hỏi dev từng làm module đó.*
**Đã rà:** … *(nêu phạm vi: repo nào, thư mục nào, tài liệu nào)*
### 1.2 Dữ liệu
| Bảng/thực thể | Thay đổi | Số bản ghi hiện có | Dữ liệu cũ xử lý thế nào | Mức | Ai xác nhận |
|---|---|---|---|---|---|
| | Thêm cột X | ~120.000 | Điền mặc định `Y` cho bản ghi cũ | 🟠 | |
🔴 **Dữ liệu cũ luôn phải chọn một trong ba, kèm lý do. "Xử lý sau" không phải câu trả lời:**
| Lựa chọn | Khi nào phù hợp | Chi phí kèm theo |
|---|---|---|
| **Giữ nguyên** | Dữ liệu cũ không cần theo rule mới | Chấp nhận dữ liệu không đồng nhất — phải ghi rõ cho QA và người dùng |
| **Migrate** | Cần đồng nhất để báo cáo/đối soát đúng | Script + kịch bản rollback + **đối chiếu sau khi chạy** |
| **Song song** | Rule đổi từ một mốc thời gian | Cần quy tắc phân biệt rõ ràng, hiển thị được cho người dùng |
**Nếu migrate:**
| | |
|---|---|
| Số bản ghi cần chuyển | |
| Cách đối chiếu sau khi chạy | |
| Kịch bản rollback | |
| Thời gian dừng hệ thống dự kiến | |
| Ai duyệt kết quả migrate | |
### 1.3 Business rule
| BR hiện hành | Bị ảnh hưởng thế nào | Mâu thuẫn với rule mới? | Xử lý | Mức |
|---|---|---|---|---|
### 1.4 Phân quyền
| Vai trò | Thay đổi quyền | Ai bị mất quyền | Đã thông báo | Mức |
|---|---|---|---|---|
### 1.5 Tích hợp / hệ thống ngoài
| Hệ thống | Điểm chạm | Thay đổi | Đầu mối bên kia | Cần bên kia làm gì | Hạn | Mức |
|---|---|---|---|---|---|---|
**Nếu bên kia lỗi hoặc chậm thì nghiệp vụ này xử lý thế nào?** *(bắt buộc trả lời)*
### 1.6 Báo cáo / đối soát
| Báo cáo | Số liệu nào đổi | Đổi từ khi nào | Ai dùng báo cáo này | Đã báo chưa | Mức |
|---|---|---|---|---|---|
🔴 Đổi cách tính một chỉ số mà không báo người dùng báo cáo là cách nhanh nhất để mất niềm
tin vào hệ thống: họ thấy số nhảy và nghĩ hệ thống sai.
---
## 2. Tác động lên người dùng và vận hành
| Vai trò | Thay đổi trong công việc | Cần đào tạo | Cần thông báo trước | Mức kháng cự dự kiến |
|---|---|---|---|---|
## 3. Tác động lên phi chức năng
| Khía cạnh | Tác động | Ngưỡng hiện tại | Ngưỡng sau thay đổi | Cần đo lại |
|---|---|---|---|---|
| Hiệu năng | | | | ☐ |
| Dung lượng lưu trữ | | | | ☐ |
| Bảo mật / tuân thủ | | | | ☐ |
## 4. Thứ tự triển khai bắt buộc
*Cái gì phải xong trước cái gì, và vì sao.*
| # | Việc | Phải xong trước | Vì sao | Ai làm |
|---|---|---|---|---|
| 1 | Migrate dữ liệu | Bật tính năng mới | Rule mới áp lên dữ liệu cũ sẽ sai | |
## 5. Phạm vi hồi quy đề xuất cho QA
| Khu vực cần test lại | Vì sao | Ưu tiên |
|---|---|---|
## 6. Open Questions
| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì |
|---|---|---|---|---|
## 7. Xác nhận
| Vai trò | Người | Xác nhận nội dung | Ngày |
|---|---|---|---|
| Tech Lead | | ☐ Khả thi, đã rà đủ | |
| QA | | ☐ Phạm vi hồi quy hợp lý | |
| PO | | ☐ Chấp nhận tác động lên người dùng | |

173
.claude/skills/ba-2-analysis/templates/process-model.md Normal file
View File

@@ -0,0 +1,173 @@
# PROCESS — Quy trình AS-IS / TO-BE — <Tên quy trình>
| | |
|---|---|
| **Version** | 1.0 |
| **Date** | YYYY-MM-DD |
| **Author** | <BA> (skill ba-2-analysis) |
| **Status** | 🟡 Draft |
| **Approved by** | — |
| **Source** | BRIEF_… v1.0 · ELICITATION_… |
| **Scope** | |
## Change Log
| Version | Date | Người sửa | Thay đổi | CR |
|---|---|---|---|---|
---
## 1. Phạm vi quy trình
| | |
|---|---|
| **Tên quy trình** | |
| **Điểm bắt đầu** | *(sự kiện gì kích hoạt)* |
| **Điểm kết thúc** | *(kết quả gì thì coi là xong)* |
| **Tần suất** | *(mỗi ngày / mỗi giao dịch / cuối tháng…)* |
| **Khối lượng** | *(bao nhiêu lượt mỗi kỳ)* |
| **Vai trò tham gia** | |
---
# PHẦN A — AS-IS (hiện trạng)
## A1. Sơ đồ luồng
```mermaid
flowchart TD
START(["Sự kiện kích hoạt: …"]) --> A1["A1. &lt;việc&gt; · &lt;vai trò&gt; · ⏱ …"]
A1 --> A2["A2. &lt;việc&gt; · &lt;vai trò&gt; · ⏱ …"]
A2 --> D1{"&lt;điều kiện&gt;?"}
D1 -->|Có| A4["A4. …"]
D1 -->|Không| A3["⚠️ P1 · A3. &lt;việc&gt; · ⏱ …"]
A3 --> EXT[["📄 Gọi điện / file Excel thủ công"]]
EXT --> A2
A4 --> END(["Kết thúc: …"])
```
**Quy ước hình dạng** *(không tô màu — xem `diagram-rules.md` §3)*:
| Hình | Cú pháp | Nghĩa |
|---|---|---|
| Bo tròn | `(["…"])` | Bắt đầu / kết thúc |
| Chữ nhật | `["…"]` | Bước xử lý |
| Thoi | `{"…"}` | Điểm quyết định |
| Khung đôi | `[["…"]]` | Ngoài hệ thống / làm thủ công |
Đánh dấu bằng **tiền tố trong nhãn**: `⚠️ P1 ·` điểm đau · `🔁` làm lại · `📄` file thủ công.
🔴 ID node (`A1`, `D1`) phải **khớp cột `#` của bảng A2** — đó là thứ nối sơ đồ với bảng (W13).
## A2. Bảng chi tiết từng bước
| # | Bước | Ai làm | Input | Output | Công cụ | ⏱ Thời gian | Ghi chú |
|---|---|---|---|---|---|---|---|
| A1 | | | | | | | |
| A2 | | | | | | | |
**Tổng thời gian một lượt:** … · **Số người liên quan:** …
Cột **⏱ Thời gian** là cột chỉ ra chỗ đáng tự động hoá. Không có nó thì TO-BE chỉ là ý kiến.
## A3. Điểm đau
| ID | Bước | Vấn đề | Tần suất | Hậu quả đo được | → RQ |
|---|---|---|---|---|---|
| P1 | A3 | | | | RQ-0nn |
## A4. Đường tắt / cách làm ngoài quy trình
*Chỗ người ta lách quy trình. **Mỗi đường tắt là một nhu cầu hệ thống chưa đáp ứng** — đây
là spec ẩn, đừng bỏ qua.*
| # | Ai làm | Làm gì ngoài quy trình | Vì sao phải làm vậy | Ẩn ý về yêu cầu |
|---|---|---|---|---|
| 1 | | *(vd: giữ file Excel riêng)* | | |
## A5. Ngoại lệ
| # | Ca ngoại lệ | Tần suất | Hiện xử lý thế nào | Ai xử lý | TO-BE có xử lý? |
|---|---|---|---|---|---|
| E1 | | …/tháng | | | ☐ |
🔴 Mọi dòng ở đây phải có câu trả lời ở cột cuối. Ngoại lệ bị bỏ quên ở GĐ2 sẽ quay lại
thành defect ở UAT.
## A6. Hệ thống & dữ liệu đang dùng
| Hệ thống | Vai trò trong quy trình | Ai quản trị | Dữ liệu liên quan |
|---|---|---|---|
---
# PHẦN B — TO-BE (đề xuất)
## B1. Sơ đồ luồng
```mermaid
flowchart TD
START(["Sự kiện kích hoạt: …"]) --> B1["🆕 B1. &lt;việc&gt; · &lt;vai trò&gt; · ⏱ …"]
B1 --> B2["⬜ B2. &lt;việc&gt; · &lt;vai trò&gt;"]
B2 --> D1{"&lt;điều kiện&gt;?"}
D1 -->|Có| B3["🔄 B3. &lt;việc, đã đổi cách làm&gt;"]
D1 -->|Không| END(["Kết thúc"])
B3 --> END
```
*Đánh dấu mỗi bước bằng **tiền tố trong nhãn**: `🆕 MỚI` · `🔄 ĐỔI` · `⬜ GIỮ NGUYÊN`.
Bước `➖ BỎ` **không vẽ trong sơ đồ TO-BE** — nó nằm ở bảng B4, vì vẽ một bước không còn tồn
tại sẽ gây hiểu nhầm.*
**Đặt cạnh nhau để so sánh:** sơ đồ A1 và B1 dùng chung quy ước hình dạng, nên mở hai mục
cạnh nhau là thấy ngay bước nào biến mất và bước nào thêm vào.
## B2. Bảng chi tiết từng bước
| # | Bước | Loại | Ai làm | Input | Output | Hệ thống | ⏱ Dự kiến | US |
|---|---|---|---|---|---|---|---|---|
| B1 | | 🆕 | | | | | | US-0nn |
**Tổng thời gian dự kiến:** … *(so với AS-IS: …)*
## B3. Đối chiếu điểm đau → cách xử lý
*Bảng bắt buộc. Mỗi điểm đau ở A3 phải có một dòng.*
| Điểm đau | Bước TO-BE xử lý | Cách xử lý | Hiệu quả kỳ vọng | Nếu không xử lý: lý do |
|---|---|---|---|---|
| P1 | B2 | | | |
Điểm đau không có bước nào xử lý ⇒ hoặc TO-BE thiếu, hoặc nằm ngoài phạm vi — **ghi rõ ở
cột cuối, không để trống**.
## B4. Bước bị bỏ — ai làm thay
| Bước AS-IS bỏ đi | Việc đó giờ ai/cái gì làm | Xác nhận bởi |
|---|---|---|
## B5. Bước mới — ai có thời gian làm
| Bước mới | Ai làm | Thêm bao nhiêu thời gian/ngày | Đã hỏi người đó chưa |
|---|---|---|---|
🔴 Bước mới đổ việc lên một vai trò đã quá tải là lý do phổ biến khiến hệ thống đúng spec
mà không ai dùng.
## B6. Thay đổi với người dùng
| Vai trò | Trước | Sau | Cần đào tạo gì | Mức kháng cự dự kiến |
|---|---|---|---|---|
---
## 2. Open Questions
| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì |
|---|---|---|---|---|
## 3. Ngoài phạm vi
- Thiết kế màn hình → GĐ3 `SRS`
- Quy tắc chi tiết → `BR_…md`
- Phân quyền → `RBAC_…md`

112
.claude/skills/ba-2-analysis/templates/rbac-matrix.md Normal file
View File

@@ -0,0 +1,112 @@
# RBAC — Ma trận phân quyền — <Tên module>
| | |
|---|---|
| **Version** | 1.0 |
| **Date** | YYYY-MM-DD |
| **Author** | <BA> (skill ba-2-analysis) |
| **Status** | 🟡 Draft |
| **Approved by** | — |
| **Source** | |
| **Scope** | |
## Change Log
| Version | Date | Người sửa | Thay đổi | CR |
|---|---|---|---|---|
---
## 1. Vai trò
| ID | Vai trò | Ai thuộc vai trò này | Số người ước tính | Phạm vi dữ liệu | Vai trò hệ thống hiện có |
|---|---|---|---|---|---|
| ROLE-01 | | | | Toàn hệ thống / Theo cửa hàng / Chỉ bản ghi của mình | |
**Phạm vi dữ liệu** là cột hay bị bỏ và là nguồn của lỗ hổng bảo mật phổ biến nhất: hai
người cùng vai trò nhưng chỉ được xem dữ liệu của đơn vị mình.
## 2. Ma trận vai trò × hành động
*Ô ghi: `✅` được · `❌` không · `🔶` được nhưng có điều kiện.*
🔴 **Ô `🔶` bắt buộc ghi điều kiện ngay trong ô.** `🔶` không điều kiện = chưa phân tích xong.
| Hành động | ROLE-01<br>Nhân viên | ROLE-02<br>Trưởng nhóm | ROLE-03<br>Kế toán | ROLE-04<br>Admin | BR |
|---|---|---|---|---|---|
| Xem danh sách | 🔶 chỉ cửa hàng phụ trách | ✅ | ✅ | ✅ | BR-030 |
| Xem chi tiết | 🔶 chỉ cửa hàng phụ trách | ✅ | ✅ | ✅ | |
| Tạo mới | ✅ | ✅ | ❌ | ✅ | |
| Sửa | 🔶 chỉ khi trạng thái Nháp | ✅ | ❌ | ✅ | BR-005 |
| Xoá | ❌ | 🔶 chỉ Nháp, cần lý do | ❌ | ✅ | BR-006 |
| Gửi duyệt | ✅ | ✅ | ❌ | ✅ | |
| Duyệt | ❌ | 🔶 không tự duyệt bản ghi mình tạo | ❌ | ❌ | **SoD-01** |
| Xuất dữ liệu | 🔶 cần nhập lý do | ✅ | ✅ | ✅ | BR-031 |
| Xem lịch sử thay đổi | ❌ | ✅ | ✅ | ✅ | |
**Kiểm tra chất lượng ma trận:** một cột toàn ✅ hoặc một hàng toàn ✅ ⇒ chưa phân tích.
Luôn hỏi ngược *"vai trò nào KHÔNG được làm việc này?"* — câu phủ định ép ra ranh giới thật.
## 3. Separation of Duties (SoD)
*Bắt buộc với mọi hành động phê duyệt / chốt sổ / thanh toán / cấp quyền.*
| ID | Cặp hành động xung đột | Quy tắc | Hệ thống chặn thế nào | Ai giám sát |
|---|---|---|---|---|
| SoD-01 | Tạo ↔ Duyệt | Người tạo không được duyệt bản ghi của chính mình | Ẩn nút Duyệt khi `createdBy = currentUser` | Kiểm toán nội bộ |
| SoD-02 | Duyệt ↔ Chi tiền | | | |
**Ngoại lệ SoD** — nếu tổ chức quá nhỏ để tách vai:
| Ngoại lệ | Điều kiện | Bù đắp bằng | Ai phê chuẩn ngoại lệ |
|---|---|---|---|
| | *(vd: chi nhánh <3 người)* | Log + báo cáo hằng tháng cho trưởng phòng | |
Không có SoD trong nghiệp vụ tài chính là **phát hiện của kiểm toán**, không phải chi tiết nhỏ.
## 4. Dữ liệu nhạy cảm
| Trường/dữ liệu | Loại | Ai được xem | Che thế nào | Xuất được không | Lưu bao lâu | Căn cứ |
|---|---|---|---|---|---|---|
| Số CMND/CCCD | PII | ROLE-03, ROLE-04 | Che 6 số giữa | 🔶 cần lý do | 5 năm | |
| Số tài khoản | PII tài chính | ROLE-03 | Che 4 số cuối | ❌ | | |
## 5. Lưu vết (audit)
| Hành động | Ghi vết | Nội dung ghi | Giữ bao lâu | Ai xem được |
|---|---|---|---|---|
| Sửa bản ghi | ✅ | ai · lúc nào · trường nào · trước→sau | 2 năm | ROLE-02+ |
| Duyệt | ✅ | ai · lúc nào · ghi chú | 5 năm | ROLE-02+ |
| Xuất dữ liệu | ✅ | ai · lúc nào · **lý do** · số bản ghi | 5 năm | ROLE-04 |
| Đăng nhập thất bại | ✅ | | | |
Ba câu hỏi cho mỗi hành động nhạy cảm — trả lời đủ mới coi là phân tích xong:
1. Ai được **xem** dữ liệu này? Có phải thông tin cá nhân không?
2. Có cần **lưu vết** không? Lưu bao lâu?
3. Có cần **nhập lý do** khi thực hiện không?
## 6. Hành vi khi không đủ quyền
*Quy tắc W7 — ba trạng thái khác nhau, phải chọn rõ cho từng trường hợp.*
| Tình huống | Hành vi | Lý do |
|---|---|---|
| Không có quyền xem màn hình | Không hiện trong menu + chặn ở route | Tránh lộ sự tồn tại của chức năng |
| Có quyền xem, không có quyền sửa | Hiện, ở chế độ read-only | Vẫn cần tra cứu |
| Có quyền nhưng sai trạng thái | Hiện nút, **disable**, có tooltip nêu lý do | Người dùng cần biết vì sao không bấm được |
| Gọi thẳng API không đủ quyền | Trả 403 + ghi log | Chặn ở cả FE và BE |
🔴 Chặn ở giao diện là trải nghiệm, **chặn ở backend mới là bảo mật**. Ghi rõ cả hai.
## 7. Thay đổi so với phân quyền hiện tại
*Chỉ dùng khi làm enhancement.*
| Vai trò | Quyền cũ | Quyền mới | Ai bị mất quyền | Đã thông báo chưa |
|---|---|---|---|---|
Mất quyền mà không báo trước là sự cố vận hành ngày go-live.
## 8. Open Questions
| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì |
|---|---|---|---|---|

179
.claude/skills/ba-2-analysis/templates/user-story-backlog.md Normal file
View File

@@ -0,0 +1,179 @@
# BACKLOG — <Tên module>
| | |
|---|---|
| **Version** | 1.0 |
| **Date** | YYYY-MM-DD |
| **Author** | <BA> (skill ba-2-analysis) |
| **Status** | 🟡 Draft |
| **Approved by** | — |
| **Source** | BRIEF_… v1.0 · PROCESS_… v1.0 |
| **Scope** | |
## Change Log
| Version | Date | Người sửa | Thay đổi | CR |
|---|---|---|---|---|
---
## 0. Sơ đồ Use Case — toàn cảnh cho PO
*Một hình cho PO thấy **ai làm được gì** trong phạm vi này. Đây là thứ mang vào buổi duyệt
G2, không phải bảng US 40 dòng.*
```mermaid
flowchart LR
NV(["👤 Nhân viên đối soát"])
TN(["👤 Trưởng nhóm"])
KT(["👤 Kế toán"])
subgraph HT["Phạm vi US-011 … US-014"]
UC11(["US-011 Tải file POS"])
UC12(["US-012 Xem kết quả nhập"])
UC13(["US-013 Xem chênh lệch"])
UC14(["US-014 Đóng chênh lệch"])
end
NGOAI[["Hệ thống POS — ngoài phạm vi"]]
NV --- UC11
NV --- UC12
NV --- UC13
TN --- UC13
TN --- UC14
KT --- UC13
UC11 --- NGOAI
```
**Quy ước:** dùng `---` không mũi tên (quan hệ actor–use case là **liên kết**, không phải
luồng) · ID node là `UC<số US>` để khớp bảng §5 · khung đôi `[[ ]]` = ngoài phạm vi.
Sơ đồ quá 12 use case ⇒ **tách theo Epic**, mỗi Epic một sơ đồ. Nhồi hết vào một hình thì
không ai đọc được, và mục đích của nó là để đọc được.
🔴 **Bảng đi kèm bắt buộc là bảng §5** (quy tắc W13) — sơ đồ không nói được MoSCoW, ước
lượng, phụ thuộc, hay `RQ` nào sinh ra US đó.
| Actor trong sơ đồ | Vai trò trong `RBAC` | Số US |
|---|---|---|
| Nhân viên đối soát | ROLE-01 | 3 |
| Trưởng nhóm | ROLE-02 | 2 |
| Kế toán | ROLE-03 | 1 |
*Actor ở đây phải khớp vai trò trong `RBAC_….md`. Lệch nhau ⇒ một trong hai tài liệu sai.*
## 1. Cây phân rã
```mermaid
flowchart LR
RQ007["RQ-007 &lt;phát biểu ngắn&gt;"]
E02["EPIC-02 &lt;tên&gt;"]
F05["FEAT-05 &lt;tên&gt;"]
F06["FEAT-06 &lt;tên&gt;"]
U11(["US-011 &lt;tên ngắn&gt;"])
U12(["US-012 &lt;tên ngắn&gt;"])
U13(["US-013 &lt;tên ngắn&gt;"])
RQ007 --> E02
E02 --> F05
E02 --> F06
F05 --> U11
F05 --> U12
F06 --> U13
```
*Ba tầng, không nhảy cóc. Một `RQ` ra nhiều `EPIC` thì vẽ nhiều nhánh; nhiều `RQ` cùng ra
một `EPIC` cũng hợp lệ — vẽ nhiều mũi tên vào.*
## 2. Epic
| ID | Tên | Giá trị nghiệp vụ | RQ phủ | Feature | Ưu tiên |
|---|---|---|---|---|---|
| EPIC-01 | | | RQ-001, RQ-003 | FEAT-01…03 | |
## 3. Feature
| ID | Tên | Epic | Mô tả một câu | US | MoSCoW |
|---|---|---|---|---|---|
| FEAT-01 | | EPIC-01 | | US-001…004 | Must |
## 4. User Story
> Mẫu — **cả ba vế bắt buộc**:
> *Là `<vai trò cụ thể>`, tôi muốn `<hành động>`, để `<giá trị nghiệp vụ>`.*
>
> Vai trò phải cụ thể ("nhân viên đối soát"), không được là "người dùng".
> Vế **để** trống hoặc lặp lại vế **muốn** ⇒ US này chưa chứng minh được giá trị.
### US-011 — <tên ngắn>
| | |
|---|---|
| **Feature** | FEAT-05 |
| **RQ** | RQ-007 |
| **MoSCoW** | Must |
| **Vai trò** | |
| **Phụ thuộc** | *(US phải xong trước, nếu có)* |
| **BR áp dụng** | BR-021, BR-022 |
| **Ước lượng sơ bộ** | S / M / L / XL |
**Story:**
> Là …, tôi muốn …, để ….
**Phạm vi:**
- Trong: …
- Ngoài: …
**Điều kiện nghiệm thu mức thô** *(chi tiết Given/When/Then viết ở GĐ3)*
- …
**INVEST:**
| I | N | V | E | S | T | Ghi chú nếu không đạt |
|---|---|---|---|---|---|---|
| ✅ | ✅ | ✅ | ⚠️ | ✅ | ✅ | E: chưa rõ nguồn dữ liệu POS → OQ-014 |
---
## 5. Bảng tổng hợp US
| ID | Tên | Feature | RQ | MoSCoW | Ước lượng | Phụ thuộc | INVEST | Trạng thái |
|---|---|---|---|---|---|---|---|---|
| US-011 | | FEAT-05 | RQ-007 | Must | M | — | ✅ | Draft |
## 6. Đối chiếu ngược RQ → US *(bảng bắt buộc)*
| RQ | Phát biểu ngắn | MoSCoW | US phủ | Trạng thái |
|---|---|---|---|---|
| RQ-001 | | Must | US-001, US-002 | ✅ Đã phủ |
| RQ-005 | | Should | — | 🔴 **CHƯA PHỦ** |
**RQ chưa phủ ⇒ giải thích từng cái:** bị hoãn sang phase sau (ghi `DEC-nn`), hay bỏ sót?
## 7. US không truy về RQ nào *(nghi ngờ scope creep)*
| US | Từ đâu ra | Đề xuất | PO quyết |
|---|---|---|---|
| US-0nn | *(ai đề xuất, buổi nào)* | Giữ / Bỏ / Hoãn | ☐ |
Không im lặng giữ. Mỗi dòng phải có PO quyết.
## 8. Đề xuất thứ tự thực hiện
*BA đề xuất, **PO chốt**. Sắp theo: phụ thuộc kỹ thuật → giá trị → rủi ro.*
| Đợt | US | Lý do xếp trước | Kết quả demo được |
|---|---|---|---|
| 1 | US-001, US-011 | Nền tảng dữ liệu, US khác phụ thuộc | Nhập được file POS |
| 2 | | | |
## 9. Open Questions
| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn US nào |
|---|---|---|---|---|
## 10. Ngoài phạm vi
- Ước lượng story point chính thức → team dev ở buổi grooming
- Thiết kế màn hình, field spec → GĐ3 `SRS`