CIS 210: Systems Analysis and Development November 3, 2013
A use case with typical and alternate courses that documents the event of a bank customer withdrawing money from an ATM. In this particular use-case scenario a system analysis will be identified when a bank customer interacts with an ATM to withdraw money. Typical and alternate courses will be identified. A use-case diagram will be used as a tool to provide clarification of the necessary components or processes including hardware, system software, process and human interaction to layout or plan and identify the various components necessary to produce the desired session outcome. Rouse (2007) describes the use-case methodology; “A use case is a methodology used in system analysis to identify, clarify, and organize system requirements. The use case is made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal. It consists of a group of elements (for example, classes and interfaces) that can be used together in a way that will have an effect larger than the sum of the separate elements combined. The use case should contain all system activities that have significance to the users. A use case can be thought of as a collection of possible scenarios related to a particular goal, indeed, the use case and goal are sometimes considered to be synonymous.” In this project a use case methodology will be used to illustrate the required elements to successfully plan and implement a system that will allow a user to make a withdrawal from their banking institution and have all the necessary components interact in such a way as to successfully track the transaction and allow the user to make the transaction without error. A typical course of action would be that the customer or account holder makes a withdrawal where there is sufficient funds and moves on their way. However, alternate courses in this scenario would be that there were insufficient funds, or the ATM machine was out of service or there was lack of money. Another alternate course is that the customer has exceeded their daily allowable limit. See the following diagram which illustrates the use-case scenarios:
[pic]
Describe a use case dependency for making an account deposit A use-case dependency for making an account deposit can be typically illustrated by simply having an account; or, by having a means available to make a deposit. Other use case dependencies would be simply having the funds available for making a deposit and the physical and system component functionality present to complete the transaction. Although the required systems appear available and in order doesn’t necessarily mean the various components are in actual working order. For example, there are multiple ways an actor can make a deposit at a bank. A user can transfer funds from a savings account to a checking account using a banking website. A user may also physically enter a banking facility and request assistance from a bank teller who would in turn require a computer that is tied to the bank software and connected database to complete the transaction. Or, for the hurried user, a deposit can be made from outside the facility at the ATM or the drive thru teller. The following illustration will depict a use case dependency model for making an account deposit using a bank clerk, Concept: Use case Model. (n.d.):”
[pic]”
Use case dependency for making an account transfer All use cases in this project share one thing in common in that they all must validate the customer before the session or transaction can be successful. In the next illustration a use-case dependency diagram will be illustrated for making an account transfer. In this scenario the customer will attempt a transfer of funds with the ATM. Before the ATM dispenses the cash, the customer must be validated using the bank’s database and ID verification and also by retrieving the customer’s account number. After verifying the customer’s identity, then the funds can be transferred into the other account. The ATM teller then submits an order to deposit the funds upon verification and the bank initiates the deposit. Use-case dependencies are best described by Concept: Use case Model. (n.d.); “A number of dependency types between use-cases are defined in UML. In particular, and . is used to include optional behavior from an extending use case in an extended use case. is used to include common behavior from an included use case into a base use case in order to support re-use of common behavior. The latter is the most widely used dependency and is useful for: 1.) Factoring out behavior from the base use case that is not necessary for the understanding of the primary purpose of the use case to simplify communications. 2.) Factoring out behavior that is in common for two or more use cases to maximize re-use, simplify maintenance and ensure consistency.” Please see the following use-case diagram illustrating the use-case dependency for making an account transfer:
[pic]
Explain at least one ethical issue that the use case exposes in connection with the development or use of the ATM system. One obvious ethical issue of this scenario is the possibility and probability of an unauthorized individual making an ATM withdrawal using the customer card. Even though the machine requires a security pin to access funds, it is not unheard of that ATM pins are acquired by third parties by whatever means possible; hacks, spying, stealing or even social engineering. What is to stop a burglar from hijacking someone and their card and forcing an individual to withdraw money at gunpoint or what if someone were hiding and suddenly came out of nowhere and took the cash during a withdrawal session. These issues need to be addressed and clearly there is no backup security that I have seen to remedy such threats. De Luca et al., (2010) explains the issue of ATM ethics thoroughly in a recent work abstract; “With the increase of automated teller machine (ATM) frauds, new authentication mechanisms are developed to overcome security problems of personal identification numbers (PIN). Those mechanisms are usually judged on speed, security, and memorability in comparison with traditional PIN entry systems. It remains unclear, however, what appropriate values for PIN-based ATM authentication actually are. We conducted a field study and two smaller follow-up studies on real-world ATM use, in order to provide both a better understanding of PIN-based ATM authentication, and on how alternative authentication methods can be compared and evaluated. Our results show that there is a big influence of contextual factors on security and performance in PIN-based ATM use. Such factors include distractions, physical hindrance, trust relationships, and memorability. From these findings, we draw several implications for the design of alternative ATM authentication systems, such as resilience to distraction and social compatibility.”
