EXPERIMENT-2

AIM:Understanding a SRS(Software Requirement Specification) for Bank Management System.

REQUIREMENTS:
HARDWARE REQUIREMENTS:
➢ Standard PC
➢ Internet connection with good enough speed.
➢ ATM
➢ Pentium IV 1.7 GHz class or better processor.
➢ 128 MB or more RAM(256 MB recommended).
➢ Atleast 500 MB hardisk space.
➢ Smartphone
SOFTWARE REQUIREMENTS:
➢ Use any operating system for devloping this product.
➢ Front End: Java
➢ Back End:My Sql
➢ Web Browser:Microsoft Internet Explorer,Mozilla or Google Chrome.
THEORY:
A software requirements specification(SRS) is a detailed description of a software system to be developed with its
functional and non-functional requirements. The SRS is developed based the agreement between customer and
contractors. It may include the use cases of how user is going to interact with software system. The software
requirement specification document consistent of all necessary requirements required for project development. To
develop the software system we should have clear understanding of Software system. To achieve this we need to
continuous communication with customers to gather all requirements.
A good SRS defines the how Software System will interact with all internal modules, hardware, communication with
other programs and human user interactions with wide range of real life scenarios. Using the Software requirements
specification (SRS) document on QA lead, managers creates test plan. It is very important that testers must be cleared
with every detail specified in this document in order to avoid faults in test cases and its expected results.

SOFTWARE REQUIREMENT SPECIFICATION:

Index:
1. Introduction.
1.1. Purpose.
1.2. Scope.
1.3. Definition & Abbreviation.
1.4. References.
2. General Description.
2.1. Product Perspective.
2.2. Functionalities.
 2.3. User Characteristics.
2.4. General Constraints.
2.5. Assumptions & Dependencies.
3. Specific Requirements.
3.1. Functional Requirements.
3.1.3. Process Specification.
3.2. External Interface Requirements.
3.2.1. User Interface.
2.2. Hardware Interface.

5.3.2.3. Software Interface.

5.3.2.4. Communication Interface.
5.3.3. Non Functional Requirements.
5.3.4. Other Requirements.
Software Quality Attributes.
5.4. Possible Product Evolution.
5.4.1. Credit Card Management.
5.4.2. Interface Evolution.
5.4.3. Technological Evolution

1)Introduction:
1.1 Purpose:
The purpose of this document is to present a detailed description of the Online Banking System. It will explain the
purpose and features of the system, the interfaces of the system, what the system will do, the constraints under which
it must operate and how the system will react to external stimuli. This document is intended for both the stakeholders
and the developers of the system and will be liable for the approval or disapproval of the project by the community of
the Bank.
1.2. Scope:
An online banking system will be applicable everywhere, where banking exists. It will be more efficient and easier
way to have a record on systems through which everyone can easily access it according to his rights as compared to
the traditional banking system. Every bank will prefer the online banking system instead of the traditional banking
system as it contains many useful features and fastest methods for the transactions.

1.3. Definitions and Abbreviations:

TERMS DEFINITION
SQL Server Structured Query Language for the database purpos.
Used to define procedures to store and retrieve data.

User A person who needs the system to do histask efficiently and effectively.
An account holder or bank’s website visitor.
Database Collection of all the information monitored by the system.
Credit Card Credit holding cards, Buy everything and pay from the credit cards. These
cards are of each bank and ensure that the person has an account and balance in
the specific bank of which he holds the card.
Account Teller Bank staff that provides information about an account to the user who
visits the bank branch physically.
Administrator A person that will be responsible for the addition and deletion of the staff
members from the general database of the system.
SRS A document that completely describes all of the functions of a proposed
system and the constraints under which it must operate. For example,
this document.
Stake Holders Any person with an interest in the project who isnot a developer.

2) General Descriptions:

2.1. Product Perspective:

Following is the context or origin of online banking system. Comparison b/w the
Tradition system and the new system can also be cleared through the system models. In
traditional system, customer should have to visit the Bank branch physically for the
transactions or some other task. It wastes time. After implementing the online banking
system customer will be able to connect to his account through the internet connection.
Time usage will be minimized, task will be done fast instead of waiting someone other to
complete his task.

2.2. Functionalities:

This software will have following functionalities

2.2.1. Online balance check and transaction information:

Customer will be able to check his balance online while sitting at home by accessing the
database of the bank using his/her password and account no. allotted him by the bank.

2.2.2. Save or view up to 1 year past history of transaction:

It will be easy for the customer to view or save his history transactions up to past 1year
transactions. It will provide him the opportunity to maintain his bank balance and needs.

2.2.3. Balance transfer:

This system will provide a path to the customer
of the bank to transfer his balance to other account in easy steps. A
small transfer fee will be applicable for this transaction.

2.2.4. Online record Entry:

Bank staff will input and maintain their record online. It will be easy and efficient for them to
serve more and more people in less time.

2.2.5. Online record search:

Bank staff will easily search a record and update it if needed. Transactions will be faster even
physically from the branch because it will be very easy for the bank staff to check the balance of
a specific person and update its record if necessary.

2.2.6. Online Billing Option:

Customers will be able to shop online and pay the bills from their account. A secure way will be
provided for the billing. Online shopping will provide them the easiest way to buy
and sell their items.

2.2.7. Check book Allotment:

If the customer’s checks have been completed, a new check book will be allotted to him.

2.3 User Characteristics:

There are various kinds of users for the product. Usually web
products are visited by various users for different reasons.
The users include :

2.3.1. Chancellor who will be acting as the controller and he will

have all the privileges of administrator.

2.3.2.All the persons who needs to perform banking.

2.4 General Constraints:

Some general constraints should be defined which will have a great part in the overall succession
of the online banking project.

2.4.1. Hardware Requirements:

As this system is an online Web-based application so a client server will be the most suitable
Organizational style for this system. Computer systems will be needed by each of the actor as
well as that user must be connected to the internet. So, concisely following hardware will be
needed.
1) Computer systems
2) Internet availability

2.4.2. Safety and Security:

This Project must be safe and secure because customers will directly contact their account
through the internet. Software will have to identify the valid customer according to his/her bank
details and password. So it is a difficult task to prevent the system by major disasters by
preventing the unauthorized access to the system.

2.5 Assumptions and Dependencies:

Following are the assumptions and dependencies which are related to this online banking project.
1) This project is a stand-alone project so it will not affect the system where it will be embedded.
2) This project is a web-based project while the staff was addict of using traditional methods of
data storage and retrieval so they will be trained a bit to jump to it.
3) This system will not depend on any other module. It will be a web-based so everyone will
independently contact it.
4) It is will not affect the environment at all.
5) Banks will feel free to adopt it because it will not be so much expensive.

3) Specific Requirements:

How the online banking will interact with the environment, what will be the functional and non-
functional requirement. These all the steps should be defined here for providing a powerful base
to the design phase. The design of the project will completely depend on the functional and non-
functional requirements. So these should be defined clearly and accurately for
the effectiveness.

3.1 Functional Requirements:

Following are the services which this system will provide. These are the facilities and functions
required by the customer.
a) Online balance check.
b) Online shopping opportunity.
c) Online data entry by the staff.
d) Updating the data.
e) Balance transfer.
f) Check book Allotment.

3.1.1) Process Specification:

All the process mentioned in the DFD are described as below.

Customer Login:
Each Customer will have its account Id and password. This page will require both of these
attributes for them to access their account.

Bank Features:
It isn’t sure that each visitor of the Bank’s website will be a customer. He/she would be a normal
visitor interested in reading the features bank provides. The website’s main page should provide
him the basic features and benefits of the bank to these types of users.

Order for an Account:

A new visitor the Bank’s website would be interested in opening a new account in the Bank. So
he must be provided an easy path to create a new account in the bank.

Fill the Form:

New comer should have to fill the form to register him/her self with the bank. After filling the
form, If the values inputted by the user were logical correct, his contact details will be sent to the
administration block else he will be asked to input the values again.

Welcome Page:
After a user will be login, he will provided an interface offering different tasks (Here this
interface will provide many of the functionalities, which the customer needs in the
software). He has to choose a task to carry on his work.

Staff Login:
On the Website main page, A staff login link will also be provided. Bank staff will use to input
their ID’s and passwords to access their account. Here the type of staff will also be recognized, if
he will be of administration block, he will be sent to the administration module else he will be
sent to the record management module.

Check the balance:

After logging in, if the user wants to check his balance he will have to click the balance check
link. It will tell him his current balance of the account through which he is logged in.

Transfer Balance:
If user wants to transfer his money to some other account, then this module will provide him this
opportunity. He will input the account details of the receiver. After this process, server will
check the balance of the user and if the transfer balance will be less than the account balance
then transfer will take place else he will be alarmed that he has lo balance.

Account detail teller:

If the user physically contacts the Bank branch then he will provide his account detail to the
management staff who will inform him about his account. User will be able to do every task
at the branch that he can do online from his home.

3.3) Non-Functional Requirements:

Those requirements which are not the functionalities of a system but are the characteristics of a
system are called the non-functionalities.
a) Conformance to specific standards
b) Performance constraints : This system must be fit according to the
performance . It should use less memory and will be easily
accessible by the user. Memory management should be done wisely
so that none of the memory part goes wasted.
c) Hardware limitations: It should be designed in such a way that cheap
hardware must be installed to access and use it effectively. It should be platform independent.
There should be no hardware limitations. In should be designed to work with the low
specification hardware so that it could easily work with the high specification hardware.
d) Maintainable: Each of the modules should be designed in such a way that a new module can
easily be integrated with it.
e) Reliable
f) Testable

3.4) Other Requirements:

Software Quality Attributes:

The Quality of the System is maintained in
such a way so that it can be very user friendly to all the users.
The software quality attributes are assumed as under:
a) Accurate and hence reliable.
b) Secured.
c) Fast speed.
d) Compatibility.

CONCLUSION:
The concept of SRS has been understood and SRS for Bank Management System has been made.