MADDA WALABU UNIVERSITY COLLEGE OF COMPUTING

DEPARTMENT OF COMPUTER SCIENCE

FINAL PROJECT

TITLE: HOUSE RENTAL SYSTEM

For Bale ROBE CITY

Submitted to

College of computing department of computer science

Submitted by

1. Amberbr Belay

2. Binyam Negash

Feb, 2024

Robe Bale, Ethiopia

 Approval sheet

Project Title: ONLINE HOUSE RENTAL MANAGEMENT SYSTEM for ROBE CITY

Name of student signature date

Binyam Negash ___________________ _____________

Amberbr Belay ____________________ _____________

This project has been submitted for examination with my approval as university advisor

Advisor signature date

Tekalign Tujo ___________________ _____________

Approval for the examining board

Examiners Signature date

Examiner 1 ___________________ _____________

Examiner 2 ___________________ _____________

Examiner 3 ___________________ _____________

Approval for project coordinator

Project coordinator signature date

Mr. Tadele Shimeles ___________________ _________

Hod signature date

Mr. Mohammed Mekuriya ____________________ _________

 Executive Summary

Online House Rental Management System is developed for Bale Robe City. We were inspired to
develop this system because renting a house is not an easy activity. This is due to some problems
facing the tenants. Such problems are not knowing the exact location of the house to be rented;
this leads to fatigue in finding the house, and wastage of the of renter’s time and money. To avoid
these and some related problems we designed this online house rental system. We used an object-
oriented methodology to develop this system. Our project costs around $200,000, since our project
is for educational purposes, we did not ask any organization or investors for funds. In addition, it
was completed in five months. So we hope that the new automated system provides fast and
reliable service for tenants, and house owners by minimizing time and resource wastage with
advanced user interface experiences.

ii
 Acknowledgement

First of all, we would like to greatly praise almighty God, who gave us the power to understand
and better analyze the system. Secondly, we wish to express our hearts full thanks to our advisor
instructor Tekalgn Tujo. (Assistance professor) who is playing a great role by giving powerful
comments and different advice that helps our project. We want to thanks a Mr. Tadele for his
inspiring guidance and constant encouragement that will help us to completion of our project. Last
but not least we would thank 4th-year computer science students for sharing useful ideas and our
appreciation goes to our department lectures for their continuous encouragement and unlimited
support to do our project.

iii
 Contents
Approval sheet ............................................................................................................................................... i
Executive Summary....................................................................................................................................... ii
Acknowledgement ....................................................................................................................................... iii
List of Figures .............................................................................................................................................. vii
List of Tables .............................................................................................................................................. viii
List of acronyms ........................................................................................................................................... ix
CHAPTER ONE ............................................................................................................................................... 1
1. INTRODUCTION ..................................................................................................................................... 1
1.1 Background of the project .................................................................................................................. 2
1.2 Statement of the problem .................................................................................................................. 2
1.3. Objectives of the project.................................................................................................................... 3
1.3.1 General objective ......................................................................................................................... 3
1.3.2. Specific Objectives ...................................................................................................................... 3
1.4 Scope and limitation of the project .................................................................................................... 3
1.4.1 Scope of the project ..................................................................................................................... 3
1.4.2. Limitation of the Project ............................................................................................................. 4
1.5 Significance of the project .................................................................................................................. 4
1.6. Methodology and tools ...................................................................................................................... 4
1.6.1. Data collection methodology ...................................................................................................... 4
1.6.2. System analysis and designing method ...................................................................................... 5
1.6.3. System development tools ......................................................................................................... 5
1.7 Project management Technique ......................................................................................................... 8
1.7.1. Project schedule .......................................................................................................................... 8
1.7.2. Project budget (cost break down estimation) ............................................................................ 9
1.7.3 Project Work Break Dawn Structure (WBS), Responsibility, And Deliverable ............................. 9
1.7.4 Risk Analysis, Identification, Mitigation and Monitoring ........................................................... 10
1.8. Feasibility of the project .................................................................................................................. 11
1.8.1. Economic Feasibility .................................................................................................................. 11
1.8.2. Technical feasibility ................................................................................................................... 12
1.8.3. Schedule feasibility ................................................................................................................... 12
1.8.4. Operational feasibility ............................................................................................................... 12
Chapter Two: current system ..................................................................................................................... 13

iv
 2.1. Introduction ..................................................................................................................................... 13
2.2. Literature review.............................................................................................................................. 13
2.3. Description of the Existing System................................................................................................... 13
2.4. Drawback of the Existing system ..................................................................................................... 14
2.5. Practice to be preserved from the current System ......................................................................... 15
2.6. Business rules ................................................................................................................................... 15
2.7 Alternative solutions ......................................................................................................................... 15
2.8. Forms used ....................................................................................................................................... 16
Chapter Three: The proposed system......................................................................................................... 17
3.1 Overview of the proposed System .................................................................................................... 17
3.2. System constraints ........................................................................................................................... 17
3.3. Functional Requirements ................................................................................................................. 18
3.4. Non-Functional Requirements ......................................................................................................... 19
3.5. Graphical user Interface................................................................................................................... 20
3.5.1. Specification .............................................................................................................................. 20
3.5.2. User interfaces .......................................................................................................................... 20
3.5.3. User interface prototype (snap shoot) ..................................................................................... 20
Chapter four: System modeling .................................................................................................................. 21
4.1. Introduction ..................................................................................................................................... 21
4.2. Actor Identification .......................................................................................................................... 22
4.3. Use case Identification ..................................................................................................................... 22
4.4. System Use case diagram................................................................................................................. 22
4.4.1. Actor description....................................................................................................................... 23
4.4.2. Use case description (Scenario) ................................................................................................ 24
4.5. Dynamic modeling ........................................................................................................................... 31
4.5.1. Sequence diagram..................................................................................................................... 31
4.5.2. Collaboration diagram .............................................................................................................. 36
4.5.3 Activity diagram ......................................................................................................................... 37
4.5.4. State chart Diagram .................................................................................................................. 40
4.6. Object modeling ............................................................................................................................... 41
4.6.1. Class diagram ............................................................................................................................ 41
4.6.2. Object diagram.......................................................................................................................... 42
Chapter Five: System Design ....................................................................................................................... 44

v
 5.1 Introduction ................................................................................................................................ 44
5.2 Architecture Design........................................................................................................................... 44
5.2 .1 Component Diagram ................................................................................................................. 45
5.2.2 Deployment Diagram ................................................................................................................. 46
1.3 Database design .......................................................................................................................... 47
5.3.1 Entity Relationship Diagram (ERD) design ................................................................................. 48
5.3.2 Normalization............................................................................................................................. 49
5.3.3 Persistence diagram ................................................................................................................... 56
Chapter Six: System Implementation ......................................................................................................... 57
6.1 Introduction ................................................................................................................................ 57
6.2 User interface prototype (snap shoot) ....................................................................................... 58
6.3 Testing ......................................................................................................................................... 59
6.3.1 Unit testing.............................................................................................................................. 60
6.3.2 System testing ..................................................................................................................... 60
6.3.3 Acceptance testing .............................................................................................................. 60
6.3.4 Performance testing............................................................................................................ 61
6.4 Features to be tested and not to be tested ................................................................................ 61
6.4.1 Features to be tested .......................................................................................................... 61
6.4.2 Features not to be tested ................................................................................................... 62
6.4.3 Pass/ fail criteria.................................................................................................................. 62
6.5 System Manual (Documentation) ............................................................................................... 62
6.6 Support and Service .................................................................................................................... 63
Chapter Seven: Conclusion and Recommendation..................................................................................... 64
6.1 Conclusion ................................................................................................................................... 64
7.2 Recommendation References/bibliography ..................................................................................... 65
References .................................................................................................................................................. 66
Appendix ..................................................................................................................................................... 67

vi
 List of Figures
