Mở đầu — vì sao bài này quan trọng
Khi bạn còn làm Marketing, bạn đã quen với việc mô tả "khách hàng làm gì" trên hành trình mua hàng: họ thấy quảng cáo, click vào landing page, điền form, nhận email, rồi mua. Nhưng khi chuyển sang BA, bạn không chỉ mô tả hành vi nữa — bạn phải đặc tả chính xác hệ thống phần mềm phải làm gì để đáp ứng từng tương tác đó. Đây chính là lúc Use Case Diagram và Use Case Specification phát huy sức mạnh.
Use Case là một trong những công cụ "đắt giá" nhất của BA vì nó nằm đúng ở ranh giới giữa ngôn ngữ nghiệp vụ (mà sếp, khách hàng hiểu) và ngôn ngữ kỹ thuật (mà developer, tester cần). Một bản Use Case tốt giúp đội dev biết phải code cái gì, đội QA biết phải test kịch bản nào, và stakeholder biết hệ thống sẽ vận hành ra sao — tất cả từ một tài liệu duy nhất.
Trong bài này bạn sẽ học cách vẽ Use Case Diagram bằng UML và viết Use Case Specification chi tiết. Đây là kỹ năng được hỏi gần như chắc chắn trong phỏng vấn BA Junior tại Việt Nam, và là phần lõi mà nhiều marketer chuyển ngành hay làm hời hợt vì tưởng "vẽ vài hình oval là xong".
Khái niệm cốt lõi
Use Case là gì
Use Case là một mô tả về cách một người dùng (hoặc hệ thống khác) sử dụng hệ thống để đạt được một mục tiêu cụ thể, có giá trị. Điểm mấu chốt nằm ở chữ "mục tiêu có giá trị": "Đăng nhập" chưa phải là một use case tốt vì nó chỉ là bước phụ; "Đặt hàng và thanh toán" mới là use case vì nó hoàn tất một giá trị cho người dùng.
Use Case trả lời câu hỏi hệ thống làm gì, không phải hệ thống làm như thế nào về mặt kỹ thuật. Đó là lý do nó dễ đọc với cả người không biết code.
Use Case Diagram (UML)
Use Case Diagram là sơ đồ trực quan thể hiện bức tranh tổng thể các chức năng của hệ thống và ai dùng chúng. Bốn thành phần chính:
- Actor (tác nhân) — vẽ bằng hình người que. Là người hoặc hệ thống bên ngoài tương tác với hệ thống của bạn. Ví dụ: Khách hàng, Quản trị viên, Cổng thanh toán (Payment Gateway), Hệ thống giao hàng (GHN, GHTK). Lưu ý: actor không nằm trong hệ thống, mà đứng ngoài và "tác động vào".
- Use Case — vẽ bằng hình oval, đặt tên bằng động từ + danh từ: "Đặt hàng", "Tra cứu đơn", "Hoàn tiền".
- System Boundary (ranh giới hệ thống) — hình chữ nhật bao quanh các use case, ghi tên hệ thống. Nó tách rõ "cái gì trong tầm kiểm soát của hệ thống" với "actor bên ngoài".
- Relationships (quan hệ):
«include»): use case A luôn luôn dùng lại use case B. Ví dụ "Đặt hàng" include "Xác thực giỏ hàng".
- Extend (mũi tên nét đứt, «extend»): use case B có điều kiện mở rộng use case A. Ví dụ "Đặt hàng" được extend bởi "Áp mã giảm giá" — chỉ xảy ra khi khách có mã.
- Generalization: actor con kế thừa actor cha (ví dụ "Khách VIP" kế thừa "Khách hàng").Một mẹo phân biệt include và extend mà tôi luôn dạy học viên: include = bắt buộc, luôn chạy; extend = tùy chọn, có thể không chạy. Nếu bạn còn lăn tăn, hãy tự hỏi "use case này có luôn cần phần kia không?" — có thì dùng include, không thì dùng extend.
Use Case Specification
Diagram chỉ cho thấy bức tranh tổng thể. Phần "thịt" thực sự nằm ở Use Case Specification — bản đặc tả chi tiết từng use case. Một specification chuẩn gồm các trường:
- Use Case Name & ID: ví dụ UC-03 "Đặt hàng".
- Actor: ai liên quan.
- Brief Description: mô tả ngắn mục tiêu.
- Preconditions (điều kiện tiên quyết): điều kiện đúng trước khi chạy. Ví dụ "Khách đã đăng nhập và giỏ hàng có ít nhất 1 sản phẩm".
- Postconditions (điều kiện sau): trạng thái hệ thống sau khi hoàn tất. Ví dụ "Đơn hàng được tạo với trạng thái Chờ xử lý".
- Main Flow / Basic Flow (luồng chính): các bước khi mọi thứ suôn sẻ — gọi là happy path.
- Alternative Flows (luồng thay thế): nhánh rẽ vẫn đạt mục tiêu nhưng theo cách khác.
- Exception Flows (luồng ngoại lệ): khi có lỗi (mất kết nối, hết hàng, thanh toán thất bại).
- Business Rules: ràng buộc nghiệp vụ áp dụng (BR-12: đơn dưới 300k tính phí ship 30k).
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT nội địa: chức năng "Đặt hàng"
Giả sử bạn là BA tại một startup TMĐT ở TP.HCM tên ShopViet, đang xây tính năng checkout. Trên diagram, bạn vẽ:
- Actor: Khách hàng (primary), VNPay và GHTK (secondary).
- Use case chính: Đặt hàng, nằm trong system boundary "ShopViet Web".
- Quan hệ: "Đặt hàng"
«include»"Tính phí vận chuyển" (luôn chạy), và«extend»"Áp mã giảm giá" (chỉ khi khách nhập mã).
- Precondition: Khách đã đăng nhập, giỏ có ≥ 1 sản phẩm còn hàng.
- Main Flow: (1) Khách bấm "Thanh toán"; (2) Hệ thống hiển thị địa chỉ + sản phẩm; (3) Hệ thống gọi GHTK tính phí ship; (4) Khách chọn VNPay; (5) Hệ thống chuyển sang cổng VNPay; (6) VNPay trả kết quả thành công; (7) Hệ thống tạo đơn trạng thái "Chờ xử lý" và gửi email xác nhận.
- Alternative Flow A1 (áp mã): Tại bước 2, nếu khách nhập mã "SALE50", hệ thống kiểm tra mã hợp lệ và trừ 50.000đ vào tổng tiền.
- Exception Flow E1 (thanh toán thất bại): Tại bước 6, nếu VNPay trả "thất bại", hệ thống giữ giỏ hàng, hiển thị thông báo và cho phép thử lại.
- Exception Flow E2 (hết hàng): Tại bước 1, nếu sản phẩm đã hết khi khách bấm thanh toán, hệ thống báo "Sản phẩm vừa hết hàng" và xóa khỏi giỏ.
Ví dụ 2 — Ví điện tử kiểu MoMo: phân biệt include và extend
Tại một dự án fintech (lấy cảm hứng từ mô hình ví điện tử Việt Nam), bạn làm BA cho tính năng "Nạp tiền vào ví". Đây là tình huống kinh điển để hiểu include vs extend:
- "Nạp tiền"
«include»"Xác thực OTP" — luôn luôn phải xác thực OTP vì lý do bảo mật. Không có ngoại lệ, nên dùng include. - "Nạp tiền"
«extend»"Nhận voucher khuyến mãi" — chỉ khi đang có chương trình "nạp 100k tặng 10k". Có điều kiện, có thể không chạy, nên dùng extend.
Bài học rút ra: Dùng sai include/extend không chỉ là lỗi vẽ hình — nó truyền sai yêu cầu nghiệp vụ cho dev và có thể gây thiệt hại tiền thật (phát voucher tràn lan).
Ví dụ 3 — Hệ thống nội bộ: actor là hệ thống, không phải người
Tại một ngân hàng số ở Hà Nội, bạn làm BA cho module "Đối soát giao dịch cuối ngày". Use case "Đối soát giao dịch" được khởi tạo không phải bởi con người mà bởi một actor hệ thống: "Bộ lập lịch (Scheduler)" chạy lúc 23h mỗi ngày. Secondary actor là "Hệ thống Core Banking".
Nhiều người mới quên rằng actor có thể là một hệ thống tự động hoặc một cron job. Trên diagram, Scheduler vẫn vẽ bằng hình người que (hoặc ghi «system» để nhấn mạnh), nối tới use case "Đối soát giao dịch".
Bài học rút ra: Đừng mặc định actor luôn là người. Bất cứ thứ gì bên ngoài hệ thống và kích hoạt hoặc tham gia một chức năng đều là actor — kể cả lịch tự động, thiết bị IoT, hay API của đối tác.
Hướng dẫn từng bước
Đây là quy trình tôi khuyên bạn áp dụng mỗi khi cần dựng Use Case từ đầu:
- Xác định ranh giới hệ thống: Vẽ hình chữ nhật và đặt tên hệ thống. Tự hỏi: "Cái gì tôi đang xây? Cái gì nằm ngoài?". Điều này ngăn bạn lan man.
- Liệt kê actor: Hỏi "Ai dùng hệ thống này? Hệ thống nào kết nối vào?". Phân loại primary và secondary. Mẹo từ Marketing: danh sách persona/đối tượng bạn từng làm chính là nguồn actor tốt.
- Liệt kê use case theo mục tiêu actor: Với mỗi actor, hỏi "Họ muốn đạt được gì?". Đặt tên dạng động từ + danh từ. Tránh tách quá nhỏ (đừng tách "Nhập email", "Nhập mật khẩu" — gộp thành "Đăng nhập").
- Vẽ association nối actor với use case của họ.
- Thêm include/extend khi thấy use case dùng lại nhau hoặc có nhánh tùy chọn — nhưng đừng lạm dụng, diagram quá nhiều mũi tên sẽ rối.
- Chọn use case quan trọng để viết Specification chi tiết: thường là 20% use case lõi mang 80% giá trị. Không cần đặc tả mọi use case ngang nhau.
- Viết Main Flow trước, rồi Alternative, rồi Exception: Luôn theo thứ tự này. Viết happy path mạch lạc trước, sau đó hỏi "Còn cách nào khác đạt mục tiêu?" (alternative) và "Có thể sai ở đâu?" (exception).
- Gắn Business Rules và Precondition/Postcondition để khóa chặt nghiệp vụ.
- Review cùng stakeholder và dev: Đọc to luồng chính từng bước. Nếu một dev đọc xong biết phải code gì, bạn đã thành công.
Lỗi thường gặp & mẹo
- Đặt tên use case bằng danh từ hoặc quá kỹ thuật: "Giỏ hàng" hay "API thanh toán" không phải use case. Hãy dùng động từ chỉ mục tiêu: "Quản lý giỏ hàng", "Thanh toán đơn".
- Tách use case quá nhỏ (functional decomposition): Vẽ riêng "Click nút", "Mở form", "Validate"... khiến diagram thành sơ đồ thao tác chứ không phải mục tiêu. Use case phải là một mục tiêu trọn vẹn, có giá trị.
- Lạm dụng include/extend: Nhiều người mới thích vẽ thật nhiều mũi tên cho "ngầu". Nguyên tắc: chỉ dùng include khi thật sự tái sử dụng ở từ 2 use case trở lên, hoặc khi tách ra giúp rõ ràng hơn.
- Bỏ qua exception flow: Đây là lỗi chí mạng của marketer mới chuyển BA. Happy path ai cũng viết được; giá trị của BA nằm ở việc nghĩ ra "nếu thanh toán rớt giữa chừng thì sao?".
- Nhầm Use Case Diagram với flowchart: Use Case Diagram KHÔNG thể hiện trình tự thời gian hay điều kiện rẽ nhánh chi tiết. Đừng cố vẽ "nếu/thì" lên diagram — phần đó thuộc về specification hoặc activity diagram.
- Mẹo từ nền Marketing: Customer Journey Map bạn từng vẽ rất giống danh sách use case của primary actor. Mỗi "touchpoint khách chủ động làm" thường ánh xạ thành một use case. Hãy tận dụng tư duy hành trình khách hàng — đó là lợi thế của bạn.
- Mẹo viết flow: Mỗi bước trong Main Flow nên xen kẽ "actor làm X → hệ thống phản hồi Y". Tránh viết bước chung chung như "hệ thống xử lý" — quá mơ hồ để dev hiểu.
Bài tập thực hành
Hãy chọn một hệ thống bạn quen thuộc (gợi ý: app đặt đồ ăn như ShopeeFood, hoặc app đặt vé xem phim CGV) và làm các bước sau:
- Vẽ Use Case Diagram cho tính năng "Đặt món / Đặt vé":
- Viết Use Case Specification đầy đủ cho use case "Đặt món" / "Đặt vé", bao gồm: ID, Actor, Precondition, Postcondition, Main Flow (tối thiểu 6 bước), ít nhất 1 Alternative Flow, và ít nhất 2 Exception Flow.
- Tự kiểm tra: Đưa specification cho một người không rành kỹ thuật đọc. Họ có hiểu hệ thống làm gì không? Sau đó tưởng tượng mình là dev: bạn đã đủ thông tin để code chưa? Nếu còn câu hỏi "thế trường hợp này thì sao?", hãy bổ sung flow tương ứng.
Tóm tắt
Use Case Diagram cho bạn bức tranh tổng thể: ai (actor) dùng chức năng gì (use case) trong phạm vi nào (system boundary), với các quan hệ include (bắt buộc) và extend (tùy chọn). Use Case Specification mới là phần đặc tả chi tiết, nơi bạn viết Main Flow, Alternative Flow và đặc biệt là Exception Flow — chính những luồng ngoại lệ này phân biệt một BA chuyên nghiệp với người mới.
Là người đến từ Marketing, bạn có lợi thế tư duy hành trình khách hàng để liệt kê use case nhanh và sát thực tế. Hãy biến lợi thế đó thành đặc tả chặt chẽ: đặt tên use case bằng mục tiêu, không tách quá nhỏ, dùng đúng include/extend, và luôn nghĩ tới "cái gì có thể sai". Khi developer đọc specification của bạn mà code được ngay không cần hỏi lại, bạn đã thực sự làm chủ kỹ thuật Use Case Modeling.