bingsen0806
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.
Duplicate status (if any):
--
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.
[original: nus-cs2103-AY2122S2/pe-interim#212] [original labels: severity.Medium type.FeatureFlaw]