Mar 11, 2024

Làm thế nào để viết một Use Case: Dạng mẫu và hướng dẫn

Use case (trường hợp sử dụng) là một công cụ quyền lực để phân tích và giao tiếp với yêu cầu phần mềm.

Nếu bạn có một nền tảng về kinh tế, một use case sẽ giúp bạn xác định được phần mềm cần làm gì, kể cả khi bạn không có nhiều (hoặc không có) kiến thức về công nghệ/viết phần mềm.
Nếu bạn là một chuyên gia về kỹ thuật, một use case sẽ giúp bạn truyền đạt về chức năng của phần mềm bằng cách sử dụng ít thuật ngữ công nghệ hơn.

Trong bài hướng dẫn về use case này, bạn sẽ học cách áp dụng những use case trong công việc phân tích một cách chuẩn chỉnh nhất. Tôi cũng sẽ chia sẻ những template (dạng mẫu) ưa chuộng với chú thích và diễn giải chi tiết do đó bạn sẽ biết chính xác nội dung từng phần.

Hôm nay chúng ta sẽ nói về cách để viết một use case. Tôi cực kỳ hào hứng bởi vì những use case này chính là công cụ phân tích yêu thích của tôi. Hy vọng là khi tôi chia sẻ bài hướng dẫn này, bạn sẽ hiểu tại sao và được khuyến khích để bắt đầu trải nghiệm công cụ này, hoặc có thể là một ghi chú nếu bạn đã từng sử dụng chúng để bạn có thể sử dụng hiệu quả hơn một chút.

1. Tại sao cần viết Use Case?

Trước tiên, tại sao bạn viết use case? Viết để làm gì? Tại sao bạn cần chúng? Với cương vị là một người học về kinh tế, bạn sẽ có thể sẽ quan ngại về việc là thế nào để thực sự giao tiếp với những yêu cầu kỹ thuật hay là yêu cầu phần mềm. Bạn sẽ giao tiếp với nhà phát triển phần mềm bằng cách nào để đảm bảo rằng bạn có được thứ bạn muốn ở hệ thống phần mềm?

Một trong những lý do tuyệt vời để sử dụng use case là chúng thật sự là một điểm kết nối. Cả những người dùng với nền tảng kinh tế hay kỹ thuật đều có thể thật sự hiểu chúng và đề ra những phản hồi về chúng. Với cương vị là những chuyên viên phân tích nghiệp vụ, chúng ta sử dụng chúng như một công cụ giao tiếp để thu hẹp khoảng cách hay kết nối mọi người với nhau, về mặt kỹ thuật chung, nó là ngôn ngữ chung về những gì phần mềm sẽ làm.

Với cương vị là một người có nền tảng kỹ thuật, bạn sẽ có thể tìm kiếm một cách để giao tiếp với các bên liên quan, xây dựng sự tham gia của các bên liên quan, bỏ qua chuyện ngôn ngữ của “ký tự”, đề cập nhiều hơn về “những gì hệ thống làm” thay vì “cách hệ thống làm”. Điều này thật sự giúp đẩy nhanh tiến độ giao tiếp, làm rõ và đảm bảo rằng bạn đang xây dựng thứ mà doanh nghiệp thật sự cần và muốn khi bạn bắt đầu ngồi xuống và code.

2. Use case là gì?

Tại sao cần viết Use Case?

Use case là gì? Làm thế nào để giải quyết những vấn đề trên khi chúng ta là nhà phân tích, người chuyên kỹ thuật hay những người dùng chuyên về kinh tế?

Một use case là một mô tả bằng văn bản nắm bắt được sự tương tác giữa người dùng và hệ thống để đạt được một mục tiêu nhất định. Điều này rất quan trọng, đó là sự tương tác giữa người dùng và hệ thống phần mềm. Nó khác hơn một quy trình nghiệp vụ - nắm bắt tất cả mọi thứ mà người dùng sẽ làm để đạt được mục tiêu hay kết quả tổng quan hơn trong tổ chức. Use case rất đặc biệt, về mặt làm thế nào để người dùng thực sự tương tác với hệ thống phần mềm để đạt được một mục tiêu. Đây là một mục tiêu chi tiết hơn.

3. Ví dụ về use case

Một số ví dụ về use case:

Mua khóa học
Xem video
Đăng ký training miễn phí
Tải template

Mua khóa học là một ví dụ của Use Case

Use case là ví dụ cụ thể về những gì người dùng có thể làm với phần mềm. Chúng ghi lại tất cả các cách mà người dùng và hệ thống có thể tương tác.

