Có phải Use Case chỉ là một hình vẽ?

Hồi mới học BA, mình từng nghĩ Use Case chỉ là vài cái hình vẽ actor và chức năng, kiểu như: “Người dùng đăng nhập”, “Quản trị viên cập nhật thông tin”. Vậy là đủ rồi.

Nhưng rồi, đến lúc đi làm, phải vẽ thật, viết tài liệu thật… mình bắt đầu loay hoay và vô cùng hoang mang, rối bời vì…không biết chỗ nào cần “Include”, chỗ nào nên “Extend”. Viết Use Case Specification thì lại không phân biệt nổi Trigger và Pre-condition. 

Vậy câu hỏi đặt ra rằng: Use Case thực chất là gì? Nó có đơn giản như ta nghĩ không? Và làm thế nào để hiểu nhanh, đúng và đủ?

Bài viết này sẽ giúp bạn dù là người mới tinh nắm được toàn bộ khái niệm cơ bản về Use Case chỉ trong 5 phút, bằng ngôn ngữ dễ hiểu và ví dụ gần gũi.

Use Case thật chất là gì?

Nhiều người mới học BA từng như mình, chỉ nghĩ rằng Use Case là một sơ đồ có mấy cái hình que nối với hình oval. Nhưng sự thật là: Use Case không chỉ là “vẽ”, mà là một cách tư duy. Đó là cách kể lại một kịch bản giữa người dùng và hệ thống, với một mục tiêu cụ thể.

Hãy tưởng tượng bạn đang dùng app ngân hàng để chuyển tiền. Các bước bạn cần làm là:

• Nhập số tài khoản
• Nhập số tiền
• Nhấn nút. 
• App phản hồi lại, chuyển thành công. 

Đó chính là một Use Case. Bạn là người dùng, là Actor. Hệ thống là app ngân hàng, là đối tượng tương tác.

Use Case giúp BA mô tả rõ ràng: Ai làm gì với hệ thống? Mục tiêu là gì? Hệ thống phản hồi ra sao?

Hai hình thức của Use Case: Diagram và Specification

Use Case Diagram: Cách nhìn nhanh toàn cảnh tương tác

Use Case Diagram là một thành phần trong UML (Unified Modeling Language), dùng để mô tả cách thức hệ thống hoặc phần mềm tương tác với các người dùng (actors) và các hệ thống khác. Có hai loại Use Case Diagram phổ biến:

• Business Use Case Diagram: Mô tả sự tương tác giữa người dùng (actor) và môi trường kinh doanh cụ thể.
• System Use Case Diagram: Mô tả sự tương tác giữa người dùng (actor) và hệ thống phần mềm cụ thể.

Actor có thể là người dùng hoặc hệ thống khác. 

Các chức năng nên được đặt tên theo định dạng “Động từ + Danh từ”. Các ví dụ đặt tên:

• Đăng ký tài khoản 
• Cập nhật thông tin
• Chỉnh sửa ảnh đại diện

Ngoài Actor và Use Case, Use Case Diagram còn thể hiện các mối quan hệ như: 

• Include: chức năng phụ bắt buộc, 
• Extend: chức năng mở rộng có điều kiện, 
• Generalization: Actor hoặc Use Case kế thừa từ một đối tượng khác.

Lưu ý khi vẽ:

• Không nên có quá 10 Use Case trong một diagram.
• Tránh đưa các chức năng CRUD đơn giản.
• Hạn chế đường nối chồng chéo.

Ví dụ minh họa: Trong một app gọi xe:

• Actor: Khách hàng và Tài xế.
• Use Case: Đặt xe, Hủy chuyến, Thanh toán.
• Include: Xác thực người dùng.
• Extend: Đánh giá sau chuyến đi.

Use Case Specification: Khi sơ đồ không đủ để hiểu sâu

Use Case Specification là tài liệu mô tả chi tiết các thông tin về một Use Case. Nó giúp giải thích một cách rõ ràng Use Case Diagram và cung cấp thông tin chi tiết để triển khai và kiểm thử hệ thống.

Phần Summary của Use Case Specification bao gồm: 

• Use Case Name: Tên của Use Case (ví dụ: Sign in, Register).
• User Case ID: Mã định danh của Use Case.
• Use Case Description: Mô tả ngắn gọn về sự tương tác trong Use Case.

Ví dụ: As an <Actor>, I want to <UC name>, so that <Reason>

• Actor: Các đối tượng thực hiện sự tương tác trong Use Case.
• Priority: Mức độ ưu tiên của Use Case trong dự án.
• Trigger: Điều kiện để kích hoạt Use Case.
• Pre-condition: Điều kiện cần có để Use Case thực hiện thành công.
• Post-condition: Những gì xảy ra sau khi Use Case thực hiện thành công.
  

Về phần Flow (Luồng): 

• Basic Flow: Luồng tương tác chính giữa các Actor và hệ thống để Use Case thực hiện thành công.
• Alternative Flow: Các luồng thay thế khi có điều kiện khác làm thay đổi luồng chính
• Exceptional Flow: Các luồng ngoại lệ, dùng để mô tả trường hợp thất bại hoặc lỗi trong quá trình thực hiện.

Cuối cùng, bạn có thể bổ sung thêm các Business Rules và Non-functional Requirements để hoàn chỉnh tài liệu.

