LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT

DOCUMENTATION

Hawassa, Ethiopia
February 2023

i
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
Group members

Name ID Signature
Abdulhamid Hayrdin 0041/12

Ashenafi Terefe 0309/12

Bethlehem Yenehun 0449/12
Dawit Alemu 0614/12
Elias Kebede 0709/12
Melat Ali 0040/11

Project Advisor

Name Mr. Abebayew Samuel

Signature

Comment

Acronyms

ii
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

HTTP Hypertext transfer protocol

MYSQL My Structured Query Language

UML Unified Modeling Language

UI User Interface

CRUD Create Retrieve, Update And Delete

ERD Entity Relationship Diagram

FR-01 Functional Requirement One

NRQ-02 Non Functional Requirement Two

RDBMS Relational Database Management System

MVC. Model View Controller Architectural Pattern

BRMS Building rental Management System

SQL Structured Query Language

XSS Cross Site Scripting

GUI Graphical User Interface

BMS Building Management System

API Application Programming Interface

SDD System Design Document

AMI Asynchronous Method Invocation

TDD Test-Driven Development

iii
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

Acknowledgement

First and foremost we would like to thank the Almighty God for the strength he has given to
us the opportunity to make our beginning so successful and to see the results of our efforts. Next,
we would like to express our sincere gratitude to our advisor Mr. Abebayew S. for the continuous
support on our industrial final project, for his valuable comments, for his patience, motivation,
enthusiasm, and his guidance throughout this project work. Without his encouragement and
constant guidance, we could not have finished this project.
We are also very grateful and would like to extend our sincere thanks Abronal Technologies who
provided the idea and who helped us on our project by providing the needed information when we
were their interns. Finally, we would like to thank our colleagues and friends for their
encouragement, suggestions and support throughout the project work and also we are grateful to
everyone who involved in our project tasks by filling the questionnaires and answering our
interview questions.

iv
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

Abstract

Building owners are tasked with offering a great building for rent, search for tenant, repair and
maintain the building, collect rent, and do marketing, among others. Some owners also own
multiple rental building businesses across the country. Thus, it is not easy to manage the rental
building properly and efficiently either through the owner or agent companies. Therefore, to
facilitate easy management of rental buildings, there is need to develop a rental building
management system that can simplify work for building owners so that all their work can be
efficient and effective.
To get information about how rental building is currently being managed, we interviewed some
building owners and from the information we gathered we realized all work was done manually
with a lot of paper work involved. Papers can easily get damaged or get lost leading to loss of data.
It is also expensive to keep on buying files to store your records. A lot of files make a place look
untidy and also consume a lot of space. Getting a certain file to check data from many files becomes
a difficult task. Considering those facts, we decided to develop a rental building management
system that can solve most the problems experienced with the current manual system.
This project offers a complete solution to manage all aspects of building operations, including
tenant information management, maintenance requests, rent collection, and financial reporting for
building owners as well as advertisement of building units for potential tenants. Utilizing the latest
technologies, such as the Internet of Things and cloud computing, rental building management
systems provide a range of benefits, including reduced workload for building managers, increased
transparency and accountability, and higher tenant satisfaction. Not only do our rental building
management systems improve the management of rental buildings, but they also promote
sustainability and energy efficiency.
The system will be a web-based application that can be accessed through desktop devices and
through user mobile phones. Tools that may be used in the development of the web-based system
will be programming languages and frame works such as C# and ASP.NET.

v
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

Contents
CHAPTER 1 .....................................................................................................................................................................1
1.1. Introduction .................................................................................................................................................1
1.1.1. Background of The Project .......................................................................................................................1
1.2. Statement of The Problem .......................................................................................................................3
1.3. Objectives of The Project .........................................................................................................................4
1.2. Scope of The Project ....................................................................................................................................4
1.3. Methodology ................................................................................................................................................5
1.3.1. Interview ..................................................................................................................................................5
1.4. System Development Methodology ............................................................................................................6
1.5. Feasibility Study ...........................................................................................................................................7
1.5.1. Technical Feasibility .................................................................................................................................7
1.5.2. Operational Feasibility .............................................................................................................................7
1.5.3. Economic Feasibility ................................................................................................................................7
1.6. Significance of The Project for Our Stakeholders .........................................................................................7
CHAPTER 2: DESCRIPTIONS OF EXSTING SYSTEM ..........................................................................................................9
2.1. Introduction of The Existing System .................................................................................................................9
2.2. Proposed System Description ....................................................................................................................10
2.3. Strength of Existing System ........................................................................................................................10
2.4. Weakness of Existing System .....................................................................................................................11
CHAPTER 3: SYSTEM FEATURES ...................................................................................................................................12
3.1. Introduction ...............................................................................................................................................12
3.2. Functional Requirements ...........................................................................................................................12
3.3. Non-Functional Requirements ...................................................................................................................14
3.4. System Analysis Model ...............................................................................................................................15
3.4.1. Introduction ...........................................................................................................................................15
3.4.2. Use Case Diagram ..................................................................................................................................15
3.4.3. Use Case Description .............................................................................................................................18
3.4.4. Sequence Diagram .................................................................................................................................46
3.4.5. Activity Diagram .....................................................................................................................................52
3.4.6. Site Map .................................................................................................................................................57
3.4.7. User Interface Design.............................................................................................................................58
CHAPTER 4: SYSTEM DESIGN .......................................................................................................................................60
4.1. Introduction ...............................................................................................................................................60
4.2. Purpose of The System Design Document (SDD) .......................................................................................60

vi
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
4.3. Scope ..........................................................................................................................................................61
4.4. Architectural Design ...................................................................................................................................62
4.4.1. Logical View of the Architecture ............................................................................................................65
4.4.2. Process View ..........................................................................................................................................67
4.4.3. Deployment View ..................................................................................................................................67
4.5. Database Design .........................................................................................................................................68
4.5.1. Mapping .................................................................................................................................................71
4.5.2. Normalization ........................................................................................................................................72
Chapter 5: Conclusion and Recommendation .............................................................................................................74
5.1. Conclusion ..................................................................................................................................................74
5.2. Recommendation .......................................................................................................................................74
References ...................................................................................................................................................................75

vii
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

List of figures
Figure 1 statistical figure of houses rented worldwide ................................................................... 2
Figure 2 Use case diagram ............................................................................................................ 17
Figure 3 Sequence Diagram for Login.......................................................................................... 46
Figure 4 Sequence Diagram for Register ...................................................................................... 47
Figure 5 Sequence Diagram for Upload information ................................................................... 48
Figure 6 maintenance request ....................................................................................................... 49
Figure 7 set appointment ............................................................................................................... 50
Figure 8 view maintenance requests ............................................................................................. 51
Figure 9 Activity Diagram for Login ............................................................................................ 52
Figure 10 Activity Diagram for Register ...................................................................................... 53
Figure 11 Activity Diagram for Upload information .................................................................... 54
Figure 12 Activity Diagram for Reset Password .......................................................................... 55
Figure 13 Activity Diagram for Set appointment date ................................................................. 56
Figure 14 site map ......................................................................................................................... 57
Figure 15 user inteface sample ..................................................................................................... 58
Figure 16 user interfaces ............................................................................................................... 59
Figure 17 Logical View ................................................................................................................ 66
Figure 18 Deployment view........................................................................................................ 68
Figure 19 ER-Diagram .................................................................................................................. 70
Figure 20 Mapping ........................................................................................................................ 71

viii
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

