Skip to content

Latest commit

 

History

History
266 lines (220 loc) · 10.2 KB

REQ_280096.md

File metadata and controls

266 lines (220 loc) · 10.2 KB

EZGas - Official Requirements Document

Authors: Marco Rondina s288096 (ex 204603)

Date: 29/03/2020

Version: 1

Contents

Abstract

Motorist often need to reach a gas station for refuel their vehicle. The fuel retail price is not global fixed and everyone, everytime, tries to choose the cheapest one in their zone. This can means, sometimes, to move from one supplier to another, in order to find the most convenient.

EZGas is a crowdsourcing service that allow active users to collect prices of fuels in different gas stations, and let passive users to locate gas stations in an area, along with the prices they practice. In this way is really easier to locate the best gas station for your needs.

Stakeholders

Stakeholder name Description
Users Uses the application to collect prices of fuels (active) or uses the application to navigate within the different prices of different gas stations in an area and rates the prices (passive)
Administrator Creates gas stations list, thinks about new hypotetical functionalities
Developer Develop and mantain application
Database service Host all the needed informations
Map Service OpenStreetMap API service for mapping and geolocalization

Context Diagram and interfaces

Context Diagram

left to right direction
actor User
artifact MapService
actor Developer
actor Administrator

MapService -- (EZGas)
(EZGas) -- Administrator
(EZGas) -- Developer
(EZGas) <-> User

Interfaces

Actor Logical Interface Physical Interface
User GUI Touchscreen
Administrator GUI Screen, keyboard
Developer GUI Screen,keyboard
MapService Web services Internet connection

Stories and personas

Andrew is a motorist and owns a car that he uses everyday for cover his 30' trip to work. Once a week or so, he need to reach a gas station for refuel his vehicle. Often, he choose the first one that he meets when he leaves his workplace, at the end of the day. Frequently he realizes that just short distance away, he could have refueled at a lower price. On the other hand, sometimes, when he thinks that the price of the first gas station is too high, he tries to reach the next one which however presents an even higher price. He is facing a crossroads: going back to save money while wasting time or refueling at the most expensive station? Andrew would like to use a tool that allows him to consult the fuel price in advance, in order to choose the most convenient gas station, without wasting time.

Patricia and Gareth are two other commuters that everyday goes by the main road near Andrew's workplace,sometimes early in the morning, sometimes late in the evening. They always use EZGas for checking the fuel price in advance. Every time they stop himself to refuel, they insert their update price report. They chose EZGas, due to his scoring systems so they can trust a price when is a well-scored user to report it.

In this way, Andrew has the way to choose in advance the gas station to refuel his vehicle and save time and money.

Functional and non functional requirements

Functional Requirements

ID Description
FR1 Manage Gas stations (create,edit,delete)
FR2 Produce the list of all Gas stations with prices (ordered by name,distance,price)
FR3 Add a new price for a specific fuel in a specific gas station
FR4 Rates the prices
FR5 Manage personal gas stations preferite list
FR6 Manage threshold for price notifications
FR7 User algorithm-based reliability score

Non Functional Requirements

ID Type (efficiency, reliability, .. see iso 9126) Description Refers to
NFR1 Usability Application should be used with no training All FR
NFR2 Usability New price insertion in <= 3 buttons tap FR3
NFR3 Performance All functions should complete in < 0.5 sec All FR
NFR4 Portability The application runs correctly on Android(8.1+) All FR
The application runs correctly on iOS(10.0+) All FR
NFR5 Localisation Decimal numbers use . (dot) as decimal separator All FR

Use case diagram and use cases

Use case diagram

left to right direction
actor Administrator as a
actor User as u
u -- (FR2 Produce the list of all Gas stations with prices ordered by name,distance,price)
u -- (FR3 Add a new price for a specific fuel in a specific gas station)
u -- (FR4 Rates the prices)
u -- (FR5 Manage personal gas stations preferite list)
u -- (FR6 Manage threshold for price notifications)
u -- (FR7 User algorithm-based reliability score)
a -- (FR1 Manage gas stations)

Use Cases

Use case 1, UC1 - FR1 Manage gas stations

Actors Involved Administrator
Precondition (Creation) GS doesn't exist
(Edit or delete) GS already exists
Post condition
Nominal Scenario Administrator creates,edit,delete gas station GS
Variants

Use case 2, UC2 - FR2 Produce the list of all Gas stations with prices ordered by name,distance,price

Actors Involved User
Precondition In the radious of 5km exists at least one GS
Post condition
Nominal Scenario User want to see the GS list
Variants GS prices not updated since 2 days, issue warning

Use case 3, UC3 - FR3 Add a new price for a specific fuel in a specific gas station

Actors Involved User
Precondition GS exists
Post condition
Nominal Scenario User knows the fuel price and updates the information
Variants

Use case 4, UC4 - FR4 Rates the prices

Actors Involved User
Precondition GS exists
It is present a fuel price update related to the selected GS in the last two days
Post condition
Nominal Scenario User has chosen the GS through the app and once reached, confirms or denies the price presented
Variants

Use case 6, UC5 - FR5 Manage personal gas stations preferite list (add, remove)

Actors Involved User
Precondition (add) GS exists && User has < 3 favorites GS
Post condition
Nominal Scenario User selects the favorites GS (like a bookmark) for a faster price consultation, price rating or price update
Variants

Use case 7, UC6 - FR6 Manage threshold for price notifications

Actors Involved User
Precondition
Post condition
Nominal Scenario User can insert a threshold for receive a notification when the nearest GS fuel price falls below the threshold
Variants

Use case 8, UC7 - FR7 User algorithm-based reliability score

Actors Involved User, Developer
Precondition
Post condition
Nominal Scenario When a User run the app for the first time, it is marked with a random id. Every price update is linked with an id and a reliability score is calculated from the user rates. When a User consults the prices, he can see an icon that show an high or low score.
Variants

Relevant scenarios

Scenario 1

Scenario ID: SC1 Corresponds to UC3
Description User insert a new price report
Precondition
Postcondition Algorithm evaluates whether to show a different price than the current one
Step# Step description
1 User selects the GS
2 User selects the 'Update price' option
3 User inserts the update price and confirm
4 Algorithm adds the price report in the DB and recalculate what price to show for that GS

Scenario 2

Scenario ID: SC2 Corresponds to UC4
Description User rates the price showed by the app
Precondition Already exists an updated (in the last two days) price report
Postcondition The user reliability score of the user who entered the price is updated
Step# Step description
1 User select the GS
2 User selects the 'Rate price' options
3 User vote up/down and confirm
4 Algorithm adds the rate in the DB and recalculate what price to show for that GS

Glossary

class EZGas
class User{
	+id
}
class GasStation{
	+id
	+name
	+latitude
	+longitude
}
class Price{
	+timestamp
	+fuelType
	+amount
}
class Rate{
	+timestamp
	+vote
}
note "Gas station class" as n1
note "User 'light' class. No registration required, \n but every user at the first application use is \n is linked to a unique id." as n2
note "Price 'transaction' class.\nEvery transaction is inserted by users." as n3
note "Rate of single price transaction inserted by users." as n4

EZGas --"*" User
EZGas --"*" GasStation
User --"*" Price
GasStation --"*" Price
Price --"*" Rate
User --"*" Rate

GasStation -- n1
User -- n2
Price -- n3
Rate -- n4

System Design

The application is composed by a client-side app (on mobile phone or web app) and by an online server that host a database.

class "Mobile phone" as mp
class "Online server" as os	
mp <--> os

Deployment Diagram

artifact "EZGas Application" as a1
node "Mobile phone" as mp
node "Online server API" as os
database DB
artifact MapService
a1 -- mp
mp <--> os
DB -- os
mp <--> MapService