Inaccurate command format for `add` and `edit` for the `m/MODULE` parameter

[rama-pang]

In both the add and edit command, the module parameter is specified as [m/MODULE], meaning that it only accepts one module parameter. However, you can add multiple modules together; e.g., edit 1 m/CS2101 m/CS2103T is a valid command.

Reason for severity:

• In the user guide, it is never mentioned anywhere (neither in format, explanation, or examples) that you can enter more than one module. Thus, the reader will never know of the ability that you can add multiple modules to a person; instead, from only information in the user guide, they will understand it as: a person can only have exactly one modules associated.
• If the "multiple modules" feature is the unintended behavior (e.g. the team instead says that a person can only have exactly one module), this is instead considered a feature flaw with similar severity - more often than not, a TA has TA-ed multiple different modules.

[soc-se-bot]

Team's Response

No details provided by team.

Items for the Tester to Verify

:question: Issue severity

Team chose [severity.Low] Originally [severity.Medium]

• [x] I disagree

Reason for disagreement: This was elaborated in the original issue, but I'll reiterate.

First, let's examine the use case of the application.

Tuthub is a desktop app for NUS professors who wish to track and choose their next batch of teaching assistants/tutors based on their past performance and records but have little time to spare for tedious administrative work.

Consider the course CS2109S Introduction to AI and Machine Learning, which is a new module (this semester is the second run of this module). For its very first run last semester, the professor also needs TAs, and they are very likely students who have completed other AI and ML courses. Also, note the preclusions of CS2109S, which are CS3243 Artificial Intelligence and CS3244 Machine Learning. CS2109S aims to merge contents of both of these modules. Therefore, for a TA of CS2109S, having a student who had TAed both CS3243 and CS3244 would be very ideal. Hence, the application being able to support multiple modules is a very important feature.

The example above is not the only example of where two or more different modules might be useful. There are numerous TAs who have TAed different modules, and being able to see their TA history is important in determining whether they are qualified for a certain module. For example, we could expect students who have TAed both CS1101S Programming Methodology and CS2040S Data Structures and Algorithms would be a relatively good fit to TA CS3230 Design and Analysis of Algorithms.

Now that we have examined the importance of being able to support multiple modules for a single student, we now examine the User Guide. Everything in the User Guide implies that a student can only have exactly one module associated with them. Some example snippets from the User Guide:

Note that it is never mentioned that a student can be associated with multiple modules. All command formats don't have the ... symbol which indicates you can have multiple occurrences of that parameter.

Hence, if a user were to read the User Guide, they will infer the following: a student can only be associated with exactly one module.

As we examined previously, if this application only supports a single module per student, it would be a very serious feature flaw (with at least severity.Medium), as it can cause a lot of inconvenience to the professors.

As the cause of this problem is due to the User Guide, then it also inherits the severity of the "feature flaw" version of the issue where the application only supports a single module per student; i.e., at least severity.Medium. Especially since the users will possibly never know of this feature to have a student with multiple modules due to the incorrect User Guide.

---