Finance Management System

Department of Computing Science
CHAPTER ONE
1. Introduction
This project with title “Haramaya University Finance Management System (HUFMS)” is
developed with the aim of improving the quality of finance with regard to time efficiency, resource
minimization, and also decreasing man power. The project we develop can completely and
effectively replace the present system of the finance management system.
This project contains the following: - introduction (background, problem identification,

objective, scope and etc) and the proposed system (functional requirement, nonfunctional
requirement, system models, interface and etc).
It is obvious that, every computerized system should have a clearly described requirements
specification in order to communicate with the user effectively and efficiently. The Document
describes the system requirements for finance management system. And it is believed that this
document will give a good look of the system being developed. For the propose of ease of tracing
this document is divided into different chapters; so that one can refer to the chapter that he/she is
looking for easily.
Finally, the new project will be tested extensively to make it free from any kind of bugs. It is our
hope that this project can effectively replace the present system.
HUFMS Final Project Page 1

1.1. Background
Haramaya University (HU) was established as an institute of higher education 1954, when the
governments of Ethiopia and United States of America agree to jointly establish the Ale Maya
College of Agriculture. It was aimed and designed to conduct institution, research and extension
(demonstration, popularization) and other education activities that promote the development and
use of agriculture.
In 1985, the College was upgraded to an agricultural University and was renamed Ale Maya
University of agriculture. In 1996 the university launched faculties of education and Health science
and was promoted to a full-fledged in 1999, renamed Ale Maya University. Additional faculties
including Faculty of Business and Economics and Faculty of Law, Faculty of veterinary Medicine
and Faculty of technology was opened. HU runs both under graduate and post graduate (M. Sc and
PHD) program in various fields of study. In 2006 Alemaya University was renamed HU. The HU
Financial system was housed in administration building basement hall and Finance Management
System of HU has the same age with HU. This finance management system was established for
the primary purpose of improving finance management and accountability in the public sector.
Currently this finance has many sections, such as payroll section, accountant room, cashier room
and manager room. Manage are control over all activity of finance.
1.2. Problem definition
Currently the finance is facing many problems due to the use of manual system in its day to day
activity.
The problems are:
 Loss of document.
 Problem in Organized Data.
 Problem of duplication of items i.e. it needs to manipulate all the items individually in all
users client by transferring the items which need modification manually.
1.3. Objective of the Project
1.3.1. General Objective
In general our project objective is to develop Haramaya University Finance Management System.
1.3.2. Specific Objective
Included in the general objective, our project is also expected to fulfill or achieve the following
specific objective.
 To keep HU employees information in efficient, reliable and secured way.

 To get HU employees information as quickly as possible when he or she comes to receive

money.
 To provide a good controlling system for the manager.
 Analyzing the requirements of the users.
 Designing computerized system based on users’ request.
 Making things easier for the employers by developing, organizing and normalizing
database with updating information gathered from employers.
 To increase ease of information exchange between each of department members of the
finance.
1.4. Scope the project
The project automates the activities by providing, updating, searching, deleting and so on
activities. The major area of the finance system includes:
 Solving the problem of payroll system.

 Solving the problem of data base system which means preparing data base for the most
known finance.
 Solving the problem or file management system. This point explains how to put profile for
employees and how to get the profile from the data base.
 Solving the problem of document preparation. At this point the systems enhance the system
of preparing document simultaneously.
 Solving the problem of knowing the activity of the finance in a specified time interval in
this point the document clarify that how many employer join the finance.
 Solving the problem of getting information about the employees. This point is also explain
that how to get information about the employees as well as the activity of the finance at
any time.
 Solving the problem of information about how much employees is received money.
1.5. Methodology used
During information gathering we have used a number of techniques that helps us to get full
information about the system. These techniques are: -
1.5.1. Observation
We all have observed physically by going to the place. That most of the finance activates are
carried out manually. We have seen that there was no any well-developed computerized system in
the finance. And also information about the finance and the services that the finance provides were
not available easily.

