HAWASSA UNIVERSITY

Institute of Technology
Faculty of Informatics
Department of Information Technology
Project title: - Web based Wosagn Kunetoch Management System for Hawassa Town

Group members

NAME ID No

Submission Date: February 8, 2022.

Table of Contents

List of Table..................................................................................................................................................6
List of Figure................................................................................................................................................7
List of Acronyms..........................................................................................................................................8
CHAPTER ONE...........................................................................................................................................1
1. Introduction..........................................................................................................................................1
1.1. Background of the Study.............................................................................................................1
1.2. Statement of the Problem............................................................................................................2
1.3. Objectives of the Project..............................................................................................................2
1.3.1. General Objective.................................................................................................................2
1.3.2. Specific Objectives................................................................................................................2
1.4. Scope of the Project......................................................................................................................3
1.5. Limitation of the Study................................................................................................................3
1.6. Significance of the project...........................................................................................................3
1.7. Methodology.................................................................................................................................4
1.7.1. Data Collection Methodology..............................................................................................4
1.7.2. System Analysis and Design Methodology.........................................................................5
1.7.3. Testing and Deployment Methodology...............................................................................5
1.7.4. Development Environment..................................................................................................6
1.7.5. System Requirement............................................................................................................6
1.8. Feasibility Study...........................................................................................................................8
1.8.1. Economic Feasibility............................................................................................................8
1.8.2. Technical Feasibility............................................................................................................8
1.8.3. Operational Feasibility........................................................................................................8
1.8.4. Political Feasibility...............................................................................................................8
Chapter Two.............................................................................................................................................9
2. Description of Existing System...........................................................................................................9
2.1. Introduction of the Existing System...........................................................................................9
2.2. Proposed System Description....................................................................................................10
2.3. Strength of Existing System......................................................................................................11
2.4. Weakness of Existing System....................................................................................................11
Chapter Three............................................................................................................................................13
3. System Features..................................................................................................................................13

2
 3.1. Introduction................................................................................................................................13
3.2. Functional Requirements...........................................................................................................13
3.3. Non-Functional Requirements..................................................................................................14
3.4. Analysis Models..........................................................................................................................14
3.4.1. Use Case Diagrams.............................................................................................................14
3.4.2. Sequence Diagram..............................................................................................................30
3.4.3. Activity Diagram................................................................................................................38
3.4.4. Class diagram.....................................................................................................................49
3.4.5. User Interface Prototyping................................................................................................50
3.4.6. User Interface Design.........................................................................................................51
Reference.....................................................................................................................................................66
Appendixes..................................................................................................................................................66

3
List of Table
Table 1. 1: Hardware Requirement..................................................................................................6
Table 1. 2: Software Requirement...................................................................................................7

Table 3. 1: Login Use case Description.........................................................................................17

Table 3. 2: Register Event use case description.............................................................................18
Table 3. 3: Search Resident Use case Description.........................................................................19
Table 3. 4: Update Event Use case Description.............................................................................20
Table 3. 5: Create account use case description.............................................................................20
Table 3. 6: Lock Account use case Description.............................................................................21
Table 3. 7: See Report use case Description..................................................................................21
Table 3. 8: Generate Report use case Description.........................................................................22
Table 3. 9: See event use case Description....................................................................................22
Table 3. 10: Give Printed Certificate use case Description...........................................................23
Table 3. 11: Change Password use case Description.....................................................................24
Table 3. 12: unlock account use case Description.........................................................................24
Table 3. 13: Logout use case Description......................................................................................25
Table 3. 14: Post news use case Description.................................................................................25
Table 3. 15: update news use case Description..............................................................................26
Table 3. 16: delete news use case Description...............................................................................27
Table 3. 17: see news use case Description...................................................................................28
Table 3. 18: Send Request use case Description............................................................................28
Table 3. 19: Send Message use case Description...........................................................................29
Table 3. 20: View Message use case Description..........................................................................29

4
List of Figure
Figure 2. 1: Death certificate of Existing systems.........................................................................10

Figure 3. 1: Use Case Diagram......................................................................................................16

