TÓM TẮT
- 1 1. Giới thiệu tổng quan về Use Case
- 2 2. Chuẩn bị trước khi vẽ use case
- 3 3. Các bước vẽ use case chi tiết
- 3.1 Bước 1: Vẽ System Boundary
- 3.2 Bước 2: Đặt các actor
- 3.3 Bước 3: Xác định và vẽ các use case
- 3.4 Bước 4: Thiết lập mối quan hệ bao gồm (Include)
- 3.5 Bước 5: Thiết lập mối quan hệ mở rộng (Extend)
- 3.6 Bước 6: Thiết lập mối quan hệ kế thừa (Generalization)
- 3.7 Bước 7: Thêm mô tả chi tiết (Use case description)
- 3.8 Bước 8: Kiểm tra và tối ưu hóa sơ đồ
- 4 4. Các công cụ hỗ trợ vẽ use case
- 5 5. Thực hành: Ví dụ vẽ use case cho hệ thống đặt vé máy bay
- 6 6. Các lỗi thường gặp khi vẽ use case và cách khắc phục
- 7 7. Kỹ thuật nâng cao trong mô hình use case
- 8 8. Quy trình kiểm tra và xác nhận use case
- 9 9. Lưu trữ và quản lý tài liệu use case
- 10 10. Kết luận
1. Giới thiệu tổng quan về Use Case
Use case (trường hợp sử dụng) là một trong những công cụ quan trọng nhất trong phân tích và thiết kế hệ thống phần mềm, đặc biệt trong phương pháp luận UML (Unified Modeling Language). Nó giúp mô tả cách mà người dùng (actor) tương tác với hệ thống để đạt được một mục tiêu cụ thể. Khi được vẽ đúng cách, use case không chỉ giúp các nhà phân tích, kiến trúc sư phần mềm nắm bắt yêu cầu nghiệp vụ một cách rõ ràng mà còn hỗ trợ lập trình viên, tester và các bên liên quan hiểu đúng chức năng cần phát triển.
1.1. Lợi ích của việc vẽ use case
- Giao tiếp hiệu quả: Use case là ngôn ngữ chung giữa khách hàng, nhà quản lý dự án và đội phát triển.
- Xác định phạm vi: Giúp xác định rõ ràng những gì sẽ được phát triển và những gì không nằm trong phạm vi dự án.
- Phát hiện yêu cầu: Khi mô tả các kịch bản, chúng ta thường phát hiện ra các yêu cầu tiềm ẩn hoặc các ngoại lệ chưa được xem xét.
- Hỗ trợ kiểm thử: Mỗi use case có thể trở thành một test case, giúp xây dựng kế hoạch kiểm thử có hệ thống.
- Quản lý thay đổi: Khi yêu cầu thay đổi, ta chỉ cần cập nhật các use case liên quan mà không ảnh hưởng tới toàn bộ mô hình.
1.2. Các thành phần cơ bản của một use case
| Thành phần | Mô tả |
|---|---|
| Actor (Diễn viên) | Đối tượng (người, hệ thống, thiết bị) tương tác với hệ thống. |
| Use case (Trường hợp sử dụng) | Mô tả một hành vi chức năng mà hệ thống thực hiện để đáp ứng nhu cầu của actor. |
| System boundary (Ranh giới hệ thống) | Đường viền xác định phạm vi hệ thống, thường được biểu diễn bằng một hình chữ nhật. |
| Relationship (Mối quan hệ) | Bao gồm Association, Include, Extend, Generalization giữa các actor và use case. |
| Precondition (Điều kiện tiền đề) | Điều kiện phải đúng trước khi use case có thể bắt đầu. |
| Postcondition (Điều kiện hậu đề) | Trạng thái của hệ thống sau khi use case hoàn thành. |
| Basic Flow (Luồng cơ bản) | Kịch bản thành công nhất, mô tả các bước thực hiện chính. |
| Alternative Flow (Luồng thay thế) | Các kịch bản phụ, ngoại lệ hoặc các bước thay thế. |
2. Chuẩn bị trước khi vẽ use case
2.1. Thu thập yêu cầu
- Phỏng vấn stakeholder: Gặp gỡ người dùng cuối, quản lý, chuyên gia nghiệp vụ để nắm bắt nhu cầu.
- Phân tích tài liệu: Đọc các tài liệu yêu cầu, quy trình kinh doanh hiện có.
- Workshop và brainstorming: Tổ chức buổi họp nhóm để khai thác ý tưởng và xác định các actor, chức năng.
2.2. Xác định actor

Có thể bạn quan tâm: Cách Vẽ Tổ Ong Đơn Giản Và Đầy Sáng Tạo: Hướng Dẫn Từng Bước Cho Người Mới Bắt Đầu
- Actor chính: Người sử dụng trực tiếp hệ thống (ví dụ: Khách hàng, Nhân viên bán hàng).
- Actor phụ: Các hệ thống hoặc thiết bị hỗ trợ (ví dụ: Hệ thống thanh toán, Máy in).
- Actor ngoại vi: Các thực thể không tương tác trực tiếp nhưng ảnh hưởng đến luồng (ví dụ: Cơ quan quản lý).
2.3. Xác định phạm vi (Scope)
- Mức độ chi tiết: Đối với dự án lớn, có thể chia thành các sub‑system, mỗi sub‑system có một sơ đồ use case riêng.
- Giới hạn thời gian: Đặt ra các mốc thời gian để hoàn thành các use case quan trọng trước.
- Định nghĩa boundary: Vẽ một hình chữ nhật lớn biểu thị hệ thống, các actor được đặt bên ngoài.
3. Các bước vẽ use case chi tiết
Bước 1: Vẽ System Boundary
- Tạo hình chữ nhật: Đặt tên hệ thống ở phía trên (ví dụ: “Hệ thống Quản lý Đặt vé Máy bay”).
- Đánh dấu ranh giới: Đảm bảo mọi use case nằm bên trong, các actor nằm bên ngoài.
Bước 2: Đặt các actor
- Vẽ stick‑figure (hoặc biểu tượng) cho mỗi actor.
- Ghi tên actor ngay dưới biểu tượng.
- Sắp xếp: Đặt các actor theo nhóm chức năng (ví dụ: “Khách hàng” và “Nhân viên” ở phía trái, “Hệ thống thanh toán” ở phía phải).
Bước 3: Xác định và vẽ các use case
- Liệt kê các chức năng chính: Dựa trên yêu cầu, viết tên use case ngắn gọn, động từ + danh từ (VD: “Đặt vé”, “Thanh toán”, “Xem lịch sử đặt vé”).
- Vẽ hình ellipse cho mỗi use case, đặt bên trong boundary.
- Kết nối: Dùng đường thẳng (Association) nối actor với các use case mà họ thực hiện.
Bước 4: Thiết lập mối quan hệ bao gồm (Include)

