SOFTWARE

REQUIREMENTS
SPECIFICATION

For

ATM System

Prepared by:- H Bhargavi

Academic Year: 2023-2024

1. Introduction
1.1 Purpose
This document serves as a guide for developing an Automated Teller Machine(ATM)
system's software needs. The goal of the document is to develop a user-friendly environment
for handling financial transactions by defining the functional and non-functional requirements
as defined by the customer.
1.2 Document Conventions
 Entire document should be justified.
 Convention for Main title
Font face: Times New Roman
Font style: Bold
Font Size: 14
 Convention for Sub title
Font face: Times New Roman
Font style: Bold
Font Size: 12
 Convention for body
Font face: Times New Roman
Font Size: 12

1.3 Scope of Development Project

The manual banking system will be replaced by an internet-based application with the ATM
system. It is intended to give consumers a smooth and safe environment in which to transact
money, view account information, and utilize a range of banking services. The project scope
includes Unified Modeling Language (UML) and Entity Relationship (ER) diagrams used to
represent hardware and software interfaces.

1.4 Definitions, Acronyms and Abbreviations

•SQL: Structured Query Language
•ER: Entity Relationship
•UML: Unified Modeling Language
•IDE: Integrated Development Environment
•SRS: Software Requirements Specification
•ISBN: International Standard Book Number
•IEEE: Institute of Electrical and Electronics Engineers
•JAVA: Platform Independence

1.5 References
 Books
Software Requirements and Specifications: A Lexicon of Practice, Principles and
Prejudices (ACM Press) by Michael Jackson
Software Requirements (Microsoft) Second EditionBy Karl E. Wiegers
Software Engineering: A Practitioner’s Approach Fifth Edition By Roger S. Pressman
  Websites
http://www.slideshare.net/
http://ebookily.net/doc/srs-library-management-system
2. Overall Descriptions
2.1 Product Perspective
Use Case Diagram of ATM SYSTEM

Users and Administrators are the two primary user classes served by the ATM SYSTEM.
User are able to carry out standard operations like transfers, withdrawal, and balance inquiries.
Administration are also able to monitor transactions, adjust system parameters, and alter ATM
settings, keep an eye on transactions, and control system characteristic’s.

2.2 User Classes and Characteristics

Various services are offered by the system according to the user type (bank staff or
customers). With all the rights of an administrator, the Bank Staff will serve as the controller.
When using the ATM services, the customer may be an individual or a business entity.
Functions accessible to Bank Employees (Manager):
 Able to start a transaction on a client's behalf.
 Examine the history of transactions.
 Fill the ATM with cash.
 Verify the ATM's condition.
 Create transaction reports for ATMs.
 View every account and its information.
 Features that Clients can access:

 Check the balance that is available.

 Take money out of the ATM.
 Put money into the automated teller machine.
 Move money around in different accounts.
 Modify the PIN.
 Examine the history of transactions.
 Get a fresh ATM card

2.3 Operating Environment

The ATM system runs in a Windows environment and supports popular browsers such as Microsoft
Internet Explorer, Google Chrome and Mozilla Firefox. The hardware configuration includes at least a
dual-core Pentium processor, 40 GB of hard disk and 256 MB of RAM.
2.4 Assumptions and Dependencies
The assumptions are:-
 The system code is error-free.
 The system is user-friendly for all users.
 Information is securely stored in a database accessible by the website
The dependencies are:-
 Specific hardware and software requirements for system execution.
 Regular maintenance and updates for the system.
 Proper understanding of the system by end users.

2.5 Requirement
Software Configuration:
Front End: Java (developed using Java Runtime Environment, NetBeans 7.0.1)
Back End: Microsoft SQL Server
Operating System: Windows NT, Windows 98, Windows XP
Hardware Configuration:
Processor: Pentium Dual-core CPU
Hard Disk: 40GB RAM: 256 MB or more

2.6 Data Requirement

The inputs involve queries to the database, and outputs include solutions to queries. The
system should handle a variety of inputs related to account details, transaction requests, and
account information.

3. External Interface Requirement

3.1 GUI
The software offers a user-friendly graphical interface for both users and administrators, allowing
seamless operation for various tasks such as account management and transaction processing.

•Quick Transaction Reports:

 Users can view transaction reports, including withdrawals and deposits within specific time
frames.
•Verification and Search Facilities:
Provides stock verification and search options based on different transaction criteria.
•Customizable Interface:
Administrators have the flexibility to customize the user interface based on system requirements.
•Consistent Design:
All modules integrated into the software adhere to a standardized graphical user interface design.
•Simplified Design:
The design is kept simple, ensuring an easy-to-navigate experience for users and administrators.
•User Management Interaction:
The user interface seamlessly interacts with the user management module, facilitating efficient
account management.
•Login/Logout Module:
A dedicated section in the interface handles user login and logout functionalities.
•Login Interface:
Users can log in by entering their credentials (username and password).
New users can register by providing necessary details.
Incorrect entries prompt an error message for correction.
•Transaction Search:
Users can search for specific transactions by entering relevant details.
•Account Overview:
Provides users with an overview of their account details, including balance and recent
transactions.
•Administrator's Control Panel:
Administrators can add/remove users, manage system settings, and oversee transaction options.

4. System Features
The system should ensure user authentication, secure transaction processing, and efficient account
management. Features include:
•User Authentication: Validate users through account number and PIN.
•Transaction Processing: Allow cash withdrawals, balance inquiries, and fund transfers.
•Account Management: Enable users to reset PINs and manage account details.
•System Configuration: Provide administrators with tools to configure ATM settings.
Other Non-functional Requirements
4.1 Performance Requirement
The upcoming ATM system will serve as the primary performance tool across multiple locations,
catering to both university staff and students. The database is expected to fulfill all university-
specified requirements.
•Fast and Accurate System Performance:
The system must deliver swift and precise performance, ensuring timely completion of
transactions.
•Error Handling and Prevention:
The ATM system should be equipped to manage both expected and unexpected errors effectively.
Built-in error testing mechanisms will identify and address issues promptly, preventing data loss
 and minimizing downtime.
•Capacity to Handle Large Data Volumes:
The system must efficiently manage a substantial amount of data, accommodating a high number
of users and transactions without encountering faults. This includes processing a large volume of
transactions seamlessly.
•Reliability Across Multiple Campuses:
The ATM system is expected to maintain reliability across various university campuses, ensuring
consistent and uninterrupted service for users at different locations.
•Security Measures:
Robust security protocols should be in place to protect sensitive user data, preventing
unauthorized access and ensuring the integrity of financial transactions.
•Scalability:
The system should be scalable to adapt to the growing user base and evolving technology
requirements, ensuring a sustainable and effective solution.

4.2 Safety Requirement

•Frequent backups of databases to guard against data loss.
•Uninterrupted Power Supply (UPS/inverter) to maintain functionality even in the event of a
power outage.

4.3 Security Requirement

• Making use of a safe database.
• Restricted rights for typical users.
• Distinct access restrictions for different kinds of users.
• Sturdy password security and user authentication.
• The ability to update databases only with admin access.
4.4 Requirement attributes
• Support for numerous administrators with the ability to modify the system.
• An open-source initiative to foster community cooperation.
• An easy-to-use database layout.
• Simple installation and download for the benefit of the user.
4.5 Business Rules
• Adherence by users to rules and policies of the system.
• Taking into account project expenses and promotional offers.
• The avoidance of illicit activity and respect for established procedures.

4.6 User Requirement

The main users of the ATM system are administrators and members.
Administrator Facilities:
Administrators have access to all necessary features, such as data security backup procedures.
•Techniques for recovering passwords to aid users.
•Data migration tools help speed up the registration process for users.
•Data replication to prevent data loss and provide redundancy.
•Characteristics for auto-recovery to ensure system stability.
•Options for file upkeep to ensure effective organization.
•Updates to the server often to guarantee peak performance.
5.Other Requirements
5.1 Data and Category Requirement
Access rights will differ between different user types (e.g., bank staff, administrators, and
customers). When it comes to data, only the administrators have retrieval rights, whereas bank
staff has the ability to initiate transactions, and administrators have the ability to add, remove,
and edit data.
Different transaction types should be shown, together with the pertinent data for each, using
distinct coding.
For instance:
Withdrawal Transaction:
Pertinent Data: Amount, Account Type
Deposit Transaction:
Pertinent Data: Amount, Account Type
Fund Transfer Transaction:
Pertinent Data: Amount, Source Account, Destination Account
PIN Change Transaction:
Pertinent Data: New PIN
Balance Inquiry Transaction:
Pertinent Data: Account Type
Each transaction type will have its unique set of data requirements and coding for proper
execution and logging within the ATM system.
5.2 Appendix
A: Administration, Abbreviation, Acronym, Assumptions, ATM
B: Banking, Business Regulations
C: Class, Customer, Customs Information Needs Reliances
G: Graphical User Interface (GUI)
K: Key
M: Member
N: Non-functional Need
O: Environment of Operation (O)
P: Perspective, Performance and Goals
R: Requirement and its Characteristics (R)
S: System Features, Safety, Scope, Security
U: User, User Need, User Class and Attributes

5.3 Glossary
Administrator: A user with administrative privileges is represented by their login ID.
User: Most users are assigned a general login ID.
Client: The ATM system's intended consumers.
SQL: Structured Query Language, used to retrieve data from databases.
SQL Server: A server that keeps data organized for storage.
Layer: Represents a portion of the undertaking.
User Interface Layer: The area that deals with direct user interaction.
Application Logic Layer: A section that describes the Web Server used to do calculations.
Data Storage Layer: The area in which all data is kept on file.
Use Case: High-level diagram providing a fundamental synopsis.
Class Diagram: A static structure diagram that shows the system's organization.
Interface: A tool for cross-media communication.
Unique Key: Used to distinguish between entries in a database.

5.4 Class Diagram

Classes:
User Data:
Attributes: Name, PIN, and User ID
Techniques: Verify Credentials ()
ATM
Methods: Send Transaction Request (), Display Error ()
Attributes: ATM_ID, Location
Transaction
Methods: Process Transaction (), Generate Receipt ();
Attributes: Transaction ID, Type, Amount
Banking System
Methods: Update Balance (), Record Transaction ()
Connections:
Association: The person uses the ATM.
o Request is sent to Transaction by ATM.
o The banking system is contacted by the transaction.
Aggregation: An ATM's transaction component.
Generalization: An Account Holder's general counterpart is the User.
5.5 Sequence Diagram
 Start the Transaction:
•A transaction is started by the user engaging with the ATM.
•The Transaction class receives a request from the ATM.
 Verify the User:
•Through communication with the User class, the Transaction class confirms user credentials.
•Proceed if it is valid; if not, alert the ATM to display an error.
•Choose a Transaction Type.
•The user chooses the type of transaction (balance inquiry, withdrawal, etc.).
•The selected transaction is sent to the Transaction class by the ATM.
 Procedure for Transaction:
•The requested transaction is handled by the Transaction class.
•There are interactions with other pertinent classes (like the banking system).
•Revisions are returned to the ATM.
 Create a Receipt:
•The receipt is produced by the Transaction class.
•The receipt is shown to the user by the ATM.
 Final Transaction:
•The transaction process is completed by the ATM.