1.

Introduction

The purpose of this document is to serve as a user interaction knowledge document for Online banking system, a software application which provides customers with the facility to check their accounts and do transactions on-line. For all banks, online banking is a powerful tool to gain new customers while it helps to eliminates costly paper handling and manual teller interactions in an increasingly competitive banking environment and the goal for this project is to develop a user friendly, secure Online Banking Application. Document also focuses on the capabilities needed by the stakeholders, and the target users, and why these needs exist. The system will provide all facilities of bank to its customers when their authentications [user id and password] matches, including viewing account information, performing transfers, giving the customer an option of changing address, paying bills on-line, password retrieval, performing transactions and viewing transactions. Beginning with a brief description of the system including Product perspective of the system, product functions and User Characteristics, present document continues with specific requirement of the system. Specific requirements describe the performance, reliability, usability, design constraints of the Online banking system for XYZ bank. It also describes the design constraints that are to be considered when the system is to be designed, and other factors necessary to provide a complete and comprehensive description of the requirements for the software. 1.2 Scope The Online Banking System is a system which simulates the working of a real XYZ Bank. The scope of this document is to describe the functional and non-functional requirements. Goal of this project is to develop an Online Banking System with highly effective, reliable, secure and user friendly software solution for any XYZ Bank. This system will simulate all the functionalities of the real Bank i.e. deposit and withdraw, make a balance enquiry, make a transfer, pay bill, etc. and for the operator to perform maintenance. 1.3 Definitions, Acronyms, and Abbreviations. All terms, acronyms and abbreviations that are required to interpret the Supplementary Specification are described in the Glossary of the project.

1.4 References [1]. Bank of Canada Act, http://laws-lois.justice.gc.ca/eng/acts/B-2/.

1.5 Overview
The remaining document contains the description about system interfaces, constraints and adaptation requirements. Moreover, it also contains the main functionalities of this system, characteristics of the users, assumptions and dependencies and detailed requirements. This document consists of six different sections. Section 1 contains the introduction which describes the purpose and scope of SRS for an online banking system. Section 2 deals with general factors which affect the product and its requirement. It includes product perspective which puts the product into perspective with other related products, interfaces, design constraint and dependencies of system. Section 3 contains specific requirements for the developers at detailed level that is sufficient to design a system. It includes functional requirements and non-functional requirements. Section 4 contains the information on how to manage the change requirement in system. It includes managing the change control system from requirement phase to testing phase. Section 5 describes all the stakeholders who provide the sign off to the requirements and other documents. Section 6 includes the supporting information for SRS including indexes, appendices and Table of contents.

2. The Overall Description

Customer must have a valid User Id and password to login to the system. After the valid user login into the system, he is shown the list of accounts he has with the bank and perform various transaction as described below. 1. A customer must be able to withdraw money from any account linked to card. 2. A customer must be able to deposit money to all the accounts that are linked to the card. The customer will deposit cash and/or cheques using an envelope. This amount will reflect in account when operator will physically check the envelope.

3. A customer must be able to make a transfer of money between any two accounts linked to the card. 4. A customer must be able to make a balance inquiry of any account linked to the card. 5. A customer must be able to make a transfer either between his accounts or in another users accounts and he must be able to pay his utility bills.

2.1 Product Perspective

The Online Banking Application acts as the medium by which the user can avail the most frequently used services that he normally does in the bank. So this machine acts as an interface between the user and the bank. The user needs to have its account in the bank and an authorized access by which he can access his account via the machine and perform various transactions. User also can open a new bank account if he doesnt have. So we can simply describe the whole process flow by the following diagram.
Online Banking Application

End User

Client Side User Interface Administrat ive Interface

Applicatio n Server

Printer

Bank Database

Administrator Fig 1: System Block Diagram

User will enter commands from keypad to perform some action in system. Application is connected to database preferably to MySQL server 2008 which has information for all the customers. This database is the central and secured location which carries all the important data about its customers. Application transmits the user request to the bank (bank database) and bank will inform application about its decision. Furthermore application will respond this decision to the user.

Application is also connected to printer for printing the receipt on demand of customer. Administrator will have an administrative interface which is a GUI so that he can view the entire system. He will also have a login page where he can enter the login particulars so that he can perform all actions. This administrative interface provides different environment such that he can maintain database & provide backups for the information in the database. He can register the users by providing them with username, password & by creating account in the database. He can view the account request & perform action to accept/decline account requests. The following subsections describe the various system interfaces that will be the part of this system and some constraints that have to be kept in mind while designing this system.

2.1.1 System Interfaces

System should interact directly with bank database to access information. It will retrieve password from the database to validate the password entered by the user. This interface will also retrieve the balance information in order to perform withdrawal, deposit or any other transactions and reflect the changes in users account.

2.1.2 Interfaces
The GUI will be provided to the user to interact with the system, System will prompt the user to enter his credentials through GUI to login into the system. Application will confirm users credentials with bank database and will take the user thorough the process of cash withdrawal, deposit etc. depending upon user. User can also print the receipt or not depending upon users choice. Moreover there will be multiple-language support for the users who cannot understand English instructions. This feature will make the application more global.

2.1.3 Hardware Interfaces

The hardware interfaces required for this application is the keyboard and mouse, which are present in each and every computer system. Internet is also required as it is an online application. Moreover user will also require printer in order to print a receipt or statements.

2.1.4 Software Interfaces

There are interfaces required from the programming point of view but these interfaces will be considered more in detail during the design and development phase itself. There is no need of any special software interfaces like COTS or other APIs to carry out the development of this system. The following interfaces are inevitable as the software will be developed in C#: Microsoft Visual Studio is responsible for executing all C# applications. Microsoft Visual Studio has to be installed and configured for this application to run. SQL support is required for the application to perform queries in the database. For this any C# compatible version of SQL can be used, which has support for all the required features that the developers have used.

2.1.5 Communications Interfaces

Web Browser such as IE 6.0 or equivalent will be required which will allow users to use the application from anywhere. Moreover application should also support SSL protocols in order to establish secure and encrypted communication channel between server and client side application.

2.1.6 Memory Constraints

At least 32GB of disk space and 1024 MB of RAM is needed for memory.

2.1.7 Operations
User interface should be designed in such a way that users complete banking transaction without any assistance. Application should log off the user if it is inactive for 60 seconds. Application should notify the server for the maintenance activity like in case of unexpected shutdown of system. Application should be the on OFF mode when the system is out of service for some reasons like maintenance or down for backup purpose

2.1.8 Site Adaptation Requirements

This software system will be developed in C# using Microsoft Visual Studio, so the .Net Framework is a must for any computer to run this and deploy it anywhere. A database support shall be provided for the system to perform database operations, which are mainly to support the Online Banking operations like Withdraw, Deposit, Transfer and Balance Inquiry etc.

2.2 Product Functions

The software will provide an Online Banking System which will help the user to withdraw and deposit money from account. System will assist the user in transferring money between his accounts or to some other account System will help the user to check balance in account. User can also deposit cheques into his account System will also allow users to pay his utility bills.

Need

Priority

Features

Planned Release 1

Customer would be able to access all his accounts online.[N1]

High

Before stating session, User Id and password will be authenticated [F1] Withdrawals [F2] Deposits. [F3] Balance Enquiry. [F4] Fund transfer. [F5]

Customer should be able to withdraw money from his/her account. [N2] Customer should be able to deposit money. [N3] Customer should be able to enquire balance of his account. [N4] Customer should be able to transfer funds to his account or different users account. [N5] Customer should be able to create a new account.[N6] User should be able pay his utility bills.[N7] User should be able to apply for product including credit card and loan.[N8]

High High High Normal

1 1

1 1

Normal high Normal

Create account [F6] Pay Bill. F[7] Apply for products.[F8]

1 1 1

User should be able to view his account history.[N9] Administrator must be able to add new users to the system and perform other types of user management functions like approve/decline product request.[N10]

High Normal

View History. [F9] Manage [10] User Registration.

1 1

2.3 User Characteristics

Users need not be technical and much aware about computer use. System should be designed in such a way that people from every generation find it easy to use. The interface will be user-friendly enough that will not require the user to have any technical proficiency but the user should have a basic idea about banking transaction. The education background of most of the customers is varied from age to age. However, most of the customers have valid online banking account. So keeping all the prospects in mind the system should be kept simple.

2.4 Constraints
Although this system can be extended for any type of currency, concept of currency has been ignored for now. The host system, i.e. the system where this software will be deployed should have the .Net Framework and database support for its operation. System needs to be highly secured from outside interference as any type of virus or hacking can prove to be very fatal. Software should also have an audit function. It should be able to keep a record of all the transactions that are carried out and it will be maintained automatically by system once a day so that bank can check them at the end of the day and it will also help users if there is any kind of discrepancies. Withdrawn amount should be less or equal to actual amount in account. Users can only withdraw maximum of $3000 per day.

2.5 Assumptions and Dependencies

Assumptions Maximum number of user sessions allowed per day is 5000. Dependencies Operator manually refreshes the system before number of user sessions reaches to 5000. Limited amount of money is allowed This is to maintain the account to withdraw per transaction. balance of customer. Maximum is $1000 per transaction.

Hardware and operating system will In case of emergency, backup never crash. systems are properly available. Every user should be comfortable of User will not be able to use the working with computer and net system without knowledge of browsing computer and net browsing.

Apportioning of Requirements.
First version will have a GUI interface which has functionality of modules like deposit, withdraw, balance enquiry, fund transfer. Later versions will have added functionality like Availability of different display languages like French, Spanish. Further versions will contain the enhancement of system based on customer requirement.

3. Specific Requirements
3.1External Interfaces
3.1.1 Login

This interface allows the user to enter his Login ID and password:

Input: Unique Login ID Password for the customer for logging in Source Of Input: Keypad Input or button on screen. Output: Users personal account page.

3.1.2

Deposit

This interface allows the user to deposit cheque into his account:

Input: Scanned cheque, Amount required to deposit into the account. Source Of Input: Keypad Input or button on screen. Unit of Measure: Canadian dollar $. Range: $1 to $3000.

Output: amount deposited in users account.

3.1.3

Withdraw (Charging a MoneyCard)

This interface allows the user to withdraw amount from his account (i.e. charging a Money Card)

Input: Amount required to be withdrawn from the account. Source Of Input: Keypad Input or button on screen (for simulation). Unit of Measure: Canadian dollars ($). Value: Value depends upon customer Range: $20 to $1000.

3.1.4

Account type

This interface allows the user to check his account types he has:

Output: Different types of accounts user has. Source Of Input: Keypad Input or button on screen. Value: Chequing , Saving or Credit Card.

3.1.5

Balance Enquiry

This interface allows the user to check his current balance:

Source Of Input: Keypad Input or button on screen. Value: Depend upon the users balance. Output: Amount of money user has.

3.1.6

Transfer Money

This interface allows the user to transfer money from his account to another account:

Input: Account Number of the receiver, amount user want to transfer. Source Of Input: Keypad Input or button on screen. Output: Money transferred to target account.

3.1.7

Pay Bill

This interface allows the user pay a Bill online to a specific payee:

Input: Account Number of the payee, Bill reference, Bill Amount. Source Of Input: Keypad Input or button on screen. Output: Bill amount transferred to payees account.

3.1.8

Create An account

This interface allows the user create a new account online:

Input: Account Types, Personnel Information(identification) Source Of Input: Keypad Input or button on screen. Value: Chequing , Saving

3.1.9

View Bank Statement

This interface allows the user to review the historical transaction performed on a specific Account:

Input: Month/Year for which user want to view his bank statement. Source Of Input: Keypad Input or button on screen. Value: Chequing, Saving

3.1.10 Credit Card Application

This interface allows the user to apply for a Credit card online.

Input: Personnel Information (identification), Credit Card Type. Source Of Input: Keypad Input or button on screen.

Value: Credit limit.

3.1.11 Loan Application

This interface allows the user to submit a loan application online:

Input: Personnel Information (identification), Loan Type. Source Of Input: Keypad Input or button on screen.

