Official Requirements Document

Author: Francesco Cappa

Date: 31/03/2020

Version: 2

Version	Changes
2	Glossary added

Abstract

This application is oriented to two types of user: Administrators and Customers.

Customers would like to collect prices of different gas stations in order to comparing and choising the best based on the ratio best-price/distance.

To perform this comparison the user must use an setnav system which will show him/her the stations in the area. The system should authenticate the customer ID and position in order to update possible shown results.

The application must also be able to check if the customer is a fidelty client in order to apply him/her discounts/gifts. The fidelity of a client is mainly based on the number of feedbacks the user have done so far. The more feedback the customer does, the most benefits he/she receives.

Gas price can be updated periodically (daily). This task is in charge of an administrator. In doing so, the administrator should always check changes among the prices. On this purpose, he/she periodically receives a message with the information. If many feedbacks report complaints about prices, the administrator must be able to change accordingly. On this purpose, the administrator checks all the given feedbacks of users.

The administrator is also able to help the user when is asked, both for helping and for advertising some promotions.

Stakeholders

Stakeholder name	Description
Administrator	Uses the application (with some privileges) to update fuel prices possibly.
Customer	Use the application to find a place in the neighbourhood with the best price.
LocalServer	Provides the updated information about local gas stations to users.

Context Diagram and interfaces

Context Diagram

left to right direction
actor Administrator  as a
actor Customer as b
actor LocalServer as c
a -- (EZGas)
b -- (EZGas)
(EZGas) -- c

Interfaces

Actor	Logical Interface	Physical Interface
Administrator	GUI	Screen, keyboard
User	GUI	Screen, keyboard
LocalServer	TCP/IP	Wi-Fi/4G-LTE connectons

Stories and personas

David is driving away for a family holiday. So, after having drived for a while he needs to gas up. He should turn on his location by using an existing setnav application (such as Google Maps, Waze, etc) in order to find a near petrol station. Being a fidelity client of Q8 and Esso, he can apply for some discount by using his client cards.

So the system, when possible, should prioritize the companies to which David is a fidelity client. It should additionally both authenticate the user and checking the current validity of his/her card.

On the other hand, Roger is the administrator of the neighbourhood gas stations who should update the information about price and promotion availability. Some additional gifts can be given to the fidelity clients during Christmas holidays.

Everytime clients like David use their own fidelty card, they must be sure about the validity of the card. If they use an invalid fidelty card (e.g. it is expired) an error message will be shown. David can possibly renew the card by filling up a module online.

For doing so, he should specify his userID and the Company name of the gas station (ex. Q8,Esso, etc.). The system will then be in charge of contacting Roger who will aapprove the request.

In the meanwhile, Roger also sends David an additional promotion if he accepted to give a feedback. This feedback would be saved in the database of the local server which will be used to increase the fidelity level of David. Once it has been done, David can keep driving away.

Use case diagrams and use cases

Use case diagrams

left to right direction
actor Customer as a
a -- (FR1  Activate position)
a -- (FR2 Login to the application)
a -- (FR7 Choose a petroil station)
a -- (FR8 Gases up the car)

left to right direction
actor LocalServer as a
a -- (FR3  Authenticate user)
a -- (FR4 Track user position)
a -- (FR5 Give last updated information)

left to right direction
actor Administrator as a
a -- (FR5.1  Update prices)
a -- (FR7.3 Give a cupon to the user)
a -- (FR9.1 Checking feedbacks)

Use Cases

Use case 1, UC1 - FR1 Activate Position

Actors Involved	User
Precondition	SetNav application installed, device is not out of battery and connection stable
Post condition	Customer.location='active'
Nominal Scenario	Customer turns on his location and runs SetNav application
Variants	If connection not stable, warning message

Use case 2, UC2 - FR2 Login to the application

Actors Involved	User
Precondition	Customer has installed EZGas application, User has an account
Post condition	Customer.logged_in = 'true'
Nominal Scenario	Customer inserts his/her own credentials
Variants	Customer does a reset password because he/she has forgotten it; User create a new account

Use case 3, UC3 - FR3 Authenticate User

Actors Involved	LocalServer
Precondition	Customer Account exists (accountID>=0)
Post condition	LocalServer.authenticathed_user = true
Nominal Scenario	A local server authenticates the user and the latter can access the application services.
Variants	LocalServer.authenticathed_user = false

Use case 4, UC4 - FR4 Track customer position

Actors Involved	LocalServer
Precondition	Customer has been authenticated and user turned his/her position on
Post condition	LocalServer.position.setX(userX) LocalServer.position.setY(userY)
Nominal Scenario	The system keeps track of customer movement in order to update the results shown in the maps continously
Variants	Location is lost and a connection error message is shown

Use case 5, Give last updated information

Actors Involved	LocalServer
Precondition	Available information
Post condition	All the information are reported
Nominal Scenario	Application collects all the information about the nearby gas stations from a database stored in the local server. Then, this information is given to the users.
Variants	No available information, nothing to be reported.

Use case 5.1, Update prices

Actors Involved	Administrator
Precondition	Prices have been changed
Post condition	All the updates has been reported
Nominal Scenario	Administrator will compare the new prices with the old ones. If there have been changes .
Variants	No available information, nothing to be reported.

Use case 6, Sort available gas stations

Actors Involved	User
Precondition	Nearby gas stations available
Post condition	Best choise is given
Nominal Scenario	The application will verify if there are any gas stations related to companies which the customer is a fidelity client. Those are eventually prioritized, otherwise the selection is made based on price and distance of the gas station.
Variants	No available gas station, the customer should keep driving to find some.

Use case 8, Gasing up

Actors Involved	User
Precondition	Gas station choosen
Post condition	customer.money -= purchase
Nominal Scenario	The user puts money at the station terminal to gas up the car.
Variants	customer.cupon -= purchase

Use case 9, Giving feedback

Actors Involved	Customer
Precondition	UCustomer ser has gased up his/her car using the application
Post condition	Given feedback of the service
Nominal Scenario	The user gives a feedback on the utility of the application service
Variants	The customer reports some issue/complaints: problem in gasing up, complaints about price/service.

Use case 9.1, Checking feedback

Actors Involved	Administrator
Precondition	The customer has given a feedback
Post condition	Feedback recorded
Nominal Scenario	The administrator check feedback type and eventually gives extra fidelity points to the user
Variants	If Christmast holiday advertisements. If emergency call send a rescue team. If complaints about prices take it into account.

Relevant scenarios

Scenario 1

Scenario ID: SC1	Corresponds to UC8
Description	Gasing up
Precondition	User choosed a gas station
Postcondition	update money of User; update points/cupon of User
Step#	Step description
1	User select how much fuel to buy
2	User decides to use credit o cupon
3	User makes the purchase
4	The credit/points of user is being updated

Scenario 2

Scenario ID: SC2	Corresponds to UC9
Description	User gives a feedback
Precondition	User accepted to give a feedback
Postcondition	User receives additional cupon/points
Step#	Step description
1	User puts his/her own credentials
2	User fill out a module
3	User receives additional points
4	Database of feedback is updated

Scenario 3

Scenario ID: SC3	Corresponds to UC5.1
Description	Updating prices
Precondition	Prices has been updated OR many complaints
Postcondition	Updated information are spread among users
Step#	Step description
1	Administrator check the date OR complaints
2	Administrator check if prices are changed
2.1	If so, administrator changes the information in the local servers databases
3	Local servers show the correct information about prices

Functional and non functional requirements

Functional Requirements

ID	Description
FR1	User must activate his/her location by using an existing setnav application
FR2	User must login to the application
FR3	Application will authenticate the user
FR4	Application will use the setnav application to find near petroil stations
FR5	Application will contact a local server to get the info (company, prices, availability) of the near petroil stations
FR6	Application will sort properly the list of available petroil station (best-price, distance and fidelty client)
FR7	User choses a particular petroil station
FR8	User gases up his/her car
FR9	User gives a feedback

Extensions

ID	Description
FR2.1	A 'Resume Password' request is be sent if the user forgot the password
FR2.2	Client fills up a 'Resume Password' module
FR2.3	An Authentication Server updates new user credentials
FR3.1	An authentication error message will be shown to the user. The system restarts from FR2
FR5.1	Administrator updates prices if they have been changed
FR5.2	Application will show updated information
FR7.1	If the user is a fidelity client he uses his/her fidelity card
FR7.2	If the fidelity card is invalid, the user can use the application to request a new one
FR7.3	If the user was already a fidelity card, the administrator gave him a grupon to be used temporarily
FR8.1	User applies possible discounts
FR9.1	Administrator check the feedback

Non Functional Requirements

ID	Type (efficiency, reliability, .. see iso 9126)	Description	Refers to
NFR1	Usability	Application should be used with no training by any users	All FR
NFR2	Performance	Authentication and Network services should be completed in a few seconds	FR2,FR3,FR5
NFR3	Portability	The application runs on mobile devices (Android) and desktops (Microsoft,Linux)	All FR
NFR4	Maintanance	Updates done by the feedback of the user should be integrated without any problem.	All FR
NFR5	Localisation	Euro is the current currency. A currency converter is made available within the application to help foreign users.	FR6

Glossary

interface EZGas


abstract User{
-location
-creditCard
}

class CreditCard{

}

class Maps{
	- x
	- y
	- isMoving
}


class Administrator{
-feedbackList
-pricesDatabase
}

abstract Transaction{
	+transactionID
}

class UpdateTransaction{

}

class PurchaseTransaction{

}

class UnregisteredUser{
-accountRequest

}

class RegisteredUser {
+ name
+ surname
}


class Account{
-accountID
-numberOfFeedback
-clientPoints
-fidelityLevel
}

class Feedback{
	+typeFeedback
	+accountID
	+feedback
}

User <|-- RegisteredUser
User <|-- UnregisteredUser

Transaction <|-- PurchaseTransaction
Transaction <|-- UpdateTransaction




EZGas -- "*" User
EZGas -- "1" Administrator


RegisteredUser -- "1" Account
Maps --  User
CreditCard -- "1" User
Administrator -- "1" UpdateTransaction
User -- "1" PurchaseTransaction
User -- "*" Feedback
Administrator -- "*" Feedback

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

REQ_s275905.md

REQ_s275905.md

Official Requirements Document

Contents

Abstract

Stakeholders

Context Diagram and interfaces

Context Diagram

Interfaces

Stories and personas

Use case diagrams and use cases

Use case diagrams

Use Cases

Use case 1, UC1 - FR1 Activate Position

Use case 2, UC2 - FR2 Login to the application

Use case 3, UC3 - FR3 Authenticate User

Use case 4, UC4 - FR4 Track customer position

Use case 5, Give last updated information

Use case 5.1, Update prices

Use case 6, Sort available gas stations

Use case 8, Gasing up

Use case 9, Giving feedback

Use case 9.1, Checking feedback

Relevant scenarios

Scenario 1

Scenario 2

Scenario 3

Functional and non functional requirements

Functional Requirements

Extensions

Non Functional Requirements

Glossary

Files

REQ_s275905.md

Latest commit

History

REQ_s275905.md

File metadata and controls

Official Requirements Document

Contents

Abstract

Stakeholders

Context Diagram and interfaces

Context Diagram

Interfaces

Stories and personas

Use case diagrams and use cases

Use case diagrams

Use Cases

Use case 1, UC1 - FR1 Activate Position

Use case 2, UC2 - FR2 Login to the application

Use case 3, UC3 - FR3 Authenticate User

Use case 4, UC4 - FR4 Track customer position

Use case 5, Give last updated information

Use case 5.1, Update prices

Use case 6, Sort available gas stations

Use case 8, Gasing up

Use case 9, Giving feedback

Use case 9.1, Checking feedback

Relevant scenarios

Scenario 1

Scenario 2

Scenario 3

Functional and non functional requirements

Functional Requirements

Extensions

Non Functional Requirements

Glossary