Project-Student Financial Service System

STUDENT FINANCIAL SERVICE SYSTEM
For
FINANCIAL INFORMATION SYSTEM LAB (MBABT 420)
PROJECT REPORT
Submitted by
G.CHEZHIAN REGISTER NO: 14381012
S.PRAKASH RAJIV REGISTER NO: 14381044
R.NAGANATH RAO REGISTER NO: 14381035
E.MOHAMMED FARUK REGISTER NO: 14381032
DEPARTMENT OF BANKING TECHNOLOGY
PONDICHERRY UNIVERSITY
PUDUCHERRY-605014
NOVEMBER 2014

DEPARTMENT OF BANKING TECHNOLOGY
SCHOOL OF MANAGEMENT
PONDICHERRY UNIVERSITY
PUDUCHERRY-605014
BONAFIDE CERTIFICATE
This is to certify that the project work entitled” STUDENT FINANCIAL SERVICE
SYSTEM” is a bonafide work done by G.CHEZHIAN (REGISTER NO: 14381012),
S.PRAKASH RAJIV (REGISTER NO: 14381044), R.NAGANATH RAO
(REGISTER NO: 14381035), E.MOHAMMED FARUK (REGISTER NO: 14381032)
for FINANCIAL INFORMATION SYSTEM LAB (MBABT 420) in fulfilment of the
requirement, for the award of MBA-BANKING TECHNOLOGY by Pondicherry
University during the academic year 2014.
PROJECT GUIDE HEAD OF THE DEPARTMENT
Submitted for the University Examination held on ………………………..
INTERNAL EXAMINER EXTERNAL EXAMINER

ACKNOWLEDGEMENT
We would like to express our sincere and heartfelt gratitude to our mentor MRS.
SUGANTHY., Department of Banking Technology, Pondicherry University, for her valuable
suggestions and her timely guidance at every stage of our project. We also thank her for constant
motivation and abundant moral support towards the successful completion of our project.
We deeply gratitude to MR. Dr. K.CHANDRA SEKHARA RAO and Head, Department
of Banking Technology, Pondicherry University for providing department with all facilities and
guidance which enabled us to complete this project report.
Our sincere gratitude to the Management of Pondicherry University, for providing us
the entire infrastructure to proceed with our project.
We thank the other staff members for their generous support in making our project a
successful one.
Finally, we would like to thank our parents for guidance and encouragement, which they
have giving so far and we wish for the same. We also thank all our friends who gave their valuable
support and for extending their help. We also thank the almighty without whose help we would
have never finished our project.
As everything begins and ends in GOD, We conclude this acknowledgement by thanking
God for everything.

TABLE OF CONTENTS
CHAPTER NO TITLE PAGE NO
ABSTRACT i
LIST OF FIGURES ii
LIST OF ABBREVIATIONS iii
1. PROJECT STATEMENT AND FEASIBILITY ANALYSIS
1.1 PROJECT STATEMENT 1
1.2 FEASIBILITY ANALYSIS 1
2. SOFTWARE REQUIREMENTS SPECIFICATION
2.1 INTRODUCTION 3
2.1.1 PURPOSE 3
2.1.2 SCOPE 3
2.1.3 ACRONYMS AND ABBREVIATIONS 4
2.1.4 OVERVIEW 4
2.2 GENERAL DESCRIPTION 4
2.2.1 PRODUCT PERSPECTIVE 4
2.2.2 PRODUCT FUNCTIONS 5
2.2.3 USER CHARACTERISTICS 5
2.2.4 GENERAL CONSTRAINTS 5
2.3 SPECIFIC REQUIREMENTS 5
2.3.1 FUNCTIONAL REQUIREMENTS 5
2.3.2 NON-FUNCTIONAL REQUIREMENTS 6
2.3.3 OTHER REQUIREMENTS 7
3. OBJECT ORIENTED ANALYSIS
3.1 USE CASE ANALYSIS 9
3.2 ACTIVITY DIAGRAM 12
3.3 SEQUENCE DIAGRAM 14

4. OBJECT ORIENTED DESIGN
5.1 CLASS DIAGRAM 16
5.2 PACKAGE DIAGRAM 18
5.3 PATTERNS IDENTIFIED 19
5. IMPLEMENTATION
6.1 COMPONENT DIAGRAM 20
6.2 DEPLOYMENT DIAGRAM 22
6. CONCLUSION AND FUTURE ENHANCEMENT
7.1 CONCLUSION 23
7.2 FUTURE ENHANCEMENT 23
REFERENCES 24

