I'll use a simplified version of the IEEE SRS structure combined with

Agile-style user-focused functional requirements—ideal for small

teams. This will include:

1. Overview of the System

2. User Roles and Features

3. Functional Requirements Grouped by Feature

4. Inputs/Outputs per Function

5. Screen or Interaction Notes (where helpful)

I’ll now get started and prepare a complete document you can use
right away.

Warehouse Rental System – Functional Requirements Specification

Overview: The Warehouse Rental System is a web-based platform

connecting warehouse owners (landlords) with customers (tenants)
who need warehouse space. It lets landlords list and manage
warehouse properties, and enables customers to search, request
bookings, pay deposits, and review rentals. This SRS focuses on
functional requirements – what the system must do – without
prescribing design solutions. Each feature is described in terms of
user actions, inputs, outputs, and business rules, following
guidelines that requirements “should specify what functions are to
be performed” (the what, not the how). Requirements are stated
clearly and unambiguously, so each is necessary, appropriate,
complete, and verifiable.

User Roles and High-Level Features: The system has several user
roles with distinct capabilities:

 Guest (Visitor): Unauthenticated user who can browse

warehouse listings and search by location, size, price, and
features. Guests can view public information but must register
to make requests or see detailed data.

 Customer (Tenant): Registered user seeking to rent space.

Customers can search listings, submit rental requests (with
proposed dates and usage), pay deposits, view rental status,
and after completion, submit reviews or report issues. They
manage a personal profile with contact and payment details.
  Warehouse Owner (Landlord): Registered user offering one or
more warehouses for rent. Owners can create/edit warehouse
listings (with details like size, location, price, availability,
deposit amount), view and respond to incoming rental
requests (approve or reject), and manage their bookings and
payments.

 Admin/Staff: Authorized personnel overseeing the platform.

Admins can manage all users, warehouses, and transactions.
They review or intervene in disputes, generate reports, and
manage system settings.

Each role’s high-level features include: user account management

(registration, login), warehouse catalog maintenance, search and
filtering, booking request workflow, payment processing,
review/feedback, issue reporting, and administrative dashboards for
oversight.

1. Overview of the System

This system provides a marketplace for warehouse rentals. Key

system functions include: secure authentication and user
registration; search and browse of warehouse listings by various
criteria; booking requests with an approval workflow; handling
payments for security deposits or fees; and post-rental functions
like reviews and issue reporting. The SRS presents each function as
a requirement “the system shall…” along with its inputs, outputs,
and business rules. Requirements avoid design details; they
describe what the system must do, not how it does it.

2. User Roles and High-Level Features

 Guest: Browses warehouses. Can access home page and public

catalog. High-level features: Warehouse search, view
warehouse details (limited info), view login/register pages.
Cannot request rentals or view private data.

 Customer (Tenant): After registering and logging in, can search

and filter warehouses, view full details, submit rental requests,
pay deposits via payment gateway, view request status, and
submit reviews or issue reports. Features include Account
Profile management (update contact/payment info), and a
dashboard showing their active/past rentals and requests.
  Warehouse Owner (Landlord): After login, can create and
manage warehouse listings (add/edit/delete warehouses),
specify availability calendar, pricing, and deposit amount.
Receives customer requests and can approve or reject each
request with a reason. Upon approval, can confirm booking
schedules and track payments. Owner has a dashboard to see
all their listings, current bookings, and pending requests.

 Admin/Staff: Has full system access: manage user accounts

(approve new owners, disable users), manage all warehouse
records, oversee all rental requests, handle payments (refunds
or fee collections), monitor reviews and issues, and generate
usage reports. Admin UI includes dashboards for system
metrics and lists of pending actions (unhandled requests,
reported issues, etc.).

Each role is associated with features that span the lifecycle of a

rental (from listing creation to post-rental feedback). The functions
below are organized by feature to ensure clarity and completeness.

3. Functional Requirements by Feature

3.1 Account Management (Authentication & Registration)

User Registration:

 Inputs: new user information (full name, email, password,

contact number, and role selection: Customer or Owner; for
owners, business info may be required).

 Outputs: creation of a new user account record; success or

