Use Case

Dài hơn user story rất nhiều, và đó vừa là điểm mạnh vừa là điểm yếu. Một use case kể lại đầy đủ câu chuyện giữa người dùng và hệ thống để đạt một mục tiêu: bắt đầu từ đâu, đi qua bước nào, gặp trục trặc thì rẽ ra sao, kết thúc ở trạng thái nào. Alistair Cockburn phổ biến định dạng này từ cuối những năm 90, và với nghiệp vụ phức tạp thì vẫn chưa có thứ gì thay thế tốt hơn.

Use case là đặc tả từng bước tương tác giữa actor và hệ thống cho một mục tiêu cụ thể, gồm cả luồng chính, luồng thay thế và luồng ngoại lệ.

Cấu trúc đầy đủ

Use case viết nghiêm túc luôn có đủ các phần sau. Thiếu phần nào là thiếu đúng phần đó của sự thật.

• Mã và tên — động từ + danh từ theo góc nhìn actor: "Rút tiền tại ATM", không phải "Xử lý giao dịch rút".
• Actor — chính và phụ. Actor phụ thường là hệ thống ngoài.
• Precondition — điều kiện phải đúng trước khi use case bắt đầu. Trigger — cái gì kích hoạt.
• Main flow — đường đi khi mọi thứ suôn sẻ, đánh số từng bước, xen kẽ actor làm gì và hệ thống làm gì.
• Alternative flow — nhánh vẫn dẫn tới thành công nhưng đi đường khác.
• Exception flow — nhánh thất bại, kết thúc mà không đạt mục tiêu.
• Postcondition — trạng thái sau khi kết thúc, tách hai trường hợp thành công và thất bại. Business rules và NFR liên quan thì tuỳ nơi, nhiều chỗ đẩy hết xuống phụ lục.

Ví dụ thực tế: UC-PAY-03 Thanh toán đơn hàng bằng thẻ

Bối cảnh: website bán hàng của một chuỗi siêu thị điện máy 41 điểm bán, 1.900 đơn mỗi ngày, giá trị đơn trung bình 4,2 triệu, tích hợp một cổng thanh toán trong nước.

Actor chính: Khách hàng đã đăng nhập. Actor phụ: Cổng thanh toán, Hệ thống kho.

Precondition: Khách đã đăng nhập; giỏ hàng có ít nhất một sản phẩm; đã chọn địa chỉ giao hàng.

Trigger: Khách bấm "Thanh toán".

Main flow

1. Hệ thống hiển thị màn hình xác nhận đơn: danh sách sản phẩm, phí vận chuyển, tổng tiền.
2. Khách chọn phương thức "Thẻ nội địa/quốc tế" và bấm Xác nhận.
3. Hệ thống kiểm tra tồn kho khả dụng của từng SKU.
4. Hệ thống tạo đơn ở trạng thái PENDING_PAYMENT và giữ tồn kho trong 15 phút.
5. Hệ thống chuyển khách sang trang của cổng thanh toán kèm mã giao dịch.
6. Khách nhập thông tin thẻ và xác thực OTP.
7. Cổng thanh toán trả về kết quả thành công.
8. Hệ thống chuyển đơn sang PAID, trừ tồn kho thật, đẩy đơn sang kho đóng gói.
9. Hệ thống hiển thị màn hình cảm ơn và gửi email xác nhận.

Alternative flow

• 3a. Một SKU không đủ tồn: hệ thống hiển thị thông báo kèm danh sách SKU thiếu, cho khách chọn "Bỏ sản phẩm và tiếp tục" hoặc "Quay lại giỏ". Nếu khách bỏ sản phẩm, quay về bước 1 với giỏ đã cập nhật.
• 2a. Khách có mã giảm giá: hệ thống áp mã, tính lại tổng tiền, ghi log mã đã dùng, rồi tiếp tục bước 3.
• 6a. Khách chọn thanh toán bằng ví liên kết thay vì thẻ: chuyển sang UC-PAY-05, kết quả trả về nhập lại ở bước 7.

Exception flow

• 7a. Cổng thanh toán trả về thất bại (thẻ không đủ tiền, sai OTP quá 3 lần): hệ thống giữ đơn ở PENDING_PAYMENT, hiển thị lý do, cho phép thử lại tối đa 2 lần trong thời hạn giữ tồn kho.
• 7b. Cổng thanh toán không phản hồi trong 30 giây: hệ thống chuyển đơn sang PENDING_CONFIRMATION, không trừ tồn kho, kích hoạt job đối soát sau 15 phút và thông báo cho khách rằng đơn đang chờ xác nhận.
• 4a. Hết 15 phút giữ tồn kho mà chưa thanh toán: hệ thống nhả tồn kho, chuyển đơn sang EXPIRED, gửi thông báo cho khách.

Postcondition — thành công: đơn ở trạng thái PAID, tồn kho đã trừ, có bản ghi đối soát được với cổng thanh toán. Postcondition — thất bại: không có tiền nào bị trừ mà thiếu đơn tương ứng; tồn kho nhả về đúng trạng thái ban đầu.

Nhánh 7b là loại chi tiết mà một user story ba dòng không bao giờ nói ra được, và bỏ sót nó thì đội vận hành gánh phần còn lại bằng tay.

So sánh với User Story

Hai thứ không loại trừ nhau. Nhiều team viết user story cho backlog, rồi đính kèm use case đầy đủ cho các luồng phức tạp.

Lỗi hay gặp

• Mô tả giao diện thay vì hành vi: "khách bấm nút màu xanh góc phải". Use case sống lâu hơn thiết kế UI, đừng trói nó vào màu nút.
• Nhét nhiều mục tiêu vào một use case. Tên có chữ "và" thì nên tách.
• Bỏ trống exception flow vì "chỗ đó hiển nhiên". Không hiển nhiên với dev đang gõ code lúc 11 giờ đêm.
• Viết precondition thành "người dùng mở trình duyệt". Precondition phải có ý nghĩa nghiệp vụ.