WOLKITE UNIVERSITY

COLLEGE OF COMPUTING AND INFORMATICS

DEPARTMENT OF INFORMATION SYSTEMS
FINANCE MANAGEMRNT SYSTEM FOR WKU
By

Group Members Id Number

1. Darro Woge CIR/101/06

2. Endale Aragaw CIR/128/06
3. Niema Neja CIR/296/06
4. Seifedin Hussen CIR/322/06
5. Yonas Degefa CIR/388/06

UNDER GUIDANCE OF

MR. AMARE ABEWA

FEBRUARY 24, 2017

WOLKITE, ETHIOPIA
 WOLKITE UNIVERSITY

COLLEGE OF COMPUTING AND INFORMATICS

DEPARTMENT OF INFORMATION SYSTEMS

AUTOMATED FINANCE MANAGEMENT SYSTEMS

SUBMITED TO DEPARTMENT OF INFORMATION SYSTEMS

IN PARTIAL FULFILLMENT OF THE REQUIREMENT FOR

THE DEGREE OF BACHLOR OF SCIENCE IN INFORMATION SYSTEMS

BY:

Group Members Id Number

1. Darro Woge CIR/101/06

2. Endale Aragaw CIR/128/06
3. Niema Neja CIR/296/06
4. Seifedin Hussen CIR/322/06
5. Yonas Degefa CIR/388/06

WOLKITE UNIVERSITY, WOLKITE, ETHIOPIA

FEBRUARY 24, 2017
 Approval Form
This is to confirm that the project report entitled Automated finance management system for
Wolkite university submitted to Wolkite University, College of Computing and Informatics
department of Information systems in partial fulfillment of the requirement for the award of the
degree of Bachelor of Science in Information Systems is an original work carried out by Darro
Woge, Endale Aragaw, Seifedin Hussen, Neima Neja, and Yonas Degefaw under my guidance.
The matter embodied in this project is reliable and is genuine work done by the student and has
not been submitted whether to this University or to any other University/Institute for the fulfilment
of the requirement of any study.
Student Team Approval Form
Student Name Student Signature

---------------------------------- ----------------------------------

---------------------------------- ----------------------------------

----------------------------------- ----------------------------------
----------------------------------- ---------------------------------
----------------------------------- -----------------------------------
Advisor and department head Approval Form
Advisor Name Advisor Signature
------------------------------------ ---------------------------------
Department Head Name Department Head Signature
----------------------------------- --------------------------------------
Examiner Approval Form
Examiner Name Signature
----------------------------------- -----------------------------------
----------------------------------- -----------------------------------
----------------------------------- -----------------------------------
 Acknowledgement
First of all, we would like to thank GOD keeping us healthy to do this project. Next thanks to our
adviser Mr. Amare A for continuous support in every phase of the project and who continuously
provides us his valuable advice to prepare this project document because he is our roadmap to our
project. Deeply would like to say thanks Wolkite university finance department employees for
giving us full information about how the current system work. Finally thanks to group members
and other peoples who support us for our project document completion.

i
 Table of contents

Contents
Acknowledgement ........................................................................................................................................ i
Table of contents ......................................................................................................................................... ii
List of figures .............................................................................................................................................. v
List of Tables ............................................................................................................................................. vii
Abbreviation............................................................................................................................................. viii
Abstract ...................................................................................................................................................... ix
Chapter One ................................................................................................................................................ 1
1.1 Introduction ............................................................................................................................1
1.3 Background of the project .......................................................................................................2
1.4 Statement of the problem ........................................................................................................2
1.5 Objective of the project ...........................................................................................................4
1.5.1 General Objective ............................................................................................................................ 4
1.5.2 Specific objective ............................................................................................................................. 4
1.6 Feasibility Analysis..................................................................................................................4
1.6.1 Operational feasibility ..................................................................................................................... 5
1.6.3 Economic feasibility......................................................................................................................... 5
1.6.4 Behavioral/Political feasibility ........................................................................................................ 5
1.6.5 Schedule feasibility .......................................................................................................................... 5
1.7 Scope of the project .................................................................................................................6
1.7.1 In scope ............................................................................................................................................ 6
1.17.2 Out scope ....................................................................................................................................... 6
1.8 Significance of the project .......................................................................................................6
1.9 Target beneficiaries of the system............................................................................................6
1.10 Methodology for the project ..................................................................................................7
1.10.1. Data gathering methodology ........................................................................................................ 7
1.10.2. Software development model ........................................................................................................ 7
1.11 Systems Analysis and Design Approach.................................................................................7
1.11.1 Limitation of the project ................................................................................................................ 7

ii
 1.11.2 Risks & contingencies .................................................................................................................... 8
1.11.3 Assumptions and Constraints ........................................................................................................ 9
1.12 Team composition .................................................................................................................9
1.13 Time Table .......................................................................................................................... 10
Chapter Two: Description of the Existing System ................................................................................. 11
2.1. Introduction of Existing System ........................................................................................... 11
2.2. Organization structure ......................................................................................................... 12
2.3. Users of Existing System....................................................................................................... 12
2.4. Major functions of the Current System ................................................................................ 13
2.5. Existing System Workflow structure .................................................................................... 14
2.6. Report generated in the existing system................................................................................ 15
2.7. Forms and other documents of the existing systems ............................................................. 15
2.8. Bottlenecks of the existing system ......................................................................................... 15
2.8.1 Performance (Response time) ........................................................................................................ 15
2.8.2 Input (Inaccurate/redundant/flexible) and Output (Inaccurate).................................................... 15
2.8.3 Security and Controls .................................................................................................................... 16
2.8.4 Efficiency ....................................................................................................................................... 16
Chapter Three: Proposed System ........................................................................................................... 17
3.1. Introduction ......................................................................................................................... 17
3.2. Product Overview................................................................................................................. 17
3.3. User class and characteristics ............................................................................................... 18
3.4. Functional requirements ...................................................................................................... 19
3.4.1 Process requirements..................................................................................................................... 19
3.4.2 Input related requirements ............................................................................................................ 19
3.4.3 Output related requirements .......................................................................................................... 20
3.4.4 Storage related requirements......................................................................................................... 21
3.5. Nonfunctional Requirements ................................................................................................ 21
Chapter Four: System Analysis ............................................................................................................... 23
4.1 System models ....................................................................................................................... 23
4.1.1 Scenarios ....................................................................................................................................... 23
4.1.2 Use case model .............................................................................................................................. 23

iii
 4.1.3 Use Case Description .................................................................................................................... 25
4.1.4 Object model .................................................................................................................................. 43
4.1.4.1 Data Dictionary ...................................................................................................................... 43
4.1.4.2 Analysis level Class Diagram (Conceptual Modeling) .......................................................... 48
4.2 Dynamic model...................................................................................................................... 49
4.2.1 Sequence Diagram ......................................................................................................................... 49
4.2.2 Activity Diagram............................................................................................................................ 58
4.2.3 State Diagrams .............................................................................................................................. 67
4.3 ER Diagram .......................................................................................................................... 75
4.3.1 Mapping ......................................................................................................................................... 76
4.3.2 Normalization ................................................................................................................................ 78
Chapter Five: System Design ................................................................................................................... 82
5.1. System Overview .................................................................................................................. 82
5.2. Design Considerations .......................................................................................................... 82
5.3. Design Goals ......................................................................................................................... 83
5.3.1 End user Criteria ........................................................................................................................... 83
5.3.2 Security Criteria ............................................................................................................................ 83
5.3.3 Maintenance Criteria..................................................................................................................... 83
5.4. Design Trade-offs ................................................................................................................. 84
5.4.1. Development Cost versus Functionality ....................................................................................... 84
5.4.2. Understandability versus Efficiency ............................................................................................. 84
5.4.3. Security versus Availability .......................................................................................................... 84
5.5. Architecture of the System ................................................................................................... 85
5.6. System Decomposition .......................................................................................................... 85
5.7. Hardware/Software mapping (Deployment) ......................................................................... 88
5.8. Persistent data management ................................................................................................. 89
5.9. User interface design ............................................................................................................ 94
5.10. Object Design ..................................................................................................................... 95
5.10.1. Interface documentation guidelines ............................................................................................ 95
5.10.2. Class interfaces........................................................................................................................... 96

iv
 List of figures
Figure 1Timetable ......................................................................................................................... 10
Figure 2Organizational structure .................................................................................................. 12
Figure 3: Payroll Work flow ......................................................................................................... 14
Figure 4: Use case diagram ........................................................................................................... 24
Figure 5: Class diagram ................................................................................................................ 49
Figure 6: Sequence diagram for login ........................................................................................... 50
Figure 7: sequence diagram for employee registration ................................................................. 51
Figure 8: Sequence diagram for approve ...................................................................................... 53
Figure 9: Sequence diagram for generate pay slip ........................................................................ 54
Figure 10: Sequence diagram for expense registration ................................................................. 55
Figure 11: Sequence diagram for income registration .................................................................. 56
Figure 12: Sequence diagram for post notice ................................................................................ 57
Figure 13: Sequence diagram for report generation ...................................................................... 58
Figure 14: Activity diagram for login ........................................................................................... 59
Figure 15: Activity diagram for generate report ........................................................................... 60
Figure 16: Activity diagram for income register .......................................................................... 61
Figure 17: Activity diagram for expense register ......................................................................... 62
Figure 18: Activity diagram for calculate salary .......................................................................... 63
Figure 19: Activity diagram for approve request .......................................................................... 64
Figure 20: Activity diagram for employee register ....................................................................... 65
Figure 21: Activity diagram for pay slip ....................................................................................... 66
Figure 22: Activity diagram for post notice .................................................................................. 67
Figure 23: State diagram for login ................................................................................................ 68
Figure 24: State diagram for account update ................................................................................ 69
Figure 25: State diagram for update employee ............................................................................. 70
Figure 26: State diagram for employee register ............................................................................ 71
Figure 27: State diagram for calculate salary................................................................................ 72
Figure 28: State diagram for post notice ....................................................................................... 73
Figure 29: State diagram for expense register .............................................................................. 74
Figure 30: State diagram for income............................................................................................. 75
Figure 31: ER Diagram ................................................................................................................. 76
Figure 32: Mapping ....................................................................................................................... 77
Figure 33: First normal form ......................................................................................................... 79
Figure 34: Second normal form .................................................................................................... 80
Figure 35: Third normal form ....................................................................................................... 81
Figure 36: System architecture ..................................................................................................... 85
Figure 37: System decomposition ................................................................................................. 88
Figure 38 : Hardware and software physical mapping ................................................................. 89
Figure 39: Mapping account table ................................................................................................ 90
Figure 40: Mapping employee table ............................................................................................. 91
Figure 41: Mapping income table ................................................................................................. 91
v
Figure 42: Mapping expense table ................................................................................................ 92
Figure 43: Mapping report table ................................................................................................... 92
Figure 44: Mapping budget table .................................................................................................. 92
Figure 45: Mapping Notice table .................................................................................................. 93
Figure 46: Database relation for persistent data ............................................................................ 93
Figure 47: Login user interface ..................................................................................................... 94
Figure 48: User interface for profile setting.................................................................................. 95
Figure 49: Employee class ............................................................................................................ 96

vi
 List of Tables
Table 1: Team composition............................................................................................................. 9
Table 2Payroll form ...................................................................................................................... 15
Table 3: Use case description for .................................................................................................. 25
Table 4: Use case description for manage account ....................................................................... 26
Table 5Use case description for manage employees .................................................................... 27
Table 6: Use case description for approve .................................................................................... 28
Table 7: Use case description for manage budgets ....................................................................... 29
Table 8: Use case description for calculate salary ........................................................................ 30
Table 9: Use case description for register employee .................................................................... 31
Table 10: Use case description for create account ........................................................................ 32
Table 11: Use case description for block account......................................................................... 33
Table 12: Use case description for update account ....................................................................... 34
Table 13: Use case description for delete employee ..................................................................... 35
Table 14: Use case description for update employee .................................................................... 36
Table 15: Use case description for prepare pay slip ..................................................................... 37
Table 16: Use case description for generate report ....................................................................... 38
Table 17: Use case description for adjust budget ......................................................................... 39
Table 18: Use case description for record commitment ............................................................... 40
Table 19: Use case description for record payment receivable .................................................... 41
Table 20: Use case description for send request ........................................................................... 42
Table 21: data dictionary for expense table .................................................................................. 43
Table 22: data dictionary for income table ................................................................................... 44
Table 23data dictionary for employee table .................................................................................. 44
Table 24: data dictionary for employee table ................................................................................ 45
Table 25: data dictionary for expense category table.................................................................... 45
Table 26: data dictionary for income category table ..................................................................... 45
Table 27: data dictionary for budget table .................................................................................... 46
Table 28: data dictionary for account type table ........................................................................... 46
Table 29: data dictionary for department table ............................................................................. 46
Table 30: Data dictionary for Wing category table....................................................................... 47
Table 31Data dictionary for payment table ................................................................................... 47
Table 32Data dictionary for notice table ....................................................................................... 47
Table 35 sequence diagram for calculate salary ........................................................................... 52

vii
 Abbreviation
 Acc VP-------------------------------------Academic vice president
 Add VP-------------------------------------Administrative vice president
 CD-------------------------------------------Compact disk
 CSS------------------------------------------Cascading stylesheet
 CDRW--------------------------------------Compact disk rewritable
 DBMS---------------------------------------Database management system
 DVD-----------------------------------------Digital versatile disk
 E.C-------------------------------------------Ethiopian calendar
 ERD------------------------------------------Entity relationship diagram
 FMS------------------------------------------Finance management system
 HR-------------------------------------------Human resource
 HTML---------------------------------------Hypertext markup language
 IT---------------------------------------------Information technology
 LAN------------------------------------------Local area network
 MVC-----------------------------------------Model view controller
 MOFED------------------------------------ Ministry of Finance and Economic Development
 RDBMS-------------------------------------Relational database management system
 UML-----------------------------------------Unified modeling language
 WKU-----------------------------------------Wolkite University

viii
 Abstract
Finance management System (FMS) of Wolkite university activity related with receive different
income, employee registration related to finance, record service, view income and expenditure in
the organization and process payment for finance. The existing FMS at Wolkite university is
susceptible to the following major problems: difficulty to identify annual income and expenditure,
student who paid or not (extension and night), update payment status is difficult, inconsistence
data and poor time management and inappropriate payment handling and problems to generate
report, controlling budget is difficult. The general objective of this project is to develop automate
Financial Management System for Wolkite university. The main modules to be handled by this
system are managed account, register employee and student related to finance and payment
handling. To get the accurate data from Wolkite university finance we use observation and
interview. To analyze the document, the project follows an object oriented analysis and design
approach. Razor engine(C# and html) will develop the generation of client side web service.
The server side will be developed by using Asp.net mvc5 entity framework.

ix
 Chapter One

1.1 Introduction
Organizations develop IT systems to meet important business objectives, such as improving
competitiveness, increasing productivity and efficiency, accelerating growth, supporting
innovation and reducing costs. Productivity is an important reason for developing IT systems. IT
systems are key to delivering the information and intelligence you need to improve innovation.
Investing in IT systems and tools to improve collaboration can help you achieve growth and
productivity targets. The quality of customer service is an important element in building and
maintaining competitive advantage. IT systems can help you improve customer service in a
number of ways. A financial management system is the methodology and software that an
organization uses to oversee and govern its income, expenses, and assets with the objectives of
maximizing profits and ensuring sustainability.
Therefore, we need to automate finance management system for Wolkite University. The
automated finance management system include the functionality such as record employee detail
information related to finance, record student (extension and night students) information related
to finance and produce different reports etc. The logical reason for automating this manual system
from manual to automated system is to simplify the functionality of the system such as increasing
performance of the system, enabling users to request for finance service, to enhances the security
of the system, to avoid data redundancy and data inconsistency, to avoid consuming a lot of time
and resource, to minimizing the work load of the employee.

1
1.2 Background information of the Organization
Wolkite University is one of educational institution in Ethiopia, which is located in Southern,
nation and nationalities region, Guraghe Zone. It was founded or starts in 2004 E.C with few staffs.
Now it has many directorates and departments with staffs. From those directorates we are dealing
with finance. The finance department is responsible in giving service, which are payroll, income
and expenditure controlling, and budget controlling. However, the financial management in
Wolkite university is not automated each section perform their tasks manually like generate
reports, store documents, and calculate salaries. The current manual system has its own managing
its resources, and employees.

1.3 Background of the project

Now a day, the introduction of new information systems is increasing at an alarming rate to bring
radical change to the existing manual system, improve the performance of other systems and solve
difficulties. Though this technology is new to our country Ethiopia and most of other developing
countries, it was/is exploited well in developed countries, like Europe, India and America. The
project is intended to advocate for the need of Wolkite University finance to use facilitated
computerized and web based finance management system. Because even if there is no automated
finance management system in the university, the department that give the service use manual way
of information documenting, no reliable communication between different sections, as well as
there is no optimized way to facilitate the service. So we are initiated to develop new web based
automated system. As a result, the team member believed that the user would have the expected
satisfaction of the service provided by web based finance management system for Wolkite
University.

1.4 Statement of the problem

Currently, Wolkite University finance department is working most operations manually, due to
this, it faces many problems. Like:
 Searching of data or files from large amount of documents is more boring and time wasting
because those data are recorded manually.
 Data entry is not consistent. Means similar data or information is kept in different format.
 There is less sharing of data and customer services. Because there is no way of customers
to view information about the services available.

2
 Identifying annual income and expenditure is difficult. Since reports are not timely and
accurately provided, the organization gets it difficult to identify its income and expenditure.
 Time consuming and costly to produce reports. Because reports are collected on paper, it
takes lots of time and needs many paper.
 Lack of security. There is no way to protect the users to perform their tasks within their
privileges, so unauthorized users can access unauthorized data. Because the available
security mechanism is only physical controlling no systematic way.
 Duplication of data entry. There are users that are performing the same tasks within the
same time; in this case, they may enter the same data at the same time.
 Controlling advance payment problem. When an employee takes advance payment they
have to report within 7 days unless they are not allowed to take another payment, but there
is no modern way of controlling this.
 There is no controlling per diem, allowance and overtime payment or it is checked by
manually. These means an employee may fill a form of per diem and overtime with the
same time, which is not allowed.
 Employees cannot see their salary information so they create more question and conflict
with their employers, which is very difficult to search and show their salary information,
including their allowance, deduction and others.
 Delayed and inaccurate financial report: Since it is made on paper, it may be delayed and
it may be inaccurate because of problems in data entry defined above.
 Less available: The current system is less available which means the operation time and
the place are restricted within few time and place.
 Auditing Problem. The existing auditing system is not bad at all, but it is takes most time,
and it is tiring so it has to be automated.
 Problems in sharing information with other departments and directories: Since there is no
integrated way with other departments and directories, it is time taking and tiring to get and
share information with other departments and directories.
 No technical support: When a user enter incorrect not validate data there is no technical
support which tells the user he makes an error.

3
1.5 Objective of the project
1.5.1 General Objective
To develop web based (automated) finance information management system for Wolkite
University.
1.5.2 Specific objective
Specific objectives are objectives that used to achieve general objectives. Our specific objectives
under web based finance management system are mainly to solve the existing problems that are
listed above in problem statement. To develop the system with more reliable way and user friendly.
To make highly secure and produce timely and accurate report as a result of validated and correct
data entry. Not only this and to make employees information accessible everywhere with local
network. To develop good and clear payroll system and auditing system. However, in order to
achieve specified general objective and solve such problems we will travel in some steps. These
are:
 Identify and define problems of the existing system: by gathering data from finance
department and other departments.
 Requirement analysis: from the identified problems try to identify or determine the needs
or conditions to be fulfilled by the new project with regard to functional and non-functional
requirements. These requirements should be documented, actionable, measurable, and
testable in order to analyze, document validate and manage system requirements.
 Design a new system that can overcome the problem of the current system
 Implement the new system.
 Testing the system: testing the system using different methodology, this will ensure us its
reliability.
 Deploy the new system.
 Maintain and update the system when needed.

1.6 Feasibility Analysis

Feasibility study is a mechanism to determine whether a project is possible to develop and
implement or not by considering various factor such as economic, technical, operational, schedule,
legal and contractual and political feasibility (htt7).

4
1.6.1 Operational feasibility
Operational feasibility is a measure of how well the solution of problems or a specific solution will
work in the organization. It is also a measure of how people feel about the system/project. The
new system will take advantage to solve problems outlined in the statement of the problem in order
to achieve specified objectives. Since the system will be user friendly, and interactive with the
environment, the organization will not have any difficulties to operate the system. The system will
provide end users and managers with timely, pertinent, accurate and usefully formatted
information. Thus, we can say the project is operational feasible (htt8).
1.6.2 Technical feasibility
Technical feasibility is a measure of the practicality of a specific technical solution and the
availability of technical resources and expertise. Developing this system, the products we will use
are computer, networking devices, networking operating system, database, programming
language. In today’s world, these products are easily available in the market so the organization
will and can afford to provide, this lead us to say it is technical feasible (htt8).
1.6.3 Economic feasibility
Economic feasibility is the process of identifying the financial benefits and costs associated with
the project being developed. The purpose of assessing economic feasibility is to identify the
financial benefit and cost benefit analysis economic feasibility is often referred as cost benefit
analysis. Our proposed system uses less cost resources so it is economical feasible. Since our
proposed system costs in low we can say it is economic feasible (htt8).
1.6.4 Behavioral/Political feasibility
It is the process of how stakeholders within the organization view the proposed system. Since, the
new system will solve many problems of the existing manual system and will not violet rules and
regulation of the government as well as the organization; we can say it is legally feasible (htt8).
1.6.5 Schedule feasibility
Measure of ‘’how responsible project time table”. It will be bound by strict timing so it must be
delivered within the time bound given over the time schedule. Our intention is to finalize it hope
fully plan it have it run in real environment before the end of submission date (htt8).

5
1.7 Scope of the project
The scope of the project is limited in developing an automate finance management system for
finance department at Wolkite university to replace the existing manual system.
1.7.1 In scope
Our project will perform the following financial management
 Payment
 Expenditure
 Income
 Budget
 Report

1.17.2 Out scope

Our project will not perform the following
 Bank transaction

 Foreigner payment

1.8 Significance of the project

 Give efficient and effective use to the users
 Provide timely and error free report.
 Provide secure and accurate information about employees

1.9 Target beneficiaries of the system

To system developing team members
 An opportunity to exercise how real life problem are solved.
 Going back and forth through each system development phase and acquire skill in
developing web-based system.
 Enriching theoretical knowledge (what it mean avoid ok).
To the institute
 Solves problems that are associated with the manual system.
 It can use the document as a reference material for related projects in the future.
To training coordinator and employees of the departments related with finance work
 Increasing job satisfaction by eliminating tedious tasks.

6
  Fast and error free activities.
1.10 Methodology for the project
1.10.1. Data gathering methodology
 Interview: In order to gather sufficient and relevant information for the proposed project,
we have arranged programs to interview the training coordinator management staff
members and trainees of the institutes.
 Observation: To get first hand accurate information about how the existing system works
we have examined physical observations on how employees perform their jobs to analyze
the existing condition.

1.10.2. Software development model

In software development model we use an iterative model because in iterative model we are
building and improving the product step by step. Hence we can track the defects at early stages.
This avoids the downward flow of the defects.

1.11 Systems Analysis and Design Approach

In this project, our team will use object oriented system development methodology (OOSD) for
data analysis. This technique has several phase some of them are-:
 Object oriented analysis (OOA):- during this phase the team uses to models the function of
the system (use case modeling), finding and identify the business objects, organize the
objective and identify the relationship between them and finally model the behavior of the
objects in detail.
 Object oriented design (OOD):-During this phase, our team uses Microsoft software to
refine the use case model and rational rose for designing the sequence collaboration,
activity diagrams and to model object interaction and behavior that support the use case
scenario.
The language that we are using to develop this system asp.net mvc5 entity framework, razor view
engine for front end and Microsoft sql server as back end.
1.11.1 Limitation of the project
Our project will have the following limitation
 Shortage of data: there is no enough information about other payments like foreigner
payments. Because of this we cannot include this types of payment.

7
  Shortage of time: We have shortage of time to complete the project in one semester. This
enforces our project team to minimize the project scope.

1.11.2 Risks & contingencies

Risk are future uncertain events with a probability of occurrence and a potential for loss. Risk
identification and management are the main concerns in every system development. Effective
analysis of software risks will help to effective planning and assignments of work. During the
development of the project, there may be different problems that we may face. These are:
 Unfortunate failure of system: To handle this problem the teams have some method to resist
not completely but partially by using back up mechanisms using flash disks, CD/DVD and
by storing the data on our Email account.
 Power problem: we tried to use laptops to cover the gap happened to our project during
power failure.
 Virus attack: It is difficult to control data from virus but try to scan the data, installing and
updating antivirus software and we use CDRW instead of flash.
 Time management problem: we solve this problem by working cooperatively, divide our
time by schedule for each phase of the project and we try to use this schedule effectively.
 Security: Security is paramount to this project because it handles organizational financial
information. If security of the financial information is compromised, this project will
become a liability to its users rather than a service. Security is a risk for any financial
management system. Failures in security may only be apparent after a clever hacker steals
user data. By thoroughly researching current security trends, the security of this financial
system will continue to improve.
 Budget Risk: Since the resources available have no guarantee, it is hard to us to estimate
budget so we may face this type of risk. Project scope expansion, this means if the project
scope is expand, it may face us budget risk because it is hard to estimate budgets by
considering its expansion. If cost overruns we may face budget risk, because some
resources are delivered to us from the university and at the same time they may be exist in
our material also.
 Operational Risks: Risks of loss due to improper process implementation, failed system or
some external events risks. This may occur due to miscommunication between the teams.

8
1.11.3 Assumptions and Constraints
Our project concerned all FMS for WKU finance system .The software is assumed to do all
activities related to Manage Finance and control. It also provide a database concept to retrieve,
store, Update, Delete and in generally to manipulate different operations into or from the data base
by user of the system. The activities of the users are restricted but the head administrator i.e. the
server side has a full access of the database. The system is also fully dependent on the server based
data base system.
Constraint: The system can run on any desktop computer running any operating system. Such as
windows XP, windows vista and so on. Safety and Security constraints: The danger that surround
in relation to security is problem caused by various that led to loss of data, make the data
unacceptable and other important things existing on the system or computer.

1.12 Team composition

In order to do the projects the team will meet three days a week and communicate with advisor a
day in a week and information to get about the college at any time by:

 Phone cell.
 Physical meeting.
 E-mail.

ID Name Responsibilities

CIR/128/06 Endale Aragaw Write proposal and implementation

CIR/101/06 Darro Woge System analyst

CIR/322/06 Seifedin Hussen System design

CIR/296/06 Neima Neja System analyst

CIR/388/06 Yonas Degefa System design

Table 1: Team composition

9
1.13 Time Table

Figure 1Timetable

10
 Chapter Two: Description of the Existing System

2.1. Introduction of Existing System

Finance directorate is one of the directorates in Wolkite University, which starts to give service
since 2004 E.C. It has two sections budget and payment section and account section. These two
departments perform different tasks. They prepare payment for program budget, which includes
regular payments, may be salary, and other payments and capital budget includes building
purchasing. They announce and distribute approved budget to administrative, academic, research
and resource generate vice presidents. They also provide annual report for each activities to the
finance department. They also have a relation to human resource and other departments in different
directorates. Some operations are more successful like auditing. Since these all tasks performed
manually, they faces many problems. For example, it is tedious to search data or files, sometimes
data inconsistency occur because they have no technical support system it is time consuming and
costly to produce reports. The main issue in finance is security since they have no any method to
prevent users with privilege there is high problem in security.

11
2.2. Organization structure

President

Addministrative vise
president

Finance directorate
director

Payment and Budget Section Account section

Figure 2Organizational structure

2.3. Users of Existing System

There are five actors interacts with the existing system. These are:
 Finance manager: - a user who control the overall activities of the finance staff and view
all generate report of the system performed by accountant, budget controller, payment
controller those are going to perform activities in the finance staff and the cashier.
 Cashier: Performing payment that are less than 5000 birr.
 Accountant: -The accountant controls income and expenditure of university by
communicating payment section and generate report. Make distributing and adjusting of
budgets.

12
  Payment controller:-A person who perform any payment like payroll payment, service
payment, per-diem payment, research payment, building payment, purchasing payment and
other payments. Budget controller:-A person who control over all university budgets. This
means approved budgets, adjusted budgets and budget balance.

2.4. Major functions of the Current System

The existing system has its own function and perform its operation within its departments; it is
divided to sub departments. Those departments are Payment and budget section and account
section. Let us see each function within the departments briefly:
 Budget Controlling: In this section there is budget preparation, budget distribution and
budget controlling. They control program budget (regular budget that is approved by
MOFED) and capital budget (including project budget like building and others).
 Payment Service: They provide payment service for salary, purchasing and others: which
may be cash for less than 5000 birr, check for birr 5000-50,000 and bank transaction for
birr above than 50, 000.
 Report Service: They provide annual report for each activity
 Auditing service: It is not from the finance department but they interact with audit service.

13
2.5. Existing System Workflow structure

Figure 3: Payroll Work flow

14
2.6. Report generated in the existing system
In the existing system, the report is generated as the requirement of the finance management
system. The finance manager or the person who manages the office asks the responsible worker to
provide report. As we observed and also interview the finance office the report generating
mechanism is paper based, that is any kind of report is delivered by worker and then it will be
transformed to whom it may concerns.

2.7. Forms and other documents of the existing systems

Payroll form:

N Emp Basic Wor Salary Rank Monthly Annua Mobile House OT Gross Inco Net

o loye salary k payabl Allow Support lizatio and Allowanc Payab me Pay

. e Day e ance n Transport e before le tax ment

Nam corre
ct
e

1 0 0 0 0 0 0 0 0 0 0.0 0.00 0.00 0.00

Table 2Payroll form

2.8. Bottlenecks of the existing system

2.8.1 Performance (Response time)
The performance of the existing system does not provide fast response time because it is difficult
to access data from the stored document. In addition, it is slow /time and energy consuming.
2.8.2 Input (Inaccurate/redundant/flexible) and Output (Inaccurate)
In the existing system there needs data to be registered or entered as input. Similar data or
information is kept in different format; this shows that data entry is not consistent. In addition,
similar data will be record at the same time with different users, which results in duplicate data
entry. As a result, the output obtained will be inconsistent data.

15
2.8.3 Security and Controls
Every record of the existing financial management System is stored in the manual way, so, it is
difficult to control and secure these manual records, since it does not have any authentication and
authorization system.
2.8.4 Efficiency
Since the existing system is performing its work manually it takes lots of time to finish a certain
task which result in low efficiency.

16
 Chapter Three: Proposed System

3.1. Introduction
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 our project changes the existing
manual process of the organization to new system. To eliminate drawback of the existing system,
the only unified way is computerization. The new system perform all the manual operation that is
needed by system user to perform system functionality. The main aim of the proposed system is:
 To reduce human errors by providing user-friendly capabilities and record keeping
mechanism.
 Reduce resources that waste in the manual system like papers and others.

 To store data into the database so, it can be easily retrieved and used at any time.

 To provide high security of data.

 To enable the finance staff to facilitate its day-to-day activity efficiently by using the new
technology.

3.2. Product Overview

The proposed system will provide:

 Greater efficiency for recording file:Since the proposed system uses database system,
registering files, and updating of progress files from the database will be easy and there
will not be loose of data.
 Security: since the proposed system requires verification of login form, sensitive
information’s will not be accessed or modified by unauthorized users.
 Better service: since the proposed system allows users to report online without a need of
going to each departments, there will be fast response for requests
 Efficient retrieval of finance files: Since the proposed system record, each file on the
database, retrieval of finance files from the database at any time will be a very easy process.
 Increase Operational Efficiency: The proposed system should help in reducing the
repetitive paperwork/records and making the department functions more efficient.

17
3.3. User class and characteristics
A user class is a particular purpose that a user actually uses the system to perform the activity takes
place in the system. The following user classes have been identified from the system specification.
Manager Perform the following:

 register employee

 update employee

 delete employee

 update account

 approve request

 search and view financial info

Cashier Perform the following:
 update account

 prepare pay slip

President, Head, Dean, research head, Acc Vp, Add VP, HR head: these all approve request.

Administrator: Perform the following:

 create user account

 block user account

 update his account

Accountant: Perform the following:

 update his account

 calculate expense

 calculate income

Budget controller: Perform the following:

 view approved budget

 adjust budget

 view adjusted budget

18
  record new budget

 record commitment

 view commitment

 record payment receivable

 update account

Reporter: Perform the following:

 update account

 generate report

Payment controller: Perform the following:

 update account

 calculate salary(generate pay slip)

3.4. Functional requirements

Functional requirement talks about the proposed or designed behavior of the proposed system. Or
simply what our system is supposed to accomplish or something our system should do. The system
has the following functional requirements:
3.4.1 Process requirements
The following are some major process requirements, which the system should handle:
 Data integrity. Commit transactions that are completed and/or rollback unfinished or
timeout transactions.
 Data validation. Data error from the user’s end and from the back-end database-processing
end must be gracefully handled. There will be data validation and error-handling routines
as part of the finance management system.
 The system should allow checking budget balances.

 The system should allow the administrator to manage user’s accounts.

3.4.2 Input related requirements

Each employee is assigned a unique identifier upon. The employee must know this. This
identifying key maps to all his/her registration record information in the main record system,

19
because employee information is recorded. Such account maybe disabled when the employee leave
the organization.
 The system should allow to record employee information
 The system allows to record income and expenditure. Since there is need of auditing and
when the user wants to record new income and expenditure, the system should provide a
form to record different income and expenditure.

The above requirements are input related requirements of our system, and the facilities that the
system uses to take inputs from the users are listed below:
 Excel: It used to import employee and payroll information.

 Forms: This makes users fill their forms, which is required to be filled.

 Dialog: This enables users to make their confirmation for any request.

3.4.3 Output related requirements

Each finance management system user must have a view of summary of actions done for a
particular session or a particular function. The DB2 registration database will be able to display
all successfully committed transactions.
 The system shall allow generating report.

 The system shall allow the cashier to view authorized payment.

 The system allows to search and view data about finance information with restricted authority.

 The system shall allow displaying transaction summary.

 The system shall display confirmation

20
All the above are output related requirements, and the methods this output displayed are listed
below.
 Excel: Like salary information is displayed with it, because bank need it in the form of
excel.
 Word and pdf: Report information and salary slips will be displayed.
 Email: Employee information will be sent to their email one or two day before salary day.
 Popup Screen: Confirmation or notification message will be displayed.
3.4.4 Storage related requirements
Since finance has very sensitive data to the organization and others information the database should
perform some functionality listed below:
 The system should allow to store data in organized manner, which must be easy to access.

 The system should allow to modify stored data easily

 The system should allow to prevent data redundancy.

 General ledger management: Store all financial records for purpose of information.

 The system should allow to store log in information.

 There should be backup method.

3.5. Nonfunctional Requirements

Non-functional requirements pertain to other information needed to produce the correct system.
Constraints on the services or functions offered by the system such-as timing constraints,
constraints on the development process, standards, etc.
 Performance: The system must have quick response time. The system should respond users
request within few microseconds interval. The system must be simple to retrieve
comprehensive information.
 Reliability: Before the deployment of the system, it must undergo testing, verification and
validation step after deployment of the system, field data can be gathered and analyzed to
study the behavior of software defects.
 Availability: A system is always operational and available for use as much as possible
reduces down time. The system provides services for all system users without any time
limitation.

21
 Security: The system will have user accounts for its users. The passwords will be encrypted.
There is no such functionality in the system by which the user can register himself to the
system because there are limited system users, so the system administrator creates the user
accounts. The system administrator can activate, deactivate, create, and delete user
accounts.
 Maintainability: Since we follow the implementation in modular way that used to easily
identify the error and handle it. In the system, there is user management, registration and
report module; so if there is a problem one of these modules it is easy to maintain.

22
 Chapter Four: System Analysis

4.1 System models

4.1.1 Scenarios
The following describes scenario of how the user use the systems to perform operations.
Scenario name: login
Participant actor Mr. Endale
Mr. Endale as user if he wants to login to the system first he will run the system and the system
display home page. Next Mr. Endale click login link from home page. After that the system
display login form then Mr. Endale will fill login form and click login button and home page is
displayed next Mr. Endale perform his authenticated operation and logout.
Scenario name: employee registration
Participant actor Mr. Endale
Mr. Endale as manager if he wants to register an employee fist he will rum the system and log into
the system. Next, he will click on register employee submenu the system will display employee
registration page. Then he will fill all employee information to the form and click register button.
If he fills invalid data the system will display error message else the employee I successfully
registered.
4.1.2 Use case model
A use case is a methodology used in system analysis to identify, clarify, and organize system
requirements. A use case is a list of actions or event steps, typically defining the interactions.

23
between a role (known in the Unified Modeling Language as an actor) and a system, to
achieve a goal.

Addmini Accada
strative Head budget
mic VP Dean
VP controlle
r

Automated Finance Department view approved

budgets
Extend
Researc
h head Approve adjust budget
Requests Register
employees Extend
Extend Manage View adjusted
Extend
Update budgets budget
Presiden Extend employees Extend
Manage Include record
t Employees Include Extend commitments
Extend Delete
employees Extend View commitments
Extend Include

Manager Search and view record payment

employees Login Include recievable
Include
Update account Manage
Extend accounts
Extend
Send
Admin
request Include Include
Extend Create account
HR Extend
Check Include Include Include
approved Include
Block account
payments Include
Generate report Logout

Prepare payslip Calculate

Expense
Record recievables

Calculate salary Calculate

Cashier Income

Paymen
t controll Account Report
er ant

Figure 4: Use case diagram

24
 4.1.3 Use Case Description

Use Case ID UC1

Use case name Login
Description Allow the user to login to the system
Actor All
Pre-condition The user must have valid username and password in the system
Basic course of action Actor System
Step1. The user click on login Step2. The system display login
link. page.
Step3. The user enter user name Step4. The system validate user
and password. name and password.
Step5. The system display target
page
Step6. Use case end.

Alternative course of action If username and password in not correct

A1. The system displays invalid username and password.

A2. The user will go to Step 3 of Basic course of action.

Post condition The user successfully log in and entered to the System.
Table 3: Use case description for login

25
 Use Case ID UC2
Use case name Manage Account
Description Allow the user to manage account which includes create and block
account.
Actor Admin
Pre-condition He must have active account, and must be logged in.
Basic course of action Actor System
Step1. The user click on manage Step2. The system redirects the
account. user to account managing page.
Step3. The user select and click Step4. The system redirect him to
his option from create and block needed page by his choice.
option. Step6. The system validate and
Step5. The user perform his accept his operation.
operation Step7. The system display success
message page .
Step8. Use case end.

Alternative course of action If the user enter wrong data

A1. The system displays invalid entry or operation.

A2. The user will go to Step 5 of Basic course of action.

Post condition The user perform account managing

Table 4: Use case description for manage account

26
 Use Case ID UC3
Use case name Manage Employees
Description Allow the user to manage employees which includes add, update and
delete employee.
Actor Finance manager
Pre-condition He must have active account, and must be logged in.
Basic course of action Actor System
Step1. The user click on manage Step2. The system redirects the
employee. user to employee managing page.

Step3. The user select and click Step4. The system redirect him to
his option from add, update and needed page by his choice.
delete option. Step6. The system validate and
Step5. The user perform his accept his operation.
operation Step7. The system display success
message page
Step8. Use case end.

Alternative course of action If the user perform incorrect operation or enter wrong data

A1. The system displays invalid entry or operation.

A2. The user will go to Step 5 of Basic course of action.

Post condition The user perform employee managing

Table 5Use case description for manage employees

27
 Use Case ID UC4
Use case name Approve
Description Allow the user to approve requests.
Actor Human resource head, Finance manager, Academic vice president,
Administrative vice president, President, Department head, College
dean, and Research head.
Pre-condition The user must have active account and must be logged in.
Basic course of action Actor System
Step1. The user click on Step2. The system display approve
notification button. request page.

Step3. The user click on approve Step4. The system display success
button. message.
Step5. The user click on reject
button. Step6. The system display replay
Step7. The user fill and click on description form.
replay button. Step8. The system display success
message.
Step9. Use case end.

Alternative course of action If the user fill I correct details

A1. The system displays incorrect entry.

A2. The user will go to Step 7. To fill replay reason.

Post condition The user successfully approve requests.

Table 6: Use case description for approve request

28
 Use Case ID UC5
Use case name Manage budgets
Description Allow the user to manage budgets which includes record approved
budget, view approved budget, adjust budget, view adjusted budget,
record commitments, view commitments, record payment receivables,
view payment receivables.
Actor Budget controller.
Pre-condition The user must have active account and must be logged in.
Basic course of action Actor System
Step1. The user select and click Step2. The system redirect him to
his option from record approved needed page by his choice.
budget, view approved budget, Step4. The system validate and
adjust budget, view adjusted accept his operation.
budget, record commitments, Step5. The system display success
view commitments, record message page Step6. Use case
payment receivables, view end.
payment receivables option.
Step3. The user perform his
operation

Alternative course of action If the user perform incorrect operation or enter wrong data

A1. The system displays invalid entry or operation.

A2. The user will go to Step 3 of Basic course of action.

Post condition The user successfully perform budget managing.

Table 7: Use case description for manage budgets

29
Use Case ID UC6
Use case name Calculate salary
Description Allow the user to calculate employee’s salary.
Actor Payment controller.
Pre-condition The user must have active account and must be logged in.
Basic course of action Actor System
Step1. The user clicks on calculate Step2. The system redirect him to
new salary. calculate salary page.
Step3.The user enter employee id
and click on search. Step4. The system display salary
Step5. The user enter information information entry form.
and click on calculate button.

Step6. The system display success

message.
Step7. Use case end.

Alternative course of action If the user enter, wrong id and try to search.

A1. The system displays error message.

A2. The user will go to Step 3 of Basic course of action.

If the user enter wrong and invalid information to salary information

entry form.

A1.The system display error message.

A2. The user will go to step 5.

Post condition The user successfully perform calculating salary.

Table 8: Use case description for calculate salary

30
 Use Case ID UC7
Use case name Register employee

Description Allow the user to register new employee

Actor Finance manager
Pre-condition The user must have active account and logged in.

Basic course of action Actor System

Step1. The user click on employee Step2. The system display target
management link. page.
Step3. The user select add new Step4.The system display
button. employee registration page
Step5. The user fill the form and
click register.

Step6. The system display success

message.
Step7. Use case end.
Alternative course of action If employee exist or use enter invalid entry.

A1. The system displays error message.

A2. The user will go to Step 5 of Basic course of action.

Post condition The user successfully register new employee.

Table 9: Use case description for register employee

31
 Use Case ID UC8

Use case name Create account

Description Allow the user to create new account.

Actor Admin
Pre-condition The user must have active account and logged in.

Basic course of action Actor System

Step1. The user click on account Step2. The system display target
management link. page.

Step3. The user select add new Step4.The system display create
account. account page
Step4. The user fill the form and Step5. The system display success
click create. message.
Step6. Use case end.

Alternative course of action If the user enter invalid data.

A1. The system displays error message.

A2. The user will go to Step 4 of Basic course of action.

Post condition The user successfully add or create new account.

Table 10: Use case description for create account

32
 Use Case ID UC9
Use case name Block account

Description Allow the user to delete existing account.

Actor Admin
Pre-condition The user must have active account and logged in. In addition, there must
be account to be blocked.
Basic course of action Actor System
Step1. The user click on account Step2. The system display target
management link. page.
Step3. The user select user id and Step4.The system display con
click on block account. formation message.
Step5. The user confirm to block. Step6. The system display success
message.
Step7. Use case end.

Alternative course of action If the user id is not existed data.

A1. The system displays error message.

A2. The user will go to Step 3 of Basic course of action.

Post condition The user successfully block existing account.

Table 11: Use case description for block account

33
 Use Case ID UC9
Use case name Update account

Description Allow the user to update his own account

Actor All
Pre-condition The user must have active account and logged in.
Basic course of action Actor System

Step1. The user click on account Step2. The system display target
setting link. page.

Step3. The user edit previous Step4. The system display success
information and click update. message.

Step5. Use case end.

Alternative course of action If the user enter invalid data.

A1. The system displays error message.

A2. The user will go to Step 3 of Basic course of action.

Post condition The user successfully update account.

Table 12: Use case description for update account

34
 Use Case ID UC10
Use case name Delete employee

Description Allow the user to delete existing employee.

Actor Finance manager
Pre-condition The user must have active account and logged in. In addition, there must
be employee to be blocked.
Basic course of action Actor System

Step1. The user click on employee Step2. The system display target
management link. page.

Step3. The user select user id and Step4.The system display con
click on delete employee. formation message.
Step5. The user confirm deletion.

Step6. The system display success

message.

Step7. Use case end.

Alternative course of action If the employee id is not existed.

A1. The system displays error message.

A2. The user will go to Step 3 of Basic course of action.

Post condition The user successfully delete existing employee.

Table 13: Use case description for delete employee

35
 Use Case ID UC11
Use case name

Update employee
Description Allow the user to update existing employee information.

Actor Finance manager

Pre-condition The user must have active account and logged in. In addition, there must
be employee information to be blocked.
Basic course of action Actor System

Step1. The user click on employee Step2. The system display target
management link. page.
Step3. The user select user id and Step4.The system display con
click on update account. formation message.
Step5. The user confirm updating. Step6. The system display success
message.
Step7. Use case end.

Alternative course of action If the employee id is not existed.

A1. The system displays error message.

A2. The user will go to Step 3 of Basic course of action.

Post condition The user successfully update existing employee information.

Table 14: Use case description for update employee

36
Use Case ID UC12

Use case name Prepare pay slip

Description Allow the user to generate (prepare) pay slip.

Actor Cashier and payroll controller

Pre-condition The user must have active account and logged in. In addition, there must
be payment information to be generated.
Basic course of action Actor System

Step1. The user click on generate Step2. The system display search
pay slip link. bar.

Step3. The user enter id and click Step4.The system

on delete account. display payment
Step5. The user click on generate information.
button.

Step6. The system display success

message.

Step7. Use case end.

Alternative course of action If the user enter invalid id.

A1. The system displays error message.

A2. The user will go to Step 3 of Basic course of action.

Post condition The user successfully generated pay slip.

Table 15: Use case description for prepare pay slip

37
Use Case ID UC13
Use case name Generate report

Description Allow the user to generate report.

Actor Report controller

Pre-condition The user must have active account and logged in. In addition, there must
be report to be generated.
Basic course of action Actor System
Step1. The user click on generate Step2. The system display target
report link. page.
Step3. The user fill information Step4. The system display success
and click on generate button. message.
Step5. Use case end.

Alternative course of action If the filled information is not valid.

A1. The system displays error message.

A2. The user will go to Step 3 of Basic course of action.

Post condition The user successfully generate report.

Table 16: Use case description for generate report

38
 Use Case ID UC14
Use case name Adjust budget

Description Allow the user to delete existing account.

Actor Budget controller
Pre-condition The user must have active account and logged in. In addition, there must
be budget information to be adjusted.
Basic course of action Actor System

Step1. The user click on adjust Step2. The system display target
budget link. page.

Step3. The user fill information Step4.The system display con

and click on adjust. formation message.
Step5. The user confirm adjust.

Step6. The system display success

message.

Step7. Use case end.

Alternative course of action If the user fill invalid information

A1. The system displays error message.

A2. The user will go to Step 3 of Basic course of action.

Post condition The user successfully adjust budget information.

Table 17: Use case description for adjust budget

39
 Use Case ID UC15
Use case name Record commitment

Description Allow the user to record new commitment.

Actor Budget controller.
Pre-condition The user must have active account and logged in.

Basic course of action Actor System

Step1. The user click on record Step2. The system display target
commitment link. page.

Step3. The user fill all information Step4.The system display con
and click on save button. formation message.
Step5. The user confirm save.

Step6. The system display success

message.

Step7. Use case end.

Alternative course of action If the fill invalid information.

A1. The system displays error message.

A2. The user will go to Step 3 of Basic course of action.

Post condition The user successfully record new commitment.

Table 18: Use case description for record commitment

40
 Use Case ID UC16
Use case name Record payment receivable.
Description Allow the user to record payment receivable.
Actor Budget controller

Pre-condition The user must have active account and logged in.

Basic course of action Actor System

Step1. The user click on record Step2. The system display target
payment receivable link. page.

Step3. The user fill all information Step4.The system display con
and click on save button. formation message.
Step5. The user confirm save.

Step6. The system display success

message.

Step7. Use case end.

Alternative course of action If the user fill invalid information.

A1. The system displays error message.

A2. The user will go to Step 3 of Basic course of action.

Post condition The user successfully record payment receivable.

Table 19: Use case description for record payment receivable

41
 Use Case ID UC18
Use case name Send request.

Description Allow the user to send approval request.

Actor Payment controller.
Pre-condition The user must have active account and logged in. In addition, there must
be request to be sent.
Basic course of action Actor System

Step1. The user click on new Step2. The system display target
payment link. page.

Step3. The user fill information, Step4. The system display success
select target user and click send message.
request button.

Step5. Use case end.

Alternative course of action If the user fill invalid information.

A1. The system displays error message.

A2. The user will go to Step 3 of Basic course of action.

Post condition The user successfully send approval request.

Table 20: Use case description for send request

42
 4.1.4 Object model
4.1.4.1 Data Dictionary
A data dictionary is a collection of descriptions of the data objects or items in a data model
for the benefit of programmers and others who need to refer to them.

Field Name Field size Data Type Data Format Description Example
Id Int ----------- Unique 3
identifier for
expenses
Expense 30 Float ----------- Amount of 10 000

Amount expense
Category 15 String ----------- Type of Salary

expense
Account Type 15 String ----------- Type of cash

account
Date 20 Date time dd/mm/yyyy Date of 20/02/2017

expense
Description 100 Text ----------- Detail Paid for
description employees
salary
Table 21: data dictionary for expense table

43
 Field Name Field size Data Type Data Format Description Example
Id Int ----------- Unique 2
identifier
for
income
Income Amount 30 Float ----------- Amount of 10 000

income
Category 15 String ----------- Type of income Salary

Account Type 15 String ----------- Type of Cash

account
Date 20 Date time dd/mm/yyyy Date of income 20/02/2017

description 100 String ----------- Detail Received from

description students id
Table 22: data dictionary for income table

Field Name Field Size Data Type Data Format Description Example
Id Int --------- Unique identifier of 1
employees
First Name 20 String --------- First name of a person Endale

Middle Name 20 String --------- Middle name of a person Aragaw

Last Name 20 String --------- Last name of a person Abebe
Sex 1 Boolean --------- Gender of M

person
Salary 12 Float --------- Salary of an employee 15000
Position 12 String --------- Position of an employee Head

Department 12 String --------- Department of an Finance

department
Table 23data dictionary for employee table
44
 Field Name Field size Data Type Data Format Description Example
Id Int ------ Unique 1
identifier for
report
Type 15 String --------- Type of Monthly expenditure

report
Date 10 Date Time dd/mm/yyyy Date for 11/05/2017

report
generated

Table 24: data dictionary for employee table

Field Name Field size Data Type Data Description Example

Format
Id Int ----- Unique identifier 1
for expense
category
Category Name 15 String ----- Name for Purchasing

expense category

Table 25: data dictionary for expense category table

Field Name Field size Data Type Data Description Example

Format
Id Int ----- Unique identifier 1
for income
category
Category Name 15 String ----- Name for Payment

income category receivable

Table 26: data dictionary for income category table

45
Field Name Field size Data Type Data Description Example

Format
Id Int ----- Unique identifier 1
budget
Department 15 String ----- Name for ICT

Name Department
Amount 15 Float ------ Amount of 10000

budget allocated
Table 27: data dictionary for budget table

Field Name Field size Data Type Data Description Example

Format
Id Int ----- Unique identifier 1
for account
category
Category Name 15 String ----- Name for Cash

account category
Table 28: data dictionary for account type table

Field Name Field size Data Type Data Description Example

Format
Id Int ----- Unique identifier 1
for department
Department 15 String ----- Name of Finance

Name department
Position 15 String ------- Position name Head
Table 29: data dictionary for department table

46
 Field Name Field size Data Type Data Format Description Example

Id Int ----- Unique identifier for 1

directorate
Category 15 String ----- Name of Human
Name resource
directorate

Table 30: Data dictionary for Wing category table

Field Name Field size Data Type Data Format Description Example
Id Int ---------- Unique identifier for 1
commitments

Account type 15 String ---------- Account category Cash

Amount 15 Float ---------- Amount of 20000

commitment
Department 15 String ---------- Name of committed Purchasing

Name department

Date 15 Date Time dd/mm/yyyy Date of 18/09/2017

commitment
Table 31Data dictionary for payment table
Field Name Field size Data Type Data Format Description Example

Id Int ----- Unique for 1

identifier
notice
Description 15 Text ----- Detail description Tomorrow all staff
of the members will have
notice meeting
Type 15 String ------- Type of notice Urgent
Date 15 Date Time dd/mm/yyyy Date of notice 16/06/2017

Table 32Data dictionary for notice table

47
4.1.4.2 Analysis level Class Diagram (Conceptual Modeling)
A class diagram in the Unified Modeling (UML) is a type of static structure diagram that
describes the structure of a system by showing the system's classes, their attributes,
operations (or methods), and the relationships among objects. The class diagram is the main
building block of object-oriented modelling. It is used both for general conceptual modeling
of the systematics of the application, and for detailed modelling translating the models into
programming code. Class diagrams can also be used for data modeling. The classes in a
class diagram represent both the main elements, interactions in the application, and the
classes to be programmed.

48
 4.2 Dynamic model

Employee

id:string
fname:string
mname:string
lname:string
view 1
sex:string
wing_id:int
salary:string
dep_id:int
pos_id:int
add()
update()
delete()
has

Manager Accountant Reporting System Administrator

Budget controller
controller

Add user()
approve request() calculate payroll() generate()
manage() Delete user()
manage employee() calculate expense()
calculate income() 1
1 1 1 1
generate report() manage
manage manage
1 manage *
*
User account
*
*
* Budget * id:string
Notice
fname:string
maintains Transaction id:int Report 1
id:int mname:strikng
modify department:string
type:string id:int lname:string
transactionid:int amount:string
date:date type:string sex:string
type:string
description:text date:date useranme:string
date:date
* description password:string *
post()
modifies() role::string
update() view() active:string
delete() generate()
identify create()
print()
1 update()
Financialinfo * block()
activate()
sectionname:string
managedby:string
identify() Expenditure Income Current balance New balance
view()
id:string id:string id:string id:string
1 amount:float amount:float date:date date:date
catagory:string catagory:string amount:float amount:float
acctype:string acctype:string
amount:float viewapprovedbudget() viewapprovedbudget()
amount:float
date:datetime adjustbudget() adjustbudget()
date:datetime
description:string viewadjjustedbudget() viewadjjustedbudget()
description:string
recordcommitments() recordcommitments()
save() save() viewcommitments() viewcommitments()
edit() edit()
print() print()
view() view()

view

Figure 5: Class diagram

4.2.1 Sequence Diagram

A Sequence diagram is an interaction diagram that shows how objects operate with one another
and in what order. It is a construct of a message sequence chart. A sequence diagram shows object
interactions arranged in time sequence. It depicts the objects and classes involved in the scenario

49
and the sequence of messages exchanged between the objects needed to carry out the functionality
of the scenario.

Login
sequence
All Login Login Login DB
diagram User page
<<actor>> <<link>> <<UI>> <<controller <<server>>
>>

cllick

send

display

fill username and

password and
submit

send validate

error message
valid
check

not authentic ate

error message if authenticate

display

Figure 6: Sequence diagram for login

50
 Sequnce
diagram for <<UI>> <<Controller>>
<<Actor>> <<UI>> <<DB>>
employee Emplyee register Emplyee register
Manager Home page Table
registration form form

click employee initiate to

submenu() employee
register()

display form
fill form and click
register()

send() validate

error message check

duplication

[exist]
error message

[not exist]
success
display message

Figure 7: sequence diagram for employee registration

51
 Sequnce <<UI>>
diagram for <<Actor>> <<UI>> <<Controller>> <<DB>>
Home page
calculate Payment controller Salary form Salary Table
salary

click salary
submenu
initiate to
calculate salary

display search
bar

enter id and click

search
send to
check

[invalid]
error
[valid]
send
check
[not found]
error doesn't exist

[found]
display form show result
fill information
and click
calculate
send
check

[invalid]
[valid]
error message
save

display salary
display result

Table 33: sequence diagram for calculate salary

52
 Sequnce <<UI>>
diagram for <<Actor>> <<UI>> <<Controller>> <<DB>>
Approve request
approval Users Home page Approve request page Table
page
request

click approve
submenu() initiate to
approve request()
check for
existence of
approval
[not found]
display error
message
[found]
display form
check for error
[found]
click on reject
and send
feedback()

[invalid] validate
error message

[valid]
save
display success
message

[not found]
click on approve
()
send()
save

display success
display message

Figure 8: Sequence diagram for approve

53
 Sequence
diagram for <<Actor>> <<UI>>
<<UI>> <<Controller>> <<DB>>
generate Payment controller, Home page
Salary form Salary Table
payslip cashier

click salary
submenu()
initiate to
generate payslip
()

display search
bar

enter id and click

search
send()
check

[invalid]
error
[valid]
send
check
[not found]
error doesn't exist

[found]
display salary show result
information
click on generate
payslip button

send()

display slip
display slip

Figure 9: Sequence diagram for generate pay slip

54
 Sequnce
diagram for <<UI>> <<Controller>>
<<Actor>> <<UI>> <<DB>>
expense Expense register Expense register
Accountant Home page Table
registration form form

click expense initiate to

submenu() expense register
()

fill form and click display form

register()

send()
validate

error message check

duplication

[exist]
error message

[not exist]
success
Display
message

Figure 10: Sequence diagram for expense registration

55
 Sequnce
diagram for <<Actor>> <<UI>> <<UI>> <<Controller>> <<DB>>
income Acountant Home page Income register form Income register form Table
registration

click income
submenu() initiate to income
register()

fill form and click display form

register()

send()
validate

error message check

duplication

[exist]
error message

[not exist]
success
Display
message

Figure 11: Sequence diagram for income registration

56
 Sequnce
diagram for <<Actor>> <<UI>> <<UI>> <<Controller>> <<DB>>
post nitice Manager Home page Post notice form Post notice form Table

click notice
submenu() initiate to post
notice()

display form
select category()

fill for and click

post()
send()
validate

[invalid]
error message [valid]
save()

display succes display succes

Figure 12: Sequence diagram for post notice

57
 Sequnce
diagram for <<Actor>> <<UI>> <<UI>> <<Controller>> <<DB>>
report Report controller Home page report generate form Report generate form Table
generation

click report
submenu() initiate to
generate report()

select category
and click search display form
()
send() send()

[data not found]

error message

[data found]
success
message
display data
select id and fill
description()

send() save()
click generate()

Display success Display success

Figure 13: Sequence diagram for report generation

4.2.2 Activity Diagram

Activity diagram is another important diagram in UML to describe dynamic aspects of the
system. Activity diagram is a flow chart to represent the flow from one activity to another activity.

58
 Login page

User fills username

and password

Click on login button

Invalid
Display error
is input valid?
message

Invalid
Notify wrong
found in database?
cridential

Redirect to his previleged page

Figure 14: Activity diagram for login

59
 Report page

search data
from (db)

false
is found? Display error message
tru
e

Generate report

Figure 15: Activity diagram for generate report

60
 Income page

Fill data

Send data

false
is valid? Display error message
true

Successfully inserted to database

Figure 16: Activity diagram for income register

61
 Expenditure page

Fill data

Send data

false
is valid? Display error message
true

Successfully inserted to database

Figure 17: Activity diagram for expense register

62
 Calculate
salary page

search(empid)
from emp db

false Show Error

is found?
message
true

enter emp information

and click calculate

Check input

false
Show error
is valid
message
true

return success
message

Figure 18: Activity diagram for calculate salary

63
 Approval page

he/she looks for approval

request

Select a request and click Display error

on approve message

is saved to
database?

Display success
message

Redirect him to his

privileged page

Figure 19: Activity diagram for approve request

64
 Employee page

Fill data

Send data

false
is valid? Display error message
true

Successfully inserted to database

Figure 20: Activity diagram for employee register

65
 Salary page

Fill data and

generate

Send data

false
is valid? Display error message
true

Payslip generated

Figure 21: Activity diagram for pay slip

66
 Notice page

Fill data

Send data

false
is valid? Display error message
true

Successfully Notice posted

Figure 22: Activity diagram for post notice

4.2.3 State Diagrams

State diagrams are used to show how objects respond to different service requests and the state
transitions triggered by these requests

67
 login link

onclick
login page

fill and button

clicked

login button activate

no
validity display error message

authentication page

Figure 23: State diagram for login

68
 account update
link

onclick
account update
page

fill and button

clicked

button activate

no
validity display error message

account updated

Figure 24: State diagram for account update

69
 update employee link

onclick
update page
fill and button
clicked

button activate

no
validity display error message

employee updated

Figure 25: State diagram for update employee

70
 employee register
link

onclick
registration page

fill and button

clicked

button activate

no
validity display error message

registered

Figure 26: State diagram for employee register

71
 calculate link

onclick
salary page

fill and button

clicked

button activate

no
validity display error message

calculated

Figure 27: State diagram for calculate salary

72
 post link

onclick
post page

fill and button

clicked

button activate

no
validity display error message

posted

Figure 28: State diagram for post notice

73
 expense register
link

onclick
registration page

fill and button

clicked

button activate

no
validity display error message

registered

Figure 29: State diagram for expense register

74
 income register
link

onclick
registration page

fill and button

clicked

button activate

no
validity display error message

registered

Figure 30: State diagram for income

4.3 ER Diagram
An entity-relationship diagram (ERD) is a graphical representation of an information system that
shows the relationship between people, objects, places, concepts or events within that system.

75
 Lname
Mname
FName
Wingid

Id
Salary
Name
Lname Collegeid
Positionid
Mname
FName
Wingid
Fname Lname
Id
Salary Id Username
Name Employee 1
Name
Positionid Departmentid M
Id
Owns

Account
Password N
Accountant Views
1 1
Manager
Manages
1 1 Type Description
Id
M Manages
Date Date
N
Manages Account_id Generate Notice
Mname
Category_id
Views
Description Type
Date Fname Lname
Amount Id

N
Wingid
Id Report Id Name

Salary
Account_id Manages
N
N Positionid
Income Description 1
Date
Departmentid Collegeid
Account_id Id Fname Lname Administrator
Date
N Ammount
Description Name
Type
N
Category_id Budget Id
Payment
Id
N
Reporter
Amount

N N

Id Expense
Manages Manages
Id Id Fname
Fname Lname
Lname

1 Name
1 Name

Budgetcontroller
Paymentcontroller

Figure 31: ER Diagram

4.3.1 Mapping
It is the process of representing database logic depicted in ER diagrams to a relational schema
form. Meaning logic represented in a diagrammatic form will be translated to table forms.

76
 Employee

ID Fname Mname Lname Sex Wing_id Salary College_id Dep_id Position_id

Wing
ID Name Coll_id Dep_id

College

ID Name Dep_id

Payment

Dep_id ID Payment_category Account_category Amount Date Description

PaymentCategory

ID Name
Budget

ID Dep_id Amount

Department

ID Name Pos_id

Income
Amount
Id Category_id Account_id Date Description

IncomeCategory
ID Name
Expense
Amount
Id Category_id Account_id Date Description

ExpenseCategory
ID Name

AccountCategory ID Name

Report

Description
ID Category_id Date

ReportCategory

ID Name

Notice

Description
ID Category_id Date

NoticeCategory

ID Name

Figure 32: Mapping

77
4.3.2 Normalization
Normalization is a process of organizing the data in database to avoid data redundancy, insertion
anomaly, update anomaly & deletion anomaly.
First normal form (1NF): No composite attribute and no repeated (multi-valued) attribute are
allowed.
Second normal form (2NF): In the 1NF and there exists no partial functional dependency on the
key attribute. In other words, all attributes are dependent on the entire key.
Third normal form (3NF): In the 2NF and there exists no transitive functional dependency.

78
 Table for Employee

Salary
emp_id Fname Mname Lname Sex Wing College Position Department

Table for Wing

Id Name College Department

Table for College

Id Name Department

Table for Department

Id Name Position

Table for Income

Amount Description
Id Category Accounttype Date

Table for Expense

Amount Description
Id Category Accounttype Date

Table for Payment

Category Accounttype
Id Amount Date Description

Table for Report

Id Type Date Description

Table for Budget

Id Department Amount

Table for Notice

Id Type Date Description

Figure 33: First normal form

79
 Table for Employee

Emo_id Fname Mname Lname Sex Salary Emp_id Wingname Department College

Emp_id College Department

Emp_id Department Position

Table for Income

Amount
id Date Description Category_id Name Account_id Name

Table for Expense

Amount
id Date Description Category_id Name Account_id Name

Table for Payment

Amount
id Date Description Category_id Name Account_id Name

Table for Report

id Date Description

Table for Budget

Amount
id Date Description

Table for Wing

id Name Col_id Name Dep_id Name

Table for Department

Id Name Pos_id Name

Figure 34: Second normal form

80
 Table for Employee

Emo_id Fname Mname Lname Sex Salary Wing_id Name college_id Name Dep_id Name Pos_id Name

Table for Wing

id Name Col_id Name Dep_id Name

Table for Department

Id Name Pos_id Name

Table for Income

Amount
id Date Description Category_id Name Account_id Name

Table for Expense

Amount
id Date Description Category_id Name Account_id Name

Table for Payment

Amount
id Date Description Category_id Name Account_id Name

Table for Report

id Date Description

Table for Budget

Amount
id Date Description

Table for Notice

Id Type Date Description

Figure 35: Third normal form

81
 Chapter Five: System Design

5.1. System Overview

This chapter describes the result of design of the system carried out during design phase of Wolkite
University finance management system. The first section describes the desirable design goal that
the system strives to achieve and describing the quality of the system that we shall use optimize
derived from nonfunctional requirements.
The design goal is stated clearly in such a way that making design decisions will be in light of
these goals. The second section which is the most important one describes the system under
development in terms of design trade-offs, system decomposition, system architecture,
deployment diagram, and persistence modeling for object oriented database system and access
control.

5.2. Design Considerations

It should consider:
 Low operating cost: In performing tasks by using the new proposed
integrated FMS the process cost minimized.
 Easy to use: Because of the web application is being developed by making
easy user interactive pages to the user, the web-based system feels easy to
use.
 Easy maintenance: When sometimes failure come to the new proposed
system because the development worked on modules, it is easy to maintain
the system.
 Security: In using such system, the security issue is essential. For the
integrated FMS security is hold by in development and by user
authentication for using the system. In development by layering the overall
development, the system achieves secure system.
 Good response time: The integrated FMS implemented in Asp.net language,
which is ease to readable for all browser, and we use template which have
fast loading time it minimizes response time.
 Portability: In this case, the developed system is platform independent.
Because it run on any device.
82
5.3. Design Goals
The design goals represent the desired qualities that the system should have and provide a
consistent set of criteria that would be taken into consideration when making design decisions.
The following are outlined to be the design goals of Wolkite University financial management
system development.
5.3.1 End user Criteria
Usability is the extent to which specified users to achieve specified goals with effectiveness,
efficiency and satisfaction in a specified context of use can use a product. From the end users’
perspective, the system should be designed in such a way that it is easy to learn and use, efficiently.
5.3.2 Security Criteria
To access the system, the user should have account. The system is highly secured by using User-
Name and Password. Unauthorized access to the system, by any means, should be restricted.
Database security, to prohibit the database from an unauthorized access, should be implemented
using security feature of Microsoft SQL Server. The database should only be accessed through the
system.
5.3.3 Maintenance Criteria
 Modifiability: - The system is modifiable when the organization become large and its
working style changed.
 Readability: - only programmer, which knows programming languages like c #, and others,
easily understands the code of the system. Moreover, by reading information inside
comments of the code the system is easily understood.

83
5.4. Design Trade-offs
5.4.1. Development Cost versus Functionality
FMS provides many functions for users such as Payments, creating users etc. Each function of the
system requires extra design and this causes an extra cost for the development. Without
functionality, the system is nothing so, we focus on functionality rather than development cost.
5.4.2. Understandability versus Efficiency
Understandability of the code is too important especially during the testing phase. Each class and
method must be readable, so number of methods increase in the system and functions must be
implemented in a clear way. Writing comments into the source code increases the
understandability of the code. This causes an additional time taking in the developing phase.
5.4.3. Security versus Availability
In FMS, users must be authorized to connect to the system from web, and unauthorized people
should not be able to access the system. Each user will be able to login to the system by using the
username and password that is assigned by Administrator. And avaliability is the degree to which
a system or component is operational and accessible when required for use. The system can be
available but the system has money transactions so, we focus on the security part a little more than
on availability.

84
5.5. Architecture of the System

Figure 36: System architecture

5.6. System Decomposition

Subsystem decompositions will help reduce the complexity of the system. The sub systems that
we take the classes that our system contain and the operation performed in the class. The following
are sub systems (htt5):
Manage account subsystem: in this sub system, managing of information regard to account and
perform:
 Create account
 Delete account
 Update account
 Activate
Payment management subsystem: in this sub system manage information of payments and
perform:
 Record payment
 Calculate payment
 Update payment
 Handle payment

85
Report management subsystem: This subsystem allows for managing report information and
perform this operation:
 Generate report
 Approve report
 Delete report
 View report
Notice management subsystem: This subsystem allows for managing notice information and
perform this operation:
 Post notice
 View notice
 Delete notice
Budget management subsystem: This subsystem allows for managing budget information and
perform this operation:
 Add new budget
 Approve budget
 Delete budget
 Update budget
Income management subsystem: This subsystem allows for managing income information and
perform this operation:
 Register income
 Delete income
 Update income
 Calculate income
 Generate income
 Print record
Expense management subsystem: This subsystem allows for managing expense information and
perform this operation:
 Register expense
 Delete expense
 Update expense
 Calculate expense

86
  Generate expense
 Print record
Payroll management subsystem: This subsystem allows for managing report information and
perform this operation:
 Search employee salary
 Update salary
 Calculate salary
 Generate pay slip
 Generate report
 Print employee salary
Request management sub system: This subsystem allows for managing report information and
perform this operation:
 Send request
 Approve request
 Reject request
Database Connection Subsystem: this subsystem used for established connection between business
class and database management system.

87
 Manage
Report sub Notice Request
account
system sub sub
sub
system system
system

Generate Approve
report report Send
Post notice
Create request
account
Delete
View report
report View delete Aprove
Update notice request
account

Budget management Delete Reject

sub system notice request
Delete
account

Approve View
Add budget
budget budget

Delete Update
budget budget
Connecti
on sub
system

Payment Expense sub system

sub Database
system connection
Register Delete Update
expense expense expense
Record
payment

Calculate Income sub system

payment

Register Delete Update

Update income income income
payment
Payroll sub system

Handle
payment search emp update calculate Generate
Print salary
salary salary salary report

Figure 37: System decomposition

5.7. Hardware/Software mapping (Deployment)

Hardware/software mapping describes how subsystems are assigned to hardware and off-the-shelf
components. It also lists the issues introduced by multiple nodes and software reuse. Describe
physical connectivity of the hardware and logical connectivity (subsystem associations) (htt6).

88
 Apllication Apllication Apllication
client client client

TCP/IP(logical connectivity) Ethernet(physical connectivity)

LAN

Communication Agent
for Application Client

Global data server

Communication Agent Communication Agent

OODBMS
for Application Client for Application Client

Global data server

Communication
*
Agent
for Application Client
RDBMS

LAN

Local data server Global data server

Figure 38 : Hardware and software physical mapping

Deployment modeling used to show the hardware of the system, the software that is installed in
the hardware and the middleware that is used to connect the different machines to one and other.
It also shows how the software and the hardware components work together.
5.8. Persistent data management
Persistent data management describes the persistent data stored by the system and the data
management infrastructure required for it. This section typically includes the description of data
schemes, the selection of a database, and the description of the encapsulation of the database (htt6).

89
FMS will largely depend on a relational database to perform day-to-day operations and storing log
data. Data will be stored in a MYSQL 2008 DBMS and manipulated through the Database
Subsystem, which will ensure data integrity and consistency. Database Subsystem will contain all
necessary SQL queries that will be accessible by the rest of the Subsystems. The database will be
backed up on a daily basis to ensure data security. The data stored in the database will include:
 Payment information
 Account information
 Income information
 Expense information
 Budget information
 Report information
 Notice information
 Employee information

User account
Account table id:string
Id<<primary key>> fname:string
mname:strikng
First Name lname:string
Middle Name sex:string
useranme:string
Last Name password:string
Sex role::string
active:string
User name
create()
password
update()
Status delete()
block()
activate()

Figure 39: Mapping account table

90
 Employee table class diagram for FMS
Id<<primary key>> Employee
First Name
id:string
Middle Name fname:string
Last Name mname:string
lname:string
Sex sex:string
Salary salary:string
position:string
Position
department:string
Department add()
update()
delete()

Figure 40: Mapping employee table

class diagram for FMS

Income table
Income
Id<<primary key>>
id:string
Income Amount incometype:string
Category<<foriegn key>> incomeamount:float
catagory:string
Account Type
acctype:string
Date date:datetime
Description description:string

save()
edit()
print()
view()

Figure 41: Mapping income table

91
 class diagram for FMS
Expense table
Expense
Id<<primary key>>
id:string
Expense Amount xpensetype:string
Category<<foriegn key>> expenseamount:float
catagory:string
Account Type
acctype:string
Date date:datetime
Description description:string

save()
edit()
print()
view()

Figure 42: Mapping expense table

class for FMS

Report table Report

id:int
Id<<primary key>>
type:string
Type<foreign key>> date:date
description
Date view()
generate()
Description
print()

Figure 43: Mapping report table

class diagram for FMS

Budget table Budget

Id<<primary key>>
Id:int
Department Department Name:string
Amount Amount:int

Figure 44: Mapping budget table

92
 class diagram for FMS

Notice table Notice

Id<<primary key>>
Id:int
Description Description:string
Type<foriegn key> Type:string
Date:date
Date

Figure 45: Mapping Notice table

Figure 46: Database relation for persistent data

93
5.9. User interface design

Figure 47: Login user interface

94
Figure 48: User interface for profile setting

5.10. Object Design

5.10.1. Interface documentation guidelines
Interface is the actions performed by humans using an interactive device, like a keyboard, mouse,
trackball or touch screen, to provide information to or request processing from a computer. It also
includes computer responses (including display panels) because of information/requests from the
user.
Interface development methodology: The major components of the methodology, which are
applied throughout the six phases of the UI process, are:
1. Management: our management has three components.
95
 a) UI design team
b) Usability plan
c) Configuration control
2. Requirement analysis and definition
3. Design and implementation
4. Test

5.10.2. Class interfaces

Class

Employee

id:string
fname:string
mname:string
lname:string
sex:string
wing:string
salary:string
college:string
position:string
department:string
add()
update()
delete()

Figure 49: Employee class

Invariant

 Data should be entered from keyboard

 Employee information should be valid

Methods:
a) Add()
Precondition: Employee should be hired by the organization.
Post: The manager register employees.
b) Update()

96
Pre: Employee data should be exist.
Post: The manager update employee information.
c) Delete()

Pre: Employee data should be exist.

Post: The manager delete employee information.

97
References
(n.d.). Retrieved from http://www.utdallas.edu/~chung/SP/SystemDesignDocumentTemplate.htm
(n.d.). Retrieved from http://www.utdallas.edu/~chung/SP/SystemDesignDocumentTemplate.htm
(n.d.). Retrieved from http://sydney.edu.au/engineering/it/courses/info5210/chap09.pdf
(n.d.). Retrieved from http://sydney.edu.au/engineering/it/courses/info5210/chap09.pdf

98