Chirag Sharma

01096202718
T-17
PART-A
1. Case Study of Problem Statement

Bank management system is the complicated software system which is aimed at the professional
management of the client’s activities in the bank and high-quality and quick access to the client’s account.
With the rapid development of the banking system, the necessity of the high-quality bank management
system has become extremely relevant. Today, there is hardly a person in the world who is not involved
into the banking services and naturally, everyone has an account in a bank and saves money there. It is
obvious that everyone wants to have the constant access to his finance but it is impossible without the
high-quality management system which provides clients with such opportunities 24/7. Naturally, the
financial institutions work only in the definite hours of the day, but if the client requires the access to his
finance at night or does not have the opportunity to come to the bank, his wish will be failed. In order to
enable clients operate their accounts well, the bank management system was created

Today, due to the development of the online banking the opportunities of both the financial institutions
and clients have become extremely wide. With its help clients can operate their finance faster and fulfil
more operations at a moment’s notice making the whole banking system more rapid and dynamic. The
system stores the information about clients, their withdrawals and deposits and helps them manage and
monitor their finance effectively increasing the trust to the banking services.

Bank management systems are extremely popular and effective nowadays, because they improve the
quality of the banking services and help clients operate their finance better. When a student is asked to
analyse the definite case on bank management system, he will have to get to know about the system
itself in order to be able to analyse this question deeper later. A successful bank management system
case study should explain the purpose of the research of the problem, describe the problem itself and
touch upon its core aspects. Furthermore, one should collect data on the problem to learn about its cause
and effect in order to be able to brainstorm the effective solutions to the problem and demonstrate his
professional and critical thinking skills
In order to cope with the process of case study writing the student should take advantage of the reliable
help of the Internet and follow the expert’s manner of writing and professional way of data analysis
reading a free example case study on bank management system. Due to a well-organized free sample
case study on bank management system prepared by an expert a student learns about the process of the
right formatting and construction of the logical structure ad succeeds in writing

2. Detailed SRS

1. Introduction

This document gives detailed functional and non-functional requirements for the bank management
system. This product will support online banking transaction. The purpose of this document is that the
requirements mentioned in it should be utilized by software developer to implement the system.

1.1 Purpose
Online banking system provides is specifically developed for internet banking for Balance Enquiry, Funds
Transfer to another account in the same bank, Request for cheque book/change of address/stop payment
of cheques, Mini statements (Viewing Monthly and annual statements).

The Traditional way of maintaining details of a user in a bank was to enter the details and record them.
Every time the user need to perform some transactions he has to go to bank and perform the necessary
actions, which may not be so feasible all the time. It may be a hard-hitting task for the users and the
bankers too. The project gives real life understanding of Internet banking and activities performed by
various roles in the supply chain. Here, we provide an automation for banking system through Internet.
Internet banking system project captures

activities performed by different roles in real life banking which provides enhanced techniques for
maintaining the required in- formation up-to-date, which results in efficiency. The project gives real life
understanding of Internet banking and activities performed by various roles in the supply chain.

1.2 Scope

This Product will automate of banking transaction process.This Project investigates the entry threshold
for providing a new transaction service channel via the real options approach, where the entry
threshold is established by using an Internet banking system designed for the use of normal
users(individuals), Industrialists, Entrepreneurs, Educational Institutions(Financial sections), Organizations
and Academicians under transaction rate uncertainty.

1.3 Overview

The system provides easy solution to banks.

Overview: The SRS will include two sections, namely:

Overall Description: This section will describe major components of the system, interconnections, and
external interfaces.

Specific Requirements: This section will describe the functions of actors, their roles in the system and
the constraints faced by system.

2. General description

2.1 Product Perspective:

The client will have client interface in which he can interact with the banking sys- tem. It is a web based
interface which will be the web page of the banking application. Starting a page is displayed asking the
type of customer he is whether ordinary or a corporate customer. Then the page is redirected to login
page where the user can enter the login details. If the login particulars are valid then the user is taken to a
home page where he has the entire transaction list that he can perform with the bank. All the above
activities come under the client interface.

The administrator will have an administrative in- terface 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 his actions. This administrative interface provides different environment such that he can
maintain data- base & 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
cheque book request & perform action to issue the cheque books to the clients.
2.2 Software Interface:

Front End Client:

The system is a web based application clients are requiring using modern web browser such as
Mozilla Firefox 1.5, PHP.

* Web Server:

The web application will be hosted on one of the apache server.

* Back End:

We use backend as MY SQL.

3. Functional Specifications

This section provides the functional overview of the product. The project will require the PHP as a front
end and at the back end the database MYSQL will be running. Various functional modules that can be
implemented by the product will be

1. Login

2. Validation

3. Get balance information

4. Withdrawal of money

5. Transfer Money

6. Customer info.

3.1 Login:

Customer logins by entering customer name & a login pin.

3.2 Validation:

When a customer enters the ATM card, its validity must be ensured. Then customer is allowed to enter
the valid PIN. The validation can be for following conditions

Validation for lost or stolen card

When card is already reported as lost or stolen

then the message “Lost/Stolen card!!!”.

Validation for card’s expiry date

If the card inserted by the customer has crossed the expiry date then the system will prompt

“Expired Card”.

Validation for PIN

After validating the card, the validity of PIN must be ensured. If he/she fails to enter valid code for three
times then the card will not be returned to him. That means the account can be locked. The counter for
number of logins must be maintained

Get balance information:

This system must be networked to the bank’s computer. The updated

database of every customer is maintained with bank. Hence the balance information of every account is
available in the database and can be displayed to the customer.

3.3 Payment of Money:

A customer is allowed to enter the amount which he/she wishes to withdraw. If the entered amount is
less than the available balance and if after withdraw if the minimum required balance is maintained then
allow the transaction.

3.4 Transfer of Money:

The customer can deposit or transfer the desired amount of money.

3.5 Transaction Report:

The bank statement showing credit and debit information of corresponding account must be printed by
the machine.

3.6 Technical Issues

This product will work on client-server architecture. It will require an internet server and which will be
able to run PHP applications. The product should support some commonly used browsers such as Internet
Explorer, Mozilla Firefox.

4. Interface Requirements

4.1 GUI

This is interface must be highly intuitive or interactive because there will not be an assistance for the user
who is operating the System. At most of the places help desk should be provided for users convenience.
The screens appearing should be designed in such a manner that it can draw User attraction towards the
new plans for the customers.

Also the pin and password confidentiality should be maintained,

This can be done by using asterisks at the password panel.

Proper security messages should be displayed at most of the places.

4.2 Hardware Interfac

Various interfaces for the product could be

1. Touch screen/Monitor

2. Keypad
3. Continuous battery backup

4. Printer which can produce the hard copy.

5. Interface that connects the device to bank’s computer.

6. An interface that can count currency notes.

4.3 Software Interface

1. Any windows operating system

2. The PHP must be installed. For the database handling MYSQL must be installed. These products are
open source products.

3. The final application must be packaged in a set up program, so that the products can be easily installed
on machines. This application must be networked to corresponding banks.

5. Performance Requirements

The system should be compatible enough to hold the general traffic .

It should not get hang or show some other problems arising out due to large no of concurrent users . The
system should be fast enough to meet the customer The high and low temperature should not affect the
performance of the device. An uninterrupted transaction must be performed.

6.Constraints

* The information of all the users must be stored in a database that is accessible by the Online Banking
System.

* The Online Banking System is connected to the computer and is running all 24hours a day.

* The users access the Online Banking System from any computer that has Internet browsing
capabilities and an Internet connection.

*The users must have their correct usernames and passwords to enter into the Online Banking System.

Design Constraints

* Software Language Used

The languages that shall be used for coding Online Banking System are c , c++ , java , and HTML. For
working on the coding phase of the Online job portal System Web Sphere Application
Server/WebSphere Application Server CE Server needs to be installed.

*Database design