FIGURE 1 SYSTEM ANALYSIS AND DESIGNING METHOD ................................................................................................................5
FIGURE 2 TIME SCHEDULE OF THE PROJECT ..............................................................................................................................8
FIGURE 3 USER INTERFACE .................................................................................................................................................20
FIGURE 4 USER INTERFACE PROTOTYPE ..................................................................................................................................21
FIGURE 5 SYSTEM USE CASE DIAGRAM ...................................................................................................................................23
FIGURE 6 SEQUENCE DIAGRAM FOR CREATE ACCOUNT ..............................................................................................................32
FIGURE 7 SEQUENCE DIAGRAM FOR LOGIN .............................................................................................................................32
FIGURE 8 SEQUENCE DIAGRAM FOR CHANGE PASSWORD ..........................................................................................................33
FIGURE 9 SEQUENCE DIAGRAM FOR SEND REQUEST..................................................................................................................33
FIGURE 10 SEQUENCE DIAGRAM FOR VIEW REQUEST................................................................................................................34
FIGURE 11 SEQUENCE DIAGRAM FOR SEND RESPONSE ..............................................................................................................34
FIGURE 12 SEQUENCE DIAGRAM FOR UPLOAD HOUSE OR ROOM.................................................................................................35
FIGURE 14 SEQUENCE DIAGRAM FOR SEND FEEDBACK ..............................................................................................................36
FIGURE 15 SEQUENCE DIAGRAM FOR SEARCH A HOUSE.............................................................................................................36
FIGURE 16 COLLABORATION DIAGRAM ..................................................................................................................................36
FIGURE 17 ACTIVITY DIAGRAM FOR LOGIN .............................................................................................................................37
FIGURE 18 ACTIVITY DIAGRAM FOR REGISTER .........................................................................................................................38
FIGURE 19 ACTIVITY DIAGRAM FOR CHANGE A PASSWORD ........................................................................................................38
FIGURE 20 ACTIVITY DIAGRAM FOR UPLOAD A HOUSE ..............................................................................................................39
FIGURE 21 ACTIVITY DIAGRAM FOR VIEW OPTION ....................................................................................................................39
FIGURE 22 STATE CHART DIAGRAM FOR LOGIN .......................................................................................................................40
FIGURE 23 STATE CHART DIAGRAM FOR REGISTRATION ............................................................................................................41
FIGURE 25 SYSTEM CLASS DIAGRAM .....................................................................................................................................42
FIGURE 26 SYSTEM CLASS DIAGRAM .....................................................................................................................................43
FIGURE 27 ARCHITECTURE DESIGN DIAGRAM .........................................................................................................................44
FIGURE 28 COMPONENT DIAGRAM.......................................................................................................................................45
FIGURE 29 DEPLOYMENT DIAGRAM ......................................................................................................................................46
FIGURE 30 ENTITY RELATIONSHIP DIAGRAM (ERD) ................................................................................................................48
FIGURE 31 PERSISTENCE DIAGRAM.......................................................................................................................................56
FIGURE 32 UI DIAGRAM OF HOMEPAGE ................................................................................................................................58
FIGURE 33 UI DIAGRAM OF LOGIN ......................................................................................................................................58
FIGURE 34 UI DIAGRAM OF ADD PROPERTY .........................................................................................................................59

vii
 List of Tables

TABLE 1 HARDWARE REQUIREMENT .......................................................................................................................................6

TABLE 2 SOFTWARE REQUIREMENT.........................................................................................................................................7
TABLE 3 HARDWARE COST ESTIMATION...................................................................................................................................9
TABLE 4 TEAM STRUCTURE ...................................................................................................................................................9
TABLE 5 RISK AND CONTINGENCIES .......................................................................................................................................11
TABLE 6 CREATE ACCOUNT USE CASE DESCRIPTION ..................................................................................................................24
TABLE 7 LOGIN USE CASE DESCRIPTION .................................................................................................................................25
TABLE 8 USE CASE DESCRIPTION FOR CHANGE PASSWORD .........................................................................................................26
TABLE 9 USE CASE DESCRIPTION FOR SEARCH INFORMATION ......................................................................................................26
TABLE 10 USE CASE DESCRIPTION FOR UPLOAD HOUSE OR ROOM INFORMATION ...........................................................................27
TABLE 11 USE CASE DESCRIPTION FOR APPROVE HOUSE ...........................................................................................................28
TABLE 12 USE CASE DESCRIPTION FOR VIEW HOUSE INFORMATION .............................................................................................28
TABLE 13 USE CASE DESCRIPTION FOR SEND RESPONSE .............................................................................................................29
TABLE 14 USE CASE DESCRIPTION FOR UPDATE HOUSE INFORMATION ..........................................................................................29
TABLE 15 USE CASE DESCRIPTION FOR SEND FEEDBACK .............................................................................................................30
TABLE 16 USE CASE DESCRIPTION FOR VIEW FEEDBACK .............................................................................................................30
TABLE 17 USE CASE DESCRIPTION FOR LOGOUT .......................................................................................................................31

viii
 List of acronyms
Admin Administrator
BR Business Rule

GUI Graphical User Interface

HOD head of department
HO House Owner
OOA Object Oriented Analysis

OOD Object Oriented Design

OHRS Online House Rental System

GPS Global positioning system
PC Personal computer
UI User Interface
UML Unified Modeling Language

UC Use case

ix
 CHAPTER ONE

1. INTRODUCTION
In today's life everyone can communicate each other in all over. They share innovation and
information. More as of late it is the utilize of the computers and data innovation (IT) to progress
the proficiency and competitiveness of businesses that has driven to mechanical alter. Since
innovation is so quick, there are imperative suggestions for businesses. Websites are one of the
ways of streams of data. Individuals can get benefit by going by this websites. Leasing a house is
well known with people groups from all around the world. Regularly understudies and workers
that are moving briefly will share house leasing. The most reason of this extend is to create and
actualize “Online House Leasing Administration System” in arrange to actualize online house
Administration framework to assist tenants and proprietor to supply solid administrations. These
frameworks tend to us to discover conceivable arrangement almost the issue it makes a difference
client to get to the framework effectively.

The existing house rental framework in Parcel Robe city as of now employments the conventional
way of looking of house. The proprietor that needs to lease composes the opening (a few data)
approximately house and tag it on the entryway at that point the client studied that opening and
contact with him for leasing reason.

The manual house rental administration framework in Parcel Robe City have number of issues
like:

Take note may evacuate some time recently the client peruses it, wastage of time that the client
looking the house to lease, client devouring cash when they discover the house to lease and
proprietor to publicize the house, leaseholders lose their assets by finding house on foot from put
to put indeed they can't get house since most of houses are saved and they can't know where they
can get free house precisely, on the off chance that the client is unused to the town or doesn't have
that much data almost its encompassing, it'll difficult for him/her to seek for houses, client must
be present from the house put to get full data approximately the house, clients aggravate the tenants
by thumping windows to find leasing house and no computerized record of house (that's leased
and unrented).

1
These issues are troublesome for the client and the proprietor to perform the leasing handle. In our
venture we attempt to illuminate this issue.

1.1 Background of the project

Bale Robe Town, situated in the Bale Zone of the Oromia Region in Ethiopia, It is located about
430 kilometers by road from the capital Addis Ababa [1]. Which a rapidly growing urban center
with a vibrant community and increasing demand for housing solutions. As the town experiences
population growth and urbanization, the need for efficient and modernized house rental
management becomes paramount.

As more people seek rental accommodations for various reasons such as relocation, job changes,
or lifestyle choices, there is a pressing need for a sophisticated and automated solution that
streamlines the entire process of renting, managing, and maintaining properties.

Traditional methods of house rental management often involve cumbersome paperwork, manual
processes, and communication gaps between landlords, tenants, and property managers. These
inefficiencies can lead to delays, misunderstandings, and increased operational costs for both
property owners and tenants. Recognizing the challenges inherent in this sector, the Intelligent
House Rental Management System project aims to revolutionize and enhance the rental experience
for all stakeholders involved.

1.2 Statement of the problem

The existing house rental system in Bale robe Town currently uses the traditional way of searching
of house. The owner that wants to rent writes the vacancy (some information) about house and tag
it on the door then the customer read that vacancy and contact with him for renting purpose. This
manual system has problems those are mentioned as follows.

 The Notice posted by house owners may be removed from notice board or the house owners
gate, damaged by different factor (i.e. the rain hits notice, someone tears of the notice etc.)
Before the client reads it and Luck of promotion and awareness creation of goods and
services to customers especially to foreigners.

 Security Issues, customers are vulnerable security risks like chasing by dogs.

2
  Wastage of time and money: There is wastage of time and money that the user expenses
when searching the house to rent.
 Users Lack of information (about town): If the client is new to the town or doesn’t have
that much information about its surrounding, it will hard for him/her to look for houses.

1.3. Objectives of the project

1.3.1 General objective
The general objective of this system is to develop an automated web-based house rental
management system.

1.3.2. Specific Objectives

These activities that are performed in order to achieve the general objective. The specific
objectives of this proposed system are listed as follow:

 Design and build user-friendly user interface.

 Develop a web-based house rent system that enables users to search, view, and rent
available properties in a user-friendly and efficient manner.
 Implement a user-friendly property viewing feature that displays detailed information
about each property, including property images, descriptions, amenities, and contact
information for the users.

1.4 Scope and limitation of the project

