Use cases for tags aren't relevant in current version

[awdse22]

There is use case 5 (create tag), use case 6 (edit tag) and use case 7 (delete tag). However, based on the user guide, as far as I'm aware, the only tags that exist is the tag under a student (t/TAG parameter) There is nothing else mentioning about the use of tags in the current version. The feature does not seem to exist in the software?

(No such thing as selecting tag to delete, prompting for confirmation, etc.)

If this is supposed to be in a future version, perhaps this should have been included under planned enhancements?

[nus-pe-bot]

Team's Response

We appreciate the identification of the issue. However, we believe that the while the use case does not apply a one to one mapping to an existing feature, they are still implemented.

For UC5 Create Tag, one can use edit or add For UC6 Edit Tag, one can use edit For UC7 Delete Tag, one can use edit or delete

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: Thank you for the clarification. Indeed I have considered that the said "Tags" here may refer to the tag under a specific student and I understand that use cases may not always apply a one-to-one mapping. However, while this bug report may not be the most relevant in terms of the existence of this "Tag" feature, I don't think it should be outright rejected. From what I saw, the way these use cases are written felt more like it is implying a separate feature rather than a feature solely based on the tag of the users, hence I initially did not think of these use cases to be referring to the students' tags when reporting the bug. There are a lot of inconsistencies/ambiguity which makes it harder for users to understand that the use case is indeed referring to tags of a student based on the add, edit or delete commands.

1. The names of the use cases can be more specific (e.g. Create Tag under a student, Edit Tags of a student, etc.).
2. In UC5 extension 3a, it states System alerts the teacher that the tag exists and no new tag is created.. However, there is nothing informing the user about duplicate tags. When adding a user with duplicate tags with add n/asdf p/10101010 e/a@a.com a/some address t/test t/test f/100

When editing the asdf's tags with edit 7 t/test t/test

However, all these extensions seem to have similarities with adding students.

3. It is inherently applied that tag is supposed to be separately created in one of the extensions of UC3: Add a student.

In UC3, it is stated that if the tag does not exist, then the user needs to create a tag first.

This goes against your response that a tag should be created while creating a student using add command or by using edit to edit a students' tag.

Hence it is more likely for readers to imply that tag is supposed to be completely separate from students.

4. For UC5 and UC6, it is stated in the 2nd step of MSS that the system displays the required fields for tag creation/editing. The term "required fields" (in plural) imply that tags are supposed to contain various fields/attributes. Additionally, in the 5th step of MSS, it states "System confirms the tag has been successfully created/updated and is available for use.", which in a way further implies tags being created or updated to be used by students separately.

5. For UC7, in step 2 of MSS, it is stated "System prompts the teacher for confirmation before permanently deleting the tag". There is no prompt for any confirmation when using edit to edit tags or delete to even delete students.

When executing edit 1 t/

While all these examples seem to point towards the bug of these use cases being unclear rather than "not relevant", the point here is that these use cases, when read together with other use cases in the developer guide, more intuitively implies that tags are completely separate from students. It has also come to my attention that there is another bug report on this as well (with the same severity), which further proves my point on the implications of these use cases.

Hence, while the issue may come from the use cases not being clear and they were meant to document tags of students, this issue is likely to lead users to think that tags are supposed to be a completely separate part of the application (similar to lessons) and they end up mistaking this as an non-existent feature. Even if saying that these use cases "are not relevant" or "are not implemented" isn't completely true as your team intended to document it as the tags of students using add, edit and delete, the use cases not being clear still stands as quite a large issue in this context and I think that completely rejecting the bug report isn't really the right way to go about it.

---