Teaching slides Case study Case study Contents Introduction

Teaching slides Case study

Case study Contents • Introduction • Software requirement specifications – Use cases & SRS for OBAAS 1. 1 & OBAAS 1. 2 • Software high level design – Data flow & component diagrams for OBAAS 1. 1 & OBAAS 1. 2 • User interface design & construction – Mock up screens for OBAAS 1. 1 & OBAAS 1. 2 • Software middle layer design & construction – Class, object, sequence & statechart diagrams for OBAAS 1. 1 & OBAAS 1. 2 • Database design & construction • Software testing

Case study software requirement management – OBAAS 1. 1 System use case for OBAAS 1. 1

Case study software requirement management – OBAAS 1. 1 Create bank account use case for OBAAS 1. 1

Case study software requirement management – OBAAS 1. 1 • When the user clicks on the Create account menu, the user should be taken to the Create account page. This page should contain a form where there are textboxes for Username, Password, Retype password, Phone number, and Address. There should be another textbox named Category for which the data should be non-editable and it should have a default value “U”. The textboxes for Password and Retype password should not display the characters and should show only an asterisk for each character entered by the user. The Create account page should have two buttons, Submit and Clear. When the user provides information in the textboxes for Username, Password, and Retype password; and the information in the textboxes for Password and Retype password match; and did not leave any textboxes empty; and clicks on the Submit button the user information should be stored in the database of OBAAS. In that case, the user account should be created and the user is taken to a page containing a message confirming the successful account creation and the account number assigned to the user.

Case study software requirement management – OBAAS 1. 1 • If the Clear button is clicked then the information provided by the user in the textboxes should be cleared and no information from the Account creation form should be stored in the database. If the information provided in the Password and Retype password fields does not match and the user clicks on the Submit button then a dialog box should appear with the message “Entries in the password/retype password fields are not matching. Please ensure password/retype password are the same” and an OK button. When the user clicks on the OK button on the dialog box, the system should dismiss that dialog box and the user should be at the Create account page where the user can enter the information again. If a textbox was left empty and the user clicked the Submit button then a dialog box should inform the user to fill that empty textbox.

Case study software requirement management – OBAAS 1. 1 Check account balance use case for OBAAS 1. 1

Case study software requirement management – OBAAS 1. 1 • • Since OBAAS is not connected to any real bank account, when the online account is created for a user, there will be no balance in the account. Testing such a system for functions such as bill payment or money transfer will not be possible. Therefore, we will be depositing US$ 500 in the user’s account when the account is created in OBAAS. When the user clicks on the Account balance menu, the Account balance page appears. On this screen, a form is displayed with textboxes for Account number, Username, and Password. The textbox for Password should not display the characters and should show only an asterisk for each character entered by the user. There also two buttons, Submit and Clear, on this form. If the user fills these textboxes and clicks on the Submit button the information submitted by the user should be checked for correctness by matching it with the information in the database and if it is found to be correct then the amount should be displayed in the next screen.

Case study software requirement management – OBAAS 1. 1 • If the user fills incorrect information and clicks on the Submit button then a dialog box should appear with the message “The username/password you entered is incorrect. Please enter correct entries” and an OK button. When the user clicks on the OK button on the dialog box, the system should dismiss that dialog box and the user should be at the Account balance page where he/she can enter the information again. If a textbox was left empty and the user clicked the Submit button then a dialog box should inform the user to fill that empty textbox. There should be a Clear button on the Account balance page to reset all the text fields at any time.

Case study software requirement management – OBAAS 1. 1 Service request use case for OBAAS 1. 1

Case study software requirement management – OBAAS 1. 1 • When the user clicks on Service request menu, the Service request page should appear. Currently, using the Service request page, a user can only request a cheque book from the bank. On receiving a cheque book request, the bank will send a new cheque book, through a courier service, to the address that was provided by the user while creating the account online. On this Service request page, a form should be displayed with textboxes for Account number, Username, and Password. There should be a Service request dropdown menu with only cheque book request item in it. There should also two buttons, Submit and Clear, on this form. The textbox for Password should not display the characters and should show only an asterisk for each character entered by the user.

