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 quaUse 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.