Land Mangement System

Mekelle University Mekelle Ethiopia
Land Registration system (In The Case Of Mekelle City)
By
Group Members: Birhan W/Gebreal (EI T/UR0065/05)
Adeladay Meressa (EI T/UR0040/05)
Amanuel Bizualem (EI T/UR0047/05)
Beriha Hadigu (EI T/UR0058/05)
Eleni Beyene (EI T/UR0085/05)
Alem G/kirstose (EI T/UR0044/05)
A FINAL PROJECT REPORT SUBMITTED IN PARTIAL FULFILLMENT OF

THE REQUIREMENTS FOR THE DEGREE OF BSc. In Computer Science
Project Advisor: Fkrezgy yohhanes
Mekelle University
Ethiopian Institute of Technology-Mekelle
School of Computing
2015/16
Designed school of computing computer science students Page i

Certificate
This is to certify that “Land Registration System”

-------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------
----------------------------------
By
Group Members: Birhan W/Gebreal (EI T/UR0065/05)
Adeladay Meressa (EI T/UR0040/05)
Amanuel Bizualem (EI T/UR0047/05)
Beriha Hadigu (EI T/UR0058/05)
Eleni Beyene (EI T/UR0085/05)
Alem G/kirstose (EI T/UR0044/05)
Name of Advisor: Signature: ________
Name of School Head: Signature ________
Examiner-1 Name: Signature: ________
Examiner-2 Name: Signature: ________
Designed school of computing computer science students Page i

Acknowledgement
First of all thanks to God for helping us to overcome this project. Then our grateful
thanks go to our advisor Instructor. Fkrezgy Yohhanes for his special contribution,
support, directions assistance, guidance and helping us throughout the project. Special
thanks should be given to our department supplying project writing guidelines and
noticing the final time of the project which accelerated us to accomplish our task at a
time. Besides, this project makes us realized the value of working together as a team
in sharing and developing ideas, which challenges use every minute. Not forget, great
appreciation go to Mekelle Town Land Administration staffs who played a great role
in our analysis phase by giving us information we want. Their patience and responses
to our question is unforgettable. The whole program really brought us together to
appreciate the true value of friendship and respect of each other.
Designed school of computing computer science students Page ii

Abstract
This project is concerned with the introduction, analysis, design and later on the
implementation of LRS. The current Land registration system is currently working by
using manual way which means fully paperwork, which consist a lot of man power
and time in managing the record and Registration process. And human mistake is
unavoidable while the workload is increasing. Therefore we motivate for the
developing of Land Registration System, which making their Registration process
form paperwork into automate system. Land registration system other than replace
their manual work such as Registration, Transaction, also including new function such
as online View Parcel information any time anywhere.
Designed school of computing computer science students Page iii

Contents
Chapter one...............................................................................................................................1
1. INTRODUCTION........................................................................................................1
1.1 Background of the project...................................................................................................1
1.2 Statements of the problem..............................................................................................2
1.3 Objective of the study.....................................................................................................2
1.3.1 General objective.....................................................................................................2
1.3.2 Specific objective.....................................................................................................2
1.4 Significance of the project..............................................................................................3
1.5. Scope of the project.......................................................................................................3
1.6 Methodology...................................................................................................................4
; 1.6.1 Data sources........................................................................................................4
1.6.2 Data collection method............................................................................................4
1.6.3 Tools to use..............................................................................................................4
1.6.4 Software use.............................................................................................................5
1.7. Budget planning.............................................................................................................5
1.8. Time schedule................................................................................................................5
Chapter Two.............................................................................................................................6
System Analysis...................................................................................................................6
2. Introduction..................................................................................................................6
2.1. Purpose of the project................................................................................................7
2.2. Scope of the system...................................................................................................7
2.3. Objectives and success criteria of the project.............................................................7
2.4. Definitions, acronyms, and abbreviations..................................................................7
2.5. Current system description.........................................................................................8
2.5.1 Registration Procedure and Registration..................................................................8
2.6. The proposed system..................................................................................................9
2.6.2 Functional requirement..........................................................................................10
2.6.3 Nonfunctional requirement....................................................................................12
2.7. System modeling.........................................................................................................14
2.7.1 Scenarios................................................................................................................14
2.7.2 Use case Diagram..................................................................................................14
2.7.3. Use case description.............................................................................................17
Designed school of computing computer science students Page iv

2.8. Analysis object model..................................................................................................23

2.9. Dynamic modeling.......................................................................................................25
2.9.1 Sequence diagram..................................................................................................25
Chapter Three.........................................................................................................................28
3. System Design Document...............................................................................................28
3.1 Purpose of the SDD..................................................................................................28
3.2. Design Goal.................................................................................................................28
3.3. Definitions, acronyms, and abbreviations....................................................................28
3.4. Overview:....................................................................................................................29
3.5. Current System Architecture........................................................................................29
3.6. Proposed System Architecture.....................................................................................29
3.6.1 Overview...............................................................................................................31
3.7. Subsystem decomposition............................................................................................31
3.8. Hardware/software mapping........................................................................................32
3.9. Persistent data management.........................................................................................33
3.9.1 Database schema........................................................................................................35
3.10. Access Control and Security......................................................................................36
3.11. Global software control..........................................................................................38
3.12. Boundary Condition...............................................................................................38
3.13. Exception Handling...............................................................................................39
3.14. Sub system Description..............................................................................................39
Chapter four............................................................................................................................43
4. Testing and debugging....................................................................................................43
4.1. Introduction.................................................................................................................43
4.2. Objective......................................................................................................................43
4.3. Form Layout design.....................................................................................................43
4.3.1 Log in form............................................................................................................43
4.3.2 Add user form........................................................................................................44
4.3.2 Parcel Registration form........................................................................................45
4.4. Testing.........................................................................................................................46
4.5. Coding.........................................................................................................................46
4.4.2. Unit Testing....................................................................................................46
4.4.3. Acceptance Testing.........................................................................................48
Designed school of computing computer science students Page v

4.4.4. System Testing................................................................................................48

Chapter Five.......................................................................................................................48
5. Conclusion and Recommendation...................................................................................48
5.1. Conclusion...................................................................................................................48
5.2. Recommendation.........................................................................................................49
6. Glossary..........................................................................................................................49
7. Reference....................................................................................................................51
Table of figures
FIGURE 2.1 USE CASE DIAGRAM....................................................................................16

FIGURE 2.2 CLASS DIAGRAM........................................................................................24
FIGURE 2.3 SEQUENCE DIAGRAM FOR LOGIN...............................................................25
FIGURE 2.4 SEQUENCE DIAGRAM FOR REGISTER..........................................................26
F;IGURE 2.5 SEQUENCE DIAGRAM FOR ADD USER........................................................27
FIGURE 3.1 PROPOSED SYSTEM DIAGRAM....................................................................31
FIGURE 3.2. DEPLOYMENT DIAGRAM...........................................................................32
TABLE 3.1 DATA OBJECT FOR CLASS LAND OWNER......................................................33
TABLE 3.2 DATA OBJECT FOR AUDIT LOG CLASS..........................................................33
TABLE 3.4. DATA OBJECT FOR CLASS PARCEL.............................................................34
TABLE 3.5. DATA OBJECT FOR CLASS ACCOUNT.........................................................35
FIGURE 3.2 DATABASE SCHEMA...................................................................................36
TABLE 3.6. ACCESS CONTROL......................................................................................37
FIGURE 3.6. SUBSYSTEM ARCHITECTURE.....................................................................39
Designed school of computing computer science students Page vi