Figure 3. 2: sequence diagram for Login.......................................................................................30
Figure 3. 3: sequence diagram for Create account.........................................................................31
Figure 3. 4: sequence diagram for Register Event.........................................................................31
Figure 3. 5: sequence diagram for Search event............................................................................32
Figure 3. 6: sequence diagram for Give printed Certificate...........................................................32
Figure 3. 7: sequence diagram for see event..................................................................................33
Figure 3. 8: sequence diagram for logout......................................................................................33
Figure 3. 9: sequence diagram for Change Password....................................................................34
Figure 3. 10: sequence diagram for Generate Report....................................................................34
Figure 3. 11: sequence diagram for See Report.............................................................................35
Figure 3. 12: sequence diagram for Lock Account........................................................................35
Figure 3. 13: sequence diagram for Unlock account.....................................................................36
Figure 3. 14: sequence diagram for post news...............................................................................36
Figure 3. 15: sequence diagram for Update news..........................................................................37
Figure 3. 16: sequence diagram for delete news............................................................................37
Figure 3. 17: login activity diagram...............................................................................................38
Figure 3. 18: Create account activity diagram...............................................................................39
Figure 3. 19: Lock account activity diagram.................................................................................39
Figure 3. 20: Register event activity diagram................................................................................40
Figure 3. 21: logout activity diagram.............................................................................................40
Figure 3. 22: Search event activity diagram..................................................................................41
Figure 3. 23: See event activity diagram........................................................................................41
Figure 3. 24: Update event activity diagram..................................................................................42
Figure 3. 25: give printed certificate activity diagram...................................................................43
Figure 3. 26: Generate report activity diagram..............................................................................43
Figure 3. 27: See report activity diagram.......................................................................................44
Figure 3. 28: post news activity diagram.......................................................................................44
Figure 3. 29: Delete News activity diagram..................................................................................45
Figure 3. 30: Update News activity diagram.................................................................................45
Figure 3. 31: Change password activity diagram...........................................................................46
Figure 3. 32: unlock account activity diagram...............................................................................46
Figure 3. 33: add Kebele activity diagram.....................................................................................47
Figure 3. 34: send request activity diagram...................................................................................47
Figure 3. 35: send message activity diagram.................................................................................48
Figure 3. 36: view message activity diagram.................................................................................48
Figure 3. 37: class diagram............................................................................................................49
Figure 3. 38: user interface prototype diagram..............................................................................50
Figure 3. 39: user interface design of home page..........................................................................51

5
Figure 3. 40: user interface design of Login page..........................................................................52
Figure 3. 41: user interface design of Register page......................................................................53

List of Acronyms
ICT........................Information Communication Technology
USA......................United State of America
RAM....................Random Access Memory
CPU......................Central Processing Unit
GB........................Giga Byte
GHZ....................Giga Hertz
TB.........................Tera Byte
UTP......................Unshielded Twisted Pair
RJ............................Register Jack
UML......................Unified Modelling Language
UC...........................Use Case

1
 CHAPTER ONE
1. Introduction

The age of information has brought lot of opportunities to world which are revealed by
information and communication technology (ICT). The vital role that ICT can play in facilitating
and accelerating socio economic development has been recognized worldwide. Developed
countries such as Canada, Australia and USA have benefited a lot from the opportunities that
ICT brought. On the other hand developing countries like Ethiopia are facing new challenges
with their socio economic development as a result of the upcoming information age.
To satisfy the demand of the current global economic system developing countries have
ICT as a crucial tool and means to eradicate poverty , speed up socioeconomic development,
provide effective and efficient public service implement E- government and speed up good
governance.
Vital Events (Wosagn Kunetoch) management system is the systematic recording of the
occurrence and characteristics of vital events (birth, death, marriage, adoption, and divorces). A
birth certificates is considered as a ticket to citizenship, on the other hand , death certificate is
mandatory proof of relieving a person from the entire social, legal and financial obligation and
supports his/her family members on having the property rights. Marriage and divorce certificates
are also proof officially being married and separated from husband or wife.
1.1. Background of the Study

Vital events (Wosagn Kunetoch) are the events those are main happenings in the life time
like birth, adoption, death, marriage, and divorce. Since these kinds of events are the main
components for any personal profile, they should be registered well.
Despite governmental organization is assigned which is eligible for registering vital events,
still there are people who are using other institutions (hospitals and churches) registrations as
eligible for many purposes. For example using church’s baptizing certificate or hospital’s
vaccination certification as a birth certification.
Currently the office is open for registering events like birth, adoption, marital status (single,
married) and death. According to the office the event registration is carried using paper works,

2
which may lead to data loss.

3
1.2. Statement of the Problem

 The way information is secured is weak since paper are prone to be stolen which
result in loss of information.
 The manual system takes time in which number of customer to be served per days.
 The manual system is hard to update the vital events information.
 It is difficult to generate report.
 Paper can be damaged easily by accidents.
 Data is not well organized in those area difficult to analyze statistically.
 It is also difficult to find information about users when it’s needed because they don’t
have access to any automated system.
 When we see the forms registrars may forget to fill spaces and leave them empty this
leaves data incomplete.
 In the manual system duplication of data is occurred.
 Errors that occur on papers cannot be corrected easily also it affect economically.

1.3. Objectives of the Project

1.3.1. General Objective
The general objective of the project is to design and implement centralized vital events
(Wosagn Kunetoch) information management system for Hawassa Town.

1.3.2. Specific Objectives

To reach the general objective the following specific objectives are set.
 To Study existing works related to our problem.
 To be familiar with tools and technologies that can be used to design and implement
