HOSHIK
HOSHIK
SPECIFICATION
FOR
1. PURPOSE.
2. SCOPE
3. OVERVIE
W
4. ADDITIO
NAL
INFORMA
TION
2 GENERAL
DESCRIPTION.
3 FUNCTIONAL
SPECIFICATIONS
1. LOGIN
2. VALIDATI
ON.
3. PAYMENT
OF
MONEY
4. TRANSFE
R OF
MONEY.
5. TRANSAC
TION OF
REPORT
4 INTERFACE
REQUIREMENTS
1. GUI
2. HARDWA
RE
INTERFAC
E.
3. AVAILABILITY
4. MAINTAINABILITY
5. PORTABILITY
8 DEFINITIONS
11 REFERENCES
1. INTRODUCTON: -
The Housing Development Finance Corporation Limited (HDFC) was amongst the first
to receive an 'in principle' approval from the Reserve Bank of India (RBI) to set up a
bank in the private sector, as a part of the RBI's liberation of the Indian Banking. Industry
in 1994. The bank was incorporated in August 1994 in the name of HDFC Bank Limited,
with its registered office in Mumbai, India. HDFC Bank commenced operations as a
Scheduled Commercial Bank in January 1995.
This document gives detailed functional and non-functional requirements for the HDFC-
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. PURPOSE: -
HDFC-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 (HDFC) 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.
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.
3. OVERVIEW:-
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: -
1. PRODUCT PERSPECTION: -
The client will have client interface in which he can interact with the banking system. 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 interface which is a GUI so that he can
view the entire system. He will also have a login page where he can enter the login
particulars so that he can perform all 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.
The system is a web based application clients are requiring using modern web browser
such as Mozilla Firefox 1.5, PHP, Google Chrome.
WEB SERVER:
BACK END:
3. FUNCTIONAL SPECIFICATION:-
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
4. Withdrawal of money
5. Transfer Money
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!!!".
If the card inserted by the customer has crossed the expiry date then the system will
prompt "Expired Card"
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
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. 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.
4. Transfer of Money:
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
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.
2. Hardware Interface
5. Touch screen/Monitor
6. Keypad
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:-
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:
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 HDFC BANK 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
1. Security
The banking system must be fully accessible to only authentic user. It should require pin
for entry to a new environment.
2. Reliability
The application should be highly reliable and it should generate all the updated
information in correct order.
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.
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.
5. Portability
The application should be portable on any windows based system. It should not be
machine specific.
8. DEFINITIONS:-
Account
A single account in a bank against which transactions can be applied. Accounts may be of
various types with at least checking and savings. A customer can hold more than one
account.
ATM
A station that allows customers to enter their own transactions using cash cards as
identification. The ATM interacts with the customer to gather transaction information,
sends the transaction information to the central computer for validation and processing,
and dispenses cash to the customer. We assume that an ATM need not operate
independently of the network.
Bank
A financial institution that holds accounts for customers and that issues cash cards
authorizing access to accounts over the ATM network.
Bank computer
The computer owned by a bank that interfaces with the ATM network and the bank's own
cashier. stations. A bank may actually have its own internal network of computers to
process accounts, but we are only concerned with the one that interacts with the network.
Cash Card
A card assigned to a bank customer that authorizes access to accounts using an ATM
Machine. Each card contains a bank code and a card number, coded in accordance with
national standards on credit cards and cash cards. The bank code uniquely identifies the
bank within the consortium. The card number determines the accounts that the card can
access. A card does not necessarily access all of a customer's accounts. Each cash card is
owned by a single customer, but multiple copies of it may exist, so the possibility of
simultaneous use of the same card from different machines must be considered.
Customer
The holder of one more accounts in a bank. A customer can consist of one or more
persons or corporations, the correspondence is not relevant to this problem. The same
person holding an account at a different bank is considered a different customer.
Transaction
A single integral request for operations on the accounts of a single customer. We only
specified that ATMs must dispense cash, but we should not preclude the possibility of
printing checks or accepting cash or cheeks. We may also want to provide the flexibility
to operate on accounts of different customers, although it is not required yet. The
different operations must balance properly,
9. Data Flow Diagram (DFDs)
1. Level 0 DFD
9.2 Level - 1 DFD
9.3 Level - 2 DFD
10. Use Case Diagram
\
Class Diagram