Viết đặc Tả Use Case Sao đơn Giản Nhưng Hiệu Quả?

Hế lô anh em. Ở note trước, mình có note một số ý về Use Case, cũng như cách vẽ một Use Case Diagram. Anh em có thể xem lại ở đây. Kỳ này, mình sẽ note về cách viết đặc tả Use Case sao cho đơn giản, nhưng súc tích và hiệu quả nhất có thể nhé.

Ô kayyyy lét xờ gâuuuu 😎

1. Đặc tả Use Case là gì?

Giả dụ trường hợp ở đây: Anh em đã có Use Case Diagram, đã capture được tổng quan các requirement theo góc nhìn của người dùng. Đó là thứ để chúng ta bỏ vào các document như FRD hoặc SRS.

Tuy nhiên, Use Case Diagram khá là chung chung để các stakeholders có cái nhìn trực quan về những requirements được mô tả. Do đó, anh em cần phải diễn đạt nó một cách chi tiết hơn nữa.

Use Case Specification, hay nói cách khác là ĐẶC TẢ USE CASE sẽ giúp anh em làm chuyện đó.

2. Các thành phần có trong Use Case Specification

Đặc tả Use Case tồn tại dưới dạng một cái bảng ghi chú. Nó mô tả tất tần tật các thông tin về Use Case, giúp anh em đọc vào một phát là hiểu ngay Use Case Diagram nó vẽ vậy là ý gì.

Một cách tổng quan, Use Case Specification gồm 3 thành phần chính:

2.1. Summary

• Use Case Name: Tên Use Case
• Use Case ID: Mã Use Case
• Use Case Description: Tóm gọn nhanh sự tương tác được thể hiện trong Use Case là gì.
• Actor: Những đối tượng thực hiện sự tương tác trong Use Case.
• Priority: Mức độ ưu tiên của Use Case so với các Use Case còn lại trong dự án.
• Trigger: Điều kiện kích hoạt Use Case xảy ra.
• Pre-Condition: Điều kiện cần để Use Case thực hiện thành công.
• Post-Condition: Những thứ sẽ xuất hiện sau khi Use Case được thực hiện thành công.

2.2. Flow

• Basic Flow: luồng tương tác CHÍNH giữa các Actor và System để Use Case thực hiện thành công.
• Alternative Flow: luồng tương tác THAY THẾ giữa các Actor và System để Use Case thực hiện thành công.
• Exception Flow: luồng tương tác NGOẠI LỆ giữa các Actor và System mà Use Case thực hiện thất bại.

2.3. Additional Information

• Business Rule: các quy định về mặt Business mà hệ thống bắt buộc phải nghe theo, làm theo.
• Non-Funtional Requirement: Vì Use Case chỉ dùng để thể hiện Functional Requirement, nên anh em phải bổ sung các yêu cầu về Non-Functional ở đây luôn.

…………………………………………………………………..

Một số thông tin bổ sung thêm cho anh em.

Use Case Description chỉ cần mô tả ngắn gọn theo cú pháp của User Story: Là “Actor”, tui muốn làm “Use Case Name”, để đạt được “mục đích – lý do” gì đó. Đẹp là không quá 3 dòng cho phần tóm gọn Use Case này.

Business Rule là các quy định, hoặc các policy của khách hàng. Có sao ghi vậy. Vì đây là giai đoạn tài liệu hóa yêu cầu thông qua Use Case, nên anh em cứ liệt kê hết các Business Rule có liên quan trong này nhé.

3. Ví dụ về đặc tả Use Case

Anh em hãy cùng xét tới một Use Case đơn giản nhất, đó là Đăng nhập.

Ví dụ đối với diễn đàn Medium đi chẳng hạn. Chúng ta sẽ vẽ Use Case Diagram và viết đặc tả Use Case cho phân hệ quản lý xác thực người dùng như sau.

Ví dụ về một Use Case Diagram, ở dưới sẽ là Use Case Specification

USE CASE SPECIFICATION