Có thể bạn quan tâm: Cách Vẽ Tế Bào: Hướng Dẫn Chi Tiết Từ Cơ Bản Đến Nâng Cao
- Khi nào dùng? Khi một hành vi là bắt buộc và được tái sử dụng trong nhiều use case.
- Cách biểu diễn: Đánh dấu mũi tên có nhãn «include» từ use case phụ (được bao gồm) tới use case chính.
- Ví dụ: “Xác thực người dùng” có thể là một use case được include trong “Đăng nhập”, “Đặt vé”, “Hủy vé”.
Bước 5: Thiết lập mối quan hệ mở rộng (Extend)
- Khi nào dùng? Khi một hành vi chỉ xảy ra trong một số điều kiện hoặc ngoại lệ.
- Cách biểu diễn: Đánh dấu mũi tên có nhãn «extend» từ use case mở rộng tới use case gốc.
- Ví dụ: “Thanh toán thất bại” là một extend của “Thanh toán” khi có lỗi giao dịch.
Bước 6: Thiết lập mối quan hệ kế thừa (Generalization)
- Actor kế thừa: Nếu một actor con chia sẻ hành vi của actor cha (VD: “Khách hàng VIP” kế thừa “Khách hàng”).
- Use case kế thừa: Khi một use case con mở rộng hoặc chi tiết hơn use case cha.
- Biểu diễn: Dùng đường thẳng có mũi tên tam giác hướng tới lớp cha.
Bước 7: Thêm mô tả chi tiết (Use case description)
Mỗi use case cần một tài liệu mô tả chi tiết, bao gồm:
- Tên: Ngắn gọn, mô tả hành động.
- Mã số: Ví dụ UC‑01.
- Actor chính: Ai là người thực hiện.
- Mô tả tổng quan: Một đoạn văn ngắn.
- Precondition: Điều kiện phải thỏa mãn.
- Postcondition: Kết quả sau khi thực hiện.
- Basic Flow: Các bước chính, thường từ 1 đến n.
- Alternative Flow: Các kịch bản phụ, ngoại lệ.
- Exceptions: Những lỗi có thể xảy ra và cách xử lý.
Bước 8: Kiểm tra và tối ưu hóa sơ đồ
- Độ rõ ràng: Các đường nối không nên chồng chéo quá nhiều.
- Số lượng use case: Tránh quá tải; nếu một sơ đồ có hơn 15‑20 use case, cân nhắc chia thành các sơ đồ con.
- Consistency: Kiểm tra tính nhất quán giữa tên actor, tên use case và mô tả chi tiết.
4. Các công cụ hỗ trợ vẽ use case
| Công cụ | Ưu điểm | Nhược điểm | Giá |
|---|---|---|---|
| Microsoft Visio | Giao diện quen thuộc, tích hợp Office | Chi phí cao, không miễn phí | Thuê/ mua |
| Lucidchart | Web‑based, cộng tác real‑time | Giới hạn tính năng ở gói miễn phí | Freemium |
| draw.io (diagrams.net) | Miễn phí, tích hợp Google Drive | Giao diện hơi cồng kềnh | Miễn phí |
| StarUML | Hỗ trợ đầy đủ UML, export PDF/PNG | Cần cài đặt, không web | $79/năm |
| Enterprise Architect | Chuyên nghiệp, quản lý dự án lớn | Phức tạp, chi phí cao | $229 (cá nhân) |
| PlantUML | Tạo sơ đồ từ text, tích hợp CI/CD | Cần học syntax | Miễn phí |
4.1. Hướng dẫn nhanh vẽ use case bằng draw.io

