HAWASSA UNIVERSITY

INSTITUTE OF TECHINOLOGY
FACULTY OF INFORMATICS
DEPARTMENT OF COMPUTER
SCIENCE

Final project I Documentation

Title: - Vital Events management

System
Group members

Biruk Assefa EVCS/033/09

Elsabeth Assefa EVCS/049/09

Kibru Kassu EVCS/077/09

Project advisor: - Degu Belay (MSc)

May 2021
Vital Events Management System
ADVISOR APPROVAL

I approve that this industrial project report entitled “Vital Events

Management System!” by:

Name Signature

Biruk Assefa Amaje

Elsabeth Assefa Workineh

Kibru Kassu Tsigu

is approved by me for submission. I certify further that, to the best of my

knowledge, the report represents work carried out by the students.

Date Signature Name of Advisor

Examining committee members’ Signature

1.

2.

3.

4.

It is approved that this project has been written in compliance with the
formatting rules laid down by the university.

I|Page
Vital Events Management System
Acknowledgement
First of all, we would like to thank Almighty God for leading us throughout
our life journey.
We would also like to thank our course instructors and faculty of Informatics
members for their effort in keeping us here.
Next, we would like to express our special gratitude and thanks for our
advisor Mr. Degu Belay (MSc) for his guidance, comments and suggestions he
has given us and constant supervision as well as his kind co-operation and
encouragement.
Finally, we would like to thank SNNPR ‘wesagn hunetoch’ and Hawassa city
Administration Meneharia sub-city Guwe kebele employees those who
sincerely gave us information regarding the project.

II | P a g e
Vital Events Management System
Acronyms
CR Civil registration

SSN Social security number

PC Personal computer

GHz Gigahertz

CSA Central statistical agency

FMoH Federal ministry of health

RVERAs Regional vital events registration agencies

Html-5 Hypertext Markup Language revision 5

CSS Cascading Style Sheets

JS JavaScript

PHP Preprocessor Hypertext Protocol

MySQL Structural query language

RAM Random Access Memory

VEMS Vital Events Management System

III | P a g e
Vital Events Management System
Table of Contents
Acknowledgement ................................................................................. II
Acronyms ............................................................................................. III
Table of Contents ................................................................................. IV
List of tables ........................................................................................ VI
List of figures ...................................................................................... VII
CHAPTER ONE ............................................................................................. 1
1.1 Background of the study .......................................................................... 1
1.2 Statement of the problem .......................................................................2
1.3 Objectives of the Project .........................................................................3
1.3.1 General Objective ...........................................................................3
1.3.2 Specific Objectives..........................................................................3
1.4 Scope of the Study ................................................................................. 4
1.5 Limitation of the Study .......................................................................... 4
1.6 Methodology .......................................................................................... 4
1.6.1 Data Collection Methodology ......................................................... 4
1.6.2 System Analysis and Design Methodology ..................................... 4
1.6.2.1 System Analysis..................................................................... 4
1.6.2.2 System Design ........................................................................5
1.6.3 System Implementation .................................................................5
1.6.4 Testing and Development Methodology ..........................................5
1.6.4.1 Testing Methodology ..............................................................5
1.6.4.2 Development Methodology .....................................................5
1.6.5 Development Environment ............................................................ 6
1.6.5.1 Hardware tools...................................................................... 6
1.6.5.2 Software tools ....................................................................... 6
1.6.6 System Requirement ......................................................................7
CHAPTER TWO............................................................................................ 8
2.1 Introduction of the Existing System ....................................................... 8
2.2 Proposed System Description ................................................................ 10
2.3 Strength of Existing System ................................................................. 10

IV | P a g e
Vital Events Management System
2.4 Weakness of Existing System ............................................................... 10
CHAPTER THREE ....................................................................................... 12
3.1 Introduction ......................................................................................... 12
3.2 Functional Requirements...................................................................... 12
3.3 Non-Functional Requirements .............................................................. 13
3.4 Analysis Models ................................................................................... 14
3.4.1 Use Case Diagram ........................................................................ 14
3.4.2 Sequence Diagram .......................................................................24
3.4.3 Activity Diagram .......................................................................... 37
3.4.4 Class diagram .............................................................................. 43
3.4.5 User Interface Design ................................................................. 44
CHAPTER FOUR .........................................................................................45
4.1 Introduction .........................................................................................45
4.2 Purpose of the System Design Document ..............................................45
4.3 Scope of System Design ........................................................................45
4.4 Architectural Design ............................................................................45
4.4.1 Logical View of the Architecture ..................................................45
4.4.2 Process View ................................................................................45
4.4.3 Deployment View ........................................................................ 46
4.5 Database Design .................................................................................. 48
CHAPTER FIVE .......................................................................................... 49
5.1 CONCLUSION ....................................................................................... 49
5.2 RECOMMENDATION ............................................................................ 49
References ................................................................................................ 50
Appendix ................................................................................................... 51

