Software Requirements Specification Version 1.1 February 5, 2012 BANKING MANAGEMENT SYSTEM Divij Bansal Nishad Farooqui B.

tech(CSE)

Table of Contents
Table of Contents.............................................................................................................................................ii 1.3. Glossary.................................................................................................................................................2 1.4. References..............................................................................................................................................3 1.5. Overview of Document..........................................................................................................................3 2.0. Overall Description....................................................................................................................................4 2.1 System Environment...............................................................................................................................4 2.2 Functional Requirements Specification..................................................................................................5 2.3 User Interface Specification...................................................................................................................5 2.4 Non-Functional Requirements................................................................................................................6 3.0. Problem Statement.....................................................................................................................................7 3.1.1 ZERO LEVEL DFD..............................................................................................................................11 EMPLOYEE...............................................................................................................................................11

Table of figures
Figure 1 System Design...................................................................................................................................4

ii

1.1

Purpose
The old way of maintaining details of a customer in a bank was to details and records them. Every time the user used to perform some transactions he has to go to bank, which may not be so easy. It may be a hard-hitting task for the users and the bankers too. The project gives real life understanding of Internet banking and activities performed by various roles in the supply chain. Here, we provide an automation for banking system through Internet. Internet banking system project captures activities performed by different roles in real life banking which provides enhanced techniques for maintaining the required information up-to-date, which results in efficiency. The project gives real life understanding of Internet banking and activities performed by various roles in the supply chain.

1.2

Scope
This Project investigates the entry threshold for providing a new transaction service channel via the real options approach, where the entry threshold is established by using an Internet banking system designed for the use of normal users(individuals), Industrialists, Entrepreneurs, Educational Institutions(Financial sections), Organizations and Academicians under transaction rate uncertainty.
Customer must have a valid User Id and password to login to the system If a wrong password is given thrice in succession, that account will be locked and the customer will not be able to use it. When an invalid password is entered a warning is given to the user that his account is going to get locked. After the valid user logs in he is shown the list of accounts he has with the bank. On selecting the desired account he is taken to a page which shows the present balance in that particular account number. User can request for the details of the last n number of transactions that he has A report can also be taken of this. performed.

SRS

date

User can make a funds transfer to another account in the same bank. User is provided with a transaction password which is different from the login password.

User can transfer funds from his account to any other account with this bank. If the transaction is successful a notification should appear to the customer, in case it is unsuccessful, a proper message should be given to the customer as to why it failed.

User can request for cheque book/change of address/stop payment of cheques User can view his monthly as well as annual statements. He can also take print out of the same. Generate reports at every section Administrator can take a back up of the database for every instance that is happening, periodically. All users are authenticated to avail the services FAQ section is also included for end users benefit.

1.3. Glossary Term Customer Product Handling team

Definition The person who has an account in the Bank The persons who see the complain assigned to him in his inbox and who sends the mail to the customer through the system with any clarification or solution. The person who sees all the complaint received and forward the complaint to product handling team An authorized employee of the bank who verifies the entire system and has entire control on the system

Product Administrator

System Administrator

SRS

date

1.4. References References for the project development were taken from the following books 1.) Software engineering by Robert Pressman 2.) IEEE standards for SRS document 1.5. Overview of Document The proposed system is partially automated process of sending request through the web based system. The complaints can be sent easily by the customer from anywhere. The services are given through the system are through the email.

SRS

date

2.0.Overall Description
The CMS encompasses numerous complaints from the customers, as well as files on the bank server system. This system will be completely web-based, linking to CMS and the remote web server from a standard web browser. An Internet connection is necessary to access the system.

2.1

System Environment

Figure 1 System Design

The CMS web site will be operated from the banks server. When a customer connects to the Banks web site, he can lodge complaints through emails which passes through banks servers. The Banks server will then interact with the Database engine , which allows the Windows type program to transfer data to and from a database.And then the complaint reaches the assigned employee of the concerned product.

SRS

date

2.2

Functional Requirements Specification Inputs: The major inputs for this application can be categorized module-wise. Basically all

the information is managed by the software and in order to access the information one has to produce their identity by entering the user-id and password. Every user has their own domain of access beyond which the access is dynamically refrained rather denied. Output: The major outputs of this system are user details and services of different departments. Links are created dynamically to meet the requirements on demand. This application must be able to produce output at different modules for different inputs. 2.3 User Interface Specification The entire user interface is planned to be developed in browser specific

environment with a touch of intranet based architecture. The browser specific components are designed by using the HTML standards.

SRS

date

2.4

Non-Functional Requirements

Performance Constraints 1) Requests should be processed within no time 2) Users should be authenticated for accessing the requested data Error Handling In case of user error, the system should display a meaningful error message to the user, such that the user can correct his error. Quality Issues While developing the proposed system the developer must be able to guarantee the reliability transactions so that they will be processed completely and accurately. Security Security and confidentiality are the top most concerns for the administrator. The proposed system should provide the following 1) Each customer should be provided with id and password for controlled access. 2) Access to database should be restricted to authorized persons only.

SRS

date

3.0. Problem Statement

The complaint system presently in any organization is just done on papers and due to which the complaints are not rectified and the problems are not rectified properly because the information gets lost as it is passed from department to department. To solve this problem this system has been proposed.

4.0. System
4.1. Current system Whenever a customer of the bank requires service from the bank he required moving to the bank and then he required to submit the complaint to the specified officer. The problem is written in paper and will be submitted at the bank. Then the manager will look after it and then he will take care about the customers problems. After that the manager will equire and allocate the problem to the specified person in that department. The person will equire the problem and then rectifies it. Drawbacks of the current system 1.) Wastage of time and cost due to travelling to the bank 2.) Complexity Increases 3.) Tough handling of more complaint 4.2. Proposed system The proposed system is partially automated process of sending request through the web based system. The complaints can be sent easily by the customer from anywhere. The services are given through the system are through the email. Advantages of the proposed system 1.) All the disadvantages in the current system are rectified 2.) It is very fast, secure and scalable system 3.) Time complexity decreases 4.) Useful for both the customer and the banker 5.) Makes tasks assignment very easy at the click of mouse.

5.0 Use Case Diagram

SRS 7 date

Use cases model the system from the end user point of view, with the following objectives: 1.) To define the functional and operational requirements of the system by defining a scenario of usage 2.) To provide a class and unambiguous description of how the end user and the system interact with one another 3.) To provide a basis of validation testing

Figure 2 : Use Case Diagram

5.1 Data Flow Diagram (DFD

SRS 8 date

Data flow diagrams have been used for many years prior to advent of computers. DFDs show the flow of data through a system. The system may be company, an organization, a set of procedures, a computer hardware system, a software system, or any combination of proceeding. The DFD is known as a data flow Graph or a bubble chart.

The following observations about DFDs are important: 1. All names should be unique. This makes it easier to refer to items in the DFD. 2. DFD is not a flow chart. Arrow in the flow chart represent the order of events; arrows in DFD represent flowing data. A DFD does not imply any order of events. 3. Suppress logical decisions. If we ever have the urge to draw a diamond shaped box in a DFD, Suppress that urge! A diamond shaped box is used in flow charts to represent decision points with shaped box is used in flow charts to represent decision points with multiple exit paths of which only one is taken. This implies an ordering of events, which makes no sense in a DFD. 4. Do not become bogged down with details. Defer error conditions and error handling until the end of the analysis.

SRS

date

Notations for DFDs are as follows:

Symbol

name

function

Data flow

used to connect processes Each other, the arrowhead Indicates direction of data flow

Process

Perform some transformation Of input data to yield output

Source/Destination A Source of system inputs or Sink of system outputs and Outputs to inputs. Data Store used to show the database

SRS

10

date

3.1.1 ZERO LEVEL DFD

CUSTOMER

Opens A/C
COMMERCIAL BANKING MAGT. SYSTEM

Employee
EMPLOYEE

LEVEL 0

3.1.2 LEVEL 1 DFD

SRS

11

date

Account Master Checks Opens A/C

1 Verify Introducers A/C

2.2 Withdraw Money Verification

ok

Do Transaction

A/C Open Account Master

2 Money Transaction

Update A/c Bal.

Transaction Transaction
2.1 Deposit Money 3 A/C Balance Updated

Detail Detail Transaction Master

SRS

12

date

Money

5.2 Entity Relationship Diagram

SRS

13

date