Web Based Finance System

UNIVERSITY OF GONDAR
COLLEGE OF INFORMATICS
DEPARTMENT OF INFORMATION TECHNOLOGY

WEB BASED FINANCE MANAGEMENT SYSTEM FOR UNIVERSITY OF
GONDAR ATSE TEWODROS CAMPUS
Group Member:
Name ID
1. Fikade Melkie …………………………..………. GUR/ 01731/10
2. Aragaw Abraraw……………..………..………… GUR/ 01798/10

3. Abebe Wodaj……………………..……….………. GUR/ 01793/10
4. Abdirahman Ail …………………..……….…… GUR/ 01873/10
5.Desalegn Gete…………………………….……………GUR/ 01861/10

Gondar, Ethiopia
May 2021
DECLARATION
The project entitled --------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------------------
------------------------ Submitted to the Department of Information Technology,
College of Informatics, University of Gondar, in meeting the preliminary project

requirement for partial fulfillment of the award of Bachelor of Science Degree in
Information Technology
Name Signature
1. Fikade Melkie -------------------------
2. Aragaw Abraraw -------------------------
3. Abebe Wodaj -------------------------
4. Desalegn Gete -------------------------
5. Abdirahman Ail-------------------------
Approved by: -
Advisor Name: - _______________ Date _______________________
Signature ____________________
Examiner 1 Name: - Date Signature
1.______________________ _______________ _____________________
2..______________________ _______________ ____________________
Chairman:
Name.______________________
Signature______________________
Date .______________________
Acknowledgment
We would like to say thanks to almighty God for giving us opportunity to complete this
documentation. Then we would like to thank our advisor Instructor Abebech for his constructive
opinion and willingness to participate in each part of the project and his effective direction,
assistance and guidance for the accomplishing of this project documentation. We also wish to
thank the finance Employee of University of Gondar Atse Tewodros campus, who gave us the
required information about the Atse Tewodros campus finance system
Finally, we would like to thank the teaching staffs of Information Technology who have
contributed greatly to the success of this project documentation.
i|Page
Contents
Acknowledgment ......................................................................................................................... i
List of Table ................................................................................................................................ v
List of figure............................................................................................................................... vi
List of Abbreviation .................................................................................................................. vii
CHAPTER ONE ............................................................................................................................. 1
1.1. Introduction .......................................................................................................................... 1
1.2. Backgroundof the Organization ........................................................................................... 2
1.3. Statementofthe Problem ....................................................................................................... 2
1.4. Objective of the project ........................................................................................................ 3
1.4.1. General Objective ......................................................................................................... 3
1.4.2. Specific Objective ......................................................................................................... 3
1.5. Methodology of the Project................................................................................................ 3
1.5.1. Data collection Methodology ........................................................................................ 4
1.5.2. System development methodology ............................................................................... 5
1.6. Scope of the project.............................................................................................................. 5
1.7. Limitation of the project ...................................................................................................... 6
1.8. Constraint of the project ....................................................................................................... 6
1.9. Alternative solution of the project ....................................................................................... 6
1.10. Feasibility of the project .................................................................................................... 7
1.10.1. Operational feasibility ................................................................................................. 7
1.10.2. Economic feasibility ................................................................................................... 7
1.10.3. Technical feasibility .................................................................................................... 8
1.10.4. Organizational feasibility ............................................................................................ 8
1.11. Proposed solution ............................................................................................................... 8
1.12. Significance of the project ................................................................................................. 9
1.13. Benefit and Beneficiary of the project ............................................................................... 9
1.13.1. Benefits of the project ................................................................................................. 9
1.13.2. Beneficiaries of the project ....................................................................................... 10
1.14. System Development Tools ............................................................................................. 10
1.14.1. Hardware tools .......................................................................................................... 10
1.14.2. Software tools ........................................................................................................... 11
ii | P a g e
1.15. Cost and Budget Estimation ............................................................................................. 11
1.15.1. Hardware cost ........................................................................................................... 11
1.15.2. Software cost ............................................................................................................. 12
1.15.3. Transport Cost ........................................................................................................... 12
1.15.4. Communication Cost................................................................................................. 13
1.16. Time Schedule.................................................................................................................. 13
CHAPTER TWO .......................................................................................................................... 14
SYSTEM ANALYSIS .................................................................................................................. 14
2.1 INTRODUCTION .............................................................................................................. 14
2.2. Description of the Existing system .................................................................................... 14
2.3. Overview of the proposed system ...................................................................................... 16
2.4.Input and Output of the system ........................................................................................... 17
2.5. Requirement analysis of the new system ........................................................................... 17
2.5.1. Functional requirement ............................................................................................... 17
2.5.2 .Non Functional requirement ....................................................................................... 18
2.6. System Architecture Diagram ............................................................................................ 19
2.6.1.Current System Architecture ........................................................................................ 19
2.6.2.Proposed System Architecture ..................................................................................... 19
2.7. System Use Case Diagram ................................................................................................. 20
2.7.1 Use case components ....................................................................................................... 20
2.7.2.Actor Identification ...................................................................................................... 21
2.8 Use Case Narrative or description ...................................................................................... 22
2.9. Activity diagram ................................................................................................................ 30
2.10. Sequence diagram ............................................................................................................ 38
2.11. Class Diagrams ................................................................................................................ 44
CHAPTER THREE....................................................................................................................... 47
SYSTEM DESIGN ....................................................................................................................... 47
3.1. Introduction ............................................................................................................................ 47
3.1.1. Design Goals and Objective ........................................................................................ 47
3.2. Process Modeling ............................................................................................................... 48
3.2.1. Collaborative Diagram ................................................................................................ 48
3.2.2 Persistence Modeling ................................................................................................... 52
iii | P a g e
3.2.3. Deployment Diagram .................................................................................................. 54
Reference .................................................................................................................................. 56
iv | P a g e
List of Table
Table 1: Hardware cost ............................................................................................................... 11