Case study software requirement management – OBAAS 1. 1 • If the user fills the textboxes and selects “request a cheque book” from the dropdown list for Service request and clicks on the Submit button the information submitted by the user should be checked for correctness by matching it with the information in the database and if it is found to be correct then a message confirming the cheque book issue should be displayed. If the user fills incorrect information in the checkboxes and clicks on the Submit button then a dialog box should appear with the message “The username/password you entered is incorrect. Please enter correct entries” and an OK button. When the user clicks on the OK button on the dialog box, the system should dismiss that dialog box and the user should be at the Service request page where he/she can enter the information again. If a textbox was left empty and the user clicked the Submit button then a dialog box should inform the user to fill that empty textbox. There should be a Clear button on the Service request page to reset all the text fields at any time.

Case study software requirement management – OBAAS 1. 1 Bill payment use case for OBAAS 1. 1

Case study software requirement management – OBAAS 1. 1 • When the user clicks on Bill pay menu, the Bill pay page appears. Currently, using the Bill pay page, a user can only pay the bills for two different service providers (billers). On this Bill pay page, a form should be displayed with textboxes for Account number, Username, Password, and Amount. There should also be a dropdown menu for selecting the Biller. There should be two buttons, Submit and Clear, on this form. The textbox for Password should not display the characters and should show only an asterisk for each character entered by the user.

Case study software requirement management – OBAAS 1. 1 • If the user fills the textboxes and selects a biller from the dropdown list and clicks on the Submit button the information submitted by the user should be checked for correctness by matching it with the information in the database and if it is found to be correct then that amount should be transferred to the account of the Biller and the same amount should be subtracted from the account of the user. A screen confirming the bill payment should be displayed to the user. The system will also check in the database if the account of the user has enough account balance to pay the bill. A message “Not sufficient funds in the account. This transaction cannot be performed” should be displayed to the user in case of insufficient funds. The user can dismiss this message box by clicking on its OK button. After dismissing the message box the user will be displayed the bill payment page again. The user can pay another bill of any amount equal to or less than the balance in the account.

Case study software requirement management – OBAAS 1. 1 Close account use case for OBAAS 1. 1

Case study software requirement management – OBAAS 1. 1 • When the user clicks on Close account menu, the Close account page should appear. On this screen, a form should be displayed with textboxes for Account number, Username, and Password. There should be two buttons, Submit and Clear, on this form. The textbox for Password should not display the characters and should show only an asterisk for each character entered by the user.

Case study software requirement management – OBAAS 1. 1 • If the user fills these textboxes and clicks on the Submit button the information submitted by the user should be checked for correctness by matching it with the information in the database and if it is found to be correct then the account closure page should be displayed to the user. If the user fills incorrect information and clicks on the Submit button then a dialog box should appear with the message “The username/password you entered is incorrect. Please enter correct entries” and an OK button. When the user clicks on the OK button on the dialog box, the system should dismiss that dialog box and the user should be at the Close account page where he/she can enter the information again. If a textbox was left empty and the user clicked the Submit button then a dialog box should inform the user to fill that empty textbox. There should be a Clear button on the Close account page to reset all the text fields at any time.

Case study software requirement management – OBAAS 1. 2 System use case for OBAAS 1. 2

Case study software requirement management – OBAAS 1. 2 Money transfer use case for OBAAS 1. 2

Case study software requirement management – OBAAS 1. 2 • When the user clicks on Money transfer menu then Money transfer page should appear. On this screen, a form is displayed with textboxes for Username, Password, From Account (the user account number), Amount, and To account (the account number of the party to which the money will be transferred) fields. There also two buttons, Submit and Clear, on this form. The textbox for Password should not display the characters and should show only an asterisk for each character entered by the user. If the user fills the textboxes and clicks on the Submit button the information submitted by the user should be checked for correctness by matching it with the information in the database. If the account balance of the user, prior to this transaction, is higher than or equal to the amount that needs to be transferred then the system should proceed with the transaction.

Case study software requirement management – OBAAS 1. 2 • When the transaction is successful then the system should display a message containing the amount that was transferred and the account number to which the money was transferred. If the account balance is less than the amount to be transferred then an error message should be displayed on a dialog box informing the user about the insufficient funds. If the user fills incorrect information and clicks on the Submit button then a dialog box should appear with the message “The username/password you entered is incorrect. Please enter correct entries” and an OK button. When the user clicks on the OK button on the dialog box, the system should dismiss that dialog box and the user should be at the Money transfer page where he/she can enter the information again. If a textbox was left empty and the user clicked the Submit button then a dialog box should inform the user to fill that empty textbox. There should be a Clear button on the Money transfer page to reset all the text fields at any time.

Case study software requirement management – OBAAS 1. 2 Service request use case for OBAAS 1. 2

Case study software requirement management – OBAAS 1. 2 • When the user clicks on Service request menu, the Service request page should appear. On receiving a cheque book request, the bank will send a new cheque book, through a courier service, to the address that was provided by the user while creating the account online. On this screen, a form should be displayed with textboxes for Account number, Username, and Password. There is also a Service request dropdown menu. There also two buttons, Submit and Clear, on this form. The textbox for Password should not display the characters and should show only an asterisk for each character entered by the user. If the user fills the textboxes and selects “request a cheque book” from the dropdown list for Service request and clicks on the Submit button the information submitted by the user should be checked for correctness by matching it with the information in the database and if it is found to be correct then a message confirming the cheque book issue should be displayed.

Case study software requirement management – OBAAS 1. 2 • If the user fills incorrect information and clicks on the Submit button then a dialog box should appear with the message “The username/password you entered is incorrect. Please enter correct entries” and an OK button. When the user clicks on the OK button on the dialog box, the system should dismiss that dialog box and the user should be at the Service request page where he/she can enter the information again. If a textbox was left empty and the user clicked the Submit button then a dialog box should inform the user to fill that empty textbox. There should be a Clear button on the Money transfer page to reset all the text fields at any time. In OBAAS 1. 2, there is a service fee of US$ 5 for each cheque book request. This fee should be deducted from the bank account of the user. If the user’s bank account balance is below US$ 5 then the service request for a cheque book should not be entertained. A dialog box with a message “insufficient funds” should be displayed to the user in such case.

Case study software high level design – OBAAS 1. 1 Component diagram for OBAAS 1. 1

Case study • • software high level design – OBAAS 1. 1 Account balance: The use case states that the user can find the account balance of his/her bank account. In the component design, the account balance page searches the account database to find the account balance for the user. Service request: The use case states that the user can request a new cheque book from the bank. The user can go to the service request page. The user selects the cheque issue service request from a drop down list at the service request page. When a cheque book is issued, the service database is updated.

Case study software high level design – OBAAS 1. 1 • • • Bill payment: The use case states that the user can pay the bills using OBAAS. In the component design, when the user wants to pay a bill he/she goes to the Bill payment page. The user selects a service provider from the list then the user can pay the bill amount from the Bill payment page. After bill payment, the user account is updated because the bill payment is done from the user account. New account: The use case states that a user can create a new account in OBAAS. In the component design, the account creation page lets the user to create his/her account in the system. Account closure: The use case states that the user can close his/her online bank access account. In the component diagram, an account closure page is provided so that the user can close the account.

Case study software high level design – OBAAS 1. 2 Component diagram for OBAAS 1. 2

Case study software high level design – OBAAS 1. 2 has 2 differences as compared to OBAAS 1. 1. There is a additional feature for money transfer facility between any bank accounts. Account holders can transfer money from their own bank account to any other bank account. The other difference is that there is a service fee of $5 for new cheque book requests. This amount will be deducted from the bank account of the account holder.

Case study software high level design – OBAAS 1. 1 Data flow diagram for OBAAS 1. 1

Case study software high level design – OBAAS 1. 2 Data flow diagram for OBAAS 1. 2

Case study software high level design – OBAAS 1. 2 Data flow diagram for OBAAS 1. 1 & OBAAS 1. 2 are depicted in above diagrams. A data flow diagram shows data flows when some event gets triggered and some business logic runs. The data flow starts from an external entity and passes through a process (business logic). Finally data manipulation or data view is done in an data store.

Case study software user interface design – OBAAS 1. 1 Create account user screen for OBAAS 1. 1

Case study software user interface design – OBAAS 1. 1 Create account response user screen for OBAAS 1. 1

Case study software user interface design – OBAAS 1. 1 Dialog box for incorrect username / password in OBAAS 1. 1

Case study software user interface design – OBAAS 1. 1 Account user balance screen for OBAAS 1. 1

Case study software user interface design – OBAAS 1. 1 Account balance response user screen for OBAAS 1. 1

Case study software user interface design – OBAAS 1. 1 Bill payment user screen for OBAAS 1. 1

Case study software user interface design – OBAAS 1. 1 Bill payment response user screen for OBAAS 1. 1

