Use case là gì? Thành phần và cách xây dựng use case website

Trong quá trình phát triển một website, hiểu rõ người dùng cần gì và hệ thống cần hoạt động như thế nào là yếu tố then chốt quyết định sự thành công của sản phẩm. Nếu không xác định rõ các nhóm người dùng, nhu cầu thực tế và cách họ tương tác với hệ thống, sản phẩm rất dễ đi sai hướng, dẫn đến trải nghiệm kém và không đáp ứng được mục tiêu kinh doanh. Đây cũng là lý do use case trở thành một trong những công cụ quan trọng trong phân tích và thiết kế hệ thống. Tuy nhiên use cases là gì? Gồm những thành phần nào và làm thế nào để xây dựng use case hiệu quả cho một website?

 

 

Use cases là gì?

Use case (trường hợp sử dụng) là một mô tả chi tiết về cách một người dùng (hoặc hệ thống khác) tương tác với website để đạt được một mục tiêu cụ thể. Ví dụ, một số use case phổ biến trên website thương mại điện tử có thể kể đến như: 

- Người dùng đăng ký tài khoản.

- Người dùng tìm kiếm sản phẩm.

- Người dùng đặt hàng và thanh toán.

Mỗi hành động này đều có thể được mô tả thành một use case riêng, giúp đội phát triển hiểu rõ luồng hoạt động của hệ thống. Use case không chỉ đơn thuần là danh sách tính năng mà còn mô tả ngữ cảnh, người tham gia, điều kiện và từng bước xử lý trong một kịch bản cụ thể. Nhờ đó, cả đội kỹ thuật lẫn đội kinh doanh đều có thể dùng các use cases như một ngôn ngữ chung để thống nhất yêu cầu trước khi phát triển.

 

 

Các thành phần chính của một use case website

Một use case hoàn chỉnh thường bao gồm nhiều thành phần khác nhau. Những thành phần này giúp mô tả đầy đủ bối cảnh, người tham gia và luồng xử lý của hệ thống.

1. Actor (Tác nhân)

Actor là bất kỳ đối tượng nào tương tác với hệ thống từ bên ngoài để kích hoạt một use case. Actor không nhất thiết phải là con người mà có thể là một hệ thống khác, một dịch vụ bên thứ ba hoặc thậm chí một tác vụ tự động theo lịch.

Có 2 loại actor chính cần phân biệt:

- Primary actor (Tác nhân chính): Người hoặc hệ thống trực tiếp khởi tạo use case và hưởng lợi từ kết quả. Ví dụ: khách hàng đặt hàng, quản trị viên duyệt bài đăng.

- Secondary actor (Tác nhân phụ): Người hoặc hệ thống hỗ trợ thực hiện use case nhưng không phải người khởi tạo. Ví dụ: cổng thanh toán xử lý giao dịch, hệ thống gửi email xác nhận.

2. System (Hệ thống)

System là phạm vi của use case, tức là toàn bộ website hoặc một module cụ thể đang được mô tả. Thành phần này xác định rõ ranh giới xử lý giữa hệ thống nội bộ và các thành phần bên ngoài.

Ví dụ, trong use case “Đặt hàng”, hệ thống có thể bao gồm các module như:

- Giỏ hàng.

- Thanh toán.

- Quản lý đơn hàng.

Ranh giới hệ thống cần được định nghĩa rõ ràng để tránh nhầm lẫn giữa những gì website xử lý và những gì do bên thứ ba đảm nhận.

3. Goal (Mục tiêu)

Goal là kết quả mà actor muốn đạt được sau khi hoàn thành use case. Đây là thành phần quan trọng nhất, vì toàn bộ luồng xử lý của use case đều phục vụ cho mục tiêu này.

Một goal được xây dựng tốt cần đảm bảo các tiêu chí sau:

- Cụ thể và đo lường được: Ví dụ “Người dùng thanh toán đơn hàng thành công” thay vì “Người dùng mua hàng”.

- Xuất phát từ góc nhìn người dùng: Tập trung vào lợi ích của actor, không phải logic nội bộ hệ thống.

- Đúng mức độ khái quát: Không quá rộng (ví dụ như "sử dụng website") và cũng không nên quá chi tiết (ví dụ “nhấn nút xác nhận”).
 

 

4. Preconditions (Điều kiện tiên quyết)

Preconditions là những điều kiện bắt buộc phải được thỏa mãn trước khi use case bắt đầu. Nếu bất kỳ điều kiện nào chưa được đáp ứng, use case sẽ không thể khởi động.

Ví dụ trong use case "Đặt hàng và thanh toán":

- Người dùng đã đăng nhập vào tài khoản.

- Giỏ hàng có ít nhất một sản phẩm.

- Sản phẩm trong giỏ hàng vẫn còn hàng trong kho.

Ghi rõ preconditions giúp đội phát triển biết cần kiểm tra những trạng thái nào trước khi cho phép người dùng tiến hành, đồng thời hỗ trợ đội kiểm thử thiết kế test case đầy đủ hơn.

5. Flow of Events (Luồng sự kiện)

Flow of Events là phần mô tả chi tiết toàn bộ quá trình tương tác giữa actor và hệ thống theo trình tự thời gian, từ khi bắt đầu đến khi kết thúc use case. Đây là phần quan trọng nhất trong tài liệu use case. Một use case thường bao gồm 3 loại luồng chính:

Main flow (luồng chính)

Main flow mô tả kịch bản lý tưởng khi mọi thứ diễn ra đúng như mong đợi, không có lỗi hay tình huống ngoại lệ nào xảy ra. Đây là luồng cần được xây dựng và kiểm thử trước tiên.

Ví dụ với use case "Đặt hàng":

- Người dùng mở trang giỏ hàng.

- Hệ thống hiển thị danh sách sản phẩm và tổng tiền.

- Người dùng nhấn "Tiến hành thanh toán."

- Hệ thống yêu cầu nhập địa chỉ giao hàng.

- Người dùng nhập thông tin và chọn phương thức thanh toán.

- Hệ thống xác nhận và tạo đơn hàng thành công.

Alternative flow (luồng thay thế)

Alternative flow mô tả các biến thể hợp lệ khác của luồng chính. Các luồng này vẫn dẫn đến kết quả thành công của use case nhưng theo những biến thể khác nhau. 

Ví dụ:

- Người dùng lựa chọn thanh toán qua ví điện tử thay vì thẻ ngân hàng.

- Người dùng áp dụng mã giảm giá trước khi thanh toán, hệ thống cập nhật lại tổng tiền.

Các luồng thay thế thường được ký hiệu theo dạng "A1, A2..." và gắn vào bước cụ thể trong main flow mà chúng có thể phân nhánh.

Exception flow (luồng ngoại lệ)

Exception flow mô tả những tình huống lỗi hoặc thất bại khiến use case không thể hoàn thành theo kế hoạch. Đây là phần dễ bị bỏ qua nhất nhưng lại cực kỳ quan trọng để đảm bảo trải nghiệm người dùng không bị gián đoạn đột ngột.

Ví dụ, trong use case "Đặt hàng":

- Sản phẩm hết hàng trong lúc người dùng đang thanh toán → Hệ thống thông báo và đề xuất sản phẩm tương tự.

- Giao dịch thanh toán bị từ chối → Hệ thống hiển thị thông báo lỗi và cho phép thử lại hoặc chọn phương thức khác.

- Mất kết nối mạng giữa chừng → Hệ thống lưu trạng thái đơn hàng và cho phép tiếp tục khi kết nối được khôi phục.

Phân biệt use case và user story

Trong quá trình phát triển website hoặc phần mềm, use case và user story đều được sử dụng để mô tả yêu cầu từ góc nhìn người dùng. Tuy nhiên, hai khái niệm này có mức độ chi tiết, mục đích sử dụng và cách triển khai khác nhau. Phân biệt rõ giúp đội ngũ sản phẩm lựa chọn phương pháp phù hợp trong từng giai đoạn phát triển.
 

Tầm quan trọng của use cases trong phát triển web

Trong nhiều dự án phát triển website, thất bại không đến từ việc thiếu công nghệ hay nhân sự mà thường xuất phát từ đội ngũ phát triển và khách hàng không có chung cách hiểu về hệ thống cần xây dựng. Use case giúp giải quyết vấn đề này bằng cách mô tả rõ ràng cách người dùng tương tác với hệ thống trong từng tình huống cụ thể. Dưới đây là những lý do quan trọng cho thấy vai trò của use case trong phát triển web.

1. Lấy người dùng làm trung tâm

Use case giúp đội ngũ phát triển tập trung vào nhu cầu thực tế của người dùng thay vì chỉ nhìn từ góc độ kỹ thuật. Thay vì đặt câu hỏi “có thể xây dựng tính năng gì?”, use case định hướng câu hỏi đúng hơn: “Người dùng cần đạt được điều gì và hệ thống hỗ trợ họ ra sao?”

Cách tiếp cận này giúp:

- Tránh phát triển các tính năng phức tạp nhưng không cần thiết.

- Xác định rõ đối tượng người dùng và hành vi của họ.

- Thiết kế giao diện UI và luồng thao tác hợp lý hơn.

Khi hệ thống được xây dựng dựa trên use case, mỗi chức năng đều có mục đích rõ ràng, từ đó giúp trải nghiệm người dùng trở nên mạch lạc và dễ sử dụng hơn.

2. Tối ưu hóa quy trình kiểm thử

Use case là nguồn đầu vào lý tưởng để xây dựng test case. Mỗi luồng sự kiện trong use case từ main flow, alternative flow đến exception flow đều tương ứng trực tiếp với một kịch bản cần được kiểm thử.  Nhờ đó, quá trình kiểm thử trở nên có hệ thống và toàn diện hơn. Đội QA có thể đảm bảo rằng cả 3 loại luồng đều được phủ sóng: 

- Kịch bản thành công.

- Kịch bản có biến thể hợp lệ.

- Kịch bản xảy ra lỗi. 

Khi một lỗi được phát hiện, truy ngược về use website case tương ứng cũng giúp xác định nhanh nguyên nhân gốc rễ và phạm vi ảnh hưởng. Về lâu dài, các use case còn có thể được tái sử dụng để xây dựng bộ kiểm thử hồi quy, bảo đảm chất lượng hệ thống sau mỗi lần cập nhật.

3. Cải thiện giao tiếp giữa khách hàng và lập trình viên

Một trong những khó khăn lớn nhất trong dự án phần mềm là sự khác biệt về ngôn ngữ giữa khách hàng (hiểu nghiệp vụ) và lập trình viên (hiểu kỹ thuật). Use case đóng vai trò như một “ngôn ngữ trung gian” giúp hai bên hiểu nhau dễ dàng hơn.

Khách hàng có thể đọc một use case và xác nhận ngay liệu luồng hoạt động có phản ánh đúng quy trình kinh doanh thực tế hay không mà không cần hiểu về cơ sở dữ liệu hay API. Ngược lại, lập trình viên có thể dựa vào use case để đặt câu hỏi cụ thể, làm rõ yêu cầu mơ hồ và tránh suy diễn sai. Khi có tranh chấp về yêu cầu, điều gần như chắc chắn xảy ra trong bất kỳ dự án nào, use case đã được ký duyệt trở thành tài liệu tham chiếu chính thức, giúp giải quyết mâu thuẫn nhanh hơn và có cơ sở hơn.

4. Kiểm soát phạm vi dự án

Scope creep là tình trạng phạm vi dự án liên tục mở rộng ngoài kế hoạch ban đầu. Đây là một trong những nguyên nhân hàng đầu khiến dự án web bị trễ deadline và vượt ngân sách. Use case là một trong những công cụ hiệu quả nhất để kiểm soát rủi ro này.

Khi toàn bộ các trường hợp sử dụng của hệ thống được liệt kê và thống nhất từ đầu, bất kỳ yêu cầu mới nào phát sinh về sau đều có thể được đánh giá dựa trên một câu hỏi đơn giản: "Yêu cầu này có thuộc về use case nào đã được xác định không?" Nếu không, đó là một thay đổi phạm vi cần được cân nhắc có chủ đích, chứ không phải điều chỉnh nhỏ được thêm vào tùy tiện. Sự minh bạch này giúp quản lý dự sam kiểm soát tiến độ và nguồn lực hiệu quả hơn. 
 

 

Hướng dẫn cách viết sơ đồ use case website chuyên nghiệp, hiệu quả

Để xây dựng một hệ thống website rõ ràng, dễ phát triển và dễ kiểm thử, thiết kế use case là bước không thể thiếu. Một sơ đồ use case được xây dựng tốt sẽ giúp đội ngũ hiểu đúng chức năng hệ thống, giảm sai sót trong quá trình phát triển và đảm bảo sự thống nhất giữa các bên liên quan. Dưới đây là quy trình các bước giúp bạn xây dựng use case website một cách có hệ thống, từ bước phân tích ban đầu đến khi hoàn thiện sơ đồ UML. 

Bước 1: Xác định các actor tham gia

Trong quá trình xây dựng use case website, bước đầu tiên và quan trọng nhất là xác định các actor tham gia hệ thống. Actor là những thực thể có khả năng tương tác với website để thực hiện một mục tiêu cụ thể, vì vậy xác định đúng và đủ actor sẽ quyết định tính chính xác của toàn bộ sơ đồ use case. Actor không chỉ giới hạn ở con người mà còn có thể là hệ thống bên ngoài hoặc các dịch vụ tự động có liên quan đến quá trình vận hành của website.

Thông thường, actor được chia thành các nhóm chính như sau:

- Người dùng cuối (End User): Là những người trực tiếp sử dụng website để thực hiện các hành động như đăng ký, đăng nhập, tìm kiếm sản phẩm, đặt hàng hoặc gửi yêu cầu.

- Quản trị viên (Admin): Là người chịu trách nhiệm quản lý hệ thống như quản lý người dùng, nội dung, đơn hàng hoặc cấu hình website.

- Hệ thống bên ngoài (External System): Bao gồm các dịch vụ tích hợp như cổng thanh toán, hệ thống email, đơn vị vận chuyển hoặc API bên thứ ba.

- Tác nhân tự động (System/Automation): Là các tiến trình chạy tự động như gửi email xác nhận, cập nhật trạng thái đơn hàng hoặc đồng bộ dữ liệu theo lịch trình.

 Bước 2: Xác định mục tiêu của từng actor

Sau khi đã xác định đầy đủ các actor tham gia hệ thống, bước tiếp theo là làm rõ mục tiêu mà từng actor muốn đạt được khi tương tác với website. Đây là bước quan trọng giúp chuyển từ danh sách đối tượng sang việc hiểu rõ “họ cần gì từ hệ thống”. Mỗi actor sẽ có những nhu cầu và kỳ vọng khác nhau, vì vậy xác định đúng mục tiêu sẽ giúp đảm bảo hệ thống được thiết kế đúng hướng, tránh xây dựng những chức năng không cần thiết.

Ở bước này, bạn cần trả lời câu hỏi: “Mỗi actor sử dụng hệ thống để làm gì?”

Cụ thể:

- Người dùng cuối (End User): Mục tiêu thường xoay quanh việc tìm kiếm thông tin, sử dụng dịch vụ hoặc hoàn thành giao dịch. Ví dụ: đăng ký tài khoản, tìm kiếm sản phẩm, đặt hàng, gửi yêu cầu hỗ trợ.

- Quản trị viên (Admin): Mục tiêu là kiểm soát và vận hành hệ thống một cách hiệu quả. Ví dụ: quản lý người dùng, cập nhật nội dung, xử lý đơn hàng, theo dõi hoạt động hệ thống.

- Hệ thống bên ngoài (External System): Mục tiêu là hỗ trợ xử lý một phần chức năng trong quy trình tổng thể. Ví dụ: xác thực thanh toán, gửi email thông báo, tính phí vận chuyển.

Bước 3: Viết luồng sự kiện chính

Sau khi xác định actor và mục tiêu của từng actor, bước tiếp theo là xây dựng luồng sự kiện chính (Main Flow). Đây là phần mô tả trình tự hoạt động tiêu chuẩn giữa người dùng và hệ thống khi không xảy ra lỗi hoặc ngoại lệ.

Luồng sự kiện chính đóng vai trò như “xương sống” của use case, giúp đội phát triển hiểu rõ cách hệ thống vận hành trong điều kiện bình thường. Đồng thời, đây cũng là cơ sở quan trọng để thiết kế UX/UI và logic xử lý backend.

Ví dụ luồng đăng nhập:

- Người dùng chọn chức năng “Đăng nhập”.

- Hệ thống hiển thị form đăng nhập.

- Người dùng nhập email và mật khẩu.

- Hệ thống kiểm tra thông tin xác thực.

- Hệ thống chuyển hướng người dùng đến trang chủ. 

Cách mô tả theo từng bước như vậy giúp phân tách rõ trách nhiệm giữa người dùng (actor) và hệ thống, đồng thời giảm nhầm lẫn trong quá trình phát triển.

Một luồng sự kiện chính được viết tốt cần đảm bảo:

- Rõ ràng và tuần tự: Các bước được sắp xếp theo đúng thứ tự thời gian.

- Không mơ hồ: Mỗi bước chỉ mô tả một hành động cụ thể.

- Không bao gồm lỗi hoặc ngoại lệ: Chỉ mô tả kịch bản thành công.

- Dễ triển khai: Có thể chuyển trực tiếp thành thiết kế và logic hệ thống.
 

Bước 4: Thêm các trường hợp ngoại lệ và rẽ nhánh

Sau khi hoàn thành luồng sự kiện chính, bước tiếp theo là mở rộng use case bằng cách bổ sung các luồng thay thế (alternative flow) và luồng ngoại lệ (exception flow). Đây là bước giúp mô hình use case phản ánh sát hơn với thực tế vận hành của hệ thống, không phải mọi tình huống đều diễn ra theo kịch bản lý tưởng.

1. Luồng thay thế (Alternative flow - rẽ nhánh hợp lệ)

Luồng thay thế là những kịch bản khác với luồng chính nhưng vẫn hợp lệ và vẫn đạt được mục tiêu của use case. Các nhánh này thường xuất hiện tại một bước cụ thể trong luồng chính.

Ví dụ trong use case “Đặt hàng”:

- Người dùng chọn phương thức thanh toán bằng ví điện tử thay vì thẻ ngân hàng.

- Người dùng áp dụng mã giảm giá trước khi xác nhận đơn hàng.

- Người dùng thay đổi địa chỉ giao hàng ngay tại bước thanh toán.

Các luồng này không làm thay đổi mục tiêu cuối cùng, chỉ thay đổi cách thức thực hiện.

2. Luồng ngoại lệ (Exception flow – tình huống lỗi)

Luồng ngoại lệ mô tả các trường hợp xảy ra lỗi hoặc gián đoạn khiến use case không thể hoàn thành như dự kiến.

Ví dụ:

- Sản phẩm hết hàng trong quá trình thanh toán.

- Thanh toán bị từ chối do lỗi ngân hàng hoặc không đủ số dư.

- Người dùng nhập sai thông tin nhiều lần và bị khóa tạm thời. 

- Hệ thống mất kết nối khi đang xử lý đơn hàng. 

Trong các tình huống này, hệ thống cần có cơ chế xử lý rõ ràng như:

- Hiển thị thông báo lỗi phù hợp.

- Cho phép người dùng thử lại hoặc chọn phương thức khác.

- Lưu trạng thái tạm thời để tránh mất dữ liệu.
 

 

Bước 5: Xác định điều kiện trước và sau

Precondition và postcondition thường bị bỏ qua, tuy nhiên trong phân tích hệ thống, chúng đóng vai trò như một ràng buộc logic của use case, xác định rõ trạng thái đầu vào và trạng thái đầu ra mà hệ thống phải tuân thủ.

- Precondition (điều kiện tiên quyết) là tập hợp các điều kiện bắt buộc phải được thỏa mãn trước khi use case được kích hoạt. Đây không chỉ bao gồm các yếu tố đơn giản như “người dùng đã đăng nhập” mà cần được mở rộng theo hướng toàn diện hơn, bao gồm: trạng thái dữ liệu hệ thống, tính sẵn sàng của các dịch vụ phụ thuộc (external services), cũng như quyền truy cập (authorization) của actor đối với chức năng tương ứng. 

- Postcondition (điều kiện hậu nghiệm) mô tả trạng thái của hệ thống sau khi use case kết thúc, bất kể kết quả là thành công hay thất bại có kiểm soát. Ví dụ, trong use case “Đặt hàng thành công”, postcondition có thể bao gồm: bản ghi đơn hàng được tạo trong cơ sở dữ liệu với trạng thái “processing”, tồn kho được cập nhật tương ứng, hệ thống kích hoạt quy trình gửi email xác nhận và giỏ hàng của người dùng được reset. 

Bước 6: Vẽ biểu đồ Use Case Diagram (UML)

Sau khi hoàn thiện tài liệu đặc tả use case, bước tiếp theo là trực quan hóa mô hình hệ thống thông qua Use Case Diagram theo chuẩn UML (Unified Modeling Language). Sơ đồ này không thay thế tài liệu đặc tả chi tiết mà đóng vai trò như một công cụ mô hình hóa tổng quan (high-level abstraction) giúp các bên liên quan nhanh chóng nắm bắt cấu trúc hệ thống.

Một Use Case Diagram chuẩn bao gồm 4 thành phần chính:

- System Boundary (ranh giới hệ thống): Biểu diễn phạm vi của hệ thống, thường được thể hiện bằng khung chữ nhật bao quanh toàn bộ use case.

- Actor: Đại diện cho thực thể tương tác với hệ thống, được đặt bên ngoài system boundary.

- Use Case: Biểu diễn chức năng hoặc dịch vụ mà hệ thống cung cấp, thể hiện bằng hình ellipse.

- Relationships (quan hệ): Bao gồm các liên kết giữa actor và use case, cũng như các quan hệ đặc thù như << include >> (tái sử dụng hành vi bắt buộc), << extend >> (mở rộng hành vi theo điều kiện) và generalization (kế thừa giữa actor hoặc use case).

Bước 7: Rà soát và tối ưu

Giai đoạn thẩm định (validation) và tối ưu hóa (refinement) là bước cuối cùng nhưng mang tính quyết định để  đảm bảo chất lượng của đặc tả use case. Một use case chưa được thẩm định đầy đủ có thể dẫn đến sai lệch yêu cầu, phát sinh lỗi thiết kế hoặc gia tăng chi phí chỉnh sửa ở giai đoạn sau.

Quy trình thẩm định thường được thực hiện theo hai cấp độ:

- Internal review (thẩm định nội bộ): BA, developer và QA cùng rà soát tính nhất quán của tài liệu, kiểm tra độ đầy đủ của luồng xử lý, phát hiện các điểm thiếu logic, mâu thuẫn hoặc chưa được đặc tả rõ ràng giữa các use case.

- Stakeholder review (thẩm định với bên liên quan): Đối chiếu use case với nghiệp vụ thực tế để đảm bảo tính phù hợp (business alignment) và tránh hiểu sai yêu cầu trong quá trình phân tích.
 

 

Ví dụ thực tế về website use cases

Thay vì chỉ mô tả chức năng ở mức khái quát, sơ đồ use case đi sâu vào từng kịch bản cụ thể, giúp làm rõ luồng xử lý, trách nhiệm của hệ thống và hành vi của người dùng trong từng tình huống. Dưới đây là một số ví dụ điển hình về use case thường gặp trong các website thực tế.

Ví dụ 1: Use case đăng nhập

Use case “Đăng nhập” là một trong những use case website cơ bản và phổ biến nhất, dùng để mô tả cách người dùng xác thực danh tính và truy cập vào hệ thống. Đây là chức năng nền tảng, thường xuất hiện trong các website use cases có yêu cầu tài khoản người dùng.

- Actor: Người dùng (User)

- Mục tiêu: Truy cập vào hệ thống bằng tài khoản hợp lệ

- Luồng chính:

(1) Người dùng truy cập trang đăng nhập.