V|Page
Vital Events Management System
List of tables
Table 1 : - Maximum number of days it takes for copies of the current event
records to reach CSA ................................................................................... 9
Table 2: - Login use case description .......................................................... 15
Table 3: - Register use case description ..................................................... 16
Table 4: - Search use case description ........................................................ 17
Table 5: - Profile use case description ........................................................ 18
Table 6: - Give feedback use case description ............................................. 18
Table 7: - View feedback use case description ............................................ 19
Table 8: - Generate statistics use case description ..................................... 19
Table 9: - Request for update use case description .................................... 20
Table 10: - Update request use case description ......................................... 21
Table 11: - Create account use case description .......................................... 21
Table 12: - Delete account use case description .......................................... 22
Table 13: - Logout use case description ...................................................... 22
Table 14: - Actors and their roles ...............................................................24

VI | P a g e
Vital Events Management System
List of figures
Figure 1: - Use case diagram ...................................................................... 23
Figure 2: - Sequence diagram of login ........................................................ 25
Figure 3: - Sequence diagram of registration..............................................26
Figure 4: - Sequence diagram of search ...................................................... 27
Figure 5: - Sequence diagram of profile .................................................... 28
Figure 6: - Sequence diagram to give feedback ...........................................29
Figure 7: - Sequence diagram to view feedback ......................................... 30
Figure 8: - Sequence diagram to generate statistics ................................... 31
Figure 9: - Sequence diagram to request correction ................................... 32
Figure 10: - Sequence diagram to update correction ................................... 33
Figure 11: - Sequence diagram to create account ........................................ 34
Figure 12: - Sequence diagram to delete account ........................................ 35
Figure 13: - Sequence diagram to logout ..................................................... 36
Figure 14: - Activity diagram for login ....................................................... 37
Figure 15: - Activity diagram for registering event ..................................... 37
Figure 16: - Activity diagram for search .....................................................38
Figure 17: - Activity diagram for profile .....................................................38
Figure 18: - Activity diagram for give feedback .......................................... 39
Figure 19: - Activity diagram for view feedback ......................................... 39
Figure 20: - Activity diagram for request correction ................................. 40
Figure 21: - Activity diagram for generate statistics .................................. 40
Figure 22: - Activity diagram for update correction .................................... 41
Figure 23: - Activity diagram for create account ........................................ 41
Figure 24: - Activity diagram for delete account ........................................42
Figure 25: - Activity diagram for logout .....................................................42
Figure 26: - Class diagram ......................................................................... 43
Figure 27: - Deployment diagram ............................................................... 47
Figure 28: - Database design ..................................................................... 48

VII | P a g e
Vital Events Management System

CHAPTER ONE

INTRODUCTION

1.1 Background of the study

While the registration of all vital events is a fundamental responsibility of
government, this responsibility is not being carried out legally in our country
for many years.
In the past, the absence of a legal framework for a national vital events
registration and vital statistics system has resulted in uncoordinated practices
of producing civil status evidence. For instance, birth, death and marriage
certificates were issued by hospitals, churches and municipalities in an un-
systematic and fragmented manner.
In response to the situation, the Government of Ethiopia in 2012 adopted a
comprehensive law governing the institutional and operational framework of
vital events registration. This includes the registration of birth, death,
marriage, divorce and complimentary notations of birth such as adoption,
acknowledgment and judicial declaration of paternity.1
Besides according to Health Metrics Network Framework and Standards for
Country Health Information Systems, in most countries health information
systems rarely function systematically. Civil Registration (CR) is one
component of the health information system. In the developed world,
information on vital events is routinely collected nationally to inform
population and health policies. Reliable mortality statistics, the cornerstone
of national health information systems, are necessary for population health
assessment, health policy and health service planning, program evaluation
and epidemiological research.2

1
https://unicefethiopia.wordpress.com/tag/vital-events-registration/
2
https://www.researchgate.net/publication/220260215_Developing_Health_Information_Systems_in_Developing
_Countries_The_Flexible_Standards_Strategy

1|Page
Vital Events Management System
In addition, vital events registration is an important pre-requisite for
measuring equity, monitoring trends and, evaluating impact and outcomes of
broader development programs, such as the Sustainable Development Goals.
And is essential for compiling statistics that are required to develop policies
and implement services. The demographic data generated from such a system
is critical for government planning and decision making. This is particularly
important in areas such as child mortality, maternal health and gender
equality.3
Currently, in our country all regional states and city administrations have
established offices down to the lowest administrative level. ‘Kebele’ general
managers are acting as civil status registrars and all of them have received
training regarding the fundamentals, rules, and regulations of vital events
registration. In addition, the required registry and certificates are printed and
distributed. In order to undertake the registration process smoothly, various
actors from government and other stakeholders are playing key roles, but the
community has the primary role to play by registering vital events within the
prescribed time (birth within 90 days; marriage, divorce and death within 30
days). However, since the current system by itself is not enough, it is intended
to change the current situation in this system.

1.2 Statement of the problem

Currently, information of vital events is registered in the form of paper and
pen-based system. It can be easily damaged by disasters like fire, flood, earth
quake and others.
It affects day to day activities of ‘kebele’ as well as ‘woreda’ to find individuals
file from store this led to problem of lack good governance and it takes long
time to find.

3
https://unicefethiopia.wordpress.com/tag/vital-events-registration/

2|Page
Vital Events Management System
At this time paper-based system considered as a traditional approach to
organize and manage bulky data and is also not suitable for handling. Many
modern approaches like database are introduced to deal with this bulky file,
which is easier and optimal for these problems. As well as it takes a lot of
resource (human resource, money, material resource) and time consumption.
In addition, this manual based system doesn’t provide data sharing among
different representative registrars, this cause duplication of data in different
representative registrars, and information retrieving takes a lot of time. This
led us to unorganized work and increase the work load on government
employees. And additionally, the information collected is subject to security
inquiries.
Furthermore, related with current situation of our country to reduce the
spread of COVID19.

1.3 Objectives of the Project

1.3.1 General Objective

The general objective of this Project is to develop a web-based application
that helps for vital events registration.

1.3.2 Specific Objectives

➢ Identify functional and non-functional requirements.
➢ Design integrated vital events registration system.
➢ Create information sharing among kebele, woreda, zone, region,
federal and other government or private organization.
➢ Assign social security number for citizens.
➢ Provide detail information about citizen for authorized offices.
➢ Design the system so as to be able to generate reports based on
required query.

3|Page
Vital Events Management System
1.4 Scope of the Study
The scope of the study focuses mainly on the design and development of vital
events management system that
➢ Register individual’s information through internet.
➢ Provides certificate for events.
➢ Information can be accessed in nationwide.
➢ Organizations like police station, election board, insurance and banks
can get individuals and statistical information

1.5 Limitation of the Study

➢ In order to use this system, user needs to have basic computer
knowledge.
➢ Requires internet connection.

1.6 Methodology

1.6.1 Data Collection Methodology

The first and the most valuable data source is SNNPR ‘wesagn hunetoch’
office which work on registration of vital events. Therefore, our main
source of information is ‘wesagn hunetoch’ and at Guwe ‘kebele’ they also
provided us with the necessary information.

1.6.2 System Analysis and Design Methodology

1.6.2.1 System Analysis

In process of collecting and interpreting facts, identifying the problems,
and decomposition of a system into its components.
We were trying to review how to register and what is required during
registration in ‘wesagn hunetoch’ and at ‘kebele’. Additionally, we are
trying to refer the civil registration law of 2012(registration of vital
events and National Identity Card proclamation NO.760/2012).

4|Page
Vital Events Management System
1.6.2.2 System Design
Here in planning for a new system, design goals of the project are to
improve data management strategy, to make data available when
needed, to narrow the gap occurred during lack of data exchange.

1.6.3 System Implementation

In process of Implementation, ensuring that the information system is
operational the object model will be translated into source code, which
includes implementing the attributes and methods of each object to
function as a single system.

1.6.4 Testing and Development Methodology

1.6.4.1 Testing Methodology

The system will be tested with sample input data sets. in order to
identify any gaps, errors, or missing requirements in contrary to the
actual requirements.
First unit testing will be employed to assure individual modules
functionality to determine if there are any issues. And then
integration testing will be done Upon completion of unit testing to
check the units are to be integrated which gives raise to integration
testing. The purpose of integration testing is to verify the functional,
performance, and reliability between the modules that are
integrated.

1.6.4.2 Development Methodology

Since a system is composed of many different functions, we use the
waterfall system development model because the work we do have
sequential software development process, where progress flows
steadily toward the conclusion through the phases of a project (that
is, analysis, design, development, testing). This model involves a
rigid structure that demands all system requirements be defined at

5|Page
Vital Events Management System
the beginning. Only then after that can the design and development
stages begin.

1.6.5 Development Environment

The system development includes the overview of how the system
activities will proceed and what tools are needed. Here we use
hardware and software tools.

1.6.5.1 Hardware tools

