2024

House Rental and Seller

Addis Ababa Institute of Technology
School of Information Technology and Engineering
Department of IT/SE Eng.

Software Requirements Specification

Team Members ID.NO Section

Abigiya Daniel UGR/5110/15 4

Alpha Degago UGR/4592/15 3

Ashenafi Godana UGR/7906/14 4

Ephraim Debel UGR/0640/15 4

Jiru Gutema UGR/5902/15 4

Advisors: Aderaw
.
 Date: Nov
7, 2024

Revision History

Date Description Author Comments

Nov <Version 1> <all <First Revision>

7,2024 members>

Document Approval

The following Software Requirements Specification has been accepted and approved
by the following:

Signature Printed Name Title Date

Table of Contents
DOCUMENT APPROVAL........................................................................................................................... II
LIST OF TABLES...................................................................................................................................... IV
LIST OF FIGURES...................................................................................................................................... V
DEFINITIONS, ACRONYMS, AND ABBREVIATIONS.............................................................................VI
DECLARATION........................................................................................................................................ VII
1. INTRODUCTION..................................................................................................................................... 1
1.1 PURPOSE............................................................................................................................................ 1
1.2 SCOPE................................................................................................................................................ 2
1.3 OVERVIEW.......................................................................................................................................... 3
2. GENERAL DESCRIPTION...................................................................................................................... 4
2.1 PRODUCT PERSPECTIVE...................................................................................................................... 4
2.2 PRODUCT FUNCTIONS.......................................................................................................................... 5
2.3 USER CHARACTERISTICS..................................................................................................................... 5
2.4 GENERAL CONSTRAINTS...................................................................................................................... 6
3. SPECIFIC REQUIREMENTS.................................................................................................................. 7
3.1 EXTERNAL INTERFACE REQUIREMENTS................................................................................................. 7
3.1.1 User Interfaces.......................................................................................................................... 7
3.1.2 Hardware Interfaces................................................................................................................... 8
3.1.3 Software Interfaces.................................................................................................................... 8
3.1.4 Communications Interfaces....................................................................................................... 8
3.2 Functional Requirements.............................................................................................................. 9
3.2.1User registration and Authentication........................................................................................... 9
3.2.2 property listing........................................................................................................................... 9
3.2.3search and filter properties......................................................................................................... 9
3.3 USE CASES....................................................................................................................................... 10
3.4 NON-FUNCTIONAL REQUIREMENTS..................................................................................................... 16
3.4.1 Performance............................................................................................................................ 16
3.4.2 Reliability................................................................................................................................. 16
3.4.3 Availability................................................................................................................................ 17
3.4.4 Security.................................................................................................................................... 17
3.4.5 Maintainability.......................................................................................................................... 17
3.4.6 Portability................................................................................................................................. 17
3.5 INVERSE REQUIREMENTS................................................................................................................... 17
3.6 DESIGN CONSTRAINTS....................................................................................................................... 17
3.7 LOGICAL DATABASE REQUIREMENTS.................................................................................................. 17
3.8 OTHER REQUIREMENTS..................................................................................................................... 17
4. CHANGE MANAGEMENT PROCESS.................................................................................................. 18
REFERENCES.......................................................................................................................................... 21
A. APPENDICES....................................................................................................................................... 22
Definitions, Acronyms, and Abbreviations

This section provides definitions of terms, acronyms, and abbreviations used within this
Software Requirements Specification (SRS) document. These definitions are intended
to ensure clarity and consistency in the interpretation of the requirements.

1. Definitions

● Software Requirements Specification (SRS): A comprehensive document that

defines the requirements, expectations, design, and standards for a software
product.
● Stakeholder: Any person or group that has an interest in the software product
and its requirements, including customers, end users, project managers, and
developers.
● Change Control Board (CCB): A group of project stakeholders who review,
evaluate, and approve or reject changes to project requirements and scope.
● Requirement: A detailed and testable statement describing a specific capability
or behavior that the software product must exhibit.

2. Acronyms

ADA: Americans with Disabilities Act

API: Application Programming Interface

CCB: Change Control Board

DBMS: Database Management System

FAQ: Frequently Asked Questions

GUI: Graphical User Interface

IEEE: Institute of Electrical and Electronics Engineers

JIRA: A project management and issue tracking tool by Atlassian

JWT: JSON Web Token

ODBC: Open Database Connectivity

QA: Quality Assurance

RFC: Request for Comments

SQL: Structured Query Language

UI: User Interface

