Skip to content

Use Case Diagrams

jerryled edited this page Oct 14, 2019 · 7 revisions

Use Case 1: User Register & Log In


Identifier: Requirement 1 & 2

Author: Talha Riaz

Primary Actor: Student

Secondary Actor: Manager

Intention: The user must be able to log in to use the Tutoring System.

Precondition: Not required.

Main Scenario: The user must be able to register on the tutoring system using a unique username and a password. The user must then be able to login using the credentials used to register on the tutoring system. Upon providing the login credentials, the tutoring system will verify the provided credentials. Once the credentials match with the file on record, the user will be logged in to the tutoring system.

Alternatives/Exceptions: On registration, if the username is not unique and has already been used before, the tutoring system will display an error message and will not allow the registration until a unique username is provided to register. On login, if the provided login credentials are incorrect, the tutoring system will display an error message and will not allow the login to proceed until correct login credentials have been provided.

Post-condition(Success): The student successfully logs in and is able to use the tutoring system.

Post-condition(Failure): The student fails to log in and is unable to use the tutoring system until a valid registration and login routine is followed.

Use Case 2: Search for Course / University / Subject


Identifier Requirement 3, 4, 5&6

Author: Erdong Luo

Primary Actor Student

Secondary Actor Tutoring System

Intention The student is able to search using the subject/course number/university.

Precondition The student must already be logged into the system.

Main Scenario After the student is logged in and navigates to the search area, the students must be able to select from "search by subjects", "search by course number" and "search by university". After the student makes their decision, the tutoring system will provide the corresponding list and an input box. The student must be able to browse the list as well as search the course by typing the subject/course number/university into the input box and press the search button to find the course he wants. After the student finds his target course, the tutoring system will show all the available tutors that are able to teach this course as a list. The student must be able to browse the list and choose the tutor he wants to know about. After the student click on the tutor's name, the tutoring system will show the reviews, ratings and hourly rate of that tutor. The student should also be able to search by tutor. Similarly, they will be able to find tutors and select each to see the reviews, ratings, hourly rates, and which courses they are tutoring.

Alternatives/Exceptions If the student type a course number/ subject that doesn't exist in the tutoring system, the tutoring system will display an error message and ask the student to send an e-mail to the manager to add that course. If the student enters no text in any boxes the full list will appear.

Post-condition(Success) The student successfully finds the target course and sees the available tutors.

Post-condition(Failure) The student failed to find the target course and has to send an e-mail to the manager to add that course. Or the student fails to find the specified tutor.

Use Case 3: Book Session


Identifier Requirement 8, 9, 10 & 11

Author: Zheng

Primary Actor Student

Secondary Actor Tutor, Manager

Intention Booking a session with a tutor for a selected course

Precondition Student must be logged in to the system

Main Scenario The student logs in to the system and searches for a particular course. The system lists the search results, after selecting the course, the system provides a list of tutors for that course. The student then selects the tutor after viewing their profile and requests a session with the tutor by providing the date and times. The system then notifies the tutor for the session request and also checks if a room is available at the requested time. If the tutor accepts the session and if a room is available, the session is booked.

Alternatives/Exceptions If the Tutor denies the session request, the session is not booked and a booking error message is displayed. Alternatively, even if the tutor accepts the session request but a room isn't available for the requested time, the session booking is not complete and a booking error message is displayed.

Post-condition(Success) The session is successfully booked, a room is assigned to the session is made unavailable to other bookings for the time duration of the booked session.

Post-condition(Failure) The session is not booked and the student is redirected to the tutor list and can start over.

Use Case 4: Cancel Session


Use Case Diagram

Identifier: Requirement 12

Author: Mustafain

Primary Actor: Student

Secondary Actor: Tutor

Intention: The Student should be able to cancel a session up to 24 hours before the session starts.

Precondition: The Student should be logged in and must have a scheduled session

Main Scenario: A student can cancel their session. The only restriction is that the cancellation can be done 24 hours before the scheduled time of the session. Therefore, the system will verify this time constraint and if the time constraint is met, the system will notify the tutor about the cancellation and make the room available for other sessions.

Alternatives/Exceptions: If the time constraint is not met, the system will not cancel the session and instead will display an error message explaining that the cancellation request was within 24 hours of the scheduled session time.

Post-condition(Success): The room booked for the session is available for future sessions, and the tutor is notified regarding the cancellation. The session is successfully cancelled.

Post-condition(Failure): The session is not cancelled if time constraint isn't verified, implying that the student will have to pay for the session.

Use Case 5: Post-Session Review


Identifier: Requirement 13 & 14

Author: Paul

Primary Actor: Student

Secondary Actor: Tutor, Manager

Intention: The student shall be able to write reviews for the tutor after the session and the tutor shall be able to review the student.

Precondition: The tutoring session must have been completed before the review can be written.

Main Scenario: After the tutoring session, both the tutor and the student have the option to write a review for the tutor on the system. The manager is a secondary actor and is able to moderate the reviews for profanity.

Alternatives/Exceptions: If the user chooses they shall be able to return to a leaving a review later on. Invalid characters entered shall not be accepted in the reviews.

Post-condition(Success): The review is anonymously added to the system. Future students can read the reviews for the tutor before they book a session. Future tutors shall also be able to read the reviews of students who are attempting to book with them

Post-condition(Failure): Neither leave a review and nothing will be added to the database