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

name, description

name

description

ba-2-analysis

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ơ đồ theo chuẩn Archify (W13, ../ba-lifecycle/references/diagram-rules.md): spec JSON diagrams/<ARTIFACT>_<slug>.<type>.json (quality_profile: showcase, validate 0 lỗi) + mermaid có marker <!-- archify: <type> · <spec> --> (hoặc mermaid-only cho ERD/use case/2×2) + bảng đi kèm. Một đường chính, ≤ 12 node, nhãn cạnh là điều kiện/giao thức, không màu. Không có Bash ⇒ ghi humanInputNeeded "chạy archify validate/deliver + diagram-check", không tự nhận đã validate. Quy trình → workflow · vòng đời → lifecycle · use case, cây RQ→US, ERD → mermaid-only. Spec mẫu đã pass: templates/diagrams/PROCESS_to-be.workflow.json, templates/diagrams/BR_vong-doi.lifecycle.json. 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:

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ì
Independent	Làm được mà không cần US khác xong trước?	Ghi phụ thuộc vào cột riêng
Negotiable	Mô tả cái gì, không mô tả code thế nào?	Bỏ chi tiết kỹ thuật xuống GĐ3
Valuable	Vế "để" có giá trị thật cho vai trò đó?	Gộp vào US khác hoặc bỏ
Estimable	Dev nhìn vào ước lượng được?	Thiếu thông tin ⇒ OQ
Small	Làm gọn trong một sprint?	Tách nhỏ — xem 4 cách tách bên dưới
Testable	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.