nus-se-script
commented
2 months ago Team's Response
Thank you for your suggestion. We're correcting the type of the bug to "Feature Flaw" since the functionality is consistent with what's documented in the in-app messages and user guide, which states phone numbers should only contain numbers.
Considering the target user profile, which is NUS computer science students storing contact information of their courseMates, it is unlikely that they will store more than one phone number of their courseMate. Besides, office numbers will not be applicable as they are still students. (Most students will likely only keep the mobile numbers of their courseMates.)
However, it is still a sensible suggestion to allow that. Since it requires more effort to change the current behavior in AB3 and it does not benefit most users in our target user profile (as justified above), we are categorizing this bug as "Not in Scope" with low severity.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: I disagree with the development team's categorization of this issue as "Not in Scope" and downgrading its importance. The ability to specify additional details in phone numbers, such as whether it is an office or home phone (indicated by tags like "(Office)" or "(Hp)"), reflects a realistic and common user behavior, even among university students. The assumption that NUS computer science students would not store multiple types of phone numbers, or that office numbers are not applicable, does not consider the diversity of student situations. Many students engage in part-time work, internships, or might need to manage contacts related to academic collaborations, where distinguishing between different types of phone numbers becomes necessary.
Moreover, the course website's guidelines underscore the importance of handling real-world data inputs effectively, which includes the flexibility to accommodate various user input styles. Dismissing this feature underestimates the practical needs of users and restricts the usability of the application. Thus, this issue should indeed be considered within scope as it directly impacts the functional comprehensiveness and user friendliness of the application.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
Many users enter phone numbers indicating whether its the home number or office number. That is not accounted for here.
Steps to reproduce:
Command to enter: add John Doe -e johnd@example.com -p 98765432 (Office) -t johndoe -s Python -s Java