Thứ Năm, Tháng Bảy 7, 2022
HomeWikiViết đặc tả Use Case sao đơn giản nhưng hiệu quả? -...

Viết đặc tả Use Case sao đơn giản nhưng hiệu quả? – https://entechgadget.com

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ổ trợ thêm cho bạn bè .

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à những lao lý, hoặc những policy của người mua. Có sao ghi vậy. Vì đây là quá trình tài liệu hóa nhu yếu trải qua Use Case, nên đồng đội cứ liệt kê hết những Business Rule có tương 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 thuần nhất, đó là Đăng nhập .
Ví dụ so với forum Medium đi ví dụ điển hình. Chúng ta sẽ vẽ Use Case Diagram và viết đặc tả Use Case cho phân hệ quản trị xác nhận người dùng như sau .
Ví dụ về một Use Case Diagram, ở dưới sẽ là Use Case Specification 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 pháp đăng nhập bằng thông tin tài khoản Medium
3. Người dùng nhập thông tin tài khoản Medium và chọn lệnh đăng nhập
4. Hệ thống xác nhận thông tin đăng nhập thành công xuất sắc và được cho phép người dùng truy vấn ứng dụng
5. Hệ thống ghi nhận hoạt động giải trí đăng nhập thành công xuất sắc 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 Gmail
2 a1. Hệ thống chuyển sang màn hình hiển thị đăng nhập của Google
3 a. Người dùng nhập thông tin tài khoản Google và chọn lệnh đăng nhập
4 a. Google xác nhận thông tin đăng nhập thành công xuất sắc và được cho phép người dùng truy vấn ứng dụng
Use Case liên tục bước 5 .

2 b. Người dùng chọn phương pháp đăng nhập bằng thông tin tài khoản Facebook
2 b1. Hệ thống chuyển sang màn hình hiển thị đăng nhập của Facebook
3 b. Người dùng nhập thông tin tài khoản Facebook và chọn lệnh đăng nhập
4 b. Facebook xác nhận thông tin đăng nhập thành công xuất sắc và được cho phép người dùng truy vấn ứng dụng
Use Case liên 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 đủ để bạn bè tưởng tượng, mường tượng ra được chân tay mặt mũi của Use Case Specification .
Anh em hoàn toàn 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ì bạn bè sẽ có 1 sơ đồ Use Case Digram, gồm 5 Use Case, thì sẽ ứng với 5 Use Case Specification .
Tuy nhiên, hoàn toàn có thể đồng đội sẽ thấy confuse ở một số ít 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 hoàn toàn 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 người mua này ổng triển khai lệnh rút tiền. Cụ thể thì hoàn toàn có thể là ổng bấm cái nút “ Rút tiền ” trên màn hình hiển thị. Đó là trigger để Use Case xảy ra .
Còn Pre-Condition là những điều kiện kèm theo cần phải có để ông này ổng rút tiền thành công xuất sắc. Vì ổng không thể nào rút tiền được nếu trong thông tin tài khoản không còn tiện hoặc ổng chưa đút thẻ vô máy .
Hoặc Output ( hoặc Post-Condition ) của Use Case này hoàn toàn 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 hoàn toàn 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ì bạn bè cứ tưởng tượng như thế này …
Trong giải điền kinh xóm chiếu lan rộng ra, ông Tèo là trọng tài, ông Tủn là vận động viên tranh tài. 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 gia .
Use Case thì biểu lộ sự tương tác của Actor trong một môi trường tự nhiên / khoanh vùng phạm vi đơn cử nào đó. Vậy ở đây, Use Case bộc lộ 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 kèm theo tiên quyết mà ông Tủn phải ô kê hết thì mới cho ổng tham gia 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 kèm theo này, ông Tủn không được phép tham gia chạy ở giải điền kinh xóm chiếu lan rộng ra. Hay nói cách khác, không đạt được những điều kiện kèm theo này, Use Case sẽ không được thực thi thành công xuất sắc .
Đó là sự độc lạ 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đâ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 trong thực tiễn thì đồng đội cũng không cần quá chăm sóc yếu tố này làm gì. Trigger trong Use Case hoàn toàn có thể là bất kể thứ gì, hoàn toàn có thể là ảnh hưởng tác động từ phía người dùng, hoặc ảnh hưởng tác động từ chính mạng lưới hệ thống. Miễn nó bộc lộ đượ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 tiễn còn rất nhiều đường khác mà bạn bè hoàn toàn 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í còn đ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 hiển thị thông tin học viên
  3. Admin chọn lệnh hủy kích hoạt
  4. Hệ thống nhu yế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à triển khai hủy kích hoạt
  7. Hệ thống hiển thị thông tin đã 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.

4 a. Admin chọn phương pháp xác nhận khác : Xác nhận qua reCaptcha
4 a1. Hệ thống hiển thị mã reCaptcha và nhu yếu nhập mã reCaptcha để xác nhận
5 a. 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

5 b. 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.

5 c. 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 ), đồng đội sẽ đánh số thứ tự Open 1, 2, 3, 4, 5 …., theo số nguyên. Còn so với Alternative hay Exception Flow, bạn bè nên thêm những ký tự vần âm a, b, c, d … bên cạnh để làm dấu cho dễ phân biệt .
Và để dễ tưởng tượng và quản trị những steps có trong flow hơn, mình sẽ bonus thêm cho bạn bè phần sau đây, kaka 😎

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

Mình cá là 69 % bạn bè 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 triển khai những 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ì tất cả chúng ta phải dùng hình. Anh em sẽ bộc lộ Basic Flow, Alternative Flow và Exception Flow kèm hình vẽ như sau .

BASIC FLOW

1. Admin mở thông tin 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 hiển thị thông tin học viên
3. Admin chọn lệnh hủy kích hoạt
4. Hệ thống nhu yế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à triển khai hủy kích hoạt
7. Hệ thống hiển thị thông tin đã 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.

4 a. Admin chọn phương pháp xác nhận khác : Xác nhận qua reCaptcha
4 a1. Hệ thống hiển thị mã reCaptcha và nhu yếu nhập mã reCaptcha để xác nhận
5 a. 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

5 b. 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.

5 c. 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.

Đó là những gì mình dùng để diễn đạt Flow, một cách rõ ràng, logic và sáng sủa nhất hoàn toàn có thể .
Các step ở Basic Flow, Alternative Flow hay Exception Flow nó đều đối xứng với nhau, biểu lộ rõ thằng nào là thay thế sửa chữa 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ì bạn bè để 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 so với những Exception Flow – những flow làm fail Use Case, bạn bè hãy tô đỏ những step ở đầu cuối mà Use Case xảy ra không thành công xuất sắc ( ví dụ điển hình step 5 b1 hoặc 5 c1 ) .
.
.
.
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 quyền lợi 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 diễn đạt tổng quát và diễn đạt chi tiết cụ thể 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 đồng đội đã hiểu rõ hơn về Use Case, về thực chất cũng như cách ứng dụng nó vào trong thực tiễn sao cho hiệu suất cao. 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 😎

Like this:

Like

Loading…

Source: https://entechgadget.com
Category: Wiki

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Bài viết hay nhất

DANH MỤC WEBSITE