Software Requirement specification e business

7/29/2019 Software Requirement specification e business

1/54


2/54

1. Introduction

The purpose of this document is to serve as a user interaction

knowledge document for Online banking system, a softwareapplication which provides customers with the facility to check theiraccounts and do transactions on-line. For all banks, online banking is apowerful tool to gain new customers while it helps to eliminates costlypaper handling and manual teller interactions in an increasinglycompetitive banking environment and the goal for this project is todevelop a user friendly, secure Online Banking Application.

Document also focuses on the capabilities needed by thestakeholders, and the target users, and why these needs exist. Thesystem will provide all facilities of bank to its customers when theirauthentications [user id and password] matches, including viewing

account information, performing transfers, giving the customer anoption of changing address, paying bills on-line, password retrieval,performing transactions and viewing transactions.

Beginning with a brief description of the system includingProduct perspective of the system, product functions and UserCharacteristics, present document continues with specific requirementof the system. Specific requirements describe the performance,reliability, usability, design constraints of the Online banking systemfor XYZ bank. It also describes the design constraints that are to beconsidered when the system is to be designed, and other factorsnecessary 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 ofa real XYZ Bank. The scope of this document is to describe thefunctional and non-functional requirements.Goal of this project is to develop an Online Banking System with highlyeffective, reliable, secure and user friendly software solution for anyXYZ Bank. This system will simulate all the functionalities of the real

Bank i.e. deposit and withdraw, make a balance enquiry, make atransfer, 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.


3/54

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 andscope of SRS for an online banking system.

Section 2 deals with general factors which affect the product and itsrequirement. It includes product perspective which puts the productinto perspective with other related products, interfaces, designconstraint and dependencies of system.

Section 3 contains specific requirements for the developers at detailedlevel that is sufficient to design a system. It includes functionalrequirements and non-functional requirements.

Section 4 contains the information on how to manage the changerequirement in system. It includes managing the change controlsystem from requirement phase to testing phase.

Section 5 describes all the stakeholders who provide the sign off to therequirements and other documents.

Section 6 includes the supporting information for SRS includingindexes, 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 accountlinked to card.2. A customer must be able to deposit money to all the accountsthat are linked to the card. The customer will deposit cash and/orcheques using an envelope. This amount will reflect in account whenoperator will physically check the envelope.
http://c/Users/f_alman/Desktop/Bankhttp://laws-lois.justice.gc.ca/eng/acts/B-2/http://c/Users/f_alman/Desktop/Bankhttp://laws-lois.justice.gc.ca/eng/acts/B-2/


4/54

3. A customer must be able to make a transfer of money betweenany two accounts linked to the card.4. A customer must be able to make a balance inquiry of anyaccount 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 hisutility 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 simplydescribe the whole process flow by the following diagram.

End User

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 whichhas 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.

Online Banking Application

Client Side

UserApplicatio

n Server

Bank

DatabasPrinter

Administrat

ive


5/54

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. Thisadministrative 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 andmouse, which are present in each and every computer system. Internet isalso required as it is an online application. Moreover user will also requireprinter in order to print a receipt or statements.


6/54

2.1.4 Software Interfaces

There are interfaces required from the programming point of view but theseinterfaces will be considered more in detail during the design anddevelopment 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 inC#: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 InterfacesWeb 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 userscomplete 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 likein case of unexpected shutdown of system.

Application should be the on OFF mode when the system is out ofservice for some reasons like maintenance or down for backuppurpose

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 itanywhere.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.


7/54

2.2 Product Functions

The software will provide an Online Banking System which will help the user towithdraw and deposit money from account.

System will assist the user in transferring money between his accounts or to someother 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 PlannedRelease

Customer would be able to access all

his accounts online.[N1]

High Before stating session, User Id

and password will be

authenticated [F1]

1

Customer should be able to withdraw

money from his/her account. [N2]

High Withdrawals [F2] 1

Customer should be able to depositmoney. [N3]

High Deposits. [F3] 1

Customer should be able to enquire

balance of his account. [N4]

High Balance Enquiry. [F4] 1

Customer should be able to transfer

funds to his account or different

users account. [N5]

Normal Fund transfer. [F5] 1

Customer should be able to create a

new account.[N6]

Normal Create account [F6] 1

User should be able pay his utility

bills.[N7]

high Pay Bill. F[7] 1

User should be able to apply for

product including credit card and

loan.[N8]

Normal Apply for products.[F8] 1


8/54

User should be able to view his

account history.[N9]

High View History. [F9] 1

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]

