College of Engineering and Technology Department of Computer Science

COLLEGE OF ENGINEERING AND
TECHNOLOGY
DEPARTMENT OF COMPUTER SCIENCE
Title: -Online Vital Event Registration System for Semera City
Prepared BY: Section C Group Members

NAME ID NO
FENTALEM MULE…………….…. 0900607
FIKADE TILAHUN……………….. 0900610
FIRDWES FENTAW ……………… 0900612
MIFTAH MUFTI.…………………...0900708
YOHANNES BUSHO………………0900786
Advisor: Mohammed Oumer (BSc)
Submitted To: computer science department
Submission date 26/05/2012
Semera, Afar, Ethiopia

VITAL EVENT REGISTRATION SYSTEM FOR SEMERA CITY
Acknowledgment
First, we would like to thank God for giving us the strength and patience to start and
finish this project. Next, we would like to thank our advisor Mr. Mohammed Oumer
for his patience unreserved and valuable advises during the process of writing this
document.
We would like to thank those who gave us information for the completion of our
project, to Semera city vital event registration office for their helpful information
sharing.
Finally, our special gratitude and respects goes to our friends, who have shared their
experience, knowledge, and resources
i
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(airport,mass-media ,telecommunication ,weather forecast, ECX etc..), But
currently some services are still managed through the manual system .vital event
registration system is one them .Vital event registration is the systematic, continuous,
permanent, compulsory and universal recording of the occurrence and characteristics
of vital events (births, 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 Vital Events Registration System for Semera city,
which can handle the (birth, death, marriage and divorce) major vital events. The
system enables registration, generating report, certification of vital events, print
registered events and viewing of individual records. So, our aim is to develop a web
based vital event registration system for Semera city with the client/server architected
configuration. This means that there is a central application database to store data.
This system uses Visual studio to create local server and it has the front end with the
web programming language ASP.
ii
Abbreviations
UML………………………………………...Unified Modeling language
ID………………………………………....… …………….Identification
UN………………………………………....……………... United nation
UC………………………………………....………….…..…… Use case
OOD………………………………………...........Object oriented design
OOA………………………………………........Object oriented analysis
GUI………………………………………..........Graphical user interface
ASP…………………………………………………..Active server page
RAM………………………………………….. Random access memory
MB………………………………………............................… Megabyte
GB…………………………………………………………..… Gigabyte
E.C…………………………………………….……. Ethiopian calendar
ECX…………………………………… Ethiopian commodity exchange.
BR……………………………………………………....… Business rule
Table of Contents
CHAPTER ONE.......................................................................................................................1
1.1. Introduction.......................................................................................................................1
iii
1.1.1. Background of the organization..................................................................................1

1.1.2. Introduction about the project.....................................................................................1
1.2. Literature review................................................................................................................3
1.3. Statement of the problem...................................................................................................4
1.4. Objectives..........................................................................................................................5
1.4.1 General Objective........................................................................................................5
1.4.2 Specific objectives: -....................................................................................................5
1.5. Significance of the project.................................................................................................6
The significance of the project is classified into three main parts: -.........................................6
1.6. Scope and limitation..........................................................................................................6
1.6.1 Scope of the project.....................................................................................................7
1.6.2 Limitation of the project..............................................................................................7
1.7. Methodology......................................................................................................................7
1.7.1. Data gathering methodology...........................................................................................7
1.7.2 System analysis and design methodology....................................................................8
1.7.3. Hardware and software tools used for implementation...............................................9
1.7.3.1 Software tools.......................................................................................................9
1.7.3.2 Hardware tools......................................................................................................9
1.7.4 Testing methodology.................................................................................................10
1.7.4.1. Unit testing.........................................................................................................10
1. 7.4.2. Integration testing.............................................................................................10
1.7.4.3 System testing.....................................................................................................10
CHAPTER TWO....................................................................................................................10
REQUIRMENT ELICITATIONS..........................................................................................10
2.1. Overview of the existing system..................................................................................11
2.1.1 Problem of the existing system..............................................................................12
2.1.2. Weakness and Strength of the existing system......................................................12
2.1.3. Business rules of the system..................................................................................13
2.2 Overview of the proposed system.................................................................................14
2.2.1 Functional requirement of the proposed system.....................................................14
2.2.2. Nonfunctional requirement of the proposed system..............................................15
iv
2.2.3 System requirements of the proposed system.........................................................16

2.3. constrains and assumptions..........................................................................................17
2.3.1 Constraints.............................................................................................................17
2.3.2 Assumptions...........................................................................................................18
CHAPTER THREE................................................................................................................18
SYSTEM MODELING..........................................................................................................19
3.1 use case identification...................................................................................................19
3.2 use case diagram...........................................................................................................20
3.2.1Actor specification..................................................................................................23
3.2.2Use case description................................................................................................23
3.3 Sequence diagram.........................................................................................................38
3.4 class diagram................................................................................................................46
CHAPTER FOUR..................................................................................................................48
SYSTEM DESIGN.................................................................................................................48
4 .1Design Goals.................................................................................................................48
4.2 System Decomposition.................................................................................................49
4.4 System Architecture......................................................................................................52
4.3 Deployment diagram.....................................................................................................53
4.5 Persistent Data Management.........................................................................................55
4.6 Access control and security...........................................................................................56
References..............................................................................................................................58
v
List of figures
Figure 1 System use case........................................................................................................21

Figure 2Sequence diagram for login.......................................................................................39
Figure 3 sequence diagram for birth registration...................................................................40
Figure 4 Sequence diagram for marriage registration............................................................41
Figure 5sequence diagram for generate report......................................................................42
Figure 6 sequence diagram for view record...........................................................................43
Figure 7 sequence diagram create account............................................................................44
Figure 8 sequence diagram for add new event.......................................................................45
Figure 9Class diagram.............................................................................................................47
Figure 10component diagram..................................................................................................51
Figure 11 System architecture................................................................................................53
Figure 12deployment diagram................................................................................................55
List of tables
Table 1 software tools...............................................................................................................9

Table 2Hardware tools............................................................................................................10
Table 3 Use case identification...............................................................................................20
Table 4Log in - use case description.......................................................................................25
Table 5Birth Registration Use case description.......................................................................27
Table 6Death Registration - use case description....................................................................28
Table 7 Register marriages - use case description...................................................................29
Table 8Register divorce - use case description........................................................................31
Table 9Update records- use case description..........................................................................32
Table 10Search Residents - use case description....................................................................34
Table 11Manage Account - use case description....................................................................35
Table 12 Create account - use case description.......................................................................36
Table 13 Generate Report - use case description.....................................................................38
Table 14Add Events - use case description.............................................................................39
Table 15View Record - use case description...........................................................................40
Table 16 Access control..........................................................................................................59
vi
CHAPTER ONE
1.1. Introduction
1.1.1. Background of the organization
Ethiopia is one the developing country in east Africa and it has several regional states.
Afar regional state is one of the state found in Ethiopia. The state consists of five
administrative zones, 29 woredas and 28 towns. Semera is one of the cities found in
afar regional state and also it is capital city of afar regional state [1]. Semera has
several kebeles and has different work sectors in every kebele within it. Among these,
vital event registration office is one work sector in Semera city.
Vital events registration in Ethiopia is started In July 28/2008 E.C after long time
preparation [2]. As a result, Semera city vital event registration starts at July 28/2008
E.C. among the vital events decided by UN, Ethiopia accepted to register (birth,
death, marriage, divorce, adoption, recognition of fatherhood and decision of
fatherhood through court). From those events Semera city in Ethiopia basically works
in four of them (birth, death, marriage, divorce).
As a result, Child birth is registered within 90 days after the baby is born and (death,
marriage and divorce) are registered within30 days after the event happen
The work flow of this work sector is similar with the work flow of the Ethiopian vital
event registration agency. So that Samara uses the Ethiopian technology in order to
enhance the socio-economic development of a country and itself.
1.1.2. Introduction about the project
Vital event registration is started before the birth of Jesus Christ by orthodox religion
followers by registering new born babies. After a long time in 1812 E.C vital event
registration is included under the government as one of the governments functions by
France government. At the beginning it was started by registering (birth, death,
marriage, divorce) but now because of the human need for basic, material and
1
spiritual things is growing time to time the united nation posted the following vital
events to be registered those are (birth, death, marriage, divorce, adoption, recognition
of fatherhood and decide fatherhood through court, death of fetus, separating husband
and wife by denying second time marriage and give recognition for children that are
born during marriage time).
Vital event registration is now very important for countries including our country for
various purposes like developing appropriate policies for certain place based on the
registered data, used as evidence for courts and it also used for government planning
and budgeting by providing the exact number of populations. In general, vital event
registration means registering events that are so important or have great impact for
certain country.
But Ethiopia is facing new challenges to its socio-economic development as a result

of the up-coming information age revealed by information communication
technology, because Ethiopia has not well trained and professional citizen who can
use and modify the new technology as compared with developed country. However,
Ethiopia has to have these technologies as a crucial tool and means to speedup socio-
economic developments, provide effective and efficient public service delivery and
speedup good governance.
Vital registration is the continuous, permanent, compulsory, and universal recording

of the occurrence and characteristics of vital events (live births, 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.
To do this using the technology is compulsory in Ethiopia in vital event registration
system.
1.2. Literature review
2
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.
Ethiopia is among the countries that have not established national as well as regional
civil registration and vital statistics systems. 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. In 1960 registration activity
were incorporated in the Ethiopian Civil Code [3]. The vital events that were referred
in the Civil Code were birth, death and marriage. In support of accepting the need of
vital events registration for the success of development, in 2007 Tesfaye proposed an
automated vital events registration system. Automating such system will improve the
correctness, completeness and availability of the record and recording process [4].
The proposal includes the following services:
 Add new and update existing birth and death events of individuals.
 Check supplied data for errors and completeness.
 Automated 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.
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 and divorce.
 Doesn’t provide complete input for vital statistics
 Does not fulfill the requirement of Ethiopian vital event registration.
 Civil code assignment is not well organized to handle attributes of an event.
3
 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 divorce as mandatory events to be
certified. It also has a provision that registration is the duties of kebeles (the lowest
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
N.B The name civil registration can be used interchangeably with vital events
registration.
1.3. Statement of the problem

Currently vital event registration in Semera city record customers in a paper-based
manner. Due to this reason the institution faces too many problems. Some
of problems are listed as follows:
 Papers can be tear apart
 Errors that occur on papers cannot be corrected easily
 Can be damaged easily by accidents
 Low speed and efficiency
 It is difficult to view someone’s profile
 Peoples may leave empty spaces on the registration papers
 Duplication of data
 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.
 It is tedious and time consuming
4
Generally, the current system has a number of problems. These problems are going to
lead the registration office to give unsatisfactory service to the community.
That is why we need a system that finds a way to automate the system using most
recent vital registry technique that is proficient in the developed world. This makes
the services vital registration of Semera city more efficient and technological.
1.4. Objectives
1.4.1 General Objective
The general objective of this project is to develop computerized vital event

registration system for Semera city.
1.4.2 Specific objectives: -
In order to achieve the general objectives, the following specific tasks should be met
together.
 Study the existing system and find out the problem.
 Analyzing and identification of requirements.
 Designing and developing the system using selected tools and techniques
 To Design the proposed system based on the requirement analysis of the

existing system.
 To design the system so as to be able to generate reports based on customers’

query.
 To enhance the security of the system.
 To Deploying the system after the system is tested.
1.5. Significance of the project
The significance of the project is classified into three main parts: -
5
For the employees that work in every stage of registration: -
 It can facilitate the vital event registration system by changing it to more

automated system.
 Help to avoid errors on registering forms of data.
 Effective and efficient data collection because of it is automated.
 Effectively manage data statistically no need to calculate or manually generate

report because the system enables effective statistical data managements.
For government: -
 Government can easily perform national census and categorize population into
different group.
 Government can easily find out why some vital events are occurring more
frequently in some places and also recommends the solution.
 Helps in designing appropriate policy by providing reasonable statistical data.
 Use as evidence in many areas like courts and to eliminate things that are done
arbitrarily like early marriage etc.
 Provides a secure exchange of vital and statistical information.
For end users: -
People can ask their rights using the registered data as evidence. For example: -
 To ask for Keble id card
 To use it as evidence in courts.
1.6. Scope and limitation

1.6.1 Scope of the project
The current system is manual and runs at many stages so our working boundary will
be the overall structure of Semera city vital event registration offices that specially
focuses on registration of birth, death, marriage and divorce events. Our project will
serve for all offices of vital event registration at all stages.
6
This project is bounded to provide the following features:

 The system will do the registration of marriage, birth, divorce, and death.
 The system administrator will create new accounts for actors of the system.
 Events will have their own form to register and can be viewed by actors that
have privilege.
 The system will generate report and give printed certificate if it is necessary.
 Update user’s information
 This system will have well organized central database that is accessible by
every stage employee.
We will try to include features of good system as much as possible.
1.6.2 Limitation of the project
The project has the following limitations

 The system doesn’t use Amharic language.
 It is not available on mobile and tablet, i.e. its run only on computer.
 It is only accessed by person who has computer knowledge.
 The system is not applicable if a connection error occurs.
1.7. Methodology
1.7.1. Data gathering methodology

Data gathering methodologies are methods used to collect different data from
different data sources (documents, users and organizations etc.).
The following are the data collection methods used for requirement gathering Primary
data source for our project
7
Interview: We used interview as one of the major data collection methods. During the
interview we have got different necessary information from the vital event registration
offices. We have interviewed vital event registration coordination officers in Semera
city
Observation: in order to get better information about the system we have got through
the vital event registration process. We have observed the current document which
they used to gathering data from the users. And also, we have observed how their
work is going from the starting to the end.
Document Analysis: we have analyzed different documents and brochure from the
Semera town vital event registration office.
Internet: Internet helps us to see the available samples and to download different
types of tutorials which help us in developing the system.
1.7.2 System analysis and design methodology
Object Oriented Analysis (OOA):-During this phase the team used to model the
functions of the system (use case modeling), find and identify the business objects,
organize the objects and identify the relationship between them and finally model the
behavior of the object.
Object Oriented Design (OOD): -During this phase the team used to refine the use
case model to reflect the implementation environment, model object interactions and
behaviors that support the use case scenario, and finally update object model.
1.7.3. Hardware and software tools used for implementation

1.7.3.1 Software tools
No Name Function of Software tools
8
1 Window 10 Will be used for the system since it is readily available in

operating system laboratories.
2 MS-word 2013 For documenting and presenting the corresponding deliverables
and MS-PPT associated with the project.
3 Visual paradigm Software used for drawing UML diagrams.
16.1
4 ASP Language used for doing project.
5 Visual studio Create a local web server for testing and deployment purposes.
Table 1 software tools
1.7.3.2 Hardware tools
No Name function of Hardware

1 Personal Almost all tasks of our project are performed on computer.
computer(pc)
with all
accessories
2 Flash disk Required for data movement to store & transfer data from
one PC to another PC.
3 Paper and For writing all necessary documentations associated with
pen the project.
Table 2Hardware tools
1.7.4 Testing methodology
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. We will use unit test and integration testing
9
1.7.4.1. Unit testing
Unit testing will be employed to assure each component’s functionality, in which

object design model is compared with each object and subsystem.
1. 7.4.2. Integration testing
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.7.4.3 System testing
System testing is a level of testing that validates the complete and fully integrated
software product. The purpose of a system test is to evaluate the end-to-end system
specifications. System Testing is actually a series of different tests whose sole
purpose is to exercise the full computer-based system [5].
CHAPTER TWO
REQUIRMENT ELICITATIONS
2.1. Overview of the existing system
Vital event registration management 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 Ethiopia. Even if vital events
registration establishes the citizen’s (individual’s) identity (child’s birth and some
10
one’s death, married and divorced) and is generally a perquisite for the issuance of
certificate which is an official, permanent and legal document.
Semera city vital event registration system is the city municipalities in Ethiopia,
which work begin in 2008 E.C. But they performing its tasks manually and there are
many activities that are being done in several procedures and that need intensive
human labor, resource, and time, less security. These are procedures that are present
from registration of each person and each society to different purposes.
The primary responsibility for registering a birth lies with the child’s parent(s) or the
legal certification that shows they are really the parent of the born child. That is, they
should come up with the clinical certification which shows the child is born in
hospital or they should come up with real certification in their kebele. The
responsibility for registering a death lies with a family member (father, mother, sister,
brother), partner, nearest relatives and the real case of the person died from the kebele
of the dyed person. The responsibility for registering a marriage lies with the husband
and wife are legally married. And responsibility for divorce registration lies with
when couples are gone. But the existing system of vital registration system is entirely
manual. As a result, the current system becomes limit in providing services to the
community. This leads citizen of the city waits several days as the likelihood of
finding the required information.
2.1.1 Problem of the existing system
The current vital events registration system has several problems. Some of the major
problems are the following:
 The paper-based registration system is hard to handle.
 It is difficult to view someone’s profile.
 Institutions regularly encounter problems accessing reliable data quickly

at every kebele.
11
 Peoples may leave empty space on registration paper.
 The current system is much time and resource consuming.
 Uses a traditional approach that is subjected to loss and delay of records.
 There is data duplication in the system.
 It takes more time to access the individual data.
Generally, the existing system does not give satisfactory services to the residents.
2.1.2. Weakness and Strength of the existing system
2.1.2.1. Strength of the existing system

 They have an organized structure to facilitate the tasks that are done by
them.
 The existing system not requires internet connection.
 A Distribution of work for the employee
2.1.2.1Weaknesses of the existing system

 The files are only accessed within registrar offices.
 There is no centralized database system.
 It is not computerized.
 Searching someone’s profile is tedious and boring.
 It is not possible to access the system through internet.
 There no way to check if the resident is registered before.
 It needs more resource and time
12
2.1.3. Business rules of the system
A business rule is effectively an operating principle or polices that we try to specify

for the new proposed system must be satisfies included. The main business rules or
principles of the system are: -
BR1: -the user must be members of the kebele
BR2: -The user must be come to registration with full personal description
BR3: -The user must pay the registration payment to the financial office
BR4: -The user could take his/her certificate
BR5: -Only the registrar officer can register the user
BR6: -The user should have to know one user can not register twice
BR7: -The user should come with real case certificate that shows his/her registration
BR8: -The user should have to tell the real age.
BR9: -The user should have the 3*4 photo graph
2.2 Overview of the proposed system
Our proposed system will give up the problems that are being seen in the manual
system of vital event registration system. The project is to design and implement
online vital registration for Semera city. The proposed system will be web-based
application in which the citizen registry is stored in the central database then all
authorized individuals will have access to this central database to record and retrieve
required data and information. As a result, the proposed system will become well-
built in providing services to the community. This makes the individual more
satisfactory on the services provided from his\her Semera city.
13
2.2.1 Functional requirement of the proposed system.
Functional requirements are the intended features of the system. These features may
be expressed as services, tasks or functions that the system is required to perform.
Functional requirement is a function or feature that must be included in an
information system to satisfy the system need and be acceptable by the members [6].
These are statement of service the system should provide how the system should react
to particular input and how the system should behave in particular situation. It
specifies the software functionality that the developer must build in to the product to
enables the user to accomplish tasks.
The following are functional requirement of our project
 The system should able to register vital events.
 The system should be able create a user account, delete a user account and
manage permissions.
 The system should be able to search resident using personal identification

number as well as name.
 The system should be able to generate reports of birth, marriage, divorce,

and death records.
 The system should give a certificate at a time of registration quickly.
 The system should update and change vital event records.
 The system should be to view records of individuals.
 The system should be able to print registered events.
2.2.2. Nonfunctional requirement of the proposed system
Non-functional requirement explains and describes requirements that support the

main of the system that should have but they are not part of the system functionalities.
14
Non-functional requirements are requirements, which are the measurements of the

quality of the system operation [7]. The following are nonfunctional requirements.
 Performance: Since the system is web based the performance can be

directly affected by the quality of hardware, robustness of the software
and network traffic.
 Availability: - the system able to give full time services to its user
without any crash.
 Efficiency: -the system will allow the user to perform activities in an easy
and efficient
 Reliable: -the required data from the system must be accurate related to
the desired one.
 Response time: -the system will operate in a timely manner and should be
able to provide response in short time span.
 Security issue: - in order to make the system safe from unauthorized

users the system used a log in account to differentiate authorized users
from unauthorized users of the system. This enables the system to verify
who has logged in.
 We use two-layer authentication (user name, password)

 We used also session to restrict users from accessing page
without their privilege so we will give session time that it will
expire after the time passes.
 We protect the system from access of external intruders by
using password encryption.
2.2.3 System requirements of the proposed system
Process Requirement
15
The process of our project is accepting inputs, process that input according to the
instruction, finally produces output and displays it. To do those activities use CPU
(Central Processing Unit) capacity of the system for processing purpose, Hardware
and Software devices, Light or power for activating the system, network Connection
Client computer (desktop or laptop any type brand) with full accessories, Network
cable and Server computer.
Input Related Requirements
The proposed system can take input from the authorized user and check the validation
of the input. It also needs correct input to display correct output to end user.
Output Related Requirements
The proposed system can display the appropriate output after the system accepting
inputs from the authorized user and process it according to the instruction.
Storage Related Requirements
The system can store any data inserted in to the system in appropriate manner. The
stored data can be kept in database permanently and can be retrieving easily when the
user accesses it.
Hardware requirement
 The random-access memory (RAM) should be 512MB or higher.
 The system should have a hard disk of at least 50GB.
 An uninterruptable (cut) power supply (UPS) units.
 Printer
Software requirement
 Web browser (Mozilla Firefox, Google chrome, …)

16
 Server computer
2.3. constrains and assumptions

2.3.1 Constraints
Constraint is a restriction imposed by the study sponsor that limits the study team’s
options in conducting the study. Each and every system has some constraints that can
restrict them to work on a particular environment.
 We are entitled for many courses due to this reason we do not enough time to
fully concerned on the project.
 Some kebele officers cannot volunteer to give enough information.
 There is some problem due to the department late to announce project title
accept or reject.
 Failure of electric system and internet connection.
 Lack of enough money to doing properly our project needs materials.
2.3.2 Assumptions
It is a belief of what we assume that are expected to happen during the project's life
cycle.
 The user must have pc or end device that work properly.
 The new system shall permit only authorized members who have the
appropriate right to update, edit and delete the information.
 Nobody should be allowed to login to the system except authorized users who
have user name and password to get into the system.
 User must be good in computer usage and so on
17
CHAPTER THREE
SYSTEM MODELING
System modelling is the process of developing abstract models of the system, with
each model presenting a different view or perspective of that system.it is about
representing a system using some kind of graphical notation, which is now almost
always based on notation of UML. Models help the analyst to understand the
functionality of the system. [8]
3.1 use case identification
USE CASES Identifier
Login UC01
Birth Registration UC02
Death Registration UC03
Marriage Registration UC04
Divorce Registration UC05
Update Records UC06
Search Resident UC07
18
Manage Account UC08

Create Account UC09
Activate Account UC10
Generate Report UC11
Add events UC12
View Record UC13
Update account UC14
Logout UC15
Request information UC 16
Receive request UC 17
Print certificate Uc18
message UC 18
View his/her record UC 19
View report UC 20
View record UC 21
View notification UC 22
Post news UC 23
Deactivate account UC 24
Event registration UC 25
Change password UC26
Table 3 Use case identification
3.2 use case diagram
In the main, our use case modeling describes the proposed functionality of Semera
city vital registration system. The use case diagram shows a collection of use cases,
actors and their associations. It also represents a discrete unit of interaction between
the user and the system, capturing requirements of the proposed system and
presenting the behavior of the system from an external point of view. The following
Use Cases and Actors are identified for the proposed system called Vital Events
registration System for Semera city.
19
20
Figure 1 System use case
21
Use cases
An essential use case of vital registration system consists. These are: -
1. Login: - authenticates a user.
2. Search resident: - Must able to search by using personal ID number as well as

name.
3. Update Records: - allows updating of existing records.
4. Manage accounts: -allows managing user accounts like create, Activate,

Deactivate, and update account.
5. Generate Report: -generates report based on customers’ query.
6. View Records: - allows viewing records.
7. Send message: -giving message
8. print certificate; -print/giving certificate to register residents
9. View his/her record: -allowing residents viewing his/her record.
10. Change password: all actors can change password.
11. Post news: - allows the administer post news.
12. Receive message: to receive messages sent from users of the system.
13. Logout: Any user who wants to leave the system must click the logout menu.
14. Add events: to add new events if proclaimed by law
15. Event Registration: -allows registration of vital events: -birth, death, marriages
and divorces.
16. Print certificate: -prints certificate by customers query
17. View notification: -actors can view new posted by manager
18. View reports: -allow customer to see reports based on their query.
19. Deactivate account: -administrator of system can deactivate selected account.
22
20. Message: -actor can send message to officer.
3.2.1Actor specification
As we ask from Semera vital event registration office employee and as we have seen
from the organizational structures the following are actors of the Semera vital event
registration information management system.
1. Resident: is a person who lives in the specific place and who is going to be
registered and certified.
2. Officer: is a person who is responsible for registering and certifying vital
events.
3. Manager: is a person who responsibility for viewing report and posting news.
4. Administrator: is a person who certified on administering computerized
system, for managing user account.
5. Customers: these are people or originations who requests event information

in vital event organizations they may be courts, statistical organizations etc.
3.2.2Use case description
Use case name Login
Use case identifier UC01
Actor(s) Resident, Officer, Manager, customer and Administrator.
Description This use case describes how each stakeholder login into the System.
Pre-condition They must have username and password.
Post-condition Users login in the system and perform the action based on his/her
privilege
23
Basic course of action
1. The actor sends login request to the system.

2. The System displays the login form to the user.
3. The user enters email/username/ and password then press Login button.
4. The system validates the account.
5. The user accesses the system.
6. Use case end.
Alternative course of action
Alternative course of action A: if the user enters invalid user name and password.
A.1. The system determines that the entered user name and password is invalid.
A.2. The system displays “please enter correct username and password” message.
A. 3. Go to 2.
A.4.Usecase ends.
Table 4Log in - use case description
Birth Registration Use case description
Use case name Birth Registration
Actor Officer
Description This use case describes how new born residents Registered
by officer.
Pre-condition The actor must have an account with officer privilege.
Post-condition The residents will be registered.
24
1. Actor click Event Registration menu item.

2. The system displays Event Registration Menu.
3. The actor selects Birth Registration menu item
4. The system displays Birth Registration form like
5. Actor fills the Birth Registration form and click Submit button.
6. The system checks or validates the form fields.
7. The system acknowledges and prompts for Generate of Birth certificate for evidence.
8. The system registers the resident.
9. The use case ends.
Alternative course of action A: If the Actor enters invalid information.
A.1. The system determines the entered information is invalid.
A.2. The system marks a place of Invalid information.
A.3. Go to 4.
A.4.use case ends.
Table 5Birth Registration Use case description
Death registration table
Use case name Death Registration
Actor Officer
Description This use case describes how deceased residents Register.
25

3. The actor selects Death Registration menu item
4. The system displays Death Registration form like: -
5. Actor fills the Death Registration form and click Submit button.
7. The system acknowledges and prompts for Generate of Death certificate for evidence.
8. The Actor perform intended task.
A.3. Go to 4.
A.4. use case ends.
Table 6Death Registration - use case description
Marriage Registration
26
Use case name Marriage Registration
Actor Officer
Description This use case describes how new couple residents Registered.
Actor click Event Registration menu item.

2. The actor selects Marriage Registration menu item
3. The system displays Marriage Registration form like: -
4. Actor fills the Marriage Registration form and click Submit button.
6. The system acknowledges and prompts for Generate of certificate for evidence.
7. The Actor perform intended task.
Alternative course of action A: If the actor enters invalid information.
A.3. Go to 4.
A.4. use case ends.
27
Table 7 Register marriages - use case description
Divorce registration
Use case name Divorce Registration
Actor Officer
Description This use case describes how divorced residents Registered by

resident and officer.

3. The actor selects Divorce Registration menu item
4. The system displays Divorce Registration form like: -
5. Actor fills the Divorce Registration form and click Submit button.
7. The system acknowledges and prompts for Generate of certificate for evidence.
8. The actor performs intended task.
28
A.3.Go to 4.
A.4.Use case ends.
Table 8Register divorce - use case description
Update Records .
Use case name Update Records
Actor Officer
Description Update vital information for appropriate citizens.
Pre-condition The person must have a unique ID and the actor must
have an account with officer privilege
Post-condition The citizen vital information will be updated if he or she is fittin
29
1. The actor clicks update Records button.

2. The system prompts the actor to enter ID Number of the person.
3. Fill and submit the ID Number
4. The system provides the personal vital event record.
5. The actor updates vital events record. Select the value to be updated as well as new va
and press submit button.
6. The system validates the submitted information
7. After validation, the system stores the updated information.
8. use case end
Alternative course of action A: If the officer enters invalid information
A.1. the system determines that the entered information is invalid.
A.3.Go to 4.
A.4. Use case ends.
Table 9Update records- use case description
Search Resident use case description
Use case name Search resident
Actor(s) Officer
Description Searching for registered citizens for different purpose.
30
Pre-condition The citizen is registered in the system. and the actor must
Have an account with appropriate privilege.
Post-condition The system will generate search results.
1. The actor clicks search resident link

2. The system displays appropriate page.
3. The actors enter personal identification number as well as name on the search box.
4. After entering search key, the Actors submits it using the search button.
5. The system validates the entered search key.
6. The systems display result for searching.
7. Use case ends.
Alternative course of action A: if the Actors enters invalid personal identification number as well as name
A.1.The system determines that the entered personal identification number as well as name is invalid.
A.2.Go to 2
A.3. use case ends.
Table 10Search Residents - use case description
Manage accounts use case description
Use case name Manage accounts
31
Actor(s) Administrator
Description Allows system administrators to create, change,

activate, and deactivate account.
Pre-condition The actor must have valid account.
Post-condition The Actors will manage accounts.
1. The Actors chooses manage account link

2. The system displays manage account Menu Item like: -
 Create Account
 Activate Account
 Deactivate Account
 Change Account
3. The actors perform the intended task
4. The system performs the intended task.
5. Use case ends.
Alternative course of action A: If the Actors enters incorrect information
A.2.The system marks a place of Invalid information
A.3.Go to 3.
A.4. Use case ends.
Table 11Manage Account - use case description
Create account use case description
32
Use case name Create accounts
Actor(s) Administer
Description Actors can add user account.
Pre-condition The actor must register in the system
Post-condition The Actors will create accounts.
1. The Actors chooses create account link

2. The system displays the form of create account
3. The actor fills the form appropriately and press submit button.
4. The system validates the intended task.
5. Use case ends.
Alternative course of action A: If the Actors enters incorrect information
A.2. The system marks the invalid information.
A.3. Go to 2
A.3. Use case ends.
Table 12 Create account - use case description
33
Generate Report Use Case Description
Use case name Generate Report
Actor(s) Officer
Description Allows actors to generate report.
Pre-condition The actor must have valid account.
Post-condition Any appropriate actor accesses the necessary report for their
purpose.
1. User clicks the generate report menu item.

2. The system displays the report type.
3. The user selects on report type menu item.
4. The system display report form that contain the following: -
 Date of report
 Type of report
 For whom the report is prepared.
5. The user fills the form
6. The user clicks on generate report button
7. The system processes the report and displays it.
8. The users perform intended tasks.
9. Use case ends.
Alternative course of action A: If any information is not registered on that database
A.1. the system determines that there is not any report for generating your flavor.
34
A.2. The system displays “not legal report” message.
A.3. Use case ends.
Table 13 Generate Report - use case description
Add Events Use Case Description
Use case name Add Events.
Actor(s) Administrator
Description Adding new events in the system.
Pre-condition The Administrator must have username and password
Post-condition New events added in the system.
1. Administrator click Add Events button.

2. The system displays the appropriate form for adding new events.
3. The administrator fills the form.
5. The system displays “events successfully added” message.
6. Use case ends
Alternative course of action A: If the Administrator enters invalid information.
35
A.2. The system marks the invalid information.
A.3. Go to 2.
A.4. use case ends.
Table 14Add Events - use case description
View Record Use Case Description
Use case name View Record
Actor Officer, Manager
Description Allows actors to view individual vital events record.
Pre-condition The record must exist in the database and the actor should have valid
accounts.
Post-condition The required information will be displayed.
36
1. Actor clicks View Record button.

2. The system displays the appropriate information for users.
3. The user performs intended task.
4. Use case ends
Alternative course of action A: if the supplied information is not existing in the database:
A.1. The system displays “you haven’t any data” message with text box
Table 15View Record - use case description
3.3 Sequence diagram
Sequence diagram is the most commonly used interaction diagram. Interaction

diagram is used to show the interactive behavior of a system. Sequence diagram
simply depicts interaction between objects in a sequential order.[9]
37
Figure 2Sequence diagram for login
38
Figure 3 sequence diagram for birth registration
39
Figure 4 Sequence diagram for marriage registration
40
Figure 5sequence diagram for generate report
41
Figure 6 sequence diagram for view record
42
Figure 7 sequence diagram create account
43
Figure 8 sequence diagram for add new event
44
3.4 class diagram
Class diagrams are the mainstay of object-oriented modeling. Class models show the
classes of the system, their interrelationships (including inheritance, aggregation, and
association), and the operations and attributes of the classes. Class diagrams are used
for a wide variety of purposes, including both conceptual/domain modeling and
detailed structural design modeling.
Essential Elements:
1. Classes: The top compartment shows the class's name.
2. Attributes: The attribute section of a class (the middle compartment) lists

each of the class's attributes on a separate line. The attribute section is
optional, but when used it contains each attribute of the class displayed in a
list format. The line uses the following format.
3. Operations: The class's operations are documented in the third (lowest)

compartment of the class diagram's rectangle, which again is optional. Like
the attributes, the operations of a class are displayed in a list format, with each
operation on its own line.
4. Associations: An association relation is established when two classes are

connected to each other in any way. When you model a system, certain objects
will be related to each other, and these relationships themselves need to be
modeled for clarity.
5. Generalization: Generalization means that the specializing or derived type

inherits attributes, operations, and associations of the general or base type. The
general type appears at the arrowhead end of the relationship.
45
Figure 9Class diagram
CHAPTER FOUR
46
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.
4 .1Design 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
47
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.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.
During system decomposition of vital event registration system, we break down the
system into different subsystems or modules. The subsystems are with strong
coherence in order to perform specific task and loosely coupled in order to solve and
modify the modules separately. The vital event registration system can be
decomposed into some subsystems that are for some extent the give the same services
to the users. The subsystems of vital event registration system are listed below.
Account management subsystem.
Register management subsystem.
48
News management subsystem.

Report management subsystem.
Feedback management subsystem
User certificate management subsystem
User interface management subsystem
Database management subsystem.
49
Figure 10component diagram
50
4.3System 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.
51
Figure 11 System architecture
4.4 Deployment diagram
A deployment diagram in the Unified Modeling Language models the physical

deployment of artifacts on nodes. Deployment diagram depicts a static view of the
run-time configuration of processing nodes and the components that run on those
nodes. In other words, deployment diagrams show the hardware for your system,
52
the software that is installed on that hardware, and the middleware used to connect
the disparate machines to one another. A web server, an application server, and a
database server example of deployment diagram.
Nodes consist of (manager, officer, Customer, resident, and Administrator) and the
components (register event, view report, and generate report, manage account, print
certificate, post notification, update record, view record) that run on those nodes.
Figure 12deployment diagram
53
4.5 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 Semera city vital event registration system, persistent objects are
identified .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 object database. This object database provides better abstraction of data. Data is
stored in objects that comply with a predefined type called classes. Each class consists
an attribute and operation.
4.6 Access control and security
Access control and security are the most important terms during website development.
Good security requires physical access control, reliable personal, trust worthily.
Installation and configuration procedure, secure communications and control of data
base operation. Such as selecting, viewing, updating or deleting data base records.
Restrict unauthorized access to the places and during the time you specify all
information and resources are protecting from unauthorized people with respect to
confidentiality and integrity. This system is locked to prevent people from accessing
private document and resources. Let us see the table below to describe the Access
control and security issues in developing this system. The rows represent the actor of
the system and the column represents the classes of the system and operation that
actors are allowed to perform.
54
Actor Administrat Officer Resident cutomer manager

or
Servi Create_acco Gerenerate_r Sent_feedb View _report() View_record()

eport() ack() View_report()
ces unt() Send_message
Register_eve See_certifi
update_acco cate() () Post_news()
nts()
Event_regi Send_mesage(
unt() View_feedb Change_passw
ster() )
Delete_acco ack() Submit() ord()
Print_certific View_own
unt()
ate() _record()
Change_pass Update_reco Change_pa
rd (). ssword
word()
Delete-
View_messa
record()
ge() Search()
Add_new_ev View_record
ent() ()
Change_pass
word()
Table 16 Access control
55
References
[1]. About FDRE vital events registration: https://www.facebook.com/FDRE-
Immigrat ionNationality-And- Vital-Events-Agency-327700827402816/[Accessed 29
November 2019]. (2019)].
[2]. About Afar region: https: //www. google. com/url?q=http ://www.ethiopia.gov

.et/afar-regional-state&sa=U& ved =2ahUK EwjLosndzJvmAhXSaFA
KHYNtByUQFjAKegQIBhAB&usg=AOvVaw2 wB AAt-wr56ssWgolXdi0
N[Accessed 4 December 2019]. (2019)].
[3]. E-Vital Event Registration System: Tesfaye Ayalew, 2007,” Electronic Vital
Event Registration System”, Msc project, Department of Computer Science, AAU.
[4]. About Ethiopian Central Statistics: Abdulahi Hassen, 2001, Report of Ethiopian
Central Statistics Authority, Addis Ababa, Ethiopia.
[5] Definition of system testing:
https://com.sec.android.app.sbrowser/readinglist/0131074728.mhtml [Accessed 2
January 2020]. [2020]
[6] Definition of functional requirement: http://www.ops.fhwa.dot.gov/functional-
requirement [Accessed 1 january 2020]. (2020)].
[7]. Definition of functional requirement & non-

