nus-se-script
commented
1 week ago Team's Response
Thank you for raising this issue.
While it’s true that the “add person” use case is omitted from the Developer Guide, it doesn’t cause significant problems for the following reasons:
The add feature is already implemented and functional in the original AB3: Future developers won’t have to create or design the “add person” functionality from scratch. They can rely on the existing implementation, which already meets the expected requirements. The lack of documentation in the Developer Guide doesn’t prevent them from understanding or maintaining the feature.
The risk is minimal: The feature has been inherited from the original address book app, so there’s no chance it will be forgotten or left unimplemented. It’s part of the app’s core functionality, and its behavior is well-established and intuitive.
No significant impact on development: The missing use case is only a minor documentation gap. Developers working on the app will see that the feature is already there, and they can refer to the existing code if needed since the primary purpose of DG is to serve as a complement. The extensions mentioned can be seen as an isolated enhancement that doesn’t fundamentally alter the “add person” functionality, and future developers can easily follow the existing patterns from AB3 without additional guidance. This doesn’t create confusion or block further development.
According to the course guidelines, the severity of missing requirements depends on the potential damage caused. In this case, the impact is negligible since the feature works perfectly and isn’t at risk of being missed or confusing.
Given these points, this issue should be classified as low severity because it doesn’t affect the app’s functionality or development in any meaningful way. It’s simply a small gap in the documentation.
Items for the Tester to Verify
:question: Issue severity
Team chose [severity.Low]
Originally [severity.Medium]
- [x] I disagree
Reason for disagreement: 
Use cases thus provides unique and significant information to the developer than if they just read the code. Yes, the code already exists and the feature already exists. But the purpose of your use case section is to capture functional requirements based on user intention and user interactions. Reading the code itself will not easily show a current/future developer, what the functional requirements/user intentions/user interactions are. Perhaps that is fine for straightforward features such as delete which doesn't have that many possible ways a user can interact with it. But for the add feature (and the edit feature), there are so many prefixes (compulsory and optional!) a user can use. But if the complexity of user interactions was just the prefixes as they worked in AB3, perhaps documenting user interactions via use cases would not be as critical. The risk of developers not understanding the functional requirements regarding user interactions would be small, and thus it would be a low priority bug to leave out add (and edit) from the use cases.
BUT, on top of the multitude of prefixes (optional and compulsory), the add (and edit) feature also seems to require "specific pairings" to be in place due to your roles (r/) prefix. After testing, here are what i assume your pairing requirements are:
1) r/Person must not have the h/ d/ or ped/ prefixes
2) r/Volunteer must have the h/ prefix and must not have the d/ or ped/ prefixes
3) r/Donor must have the d/ prefix and must not have the h/ or ped/ prefixes
4) r/Partner must have the ped/ prefix and must not have the h/ or d/ prefixes
5) the format of h/ d/ and ped/ also have their own individual requirements
Such paired requirements for adding people does not exist in AB3 so if such requirements and the user interactions related to it are not specified through your DG (like through your use cases), there is a substantial likelihood that a current/future developer might miss out on these requirements and then go on to change up your code's functionality.
For example:
Let's say I am a developer who wants to add a new role... then I might implement it without envisioning that users should receive an error message if they use prefixes from other roles or if they forgot to add the required prefix pair because I did not realise these should occur for this feature. I'm not saying that all of these possible user interactions should be covered in your use cases, but providing a use case for add with an MSS and then a generic extension for user interactions with roles and unexpected paired prefixes would prevent significant misunderstandings from occurring.
Thus, I do not agree that this is "simply a small gap" and is instead a substantial source of potential development problems (especially since this is a core feature of your app which also has significant room for expansion to include more prefixes and more roles with paired prefixes). Hence, I still think this is a medium severity documentation bug.
it is important to have use case for adding a person since it is an important feature plus many different roles can be added hence there may be significant extensions to write about in the use case.