3. System Features

3.1 User details

3.1.1 Description and Priority

Provides your typical user profile details such as age, gender, phone number and email. The user can also edit their details. It has a relatively high priority since renters must be comfortable and know who is taking their children, including the passengers with them. Although, if the developers chose to skip this feature, it could negatively affect of the success rate of the project.

3.1.2 Functional Requirements

REQ-1:The system shall show the user the specified user profile.

REQ-2:The user shall be able to change their user profile details.

3.2 Sending messages

3.2.1 Description and Priority

The renter and the driver can message each other through the app. The priority is low on this feature, and it is not very necessary to implement but can be very beneficial to the user experience.

3.2.2 Functional Requirements

REQ-3: The user shall send messages once the order is confirmed

REQ-4: The system shall be able to fetch messages from the other user.

3.3 View previous trips

3.3.1 Description and Priority

The renter can see what places they have been to. It’s low priority feature but it can help the customer service team since to diagnose any issues the renter had.

3.3.2 Functional Requirements

REQ-3: The system shall fetch the specified user data from the database.

REQ-4: The system should be able to show completed trips.

3.4 Vehicle capacity

3.4.1 Description and Priority

This feature will inform the driver before taking the renters of how many people there are to take. This will make sure that the number of renters doesn't exceed the capacity of the vehicle. This feature has high priority, because having the driver go to the renters and being not able to take them all is wasting of the renters and driver time.

3.4.2 Functional Requirements

REQ-5: The system must not accept a renter request if it exceeds the trip capacity

3.5 Rating the users

3.5.1 Description and Priority

The renter can see the driver's ratings and see the comments on his trips if there's any comments and can rate the driver or comment after the trip.

The driver can see the renter's ratings and if there any comment, as well as rating the renter and see the ratings and the comments after finishing a trip.

The priority of this feature is high.

3.5.2 Functional Requirements

REQ-6: The system should show the driver's ratings to the renter.

REQ-7: The system should show the comments on the driver's previous trips to the renter.

REQ-8: The renter should be able to rate the driver after a trip.

REQ-9: The renter should be able to comment on the trip they took with the driver.

REQ-10: The system should allow the driver to rate the renter.

REQ-11: The system should allow the driver to comment on the renter.

REQ-12: The driver should be able to see the ratings after a trip is done.

REQ-13: The driver should be able to see the comments after a trip is done.

3.6 Student arrival verification

3.6.1 Description and Priority

This feature will send a message to the renters that the students have arrived at the school. The priority of this feature is high, and its priority is 9 out of 9 in the safety terms.

3.6.2 Functional Requirements

REQ-14: The driver must confirm that the students have arrived at the school

REQ-15: The system shall send a message to the renter upon arrival of the student.

3.7 Create new trip

3.7.1 Description and Priority

In this feature the driver can specify the type of trip whether it’s from school to neighbor or from school to neighbor. The priority of this feature is High, because the renters must know the destination of the driver to achieve the goal of this app. The cost is 6 out of 9 since there will be a need for locating the destination of a trip. The benefits 9 out of 9 for the user since it will help them identify the best option/driver for their wanted trip.

3.7.2 Functional Requirements

REQ-16: The system shall ask for the driver’s initial destination.

REQ-17: The system shall ask for the driver’s final destination.

REQ-18 : The system shall ask the driver to the type of the trip.

REQ-18.1 : The system shall make a type called from school to housing.

REQ-18.2 : The system shall make a type called from housing to school.

REQ-19 : The system shall ask the driver to enter the time at which the trip starts.

REQ-19.1 : The system shall make the timings of the trips of 15 minutes slots.

3.8 KFUPM Portal verification

3.8.1 Description and Priority

This feature requires all users to verify that they’re KFUPM members when creating a new account through KFUPM Portal. The priority of this feature is High since users would feel safe if all users are verified KFUPM members. The cost 5 out of 9 since the system would only shift the user to the Portal page. The Risk 7 out of 9 since there’s a chance for system’s failure if the Portal is not available.

3.8.2 Functional Requirements

REQ-20: The system shall shift the user to the KFUPM portal page to verify that he/she is a KFUPM member.

REQ-21: The system shall return the user to the app after the verification.

REQ-22: The system shall Not continue with the creation of the account if the verification failed.

3.9 Create schedules

3.9.1 Description and Priority