List of tables
Table 1 Use case Description for login ......................................................................................... 18
Table 2 Use case Description for Register .................................................................................... 19
Table 3 Use case Description for Pay ........................................................................................... 20
Table 4 Use case Description for Upload information ................................................................. 22
Table 5 Use case Description for Add Location ........................................................................... 23
Table 6 Use case Description for Assign manager ....................................................................... 24
Table 7 Use case Description for Create user ............................................................................... 25
Table 8 Use case Description for Update Employee .................................................................... 26
Table 9 Use case Description for Update Profile.......................................................................... 27
Table 10 Use case Description for User detail.............................................................................. 28
Table 11 Use case Description for Delete user ............................................................................. 29
Table 12 Use case Description for Reset password ...................................................................... 30
Table 13 Use case Description for Create unit ............................................................................. 31
Table 14 Use case Description for Update Unit ........................................................................... 32
Table 15 Use case Description for View Unit detail .................................................................... 34
Table 16 Use case Description for Manage payment ................................................................... 34
Table 17 Use case Description for Browse building .................................................................... 35
Table 18 Use case Description for Set appointment date ............................................................. 36
Table 19 Use case Description for Manage Appointment ............................................................ 37
Table 20 Use case Description for Request Maintenance ............................................................ 38
Table 21 Use case Description for view maintenance requests .................................................... 39
Table 22 Use case Description for View Owner detail................................................................. 40
Table 23 Use case Description for Search .................................................................................... 41
Table 24 Use case Description for View Report .......................................................................... 42
Table 25 Use case Description for Check Market price ............................................................... 43
Table 26 Use case Description for cancel subscription ................................................................ 44
Table 27 UnnormalizedOwnerTable............................................................................................. 72
Table 28 FirstNormalOwnerTable ................................................................................................ 73

ix
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

CHAPTER 1

1.1. Introduction

1.1.1. Background of The Project

The issue of housing all over the world is an incredibly pressing and far-reaching problem. With
the global population at an all-time high, urbanization continues to be a huge factor in creating
overcrowded cities, resulting in rising rents/ home prices that are increasingly unaffordable for
many citizens. In some cities, this has caused a major problem as the number of available properties
cannot keep up with the number of people searching for them.

The urban population all round the world has led to the increase in demand for renting houses.
Renting can be an option for the issues mentioned above since it is a cost-effective way to access
safe and comfortable housing without having to make a long-term or costly commitment that
comes with buying. It allows tenants to live in a wide variety of areas, from dense urban centers
to rural communities where homeownership may be difficult to afford. Finally, renting may benefit
low-income individuals by offering housing options they are unable to secure through ownership.

Governments around the globe get involved heavily in renting markets, and most have various
policies to pursue multiple goals. In most parts of the world, people desire to own a home while
others prefer renting. However, every country has its own specific approach to solve building
building management problem and housing demand. There is a need for every government to
encourage and support the development of rental market and building rental management system
especially where most urban residents are tenants.

1
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

Figure 1 statistical figure of houses rented worldwide

The housing sector in Ethiopia has been growing and evolving over the years. It is difficult to find
an exact figure for how much money is moved in the economy using house rental sector because
there is no official data exists about how much money is moving through rental properties. Some
estimates suggest that annual rental income of around $1 billion USD is generated in Ethiopia from
the residential sector alone.

IT plays major role in house rentals, as it enables potential tenants to search for the right home and
finalize their rental agreement from virtually anywhere in the world. IT also enables real estate
companies and owners or building owners to manage, automate, and communicate with applicants
and tenants, with features such as managing their tenant, all its income and expenses. For example,
rental companies can use software to manage tenant and owners. Furthermore, online payment
options make it easier for tenants to securely pay their rent each month.

In the next subtopics of this chapter we will be discussing about general and specific objectives of
our project, scope of the study, methodology and problem statement in detail.

2
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

1.2. Statement of The Problem

Building renting is one of the prime problems existing in Ethiopia. The current building rental
system in Ethiopia is done via an intermediary such as a real estate agent and broker. The tenant
typically visits an office of the real estate agent and looks at listings of available rentals in the area.
If the tenant finds one that meets their needs, they sign an agreement with the owner. The
agreement outlines the terms and conditions of the rental, including rent amount and rental period.
Once the agreement is finalized, the tenant pays a fee to the intermediary for their services. The
building owners then keep their tenant’s data and other information manually. Additionally, the
building rental system advertisement is done using social media.

The problems of the current rental system in Ethiopia are:

I. Limited accessibility: the current system is not widely accessible for tenants because they
cannot reach every broker in their city.
II. Data growth makes storing and maintaining all data manually very difficult for brokers and
building owners.
III. Data security is not assured in manual ways. Data is recorded on books/papers which may
easily get damaged leading to loss of data.
IV. Lack of computerized system: Currently most owners or managers use the manual system
in recording and maintaining their building and customer’s data
V. While advertising building rental over social media there is the possibility of scammers
targeting potential tenant, difficult to ensure that a building is being rented out by someone
who is truly legitimate and responsible, lack of professionalism and insufficient reach since
not everyone uses social media.

Considering the above problems, we are proposing a web based building rental and
management system. Our project focuses on making management of building rental and
registering tenant information digitalized. It also advertises building rentals and units for
potential tenants.

3
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

1.3. Objectives of The Project

1.3.1. General Objective

This project aims at developing building rental management system for managing and advertising
building rentals.

1.3.2. Specific Objectives

 Analyze the challenges faced for management of building rentals

 Analyze challenges faced when looking for building rentals

 Review existing systems

 To study existing building rental advertisement mechanisms

 To design a database for managing the building rentals

 To develop a system for finding and browsing building rentals

 To create documentation of the project and web application

 To test the system

1.2. Scope of The Project

The project will mainly focus on helping the owner to manage their building and tenants’
information, and for the tenants to have a digital way to access the information about the building
and to make it easy for them to engage in any activity regarding the building including monthly
payments.

The system is supposed to have the following scope:

4
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
 The system will be hosted on the cloud so that many building owner (owners) can use it.

 It will integrate Google map.

 It will integrate online payment method.

 It focuses on renting, keeping record and managing ones building properties and human
resource (do not focus sales related management).

 It also focuses on buildings that have several units (excluding villas and small houses)

 It will enable the owners to advertise their building sections which are free for renting.

1.3. Methodology

The system methodology focuses on how to collect data and how they will be analyzed and
implemented.

1.3.1. Interview

This method was used to collect information from owners and tenants via conversation so as to
know how the manual way of managing information works, its flows and if and how the digital
system might help them.
Primary data collection
This data is collected from the respondents that will assist in developing the system. It will include
contracts, forms and other information that will be given out by respondents during an interview.

Secondary Data Collection

This data is collected from existing sources such as books, research papers (a web-based building
management system), journals and magazines we fond from the internet, that was collected by
other researchers and analysis was done. It is from that data that we then compared with the
primary data and make a decision and conclusion.

5
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

1.4. System Development Methodology

Waterfall Model

It is comprised of the stages that the developer will use when developing the system. It is a
sequential model hence, the name waterfall. The developer has to finish with one stage before
going to the next one. It comprises of the feasibility study, analysis phase, design phase, coding
phase, testing phase, implementation phase and finally the maintenance phase. It is a simple model
and easy to use and understand. With waterfall development based methodologies, the analysts
and users proceed sequentially from one phase to the next. The deliverables from each phase are
voluminous and are presented to the project sponsor for approval as the project moves from phase
to phase. Once the phase is approved by the sponsor it ends and the next phase begins.
We chose the waterfall model for our system development because it is a well-defined, structured
approach that progresses in an orderly and sequential manner. This means that each stage is
completed before the next one can begin, resulting a linear progression and reduced risk of errors.
Additionally, the waterfall model allows for successful completion of projects where requirements
are known at the outset, as project managers are able to track progress against established
milestones.

The main advantage of using Waterfall methodology is its straightforwardness. The steps involved
in the process are easy to understand and can be completed sequentially as defined in the process
design documents. This increases efficiency, minimizes wastage of resources and helps reduce
costs associated with development efforts. Additionally, there is a strong focus on documentation
during the life-cycle which leads to better version tracking and a thorough understanding of
existing systems or processes at hand.

6
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

1.5. Feasibility Study

1.5.1. Technical Feasibility

Technical feasibility considers the technical requirements of the proposed project. By this we mean
that while we develop this system and website, we have equipped ourselves with hardware-based
and software-based knowledge requirements of the proposed system and website. So, it is possible
to take guaranteed the proposed system and website as feasible. For example, the hardware
requirements as per required by the system are available at hand for showing the prototype. In
terms of software and other knowledge-based issues also have the technical solution from the
members studying timely new programming languages other frameworks such as C#, ASP.NET
MVC, entity framework and SQL server database that will have greater impact for the future, too

1.5.2. Operational Feasibility

To operate the system and the website, there is no hindrance except doing it in the wrong way. The
proposed application will consider all possible circumstances that are available at hand for
predicting the future problems. The design will handle it wisely. There for it is operationally
feasible, too.

1.5.3. Economic Feasibility

The proposed system and website, will be economically feasible because the initial requirement is
not that much expensive Nevertheless, if it gets wider in its use, the system/website will handle its
economy generating income for registering or accessing it with relatively small amount of cost
from its competitors.

1.6. Significance of The Project for Our Stakeholders

This system is for

1. Building rental owners

7
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
2. Tenants
3. Visitors

Building rental owners can use this system regardless of the size of their building or the numbers
of units the building contains. but the payment for the use of the system is relative to the size of
the building or the number of units they contain and the location where the building is found so
these owners use the system for advertising and managing their building.

Tenants who are using the rented units can use the system for paying their payment online for the
owners so it makes the payment system easier for the tenants and also for the owners who receive
the payment.

In the case of Visitors who wants to get a unit for rent can use the system for viewing any free unit
from any building using any portable device without any pre-payment and the information he/she
get is totally correct so these users can avoid their trouble while using the manual system.

8
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

CHAPTER 2: DESCRIPTIONS OF EXSTING SYSTEM

2.1. Introduction of The Existing System

Building renting is needed; hence it’s necessary to provide adequate and decent building units for
business or other purposes. This chapter will focus on reviewing challenges and existing building
rental management systems.
We have tried to look into an existing system related to building management, although most
building rental process is manual in Ethiopia, we got some systems like Ayat Real Estate and most
of them are related to displaying available buildings for sale. But our goal is not to display available
buildings for sale, which inspire us to develop a system to manage all building materials and human
resources like tenants and employees.

The building rental system advertisement done using social media can be considered as an existing
system. This type of advertisement typically involves posting information about available
properties on popular social media networks like Facebook, twitter and Telegram. These posts
usually include pictures, descriptions, and contact information for the owner or building manager.
Potential renters can view these posts, contact the owner directly for more information, or arrange
a viewing of the building.

The Ayat real estate system deals in the leasing and sale of properties as well as building
management services.
The other thing we found is paper based system. We asked the manager of Atnet building and we
got some information from the Abronal software company and both building managers said that
most of building owners in Ethiopia manage their buildings manually. On this system the payment
method, the contract and everything is paper based.

9
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

2.2. Proposed System Description

All over the world, there are a significant number of building owners using rental as a business
and they need to manage their tenants, all its income and expenses. As the number of units increase
on the building it is hard to manage all units in manual or the traditional paper based way. Some
tenants can use this weakness as a chance to evade paying the rent which causes financial
bankruptcy to the owners.
The main objective of this project is to design and implement a system that can be accessed on
portable devices such as mobile phones, that will digitalize the manual building rental management
system and thus helping the owner to manage the building and tenants’ information and the tenants
to have a digital way to access the information about the building and to make it easy for them to
engage in any activity regarding the building including monthly payments.
Thus, the focus of this project is:
 To help owners to manage building rental they have put in the market by keeping their
relation with the tenants digitalized.
 To give access to the business owner (tenants) to easily find business area via technology
rather than physically searching for rental places or find brokers who would help them the
process of finding rental houses in which they might incur extra cost.
 This system will help the owners to advertise their building sections so as they can attain
as much tenants as possible which will help them increase their income.
 Helping owners manage their buildings in one centralized system instead of assigning
many people to do the job.

2.3. Strength of Existing System

Some of the strength of the existing systems like Ayat real estate (Marefiya Gojoye) and social
media advertisement is:
 It saves the money spent on brokers to find buyers.
 It gives many options for people looking for houses.
 Easily manageable for building owners or owners.
 Easily accessible anytime anywhere for tenants and buyers.

10
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

2.4. Weakness of Existing System

Over the years’ owners/building managers have had a problem in maintaining and managing their
customers and their own records.
The data tend to grow from time to time as more tenants start renting the building. Since the data
is manually recorded and managed, it is hard to keep track of the data while it is paper based. Since
the current system that they have is manual recording of the information some of the problems the
owners face includes:

i) There is no building rental system. There are only house and apartment selling websites in
Ethiopia.
ii) Data growth, Data increase day to day. Storing and maintaining all data manually is very
difficult.
iii) Lack of computerized system. Currently most owners/building managers use the manual
system in recording and maintaining their building and customer’s data.
iv) Data security is not assured in a manual way; data is recorded on books/papers which may
easily get damaged leading to loss of data.
v) There is no database to store information, Potential of data loss or damage is very high
because data is stored on tangible files. Lack of these crucial requirements makes
management of the tenants and houses very difficult as some tenants may end up not
paying rent.
vi) Problems with advertising house rental over social media is the possibility of scammers
targeting potential tenant, difficult to ensure that a building is being rented out by someone
who is truly legitimate and responsible, lack of professionalism and insufficient reach
since not everyone uses social media.

11
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

CHAPTER 3: SYSTEM FEATURES

3.1. Introduction

This chapter includes features of the proposed system under development process. Under this
chapter, system analysis phase will be covered. The major subtopics are functional requirement,
Nonfunctional requirements and different analysis models depicted using diagrams.
In the functional and Nonfunctional requirement section we will describe what the system does
and how it should perform it. Using these two types of requirements, we will define our systems
core functionalities and performance characteristics.
Since our system is a web based design to help owners keep track of their tenants, rent payments,
and other information related to their properties, the implementation of both functional and
Nonfunctional requirements in order to ensure the successful deployment of the application is
mandatory.
Typically, Analysis model diagrams consists diagrams that illustrate the logical relationships
between individual components of a system. By utilizing analysis model diagrams such as use case
diagram, sequence diagram, activity diagram and class diagram, we are able to understand better
the overall structure of our system before moving forward with programming logic code
implementation.

3.2. Functional Requirements

This section provides a brief outline and description of the main features and functionalities of the
Lucy BRMS. The features are split into two major categories: core features and additional features.
Core features are essential to the application’s operation, whereas additional features simply add
new functionalities. The latter features will only be implemented as time permits.
The functional requirements for the proposed system include:

Functional requirements related to the Tenant:

[FR-01] The system must let the tenant to update his/her profile.

12
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
[FR-02] The system must let the tenant to request maintenance if any maintenance problem occurs
in the building.

[FR-03] The system must allow all the tenant of the system to view contract, building and payment
information from the system.

[FR-04] The system must allow the tenant to perform online payment.

Functional requirements related to the visitor:

[FR-05] The system must let the visitor to set appointment date.

[FR-06] The system must let the visitor to browse the buildings in the system.

Functional requirements related to the owner:

[FR-07] The system must allow the owners to register to use the system for their buildings.

[FR-08] The system must allow the owner to add building.

[FR-09] The system must allow the owner to get tenant, unit and payment reports.

Functional requirements related to the manager:

[FR-10] The system must allow the manager to update building details.

[FR-11] The system must allow the manager to calculate lease fees.

[FR-12] The system must allow the manager to add tenant.

[FR-13] The system must allow the manager to get information about the tenants.

[FR-14] The system must allow the manager to maintain tenant-in form upon the tenant’s start of
contract and edit and delete various components from the system which include tenants, contracts
and payment.

13
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
[FR-15] The system must allow the manger to maintain the tenant-out form upon the tenant’s end
of contract and update information.

