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

160
.claude/skills/ba-2-analysis/GUIDE.md Normal file
View File

@@ -0,0 +1,160 @@
# Hướng dẫn sử dụng — `ba-2-analysis` (Giai đoạn 2)
## Giai đoạn này giải quyết gì
Đầu vào là `BRIEF` đã qua G1 với một danh sách `RQ`. Đầu ra là mô hình nghiệp vụ mà PO và
Dev đọc đều hiểu giống nhau: quy trình chạy thế nào, chia thành những user story nào, quy
tắc gì chi phối, ai được làm gì, và việc này đụng vào đâu trong hệ thống đang chạy.
**Không làm ở giai đoạn này:** vẽ màn hình chi tiết, định nghĩa field (kiểu, độ dài,
validation), viết AC Given/When/Then, thiết kế API. Tất cả là GĐ3.
Ranh giới dễ nhớ: GĐ2 trả lời *"nghiệp vụ cần gì"*, GĐ3 trả lời *"dev code cái gì"*.
## Khi nào gọi
| Tình huống | Có nên gọi |
|---|---|
| `BRIEF` vừa qua G1, cần phân rã backlog | ✅ Chạy đầy đủ |
| Nhận một US từ khách, cần hiểu nó ảnh hưởng tới đâu | ✅ Chạy Bước 5 (`IMPACT`) là chính |
| Quy tắc nghiệp vụ đang rối, nhiều chỗ mâu thuẫn | ✅ Chạy Bước 3 (`BR`) là chính |
| Cần ma trận phân quyền cho module | ✅ Chạy Bước 4 (`RBAC`) |
| Đã có backlog rồi, chỉ cần viết spec | ❌ Sang `ba-3-specification` |
## Cú pháp
```
/ba-2-analysis <PROJECT|US-id> [--only process|backlog|br|rbac|impact] [--out <path>] [go]
```
| Tham số | Ý nghĩa |
|---|---|
| `--only <bước>` | Chỉ chạy một phần. Dùng khi bạn chỉ cần `IMPACT` hoặc chỉ cần `RBAC` |
| `go` | Bỏ bước dừng xác nhận input |
Ví dụ:
```
/ba-2-analysis Settlement
/ba-2-analysis US059 --only impact
/ba-2-analysis Settlement --only br,rbac
```
## Chuẩn bị gì trước khi gọi
**Bắt buộc:**
- `BRIEF` với danh sách `RQ` (từ GĐ1). Chưa có ⇒ skill sẽ cảnh báo và đề nghị quay lại GĐ1
**Rất nên có** — quyết định chất lượng của `PROCESS` và `IMPACT`:
- Biên bản quan sát người dùng làm việc thật
- Quyền truy cập/ảnh chụp hệ thống hiện tại
- Tài liệu hoặc schema DB hiện có
- Tên dev/tech lead từng làm module bị ảnh hưởng
## Quy trình 5 bước — bạn tham gia ở đâu
| Bước | Skill làm | Bạn làm |
|---|---|---|
| 1. `PROCESS` | Dựng khung AS-IS/TO-BE, đòi cột thời gian, đòi đối chiếu điểm đau | Cung cấp quy trình thật, xác nhận với người dùng |
| 2. `BACKLOG` | Phân rã 3 tầng, chấm INVEST, đối chiếu ngược RQ→US | Chốt MoSCoW với PO, chốt thứ tự |
| 3. `BR` | Gom rule, dựng bảng chuyển trạng thái, dò mâu thuẫn | Hỏi nguồn của từng rule, đưa PO quyết mâu thuẫn |
| 4. `RBAC` | Dựng ma trận, đòi điều kiện cho ô 🔶, đòi SoD | Xác nhận với bảo mật/kiểm toán |
| 5. `IMPACT` | Rà 6 trục, đòi phương án cho dữ liệu cũ | Xác nhận với Tech Lead |
## Bạn sẽ nhận được gì
```
ba-output/<PROJECT>/02-analysis/
├── PROCESS_<tên quy trình>_v1.0.md
├── BACKLOG_<PROJECT>_v1.0.md
├── BR_<PROJECT>_v1.0.md
├── RBAC_<PROJECT>_v1.0.md
└── IMPACT_<US|PROJECT>_v1.0.md
```
Cộng bốn bảng in ra màn hình: đối chiếu `RQ`→`US` · tự chấm G2 · checklist W1–W13 · `OQ` mở.
**Bảng đối chiếu `RQ`→`US` là thứ đáng đọc nhất.** Nó chỉ ra ngay hai loại lỗi:
```
| RQ | US phủ | Trạng thái |
| RQ-001 | US-001, US-002 | ✅ Đã phủ |
| RQ-005 | — | 🔴 CHƯA PHỦ | ← yêu cầu bị bỏ quên
US không truy về RQ nào (nghi ngờ scope creep):
| US-018 | Từ đề xuất của dev ở buổi grooming | Chờ PO quyết |
```
## Ví dụ hội thoại
```
Bạn: /ba-2-analysis Settlement
Claude: [Bước 0]
Input:
| BRIEF_Settlement_v1.0.md | Yêu cầu nghiệp vụ, 12 RQ | v1.0 | ✅ Baselined |
| PROCESS_… | Chưa có | — | — |
G1: đã qua (Approved by: chị Lan, 2026-08-25). ✅
Phạm vi: 12 RQ — chạy một lượt được, không cần chia.
Để làm IMPACT tôi cần khảo sát:
- d:/Kakao/fan-platform-admin (màn hình admin hiện có)
- Schema DB settlement — bạn có tài liệu không?
Xác nhận giúp tôi.
Bạn: DB thì hỏi anh Huy. Cứ đọc repo admin trước đi.
Claude: [chạy 5 bước, ghi 5 file, in bảng đối chiếu RQ→US]
⚠️ RQ-005 (cảnh báo chênh lệch qua email) chưa có US nào phủ.
Đây là Should. Bạn muốn tôi thêm US hay ghi DEC hoãn sang phase 2?
```
## Lỗi thường gặp
**"AS-IS mất thời gian quá, bỏ được không?"**
Bỏ được, và bạn sẽ thiết kế một TO-BE thiếu đúng phần ngoại lệ mà người ta xử lý tay mỗi
ngày. Nếu thật sự gấp: tối thiểu phải có mục A4 (đường tắt) và A5 (ngoại lệ) — hai mục đó
chứa spec ẩn nhiều nhất.
**"US của tôi bị chấm INVEST không đạt chữ S, phải tách."**
Dùng bốn cách tách theo thứ tự: luồng nghiệp vụ (CRUD) → quy tắc (thường/ngoại lệ) → dữ
liệu (loại A trước, loại B sau) → vai trò. **Đừng tách theo tầng kỹ thuật** ("US làm API",
"US làm UI") — mỗi US phải giao được một mẩu giá trị chạy được đầu-cuối.
**"Ma trận phân quyền của tôi toàn ✅."**
Nghĩa là chưa phân tích. Hỏi ngược từng hành động: *"vai trò nào KHÔNG được làm việc này?"*
Nếu câu trả lời thật sự là "ai cũng được" thì ghi rõ lý do vào ghi chú.
**"Không biết dữ liệu cũ xử lý sao, ghi 'sẽ xử lý sau' được không?"**
Không. Chọn một trong ba (giữ nguyên / migrate / song song) và ghi lý do. Chưa đủ thông tin
để chọn ⇒ ghi `OQ` với người phải trả lời và hạn — như vậy nó là một việc có chủ, không
phải một khoảng trống.
**"IMPACT của US này chắc chắn bằng không, cần viết file không?"**
Có. Ghi *"đã rà 6 trục, không phát hiện tác động"* kèm phạm vi đã rà. Sáu tháng sau khi có
sự cố, dòng đó là bằng chứng đã rà, chứ không phải đã quên.
**"Rule tôi viết thẳng trong mô tả US cho tiện."**
Rồi sáu tháng sau rule đổi, bạn sửa một US và quên ba US khác cũng chứa rule đó. Rule luôn
có ID riêng, sống ở `BR`, US chỉ tham chiếu.
## Ra khỏi giai đoạn này khi nào
Đủ cả bốn:
1. Bảng đối chiếu `RQ`→`US` phủ 100% (hoặc RQ chưa phủ đều có `DEC` hoãn)
2. Bảng tự chấm G2 toàn ✅
3. PO **và** Tech Lead đã điền `Approved by`
4. Chạy `/ba-traceability <PROJECT>` không còn cảnh báo mức 🔴
Rồi chạy `/ba-3-specification <US-id>`.
## Liên quan
- Tiêu chí gate G2: `../ba-lifecycle/references/workflow.md` §2
- Quy tắc viết: `../ba-lifecycle/references/writing-rules.md`
- Template: `templates/process-model.md` · `templates/user-story-backlog.md` ·
`templates/business-rules.md` · `templates/rbac-matrix.md` · `templates/impact-analysis.md`

