Online Vital Registration

ADDIS ABABA UNIVERSITY
SCHOOL OF GRADUATE STUDIES
COLLEGE OF NATURAL SCIENCES
FACULTY OF COMPUTER AND MATHEMATICAL SCIENCES
DEPARTMENT OF COMPUTER SCIENCE
Enhanced Electronic Vital Events Registration System

for Ethiopia (EEVERSE)
Submitted by: Kedir Kamu
A Project document submitted to the School of Graduate Studies

of Addis Ababa University in partial fulfillment of the
requirements for the Degree of Master of Science in Computer
Science
June, 2011
ADDIS ABABA UNIVERSITY
SCHOOL OF GRADUATE STUDIES
COLLEGE OF NATURAL SCIENCES
FACULTY OF COMPUTER AND MATHEMATICAL SCIENCES
DEPARTMENT OF COMPUTER SCIENCE
Enhanced Electronic Vital Events Registration System

for Ethiopia (EEVERSE)
Submitted by: Kedir Kamu
Name and Signature of Members of the Examining Board:
NAME SIGNATURE
1. Dr. Mulugeta Libsie, Advisor _________________
2. _________________
3. _________________
June, 2011
Acknowledgment
First and for most I would like to express my gratitude to my advisor Dr. Mulugeta Libsie, for
deep concern, rigorous comments and suggestions he has given, from the proposal development
to the realization of the project.
Next I would like to extend my very sincere and special thanks to the Central Statistics Agency
office of vital events registration, that provided me with the necessary information and
individuals those were willing for interview.
Lastly, my special gratitude and respects goes to my friends, who have shared their experience,
knowledge, and resources.
i
Table of Contents
1. INTRODUCTION...................................................................................................................1
1.1 Background ....................................................................................................................... 1
1.2 Statement of the problem ................................................................................................... 2
1.3 Objective ........................................................................................................................... 3
1.4 Scope and Limitations ....................................................................................................... 3
1.5 Methodology………………………………………………………………………………. 4
1.6 Beneficiaries ……………………………………………………………………………..... 5
1.7 Overview of the document ……………………………………………………………….. 6
2. LITERATURE REVIEW ........................................................................................................7
2.1 Vital Events Registration ................................................................................................... 7
2.2 Vital Events Registration in Africa .................................................................................. 11
2.3 Vital Events Registration in Ethiopia ……………………………………………………. 13
2.4 Automation of Vital Events Registration ………………………………………………... 15
2.5 Experience of Different Countries on E-Vital Events Registration Systems ……………. 16
2.6 Summary ………………………………………………………………………………… 17
3. THE PROPOSED SYSTEM ................................................................................................. 18
3.1 Functional Requirements ................................................................................................. 18
3.2 Nonfunctional Requirements............................................................................................ 18
3.3 Peseudo requirements ...................................................................................................... 20
3.4 System Models …………………………………………………………………………... 21
3.4.1 Use Cases and Actors ................................................................................................ 21
3.4.2 Class Diagram of EEVERSE ..................................................................................... 24
3.4.3 Sequence Diagram..................................................................................................... 25
ii
4. SYSTEM DESIGN ............................................................................................................... 26
4.1 System Architecture......................................................................................................... 27
4.2 System Decomposition .................................................................................................... 29
4.3 Hardware Software Mapping ........................................................................................... 32
4.4 Persistent Data Management ............................................................................................ 34
4.5 Access Contro Policy ....................................................................................................... 36
5. PROTOTYPE DEVELOPMENT .......................................................................................... 37
5.1 Development Tools .......................................................................................................... 37
5.2 Database Design .............................................................................................................. 37
5.3 Security ........................................................................................................................... 38
5.4 Components ..................................................................................................................... 38
6. CONCLUSION AND FUTURE WORKS ............................................................................. 46
6.1 Conclusion....................................................................................................................... 46
6.2 Future Works ................................................................................................................... 47
REFERENCES ........................................................................................................................ 48
Annex: A .................................................................................................................................. 50
Annex: B .................................................................................................................................. 55
Annex: C .................................................................................................................................. 60
iii
List of Tables
Table 4.1: Access Control Matrix of EEVERSE .................................................................... 36
Table 5.1: Summary of tables in the database ........................................................................ 38
List of Figures
Figure 3.1: Use Case diagram of EEVERSE .......................................................................... 23
Figure 3.2: Class diagram of EEVERSE ................................................................................ 24
Figure 3.3: Sequence diagram of RegisterEvent Use Case ..................................................... 25
Figure 4.1: Architectural model of EEVERSE ....................................................................... 28
Figure 4.2: Subsystem decomposition for EEVERSE ............................................................ 30
Figure 4.3: Deployment diagram of EEVERSE ..................................................................... 33
Figure 4.4: Relational model for EEVERSE .......................................................................... 35
Figure 5.1: Screenshot of Login Page .................................................................................... 39
Figure 5.2: Screenshot of Amharic version Divorce registration page .................................... 40
Figure 5.3: Screenshot of Index Card Generated .................................................................... 40
Figure 5.4: Screenshot of Divorce registration certificate generated ...................................... 41
Figure 5.5: Screenshot of Form to update personal record ..................................................... 42
Figure 5.6: Screenshot of Amharic version birth report generation page ................................ 43
Figure 5.7: Screenshot of English version birth report generation page .................................. 43
Figure 5.8: Screenshot of Document certification Page .......................................................... 44
Figure 5.9: Screenshot of System Administration page with default create account option ..... 45
Figure 5.10: Screenshot of View record Page......................................................................... 45
iv
Figure B.1: Sequence diagram of Login Use Case ................................................................ 55
Figure B.2: Sequence diagram of UpdateRecord Use Case ................................................... 56
Figure B.3: Sequence diagram of ViewRecord Use Case ...................................................... 57
Figure B.4: Sequence diagram of GenerateReport Use Case ................................................. 58
Figure B.5: Sequence diagram of ManageAccount Use Case ................................................ 59
v
List of Acronyms
 ADRN : Adoption Registration Number

 CR: Civil Registration
 CRN : Civil Registration Number
 CRVSS: Civil Registration and Vital Statistics system
 DVRN : Divorce Registration Number
 DRN : Death Registration Number
 EEVERSE: Enhanced Electronic Vital Events Registration System for Ethiopia
 ICT: Information and Communication Technology
 IIS: Internet Information Service
 MRN: Marriage Registration Number
 PISA: Public-Interface Services Application
 RAD: Requirement Analysis Document
 SDD: System Design Document
 SSA: Social Security Agency
 SSL: Secure Socket Layer
 UN: United Nations
 VS: Vital Statistics
vi
Abstract
The age of information brought lots of opportunity to the global economy. E-government is one
of the potential advantages of Information and Communication Technology. E-government is
defined as the delivery of government services and information to the public using electronic
means. Among many of the e-government services, vital event registration application, which is
characterized as Public-Interface Services Application (PISA), is the main e-government
application for the provision of e-government related services and information to the public at
large. Vital event registration is the systematic, continuous, permanent, compulsory and
universal recording of the occurrence and characteristics of vital events (live births, deaths, fetal
deaths, marriages, and divorces) and other civil status events pertaining to the population as
provided by decree, law or regulation, in accordance with the legal requirements in each country.
This project aimed to develop Enhanced Electronic Vital Events Registration System for
Ethiopia, which can handle the five (birth, death, marriage, divorce, and adoption) major vital
events. To address the problem a web-based application which handles birth, death, marriage,
divorce, and adoption is developed. The application serves both in Amharic and English. The
system is designed in such a way to be accessible via the Internet. Customers have access based
on their privilege level. The system enables registration, update of individual records, generating
reports based on the demand of the customer, issuance of certificates and index cards upon
registration of events, certification of vital events documents, and viewing of individual records
for special customers such as court. Object oriented software engineering and ASP.NET 3.5
platform is employed to develop the project.
vii
EEVERSE for Efficient and Effective Public Service Delivery Page 1
CHAPTER ONE
1. Introduction
1.1 Background
The age of information has brought lots of opportunities to the 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 [1]. On the other hand developing countries like Ethiopia are
facing new challenges with their socio-economic development as a result of the up-coming
information age. To satisfy the demand of the current global economic system, developing
countries have to have ICT as a crucial tool and means to eradicate poverty, speedup socio-
economic development, provide effective and efficient public services, implement E-
government, and speed up good governance.
E-government is the delivery of government services and information to the public using
electronic means. ICT is the integral part of e-government. Thus, it brings the government closer
to the people through major improvements in the delivery of government services, and
information provision to citizens and organizations in effective and convenient way [2]. Among
many of the e-government services, vital event registration application which is characterized as
Public-Interface Services Application (PISA) is the main e-government application for the
provision of e-government related services and information to the public at large [3].
Vital event registration is the systematic, continuous, permanent, compulsory and universal
recording of the occurrence and characteristics of vital events (live births, deaths, fetal deaths,
marriages and divorces) and other civil status events pertaining to the population as provided by
decree, law or regulation, in accordance with the legal requirements in each country. Records
from vital event registration system are also the main and preferred source of continuous vital
statistics on live births, fetal deaths, marriages, divorces, legal separations and deaths. Civil
registration is the foundation of a legal system for establishing the rights and privileges of
individuals [4]. Birth registration opens the door for a newborn child to enter into a permanent
identity. A birth certificate is considered as a ticket to citizenship, without which an individual
does not officially exist and therefore lacks legal access to the privileges and protection of a
nation. On the other hand, a death certificate is a mandatory proof for relieving a person from the
entire social, legal and financial obligation and supports his/her family members on having the
property rights and schemes like policy benefits and other entitled privileges [5]. Marriage and

divorce certificates are also proof of officially being married and separated from husband or
wife. Stillbirth registration is the process of certifying unnatural births.
To benefit Ethiopia from the opportunity of civil registration, there were uncoordinated and
unorganized administrative attempts that were targeted on the issuance of marriage, birth, and
death certificate by municipalities. One of the major reasons for such uncoordinated effort is the
lack of adequate human and financial resources that hinder to do coordinated and sustainable
pilot studies that would enable to create national and regional permanent experimental areas of
civil registration and vital statistics systems. However, in the past few years major diversion in
the thinking and practice of civil registration and statistics systems was observed among the
judicial bodies as well as policy makers and planners. Even though there is no mandatory
exercise of civil registration, electronic birth and death registration system is designed by
Tesfaye [6]. But the system lacks a lot of features to meet the goals in the Ethiopian context. The
system is able to handle birth and death events only which are not enough details to get public
services to individuals and provide complete vital statistics. Since the system was designed to be
accessible through the WoredaNet network its access is limited to specific locations and only to
registrars which limits ease of access of the system. It was also designed to work in English
language only but most Ethiopians do not speak English that leads to the need of localization of
the service language of the system. The civil code assignment is also not as such informant
enough to prepare reports using civil code and other criteria. Interfacing with other organizations
or systems is also not considered. Hence, this work is motivated by the lack of the above features
to have a standard vital event registration system in Ethiopia and to enhance the system.
1.2 Statement of the problem

Even though, Ethiopia is among the countries that have not installed national as well as regional
civil registration and vital statistics systems, there were uncoordinated and unorganized
administrative attempts that were targeted on the issuance of marriage, birth and death
certificates by municipalities. Its importance as a rights issue and as part of an information
system for planning and policy formulation is therefore not widely grasped. The practice of birth,
death and marriage certificates being issued by churches, hospitals and municipalities is used as
a replacement of vital event registration. But issuance of certificates is not based on vital events
record. In addition the service delivery is unstructured and manual. Other events such as divorce,
marriage, adoption and stillbirth are not registered yet officially. However, none of these
organizations consider registration to be a prerequisite for issuing certificates. While churches
and hospitals may check with baptismal records and delivery notes to issue certificates,
municipalities rarely require more than some form of identity paper from other sources. In all

cases, the certification process is exposed to falsification, for instance the case of birth is exposed
to falsification of age, identity of the person and their parents, and birth place [5]. Since vital
event registration is not mandatory, permanent, continuous, secured and automated, the records
are not enough to make decisions and considered as confidential records. The government and
different organizations which are badly in need of the report are not able to benefit from the
system. It also contributed a lot for corruption and inefficient public service delivery.
Considering the major diversion in the thinking and practice on civil registration and vital
statistics systems observed among the judicial bodies as well as policy makers and planners,
birth and death registration system for Ethiopia have been proposed. As mentioned in the
previous section, the proposal lacks a lot of features to meet the goal in the Ethiopian context and
to the standard of civil registration systems. To utilize the possible opportunities of automated
civil registration and have standard civil registration in Ethiopia, this enhancement project is
initiated.
1.3 Objectives
General Objective
The general objective of this project is to design and implement enhanced electronic vital events
registration system for Ethiopia.
Specific Objectives
 To include events like marriage, divorce, and adoption to make the system full-fledged.
 To design the system in such a way that can be accessible through the Internet.
 To design the system so as to support both Amharic and English languages.
 To adjust the registration number, to enable handling of attributes to each event.
 To design the system so as to be able to generate reports based on customers’ query.
 To enhance the security of the system.
 To develop the prototype.
1.4 Scope and Limitations

Scope
This project is limited to providing the following features
 Registration via the Internet.
 Access to the system in both Amharic and English languages.
 Include registration and certification of vital events like marriage, divorce and adoption.
 Access to individual records and reports based on privilege level of customers.

 Generate report based on customers’ query.
 Certification of vital event documents.
Limitation
The project has the following limitations
 Doesn’t register vital events like stillbirth, fetal death, annulment and separation.
 Supports access using only Amharic or English languages.
1.5 Methodology
A project, whose purpose is to develop a software system, is composed of a number of activities.
Each activity is in turn composed of a number of Tasks. A Task consumes Resources and
produces a Work Product. A Work Product can be a System, a Model, or a Document. Resources
are either Participants Time, or Equipment. To achieve the goal, these resources need to be
managed in organized manner. The management process has to be guided by the appropriate
methodology. Methodology is a sequence of step - by - step approach that helps to develop the
final work product. To develop the system, object oriented software engineering, which consists
of requirement elicitation and analysis, system and object design, implementation and testing
activities will be employed.
 Requirement Elicitation and Analysis

To identify the functional and non functional requirements of the system, requirement elicitation
and analysis will be done. As a starting point, extensive literature review is conducted to review
the standard, opportunities and experiences of both developed and developing countries on
electronic vital events registration system. To come up with the specific requirements (the data
needed to develop the system and the functional and nonfunctional requirements anticipated by
the customers) for Ethiopian context, data collection will be done, which will cover Central
Statistics Agency, Social Security Agency and individuals. During data collection interview with
open-ended and close-ended questions and document review methods will be employed. The
collected data will be analyzed to produce a model of the anticipated system that is correct,
complete, consistent, unambiguous, realistic, and verifiable.
 System and Object Design

During system design, the design goals of the project will be defined and the system will be
decomposed into smaller subsystems that can be realized thoroughly. Strategies will be selected
for building the system, such as the hardware/software platform on which the system will run,
the persistent data management strategy, the access control policy, and the handling of boundary

conditions. The object design defines custom objects to bridge the gap between the analysis
model and the hardware/software platform defined during system design. This includes precisely
describing object and subsystem interfaces, selecting off-the-shelf components, restructuring the
object model to attain design goals such as extensibility or understandability, and optimizing the
object model for performance.
 Implementation
During implementation, the object model will be translated into source code, which includes
implementing the attributes and methods of each object and integrating all the objects such that
they function as a single system. The implementation activity spans the gap between the detailed
object design model and a complete set of source code files that can be compiled together.
 Testing
The system will be tested to discover as many faults as possible such that they can be repaired
before the delivery of the system by executing the system (or parts of it) with sample input data
sets. First unit testing will be employed to assure each component’s functionality, in which
object design model is compared with each object and subsystem. Finally integration testing will
be done in which combination of subsystems will be integrated and compared with the system
design model. During system testing, typical and exception cases will be run through the system
and compared with the requirements model.
1.6 Beneficiaries
The output of this project is expected to benefit both governmental and nongovernmental
organizations, and citizens including:
 Central Statistics Agency
 Municipality offices
 Immigration
 Courts
 Individuals
 Nongovernmental organizations
 Social Security Agency
 Federal Ministry of Education and Regional Education Bureaus

1.7 Overview of the document
The rest of the document is organized as follows. The second Chapter presents the literature
review conducted to share opportunities, standards, best practices, and experiences on vital
events registration. The third Chapter discuses about the proposed system including functional,
nonfunctional, pseudo requirements, and system models. The fourth Chapter presents the general
system architecture of the proposed system, the qualities that need attention of the developer,
decomposition the system into subsystems, the relational model and access control policy
defined for the system. The fifth Chapter presents the prototype. Finally, Chapter six presents
conclusion and future works.

CHAPTER TWO
2. Literature Review
A number of research papers, workshop reports, conference proceedings, journal papers and vital
event registration systems have been reviewed to share the opportunities, the standards and
experiences on E-vital event registration systems. The practice of both developed and developing
countries are reviewed.
2.1 Vital Events Registration

A vital event is a major change in an individual’s status that leads to a change of population size
and status. There is no consensus among policy makers and demographers as to what specifically
constitute vital events. The UN Definitions of Vital Events include ten possibilities [4]:
1. Live birth: is the complete expulsion or extraction from its mother of a product of
conception.
2. Death: is the permanent disappearance of all evidence of life at any time after live birth
has taken place
3. Foetal death: is death prior to the complete expulsion or extraction from its mother of a
product of conception, irrespective of duration of pregnancy.
4. Marriage: the act, ceremony or process by which the legal relationship of husband and
wife is constituted.
5. Divorce: a final dissolution of a marriage, that is, the separation of husband and wife
which confers on the parties the right to remarriage.
6. Adoption: is the legal and voluntary taking and treating of the child of other parents as
one’s own, in so far as provided by the laws of each country.
7. Legitimization of birth: the formal investigating of a person with the status and rights of
legitimacy, according to the laws of each country.
8. Recognition of parenthood: the legal acknowledgment, either voluntarily or
compulsorily, of the maternity or paternity of an illegitimate child.
9. Separation: is the disunion of married persons, according to the laws of each country,
without conferring on the parties’ right to remarry.
10. Annulment of marriage: is the invalidation or voiding of marriage by a competent
authority, according to the laws of each country, which confers on the parties the status of
never having been married to each other.
Vital registration is the systematic registration of vital events. The United Nations Statistics
Division defines civil registration as “the continuous, permanent, compulsory and universal
recording of the occurrence and characteristics of vital events (live births, deaths, foetal deaths,

marriages and divorces) and other civil status events pertaining to the population as provided by
decree, law or regulation, in accordance with the legal requirements in each country” [15].
Countries tend to define vital events and registration differently. The UN uses “civil registration”
to emphasize the necessity to build legal and administrative institutions for a civil society, in
which the fundamental human rights related to vital events will be systematically protected, and
thus, vital registration will be institutionalized. According to the UN, “civil registration is the
foundation of a legal system for establishing the rights and privileges of individuals. Records
from that system are also the main and preferred source of continuous vital statistics on live
births, fetal deaths, marriages, divorces, legal separations and deaths”. A vital registration system
requires functional, legal, and administrative institutions, literacy and education, adequate
technical infrastructure, and sufficient human and financial resources. In most cases, five major
vital elements are codified in vital registration: birth, death, fetal death, marriage, and divorce
[4].
Unlike censuses that describe the state of the population at a fixed point of time, vital statistics
are collected on a continuous basis and are thus important for the study of population change.
The term, “vital statistics,” refers to the statistical information that can be extracted from the civil
registration system, such as the number and rates of births and deaths, causes of death, and other
measures [7]. The three main data sources of vital statistics are vital registration, population
census and sample surveys. Vital registration is the best source for coherent, reliable and
accountable vital statistics. Vital registration must be universal, continuous, permanent and
compulsory to benefit the maximum from the system. It also has to be operated by a state-run
public institution and that the registration functions include recording of vital events; storing,
safe-keeping and retrieval of vital records; protection of confidentiality; certificate issuing and
other customer services; recording and reporting information on vital events for statistical
purposes; and providing reliable and timely information and data to other government agencies
[8].
Government administrations are the primary beneficiaries from the three major category uses of
civil registration, that is, legal, administration and statistics. Judicial services, including police
and prison administrations and civil and criminal court rulings and proceedings require evidences
of vital event records: birth, death, marriage and divorce certificates at the local administrations
as well as at the center in day-to-day public transactions and administration of legal cases. The
public administration at all levels (local, district, region/state or at the center) uses vital event
records in providing various administrative services, including issuing residence identification
cards that provides facts about the name, date and place of birth and other related personal
information that require accurate birth and death certificates. It is a requirement for local

