nus-se-bot
commented
1 week ago Team's Response
Thank you for your feedback, however, after reviewing your comment, we believe that your suggestion is not in scope for the current development phase of the product. This is because our find command is specifically designed to only search for contacts by their names.
This is also clearly specified in the UG(as provided above) and the error message, which highlights that our find command only works for names of a contact. While it is useful to be able to search for other fields, this is a good enhancement on top of the current feature, therefore we believe that it is not in scope. But still, thank you for your suggestion.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: I disagree that this feature flaw is NotInScope as restricting the find command to only names severely undermines the usefulness of the app and thus, it is definitely a high priority flaw to fix.
For this discussion, let's focus on the NRIC field. Allowing users to search by the NRIC field is crucial for the app to be reasonably effective. Given that NRIC is a unique identifier that can precisely identify a student, a find by NRIC feature will be able to precisely and effectively identify a student contact. As such, find by NRIC is an essential feature with numerous real world use cases such as:
- For example, when a student is paying fees/enrolling for new courses, the student will likely provide his/her NRIC for identification and verification purposes. The admin staff would then need to quickly search for the student’s record using the NRIC to retrieve and cross-check a student’s details, ensuring that there are no discrepancies in the records.
- Another example is when two or more students have the same name, searching by NRIC ensures the tuition centre retrieves the correct student’s records without confusion.
- Another example is when students may write only thier NRIC on their test/exam papers due to the enforcement of blind grading (where the writing of name is not allowed to avoid any bias). In such scenarios, the staff will have to find by NRIC and link the exam paper to the correct student record and ensure that the right results are attributed to the correct individual based on the NRIC.
Therefore, the absence of a find by NRIC feature severely limits the app's functionality and reduces its practicality in real-world applications, causing the app to fail to meet users’ need for easy information retrieval. As such, the limited functionality of the find command is a critical flaw that should have been addressed with high priority.
Furthermore, other features, such as sort and filter, already have support for multiple fields. So I believe that the team does have the proficiency to extend the find command without much difficulty. As such, it is reasonable to expect that the important feature of find by NRIC should have already been implemented in previous iterations.
In fact, extending the find command to other fields should have been prioritised over the less important tasks that the team has done in previous iterations, such as purely cosmetic UI changes. Looking at the release notes of this app on GitHub, I noticed that the team allocated substantial time working on purely cosmetic UI changes to make the app more visually appealing (e.g. fancy popups, colour scheme, scrollbar, margin and padding). Another non-essential feature that the team has done is to allow users to use keyboard shortcuts to close popup windows. (Evidence from PRs). While such UI changes and keyboard shortcuts do its value, I strongly believe that extending the find command to search by NRIC is a far more important and impactful feature to work on. As such, prioritising extending the find command would have been a better use of development resources, ensuring the app meets the practical needs of its users more effectively. Therefore, this feature flaw should definitely not be classified as NotInScope
I have attached screenshots of the app’s release notes for v1.3 and v1.5 which indicates the substantial cosmetic UI changes made by the team in previous iterations.
v1.3:
v1.5:
PRs for keyboard shortcuts:
This time and effort used for improving visual appeal and implementing non-essential features could have been better spent on addressing the critical feature flaw that I have pointed out.
To summarise, I disagree that this feature flaw is NotInScope due to two key reasons:
First, the inability to search by NRIC severely limits the app's practicality, resulting in a failure to meet essential user needs. Thus, addressing this feature flaw is a high priority task that demands immediate attention.
Second, purely cosmetic UI changes & non-essential keyboard shortcuts could have been deprioritized in favour of addressing more critical features like the find-by-NRIC functionality. As such, I would argue that less important UI changes & keyboard shortcuts should have been postponed to future iterations so that this higher priority feature flaw can be addressed first. This is because addressing this feature flaw to provide a more flexible find command for users would allow the app to better address users' needs as compared to purely cosmetic UI changes/non-essential features. Thus, I disagree that this feature flaw is NotInScope.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** I strongly believe that the limited functionality of the find command should be classified as a medium severity flaw due to its significant negative impact and inconvenience on users. For this discussion, let's focus on the `NRIC` field. Given that NRIC is a unique identifier that can precisely identify a student, a find by NRIC feature will be able to precisely and effectively identify a student contact. As such, find by NRIC is an essential feature with numerous real world use cases such as: - For example, when a student is paying fees/enrolling for new courses, the student will likely provide his/her NRIC for identification and verification purposes. The admin staff would need to quickly search for the student’s record using the NRIC to retrieve and cross-check a student’s details, ensuring that there are no discrepancies in the records. - Another example is when two or more students have the same name, searching by NRIC ensures the tuition centre retrieves the correct student’s records without confusion - Another example is when students may write only NRIC on their test/exam papers due to the enforcement of blind grading (where writing of name is not allowed to avoid any bias). In such scenarios, the staff will have to find by NRIC and link the exam paper to the correct student record and ensure that the right results are attributed to the correct individual Furthermore, the current implementation of the find command is overly restrictive, as it lacks the ability to search by other essential fields such as Phone Number, Email, or Address. This limitation significantly reduces the app's practicality for tuition centres, where flexibility in searching is critical. For instance, an administrator handling a call might only have access to a student's phone number. In such cases, the ability to search by phone number would allow them to quickly retrieve the student's record, ensuring efficient and seamless operations. Without this functionality, the app fails to cater to real-world scenarios, diminishing its value as an effective administrative tool. Therefore, with such a limited functionality for the existing `find` command, the target user (tuition centres) would experience significant inconvenience in their workflows and operations. The absence of this critical feature fundamentally undermines the app’s purpose of facilitating easy information retrieval, rendering it ineffective in addressing the core needs of its intended users. Thus, I would like to argue that this flaw is of severity Medium as it causes significant inconvenience to users. I would also like to note that the team did not specify a clear reason for downgrading the severity from medium to low.
The current implementation of the find command restricts its search functionality to the Name field only. While it efficiently retrieves students based on their names, it lacks the ability to search for other critical fields such as Phone Number, NRIC, Email or Address.
This limitation can hinder the usability of the application, particularly in scenarios where users need to quickly access student records using non-name identifiers, such as a phone number, nric, email or address. For example, an administrator who receives a call might only have the student's phone number on hand; they should be able to search by the phone number to locate the student’s record quickly when using AcademyAssist.
This reduces the application's flexibility and makes it less effective in handling diverse real-world use cases. This limitation is not addressed by the planned enhancements/upcoming feature.