In our database design, we give names to data flows, processes and data stores. Although the names are
descriptive of data, they do not give details .So following DFD, our interest is to build some details of the
contents of data flows, processes and data store. A data dictionary is a structured repository of data
about data .It is a set of rigorous definitions of all DFD data elements and data structures .

7. Performance

7.1 Security
The banking system must be fully accessible to only authentic user.

It should require pin for entry to a new environment.

7.2 Reliability

The application should be highly reliable and it should generate all the updated information in correct
order

7.3 Availability

Any information about the account should be quickly available from any computer to the authorized user.
The previously visited customer’s data must not be cleared.

7.4 Maintainability

The application should be maintainable in such a manner that if any new requirement occurs then it
should be easily incorporated in an individual module.

7.5 Portability

The application should be portable on any windows based system. It should not be machine specific.

8 References:

www.w3schools.com

www.roseindia.net

www.dbforums.com

www.ibm.com

http://tomcat.apache.org/

3. Requirement Gathering Technique used

Requirement engineering
Requirement Engineering is the process of defining, documenting and maintaining the
requirements. It is a process of gathering and defining service provided by the system.
Requirements Engineering Process consists of the following main activities:
 Requirements elicitation
 Requirements specification
 Requirements verification and validation
 Requirements management
Requirements Elicitation:
It is related to the various ways used to gain knowledge about the project domain and
requirements. The various sources of domain knowledge include customers, business
manuals, the existing software of same type, standards and other stakeholders of the
project.
The techniques used for requirements elicitation include interviews, brainstorming, task
analysis, Delphi technique, prototyping, etc. Some of these are
discussed here. Elicitation does not produce formal models of the requirements
understood. Instead, it widens the domain knowledge of the analyst and thus helps in
providing input to the next stage.
Requirements specification:
This activity is used to produce formal software requirement models. All the
requirements including the functional as well as the non-functional requirements and
the constraints are specified by these models in totality. During specification, more
knowledge about the problem may be required which can again trigger the elicitation
process.
The models used at this stage include ER diagrams, data flow diagrams(DFDs),
function decomposition diagrams(FDDs), data dictionaries, etc.
Requirements verification and validation:
Verification: It refers to the set of tasks that ensures that the software correctly
implements a specific function.
Validation: It refers to a different set of tasks that ensures that the software that has
been built is traceable to customer requirements.
If requirements are not validated, errors in the requirement definitions would propagate
to the successive stages resulting in a lot of modification and rework.
The main steps for this process include:
 The requirements should be consistent with all the other requirements i.e no two
requirements should conflict with each other.
 The requirements should be complete in every sense.
 The requirements should be practically achievable.
Reviews, buddy checks, making test cases, etc. are some of the methods used for this.
Requirements management:
Requirement management is the process of analyzing, documenting, tracking,
prioritizing and agreeing on the requirement and controlling the communication to
relevant stakeholders. This stage takes care of the changing nature of requirements. It
should be ensured that the SRS is as modifiable as possible so as to incorporate
changes in requirements specified by the end users at later stages too. Being able to
modify the software as per requirements in a systematic and controlled manner is an
extremely important part of the requirements engineering process.

Technique used in requirement gathering

Survey/Questionnaire

When collecting information from many people – too many to interview with budget and
time constraints – a survey or questionnaire can be used. The survey can force users to
select from choices, rate something (“Agree Strongly, agree…”), or have open ended
questions allowing free-form responses. Survey design is hard – questions can bias the
respondents.

We used survey/Questionnaire for requirement gathering because of following points;

The advantages of questionnaires

In our Project we gathered requirements of software using Surveys. Google Forms were created
with specific questions and respective options that users may want from our software. We used
Google Forms due to the following reasons:

 Google forms allows us to see how the survey will look before sending it over to the recipients.

 It is a free online tool, that allowed collection of information easily and efficiently.

 It’s interface is very easy to use which makes creating a form much simpler.

 The assistant is simple to use. The What-You-See-Is-What-You-Get interface makes it easy to

