Jan 12, 2022

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

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

6 kỹ năng hàng đầu cần có ở các Data Science năm 2022

Data Science trong năm 2022 cần những kỹ năng hàng đầu bao gồm cả kỹ năng kỹ thuật và kỹ năng phi kỹ thuật. Bài viết này sẽ giúp các bạn tổng hợp những kỹ năng quan trọng nhất để chuẩn bị cho một năm sôi động của Big Data.
4 mẹo quản lý các vấn đề về yêu cầu cho các Business Analyst

Quản lý các vấn đề về yêu cầu là công việc quen thuộc với các Business Analyst. Tuy nhiên, đối với các bạn mới bắt đầu, việc này sẽ tương đối khó khăn, tốn nhiều thời gian, công sức. Các mẹo trong bài viết này chính là đáp án cho các bạn.
7 Kỹ thuật hữu ích giúp khơi gợi yêu cầu của khách hàng

BA cần nắm được các yêu cầu cụ thể của khách hàng, rồi từ đó hệ thống hóa nó lại và cung cấp cho họ một cái nhìn tổng quan hơn về dự án. Bài viết này giới thiệu về những kỹ thuật hữu ích giúp BA khơi gợi yêu cầu của khách hàng hiệu quả.
Làm thế nào trở thành Business Analyst khi không có nền tảng CNTT

Hiện này, nhu cầu về nhà phân tích nghiệp vụ CNTT đang phát triển với tốc độ khá nhanh. Vậy nếu không có nền tảng về CNTT thì có thể trở thành BA được hay không?. Trong blog này, chúng ta sẽ đọc một vài gợi ý về cách trở thành một BA mà không cần kiến thức nền tảng.

Bình luận

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 +
Phạm Quế

Business Analyst

Khoá học Product Design của BAC đã cung cấp cho tôi nhiều kiến thức và nền tảng vô cùng hữu ích. Giảng viên giảng dạy rất nhiệt tình, truyền cho chúng tôi ngọn lửa đam mê và nhiệt huyết trong ngành. Đồng thời chia sẻ các kiến thức và kỹ năng cần thiết trong bài giảng một cách dễ hiểu hơn. Số lượng học viên không quá nhiều nên chất lượng giảng giạy vô cùng tốt. Giảng viên sửa bài tập 1-1 nên bài giảng sẽ chuyên sâu hơn.
Xem chi tiết +
Nguyễn Văn Long

Chuyên viên về chế độ kế toán & Giải pháp nghiệp vụ Tài chính kế toán trong ứng dụng CNTT - Tập đoàn Điện lực Việt Nam (EVN)

Tôi đã tham gia khóa Phân tích nghiệp vụ phần mềm cơ bản 3.0 tại BAC. Ở đây, tài liệu đào tạo cung cấp nhiều nội dung bổ ích và trình bày dễ hiểu. Giảng viên rất nhiệt tình, ngoài nội dung giảng dạy theo giáo trình còn chia sẻ nhiều kinh nghiệm thực tiễn, các câu hỏi của học viên đều được giải đáp ngay trên lớp và có minh họa từ các dự án trong thực tế. Sau tất cả, tôi cảm ơn BAC và Thầy giáo Thái Sơn.
Xem chi tiết +