Functional requirements related to the system administrator:

[FR-16] The system must allow the administrator to view all building owners detail information.

[FR-17] The system must allow the administrator to cancel owner’s subscriptions.

3.3. Non-Functional Requirements

Non-functional requirements are requirements that are not directly concerned with the specific
services delivered by the system to its users. Instead, they describe user-visible features of the
system. They may relate to emergent system properties such as reliability, response time, and
store occupancy.

Non-functional requirements for the proposed system include:

[NFQ-02] Usability:
 Usage environment (browser support, desktop, tablet and smart phone)

 Error message shall display in the form of notification.

 The system shall use English language by default.

[NFQ-03] Availability:

 The system shall be available 24/7 and in anywhere a user wants to access it, unless there
is connection interruption or other cases.

[NFQ-04] Performance:

 The response shall be fast enough to avoid interrupting the user’s flow of thought.
(Quantification: A sampling of representative users shall use the system and the product
shall respond in reasonable time for 90 percent of the user interactions.)

14
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
[NFQ-05] Security:

 Login verification will be checked to remove XSS and SQL injection.

 For the sake of database consistency for every forms on the site shall be input validation

[NFQ-06] GUI:

 The user interface shall be Web based and all functions shall operate fully with all popular
Web browser/operating system family combinations. All versions of any such Web
browser that have been the latest version at any time in the past two years shall be
supported.

3.4. System Analysis Model

3.4.1. Introduction

In this section we will cover analysis models which allow us to describe the internal elements of
our system.
 The UML use case diagram
 Sequence diagram
 Activity diagram
 Class diagram
 User interface design

3.4.2. Use Case Diagram

A use case is a sequence of actions that provides measurable value to an actor. It also describes a
way to which a real world interacts with the system using diagram called use case.
This use case diagram illustrates:
 A set of use case for the system
 The actors of the use cases in the system

15
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
 The relations among the use cases.
 The relations between the actors and the use cases

Use cases
1. Login 9. Update Profile 17. Maintenance Request
2. Logout 10. Manage Employee 18. View Maintenance
3. Register 11. Reset password Request
4. Pay 12. Manage Unit 19. Search
5.Upload Building 13. Manage payment 20. View Report
Information 14. Browse Building 21. Check Market Price
6. Add Location 15. Set appointment date 22. Cancel subscription
7. Assign manager 16. Manage Appointment 23. View Owner Details
8. Manage Tenants

16
LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

Figure 2 Use case diagram

17
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

[NB-1]
The tenant, Employee and Unit management use cases in a Building Management System (BMS)
is a crucial component of the system as it allows administrators to manage the tenants associated
with a building. The management use cases typically include the following actions:
Create: Allows the Manger to add new Actors or Properties to the system.
Update: Allows the Manger to modify existing Actors or properties information.
Delete: Allows the Manger to remove Actors or Properties from the system.
View Details: Allows the Manger to view information about a specific Actors or Properties

3.4.3. Use Case Description

Table 1 Use case Description for login

Use Case ID 01

Use Case Name: Login

Actors: Owner, Admin, Tenant

Description: This use case describes how to authenticate and validate system members and admin, so
that only members and admin with correct username and password can access the system

Trigger When all users want to login to use the system

Pre-conditions: All users must have an account to login

Normal Flow: User Action System Response

1. Users’ open login page 2. The system responses by display the login
page
3. The users fill the login form by
providing phone/email and password 5. System checks whether all the fields are
filled accurately and are valid and verify from
4. They click login button. database

18
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
6. The user gets access to corresponding 7. Use case ends
homepage

Post conditions: The user will be logged into the system if the user is registered in the system and inserted
correct username and password

Alternative Flows: Alternate Course

5.1. If user enters invalid email/username or tries to login without filling out all the provided
fields, try again or fill out all field

5.2 The System determines the Alternate course of Action invalidity of email/username
and/or give a warning message to user to fill all available fields. Go to step 3.

Table 2 Use case Description for Register

Use Case ID 02

Use Case Name: Register

Actors: Owner

Description: This use case describes how the owner register (sign up) to the system.

Trigger When all building owners want to register to use the system

Pre-conditions: All Building Owners must browse to the system and open register page

Normal Flow: User Action System Response

19
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
1. Owners’ open registration page 2. The system responses by display the
registration page
3. The owners fill the register form by
providing all needed information. 5. System checks whether all the fields are
filled accurately and are valid.
4. They click sign up button.
6. store to database
7. The owner gets in to payment gateway
integration). 8. Use case ends

Post conditions: Once the owner has registered, they would be directed to a payment gateway, where they
would be prompted to make a payment for the system. The payment gateway could be
integrated with a variety of payment methods, such as Stripe

Alternative Flows: Alternate Course

5.1. If the owner enters invalid input or tries to register without filling out all the provided
fields, try again or fill out all field

Table 3 Use case Description for Pay

Use Case ID 03

Use Case Name: pay

Actors: Owner , Tenants, Manager

Description: This use case describes how the owner pay the payment for the use of the system, the tenant
pay for the rented unit and the manager pays salary for employees.

20
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
Trigger Owner Manager and tenant clicks on the "Pay" button

Pre-conditions: The owner would be directed to a payment page after they have registered and they click
“pay” button. The tenants and the manager will also click the “pay” button to initiate the
payment process.
Normal Flow: Owners Action System Response
1. The owner, manager, tenant clicks the 2. The payment gateway will display payment
“pay now” button page with details

3 The owner, manager, tenant fills the 5. Payment gateway verifies the payment: The
details for the payment. payment gateway would then communicate
with the owner's bank or the credit card issuer
4. Owner, manager, tenants review and to verify that the payment details are valid and
confirm the payment: The owner, that the account has sufficient funds to
manager, tenants would then review the complete the transaction.
payment details. They would then confirm
the payment by clicking on a "Pay" button. 6. Payment gateway sends a response: The
payment gateway would then send a response
7. Owner, manager, tenants receive a to the system indicating whether the payment
confirmation: The owner would then was successful or not. If the payment was
receive a confirmation of the payment, successful, the owner's account would be
either on the screen or by email. The activated and they would be granted access to
confirmation would include the payment the system
amount, the date and time of the payment,
and a reference number. 8. redirect owner to upload information page

8. use case ends

Post conditions: after the owner, manager, tenants receives the payment confirmation, they would typically
be directed to a page where they can upload additional information required for the building
management system

Alternative Flows: Alternate Course

5.1. If the transaction fails, ask the owner, manager, tenants to try again

21
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

Table 4 Use case Description for Upload information

Use Case ID 04

Use Case Name: Upload information

Actors: Owner

Description: This use case describes how the owner uploads information about the building into the
system.

Trigger Confirmation of successful payment: Once the payment is successful, the owner can be
prompted to upload their information.

Pre-conditions: Valid account: The owner must have a valid account on the system, with a valid username
and password, before they can upload their information and be granted access.

Normal Flow: Owners Action System Response

2. Owner fills valid information about the 1.System displays form to be filled
building.
4. system checks if the information is valid
3. Owner reviews and confirms the
information by clicking “Submit” button. 5. Store in the database if it is valid and
correct.

6. use case ends

Post conditions: The information must be available for visitors and other users

Alternative Flows: Alternate Course

4.1. If the owner enters invalid input or tries to submit without filling out all the provided
fields, try again or fill out all field

22
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
Table 5 Use case Description for Add Location

Use Case ID 05

Use Case Name: Add location

Actors: GPS, Owner

Description: This use case describes how GPS is included in the system to make it easy for buildings to
be found, and how the Owner interact to the location to store its location information into
the database.

Trigger When users click location button

Pre-conditions: All Building Owners must browse to the system and open building register page

Normal Flow: User Action System Response

