nus-pe-bot
commented
2 years ago Team's Response
We would like to thank you for your suggestion. This issue is very opinion-based, as our team has actually spent many hours considering the design of this feature thoroughly. We would like to share with you why we made this decision when designing our feature, and why we do not consider it as a feature flaw.
First of all, our use case for request feature is that the librarian will always be reminded to notify all requesters when one copy of the book is returned. This is explained partly in the FAQ of UG, as shown below. Doing it this way is also an essential part of maintaining data integrity, as explained in our “Elimination of Data Inconsistency” subsection of “Efforts” section in DG (not screenshot below because it is lengthy).
Secondly, practically speaking in a real scenario, libraries have many copies of the same book, especially textbooks (e.g. 10-20 copies). Our app enforces the condition that a book can be requested only when it has no available copy. So, if there are 15 copies of book A, all borrowed, as long as any of the 15 copies is returned, the librarian will notify all requesters and the all “requested by” tags will be removed, hence number of requesters reset to 0. If the loan period is 14 days, on average more than 1 copy is returned every day (the point here is that requester count is reset frequently). It is extremely rare that 15 patrons will request for the same book in a single day, thus breaking our maximum limit.
Furthermore, a very important point we considered while designing this feature is that "it is unreasonable to not limit the number of requesters", because if that’s the case then for a book with only 1 copy but with 15 requests, the requester may need to wait for around half to one year before borrowing, which is unrealistic and defeats the purpose of requesting (should be the librarian's job to buy in more books). If a librarian use our app frequently and notices that a certain book A often exceeds maximum requests, it can serve as a sign for her to purchase more copies of the book, hence this is a feature not a bug.
Initially, we have tried other alternatives of limiting requesters, for example limiting number of requesters to 3 (which will be too low for books with 10 copies), and limit to 10 (which is too much for books with only 1 copy). Either way, these can also be reported as feature flaws. Our team has made a rational decision of picking the middle line, that is, the maximum requesters should scale accordingly to number of copies. In conclusion, we would like to politely reject the tester’s justification as to why our limit for requesters is unreasonable, because our team has considered multiple limit options and chose this is a design choice that we deliberately made, and deem it as the most suitable choice.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: ## Points and my response
- They made the claim that it is unreasonable to not limit the number of requesters", because if that’s the case then for a book with only 1 copy but with 15 requests, the requester may need to wait for around half to one year before borrowing, which is unrealistic and defeats the purpose of requesting (should be the librarian's job to buy in more books)."
This is an irrelevant point to the point I made.
I made the claim that "An expectation is to have a bound based on the user - each user can only have at most one request per unique book.", which not only fits into their use case, but also not not addressed by this point. I am not asking to not limit, but rather have the limit be the number of users, rather than number of books. It fits within what the team has said in their thought processes - not unbounded, also provides feedback to the librarian that a book is popular.
The main difference between my proposed expectation and the current implementation is the case where there are say, 10 books, all currently borrowed, and say, 12 requesters. Then the librarian would have to manually keep track of the remaining 2 requesters! Which defeats the specific use case they have referenced, here.
- They also argue that "First of all, our use case for request feature is that the librarian will always be reminded to notify all requesters when one copy of the book is returned."
Again, this is an irrelevant point to what I'm saying. I'm simply saying that bounding the number of requesters to the number of copies is silly, and nothing about who is requesting, or how requesters are notified.
Summary
All in all, the website denotes a feature flaw as the following.
Given that in the specified use case, a librarian would have to manually keep track of requests in normal usage (10 books, 12 requesters, a very reasonable scenario), the app does not fully support this specified use case.
The website denotes medium and low severity as the following:
To this end, I think it's reasonable to interpret as a low severity case, since for most NUS libraries (which is the target user), the number of copies likely outweigh requesters.
:question: Issue severity
Team chose [severity.Low]
Originally [severity.Medium]
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
The number of book requests are currently bounded by the number of books with that ISBN. The rationale is that "There is no need to have too many book requests because ultimately each copy of the book can only be borrowed by one patron".
While that is reasonable in a sense, in practical applications, the number of requesters almost always outweigh the number of books - that is, after all, the purpose of putting in a request. An expectation is to have a bound based on the user - each user can only have at most one request per unique book.
It is also specified in the user stories where a librarian would like to take note of book requests from students (as in a plural sense), and it is not hard to imagine a popular book being desired by multiple individuals.