Chapter one
1. INTRODUCTION
Development literature is filled with information concerning the importance of land
and land rights in the economic development process. Individual and secure land
tenure rights are vital components of a productive agricultural sector, which is crucial
to poverty alleviation and economic growth. In most instances, secure land tenure
requires that legal rights to land are adequately defined and documented. Defining and
documenting land owners' legal rights and the extent of the landholding are important
for simplifying land transactions, using land as collateral for credit, and enabling land
administration.
1.1 Background of the project

Mekelle City is one of the zones under Tigray region. It is a much known zone that
consists of 7 sub city (woredas) each sub cities has their own land administration
office. The city has officially independent land administration which is known as
mekelle City Land Administration Office. That transfer and administer lands in the
city. Before 2004 EC the area of mekelle city is not known. But later new master plan
study the area of city calculated to 39.027km2 that makes mekelle city distinct which
contain 19 kebeles. The land administration office transfer lands based on status of
land use for:-
1. Residence
2. Business
3. Social service
4. Industry
5. Urban agriculture
6. Mixed use
Some type of land registration system is a necessary element of a developed market

economy. Land is a fundamental resource that is most effectively used and exchanged
when the rights to land are registered. Designing a land registration system requires a
comprehensive analysis of why land registration is necessary.
Designed school of computing computer science students Page 1

1.2 Statements of the problem

Because of existing system of the land administration is fully manual (data storage
and search, file about the owner and document identification method), it leads to
losing very sensitive data. Another problem of existing system is security issue where
anybody who enters to the record office sees owners profile and can update it as
he/she want. Due to unorganized database about the lands the town losses a much
money and time in every years. This led time delay to assign the land to customers.
On the other hand, there is the case where more than two individuals own one plot
that raises conflict between communities. Generally the problem of the services
delivery at mekelle town administration office could be put as follow.
 Data storage and retrieval system is not automated. The amount of vacant land
and plotted land is known but not recorded in the database.
 There is high redundancy in data storage.
 Land preparation and allocation for investment is inefficient and time
consuming that results delays and frustration especially for investors.
 This discourages investment activity in the city.
 Allocation of a given pieces of land to more than one applications owner
leading to conflicts.
 Cross checking manual documents of the owner by document identification
method is very difficult.
 Very let delivery of owners land registration
 It is less secure as it is vulnerable to unauthorized access; any one enters to the
office see owners profile, edit manual document, data theft and unauthorized
data modification as it’s accessible by anyone who has access to the room
(including the janitors).
1.3 Objective of the study

1.3.1 General objective
The general objective of this project is developing Web based application
Land Registration System.
1.3.2 Specific objective

 To minimize data redundancy on the files and the form.
 To save man power and time.

 Improve access to land record information

 To update owners document when transaction is needed such as;-
 Selling
 Gift
 All the customer record information’s are kept properly in well-

organized database.
 The system allows the following operation:
 Searching, Updating, and deleting record
 To design an efficient database.

1.4 Significance of the project
The project aims to improve the registry and filing system for Mekelle City
land administration office. Land is scarce resource that should manage
carefully and gives crucial role play in the economy. So efficient and Careful
administration is required to make the best of it. Regarding this the project
contributes to the Achievement of such goals. Since the existing filing system
is in manual manner (data storage and search, file about the owner and
document identification method) it leads to losing very sensitive data.
So the project will:
 Emphasizes on automating database that store and retrieve documents about

owner of the land.
 Helps Mekelle City administration to avoid delay in service delivery,
enhancement activities.
 Ensures Security issue by developing password protected database that allows
only database Administrator.
 The project team, getting experience
 Land owners can get service easily.
1.5. Scope of the project

Mekelle city municipal is subdivided into different organs like: land administration,
tax administration, house administration etc. Among this our project emphasis on

automating information system of the city land administration specifically Land

Registration system. That is to change the manual system into automated system. The
project attempt to
 Design a system that could be applicable to the city land administration office.
However the issue of land taxation would be out of our scope. Since it has its
own administration.
 The system is web based and mainly used for Land registration purpose.
 It allows to update owners profile when land bequests, splitting, merging,
selling is needed.
 The system allows the following operation:
 Searching
 Updating
 deleting record
1.6 Methodology
; 1.6.1 Data sources
The main data source for this project was the office of Mekelle city land
administration.
1.6.2 Data collection method

Data collection methods are the most important part of our project to find the main
requirements of system and how to understand the system is does. To gather the
information we used data collection methods that mentioned as follow:-
 Interview: to gather information from representatives of the city land

administration in order to get crucial information we need for the project and
also from direct users regarding the procedures of residents registration and
documentation system.
 Questionnaires’: We prepare questionnaires for mekelle city land
administration system office and we get enough information about the existing
system.
 Observation: to understand system process.
1.6.3 Tools to use

Use case: - used to describe interaction between user and system.
Sequence diagram: - depicts system interaction arranged in a time sequence

Class diagram: - the graphical representation of various system elements such as

process flow, data relationship and program structures for the proposed system of
Land Registration
1.6.4 Software use

 HTML, Css, JavaScript, markup language for front end
 Wamp server for back end
 PHP framework
 Microsoft SQL for back end
 Sniping tools Image capture to help users how to use the system
 Microsoft office to write documents
1.7. Budget planning

For the purpose of administering this project we required to budget for different
resources as Shown below: -
NO. Material Amount Price(ETB) Total
1 Paper 1 pack 90birr 90birr
2 Pane 5 4birr 20birr
3 CDRW 2 8birr 16birr
4 Blank cd 2 7.50birr 15birr
5 Removable Disk 1 200birr 200birr
6 Copy and print - - 100birr
7 Pencil and Eraser 3 1birr 3birr
8 Transportation - - 150birr
9 Laptop 1 - -
Total 594ETB
1.8. Time schedule

In order to use our time effectively and accomplish activities in their precedence we
have arrange main activities with their respective duration as the following.

No. Task name Duration Start date End date
1 Title selection 1 week October 28,2015 November

4,2015
2 Data collection 1 week November November

5,2015 11,2015
3 Data analysis 2 weeks November November

12,2015 26,2015
4 User interface 2 days November November

design 27,2015 29,2015
5 Database design 5 days November December 4,2015

30,2015
6 Coding 2 weeks December December

5,2015 18,2015
7 Testing 1 week December December

19,2015 25,2015
8 Maintenance 1 week january1,2015 january1,2015
9 Document 2 week January 2,2015 january16,2015

preparation
Chapter Two
System Analysis
2. Introduction
There is land registration process in Ethiopia land registration is a process of
registering land information which is an immovable property of the person who have
the right to hold land. In the case of mekelle city there is a land registration institution.
The registration institution has a responsibility of registering and issuing certificate
for land owner. But the registry process is done by manual registry form.

2.1. Purpose of the project

;The purpose this document is to describe the requirement analysis document which
includes current system description, activity provided by existing system, overview of
proposed system, functional and nonfunctional requirements. And the next is system
designing that contain: physical and logical design, design tool (use case diagram,
sequence diagram, and class diagram).
2.2. Scope of the system

Mekelle city municipal is subdivided into different organs like: land administration,
tax administration, house administration etc. among these our project emphasis on
automating information system of the city land administration specifically Land
Registration system. That is to change the manual system into automated system. The
automated system will be a web based intended to overcome existing challenges by
providing the following features.
 It allows to register parcel information of the owner

 It allows to update owners profile when land bequests, splitting, merging,
selling is needed.
 Generating conclusive evidence concerning the status of rights to land.
 Updating existing land right record
 Allowing prospective purchaser to view status of a particular parcel
 Issuing a certificate and ownership to the owner.
2.3. Objectives and success criteria of the project

The general objective of this project is to develop a Web based Land Registration
System to register land holding rights of the owner in the database.
2.4. Definitions, acronyms, and abbreviations

Register Officer: means all organ established or designated by a region at
appropriate level to undertake registration of urban land and immovable property
information and is accountable to the appropriate body;
FR: functional requirement
NFR: nonfunctional requirement
Customer (Land Owner): a person who have the right to hold land or the owner of
the land.
Administrator: A person who control or manage all the functionality of the system.

Parcel: means an area of land its boundary extent is clearly defined and demarcated
on the ground and drawn upon a map with rights having a unique parcel identification
code;
Account: Means an attribute of the actor used to enter in the system.
Registration institution’s registering institution" means all organ established or

designated by a region at appropriate level to undertake registration of urban land
and immovable property information and is accountable to the appropriate body;
2.5. Current system description

In this section we briefly review the current system used by Mekelle Town Land
Registration followed by a brief description of the problems associated with the
current system and a proposed system that aim to solve these problems. Currently the
land administration system has no automated system for registering the available land
and keeping users or customer’ data. The customer who asks for land enters in to the
land administration office by registering his/her full addresses and information about
requested land (for what purpose, preferred area of location, City, sub city, kebele,
Parcel number and etc.) the clerks has customer registration format prepared on a
paper which asks information like, Customer’s full name, address, date, purpose of
requested land etc. The main tasks of existing system are summarized below.
Use manual system to register land information.

Related data is not well organized.
Updating, deleting land information is very late.
The customer land information is not secure.
To Cross checking land registered among federal and regional
government use manually
2.5.1 Registration Procedure and Registration

Step 1.Submit application letter for land holding registration
Step 2.The register institution Receiving Applications for Registration.
Step 3.The registration institution verify Applications for Registration
Step 4. Register land holding right
Step 5. Own certificate
Step 6. If transaction is needed update Landholding Information

2.6. The proposed system

The proposed system deals with automating the registry system of Mekelle town land
Registration. The new ensures;
 accelerating the economic, social and environmental development of urban

centers by ensuring land holders security of landholding right and
recognition of title to immovable property by certifying the right through
registration.
 A document specifying the right, restriction and responsibility of person
having a land use right shall be prepared on paper and digital form for each
parcel.
 Each parcel of land shall be assigned with a unique identification code
 Update full information of customers when transaction is needed like bequest
and selling.
2.6.1 Overview
The proposed system is also efficient in file handling system. The major thing in the
proposed system is authenticating typical users. Authorized users only access the
system. Unauthorized person is not allowed to access the system. They are prevented
by user name and password mechanism.
The need to develop automating registration system of the Mekelle town land
administration to register land is that current activities of the administration are time
consuming and labor intensive due to manual system. Consequently delays the
development of the town.
The system registers Land information of the owner easily to identify individuals who
own lands. When an individual requests for land, first his full information is
registered and checked on a database weather he has register land before means The
system identifies the customer whether he/she is resident or new comer by checking
their document id during registration. Services given by proposed system are
summarized as below:
 The system gives document ID for the documents of an individual who take
plot to identify them.

 It gives fast accelerated service for all users.

 It can search required information.
 It control data of customer as needed
 It can save time for the customer and workers.
 It hold data base in well-structured and organized manner.
 It is easy to search, retrieve, update and delete.
 The system has high security, because the user can only enter into the
system by user name and password.
 Any unauthorized person can't enter in to the system.
 Administrators of the system can manage all database of the system.
 System identifies person who registered before and new person.
2.6.2 Functional requirement

The functional requirements are the features that the system must include to satisfy
the system need and to be acceptable by the user. The functional requirements of
proposed system are:-
List of Functional requirement
[FR-01]: add user
Description: The system must continuously add user based on the correct
input given.
Requirements: The system need inputs like full name, username, user type like
registrar officer, administrator, and landowner to add user. Fill the inputs correctly
and then click the add user button.
Ranking: Essential
[FR-02]: Register

Description: The system must register land owner information and parcel
information correctly.
Requirements: The system need inputs like full name, address, age, gender,
parcel code marriage status, region, registration date, sub city, city, kebele,
occopetion, tenure type, service, encumbrance, anualfee, area.
Ranking: essential
[FR-03]: Delete user
Description: The systems delete land owner information as well as personal
information.
Requirements: The system must allow the administrator to delete user in the
system .to delete first search the lad owner information by name and then click
delete button.
The system must allow the Registrar to delete parcel in the system.
Ranking: essential
[FR-04]: Search user
Description: The system must provide the functionality for searching for
previous
Transactions.
Requirements: The system must allow the user to search according to: Name
Ranking: Essential
[FR-05]: View parcel information

Description:thesystemviewparcelinformationlikefullname,address,age,gender,
parcelcodemerigestatus,region,registrationdatdate,subcity,city,kebele,occopeti
on,tinertype,service,encumbrance,anualfee,area.
Requirements: The system must allow viewing parcel information.toview the
information first search by name and then click the view button.
Ranking: Essential
[FR-06]: update parcel information
Description: making or becoming different from the previous record.
Requirements: To update land owner information you must search the land owner
information by name and update what you want record then click update update.

Ranking: desirable
[FR-07]: export certificate
Description: The system must allow export certificate with full information.
Requirements: To export the certificate click export certificate button.
Ranking: essential
2.6.3 Nonfunctional requirement

A Non-Functional Requirement is usually some form of constraint or restriction that
must be considered when designing the solution. Non-functional requirements of the
proposed system are:
[NFR-1] usability
Description: the system must be easy understandable by the clients.
Requirement: the system is object oriented approach.
Rank: essential.
[FR-2] reliability
Description: it describes the functionality of the system
Requirement: the system must be includes all the requirements of the client.
Rank: essential.
[NFR-3] performance
Description: describes the ability of the system for its function and
Waiting for an application to load can be frustrating for an end user. so make them
a quick start up is extremely important.
Requirements: The System must have a startup time of less than 5 seconds,
Ranking: Desirable
[NFR-4] response time for searching

Description: The system must report results from searches within a specified period
Of time.
Requirements: The following minimal performance requirements must be met for a
Reasonably fast machine:
1. When the system searches according the request, the results from the search
Must be reported within 30 seconds.
2. When the system searches through the entire database, the results
From the search should be reported within 30second.
Ranking: Essential
[NFR-5 supportability.
Description: the system must be run in all operating systems.
Requirement: The system must compile and run successfully on any Windows.
Rank: essential.
[NFR-6] Legal
Description: the system is legal in terms of federal democratic republic Ethiopian rule
in article 40(7) of the constitution.
Requirements: the system must fill full the rule and regulation of Ethiopia.
Rank: desirable
[NFR-7] implementation
Description: The system is implemented using PHP, HTML and uses MySQL for
database.
Requirement: the system must be corrective, adaptive, or perfective though time.
Rank: desirable.
[NFR-8] interface
Description: boundary between the user and the system.
Requirement: the system has an interface that enables for the data flows
To and from the data base.

Rank: essential.
[NFR-9] packaging
Description: installing of the system by the client to use it.
Requirement: the installation time must be less than 5minutes.
Rank: essential.
2.7. System modeling

2.7.1 Scenarios
Scenario name: Land Registration
Participating actor User: Adeladay: register officer: Amanuel
Adelady wants to register the land information in land registration institution. First
Adela day apply to registering institution for registration. Because the application for
registration shall be made by filling the forms prepared by the registering institution
for this purpose and upon payment the service fee. The register officer amanuel shall,
upon receiving a duly completed application form for landholding registration, assign
serial number in sequential order to each application to be placed in folder, and
also amanuel shall verify that the applicant's request. After that amnuel register
adeladys necessary information like, first name, Last Name, city, sub city, gender,
region, marriage status, address, document id, service type, parcel code, boundary,
area etc. Now Adeladays land information is correctly registered and take his
prepared certificate in the registration instution. But one day adeladay want to merge,
split, bequest or sell; to someone from his family member. So adeladay communicate
with amanuel in the registration institution after that register officer amnuel update
adeladys information to the required person and the new person can take certificate of
the land right.
2.7.2 Use case Diagram

An important part of the Unified Modeling Language (UML) is the facilities for
drawing use case diagrams. They separate the system into actors and use cases.
Use cases describe the behavior of the system when one of these actors sends one
particular stimulus. This behavior is described textually. It describes the nature of the
stimulus that triggers the use case; the inputs from and outputs to other actors, and the

behaviors that convert the inputs to the outputs. The text of the use case also usually
describes everything that can go wrong during the course of the specified behavior,
and what remedial action the system will take. Use case diagrams are used for
documenting the system’s behavior from the user’s point of view. Those diagrams are
used to identify the processes/ functions and the main elements which form the
system. The processes/functions are called use cases and the main elements are called
actors. The diagram also shows the interactions that occur with each of the actors,
with each use case. The UML notation for a use has the following three elements.
 An oval represents a use case,

 A stick figure represents an actor,
 An arrow between an actor and a use case represents that the actor initiates
and/or participates in the process.
Use case
Informally speaking, a use case is a story or a case of using a system by some users to
carry out a process. A bit more precisely speaking, a use case describes the sequence
of events of some types of users, called Actors, using some part of the system
functionality to complete a process.
Actors: An actor represents a coherent set of roles that are entities external to the
system can play in using the system, rather than representing a particular individual.
An actor represents a type of users of the system or external systems that the system
interacts with.
In this project we have three actors each has its own activities /use cases.
1. Register Officer
2. Customer(Land Owner)
3. Administrator
1. Register Officer; allows to performing the following action
Register customer; update Land holding right, view customer’s information when
needed.
2. Customer (Land Owner)

Can view his parcel information, change his own password, see and export his
certificate.
3. Administrator
A person who control or manage all the functionality of the system like; add user,
delete user, give privilege for users etc.
Figure 2.1 use case diagram
uc Use Case Mo...
Search
LogHistory
<<initiate>>
<<initiate>>
GenerateCertificate <<initiate>>
«include»
+<initiate>
«include»
<<initiate>> «include» AddUser

<<initiate>>
Update parcel «include»
<<initiate>> «include»
RegistrationOfficer
Login
<<initiate>> Administrator
initiate <<initiate>>
Register
<<initiate>> «include»
«include»
«include» DeleteUser
«extend»
«include»
View Parcel «include»
Logout
<<initiate>>
Delee Parcel
<<participate>>
Export and see

Certificate
Customer

2.7.3. Use case description
Use Case Name Login

ACTOR Initiated by: - Administrator, Customer and
Registration Officer.
Pre-condition the actor should have user name and password
Main flow 1. The admin open the system and click login
2.the system display login screen
3.the actor enter username and password to login
4.the system check validity username and password
5. the system login the user in
Post condition User to access the required page
Alternative flow of event 4.1. the user didn’t type of the correct displays
username/password
Or Do not have an account.
4.2. The system display the corresponding error try
again message.
Table 1: Use case description for login
Use case add user
Actors Administrator
Preconditions administrator has logged in

1- Use case begins when the administrator press add

user button
2- When administrator press the button the system
displays the form that asks F name, Lname, address,
username, password.. etc.
Flow of event
3- Administrator completes these attributes of the user
and press the submit use case.
4- The system validates the input.
5- System displays a message that account is
successfully created.
6- administrator session is closed
Post condition The user have been added to the system

4.1 The admin didn’t type of the correct username and
password.
4.2 The system display error message.

Alternate flow
Of event 4.3 The admin didn’t fill the correct value or missing some
forms.
4.4 System display error message in order to fill it again or

to fill it order valid value.
;
Table 2. Use case description for add user
Use case name Delete user

Actor Administrator
Pre-conditions 1. Administrator should be logged in
2. The system should display the user
profile form
Flow of event 1. The administrator selects delete option
2. The system displays delete options
3. The administrator selects the user to be
deleted
3. The administrator deletes the user profile
Post-conditions 1. User is deleted from the system

Exceptions 1. The administrator cancel the form

1.1 nothing is changed on the system
Quality Requirement The system responds in 25 seconds
Table 3. Use case description for delete user
Use case Register
Actors registration officer
Preconditions
actor enters to the system
1- Use case begins when the register

officer press register land owner
button
2- When register officer press the button
the system displays the form that asks
F name, Lname, address, username,
Flow of event password, service type, location,
boundary, city, sub city etc.
3- Register officer completes these
attributes of the user and press the
submit use case.
5- System displays a message that
account is successfully created.
6- Register officer session is closed
Land owner (customer) have been registered
Post condition correctly
4.1 The Register officer didn’t type of the

correct username and password.

Alternate flow
Of event
4.3 The Register officer didn’t fill the correct
value or missing some forms.
4.4 System display error message in order to

fill it again or to fill it order valid value.
Table 4. Use case description for register land owner
Use case name Search user

Actor Initiator:- Administrator
Pre-conditions 1. Administrator should be logged in
2. The system should display the user search
form
Flow of event 1. The system displays user profile options
2. The administrator selects the user search
form
3. The administrator selects search option
4. The system display search form
5. The administrator inserts Id of the user to be
displayed
6. The system checks whether the id is exists or
not
7. The administrator views the data
Post-conditions 1. The system displays the result whether the
user is found or not
2. No changes occur on the system
Exceptions 1. The administrator cancel the form
1.1 nothing is saved on the system
2. The administrator inputs invalid user Id
2.1 The system lets the administrator enter
to data again
Table 5. Use case description for search user

Use case name Update parcel

Actor Initiated by:- Registration officer
Participating actor:- Customer
Pre-conditions 1. Registration officer should be logged in
2. The system should display the user profile
form
Flow of event 1. The Registration officer fill the new
information of land owner
2. after filling the form The Registration officer
clicks update button
3. The system display successfully updated
message
Post-conditions 1. Land owner information updated correctly in
the database.
Exceptions 1. Registration officer didn’t fill the
correct value or missing some forms.
2. System display error message in order
to fill it again or to fill it order valid
value.

Table 6. Use case description for Update parcel
Use case name View parcel information

Actor Registration officer, Land owner
Pre-conditions 1. actor should be logged in
1. The actor search the required information

of land owner
Flow of event 2. after searching the system displays the
required information of the user
3. Actor can view the output.
Post-conditions 1. Land owner information displayed
correctly.
Exceptions 1. When actor searches the system
display there is no result in the in the
database.
.

Table 7. usecase description for view parcel information
Use case Update landholding right
Actors registration officer
Preconditions
actor enters to the system
1- Use case begins when the register officer press

Update land owner info button
2- When register officer press the button the system
displays the form that asks the attributes needed
;Flow of event
for transaction such as new owners profile and
what type of transaction (splitting, merging,
bequest).
3- Register officer completes these attributes of the
new owner and press the submit use case.

5- System displays a message that information is

successfully updated.
6- Register officer session is closed
Land owner (customer) information have been Updated

Post condition
correctly
4.1 The Register officer didn’t type of the correct

username and password.

Alternate flow
Of event 4.3 The Register Officer didn’t fill the correct value or
missing some forms.
4.4 System display error message in order to fill it again

or to fill it order valid value.
Table 8. Use case description for Update land owner’s info
2.8. Analysis object model

In this project we have seven classes each has its own activities.
1. Register Officer
2. Customer(Land Owner)
3. Administrator
4. Parcel
5. Account
6. Audit log
Register Officer; allows to performing the following action
Register customer; update Land holding right, view customer’s information when
needed. Customer (Land Owner) can view his parcel information, change his own
password, see and export his certificate.
Administrator: A person who control or manage all the functionality of the system
like; add user, delete user, give privilege for users etc.
code;

class Class Mo...
Customer(Landow ner)
+ address: string
+ age: int
Parcel + date: int
+ Documentid: string
+ Address: string + fullName: string
+ agreement era: string + Gender: string
+ anual fee: string + Id(primary key): string
+ Area: string + Kebele: string
+ Boundary: string + mariagestatus: string Administrator
- Encumbrance: char Own
+ Region: string
+ Id(foriegn key): string - Adress: string
1..* 1 + Subcity: string
+ Land tenure: string - age: int
+ Location: string - Fname: string
+ Exportcertificate() : void
+ parcelcode: string - Gender: string
+ Search() : void
+ Purpose: string - L name: string
+ View() : void
+ Givesurvice() : void + Adduser() : void

+ deleteuser() : void
1h as + search() : void
1
+ viewInfo() : void
has
1
Account
+ First name: string 1

+ Last Name: string
- Password: string
- User Type: string
Register
+ Username: string see
+ Change password() : void

+ Login() : void 1
+ Logout() : void
1
has
AuditLog
1..* + Date: int

+ profile: sring
RegisterOfficer + time: int
1 + user Name: string
+ adress: string
+ age: int + Report() : void
+ F name: string
+ Save() : void
+ Gender: string
+ L name: string
+ Delete Parcel() : void

+ GenerateCertificate() : void
+ search() : void
+ Update Parcel() : void
+ View Parcel() : void
Figure 2.2 Class diagram

2.9. Dynamic modeling
2.9.1 Sequence diagram
Describe interactions among classes in terms of an exchange of messages over time.
Sequence diagrams show a detailed flow for a specific use case or even just part of a
specific use case. They are almost self-explanatory; they show the calls between the
different objects in their sequence and can show, at a detailed level, different calls to
different objects. Sequence diagram models the sequential logic, ordering of messages
with respect to time. Sequence diagram is used

sd Use Case Mo...
Actor ApplicationForm LoginControler Login<<UI>> UserAccount

Login
Basic Course of action
click()
Initiate()
<<create>>()
enter username and password()
UserName()
Password()
Validate(Username,Password)
Invalid()
Invalid username or password Reenter again()
valid()
Succesfully Loged in()
acces required page()
X X X X X
Figure 2.3 sequence diagram for Login
Figure 2.4 sequence diagram for Register

sd Class Mo...
Actor Menu<<UI>> CustomerRegistration FormControler Registration<<UI>> DB
Click
CustomerRegistration link()
BasicCourseOfaction
Click()
initiate()
Create()
DisplayForm()
Fill
Form()
Invalid()
please enter correct input()
Valid()
Register()
Succesfully registerd()
Actor:
customer
X X X X
X
X

sd Class Mo...
administrator Menu add user account controller Form DB table
loged in to()
press()
create()
displayform()
fill form()
add user()
invalid input()
valid input()
submit()
sucessfuly added()
Figure 2.5 sequence diagram for add user

Chapter Three
3. System Design Document
3.1 Purpose of the SDD
This section focuses on the Design goal, descriptions of current software architecture,
proposed system architecture, subsystem decomposition, software and hardware
mapping, the user model of the system in terms of access control, the boundary
conditions: startup, shutdown, and error behavior of the system, and also a brief
description of the implementation plan for the subsystem. The purpose of design is to
model the structural aspects of the system architecture. So that one could see it as the
application of the systems theory to product development. For this project we used an
Object-Oriented analysis and design methods for our project which is widely used for
modeling software systems. ;
3.2. Design Goal

The goal of the system is to satisfy the functional and nonfunctional requirements as
specified in the RAD document. And also implement the system using Object
Oriented approaches. The purposes of OOD approach design are to provide an
overview of the proposed system and the information needed to derive the actual
implementation of the system /LRS.
3.3. Definitions, acronyms, and abbreviations

Design goal: describing the qualities of the system that developers should optimize.
Boundary condition: describing the system configuration, startup, shutdown, and

exception handling issues.
Subsystem: is a replaceable part of the system with wells-defined interfaces that

encapsulates the state and behavior of its contained classes.
Client/Server Architecture Often used in database systems:
• Front-end: User application (client)
• Back end: Database access and manipulation (server
Software architecture: describing the subsystem decomposition in terms of

subsystem responsibilities, dependencies among subsystems, subsystem mapping to
hardware, and major policy decisions such as control flow, access control, and data
storage.
RAD: Requirement analysis document
LAN: local area network
AVUDRC: add user, view, update, delete, register, change password

LRS: land registration system
OOD: object oriented design used to design the project by representing real world
things.
SDD: system design document
PHP: php hypertext preprocessor
3.4. Overview:
SDD focuses on the Design goal, descriptions of current software architecture,
proposed system architecture, subsystem decomposition, software and hardware
mapping, the user model of the system in terms of access control, the boundary
conditions: startup, shutdown, and error behavior of the system, and also a brief
description of the implementation plan for the subsystem. In this design phase, we
focus on the processes, data structures, and software and hardware components to
implement the system using structural or Object Oriented approaches.
3.5. Current System Architecture

Currently the System Architecture is a manual based Registration system, that’s why
we are intended to develop computerized system to solve the problem of this paper
based registration system for land. The land registration Institution uses manual based
architecture to store and process customers’ and parcel information. Thus we can say
the land registration System Institution have no specified architecture at the moment.
We are unable to document the current software architecture. Although we have not
observed any architecture it is common that web based application best fit with
client/server architecture.
3.6. Proposed System Architecture

This proposed system architecture describes the system architecture of LRS by using
OO architecture and has two main subsystems architecture. The land registration
Institution follows client/server architecture.
We use client/server architecture mainly to take advantage

• Centralized data management
• Data integrity and database consistency
• Database security
• Concurrent operations (multiple user access)

• Centralized processing (for example archiving)
In general the solution architecture advantage are listed below
 Low deployment and maintenance costs
Even if accessed by many users from different locations the system can be fully
managed and maintained by operating on the central server; no intervention is
required to install or maintain workstations.
 Access from anywhere
Users can access the system from any workstation running a generic Web Browser
that support both local and remote connections through the internet.
 High Data Security
End users can access the system data only through the application layer which
implements appropriate business rules to allow only authorized operations based
on the actual user permissions; no direct access to the physical database is needed.
 High System Reliability
The centralization of the data allows efficient monitoring and backup procedures; no
data is stored on clients.
; Registrar (e.g. register officer) user

LAN
Figure 3.1 proposed system diagram

3.6.1 Overview
The proposed system has sub component like view parcel and customer information,
account management, database, That means the registrar can access the LRS
application using local area network, and also the user can access LRS application
through the internet.
3.7. Subsystem decomposition

Register customer and parcel information
This sub system registers parcel and customer information process from collecting
information on a new user
Or retrieving account for an existing one.
View Information management
The user module includes the follow functionalities:
 View parcel information.
Database: - This component of the land registration System application comprise

relational database store information in various tables regarding parcel and customer
information, user detail, account detail, delivery Order and other service detail.
Account Management
- Add user account
- Delete user account

- Maintain the system

- Manage User Authentication and access control
3.8. Hardware/software mapping

The land registration system will have three main components: the client, the web
server and the database server. The web server of the land registration System will run
at HTML&PHP and will contain all subsystems. The database server will use WAMP
SERVER 2007 database and will handle all persistent data storage. Again, the client
will access the land registration System website through their internet browser (i.e.
Mozilla Firefox, Google Chrome, Internet Explorer…).The web server and the
database server will be hosted on the same physical machine. However it is possible
to place on separate machines is desired. Place on separate machines is desired.
deployment Component Mo...
Client Machine System APP
LRS
internet brow ser
Web Serv er
appache
DB serv er MySql
Figure 3.2. Deployment diagram

3.9. Persistent data management

The land registration system will use the WAMP SERVER 2007 database engine for
storing data. This will allow the database to be easily integrated with and accessed by
the rest of the system. The database will retain customer and parcel information. Each
of the items will be a separate table.
We describe data object for each table below.
Table 3.1 data object for class land owner
Table object Type Length Default value Null
Id Int 11 - X
First name Varchar 30 - X
Last Name Varchar 30 - X
Current City Varchar 30 - X
Sub city Varchar 30 - X
Kebele Varchar 30 - X
Marriage Status Varchar 30 - X
Gender Varchar 30 - X
Birth date Int 11 - X
Date Int 11 - X
Table 3.2 data object for audit log class
Date Int 20 - X
Time Int 20 - X

Profile name Varchar 30 - X
User name Varchar 30 - X
Table 3.4. Data object for class parcel
Parcel code Varchar 20 - X
Area Varchar 30 - X
Land level Varchar 40 - X
Land tenure Type Varchar 40 - X
North boundary Varchar 40 - X
South boundary Varchar 40 - X
East boundary Varchar 40 - X
West boundary Varchar 40 - X
Annual fee Varchar 40 - X
Agreement era Varchar 40 - X
Service Type Varchar 40 - X
Work Varchar 40 - X
;User name Varchar 20 - X
Password Varchar 15 - X

Table 3.5. Data object for class account

First name Varchar 30 - X
Last name Varchar 30 - X
User Name Varchar 20 - x
User type Varchar 20 - X
Password Varchar 15 - X
Where X represents not null
3.9.1 Database schema
A database consists of multiple relations.

Account: store information about accounts
User information: stores information about personal and parcel information
Account (First name, Last Name, Email, User name, password)
Land owner information (ID First Name, Last Name, City, sub city, birthdate,
Kebele, marriage status, gender, date)
Parcel (ID (Fk), parcel code, land level, area, service type, north boundary, south
boundary, east boundary, west boundary, land tenure type, annual fee, agreement era,
occupation
Comment (ID (FK), First Name, Last Name, Email, Message)
Audit log (user name (fk), profile name, date, time)

Figure 3.1 database schema
3.10. Access Control and Security

System access control and security is the main issue of the project. Therefore system
identify someone who is, what he/she wants to access, check whether the somebody is
authorized or not and granting permission or deny. Thus the system provides
protection over system from unauthorized users and allows those who have an
authority to access the system and even an authorized body forgot either of his/her
user name or password the system prompts to correct again. We are concerned with
information security and application controls. The information security of the land
registration System aims to preserve:-
 Confidentiality:
The only people to see the data those authorized to see it. Private data is kept
private; personal privacy is respected.
 Integrity:

There are limits on who can change the land registration System.
 Availability:
The registered parcel and customer information data is available at all times to
authorized users.
 Accountability:
It is possible to discover that after the event who has modified what data in the land
registration System
Where R: register, U: update, D: delete, V: View
Table 3.6. Access control
Register officer Administrator Land owner
R U D V R U D V R U D V
Persona Yes yes no y no no n ye no No No ye

l es o s s
Inform
ation
Accoun No yes no y yes yes ye ye no yes No ye

t es s s s
Parcel Yes yes no y no no n ye no No No ye

es o s s
Inform
ation
Audit no no no n no no n y no no no n
log o o e o
s

3.11. Global software control

Due to its nature as a website, the land registration will be event driven. When a user
is presented with a web page they will have the option of clicking on a number of
links. When a link is clicked, a function in the system management subsystem will be
invoked. Functions in a subsystem may call other functions within that same
subsystem or they may communicate with other system using the interface provided
in those subsystems. The registrar initiates the Land registration System (subsystem)
by logging in.) The administrator initiates account management subsystem in LRS by
logging in The land owner initiates view parcel information subsystem in LRS by
logging in.
3.12. Boundary Condition

 Startup and Shutdown
The land registration System does not have any startup or shutdown
procedures. Since it is a website, startup and shutdown are controlled by the
web server and host, both of which are outside of land registration System’s
scope. The website is designed to be online 24 hours a day; 7 days a week;
365 days a year except during system maintenance. If the web server and host
are running, then land registration System is operational.
 Initialization
The land registration System does not require any initialization upon system
startup. When creating the website for the first time some interesting persistent
data needed to be added to the database. However these operations can be
performed at any time. If the web server is rebooted for example, it is not
necessary to re-add the previously performed operations, since this
information already exists inside the database.
 Configuration: -The land registration System contains the following
configuration options:
 Add/Delete user account

3.13. Exception Handling

All exception handling will be managed by the Exception Handling subsystem. The
Exception Handling subsystem manages the following exceptions:
 Database Exception – Occurs when there is an error accessing the database.
Recovery from this error is achieved by displaying an error message stating
that the database is temporarily unavailable.
 Access Control Exception – Occurs when a user is trying to access a function
that they do not have permission to access. Recovery from this error is
achieved by preventing the user for executing this function.
 Data Validation Exception – Occurs when a user tries to add HTML, a DATA
BASE query, or any other unauthorized text into a string. Recovery from this
error is achieved by removing the unauthorized text.
cmp Component Mo...
registration management
v iew management
account management
database
Figure 3.6. Subsystem architecture

3.14. Sub system Description
Register customer and parcel
This sub system register parcel and customer information process from collecting
information on a new user or retrieving the account for an existing one.

View Information management

The user module includes the follow functionalities:
 Search and View parcel information by entering their id in the search
box.
 Export their certificate and view their information.
Database: - This component of the land registration System application comprise

relational database store information in various tables regarding parcel and customer
information, user detail, account detail, and other service detail.
Account Management
Account management is LRS sub system that are used to perform the following
operations
- Add user account
- Delete user account
- Edit profile
- Manage User Authentication and access control
Some input output mockups are discussed below.

Input for registration

Output for view information

Chapter four
4. Testing and debugging
4.1. Introduction
The implementation document enables the user (society) as well as the administrator
to work with the system and to use the application efficiently and effectively. It helps
users not to be confused with the system. It includes sample snapshot. It gives the
users a brief over view of the system.
4.2. Objective
The implementation is to change what we did in the design Phased to machine
readable form by writing code using php to all modules. The system contains many
forms that are connected to the data base in each individual form also combined in
one module in order to work the system as whole.
4.3. Form Layout design

4.3.1 Log in form
This page is available for registered users Register officer and for the administrator to
login and do different activities like adding users account, update user account, view list of
users, delete user account.

4.3.2 Add user form

This page is available for Administrator of the system can create account on the Add
user form in the following label.

4.3.2 Parcel Registration form

This page is available for Register officer of the system can Register Land owner in
the following form.

4.4. Testing
Final phase of implementation is testing. Testing is a process to show the correctness
of the program. Testing is checking of System Implementation
Implementation is the phase where objectives of physical operations of the system
turned into reality i.e. real working model. The crucial phase in the system
development life cycle is the successful implementation of the new system design.
The process of converting as new system into an operational one is known as system
implementation. This includes all those activities that take place to convert from an
old system to a new system.
4.5. Coding
The system workability in an attempt to discover errors and avoiding such errors from
the system. In this the team members tested the entire system as a whole with all
forms, code in this we tested all the functionalities in the System. All errors in the
forms, functions have been tested. The following are different testing strategies.
4.4.1. Unit Testing
Unit testing is every module of the System is separately tested. It is often done by the
programmer to test that the unit he/she has implemented is producing expected output
against given input.
Test Case 1:
Test Case ID = Administrator – TestCase02
Unit to Test = add user
Assumptions = successfully registered!
Test Data = first Name (invalid, Valid, empty)
Last name(invalid, valid, empty)
User type(Selected, empty)
Password (invalid, valid, empty)
conform password (not match, matched, empty)
Steps to be Executed Data Expected Results

Empty first Name and all
Any valid data for the other “First Name must
others filled and Click Add
fields Required”
button
Empty last name and Click Any valid data for the other “Last Name must
Add button fields and last name empty Required”
Not select user type and Not select user type “select user type you

Click add button want to be!”

Password not Match Type unmatched password "Password do not match!"
Test Case 2:
Test Case ID = register officer – TestCase01
Unit to Test = Registration
Assumptions = successfully registered!
Test Data = first Name (invalid, Valid, empty)
Last name(invalid, valid, empty)
City(valid, empty)
Sub city(valid, empty)
kebele(invalid, valid, empty)
Marriage status (selected, empty)
Gender(selected, empty)
Parcel code (invalid, valid, empty)
Land level(invalid , valid, empty)
Area (invalid, empty)
Service type (Selected, empty)
Boundary (invalid, empty)
Land Tenure(invalid, empty)
Annual fee(invalid, empty)
Agreement era(invalid, empty)
Encumbrance(invalid, empty)
Steps to be Executed Data Expected Results

Empty first Name and all “First name must have
Any valid data for the other
others filled and Click alphabet characters
fields
Register button only”
“Last name must have
empty last name and Click Any valid data for the other
alphabet characters
Register button fields and last name empty
only”
Not select Sub city and “select Sub city you
Not select Sub city
Click Register button Where!”
Not select Marriage Status "select Your Marriage
Not select Marriage Status
and Click Register button Status !"
Not Select gender and click Gender Not selected
“Please select gender!"
Register button.
Parcel code already exist Parcel code LA123 “The parcel code you

and Click register button enterd is already exist!"

All fields with valid data All fields with valid data Successfully
and Click Register button registered!
4.4.2. Acceptance Testing
Acceptance testing is the process of testing system (e.g. software, lots of

manufactured mechanical parts, or batches of chemical products) prior to its delivery.
A system is mainly developed for an end user normally a customer of the
organization. A system is said to be accepted if and only if the user of the system is
satisfied. In this perspective acceptance testing is widely used to prove that system
performs as per the requirements.
In acceptance testing the customers provides the input data to validate the system
operation. It is also known as functional testing, black-box testing, release
acceptance, QA testing, application testing, confidence testing, final testing,
validation testing, or factory acceptance testing
4.4.3. System Testing

It is the final step of testing. In this the team members tests the entire system as a
whole with all forms, code. This form of testing is popularly known as Black Box
testing or System tests. In this the team members tests all the functionalities in the
System. All errors in the forms, functions are tested.
Chapter Five
5. Conclusion and Recommendation
5.1. Conclusion
Generally in this project, we developed an automated LRS that facilitates various
activities taking place at the Mekelle Land Administration. The LRS do different
activities such as Parcel registration User registration, update parcel information,
delete parcel information and also anyone who has internet access can view parcel
information using the search service in the system. We realize that the existing system
is not capable of reducing errors and too backward to work in a flexible manner.
However, the newly developed system has dynamic features of manipulating and

managing data. Furthermore this document briefly describes the problems and the
solutions we proposed with the figures to visualize better and steps taken to solve the
problem. In other words this document introduces the technical details of the LRS. In
the first part of the technical design the major functions needed to develop LRS are
introduced. Later on, these major functions and their sub-functions are visualized with
the use case diagrams. In the second part, user interfaces are described in a detailed
manner with figures. Lastly, data modules and their relationships are discussed. We
believe from heartily that the existing problems of the LRS will be resolved and a
sustainable working environment will be created just by taking advantage of the
newly developed system. To conclude, this document constitutes a base for the
development of LRS. In addition, with implementing the new system will make the
overall system more convenient and give fast and reliable service for users which has
continuous relation with Land Administration office. Overall the implementation of
this project was an excellent learning opportunity for us.
5.2. Recommendation
This paper will recommend specific steps to transform the elements of the LRS in to
technologies. These steps, if taken, will result in better support to users while
expediting access to different information requirements and decreasing the workload
of the employees. These improvements will depend on the creation of an integrated
software development with one lead agent in charge of developing, maintaining, and
growing the architecture. The Land registration system is immense and expanding.
There should be one centralized element responsible for design control and
monitoring. It is imperative that automation is properly reviewed and focused around
the Core Task of Registration and user management. There needs to be a plan for the
entire system. This plan must be an active document that grows with changes while
anticipating future requirements. The following paragraphs will provide specific
recommendations Automation of Common Tasks: LRS tasks were manual
procedures. Instead of multiple manual submissions of identical information,
automation solutions could significantly simplify these tasks with the use of
standardized applications within existing software solutions. Rapid Response: Land
Registration System Automation must be responsive to the needs and requirements of
the Land owner and Land administration employees. The design must be responsive
enough to implement changes prior to requirements for users the final
recommendation is to establish effective, efficient and reliable information
Registration system for Land Administration as well as for all Land owners of
Ethiopia.
6. Glossary
Main terms
Use case: A use case expresses a contract between the stakeholders of a system about
its behavior. It describes the system’s behavior and interactions under various

conditions as it responds to a request on behalf of the stakeholders, the primary actor,

showing how the primary Actor’s goal gets delivered or fails. The use case collects
together the scenarios related to the primary actor’s goal.
Scenario: A scenario is a sequence of action and interactions that occurs under

certain conditions, expressed without branching.
Actor: Something with behavior. It might be a mechanical system, computer system,

a person, an organization or some combination.
Use case diagram: In UML, the diagram showing the external actors, the system
boundary, the use cases as ellipses, and arrows connecting actors to ellipses or ellipses
to ellipses. Primarily useful as a context diagram and table of contents.
Sequence diagram: In UML, the diagram showing actors across the top, owning
columns of space, and interactions as arrows between columns, with time flowing
down the page. Useful for showing one scenario graphically.
Class diagram: Class diagrams show the classes of a system and their
interrelationship’s. Class diagrams are often mistakenly referred to as object models.
Register Officer: means all organ established or designated by a region at

appropriate level to undertake registration of urban land and immovable property
information and is accountable to the appropriate body;
Customer (Land Owner): a person who have the right to hold land or the owner of
the land.
Administrator: A person who control or manage all the functionality of the system.
code;
Registration institution’s registering institution" means all organ established or

designated by a region at appropriate level to undertake registration of urban land
and immovable property information and is accountable to the appropriate body;
Tenure:-the condition under which land or buildings is occupied.
PHP: - PHP Hypertext Preprocessor used for back end.
HTML: - Hyper Text Markup Language used for front end.
SQL: - Structural Query Language.

CSS: - Cascading Style Sheet used to style the interface of web.
UML: - Unified Modeling Language.
RAD: Requirement analysis document
LAN: local area network
AVUDRC: add user, view, update, delete, register, change password
LRS: land registration system
OOD: object oriented design used to design the project by representing real world
things.
SDD: system design document
WWW: World Wide Web
7. Reference
(Proclamation) Federal negarit gazette (the whole document is depend on this
article because we concern Land registration in the case of Ethiopia)
Usable land registration system Pdf files(These was some useful guide for us to
understand the analysis phase )
Designing land registration system pdf file
object oriented software engineering hand out(For System design document)
Www.google .com specifically system designing with object oriented approach.
www.mekellelandadministration.gov.et

Land Mangement System

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

Land Mangement System

Uploaded by

Copyright:

Available Formats

Mekelle University Mekelle Ethiopia

Land Registration system (In The Case Of Mekelle City)

Group Members: Birhan W/Gebreal (EI T/UR0065/05)

Adeladay Meressa (EI T/UR0040/05)

Amanuel Bizualem (EI T/UR0047/05)

Beriha Hadigu (EI T/UR0058/05)

Eleni Beyene (EI T/UR0085/05)

Alem G/kirstose (EI T/UR0044/05)

A FINAL PROJECT REPORT SUBMITTED IN PARTIAL FULFILLMENT OF

Project Advisor: Fkrezgy yohhanes

Ethiopian Institute of Technology-Mekelle

Designed school of computing computer science students Page i

This is to certify that “Land Registration System”

Group Members: Birhan W/Gebreal (EI T/UR0065/05)

Adeladay Meressa (EI T/UR0040/05)

Amanuel Bizualem (EI T/UR0047/05)

Beriha Hadigu (EI T/UR0058/05)

Eleni Beyene (EI T/UR0085/05)

Alem G/kirstose (EI T/UR0044/05)

Name of Advisor: Signature: ________

Name of School Head: Signature ________

Examiner-1 Name: Signature: ________

Examiner-2 Name: Signature: ________

Designed school of computing computer science students Page i

Designed school of computing computer science students Page ii

Designed school of computing computer science students Page iii

Designed school of computing computer science students Page iv

2.8. Analysis object model..................................................................................................23

Designed school of computing computer science students Page v

4.4.4. System Testing................................................................................................48

FIGURE 2.1 USE CASE DIAGRAM....................................................................................16

Designed school of computing computer science students Page vi

1.1 Background of the project

Some type of land registration system is a necessary element of a developed market

Designed school of computing computer science students Page 1

1.2 Statements of the problem

1.3 Objective of the study

1.3.2 Specific objective

Designed school of computing computer science students Page 2

 Improve access to land record information

 All the customer record information’s are kept properly in well-

 The system allows the following operation:

 Searching, Updating, and deleting record

 To design an efficient database.

So the project will:

 Emphasizes on automating database that store and retrieve documents about

1.5. Scope of the project

Designed school of computing computer science students Page 3

automating information system of the city land administration specifically Land

1.6.2 Data collection method

 Interview: to gather information from representatives of the city land

1.6.3 Tools to use

Sequence diagram: - depicts system interaction arranged in a time sequence

Designed school of computing computer science students Page 4

Class diagram: - the graphical representation of various system elements such as

1.6.4 Software use

1.7. Budget planning

NO. Material Amount Price(ETB) Total

1 Paper 1 pack 90birr 90birr

2 Pane 5 4birr 20birr

3 CDRW 2 8birr 16birr

4 Blank cd 2 7.50birr 15birr

5 Removable Disk 1 200birr 200birr