avellinwong01 / pe Goto Github PK

Does not describe in sufficient detail how to use the BMI calculator/calorie intake calculator.
Seems like more details were given in the DG manual testing section instead, for instance: how the activity level works (is 1 the lowest or highest activity level and won't it be quite subjective across different individuals as well?)

Error message could be clearer to tell the user which attribute needs a positive integer here

Such workouts do not appear under the list of scheduled workouts for the future, which seems counterintuitive. Instead, they appear under "completed workouts" which doesn't really make sense.

While I see why your team would want to include this section into the UG, I feel that it is too overwhelming especially for a first time user reading this UG to understand all the limitations and many restrictions in their text-based input. The user would probably figure out some of these errors along the way as he uses the product through error messages.

The UG as a whole was personally too complicated for a first time reader trying to test your product.

App reschedules workouts that are scheduled for past days.

However, app does not reschedule workout that is scheduled today (12th Nov) but already past time (3.40am)

Since list schedule all is also a valid input, perhaps it should be mentioned in the error message, rather than just the date and time

The footbox of each entity should be hidden as it is not part of the standard UML diagram notation for this module.

0ml drink is added which is not realistic in real life

Program accepts input if duplicate dates are keyed in by picking the first one

Scrolling through your DG, I see all class diagrams and sequence diagrams. Would be good if you could include some object diagrams for specific implementation example inputs. Otherwise all of it is a fairly bigger picture/higher level view.

UG says that parameters between <> angle brackets are optional, yet the volume of the fluid seems to be required here.

Might be more reader-friendly to put each expected output right after each example usage, so that the reader knows which corresponds to which.

For a user unfamiliar with the commands of the app, it is unclear what positive integer he is supposed to enter here.

The design and implementation section immediately goes into descriptions of each component, class and functionality. It will be good to first have an overall high level architecture diagram and introduction + brief overview of the various components/classes and how they fit together as a cohesive whole.

Once the date/time passes for the scheduled workout, is it automatically assumed that the workout is completed (if it was not deleted beforehand)? And would the calories automatically be counted into that day's calories burnt?

Meal and fluid library seems redundant, there are now 2 ways to add meals and fluids into the app which makes it complicated

It is unclear which attribute a positive integer is supposed to be entered, since all attributes are left blank here.

Possible to allow user to directly key in calories after, if meal is not recorded in library

The instructions for manual testing section take up ~50% of your DG length. I don't think it is necessary to have so much detail of all the different test cases, sample inputs and expected outputs -- it makes it overlap with the UG and there's way too much detail, making it overwhelming.

Testing

The protected ArrayList meals should be written as "# meals: ArrayList", similar to the other protected attributes in the class diagram.

I see many such comments (yellow boxes) in various UML diagrams in your DG. Not sure if those are accepted for this module.

When optional attributes /d and /t are keyed in without a space in between, the program accepts the input as long as the other attributes are correctly keyed in. But when /d and /t are keyed in with a space in between, the program rejects the input. I think the behaviour should be more consistent since the inputs are almost identical

Details here are too complicated, again the user will probably find out from using the app itself when he/she types in a wrong format (with suitable error messages thrown). The command itself is also too complicated for fast-typists with too many things to watch out for