1.4.1 Scope of the project
The scope of the project can be described as the overall features of what the new system is capable
of doing. This system has different features which make things easier for the user and the
organization.
Generally, our proposed system will support the following features.
 Upload their house or room.
 User can change password.
 Update house information.
 View uploaded house and free house
 Admin approve house.
 View request.

3
  Send response to the tenant.
 View houses information.
 View feedback.
 Send cancel reservation request.
 Send feedback.
1.4.2. Limitation of the Project
Our proposed project is not including the following activities:
 It does not include online payment.
 Our system does not support agreement canceling before due date.
1.5 Significance of the project
After implementing this project the system has the following benefits.

 Users can view house detail online even they are not in Bale robe Town they can view
before coming and they can directly go to the house after they come.
 The system is more secured than existing one so users can simply believe it.
 Save time of customer and owner, customers can not lose their time to finding a house
and the owner cannot lose their time to advertise their own house property by post
notice.
 Save resources of client so they cannot lose their time and money to search houses on
foot.

1.6. Methodology and tools

1.6.1. Data collection methodology
We use two data collection methods to collect the data need for the team project those are:

 Primary data collection method

 Observation: to gather relevant information the project team observes how
the current system works.
 Interview: We will have use this method to gather information by asking
the house owner and tenants. We will have also interviewed the of contract
in the office of “file and information handling”

4
  Secondary data collection methods
 Document analysis: the project team tried to discover written documents
about the organizational areas relevant to the project.
 Internet: Internet helps us to see the available samples and to download
different types of tutorials which help us in developing the system.

1.6.2. System analysis and designing method

The goal of this section is to provide the basic overview of the system that we are going to develop.
The system analysis and design approaches for this project we used the object oriented system
analysis & design. Because

 It provides code and function reuse through the concepts of inheritance, polymorphism,
encapsulation, modularity, coupling and cohesion.
 To design the system the project team has choose Object Oriented Modeling techniques
and Unified modeling language tools.
 Understanding of the structure is easy because object oriented modeling and tools used to
represent real world entities.
 It enables us to comprehensively model a system before we develop it.
 Modification of the object implementation is easy because objects are loosely coupled.

Figure 1 system analysis and designing method

1.6.3. System development tools

To develop the system use different tools both hardware and software.

5
1.6.3.1 Hardware requirement
Hardware requirement specification Usage
Personal computer Processor: Intel core-i5 They are used to do any
and RAM 8 GB activities by using computer
Cpu:1.5 GHz above processor must be used.

Flash disk 16 GB and above To store, transfer and for data

backup purpose.

Printer ___ ____ Used to print the softcopy

what we do in our project.

Table 1 Hardware requirement

6
 1.6.3.2. Software requirement
software requirement specification Usage

Windows OS Windows 10 and 11 We will be used for

running the browser and
the other software needed
for project.

Firebase Server Manage servers setting

and for real time database

Edraw max ___ ____ Used to create simple or

complicated diagrams
Browser Like chrome, Edge, opera
are used for searching
___ ____ information for designing
and developing.
Vs code For writing a program or
___ ____
coding
Flask A python web framework
for backend.
Html and css For fronend interface

Table 2 software requirement

.

7
1.7 Project management Technique
1.7.1. Project schedule

Figure 2 Time schedule of the project

8
1.7.2. Project budget (cost break down estimation)
No Item quantity Price per item Total price
1 paper 60 2 120

2 Pen 2 20 40

3 Mobile card 50 6 300

4 print 100 2 200

5 binding 1 30 30

6 Miscellaneous cost - - 800

7 Flash 1 350 350

8 pc 2 30000 60000

Total 8 166 30410 61,840

Table 3 Hardware cost estimation

1.7.3 Project Work Break Dawn Structure (WBS), Responsibility, And Deliverable
Responsibility and Deliverables

The responsibility for each task in the WBS should be clearly assigned to a specific individual or
team. The deliverables for each task should also be clearly defined so that it is clear what is
expected to be produced.

ID Name Email Responsibility

UGR/21193/13 Ambebr Belay Hiweth21@gmail.com All

UGR/21371/13 Binyam Negash Benjazemu14@gmail.com All

Table 4 Team structure

9
1.7.4 Risk Analysis, Identification, Mitigation and Monitoring

In the context of a house renting management system, "Risk Analysis, Identification, Mitigation,
and Monitoring" refers to a set of processes aimed at understanding, addressing, and overseeing
potential risks associated with the management of rental properties. Let's break down each
component:

1. Risk Analysis:

 This involves evaluating and assessing potential risks that could affect the
successful operation of the house renting management system. It includes
identifying both internal and external factors that may pose threats or
opportunities.

2. Risk Identification:

 This step involves specifically identifying and documenting the potential

risks that have been analyzed. In the context of house renting management,
risks could include non-payment of rent, property damage, legal issues, or
market fluctuations.

3. Risk Mitigation:

 Once risks are identified, strategies and actions are developed to minimize
the impact or likelihood of these risks occurring. For example,
implementing thorough tenant screening processes, setting up legal
agreements, and maintaining property insurance are common risk
mitigation measures.

4. Risk Monitoring:

 Continuous oversight of the rental property management system is crucial.

This involves regularly reviewing and updating the risk assessments,

10
 ensuring that risk mitigation measures are effective, and staying vigilant for
new potential risks that may emerge over time.
In summary, integrating risk analysis, identification, mitigation, and monitoring into a house
renting management system helps ensure a proactive approach to potential challenges, ultimately
promoting a more secure and efficient operation of the rental properties.

Risk priority Mitigation

Data lose high Using daily back-up
Virus attacks our files Medium Using anti-virus software’s
Failures of programing tools low We set back-up and re-installing programing
tools
Table 5 risk and contingencies
1.8. Feasibility of the project
Depending on the results of the initial investigation the review is now expanded to a more
detailed feasibility study. Feasibility study is a test of system proposal according to its
workability, impact of the company in our country ability to meet needs and effective use
of the resources. It focuses on these major questions:

 What are the user’s demonstrable needs and how does a proposed system meet them?
 What resources will be available in the proposed system?

1.8.1. Economic Feasibility

The purpose of this economic feasibility analysis is to evaluate the financial viability of developing
and implementing an online house renting management system. This system aims to streamline
and simplify the process of house renting for landlords and tenants, providing a comprehensive
platform for property listings, tenant screening and rental agreements.

Based on a comprehensive evaluation of development costs, revenue generation opportunities, and

market analysis, an online house renting management system can be economically feasible.
However, it is crucial to conduct thorough market research, refine the revenue model, and closely
monitor financial performance to ensure long-term sustainability and profitability.

11
1.8.2. Technical feasibility
Technical feasibility is the measure of practicality of the specific technical solution and the
availability of technical resources and skill. The proposed system can be easily maintained and
repaired without requiring high specialists or technical
Assistants. The project is develop with modern programming language and the user interface is
user friendly as well as the system can lead them how technically interact with the system.
This evaluation determines whether the technology needed for the proposed system is available or
not.
 If new technology is needed then what can be developed?
 Can the work for the project be done with current equipment existing software technology
& available personal?

1.8.3. Schedule feasibility

The proposed schedule for the development of the Bale Robe House Rental Management System
spans 20 weeks, organized into six distinct phases. The initial 3-week project idea identification
following this, the 3-week proposal writing phase and then data collection phase, data reprocessing
after that project design includes setting up the development environment, backend and frontend
development, integration, and testing. The last phase, Implementation, encompasses deployment,
user training, data migration, and system go-live over a three-week period.

1.8.4. Operational feasibility

The system is operationally feasible as it very easy for the end users to operate it. Operational
feasibility covers two aspects. One is the technical performance aspect and other is the acceptance
within the organization. The online house rental management system that the project team will
develop user friendly.

12
 Chapter Two: current system
2.1. Introduction
Requirement analysis is the main activities that must be undertaken to have a clear understanding
of the system that is being used. Studying the requirement analysis of the existing system brings
about an important contribution to the entire development process. It is after the compilation of
this step that we can realize what goes wrong, which activities are right and which activities should
be encouraged. And what alternative methods should be taken to increase the performance of the
proposed system and to make the new system fully applicable by the particular organization.

2.2. Literature review

