Internet Banking System: Crusaderz

Internet Banking System Software Requirements Specification Crusaderz
Version 1.0 9th December 2010
CRUSADERZ
INTERNET BANKING SYSTEM
Software Requirements Specification Version 1.0
Team Name : Crusaderz Team Guide : Ancy Zachariah Members : Shobhit Kumar Tiwari Shekhar Kumar College Name : School Of Engineering, CUSAT Department : Computer Science & Engineering State : Kerala
CRUSADERZ/School Of Engineering,Kerala
Revision History
Date 09/12/2010 Version 1.0 Description Synopsis Author Crusaderz
Table of Contents
Description 1.0 Introduction 1.1 Purpose 1.2 Scope 1.3 Definition, Acronyms, and Abbreviations 1.4 References 1.5 Technologies to be used 1.6 Overview 2.0 Overall Description 2.1 Product Perspective 2.2 Software Interface 2.3 Hardware Interface 2.4 Product Function 2.5 User Characteristics 2.6 Constraints 2.7 Use Case Model Survey 8 9 9 10 10 10 11 5 5 6 7 7 8 Page No
2.8 Class Diagram 2.9 Sequence Diagrams 2.10 Activity Diagram 2.11 Database Design 2.12 Assumptions and Dependencies 3.0 Specific Requirements 3.1 Use Case Reports 3.2 Supplementary Requirements
12 13 18 19 20
20 25
Software Requirement Specification

1.0 Introduction 1.1 Purpose The purpose of this project is to develop an online comprehensive solution to manage Internet banking. This system will be accessible to users such as general customers, industrialists, entrepreneurs, organizations, academicians who have valid user-id and password. 1.2 Scope Customers are provided with a valid user-id and password to login. This system will provide the facility to lock the account if a wrong password is entered thrice in succession. Also, a warning regarding account locking will be given to the customer when an invalid password is entered. Maintain a centralized database to provide security to information which can be accessed only by the admin. End user logs in the system to view details of his various accounts in the bank. Users can transfer funds to accounts in the same bank. User is provided with a transaction password which is different from the login password. The system should display a notification in case of success of transaction and proper message should be given to the user in case of failure informing as to why it failed. System provides the facility to print statement and view last n transactions.
1.3
User can also request for cheque book or change of address. End user can stop payment of cheques issued by him. Definitions, acronyms and abbreviations HTML (Hyper Text Markup Language): It is used to create static web pages. JSP (Java Server Pages): It is used to create dynamic web content. J2EE (Java 2 Enterprise Edition): It is a programming platform, belonging to the Java platform, which is used for developing and running distributed java applications. WASCE (Web Sphere Application Server Community Edition): It is an application server that runs and supports the J2EE and the web service applications. WSAD (Web Sphere Studio Application Developer ): It is a designer toolkit which is designed to develop more complex projects by providing a complete dynamic web service. DB2 (IBM Database 2): It is a database management system that provides a flexible and efficient database platform to raise a strong "on demand" business applications. HTTP (Hyper Text Transfer Protocol): It is a transaction oriented client/ server protocol between a web browser and a web server. XML (Extensible Markup Language): It is a markup language that was designed to transport and store data. Ajax (Asynchronous Java Script and XML): It is a technique used in java script to create dynamic web pages. Web 2.0: It is commonly associated with web applications which facilitate interactive information sharing,
1.4
1.5
Inter-operability, user-centered design and collaboration on the World Wide Web. HTTPS: Secure Hypertext Transfer Protocol is a HTTP over SSL (secure socket layer). TCP/IP: Transmission Control Protocol/Internet Protocol, the suite of communication protocols used to connect hosts on the Internet. TCP/IP uses several protocols, the two main ones being TCP and IP. Java script: It is a scripting language used for client side web development. Admin: Administrator, he is the controller of all the users of the system and maintains the database. Corporate: It is used as a common term for industrialists, entrepreneurs, organizations, academicians etc. Customers: These are the general end-users. Statement: It is a document listing the various transactions along with date of transaction. References Problem definition (provided by TGMC,IBM) IEEE SRS format Fundamentals Of Database Systems, Fifth Edition By Ramez Elmasri and Shamkant B. Navathe Technologies To Be Used HTML JavaScript JSP DB2,Rational Rose Ajax RAD/WAS Servelets
1.6
Overview The SRS will include two sections, namely: Overall Description: This section will describe major components of the system, interconnections, and external interfaces. Specific Requirements: This section will describe the functions of the actors, their role in the system and the constraints faced by the system.
2.0
Overall Description 2.1 Product Perspective The web pages (XHTML/JSP) are present to provide the user interface on client side. Communication between client and server is provided through HTTP/HTTPS protocols. The Client Software is to provide the user interface on system user client side and for this TCP/IP protocols are used. On the server side web server is for EJB and database server is for storing the information.
2.2
Software Interface Client on Internet: Web Browser, Operating System (any) Client on Intranet: Client Software, Web Browser, Operating System (any) Web Server: WAS, Operating System (any) Data Base Server: DB2, Operating System (any) Development End: RAD (J2EE, Java, Java Bean, Servlets, JSP, EJB), DB2, Linux, Web Server.
2.3
Hardware Interface Minimum hardware requirement: Client Side Internet Explorer Processor 6.0 and above, Mozilla Firefox, Pentium III at 500MHz Google chrome Server Side Web Sphere Application Server DB2 Pentium IV at 1.3GHz 512MB 2GB
RAM 128MB
Disk Space 1GB
Pentium IV at 1.3GHz
512MB
1GB (Excluding data size)
2.4
Product Function The Internet banking system consists of following modules : 1) Login Process: This module allows valid customers to access the functionalities provided by the bank. 2) Balance Enquiry: This module maintains the balance details of a particular account. 3) Update Profile: This module allows the customer to update profile of their account. 4) Funds Transfer: This module allows the customers to transfer funds from one account to another within the same bank. 5) Change of Password: This module allows customers to change their password. 6) Mini Statements: This module allows customers to view their transaction details. User Characteristics Every user should be comfortable of working with computer and net browsing. He must have basic knowledge of English too.
2.5
2.6
Constraints GUI is only in English. Login and password is used for identification of customers account and there is no facility for guest. Limited to HTTP/HTTPS.
10
2.7
Use Case Model Survey
Log In
Manage Users
Help & FAQs Maintains Database Administrator
Balance Enquiry Maintain Portal
Fund Transfer
Adding FAQs
Request Cheque Book
Customer
Stop Payment Of Cheques Corporate
View Monthly/ Annual Statements
View 'n' Transactions
Change Password
Request Address Change
11
2.8
Class Diagram
12
2.9
Sequence Diagram Normal Flow of Events For Balance Enquiry:
/ cUSTOMERR1 : CUSTOMER
/ aCCOUNTR1 : ACCOUNT
Account database
/ customerR1 : Customer 1: login() 1.1: show_balance() 1.1.1: Ac_no
1.1.1.1: Balance
1.1.2: return 1.2: return
13
Normal Flow of Events for change of Address:
/ cUSTOMERR3 : CUSTOMER
Database
/ customerR7 : Customer
/ administratorR2 : Administrator
1: Request address change 1.1: change_address() 1.1.1: update address
1.1.1.1: updated 1.1.2: return 1.2: return
14
Normal Flow of Events For Fund Transfer:
/ aCCOUNTR2 : ACCOUNT 1: trans_login() / customerR2 : Customer
Customer database
1.1: verify_transpswd
1.1.1: cofirm_login 1.2: loggedin 2: fund_transfer() 2.1: chk_balance
2.1.1: balanceAvailable 2.2: update_balance
2.2.1: confirm_transfer
2.3: transfer_success
15
Normal Flow of Events for Monthly/Annual Statements:
/ tRANSACT ION_DETAILSR1 ... : T RANSACT ION_DET AILS ...
Ac count_database
/ c ustomerR3 : Customer 1: create_statement()
1.1: get_statementdetails 1.1.1: statement_details
1.2: generate_statement
Normal Flow of Events for request cheque book:
/ aCCOUNTR3 : ACCOUNT
/ c ustomerR6 : Customer
/ administratorR1 : Administrator
1: Request c heque book 1.1: issuechequebook ()
1.1.1: issue c heque book 1.2: cheque book issued
16
Normal Flow of Events for Stop Payment of Cheques:
/ cHEQUER1 : CHEQUE
database
/ customerR5 : Customer 1: stop_payment() 1.1: stop_check
1.1.1: stopped
1.2: return
17
2.10 Activity Diagram
18
2.11 Database Design E-R Diagram:
19
2.12 Assumptions and Dependencies The details of customers such as username, password, account type and their corresponding authority details should be manually entered by the administrator before using this system. The end user should have the basic knowledge of English and computer usage. Administrator is created in the system already.
3.0
Specific Requirements 3.1 Use Case Reports ADMINISTRATOR: Responsible for managing system users, viewing logs and managing standard groups of the system. Manage Users: The administrator will add new users to the system, remove a user, authorize change of address and issue cheque books. Maintains database: The administrator is responsible for data backup, data recovery, as well as authorizing access to the database. Adding FAQs: Admin helps to clear the doubts of citizens in this section by creating some frequently asked questions and its corresponding answers. Manage Users Name of the use case: Add new user Description: The administrator provides log-in details and permissions after verifying the documents of the user. Pre-conditions: Administrator is already logged in and all the required documents and the identification had been verified.
20
Normal flow of events: 1) Log in, password and permissions are entered by the admin. 2) Save the details. Alternate flow of events: 1) A message appears for duplicate log in message. 2) The admin has to fill the details again. Post-conditions: A login id is generated with details. Name of the use case: Authorize change of address Description: The administrator authorizes the address change of the customer. Pre-conditions: Administrator is already logged in and the new address has been verified. Normal flow of events: 1) The administrator updates the address of the customer. 2) Save the new address. Post-conditions: The address is updated. Adding FAQs Name of the use case: Adding FAQs Description: Admin helps to clear the doubts of citizens in this section by creating some frequently asked questions and its corresponding answers. Pre-conditions: Administrator is already logged in. Normal flow of events: Admin adds FAQs in the portal to help the customers.
21
CUSTOMER: Ordinary customers have a user name & password with which they can login into their account. They can perform all the transactions such as funds transfer, balance enquiry, cheque book request, etc. by sitting at their home on internet. Name of use case: Login Description: The customer enters a valid user-id and password to log-in. Pre-condition: The customer has already been added to the system. Normal flow of events: 1.) The user enters correct user name and password. 2.) The user is logged in. Alternate flow of events: 1.) The user enters incorrect details. 2.) An error message is displayed asking the user to re-enter correct details. Post-condition: None Name of use case: Balance enquiry Description: The user can view the current balance in one of his accounts. Pre-condition: The user is already logged in. Normal flow of events: 1.) The account for which the balance is to be viewed is selected. 2.) The current balance of the account is displayed. Post-condition: None.
22
Name of the use case: Fund Transfer Description: The customer can transfer funds to an account in the same bank. Pre-condition: The user is already logged in. Normal flow of events: 1.) The user selects one of his accounts. 2.) The account number of the destination account is entered along with the amount. 3.) The user enters the transaction password. 4.) Transfer of funds is carried out. Alternate flow of events: 1.) The destination account no. is wrong or the customer does not have sufficient balance in his account. 2.) Appropriate error message is displayed. Post-condition: The transaction has terminated. Name of use case: Request cheque-book Description: The customer can request new cheque book. Pre-condition: The user is already logged in. Normal flow of events: 1.) The user selects an account. 2.) The user requests a new cheque book. Post-condition: None Name of use case: Stop payment of cheques. Description: The customer can stop payment of cheque issued by him if it has not been encashment yet. Pre-condition: The user is already logged in. Normal flow of events: 1.) The customer selects an account.
23
2.) The details of the cheque that has to be stopped is entered. Post-condition: None. Name of use case: View monthly/annual statement Description: The user can view monthly and annual statements for his account. Pre-condition: The customer is already logged in. Normal flow of events: 1.) The user selects one of his accounts. 2.) The period for which the statement to be generated is entered. 3.) The statement is generated in pdf or xls format. Post-condition: None. Name of use case: Change password Description: The user can change his password. Pre-condition: The customer is already logged in. Normal flow of events: 1.) The user is asked to enter the old password. 2.) The new password is entered by user. Post-condition: The user profile is successfully updated. Name of use case: Request change of address. Description: The user can request change of his address. Pre-condition: The user is already logged in. Normal flow of events: 1.) The user enters the new address and requests for its updating. Post-condition: None.
24
3.2
Supplementary Requirements 1.) As it is a financial system proper steps must be taken to ensure security of confidential user data. SSL should be used. 2.) 365X24X7 availability. 3.) The system should be designed and tested to ensure optimal performance even under stress for example during peak hours. 4.) Flexible service based architecture will be highly desirable for future extension.
25
26