1. user click on location button 2. The map display that include a map view
and a search bar, where the administrator can
3. The administrator will enter the location enter an address or place name.
of the building.
5. The Google map will be geocoding (covert
4. Administrator enters all other addresses to coordinates) and store the data
information: and click the upload building into the database.
button
6. use case end
Post conditions: The building location is displayed on the map: The location of the building is displayed on
the map, which can be viewed by the administrator, owner, and visitor.

Alternative Flows:

23
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
Table 6 Use case Description for Assign manager

Use Case ID 06

Use Case Name: Assign manager

Actors: Owner

Description: The building owner assigns manager and gives some authority and privilege to run things
in the system.

Trigger When all building owners want to register their managers to use the system

Pre-conditions: The building owner must first subscribe to the system and fill in formation about the
building
Normal Flow: Owners Action System Response
1. Owner navigates to the user 2. the system will display user management
management page. page.

3. Owner grants permission to the 4.the system validates the change.

administrator: The owner would select the
administrator's account and grant them 5. The system stores the changes.
specific permissions
6. The system sends a notification to the
administrator: The system would send a
notification to the administrator, alerting them
that the owner has granted them permission.

7. use case ends

Post conditions: The manager can now login to the system and access or alter some information’s in the
system.
Alternative Flows: Alternate Course

4.1. If any issues are found, the owner would be prompted to correct them.

24
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

Table 7 Use case Description for Create user

Use Case ID 07

Use Case Name: Create user(tenant, employee)

Actors: manager

Description: This use case describes how the manager create a new user to the system like tenants and
employees.
Trigger The manager clicks on a button or link to create a new user.

Pre-conditions: The manager logs into the building management system and navigates to the user management
section.
Normal Flow: Manager Action System Response User action
1. Clicks on a button or link 4. The system validates the information 6. The new user
to create a new user. entered by the manager, ensuring that receives the
all required fields are filled out and that message, clicks on
2. A form appears for the the email address is in the correct the link, and sets
manager to fill out with the format. their password.
user's information, such as
name, email, contact 5. Once the information is validated,
number, and role (tenant or the system sends an email or text
employee). message to the new user with a link to
set their password and login to the
3. The manager enters the system.
user's information and clicks
on a submit button. 7. use case ends

Post conditions: The system updates the user's status to active, and the new user can now log in to the system
and access their account.

25
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
Alternative Flows: Alternate Course

4.1. if the information entered by the manager is not valid, the system will typically display
an error message to the manager and highlight the specific fields that contain invalid
information. The manager can then correct the information and resubmit the form

Table 8 Use case Description for Update Employee

Use Case ID 08

Use Case Name: Update employee

Actors: Manager
Description: This use case describes how the manager updates the employee information in the system.

Trigger The employee's contact information, role is changed and needs to be updated in the system.

Pre-conditions: The manager logs into the building management system and navigates to the employee
management section.
Normal Flow: Manager Action System Response

26
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
1.The manager searches for the 3. The system displays the employee information,
employee they want to update by such as name, email, number, and role (tenant or
using the search function or by employee) in a form, which the manager can edit.
browsing through a list of employee.
5. The system validates the information entered by
2. The manager selects the employee the manager, ensuring that all required fields are
they want to update. filled out and that the email address is in the correct
format.
4. The manager makes the
necessary changes to the employee 6. Once the information is validated, the system
information and clicks on a submit updates the employee information in the system.
button.
7.Use case ends

Post conditions: The building management system will update the employee information.

Alternative Flows:

Table 9 Use case Description for Update Profile

Use Case ID 09

Use Case Name: Update Profile

Actors: Tenant
Description: This use case describes how the tenants updates their user information in the system.

Trigger The tenant's contact information, contract is changed and needs to be updated in the system.

Pre-conditions: The tenant logs into the building management system and update his/her profile

27
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
Normal Flow: Manager Action System Response
1.The tenant clicks update profile 3. The system displays the tenant information, such
button. as name, email, contact number,

2. The tenant selects the information 5. The system validates the information entered by
they want to update. the tenant, ensuring that all required fields are filled
out and that the email address is in the correct
4. The tenant makes the format.
necessary changes to the information
and clicks on a submit button. 6. Once the information is validated, the system
updates the tenant information in the system.

7.Use case ends

Post conditions: The building management system will update the tenant information.

Alternative Flows:

Table 10 Use case Description for User detail

Use Case ID 10

Use Case Name: User detail

Actors: manager

Description: This use case describes how the manager views detail information about the users they want.

28
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
Trigger The manager needs to verify the user's information for administrative or billing purposes.

Pre-conditions: The manager logs into the building management system and navigates to the user
management section.

Normal Flow: Manager Action System Response

1. The manager searches for the user 3. The system displays the user's information, such
they want to view by using the search as name, email, contact number, and role (tenant or
function or by browsing through a employee) in a form, which the manager can view.
list of users.
4. The system also displays other information
2. The manager selects the user they related to the user, such as the transactions, bills,
want to view. and appointments.

5. use case ends.

Post conditions: The system will not make any changes to the user's information or account.

Alternative Flows:

Table 11 Use case Description for Delete user

Use Case ID 11

Use Case Name: Delete user

Actors: manager

Description: This use case describes how the manager deletes users from the system.

Trigger The tenant's or employee's lease or contract has ended and they are no longer associated
with the building.

Pre-conditions: The manager logs into the building management system and navigates to the user
management section.
Normal Flow: Manager Action System Response

29
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
1. The manager searches for the user 3. The system will prompt the manager to confirm
they want to delete by using the search the deletion, and the manager will need to click
function or by browsing through a list on a button to confirm the deletion.
of users.
4. The system will also delete any related
2. The manager selects the user they information, such as the user's transactions, bills,
want to delete. and appointments.

5. use case ends.

Post conditions: Once the deletion is confirmed, the building management system will remove the user from
the system, and the user will no longer be able to log in or access their account.

Alternative Flows: Alternate Course

3.1 The building management system may simply cancel the deletion process and the user
will remain in the system.

Table 12 Use case Description for Reset password

Use Case ID 12

Use Case Name: Reset Password

Actors: Users

Description: This use case describes how users will reset their password

Trigger When all users want to reset their password

Pre-conditions: User must click reset password option and he must log out

Normal Flow: User Action System Response

30
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
1. User will click reset password 2. The system will redirect to page where user can
enter their email to receive a link to reset their
3. The user click the reset password password
link
4. The system redirect to a page to which user can
5. The user will enter new password input new password

6. The system will check the input and match with

the confirm password

7. The System will store the new password to the

database 8. use case will end
Post conditions: The user will login with the updated password

Alternative Flows: Alternate Course

6.1 If the password is not secure and mismatch with the confirmation password, the
appropriate message will be displayed

Table 13 Use case Description for Create unit

Use case ID 13

Use Case Name: Create unit

Actors: manager

Description: This use case describes how the manager add or creates a new unit to the system.

Trigger When a new building is added to the management system, and units need to be created for
it.

Pre-conditions: The manager logs into the building management system and navigates to the unit
management section.
Normal Flow: Manager Action System Response

31
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
1. The manager clicks on a button or 2. The system displays a form for the manager to
link to create a new unit. enter the unit information, such as unit name,
number, type, size, and any other relevant
3. The manager fills out the form with information.
the information for the new unit and
clicks on a submit button. 4. The system validates the information entered by
the manager, ensuring that all required fields are
6. The manager can view the new unit filled out and that the unit name or number is
in the unit management section and unique.
can edit or delete it as needed.
5. Once the information is validated, the system
creates the new unit in the system and assigns it the
appropriate attributes.

7. use case ends

Post conditions:

Alternative Flows: Alternate Course

4.1 The system will display an error message, indicating which fields are incorrect or
missing. The manager will need to correct the errors and resubmit the form.

Table 14 Use case Description for Update Unit

Use Case ID 14

Use Case Name: Update unit

32
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
Actors: manager

Description: This use case describes how the manager updates the existing unit information in the system.

Trigger When an existing unit's information needs to be updated for administrative or billing
purposes.

