-
Notifications
You must be signed in to change notification settings - Fork 1
Home
Project Requirements and Specification
(Borrowed and Adapted from UCB CS169)
Tutoring Machine
Requirements and Specification Document
10/05/2019, version 1.0.36
Tutoring Machine is an automatic system for tutor-matching, and it is expected to automize 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, someone needs to identify and verify them. Through Tutoring Machine, tutors just upload their scanned documents, and the service will help organize tutors’ file. Computer vision comes into the task and reads the texts and its composition. By Microsoft Azure Computer Vision API, it detects the name of the university and other meaningful texts, and automatically saves it into tutors’ profile.
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.
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 is 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.
Feature: Sign up as a tutee
Tutee
No Precondition is needed
User(the tutee or parents) clicks on the "Sign up" button on main page
- The page shows the buttons to choose whether the user wants to register as tutee or tutor
- Sign up page displays the form to fill out where tutee's personal informations(name, age, phone number, schedule) and ID goes in
- The user fills out the form and marks some schedules on timetable
- When the user does not input proper information(Duplicated ID, non-integer value on age ... etc) and clicks "sign up" button, then "should rewrite (informations)" and displays "sign up" page again.
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
Tutor
No Precondition is needed
User(the tutor) clicks on the "Sign up" button on main page
- The page shows the buttons to choose whether the user wants to register as tutee or tutor
- After choosing, sign up page displays the form to fill out where tutor's personal informations(name, age, level of education, schedule) and ID goes in
- The user fills the blanks, uploads the certificate and marks some schedules on timetable
- After the test of certificate, the user clicks "Sign up" button
- When the user does not input proper information(ID duplication, text on age ... etc) and clicks "sign up" button, then page alerts "should rewrite ~~(informations)" and displays "sign up" page again.
- When the user uploads wrong certificate file, then page shows text "unidentified certificate" and nothing happens.
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
Tutee or tutor
The user has signed up
User(the tutee or the tutor) clicks on the "Sign in" button
- Log-in page displays input elements for ID and password
- The user enters ID and password and clicks "Sign in" button
The user enters wrong ID or password. Then, pop-up for indicating invalid values has been put.
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
Tutee or Tutor
The tutee or tutor has signed up
User clicks on the ‘Upload Schedule’ button.
- The page shows a set of blank squares which consist of time table, and a map from external API next it
- Each cell can be checked by dragging, which can be displayed in distinct color
- After the user finishes dragging, the map requires the user to provide the geolocational information for the cell
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.
Given the user has filled out schedule as the scenario indicates.
The user clicks on the 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
Tutee or tutor
The tutee or tutor has signed up and classified as one of the parties(tutoee & tutor).
User clicks on the 'Update Profile' on their profile.
- The page varies as the database provides the variable to distinguish between tutee and tutor.
- Both tutee and tutor have 'Delete account', 'Timetable' menus.
- Tutee has menu for 'Request tutor'.
- Tutor has menus for 'Tutor list'
The user empties the essential inputs and submits. Then, the pop-up notifies the user that the essential forms are empty.
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
Tutee
The tutee has signed in.
Tutee clicks “Find tutor”.
- The tutee filled in various conditions to find tutor such as subject, academical background, gender, etc.
- Tutors come up with recommendation order.
- Tutee can change conditions or list tutors with different ordering such as price.
When the tutee cannot find any proper tutor. Then the page should show sorry message and advice to change conditions.
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
Tutee
Tutee can see proper tutors list.
User clicks the tutor on the list.
- Clicked tutor’s detailed profile came out with pop-up.
- Tutee can see tutor’s detailed profile and reviews.
- Tutee can send message to the tutor by clicking “send message” button
When tutor has no contact info. Then the tutor should not be listed.
Given the tutee click one of the tutor 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
Tutor
The tutor has signed in.
Tutor click “request list” in profile page.
- The tutor can check requests that tutee sent.
- Tutor can see detail about tutee.
- Tutor can accept or decline tutee.
- Tutor can send back message to tutee.
When the tutor has no request Then “request list” should be disabled.
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
Tutee
Tutee has at least one registered class.
User clicks the “lesson lists” on the profile page.
- Tutee can see how much he or she should pay and where he or she should send money.
- Tutee can see the period of the classes.
When the tutee has no class. Then “lesson list” button should be disabled.
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.
Team members has discussed the future plan for 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:
Not only using message system which our page provides, we can add kakaotalk message system.
For now we only provide the payment system by acount transfer. However we might implement more payment system(card payment, kakaopay, naverpay).