➢ Personal computer (PC) or laptop: almost all tasks of our
project are performed on computer.
➢ USB Flash drive: required for data back-up and transferring of
computer files.
➢ Printer: an output device that prints paper documents.
➢ Stationeries (pen, paper): for writing all necessary
documentations associated with the project.
➢ Note book: to take notes during data collection and for other
documentations.

1.6.5.2 Software tools

➢ MS Word 2019: is a graphical word processing program used
for documentation.
➢ Wondershare EdrawMax: for drawing UML diagrams like use
case and class diagram.
➢ Notepad++ 7.9.2: text and source code editor supports tabbed
editing, which allows working with multiple open files in a
single window.
➢ Html-5: markup language used for structuring and presenting
content on the World Wide Web.
➢ CSS: is the language we use to style an HTML document.

6|Page
Vital Events Management System
➢ JS: is a light-weight object-oriented programming language
which is used by several websites for scripting the webpages.
➢ PHP: is a general-purpose scripting language especially suited
to web development.
➢ MySQL: is an open-source rational database management
system.
➢ Browsers: is application software for accessing web.

1.6.6 System Requirement

➢ Operating system, Graphics card, Display: is not dependent on
any.
➢ Browser: any browser.
➢ Processor: 1 GHz or faster.
➢ RAM: 1 gigabyte (GB)

➢ Hard drive size: 300 GB

➢ Internet connection
All of the above are minimum requirement

7|Page
Vital Events Management System
CHAPTER TWO
DESCRIPTION OF EXSTING SYSTEM

2.1 Introduction of the Existing System

Currently the Central Statistical Agency (CSA) is the main agency for
collecting, compiling and disseminating official statistics, including vital
statistics from population and housing censuses and household surveys. It is
also charged by law to coordinate the country’s statistical activities to ensure
the use of uniform statistical concepts, definitions and classifications nation-
wide. According to the CR law of 2012, the information gathered by the vital
events registration agencies on births, marriages, divorces and deaths are
compiled for statistical purposes and disseminated by CSA.
The Federal Ministry of Health (FMoH) is responsible for notifying the
concerned civil registration office of births and deaths, including cause of
death information, occurring in health facilities. The kebeles record the
events along with the particulars of the events in the civil registers. CSA is
tasked with compiling vital statistics and cause-of-death information from
the copies of registers they receive from the vital events registration agencies
at federal and regional levels.
The civil registration law requires that three detachable copies of the
registration forms reach the Regional Vital Events Registration Agencies
(RVERAs) within 30 days after the date of registration. The RVERAs keep one
copy and transmit the remaining two copies of the records to the federal
organ within another 30 days. The federal agency in turn sends one set of the
registration forms to CSA within 30 days. Taking these dates into account,
the expected time it would take the registers to reach CSA, excluding late
registers, it is set on the table as follows

8|Page
Vital Events Management System
Vital Time for Kebeles RVERAs VERAs Maximum
events registering transmit transmit transmit number of
an event records to records to records to days it
RVERAs VERAs CSA takes to
reach CSA

Birth 90 days 30 days 30 days 30 days 180 days

Death,
marriage 30 days 30 days 30 days 30 days 120 days
and
divorce
Table 1 : - Maximum number of days it takes for copies of the current event
records to reach CSA

Adoption: - is registered in 3 stages

1st from zero to 90 days as Current
2nd from 91-365 days as Delayed
3rd above 365 days/1 year as Existing and transmitting days are the
same as other events.

The time it would take for records emanating from Ethiopian embassies,
Ethiopian ships, or the Ministry of National Defense to reach CSA is shorter
than those indicated above.
In general, it could take up to 6 months for copies of the birth registration
form to reach CSA. For the paper-based registration, it could take up to 3
months to code, edit and key-in data into computers. Compiling and
tabulating the data at different administrative levels could take another 3
months. Given this, it is feasible to produce CR-based vital statistics to
produce least annually.

9|Page
Vital Events Management System
2.2 Proposed System Description
As a system is used to record vital events, such as births, deaths, marriages,
divorces and adoption. This system creates
➢ Permanent record of each event.
➢ Secure individual’s data with recognition of their legal identity.
➢ Generate statistics on population dynamics.

➢ Accessible everywhere and anytime.

➢ Provides certificate for all registered events.
➢ Generate essential statistical information that decision-makers depend
on for policy formulation, planning and implementation, and
monitoring.

2.3 Strength of Existing System

➢ Easier to Customize.
➢ Creates legal documents used to establish and protect the civil rights of
individuals and provides a source of information that can be collected
to provide critical statistics.
➢ Although there is a gap during the transfer but helps to analyze
population trends at any time. Helps to fill the gap between two
censuses related to population composition, size, distribution and
growth.