failure notification; verification email sent to user.

 Rules: Email must be unique and valid. Password must meet

complexity rules (e.g. minimum length, character types). Upon
successful registration, the system marks the account as
inactive until email verification. Only verified accounts can log
in. All form inputs are validated on the server side (no blank
required fields, proper formats).

 UI Notes: Registration page has input fields with labels and

hints. A confirmation message and link for email verification
are displayed. Errors (e.g. “Email already used”, “Password
too weak”) appear inline.
User Login:

 Inputs: existing user’s email and password.

 Outputs: user session established on successful login;

otherwise an error message. Redirect to user dashboard or
home.

 Rules: Login only if account is verified and active. After a

configurable number of failed attempts, the system locks the
account or introduces a delay to prevent brute force. Session
timeout and “Remember me” options may apply.

 UI Notes: Login form on home page. Show generic error

(“Invalid credentials”) without revealing whether email or
password is incorrect. Provide “Forgot password” link.

Logout and Session:

 Inputs: user action (click “Logout”).

 Outputs: session terminated, user returns to public home

page.

 Rules: The system clears session cookies.

 UI Notes: “Logout” button/menu accessible from any

authenticated page.

Password Reset:

 Inputs: user’s registered email via “Forgot password” form.

 Outputs: if email exists, send a secure reset link; else an error

message.

 Rules: The reset token expires after a set time (e.g. 1 hour)
and can be used only once. New password must meet
complexity rules.

 UI Notes: “Forgot password” page with email input. After

submission, show a generic message (“If this email is
registered, you will receive reset instructions”). Reset page
(linked from email) has password fields.

3.2 Warehouse Listing and Management (Owner)

Add Warehouse Listing:

  Inputs: Owner-provided warehouse details including address,
size (sqm), dimensions, type (e.g. dry storage), features (e.g.
refrigeration, security), rent price per unit time, required
deposit amount, availability schedule (start/end dates), and
images.

 Outputs: new warehouse record stored; listing visible in

catalog (pending admin approval if required). Confirmation
message with listing ID.

 Rules: All fields marked required must be filled. Location is

validated (geocoded). The system ensures the owner has not
exceeded a maximum number of listings (if any). Listing
cannot go live without mandatory fields or approval.

 UI Notes: “Create Warehouse” form with labeled fields, date

pickers for availability, multi-file upload for images. Preview
before submission.

Edit Warehouse Listing:

 Inputs: updated fields for an existing warehouse (identified by

ID).

 Outputs: listing updated in database; confirmation message.

 Rules: Only the owner who created the listing (or admin) can
edit. Changes to availability or pricing are validated (e.g. new
price >= 0). If changes conflict with existing bookings, the
system may disallow (e.g. reducing size below reserved
amount).

 UI Notes: Warehouse detail page for owner with an “Edit”

button. Edit form pre-filled with current data.

Delete or Deactivate Listing:

 Inputs: Owner action to remove or deactivate a listing.

 Outputs: listing marked as inactive or removed, no longer

appears in searches; confirmation shown.

 Rules: Only if no active bookings exist, or any active bookings

are transferred/cleared first. If bookings exist, system must
warn and optionally cancel pending bookings.
  UI Notes: “Delete/Deactivate” option in listing management.
Show warning if cancellations needed.

3.3 Warehouse Search and Browse (Customer)

Search Warehouses:

 Inputs: search criteria from user: location (address or map),

date range (desired rental period), size requirements, price
range, warehouse features/tags (e.g. “temperature-
controlled”), and optional keywords.

 Outputs: a list of matching warehouse summaries sorted

(default by relevance or price). Each result shows key info
(location, thumbnail, price, size).

 Rules: Only listings that are active and available for the
requested dates should appear. If date range overlaps existing
approved bookings, those dates are excluded. Filtering is case-
insensitive. Results are paginated.

 UI Notes: Search form on homepage or dedicated page.

Dynamic filters on side. “No results” message if none found.

View Warehouse Details:

 Inputs: user selects a warehouse from search results.

 Outputs: detailed page with full description, photos, map

location, owner contact info (masked until booking), pricing
breakdown (rent, deposit), calendar availability, and a
“Request to Book” button.

 Rules: Display only allowed fields: guests see limited details,

logged-in users see more. If listing is owned by a different
user, contact info is visible only after booking is confirmed (or
via system messaging).

 UI Notes: Clear layout with image gallery, tabs/sections for

details and reviews, “Back to search” link.

3.4 Rental Request Process (Customer)

Submit Rental Request:

  Inputs: from customer: selected warehouse ID, requested
rental start date and end date, purpose/use description, and
agreement to terms.

 Outputs: a new rental request created with status “Pending.”

Confirmation to user including request ID and summary.
Notification sent to warehouse owner (and admin).

 Rules: Request dates must fall within the warehouse’s

available range and not overlap other approved rentals. If
invalid, the system rejects request with explanation. A
customer cannot request the same warehouse for overlapping
periods.

 UI Notes: “Request Booking” form on warehouse details. Date

pickers with disabled unavailable dates. Show deposit amount
upfront.

Request Validation:

 Inputs: the system automatically checks submitted request

against availability and policy.

 Outputs: either accept into “pending” or immediate rejection

(if e.g. dates invalid, user not allowed).

 Rules: Overlap rules enforced. If the owner is inactive or listing

was disabled mid-process, request is automatically rejected.

 UI Notes: Any errors show on the request form page.

3.5 Approval Workflow (Owner)

Review Incoming Request:

 Inputs: Owner views list of pending requests for their

warehouses. Each entry includes customer name, requested
dates, and details.

 Outputs: Owner can select a request and see full request info.

 Rules: Only owners of that warehouse (or admin) can access

each request. Requests older than a certain threshold may
auto-expire.

 UI Notes: “Requests” dashboard showing Pending, Approved,

Rejected tabs with counts.
Approve Request:

 Inputs: Owner action on a pending request: click “Approve”.

Optionally enter terms or comments.

 Outputs: The request status changes to “Approved.” System

blocks those dates in the availability calendar. Notifications are
sent to customer and admin.

 Rules: Upon approval, the system must record the approval

date and user. Overlapping requests from other customers for
same dates must be flagged (owner is warned before final
approve).

 UI Notes: On request detail page, an “Approve” button.

Confirmation dialog to avoid mistakes.

Reject Request:

 Inputs: Owner action: click “Reject” on a pending request;

must provide a reason (text).

 Outputs: The request status changes to “Rejected” with

reason. Notification to customer. No dates are blocked.

 Rules: Owner must supply a reason (prevents rejections

without cause). System logs the rejection reason.

 UI Notes: “Reject” button on request detail, opens a small

modal/dialog with a “Reason” text area.

3.6 Deposit Payment and Booking Confirmation

Payment Processing:

 Inputs: After approval, customer initiates deposit payment:

selects payment method (e.g. credit card), and provides
payment details. The required amount (as specified in the
listing) is charged.

 Outputs: On success, a payment confirmation and receipt are

generated. Booking status changes to “Confirmed.” Funds (or
hold) are recorded. On failure, an error message is shown.

 Rules: The system integrates with a payment gateway API.

Must ensure transactional integrity (no partial saves). Taxes or
fees (if any) are calculated and shown. A receipt (possibly
 downloadable) is provided. If payment fails, customer may
retry or cancel request.

 UI Notes: “Checkout” page showing amount, breakdown, and

payment fields. Clear success/failure messages.

Finalize Booking:

 Inputs: Payment success and prior approval.

 Outputs: The rental order is finalized; an entry appears in both

customer’s and owner’s booking list with status “Active” or
“Scheduled.” An email confirmation is sent with rental details
and rules.

 Rules: The system updates availability calendar to remove

booked period. Cancellation policy may apply (if user cancels
after payment).

 UI Notes: Booking detail page with dates, link to contract (if

generated), and contact info. Customer sees status
“Confirmed.”

3.7 Reviews and Ratings (Customer)

Submit Review:

 Inputs: After rental end date (or after move-in), customer

enters a review: star rating (1–5) and text comments for the
warehouse (and optionally about the owner or service).

 Outputs: Review added to the warehouse’s reviews;

aggregated rating updated. Confirmation shown.

 Rules: Customer can review each booking once. Content is

moderated (e.g. profanity filter). The system prevents posting
before move-in date or long after rental end (e.g. reviews only
within 30 days of end).

 UI Notes: “Leave a Review” button appears on user’s past

bookings. Review form with stars and text. Once submitted,
the review displays under the warehouse’s page.

3.8 Issue Reporting (Customer and Owner)

Report Issue:
  Inputs: Either party (mostly customer) can report an issue
during or after a rental: select related booking, describe issue
(text), optionally attach photos.

 Outputs: A new issue ticket is logged (with status “Open”) and

assigned (to admin or owner as appropriate). Notification sent
to admin and involved parties.

 Rules: Issue categories (e.g. “Damage”, “Late availability”)

standardize reports. Each report records date/time and user.
The reporter receives an issue ID.

 UI Notes: “Report an Issue” link on booking page. Form fields:

subject, description, attachments. Confirmation page with
ticket number.

Issue Handling:

 Inputs: Admin/staff reviews open issues, adds status updates

(In Progress, Resolved), and communicates via the system
(notes, messages).

 Outputs: Status changes trigger notifications to reporter and

other involved users. When resolved, final remarks are
recorded.

 Rules: Only staff/admin can mark an issue resolved. All actions

are logged for audit.

 UI Notes: Admin dashboard shows a list of reported issues with

filters by status.

3.9 Admin/Staff Dashboard and Management

User Management:

 Function: Admin can list all user accounts, search/filter by role

or status, and perform actions (activate/deactivate accounts,
reset passwords, escalate issues with users).

 Inputs: Admin selects a user, then chooses actions.

 Outputs: Changes applied to user records; audit log updated;

user notified if needed.

 Rules: Admin cannot deactivate themselves. Owner

registrations may require manual approval.
  UI Notes: “Manage Users” page with a table of users and
action buttons (Edit, Deactivate, etc.).

Warehouse Oversight:

 Function: Admin can view all warehouse listings, filter by

owner, status, or location, and suspend or remove listings that
violate policy.

 Inputs: Admin actions on listings.

 Outputs: Listing status updated; owner notified.

 Rules: Admin actions are logged.

 UI Notes: “Manage Warehouses” page similar to user

management.

Booking and Payment Reports:

 Function: Admin views lists of all rental orders and payments,

with filtering (date range, status, warehouse). Also exportable
reports (CSV/Excel) of rentals, revenues, occupancy rates.

 Inputs: filter criteria or export commands.

 Outputs: filtered list on screen, or downloaded report file.

 Rules: Sensitive data (like payment details) masked. Reports

auto-update (no caching needed).

 UI Notes: “Reports” section with options: “Active Bookings”,

“Completed Rentals”, “Revenue by Month”.

System Notifications:

 Function: The system automatically generates alerts for

admins: e.g. new user sign-ups, unresolved payment failures,
issues escalated more than X days, or abandoned carts.

 Inputs: system events (user registration, failed payments, etc).

 Outputs: notification entries and/or emails to admins or

owners.

 Rules: Notification thresholds are configurable (e.g. send daily

summary).
  UI Notes: A notification bell or inbox in admin UI, plus email
alerts.

UI Consistency & Navigation: For all roles, screens include

consistent navigation (menus, breadcrumbs). Key functions (search
bar, dashboard) are accessible from most pages. Forms provide
helpful validation and feedback messages. All list views (e.g. search
results, request lists) are paginated with clear headings. The
system enforces role-based access control on each screen (e.g. only
owners see “My Listings” menus).

Each functional requirement above is defined with clear

preconditions, inputs, expected outputs, and business rules, making
them actionable for implementation. By following this specification,
developers can implement a system where each feature can be
tested against the stated requirements.

Sources: This specification follows SRS best practices to clearly

define functional requirements, focusing on what the Warehouse
Rental System must do. Requirements are scoped to the functions
listed above; any missing elements would need new requirements.