Requirements Analysis Document

NYEV Networking Solutions -

NYEV Banking System

15-612 Distributed Systems

Spring 1998

Carnegie Mellon University

Pittsburgh, PA 15213

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

Preface:

Target Audience:

NYEV Members:

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

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:

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

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 3.5.2.1 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 (optional).

3.3.2 Documentation

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

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

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

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

3.5.2.1 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 program.
• 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.

3.5.2.2 Use Cases

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.

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 response.
• 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 server.
• 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.

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 processing.
• 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 database.

3.5.3 Dynamic Models

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