drag and drop form elements and organize them based on actions or events.

 At the design level it is possible to choose between a palette of colors, as well as own images as
a background that can add visual aids related to our project.

 It stores the feedback received so we can analyze it in detail.

 The forms are integrated with Google spreadsheets therefore we can access to a spreadsheet
view of the collected data.

 The general configuration of forms or surveys allows you to collect the recipient’s email
address and limit the answers.

 For advanced users, the type of data that can be inserted into a field can be customized using
regular expressions. This helps customize the form even more.

 We can send the form by email, or send the link via social networks or any other means.

 With this tool, you can get unlimited questions and answers at no cost, while other survey tools
require a payment depending on the number of questions and recipients.

Google form link

https://docs.google.com/forms/d/e/1FAIpQLScGjqjLV-
VK8fFO9UJMVS_4UZmGf2aQCS4hQcytc87Q0AqfFw/viewform?
usp=sf_link
Responses
4. Analysis of Requirement into Functional And Non-
Functional Requirement

Functional Requirements: These are the requirements that the end user
specifically demands as basic facilities that the system should offer.
All these functionalities need to be necessarily incorporated into the
system as a part of the contract. These are represented or stated in the
form of input to be given to the system, the operation performed and
the output expected. They are basically the requirements stated by the
user which one can see directly in the final product, unlike the non-
functional requirements.

Non-functional requirements: These are basically the quality constraints that

the system must satisfy according to the project contract. The priority or
extent to which these factors are implemented varies from one project to
other. They are also called non-behavioural requirements.
They basically deal with issues like:
 Portability
 Security
 Maintainability
 Reliability
 Scalability
 Performance
 Reusability
 Flexibility

Functional Requirements Non Functional Requirements

A functional requirement defines a A non-functional requirement defines

system or its component. the quality attribute of a software
system

It specifies “What should the It places constraints on “How should

software system do?” the software system fulfill the
functional requirements?”
Functional requirement is specified Non-functional requirement is
by User. specified by technical peoples e.g.
Architect, Technical leaders and
software developers.

It is mandatory. It is not mandatory.

It is captured in use case. It is captured as a quality attribute

Defined at a component level. Applied to a system as a whole.

Helps you verify the functionality of Helps you to verify the performance of
the software. the software.

Functional Testing like System, Non-Functional Testing like

Integration, End to End, API testing, Performance, Stress, Usability,
etc are done. Security testing, etc are done.
Usually easy to define Usually more difficult to define.
Functional requirements of bank management system

4.1. Functional Requirement

General principles of requirements engineering is a distinction between requirements definitions

and requirements specifications. A software requirements definition is an abstract description of
the services which the system should provide and the constraints under which the system must
operate. And requirements definition is probably the most important technique in structured
analysis. It is the only technique that permeates every step of the method. It also is one of the
least pictorial, making it difficult to describe precisely. In essence, the technique involves
capturing what the users really want and making sure that every subsequent project activity leads
to the best possible transformation of those user needs into system needs which, when satisfied,
will deliver what the users wanted in the first place.

 Customer The valid customer on internet banking has a set of requirements he/she does on
internet banking. These requirements are offered on next pointes.

 Login A customer to be able to use this system, he/she has to enter username and password
which he/she has created before and been saved in the database in the Login page. This function
might be a customer or an Admin also. The input in this function most be valid username and
valid password and the output if the user is valid user then he/she will get into a page which can
makes has/her transaction, but if the user made wrong in username or password then he/she will
be invalid user and will see a message “Alert Invalid Username and Password” and to login again.

 View Account View Account allows to a customer to view today’s up-to the minute balance
information on deposit (saving/current), credit card, etc. The customer can also view transaction
history with retention period up to a maximum of 90 days. Within this feature, the customer can
request for account such as “view online, by e-mail or by post option. But the customer most be
logged in the internet banking.

 Transfer Funds The customer must be logged into Banking System to be able to make his/her
transaction for transfer funds. Transfer Funds allows customer to transfer funds between
authorized accounts – own personal accounts. Requested transfer take place immediately or at a
selected future date specified by customer. The customer can save up to a maximum of 10
accounts and update or delete the account details. All the outstanding future transfers are
recorded in a table. The customer can enquire whether there is any funds transfer pending and.
when the customer selects the Transfer funds, the system will display Menu to select Transfer
Funds function for transfer funds or Transfer History function for display the transaction he/she
done.

 Pay Bills The customer most be logged into Banking System. With internet banking, customers
can make payments to corporations that include utilities, assessments, Insurance,
telecommunications, and other services. The customers can use Online Pay Bill service to pay bills
by debiting their account. This payment made to payee corporations that the customer has
registered with internet banking by using the Registered Bill. But with new payee corporations
that the customer has not registered, this payment can be made immediately or at a later date

4.2. Non-functional Requirements

Non-functional requirements are requirements that are not directly concerned with the specific
functions delivered by the system. They may relate to emergent system properties such as
reliability, response time and store occupancy. They may specify system performance, security,
availability, and other emergent properties. This means that they are often more critical than
individual functional requirements. System users can usually find ways to work around a system
function that doesn’t really meet their needs. However, failing to meet a nonfunctional
requirement can mean that the whole system is unusable. Non-functional requirements needed
in this internet banking system are identified as performance requirements, safety requirements,
security requirements and software quality attributes.

4.2.1 Performance Requirements

 Increase Customer Satisfaction Internet banking system must allows customers to access
banking services 24 hours a day, 365 days a year with minimum downtime period for backup and
maintenance.

 Expand Product Offerings The new services allows bank to capture a larger percentage of their
customers’ asset base. The internet banking system will provide facilities for bank to offer new
services and products onto its homepage.

 Reduce Overall Costs It will help to reduce a bank’s costs in two fundamental ways: it minimize
the cost of processing transactions and reduces the number of branches required to service an
equivalent number of customer.

4.2.2 Safety Requirements

 Backup, recovery & business continuity Banks should ensure adequate back up of data as may
be required by their operations. Banks should also have, well documented and tested business
continuity plans that address all aspects of the bank’s business

1. Both data and software should be backed up periodically, the frequency of back up depending
on the recovery needs of the application. The back-up may be incremental or complete.
Automating the backup procedures is preferred to obviate operator errors and missed back-ups.
2. Recovery and business continuity measures, based on criticality of the systems, should be in
place and a documented plan with the organization and assignment of responsibilities of the key
decision making personnel should exist.

3. An off-site back up is necessary for recovery from major failures / disasters to ensure business
continuity. Depending on criticality, different technologies based on back up, hot sites, warm sites
or cold sites should be available for business continuity. The business continuity plan should be
frequently tested
5. Design – ER Diagram, USE case, Class diagram, Activity diagram, State diagram,
Sequence diagram etc.

ER DIAGRAM
USE CASE DIAGRAM

Level – 0 Data Flow Diagram :-

Level – 1 Data Flow Diagram :-

State Chart Diagram :

Activity Diagram :
Class Diagram :