3. Abbreviations
 ● v: Version (e.g., v1.0, v2.0)
● SRS: Software Requirements Specification
● QA: Quality Assurance
● DB: Database

DECLARATION
We declare that this written submission represents our ideas in our own words and
where others’ ideas or words have been included. We have adequately cited and
referenced the original sources. We also declare that we have adhered to all principles
of academic honesty and integrity and have not misrepresented or fabricated or falsified
any idea/data/fact/source in our submission. We understand that any violation of the
above will be cause for disciplinary action by the Institute and can also evoke penal
action from the sources which have thus not been properly cited or from whom proper
permission has not been taken when needed.
1. Introduction
This Software Requirements Specification (SRS) document outlines the functional and
non functional requirements for the property rental and sales platform designed for the
Addis Ababa housing market. The purpose of this document is to provide a detailed
description of the software system to be developed, including its functionalities,
constraints, and interactions with users and other systems. This document serves as a
comprehensive guide for developers, designers, testers, and other stakeholders,
ensuring that the system meets the objectives set forth by the business and end-users.

The platform will facilitate the interaction between tenants and landlords, allowing for
seamless property listing, search, communication, booking. Additionally, the system will
include features such as user authentication, feedback, and rating systems, and
advanced search filters for enhanced user experience. This SRS document is intended
to provide a clear, precise, and detailed description of the software system, enabling all
stakeholders to understand the scope, requirements, and expectations of the project.

The primary goal of this software is to address the housing challenges in Addis Ababa
by providing a centralized, user-friendly platform for property rentals and sales. The
system will be designed with performance, security, scalability, and ease of use in mind.
This document defines the scope, requirements, and objectives necessary to develop
and deploy the system successfully. Furthermore, it will guide the design and
implementation phases, ensuring that the final product aligns with the needs of both
tenants and landlords while providing a reliable and secure platform for all users.

The following sections will cover detailed functional and non-functional requirements,
system architecture, user roles and permissions, data management, security measures,
and testing plans, ensuring that the project is executed efficiently and meets its intended
goals.

1.1 Purpose

The purpose of this Software Requirements Specification (SRS) document is to define

the requirements for the property rental and sales platform that will be developed to
address housing needs in Addis Ababa. This document is intended to provide a detailed
and clear description of the functionalities, user interactions, and technical requirements
needed to develop, test, and deploy the software. It will serve as a blueprint for
developers, designers, and testers, ensuring that the system meets the expectations of
its stakeholders, such as tenants, landlords, and administrators.

The primary audience for this SRS includes:

School Of Information Technology and Engineering 1| Page

 ● Software Engineers and Developers: To guide the implementation of the
platform according to the defined functional and non-functional requirements.
● System Designers: To understand the system architecture and design
constraints when creating the software.
● Testers: To ensure the system adheres to the requirements during the testing
phase and meets the specified quality standards.
● Project Managers: To monitor the progress of the development and ensure all
requirements are met within the proposed timeline and budget.
● End-users (Tenants, Landlords): Though this document is primarily for the
development team, it provides insight into the system features they will interact
with.

1.2 Scope
1.2.1 Software Products

The software product to be developed is a Property Rental and Sales Platform for the
Addis Ababa housing market. This system will enable tenants to search for rental and
sales properties and communicate with landlords. Landlords can list properties, manage
inquiries, and accept or reject bookings. Administrators will have the ability to monitor
the system, moderate content, and manage user accounts.

1.2.2 What the Software Will and Will Not Do

What the software will do:

● Allow tenants to search and filter rental and sales properties based on various
parameters such as location, size, and price.
● Enable tenants to book properties and communicate with landlords directly
through the platform.
● Provide a user authentication system to protect user data and ensure only
authorized access.
● Allow landlords to manage property listings, including adding new properties,
editing existing ones, and tracking property status.
● Provide admin-level controls for managing users, moderating content, and
generating reports.
● Offer real-time notifications to users regarding booking confirmations, messages,
and property availability changes.

What the software will not do:

● The platform will not handle physical inspections or viewings of properties.

School Of Information Technology and Engineering 2| Page

1.2.3 Application of the Software

The software will serve as an online platform for property rentals and sales, aimed
primarily at tenants looking for housing and landlords offering properties. It will offer a
streamlined process for searching, listing, and booking properties, and will facilitate
communication between tenants and landlords. The main objective is to create a
transparent, efficient, and user-friendly platform that supports the real estate market in
Addis Ababa. The benefits of the software include:

● Convenience: Tenants and landlords can interact remotely, reducing the time
and effort involved in finding and managing properties.
● Transparency: Clear listings and user reviews will help foster trust in the
platform.
● Efficiency: Automation of property listing, search, and communication will speed
up the process of renting or selling properties.
● Scalability: The platform is designed to handle a growing number of users and
listings, making it scalable to meet the needs of the expanding real estate market
in Addis Ababa.

This software will be developed in line with similar projects and will aim to adhere to
industry standards for usability, security, and performance.

1.3 Overview

The remainder of the Software Requirements Specification (SRS) document is

organized into the following sections:
Section 2: Overall Description
This section provides a high-level overview of the platform, including its core
functions, user types, key user characteristics, and operating environment.
Section 3: Specific Requirements
This section describes the detailed functional and non-functional requirements for
the platform, covering specific features for tenants, landlords, and administrators.
These requirements are organized by use case to ensure clarity.
Section 4: System Architecture
This section outlines the system architecture, specifying the technologies,
components, and integration points necessary for the platform. It includes the
structure of the backend and frontend systems, database, APIs, and other
essential services.
Section 5: User Interface Design
This section provides guidelines for the design of the platform's user interfaces,
covering layout, accessibility, responsiveness, and overall user experience. It

School Of Information Technology and Engineering 3| Page

also includes mockups or wireframes to illustrate the expected look and feel of
the system.

Section 6: Testing and Validation

This section details the testing processes, methods, and tools to be used to verify
that the software meets the required quality standards. It includes functional,
usability, performance, and security testing strategies to ensure the platform
functions as intended.

Section 7: Security and Privacy Considerations

This section outlines the security measures and data privacy protocols to protect
user data and ensure compliance with relevant regulations, such as GDPR or
CCPA. Topics include authentication, data encryption, access control, and
auditing.

Section 8: Change Management

This section defines the process for updating the SRS and implementing any
required changes to the platform, including how change requests will be
submitted, reviewed, and approved.

Section 9: References
This section provides a complete list of all documents referenced in the SRS
document, including titles, report numbers, dates, and sources.

By following this structure, the SRS document aims to provide a comprehensive and
well-organized guide for developing the property rental and sales platform, ensuring that
the end product meets the needs of all stakeholders.

2. General Description

This section provides an overview of the general factors that affect the software product
and its requirements. It offers the context needed to understand the functional and non-
functional aspects of the system, without diving into specific requirements.

2.1 Product Perspective

The Property Rental and Sales Platform is designed to address the needs of tenants
and landlords in Addis Ababa, and it will be compared with other property listing and
rental platforms such as Airbnb, OLX, and Jumia. However, unlike these general
platforms, our system is tailored to the specific market dynamics of Addis Ababa,
considering local regulations, tenant needs, and the property rental process. The
system will allow landlords to list both rental and sales properties, handle inquiries, and

School Of Information Technology and Engineering 4| Page

manage their property portfolios. Tenants will be able to search for properties, book
rentals, and communicate with landlords. The platform will have an integrated admin
panel that allows administrators to moderate content and manage user data.

In terms of its architecture, the system will be a cloud-based web application that
integrates with third-party services for payment processing and messaging. The
platform will need to be scalable, flexible, and user-friendly, ensuring that tenants and
landlords can easily navigate it while meeting their needs. The system will also have the
potential to expand into mobile applications in the future.

2.2 Product Functions

The primary functions of the Property Rental and Sales Platform are as follows:

1. User Registration and Authentication: Tenants and landlords can create

accounts, sign in, and securely manage their information.
2. Property Listings: Landlords can list properties with details such as location,
size, amenities, price, and media.
3. Search and Filters: Tenants can search for properties using a variety of filters,
such as location, price, type (rental or sales), and amenities.
4. Booking and Inquiry: Tenants can request bookings or make inquiries for
properties. The system will facilitate communication between tenants and
landlords.
5. Payment Integration: The system will integrate with third-party payment
gateways to process booking fees or property purchases.
6. Messaging System: Tenants and landlords can communicate within the platform
using a messaging system to handle inquiries and bookings.
7. Admin Management: Administrators will be able to manage users (tenants,
landlords), moderate content, generate reports, and oversee the overall system
operation.
8. Feedback and Ratings: Users (both tenants and landlords) can leave feedback
and ratings after transactions to build trust in the platform.
9. Notifications: The system will notify users about booking confirmations, new
messages, or changes in property availability.

2.3 User Characteristics

The end users of the platform are tenants, landlords, and administrators. Each user type
has different needs and skill levels:

1. Tenants:

Tend to be non-technical users who may not be familiar with advanced

technology but are familiar with basic web navigation and mobile apps.

They will primarily use the platform for property searches, bookings, and
communication with landlords.

School Of Information Technology and Engineering 5| Page

 Their requirements focus on a simple, intuitive user interface that makes
searching for and booking properties easy.

2. Landlords:

Landlords may have varying levels of technical proficiency, but they need to
manage their property listings and interact with tenants.

They will need tools for uploading property images, managing property
availability, setting prices, and responding to inquiries.

A straightforward property management system with real-time notifications and

messaging is essential.

3. Administrators:

Administrators are typically more tech-savvy and will be responsible for

managing users, moderating content, and generating reports.

They will require access to more advanced tools for managing the platform,
monitoring transactions, and ensuring compliance with the platform’s policies.

All users will require access to mobile-responsive interfaces to interact with the platform
effectively across devices. The system will be designed with accessibility in mind to
cater to diverse user groups.

2.4 General Constraints

The following general constraints will affect the design and development of the system:

1. Regulatory Policies: The system must adhere to local real estate laws and data
privacy regulations (e.g., GDPR or Ethiopia’s data protection laws), ensuring that
tenant and landlord information is handled securely.
2. Hardware Limitations: The platform must be optimized to work on various
devices with different processing capabilities, including smartphones and desktop
computers. Low-bandwidth regions may also require a simplified version of the
system.
3. Interface to Other Applications: The system will integrate with third-party
applications, such as payment gateways (for processing bookings and
transactions) and email notification services. APIs and integration methods must
be clearly defined.
4. Parallel Operation: The platform must support simultaneous user access
without affecting performance, especially during peak times (e.g., when multiple
tenants are making inquiries or landlords are updating listings).
5. Security Requirements: The system will need to implement robust security
measures to protect sensitive data, including secure payment processing,

School Of Information Technology and Engineering 6| Page

 encrypted user data, and authentication methods such as two-factor
authentication.
6. Reliability: The platform should have a high uptime, with quick recovery in case
of system failures.
7. Safety and Security Considerations: Protection against unauthorized access to
user data, including sensitive information such as addresses, payment details,
and personal messages, must be a top priority.

2.5 Assumptions and Dependencies

The following assumptions and dependencies will affect the requirements of the system:

1. Availability of Third-party Payment Gateway: The platform will depend on

third-party services for payment processing (e.g., Tele-birr, M-PESA). The
system will need to support these services through well-defined APIs.
2. Operating System: The platform will be built as a web application and will be
hosted on cloud servers, with the assumption that the servers support standard
operating systems and web server environments.
3. Internet Connectivity: It is assumed that users will have access to the internet
to interact with the platform. The system will not support offline functionality.
4. Data Availability: The platform assumes that landlords will actively provide
accurate and up-to-date property listings and maintain them on the platform. If
landlords fail to update their listings, it may lead to inaccurate data being
displayed to tenants.
5. User Adoption: The system depends on tenants and landlords actively using
and engaging with the platform. Any resistance or delay in adoption could affect
the success of the platform.

3. Specific Requirements

This section contains detailed requirements for the Property Rental and Sales Platform,
ensuring the design, development, and testing teams have the necessary specifications
to implement and verify the system. Each requirement is defined to be precise,
unambiguous, complete, and verifiable, with every requirement cross-referenced to its
respective functionality.

3.1 External Interface Requirements

3.1.1 User Interfaces

1. User Interface Type: The platform will provide a graphical user interface (GUI) that
is accessible on both desktop and mobile devices.
2. User Dashboard:
● Tenants will have a dashboard to search properties, view saved
properties, manage bookings, and communicate with landlords.

School Of Information Technology and Engineering 7| Page

 ● Landlords will have a dashboard to manage property listings, view
inquiries, and handle bookings.
● Administrators will have an admin panel to manage users, properties, and
platform content.
3. Accessibility: The platform will be designed with accessibility in mind, adhering to
the Web Content Accessibility Guidelines (WCAG) to ensure usability for people
with disabilities.
4. Navigation and Layout: The platform will have a top navigation menu with sections
for "Home," "Properties," "Bookings," and "Account." Each section will provide
access to corresponding features.
5. User Feedback: Each action (such as booking or message sending) will trigger
feedback, either through visual cues (e.g., checkmarks for success) or alerts for
errors.

3.1.2 Hardware Interfaces