2.4 Weakness of Existing System

➢ Storage isn't scalable. Unlike electronic system stored on cloud servers,
paper-based system needs physical space for storage purposes.
➢ Lack of backups and limited security.
➢ Paper-based systems need to tones of paper, printers, photocopier,
stationery and other office supplies. These costs result for significant
expense.
➢ Transporting documents is quite complicated, slow and inefficient.

10 | P a g e
Vital Events Management System
➢ If you want to make changes to a paper-based document, you will need
to write all the content again.
➢ In process of working with paper document, collaboration is extremely
difficult. If several departments need to have information of individuals,
they must to have multiple copies printed.

11 | P a g e
Vital Events Management System
CHAPTER THREE

SYSTEM FEATURES

3.1 Introduction
In the chapter above, a base to describe what the proposed system look like
is provided. With that in mind, requirement elicitation is done to identify the
specific requirements in the process of CSA working. As CSA five vital events
(birth, death, marriage, divorce, and adoption) are mandatory, and the task
of registering vital events will be the duties of the lowest administrative
levels (kebele/woreda).
Additionally, the system must to provide a well-organized data storage
system and will bring different organizations in to a pool in which they can
easily share and retrieve data from the system, advanced searches and
generate statistical reports that decreases the load of employees in different
organizations by providing attractive and easy interface to interact with.
Considering the result of requirement elicitation requirements of the
proposed system are set as functional and non-functional requirements.
Functional requirements are defining a function of a system or its component,
where a function is described as a specification of behavior between outputs
and inputs and non-functional requirements are requirement that specifies
criteria that can be used to judge the operation of a system, rather than
specific behaviors.

3.2 Functional Requirements

➢ Register all vital events via internet and provide certificates.
➢ Assign unique registration number using the attributes of an event.
➢ Identification of different users and their roles authenticate and
authorize users.
➢ Update of registered records and change on vital event records
correction, and is possible only if there is a court order.

12 | P a g e
Vital Events Management System
➢ Provide statistical report.

3.3 Non-Functional Requirements

➢ Reliability
The system should be highly reliable. Since the user of the system is
government office, the system will be best in handling errors and
display an appropriate error message in order to minimize system
failures.
➢ Maintainability
The system should be maintainable. Because the interaction between
subsystems will be loosely couple and the interaction between classes
and operations will be highly cohered, changes made on our system such
as adding other functionality shouldn’t affect the existing functionality
of the system.
➢ Compatibility
The system should have to be compatible. Since the system is web based
it must be compatible with any operating system environment, if web
browser installed in the computer and internet connection is available.
➢ Accessibility
The system should be accessible at any time since it is needed in every
time. As the is web-based system, internet connection and platform are
required to be accessible.
➢ Performance
The system should respond within a short period of time. It depends on
the performance of the hardware environment and internet connection
speed. As governmental system it should perform better to maximize
its productivity.

13 | P a g e
Vital Events Management System
➢ Error Handling and Extreme Conditions
Each error that may occur in VEMS will be handled accordingly in order
to reduce the amount of failure. Since users of system are human, they
may make mistakes, each and every input box are going to be handled
according to their type.
➢ Security
These files which are going to be registered in the system have to be
secured and must be kept in a secured manner. To satisfy these, the
system will provide authorization level according to their managing
level and restrict unauthorized access to these files.
➢ Usability
The system should be easy to learn and understandable for the user.
Since system will be developed by considering all Kebeles of the woreda,
all cities of region and all region of the federal, it must be easy to use
and learn. In addition, it will have a user manual that tells the user how
to use the system.

3.4 Analysis Models

3.4.1 Use Case Diagram

Our system includes the following use cases
➢ Login

➢ Register
➢ Search
➢ Profile
➢ Give feedback
➢ View feedback
➢ Generate statistics

➢ Request for correction update

➢ Update requested correction

14 | P a g e
Vital Events Management System
➢ Create account

➢ Delete account
➢ Logout
Use case name Login
Use case identifier VEMS01
Participating actor(s) Police Station employee, Woreda Employee,
Regional admin, Federal admin

Description This use case describes the user login process.

Pre-condition The users must have authorized user name and
password given by Administrator.
Post-condition The user will access the system.
Basic course of action

1. The user sends the request to the server using web browser.

2. The System displays the login page.

3. The user enters username and password and press login button.

4. The system validates the account.

5. The system displays the appropriate home page.

6. The user access the system.

7. Use case end.
Alternative course of action

➢ If the username and/or password is not correct, invalid login message is

displayed.
➢ The user is returned to login screen and re-enters user name and
password.
Table 2: - Login use case description