Pre-conditions: The manager logs into the building management system and navigates to the unit
management section.
Normal Flow: Manager Action System Response
1. The manager searches for the unit 3. The system displays a form for the manager to
they want to update by using the update the unit information, such as unit name,
search function or by browsing number, type, size, and any other relevant
through a list of units. information.

2. The manager selects the unit they 5. The system validates the updated information,
want to update. ensuring that all required fields are filled out and that
the unit name or number is unique.
4. The manager makes the
necessary updates to the unit 6. Once the information is validated, the system
information and clicks on a submit updates the unit information in the system, and
button. updates any related information, such as the
building's occupancy, available units, and unit type.

7. use case ends.

Post conditions: The manager can view the updated unit information in the unit management section, and
can edit or delete it as needed.
Alternative Flows: Alternate Course

5. 1 The system will display an error message, indicating which fields are incorrect or
missing. The manager will need to correct the errors and resubmit the form.

33
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
Table 15 Use case Description for View Unit detail

Use Case ID 15

Use Case Name: View Unit detail

Actors: manager

Description: This use case describes how the manager views a detail information of the unit he wanted
to see.
Trigger When the manager needs to check the unit's information for administrative or billing
purposes. or When a tenant or employee requests more information about the unit.

Pre-conditions: The manager logs into the system and navigates to the unit management section.

Normal Flow: Manager Action System Response

1. The manager searches for the unit they 3. The system displays a detailed view of the
want to view by using the search function unit information, such as unit name, number,
or by browsing through a list of units. type, size, occupancy status, tenant/employee
information.
2. The manager selects the unit they want
to view. 4. use case ends.

Post conditions:

Alternative Flows: Alternate Course

Table 16 Use case Description for Manage payment

Use Case ID 16

34
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
Use Case Name: Manage payment

Actors: Building owner, Tenant, Payment gateway, manager, admin

Description: This use case describes how payment is done between building owners, manager, tenant,
and admin

Trigger The customer initiates a payment by entering their payment information on a form or
checkout page within your building management system.

Pre-conditions: Registering to the system

Normal Flow: System action Payment gateway

1. The system sends the payment 2.The payment gateway performs various
information, along with any additional checks and validations on the payment
information required by the payment information, such as checking for fraud and
gateway (such as the amount, currency, and ensuring that the customer has sufficient
a description of the purchase), to the funds.
payment gateway's servers
3. If the payment is approved, the payment
4. The system updates the customer's gateway sends a confirmation message to
account and records the transaction. the building management system, along with
any relevant transaction details.
5.use case end
Post conditions: After the payment is complete, the customer is typically redirected back to the system,
where they can view their receipt or order details.
Alternative Flows: Alternate Course
3.1 the payment gateway sends an error message to the building management system, which
can then be displayed to the customer.

Table 17 Use case Description for Browse building

Use Case ID 17

35
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
Use Case Name: Browse building

Actors: Visitor

Description: This use case describes how users can open the site and look into available information on
our site

Trigger When all users open the website

Pre-conditions: All users must browse to the system

Normal Flow: visitor Action System Response

1. Visitor opens the system 2. The system responses by display the home
page.
3. looks into the building information
displayed. 5. the system will display the detail of the selected
building.
4. If the user is interested in any
building the clicks “detail” button. 7. use case end

6. The user views the detail

Post conditions: If the visitor is interested on one of the buildings detail he/she will go for appointing a date
to visit.
Alternative Flows:

Table 18 Use case Description for Set appointment date

Use Case ID 18

Use Case Name: Set appointment date

36
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
Actors: Visitor

Description: This use case describes that when a visitor is interested in renting a unit, he/she asks for
appointment date to see the building in person and rent the unit.

Trigger When visitors want to view the building in person and click the “appointment date” button.

Pre-conditions: The visitor must view detail information of the building they are interested in.

Normal Flow: Visitor Action System Response

1. Visitor looks for suitable units 3. The system prompt the visitor to enter their contact
that match their needs. information, such as their name, email, phone
number and appointment date from Calendar or time
2. The visitor selects a unit that they picker.
are interested in and clicks on a
button to request an appointment. 6. The system receives the appointment request and
sends an email or text message to the visitor to
4. The visitor enters all information confirm the appointment details.
and selects a date and time for the
appointment. 7. use case ends

5. The visitor confirms the

appointment details and submits the
request.

Post conditions: The visitor receives confirmation message through email or text message about the
confirmation of the appointment.
Alternative Flows:

Table 19 Use case Description for Manage Appointment

Use Case ID 19

37
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
Use Case Name: Manage Appointment

Actors: manager

Description: This use case describes how the manager sees the appointments of the visitors and
accept/reject it.
Trigger When a person requests an appointment to view a unit through the system's website.

Pre-conditions: The manager logs into the system and navigates to the appointment management section.

Normal Flow: Manager Action System Response

1. The manager sees the request for the appointment, 3. The system will send
which includes the person's contact information, the confirmation message to the user.
desired appointment date and time, and the unit that
the person is interested in viewing. 4. use case ends.

2. The manager can accept the request by clicking on

an "accept" button, in this case, the system will
confirm the appointment to the person who requested
it and update the unit's status to "booked" or
"reserved" and if he want it will reject it
Post conditions: The user receives confirmation messages about the appointment from the system.

Alternative Flows: Alternate Course

Table 20 Use case Description for Request Maintenance

Use Case ID 20

Use Case Name: Request Maintenance

38
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

Actors: tenant

Description: This use case describes how tenants comment about the building or the unit they are using
when they discover problem with the unit/building , such as a malfunctioning toilet or a
broken light bulb.
Trigger When the tenant click maintenance request.

Pre-conditions: Tenant must login to the system

Normal Flow: User Action System Response

1. The tenant navigates to a form or page 4. The building management system receives
within the system where they can submit a the request and sends a notification to the
maintenance request. manager.

2. The tenant fills out the form, providing 5.use case ends.
details about the problem and the unit
number.

3. The tenant submits the request, which is

sent to the building management system.
Post conditions: The staff member receives the notification and takes appropriate actions by scheduling the
repair or replacement of the items.
Alternative Flows: Alternate Course

Table 21 Use case Description for view maintenance requests

Use Case ID 21

Use Case Name: View maintenance requests

39
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
Actors: manager

Description: This use case describes how the manager views the requests made by the tenants about
maintenance.
Trigger When a tenant experiences an issue and submits a maintenance request through the system's
website.

Pre-conditions: The manager logs into the building management system and navigates to the maintenance
request List.

Normal Flow: Manager Action System Response

1. The building manager can review the 3. The system will provide a report page for
request and determine the urgency of the the manager to fill necessary information
issue. about the maintenance.

2. The manager clicks “Done” button after 5. The system validates the filled information.
finishing the required maintenance.
6. The system stores information to the
4.The manager fills the required database.
information about the maintenance
and submit the report. 7. use case ends.

Post conditions: The manager can view lists of completed maintenance with their details.

Alternative Flows: Alternate Course

5.1. The system will display an error message, indicating which fields are incorrect or
missing. The manager will need to correct the errors and resubmit the report.

Table 22 Use case Description for View Owner detail

Use Case ID 22

40
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
Use Case Name: View owner detail

Actors: admin

Description: This use case describes how the admin is granted the permission to see all Owner details

Trigger
When admin clicks on show Owner detail button

Pre-conditions:
The building owners must submit building and their contact information.
Normal Flow: Admins Action System Response
1.click on show Owner detail 2.fetch from database and display.

3. Admin view the displayed detail. 4. use case ends.

Post conditions:

Alternative Flows: Alternate Course

2.1 if there is no record on the database, display there is no information in the database.

Table 23 Use case Description for Search

Use Case ID 23

Use Case Name: Search

Actors: User

Description: This use case describes how users will search any information in the system

41
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
Trigger When all users hit the search button after writing query

Pre-conditions: User must be logged in

Normal Flow: User Action System Response

1. User will type search query 2. The system will automatically suggest after
each query
3. The user click on of the suggestion or
search button 4. The system will display search result from
database
4. They click subscribe
5. store to database the credentials

6. Use case ends

Post conditions: The user is able to see searched information

Alternative Flows: Alternate Course

5.1. If user inputs invalid query or if the searched query result doesn’t found in database,
appropriate message will be shown

Table 24 Use case Description for View Report

Use Case ID 24

Use Case Name: View report

Actors: Owner

Description: In this use case the building owner can see reports(financial, occupancy, maintenance) about
the building.
Trigger When the owner clicks on the report button

Pre-conditions: The system must prepare and organize the monthly report and store it on the database

42
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
Normal Flow: Owners Action System Response
1.The owner clicks the report button. 2. The system displays the report page.

3. The owner select the report they want to 4. The system fetches the reports about what
view from a list of available reports. the owner selects and wants to see.

5. The owner review the report, and can 7. use case ends.
filter the data to see specific information.

6. The owner can export the report in

different format like excel, pdf, or csv for
their own use.
Post conditions:

Alternative Flows: Alternate Course

4.1 if there is no report on the database the system displays no report exists.

Table 25 Use case Description for Check Market price

Use Case ID 25

Use Case Name: Check market price

Actors: Manager

Description: This use case describes how the manager set price of a unit based on pricing information
he/she get from the current market.
Trigger When a manager wants to set the price for a new unit that is being added to the building
management system.

Pre-conditions: The manager logs into the building management system and navigates to the unit
management section.
Normal Flow: User Action System Response

43
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
1. The manager selects the unit they want 2. The system displays data on the current
to price and clicks on a button or link to market prices for similar units in the area,
view pricing information. including the average price, the highest price,
and the lowest price.
3. The manager views the displayed data
and decide/set price of the unit. 4. The system stores the price in the database.

4. The manager submits the price of the 5. Use case ends.

unit.

Post conditions: The manager/visitor/users can view the price of the unit.

Alternative Flows: Alternate Course

Table 26 Use case Description for cancel subscription

Use Case ID 26

Use Case Name: Cancel subscription

Actors: admin

Description: This use case describes how admin (developer) removes subscribers when they no longer
want to use the system.
Trigger When owner requests cancel subscription

Pre-conditions: The owner must request to stop using the system

Normal Flow: Owners Action System Response Admins response

44
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
1.Owner requests to cancel 2. System notifies the 3.The admin removes the owner,
subscription. admin manager and tenants of the
building subscribed in the
4. use case ends system.
Post conditions: The building owner, manager and tenants must be denied from accessing the system

Alternative Flows: Alternate Course

45
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

3.4.4. Sequence Diagram

Figure 3 Sequence Diagram for Login

46
LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

Figure 4 Sequence Diagram for Register

47
LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

Figure 5 Sequence Diagram for Upload information

48
LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

Figure 6 maintenance request

49
LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

Figure 7 set appointment

50
LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

Figure 8 view maintenance requests

51
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

3.4.5. Activity Diagram

Figure 9 Activity Diagram for Login

52
LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

Figure 10 Activity Diagram for Register

53
LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

Figure 11 Activity Diagram for Upload information

54
LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

Figure 12 Activity Diagram for Reset Password

55
LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

Figure 13 Activity Diagram for Set appointment date

56
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

3.4.6. Site Map

Figure 14 site map

57
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

3.4.7. User Interface Design

Figure 15 user interface sample

58
LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

Fig 16 user interfaces

59
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

CHAPTER 4: SYSTEM DESIGN

4.1. Introduction

In this chapter we will see a detailed overview of the system design, architectural design, and
database design of the Building Management System (BMS) project. In this chapter, we will delve
into the various components of the system, their relationships with each other, and the overall
architecture of the system.

4.2. Purpose of The System Design Document (SDD)

The System Design Document (SDD) is a fundamental document that acts as the heart of system
development in building rental software. It provides a detailed understanding and overview of the
system structure and its functionalities, while also detailing the requirements needed to
successfully implement and manage an effective building rental software solution.

The SDD outlines all aspects of the proposed software project, including overall goals,
architecture, system components, databases, technologies used, logic flow diagrams, database
models and designs. Its goal is to give developers a thumbs-up on the design before development
begins.

The SDD for building rental software should be thorough enough to provide builders with clear
guidelines for developing each component of their app as well as defining roles for users involved
in completing tasks across multiple sites or locations. For instance: The document should describe
how access rights are granted to different users on different parts of the web application such as
editing tenant data or approving contracts from authorized users at particular locations; it should
also outline any third-party integrations needed to complete particular tasks like registration
systems or credit card payment processing systems.

60
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

4.3. Scope

System Design for Building Rental Software may include:

 Requirements Gathering and System Analysis which we saw in chapter 3

 forming architectural design for our project
 Database Design: we will focus in this chapter
 User Interface Design, Development, Testing and Implementation which we will be doing
next semester.

Database Design:
Decide the type of databases that will best suit the system requirements e.g., Relational Database
Management System (RDBMS), object-oriented database or NoSQL etc. Set up data structures /
schemas based on this decision covering entities/objects like rental agreement documents etc.,
along with any relations between them.

User Interface Design:

Design a friendly user interface following usability principles which enables users to interact with
the system in an effective manner ensuring desired results are achieved quickly without any
confusion. This should cover devices like mobile phone, desktop computer etc.

Development:
-Develop application code using development languages(s) which satisfy the desired functional
requirements efficiently. This could involve setting up an API server layer which
interacts with clients at frontend and internal databases behind it. Code review checks can be done
throughout this process to ensure quality standards are met.

Testing & Implementation:

Perform unit testing where individual components of developed code are tested for functionality
in isolation from other parts of code. Integration tests need to be performed by combining
different units together & required scenario tests to ensure complete functionality of intended

61
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
features work correctly & expected results are achieved successfully. Deployment plan needs to
be designed for smoothly pushing out software into production environment

4.4. Architectural Design

Architectural design is the process of defining a structured solution that meets all of the technical
and operational requirements, while optimizing common quality attributes.
The architecture used for the system we are going to build is a Model View Controller
Architectural pattern (MVC). MVC is short for Model, View, and Controller, is a methodology or
architectural pattern used for efficiently relating the user interface to underlying data models and
organizing to relate the application code. MVC is primarily used to separate an application into
three main Components: Model, View, and Controller.

Model: the center of the pattern. It is the application’s dynamic data structure, independent of the
user interface. It directly manages data, logic and rules of the application. It communicates with
database and retrieves data for controller.
This level is considered the lowest level when compared with the View and Controller. It primarily
represents the data to the user and defines the storage of all the application’s data objects.

Controller: the controller’s job is to take the user’s input and figure out what to do with it. It
means that this part is used to receive events from views, and will implement all actions to give
data to the model. And the controller also will take all modifications from the model, and then
creates some updates to the view. This level takes care of the request handler. It is often considered
as the brain of the MVC system- a link, so to speak, between the user and the system. The controller
completes the cycle of taking the user output, converting it into desired messages, and passing
them on to the views (UI).

View: the presentation of application that users can interact with it. In some variations of MVC,
the view does not directly interact with the model. But originally, MVC use observer pattern to
know all changes from the model to update the view part. This level is majorly associated with the

62
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
User Interface (UI) and it is used to provide the visual representation of the MVC model. In simpler
terms, this level deals with displaying the actual output to the user. It also handles the
communication between the user (inputs, requests, etc.) and the controller.

This MVC architectures division of system is not based on functionality but based on volatility.
This means, things that must often change are separated together so as to meet the low coupling.

Since MVC architecture has the following advantages, we have chosen this architecture to take
advantage of it and we thought it very suitable for the project we are building.
 It organizes large-size web applications
 It supports Asynchronous Method Invocation (AMI)
 It makes the project easily Modifiable
 It allows faster Development Process
 It enables easy planning and maintenance
 It supports TDD (test-driven development)
 Multiple Views are easily achievable

