FDRE Vital Events Registration Agency Information

Management System

A Project Report

Submitted By:
NAME ID NUMBER
MAHILET ZEWDU TER/4740/07
HANNA TILAHUN TER/4734/07
WULETAW YEHUALA TER/4761/07
TARIKU BEKELE TER/4755/07

In partial fulfilment for the award of the degree of

BACHELOR OF SCINCE IN INFORMATION TECHNOLOGY
Under the guidance of
Instructor WubetuShiferaw
………………………………
ADVISOR SIGNATURE

DEPARTMENT OF INFORMATION TECHNOLOGY

COLLAEGE OF TECHNOLOGY
DEBRE MARKOS UNIVERSITY
DEBRE MARKOS
May 22/09/2010 E.C

1
Abstract

The FDRE vital events registration agency manages information using manual system and
transports information from one branch to another by using humans. The other is when we
see the forms registrars may forget to fill spaces and leave them empty this leaves data
incomplete.It is also difficult to find information about users when it’s needed and Data is not
well organized in those areas difficult to analyze statistically. This manual system is tedious,
time and resource consuming. Our project will have account for every stage offices (Keble,
zone, region…etc) so that they can access the central database to register, view, give
certification, and produce report easily. Data will pass through offices by sending and
receiving using online system and it will be easy for further statistical analysis and it will be
more secure. So our aim is to develop a general-purpose automated system which can
effectively manageinformation.

2
Acknowledgement

First we would like to thank God for giving us the strength and patience to start and finish
this project. We thank our advisor MSC Wubetu Shiferaw for his patience unreserved and
valuable advises during the process of writing this document.

Thanks to those who gave us information for the completion of our project, to east gojjam
vital event registration office for their valuable comment and helpful information sharing.

Our Thanks is also forwarded to individuals who directly or indirectly supported us during
our project work.

Finally we would like thank our families and friends for being so helpful and encouraging
during this process.

3
Table of content
List of Figure ............................................................................................................................................ 6
List of Table ............................................................................................................................................. 7
Acronyms and Abbreviations .................................................................................................................. 8
Chapter one ............................................................................................................................................ 9
Introduction ............................................................................................................................................ 9
1.1 Introduction ............................................................................................................................. 9
1.2 Background of the organization .............................................................................................. 9
1.3 Statement of the problem ...................................................................................................... 10
1.4 Objective the Project ............................................................................................................. 10
1.4.1 General Objective ................................................................................................................ 10
1.4.2. Specific Objective ............................................................................................................... 10
1.5 Scope of the project .............................................................................................................. 11
1.6 Overview of the proposed system ......................................................................................... 11
1.6.1 Limitation of the project ............................................................................................... 11
1.7 Significance of the project .................................................................................................... 12
1.8 System requirements ............................................................................................................. 12
1.8.1 Hardware Requirements ................................................................................................ 12
1.8.2 Software Requirements ................................................................................................. 13
1.8.3 Programming language ................................................................................................. 13
1.9 Methodology ......................................................................................................................... 14
1.9.1 System development methodology ............................................................................... 14
1.9.2 Data collection methodology ........................................................................................ 14
1.10 Feasibility Study ................................................................................................................... 15
1.10.1. Operational feasibility ....................................................................................................... 15
1.10.2. Economic feasibility ......................................................................................................... 15
1.10.3. Legal feasibility................................................................................................................. 16
1.10.4 Technical feasibility ........................................................................................................... 16
Chapter two ........................................................................................................................................... 18
2. System analysis ................................................................................................................................. 18
2.1 Overview of the existing system ................................................................................................. 18
2.2 System requirement specification ............................................................................................... 20

4
 2.2.1 Functional requirements....................................................................................................... 20
2.2.2 Non functional requirements ................................................................................................ 21
2.2.2. Technical requirement......................................................................................................... 23
2.2.3. Business rules...................................................................................................................... 23
2.3. System requirement analysis...................................................................................................... 24
2.3.1. Actor and use case identification ........................................................................................ 24
2.3.3. UML Sequence Diagram .................................................................................................... 40
2.3.4 Activity diagram .................................................................................................................. 45
2.3.5 Analysis Class Diagram ....................................................................................................... 50
Chapter three ......................................................................................................................................... 52
3. System Design .................................................................................................................................. 52
3.1. Design class diagram ............................................................................................................ 52
3.2. Database design .................................................................................................................... 54
3.2.1. Physical data model ............................................................................................................ 54
3.2.2. Normalized table ................................................................................................................. 54
3.3 system architecture...................................................................................................................... 57
3.3.1. Deployment diagram ............................................................................................................... 57
4. Implementation and testing ........................................................................................................... 58
4.1. Implementation .......................................................................................................................... 58
4.2. Overview of the programming language ................................................................................... 58
4.2.1. sample code for login .......................................................................................................... 58
4.2.2. sample code for birth registration ....................................................................................... 61
5. Testing .............................................................................................................................................. 67
5.1. Unit testing ................................................................................................................................. 67
5.2. Integration testing ...................................................................................................................... 67
5.3. System testing ............................................................................................................................ 67
5.4 sample test................................................................................................................................... 67
Chapter six ............................................................................................................................................ 69
6. Conclusion and recommendation ...................................................................................................... 69
6.1. Conclusion ................................................................................................................................. 69
6.2. Recommendations ...................................................................................................................... 69
6.3. Future enhancement ................................................................................................................... 69
Appendix I ............................................................................................................................................. 70
References ............................................................................................................................................ 71

5
 List of Figure

Figure 1: Use Case Diagram ................................................................................................................. 27

Figure 2: sequence diagram for login ................................................................................................... 40
Figure 3: sequence diagram for registering events ............................................................................... 41
Figure 4: sequence diagrams for updating events. ................................................................................ 42
Figure 5: sequence diagram for the calculating population size ........................................................... 43
Figure 6: sequence diagram for view events ......................................................................................... 44
Figure 7: Sequence diagram for create user account ............................................................................ 45
Figure 8: Activity diagram for register events ...................................................................................... 46
Figure 9: activity diagrams for update event ........................................................................................ 47
Figure 10: Activity diagram for calculating population size ................................................................ 48
Figure 11: Activity diagram for view event .......................................................................................... 49
Figure 12: Activity diagram for create account..................................................................................... 50
Figure 13: Analysis class diagram ........................................................................................................ 51
Figure 14: Design class diagram ........................................................................................................... 53
Figure 15: Home page of the system .................................................................................................... 56
Figure 16: kebele officers page of the system....................................................................................... 56
Figure 17 deployment diagram ............................................................................................................. 57
Figure 18 sample test for create account ............................................................................................... 68

6
 List of Table

Table 1: Use case identification ............................................................................................................ 25

Table 2: Use case description and actors .............................................................................................. 28
Table 3: Use case description of register events ................................................................................... 29
Table 4: Use case description for update events ................................................................................... 31
Table 5: Use case description for view events ...................................................................................... 33
Table 6: Use case description for give printed certificate ..................................................................... 34
Table 7: Use case description for Generate report ................................................................................ 35
Table 8: Use case description for Calculate population size................................................................. 37
Table 9: use case description for login.................................................................................................. 38
Table 10: Birth table ............................................................................................................................. 54
Table 11: Death table ............................................................................................................................ 55
Table 12: kebele table ........................................................................................................................... 55