15 | P a g e
Vital Events Management System
Use case name Register
Use case identifier VEMS02
Participating actor(s) Woreda Employee
Description This use case describes the vital event
registration process.
Pre-condition ✓ The users must to login first.
✓ The registrant must to bring all necessary
information.
Post-condition The individuals registered and certificate must be
issued for registered event up on request.
Basic course of action

1. The user log into the system.

2. User selects registration tab from navigation bar and selects event type
to be registered.
3. The system provides registration form
4. The registrar user fills the form of registration and clicks save
5. The system validates form
6. The system saves or stored registration information on the vital event
database
7. The system prompts for print of certificate and the registrar click on
print button to print out vital event certificate form
8. Use case end.
Alternative course of action

➢ If the registered person is registered before the system notifies and

display that the same data of registrant found
Table 3: - Register use case description

16 | P a g e
Vital Events Management System
Use case name Search
Use case identifier VEMS03
Participating actor(s) Police Station employee, Woreda Employee,
Regional admin, Federal admin
Description This use case describes searching process.
Pre-condition The users must to login first.
Post-condition The system generates search result.
Basic course of action

1. The user log into the system.

2. User selects search tab from navigation bar.
3. The system provides searching form.
4. The users fill the form and clicks search button.
5. The system validates form
6. If valid the system displays result of searched SSN
7. Use case end.
Alternative course of action
6a. If the SSN is not found display not found
Table 4: - Search use case description

Use case name Profile

Use case identifier VEMS04
Participating actor(s) Police Station employee, Woreda Employee,
Regional admin, Federal admin
Description This use case describes process how users see
their profile and change password.
Pre-condition The users must to login first.
Post-condition Users manage their password.
Basic course of action

17 | P a g e
Vital Events Management System

1. The user log into the system.

2. User selects profile tab from navigation bar.
3. The system provides profile page of user.
4. Use case end.
Alternative course of action

➢ If the users click on change password button

➢ The system provides form

➢ The users fill the form and clicks change password button
➢ The system validates form If valid the system changes password and
displays success message.
Table 5: - Profile use case description

Use case name Give feedback

Use case identifier VEMS05
Participating actor(s) Police Station employee, Woreda Employee,
Description This use case will help the user to make contact
and give a feedback to system admins.
Pre-condition The users must to login first.
Post-condition User feedback sent to admin.
Basic course of action

1. The user log into the system.

2. The user clicks Feedback tab.
3. The system display Feedback page
4. The user fills its feedback and press Submit button.
5. Use case end.
Table 6: - Give feedback use case description

18 | P a g e
Vital Events Management System
Use case name View feedback
Use case identifier VEMS06
Participating actor(s) Regional admin, Federal admin
Description This use case will help to collect a feedback from
a user.
Pre-condition The users must to login first.
Post-condition View a feedback.
Basic course of action

1. The user log into the system.

2. The user clicks Feedback View tab.
3. System display/view a feedback.
4. Use case end.
Table 7: - View feedback use case description

Use case name Generate statistics

Use case identifier VEMS07
Participating actor(s) Woreda employee, Regional admin, Federal admin
Description This use case describes how users generate
statistics data.
Pre-condition The users must to login first.
Post-condition Generate statistical data with their privilege level.
Basic course of action

1. The user log into the system.

2. The user clicks statistics tab.
3. The system provides statistical data.
4. Use case end.
Table 8: - Generate statistics use case description

19 | P a g e
Vital Events Management System
Use case name Request for update
Use case identifier VEMS08
Participating actor(s) Woreda employee
Description This use case describes correction request
process.
Pre-condition The users must to login first.
Post-condition Request for correction update.
Basic course of action

1. The user log into the system.

2. The user clicks request update tab.
3. The system provides request for update form.
4. The user fills form and press send request button.
5. The system validates form If valid the request sent to regional admin.
6. Use case end.
Alternative course of action

➢ If the form is invalid error message is displayed.

Table 9: - Request for update use case description

Use case name Update request

Use case identifier VEMS09
Participating actor(s) Regional admin
Description This use case describes correction update
process.
Pre-condition The users must to login first.
Post-condition Update requested correction.
Basic course of action

1. The user log into the system.

20 | P a g e
Vital Events Management System
2. The user clicks update request tab.
3. The system displays request for update page.
4. If there is request to update clicks on update request button.
5. The system provides correction form.
6. The system validates form and updates data.
7. Use case end.
Table 10: - Update request use case description

Use case name Create account

Use case identifier VEMS10
Participating actor(s) Regional admin, Federal admin
Description This use case describes account creating
process.
Pre-condition The users must to login first.
Post-condition Admins create account for new system users.
Basic course of action

