Phân rã chức năng (Functional Decomposition)

Biến mô tả hệ thống thành một cây chức năng đủ nhỏ để ước lượng, viết user story và kiểm thử; mỗi nút có ID ổn định, actor, nguồn yêu cầu, và được kiểm chứng bằng lint (MECE, CRUD, xuyên suốt, truy vết). AI chỉ phác thảo bản nháp; việc xác nhận nghiệp vụ thuộc về người vận hành và stakeholder.

Chọn chế độ

Đối chiếu yêu cầu ↔ chức năng và phân tích tác động khi yêu cầu đổi đều dùng chung spec (references/traceability.md).

Chế độ A: Phân rã (6 bước)

1. Phạm vi và biên - mục tiêu 1–2 dòng, scope.in / scope.out, giả định.
2. Actor và đối tượng nghiệp vụ - ai dùng; hệ thống lưu giữ "danh từ" nào cần theo dõi vòng đời (đối tượng nào do hệ thống khác sở hữu thì source: external).
3. Cấp 1: năng lực - 4–9 module theo năng lực nghiệp vụ, không theo màn hình hay phòng ban; có domain pack thì lấy capability map làm khung.
4. Cấp 2–3: tính năng → chức năng - lá là hành động nguyên tử, tên Động từ + Danh từ, gắn actor và ưu tiên; qua "hàm test nguyên tử" (levels-and-depth.md).
5. Kiểm MECE, CRUD, xuyên suốt - mọi đối tượng đủ Tạo/Xem/Sửa/Hủy (hoặc miễn trừ có lý do); có xác thực, thông báo, nhật ký, báo cáo, cấu hình (hoặc miễn trừ).
6. Truy vết và lint - gắn reqs (chức năng suy ra thì derived), chạy fd_lint.py tới 0 lỗi, giải thích các cảnh báo còn lại.

Ở mỗi bước, ghi quyết định theo mẫu Làm gì → Vì sao làm vậy → Vì sao không làm cách khác.

Thiếu thông tin thì hỏi gì

Chỉ hỏi khi mô tả chưa nêu (tối đa 4 câu, một lượt): (1) hệ thống thuộc lĩnh vực/mô hình nào và dành cho ai, (2) đâu là ngoài phạm vi, (3) có danh sách yêu cầu hoặc tài liệu nguồn không, (4) mức chi tiết mong muốn (thống nhất phạm vi, ước lượng, hay backlog). Không đủ thì làm theo giả định ghi rõ và đừng bịa chức năng.

Domain knowledge

Nếu hệ thống thuộc lĩnh vực có domain pack - domain-banking, domain-ecommerce (xem thêm skills/domain-*) - nạp pack đó: lấy capability map làm khung cấp 1, đối chiếu checklist.md và business-rules.md để tìm chức năng bắt buộc mà stakeholder không nhắc, thêm chúng với derived: true và note bắt đầu bằng [domain], rồi hỏi stakeholder xác nhận. Chưa có pack: hỏi một câu về lĩnh vực hoặc nêu giả định. Chi tiết: references/domain-integration.md.

Đầu ra

Viết một spec JSON (định dạng: references/output-formats.md, mẫu: examples/*/spec.json), rồi sinh mọi định dạng từ đó:

python3 scripts/fd_lint.py             spec.json                # phải 0 lỗi trước khi giao
python3 scripts/spec_to_table.py       spec.json hierarchy.md   # bảng phân cấp, CRUD, truy vết, Actor × Module
python3 scripts/spec_to_mermaid.py     spec.json diagram.mmd    # vòng nháp; tự giữ ≤ 40 node, --split theo module
python3 scripts/spec_to_svg.py         spec.json diagram.svg    # hình đẹp để chèn tài liệu
python3 scripts/spec_to_csv.py         spec.json tree.csv       # Excel/Sheets; thêm --jira cho Jira
python3 scripts/build_explorer_page.py spec.json explorer.html  # trang lọc theo actor/ưu tiên, xem CRUD, truy vết, lint
python3 scripts/outline_to_spec.py     outline.txt spec.json    # chế độ Soát: dựng spec khung từ danh sách có sẵn
sh scripts/build_all.sh spec.json thu-muc-dau-ra                # chạy tất cả

• Vòng nháp: bảng + Mermaid để người dùng soát nội dung nhanh.
• Vòng cuối (khi đã chốt nội dung): lint 0 lỗi + SVG + explorer; CSV khi cần đưa vào công cụ quản lý.
• Mermaid chỉ vẽ tới độ sâu vừa 40 node; cây lớn dùng --module hoặc --split.
• Màu SVG/HTML chỉnh trong assets/svg-theme.css.

Báo cáo kèm theo (luôn có)

Theo mẫu assets/report-template.md:

• Phạm vi và giả định.
• Bảng tóm tắt: module → tính năng → chức năng, actor, ưu tiên.
• Bảng quyết định cấu trúc: lựa chọn không hiển nhiên, mỗi dòng có "vì sao làm / vì sao không".
• CRUD và truy vết: ô thiếu, yêu cầu chưa phủ, chức năng derived cần xác nhận.
• Kết quả lint: số lỗi/cảnh báo/miễn trừ, đã sửa gì.
• Danh sách giả định và 3–5 câu hỏi cho stakeholder.

Quy tắc chất lượng

• Phân rã theo năng lực, không theo màn hình, phòng ban hay bảng dữ liệu; cây là cấu trúc, không có thứ tự (thứ tự thuộc BPMN).
• Mỗi nút 2–9 con; lá là chức năng nguyên tử, tên Động từ + Danh từ, không "Quản lý X".
• ID ổn định 1 / 1.1 / 1.1.1; không đánh lại số, không tái sử dụng ID đã bỏ.
• Mọi chức năng có nguồn: reqs, hoặc derived: true kèm lý do. Không bịa chức năng "nghe hợp lý": đưa vào giả định.
• Không bịa giá trị nghiệp vụ (hạn mức, thời hạn): ghi [xác nhận]; không khẳng định quy định pháp lý.
• Miễn trừ cảnh báo bằng waive kèm lý do; không xóa cảnh báo âm thầm.
• Dữ liệu nhạy cảm: nếu người dùng dán dữ liệu thật (tên, số tài khoản), nhắc thay bằng dữ liệu giả.
• Dùng tên chung cho ví dụ; không gắn thương hiệu thật nếu người dùng không yêu cầu.
• Lint chỉ kiểm cấu trúc và thói quen đặt tên (B1, B3, B4, B5 là heuristic, có thể báo oan); việc đúng nghiệp vụ cần người xác nhận.

Chuỗi skill

Biên bản → yêu cầu (meeting-to-requirements) → phân rã chức năng → user story + AC (user-story-writer) → chất lượng yêu cầu (requirements-linter); quy trình chi tiết (bpmn-modeling), trạng thái/ERD/context (ba-diagrams). Gợi ý bước tiếp theo ở cuối báo cáo.

Tham chiếu