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.
1.1. Background
HUFMS Final Project Page 1

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

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
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
Post
Usecondition
case description for check 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.

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
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.
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.
Fig.3 Sequence Diagram for create account

Fig.4 Sequence Diagram for register

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.
Fig.8 Activity diagram for account create

Fig.9 Activity diagram for registration

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.
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.
Fig.14. Sequence Diagram for login

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

Copyright:

Available Formats

Finance Management System

Uploaded by

Document Information

Original Title

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

In general our project objective is to develop Haramaya University Finance Management

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

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

3.2.1.1. Use case diagram

HUFMS Final Project Page 5

Fig.1 use case diagram

2.3.1.2 Use Case Description

HUFMS Final Project Page 6

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.

Use case description for login

Description T Administrator needs to create an account and

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.

Use case description for calculate payroll

Description Accountant calculate payroll.

Department of Computing Science

Use case description for register

2. Fill the employee registration page and Click save

3. Display the registration page

4. Display registration successful or failed

Use case description for add employee

HUFMS Final Project Page 9

Use case name Add employee Information

Description Administration can 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.