Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn được giao mô tả yêu cầu cho một tính năng "đặt vé xem phim online" tại CGV. Bạn có thể viết 30 trang tài liệu đặc tả kỹ thuật, nhưng khi đưa cho khách hàng đọc, họ chỉ lắc đầu: "Tôi không hiểu cái này có giúp khách hàng đặt vé được không." Đây chính là vấn đề mà Use Case ra đời để giải quyết: nó kể một câu chuyện về việc ai dùng hệ thống để làm gì, theo ngôn ngữ mà cả người kinh doanh lẫn lập trình viên đều hiểu.
Với kỳ thi ECBA, Use Case xuất hiện trong nhóm kỹ thuật (techniques) của BABOK Guide v3 — cụ thể là kỹ thuật "Use Cases and Scenarios" — và nó gắn chặt với Knowledge Area "Requirements Analysis and Design Definition" (KA5). Đề thi thường kiểm tra xem bạn có phân biệt được Use Case với User Story hay không, có hiểu các thành phần (actor, flow, precondition) hay không, và biết khi nào nên dùng Use Case Diagram. Đây là một trong những kỹ thuật mô hình hóa "kinh điển" nhất, nên gần như chắc chắn bạn sẽ gặp câu hỏi liên quan.
Quan trọng hơn cả thi cử: Use Case là công cụ giao tiếp tuyệt vời. Trong thực tế nghề BA tại Việt Nam, khi làm việc với khách hàng không rành công nghệ — chủ một chuỗi spa, một công ty logistics, một ngân hàng — Use Case giúp bạn "nói chuyện" về hành vi hệ thống mà không sa đà vào kỹ thuật. Học tốt bài này, bạn vừa qua được câu hỏi thi, vừa có một vũ khí làm việc thực chiến.
Khái niệm cốt lõi
Use Case là gì?
Theo BABOK Guide, Use Case mô tả các tương tác giữa một actor (tác nhân) và một hệ thống (system) để hệ thống đó tạo ra giá trị cho actor — tức là giúp actor đạt được một mục tiêu (goal) cụ thể. Nói đơn giản: một Use Case là một câu chuyện về cách ai đó sử dụng hệ thống để hoàn thành một việc có ý nghĩa.
Ví dụ "Đặt vé xem phim", "Hủy đơn hàng", "Rút tiền tại ATM" đều là các Use Case. Điểm mấu chốt: mỗi Use Case phải mang lại giá trị quan sát được cho actor. "Đăng nhập" thực ra là một Use Case yếu, vì bản thân việc đăng nhập không tạo giá trị — người ta đăng nhập để làm gì đó. Đây là một bẫy hay gặp.
Use Case rất phổ biến trong các phương pháp luận như Waterfall và RUP (Rational Unified Process), và vẫn được dùng trong môi trường Agile (dù Agile thường ưu tiên User Story — chủ đề của một bài khác). Trong phạm vi bài này, ta tập trung vào bản chất, cấu trúc và cách vẽ Use Case.
Hai dạng thể hiện: Use Case (văn bản) và Use Case Diagram (sơ đồ)
Cần phân biệt rõ ngay từ đầu để tránh nhầm khi thi:
- Use Case Diagram (sơ đồ use case): là một hình vẽ tổng quan, dùng ký hiệu UML, cho thấy bức tranh lớn — có những actor nào, hệ thống cung cấp những use case (chức năng) nào, và mối quan hệ giữa chúng. Nó trả lời câu hỏi "hệ thống làm được những gì và cho ai".
- Use Case (mô tả văn bản / textual specification): là phần chi tiết bên trong mỗi use case — mô tả từng bước tương tác cụ thể (các flow). Nó trả lời câu hỏi "việc đó diễn ra như thế nào, từng bước một".
Các thành phần của một Use Case Diagram
Actor (tác nhân): là một vai trò (role) tương tác với hệ thống — có thể là người (khách hàng, nhân viên thu ngân), hệ thống bên ngoài (cổng thanh toán VNPAY), hoặc thiết bị/thời gian (đồng hồ kích hoạt một tác vụ định kỳ). Lưu ý: actor là vai trò, không phải con người cụ thể. Anh Tuấn có thể vừa là "Khách hàng" vừa là "Nhân viên" — đó là hai actor khác nhau. Ký hiệu là hình người que (stick figure), đặt ngoài ranh giới hệ thống.
- Primary actor (actor chính): người khởi xướng use case để đạt mục tiêu của mình (ví dụ Khách hàng khởi xướng "Đặt vé").
- Supporting/secondary actor (actor phụ): hệ thống/người tham gia hỗ trợ nhưng không khởi xướng (ví dụ Cổng thanh toán xử lý giao dịch).
Use Case: hình bầu dục (ellipse) bên trong ranh giới, đặt tên bằng động từ + danh từ ("Đặt vé", "Hoàn tiền").
Relationships (quan hệ):
- Association: đường thẳng nối actor với use case mà nó tham gia.
- Include (
<<include>>): use case A luôn luôn gọi use case B như một phần của mình. Ví dụ "Đặt vé" luôn include "Xử lý thanh toán". Mũi tên đứt nét trỏ tới use case được include. - Extend (
<<extend>>): use case B có thể mở rộng use case A trong một điều kiện nhất định (hành vi tùy chọn). Ví dụ "Đặt vé" có thể được extend bởi "Áp dụng mã giảm giá" — chỉ khi khách có mã. Mũi tên đứt nét trỏ tới use case cơ sở (base). - Generalization: quan hệ kế thừa giữa các actor hoặc use case (một actor "Khách VIP" là dạng đặc biệt của "Khách hàng").
Cấu trúc của một Use Case mô tả văn bản
Một Use Case viết đầy đủ thường gồm các phần sau:
- Tên (Name): động từ + tân ngữ, ví dụ "Hoàn tiền đơn hàng".
- Actor: ai khởi xướng và ai tham gia.
- Precondition (điều kiện tiên quyết): trạng thái phải đúng trước khi use case bắt đầu (ví dụ "Khách đã đăng nhập", "Đơn hàng đang ở trạng thái Chờ giao").
- Trigger (kích hoạt): sự kiện làm use case bắt đầu.
- Main flow / Basic flow (luồng chính): chuỗi các bước khi mọi thứ suôn sẻ — còn gọi là "happy path" (đường đi hạnh phúc).
- Alternative flows (luồng thay thế): các nhánh hợp lệ khác (ví dụ khách chọn trả bằng ví Momo thay vì thẻ).
- Exception flows (luồng ngoại lệ): xử lý lỗi (thẻ bị từ chối, mất kết nối).
- Postcondition (điều kiện sau): trạng thái hệ thống sau khi use case hoàn tất thành công (ví dụ "Tiền đã được hoàn về tài khoản khách, đơn ở trạng thái Đã hủy").
Tình huống thực tế
Tình huống 1: Hệ thống đặt vé của CGV Việt Nam
Một nhóm BA được thuê để phân tích tính năng đặt vé online cho rạp phim. Họ bắt đầu bằng Use Case Diagram với ranh giới hệ thống là "Hệ thống đặt vé CGV". Các actor: Khách hàng (primary), Cổng thanh toán VNPAY (supporting), Nhân viên rạp (kiểm tra vé khi khách đến).
Use case "Đặt vé" được vẽ ở trung tâm. Nhóm dùng <<include>> để nối "Đặt vé" với "Xử lý thanh toán" — vì mọi lần đặt vé đều phải thanh toán. Họ dùng <<extend>> để nối "Áp dụng mã giảm giá" vào "Đặt vé" — vì chỉ một số khách có mã.
Khi viết mô tả văn bản, luồng chính là: chọn phim → chọn suất → chọn ghế → nhập thông tin → thanh toán → nhận vé điện tử. Luồng ngoại lệ quan trọng: "Ghế vừa được người khác đặt trong lúc khách đang thanh toán". Chính nhờ liệt kê exception flow này mà đội phát triển nhận ra cần một cơ chế giữ ghế tạm 5 phút. Bài học: giá trị lớn nhất của Use Case không nằm ở happy path — nó nằm ở việc bắt buộc bạn phải nghĩ tới các luồng thay thế và ngoại lệ mà nếu chỉ liệt kê "yêu cầu" thì rất dễ bỏ sót.
Tình huống 2: Sàn TMĐT giả định "ChợViệt" và bẫy actor
Đội BA của một startup TMĐT tên ChợViệt vẽ Use Case Diagram cho module quản lý đơn. Ban đầu họ vẽ một actor duy nhất tên "Anh Hùng" — người vừa bán hàng vừa quản lý kho. Khi review, BA lead chỉ ra lỗi: actor phải là vai trò, không phải con người. Họ tách thành hai actor "Người bán" và "Thủ kho", dù trên thực tế cùng một người đảm nhiệm.
Việc tách này giúp họ phát hiện một use case bị bỏ quên: "Thủ kho" cần "Cập nhật tồn kho" — một chức năng mà khi nghĩ theo góc nhìn "Anh Hùng" họ đã gộp lẫn vào việc bán hàng và bỏ sót. Bài học: mô hình hóa actor theo vai trò giúp lộ ra các chức năng ẩn. Đây cũng là điểm ECBA hay hỏi: "Actor đại diện cho điều gì?" — đáp án là vai trò (role), không phải cá nhân.
Tình huống 3: Ngân hàng số và sự khác biệt include vs extend
Một ngân hàng số tại Đông Nam Á phân tích tính năng "Chuyển khoản". Đội tranh luận: "Xác thực OTP" nên là include hay extend? Lúc đầu họ để extend. Nhưng theo chính sách bảo mật, mọi giao dịch chuyển khoản trên 5 triệu đồng đều bắt buộc OTP, và thực tế hệ thống yêu cầu OTP cho hầu hết giao dịch. Họ sửa thành <<include>> "Xác thực OTP", còn <<extend>> để dành cho "Lưu người thụ hưởng vào danh bạ" — một hành động tùy chọn sau khi chuyển thành công.
Bài học: quyết định include hay extend không phải chuyện thẩm mỹ, nó phản ánh đúng nghiệp vụ. Include = luôn xảy ra, là phần không thể thiếu. Extend = tùy chọn, có điều kiện. Hiểu sai sẽ dẫn tới đặc tả sai và lập trình viên hiểu nhầm phạm vi.
Hướng dẫn từng bước
Đây là quy trình xây dựng Use Case mà bạn có thể áp dụng ngay:
- Xác định phạm vi và ranh giới hệ thống. Vẽ hộp chữ nhật: cái gì nằm trong tầm kiểm soát của hệ thống, cái gì là bên ngoài. Đặt tên hệ thống rõ ràng.
- Liệt kê actor. Hỏi: "Ai dùng hệ thống này? Hệ thống nào nói chuyện với nó?". Nhớ tư duy theo vai trò. Phân biệt primary và supporting actor.
- Xác định các use case (mục tiêu của actor). Với mỗi actor, hỏi "Họ muốn đạt được điều gì?". Mỗi câu trả lời mang lại giá trị quan sát được là một use case. Đặt tên bằng động từ + danh từ.
- Vẽ quan hệ. Nối actor với use case (association). Thêm
<<include>>cho phần bắt buộc dùng chung,<<extend>>cho phần tùy chọn có điều kiện. Đừng lạm dụng — nếu thấy mình vẽ quá nhiều include/extend, có thể bạn đang phân rã quá mức.
- Viết mô tả văn bản cho các use case quan trọng. Bắt đầu với precondition và trigger. Viết luồng chính (happy path) theo từng bước đánh số, xen kẽ "actor làm gì → hệ thống phản hồi gì".
- Bổ sung luồng thay thế và ngoại lệ. Tại mỗi bước của luồng chính, hỏi "Còn cách nào khác?" (alternative) và "Có thể sai ở đâu?" (exception). Đây là bước tạo ra giá trị thật.
- Khai báo postcondition. Mô tả trạng thái hệ thống sau khi hoàn tất. Điều này giúp tester biết phải kiểm tra gì.
- Rà soát với stakeholder. Đọc luồng cho khách hàng nghe — nếu họ gật đầu "đúng rồi, sẽ diễn ra như vậy", 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. "Bảng đơn hàng" không phải use case; "Tạo đơn hàng" mới đúng. Luôn dùng động từ thể hiện hành động.
- Nhầm "Đăng nhập" là use case giá trị. Đăng nhập, đăng xuất, xác thực thường là use case phụ trợ (qua include), không phải mục tiêu chính. ECBA thích bẫy này.
- Vẽ luồng (sequence chi tiết) lên Use Case Diagram. Sơ đồ use case không thể hiện thứ tự các bước hay điều kiện rẽ nhánh. Đó là việc của mô tả văn bản hoặc activity diagram. Sơ đồ chỉ cho thấy cái gì và cho ai.
- Lẫn lộn include và extend. Nhớ câu thần chú: include = bắt buộc luôn chạy; extend = tùy chọn có điều kiện. Và để ý hướng mũi tên: include trỏ tới use case con được gộp; extend trỏ tới use case base.
- Actor là con người cụ thể. Sai. Actor là vai trò. Một người có thể đóng nhiều vai; một vai có thể do nhiều người đảm nhiệm.
- Bỏ qua exception flow. Đây là lỗi đắt giá nhất trong thực tế. Happy path thì ai cũng viết được; giá trị của BA nằm ở việc lường trước những gì có thể sai.
- Mẹo phân biệt với User Story (sẽ học ở Bài 23): Use Case nặng về luồng tương tác chi tiết, nhiều bước, có flow; User Story ngắn gọn theo mẫu "Là... tôi muốn... để...". Use Case hợp với hệ thống phức tạp, nhiều nhánh; User Story hợp với Agile lặp nhanh. Đề ECBA có thể hỏi khi nào dùng cái nào.
Bài tập thực hành
- Phân tích nhanh: Chọn một ứng dụng bạn dùng hàng ngày (Grab, Shopee, MoMo, hoặc app ngân hàng). Liệt kê ít nhất 3 actor và 5 use case. Đánh dấu đâu là primary, đâu là supporting actor.
- Vẽ sơ đồ: Vẽ tay một Use Case Diagram cho tính năng "Đặt món" của một app giao đồ ăn. Phải có ít nhất một quan hệ
<<include>>(gợi ý: thanh toán) và một quan hệ<<extend>>(gợi ý: thêm ghi chú cho quán).
- Viết mô tả văn bản: Chọn use case "Hủy đơn hàng" và viết đầy đủ: precondition, trigger, luồng chính (đánh số bước), ít nhất 1 luồng thay thế, 1 luồng ngoại lệ, và postcondition.
- Tự kiểm tra ECBA: Tự trả lời ba câu — (a) Actor đại diện cho điều gì? (b) Sự khác biệt cốt lõi giữa include và extend? (c) Vì sao "Đăng nhập" thường không được coi là use case mang giá trị độc lập? So sánh đáp án của bạn với phần Khái niệm cốt lõi.
Tóm tắt
Use Case là kỹ thuật mô tả tương tác giữa actor và hệ thống nhằm đạt một mục tiêu mang lại giá trị quan sát được. Nó tồn tại ở hai dạng: Use Case Diagram (bức tranh tổng quan — actor, use case, ranh giới, quan hệ include/extend/generalization) và mô tả văn bản (chi tiết các flow: precondition, trigger, luồng chính, luồng thay thế, ngoại lệ, postcondition).
Những điểm cốt yếu cho ECBA và thực chiến: actor là vai trò chứ không phải cá nhân; use case đặt tên bằng động từ và phải mang giá trị; include = bắt buộc luôn chạy, extend = tùy chọn có điều kiện; và giá trị thật của BA nằm ở việc lường trước các luồng thay thế và ngoại lệ. Sơ đồ chỉ là mục lục — phần thịt nằm ở mô tả chi tiết. Nắm vững những điều này, bạn vừa tự tin trước câu hỏi thi, vừa có công cụ giao tiếp mạnh mẽ với mọi stakeholder trong dự án thực tế.