Subjects Allowed Are Limited Compared To Subjects Present

[e1121208]

Description

The user guide states that, and I quote,

UGTeach is a desktop app for managing your students' contacts that aims to empower Singapore-based undergraduate private tutors to efficiently manage payments and organize schedules.

However, undergraduate private tutors are also responsible for tutoring JC students which expands the subject to Computing, Further Mathematics, Knowledge and Inquiry and many more. Furthermore, such subjects can also be banded to H1, H2 and even H3.

This may cause such an application to be limited to primary school tutors, as even secondary school has their mathematics subject split into Additional Mathematics and Elementary Mathematics.

[nus-se-script]

Team's Response

Thank you for your response. We will mark this as a duplicate of #145.

As for v1.6, we feel that enforcing the constraint for subject to only take a certain value is at least better than of allowing for any strings to be valid for the subject so that user. Improvements / widening of this scope could be postponed to the future iterations, since the current iteration would be sufficient for our target user most of the time. Hence, the severity is likely low, as it is only in rare case where the app will not be sufficient for the target user.

We believe that the subjects that you have provided are niche, there is only a small population of students who takes those subjects, in general.
For the subjects that we allow in UGTeach, it should suffice for most undergraduate tutors who provides private tuition.

As for the Additional Mathematics and Elementary Mathematics, we feel that as for the current iteration, combining them into Mathematics will not bring too much inconvenience to the user. They can still have a workaround and indicate the subject as Mathematics.

Of course, your suggestion is valuable to our team in terms of improving the user experience for UGTeach. This issue will be resolved at the same time when we resolve #145, by allowing for a more flexible subject validation.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Not allowing possible valid subjects

UG mentioned that this app is for Singapore-based undergraduate private tutors.

Undergraduate private tutors might offer classes beyond the usual school subjects. Some valid example including foreign language tutors (e.g. Japanese, Spanish, etc) or special skills tutors (e.g. coding, cooking, etc).

Limiting the subject input to only include common school subject hinders the ability of those tutors to use this app.

Suggestion: Allow user to put different type of subject outside the list.

---

_{[original: nus-cs2103-AY2425S1/pe-interim#207] [original labels: type.FeatureFlaw severity.Low]}

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

Thank you for your response. We will mark this as NotInScope.

As for v1.6, we feel that enforcing the constraint for subject to only take a certain value is at least better than of allowing for any strings to be valid for the subject so that user. Improvements / widening of this scope could be postponed to the future iterations, since the current iteration would be sufficient for our target user most of the time.

We believe that the subjects that you have provided are niche, there is only a small population of students who takes those subjects, in general.
For the subjects that we allow in UGTeach, it should suffice for most undergraduate tutors who provides private tuition.

Of course, your suggestion is valuable to our team in terms of improving the user experience for UGTeach, and we will consider improving this in the future iteration, which is to make our subject validation more flexible and accommodate more subjects.

Items for the Tester to Verify

❓ Issue duplicate status

Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)

• I disagree

Reason for disagreement: [replace this with your explanation]

---

❓ Issue response

Team chose [response.NotInScope]

• I disagree

Reason for disagreement: [replace this with your explanation]

---

❓ Issue type

Team chose [type.FeatureFlaw]
Originally [type.FunctionalityBug]

• I disagree

Reason for disagreement: [replace this with your explanation]

---

❓ Issue severity

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

• I disagree

Reason for disagreement: [replace this with your explanation]

---