Là nhà phân tích nghiệp vụ [Business Analyst - BA], bạn có nhận thấy rằng chúng ta có khá nhiều tác vụ liên quan đến một số tương tác với đội ngũ phát triển Công nghệ Thông tin [CNTT] hoặc hệ thống CNTT hay không? Vậy thì, bạn đã bao giờ gặp khó khăn trong việc hoàn thành những trách nhiệm của mình nếu bạn không có nhiều [hoặc bất kỳ] kiến thức công nghệ chưa? Và bạn đã tìm ra cách để giải quyết những khó khăn này chưa?
Còn nếu bạn là một chuyên gia về kỹ thuật, bạn có muốn tìm hiểu "bí quyết" giúp bạn chia sẻ chính xác những gì đội ngũ IT đang làm cho dự án, đặc biệt là khi trình bày với những người không rành về công nghệ [non-tech] không? Bạn đã từng được yêu cầu thuyết trình về những gì mà công nghệ có thể hỗ trợ nhưng lại phải sử dụng càng ít "ngôn ngữ IT" càng tốt mà vẫn đảm bảo người nghe hiểu chính xác ý nghĩa chưa?
Vâng, một công cụ mạnh mẽ đã ra đời để giúp cả hai bên cùng nhau giải quyết vấn đề này. Vậy, công cụ đó là gì? Đó chính là Use Case [UC]! Nếu bạn chưa sử dụng UC bao giờ, BAC hy vọng bài viết này sẽ giúp bạn hiểu được UC là gì và làm thế nào để viết UC? Tại sao UC được khuyến khích sử dụng trong nhiều dự án?,...
Còn nếu bạn đã từng áp dụng UC trong công việc phân tích của mình và vẫn còn gặp khó khăn thì BAC hy vọng bải viết này sẽ giúp bạn sử dụng UC tốt hơn trong các dự án sau này.
Trước tiên, chúng ta cần tìm hiểu lợi ích mà UC mang lại để tăng tính thuyết phục vì sao chúng ta cần tìm hiểu và nên sử dụng UC? Công cụ này được áp dụng để làm gì và tại sao phải áp dụng nó?
Đứng ở phía nghiệp vụ/ kinh doanh, bạn có thể gặp vấn đề về việc làm thế nào để thực sự truyền đạt các yêu cầu của các bên liên quan đến đội ngũ phát triển vì bạn chưa hiểu rõ những yêu cầu đó được anh em IT gọi là gì và chúng sẽ được code ra như thế nào? Nếu chưa hiểu rõ thì làm sao để giao tiếp với bên phát triển phần mềm và vẫn đảm bảo rằng họ nhận được chính xác những gì bên nghiệp vụ và các bên liên quan mong muốn?
Đứng ở phía IT, bạn có thể đang tìm cách giao tiếp với các bên nghiệp vụ và hạn chế sử dụng các thuật ngữ chuyên ngành, hạn chế nói quá chi tiết về cách hệ thống thực hiện cũng như những gì hệ thống làm. Nếu hạn chế quá nhiều vậy thì liệu sẽ có thiếu sót gì không? Làm sao để tăng tốc độ giao tiếp, làm rõ và đảm bảo rằng các bên liên quan sẽ hiểu bạn, cùng như bạn đã ngồi xuống và bắt đầu code đúng những gì mà bên liên quan mong đợi?
Vâng, đó là lý do để chúng ta nên sử dụng một công cụ tuyệt vời: Use Case - một phương thức kết nối cả hai bên lại với nhau. Để một dự án thành công, cả doanh nghiệp và đội ngũ kỹ thuật phải thực sự hiểu nhau, phản hồi, góp ý và nhận xét cho nhau. Vì vậy mà BAs - người sẽ gắn kết tất cả mọi người lại với nhau cần học cách sử dụng nhuần nhuyễn UC như một công cụ giao tiếp hiệu quả trong việc thu hẹp khoảng cách và kết nối mọi người với nhau bằng một "ngôn ngữ chung".
2. Định nghĩa về Use Case:
Use case là gì? Làm thế nào mà UC giải quyết những vấn đề này cho tất cả các bên liên quan bao gồm nhân viên phân tích, nhân viên kỹ thuật, và các đại diện của doanh nghiệp?
Hiểu đơn giản thì UC là một mô tả dạng văn bản ghi lại sự tương tác giữa người dùng và hệ thống để đạt được một kết quả có ý nghĩa. Điều này thực sự quan trọng. Đó là sự tương tác giữa người dùng và hệ thống phần mềm và phải đạt được một kết quả và kết quả đó phải có ý nghĩa.
Khác với quy trình nghiệp vụ, cái mà nhờ nó chúng ta có thể nắm bắt tất cả những điều mà người dùng sẽ làm để đạt được mục tiêu tổng thể hoặc kết quả của tổ chức. UC sẽ chi tiết hơn và liên quan đến cách người dùng thực sự tương tác với hệ thống phần mềm để đạt được mục tiêu có nghĩa.
Ví dụ: Bạn nhấp chọn vào đường dẫn này và đăng ký thành công một khoá học, thì điều này có nghĩa bạn đang thực thi một UC.
Những điều rất chi tiết và cụ thể mà người dùng có thể thực hiện với hệ thống phần mềm, tất cả các cách mà người dùng và hệ thống đó có thể tương tác, bao gồm các trường các ngoại lệ và biến thể có thể xảy ra [chẳng hạn như bạn đăng ký khoá học bằng một địa chỉ email không hợp lệ hoặc những điều tương tự],..., tất cả chính là UC.
Lưu ý: Những ngoại lệ và biến thể đó phải nằm trong phạm vi của hệ thống thì phần mềm đó đạt yêu cầu.
3. UC bao gồm những gì? Biểu mẫu [template] của một UC
Có những thành phần nào trong một UC? Tuỳ từng công ty khác nhau mà bạn sẽ có những templates khác nhau để viết UC. Bạn có thể tham khảo qua các mẫu UC mà BAC đã tổng hợp tại đây.
-
Thành phần đầu tiên của một UC đó là Tên của UC [UC Name]. Giống như quy trình nghiệp vụ, tên của UC thường được viết theo cú pháp “động từ + danh từ”.
-
Ví dụ: “Đăng ký khoá học”, “xem thông tin giảng viên”, “tìm kiếm nội dung”,...
-
Đừng đặt những cái tên như “Khoá học Phân tích nghiệp vụ cơ bản” hay "Giảng viên A",... vì bạn cần nắm rõ hành động mà người dùng cần thực hiện được mô tả trong UC là gì?
-
-
Tiếp theo là mô tả ngắn gọn [short description] cho UC, và một trong những điều chúng ta nên vào mô tả là một câu hoàn chỉnh và phải đảm bảo rõ ràng về phạm vi.
-
“Trường hợp sử dụng này bắt đầu khi…”
-
“Trường hợp sử dụng này kết thúc khi…”
-
Khi bạn bắt đầu viết tất cả các bước, bạn sẽ phân tích thêm các trường hợp ngoại lệ và biến thể trong UC, nếu không giới hạn phạm vi thì có thể đột nhiên bạn nhận ra rằng UC của bạn bao gồm rất nhiều hành động khác nữa. Bạn có thể trao đổi thêm với nhóm thì nhận ra rằng: “Này, đây không giống một chuỗi các bước. Đây giống một trang web luôn rồi." Lúc này, bạn đang đi chệch hướng hoặc phân tích quá chi tiết các phương án thay thế, hoặc bạn đã ra khỏi phạm vi của các bước cần thực hiện cho mục tiêu cụ thể của UC đó.
-
Nhắc lại: Xác định điểm bắt đầu và kết thúc sẽ giúp ích rất nhiều cho bạn.
-
-
Thành phần tác nhân [actor]: Actor có thể là người dùng [user], là vai trò, hoặc bất kỳ tác nhân nào có thể tác dụng lên hệ thống. Actor không phải là chức danh nghề nghiệp và nhiều người có thể cùng thực hiện vai trò đó với hệ thống [ví dụ như nhiều người có thể "đăng ký khoá học"]. Actor là những ai đượchệ thống có thể xác định: Bạn có phải là người mua hàng không? Bạn là quản trị viên hay không? Hay bạn là học viên?,...
-
Điều kiện tiên quyết [preconditions]: Điều gì cần phải thực hiện đúng trước khi bắt đầu UC? Đây là một cấp độ rất hệ thống. Điều gì hệ thống có thể biết là đúng trước khi UC bắt đầu?
-
Tiếp theo là luồng cơ bản [basic flow]. Bạn có thể hình dung basic flow giống một trò thể thao “ping pong” [bóng bàn], người dùng thực hiện một thao tác [tạm hình dung là “ping”] và hệ thống sẽ phản hồi lại [“pong”] ≈ một người chuyền bóng [“ping”] và người còn lại đỡ bóng và tiếp tục chuyền bóng [“pong”]. Và ta thấy các hành động lần lượt là “ping ► pong ► ping ► pong”. Việc liên tưởng đến “ping pong” sẽ giúp bạn dễ hình dung hơn về tương tác giữa người dùng và hệ thống.
-
Tuy nhiên, mọi việc không phải lúc nào cũng rõ ràng và nhất định phải là như vậy. Thỉnh thoảng sẽ là “ping ► ping ► pong ► pong ► pong.” Không phải lúc nào cũng bắt buộc là nếu có một tương tác [“ping”] thì bên còn lại phải đáp trả lại ngay lập tức [“pong”].
-
Từ góc nhìn của những ai có kiến thức nền nghiêng về nghiệp vụ, đôi khi họ chỉ thấy “ping ► ping ► ping” nhiều hơn, tức thấy những tác vụ/ hành động của người dùng nhiều hơn. Trong khi đó, hệ thống thì chỉ thực hiện 1 tác vụ duy nhất [??!]. Tuy nhiên, thực tế thì hệ thống đã “ngầm” thực hiện nhiều tác vụ khác. Nếu bạn không thấy được điều này là vì bạn chưa quen với việc ”nhìn” ra ra được nhìn gì hệ thống đang hỗ trợ mà thôi. Hoặc có thể là vì bạn đứng từ góc nhìn của một nhà kinh doanh nên sẽ thấy rõ các hành động của người dùng hơn. Những gì không nhìn thấy được sẽ là một hạn chế có thể khắc phục được nhờ sức mạnh của Use Case [UC sẽ giúp bộ phận nghiệp vụ nhận ra được hệ thống đang hỗ trợ chúng ta những gì, cũng như các yêu cầu thật sự được thể hiện như thế nào trong hệ thống. Và ngược lại,...
-
Đối với bên nghiêng về kỹ thuật hơn, họ sẽ thường thấy các người dùng chỉ thực hiện một tác vụ duy nhất [??!], trong khi hệ thống phải thực hiện rất nhiều “pong ► pong ► pong ► pong”. Những chi tiết mà hệ thống đang hỗ trợ là những điều khá sâu về mặt kỹ thuật và thường không được bên nghiệp vụ quan tâm hoặc thậm chí bị bỏ qua trong quá trình giao tiếp. Tất cả những chi tiết kỹ thuật như “Hệ thống phải thực hiện loại thủ tục này, và cập nhật dữ liệu này, đồng thời gửi dữ liệu tới API này và cập nhật biểu mẫu web như thế này…” không phải là một thông số kỹ thuật, cũng không phải là một chi tiết hệ thống. Vậy nên, chúng sẽ không xuất hiện trong UC, thay vào đó là các yêu cầu [requirements], tức những gì người dùng có thể trải nghiệm và quan sát được từ hệ thống [chứ không phải là hệ thống đang "âm thầm" hoạt động như thế nào]. Chúng ta thường gọi vui rằng có một loại “phép thuật thần kỳ” đã xảy ra và “phép thuật” này sẽ không được đề cập trong UC.
-
Tóm lại: “Ping pong”, đôi khi có thể là “ping ► ping ► pong ► pong” nhưng không phải lúc nào các tương tác cũng chính xác như vậy. Nếu mọi thao tác đều tương tác qua lại đúng theo một cú pháp nào đó 100%, thì có lẽ bạn sẽ cần một loại tài liệu khác chứ không phải là UC nữa.
-
-
Luồng thay thế [alternate flow] và luồng ngoại lệ [exception flow] là những hướng đi khác nhau trong UC.
-
Alternate flow là một hướng đi khác main flow [tách nhánh] nhưng cuối cùng sẽ gom nhánh lại ở một hành động nào đó và kết thúc của alternate flow sẽ giống basic flow, đó là UC được thực hiện thành công. Một ví dụ về alternate flow đó là: Trong UC “Xem đoạn video ngắn” thì sẽ có những hành động khác nữa như “tạm dừng video” hay “tua nhanh video”, “thích video”, và tất cả những hành động có thể xảy ra khi bạn xem một đoạn video.
-
Một ví dụ để làm rõ exception flow có thể xảy ra đó là: "Mất điện" hoặc "mất wifi đột ngột",... thì điều gì sẽ xảy ra vói người dùng? Exception flow là những gì có thể xảy ra và ngăn cản người dùng đạt được mục đích cuối cùng.
-
-
Post-condition là những gì sẽ xảy ra sau khi UC kết thúc. Ví dụ như thông tin nào sẽ được lưu trữ, hoặc kết quả đầu ra cần được tạo là gì,... sẽ được đề cập đến trong phần post-condition này.
4. Hoàn thành bộ UC có yêu cầu nhiều kiến thức về kỹ thuật?
Có khá nhiều câu hỏi thường gặp khi nhắc đến UC:
-
“Tôi không giỏi kỹ thuật lắm thì có viết được UC không?”
-
“Không biết về công nghệ thì sao tôi có thể trao đổi với đội ngũ phát triển về UC?”
-
“Tôi cần phải thành thạo cả về mặt nghiệp vụ và công nghệ phải không?”
Câu trả lời chung cho các câu hỏi này đó là: UC là công cụ cho phép giao tiếp các kiến thức về công nghệ mà không cần thực sự nắm rõ kỹ thuật, vì bạn sẽ không phải là người trực tiếp hoàn thành nó. Bạn không nhất thiết phải nhìn rõ từng tác vụ khác nhau đang chạy như thế nào phía sau một hệ thống. Bạn chỉ cần nhìn theo hướng của một người dùng, những chức năng có thể nhìn thấy là gì? Tôi có thể nhìn thấy những gì hệ thống đang làm cho mình. Đây cũng là điều mà một BA cần phải làm rõ và thảo luận cụ thể.
5. UC là một công cụ hỗ trợ người BA đặt ra những câu hỏi chính xác
Như bạn đã biết thì các tác vụ chính của một người BA đó là Định nghĩa dự án -> Làm rõ -> Phân tích -> Tài liệu hoá - Xác thực -> Quản lý. UC là một người bạn hỗ trợ đắc lực trong giai đoạn là rõ và giúp BAs đặt đúng câu hỏi cần được giải đáp, xoá bỏ khoảng cách giữa các bên và hiểu rõ các yêu cầu hơn. Nhìn vào UC mà bạn sẽ hình dung từ đầu cho đến khi kết thúc UC những gì đang diễn ra và thấy được những khoảng cách, những điểm bất hợp lý, những gì chưa rõ cần được giải thích,... Từ đó, các câu hỏi bạn đưa ra sẽ chính xác hơn, như “Điều này thực sự xảy ra như thế nào?”, “Từ bước 3 đến bước 4 đã hợp lý chưa?”
BAC hy vọng rằng những chia sẻ trên sẽ hữu ích các bạn và các bạn có thể áp dụng ngay kiến thức vừa thú vị vừa quan trọng này ngay vào thực tế công việc. Từ đó hiểu rõ các yêu cầu, thu hẹp khoảng cách giữa doanh nghiệp, đội ngũ phát triển và các bên liên quan khác, đưa mọi người thực sự hiểu lẫn nhau và hiểu về những gì phần mềm cần thực hiện.
Bạn có thể tham khảo thêm đoạn video từ Bridging the gap nói về UC bên dưới nhé:
Trên đây lầ các thông tin cơ bản và khá đầy đủ liên quan đến nội dung về UC. BAC hy vọng sẽ có ích cho các bạn. Bên cạnh đó, nếu bạn muốn tìm hiểu thêm thông tin về các tác vụ và chuẩn chỉnh nghiệp vụ của một BA, bạn có thể tham khảo thêm các khoá học tại BAC: