0% found this document useful (0 votes)
3 views33 pages

Use Cases (Fix)

The document outlines use cases for the House Finder System, detailing user interactions for logging in, viewing available houses, filtering results, and viewing house details. Each use case specifies actors, triggers, preconditions, postconditions, normal flows, alternative flows, exceptions, and other relevant information. The system is designed to ensure secure access, efficient data retrieval, and user-friendly experiences for registered users and guests.
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3 views33 pages

Use Cases (Fix)

The document outlines use cases for the House Finder System, detailing user interactions for logging in, viewing available houses, filtering results, and viewing house details. Each use case specifies actors, triggers, preconditions, postconditions, normal flows, alternative flows, exceptions, and other relevant information. The system is designed to ensure secure access, efficient data retrieval, and user-friendly experiences for registered users and guests.
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd

ID and Name: UC-08 Login

Created By: Phùng Xuân Đạt Date Created: 26/04/25


Primary Actor: Registered User Secondary Actors: Authentication System , Database
System
Description: A Registered User accesses the House Finder System via a web browser app to
log into their account using valid email and password credentials. The system
validates the credentials and grants access if correct, or provides appropriate
feedback if the login fails.
Trigger: The user selects the “Login” option from the House Finder System’s homepage or
login screen.
Preconditions: PRE-1: The user has an active account in the House Finder System with valid
email and password credentials.
PRE-2: The system is operational and capable of processing login requests.
PRE-3: The user knows their email and password or can use the “Forgot
Password” function if needed.
Postconditions: POST-1: If the credentials are valid, the user is logged into the system and granted
access to their account.
POST-2: The user is redirected to the dashboard or homepage of the House Finder
System.
POST-3: The system logs the login action with a timestamp.
POST-4: If the login fails, the user receives an error message indicating the reason
(e.g., incorrect email or password).
Normal Flow: The user navigates to the “Login” section on the House Finder System’s homepage
or login screen.
The system displays a login form with fields for Email and Password.
The user enters their email and password.
The user submits the login form.
5a. Validation process:
5a.1. The system verifies that the email exists in the database.
5a.2. The system checks that the provided password matches the stored
password for the email.
If all validations pass, the system authenticates the user and grants access to their
account.
The system redirects the user to the dashboard or homepage.
The system logs the login action with a timestamp.
Alternative Flows: 4.1 Incorrect Email or Password
1. The system detects that the email does not exist or the password is incorrect.
2. The system displays an error message: “Incorrect email or password. Please try
again.”
3. The user re-enters their email and/or password and resubmits, returning to step 3
of the normal flow.
4.2 Account Locked
1. The system detects that the account is locked (e.g., due to multiple failed login
attempts).
2. The system displays an error message: “Your account is temporarily locked.
Please try again later or use the ‘Forgot Password’ option.”
3. The user follows the “Forgot Password” process or waits for the lock to expire,
then restarts the use case.
Exceptions: 4.0.E1 Incomplete Form
1. The system detects that one or more required fields (Email, Password) are
empty.
2. The system displays an error message: “Please fill in all required fields.”
3a. If the user cancels the login process, the system terminates the use case.
3b. If the user provides the missing data, return to step 3 of the normal flow.
4.0.E2 System Unavailable
1. The system displays: “Service temporarily unavailable. Please try again later.”
2a. If the user cancels the login process, the system terminates the use case.
2b. If the user retries later, the use case restarts.
Priority: High
Frequency of Use: Approximately 1,000–2,000 login requests per day across all users (Renter,
Landlord, Staff), with peaks during morning and evening hours.
Business Rules: BR-1.
Other Information: 1. Passwords are stored securely using industry-standard encryption.
2. All login actions (successful or failed) are logged for security and auditing
purposes.
3. Users can cancel the login process at any time before submission.
4. The system provides clear, user-friendly error messages for invalid inputs.
5. The system supports a “Forgot Password” option for users who cannot log in.
Assumptions: 1. The system reliably validates email and password credentials.
2. Users have access to their registered email and password or can recover them
via the “Forgot Password” function.
3. The average login failure rate is below 5% based on historical system usage
data.
4. The system’s database is secure and capable of handling login requests without
downtime.

ID and Name: UC-09 View List of Available Houses


Created By: Phùng Xuân Đạt Date Created: 26/04/25
Primary Actor: Registered User Secondary Actors: Database System, House Finder
System
Description: A Registered User accesses the House Finder System via a web browser app to
view a list of available houses for rent. The user can filter or sort the list based on
criteria such as location, price, house type, or availability. The system retrieves and
displays the list of houses that match the user’s criteria and comply with business
rule BR- 22, which ensures only verified and active rental listings are shown.
Trigger: The user selects the “View Houses” or “Search Houses” option from the House
Finder System’s homepage, dashboard, or search interface.
Preconditions: PRE-1: The user has an active account in the House Finder System and is logged
in.
PRE-2: The system is operational and capable of retrieving house listings from the
database.
PRE-3: There are active and verified house listings available in the system that
comply with BR-22 (listings must be verified by landlords and marked as
available).
Postconditions: POST-1: The system displays a list of available houses that match the user’s search
criteria (if any) or a default list of verified, active listings.
POST-2: The user can view details of each house (e.g., location, price, type,
description) by selecting a listing.
POST-3: The system logs the user’s search action with a timestamp for analytics
purposes.
POST-4: If no houses match the criteria or an error occurs, the system displays an
appropriate message (e.g., “No houses found matching your criteria”).
Normal Flow: 9.0 View List of Available Houses
1. The user navigates to the “View Houses” or “Search Houses” section on the
House Finder System’s homepage or dashboard.
2. The system displays a search interface with optional filters (e.g., location, price
range, house type, number of bedrooms) and sorting options (e.g., price low-to-
high, newest first).
3. The user optionally applies filters or sorting preferences and submits the search
request.
4. The system queries the database for house listings that comply with BR-HF-22
(verified and active listings) and match the user’s criteria.
5. The system displays a list of available houses, including summary details such
as location, price, house type, and a thumbnail image.
6. The user can select a house to view its full details (e.g., description, amenities,
contact information).
7. The system logs the search action with a timestamp.
Alternative Flows: 9.1 No Houses Match Criteria
1. The system detects that no houses match the user’s search criteria.
2. The system displays a message: “No houses found matching your criteria. 3.
Please adjust your filters and try again.”
4. The user modifies the filters or clears them and resubmits, returning to step 3 of
the normal flow.
9.2 Default Listing Without Filters
1. The user does not apply any filters or sorting preferences.
2. The system retrieves and displays a default list of verified, active house listings
sorted by relevance or recency (per BR-22).
3. The flow continues from step 5 of the normal flow.
Exceptions: 9.0.E1 System Unavailable
1. The system displays: “Service temporarily unavailable. Please try again later.”
2a. If the user cancels the search process, the system terminates the use case.
2b. If the user retries later, the use case restarts.
9.0.E2 No Active Listings
1. The system detects that no verified, active house listings are available in the
database.
2. The system displays a message: “No houses are currently available. Please
check back later.”
3. The user exits the search or retries later, restarting the use case.
Priority: High
Frequency of Use: Approximately 5,000–10,000 search requests per day across all users (Renter,
Landlord, Staff), with peaks during weekends and housing market seasons.
Business Rules: BR-22
Other Information: 1. The system supports filtering by location, price range, house type (e.g.,
apartment, house, studio), number of bedrooms, and other criteria.
2. Sorting options include price (low-to-high, high-to-low), recency, and relevance.
3. All search actions are logged for analytics and auditing purposes.
4. The system provides clear, user-friendly messages for cases where no results are
found.
5. House listings include essential details (e.g., price, location, type) and a link to
view full details.
Assumptions: 1. The system reliably retrieves and filters house listings based on user criteria.
2. The database contains verified and active listings that comply with BR- 22.
3. The average rate of searches returning no results is below 10% based on
historical system usage data.
4. The system’s database is secure and capable of handling high-volume search
requests without downtime.

ID and Name: UC-10 Filter Results


Created By: Phùng Xuân Đạt Date Created: 26/04/25
Primary Actor: Registered User, guest Secondary Actors: Database System, House Finder
System
Description: A Registered User accesses the House Finder System via a web browser app to
filter the list of available houses for rent based on specific criteria such as location,
price range, number of bedrooms, house size, or pet policy. The system applies the
selected filters and displays a refined list of active house listings. The user can
adjust, combine, or reset filters to refine results further.
Trigger: The user selects filter options from the “Search Houses” or “View Houses”
interface and applies them to refine the list of available houses.
Preconditions: PRE-1: The user has an active account in the House Finder System and is logged
in.
PRE-2: The system is operational and capable of processing filter requests.
PRE-3: There are active house listings available in the system database.
PRE-4: The user is on the “Search Houses” or “View Houses” interface with
access to filter options.
Postconditions: POST-1: The system displays a filtered list of available houses that match the
user’s selected criteria.
POST-2: The user can view details of each house (e.g., location, price, size, pet
policy) by selecting a listing from the filtered results.
POST-3: The system logs the filter action with a timestamp for analytics purposes.
POST-4: If no houses match the selected filters, the system displays an appropriate
message (e.g., “No houses found matching your criteria”).
Normal Flow: 10.0 Filter Results
1. The user navigates to the “Search Houses” or “View Houses” section on the
House Finder System’s homepage or dashboard.
2. The system displays a search interface with filter options (e.g., location, price
range, number of bedrooms, house size in square meters, pet policy) and sorting
options (e.g., price low-to-high, newest first).
3. The user selects one or more filter criteria (e.g., price range: $300–$800,
location: Hanoi, pet-friendly: yes) and applies the filters.
4. The system queries the database for active house listings that match the user’s
selected filters.
5. The system displays a filtered list of available houses, including summary
details such as location, price, number of bedrooms, size, and pet policy.
6. The user can select a house to view its full details (e.g., description, photos,
landlord contact).
7. The system logs the filter action with a timestamp.
Alternative Flows: 11.1 No Houses Match Filters
1. The system detects that no houses match the user’s selected filter criteria.
2. The system displays a message: “No houses found matching your criteria.
Please adjust your filters or try again.”
3. The user modifies or resets the filters and resubmits, returning to step 3 of the
normal flow.
11.2 Reset Filters
1. The user selects the option to reset all filters.
2. The system clears all applied filters and retrieves a default list of active house
listings sorted by default criteria (e.g., recency or relevance).
3. The flow continues from step 5 of the normal flow.
Exceptions: 10.0.E1 System Unavailable
1. The system displays: “Service temporarily unavailable. Please try again later.”
2a. If the user cancels the filter process, the system terminates the use case.
2b. If the user retries later, the use case restarts.
10.0.E2 No Active Listings
1. The system detects that no active house listings are available in the database.
2. The system displays a message: “No houses are currently available. Please
check back later.”
3. The user exits the search or retries later, restarting the use case.
Priority: High
Frequency of Use: Approximately 2,500–6,000 filter requests per day across all users (Renter,
Landlord, Staff), with higher usage during peak housing search periods (e.g., start
of academic or fiscal years).
Business Rules: BR-1: Renter must be logged in to use the search function. BR-2: Search results
only display active listings (not deleted or reported). BR-3: Listings with images
and full descriptions are prioritized (Priority = M).
Other Information: 1. Supported filter criteria include location (city, district), price range, number of
bedrooms (e.g., 1, 2, 3+), house size (e.g., 50–100 m²), and pet policy (pet-friendly
or no pets).
2. The system allows combining multiple filters to narrow results.
3. All filter actions are logged for analytics and auditing purposes.
4. The system provides clear, user-friendly messages when no results are found or
when filters are invalid.
5. Filtered results include essential details (e.g., price, location, size, pet policy)
and a link to view full house details.
Assumptions: 1. The system reliably applies filters and retrieves matching house listings.
2. The database contains active house listings with sufficient data to support
filtering.
3. The average rate of filter searches returning no results is below 8% based on
historical system usage data.
4. The system’s database is secure and capable of handling high-volume filter
requests without downtime.

ID and Name: UC-11 View House Details


Created By: Phùng Xuân Đạt Date Created: 26/04/25
Primary Actor: Registered User,Guest Secondary Actors: Database System, House Finder
System
Description: A Registered User accesses the House Finder System via a web browser app to
view detailed information about a specific house listed for rent. The user selects a
house from a list of available houses (e.g., search results or filtered list) and views
comprehensive details such as price, location, house type, size, amenities, photos,
and landlord contact information. The system retrieves and displays the details of
the selected house.
Trigger: The user selects a specific house listing from the search results, filtered list, or
homepage of the House Finder System.
Preconditions: PRE-1: The user has an active account in the House Finder System and is logged
in.
PRE-2: The system is operational and capable of retrieving house details from the
database.
PRE-3: The selected house is an active listing in the system (not expired or
deactivated).
PRE-4: The user is on an interface displaying a list of houses (e.g., search results
or filtered results).
Postconditions: POST-1: The system displays detailed information about the selected house,
including price, location, house type, size, amenities, photos, and landlord contact
information.
POST-2: The user can interact with the details (e.g., view photos, contact the
landlord, or save the listing).
POST-3: The system logs the view action with a timestamp for analytics purposes.
POST-4: If the house details cannot be retrieved (e.g., listing no longer active), the
system displays an appropriate error message.
Normal Flow: 11.0 View House Details
1. The user navigates to the “Search Houses” or “View Houses” section on the
House Finder System’s homepage or dashboard and views a list of available
houses.
2. The user selects a specific house listing from the displayed results.
3. The system queries the database for the detailed information of the selected
house.
4. The system displays the house details, including:
- Price (e.g., monthly rent).
- Location (e.g., city, district, address).
- House type (e.g., apartment, house, studio).
- Size (e.g., square meters).
- Number of bedrooms and bathrooms.
- Amenities (e.g., air conditioning, parking, Wi-Fi).
- Pet policy (e.g., pet-friendly or no pets).
- Photos of the house.
5. Landlord contact information (e.g., phone number or messaging option).
6. The user can interact with the details (e.g., browse photos, initiate contact with
the landlord, or save the listing to favorites).
7. The system logs the view action with a timestamp.
Alternative Flows: 11.1 House Listing No Longer Active
1. The system detects that the selected house listing is no longer active (e.g., rented
or deactivated).
2. The system displays a message: “This house is no longer available. Please select
another listing.”
3. The user returns to the list of available houses and selects another listing,
returning to step 2 of the normal flow.
11.2 Partial Details Available
1. The system detects that some details (e.g., photos or amenities) are missing for
the selected house.
2. The system displays the available details and a message: “Some information is
incomplete. Contact the landlord for more details.”
3. The flow continues from step 5 of the normal flow.
Exceptions: 11.0.E1 System Unavailable
1. The system displays: “Service temporarily unavailable. Please try again later.”
2a. If the user cancels the process, the system terminates the use case.
2b. If the user retries later, the use case restarts.
11.0.E2 House Not Found
1. The system detects that the selected house does not exist in the database (e.g.,
due to a data error).
2. The system displays a message: “Error: House not found. Please try another
listing.”
3. The user returns to the list of available houses, restarting the use case.
Priority: High
Frequency of Use: Approximately 4,000–8,000 house detail views per day across all users (Renter,
Landlord, Staff), with peaks during weekends and housing market seasons.
Business Rules: BR-1: Sorting by price takes priority over distance.
Other Information: 1. House details are presented in a user-friendly format with clear sections for
price, location, amenities, etc.
2. The system supports interaction options such as saving the listing, sharing it, or
contacting the landlord directly.
3. All view actions are logged for analytics and auditing purposes.
4. The system ensures high-quality display of photos (if available) and provides a
fallback message if photos are missing.
5. Landlord contact information is only displayed to logged-in users to prevent
unauthorized access.
Assumptions: 1. The system reliably retrieves and displays house details for active listings.
2. The database contains sufficient data for most active listings to provide
comprehensive details.
3. The average rate of unavailable or missing house listings is below 5% based on
historical system usage data.
4. The system’s database is secure and capable of handling high-volume detail
requests without downtime.

ID and Name: UC-012 View House Location on Google Maps


Created By: Phùng Xuân Đạt Date Created: 26/04/25
Primary Actor: Registered User Secondary Actors: Database System, House Finder
System, Google Maps API
Description: A Registered User accesses the House Finder System via a web browser app to
view the location of a specific house listed for rent on an embedded Google Maps
interface. The user selects a house from a list or its details page, and the system
displays the house’s location using coordinates or address provided in the listing.
The map allows basic interaction such as zooming or panning.
Trigger: The user selects the “View on Map” option from a house’s details page or listing
summary in the House Finder System.
Preconditions: PRE-1: The user has an active account in the House Finder System and is logged
in.
PRE-2: The system is operational and capable of retrieving house details and
integrating with the Google Maps API.
PRE-3: The selected house is an active listing with valid location data (e.g.,
address or coordinates).
PRE-4: The user is on a house details page or a listing interface that includes a
“View on Map” option.
Postconditions: POST-1: The system displays the house’s location on an embedded Google Maps
interface, centered on the house’s address or coordinates.
POST-2: The user can interact with the map (e.g., zoom, pan) to explore the
surrounding area.
POST-3: The system logs the map view action with a timestamp for analytics
purposes.
POST-4: If the house’s location data is invalid or unavailable, the system displays
an appropriate error message.
Normal Flow: 12.0 View House Location on Google Maps
1. The user navigates to a house’s details page or a list of available houses in the
House Finder System.
2. The user selects the “View on Map” option for a specific house listing.
3. The system retrieves the house’s location data (e.g., address or coordinates)
from the database.
4. The system sends a request to the Google Maps API to generate an embedded
map centered on the house’s location.
5. The system displays the embedded Google Maps interface with a marker
indicating the house’s location.
6. The user can interact with the map (e.g., zoom in/out, pan) to view the
surrounding area.
7. The system logs the map view action with a timestamp.
Alternative Flows: 2.1 Invalid or Missing Location Data
1. The system detects that the house’s location data (e.g., address or coordinates) is
invalid or missing.
2. The system displays a message: “Location data unavailable for this house.
Please contact the landlord for more information.”
3. The user returns to the house details page or selects another listing, terminating
the use case.
12.2 Google Maps API Failure
1. The system detects that the Google Maps API request fails (e.g., due to
connectivity issues or API limits).
2. The system displays a message: “Unable to load map at this time. Please try
again later.”
3. The user can retry the “View on Map” option, returning to step 2 of the normal
flow, or exit the use case.
Exceptions: 12.0.E1 System Unavailable
1. The system displays: “Service temporarily unavailable. Please try again later.”
2a. If the user cancels the process, the system terminates the use case.
2b. If the user retries later, the use case restarts.
12.0.E2 House Not Found
1. The system detects that the selected house does not exist in the database (e.g.,
due to a data error).
2. The system displays a message: “Error: House not found. Please try another
listing.”
3. The user returns to the list of available houses, restarting the use case.
Priority: High
Frequency of Use: Approximately 1,000–3,000 map view requests per day across all users (Renter,
Landlord, Staff), with higher usage during peak housing search periods.
Business Rules: BR-1: Messages must comply with system regulations.
Other Information: 1. The map displays a marker at the house’s exact location or approximate area
based on the provided address/coordinates.
2. The system ensures secure integration with the Google Maps API to protect user
data.
3. All map view actions are logged for analytics and auditing purposes.
4. The system provides clear, user-friendly error messages for cases where the map
cannot be displayed.
5. The map interface is responsive and optimized for both web and mobile app
users.
Assumptions: 1. The system reliably retrieves location data and integrates with the Google Maps
API.
2. Most active house listings include valid location data (address or coordinates).
3. The average rate of unavailable or invalid location data is below 5% based on
historical system usage data.
4. The system’s database and API integration are secure and capable of handling
map view requests without downtime.