1. The user log into the system.

2. The user clicks create account tab.
3. The system displays form.
4. Admins fill form, set the new user privilege level and clicks create
account button.
5. Use case end.
Alternative course of action

➢ If there is account with the SSN the system notifies that there is account
with the SSN.
Table 11: - Create account use case description

21 | P a g e
Vital Events Management System
Use case name Delete account
Use case identifier VEMS11
Participating actor(s) Regional admin, Federal admin
Description This use case describes account deleting
process.
Pre-condition The users must to login first.
Post-condition Admins deletes accounts.
Basic course of action

1. The user log into the system.

2. The user clicks account tab.
3. The system displays all users.
4. Admins select account to be deleted and clicks on delete account button.
5. Use case end.
Table 12: - Delete account use case description

Use case name Logout

Use case identifier VEMS12
Participating actor(s) Police Station employee, Woreda Employee,
Regional admin, Federal admin
Description Used to leave the page.
Pre-condition The users must to login first.
Post-condition Users leave the page.
Basic course of action

1. The user log into the system.

2. The user clicks logout tab.
3. The system displays login screen.
4. Use case end.
Table 13: - Logout use case description

22 | P a g e
Vital Events Management System

Figure 1: - Use case diagram

23 | P a g e
Vital Events Management System
Actors and their role
Name Description Role

Woreda Employees at an Register events, request

employees administrative division update for correction, view
managed by local citizen information by their
government SSN, generate statistics in
woreda level.

Police station Is may be an officer, To prove citizen’s identity,

employees policeman, or a they can search by SSN of
policewoman, is a citizen.
warranted law employee
of a police force in some
administrative division
Regional Admins at regional level At regional level manage
Admins activities, view feedbacks,
generate statistics
Federal admin Top level admin of the Create accounts for regional
system admins, view feedbacks,
control all activities

Table 14: - Actors and their roles

3.4.2 Sequence Diagram

A sequence diagram shows object interactions arranged in time
sequence. It depicts the objects 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.
Here up next there is sequence diagram for each use cases

24 | P a g e
Vital Events Management System

Figure 2: - Sequence diagram of login

25 | P a g e
Vital Events Management System

Figure 3: - Sequence diagram of registration

26 | P a g e
Vital Events Management System

Figure 4: - Sequence diagram of search

27 | P a g e
Vital Events Management System

Figure 5: - Sequence diagram of profile

28 | P a g e
Vital Events Management System

Figure 6: - Sequence diagram to give feedback

29 | P a g e
Vital Events Management System

Figure 7: - Sequence diagram to view feedback

30 | P a g e
Vital Events Management System

Figure 8: - Sequence diagram to generate statistics

31 | P a g e
Vital Events Management System

Figure 9: - Sequence diagram to request correction

32 | P a g e
Vital Events Management System

Figure 10: - Sequence diagram to update correction

33 | P a g e
Vital Events Management System

Figure 11: - Sequence diagram to create account

34 | P a g e
Vital Events Management System

Figure 12: - Sequence diagram to delete account

35 | P a g e
Vital Events Management System

Figure 13: - Sequence diagram to logout

36 | P a g e
Vital Events Management System
3.4.3 Activity Diagram
Activity Diagrams are graphical representations of workflows of
actions.

Figure 14: - Activity diagram for

login

Figure 15: - Activity diagram for registering event

37 | P a g e
Vital Events Management System

Figure 16: - Activity diagram for profile

Figure 17: - Activity diagram for search

38 | P a g e
Vital Events Management System

Figure 19: - Activity diagram for

Figure 18: - Activity diagram for view
feedback give feedback

39 | P a g e
Vital Events Management System

Figure 20: - Activity diagram for request

correction

Figure 21: - Activity diagram for

generate statistics

40 | P a g e
Vital Events Management System

Figure 22: - Activity diagram for Figure 23: - Activity diagram for
update correction
create account

41 | P a g e
Vital Events Management System

Figure 24: - Activity diagram for logout

Figure 25: - Activity diagram for delete account

42 | P a g e
Vital Events Management System
3.4.4 Class diagram
A class diagram models the static structure of a system. It shows
relationships between classes, objects, attributes, and operations.
A class diagram is typically modeled rectangles with three-section:
➢ The top one indicates the name of the class

➢ The middle one lists the attributes of the class and

➢ The third one lists the methods.

Figure 26: - Class diagram

43 | P a g e
Vital Events Management System
3.4.5 User Interface Design
is the point of human to computer interaction and communication
on a device, webpage, or app. User interface of the system is to be
responsive and can perfectly adapt itself to any screen size that it is
interactive, user friendly and easy to learn and not confusing users.

