Post on 04-Apr-2018
transcript
7/29/2019 Software Requirement specification e business
1/54
7/29/2019 Software Requirement specification e business
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.
7/29/2019 Software Requirement specification e business
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/7/29/2019 Software Requirement specification e business
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
7/29/2019 Software Requirement specification e business
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.
7/29/2019 Software Requirement specification e business
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/29/2019 Software Requirement specification e business
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
7/29/2019 Software Requirement specification e business
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.
7/29/2019 Software Requirement specification e business
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.
Source Of Input: Keypad Input or button on screen.
Unit of Measure: Canadian dollar $.
Range: $1 to $3000.
7/29/2019 Software Requirement specification e business
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.
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
7/29/2019 Software Requirement specification e business
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.
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.
7/29/2019 Software Requirement specification e business
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.
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 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
7/29/2019 Software Requirement specification e business
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
7/29/2019 Software Requirement specification e business
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.
7/29/2019 Software Requirement specification e business
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
7/29/2019 Software Requirement specification e business
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%.
7/29/2019 Software Requirement specification e business
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.
7/29/2019 Software Requirement specification e business
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.
7/29/2019 Software Requirement specification e business
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.
7/29/2019 Software Requirement specification e business
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.
7/29/2019 Software Requirement specification e business
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.
7/29/2019 Software Requirement specification e business
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
7/29/2019 Software Requirement specification e business
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
7/29/2019 Software Requirement specification e business
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
7/29/2019 Software Requirement specification e business
25/54
Use Case Context Diagram
2. Use Case Briefs
Id: - UC- 1
Use Case- Withdraw Fund
7/29/2019 Software Requirement specification e business
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
7/29/2019 Software Requirement specification e business
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).
7/29/2019 Software Requirement specification e business
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
7/29/2019 Software Requirement specification e business
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.
7/29/2019 Software Requirement specification e business
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
7/29/2019 Software Requirement specification e business
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:
7/29/2019 Software Requirement specification e business
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.
Use Case Diagram (UC-2)
Level: User Level GoalPrimary Actor:-
Customer, Customer wants to deposit money to account.
Supporting Actor:-
Bank`s Database
Stakeholders and interests
7/29/2019 Software Requirement specification e business
33/54
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. 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.
7/29/2019 Software Requirement specification e business
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.
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.
7/29/2019 Software Requirement specification e business
35/54
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
7/29/2019 Software Requirement specification e business
36/54
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. 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.
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
7/29/2019 Software Requirement specification e business
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.
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
7/29/2019 Software Requirement specification e business
38/54
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 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.
7/29/2019 Software Requirement specification e business
39/54
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 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.
7/29/2019 Software Requirement specification e business
40/54
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 toabnormal 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.
7/29/2019 Software Requirement specification e business
41/54
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 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.
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
7/29/2019 Software Requirement specification e business
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.
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
7/29/2019 Software Requirement specification e business
43/54
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 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.
Special requirements:
The non-functional requirements which are related to this use case are
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
7/29/2019 Software Requirement specification e business
44/54
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 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.
7/29/2019 Software Requirement specification e business
45/54
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, 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 .
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.
7/29/2019 Software Requirement specification e business
46/54
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 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
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.
7/29/2019 Software Requirement specification e business
47/54
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.
7/29/2019 Software Requirement specification e business
48/54
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 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
implemented for any manufacturing faults or if any new functionality is
wanted.
Pre-condition
Customer should be authorized.
Post condition
Success end condition
7/29/2019 Software Requirement specification e business
49/54
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. 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.
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.
7/29/2019 Software Requirement specification e business
50/54
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 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
implemented for any manufacturing faults or if any new functionality is
wanted.
Pre-condition
Customer should be authorized.
7/29/2019 Software Requirement specification e business
51/54
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 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.
7/29/2019 Software Requirement specification e business
52/54
3.7.5 Stimulus
N/A
3. 7.6 Response
N/A
7/29/2019 Software Requirement specification e business
53/54
3.7.7 Functional Hierarchy
7/29/2019 Software Requirement specification e business
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.