Carpool SRS

SWE 216

Software Requirements Specification (SRS) Template

The document in this file is an annotated outline for specifying software requirements, adapted from the IEEE Guide to Software Requirements Specifications (Std 830-1993).

Tailor this to your needs, removing explanatory comments as you go along. Where you decide to omit a section, you might keep the header, but insert a comment saying why you omit the data.

Software Requirements Specification for KarPool

Version 1.0 approved

Prepared by Team 6

KFUPM

2/20/2022

Revision History

1. Introduction

1.1 Purpose

The purpose of the KarPool app is that it reduces the number of cars driving on the university’s roads by combining many trips for those who have the same endpoint (school) into one trip using only one car.

• KarPool : give a general idea of the app and its features and the detailed requirements that the app should be built based on it.

• Version: 1.0

1.2 Document Conventions

The font that is used in this SRS is “Arial”. Some abbreviations that have been used in this SRS:

• SRS: software requirements specifications.

• Carpool/Carpooling: multiple people using the one car instead of using multiple cars.

• 2FA: 2 Factor Authentication.

1.3 Intended Audience and Reading Suggestions

This project targets people who are unable to take their children to school. The document is intended for developers and project managers. Developers will need this document to understand the documentation which will help them understand the pre-existing features so they can implement other new features that are integrated within the system. As for project managers, it guides them to understand the vision of the project and how it will work later down the line.

1.4 Project Scope

KarPool is an app aims to help parents who can’t drive their children to schools by sending them with other parents who’re heading to the same school/ neighborhood as their children’. The main goals of the system are to reduce morning traffic in campus, and to solve time conflicts KFUPM members face with their work and drooping their children. The objectives of the system are:

1- To make sure users using the app more often, KFUPM members should have a better experience using the app.

2- By making sure parents feel safe about the experience, more KFUPM members would use it.

1.5 References

Stack Overflow: https://stackoverflow.com/questions/20184055/what-if-any-is-thedifference-between-a-software-release-and-a-version/20184757.

2. Overall Description

2.1 Product Perspective

KarPool is a new product that comes to solve certain problems within the university compound. It started with observing that there are conflicts between the schedule of the university’s faculty and their children who need to go to school. Initially, the concept of ordering rides came from transportation apps, such as Uber, Kareem and Bolt.

2.2 Product Features

From the renter’s perspective: The product will allow the user to rent a driver who can drive the children of the user to the school by showing the driver’s information

From the driver’s perspective: The product will allow the driver to see who wants this service and have a choice of whether to accept it or not.

2.3 User Classes and Characteristics

The user classes that will be used are:

Renter:

1- Can request a service from the driver

2- Can navigate where the driver is until the children reach the school

3- Moderate technical expertise

4- Very important to satisfy

Driver:

1- Can accept ride requests

2- Interaction with the app is very low since they are driving

3- Low technical expertise

4- Very important to satisfy

Customer service:

1- Can communicate with the app users and help them with any issues

2- Have a certain administration

3- High technical expertise

4- Have to be fairly satisfied

2.4 Operating Environment

The app will be used in the KFUPM community. The hardware platform that the system will operate is ARM. It would be available on both iOS 14 and above and android 10 and above. The software does not require any external components.

2.5 Design and Implementation Constraints

The main constraint will be developing the system using Java and Flutter API. The system’s memory usage shall not exceed 75% of the hardware’s memory which means the program must work efficiently and not waste device’s resources. The system must comply with the regulations of the ministry of transportation.

As for using other technologies, the system will be using Microsoft’s Azure services to keep the system’s online services up and running.

Since 2FA is much more effective than passwords, the user can choose not to use passwords to log in and use 2FA instead, but they must verify their phone number before that. When it comes to implementing new security features, the developers must make sure that the user doesn’t lock themselves out of their account.

2.6 User Documentation

The app will have a tutorial at the first time launching for every user. A support number will be available within the app that can assets the user at any time. The software will have a wiki page explaining the features and how to use them. It will also have hint icons that explain what that feature is.

2.7 Assumptions and Dependencies

The development team has experience of integrating the commercial components which will be used later. The university has database servers capable of operating the system. Assuming the system can be operated in IOS and Android. The development team should know the latest regularities from the ministry of transposition and implement the system upon them. The system will assume that the architecture of the CPU is ARM, meaning it will not run on x86 or RISC. The system also assumes that the device has Java installed. The user’s account can be logged in by more than one device. KFUPM IT department allowing usage of the all KFUPM portal log in data to verify that all users of the app are KFUPM members.

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

Software Requirements Specification for KarPool

Priority Medium

Effort

7 Days

Risk Low

Use Case(s)

Description

UC-17,UC-18

This requirement should keep record of how much the user have and allow him to deposit to this in-app wallet and withdraw from it.

Notes No note here

UC 17: UC Deposit money

Use Case ID: UC-17

Use Case Name: Deposit money

Created By: Omar Al-Najjar

Date Created: 4/4/2022

Actors: Primary: user of app Secondary: Banks

Description: This use case should offer ways to deposit and increase the balance after depositing.

Trigger: Click the button of deposit

Preconditions:

Post conditions:

Normal Flow:

1- The user clicks the deposit button

2- The system prompts the user to enter the amount wanted to be deposited and the method of depositing

3- The user enters the amount and credit card as method

4- The system open a window of the bank website to enter the credit card details

5- The user enters the details of the credit card

6- The system withdraw the money from the credit card

7- The system shows a successful deposit message

8- The system shows the home page

Alternative Flows: 3a.

1- The user enters the amount and SADAD as method

2- The system open a window of the bank website to enter the SADAD details

3- The user enters the details of the SADAD

4- The system withdraw the money from the account

5- Go back to 7 3b.

1- The user enters the amount and bank transaction as method

2- The system open a window of the bank website to enter the bank transaction details

3- The user enters the details of the bank transaction

4- The system gets the money from the bank transaction

5- Go back to 7 3c.

1- The user enters the amount and apple pay as method

2- The system shows the apple pay window to chose the card that the user wants to deposit from

3- The user choses the card

4- The system withdraw the money from the chosen card

5- Go back to 7

Dependencies (Includes and extends relationships)

Frequency of Use: It will be used highly.

UC ID18: UC Withdraw money

Use Case ID: UC-18

Use Case Name: withdraw money

Created By: Omar Al-Najjar

Date Created: 4/4/2022

Actors: Primary: user of app Secondary: Banks

Description: This use case should offer ways to withdraw money from the in-app wallet.

Trigger: Click the button of withdraw

Preconditions:

Post conditions:

Normal Flow:

1- The user click the withdraw button

2- The system prompts the user to enter the amount wanted to be withdrawal

3- The user enters the amount

4- The system open a window of the bank website to enter the account details

5- The user enters the details of the account

6- The system deposit the money to the account

7- The system shows a successful withdraw message

8- The system shows the home page

Alternative Flows:

Dependencies (Includes and extends relationships)

Frequency of Use: Medium use

4.2.9 Requirements 14-15: Student arrival verification

UC 19: Update student arrival status

Use Case ID: UC-19

Use Case Name: Update student arrival status

Created By: Mohannad Almalayo

Date Created: 4/4/2022

Actors: Primary actor: Driver Second actor: Renter

Description: The driver will send a message that contain confirmation of student’s arrival

Trigger: The driver arrives to the waypoint

Preconditions: The driver has reached the waypoint

Post conditions: A message sent to the renter

Normal Flow:

1- The driver clicks on the “trip completed” button

2- The driver marks all students has arrived safely

3- The renter receives a message that include that the trip has finished with the status of the student

Alternative Flows: 2a.

1- The driver didn’t mark one or more students that they have arrived safely

2- Go back to step 3

Dependencies

(Includes and extends relationships)

Frequency of Use: Highly used

4.2.10 Requirements 23-25: Create schedules

4.2.10.1 UC 20: View schedule

Use Case ID: UC-20

Use Case Name: View schedule

Created By: Mohannad Almalayo

Date Created: 4/4/2022

Actors: Primary actor: Driver

Description: The driver will be able to see his work schedule and decide whether to make a trip or not

Trigger: The driver clicks on the “view schedule” button

Preconditions: The driver has already created a schedule

Post conditions:

Normal Flow:

Alternative Flows:

Dependencies

(Includes and extends relationships)

1- The system will load the schedule of the driver

2- The system will show the schedule of the driver

Frequency of Use: Poorly used

4.2.1.2 UC 21: create schedule

Use Case ID: UC-21 Use Case Name: Create schedule

Created By: Mohannad Almalayo

Date Created: 4/4/2022

Actors: Primary actor: Driver

Description: The driver will be able to create his own schedule of work that can be saved in the app

Trigger: The driver clicks on the “create schedule” button

Preconditions: The user is in the driver mode

Post conditions:

Normal Flow:

1- The system will prompt the user to the schedule planner

2- The driver will assign the name and the time of the work

3- The driver clicks on the “add to schedule” button

4- The system will show a message that the operation has been completed successfully

Alternative Flows: 3a.

1- The system will show a message that the schedule has some conflicts

2- The system will not add the work

3- Go back to step 1

Dependencies

(Includes and extends relationships)

Frequency of Use: 1 time usage every term

4.2.1.3 UC 22: Alert schedule conflict

Use Case ID: UC-22

Use Case Name: Alert schedule conflict

Created By: Mohannad Almalayo

Date Created: 4/4/2022

Actors: Primary actor: Driver

Description: The driver will be notified if there is a conflict between the trip time and the schedule of work

Trigger: The driver clicks on the “add new trip” button

Preconditions: The user is in the driver mode

Post conditions:

Normal Flow:

1- The system will scan the schedule if there is a work after 15 minutes

2- The system finds a conflict between the trip time and the schedule

3- The system prompts a question that there is a conflict in the time that says, “ there is conflict in time, want to make a trip? ”

4- The driver clicks on “no” button

5- The system prompts the user to the home screen

Alternative Flows: 2a.

1- The system didn’t find conflicts between the trip time and the schedule

2- The system makes a trip 4a.

1- The driver clicks on “yes” button

2- The system makes a trip

Dependencies

(Includes and extends relationships)

Frequency of Use: This will be highly used if the user takes the driver role frequently but if he is a renter it will never be used

4.2.11 Requirements 1-2 :

User details

View personal profile or other user profiles Notes -

Use Case ID: UC-01

Use Case Name: User details

Created By: Mohammed Al-Mohammedi

Date Created: 2022/3/28

Software Requirements Specification for KarPool

Actors: User

Description: The user can their own profile or view profiles from different users.

Trigger: The user clicks on the image of the user.

Preconditions: - The user’s profile that is being viewed must have their profile set-up.

Post conditions: None.

Normal Flow:

Alternative Flows:

- The user clicks on the image of the user.

- The system shows the profile to the user

- The user clicks on “My profile” button to view their own profile

- The system shows the profile of the account holder

Dependencies (Includes and extends relationships) None

Frequency of Use: Daily

4.2.12 Requirements 3-4 : Sending messages

Priority High Effort 1 week

Risk High

Use Case(s) UC-02

Description Send messages to the other actor

Notes -

Use Case ID: UC-02

Use Case Name: Sending messages

Created By: Mohammed Al-Mohammedi

Date Created: 2022/3/28

Actors: The driver, the renter

Description: Both actors can message each other inside the app.

Trigger: The driver or the renter clicks on the “message” button.

Preconditions: - The trip/order is active

Post conditions: None.

Normal Flow:

1- View trip/order details page

2- Clicks “message” button

3- The system shows the message session screen

Alternative Flows: None.

Dependencies (Includes and extends relationships) None.

Frequency of Use: About every 10 minutes.

4.2.13 Requirements 3-4 : View previous trips

Notes -

Use Case ID: UC-03

Use Case Name: View previous trips

Created By: Mohammed Al-Mohammedi

Date Created: 2022/3/28

Actors: The driver, the renter

Description: The driver and the renter can view the trip history.

Trigger: The driver or the renter clicks on the “Previous trips” button.

Preconditions: - The renter or the driver had at least one trip

Post conditions: None.

Normal Flow:

1- Clicks on “Previous trips”

2- The system shows the previous trips of the account holder.

Alternative Flows: None.

Dependencies (Includes and extends relationships) None.

Frequency of Use: Monthly.

4.2.14 Requirements 3-4 : Rate User

Description 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.

Use Case ID: UC-5.1

Use Case Name: Rate user

Created By: Abdulmalik

Date Created: 2022/4/8

Actors:

1. The Driver

2. The renter

3. The System

Description: The driver should be able to rate the renter

The renter should be able to rate the driver

Trigger: The user selects on "rate trip"

Preconditions:

Post conditions:

Normal Flow:

1- The user is a valid kfupm member.

2- The user has finished a trip.

1- The rating will be saved in the user's profile

1. When a trip is finished, the driver should click on finish trip.

2. The renter will confirm finishing the trip.

3. The system will show "rate trip" option.

4. The users select on "rate trip" option.

5. The system will open a new window for rating the trip.

6. The users will be able to rate the trip.

7. The users should click on save and finish.

Alternative Flows:

Dependencies (Includes and extends relationships)

Frequency of Use: High

Use Case ID: UC-5.2

Use Case Name: Comment on user

Created By: Abdulmalik

Date Created: 2022/4/8

Actors:

1. The Driver

2. The renter

3. The System Description: The driver should be able to rate the renter

The renter should be able to rate the driver

Trigger: The user selects on "rate trip"

Preconditions:

Post conditions:

Normal Flow:

1- The user is a valid kfupm member.

2- The user has finished a trip

1- The rating will be saved in the user's profile

1. When a trip is finished, the driver should click on finish trip.

2. The renter will confirm finishing the trip.

3. The system will show "comment on trip" option.

4. The users select on "comment on trip" option.

5. The system will open a new window for rating the trip.

6. The users will be able to rate the trip.

7. The users should click on save and finish.

Alternative Flows:

Dependencies (Includes and extends relationships)

Frequency of Use: High

4.2.15 Requirement 10 : Show driver’s location

Description

Notes

This feature will allow the renter to see the driver's location on the map while taking the renter's Kids.

