7 sai lầm thường gặp khi viết Use Cases của Business Analyst

Bạn đã bao giờ gặp trường hợp các nhà phát triển đưa ra những câu hỏi về cách hệ thống làm việc ngay cả khi bạn đã viết tài liệu chức năng trong một use case?. Use case là một công cụ yêu cầu có giá trị để nắm bắt những yêu cầu chức năng trong bối cảnh hành động của người dùng. Cùng với wireframes, chúng có thể là một công cụ để cuối cùng đưa mọi người vào cùng trang về các yêu cầu phần mềm.

Use case cần được trình bày một cách rõ ràng, cụ thể

Nhưng một số lỗi use case thường gặp sẽ làm cho use case khó hiểu và thực sự có thể tạo ra nhiều sự mơ hồ về các yêu cầu. Bạn có thể tránh nhiều khó khăn cho mọi thành viên trong nhóm bằng cách đảm bảo bản thân không mắc một số lỗi dưới đây.

1. Sử dụng ngôn ngữ người dùng

Sai lầm phổ biến nhất trong use case là chúng 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ì nói “người X tạo tài khoản mới” chúng lại nói rằng “người X nhấn vào nút tạo tài khoản”.

Sử dụng giao diện người dùng chi tiết sẽ dẫn đến sự mơ hồ. Điều này là không trực quan vì “nhấn vào nút tạo tài khoản” có vẻ cụ thể hơn nhưng đôi khi tên của phần tử không xác định rõ ràng hành động người dùng đang thực hiện. Vì thế, nó tạo ra sự mơ hồ về bước thật sự mà chúng tôi cần từ người dùng để hệ thống thành công.

2. Không xác định một phản hồi hệ thống với một hành động người dùng

Sai lầm tiếp theo là từ những cá nhân không tiếp xúc nhiều với các dự án công nghệ thông tin, đó là các use case thiên về quy trình. Use case rất rõ ràng về các bước mà người dùng cần thực hiện nhưng nó thiếu hành động hệ thống tương ứng cần phải xảy ra theo từng bước của người dùng.

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

3. Thêm chi tiết kỹ thuật

Một lỗi phổ biến khác có xu hướ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.

Những ví dụ phổ biến của chi tiết kỹ thuật bao gồm:

• Xác định các đối tượng dữ liệu hoặc các bảng dữ liệu.
• Tên của các thành phần hệ thống sẽ không hiển thị với người dùng cuối thông thường của hệ thống.
• Các quy trình hoặc thủ tục do hệ thống kích hoạt cần chạy.

Bao gồm quá nhiều chi tiết kỹ thuật có thể làm rõ mọi thứ cho nhóm kỹ thuật nhưng phá vỡ quy trình của use case và khiến các bên liên quan doanh nghiệp của bạn khó hiểu và người kiểm thử của bạn để kiểm tra. Những chi tiết này được lưu tốt nhất cho một tài liệu thiết kế kỹ thuật.

4. Không phù hợp với wireframes

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

Wireframe thường được tạo ra cùng với use case

Việc các use case và wireframes không đồng bộ là điều rất phổ biến. Ví dụ, có thể có một chuỗi các bước không được thể hiện trong wireframe có thể thiếu các nút và trình kích hoạt cần thiết để thực hiện đầy đủ chức năng trong use case.

Sự không nhất quán trong các sản phẩm phân phối cuối cùng tạo ra nhầm lẫn vì không rõ sản phẩm có thể phân phối là nguồn yêu cầu thực sự.

5. Không rõ nơi thay thế và ngoại lệ rẽ nhánh ngoài luồng chính

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

Khi trình bày chi tiết quy trình thay thế hoặc quy trình ngoại lệ, bạn nên xác định một bước cụ thể trong quy trình cơ bản nơi bắt đầu hoặc kích hoạt quy trình. Tương tự như vậy, khi mô tả luồng hoàn tất, bạn nên chỉ ra bước nào trong quy trình cơ bản mà luồng thu hồi trở lại.

Thói quen này giúp bạn ít bỏ lỡ các bước trong luồng cơ bản của mình. Nó cũng làm rõ cho người đọc của bạn chính xác khi nào và cách thức các thay thế và ngoại lệ được kích hoạt.

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

Một use case nên có tính rời rạc, mô tả trình tự từng bước để hoàn thành một mục tiêu người dùng cụ thể, như tạo tài khoản, gửi email hoặc tạo báo cáo. Một sai lầm phổ biến là bao gồm các bước xảy ra trước điều kiện đầu tiên, sau điều kiện sau hoặc không liên quan đến mục tiêu của người dùng trong trường hợp sử dụng. Sai lầm này cho biết rằng use case cần được chia thành nhiều hơn là một use case.

Điều này có thể dẫn đến thiếu các yêu cầu khi bạn cố gắng bao gồm nhiều use case. Càng nhiều use case được bao gồm thì bạn càng có nhiều khả năng bỏ qua các bước và các đường dẫn thay thế thông qua nó.

7. Thuật ngữ không nhất quán

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

Sự nhất quán là yếu tố quan trọng khi viết use case

Giả sử trong trường hợp này, chúng ta nói về việc tạo một bài viết mới để xuất bản trên website. Nếu bước 1 đề cập đến một bài viết dưới dạng “blog post”, thì bước 3 là một “bài viết” và bước 5 có đề cập đến một “mục nội dung đã xuất bản”, thì không rõ liệu tất cả các khái niệm này giống nhau hay khác nhau.

Không biết thuật ngữ kinh doanh, các bên liên quan về kỹ thuật của bạn rất có thể sẽ cho 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à đặt câu hỏi về cách các khái niệm được liên kết.

8. Cách tránh các lỗi khi viết Use Case

Nếu bạn đang mắc các lỗi này, bạn có thể đánh mất cơ hội tạo ra các yêu cầu chức năng rõ ràng và ngắn gọn để các bên liên quan của bạn hiểu, cung cấp phản hồi và thực hiện.

Xem lại use case mới nhất của bạn cho từng lỗi được đề cập và tìm cách sửa nó. Tốt hơn hết, hãy trao đổi các use case với một người khác và xem xét công việc của nhau để tìm dấu hiệu của những lỗi kể trên. Thông thường, một người quan sát bên ngoài có thể thấy những gì chúng ta không có.

Trên đây là bài viết tổng hợp những lỗi thường gặp khi viết use case dành cho các bạn Business Analyst. Mong rằng các thông tin này đã mang đến cho bạn đọc những 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