functionalrequirement:https://reqtest.com/requirements-blog/functional-vs-non-
functional-requirements/ [Accessed 2 january 2020]. (2020)].
[8]definition of system modeling

:https://cs.ccsu.edu/~stan/classes/CS410/Notes16/05-system modeling.html[accessed
10 january 2020].(2020)]
56
[9]Definition of sequence diagram

:https://www,google.com/amp/s/.www,geeksforgeeks.org/unified-modeling-language-
uml-sequence-diagrams/amp/[accessed 10 january 2020].(2020)]
57

College of Engineering and Technology Department of Computer Science

Uploaded by

Document Information

Original Title

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

College of Engineering and Technology Department of Computer Science

Uploaded by

Copyright:

Available Formats

COLLEGE OF ENGINEERING AND

Prepared BY: Section C Group Members

FENTALEM MULE…………….…. 0900607

FIKADE TILAHUN……………….. 0900610

FIRDWES FENTAW ……………… 0900612

Advisor: Mohammed Oumer (BSc)

Submitted To: computer science department

Submission date 26/05/2012

Semera, Afar, Ethiopia

1.1.1. Background of the organization..................................................................................1

2.2.3 System requirements of the proposed system.........................................................16

Figure 1 System use case........................................................................................................21

Table 1 software tools...............................................................................................................9