i
ABSTRACT
This Student Financial Service system provides an easy, accessible, and seamless to
students whenever they need it. It ensures access to a PU education for all admitted and enrolled
students without regard to their financial circumstances. It provides the best possible solutions and
service to students and their families.
Credit Services is responsible for assisting students to finance their education by providing
efficient and accurate certification of loan eligibility, providing entrance and exit loan counselling
to advise students of their rights and responsibilities during loan repayment, and by delivering loan
disbursements to student or parent borrowers quickly, via EFT.
A single point of professional service for answers to questions about administrative and
financial matters such as the University bill, registration, enrolment, and ID cards.
The various services includes that orders food through online, allocates hostel room can be
made by student through online, to make payment for fees and to access library using account
number

ii
LIST OF FIGURES
FIGURE NO FIGURE NAME PAGE NO
3.1 System Use Case Diagram 10
3.2 Admission Use Case Diagram 11
3.3 Loan Processing Activity Diagram 13
3.4 Loan Repayment Sequence Diagram 15
4.1 System Class Diagram 17
4.2 System Package diagram 18
4.3 Singleton Pattern 19
5.1 Component Diagram 21
5.2 Deployment Diagram 22

iii
LIST OF ABBREVIATIONS
1. SFS Student Financial System
2. MBA Master of Business Administration
3. BT Banking Technology
4. EFT Electronic Fund Transfer

1
CHAPTER 1
PROJECT STATEMENT AND FEASIBILITY ANALYSIS
1.1 PROJECT STATEMENT:
To propose a financial service system for students that provides with the information,
products and services need to finance their education and it ensures access to a PU education for
all admitted and enrolled students without regard to their financial circumstances.
The objectives of student financial service system are:
(i) Credit Services is used for assisting students to finance their education.
(ii) To ensure the timely billing and collection of the university’s student receivables.
(iii)To pay admission fees, hostel fees, students can made payment in online.
(iv)Allocating hostel room can be made by student.
(v) To access library using account number and paying fine charges through online.
(vi)Students can order food through online.
1.2 FEASIBILITY ANALYSIS:
The feasibility study is basically the test of the proposed system in the light of the
workability, meeting user requirements, effective use of resources and the need effectiveness. It is
most vital point for developing the new system.
The objective of feasibility is to solve the problem of time bound announcement and reach
the user quickly and efficiently. The system is to consider feasible only if the proposed system is
useful and is determined at the preliminary investigation stage.
Thus the purpose of the feasibility is to gather, analyse and document the data needed to
make an informal intelligent decision regarding system’s practicability. There are three aspect of
feasibility study of the preliminary investigation.

2
The feasibility study concerns with the consideration made to verify whether the system is
fit to be developed in all terms. The feasibility study is basically the test of the proposed system in
light of its workability, meeting user’s requirement, effective use of the resources and of course
the cost effectiveness. The main goal of feasibility study is the cost and benefits are estimated with
greater accuracy.
The feasibility study is an important factor in analysing the capability of the project. The
key objective is to weigh up three types of feasibility. They are:
 Operational feasibility
 Technical feasibility
 Economic feasibility
i) Operational feasibility:
Operational feasibility ensures that the project developed is successfully implemented in
the distributed environment. The Operational feasibility is very high as it is user-friendly, easy to
use and found to be beneficial environment.
ii) Technical feasibility
The financial service systems is considered technically feasible if the internal technical capability
is sufficient to support the system requirements. The system is feasible within the limits of current
technology. The system is going to propose within the available resource constraints. It gives
solutions for all related financial service problems.
iii) Economic feasibility
The financial service system is a cost saving method compared with the existing systems.
Therefore it is economically feasible. The system cannot use advanced technology because budget
is limited. If the system is expanded to advanced technology, then the system is not economically
feasible, and the project should not proceed any further. If the expected benefits equal or exceed
costs, the system can be judged to be economically feasible.

3
CHAPTER 2
SOFTWARE REQUIREMENTS SPECIFICATION
2.1 INTRODUCTION
2.1.1 Purpose
The purpose of this document is to describe a detailed objective of Student Financial
Service system and how it is going to work and how we are going to implement the system of
activities. The system can able to access bank accounts and use all the services and made payments
inside the university.
2.1.2 Scope
This system will be an online financial and payment System for a location inside
Pondicherry university. This system will be designed to optimize the efficient transaction by
providing tools to assist in automating transaction and payment processes. This system ensures
that the timely billing and collection of the university’s student receivables, and verify that all
students are being billed according to the rates and policies.
More specifically, this system is designed to allow every user to do transaction in an
effective way and providing online credit without any delay in Pondicherry university community.
The software will facilitate communication between students, staffs, and the banker via online
credit transaction. Transaction processing is information processing that is divided into individual,
indivisible operations. The technology responsible for making the exchange balanced and
predictable is called transaction processing. Transactions ensure that data-oriented resources are
not permanently updated unless all operations within the transactional unit complete successfully.
By combining a set of related operations into a unit that either completely succeeds or completely
fails, you can simplify error recovery and make your application more reliable.
Therefore, areas such as registrar, student employment, financial aid, payment option
programs, billing, loan processing and a service center join together to form Student Payment and
Financial Services.

4
2.1.3 Acronyms and Abbreviations
 SFS Student Financial System
 MBA Master of Business Administration
 BT Banking Technology
 EFT Electronic Fund Transfer
2.1.4 Overview
The SRS document for the Student Financial Service System covers the following:
 General Description: This section describes the general functionality of the system, as
desired by the customer in common terms.
 Specific Requirements: This section describes about both the functional and non-
functional requirements of the system. The Functional Requirement section defines the
requirement specifications from functionality viewpoint while the Non-Functional
Requirements - external interface, performance, etc. are dealt in detail in corresponding
sub-sections.
2.2 GENERAL DESCRIPTION
2.2.1 Product Perspective
Students can directly interact with the following other services of the system:
1. FINANCIAL SERVICE: students can able to get deposit their own money and students
can able to get loan for their studies
2. PAYMENT SERVICE: students can made payments using various services offered in
university.

5
2.2.2 Product Functions
 To provide financial service to students by creating bank accounts and made deposit by
students or can take loan from bank.
 To pay admission fees, hostel fees, students can made payment in online.
 Allocating hostel room can be made by student.
 To access library using account number and paying fine charges through online.
 Students can order food through online.
2.2.3 User Characteristics
 The SFS user can access various services who got admission in university
 The SFS user must create bank account compulsory and he can deposit in bank or he can
get loan to pay fees. After the course completion, if he availed loan, he should be in a
position to repay the money after he got the job.
2.2.4 General Constraints
 The university selects only top 50 students from AIEEE or GATE Exam.
 This system is applicable only for MBA Banking Technology Department.
 Student cannot access and perform transactions outside university.
 This system will maintain a server and proxy server in university.
 There is a one-time password to access online transactions.
2.3 SPECIFIC REQUIREMENTS
2.3.1 Functional Requirements
2.3.1.1 Financial Service
(i) Deposit Money:
Student must create bank account who got admission in university. Once student
created bank account they can deposit their own money.
(ii) Loan Process:
If student is not having money and he can’t able to pay. So he can avail the loan
freely. After the course completion student should be in a position to repay the
money after he got placement or job.

6
2.3.1.2 Payment services
(i) Ordering food through online:
Once student created bank account he can use various services. Student can order
food through online or ATM card. The requirements of the payments are:
 Table number
 Account number
 One time password
 Pay money
 Choosing the food available in canteen
(ii) Access Library:
Students can access Library using account number. The various to access library
are:
 Buying books through online
 Borrowing books through online
 Paying fine charges through online
The procedure to access here is that once if you choose a recommended book, library staff
will search the books within 2 hours and library staff sends the corresponding books to the
respective department.
2.3.2 Non Functional Requirements
2.3.2.1 Performance Requirements
Performance of the SFS Payment system depends on the following factors:
 Speed: the speed of the system to access the system is very fast and effectively used by
students. There are many constraints to access various services.
 Storage: the highly retrieved database was used. The storing algorithms need to give more
importance to the efficient retrieval of data than the amount of space they consume.

7
2.3.2.2 Attributes
The various attributes of the SFS system are as follows:
 Efficiency: administrators will process financial service and payment services to perform
through efficiency.
 Maintainability: banks should maintain the student transactions and fixing the problems
in a system.
 Portability: The system is user-friendly to access payment services.
 Security: The availability of student profile and transactions should be highly secured and
protective.
Attribute High Medium Low
Efficiency X
Maintainability X
Portability X
Security X
2.3.3 Other Requirements
2.3.3.1 Databases
For the operation of the SFS System, the following files will be maintained:
 Student Profile: Profile created by the users and it will be maintained by administrators.
 Student Transactions: It will be monitored

8
2.3.3.2 User Documentation
A complete documentation of the system will be provided. The documentation will contains:
 SFS System Guidelines.
 SFS Procedures