3.2 Functions
3.2.1 Log in When customer first approaches OLBS information display would be asking for account number. In actual scenario it would display insert number account Customer will enter access number account it will be taken as customer has inserted the number. Then customer will enter 4 digits PIN. This is a secret PIN which would help system for validation and security. Then system will check the database for the combination if access number is wrong then system will display an error message. If customer has entered a valid access account number but PIN is wrong system will display another error message accordingly. If PIN is correct then transaction menu will be displayed. The PIN would be entered again if it is wrong the first time. But in case PIN entered is wrong for three consecutive times then system will automatically lock that particular access card number. Message will be displayed asking the customer to contact bank. 3.2.2. Withdraw When customer chooses to withdraw money from account from menu. Then customer will have to choose account type from which money is to withdrawn. Then system will ask customer to enter the amount that is to be withdrawn from account. Then system will check if customer has enough funds to withdraw the given amount. If funds are not enough then an error message will be displayed

If customer has enough funds then system will perform some calculations in background validating the withdrawal and calculating the new balance of customers account. System will allow maximum of CAD $3,000 per day to be withdraw. Message would be displayed if customer wants a receipt for the transaction. If customer says yes then a receipt would be printed.

3.2.3 Deposit When customer chooses to deposit cash to account from menu. Then customer will choose the account type to which cash is to be deposited. Then system will ask for total amount that customer wants to deposit. System will allow maximum of CAD $3,000 to be deposited in a day. Then system will perform some background calculations calculate new account balance. System will then display new account balance on screen System will then ask customer if receipt is required for transaction. If customer says yes then system will print the receipt Session will then end 3.2.4. Balance Enquiry First customer will choose to check balance of account from menu. Then customer will select type of account from which balance is to check. Then system will show the balance for that particular account on screen. In next version system will display the balance for selected dates. Then system will ask the customer if a receipt is required for the balance enquired. If customer says yes then system will print receipt. Session will end. 3.2.5. Fund transfer Customer will choose to transfer funds from menu. Then customer will be asked to select an account from which funds are to transfer. Then customer will select the account to which funds are transferred. Then customer will enter amount that is to be transferred

 3.2.6

Then system will check from database if customer has enough funds in order to perform the transfer and will validate the transfer. If not error message will be displayed Then system will perform some background calculations system will reduce the amount from account and add the same amount to another account. Then system will display both the balances on screen. Then system will ask the customer if receipt is required or not. If customer says yes then receipt will be printed. Session will end. Pay Bill User selects the Pay Bill option from menu. ONBS shows the available account type. Users select an source account Users selects bill which he/she wants to pay. User will be able to see Account number for particular bill. ONBS system asks user to enter amount. User enter amount and press submit button. System checks the availability of funds in user source account. If balance is positive, system pays bill and amount will be deducted from user account. System asks for another transaction. If user press yes, control will go back to step2.If user press No, system asks user for receipt. User selects yes. System will print the receipt.

3.2.7 Change PIN User selects the Changed PIN option from menu. ONBS system asks user to enter Old Pin ONBS system asks user to enter New Pin and Confirmed PIN. System validates the New PIN and Confirmed PIN. If both PIN matches, system will update the database with new PIN. System asks user to login the system again and system will end the user session. 3.2.8 Create an account User selects Create an Account option from menu. OLBS system asks user to fill a form which contains his/her Identification.

OLBS system asks user to upload the entire required documents (Passport, Driving License etc. . .) System validates the Identification proof uploaded. If Identification will be valid, system will proceed further to create an account. If not Then Customer will be asked to resubmit the Identification proof and documents. System will successfully create an account and system will end the user session.

3.2.9 View account history Customer selects view an account history option from the menu. System requests account number. Customer enters account number. System verifies account number. If Customer enters incorrect account number System presents error message If account number is correct system requests start date and end date. Customer enters start date and end date. System verifies time period. System gets all transactions based on account number within time period. System presents all the transactions. System present user options 3.2.10 Apply for credit card Customer selects apply for credit card option from the menu. System requests account number. Customer enters account number. System verifies account number. If Customer enters incorrect account number System presents error message If Customer enters correct account number system requests the type of the credit card. Customer enters the type of the credit card. System allots the selected type of credit card to the customer. System gets all transactions based on account number within time period. System presents all the transactions. System present user options

3.2.11 Apply for Loan

Customer selects apply for a loan option from the menu. System creates new loan application. System request customer ID. Customer enters customer ID. System verifies customer ID. System requests loan type ID. Customer enters loan type ID. System verifies loan type ID. If Loan type ID is invalid
System presents invalid loan type ID

If Loan type ID is valid. System requests loan information Duration Amount Employment Income Interest rate Customer enters loan information
System creates loan application. System creates loan application.

System creates loan application.

3.2.12. Abort Transaction There will be a Cancel Button on every page if customer wants to abort transaction anywhere in between then customer can hit this button and abort transaction wherever required.

3.3 Performance Requirements

3.3.1 Static Numerical Requirement. 1. Maximum numbers of users over network allowed at given time is 40.This should be tested by using Load testing. 2. The total numbers of terminal that should be supported by OLBS is 40-42. 3. Over 98% of transaction should be related to funds transfer, Balance enquiry and Pay Bill. 4. The System should process all the transaction in Canadian Currency only (almost more than 95% of total transaction). Rest 5% should in US Currency. 5. OLBS should print the statement upon request from user. 6. The reliability of the system should be more than 90%.

3.3.2 Dynamic Numerical Requirement. 1. The response time of OLBS should be less than 5 seconds for a user request during normal workload conditions and during peak hours it should not be more than 10 seconds. 2. System should not be hanged during operations. This should be checked by doing the Stress testing. 3. More than 90% of transaction should be processed in less than 5 seconds.

3.4 Logical Database Requirements

In our database information related to customers accounts will be stored. Account balance of customer, Passwords of customers and number of accounts linked to a particular user etc. such type of information will be stored in our database. Database will be used quite frequently each time a customer uses Online Banking System then there will be very frequent requests sent to database for account balance information or any other information related to transaction that customer is doing. We need a highly accurate and consistent database as information in our database is very critical any ambiguity in our database can lead to major problems for both customer and bank. Database holds integer, floats, and Boolean data types. All the log files should be saved in bank database. There is one backup database for bank application which is used to retrieve information in case of database failures. This backup database works synchronously with bank database.

