Team's Response

Hi, thank you for your bug report.

This is a good suggestion, but the team would like to reject this as Not In Scope.

The LTA API does not provide the full address with zip code for each carpark. Therefore, for this feature to work, it would require a Geofencing API, such as the one below:

https://developers.google.com/location-context/geofencing

As such, we would see this as not in scope as described below:

To break it down point by point:

if fixing the feature flaw is essential for the app to be reasonably useful: The app still helps you "choose where to park" given that usually drivers know the rough address of the place they are driving to. In your example, instead of doing filter clementi, one could do filter clementi ave 3, if they are driving around that area, which will narrow the search down to carparks within immediate proximity. Therefore, this feature is still reasonably useful to look for available carparks in whatever area you want to drive to.
if the feature is implemented to work in a certain way but it could have been implemented to work in a better way (from the end-user's point of view) without much additional effort: The important section here is without much additional effort: using a Geofencing API for every carpark on the list will be prohibitively expensive and incur much development time (interfacing with a whole new API, parsing based on coordinate data). We contest that this feature, while nice to have, will require much additional effort, and thus is out of scope.

We would then mark this as a feature to be rolled out in future versions, rather than something critical to this current version, as shown below:

The second point (the user cannot attempt to use the missing feature) is satisfied, and thus qualifies for the not in scope response.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

[x] I disagree

Reason for disagreement: The argument given presents a straw man fallacy.

The entire basis of the argument is "the LTA API does not support this and therefore we do not support this" - this in fact accentuates my point that this application at its current state provides no service at all(just fetches and presents data)

First, let me address your points below

if fixing the feature flaw is essential for the app to be reasonably useful: The app still helps you "choose where to park" given that usually drivers know the rough address of the place they are driving to.
In your example, instead of doing filter clementi, one could do filter clementi ave 3, if they are driving around that area, which will narrow the search down to carparks within immediate proximity.
Therefore, this feature is still reasonably useful to look for available carparks in whatever area you want to drive to.

Please try running filter clementi ave 3 - you get 20 results due the relaxed nature of your search function - which is precisely why I am suggesting zip codes instead
With this 20 results that are sorted by carpark_id(again, makes no sense) I argue that it is not reasonably useful as you claim
In addition, clementi ave 3 is a nuanced example, I can counter present a case where your application is not at all useful: consider people who are headed to malls e.g. clementi mall - searching by a mall name does notk

if the feature is implemented to work in a certain way but it could have been implemented to work in a better way (from the end-user's point of view) without much additional effort: 
The important section here is without much additional effort: 
using a Geofencing API for every carpark on the list will be prohibitively expensive and incur much development time (interfacing with a whole new API, parsing based on coordinate data). 
We contest that this feature, while nice to have, will require much additional effort, and thus is out of scope.

Whatever I'm suggesting is actually quite easy to implement, but yet not considered - you literally only need two implementations
getDistanceBetweenByLatLng(start_lat, start_lng, end_lat, end_lng) and getLatLngByZip(zip_code)
getDistanceBetweenByLatLng is one google search away; it is very easily implemented
getLatLngByZip is easily obtainable by 1 API call to Google's Geocoding API(literally 1 call)https://maps.googleapis.com/maps/api/geocode/json?address=YOUR_ZIP&key=YOUR_API_KEY
A very relaxed estimation of implementation time is at most 2 hours by 1 person

Next, presenting my argument

My argument is that there is a huge mismatch between target users, user stories and actual implementation and the application in general is not reasonably useful.

The application seeks to help drivers(easy assumption here is they are headed somewhere) find carpark availability, presenting them with live carpark availability data.

In order to do this, you must consider "distance from destination" and build around it - I find it quite weird that there is no sort by distance functionality which seems like a very minimal feature.

Even if we do not have a sort by distance feature, at the very minimum you need to allow searching by destination through zip codes and not address name
This is especially the case because of your relaxed search function(as mentioned above)

Here are some other considerations problems:

The application does not actually feed live data

Data is fetched when the app starts, not when the user searches by entering find or filter so it actually is not live data unlike what the user stories suggest
If i leave the application open for 15mins, and i run filter clement ave 1, i get data from 15mins ago

The last argument is that the actual unit in applications for location is by geolocation i.e. lat lng while destination is by zip code - it is in fact unnatural to use name's for destination

:question: Issue severity

Team chose [severity.Low] Originally [severity.High]

[x] I disagree

Reason for disagreement: Should be severity.High - as described above, the app actually does not serve its purpose of helping drivers find parking for a given location

winston-lim / pe