Team's Response

Duplicate because these reports are describing that there are not enough use cases.

The 'Original' Bug

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

Insufficient use cases

Note from the teaching team: This bug was reported during the Part II (Evaluating Documents) stage of the PE. You may reject this bug if it is not related to the quality of documentation.
There are only 3 use cases for about 29 possible commands. There is clearly insufficient documentation for how these commands are intended to be used.

_{[original: nus-cs2103-AY2122S1/pe-interim#1241] [original labels: severity.High type.DocumentationBug]}

Their Response to the 'Original' Bug

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

Reasons for rejecting:

"There are only 3 use cases for about 29 possible commands" is not a problem because there is no requirement whatsoever that there must be a minimum number of use cases covered (see screenshot 1 below). To the developer team and we believe to future developers, quality is more important than quantity. Understanding what is written in the documentation, and the documentation describing the most general use cases, is more important than the documentation exhaustively writing every single possible use case. As mentioned in the textbook, developer documentation is meant to be "minimal but sufficient" (see screenshot 2 below)

"There is clearly insufficient documentation for how these commands are intended to be used" is not valid, because the User Guide already serves as a comprehensive documentation for how all 29 commands are intended to be used.

2 of the 3 use cases (UC01: add and UC02: delete) actually cover 8 commands, because it covers add and delete for all our models (i.e. these use cases cover add custom goal, add contact, add event, add todo, delete custom goal, delete contact, delete event, delete todo). We mentioned only 2 use cases instead of 8 for the sake of brevity. In fact, it would inconvenience the reader if we were to include all these use cases.

Given that the most important use cases have been covered, the developer has an idea how the app works, and can simply refer to the User Guide to figure out the remaining details of how a user will use the app, rendering additional use cases unnecessary. We deliberately omitted less important use cases to keep the Developer Guide short and concise, so that it does not unnecessarily waste the reader's time.

Reasons for changing severity from High to Low:

Even if this is considered a bug, it cannot have a High severity because it does not cause a major problem for the developers reading the guide. The developer can still understand the Developer Guide, the requirements and the underlying implementation by reading the rest of the Developer Guide. The developer can also understand how the product is used simply by referring to the User Guide. The omission of some use cases is not going to make the Developer Guide unusable for developers.

Screenshot 1: to prove that not all 29 commands must be covered

Screenshot 2:

Items for the Tester to Verify

:question: 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]

:question: Issue response

Team chose [response.Rejected]

[x] I disagree

Reason for disagreement: While it is unnecessary to have DG that covers all of the use cases, use cases are not only useful for the developers to read and understand how they should work, but it is also useful for system and acceptance testing. In fact, you can do testing based on UC, which is a focus on testing based on functional requirements. In addition, while it is minimal, the DG should also cover sufficient use cases. Hence, it needs to cover important use cases for the developers to be able to test the functional requirements. While the User Guide can also be read by developers, the Developer Guide should provide enough for the developers to start with, and if I were the developer and I was asked to test based on these 3 use cases (which claims to cover 17 commands), I'm not sure if it covers all the important commands to begin with, as there are many different features to be tested.

I agree that the severity should be low, however, as it does not cause major problems for the developers.

Screenshot 1: proving that DG should cover all important use cases

Screenshot 2:

HalphasX / pe

Docs: Use cases for DG #15