Normal Manage User Registration.

[10]

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 tohave 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 hasbeen 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 orhacking can prove to be very fatal.

Software should also have an audit function. It should be able to keep a record of allthe transactions that are carried out and it will be maintained automatically by systemonce a day so that bank can check them at the end of the day and it will also helpusers 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 DependenciesAssumptions DependenciesMaximum number of user sessionsallowed per day is 5000.

Operator manually refreshes thesystem before number of usersessions reaches to 5000.

Limited amount of money is allowedto withdraw per transaction.Maximum is $1000 per transaction.

This is to maintain the accountbalance of customer.


9/54

Hardware and operating system willnever crash.

In case of emergency, backupsystems are properly available.

Every user should be comfortable ofworking with computer and net

browsing

User will not be able to use thesystem without knowledge of

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.


Unit of Measure: Canadian dollar $.

Range: $1 to $3000.


10/54

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.


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


11/54

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.


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.


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)


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.


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.



12/54

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.


3.2 Functions

3.2.1 Log in

When customer first approaches OLBS information display would beasking for account number. In actual scenario it would display insertnumber account

Customer will enter access number account it will be taken ascustomer has inserted the number.

Then customer will enter 4 digits PIN. This is a secret PIN whichwould help system for validation and security.

Then system will check the database for the combination if accessnumber is wrong then system will display an error message.

If customer has entered a valid access account number but PIN iswrong 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 incase PIN entered is wrong for three consecutive times then systemwill automatically lock that particular access card number. Messagewill 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 whichmoney is to withdrawn.

Then system will ask customer to enter the amount that is to bewithdrawn from account.

Then system will check if customer has enough funds to withdrawthe given amount.

If funds are not enough then an error message will be displayed


13/54

If customer has enough funds then system will perform somecalculations in background validating the withdrawal and calculatingthe new balance of customers account. System will allow maximumof 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 bedeposited.

Then system will ask for total amount that customer wants todeposit. System will allow maximum of CAD $3,000 to be depositedin a day.

Then system will perform some background calculations calculatenew 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 selecteddates.

Then system will ask the customer if a receipt is required for thebalance 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 aretransferred.

Then customer will enter amount that is to be transferred


14/54

Then system will check from database if customer has enoughfunds 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 willreduce 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.

3.2.6 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 seeAccountnumber 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 deductedfrom 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 theuser 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/herIdentification.


15/54

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 createan 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 enddate.

Customer enters start date and end date.

System verifies time period.

System gets all transactions based on account number withintime 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


16/54

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 Requirements3.3.1 Static Numerical Requirement.

1. Maximum numbers of users over network allowed at given timeis 40.This should be tested by using Load testing.2. The total numbers of terminal that should be supported byOLBS 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 CanadianCurrency only (almost more than 95% of total transaction). Rest5% 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%.


17/54

3.3.2 Dynamic Numerical Requirement.

1. The response time of OLBS should be less than 5 seconds for auser request during normal workload conditions and during peakhours it should not be more than 10 seconds.

2. System should not be hanged during operations. This should bechecked by doing the Stress testing.3. More than 90% of transaction should be processed in less than 5

seconds.

3.4 Logical Database RequirementsIn our database information related to customers accounts will be

stored. Account balance of customer, Passwords of customers andnumber of accounts linked to a particular user etc. such type ofinformation will be stored in our database.

Database will be used quite frequently each time a customer uses OnlineBanking System then there will be very frequent requests sent todatabase for account balance information or any other informationrelated to transaction that customer is doing.

We need a highly accurate and consistent database as information in ourdatabase 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 bankdatabase. There is one backup database for bank application which isused to retrieve information in case of database failures. This backupdatabase works synchronously with bank database.


18/54

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 userrequest.

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.


19/54

Standards Compliance

Legal Bank Act will be applied on all customer account and financialinformation.

All the changes in database will be saved in log file and archive oflog 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 AttributesThis section includes all the non-functional requirements for OLBS system.

3.6.1 Reliability

The System should be operational for 24X7. There is regular schedulemaintenance period during midnight for 15 minutes.

Mean Time Between Failures (MTBF)

