Skip to content

Requirements Specifications

Jump to bottom
Brian Ofrim edited this page Nov 28, 2016 · 35 revisions

Use Cases

Use Case: 1
ID: US 01.01.01
Story: One
Description: A casual rider's car will not start and is in a rush to arrive. He uses a2b by selecting the start and end locations for the trip, and then requesting a ride between those two locations.
Primary Actor: The casual rider
Supporting Actor(s): Any drivers considering the request
Goal: To submit a request for a ride between the two locations to the a2b system.
Pre-conditions:

  • App has access to the internet.

Post-conditions:

  • A request between the two locations is submitted to a2b servers.

Basic Flow:

  • 1 The (logged in) rider selects a starting location
  • 2 The rider selects an end location
  • 3 The rider submits the request (with a fare offer?)

Exceptions:

  • 1 - If there is no internet connection, system displays an error, loops to step 1 (eventually will use use case 21 instead - v2.0?)

Use Case: 2
ID: US 01.02.01
Story: Two
Description: A casual rider is unsure of what/how many current requests they have. She would like to use a2b to view a list of these current requests.
Primary Actor: The casual rider
Supporting Actor(s): N/A
Goal: To view all current ride requests.
Pre-conditions:

  • App has access to the internet.

Post-conditions:

  • All ride requests, if any, are displayed in a clear fashion.

Basic Flow:

  • The (logged in) rider selects a button to view current requests
  • A list of current requests (if any) is populated and displayed to the rider

Exceptions:

  • N/A

Use Case: 3
ID: US 01.03.01
Story: Three
Description: A casual rider should be notified of whether or not his request has been accepted in real time.
Primary Actor: The casual rider
Supporting Actor(s): Driver(s) who have accepted the request
Goal: To immediately notify the rider of an accepted request when a driver chooses to do so
Pre-conditions:

  • Rider has submitted at least one request
  • At least one driver has accepted said request

Post-conditions:

  • The rider has been notified of the acceptance over the standard android notification system

Basic Flow:

  • 1 A notification appears on the rider's device

Exceptions:

  • If the rider is not connected to the internet
  • The data should be stored and sent as soon as the device connects

Use Case: 4
Story: Four
ID: US 01.04.01
Description: A casual rider had submitted a request, but no longer wishes to employ the services of an a2b driver.
Primary Actor: The casual rider
Supporting Actor(s): N/A
Goal: To cancel a current ride request
Pre-conditions:

  • At least one ride request exists

Post-conditions:

  • The ride request in question is cancelled

Basic Flow:

  • 1 The (logged in) rider selects a button to view current requests
  • 2 A list of current requests (if any) is populated and displayed to the rider
  • 3 The rider selects one of the current requests and views its details
  • 4 The rider selects a delete button and a dialog confirms the rider would like to delete the request
  • 5 The request is deleted
  • 6 The app returns to main activity

Exceptions:

  • If the system cannot access the internet or cannot cancel the request for any reason
  • The rider is notified and given the opportunity to try again

Use Case: 5
ID: US 01.05.01
Story: Five
Description: A casual rider would like to get in contact with a driver who has accepted one of their requests, either by phone number or by email.
Primary Actor: The casual rider
Supporting Actor(s): The driver who has accepted the rider's request
Goal: To provide the contact information of a driver who has accepted a rider's request to said rider
Pre-conditions:

  • App has access to the internet
  • At least one request has been made by the rider
  • The driver has accepted at least one request made by the rider

Post-conditions:

  • The driver's contact information is presented to the rider in a clear, readable fashion

Basic Flow:

  • 1 The (logged in) rider selects a button to view current accepted requests
  • 2 The rider selects an accepted request
  • 3 The rider selects a button to view details about the driver who accepted the request
  • 4 The contact information of the driver is presented to the rider

Exceptions:

  • Contact information not found
  • In this case the system should make an immediate note as all users should have signed up with contact information
  • Internet connection not working
  • The rider should be notified that their connection is not working and given the opportunity to attempt the operation again

Use Case: 6
ID: US 01.06.01
Story: Six
Description: A casual rider would like to use the app to provide an reasonable estimation of a fair fare to offer for a trip between two locations.
Primary Actor: The casual rider
Supporting Actor(s): N/A
Goal: To provide a reasonable estimation of a fair fare to offer for a trip between two locations.
Pre-conditions:

  • App has access to the internet
  • Rider has selected a start and end location

Post-conditions:

  • A fare estimate based on distance between the two locations and time of day/availability of drivers.

Basic Flow:

  • 1 The (logged in) rider selects the start and end locations
  • 2 The rider selects a button that provides a fair suggestion
  • 3 A fair suggestion is presented to the rider

Exceptions:

  • N/A

Use Case: 7
ID: US 01.07.01
Story: Seven
Description: A rider confirms that a request has been completed and officially transfer payment.
Primary Actor: The casual rider
Supporting Actor(s): The driver who has completed the rider's request
Goal: For the rider to close a request as completed and complete payment to the driver
Pre-conditions:

  • Driver has accepted and completed the rider's request
  • The rider had confirmed the acceptance

Post-conditions:

  • The request is closed as completed, and the rider's payment information is processed.

Basic Flow:

  • 1 The (logged in) rider selects a confirm that they have arrived at the destination
  • 2 The rider selects the payment option

Exceptions:

  • 2 Valid Payment information not found -> input payment information

Use Case: 8
ID: US 01.08.01
Story: Eight
Description: A casual rider would like to confirm an acceptance of their request.
Primary Actor: The casual rider
Supporting Actor(s): The driver who has accepted the rider's request
Goal: To confirm the acceptance of a request.
Trigger: The rider hits the "confirm" button for the request
Pre-conditions:

  • At least one request has been made by the rider
  • At least one request has been accepted by the driver

Post-conditions:

  • The driver will provide the rider with a ride
  • The rider will provide the driver with the agreed upon payment

Basic Flow:

  • 1 The (logged in) rider selects a button to view current accepted requests
  • 2 The rider selects an accepted request
  • 3 The rider confirms this acceptance by touching a button
  • 4 A dialog confirms to the rider that the confirmation has been completed

Exceptions:

  • N/A

Use Case: 9
ID: US 02.01.01
Story: Nine and Ten
Description: A user (rider or driver) would like to view the status of a request that they have either made, accepted or confirmed.
Primary Actor: The user (rider or driver)
Supporting Actor(s): N/A Goal: To view the status of a request
Trigger: The user selects the detail view of a request Pre-conditions:

  • At least one request has been made or accepted by the user

Post-conditions:

  • The status of the request is not effected by this action

Basic Flow:

  • 1 The (logged in) user selects a button to view current requests involving them
  • 2 The user selects the request in question
  • 3 A detail view (activity) is loaded

Exceptions:

  • 2 Request not found -> return to 1

Use Case: 10
ID: US 03.01.01
Story: Eleven
Description: A user creates a profile with a unique username and their contact information
Primary Actor: The user
Supporting Actor(s): N/A
Goal: To create a profile for the user with a unique username and contact information
Trigger: The user hits the "sign up" button
Pre-conditions:

  • Connection to the internet

Post-conditions:

  • The account and account information is update
  • The user is automatically signed into the service

Basic Flow:

  • 1 The user views the welcome page
  • 2 The user selects "sign up"
  • 3 The user is prompted to enter a unique username
  • 4 The user is prompted to enter contact info (phone number, email)
  • 5 The user's account is recorded
  • 6 The user is automatically signed in

Exceptions:

  • 3 The username chosen is not unique -> loop to 3 until unique
  • 4 Invalid phone number, email -> loop to 4 until valid
  • 5 Cannot record account -> notify the user and reset to step 1
  • 5 sign in failed -> notify the user and reset to step 1

Use Case: 11
ID: US 03.02.01
Story: Twelve
Description: A user would like to edit the contact information in their profile
Primary Actor: The user (rider or driver)
Supporting Actor(s): N/A
Goal: To edit the profile for the user
Trigger: The user hits the "edit" button in "myprofile"
Pre-conditions:

  • Connection to the internet
  • The user is logged in
  • The user is in the "myprofile" view

Post-conditions:

  • The account information is updated

Basic Flow:

  • 1 The user views the main page
  • 2 The user selects my profile button
  • 3 The user selects the edit button
  • 4 The user is prompted to edit contact info (phone number, email)
  • 5 The user's changes are recorded upon hitting "save"
  • 6 Return to main screen

Exceptions:

  • 4 Invalid contact info -> Return to 2 after notifying the user
  • 5 Changes could not be saved -> Notify the user and return to 2

Use Case: 12
ID: US 03.03.01
Story: Thirteen
Description: A user would like to find out more information about another user
Primary Actor: The user
Supporting Actor(s): The other user (who primary actor is finding info about) Goal: To view the contact information for another user
Trigger: The user hits the "clickable" username in any view
Pre-conditions:

  • Connection to the internet
  • Logged in
  • Access to the username (ie there is no "search for users" functionality)

Post-conditions:

  • N/A

Basic Flow:

  • 1 The user views any page with another username on it
  • 2 The user selects the username
  • 3 The user is presented with the contact information associated with that username

Exceptions:

  • 3 User not found -> back to 1

Use Case: 13
ID: US 04.01.01
Story: Fourteen
Description: A driver browses through nearby (or to any geo-location) requests
Primary Actor: The driver Supporting Actor(s): Riders placing requests Goal: To view nearby requests (what should this radius be?)
Trigger: The driver requests to view requests near a specific geolocation
Pre-conditions:

  • Connection to the internet

Post-conditions:

  • Should not have any effect on requests, status, etc

Basic Flow:

  • 1 The driver views the main page
  • 2 The driver selects a geolocation, either their current location or manually
  • 3 The driver touches the search for requests nearby button

Exceptions:

  • 2 Cannot find location -> reset to 1

Use Case: 14
ID: US 04.02.01
Story: Fifteen
Description: A driver searches open requests using a keyword
Primary Actor: The driver
Supporting Actor(s): riders sending requests with relevant keyword
Goal: To display all requests containing the keyword in their description
Trigger: The driver chooses search by keyword
Pre-conditions:

  • Connection to the internet

Post-conditions:

  • Should not change any requests or statuses

Basic Flow:

  • 1 The driver views the main page
  • 2 The driver selects the search button
  • 3 The driver chooses to search by keyword
  • 4 The driver enters the keyword
  • 5 A clickable list of corresponding open requests is displayed to the driver

Exceptions:

  • 5 No corresponding requests found -> Loop back to 1 after notifying the driver

Use Case: 15
ID: US 05.01.01
Story: Sixteen
Description: A driver wants to accept an open request as well as payment upon completion
Primary Actor: The driver
Supporting Actor(s): the rider
Goal: To accept an open request and payment
Trigger: The driver accepts an open request, and then completes said request
Pre-conditions:

  • Connection to the internet
  • An open request exists for the driver to accept

Post-conditions:

  • The request is completed
  • Payment has been made
  • The driver has completed the request

Basic Flow:

  • 1 The driver views open requests
  • 2 The drives accepts a request
  • 3 The rider confirms the acceptance
  • 4 The driver drives the rider and marks the request as complete
  • 5 The rider processes payment and marks the request as complete

Exceptions:

  • 3 Rider does not confirm acceptance -> Timeout??
  • 4 Driver does not drive the rider -> Give rider option to protest?
  • 5 rider does not correctly process payment -> notify the rider

Use Case: 16
ID: US 05.02.01
Story: Seventeen
Description: A driver views all pending accepted requests
Primary Actor: The driver
Supporting Actor(s): Riders who submitted the accepted requests Goal: To display all pending accepted requests for the driving, including location, description and confirmation status
Trigger: The driver hits the "pending requests" button
Pre-conditions:

  • Connection to the internet
  • Logged in

Post-conditions:

  • No change in status or requests

Basic Flow:

  • 1 The driver selects the pending requests button
  • 2 The driver is shown a list of pending requests (if any) that he/she has accepted
  • 3 Touching a specific requests brings up a detailed view including location, confirmation status, time, etc

Exceptions:

  • 2 No requests found -> Notify user and return to main screen

Use Case: 17
ID: US 05.03.01
Story: Eighteen
Description: A driver wants to see if an accepted request is confirmed
Primary Actor: The driver
Supporting Actor(s): The rider confirming the acceptance
Goal: To display confirmation status of an accepted request
Trigger: The driver selects a specific accepted request from the pending requests list
Pre-conditions:

  • Connection to the internet
  • pending requests list is up
  • At least one pending/accepted request exists

Post-conditions:

  • Should not change requests or status

Basic Flow:

  • 1 The driver selects a specific pending request from pending requests list (see case 16)
  • 2 The confirmation status of the request is displayed

Exceptions:

  • 1 There are no pending requests -> See use case 16 exceptions

Use Case: 18
ID: US 05.04.01
Story: Nineteen
Description: A driver is notified when an acceptance (an open request marked as accepted) has been confirmed by a rider
Primary Actor: The driver
Supporting Actor(s): the rider Goal: To notify the driver of a confirmed acceptance
Trigger: The rider confirms the acceptance
Pre-conditions:

  • Connection to the internet
  • Logged in
  • Driver has accepted at least one request

Post-conditions:

  • An android system notification has appeared notifying the driver of the confirmation

Basic Flow:

  • 1 The rider confirms the acceptance
  • 2 A notification appears on the driver's device, informing of this development

Exceptions:

Use Case: 19
ID: US 08.01.01
Story: Twenty
Description: Offline storage of accepted requests (by driver)
Primary Actor: the driver
Supporting Actor(s): riders submitting requests
Goal: To allow the driver to view accepted requests even while offline
Trigger: The driver loads the "pending requests" view Pre-conditions:

  • No connection to internet
  • the driver has accepted at least one request

Post-conditions:

  • No change in requests or status

Basic Flow:

  • 1 The driver views the main page
  • 2 The driver selects pending requests
  • 3 The driver is notified that he/she is offline and cached data will be used
  • 4 The driver selects the "accepted" option from the dropdown
  • 5 The accepted requests are presented to the driver in a clickable listview

Exceptions:

  • 3 No pending requests found in cache -> Notify user and reset to 1

Use Case: 20
ID: US 08.02.01
Story: Twenty-one
Description: A rider views requests they have submitted despite not being connected to the internet
Primary Actor: The rider
Supporting Actor(s): N/A
Goal: To allow the rider to view submitted requests even without internet connection (ie cached submitted requests)
Trigger: The rider selects the "my requests" option from the dropdown menu in the
Pre-conditions:

  • No connection to internet
  • The rider has submitted at least one request

Post-conditions:

  • No change in status or requests

Basic Flow:

  • 1 The rider views the main page
  • 2 The rider selects "pending requests"
  • 3 The rider is warned that they are offline and cached data will be used
  • 4 The rider is selects "my requests" from the dropdown filter menu
  • 5 A clickable listview of the pending requests from this rider is displayed

Exceptions:

  • 3 No pending requests found in cache -> reset to 1 after notifying the rider

Use Case: 21
ID: US 08.03.01
Story: Twenty-two
Description: A rider makes a request while offline, to be immediately sent once connectivity is restored.
Primary Actor: The rider
Supporting Actor(s): N/A
Goal: To store a request offline until connectivity is restored, at which point to submit said request
Trigger: The user creates a new request while offline
Pre-conditions:

  • No internet connection

Post-conditions:

  • Request is submitted upon re-connection

Basic Flow:

  • 1 The rider views the main page
  • 2 The rider selects the new request button
  • 3 The rider fills out the details and submits the request as normal
  • 4 The rider is notified that they are offline and the request will be saved and sent once connectivity is restored

Exceptions:

  • See exceptions in case 1, these apply here as well (except for no internet connection)

Use Case: 22
ID: US 08.04.01
Story: Twenty-three
Description: A driver accepts a request while offline to be sent once connectivity is restored
Primary Actor: The driver
Supporting Actor(s): the rider who sent the request
Goal: To store the acceptance until connectivity is restored, and then submit the acceptance
Trigger: The driver accepts a request in the usual manner while offline
Pre-conditions:

  • No connection to the internet
  • At least one request exists

Post-conditions:

  • The request is accepted once connectivity is restored

Basic Flow:

  • 1 The driver views the main page
  • 2 The driver views (cached) pending requests
  • 3 The driver is warned that he/she is offline and cached data will be used
  • 4 The driver selects "not accepted" from the dropdown filter menu
  • 5 The driver selects a specific request
  • 6 The driver selects "accept" while in the detailed view
  • 7 When connectivity is restored, the acceptance is sent

Exceptions:

  • 3 There are no cached requests -> notify the driver and reset to 1

Use Case: 23
ID: US 10.01.01
Story: Twenty-four
Description: Specifiy start and end locations on a map for a request
Primary Actor: The rider
Supporting Actor(s): N/A
Goal: To set location data on requests by geolocation on visual map.
Trigger: The rider selects the first geolocation on the map
Pre-conditions:

  • Connected to the internet
  • Location services??? - Do we actually need this?

Post-conditions:

  • The rider is in a position where they can complete their request (with other details) involving these two geolocations

Basic Flow:

  • 1 The rider selects a location on the map
  • 2 The rider selects the second location on the map
  • 3 The rider chooses to make a new request

Exceptions:

  • N/A

Use Case: 24
ID: US 10.02.01
Story: Twenty-five
Description: A driver views start and end locations associated with a request directly on a map
Primary Actor: The driver
Supporting Actor(s): the rider who sent the request
Goal: To display the start and end geo locations of the request on the map
Trigger: The driver selects "view" in the request detail page
Pre-conditions:

  • At least one request exists

Post-conditions:

  • The locations are shown on the map
  • Should not effect status or requests

Basic Flow:

  • 1 The driver views the main page
  • 2 The driver views pending requests
  • 3 The driver enters the detail view for a specific request
  • 4 The driver selects "view"
  • 5 The driver is shown the locations on a map

Exceptions:

  • N/A

Use Case: 25
ID: US 1.09.01 (added 2016-11-14)
Story: 26
Description:
A user using A2B has requested a ride to a destination. A driver nearby has accepted his request and is on his way. The user in need of a ride would like to read a description of the driver’s car so he he/she knows what to look for.
Primary Actor: The casual rider
Supporting Actor(s): Any drivers that have accepted the riders request
Goal: to provide the rider a description of the driver’s vehicle

Pre-conditions:

  • User has at least one of his ride requests accepted by a driver

Post-conditions:

  • The rider will see a description of the driver’s vehicle on the app when looking at the driver’s profile or request detail

Basic Flow:

  • 1 The (logged in) rider selects a starting location
  • 2 The rider selects an end location
  • 3 The rider submits the request (with a fare offer?)
  • 4 A nearby driver accepts the riders request
  • 5 the rider is sent a notification that his request has been accepted by a driver
  • 6 the rider clicks on his accepted and request and clicks on the driver’s profile
  • 7 profile should load for the driver and the user can see a description of the driver’s vehicle

Exceptions:

  • 1 - If there is no internet connection, system goes to offline mode

Use Case: 26
ID: US 1.10.01 (added 2016-11-14)
Story: 27
Description:
A user has made a ride request and several drivers in the area has accepted his/her request. The user now with a couple choices of drivers wants to view these driver’s profiles and view their driver rating so that he can make an informed decision Primary Actor: The rider
Supporting Actor(s): The drivers
Goal: To display the driver’s driver rating on his profile view
Trigger: The rider clicks on a driver’s profile

Pre-conditions:

  • None Post-conditions:

  • Profile view is loaded to the screen

  • User can see a rating for the selected driver

Basic Flow:

  • 1 The rider makes a request for a ride between two locations
  • 2 Three nearby drivers accept this request
  • 3 The rider is given a notification that his ride has been accepted
  • 4 The rider now sees a list of drivers willing to drive him and their respective ratings

Exceptions:

  • No internet connection the user cannot see the driver

Use Case: 27
ID: US 1.11.01(added 2016-11-14)
Story: 28
Description:
A rider has received his ride to his/her location and is prompted to give the driver a rating for his overall A2B experience
Primary Actor: The rider
Supporting Actor(s): the driver who gave the ride
Goal: To give the driver of the ride a rating out of 5 for the rider’s overall experience Trigger: The driver sends confirmation that he has given the ride and the rider sends payment, rider is then prompted to give a rating for the driver

Pre-conditions:

  • Rider has received his ride
  • Rider has sent payment
  • Rider has been prompted for rating
  •   Internet connection is available

Post-conditions:

  • The drivers rating on his profile is now updated as the new average including the riders recent rating

Basic Flow:

  • 1 The rider receives his ride
  • 2 The rider sends payment for the ride
  • 3 The rider is prompted to provide a rating for the ride
  • 4 Rating is provided, drivers rating is queried from the elastic search server
  • 5 new rating is now added to the sum of the other ratings to calculate a new average rating for the driver
  • 6 Rating is now sent back to server for the driver

Exceptions:

  • Rider can refuse to provide a rating in which case driver’s rating is unaffected

Use Case: 28
ID: US 03.04.01 (added 2016-11-14)
Story: 29
Description:
A driver wants to add a description of his vehicle for riders to view in his profile
Primary Actor: The driver
Supporting Actor(s): none
Goal: To add a description of the driver’s vehicle to his profile
Trigger: The driver clicks edit in the profile activity

Pre-conditions:

  • Driver’s profile must already exist
  •   Internet connection is available

Post-conditions:

  • The vehicle description is now shown on the driver’s profile

Basic Flow:

  • 1 The driver clicks to view his profile
  • 2 The driver clicks edit
  • 3 The driver types his vehicle description in the edit text view provided for his vehicle description
  • 4 The driver clicks save
  • 5 The driver data is sent to the server

Exceptions:

  • Vehicle description is too long? Or too short?

Use Case: 29
ID: US 04.03.01 (added 2016-11-14)
Story: 30
Description: A driver wants to filter requests by price per KM or price
Primary Actor: The driver
Supporting Actor(s): none
Goal:
To display requests with a max value for price per KM or price
Trigger: The driver selects requests for price per KM or price

Pre-conditions:

  • At least one request exists
  •   Internet connection is available

Post-conditions:

  • The requests that have been filtered are displayed to the driver

Basic Flow:

  • 1 The driver clicks on the request page
  • 2 The driver clicks the spinner and selects price per KM or price
  • 3 dialog opens to ask the driver for a max price he wants to pay per KM or total price in general
  • 4 Driver enters the wanted value
  • 5 elasticsearch controller queries based on given information. Results are either requests with the total price given or price per km.
  • 6 requests are printed and shown to the driver

Exceptions:

  • Driver gives an invalid price(negative number)

Use Case: 30
ID: US 04.04.01 (added 2016-11-14)
Story: 31
Description:
A driver wants to view the addresses of the start and finish locations of a riders request
Primary Actor: The driver
Supporting Actor(s): the rider who sent the request
Goal: To display the start and end addresses of a request
Trigger: The driver selects "view" in the request detail page

Pre-conditions:

  • At least one request exists
  •   Internet connection is available

Post-conditions:

  • The addresses of the start and end locations are shown to the driver

Basic Flow:

  • 1 The driver clicks to see a list of requests
  • 2 The driver clicks on one specific request
  • 3 The driver is now presented a view of all the request details including the addresses of the start and end locations of the request

Exceptions:

Use Case: 31
ID: US 04.05.01 (added 2016-11-14)
Story: 32
Description:
A driver wants to search requests by address or nearby address
Primary Actor: The driver
Supporting Actor(s): none
Goal: To display requests based on a given address, it can be done either by direct match or nearby address
Trigger: The driver selects address or nearby address under the spinner selections when in the requests view

Pre-conditions:

  • At least one request exists
  • Connected to the internet
  •   Internet connection is available

Post-conditions:

  • The requests with the specific location included or nearby the location are displayed

Basic Flow:

  • 1 The driver selects requests in the main menu
  • 2 The driver either selects ‘nearby address’ or ‘address’ under the spinner menu for request filters
  • 3 Dialog will pop up asking driver for the address to filter by
  • 4 If driver selected nearby address then elastic search controllers will query server for requests that are within 5 km of the given address. If address was selected then only requests with locations with that specific address will be searched for
  • 5 requests are displayed to the screen

Exceptions:

  • non existent address is given

User Stories

Taken From Project Description
Requests
US 01.01.01
As a rider, I want to request rides between two locations.

US 01.02.01
As a rider, I want to see current requests I have open.

US 01.03.01
As a rider, I want to be notified if my request is accepted.

US 01.04.01
As a rider, I want to cancel requests.

US 01.05.01
As a rider, I want to be able to phone or email the driver who accepted a request.

US 01.06.01
As a rider, I want an estimate of a fair fare to offer to drivers.

US 01.07.01
As a rider, I want to confirm the completion of a request and enable payment.

US 01.08.01
As a rider, I want to confirm a driver's acceptance. This allows us to choose from a list of acceptances if more than 1 driver accepts simultaneously.

US 1.10.01 (added 2016-11-14) As a rider, I want to see some summary rating of the drivers who accepted my offers.

US 04.03.01 (added 2016-11-14) As a driver, I should be able filter request searches by price per KM and price.

US 04.04.01 (added 2016-11-14) As a driver, I should be able to see the addresses of the requests.

Status
US 02.01.01
As a rider or driver, I want to see the status of a request that I am involved in

User profile
US 03.01.01
As a user, I want a profile with a unique username and my contact information.

US 03.02.01
As a user, I want to edit the contact information in my profile.

US 03.03.01
As a user, I want to, when a username is presented for a thing, retrieve and show its contact information.

US 1.09.01 (added 2016-11-14) As a rider, I should see a description of the driver's vehicle.

US 1.11.01 (added 2016-11-14) As a rider, I want to rate a driver for his/her service (1-5).

US 03.04.01 (added 2016-11-14) As a driver, in my profile I can provide details about the vehicle I drive.

Searching
US 04.01.01
As a driver, I want to browse and search for open requests by geo-location.

US 04.02.01
As a driver, I want to browse and search for open requests by keyword.

Accepting
US 05.01.01 As a driver, I want to accept a request I agree with and accept that offered payment upon completion.

US 05.02.01
As a driver, I want to view a list of things I have accepted that are pending, each request with its description, and locations.

US 05.03.01 As a driver, I want to see if my acceptance was accepted.

US 05.04.01
As a driver, I want to be notified if my ride offer was accepted.

US 04.05.01 (added 2016-11-14) As a driver, I should be able to search by address or nearby an address.

Offline Behaviour
US 08.01.01
As an driver, I want to see requests that I already accepted while offline.

US 08.02.01
As a rider, I want to see requests that I have made while offline.

US 08.03.01
As a rider, I want to make requests that will be sent once I get connectivity again.

US 08.04.01
As a driver, I want to accept requests that will be sent once I get connectivity again.

Location
US 10.01.01
As a rider, I want to specify a start and end geo locations on a map for a request.

US 10.02.01
As a driver, I want to view start and end geo locations on a map for a request.

Clone this wiki locally