Mở đầu — vì sao bài này quan trọng
Ở Bài 46, bạn đã học cách viết PRD cho môi trường Agile — tài liệu mô tả cái gì và tại sao ở tầm sản phẩm. Nhưng khi đội phát triển bắt tay vào xây dựng một chức năng cụ thể, họ luôn cần một câu hỏi được trả lời rõ ràng: "Khi người dùng thực sự làm việc này, từng bước diễn ra như thế nào, và nếu có gì sai thì hệ thống xử lý ra sao?" Đó chính là lúc Use Case specification lên tiếng.
Nhiều BA mới nhầm Use Case với User Story (Bài 6) hay với Use Case diagram của UML (Bài 49). Hãy phân biệt ngay từ đầu cho rõ: User Story là một câu ngắn nhắc nhở cần trò chuyện thêm; Use Case diagram chỉ là hình vẽ mấy cái bong bóng nối với "người que". Còn Use Case specification là một văn bản kể chuyện (narrative) chi tiết, mô tả trọn vẹn một mục tiêu của người dùng từ lúc bắt đầu đến lúc hoàn thành — bao gồm cả những ngả rẽ khi mọi thứ không diễn ra suôn sẻ. Nó là cầu nối giữa "ý tưởng nghiệp vụ" và "việc dev gõ code".
Vì sao kỹ năng này quan trọng đến mức được dành riêng một bài? Vì trong các hệ thống có logic phức tạp — ngân hàng, bảo hiểm, ERP, fintech — một User Story kiểu "Là khách hàng, tôi muốn mở tài khoản online để khỏi ra quầy" là quá mỏng. Nó không nói gì về việc OTP gửi sai, eKYC thất bại, hay khách bỏ dở giữa chừng. Use Case spec buộc bạn nghĩ trọn vẹn mọi nhánh, và chính kỷ luật suy nghĩ đó mới là giá trị thật. Bài này dạy bạn cấu trúc narrative kiểu Cockburn — chuẩn mực kinh điển nhất của ngành — và cách viết nó sao cho dev đọc xong là làm được.
Khái niệm cốt lõi
Use Case là gì, theo đúng nghĩa
Use Case mô tả cách một actor (tác nhân — người hoặc hệ thống bên ngoài) tương tác với hệ thống để đạt được một mục tiêu có giá trị. Điểm mấu chốt nằm ở chữ "mục tiêu": một Use Case tốt luôn ứng với một việc mà actor muốn hoàn thành trọn vẹn trong một lần ngồi xuống — ví dụ "Mở tài khoản online", "Chuyển khoản", "Hủy đơn hàng". Nó không phải là "Nhấn nút Đăng nhập" (quá nhỏ, chỉ là một bước) cũng không phải "Quản lý tài khoản" (quá lớn, gộp nhiều mục tiêu).
Alistair Cockburn — tác giả cuốn Writing Effective Use Cases mà cả ngành tham chiếu — gọi cấp độ mục tiêu này là user goal level (mức "sea level", ngang mặt biển). Đây là cấp độ vàng để viết Use Case: đủ lớn để có ý nghĩa nghiệp vụ, đủ nhỏ để mô tả trọn trong một văn bản.
Cấu trúc một Use Case spec kiểu Cockburn
Đây là khung sườn chuẩn mà bạn nên thuộc lòng. Mỗi trường (field) có một nhiệm vụ riêng:
| Trường | Mô tả | Ví dụ |
|---|---|---|
| Use Case Name | Động từ + tân ngữ, mô tả mục tiêu | "Mở tài khoản thanh toán online" |
| Use Case ID | Mã định danh để truy vết | UC-ACC-01 |
| Primary Actor | Tác nhân chính khởi xướng | Khách hàng cá nhân chưa có tài khoản |
| Stakeholders & Interests | Các bên liên quan và mong muốn của họ | Khách: nhanh, không ra quầy. Ngân hàng: đúng eKYC, chống gian lận |
| Preconditions | Điều kiện phải đúng trước khi bắt đầu | Khách có CCCD gắn chip, có số điện thoại chính chủ |
| Trigger | Sự kiện kích hoạt Use Case | Khách nhấn "Mở tài khoản" trên app/web |
| Postconditions (Success Guarantee) | Trạng thái hệ thống sau khi thành công | Tài khoản được tạo, số TK sinh ra, gửi email/SMS xác nhận |
| Minimal Guarantee | Điều hệ thống đảm bảo kể cả khi thất bại | Không tạo tài khoản dở dang; dữ liệu cá nhân không bị lưu rác |
| Main Success Scenario | Luồng chính (happy path), đánh số từng bước | (xem bên dưới) |
| Extensions / Alternate Flows | Các nhánh rẽ khi điều kiện khác xảy ra | 3a, 5b... lỗi OTP, eKYC fail |
| Special Requirements | Yêu cầu phi chức năng gắn liền | eKYC phản hồi < 5 giây, mã hóa dữ liệu CCCD |
| Frequency / Assumptions | Tần suất, giả định | ~2.000 lượt/ngày giờ cao điểm |
Main Success Scenario — trái tim của narrative
Đây là phần "kể chuyện" cốt lõi. Quy tắc viết:
- Mỗi bước là một câu, ở thì hiện tại, có chủ ngữ rõ ràng (actor hoặc hệ thống làm gì).
- Đánh số tuần tự 1, 2, 3...
- Luân phiên qua lại: actor làm → hệ thống phản hồi → actor làm tiếp.
- Mô tả ý định nghiệp vụ, không mô tả UI ("Hệ thống xác thực danh tính", chứ không phải "Hệ thống hiển thị nút màu xanh ở góc phải").
- Khách nhập số điện thoại và yêu cầu mã OTP.
- Hệ thống gửi OTP và khách nhập mã xác thực thành công.
- Khách chụp ảnh hai mặt CCCD gắn chip.
- Hệ thống trích xuất thông tin và đối chiếu với cơ sở dữ liệu định danh (eKYC).
- Khách quay video selfie để kiểm tra liveness.
- Hệ thống xác nhận khuôn mặt khớp với ảnh CCCD.
- Khách chọn loại tài khoản và xác nhận điều khoản.
- Hệ thống tạo tài khoản, sinh số tài khoản, gửi SMS/email xác nhận.
Extensions — nơi BA giỏi tỏa sáng
Luồng chính ai cũng viết được. Cái phân biệt một spec nghiệp dư với chuyên nghiệp là độ phủ của các nhánh rẽ (extensions). Mỗi extension được đánh số theo bước mà nó rẽ ra: nhánh rẽ tại bước 2 là 2a, 2b; tại bước 4 là 4a, 4b...
Ví dụ với Use Case trên:
- 2a. OTP nhập sai: Hệ thống báo lỗi, cho nhập lại tối đa 3 lần. Sau 3 lần, khóa 15 phút, kết thúc Use Case (về Minimal Guarantee).
- 4a. eKYC không khớp / CCCD mờ: Hệ thống yêu cầu chụp lại tối đa 2 lần; nếu vẫn fail, chuyển sang luồng định danh tại quầy.
- 6a. Liveness thất bại: Hệ thống yêu cầu quay lại trong điều kiện ánh sáng tốt hơn.
- 8a. Số CCCD đã có tài khoản: Hệ thống dừng, thông báo "Bạn đã có tài khoản", gợi ý đăng nhập.
Tình huống thực tế
Ví dụ 1 — Ngân hàng số: cái giá của extension bị bỏ sót
Một ngân hàng số tại TP.HCM (gọi là "NeoBank VN") triển khai tính năng mở tài khoản online. BA đầu tiên chỉ viết User Story ngắn và luồng happy path. Đội dev xây xong, demo mượt mà. Nhưng khi go-live, tổng đài nổ máy: khoảng 18% khách bị kẹt ở bước eKYC vì CCCD chụp ngược sáng, app không hướng dẫn gì, màn hình đứng im. Khách bỏ cuộc, tỷ lệ hoàn thành chỉ đạt 61%.
Khi BA mới được giao viết lại dưới dạng Use Case spec fully dressed, chị liệt kê 11 extensions chỉ riêng cho khâu eKYC và OTP — bao gồm CCCD mờ, mã hết hạn, mất mạng giữa chừng, khách đã có tài khoản. Sau khi dev xử lý các nhánh này, tỷ lệ hoàn thành tăng lên 87% trong hai tháng.
Bài học: Phần lớn rủi ro của một chức năng không nằm ở luồng chính mà nằm ở các nhánh rẽ. Use Case spec ép bạn truy hết những nhánh đó trước khi code, thay vì để khách hàng phát hiện hộ bạn ngoài production.
Ví dụ 2 — Sàn TMĐT: viết quá chi tiết UI khiến spec lỗi thời
Một sàn thương mại điện tử kiểu Tiki/Shopee thuê BA viết Use Case "Hủy đơn hàng". Vị BA này rất chăm chỉ nhưng viết bước kiểu: "Khách nhấn nút Hủy màu đỏ ở góc dưới bên phải, popup hiện ra với hai nút Đồng ý và Quay lại". Ba tuần sau, team thiết kế đổi giao diện — nút Hủy chuyển lên đầu trang, popup thành màn hình riêng. Toàn bộ spec sai, dev và QA tranh cãi xem theo tài liệu hay theo Figma.
BA senior sửa lại theo nguyên tắc mô tả ý định, không mô tả pixel: "Khách yêu cầu hủy đơn → Hệ thống xác nhận đơn còn ở trạng thái cho phép hủy → Hệ thống hoàn tiền theo phương thức gốc". Extension xử lý các trạng thái: đơn đã đóng gói (chỉ hủy được khi shipper chưa lấy hàng), đơn đã thanh toán qua ví (hoàn vào ví), đơn COD (chỉ cần đánh dấu hủy). Bản này ổn định qua nhiều lần đổi UI.
Bài học: Use Case sống ở tầng nghiệp vụ và logic, không phải tầng giao diện. Càng buộc spec vào chi tiết UI, spec càng nhanh lỗi thời và càng mất uy tín với đội.
Ví dụ 3 — Fintech ví điện tử: Preconditions cứu một lỗ hổng
Một startup ví điện tử ở Hà Nội viết Use Case "Nạp tiền từ tài khoản ngân hàng liên kết". BA cẩn thận ghi rõ Preconditions: "Khách đã liên kết thành công ít nhất một tài khoản ngân hàng và tài khoản đó đang ở trạng thái active". Trong buổi review, một dev hỏi: "Thế nếu ngân hàng vừa khóa liên kết của khách vì lý do bảo mật, mà app mình chưa cập nhật trạng thái thì sao?" Câu hỏi đó dẫn đến một extension mới (1a. Liên kết đã bị ngân hàng hủy phía họ) và một yêu cầu kỹ thuật: kiểm tra trạng thái liên kết theo thời gian thực trước mỗi giao dịch nạp.
Nhờ phát hiện sớm ở khâu spec, đội tránh được một lỗi có thể gây giao dịch treo và khiếu nại tiền bạc — loại lỗi đắt nhất trong fintech.
Bài học: Preconditions không phải thủ tục cho có. Việc viết rõ "điều gì phải đúng trước khi bắt đầu" thường lôi ra những giả định ngầm nguy hiểm mà cả nhóm chưa từng đặt câu hỏi.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng ngay khi nhận một chức năng cần viết Use Case spec:
Bước 1 — Xác định Primary Actor và mục tiêu. Hỏi: "Ai khởi xướng việc này, và họ muốn đạt được điều gì có giá trị?" Đặt tên Use Case theo công thức động từ + tân ngữ ở mức user goal. Nếu tên nghe quá to ("Quản lý đơn hàng") hãy tách nhỏ; nếu quá vụn ("Nhấn nút lưu") hãy gộp lên.
Bước 2 — Liệt kê Stakeholders & Interests. Mỗi bên liên quan muốn gì? Mục này giúp bạn không bỏ sót yêu cầu ẩn (ví dụ: bộ phận tuân thủ muốn lưu log eKYC để đối chiếu thanh tra).
Bước 3 — Viết Preconditions và Postconditions. Trước khi viết luồng, hãy chốt điểm đầu (cần gì để bắt đầu) và điểm cuối (thành công nghĩa là hệ thống ở trạng thái nào). Thêm Minimal Guarantee: kể cả thất bại thì hệ thống vẫn đảm bảo điều gì.
Bước 4 — Viết Main Success Scenario. Mỗi bước một câu, chủ ngữ rõ, luân phiên actor ↔ hệ thống, mô tả ý định nghiệp vụ. Giữ luồng chính sạch và ngắn — lý tưởng 3 đến 9 bước. Nếu dài hơn, có thể bạn đang nhồi nhiều mục tiêu vào một Use Case.
Bước 5 — Truy hết Extensions. Đi qua từng bước của luồng chính và tự hỏi: "Ở bước này, còn điều gì khác có thể xảy ra?" Lỗi nhập liệu, hết thời gian, dữ liệu trùng, mất kết nối, từ chối quyền... Mỗi nhánh đánh số (3a, 3b) và ghi rõ kết cục.
Bước 6 — Bổ sung Special Requirements. Gắn các yêu cầu phi chức năng vào đúng chỗ: thời gian phản hồi, bảo mật, giới hạn số lần thử, khả năng chịu tải.
Bước 7 — Review với dev và QA. Đọc to luồng chính cho cả nhóm nghe (kỹ thuật "playback" ở Bài 18). Dev sẽ chỉ ra nhánh kỹ thuật bạn quên; QA sẽ thấy ngay đây chính là bộ ca kiểm thử của họ. Đây là bước biến tài liệu cá nhân thành tài liệu được đồng thuận.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết Use Case ở sai cấp độ. Quá to thì thành một mớ; quá nhỏ thì vụn vặt vô nghĩa. Mẹo: dùng "phép thử cốc cà phê" của Cockburn — một Use Case nên là việc actor hoàn thành được trong một lần ngồi xuống mà không cần đứng dậy.
Lỗi 2 — Nhồi chi tiết UI vào bước. Như ví dụ 2, spec sẽ lỗi thời ngay khi đổi giao diện. Mẹo: mỗi khi định viết "nhấn nút màu...", hãy dừng lại và viết ý định thay vì thao tác.
Lỗi 3 — Extension không có kết cục. Viết "OTP sai" mà không nói tiếp gì khiến dev tự đoán. Mẹo: mọi extension phải kết thúc bằng một trong hai câu: "quay lại bước X" hoặc "Use Case kết thúc với [trạng thái]".
Lỗi 4 — Lẫn lộn luồng chính và ngoại lệ. Nhét cả "nếu lỗi thì..." vào luồng chính làm nó rối như mì. Mẹo: luồng chính chỉ chứa happy path; mọi "nếu/nhưng" đẩy hết xuống Extensions.
Lỗi 5 — Viết fully dressed cho mọi thứ. Lãng phí thời gian cho những chức năng đơn giản. Mẹo: dùng casual cho việc đơn giản, dồn công sức fully dressed vào nơi rủi ro và logic cao.
Lỗi 6 — Viết một mình rồi quẳng cho dev. Use Case là công cụ giao tiếp, không phải bài luận. Mẹo: viết nháp 70% rồi mang đi review sớm, đừng cố hoàn hảo trong phòng kín.
Bài tập thực hành
Hãy chọn chức năng "Đặt lại mật khẩu (Reset Password)" cho một ứng dụng ngân hàng số Việt Nam và viết một Use Case spec fully dressed hoàn chỉnh:
- Điền đầy đủ các trường: Name, ID, Primary Actor, Stakeholders & Interests, Preconditions, Trigger, Postconditions (Success Guarantee), Minimal Guarantee.
- Viết Main Success Scenario từ 5 đến 8 bước, mỗi bước một câu, mô tả ý định nghiệp vụ (không mô tả UI).
- Truy ít nhất 6 extensions, ví dụ: email không tồn tại trong hệ thống, OTP sai/hết hạn, tài khoản đang bị khóa, mật khẩu mới không đạt chính sách bảo mật, link reset hết hạn, người dùng đã đăng nhập sẵn.
- Thêm tối thiểu 2 Special Requirements (ví dụ: OTP hết hiệu lực sau 60 giây; ghi log mọi lần reset để phục vụ điều tra bảo mật).
Tóm tắt
Use Case specification là tài liệu narrative mô tả trọn vẹn cách một actor đạt được một mục tiêu nghiệp vụ — từ luồng chính suôn sẻ đến mọi ngả rẽ khi mọi thứ trục trặc. Khác với User Story (lời nhắc trò chuyện) và Use Case diagram (hình vẽ tổng quan), Use Case spec là nơi bạn ghi chi tiết hành vi của hệ thống dưới dạng câu chuyện dễ đọc.
Khung Cockburn cho bạn một bộ trường chuẩn: Actor, Stakeholders, Preconditions, Postconditions, Main Success Scenario, và quan trọng nhất là Extensions. Giá trị thật của BA không nằm ở luồng happy path mà ở độ phủ của các nhánh rẽ — chính đó là nơi rủi ro, gian lận và trải nghiệm tệ ẩn náu. Hãy viết ở đúng cấp độ user goal, mô tả ý định thay vì giao diện, đảm bảo mọi extension có kết cục, và luôn mang spec đi review sớm với dev và QA. Khi làm tốt, một Use Case spec không chỉ giúp dev code đúng mà còn trở thành bộ khung kiểm thử có sẵn cho QA — một tài liệu, nhiều người cùng hưởng lợi.