This feature will allow the users to create and view their schedule, and this can help them to decide whether renting a driver is needed. The priority of this feature is low, and its priority is 3 out of 9 in terms of benefits of the user.

3.9.2 Functional Requirements

REQ-23: The app shall allow the user to show the schedule

REQ-24: The one who is intended to drive to school should get an alert in case there are conflicts between the trip time and the schedule.

REQ-25: The app shall allow the user to create the schedule

3.10 Show driver location

3.10.1 Description and Priority

This feature will allow the renter to see the driver's location on the map while taking the renter's Kids. The priority of this feature is high.

3.10.2 Functional Requirements

REQ-26: The system should allow the renter to see the driver's location on the map.

3.11 In-App wallet

3.11.1 Description and Priority

This feature will hold the money of the user. It will allow the renter to pay the driver or will let the driver return the change to the renter if he doesn’t have cash. This feature has a medium priority, that is because the users could use cash instead of using the in-app wallet, but it will make the process much easier.

3.11.2 Functional Requirements

REQ-27: The system should support apple to deposit to the in-app wallet.

REQ-28: The system should support credit card deposit to deposit to the in-app wallet.

REQ-29: The system should support bank transcription to deposit to the in-app wallet.

REQ-30: The system should support SADAD to deposit to the in-app wallet.

REQ-31: The system should support bank transcription to withdraw to the personal bank.

REQ-32: The system shall allow the renter to transfer money to the driver’s in-app wallet.

REQ-33: The system shall allow the driver to transfer money to the renter’s in-app wallet.

3.12 Create a new account

3.12.1 Description and Priority

This feature allows the user to create a new account the first time he/she enter the app. The data required at this use case are the user’s name, contact information and KFUPM portal log in information.

3.12.2 Functional Requirements

REQ-34 : The system shall ask the user to enter the main 3 information; e-mail, phone number, password.

REQ-35 : The system shall make sure the e-mail entered is not the same as KFUPM e-mail.

REQ-36 : The system shall make the password digits not less than 8.

REQ-37 : The system shall pull all user’s other KFUPM data from database after the KFUPM membership is verified.

REQ-38 : The system shall make sure the phone numbers are not repeated.

3.13 Search for a trip

3.13.1 Description and Priority

In this feature the renter can search for a trip by specifying the intended destination, either to a school or to the housing. The renter can see all the available trips, and see their driver’s information before selecting one.

3.13.2 Functional Requirements

REQ-39 : The system shall allow the renters to search for a trip based on the 2 destination criteria.

REQ-40 : The system shall make the first destination criteria as from school to housing.

REQ-41 : The system shall make the second destination criteria as from housing to school.

REQ-42 : The system shall allow the user to search for a trip based on the driver’s rating.

REQ-43 : The system shall allow the user to search for a trip based on the number of available capacity.

3.14 Request a ride

3.14.1 Description and Priority

This feature allows the renter after finding the best trip for him to request a ride, so the driver can drive the kid to their common destination. The request maybe completed or not, depending if the ride is full or if the driver for some reason didn’t accept the request.

3.14.2 Functional Requirements

REQ-44 : The system shall allow the renter to request a trip.

REQ-45 : The system shall NOT add the trip if the trip capacity is full .

REQ-46 : The system shall allow the user to specify the number of passenger when requesting the trip.

REQ-47 : The system shall clarify to the user the reason –if - the trip was not accept it.

3.15 Switch role

3.15.1 Description and Priority

The feature allow the user to switch the role either to driver or renter, so user can use each function for the specific role he/she want at that time. The default role is renter, unless the user wants to switch to driver. All user’s information are saved into either a driver or a renter classes.

3.15.2 Functional Requirements

REQ-48 : The system shall make a button to switch the user rule from driver to renter.

REQ-49 : The system shall make a button to switch the user rule from renter to driver.

REQ-50 : The system shall make sure that all user’s information is transformed to the selected rule.

REQ-51 : The system shall make sure that all driver functionality are available in the driver role.

REQ-52 : The system shall make sure that all renter functionality are available in the renter role.

REQ-53 : The system shall make sure that the user’s default role is renter.

3.16 Log in

3.16.1 Description and Priority

This feature allows users to login into his/her account using the user’s phone number or e-mail. The feature has an authentication using code sent to the user via SMS or e-mail.

3.16.2 Functional Requirements

REQ-54 : The system shall allow users to log in into their account using e-mail.

REQ-55 : The system shall allow users to log in into their account using phone number.