ID and Name: UC-13 View Available Rooms


Created By: Phùng Xuân Đạt Date Created: 26/04/25
Primary Actor: Registered User Secondary Actors: Database System, House Finder
System
Description: A Registered User accesses the House Finder System via a web browser app to
view a list of available rooms for rent within houses or apartments. The user can
browse rooms based on default criteria or apply filters (e.g., location, price, room
type). The system retrieves and displays a list of active room listings with
summary details such as price, location, and room type.
Trigger: The user selects the “View Rooms” or “Search Rooms” option from the House
Finder System’s homepage, dashboard, or search interface.
Preconditions: PRE-1: The user has an active account in the House Finder System and is logged
in.
PRE-2: The system is operational and capable of retrieving room listings from the
database.
PRE-3: There are active room listings available in the system (not expired or
deactivated).
Postconditions: POST-1: The system displays a list of available rooms that match the user’s search
criteria (if any) or a default list of active room listings.
POST-2: The user can view summary details of each room (e.g., price, location,
room type) and select a room to view its full details.
POST-3: The system logs the search action with a timestamp for analytics
purposes.
POST-4: If no rooms are available or match the criteria, the system displays an
appropriate message (e.g., “No rooms found matching your criteria”).
Normal Flow: 13.0 View Available Rooms
1. The user navigates to the “View Rooms” or “Search Rooms” section on the
House Finder System’s homepage or dashboard.
2. The system displays a search interface with optional filters (e.g., location, price
range, room type such as single room or shared room, amenities) and sorting
options (e.g., price low-to-high, newest first).
3. The user optionally applies filters or sorting preferences and submits the search
request.
4. The system queries the database for active room listings that match the user’s
criteria.
5. The system displays a list of available rooms, including summary details such as
price, location, room type, and a thumbnail image (if available).
6. The user can select a room to view its full details (e.g., size, amenities, landlord
contact information).
7. The system logs the search action with a timestamp.
Alternative Flows: 13.1 No Rooms Match Criteria
1. The system detects that no rooms match the user’s search criteria.
2. The system displays a message: “No rooms found matching your criteria. Please
adjust your filters and try again.”
3. The user modifies the filters or clears them and resubmits, returning to step 3 of
the normal flow.
13.2 Default Listing Without Filters
1. The user does not apply any filters or sorting preferences.
2. The system retrieves and displays a default list of active room listings sorted by
relevance or recency.
3. The flow continues from step 5 of the normal flow.
Exceptions: 13.0.E1 System Unavailable
1. The system displays: “Service temporarily unavailable. Please try again later.”
2a. If the user cancels the search process, the system terminates the use case.
2b. If the user retries later, the use case restarts.
13.0.E2 No Active Room Listings
1. The system detects that no active room listings are available in the database.
2. The system displays a message: “No rooms are currently available. Please check
back later.”

3. The user exits the search or retries later, restarting the use case.
Priority: High
Frequency of Use: Approximately 2,000–5,000 room search requests per day across all users (Renter,
Landlord, Staff), with peaks during student housing seasons or urban migration
periods.
Business Rules: BR-1: Sorting by price takes priority over distance.
Other Information: 1. The system supports filtering by location, price range, room type (e.g., single
room, shared room), and amenities (e.g., private bathroom, Wi-Fi).
2. Sorting options include price (low-to-high, high-to-low), recency, and relevance.
3. All search actions are logged for analytics and auditing purposes.
4. The system provides clear, user-friendly messages for cases where no results are
found.
4. Room listings include essential details (e.g., price, location, room type) and a
link to view full details.
Assumptions: 1. The system reliably retrieves and filters room listings based on user criteria.
2. The database contains active room listings with sufficient data to support
browsing.
3. The average rate of searches returning no results is below 10% based on
historical system usage data.
4. The system’s database is secure and capable of handling high-volume search
requests without downtime.

ID and Name: UC-14 Send Offer for Accommodation


Created By: Phùng Xuân Đạt Date Created: 26/04/25
Primary Actor: Registered User Secondary Actors: Database System, House Finder
System, Landlord (Recipient)
Description: A Registered User (Renter) accesses the House Finder System via a web browser
app to send an offer to rent a house or room to the landlord who posted the listing.
The offer includes the renter’s contact information and specific requirements (e.g.,
move-in date, duration, special requests). The system facilitates the
communication through its messaging platform, but any formal contract is handled
directly between the renter and landlord outside the platform.
Trigger: The user selects the “Send Offer” or “Contact Landlord” option from a house or
room listing’s details page in the House Finder System.
Preconditions: PRE-1: The user has an active account in the House Finder System and is logged
in.
PRE-2: The system is operational and capable of processing and sending offer
messages.
PRE-3: The selected house or room is an active listing with valid landlord contact
information.
PRE-4: The user is on the details page of a house or room listing that includes a
“Send Offer” or “Contact Landlord” option.
Postconditions: POST-1: The system successfully sends the renter’s offer, including contact
information and requirements, to the landlord via the platform’s messaging system.
POST-2: The user receives a confirmation message that the offer has been sent.
POST-3: The system logs the offer action with a timestamp for analytics and
auditing purposes.
POST-4: If the offer cannot be sent (e.g., invalid listing or system error), the
system displays an appropriate error message.
Normal Flow: 8.0 Send Offer for Accommodation
1. The user navigates to the details page of a house or room listing in the House
Finder System.
2. The user selects the “Send Offer” or “Contact Landlord” option.
3. The system displays a form with fields for the user’s contact information (e.g.,
name, phone number, email) and specific requirements (e.g., move-in date, rental
duration, number of occupants, special requests).
4. The user fills in the required fields and submits the offer.
5. The system validates the input data (e.g., ensures all required fields are filled,
contact information is valid).
6. The system sends the offer to the landlord via the platform’s messaging system.
7. The system displays a confirmation message: “Your offer has been successfully
sent to the landlord.”
The system logs the offer action with a timestamp.
Alternative Flows: 8.1 Invalid Input Data
1. The system detects that one or more required fields (e.g., contact information,
move-in date) are missing or invalid.
2. The system displays a message: “Please fill in all required fields with valid
information.”
3. The user corrects the input data and resubmits, returning to step 4 of the normal
flow.
8.2 Landlord Contact Unavailable
1. The system detects that the landlord’s contact information is missing or the
listing is no longer active.
2. The system displays a message: “Unable to send offer. This listing is no longer
available or contact information is missing.”
3. The user returns to the listing page or selects another listing, terminating the use
case.
Exceptions: 8.0.E1 System Unavailable
1. The system displays: “Service temporarily unavailable. Please try again later.”
2a. If the user cancels the process, the system terminates the use case.
2b. If the user retries later, the use case restarts.
8.0.E2 Messaging System Failure
1. The system detects that the messaging system failed to send the offer.
2. The system displays a message: “Error: Unable to send offer. Please try again
later.”
3. The user can retry sending the offer, returning to step 4 of the normal flow, or
exit the use case.
Priority: High
Frequency of Use: Approximately 500–1,500 offer requests per day across all users (Renters), with
peaks during housing market seasons or student move-in periods
Business Rules: BR-1: Sorting by price takes priority over distance.
Other Information: 1. The system ensures that the offer form is user-friendly, with clear fields for
contact details and requirements.
2. The platform’s messaging system securely transmits the offer to the landlord
without exposing sensitive user data publicly.
3. All offer actions (successful or failed) are logged for analytics and auditing
purposes.
4. The system provides clear, user-friendly error messages for invalid inputs or
failed submissions.
5. The landlord receives the offer as a message within the platform and can
respond directly to the renter.
Assumptions: 1. The system reliably validates and sends offer messages to landlords.
2. Most active listings include valid landlord contact information.
3. The average rate of failed offer submissions is below 5% based on historical
system usage data.
4. The system’s messaging system is secure and capable of handling high-volume
offer requests without downtime.
ID and Name: UC-15 Report Listing Of Post
Created By: Phùng Xuân Đạt Date Created: 26/04/25
Primary Actor: Registered User Secondary Actors: Database System, House Finder
System
Description: A Registered User accesses the House Finder System via the internet, navigates to
a specific property listing, and submits a report regarding issues with the listing
(e.g., inappropriate content, inaccurate information, or suspected fraud). The
system validates the report, logs it for review, and notifies the System
Administrator for further action. If the report is incomplete or invalid, the system
prompts the user to correct it.
Trigger: The user selects the “Report Listing” option on a property listing page.
Preconditions: PRE-1: The user is logged into the House Finder System with an activated
account.
PRE-2: The user has permission to report a listing.
PRE-3: The system is active and capable of processing listing reports.
PRE-4: The property listing exists in the system and is accessible to the user.
Postconditions: POST-1: The report is successfully submitted and stored in the system for review.
POST-2: The system logs the report action with a timestamp and user details for
audit purposes.
POST-3: The user receives a confirmation message indicating the report has been
submitted.
POST-4: The System Administrator is notified of the new report for further
investigation.
Normal Flow: 15.0 Report Listing of Post
1. The user navigates to a specific property listing in the House Finder System.
2. The user selects the “Report Listing” option on the listing page.
3. The system displays a report form with fields for the reason for the report (e.g.,
inappropriate content, inaccurate details, suspected fraud) and an optional
description.
4. The user fills out the report form and submits it.
5. The system validates the input data (e.g., ensures a reason is selected and the
description, if provided, meets length requirements).
6. If the data is valid, the system saves the report in the database and notifies the
System Administrator.
7. The system logs the report action with a timestamp and user ID.
8. The system displays a confirmation message: “Your report has been submitted
successfully and is under review.”
Alternative Flows: 15.1 Session Expired
1. If the user’s login session expires while filling out the report form, the system
displays: “Your session has expired. Please log in again.”
2. The system redirects the user to the login page.
3. After successful login, the system redirects the user back to the report form for
the same listing, returning to step 3 of the normal flow.
15.2 Incomplete Report Submission
1. If the user submits the report without selecting a reason, the system displays:
“Please select a reason for the report.”
2. The system retains the entered data and prompts the user to select a reason.
3. The user corrects the input and resubmits, returning to step 5 of the normal flow.
Exceptions: 15.0.E1 System Unavailable
1. The system displays: “Service temporarily unavailable. Please try again later.”
2a. If the user cancels the report process, the system terminates the use case.
2b. If the user retries later, the system restarts the use case from step 1.
15.0.E2 Listing No Longer Available
1. If the listing is removed or unavailable while the user is accessing the report
form, the system displays: “This listing is no longer available.”
2. The system redirects the user to the main listings page, and the use case
terminates.
Priority: Medium
Frequency of Use: Approximately 50–100 reports per week across all user types (Homeowner,
Renter, Real Estate Agent), with higher frequency in high-demand rental seasons
(e.g., September, October).
Business Rules: BR-1: Sorting by price takes priority over distance.
Other Information: 1. The system logs all report submissions (success or failure) for audit purposes,
including the user ID, listing ID, reported reason, and timestamp.
2. Users can cancel the report submission process at any time before submission.
3. The system provides clear and user-friendly error messages for invalid or
incomplete report submissions.
4. The description field for reports is optional but limited to 500 characters to
ensure concise input.
Assumptions: 1. The system can reliably validate report inputs (e.g., reason selection, description
length).
2. The System Administrator has tools to review and act on submitted reports (e.g.,
remove listing, contact poster).
3. The system can handle notifications to administrators without significant delay

ID and Name: UC-16 Mark Favourite


Created By: Phùng Xuân Đạt Date Created: 26/04/25
Primary Actor: Registered User Secondary Actors: None
Description: A Registered User accesses the House Finder System, a platform connecting
renters and landlords, via the internet, navigates to a specific property listing (e.g.,
house, apartment, or commercial space), and marks it as a favorite to save it for
later review or tracking. The system updates the user’s favorite list and confirms
the action. If the listing is unavailable or the user is not logged in, the system
handles the situation appropriately.
Trigger: The user selects the “Mark Favourite” option (e.g., a heart or bookmark icon) on a
property listing page.
Preconditions: PRE-1: The user is logged into the House Finder System with a verified and
activated account.
PRE-2: The user has permission to mark listings as favorites (applicable to all
registered user types: Renter, Landlord, Real Estate Agent).
PRE-3: The system is operational and capable of processing favorite list updates.
PRE-4: The property listing exists and is publicly visible on the platform.
Postconditions: POST-1: The listing is added to the user’s favorite list in the system.
POST-2: The system logs the action with a timestamp and user ID for audit
purposes.
POST-3: The user receives a confirmation message or visual indication (e.g.,
highlighted icon) confirming the listing has been marked as a favorite.
Normal Flow: 16.0 Mark Favourite
1. The user navigates to a specific property listing (e.g., house, apartment) on the
House Finder System.
2. The user selects the “Mark Favourite” option (e.g., clicks a heart or bookmark
icon) on the listing page.
3. The system verifies the user is logged in and the listing is valid.
4. The system adds the listing to the user’s favorite list in the database.
5. The system logs the action, including the user ID, listing ID, and timestamp.
6. The system updates the listing page to display a visual indication (e.g., a filled
heart icon) and shows a confirmation message: “This listing has been added to
your favorites.”
Alternative Flows: 16.1 Session Expired
1. If the user’s login session expires when attempting to mark a listing as a
favorite, the system displays: “Your session has expired. Please log in again.”
2. The system redirects the user to the login page.
3. After successful login, the system returns the user to the same listing page,
resuming at step 2 of the normal flow.
16.2 Listing Already in Favorites
1. If the user attempts to mark a listing that is already in their favorite list, the
system displays: “This listing is already in your favorites.”
2. The system provides an option to view the favorite list or continue browsing,
and the use case terminates.
Exceptions: 16.0.E1 System Unavailable
1. If the system is temporarily unavailable, it displays: “Service temporarily
unavailable. Please try again later.”
2a. If the user cancels the action, the system terminates the use case.
2b. If the user retries later, the system restarts the use case from step 1.
16.0.E2 Listing Removed or Unavailable
1. If the listing is no longer available (e.g., removed by the poster or administrator)
when the user attempts to mark it, the system displays: “This listing is no longer
available.”
2. The system redirects the user to the main listings page, and the use case
terminates.
Priority: High
Frequency of Use: Approximately 300–500 favorite markings per day across all user types (Renter,
Landlord, Real Estate Agent), with higher frequency during peak rental seasons
(e.g., August–October for student rentals or post-holiday periods).
Business Rules: BR-1: Sorting by price takes priority over distance.
Other Information: 1. The system logs all favorite marking actions (successful or failed) for audit
purposes, including user ID, listing ID, and timestamp.
2. Users can access their favorite list from the system dashboard or profile page.
3. The system provides a clear visual indication (e.g., toggling a heart icon) to
show whether a listing is marked as a favorite.
4. The favorite list is private and only visible to the user who marked the listings.
Assumptions: 1. The system can efficiently handle updates to the user’s favorite list without
performance issues.
2. The system supports real-time updates to the favorite icon’s state (e.g., filled or
unfilled heart).
3. The platform can manage high volumes of favorite markings during peak
seasons.
ID and Name: UC-17 Purchase Listing Package
Created By: Phùng Xuân Đạt Date Created: 26/04/25
Primary Actor: Renter Secondary Actors: Authentication System
Description: A Registered User accesses the House Finder System, a platform connecting
renters and landlords, via the internet, navigates to the listing package purchase
section, and purchases a listing package (free or premium) to post property listings
(e.g., houses, apartments) or rental needs (e.g., finding co-tenants). The system
validates the selected package, processes the payment (including 10% VAT),
ensures non-cash payment for transactions exceeding 20 million VND, and
activates the package. If the payment fails or input is invalid, the system prompts
the user to correct it.
Trigger: The user selects the “Purchase Listing Package” option from the system dashboard
or listing creation page.
Preconditions: PRE-1: The user is logged into the House Finder System with a verified and
activated account.
PRE-2: The user has permission to purchase listing packages (applicable to
Landlord or Real Estate Agent roles).
PRE-3: The system is operational and connected to a payment gateway for
processing transactions.
PRE-4: The available listing packages (free or premium) are configured in the
system.
Postconditions: POST-1: The selected listing package is activated for the user’s account.
POST-2: The system logs the purchase action with a timestamp, user ID, and
package details for audit purposes.
POST-3: The user receives a confirmation message and invoice (including 10%
VAT) confirming the successful purchase.
POST-4: The user can post listings or rental needs based on the package’s
permissions.
Normal Flow: 17.0 Purchase Listing Package
1. The user navigates to the “Purchase Listing Package” section from the system
dashboard or during the listing creation process.
2. The system displays available listing packages (e.g., Free Package: 1 listing,
Premium Package: 10 listings with enhanced visibility) with prices, including 10%
VAT.
3. The user selects a package and proceeds to payment.
4. The system validates the selection and checks if the transaction exceeds 20
million VND; if so, it enforces non-cash payment methods (e.g., bank card, mobile
app).
5. The system redirects the user to the payment gateway to complete the
transaction.
6. Upon successful payment, the payment gateway notifies the system, and the
system activates the selected package for the user’s account.
7. The system logs the purchase action, including user ID, package details,
payment amount, and timestamp.
8. The system sends a confirmation message: “Your listing package has been
successfully activated. You can now post listings.”
9. The system emails an invoice to the user, detailing the package, price, and 10%
VAT.
Alternative Flows: 17.1 Session Expired
1. If the user’s login session expires during the purchase process, the system
displays: “Your session has expired. Please log in again.”
2. The system redirects the user to the login page.
3. After successful login, the system returns the user to the package selection page,
resuming at step 3 of the normal flow.
17.2 Payment Failure
1. If the payment fails (e.g., insufficient funds, invalid card), the system displays:
“Payment failed. Please check your payment details and try again.”
2. The system retains the selected package and prompts the user to retry payment
or choose another payment method.
3. The user corrects the payment details and resubmits, returning to step 5 of the
normal flow.
Exceptions: 17.0.E1 System Unavailable
1. If the system or payment gateway is temporarily unavailable, the system
displays: “Service temporarily unavailable. Please try again later.”
2a. If the user cancels the purchase process, the system terminates the use case.
2b. If the user retries later, the system restarts the use case from step 1.
17.0.E2 Invalid Package Selection
1. If the user selects an invalid or unavailable package (e.g., discontinued
package), the system displays: “Selected package is not available. Please choose
another package.”
2. The system redirects the user to the package selection page, resuming at step 2
of the normal flow.
Priority: High
Frequency of Use: Approximately 200–400 package purchases per week across Landlord and Real
Estate Agent users, with higher frequency during peak rental seasons (e.g.,
August–October for student rentals or post-holiday periods).
Business Rules: BR-1: Sorting by price takes priority over distance.
Other Information: 1. The system logs all purchase actions (successful or failed) for audit purposes,
including user ID, package ID, payment amount, VAT, and timestamp.
2. Users can cancel the purchase process at any time before payment completion.
3. The system provides clear error messages for invalid payment attempts or
unavailable packages.
4. The invoice includes a breakdown of the package price, 10% VAT, and
transaction details.
5. The system supports multiple non-cash payment methods (e.g., bank cards,
mobile apps) for transactions exceeding 20 million VND.
Assumptions: 1. The system is integrated with a reliable payment gateway to process transactions
securely.
2. The system can accurately calculate and display VAT for all packages.
3. The platform can handle high volumes of package purchases during peak
seasons without performance issues.
4. Users have access to their purchase history and active package details in their
account dashboard.

