Uѕe caѕe là gì? Uѕe caѕe là một tài liệu mô tả từ đầu đến cuối hành ᴠi của hệ thống từ góc nhìn của người ѕử dụng. Uѕe caѕe mô tả ѕự tương tác đặc trưng giữa người dùng bên ngoài (Actor) ᴠà hệ thống. Mỗi Uѕe caѕe ѕẽ mô tả cách thức người dùng tương tác ᴠới hệ thống để đạt được mục tiêu nào đó.Ngoài ra, Uѕe caѕe cũng хác định trình tự các bước mô tả mọi tương tác giữa người dùng ᴠà hệ thống. Tuу nhiên, Uѕe caѕe được định nghĩa theo thuật ngữ của người dùng, không phải của hệ thống, mô tả những gì mà người dùng làm ᴠà người dùng nhìn thấу hơn là những gì đầu ᴠào hệ thống mong đợi ᴠà đầu ra của hệ thống là gì. Show Bạn đang хem: đặc tả uѕe caѕe là gì
Đặc tả yêu cầu phần mềm<Dự án><Nhóm tác giả><Ngày tháng năm> MỤC LỤC1. Giới thiệu2. Tổng quan hệ thống3. Đặc tả yêu cầu hệ thống3.1 Danh sách các actor và usecase3.2 Sơ đồ usecase3.2.1. Sơ đồ usecase tổng quát3.2.2 Sơ đồ usecase cho phân hệ …(usecase chi tiết)3.3 Đặc tả usecase (đặc tả tối thiểu 2 usecase chính của hệ thống)3.3.1 Usecase “…”Cấu trúc đặc tả usecase gồm 3 phần như sau:1. SummaryUse Case Name: Tên Use CaseUse Case ID: Mã Use CaseUse 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. FlowBasic Flow: luồng tương tác CHÍNH giữa các Actor và System để Use Case thực hiện thànhcông.Alternative Flow: luồng tương tác THAY THẾ giữa các Actor và System để Use Case thựchiệ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ựchiện thất bại.3. Additional InformationBusiness Rule: các quy định về mặt Business mà hệ thống bắt buộc phải nghe theo, làmtheo.Non-Funtional Requirement: Vì Use Case chỉ dùng để thể hiện Functional Requirement,nên có thể bổ sung các yêu cầu về Non-Functional ở đây luôn.3.3.2. usecase “…” Ví dụ đặc tả usecase “Đăng nhập”:Use CaseIDUC-1.1Use CaseNameĐăng nhậpDescriptionLà người dùng, tôi muốn đăng nhập vào ứng dụng để sử dụngdịch vụ từ ứng dụng.Actor(s)Khách hàng, Google, FacebookPriorityMust HaveTriggerNgười dùng muốn đăng nhập vào ứng dụng MediumPreCondition(s):Tài khoản người dùng đã được tạo sẵnTài khoản người dùng đã được phân quyềnThiết bị của người dùng đã được kết nối internet khi thựchiện đăng nhậpPostCondition(s):Người dùng đăng nhập ứng dụng thành côngHệ thống ghi nhận hoạt động đăng nhập thành công vàoActivity Log.Basic Flow1. 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ảnMedium3. Người dùng nhập tài khoản Medium và chọn lệnh đăng nhập4. Hệ thống xác thực thông tin đăng nhập thành công và chophép người dùng truy cập ứng dụng5. Hệ thống ghi nhận hoạt động đăng nhập thành công vàoActivity Log. 2a. Người dùng chọn phương thức đăng nhập bằng tài khoảnGmail2a1. Hệ thống chuyển sang màn hình đăng nhập của Google3a. Người dùng nhập tài khoản Google và chọn lệnh đăng nhập4a. Google xác thực thông tin đăng nhập thành công và chophép người dùng truy cập ứng dụngUse Case tiếp tục bước 5.Alternative Flow2b. Người dùng chọn phương thức đăng nhập bằng tài khoảnFacebook2b1. Hệ thống chuyển sang màn hình đăng nhập của Facebook3b. Người dùng nhập tài khoản Facebook và chọn lệnh đăngnhập4b. Facebook xác thực thông tin đăng nhập thành công và chophép người dùng truy cập ứng dụngUse Case tiếp tục bước 5.ExceptionFlow4c. 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ẩuUse Case tiếp tục Use Case UC1-34c3. Người dùng chọn lệnh khóa tài khoảnUse Case tiếp tục Use Case UC1-4BusinessRulesBR1.1-1: Người dùng nhập sai thông tin đăng nhập ở lần thứ 6liên tiếp sẽ bị khóa tài khoản 30 phút.NonFunctionalRequirementNFR1.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. Learn when to describe an exception and when to go into an alternate flow. This is essential to improve readability of your use cases. As you might all know writing use cases may be tricky. The template is as easy as you can think. But using it efficiently is not that easy. One question I have been asked several times lately is When do I have to describe an Exception? What is an Alternate Flow? Actually, the difference is very easy to explain.
Cancel is no Alternative! It’s an ExceptionAnything that leads to NOT achieving the use case’s goal is an Exception. Very often the user is requested to confirm a step like data entry or delete something. In that situation there is always the possibility that the user does not confirm but cancel the use case. So what happens? The system works perfectly right handling the cancellation. Nevertheless this is a typical Exception because it leads to not achieving the use case’s goal. In the example below the user confirms the deletion in step 5. But there are two other options the user may select: He aborts the the deletion or he prolongs the deletion. Because both possibilities refer to step 5 they are numbered as 5a and 5b within the section Exceptions. Again, both exceptions are not caused by system errors or malfunction. But both exceptions lead to not achieving the use case’s goal, which is the deletion of the contract. In the first case the user will not delete the contract. In the letter case the contract is also not deleted but additionally put into the job queue for later assessment. Alternatives lead to successWe consider any steps deviating from the main success scenario, which finally lead to a success of the use case as Alternative Steps. There are many roads to Rome. The main success scenario describes the most likely way a user may take to achieve the business goal. Nevertheless, there may be other ways to perform a particular step or a sequence of steps. Those different paths are called Alternate Flows or Alternatives. Below an example show how to delete a contract. From the pure business perspective this is most likely not the way we do that. But take it just as an example. In the first step the user’s navigates to the customer who’s contract to be deleted. Next he selects the particular contract (step 2). Instead of locating the customer the user may filter the huge list of contracts alternatively. As this is an alternative to step 1 of the success scenario it is numbered as 1a within the alternate flows. As it is nothing stated explicitly in the alternate step the use case will continue with step 2 of the main scenario. The user selects the contract and initiates the deletion. Use case with two exceptions and one alternate step How do you deal with this issue in your projects? I hope I could provide a rule of thumb to distinct between Exceptions and Alternatives. If there are any questions or suggestions don’t hesitate and write a comment. #AlternateFlow #BusinessProcessAnalysis #Exceptions #UseCase
Use case là một tài liệu mô tả từ đầu đến cuối hành vi của hệ thống từ góc nhìn của người sử dụng. Use case mô tả sự tương tác đặc trưng giữa người dùng bên ngoài (Actor) và hệ thống. Mỗi Use case sẽ mô tả cách thức người dùng tương tác với hệ thống để đạt được mục tiêu nào đó. Ngoài ra, Use case cũng xác định trình tự các bước mô tả mọi tương tác giữa người dùng và hệ thống. Tuy nhiên, Use case được định nghĩa theo thuật ngữ của người dùng, không phải của hệ thống, mô tả những gì mà người dùng làm và người dùng nhìn thấy hơn là những gì đầu vào hệ thống mong đợi và đầu ra của hệ thống là gì. Những thành phần của Use case
Use case diagramUse case diagram là một sơ đồ biểu diễn bằng hình ảnh về các hành vi của người dùng trong một hệ thống, cách người dùng tương tác với hệ thống. Nó chỉ ra luồng đi từ hoạt động này sang hoạt động khác trong một hệ thống. Nó đặc biệt quan trọng trong việc xây dựng mô hình chức năng của hệ thống và nhấn mạnh tới việc chuyển đổi quyền kiểm soát giữa các đối tượng người dùng (Actors) 
Trên đây là ví dụ về Use case diagram cho trường hợp 'Login'. Trong ví dụ này, chúng ta có nhiều người sử dụng hệ thống và tất cả đều được đặt bên ngoài hệ thống. Students, Teacher, Parents được xem như là những người dùng chính (Actors) của hệ thống vì thế họ được đặt bên trái và ở ngoài hình chữ nhật. Admin và Staff được xem là người dùng phụ vì thế cũng được đặt bên phải và ở ngoài hình chữ nhật. Tất cả các người dùng đều có thể đăng nhập vào hệ thống vì thế chúng ta biểu diễn mối quan hệ giữa người dùng (Actors) và chức năng Login. Ngoài ra, còn những chức năng khác của hệ thống như "Reset Password" và "Forgot Password". Chúng cũng có mối liên quan đến chức năng "Login", vì thế chúng ta cũng cần có biểu diễn mối quan hệ giữa các chức năng này với nhau. Use case testing là gì?Use case testing là một kỹ thuật kiểm thử chức năng của kiểm thử hộp đen, vì thế chúng ta sẽ không cần quan tâm đến code. Nó giúp Tester xác định được các kịch bản kiểm thử được thực hiện trên toàn bộ hệ thống từ đầu đến cuối của mỗi giao dịch. Một vài đặc điểm của Use case testing
Ví dụ về Use case testing Ví dụ với trường hợp kiểm tra điểm của sinh viên của hệ thống quản lý giáo dục Actors: Students, Teacher, Parents Pre-condition:
Dưới đây là Use case và Test case tương ứng đối với trường hợp kiểm tra điểm của sinh viên Kết luậnQua bài viết này tôi hi vọng các bạn có thể hiểu rõ hơn về Use case và Use case testing. Viết Use case là một quá trình lặp lại. Bạn chỉ cần dành một chút thời gian để thực hành và cần có kiến thức tốt về hệ thống để thiết kế Use case. Tóm lại, chúng ta có thể sử dụng ‘Use Case testing’ trong một ứng dụng để tìm các liên kết còn thiếu, các yêu cầu không hoàn chỉnh… Tìm chúng và sửa đổi hệ thống sẽ đạt được hiệu quả và chính xác cho hệ thống. Nguồn: https://www.softwaretestinghelp.com/use-case-testing/ |
