Money Withdrawal and Account Transfer Use Cases

Description

The use case under analysis describes the procedure concerning withdrawing money from a bank account by a customer. The relevant process implies four principal actors: the customer, the bank system, the service administrator, and the security administrator. The authenticate customer is an additional actor.

Among the necessary preconditions, one might point out the following terms: credit card possession, an active network connection to the relevant system, cash available for dispense, the available option of cash withdrawal.

The basic flow of the process might be put as follows:

1. The bank client inserts the card into the ATM card reader.
2. ATM session identifier is automatically allocated to monitor the potential errors and ensure the connection between the system and the bank.
3. The system authenticates the client.
4. The system displays available options.
5. The client selects a withdrawal option and indicates the targeted amount (the system might provide the most typical amounts for withdrawal).
6. The customer selects/indicates the necessary amount and confirms the procedure.
7. The system ejects the card.
8. The system dispenses the targeted amount.
9. The system records a transaction log.
10. The customer takes the money and the card; the use case ends.

Among alternative flows of the procedure, one might point out the following cases: requesting a non-standard amount, emergency card ejection, unreadable card, card jamming, invalid card, receipt request, an authentication failure.

The key requirement for the system’s efficiency implies dispensing the correct amount of cash in 99 cases out of 100. The relevant factor determines the cost-effectiveness of the suggested method. Thus, every dispensing error reduces the cost-effectiveness of the method significantly.

Among the potential risks that are likely to lead to financial losses, one might point out the following cases: dispensing a wrong amount of money, card damaging, or providing a wrong transitional log.

From an ethical perspective, the relevant process might imply some negative aspects. Specialists note that relevant procedures imply some non-confidential connotations. Hence, the people that stand in a line have an opportunity to see the details of the carried-out operation including the amount of money the customer withdraws (Shelly & Rosenblatt, 2003).

Use Case Dependency for Making an Account Deposit

The described use case might be equally employed for performing account deposits. The actors of the process, in this case, remain the same. Although the flow of the process will be slightly different:

1. The bank client inserts the card into the ATM card reader.
2. ATM session identifier is automatically allocated to monitor the potential errors and ensure the connection between the system and the bank.
3. The system authenticates the client.
4. The system displays available options.
5. The client selects the deposit option and indicates the targeted amount (the system might provide the most typical amounts for a deposit).
6. The customer selects/indicates the necessary amount and confirms the procedure.
7. The customer inserts the targeted amount
8. The system identifies the validity of the banknotes
9. The customer confirms the deposit procedure.
10. The system ejects the card.
11. The system records a transaction log.
12. The customer takes the card; the use case ends.

Among potential risks, one may point out the following cases: performing a deposition for an amount that exceeds the targeted sum and card damage.

The deposit function should be necessarily implemented because it is one of the most frequently required options. Moreover, it contributes to the circulation of the banknotes within the system (Bittner & Spence, 2003).

From the ethical point of view, the deposit operation performed with the help of the system described has a critical disadvantage. First and foremost, operating through an automatic deposit system requires specific knowledge. Thus, the client might experience particular difficulties in trying to complete the operation. As a result, extra assistance might be necessary to perform a withdrawal. Otherwise, a line of clients might appear creating extra psychological tension.

Involving a third party responsible for assisting is, meanwhile, undesirable as it is likely to result in extra costs that will reduce the cost-effectiveness of the system under analysis. According to experts, the most efficient solution is to create a multi-functional service that takes into account the maximal number of customers’ decisions and potential outcomes (Rosenblatt, 2013).

Use Case Dependency for Making an Account Transfer

The transfer procedure might be carried out by the same actors as in the withdrawal and deposit options. Thus, the flow of the process might be put as follows:

As one might note the described procedure follows the same pattern as the withdrawal operation. The major discrepancy resides in the identification of the targeted account. The relevant option requires careful consideration. The question arises, whether the system should identify the inserted account number and provide the data on the receiver to eliminate the possibility of indicating a wrong addressee.

Although the following option requires extra design and complicates the system’s structure, one recommends that the option of addressee’s identification is implemented as it is apt to improve the general performance of the system. Experts state that the primary task of the system design is the elimination of the risks of operation failure (Blokdijk, 2015).

The implementation of the described use case might require extra procedures:

1. Machine configuration.
2. System performance analysis.
3. Transaction logs reconciliation.

Reference List

Bittner, K. & Spence, I. (2003). Use Case Modeling. Boston, Massachusetts: Addison-Wesley Professional.

Blokdijk, G. (2015). Use Case – Simple Steps to Win, Insights and Opportunities for Maxing Out Success. Queensland, Australia: Emereo Publishing.

Rosenblatt, H.J. (2013). Systems Analysis and Design. Boston, Massachusetts: Cengage Learning.

Shelly, G. B. & Rosenblatt, H.J. (2003). Analysis and Design for Systems. Boston, Massachusetts: Course Technology Cengage Learning.