Là một BA, việc viết Use Case Specification không chỉ là một phần công việc mà còn là một thách thức không nhỏ. Mới vào nghề, mình đã từng gặp rất nhiều tình huống “dở khóc dở cười” khi viết Use Case, và nhận thấy rằng rất nhiều khi mọi người trong team phát triển vẫn không hiểu hết yêu cầu dù mình đã cố gắng soạn thảo tài liệu. Điều này khiến mình tự hỏi: “Liệu mình có đang viết Use Case đủ rõ ràng không? Tại sao lại có những câu hỏi mà mình tưởng như đã giải quyết trong tài liệu?”

Qua thời gian, mình nhận ra rằng một Use Case tốt không chỉ giúp các bên liên quan hiểu yêu cầu mà còn giúp việc phát triển và triển khai hệ thống trở nên dễ dàng hơn rất nhiều. Dưới đây là những sai lầm phổ biến mà mình đã gặp và mình viết cách có thể tránh để viết Use Case hiệu quả hơn.

Lỗi 1: Bao gồm chi tiết giao diện người dùng

Một trong những sai lầm mình đã mắc phải khi viết Use Case là quá chú trọng vào giao diện người dùng. 

Ví dụ, thay vì chỉ ghi đơn giản là “Người dùng tạo tài khoản mới”, mình lại viết chi tiết như “Người dùng nhấn nút tạo tài khoản”. Cứ nghĩ rằng như vậy sẽ rõ ràng hơn. Nhưng bạn có bao giờ nghĩ, nếu giao diện thay đổi (vì lý do nào đó) thì liệu bạn có phải cập nhật lại tất cả các Use Case có liên quan không?

Ví dụ minh hoạ:

Giải thích: Việc ghi rõ tên nút giao diện như “Tạo tài khoản mới” không chỉ làm tài liệu khó duy trì mà còn gây mơ hồ nếu giao diện thay đổi. Khi sử dụng cách viết chung như “Người dùng tạo tài khoản mới”, tài liệu sẽ dễ dàng hơn trong việc duy trì và có thể áp dụng cho mọi thay đổi giao diện.

Lỗi 2: Không xác định phản hồi của hệ thống đối với hành động của người dùng

Một Use Case rõ ràng không chỉ mô tả hành động của người dùng mà còn cần phải chỉ ra phản hồi của hệ thống. 

Mình nhớ có một lần khi viết Use Case cho tính năng đăng nhập, mình đã bỏ qua việc hệ thống cần làm gì khi người dùng nhập sai mật khẩu. Khi đó, team phát triển đã hỏi lại: “Khi người dùng nhập sai, hệ thống sẽ làm gì?” Điều này nhắc nhở mình rằng mỗi bước hành động của người dùng trong Use Case cần có phản hồi rõ ràng từ hệ thống.

Ví dụ minh hoạ:

Giải thích: Mỗi hành động của người dùng cần có phản hồi từ hệ thống. Nếu không mô tả rõ ràng phản hồi này, đội ngũ phát triển sẽ không biết phải xử lý các tình huống như thế nào, dẫn đến việc thiếu sót hoặc hiểu nhầm yêu cầu.

Lỗi 3: Bao gồm chi tiết kỹ thuật không cần thiết

Khi mới làm BA, mình nghĩ rằng việc đưa vào chi tiết kỹ thuật như tên bảng dữ liệu, quy trình hệ thống hay các thành phần mà người dùng không nhìn thấy sẽ giúp tài liệu dễ hiểu hơn. Nhưng thực tế, đó là một sai lầm. Những chi tiết này chỉ thực sự hữu ích với team kỹ thuật, còn với các bên liên quan không phải kỹ thuật, nó chỉ làm tài liệu trở nên khó hiểu.

Ví dụ minh hoạ:

Giải thích: Việc đưa vào chi tiết như cấu trúc cơ sở dữ liệu trong Use Case không chỉ làm tài liệu rối rắm mà còn không cần thiết đối với những người không làm việc với kỹ thuật. Hãy để những chi tiết này trong tài liệu thiết kế kỹ thuật hoặc tài liệu phụ như từ điển dữ liệu.