REQ-56 : The system shall verify users using verification number sent to their mobile phone.

REQ-57 : The system shall verify users using verification number sent to their e-mail.

4. Detailed Requirements

4.1 UML Use case Diagram

4.2 Functional Requirements

4.2.1 Requirements 16 - 19 : Create new account

Priority High

Effort 8 days

Risk High

Use Case(s) UC-7

Notes

4.2.1.1 UC 7 : Create new trip

Use Case ID: UC-7

Use Case Name: Create new trip.

Created By: Ammar

Date Created: 2022/4/1

Actors:

All above 5 requirements have the same use case.

1. The Driver

2. The System

Description: The driver enters the initial and final location of the trip. And specify the type of the trip, as well as the capacity.

Trigger: The driver wants to create a new trip.

Preconditions:

Post conditions:

1- The driver has a valid account.

2- The driver has no current trip.

1- The trip is added to the trips list.

2- The driver can’t add another trip.

3- The trip is available for renters.

Normal Flow:

1. The driver selects on “add new trip”.

2. The system promotes the driver to enter his/her start location.

3. The driver selects his/her start location.

4. The system promotes the driver to enter his/her final destination.

5. The driver selects his/her final destination.

6. The system promotes the driver to select the type of the trip.

7. The driver selects the type.

8. The system promotes the user to select the time the trip starts at.

9. The driver selects the time.

10. The system promotes the driver to enter the trip capacity 2 to 7.

11. The driver enters the capacity number.

12. The system promotes the driver to select “Confirm “or “Edit”.

13. The trip is added

Alternative Flows: [Edit]

At step 12 if the driver wants to modify trip information,

1. Actor enters the information again. Resume at step 13.

Dependencies (Includes and extends relationships)

Extend (Edit)

Frequency of Use: High

4.2.2 Requirements 20 - 22 : KFUPM Portal verification

Priority High

Effort 4 days

Risk Medium

Use Case(s) UC-8

Notes All above 5 requirements have the same use case.

4.2.2.1

UC 8 : KFUPM Portal verification

Use Case Name: KFUPM Portal Verification

Created By: Ammar

Date Created: 2022/4/1

Actors:

1. User.

2. The system.

Description: This function makes sure that the user is a KFUPM members. If not the system will not allow the user to continue with the creation of the account.

Trigger: The user wants to create a new account.

Preconditions:

Post conditions:

Normal Flow:

1. The user entered his/her main information to create the account.

1. User account is verified.

2. The data of the new account is sent to the database.

1. The user selects on “Verify KFUPM membership”

2. The system promotes the user to enter his/her portal log in information.

3. The system verify that the entered data are correct KFUPM portal log in information.

4. User account is verified.

Alternative Flows: 3b. In step 3 of the normal flow if the data are incorrect,

1. The system promote the user to enter the data again

2. Use Case resume from step 4.

Dependencies (Includes and extends relationships) Extend (verify entered data)

Frequency of Use: Low

4.2.3 Requirements 34-38 : Create New Account

Priority High

Effort 6 days

Risk High

Use Case(s) UC-12

Notes All the above requirements have the same use case.

4.2.3.1 UC 12: Create new Account

Use Case Name: Create new Account

Created By: Ammar

Date Created: 2022/4/1

Actors: 1- User.

2- The system.

Description: The function allows the user to create a new account at by entering the required information.

Trigger: The user selects on create new account.

Preconditions: The user hasn’t logged in to the account yet.

Post conditions: A new account has been created.

Normal Flow:

1. The system promotes the user to enter his/her non-KFUPM e-mail.

2. The user enters the e-mail.

3. The system promotes the user to add a phone number.

4. The user enters the phone number.

5. The system promotes the user to create a new password.

6. The user enters the password.

7. The system promotes the user to add verify his/her KFUPM account log in information.

8. The system pulls user’s KFUPM data from database. 5.

Alternative Flows: 2b. In step 2 of the normal flow if the user entered a KFUPM email,

1. The system promotes the user to enter the data again

2. Use Case resume from step 3.

4b. in step 3 of the normal flow if the user enters existing phone number,

1. The system promotes the user to enter the data again

2. Use Case resume from step 5. 3.

Dependencies (Includes and extends relationships) include (verify entered data)

Frequency of Use: Low

4.2.4 Requirements 39-43 : Search for a trip

Priority High

Effort 10 days

Risk High Use Case(s) UC-13