2.3.3.3 Object Reuse
The system will be designed for students to access financial service and payments services.
The system will reuse the student objects to add various services and maintaining in data center.

9
CHAPTER 3
OBJECT ORIENTED ANALYSIS
3.1 USE CASE ANALYSIS
Use case diagrams provide a way of describing the external view of the system and its
interactions with the outside world. In this way it resembles the context diagram of traditional
approaches. In this representation the outside world is represented as actors. And also in addition
to the links among actors and use cases, there are two other types of links called include and
extends, they represent include and extends relationships among use cases.
3.1.1 Use Case Diagram for the student’s financial service system:
In this use case diagram, the actor of the financial service system is student, manager and
library staff. Student enters into the admission process consists of verifying mark sheets, creating
bank accounts and other formalities. After created your student account, student can able to deposit
an amount to and withdraw an amount from his accounts using this system. If student can’t able
to pay fee, so student will be able to apply for a loan. Bank manager will explain the procedure of
loan process. Student can access library to get books through library staff. Student can made
payment through online for buying books, materials for project, etc.

10
Fig. No. 3.1 System Use Case Diagram
3.1.2 Use case Diagram for student’s admission process:
Student’s admission process is a part of the system. In this use case diagram, student applying for
a course through online. Department head will shortlist the students through the exam. Department
head sends call letter to the shortlisted students. Student will come for admission with call letter
and mark sheets, department head will verify the mark sheets. Once student verified, student can
create account using admission number. After created account, student can use various services
offered by this system.
System
admission process
deposit money
applying loan
loan evaluation
library process
payment process
student
manager
library staff

11
Fig. No. 3.2 Admission Use Case Diagram
System
department head
applying admission
selects students
calls through mail
verifies marksheets
create university account
money deposit/avail loan
pay fees
use payment services
student
manager

12
3.2 Activity diagram for loan application process:
The activity diagram focuses on activities, chunks of process that may or may not
correspond to methods or member functions, and the sequencing of these activities. In this sense
it is like a flow chart. Loan application process is a part of the system.
In this activity diagram, student activities are requests the loan application, fills application,
preparing documents to submit for loan and student will receive loan amount through online. These
are the activities carried out by the student. Manager activities are accepts application, analyzes
application and submitted documents, enquires eligibility to get loan, decide whether to accept
loan or not. If the loan was approved, manager will make a agreement to sign in the document.
These are the activities carried out by the manager.

13
Fig. No. 3.3 Loan Processing Activity Diagram
student Manager
loan request
accept and fill loan application
preparing documents
application filled
analyzing application and docs
enquiry eligibility to avail loan
loan disapprovalloan approved
signing agreement
loan amount disbursed
loan amount received

14
3.3 Sequence Diagram for loan repayment process:
Sequence diagrams show a detailed flow for a specific use case or even just part of a
specific use case. They are almost self-explanatory. They show the calls between the different
objects in their sequence and can show at a detailed level, different calls to different objects.
In this sequence diagram, manager assigns loan account number to student for repayment.
After student got the job, he joined in a company. HR Manager will get the details using Aadhaar
number and manager checks that whether student is applied loan or not. Company will repay the
loan amount through his salary. Company will deduct some amount in his salary to pay the loan
amount through EMI. If the loan was repaid, then bank manager and student will cancel the loan
agreement.

15
Fig. No. 3.4 Loan Repayment Sequence Diagram
manager student company HR
1 : assign loan a/c number()
2 : joined company()
3 : getting_details()
4 : check loan avail()
5 : loan avail()
6 : getting Loan details()
7 : pay loan()
8 : repay money through EMI()
9 : monitoring whether pay or not()
10 : loan paid()
11 : sending message()
12 : cancel agreement loan()

16
CHAPTER 4
OBJECT ORIENTED DESIGN
4.1 Class diagram for student financial service system:
The system static structure can be documented by class diagram. All system life time can
be shown on a links between classes with their operations, attributes, and names. Class diagram
define as a rectangular boxes .This boxes initially contain sections. First section gives for class
name, second one contains the class attributes, and the bottom section for methods (operations)
associated with the class.
You will usually create several Class diagrams for a single system. Some will display a
subset of the classes and their relationships. Others might display a subset of classes, including
their attributes and operations. Still others may display only the packages of classes and the
relationships between the packages. You can create as many Class diagrams as you need to get a
full picture of your system.
In this class diagram, the classes designed for student financial service system are:
 Student account
 Admission process
 Loan processing
 Loan repayment
 Library system
 Payment processing