administrations to maintain databases of individual citizens residing in their jurisdiction in
support of various public services. Local government administrations are meant to be the major
vital statistics data users for preparing, implementing and monitoring of local development plans
and programmes for the sectors under their jurisdiction. In the majority of African countries
more than ever, due to the progressive movement towards decentralized government
administration, local governments are empowered in administering their own socio-economic
and political affairs that urge them to prepare, implement and review their development plans
and programmes. The primary statistical data the local administrations look for are population
size and vital statistics information that are required to update and estimate future population
growth and trends at the community and district levels [9].
The forerunners of national systems were sometimes religious records, such as parish registers in
Europe or temple records in Japan. Although local parish registers were kept by some churches
in Europe from the 14 century onwards, civil or state registration systems did not develop until
the 19 and 20 centuries. Like the parish registers, births, deaths and marriages are recorded in
separate registers, with no cross –referencing. In the 1950s historical demographers used French
parish registers to develop the techniques of family reconstitution. This technique often begins
with a record of a marriage, and then links this with other records showing the dates of birth and
death of the spouses and their children. Sophisticated computer-based techniques of record
linkage are now being used in Europe and North America [10].
A good register system should be continuous, complete, permanent and compulsory. In England
and Wales, the 1837 Act of parliament provided the basis for a national registration system, with
a general registry office headed by the Registrar General, and included a provision to record the
cause of death. In Australia, each state and territory has its own registers. In Victoria State, for
example, there is a registry of births, deaths and marriages within the Department of Justice. If
registration is effective and compulsory, as in Australia and similar developed countries, the
registered numbers of births and deaths, together with the most recent census and migration
statistics, enable the calculation of birth and death rates and up-to-date estimates of the
population. Registration provides flow data for demographic analysis, so the data relate to
incidence rather than prevalence. A number of developing countries in Central and South
America have complete vital registration (of births, marriages, and deaths), and countries such as
Mauritius and Fiji have a fairly complete recording. Sri Lanka is one of the few developing
countries in Asia with a compulsory and comprehensive registration system. However, the
difficulties and costs of establishing a complete registration system are so enormous that
registration is unlikely to provide reliable demographic data for most developing countries within
the next few decades [10].

Developed countries have systems in place to register vital events that can be used to measure
the number of births and deaths, with varying degrees of accuracy depending on the level of
maintenance of the registers. Developing countries still do not have complete and reliable
registration systems of births and deaths. Moreover, it appears that over time statisticians have
decreased their use of civil registration systems as the source of vital statistics and have instead
used censuses and sample surveys (with sometimes very large confidence intervals) as the data
source for the vital statistics reported to the United Nations Statistics Division. It is estimated
that the coverage of vital events in the world has not progressed too far from the 50 percent level.
According to information on coverage of birth and death registration systems provided by
countries to the United Nations Statistics Division for the Demographic Yearbook, only 54
percent of countries reported complete coverage for births and 52 percent for deaths for the
period 1995 – 2004. Disparities among regions exist; for example, in Africa the percentage is
much lower with only 16 percent and 9 percent of countries reporting complete coverage for
births and deaths, respectively [11].
The reasons for lack of progress vary. The following problems have been identified as affecting
the availability and quality of vital statistics in many countries [12]:
 Under-enumeration of vital events, for example, omission of registration of births when
the newborn dies a few days after birth.
 Misreporting of information, such as the misreporting of age at death or the cause of
death.
 Changes in the legal/administrative framework, for example, changes in registration
procedures or problems with deficiencies in the registration law such as failure to make
registration compulsory.
 Problems associated with the organization of the civil registration systems, for example,
problems in the exchange of information with Hospitals, Ministries of Health and
Statistics, or other administrations, and the failure to coordinate their roles (moreover,
statisticians rarely have full control of civil registration systems).
 General lack of awareness of the need to register, or lack of incentives to register. (The
costs to individuals for making an effort to register an event may outweigh the perceived
benefits of registration).
 Lack of political support at the highest levels of government for civil registration
improvement projects and lack of long-term budgetary funding.

2.2 Vital Events Registration in Africa
Today, it is becoming more evident that every African nation is suffering from the effects and
consequences of a lack of reliable and routine population and health statistics due to the absence
of complete civil registration systems. Absence of routine population dynamics information has
affected the preparation of current population estimates and the updating of population
projections. This has resulted in limited use of national census data and lack of reliable statistics
for the designing, implementation and monitoring of development policies and programs. On the
other hand, most Millennium Development Goal (MDG) health indicators, including infant and
under-five mortality rates, maternal mortality ratios and cause-specific death rates, are being
affected by the absence of reliable and current mortality measures [4].
Every nation in Africa seeks its civil registration to be complete and the vital statistics data to be
high quality. However, the past four to five decades efforts and improvement initiatives have not
resulted in the required level of completeness in terms of geographic coverage, content and
quality of information of the civil registration and vital statistics systems in the majority of the
countries. Various UN agencies, donor communities and governments have extended resources
to many African countries in support of projects and pilot or model programs designed to
improve civil registration systems. In parallel, various intervention programmes and alternatives
or interim methods and techniques have been developed, tested and applied in different parts of
Africa aimed at generating qualified vital statistics data. These long-years of engagements
without tangible development results have created frustrations among the major development
partners, experts and focal national institutions that resulted in ignorance and stagnation at the
national level in most parts of Africa [9].
Problems hampering development of civil registration in Africa include:
 Infrastructure
 Organization and management of the registration process
 Capacity constraints
 Legal framework
The African experts’ groups on statistics and vital registration forwarded the following
recommendations for the improvement of civil registration and vital statistics in Africa [14]:
 Countries should explore the possibility to enshrine civil registration in national constitutions
and charters, given its importance for public policy, good governance, human rights, rights of
children, and as a basis for reliable vital statistics.
 Countries should revisit and update their civil registration and vital statistics (CRVS) laws
and statistical legislation in line with United Nations guidelines and recommendations, to

improve CRVS programmes; evidence-based legislative drafting techniques should be used
to draft and revise comprehensive organic law, subsidiary rules/administrative regulations,
and operational manuals.
 Countries should adopt laws and policies that ensure timely and compulsory
registration of vital events occurring within their national territories, with guarantees for
equal access to the system for all persons, regardless of nationality, immigration or marital
status, including refugees, internally-displaced persons and marginalized populations.
 Countries should develop strategies to derive vital statistics from the registers, including
regular publication and dissemination of the statistics, with due regard to privacy and
confidentiality of personal information.
 Countries should allocate adequate financial and human resources to support civil
registration and vital statistics systems.
 Countries should revisit the issue of fees, and consider free registration of vital events, as
well as free issuance of certificates, specifically for first time current registration.
 Countries should establish systematic and scientific methods and procedures for monitoring
and evaluation of civil registration and vital statistics systems.
 Countries should develop appropriate instruments, techniques and accessible procedures for
registering vital events that were not immediately registered on occurrence, as well as make
provision for back-logged registration.
Creating demand for birth, death, adoption, marriage, fetal death, stillbirth, and divorce records
is one aspect of promoting the values and functions of civil registration records. However,
demand should be followed and accompanied with the actual use of the records for the intended
purpose. Users of vital records vary and range from individuals to national governments and
international organizations depending on the type and purpose of vital events. The mode of
application and use of the records also vary depending on the type of services intended to be
used: for legal or administrative or statistical purposes. The civil registration authority or office
should take as one priority responsibility the facilitation of the use of vital event records and the
certificates by the various beneficiaries beyond managing the registration and certification
operations. To facilitate the use of vital records, the following bodies can play crucial role [9]:
 Courts and other judicial bodies

 Health institutions and health workers
 Schools and the education system
 Residence identification issuers and identity system managers
 Agencies engaged in assigning unique identity numbers for citizens
 Immigration offices

 Social services and welfare administration bodies
 Pension administration offices
 Land administration offices
 Election commissions and offices
 Emergency and preparedness offices
 National statistics offices
2.3 Vital Events Registration in Ethiopia

Ethiopia is among the countries that have not established national as well as regional civil
registration and vital statistics systems. One of the prior requirements for the establishment of a
civil registration system in any country is the formulation of compulsory civil registration law.
Alongside the law, it is necessary to setup the civil registration and vital statistics administration
or organization. With respect to the registration law, even though Ethiopia has not made
adequate attempts to devise an independent civil registration law in the past, several articles on
the procedures for reporting of the occurrence of vital events, organizational structure, storage,
and similar other components of the registration activity were incorporated in the 1960 Ethiopian
Civil Code. The vital events that were referred in the Civil Code were birth, death and marriage.
Although the Civil Code has incorporated articles on the registration of vital events, the articles
that refer to the registration were stated to remain inapplicable, until such time that it is
proclaimed in the Negarit Gazetta. Since then, the Ethiopian Civil Code was left dormant and
idle with respect to its section on civil registration [13].
Nevertheless, there were uncoordinated and unorganized administrative attempts even before the
1960 civil code that were targeted on the issuance of marriage, birth and death certificates by
municipalities. The registration and certificate issuing that are currently being exercised in major
cities and regional capitals are a continuation of this administrative exercise. They are
administrative services primarily driven by the interest or request of individuals for purposes of
administrative and legal support documents. One of the major reasons for such uncoordinated
effort is the lack of adequate human and financial resources that hinder to do coordinated and
sustainable pilot studies that would enable to create national and regional permanent
experimental areas of civil registration and vital statistics systems. However, in the past few
years major diversion in the thinking and practice of civil registration and statistics systems was
observed among the judicial bodies as well as policy makers and planners [13]. In support of
accepting the need of vital events registration for the success of development, an automated vital
events registration mechanism has been proposed by Tesfaye [6].

Vital event registration system, which is the continuous, permanent and compulsory recording of
the occurrence and characteristic of vital events, is the basis for developing legal, administrative
and statistical information system that protects and safeguards most rights and privileges of
individuals (citizens) endorsed in the numerous conventions and recommendations of the United
Nations (UN). Automating such system will improve the correctness, completeness and
availability of the record and recording process. Also it makes the registered data available not
only to vital statistics but also to other public agencies that are using the information in their
administration. The proposal presented by Tesfaye [6] is also to take these advantages. The
proposal includes the following services:
 Add new and update existing birth and death events of individuals.
 Check supplied data for errors and completeness.
 Provide paper based birth and death report for external institutions on request.
 Automatic issuance of certificates during registration.
 Generate statistical reports on birth and death.
 Authentication of users.
The system is proposed in such a way that can be accessible via the WoredaNet network and
access right is granted to authorized registrars and administrators. Distributed client/server
architecture design is selected so that each region will have its own local administration center of
the system.
Even though this proposal tried to take the advantages of electronic vital events registration, it
has limitations that will hinder to take the possible potential benefits of vital events registration.
The limitations include:
 Ignores other vital events, such as marriage, divorce, stillbirth and adoption.
 Doesn’t provide complete input for vital statistics.
 Its access is limited to via WoredaNet network.
 Access privilege is given only for registrars and administrators.
 The way the distributed architecture used disintegrated the system.
 Doesn’t consider interface to other systems.
 Civil code assignment is not well organized to handle attributes of an event.
 Less consideration of system design issues.
Currently the Central Statistics Agency has established an office which is responsible for vital
events registration system initiation. The office prepared a draft proclamation on both civil
registration and population register. The draft on civil registration proclaims that birth, death,
marriage, divorce and adoption as mandatory events to be certified. It also has a provision that
registration is the duties of kebeles (the lowest administrative unit) and others such as Hospitals,

social associations, Clinics, Churches, and individuals are responsible to inform the occurrence
of vital vents.
2.4 Automation of Vital Events Registration

One distinguishes a computerized civil registration system as the electronic registration and
updating of the civil information linked to individuals of the country in the events of live birth,
death, marriage, divorce, fetal death, annulment, judicial separation, adoption, legitimization and
recognition. Computerization of civil registration will broaden the uses that can be made of the
civil registration system. Linkage of the civil registration system to other computerized systems
will become possible. In both the civil registration system and the Vital statistics system,
issuance of a unique registration or personal identification number should take place at the time
of birth or at the initial registration of an individual. One of the main purposes of
computerization will usually be to enhance the quality of civil registration data and consequently
the quality of the vital statistics. The quality of data can be measured by completeness,
correctness and availability. Computerization alone does not ensure more complete and accurate
data. It may facilitate the registration of data, but it is equally important to improve reporting
procedures. Another vital purpose of computerization is to make the registered data available not
only to vital statistics but also to other public agencies that are using the information in their
administration [15].
The data provided by the civil registration system is passed on to the vital statistics system in two
ways: status extract and changes extract. The status extract is an extract of all data related to
individuals who are registered as "active" in the register at a specific time. The change extract
concerns all relevant changes in the civil registration register, such as births, deaths, marriages
and divorces, during a specified period of time. The more extensive the checking that is
implemented, the higher the quality of data recorded in the register, and thus, the more reliable
and accurate the resulting statistics [15].
Computerizing civil registration will have a number of effects. When computerizing civil
registration systems a different view point is taken. The civil registration system concept focuses
on the individual as the main key to the civil events, information linking of all registrations to the
individual. By establishing this linkage, the civil registration system is from the very first version
prepared for future changes and additions. On the other hand, automation facilitates the
registration process, assures quality of data, provides ease of access of individual records and
statistical data and smoothen the interface between systems which are in need of vital
information [15].

2.5 Experience of Different Countries on E-vital Events Registration Systems
Mauritius has centralized civil registration system, which is used to collect information on live
births, stillbirths, deaths, marriages and divorces. Live births, stillbirths, deaths and marriages are
registered by the Central Civil Status Office (under the Prime Minister’s Office) and divorces are
registered by the Judicial Department (also named Supreme Court of Mauritius). Electronic
registration records are transmitted from the Central Civil Status Office to Central Statistics
office for coding and dissemination. For divorce statistics, summary reports are provided to
Central Statistics office for dissemination. According to the legal requirement, live births are to
be registered within 45 days and stillbirths and deaths are to be registered within 24 hours from
the occurrence of the event. Mauritius’s civil registration system is one of the most successful
and of accepted one in the Southern African Development Community Region with above 90%
birth and death registration coverage. The Civil Status Office is currently working on providing
online registration services in both English and French languages [8].
In Botswana, the civil registration system is centralized and administered by the Department of
Civil and National Registration. Births, fetal deaths and deaths are registered either at the
hospital or municipal offices. The registration of births and deaths is computerized and the
registration records are transferred from the local to the central office electronically. Marriages
are registered manually at the municipal offices and divorces are registered at court offices.
However, only marriage registration records are sent to the central office for processing [8].
Australian Civil registration (vital) records were created by the government and include births,
marriages, and deaths. They are commonly referred to as vital records because they pertain to
critical events in a person’s life. They are an excellent source of information for names, dates,
birthplaces, marriages, and deaths. These records may also include divorce records [17].
In the US state of Minnesota, all births and deaths that occur at home are filed electronically by
entering data in Minnesota's integrated electronic system, which is a client server application
used by hospitals and registrars and a web based application used by funeral directors,
physicians, medical examiners, and coroners [16].
In Ireland, there is an Electronic Civil Registration Service which is used for recording of all life
events such as births, stillbirths, adoptions, marriages and deaths. Registering and producing a
certificate for these events was labor intensive. But, the implementation of an Electronic Civil
Registration Service is at the heart of providing better public services to citizens through the
Government's modernizations action program. The system generates a unique Personal Public
Services Number (PPS No.), which is a permanent personal number to the child that is

automatically allocated at the time of registration and a certificate is issued free of charge and an
electronic birth certificate sent to the Department of Social, Community and Family Affairs to
facilitate the administration of social welfare services. This means that it is necessary to get a
birth certificate in order to claim child benefit [18].
In Norway, the Population Register came under the authority of the Directorate of Taxes in 1991.
The Register uses the national identification number that was introduced in 1964. The number is
composed of the date of birth in combination with three distinguishing digits, and check digits
[15].
2.6 Summary
Having studied related literature and systems developed for vital events registration,
opportunities, limitations, standards, needs and experiences considered are listed below, which
may lead us to better design consideration.
 The name civil registration can be used interchangeably with vital events registration.
 Unique civil code is assigned to individuals registered.
 In most cases five of the vital events, which include birth, death, marriage, divorce, and
adoption are considered.
 E-vital event registration systems of most countries are accessible via virtual private
networks.
 Most of the countries which are using virtual private networks planned to use the Internet
and consider interfacing with other systems.
 There is no well defined standard for vital event registration.
 Developing countries that have planned civil registration are advised to follow the United
Nations publication series on civil registration.
 Certificates are issued for registered vital events.
 In some countries vital registration is not mandatory.
 For the success of vital event registration, well-defined vital registration law and
enforcement of the law is critical.
 Most of vital event registration systems use client server architecture and central
repository.
 Output of most vital event registration systems in developing countries are not complete
to use as input for vital statistics.
 Awareness and implementation of vital event registration system in Africa is negligible.
 Vital events registration is a base for effective planning, good governance and efficient
public service delivery.

CHAPTER THREE
3. The Proposed system