our system.
 To gather data about Wosagn Kunetoch and how it works.
 To analyze collected data and examine the problems of current system.
 To design or address the requirements specified in analysis phase for proposed system.
 To implement the system according to the system design.
 Deploy and test the performance of the system.

4
1.4. Scope of the Project
 The system will do registration of birth, adoption, marriage, divorce, and death.
 The administrator post News about vital events.
 Events will have their own form to register and can be viewed by actors that have
privilege.
 Update the customer’s information.
 This system will have well organized central database that is accessible by every
stage employees.
 The system will generate report and give printed certificate if it is necessary.
 The administrator has the privileges to create and deactivate manager account.
 The manager has the privileges to create and deactivate officer account.
 The resident create account themselves.
 Resident Sends request to the officer to get a printed certificate.

1.5. Limitation of the Study

Although the system is advantageous compared to the manual system but it still has limitations.

The followings are the main limitation of our project

 Due to lack of enough time to develop Wosagn Kunetoch information management

system our system is limited to implement tasks which are listed on scope.
 Our system only support English language.
 The system need internet connection because of this many customers may not access the
system.
 Some customers may not access the web site because of lack of knowledge example
lower level workers.

1.6. Significance of the project

The study work will help in a good numbers of ways to ease register of vital events the web based
and centralized management system will helps customers, employees and the administration.

The web based Wosagn Kunetoch Management system significance to:-

 Save time,

5
  Avoid workload of employees,
 Avoid decentralized of information in different area such as (church, hospital),
 Avoid data lost and increase accuracy of data.
After completion of this project, the system will provide benefits to different users such as

 Customers: -They will save time since they served quickly than the previous system. It
also use customer to store data as secure in computerized manner.
 Employees: - The vital event registration workers will get a simple and helpful tool
during retrieve, updating data, register event.
 Company: - The administration will be benefited because it able to control all vital
events in centralized and computerized manner.

1.7. Methodology

We use different methodology to develop this new system, those are:-

1.7.1. Data Collection Methodology

To develop web based vital event (Wosagn Kunetoch) management system data collection was
one of the important task to analysis how activities done in the existing system and to develop
the new system. Data obtain from different source we use primary source like observation and
interview techniques.

Observation: This technique is the most reliable fact finding techniques because we use this
method when observing the existing vital events (Wosagn Kunetoch) management system done
by employees. We have observe the following about the existing system:-

 It takes time in which number of customer to be served per days.

 It is hard to manage the data.
 Occurs duplication of data.
 It is difficult to data processing, update, and search the registered information.
 It occurs loss of data because paper can be damaged easily by accident.
 Shortage of Birth certificate to give for the customers.
Interview: We used interview as one of the major data collection methods. During the interview
we have got different necessary information from the vital event registration offices found in

6
Hawassa town. We have also interview Sidama National Regional State Vital Events registration
Agency Director of Educational and Training Directorate Ato Frew. We also asked some
question about the existing system like:-

 What kind of system are used?

 How the existing system works?
 What are the problems of the existing system?
 Is the customer happy with the existing system?
 Who are responsible for managing the system?
 How to give a certificate for the customers?
And also Ato Frew give responses all about the listed questions.

1.7.2. System Analysis and Design Methodology

System development methodology is a way that is used to structure plan and control the flow of
developing an information system. For this project we used object oriented software
development methodology.

The reason why we selected object oriented system development is because it has the following
advantages.

 Object-oriented systems development is a way to develop software by building self-

contained modules or objects that can be easily replaced, modified, and reused.
 Is used to manage the complexity of software systems because objects, attributes,
methods can be reused so it reduces the complexity of the code.
 The project is implemented in an object oriented environment.
 It encourages re-use not only modules but also entire design.
 Objects are grouped into classes in object oriented term, we discover and describe the
classes involved in the problem domain.
 Each object has attributes (data) and methods (functions).

1.7.3. Testing and Deployment Methodology

There are two types of testing methodologies. Those are white box and black box. So the
programmer has to check its faults before others do (White box). And others who don’t have
programming knowledge have to test the system (Black box). To ensure the system is fine the
web
7
based vital event (Wosagn Kunetoch) Management system will be tested by both black box and
white box.
The reason we select black box test to remove error that occurs in our system. In this test end
user may observe that error. This testing method will not need knowledge of implementation and
programing knowledge it concern on functionality of system, and take less time to test. Whereas,
in the white box testing activity will perform by developer and testing needs with knowledge of
implementation, programing language due to this testing will perform both functionality of the
system and implementation.
1.7.4. Development Environment
We will use Apache NetBeans IDE to writing and editing purpose of the code.

1.7.5. System Requirement

In order to develop a web based system, it is very important to choose the correct hardware,
software and technology. Below there are some explanations of the hardware, software and
technology chosen as development tools to the vital events (Wosagn Kunetoch) management
system.

