Mở đầu — vì sao bài này quan trọng
Hãy hình dung bạn vừa chuyển từ phòng kế toán sang vị trí BA, và sếp giao cho bạn nhiệm vụ mô tả một tính năng: "Hệ thống cần cho phép duyệt giải ngân khoản vay." Nếu bạn viết lại đúng câu đó vào tài liệu, lập trình viên sẽ hỏi bạn mười câu liên tiếp: Ai được duyệt? Duyệt theo bước nào? Nếu hồ sơ thiếu giấy tờ thì sao? Số tiền trên hạn mức ai được duyệt? Khi từ chối thì hệ thống làm gì? Và bạn sẽ nhận ra rằng một câu mô tả đẹp đẽ trên giấy không hề "chạy" được khi đưa vào tay đội phát triển.
Đây chính là lý do bài này quan trọng đến vậy. Use case theo phong cách Alistair Cockburn và Acceptance Criteria viết bằng Gherkin là hai công cụ giúp bạn biến một ý tưởng mơ hồ thành một kịch bản rõ ràng, có thể kiểm thử được, và quan trọng nhất — không thể hiểu sai. Với người xuất thân từ Finance/Kế toán, đây là tin vui lớn: tư duy của bạn vốn đã quen với việc mô tả quy trình theo từng bút toán, từng bước hạch toán, từng điều kiện duyệt chứng từ. Use case và Gherkin chẳng qua là cách "đóng gói" lại đúng thứ tư duy quy trình đó theo ngôn ngữ mà đội IT hiểu và tin tưởng được.
Trong bài này, chúng ta sẽ đi sâu vào hai thứ: (1) cách viết một use case hoàn chỉnh theo template Cockburn — với actor, tiền điều kiện, luồng chính và các luồng rẽ nhánh; và (2) cách viết Acceptance Criteria bằng cú pháp Given-When-Then của Gherkin để mỗi yêu cầu đều có thể đem ra nghiệm thu. Sau bài này, bạn sẽ không còn viết "hệ thống cần duyệt khoản vay" một cách chung chung nữa, mà sẽ viết được một kịch bản đủ chi tiết để dev code và tester kiểm thử ngay.
Khái niệm cốt lõi
Use case là gì và tại sao Cockburn lại quan trọng
Use case là một mô tả về cách một actor (người dùng 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ụ thể. Điểm mấu chốt: use case luôn xoay quanh một mục tiêu của actor, chứ không phải mô tả tính năng kỹ thuật. "Duyệt giải ngân khoản vay" là một mục tiêu; "gọi API kiểm tra hạn mức" thì không — đó chỉ là một bước kỹ thuật bên trong.
Alistair Cockburn — tác giả cuốn Writing Effective Use Cases và là một trong những người ký tên vào Tuyên ngôn Agile — đã chuẩn hóa một template viết use case mà đến nay vẫn là chuẩn vàng trong ngành. Điểm hay của template Cockburn là nó buộc bạn phải nghĩ đến cả những trường hợp "xấu": khi hồ sơ thiếu, khi hệ thống lỗi, khi người duyệt vượt quyền. Với người Finance, đây chính là tư duy "đối chiếu công nợ" và "kiểm soát nội bộ" được hệ thống hóa.
Các thành phần của một use case Cockburn
Một use case đầy đủ (định dạng "fully dressed" theo cách Cockburn gọi) gồm các phần sau:
- Use Case (Tên): Đặt theo động từ + danh từ, thể hiện mục tiêu. Ví dụ: "Duyệt giải ngân khoản vay".
- Primary Actor (Actor chính): Người khởi xướng và muốn đạt mục tiêu. Ví dụ: Cán bộ tín dụng (Loan officer).
- Stakeholders & Interests (Các bên liên quan và lợi ích): Ai quan tâm tới use case này và họ cần gì. Người vay muốn được giải ngân nhanh; bộ phận Compliance muốn đảm bảo tuân thủ; Treasury muốn kiểm soát dòng tiền.
- Preconditions (Tiền điều kiện): Điều gì phải đúng trước khi use case bắt đầu. Ví dụ: hồ sơ vay đã được phê duyệt tín dụng ở bước trước, khách hàng đã ký hợp đồng.
- Postconditions / Success Guarantee (Hậu điều kiện): Trạng thái hệ thống sau khi use case thành công. Ví dụ: khoản tiền đã được ghi nhận chờ giải ngân, bút toán đã được tạo, thông báo đã gửi cho khách hàng.
- Main Success Scenario (Luồng chính thành công): Chuỗi các bước được đánh số khi mọi thứ diễn ra suôn sẻ.
- Extensions / Alternative Flows (Luồng mở rộng / rẽ nhánh): Cái gì xảy ra khi có ngoại lệ tại từng bước. Đây là phần "vàng" mà người mới thường bỏ qua.
- Trigger (Sự kiện kích hoạt): Điều gì bắt đầu use case. Ví dụ: cán bộ tín dụng nhấn nút "Yêu cầu giải ngân".
Gherkin và Acceptance Criteria
Use case mô tả toàn bộ hành trình; còn Acceptance Criteria (AC — tiêu chí nghiệm thu) xác định điều kiện cụ thể để biết một yêu cầu đã được hoàn thành đúng. Gherkin là một ngôn ngữ viết AC theo cấu trúc ba phần:
- Given (Cho trước): Bối cảnh/tiền điều kiện. Trạng thái hệ thống trước khi hành động.
- When (Khi): Hành động hoặc sự kiện xảy ra.
- Then (Thì): Kết quả mong đợi, có thể quan sát và kiểm chứng được.
Scenario: Duyệt giải ngân trong hạn mức
Given hồ sơ vay đã được phê duyệt tín dụng
And số tiền giải ngân là 200 triệu VND
And hạn mức duyệt của cán bộ tín dụng là 500 triệu VND
When cán bộ tín dụng nhấn "Duyệt giải ngân"
Then hệ thống tạo lệnh giải ngân với trạng thái "Chờ Treasury xử lý"
And hệ thống ghi log người duyệt và thời điểm duyệt
Vẻ đẹp của Gherkin là nó vừa đọc được như tiếng người (Business đọc hiểu), vừa có cấu trúc đủ chặt để tester biến thành test case, thậm chí dev có thể tự động hóa bằng công cụ như Cucumber. Mối quan hệ giữa hai công cụ: use case cho bạn bức tranh toàn cảnh và các luồng; mỗi bước hoặc mỗi luồng rẽ nhánh trong use case thường sinh ra một hoặc vài scenario Gherkin để nghiệm thu.
Tình huống thực tế
Ví dụ 1: Duyệt giải ngân tại một công ty cho vay tiêu dùng (FE Credit / Home Credit phong cách)
Bối cảnh: Một công ty tài chính tiêu dùng tại Việt Nam (giả định theo mô hình FE Credit) đang số hóa quy trình giải ngân. Trước đây cán bộ tín dụng duyệt thủ công trên Excel và email. Linh — một kế toán công nợ vừa chuyển sang làm BA — được giao viết use case cho tính năng giải ngân.
Linh viết use case như sau:
Use Case: Duyệt giải ngân khoản vay
Primary Actor: Cán bộ tín dụng
Stakeholders: Khách hàng vay (muốn nhận tiền nhanh),
Compliance (đảm bảo tuân thủ KYC/AML),
Treasury (kiểm soát dòng tiền ra)
Preconditions: Hồ sơ đã qua thẩm định tín dụng; hợp đồng đã ký số
Trigger: Cán bộ tín dụng nhấn "Yêu cầu giải ngân"
Main Success Scenario:
1. Cán bộ tín dụng mở hồ sơ ở trạng thái "Đã thẩm định"
2. Hệ thống hiển thị số tiền, tài khoản nhận, hạn mức duyệt
3. Cán bộ tín dụng xác nhận thông tin và nhấn "Duyệt"
4. Hệ thống kiểm tra số tiền nằm trong hạn mức của cán bộ
5. Hệ thống tạo lệnh giải ngân, chuyển trạng thái "Chờ Treasury"
6. Hệ thống ghi log và gửi thông báo cho Treasury
Extensions:
4a. Số tiền vượt hạn mức cán bộ:
4a1. Hệ thống chuyển hồ sơ lên trưởng phòng phê duyệt
4b. Tài khoản nhận chưa qua xác thực KYC:
4b1. Hệ thống chặn duyệt, hiển thị cảnh báo Compliance
Diễn giải: Phần khiến use case này có giá trị không phải luồng chính (bước 1-6), mà là phần Extensions. Chính vì Linh từng làm kế toán công nợ, cô lập tức nghĩ tới chuyện "vượt hạn mức ai duyệt" và "tài khoản chưa xác thực" — đúng kiểu kiểm soát nội bộ. Đội dev sau đó nói với Linh rằng đây là tài liệu hiếm hoi họ không phải hỏi lại quá nhiều.
Bài học rút ra: Tư duy kiểm soát của Finance là tài sản trực tiếp để viết phần Extensions — phần phân biệt một BA giỏi với một người chỉ chép lại yêu cầu.
Ví dụ 2: Đối soát giao dịch ví điện tử (MoMo / ZaloPay phong cách)
Bối cảnh: Một ví điện tử cần tính năng đối soát giao dịch hằng ngày với ngân hàng đối tác. Hùng — cựu kế toán tổng hợp — được giao viết AC cho tính năng "Đối soát tự động cuối ngày". Anh quen với việc đối chiếu sao kê ngân hàng nên hiểu rất rõ các trường hợp lệch.
Hùng viết AC bằng Gherkin:
Scenario: Đối soát khớp hoàn toàn
Given có 10.000 giao dịch ngày 26/06 ở phía ví
And ngân hàng gửi file sao kê 10.000 giao dịch
When hệ thống chạy đối soát lúc 23:00
Then tất cả giao dịch ở trạng thái "Khớp"
And báo cáo đối soát hiển thị "0 lệch"Scenario: Giao dịch có ở ví nhưng không có ở ngân hàng
Given giao dịch X có ở ví với số tiền 500.000 VND
And giao dịch X không xuất hiện trong sao kê ngân hàng
When hệ thống chạy đối soát
Then giao dịch X được đánh dấu "Treo - chờ ngân hàng"
And hệ thống tạo cảnh báo cho đội vận hành
Scenario: Lệch số tiền giữa hai bên
Given giao dịch Y ở ví ghi 1.000.000 VND
And giao dịch Y ở sao kê ngân hàng ghi 999.000 VND
When hệ thống chạy đối soát
Then giao dịch Y được đánh dấu "Lệch số tiền"
And chênh lệch 1.000 VND được ghi vào danh sách cần xử lý
Diễn giải: Mỗi tình huống lệch mà Hùng từng gặp khi làm kế toán — lệch thời gian, lệch số tiền, giao dịch treo — đều trở thành một scenario riêng. Đội QA của ví dùng chính ba scenario này làm test case tự động. Khi go-live, tính năng bắt đúng các trường hợp lệch ngay từ ngày đầu.
Bài học rút ra: Mỗi "ngoại lệ" trong nghiệp vụ Finance là một scenario Gherkin tiềm năng. Đừng chỉ viết "happy path" (luồng đẹp) — sức mạnh nằm ở việc liệt kê các luồng lỗi mà bạn vốn đã thuộc lòng.
Ví dụ 3: Lỗi viết AC quá mơ hồ tại một startup B2B SaaS
Bối cảnh: Tại một startup phần mềm kế toán B2B ở TP.HCM, một BA mới viết AC: "Khi người dùng xuất báo cáo, hệ thống phải xuất nhanh và đúng." Dev hỏi: "Nhanh là bao nhiêu giây? Đúng là so với cái gì?" AC không trả lời được, dẫn tới ba vòng làm lại.
Sau khi được mentor hướng dẫn, BA viết lại:
Scenario: Xuất báo cáo công nợ dưới 5.000 dòng
Given người dùng có quyền xem báo cáo công nợ
And dữ liệu công nợ có 4.500 dòng
When người dùng nhấn "Xuất Excel"
Then file Excel được tải về trong vòng 10 giây
And tổng công nợ trong file khớp với tổng hiển thị trên màn hình
Diễn giải: "Nhanh" trở thành "dưới 10 giây", "đúng" trở thành "khớp tổng với màn hình". Mỗi từ định tính được thay bằng một điều kiện kiểm chứng được.
Bài học rút ra: Một AC tốt phải testable — nếu tester không biết cách kiểm tra Then có đúng không, thì AC đó chưa xong.
Hướng dẫn từng bước
Bước 1 — Xác định mục tiêu và actor chính. Hỏi: "Ai muốn làm gì, để đạt điều gì?" Đặt tên use case theo động từ + danh từ. Tránh tên kỹ thuật như "Xử lý API giải ngân".
Bước 2 — Liệt kê stakeholders và lợi ích của họ. Với mỗi bên (Compliance, Treasury, khách hàng…), viết một câu họ quan tâm gì. Đây là cách bạn không bỏ sót yêu cầu phi chức năng (bảo mật, tuân thủ).
Bước 3 — Viết preconditions và postconditions. Tiền điều kiện = trạng thái phải đúng trước khi bắt đầu. Hậu điều kiện = trạng thái sau khi thành công. Với người Finance, hãy nghĩ tới "đầu kỳ" và "cuối kỳ" của một bút toán.
Bước 4 — Viết Main Success Scenario. Đánh số từng bước, mỗi bước một câu, xen kẽ "actor làm gì" và "hệ thống phản hồi gì". Giữ ở mức 3-9 bước; nếu dài hơn, có thể bạn đang gộp nhiều use case.
Bước 5 — Thêm Extensions cho từng bước. Quay lại từng bước và hỏi "Cái gì có thể sai ở đây?" Đánh số theo bước cha (ví dụ 4a, 4b). Đây là lúc tư duy kiểm soát Finance phát huy sức mạnh.
Bước 6 — Chuyển các bước và nhánh thành AC Gherkin. Mỗi luồng (chính và rẽ nhánh) thường thành một Scenario. Viết Given (bối cảnh), When (một hành động), Then (kết quả quan sát được). Giữ mỗi scenario chỉ có một When chính.
Bước 7 — Kiểm tra tính testable. Đọc lại từng Then và tự hỏi: "Tester sẽ kiểm tra điều này bằng cách nào?" Nếu không trả lời được bằng một con số hoặc một trạng thái cụ thể, hãy viết lại.
Bước 8 — Rà soát với dev và tester. Đưa use case + AC cho đội phát triển trước khi sprint bắt đầu. Một AC tốt là AC mà cả ba bên (BA, dev, QA) đều gật đầu cùng hiểu giống nhau.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ viết happy path. Người mới thường tả luồng đẹp rồi dừng. Mẹo: với mỗi bước trong luồng chính, ép mình viết ít nhất một Extension. Nếu một bước "không thể sai", hãy ghi rõ lý do.
Lỗi 2 — Nhồi quá nhiều When vào một scenario. Khi bạn viết "When người dùng nhấn A và sau đó nhấn B và rồi nhập C", scenario trở nên khó test và khó debug. Mẹo: một scenario — một When chính. Tách thành nhiều scenario nếu cần.
Lỗi 3 — Then không quan sát được. "Then hệ thống xử lý đúng" là vô nghĩa. Then phải là trạng thái, con số, thông báo, hoặc bản ghi cụ thể mà ai cũng nhìn thấy được.
Lỗi 4 — Lẫn lộn use case với UI. Use case mô tả mục tiêu và hành vi, không phải vị trí nút bấm hay màu sắc. Đừng viết "người dùng nhấn nút xanh ở góc phải" — hãy viết "người dùng xác nhận duyệt".
Lỗi 5 — Viết Given chứa hành động. Given là trạng thái có sẵn, không phải hành động. "Given người dùng đã đăng nhập" thì đúng; "Given người dùng đăng nhập" (đang thực hiện) thì sai về mặt ngữ nghĩa.
Mẹo riêng cho ex-Finance: Khi bí ý cho phần Extensions, hãy tự hỏi đúng những câu kiểm soát nội bộ bạn vốn quen: "Ai được duyệt mức này? Vượt hạn mức thì sao? Thiếu chứng từ thì sao? Có dấu vết audit không? Đối soát ra sao?" Mỗi câu thường là một nhánh.
Bài tập thực hành
Bài 1 — Viết use case fully dressed. Chọn nghiệp vụ "Hoàn tiền cho khách hàng" (refund) của một sàn thương mại điện tử như Shopee. Viết đầy đủ: tên, actor chính, stakeholders, preconditions, postconditions, trigger, main success scenario (tối thiểu 5 bước), và ít nhất 3 extensions. Gợi ý extensions: đơn đã quá hạn hoàn, số tiền hoàn vượt giá trị đơn, khách yêu cầu hoàn nhưng hàng chưa trả.
Bài 2 — Viết 4 scenario Gherkin. Cho tính năng "Tính lãi tiết kiệm cuối kỳ" của một ngân hàng số. Viết 4 scenario: (1) sổ tất toán đúng hạn, (2) sổ rút trước hạn (lãi không kỳ hạn), (3) số dư dưới mức tối thiểu, (4) ngày đáo hạn rơi vào ngày lễ. Mỗi scenario phải có Given-When-Then và ít nhất một Then có con số cụ thể.
Bài 3 — Sửa AC kém. Viết lại AC sau cho testable: "Khi nhân viên duyệt chi, hệ thống phải kiểm tra ngân sách và xử lý phù hợp." Tách thành ít nhất 2 scenario (trong ngân sách / vượt ngân sách) với điều kiện kiểm chứng được.
Sau khi làm xong, hãy đưa cho một người bạn (lý tưởng là một dev hoặc tester) đọc và hỏi: "Bạn có hiểu giống mình không?" Nếu họ hiểu khác đi ở bất kỳ điểm nào, đó chính là chỗ AC của bạn còn mơ hồ.
Tóm tắt
Use case theo template Cockburn và Acceptance Criteria viết bằng Gherkin là hai công cụ nền tảng giúp bạn biến yêu cầu mơ hồ thành kịch bản rõ ràng, kiểm thử được. Use case cho bạn bức tranh toàn cảnh với actor, tiền/hậu điều kiện, luồng chính và đặc biệt là các luồng rẽ nhánh (Extensions) — nơi tư duy kiểm soát nội bộ của người Finance tỏa sáng. Gherkin với cấu trúc Given-When-Then biến mỗi luồng thành một scenario nghiệm thu mà cả BA, dev và QA đều hiểu giống nhau.
Ba điều cần nhớ: (1) đừng chỉ viết happy path — sức mạnh nằm ở các ngoại lệ mà bạn vốn thuộc lòng từ nghề cũ; (2) mỗi Then phải quan sát và kiểm chứng được bằng con số hoặc trạng thái cụ thể; (3) một scenario chỉ nên có một When chính. Nền tảng Finance không phải gánh nặng phải gỡ bỏ — nó chính là lợi thế giúp bạn viết được những use case và AC chặt chẽ hơn nhiều BA "thuần IT". Hãy luyện viết hai công cụ này trên chính những nghiệp vụ tài chính bạn đã quen, và bạn sẽ thấy mình chuyển đổi nhanh hơn tưởng tượng.