7
 Acronyms and Abbreviations

HTML…………………………………..HyperText Mark-up Language

CSS……………………………………...Cascading Style Sheet
PHP…………………………………….HyperTextPre-processor
MYSQL………………………………..My Structured Query Language
WAMP…………………………………Windows Apache MySQL PHP
JS……………………………………….Java Script
UML…………………………………....Unified Modeling Language
BR……………………………………..Business Rule
UC…………………………………….Use Case
ALT……………………………………Alternate Course of Action
VERA…………………………………… vital event registration agency

8
Chapter one

Introduction

1.1 Introduction
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 function 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 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)[7].

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 population. In general vital event registration means
registering events that are so important or have great impact for certain country.

1.2 Background of the organization

Vital events registration in Ethiopia is started In July 28/2008 E.C after long time preparation.
From the above vital events that are decide by UN, Ethiopia accepted to register (birth, death,
marriage, divorce, adoption, recognition of fatherhood and decision of fatherhood through
court). From those events Ethiopia works hardly in four of them (birth, death, marriage,
divorce).
Child birth is registered 90 days after the baby is born and (death, marriage and divorce) are
registered 30 days after they happen[7].

9
1.3 Statement of the problem
The FDRE vital events registration agency has the authority to form central database and to
control it but as we ask the employees of East Gojjam vital events registration there is central
database in head office they do not have any access to the database so they still work with
papers. The registration papers are published and distributed by the FDRE vital events
registration agency to the regions then to zones and zones distribute to Keble’s.

As we stated earlier the problem of this system basically comes with paper. Papers by
themselves bring many problems they can be:-
 Stolen by peoples
 Papers can be tear apart
 Errors that occur on papers cannot be corrected easily.
 Can be damaged easily by accidents.
As we have seen in the above the registration papers are transformed from one office to other
using car by humans until they reach in federal vital events registration agency this is tedious
and time consuming. The other is when we see the forms registrars may forget to fill spaces
and leave them empty this leaves data incomplete.
It is also difficult to find information about users when it’s needed especially for regions,
zones, and Keble’s because they don’t have access to any automated system. Data is not well
organized in those areas difficult to analyse statistically. To summarise this system have
database but it is not distributed to branch offices because of this several problems occur.

1.4 Objective the Project

1.4.1 General Objective

The general objective of this project is to develop an automated vital event registration
system. This project aims also to solve every problem that is faced during manual operation.

1.4.2. Specific Objective

To achieve the objective that are stated in the above we state the following specific
objectives:-
 To register events like marriage, birth, divorce, death, and adoption more easily than
the existing system.
 Generating valid statistical reports

10
  To give printed certificate for users.
 To enable actors view, update vital event information.
 Create more accessible database in every stage.

1.5 Scope of the project

The current system is manual and runs at many stages so our working boundary will be the
overall structure of federal vital event registration offices that specially focuses on
registration of birth, death, marriage, adoption, and divorce events. Our project will serve for
all offices of vital event registration at all stages.
 The system will do the registration of marriage, birth, divorce, adoption, 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 users information
 This system will have well organized central database that is accessible by every stage
employees.
We will try to include features of good system as much as possible.

1.6 Overview of the proposed system

The system that we develop eliminates all the paper based problems. The system have
account for every stage offices (Keble, zone, region a) so that they can access the central
database to register, view, give certification, and produce report easily without major errors.
Data pass through offices by sending and receiving using online system. The system is more
secure. The errors that occur in paper forms donot occur in our system because the forms that
we will generate do not let the users pass spaces empty so there no incomplete data.

1.6.1 Limitation of the project

The FDRE vital events registration agency information management system focuses only in
registration of events and counting those events. It does not do further statistical analysis by
using different types of criteria’s. it also does not support languages only in English.

11
1.7 Significance of the project
The significance of the project would be:-
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.
 It transmits data quicker than the existing system.
 Help to avoid errors on registering forms of data.
 Effective and efficient data collection.
 Effectively manage data statistically.
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 citizenship, 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:-
Peoples can ask their rights using the registered data as evidence.
For example:-
 To ask for Keble id card
 To ask citizenship
 To ask government different types of infrastructures.
 To use it as evidence in courts. etc

1.8 System requirements

In order to develop a web base system, it is very important to choose the correct hardware,
software and technology. Below there are some explanations of the hardware, software and
technology chosen as development tools to the vital event registration system.

1.8.1 Hardware Requirements

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

12
Specifically:-
 CPU with 2.20GHZ capacity
 8GB RAM
 Hard disk with 424GB

1.8.2 Software Requirements

There are many software requirements of the vital event registration system.

Microsoft office Visio 2007

Notepad++: For text editor
Window -7: for running and processing the tasks
Baidu browser: For displaying the system
Wamp server : for implementing the project
Xamp server: for implementing the project

1.8.3 Programming language

We will use different types of programming languages to implement or change our system
from document to practice. The system that we are going to develop must be user interactive,
easy to understand, and interesting to use in order to achieve those features we will use the
following programming language.
Server side programming script, PHP.
Because:
 It is open source
 User friendly language.
 Ease of Use:
 PHP is easy to learn compared to many other scripting languages.
 PHP can be easily fixed directly into, HTML and CSS
 PHP is platform independent.
 Easy to understand

Database system, MySQL

Because:

13
  Open –source
 Security
 Easy to develop
 Client side language, HTML, CSS, JavaScript

1.9 Methodology

1.9.1 System development methodology

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

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

Inan object-oriented environment, Object-oriented systems development is a way to

develop software by building self-contained modules or objects that can be easily
replaced, modified, and reused.
Is used to manage the complexity of software systems because objects, attributes,
methods can be reused so it reduces the complexity of the code.
Identifying the source of errors becomes easier because objects are self-contained
(encapsulation).

1.9.2 Data collection methodology

Data collection 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
Primary data source

 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.
 Observation: in order to get better information about the system we have got through
the vital event registration process.

14
  Document Analysis: we have analyzed different documents and brochure from the
East Gojjam vital event registration office.

Secondary source data

 Internet: Internet helps us to see the available samples and to download different
types of tutorials which help us in developing the system.

1.10 Feasibility Study

This analysis helps the organization in determining whether they should proceed with a
project or not. It determines the future of the project.

1.10.1. Operational feasibility

Operational feasibility is mainly concerned with issues like whether the system will be used if
it is developed and implemented. This system will be operationally feasible and the system
will be user friendly. The essential questions that help in testing the operational feasibility of
a system are following.

 Does management support the project? The vital event registration office
employees made a strong commitment to cooperate with the project team because
they want to eliminate the manual system once and for all. They give us necessary
information and resource about the existing system. All these shows that their
willingness to the success of the new system.

 For users: The system is operationally feasible as it is very easy for the End users to
operate it. It only needs to give some basic trainings about computer system.

1.10.2. Economic feasibility

Economic analysis involves the cost incurred on the system development team, estimated
cost of hardware and software, the cost of performing implementation and so on.
The system will not require much more cost beyond the capacity of the vital event
registration office capital when automating the system such as cost for networking

15
equipment’s, hardware and other infrastructures. Therefore, our system will be acceptable,
economically towards solving problems.
The system that we are going to develop has many tangible and intangible benefits for the
employees of FDRE vital events registration agency.

Tangible benefits
 Reduces cost for printing and distributing registration papers.
 Reduce cost for transporting registration papers from one stage to another.

Intangible benefits
 High user satisfaction.
 Reduces operation time
 Time to view events
 Time to update events
 Time to give printed certificate to the users.etc

1.10.3. Legal feasibility

The system will not have any conflict with the rule and regulation of country and also it is
legally acceptable since it respects the business rule of federal vital registration office and
regulation as well as other constitutional laws of the country.

1.10.4 Technical feasibility

This is study of resource availability that may affect the ability to achieve an acceptable
system. This evaluation determines whether the technology needed for the proposed system is
available or not[1].
 Can the work for the project be done with current equipment existing software
technology & available staff?
 Can the system be implementing after development?
 If new technology is needed then what can be developed?
This is concerned with specifying equipment and software that will successfully satisfy the
user requirement. An important issue for the development of a project is the selection of
suitable front-end and back-end.

16
Front-end selection:
 It must have a graphical user interface that assists employees that do not have IT
knowledge.
 Must be according to the organization requirement and the business rule.
 Must provide excellent reporting features with good printing support.
 Platform independent.
 Easy to debug and maintain.
 Front end must support some back end like Mysql
According to the above stated features we select Java script, HTML and CSS as the front-end
for developing our project.
Back-end Selected:
 Multiple user support.
 Efficient data handling.
 Provide efficient security system.
 Efficient data retrieval and maintenance.
 Operating System compatible.
 Easy to install.
 Easy to debug and maintain.
 Easy to connect with the Front-end.
According to above stated features we selected Mysql, PHP as the backend. And to
implement the automated system there must be network infrastructure with in different
offices of the vital event registration and one dedicated server.

17
 Chapter two

2. System analysis

2.1 Overview of the existing system

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

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

In Ethiopia there are four vital events that are being registered those are (birth, death,
marriage, divorce). Child birth is registered 90 days after the baby is born and (death,
marriage and divorce) are registered 30 days after they happen [7].

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

When marriage is registered they must have four witnesses two on behalf of female and two
on behalfthen they bring three photos for the certificate. The users must pay to get vital event

18
registration certificate. For the birth and marriage certificate users pay 35 birr and 25 birr
and10 birr for divorce and death respectively.

The existing system has the following characteristics:-

 Has long waiting time to get certificate of different vital events to use it as evidence
for different offices.
 Low speed and efficiency.
 It is difficult to view someone’s profile.
 Is less Secure.
 Peoples may leave empty spaces on the registration papers.
 Duplication of data.
 Loss of personal information.

Users of the existing system

The current system has many users. Those are:-
 Government: - government is major user of this vital event registration system. This
helps the government to make effective decisions, to design appropriate polices for
appropriate place; it can give recommendations to solve some problems etc.

 Courts: - this system is useful for courts by giving good evidences for the
accusations. For example in divorce cases, in decision of fatherhood, in the early
marriage cases. It can also used as evidence to decide whether someone has to go to
jail or not because if a person is under eighteen years of age he/she cannot go to jail.

 Central statistics agency:-the vital event registration information management

system can also be useful to central statistics agency by providing easy way to
conduct statistical analysis on population. For example making easy to do national
census, to know easily that how frequently occur those vital events and cause of them.

 Federal and regional education offices and schools:-vital event registration

information is very important for education offices and schools because if
childrenregistered those offices can easily know that how many children are ready to
go to school and can mobilize parents to send the children to school.

19
  Health centers: -are also users of this system. They give birth and death certificate to
the peoples so that theycan register the events. They can also view the registered
information for various purposes.

 Kebele offices: -those offices have responsibility to register the vital events that occur
within the Keble.

2.2 System requirement specification

System requirement specification contains the features that we intended to achieve with our
project that we are going to develop.
We try to summarize the specifications in to two categories:-
 Functional requirement
 Non functional requirement

2.2.1 Functional requirements

Functional requirements are the intended features of the system. These featuresmay 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. 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[2].

Thefollowing are functional requirement of our project

 Register the vital events
 Create user account for actors of the system
 Update the registered information if it is necessary
 View the registered information
 Generate statistical and non-statisticalreport based on the user’s requirement or query.
 Print certificate and give it to the users

20
2.2.2 Non functional requirements
Nonfunctional requirement is a requirement that specifies criteria that can be used to measure
the quality of a system, rather than specific behaviours. This should be compatible with
functional requirements that define specific behaviour or functions.
In general, functional requirements define what a system is supposed to do whereas non-
functional requirements define how a system is supposed to be. Non-functional requirements
are often called qualities of a system. Other terms for non-functional requirements are
constraints, quality attributes, quality goals and quality of service requirements[3].
Qualities that are non-functional requirements are the following:

Performance
Performance is characterized by the amount of task that are accomplished by asystem
withingiven time and resources used.
Good performance may involve one or more of the following characteristics:
 Short response time for a given task
 High efficiency
 High availabilitymeans that the system must stay up 24 hours a day within 7 days in a
week.
 Highdata transmissionrate
So to improve the performance of the system that we are going to develop we will use the
following methods:-
 Installing our system on multiple servers
 We use high capacity processors
 Improving bandwidthto make short response time
Security
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 restrict the privilege of users for example: - regional vital event registration
office employees must access only their regions data.
 The federal vital event registration agency employees and statistician from
statistics agency access the whole database.

21
  We used also session to restrict users from accessing page without their
privilegeso 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 methods like SHAL etc
Usability
Usability often refers to howsystem iseasyor cleartointeract with users. The system is be easy
to learn, easy to operate with the existing stuff.
It also includes the following points:-

 More efficient to use—it takes less time to accomplish a particular task

 Easier to learn—operation can be learned by observing the object
 More satisfying to use
To improve our systems usability we introduce the following methods
 Designing more intractable user interface by using more efficient codes like CSS
and HTML.
 We will make the system more usable by employees of the vital event registration
office by giving continues training
Reliability
The system is expected to performperfectly without major errors and failure. The system
should satisfy the user and should be fault tolerant.
To achieve this
 We will install our system on high quality hard wares
 Back up regularly
 Control external factors like power loss as much as possible.

Modifiability
The system that we develop is easy to modify by its users if it is necessary.

 If we want to add new functionalities

 If we want to add new features
The system continues performing as previous time even we change some features.

22
 2.2.2. Technical requirement
The technical requirement of the system:

 The interface of the system is user friendly easy to use.

 The interface displays error message if it detects invalid input
 The system deny unauthorized accesses to the system domain
 The system provides help for the user.
 Training the users to access the system.

2.2.3. Business rules

The business rule defines or constrains one aspect of your business that is intended to assert
business structure or influences the behavior of your business. Business rules often focus on
access control issues or sometimes they focus on polices of the organization.

Business rule are principles, requirements and polices that must be fulfilled and obligated in
order the system will function properly and effectively.

The business rules that must be considered for this project are described below.

BR1: Any vital event cannot be registered more than once.

BR2: The person who wants to register the vital event they should appear physically in the
Keble registrar offices.

BR3: the vital event information’s should be registered on the forms without any error.

BR4: the registrars update events with the order of the courts

BR5: the registrar must assure the correctness of the registered information by showing to the
users.

BR6: after reading the registered information the user must sign on it.

BR7: the vital events should be registered with working language of the region that event
happens and with Amharic language.

BR8: the registrar must also sign on registration papers after assuring its correctness.

BR9: the certificate is given to the user after they pay the service payment.

23
BR10: The registrar should keep theconfidentiality of the vital eventinformation.
BR11: every employee in every stage access the system according to their privilege

2.3. System requirement analysis

2.3.1. Actor and use case identification

Actor: An actor represents a type of users of the system or external system that plays a role in
one or more interactions with our system.

Use case: A use case describes a sequence of actions that provide a measurable value to an
actor. A use case is drawn as horizontal ellipse on a UML use case diagram.

2.3.1.1 Actor identification

As we ask from East Gojjam zone vital event registration office employee and as we have
seen from the organizational structures the following are actors of the FDRE vital event
registration information management system.

System Administrator: a person who is going to administer system we are going to develop.

Keble officer: Is a person who has responsibility to register vital events in Keble level.

Statistician: Person who works central statistics agency that groups population according to
the calculated information.

Federal officer: is captain, solider or employee of Ethiopian foreign ministerin foreign

country which is responsible to register vital events.

Regional vital event registration office employees: views the registered information and
zones that are under its administration and send feed back if any problem on forms.

Zonal vital event registration office employees: views the registered information and send
feed back if any problem on forms to the kebele registrars.

Woreda vital event registration office employees: - views the registered information and
send feed back if any problem on forms to the kebele registrars.

24
2.3.1.2 Use case identification
Table 1: Use case identification

Use case name Use case ID includes

Register vital events UC01 Login

Update registered events UC02 Login

View registered events UC03 Login

Give certificate UC04 Login

Generate report UC05 Login

Calculate population size UC06 Login

Count number of birth UC07 Login

Count number of death UC08 Login

Count number of marriage UC09 Login

Count number of divorce UC10 Login

Send feed back UC11 Login

Create user account UC12 Login

Block account UC13 Login

Update account UC14 Login

Search account UC15 Login

View feedback UC16 Login

View report UC17 Login

Register region UC18 Login

Register zone UC19 Login

Register woreda UC20 Login

Register kebele UC21 Login

Register city UC22 login

25
Login UC23

2.3.1.3 Use case diagram

A system use case model is composed of a use case diagram and the accompanying
documentation describing the use cases, actors, and associations. The main difference
between an essential use case and a system use case is that in the system use case you
include high-level implementation decisions.

26
 register woreda

register city

register kebele

woreda officer
zonal officers

view events
count divorce
update event
count birth
«extends»«extends»

view report

count events

«extends»
«extends»
generete report
register events statician
count marriage
fedreral officer
count death
view feedback

send feedback
give printed
certificate

register zone
login
kebele officer «extends»
regional officers
logout

register region
«extends»
create account
manage account
«extends» «extends»

«extends»
«extends» search account
block account

update accont
create backup

syatem adminstrator

Figure 1: Use Case Diagram

27
2.3.2 Use case description
Table 2: Use case description and actors

Actors Use case

System administrator  login
 Create account
 Block account
 Update account
 Search account
 Create backup
 Register region
 logout

Keble registrars, federal registrars  login

 register events
1. birth
2. death
3. marriage
4. divorce
 view events
 update events
 generate report
 give printed certificate
 view feedback
 count vital events
 view report
 logout
Statistician  login
 calculate population size
 count birth
 count death
 count marriage
 count divorce

28
  view events
 view report
 generate report
 send feedback
 count vital events
 logout
Zone, woreda and regional employees of  login
VERA  view events
 generate report
 count vital events
 view report
 send feedback
 logout

Table 3: Use case description of register events

Name Register event

Use case ID: UC01

Participating Actors: Keble Registrar, federal registrars

Description: Used to register vital events at Keble and

federal level.
Precondition:  The user must have an account to
register events.
 Have notification paper from health
centers
Post condition:  System adds event information to
database.
 Give certificate
Basic course of action
1. The use case starts when registrars
indicate they want to register events.
2. Thenregistrar enters user name and

29
 password.
3. Click login button. [Alt: A]
4. The system provides a list of
operations. [BR11: access its own
page only]
5. The Registrar selects register
eventslink it may be birth, death,
marriage, divorce.
6. The Registrar fills and submits the
form. [BR1,BR3,BR5,BR6 and
BR7: register without error, do not
duplicate events ] [Alt: B]
7. The system receives data and prepares
it to be printed on certificate if it is
necessary.
8. The use case ends

Alternative course of action : A:user entered invalid user name and

password
A3: The system displays error message
saying “Invalid user name or password.”
A4: Usecase continues from step 2

B: Registrar filled invalid form data

B6: The system shows error message invalid
form data message
B7: System asks user to re-enter the invalid
data again
B8. Use case continues from step 6

30
Table 4: Use case description for update events

Name Update events

Use case ID: UC02

Participating Actors: Keble Registrar, federal registrars

Description: The registrars updates of the registered vital

events.

Preconditions:  The user must bring order paper from

courts that enables the registrar to
update the registered event.

 The registrar must have an account

with update privilege.

Basic course of action:

1. The use case starts.
2. Then registrar enters user name and
password.
3. Click login button. [Alt: A]
4. The system provides a list of
operations. [BR11: access its own
page only]

5. The Registrar selects update events

link it may be birth, death, marriage,
divorce.
6. The registrar enters the events
identification Number and submits.
[Alt: B]
7. The Registrar updates and submits the

31
 form. [BR4,BR5, BR6: update events
according to the order of courts and
assure the correctness of data.][Alt:
C]
8. The system receives data and prepares
it to be printed on certificate if it is
necessary.
9. The use case ends.

Alternative course of action: A:user entered invalid user name and

password
A3: The system displays error message
saying “Invalid user name or password.”
A4: Use case continues from step 2

B: Registrar filled invalid form data

B6: The system shows error
message“invalidIDnumber”.
B7: System asks user to re-enter the invalid
data again
B8. Use case continues from step 6

C: registrar fills the data that is needed to be

updated.
C7: The system displays error message
saying “Invalid formdata.”
C8: System asks user to re-enter the invalid
data again.
C9: Use case continues from step 7

Post conditions: The system successfully updates the vital

events (birth, death, marriage, divorce)

32
Table 5: Use case description for view events

Use case name: View events

Use case ID: UC03

Participating Actors: Keble registrars, federal registrars,

statistician, regional officers, zone officers
Description: The registrars view events may be for error
check or just viewing.

Preconditions: The event must exist in the database and

actors must have privilege to view events.

Basic course of action:

1. The use case starts
2. The actor enters user name and
password.
3. Click login button.[Alt: A]
4. The system provides a list of
operations. [BR11: access its own
page only]
5. The actor selects viewing event links.
6. The actor fills necessary information
and clicks on view button.[Alt: B]
7. The actor viewing events.
8. The use case ends.

Alternative course of action: A:user entered invalid user name and

password
A3: The system displays error message

