INSE 6260 SOFTWARE QUALITY ASSURANCE

BankOn ONLINE BANKING SYSTEM

Instructor

Prof. Rachida Dssouli

Group Members

Vivian Michael Gerard (6764061) Anshdeep Singh (6508308)

Table of Contents
1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations. 1.3 References 1.4 Overview 2. The Overall Description 2.1 Product Perspective 2.1.1 System Interfaces 2.1.2 Interfaces 2.1.3 Hardware Interfaces 2.1.4 Software Interfaces 2.1.5 Communications Interfaces 2.1.6 Memory Constraints 2.1.7 Operations 2.1.8 Site Adaptation Requirements 2.2 Product Functions 2.3 User Characteristics 2.4 Constraints 2.5 Assumptions and Dependencies 2.6 Apportioning of Requirements. 3. Specific Requirements 3.1 External Interfaces 3.1.1 Primary Actors 3.1.2 Secondary Actors 3.2 Use Case 3.2.1 Use case Diagram 3.2.2 Use case Description 3.3 Functions 2 4 4 4 4 5 5 5 5 6 6 6 7 7 7 7 7 7 8 8 8 8 9 9 9 9 9 9 11 21

3.4 Performance Requirements 3.5 Logical Database Requirements 3.6 Business Rules and Design Constraints 3.6.1 Standards Compliance 3.7 Software System Attributes 3.7.1 Reliability 3.7.2 Availability 3.7.3 Security 3.7.4 Maintainability 3.7.5 Portability 3.8 Organizing the Specific Requirements 3.8.1 System Mode 3.8.2 User Class 4. Change Management Process

21 21 22 24 24 24 24 25 25 25 26 26 26 27

1. Introduction
1.1 Purpose The Purpose of this System Requirement Specification (SRS) document is to give an overview of the system which is to be built and to collect requirements for developing an Online Banking System application. This document provides information on the various needs and features of the system in a high level of abstraction without getting into the design of application. The requirements of all stakeholders at different level interacting with the system are discussed comprehensively. SRS can also be used as a standard to assess the developed application. 1.2 Scope The scope of this document is to describe the functional and non-functional requirements of the online banking system BankOn in detail. BankOn is used by the customers of the bank XYZ to perform basic banking operations such as transfer funds, balance enquiry, view transaction history details, pay bills and to manage their own profile by updating their personal details. BankOn also offers investment options especially through Money Market Account (A type of savings account that offers a competitive rate of interest (real rate) in exchange for larger-than-normal deposits.) and Bonds. The system also serves the employees and administrator (manager) by providing features to manage employees, accounts, customers, various branches of the bank. Overall BankOn is to be designed as a user-friendly, secure and reliable system. 1.3 Definitions, Acronyms, and Abbreviations. SQLGUI SQASRSAPIJDKJREStructured Query Language for database purposes Graphical User Interface Software Quality Assurance System Requirement Specification Application Programming Interface Java Development Kit Java Runtime environment

User- A person who needs the system to do a task efficiently and effectively. An account holder or a banks website visitor Database- It is the collection of all the information monitored by the system Credit Card - These are the credit holding cards used to buy things by making payment through the cards. These cards are issued by the bank and ensure that the person has an account and requisite account balance in the bank.

Account Teller Bank staff that provides information about an account to the user who makes a visit to the bank branch. Bank features All the benefits and features provided by the bank. These will be explained to the customer when he/she visits the bank website without any account. Administrator A person who will be responsible for the addition and deletion of the staff members from the database. Software Requirement Specification A document that completely describes all of the functions of a proposed system and the constraints under which it must operate. Stakeholder Anyone who has an interest in the project. 1.4 References a. INSE6260, Dr.Rachida Dssouli, 2014, Concordia University; b. SRS,Dr.Rene Witte

1.5 Overview The SRS document contains the information required for designing and developing the online banking system in terms of functional and non-functional requirements. The SRS document is organized in different sections such as product perspective, product functions, user characteristics, constraints, assumptions and apportioning of requirements for the customers to understand .Also, specific requirements, design constraints, software system attributes, organizing the specific requirements in terms of system mode, user class, objects, features, stimulus and additional comments for the developers to comprehend and develop the system.

2. The Overall Description

