Here is a hierarchical list of our use cases with a workflow diagram drawn for each (1 per team member):

1.) Login/Logout (Anthony Porporino)

This use case demonstrates that a tutor can login in and out of the system. It is an important use case since it is the first thing the tutor will do anytime they open the application. Without logging in they do not have access to do anything else. The tutor must be registered and provide the correct username and password to log in.

2.) Input/Modify Availability (Charles Bourbeau)

This use case describes the way a tutor can either input a new availability to his calendar, or modify a current availability by deleting it. This calendar is crucial for the tutor because it is the way the students will be able to reach out to the tutor and book a tutoring session at a specific date and time. The way this feature will work is by first showing an interface of the current calendar for the tutor. Then the tutor is able to select a specific date and time from the calendar. What the tutor has selected will be in either one of two cases: a blank space in the calendar or a current availability. If it was a blank space, the tutor has the option to add a new availability to his calendar. Otherwise, the only option offered to the tutor is to delete the availability selected. After this process ends, a tutor can continue modifying his calendar if he is not done, or confirm his changes if he is done. In the case of him not being done, he will be required to select a new date and time. If he has confirmed he is done, he will receive an email confirmation of his changes and the whole process will be terminated.

3.) Accept/Decline Appointment (Felix Simard)

The following will detail the use case: Accept/Decline Appointment. This use case effectively describes how a tutor can either choose to accept or decline a requested appointment/tutoring session by a student. The first straightforward scenario of this use case is shown by the left split at the first decision node of the flow diagram, where a tutor simply decides to decline a requested appointment. In this case, by following the association to the last merging branch, the student is notified that the tutor is "unavailable", the tutor sees a confirmation that he declined the session and the manager's dashboard is updated to reflect the request's status. Now, if a tutor decides to accept an appointment request, the online tutoring system checks if the tutor is indeed available at the specified date and time. In the event where he/she is "already booked" (shown by the right split at the rightmost decision node), we notify the student that the tutor is unavailable and offer other times, and we inform the tutor within the system that he/she is booked (they can decide to edit or cancel conflicting appointments). Finally, in the case where the tutor accepts the request and is in fact available, then we simply confirm the appointment creation, book an available room (assumed always at least one available), then we jump to the last merging branch to notify the actors of their upcoming appointment and update the manager's dashboard to reflect the newly scheduled appointment.

4.) Submit Student Review (Kyle Myers)

This use case deals with when the tutor desires to review a student for a tutoring session that has previously been completed. This is to improve the quality level of learning, and to help the tutor make decisions about accepting and declining requests by students. Students will therefore be forced to participate efficiently in the tutoring sessions, and therefore not take up time that could have otherwise been used for a student who is more willing to listen and participate with the tutor.

The tutor will begin by selecting the “rate/review a student” option inside the tutor main menu (i.e. the screen viewed once the tutor has logged in). After this, the tutor will continue to select a student for whom we wishes to rate, and therefore specifying which profile the subsequent information will be associated to. In the next step, the tutor will be forced to select an appointment from his previous meetings that associate with that student. Therefore, a tutor will not be allowed to rate/review a student that he or she has not tutored. However, the tutor will be able to make multiple ratings/reviews of the same student for different meetings if this occurs. A tutor will be able to edit the rating/review once it has been made. All that needs to be done is to reselect the same student, and click on the same appointment to edit.

Once this is complete, two choices will have to be made by the tutor simultaneously. The tutor will have to either submit a review or not. If a textual review (limited to up to 200 characters) is made, it will be submitted to the database and stored. If there is not input, the result for the review will be null. The tutor will also choose to input a rating. If there is a rating (a Natural Number input between 0 and 5) the rating will be stored. After being stored, it will update the running average for the student, and an average rating will be displayed for the student. If no rating is put in, the rating will be recorded as null.

The tutor will then be forced to click the submit button. If both inputs for the rating and review are null, the data will not be recorded in that database. If one of the elements has an input, then the data will be recorded in the database. If there are no inputs for both entries, nothing will be recorded in the database.

5.) Cancel Appointment (Tyler Watson)

This use case deals with when a tutor must cancel an appointment that they have previously accepted and has been scheduled. Upon cancellation, both the student(s) and the manager must be informed that the meeting has been cancelled. This would be done via email. The reason for the cancellation could be one of two circumstances. It may be because a tutor has become unavailable for some reason. In that case, the tutor availability page would keep those days marked as unavailable and would not allow for another student to book those times. However, the tutor may have cancelled for another reason, such as not wanting to meet with that particular student, but may still be available. In that case, their availability would be updated to mark those dates as available for another student to book. Either way, the tutor is then notified by the system via email of the cancellation.