nus-pe-script
commented
2 years ago Team's Response
Hi, we choose to reject this bug for the following reasons-
Firstly, one can see the mention of a temporary-adding feature in our user stories. It has, however, been categorised as priority.Low in the interest of time, and we chose not to implement the feature in v1.3 eventually.
Nonetheless, we did not want to edit our Use Case because it is how we aim for our product to work, once the feature has been fully implemented. We also actively searched through the CS2103T website and did not find any guidelines mentioning that Use Cases had to be drafted in line with the current state of the product and could not contain aspects of features willing to be implemented in later iterations. Since the choice seemed to be with the developing team, it was our decision to keep the use cases the way they were and not edit them.
As CS2103T students, we work in slightly unusual circumstances and thus think it is important to acknowledge the grey area between what a team wishes to implement vs what they manage to implement and how they choose to document it in the absence of concrete guidelines.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: I disagree with the team because I believe that although teams should have some flexibility in deciding some aspects of the DG, consideration should be given that whatever listed in the DG needs to be sufficiently organised with proper notices or guidance to be well understood by the reader (in this case other devs).
I understand the fact that the priority of the user story is low and thus has not been implemented, but I don't think there has been reasonable effort to document how the section on use cases tie to the user stories (i.e. whether these use cases have been implemented or not), and in fact (though a little more subjective) I think the user story could even be crafted a little more specifically to highlight the use of tags as part of the feature. And upon now understanding where the team is coming from, that might imply there is an error in the use case stated, that the extensions should resume at step 2 instead of simply ending (otherwise we would be lacking the step on the student being added to the system).
Further, since the priority of the user story is low as justified by the team, then perhaps it might be reasonable to not include this use case at all and look into implementing use cases for the high priority user stories? -
But I think ultimately the point the team is trying to put across is that there is some sort of documentation that this "permanant/temporary" tag feature is included in the DG, and as such, this use case is valid. On this grounds, though I still believe this to be a documentation bug (as the screenshot provided is a ambiguous and there is no further documentation on whether the limited use cases have been implemented), I would think the severity could be reasonably lowered to low.
Use case 2 (UC2) in DG mentions about lifespan of the entry in manually adding a student as well as using the permanent tag or temporary tag. However though these seem to be crucial details, they do not seem to be otherwise recording in the add command feature in the UG, nor noted anywhere else in the DG that these are upcoming feature etc.
(see SS below for the relevant section mentioning the lifespan of entry and temporary/permanent tag etc. which do not seem to be otherwise documented in the UG nor noted in current app behaviour)