This section provides the details on various factors that affect the application that is to be implemented and provides a pre-requisite for these requirements. 2.1 Product Perspective A number of banking websites are available online. Almost every bank has its online website for the customers to use. The online banking application which we are developing is a stand-alone product and is not a part or component of some larger system. The purpose of Bank On (this project) is to help the customer to perform normal banking through internet from his/her home operation along with Investment management relieving them of the burden to come to the bank in person within the working hours. 5

Block diagram for old banking system

Bank Branch

Account

Block diagram for new banking system

Online Banking BankOn

Account

2.1.1 System Interfaces Since the system developed is a dynamic Web project there are no external interfaces and with the help of local components/APIs the Bank On application will be developed. 2.1.2 Interfaces The application consists of a graphical user interface layer where the user can do various banking operations, business logic layer where the behavior of the system is set by the object oriented programming (JAVA) and a database layer which uses MySQL to store all the information that is related to the banking operations. 2.1.3 Hardware Interfaces There are no hardware interfaces present in the BankOn System to be developed.

2.1.4 Software Interfaces As mentioned earlier the components or layers are coupled locally and has no external interfaces. Anyhow Microsoft SQL Server 2014 is used and communication with the data stored is through database connections. 2.1.5 Communications Interfaces Except or a client browser to communicate to the application which is installed in the same/different system with a web server and an interface to the DB which is handled by database connection no special interfaces are needed. 2.1.6 Memory Constraints Minimum set of pre-requisites such as 512 MB RAM should be available for the efficient functioning of the software application. 2.1.7 Operations The application should be designed so that basic operations of banking and investment related options should be made available to the user. The BankOn system should be easy to understand and common mental/conceptual models that are used in the existing banking system should be incorporated. Security, reliability and portability should be efficiently added on to the system. Since the application developed is a banking system frequent backups/data base dumps should be taken regularly to avoid loss of data. 2.1.8 Site Adaptation Requirements There is no specific set of site requirements needed for the system to be developed. Data migration and compatibility of the system should be made efficient in the case of real time scenario. 2.2 Product Functions The objective this project is to deliver a working system to the client within the estimated time/effort, to satisfy all the requirements that are mentioned in the Software Requirements Specification and to subject the system to quality assurance techniques. The scope of the project includes implementing basic banking operations, management functions handled by the administrator or the manager, security features and investment related solutions.

Along with the functional requirement stated above care should also be taken to implement non- functional requirements such as efficiency and reliability of the system making sure that the application is stable 24/7, making sure that the system is secure by implementing proper authorization and authentication of the users who login into the system. Each type of user should be assigned a role and depending upon the role the abstraction of both the data and the business logic should be structured. 2.3 User Characteristics The typical bank customer will be a person, from the age of 12 and up there will be a fair distribution of males and females. The customer will probably use the banking system 2-3 times a week. The typical customer might not have good know-how of computers so the banking system has to be easy to use. The typically customer will probably be a busy person; therefore, they will need to do their transactions as quickly and efficiently as possible. The other user is a bank employee. The bank employee is a fairly educated user, who has good know-how of computers and is willing to learn about functionality. They will use the software daily, for every transaction. This could quite possibly be 40-50 transactions per hour per employee. Due to this frequency of usage stability and speed of this software is incredibly important. 2.4 Constraints 1. The banking system must be able to function on 512MB RAM machine for optimum performance. 2. In case of a power outage, there must be functionality for data back-up and recovery can be implemented in the future for a real time scenario. 3. The banking system should be reliable. 4. The banking system requires a database to store persistent data. 5. The development of the system will be constrained by the availability of required software such as web servers, database and development tools. 2.5 Assumptions and Dependencies 1. The workflow/process/functionality of the application should comply with the central bank regulation and also apply normal day-day banking practices. 2. The application should work 24/7 with no downtime and maintenance activity can be scheduled beforehand. 3. The project will be completed within the deadline provided the resources are available at their expected time and also the proper effort is put in. 2.6 Apportioning of Requirements. 1. A virtual keypad can be introduced in the banking system which will enable the user to enter the information quickly. 8

2. Additional security features can be added to enhance the security of the system. 3. Online chat applications to contact the bank representative for quick resolution of issues can be implemented. 4. Mobile banking facility thought an application which runs on mobile can also be evolved from the existing system.

3. Specific Requirements
This section contains all the software requirements at a level of detail sufficient to enable the designers to design a system to satisfy the requirements and testers to test the system from the perspective of the different stakeholders involved. 3.1 External Interfaces 3.1.1 Primary Actors 3.1.1.1 Client/Customers-Potential users who have accounts with the bank and use the services and products provided by the bank through the BankOn application. 3.1.1.2 Bank Employees-Type of users who use the system for maintaining the accounts and manage the client/customer requested services. 3.1.1.3 Administrator/Manager-The admin user is responsible to setting the business rules for example updating interest rates from time to time, managing the employees in the bank. 3.1.2 Secondary Actors In this application there are no external factors that are connected to the system. Usually systems like Tax calculator, interest report generator and other legacy systems are interfaced to the application and they are called as secondary actors.

3.2 Use Case 3.2.1 Use case Diagram

BankOn
Manage Customer Profile

Create a new service/account

Transfer Funds

Customer
Check balance & Transaction history

Deposit/Withdraw Amount

Administrator
Pay Bills/Deposit Cheque

Employee

Investments

Manage Employee

Approve cheques

10

3.2.2 Use case Description Use Case ID: Use Case Name: Actor(s): UC1 Login 1. Bank Customer 2.Employee 3.Adminstrator Its primary function is to ensure that the user is accessing their information and account and to ensure that no unauthorized user access the intended users account. A user provides a name/customer id and password. The system verifies the credentials and provides access to the system on successful authentication. The user is not logged into the system. The user is displayed with the user console. The system is kept secured from un authorized access. 1. System is at the welcome screen when user comes to the login Use-Case. The welcome screen has a sign in prompt. 2. The welcome screen will prompt the user for his / her account number and password. 3. The user enters his / her information 4. The information is validated against the bank database. 5. If the validation process returns true, then the user is granted access to the Banking System. 1. If the validation returns false, then the user is informed and the Banking returns to the welcome screen. 2. If the user enters their information incorrectly three times, then their account is locked and the Bank Officer must unlock the account before the user can use the system again. 3. Any time the user tries to access their account before it is unlocked they will receive a message telling them that their account is still locked.

Goal/Actor Goals:

Description/Sum mary: Preconditions: Post-conditions: Minimum Guarantee: Basic Flow:

Alternate Flow

11

Use Case ID: Use Case Name: Actor(s):

UC2 Reset password 1. Bank Customer 2.Employee 3.Adminstrator A user wants to reset his or her own password. A user will provide a valid email ID that is registered with the system to reset the password, the system then sends a temporary password to the users email. The user is not logged into the system. The user will receive an email containing the temporary password. The system is kept secured from un authorized access.
1. A user provides a valid email ID 2. The system verifies the email ID. 3. The system sends an email containing the temporary password to the respective email ID.

Goal/Actor Goals: Description/Sum mary: Preconditions: Post-conditions: Minimum Guarantee: Basic Flow:

Use Case ID: Use Case Name: Actor(s):

UC3 Logout 1. Bank Customer 2.Employee 3.Adminstrator A user wants to logout from the system. A user opts to logout from the system, after which the system terminates the access for that user. The user is logged into the system. User access is terminated by the system. The system is kept secured from un authorized access.
1. A user opts to logout from the system 2. The system terminates the access for that user. 3. The system redirects to the login prompt.

Goal/Actor Goals: Description/Sum mary: Preconditions: Post-conditions: Minimum Guarantee: Basic Flow:

12

Use Case ID: Use Case Name: Actor(s): Goal/Actor Goals: Description/Sum mary: Preconditions: Post-conditions: Basic Flow:

UC4 Create customer profile/account Prospective customer Employee The user wants to request a service from the bank A prospective client want to use a service/product and makes a request to the bank providing the necessary detail and the service he is interested in The user should not be an existing customer of the bank The customer profile is created successfully 1. The user initiates the request to use a service of the bank 2. The system responds by displaying the information to be completed by the customer. 3. The customer provides all the information that is requested by the system such as personal details, services interested, email ID, address proof upload/verification and submits the form. 4. The system validates the information given by the user. 5. If the validation is successful the system creates a customer profile and displays the unique id given to the user 6. The system also sends a welcome e-mail to the customer. 4.1 If the validation doesnt pass the user is requested to correct/complete the information needed by providing valid error messages.

Alternate flow:

Use Case ID: Use Case Name: Actor(s): Goal/Actor Goals: Preconditions:

UC5 Close services/account/profile Employee, Customer The user/employee requests the system to close the services. The account/service should be present in the bank. The balance should be non-negative and it should not contain any funds The closing should be done successfully. 1. The user requests the system to close the service/account/plan 13

Post-conditions: Basic Flow:

Alternate Flow:

that is provided. 2. The system or the employee makes sure that the account/service conforms to the business rules while before closing. 3. After proper validation from both the system and the employee the service is closed. 4. An email confirming the closing/de-activating of the service is given to the user and the records are removed from the database accordingly. 3. If the validation does not pass through the employee or the user has to do the required action that would result in the smooth closure of an account.

Use Case ID: Use Case Name: Actor(s):

UC6 Create an service/account 1. Bank Customer 2.Employee 3.Adminstrator The user want to create an account of his desired type so that he can manage transaction that occur in the bank There are different types of services that are provided by the bank such as student plan, savings account plan, chequing account plan, credit card. And depending on the customers preference the service is made available to the customer and business rule and the core logic is implemented. The user should not multiple account services of the same type. A user profile should be created beforehand. The requested service is created successfully 1. The user initiates the request for creation of a service/account/credit card/plan providing the customer id generated while creating his/her profile. 2. The system requests for a whole bunch of information from the user about his preferences. 14

Goal/Actor Goals: Description/Sum mary:

Preconditions: Post-conditions: Basic Flow:

3. The user responds by providing all the details. 4. The system then validates the information provided by the user and on successful validation it creates the service requested by the customer. 5. The system finally displays the account details/credit card information and details of the services. Alternate Flow: 4.1 If the validation doesnt pass the user is requested to correct/complete the information needed by providing valid error messages.

*The term services include the different types of saving account, chequing account, and credit account types. The use case remains almost same for all services but the business logic differs according the requirements of each service which can be added/removed at a late point. Use Case ID: Use Case Name: Actor(s): UC7 Deposit Money 1. Bank Customer 2.Employee 3.Adminstrator The user wants to deposit money in his account for doing transactions. The primary function is to allow the user to deposit money into an account by means of the banking System. The use should be an existing customer of the bank and should have an account id and a customer id Update the account balance of the customer appropriately by passing the unique account id 1. The user is presented with the main menu screen. 2. The user will request deposit option from the System by clicking on the deposit button of the main menu. 3. The user is presented with a screen that prompts the user for the account to where the money will be deposited and the amount of money to deposit. 4. The user enters the correct information and then clicks on the confirm button. 5. The Banking system sets updateBalanceNeeded on the users account. 6. The Banking system will prompt the user for another 15

Goal/Actor Goals: Description/Sum mary: Preconditions: Post-conditions: Basic Flow:

transaction. If the user input is yes then the Banking system will reset to main menu screen. If the user input is No then the system will logout the user and returns to the login screen.

Use Case ID: Use Case Name: Actor(s):

UC8 Withdraw Money 1. Bank Customer 2.Employee 3.Adminstrator The user requests to withdraw money from his account providing his account details /debit card which is linked to his/her account. The primary function is to allow the user to withdraw money from an account by means of the banking System. 1. The use should be an existing customer of the bank and should have an account id and a customer id. 2. The user should have sufficient balance so that the amount requested to be withdrawn should be lesser than the balance amount in case of a debit/savings/chequing account. Update the account balance of the customer appropriately by passing the unique account id 1. The user is presented with the main menu screen. 2. The user will request withdraw option from the System by clicking on the withdraw button of the main menu. 3. The user is presented with a screen that prompts the user for the account from where the money is to be withdrawn. 4. The user enters the correct information and then clicks on the confirm button. 5. The Banking system sets updateBalanceNeeded on the users account. 6. The Banking system will prompt the user for another transaction. If the user input is yes then the Banking system will reset to main menu screen. If the user input is No then the system will logout the user and return to the login screen.

Goal/Actor Goals: Description/Sum mary: Preconditions:

Post-conditions: Basic Flow:

16

Alternate Flow

4.1 In case the amount requested to be withdrawn is be greater than the balance amount proper error message stating Insufficient balance should be displayed by the system.

Use Case ID: Use Case Name: Actor(s):

UC9 Transfer funds 1. Bank Customer 2.Employee 3.Adminstrator The user requests to transfer funds from his/her account to another account providing the account details of the destination account. The Transfer Funds use-case for the customer is for the Banking System. Its primary function is to allow the user to transfer funds from one account to another. 1. The use should be an existing customer of the bank and should have an account id and a customer id. 2. The user should have sufficient balance so that the amount requested to be transferred should be lesser than the balance amount. Update the account balance of the customer appropriately by passing the unique account id 1. The user is presented with the main menu screen. 2. The user requests transfer funds from Banking system main menu screen. 3. The user selects the accounts for outgoing funds and incoming funds. 4. The user enters the dollar amount of funds to transfer. 5. The Banking system queries the bank server to validate fund transfers vs. account balances. 6. The Banking System queries the bank server to complete funds transfer. 7. The user is prompted for another transaction. If the user input is Yes then go to main menu screen. If the user input is No then go to login screen.

Goal/Actor Goals:

Description/Sum mary:

Preconditions:

Post-conditions: Basic Flow:

17

Alternate Flow

1. If the user doesnt have the necessary funds to complete a funds transfer then the user is notified. 2. The user is prompted for another transaction. If the user input is Yes then go to main menu screen. If the user input is No then go to login screen.

Use Case ID: Use Case Name: Actor(s):

UC10 Check Balance 1. Bank Customer 2.Employee 3.Adminstrator The user requests to check the available balance left in his account providing his account details /debit. The Check Balance use-case is on the Banking System. The primary purpose for this function is to allow the user to check the balance of their account at any system without having to go to the bank. 1. The use should be an existing customer of the bank and should have an account id and a customer id. 2. The user has logged into their account. The balance of the account is displayed successfully. 1. The user selects the Check Balance option from the main Banking Screen. 2. The user enters the account that they would like to know the balance of. 3. The Banking System runs the print function with the balance and account information on the slip. 4. The Another Transaction screen will appear and the user will select yes to return to the main Screen or no to exit the banking System. The user will be logged out automatically.

Goal/Actor Goals: Description/Sum mary:

Preconditions:

Post-conditions: Basic Flow:

Use Case ID: Use Case Name: Actor(s): Goal/Actor Goals:

UC11 Deposit Cheque Customer The user want to deposit funds to his account thought the medium of cheque.

18

Description/Sum mary: Preconditions:

A cheque can be uploaded/or given in person to the bank for depositing the amount by providing the required details. The cheque leaf should be a valid one and should be within the expiry date and the customer ID/account ID, amount tom be deposited and date should be mentioned. The cheque should be deposited successfully and notified to the employee for approval 1. The user initiates the request to deposit a cheque. 2. The system responds by asking for the account details and the user is requested to upload the cheque image. 3. The system validates the account number and updates the user of successful upload. 4. The system forwards a request to the employee for approval of the deposited cheque. 3.1 If the validation doesnt pass the user is requested to correct/complete the information needed by providing valid error messages.

Post-conditions: Basic Flow:

Alternate Flow:

Use Case ID: Use Case Name: Actor(s): Goal/Actor Goals: Preconditions:

UC12 Approve Cheque Employees The system requests the employee for the approval of the deposited cherub 1. A cherub should be uploaded/ sent for approval by the customer. 2. The customer should have a valid chequing account. 3.The cheque image should contain valid information/details The action of the employee either approval/reject should be updated by the system. 1. The system forwards the request made by the employee to clear the cheque. 2. The employee verifies the necessary details a request the system to update the balance amount and the cheque is approved. 3. The system also updates the balance of the corresponding account accordingly.

Post-conditions: Basic Flow:

Alternate Flow

2.1 If the employee finds that the information given in the 19

cheque is not valid or if there is insufficient balance the cheque is rejected and the customer notified. Use Case ID: Use Case Name: Actor(s): Goal/Actor Goals: Description/Sum mary: UC13 Investments Customer, Employee The customer requests for investing his money in the services that are offered by the bank. Money Market & Bonds investments are the available services in the bank. The customer is first provided the basic details of the investment policies, interest rates and a service is created according to the customers preference. The customer should be an existing customer of the bank. The investment service is provided to the customer 1. The customer requests for the investment options available in the bank. 2. The system provides the detailed description of the investments available. Money Market Account and Bonds. 3. Depending on the preference of the user the system creates an Investment account for the user. 4. The system also requests for the account details and customer id to link the investment account with the existing profile. 5.The system then displays a success message and according to the business logic and the customer needs investment account is created