Use Case ID: UC-10

Use Case Name: Show driver's location

Created By: Abdulmalik

Date Created: 2022/4/1

Actors:

1. The renter

2. The System

Description: The system will show the driver's location on the map

Trigger: The user selects on "show driver's location"

Preconditions:

Post conditions:

Normal Flow:

1- The renter is a valid kfupm member.

2- The renter has added a new trip.

1. The system will open a window asks the renter to click on "show driver's location".

2. The user clicks on "show driver's location".

3. The system will open the map that has the driver's location on another window.

Alternative Flows:

Dependencies (Includes and extends relationships)

Frequency of Use:

4.3 UML Activity Diagrams

4.4 System Domain Model

4.5 Non-functional Requirements

4.5.1 Performance Requirements

NFR-1. The system shall not take more than 1 second to load the data in the user interface

NFR-2. messages shall not take more than 1 second to be sent

NFR-3. messages shall not take more than 1 second to be received

NFR-4. the system shall not take more than 1 second to send an arrival message to the renter

NFR-5. a trip request shall be sent to the driver in less than 0.5 second

NFR-6. the system shall obtain the user's data from the KFUPM database in less than 5 seconds

NFR-7. the driver's location shall be refreshed every 0.2 seconds

NFR-8. the account must take less than 3 seconds to be made in the database

4.5.2 Security Requirements

NFR-9. The private details of the user profile shall be censored

NFR-10. the messages between the renter and driver shall be encrypted

NFR-11. the data of the credit cards must be encrypted

NFR-12. the system shall generate random numbers each time the authentication message sent

NFR-13. the system must have 2FA as a primary authentication method

NFR-14. the system shall not show the user password in the account creation process.

NFR-15. the system shall make sure the user is a valid KFUPM member.

4.5.3 Safety Requirements

NFR-16. the number of passengers must not exceed the number of capacity of the car

NFR-17. the car has been checked for at max 6 months ago

NFR-18. the user rating should be anonymous

NFR-19. the rating of the driver shall be updated every 10 trips

4.5.4 Other Software Quality Attributes

NFR-20. the messages shall be formed with known fonts

NFR-21. the distance between the lines shall not be less than 8 pt

NFR-22. the system shall use rating by picking number of stars out of five that represents the satisfactory of the renter

NFR-23. the renter should not take more than 3 clicks when requesting a trip

NFR-24. The request failure rate must be lower than 5%

NFR-25. The system should take less than 150MB in storage space

4.5.5 Other Requirements

NFR-26. the map shall show which way the driver should take in order to reach the distention

5. External Interface Requirements

5.1 User Interfaces

<Describe the logical characteristics of each interface between the software product and the users. This may include sample screen images, any GUI standards or product family style guides that are to be followed, screen layout constraints, standard buttons and functions (e.g., help) that will appear on every screen, keyboard shortcuts, error message display standards, and so on. Define the software components for which a user interface is needed. Details of the user interface design should be documented in a separate user interface specification.>

5.2 Hardware Interfaces

<Describe the logical and physical characteristics of each interface between the software product and the hardware components of the system. This may include the supported device types, the nature of the data and control interactions between the software and the hardware, and communication protocols to be used.>

The KarPool system function on either IOS or Android operating systems only For the visionimpaired to use the app, the vision features must be turn-on on users’ devices. No other hardware are required.

5.3 Software Interfaces

<Describe the connections between this product and other specific software components (name and version), including databases, operating systems, tools, libraries, and integrated commercial components. Identify the data items or messages coming into the system and going out and describe the purpose of each. Describe the services needed and the nature of communications. Refer to documents that describe detailed application programming interface protocols. Identify data that will be shared across software components. If the data sharing mechanism must be implemented in a specific way (for example, use of a global data area in a multitasking operating system), specify this as an implementation constraint.>

5.4 Communications Interfaces

<Describe the requirements associated with any communications functions required by this product, including e-mail, web browser, network server communications protocols, electronic forms, and so on. Define any pertinent message formatting. Identify any communication standards that will be used, such as FTP or HTTP. Specify any communication security or encryption issues, data transfer rates, and synchronization mechanisms.>

Users must have internet connection when using the app. The system shall be able to send SMS messages for any KSA phone number. A driver location shall be sent to the system’s main server as well as to the renter’s device synchronously A driver location shall be updated at any internet speed. Communication between users shall be with less than 1 second at any internet speed SMS verification codes shall be encrypted when sent to the user.

Appendix A: Glossary

<Define all the terms necessary to properly interpret the SRS, including acronyms and abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire organization, and just include terms specific to a single project in each SRS.>

Appendix B: Issues List

< This is a dynamic list of the open requirements issues that remain to be resolved, including TBDs, pending decisions, information that is needed, conflicts awaiting resolution, and the like.>