Use Case ID	UC-1.1
Use Case Name	Đăng nhập
Description	Là người dùng, tôi muốn đăng nhập vào ứng dụng để sử dụng dịch vụ từ ứng dụng.
Actor(s)	Khách hàng, Google, Facebook
Priority	Must Have
Trigger	Người dùng muốn đăng nhập vào ứng dụng Medium
Pre-Condition(s):	Tài khoản người dùng đã được tạo sẵn Tài khoản người dùng đã được phân quyền Thiết bị của người dùng đã được kết nối internet khi thực hiện đăng nhập
Post-Condition(s):	Người dùng đăng nhập ứng dụng thành công Hệ thống ghi nhận hoạt động đăng nhập thành công vào Activity Log.
Basic Flow	1. Người dùng truy cập ứng dụng Medium.2. Người dùng chọn phương thức đăng nhập bằng tài khoản Medium 3. Người dùng nhập tài khoản Medium và chọn lệnh đăng nhập 4. Hệ thống xác thực thông tin đăng nhập thành công và cho phép người dùng truy cập ứng dụng 5. Hệ thống ghi nhận hoạt động đăng nhập thành công vào Activity Log.
Alternative Flow	2a. Người dùng chọn phương thức đăng nhập bằng tài khoản Gmail2a1. Hệ thống chuyển sang màn hình đăng nhập của Google 3a. Người dùng nhập tài khoản Google và chọn lệnh đăng nhập 4a. Google xác thực thông tin đăng nhập thành công và cho phép người dùng truy cập ứng dụng Use Case tiếp tục bước 5. 2b. Người dùng chọn phương thức đăng nhập bằng tài khoản Facebook 2b1. Hệ thống chuyển sang màn hình đăng nhập của Facebook 3b. Người dùng nhập tài khoản Facebook và chọn lệnh đăng nhập 4b. Facebook xác thực thông tin đăng nhập thành công và cho phép người dùng truy cập ứng dụng Use Case tiếp tục bước 5.
Exception Flow	4c. Hệ thống xác thực thông tin đăng nhập không thành công và hiển thị thông báo.4c1. Người dùng chọn lệnh hủy đăng nhập. Use Case dừng lại. 4c2. Người dùng chọn lệnh lấy lại mật khẩu Use Case tiếp tục Use Case UC1-3 4c3. Người dùng chọn lệnh khóa tài khoản Use Case tiếp tục Use Case UC1-4
Business Rules	BR1.1-1: Người dùng nhập sai thông tin đăng nhập ở lần thứ 6 liên tiếp sẽ bị khóa tài khoản 30 phút.
Non-Functional Requirement	NFR1.1-1: Time out cho màn hình đăng nhập dưới 60 giây.NFR1.1-2: Mật khẩu của người dùng phải được hash bằng MD5.

Đó là đặc tả Use Case. Hi vọng ví dụ này đủ để anh em hình dung, mường tượng ra được chân tay mặt mũi của Use Case Specification.

Anh em có thể làm một Use Case Specification cho một Use Case (tức một hình Oval). Vậy ở ví dụ trên thì anh em sẽ có 1 sơ đồ Use Case Digram, gồm 5 Use Case, thì sẽ ứng với 5 Use Case Specification.

Tuy nhiên, có thể anh em sẽ thấy confuse ở một số chỗ…

4. Một số nhầm lẫn hay gặp

Thường khi làm đặc tả Use Case mình sẽ rất dễ bị nhầm lẫn ở hai chỗ:

• Trigger và Pre-Condition
• Alternative Flow và Exception Flow.

4.1. Trigger và Pre-Condition

Trigger nghĩa là một thứ gì đó để kích hoạt cho Use Case chạy, khởi xướng cho Use Case chạy. Còn Pre-Condition nghĩa là một thứ gì đó, mà phải có nó thì Use Case mới chạy được.

Use Case có thể có Pre-Condition hoặc không, nhưng Trigger thì thường phải có.

Ví dụ Use Case rút tiền tại máy ATM.

• Use Case: Khách hàng rút tiền
• Actor: Khách hàng
• Trigger: Khách hàng thực hiện lệnh rút tiền.
• Pre-Condition:
  • Khách hàng đã đút thẻ vào máy ATM.
  • Số dư lớn hơn 50,000đ.

Tức Use Case chỉ xảy ra khi ông khách hàng này ổng thực hiện lệnh rút tiền. Cụ thể thì có thể là ổng bấm cái nút “Rút tiền” trên màn hình. Đó là trigger để Use Case xảy ra.

Còn Pre-Condition là các điều kiện cần phải có để ông này ổng rút tiền thành công. Vì ổng không thể nào rút tiền được nếu trong tài khoản không còn tiện hoặc ổng chưa đút thẻ vô máy.

