Evaluations of Nonfunctional Requirements of Ride-hailing App

A mobile ride-hailing application might feature a flawless architectural design, but if the map stutters during navigation, driver markers freeze under poor connectivity, or the background process aggressively drains the device battery, the system has failed the user. These failures typically trace back to decisions made deep in the mobile client stack regarding hardware utilization, network protocols, and rendering pipelines.

Behind every reliable ride lies a complex series of architectural trade-offs:

• Should the system poll GPS aggressively to guarantee 5-meter accuracy, or decrease polling frequency to extend battery life?

• Is it better to block the UI during a network drop, or allow optimistic state transitions that might conflict with the server?

• When device memory is critically low, should the application evict map tiles or reduce the location history buffer?

These decisions require a strict System Design evaluation. In this lesson, we will explore how to optimize location tracking, balance critical nonfunctional requirements (NFRs) against hardware limits, enforce security, and ensure accessibility for all users.

Performance and location accuracy

Performance in a mobile ride-hailing app is quantified across three specific metrics:

1. Time-to-first-location-fix (TTFF): The exact duration from application launch to the acquisition of a usable GPS coordinate for the pickup location.

2. Map rendering smoothness: The sustained frame rate (ideally 60 FPS) and visual continuity of the driver marker moving along the map interface.

3. Interaction responsiveness: The measured network latency between a user action (such as confirming a pickup) and the system's explicit UI ...