Database will consist of three tables: 1. Login: This table holds the User ID, Password and Status of the user. 2. Account: This table holds the User ID, Account type and Amount Columns. 3. Summary: This table holds the Account Number, Balance Amount, Last Transaction date and Transaction amount in a day.

3.5 Design Constraints

Input data will be limited to the software system. System will use this data to perform other operations. Output data will be limited to screen and receipt based on user request. Printer should be always connected to system. 32GB of disk space and 1024 MB RAM is required. Bank database will be used to perform all transactions.

Standards Compliance Legal Bank Act will be applied on all customer account and financial information. All the changes in database will be saved in log file and archive of log file will be created for future reference during audit process. The entire daily report summary will be saved in Excel sheets.

3.6 Software System Attributes

This section includes all the non-functional requirements for OLBS system. 3.6.1 Reliability The System should be operational for 24X7. There is regular schedule maintenance period during midnight for 15 minutes. Mean Time Between Failures (MTBF) This system will fail when there is a system crash i.e. the situation where application ceases to function properly in case of unavailability of database, bugs in the application code or corruption of data i.e. The mean time between failure for this application is 15 000 hours. Mean Time To Repair(MTTR) Ninety percent (90%) of the errors or system failures must be repairable within ten minutes of the failure occurrence. In this case, repairable implies that the source of the error is found, corrected and the system should be able to handle at-least fifty percent (50%) of average user load. Moreover all errors should be repaired within an hour and system should be able to handle the same user rate as above

3.6.2 Availability This application shall exhibit an availability of 4 nines I.e. 99.99%. Moreover any maintenance or service routines must run between the midnight and 8 am to avoid inconvenience to users.
3.6.3 Security

The web interface of the application must use secure protocols like SSL that protects data from packet analysis. OLBS will generate the system log files on daily basis and keep it archived. The application should restrict the number of successive login attempts to three, after which the account is locked. There should be three security questions that users must have to answer in case of an account lock or other issues.

In case of any error like database error, network connection error, software error system should be shutdown. OLBS system should receive a confirmation token message from database for every transaction. OLBS system will log all the transactions. The client side application should not allow more than one instance of the application to be opened for one user account. In case a second instance is opened, the first instance should log out with an error.

3.6.4 Maintainability