1.5.2. Interview
The other most important method that helps us to get the most important and critical information
about the general view of the finance is by interviewing the different staff members of the finance.
They also told us the background of the finance. The other method that we are going to use for
designing our system is the structured methodology. This designing method helps us to understand
the system more easily. Under structured methodology we have other two methods.
1.6. Definition, Abbreviations, Acronym
 HU-Haramaya University.
 Id- Identification number
 HUFMS-Haramaya University Finance Management System

CHAPTER TWO
2. Proposed System
2.1. Functional Requirements
In our newly developed system we need to include different features about the finance. We have
so many functional requirements in our newly developed system but the main are as follows.
 The system store and display data about the employees.

 Payroll system.
 The system would be able to search, update and delete the information of employees.
2.2. Non-Functional Requirements
Our newly developed system will provide the following functionalities: -
 Documentation: The system will provide information about how to use it and all the
indispensable information about the system.
 Error handling: our system handles error by showing the message” invalid input” when the
user enters invalid input.
 Performance: The system has high performance example accessing information and
performance activities in a short period of time.
 Security: Except the concerned body any one cannot change, delete retrieve or append data.
2.3. System Models
To produce a model of the system which is correct, complete and consistent we need to construct
the analysis model which focuses on structuring and formalizing the requirements of the system.
Analysis model contains three models: functional, object and dynamic models. The functional
model can be described by use case diagrams. Class diagrams describe the object model. Dynamic
model can also be described in terms of sequence, state chart and activity diagrams. For the purpose
of this project we have described the analysis model in terms of the functional model and dynamic
models using use case and sequence diagrams.
2.3.1. Use cases
Use case defines set of interaction between actors and proposed system models considerations.
It is a methodology used in system analysis to identify, clarify and organize all system activities
that have significations to contain. Use cases of the system are identified as can be seen from the
diagram each actor has access to different Use Case.
Use cases of the system are identified to be create account, login, register, receive money, calculate
payroll, search employee information, add employee information, update employee information,
delete employee information and detail report.

3.2.1.1. Use case diagram

The simplest possible class diagram of our proposed system is shown in Fig.1.
Create account
Receive money
Employee
Login
Register
Cashier
Calculate payroll
Admin
Search employee
information
Update employee
information
Add employee
information
Delete employee Accountant

information
Detail report
Fig.1 use case diagram

2.3.1.2 Use Case Description
Use case description for create account
Use case name Create account
Actor Administrator
Description T Administrator needs to create an account and
this enables further communication and other
tasks in the forum.
Precondition Clicks create account.
Basic course action
1. Clicks create administrator account menu.
2. Fills the following details:
 User name
 password
3. Saves the account information.
4. Displays acknowledgment.
5. Clicks close.
Post condition Closes the window.

Use case description for login
Use case name Create account
Actor Administrator
Description T Administrator needs to create an account and
this enables further communication and other
tasks in the forum.
Precondition Clicks create account.
Basic course action
1. Clicks create administrator account menu.
2. Fills the following details:
 User name
 password
3. Saves the account information.
4. Displays acknowledgment.
5. Clicks close.
Post condition Closes the window.
Use case description for receive money
Use case name Receive money
Actor Employee
Description Employee received money from cashier.
Precondition Employee comes to get information about money.
Basic course action
1. Employee comes to get information about money.
2. The employee receive money.
Post condition Employee received money.

Use case description for calculate payroll
Use case name Calculate payroll
Actor Accountant
Description Accountant calculate payroll.
Pre condition he or she must login in to the home page
login form and calculate payroll.
Basic course action
1. The administrator ordered to accountant to calculate payroll.
2. The accountant accepts the employee information.
3. Calculate payroll for all employee.
Post condition The payroll will be calculated .
Use case description for register
Use case name register

Actor Administrator
Description when the new employee added to the existing
member.
Precondition he or she must login in to the home page login form
and accept the information of employee.
Basic course action

1. Open employee registration page from menu
2. Fill the employee registration page and Click save
3. Display the registration page
4. Display registration successful or failed

Use case description for check
Post condition Employee registered