Có thể bạn quan tâm: Cách Vẽ Tĩnh Vật – Hướng Dẫn Chi Tiết Từ Cơ Bản Đến Nâng Cao
- Mở draw.io, chọn “Create New Diagram”, đặt tên và chọn “Blank Diagram”.
- Kéo shape “Ellipse” cho use case, “Stick Figure” cho actor từ thanh công cụ “UML”.
- Đặt tên cho mỗi shape bằng cách double‑click.
- Kết nối bằng công cụ “Connector”, chọn “Straight Line” và kéo từ actor tới use case.
- Thêm mũi tên và nhãn: Click vào connector → “Style” → “Arrow” → “Start/End”, nhập nhãn “<
>” hoặc “< >”. - Export: File → Export As → PNG/PDF.
5. Thực hành: Ví dụ vẽ use case cho hệ thống đặt vé máy bay
5.1. Xác định actor
| Actor | Mô tả |
|---|---|
| Khách hàng | Người dùng cuối, mua vé qua website hoặc app. |
| Nhân viên hỗ trợ | Quản lý đặt vé, xử lý hủy/đổi vé. |
| Hệ thống thanh toán | Cổng thanh toán của ngân hàng. |
| Hệ thống email | Gửi thông báo xác nhận, vé điện tử. |
| Quản trị hệ thống | Quản lý dữ liệu, báo cáo. |
5.2. Liệt kê use case chính
- Đăng ký tài khoản
- Đăng nhập
- Tìm chuyến bay
- Đặt vé
- Thanh toán
- Xác nhận đặt vé
- Hủy vé
- Đổi vé
- Xem lịch sử đặt vé
- Gửi email xác nhận
5.3. Mối quan hệ include / extend
- Include: “Xác thực người dùng” được include trong “Đăng nhập”, “Đặt vé”, “Hủy vé”.
- Extend: “Thanh toán thất bại” extend “Thanh toán” khi giao dịch bị từ chối.
- Extend: “Gửi email xác nhận” extend “Xác nhận đặt vé”.
5.4. Sơ đồ use case (miêu tả bằng text)
+---------------------------------------------------+
| Hệ thống Đặt vé Máy bay |
| |
| (Khách hàng) ------------------- (Đăng ký tài khoản) |
| (Khách hàng) ------------------- (Đăng nhập) |
| (Khách hàng) ------------------- (Tìm chuyến bay) |
| (Khách hàng) ------------------- (Đặt vé) |
| (Khách hàng) ------------------- (Thanh toán) |
| (Khách hàng) ------------------- (Xác nhận đặt vé) |
| (Khách hàng) ------------------- (Hủy vé) |
| (Khách hàng) ------------------- (Đổi vé) |
| (Khách hàng) ------------------- (Xem lịch sử) |
| (Hệ thống thanh toán) ------<<include>> (Xác thực người dùng) |
| (Thanh toán) --<<extend>> (Thanh toán thất bại) |
| (Xác nhận đặt vé) --<<extend>> (Gửi email xác nhận) |
+---------------------------------------------------+
5.5. Mô tả chi tiết một use case: “Đặt vé”

Có thể bạn quan tâm: Cách Vẽ Tóc Xoăn Chuẩn Đẹp Từng Đường Nét: Hướng Dẫn Chi Tiết Từ Cơ Bản Đến Nâng Cao
- Mã: UC‑04
- Tên: Đặt vé
- Actor chính: Khách hàng
- Precondition: Khách hàng đã đăng nhập, đã tìm và chọn chuyến bay.
- Postcondition: Đặt vé được tạo, trạng thái “Chờ thanh toán”.
- Basic Flow:
- Khách hàng chọn chuyến bay và nhấn “Đặt vé”.
- Hệ thống hiển thị form nhập thông tin hành khách.
- Khách hàng nhập thông tin cá nhân, lựa chọn chỗ ngồi.
- Hệ thống tính tổng tiền, hiển thị chi phí.
- Khách hàng nhấn “Tiếp tục” → chuyển tới use case “Thanh toán”.
- Alternative Flow:
- A1: Nếu khách hàng chưa đăng nhập, hệ thống redirect tới “Đăng nhập” (include “Xác thực người dùng”).
- A2: Nếu không còn chỗ trống, hiển thị thông báo “Chuyến bay đã đầy” và kết thúc.
- Exceptions:
- E1: Lỗi kết nối cơ sở dữ liệu → hiển thị lỗi “Hệ thống đang bảo trì”.
6. Các lỗi thường gặp khi vẽ use case và cách khắc phục
| Lỗi | Nguyên nhân | Cách khắc phục |
|---|---|---|
| Quá nhiều actor | Không phân loại rõ ràng, mỗi vai trò được tạo thành actor riêng. | Gom các vai trò tương đồng, dùng Generalization để thể hiện quan hệ cha‑con. |
| Use case lặp lại | Thiếu phân tích include/extend. | Xác định các hành vi chung, tách ra thành use case riêng và dùng include. |
| Mối quan hệ không hợp lý | Nhầm lẫn giữa extend và include. | Remember: Include = bắt buộc, Extend = tùy chọn/ngoại lệ. |
| Sơ đồ quá rối | Nhiều đường nối chồng chéo. | Sắp xếp lại vị trí actor và use case, dùng layout “horizontal” cho các nhóm. |
| Thiếu mô tả chi tiết | Tập trung quá vào hình ảnh, bỏ qua tài liệu. | Đảm bảo mỗi use case có mô tả đầy đủ (pre/post, flow). |
| Không cập nhật khi yêu cầu thay đổi | Quản lý phiên bản kém. | Sử dụng công cụ hỗ trợ version control (Git + PlantUML). |
7. Kỹ thuật nâng cao trong mô hình use case
7.1. Use case diagram kết hợp với activity diagram
- Mục đích: Khi một use case có luồng phức tạp, ta tạo activity diagram để chi tiết hoá bước thực hiện.
- Cách thực hiện: Liên kết use case trong sơ đồ use case với activity diagram bằng nhãn “detailed in”.
7.2. Use case và hệ thống con (sub‑system)
- Kỹ thuật: Đối với dự án lớn, chia hệ thống thành các module (ví dụ: “Quản lý Đặt vé”, “Quản lý Thanh toán”). Mỗi module có sơ đồ use case riêng, sau đó dùng “Package Diagram” để mô tả mối quan hệ giữa các module.
7.3. Use case và yêu cầu phi chức năng
- Cách tích hợp: Đánh dấu các yêu cầu phi chức năng (performance, security) bằng các ghi chú (note) gắn vào use case. Ví dụ: “Thanh toán” có note “Response time < 2s, Must comply with PCI‑DSS”.
7.4. Use case và story mapping