Coding standard: Successful software tends to live a long time: fixing bugs; adding new features; supporting new platforms; and the software adapted to new market. During the development of this application industry coding standard to make the code base be maintainable by a succession of many different programmers over a period of many years were kept in mind. Certain guidelines like Use descriptive, explanatory, consistent and regular names for variables, use proper comments to make the code readable and maintainable, Avoid ambiguous words in names (e.g. Don't abbreviate "Number" to "No"; "Num" is a better choice) etc. by following these constraints codes are more maintainable.

Maintenance access: Mostly the development team who is developing the application will be responsible for maintaining the application, so after the first release some of these developers will have the maintenance access for the application. In case when this development team is no longer working in the organization, other developers will be doing the maintenance task.
3.6.5 Portability

OLBS system should be developed on .Net Platform. So system should only host on windows platform.

(WILL FINISH THIS TABLE LATER AS IT DEPENDS ON FEATURES)

ID 1 2 3 4 5 6 7 8 9 10 11 12 Characteri stic Correctness Efficiency Flexibility Integrity/Secu rity Interoperabilit y Maintainabilit y Portability Reliability Reusability Testability Usability Availability H/M/L F1 F2 F3 F4 F5 F6 F7

3.7 Organizing the Specific Requirements

3.7.1 System Mode System operates under two modes named as online mode and offline mode. Online mode is one when customer is using the OLBS and system is under operating stage. Whenever any fault exists, system should go offline. This mode is useful for maintenance purpose.
3.7.2 User Class

User Class: There are two types of users who access the system. Customer: This is authorized user who has account in bank and has valid PIN number to access the functionality of system. A non-authorized user is not allowed to access the system.

System Administrator: This is the user who has access to system to maintain the proper functionality of system. In case of any fault only System administrator has access to resolve the issue.

3.7.3 Objects

Below is the list of all the classes with variables and functions. 1. Login Attributes: UserId Password Status Methods: UserAuthentication MainMenu 2. Withdrawn Attributes: AccountType AmountWithdrawn WithdrawnStatus Methods: ValidateWithdrawnAmount WithdrawnMoney UpdateAccount 3. Deposit Attributes: AccountType AmountDeposit DepositStatus Methods: DepositMoney ValidateDepositAmount UpdateAccount 4. FundTransfer Attributes: FromAccount ToAccount ToUserAccountId Amount Methods: ValidateAccount TransferMoney

SuccessMessage UpdateAccount 5. BalanceEnquiry Attributes: AccountType Methods: GetDetails 6. Pay Bill Attributes: AccountType Payee Amount Methods: ValidateAccount PayBill SuccessMessage UpdateAccount 7. Change Pin Attributes: Old PIN New PIN Confirmed PIN Methods: ChangePin SuccessMessage UpdatePin 8. Create an account Attributes: UserName Password FName LName Address Email Methods: CreateAccount SuccessMessage 9. View account history Attributes: AcountType Month Year

Methods: DisplayHistory 10. Apply for credit card Attributes: credit card Type PersonalDetails Methods: ValidateDetail SuccessMessage 11. Apply for Loan Attributes: LoanType PersonalDetails Methods: ValidateDetail SuccessMessage

3.7.4 Feature 1. Use Case Context Diagram

Use Case Context Diagram

2. Use Case Briefs

Id: - UC- 1 Use Case- Withdraw Fund

Primary actor: - Customer, Customer wants to withdraw money from his/her account. Description This use case describes the scenario when customer wants to withdraw Fund from account. First customer chooses from various options to withdraw money from account within a session. Then system displays various accounts that are linked to particular card customer is using. Customer chooses the account from which amount is to be withdrawn. Then system displays most likely figures that user may withdraw depending upon the previous transactions. Customer either one of these amounts or enters a new one using the key pad. Then system checks from the database is customer has enough funds or not. If customer has enough funds then system dispenses the money then prompts the user if receipt is required or not. If user says yes system prints the receipt.

Id: - UC-2 Use Case: - Deposit fund Primary Actor: - Customer, Customer wants to deposit money to account. Description This use case describes the scenario when customer wants to deposit money to his account. First customer chooses from various options to deposit fund to account within a session. Then system displays various accounts that are linked to particular customer is using. Customer chooses the account in which fund is to be deposited. Then system asks the user to select ok option when customer is ready to insert the envelope containing cash. Then system sends the transaction to bank for approval. If transaction is approved user account balance is updated accordingly. Then user is prompted is receipt is required or nor. If user says yes then system prints the receipt. Id: - UC-3 Use Case: - Balance Enquiry Primary Actor: - Customer, Customer wants to checks balance from his account. Description:This use case describes the scenario when customer wants to check balance of account. First customer chooses from various options to check balance of account within a session. Then system displays various accounts that are linked to particular card that customer is using. Customer chooses the

account for which balance is to be enquired. Then system prompts the user if receipt is required or not. If customer says yes then balance is displayed on screen as well as a receipt is printed and transaction is over. Id: - UC-4 Use Case: - Transfer Fund Primary Actor: - Customer, Customer Wants to transfer money from one account to another. Description This use case describes the scenario when customer wants to transfer money from one account to another. First customer chooses from various options to transfer funds from one account to another within a session. Then customer chooses from various accounts that are linked to particular account that are linked to the account which a customer is using. Then customer chooses the account from which funds are to transfer and then the account into which funds are to transfer. Then customer enters the amount that is to be transferred using keypad. Then system checks in database if customer has enough funds or not. If customer has funds then money is transferred. Then customer is prompted if receipt is required or not. If customer wants the receipt it is printed and transaction is over. Id: - UC-5 Use Case: - Pay Bill Primary Actor: - Customer, Customer Wants to pay bill. Description This use case describes the scenario when customer wants to pay bills through the system . First customer chooses the Paybill option from main menu. Then customer chooses the account from which he wants to pay the bill and then the account into which funds are to transfer. Then customer enters the amount that is to be transferred using keypad. Then system checks in database if customer has enough funds or not. If customer has funds then money is transferred. Then customer is prompted if receipt is required or not. If customer wants the receipt it is printed and transaction is over. Id: - UC-6 Use Case: - Change PIN Primary Actor: - Customer, Identification Number (PIN).

Customer

Wants

to

change

Personal

Description This use case describes the scenario when customer wants to change his/her PIN. First Customer chooses the ChangePin option from main menu.Then customer enters the value in textbox of old pin, new pin and confirmed pin through keypad. New PIN should also be of numeric type. Then user will press the change pin button.System will validate the new pin and confirmed pin fields. If both have same value, system will update the database with new pin value. System will ask user to login again.

Id: - UC-7 Use Case: - Create an account Primary Actor:-Customer, Customer wants to create a new account to register in the bank. Description This use case describes the scenario when customer wants to create a new account in order to get register with bank as a new user. First of all customer will gather the entire Identification which is mandatory to create an account. Then customer will have to fill a form which will contain various information based on customers Identity .Soon after the form will be filled, all the documents need to be uploaded and transaction is complete . Id: - UC-8 Use Case: - view account history Primary Actor Customer, Customer wants to create a new account to register in the bank. Description This use case describes the scenario that how customer view to his/her bank statement since last few weeks, months etc. First of all customer chooses the view account history Option from main menu. Then customer chooses the duration for which one needs statement like as seven days, three weeks, a month etc. Then system checks in database whether how many transection have been made so far within that specified period of time Then customer is prompted if print of the view statement is required or not. If customer wants it, then it is printed and transaction is over. Id: - UC-9

Use Case: - Apply for Credit card Primary Actor Customer, Customer wants to apply for Credit card. Description This use case describes the scenario that how customer apply for credit card. First of all customers chooses to apply for credit card, and then customers account will be verified for the eligibility of getting credit card. After completing all verification and other credentials customer will be asked to choose the maximum credit limit of the card. Id: - UC-10 Use Case: - Apply for Loan Primary actor Customer, Customer wants to apply for loan. Description This use case describes the scenario that how customer apply for loan. First of all customer select to apply for loan .Then system creates a new loan application. After that system will ask for customers Id and other information like as; Loan type Id, amount, employment, income and Interest rate. Eventually system validates loan information and record logs for loan application. 1. FULLY DRESSED USE CASE Id: - UC-1 Use Case: - Withdraw Money Description: This use case describes the scenario when customer wants to withdraw money from account. First customer chooses from various options to withdraw money from account within a session. Then system displays various accounts that are linked to particular account customer is using. Customer chooses the account from which amount is to be withdrawn. Then system displays most likely figures that user may withdraw depending upon the previous transactions. Customer either one of these amounts or enters a new one using the key pad. Then system checks from the database is customer has enough funds or not. If customer has enough funds then system dispenses the money then prompts the user if receipt is required or not. If user says yes system prints the receipt returns card and transaction is over.

Use Case Diagram (UC-1)

Level: User Level Goal Primary Actor:Customer, Customer wants to withdraw money. Supporting Actor:Bank`s Database. Stakeholders and interests Managers:- Would like to monitor if the system is working properly. Would also monitor if system is generating any profit or not. Development team: - They will actually develop the system and include all the required functionalities in system Testing team: - They will test the system in all possible scenarios and would see system works normally or not. They will also test how system reacts to abnormal situations Maintenance and support team: - They will maintain the system after it is implemented for any manufacturing faults or if any new functionality is wanted. Pre-condition Customer must have valid account so that one can have access to the account after entering his/her user Id & password i.e. customer must be authenticated and logged into the system. Post condition

Success end condition System validates the transaction. Money is dispensed and transaction is reflected in customer`s account amount instantly Failure end condition Customer could get money but transaction is not reflected in account and account balance remains unchanged. Minimal Guarantee Sufficient information will be available at all times to trace transactions. System will display error messages in abnormal conditions.

Main Success Scenario: 1. User select the withdraw button from menu. 2. OLBS system shows the available account type. 3. Users select an account. 4. OLBS system asks user to enter amount. 5. User enter amount and press submit button. 6. OLBS check the availability of funds in user account. 7. If balance is positive, system dispenses Money to the user. 8. System shows the transaction successful message. 9. OLBS asks for another transaction. 10. If user press yes, control will go back to step2.If user press No, system asks user for receipt. 11. User selects yes. 12. OLBS system will print the receipt. Extensions: 6. a If sufficient balance is not available in user account 6. A.1 OLBS will show a message on screen that sufficient balance is not available in account. 6. A.2 OLBS will cancel the transaction. Special requirements:

The non-functional requirements which are related to this use case are Maintainability Security Reliability Id: - UC-2 Use Case: - Deposit Money Description: This use case describes the scenario when customer wants to deposit money to his/her account. First customer chooses from various options to deposit money to account within a session. Then system displays various accounts that are linked to particular card customer is using. Customer chooses the account in which money is to be deposit. Then system asks the user to press ok button when customer is ready to insert the envelope containing cash. Then system sends the transaction to bank for approval. If transaction is approved user account balance is updated accordingly. Then user is prompted is receipt is required or nor. If user says yes then system prints the receipt and transaction is over. User session will be expired.

Use Case Diagram (UC-2)

Level: User Level Goal Primary Actor:Customer, Customer wants to deposit money to account. Supporting Actor:Bank`s Database Stakeholders and interests

Managers: - Would like to monitor if the system is working properly. Would also monitor if system is generating any profit or not. Development team: - They will actually develop the system and include all the required functionalities in system Testing team: - They will test the system in all possible scenarios and would see system works normally or not. They will also test how system reacts to abnormal situations. Maintenance and support team: - They will maintain the system after it is implemented for any manufacturing faults or if any new functionality is wanted.

Pre-condition Customer must enter his/her user Id & password in order to access thesystem i.e. customer must be authenticated to logged into the system. Post condition Success end condition System validates the transaction. Funds should be deposited and transaction is reflected in customer`s account amount. Failure end condition Transaction does not executed successfully and account balance remains unchanged. Minimal Guarantee Sufficient information will be available at all times to retrace transactions. System will display error messages in abnormal conditions Main Success Scenario: 1. 2. 3. 4. 5. 6. User selects the deposit button from menu. OLBS shows the available account type. Users select an account. OLBS asks user to enter amount. User enter amount and press submit button. OLBS deposited the money to users account.

7. OLBS asks for another transaction. 8. If user press yes, control will go back to step2.If user press No, system asks user for receipt. 9. User selects yes. 10. System will print the receipt. Extensions: 2.a If system does not show the available account type. 2.a.1 User will cancel the transaction and will contact the support team for assistance. Special requirements: The non-functional requirements which are related to this use case are Maintainability Security Reliability Performance Id: - UC-3 Use Case: - Balance Enquiry Description: This use case describes the scenario when customer wants to check balance of account. First customer chooses from various options to check balance of account within a session. Then system displays various accounts that are linked to particular account that customer is using. Customer chooses the account for which balance is to be enquired. Then system prompts the user if receipt is required or not. If customer says yes then balance is displayed on screen as well as a receipt is printed and transaction is over.

Use Case Diagram (UC-3)

Level: User Level Goal Primary Actor:Customer, Customer wants to checks balance from his account. Supporting Actor:Bank`s Database Stakeholders and interests Managers: - Would like to monitor if the system is working properly. Would also monitor if system is generating any profit or not Development team: - They will actually develop the system and include all the required functionalities in system Testing team: - They will test the system in all possible scenarios and would see system works normally or not. They will also test how system reacts to abnormal situations Maintenance and support team: - They will maintain the system after it is implemented for any manufacturing faults or if any new functionality is wanted. Pre-condition Customer must enter his/her user Id & password in order to access the system i.e. customer must be authenticated to logged into the system. Post condition Success end condition

System generates the report of user account which includes account number, type of account, balance, and current date. Failure end condition System is down or Printer dispenser is not working properly . Minimal Guarantee Sufficient information will be available at all times to reach transactions. System will display error messages in abnormal conditions Main Success Scenario: 1. 2. 3. 4. 5. 6. 7. 8. 9. User selects the Balance Enquiry from menu. OLBS shows the available account type. Users select an account. User presses the Balance Enquiry button. System will validate the account type. System will show the balance on screen. System asks user for receipt. User selects yes. System will print the receipt.

Extensions: 2.a If system does not show the available account type. 2.a.1 User will cancel the transaction and will contact the support team for assistance. Special requirements: The non-functional requirements which are related to this use case are Maintainability Security Reliability

Id: - UC-4 Use Case: - Fund Transfer Description: This use case describes the scenario when customer wants to transfer money from one account to another. First customer chooses from various

options to transfer funds from one account to another within a session. Then customer chooses from various accounts that are linked to particular account that are linked to the account which a customer is using. Then customer chooses the account from which funds are to transferred and then the account into which funds are to transferred. Then customer enters the amount that is to be transferred using keypad. Then system checks in database if customer has enough funds or not. If customer has funds then money is transferred. Then customer is prompted if receipt is required or not. If customer wants the receipt it is printed and transaction is over.

Use Case Diagram (UC-4)

Level: User Level Goal Primary Actor:Customer, Customer wants to transfer money from one account to another. Supporting Actor:Bank`s Database Stakeholders and interests Managers: - Would like to monitor if the system is working properly. Would also monitor if system is generating any profit or not Development team: - They will actually develop the system and include all the required functionalities in system Testing team: - They will test the system in all possible scenarios and would see system works normally or not. They will also test how system reacts to abnormal situations

Maintenance and support team: - They will maintain the system after it is implemented for any manufacturing faults or if any new functionality is wanted. Pre-condition Customer must enter his/her user Id & password in order to access the system i.e. customer must be authenticated to logged into the system. Customer must have minimum of two active account numbers. Post condition Success end condition System validates the transaction. Funds will be transferred from customer one account to other and transaction is reflected in customer`s account number. Failure end condition Transferred funds are not reflected in customer account. Minimal Guarantee Sufficient information will be available at all times to retrace transactions. System will display error messages in abnormal conditions Main Success Scenario: 1. Customer selects the Funds Transfer option from menu. 2. OLBS shows the available account type. 3. Users select an source account 4. Users select destination account. 5. OLBS system asks user to enter amount. 6. User enter amount and press submit button. 7. System checks the availability of funds in user source account. 8. If balance is positive, system transfer funds to the destination account. 9. System asks for another transaction. 10. If user press yes, control will go back to step2.If user press No, system asks user for receipt. 11. User selects yes. 12. System will print the receipt. Extensions: 6.a If sufficient balance is not available in user source account 6.a.1 System will show an message on screen that sufficient balance is not available in source account. 6.a.2 System will cancel the transaction.

Special requirements: The non-functional requirements which are related to this use case are Maintainability Security Reliability

Id: - UC- 5 Use Case: - Pay Bill Description: This use case describes the scenario when customer wants to pay bills through System. First customer chooses the PayBill option from main menu. Then customer chooses the account from which he wants to pay the bill and then the account into which funds are to transfer. Then customer enters the amount that is to be transferred using keypad. Then system checks in database if customer has enough funds or not. If customer has funds then money is transferred. Then customer is prompted if receipt is required or not. If customer wants the receipt it is printed and transaction is over.

Use Case Diagram (UC-5) Level: User Level Goal Primary Actor:Customer, Customer Wants to Pay Bill Supporting Actor:Bank`s Database Stakeholders and interests Managers:- Would like to monitor if the system is working properly. Would also monitor if system is generating any profit or not Development team:- They will actually develop the system and include all the required functionalities in system Testing team: - They will test the system in all possible scenarios and would see system works normally or not. They will also test how system reacts to abnormal situations Maintenance and support team: - They will maintain the system after it is implemented for any manufacturing faults or if any new functionality is wanted. Pre-condition Customer must enter his/her user Id & password in order to access the system i.e. customer must be authenticated to logged into the system. Customer must have minimum of two active account numbers. Post condition Success end condition System validates the transaction. Funds will be transferred from customer account to Payee Account and amount is deducted customer`s account number.

Failure end condition Deducted amount is not reflected in customer account. Minimal Guarantee Sufficient information will be available at all times to retrace transactions. System will display error messages in abnormal conditions Main Success Scenario: 1. Customer selects the Pay Bill option from menu. 2. OLBS shows the available account type. 3. Users select an source account 4. Users selects bill which he/she wants to pay. User will be able to see Account number for particular bill. 5. OLBS system asks user to enter amount. 6. User enter amount and press submit button. 7. System checks the availability of funds in user source account. 8. If balance is positive, system pays bill and amount will be deducted from user account. 9. System asks for another transaction. 10. If user press yes, control will go back to step2.If user press No, system asks user for receipt. 11. User selects yes. 12. System will print the receipt. Extensions: 6.a If sufficient balance is not available in user source account 6.a.1 System will show an message on screen that sufficient balance is not available in source account. 6.a.2 System will cancel the transaction.

Special requirements: The non-functional requirements which are related to this use case are Maintainability Security Reliability Id: - UC- 6 Use Case: - Change PIN Description: This use case describes the scenario when customer wants to change his/her PIN. First Customer chooses the ChangePin option from main menu. Then

customer enters the value in textbox of old pin, new pin and confirmed pin through keypad. New PIN should also be of numeric type. Then user will press the change pin button. System will validate the new pin and confirmed pin fields. If both have same value, system will update the database with new pin value. System will ask user to login again.

Use Case Diagram (UC-6) Level: User Level Goal Primary Actor:Customer, Customer wants to change the Personal Identification Number (PIN). Supporting Actor:Bank`s Database Stakeholders and interests Managers: - Would like to monitor if the system is working properly. Would also monitor if system is generating any profit or not Development team:- They will actually develop the system and include all the required functionalities in system Testing team: - They will test the system in all possible scenarios and would see system works normally or not. They will also test how system reacts to abnormal situations Maintenance and support team: - They will maintain the system after it is implemented for any manufacturing faults or if any new functionality is wanted. Pre-condition

Customer must enter his/her user Id & password in order to access the system i.e. customer must be authenticated to logged into the system. Customer must have minimum of two active account numbers. Post condition Success end condition System validates the new PIN and confirmed PIN fields. System will update the database with the changed value of PIN. Failure end condition PIN is not getting changed. Minimal Guarantee Sufficient information will be available at all times to retrace transactions. System will display error messages in abnormal conditions Main Success Scenario: 1. User selects the Changed PIN option from menu. 2. OLBS system asks user to enter Old Pin 3. OLBS system asks user to enter New Pin and Confirmed PIN. 4. System validates the New PIN and Confirmed PIN. 5. If both PIN matches, system will update the database with new PIN. 6. System asks user to login the system again and system will end the user session. Extensions: 4.a If New PIN and Confirmed PIN does not matches. 4.a.1 System will show an error message that both PIN should match.

Special requirements: The non-functional requirements which are related to this use case are Maintainability Security Reliability Id: - UC-7 Use Case: - Create an account Description: This use case describes the scenario when customer wants to create a new account in order to get register with bank as a new user. First of all customer will gather the entire Identification which is mandatory to create an account. Then customer will have to fill a form which will contain various information

based on customers Identity .Soon after the form will be filled, all the documents need to be uploaded and transection is complete .

Use Case Diagram (UC-7) Level: User Level Goal Primary Actor:Customer, Customer wants to create a new account. Supporting Actor:Bank`s Database Stakeholders and interests Managers: - Would like to monitor if the system is working properly. Would also monitor if system is generating any profit or not Development team: - They will actually develop the system and include all the required functionalities in system Testing team:- They will test the system in all possible scenarios and would see system works normally or not. They will also test how system reacts to abnormal situations Maintenance and support team:- They will maintain the system after it is implemented for any manufacturing faults or if any new functionality is wanted. Pre-condition Customer must have a valid Identification proof and a fully filled form must be submitted as well as the required documents should be uploaded.

Post condition Success end condition The customer successfully creates an account and receives his/her account information. Failure end condition Identification proof is not valid. Minimal Guarantee Sufficient information will be available at all times to retrace transactions. System will display error messages in abnormal conditions Main Success Scenario: 1. User selects to create an account option from menu. 2. OLBS system asks user to fill a form which contains his/her Identification. 3. OLBS system asks user to upload the entire required documents (Passport, Driving License etc. . .) 4. System validates the Identification proof uploaded. 5. If Identification will be valid, system will proceed further to create an account. 6. System will successfully create an account and system will end the user session. Extensions: 5. a If Identification and required document will not be valid .Then Customer will be asked to resubmit the Identification proof and documents . Special requirements: The nonfunctional requirements which are related to this use case are Maintainability Security Reliability Id: - UC-8 Use Case: - View account history Description: This use case describes the scenario that how customer wants to view his/her bank statement history.

Use Case Diagram (UC-8) Level: User Level Goal Primary Actor:Customer, Customer wants view account history. Supporting Actor:Bank`s Database Stakeholders and interests Managers: - Would like to monitor if the system is working properly. Would also monitor if system is generating any profit or not Development team: - They will actually develop the system and include all the required functionalities in system Testing team:- They will test the system in all possible scenarios and would see system works normally or not. They will also test how system reacts to abnormal situations Maintenance and support team:- They will maintain the system after it is implemented for any manufacturing faults or if any new functionality is wanted.

Pre-condition Customer should be authenticated. Post condition Success end condition The customer successfully view account history.

Failure end condition Customer enters incorrect account number and enters invalid time period. Minimal Guarantee Sufficient information will be available at all times to retrace transactions. System will display error messages in abnormal conditions Main Success Scenario: 1. Customer selects view account history option. 2. System requests account number. 3. Customer enters account number. 4. System verifies account number. 5. System requests start date and end date. 6. Customer enters start date and end date. 7. System verifies time period. 8. System gets all transactions based on account number within time period. 9. System presents all the transactions. 10. System present user options Alternative Flow 4a. Customer enters incorrect account number. 1. System presents error message. 2. Return to step 2. 7a. Customer enters invalid time period 1. System presents error message. 2. Return to step 5.

Id: - UC-9 Use Case: - Apply for credit card. Description: This use case describes the scenario that how customer wishes apply for credit card.

Use Case Diagram (UC-9) Level: User Level Goal Primary Actor:Customer, Customer wants apply for credit card. Supporting Actor:Bank`s Database Stakeholders and interests Managers: - Would like to monitor if the system is working properly. Would also monitor if system is generating any profit or not Development team: - They will actually develop the system and include all the required functionalities in system Testing team: - They will test the system in all possible scenarios and would see system works normally or not. They will also test how system reacts to abnormal situations Maintenance and support team:- They will maintain the system after it is implemented for any manufacturing faults or if any new functionality is wanted.

Pre-condition Customer should be authorized. Post condition Success end condition

The customer successfully receives the credit card. Failure end condition Customer enters incorrect information. Minimal Guarantee Sufficient information will be available at all times to retrace transactions. System will display error messages in abnormal conditions. Main Success Scenario: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Customer selects apply for credit card option System requests account number. Customer enters account number. System verifies account number. System requests the type of the credit card Customer enters the type of the credit card. System allots the selected type of credit card to the customer. System gets all transactions based on account number within time period. System presents all the transactions. System present user options

Alternative Flow 4a. Customer enters incorrect account number. 1. System presents error message. 2. Return to step 2.

Id: - UC-10 Use Case: - Apply for Loan Description: This use case describes the scenario that how customer wishes apply for Loan.

Use Case Diagram (UC-10) Level: User Level Goal Primary Actor:Customer, Customer wants apply for loan. Supporting Actor:Bank`s Database Stakeholders and interests Managers: - Would like to monitor if the system is working properly. Would also monitor if system is generating any profit or not Development team: - They will actually develop the system and include all the required functionalities in system Testing team: - They will test the system in all possible scenarios and would see system works normally or not. They will also test how system reacts to abnormal situations Maintenance and support team: - They will maintain the system after it is implemented for any manufacturing faults or if any new functionality is wanted.

Pre-condition Customer should be authorized.

Post condition Success end condition The customer successfully receives the loan. Failure end condition Customer enters incorrect information. Minimal Guarantee Sufficient information will be available at all times to retrace transactions. System will display error messages in abnormal conditions. Main Success Scenario: 1. Customer selects apply for a loan option 2. System creates new loan application. 3. System request customer ID 4. Customer enters customer ID. 5. System verifies customer ID. 6. System requests loan type ID. 7. Customer enters loan type ID. 8. System verifies loan type ID. 9. System requests loan information Duration Amount Employment Income Interest rate 10. Customer enters loan information 11. Customer enters loan information 12. System creates loan application. 13. System creates loan application. 14. System creates loan application. Alternative Flow 8a. Loan type ID is invalid. (Not active or not exist) 1. System presents invalid loan type ID 2. Return to step 6 11a. Loan information is incomplete. 1. System presents incomplete loan application. 2. Return to step 9.

3.7.5 Stimulus N/A 3. 7.6 Response N/A

3.7.7 Functional Hierarchy

4.Change Management Process

Any software system is subject to change otherwise it may become the legacy system in future. The development methodology would be agile where small releases will be followed by some refactoring and clients review and this process will go on till the product is developed completely. Each small release will be presented to the clients representative, so that if the client wants to do any changes, he is able to inform the developers during the development phase itself. Hence, the developers will constantly approve their small releases so that the client has some idea about the final product, which will ensure that the final product is what the client wants. A request for change will be considered later as well is theres a need. The medium for communication shall be a telephonic conversation or a meeting between the client and the developer as it helps in clarification of doubts at the same time.