A. Hardware Requirement

The Followings are hardware requirements for developing the system such as:

Table 1. 1: Hardware Requirement

Hardware Tool Machine

Client Server

RAM 4GB 8 GB

CPU 2 GHZ 2 GHZ

Hard disk 500 GB 1 TB

Other Internet connection tools such as UTP, RJ45, and Printer.

8
 B. Software Requirement

The Followings are Software requirements for developing the system such as:

Table 1. 2: Software Requirement

Software tools Applications

Microsoft word Used to write the document

Microsoft Power point Used to prepare slide for presentation

Microsoft Visio Used for design different diagram

Browser Used to search information from google and

For displaying the system

Apache NetBeans Used to write code

Xamp servers Used to connect the code with database

C. Programming Language

We will use different types of programming languages to implement or change our system from
document to practice. The system that we are going to develop must be user interactive, easy to
understand, and interesting to use in order to achieve those features we will use the following
programming language.

 Server side programming script, PHP.

 Database system, MySQL

 Client side language, HTML, CSS, JavaScript.

9
1.8. Feasibility Study

Feasibility studies are conducted in our project development. The aim of this study is determine
whether or not the new system is feasible in different feasibility study such as economic,
technical, operational and political feasibility.

1.8.1. Economic Feasibility

Our project is economically feasible. It may save the resources like paper and other stationary
materials, time and on the other side the man power usage in vital event Management System
will decreases. So it is economically feasible.

1.8.2. Technical Feasibility

Currently the most web servers support PHP. So we can get web server easily. Our database
server is MySQL and it is easily maintainable. Since all features are available on web the client
don’t need to install other applications rather than a web browser. Unified Modeling Language
(UML) model to do analyzing and designing in good manner. So the system will be technically
feasible.

1.8.3. Operational Feasibility

The client can get a user friendly GUI and easily operable system. So our system is operational
feasible. It determines how the proposed system will satisfy the organizations need and it also
offers Secure, accurate and efficient system to the organization.

The system in which we are developing is also compatible to all operating systems and web
browsers. So our proposed system is operational feasible.

1.8.4. Political Feasibility

Our system doesn’t conflict to any national or international laws. The main purpose of this
system is to record all vital events in computerized and centralized way. But the people privacy
will be secured.

10
 Chapter Two
2. Description of Existing System
2.1. Introduction of the Existing System
The existing system try to reach users from federal to Keble in every stage there is vital event
registrar with employees that are responsible for every action. The registration starts from Keble.
In Keble the registration is done by the Keble manager with help of nominators. These
nominators have their own responsibility which is to give information for the Keble manger if
there is new vital event (birth, adoption, death, marriage and divorce.) with in Keble. Then data
is copied within four papers called honour files and sent it to region and other stages. Within
every office (regional, federal and one for central statistics agency) they take one copy from
every type of vital event registration papers for themselves. The Ethiopian federal vital event
registration agency has many responsibilities including print the registration papers (honour files)
and distribute them to regions.

For peoples that live out of Ethiopia there are organizations that are responsible for registration
of vital events like (defense ministry of Ethiopia, foreign ministry of Ethiopia and Ethiopian sea
transportation and logistics service organization) this organization register vital events and send
to federal vital event registration agency

If someone wants to register vital events he or she needs to have Keble identity card and if it is
birth event the parents of the child should appear physically to the registrars and get registered. If
parents are not alive or cannot go to the registrars because of work or other reasons the person
who is responsible for the child must appear and register but he or she should have delegation
paper from courts.

All vital events has its own certificate form. For example form used for Death certificate is
shown below in the figure.

11
Figure 2. 1: Death certificate of Existing systems

2.2. Proposed System Description

Our team saw the existing system of vital event Management system. We see different problem
and we initiation to do change the current system into web based system. Our proposed system
can do web based management system. The new system can to improve with better to the
existing system. The new system/ the proposed system can different activities’ the vital event
Management system is developed in order to minimize the problem of Existing system which is
described in the statement of the problem. Unlike existing system the proposed system is
effective at the time of registration, update, and search.
Generally the new system is:-
 Easily file manage and to easily search files or data’s.
 Capable of providing high data security and reliability.
 System can generate report easily this makes to minimize the work load of employee.
 Capable of better providing fast service for users and workers during update and search.

12
2.3. Strength of Existing System
The Existing System has the Following Strength:-
 It creates opportunities to work because it needs number of workers since it works manual.
 No cost of electronic devices and other costs like internet connection.
 Information become centralized in one office. Means existing system ignore certify event
from other institutions like (hospital, churches).
 All peoples use the system because of there is no need of electronic device knowledge.
 It increase the human interaction.

2.4. Weakness of Existing System

