Learning Center
Plans & pricing Sign in
Sign Out



Requirements Analysis Document

NYEV Networking Solutions -

NYEV Banking System

15-612 Distributed Systems

Spring 1998

Carnegie Mellon University

Pittsburgh, PA 15213

Revision History:

Version 0.91, 02/18/98, Security Issues section added by Nelson Montalvo
Version 0.90, 02/17/98, Integrated by Vincent Mak and Nelson Montalvo


A high level description of the features of the NYEV Banking System.

Target Audience:

Client, Developers

NYEV Members:

Nelson Montalvo, Yenni Kwek, Eric Farng, Vincent Mak

1.0 General Goals

The primary goal of the NYEV Banking System is to create a distributed
banking system that is readily customizable to any bank. This system
should allow a bank customer (user) to view account balances and
histories, transfer between accounts, pay bills, etc. On the
administration side, accounts should be properly created and managed.

The NYEV Banking System will be built on a distributed architecture that
is extensible, scalable, relatively platform independent, highly
available, and secure. With these attributes, a side-goal is to create an
architecture that will be flexible enough to adapt for other business

2.0 Current System

Most large banks have already allowed their customers to access similar
systems over the World Wide Web. One US demo may be found on the Citibank
web site. The following are some sample screen shots from the Citibank
online banking system:

Figure 2.1 Sample screen shot of Citibank's Direct Access banking system

Figure 2.2 Sample shot of the accounts balance screen

Since our goal is to create a system that can be used by any bank, many
common features will be integrated into the system and many customized
features will be added later. As far as our research tells us, most
banking systems are built from the ground up. While this may be more
secure and affordable by the bigger banks, many smaller banks may not be
able to readily afford such custom systems.

3.0 Proposed System

3.1 Overview

The NYEV Banking System is a highly available and reliable online banking
system designed to provide several services to increase the efficiency
and convenience of all of its users. It uses Java, CORBA and Internet-
based technologies to provide a platform independent, distributed
computing environment based on the client-server model. The client is a
Java-applet that runs on any standard browser and PC that is connected to
the Internet and supports Java and CORBA. The client connects to a server
that acts as a transaction manager. The servers are connected to
databases where all of the account profiles and information is stored.

There are four different types of client applets, each for a different
user-type and with different capabilities. (See section 3.5.1) There will
be multiple transaction-manager servers for load balancing and high
availability. If any server goes down, there are several other servers
that can take over for it. The system will also have at least two
databases, one primary and the other for back up. The information between
the two databases are kept synchronized whenever possible. All data is
first sent to the primary database and then to the backup database. If
the primary database ever goes down, the backup will take over and become
the primary. Once the primary is back up, it will have to resynchronize
with the data on the backup database. This all allows the NYEV Banking
System to be highly available and reliable while remaining transparent to
the users.

3.2 Functional Requirements

There are four different user types for the NYEV Banking System: bank
Customer, company Biller, bank Teller and bank Administrator. Each user-
type has different uses and feature requirements from the system. (See
section 3.5.1) Therefore the features will be divided up between general
features and those that are specifically needed by each user-type. Of
course, it is possible for these features to overlap.

General features of the NYEV Banking System:

4 different client Java-applets, each one specific to a user-type.
Multiple servers for high availability and load balancing.
2 databases, one primary and one backup, with the backup synchronized to
the primary.
Authentication onto the system to determine user and access rights.
Encryption of all remote communications to ensure security and privacy.
Logs are kept of every transaction
Transparent error handling whenever possible. I.e. rerouting a client to
a different server if the current server goes down, rerouting a server to
the backup database if the primary database goes down, synchronizing the
primary with the backup once the primary is up again.

Customer features:

View the current balance on all of his accounts.
View the transaction history on each of his accounts.
Transfer money between any of his accounts.
View all the bills that he has in his accounts.
Pay the bills in his accounts with his accounts.

Biller features:

View the billing and payment history of a customer of the company the
Biller represents.
Administer over the billing account of a customer including
opening/closing billing accounts and changing the balance on the account.

Teller features:
All the rights that a regular Customer has.
Deducting from an account when a Customer withdraws from the bank.
Credit to an account when a Customer deposits to a bank.

Administrator features:

Opening new accounts.
Closing existing accounts.
All of the above including the right to change any information in any

3.3 Nonfunctional Requirements

3.3.1 User Interface and Human Factors

This system will be used by two main groups of people: First it can be
used by people work at banks, such as tellers and customer service
representatives. Second, bank customers who can be connected to the
Internet or can dial to the bank can use it. The complete user
definitions are described in section User Model.

Since the system can be used by novice computer users, the front end of
the system is very user friendly (WYSIWYG) and should required minimal
formal training. Online documentation will be provided to help users with
the system. Customers, however, will have to have previous knowledge
about having modem connection or connecting to the WWW. Although the
system required no training, we recommend bank workers be trained to use
the system, since mistakes that are made by bank workers, could affect
multiple accounts.

The system will try to protect users from making errors by double
checking every transfer and electronic payment made by the account. The
system will also keep log of transaction, so that mistake can be traced
whenever needed.

The devices needed for input/output for human interface are keyboard,
mouse (recommended), computer monitor, speaker (optional), and sound card

3.3.2 Documentation

The following documentation pieces are to be created as part of the NYEV
Banking System.


Target Audience
Software Project Management Plan developer, project management
Requirements Analysis Document    developers, project management, clients
System Design Document developer (internal)
Object Design Document developer
User's Guide     clients
A developer and project manager is a member of the NYEV project team and
the clients are professors and users.

There will be a different User's Guide for each of the different user-
types since the interface, capabilities and uses of the system would
vary. The User's Guide should include a few scenarios that cover some
common uses of the banking application to give new owners an idea of why
they would want to use the NYEV Banking System and what they can do with
it. There will be sections covering the user interface and how it is to
be utilized in conjunction with the rest of the banking application.
Instructions will be available on how view your account history, transfer
money between accounts and pay off bills online.

3.3.3 Hardware Consideration

All three clients side programs will have to access the system through a
web browser. The applets are not going to be very large, so any machine
that can run the Java Virtual Machine through any web browser should be

The transaction servers are probably going to be run on an NT machine
because of the lack of CORBA development tools. The machines won't have
to be too large. Memory requirements will be little because most of the
information for each client will be cached on the client side. No
information about a customer will be stored on the transaction server.
All we are going to store would be log files.

The database servers are also going   to run on NT's for the same reason.
These machines will require lots of   disk space as they will store all the
information for the clients. Memory   requirements might also be high as we
will probably leave information for   currently running clients in memory
and then save after the client logs   out

3.3.4 Performance Characteristics

The bottleneck of the system will be the bandwidth of the network
reaching different parts of the system. If all the servers are in one
location and connected through Ethernet, then our first consideration is
the bandwidth in reaching the client. If we decide to let the servers to
be located far apart, then we'll have to worry about bandwidth between
servers to the transaction servers.
The speed of the servers will not be a problem because of the network.
The speed of the client machine also should not be a problem because the
applet will be relatively small.

Obviously, the data for each customer will have to be as compact as
possible. Ideally, the data sent could fit within one packet or close to
the size of two or 3 packets.

3.3.5 Error Handling and Extreme Conditions

Obvious input errors, such as letters where numbers are expected, will be
handled at the client side. Other problems such as withdrawing too much
money or other typo's and improper clicks could be handled by rechecking
the input.

Lost, garbled, and/or out of order packets should all be handled by the
development packages that we will be using.

When a transaction server goes down, each client should have a list of
other servers to go to if the primary server goes down. If the server
comes back up, the client will not need to reconnect to it. Each session
is temporary and the next time the client connects to the server, they
can go back to the primary server.

Each database will have a backup server to recover in case the primary
database dies.

The network connection from a transaction server to a backup database
should not have to go through the primary database server so we can
tolerate that cable dying. Connections between the databases and
transactions servers should be as close to fully interconnected as
possible so we can tolerate as many network crashes as possible.

Should we lose actual information (disk getting corrupted) and both the
backup and primary databases die, we can run through the logs and
recreate all the events again. If the logs are corrupt, we can possibly
restore an old state of the system from tape backups

3.3.6 System Interfacing

Because transferring and making electronic payment may require connection
to other bank systems, there would be input and output that come from and
to the proposed system.

The systems will communicate using standard Java and CORBA. CORBA was
decided over RMI because it allows the system to talk to outside systems
that are not necessarily written in Java.
3.3.7 Quality Issues

For this system to be reliable, multiple transaction servers will be used
such that each client can connect. Each database will have a backup.
Because we're dealing with money, any failure of the system may cause
major havoc. Performance can suffer if it will compromise reliability.

If any transaction server crashes, it is not critical to get it back
running quickly because there are other servers that provide the same
services. If any database server dies, there is only one backup and so
we'd want to get the primary back and running ASAP. But more importantly
is to get the server running correctly and in the correct state. So
bringing the server back up is less important then keeping the
information correct.

The system at the very least should be up and running during normal
business hours when it will be used the most.

The clients will have to be as portable as possible. We're going to
develop with Java to keep it portable. The servers need not be portable.

3.3.8 System Modifications

System modifications will be made primarily on the client side, through
added functionality. This could include adding features such as stock
portfolio management. On the distributed backend, most modifications will
be made to the security features, so as to assure that the system remains
as secure as possible.

So as to allow for customized business applications in different areas,
modifications will occur through customized client applications and

3.3.9 Physical Environment

The final clients should run at home/office from any machine and a Java
enabled web browser. Most PC's bought today have this installed already
or are capable of running it. Though there are some households with older
computers that will have a hard time running a JVM, we feel that using a
Java applet is the best way to reach the wide set audience, though maybe
not all.

The servers will probably run on NT servers either in one location or in
separate locations depending on the requirements of the users of the
system. Our intent is to have the capability for our system to run in
different locations though of course then bandwidth becomes a
consideration and performance issue.
The room itself shouldn't require anything special. Though if there are a
lot of servers, you might want to turn the temperature lower to
compensate for the heat generated from many machines.

3.3.10 Security Issues

Physically, the machines serving as the backend must be securely placed
such that no unauthorized persons has any access to the machines. Hence,
accesss to the system itself must be controlled so as to assure the
transactions that the machine is carrying out are in no way altered.

The standard security issues must be resolved, in terms of authorization
and authentication. Given the nature of the NYEV banking system, there
will be several levels of security. This includes, but is not limited to,
customer, teller, and administrator level access.

Assuring that the transactions cannot be intersepted easily, and so as to
secure such things as account numbers and passwords, a level of
encryption must be used between machines. Currently ssh and ssl are being
looked at as possible methods of securing communication from web based
clients to the servers. Other methods will be looked into for server to
server communication, if necessary.

3.3.11 Resource Issues

Ideally the database system should be backed up continuously. At least
once every two hours at the central level should be considered a bare
minimum in case of catastrophic failure, to minimize data loss.

System administrator should maintain the system and its databases to
ensure their integrity and availability.

3.4 Constraints

The system will be developed with Java (JDK 1.1.5) with CORBA using
VisiBroker. Object and case models will be constructed using the CASE
tool Rational Rose 4.0. Source control will be handled using CVS.

The major constraint to using CORBA is that it requires the client and
servers to run a CORBA ORB. This should not be a problem for the server
since the bank administers it but it may be a problem to require all the
clients to have ORB on their machine. It would be possible though for the
bank to distribute a copy of an ORB along with any software and manuals
that they would normally provide one of their customers when they sign up
for the service.
3.5 System Model

The NYEV system is designed with four different types of users in mind: a
regular bank Customer, an accounts Biller, a bank Teller and a bank
Administrator, all generically called a User. (see section
Actors) Each user type has different requirements and uses in mind for
the system, and therefore different levels of access rights and
privileges. Of course, it is possible for a person to have more than one
user type. I.e., a bank Administrator could also be a regular Customer of
the bank. In such a case, the person would have more than one account,
one for every user type he has.

The system is designed to aid both bankers and the banks themselves in
handling their finances. Some possible situations where the system would
be useful are described in the scenarios under section 3.5.1. UML
notation is also displayed (section 3.5.2) to show more comprehensive use
case models that describes the functionality to be provided by the
system. The dynamic models (section 3.5.3) illustrate the sequence of
events that occur when using the system.

3.5.1 Scenarios

John is a Customer of a bank using the NYEV Banking System. He likes the
convenience that allows him to do a lot of his banking chores from home
instead of having to go to a branch of the bank or an ATM. From the
comfort of his own home or even while at work, John can check on his bank
accounts and pay off his various bills (telephone, electric, credit
cards, car insurance, etc.) without the hassle of writing separate checks
to the various different companies.
The Electric Company is an enthusiastic user of the NYEV Banking System
because it allows them to dramatically lower their operations costs in
collecting payments from their customers. They are now able to directly
bill the accounts of their customers who also use the NYEV system. They
still send out hardcopy statements to all of their customers, along with
a summary of the charges. Those customers who don't use the NYEV system
can still pay their bills the traditional way. Customers with the NYEV
system have the option of not writing a check and mailing it back to the
company. Instead they can log onto their bank accounts, see the charges
from the company, deduct the money from their own accounts and pay off
their bills online.
Mary is a bank Teller in a bank that uses the NYEV Banking System. She
likes it a lot because the interface is a lot nicer, much better then the
amber text screens that she was used to staring at. She's also much more
familiar and comfortable with the standard windows GUI-type interface
because it's similar to the applications that she uses at home, including
the banking application.
Bob recently had the NYEV Banking System installed in the bank branch
that he manages. He's very proud of it and likes to show it off to
potential new customers of the bank. It also makes his job a lot easier
because is allows him to manage all of the different accounts much better
than the older mainframe system. Before, if something went wrong with the
mainframe, his bank could be out of service for days. Now with the new
systems and it's distributed servers and replicated databases, he rarely
worries about not being able to serve his customers.

