You are on page 1of 52

INSTITUTE OF TECHNOLOGY SCHOOL

OF
INFORMATICS
DEPARTEMENT OF COUMPUTER SCIENCE

PROJECT DOCUMENTATION ON
GPS BASED
HOUSE RENT MANAGEMENT SYSTEM

GROUP MEMBERS
NAMEID
MISGANAW AMBAYE CS/0137/09
TADESSE ABEBE CS/0177/09
ZIGJU MEZGEBU CS/0216/09
HANA ENDASHAW CS/0106/08
BEKTU ABDELA CS/0031/09

Title: GPS BASED HOUSE RENTAL MANAGEMENT SYSTEM

ADVISER: Mr. YITBAREK ZEWDE


SUBMITTED TO: DAWIT
DATE OF SUBMISSION :15/11/2019

1|Page
Table of contents
1.Introduction
……………………………………………………………………………………………3
2.backroud of the
study………………………………………………………………………………..3
3.stetment of problem and its
justification………………………………………………………………3
4.objective of the project
………………………………………………….…………………………..4
4.1 general objective
……………………………………………………….………………………..4
4.2 specific objective
………………………………………………………………..…………….4
5. scope and limitation of the project…………………………..…………………………..5
5.1 scope ………………………………………………………………………….5
5.2 limitation………………………………………………………………..…….6
6.methodology the project…………………………………………………………….…….6
6.1 Data Gathering Tools…………………………………………………………..6
6.1.1 Primary data collection…………………………………………..………6
6.1.1.1 Interview………………………………………………………..….6

6.1.1.2 Observation…………………………………………………….….7
6.1.2 Secondary data collection………………………………………..….….7

6.1.2.1 Document analysis……………………………………………….7


6.2 Design Methodology…………………………………………………….……..7
6.3 Development Methodology…………………………………………………….8
6.4 Implementation Methodology………………………………………………….8
6.5 Hardware Requirements………………………………………………….…….8
6.6 Software Requirements………………………………………………………….8
6.7 Testing methodology……………………………………………………………..9
7 significance/benefits of the project…………………………..………………………....9
8 budget schedule.……………………………………………………..………….…….....10
9 time schedule …………………………………………………………..………………10

2|Page
ABSTRACT
We are stuck with technology when what we really want is just stuff that works. With the
current paradigm shift in technological field, there is an urgent need to embrace and
appreciate the power of technology. Housing sector remains vigilant to face the challenges of
change by employing a new strategy that facilitates easy management of houses rental. Hence
there is need to develop a house rental system that can simplify work for the rental managers
so that all their work can be efficient and effective. To get information about how house rental
is currently being managed, we prepared questions and ask them to a number of house rental
managers, Employees 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, I decided to develop a house
rental system that can solve all the problems experienced with the current manual system. The
system was developed in such manner that it provides maximum user-friendly interface. Once
you the user logs in the system automatically show the forms. Each form has several command
buttons; new, save, cancel, delete, next, previous and exit. With the command Buttons you can
manipulate the database.

Acknowledgment
At the beginning we are very much grateful to almighty God for giving us
strength and opportunity and sound mind to complete the house rental
management project we want to bid our heartiest thanks to my advisor Mr.
Yitbarek for guiding and giving us the opportunity to imitate this report. Then we
want to thank.
1. INTRODUCTION THE PROJECT
House rental is one of the most popular actions taken by most people in this real world. This is
the reason why, now a day’s people move from place to place, city to city and country to country
for different purposes and they may have to stay there for limited and unlimited time.
2. BACKGROUND OF THE STUDY
House is one of the basic needs for human being. From the four needs of human beings as its
needed people who have no house may live through paying rent for other people who have more
houses. But here what we have to understand is that the relation between the person who rented
house and the renter how they make the process of renting. The new web -based application is
very important for both customer and for private owner’s by solving complex data recording and
data storing system problems with respect to the houses location, since the new system is very
flexible, easy and user-friendly web application to use related with house rental process for the
customer

3|Page
3. STATEMENT OF THE PROBLEM & ITS JUSTIFICATION
➢ Manpower wastage: - manually customers lose their energy by finding house from place to
place even they cannot get house because most of houses are reserved and they cannot know
where they can get free house exactly.
➢ Wastage of time: - lose their time by searching houses in different places. This is difficult
for new customers because they may miss their work time. The office manager loss his time
to register each customer. Office employees and private owners also loss their time to show
the house and services for new customers.
➢ Wastage of money: -the person who wants to rent the house waste their money for
coordinators payment and for taxi in order to go the office and private owners pay for
coordinators to advertise their house.
➢ Coordinators or brokers false information: -coordinators give uncertain information for
the customer when he/she will find the house with coordinators. So, the client did not get the
house as he/she expect.
➢ Redundancy: - There is redundancy in renting new houses manually. Coordinators or
brokers may take payment from different peoples and they will give the house for the one
who gives more money for them this leads to conflict among them.
➢ Difficult reporting mechanism: -It is difficult to generate report about customers and the
number of houses which is rented.
➢ Difficult to manage the house: - This is time killer and tedious to manage each house for
the private owners.
➢ Prone to error: - Since human being’s does manual systems, it is tolerable or prone to
error.
➢ Files are not secure: -There is no authentication mechanism to secure the files. There for
files are easily accessible by anyone. So, data security is not assured. That is, data is
recorded on books/papers which may easily get damaged leading to loss of data.
➢ Data growth:
Data increase day to day. Storing and maintaining all datamanually is very difficult

➢ There is no database to store information


Potential of data loss or damage is very high because data is stored on tangible files

4. OBJECTIVES OF THE PROJECT

4|Page
4.1General Objective:
The general objective of the system is to develop a gps-based house rental system for Ethiopia

4.2 Specific Objectives:


To achieve general objective of the system we used the following specific objectives.

▪ Gathering required information for proposed system by using interview, observation, and
document analysis.
▪ Analyzing the gathered information using Software Requirement Specification (SRS)
document
▪ Compare and contrast the proposed system with existing system
▪ Design a new proposed system to solve the existing problem.
▪ Specifying functional and non-functional requirements of the proposed System
▪ Design the proposed system using Unified Modeling Language (UML) diagram.
▪ Design a user interface for the proposed system
▪ Design a database for the proposed system
5. SCOPE AND LIMITATION OF THE PROJECT

5.1 Scope
The scope of the project can be described as the overall features of what the new system is
capable of doing. This system has different features, which make things easier for the client as
well as for private owners. Generally, our proposed system will support the following features.
➢ PHP Technology used for the development of the application.
➢ General customers as well as the owners will be able to use the system effectively.
➢ Web-platform means that the system will be available for access 24/7
➢ Existing Systems: This involves studying the existing systems and learning their
weakness hence developing a new system to improve for the challenges of the local and
faces when dealing with house rental issues.
➢ Support mobile device accessible
➢ The system enables the new customer to reach the housing center without doubt through
GPS locator

5|Page
5.2 Limitation of the project
➢ Verification of cellphone is difficult since it requires much connection with the
telephone /ethiotelecom.
➢ Requires internet /connection access
6. METHODOLOGY OF THE PROJECT
6.1 Data Gathering Tools
Software development begins with a certain human need, which can be taken as a problem. We
stated the statement of problem above then we develop complete understanding on the topic.
Next, we had some idea to solve the problems and then we formalize and change our idea to
reality by producing software. This will be achieved by software development, which involves
eliciting system requirements specification, system design, system implementation and finally
system testing. In other words, we also had to follow methodologies used in software
engineering
There are several fact-finding techniques or methods involved in system analysis phase. That we
will use them. Throughout the system development life cycle.
6.1.1Primary data collection
In primary data collection, we collect the data by the following methods, such as interviews and
observation.

6.1.1.1 Interview
We have conducted interview about the current situation from the customer and the office
Manager and private owners face-to-face by asking questions prepared by the team. We have
asked the following basic questions:
Q.1 How do you register your customers?
Q.2 How many numbers of governmental /private owned houses are rented?
Q.3 How customers reserve house?
Q.4 How to determine the price of each house?
In addition, the answers given by the owner and the customer are:

These observations had given us an extraordinary data towards developing our problem
statement and objectives. The working environment is bad lack of good customer service. From
the requirement gathering, we get what the current system look like, how the current system
works and the drawback of current system from the fact-finding methods we conclude the
current system follow manual system and works are done on a paper form so we can see this
system create conflict between employees.

6|Page
Generally, the following results are found while gathering requirements regarding the problem of
the current house rental system.

▪ The office manager said that since the number of customers is becoming large from day
to day it is difficult to register, allocate and manage the rented houses for each
registered customer
▪ Customers said, “We are losing time to wait in the office until they become registered
or a lot of time is wasted to find a house for rent by asking the house owner”. They also
lost a lot of money for taxi to go to the office or by paying a lot of money for brokers to
show a free house.
▪ Private owners said, “We are losing a lot of money by paying for brokers in order to
advertise their own house”. A lot of time is wasted to show the house properties for
customers.

These results are used to identify the functionalities of our proposed system.

6.1.1.2 Observation
It allows as watching a person perform activities to learn about the current situation or System.
This is using full when the validity of date collection is in question or when the Complexity of
certain aspect of the system prevents a clear explanation by the system.
6.1.2 Secondary data collection
From secondary data collection method, we have used document analysis.

6.1.2.1 Document analysis


6.2 Design Methodology
We prefer Object Oriented softwareengineering (OOSE) methodology and incremental model to
develop our system. This is because an OOSE) provides the following advantages
▪ Promotes better understanding of user requirements.
▪ Leads to clear design by using use case, activity diagrams and sequence diagrams.
▪ Allows to breakdown-complicated systems into smaller, clearly defined and more
manageable parts.
▪ Easy maintenance.
▪ Enables the standardization of objects which increases design understanding and
decreases the risk associated with project development.

7|Page
6.3 Development Methodology
We have chosen incremental methodology, which includes requirement analysis, system design,
implementation and unit testing, integration and system testing and deployment. We have chosen
this methodology as the problem is well known and organized. In this methodology, the
customer requirements should be fully analyzed and the system should be designed. Therefore, it
is easy to implement the system.
6.4 Implementation Methodology
To implement our proposed system, the following hardware and software tools are required:
6.5 Hardware Requirements
➢ Hard disk: above 4GB
➢ Processor: Pentium 3 with greater than 1.8GHz processing capability
➢ Memory: greater than 4GB RAM
6.6Software Requirements
✓ Operating System: Windows 7 and above.
✓ Language: PHP
✓ Database server: MySQL
✓ Wamp Server:
✓ Documentation: Microsoft word
✓ Web Browser: Current available browser
✓ Styling: CSS
✓ GPS: location indicator
✓ Google map
✓ UML:visual paradigm
6.7Testing methodology
Once the system is implemented, the system testing will be followed to identify errors and other
defects within the system. The testing methodologies used are:
Unit testing: testing each module later to be integrated to form the system.
Integration testing: testing the integrated software after integrating all programs and
checks whether the integrated program meets all the functional requirements.
System testing: testing end application done by:
➢ Alpha testing: - In this testing method, the system will be tested by giving the
correct input. A customer at the developer site will test it.

8|Page
➢ Beta testing: -In this testing method, team will force the system to be tested for
incorrect data input. The customer at their actual work place will test the system.
7. SIGNIFICANCE/BENEFITS OF THE PROJECT
After implementing our proposed system provides many advantages for customers, private
owners. The main significance of the project includes:
➢ Customers will reserve house by selecting the place, type of house and the cost they
can pay by viewing all recorded house details
➢ Houses can become available to customers within the time of they want to rent
Minimizes money, time, and other unnecessary wastages.
➢ The system is more secured than existing one so file cannot be lost easily
➢ It increases performance of the system.
➢ Decrease the difficulties of customer in searching houses
➢ Makes the system user friendly
➢ Motivate the people to use online system
➢ Provide knowledge and internet service for the people
➢ Easy and manageable report

8. Feasibility Study

9.1 Technical Feasibility


The technical issues that are involved in the system such as the normality and strength of the
owners and the customers mobile device from the hardware part, the software should work
properly in the proper inputs from its users both user and the software point of view should be
considered to determine the feasibility. Additionally, in simple terms long range portable mobile
device required for the betterment of the application usage.so that GPS based online house rent
management system is intended to be developed in the existing technology to be easily usable by
the user.

8.2 Operational Feasibility


This system is operational feasible because it is initially proposed to be designed to professional
user. The users are professional and known with the technologies and hence there is no need to
come up the user specially customer too much to see the rental service system. The user should

9|Page
not misuse the system. The application is expected to be very flexible for its users. The system
will satisfy the user by simply accessing it via a mobile device. And this is also one of the factors
that make it operationally feasible.

8.3 Economical Feasibility


The proposed system is going to be economically feasible in such a way that, since the system
will be developed for house rental so that customers and owners can afford to have smart phones
and also to install this system and consume less money and time for clients to get best house to
be rented as well as the owners to manage rental process .In addition to this implementing this
system brings several other purposes. Such as the reduction of stationary material cost that used
for manual record in rental organizations. The reduction of cost paid for printing forms that is
used for recording information. Save the money that used to buy shelf. Knowledge gain by
project developer. More timely and accurate information processing of the user. Give effective
house rental managing service for the owner as well as the customer. Facilitating information
processing of users.

8. BUDGET SCHEDULE
ITEM COSTS
HARDWARE
Laptop computer 15,500birr
Flash disk 350birr
SOFTWARE free
Microsoft windows 7 operating system free
Microsoft office word 2016 free
Microsoft office access 2016 free
Visual basic studio free
OTHER COSTS
Printing 10birr
total 16210

9.TIME SCHEDULE

ACTIVITY DATES DURATION


Project proposal 10th Nov -15th Nov 5 days
Requirement analysis 16th Nov-30th Nov 2 weeks

10 | P a g e
design 1th Jan-30th Jan 4 weeks
Coding and testing 1th Feb-1th Jun 16weeks
Evaluation 2th Jun-9th Jun 1weeks

.TIMESCHEDULE
Id Tasks Start finish Duration Nov Dec Jan Feb Mar April May Jun
10
1 Project 10/11/19 15/11/19 5days
Proposal
2 Requirements 16/11/19 30/11/16 15days
Analysis
3 Design 1/1/20 30/1/20 1month

5 Testing and 2/2/20 2/6/20 4months


coding

6 Evaluation 2/6/20 9/620 7days

Chapter Two: DESCRIPTON OF THE EXISTING SYSTEM


2.1 Introduction of the Existing System
The existing system works as we said in statement of problems manually that means that
the customers that rent the house is manually register in a paper without any recovery
mechanism and this papers are easily movable by peoples, other peoples may use this
paper to register their information’s so may be data loss in case of movement.
The existing system is mainly works using blockers and some helper people to get the
rented house this means that the blockers and the house founders are gather the
information’s related to the house that is rented by the private owner and after gathering
the information’s from the private owner they notify to the customers that are wanted to
rent the house .the customer rents the house by performing fees to the blocker.
The blockers find the rented house location by searching and asking the peoples near to
or around the rented house.
Finally the existing system works both by blockers and manually by registering by paper
of their customers.

11 | P a g e
The office requires significant volume of paper work to manage the habits for those
recorded information’s.
2.2 Description of the Proposed System
House rental management system is designed to provide fast and easy way of controlling all the
activities of house renting. Taking this into account the problems of the existing system, we have
proposed a gps web-based application system. Our proposed system provides an easy way for
customers to check available house’s for renting. And allow private owners to manage all
customers and house related files. This includes posting new happenings, deleting, updating and
posting houses. The system also provides an easy way for private owner to see customer’s
request on the web and sending their response to the customer. Generally, house rental
management system is concerned on managing house’s, providing easy and understandable way
of controlling the activities of house renting, and making easy and fast of communication held
between customer, employee and private owner. The major solutions to address the problems of
the existing system are as follows. Better utilization of resources, performance, security,
reliability, accuracy and in general better service and the new system is aimed to perform basic
and crucial tasks of the organization. It contains a well-organized database server which makes
data to retrieve, update easily.

2.3 Strength of the Existing System


The main opportunity of the current manual House Rental Management System provides job
opportunity for many employees. The existing system works offline, which mean the
organization can perform tasks without internet. Solve problems between the customer and the
office.

2.4 Weakness of the Existing System

The main limitations in the current manually house rental management systems are human &
natural disasters like fire, theft. If the document is lost, it is hard to find such information. Lack
of data integration and consistency. The organization requires much effort, time and tasks are not
completed within time. High budget constraint.
Chapter Three: SYSTEM FEATURE

3.2 Requirement specification

12 | P a g e
User Requirements
It entailed user involvement and statements of facts and assumptions that define the expectations
of the system in terms of mission objectives, environment, constraints and measures of
effectiveness and suitability. Basically, the users:
➢ A system that improves on the efficiency of information storage and retrieval.
➢ A system that is easy to learn and use
➢ A system that is fast in processing transactions
➢ A system that is flexible, safe and convenient
➢ 3.3 Functional Requirements
This is a necessary task, action or activity that was accomplished by the system directly.
➢ Functions of the system

• Allow owner to add a houses, tenant and customers details


• Allow the owner to delete houses, tenants and customers details
• Allow the owner to search data in the database
• Allow the owner to edit data in the database
• Graphical User interface with the User.
➢ Functions of Customer
• Login Request
• Registration Confirmation by the System
• Reserve House
• House Issued by the System
• Email received for Reserved House.
➢ Functions of private owner:
• Register in to the system
• Add Customers/Tenants/.
• Send E-Mails for Reserved House
• Post rent Houses
• Post a New house
• Send House Confirmation to System

13 | P a g e
Software Requirements

For developing the application, the following are the Software Requirements:

➢ Website development tools

Operating Systems supported

➢ Windows 10

Technologies and Languages used to Develop

➢ PHP

➢ HTML

➢ JavaScript

For running the application, the following are the Software Requirements:

✓ Operating System

Hardware Requirements

For developing the application, the following are the Hardware Requirements:

✓ Processor: Pentium IV or higher


✓ RAM: 256 MB
✓ Space on Hard Disk: minimum 512MB

3.4 Non-functional requirement


Nonfunctional requirement is a requirement that describes about how the system performs the
functional requirements. It describes performance, maintainability, accessibility, usability,
portability, availability, accuracy, and reliability of the proposed system.

14 | P a g e
➢ Performance and Response time: - The system should have high performance rate
when executing user is input and should be able to provide feedback or response
within a short time span. And also, the new system minimizes the work load of the
customer and also it minimizes wastage of time by facilitate services in
understandable way and also its effectiveness is better because the newly developed
system helps users to access the information and register or reserve at a time in
anywhere. Many users estimated in this system can access at the same time
➢ Portability: It can be run across different operating system
➢ Accessibility: The system can be accessible based on the accessible privilege or based
on authorization.
➢ Availability: -This system should always be available for access at 24 hours, 7 days a
week unless in the occurrence of any major system malfunctioning, the system should
be available in all working days, so that the business process is not severely affected.
➢ Error handling:
- Error should be considerably minimized and an appropriate error message that
guides the user to recover from an error should be provided. Validation of user’s input
is highly essential. In addition, the standard time taken to recover from an error
should be minimized.
➢ Accuracy: proposed system reduces error because all operation can be check
correctly and validate that whatever information is coming from the database and
input to the database.
➢ Maintenance: our system can be easy maintainable and updateable, if the system gets
any failure.
3.5 Analysis model
3.5.1 Use case Model
In this section, we are going to see use case diagram, description of use case diagram. This helps
to know the functional interaction between user and the system. Use cases are drawn by
examining the actors and defining what the actor will be able to do with the system.

3.5.2 Actor Specification

Actors: An actor represents a type of users of the system that the system interacts

15 | P a g e
with. An actor is a user of the system playing a particular role.

Use cases: A use case describes the sequence of events of some types of users,
called Actors, using some part of the system functionality to complete a process.
An actor initiates a use case and receives something of value from the use
case. Actors are always external to the system being modeled i.e. they are not
parts of the system.

We identified the following actors.


Customer: allows browsing, comparing preview / managing agreement, view
agreement expiry.
Owner: allows posting their house, managing house information, viewing agreement expiry

16 | P a g e
Fig 1. Use case diagram for gps based house rental management system

3.1. Description of use case model


Table 1.login use case description

Use case name Login

17 | P a g e
Actors Customer, Private Owner

Description The Customer, Private uses this form to log into the system.

Pre-condition The Customer, Private Owner should be register first or need to have an
account to login.

Basic flow of 1. The customer, Private Ownerenter to the home page


event 2. system displays login form
3. Enter user name and password and click login button
4. The system checks for the validity of the user name and password
5. The system displays the customer, Private Owner page.
6. Use case Exit

Alternate A1 If the entered user name and password is not valid it displays “please enter
course of valid user name and password” go to basic flow 2.
action
B2 If the user forgot the user name and password display reset user name and
password page.

Post condition The users (Customer, Private Owner) logged in to the main page.

18 | P a g e
Table 2 Register house use case description

Use case Register House


Actor Private Owner
Description This use case permits to register rental information of the Private Owner
and the house that they register
Pre-condition Login
Flow of event 1: This use case is initiated when the actors click on register houses
option.
2: System displays the page that contains information to will be
registered.
3: Private Own fill all the information
4: Private Owner click or press on the save or Register button.
5: The system verifies that fields have been filled out correctly.
6: The system displays inserted successfully message.
7: Use case Exit
Alternate A1 If property owner’s fields are not filled out correctly system goes back
course of action or returns to step 3 of basic course of Action. To fill invalid field.
Post-condition Private Owner information is registered.

Table 3 use case description for delete house

Use case Delete house information

19 | P a g e
Actor Private Owner
Description Only Private Owner delete their own house
Pre-condition Private Owner need to have an account to manage
Flow of event 1: This use case is initiated when Private Owner click on manage delete
house option.
2: System displays the page that contains delete buttons.
3: Private Owner deletes resources.
4: System displays deleted successfully if Private Owner delete house
information.
5. Use case Exit
Post-condition Private Owner want to manage resources

Table 4.use case description for send request

Use case Send request

20 | P a g e
Actor Customer
Description This use case permits to register rental information of the customers
and the house that the customers rent.
Pre- Login
condition
Flow of 1: This use case is initiated when the actor’s clicks on send request .
event option.
2: System displays the page that contains information to be
registered
3: Actors fill all the information
4: customer clicks or press on the
Save or insert button.
5: The system verifies that the fields have been filled out correctly.
6: System displays send successfully.
7: Use case Exit

Alternate A1 If the customers fields are not filled out correctly system goes back
course of or returns to step 4 of basic course of Action to fill valid data.
action
Post- Customer’s information is registered.
condition

Table 5 search house use case description

21 | P a g e
Use case Search house
Actor Customer
Description When actors choose search house option, the system displays all available
houses.

Pre-condition User need to have an account if they want to see more house information.
Flow of event 1: This use case is initiated when the actors click on search house
option.
2: System displays available name of the Private Owners and some
information of the house.
3: customer click on search house option
4: System displays all the available houses recorded in the database.
5: Use case Exit
Post-condition Customer wants to know if house information is reserved or not.

Table 6 send response use case description

Use case Send response

22 | P a g e
Actor Private Owner

Description When Private Owner choose view Customer request option, the system
displays information about who is requested

Pre-condition Owner is already logged in

Flow of events 1. The Private Owner click view request button.


2. System display text area box and request button.
3. private owner fills necessary notification and click request button to
send it.
4. The system will display send successfully message.
5. Use case Exit

Post condition Response is sent to the Customer

Table 7 Update house use case description

Use case Update house

23 | P a g e
Actor Private Owner
Description Only Private Owner can update Their own house information.

Pre-condition Private Owner need to have an account to modify the property


Flow of event 1: This use case is initiated when Private Owner click on house
information option.
2: System displays the page that contains update buttons.
3: Private Owner updates resources.
4: System displays update successfully.
5. Use case Exit

Post-condition Private Owner want to modify house information

Table 8 logout use case description

Use case name Logout

Participating Customer and Private Owner


actors:

Pre- Condition: Customer and Private Owner should be logged in

Description: To Exit from services.

Flow of action: Customer and Private Owner clicks on logout button.

24 | P a g e
Table 9 Register account use case description

Use case Name: Register account

Actors: Customer and Private Owner

Description: Customer insert his/her Details information in to the system or


Private Owner inserts all detail information of houses

Precondition: Customer Private Owner must be accessing the webpage

System action User action

1) System give menu bar 2) Customer and Private


Owner click on register
Flow of event: 3) System display registration form
4) Customer and Private
6) Systems validate the user input
Owner fills the form
and unfilled input
5) Customer and Private
7) Use case Exit
Owner clicks the submit
button.

Post condition: Successfully register

Alternative flow of A1) If the fill form is invalid system display the register form
again
event

25 | P a g e
Table 10 use case description for manage account

Use case Name: Manage account

Description: private owner and customer can create, delete, change


user name and password

Actors: Private Owner and customer can involve

Precondition: Private Owner and customer can must be log in to the


system

System Action User action

Main course of 1)System display menu option 2) Private Owner


action: and customer can
3)System display detail data of
click on account
customer

5) Systems validate the user input 4) Private Owner,


and customer can fill
and unfilled input
manage account
6) Use case Exit
form.

6) Private Owner,
and customer can
click on submit
button

Post condition Successfully check its own accounts

Alternative flow of A1) If the fill form is invalid system display the form
again
event .

Table 11. use case description for post house


Use case name Post house

26 | P a g e
Participating Private Owner
actors:

Pre- Condition: Private Owner should be logged in

Description: Private owner should be posting the house info in detail.

Flow of action: 1.Private Owner clicks the button of login

2.login into the system

3. posts the rent house

4.uplode it to the system

Post condition Successfully post the house information

Table 12. use case description for Manage customer

27 | P a g e
Use case name Manage customer

Participating Private Owner


actors:

Pre- Condition: The private owner login into the system.

Description: The private owner should bemanaging the information related to


the customer

Flow of action: 1.Private Owner should be logged in.

2.private owner should be managed the customer after login.

Post condition The private owner mange the customer

Table 13. use case description for View notifications


Use case name View notifications

Participating Customer
actors:

Pre- Condition: Customer should be logged in

Description: View the information or news related to whether the owner


upload the information of the house

Flow of action: 1.Customer clicks on login button.

2.if the private owner uploads the house the customer sees the
information

3.the customer rents the house

Post condition Successfully views the house that is rented to

Table 14. use case description for reserve house

28 | P a g e
Use case name Reserve house

Participating Private Owner, customer


actors:

Pre- Condition: Private Owner and customer should be logged in

Description: Private owner should be reserve house for the customer in order
of time of request to rent the house.

The customer reserve the house as he/she leaves the house when
he finishes the time of rent.

Flow of action: 1.Private Owner and customer clicks the button of login

2.login into the system

