HARAMAYA UNIVERSITY

College of Computing and Informatics

Department of Information Systems

Project Report

<Haramaya university human resource management system>

Name ID
1. Helina Embibel 614/08
2 Munteha Shafi 633/08
3 Emebet Kebede 1402/07
4 Dureti Mohamed Shafi 592/08

Adviser

<Belen Y. and Yishak G. >

Supervisor Affiliation

<2019>
 HARAMAYA UNIVERSITY
College of Computing and Informatics

Department of Information Systems

CERTIFICATE

This is to certify that the work embodies in this project entitled

“______________________________________________________” being
submitted by following students for partial fulfillment of the requirement to
“Haramaya University” during the academic year 2017-18 is a record of
bonafide piece of work, carried out by them under my supervision and
guidance in the “Department of Information Systems”, College of
Computing and Informatics.

1. Helina Embibel 614/08

2 Munteha Shafi 633/08
3 Emebet Kebede 1402/07
4 Dureti Mohamed Shafi 592/08

ADVISER BY: CO ADVISER BY:

Miss Belen Y. Mr. Yishak G.

(Lecturer….) (Lecturer….)

HEAD OF DEPARTMENT

Mr. Beyene B.
(Lecturer….)

II
 HARAMAYA UNIVERSITY
College of Computing and Informatics

Department of Information Systems

CERTIFICATE OF APPROVAL

The project report entitled “_________________________” being submitted

by following students has been examined by me/us and is hereby approved
for project work which it has been submitted. It is understood that by this
approval the undersigned do not necessarily endorse or approve any
statement made, opinion expressed or conclusion drawn therein, but
approve the project report only for the purpose for which it has been
submitted.

1. Helina Embibel 614/08

2 Munteha Shafi 633/08
3 Emebet Kebede 1402/07
4 Dureti Mohamed Shafi 592/08

APPROVED & ADVISER/ CO ADVISER BY:

Miss Belen Y. Mr. Yishak G.

(Lecturer….) (Lecturer….)

DATE:

III
Acknowledgment

Firstly, we are greatly indebted to the following for their contribution to our project: The Almighty
God, who gave us the insight and perseverance to accomplish this project. Our Advisor Miss Belen
Yitages and co adviser Mr. Yishak Gebeyehu their sounding advice helped us guide this project in
the right direction, in which they can enforce us to have a massive knowledge about the project to
easily familiarize with the concept of project development.
Secondly, we would like to thank Haramaya University HRMS personnel officer and the
department officers especially Ato. Desta Reta and for him willingness on interview, patience in
answering to our numerous questions, giving existing activity materials and reading materials that
help us to precede our project.

Lastly, we would like to thank Haramaya University College of computing and informatics
department of information system for giving us such a great opportunity to explore and dig about
different knowledge related to our fields.

IV
Contents
CERTIFICATE .......................................................................................................................................... II
CERTIFICATE OF APPROVAL ................................................................................................................. III
Acknowledgment ......................................................................................................................................... IV
List of tables.................................................................................................................................................. X
Keywords/Acronyms ................................................................................................................................... XI
Abstract...................................................................................................................................................... XII
CHAPTER ONE ......................................................................................................................................... 1
1 Introduction .............................................................................................................................................. 1
1.1 Background of the organization .......................................................................................................... 1
1.2. Statement of the problem .................................................................................................................... 2
1.3 Objectives........................................................................................................................................... 2
1.3.1 General Objective ............................................................................................................................ 2
1.3.2 Specific Objective ............................................................................................................................ 2
1.4 Methodology .......................................................................................................................................... 3
1.4.1 Data Collection Methodology .......................................................................................................... 3
1.4.2 System Development Methodology ................................................................................................. 4
1.4.3 System Development Tool ............................................................................................................... 5
1.5 Scope of the study and limitation......................................................................................................... 5
1.6 Significance of the project .................................................................................................................... 6
1.6.1 Benefits for the human resource office ............................................................................................ 6
1.6.2 Benefits for the applicant ................................................................................................................. 6
1.6.3 Benefits for the Department ............................................................................................................. 6
1.7 Feasibility Assessment .......................................................................................................................... 6
1.7.1 Economic Feasibility ....................................................................................................................... 6
1.7.2 Technical Feasibility ........................................................................................................................ 8
1.7.3 Operational Feasibility ..................................................................................................................... 8
1.7.4 Schedule Feasibility ......................................................................................................................... 8
1.8 Management Issues ............................................................................................................................... 9
1.8.1 Team configuration and management .............................................................................................. 9
1.9 Communication plan .......................................................................................................................... 10
1.10 Change management ........................................................................................................................ 10
CHAPTER TWO ...................................................................................................................................... 11

V
2 System analysis ....................................................................................................................................... 11
2.1. Introduction ...................................................................................................................................... 11
2.2. current system description ................................................................................................................ 11
2.2.1. Player of the existing system .................................................................................................... 11
2.2.2. Work Flow of the Existing System ........................................................................................... 12
2.3. Proposed system ................................................................................................................................. 12
2.3.1 Expected Advantages of the proposed system ............................................................................... 12
2.4 Functional requirements .................................................................................................................... 13
2.5 System Requirement Specification and Analysis modeling (SRS).................................................. 13
2.5.1 CRC (class responsibility collaboration) ....................................................................................... 13
2.5.1.1 CRC diagram for actor class ................................................................................................... 13
2.5.1.2 CRC diagram for UI class ....................................................................................................... 15
2.5.1.3 CRC diagram for Business class ............................................................................................. 16
2.6 use case modeling ................................................................................................................................ 17
2.6.1 Essential use case modeling ........................................................................................................... 17
2.6.2 Essential use case description ........................................................................................................ 18
2.6.3 System use case modeling.............................................................................................................. 23
2.6.4 System use case description ........................................................................................................... 25
2.6.5 Features .......................................................................................................................................... 33
2.7 User interface prototyping ................................................................................................................. 33
2.7.1 Traditional User-Interface Prototyping .......................................................................................... 33
2.7.2 User-Interface Flow Diagramming ................................................................................................ 35
2.8 Supplementary specification .............................................................................................................. 36
2.8.1 Business rules................................................................................................................................. 36
2.8.2 Nonfunctional requirements ........................................................................................................... 36
2.8.3 Constraints ..................................................................................................................................... 37
CHAPTER THREE .................................................................................................................................. 38
3 Design Document ................................................................................................................................... 38
3.1 class modeling ...................................................................................................................................... 38
3.1.1 Class layered approach .................................................................................................................. 38
3.1.2 class diagram.................................................................................................................................. 39
3.2 Sequence diagram ............................................................................................................................... 41
3.3 Activity diagram.................................................................................................................................. 46

VI
3.4 User Interface Design ......................................................................................................................... 49
3.4.1 Form Design................................................................................................................................... 49
3.4.2 Report Design ................................................................................................................................ 51
3.4.3 Dialogue and Interface Design ....................................................................................................... 52
3.5 State chart diagram ............................................................................................................................ 53
3.6 Object diagram.................................................................................................................................... 56
3.7 Persistent Modeling/ Database Design .............................................................................................. 57
3.7.1 Normalized database ...................................................................................................................... 57
3.7.2 Normalized Physical database model ............................................................................................ 58
3.8 Component diagram ........................................................................................................................... 59
3.9 Deployment diagram .......................................................................................................................... 60
3.10 Current software architecture ......................................................................................................... 61
3.11 Proposed software architecture ....................................................................................................... 61
References ................................................................................................................................................... 63
Appendix I ................................................................................................................................................. 64

VII
List of figures

Figure 1 waterfall methodology .................................................................................................................... 4

Figure 2 CRC for applicant ......................................................................................................................... 14
Figure 3 CRC for HR manager ................................................................................................................... 14
Figure 4 CRC for department dean ............................................................................................................. 14
Figure 5 CRC User Interface class for login form ...................................................................................... 15
Figure 6 CRC User Interface class for applicant signup ............................................................................. 15
Figure 7 CRC User Interface class for post vacancy .................................................................................. 16
Figure 8 CRC business class for scheduling ............................................................................................... 16
Figure 9 CRC business class for requirement ............................................................................................. 16
Figure 10 Essential use case diagram ......................................................................................................... 17
Figure 11 System use case diagram ............................................................................................................ 24
Figure 12 User interface prototype Login form .......................................................................................... 33
Figure 13 User interface prototype registration form ................................................................................. 34
Figure 14 user interface prototype for post vacancy form .......................................................................... 34
Figure 15 User interface flow diagram ....................................................................................................... 35
Figure 16 class layered approach ................................................................................................................ 39
Figure 17 class diagram for HRMS ............................................................................................................ 40
Figure 18 sequence diagram for login......................................................................................................... 41
Figure 19 sequence diagram for post announcement .................................................................................. 42
Figure 20 sequence diagram for view and register ..................................................................................... 43
Figure 21 sequence diagram for send requirement ..................................................................................... 44
Figure 22 sequence diagram for screen....................................................................................................... 45
Figure 23 activity diagrams for login .......................................................................................................... 46
Figure 24 activity diagrams for post announcement ................................................................................... 47
Figure 25 activity diagrams for screening................................................................................................... 47
Figure 26 activity diagrams for Send requirement...................................................................................... 48
Figure 27 activity diagrams for view and apply ......................................................................................... 48
Figure 28 User interface design for login ................................................................................................... 49
Figure 29 User Interface Design for apply.................................................................................................. 50
Figure 30 user interface design for report design........................................................................................ 51
Figure 31 User Interface Design for Dialogue and Interface Design .......................................................... 52
Figure 32 state chart diagram for login ....................................................................................................... 53

VIII
Figure 33 state chart diagram for send requirement.................................................................................... 54
Figure 34 state chart diagram for post announcement ................................................................................ 54
Figure 35 state chart diagram for view and apply ....................................................................................... 55
Figure 36 state chart diagram for screen .................................................................................................... 55
Figure 37 Object diagram for HRM ............................................................................................................ 56
Figure 38 Persistent diagram....................................................................................................................... 58
Figure 39 Component diagram ................................................................................................................... 59
Figure 40 Deployment diagram for HRMS ................................................................................................ 60
Figure 41 proposed software architecture ................................................................................................... 62

IX
List of tables
Table 1 system development tool.................................................................................................................. 5
Table 2 Miscellanies Costs ........................................................................................................................... 7
Table 3 Software Development Costs ........................................................................................................... 7
Table 4 Time schedule for our Project .......................................................................................................... 9
Table 5 Team configuration and task assigning. ........................................................................................... 9
Table 6 communication plan ....................................................................................................................... 10
Table 7 Essential use case description for attaching vacancy paper ........................................................... 18
Table 8 Essential use case description for requirement collection.............................................................. 18
Table 9 Essential use case description for screening information .............................................................. 19
Table 10 Essential use case description for attach result and interview date .............................................. 19
Table 11 Essential use case description for send information. ................................................................... 20
Table 12 Essential use case description for apply....................................................................................... 20
Table 13 Essential use case description for view attached vacancy. .......................................................... 21
Table 14 Essential use case description for view attached result and interview dates. ............................... 21
Table 15 Essential use case description for sending recruitment for collage dean. .................................... 22
Table 16 Essential use case description for receive applicants result ......................................................... 22
Table 17 system use case description for login........................................................................................... 25
Table 18 system use case description for ask requirement. ....................................................................... 26
Table 19 system use case description for post vacancy. ............................................................................. 27
Table 20 system use case description for view report................................................................................. 28
Table 21 system use case description for send message. ........................................................................... 28
Table 22 system use case description for post result and interview date. .................................................. 29
Table 23 system use case description for screen information. .................................................................... 30
Table 24 system use case description for screen information. ................................................................... 31
Table 25 system use case description for register. ...................................................................................... 32

X
Keywords/Acronyms

HU Haramaya University
CGPA Cumulative Grade Point Average
UML Unified Modelling Language
DB Database
ID Identification
UC Use Case
HTML Hypertext Markup Language
SQL Structure Query Language
PHP Hypertext Pre-processor
INFO Information
App _ID Applicant Identification
EMP_ID Employee Identification
HR_ID Human Resource Admin Identification
CSS Cascading Style Sheet
HTTP Hypertext Transfer Protocol
CRC Class Responsibility Collaboration
BR Business rule
LAN Local Area Network
WAN Wide Area Network
ADMIN Administrator
HRMS Human Resource Management system
MS Microsoft
UI User Interface

XI
Abstract

This system document is prepared for employee requirement management system of HU and
concerned with the description of the existing Human Resource management system and different
types of models used to model the new system under study. Web based human resource
management system mainly provides effective and fast data processing and controlling of
personnel. This web-based system of managing human resource in our University setting is
expected to help various services keep an updated data on the status of their employee personal
information. In designing such a system, PHP has been engaged as a development language and
MySQL as a backend database with CSS implemented for the interface. Generally, the main goal
of online human resource management system is to shorten data-processing time, to reduce errors,
to improve the accuracy of input and to provide data reliability of the personnel.

XII
 CHAPTER ONE

1 Introduction
In this world of growing technologies everything has been computerized. With large number of
works opportunities the Human workforce has increased. Thus, there is a need of a system which
can handle the data of such a large number of Employees. The aim of this project is to develop a
web-based system for HU human resource management. While HU was established the office of
HRM was also established and for this long period of time the offices process data manually. The
manual processing system has many problems. In order to solve this issue; we are going to develop
a web based human resource management system. The project that is going to be completed will
solve the problems that had affected the human resource management offices. Since it is online it
reduces a lot of costs, time to travel to the offices, work over load and it minimizes the space used
to store the data. Online human resource management system enables to register applicants online,
hiring employees, requirement collection from all collages, different report generation and other
different functionalities.

1.1 Background of the organization

Haramaya University is one of the most prominent and prestigious universities in Ethiopia. The
University has educated a number of individuals who have contributed to the improvement and
development of the world. The University has been the knowledge pool for many other
intellectuals, who have made their mission helping human kind and improving our earth.
Haramaya University, formerly known as Alemaya University, was established with the initiative
of Emperor Haile Selassie in 1954 based on the need for modernizing Ethiopian agriculture in
particular and education in general through the establishment of an agricultural college and
training. It was based on the emperor’s wish that the college is founded at its current location. Up
until 1963, Oklahoma State University was given the mandate to establish and operate the college.
In the past few years the university has witnessed tremendous expansion in terms of fields of study
and facilities [1].

1
 1.2. Statement of the problem

Different problems that seem easy but difficult for the HRM workers and customers initiated us
to do the system. The problems are: -

❖ Consuming of time for the simple and easy jobs.

❖ Since there are a lot of employee documents in the office it’s hard to manage such
huge data manually.
❖ Security issue in different human resource essential data.
❖ The use of paper work in handling some of the processes could lead to human error, papers
may end up in the wrong hands and not forgetting the fact that this is time consuming.
❖ The ups and downs and time consumption of customers while medical checkup and other
checkups process for different purpose.
❖ Loss of up to date information like vacancy, interview date, results and other information.

1.3 Objectives
1.3.1 General Objective
The general objective of the project is to develop a web based human resource management
system for Haramaya university.

1.3.2 Specific Objective

The specific objective of this project is listed below

❖ To develop an HRM system that facilitates fast report generation.

❖ To develop an HRM system that enables users to apply the forms online.
❖ To develop an HRM system that makes retrieval of data efficient.
❖ To develop a system with a great security.
❖ To Increase to the work efficiency of the office which is the problem of the manual
system.

2
1.4 Methodology
1.4.1 Data Collection Methodology
We have used interview, direct observation and document analysis in order to determine the
information, which is used in the existing system and its very important to develop the proposed
system.

A. Interview

we have gathered information by interviewing the HRMS officers about the existing system. We
have asked some necessary questions to the human resource management directorate to get the
necessary information about the existing system.

B. Practical observation

This method helped us to test if what they were talking in the interview was correct or not. Plus, it
helped us to get real information how the organization performs its function and this helps to
strength the data that gathered through interview and document analysis.

C. Document analysis

This technique provided us information on how the existing system works. Documents related to
the existing system of the organization are accessed by this technique.

3
1.4.2 System Development Methodology

As a system development methodology, we used Waterfall model because

• Water fall is the simplest process model.

• Phases are organized in a linear order, and every next phase starts upon completion of
previous phase. The phases are i.e. Requirement Analysis, Design, coding, testing,
installation, and operation & maintenance.

• Documentation is produced and checked at each phase and that it fits with other engineering
process models and that makes easy to manipulate [2].

Changed
Requirements
Communicated
Requirements

Requirements
Requirements Specification
Engineering

Design
Design Specification

Executable
Software
Programming Maintenance
Modules

Integrated
Software
Integration Product

Delivered
Software
Delivery Product

Figure 1 waterfall methodology

4
1.4.3 System Development Tool

Table 1 system development tool

Activities Tools
Documentation, code editor MS word 2010, notepad++
Design Edraw Max 8.6 for UML standard design
Programming languages PHP, JavaScript, CSS, HTML
Web server Apache Xampp server v3.2.2
Data base Server My sql database

1.5 Scope of the study and limitation

The system we are proposing is mainly focused on HU HRM and the system will include the
following features

❖ Announcement process: - The system will announce the vacancy, interview date and
results to the applicant.
❖ Online Registration of Applicants: -The system registers all the applicant
information that is used to hire in the institution.
❖ Requirement collection from dean of all collages: - The system collects
information from dean of collages for different purposes.
❖ Official joining process, document verification, medical checkup and other
checkups: - The system can take those documents.
❖ Official requirement
❖ Screening for application: - The system validates the applied documents according to
different standards.
❖ Clearance, certificate, promotion letter: The applicant can attach those documents if
any.
❖ Expatriate contract

5
 Limitation

• The system will not support multi languages. This is because of lack of time.
• Our system will not include the leave employee functionality, this is also because of lack
of time.

1.6 Significance of the project

The proposed system has a lot of significance for different departments that include

1.6.1 Benefits for the human resource office

❖ Avoiding improper resource consumption like paper, pen…
❖ Avoiding data loss because of improper data storage.
❖ Reducing work over load of the office.
❖ Produce Simple process for posting job vacancy
❖ Handling the applicants effectively and support the smooth functioning of the
business.
1.6.2 Benefits for the applicant
❖ Simple access anywhere and anytime to access services whenever there is internet access.
❖ Simplified process for registering online
❖ Can view posted information’s from anywhere at any time
1.6.3 Benefits for the Department
❖ Facilitates fast and efficient retrieval of data
❖ Avoiding improper resource consumption like paper, pen, ledger…
❖ Reduced workload of the office activities such as preparation of reports
❖ Simplified process for managing employee information

1.7 Feasibility Assessment

1.7.1 Economic Feasibility
We used this method for comparing the cost with the benefit or income that is expected from
developed system.
The system to be developed is economically feasible and the benefit is outweighing the cost. Since
this project will computerizes the existing system, the reduction of cost for materials used in
manual operation will become beneficiary to the organization.

6
Cost of the Project
Tangible Costs
The tangible costs acquired in developing the system are: -
❖ Miscellaneous Cost which includes hardware development cost and other costs.
❖ Software development cost
a. Miscellaneous Cost

This cost contains the various types of costs in which we spent for the development of the
project or the University covers some of the hardware expenses.
The following table lists the different miscellanies costs that we have spent in the process of the
development of the system.

Table 2 Miscellanies Costs

Resources Amount Price

Pen 3 pens 15 Birr
Printing 120 pages 100 Birr
Paper ¼ DESTA 22 Birr and 50 cents
Total 137 Birr and 50 cents

b. Software Development Cost

For this particular project we had used different software but the software is provided by the

university.

Table 3 Software Development Costs

Type of Software’s Price

Microsoft windows 7/8/XP Free down load
Microsoft Office Free down load
MySQL from Xampp Free down load
Visual Paradigm for UML 11.0/Microsoft Visio /Rational Free download
Notepad++ Free download
Rose
Total 0.00 Birr
7
Intangible Cost
Is a cost which is uncountable. The intangible cost that is acquired in developing the system
is Our knowledge that we spent to develop the system may not be measurable in terms of money.

1.7.2 Technical Feasibility

The team members have technical knowledge about:
❖ PHP to write the code or implementation with XAMPP.
❖ MySQL to build the database to store the data.
❖ Unified Modelling Language (UML) model to do analyzing and designing in good
manner.

The technical requirement for the human resource management system in order to do their
operation by the new computerized system is:

❖ Training on the new system to know how it operates and how to use the
computerized system.

1.7.3 Operational Feasibility

The system to be developed will provide accurate, active, secured service and decreases labor of
workers and also it is not limited to particular groups or body. The system will easily operational,
as it doesn’t affect the existing organizational structure. So, the system will be operationally
feasible.

1.7.4 Schedule Feasibility

Within the time gap, we have classified the activities of the project in order to accomplish the
project objective within the given time as shown in the table below.

8
Table 4 Time schedule for our Project

1.8 Management Issues

1.8.1 Team configuration and management
This technique is used for managing the project team for effective team performance. The team
configuration refers to the members of the team which is determined by the active and passive
languages of the meeting and participation of the group often referred to as managing strength,
team configuration in the narrow sense refers to the team strength that is the number of interpreters
required for a given team depending on the language used. There exist four team members who
participated in this project.

Table 5 Team configuration and task assigning.

GROUP MEMBERS TASKS

Helina Embibel Project manager
Muntha Shafi and Helina Embibel System building and testing
Emebet Kebede and Helina Embibel System designer
Dureti Mohamedshafi System analyst

9
1.9 Communication plan
While developing software or doing projects in group it is common to have a group norm and
agreements which will lead the group to the successful accomplishment of the project. Based on
the schedule suggested by the department together with our schedule we will contact our advisor
in every phase and take correction and guideline for our project.

Table 6 communication plan

Date Time Techniques

Member with Monday, Wednesday At 1 o’clock at night phone
members and weekends. fb and f2f
Members with When we finish one Morning or afternoon email, f2f
Advisors chapter.

1.10 Change management

It includes identifying, assessing and managing the risks and day-to-day changes that occur during
a project. If there is change occurs during the project development mainly the project manager will
take care of the changes.

10
 CHAPTER TWO

2 System analysis
2.1. Introduction
In this chapter the existing system of HU HRMS was clearly defined by answering how
existing system is working? In what way the employee managed? What are techniques being used
to handle personnel file? What are the business rules of the existing system? And what are the
problems in the existing system? After studying the existing system, it is possible to understand
that how the proposed system can solve the existing system problems. Studying the existing system
will also use to determine both functional and non-functional requirements.

2.2. current system description

The existing human resource management system performs the following function with manual
system and this leads to less security issues. Because of the manual system recording system is
time consuming and boring. This is the result of lack of computerized system or web-based system.

2.2.1. Player of the existing system

HRM director - is a person who is in charge of controlling and following up all the employees’
Activities and departmental communications using acceptable and approved documents.
Staff workers: -are those employee works in HRMS office.
Section/Department: - A business unit in which all employees are included.
Applicants: -they are person who find job.
Employees: -they are person who works in the institution (could be lecturers, accountants,
technicians)

11
2.2.2. Work Flow of the Existing System

The work flow in the existing system is starting from the human resource manager to send
request to every department to check if there any employee they want to hire and the department
head gives the response Then, human resource directorate posts the paper of vacant position and
hired employee and the interview dates and other information in the board after screening the
applicants document from the standards given from each department. After hiring the employee
then send the hired employee data to that of departments who require the employee in letter form.
And the applicant departments accept the employee and place them to their tasks. If the employee
gets training, done projects the departments update the new information of the employee in manual
or paper-based system. As we see the existing system all activity is done from the human resource
office to every departments in the institution are manual base system.

2.3. Proposed system

The proposed system is designed to eliminate all the drawbacks of the existing human resource
management system. The system shall be responsible for posting announcement, hiring new
employees, screening the applicants document, and managing information about employees to
their personal profile. It also contains a report generation system. All these and some extra features
include are included in the proposed system.

2.3.1 Expected Advantages of the proposed system

The system has provided

➢ Security: since the system requires verification of logon form, sensitive information’s will
not be accessed or modified by unauthorized users.
➢ Efficient way of employee’s data management: -Since the system uses database system
there is no loose of data. The employee information is highly secured, the search and update
of employee is simple.
➢ Give online information registration: -The system gives online information about vacant
position for the applicant from the institution, so to know the criteria that must be full fill
to register and also can register online at a time.
➢ Give’s Notification information: -the system gives notification through posting in the
website and email notifications

12
2.4 Functional requirements
Functional Requirements are those that refer to the functionality of the system, i.e., what services
it will provide to the user. Statements of services the system should provide how the system should
react to particular inputs and how the system should behave in particular situations.

➢ Posting announcements: the system post vacancy announcements, interview dates and
other notices for the applicants in order to make them informed.
➢ Register applicant online: The system registers applicants’ who wants to be hired in the
institution with appropriate information. Without coming to the office, they can be able to
register online by using the system.
➢ Placing new employee: the system is able to recorded the new employed applicants and
able to place to their respected position.
➢ Manage employee information: The system is able to add, delete and update the hired
employee information when it is needed. And also, the department can assign project team
for every employee in his department.
➢ Message: The system is can able to communicate the users.
➢ Report generation
o Report generation- the system is able to generate a report for each employee based
on the information in the database.
➢ Attachments of different certificate: The system allows the applicant to scan and attach
different certificate like medical checkups and other.

2.5 System Requirement Specification and Analysis modeling (SRS)

2.5.1 CRC (class responsibility collaboration)

2.5.1.1 CRC diagram for actor class

13
 Applicant<<Actor
Applicant<<Actor
class>>
class>>

Register
Register Registration <<UI>>
Registration <<UI>>
Apply LoginLogin
<<UI>> <<UI>>
Apply Applicant page<<UI>>
View View<<UI>>
View Apply<<UI>>

Figure 2 CRC for applicant

HR manager <<Actor class>>

Create <<UI>>
Post Update<<UI>>
View Screen <<UI>>
Manage account Post <<UI>>
Screening

Figure 3 CRC for HR manager

Department dean<<Actor class>>

Edit profile
Department dean page<<UI>>
Generate report
Send information

Figure 4 CRC for department dean

14
2.5.1.2 CRC diagram for UI class
It accepts input from users, retrieve business objects, enable users to manipulate the business
objects, support creation, update, deletion, and saving of business objects into the system.

Login Form<<UI>>

User name Administrator page

password Applicant page

Department dean page

Figure 5 CRC User Interface class for login form

Applicant signup<<UI>>

Name of applicant
address
CGPA
Marital status Applicant <<UI>>
Age
Gender

Figure 6 CRC User Interface class for applicant signup

Post vacancy<<UI>>

Education level
Type of position
Salary
Department Post announcement <<UI>>
End date

Term of employee

15
 Figure 7 CRC User Interface class for post vacancy

2.5.1.3 CRC diagram for Business class

Scheduling << Business class >>

Job number
Practice exam time
Interview exam date
Place Post announcement<<UI>>
date
interview time

Figure 8 CRC business class for scheduling

Recruitment << Business class >>

Recruitment number
Type of position
Education level
Quantity Department page<<UI>>

Sex
Term of employee

Figure 9 CRC business class for requirement

16
2.6 use case modeling
2.6.1 Essential use case modeling

Figure 10 Essential use case diagram

17
2.6.2 Essential use case description
Table 7 Essential use case description for attaching vacancy paper

Actor: HR manager

Description: Attaching vacancy paper

Precondition: collecting the requirement for the vacancy

Post condition: Displaying the vacancy for the applicants

Basic course of action 1collecting the recruitment needed from

college dean.

2 preparing the required information for the

applicants.

3 Attaching the vacancy paper.

Alternative course of action 4A If the manager didn’t get the required

information.

4B the system goes to 1

Table 8 Essential use case description for requirement collection

Actor: HR manager
Description: Getting information from the collage dean
Precondition: Contacting the dean and ask the information available
Post condition: Getting the required data
Basic course of action 1 contacting the college dean
2 Ask the information needed for hiring the
applicants.
3 Getting the required data

Alternative course of action 4A If the manager didn’t contact the dean

18
 4B the system goes to 1

Table 9 Essential use case description for screening information

Actor: HR manager

Description: screening the applicant’s information

Precondition: the applicants needs to apply

Post condition: screening the information of applicants before posting.

Basic course of action 1 the applicants apply for the job according to
the posted vacancy.

2 HR manager validates the information of the

applicants according to the information
collected from the collage dean.

Alternative course of action 3A If there is no applicant information

3B the system goes to 1

Table 10 Essential use case description for attach result and interview date

Actor: HR manager
Description: Attaching the result and interview dates
Precondition: should have the screened information of applicants
Post condition: attaching the paper with results and interview dates.
Basic course of action 1 HR manager validate or screen the data of the
applicants
2 HR manager prepares the applicant data who
are qualified to be hired
3 the HR manager attaches the result and
interview dates.

19
 Alternative course of action 4A If the applicant is not qualified

4B the system goes to 1

Table 11 Essential use case description for send information.

Actor: HR manager

Description: sending results to the dean of collage

Precondition: having the results of the applicant

Post condition: the collage dean gets the result of hired applicants.

Basic course of action 1 the HR manager finishes screening the

applicant’s data.

2 the HR manager sends the applicants

information to the collage dean

Alternative course of action 3A If there is no qualified applicant

3B the system goes to 2

Table 12 Essential use case description for apply

Actor: Applicant

Description: Appling for job

Precondition: they should qualify the required format

Post condition: to be qualified for that place.

Basic course of action 1 the applicant views the attached vacancy

2 the applicant goes to the HR manager and fill

the required form.

20
 3 the applicant gives the paper that is filled to
the HR manager.

Table 13 Essential use case description for view attached vacancy.

Actor: Applicant

Description: view the attached vacancy paper.

Precondition: the HR manager should post

Post condition: the applicant gets the information displayed.

Basic course of action 1 the applicant goes to the board where the
paper is attached.

2 the applicant will see if there is a vacancy

paper attached by his filled of study.

Table 14 Essential use case description for view attached result and interview dates.

Actor: Applicant

Description: view the attached results and interview dates.

Precondition: the HR manager should evaluate and post

Post condition: the applicant will know whether he is qualified for the place or not.

Basic course of action 1 the applicant goes to the board where the
paper is attached.

2 the applicant will see on the attached paper

whether he is qualified for that place or not.

21
Table 15 Essential use case description for sending recruitment for collage dean.

Actor: Department dean

Description: sending requirement needed to the HR manager

Precondition: the HR manager asks to give collage dean the recruitment needed.

Post condition: the HR manager will get the information.

Basic course of action 1 the HR manager asks the collage dean to send
him the information needed.

2 the collage dean sends the required

information to the dean by a letter.

Table 16 Essential use case description for receive applicants result

Actor: Department dean

Description: receiving the results of the applicant

Precondition: the HR manager should have the results

Post condition: the collage dean will receive the results.

Basic course of action 1 the HR manager finishes screening the

applicant’s information.

2 the HR manager will send the results by letter

3 the collage dean will receive the results.

22
2.6.3 System use case modeling

A use case defines a goal-oriented set of interactions between external users and the system
under consideration or development. Thus, a Use Case Scenario is a description that illustrates,
step by step, how a user is intending to use a system, essentially capturing the system behavior
from the user's point of view [3].
In order to create relevant use cases for the system, the following actors for the system have been
identified:

❖ applicant
❖ Department officer
❖ Human Resource Admin

23
 Figure 11 System use case diagram

24
2.6.4 System use case description
Table 17 system use case description for login

Usecase name: Login

UC_ID: UC_01
Actor: HR manager, collage dean, applicant

Description: this use case is used to ensure security while logging into the system
Precondition: the user must have correct username and password.

Post condition: the main page will be displayed then user gets access to their privilege and after
finishing their work they can logout.
Basic course of action
1. User wants to login into the system
2. User has to open the system.
3. The System displays the login interface and
allows the user for the user enter name and
password.
4. User fills his or her username and password.
5. the user clicks on login button.
6. the system displays “login successfully” message.
7. Use case ends.

Alternative course of action If the user is not authorized

A.6 the system gives a confirmation message that is

wrong username or password.
A.7 The system returns to step 3.
A.8 Usecase ends.

25
Table 18 system use case description for ask requirement.

Usecase name: ask requirement

UC_ID: UC_02
Actor: HR manager

Description: the HR manager will ask the dean to give him the requirement needed to perform his
task.
Precondition: the manager must login to the system.

Post condition: the manager will send the message for the dean to send the information needed
Basic course of action 1. HR manager wants to ask requisition or requirement.
2. HR manager has to open the system.
3. The System displays the login interface and allows
him to enter name and password.
4. by selecting account type he fills his username and
password.
5. He clicks on login button.
6. the system displays “login successfully” message.
7. he will write the message and clicks on send button.
8. the system displays “message sent successfully”
message.
9. Use case ends.

Alternative course of action

26
Table 19 system use case description for post vacancy.

Usecase name: post vacancy

UC_ID: UC_03
Actor: HR manager

Description: After HR manager asks the employment requisition the HR manager should be posted
vacancy announcement to the users.
Precondition: the manager should have the requirements to be posted.

Post condition: Record is successfully added to the database message should be display to the user.
Basic course of action 1 The manager wants to post vacancy for the users.
2.the manager click post announcement page from
menu
3. the manager choses the post vacancy button.
4.the system displays post announcement form
5. He fills all information needed to the vacant
position.

6. He will click on post button

7. The system displays successfully posted message.
8. use case end.
Alternative course of action
A.1 If the user doesn’t have access privilege to use
the system; user is not authenticated and is denied
access to the system.
A.2 Usecase ends.

27
Table 20 system use case description for view report.

Usecase name: view report

UC_ID: UC_04
Actor: HR manager

Description: the manager will see the reports generated from the dean.
Precondition: the manager must login to the system.

Post condition: the manager will see the reports if any.

Basic course of action 1.the manager wants to view reports
2.the manager should login to the system.
3. the manager clicks on view report button
4. the manager will see if there is any report.
5. Usecase ends.

Table 21 system use case description for send message.

Usecase name: send message

UC_ID: UC_05
Actor: HR manager

Description: after the manager have the results of the applicant, he will send the information’s to the
dean.
Precondition: there must be results to be send.

28
 Post condition: the dean will get the information.
Basic course of action
Alternative course of action
1.the manager wants to send some information’s.
2.the manager should login to the system.
3. the manager will insert the information to be send.
4. the manager will click on send button,
5. the system displays “message sent successfully” message.
6.Usecase ends
A1. If there is no result inserted to the system there will be
no information to be send.
A2 Usecase ends.

Table 22 system use case description for post result and interview date.

Usecase name: post screening information and result date

UC_ID: UC_06
Actor: HR manager

Description: after the applicants apply for the vacancy the manager will screen the documents and
if anyone fulfils the condition, he will post the result and also the interview dates.
Precondition: the applicants should apply for the vacancy.

Post condition: the applicants will view the posted dates and results.
Basic course of action 1.the manager wants to post screen and result date.
2.the manager clicks post announcement page from
menu
3. the manager choses display result and interview
date button
4. the system displays the information’s screened.

29
 5. the manager will click on post button

6. The system displays successfully posted message.

7. use case end.
Alternative course of action
A.1 If the user doesn’t have access privilege to use
the system; user is not authenticated and is denied
access to the system.
A2 Usecase ends.

Table 23 system use case description for screen information.

Usecase name: Screen information

UC_ID: UC_07
Actor: HR manager

Description: the HR manager screens the results of the applicants according to the standards given
from the department.
Precondition: the manager should have the requirements crosscheck with it.

Post condition: the results are screened.

Basic course of action 1. The manager wants to screen the documents.
2.After logging in to the system the manager clicks on
the screen button.
3.the system screens the results according to some
standards and displays the result.
4.Usecase ends.

30
 Alternative course of action
A1. If there is no applicant’s information inserted the
system will not screen anything.
A2 Usecase ends.

Table 24 system use case description for screen information.

Usecase name: Manage account

UC_ID: UC_08
Actor: HR manager

Description: This use case is done by the manager when they need update create and delete e profile
applicants’ information.
Precondition: The manager must login to the system to manage the applicants.
Post condition: The applicant’s information will be managed (created, updated) by the manager.
Basic course of action 1. The manager wants to manage accounts.
2. the manager click manage applicants link
3. the system display the manage applicants page
4. the manager manages (i.e. create, update, delete)
the account.
5. the system displays the successful massages

6. Usecase ends.

31
Table 25 system use case description for register.

Usecase name: Register

UC_ID: UC_09
Actor: Applicant

Description: this use case is done by the applicant in order to register for applying to the vacant
position.
Precondition: the applicant must have an internet connection, and must have necessary information
based on the announcement requirements.

Post condition: the applicant must be registered successfully.

Basic course of action 1: Applicant wants to register.

2. the applicant opens the home page of the

website.

3. the system displays the home page

4.applicant select online applicant registration

page.
5. the system displays the applicant registration
form 6. applicant fill all his/her information
required.
7: the system display register successfully
messages 8: applicant click apply button

9. Usecase ends

Alternative course of action A1 the system displays an error message if the

applicant information doesn’t fill accurately
A2 Usecase ends

32
2.6.5 Features
Some features of the system include

• Posting vacancy
• Online applying for vacancy
• Screening the applicant document
• Generating report
• Viewing posted vacancy
• Viewing posted screened result and interview dates
• Sending and receiving requirements needed for the vacancy by department and HR
manager respectively.
• Managing account of applicant

2.7 User interface prototyping

2.7.1 Traditional User-Interface Prototyping

Figure 12 User interface prototype Login form

33
 Figure 13 User interface prototype registration form

Figure 14 user interface prototype for post vacancy form

34
 2.7.2 User-Interface Flow Diagramming
Home Page

Vacancy Applicant About us

Login Contact
announcement
Screening us

HR admin Department Applicant page

page page

Send Generate View Apply Register View

requirements report results

Vacancy Screen
Manage View post View report View notification
account requirement comment

Screen Vacancy

Figure 15 User interface flow diagram

35
2.8 Supplementary specification
2.8.1 Business rules
In every organizations or institutions there are rules and policy, which used to govern all activities
in specified work flow, control the work flow, and performed in the work environment.

BR1: To get employee the departments who needs employee should write an application letter for
their vacant position to personnel department

BR2: when the vacant position is announced to external applicant on notice board or on mass
media externally for consecutive 5 to10 work days.

BR3: To be employed applicants should bring a clearance letter from previous Employer.

BR4: when the human resource hired the new employee to that of departments who needs an
employee, they must send a letter that has full documents about the new employee.

BR5: Access of information depends on the authority of the user.

BR6: If one wants to leave from HU before he/she fills the form leave form he/she must return all
working material to respected department otherwise they will be rejected.

2.8.2 Nonfunctional requirements

❖ Security:
➢ The system shall provide high level of security by blocking an authorised user to view
secured system page.
➢ The external security should be provided by giving login authentication.
❖ Performance:
➢ The system shall minimize errors and should display clear error message that guides
users.
➢ For login to the software password and user name should be matched to the password
and name.
➢ There shall be various ways of retrieving data and it shall take less time.

36
❖ Usability
➢ The end user shall be able to access any page fast according to the internet
connection speed.
❖ Availability
➢ The availability of the software shall be for everyone who has an internet connection.
➢ The system shall be available for 24 hours and 7 days a week.
❖ Correctness
➢ The results of the functions should be correct and accurate.
❖ Maintainability
➢ After the deployment of the project if any error occurs then it should be easily
maintained by the software developer.
❖ Portability
➢ The software shall work properly in any browsers.
❖ Reliability
➢ The performance of the software shall be better which will increase the reliability of
the Service.
➢ The system shall require guide and help to be understood by user.
❖ Reusability
➢ The data and record that are saved shall be reused if needed.
❖ Design Constraints: The system shall replace the existing system

2.8.3 Constraints
Some of the problems that we face while doing this project were: -

➢ Lack of time due to different reasons.

➢ During our project progress the computer laboratory was occupied by the
remaining Batch students or lack of enough computer access.

37
 CHAPTER THREE

3 Design Document

3.1 class modeling

3.1.1 Class layered approach

User interface class

Home page
Manage account
Post vacancy
Application
Screening
Generate report

Control/process class

Business/domain class
Schedule
SYSTEM
Requisition

Persistence Classes
Account

Comment

Screening info

Result

Applicant information

Requisition

38
 Figure 16 class layered approach

3.1.2 class diagram

The class diagram is the main building block of object oriented modeling. It is used both for
general conceptual modeling of the systematic of the application, and for detailed modeling
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 objects, interactions in the application and
the classes to be programmed.

In the diagram, classes are represented with boxes which contain three parts:

• The top part contains the name of the class.

• The middle part contains the attributes of the class.
• The bottom part contains the methods the class can execute [4].

39
 Figure 17 class diagram for HRMS

40
3.2 Sequence diagram
A Sequence diagram is an interaction diagram that shows how processes 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
and the sequence of messages exchanged between the objects needed to carry out the functionality
of the scenario. Sequence diagrams are typically associated with use case realizations in the
Logical View of the system under development [5].

Figure 18 sequence diagram for login

41
 Figure 19 sequence diagram for post announcement

42
 Figure 20 sequence diagram for view and register

43
 Figure 21 sequence diagram for send requirement

44
 Figure 22 sequence diagram for screen

45
3.3 Activity diagram
Activity diagrams are graphical representations of workflows of stepwise activities and actions
with support for choice, iteration and concurrency. In the Unified Modelling Language, activity
diagrams are intended to model both computational and organizational processes (i.e. workflows).
Activity diagrams show the overall flow of control [6].

Figure 23 activity diagrams for login

46
 Figure 24 activity diagrams for post announcement

Figure 25 activity diagrams for screening

47
 Figure 26 activity diagrams for Send requirement

Figure 27 activity diagrams for view and apply

48
3.4 User Interface Design
3.4.1 Form Design

Home About us Login

Login Vacancy Comment Contact us

1
Register 1
1
Screening
information Login form
Interview date
User name:
Password: Password

Forget password?
Login Cancel

HU

Figure 28 User interface design for login

49
 Home About us Login Vacancy
Vacancy Comment Contact us

Register
Applicant Registration Form
Screening
information
Applicant id: ID
Interview date First name: First name
Last name: Last name
Age: age
CGPA: CGPA
Educational level:

Email address:
email
Photo: Choose file
Scan your CV and related files: Choose file

Apply cancel

HU

Figure 29 User Interface Design for apply

50
3.4.2 Report Design

HOME Approved logout

CREATE NEW REPORT

UNREAD REPORTS (0)

Title No. replies Participant Date of creation

Welcome
You have no unread report.
Profile
READ REPORTS (3)

title No. replies Participant Date of creation

Message (0)
Message 0 Munteha 2/15/2019

Message 0 Emebet 19/01/2011

Message 1 Durati 1/3/2010

HU

Figure 30 user interface design for report design

51
3.4.3 Dialogue and Interface Design

Home About us Login

Login Vacancy Comment Contact us

1
Register 1
1
Screening
information Login form

Interview date
User name:
Incorrect user name
Password: ******** and password
please try again

Forget password?
Login Cancel

HU

Figure 31 User Interface Design for Dialogue and Interface Design

52
3.5 State chart diagram
State chart diagram is used to describe the states of different objects in its life cycle. So, the
emphasis is given on the state changes upon some internal or external events. These states of
objects are important to analyze and implement them accurately. State chart diagrams are very
important for describing the states. States can be identified as the condition of objects when a
particular event occurs. Before drawing a State chart diagram, we must have clarified the following
points:

• Identify important objects to be analyzed.

• Identify the states.
• Identify the events [7].

Figure 32 state chart diagram for login

53
 Figure 33 state chart diagram for send requirement

Figure 34 state chart diagram for post announcement

54
 Figure 35 state chart diagram for view and apply

Figure 36 state chart diagram for screen

55
3.6 Object diagram
Object Diagram (instance diagrams), are useful for exploring real world examples of objects and
the relationships between them. It shows instances instead of classes. They are useful for
explaining small pieces with complicated relationships, especially recursive relationships.

Figure 37 Object diagram for HRM

56
3.7 Persistent Modeling/ Database Design
3.7.1 Normalized database

1st normal form

HR manager table
mid uname password

Department table
Did uname password

Applicant table
aid uname password

Requirement table
Recruitment Type of department Edu_level Quantity Term of sex
number position employee

Schedule table
Sid date Job Written Practical place remember
number exam date exam date

Report table
Rid name date time

Registration table
aid uname age CGPA sex email Scan Photo
file

Screening
aid uname lname CGPA sex age

comment
cid uname email comment

57
3.7.2 Normalized Physical database model

Database design is the process of producing a detailed data model of a database. This logical data
model contains all the needed logical and physical design choices and physical storage parameters
needed to generate a design in a Data Definition Language, which can then be used to create a
database. A fully attributed data model contains detailed attributes for each entity. The term
database design can be used to describe many different parts of the design of an overall database
system. Principally, and most correctly, it can be thought of as the logical design of the base data
structures used to store the data [8].

Figure 38 Persistent diagram

58
3.8 Component diagram
By this Diagram, components of the system will be wired showing that there is relation among
components; management of the system, database and operations performed on databases such
security issue. This in some extent shows which component or objects will be accessed by whom
and what type of security infrastructures it is using.

Figure 39 Component diagram

59
3.9 Deployment diagram
Deployment diagrams model the physical architecture of a system, and it shows the relationships
between the software and hardware components in the system and the physical distribution of the
processing [9].

Figure 40 Deployment diagram for HRMS

60
3.10 Current software architecture
The current is system have no software architecture since everything works by manual or paper-
based system.

3.11 Proposed software architecture

The proposed system is expected to replace the existing manual system by an automated system
in all facets.

The architecture used for the system is a 3 tier Client/Server Architecture where a client can use
Internet browsers to access the online report provided by the system within the local area network
of the school or anywhere using the Internet. Figure 25 shows the architecture of the proposed
system.

The middle tier (web/application server) implements the business logic, controller logic and
presentation logic to control the interaction between the application’s clients and data. The
controller logic processes client requests such as requests to view applicants result, to record some
data or to retrieve data from the database. Business rules enforced by the business logic dictate
how clients can and cannot access application data and how applications process data.

A web server is a program that runs on a network server (computer) to respond to HTTP requests.
The most commonly used web servers are Internet Information Server (IIS) and Apache. The web
server used in this system is IIS. HTTP is used to transfer data across an Intranet or the Internet. It
is the standard protocol for moving data across the internet.

The client tier is the applications user interface containing data entry forms and client-side
applications. It displays data to the user. Users interact directly with the application through user
interface. The client tier interacts with the web/application server to make requests and to retrieve
data from the database. It then displays to the user the data retrieved from the server.

61
 Figure 41 proposed software architecture

62
References

[1] "haramaya university," [Online]. Available: http://www.haramaya.edu.et. [Accessed 1/2/2019

february 2019].

[2] R. miler, in the object primer third edition.

[3] sysem usecase. [Film]. indian.2009.

[4] E. torlack, UML CLASS DIAGRAM, 2016.

[5] R. miler, the object primier, 2004.

[6] I. John Wiley & Sons, system analysis and design fifth edition, 2015.

[7] I. John Wiley & Sons, system analysis and design fifth edition, 2015.

[8] physical database model. [Film]. 2007.

[9] T. o. p. 2. edition, scott w.ambeler, 2004.

63
Appendix I
The questions below are some questions that we asked during our requirement gathering phases.
The questions listed below includes about the HRM history and the work flow structure of the
HRMS.

1. Was the existence of the HRM within the existence of Haramaya University?

2. What is the work flow structure of the existing system?

3. How dose the actors in the system (i.e. Department, HR manager, Applicant) interacts with each
other?

4. In the existing system how does the announcement process goes on?

5. How does the applicant will register for vacancy?

6. what are some difficulties you face in the System?

64