Notes All the above requirements have the same use case.

4.2.4.1 UC 13: Search for a trip

Use Case Name: Search for a trip

Created By: Ammar

Date Created: 2022/4/12

Actors: 1- Renter.

Description:

2- The system.

This use case allows the user to find all available trip, and filter them on various criteria.

Trigger: The renter selects on search for a trip.

Preconditions: The renter has no requested trip.

Post conditions: Renter finds the most convenience trip for him/her.

Normal Flow:

1. All available trips are shown for the renter. Alternative Flows: [Trip type]

At step 1 if the renter wants to filter trips based on type,

1. Renter selects type.

2. Available trips based on the type are shown. Use case ends.

[Driver ratings]

At step1 if the renter wants to sort results based on ratings.

1. Renter selects on “Sort by Rating “

2. Trips are sorted based on rating. Use case ends.

[Available capacity]

At step 1 if the renter wants to sort trips based on available capacity,

1. Renter selects on “Sort by Available capacity “

2. Trips are sorted based on available capacity. Use case ends.

[Trip timing]

At step 1 if the renter wants to sort trips based on start of the trip time,

1. Renter selects on “Sort by time “

2. Trips are sorted based on timing. Use case ends

[Refresh]

At step 1, if the renter wants to reset search criteria,

1. Renter selects on refresh.

2. All available trips are shown. Use case ends.

4.

Dependencies (Includes and extends relationships) Extends (Trip type) Extends (Driver ratings) Extends (Available capacity) Extends (Refresh) Extends (Trip Timing)

Frequency of Use: High

4.2.5 Requirements 44-47: Request a Ride

Notes

4.2.5.1 UC 14: Request a Ride

Use Case Name: Request a ride

Created By: Ammar

Date Created: 2022/4/12

All the above requirements have the same use case.

Actors: 1- Renter.

Description: The function allows the renter to request the wanted trip.

Trigger: The renter selects on request trip.

Preconditions: The renter has no existing trip.

Post conditions: The renter is added to the trip.

Normal Flow:

1. The system promotes the renter to specify the number of passengers.

2. The renter selects number of passengers.

3. The renter selects confirm.

Alternative Flows: [exceeding capacity number]

At step 2 if the user wants to logs in using his/her e-mail,

1. The user enters the number again. Use case resume from step 2.

Dependencies (Includes and extends relationships) exceeding capacity number]

Frequency of Use: High

4.2.6 Requirements 48-52: Switch Role

All the above requirements have the same use case.

4.2.6.1 UC 15: Switch Role

Use Case Name: Switch role

Created By: Ammar

Date Created: 2022/4/12

Actors: 1- User.

2- The system.

Description: This use case allows the user to switch his/her current role either to a driver or to a renter. The default role is Renter.

Trigger: The user enters the app’s Home Page.

Preconditions: The user has logged into to the account.

Post conditions: User switch to the wanted role.

Normal Flow:

1. User selects on “Switch to driver”.

2. User is shifted to the driver page.

Alternative Flows: [User is a driver]

At step 1 if the user is in the driver page and wants to switch to the renter,

1. User selects on “Switch to renter”.

2. User is shifted to the renter page. Use case ends.

Dependencies (Includes and extends relationships) Extends (User is a driver)

Frequency of Use: Medium

4.2.7 Requirements 54-57: Log in

Priority High

Effort 3 days

Risk High

Use Case(s) UC-16

Notes

4.2.7.1 UC 16: Log in

Use Case Name: Log in

Created By: Ammar

Date Created: 2022/4/12

Actors:

All the above requirements have the same use case.

1- User.

2- The system.

Description: The function allows the user to log in into his/her existed account.

Trigger: The user selects on Log in.

Preconditions: The user has an existed account.

Post conditions: The user is logged into his/her account.

Normal Flow:

1. The system promotes the user to enter his phone number.

2. User enters his/her phone number.

3. The system send verification code to the entered phone number.

4. User enter the code.

4. The system logged the user into his/her account.

Alternative Flows: [E-mail log in]

At step 1 if the user wants to logs in using his/her e-mail,

1. User selects on “log in using e-mail ”.

2. User enters his/her e-mail address.

3. The system sends verification code to the entered e-mail.

4. User enter the code. Use case resume from step 5.

Dependencies (Includes and extends relationships) extends (E-mail log in)

Frequency of Use: Medium

4.2.8 Requirements 25 - 29 : In-App wallet