nus-pe-bot
commented
2 years ago Team's Response
Hi,
We choose to reject this bug since there have been no concrete guidelines given on the CS2103T website stating how extensive use cases must be. They most certainly cannot be exhaustive looking at the permutation and combinations of situations that can arise from using different commands and thus the decision was with the developers' team to choose where we wanted to stop with the extent of use cases.
We felt like these use cases, however minimal in number, are capable of depicting that the team members have the ability and skills required to write well-formatted use cases.
Moreover, since the developer guide and user guides can be read in tandem (since they were shared together), we believe that all of our command usage examples and recommended workflow are actually extensive enough to ensure that the reader doesn't feel clueless about what TAilor can offer and how they can work for that desired output
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: I would disagree with the team, given as although there is no concrete guidance provided on the cs2103/T website, I believe it should be reasonable for us to understand that the DG should be properly documented with sufficient details on the current implementation for the application. Though I agree that the use cases need not be exhaustive because that might be unreasonable and subjective, I feel that it is fair to say that the team's use cases are lacking significant details and do not touch on many of the other core commands that have actually been implemented.
Further I don't believe the point of the DG is to provide a sample to just demonstrate we are able to write according to the format (as justified by the team). I think that information placed into the DG should be reflective of the work done, to properly mirror a DG that should be created in a real brownfield project that might be read by other developers looking to maintain the code as well, and perhaps this should be the focus of the takeaway from the DG. Otherwise, the same standard based on the justification by the team can be placed upon any other UG/DG component which wouldn't make sense :(
Again I don't think the point of the UG and DG is for them to be read in tandem. I believe there are two different documents for different reasons, where developers should be able to focus on reading the DG in order to understand the high level view of interactions between the system and the user. Further I believe the point of use cases can become even more crucial as the application become more complex, where the use cases no longer simply require the execution of a single command, and needs to allow the developer to understand how the user is guided from one point of the app to the other with multiple interactions - in the case of the team's project, I felt one crucial use case could be regarding how a user might want to send emails to students within a specific a specific module's group, as the team could then demonstrate the system user interactions in combining the find and mail-x commands and showcase the expected flow of behaviour.
In light of the above, I do think the use case section is lacking details. Given as I believe quite some information has been left out of the section, I have selected medium as the appropriate severity!
Hope this clarifies!
Use cases have only been documented for very limited 3 features (importing, manually adding and finding a student). Use cases for other new commands e.g. newtask and deltask etc. should likely be added as part of the documentation in DG.
(see zoomed out SS below to show the consecutive page numbering - to note no missing pages - and only 3 use cases seem to be documented)