Làm Business Analyst (BA) không chỉ là “nói chuyện giữa business và dev”. Nhiệm vụ cốt lõi của một BA là chuyển hóa yêu cầu của người dùng thành ngôn ngữ mà developer hiểu, tester kiểm thử được, và khách hàng hài lòng.
Nghe đơn giản, nhưng để làm được điều đó, BA cần nhiều hơn là kỹ năng giao tiếp. Thứ giúp mọi người “nói cùng một ngôn ngữ” chính là tài liệu. Và trong hàng chục loại tài liệu mà BA có thể phải viết, có 3 loại cốt lõi được xem là “xương sống” của nghề:
👉 User Story
👉 Use Case
👉 Functional Specification
Cùng BAC bóc tách xem vì sao ba loại tài liệu này lại quan trọng đến vậy và cách chúng gắn kết thành một bức tranh hoàn chỉnh của dự án nhé!
1. User Story: Khi BA nói bằng tiếng nói của người dùng
User Story là tài liệu mô tả ngắn gọn về nhu cầu của người dùng đối với một tính năng trong sản phẩm. Nó không nói quá sâu về kỹ thuật, mà tập trung vào giá trị mang lại cho người dùng.
Một User Story thường được viết theo cấu trúc chuẩn:
“As a [actor], I want to [action] so that [achievement].”
Ví dụ:
“As a customer, I want to choose my favorite driver so that I feel enjoyable and safe during my ride.”
Minh họa cho User Story
Ngắn, gọn, và rất rõ ràng. Chỉ vài dòng thôi, nhưng team hiểu được: người dùng là ai, họ muốn gì, và tại sao điều đó quan trọng.
Trong môi trường Agile/Scrum, nơi yêu cầu liên tục thay đổi, User Story là công cụ linh hoạt để đội ngũ nắm bắt nhanh mục tiêu của từng tính năng. Mỗi story thường đi kèm với:
- Acceptance Criteria: Khi nào story được xem là “done”.
- Priority: Mức độ ưu tiên trong backlog.
- Story Points / Effort: Độ phức tạp ước lượng cho dev.
👉 Tóm lại:
User Story chính là “bức tranh nhỏ” trong bức tranh lớn của hệ thống, giúp BA và team hiểu người dùng thật sự cần gì, chứ không chỉ “làm theo yêu cầu”.
2. Use Case: Khi BA kể lại hành trình người dùng tương tác với hệ thống
Nếu User Story là “một câu chuyện ngắn”, thì Use Case giống như kịch bản phim chi tiết — nơi BA mô tả cụ thể người dùng làm gì, hệ thống phản hồi ra sao, và có những tình huống ngoại lệ nào. Use Case định nghĩa rõ ràng sự tương tác giữa người dùng và hệ thống, hoặc giữa các hệ thống với nhau.
Một Use Case chuẩn thường gồm các thành phần:
- Tên Use Case (VD: UC01 – Reset Password)
- Actor: Người dùng hoặc hệ thống khác tương tác
- Mục tiêu
- Luồng chính (Main Flow) – các bước bình thường
- Luồng phụ / ngoại lệ (Alternative Flow) – khi xảy ra lỗi hoặc rẽ nhánh
Ví dụ:
UC01 – Reset Password
Actor: Customer
Main Flow:
- Customer chọn “Forgot password”
- Nhập email đăng ký
- Hệ thống gửi email có link đặt lại mật khẩu
- Customer nhấn vào link, nhập mật khẩu mới
- Hệ thống lưu thay đổi và hiển thị thông báo thành công
Alternative Flow:
2a. Nếu email không tồn tại → hiển thị lỗi “Email not found”
Loại tài liệu này cực kỳ hữu ích trong mô hình Waterfall hoặc Hybrid, nơi mà yêu cầu cần được mô tả rõ ràng, tránh hiểu sai giữa các bên. Ngoài ra, BA thường kết hợp Use Case Diagram để trực quan hóa ai đang làm gì trong hệ thống rất dễ hiểu với stakeholder không rành kỹ thuật.
👉 Tóm lại:
Use Case giúp team hình dung hành vi và luồng hoạt động của hệ thống, là cầu nối giữa mong muốn người dùng (User Story) và thiết kế chi tiết (Functional Specification).
3. Functional Specification: Khi BA nói ngôn ngữ của hệ thống
Sau khi hiểu người dùng cần gì (User Story) và hệ thống sẽ hoạt động ra sao (Use Case), bước tiếp theo là mô tả cách hệ thống thực sự được xây dựng đó là lúc Functional Specification ra đời. Functional Specification Document (FSD) là tài liệu đặc tả chức năng chi tiết, được xem là bản hướng dẫn chính thức cho developer và tester.
Một FSD thường bao gồm:
- Tổng quan hệ thống hoặc module
- Danh sách tính năng chi tiết
- Luồng dữ liệu (data flow)
- Thiết kế giao diện (mockup, wireframe)
- Quy tắc nghiệp vụ (business rules)
- Điểm tích hợp (integration points)
- Giới hạn kỹ thuật (constraints)
Cấu trúc tài liệu đặc tả chức năng (FSD)
Ví dụ đoạn mô tả trong FSD:
- Feature: Reset Password
- Input: Email hợp lệ của người dùng đã đăng ký
- Output: Email chứa link reset hợp lệ trong 15 phút
- Validation: Email phải tồn tại trong database, nếu không hiển thị “Email not found”
- Security: Token reset được mã hóa và chỉ sử dụng một lần
Functional Spec giống như bản vẽ chi tiết kỹ thuật của dự án phần mềm. Tại đây, mọi logic được thể hiện rõ ràng để tránh hiểu lầm, đồng thời giúp BA đảm bảo không bỏ sót yêu cầu nghiệp vụ nào.
👉 Tóm lại:
Functional Spec là nơi BA “nói chuyện” với dev bằng ngôn ngữ kỹ thuật, giúp hiện thực hóa mọi ý tưởng đã được định hình từ User Story và Use Case.
4. Kết luận: Biết viết chưa đủ, phải biết viết đúng loại
Một BA giỏi không chỉ dừng ở việc “biết viết tài liệu”, mà còn phải hiểu:
- Khi nào cần viết loại nào,
- Chi tiết đến đâu,
- Và viết cho ai đọc.
User Story – Use Case – Functional Specification là bộ ba tài liệu nền tảng giúp BA kết nối business và technical hiệu quả nhất.
Nếu bạn đang học nghề BA, hãy thử bài tập nhỏ:
- Chọn một tính năng quen thuộc (ví dụ: “Đăng nhập” hoặc “Thanh toán”).
- Viết User Story cho tính năng đó.
- Mở rộng thành Use Case với luồng chính và luồng phụ.
- Mô tả chi tiết trong Functional Specification.
Khi bạn làm được cả ba bước, bạn sẽ hiểu sâu hơn rằng: Cốt lõi của nghề BA không nằm ở việc viết tài liệu, mà nằm ở khả năng lắng nghe, hiểu và diễn đạt lại đúng ngôn ngữ cho từng người trong team.
Hãy theo dõi BAC's Blog để cập nhật thêm nhiều thông tin hữu ích nhé!
Nguồn tham khảo:
Internet
Nhu cầu đào tạo doanh nghiệp
BAC là đơn vị đào tạo BA đầu tiên tại Việt Nam. Đối tác chính thức của IIBA quốc tế. Ngoài các khóa học public, BAC còn có các khóa học in house dành riêng cho từng doanh nghiệp. Chương trình được thiết kế riêng theo yêu cầu của doanh nghiệp, giúp doanh nghiệp giải quyết những khó khăn và tư vấn phát triển.
CÁC KHOÁ HỌC BUSINESS ANALYST BACs.VN DÀNH CHO BẠN
Khoá học Online:
Khoá học Offline:
Tại Tp.HCM:
Tại Hà Nội:
Tham khảo lịch khai giảng TẤT CẢ các khóa học mới nhất
Ban biên tập nội dung - BAC