33
 saying “Invalid user name or password.”
A4: Use case continues from step 2

B: Registrar filled invalid eventID number.

B6: The system shows error message “invalid
ID number”.
B7: System asks user to re-enter the invalid
data again
B8. Use case continues from step 6

Post conditions: The actors successfully views vital event.

Table 6: Use case description for give printed certificate

Use case name: Give printed certificate

Use case ID: UC04

Participating Actors: Keble Registrar, federal registrars

Description: The registrars give printed certificate by the

request of the customers.

Preconditions: The event must exist in database and the

certificate is printed if the end user request.

Basic course of action: 1. The use case starts.

2. The actor enters user name
and password.
3. Click login button.[Alt: A]
4. The system provides a list of

34
 operations. [BR11: access its
own page only]
5. The actor selects generate
certificate link.
6. Retrieve necessary
information’s from the
database. [Alt: B]
7. Click on print button
8. The use case ends

Alternative course of action: A:user entered invalid user name and

password
A2: The system displays error message
saying “Invalid user name or password.”
A3: Use case continues from step 2

B: Registrar Retrieve invalid data.

B6: The system shows error message
“informationdoes notexist”.
B7: System asks user to re-enter the valid
data again
B8. Use case continues from step 6

Post conditions: Give printed certificate filling correct

information to end users.

Table 7: Use case description for Generate report

Use case name: Generate report

Use case ID: UC05

Participating Actors: Statistician, Keble registrar, federal registrar

35
Description:  Generating report that gives general
information about the records in
database.

 The reports are used for further

researches and analysis.
Preconditions: The actor must have an account and privilege
to generate report.

Basic course of action:

1. The registrarenters username and
password
2. The registrar click login button. [Alt:
A]
3. The system provides a list of
operations. [BR11: access its own
page only]
4. The registrarselects generate Report
link.
5. The registrarselects the report type
6. then generate report[Alt: B]
7. the use case ends

Alternative course of action: A:user entered invalid user name and

password
A2: The system displays error message
saying “Invalid user name or password.”
A3: Use case continues from step 2

B: Registrar wantsRetrieve thedata that is not

in the database.
B6: The system shows error message

36
 “informationdoes notexist”.
B7: System asks user toretrieve again.
B8. Use case continues from step 5

Post conditions: Generate reports successfully.

Table 8: Use case description for Calculate population size

Use case name: Calculate population size

Use case ID: UC06

Participating Actors: Statistician

Description: Allows the statistics agency to do national

census easily and calculate the size of people
over Keble, woreda, zone, region and over all
country’s population.

Preconditions:  The actor must have an account with

calculate population size privilege.

 The events must be registered in

central database.

Basic course of action:

1. The actor enters user name and
password.
2. Click login button. [Alt: A]
3. The system provides a list of

37
 operations. [BR11: access its own
page only]

4. The Statistician selects calculate the

population size link.
5. The Statistician clicks calculate
button.[Alt: B]
6. Generates reports if it is necessary.
[Alt: C]
7. The use case ends.

Alternative course of action : A:user entered invalid user name and

password
A2: The system displays error message
saying “Invalid user name or password.”
A3: Use case continues from step 2

B: The Statistician wantstocalculate data that

is not in the database.
B6: The system shows error message
“informationdoes notexist”.
B7: System asks user toretry again.
B8. Use case continues from step 5

Post conditions: Calculate the size of population without any

error

Table 9: use case description for login

Use case name : Login

Use case ID UC23

38
Participating Actors: Keble registrars, federal registrars,
statistician, regional officers, zone officers,
medical officer, administrator.

Description : Users are authenticated and enter to their own

user interface page.

Precondition Users must get an account from the system

administrator

Post condition The user is authenticated and taken to his/her

own user interface

Basic course of action 1. The user opens the main home page
by writing the URL of the website.
2. The system display the Main Home
page
3. Actor clicks a login link
4. The user inputs user name and
password and submit [Alt: A]
5. The system validates the account and
displays the user require information.
6. The system directs to his own page
[BR11: access its own page only]

Alternate course of action: A: If the login name or password is invalid

A4: The system displays invalid username or
password message

A5: The user re-enters the username and

password

39
 A6. Turn back to step 4

2.3.3. UML Sequence Diagram

A UML Sequence diagram showing the sequence of interactions among objects and used to
represent or model the flow of messages, events and actions between the objects or components
of a system. Sequence Diagrams are also used primarily to design, document and validate the
architecture and interfaces of the system by describing the sequence of actions that need to be
performed to complete a task.

login form login form

user <<UI>> <<controler>> database
<<actors>>

Enter UN and pass

chek data()

check form

check user()

check if presents()
successfully login

Figure 2: sequence diagram for login

40
 registrar page event registration form event registration form
kebele registrar
<<UI>> <<UI>> <<controler> database
<<actor>>
>

Click on register
event link()

display()

fill the data and click

on register button()

check form data()

is valid()

chek & add data()

registered check if not

present

Figure 3: sequence diagram for registering events

41
 kebele registrar registrar page update form update form database
<<actor>> <<UI>> <<UI>> <<controler>>

Click on update
events link
display()

Enter events IDNO

click on search
button()
check ID & search()

is valid()

search()

check if presents()

view events

fill data & click on update button()

check form data()

is valid

update()

check data()

event successfully updated

Figure 4: sequence diagrams for updating events.

42
 statistician page calculate size form calculate pop size
statistician
<<UI>> <<UI>> <<controler>> database
<<actor>>

Click on calculate
pop size link()
display()

Click on calculate
button()
calculate()

calculate()

display result()

Figure 5: sequence diagram for the calculating population size

43
 kebele registrar view event form view form
<<actor>> <<UI>> <<controler>> database

Enter events IDno

click on search button()

check eventID()

check if valid()

search event()

check if presents()

view event

Figure 6: sequence diagram for view events

44
 system administrator admin page create account form create account form
<<actor>> <<UI>> <<UI>> <<controler>> database

Click on create
account link()
display()

fill the data and click

on create button()
check the form data()

is valid()

Add user()

Check if
not
successfully added presents

Figure 7: Sequence diagram for create user account

2.3.4 Activity diagram

Activity diagram is basically a flow chart to represent the flow form one activity to another
activity. The activity can be described as an operation of the system. So the control flow is
drawn from one operation to another. This flow can be sequential, branched or concurrent.
Activity diagrams deals with all types of flow control by using different elements like fork,
join etc. [4]

45
 enter user name and password

click on login button enter UN and PASS again

Check input
display invalid input
NO
YES
display registrar page

click on register events link

event successfully registered

display register events form

YES

fill the form

NO

click on register button

Check input

Figure 8:Activity diagram for register events

46
 successfully updated

YES
Check
enter user name and password input
no

click on update button

enter UN and PASS again click on login button

fill the data

Check
display invalid input un&pass
NO
YES
display event inforrmation
display registrar page
YES
Check id no invalid ID

click on update link

click search button enter event ID again

display update event form enter events ID

Figure 9: activity diagrams for update event

47
 enter user name and password

click on login button enter UN and PASS again

Check invalid input

input NO
YES
display statistician page

click on calculate link

display calculate size form

NO

click on calculate button display result

YES
Check
data

Figure 10: Activity diagram for calculating population size

48
 enter user name and password

click on login button enter UN and PASS again

Check
un&pas NO invalid input

YES
display actors page

click on view events link

fill the data

NO

click on search button display event

Check YES
event

Figure 11: Activity diagram for view event

49
 enter user name and password

click on login button enter UN and PASS again

Checkun
NO
&pas invalid input

YES

display administrator page

click on create account link

display create account form

fill the data NO

click on create button successfuly created

YES
Check
input

Figure 12: Activity diagram for create account

2.3.5 Analysis Class Diagram

UML class diagrams are the mainstay of object-oriented modelling. 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 modelling and detailed structural
design modelling. [5]

50
 Administrator Account
-AID -User name
-Aname -Password
-Afname 1 1* -status
-Role
+Manage account()
+create account()
+update account()
+block account() 1
+search ()
+add custemer()
1 1
1 1
zone officer
1 -zofID worreda officer
kebele officer
Federal officer 1 -zid
Regional officer -wofid
-FID -Rid
-officerID -wID
-fname -RID
1 -kid
-lname -RegofID
-fname -wname
-fname -lname -wlname
-place -rename
statistician -lname +View event() +generate report()
-rfname
-SID +register event ()
+register events() +sendfeedback() +view report() 1
-Sname +view event()
+update events() +view events() +view report() +count events() 1* kebele
+view events() +send feedback() +generate
-Sfname +update event() +view events()
+generate report() +view report() report() 1 -kid
+view event() +()
+print certificate() +generate report() 1 1 1 1 -Wid
+generate report() +generate report()
+() 1
+calculate pop size() 1 +print certificate()
+view feedback() 1 1* -kname
+count events() +view feedback()
+view report()
+view report()
+view report() 1* 1 1*
1 1 1 1
1 woreda
-Wid
-Zid
-wname 1
1* 1* 1*
Zone 1
1* Events 1* -Zid 1* 1* city
-RID
Divorce
-EID
-SID
1* 1* 1* -Zname
-cityid
«inherits» -wid
-file no -kregID 1* Feedback 1 1* -cname
-divorce date -Ename 1* -FeID
-divorce reason -region -Date 1*
-woreda
1* 1* Region
-DVID -sender
-Mid -zone -feedback -RID
1* -Rname

«inherits»
1
1 1*
«inherits» «inherits» 1*

1
Marriage Death
1
-brname -DID
Birth -educational status
-grname
-previous mar sta -BID -work position
-ceremony type -bname 1 1 -nationality
-date 1* 1 -bfname -BID
-BID -blname
-MID -wieght
-nationality

Figure 13: Analysis class diagram

51
 Chapter three

3. System Design
System design is the transformation of the analysis model into a system design model.
System design is the first part to get into the solution domain in a software development.
System analysis transform the analysis model into the design model that takes into account
the non-functional requirements and constraints described in the problem statement and
requirement analysis. The purpose of designing is to show the direction how the system is
built and to obtain clear and enough information needed to drive the actual implementation of
the system. The objectives of design are to model the system with high quality.
Implementing of high quality system depend on the nature of design created by the designer.
If one wants to change to the system after it has been put in to operation depends on the
quality of the system design.

3.1. Design class diagram

The class diagram represents the static view of an application. Class diagram is not only used
for visualizing, describing and documenting different aspects of a system but also for
constructing executable code of the software application. The class diagram describes the
attributes and operations of a class and also the constraints imposed on the system. The
classes diagrams are widely used in the modeling of object oriented systems because they are
the only UML diagrams which can be mapped directly with object oriented languages. The
class diagram shows a collection of classes, interfaces, associations, collaborations and
constraints. [5]

Systems design is the process of defining the architecture, modules, interfaces, and data for a
system to satisfy specified requirements. Systems design could be seen as the application of
systems theory to product development.

52
 Administrator Account
-AID : int -User name : char
-Aname : char -Password : int
-Afname : char 1 1* -status : char
-Role : char
+Manage account()
+create account()
+update account()
+block account() 1
+search ()
+add custemer()
1 1
1 1
zone officer
1 -zofID : int worreda officer
Federal officer 1 -zid : int
kebele officer Regional officer -wofid : int
-FID : int -Rid : int -wID : int
-officerID : int -RID : int
1 -kid : int
-fname : char
-RegofID : int
-fname : char -wname : char
-lname : char -lname : char -wlname : char
-fname : char -rename : char
statistician -place : char +View event() +generate report()
-lname : char -rfname : char
-SID : int +register events() +sendfeedback() +view report() 1
-Sname : char
+register event ()
+update events()
+view events() +view report() +count events() 1* kebele
+view event() +send feedback() +generate
-Sfname : char +view events() +view events()
+update event()
+generate report()
+view report() report() 1 -kid : int
+view event() +generate report() +generate report() 1 1 1 1 -Wid : int
+generate report() +print certificate()
+print certificate()
+calculate pop size() 1 +view feedback()
+view feedback() 1 1 1* -kname : char
+count events() +view report()
+view report()
+view report() 1* 1 1*
1 1 1 1
1 woreda
-Wid : int
-Zid : int
-wname : char 1
1* 1* 1*
Zone 1
1* Events 1* -Zid : int 1* 1* city
-RID : int
Divorce
-EID : int
1* 1* 1* -Zname : char
-cityid : int
«inherits» -SID : int -wid : int
-file no : int -kregID : int 1* Feedback 1 1* -cname : char
-divorce date : char -Ename : char 1*-FeID : int
-divorce reason : char -region : char -Date : Date 1*
-woreda : char
1* 1* -sender : char Region
-DVID : int
-Mid : int -zone : char -feedback : char -RID : int
1* -Rname : char

«inherits»
1
1 1*
«inherits» «inherits» 1*

1
Marriage Death
1
-hname : char -DID : int
Birth -educational status : char
-hname : char
-previous mar sta : char -BID : int -work position : char
-ceremony type : char -bname : char 1 1 -nationality : char
-date : Date 1* 1 -bfname : char -BID : int
-BID : int -blname : char
-MID : int -wieght : char
-nationality : char

Figure 14: Design class diagram

53
 3.2. Database design

3.2.1. Physical data model

A physical data model (or database design) is a representation of a data design as
implemented, or intended to be implemented, in a database management system. In the
lifecycle of a project it typically derives from a logical data model, though it may be reverse-
engineered from a given database implementation. A complete physical data model will
include all the database artifacts required to create relationships between tables or to achieve
performance goals, such as indexes, constraint definitions, linking tables, partitioned tables or
clusters. Analysts can usually use a physical data model to calculate storage estimates; it may
include specific storage allocation details for a given database system. [6]

A physical database model shows all table structures, including column name, column data
type, column constraints, primary key, foreign key, and relationships between tables.

 Entities are tables.

 Attributes are columns.
 Unique identifiers are columns that are not allowed to have NULL values.
 Relationships are modeled by foreign keys.

3.2.2. Normalized table

Table 10: Birth table

Column name Data type Primary key Foreign key Uniqueness

Eid Varchar(30) yes yes
KregID Varchar(20) yes
ZoID Varchar(20) yes
RegofID Varchar(20) yes
City Varchar(20)
Baby name Varchar(20)
Father name Varchar(20)
Grandfather Varchar(20)
name
Birth date Date & time