The literature review conducted provided a base to consider the possible opportunities,
limitations, standards, and current status of civil registration generally. It also indicated the major
problems that are hindering development of civil registration in developing countries.
Specifically in Africa being underdeveloped, political instability, less dedication of government,
scarcity of resources and lack of equipped professional made the task of improving status of civil
registration too difficult. Moreover to overcome this complexity experts have forwarded their
recommendations as listed above in Section 2.2.
Having considered the output of literature review, requirement elicitation is done to identify the
specific requirement for Ethiopian context. To identify the requirements, interview and
document review has been conducted with Central Statistics Agency Office of Vital Events
Registration. The agency has recently established an office which is delegated for initiation of
vital events registration system and developed draft proclamation on civil registration and
population register. According to the draft proclamation, five vital events (birth, death, marriage,
divorce, and adoption) are to be mandatory, which serve the minimum requirements to have
standard civil registration. In addition the task of registering vital events will be the duties of the
lowest administrative levels (kebele/woreda). The requirement elicitation has also showed that
central statistics agency doesn’t have as such well studied anticipated output from civil
registration. To measure awareness of individuals interview has been conducted with individuals
and it has shown that the level of awareness on civil registration is negligible. The ICT
development plan document has shown that the government developed strategy to benefit from
E-government. Interview questions are attached as Annex C.
Considering the result of requirement elicitation, standard of vital events registration systems, the
context of the country, and anticipation of customers, requirements of the proposed system are
set. A requirement is a feature that the system must have or a constraint that it must satisfy to be
accepted by the client. The requirement elicitation yielded the specification of the system written
using natural language, so that the client can understand. Analysis of the requirements, which
resulted in an analysis model that can be unambiguously interpreted during development. During
specification of requirements functional, nonfunctional and pseudo requirements are identified.

3.1 Functional Requirements
The system must be able to:
 Register, update and change vital event records via the Internet.
 Operate both in Amharic and English languages.
 Generate reports based on customers’ query.
 Provide different levels of privileges to customers to manipulate the records.
 Automate issuance of certificates for registered events.
 Generate and print index card for each registered event.
 Authenticate vital event certificates/records.
 Assign unique registration number using the attributes of an event.
 Authenticate and authorize users.
3.2 Nonfunctional Requirements

Nonfunctional requirements specification is done to identify aspects that are visible to the user
but not directly related to the functionality of the system. These include constraints on the
performance of the system, its security, its user interface, its documentation, the resources it
consumes, and its quality. This constraints do not have direct impact on the functionality of the
system but, for example if the user interface is not attractive and doesn’t provide options to
navigate easily, users will be frustrated to do their jobs using the system, which may leads to
poor quality service delivery. In case of performance if the system doesn’t respond within a
reasonable latency and provide accurate result, users will not have confidence on their job. In
addition if the system is not well secured, citizens may not be willing to provide accurate
information and customers will not trust the service provided by the system.
User Interface and Human Requirements

o Interaction of users with the system should be through graphical user interface.
o The user interface should be user friendly and attractive.
o The navigation facility should be flexible.
o The user interface should be consistent in terms of format of page, background color, font
and size.
Performance Requirements
o Since the system is web based the performance can be directly affected by the quality of
hardware, robustness of the software and network traffic. So the response time should be
reasonable.

o Reasonable number of concurrent accesses should be enabled.
Quality Requirements
o The system should be available 24 hours of the day with full potential.
o For each action the user performs, the system must prompt to confirm the action
o Reliability of the system should be high.
o The recovery methods should be simple and fast enough.
Hardware Requirements: The system has to be able to run with minimal and reasonable
memory and processing power demand. Since the system is a nationwide application, the server
has to be equipped with devices of super capability. As a web application the concurrent number
of users vary, so to enable handling the worst case the server has to have multiple modems, super
processing capability, large storage capacity, and redundant storage devices.
Security Issues
o All users should be authenticated.
o Strong access right control should be implemented on methods for user with different
privilege level.
o Preferable if Transport Layer Security mechanism is implemented to protect from
eavesdroppers’ during communication.
Error Handling
o The system must be able to validate all input to their assigned value and display
informative message to the user.
o Well structured client side validation should be implemented for ease of functionality.
Documentation Requirements
o The overall development process should be documented including the Requirement
Analysis, System Design, and Implementation details.
3.3 Pseudo requirements

Even though advancement of technological industries is believed to be one of the tools to reduce
poverty, the current technological infrastructure deployment in Ethiopia is not as such enabling
to launch completely automated systems. The low level ICT infrastructure deployment,
penetration and access within public sector throughout the country are the main challenges
imposed on the design of the proposed system. Considering the above constraints, the system has

to provide paper based vital events registration mechanism for remote areas at lowest
administrative levels. The collected records must be updated to the national electronic vital
events registration system by the immediate responsible body and certificates should be issued to
individuals.
Ethiopia is a land of diversified ethnic and cultural compositions with many linguistic groups. It
is also one of the few countries which has its own unique alphabet. Since our languages are not
widely used other than within the country, technologies are being adopted with the most
common language manuals and description. As the other technologies, computer systems are
also adopted with English language. Moreover, Windows operating system doesn’t have
Amharic package which enables to localize websites for Amharic language. The lack of the
above feature is a bottleneck on efficiency of localized services, because it needs localized query
mechanism which may result in higher response time.
3.4 System Models

3.4.1 Use Cases and Actors
Use cases are used during requirements elicitation and analysis to represent the functionality of
the proposed system. Use cases focus on the behavior of the system from an external point of
view. A use case is used to describe a function provided by the system that yields a visible result
for an actor. An actor describes any entity that interacts with the system, such as a user, another
system and the system’s physical environment. The identification of actors and use cases resulted
in the definition of the boundary of the system that is, in differentiating the tasks accomplished
by the system and the tasks accomplished by its environment. The actors are outside the
boundary of the system, whereas the use cases are inside the boundary of the system. The
following Use Cases and Actors are identified for the proposed system called Enhanced
Electronic Vital Events Registration System for Ethiopia (EEVERSE). Use case diagram of
EEVERSE is shown in Figure 3.1.
 Use Cases
- RegisterEvent: allows registration of vital events, generate index card and certificates
of registered event.
- UpdateRecord: allows updating of existing records.
- GenerateReport: generates report based on customers’ query.
- Login: authenticates a user.
- ViewRecord: allows viewing records.

- CertifyDocument: allows issuing certificates for registered events and certifying
issued certificates on request.
- ChangePassword: lets the user to change personal account password.
- ManageAccount: allows managing user accounts like create, delete, update, enable,
disable and change privilege level.
 Actors
- Registrar: is a person who is authorized by the center to register vital events.
- Registrant: a person who is registered by the civil registry and entitled with respective
civil rights.
- System Administrator: a person certified on administering computerized systems.
- Office Manager: a person certified in management and who is assigned to registration
centers or regional Bureaus.
- Customer: can be a person or an organization or a system, which uses the service
provided by the system. It includes citizens with special cases, researchers, hospitals,
regional education bureaus, courts, central statistics agency, social security agency,
ministry of health, government and nongovernmental organizations.

Use case diagram of EEVERSE
Figure 3.1: Use Case diagram of EEVERSE
Details of Use Cases and Actors are attached as Annex A.

3.4.2 Class Diagram of EEVERSE
We used class diagram to describe the structure of the proposed system in terms of objects,
classes, attributes, operations, and their associations. Classes are abstractions that specify the
common structure and behavior of a set of objects in Use Cases. Objects are instances of classes
that are created, modified, and destroyed during the execution of the system. The proposed
system consists Person, Centerstaff, Account, Customer and Registrant classes. The class
diagram will be refined during system design to include classes representing the solution domain.
The class diagram of EEVERSE is shown in figure 3.2.
Figure 3.2: Class diagram of EEVERSE

3.4.3 Sequence Diagram
Sequence diagrams are used to formalize the behavior of the system and to visualize the
communication among objects. Since it is useful for identifying additional objects that
participate in the use cases and describe patterns of communication among a set of interacting
objects, the diagram is developed for each Use Case. An object interacts with another object by
sending messages. The reception of a message by an object triggers the execution of an
operation, which in turn may send messages to other objects. Arguments may be passed along
with a message and are bound to the parameters of the executing operation in the receiving
object. The sequence diagram for the RegisterEvent use case is shown in figure 3.3.
Figure 3.3: Sequence diagram of RegisterEvent use case

Sequence diagrams for the remaining use cases are attached as Annex B.

CHPTER FOUR
4. System Design
During requirement elicitation and analysis phase the services that are intended to be
provided by the system are identified and modeled in such a way that can facilitate
communication among clients, users and developers, but is not detailed at low level how the
tasks will be performed. So by applying standard design strategies, the gap between
specification of requirements and what the system really consists of in terms of functional
components is filled. At this phase, we also specify the mechanism of how to organize the
system internally through hardware-software mapping with the inclusion of persistent data
management. The goal of this phase is to manage complexity by dividing the system into
smaller, manageable pieces. This is done by a divide-and-conquer approach, where we
recursively divide parts until they are simple enough to be handled by one person or one
team.
Design Goals
Defining design goals is the first step of the system design, which identifies the qualities that
the proposed system should focus on. Design goals of the proposed system are inferred from
nonfunctional requirements and elicited from clients. It will help to make better decision
when trade- offs are needed.
 Performance
Response time should be reasonable at any time. It also has to serve all parallel users.
Moreover since the system will be web-based application, it has to demand minimal
memory and reasonable processing power so that any user can access it with available
resources.
 Dependability
The system should be accessible as long as the ISP providers are available. The
system should also be able to prompt the users for supplying user name and password
before appropriate access is granted. Secure Socket Layer security should be
employed to protect from eavesdroppers during communication on the net. Moreover
users may supply invalid input deliberately or because of typing error, so the system
should be able to validate all inputs supplied to the assigned control value and must
handle error using error handling mechanisms so that the user gets informed about the
errors and fix.

 Maintainability: The system should be extensible enough to incorporate additional
