Functional Requirements of the ATM System

The main functional requirements of the ATM are described below:

System requirement: One of the major requirement will be establishing of parameters within the system for data storage and setting that can be used in the execution process.

No activity condition: In case, there is no valid cash card; the display will flash the in initial display.

Cashless ATM: In the deemed scenario, the acceptance of the card should be denied while the screen flashes an error message.

Authorization: Another notable requirement suggests that after the cash card mode is entered, a pin acceptance should be done so that the ATM can process the validity of the cash card.

Card acceptance: Readability of the bank code and serial number to ensure the validity of the card after which the card can be accepted by the ATM. In case, the card is not read within a timeframe of 5 seconds, the screen will flash a timeout error notification.

Serial Number reading: The code along with the recorded serial number should be registered with the system. The serial number on the card should be read efficiently by the machine.

Pin Request: On successful recognition of the cash card. A screen will be flashed asking for the card’s pin and only after validation of the pin, the system can be accessed.

Processing of Pin: Post processing of the entered pin, the screen will display a dialogue box citing whether the input response is positive or negative. If the response is identified negative, the user will be offered three chances to re-enter their pin after which the system will block the user by capturing the card.

Transaction Type: On validation of the pin the screen will display message after which the user can proceed with the transaction that will include options such as withdraw, deposit, transactions and others.

Post transaction: Post-transaction, the system will enquiry about the further step that will include continuation of the process or not. Additionally, printing of the receipt will also be enquired after which the process will be complete.

The non-functional requirements of the ATM system are described below:

• Scalability: The ATM should offer scalability that is it should be capable of withstanding harsh situations such as excessive load that can be resulted from increased number of users and provide cash to the users as long as it has ample cash.
• Flexibility: Another notable requirement of the ATM should be flexibility. The system should not be limited to withdrawal of the cash only; it should also offer options like, checking of last transactions, cash deposit, change of pin, applying for the bank account and similar others.
• UI ease: User Interface (UI) is one of the most desirable requirement for the ATM because it decides what comfort will the user enjoy while using the ATM. Hence, it is mandatory that the input and dialogue box displayed on the ATM’s screen is understandable and offers ease of use. The options should also be understandable and visible to the users.
• Usability ease: The ATM should also offer ease of usability to the users that is the actions should be responded effectively and efficiently. A tutorial for the first time users can be added to enhance understanding.
• Adaptability: The discussed system should also offer adaptability that is it should follow open system that can be volatile as per the circumstances. However, the adaptability should not compromise on the security of the system.
• Efficiency: Efficiency is one of the most required feature of the system and hence should be cited special attention. The users should receive adequate response to the input they have given to the system that and no option should be included in the system that is not capable of providing appropriate response.
• Compatibility: Another notable non-functional requirement of the system is compatibility. The discussed system should offer compatibility with the systems in existence to ensure that the users are comfortable with the system and can easily understand the purpose of the system. The data collected during account opening process at the banks should be applied to the deemed system while ensuring the compatibility.
• Security: Security is the most crucial requirement of the deemed system and should be strong enough to withstand undesired circumstances. The password protection does ensure the safety of the system to a limit, however, to enhance it to next level the connection between the ATM and bank (by electronics means) should be secured. Additional, appropriate care should be given to avoid stalkers when, user is entering the pin.

 

 The table provided below provides the description of the uses of the designed system:

Use Case	Brief Use Case Description
Insert Card	The system allows the user to insert the card into the system.
Card Recognition	The system should be able to provide the bank with option of recognizing the card.
Re-insert Card	The customer should be able to re-insert the card in to the system in case the recognition of the card fails for the first time.
Enter Pin	The customer should be able to enter the pin into the system.
Pin Verification	The ban king authorities should be provided with the option to recognize the pin verification and allow access to the customer. In the machine.
Re-enter Pin	The customer should be allowed to re-enter the pin in the system in case the customer enters wrong pin for the first time.
Authorize Account	The banking authorities should be allowed to authorize the account of the customer so that the customer can perform the actions required by him on the ATM machine.
View Options	The View option would enable the customer to view the different type of accounts that is Savings, Credit and Super Saver.
Select Account	The customer would be able to select the type of account the customer possesses.
View Main Menu	The customer is allowed to view the main menu of the ATM.
Transfer Money	The system provides the customer with the option to transfer money from their account.
Withdraw money	The customer is also provided with the option of withdrawing money from the ATM machine.
Check balance	The customer is also provided with the option to check their balance with the bank.
Deposit Money	The customer is provided with the option of depositing money to the system.
Print transaction History	The print transaction option of the system would allow the customer to view the transaction history of the customer.
Generate report	The banking authority is provided with the option to print the daily, weekly and monthly report from the system.

The use used for description in this section of the report is the use case of View main menu by the customer:

Use Case Name:	View Main Menu
Scenario:	View the main menu
Triggering Event:	The customer enters the system and views main menu.
Brief Description:	The customer is allowed to view the main menu of the ATM.
Actors:	Customer, The system
Related uses cases:	From the main menu the customer can view other use cases such as check balance and deposit money.
Stakeholders:	The other stakeholders related to this use case is the bank and the banking authority.
Precondition:	The precondition of the use case is select account. The customer has to select the account
Post condition:	The post condition of the use case is any of the five stages provided below: · Transfer Money · Withdraw money · Check balance · Deposit Money · Print transaction History
Flow of Activities	Actor	System
	1. Customer inserts the ATM card. 2. The customer enters the ATM Pin 3. The customer selects main menu	1. The system checks the ATM card 2. The system verifies the Pin 3. The system displays main menu
Exception condition:	1. The ATM Pin is not valid 2. The customer account is not valid

During the creation of the class diagram various assumptions were made as the provided conditions for the construction was not enough and hence, the assumptions helped in the development of the concept for the class diagram for the construction of the class diagram of the ATM system. The major assumptions made for the system includes the connection of the system to the bank and the bank keeping an account for the users of the ATM. It is assumed that the data of the Customers would be stored in the database of the bank and the ATM machine a=would be fetching the details of the customers from the bank of the user. With these assumptions in mind the construction of the class diagram of the ATM has been done.

Non-Functional Requirements of the ATM System

The Software Development Life Cycle includes the following six phases:

Requirement gathering and analysis: In this phase the analysis of the requirement are and the main requirements for the implementation of the system are identified.

Design: The design phase involves ideating the design of the system that is to be installed in to t he system.

Implementation: The implementation phase involves the implementation of the system involves the actualization of the design for the system that is to be adopted in the ATM.

Testing: The testing phase involves the testing of the system that has been implemented for installation in an ATM machine. The simulation need not be done in an actual ATM machine, it can also be done in a simulation tool.

Deployment: The deployment phase involves deploying the system into an actual ATM system.

Maintenance: After the deployment phase is over the machine is to be maintained regularly. The maintenance of the system would keep the machine from lagging or getting damaged at critical stages. 

ATMs (or Automated Teller Machines) are what are known as Alternative Delivery Channels.

• Alternative, because they are alternative to the human teller.
• Delivery because they are programmed to deliver a specific set of services, and
• Channel because in the banking world, all delivery mechanisms need a channel via which the delivery would be made.

 The application would be containing a front end which is to be connected to an internet connection. The ATM actually do not have any database connected to the machine but it uses the data obtained from banks via the internet.

 The user interface of the machine should be designed efficiently. The customer visiting the ATM counter should be able to perform their operation efficiently and should be guided efficiently.

 The data store in the ATM is not actually a database it is connected to the internet and obtains the data via the internet.

References

Ahmed, M. A., Butt, W. H., Ahsan, I., Anwar, M. W., Latin, M., & Azam, F. (2017, March). A Novel Natural Language Processing (NLP) Approach to Automatically Generate Conceptual Class Model from Initial Software Requirements. In International Conference on Information Science and Applications (pp. 476-484). Springer, Singapore.

Almorsy, M., Grundy, J., & Müller, I. (2016). An analysis of the cloud computing security problem. arXiv preprint arXiv:1609.01107.

Bello, S. I., Bello, R. O., Babatunde, A. O., Olugbebi, M., & Bello, B. O. (2017). A University Examination Web Application Based on Linear-Sequential Life Cycle Model.

Bertoncello, V., Possamai, O., Bortolozzi, F., & Vosgerau, D. S. (2017, April). A Model for the Development of Learning Objects Using Educational Design. In Proceedings of the 2017 International Conference on Information System and Data Mining (pp. 111-118). ACM.

Dennis, A., Wixom, B. H., & Tegarden, D. (2015). Systems analysis and design: An object-oriented approach with UML. John wiley & sons.

Dwarakanath, A., Chintala, U., Virdi, G., Kass, A., Chandran, A., Sengupta, S., & Paul, S. (2015, May). CrowdBuild: a methodology for enterprise software development using crowdsourcing. In Proceedings of the Second International Workshop on CrowdSourcing in Software Engineering (pp. 8-14). IEEE Press.

Elamin, R., & Osman, R. (2017, July). Towards Requirements Reuse by Implementing Traceability in Agile Development. In Computer Software and Applications Conference (COMPSAC), 2017 IEEE 41st Annual (Vol. 2, pp. 431-436). IEEE.

Gude, B. C., Kakumani, L. R., Phanindhar, S., & Singireddy, S. R. (2016). GSU Event Portal.

Johnston, S. K., & Nally, M. P. (2015). U.S. Patent No. 9,122,422. Washington, DC: U.S. Patent and Trademark Office.

Mall, R. (2014). Fundamentals of software engineering. PHI Learning Pvt. Ltd..

Mao, K., Capra, L., Harman, M., & Jia, Y. (2017). A survey of the use of crowdsourcing in software engineering. Journal of Systems and Software, 126, 57-84.

Misra, H. (2016). Managing User Capabilities in Information Systems Life Cycle: Conceptual Modeling. International Journal of Information Science and Management (IJISM), 15(1).

Mythily, M., Valarmathi, M. L., & Durai, C. A. D. (2018). Model transformation using logical prediction from sequence diagram: an experimental approach. Cluster Computing, 1-12.

Rodriguez-Martinez, L. C., Duran-Limon, H. A., Mendoza-González, R., & Muñoz, J. (2015). Identifying common activities in the graphical user interface development process and their integration into the software-system development life cycle. Computer Science and Information Systems, 12(1), 323-348.

Saeed, M. S., Sarwar, N., & Bilal, M. (2016, August). Efficient requirement engineering for small scale project by using UML. In Innovative Computing Technology (INTECH), 2016 Sixth International Conference on (pp. 662-666). IEEE.

Sah, A., Bhadula, S. J., Dumka, A., & Rawat, S. (2018). A Software Engineering Perspective for Development of Enterprise Applications. In Handbook of Research on Contemporary Perspectives on Web-Based Systems (pp. 1-23). IGI Global.