| 1 |
API timeout during peak demand |
Performance, Availability, Scalability |
It is 12:50 PM between classes. The app is querying room availability from the university API. High concurrent usage |
The API response exceeds the timeout threshold due to overload |
The app stops waiting after a defined timeout, displays last cached availability, and logs the incident for monitoring. UI remains responsive |
| 2 |
Offline search attempt |
Eventual Connectivity, Usability, Resilience |
The student opens the app in a basement with no internet connection. The app only stores locally: favorites, reservations, and recently viewed rooms (no full availability cache) |
The user attempts to search for a new available room not previously stored locally |
The app detects lack of connectivity before sending the request, informs the user that real-time availability requires internet access, allows access to locally stored favorites/reservations, and automatically retries availability queries once connectivity is restore |
| 3 |
Simultaneous room reservation attempt |
Concurrency control, Data integrity, Consistency |
Two students view the same room as available for the same time window |
Both attempt to reserve the room within seconds of each other |
The backend enforces transactional locking, confirms reservation for the first valid request, and immediately updates availability state for the second user with a clear notification. |
| 4 |
User disputes incorrect occupancy status |
Auditability, Accountability |
A student claims a room was marked “available” but was actually occupied |
The user submits a dispute report through the app |
The system stores timestamped logs of schedule inference, user reports, and confidence levels, allowing traceability and review |
| 5 |
Privacy-Preserving Analytics Export |
Privacy, Anonymity, Security |
The engine is aggregating daily usage data (routes and heatmaps) for campus operations |
A stakeholder requests a granular report on student flow in a specific building |
The system applies differential privacy or k-anonymity algorithms to ensure that individual students cannot be re-identified from the aggregated movement patterns before export |
| 6 |
Resource-Aware Navigation |
Performance, Usability, Resilience |
The student is following a real-time route to a study room with the screen active |
The device's battery drops below 15% and enters "Power Saving Mode" |
The app detects the OS flag, reduces GPS polling frequency, and switches from a high-fidelity 2D map with text-based directions to minimize CPU/GPU drain |
| 7 |
Map routing service unavailable |
Reliability, Fault tolerance |
The student selects a room and opens navigation to reach it quickly between classes. |
The map tiles or routing provider fails |
The app switches to a fallback route view with text-only directions (building-to-building steps), shows an “Map unavailable” notice, and keeps the room details accessible. It retries in the background and restores the map automatically when the service returns. |
| 8 |
University API response format change |
Interoperability, Modifiability, Robustness |
The backend is parsing the university schedule feed to compute occupied vs free rooms for the current time window. |
The API changes a field name/structure or returns a new version that breaks parsing. |
The system detects parsing failure, uses a versioned adapter (fallback parser if available), and if it cannot recover it serves the last known valid availability with a “limited data” label. It logs an alert for developers and prevents the app from crashing or showing empty results without explanation. |
| 9 |
Corrupted local cache for favorites or recent rooms |
Recoverability, Resilience, Data integrity |
The student opens the app; it loads favorites and recently viewed rooms stored locally. |
Local storage becomes corrupted (e.g., unexpected shutdown, OS cleanup, partial write). |
The app detects invalid data (failed parse/validation), clears only the affected cache entries, restores safe defaults (empty favorites/recent), and continues. It shows a lightweight message (“Local data refreshed”) and allows the user to re-add favorites. |
| 10 |
Accessibility with large text and screen reader |
Accessibility, Usability |
A student uses system large text and a screen reader to browse available rooms. |
The user increases font size and navigates using screen reader gestures. |
The UI reflows without overlapping or clipped text, maintains adequate tap targets, and provides accessible labels for key elements (room name, availability confidence, distance, time window). The screen reader announces the most important info in a logical order. |
| 11 |
Recommendation transparency |
Explainability, Learnability, Trust |
The app recommends rooms based on proximity, time available, and past behavior. |
The user taps “Why this recommendation?” or marks the suggestion as not useful. |
The app shows concise reasons (e.g., near next class, matches quiet preference, fits available time) and offers quick preference controls (study/group/rest, noise level). It records the feedback to adjust future recommendations without blocking the current task. |
| 12 |
Low data connection mode |
Resource efficiency, Adaptability, Performance |
The student is browsing rooms and may open navigation while on a limited data plan. |
The OS/network reports a metered connection or Low Data Mode is enabled. |
The app reduces data usage by disabling auto-loading maps/images, using smaller payloads, and loading results in smaller batches. It keeps the core room list and text directions working and provides a toggle to load the full map only if the user requests it. |