3.5.2 Use Case Models

The following is a top-level use case model done in UML notation. It is
used to provide a more formal specification of the general uses of the
NYEV Banking System. Actors

User - Any user of the system. There are 4 different types of users in
this system. The User interacts with the system through the client
Customer - A regular, everyday bank customer. He only has access to
information related to his account. The client programs that he generally
runs are from a home or office PC. From their PC, he can view his account
information and history, transfer money and pay off bills but cannot
directly withdraw or deposit cash.
Biller - A user who bills the customers of the company that he works for.
The Biller only has the right to bill a customer, not deduct the money
directly from their customer's account.
Teller - A regular bank teller for a bank. He has the right to view
accounts of customers, their account history and deposit and withdraw
money from those accounts.
Administrator - A bank branch manager type person. He has total access
and complete control over all the accounts that he is responsible for.
This includes view any information, transferring money and opening and
closing accounts.
Database - The primary place where all of the information is stored. This
includes all of the user profiles, passwords, account information and
logs of all the transactions that took place. There will be at least two
servers, one primary and one secondary for back up purposes. Use Cases

Figure 3.1 UseBanking: High-level use case diagram

Purpose: UseBanking

This is the high-level use case for using the NYEV Banking System. To use
the system for any transaction, one of the 4 different use types logs
onto the client program, which connects to a transaction manager server
which stores its information on a database.

Entry Conditions:
The client program must be able to connect to at least one transaction
manager server. Servers are replicated for load balancing.
The transaction manager server must be able to connect to at least one of
its databases. Databases are replicated for backup purposes.
Exit Conditions:

It is very important that banking transaction go through correctly.
Therefore it is necessary that all transactions be completed before the
system is exited. If there are any problems, the system must at the very
least notify the user of the problem if it is unable to correct the
problem itself.
All information should be stored on multiple databases for backup
purposes. At the end of a transaction, all the data between the databases
should be synchronized.
Flow of Events:

User logs onto one of the clients and authenticates with the system.
The client sends any user requests to the transaction manager server.
The server processes the requests, sending commands to the database to
fulfill the requests.
The processed request is sent from the server back to the client where
the information is displayed.
Special Conditions:

The special conditions for a banking system like this is high-
availability and high-reliability.
There are 4 different types of users, each with different access rights
and uses a different client program.
There are multiple transaction manager servers for load balancing.
There are multiple database to backup information.
Logs will be kept of every transaction.

Purpose: UseClient

Represents any interaction with the system through the client program.
The client program communicates with a transaction manager server. It
sends all requests to the server and waits for a response. Any results
are shown to the User.

Entry Condition:

The client program must be able to connect with at least one of many
transaction manager servers.
Exit Condition:

The client program must receive a message from the server saying that the
last transaction went through correctly. If not, an error message must be
displayed to the User.
Flow of Events:

The User logs onto the client program.
The client sends a authentication request to the server.
The server does a look up and returns a token to authenticate.
All User commands are passed to the server and the clients waits for a
Once all commands are correctly served and the User notified, the system
may exit.
Special Conditions:

The client program must be able to connect to a transaction manager
All communications with the server must be secured with encryption.
All commands must be correctly and completely fulfilled before the system
can exit. If there is a problem that the system is unable to correct
itself, it must notify the User of this.

Purpose: ManageTransaction

Acts as the transaction manager server. It receives requests from a
client program, processes the command, gets and sets whatever data it
needs from the database and sends the results back to the client.

Entry Condition:

The server must be connected to a database for all the information
The server must be able to communicate with the client. The client must
be correctly authenticated.
Exit Conditions:

All transaction must be completed correctly before the system can exit.
All information must be correctly stored on the database.
Flow of Events:

Receives a request to authenticate from a client.
Looks up account information from the database, authenticates and sends a
token back to the client.
Waits to receive requests from a client. Once it receives it, it
processes the request.
Talks to the database to get and set whatever information is necessary to
process the request.
Sends the processed information back to the client or an error message if
there was a problem.
Special Conditions:

The transaction manager server must able to connect to the client program
and at least one database.
All transactions must be secured with encryption.
All transactions with the client must be completed and correct before
disconnecting with the client.
All information on the database must be correctly stored in every
transaction with the database.
There are multiple servers for load balancing purposes.
A log of every transaction must be kept by the server and stored on the
3.5.3 Dynamic Models

The following is a top-level view of the sequence diagram in UML notation
for the NYEV Banking System.

Figure 3.2 UseBanking: High-level sequence diagram

To top