Table 2: software cost ................................................................................................................... 12
Table 3: Transport cost ................................................................................................................. 12
Table 4: Communication cost ....................................................................................................... 13
Table 5: Time schedule ................................................................................................................. 13
Table 6: Use Case Description for Login ...................................................................................... 24
Table 7: Use Case Description for Create Account ...................................................................... 24
Table 8: Use Case Description for Register Expenditure ............................................................. 25
Table 9 : Use Case Description for Register Income .................................................................... 26
Table 10: Use Case Description for Make payroll ........................................................................ 27
Table 11: Use Case Description for Generate Report ................................................................... 28
Table 12: Use case description for sent request ............................................................................ 29
v|Page
List of figure
Figure 1: Proposed software Architecture .................................................................................... 20

Figure 2: System Use Case Diagram ............................................................................................ 22
Figure 3: Activity diagram for login ............................................................................................. 31
Figure 4: Activity diagram for create account .............................................................................. 32
Figure 5: Activity diagram for payroll .......................................................................................... 33
Figure 6: Activity diagram for expenditure .................................................................................. 34
Figure 7: Activity diagram for report generate ............................................................................. 35
Figure 8: Activity diagram for sent request .................................................................................. 36
Figure 9: Activity diagram for income register ............................................................................ 37
Figure 10: Sequence diagram for Login ....................................................................................... 38
Figure 11: Sequence diagram for create user account .................................................................. 39
Figure 12: Sequence diagram for payroll ...................................................................................... 40
Figure 13: Sequence diagram for register expenditure ................................................................. 41
Figure 14: Sequence diagram for register income ........................................................................ 42
Figure 15: Sequence diagram for generate report ......................................................................... 43
Figure 16 : Sequence diagram for Logout .................................................................................... 44
Figure 17: class diagram ............................................................................................................... 46
Figure 18: Collaboration diagram for login .................................................................................. 49
Figure 19: Collaboration diagram for create account ................................................................... 50
Figure 20Collaboration diagram for Register expenditure ........................................................... 50
Figure 21 : Collaboration diagram for Register Income ............................................................... 51
Figure 22: Collaboration diagram for logout ............................................................................... 52
Figure 23: Persistence Diagram .................................................................................................... 53
Figure 24: Deployment Diagram .................................................................................................. 55
vi | P a g e
List of Abbreviation
UML: Unified Modeling Language
OOSAD: Object oriented System Analysis and Design
HTTP: hypertext transfer protocol
HTML: Hypertext Markup Language
CSS: Cascading Style Sheet
UOG:University of Gondar
PHP: Hyper Preprocessor
UC: Use Case
MS: Micro Soft
EX;expenditure
WAMP: Window Apache MYSQL and PHP
HTTP: Hyper Text Transfer Protocol
E.C: Ethiopian Calander
PK: Primary key
FK: foreign key
vii | P a g e
UOG Atse Tewodros campus financial management system | 2013 E.C
CHAPTER ONE
1.1. Introduction
A financial management system is a system that an organization uses to oversee and govern its
income, expenses, and assets with the objective of ensuring sustainability[1]. The Finance
Management system is used to provide an option to generate the salary automatically every
month. This system is also equipped to enter the attendance of each employee in the
organization, it helps them to track each employee's attendance, based on this the system can
generate the salary.
Financial management system performs various functions: reducing accounting errors,

maintaining audit trails, and ensuring compliance with applicable accounting standards.
The finance management system is keeping payments and receivables transparent, amortizing
prepaid expenses, depreciating assets according to accepted schedules, keeping track of
employee data, Coordinating income statements, expense statements, and balance sheets,
ensuring data integrity and security. Keeping all records up to date, maintaining a complete and
minimizing overall paperwork.
Related to the UoG Atse tewodros campus finance office every accountantdoes their jobs with
paper works. Every customer request their services with a lot of forms with papers, and every
management heads should look and sign for every requested service, then after that, the
accountants should calculate and generate a statement and send it to the delegated person
through folders after that it should be sent to the bank through assistants.
The project will help to make those processes done with a few clicks, every actor will have
their privileges related to their work, all they have to do is logged into their account and see
their requested services, reports, and pending duties to be done. And then the system will work
everything after the actor gives the order.
1|Page
1.2. Backgroundof the Organization

The University of Gondar is one of the oldest universities in Ethiopia located in the Amhara
Region in the Historic town of Gondar. Established in 1954 as a Public Health College and
Training campus Center, the University has steadily grown and evolved into one of the top
education institutions in the country today. The university has five branches are college of
Medicine and Health Science , Atse Tewodros campus, Maraki campus, AtseFasil campus and
Tesedacampus.AtseTewodros campus is the main campus of the University.
Atse Tewodros campus is one of the campuses in University of Gondar located 2km away from
the capital city of Central Gondar zone. After the campus has established in this area it started
the teaching-learning activities by taking freshmen students in undergraduate programs.
Atse tewodros campus is a big academic institution having a large number of employees; the
finance office was established immediately when the campus is established.
Still, it has a manual financial management system. So it is unable to serve the campus
employees effectively and efficiently to make them satisfied and facilitate the growth of the
campus.Having this fact in mind,we plan to develop web-based application allows finance
stakeholders to exchange transaction easily.
1.3. Statementofthe Problem

Now a day’s University of Gondar Atse tewodros campus is also working on quality education
to attain its mission. As we know Atse tewodros campus still uses manual finance-related
activities. In this section, we mention the desirable problems related to the current manual
system. Most of the finance section is handled by a manual system. Their file control
mechanism is complicated and time-consuming. Processing data collection for payroll takes a
long time, because it is being done manually, therefore it incurs overtime cost, Requires more
manpower and few activities, Lack of security of data, and Consume large volume of
paperwork
All the necessary records of the above management activities are kept manually on paper. Due
to manual way of handling files error are occurs which lead to necessary rework. Those
problems stated above may cause finding some specific data from the file in cabinets or
2|Page
document which resulted in slow retrieval of data; difficulty in updating information

encountered a problem when the report is generated and it is time-consuming, the mechanism
of data handling is unsecured may cause the loose of data by several kinds of problems like
rats.
1.4. Objective of the project

1.4.1. General Objective
The main objective of this project is to develop a web-based finance management system for
the University of Gondar Atse Tewodros Campus.
1.4.2. Specific Objective
Specific objectives of the project:
• To Reduce the time to generate the report of the work.

• To minimize the loss of records or data .
• To minimize the time consuming for making payroll.
• To Increase the security of the data by authentication

• To make the office works simply and efficiently.
• Designing the proposed system user interface in a friendly manner .
• Implementing the proposed system.

• Deploying the proposed system into the existing one.
• Designing database.
• Designing and developing supportive web site.
1.5. Methodology of the Project
To achieve the proposed system, we would use the following methodologies
3|Page
1.5.1. Data collection Methodology
To develop a web-based financial management system the primary or initial task is collecting
required data from different sources to perform further tasks. The data will be gathered by
using the following techniques:-
 Interview: -
An interview is particularly useful for getting the history behind the participant’s experiences.
We have used to get information about the general view of the system is by interviewing an
employee.We would use an interview to get information about the existing system for
developing the project. The team would make an interview with the staff members.
We have asked different questions some are:-
 What is the current problem of the manual system?

 How do you work currently? OrHow to process the current system?
 Observation: -
We have observed some data physically by going to their office directly. We select observation
to know the real-world environment of the Office manual working. In the observation part, we
observe how the manual financial management system is working.
We would make physical observations on how employees perform their job and what are the
problems faced on the existing system.
 Document analysis:-
We also collected certain relevant information from written documents in the finance office.
Not only that but also we tried to review other relevant documents to develop our project
proposal.
 Questioners:
 By preparing questioner papers and giving these papers to the employees of the
organization.
4|Page
 The questioner will helpus to identify the main problem of the manual work from the
project actors. Thequestions are about how the campus finance office handles every
customer or employee, how they pay salary (prepare payroll).
 Internet:-
Internet aids or help us to see the available sample on the internet and to download different
types of tutorials that help to do the project.
1.5.2. System development methodology
It is a recommended collection of phases, procedures, rules, techniques, tools, documentation,

and training to improve the quality of a software development effort.We useobject-oriented
system analysis and design methodology.
An object-oriented system analysis and design methodology suitable for this particular project
because:-
 Increased re-usability
 Users usually understand the objects easily
 Object-oriented system analysis and design methodology is more user friendly
1.6. Scope of the project

The system would design for the enhancement or development of a computerized financial
management system for the University of Gondar Atse Tewodros campus. The system
performs operations in the finance management system includes:-
• Employee Attendance submission
• Calculating and preparing payroll
• Generating report
• Register income and expenses
• Create user account
• View report
5|Page
• Assign budget
• Update user information
• Delete user information
1.7. Limitation of the project
 The system works only in the English language

 Interms of time the system is not connected to human resource management system and
bank sysetm.
1.8. Constraint of the project
A constraint is a restriction on the degree of freedom we have providing a solution for the
system. Many constraints affect us to develop a full-function-able new system. Some of
these are:-
 Failure of electric power: to mitigate this problem we used personal resources like a
laptop.
 Time: to develop the new system we have only seven-week, so these are not quite enough.
 Connection: to get every aspect of information connection is very necessary, but we can’t get it
at any time.
 Budget: since all, we are students we have no enough money for a copy, print, etc.
1.9. Alternative solution of the project
The existing system has drawbacks that have a limitation on the functionality, performance,
efficiency, and speed of the system because the system operates manually. To overcome the
existing system problems, that s functioning inthe University of Gondar Atse Tewodros
campus, the project team members have put down alternative options. These are:
Develop desktop applications (They are easier to access once it installed) and it gives
better system integration.
6|Page
1.10. Feasibility of the project
Feasibility is assessing the visibility of this project through different factors. Accessing
feasibility means answering the question of the utility and usability of the system that is going
to be developed. We have analyzed the feasibility of the system in terms of economic
feasibility, technical feasibility, operational feasibility, and organizational feasibility of the new
system.
From the broad idea of what solutions are provided to solve the current system problems, the
best solution should be selected. The best solution selected is focused on the system acceptance
in different areas which have to be examined in terms of feasibility study of the proposed
system. To get user acceptance and making the system easily understandable and accessible the
new system
1.10.1. Operational feasibility
It Measures how the proposed system solves the problem of the existing system. The design is
very easy for everybody to interact with the system it will not have any operational problem.
It will minimize the amount of effort to do all through manually. The new financial
management system is operationally feasible and it doesn’t affect the organization structure.
The new system is operationally feasible in terms of reliability, supportability, usability, and
flexibility. The new system will be:-
 User friendly
 Easier tonavigate the page
1.10.2. Economic feasibility
The system which we have developed would be economically feasible. Because when we
compare the existing manual system with the new system the system requires less expense.
The existing system has cost and manpower expeditions. All works are done by papers,
document folders, folder holder tables which can make it so difficult to search or find a
document by looking with dates or names. This needs manpower and cost to make it done
easily.
7|Page
So the proposed system will reduce the cost and manpower expeditions by making the system
more easy and friendly to communicate/work using only computers.
The Economic feasibility analysis includes the concern of cost-benefit analysis, long-term
usage, cost of resources needed for the development and implementation of the project. In the
existing manual financial management system, the finance officers have to maintain a large
number of papers or forms. This can be avoided by putting the data in a computer format that is
cheaper and reliable. Since the cost of resources for the development of the system satisfies the
organization, the software is economically feasible.
1.10.3. Technical feasibility
The system which we have developed, would be technically feasible. The new system does not
require new professional person that process the implemented system, because the system does
not need many employees which need special computer skill. The system can be operated in
simple way and all users can access it easily by giving some training for them.
1.10.4. Organizational feasibility
Organizational feasibility attempts to developing and implementing a new system, against the
benefits that would augment from having the new system in place. This feasibility study gives the
top management the organizational justification for the new system. So the new system is
considered to be organizationally feasible.
1.11. Proposed solution
From the alternative solution, the desktop application is designed specifically for the operating
system/hardware that it’s run on. This means that software maintenance can become reliant on
upgrading the hardware, as much as the program. This means the desktop application is limited
by hardware and an Application server generally requires more expenses, especially for the
setup process,and managing the server too needs additional cost since there is an increase in
security and reduced need in resources.
Unlike a desktop applications, web-based applications are not as reliant on the hardware you’re
using. This means that older, newer, faster, bigger, and smaller machines can all access and use
8|Page
the program. Therefore the proposed solution of the system is a web-based financial
management system for the University of Gondar Atse tewodros campus.
1.12. Significance of the project
There are several reasons why a finance management system is necessary for the University of
Gondar Atsetewodroscampus. It has the following purposes.
• To give the fastest payment system
• To use time effectively
• To satisfy employee or customer
• To remove manual data handling
• Minimize manual data entry
• Easy to use the system
• Minimize workload
• Better service
• Greater efficiency
1.13. Benefit and Beneficiary of the project
1.13.1. Benefits of the project
As a project, this computerized financial management system would have the following
tangible and intangible benefits
Tangible benefits:- Is a benefit that can easily be quantified the system would provide tangible
benefits such as
• Decreases workload
• Increase speed of activities to the system
• Increased efficiency & effectiveness of the information
9|Page
• Problems & Error reduction
Intangible Benefits:- Refers to items that can not easily be measured in terms of money and
with certainty. It cannot be determined the exact amount of money consumed. Intangible
benefits are as follow: -
• Improved user satisfaction
• Reduce employee or customer westage of time
1.13.2. Beneficiaries of the project
The main beneficiary of this system is the finance department in which the environment is
changed to a computerized environment, which improves the quality of internal operations like
accuracy, timeliness, reliable, secured, relevant and valuable data usage for the finance
department.
The other beneficiaries of the system are employees Ones the new system is implemented,
firstly employees are benefited from the system in such a way that the quality and performance
of their work is improved, the time they spent for manual operation is significantly reduced and
their management and control of their job is improved. In addition to this, the employee’s
efficiency became increase.
1.14. System Development Tools
1.14.1. Hardware tools
Different hardware tools will be used to develop our project
• Computer: - we would use the computer to install software that are necessary for the
work like MS word, WAMP, and to do other tasks related to the project.
• Printer: - for printing documentation.
• Network cable: - we would use a network cable to get internet access which is used to
get many information about the project.
• Flash disk: - used to store the file and move from one computer to another computer.
10 | P a g e
• Pen and paper:- for writing all necessary documentation associated with the project.
• Notebook: - to take notes during data collection and for other documentations.
1.14.2. Software tools
We would use different software tools to develop the project.
• MS word: - used to write the proposal of the project
• MSpowerpoint: - used to present the document in abstract forms. We would use

it to present the presentation in a short and brief way.
• WAMP server and programming languages PHP:-which is a server-side

scripting language used to collect information from the user interface storing in
a database retrieving data from the database and displaying the data retrieved on
the user interface.
• HTML:-to design the user interface by creating forms to receive input from
users.
• CSS:-describes how HTML elements are to be displayed on screen
• Notepad ++:- used to write source code.
• E-draw max: to draw different diagrams
1.15. Cost and Budget Estimation
1.15.1. Hardware cost
Table 1: Hardware cost
Tools Material Quantity Estimated Unit Estimated Total

cost in birr Cost in Birr
Copy/print - - 100
Paper Half packet 125 125
Ware
Pen 3 10 30
Mobile card 10 10 100
Tools
Hard
Flash 1 300 300
11 | P a g e
Computer 1 17,000 17,000

Total price 17,655
1.15.2. Software cost
Table 2: software cost
Tools Material Quantity Estimated Unit Estimated Total

cost in birr Cost in Birr
MS word 2007 1 Free free
MS powerpoint 1 Free free
Software Tools
E-draw max 1 Free free

WAMP server 1 Free free
Notepad++ 1 free free
Total cost 0
1.15.3. Transport Cost
Table 3: Transport cost
Place Number Day go to Birr

the office
Atse Tewodros finance office 3 0
Total 7 0
12 | P a g e
1.15.4. Communication Cost
Table 4: Communication cost
Type Birr
For communicate finance office manager and 20
employee
For adviser 40
For team member 100
Total 160
1.16. Time Schedule
Table 5: Time schedule
Phase Task April 6 – April April 18–May 09 May 10 – May 27

17
1 Proposal
2 System
analysis
3 System
Design
13 | P a g e
CHAPTER TWO
SYSTEM ANALYSIS
2.1 INTRODUCTION
Systems analysis is the process of studying a procedure to identify its goals and purposes and
create systems and procedures that will efficiently achieve them. Another view sees system
analysis as a problem-solving technique that breaks down a system into its component pieces
for studying how well those parts work and interact to accomplish their purpose[2].
This chapter contains the requirements of the system and the problem that we are going to
solve. This phase is broad and contains many diverse activities and tasks that are extremely
important to the overall success of the project.This includes requirement analysis, current
system description, drawbacks of the current system, problem analysis, proposed system
description Also this chapter contains and describes Functional requirements and non-
functional requirements, system use case diagram, system use case description, and Analysis
Model (Activity diagram, Sequence Diagram, and conceptual modeling class diagram).
2.2. Description of the Existing system
The existing system of the University of Gondar Atse Tewodros campus Finance management
system works manually. The main objective of this part is to study the nature of the system in
detail and identify the problem as well as to define the relevant way to design a new system for
the University of Gondar Atse Tewodros campus finance management system. When we were
analyzing the existing system of the University of Gondar Atse Tewodros campus financial
management system, we have tried to study the detailed nature and procedure of the tasks and
operations performed by the finance department regarding employee or customer payroll. By
having this analysis over the system we were explained the tasks performed.
14 | P a g e
The existing system works manually; first, the employee or customer attendance is submitted
by the department head to the finance office, this attendance contains employee id,
name,department,workday, absent day, etc. then the accountant prepare or calculate the
payment of the employee based on the given attendance and forward performed task orthe
report to the finance director.
In the existing system, the financial works are done manually and there are errors due to
oversight that may result in loss to the data and to the organization. For an organization, time
is savery important factor. They work manually, unsatisfactory and very difficult to work
because their current work system has many problems such as lack of security of data, needs
manual calculations using paper and calculator, no fast retrieval of data time, consume a large
volume of paperwork and more manpower, waste of too many hardware materials and loss of
their files. All the necessary records of the above management activities are kept manually on
paper.
Some problem in the existing or current system
Performance
The performance of the existing system does not provide a fast response time because it is
difficult to access data from the stored document. And also, it is slow /time, and energy-
consuming.
Security and Controls
Every record of the existing financial management system is stored manually, so, it is difficult
to control and secure these manual records since it doesn’t have any authentication and
authorization system.
Cost
Due to the operation that is done by the hand most of the activities are causes by high
consumption of resources like papers, manpower, time, etc. This makes the existing system
costs are too high.
Data storage problem
15 | P a g e
• Data are not easily accessible due to place in different location.
• Difficult to change and edit.
• Data redundancy leads to inconsistency.
2.3. Overview of the proposed system
The key solution to avoiding all the problems mentioned previously is to find a unified way to
solve the problems mentioned earlier. The proposed system of the project changed the existing
manual process of the organization to the new system. To eliminate the drawback of the
existing system, the unified way is computerization. The new system gives the system
functionality that is needed by the system user to perform system functionality.
The proposed or new system works; first, the employee or customer attendance is submitted by
the department head to the finance office, this attendance contains employee id,
name,department,work day, absent day, etc. then the accountant prepare or calculate the
payment of the employee based on the given attendance and forward the report to the finance
director and post payment information and other necessary information to the employee. The
system admin is to manage the system such as create user account, update user information is
work computerized.
The main aim of the proposed system is that
• Is to reduce human errors by providing user-friendly capabilities and record keeping.
• Reduce resources that waste in the manual system.
• To store data in the database .
• To enable the finance staff to facilitate its day to day activity efficiently by using the
new technology.
• The authorized users access the data
16 | P a g e
2.4.Input and Output of the system
University of Gondar Atsetewodros campus financial management system performs most of the
activities manually.
Input
• AccountantsGathering employee’s attendance from departments by list their employee

id, first name, last name,department, absent day and workday to calculate payroll is also
done computerized.
• Accountant and head recive request from employee or customer
Output
 Providing payment information to employees or customers is also done computerized.
 After the Accountant makespayroll, register income, and register expenditure generate their
work to the finances director iscomputerized.
 Accountant and head are response their recive requests from employee or customer
2.5. Requirement analysis of the new system
2.5.1. Functional requirement
Functional Requirements are those that refer to the functionality of the system, i.e. what
services it will provide to the user. Statements of services the system should provide how the
system should react to particular inputs and how the system should behave in particular
situations. The new system would perform the following tasks.
• Accountant can generate reports or performed task,Register income andRegister

expenditure.
• Accountant can Make payment for the employee.
• Finance director can View the report and manage all over activity in the finance .
17 | P a g e
• The customer can be Send request and view response from accountant and department
head.
• The system admin is to create account for the user and manage their account .
• Department head Submit employee attendance to accountant for the purpose of making
payment and accountant Post payment information to the customer
• Customer View payment information
2.5.2 .Non Functional requirement
Non-functional requirements pertain to other information needed to produce the correct system
and are detailed separately.
Non-functional requirements describe how the system works, while functional requirements
describe what the system should do. They specify criteria that judge the operation of system
qualities to capture the required properties of the system. Then the team is going to develop its
own non-functional requirements, such as:-
• User interface: - The system should havean attractive, suitable for the user,and easily
understandable interface.
• Hardware consideration: -the organization should have computers having typical

storage capacity and processing speed.
• Error handling: - When the users of the system interact with the system errors may
appear. To control these inaccuracies the system would generate different messages.
Data errors that are entered into the system can be minimized or reduced.
• Security: - the system should have a security privilege that secures the system. That
means the system can only be accessed by authorized persons and on their privileges.
The administrator of the system monitors overall activity.
18 | P a g e
• Performance: - the system should be responsibly fast to access the required

information.
• Modifiability or Extensibility: - the system would have the ability to add future
functionality.
• Reusability: - the system would have the ability to reuse in future system
2.6. System Architecture Diagram
2.6.1.Current System Architecture
The existing system of the University of Gondar Atsetewodros campus financial management
system ismanual and there is no current software architecture that will be considered. As a
result the only describe the software architecture of the newly proposed system.
2.6.2.Proposed System Architecture
It is the architecture that determines the type of interactions that the components are going to
have. The System architecture of the University of Gondar Atse Tewodros campus financial
management system that does this work uses Client/Server architecture. In this type of
architecture, the server is responsible to receive a request from the client and respond to the
request, whereas the client is responsible to interact with that of the users of the system. The
server does two types of work. The first type is a web (application) server, which is responsible
to receive browsers’ requests through HTTP protocol and responds accordingly. Whereas the
second type of server is a database server, which is responsible to provide the requested
database services to the application server. The database serverscan only communicate with the
webserver. The client-side is a web browser that receives requests from the user of the system
and responds to the request by communicating with the webserver. If the user has a request on
data, the browser passes the request to the webserver then the webserver passes the request to
the database server.
The Figure below shows the architecture of the system.
19 | P a g e
Figure 1: Proposed software Architecture
2.7. System Use Case Diagram
Use Case represents the interaction between a user (human) and the system. Use case diagram
is one of the UML which represents the user’s interaction with the system and depicting the
specifications of a use case.
Use Case Diagram captures the system's functionality and requirements by using actors and use
cases. Use Cases model the services, tasks, function that a system needs to perform. Use cases
represent high-level functionalities and how a user will handle the system. Use-cases are the
core concepts of Unified Modeling language modeling[3].
2.7.1 Use case components
 Actor: is a person, or external system that plays a role in one or more interaction with
the system. And represented with:
20 | P a g e
 Use case: describe a sequence of actions that provides something of measurable value to
an actor and is drawn as a horizontal ellipse.
 System boundary: indicates the scope of the system project. Anything within the box
represents functionalities in the side in scope.
System
 Invocation of a use case by another one and One use case includes the behavior of
another use case at specific point.
-----<<include >>
 Extends is used to indicate an extend association and It is a generalization relationship
where an extending use case continues the behavior of a base use case
-----<<extend >>
2.7.2.Actor Identification
The systems actors that we identified are: -
Finance director: - a person who controls the overall activities of the finance staff and view all
reports that are generated from the system perform by accountant.
Accountant:- is the person who is responsible for calculating and preparing payroll of
employees, registering expenditures and incomes of the finance.
Head: - is a person who is responsible to submit employee attendance.
System admin: - is a person who is responsible for creatinguseraccount, update user

information and maintain when the system fails.
Customer: - is the person who use the system
21 | P a g e
Use case diagram
Figure 2: System Use Case Diagram
2.8 Use Case Narrative or description
A use case is a particular purpose that a user uses the system to perform the activity that takes
place in the system. The following use cases have been identified from the system
specification: -
22 | P a g e
• Login
• Create user account
• register expenditure
• Manage account
• register income
• prepare payroll
• Generate report
• View report
• Submit employee attendance
• View employee attendance
• View post information
• Post payment information
• Block user account
Table component description
 Use case number: - Give an identification number that enables you to make the use case
traceable.
 Name: - The name that you have used in the use case model.
 Actor: - who interacts with the system.
 Pre-condition: -what is the expected situation before the use case can be started.
 Basic flow of event: -order or sequence of action.
 Alternative course of action: - it is optional but it is the activity done when basic course
of actions failed.
 Post-condition:- what is expected.
23 | P a g e
Table 6: Use Case Description for Login
Name Login
Use case number UC1
Description To login to the System
Actor User
Pre- condition The user must have a username and password.
Flow of events 1. The user first click the login button
2. The system asked to insert a valid username and

password.
3. The user inserts username and password and clicksthe

login button
4. The System checks the username and password whether

it is valid or invalid.
Alternative flow of
4.1. The system validates the entered information the
events
input data is invalid. The system display error message
and asks again to enter a valid password and username.
4.2 The system validates the entered information the

input data is valid
The system is process to enter the system.
Post condition successfully enter to the System
Table 7: Use Case Description for CreateAccount
24 | P a g e
Name Create account
Use case number UC2
Description To create account for the user
Actor System admin
Pre-condition 1. The System admin first login to the system and open
createaccount form
2. There must be a user to be created
Flow of events 1. The System admin clicks “create account” button
2. The system displays the form
3. The System admin fills the necessary attribute and click the
“create” button
4. The System checks the the entered data whether it is valid or

invalid
Alternative flow of events 4.1. The system displays error message that the entered datais
invalid and allows them to enter valid data again.
4.2. the entered data is valid ,The system is process to creates the
account
Post condition successfully Created
Table 8: Use Case Description for Register Expenditure
Name Register expenditure
25 | P a g e
Use case number UC3
Description To Register expenditure
Actors Accountant
Pre-condition 1. The accountant must have valid username and password

2. The accountant first must login to the system
Flow of events 1. The accountant clicks “register expenditure” button
3. The accountant fills the necessary attribute and click the
register button
4. The system check the entered data is weather valid or invalid
Alternative flow of events 1.1 The system displays error message that the entered datais
invalid and allows them to enter correct data again.
1.2 The entered data is correct the system process to register
expenditure
Post condition successfully Registered
Table 9 : Use Case Description for Register Income
Name Register income
Use case number UC4
Description To Register income
Actors Accountant

26 | P a g e
Flow of events 1. The accountant clicks register income button

3. The accountant fills the necessary attribute and click the
register button
4. The system check the entered data is weather valid or invalid
Alternative flow of 4.1. The system displays error message that the entered data is
events invalid and allows them to enter valid data.
4.2. The entered data is correct the system process to register

income.
Post condition successfully Registered
Table 10: Use Case Description for Makepayroll
Name Make Payroll
Use case number UC5
Description Make payment
Actors Accountant

Flow of events 1.The accountant view the employee attendance
2.after view employee attendance the accountant click payroll
button
3.The system displays the form
4.The accountant fills the necessary attribute and click the
payroll button
5. The system check the entereddata is weather valid or invalid
27 | P a g e
Alternative flow of 5.1. The system displays error message that the entered data is
events invalid and allows them to enter valid data.
5.2 The entered data is correct the system process the payment.
Post condition successfully pay
Table 11: Use Case Description for Generate Report
Name Generate report
Use case number UC6
Description To generate report
Actors accountant
Pre-condition 1. The Accountant must have valid username and password

and logging to the system
2. There must be record to be generated
Flow of events 1. The accountant click generate report button
2. Then, the system displays the form
3. The user fills the necessary data and click the generate
button
4. The system check the entered data is weather valid or

invalid
Alternative flow of 4.1. The system displays error message that the entered
events data is invalid and allows them to enter valid data.
4.2. The entered data is correct the system process to
28 | P a g e
generate report.
Post condition successfully generate
Table 12: Use case description for sent request
Name Sent request
Use case number UC7
Description send request to accountant or and head
Actors customer
Pre-condition 1. The customer must have valid username and password

and logging to the system
Flow of events 1. The customer clicks request button
2. Then, the system displays the form
3. The customer fills the necessary data and click the

request button
4. The system check the entered data is weather valid or

invalid
Alternative flow of 4.1. The system displays error message that the entered
events datais invalid and allows them to enter valid data.
4.2. The entered data is corrects the system process to the

request.
Post condition Sent successfully
29 | P a g e
2.9. Activity diagram
An activity diagram is a flowchart to represent the flow from one activity to another activity.
The activity can be described as an operation of the system. The basic purpose of activity
diagrams is to capture the dynamic behavior of the system (4).
This UML diagram focuses on the execution and flow of the behavior of a system instead of
implementation. Activity diagrams consist of activities that are made up of actions that apply to
behavioral modeling technology.
The purposes of the activity diagram can be described as:
 Demonstrate the logic of an algorithm

 Illustrate a process or workflow between users and the system
 Simplify and improve any process by clarifying complicated use cases
30 | P a g e
Figure 3: Activity diagram for login

31 | P a g e
Figure 4: Activity diagram for create account

32 | P a g e
Figure 5: Activity diagram for payroll
33 | P a g e
Figure 6: Activity diagram for expenditure
34 | P a g e
Figure 7: Activity diagram for report generate
35 | P a g e
Figure 8: Activity diagram for sent request
36 | P a g e
Figure 9: Activity diagram for income register
37 | P a g e
2.10. Sequence diagram
A Sequence diagram is an interaction diagram that shows how objects operate with one another
and in what order. A sequence diagram shows object interactions arranged in a time sequence.
Sequence diagrams are sometimes called event diagrams. It is also:-
 Represent the details of a UML use case
 Model the logic of a sophisticated procedure, function, or operation
 See how tasks are moved between objects or components of a process
Figure 10: Sequence diagram for Login
38 | P a g e
Figure 11: Sequence diagram for create user account
39 | P a g e
Figure 12: Sequence diagram for payroll
40 | P a g e
Figure 13: Sequence diagram for register expenditure
41 | P a g e
Figure 14: Sequence diagram for register income
42 | P a g e
Figure 15: Sequence diagram for generate report
43 | P a g e
Figure 16 : Sequence diagram for Logout
2.11. Class Diagrams
Class diagram is a static diagram. It represents the static view of an application. Class diagram
is not only used for visualizing, describing, and documenting different aspects of a system but
also for constructing executable code of the software application[4].
Class diagram describes the attributes and operations of a class and also the constraints
imposed on the system. The class diagrams are widely used in the modeling of object oriented
systems because they are the only UML diagrams, which can be mapped directly with object-
oriented languages.
44 | P a g e
In the class diagram, classes are represented with boxes that contain three parts:
 The top part contains the name of the class

 The middle part contains the attributes of the class
 The bottom part gives the methods or operations the class can take or undertake
 The relationships among objects.
45 | P a g e
Figure 17: class diagram
46 | P a g e
CHAPTER THREE
SYSTEM DESIGN
3.1. Introduction
System design is the first part to get into the solution domain in software development. This
chapter focuses on transforming the analysis model into the design model that takes into
account the non-functional requirements and constraints described in the problem of the
statement and requirement analysis sections discussed earlier.
The purpose of designing is to show the direction of how the system is built and to obtain clear
and enough information needed to drive the actual implementation of the system. It is based on
the change to the system after it has been put into operation depends on the quality of the
system design. So if the system is designed clearly, it will be easy to make changes to it.
3.1.1. Design Goals and Objective
The objectives of the design are to model the system with high quality. The design goals are
derived from non-functional requirements that mean the non-functional requirement is the
description of the feature characteristics and attribute of the system .
Design goals describe the qualities of the system that the team memeber should consider.
 Security: the system should be secured, i.e., not allow other users or unauthorized users to
access data that has no right to access it.
 Modifiability: the system should be modifiable for further modification and enhancement
of the application.
 Performance: University of GondarAtseTewodros campus financial management system
should respond fast , i.e. It should perform updating userinformation, and generating the report as
quickly as possible.
 End-User Criteria: - The system should have a simple and understandable graphical user
interface such as forms and buttons. It should give a reliable response for each request at
least before the session expires.
47 | P a g e
 Reliability: it should be able to carry on invalid user inputs, reliable, and available.
 Cost: The system should be developed, deployed, administered, and maintained with minimum
cost as possible.
 Flexibility: The system able to change to suit new conditions or situations.
3.2. Process Modeling
Process modeling involves graphically representing the processes, or actions, that

capture, manipulate, store, and distribute data between a system and its environment
and among components within a system.
Process models are processes of the same nature that are classified together into a
model. Thus, a process model is a description of a process at the type level. Since the
process model is at the type level, a process is an instantiation of it. The same process
model is used repeatedly for the development of many applications and thus, has many
instantiations. One possible use of a process model is to prescribe how things
must/should/could be done in contrast to the process itself which is really what
happens. A process model is roughly an anticipation of what the process will look like.
What the process shall be will be determined during actual system development
3.2.1. Collaborative Diagram
A Collaboration diagram is easily represented by modeling objects in a system and

