Skip to content

Latest commit

 

History

History
197 lines (148 loc) · 9.4 KB

REQ_s270121.md

File metadata and controls

197 lines (148 loc) · 9.4 KB

EZGas - Official Requirements Document

Author: Fabio Stabile

Contents

Abstract

EZGas is a crowdsourcing service that allows users to collect prices of fuels in different gas stations and locate gas stations in an area, along with the prices they practice.

Stakeholders

Stakeholder name Description
User Uses the application to locate gas station with their prices.
Registered User Special user who can also use the application to send request to update gas stations' informations
Administrator Checks data inserted by user and manages the application.
Google Maps Provides Map services to visualize gas stations on a map. It is possible throw dedicated APIs.
Database It is used to collect data generated by the application.

Context Diagram and interfaces

Context Diagram

Interfaces

Actor Logical Interface Physical Interface
User GUI Screen, keyboard
Administrator GUI Screen, keyboard
Google Maps API, data exchange Internet connection
Database API, data exchange Internet connection

Stories and personas

Andy is the administrator of the EZGas app. He can manage the different gas stations' changes proposed by users. He opens the app and accept or decline changes. All the changes are uploaded into the system.

Bob is a middle edge man who likes to drive and to save money for the fuel. Therefore, when his car needs fuel, he wants to find the best gas station that can offer the lowest price. Bob opens the EZGas application and, using the GPS, locates on map the best gas station based on price and distance. Bob select the gas station and uses the directions offered by the application. Bob reaches the gas station and is happy because he can save money and continue to drive his lovely car.

Charlie has found a new gas station with incredible prices and wants to share his discovery with everyone. Therefore, he opens the EZGas application, logs in and asks for create a new gas station location on the map, with its prices. Charlie compiles all the form and sends the application to the administrator of the app. Now Charlie feel good because he have done something useful for the community.

Functional and non functional requirements

Functional Requirements

ID Description
FR1 Display on a map the gas stations' locations
FR2 Manage gas station creation
FR2.1 Insert a new gas station in the map with its prices
FR2.2 Delete a gas station from the system
FR2.3 Update gas station's prices
FR3 Provide directions to reach a gas station
FR4 Manage user session
FR4.1 Create new user
FR4.2 Log in
FR4.3 Log out

Non Functional Requirements

ID Type (efficiency, reliability, .. see iso 9126) Description Refers to
NFR1 Usability Application should be used with no training by users All FR
NFR2 Performance All functions should complete in < 0.5 sec All FR
NFR3 Performance Data is taken from DB in < 1 sec All FR
NFR4 Portability The application runs on Windows, Android and IOs All FR
NFR5 Portability The application (functions and data) should be portable from a PC to another PC in less than 1 minute All FR

Use case diagram and use cases

Use case diagram

Use Cases

Use case 1, UC1 - FR1 Display gas stations locations

Actors Involved User, Database, Google Maps
Precondition Database should contains gas station list
Post condition Gas stations have to be displayed on the map
Nominal Scenario User select to open the map. EZGas query the DB to receive the list of gas station in the area of the user. EZGas uses Google API to display the locations
Variants Lost of connection. There are not gas stations near the user

Use case 2, UC2 - FR2 Manage gas station creation

Actors Involved Registered user, Administrator, Database
Precondition Registered user has to be logged in
Post condition Database updated
Nominal Scenario User compile the form to send a new request for a new gas station. Administrator evaluates the request and decide to accept or decline it. If the request is accepted the database is updated
Variants If the request is declined ther is not database update

Use case 3, UC3 - FR3 Provide directions to reach the gas station

Actors Involved User, Google Maps
Precondition
Post condition
Nominal Scenario User select a gas station on the map and asks for direction. Google Maps provides directions.
Variants Lost connection

Use case 4, UC4 - FR4 Manage user account

Actors Involved User
Precondition
Post condition Database updated
Nominal Scenario User decide to create a new account to use the EZGas application. He compiles the form and submit it to the system. The system create a new account. If the user decides to delete his account, he can do it in his account manager section and the system deletes the account.
Variants Lost connection

Relevant scenarios

Scenario 1

Scenario ID: SC1 Corresponds to UC1
Description User uses the app to visualize the map with the gas stations information
Precondition
Postcondition
Step# Step description
1 User selects the map
2 System query the database to obtain the information about all the gas stations near the user and send it throw Maps API
3 Maps API elaborates information to provide the interactive map with information displayed

Scenario 2

Scenario ID: SC2 Corresponds to UC2
Description User find a new gas station and wwants to uoload it on the EZGas application
Precondition Registered user has to be logged in
Postcondition
Step# Step description
1 Registered user logs in and clicks on "Add new gas station information" and fill the form
2 System upload the request into the database and visualizes a messagge
3 Administrator check the request and decide to accept or decline it
3.1 If administrator decide to accept the request, database is updated with new information

Scenario 3

Scenario ID: SC3 Corresponds to UC4
Description Creation of a new user
Precondition
Postcondition
Step# Step description
1 User click on "Sign in" and fill the form
2 System check the form
2.1 If everything is ok, system completes registration and send an email to the user's account
2.2 If something is wrong, system reject the registration

Glossary

System Design

Deployment Diagram