Mar 11, 2024

7 lỗi thường gặp khi viết Use Case

Bạn có gặp trường hợp những nhà phát triển sản phẩm (developers) có hết câu hỏi này đến câu hỏi khác về việc hệ thống muốn vận hành như thế nào, kể cả khi bạn đã soạn các chức năng trong use case? Tệ nhỉ, nhưng nhóm phát triển sản phẩm (development team) đã hoàn thành một sản phẩm khác với bạn và những bên liên quan đã kỳ vọng? Hoặc các chuyên viên kiểm thử (testers) quay lại hỏi bạn liên tiếp những câu hỏi về việc cần kiểm thử cái gì?

Người viết Use Case thường mắc nhiều lỗi làm Use Case thiếu hiệu quả, chính xác

"Use cases" là một công cụ yêu cầu có giá trị để ghi lại yêu cầu chức năng trong ngữ cảnh của các hành động của người dùng. Cùng với "wireframes," đồng minh siêu mạnh của chúng, chúng có thể là một công cụ để cuối cùng đưa mọi người vào cùng một trang về yêu cầu phần mềm.

Nhưng một số sai lầm phổ biến khi tạo "use cases" làm cho chúng khó hiểu, và thực tế có thể tạo ra nhiều sự mơ hồ về yêu cầu. Bạn có thể tránh được nhiều nỗi đau và khổ cực cho mọi người trong nhóm của bạn bằng cách đảm bảo bạn không mắc một số sai lầm phổ biến nhất trong "use cases" dẫn đến sự mơ hồ.

Cần rõ ràng, đúng trọng tâm khi viết Use Case

Phần tốt nhất là khi bạn học cách phân tích yêu cầu trong các "use cases," bạn có thể trở nên như người thông minh nhất trong phòng bằng cách tránh những thách thức phổ biến sau:

Xác nhận rằng "use case" phản ánh đúng nhu cầu thực sự của người dùng cuối.
Mô tả các bước hệ thống và người dùng ở mức độ chi tiết phù hợp.
Đảm bảo yêu cầu phần mềm của bạn rõ ràng và hoàn chỉnh.

Lỗi viết "Use Case" #1 – Bao gồm Chi Tiết Giao Diện Người Dùng:

Rõ ràng lỗi phổ biến nhất mà chúng tôi thường thấy trong các "use case" là họ sử dụng ngôn ngữ của giao diện người dùng để nói về hành vi của người dùng. Ví dụ, thay vì "Người tham gia X tạo tài khoản mới" thì họ viết là "Người tham gia X nhấn nút tạo tài khoản mới (hoặc tab, hoặc bất cứ thứ gì)."

Tránh đề cập quá chi tiết giao diện để không mắc trường hợp cập nhật hàng loạt

Sử dụng chi tiết giao diện người dùng dẫn đến sự mơ hồ. Điều này ngược với logic vì "nhấn nút tạo tài khoản mới" có vẻ rõ ràng hơn so với "tạo tài khoản." Tuy nhiên, đôi khi tên của phần tử giao diện người dùng không mô tả rõ hành động mà người dùng đang thực hiện và do đó tạo ra sự mơ hồ về bước thực sự mà chúng ta cần từ người dùng để hệ thống thành công. (Hơn nữa, nếu bạn thay đổi tên của nút hoặc tab, bạn có thể cần phải cập nhật rất nhiều "use case." Nói về một cơn ác mộng về bảo trì!)

Nhưng, chúng ta đã nói đủ về lỗi này. Hãy đi vào các lỗi khác, vì chúng có thể nhiều lắm!

Lỗi Viết "Use Case" #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:

Lỗi phổ biến tiếp theo mà chúng tôi thường thấy, đặc biệt là từ những người không có nhiều kinh nghiệm trong các dự án công nghệ thông tin, là "use cases" rất tập trung vào quy trình nghiệp vụ. "Use case" rõ ràng về tất cả các bước mà người dùng cần thực hiện, nhưng thiếu hành động của hệ thống tương ứng cần xảy ra phản hồi với mỗi bước của người dùng.

Trong một "use case," gần như mỗi bước của người dùng nên có một hành động hoặc phản hồi tương ứng từ hệ thống. Nếu không có, nhóm phát triển của bạn không rõ về hệ thống cần phải làm gì để giữ vững phần của mình. Điều này dẫn đến việc đưa ra giả định hoặc đặt câu hỏi trong quá trình triển khai.

Lỗi Viết "Use Case" #3 – Bao Gồm Chi Tiết Kỹ Thuật:

Một lỗi phổ biến khác, và lỗi này thường đến từ các chuyên gia tập trung vào kỹ thuật hơn, là "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.

Các ví dụ phổ biến về các chi tiết kỹ thuật bao gồm:

Các yếu tố dữ liệu cụ thể hoặc các bảng dữ liệu.
Tên của các thành phần hệ thống mà người dùng cuối thông thường không thấy được trên hệ thống.
Các quy trình hoặc thủ tục được kích hoạt bởi hệ thống cần chạy.

Bao gồm quá nhiều chi tiết kỹ thuật có thể làm rõ điều gì đó đối với nhóm kỹ thuật, nhưng làm gián đoạn luồng của "use case" và làm cho nó khó hiểu đối với các bên liên quan nghiệp vụ của bạn và những người kiểm thử của bạn. Những chi tiết này tốt nhất nên được lưu lại cho một tài liệu thiết kế kỹ thuật.

Khi đến với các yếu tố dữ liệu, một phương pháp tốt nhất là sử dụng từ điển dữ liệu (data dictionary) hoặc bản đồ dữ liệu (data map) để phân tích các yêu cầu dữ liệu (data requirements).

Lỗi Viết "Use Case" #4 – Không Nhất Quán với Wireframes:

Use Case phải nhất quán với Wireframes

Mặc dù "use case" có thể tồn tại độc lập như một tài liệu yêu cầu, thường thì chúng được tạo ra cùng với các "wireframes" để hiển thị hoặc một luồng hoặc một trong số các luồng có thể thông qua một loạt các màn hình để thực hiện "use case."

Thường xuyên xảy ra lỗi khi "use case" và "wireframes" không đồng bộ. Ví dụ, có thể có một chuỗi bước không được đại diện trong "wireframe" hoặc "wireframe" có thể thiếu các nút và kích hoạt cần thiết để hoàn toàn thực hiện chức năng trong "use case."

Sự không nhất quán trong các bản giao hàng cuối cùng tạo ra sự nhầm lẫn vì không rõ bản giao hàng nào nên là nguồn yêu cầu đích thực. (Và khi không rõ ràng, các nhà phát triển thường chọn các hình ảnh vì chúng dễ tiêu thụ hơn.)

Lỗi Viết "Use Case" #5 – Không Rõ Ràng Vị Trí Các Luồng Thay Thế (Alternative Flow) và Ngoại Lệ (Exception Flow) Tách Ra từ Luồng Chính:

Một trong những yếu tố hữu ích của "use case" là chúng cho phép bạn tập trung vào luồng cơ bản hoặc "happy path" độc lập với tất cả các biến thể có thể xảy ra trên con đường đó. Các biến thể này được gọi là các luồng thay thế và ngoại lệ.

Dưới đây là một ví dụ cho chức năng "Ghi nhớ tôi" trong một "use case" đăng nhập:

2a – Ghi Nhớ Tôi:

Hệ thống phát hiện rằng máy tính của người dùng đã lưu tên người dùng và mật khẩu.
Hệ thống bỏ qua các bước 3 và 4.
Tiếp tục với Luồng Cơ Bản, Bước 5.

Khi mô tả một luồng thay thế hoặc ngoại lệ, thì tốt nhất là xác định một bước cụ thể trong luồng cơ bản mà luồng thay thế hoặc ngoại lệ bắt đầu hoặc được kích hoạt. Tương tự, khi mô tả luồng hoàn toàn, bạn nên chỉ ra bước trong luồng cơ bản mà luồng bắt đầu lại.

Thói quen này làm giảm khả năng bạn sẽ bỏ sót bước trong luồng cơ bản của mình. (Thường khi tôi nhận ra những sai lầm này, không có bước phù hợp trong luồng cơ bản để tách ra, điều này thường có nghĩa là một kiểm tra hệ thống đang bị thiếu.) Nó cũng làm cho người đọc của bạn hiểu rõ hơn về khi nào và làm thế nào các luồng thay thế và ngoại lệ được kích hoạt.

Lỗi Viết "Use Case" #6 – Bao Gồm Các Bước Ngoài Phạm Vi:

Một "use case" nên khá rõ ràng. Nó nên mô tả chuỗi các bước (và tất cả các biến thể cần thiết) để hoàn thành 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.

Cần xác định rõ phạm vi từ đầu

Một lỗi phổ biến là bao gồm các bước xảy ra trước các điều kiện tiên quyết, sau các điều kiện hậu quả, hoặc là không liên quan đến mục tiêu của người dùng trong "use case." Lỗi này là một dấu hiệu cho thấy "use case" cần phải được chia thành nhiều hơn một "use case."

Lỗi này dẫn đến việc thiếu yêu cầu vì càng cố gắng bao quát nhiều trong một "use case" duy nhất, thì bạn càng có khả năng bỏ sót các bước và các đường dẫn thay thế qua nó.

Lỗi Viết "Use Case" #7 – Sử Dụng Thuật Ngữ Không Nhất Quán:

Một lỗi cuối cùng có thể gây ra sự nhầm lẫn đáng kể là khi các BA sử dụng các thuật ngữ không nhất quán. Ví dụ, thông thường một "use case" sẽ mô tả một luồng các bước để xử lý một loại thông tin cụ thể.

Hãy giả sử trong tình huống này, chúng ta đang nói về việc tạo một bài viết mới để xuất bản trên trang web này. Nếu bước 1 chỉ bài viết là một "bài blog," bước 3 là một "bài viết," và trong bước 5 có một tham chiếu đến một "mục nội dung đã xuất bản," thì không rõ liệu đây có phải là cùng một khái niệm hay các khái niệm khác nhau.

Không biết lóng tiếng nghiệp vụ, các bên liên quan kỹ thuật của bạn có thể giả định rằng có ba khái niệm khác nhau cần được triển khai với các yếu tố dữ liệu khác nhau và sau đó đặt câu hỏi về cách một khái niệm liên kết với một khái niệm khác.

Và mặc dù nghe có vẻ lớn lao, nhưng đầu tư vào việc tạo ra một từ điển thuật ngữ để làm rõ các thuật ngữ và định nghĩa của chúng có thể tiết kiệm rất nhiều thời gian và sự nhầm lẫn trong tương lai.

Trên đây là những lỗi mà một người Business Analyst hay gặp để bạn lưu ý. Hy vọng những thông tin được BAC tổng hợp trên đây sẽ giúp các bạn có thêm kiến thức hữu ích. Đừng quên đón xem các bài viết mới nhất sẽ được cập nhật thường xuyên tại BAC's Blog.

Nguồn tham khảo:
https://www.bridging-the-gap.com/

Nhu cầu đào tạo doanh nghiệp

BAC là đơn vị đào tạo BA đầu tiên tại Việt Nam. Đối tác chính thức của IIBA quốc tế. Ngoài các khóa học public, BAC còn có các khóa học in house dành riêng cho từng doanh nghiệp. Chương trình được thiết kế riêng theo yêu cầu của doanh nghiệp, giúp doanh nghiệp giải quyết những khó khăn và tư vấn phát triển.

CÁC KHOÁ HỌC BUSINESS ANALYST BACs.VN DÀNH CHO BẠN

Khoá học Online:

Khoá học Offline:

Tại Tp.HCM:

Tại Hà Nội:

Tham khảo lịch khai giảng TẤT CẢ các khóa học mới nhất

Ban biên tập nội dung - BAC

Click để đọc tiếp

Mục đích chính của phân tích dữ liệu là gì? Ứng dụng thực tế trong công việc

Mục đích chính của phân tích dữ liệu là gì và làm thế nào để ứng dụng trong công việc là những câu hỏi thường gặp. BAC sẽ giúp bạn tổng hợp những kiến thức nền tảng thông qua các ví dụ thực tế, gần gũi.
Bài tập phân tích dữ liệu trong kinh doanh cho người mới bắt đầu có đáp án

Bạn muốn tìm bài tập phân tích dữ liệu trong kinh doanh cho người mới bắt đầu có đáp án? Bạn là người mới và chưa biết phải bắt đầu từ đâu? Hãy để BAC giúp bạn thông qua hướng dẫn chi tiết ở đây.
Dữ liệu thứ cấp là gì? phương pháp phân tích dữ liệu thứ cấp là gì?

Nếu bạn đang tìm hiểu về phân tích dữ liệu và gặp khái niệm dữ liệu thứ cấp thì đây là bài viết dành cho bạn. BAC sẽ giúp bạn tìm hiểu tất cả thông tin như định nghĩa, đặc điểm, ưu và nhược điểm cũng như những phương pháp phân tích.
Business Analyst thời đại AI: Cơ hội, thách thức và kỹ năng cần có để không bị thay thế

Trí tuệ nhân tạo (AI) đang thay đổi ngành phát triển phần mềm, ảnh hưởng đến vai trò của Business Analyst (BA). Hãy phân tích BA cần làm gì để thích nghi ở thời đại mới

Bình luận

Lê Anh Tuấn

Chuyên viên HO - Kỹ thuật Ngân hàng số Eximbank

Tôi là nhân sự thuộc Trung tâm Phát triển CNTT – Khối Ngân hàng số, hiện đang đảm nhiệm vai trò kiểm thử phần mềm (tester). Việc tham gia khóa học Business Analyst đã mang lại cho tôi góc nhìn toàn diện và rõ ràng hơn về vai trò của BA trong lĩnh vực ngân hàng.

Khóa học Fundamental Business Analysis tại BAC không chỉ giúp tôi hiểu đúng bản chất công việc BA mà còn hỗ trợ phát triển tư duy nghiệp vụ – từ tiếp cận giải pháp kỹ thuật sang tập trung vào nhu cầu người dùng. Phương pháp giảng dạy kết hợp lý thuyết và thực hành thực tiễn, cùng các hoạt động mô phỏng, thảo luận nhóm đã giúp tôi nâng cao kỹ năng giao tiếp, phân tích và trình bày yêu cầu – những năng lực thiết yếu để phối hợp hiệu quả giữa các bên trong dự án công nghệ.

Xem chi tiết +
Huỳnh Cao Cường

Nhân viên HO - Kỹ thuật Ngân hàng số Eximbank

Tôi hiện đang công tác tại Trung tâm Phát triển CNTT – Khối CNTT, với vai trò là nhân sự chức năng phụ trách mảng Ngân hàng số, chuyên sâu về kiểm thử phần mềm (Tester). Trước khi tham gia khóa học Fundamental Business Analysis do BAC tổ chức, tôi từng hình dung BA chỉ đơn thuần là cầu nối giữa bộ phận kỹ thuật và nghiệp vụ.

Tuy nhiên, quá trình học đã giúp tôi nhận thức rõ hơn về bản chất và tầm quan trọng của vị trí này. BA không chỉ kết nối các bên liên quan, mà còn giữ vai trò định hình yêu cầu, đảm bảo giải pháp được thiết kế đúng mục tiêu và sát với nhu cầu thực tế. Khóa học đã trang bị cho tôi tư duy phân tích bài bản, khả năng diễn đạt yêu cầu rõ ràng, và kỹ năng phối hợp hiệu quả trong môi trường dự án đa chiều.

Với nền tảng công nghệ thông tin sẵn có, khóa học là bước chuyển hướng quan trọng giúp tôi phát triển tư duy nghiệp vụ vững chắc và sẵn sàng theo đuổi lộ trình nghề nghiệp chuyên sâu trong lĩnh vực Business Analysis tại Eximbank.

Xem chi tiết +
Nguyễn Thị Mai Bình

Business Analyst

Với một người ngoại đạo như mình thì những chuyên đề về "kỹ thuật" của BA hết sức quan trọng. Ví dụ như sử dụng các diagram để mô hình hóa requirement, viết User Story/Use case, v...v..

Đến với khóa học Fundamental Business Analysis, mình đã được gặp thầy Lộc, một người người rất nhiệt tình và có tâm. Ngoài việc chia sẻ các kinh nghiệm thực tế trên lớp thì thầy còn dành thời gian ra để tư vấn, hỗ trợ, góp ý CV cho mình. Bên cạnh đó trung tâm và anh Phụng cũng hỗ trợ gửi CV, kết nối học viên tới mạng lưới các công ty đối tác chất lượng, điều này giúp học viên như mình tìm được công việc phù hợp nhất. Cảm ơn BAC.
Xem chi tiết +

Professional Transfer Services in Batumi

Luxury Georgian Transfer Services – Tbilisi & Batumi

Airport Transfers in Georgia

Mục đích chính của phân tích dữ liệu là gì? Ứng dụng thực tế trong công việc

Bài tập phân tích dữ liệu trong kinh doanh cho người mới bắt đầu có đáp án

Dữ liệu thứ cấp là gì? phương pháp phân tích dữ liệu thứ cấp là gì?

Business Analyst thời đại AI: Cơ hội, thách thức và kỹ năng cần có để không bị thay thế

CÔNG TY CỔ PHẦN ĐÀO TẠO VÀ TƯ VẤN BAC