Sequence Diagram :
PART-B
1. Design all possible test cases for Problem Statement.
1. Verify the admin login with valid and Invalid test data
2. Verify the admin login without test data
3. Verify the all home links for admin role
4. Verify the admin change password with valid and invalid test data
5. Verify the admin change password without test data
6. Verify the admin change password with existing test data
7. Verify the admin logout successfully
8. Test cases for new Branch
9. Create new branch with valid and invalid test data
10. Create new branch without test data
11. Create new branch with existing branch data
12. Verify the reset and cancel option
13. Update branch details with valid and invalid test data
14. Update branch details without test data
15. Update branch details with existing branch test data
16. Verify the cancel option is working
17. Verify the branch deletion with and without dependencies
18. Verify branch search option
19. Test Cases for New Role
20. Create new role with valid and invalid test data
21. Create a new role without test data
22. Verify new role with existing test data
23. Verify the role description and role types
24. Verify the cancel and reset option is working
25. Verify role deletion process with and without dependency
26. Verify the links in role details page
27. This is really useful sample test case for banking application which I have described in
above case, now we can see some of test cases for customer and visitor
28. Test cases for customer and visitors
29. Verify the all visitor and customer links
30. Verify the customer login with valid and invalid test data
31. Verify the customer login without test data
32. Verify the banker login without data
33. Verify the banker login with valid or invalid test data
34. Test cases for New users
35. Create new user with valid and invalid test data
36. Create new user without test data.
37. Create new user with existing branch test data
38. Verify the cancel and reset option is working
39. Update user details with valid and invalid test data
40. Update user details with existing test data
41. Verify cancel option is working
42. Verify the deletion of the new user
43. Test cases for opening bank account
44. Verify mandatory input parameters
45. Verify optional input parameters
46. Create a new account entity.
47. Verify the user can deposit an amount in the newly created account (and thus
updating the balance)
48. Verify the user can withdraw an amount from the newly created account (after deposit)
(and thus updating the balance)
49. Verify the company name and its pan number and other details are provided in case
of salary account
50. Verify primary account number is provided in case of secondary account
51. Verify company details are provided in cases of current account
52. Verify the provided proofs for joint account in case of joint account
 53. Verify whether able to maintain zero balance in salary account
54. Verify whether able to maintain zero balance or minimum balance for non-salary
account.

2. Consider a program for the determination of the nature of roots of a  quadratic

equation. Its input is a triple of positive integers (say a,b,c) and  values may be from
interval [0,100]. The program output may have one of  the following words.
               [Not a quadratic equation; Real roots; Imaginary roots; Equal roots] 
              A) Design the boundary value test cases.
               B) Design the Robust test case and worst  test cases for this program.
               C) Identify the equivalence class test  cases for output and input domains.
               D) Identify the  test cases using the decision table.
E )Draw the Cause  effect graph and identify the test cases.

Answer A)
Quadratic equation will be of type: ax2+bx+c=0 Roots are real if (b2-4ac)>0 Roots are imaginary if
(b2-4ac)<0 Roots are equal if (b2-4ac)=0 Equation is not quadratic if a=0

B) Robust test cases are 6n+1. Hence, in 3 variable input cases total number of test cases are 19
In case of worst test case total test cases are 5n. Hence, 125 test cases will be generated in worst
test cases. The worst test cases are given below:
 C) Identify the equivalence class test  cases for output and input domains.
Output domain equivalence class test cases can be identified as follows: O1={<a,b,c>:Not a
quadratic equation if a = 0} O1={<a,b,c>:Real roots if (b2-4ac)>0} O1={<a,b,c>:Imaginary roots if
(b2-4ac)<0} O1={<a,b,c>:Equal roots if (b2-4ac)=0}` The number of test cases can be derived form
above relations and shown below:

We may have another set of test cases based on input domain.

I1= {a: a = 0}
I2= {a: a < 0}
I3= {a: 1 ≤ a ≤ 100}
I4= {a: a > 100}
I5= {b: 0 ≤ b ≤ 100}
I6= {b: b < 0}
I7= {b: b > 100}
I8= {c: 0 ≤ c ≤ 100}
I9= {c: c < 0}
I10={c: c > 100}
D) Identify the test cases using the decision table.

E) Draw the Cause effect graph and identify the test cases.
Cause and effect graph is a dynamic test case writing technique. Here causes are the input
conditions and effects are the results of those input conditions. Cause-Effect Graphing is a
technique which starts with set of requirements and determines the minimum possible test
cases for maximum test coverage The goal is to reduce the total number of test cases still
achieving the desired application quality.

The Causes and Effects are:

C1: a ≠ 0

C2: b = 0

C3: c = 0

C4: D > 0 where D is b2 – 4 * a * c

C5: D < 0

C6: D = 0

C7: a = b = c

C8: a = c = b/2

E1: Not a quadratic equation

E2: Real Roots

E3: Imaginary Roots

E4: Equal Roots

The Cause Effect graph is: