soc-pe-bot
commented
3 years ago Team's Response
We think that our design solved the stated problem of the intended user. However, your suggestion can be an additional feature in the future.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: I believe that the feature does not solve the stated problem of the intended user (feature flaw) which is to help the user "keep track of the modules you are taking or planning to take" and "have an overview of your modules" (as stated in UG). This feature can only list modules (no distinction whether you've actually taken a module or plan to take it) which isn't an overview or a helpful way to keep track of modules. I believe my original response to the bug is enough justification as to why the application is missing a critical functionality such as total MCs or which semester the user is taking/planning to take the module in in related to the team's stated problem of the intended user.
Module features are stated to help users "keep track of the modules you are taking or planning to take" and "have an overview of your modules".
However, adding/listing of modules does not provide helpful data such as total MCs or which semester the user is taking/planning to take the module in. User only receives a list of modules they have included with no distinction between "modules you are taking or planning to take" (as listed in UG) as shown below, making the module functionalities ('module add' and 'module list' part) of the program have very little value-add to the target audience. Applications like NUSMods will be more useful for tracking of modules, providing users with the ability to see their total MCs and plan for future modules while still keeping track of current modules, allowing a distinct seperation between the two.