(2) Hệ thống hiển thị form đăng nhập.

(3) Người dùng nhập email và mật khẩu.

(4) Hệ thống xác thực thông tin.

(5) Hệ thống cho phép truy cập và chuyển hướng đến trang chính.

- Luồng ngoại lệ:

Sai email hoặc mật khẩu → Hệ thống hiển thị thông báo lỗi.

Tài khoản bị khóa → Hệ thống từ chối truy cập.

Quên mật khẩu → Chuyển sang quy trình khôi phục mật khẩu.

Use case này thường được thể hiện rõ trong sơ đồ use case với actor “User” kết nối trực tiếp đến chức năng “Login”.

Ví dụ 2: Use case mua hàng

Use case “Mua hàng” là một website use cases phức tạp hơn, thường xuất hiện trong các hệ thống thương mại điện tử.

- Actor: Khách hàng (Customer), Hệ thống thanh toán (Payment Gateway)

- Mục tiêu: Hoàn tất quá trình đặt hàng và thanh toán thành công

- Luồng chính:

(1) Khách hàng chọn sản phẩm.

(2) Thêm sản phẩm vào giỏ hàng.

(3) Kiểm tra giỏ hàng và tiến hành thanh toán.

(4) Nhập thông tin giao hàng.

(5) Chọn phương thức thanh toán.

(6) Hệ thống xử lý thanh toán.

(7) Tạo đơn hàng thành công và gửi xác nhận.

- Luồng thay thế:

Áp dụng mã giảm giá → hệ thống cập nhật lại tổng tiền

Thay đổi phương thức thanh toán → hệ thống điều hướng sang cổng thanh toán khác

- Luồng ngoại lệ:

Thanh toán thất bại → Yêu cầu thử lại hoặc chọn phương thức khác.

Sản phẩm hết hàng → Hệ thống thông báo và loại khỏi giỏ hàng.

Lỗi kết nối → Lưu trạng thái đơn hàng tạm thời.

Use case này thường được mô tả chi tiết trong cả tài liệu use case website và thể hiện trực quan trong sơ đồ use case, giúp đội phát triển hiểu rõ toàn bộ quy trình từ chọn sản phẩm đến hoàn tất giao dịch.

 

 

Một số hạn chế của việc xây dựng website use cases

Mặc dù website use cases là công cụ quan trọng trong phân tích hệ thống, giúp làm rõ luồng xử lý và hành vi người dùng nhưng trong thực tế triển khai dự án, phương pháp này vẫn tồn tại nhiều hạn chế nhất định. Nếu không được kiểm soát tốt, tài liệu use case có thể trở nên phức tạp, khó duy trì và giảm hiệu quả trong quá trình phát triển web.

- Tốn nhiều thời gian xây dựng và duy trì tài liệu use case: Xây dựng đầy đủ một use case website không chỉ dừng ở mô tả chức năng, mà còn bao gồm actor, mục tiêu, luồng chính, luồng thay thế và luồng ngoại lệ. Với các hệ thống lớn, số lượng website use cases có thể rất nhiều, dẫn đến việc mất nhiều thời gian để viết, rà soát và cập nhật khi có thay đổi. Điều này khiến quy trình phân tích trở nên nặng nề nếu không có quy chuẩn rõ ràng.

- Dễ dẫn đến tài liệu quá chi tiết hoặc cồng kềnh: Một trong những vấn đề phổ biến khi xây dựng sơ đồ use case là xu hướng “over-specification”, tức mô tả quá chi tiết từng bước xử lý. Khi đó, tài liệu use case trở nên dài dòng, khó đọc và mất đi tính tổng quan. Thay vì hỗ trợ phát triển, tài liệu lại trở thành gánh nặng cho đội dự án.

- Khó bảo trì khi hệ thống thay đổi thường xuyên: Trong môi trường phát triển agile, yêu cầu sản phẩm có thể thay đổi liên tục. Khi đó, toàn bộ website use cases liên quan cũng cần cập nhật lại. Nếu không có quy trình quản lý tài liệu tốt, rất dễ xảy ra tình trạng use case và hệ thống thực tế bị lệch nhau, gây hiểu nhầm trong quá trình phát triển và kiểm thử.

- Không phù hợp với các chức năng đơn giản hoặc thay đổi nhanh: Với những tính năng nhỏ như “hiển thị thông báo” hoặc “bật/tắt một tùy chọn”, xây dựng đầy đủ sơ đồ use case có thể trở nên không cần thiết. Trong các trường hợp này, use case có thể gây lãng phí thời gian thay vì mang lại giá trị thực tế cho dự án.
 

 

Những lỗi thường gặp khi xây dựng use case website và cách khắc phục

Trong quá trình xây dựng use case website, dù đã có quy trình và nguyên tắc rõ ràng, người phân tích vẫn dễ mắc phải nhiều sai sót khiến tài liệu sơ đồ use case và hệ thống website use cases trở nên thiếu nhất quán hoặc khó áp dụng trong thực tế. Những lỗi này thường không xuất hiện ngay lập tức nhưng sẽ bộc lộ rõ khi hệ thống bắt đầu phát triển hoặc khi chuyển sang giai đoạn kiểm thử và triển khai. Dưới đây là một số lỗi thường gặp trong quá trình xây dựng use case website cùng với hướng khắc phục dành cho bạn:

1. Quá tập trung vào giao diện thay vì hành vi

Lỗi thường gặp khi xây dựng use case website là mô tả theo hướng giao diện (UI) thay vì mô tả hành vi và tương tác logic giữa actor và hệ thống. Người viết thường bị ảnh hưởng bởi thiết kế màn hình, dẫn đến các use case bị biến thành danh sách thao tác trên UI như “nhấn nút”, “click icon”, thay vì mô tả mục tiêu và luồng xử lý. Điều này làm mất đi bản chất của website use cases, vốn phải tập trung vào hành vi và mục tiêu của người dùng.

Cách khắc phục:

- Luôn bắt đầu từ câu hỏi “Người dùng muốn đạt được điều gì?” thay vì “Họ click vào đâu?”.

- Mô tả theo hướng hành vi và hệ thống phản hồi, không phụ thuộc giao diện.

- Tách biệt rõ giữa use case (logic) và UI flow (thiết kế giao diện).

2. Chia nhỏ use cases quá mức

Nếu chia sơ đồ use cases thành  quá nhiều use case nhỏ, hệ thống sẽ bị phân mảnh và khó quản lý. Thay vì gom các hành vi liên quan thành một use case logic hoàn chỉnh, người viết lại tách thành nhiều use case rời rạc không cần thiết. Điều này khiến tài liệu trở nên rối, khó theo dõi và làm giảm tính tổng quan của hệ thống.

Một số cách khắc phục tình trạng này:

- Nhóm các hành vi có cùng mục tiêu vào một use case chính.

- Chỉ tách use case khi có sự khác biệt rõ ràng về mục tiêu hoặc actor.

- Giữ mức độ chi tiết ở ngưỡng vừa đủ để đảm bảo dễ hiểu và dễ triển khai.
 

 

3. Bỏ qua các luồng ngoại lệ

Trong nhiều use case website, người phân tích chỉ tập trung vào luồng chính (main flow) mà bỏ qua luồng ngoại lệ (exception flow). Điều này khiến hệ thống thiếu các kịch bản xử lý lỗi, dẫn đến rủi ro trong quá trình vận hành thực tế. Các trường hợp như lỗi thanh toán, mất kết nối, dữ liệu không hợp lệ… nếu không được mô tả trong website use cases, sẽ gây khó khăn cho cả lập trình viên và đội QA.

Cách khắc phục:

- Luôn bổ sung ít nhất 1 - 3 luồng ngoại lệ cho mỗi use case quan trọng.

- Nghĩ theo hướng “hệ thống có thể lỗi ở đâu?” khi phân tích. 

- Phối hợp với QA để đảm bảo đầy đủ kịch bản kiểm thử. 

 4. Nhầm lẫn giữa actor và vai trò (role)

Một lỗi khá phổ biến khi vẽ sơ đồ use case là nhầm lẫn giữa actor và vai trò (role). Người viết có thể tạo quá nhiều actor không cần thiết hoặc đặt tên actor không đúng bản chất, dẫn đến sơ đồ trở nên khó hiểu và thiếu chuẩn hóa.

Ví dụ, thay vì gom “Khách hàng” thành một actor, lại tách thành “Người mua”, “Người xem”, “Người đăng ký” dù thực tế đó chỉ là các vai trò khác nhau của cùng một người dùng.

Cách khắc phục: 

- Xác định actor dựa trên hệ thống tương tác, không dựa trên hành vi nhỏ lẻ.

- Nhóm các hành vi tương tự vào cùng một actor khi có thể.

- Phân biệt rõ actor (thực thể tương tác) và role (vai trò trong ngữ cảnh). 

5. Viết use case quá kỹ thuật

Khi người trực tiếp xây dựng use case website là lập trình viên, tài liệu thường dễ bị “kỹ thuật hóa” quá mức. Thay vì mô tả hành vi nghiệp vụ, use case lại bị biến thành mô tả triển khai hệ thống như: gọi API, xử lý database, hay cơ chế message queue. Viết use case đi sâu vào cách hệ thống hoạt động thay vì tập trung vào hành vi và mục tiêu của người dùng, dễ bị “biến tướng” thành tài liệu thiết kế kỹ thuật (technical design) hoặc pseudo-code.

Nguyên tắc quan trọng trong website use cases là mô tả hành vi ở mức black-box perspective,  tức là chỉ tập trung vào những gì có thể quan sát từ bên ngoài hệ thống, không đi vào cách hệ thống thực hiện bên trong. Một quy tắc thực hành hiệu quả là: nếu một câu chỉ lập trình viên mới hiểu, thì câu đó cần được viết lại theo ngôn ngữ nghiệp vụ.

6. Thiếu sự liên kết với UI/UX và hệ thống 

Một trong những hạn chế lớn của use case website là không mô tả trực tiếp trải nghiệm giao diện người dùng (UI) và hành trình tương tác thực tế (UX). Sơ đồ use case chủ yếu tập trung vào logic nghiệp vụ và mối quan hệ giữa actor với hệ thống, vì vậy không thể hiện rõ người dùng sẽ di chuyển qua các màn hình như thế nào hoặc trải nghiệm từng bước ra sao. 

Ví dụ, nếu use case mô tả “hệ thống gợi ý sản phẩm ngay lập tức”, trong khi thực tế cần thời gian xử lý bất đồng bộ thì use case đang tạo ra kỳ vọng sai lệch cho cả đội UX và người dùng cuối.

Để khắc phục hạn chế này, team cần kết hợp thêm user flow trong quá trình phân tích. Nếu use case mô tả “hệ thống cần làm gì” ở góc nhìn nghiệp vụ, thì user flow lại mô tả “người dùng đi qua từng bước giao diện như thế nào”. Sự kết hợp này giúp đảm bảo hệ thống vừa đúng logic, vừa tối ưu trải nghiệm người dùng. 

7. Không xác định rõ phạm vi hệ thống

Một lỗi nghiêm trọng khác khi xây dựng website use cases là thiếu định nghĩa rõ ràng về system boundary. Khi ranh giới hệ thống không được xác định, use case dễ bị mở rộng sang cả những thành phần nằm ngoài phạm vi kiểm soát của website, chẳng hạn như hệ thống ngân hàng, cổng thanh toán hoặc ứng dụng bên thứ ba. Hệ quả là tài liệu trở nên phình to, khó quản lý và gây nhầm lẫn về trách nhiệm giữa các hệ thống.

Do đó, bạn cần xác định rõ ngay từ đầu: hệ thống chịu trách nhiệm xử lý phần nào, hệ thống bên ngoài đảm nhiệm phần nào và cơ chế tương tác giữa các bên được thực hiện ra sao. Một lưu ý trong sơ đồ use case là luôn xác định system boundary trước khi mô tả chi tiết use case nhằm đảm bảo mọi actor và hành vi đều nằm đúng phạm vi được định nghĩa.

8. Không cập nhật use case khi hệ thống thay đổi

Trong nhiều dự án, use case website chỉ được xây dựng một lần ở giai đoạn khởi tạo và sau đó không được cập nhật khi hệ thống thay đổi. Trong khi đó, các thay đổi thường xuyên lại chỉ được phản ánh trong code hoặc task management tool, dẫn đến sự lệch pha giữa tài liệu và sản phẩm thực tế.

Kết quả là sau một thời gian phát triển, website use cases không còn phản ánh đúng hệ thống đang vận hành, làm giảm giá trị tham chiếu của tài liệu trong cả phát triển lẫn kiểm thử.

Để khắc phục, cần đưa việc cập nhật use case vào quy trình phát triển chính thức, ví dụ như một phần của Definition of Done (DoD). Mỗi khi có thay đổi về luồng nghiệp vụ, exception mới hoặc điều chỉnh từ stakeholder, use case liên quan phải được cập nhật đồng thời. Lưu trữ use case trong hệ thống version control (như Git) hoặc công cụ quản lý tài liệu cũng giúp đảm bảo khả năng truy vết (traceability) và duy trì tính nhất quán trong toàn bộ vòng đời dự án.
 

 

Qua bài viết của Phương Nam Vina, có thể thấy use case website là một công cụ quan trọng trong phân tích và thiết kế hệ thống, giúp mô tả rõ ràng các kịch bản tương tác giữa người dùng và hệ thống trong từng tình huống cụ thể. Thông qua xác định actor, mục tiêu, luồng xử lý và các trường hợp ngoại lệ, use case giúp đội phát triển hiểu đúng yêu cầu nghiệp vụ và xây dựng hệ thống một cách logic, nhất quán. Bên cạnh đó, khi kết hợp với sơ đồ use case, user flow và các tài liệu thiết kế khác, use case không chỉ hỗ trợ lập trình mà còn giúp cải thiện giao tiếp giữa BA, developer và UX/UI designer. Tuy vẫn tồn tại một số hạn chế trong quá trình áp dụng thực tế nhưng nếu được xây dựng đúng cách, use case sẽ trở thành nền tảng quan trọng giúp tối ưu hóa quá trình phát triển website và đảm bảo sản phẩm cuối cùng đáp ứng đúng nhu cầu người dùng.

Tham khảo thêm:

 Navigation bar là gì? Cách tạo và tối ưu navigation bar

 Hành trình khách hàng là gì? Tổng quan về customer journey

 Breadcrumb là gì? Vai trò và cách tối ưu breadcrumb website