ella-e / pe Goto Github PK

One limitation for the application is that it doesn't enforce any data encryption or protection for the data. It would be better if this limitation of the application's scope could be mentioned in the NFR section.

Since archive related features are important part of this project. But this word is pretty general and may hold different meanings in different context. It would be better if it could be defined and explained more in the glossary.

I choose severity low because this is not a cosmetic thing and may lead to misunderstanding for some developers.

For the clear and clear_archived commands, additional notes could be added to warn the user about possible negative effects of these two commands. Because there is no way to undo the command and running of the two commands might result in loss of all the data.

I choose this severity as Low because it is not a cosmetic issue. It may result in drastic outcomes for some users.

In this paragraph of DG, it mentioned that there should be some form of tag list exist in the application. However, according to the later implementation part, the group has already changed the tag feature into group feature. Therefore, the changes should also be reflected here for the developers to understand the system.

I choose the severity as low because this is not a cosmetic issues and may make developers reading this part confused.

Dummy bug report.

Since this application is designed for fast typer, it would be better if the user could quickly switch between the normal list and the archived list without any use of mouses.

After doing the delete_archived command, all the archived students are just deleted. It would be better if they could be returned back to the normal list. Since there is no further explanation in the UG, users might accidentally delete all the students and can not retrived.

If a student is already in the archive list, if the user tries to archive the student again, a warning message that the id is not in the entry is shown. However, the actual situation is that the student is already in the archive list. It would be better if the message could match the situation and report to the user that the student is already in the archived list, instead of say it is not in the entry.

As shown by the screenshot, the application log file created automatically still contains the word address book. It would be better if it is changed to the name of the application, e.g. teacherStack.

It is stated in the warning message that both of the student id and email should be unique. However, I am able to add students with same email address with just the first letter being different. However, conventionally, email addresses are not case sensitive.

The email should not be case-sensitive. In the real world, a person with email [email protected] is still able to receive the email sent to the email address: [email protected]

After I change the domain name to the lower case letter, this command works.

For the archive list related features, command for adding an archive student is "archive", while for unarchive action, the command is "unarchived". It is not very intuitive in making the two different, and would add in more effort for the users to remember and distinguish.

There are a lot of instances of the word "addressbook" appear in the DG's text contents. Since this application is about student management (called TeachStack), it is unlikely for them to use the word AddressBook in the DG.

Here are some of the screenshots, there are others that are not shown:

In the testing section, it is instructed to double click the app, while it doesn't work for some cases. Better to change to java -jar

According to the UG, I can only form a group for multiple students. But if I want to edit the group name later, I may need to use the edit command instead to edit the group name one by one for each students. But according to the edit comment's description in the UG, the group name can only be overwrite. There seems like no way to edit a single group name for a student.

Here is the corresponding description in the UG.

In the UG, the prefix of Email example is suggested to be starting with "e". However, in the application's output message, it suggested starting for the email becomes "E".

In UG:

In Application:

There are also unchanged "AddressBook" appear in the diagrams of the DG.

Here are some of the screenshots:

In the UG, it is said that the list command is used to list all the students, while in the actual application, the instruction displayed is list all persons. Since the target user is teachers in this case, using the word student consistently would be more intuitive.
In the app:

In UG: