Use Case (UC)
Mô tả một tương tác giữa actor và hệ thống để đạt một mục tiêu nghiệp vụ. Trả lời câu hỏi: ai làm gì với hệ thống? Đây là đơn vị làm việc chính trong SDD.
Các thành phần tối thiểu
- ID (vd
UC-042) - không có ID thì rất khó lần ngược từ spec sang code, test, commit, PR hay incident. - Actor - ai thực hiện (user thường, admin, scheduled job, webhook, support). Mỗi loại dẫn tới permission và validation khác nhau.
- Trigger - use case bắt đầu khi nào (button click, webhook, cron job, event nội bộ → thiết kế code khác nhau).
- Main Flow - happy path. AI làm khá ổn nếu được viết rõ.
- Alternative Flows - biến thể hợp lệ. Nơi nhiều bug xuất hiện vì business nghĩ “cái đó đương nhiên” còn dev và AI thì không.
- Exceptions - tình huống lỗi đã có quyết định xử lý. Đừng trộn với bug: “QR hết hạn thì hiển thị lỗi và cho tạo lại” là exception; “app crash khi QR hết hạn” là bug.
- Acceptance Criteria - không có AC, spec mới chỉ là mô tả; có AC, spec bắt đầu kiểm thử được.
Mẹo thực hành
Đừng cố nghĩ hết Alternative và Exception ngay vòng đầu. Viết đủ những case rõ nhất để bắt đầu, rồi bổ sung khi review/test/user phản hồi. Spec tốt không phải spec hoàn hảo từ ngày đầu, mà là spec chịu được việc học thêm → Iterative Improvement.
Liên quan
- Bốn tầng của yêu cầu - UC là tầng 2
- Acceptance Criteria - phần biến UC thành thứ kiểm thử được
- Business Requirement (BR) - UC phục vụ BR nào
- Hexagonal Architecture - mỗi UC map gần 1-1 với use case trong domain core