According to the above information, we divided our system into the following sub systems.

Models of The Systems includes

 Owner

 Building

 Tenant

 Employee

 Visitor

 Maintenance

 Unit

 Contract

63
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
 Expense

 Salary

 Department

 Payment

Views of The Systems includes

 Authenticate user UI

 Manage Owner UI

 Manage Building UI

 Manage Employee UI

 Display dashboard UI

 Display Building Details UI

 Display Expense Details UI

 Display Payment Status UI

Controllers of The Systems Includes

 Owner Controller

 Building Controller

 Tenant Controller

 Employee Controller

 Visitor Controller

64
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
 Maintenance Controller

 Unit Contract

 Expense Controller

 Salary Controller

 Department Controller

 Payment Controller

4.4.1. Logical View of the Architecture

A logical view shows the key abstractions in the system as objects or object classes. It should be
possible to relate the system requirements to entities in this logical view.
Our system will be developed based on a tiered logical architecture because Organizes the system
into layers with related functionality associated with each layer. A layer provides services to the
layer above it so the lowest-level layers represent core services that are likely to be used
throughout the system where the user interface, business logic, and data access logic parts of the
system are separated. It must have a minimum of three layers (tier); the presentation tier, logical
tier, and data access tier.
 The Presentation Tier: is the topmost level of the application. It is the one the users
directly interact with. It provides GUI to allow the tenant, visitor, owner, admin gaining
access to the system.
 Logical Tier/Middle Tier: It accepts inputs from the tenant, visitor, owner, admin and
performs detailed processing. Like for example form handling and more it is a bridge
connecting between the presentation tier and data access tier.
 Data Access Tier: Provides data persistence mechanism and storage to the data. It consists of a
mechanism to access the database without installing database dependent drivers and libraries on
the client device.
 Our system has three architectural structures: client side, server and database.
 Client side: the client side includes tenant, visitor, owner and admin.
 Server side: the web server to connect the database applications(facilities)

65
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
 Database: the database that stores information
The proposed logical architecture is depicted below.

Figure 17 Logical View

66
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

4.4.2. Process View

It is all about processes and threads into which execution is divided. A process view, which shows
how, at run-time, the system, is composed of inter-acting processes. This view is useful for making
judgments about non-functional system characteristics such as performance and availability. It also
describes the allocation of objects and classes to tasks.

4.4.3. Deployment View

To provide a basis for understanding the physical distribution of the system across a set of
processing nodes, an architectural view called the deployment view is used in the Analysis &
Design workflow. The deployment view (one of five views) illustrates the distribution of
processing across a set of nodes in the system, including the physical distribution of processes
and threads. The deployment view is refined during each iteration. And we can best resolve this
view using deployment diagram our system deployment diagram will be shown below.

67
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

Figure 18 Deployment view

4.5. Database Design

Database design is the organization of data according to a database model that involves classifying
data and identifying interrelationships.it is collection of processes that facilitate the designing,
development, implementation and maintenance of enterprise data management systems. Properly
designed databases are easy to maintain, improve data consistency and are cost effective in terms
of disk storage space. The main objective of database designing is to produce logical and physical

68
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
designs models of the proposed database system. The logical model concentrates on the data
requirements and the data to be stored independent of physical considerations. It does not concern
itself with how the data will be stored or where it will be stored physically. The physical data
design model involves translating the logical design of the database onto physical media using
hardware resources and software systems such as database management systems. In these pages
we designed logical model of database design. To represent database design of our project we have
used Entity relationship diagram.

69
LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

Figure 19 ER-Diagram

70
LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

4.5.1. Mapping

Figure 20 Mapping

71
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

4.5.2. Normalization

Normalization is the process of organizing data into tables in such a way that the results of using
the database are always unambiguous and as intended. It is a technique of organizing the data
into multiple related tables to minimize data redundancy. Data redundancy is repetition of similar
data at multiple rows. Repetition of data increases the size of database. Data redundancy also
produces the following issues:
 Insertion problem
 Deletion problem
 Updating problem

There are three basic normalization techniques

1. First normal form
In this normalization technique, we can follow the following basic rules
 Each column of table must contain single values (atomic values).
 Column should contain values that are of the same type.
 Each column should have unique name. similar name of columns leads to confusion at the
time of data retrieval.
 Order in which data stored doesn’t matter

Unnormalized Form

Owner
Table 27 UnnormalizedOwnerTable

id First_name Last_name adress email phone

1 Elias Kebede Ethiopia,Hawassa Kebedeelias30@gmail.com 0902318728
2 Ashenafi Terefe Ethiopia,Shashemene Ashenafiterefe.3874@gmail.com 0916063874

72
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION

NB [1]- Since address attribute contains composite values we have to normalize it to first normal
form

First Normal form

Table 28 FirstNormalOwnerTable

id First_name Last_name Country City email phone

1 Elias Kebede Ethiopia Hawassa Kebedeelias30@gmail.com 0902318728
2 Ashenafi Terefe Ethiopia Shashemene Ashenafiterefe.3874@gmail.com 0916063874

2. Second normal form

For the table to be in the second normal form:
 It should be in the first normal form
 And it should not have any partial dependency

NB [2] - Our tables already don’t have any partial dependency, since the we don’t need to
normalize it to second normal form

3. Third normal form

For table to be in third normal form:
 It should be in second normal form
 And it should not have transitive dependency

Transitive dependency: when attribute in the table depend on some non-primary attribute and not
on the primary key attribute. So, we must remove transitive dependency from our table.
NB [2] - Our tables already don’t have any transitive dependency, since the we don’t need to
normalize it to third normal form

4. Fourth Normal Form

73
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
There must not be multivalued dependency to do fourth normal form. But our tables are already
normalized to forth normal form.

Chapter 5: Conclusion and Recommendation

5.1. Conclusion

Building rental management system plays a crucial role in the effective operation of modern
building rentals. It provides building owners and managers with a comprehensive solution for
managing tenant information, maintenance requests, rent collection, and financial reporting. With
the integration of advanced technologies, building rental management systems are able to
streamline building operations, improve communication between tenants and building
management, and enhance overall efficiency.
The implementation of a building rental management system can result in significant benefits,
including reduced workload for building managers, increased transparency and accountability, and
improved tenant satisfaction.
In conclusion, building rental management systems offer a comprehensive solution for managing
modern building rentals, providing building owners and managers with improved efficiency,
increased transparency, and enhanced tenant satisfaction. With careful consideration and the right
choice of system, building rental management systems can provide a valuable investment for
building owners and managers.

5.2. Recommendation

Our project is meant to satisfy the needs of rental Building owners and potential tenants. Several
user friendly interfaces will also be adopted. We will present this software hoping that it will solve
problems and encourage everyone to continue appreciating technology because it is meant to
change and ease all our work that seems to be very difficult.
We encourage anyone who has the ability and willingness to advance our system:
 To include also apartments, villas and any kind of construction additional to just building
units.

74
 LUCY BUILDING RENTAL MANAGEMENT SYSTEM PROJECT
DOCUMENTATION
 To use Ethiopian owned payment system.
 To also focus on sales additional to rent.
 And also to use advanced technologies so as to increase its capabilities.

References
[1] https://www.facilitiesnet.com/buildingoperations/
[2] https://www.bomahut.com/
[3] https://www.ifma.org/resources/facility-management-resources/building-automation-
controls/
[4] https://www.marketsandmarkets.com/Market-Reports/building-management-system-market-
1588.html/
[5] https://www.johnsoncontrols.com/buildings/building-management-systems/
[6] https://ethiorealestate.net/index.html
[7] https://www.sourcecodester.com/blog/14107/rental-house-management-system-thesis-
documentation-chapter-five.html
[8] https://www.google.com/amp/s/www.lovelycoding.org/rental-building-management-
system/amp/

75