The platform is a cloud-hosted web application and does not interact with specific
hardware devices directly. Therefore, the system has no hardware interface
requirements.

3.1.3 Software Interfaces

1. Database:
● MySQL (v8.0 or above) for structured data storage.
● Interaction: Communication with the database will occur through SQL
queries over an ODBC/JDBC connection, supporting CRUD operations.
2. Payment Gateway Integration:
● Stripe API (or equivalent) for payment processing.
● Interface: The platform will use REST API calls to initiate and confirm
transactions, handle refunds, and process user payment information
securely.
3. Email Notification Service:
● SendGrid API for sending transactional emails.
● Interface: The system will use SMTP or REST API for sending
notifications about bookings, inquiries, and system alerts to users.
4. Authentication Service:
● JWT (JSON Web Tokens) for secure user authentication.
● Interface: The system will generate and validate JWTs for each login
session, securing user interactions with the backend.
3.1.4 Communications Interfaces

1. HTTP/HTTPS Protocols: The platform will operate over HTTPS to ensure data
encryption during data transmission.
2. WebSocket Protocol: Real-time messaging will be supported between tenants
and landlords using WebSocket connections to provide instant communication.
3. RESTful API: External communication and integration with third-party services
will be facilitated using RESTful APIs. Data will be exchanged in JSON format.

School Of Information Technology and Engineering 8| Page

3.2 Functional Requirements

3.2.1 User Registration and Authentication

1. Introduction: The system shall allow tenants, landlords, and administrators to

register, log in, and manage their accounts.
2. Inputs: Registration form inputs include username, password, email, and role
(tenant/landlord).
3. Processing: Upon submission, user data is validated and stored securely.
Passwords are hashed.
4. Outputs: User is redirected to their dashboard upon successful login. Error
messages are shown for failed registrations or incorrect login details.
5. Error Handling: The system shall display error messages if the username
already exists or if password criteria are not met.
3.2.2 Property Listings

1. Introduction: The system shall allow landlords to create and manage property
listings with information like price, description, photos, and availability status.
2. Inputs: Property details include property name, location, price, type
(rental/sales), description, images, and amenities.
3. Processing: Information is stored in the database, and images are processed to
ensure standard resolution and size.
4. Outputs: Property listings are displayed to tenants in search results.
5. Error Handling: Error messages are displayed if required fields are missing or
images are not in the correct format.
3.2.3 Search and Filter Properties

1. Introduction: The system shall allow tenants to search for properties using
criteria such as location, price range, property type, and amenities.
2. Inputs: Search inputs include text for location, dropdowns for property type, and
sliders for price range.
3. Processing: Search filters query the database, returning properties that match
specified criteria.
4. Outputs: Matching properties are displayed in a paginated list view.
5. Error Handling: If no properties match the criteria, a "No results found" message
is displayed.

3.3 Use Cases

School Of Information Technology and Engineering 9| Page

 3.3.1. Use Case Name: Login
● ID: UC1

School Of Information Technology and Engineering 10 | Page

 ● Actors: Admin, Owner, User
● Description: Authenticated users can log into the system to access relevant
pages.
● Pre-condition: The user must have a valid email and password.
● Post-condition: The user successfully logs in and is directed to their respective
dashboard.

Basic Course of Action:

1. User opens the system to log in.

2. The system displays the login form.
3. User enters email and password and clicks the login button.
4. The system validates the credentials.
5. The system displays the appropriate page for the user.
6. Use case ends.

Alternative Course of Action:

● If login credentials are invalid, the system displays an error message and reloads
the login form.

3.3.2. Use Case Name: Create Account

● ID: UC2
● Actors: Owner, User
● Description: Allows qualified users to create an account.
● Pre-condition: Users must have valid credentials.
● Post-condition: Users can access their accounts and interact with the system.

Basic Course of Action:

1. User clicks the "Sign Up" button.

2. The system displays the sign-up form.
3. User fills in the required details.
4. The system validates the provided information.
5. If successful, the system displays a confirmation message.
6. Use case ends.

Alternative Course of Action:

● If invalid data is entered, the system displays an error message and prompts the
user to re-enter data.

3.3.3. Use Case Name: Upload House

School Of Information Technology and Engineering 11 | Page

 ● ID: UC3
● Actor: Owner
● Description: Allows owners to upload house information to the system.
● Pre-condition: The house must be registered in the system.
● Post-condition: House information is successfully uploaded.

Basic Course of Action:

1. Owner logs in.