Use case description for add employee
Use case name Add employee Information
Actor Administration
Description Administration can add employee information.
Pre Condition he or she must login in to the home page and add
employee information.
Basic course action
1. Open add Page form from menu.
2. Fill the add form and Click add.
3. Display the add page form.
4. Display add Successfully.
Post Condition Employee information is added.
Use case description for search
Use case name Search Employee Information
Actor Administrator and Cashier
Pre Condition he or she must login in to the home page and se
search employee Information.
Basic course action
1. Open Search form from menu.
2. Enter the ID of employee and Click search.
3. Display the Search form.
Post Condition Search is Successful

Use case description for update
Use case name Update employee Information
Description Administration can update employee information.
Pre Condition he or she must login in to the home page and
update employee information.
Basic course action
1. Open Update Page form from menu.
2. Fill the update form and Click Update.
3. Display the Update page form.
Post Condition Employee information is updated
Use case description for delete
Use case name Delete employee Information
Description Administration can delete employee information.
Pre Condition he or she must login in to the home page and
delete employee information
Basic course action
1. Open deleted Page form from menu
2. Fill the delete form and Click delete.
3. Display the delete page form
4. Display delete successfully
Post Condition Employee information is deleted.

Use case description for detail report
Use case name detail report
Actor Accountant and cashier
Description Manager needs detail report from accountant and cashier.
Precondition he or she must login in to the home page login form
Administrator tells them to prepare the detail report.
Basic course action
1. Administrator tells them to prepare the detail report
2. They prepared their detail report.
3. Finally they send to administrator.
Post condition Administrator checks the detail report.
3.2.1.3. Actor description

For our systems actors that we identified are:
Actor: Admin
Description: Administrator is able to manage over all the activity such as: create account, login,
add employee information, search employee information, update employee information and delete
employee information.
Actor: Employee
Description: receive money from cashier.
Actor Cashier
Description: login the system, search employee information and pay money for employee.
Actor: Accountant
Description: login the system and calculate the payroll.

3.2.1.4. Class Diagram
A class diagram depicts classes and their interrelationships. Class diagrams describe the structure
of the system in terms of classes and objects. Classes are abstractions that specify the attributes
and behavior of a set of objects. Objects are entities that encapsulate state and behavior. In our
new proposed system boxes including three compartments because it is a standard convention
depict classes and objects. The top compartment displays the name of the class or object. The
center compartment displays its attributes, and the bottom compartment displays its operations.
The attribute and operation compartment can be omitted for clarity. Object names are underlined
to indicate that they are instances. The simplest possible class diagram of our proposed system is
shown in Fig.2.
1
Admin
-Fname
-Lname
-Staff id
-Sex
-Age
-Phone no
-Room no
+Create account()
+Login()
+Add()
+Search()
1..* +Update() 1..*
+Delete()
Accountant Cashier
-Fname 1 1 -Fname
-Lname -Lname
-Staff id -Staff id
-Sex -Sex
-Age -Age
-Phone no -Phone no
1..* 1
-Room no -Room no
+Login() +Login()
Employee
+Calculate payroll() 1..* +Search()
-Fname
+Detail report() +Detail report()
-Lname
-Emp id
1 -Sex
-Age
-Phone no
1..* +Receive money()
Fig.2 class diagram
2.3.2. Sequence Diagrams

The sequence diagram is used primarily to show the interactions between objects in the
sequential order that those interactions occur. Much like the class diagram, typically think
sequence diagrams were meant exclusively for them. Besides documenting an organization's
current affairs, a business level sequence diagram can be used as a requirements document to
communicate requirements for a future system implementation. The simplest possible Sequence
diagram of our proposed system is shown in Fig.3, Fig.4 and Fig.5.
Admin page Account form controller Database

Admin
1. Click create account menu()
2. Generate account form
3. Display account form
4. Account form
5. Click ok()
6. Validate account form
7. Display error report
8. Error report
9. Save account information
11.Acknowledgement
10.Display acknowledgement
12. Click close()
Fig.3 Sequence Diagram for create account