representing the associations between the objects in UML. The interaction between the
objects is denoted by arrows. To identify the sequence of invocation of these objects, a
number is placed next to each of these arrows.
A collaboration diagram, also known as a communication diagram, is an illustration of the

relationships and interactions among software objects in the Unified Modeling Language
(UML). These diagrams can be used to portray the dynamic behavior of a particular use case
and define the role of each object[5].
UML collaboration/communication diagrams like UML sequence diagrams are used to explore
the dynamic nature of your software. Collaboration diagrams show the message flow between
48 | P a g e
objects in an object-oriented application, and also imply the basic associations (relationships)
between classes.
Figure 18: Collaboration diagram for login
49 | P a g e
Figure 19: Collaboration diagram for create account
Figure 20Collaboration diagram for Register expenditure
50 | P a g e
Figure 21 : Collaboration diagram for Register Income
51 | P a g e
Figure 22: Collaboration diagram for logout
3.2.2 Persistence Modeling
Persistence modeling is used to communicate the design of the database, usually the
database to both the users and the developers. It is also used to describe the persistence data
aspect of the system.
Persistent data management deals with how the proposed system is going to handle the
actual data that need to be stored on the database of the system. The purpose of persistence
modeling is which objects in the system design are required to be stored persistently. The
persistence of our object can be achieved by a relational database since it is used as a
machine to make the object persistent. It describes the persistent data aspect of the software
system. Our system includes the basic table that handles the data of the system implemented
using the WAMP server.
Persistence diagram of the system.
52 | P a g e
Figure 23: Persistence Diagram
53 | P a g e
3.2.3. Deployment Diagram
A UML deployment diagram is a diagram that shows the configuration of run-time processing
nodes and the components that live on them. Deployment diagrams are a kind of structure
diagram used in modeling the physical aspects of an object-oriented system.
Deployment diagrams are used to visualize the topology of the physical components of
a system where the software components are deployed. So deployment diagrams are
used to describe the static deployment view of a system. Deployment diagrams consist
of nodes and their relationships. Deployment diagrams are used for describing the
hardware components where software components are deployed.
A deployment diagram is a graph of nodes connected by communication associations.
 Nodes may contain component instances.
 Components may contain objects (indicating that the object is part of the
component)
54 | P a g e
Figure 24: Deployment Diagram
55 | P a g e
Reference
1. https://www.gartner.com/en/finance/glossary/financial-management-system-fms-.
2. http://en.wikipedia.org/wiki/Systems_analysis.
3. https://www.guru99.com/use-case-diagrams-example.html.
4. https://www.tutorialspoint.com/uml/uml_class_diagram.htm.
5.https://searchsoftwarequality.techtarget.com/definition/collaboration-diagram.
6. http:// www.uml diagram.org

7.A.Hoffer. (2007). Modern Systems Analysis and Design (6th Edition).
8.(https://en.wikipedia.org/wiki/Process_modeling)
56 | P a g e

Web Based Finance System

Uploaded by

Document Information

Original Description:

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

Web Based Finance System

Uploaded by

Copyright:

Available Formats

UNIVERSITY OF GONDAR

DEPARTMENT OF INFORMATION TECHNOLOGY

1. Fikade Melkie …………………………..………. GUR/ 01731/10

2. Aragaw Abraraw……………..………..………… GUR/ 01798/10

5.Desalegn Gete…………………………….……………GUR/ 01861/10

The project entitled --------------------------------------------------------------------------------------------

College of Informatics, University of Gondar, in meeting the preliminary project

Advisor Name: - _______________ Date _______________________

Examiner 1 Name: - Date Signature

1.______________________ _______________ _____________________

2..______________________ _______________ ____________________

Table 1: Hardware cost ............................................................................................................... 11

Figure 1: Proposed software Architecture .................................................................................... 20

Financial management system performs various functions: reducing accounting errors,

1.2. Backgroundof the Organization

1.3. Statementofthe Problem

document which resulted in slow retrieval of data; difficulty in updating information

1.4. Objective of the project

1.4.2. Specific Objective

Specific objectives of the project:

• To Reduce the time to generate the report of the work.

• To Increase the security of the data by authentication

• Implementing the proposed system.

• Designing and developing supportive web site.

1.5. Methodology of the Project

To achieve the proposed system, we would use the following methodologies

1.5.1. Data collection Methodology

We have asked different questions some are:-

 What is the current problem of the manual system?

1.5.2. System development methodology

It is a recommended collection of phases, procedures, rules, techniques, tools, documentation,

1.6. Scope of the project

• Employee Attendance submission

• Calculating and preparing payroll

• Register income and expenses

• Create user account

• Update user information

• Delete user information

1.7. Limitation of the project

 The system works only in the English language

1.8. Constraint of the project

1.9. Alternative solution of the project

1.10. Feasibility of the project

1.10.1. Operational feasibility

1.10.2. Economic feasibility

1.10.3. Technical feasibility

1.10.4. Organizational feasibility

1.11. Proposed solution

1.12. Significance of the project

• To give the fastest payment system

• To use time effectively

• To satisfy employee or customer

• To remove manual data handling

• Minimize manual data entry

• Easy to use the system

1.13. Benefit and Beneficiary of the project

1.13.1. Benefits of the project

• Increase speed of activities to the system

• Increased efficiency & effectiveness of the information

• Problems & Error reduction

• Improved user satisfaction

• Reduce employee or customer westage of time

Advisor Name: - _ Date _________

1.______________ _ _______________

2..______________ _ ______________