54
Birth place Varchar(20)
sex char
Nationality Varchar(20)

Table 11: Death table

Column name Data type Primary key Foreign key Uniqueness

Eid Varchar(30) yes yes
RegID Varchar(20) yes
ZoID Varchar(20) yes
city Varchar(20)
kregID Varchar(20) yes

Table 12:kebele table

Column name Data type Primary key Foreign key Uniqueness

wid Varchar(30) yes
KID Varchar(30) yes
kname Varchar(20)

55
3.1. User interface design

Figure 15: Home page of the system

Figure 16: kebele officers page

56
 3.3 system architecture

3.3.1. Deployment diagram

Deployment diagram is a structure diagram which shows architecture of the system as
deployment or distribution of software artifacts to deployment targets. Deployment diagrams
model the physical architecture of a system. It also shows the relationship between the
software and hardware. A deployment diagram shows how and where the system is to be
deployed; that is, its execution architecture.

Client Application server

Database server
create account
system admin page

block account
woreda

update account
FDRE Vital Event
kebele registrar page Registration system
Database
register kebele

federal registrar page

update events

regional officer page

view events

zonal officers page

generate report

statistician page
register events

view report

calculate population size

Figure 17 deployment diagram

57
 Chapter four

4. Implementation and testing

4.1. Implementation
Implementation in the system includes implementing the attributes and methods of each
object and integrating all the objects in the system, to function as a single system the
implementation activity fills the gap between the detailed objects designed model and a
complete set of source code file that is compiled together.[8]

4.2. Overview of the programming language

We used different types of programming languages to implement our system from. PHP is
one from the languages it is scripting language that is often embedded into HTML to add
functions that HTML alone can't do. PHP allows us to collect process and utilize data to
create a desired output. In short, it lets you interact with your pages. PHP is freely available
for use. PHP is available at free and it has most important functionality in its associative
software's like MySQL, and Apache Server are also freely available, we also use xamp server
to run the project.
We use other languages for implementing this project we use :-
 Scripting language:-used to develop different validations.
 HTML:-to display the web page.
 CSS: - for the formatting of the web site.

4.2.1. sample code for login

<?php
if(isset($_POST["login"]))
{ $un=$_POST["un"];
$pass=sha1($_POST["pass"]);
if($con)
{
//account

58
 $sql="select * from account where username='$un' and
password='$pass'";
$matchfound=mysql_query($sql);
if($row=mysql_fetch_assoc($matchfound))
{
$uid=$row["uid"];
$un=$row["username"];
$pw=sha1($row["password"]);
$status=$row["status"];

//user
$sqll="select * from user where uid='$uid'";
$matchfound1=mysql_query($sqll,$con);
if($row=mysql_fetch_assoc($matchfound1))
{
$uid=$row["uid"];
$fname=$row["ufname"];
$mname=$row["umname"];
$lname=$row["ulname"];
$mobile=$row["mobile"];
$sex=$row["sex"];
$role=$row["role"];
$photo=$row["photo"];
$email=$row["email"];
}//session
$fullname=$fname." ".$mname." ".$lname;
$_SESSION['fullname']=$fullname;
$_SESSION['sun']=$un;
$_SESSION['spw']=$pw;
$_SESSION['srole']=$role;

59
 $_SESSION['uid']=$uid;
$_SESSION['sphoto']=$photo;

if($role=="Admin" && $status=="active")

header("location:Adminpage.php");

else if($role=="federaloficer" &&

$status=="active")
header("location:federalregistrarpage.php");
else if($role=="reginalofficer" &&
$status=="active")
header("location:reginalofficer.php");

else if($role=="kebeleofficer" &&

$status=="active")
header("location:kebeleregistrarpage.php");

else if($role=="woredaofficer" &&

$status=="active")
header("location:woredaofficer.php");

else if($role=="zonalofficer" &&

$status=="active")
header("location:zonalofficer.php");
else if($role=="statician" &&
$status=="active")
header("location:staticianpage.php");
else if($role=="federaladmin" &&
$status=="active")
header("location:branchadmin.php");
else
{

60
 echo "<script>alert('your account blocked
contact adminstrator')</script>";
}
}
else
echo"<script>alert('Invalid username or password')</script>";
}
else
{
echo "Invalid username or password";
header("location:home.php");
}
}
?>

4.2.2. sample code for birth registration

<?php

session_start();

include("connection.php");

?><html>

<head>

<title>VITAL EVENT REGISTRATION INFORMATION

MANEGMENT SYSTEM</title>

<link href="mystyles.css" rel="stylesheet"

type="text/css" /

</head>

<body id="bockground">

<?php

if(isset($_SESSION['sun'])&&isset($_SESSION['spw']))

61
 $id=$_SESSION['uid'];

$sql="select*from user where uid='$id'";

$record=mysql_query($sql,$con);

if(mysql_num_rows($record)>0)

while($row=mysql_fetch_array($record))

$nation=$row["nationality"];

$region=$row["region"];

$zone=$row["zone"];

$woreda=$row["woreda"];

$city=$row["city"];

$kebele=$row["kebele"];

}} else

echo"No Result Found"; ?>

<div id="all"><table><div id="divHeader">

<?php require("header.php"); ?>

</div><div id="divNav">

<?php require("kebeleregistrarmenu.php"); ?></div>

<tr><td><div id="divSideContentLeft">

<?php require("kebelemenu2.php");
?></div></td><td>

<div id="divContentCenter"><table><tr><td><font size="5"

color=blue>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;wellcome to
birth registration form in <?php echo"$kebele
kebele"?></font><br/></td></tr></table>

<?php

if(isset($_POST['register']))

{ $id=$_POST['kooficer'];

62
 $babyname=$_POST['babyname'];

$fathername=$_POST['fathername'];

$gfather=$_POST['gfather'];

$mathername=$_POST['mathername'];

$mathermname=$_POST['gmaname'];

$sex=$_POST['sex'];

$bdate=$_POST['bdate'];

$nation=$_POST['nation'];

$regdate=$_POST['regdate'];

$region=$_POST['region'];

$zone=$_POST['zone'];

$city=$_POST['city'];

$woreda=$_POST['woreda'];

$kebele=$_POST['kebele'];

$birthstatus=$_POST['birthstatus'];

//insert data in to the table

$sql="INSERT INTO
birthtable(fname,mname,lname,motherfname,mothermname,sex,birth
date,nationality,registrationdate,birthregion,birthzone,birthc
ity,birthworeda,birthkebele,uid,statusformrg,birthstatus)
VALUES('$babyname','$fathername','$gfather','$mathername','$ma
thermname','$sex','$bdate','$nation','$regdate','$region','$zo
ne','$city','$woreda','$kebele','$id','unmarried','born')";

$res= mysql_query($sql,$con);

if(!$res)

{ echo "<font size='5'>baby registered before

try again!!!</font>".mysql_error($con);

else

63
 { echo "<font size='5' color=green>born baby
successfully registered!!!</font>";

}} ?>

<br/><br/><br/>

<fieldset style="border-radius:5px;">

<legend><font size=4>birth registration

form</font>s</legend>

<form action="birthreg_form.php" method="post">

<table><tr><td>baby name</td><td>

<input type="text" name="babyname" pattern="[A-Za-z]+"

placeholder="Enter baby name " required="" style="font-
size:12pt;color:black;border:1px solid gray;padding:2px;
width:230px;" required="">

</td></tr><tr><td> father_name:</td><td>

<input type="text" name="fathername" pattern="[A-Za-z]+"

placeholder="enter father " required="" style="font-
size:12pt;colo r:black;border:1px solid
gray;padding:2px; width:230px;" required="">

</td></tr><tr><td>grandfather</td><td>

<input type="text" name="gfather" pattern="[A-Za-z]+"

placeholder="gfather " required="" style="font-
size:12pt;color:black;border:1px solid gray;padding:2px;
width:230px;" required=""> </td></tr><tr><td>
mother_name</td><td>

<input type="text" name="mathername" pattern="[A-Za-z]+"

placeholder="maname " required="" style="font-
size:12pt;color:blac k;border:1px solid
gray;padding:2px; width:230px;" required="">

</td></tr><tr><td> grand
mother_name</td><td>

<input type="text" name="gmaname" pattern="[A-Za-z]+"

placeholder="gmaname " required="" style="font-
size:12pt;color:black; border:1px solid

64
gray;padding:2px; width:230px;"
required=""></td></tr><tr><td>sex:</td><td>

<select name="sex" style="font-

size:12pt;color:black;border:1px solid gray;padding:2px;
width:230px;" required="">

<option>female </option>

<option>male</option></select></td></tr><tr><td>birth
date</td><td>

<input type="date" name="bdate" style="font-

size:12pt;color:black;border:1px solid gray;paddin
g:2px; width:230px;" value="<?php echo date("Y-m-d"); ?>" >

</td></tr><tr><td>nationality:</td><td>

<input type="text" name="nation" style="font-

size:12pt;color:black;border:1px solid gray;padding:2px;
width:230px;" required readonly value="<?php echo $nation;?>"
></td>

</tr><tr><td>region:</td><td>

<input type="text" name="region" style="font-

size:12pt;color:black;border:1px solid gray;padding:2px;
width:230px;" required readonly value="<?php echo $region;?>"
></td>

</tr><tr><td>zone:</td><td>

<input type="text" name="zone" style="font-

size:12pt;color:black;border:1px solid gray;padding:2px;
width:230px;" required readonly value="<?php echo $zone;?>"
></td>

</tr><tr><td>woreda:</td><td>

<input type="text" name="woreda" style="font-

size:12pt;color:black;border:1px solid gray;padding:2px;
width:230px;" required readonly value="<?php echo $woreda;?>"
></td>

</tr><tr><td>city:</td><td>

<input type="text" name="city" style="font-

size:12pt;color:black;border:1px solid gray;padding:2px;

65
width:230px;" required readonly value="<?php echo $city;?>"
></td>

</tr><tr><td>kebele:</td><td>

<input type="text" name="kebele" style="font-

size:12pt;color:black;border:1px solid gray;padding:2px;
width:230px;" required value="<?php echo $kebele;?>" ></td>

</tr><tr><td>registration date:</td><td>

<input type="text" name="regdate" value="" style="font-

size:12pt;color:black;border:1px solid gray;padding:2px;
width:230px;">

</td></tr><tr><td>birthstatus:</td><td>

<input type="text" name="birthstatus" value="born"

style="font-size:12pt;color:black;border:1px solid
gray;padding:2px; width:230px;" required="">

</td></tr><tr><td> Kebele officer:</td><td>

<input type="text" name="kooficer" value="<?php echo $id;

?>" style="font-size:12pt;color:black;border:1px solid
gray;padding:2px; width:230px;" readonly>

</td></tr><tr><td width="230px" height="40px"></td><td>

<input type='submit' name='register' value='registerbirth'

class="btn">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

<input type='reset' value='Clear' id="reset">

</td></tr></table></form></fieldset></div></td></tr>

<tr><td><div id="divFooter"><?php require("footer.php")

?></div></td></tr></table></div>

<?php } else { header("location:home.php"); } ?></body></html>

66
Chapter five

5. Testing

5.1. Unit testing

Unit testing is a software verification and validation method in which a programmer tests if
individual units of source code are fit for use. The FDRE vital events information
management system units are tested one by one.

5.2. Integration testing

Combining modules and testing them is called integration testing. Integration testing is
gradual. First we test the highest level, or coordinating module, and only one of its
subordinate modules.

After unit testing, the FDRE vital events information management system is also tested
whether every unit is integrated to each other.

5.3. System testing

System testing of software or hardware is testing conducted on a complete, integrated system
to evaluate the system's compliance with its specified requirements. It is a testing process in
which the aim is to ensure that the overall system works as defined by the requirements. [9]

5.4 sample test

67
Figure 18 sample test for create account

68
 Chapter six

6. Conclusion and recommendation

6.1. Conclusion
The FDRE vital event registration information management system is comprehensive vital
event registration information management system software. It is designed for better
interaction between citizens, registrars, statistician, and other stakeholders. This management
system handles all the requirements for vital event registration system. The system can be
accessed from anywhere which enables the citizens, registrars, statistician, and other users of
the system can contact with each other at all times easily.

6.2. Recommendations
The system we have developed is an automated vital event registration information
management system it needs to train users how to interact with the system. So, we
recommend the system should run by the responsible and trained user. We also recommend
the system hardware and software parts should be kept in secured condition.

6.3. Future enhancement

As a new system developer, we recommend the following functionalities are more done such
as:-

 Develop better error detection mechanism.

 Integrate with different systems that are in different organizations eg:- Statistics
agency, hospitals and other healthcare centers etc.
 Make this system to work with different language of the country.
 Making the system more secure.
 Develop better statistical analysis methods

69
 Appendix I
APPROVAL OF ADVISOR AND EXAMINERS

This project has been submitted for examination with in the approval of the
project advisor.

Advisor Name ____________________ Signature ____________

This project has been examined with our approval as the project examiner.

Examiner Name:

1. ____________________ signature______________

2. ____________________Signature______________

3. _____________________Signature_____________

70
 References
[1]. Technical Feasibility, Economic Feasibility, Operational Feasibility, and Legal
Feasibility:http://www.freetutes.com/systemanalysis/sa3-technical-economic-operational-
legal.html
[2]. Definition of functional requirement: http://www.ops.fhwa.dot.gov/functional-
requirement
[3] Definition of functional requirement & non-functional requirement:
https://reqtest.com/requirements-blog/functional-vs-non-functional-requirements/

[4]. Activity diagram: https://en.wikipedia.org/wiki/Activity_diagram

[5]. Class diagram: https://en.wikipedia.org/wiki/Class_diagram
[6].Physical Data Model:https://www.1keydata.com/datawarehousing/physical-data-
model.html

[7].about FDRE vital events registration system: www.vera.gov.et

[8].definition of implementation: https://en.wikipedia.org/wiki/Implementation

[9]. about system testing

http://ce.sharif.edu/courses/8586/2/ce924/resources/root/Presentations/3.%20OOTesting.pdf
&https://ijcsits.org/papers/Vol2no22012/40vol2no2.pdf

71