Quá hư cấuuu, chỉ có trong phim…

Hoặc Output (hoặc Post-Condition) của Use Case này có thể là trigger của Use Case khác.

Cũng ở ví dụ rút tiền tại máy ATM bên trên, Post-Condition ở đây có thể là:

• Khách hàng nhận được tiền mặt sau khi thực hiện rút tiền.
• Số dư của khách hàng đã bị trừ đi khoảng tiền đã rút.

Nếu những post-conditions này xảy ra thì Use Case: Rút tiền tại máy ATM đã được thực hiện xong. Và đồng thời nó cũng là trigger cho Use Case tiếp theo: Gửi tin nhắn SMS thông báo cho khách hàng.

…

Để phân biệt rõ hơn giữa Trigger và Pre-Condition thì anh em cứ tưởng tượng như thế này…

Trong giải điền kinh xóm chiếu mở rộng, ông Tèo là trọng tài, ông Tủn là vận động viên thi đấu. Cả 2 ông này đều là Actor. Một ông là Actor ở vai trò trọng tài, còn một ông là Actor ở vai trò vận động viên tham dự.

Use Case thì thể hiện sự tương tác của Actor trong một môi trường/ phạm vi cụ thể nào đó. Vậy ở đây, Use Case thể hiện sự tương tác chạy đua trong một giải điền kinh, mà cả Actor trọng tài và Actor vận động viên đều tham gia vào.

Vậy thì đâu là Trigger, và đâu là Pre-Condition?

Trigger chính là cò nổ của ông Tèo trọng tài. Ổng giơ súng lên trời, bắn cái đùng, là ông Tủn vận động viên bắt đầu chạy. Hay nói cách khác, khi cò nổ, thì là lúc Use Case bắt đầu.

Còn Pre-Condition là những điều kiện tiên quyết mà ông Tủn phải ô kê hết thì mới cho ổng tham dự giải đấu, ví dụ:

• Nặng trên 50km.
• Không có tiền sử trĩ hay táo bón kinh niên
• Đã vượt qua vòng loại ở giải trẻ cấp ao làng.
• ….

Ví dụ vậy, không đạt được những điều kiện này, ông Tủn không được phép tham gia chạy ở giải điền kinh xóm chiếu mở rộng. Hay nói cách khác, không đạt được những điều kiện này, Use Case sẽ không được thực hiện thành công.

Đó là sự khác biệt giữa Trigger và Pre-Condition.

Một điểm nữa là có thể anh em sẽ cảm thấy bối rối khi phân biệt đâu là Trigger và đâu là bước đầu tiên trong Basic Flow của Use Case. Vì có thể Trigger sẽ là bước đầu tiên của Basic Flow, hoặc không.

Tuy nhiên thực tế thì anh em cũng không cần quá quan tâm vấn đề này làm gì. Trigger trong Use Case có thể là bất kỳ thứ gì, có thể là tác động từ phía người dùng, hoặc tác động từ chính hệ thống. Miễn nó thể hiện được hình ảnh cò nổ để Use Case chạy là được.

4.2. Alternative Flow và Exception Flow

Flow là các luồng tương tác giữa các Actor và hệ thống với nhau. Basic Flow là luồng tương tác chính, là happy case đơn giản nhất có thể xảy ra.

Ví dụ chạy từ Quận 1 ra Quận 7 thì cứ men theo Cách Mạng Tháng 8 ra Hoàng Diệu, rồi cứ cắm đầu Nguyễn Văn Linh là ra. Đó chính là Basic Flow, là đường ngắn nhất, cơ bản nhất.

Nhưng thực tế còn rất nhiều đường khác mà anh em có thể đi: như quẹo qua Quận 8, đi Võ Văn Kiệt, Phạm Thế Hiển…. Hoặc thậm chí đi giữa đường xe bị lủng bánh, không có chỗ vá, phải dắt bộ ngược zề, và không qua được Quận 7 nữa, chuyến đi thất bại.

Những trường hợp đó mình sẽ gom hết lại, và quy nó thành Alternative Flow hoặc Exception Flow. Cụ thể:

• Alternative Flow: những hướng khác giúp anh em đi từ Quận 1 tới Quận 7 thành công, như các tuyến đường khác chẳng hạn.
• Exception Flow: những trường hợp mà nó ngăn chặn, khiến cho anh em không qua Quận 7 được, làm kế hoạch qua Quận 7 mình bị thất bại, như: lủng xe, hết xăng, bị công an giam xe…

Vậy xét qua lăng kính Use Case, đặc tính của 3 luồng tương tác này như sau:

BASIC FLOW	ALTERNATIVE FLOW	EXCEPTION FLOW
Ý ĐỒ THỂ HIỆN	Luồng đi đơn giản nhất	Các luồng đi khác	Các luồng đi khác
KẾT QUẢ DẪN TỚI	Use Case xảy ra thành công	Use Case xảy ra thành công	Use Case xảy ra thất bại

…

Ví dụ trong mô hình quản lý e-Learning, anh em có một Use Case: Hủy kích hoạt tài khoản học viên chẳng hạn. Use Case này sẽ có các Flow như sau.

BASIC FLOW

1. Admin mở tài khoản học viên cần hủy kích hoạt
2. Hệ thống hiển thị màn hình thông tin học viên
3. Admin chọn lệnh hủy kích hoạt
4. Hệ thống yêu cầu nhập mã OTP để xác nhận
5. Admin nhập đúng mã OTP để xác nhận lệnh hủy kích hoạt
6. Hệ thống kiểm tra mã OTP và tiến hành hủy kích hoạt
7. Hệ thống hiển thị thông báo đã hủy kích hoạt.

ALTERNATIVE FLOW

1a. Admin chọn học viên cần hủy kích hoạt ở lưới học viên. Use Case tiếp tục bước 3.

4a. Admin chọn phương thức xác nhận khác: Xác nhận qua reCaptcha

4a1. Hệ thống hiển thị mã reCaptcha và yêu cầu nhập mã reCaptcha để xác nhận

5a. Admin nhập đúng mã reCaptcha để xác nhận lệnh hủy kích hoạt

6a. Hệ thống kiểm tra mã reCaptcha và tiến hành hủy kích hoạt Use Case tiếp tục bước 7.

EXCEPTION FLOW

5b. Admin nhập sai mã reCaptcha.

5b1. Hệ thống báo lỗi và hủy bỏ lệnh hủy kích hoạt học viên. Use Case dừng lại.

5c. Admin nhập sai mã OTP.

5c1. Hệ thống báo lỗi và hủy bỏ lệnh hủy kích hoạt học viên. Use Case dừng lại.

*Ghi chú:

Đối với luồng chính (Basic Flow), anh em sẽ đánh số thứ tự xuất hiện 1, 2, 3, 4, 5…., theo số nguyên. Còn đối với Alternative hay Exception Flow, anh em nên thêm các ký tự chữ cái a, b, c, d… bên cạnh để làm dấu cho dễ phân biệt.

Và để dễ hình dung và quản lý các steps có trong flow hơn, mình sẽ bonus thêm cho anh em phần sau đây, kaka 😎

4.3. Bonus: Mô tả Flow sao cho ngầu

Mình cá là 69% anh em lần đầu viết flow cho use case sẽ thấy hơi… rối bời, và không biết tổ chức các steps sao cho logic hết.

Để giải quyết vấn đề này, hãy vẽ nó. Một lần nữa, việc vẽ lên ngôi.

Dùng chữ khó quá thì chúng ta phải dùng hình. Anh em sẽ thể hiện Basic Flow, Alternative Flow và Exception Flow kèm hình vẽ như sau.

(Hình dưới có thể hiển thị không tốt lắm cho điện thoại, nên anh em xem trên laptop để có trải nghiệm tốt nhất nhé)

BASIC FLOW1. Admin mở tài khoản học viên cần hủy kích hoạt 2. Hệ thống hiển thị màn hình thông tin học viên 3. Admin chọn lệnh hủy kích hoạt 4. Hệ thống yêu cầu nhập mã OTP để xác nhận 5. Admin nhập đúng mã OTP để xác nhận lệnh hủy kích hoạt 6. Hệ thống kiểm tra mã OTP và tiến hành hủy kích hoạt 7. Hệ thống hiển thị thông báo đã hủy kích hoạt.

Basic Flow thể hiện dưới dạng process.