functionalities such as registering stillbirth and fetal death without affecting the
general framework of the system. It also should be easily modifiable when
requirements are changed. The programs should be platform independent so that it
can be usable with little modification. Also the code should be written using readable
format for ease of readability.
 End user: The system should provide user friendly and self-explanatory graphical
user interface that eases the interaction of the user with the system. In addition, the
system should support and facilitate work like automatic generating and printing of
certificates and index cards upon registration of events, enabling customers to
generate report based on demand.
4.1 System Architecture
Even though the existing proposal tried to implement the advantages of distributed
information processing and storage, these advantages often come at the cost of more complex
software, degraded performance and weaker security. Since the proposed system is a public
interface service system, it is not supposed to be as such complex and costly in Ethiopian
context as lots of constraints exist. The design of the application also should consider low
level ICT infrastructure installation throughout the country to enable the application
performance. Moreover the records kept by the system are sensitive so that strong security
mechanisms are needed. Considering the characteristics of the application anticipated by the
client, the system is designed to have three-tiered centralized client/server architecture.
Following layered architectural style, the system will have the user-interface level, the
processing level and the data level. The user-interface layer contains all that is necessary to
directly interface with the user, such as display management. The middle tier typically
contains the processing logic. Finally at the bottom, the data level, actually manages the data
that is being acted on. The proposed system architecture is shown in Figure 4.1.

PC Workstations
User EEVERSE Users
Interface
Level
Application Server
Application
Level
EEVERSE Application Services
Database Server
Data Level
EEVERSE Database
Figure 4.1: Architectural model of EEVERSE

4.2 System Decomposition
To reduce the complexity of the solution, the system is decomposed into subsystems based on
functionality, which in-turn consists of a number of solution domain classes. During
decomposition we have tried to achieve low coupling between subsystems so that change or
error on one will not be propagated to the other and there will be a high coherence within a
subsystem. Figure 4.2 depicts the decomposition of the system into subsystems.

User-Interface<<subsystem>>
Login
UpdateRecord RegisterEvent
GenerateReport ViewRecord ManageAccount
Application<<subsystems>>
RegisterEvent
UpdateRecord
Registration IssueCertificate
UpdaterPersonalRecord
Generate
Registration GenerateIndexCard
ViewRecord
Number
ViewRecord
Login
Authentication CertifyDocument
DocumentAuthentication
Authorization
ManageACCount
GenerateReport
CreateAccount
GenerateReport DeleteAccount
UpdatePrivilege
Enable/DisableAccount ChangePassword
DataManagement<<subsystem>>
Store Data
Update Data Retrieve Data
Figure 4.2: Subsystem decomposition of EEVERSE

Subsystems Description
 User-Interface Subsystem: this subsystem provides a means which eases user

interaction with the system. It includes the following subsystems.
o RegisterEvent Interface: allows supplying attributes of vital events to be
registered and display message.
o EventUpdate Interface: allows changing or adding new attributes of existing vital
event record.
o GenerateReport Interface: allows entering filter criteria to generate report and
displays the generated report.
o ViewRecord Interface: allows supplying the required record identification
number and display the corresponding attributes.
o ManageAccount Interface: allows selecting account management tasks and
provides the corresponding facilities to manage user account.
o Login Interface: allows users to supply account details to get access to the
system.
 Application level: this level holds the overall business logic on which the system
depends.
o Login Subsystem: This subsystem authenticates and authorizes a user. It also
grants access to corresponding privilege for authenticated users.
o RegisterEvent Subsystem: register vital events, generate registration number for
registered events, and prepare, print index and certificate for events.
o UpdateRecord Subsystem: search the required vital event record and update
attributes.
o ViewRecord Subsystem: search and return the required vital event record.
o GenerateReport Subsystem: accept filter criteria from customer and return the
corresponding generated report.
o ManageAccount Subsystem: allows the system administrators to perform
account management tasks such as creating new user account, change password,
deleting, enabling, disabling, and updating account details.
o CertifyDocument Subsystem: accepts vital event registration number and display
the corresponding record so that the registrar can certify the document presented
by the registrant.
 DataManagement Subsystem: this subsystem mainly provides persistent data storage
and management facilities; it also executes queries passed by the applications. It is also
responsible for storing, updating, and retrieval of data on demand of subsystems and

maintains consistency of metadata. Data like table description, entry constraints and
application specific metadata are stored at this subsystem.
4.3 Hardware/Software Mapping

As mentioned above, EEVERSE is intended to be Client-Server application that consists of
user interface, processing and data levels. Using this architecture facilitates to support better
security that can be achieved by placing controlling mechanisms at the processing level.
Figure 4.3 depicts the deployment diagram of EEVERSE. 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 like HTTP, FTP and TCP/IP. The database server stores the database to be
managed by the underlying database management system. At the front end, any client 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 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.

Figure 4.3: Deployment diagram of EEVERSE

4.4 Persistent Data Management
Allocating subsystems to hardware nodes enables to distribute functionality and processing. It

also introduces issues related to storing, transferring, replicating, and synchronizing data among
subsystems. Managing persistent data which is going to be used by transactions of the
application is the other task of the design phase. This task constitutes a major part in design of
the proposed system. To define persistent data management of EEVERSE, persistent objects are
identified which include Birth, Death, Marriage, Divorce, Adoption, CenterStaff, Customer and
Account. These objects are persistent because the application is waving around these objects and
it is inferred from the application domain. As the system will store large amount of data and
handle complex queries on attributes of each object, the system uses a relational database. This
relational database provides better abstraction of data. Data is stored in tables that comply with a
predefined type called schema. Each column in the table represents an attribute. Each row
represents a data item as a tuple of attribute values. Several tuples in different tables are used to
represent the attributes of an individual object. Even though the use of a relational database may
introduce a performance bottleneck, the design goals trade off is used for performance and
modifiability. Hence, the classes which were identified in the analysis phase are mapped to a
relational model. Classes such as Account, Staff, and Customer are directly mapped to each
table, but since Registrant class contains subclass like Birth, Death, Marriage, Divorce and
Adoption, it is mapped to a table for each subclass. Figure 4.4 depicts the Relational Model for
EEVERSE.

Figure 4.4: Relational Model of EEVERSE

4.5 Access Control Policy
Since there are multiple users of EEVERSE with different access privileges to different services
and data, the access control policy is presented using access control matrix. The implimentation
of access control policy will enhance the security of EEVERSE at low level. Hence, the various
actors of this system have different access to the classes of the system. This access control is
represented using access control matrix. In the access control matrix, rows represent actors and
columns represent classes. Each cell in the matrix represents access right and list of operations
that can be executed on instance of the class by the actor. An empty cell represents that the actor
is denied access to the corresponding class. The access control matrix defined for the system is
shown in Table 4.1.
Table 4.1: Access Control Matrix of EEVERSE
Actor Class
Registrant CenterStaff Account Customer
Registrar AddEventRecord() ChangePassword()
UpdateEventRecord() UpdateAccountDetails()
EditEventRecord()
DeleteEventRecord()
GeneRateReport()
Registrant ViewPersonalRecord()
Customer GenerateReport() ChangePassword()
ViewReport()
ViewPersonalRecords()
System AddCenterS CreateAccount() AddCustomerRe
Administrator taffRecord UpdateAccountDetails() cord()
() DeleteAccount() UpdateCustomer
UpdateStaff ChangePassword() Record()
Record() EnableAccount() DeleteCustomer
DisableAccount() Record()
Office Manager GenerateReport() ChangePassword()
ViewReport() UpdateAccountDetails()

CHAPTER FIVE
5. Prototype Development
To realize the feasibility and validity of the proposed solution, attributes and methods of the
identified objects are converted to a source code and integrated in such a way that they work
together for common purpose. This process fills the gap between the analysis model and the
anticipated application.
5.1 Development Tools

To develop a prototype which can meet the design goals of EEVERSE, different tools and
platforms have been used. The Microsoft ASP.NET 3.5 platform is used, and consists of the
following.
 Microsoft Visual Web Developer 2008 Express Edition Integrated Development
Environment is used to design and develop the application interface. Since it
provides debugging tools which allows figuring out what is going wrong with the
code and to see what is happening step-by-step, it eases coding. It also has the
advantage of a DataGridView, where we can add columns based on the properties
of the objects the control will contain before we even have to write a line of code.
 C# programming language is employed to write the codes which will be executed
by the server when a client requests a service.
 Microsoft SQL Server 2005 Express Edition is used for data storage and
management, which adds more flexibility and high level abstraction as it provides
fully relational database management system. The use of SQL Server 2005 has also
increased scalability, performance, and tight yet flexible security controls.
 Tavultesoft Keyman Desktop Professional 7.1 Amharic font editor is used to
create Amharic version interfaces.
 Windows 7 is used as an operating system.
 Internet Information Service 7 is configured to enable the secure socket layer
security service.
 Microsoft Office Visio 2003 and Microsoft Office Word 2007 are used for
documentation.
5.2 Database Design

As we have mentioned above, the application uses SQL Server which uses fully relational
database management system. The use of SQL Server guarantees high level abstraction, which
eases writing complex queries on the database and the capability of holding huge amount of

records. It also provides 64-bit processing capability which improves query performance and
critical for server better efficiency. Since the server requires higher processing capability we
may deploy 64 bit machines, in such cases SQL server is compatible for 64 bit processing. The
database of EEVERSE consist 8 tables. The tables are direct mapping of persistent objects
identified. Table 5.1 summarize EEVERSE database.
Table 5.1: Summary of tables in the database.

Table Name No of attributes Primary key
tblBIRTH 15 CRN
tblDEATH 13 DRN
tblMARRIAGE 13 MRN
tblDIVORCE 9 DVRN
tblADOPTION 10 ADRN
tblCUSTOMER 4 CURN
tblSTAFF 4 EMPIDNo
tblACCOUNT 8 UserName
5.3 Security
As a web application to achieve the security needs of the system, the following issues are
considered.
 Since ASP.NET platform is used all ASP.NET codes are executed on the server, and
automatically blocks access to files such as configuration files and source codes, which
improves the security of the system.
 Access control matrix is defined to each actor and the corresponding class access right, to
implement security at low level.
 Strong authentication method to prove the user is whether or not who claims to be and
authorization rules to grant only the allowed services.
 Parameterized database commands are used to prevent SQL injection attack.
 Secure Socket Layer is implemented using test Certificate to secure the communication
on the net.
5.4 Components
The system is composed of seven major functional components namely Login, RegisterEvent,
UpdateRecord, GenerateReport, ViewRecord, CertifyDocument, and ManageAccount
subsystems. Each component is responsible for assigned task and it has its own blocks of codes.

Login: The login component is designed for authentication and authorization of all users. Each
user has unique user name and specified privilege level. An account for each user will be
created by the system administrator and the user will change his/her password. Screenshot of
login page is shown in Figure 5.1.
Figure 5.1: Screenshot of Login page

RegisterEvent: This component is responsible to register Birth, Death, Marriage, Divorce, and
Adoption events, and to prepare and print registration certificate and index card. In addition, it
is responsible to generate a unique identification number to each registered event using its
attributes. The registration can be done using Amharic or English. The index will be prepared
by the language used to register the event. The certificate also will be generated by the language
used to register the event and the corresponding fields will be filled by the registrar so that the
certificate will be in both languages. To generate certificates, cross page posting is used, which
enables to post contents of the source page controls on the target page in simple way.
Screenshot of divorce registration page with registered event, the generated index card, and
certificate prepared are shown in Figure 5.2, Figure 5.3, and Figure 5.4 respectively.

Figure 5.2: Screenshot of divorce registration page
Figure 5.3 Screenshot of index card generated for the above registered event

Figure 5.4: Screenshot of Divorce Registration Certificate generated for an event
registered using the above form
UpdateRecord: This component is designed to search for specific record using registration
number supplied by a customer and update attributes like name and educational status of
specific registrant. Screenshot of UpdateRecord page is shown in Figure 5.5.

Figure 5.5: Screenshot of update Personal Record page
GenerateReport: This module is designed to generate dynamic reports based on customers

query. The module accepts filter criteria to generate the possible report and allows printing the
generated report. Screenshot of GenerateReport pages are shown in Figure 5.6 and Figure 5.7.

Figure 5.6: Screenshot of Amharic version birth report generation page with generated
report
Figure 5.7: Screenshot of English version birth report generation page

CertifyDocument: This subsystem certifies registered vital events on request. Customers can
use the module as a means of verification of vital event document attributes presented to them.
To use this module, the customer must type the URL of the system and login to the system, then
select the certify document link. Up on arrival to the page, the user will supply the registration
number and click on the certify document button and the system will acknowledge whether the
document is authentic or not. Screenshot of document certification page is shown in Figure 5.8.
Figure 5.8 Screenshot of Document certification Page.
ManageAccount: This part of the system is to be used by the system administrator. It enables
the system administrator to create, delete, enable, disable and update accounts. This module
uses tblACCOUNT to authenticate and authorize users. When the system administrator logs in,
it will redirect to account management page. Screenshot of ManageAccount page is shown in
Figure 5.9.

Figure 5.9 Screenshot of System Administrator Page with default create account option
ViewRecord: This module lets special customers to view individual records of vital events on
request. Screenshot of the view record page is shown in Figure 5.10.
Figure 5.10 Screenshot of View record page

CHAPTER SIX
6. Conclusion and Future Works
6.1 Conclusion
The current attitude of government and professionals on vital events registration is encouraging
to take the advantages of the system. Registering the occurrence and characteristics of vital
events is a long term process, which requires enforcing laws, awareness of citizens, cooperation
of institutions, dedication of the government, professional contribution of citizens, and
integration of up-to-date technology. Even though the current technological infrastructure
deployment of Ethiopia is not as such enabling to use fully automated systems, it is inevitable to
use the opportunities of Information and Communication Technology for the successful and
efficient vital statistics development.
In this project we have tried to analyze the standard, opportunities, experiences, and
requirements on vital events registration systems of developing and developed countries.
Considering the specific needs and facts of the country, we have proposed a bilingual Enhanced
Electronic Vital Events Registration system, which can handle birth, death, marriage, divorce
and adoption events. To realize the feasibility and validity of the proposal object oriented
software engineering is used to develop the prototype. Accordingly, the requirements identified
are analyzed and structured using application domain modeling. Then to achieve the
requirements, centralized client/server architecture is selected. Then design goals are inferred
from the non functional requirements set during the requirement analysis. Then the solution
domain is modeled to achieve what the clients anticipate. Finally, the solution domain model is
mapped to a source code to provide a web application which can be accessed via the Internet,
using Visual Studio Web Developer 2008 Express Edition, C#, SQL Server 2005, and
Tavultesoft Keyman Desktop Professional 7.1.
Finally, if the other requirements of vital event registration are in place, the proposed solution
will facilitate the registration, storage, communication, and presentation of vital events with
minimum cost and effort. Moreover, it will provide reliable, complete, and up-to-date input for
vital statistics. Also it will contribute for good governance and addressing the public at large.

6.2 Future Works
The proposed electronic vital events registration system can be enhanced by including the
following feature for better benefits and efficiency.
 To include registering still birth, fetal death, and separation, will contribute for a
complete vital statistics.
 Letting the system to automatically inform the registration of vital events to other
systems like court systems.
 To use XML for better interfacing with other systems.

REFERENCES
[1] Prasanta M., K. Shibuya, A. D. Lopez, F. Coullare, F. C. Notzon, C. Rao, S. Szreter, on

behalf of the Monitoring Vital Events (MoVE) writing group, 2007: Civil Registration
Systems and Vital Statistics: Successes and missed opportunities. The Lancet, Volume 370,
Issue 9599, 1653 – 1663.
[2] http://egovaspac.apdip.net/, Asia-Pacific e-Government Portal, Last accessed on February,
2011.
[3] Satish J. and Leon S., Proceedings, IFIP, Third World Forum for Information Technology,
Addis Ababa, Ethiopia, November, 2007.
[4] Chengzhi Wang, Donald E., Ansley J., 2003: Research paper: International vital statistics: a
resource guide. Collection building, volume 22, number 2, pp 53-59.
[5] Assefa Bequele, Universal Birth Registration: The challenge in Africa, presented on the
Africa Conference on Universal Birth Registration, Mombassa, Kenya,September 26 – 30,
2005.
[6] Tesfaye Ayalew, 2007,”Electronic Vital Event Registration System”, Msc
project, Department of Computer Science, AAU.
[7] UN, Principles and recommendations for a Vital Statistics System,
ST/ESA/STAT/SER.M/19/Rev.2, ISBN 92-1-161439-2, New York, 2001.
[8] UN Report, Workshop on the Improvement of Civil Registration and Vital Statistics in
SADC Region, Blantyre, Malawi, 1-5 December 2008.
[9] Genene Bizuneh, 2010, Operational Guideline, Improving Coverage and Completeness of
Civil Registration System in Africa, Draft, Addis Ababa, Ethiopia.
[10] David Lucas, 2003, “Registration, Administrative, and Qualitative Data”.
[11] Katherine K. Wallman, Suzann K. E., no Date, International Standards for Compilation of
Statistics: The Gap between Standards Adoption and Standards Implementation.
[12] UN Report and documentation, workshop on Civil Registration and Vital Statistics Systems
in Africa, Dareselam, Tanzania, 29 June – 3 July 2009.
[13] Abdulahi Hassen, 2001, Report of Ethiopian Central Statistics Authority, Addis Ababa,
Ethiopia.

[14] Recommendations of the Experts’ Group Meeting on Civil Registration and Vital Statistics,
UN Conference Center, Addis Ababa, Ethiopia, 10-12 august 2010.
[15] UN, Handbook on Civil Registration and Vital Statistics Systems Computerization,
ST/ESA/STAT/SER.F/73, ISBN 92-1-161403-1, New York, 1998.
[16] http://www.health.state.mn.us/divs/chs/osr/birthreg/, Birth Registration and Fetal
Death Reporting in Minnesota, last accessed on October, 2010.
[17] http://www.library.usyd.edu.au/subjects/government/austhist.html, Civil Registration of
Australia, New South Wales 2001, last accessed on January, 2011.
[18] http://www.groireland.ie,Civil Registration Service Modernization Program, Last accessed
on February , 2011.

Annex: A
Description of Use Cases and Actors
Actors Description
 Registrar:
o Has the following role:
- Register vital events
- Update vital records
- Prepare reports
- Certify documents
- Prepare and maintain index cards
- Change personal account password
 Customer:
- View records of individuals
- Collect vital event reports
 Registrant:
- Supply Information about personal vital events
- View Personal vital event records
 System Administrator:
- Maintain details of user accounts
- Manage user accounts
 Office Manager:
o Has the following roles:
- View reports generated
- Prepare reports based on customers requirement
Use Case Description

 Use case name: RegisterEvent
Participating actor(s): Registrar
Description: allows registering vital events
Precondition: the actor must have an account with registrar privilege