Case study software user interface design – OBAAS 1. 1 Service request user screen for OBAAS 1. 1

Case study software user interface design – OBAAS 1. 1 Service request user screen for OBAAS 1. 1

Case study software user interface design – OBAAS 1. 1 Close account user screen for OBAAS 1. 1

Case study software user interface design – OBAAS 1. 1 Close account user screen for OBAAS 1. 1

Case study software user interface design – OBAAS 1. 2 Service request user screen for OBAAS 1. 2

Case study software user interface design – OBAAS 1. 2 Service request user screen for OBAAS 1. 2

Case study software user interface design – OBAAS 1. 2 Money transfer user screen for OBAAS 1. 2

Case study software user interface design – OBAAS 1. 2 Money transfer user screen for OBAAS 1. 2

Case study software middle layer design – OBAAS 1. 1 Class diagram for OBAAS 1. 1

Case study software middle layer design – OBAAS 1. 1 Class diagram for OBAAS 1. 1 is shown above. In the classes we have created, we can see that we have not included database connection management. We will discuss database connection management now as all transaction in OBAAS results in saved or modified records in the database system. From the component design we can also see that database connection is required on each web page many times. This means, the connection with the database is an activity that is required to be performed many times. You can also realize that each class we have designed in OBAAS will be connecting to the database many times. Thus it will be better to pool all the database connection related activities inside a pool of specialized classes which will be dealing only with database connection management.

Case study software middle layer design – OBAAS 1. 1 From the requirement specifications (use cases) described in Chapter 4, we can see that for each activity on the user interface, the user is required to provide the username, password, and account number for authentication. This means that each of the activities of checking account balance, bill payment, service request, and account closure are independent of each other. If there is only one response for each of these activities then the system no longer keeps the information about a user after the completion of each of these activities. Thus, we do not need to keep the session variables to keep the information about a user after an activity gets completed. As we can see that each activity involves the authentication of a user by checking the database entries for username, password, and account number; authentication function is being used many times. Thus, we need to create a class for authentication function so that we do not need to write the source code for authentication function over and over.

Case study software middle layer design – OBAAS 1. 1 object diagram for OBAAS 1. 1

Case study software middle layer design – OBAAS 1. 1 • • The object diagram depicted in above Figure shows the state of the objects at a time when one object was processing bill payment and another one was processing a service request. Each of these objects is linked to the corresponding Account and User objects. In this figure, you can see that user with a user_ID 1223 is using OBAAS for a bill payment. At the same time, another user with a user_ID 4523 is using OBAAS for a service request. You can create many object diagrams for OBAAS to fully understand its functionality and how to design the application. For example, you can create another object diagram where one user is creating a new account and at the same time, 2 more users are doing some other transactions in OBAAS.

Case study software middle layer design – OBAAS 1. 1 sequence diagram for OBAAS 1. 1

Case study software middle layer design – OBAAS 1. 1 • • Sequence diagram for Bill_payment process for OBAAS is shown in above Figure. The user needs to provide the Username, Password, amount and Account number into the user interface of OBAAS for bill payment. The user also needs to select the biller from the drop down list. When the user clicks on Submit button then, first, the authentication() method of the User object is invoked by the Account object to verify the user. The payment_request() method is invoked later by the Account object. After bill payment, the response() method is self called by the bill_payment object. You can create similar sequence diagrams to fully design OBAAS.

Case study software middle layer design – OBAAS 1. 1 statechart diagram for OBAAS 1. 1

Case study software middle layer design – OBAAS 1. 1 The statechart diagram for OBAAS 1. 1 is given in above Figure. Please note that we have used commonly understandable English words in place of actual method names to understand this diagram better. This statechart diagram describes the states through which an object of Bill pay type goes through from its initialization to finish. First this object is created (by a call in the software application). At the initial state, the Bill pay object is idle. When this object is initialized to perform a bill payment transaction, the first state it goes through is when the bill payment object becomes active and is loaded on the web page. In this state, the list of billers is also loaded in the object. When a bill type (i. e. , the biller) is selected by the user then this object moves in the next state “Select bill”. Naturally this state is invoked by a user. Then the user enters the amount to be paid against the bill. The user then pays the bill by clicking the Submit button on the user screen. At this stage, the bill payment object is in “Pay bill” state. The next state into which the bill payment object will move in is “Show receipt” stage. This stage in the life of the bill pay object is in the form of a response page where the bill payment statement is shown. After the response page is displayed, the bill payment object is destroyed. This is the complete lifecycle of the bill payment object.

Case study software middle layer design – OBAAS 1. 1 In the Figure given above, the mapping of words used with the states of the object with the actual methods and properties is given here: Bill payment – populate biller list in the dropdown list Select bill – select biller from dropdown list Input amount – paid_amount Pay bill – payment_request() Show receipt – response() Cancel bill – cancel button press You can draw similar statechart diagrams for other objects such as service request, account balance enquiry, etc.

Case study software middle layer design – OBAAS 1. 2 class diagram for OBAAS 1. 2

Case study software middle layer design – OBAAS 1. 1 • The class diagram for OBAAS 1. 2 (above Figure) includes the money transfer class. All other classes remain the same as in OBAAS 1. 1. This new class “Transfer_Money” is used to take care of the methods and properties that will be needed for money transfer from one bank account to another bank account. Currently OBAAS only supports money transfer between bank accounts which are kept in the same bank.

Case study software middle layer design – OBAAS 1. 2 object diagram for OBAAS 1. 2

Case study software middle layer design – OBAAS 1. 1 • The object diagram depicted in above Figure shows the state of the objects at a time when one object was processing bill payment and another one was processing a service request and a third object was processing money transfer. Each of these objects is linked to the corresponding Account and User objects.

Case study software middle layer design – OBAAS 1. 2 While discussing the class diagram, we mentioned about refactoring the classes to make it possible to reuse the source code. This is possible because we can create classes for the database connection and user verification. The methods from these classes will be used frequently by other classes. The main tasks associated with account balance enquiry, new account creation, bill payment, service request, and account closure can be implemented by using classes. These classes can be compiled and stored at the application server. This alternative is good when a large number of web pages will be using these classes. Another alternative is to write the source code for these classes directly on the web pages in the form of client-side scripts. This approach is fine when each class is used only on a few pages thus there is not much repetition of source code. We have used this approach to build OBAAS. While classes have been built for reusing the source code for database connections and user verification, the classes that implement all the required functionality for accomplishing the tasks related to account balance enquiry, bill payment, and account closure can be put inside the server-side scripts. There is another aspect that we have considered. If you look closely at the requirement specifications, you will find that, out of all the functionality in OBAAS, there are only two components that deal with the creation of new records in the database. The first one is the creation of a new bank account and the other is the cheque book request. We decided to create compiled classes to achieve these functionalities. All other functionalities have been implemented using server-side scripts.

Case study software middle layer design – OBAAS 1. 2 The final solution that we have implemented includes a controller as well. This controller has been implemented to identify the user interface from which a request is coming. Based on the user interface, from which a request comes, further processing is redirected to the appropriate piece of source code. For example, if the user request came from the user interface for creating a new account then this request will be redirected to the source code that implements the functionality to create a new account. The final solution consists of the following classes: Create servlet: This class is the controller that redirects the user requests to various pieces of source code. DBInitializer: This class contains information about the database connection string. Get. Con: This class tests the connection to the database. Register. User: This class implements the creation of a new account as well as the creation of a new cheque book. Verify. User: This class verifies the user by comparing the input values, entered by the user for username, password, and account number, with the values existing in the database.

Case study software middle layer design – OBAAS 1. 1 The use cases mention about user validation for the inputs provided by the user. All user validations have been implemented in the client-side scripts. These validations include: • Password - repassword check • Field left blank check • String input in a numeric field • Numeric input in a field which should accept only string values

Case study software middle layer design – OBAAS 1. 1 There also validations to check • The amount in a bank account should be sufficient to cover the transfer of money into another bank account. For example, if an account has an opening balance of US$ 300 and the user who owns this account wants to transfer US$ 400 into another account then the validation is there to stop such transactions. The user is provided with a message stating that there is not sufficient amount in the bank account and so this transaction cannot be completed. • For OBAAS 1. 2, there is a fee of US$ 5 for issue of a new cheque book. This fee is deducted from the bank account of the user. The amount in the bank account of the user should be equal to or more than US$ 5 to cover the charge for the issue of the cheque book. Else the user is provided with a message stating that the amount is not sufficient in the bank account and so this transaction cannot be completed. All the above mentioned validations cannot be implemented through client-side scripts. It is because these validations need a check in the database to find out the balance amount in the bank account of the user. For this reason, these validations have been implemented using server-side scripts.

Case study software database design – OBAAS 1. 1 Entity relationship diagram for OBAAS 1. 1 & OBAAS 1. 2

Case study software database design – OBAAS 1. 1 Based on the ER diagram, the schema and database entities have been created. Even though there are many types of transactions being done in OBAAS, some of them are similar in nature. For example, bill payment and transfer fund transactions are very similar. In both these transactions, fund transfer happens from one account into another account (in case of bill payment, fund transfer happens from the user account to the account of the biller). Transactions such as close account, transfer fund, bill payment, and balance enquiry exclusively deal with the account entity. However, service request transaction deals with a service entity. Thus we can see that, for our purpose, only two tables are needed: one table deals with the user and account entities and the other table keeps information about the service requests. Account & user: For the account and user entities, “NEWACCOUNT” table has been created.

Case study software database design – OBAAS 1. 1 CREATE TABLE "NEWACCOUNT" ( "ACCOUNTNO" NUMBER, "USERNAME" VARCHAR 2(40), "PASSWORD" VARCHAR 2(40), "REPASSWORD" VARCHAR 2(40), "AMOUNT" NUMBER, "ADDRESS" VARCHAR 2(400), "PHONE" NUMBER, “CATEGORY” VARCHAR 2(1), CONSTRAINT "NEWACCOUNT_PK" PRIMARY KEY ("ACCOUNTNO") ENABLE ); Service request: For taking care of service requests, a table named CHEQUEBOOK has been created. CREATE TABLE "CHEQUEBOOK" ( "ACCOUNTNO" NUMBER, "SERVICETYPE" VARCHAR 2(1), ); We also need a sequence to populate the data in the primary key field “ACCOUNTNO” in the “NEWACCOUNT” table. CREATE SEQUENCE BANK_SEQ MINVALUE 1 MAXVALUE 999999 INCREMENT BY 1 START WITH 1 NOCACHE NOORDER NOCYCLE;

Case study software database design – OBAAS 1. 1 • • Table “NEWACCOUNT” is the main table in the OBAAS database and it holds most of the data used in OBAAS. It holds information for username, password, phone number, address, and account number. In OBAAS, at present, we are creating a service number whenever a cheque book is issued. We are using “SERVICENO” column of “CHEQUEBOOK” table to populate the service numbers. For these services, we have currently created a table “CHEQUEBOOK”. It is named so because currently there is only one service: cheque book issue. In future, when other services are introduced, this table name will be changed accordingly (as part of refactoring). In future, there could be many services introduced by the bank. So, we have created a service type field (i. e. , a column) in this table to represent different types of services. The “CHEQUEBOOK” table is a transaction table. The “ACCOUNTNO” field in this table is actually a foreign key and the corresponding primary key is the “ACCOUNTNO” column of the “NEWACCOUNT” table. We have not defined a primary key – foreign key relationship between these two tables. This is because once a service number is generated, it is only shown if needed (i. e. , it does not need to be modified or deleted). For such a scenario, a foreign key is not needed. As per the software requirement specifications (SRS), there are no reports to be shown for the transactions. For example, the SRS does not mention the transaction history reports for the customers. So, we are not generating any transaction numbers for the transactions, including the money transfer and bill payments transactions (when they happen). Thus, in the database, we have not provided any columns to keep these transaction numbers.

Case study software database design – OBAAS 1. 1 • Database transactions such as insert, update, and delete have been used in OBAAS when users interact with it. For example, when the user wants to create a new account in OBAAS then an insert operation takes place in the “new_account” table so that a new record can be created in this table for the user. Similarly, when the user wants to pay a bill then the “new_account” table gets updated. The billers account is credited and the user’s account is debited by the amount of the bill which needs to be paid.

Software testing (verification & validation) for OBAAS involved doing unit, integration and system testing for the entire software product. Unit testing was done to check business logic of each class. For example, the Verify. User class was unit tested to find out if a user could be validated by comparing user input for username, password and account number with the existing data in the database. Usability tests were done to check all navigation links and menus were working fine. Non functional tests included security and performance tests. Functional testing included checking the user input validations, validations to check enough prior account balance before doing transactions for cheque issue, money transfer and bill payments. Functional testing also included checking complete functionality of account balance, new account creation, cheque issue, money transfer, bill payment and account closure.