272
.claude/skills/ba-2-analysis/SKILL.md Normal file
View File

@@ -0,0 +1,272 @@
---
name: ba-2-analysis
description: Giai đoạn 2 của quy trình BA — phân tích và mô hình hoá nghiệp vụ. Dùng để vẽ quy trình AS-IS/TO-BE, phân rã yêu cầu thành Epic/Feature/User Story, chốt business rule, dựng ma trận phân quyền RBAC, vẽ vòng đời trạng thái, và phân tích tác động lên module/dữ liệu/tích hợp hiện có. Kích hoạt khi người dùng nói "phân rã user story", "vẽ quy trình nghiệp vụ", "làm rõ business rule", "ma trận phân quyền", "US này ảnh hưởng tới đâu", "phân tích tác động", "backlog", "AS-IS TO-BE". Input là BRIEF đã qua G1; output vào ba-output/<PROJECT>/02-analysis/ và phải qua Gate G2 trước khi sang ba-3-specification.
---
# GĐ2 · ANALYSIS — Phân tích & mô hình hoá
Mục tiêu: **chuyển yêu cầu nghiệp vụ (`RQ`) thành mô hình mà cả PO lẫn Dev đọc đều hiểu
giống nhau** — quy trình, user story, quy tắc, phân quyền, tác động.
Vẫn chưa vẽ màn hình chi tiết. Ở đây trả lời *"nghiệp vụ chạy thế nào và cần những gì"*,
GĐ3 mới trả lời *"màn hình trông ra sao, field nào bao nhiêu ký tự"*.
Output: `PROCESS` · `BACKLOG` · `BR` · `RBAC` · `IMPACT` trong `ba-output/<PROJECT>/02-analysis/`
## Bốn nguyên tắc bất di bất dịch
1. **Không bịa yêu cầu** — thiếu ⇒ `OQ-nnn`.
2. **Không quyết định thay PO** — ưu tiên và trade-off nghiệp vụ do PO chốt.
3. **Mọi phát biểu truy vết được** — mỗi `US` chỉ về `RQ`, mỗi `BR` chỉ về `RQ` hoặc `DEC`.
4. **Không ghi đè tài liệu đã qua gate.**
Nạp thêm: `../ba-lifecycle/references/domain-profiles.md` · `../ba-lifecycle/references/writing-rules.md` ·
`../ba-lifecycle/references/artifact-map.md` §2 · **`../ba-lifecycle/references/diagram-rules.md`**
(giai đoạn này sinh nhiều sơ đồ nhất: quy trình, use case, trạng thái, ERD).
Ví dụ minh hoạ nhiều domain: `examples.md`.
🔴 **Mọi sơ đồ vẽ bằng mermaid, không ASCII art, và luôn có bảng đi kèm** (quy tắc W13).
Sơ đồ để nhìn, bảng để truy vết và test — sơ đồ đứng một mình là bức tranh đẹp mà QA không
viết được test case từ đó.
## Bước 0 — Chốt input rồi dừng lại
**Chưa được ghi file.** Làm sáu việc rồi **dừng chờ trả lời**:
1. **Profile** — đọc `00-index/PROFILE_<PROJECT>.md`. Chưa có ⇒ suy ra từ `BRIEF`, **nêu rõ
là suy đoán** và hỏi xác nhận.
2. **Input dùng được** — bảng `File | Vai trò | Version | Status`. Bắt buộc tìm `BRIEF` và
`RQ` list từ GĐ1 trong `ba-output/<PROJECT>/01-discovery/`.
3. **Gate G1 đã qua chưa** — đọc `Approved by` trong header `BRIEF`. Chưa qua ⇒ **nói rõ
rủi ro** (backlog sẽ phải làm lại nếu phạm vi đổi), rồi hỏi có làm tiếp không.
4. **Artifact sẽ ghi, theo profile** — nêu đích danh, kèm cái sẽ bỏ và vì sao:
`LIFECYCLE = greenfield` ⇒ `PROCESS` PHẦN A rút gọn còn A3–A5 ·
`RIGOR = light` ⇒ bỏ `RBAC` nếu 1 vai trò, `IMPACT` chỉ trục dữ liệu + tích hợp ·
`PRODUCT = api-service` ⇒ `RBAC` theo client/scope thay vì vai trò người ·
`PRODUCT = data-pipeline` ⇒ `RBAC` theo tập dữ liệu và độ nhạy cảm.
5. **Phạm vi lần chạy này** — cả module hay một vài `RQ`/`US`? Phân tích cả module một lúc
thường ra tài liệu nông; đề xuất chia nhỏ nếu >15 `RQ`. Kèm hệ thống/DB/tài liệu định
khảo sát để làm `IMPACT`.
6. **Hỏi xác nhận** năm điểm trên.
Bỏ qua khi lệnh có `go`.
## Thực hiện — 5 bước
### Bước 1 — Quy trình AS-IS rồi mới TO-BE
Điền `templates/process-model.md`.
**AS-IS trước, luôn luôn** — khi `LIFECYCLE` là `brownfield` hoặc `enhancement`. Bỏ qua
AS-IS là cách nhanh nhất để thiết kế một TO-BE bỏ sót ngoại lệ mà người ta vẫn xử lý tay
mỗi ngày.
`LIFECYCLE = greenfield` ⇒ PHẦN A rút gọn còn **A3 điểm đau · A4 đường tắt · A5 ngoại lệ**
(ba mục chứa spec ẩn nhiều nhất). Bỏ A1, A2, A6 và **ghi rõ lý do**, đừng để trống.
Mỗi bước quy trình ghi đủ sáu cột: `ai làm | làm gì | input | output | công cụ | thời gian`.
Cột **thời gian** là thứ chỉ ra chỗ đáng tự động hoá — không có nó thì TO-BE chỉ là ý kiến.
Với AS-IS, bắt buộc ghi thêm:
- **Điểm đau** — bước nào chậm/sai/phải làm lại, gắn về `RQ` nào
- **Đường tắt** — chỗ người ta lách quy trình (file Excel riêng, gọi điện xác nhận, sổ tay).
Đây là **spec ẩn**: mỗi đường tắt là một nhu cầu chưa được hệ thống đáp ứng
- **Ngoại lệ** — ca bất thường và cách xử lý hiện tại, kèm tần suất
Với TO-BE:
- Đánh dấu rõ bước nào **mới**, **đổi**, **bỏ**, **giữ nguyên**
- Mỗi bước bỏ đi phải trả lời: *việc đó ai làm thay, hay không cần làm nữa?*
- Mỗi bước mới phải trả lời: *ai có thời gian làm việc này?*
🔴 **TO-BE phải giải quyết được điểm đau đã ghi ở AS-IS.** Đối chiếu từng điểm đau ⇒ bước
nào trong TO-BE xử lý nó. Điểm đau không có bước nào xử lý ⇒ hoặc TO-BE thiếu, hoặc điểm
đau đó nằm ngoài phạm vi — ghi rõ, đừng để lửng.
### Bước 2 — Phân rã tới User Story
Điền `templates/user-story-backlog.md`. Ba tầng, không nhảy cóc:
```mermaid
flowchart LR
RQ["RQ-nnn (từ GĐ1)"] --> E["EPIC-nn"]
E --> F1["FEAT-nn"]
E --> F2["FEAT-nn"]
F1 --> U1(["US-nnn"])
F1 --> U2(["US-nnn"])
F2 --> U3(["US-nnn"])
```
Cây phân rã thật ở hai domain khác nhau: `examples.md`.
**Kèm sơ đồ Use Case ở §0 của `BACKLOG`** — một hình `actor × use case` cho PO thấy toàn
cảnh phạm vi, mang vào buổi duyệt G2 thay cho bảng US 40 dòng. Actor trong đó phải khớp vai
trò trong `RBAC`; lệch nhau là một trong hai tài liệu sai.
Mẫu user story — **cả ba vế đều bắt buộc**, vế "để" là vế hay bị bỏ và cũng là vế quan trọng nhất:
```
US-013 | Là <vai trò cụ thể, không phải "người dùng">
tôi muốn <hành động>
để <giá trị nghiệp vụ đạt được>
```
Vế "để" trống hoặc lặp lại vế "muốn" ("để xem được danh sách") ⇒ US này chưa chứng minh
được giá trị, nhiều khả năng là chức năng do ai đó tưởng tượng ra.
Chấm mỗi US theo **INVEST**, ghi vào bảng:
| Chữ | Kiểm tra | Không đạt thì làm gì |
|---|---|---|
| **I**ndependent | Làm được mà không cần US khác xong trước? | Ghi phụ thuộc vào cột riêng |
| **N**egotiable | Mô tả *cái gì*, không mô tả *code thế nào*? | Bỏ chi tiết kỹ thuật xuống GĐ3 |
| **V**aluable | Vế "để" có giá trị thật cho vai trò đó? | Gộp vào US khác hoặc bỏ |
| **E**stimable | Dev nhìn vào ước lượng được? | Thiếu thông tin ⇒ `OQ` |
| **S**mall | Làm gọn trong một sprint? | Tách nhỏ — xem 4 cách tách bên dưới |
| **T**estable | Nghĩ ra được cách kiểm chứng? | Chưa rõ điều kiện ⇒ `OQ` |
**Bốn cách tách US quá lớn** (theo thứ tự ưu tiên):
1. **Theo luồng nghiệp vụ** — tạo / sửa / xoá / xem là bốn US riêng
2. **Theo quy tắc** — luồng thường vs. luồng ngoại lệ
3. **Theo dữ liệu** — một loại đối tượng trước, loại khác sau
4. **Theo vai trò** — người nhập liệu vs. người phê duyệt
❌ **Không tách theo tầng kỹ thuật** ("US làm API", "US làm giao diện"). Mỗi US phải giao
được một mẩu giá trị chạy được đầu-cuối.
**Đối chiếu ngược bắt buộc:** mỗi `RQ` của GĐ1 phải map về ≥1 `US`. `RQ` không có `US` là
yêu cầu bị bỏ quên — in ra danh sách này ở phần báo cáo. Ngược lại, `US` không truy về `RQ`
nào là **scope creep** — hỏi PO xem giữ hay bỏ, đừng im lặng giữ.
### Bước 3 — Chốt business rule và vòng đời trạng thái
Điền `templates/business-rules.md`.
**Quy tắc tách khỏi user story.** Cùng một `BR` thường chi phối nhiều US; nhét vào US thì
sửa một chỗ quên chín chỗ.
Mỗi `BR-nnn` ghi: phát biểu · loại · nguồn · US áp dụng · hành vi khi vi phạm (chặn/cảnh
báo/ghi log) · ngoại lệ và ai được cho phép ngoại lệ.
Bốn loại rule, rà đủ:
| Loại | Câu hỏi nhận diện |
|---|---|
| **Ràng buộc dữ liệu** | Cái gì là duy nhất? Giá trị nào hợp lệ? |
| **Điều kiện hành động** | Phải có gì mới được làm việc này? |
| **Tính toán** | Con số này ra từ đâu, theo công thức nào? |
| **Quy trình / phê duyệt** | Mức nào cần ai duyệt? Có cần hai người không? |
🔴 **Hỏi nguồn của mỗi rule.** Quy định pháp luật, hợp đồng/chính sách, hay thói quen nội bộ?
Ba thứ này có độ cứng hoàn toàn khác nhau — thói quen nội bộ có thể đề xuất bỏ khi nó cản
trở, quy định pháp luật thì không. Gộp chúng lại làm mất khả năng đàm phán ở đúng chỗ đáng
đàm phán. Ví dụ ba mức nguồn: `examples.md`.
**Mô hình dữ liệu khái niệm (ERD)** — bắt buộc khi US chạm từ **2 thực thể trở lên**. Không
có nó, dev tự suy ra quan hệ 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. Vẽ bằng `erDiagram`, kèm bảng thực thể (khoá nghiệp vụ, số bản ghi hiện
có) và bảng quan hệ (xoá bên "một" thì bên "nhiều" ra sao).
🔴 Đây là mô hình **khái niệm**: thực thể, quan hệ, khoá nghiệp vụ. **Không** kiểu dữ liệu
vật lý, không index, không bảng trung gian — đó là việc của Solution Architect và dev.
**Vòng đời trạng thái** — mọi thực thể có trạng thái phải có bảng chuyển (quy tắc W6):
| Trạng thái nguồn | Sự kiện | Điều kiện | Trạng thái đích | Ai được làm | BR |
|---|---|---|---|---|---|
Trả lời đủ bốn câu: trạng thái khởi tạo là gì · trạng thái nào là cuối · từ trạng thái cuối
quay lại được không · trạng thái nào cho phép xoá.
**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ể. Mâu thuẫn phải đưa PO quyết, không tự chọn.
### Bước 4 — Ma trận phân quyền
Điền `templates/rbac-matrix.md`.
Ma trận `chủ thể × hành động`. **Chủ thể đổi theo `PRODUCT`**: `screen` → vai trò người
dùng · `api-service` → client/scope · `data-pipeline` → nhóm người tiêu thụ theo độ nhạy
cảm của tập dữ liệu · `batch-job` → ai được chạy tay, ai nhận cảnh báo.
Ô ghi một trong: `✅ được` · `❌ không` · `🔶 được nhưng có điều kiện` — **ô `🔶` bắt buộc ghi
điều kiện ngay trong ô**. Ô `🔶` không có điều kiện là ô chưa phân tích xong.
Bắt buộc có **bảng SoD (Separation of Duties)** cho mọi hành động phê duyệt/chốt sổ/thanh
toán: ai tạo thì không được tự duyệt. Không có SoD ở 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ỏ. `RIGOR = strict` ⇒ **bắt buộc có SoD kể cả khi nghiệp vụ
trông đơn giản**; `RIGOR = light` với đúng 1 vai trò ⇒ được bỏ `RBAC`, nhưng phải **ghi rõ
"1 vai trò"** thay vì bỏ im lặng.
Ba câu phải trả lời cho mỗi hành động nhạy cảm:
- Ai được **xem** dữ liệu này? Có phải thông tin cá nhân không?
- Có cần **lưu vết** ai làm gì lúc nào không? Lưu bao lâu?
- Có cần **lý do** khi thực hiện không (xoá, xuất dữ liệu nhạy cảm)?
### Bước 5 — Phân tích tác động
Điền `templates/impact-analysis.md`. **Bước này hay bị bỏ nhất và trả giá đắt nhất.**
Rà đủ sáu trục:
| Trục | Câu hỏi | Cách kiểm tra |
|---|---|---|
| **Màn hình/chức năng** | US này đụng màn hình nào đã có? | Tra map màn hình, grep tên route |
| **Dữ liệu** | Thêm/sửa bảng nào? Dữ liệu cũ xử lý sao? | Đọc schema, đếm bản ghi hiện có |
| **Business rule** | Rule mới có mâu thuẫn rule cũ không? | Đối chiếu `BR` hiện hành |
| **Phân quyền** | Vai trò mới? Vai trò cũ đổi quyền? | Đối chiếu `RBAC` hiện hành |
| **Tích hợp** | Đụng API/hệ thống ngoài nào? | Danh sách endpoint, đầu mối bên kia |
| **Báo cáo/đối soát** | Số liệu nào đổi cách tính? | Hỏi kế toán/BI |
Với mỗi tác động: mô tả · mức (🔴 phải xử lý / 🟠 cần lưu ý / 🟢 ghi nhận) · phương án ·
ai xác nhận.
🔴 **Dữ liệu cũ luôn phải có câu trả lời rõ ràng** khi `LIFECYCLE` là `brownfield` hoặc
`enhancement`. Ba lựa chọn, chọn một và ghi lý do: giữ nguyên (chấp nhận không đồng nhất) ·
migrate (cần script + đối chiếu) · để song song (cần quy tắc phân biệt). "Sẽ xử lý sau"
không phải câu trả lời. `RIGOR = strict` ⇒ migrate phải kèm **kịch bản rollback đã thử**.
Ví dụ ba lựa chọn ở ba domain: `examples.md`.
Không có tác động nào ⇒ vẫn viết file, ghi *"đã rà 6 trục, không phát hiện tác động"* kèm
phạm vi đã rà. **"Đã rà và không thấy" khác hoàn toàn "chưa rà".**
## Trước khi kết thúc
In bốn thứ:
**① Bảng đối chiếu `RQ` → `US`** — mỗi `RQ` một dòng, cột "US phủ". `RQ` trống ⇒ đánh dấu
🔴 và giải thích. `US` không có `RQ` ⇒ liệt kê riêng dưới nhãn "nghi ngờ scope creep".
**② Bảng tự chấm Gate G2** (`../ba-lifecycle/references/workflow.md` §2) dạng ☐/✅.
**③ Checklist W1–W13** dạng ☐/✅.
**④ `OQ` mở** kèm người trả lời và cái đang bị chặn.
Chấm G2 theo đúng `RIGOR` — áp bảng "Bớt ở light" / "Thêm ở strict" ở
`../ba-lifecycle/references/workflow.md` §2, và **nói rõ đang chấm ở mức nào**.
Nhắc chữ ký: `light` chỉ PO · `standard` **PO + Tech Lead** · `strict` thêm **Bảo mật**.
Nên chạy `/ba-traceability` trước khi trình.
## Bẫy thường gặp
**Bỏ AS-IS vì "ai cũng biết quy trình rồi".** Người biết là người đang làm, không phải người
ngồi họp. Và cái "ai cũng biết" thường thiếu đúng phần ngoại lệ chiếm 20% khối lượng.
**User story viết theo màn hình.** "US: màn hình danh sách chênh lệch" không phải user
story, đó là tên màn hình. US phải nói *ai* làm *gì* để *được gì* — một US có thể trải trên
hai màn hình, hai US có thể dùng chung một màn hình.
**Rule nhét trong mô tả US.** Sáu tháng sau sửa rule đó, không ai biết nó còn nằm ở ba US
khác. Rule luôn có ID riêng và sống trong `BR`.
**Ma trận phân quyền toàn ✅.** Nghĩa là 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.
**Phân tích tác động chỉ nhìn code.** Tác động lớn nhất thường ở dữ liệu cũ và ở quy trình
của người dùng, không ở code.
**Gộp GĐ2 vào GĐ3 cho nhanh.** Viết SRS khi backlog chưa chốt nghĩa là mỗi lần PO đổi ưu
tiên phải viết lại SRS. GĐ2 rẻ, GĐ3 đắt — làm sai thứ tự thì trả giá ở chỗ đắt.

