faaheem13 / pe

0 stars 0 forks source link

Feature Flaw: Adding Person Functionality Not Optimal #2

Open faaheem13 opened 5 months ago

faaheem13 commented 5 months ago

image.png

image.png

While it is entirely plausible for two people to have the same name, it is also entirely unlikely for two people to have the same e-mail ID or phone number.

Although it is mentioned in the UG as Phone Numbers, Emails need not be unique, I do believe it to be a feature flaw as it is not intuitive and allows duplication of fields that shouldn't have it and vice versa.

nus-se-script commented 4 months ago

Team's Response

Thanks for raising this. This viewpoint is valid but not in the context of this application. Furthermore, this is intended and mentioned in the UG, it is not in scope of the product.

It may be a common practice at an organisation level for people to share the same email address and landline phone numbers

A valid NUS example may be the CS2103 Teaching Team itself. Whose cs2103@comp.nus.edu.sg email address access may be shared across multiple professors. If the professors would like to indicate that as the primary contact email, it is possible to do so.

The same applies to the the staff office where several tables may share the same phone line 6123 4567 and the staff would not like to indicate their personal numbers but the landline number instead.

Hence to accommodate for situations like this it is a better choice to allow for duplicate emails and phone numbers.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: Thank you for responding with such great detail. I can see why the same e-mail and same phone number being allowed accommodates for these situations. I had overlooked the possibility of the same.

However, while I agree with most of the points raised, I must disagree with the same name being disallowed although it's mentioned in the UG. I would believe it is entirely plausible for two people be it tutors or professors to have the same name. Disallowing which would mean that the user will not be able to accommodate for one of them and will have to have a workaround.

While extremely unlikely, I do believe it is not unplausible. But, because this probably means a much lesser occurrence of the issue, I do agree with the change in severity.


## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.High`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]