Preface the literature review deals with the motifs and the experimenters that would help to
understand house renting system the being system that are similar to house settlement system.
Ethiopia is the alternate most vibrant country in Africa, coming to Nigeria. Ethiopia is one of the
least citified countries on the mainland. still, as proved in the Centre for Affordable Housing
Finance Center for Affordable Housing Finance[1] and[2] during the once decade, the country
has witnessed a growing urbanization rate. For case, the proportion of the civic population to the
total population increased from 14.74% in 2000 to 21.69% in 2020. As a result of high population
growth and massive pastoral to civic migration, the urbanization rate has been adding which in
turn increase the demand for casing in metropolises and municipalities of Ethiopia from time to
time. The report of the Ministry of Urban Development and Housing [MUDH, 2016] revealed that
one of the civic casing problems in Ethiopia is deficit of house force relative to its demand which
put homes to spend further for accommodation. The high spending for sanctum exposes them to
different profitable, social and cerebral complications. In response to this problem, during the once
times, the government of Ethiopia has been enforced the integrated condominium homeownership
programs and other casing development programs. still, the demand for house remained unmet and
living in house rent becomes an indispensable means of sanctum fulfilling styles. For case, UN-
HABITAT [2011] showed that the casing gap in civic Ethiopia was estimated between 900,000,
and 1, 000, 0000 units[4].

13
2.3. Description of the Existing System
The existing house rental system in Bale robe city currently uses the traditional way of searching
of house. The house owner that wants to rent writes some information about house and tag it on
the door, then the customer read and contact with him for renting purpose. Once a customer finds
a vacant house after a long journey, they can call the renter of the house by the contact information
tagged to the house. And if they can reach at an agreement, mutual third party is mandatory for
them to sign an agreement contact that deals about price and different conditions.
The Revenue Center register customers on the paper. Since it is paper based or manual based it
leads to different problems. One of the problems that are caused by this manual-based system is
that loss of the file. This implies that the information is simply put on paper without any recovery
mechanism. Since these papers are easily movable by peoples, other people may intentionally or
unintentionally loss the file.
The main problem is that there is no any modern tool to search and find houses for renting as well
as showing the location of houses for customers. Due to this reason new customers may face
different difficulties. Among those difficulties’ customers may lose money for brokers. Brokers
may also give incorrect information about the house. This leads to customers too difficult to change
or leave the house after renting if the house is not comfortable to live or work. New customer’s
money or other things may be stolen by thieves since there is no information about the thieves or
the people.
2.4. Drawback of the Existing system
The house rental management system in Bale Robe city, Ethiopia, is marred by several drawbacks
that impede its effectiveness and fairness.

One notable drawback is the lack of a centralized database or platform where landlords can list
their properties and tenants can access comprehensive information. This fragmentation makes it
arduous for tenants to find suitable rental properties, resulting in inefficiencies and a restricted
range of options.

Transparency is a significant issue in the house rental management system. Landlords often
provide incomplete or inaccurate information regarding rental rates, property conditions, and
terms. This information asymmetry creates disputes and fosters unfair rental practices, leaving
tenants ill-informed and unable to make informed decisions.

14
2.5. Practice to be preserved from the current System
In the existing system, when the renter needs to rent the house, they find by going and asking
individual home one by one. First the house owner post notice for renting house. The renter reads
the notice, then the renter goes to individual house to find and rent. After this both of them write
their licensee agreement on paper or agreed by talking face to face.

2.6. Business rules

Business rules are any operating principles about the product, such as which individuals or roles
can perform which functions under specific circumstances. These are not functional requirements
in themselves, but they may imply certain functional requirements to enforce the rules.
The business rules of the existing system: -

 BR1: house owner announce to the broker should be register house.

 BR2: broker should be register house.
 BR3: tenants asks the broker.
 BR4: Both owners and renter should submit legal agreement and take full accountabilities.
 BR5: Agreement should be register to the file recorder.
 BR6: Tenant and owner meet to sign agreement.

2.7 Alternative solutions

In the context of the house rental management system in Bale Robe city, Ethiopia, an alternative
solution can be implemented to address the existing challenges. Here are some potential
alternatives:

Establish a Local Rental Management Platform: Develop a localized online platform or mobile
application dedicated to house rental management in Bale Robe city. This platform should serve
as a centralized database where landlords can list their properties and tenants can access
comprehensive and up-to-date rental information.

Improve Rental Market Transparency: Enhance transparency in the rental market by

implementing standardized rental agreements and ensuring that landlords provide accurate and
detailed information about their properties. This can include information on rental rates, property
conditions, amenities, and terms, enabling tenants to make informed decisions.

15
Strengthen Regulatory Framework: Implement and enforce robust regulations specific to the rental
market in Bale Robe city. This includes monitoring compliance with building safety standards, fair
housing practices, and rent control policies. Strengthening the regulatory framework will protect
the rights of both landlords and tenants and contribute to a more secure and fair rental market.

2.8. Forms used

Agreement forms that are filled by house owner and the tenant are attached in appendix. The
consists date at which the agreement filled, renter full information, house owner detail information,
the amount of money to be paid for the house per year and the amount of birr to be punished if
someone violates the agreement. It also encompasses witness full names and signature.

16
 Chapter Three: The proposed system
3.1 Overview of the proposed System
House rental system is designed to provide fast and easy way of controlling all the activities of
house renting. It is also used to communicate with customer’s using the web, keep the data for the
longest time with in the database.
Our proposed system provides an easy way for customers to check available houses for renting.
And also, the system allows to manage all house related files. This includes posting, deleting and
updating houses. The system also provides an easy way for admin and house owner to see tenants’
request on the web and sending their response to the customer.
Generally, house rental system is concerned on managing houses, providing easy and
understandable way of controlling the activities of house renting, and making easy and fast
communication held between renter, admin, and house owner.
The major solutions to address the problems of the existing system are as follows. Better utilization
of resources, performance, security, reliability, accuracy and in general better service and the new
system is aimed to perform basic and crucial tasks of the organization. It contains a well-organized
database server which makes data to retrieve, update easily. Since the computer is capable of
performing and processing many and huge tasks too faster, efficient and more correct it is preferred
to apply it on the system.

3.2. System constraints

System constraints are elements, factors or sub system that works as a narrow part of a road, when
congestion occurs. It put a limit on an entity, project or system from achieving its qualities that
may be developed with reference to its goals.
The constraints may include the following: -
 Except the user those about to view the home page, other tenants should have username
and password (for identification) in order to login and use the system.

17
3.3. Functional Requirements
Functional requirements consist of a specification of a function that the system must support. In
this section we discuss what is our system is expect to do. The type of user in this system is renter
(tenant), house owner and administrator.
Administrator:
 The system allows administrator to login before accessing system.
 The system allows administrator to approve house.
 The system allows administrator to view user feedback.
House owner:
 The system allows house owner to create account before accessing system.
 The system allows house owner to upload their house or room.
 The system allows house owner to view tenant’s request.
 The system allows house owner to send feedback.
 The system allows house owner to change their password.
Tenants (renters):
 The system allows tenant to create account before accessing system.
 The system allows tenant to send request.
 The system allows tenants to send feedback.
 The system allows tenant to view houses.
 The System allows tenant to change their password.
Admin:
 The system allows Admin to login before accessing system.
 The system allows Admin to view pending house.
 The system allows Admin to view free house.

18
3.4. Non-Functional Requirements
Non-functional requirements are requirement, which are not very basic or essential for the system,
but it can support and give more quality for the system. The non-functional requirement of the
system deals with how well the system provides service to the user. They are also called technical
requirements. It concerns to the technical aspects that your system must fulfill, such as
performance-related issues, reliability issues, and availability issues. The new system had the
following Non-functional requirements.
 User friendly interface: -since the system has attractive interface therefore users are
interested to use it.
 Error handling: - when the user makes some mistakes the system responds that error
has occurred using easily understandable messages and allows the user to recover from
the error.
 Availability: -the system is available at any time with internet connection.
 Security issue-the system is secured, users can't access the system without
authentication.
 User satisfaction: -we will satisfy all requirement of the user as much as possible by
using prioritization and negotiation.
 Efficiency: - The system responds to user requests as fast as possible and fully
operational every day for 24 hours.
 Cost minimization since searching is online expenses are reduced.
 Reliability: The system should handle invalid inputs and displays error message to
users. Reliability is one feature of the system significantly validates user inputs
 Portability: This system is portable, since it runs on different platforms (i.e. MacOS,
Windows, Ubuntu… etc.). Running on different platforms makes the system accessible
by users.
 Flexibility: the system must support commonly usable browsers.

 Scalability: the system must update when some updates will available.
 Performance: there is no ambiguous data fetched on the system and no wastage of
time to organize and integrate file.

19
3.5. Graphical user Interface
3.5.1. Specification
Our web based application will be accessed through a browser and any user can access by writing
at search place of browsers. Our web based application would be fully compatible with google
chrome, Mozilla Firefox and Microsoft edge.

3.5.2. User interfaces

Figure 3 User interface

3.5.3. User interface prototype (snap shoot)

User interface prototyping is an iterative development technique in which users are actively
involved in the user interface of a system. It is place where user directly interacts with systems. It
represents the general ideas behind the UI, but not the exact details. According to these criteria
here is user interface design for online house rental system.

20
Figure 4 user interface prototype

Chapter four: System modeling

4.1. Introduction
System modeling is the process of creating simplified representations or models of complex
systems. A system model is a conceptual or mathematical framework that captures the essential
elements, relationships, and behaviors of a system. It allows us to understand, analyze, design, and
simulate systems in a structured and systematic manner [5].

System modeling involves identifying the components of a system, defining their interactions and
relationships, and representing these elements using diagrams, mathematical equations, or

21
computer simulations. The purpose of system modeling is to gain insight into how a system
functions, predict its behavior, evaluate alternative designs or configurations, and make informed
decisions.

4.2. Actor Identification

An actor initiates a use case and receives something of value from the use case. Actors are always
external to the system being modeled i.e. they are not parts of the system. We identified the
following actors.

 Administrator: manages the whole system of the project.

 Tenant: search and view free house from the system online.
 Owner: view their house and update information.
 Adminr: Record house, generate report and control their tasks related to the owner and
renters.

4.3. Use case Identification

A use case is a list of actions, roles or events that are performed by an actor, to achieve a system
goal. The project team identified the following use cases for the new system

4.4. System Use case diagram

Use case diagram Shows use cases, actors, and their inter-relationships. A use case diagram is a
graphic depiction of the interactions among the elements of a system. A use case is a methodology
used in system analysis to identify, clarify and organize system requirements. Use case model
describes the proposed functionality of a new system.
Actors: An actor represents a type of users of the system that the system interacts with. An actor
is a user of the system playing a particular role.
Use cases: 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.
Extended association: is the generalization relation where the extending use case continues the
behavior of the base use case. The extending use case accomplishes this by inserting additional
action sequences into the base use case sequence. This is modeled using a use case association
with the <<extend>> stereotype.

22
Include association: is the relationship denoting the inclusion of the behavior described by the
use case with in another use case. This is modeled using a use case association with the
<<include>> stereotype also known as “uses” or a “has-a” relationship.

Figure 5 system use case diagram

4.4.1. Actor description

 An actor initiates a use case and receives something of value from the use case. Actors are
always external to the system being modeled i.e. they are not parts of the system. We
identified the following actors.
 Administrator: manages the whole system of the project.

23
  Tenants: search and view free house from the system online.
 House Owner: view their house and upload house.
 Admin: Approve house and control their tasks related to the owner and renters.

4.4.2. Use case description (Scenario)

Create Account
Use case name
Actors Tenant and house owner
Description This state allows these actors, to create user name and password in order to access
the system.

Pre-condition The actors should be new user.

Basic course of action 1. The tenants and house owner enter to home page
2. Then click create account link on home page
3. The system displays registration form
4. The user fill the required data on the form and click register button.
5.The system can validate all inserted data
6. the system can register on database
7. The system displays your account is successfully created
8. Use case ends.
Alternate flow of A1. If the entered required information is not valid it returns step 4 to refill the
action form.
Post condition The new user is registered.

Table 6 Create account use case description

24
 Use Case name Login
Actors Tenants, house owners, and administrator
Description Users use this use case to login to the system.
Pre-condition The user should be registered first or need to have account to login
Basic course of 1. The user enters to the home page.
action 2. Click login link on home page
3. Enter user name and password and click login button.
4. The system checks for validity of user name and password
entered.
5. The system displays user page if user name and password is
correct.
6. Use case exit.
Alternative course of A1 If the entered user name and password is not valid it displays “please
action enter valid user name and password” go to basic flow 3.
A2 If the user forgot the user’s name and password display reset user
name and password page.
Post Condition The users logged in to the main page.

Table 7 Login use case description

Use case name Change password

Actors Tenants and house owner
Description Allows the system users to change their password.
Pre-condition User must have older password.
Basic course of action 1. User login first into the system.
2. Choose change password option.
3. System will display the page.
4. User fills the information required and press change button.
5. The system checks for validity.

25
 6. Display success message.
7. Use case exits.

Alternate course of If the entered data is not valid the system displays error message and
action returns basic course of action 3.
Post condition User password changed successfully.
Table 8 Use case description for change password

Use case name Search Information

Actor Tenant, House owner, and admin

Description When tenant enters their information needed and click search option, the
information needed for the tenant is displayed if available.

Pre-condition Tenant does not need to have an account to search.

1. The actors click on search option.
Flow of action
2. The system displays the page that contains a text box and search button.
3. Tenant enters their need and press search button.
4. System displays the requested information if available otherwise item is
not found prompt will be displayed.
5. Use case Exit

Alternate course The house or room is not found prompt is displayed.

of action

Post condition Users able to find the information they want.

Table 9 use case description for search information

26
Use case Upload House or Room Information
Actor House owner
Description This use case permits house owner to register rental information of the house or
room that they will rent.
Pre-condition Logging into the system
Flow of action 1. This use case is initiated when the actors click on register houses option.
2. System displays the page that contains information to will be registered.
3. Fill all the information
4. Then they click or press on the register button.
5. The system verifies that fields have been filled out correctly.
6. The system displays inserted successfully message.
7. Use case Exit

Alternative A.1 If the fields are not filled out correctly system goes back or returns to step 3
course of action of basic course of action to fill invalid field.
House owner information is registered.
Post condition
Table 10 use case description for upload house or room information
Use case name Approve the house
Actor Admin
Description This use case permits admin to approve the house.
Pre-condition  Admin must first log in.

 There must be request from house owner for approval.

Basic course of 1. The Admin logged in and view all pending houses.
action 2. Then press approve button.
3. The system displays success message.
4. Use case ends.
Alternative If the uploaded house does not meet the requirements the admin does not approve
course of action the house.
Post condition Once the house approved the house removed from pending node

27
 Table 11 use case description for Approve house

Use case View house information

Actor Tenant, house owner, and administrator

Description When actors choose view house information option, the system displays
information.

Pre-condition Users need to have an account if they want to see more information.

Flow of event 1. This use case is initiated when the actor clicks on view house owners’
resources option.
2. System displays available name of the house owner and some
descriptions.
3. Admin and tenant click on renting option.
4. System displays all the available resources recorded in the database.
5. Use case Exit

Post-condition Admin and tenant know if house information is reserved or not.

Alternative flow of Actors see only name of the house owner and the description if they don’t want
action to login.

Table 12 use case description for view house information

Use case Send response

Actor House owner

Description When house owner chooses view tenant request option, the system displays
information about who is requesting. Then he/she can reply the response to the
requester.

28
Pre-condition  House owner must first log in.
 There must be request from tenant.

Flow of events 1. The house owner clicks view request link.

2. System displays the response page.
3. User fills necessary notification and click send button to send it.
4. The system will display success message to user.
5. Use case Exit
Post condition Response is sent to the tenant

Table 13 use case description for send response

Use case name Update house information

Actor House owner

Description House owners can update their own house information

Pre-condition  House owner needs to have an account to modify his property.
 House owner should have resource posted first to update it.
Basic flow of
1. This use case is initiated when they click on update house link.
action
2. System displays the page with house information with update button.
3. House owner updates the fields.
4. Then press update button.
5. System displays success message.
6. Use case exit.

Post condition House information is modified.

Table 14 use case description for update house information

29
 Use case name Send feedback

Actor Tenant and house owner

Description To enable the users to send the feedback, to comment any suggestion on
text area.

Pre-condition The users must be having a suggestion about the system as well as houses
property.
Basic course of
1. The users click feedback button.
action
2. System display text area box.
3. The users write some necessary information and click post button.
4. The system validates the entered data.
5. The system can make save on database.
6. Use case Exit

Post condition Suggestion will be posted

Table 15 use case description for send feedback

Use case name View feedback

Actor Admin
Pre-condition To view login to system first and there must be sent feedback.
Description This helps the service provider to improve services they are providing
or to appreciate the services provider.
Basic course of action 1 Login to the system first.
2 Select view feedback link.
3 System displays the feedback if available else display there is no
available feedback response.
4 Use case exit.
Post condition Admin view all feedbacks.
Table 16 use case description for view feedback

30
 Use case name Logout

Actors Tenant, house owners, and admin

Administrator, tenants, and house owner should be logged in first.
Pre-condition
To out from services.
Description
The user clicks on logout button.
Basic flow of action
users logged out from the system
Post condition
Table 17 use case description for logout
4.5. Dynamic modeling
4.5.1. Sequence diagram
A sequence diagram is an interaction diagram. From the name, it is clear that the diagram deals
with some sequences, which are the sequence of messages flowing from one object to another.
Interaction among the components of a system is very important from implementation and
execution perspective. So, Sequence diagram is used to visualize the sequence of calls in a system
to perform a specific functionality. The Sequence diagram models the collaboration of objects
based on a time sequence. It shows how the objects interact with others in a particular scenario of
a use case. UML can generate sequence diagram from the flow of events which you have defined
in the use case description [5].

A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects that
live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the
order in which they occur. This allows the specification of simple runtime scenarios in a
graphical manner.

31
Figure 6 sequence diagram for create account

Figure 7 sequence diagram for login

32
Figure 8 sequence diagram for change password

Figure 9 sequence diagram for send request

33
Figure 10 sequence diagram for view request

Figure 11 sequence diagram for send response

34
Figure 12 sequence diagram for upload house or room

35
Figure 14 sequence diagram for send feedback

Figure 15 sequence diagram for search a house

4.5.2. Collaboration diagram

Figure 16 collaboration diagram

36
4.5.3 Activity diagram
Activity diagrams are graphical representations of workflow of stepwise activities and
actions with support for choice, iteration and concurrency. In the UML activity diagrams
are intended to model both computational and organizational processes (i.e., workflows),
as well as the data flows intersecting with the related activities. Activity diagram is UML
diagram used to model high level business process or the transition between states of the
class [6]. Although, activity diagrams primarily show the overall flow of control, they can
also include elements showing the flow of data between activities through one or more data
stores. Activity diagrams are constructed from a limited number of shapes, connected with
arrows.

Figure 17 activity diagram for login

37
 Figure 18 activity diagram for register

Figure 19 activity diagram for change a password

38
Figure 20 activity diagram for upload a house

Figure 21 activity diagram for view option

39
4.5.4. State chart Diagram
One of the five UML diagrams used to represent a system's dynamic nature is the state chart
diagram. Throughout an object's existence, they specify several states, and events alter these
states. Reactive systems can be effectively modeled with state chart diagrams. A system that
reacts to internal or external events is known as a reactive system.
A state chart diagram shows how control moves from one state to another. A state is an object's
existence that modifies itself in response to an external event. State chart diagrams are mostly
used to represent an object's lifecycle from creation to termination.

Figure 22 State chart Diagram for login

40
Figure 23 State chart Diagram for registration

4.6. Object modeling

4.6.1. Class diagram
UML class diagrams 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 design modelling. A class model is comprised of one or more class diagrams and the
supporting specifications that describe model elements including classes, relationships between
classes, and interfaces. UML class diagram show the classes of the system, their interrelationships,
and the operations and attributes of the classes [7].

Class diagram provide an over view of target system by describing the object and classes inside
the system and the relationship between them.

41
Figure 25 system class diagram

4.6.2. Object diagram

Object diagrams are derived from class diagrams so object diagrams are dependent upon class
diagrams. It represent an instance of a class diagram. The basic concepts are similar for class
diagrams. Object diagrams also represent the static view of a system but this static view is a
snapshot of the system at a particular moment. Object diagrams are used to render a set of objects
and their relationships as an instance [7].

The purpose of a diagram should be understood clearly to implement it practically. The purposes
of object diagrams are similar to class diagrams. The difference is that a class diagram represents
an abstract model consisting of classes and their relationships. However, an object diagram
represents an instance at a particular moment, which is concrete in nature.

42
It means the object diagram is closer to the actual system behavior. The purpose is to capture the
static view of a system at a particular moment.

Figure 26 system class diagram

43
 Chapter Five: System Design
5.1 Introduction
System design outlines the architectures, parts, pieces, and information that make up a
system in order to meet predetermined specifications. It addresses the representation
and storing of data within the system. Therefore, systems design is the process of
defining and creating systems to fulfill particular specifications provided by the user.
The real input and output operations of the system are related to the system design. This
outlines the procedures for entering data into a system, validating and processing it, and
presenting it [8].

5.2 Architecture Design

An architecture design diagram is a visual representation of the structure, components, and
relationships within a system or application. It helps stakeholders, such as developers, architects,
and project managers, understand the overall design and how different elements interact with each
other. While there are various notations and styles for architecture diagrams, I'll provide you with
a simple example using a high-level block diagram.

Figure 27 Architecture Design diagram

44
5.2 .1 Component Diagram
Online house rental system component diagram show how its Components are wired together to
form larger components and or software system they are used to illustrate the structure of
arbitrarily complex house renting system. This diagram helps us to model the physical aspect of
our system. It illustrates the architectures of the software components and the dependencies
between them [8].

Figure 28 component diagram

45
5.2.2 Deployment Diagram
A UML deployment diagram displays a static view of the system user's runtime
configuration as well as the components that the system is running. Put otherwise, the
deployment diagram displays our system's hardware along with the software that will be
installed on it. It also demonstrates how Software and hardware components are work
together [5].

Figure 29 deployment diagram

46
1.3 Database design

Database design can be generally defined as a collection of tasks or processes that enhance
the designing, development, implementation, and maintenance of enterprise data
management system. Designing a proper database reduces the maintenance cost thereby
improving data consistency and the cost-effective measures are greatly influenced in terms
of disk storage space. Therefore, there has to be a brilliant concept of designing a database.
The designer should follow the constraints and decide how the elements correlate and what
kind of data must be stored [8].

The main objectives behind database designing are to produce physical and logical design
models of the proposed database system. To elaborate this, the logical model is primarily
concentrated on the requirements of data and the considerations must be made in terms of
monolithic considerations and hence the stored physical data must be stored independent
of the physical conditions. On the other hand, the physical database design model includes
a translation of the logical design model of the database by keep control of physical media
using hardware resources and software systems such as Database Management System
(DBMS).

47
5.3.1 Entity Relationship Diagram (ERD) design
An Entity-Relationship Diagram (ERD) is a visual representation of entities, their attributes, and
the relationships between entities in a database. It helps to illustrate the logical structure of a
database system. Here's an example of an ERD for a House Rental Management System:

The ERD provides a visual representation of the entities and their relationships, helping to
understand the structure of the House Rental Management System database.

Figure 30 Entity Relationship Diagram (ERD)

48
5.3.2 Normalization
Normalization is the process of organizing the data in the database. Normalization is used to
minimize the redundancy from a relation or set of relations. It is also used to eliminate undesirable
characteristics like Insertion, Update, and Deletion Anomalies. Normalization divides the larger
table into smaller and links them using relationships. The normal form is used to reduce
redundancy from the database table. [8]

The main reason for normalizing the relations is removing these anomalies. Failure to eliminate
anomalies leads to data redundancy and can cause data integrity and other problems as the database
grows. Normalization consists of a series of guidelines that helps to guide you in creating a good
database structure [8].

Mapping tenants

Tenants-ID Name Sex Email Phone no password

Mapping admin

Admin-ID Name Sex Email Phone no

Mapping house owner

House owner-ID Name Sex Email Phone no

Mapping to Admin

Adminr-ID Name Sex Email Phone no

Mapping house

49
 house-ID House no Location price

Mapping feedback entity

Source body Sent time

Un-normalized form

1. Tenants

Tenants-ID Name Sex Email Phone no password

T1 Daniel getachew M Dan43@gmail.com 0965784746 Ad.11221

2. Admin

Admin-ID Name Sex Email Phone no

A1 Ermiyas selomon M Ermi234@gmail.com 0956343345
0965784532

3. House owner

House owner-ID Name Sex Email Phone no

Ho1 Hewan Desta F Hewi234@gmail.com 0945357698

4. house

50
 house-ID House no Location price
H1 465 Awuraris 2000

5. feedback

Source body Sent time

Ermi234@gmail.com Good service 10/10/2016

6. Admin

Adminr-ID Name Sex Email Phone no

Ro1 Neba tilahun M neba234@gmail.com 0942357698

First Normal Form (1NF)

 A relation will be 1NF if it contains an atomic value.

 It states that an attribute of a table cannot hold multiple values. It must hold only single-
valued attribute.
 First normal form disallows the multi-valued attribute, composite attribute, and their
combinations.0

1. Tenants

Tenants- FName LName Sex Email Phone no password

ID

51
T1 Daniel getachew M Dan43@gmail.com 0965784746 Ad.11221

2. Admin

Admin-ID Fname Lname Sex Email Phone no

A1 Ermiyas Solomon M Ermi234@gmail.com 0956343345
A1 Ermiyas Salomon M Ermi234@gmail.com 0965784532

3. House owner

House owner-ID Name Sex Email Phone no

Ho1 Hewan Desta F Hewi234@gmail.com 0945357698

4. house

house-ID House no Location price

H1 465 Awuraris 2000

5. feedback

Source body Sent time

Ermi234@gmail.com Good service 10/10/2016

6. Admin

Adminr-ID Name Sex Email Phone no

Ro1 Neba tilahun M neba234@gmail.com 0942357698

52
Second Normal Form (2NF)

 In the 2NF, relational must be in 1NF.

 In the second normal form, all non-key attributes are fully functional dependent on the
primary key.
1. Tenants

Tenants- FName Lname Sex Email Phone no password

ID
T1 Daniel Getachew M Dan43@gmail.com 0965784746 Ad.11221

2. Admin

Admin-ID Fname Lname Sex Email Phone no

A1 Ermiyas Solomon M Ermi234@gmail.com 0956343345

A1 Ermiyas Salomon M Ermi234@gmail.com 0965784532

3. House owner

House owner-ID Name Sex Email Phone no

H01 Hewan Desta F Hewi234@gmail.com 0945357698

4. House

house-ID House no Location price

H1 465 Awuraris 2400

53
 5. Feedback

Source body Sent time

Ermi234@gmail.com Good service 10/10/2016

6. Admin

Adminr-ID Name Sex Email Phone no

Ro1 Neba tilahun M neba234@gmail.com 0942357698

Third Normal Form (3NF)

 A relation will be in 3NF if it is in 2NF and not contain any transitive partial dependency.
 3NF is used to reduce the data duplication. It is also used to achieve the data integrity.
 If there is no transitive dependency for non-prime attributes, then the relation must be in
third normal form.
1. Tenants

Tenants- FName LName Sex Email Phone no password

ID
T1 Daniel getachew M Dan43@gmail.com 0965784746 Ad.11221

2. Admin

Admin-ID Fame Lname Sex Email Phone no

A1 Ermiyas Solomon M Ermi234@gmail.com 0956343345

A1 Ermiyas Solomon M Ermi234@gmail.com 0965784532

54
 3. House owner

House owner-ID Name Sex Email Phone no

Ho1 Hewan Desta F Hewi234@gmail.com 0945357698

4. house

house-ID House no Location price type

H1 465 Awuraris 2400 1 room

5. feedback

Source body Sent time

Ermi234@gmail.com Good service 10/10/2016

1. Admin

Adminr-ID Name Sex Email Phone no

Ro1 Neba tilahun M neba234@gmail.com 0942357698

55
5.3.3 Persistence diagram
Persistent data management is basically used to represent the design of the database. Database
design is the process of producing a detailed data model of a database. Online house rent system
will have database tables to store, access and maintain information that flows in the system [8].

Figure 31 Persistence diagram

56
 Chapter Six: System Implementation
6.1 Introduction

System implementation is a pivotal phase in the lifecycle of any technological endeavor,

marking the transition from planning and development to practical application. It
represents the culmination of meticulous design, rigorous testing, and strategic
deployment, with the ultimate goal of translating theoretical concepts into tangible
solutions that address real-world challenges.

In essence, system implementation involves the transformation of abstract ideas into

functional systems or software, ready for operational use. This process encompasses a
spectrum of activities, ranging from installing hardware components and configuring
software platforms to integrating disparate systems and training end-users. Each step is
meticulously orchestrated to ensure seamless execution and optimal performance, with a
keen focus on meeting predefined objectives and stakeholder expectations.
System implementation is the process of putting a new system or technology into operation
within an organization. It involves the transition from the design and development phase
to the practical application and utilization of the system to achieve specific goals or
objectives. Whether it's the deployment of a new software application, the integration of a
complex network infrastructure, or the introduction of a cutting-edge technological
solution, system implementation is a critical phase in the lifecycle of any technological
initiative.

57
 6.2 User interface prototype (snap shoot)

Figure 32 UI diagram of homepage

Figure 33 UI diagram of Login

58
Figure 34 UI diagram of add property

6.3 Testing

Testing in a proposed system refers to the process of evaluating and verifying the functionality,
performance, and reliability of the system before it is deployed or released to users. It involves
executing predefined test cases, analyzing the results, and identifying any defects or issues that
need to be addressed.

Common types of testing in a proposed system may include:

 Functional Testing: Verifying that the system functions correctly and meets the specified
requirements.
 Integration Testing: Testing the interaction and compatibility of different system
components.
 Performance Testing: Evaluating the system's performance under varying loads and stress
conditions.
 Security Testing: Assessing the system's security measures and vulnerabilities.

59
  Usability Testing: Evaluating the system's user interface and user experience.
 Regression Testing: Re-testing previously tested functionalities to ensure they remain
functional after changes or updates are made.

Overall, testing in a system is critical to ensure its reliability, functionality, and performance. It
helps identify and address potential issues, ultimately leading to a higher quality and more robust
system for end-users.

6.3.1 Unit testing

Unit testing in a proposed system refers to the testing of individual units or components
of the system in isolation. It focuses on verifying the correctness and functionality of each
unit independently, ensuring that it behaves as expected.

Moreover, unit testing in a system involves testing individual units or components in

isolation to ensure their correctness and functionality. It helps detect bugs early, improves
code quality, verifies design, and supports refactoring efforts.

6.3.2 System testing

System testing in a proposed system refers to the testing of the entire system as a whole,
rather than testing individual units or components in isolation. It focuses on evaluating the
system's behavior and performance in a real or simulated environment to ensure its overall
functionality, reliability, and compliance with specified requirements.
System testing is essential in a proposed system to validate the overall functionality,
performance, and quality of the system. It helps uncover defects, ensure system stability,
and provide confidence in the system's readiness for deployment to end-users.

6.3.3 Acceptance testing

Acceptance testing in a system refers to the formal evaluation of the system's compliance
with business requirements and its suitability for acceptance and deployment by end-users
or stakeholders. It is a type of testing that focuses on determining whether the system meets
the specified criteria and satisfies the needs of the intended users.
60
 The primary goal of acceptance testing is to gain confidence that the system is ready for
deployment and meets the expectations of the end-users or stakeholders. It provides a final
validation step before the system is officially accepted and put into operation.

6.3.4 Performance testing

Performance testing in a proposed system refers to the process of evaluating and

measuring the performance characteristics of the system under specific conditions. It is
conducted to assess how well the system performs in terms of speed, responsiveness,
scalability, stability, and resource usage.

Overall, performance testing in a proposed system is crucial to ensure that the system
can handle the expected workload, deliver satisfactory response times, and provide a
smooth user experience. It helps identify performance bottlenecks, scalability issues,
and other performance-related problems, allowing developers and stakeholders to make
necessary optimizations and improvements before deploying the system in a production
environment.

6.4 Features to be tested and not to be tested

6.4.1 Features to be tested

When conducting testing for a proposed system, several features should be considered
for thorough coverage. The specific features to be tested will depend on the nature of
the system and its intended functionality. However, here are some common features
that are typically tested in a proposed system:

1. User Interface, Functionality, Security, Performance, Usability and more to be tested.

These are some of the key features that should be tested in a proposed system. The
testing approach may vary based on the system's complexity, requirements, and
priorities. It is important to define a comprehensive test strategy to cover all critical
features and ensure the system functions reliably and meets the desired quality
standards.

61
6.4.2 Features not to be tested

When testing a proposed system, it is important to prioritize and focus on the most
critical and high-risk features. However, there are certain features that may not require
testing in the proposed system. These features typically fall into the following
categories:

It is important to note that the decision of which features not to test should be made
based on careful analysis and risk assessment. The exclusion of certain features from
testing should be well-documented and communicated to stakeholders to ensure
everyone is aware of the testing scope and any associated risks. Additionally, even if
some features are not tested, it is recommended to have a contingency plan in case issues
arise with those features during the system's implementation or usage.

6.4.3 Pass/ fail criteria

The pass or fail criteria for a system can vary depending on the specific requirements
and objectives of the system. Generally, the pass or fail criteria are defined during the
system development and testing phase and are based on the system's functional and
non-functional requirements.
It is important to define clear and measurable pass or fail criteria for each aspect of the
system to ensure that the system meets the desired quality standards. These criteria
should be agreed upon by stakeholders and documented in the system requirements or
testing documentation.

6.5 System Manual (Documentation)

Purpose
The purpose of this system manual is to provide comprehensive documentation for the
House Rental Web-Based System. It aims to guide users in understanding the system's
features, functionalities, and usage.

62
 System Overview:
The House Rental Web-Based System is an online platform designed to facilitate the
rental process between property owners and tenants. It enables property owners to list
their properties and manage bookings, while tenants can search for available properties
and make renting. The system includes features for user registration, property
management, uploading houses, system administration, and more.

