sys-analysis-design/.claude/skills/ba-2-analysis/SKILL.md

---
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.