# Skill: Phân tích yêu cầu ban đầu (BA Analyst) - Phiên bản v1

## 1. Mục đích (Purpose)
Kỹ năng này giúp Business Analyst (hoặc Agent) quét, đọc hiểu và cấu trúc hóa các yêu cầu thô được cung cấp bởi khách hàng hoặc các stakeholders. Mục tiêu là phân tách rõ ràng giữa các thông tin thực tế (Facts) và các giả định (Assumptions), phát hiện các khoảng trống nghiệp vụ (Gaps), và tạo cơ sở cho việc lập danh sách câu hỏi làm rõ (Q&A) cũng như dự thảo spec ban đầu.

Ngôn ngữ output: auto-detect theo ngôn ngữ của ticket/task input — xem `custom/rules/output-language.md` (input tiếng Việt → output tiếng Việt; ngược lại mặc định tiếng Anh).

## 2. Kiến thức cần có (Prerequisite Knowledge)
- **Tư duy phân tích (Analytical Thinking):** Khả năng chia nhỏ một yêu cầu lớn thành các luồng nghiệp vụ nhỏ và các thành phần cấu thành.
- **Phân biệt Fact vs. Assumption:**
  - *Fact (Sự thật):* Thông tin được ghi rõ ràng trong tài liệu, được khẳng định từ khách hàng.
  - *Assumption (Giả định):* Những giả thiết do BA đưa ra dựa trên kinh nghiệm hoặc ngữ cảnh mà chưa được khách hàng xác nhận bằng văn bản.
- **Kỹ thuật Gap Analysis:** Kỹ thuật nhận diện các điểm chưa thống nhất, các thông tin bị thiếu (ví dụ: thiếu thông báo lỗi khi validate thất bại, thiếu quy tắc lưu trữ vào cơ sở dữ liệu, thiếu mô tả quyền truy cập).
- **Thuật ngữ phần mềm cơ bản:** Khách hàng (Client), Người dùng (User), Tác nhân (Actor), Ràng buộc (Constraints), Luồng chính (Happy Path), Trường hợp ngoại lệ (Edge cases).

## 3. Quy trình thực hiện (Step-by-step Process)
- **Bước 1: Tiếp nhận và đọc quét (Read & Scan):**
  Đọc toàn bộ tài liệu đầu vào (ví dụ trong folder `TÀI LIỆU/input/`) ít nhất 2 lần để nắm bức tranh tổng thể và ngữ cảnh nghiệp vụ.
  Sau đó đọc source code liên quan (nếu workspace có source repos):
  - Ưu tiên đọc: data models/entity, API endpoints hiện tại, service/business logic
  - Mục đích: hiểu hệ thống đang tồn tại, tìm constraints kỹ thuật, tránh đề xuất mâu thuẫn architecture
  - Nếu GitNexus MCP có sẵn: dùng `gitnexus: query()` / `gitnexus: context()` thay vì đọc file trực tiếp
- **Bước 2: Phân loại thông tin (Categorize):**
  Trích xuất các thông tin theo các cấu trúc:
    - Mục tiêu của chức năng.
    - Các tác nhân tham gia vào luồng.
    - Các yêu cầu chức năng (các hành động, nút bấm, trường thông tin).
    - Các yêu cầu phi chức năng (bảo mật, hiệu năng, nền tảng hệ điều hành/trình duyệt).
- **Bước 3: Nhận diện và ghi nhận Gap (Identify Gaps):**
  Đối chiếu từng yêu cầu chức năng với các câu hỏi:
    - Dữ liệu đầu vào của trường này có giới hạn độ dài/định dạng không?
    - Nếu để trống thì hệ thống xử lý thế nào? Có thông báo lỗi gì không?
    - Có quy tắc nghiệp vụ (Business rules) ngầm định nào không?
    - Luồng thay thế (Alternative flows) hoặc luồng lỗi (Exception flows) là gì?

  Số lượng Gap tìm được phải tăng theo độ phức tạp thực tế của yêu cầu — KHÔNG dừng lại khi "cảm thấy đủ" hoặc đã đạt một số lượng quen thuộc (ví dụ 5-6 điểm) nếu còn trường/luồng/actor chưa được đối chiếu hết qua 4 câu hỏi trên. Với yêu cầu nhiều màn hình/nhiều actor/tích hợp hệ thống khác, quét từng màn hình/actor riêng biệt rồi tổng hợp, không gộp tắt.
  Với mỗi Gap, gắn nhãn mức độ ảnh hưởng ngay: 🔴 **Blocking** (ảnh hưởng cấu trúc dữ liệu, luồng chính, phân quyền/bảo mật, hoặc quyết định khó đảo ngược) hoặc 🟡 **Non-blocking** (chi tiết UI/text, giá trị mặc định có thể đổi sau, luồng hiếm gặp).
- **Bước 4: Soạn dự thảo Kết quả phân tích ban đầu:**
  Áp dụng template phân tích ban đầu (`skill-ba-initial-analysis-template-v1.md`) để điền thông tin và lập bảng Gap/Assumption, kèm cột Mức độ ảnh hưởng cho mỗi Gap.

## 4. Checklist kiểm tra (Checklist for Verification)
- [ ] Đã xác định rõ Mục tiêu hệ thống/chức năng chưa? (Hệ thống giải quyết bài toán gì?)
- [ ] Đã làm rõ tất cả các Tác nhân (Actors) tham gia chưa?
- [ ] Đã bóc tách hết các trường thông tin (Inputs) được liệt kê trong tài liệu thô chưa?
- [ ] Đã ghi nhận rõ ràng danh sách các điểm mơ hồ hoặc thiếu thông tin dưới dạng **Gap/Assumption** chưa?
- [ ] Số lượng Gap tìm được có phản ánh đúng độ phức tạp thực tế (nhiều màn hình/actor/luồng → nhiều Gap hơn), không bị gò về một số cố định không?
- [ ] Mỗi Gap đã có nhãn Mức độ ảnh hưởng (🔴 Blocking / 🟡 Non-blocking) chưa?
- [ ] Không tự tiện bổ sung các tính năng ngoài phạm vi yêu cầu của khách hàng khi chưa có thảo luận/Q&A.

## 5. Output mong đợi (Expected Output)
- File tài liệu phân tích ban đầu định dạng markdown, cấu trúc thống nhất dựa theo `@skill-ba-initial-analysis-template-v1.md`, đặt tên theo chuẩn: `Analysis_v(n).md` trong thư mục `02.BA-Specs/01.Analysis/[functionId]/`.