Tuần 1 • Buổi 2 — Các loại yêu cầu & tổng quan BABOK — Business Analyst Fundamentals

Tại sao phân loại requirement quan trọng?

Trong thực tế, khi stakeholder nói "tôi muốn hệ thống bán hàng dễ dùng" — đó chưa phải requirement. Đó là mong muốn mơ hồ. Công việc của BA là khai thác sâu hơn, phân loại đúng, rồi viết thành requirement cụ thể mà dev có thể implement được.

Phân loại đúng giúp BA:

Biết phải hỏi ai để làm rõ
Biết loại tài liệu nào cần viết
Ưu tiên hóa đúng — không phải mọi requirement đều quan trọng như nhau

---

4 loại requirements cơ bản

1. Business Requirements

"Tại sao" chúng ta build hệ thống này?

Đây là mục tiêu cấp cao của tổ chức, thường đến từ C-level hoặc business owner.

Ví dụ — hệ thống bán hàng của một shop thời trang:

"Tăng doanh thu online lên 30% trong năm 2025"
"Giảm thời gian xử lý đơn hàng từ 2 ngày xuống còn 4 giờ"

BA dùng business requirements để đánh giá xem một tính năng có đáng build không.

2. Stakeholder Requirements

"Cái gì" stakeholder cần để đạt được mục tiêu đó?

Là nhu cầu của từng nhóm người dùng hoặc bên liên quan.

Ví dụ — cùng hệ thống bán hàng:

Nhân viên kho: "Tôi cần thấy tồn kho real-time khi đóng gói"
Nhân viên CSKH: "Tôi cần tra cứu lịch sử đơn hàng của khách trong vòng 5 giây"
Quản lý: "Tôi cần báo cáo doanh thu theo từng nhân viên bán hàng"

3. Functional Requirements

"Hệ thống phải làm gì?"

Là hành vi cụ thể của hệ thống — thường viết dưới dạng user story hoặc use case.

Ví dụ:

"Hệ thống cho phép khách tìm sản phẩm theo tên, màu sắc, và giá"
"Khi đơn hàng được xác nhận, hệ thống tự động gửi email thông báo cho khách"
"Nhân viên kho có thể cập nhật số lượng tồn kho bằng cách scan mã vạch"

Functional requirements có thể kiểm tra được bằng test case.

4. Non-Functional Requirements (NFR)

"Hệ thống phải hoạt động như thế nào?"

Là các ràng buộc về chất lượng và hiệu suất — thường bị bỏ qua cho đến khi có sự cố.

Ví dụ:

Performance: trang chủ load trong vòng 2 giây khi có 1.000 user đồng thời
Security: mật khẩu phải được hash, không lưu dạng plaintext
Availability: hệ thống uptime 99.5% (tối đa 43 giờ downtime/năm)
Usability: người dùng mới có thể đặt hàng lần đầu trong vòng 3 phút không cần hướng dẫn

flowchart TD
    A[Yêu cau cua Stakeholder] --> B{BA phan loai}
    B --> C[Business Requirements]
    B --> D[Stakeholder Requirements]
    B --> E[Functional Requirements]
    B --> F[Non-Functional Requirements]
    C --> G[Tai sao build?]
    D --> H[Ai can gi?]
    E --> I[He thong lam gi?]
    F --> J[He thong hoat dong the nao?]

---

Tổng quan BABOK — 6 Knowledge Areas

BABOK (Business Analysis Body of Knowledge) là bộ chuẩn kiến thức quốc tế do IIBA (International Institute of Business Analysis) ban hành. BABOK không phải quy trình phải tuân theo từng bước — đó là bộ công cụ và kỹ thuật mà BA có thể lựa chọn tùy ngữ cảnh.

6 Knowledge Areas:

#	Knowledge Area	Mô tả ngắn
1	Business Analysis Planning & Monitoring	Lập kế hoạch: ai làm gì, khi nào, dùng công cụ gì
2	Elicitation & Collaboration	Thu thập yêu cầu từ stakeholder — kỹ thuật phỏng vấn, workshop
3	Requirements Life Cycle Management	Quản lý yêu cầu từ lúc phát sinh đến khi approve và trace
4	Strategy Analysis	Phân tích tình trạng hiện tại (as-is) và tương lai mong muốn (to-be)
5	Requirements Analysis & Design Definition	Phân tích sâu, mô hình hóa, và định nghĩa solution
6	Solution Evaluation	Đánh giá solution đã implement có đáp ứng mục tiêu business chưa

Trong khóa học này, chúng ta sẽ đi qua cả 6 knowledge areas theo thứ tự thực tiễn — bắt đầu từ elicitation (tuần 2-3), phân tích yêu cầu (tuần 4-5), và solution evaluation (tuần 8).

---

Tư duy phân tích & nghệ thuật đặt câu hỏi

BA giỏi không phải người biết nhiều — mà là người biết hỏi đúng câu hỏi.

Framework 5 Whys là công cụ đơn giản nhưng hiệu quả:

Tình huống: Quản lý nói "Tôi muốn thêm tính năng xem báo cáo theo giờ"

Why 1: Tại sao cần xem theo giờ? → "Để biết giờ nào bán được nhiều nhất"
Why 2: Tại sao cần biết giờ bán nhiều nhất? → "Để sắp xếp nhân sự hợp lý"
Why 3: Tại sao cần sắp xếp nhân sự hợp lý? → "Giờ cao điểm đang bị thiếu người, khách chờ lâu"
Root cause: Bài toán thực sự là tối ưu lịch làm việc theo nhu cầu thực tế.

Có thể giải quyết bằng: báo cáo theo giờ ĐÃ SẴN CÓ nhưng ai cũng bỏ qua, + alert khi queue vượt 5 phút. Không cần build tính năng mới.

---

Tự luyện

Task 1: Lấy một requirement bạn từng nghe ("app phải nhanh", "giao diện phải đẹp") và phân loại nó vào một trong 4 loại. Sau đó viết lại thành requirement cụ thể, đo lường được.
Task 2: Chọn một tính năng trong app quen dùng. Áp dụng 5 Whys để tìm ra lý do thực sự nó tồn tại.
Task 3: Trong 6 Knowledge Areas của BABOK, bạn nghĩ mình đang mạnh nhất ở area nào? Yếu nhất ở đâu? Giải thích lý do.