1.1.2. Introduction about the project

But Ethiopia is facing new challenges to its socio-economic development as a result

Vital registration is the continuous, permanent, compulsory, and universal recording

1.2. Literature review

A number of research papers, workshop reports, conference proceedings, journal

 Check supplied data for errors and completeness.

 Automated birth and death report for external institutions on request.

 Automatic issuance of certificates during registration.

 Generate statistical reports on birth and death.

 Ignores other vital events, such as marriage and divorce.

 Doesn’t provide complete input for vital statistics

 Does not fulfill the requirement of Ethiopian vital event registration.

 Civil code assignment is not well organized to handle attributes of an event.

 Less consideration of system design issues.

1.3. Statement of the problem

 Papers can be tear apart

 Errors that occur on papers cannot be corrected easily

 Can be damaged easily by accidents

 Low speed and efficiency

 It is difficult to view someone’s profile

 Peoples may leave empty spaces on the registration papers

 The certification process is exposed to falsification, for instance the case of

 It is tedious and time consuming

The general objective of this project is to develop computerized vital event

1.4.2 Specific objectives: -

 Analyzing and identification of requirements.

 To Design the proposed system based on the requirement analysis of the

 To design the system so as to be able to generate reports based on customers’

 To enhance the security of the system.

 To Deploying the system after the system is tested.

1.5. Significance of the project

The significance of the project is classified into three main parts: -

For the employees that work in every stage of registration: -

 It can facilitate the vital event registration system by changing it to more

 Help to avoid errors on registering forms of data.

 Effective and efficient data collection because of it is automated.

 Effectively manage data statistically no need to calculate or manually generate

 Helps in designing appropriate policy by providing reasonable statistical data.

 Provides a secure exchange of vital and statistical information.

For end users: -

 To use it as evidence in courts.

1.6. Scope and limitation

This project is bounded to provide the following features:

 Update user’s information

We will try to include features of good system as much as possible.

1.6.2 Limitation of the project

The project has the following limitations

 It is only accessed by person who has computer knowledge.

 The system is not applicable if a connection error occurs.

1.7.1. Data gathering methodology