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