System Setup and Configuration

To run the House Rental Web-Based System, the following technical requirements must be met:

 Web server with python flask support

 Firebase or compatible database server
 Compatible web browser (Chrome, Firefox, etc.)
 Internet connectivity

Installation Instructions:
 .Obtain the system installation package from the designated source.
 Extract the installation package to the desired location on the web server.
 Create a new firebase database for the system.
 Configure the system by modifying the configuration file with the appropriate
database credentials and other settings.
 Access the system via a web browser to complete the installation.

6.6 Support and Service

Support and service in a proposed system refer to the activities and processes involved in providing
ongoing assistance, maintenance, and customer support for the system after its implementation. It
ensures that the system continues to operate effectively, remains up-to-date, and meets the
evolving needs of the users. Here are some key aspects of support and service in a proposed system:

Effective support and service are crucial for ensuring the long-term success and usability of a
proposed system. By providing ongoing assistance, maintenance, and customer support,
organizations can maximize the value and benefits derived from the system, enhance user
satisfaction, and adapt the system to meet evolving needs.

63
 Chapter Seven: Conclusion and Recommendation

6.1 Conclusion

The development of an online house rental system for Bale Robe City holds great potential
to streamline and enhance the process of finding and renting houses in the city. By
leveraging the power of technology, such a system can bring numerous benefits to both
property owners and potential tenants.

For property owners, the online house rental system offers a platform to efficiently list and
advertise their available properties, reaching a wider audience and increasing the chances
of securing tenants. The system can provide features such as property management,
simplifying the rental process and reducing administrative overhead.

On the other hand, potential tenants can benefit from the convenience and accessibility
provided by the online house rental system. They can easily search for available properties
based on their specific preferences, such as location, size, amenities, and price range. The
system can also offer features like virtual tours, detailed property descriptions, and user
reviews, enabling tenants to make informed decisions and find the perfect rental home in
Bale Robe City.

However, it is important to ensure that the online house rental system is thoroughly tested
and continuously maintained to guarantee its reliability, security, and user-friendliness.
Rigorous testing should cover various scenarios, including user registration, property
listing and search, and system integrations, to ensure that the system functions flawlessly
and provides a seamless experience for users.

In conclusion, the implementation of an online house rental system for Bale Robe City has
the potential to revolutionize the local rental market, making it easier and more efficient
for property owners and tenants to connect and transact. By embracing technology and

64
 focusing on quality testing and maintenance, the system can contribute to a thriving rental
ecosystem in Bale Robe City, benefiting the entire community.

7.2 Recommendation References/bibliography

I highly recommend the implementation of a robust and user-friendly online house rental system
for Bale Robe City. Such a system can bring numerous advantages and improve the overall rental
experience for both property owners and potential tenants. Here are some key recommendations
for the house rental system:

 User-Friendly Interface: Design the system with a clean and intuitive user interface that is
easy to navigate. Ensure that property owners and tenants can easily access and use the
system without any technical difficulties.
 Comprehensive Property Listings: Encourage property owners to provide detailed and
accurate information about their rental properties. Include features such as high-quality
images, property descriptions, amenities, location details, and rental terms to help potential
tenants make informed decisions.
 Advanced Search and Filtering: Implement an advanced search functionality that allows
tenants to filter and search for properties based on specific criteria such as location, size,
& price range. This will help tenants find properties that meet their preferences quickly
and efficiently.

8. Continuous Testing and Maintenance: Regularly test and maintain the house rental system to
identify and address any bugs, glitches, or performance issues. Conduct thorough testing at each
stage of development to ensure a stable and reliable platform.

By implementing these recommendations, the online house rental system for Bale Robe City can
provide a seamless and efficient rental experience for property owners and tenants. It can foster
transparency, convenience, and trust within the local rental market, ultimately benefiting the entire
community and contributing to the growth and development of the city's housing sectors or owners.

65
 References

[1] Wikipedia, "www.wikipedia.com," 13 08 2019. [Online]. Available:

https://en.wikipedia.org/wiki/Bale_Robe. [Accessed 13 02 2204].

[2] CAHF and 2021, 2021. [Online].

[3] ARUP. [Online]. [Accessed 2016)].

[4] E. Mekonnen, "jornal web page," 01 09 2022. [Online]. Available: https://www.tandfonline.com.

[Accessed 9 03 2024].

[5] t. point, "tutorials point," 6 09 2023. [Online]. Available:

https://www.tutorialspoint.com/uml/uml_deployment_diagram.htm. [Accessed 09 02 2024].

[6] S. w.ambler, the application developers guide to object orientation and the UML, Cambridge: idge
university press, 2001.

[7] S. W. Ambler, Introduction to Techniques for Agile Modeling, 2009.

[8] javatpoint, "javatpoint," 03 02 2021. [Online]. Available: https://www.javatpoint.com/database-

design.

[9] w. bank, 2021. [Online].

66
 Appendix
1: Agreement forms that are filled by house owner and the tenant

2: We ask some questions for the house owner and the customer:
 How to sign agreement between tenant and house owner?
 Who approving the agreement between tenant and house owner?
 How tenants search free house?
 How house owner is announcing to the organization, when the tenant is leave?

3: Coding (sample code)

<!--Register.html-->

<!DOCTYPE html>

<html>

67
<head>

<title>Registration Bale</title>

<link rel="shortcut icon" href="images/home_hand_3-1.svg" />

<link rel="stylesheet" type="text/css" href="static/normalize.css" />

<link rel="stylesheet" type="text/css" href="static/styles.css">

<link rel="stylesheet" href="static/homlisti.css" />

<link rel="stylesheet" type="text/css" href="static/normalize.css" />

<link rel="stylesheet" type="text/css" href="css/" />

<link rel="stylesheet" href="https://unpkg.com/aos@next/dist/aos.css" />

</head>

<body>

<div class="main-header">

<div class="container">

<a href="index.html" class="logo">

<img src="images/logo.svg" alt="" />

</a>

</div>

</div>

<form method="post">

<div>

<label for="developer_name">Full Name</label>

68
 <input type="text" id="developer_name" name="developer_name" required>

</div>

<div>

<label for="email">Email</label>

<input type="email" id="email" name="email" required>

</div>

<div>

<label for="phone_number">Phone Number</label>

<input type="text" id="phone_number" name="phone_number" required>

</div>

<div>

<label for="address">City</label>

<input type="text" id="address" name="address" required>

</div>

<div>

<label for="address">Occupation</label>

<input type="text" id="occupation" name="occupation" required>

</div>

<div>

<label for="password">Password</label>

<input type="password" id="password" name="password" required>

</div>

69
 <div>

<label for="confirm_password">Confirm Password</label>

<input type="password" id="confirm_password" name="confirm_password" required>

</div>

<div>

<input type="submit" value="Register">

</div>

</form>

</body>

</html>

<!-- Login.html -->

<! DOCTYPE html>

<Html>

<Head>

<Title>Login Form</title>

<link rel="stylesheet" type="text/css" href="static/styles.css">

</head>

<body>

<form method="post" id="login Form">

<div>

<label for="phone_number">Phone Number:</label>

<input type="text" id="phone_number" name="phone_number" required>

70
 </div>

<div>

<label for="password">Password:</label>

<input type="password" id="password" name="password" required>

</div>

<div>

<input type="submit" value="Login" style="margin-top: 10px;">

</div>

</form>

</body>

</html>

#register

@app.route('/register.html', methods = ['GET', 'POST'])

def register():
if request.method == 'POST':
developer_name = request.form['developer_name']
email = request.form['email']
phone_number = request.form['phone_number']
address = request.form['address']
password = request.form['password']
confirm_password = request.form['confirm_password']
if password == confirm_password:
developer_data ={
"name":developer_name,
"email":email,
"phone_number":phone_number,

71
 "address":address,
"password":password
}
email_key = email.replace('.','_dot_')
real_db.child('Users').child(phone_number).set(developer_data)
return redirect(url_for('login'))
else:
return redirect(url_for('register'))
return render_template('register.html')

# login
@app.route('/login.html', methods=['GET', 'POST'])
def login():
if request.method == 'POST':
phone_number = request.form['phone_number']
password = request.form['password']
is_admin = request.form.get('admin')
user = real_db.child('Users').child(phone_number).get().val()
if user:
if password == user.get('password'):
session['user_name'] = user.get('name')
session['user_phone'] = phone_number
session['user_email'] = user.get('email')
return redirect(url_for('index'))
else:
return 'Incorrect password for user'
else:
return 'User not found. Please register first'

return render_template('login.html')

72