Lab 5: Use Case Specifications The use case specification document (template) describes the process for developing use case specifications during requirements gathering. This process needs to be followed when developing functional requirements especially when those requirements are from a user's perspective. Use cases specification template <ToDo: Create a table for each use case. Use cases must be numbers e.g., UC01, UCO2.... > Use case Id: UC?? <Use case Title> Brief Description Primary actors Preconditions: Post-conditions: Main Success Scenario: Actor Action 1. System Response 2. Alternative flows: ?.a. Example Use case Id: UC01 Login Brief Description User login to the Payroll System Primary actors Payroll Officer and HR Manager Preconditions: The user has a valid account. Post-conditions: If the use case was successful, the actor is logged into the system. If not, the system state is unchanged. Main Success Scenario: Actor Action System Response 1. Enters username and password 2. The system validates the entered username and password and logs the user into the system (See 2.a. for alternative flow) Alternative flows: 2.a. Invalid Username/Password If the user enters an invalid username and/or password, the system displays an error message. The user can choose to either return to the beginning of the basic flow or cancel the login, at which point the use case ends. Case Study: All Phones Shop (APS) Student Name: Student ID: System description: All Phones Shop (APS) is a company that sells three types of phone: smartphone, normal mobile phone, and land phone. APS currently uses a small computer based system called PoB that manages the payroll of its employees, all payments made by clients, and the financial information of the APS client. PoB is actually a standard, commercial-off-the-shelf application. APS has two types of client: individual, and corporate. To buy or sell a phone, the client must first register if he/she does not have any registration with APS. In order to register, the client has to provide name and address. APS first checks if the client already exists. If not, the system creates a registration, assigns a unique registration number, PoB is advised by APS with the registration number. PoB then opens a financial account of the client with the registration number. All payments of the client are handled by PoB and recorded in the financial account. However, APS keeps only the registration information such as name, address, the registration number, the invoice(s) if the client has bought any item from APS, and the item information if the client sells any item. For all future sale and buy activities with APS, the client has to use the same registration number. A registration can only be removed by corporate clients. In this case, APS checks if there is any unpaid invoice attached with the client registration. PoB is informed if a client registration is removed. The individual client can only create registration but cannot remove any registration. APS does not handle any login operation, it is assumed all login functions are checked before any operation is executed. To sell an item, the client first selects the type of the item that he/she wants to sell. Under smartphone category, there are two sub-categories: Apple iPhone and Samsung Galaxy. The client then provides model, make, capacity, and color. The client has the option to sell the item either on auction (bidding), or on fixed price sale. For the auction, a starting price and the end of the auction time is specified; and for the fixed price sale, a price is given. For both types of sale (fixed price and auction), the system assigns an ID to the item, records and attaches the item information with the client registration. For the catalog entry, APS then automatically creates a display image based on the item description, asks the client (seller) to approve it, and displays the item for sale if approved by the client. Otherwise, the system re-creates another image, and displays it to the client for approval. Once the client approves the display image, APS includes it in its product catalog. Clients can also remove their items after display but before sale; in that case, a penalty of 10% of the starting price (for auction) or the fixed price of the item is charged to the client, and an advice on this penalty will be sent to PoB. Clients can also buy items on auction, or on fixed price sale. For the fixed price items, the client selects item(s). The system creates a shopping basket for the selected item(s). The system saves the shopping basket, and attaches this with the client registration. The client then checks out, and each item in the basket is considered "sold", and removed from the product catalog. For auction, clients can bid a price for the selected item before the end of auction time. A bid submitted by a client must be greater than the last offered bid (price). All bids submitted by a client are recorded in the registration of the client. When the auction time ends, the client with last bid will be notified as the winner. The item is considered "sold", and removed from the product catalog. For either type of sale, APS prepares an invoice (bill) based on the item(s). Once the client confirms the invoice, it is attached with the client registration with the status "unpaid”. For all payments, PoB informs APS with the client registration number and the invoice number. The system finds the invoice, and assigns the invoice as “paid". If a client fails to pay to PoB within 7 days, a penalty of 10% of the price is charged to the client, an advice on this penalty is sent to PoB, and the sale is cancelled by APS. Task: Develop two use case specification of the system. Lab topic(s): Requirement specification Lab objective(s): Understanding of Flow of events in a use case • Identification of system responses to actor's actions • Identification of alternative flows. Lab activities: Activity Resources and notes Estimated time 10 minutes The lab instructor explains the lab activities Lab-5 Students write their name and SID • First page of this 5 minutes (See first page on where to write document these) The lab instructor explains the Use case specification 15 Minutes specification of the use case "Create available from Registration" document Each student reviews their use case. Use case diagram 10 minutes diagram (second draft) developed in (second draft) Lab 1 this Task 1: The student develops • System description, 30 minutes specification for the use case "Sell • Use case diagram, item" Template for use case specification The student saves the specification. This document 5 minutes in this document Task-2: The student develops System description, 30 minutes specification for the use case "Buy on . Use case diagram, auction" • Template for use case specification 8. The student saves the specification. This document 5 minutes in this document Submit your work to the lab instructor, This document with two 5 minutes and leave the lab clean and tidy. use case specifications. • Below is an example on the use case "Create Registration” specification template. Use case ld: UC001 Create Registration Brief Description The client creates a new registration with APS and PoB is informed about the new client. Primary Client, PoB. actors Preconditions: 1. The client must not exist. Post-conditions: 1. A client registration is created. Main Success Scenario: A client registration has been created. Actor Action System Response 1. The client provides details 2. Check if the client exits 3. Create a registration with the client details if the registration does not exist. (See 3.a. for alternative flow) 4. Assign a unique number to the registration 5. Advise PoB about the new client. 6. Inform the client with the registration number. Alternative flows: 3.a. If the client already exists, inform the client that a new registration cannot be created. Enter vour work here: Task 1: Use cases specification template <ToDo: Create a table for each use case. Use cases must be numbers e.g., UC01, UC02.... > Use case Id: UC?? Sell Item Brief Description Primary actors Preconditions: Post-conditions: Main Success Scenario: Actor Action 1. System Response 2. Alternative flows: ?.a. Task 2: Use cases specification template <ToDo: Create a table for each use case. Use cases must be numbers e.g., UC01, UCO2.... > Use case Id: UC?? Buy item on auction Brief Description Primary actors Preconditions: Post-conditions: Main Success Scenario: Actor Action 1. System Response 2. Alternative flows: 2.a.