ID and Name: UC-18 Upload Listing Of Post


Created By: Phùng Xuân Đạt Date Created: 26/04/25
Primary Actor: Registered User Secondary Actors: System Administrator
Description: A Registered User accesses the House Finder System, a platform connecting
renters and landlords, via the internet, navigates to the listing creation section, and
uploads a new property listing (e.g., house, apartment) or a rental need (e.g.,
finding co-tenants). The listing includes a precise address, rental price (with 10%
VAT if applicable), at least one image, and a detailed description. The system
validates the input data and ensures the user has a valid listing package. If the input
is invalid or the package is not active, the system prompts the user to correct the
issue.
Trigger: The user selects the “Upload Listing” option from the system dashboard or listing
management page.
Preconditions: PRE-1: The user is logged into the House Finder System with a verified and
activated account.
PRE-2: The user has permission to upload listings (applicable to Landlord or Real
Estate Agent roles).
PRE-3: The user has an active listing package (free or premium) with available
listing slots.
PRE-4: The system is operational and capable of processing listing uploads and
image storage.
Postconditions: POST-1: The new listing is successfully uploaded and published on the platform.
POST-2: The system logs the listing upload action with a timestamp, user ID, and
listing ID for audit purposes.
POST-3: The user receives a confirmation message confirming the listing has been
published.
POST-4: The listing is visible to other users (e.g., Renters) on the platform.
Normal Flow: 18.0 Upload Listing of Post
1. The user navigates to the “Upload Listing” section from the system dashboard
or listing management page.
2. The system checks if the user has an active listing package with available slots.
3. The system displays a listing creation form with required fields: precise address,
rental price (including 10% VAT if applicable), at least one image, detailed
description, and optional fields (e.g., amenities, property type).
4. The user fills out the form, uploads at least one image, and submits the listing.
5. The system validates the input data (e.g., address format per BR-58, image
format and size per BR-90, description length, and price including VAT per BR-
102).
[Link] the data is valid, the system saves the listing in the database and publishes it on
the platform.
The system logs the upload action, including user ID, listing ID, and timestamp.
The system displays a confirmation message: “Your listing has been successfully
published.”
Alternative Flows: 18.1 Session Expired
1. If the user’s login session expires during the listing creation process, the system
displays: “Your session has expired. Please log in again.”
2. The system redirects the user to the login page.
3. After successful login, the system returns the user to the listing creation form
with entered data preserved (if possible), resuming at step 4 of the normal flow.
18.2 Invalid or Incomplete Input
1. If the user submits the form with invalid or missing data (e.g., no image
uploaded, invalid address format, or missing price), the system displays an error
message: “Please provide a valid [field name]” or “At least one image is required.”
2. The system retains the entered data and prompts the user to correct the issue.
3. The user corrects the input and resubmits, returning to step 5 of the normal flow.
18.3 No Active Listing Package
1. If the user does not have an active listing package or has no remaining slots, the
system displays: “You need an active listing package to post. Please purchase a
package.”
2. The system redirects the user to the “Purchase Listing Package” section (UC-
16).
3. After purchasing a package, the user is returned to step 3 of the normal flow.
Exceptions: 18.0.E1 System Unavailable
1. If the system is temporarily unavailable, it displays: “Service temporarily
unavailable. Please try again later.”
2a. If the user cancels the upload process, the system terminates the use case.
2b. If the user retries later, the system restarts the use case from step 1.
18.0.E2 Image Upload Failure
1. If the image upload fails (e.g., file too large, unsupported format), the system
displays: “Image upload failed. Please upload a valid image (e.g., JPG, PNG, max
5MB).”
2. The system retains other entered data and prompts the user to upload a valid
image.
3. The user uploads a new image and resubmits, returning to step 5 of the normal
flow.
Priority: High
Frequency of Use: Approximately 500–800 listing uploads per day across Landlord and Real Estate
Agent users, with higher frequency during peak rental seasons (e.g., August–
October for student rentals or post-holiday periods).
Business Rules: BR- 5, BR- 8, BR- 58, BR- 90, BR- 93, BR- 102
Other Information: 1. The system logs all listing upload actions (successful or failed) for audit
purposes, including user ID, listing ID, and timestamp.
2. Users can cancel the listing upload process at any time before submission.
3. The system provides clear, user-friendly error messages for invalid inputs (e.g.,
missing fields, unsupported image formats).
4. Listings are published immediately after validation, unless flagged for manual
review by the System Administrator (e.g., for suspicious content).
4. The description field is limited to 1000 characters to ensure concise input.
Assumptions: 1. The system can validate address formats, image uploads, and price calculations
reliably.
2. The system supports secure storage and display of uploaded images.
3. The platform can handle high volumes of listing uploads during peak seasons
without performance issues.
4. Users have access to their uploaded listings in their account dashboard for
management (e.g., edit, delete).

ID and Name: UC-19 Manage Listing of Post


Created By: Phùng Xuân Đạt Date Created: 26/04/25
Primary Actor: Registered User Secondary Actors: System Administrator
Description: A Registered User accesses the House Finder System, a platform connecting
renters and landlords, via the internet, navigates to the listing management section,
and performs actions on a previously uploaded property listing or rental need (e.g.,
house, apartment, or co-tenant request). The actions include updating listing
details, deleting the listing, renewing its active period, or boosting its visibility
(pushing the listing). The system validates the actions, ensures the user has a valid
listing package for certain actions (e.g., boosting), and processes the request. If the
input is invalid or permissions are lacking, the system prompts the user to correct
the issue.
Trigger: The user selects the “Manage Listings” option from the system dashboard or
listing management page and chooses an action (update, delete, renew, or boost)
for a specific listing.
Preconditions: PRE-1: The user is logged into the House Finder System with a verified and
activated account.
PRE-2: The user has permission to manage listings (applicable to Landlord or Real
Estate Agent roles).
PRE-3: The user has at least one active or expired listing in the system.
PRE-4: The system is operational and capable of processing listing management
actions.
PRE-5: For boosting or renewing listings, the user has an active listing package
with available slots or credits.
Postconditions: POST-1: The selected action (update, delete, renew, or boost) is successfully
applied to the listing.
POST-2: The system logs the management action with a timestamp, user ID, and
listing ID for audit purposes.
POST-3: The user receives a confirmation message confirming the action’s
completion.
POST-4: The listing’s status or visibility is updated on the platform as per the
action performed.
Normal Flow: 19.0 Manage Listing of Post
1. The user navigates to the “Manage Listings” section from the system dashboard
or listing management page.
2. The system displays a list of the user’s current and expired listings with options
to update, delete, renew, or boost each listing.
3. The user selects a listing and chooses an action (update, delete, renew, or boost).
4. The system checks the user’s permissions and, for renew or boost actions,
verifies an active listing package with available slots or credits.
5. Depending on the action:
a. Update: The system displays an editable form pre-filled with the listing’s
current details (e.g., address, price, images, description). The user modifies the
desired fields and submits.
b. Delete: The system prompts for confirmation: “Are you sure you want to delete
this listing?” The user confirms.
c. Renew: The system confirms the listing’s eligibility for renewal and processes
the extension of its active period.
d. Boost: The system confirms the availability of boost credits and increases the
listing’s visibility (e.g., moves it to the top of search results).
6. The system validates the input or action (e.g., updated fields meet requirements
per BR-HF-8, sufficient credits for boosting).
7. If valid, the system processes the action, updates the listing in the database, and
reflects changes on the platform.
8. The system logs the action, including user ID, listing ID, action type, and
timestamp.
9. The system displays a confirmation message: “Your listing has been
[updated/deleted/renewed/boosted] successfully.”
Alternative Flows: 19.1 Session Expired
1. If the user’s login session expires during the management process, the system
displays: “Your session has expired. Please log in again.”
2. The system redirects the user to the login page.
3. After successful login, the system returns the user to the “Manage Listings”
section, resuming at step 2 of the normal flow.
19.2 Invalid Update Input
1. If the user submits updated listing details with invalid data (e.g., incorrect
address format, missing required fields), the system displays: “Please provide valid
[field name].”
2. The system retains the entered data and prompts the user to correct the issue.
3. The user corrects the input and resubmits, returning to step 6 of the normal flow.
19.3 No Active Listing Package for Renew/Boost
1. If the user attempts to renew or boost a listing without an active listing package
or sufficient credits, the system displays: “You need an active listing package to
[renew/boost]. Please purchase a package.”
2. The system redirects the user to the “Purchase Listing Package” section (UC-
16).
3. After purchasing a package, the user is returned to step 5 of the normal flow.
Exceptions: 19.0.E1 System Unavailable
[Link] the system is temporarily unavailable, it displays: “Service temporarily
unavailable. Please try again later.”
2a. If the user cancels the action, the system terminates the use case.
2b. If the user retries later, the system restarts the use case from step 1.
19.0.E2 Listing No Longer Eligible
1. If the listing is no longer eligible for management (e.g., permanently removed
by the System Administrator), the system displays: “This listing is no longer
available for management.”
2. The system redirects the user to the “Manage Listings” section, and the use case
terminates.
Priority: High
Frequency of Use: Approximately 600–1000 listing management actions (updates, deletions,
renewals, boosts) per day across Landlord and Real Estate Agent users, with higher
frequency during peak rental seasons (e.g., August–October for student rentals or
post-holiday periods).
Business Rules: BR- 5, BR- 8
Other Information: 1. The system logs all listing management actions (successful or failed) for audit
purposes, including user ID, listing ID, action type, and timestamp.
2. Users can cancel any management action before final submission or
confirmation.
3. The system provides clear, user-friendly error messages for invalid inputs or
insufficient permissions.
4. Boosted listings are prioritized in search results and marked with a visual
indicator (e.g., “Promoted”).
5. Updated listings may undergo automatic re-validation or manual review if
significant changes are detected (e.g., price or address).
Assumptions: 1. The system can validate updated listing details and manage actions reliably.
2. The system supports real-time updates to listing visibility for boost actions.
3. The platform can handle high volumes of listing management actions during
peak seasons without performance issues.
4. Users have access to a dashboard to view and manage their listings’ status (e.g.,
active, expired, boosted).

ID and Name: UC-20 Manage Viewing Requests


Created By: Phùng Xuân Đạt Date Created: 26/04/25
Primary Actor: Registered User Secondary Actors: System Administrator, Renter
Description: A Registered User (Landlord or Real Estate Agent) accesses the House Finder
System, a platform facilitating connections between renters and landlords, via the
internet, and navigates to the viewing requests section to handle requests from
Renters interested in viewing their listed properties (e.g., houses, apartments). The
user can review, approve, reject, or suggest alternative times for these requests.
The system ensures the action is valid, updates the request status, notifies the
Renter of the response, and logs the interaction. If the request is invalid or the
listing is no longer available, the system guides the user to resolve the issue.
Trigger: The user selects the “Manage Viewing Requests” option from the system
dashboard or listing management page.
Preconditions: PRE-1: The user is logged into the House Finder System with a verified and
activated account.
PRE-2: The user has permission to manage viewing requests (applicable to
Landlord or Real Estate Agent roles).
PRE-3: The user has at least one active listing with pending viewing requests from
Renters.
PRE-4: The system is operational and capable of processing viewing request
actions and notifications.
Postconditions: POST-1: The viewing request is updated with the user’s response (accepted,
declined, or alternative time proposed).
POST-2: The system logs the management action with a timestamp, user ID,
listing ID, and request ID for audit purposes.
POST-3: The Renter receives a notification with the response to their viewing
request.
POST-4: The user receives a confirmation message confirming the action’s
completion.
Normal Flow: 20.0 Manage Viewing Requests
1. The user navigates to the “Manage Viewing Requests” section from the system
dashboard or listing management page.
2. The system displays a list of pending viewing requests for the user’s listings,
including details such as the Renter’s name, requested date/time, and listing title.
3. The user selects a viewing request and chooses an action: accept, decline, or
propose an alternative time.
4. Depending on the action:
a. Accept: The system confirms the viewing appointment and schedules it.
b. Decline: The system prompts for an optional reason (e.g., “Property
unavailable”).
c. Propose Alternative Time: The user enters a new date/time, and the system
validates the input (e.g., future date, within listing availability).
5. The system validates the action (e.g., ensures the listing is active, the proposed
time is valid per BR-HF-15).
6. If valid, the system updates the viewing request status in the database and sends
a notification to the Renter with the response (e.g., “Your viewing request for
[listing title] has been accepted for [date/time]”).
7. The system logs the action, including user ID, listing ID, request ID, action type,
and timestamp.
8. The system displays a confirmation message: “Your response to the viewing
request has been processed successfully.”
Alternative Flows: 20.1 Session Expired
1. If the user’s login session expires during the management process, the system
displays: “Your session has expired. Please log in again.”
2. The system redirects the user to the login page.
3. After successful login, the system returns the user to the “Manage Viewing
Requests” section, resuming at step 2 of the normal flow.
20.2 Invalid Proposed Time
If the user proposes an invalid alternative time (e.g., past date, outside listing
availability), the system displays: “Please propose a valid date and time for the
viewing.”
The system retains the selected request and prompts the user to enter a new
date/time.
The user corrects the input and resubmits, returning to step 5 of the normal flow.
Exceptions: 20.0.E1 System Unavailable
1. If the system is temporarily unavailable, it displays: “Service temporarily
unavailable. Please try again later.”
2a. If the user cancels the action, the system terminates the use case.
2b. If the user retries later, the system restarts the use case from step 1.
20.0.E2 Listing Unavailable
1. If the listing associated with the viewing request is no longer available (e.g.,
removed or rented), the system displays: “This listing is no longer available for
viewing requests.”
2. The system notifies the Renter that the request is void and removes it from the
user’s pending requests.
3. The system redirects the user to the “Manage Viewing Requests” section, and
the use case terminates for that request.
Priority: High
Frequency of Use: Approximately 400–700 viewing request management actions (accept, decline,
propose alternative) per day across Landlord and Real Estate Agent users, with
higher frequency during peak rental seasons (e.g., August–October for student
rentals or post-holiday periods).
Business Rules: BR- 5, BR- 8, BR- 58, BR- 90, BR- 93, BR- 102
Other Information: 1. The system logs all viewing request management actions (successful or failed)
for audit purposes, including user ID, listing ID, request ID, action type, and
timestamp.
2. Users can cancel the management action before final submission.
3. The system provides clear, user-friendly error messages for invalid inputs (e.g.,
past dates).
4. Notifications to Renters include details of the response (e.g., accepted time,
reason for decline, or proposed alternative).
5. The system allows users to view a history of managed requests in their
dashboard.
Assumptions: 1. The system can validate viewing request actions and send notifications reliably.
2. The system supports real-time updates to request statuses and notifications.
3. The platform can handle high volumes of viewing request actions during peak
seasons without performance issues.
4. Renters receive notifications via email or in-app messages, as configured in their
account settings.

ID and Name: UC-21 Update Profile


Created By: Phùng Xuân Đạt Date Created: 26/04/25
Primary Actor: Registered User Secondary Actors: System Administrator
Description: A Registered User accesses the House Finder System, a platform connecting
renters and landlords, via the internet, navigates to the profile management section,
and updates their personal information (e.g., name, phone number, email) and, if
applicable, their VAT status for posting rental listings. The system validates the
updated information, ensures compliance with platform requirements, and saves
the changes. If the input data is invalid or the VAT status is incorrectly configured,
the system prompts the user to correct it.
Trigger: The user selects the “Update Profile” option from the system dashboard or profile
page.
Preconditions: PRE-1: The user is logged into the House Finder System with a verified and
activated account.
PRE-2: The user has permission to update their profile (applicable to all registered
user types: Renter, Landlord, Real Estate Agent).
PRE-3: The system is operational and capable of processing profile updates.
PRE-4: For VAT status updates, the user has active listings or intends to post
listings requiring VAT configuration.
Postconditions: POST-1: The user’s profile information and VAT status (if applicable) are updated
in the system.
POST-2: The system logs the profile update action with a timestamp, user ID, and
updated fields for audit purposes.
POST-3: The user receives a confirmation message indicating the successful
profile update.
Normal Flow: 21.0 Update Profile
1. The user navigates to the “Update Profile” section from the system dashboard or
profile page.
2. The system displays the user’s current profile information in an editable form
(e.g., name, phone number, email, VAT status for Landlords/Real Estate Agents).
3. The user modifies the desired fields (e.g., updates phone number, email, or
toggles VAT status per BR- 104) and submits the changes.
4. The system validates the input data (e.g., phone number format, email syntax,
VAT status eligibility per BR- 9 and BR- 46).
5. If the data is valid, the system updates the user’s profile in the database.
6. The system logs the update action, including user ID, updated fields, and
timestamp.
7. The system displays a confirmation message: “Your profile has been updated
successfully.”
Alternative Flows: 21.1 Session Expired
1. If the user’s login session expires during the update process, the system
displays: “Your session has expired. Please log in again.”
2. The system redirects the user to the login page.
3. After successful login, the system returns the user to the “Update Profile”
section with entered data preserved (if possible), resuming at step 3 of the normal
flow.
21.2 Invalid Input
1. If the user submits invalid data (e.g., incorrect phone number format, invalid
email, or incorrect VAT status), the system displays an error message: “Please
provide a valid [field name].”
2. The system retains the entered data and prompts the user to correct the issue.
3. The user corrects the input and resubmits, returning to step 4 of the normal flow.
Exceptions: 21.0.E1 System Unavailable
1. If the system is temporarily unavailable, it displays: “Service temporarily
unavailable. Please try again later.”
2a. If the user cancels the update process, the system terminates the use case.
2b. If the user retries later, the system restarts the use case from step 1
Priority: High
Frequency of Use: Approximately 150–300 profile updates per day across all user types (Renter,
Landlord, Real Estate Agent), with higher frequency during peak rental seasons
(e.g., August–October for student rentals or post-holiday periods).
Business Rules: BR-9, BR-46,BR-104
Other Information: 1. The system logs all profile update actions (successful or failed) for audit
purposes, including user ID, updated fields, and timestamp.
2. Users can cancel the profile update process at any time before submission.
3. The system provides clear, user-friendly error messages for invalid inputs (e.g.,
incorrect email format).
4. VAT status updates apply only to Landlords and Real Estate Agents and affect
how rental prices are displayed (e.g., including 10% VAT if registered).
5. Email updates require verification via a confirmation link sent to the new email
address.
Assumptions: 1. The system can reliably validate user input data (e.g., phone number, email,
VAT status).
2. The system supports secure storage and processing of updated profile
information.
3. The platform can handle high volumes of profile updates during peak seasons
without performance issues.
4. Users have access to their updated profile information in their account
dashboard.

ID and Name: UC-22 Change Password


Created By: Phùng Xuân Đạt Date Created: 26/04/25
Primary Actor: Registered User Secondary Actors: System Administrator
Description: A Registered User accesses the House Finder System, a platform connecting
renters and landlords, via the internet, navigates to the account security section,
and changes their account password to ensure security. The system validates the
current password, ensures the new password meets security requirements, and
updates the account. If the input is invalid or the current password is incorrect, the
system prompts the user to correct the issue.
Trigger: The user selects the “Change Password” option from the system dashboard or
account settings page.
Preconditions: PRE-1: The user is logged into the House Finder System with a verified and
activated account.
PRE-2: The user has permission to change their password (applicable to all
registered user types: Renter, Landlord, Real Estate Agent).
PRE-3: The system is operational and capable of processing password change
requests.
Postconditions: POST-1: The user’s account password is updated in the system.
POST-2: The system logs the password change action with a timestamp and user
ID for audit purposes.
POST-3: The user receives a confirmation message indicating the successful
password change.
POST-4: The user may be required to log in again with the new password on all
devices.
Normal Flow: 22.0 Change Password
1. The user navigates to the “Change Password” section from the system
dashboard or account settings page.
2. The system displays a password change form with fields for the current
password, new password, and confirmation of the new password.
3. The user enters the current password, new password, and confirms the new
password, then submits the form.
4. The system validates the input data:
a. Verifies the current password matches the account’s stored password.
b. Ensures the new password meets security requirements (e.g., at least 8
characters, including uppercase, lowercase, number, and special character per BR-
10).
c. Confirms the new password and confirmation field match.
5. If the data is valid, the system updates the user’s password in the database.
6. The system logs the password change action, including user ID and timestamp.
7. The system displays a confirmation message: “Your password has been changed
successfully. Please log in again.”
8. The system logs the user out of all sessions, requiring re-authentication with the
new password.
Alternative Flows: 22.1 Session Expired
1. If the user’s login session expires during the password change process, the
system displays: “Your session has expired. Please log in again.”
2. The system redirects the user to the login page.
3. After successful login, the system returns the user to the “Change Password”
section, resuming at step 2 of the normal flow.
22.2 Invalid Input
1. If the user submits invalid data (e.g., incorrect current password, new password
not meeting security requirements, or mismatched confirmation), the system
displays an error message: “Incorrect current password” or “New password must
be at least 8 characters with uppercase, lowercase, number, and special character”
or “Passwords do not match.”
2. The system retains the entered data (except the current password) and prompts
the user to correct the issue.
3. The user corrects the input and resubmits, returning to step 4 of the normal flow.
Exceptions: 22.0.E1 System Unavailable
1. If the system is temporarily unavailable, it displays: “Service temporarily
unavailable. Please try again later.”
2a. If the user cancels the password change process, the system terminates the use
case.
2b. If the user retries later, the system restarts the use case from step 1
Priority: High
Frequency of Use: Approximately 100–200 password change requests per day across all user types
(Renter, Landlord, Real Estate Agent), with higher frequency during account
creation periods or after security notifications.
Business Rules: BR- 10
Other Information: 1. The system logs all password change actions (successful or failed) for audit
purposes, including user ID and timestamp.
2. Users can cancel the password change process at any time before submission.
3. The system provides clear, user-friendly error messages for invalid inputs (e.g.,
weak password, incorrect current password).
4. Password changes trigger a notification email to the user’s registered email
address for security monitoring.
5. The system ensures passwords are securely hashed and stored in the database.
Assumptions: 1. The system can reliably validate password inputs and securely update
passwords.
2. The system supports secure session management and logout functionality across
devices.
3. The platform can handle high volumes of password change requests without
performance issues.
4. Users have access to their email for security notifications post-password change.

ID and Name: UC-23 View Listing Status


Created By: Phùng Xuân Đạt Date Created: 26/04/25
Primary Actor: Registered User Secondary Actors: System Administrator
Description: A Registered User accesses the House Finder System, a platform connecting
renters and landlords, via the internet, navigates to the listing management section,
and views the status of their posted property listings or rental needs (e.g., house,
apartment, or co-tenant request). The status can be “Pending Approval,”
“Approved,” or “Rejected,” with specific reasons provided for rejections (e.g.,
“Missing ownership certificate” per BR-HF-34). The system retrieves and displays
the status and any associated details, ensuring the user is informed of their listing’s
current state.
Trigger: The user selects the “View Listing Status” option from the system dashboard or
listing management page.
Preconditions: PRE-1: The user is logged into the House Finder System with a verified and
activated account.
PRE-2: The user has permission to view listing statuses (applicable to Landlord or
Real Estate Agent roles).
PRE-3: The user has at least one listing (active, pending, or rejected) in the system.
PRE-4: The system is operational and capable of retrieving listing status
information.
Postconditions: POST-1: The system displays the current status of the selected listing(s) along with
any rejection reasons, if applicable.
POST-2: The system logs the status view action with a timestamp, user ID, and
listing ID for audit purposes.
POST-3: The user is informed of the listing’s status and can take further actions
(e.g., resubmit a rejected listing).
Normal Flow: 23.0 View Listing Status
1. The user navigates to the “View Listing Status” section from the system
dashboard or listing management page.
2. The system displays a list of the user’s listings with their respective statuses:
“Pending Approval,” “Approved,” or “Rejected.”
3. The user selects a specific listing to view detailed status information.
4. The system retrieves and displays the listing’s status and, if rejected, includes
the specific reason (e.g., “Missing ownership certificate” per BR- 34).
5. The system logs the status view action, including user ID, listing ID, and
timestamp.
6. The system provides options for further actions (e.g., resubmit for rejected
listings, edit for approved listings).
Alternative Flows: 23.1 Session Expired
1. If the user’s login session expires while viewing the listing status, the system
displays: “Your session has expired. Please log in again.”
2. The system redirects the user to the login page.
3. After successful login, the system returns the user to the “View Listing [Link]”
section, resuming at step 2 of the normal flow.
23.2 No Listings Available
1. If the user has no listings in the system, the system displays: “You have no
listings to view. Create a new listing to get started.”
2. The system provides an option to navigate to the “Upload Listing” section (UC-
18).
3. The use case terminates.
Exceptions: 23.0.E1 System Unavailable
1. If the system is temporarily unavailable, it displays: “Service temporarily
unavailable. Please try again later.”
2a. If the user cancels the action, the system terminates the use case.
2b. If the user retries later, the system restarts the use case from step 1.
23.0.E2 Listing Removed by Administrator
1. If the selected listing has been permanently removed by the System
Administrator (e.g., for policy violation), the system displays: “This listing has
been removed by the administrator and is no longer available.”
2. The system removes the listing from the user’s viewable list and redirects the
user to the “My Listings” section.
3. The use case terminates for that listing.
Priority: Medium
Frequency of Use: Approximately 400–700 listing status views per day across Landlord and Real
Estate Agent users, with higher frequency during peak rental seasons (e.g.,
August–October for student rentals or post-holiday periods) or after listing
submissions.
Business Rules: BR- 34
Other Information: 1. The system logs all listing status view actions for audit purposes, including user
ID, listing ID, and timestamp.
2. Users can view statuses for multiple listings in a single session via the “My
Listings” section.
3. The system provides clear, user-friendly messages for each status and detailed
rejection reasons (e.g., “Please upload a valid ownership certificate and resubmit”).
4. For rejected listings, the system suggests corrective actions and links to the
“Manage Listing” section (UC-19) for resubmission or editing.
5. The system displays expiration dates for approved or expired listings to inform
users of renewal deadlines.
Assumptions: 1. The system can accurately retrieve and display listing status information in real-
time.
2. The System Administrator provides precise and actionable reasons for listing
rejections.
3. The platform can handle high volumes of status view requests during peak
seasons without performance issues.

ID and Name: UC-24 View Tax Compliance Status


Created By: Phùng Xuân Đạt Date Created: 26/04/25
Primary Actor: Registered User Secondary Actors: System Administrator
Description: A Registered User accesses the House Finder System, a platform connecting
renters and landlords, via the internet, navigates to the tax compliance section, and
views their tax compliance status. This includes notifications if their rental income
exceeds 100 million VND per year (per BR-109, applicable only to users posting
listings) or VAT information for foreign suppliers (per BR-07). The system
retrieves and displays the tax status, any relevant notifications, and actionable
guidance, ensuring users are informed of their tax obligations.
Trigger: The user selects the “View Tax Compliance Status” option from the system
dashboard or account settings page.
Preconditions: PRE-1: The user is logged into the House Finder System with a verified and
activated account.
PRE-2: The user has permission to view tax compliance status (applicable to
Landlord or Real Estate Agent roles who post listings).
PRE-3: The system is operational and capable of retrieving tax compliance data.
PRE-4: The user has at least one active or past listing associated with their account
to trigger tax compliance tracking.
Postconditions: POST-1: The system displays the user’s tax compliance status, including any
notifications about rental income exceeding 100 million VND/year or VAT details
for foreign suppliers.
POST-2: The system logs the status view action with a timestamp, user ID, and
relevant tax data for audit purposes.
POST-3: The user is informed of their tax obligations and provided with guidance
for compliance, if applicable.
Normal Flow: 24.0 View Tax Compliance Status
1. The user navigates to the “View Tax Compliance Status” section from the
system dashboard or account settings page.
2. The system retrieves the user’s tax compliance data, including:
a. Rental income tracked from listings (per BR- 109).
b. VAT status and details for foreign suppliers, if applicable (per BR-107).
3. The system displays the tax compliance status:
a. If rental income exceeds 100 million VND/year, a notification is shown: “Your
rental income has exceeded 100 million VND/year. Please declare taxes as
required.”
b. If the user is a foreign supplier, VAT details are displayed (e.g., “VAT
registered” or “VAT exempt”).
c. If no issues, the system shows: “Your account is tax compliant.”
4. The system provides guidance or links to resources for tax declaration or VAT
compliance, if applicable.
5. The system logs the status view action, including user ID, tax data accessed, and
timestamp.
6. The system displays actionable options (e.g., “Contact Support” or “View Tax
Declaration Guide”).
Alternative Flows: 24.1 Session Expired
1. If the user’s login session expires while viewing the tax compliance status, the
system displays: “Your session has expired. Please log in again.”
2. The system redirects the user to the login page.
3. After successful login, the system returns the user to the “View Tax Compliance
Status” section, resuming at step 2 of the normal flow.
24.2 No Listings or Tax Data
1. If the user has no listings or no tax-relevant data (e.g., no rental income or VAT
status), the system displays: “No tax compliance data available. Post a listing to
track tax obligations.”
2. The system provides a link to the “Upload Listing” section (UC-16).
3. The use case terminates.
Exceptions: 24.0.E1 System Unavailable
1. If the system is temporarily unavailable, it displays: “Service temporarily
unavailable. Please try again later.”
2a. If the user cancels the action, the system terminates the use case.
2b. If the user retries later, the system restarts the use case from step 1
Priority: High
Frequency of Use: Approximately 200–400 tax compliance status views per week across Landlord
and Real Estate Agent users, with higher frequency at year-end tax reporting
periods (e.g., December–January) or during peak rental seasons (e.g., August–
October).
Business Rules: BR- 107, BR-109
Other Information: 1. The system logs all tax compliance status view actions for audit purposes,
including user ID, accessed tax data, and timestamp.
2. Users can access the tax compliance status section multiple times to monitor
updates.
3. The system provides clear, user-friendly notifications and guidance for tax
compliance (e.g., links to tax declaration forms or contact details for tax
authorities).
4. Notifications for exceeding 100 million VND/year are sent via email and
displayed in the user’s dashboard.
5. VAT details for foreign suppliers are displayed only if the user has configured
their account as a foreign supplier.
Assumptions: 1. The system can accurately track and calculate rental income from listings to
determine tax compliance thresholds.
2. The system integrates with reliable data sources to verify VAT status for foreign
suppliers.
3. The platform can handle high volumes of tax compliance status views during
peak tax reporting periods without performance issues.
4. Users have access to their tax compliance status and related notifications in their
account dashboard for easy monitoring.

ID and Name: UC-18 Upload Listing Of Post


Created By: Phùng Xuân Đạt Date Created: 26/04/25
Primary Actor: Registered User Secondary Actors: System Administrator
Description: A Registered User accesses the House Finder System, a platform connecting
renters and landlords, via the internet, navigates to the listing creation section, and
uploads a new property listing (e.g., house, apartment) or a rental need (e.g.,
finding co-tenants). The listing includes a precise address, rental price (with 10%
VAT if applicable), at least one image, and a detailed description. The system
validates the input data and ensures the user has a valid listing package. If the input
is invalid or the package is not active, the system prompts the user to correct the
issue.
Trigger: The user selects the “Upload Listing” option from the system dashboard or listing
management page.
Preconditions: PRE-1: The user is logged into the House Finder System with a verified and
activated account.
PRE-2: The user has permission to upload listings (applicable to Landlord or Real
Estate Agent roles).
PRE-3: The user has an active listing package (free or premium) with available
listing slots.
PRE-4: The system is operational and capable of processing listing uploads and
image storage.
Postconditions: POST-1: The new listing is successfully uploaded and published on the platform.
POST-2: The system logs the listing upload action with a timestamp, user ID, and
listing ID for audit purposes.
POST-3: The user receives a confirmation message confirming the listing has been
published.
POST-4: The listing is visible to other users (e.g., Renters) on the platform.
Normal Flow: 18.0 Upload Listing of Post
1. The user navigates to the “Upload Listing” section from the system dashboard
or listing management page.
2. The system checks if the user has an active listing package with available slots.
3. The system displays a listing creation form with required fields: precise address,
rental price (including 10% VAT if applicable), at least one image, detailed
description, and optional fields (e.g., amenities, property type).
4. The user fills out the form, uploads at least one image, and submits the listing.
5. The system validates the input data (e.g., address format per BR-58, image
format and size per BR-90, description length, and price including VAT per BR-
102).
[Link] the data is valid, the system saves the listing in the database and publishes it on
the platform.
The system logs the upload action, including user ID, listing ID, and timestamp.
The system displays a confirmation message: “Your listing has been successfully
published.”
Alternative Flows: 18.1 Session Expired
1. If the user’s login session expires during the listing creation process, the system
displays: “Your session has expired. Please log in again.”
2. The system redirects the user to the login page.
3. After successful login, the system returns the user to the listing creation form
with entered data preserved (if possible), resuming at step 4 of the normal flow.
18.2 Invalid or Incomplete Input
1. If the user submits the form with invalid or missing data (e.g., no image
uploaded, invalid address format, or missing price), the system displays an error
message: “Please provide a valid [field name]” or “At least one image is required.”
2. The system retains the entered data and prompts the user to correct the issue.
3. The user corrects the input and resubmits, returning to step 5 of the normal flow.
18.3 No Active Listing Package
1. If the user does not have an active listing package or has no remaining slots, the
system displays: “You need an active listing package to post. Please purchase a
package.”
2. The system redirects the user to the “Purchase Listing Package” section (UC-
16).
3. After purchasing a package, the user is returned to step 3 of the normal flow.
Exceptions: 18.0.E1 System Unavailable
1. If the system is temporarily unavailable, it displays: “Service temporarily
unavailable. Please try again later.”
2a. If the user cancels the upload process, the system terminates the use case.
2b. If the user retries later, the system restarts the use case from step 1.
18.0.E2 Image Upload Failure
1. If the image upload fails (e.g., file too large, unsupported format), the system
displays: “Image upload failed. Please upload a valid image (e.g., JPG, PNG, max
5MB).”
2. The system retains other entered data and prompts the user to upload a valid
image.
3. The user uploads a new image and resubmits, returning to step 5 of the normal
flow.
Priority: High
Frequency of Use: Approximately 500–800 listing uploads per day across Landlord and Real Estate
Agent users, with higher frequency during peak rental seasons (e.g., August–
October for student rentals or post-holiday periods).
Business Rules: BR- 5, BR- 8, BR- 58, BR- 90, BR- 93, BR- 102
Other Information: 1. The system logs all listing upload actions (successful or failed) for audit
purposes, including user ID, listing ID, and timestamp.
2. Users can cancel the listing upload process at any time before submission.
3. The system provides clear, user-friendly error messages for invalid inputs (e.g.,
missing fields, unsupported image formats).
4. Listings are published immediately after validation, unless flagged for manual
review by the System Administrator (e.g., for suspicious content).
4. The description field is limited to 1000 characters to ensure concise input.
Assumptions: 1. The system can validate address formats, image uploads, and price calculations
reliably.
2. The system supports secure storage and display of uploaded images.
3. The platform can handle high volumes of listing uploads during peak seasons
without performance issues.
4. Users have access to their uploaded listings in their account dashboard for
management (e.g., edit, delete).

You might also like