Skip to content
GodDrinkTeJAVA edited this page Oct 5, 2019 · 54 revisions

Tutoring Machine, Automate Your Matching for Tutoring

Project Requirements and Specification

Project Requirements and Specification
(Borrowed and Adapted from UCB CS169)

Tutoring Machine
Requirements and Specification Document
10/05/2019, version 1.0.9


1. Project abstract

Tutoring Machine is an automatic system for tutor-matching, and it is expected to automate great portion of tasks for both operator and user side. It consists of three main functions. First, Tutoring Machine provides appropriate matches between tutors and tutees. Based on information provided by both sides, Tutoring Machine suggests the optimized choices. The condition includes time schedule, geolocational distance, and tutor’s academic background. Second, Tutoring Machine also provides adequate guideline of tutoring fee for both sides. Usually, the bargain is important part and it can be weary task as financial conflicts are involved. Tutoring Machine provides standard fee through various conditions. For example, if distance between them is longer, their price would be more expensive to compensate their effort. Third, Tutoring Machine reduces great amount of effort from service operator. As the service requires personal documents such as certificate, it is required to be identified and verified. Through Tutoring Machine, tutors just upload their scanned documents, and the service will help organize tutors’ file. Tutoring Machine can read the image and let the documents verified automatically. More specifically, by Microsoft Azure Computer Vision API, Tutoring Machine detects the name of the university and other meaningful texts, and automatically saves it into tutors’ profile.


2. Customer

The possible customer can be divided into two types.
Tutees are people, or groups of people who wish to be taught by proper tutor. They usually become frustrated by flooding list of tutors, which might lead to a panic decision.
Tutors are defined as personal, non-professional people, who are willing to teach in part-time. They have their own schedule such as study. Therefore, they wish their tutoring would not interrupt their prior task.


3. Competitive Landscape

Even today, lots of the service features for matching tutor have primitive, early web-service era form. Usually the service such as SeoulIn is operated in old-fashioned board system, where tutees post the recruits for their personal tutor. Also, identifying and verifying certificates needs to be handled by service staffs. Those manual works are cumbersome for tutor as it can be prone to leak and be handled only when staffs have spare time to take.
Tutoring Machine is a game changer and it can reform the former age-old matching system.
First, the system itself can check the conditions given by tutors and find the most appropriate tutee. In existing systems, tutors are simply listed in a first-come-last-served order. It is way harder to find the tutor in their location, teaching what they want to learn, and even in the right spot of schedule. In Tutoring Machine, it is planned to suggest the best option for tutees.
Second, for system operators, current system forces them to do manual work, distracting them from concentrating real task. In almost every similar webpage, it requires tutors to hand in their documents, such as certificate. However, it should be sent by mail or tutors should bring it to the operator. Not only is this task cumbersome for tutors, but this is also a bothering routine for system operators. Tutoring Machine just requires tutors to attach their scanned image of documents, and it would be handled by computer vision to read and verify.


4. User Stories

Feature: Sign up as a tutee

Actors:

Tutee

Precondition:

No Precondition is needed

Trigger:

User (the tutee or parents) clicks on the "Sign up" button on main page

Scenario:

  1. The page shows the buttons to choose whether the user wants to register as tutee or tutor
  2. Sign up page displays the form to fill out where tutee's personal information (name, age, phone number, schedule) and ID goes in
  3. The user fills out the form and marks some schedules on timetable

Exceptions:

  1. When the user does not input proper information (Duplicated ID, non-integer value on age ... etc.) and clicks "sign up" button, then "should rewrite (information)" and displays "sign up" page again.

Acceptance Test:

Given the user has filled out all the form.
When the user clicks on the "Sign up" button,
then the user should see "Completed" message.

Feature: Sign up as a tutor

Actors:

Tutor

Precondition:

No Precondition is needed

Trigger:

User (the tutor) clicks on the "Sign up" button on main page

Scenario:

  1. The page shows the buttons to choose whether the user wants to register as tutee or tutor
  2. After choosing, sign up page displays the form to fill out where tutor's personal information (name, age, level of education, schedule) and ID goes in
  3. The user fills the blanks, uploads the certificate and marks some schedules on timetable
  4. After the test of certificate, the user clicks "Sign up" button

Exceptions:

  1. When the user does not input proper information (ID duplication, text on age ... etc.) and clicks "sign up" button, then page alerts "should rewrite ~~(information)" and displays "sign up" page again.
  2. When the user uploads wrong certificate file, then page shows text "unidentified certificate" and nothing happens.

Acceptance Test:

Given the user has filled out all the form and certificate.
When the user clicks on the "Sign up" button,
then the user should see "Completed" message.

Feature: Sign in

Actors:

Tutee or tutor

Precondition:

The user has signed up

Trigger:

User (the tutee or the tutor) clicks on the "Sign in" button

Scenario:

  1. Log-in page displays input elements for ID and password
  2. The user enters ID and password and clicks "Sign in" button

Exceptions:

The user enters wrong ID or password. Then, pop-up for indicating invalid values has been put.

Acceptance Test:

Given the user entered the ID and password.
When the user clicks on the "Sign in" button,
then the user should see tutor's page or customer's page.

Feature: Upload Schedule

Actors:

Tutee or Tutor

Precondition:

The tutee or tutor has signed up

Trigger:

User clicks on the ‘Upload Schedule’ button.

Scenario:

  1. The page shows a set of blank squares which consist of time table, and a map from external API next it
  2. Each cell can be checked by dragging, which can be displayed in distinct color
  3. After the user finishes dragging, the map requires the user to provide the geolocational information for the cell

Exceptions:

The user checks the cells but does not put the geolocation ignoring the map, which results in null value. Then, the "Finish" button would be disabled, and the map would be highlighted.

Acceptance Test:

Given the user has filled out schedule as the scenario indicates.
The user clicks on the "Finish" button.
Then, a pop-up that tells the schedule is saved should show up, and the schedule chart should be refreshed.

Feature: Update Profile

Actors:

Tutee or tutor

Precondition:

The tutee or tutor has signed up and classified as one of the parties (tutee & tutor).

Trigger:

User clicks on the 'Update Profile' on their profile.

Scenario:

  1. The page varies as the database provides the variable to distinguish between tutee and tutor.
  2. Both tutee and tutor have 'Delete account', 'Timetable' menus.
  3. Tutee has menu for 'Request tutor'.
  4. Tutor has menus for 'Tutor list'

Exceptions:

The user empties the essential inputs and submits. Then, the pop-up notifies the user that the essential forms are empty.

Acceptance Test:

Given the user has filled out all their forms to update its profile.
The user hits the 'Submit' button.
Then the user should see 'Profile is updated' pop-up, and be redirected to main page.

Feature: Find tutors

Actors:

Tutee

Precondition:

The tutee has signed in.

Trigger:

Tutee clicks on the “Find tutor” button.

Scenario:

  1. The tutee fills in various conditions to find tutor such as subject, academical background, gender, etc.
  2. Tutors come up with recommendation order.
  3. Tutee can change conditions or list tutors with different ordering such as price.

Exception:

When the tutee cannot find any proper tutor. Then the page should show sorry message and advice to change conditions.

Acceptance Test:

Given the tutee has filled out all conditions to find tutors.
The user hits the 'Find tutor' button.
Then the user should see proper tutors list.

Feature: Contact tutor

Actors:

Tutee

Precondition:

Tutee can see proper tutors list.

Trigger:

User clicks the tutor on the list.

Scenario:

  1. Clicked tutor’s detailed profile came out with pop-up.
  2. Tutee can see tutor’s detailed profile and reviews.
  3. Tutee can send message to the tutor by clicking “send message” button

Exception:

When tutor has no contact info. Then the tutor should not be listed.

Acceptance Test:

Given the tutee clicks one of the tutors on the list.
Pop-up should come out and tutee can see detailed profile and reviews.
Then the tutee click “send message” and tutee can send message to tutor.

Feature: Accept or decline tutee

Actors:

Tutor

Precondition:

The tutor has signed in.

Trigger:

Tutor click “request list” in profile page.

Scenario:

  1. The tutor can check requests that tutee sent.
  2. Tutor can see detail about tutee.
  3. Tutor can accept or decline tutee.
  4. Tutor can send back message to tutee.

Exception:

When the tutor has no request Then “request list” should be disabled.

Acceptance Test:

Given the tutor has received request.
The tutor can see detail about tutee.
Then the can accept or decline the request.

Feature: Pay tuition fee

Actors:

Tutee

Precondition:

Tutee has at least one registered class.

Trigger:

User clicks the “lesson lists” on the profile page.

Scenario:

  1. Tutee can see how much he or she should pay and where he or she should send money.
  2. Tutee can see the period of the classes.

Exception:

When the tutee has no class. Then “lesson list” button should be disabled.

Acceptance Test:

Given the tutee clicked “lesson lists” on the profile page.
Tutee should see tuition fee and period of each lesson and whether it is paid or not.
If the class is not paid, then the user should see the fee and where he or she should send money.

5. Iteration Plan

Team members has discussed the plan for additional features, and agreed with idea that features below are worth considering implementation

For further sprints, these are the additional features to add and expand user stories:

1. Kakaotalk message system.

Not only using message system which our page provides, we can add Kakaotalk message system.

2. Additional payment system.

For now, we only provide the payment system by account transfer. However, we might implement more payment system (card payment, Kakaopay, Naverpay).

3. Sending notification

In present iteration, tutee and tutor should check their matches through profile page. By adding notification system, they can be announced that they have got their responses without checking profile manually.

4. Detecting fake certificate

In present iteration, computer vision API is used only to read and save the text on the document to the profile. However, as API provides the coordinate of each text, differentiating real certificate from fake one can be possible to implement

6. interface sketch

images/01edit.png images/02edit.png

Clone this wiki locally