Flow of events:
1. Actor clicks login link.
2. The system displays login page.
3. The actor enters user name and password.
4. Click login button [Alt 4].
5. The system provides list of operations
6. The Registrar selects register operation.
7. The system provides registration form.
8. The Registrar fills and submits the form [Alt 8].
9. The system acknowledges and prompts for print of certificate and index card.
10. The Registrar confirm for print.
11. The system acknowledges
[Alt 4]: [if the Registrar doesn’t provide valid account information]
4.1. The system displays the login page with error message.
4.2. Go to 3.
[Alt 8]: [if the Registrar does not fill the form properly]
8.1. The system displays an error message with registration form.
8.2. Go to 8.
Post condition: The individuals should be registered and certificate must be issued for
registerd event.
 Use Case name: UpdateRecord

Participating actor(s): Registrar
Precondition: The person must have Civil Registration Number and the actor must
have an account with registrar privilege
Flow of events:
1. Actor clicks login link.
2. The system displays login page.
3. The actor enters user name and password.
4. Click login button [Alt 4].
5. The system prompts the actor to enter Civil Registration Number of the person.
6. Fill and submit the Civil Registration Number [Alt 6]
7. The system provides the personal vital event record.
8. The actor updates vital events record.
9. The system acknowledges.

[Alt 4]: [if the user doesn’t provide valid account information]
4.1. The system displays the login page with error message.
4.2. Go to 3.
[Alt 6]: [if the user enters invalid Civil Registration Number].
6.1. The system display error message with text box.
6.2. Go to 6.
Post condition: personal vital event record should be updated.
 Use Case name: ViewRecord

Participating actor(s): EEVERSE Customers, Registrants and Registrars
Description: allows actors to view individual vital events record
Precondition: the record must exist in the database and the customer should have
valid account details or Civil Registration Number
Flow of events:
1. The customers or registrars initiates login
2. The system prompts actors to enter account details or Civil Registration Number (CRN)
3. The actor supply account detail or CRN [Alt 3]
4. The system displays the corresponding vital event record
5. The actor closes the page
[Alt 3]: [if the supplied information is invalid]
3.1. The system displays error message with text box
3.2. Go to 3
Post condition: The customer, registrant, registrars must be able to view the vital record
 Use Case name: MangeAccount

Participating Actor(s): System administrator
Description: allows system administrators to create, modify, enable, disable,
delete, and set privileges of user accounts.
Precondition: the actor must have valid account.
Flow of events:
1. The administrator clicks Login link.
2. The system display login form.
3. The actor enter user name and password
4. The Click login [Alt 4]
5. The system displays account management page with list of services
6. The actor selects required service

7. The system displays active page to manage the selected service
8. The actor performs the required task
9. The system prompts for confirmation
10. The actor confirms
11. The system acknowledges[Alt 11]
12. The actor close the page
[Alt 4]: [if the actor doesn’t supply valid account detail]
3.1. The system displays error message with login page
3.2. Go to 3
[Alt 11]: [if the actor needs to manage another account]
12.1. Go to 5
 Use Case name: GenerateReport

Participating Actor(s): registrar, customer, office manager
Description: allows actors to generate report
Flow of events:
1. The actor click login link.

2. The system displays login form.
3. The actor fills username and password.
4. The actor click login [Alt 4].
5. The system display the corresponding service page to the account details submitted.
6. The actor selects Report link.
7. The system displays a page which contains different type of Reports.
8. The actor selects report type.
9. The system display corresponding report generation page.
10. The actor select filter criteria.
11. The system displays the corresponding report to the filter criteria [Alt 11].
4.1. The system displays error message with login page
4.2. Go to 3
[Alt 11]: [if the actor needs to generate another report]
12.1. Go to 8

 Use Case name: ChangePassword
Participating Actor(s): registrar, customer, office manager, system administrator,
Description: allows actors to change password
Flow of events:
1. The actor click login link.

2. The system displays login form.
3. The actor fills username and password.
4. The actor click login [Alt 4].
5. The system display the corresponding service page to the account details submitted.
6. The actor select change password service.
7. The system displays a form.
8. The actor fills the form.
9. The actor click change password [Alt].
10. The system Acknowledges.
4.1 The system displays error message with login page
4.2 Go to 3
[Alt 9]: [if the actor doesn’t supply appropriate information]
9.1 The system displays an error message with new form.
9.2 Go to 8

Annex: B
Sequence diagram of Use Cases
Sequence diagram of Login Use case
Figure B.1: Sequence diagram of Login use case

Sequence diagram for UpdateRecord Use Case
Figure B.2: Sequence diagram of UpdateRecord Use Case

Sequence diagram for ViewRecord Use Case
Figure B.3: Sequence diagram of ViewRecord Use Case

Sequence diagram of GenerateReport Use case
Figure B.4: Sequence diagram of GenerateReport Use Case

Sequence diagram of ManageAccount Use Case
Figure B.5: Sequence diagram of ManageAccount Use Case

Annex: C
Interview questions used for Central Statistics Agency office of vital events
registration
1. What is the current status of vital events registration system in Ethiopia?

2. What does the draft proclamation look like?
3. What are the vital events included in the proclamation?
4. Who will be responsible to register vital events?
5. What will be the responsibilities of citizens, organizations, and associations?
6. Is there any disclosure rule for individual records?
7. What kinds of benefits are anticipated from vital events registration system?
8. Do you have strategic plan to use potential advantages of vital events registration?
9. Do you have any report format that is anticipated from vital events registration system?
10. Do you have sample forms of vital event registration?
Interview questions used for individuals

1. What do you know about civil registration?
2. Do you think vital events registration is necessary? If yes why?
3. Have you ever used vital event registration?
4. What is your attitude towards vital events registration?

Online Vital Registration

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Online Vital Registration

Uploaded by

Copyright:

Available Formats

ADDIS ABABA UNIVERSITY

SCHOOL OF GRADUATE STUDIES

COLLEGE OF NATURAL SCIENCES

FACULTY OF COMPUTER AND MATHEMATICAL SCIENCES

DEPARTMENT OF COMPUTER SCIENCE

Enhanced Electronic Vital Events Registration System

A Project document submitted to the School of Graduate Studies

COLLEGE OF NATURAL SCIENCES

FACULTY OF COMPUTER AND MATHEMATICAL SCIENCES

DEPARTMENT OF COMPUTER SCIENCE

Enhanced Electronic Vital Events Registration System

Name and Signature of Members of the Examining Board:

1. Dr. Mulugeta Libsie, Advisor _________________

1.1 Background ....................................................................................................................... 1

1.2 Statement of the problem ................................................................................................... 2

1.3 Objective ........................................................................................................................... 3

1.4 Scope and Limitations ....................................................................................................... 3

1.6 Beneficiaries ……………………………………………………………………………..... 5

1.7 Overview of the document ……………………………………………………………….. 6

2. LITERATURE REVIEW ........................................................................................................7

2.1 Vital Events Registration ................................................................................................... 7

2.2 Vital Events Registration in Africa .................................................................................. 11

2.3 Vital Events Registration in Ethiopia ……………………………………………………. 13

2.4 Automation of Vital Events Registration ………………………………………………... 15

2.5 Experience of Different Countries on E-Vital Events Registration Systems ……………. 16

2.6 Summary ………………………………………………………………………………… 17

3. THE PROPOSED SYSTEM ................................................................................................. 18

3.1 Functional Requirements ................................................................................................. 18

3.2 Nonfunctional Requirements............................................................................................ 18

3.3 Peseudo requirements ...................................................................................................... 20

3.4 System Models …………………………………………………………………………... 21

3.4.1 Use Cases and Actors ................................................................................................ 21

3.4.2 Class Diagram of EEVERSE ..................................................................................... 24

3.4.3 Sequence Diagram..................................................................................................... 25

4.1 System Architecture......................................................................................................... 27

4.2 System Decomposition .................................................................................................... 29

4.3 Hardware Software Mapping ........................................................................................... 32

4.4 Persistent Data Management ............................................................................................ 34

4.5 Access Contro Policy ....................................................................................................... 36

5. PROTOTYPE DEVELOPMENT .......................................................................................... 37

5.1 Development Tools .......................................................................................................... 37

5.2 Database Design .............................................................................................................. 37

5.3 Security ........................................................................................................................... 38

5.4 Components ..................................................................................................................... 38

6. CONCLUSION AND FUTURE WORKS ............................................................................. 46

6.2 Future Works ................................................................................................................... 47

Table 4.1: Access Control Matrix of EEVERSE .................................................................... 36

Table 5.1: Summary of tables in the database ........................................................................ 38

Figure 3.1: Use Case diagram of EEVERSE .......................................................................... 23

Figure 3.2: Class diagram of EEVERSE ................................................................................ 24

Figure 3.3: Sequence diagram of RegisterEvent Use Case ..................................................... 25

Figure 4.1: Architectural model of EEVERSE ....................................................................... 28

Figure 4.2: Subsystem decomposition for EEVERSE ............................................................ 30

Figure 4.3: Deployment diagram of EEVERSE ..................................................................... 33

Figure 4.4: Relational model for EEVERSE .......................................................................... 35

Figure 5.1: Screenshot of Login Page .................................................................................... 39

Figure 5.2: Screenshot of Amharic version Divorce registration page .................................... 40

Figure 5.3: Screenshot of Index Card Generated .................................................................... 40

Figure 5.4: Screenshot of Divorce registration certificate generated ...................................... 41

Figure 5.5: Screenshot of Form to update personal record ..................................................... 42

Figure 5.8: Screenshot of Document certification Page .......................................................... 44

Figure 5.10: Screenshot of View record Page......................................................................... 45

Figure B.2: Sequence diagram of UpdateRecord Use Case ................................................... 56

Figure B.3: Sequence diagram of ViewRecord Use Case ...................................................... 57