Card 08/ 09
Practice: Sorting a Ride-Sharing App's Requirements
Eight requirements, two lists, and one too vague to keep as written.
Three requirement skills meet on one product here: sorting requirements into functional and non-functional, naming the quality each non-functional one constrains, and spotting a requirement too vague to design for.
A ride-sharing app has these eight requirements. Sort each one, name the quality for each non-functional one, and find the one that cannot be kept as written.
- Riders request a ride from their current location.
- Drivers accept or decline a request.
- The rider sees the driver's position update on a map.
- A completed trip's record is never lost.
- The app copes with New Year's Eve, at eight times a normal night's requests.
- The fare estimate appears in under 500 ms for 99% of requests.
- Requests keep working when one data centre fails.
- The app should feel responsive.
Check your sorting
| Number | Kind | Quality |
|---|---|---|
| 1 | Functional | None |
| 2 | Functional | None |
| 3 | Functional | None: a live map is a feature |
| 4 | Non-functional | Durability |
| 5 | Non-functional | Scalability |
| 6 | Non-functional | Latency |
| 7 | Non-functional | Availability |
| 8 | Non-functional | Latency, but not measurable |
Number 3 is the trap: the map updates live, and it is still a feature. The quality inside it, how fresh the position must be, would be its own line. Number 8 names no number, percentile or load. Rewrite it in the shape of number 6, for example "every screen responds in under 300 ms for 95% of taps", or drop it.
← → move through sections and cards