- Áp dụng: Khi làm Agile, chuyển các use case thành user story, sắp xếp trên story map để xác định MVP (Minimum Viable Product) và các release tiếp theo.
8. Quy trình kiểm tra và xác nhận use case
- Review nội bộ: Đội phân tích, kiến trúc, tester cùng đọc và thảo luận.
- Walk‑through với stakeholder: Trình bày sơ đồ, nhận phản hồi.
- Kiểm tra tính toàn vẹn: Đảm bảo mọi yêu cầu nghiệp vụ đều có ít nhất một use case liên quan.
- Kiểm tra tính nhất quán: Các tên, mô tả, mã số phải thống nhất trên toàn bộ tài liệu.
- Phê duyệt: Lấy chữ ký/điểm phê duyệt từ người quản lý dự án và chủ sở hữu yêu cầu.
9. Lưu trữ và quản lý tài liệu use case
- Version control: Sử dụng Git để lưu trữ file .uml (PlantUML) hoặc .xml (StarUML). Đặt tag cho mỗi phiên bản phát hành.
- Repository: Tạo thư mục
docs/use_cases/với cấu trúc:
use_cases/ ├─ UC01_DangKyTaiKhoan.uml ├─ UC02_DangNhap.uml ├─ UC03_TimChuyenBay.uml └─ README.md (mô tả tổng quan) - Traceability matrix: Tạo bảng mapping giữa yêu cầu (Requirement ID) và use case (UC ID) để theo dõi.
10. Kết luận
Việc vẽ use case không chỉ là một bước hình ảnh hoá đơn thuần mà còn là một quá trình tư duy, phân tích và giao tiếp sâu sắc giữa các bên liên quan trong dự án phần mềm. Khi thực hiện đúng các nguyên tắc, chuẩn bị kỹ lưỡng và áp dụng các kỹ thuật nâng cao, bạn sẽ nhận được:
- Sơ đồ rõ ràng, dễ hiểu giúp mọi người nhanh chóng nắm bắt chức năng hệ thống.
- Tài liệu chi tiết hỗ trợ phát triển, kiểm thử và bảo trì lâu dài.
- Công cụ và quy trình tiêu chuẩn hoá, giảm thiểu rủi ro sai sót và tăng tốc độ phát triển.
Hy vọng bài viết này đã cung cấp cho bạn một hướng dẫn toàn diện, từ những bước cơ bản đến các kỹ thuật nâng cao, giúp bạn tự tin tạo ra các sơ đồ use case chuyên nghiệp cho bất kỳ dự án phần mềm nào. Chúc bạn thành công!