44 | P a g e
Vital Events Management System
CHAPTER FOUR
SYSTEM DESIGN

4.1. Introduction
This is a system design document for Ethiopian vital events management
system all over the country. The document includes the design goal, planned
system design, and object design.

4.2. Purpose of the System Design Document

This document explains the design issues of the overall system and provides
complete overview of the proposed system architecture. It is intended to
capture and express significant architectural decisions made on the system
information needed to administer all citizens of the country.

4.3. Scope of System Design

The Design Scope outlines the general aims and goals of the project design
and lists the major deliverables and milestones. During architectural design
the system should be decomposed onto a set of communicating subsystems.
These subsystems will work together in order to provide overall system
functionalities and also to meet the non-functional requirements.

4.4. Architectural Design

Architectural design is concerned with understanding how a system should
be organized and designing the overall structure of the system.

4.4.1. Logical View of the Architecture

The logical view is concerned with the functionality that the system
provides to end-users.
UML diagrams are used to represent the logical view, and include class
diagrams, and state diagrams.

4.4.2. Process View

Process view deals with the dynamic aspects of the system, explains the
system processes and how they communicate, and focuses on the run time

45 | P a g e
Vital Events Management System
behavior of the system. The process view addresses concurrency,
distribution, integrator, performance, and scalability, etc. UML diagrams
to represent process view include the sequence diagram and activity
diagram

4.4.3. Deployment View

Deployment diagram shows execution architecture of systems that
represent the assignment (deployment) of software artifacts to
deployment targets. It is used to visualize the topology of the physical
components of a system where the software components are deployed.
A deployment diagram is just a special kind of class diagram, which
focuses on a system's nodes. It models the run-time configuration in a
static view and visualizes the distribution of components in an application.
This system is physically distributed across three nodes. These three are
web server, database server and workstations.
➢ The web server contains the interface part of the system, business
logic and application specific protocols.
➢ The database server stores the database to be managed by the
underlying database management system.
➢ At the front end, any user can make request through locally
existing web browser, to access services provided by the system.
The web server provides graphically designed interface to receive request
and it transforms the user(client) request to one or more database queries
to communicate with the database server. Then the database server
returns the result to the web server which is accessible to the end user
through the web browser.

46 | P a g e
Vital Events Management System

Figure 27: - Deployment diagram

47 | P a g e
Vital Events Management System
4.5. Database Design
Database design is the organization of data according to a model. That helps
us to produce database systems that meet the requirements.

Figure 28: - Database design

48 | P a g e
Vital Events Management System
CHAPTER FIVE
CONCLUSION AND RECOMMENDATION

5.1 CONCLUSION
VEMS is designed to improve the registration of critical events nationwide.
This system is a web-based application to serve citizens as well as the
working group of system in different better manner. The benefits of the
system can be summarized as improved the manual system to centralized
online system which generates unique individual citizen’s identification SSN.
While developing VEMS we have gained more knowledge and experience
about the different phases of the software development life-cycle and as a
computer science student, we are motivated to solve lot of problem where we
are.

5.2 RECOMMENDATION
While doing this system as a team we have faced different challenges, but by
the cooperation of all the group members now we are able to reach to the
final result. This system is developed by all the group members through
strongly fought those challenge as much as possible.
Now we recommend to other developers who want to maintain this system,
to add some features which are not completed on this system. Additionally,
to the limitation adding real-time image recognition for police department to
track the criminals and finally if the system scope can also include SSN for
foreigner citizens, it can be better.

49 | P a g e
Vital Events Management System
References
 ወሳኝ ኩነት መመሪያ, Amharic book provided by CSA
 https://www.wikipedia.org/
 https://www.dictionary.com/
 https://crvssystems.ca/country-profile/ethiopia
 https://chilot.files.wordpress.com/2013/04/proclamation-no-760-
2012-registration-of-vital-events-and-national-identity-card-
proclamation.pdf
 https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd
=&cad=rja&uact=8&ved=2ahUKEwiD-
O2TqMbwAhWsQEEAHUqAA2IQFjABegQIBhAD&url=http%3A%2F%2F
etd.aau.edu.et%2Fbitstream%2Fhandle%2F123456789%2F2355%2FK
edir%2520Kamu.pdf%3Fsequence%3D1%26isAllowed%3Dy&usg=AOv
Vaw0tosb11lRdHaQCgSrTTdgl

50 | P a g e
Vital Events Management System
Appendix
 https://getinthepicture.org/sites/default/files/resources/eth_crvs_cas
e_study_2014.pdf
 https://www.unicef.org/ethiopia/press-releases/first-ever-civil-
registration-and-vital-statistics-day-observed-ethiopia

51 | P a g e