...

7 SAI LẦM THƯỜNG GẶP KHI VIẾT USE CASE!

Cập nhật 14:31, 23/06/2025

1353 lượt xem

Admin

👉 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é!

Lưu lại cùng True Skill Center để tìm hiểu nhé!

– – –
 
Xem thêm thông tin bổ ích miễn phí và tham gia cộng đồng True Skill tại:
 
 
Facebook: True Skill Center 
 
 
Youtube: Quý Nguyễn 

CÓ THỂ BẠN QUAN TÂM

ITBA

Làm BA trong Fintech: Bí kíp để không chỉ là người ghi yêu cầu!

Fintech đang là “đỉnh của chóp” với ví điện tử, ngân hàng số, blockchain, crypto – cơ hội cho BA tụi mình đầy rẫy ngoài kia. Nhưng làm BA trong fintech không chỉ là ngồi viết BRD hay vẽ sơ đồ đâu nha. Muốn nổi bật, bạn cần vài “vũ khí bí mật” ngoài nghiệp vụ. Hôm nay, mình chia sẻ 5 bí kíp siêu thực tế, cộng thêm cách dùng AI để học fintech nhanh như chớp và lý do vì sao dân BA mê mẩn ngành này.

ITBA

[NHẢY VIỆC] Khi Nào Là Đúng Lúc? Kinh Nghiệm Qua Từng Giai Đoạn Sự Nghiệp

Đây là một chủ đề mình từng viết cách đây 4 năm – và đến giờ vẫn thấy còn nguyên giá trị. Khác với chuyện chọn vợ/chồng, sự nghiệp là thứ ta có thể chủ động lựa chọn và thay đổi khi không còn phù hợp. Nhảy việc – dù êm đềm hay kịch tính – là một phần không thể thiếu của hành trình phát triển.

ITBA

3 TIPS ĐỂ CÓ MỘT CUỘC HỌP ONLINE HIỆU QUẢ

Làm Business Analyst (BA) không chỉ là phân tích nghiệp vụ hay viết tài liệu – mà còn là kết nối, thấu hiểu và dẫn dắt. Khi môi trường làm việc chuyển dịch sang online, bạn có đang loay hoay để giữ vững hiệu quả cộng tác?

ITBA

BA/PO/PM Xử lý khi Dev nói:"Cái này không làm được đâu?"

Anh chị em làm nghề BA/PO/PM nhà mình chắc không lạ gì câu này. :)) Có điều thì ở mỗi hoàn cảnh khác nhau, đôi khi bản thân chúng ta cũng không biết nên reply câu này như thế nào cho hợp lý. Mình chia sẻ tý trải nghiệm cá nhân nha.

Đăng kí nhận tư vấn

Hãy nhập ngay email của bạn vào form bên dưới để được nhận tư vấn trực tiếp từ trung tâm.