140
.claude/skills/ba-2-analysis/examples.md Normal file
View File

@@ -0,0 +1,140 @@
# Ví dụ minh hoạ — `ba-2-analysis`
Tách khỏi `SKILL.md` để quy trình không lẫn ví dụ của một ngành cụ thể.
---
## Bước 2 · Cây phân rã ba tầng
Không nhảy cóc từ `RQ` xuống `US`.
### Bán lẻ — đối soát POS
```mermaid
flowchart LR
RQ["RQ-007 Phát hiện chênh lệch<br/>trong ngày phát sinh"] --> E02["EPIC-02 Đối soát POS"]
E02 --> F05["FEAT-05 Nhập dữ liệu POS"]
E02 --> F06["FEAT-06 So khớp và xử lý"]
F05 --> U11(["US-011 Tải lên file POS hằng ngày"])
F05 --> U12(["US-012 Xem kết quả nhập và lỗi từng dòng"])
F06 --> U13(["US-013 Xem danh sách chênh lệch"])
F06 --> U14(["US-014 Ghi chú và đóng một chênh lệch"])
```
### Y tế — đặt lịch khám
```mermaid
flowchart LR
RQ["RQ-003 Biết ngay slot<br/>còn trống hay không"] --> E01["EPIC-01 Đặt lịch trực tuyến"]
E01 --> F01["FEAT-01 Tra cứu slot"]
E01 --> F02["FEAT-02 Giữ chỗ và xác nhận"]
F01 --> U01(["US-001 Xem slot trống theo chuyên khoa và ngày"])
F01 --> U02(["US-002 Lọc slot theo bác sĩ"])
F02 --> U03(["US-003 Giữ slot tạm 10 phút khi đang điền"])
F02 --> U04(["US-004 Xác nhận đặt lịch, nhận mã hẹn"])
```
### Use case của cùng module y tế — hình mang vào buổi duyệt G2
```mermaid
flowchart LR
BN(["👤 Bệnh nhân"])
DD(["👤 Điều dưỡng tiếp nhận"])
subgraph HT["Phạm vi US-001 … US-004"]
UC01(["US-001 Xem slot trống"])
UC02(["US-002 Lọc theo bác sĩ"])
UC03(["US-003 Giữ slot tạm"])
UC04(["US-004 Xác nhận đặt lịch"])
end
BHYT[["Hệ thống BHYT — ngoài phạm vi"]]
BN --- UC01
BN --- UC02
BN --- UC03
BN --- UC04
DD --- UC01
DD --- UC04
UC04 --- BHYT
```
Cùng một phạm vi, hai góc nhìn: cây phân rã cho BA truy vết `RQ → US`; use case cho PO thấy
**ai làm được gì** trong một hình.
🔴 `US-003` là US mà **chỉ có AS-IS mới lộ ra**: quan sát thấy hai bệnh nhân cùng chọn một
slot rồi một người bị gọi lại báo huỷ. Không quan sát thì không ai nghĩ tới việc giữ chỗ tạm.
---
## Bước 2 · Tách US quá lớn — bốn cách, theo thứ tự
| Cách | Ví dụ |
|---|---|
| **1. Theo luồng nghiệp vụ** | "Quản lý cửa hàng" → tạo · sửa · xoá · xem = bốn US |
| **2. Theo quy tắc** | "Đặt lịch" → luồng thường / luồng bệnh nhân BHYT (cần tra cứu thẻ) |
| **3. Theo dữ liệu** | "Nạp dữ liệu" → nguồn POS trước, nguồn ERP sau |
| **4. Theo vai trò** | "Xử lý chênh lệch" → người ghi chú / người phê duyệt đóng |
❌ **Không tách theo tầng kỹ thuật.** "US làm API" + "US làm giao diện" không giao được mẩu
giá trị nào chạy được đầu-cuối — và không ai nghiệm thu được từng cái riêng.
---
## Bước 3 · Nguồn của rule quyết định độ cứng
| Rule | Domain | Nguồn | Được đề xuất bỏ không |
|---|---|---|---|
| "Hồ sơ bệnh án lưu tối thiểu 10 năm" | Y tế | 🔴 Quy định pháp luật | Không — chỉ tuân thủ, ghi rõ điều khoản |
| "Chênh lệch > 10 triệu cần trưởng phòng duyệt" | Bán lẻ | 🟠 Chính sách công ty | Có, qua cấp ký chính sách |
| "Mã cửa hàng phải viết hoa" | Bán lẻ | 🟢 Thói quen nội bộ | Có — **và nên hỏi**, thường không ai nhớ vì sao có |
Hỏi nguồn của mọi rule. Ba loại này có độ cứng hoàn toàn khác nhau, và gộp chúng lại làm mất
khả năng đàm phán ở đúng chỗ đáng đàm phán.
---
## Bước 3 · Công thức tính toán — chỗ hay sai
```
BR-045 | Chênh lệch đối soát
Công thức: tổng POS − tổng hệ thống
Đơn vị: VND
🔴 Thứ tự: làm tròn TỪNG DÒNG tới đơn vị rồi mới cộng
(khác với cộng rồi làm tròn — lệch tới vài nghìn đồng/ngày)
Múi giờ: giao dịch tính theo ngày làm việc của cửa hàng (UTC+7),
KHÔNG theo timestamp UTC của bản ghi
Ví dụ: 1.234.567 − 1.234.000 = 567
```
Ba thứ phải ghi rõ ở mọi công thức, ở mọi domain: **thứ tự phép tính** · **làm tròn ở bước
nào** · **múi giờ / đơn vị**.
---
## Bước 4 · Ma trận phân quyền — hỏi câu phủ định
Ma trận toàn ✅ nghĩa là chưa phân tích. Hỏi *"vai trò nào KHÔNG được làm việc này?"*
| Hành động | Nhân viên | Trưởng nhóm | Kế toán | Admin |
|---|---|---|---|---|
| Xem danh sách | 🔶 chỉ cửa hàng phụ trách | ✅ | ✅ | ✅ |
| Duyệt chênh lệch | ❌ | 🔶 **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 | ✅ | ✅ | ✅ |
Chú ý ô Admin ở dòng "Duyệt": ❌. Admin có mọi quyền kỹ thuật nhưng **không có thẩm quyền
nghiệp vụ** — đây là chỗ ma trận hay bị điền sai theo quán tính.
Ô `🔶` **bắt buộc ghi điều kiện ngay trong ô**. `🔶` trống là ô chưa phân tích xong.
---
## Bước 5 · Dữ liệu cũ — ba lựa chọn, phải chọn một
| Domain | Tình huống | Lựa chọn | Chi phí kèm theo |
|---|---|---|---|
| Bán lẻ | Thêm cột "loại cửa hàng", 12.000 bản ghi cũ null | **Migrate** — điền `THƯỜNG` | Script + đối chiếu count sau khi chạy |
| Y tế | Đổi quy tắc mã hồ sơ từ 2026 | **Song song** — hồ sơ cũ giữ mã cũ | Quy tắc phân biệt phải hiển thị được cho điều dưỡng |
| Logistics | Thêm trường "nhiệt độ" cho lô hàng lạnh | **Giữ nguyên** — lô cũ không có | Chấp nhận báo cáo trước 2026 không có cột này; **phải báo người đọc báo cáo** |
"Sẽ xử lý sau" không phải câu trả lời. Chưa đủ thông tin để chọn ⇒ `OQ` có người và có hạn.

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`