Tổng kết rằng, công thức bạn cần nhớ như sau: 

Summary + Flow + Additional information (Business rule hoặc non-functional requirements)

Ví dụ cụ thể: Với Use Case “Đăng nhập hệ thống”:

• Trigger: Nhấn nút “Đăng nhập”
• Pre-condition: Tài khoản hợp lệ
• Basic Flow: Nhập tài khoản và mật khẩu → kiểm tra → thành công
• Exceptional Flow: Nhập sai quá 5 lần → khóa tài khoản

Hãy thực hiện vẽ Use case này và comment ngay bên dưới để nhận sự góp ý của team Sia nhee bạn ơi

Khi nào nên sử dụng Use Case? Có phải mọi dự án đều cần ?

Không phải mọi dự án đều cần Use Case. 

Tuy nhiên, khi bạn làm việc với những hệ thống có nhiều phân nhánh, điều kiện rẽ nhánh, hoặc luồng tương tác phức tạp giữa nhiều bên liên quan (business, người dùng, dev, tester), Use Case trở thành một công cụ cực kỳ mạnh mẽ.

Lợi ích rõ ràng nhất của Use Case là khả năng làm rõ yêu cầu thông qua kịch bản thực tế, giúp cả team hiểu đúng – đủ – rõ về điều người dùng thật sự cần làm và cách hệ thống cần phản hồi. Nhờ đó, Use Case giúp:

• Giao tiếp trơn tru giữa các bên mà không cần thuật ngữ kỹ thuật cao siêu.
• Kiểm soát phạm vi (scope): xác định rõ hành vi nào thuộc/không thuộc hệ thống.
• Giảm thiểu rủi ro sai sót trong phát triển nhờ có flow rõ ràng, đặc biệt là các flow ngoại lệ và điều kiện tiền đề.

Tuy nhiên, với những dự án đơn giản, làm prototype nhanh hoặc chỉ để test ý tưởng ban đầu, không bắt buộc phải dùng Use Case đầy đủ. Khi đó, các công cụ nhẹ hơn như user flow hoặc user story có thể phù hợp hơn. 

Điều quan trọng là: Chọn đúng công cụ cho đúng bối cảnh để tối ưu thời gian và hiệu quả làm việc.

Ngoài BA, trong dự án có những ai cần biết về Use Case?

Không chỉ riêng BA, mà tất cả các thành viên trong team dự án như Developer, Tester và Product Owner đều nên hiểu và sử dụng Use Case một cách hiệu quả.

• Dev: sử dụng Use Case để nắm rõ logic nghiệp vụ mà hệ thống cần đáp ứng. Khi hiểu rõ kịch bản tương tác giữa người dùng và hệ thống, họ sẽ xây dựng hệ thống đúng theo nhu cầu thực tế, tránh việc “build theo suy đoán”.
• Tester: dựa vào Use Case để viết các test case sát với thực tế sử dụng của người dùng. Các flow như Basic Flow hay Exceptional Flow giúp họ biết chính xác hệ thống phải phản hồi ra sao trong mỗi tình huống, từ đó tạo ra các kịch bản kiểm thử đầy đủ và chính xác.
• Product Owner (PO): nhìn vào Use Case để xác định tính đầy đủ và hợp lý của yêu cầu. PO cũng dùng Use Case để giải thích cho các bên liên quan về giá trị mà một tính năng mang lại theo đúng hành vi người dùng.

Use Case đóng vai trò như một ngôn ngữ trung gian chung cho cả team. Khi tất cả các vai trò cùng hiểu một Use Case theo cùng một cách, khả năng hiểu nhầm hoặc truyền đạt sai lệch sẽ được giảm thiểu đáng kể. Điều này không chỉ tiết kiệm thời gian sửa sai về sau mà còn nâng cao chất lượng sản phẩm ngay từ giai đoạn phân tích và thiết kế.

Lời kết

Học Use Case không cần bạn giỏi công nghệ, cũng chẳng đòi hỏi viết tài liệu dài dòng. Chỉ cần bạn biết quan sát một tình huống thường ngày, đặt mình vào vai người dùng và tưởng tượng xem hệ thống sẽ phản hồi ra sao. Đó đã là bước khởi đầu hoàn hảo.

Nếu bạn từng đặt lịch khám bệnh, gọi xe công nghệ, hay chỉ đơn giản là đặt món ăn qua app, bạn đã sống trong những Use Case mỗi ngày mà không nhận ra. Giờ là lúc lật lại những trải nghiệm đó dưới góc nhìn của một BA: Ai làm gì? Vì sao họ làm? Điều gì xảy ra tiếp theo? Và điều gì có thể xảy ra sai?

Use Case không phải là công cụ của người giỏi lý thuyết. Nó là công cụ của người biết lắng nghe, biết đặt câu hỏi và biết kết nối. Và nếu bạn đang bắt đầu hành trình trở thành BA, thì việc nắm được Use Case chính là một trong những nền móng vững chắc nhất.

Kể được câu chuyện đúng, bạn không chỉ hiểu Use Case. Bạn đang dần trở thành một BA thực thụ.

Nhận ngay ebook cho lộ trình học tập trở thành BA ngay bên dưới bạn nhe