Registration controller database

Admin page
Admin
1. Click register employee menu()
2. Generate employee register form
3. Display employee register page
4. Employee registration form
5. Click save()
6. Validate registration form
7. Display error form
8. Error report
9. Save employee information
11. Acknowledgement
10.Display acknowledgement
12. Click close()
Fig.4 Sequence Diagram for register

Home page Database

Admin and cashier
Enter the ID of employee
Click Search button
Get Information
Display Information
Fig.5 Sequence Diagram for search
2.4. Interface
Interface is a device or program enabling a user to communicate with a computer, or for connecting
two items of hardware or software. User interface design shows interfaces of this system how it
interacts to its users. In the following section we are going to show the UI design we are going to
use to our Web application system. In addition to hardware and software interfaces, an interface
may refer to the means of communication between the computer and the user by means of
peripheral devices such as a monitor or a keyboard and point of communication involving a
computer.
2.4.1. Form
The simplest possible form of our proposed system is shown in Fig.6 and Fig.7.
Fig.6 Login form

Fig.7 Home page

2.4.2. Activity Diagram
Activity diagram shows the conditional logic for the sequence of the system activities needed to
accomplish a business process. It clearly shows parallel and alternative behaviors that can be used
to show the logic the activities in the system. The simplest possible activity diagram of our
proposed system is shown in Fig.8, Fig.9 and Fig.10.
Create account
Select account type
Fill detail
If password or user name Success
don't much. Save
Error
Display error message Acknowldge
Fig.8 Activity diagram for account create

Employee registration
Select Employee type
Fill detail
Save
Success
Acknowdlge
Error
Send
Display error message
Fig.9 Activity diagram for registration

Search employee information
Fill detail
verefiy
success
search
Error
Acknowldge
Display error
Fig.10 Activity diagram for search

CHAPTER THREE
3. System Design
3.1. Introduction
System design has a great part which describes the first solution of the system problem. So
designing a system is the important and necessary step in any computer system. System design
provides a clear description of the overall design of the HUFMS and bridging the gap between
desired and existing system in a manageable way.
The internal part of this system design document is organized as: subsystem decomposition,
software and hardware mapping, persistent data management, access control, object design and
database design.
3.1.1. Purpose
The purpose of this project is to support the finance in many ways. From those ways some of them
are:-
 Save the time that is lost while doing some jobs manually.
 Protect the data of the finance from access by unauthorized person.
 Support simulations document preparation of different office of the organization and
finally to enable the insurance performance.
3.1.2. Design Goals
The design part is very important so as to make the implementation very easy. The non-functional
requirement is the description of the feature characters and attributes of the system. Some of the
design goals are:
1. The system should be secured: as the system is finance system the security requirement is a
critical issue. So that the system should prevent unauthorized access to the data stored in the
database, and in addition the system should maintain data about what activities are performed by
whom and when.
2. Ease of access to the required data: any data can be required at any time for some purpose,
i.e. modify or view. So that the system should enable the user acquire the required data easily and
timely with no need of navigating too many files.
3. Error handling: The system should be able to give response (error message) when the user
enter incorrect input. This recommends the user to enter correct input.

3.1.3. Definition, Abbreviations, Acronym
 HUFMS-Haramaya University Finance Management System

 UML-Unified Modeling Language
 DBMS-Database Management System
 DB-Database
 ER-Entity Relationship
3.2. System Design Model
3.2.1 Subsystem decomposition
To reduce the complexity of the system we decomposed the system into different and simple
subsystems. The following are identified to be subsystems of the systems:-Administration
subsystem, Register subsystem and Payroll subsystem.
Administration subsystem
Administration Subsystem
Select from the menu
Click on your choice
Register subsystem:-
Register subsystem
Fill the form
Submit
Payroll subsystem:-
Payroll subsystem
Fill the form
Submit