This system will fail when there is a system crash i.e. the situationwhere application ceases to function properly in case of unavailabilityof database, bugs in the application code or corruption of data i.e. Themean 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 berepairable within ten minutes of the failure occurrence. In thiscase, repairable implies that the source of the error is found,corrected and the system should be able to handle at-least fiftypercent (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 themidnight 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 loginattempts to three, after which the account is locked. There shouldbe three security questions that users must have to answer in caseof an account lock or other issues.


20/54

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 fromdatabase for every transaction.

OLBS system will log all the transactions.

The client side application should not allow more than one instanceof the application to be opened for one user account. In case asecond instance is opened, the first instance should log out with anerror.

3.6.4 Maintainability

Coding standard:

Successful software tends to live a long time: fixing bugs; adding newfeatures; 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 beresponsible for maintaining the application, so after the first release some of

these developers will have the maintenance access for the application. Incase 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.


21/54

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

ID Characteristic

H/M/L F1 F2 F3 F4 F5 F6 F7

1 Correctness2 Efficiency

3 Flexibility

4 Integrity/Security

5 Interoperability

6 Maintainability

7 Portability

8 Reliability

9 Reusability

10 Testability

11 Usability

12 Availability

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 toaccess the functionality of system. A non-authorized user is not allowed to access thesystem.


22/54

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

3.7.3 Objects

Below is the list of all the classes with variables and functions.

1. Login

Attributes:UserIdPasswordStatusMethods:UserAuthenticationMainMenu

2. Withdrawn

Attributes:AccountTypeAmountWithdrawnWithdrawnStatusMethods:ValidateWithdrawnAmountWithdrawnMoneyUpdateAccount

3. DepositAttributes:AccountTypeAmountDepositDepositStatusMethods:DepositMoneyValidateDepositAmountUpdateAccount

4. FundTransfer

Attributes:FromAccountToAccountToUserAccountId

AmountMethods:

ValidateAccountTransferMoney


23/54

SuccessMessageUpdateAccount

5. BalanceEnquiry

Attributes:

AccountTypeMethods:GetDetails

6. Pay Bill

Attributes:AccountTypePayeeAmount

Methods:ValidateAccountPayBillSuccessMessageUpdateAccount

7. Change Pin

Attributes:Old PIN

New PINConfirmed PIN

Methods:ChangePin

SuccessMessageUpdatePin

8. Create an account

Attributes:UserNamePasswordFNameLNameAddressEmailMethods:

CreateAccountSuccessMessage

9. View account history

Attributes:AcountTypeMonthYear


24/54

Methods:

DisplayHistory

10. Apply for credit card

Attributes:credit card TypePersonalDetails

Methods:ValidateDetailSuccessMessage

11. Apply for Loan

Attributes:LoanTypePersonalDetails

Methods:ValidateDetailSuccessMessage

3.7.4 Feature

1. Use Case Context Diagram


25/54

Use Case Context Diagram

2. Use Case Briefs

Id: - UC- 1

Use Case- Withdraw Fund


26/54

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 inwhich 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 hisaccount.

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


27/54

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 accountinto 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, Customer Wants to change Personal

Identification Number (PIN).


28/54

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 systemchecks 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


29/54

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 loanapplication. 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 MoneyDescription:

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.


30/54

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


31/54

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 notavailable in account.

6. A.2 OLBS will cancel the transaction.

Special requirements:


32/54

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.


Level: User Level GoalPrimary Actor:-

Customer, Customer wants to deposit money to account.

Supporting Actor:-

Bank`s Database



33/54

Managers: - Would like to monitor if the system is working properly. Would

also monitor if system is generating any profit or not.





abnormal situations.



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


System validates the transaction. Funds should be deposited and transaction

is reflected in customer`s account amount.


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


1. User selects the deposit button from menu.2. OLBS shows the available account type.3. Users select an account.4. OLBS asks user to enter amount.5. User enter amount and press submit button.6. OLBS deposited the money to users account.


34/54

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.



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.


35/54



Primary Actor:-Customer, Customer wants to checks balance from his account.

Supporting Actor:-

Bank`s Database



also monitor if system is generating any profit or not





abnormal situations



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



36/54

System generates the report of user account which includes account

number, type of account, balance, and current date.


System is down or Printer dispenser is not working properly .

Minimal Guarantee

Sufficient information will be available at all times to reach transactions.



1. User selects the Balance Enquiry from menu.2. OLBS shows the available account type.3. Users select an account.4. User presses the Balance Enquiry button.

5. System will validate the account type.6. System will show the balance on screen.7. System asks user for receipt.8. User selects yes.9. 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.



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


37/54

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.



Primary Actor:-

Customer, Customer wants to transfer money from one account to another.

Supporting Actor:-

Bank`s Database








abnormal situations


38/54



wanted.

Pre-condition



Customer must have minimum of two active account numbers.

Post 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




1. Customer selects the Funds Transfer option from menu.2. OLBS shows the available account type.

3. Users select an source account4. 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.


39/54



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 thenmoney is transferred. Then customer is prompted if receipt is required or

not. If customer wants the receipt it is printed and transaction is over.


40/54



Primary Actor:-

Customer, Customer Wants to Pay Bill

Supporting Actor:-Bank`s Database


Managers:- Would like to monitor if the system is working properly. Would


Development team:- They will actually develop the system and include all



see system works normally or not. They will also test how system reacts toabnormal situations



wanted.

Pre-condition




Post condition


System validates the transaction. Funds will be transferred from customer

account to Payee Account and amount is deducted customer s account

number.


41/54


Deducted amount is not reflected in customer account.

Minimal Guarantee




1. Customer selects the Pay Bill option from menu.2. OLBS shows the available account type.3. Users select an source account4. 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.



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


42/54

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.



Primary Actor:-

Customer, Customer wants to change the Personal Identification Number

(PIN).

Supporting Actor:-

Bank`s Database




Development team:- They will actually develop the system and include all




abnormal situations



wanted.

Pre-condition


43/54




Post condition


System validates the new PIN and confirmed PIN fields. System will update

the database with the changed value of PIN.


PIN is not getting changed.

Minimal Guarantee



Main Success Scenario:1. User selects the Changed PIN option from menu.2. OLBS system asks user to enter Old Pin3. 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.



Maintainability

Security

Reliability

Id: - UC-7

Use Case: - Create an accountDescription:

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


44/54

based on customers Identity .Soon after the form will be filled, all the

documents need to be uploaded and transection is complete .



Primary Actor:-

Customer, Customer wants to create a new account.

Supporting Actor:-

Bank`s Database






Testing team:- They will test the system in all possible scenarios and would


abnormal situations

Maintenance and support team:- They will maintain the system after it isimplemented 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.


45/54

Post condition


The customer successfully creates an account and receives his/her account

information.


Identification proof is not valid.

Minimal Guarantee




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, DrivingLicense 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 .


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.


46/54



Primary Actor:-

Customer, Customer wants view account history.

Supporting Actor:-

Bank`s Database






Testing team:- They will test the system in all possible scenarios and wouldsee 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


wanted.

Pre-condition

Customer should be authenticated.

Post condition


The customer successfully view account history.


47/54


Customer enters incorrect account number and enters invalid time period.

Minimal Guarantee




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


Id: - UC-9

Use Case: - Apply for credit card.Description:

This use case describes the scenario that how customer wishes apply for

credit card.


48/54

Use

Case Diagram (UC-9)


Primary Actor:-

Customer, Customer wants apply for credit card.

Supporting Actor:-Bank`s Database






Testing team: - They will test the system in all possible scenarios and wouldsee 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


wanted.

Pre-condition

Customer should be authorized.

Post condition



49/54

The customer successfully receives the credit card.


Customer enters incorrect information.

Minimal Guarantee




1. Customer selects apply for credit card option2. System requests account number.3. Customer enters account number.4. System verifies account number.5. System requests the type of the credit card6. Customer enters the type of the credit card.

7. System allots the selected type of credit card to the customer.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.


Id: - UC-10

Use Case: - Apply for Loan

Description:

This use case describes the scenario that how customer wishes apply for

Loan.


50/54



Primary Actor:-

Customer, Customer wants apply for loan.

Supporting Actor:-

Bank`s Database






Testing team: - They will test the system in all possible scenarios and wouldsee system works normally or not. They will also test how system reacts to

abnormal situations



wanted.

Pre-condition

Customer should be authorized.


51/54

Post condition


The customer successfully receives the loan.


Customer enters incorrect information.

Minimal Guarantee




1. Customer selects apply for a loan option2.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 information11. 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 ID2. Return to step 6

11a. Loan information is incomplete.1. System presents incomplete loan application.2. Return to step 9.


52/54

3.7.5 Stimulus

N/A

3. 7.6 Response

N/A


53/54

3.7.7 Functional Hierarchy


54/54

4.Change Management Process

Any software system is subject to change otherwise it may become thelegacy system in future. The development methodology would be agilewhere small releases will be followed by some refactoring and clients reviewand this process will go on till the product is developed completely. Eachsmall release will be presented to the clients representative, so that if theclient wants to do any changes, he is able to inform the developers duringthe development phase itself. Hence, the developers will constantly approvetheir 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 meetingbetween the client and the developer as it helps in clarification of doubts at

the same time.

Documents

Software Requirement specification e business