This assignment supports the following course outcomes: Explain the need for gathering requirements at the outset of a project as well as effective means of gathering such requirements Discuss how Use Case Descriptions and Diagrams can be used to gather and document system requirements

Review the modules content on the components of a use case description, how to create an Intermediate-Level Use Case Description as well as the examples in the module. Pay close attention to the numbering of the main and alternative scenario paths within the description. 2. In your report titled UC Analysis Report make sure that each UC Description: Has the use case goal statement (i.e. the name) Identifies the actor(s) for the use case as well as the trigger event Shows both the main success path (the happy path) as well as the alternative paths (recoverable and non-recoverable exceptions). Label these paths MAIN and EXCEPTION Pay close attention to the numbering scheme used throughout the paths Watch for the need to branch within your paths As discussed in the Module, ensure that your EXCEPTION paths either rejoin the MAIN path or END USE Please place your completed UC Description in tabular format (as shown on Slide 24 of Module-04) 3. NOTE about Supporting Use Cases In the following scenarios, there is reference to several supporting use cases. As mentioned in Module-04 a supporting use case is another, completely separate use case that someone else may have developed (see example on Slide 19 of Module-04 as well as the note on Slide 22 of the module) Being as each supporting use case is complete in its own documentation you do not have to concern yourself (or handle any exceptions) from that use case while developing your own For example in scenario #1 below (the Bank Machine) there is a supporting use case called Verify PIN. When your use case calls on or invokes the Verify PIN use case you do not need to worry about what happens if the user enters their PIN incorrectly? Because that exception would be completely covered by the Verify PIN use case. There is no need for you to handle the exceptions from that use case Use Cases to Capture 1. Please capture the logic of a customer withdrawing $60.00 from an ATM (Bank Machine). The ATMs in question belong to a bank called XYZ Bank. Bank XYZ doesnt believe in interac or cirrus therefore the ATMs for this bank only support XYZ customers (any other bank customers trying to use this ATM are told that they cannot). The ATM detects this situation after the customer inserts their band card. Once the customers PIN has been verified (the logic for this is covered in another use case titled Verify PIN) the ATM presents the options to withdraw or deposit. The customer selects the option to withdraw cash. (if customer selects deposit, then exit the use case) There is only one type of bank account at XYZ Bank so there is no need to ask the user what account they want to withdraw from. The XYZ ATMs only dispense money in $20 REQUIREMENTS increments - if a customer tries to withdraw an amount other than a multiple of $20, they are informed and asked to change the amount to withdraw (or they can cancel the transaction if they wish). Bank XYZ also wants to ensure that they do not lose money on their ATMs so it must be ensured that a customer withdrawing funds actually has those funds in their bank account. If the customer tries to withdraw more money than the bank account allows, the ATM informs them and they can select a different amount or cancel the transaction. The ATM also needs to verify that it has enough cash to dispense before it does so and debits the customers account if the ATM does not have enough cash, the transaction is cancelled. Bank XYZ also does not believe in offering or giving the customer an option of printing a receipt for the withdrawal. 2. Please capture the logic of a user setting an alarm on the XYZ Alarm Clock Radio. The rules behind setting an alarm are straightforward the user must first choose the Create Alarm option from the Administration Menu. The clock will prompt the user for the date and time of the alarm - the values entered must represent a valid date/time and it must be in the future (if not, the clock will alert the user and ask for re-entry or to cancel the alarm). Then the user is presented with the option of waking to a tone or a radio station. If they choose to wake to a radio station, then they may choose from a list of radio pre-sets that they have already created or they can choose to set a different radio station for the alarm (this is covered in another use case titled Set Radio Station). If they choose to wake to a tone, then they may choose from a list of preexisting tones on the clock radio or they can choose to upload a new tone for the alarm (this is covered in another use case titled Upload Tone). When setting the alarm, they must also specify the frequency of the alarm (i.e. daily, weekdays only, weekend only, only once referred to as the alarm repeater setting). Before allowing the user to complete the alarm setup, the clock radio asks the user to confirm all of the settings they have made they can choose to accept the settings or cancel the alarm. If the user accepts the settings, then the alarm is created otherwise the settings are discarded and the clock returns to the stand-by / unattended mode. 3. Please capture the logic for a customer to purchase movie ticket(s) from the XYZ Ticket Kiosk. The customer starts the transaction by clicking on the Purchase Tickets option on the systems screen. The system will then prompt the customer to choose the movie they want to see from a list, after this selection, the system will display the allowable (future) times and have the customer make a choice. Finally, the system prompts the customer for the number of tickets they wish to purchase (the system will not allow the user to select any less than 1 ticket). Note that this movie ticket purchasing system has knowledge of how many seats are in the theater and how many tickets have previously been sold for each performance of the movie so it needs to detect and handle the fact that a customers request may not be allowed to be fulfilled. If the customer has requested more tickets than what is left for that movie showing, the system informs them and asks them to restart the whole process FILE NAMING REQUIREMENTS SUBMISSION REQUIREMENTS over (to pick another movie) or cancel. The movie ticket purchasing system also presents the customer with an optional ability to purchase snacks and drinks (covered in another use case titled Purchase Snacks). Before the ticket purchasing system prints the movie and snack tickets for the customer, they need to review their order. At this point, they can either accept the order and pay (covered in another use case titled Pay for Snacks and Tickets) or cancel the order. If the Ticket Kiosk has run out of paper, the Kiosk alerts a staff member and waits for more paper.