sys-analysis-design/.claude/skills/ba-1-discovery/templates/project-brief.md

BRIEF — <Tên module/dự án>

Version	1.0
Date	YYYY-MM-DD
Author	(skill ba-1-discovery)
Status	🟡 Draft
Approved by	—
Source	<liệt kê file/biên bản đã dùng, mỗi cái một dòng>
Scope	<module / US id>

Change Log

Version	Date	Người sửa	Thay đổi	CR
1.0	YYYY-MM-DD		Bản đầu	—

---

1. Tóm tắt cho người quyết định

Ba câu. Đọc xong biết: vấn đề gì, làm gì, được gì. Viết mục này SAU CÙNG.

---

2. Bối cảnh

Hiện tại việc này đang diễn ra thế nào? Ai làm, tần suất bao nhiêu, mất bao lâu, bằng công cụ gì. Chỉ nêu sự thật quan sát được, kèm nguồn.

Thông tin hiện trạng	Giá trị	Nguồn
Số giao dịch/ngày
Số người thao tác
Thời gian xử lý trung bình
Tỷ lệ sai sót hiện tại

3. Phát biểu bài toán

Vấn đề: gặp <khó khăn gì> khi <làm việc gì>, dẫn tới <hậu quả đo được>.

❌ Không viết giải pháp ở đây ("cần thêm màn hình…", "cần nút export…"). ✅ Viết vấn đề đo được ("mất trung bình 2 giờ/ngày đối chiếu thủ công, sai sót 3–5 ca/tháng").

Bằng chứng của vấn đề:

#	Bằng chứng	Nguồn	Loại
1		STK-nn, biên bản ngày…	Sự thật / Ý kiến

Điều gì xảy ra nếu không làm gì cả? (câu này quyết định dự án có đáng làm không)

4. Mục tiêu kinh doanh & KPI

ID	Mục tiêu	Baseline hiện tại	Mục tiêu	Cách đo	Ai đo	Tần suất
GOAL-01
GOAL-02

🔴 Baseline trống ⇒ ghi OQ kèm đề xuất cách đo. Không có baseline thì GĐ5 không có gì để so sánh, và "dự án có thành công không" sẽ thành tranh cãi cảm tính.

5. Phạm vi

5.1 Trong phạm vi

#	Hạng mục	Vì sao cần	RQ liên quan
1			RQ-001

5.2 Ngoài phạm vi (quan trọng hơn mục 5.1)

#	Hạng mục	Lý do loại	Xử lý ở đâu / khi nào
1

5.3 Ranh giới hệ thống

Hệ thống nào nằm trong, hệ thống nào chỉ tích hợp, dữ liệu đi qua đâu.

flowchart LR
    NGUOIDUNG(["👤 Vai trò sử dụng"])

    subgraph PHAMVI["Trong phạm vi dự án"]
        HT["Hệ thống đang xây"]
    end

    HTA[["Hệ thống A — chỉ tích hợp"]]
    HTB[["Hệ thống B — ngoài phạm vi"]]

    NGUOIDUNG --> HT
    HT <--> HTA
    HT --> HTB

Khung đôi [[ ]] = ngoài phạm vi dự án. Mũi tên hai chiều = có trao đổi dữ liệu hai chiều.

Hệ thống	Trong/Ngoài phạm vi	Dữ liệu trao đổi	Chiều	Đầu mối

Bảng này là phần bắt buộc đi kèm sơ đồ (quy tắc W13) — sơ đồ không nói được dữ liệu gì đi qua và ai chịu trách nhiệm.

6. Yêu cầu mức nghiệp vụ

ID	Phát biểu yêu cầu	Nguồn (STK + ngày)	MoSCoW	GOAL	Giải pháp khách gợi ý
RQ-001		STK-01, 2026-08-22	Must	GOAL-01
RQ-002			Should

Kiểm tra phân bổ MoSCoW: Must ≤ 60% tổng số. Vượt ⇒ chưa phân loại thật, quay lại hỏi PO "nếu chỉ kịp một nửa thì cắt cái nào".

MoSCoW	Nghĩa chính xác
Must	Không có thì bản phát hành này vô nghĩa
Should	Quan trọng, nhưng thiếu vẫn dùng được, có cách làm thủ công tạm
Could	Có thì tốt, cắt đầu tiên khi thiếu thời gian
Won't (this time)	Đã bàn và thống nhất không làm lần này — ghi để khỏi bàn lại

7. Ràng buộc

Loại	Nội dung	Nguồn	Ảnh hưởng
Thời gian
Ngân sách / nguồn lực
Công nghệ
Pháp lý / tuân thủ
Tổ chức / quy trình

8. Giả định và rủi ro

Chi tiết ở RISK_<...>.md. Ở đây chỉ nêu những cái ảnh hưởng tới phạm vi.

ID	Nội dung	Nếu sai thì sao
ASM-01
RISK-01

9. Tiêu chí thành công của giai đoạn

Khi nào coi là "làm xong và làm đúng"? Khác với KPI ở mục 4 — mục này nói về sản phẩm, mục 4 nói về hiệu quả kinh doanh.

10. Open Questions

ID	Câu hỏi	Hỏi ai	Từ ngày	Chặn gì	Phương án BA đề xuất
OQ-001					(đề xuất, chưa phải quyết định)

11. Ngoài phạm vi tài liệu này

Những gì người đọc có thể tưởng là có trong tài liệu này nhưng không có, và tìm ở đâu.

• Thiết kế màn hình → GĐ3, SRS
• Quy trình chi tiết từng bước → GĐ2, PROCESS
• Ước lượng công sức → PM

---

Tự chấm

Gate G1

#	Tiêu chí	☐/✅	Ghi chú
1	BRIEF có bối cảnh, phát biểu bài toán, phạm vi in/out, GOAL kèm KPI
2	STAKEHOLDER đủ 4 nhóm, có tên thật
3	ELICITATION có ≥1 buổi với nhóm quyết định và nhóm sử dụng
4	RQ có MoSCoW, truy về được stakeholder cụ thể
5	RISK/ASM đã ghi, rủi ro cao có người chịu trách nhiệm
6	KPI có baseline

Quy tắc viết W1–W13 — xem ../ba-lifecycle/references/writing-rules.md

W1	W2	W3	W4	W5	W6	W7	W8	W9	W10	W11	W12	W13