Part2 Feedback

Requirement Met or Exceeded	Opportunity for Improvement
Product Backlog:
All 8 stories present have a rationale, though not all of them are appropriate user rationales.	Not all user stories present in GitHub Issues list. Only 8 are there, but 18 user stories are provided in the problem description. Format of issue titles is a bit hard to read, please use plain written language.
All 8 stories present have point estimate.	Rationales should not be a technical rationale - they should be a user-based rationale. EX: "no duplicated username in database" is not why the user wants a unique username. The user would want a unique username so that they can easily tell their friends how to find them in the app, for example.
All 8 stories present have risk level.	User stories do not reference US XX.YY.ZZ code provided in problem description.
User Interface Mockups and Storyboard Sequences:
Most important interfaces/dialogs present, but some are missing.	Technical implementation details do not belong on UI mockup comments. EX: "the system should automatically check if the username is used" is technical. Instead, comments sholud be relevant only to the user experience.
Comments are present	UI mockups are provided as a list of pages, but there is no storyboarding aspect.
Some transitions are indicated in plain text, rather than as sequences or transition graphs.	Sometimes it is hard to tell what user action triggers a transition to a given UI mockup.
Some extra requirements appear to have been added (EX: messaging, searching)	Requirements are not referred to by US XX.YY.ZZ code in UI mockups.
	Important requirements are missing - no map views included. It is sometimes difficult to tell whether or not a requirement is met (EX: following permission accept/deny) due to lack of storyboarding and user triggers.
Object-Oriented Analysis:
UML syntax is correct, and clearly corresponds to possible Java classes.	The relationship between User and Friend is composition, but also allows for 0..1 cardinality in both directions? This is confusing - can a User only have 0 or 1 friends, but no more? And it's contradictory - the composition relationship indicates an at-least-one cardinality, but you have indicated a cardinality of 0..1. Less important: UML is missing some attribute types, most method return types, and all method parameter types.
	This is not sufficient design to implement your own UI mockups (EX: no concept of messaging, nickname, avatar, etc.) It is also not sufficient OO design to implement the required userstories for the project. (EX: There is no clear way for a User to have a mood history, moods do not indicate location, etc.) It is also not self-consistent. (EX: only one "Page" class is shown, though several more are referred to by methods.)
	UML indicates that the User class will inherit from Profile, which is an interesting design choice, but the separation between those concepts should be explained in the UML.
Glossary and Information Sources:
Some important domain terms defined.	Glossary terms should define domain terminology, like Mood Reason, Emotional State, Mood, User. You have some. But user action and UI-based definitions are less important. For example, you define "Message and friend" which is a UI element. But you do not define Friend or Message, which are the important domain terms you use throughout the rest of your submission.
Programming terms are not included - good.	Competitive or comparable products shown in wiki.
License included in codebase - good.	It's also nice to have the license in the wiki. But no grades deducted for that :)
Tool Practices:
All deliverables made available on GitHub or Trello, with obvious contributions from all members.