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

improve BA skill

Browse Source
This commit is contained in:
Leonard-ThindPad-P50
2026-09-09 06:34:57 +07:00
parent 119792967c
commit 2c7bcde741
42 changed files with 5429 additions and 54 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
.claude/skills/ba-lifecycle/SKILL.md
View File

@@ -68,9 +68,11 @@ bảng "Thêm ở strict". Ghi mức đang chấm ngay đầu bảng pipeline.
Chấm **thật**: mở artifact và kiểm tra mục bắt buộc có nội dung hay chỉ là khung rỗng. Một
file tồn tại nhưng các mục còn `TBD` ⇒ **chưa đạt**, không được đánh ✅.
**Tiêu chí phụ thuộc `PRODUCT`**: dòng "bảng field" và "wireframe" của G3 chỉ áp cho
`PRODUCT = screen`. Loại khác dùng tiêu chí ghi ở đầu file
`ba-3-specification/templates/srs-part2/<loại>.md`.
**Tiêu chí phụ thuộc `PRODUCT`**: dòng "bảng field" và bốn dòng *(screen)* của G3 (`UICONV`
tồn tại và có chữ ký Designer · `WF` phủ mọi SCR, `C-id` khớp hai chiều · `WF` §5 không còn lệch
Tồn tại/Hành vi chưa quyết · WF ✏️ có Designer ký) chỉ áp cho `PRODUCT = screen`. Loại khác
dùng tiêu chí ghi ở đầu file `ba-3-specification/templates/srs-part2/<loại>.md`.
Khi chấm G3 cho `screen`, mở cả `00-index/UICONV_*.md` và `03-specification/WF_*.md`.
Ba trạng thái, không có trạng thái thứ tư:

15
.claude/skills/ba-lifecycle/references/artifact-map.md
View File