The Existing System has the following Weakness:-

 Have Problem in data Storage and management: In the current system data are stored in a
paper form, due to this reason it is very difficult to store and manage papers data by the
current Wosagn Kunetoch management system. If the number of paper data is huge it is
tedious to manage that data by human beings. Therefore, proper and systematic database
should be used to store these data and to allow user to manage data efficiently and
effectively.
 Problem in data security: Data management and storage are most common issues of
security, in the current manual system, there is no any types of software security rather it has
only physical security. The current system has no software security therefore it leads
sensitive data to be changed or lost. The current system has no authentication method to
identify who is the correct authorized user.
 Performance and Response time: The current system has low performance and response
time because the system does not use machine (mobile and computers) to facilitate their
work.
 Problems in data back upping: back upping of data are difficult because the data is
organized in a paper form so to back up such types of data there must be a room to store
paper data. When the paper data is large it is difficult to back up all data in a room.
 Problem in information retrieval: the information retrieval is very less this is due to the
problem of not having computerized and centralized database to retrieve information to some

13
body that wants to access the information or data.

14
 Problem in economic: lots of money is spent on paper print, pens, record books so and so
on.
 Problem in time:- recording of data is very time consuming due to the operation of
existing system are operated by manual system. Writing everything on paper is also time
consuming.
 Problem to generate report: - it is difficult to generate report.
 Problem in paper formulation: - peoples may leave empty space on the registration papers.

15
 Chapter Three
3. System Features
3.1. Introduction
This chapter outlines the functional and non-functional requirements of the system. It also
demonstrates the requirement elicitation of the system using system models which include the
use case diagram, class diagram, sequence diagrams and activity diagram.
3.2. Functional Requirements
Functional requirements are the description of the facility or feature required. Functional
requirements deal with what the system should do or provide for users. They include description
of the required functions, outlines of associated reports or online queries, and details of data to be
held in the system.
Our system has the following Functional requirement.
 The system should allow the user to login to the system.
 The system should allow the user to create account for users.
 The system should allow the user to lock account of users.
 The system should allow the user to update account of users.
 The system should allow the user to unlock account of users.
 System should allow Generate report based on the activities.
 The system allows View report.
 The system should allow Register event based on customers’ information.
 The system should allow View event.
 The system should allow Give certificate based on registered event.
 The system should allow Add news.
 The system should allow Update news.
 The system should allow View news.
 The system should allow Logout.
 The system should allow send Event request to get certificate.
 The system should allow communication between users.

16
3.3. Non-Functional Requirements
Nonfunctional requirement is the second type of requirements that describe invisible aspects of
the system and additional quality of system. Such as accuracy, maintainability, portability,
reliability, performance, graphical user interface, and etc.
 Accuracy: The system will be accurate to search; update, register and login to system and
user get correct and real information.
 Security: The new user should allow login for authorized user who has an account. The
system should allow password must be encrypted when it is placed in the data base.
 Availability: The availability of system will be for everyone who has an internet connection.
The system will be available for 24 hours.
 Accessibility: Since the new system is web based it can access easily
 Correctness: The result of function should be correct and accurate.
 Maintainability: The new system can maintain when the problem will occur. After the
deployment of the project if any error occurs then it should be easily maintained by the
system developer.
 Performance: The proposed system performs tasks and produces an output with in short
period of time. That means it take short response time to perform all activities such as
retrieve, register information. The system shall minimize errors and should display clear error
message that guides users there will be various way of retrieving data and it shall take less
time.
 User Interface: The user interface should be user friendly and attractive graphical user
interfaces that ease to use and learn the system.

3.4. Analysis Models

In this section we are going to describe the proposed system by using different UML diagram.
The diagram is used to model the system or subsystem of an application. Analysis results in a
model of the system that aims to be correct, complete, consistent, and unambiguous.
3.4.1. Use Case Diagrams
A use case diagram is a representation of a user's interaction with the system and describing the
specifications of a use case. It contains actors, use case, and their relationships. Let us see the use
case diagram.

17
Actors
 Officer
 Manager
 Administrator
 Resident
Use Case
 Login  Send Request
 Register Event  Change Password
 Update Event  Lock Account
 See Event  Unlock Account
 Give Printed Certificate  See Report
 Search Resident  Add Kebele
 Send Message  Post News
 View Message  Update News
 Generate Report  Delete News
 Create Account  Logout

18
Below is the use case diagram for Web based Wosagn Kunetoch Management System for
Hawassa Town.

Figure 3. 1: Use Case Diagram.

19
Use Case Description