Internet Banking System: Crusaderz

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Internet Banking System: Crusaderz

Uploaded by

Copyright:

Available Formats

Internet Banking System Software Requirements Specification Crusaderz

Version 1.0 9th December 2010

Internet Banking System Software Requirements Specification Crusaderz

Version 1.0 9th December 2010

Internet Banking System Software Requirements Specification Crusaderz

Version 1.0 9th December 2010

Internet Banking System Software Requirements Specification Crusaderz

Version 1.0 9th December 2010

Internet Banking System Software Requirements Specification Crusaderz

Version 1.0 9th December 2010

Software Requirement Specification

Internet Banking System Software Requirements Specification Crusaderz

Version 1.0 9th December 2010

Internet Banking System Software Requirements Specification Crusaderz

Version 1.0 9th December 2010

Internet Banking System Software Requirements Specification Crusaderz

Version 1.0 9th December 2010

Internet Banking System Software Requirements Specification Crusaderz

Version 1.0 9th December 2010

Disk Space 1GB

1GB (Excluding data size)

Internet Banking System Software Requirements Specification Crusaderz

Version 1.0 9th December 2010

Internet Banking System Software Requirements Specification Crusaderz

Version 1.0 9th December 2010

Use Case Model Survey

Help & FAQs Maintains Database Administrator

Balance Enquiry Maintain Portal

Request Cheque Book

Stop Payment Of Cheques Corporate

View Monthly/ Annual Statements

View 'n' Transactions

Request Address Change

Internet Banking System Software Requirements Specification Crusaderz

Version 1.0 9th December 2010

Internet Banking System Software Requirements Specification Crusaderz

Version 1.0 9th December 2010

Sequence Diagram Normal Flow of Events For Balance Enquiry:

/ customerR1 : Customer 1: login() 1.1: show_balance() 1.1.1: Ac_no

1.1.2: return 1.2: return

Internet Banking System Software Requirements Specification Crusaderz

Version 1.0 9th December 2010

Normal Flow of Events for change of Address:

1: Request address change 1.1: change_address() 1.1.1: update address

1.1.1.1: updated 1.1.2: return 1.2: return

Internet Banking System Software Requirements Specification Crusaderz

Version 1.0 9th December 2010

Normal Flow of Events For Fund Transfer:

/ aCCOUNTR2 : ACCOUNT 1: trans_login() / customerR2 : Customer

1.1.1: cofirm_login 1.2: loggedin 2: fund_transfer() 2.1: chk_balance

2.1.1: balanceAvailable 2.2: update_balance

Internet Banking System Software Requirements Specification Crusaderz

Version 1.0 9th December 2010

Normal Flow of Events for Monthly/Annual Statements:

/ tRANSACT ION_DETAILSR1 ... : T RANSACT ION_DET AILS ...

/ c ustomerR3 : Customer 1: create_statement()

1.1: get_statementdetails 1.1.1: statement_details

Normal Flow of Events for request cheque book:

1: Request c heque book 1.1: issuechequebook ()

1.1.1: issue c heque book 1.2: cheque book issued

Internet Banking System Software Requirements Specification Crusaderz

Version 1.0 9th December 2010