Bạn có thường xuyên nhận được hàng loạt câu hỏi từ đội ngũ developer về cách hệ thống thực sự hoạt động, mặc dù bạn đã ghi lại chức năng trong một use case? Tệ hơn nữa, đội ngũ phát triển của bạn đã triển khai một thứ hoàn toàn khác với kỳ vọng của bạn và các business stakeholder? Hay đội ngũ tester (những người đáng quý) liên tục quay lại với câu hỏi về việc cần test những gì?

 Use case là một công cụ quan trọng để ghi lại functional requirement trong bối cảnh hành động của người dùng. Kết hợp với wireframe – người bạn đồng hành siêu mạnh mẽ, chúng có thể giúp mọi người thống nhất về software requirement. Nhưng những sai lầm phổ biến khi viết use case có thể khiến chúng khó hiểu và tạo ra nhiều sự mơ hồ hơn về yêu cầu. Cùng True Skill Center điểm qua 7 sai lầm thường gặp khi viết use case qua bài viết bên dưới nhé!

 1. NHỒI CHI TIẾT GIAO DIỆN VÀO USE CASE
Lỗi hay gặp nhất là mô tả hành vi người dùng bằng ngôn ngữ của giao diện.
Ví dụ, thay vì viết “Actor X tạo một tài khoản mới”, use case lại viết “Actor X nhấp vào nút tạo tài khoản mới (hoặc tab, hoặc bất kỳ thứ gì).”
Việc sử dụng chi tiết UI dẫn đến sự mơ hồ. Điều này nghe có vẻ ngược đời vì “nhấp vào nút tạo tài khoản mới” dường như cụ thể hơn “tạo một tài khoản.” Tuy nhiên, đôi khi tên của UI element không mô tả rõ ràng hành động mà người dùng thực hiện, gây nhầm lẫn về bước thực sự cần thiết. Hơn nữa, nếu bạn thay đổi tên nút hoặc tab, bạn sẽ phải cập nhật rất nhiều trong use case

 2. KHÔNG GHI RÕ SYSTEM REPONSE CHO HÀNH ĐỘNG CỦA USER
Sai lầm tiếp theo, đặc biệt ở những người chưa quen với các dự án công nghệ, là use case tập trung quá nhiều vào business process. Use case mô tả rõ ràng các bước người dùng cần thực hiện, nhưng lại thiếu hành động tương ứng của hệ thống cho mỗi bước đó.
Trong một use case, hầu như mọi bước của người dùng đều cần có system response hoặc hành động tương ứng. Nếu không, đội ngũ developer sẽ không rõ hệ thống cần làm gì, dẫn đến giả định sai lệch hoặc hàng loạt câu hỏi trong quá trình triển khai

 3. NHÉT TECHNICAL DETAILS VÀO USE CASE
Một lỗi từ các bạn có thế mạnh về Technical sẽ là viết use case bao gồm các chi tiết kỹ thuật không cần thiết để hiểu cách người dùng tương tác với hệ thống
Ví dụ:
- Các data element hoặc data table cụ thể.
- Tên của system component không hiển thị với người dùng cuối.
- Các quy trình hoặc thủ tục kích hoạt bởi hệ thống.
Việc này có thể giúp dev dễ hiểu, nhưng làm rối use case, khiến stakeholders và tester khó nắm bắt. Những chi tiết này nên để riêng trong tài liệu technical design.

 4. USE CASE VÀ WIREFRAME KHÔNG ĐỒNG BỘ
Dù use case có thể đứng độc lập, chúng thường được tạo cùng với wireframe để minh họa luồng hoặc một luồng khả thi qua các màn hình nhằm hiện thực hóa use case. Tuy nhiên, use case và wireframe thường không đồng bộ. Ví dụ, có thể có một chuỗi bước trong use case không được thể hiện trong wireframe, hoặc wireframe thiếu các nút và trigger cần thiết để thực hiện đầy đủ chức năng.
Sự không nhất quán này gây nhầm lẫn vì không rõ deliverable nào là nguồn yêu cầu chính xác. (Và khi thiếu rõ ràng, developer thường chọn wireframe vì chúng dễ hiểu hơn.)

 5. KHÔNG RÕ ĐIỂM BẮT ĐẦU/KẾT THÚC CỦA ALTERNATE FLOW VÀ EXCEPTION FLOW
Một ưu điểm lớn của use case là phân biệt được “happy path” (flow chuẩn) và các trường hợp alternate hay exception. Nhưng nhiều bạn quên chỉ rõ alternate/exception bắt đầu từ bước nào, kết thúc tại đâu. Điều này khiến tester dễ sót case và dev dễ làm sai.

 6. NHỒI BƯỚC NGOÀI SCOPE VÀO USE CASE
Use case nên tập trung vào một mục tiêu cụ thể của người dùng, như tạo tài khoản, gửi email, hoặc tạo báo cáo. Sai lầm phổ biến là bao gồm các bước xảy ra trước pre-condition, sau post-condition, hoặc không liên quan đến mục tiêu của người dùng. Đây là dấu hiệu cho thấy use case cần được chia thành nhiều use case riêng biệt.
Sai lầm này dẫn đến việc bỏ sót yêu cầu vì càng cố gắng bao quát trong một use case, bạn càng dễ bỏ qua các bước và luồng thay thế.

 7. SỬ DỤNG THUẬT NGỮ KHÔNG NHẤT QUÁN
Sai lầm cuối cùng là sử dụng thuật ngữ không nhất quán. Ví dụ, nếu use case mô tả luồng xử lý một loại thông tin, như tạo bài viết mới cho website, mà bước 1 gọi là “blog post”, bước 3 là “article”, và bước 5 là “published content item”, sẽ không rõ liệu đây là cùng một khái niệm hay các khái niệm khác nhau.

Với những người không quen thuật ngữ doanh nghiệp, technical stakeholder có thể hiểu nhầm rằng đây là ba khái niệm khác nhau, dẫn đến câu hỏi về cách chúng liên kết. Đầu tư vào việc tạo glossary để làm rõ thuật ngữ và định nghĩa có thể tiết kiệm rất nhiều thời gian và tránh nhầm lẫn.

 KẾT LUẬN:
Viết use case nghe đơn giản nhưng thực tế lại rất dễ mắc lỗi. Đừng lo — qua thực hành và chỉnh sửa, ai cũng có thể làm tốt! Nếu bạn muốn học cách viết use case chuẩn chỉnh, hãy tham khảo khoá học Business Analysis tại True Skill Center nhé!