Functional Scenarios:

Functional scenario 1:

The user action consists of opening AndeSpace during a one-hour gap and pressing Search on the “Where do you want to go?” screen, where the time window is automatically set from the current time to one hour ahead and the “Close to me” option is enabled by default. The execution context is a student physically located on campus with GPS permissions granted and an active internet connection. The system response is that the app reads the user’s current location, sends a request to the backend for classrooms available during that specific interval, prioritizes nearby rooms, and displays a results list including room code, capacity, and exact availability window so the student can immediately evaluate options without physically checking classrooms.

Functional scenario 2:

The user action consists of tapping the filter icon from the results screen, selecting the Building filter, choosing “ML” and “Floor 5” from the dropdown menus, and pressing Apply Filters. The execution context is an already loaded results list for a previously selected time interval. The system response is that the app refreshes the results to show only classrooms matching the selected building and floor while keeping the original time window unchanged; if the user later selects “Clean selection” and reapplies, the system removes the building constraints and restores the broader campus-wide results accordingly.

Functional scenario 3:

The user action consists of opening Filters, selecting the Times option, setting a custom interval such as “Since 12:30” and “Until 13:30,” and pressing Apply. The execution context is a student planning around two classes and needing a precise availability window. The system response is that the app validates the selected interval, prevents submission if the time range is invalid, and then queries or re-filters backend availability data to ensure that all displayed rooms are fully free during the entire specified interval, not partially overlapping, before updating the results list.

Functional scenario 4:

The user action consists of selecting a specific room from the results list, such as “ML 517,” to view more detailed information before deciding to walk there. The execution context is a previously generated results list for a given time window. The system response is that the app opens a room detail view showing building, floor, capacity, and a breakdown of availability blocks across the week; after reviewing the details, when the user navigates back, the app returns them to the same scroll position in the results list to preserve continuity in their decision-making process.

Functional scenario 5:

The user action consists of navigating to My Schedule, selecting Load Schedule, importing an ICS file or manually adding a class by entering its start time, end time, and day(s), and confirming the action. The execution context is a logged-in user who wants personalized planning features and has access to their academic schedule file. The system response is that the app parses the imported data into structured class blocks displayed in the My Schedule view as a weekly timetable; manually added classes appear immediately, and if the user later selects Reload the schedule, the system updates the timetable while maintaining data consistency within the user’s profile.

Functional scenario 6:

The user action consists of pressing the “Give me Suggestions” button after having a valid schedule loaded in My Schedule. The execution context is a schedule that contains identifiable gaps between classes and an active backend connection to retrieve real-time availability data. The system response is that the app automatically detects those gaps, queries the backend for classrooms that are fully available during each detected interval, prioritizes rooms near the previous or next class location, and generates a proposed schedule draft with suggested rooms assigned to each gap; the user can then accept or decline the draft, and upon acceptance the My Schedule view updates to reflect the suggested study sessions.

Functional scenario 7:

The user action consists of pressing the AndeBot assistant button from the home screen and typing, "I need a quiet room for 4 people with a whiteboard for tomorrow morning," the execution context is a student logged into the app off-campus with a "first-time user" profile state and no prior booking history, and the system response is the activation of the Smart Chatbot feature to parse the natural language intent, which then automatically updates the app’s search filters (Date: Tomorrow, Capacity: 4, Tag: Whiteboard) and redirects the user to a pre-filtered results list.

Functional scenario 8:

The user action consists of navigating to the "Classrooms" dashboard on a Tuesday afternoon to find a study spot, the execution context is a logged-in state where the system predicts how useful buildings would be for the user during this specific hour, and the system response is the triggering of the Smart Recommendation feature, which analyzes these usefulness of buildings to display a "Suggested for You" section featuring a one-tap booking for the user’s most recommended rooms (W 405).

Functional scenario 9:

The user action consists of opening the "Scan Room" tool and pointing the camera at the room number plaque of classroom ML 511, the execution context is a student physically in the ML building with active camera permissions and GPS coordinates confirming their position in front of the door, and the system response is the activation of the Camera OCR feature to extract the text "ML 511," query the live database, and overlay a digital status card on the screen showing the room is reserved for "Vector Calculus" until 3:30 PM.

Functional scenario 10:

The user action consists of asking the chatbot, "Where should I practice my presentation next week?" the execution context is a user profile with a history of booking rooms equipped with projectors and the system response is the integration of the Smart Chatbot with the Smart Recommendation engine to interpret the request, cross-reference preferred room types with future availability, and reply with specific suggestions like, "W 301 has the projector you usually use and is free next Tuesday,".

Functional scenario 11:

The user action consists of tapping the "Report Issue" flag within the Room Detail view for "ML 202" and selecting the checkbox "Missing/Incorrect Attribute: No Whiteboard," the execution context is a student who just entered a room filtering by rooms that have "Whiteboard" tag only to find the wall is empty. The system response is the immediate triggering of the Smart Recommendation engine to lower the confidence score of the "Whiteboard" attribute for ML 202.

Functional scenario 12:

The user action consists of tapping the "Room is Occupied" button within the active reservation view for room ML 302 and selecting "Unscheduled Class in Session" as the reason, the execution context is a student who has just arrived at their reserved location only to find a professor lecturing inside, while the app’s internal state shows the room as "Reserved" and the user's GPS confirms they are standing at the correct door, and the system response is downgrading the fitness of this room for recommendation to future reservations at that time.