Preconditions: Post-conditions: Basic Flow:

Use Case ID: Use Case Name: Actor(s): Goal/Actor Goals:

UC14 Employee Profile Management Employee, Administrator The employee intends to update his profile details. The administrator requests the system to add/delete/Update certain employee details. The bank adds/deletes its employee details frequently as inflows/outflows/transfers and promotions happen frequently The employee record should be existing in the database The employee record should be successfully updated 1. The user initiates a request to update (add, delete, edit) the 20

Description/Sum mary: Preconditions: Post-conditions: Basic Flow:

employee record. 2. Depending upon the level of access set the system allows the user to perform the requested action. 3. The System then validates the updated fields and updates the employee record accordingly. Alternate Flow: 3.1 If the validation doesnt pass the user is requested to correct/complete the information needed by providing valid error messages.

3.3Functions The system shall perform a number of operations depending on the customers requirements. 3.2.1. The system shall provide a login page on the welcome screen wherein the customer can login by putting in his/her credentials. 3.2.2. The system shall provide a list of operations to the customer like: a) Deposit money b) Withdraw money c) Making bill payments d) Investment related functions e) Creation and deletion of accounts 3.4 Performance Requirements The banking system application can be installed on any number of systems provided the required software and hardware requirements are met completely. On each machine a single user can access the banking system at a time. All the information of numbers is stored as 32 bit floating point numbers. All the links accessed by the customer should open within a second.

3.5 Logical Database Requirements A database will be kept to store options about the software. This database will hold integers and floats as well as Boolean data. The information stored will be accessible at almost every possible interface with the user and by almost every internal system. The software will allow a user to store and recall values. These values will be stored in a database and will be accessed only if the user updates or requests a stored value. The input will access this database. 21

3.6 Business Rules and Design Constraints The information of numbers input by the users will be in the form of floating point numbers and the strings will be in the form of characters. The user interface will be as simple as possible for the novice user to comprehend the information and act accordingly. The links will be clearly identifiable and will be easy to access. The users will be able to enter their information in the required space.

The whole banking system works on the business rules that are set by either the banking representative or the Central bank. The set of business logics or business rules that are to be adhered while developing the system are defines as follows: Business rules related to user validation 1. Validation of user credentials should be done as it is very critical in a banking system. 2. Proper validation and security question logic should be implemented when the system detects a request from a different IP address comes in. 3. The account should get locked when the user tries to enter in with invalid credentials more than three times. 4. Every customer should create a customer profile which results in a unique customer ID. The unique customer ID should be linked to whatever services (accounts) that the user requests. 5. When the system remain idle for more than 5 minutes and automatically the session should be terminated and the user is re-directed to the login screen again. 6. The password creation logic should be such that it contains alphanumeric characters and the password strength can be validated. Business rules related to transaction 1. All transactions happen only with the CAD (Canadian Dollar Currency). 2. Ideally a time period can be set for the transaction to occur to from the user account. And when the customer or the employee tries to transfer funds/pay bills beyond the cut off time he can be denied permission. This rule can be considered as a part of a security feature. 3. The transaction limit i.e. withdrawal or deposit limit can also be set by the administrator or the employee if there a cap is meant to put on the transaction amount. 4. The logic of credit and debit should be properly planned and a general Ledger which the bank uses as a common inventory can also be implemented. 5. Update of the corresponding service/account should happen after every debit/credit transaction. 22

6. Proper validation should be provided for the amount being entered in the while transaction is being made. It should check the current balance that is available and displayed to the user before every transaction is being done. 7. In case of transfer of funds or payment of bills, proper validation should be made on the destination account and every transaction should be recorded in the transaction table. Business rules related to user accounts/services 1. If a particular customer uses more than of the services they all should be linked to the customer id. Multiple accounts or services should not be present for a single customer. 2. Investment related accounts can also be linked to the normal services used by the customer. 3. Provisions should be made for inter transfer of funds between accounts. For example a customer can transfer funds form a savings account to a chequing account and vice versa. 4. A request should be made by the customer while opening or closing of an account. 5. While closure of account validation should be made on the current account balance of the account. 6. The interest rates can carry depending upon the type of service the user chooses. And interest calculation can be on a daily/monthly/quarterly basis. 7. The interest amount which is accrued can be transferred to the saving account of the customer. 8. The Money market account which is a type of investment account has a higher rate of interest than others and the interest that is accrued can be linked to the savings account. Business rules related to profile (Customer and Employee) 1. The customer profile contains the detailed information about the person such as date of birth, name, occupation, temporary and permanent address, lease documents for proof, Identity poof, Social insurance number etc., 2. The customer is only given certain privileges to update/modify the information present. The employee can only review/view the information and can approve the changes made by the customer. The administrators have both read and update privilege on the information. 3. Similarly the employee profile contains details of all the employees working for the bank, their responsibility and role, and the privileges given to them. The employee does not have access to his own profile. The administrators only have the access to add/update/delete an employee record and also revoke/grant permission to certain functionality depending on the role or post of the employee. 23

3.6.1 Standards Compliance There should be consistency in the look of the user interface; all the links must be identifiable. There should be data backup and recovery facility in case of power outage. The database must not be accessible to some unauthorized person.

3.7 Software System Attributes The input of the banking system that the customer provides will be in the form of characters and floating point numbers. The output will be displayed on the screen of the system and can be further used to derive more information.

3.7.1 Reliability The information provided by the customer to the system as input should be committed to the database. In case of a power outage, there must be facility for data backup and recovery. The output should be available to the customer instantly without any delay of time. The system must be available to the customer 24/7.

3.7.2 Availability All cached data will be rebuilt during every startup. There is no recovery of user data if it is lost. Default values of system data will be assigned when necessary. The data in the database should be available 24/7.

24

3.7.3 Security The data which is present in the database should not be accessible to any unauthorized person. In the case of a database issue, network connection down, or software error system should be shutdown. The application should use secure protocols like SSL that protects data/information from packet analysis.

The application will generate the system log files on daily basis and keep it archived. The application should also restrict the number of successive login attempts to three, after which the account should be locked.

3.7.4 Maintainability The customer will be able to change his/her login details at any time. The database must be backed up frequently for data security purposes. Industry coding standards should be used so that it is easy for the application to evolve in the future when new requirements come up or when a maintenance activity has to be done. Also the core part such as the business logic and the static structures of the use case that not prone to any change should be down the layer and the use cases that are more prone to change should above the core logic layer, which in turn increases maintainability.

3.7.5 Portability The online banking system can function on any system that has java runtime, SQL server for the database. Since the JVM installed in the machine is not platform depended the application which is built using JAVA runs almost on all platforms.

25

3.8 Organizing the Specific Requirements This section organizes the specific requirements in the following ways: 3.8.1 System Mode The system is designed to function on a state to state basis. At the standard input state, a character sequence is entered via the keyboard. When the user signals that the input is finished, the system processes the algorithm and outputs a result. During standard output state, the customer can further use the output to derive required results. During menu navigation, the user is allowed to change different options pertaining to the system. The input no longer accepts the characters associated with building an algorithm but instead allows the user to travel from menu to menu.

3.8.2 User Class

Different functions can be provided to different users: The user class includes administrator, customer, and employee. Administrator can perform following functions 1. Add/Update/Delete Branch Records 2. Add/Update/Delete Employee Records 3. View List of Employees 4. Set interest Rates Employee can perform following functions 1. Add Customer-id 2. Add Accounts-Link id to accounts created 3. Set limits on transaction of Savings/chequing account 4. View/Search List of Customers & Accounts 5. Approve/Reject Cheque 6. Approve Transactions(TBC) Customer can perform following functions 1. View different account profiles/Balance Enquiry 2. Transfer funds 3. Pay Bills/Credit card outstanding 4. View Transaction History 5. Deposit Amount 6. Withdraw Amount 7. Update/View own profile 8. Order/Upload cheque 26

4. Change Management Process

The Online Banking system will use Google Drive/Cloud Forge/JIRA (if needed) to manage all versions of the code and documentation. All the updated documents will be given proper comments and the context/reason for the change to ensure the changes and updates are traceable. Then Business analyst will prepare documents which can be tracked easily using the above mentioned tools. All of the team member should have access to the tools mentioned. Once a one team person finishes the work the document should be checked out so that others can access it.

27