17
Fig. No. 4.1 System Class Diagram
student
+account number
+Aadhaar number
+name
+department
+course
+deposit()
+withdraw()
+getting_book()
+loan()
+purchase()
admission
+admission number
+Attribute1
+create account()
+allocate hostel room()
+get_details()
library system
+account number
+name
+get_book details()
+borrow_book()
+Return book()
payment transactions
+unique transaction id
+student account number
+purchase_book()
+pay_fees()
loan process
+loan app number
+student account number
+aadhaar number
+name
+loan_request()
+loan_enquiry()
+loan_approval()
+loan_disbursement()
loan repayment
+aadhaar number
+name
+get_details()
+pay_EMI()
Manager
+name
+employee id
+designation
+Enquiry()
+final approval loan()
+Monitoring()

18
4.2 Package Diagram
A package diagram in the Unified Modeling Language depicts the dependencies between the
packages that make up a model.
Fig. No. 4.2 System Package Diagram

19
4.3 PATTERNS IDENTIFIED
Patterns used in our system is
 Singleton Pattern
Singleton Pattern
The singleton pattern is one of the simplest design patterns: it involves only one class which
is responsible to instantiate itself, to make sure it creates not more than one instance; in the same
time it provides a global point of access to that instance. In this case the same instance can be used
from everywhere, being impossible to invoke directly the constructor each time.
In our system Manager Class follows singleton pattern because this class has only one
instance and provide a global point of access to the object.
 We had to have only one instance for class Manager. We simply solve our problem using
Singleton Pattern
Fig. No. 4.3 Singleton Pattern
manager
+loan_process(): manager -instance

20
CHAPTER 5
IMPLEMENTATION
5.1 Component Diagram
A component diagram provides a physical view of the system. Its purpose is to show the
dependencies that the software has on the other software components (e.g., software libraries) in
the system. The diagram can be shown at a very high level, with just the large-grain components,
or it can be shown at the component package level.
A component represents a software module (source code, binary code, executable, DLL,
etc.) with a well-defined interface. The interface of a component is represented by one or several
interface elements that the component provides. Components are used to show compiler and run-
time dependencies, as well as interface and calling dependencies among software modules. They
also show which components implement a specific class.
A Component diagram depicts how components are wired together to form large
components and or software systems. They are used to illustrate the structure of arbitrarily complex
system.
The following components involved in the SFS:
 Student access UI
 Transaction UI
 Main UI

21
Fig. No. 5.1 Component Diagram
view_classes
student access UI
transaction UI
Main UI
business_classes
students
manager
library staff
access_classes
accessdatabase
canteen incharge

22
5.2 Deployment Diagram
The deployment diagram shows how a system will be physically deployed in the hardware
environment. Its purpose is to show where the different components of the system will physically
run and how they will communicate with each other.
Fig. No. 5.2 Deployment Diagram
access
application server
student_PC
Main UI
admission process loan_Processing
payment_transactions
accessdatabase

23
CHAPTER 6
CONCLUSION AND FUTURE ENHANCEMENT
6.1 CONCLUSION
Financial service system for students manages for all admitted and enrolled students are
having competitive advantage with those offered by other institutions which limit educational debt
burden, but our system facilitates accessibility to the administration. SFS provide an array of
financial services, products, counseling resources and information to meet the needs of students
and their families when planning for and managing the cost of attendance. SFS provide the means
for students to register for courses, maintain accurate records of academic achievement and student
data, to provide transcripts, and to schedule the use of money.
6.2 FUTURE ENHANCEMENT
In responding to the diverse and changing needs of the university, a spirit of cooperation,
innovation and fairness will be maintained. Student Financial Services supports enrollment and
retention by connecting students and their families to financial resources and educating parents
and students so they can make sound financial decisions. The New technologies in the future such
as mobile banking, credit app, payment app. These are the future applications supports financial
service system.

24
REFERENCES
[1] Ali Bahrami, Object Oriented System Development: Using The Unified Modeling
Language(1999) , Tata Mcgraw Hill Education Private Limited.
[2] Craig Larman, Applying UML and patterns, Addison Wesley, 2000.
[3] Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language User
Guide, Addison - Wesley Longman, 1999.
[4] Erich Gamma, Design Patterns, Addision Wesley, 1994.
[5] Roger.s.Pressman., Software Engineering: A Practioner's Approach 7e (2009),Tata
Mcgraw Hill Education Private Limited.

Project-Student Financial Service System

More Related Content

What's hot

Similar to Project-Student Financial Service System

Recently uploaded

Project-Student Financial Service System