nus-pe-bot
commented
18 hours ago Team's Response
Thanks for you testing！ The restriction on adding employees with duplicate names is a deliberate design choice, not a flaw. While it is true that people in the real world can have the same name, using unique names as identifiers within the system helps prevent confusion or data errors caused by duplicates. This approach is a common practice in many systems to maintain data integrity.
Additionally, if the tester's suggestion is to allow duplicate names but enforce uniqueness through phone or email values, this would be considered a feature enhancement rather than a bug or deficiency in the current implementation. The existing functionality aligns with the intended design and allows for flexibility through other fields for distinguishing users. Therefore, this behavior should not be treated as a functional flaw.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: I believe it is of severity medium as the inability to add employees with duplicate names creates significant inconvenience for users managing real-world data, where duplicate names are common (e.g., "John Tan" or "Sarah Lim"). While the system allows flexibility through fields like phone numbers or emails, users must constantly modify names manually (e.g., appending initials or numbers like "John Tan 1") to bypass the restriction. This introduces unnecessary friction in normal operations.
Allowing duplicate names but enforcing uniqueness through fields like phone numbers or email values is a common and straightforward design. Implementing this would require relatively minimal additional effort since uniqueness checks could be shifted to those fields instead of names. The current design prioritizes simplicity at the cost of usability, but the alternative is a more intuitive solution that does not require complex changes.
The deliberate design choice, while understandable, sacrifices a critical user expectation. Most systems, including HR or contact management software, allow duplicate names because it reflects real-world scenarios. Users encountering this restriction may feel the system is unintuitive or incomplete. The resulting inconvenience is not minor and occurs often enough to be classified above severity.Low.
The issue affects usability and is not just a future enhancement. It directly impacts how users interact with the system, which is central to its functionality. Fixing this would not require a complete overhaul. It is a modest adjustment to enforce uniqueness through other fields, which could have been implemented from the start without diverting significant resources.
People in the real world can have the same name. Though it's the feature flaw inherited from AB3, duplicate names are very common.
Perhaps it would be better to check value of the phone / email as well?