Chi tiết của những use case bao gồm tất cả những trường hợp và biến thể có thể xảy ra. Điều gì sẽ xảy ra nếu bạn đi mua một khóa học, và địa chỉ email không hợp lệ, thẻ tín dụng không hợp lệ hoặc những vấn đề tương tự vậy. Tất cả những biến thể về việc điều gì có thể diễn ra không đúng trong những lối khác nhau trong phạm vi của hệ thống. Đó là thứ cho phép chúng ta có được yêu cầu phần mềm.

4. Use case template + Step-by-Step Tutorial

Điều gì sẽ bao gồm trong một use case? Tôi sẽ thông qua những thành phần chung nhất trong một template use case truyền thống.

5. Làm thế nào để đặt tên một Use Case?

Nếu bạn muốn bắt đầu với một cái tên, và cũng giống như một quy trình doanh nghiệp, bạn muốn cái tên nó phải ở dạng “động từ - danh từ”. Vậy nên, “mua khóa học”, “ đăng ký khóa học miễn phí”, không phải chỉ “khóa học miễn phí”. Như vậy bạn có thể biết hành động của người dùng nên được mô tả trong use case là gì.

6. Viết mô tả sơ lược cho Use Case

Tiếp theo là mô tả sơ lược, và một trong những thứ tôi muốn đề cập trong phần mô tả sơ lược là một câu văn làm rõ phạm vi. “This use case starts when…” and “This use case ends when…” bởi vì chuyện gì diễn ra khi bạn bắt đầu viết những bước trên là bạn tìm ra những biến thể đó.

Sau đó, đột nhiên, use case của bạn xuất hiện khắp nơi và bạn kiểu, “Laura, đây không phải là một chuỗi các bước. Đó là một trang web.” Điều này thường là do bạn đang đi chệch hướng hoặc khám phá các giải pháp thay thế quá chi tiết hoặc thực sự không nằm trong phạm vi các bước cần thực hiện cho mục tiêu cụ thể của trường hợp sử dụng đó.

7. Xác định những tác nhân của Use Case

Những tác nhân bao gồm: người dùng, hay vai trò, những loại tác nhân mà có thể sử dụng hệ thống? Đây không đề cập đến tên nghề nghiệp, mà là tác nhân.

Nhiều người có thể đảm nhận vai trò đó trong hệ thống. Đó là những gì hệ thống có thể xác định về bạn.

Bạn có phải là người mua hàng?
Bạn có phải là quản trị viên?
Bạn có phải là phóng viên?
Một cái gì đó tương tự.

8. Xác định điều kiện tiên quyết (Preconditions)

Điều kiện tiên quyết: điều gì sẽ phải “đúng” trước khi Use Case bắt đầu?

Một lần nữa, là một cấp độ hệ thống. Hệ thống có thể biết điều gì là đúng trước khi use case bắt đầu?

9. Viết quy trình cơ bản (Basic Flow) cho Use Case

Tiếp theo, là phần Basic Flow, và tôi thích nghĩ về Basic Flow kiểu ping pong: Người dùng làm một thứ, sau đó hệ thống sẽ làm một thứ khác. Người dùng làm một thứ, sau đó hệ thống sẽ làm một thứ khác. “Ping pong, ping pong”. Không phải lúc nào cũng giống như thế. Đôi khi sẽ kiểu “Ping, ping, pong, pong, pong. Ping pong.” Nó không nhất thiết phải chỉ là một lần qua rồi lại như vậy, nhưng hãy nghĩ về nó như một quả bóng bàn thực sự giúp đảm bảo rằng bạn đang nhận được sự tương tác giữa người dùng và hệ thống.

Điều chúng tôi thấy rất phổ biến ở những người tham gia khóa học phân tích nghiệp vụ là những người có nhiều kiến thức nền tảng về kinh tế sẽ nói: “Ping, ping, ping. User, user, user, user, user, user.” Hệ thống thực hiện một việc. Thực sự, hệ thống vẫn đang làm mọi việc, họ chỉ không nhìn thấy nó vì họ không quen tìm kiếm xem hệ thống làm gì để hỗ trợ họ và vì họ là business user nên họ đang nghĩ về tất cả những gì hệ thống làm để hỗ trợ họ. những điều đang xảy ra trong doanh nghiệp. Vì vậy, họ không nhìn thấy.

Đó là một phần lý do khiến use case trở thành một công cụ mạnh mẽ như vậy. Nó thực sự giúp bạn, với tư cách là một business user, biết hệ thống đang làm gì để hỗ trợ bạn và những yêu cầu đó thực sự là gì đối với hệ thống mà bạn có thể không thấy. Nó trở nên rất quan trọng khi bạn giống như, “Ping, ping, ping, ping. User, user, user, user.”

Mặt khác, một người thiên về kỹ thuật hơn sẽ thường nói, “Người dùng thực hiện một việc theo kiểu ‘Boom, boom, boom, boom.’” Nó giống như, “Pong, pong, pong, pong, pong.” Đó là tất cả các chi tiết mặt kỹ thuật về những gì hệ thống đang thực hiện, chuyên sâu hơn nhiều so với những gì doanh nghiệp thực sự quan tâm bởi vì bạn chỉ mất chúng bằng “văn bản” nói về “Ồ, hệ thống thực hiện loại quy trình này và cập nhật dữ liệu và gửi dữ liệu này tới API này, đồng thời cập nhật biểu mẫu web” và tất cả chi tiết kỹ thuật này. Đó không phải là những gì có trong use case.

Thay vào đó, tìm hiểu công cụ mô hình hóa dữ liệu (data modeling techniques) như từ điển dữ liệu (data dictionary), sơ đồ ngữ cảnh (system context diagram), và bản đồ data (data map) để đảm bảo là bạn đã hiểu đầy đủ về những yêu cầu dữ liệu (data requirements). “Use case không phải là đặc tả kỹ thuật cũng không phải đặc tả hệ thống.”

Bạn muốn những yêu cầu, hoặc thứ gì sẽ nằm trong đặc tả chức năng (functional specification). Điều này liên quan đến phần có thể quan sát được của hệ thống là gì, mà người dùng có thể thấy hệ thống đang hoạt động và trải nghiệm hệ thống đang hoạt động? Không phải cách hệ thống đang làm tất cả những điều đó. Tôi nhận ra rằng có rất nhiều điều kỳ diệu và thú vị xảy ra ở đó; nó không phù hợp với use case của bạn. “Ping pong”. Đôi khi, “Ping, ping, pong,” nhưng không phải tất cả cái này hay tất cả cái kia. Nếu không, bạn thực sự có một loại tài liệu khác chứ không phải use case.

10. Luồng tương tác thay thế (Alternative Flow) và luồng tương tác ngoại lệ (Exception Flow)

Sau đó, là các luồng thay thế và các luồng ngoại lệ. Đây là các đường dẫn biến thể. Đôi khi—Hãy xem một ví dụ. Đối với "use case" "Xem Video," bạn có thể "Tạm Dừng." Bạn có thể tạm dừng video. Bạn có thể kết thúc video (xin đừng làm như vậy!). Bạn có thể làm các việc khác. Bạn có thể "Thích" video. Có thể bạn có—Đôi khi có thể không phù hợp với phạm vi của "use case" đó nhưng tất cả các việc khác bạn có thể làm. Đây là các luồng thay thế.

Một luồng ngoại lệ có thể là: điều gì xảy ra nếu kết nối Internet của bạn bị ngắt và luồng kết thúc? Làm thế nào để hiển thị điều đó cho người dùng? Những điều gì có thể xảy ra sai và ngăn cản mọi người không đạt được mục tiêu cuối cùng hoặc kết thúc của "use case".

11. Các điều kiện cần được kiểm tra sau khi hoàn thành (Postconditions)

Cần kiểm tra điều kiện sau khi hoàn thành để đảm bảo đúng mục tiêu ban đầu

Post-conditions là những điều đúng sau khi "use case" đã kết thúc. Nếu có bất kỳ thông tin nào cần được lưu trữ hoặc đầu ra cần được tạo ra, tất cả đều cần có các bước trong "use case" của bạn, và bạn có thể ghi lại chúng như là post-conditions. Một lần nữa, bạn không cần phải nhớ tất cả các chi tiết này. Hãy đảm bảo tải xuống mẫu "use case" của chúng tôi, sẽ cung cấp cho bạn một mẫu được chú thích, tất cả các phần này, một tóm tắt nhanh gọn về những gì đã bao gồm. Một lần nữa, đó chỉ là một trong số mười ba mẫu mà chúng tôi bao gồm trong Bộ công cụ Mẫu Phân Tích Nghiệp Vụ của chúng tôi.

12. Use Cases không yêu cầu kiến thức về mặt kỹ thuật (Technical)

Một điều mà tôi muốn đề cập—và tôi đã nói đến điều này khi tôi mô tả một "use case", nhưng chúng ta vẫn nhận được rất nhiều câu hỏi về nó—đó là: liệu rằng "use case" đó cần kiến thức kỹ thuật không? "Nếu tôi không biết về công nghệ thì phải làm sao? Làm thế nào để tôi giao tiếp với nhà phát triển, và làm thế nào để tôi thực hiện các yêu cầu? Dường như tôi phải biết tất cả công nghệ này, và tôi phải biết về phân tích nghiệp vụ."

Thực ra, bạn phải nghĩ về "use case" như là một công cụ cho phép bạn giao tiếp về những gì công nghệ cần làm mà không cần phải biết cách xây dựng nó, bởi vì bạn không phải làm tất cả những cái "Pong, pong, pong, pongs" đó. Bạn không thấy tất cả các mảnh ghép khác nhau của công nghệ diễn ra sau hậu trường.

Bạn đang nói, "Như một người dùng, chức năng quan sát của tôi là gì? Hệ thống làm gì cho tôi?" Chúng ta nên có thể rất rõ ràng về điều đó như một nhà phân tích nghiệp vụ. Đó là một phần của sự rõ ràng mà chúng ta mang lại.

13. Use Case giúp bạn hỏi những câu hỏi thông minh

Đó là lý do tại sao "use case" là một công cụ tuyệt vời; chúng giúp chúng ta đặt ra những câu hỏi rất thông minh, giúp phát hiện ra những khoảng trống trong tư duy và hiểu biết và yêu cầu.

Use Case giúp phát hiện được những lỗ trống tư duy

Ví dụ, giả sử chúng ta đang nói về "Mua Khóa học." Chúng ta có một bước cho người dùng chọn một khóa học, một bước cho hệ thống hiển thị biểu mẫu đặt hàng. Sau đó, người dùng điền vào biểu mẫu đặt hàng; người dùng gửi biểu mẫu đặt hàng, giỏ hàng kiểm tra chi tiết thẻ tín dụng. Tôi có thể đã bỏ sót một vài điều ở đây, nhưng bạn sẽ có sự trao đổi này giữa người dùng và hệ thống.

Tôi hy vọng rằng điều đó là cả một hướng dẫn về cách tạo ra một "use case" và một bài học về tại sao chúng lại thú vị và quan trọng, và tại sao tôi yêu chúng đến vậy, và cách chúng là một công cụ phân tích mạnh mẽ mà bạn nên sử dụng để thực sự làm sáng tỏ các yêu cầu để kết nối khoảng cách giữa doanh nghiệp và các bên liên quan đến công nghệ, đưa mọi người thực sự trên cùng một trang về những gì phần mềm cần làm bằng cách sử dụng một công cụ giao tiếp và một công cụ phân tích giúp bạn phát hiện khoảng trống và giao tiếp với những người vừa là kỹ thuật vừa không kỹ thuật. Hãy tiếp tục khám phá thêm nhiều điều mới tại BAC's Blog bạn nhé!

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

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 mạnh mẽ ngành phát triển phần mềm, ảnh hưởng trực tiếp đến vai trò của Business Analyst (BA). Bài viết phân tích BA cần làm gì để thích nghi, nâng cấp kỹ năng và đón đầu các cơ hội trong thời đại AI.
Prototype sớm - Nghệ thuật hiện thực hóa ý tưởng của BA thông minh

Thời đại AI mở ra cơ hội mới cho BA: biến ý tưởng thành sản phẩm nhanh chóng bằng prototype sớm. Đây là chìa khóa giúp kiểm chứng giá trị, thúc đẩy sáng tạo và khai thác tối đa sức mạnh công nghệ.
10 Thuật ngữ AI ai cũng nên biết

Khám phá 10 thuật ngữ quan trọng nhất trong lĩnh vực trí tuệ nhân tạo (AI) cùng BAC – từ AI, Machine Learning đến Generative AI, Copilot và hơn thế nữa. Bài viết được biên dịch từ nguồn Microsoft, giúp bạn hiểu rõ cách công nghệ này hoạt động và đang thay đổi thế giới. Một tài liệu nhập môn hoàn hảo cho người mới, chuyên viên công nghệ hay bất kỳ ai muốn bắt kịp làn sóng chuyển đổi số.
Học AI từ con số 0: Lộ trình đơn giản cho người mới bắt đầu

Khám phá lộ trình học AI đơn giản cho người mới bắt đầu cùng BAC. Bạn không cần giỏi lập trình để có thể học AI và trở thành chuyên gia. Những kiến thức này hoàn toàn có thể được tiếp thu và ứng dụng thực tế bởi tất cả mọi ngườ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

4. Use case template + Step-by-Step Tutorial

5. Làm thế nào để đặt tên một Use Case?

6. Viết mô tả sơ lược cho Use Case

7. Xác định những tác nhân của Use Case

8. Xác định điều kiện tiên quyết (Preconditions)

9. Viết quy trình cơ bản (Basic Flow) cho Use Case

10. Luồng tương tác thay thế (Alternative Flow) và luồng tương tác ngoại lệ (Exception Flow)

11. Các điều kiện cần được kiểm tra sau khi hoàn thành (Postconditions)

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ế

Prototype sớm - Nghệ thuật hiện thực hóa ý tưởng của BA thông minh

10 Thuật ngữ AI ai cũng nên biết

Học AI từ con số 0: Lộ trình đơn giản cho người mới bắt đầu

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