Login
Use case Number UC-01
Use Case Name Login
Actors Officer, Resident, Manager, and administrator.
Description This use case describes how each user login into the System.
Precondition All user must have previously created account.
Post condition If the use case was successful, the user is now logged into the
system. If not, the system state is unchanged.
Normal flow of 1. The users open system.
events 2. The user click login button.
3. System displays the login form.
4. The User enters user name and password and click login
button.
5. The system verifies the password and username.
6. The system logs in the user.
7. Use case end.
Alternative flow of If user simply click login button without enter password and
event name
Please enter the username and password Message displayed.
If user enter incorrect password and username
Invalid username and password combination message display
Use case end.

Table 3. 1: Login Use case Description.

20
Register Event
Use case Number UC-02
Use Case Name Register Event
Actors Officer
Description The use case is about registering new event
Precondition A user must be logged as an officer.
Post condition New event is registered on the database
Normal flow of 1. Officer click add event button.
events 2. System Display alternative to select event type.
3. Officer select event type.
4. System displays event form
5. Officer fill information and click register button.
6. System validate the entry and register event in the database.
7. Use case end.
Alternative flow of If user enter invalid data
event Please enter correct data message displayed
Use case end.
Table 3. 2: Register Event use case description

Search Resident
Use case Number UC-03
Use Case Name Search Resident
Actors Officer
Description Searching the information from the database.
Precondition The user must be logged in first.
Post condition Get the search information.
Normal flow of 1. User click search button
events 2. System display the form.
3. Fill the entry to search.
4. System check and display the event information

21
 5. Search event successfully.
6. Use case end.
Alternative flow of If the required information is incorrect
event Fill the information again message displayed
Use case end.
Table 3. 3: Search Resident Use case Description

Update Event
Use case Number UC-04
Use Case Name Update Event
Actors Officer
Description Update the customer information in the database.
Precondition Officer logged in first and customer information must be exist.
Post condition The customer information updated.
Normal flow of 1. Officer click update button.
events 2. System display search form.
3. Officer select event type to update and enter required
information.
4. System search and displays the result in the selected event
type to update.
5. System display search result.
6. Officer select the event to update.
7. System display event update form.
8. Officer enter new information and click update button.
9. System validate the information.
10. System update and save on the database.
11. Use case end.
Alternative flow of If the required information is incorrect
event No result found try again message display.
If user enter incorrect information.

22
 The inputs are invalid please enter correct data message displayed
Use case end.
Table 3. 4: Update Event Use case Description

Create Account
Use case Number UC-05
Use Case Name Create Account
Actors Resident, Manager, Administrator
Description Describe how to create account.
Precondition Some user must logged in first and Resident without logged in
first.
Post condition Create account.
Normal flow of 1. Click create account button.
events 2. System display form.
3. Fill the information and click submit button.
4. System validate the information.
5. System register the information to the database.
6. Successfully account create.
7. End use case.
Alternative flow of If the required information fill is incorrect.
event please try again message display
Use case end.
Table 3. 5: Create account use case description

Lock Account
Use case Number UC-06
Use Case Name Lock Account
Actors Manager, Administrator
Description Describe how account to be locked
Precondition User must previously must have account.

23
 Post condition Account become locked.
Normal flow of 1. User click account button.
events 2. System display list of user form page.
3. User select the user account to be locked.
4. User click Lock button.
5. System lock account from database.
6. The system displays successful locked user account message.
7. Use case end.
Alternative flow of If the required information fill is incorrect.
event please try again message display
Use case end.
Table 3. 6: Lock Account use case Description.

See Report
Use case Number UC-07
Use Case Name See Report
Actors Manager
Description Describe how the user see report.
Precondition User must logged in and report must be present previously
Post condition User see report.
Normal flow of 1. User opens the see produced report page.
events 2. System displays the produced report.
3. User see the report.
4. Use case end.
Table 3. 7: See Report use case Description.

Generate Report
Use case Number UC-08
Use Case Name Generate Report
Actors Officer

24
 Description Describes how to generate report.
Precondition User logged in first
Post condition Generate report.
Normal flow of 1. User click generate report button.
events 2. System display page.
3. User fill the information.
4. System validate the information.
5. System save it to file.
6. Generate report success message displayed.
7. Use case end.
Alternative flow of If option form fill incorrect.

event Please fill the option form correctly message displayed.

Use case end.
Table 3. 8: Generate Report use case Description.

See Event
Use case Number UC-9
Use Case Name See Event
Actors Officer, Manager
Description Describe how user see event.
Precondition First register event must exist
Post condition Event saw by user.
Normal flow of 1. Click see event button.
events 2. System display alternative to select event type to see.
3. User select event to see.
4. System show the information.
5. Use case end.
Table 3. 9: See event use case Description

25
Give Certificate
Use case Number UC-10
Use Case Name Give Printed Certificate
Actors Officer
Description Describe how to give Printed certificate.
Precondition User logged as Officer and event must be registered.
Post condition Give certificate to the customer.
Normal flow of 1. Officer click give certificate button.
events 2. System display search form.
3. Officer select event to give certificate.
4. Enter required information.
5. System search and display the result in the selected event
type.
6. Officer select event to give certificate.
7. System display certificate preview.
8. Officer click print button.
9. System print the Certificate.
10. Use case end.
Alternative flow of No result found please try again. Message displayed.
event Use case ends.
Table 3. 10: Give Printed Certificate use case Description

