soc-pe-bot
commented
10 months ago Team's Response
We intend to use NRIC for appointments since it is a unique identifier for both patient and doctors to ensure accuracy of the patient and doctor being entered in. Typing the NRIC also would not be an issue for fast typers which this application is meant for (Feature of our target user).
Tester's suggestion is still valid. This can be a potential feature enhancement in a future version.
However the suggested work around has its limitation as well. Even if we were to use the index of the patient and doctor to add appointments, the user would have to scroll through the list to find the index. Also the NRIC would be visible right away in the patient/doctor card.
Since the absence of the suggested implementation does not hinder the user from accessing any of the features that the UG states, we will propose to have this as Not In Scope.
With the consideration of our target users being fast typer, the severity we propose to change to Low as typing 10 characters more wouldn't be an inconvenience to the user.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** Considering the scope of Low to be: Unlikely to affect normal operations of the product Appears only in very rare situations and causes a minor inconvenience only. While the scope of Medium to be: Causes occasional inconvenience to some users but they can continue to use the product. I believe this bug falls under Medium as all users will be affected by this choice to use NRIC compared to index. Regarding the target user: I was referring to the following module requirement: https://nus-cs2103-ay2324s1.github.io/website/admin/tp-pe.html#pe-phase-1-part-i-product-testing-60-minutes  This highlights that input formats should be optimised so that the process can be quick and fast. Having to input the entire IC is not very convenient for users. A slight mistake in the input means that my command would not be valid or I would accidentally schedule the wrong patient/doctor without noticing which would be a larger problem, especially because there is no confirmation message to see the name of the patient/doctor.   Hence, it would be much more convenient for users to use an index and show the name of the patient/doctor in the output message or in the confirmed appointment. If the concern is having to scroll through, I would suggest implementing a find function that allows users to find the index using the NRIC (partial patching though so users do not need to key in the entire NRIC as they tend to be very unique so half the NRIC should give 5 results through which they can then scroll through and find their patient/doctor). This helps users confirm the name of their patient/doctor before they use the index to schedule the appointment so that they don't accidentally schedule with the wrong patient/doctor.
Right now users need to find the IC of the patient and doctor to be able to schedule an appointment, this is not common knowledge and is too long of an input. A suggestion is to use their index in the list instead.