Lỗi 4: Không nhất quán với Wireframes

Khi viết Use Case, nhiều khi mình bị quên kiểm tra sự đồng bộ với Wireframes. Mình viết Use Case cho tính năng nhưng lại không đối chiếu với giao diện đã được thiết kế. Điều này khiến cho trong thực tế, khi team phát triển bắt tay vào làm, họ không thể hiểu được yêu cầu chính xác từ tài liệu của mình.

Ví dụ minh hoạ:

Giải thích: Use Case và Wireframes phải luôn đi đôi với nhau. Nếu trong Wireframe không có nút ‘Đăng nhập’ nhưng trong Use Case lại có, điều này sẽ gây ra sự hiểu nhầm và nhầm lẫn trong việc phát triển tính năng.

Lỗi 5: Không rõ ràng các luồng thay thế và ngoại lệ

Mình đã từng bỏ qua các luồng thay thế và ngoại lệ trong Use Case, và kết quả là team phát triển không biết phải xử lý những tình huống ngoài luồng chính như thế nào. 

Ví dụ, khi mô tả tính năng đăng nhập, mình đã không chỉ rõ khi nào tính năng “Ghi nhớ mình” sẽ được kích hoạt và ảnh hưởng như thế nào đến luồng chính. Điều này gây ra sự khó hiểu và làm tăng khả năng bỏ sót bước quan trọng trong quá trình phát triển.

Ví dụ minh hoạ:

Giải thích: Việc mô tả rõ ràng các luồng thay thế và ngoại lệ giúp tránh nhầm lẫn khi người dùng không đi theo “happy path” và giúp team phát triển xử lý tình huống một cách chính xác.

Lỗi 6: Bao gồm các bước ngoài phạm vi

Mình từng viết một Use Case mà trong đó bao gồm quá nhiều bước không liên quan đến mục tiêu của người dùng. Khi đó, tài liệu của mình trở nên rất dài dòng và không rõ ràng. Điều này không chỉ gây khó khăn cho việc đọc hiểu mà còn có thể dẫn đến việc bỏ sót các bước quan trọng.

Ví dụ minh hoạ:

Giải thích: Một Use Case nên tập trung vào một mục tiêu duy nhất. Các bước ngoài phạm vi (ví dụ, thanh toán) nên được tách ra thành một Use Case riêng biệt, giúp tài liệu rõ ràng hơn và dễ hiểu hơn.

Lỗi 7: Sử dụng thuật ngữ không nhất quán

Mình từng gặp phải tình huống trong đó thuật ngữ trong Use Case bị sử dụng không nhất quán. 

Ví dụ, trong một Use Case về đăng bài viết, có lúc dùng từ “bài viết”, lúc lại dùng “bài blog” mà không giải thích rõ ràng hai khái niệm này có giống nhau hay không. Điều này gây ra sự nhầm lẫn cho team phát triển và các bên liên quan.

Ví dụ minh hoạ:

Giải thích: Việc sử dụng thuật ngữ không nhất quán sẽ gây ra sự hiểu lầm về các khái niệm trong Use Case. Hãy đảm bảo rằng bạn định nghĩa rõ các thuật ngữ và sử dụng chúng nhất quán trong suốt tài liệu.

Kết luận

Việc viết Use Case Specification là một phần không thể thiếu trong công việc của một BA. Tuy nhiên, để viết được một Use Case tốt, bạn cần phải tránh những sai lầm phổ biến mà nhiều người dễ mắc phải. Hãy nhớ rằng một Use Case rõ ràng, chi tiết và dễ hiểu sẽ giúp bạn và đội ngũ phát triển làm việc hiệu quả hơn, tránh những sai sót không đáng có.

Dù ban đầu có thể gặp khó khăn, nhưng qua từng lần thực hành và học hỏi từ những sai lầm, bạn sẽ trở nên thành thạo và tự tin hơn trong việc viết Use Case. 

Nhận ngay ebook “6 kiến thức – 4 công cụ” được tổng hợp từ mình và đừng ngần ngại book ngay lịch tư vấn 1-1 miễn phí với team mentor chuyên nghiệp nhé.