The Use Case of Withdrawal
The use case is depicting the associated activities related to the money withdrawal of a bank client from an ATM. Before withdrawing money from an ATM, certain conditions must be fulfilled; and the conditions are: the customer has an ATM card with him, the network connection of bank system is active, the ATM must contain a withdrawable amount of cash, and the ATM has an option for withdrawing money. When a person goes to an ATM booth to withdraw cash, the following events are most likely to happen.
First, the customer has to insert his/her bank card into the card reader of the ATM. Once the customer’s bank card is in the system, it distributes a session code as a reference for forthcoming uses for identifying system errors (if there are any), the code is synchronized with the bank system. The system reads the card information and then matches it with the pre-stored information in the system. Once the match is found, the system authenticates the customer by displaying a set of service options to the customer.
When the service options are available, the customer has to select the option “withdraw cash”. As the cash withdrawal button is pressed by the customer, the system displays a number of standard withdrawal amounts along with an option to input a customized amount. Then the customer selects an amount to withdraw and requests withdrawal pressing the confirmation button. Upon receipt of the withdrawal confirmation, the system matches the available cash with the requested amount, if the system finds sufficient cash to dispense, it starts performing the withdrawal.
The system discharges the customer’s card, and when the customer collects the bank card, the system then hands out the requested amount of cash to the customer. After that, the system distributes a receipt to the customer and creates a transaction log entry of the withdrawal. Under some specific situations, the above-mentioned use case might not work as stated, sometimes there could be a failure of the system. [See chart 1].
One of the alternate processes can be initiated in the customer authentication process. When the customer authentication process starts, the system validates the card information by communicating with the bank system through the internal network connection. Sometimes, the ATM fails to get connected with the bank server, and the system fails to substantiate the customer, and it ends the withdrawal request. Also, the system might fail to authenticate the customer due to an inactive bank card and an inactive account. In case of a stolen card, incorrect PIN, and invalid card information, the ATM confiscates the card and captures a ten seconds video of the person.
After that, the system informs the customer that the card has been confiscated, and he or she should contact their bank regarding this situation. The system creates an event log entry to keep the customer’s information and the captured images, and then resume to the basic flow. Functional failure of the ATM machine, apart from the fact the customer did not have enough funds in his/her account, or the ATM did not have enough cash to dispense, can end the withdrawal request.
The Use Case of Deposit
The deposit use case is slightly different from the withdrawal case, but some of the steps are essentially the same in the process. The customer must put the money that will be deposited into an envelope and write down the account name and amount on the envelope for later verification by the cashier. The process of deposit starts when the customer is identified with the basic process by inserting the basic required information the ATM, and the ATM displays different options to the customer, and the customer selects the deposit option.
The ATM asks for the account number and the amount that will be deposited into the account, and the customer has to fill the forms with the requested information. As soon as the information is entered, the ATM will request the customer to put all the money into an envelope and insert it into the “insert box”, once the customer inserts the envelope, the ATM prints a transaction ID on the envelope. The ATM system prints the deposit receipts and returns the bank card to the customer [See chart 2].
The deposit case could end with some alternative flow which is described here in the paper. When the customer inserts the money without an envelope, the ATM will print the transaction details on the first bill or note and rest of the note or bills will not be counted which is not a good thing at all, there must be a solution to the issue. Two or more envelopes would also create a similar problem like the first one, only one envelope would be counted and rest of the envelopes will not be counted which is an issue.
If no envelope is inserted at all then after a minute the basic case ends, and return to the beginning of the flow. When the inserted card information does not match with the account number that the customer has inserted, the bank consortium indicates it to the ATM system, and it shows an error message “wrong account information”. The customer has to start at the step where he/she had to enter the account details. The deposit system may fail if the connection to the cashier is lost and the use case ends.
The use case of Bank transfer
The system of ATM reads the card information and validates it. Then the ATM requires the PIN code from the customer when the customer enters the PIN code the system verifies it by communicating with the bank system. The next step starts when the ATM displays the available service options on the screen, and the customer selects “Fund Transfer” from the menu. The ATM then asks the customer to input the account number from which the fund will be transferred, which is followed by an input request of the account number to which the fund should be transferred, and finally, it asks the customer to input the amount that he/she is intended to transfer.
The bank customer enters all the requested information and confirms the transfer. As soon as the ATM receives the transfer instruction it sends a request to the bank consortium with the card ID, pin, amount, and account details; the consortium verifies the transaction and approves the transfer request. The ATM ejects the bank card and resends it back to the customer, it also prints a receipt of the fund transferring details. The use case ends here [See chart 3].
The fund transfer case can be failed through the alternative process in which the bank consortium fails to approve the transfer request due to insufficient funds, invalid bank card information, invalid PIN code, invalid account information, and the customer cancellation. The alternative process can also be initiated for technical errors among which card stuck in the card reader, power cut, network problem between ATM and bank consortium, and in the case of robbery. When alternative process initiated it eventually ends the process, and begin the flow again.
Ethical Issues with ATM Use Case
The development of ATM machine system is literally a critical issue and most importantly it deals with the financial assets of people. Due to the complexity of the system, some ethical issues should come into the consideration. The implication of use case can be seen only for ATM development which articulates how the customers or external users can use the system to withdraw, deposit, and transfer fund. Kamalrudin, Grundy, and Hosking (2010) asserted that the use case is a medium for assessing the requirement for creating a better system that makes sure the users and the customers are going through a dialogue with a transaction.
The use case has a good number of pitfalls and some of these pitfalls include some ethical issues as well. One of the biggest ethical issues is the security system. Although the system verifies the cardholder information still it cannot detect if the ATM user is the actual bank customer or not. Which implies someone else who knows the PIN and has access to the card of a bank can easily withdraw money from ATM.
Rajaraman (2011) mentioned in his book that many studies had found ATM as the source of stealing money from bank customers. Oko and Oruh (2012) mentioned about some fraudulent activities that are happening now a day; they mentioned ATM card theft, skimming, pin theft, card reader techniques, pin pad techniques, and force withdrawal are the most common security threat. It can be said that; these threats must be taken into consideration while using use cases for designing the ATM system development.
References
Kamalrudin, M., Grundy, J., & Hosking, J. (2010). Tool support for essential use cases to better capture software requirements. In Proceedings of the IEEE/ACM international conference on Automated software engineering (pp. 255-264). Antwerp, Belgium: ACM. Web.
Oko, S., & Oruh, J. (2012). Enhanced ATM security system using biometrics. International Journal of Computer Science Issues, 9(5), 355-363. Web.
Rajaraman, V. (2011). Analysis and design of information systems. New Delhi, India: PHI Learning Pvt. Ltd.