nus-se-bot
commented
3 years ago Team's Response
Command result shown by Momentum is the error, the extension builds up on this. Hence there is no problem with the extension.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: I'm not sure what the team means by "Command result shown by Momentum is the error, the extension builds up on this." as there is no mention of a command result in the MSS for this use case.
However, similar to my response to #11, the handling of erroneous input (in this case, to start an already-existing timer) should occur before the actual starting of the timer (step 2).
In this aspect, I suspected that the team may be using a different convention for use case extensions. Instead of an extension "executing after" a MSS step (i.e. extension 2a "executes" after step 2), which is the understanding I get from the textbook, they may think that an extension "executes before" the MSS step, i.e. extension 2a "executes" before step 2.
However, this is also clearly not the case as extension 3a in this same use case correctly follows the textbook's "execute after" convention.. It does indeed "execute after" step 3. As such, I'm not sure what the team's usage of an extension is since it doesn't seem to be consistent.
As for the severity, I agree with lowering it to Low.
:question: Issue severity
Team chose [severity.Low]
Originally [severity.Medium]
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
I think extension 2a should be 1a instead. After step 1 when a user requests to start a timer, if there's already an existing timer then it should immediately throw an error. It shouldn't continue to execute step 2 and start "the timer" before throwing the error