3.2.2. Hardware/software mapping
The DBMS subsystem is mapped to a server which has more processing power and storing
capacity, hence the system is build as a client/server application and communicates to any
other computers, so the system is a dependent component that runs on any computer node.
UML deployment diagram illustrate the hardware/software mapping of the system.
3.2.2.1. Deployment modeling
Deployment diagram shows a static view of the non-run time configuration of processing nodes
and the component that run on those nodes. Deployment show the hardware for your system, the
software that is installed on the hardware and the middleware used to connect the disparate
machines to one another. We create deployment model for applications that are deployed to several
machines. The simplest possible deployment diagram of our system design is shown in Fig.11.
Client Server
Register
fill form and submit
Calculatepayroll Database
fill form and update
Update
fill form and search
Search
Fig.11 Deployment Diagram
3.2.3. Persistent data management

The system requires persistent data management since it needs:

 To store employee information.
 To store payroll information.
 To permit different user to have different views of the system.
 To allow concurrent access to the system information and other related issues.
Identification of the persistent is realized from dynamic model in the application domain.
A relational database management will be used to maintain the persistent data in its
advantages that it provides several services and utilities that help to attain the design goals
of the system.
3.2.4. Access Control
The system uploaded on a central server to be accessed by multiple users. It will have user
interfaces to interact with the users easily. User will type their user name and password on the
login form and the system will check the validity of the user in the database. If a match is found
the user will be allowed to access the system with the privilege level assigned to him/her. If a
match is not found in the database the system will display a message telling the user to re-enter the
user name and password or else service will be denied.
3.3. Detailed Design
3.3.1 Object design
Conceptually, we think of system development as filing gap between the problem and the machine.
The activities of the system development incrementally close this gap by identifying and defining
objects that realizes part of the system.
System design reduces the gap between the problem and the machine by defining a hardware and
software platform that provides a higher level of abstraction than the computer hardware. During
object design, we the analysis and system design models identify new objects, and close the gap
between the application object and off-the-shelf components. This includes identification of
custom objects and the precise specification of each subsystem interface and class. As a result, the
object design model can be partitioned into set of classes such that they can be implemented by
individual developers.
In object design documentation we try to find out all the definition of the class and association that
will be used in the implementation as well as the interface s documentation and pseudo code of
the method used to implementation.
3.3.1.1. Object Design Trade-offs

The trade-off that we come across during design phase of HUFMS is between modularity,
reusability and efficiency cost of the system. We want to design class as modular as possible
however this would result to inefficient due to function call overload and cost more because of the
time spent. Therefore we need balance these groups of properties. We applied modularity and
reusability principles to whatever suitable but we also tuned critical functions for efficiency.
Developing a modularity designed for HUFMS will be different from mainstream of manual. This
is because the focus will be less on performance and more on durability and flexibility.
Performance: The performance of the system includes response time, the ability and speed of the
system while the system is running like for log in, registration, searching etc.
Durability: Having the system running with great speed today doesn’t help users in the future if
the system doesn’t work on newer platforms.
Flexibility: If the system is flexible it is easy to configure and less tight to get the maximum
performance. Therefore, flexibility is higher priority than performance.
3.3.2. Database design
The design of the DB is portrayed as a special model, database schema. It is the physical model or
blueprint for a DB, which represents the technical implimentations of the logical data model. A
relational DB schema defines the DB structure interms of tables, keys,indexs and integrity rules.
A DB schema specifiece details based on the capablities, terminologies, and constraints the chosen
DBMS.
3.3.2.1. Entity Relationship (ER) diagram
ER diagram of the database can be seen in Fig.12.
Fig.12. ER diagram
3.3.2.2.ER Mapping to Relational Databases

 Employee registration table: - It is one part of our database system which contains
personal information of the employee.
Column name Data type

Fname Varchar(10)
Lname Varchar(10)
EmpID Varchar(8)
Sex Char(1)
AdminID Varchar(8)
AccountID Varchar(8)
CasheirID Varchar(8)
Age Int(3)
Education status Varchar(15)
Mobileno Int(10)
BasicSalary Double(8)
Allowance Double(8)
Overtime Varchar(5)
 Cashier registration table: - It is one part of our database system which contains personal
information of the cashier.

Fname Varchar(10)
Lname Varchar(10)
CashierID Varchar(8)
AdminID Varchar(8)
Sex Char(1)
Age Int(3)
Mobileno Int(10)
 Accountant registration table: - It is one part of our database system which contains
personal information of the accountant.


Fname Varchar(10)
Lname Varchar(10)
AccountantID Varchar(8)
AdminID Varchar(8)
Sex Char(1)
Age Int(3)
Mobileno Int(10)
The simplest possible ER mapping of our system design is shown in Fig.13.
Fig.13. ER mapping to relational database model
4. Conclusion

The finance management system conversion from the present system the new system is based on
the radical change which based an acceptance from the users of the system.
Moreover, the system will bring radical change to the finance current working condition of the
payroll system department.
Finally, we concluded that the finance management system will be give efficient and effective
service for employee.
5. Recommendations
Finally, the team members recommend the following points:
 This system will give a solution for some of the problems in the registration process of the
employee.
 We recommend to the University department of computing science to provide its students
the opportunity to work on developing systems that are aimed in solving the real problems.
6. Appendix
The simplest possible Sequence diagram of our proposed system is shown in Fig.14, and Fig.15.

Admin page Account form controller Database
Admin,cashier and accountant
1. Click login()
2. Generate login form
3. Display login form
4.login form
5. Click login()
6. Validate login form
7. Display error report
8. Error report
9. login to page
11. Acknowledgement
10. Display acknowledgement
Fig.14. Sequence Diagram for login

Database
Home page
Admin
Enter employee info
Click update button
update employee information
Display Information
Fig.15. Sequence Diagram Update

7. References
1. Software Engineering book (Jalote).
2. Jeffery, D.Bently (2001) Object Oriented System Analysis and Design Method (5thedition). 3.
Joseph, S.Valacich. (2004)Essentials of Systems Analysis and Design (2nd edition).

Finance Management System

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Finance Management System

Uploaded by

Copyright:

Available Formats

Department of Computing Science

This project contains the following: - introduction (background, problem identification,

HUFMS Final Project Page 1

1.2. Problem definition

The problems are:

1.3.1. General Objective

1.3.2. Specific Objective

 To keep HU employees information in efficient, reliable and secured way.

HUFMS Final Project Page 2

 To get HU employees information as quickly as possible when he or she comes to receive

 Solving the problem of payroll system.

HUFMS Final Project Page 3

1.6. Definition, Abbreviations, Acronym

HUFMS Final Project Page 4

2.1. Functional Requirements

 The system store and display data about the employees.

Our newly developed system will provide the following functionalities: -

2.3.1. Use cases

HUFMS Final Project Page 5

3.2.1.1. Use case diagram

Delete employee Accountant

Fig.1 use case diagram

HUFMS Final Project Page 6

2.3.1.2 Use Case Description

Use case description for create account

Use case name Create account

Description T Administrator needs to create an account and

this enables further communication and other

tasks in the forum.

Precondition Clicks create account.

Basic course action

1. Clicks create administrator account menu.

2. Fills the following details:

Post condition Closes the window.

HUFMS Final Project Page 7

Use case description for login

Use case name Create account

Description T Administrator needs to create an account and

this enables further communication and other

tasks in the forum.

Precondition Clicks create account.

Basic course action

1. Clicks create administrator account menu.

2. Fills the following details:

Post condition Closes the window.

Use case description for receive money

Use case name Receive money

Description Employee received money from cashier.

Precondition Employee comes to get information about money.

Basic course action

1. Employee comes to get information about money.

2. The employee receive money.

Post condition Employee received money.

HUFMS Final Project Page 8

Use case description for calculate payroll

Use case name Calculate payroll

Description Accountant calculate payroll.

Pre condition he or she must login in to the home page

login form and calculate payroll.

Basic course action

1. The administrator ordered to accountant to calculate payroll.

2. The accountant accepts the employee information.

3. Calculate payroll for all employee.

Post condition The payroll will be calculated .