ALTERNATIVE FLOW1a. Admin chọn học viên cần hủy kích hoạt ở lưới học viên. Use Case tiếp tục bước 3. 4a. Admin chọn phương thức xác nhận khác: Xác nhận qua reCaptcha 4a1. Hệ thống hiển thị mã reCaptcha và yêu cầu nhập mã reCaptcha để xác nhận 5a. Admin nhập đúng mã reCaptcha để xác nhận lệnh hủy kích hoạt 6a. Hệ thống kiểm tra mã reCaptcha và tiến hành hủy kích hoạt Use Case tiếp tục bước 7.

Alternative Flow thể hiện dưới dạng process.

EXCEPTION FLOW5b. Admin nhập sai mã reCaptcha. 5b1. Hệ thống báo lỗi và hủy bỏ lệnh hủy kích hoạt học viên. Use Case dừng lại. 5c. Admin nhập sai mã OTP. 5c1. Hệ thống báo lỗi và hủy bỏ lệnh hủy kích hoạt học viên. Use Case dừng lại.

Exception Flow thể hiện dưới dạng process.

Đó là những gì mình dùng để mô tả Flow, một cách rõ ràng, logic và sáng sủa nhất có thể.

Các step ở Basic Flow, Alternative Flow hay Exception Flow nó đều đối xứng với nhau, thể hiện rõ thằng nào là thay thế của thằng nào, và thằng nào là Exception của thằng nào.

Riêng luồng tương tác nào Exception thì anh em để dạng nét đứt cho dễ phân biệt.

Các step bắt đầu (có thể là Trigger hoặc không) và kết thúc anh em hãy tô màu đen, để các Stakeholder có thể nắm được độ phức tạp của Use Case một cách nhanh nhất.

Còn đối với các Exception Flow – những flow làm fail Use Case, anh em hãy tô đỏ các step cuối cùng mà Use Case xảy ra không thành công (chẳng hạn step 5b1 hoặc 5c1).

.

.

.

TÓM GỌN

Đặc tả Use Case về bản chất rất đơn giản vì nó mang ngôn ngữ tự nhiên của người dùng. Vấn đề chỉ nằm ở một số điểm hay nhầm lẫn và cách  chúng ta tổ chức các Use Case như thế nào cho logic và hiệu quả mà thôi 🙂

5. Chốt lại: làm Use Case được lợi ích gì?

Mình sẽ tóm gọn giá trị của Use Case (cả Diagram và Specification) qua 2 bài notes về Use Case như sau:

1. Use Case giúp anh em thể hiện được rõ Requirement theo góc nhìn của người dùng cuối (rất quan trọng, vì nó giúp mình hiểu rõ bản chất vấn đề hơn).
2. Theo đó, những gì được thể hiện trong Use Case rất tự nhiên, ai đọc vô cũng hiểu hết trơn.
3. Use Case có thể chia nhỏ phạm vi theo nhiều phân hệ, hoặc cụm tính năng. Và nó cũng có thể nhìn dưới góc độ high-level. Do đó, dễ hơn cho mình rất nhiều để cover đủ các yêu cầu trong một dự án lớn.
4. Use Case là bước đệm tuyệt vời giữa việc mô tả tổng quát và mô tả chi tiết sự tương tác thông qua Sequence Diagram (con nhà UML).
5. Use Case được dùng để tạo các Epic, và các User Stories trong dự án Scrum, làm mọi thứ được nhất quán và rất chặt chẽ.
6. Use Case còn được dùng để tạo các Test Case sau này.

…

Hi vọng anh em đã hiểu rõ hơn về Use Case, về bản chất cũng như cách ứng dụng nó vào thực tế sao cho hiệu quả. Nếu có gì cần trao đổi thì cứ còm men bên dưới cho mình nhé!

Bái bai và hẹn gặp lại 😎

Share để lưu lại

• Nhấn vào chia sẻ trên Facebook (Mở trong cửa sổ mới)
• Bấm để chia sẻ lên LinkedIn (Mở trong cửa sổ mới)
• Nhấp để chia sẻ trên WhatsApp (Mở trong cửa sổ mới)
• Nhấp để chia sẻ trên Telegram (Mở trong cửa sổ mới)
• Bấm để chia sẻ trên Pocket (Mở trong cửa sổ mới)
• Bấm để gửi một liên kết tới bạn bè (Mở trong cửa sổ mới)

Thích điều này:

Thích Đang tải...

Related