2. The system displays the owner's dashboard.
3. Owner navigates to the "Rent House" section.
4. The system displays a form to enter house details.
5. Owner fills out the form and clicks "Upload."
6. The system validates the data.
7. If successful, a confirmation message is displayed.
8. Use case ends.

Alternative Course of Action:

● If the form contains invalid data, an error message is displayed, and the system
returns to the form.

3.3.4. Use Case Name: Update House Information

● ID: UC4
● Actor: Owner
● Description: Allows owners to update previously posted house information.
● Pre-condition: Owner must have an existing post.
● Post-condition: The house information is successfully updated.

Basic Course of Action:

1. Owner logs in.

2. The system displays the owner's dashboard.
3. Owner navigates to their posts.
4. The system displays the edit form.
5. Owner updates the information and clicks "Update."
6. The system validates the data.
7. If successful, a confirmation message is displayed.
8. Use case ends.

Alternative Course of Action:

● If the entry is invalid, the system displays an error message and reloads the form.

School Of Information Technology and Engineering 12 | Page

 3.3.5. Use Case Name: View Available Houses

● ID: UC6
● Actor: All Users
● Description: Users can view available houses in the system.
● Pre-condition: User wants to view available houses.
● Post-condition: User views the available houses.

Basic Course of Action:

1. User opens the system.

2. The system loads the homepage with available houses.
3. User navigates to "For Rent" section.
4. System displays available houses with details.
5. Use case ends.

3.3.6. Use Case Name: Send Request to Apply

● ID: UC12
● Actor: User
● Description: Allows users to send a request to apply for a house.
● Pre-condition: User must be logged in.
● Post-condition: Request is sent successfully.

Basic Course of Action:

1. User logs in.

2. User navigates to the "For Rent" section and views available houses.
3. User selects a preferred house and clicks "Request to Apply."
4. The system displays a request form.
5. User fills out and submits the request.
6. The system validates the data.
7. If successful, a confirmation message is displayed.
8. Use case ends.

3.3.7. Use Case Name: Send Response

● ID: UC13
● Actor: Owner
● Description: Allows owners to respond to user requests.
● Pre-condition: Owner must be logged in.
● Post-condition: Response is successfully sent.

School Of Information Technology and Engineering 13 | Page

 Basic Course of Action:

1. Owner logs in.

2. Owner navigates to the "Chat" section.
3. System displays user requests.
4. Owner clicks "Write Message" and enters a response.
5. Owner submits the response.
6. The system validates the response.
7. If successful, a confirmation message is displayed.
8. Use case ends.

3.3.8. Use Case Name: Send Feedback

● ID: UC14
● Actors: Owner, User
● Description: Allows users to provide feedback about the system or properties.
● Pre-condition: User has feedback to submit.
● Post-condition: Feedback is successfully submitted.

Basic Course of Action:

1. User navigates to the "Contact Us" section.
2. The system displays the feedback form.
3. User fills in the form and submits it.
4. System validates the feedback.
5. If successful, a confirmation message is displayed.
6. Use case ends.

3.3.9. Use Case Name: Search House

● ID: UC11
● Actors: Owner, User
● Description: Allows users to search for specific houses.
● Pre-condition: User wants to find specific properties.
● Post-condition: System displays search results.

Basic Course of Action:

1. User opens the system.

2. The system displays a search bar.
3. User enters search criteria and submits.
4. System processes the request and displays relevant results.
5. Use case ends.

School Of Information Technology and Engineering 14 | Page

 3.3.10. Use Case Name: Set Location
● ID: UC33
● Actor: Owner
● Description: Allows owners to set the location of their properties.
● Pre-condition: Owner is listing a property and needs to specify its location.
● Post-condition: Location is saved successfully.

Basic Course of Action:

1. Owner logs in and navigates to property listing.

2. Owner enters location details for the house.
3. System saves the information.
4. Use case ends.

3.3.11. Use Case Name: View House

● ID: UC7
● Actors: Owner, User
● Description: Allows users to view house details.
● Pre-condition: User or owner wants to view details of a house.
● Post-condition: System displays house details.

Basic Course of Action:

1. User opens the system.

2. System displays available houses.
3. User views details of a selected house.
4. Use case ends.
Alternative Course of Action:

● If there is a connection error, the system displays a message and reloads the
page.

3.3.12. Use Case Name: Cart

● ID: UC35
● Actor: User
● Description: Allows users to compare houses they are interested in.
● Pre-condition: User is logged in and has added houses to the cart.
● Post-condition: User can view and compare selected houses.

School Of Information Technology and Engineering 15 | Page

 Basic Course of Action:

1. User logs in and navigates to "For Rent."

2. User adds houses to the cart.
3. System allows user to compare selected houses.
4. Use case ends

3.4 Non-Functional Requirements

3.4.1 Performance

● The system shall process search requests within 2 seconds for up to 10,000
users.
3.4.2 Reliability

● The system shall have an uptime of 99.9% and recover from errors within 10
seconds.

3.4.3 Availability

● The system shall be accessible 24/7, with scheduled maintenance not exceeding
2 hours per month.

3.4.4 Security

● The system shall encrypt sensitive data (e.g., passwords and payment info)
using AES-256.

3.4.5 Maintainability

● The system code shall follow modular architecture and proper documentation for
ease of maintenance.

3.4.6 Portability

● The system shall be compatible with the latest versions of popular browsers and
mobile operating systems.

3.5 Inverse Requirements

● The system shall not support offline property search or offline booking.
● The system shall not provide video tours of properties.

3.6 Design Constraints

● The platform must comply with data privacy regulations, including GDPR.

School Of Information Technology and Engineering 16 | Page

 ● Integration with third-party payment services is constrained to Tele-birr ,M-PESA.

3.7 Logical Database Requirements

● The database shall store data in structured tables for properties, users, bookings,
and payments.
● Data integrity shall be maintained with foreign keys linking users to bookings and
properties to landlords.

3.8 Other Requirements

Training-Related Requirements

● A user manual shall be provided for tenants and landlords, covering property
listing, booking, and account management.

Packaging Requirements

● The system shall be packaged as a cloud-hosted application with code

repositories and a README file for installation instructions.

Legal Requirements

● All system components shall comply with copyright laws, and licenses for third-
party libraries shall be appropriately acquired.

4. Change Management Process

The change management process for the Software Requirements Specification (SRS) is
designed to ensure that all modifications are tracked, reviewed, and approved
systematically. This process will help maintain the integrity of the SRS document,
accommodate changes in project scope or requirements, and provide clarity for the
project team and stakeholders.

4.1 Change Request Submission

1. Who Can Submit Changes:

● Change requests can be submitted by any key project stakeholders,
including the Project Manager, Product Owner, Development Team
Lead, QA Lead, or any Stakeholder representing the customer’s
requirements.
● Only authorized individuals may submit changes to prevent unnecessary
or unauthorized modifications.
2. Means of Submission:

School Of Information Technology and Engineering 17 | Page

 ● Change requests will be submitted via a Change Request Form
accessible through the project management tool (e.g., JIRA, Asana) or
shared collaboration platform (e.g., Confluence).
● The Change Request Form should include:
● Requestor’s name and role
● Date of submission
● Description of the requested change
● Rationale for the change
● Impact analysis (potential effects on scope, timeline, and budget)
● Priority level (critical, high, medium, low)

4.2 Change Review Process

1. Initial Review:
● The Project Manager and Product Owner will review each change
request to determine if it aligns with project goals and objectives.
● If the change is deemed significant, it will be discussed in a Change
Control Board (CCB) meeting for further evaluation.
2. Change Control Board (CCB):
● The CCB will be responsible for evaluating and approving major changes.
The board will include representatives from key areas:
○ Project Manager
○ Product Owner
○ Development Team Lead
○ QA Lead
○ Relevant Stakeholders or Customer Representative (if applicable)
● The CCB will meet weekly (or as needed) to review pending change
requests.
● During the meeting, the CCB will assess each change based on:
○ Feasibility: Technical and operational feasibility of the change.
○ Impact: Evaluation of the impact on requirements, scope, timeline,
and budget.
○ Risks: Assessment of any risks associated with implementing the
change.
○ Prioritization: Assigning a priority level to the change based on
project needs.
3. Approval Process:

Changes will be approved by majority vote within the CCB. For critical changes,
unanimous approval may be required.

Once a change is approved, it will be assigned an implementation priority and

timeline, and the SRS will be updated accordingly.

For minor changes, approval may be granted directly by the Project Manager and
Product Owner without a CCB meeting.

School Of Information Technology and Engineering 18 | Page

4.3 SRS Update and Version Control

1. SRS Document Update:

● After a change is approved, the Technical Writer or Project Manager will
update the SRS document to reflect the new requirements or
modifications.
● Each change will be documented in the Revision History section of the
SRS, including:
■ Date of change
■ Change request ID
■ Brief description of the change
■ Reason for the change
■ Approving authority
2. Version Control:
● Each updated version of the SRS will be assigned a unique version
number (e.g., v1.1, v1.2).
● A copy of each version will be saved in a centralized repository (e.g.,
Google Drive, Confluence, or Git) with restricted editing access to
maintain document integrity.
● Version numbers will be included in the document header and tracked in
the Revision History.
3. Notification of Changes:
● Once updated, a notification will be sent to all project stakeholders and
team members through email or project communication channels (e.g.,
Slack, Microsoft Teams).
● The Project Manager will also highlight key changes during weekly project
meetings.

4.4 Change Implementation and Testing

1. Implementation:
● Approved changes will be assigned to the respective development or
design teams with a defined timeline and task list.
● The Project Manager will update the project schedule to reflect any impact
on milestones or deadlines caused by the change.
2. Testing and Validation:
● The QA team will develop or modify test cases to validate the change
once it is implemented.
● After successful testing, the change will be marked as “Completed” and
closed in the change management system.

4.5 Change Request Closure

Once a change has been implemented, tested, and validated, the Change Request will
be marked as “Closed” in the project management tool. The CCB or Project Manager
will review closed requests periodically to ensure proper documentation and traceability.

School Of Information Technology and Engineering 19 | Page

4.6 Documentation and Traceability

To ensure traceability:

1. Unique Identifiers: Each change request will have a unique ID for tracking and
cross-referencing in the SRS.
2. Linking Changes to Requirements: All modified requirements will be
referenced with their respective change request IDs.
3. Audit Trail: A complete audit trail of all changes will be maintained, with each
change linked back to its original request, approval, and implementation record.

References

This section provides a list of all documents referenced throughout the Software
Requirements Specification (SRS) document. Each document is identified by its title,
report number (if applicable), date, and publishing organization. Sources are specified
for easy access to these references.

1. Software Requirements Specification Overview

● Title: Software Requirements Specification

● Source: Wikipedia
● Link: Software Requirements Specification
● Publishing Organization: Wikimedia Foundation, Inc.

2. Client Information

● Title: Infinity Property Marketing

● Contact Information:
○ Phone Number (Main): 0976 186 966
○ Alternate Phone Number: 0947 404 142
● Publishing Organization: Infinity Property Marketing
● Date:Nov 4,2024
● Description: Contact information for the client to provide further information
regarding project requirements and details.

School Of Information Technology and Engineering 20 | Page

School Of Information Technology and Engineering 21 | Page
A. Appendices

The appendices section provides supplementary information that supports

the main content of the Software Requirements Specification (SRS)
document. Unless explicitly stated otherwise, the information contained
within each appendix is intended to assist in the understanding of the SRS
but is not to be considered part of the formal requirements.
A.1 Appendix 1: Initial Conceptual Documents

This appendix includes the initial conceptual documents for the software
project, such as:

● Early drafts of the project concept and objectives.

● Diagrams illustrating key concepts or proposed system architecture.
● Notes on initial functionality and feature set discussions.
● High-level requirements brainstormed in the early stages.

These documents provide background on the initial project direction and

can help clarify the intent behind certain requirements.
A.2 Appendix 2: Marketing and Stakeholder Materials

This appendix contains marketing and stakeholder-related materials,

including:

● Market research data relevant to the project, identifying the needs of

potential users.
● Early product positioning and branding documents.
● Any relevant marketing material that influenced the direction of the
project, including personas or user stories developed from market
analysis.
● Summary of benefits and key selling points for the software product.

These documents can offer additional insight into the user and business
needs addressed by the requirements.
A.3 Appendix 3: Meeting Minutes with Customers

This appendix provides minutes from meetings with the customer(s) or

stakeholders, capturing discussions around:

● Initial requirements and project expectations.

School Of Information Technology and Engineering 22 | Page

 ● Feedback on early design and functionality.
● Key decisions, clarifications, and agreed changes in project scope.
● Milestone reviews and customer satisfaction notes.

This information is valuable for tracing decisions made during requirements

development and ensuring all requirements are grounded in documented
stakeholder input.
A.4 Appendix 4: Change Log for Requirements

This appendix records changes made to the SRS over time, detailing:

● Dates of changes, versions, and summaries.

● Reasons for requirement additions, deletions, or modifications.
● Approvals from the Change Control Board (CCB).
● Impact analysis for major changes, including how the adjustments
align with project goals and stakeholder needs.

The change log is essential for traceability and ensuring that all
adjustments to the requirements are documented and approved

School Of Information Technology and Engineering 23 | Page