3. private owner and customer clicks the reserve house option.

4.the customer notifies the private owner that he leaves the


house.

5.the private owner reserves house based on the queue of


request.

Post condition Successfully reserve the house in both actors

3.2 Sequence Diagram


Sequence diagrams describe interactions among classes in terms of an exchange of messages
over time. They are also called event diagrams. A sequence diagram is a good way to visualize
and validate various runtime scenarios. These can help to predict how a system will behave and
to discover responsibilities a class may need to have in the process of modeling a new
system.UML sequence diagrams model the flow of logic within our system in a visual manner,
enabling you both to document, validate your logic, are commonly used for both analysis, and
design purposes. Sequence diagrams are the most popular UML artifact for dynamic modeling,
which focuses on identifying the behavior within your system. `

29 | P a g e
Fig 1 Sequence diagram for login

Fig 2 Sequence diagram for register account

30 | P a g e
Fig 3 Sequence diagram for post house

31 | P a g e
Fig 4 Sequence diagram for search house

Fig 5 Sequence diagram for view request


32 | P a g e
Fig 6 Sequence diagram for manage account

Fig 7 Sequence diagram for update house information

33 | P a g e
Fig 8 Sequence diagram for register house

34 | P a g e
35 | P a g e
Fig 9 Sequence diagram for send response

Fig 10 Sequence diagram for Delete house

36 | P a g e
37 | P a g e
Fig 11 Sequence diagram for create account

Fig 12 Sequence diagram for logout

38 | P a g e
Activity diagram

39 | P a g e
Activity diagram is another important diagram in UML to describe dynamic aspects of the
system. Activity diagram is basically a flow chart to represent the flow of information one
activity to another activity.

Fig 13 Activity diagram for login

40 | P a g e
41 | P a g e
Fig 14 Activity diagram delete house information

42 | P a g e
Fig 15 Activity diagram for register house info

43 | P a g e
Fig 16 Activity diagram for view notification

Activity diagram for managing house info

44 | P a g e
Fig 17 Activity diagram for managing house info

45 | P a g e
Fig 18 Activity diagram for send response house

46 | P a g e
Fig 19 activity diagram for reserve house

47 | P a g e
Fig 20 Activity diagram for register account

48 | P a g e
fig 21 Activity diagram for logout

49 | P a g e
Class Diagram
UML class diagrams show the classes of the system, their interrelationships (including
inheritance, aggregation, and association) and the operations and attributes of the classes. Class
diagrams are used for a wide variety of purposes, including both conceptual domain modeling
and detailed design modeling. A class model is comprised of one or more class diagrams and the
supporting specifications that describe model elements including classes, relationships between
classes, and interfaces. UML class diagrams show the classes of the system, their inter-
relationships, and the operations and attributes of the classes.

Analysis level class diagram

50 | P a g e
Diagram 1 E-R diagram for HRMS

CHAPTER FOUR

System Design

In this chapter, we are going to describe the architectural design of the proposed system. In
addition to this, we will describe the access control and security of our system. The overall

51 | P a g e
system design objective is to give an efficient, modular design that will reduce the system
complexity, facilitate change and leads to an easy implementation.

4.1. Design Goal


Design goals describe the important system qualities. Design goals also define the values against
which options are evaluated. When designing a new system, a system designer creates a model
of the system from requirements made. The quality of the model highly determines the quality of
the product and future maintainability.

Design goals: -

▪ Response time: Our proposed system will take less time to respond to any request by a
user.
▪ Simplicity: The user interface of the proposed system will be easy to use by each user of
the system, as the system is going to use a user-friendly graphical user interface.

▪ Reliability: the system must perform its intended functions and operations in a system's
environment. Without experiencing failure or system crash.

▪ Security: the new proposed systemwill be protected from an authorized access, threats,
attacks and vulnerabilities.

▪ Fault tolerance: Our proposed system will have the ability to satisfy requirements despite
failures such as hardware, software or network we will maintain a regular backup.

52 | P a g e

You might also like