Change Password
Use case Number UC-11
Use Case Name Change Password
Actors Officer, Resident, Manager, Administrator.
Description Describe how to change password of the users.
Precondition User must have account previously.
Post condition Users change password

26
 Normal flow of 1. Click change password button.
events 2. System displays form.
3. Fill the information.
4. Press change password button.
5. System validate the information.
6. System update information on the database.
7. Success message display.
8. Use case end.
Alternative flow of Invalid input. Please try again message displayed.
event Use case ends.
Table 3. 11: Change Password use case Description

Unlock Account
Use case Number UC-12
Use Case Name Unlock Account
Actors Manager, Administrator
Description Describe how to Unlock account.
Precondition User must logged in as an administrator and as a Manager and
account has exist.
Post condition Unlock account.
Normal flow of 1. Click unlock account button.
events 2. System display page.
3. Administrator select locked account and click unlock button.
4. System unlock the account.
5. Success message display.
6. Use case end.
Table 3. 12: unlock account use case Description

27
Logout
Use case Number UC-13
Use Case Name Logout
Actors Officer, Resident, Manager, Administrator
Description Describe how to logout from the system
Precondition User must logged in to the system.
Post condition User logout from the system.
Normal flow of 1. User click logout
events 2. System return to login page
Table 3. 13: Logout use case Description

Post News
Use case Number UC-14
Use Case Name Post news
Actors Administrator
Description Describe how Administrator post news

Precondition User must logged in as administrator

Post condition News will be posted
Normal flow of 1. Admin click news button.
events 2. System display news page.
3. Admin click add news button.
4. System display form.
5. Admin fill the information and click post button.
6. System validate the input and save to the database.
7. Success message display.
8. Use case end.
Alternative flow of Enter the required form is incorrect please try again message
event display
Use case end
Table 3. 14: Post news use case Description

28
Update news
Use case Number UC-15
Use Case Name Update news
Actors Administrator
Description Describe how Administrator update news.
Precondition User must logged as administrator and news must be posted
before.
Post condition News will be updated.
Normal flow of 1. Administrator click news button.
events 2. News page display.
3. Administrator clicks edit button on the news to be updated
from news table.
4. System display form.
5. Admin fill information and click update button.
6. System validate the input.
7. System update the news to database.
8. Success message display.
9. End use case.
Alternative flow of Enter the required form is incorrect please try again message
event display
Use case end
Table 3. 15: update news use case Description

Delete News
Use case Number UC-16
Use Case Name Delete news
Actors Administrator
Description Describe how Administrator delete news.

29
 Precondition User must logged as administrator and news must be posted
before.
Post condition News will be deleted.
Normal flow of 1. Admin click news button.
events 2. News page displayed.
3. Admin clicks delete button on the news to be updated from
news table.
4. System displays confirmation dialog.
5. Administrator choose delete button.
6. System deletes the news from the database.
7. Success message displayed.
8. End use case.
Alternative flow of Error! Cannot open the data base please contact system
event administrator message displays.
Use case end
Table 3. 16: delete news use case Description.

Add Kebele
Use case Number UC-17
Use Case Name Add Kebele
Actors Manager
Description Describes how to add Kebele
Precondition User must be logged in as a manager
Post condition Kebele will be added

30
 Normal flow of 1. Manager click add Kebele button.
events 2. System displays the form.
3. Manager fill the information and click submit to add Kebele.
4. System validate the submit information.
5. Success message display.
6. Use case end.

Alternative flow of If manager fill incorrect information

event Enter the required form is incorrect please try again message
display
Use case end
Table 3. 17: see news use case Description.

Send Request
Use case Number UC-18
Use Case Name Send Request
Actors Resident
Description Describe how Resident send request to get certificate.
Precondition User must logged as Resident.
Post condition Request is send
Normal flow of 1. Resident click request button.
events 2. System display event alternative.
3. Resident select Event Type
4. System displays event forms
5. Resident fill the information and click send button.
6. System validate the input.
7. System save the input in the database.
8. Success message display.
9. End use case.

31
 Alternative flow of If user fill incorrect information
event Enter the required form is incorrect please try again message
display
Use case end
Table 3. 18: Send Request use case Description.

32
Send Message
Use case Number UC-19
Use Case Name Send Message
Actors Officer
Description Describe how user send message.
Precondition User see the request.
Post condition User send message
Normal flow of 1. Click send message button.
events 2. System display pages
3. Select users.
4. Write message and click send button.
5. System validate the message.
6. System sends message to the user.
7. Send message successfully.
8. End use case.
Alternative flow of incorrect input please try again message display
event Use case end
Table 3. 19: Send Message use case Description.

View Message
Use case Number UC-20
Use Case Name View Message
Actors Resident
Description Describe how to view message.
Precondition First message must be exist.
Post condition User view message
Normal flow of 1. User open the message page.
events 2. System display the message.
3. User see the message.
4. Use case End
Table 3. 20: View Message use case Description.

33
3.4.2. Sequence Diagram
The sequence diagram of our system is used primarily to show the interactions between objects
in the sequential order. The main purpose of a sequence diagram is to define event sequences
that result in some desired outcome. Our Sequence diagrams are shows graphically how objects
interact with each other via messages in the execution of a use case or operation. The sequence
diagrams for the above sequence of actions are done as follows.

Login

Figure 3. 2: sequence diagram for Login

34
Create Account

Figure 3. 3: sequence diagram for Create account.

Register Event

Figure 3. 4: sequence diagram for Register Event.

35
Search Resident

Figure 3. 5: sequence diagram for Search event.

Give Certificate

Figure 3. 6: sequence diagram for Give printed Certificate.

36
See Event

Figure 3. 7: sequence diagram for see event.

Logout

Figure 3. 8: sequence diagram for logout.

37
Change Password

Figure 3. 9: sequence diagram for Change Password.

Generate Report

Figure 3. 10: sequence diagram for Generate Report.

38
See Report

Figure 3. 11: sequence diagram for See Report.

Lock Account

Figure 3. 12: sequence diagram for Lock Account.

39
Unlock Account

Figure 3. 13: sequence diagram for Unlock account.

Post news

Figure 3. 14: sequence diagram for post news.

40
Update News

Figure 3. 15: sequence diagram for Update news.

Delete News

Figure 3. 16: sequence diagram for delete news.

41
3.4.3. Activity Diagram
Activity diagrams are used to show how different workflows in the system are constructed, how
they start and the possibly many decision paths that can be taken from start to finish. They may
also illustrate where parallel processing may occur in the execution of some activities.

Login

Figure 3. 17: login activity diagram.

42
Create account

Figure 3. 18: Create account activity diagram.

Lock Account

Figure 3. 19: Lock account activity diagram.

43
Register Event

Figure 3. 20: Register event activity diagram.

Logout

Figure 3. 21: logout activity diagram.

44
Search Resident

Figure 3. 22: Search event activity diagram.

See Event

Figure 3. 23: See event activity diagram.

45
Update Event

Figure 3. 24: Update event activity diagram.

46
Give Printed certificate

Figure 3. 25: give printed certificate activity diagram.

Generate Report

Figure 3. 26: Generate report activity diagram.

47
See Report

Figure 3. 27: See report activity diagram.

Post News

Figure 3. 28: post news activity diagram.

48
Delete News

Figure 3. 29: Delete News activity diagram.

Update News

Figure 3. 30: Update News activity diagram.

49
Change password

Figure 3. 31: Change password activity diagram.

Unlock Account

Figure 3. 32: unlock account activity diagram.

50
Add Kebele

Figure 3. 33: add Kebele activity diagram.

Send Request

Figure 3. 34: send request activity diagram.

51
Send message

Figure 3. 35: send message activity diagram.

View Message

Figure 3. 36: view message activity diagram.

52
3.4.4. Class diagram
Class diagrams show the static structure of the model, in particular, the things that exist (such as
classes and types), their internal structure, and their relationships to other classes.

Figure 3. 37: class diagram.

53
3.4.5. User Interface Prototyping

Wosagn Kunetoch Management System website has user friendly user interfaces for its users. It
eases interaction and understanding of the system for different users from their electronic
devices. There are many services in the System The overall structure of the application is
relatively simple, as shown in the following diagram.

Figure 3. 38: user interface prototype diagram.

54
3.4.6. User Interface Design

User interface design is the overall process of designing how a user will be able to interact with a
system. The goal of user interface design is to make the user's interaction as simple and efficient
as possible, in terms of accomplishing user goals.
Some of our designed interfaces are listed below:-
Home Page Interface

Figure 3. 39: user interface design of home page

55
Login Page Interface

Figure 3. 40: user interface design of Login page.

56
Register Page Interface

Figure 3. 41: user interface design of Register page.

57
Reference
1, Federal negarit Gazeta of the federal democratice republic of Ethiopia, 19th year No 13
Addis Ababa 31’nd December, 2012.

Appendixes
Question for Vital Event Registration Agency:-

 What kind of system are used know?

 How the system works?
 What are the problems of the system?
 Who are responsible for managing the system?
 Is customers happy with the system?
 How to give a certificate for the customers?
 Hierarchy of the system.
 Is there a lawyer with in a system?

58
Got Documents image

59
60
61