nus-se-script
commented
1 week ago Team's Response
Thanks for submitting this report.
Comments from dev team: Rejected
Bug Type that we chose: [bugtype] NA
Severity that we chose: [severity] NA
Decision that we made: [decision] We don’t think his reasoning is fair. Adding the event or person to the address book is the main focus of this use case. He brings up formatting and valid inputs as a reason for separating into 2 different use cases. This shouldn't be a part of the focus as use cases cover how our product is generally used by a person. This should not include specific details such as formatting of command. There is a reason why we have documentation for how to format our commands.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: I am not talking about the format of the commands. Events and Persons are seperate entities that should be considered as distinct use cases. The course website has stated that use cases should describe interactions between Users and the System for a specific functionality. It is clear that adding a Person is distinct from adding an Event as they are two significantly different components in the application. As a developer reading the developer guide, it is unclear as to how the system acutally functions if the team is to treat Events and Persons as the same.
Looking at the documentation of use case 1, the combination of Person and Event is not the same use case given there is quite a big difference between them.
Events require a time field that has to be extensively validated. Further, the time component is a big part of your implementation as it is needed in the schedule function.
As a developer looking at the Use Case, adding a person and an event seems to be exactly the same but in reality, it is two distinct components.
Suggestion: Seperate the documentation and use "Like Use Case x" and explictly state the differences like Time/ Phone number.
Extracted From DG: