Skip to content

Latest commit

 

History

History
224 lines (170 loc) · 8.62 KB

REQ_s269149.md

File metadata and controls

224 lines (170 loc) · 8.62 KB
Raw

Official Requirements Document

Authors: Federico Cucinella

Date: 28/03/2020

Contents

Abstract

Nowadays it often happens for the average car driver to go and seek for the most convenient gas station nearby when refueling is needed. He might stick to the one he thinks is the best in terms of price and distance, but he would need to periodically check his area for price changes in the other stations, relatively to the one he chose.

That's why our brand new startup decided to develop a service which could help the drivers to find the most convenient gas station in their area when they need it.

Stakeholders

Stakeholder name Description
Guest User Searches for a gas station
Registered User Searches for a gas station and/or inserts/updates them
OpenStreetMaps Provides maps API and service

Context Diagram and interfaces

Context Diagram

left to right direction
actor "Guest User" as a
actor "Registered User" as b
actor "OSM API" as GM
a -- (EZGas)
b -- (EZGas)
(EZGas) -- GM

Interfaces

Actor Logical Interface Physical Interface
User GUI Smartphone/Computer

Stories and personas

Mark is a regular car driver and when he needs to buy fuel for his car he can drive even for a whole kilometer looking for the gas station with the lowest price in the way. Though he often ends up losing a good bit of the money he saved for searching the station. Though with EZGas he can easily find the best compromise every time he needs to refill!

Barbra instead uses to always refill to the same gas station, which has really low prices, but many times there have been better alternatives in her area! With EZGas now she can find out which is the closest dealer with the lowest price.

Jack is driving on the highway and he will need to refuel soon, so when he reaches for the next service area he looks on EZGas if such service area is convenient or there are better alternatives further on the route, but before the fuel runs too low! At the same time, he finds out the price in EZGas for the gas station (in the service area he's currently in) isn't up-to-date, so he proceeds to send an update.

Functional and non functional requirements

Functional Requirements

ID Description
FR1 Any user shall be able to find gas stations nearby given a certain radius
FR2 Any user shall be able to sort gas stations by price
FR3 Any user shall be able to sort gas stations by distance
FR4 Any user shall be able to filter gas stations by fuel type
FR5 Any user shall be able to authenticate itself
FR6 Registered users shall be able to insert new gas stations
FR7 Registered users shall be able to update an existent gas station's price

Non Functional Requirements

ID Type Description Refers to
NFR1 Usability Application should be used with no training All FR
NFR2 Performance All functions should complete in < 1 sec All FR
NFR3 Portability The application runs on any major browser All FR
NFR4 Portability The application (functions and data) should be accessible from any internet connected device without installation All FR
NFR5 Localisation Decimal numbers use local display format All FR
NFR6 Localisation Gas station names may contain any special character All FR
NFR7 Privacy GDPR has to be taken into account FR[5,6,7]

Use case diagram and use cases

Use case diagram

left to right direction
actor "Guest User" as a
actor "Registered User" as b
a -- (FR[1,2,3,4] Searches suitable gas station)
a -- (FR5 Registers or logs in) 
b <-- (FR5 Registers or logs in) 
b -- (FR[1,2,3,4] Searches suitable gas station)
b -- (FR6 Adds new/missing gas station)
b -- (FR7 Updates gas station's price)

Use Cases

Use case 1, UC1 - FR[1,2,3,4] Search suitable gas station

Actors Involved Any user
Precondition Gas stations are present on database, search filters are set
Post condition Gas stations are displayed
Nominal Scenario User chose search parameters and reads results
Variants Registered user recalls the last search

Use case 2, UC2 - FR5 - User sign-up

Actors Involved Guest user
Precondition User has never registed
Post condition User has now a personal account
Nominal Scenario Guest user registers inserting required personal data
Variants

Use case 3, UC3 - FR5 - User log-in

Actors Involved Guest user
Precondition User is already registered and not authenticated
Post condition User is authenticated
Nominal Scenario Guest user authenticates using his login details
Variants

Use case 4, UC4 - FR6 - Add new gas station entry

Actors Involved Registered user
Precondition Chosen gas station doesn't exist in EZGas, GPS is enabled on the device and user is located in the gas station itself
Post condition Gas station exists in EZGas database
Nominal Scenario User inserts station name, selects available fuel types and inserts the corresponding price, GPS coordinates are associated
Variants

Use case 5, UC5 - FR7 - Update outdated gas station entry

Actors Involved Registered user
Precondition Chosen gas station exists in EZGas, prices aren't up-to-date, GPS is enabled on the device and user is located nearby the gas station
Post condition Gas station prices are up-to-date in EZGas database
Nominal Scenario User inserts the corresponding price for each available fuel type in the selected gas station
Variants

Relevant scenarios

Scenario 1

Scenario ID: SC1 Corresponds to UC1
Description User needs to refuel at the lowest price available in his zone
Precondition Fuel level being too low (?)
Postcondition User knows the lowest price gas station nearby
Step# Step description
1 User inputs his fuel type
2 User inputs a search radius
3 User looks in the results and finds a solution

Scenario 2

Scenario ID: SC2 Corresponds to UC4
Description User discovers a new gas station and wants to add it to the database
Precondition Gas station not present in the database
User is logged in
Postcondition Gas station is included in the database
Step# Step description
1 User phisically reaches the gas station
2 User follows the flow for inserting a new gas station, inserting the requested data

Scenario 3

Scenario ID: SC3 Corresponds to UC5
Description User finds out a gas station entry in the database is outdated
Precondition Gas station already present (and outdated) in the database
User is logged in
Postcondition Gas station is updated in the database
Step# Step description
1 User phisically reaches somewhere close to the gas station, proving he's seeing the actual prices
2 User selects the gas station from the list
3 User follows the flow for updating such gas station, inserting the requested data

Glossary

class EZGas

class GasStation {
+ name
+ position
}

class RegisteredUser {
+ name
+ email
}

class PriceUpdate {
+ fuelType
+ price
}

EZGas -- "*" GasStation
EZGas -- "*" RegisteredUser

RegisteredUser -- "*" GasStation : creates/\nupdates
GasStation -- "*" PriceUpdate
RegisteredUser -- "*" PriceUpdate : posts
RegisteredUser -- "*" PriceUpdate : votes