[Document title]

[Document subtitle]

NAME REGISTRATION NUMBER SIGNATURE

Functional Requirements

1. User Management

• User Registration: Allow users (students, staff, admins) to create accounts

with email, phone number, or social media login.

• User Login/Logout: Secure authentication (e.g., email/password, OTP, or

OAuth) and session management.

• User Profiles: Enable users to view and edit personal details (name, contact,
ID, preferences).

• Role-Based Access: Support different roles (e.g., admin, warden, student)

with specific permissions.

2. Room Management

• Room Listing: Display available rooms with details (room type, capacity,
amenities, price).

• Room Booking: Allow users to book rooms, select check-in/check-out dates,

and confirm availability.

• Room Allocation: Enable admins/wardens to assign rooms to users manually

or automatically.

• Room Status Tracking: Show real-time room status (occupied, vacant, under
maintenance).

3. Booking and Payment

• Booking Process: Support booking requests, cancellations, and modifications

with confirmation notifications.

• Payment Integration: Enable secure online payments (credit/debit cards,

mobile payments, bank transfers).

• Invoice Generation: Provide users with booking receipts and payment history.

• Refund Management: Handle refund requests per hostel policy.

4. Hostel Facilities Management

• Amenities Listing: Display available facilities (e.g., Wi-Fi, laundry, mess, gym)
with schedules or rules.

• Service Requests: Allow users to request services (e.g., cleaning,

maintenance) and track request status.
 • Complaint System: Enable users to submit and track complaints or feedback.

5. Admin and Staff Management

• Dashboard: Provide admins with an overview of bookings, occupancy,

payments, and issues.

• User Management: Allow admins to manage user accounts (approve,

suspend, or delete).

• Reports and Analytics: Generate reports on occupancy rates, revenue, and

user activity.

• Inventory Management: Track hostel resources (e.g., beds, linens,

equipment).

6. Communication

• Notifications: Send automated emails, SMS, or push notifications for booking

confirmations, payments, or updates.

• Messaging System: Enable in-app communication between users and hostel

staff.

• Announcements: Allow admins to post hostel-wide notices or updates.

7. Search and Filters

• Room Search: Allow users to search rooms by criteria (price, type, availability,
amenities).

• Booking History: Enable users to view past and upcoming bookings with filters
(date, status).

NON-FUNCTIONAL REQUIREMENTS

1. Performance
• Response Time: The system should respond to user actions (e.g., search,
booking) within 2 seconds under normal load.
• Concurrent Users: Support at least 500 simultaneous users without
performance degradation.
• Transaction Processing: Process payments and bookings within 5 seconds per
transaction.
2. Scalability
• User Growth: Handle a 50% increase in users annually without requiring
major architectural changes.
 • Data Volume: Manage data for up to 10,000 rooms and 100,000 bookings
efficiently.
• Peak Load: Accommodate peak usage (e.g., during admission seasons) with
no downtime.
3. Reliability and Availability
• Uptime: Ensure 99.9% system availability, with no more than 8 hours of
planned downtime annually.
• Error Rate: Maintain an error rate below 0.1% for critical operations (e.g.,
payments, bookings).
• Data Recovery: Restore data within 1 hour in case of system failure.
4. Security
• Data Encryption: Use AES-256 encryption for sensitive data (e.g., user details,
payment info) at rest and in transit.
• Authentication: Implement secure authentication mechanisms (e.g., OAuth
2.0, multi-factor authentication).
• Compliance: Adhere to data protection regulations (e.g., GDPR, CCPA) for user
privacy.
• Access Control: Restrict unauthorized access with role-based permissions.
5. Usability
• User Interface: Provide an intuitive, responsive UI/UX accessible to users with
minimal technical knowledge.
• Accessibility: Comply with WCAG 2.1 standards for users with disabilities (e.g.,
screen reader support).
• Learning Curve: Ensure new users can navigate and book a room within 5
minutes without assistance.
6. Maintainability
• Code Modularity: Design the system with modular code to allow updates
within 1 day without downtime.
• Documentation: Provide comprehensive developer and user documentation
updated with each release.
• Logging: Maintain detailed logs for troubleshooting, retained for at least 6
months.
7. Compatibility
• Platform Support: Ensure compatibility with major browsers (Chrome, Firefox,
Safari) and mobile platforms (iOS 15+, Android 10+).
 • Device Responsiveness: Support screen sizes from 320px (mobile) to 1920px
(desktop).

User Stories

1. Story ID: S-LOG1

Title: Registered Student login
Story:
As a registered student, I want to securely log in to my account, so that i can
manage my hostel booking and access student-specific services.

Acceptance criteria:

 Given I am a registered student, when i enter my account correct

email/username and password, then the system logs me in and
redirects me to my dashboard.
 Given I enter an incorrect email/username or password, then the
system displays an error message: ‘’incorrect username or password.
Please try again.’’
 Given I do not have an account, when I try to log in, then the system
informs me that I need to register first.

2. Story ID: S-LOG2

Title: Un-registered Student login (Guest student)
Story:
As a prospective student, I want to browse the hostel’s services and rooms as
a guest, so that I can evaluate my options before deciding to register an
account on the system.