@@ -17,7 +17,8 @@
| `AC` | Acceptance Criteria (nếu tách khỏi SRS) | `03-specification/` | ba-3 | QA |
| `API` | API contract đề xuất | `03-specification/` | ba-3 | Dev BE/FE |
| `NFR` | Yêu cầu phi chức năng | `03-specification/` | ba-3 | Dev, Ops, QA |
| `WF` | Wireframe / Prototype | `03-specification/` | ba-3 | Dev, PO |
| `WF` | Wireframe & bố cục (`.md` bảng vùng/thành phần/lệch + `.html` low-fi) — chỉ `PRODUCT = screen` | `03-specification/` | ba-3 (activity `wf`) | Dev FE, Designer, PO |
| `UICONV` | Quy ước giao diện cấp project — chỉ `PRODUCT = screen`, sinh một lần | `00-index/` | ba-3 (activity `uiconv`) | Dev FE, Designer, mọi SRS/WF |
| `QLOG` | Clarification log | `04-delivery/` | ba-4 | Dev, QA |
| `CR` | Change Request | `04-delivery/` | ba-4 | PO, PM, Dev |
| `TCREVIEW` | Biên bản review test case | `04-delivery/` | ba-4 | QA |
@@ -128,14 +129,22 @@ flowchart LR
SRS --> AC["AC"]
SRS --> API["API"]
SRS --> NFR["NFR"]
SRS --> WF["WF"]
UICONV["UICONV"] --> SRS
UICONV --> WF["WF"]
SRS --> WF
PROTO[["Prototype / design system (ngoài bộ BA)"]] -.-> UICONV
PROTO -.-> WF
AC --> UAT["UAT"]
UAT --> BENEFIT["BENEFIT"]
UAT --> RELNOTE["RELNOTE"]
UAT --> MANUAL["MANUAL"]
```
**RTM đọc:** `BRIEF`(RQ) · `BACKLOG`(US) · `SRS`+`AC`(AC, field, mã lỗi) · `UAT`(test case) · `CR`
**RTM đọc:** `BRIEF`(RQ) · `BACKLOG`(US) · `SRS`+`AC`(AC, field, mã lỗi) · `WF`(C-id, SCR) · `UAT`(test case) · `CR`
`WF` và `UICONV` chỉ tồn tại khi `PRODUCT = screen`. `WF` **không** là nguồn sự thật về hành
vi — nó tham chiếu ngược về `SRS`; đổi prototype ⇒ đổi `WF`, `SRS` chỉ đổi khi lệch loại
Tồn tại/Hành vi được PO chấp nhận (qua `CR` nếu SRS đã Baselined).
Đọc xuôi mũi tên để biết **sửa cái này thì phải sửa tiếp cái nào**. Ví dụ sửa một `BR` ⇒
phải rà lại `SRS`, `AC`, test case, và cập nhật `RTM`.

2
.claude/skills/ba-lifecycle/references/diagram-rules.md
View File

@@ -267,7 +267,7 @@ Ba trường hợp, và cách xử lý:
| Trường hợp | Làm gì |
|---|---|
| Bố cục màn hình | Wireframe ảnh — mermaid không phải công cụ vẽ UI |
| Bố cục màn hình | `WF_<US>.md` (bảng vùng + bảng vị trí thành phần) **và** `WF_<US>.html` low-fi sinh từ `ba-3-specification/templates/wireframe.html` — mermaid không phải công cụ vẽ UI, ASCII art càng không. Có prototype thì WF ghi lại và đối chiếu; không có thì WF là đề xuất của BA |
| Ma trận ≥ 3×3, bảng số liệu | Bảng markdown |
| Sơ đồ > 20 node | Tách thành nhiều sơ đồ theo phân vùng, mỗi cái một mục con |

2
.claude/skills/ba-lifecycle/references/domain-profiles.md
View File

@@ -116,7 +116,7 @@ Quyết định **gate chặt tới đâu và ai phải ký**. `standard` là ba
| Giá trị | Dùng khi | Ký gate |
|---|---|---|
| `light` | POC, thử nghiệm, công cụ nội bộ ≤ 2 tuần, không đụng tiền/dữ liệu cá nhân | Chỉ PO |
| `standard` | Mặc định — sản phẩm thật, có người dùng thật | PO + Tech Lead + QA (theo từng gate) |
| `standard` | Mặc định — sản phẩm thật, có người dùng thật | PO + Tech Lead + QA (theo từng gate); `PRODUCT = screen` thêm **Designer ở G3** (`UICONV`, `WF`) |
| `strict` | Có tiền, dữ liệu cá nhân, yêu cầu pháp lý, chịu kiểm toán (tài chính, y tế, bảo hiểm) | Như standard **+ Bảo mật/Pháp chế ở G2 và G3** |
Chi tiết tiêu chí bớt/thêm theo từng gate: [workflow.md §2.0](workflow.md).

29
.claude/skills/ba-lifecycle/references/workflow.md
View File

@@ -15,7 +15,7 @@ flowchart TD
START --> GD1
GD1 -->|"G1 — PO ký: bài toán & phạm vi đã đúng"| GD2
GD2 -->|"G2 — PO + Tech Lead ký: khả thi, backlog đủ"| GD3
GD3 -->|"G3 — PO + Tech Lead + QA ký: Ready for Dev"| GD4
GD3 -->|"G3 — PO + Tech Lead + QA (+ Designer nếu screen) ký: Ready for Dev"| GD4
GD4 -->|"G4 — PO ký UAT pass: Go-live"| GD5
GD5 -->|"G5 — Benefit review"| END
@@ -91,7 +91,7 @@ giải quyết được pain point đã ghi ở G1.
| `IMPACT` rút gọn: chỉ trục dữ liệu và tích hợp | Mọi `ASM` phải chuyển sang **đã xác minh** trước khi qua G2 (thay vì trước G3) |
| Ký: chỉ PO | Ký: PO + Tech Lead + Bảo mật |
### G3 — Ready for Dev · duyệt bởi **PO + Tech Lead + QA**
### G3 — Ready for Dev · duyệt bởi **PO + Tech Lead + QA** (+ **Designer** khi `PRODUCT = screen`)
- [ ] `SRS` đủ mọi mục bắt buộc (xem `ba-3-specification/templates/srs.md`)
- [ ] Mỗi màn hình có bảng field: kiểu, bắt buộc, độ dài, default, validation, message lỗi
@@ -99,16 +99,20 @@ giải quyết được pain point đã ghi ở G1.
- [ ] Bảng mã lỗi `E-<DOMAIN>-nnnn` đầy đủ, mỗi mã có thông điệp hiển thị
- [ ] `NFR` đã chốt cho các nhóm áp dụng, mỗi cái có cách verify
- [ ] `API` contract có, hoặc ghi rõ là **giả định của BA** chờ BE xác nhận
- [ ] Wireframe/prototype khớp với bảng component
- [ ] *(screen)* `UICONV_<PROJECT>` tồn tại, không còn ô "chọn một" chưa chọn, có chữ ký Designer (hoặc PO + `DEC-nn` khi dự án không có Designer)
- [ ] *(screen)* `WF_<US>` (md + html) phủ **mọi** `SCR` của SRS; tập `C-id` khớp **hai chiều** với bảng thành phần
- [ ] *(screen)* `WF` §5 (lệch prototype ↔ SRS) đã điền; không còn lệch **Tồn tại/Hành vi** chưa có người quyết
- [ ] *(screen)* `WF` chế độ ✏️ (BA tự dựng) có chữ ký Designer; chế độ 🎨 (prototype tham chiếu) có PO xác nhận §1 và §5
- [ ] QA xác nhận **mọi AC đều test được** — AC không test được là AC chưa viết xong
- [ ] Không còn `OQ` mở nào ảnh hưởng tới hành vi hệ thống
- [ ] `ba-traceability` báo coverage US→AC và AC→test case ≥ 100%
- [ ] `ba-traceability` báo coverage US→AC và AC→test case ≥ 100%, và *(screen)* SRS↔WF `C-id` lệch = 0
**Chặn:** còn bất kỳ `TBD` nào trong bảng field hoặc bảng mã lỗi. Còn `OQ` mở về hành vi.
*(screen)* Còn lệch Tồn tại/Hành vi giữa prototype và SRS chưa quyết.
**Đây là gate nghiêm nhất** — một chỗ mơ hồ lọt qua G3 sẽ thành một bug hoặc một CR.
> Checklist trên viết theo `PRODUCT = screen`. Loại khác thì dòng "bảng field" và "wireframe"
> được thay bằng tiêu chí tương ứng của biến thể PART 2 — xem đầu file
> Checklist trên viết theo `PRODUCT = screen`. Loại khác thì dòng "bảng field" và bốn dòng
> *(screen)* được thay bằng tiêu chí tương ứng của biến thể PART 2 — xem đầu file
> `ba-3-specification/templates/srs-part2/<loại>.md`.
| Bớt ở `light` | Thêm ở `strict` |
@@ -116,7 +120,8 @@ giải quyết được pain point đã ghi ở G1.
| `AC` chỉ bắt buộc nhóm 1 (thành công) và 2 (validation). Nhóm 3–4 bắt buộc **nếu** có ghi/xoá dữ liệu hoặc có >1 vai trò | Bảng lưu vết (`NFR-AUD`) bắt buộc cho mọi hành động ghi |
| `NFR` chỉ bắt buộc nhóm áp dụng rõ ràng; các nhóm khác ghi "N/A — POC" | Mọi mã lỗi phải có bản dịch đủ mọi ngôn ngữ hỗ trợ, không được để sau |
| `API` được phép là phác thảo, không cần bảng đối chiếu mã lỗi | `API` phải do BE xác nhận, **không chấp nhận contract BA tự đề xuất** |
| Không cần chữ ký QA | Ký: PO + Tech Lead + QA + Bảo mật/Pháp chế |
| *(screen)* `WF` chỉ cần bảng vùng + bảng lệch, không cần HTML; `UICONV` chỉ cần §3–§6, §8 | *(screen)* `WF` phải có responsive đủ mọi breakpoint của `UICONV` §1 và thứ tự focus cho mọi form |
| Không cần chữ ký QA; Designer không bắt buộc (PO ký `WF`) | Ký: PO + Tech Lead + QA + Designer + Bảo mật/Pháp chế |
### G4 — UAT pass · duyệt bởi **PO**
@@ -162,11 +167,17 @@ cách một POC mang theo mọi thiếu sót của nó vào sản phẩm thật.
| **PO / Khách hàng** | Quyết ưu tiên và scope. Ký G1, G4, G5. Trả lời `OQ` nghiệp vụ |
| **Tech Lead** | Ký G2, G3 về mặt khả thi. Quyết kiến trúc. Trả lời `OQ` kỹ thuật |
| **QA** | Ký G3 về tính test được. Viết test case từ AC. Chủ trì thực thi UAT |
| **Dev** | Tiêu thụ SRS. Đặt `OQ` qua `QLOG` |
| **Designer** *(khi `PRODUCT = screen`)* | Sở hữu prototype, design system, visual. Ký `UICONV` và `WF` ở G3. Trả lời lệch loại *Bố cục* ở `WF` §5. Nhận từ BA: kho thành phần, text nguyên văn, trạng thái, phân quyền hiển thị — **không phải đi hỏi lại nghiệp vụ** |
| **Dev** | Tiêu thụ SRS + WF + UICONV. Đặt `OQ` qua `QLOG` |
| **PM** | Tiến độ, nguồn lực. Không ký gate nội dung |
BA **không** thay PO quyết ưu tiên, **không** thay Tech Lead chọn kiến trúc, **không** thay
PM quản tiến độ — nhưng phải cung cấp đủ thông tin để cả ba ra quyết định.
PM quản tiến độ, **không** thay Designer quyết visual — nhưng phải cung cấp đủ thông tin để
cả bốn ra quyết định. Riêng phần **bố cục và trạng thái**, BA làm được khi có prototype tham
chiếu (chế độ 🎨 của `WF`); không có thì BA đề xuất, Designer quyết (chế độ ✏️).
**Dự án không có Designer:** ghi `DEC-nn`, PO ký thay `UICONV`/`WF`, và mục §6 của `WF`
("Designer còn phải làm") chuyển thành việc của dev FE — nêu đích danh.
## 4. Khi nào được bỏ giai đoạn

11
.claude/skills/ba-lifecycle/references/writing-rules.md
View File

@@ -83,9 +83,12 @@ Một tài liệu, ba mục tiêu. Đừng viết SRS chỉ cho dev đọc.
## W11 — Ảnh không thay lời
Wireframe minh hoạ bố cục. Hành vi luôn nằm ở bảng component và AC. Khi ảnh và bảng mâu
thuẫn: **bảng thắng về việc "có tồn tại không"**, ảnh thắng về "nằm ở đâu, to bằng nào".
Ghi rõ quy tắc này trong mỗi tài liệu có ảnh.
Wireframe (`WF`) và prototype minh hoạ bố cục. Hành vi luôn nằm ở bảng component và AC. Khi
hình và bảng mâu thuẫn: **bảng thắng về "có tồn tại không" và "hành xử thế nào"**, hình thắng
về "nằm ở đâu, to bằng nào". Ghi rõ quy tắc này trong mỗi tài liệu có hình, và **ghi từng
mâu thuẫn vào `WF` §5** kèm người quyết — mâu thuẫn không ghi là mâu thuẫn dev sẽ tự xử.
Hệ quả: prototype có thành phần mà SRS không có ⇒ không tự thêm vào SRS; đó là scope creep
bằng hình ảnh, PO quyết.
## W12 — Ghi cả cái tài liệu KHÔNG nói
@@ -130,7 +133,7 @@ Sơ đồ mâu thuẫn bảng ⇒ **bảng thắng** (hệ quả của W11).
[ ] W8 Mọi chỗ chưa rõ là OQ, không phải quyết định ngầm
[ ] W9 Mọi AC/BR/field có tham chiếu ngược
[ ] W10 Có tóm tắt nghiệp vụ cho PO ở đầu
[ ] W11 Có câu quy định ảnh vs bảng
[ ] W11 Có câu quy định ảnh vs bảng; (screen) mọi lệch prototype ↔ SRS nằm ở WF §5
[ ] W12 Có mục "Ngoài phạm vi"
[ ] W13 Sơ đồ dùng mermaid (không ASCII), và mỗi sơ đồ có bảng đi kèm
```