Acceptance criteria:

 Given I am on the login page, when I select the “Explore as guest”

option, then I am granted access to public pages without needing to
log in.
3. Story ID: W-NOT1
Title: Warden sending announcements and notifications to residents
Story:
As a hostel Warden, I want to be able to send announcements and
notifications to all residents, so that i can effectively communicate important
information like events, policy changes and maintenance schedules.

Acceptance criteria:

 Given I am logged in as an administrator

 And I navigate to the announcement section
 When I create a new announcement with a title and a message
 And I select “send to all residents”, then the announcement is
successfully posted and all active residents receive a notification (e.g.,
via SMS, email, or in app pop-up)

4. Story ID: W-MAN2

Title: Assigning rooms to residents
Story:
As a hostel Warden, I want to assign available rooms and beds to new and
existing residents so that I can manage occupancy to ensure every resident
has a designated space.

Acceptance criteria:

 Given there is a vacant room with available bed and the resident’s
profile is ready for room assignment.
 When I select a resident and assign them to the available bed in the
room then the system updates the bed’s status to “occupied”
 The resident’s profile is updated with their new room and bed number
and a notification is sent to the resident.
 5. Story ID: A-MON2
Title: Monitoring suspicious activity
Story:
As a Systems administrator, I want to view security Event Logs so that I can
detect and respond to potential security threats to the residents and staff’s
data.

Acceptance criteria:

 Given multiple security events have occurred (e.g., failed logins,

unauthorised access attempts)
 When I navigate to the security log section of the admin dashboard
 I should see a chronological list of all security events and each log
entry should contain the timestamp, event type, affected user account
(if any), and source IP address

Use case: Create and Send a general announcement

Title: Send a Hostel-Wide Announcement

Primary Actor: Hostel Warden

Goal: To broadcast an important message to all current residents.

Preconditions:

 The hostel Warden is logged into the hostel management system.

 The Warden has the necessary permissions to create and send announcements
 The Warden has a pre-written message they wish to send

Main success scenario:

1. The hostel Warden navigates to the main dashboard.

2. The Warden goes to the announcement section
 3. The system displays a list of past announcements and an option of creation a new
one
4. The Warden choses to create a new announcement
5. The system provides a form in where to input the new announcement
6. The Warden enters the title and message content of the announcement
7. The Warden selects the option “that sends to all residents”.
8. The Warden then selects the send option
9. The system validates the data
10. The system then sends the announcement to all residents via their configured
notification channels (e.g. email, mobile number, mobile app notification)
11. The system displays a confirmation message to the Warden: “Announcement
successfully sent”
12. The system then adds the new announcement to the list of past announcements for
the Warden to view

Alternative flow:

 Alternate flow 1: Saving as a draft

 From step 8: the Warden selects the save as draft option instead of option
send
 The systems saves the announcement as a draft without sending any
notifications
 The draft is visible in the Warden’s announcement list with a draft status.
The Warden can later edit and send it.
 Alternative flow 2: incomplete form
 From step 8: the Warden selects the send option but leaves a required
field (e.g. “title”) blank.
 The system displays an error message next to the empty field (eg
“message cannot be empty”)
 The Warden is unable to send the announcement until all required fields
are filled.

Postconditions:

 The announcement is stored in the systems database

 Notifications are sent to all residents
 The Warden can view a log of the send announcement

UML DIAGRAM FOR ‘’Send a Hostel-Wide Announcement’’

Based on the use case you've provided, here is a second use case for a hostel
management system in Uganda.

Use Case: Book a Visitor Appointment

Goal

To allow a hostel resident to book and manage an appointment for a visitor to see them
at the hostel.

Primary Actor

Hostel Resident

Preconditions

The Hostel Resident is logged into the hostel management system.

The resident has an active booking at the hostel.

The system is configured to allow visitor appointments.

Main Success Scenario

The Hostel Resident navigates to the visitor management section from their main
dashboard.
The system displays a list of the resident's upcoming and past visitor appointments.

The resident selects the option to schedule a new appointment.

The system presents a form for the resident to input visitor details.

The resident enters the visitor's full name, a valid ID number (e.g., National ID or
passport number), and the purpose of the visit.

The resident selects the date and time of the appointment.

The system validates the proposed appointment time to ensure it falls within the hostel's
official visiting hours.

The resident confirms the details and submits the appointment request.

The system creates a new entry for the appointment and sends a notification to the
Warden for approval.

The system displays a confirmation message to the resident: "Your visitor appointment
request has been submitted for approval."

The new appointment is added to the resident's list with a "Pending" status.

Alternative Flows

Alternate Flow 1: Warden Rejects Appointment

From step 9, the Warden reviews the request and rejects it due to a policy violation (e.g.,
visitor is on a "Do Not Admit" list).

The system updates the appointment status to "Rejected" and sends a notification to the
resident explaining the reason for rejection.

The resident can view the rejected appointment and the rejection reason.

AM to 6:00 PM").

The resident must adjust the time before they can submit the request.

Postconditions

The visitor appointment request is stored in the system's database.

The Warden is notified of the new request.

The resident can view the status of their appointment request at any time.