Difference between revisions of "RICM4 2017 2018 - UltraTeam 7.1/ SRS"

From air
Jump to navigation Jump to search
 
(16 intermediate revisions by one other user not shown)
Line 38: Line 38:
 
* Collect data from the web application [https://air.imag.fr/index.php/RICM4_2017_2018_-_UltraTeamMV UltraTeamMV]
  
* Collect data from the web application [https://air.imag.fr/index.php/RICM4_2017_2018_-_UltraTeamMV UltraTeamMV]
 
* Synchronize data between server and clients
 
* Synchronize data between server and clients
−
* Data visualization (from [https://air.imag.fr/index.php/RICM4_2017_2018_-_UltraTeamMV UltraTeamMV] hikes ]
 +
* Data visualization (from [https://air.imag.fr/index.php/RICM4_2017_2018_-_UltraTeamMV UltraTeamMV] hikes)
   
 
This project may allow hikers to visualize their hikes.
  
This project may allow hikers to visualize their hikes.
Line 50: Line 50:
   
 
==1.4 References==
  
==1.4 References==
−
*The main page of the project: [https://air.imag.fr/index.php/RICM4_2017_2018_-_UltraTeam_7.1 UltraTeam_7.1]
 +
*The main page of the project: [http://air.imag.fr/index.php/UltraTeam UltraTeam]
  +
*The page of our contribution [https://air.imag.fr/index.php/RICM4_2017_2018_-_UltraTeam_7.1 UltraTeam_7.1]
 
*[https://air.imag.fr/index.php/RICM4_2017_2018_-_UltraTeam_7.1/UML UML] diagrams
  
*[https://air.imag.fr/index.php/RICM4_2017_2018_-_UltraTeam_7.1/UML UML] diagrams
   
Line 57: Line 58:
 
=2. General description=
  
=2. General description=
 
==2.1 Product perspective==
  
==2.1 Product perspective==
−
Our Web site is an open source project. This site will store and display data (GPS localisation from []users ).
 +
Our Web site is an open source project.
  +
  +
This site will store and display data (GPS localisation from [https://air.imag.fr/index.php/RICM4_2017_2018_-_UltraTeamMV UltraTeamMV] users ).
   
 
==2.2 Product functions==
  
==2.2 Product functions==
  +
*Centralization and synchronization of data.
  +
*Data visualization.
  +
 
==2.3 User characteristics==
  
==2.3 User characteristics==
  +
The typical user is a hiker who did a hike using [https://air.imag.fr/index.php/RICM4_2017_2018_-_UltraTeamMV UltraTeamMV] application.
  +
The user doesn't need specific or technical knowledge, just a basic Internet usage.
  +
 
==2.4 General constraints==
  
==2.4 General constraints==
  +
To visualize the hike, the user will have to use an external application developed by our colleagues.
  +
An Internet connection will be necessary to upload data from the application to the server.
  +
(Not necessarily at any time of the hike)
  +
 
==2.5 Assumptions and dependencies==
  
==2.5 Assumptions and dependencies==
  +
This project fully depends on [https://air.imag.fr/index.php/RICM4_2017_2018_-_UltraTeamMV UltraTeamMV] project to collect data.
  +
 
=3.Specific requirements, covering functional, non-functional and interface requirements=
  
=3.Specific requirements, covering functional, non-functional and interface requirements=
 
* document external interfaces,
  
* document external interfaces,
Line 70: Line 85:
 
* emergent system properties and quality characteristics.
  
* emergent system properties and quality characteristics.
   
−
==3.1 Requirement X.Y.Z (in Structured Natural Language)==
  
−
'''Function''': Recover data coming from users doing a hike. They can visualize their path and the system can send emergencies if they sent a SOS signal.
  
   
  +
==3.1 Requirement 1 : Load and store DATA==
−
'''Description''': recover data via API REST, data sent by the user (date, position, SOS signal,...).
  
   
  +
'''Function''': Take data (user localization and distress state) via HTTP (REST API).
−
'''Inputs''': API REST
  
   
−
'''Source''': Smartphone application of the user
 +
'''Description''': We will collect information from users (Smart-phone application -> Server) through REST API.
   
  +
'''Inputs''': Information about the user (localization, distress state, ID, post date)
−
'''Outputs''': Visualization of data through to maps, and it allows user to analyze his hike.
  
   
  +
'''Source''': User application (Smart-phone)
−
'''Destination''': Website
  
  +
  +
'''Outputs''': Data stored in the server DB
  +
  +
'''Destination''': Server
   
 
'''Action''':
  
'''Action''':
  +
* Smart-phone post request (input)
−
* Natural language sentences (with MUST, MAY, SHALL)
  
  +
* REST API - update the DB
−
* Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
  
−
* Mathematical Notations
  
−
* Tabular notations for several (condition --> action) tuples
  
   
  +
'''Non functional requirements''': None.
−
Application done with Jhipster. Stocking data in SQL database. User can visualize his own information.
  
−
(TODO)
  
   
  +
'''Pre-condition''': Smartphone Application, Internet connection.
   
  +
'''Post-condition''': None.
−
'''Non functional requirements''':
  
   
  +
'''Side-effects''': None.
−
'''Pre-condition''': Smartphone + Mobile phone plan with internet package / Wi-Fi.
  
   
−
'''Post-condition''': Detailed map of the path and live analyzing.
  
   
  +
==3.2 Requirement 2 : Send DATA==
−
'''Side-effects''':
  
  +
  +
'''Function''': Send data (user localization and distress state) via HTTP (REST API) to every hikers of the hike.
  +
  +
'''Description''': We will send information (if necessary) to any hikers (who are in the same hike) (Server -> Smart-phone application ) through REST API.
  +
  +
'''Inputs''': Request of information
  +
  +
'''Source''': User application (Smart-phone)
  +
  +
'''Outputs''': Information about users (localization, distress state, ID, post date)
  +
  +
'''Destination''': User application (Smart-phone)
  +
  +
'''Action''':
  +
* Smart-phone get request (input)
  +
* REST API
  +
  +
'''Non functional requirements''': None.
  +
  +
'''Pre-condition''': Smartphone Application, Internet connection.
  +
  +
'''Post-condition''': None.
  +
  +
'''Side-effects''': None.
  +
  +
  +
  +
==3.3 Requirement 3 : Display Hikes==
  +
  +
'''Function''': Display details of a hike (user localization and hike information).
  +
  +
'''Description''': We will display information of a specific hike and we will also display a map of the itinerary (with real time positions).
  +
  +
'''Inputs''': User hike and localizations
  +
  +
'''Source''': User (web-site)
  +
  +
'''Outputs''': Information about a specific hike (localization, distress state)
  +
  +
'''Destination''': User (web-site)
  +
  +
'''Action''':
  +
* Connect to an user profile
  +
* Go on hike page
  +
* Select a specific hike
  +
  +
'''Non functional requirements''': None.
  +
  +
'''Pre-condition''': Internet connection, user account
  +
  +
'''Post-condition''': None.
  +
  +
'''Side-effects''': None.
   
 
=4. Product evolution=
  
=4. Product evolution=
  +
  +
What must be done to make this project evolve is to make the link between the mobile application and the web application.
  +
  +
The databases and data models between the two applications are already consistent.
  +
It will be necessary to be able to send messages (entity) from the mobile application to the web application with the REST API.
  +
  +
The SOS principle is also already implemented on the web application, all that remains is to make visible all the hikes with at least one SOS for users of the "Emergency" type (not currently implemented).
   
 
=5. Appendices=
  
=5. Appendices=

Latest revision as of 10:52, 3 April 2018

The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard.


Read first:

Document History
Version Date Authors Description Validator Validation Date
0.1.0 TBC TBC TBC TBC TBC


1. Introduction

1.1 Purpose of the requirements document

This Software Requirements Specification (SRS) identifies the requirements for project UltraTeam 7.1 This document is a guideline about the functionalities offered and the problems that the system solves.

1.2 Scope of the product

The aim of this project is to create a Web Site with these specifications :

  • Collect data from the web application UltraTeamMV
  • Synchronize data between server and clients
  • Data visualization (from UltraTeamMV hikes)

This project may allow hikers to visualize their hikes.

It will also permit the synchronization of positions during the hike.

1.3 Definitions, acronyms and abbreviations

DB = Data Base

GPS = Global Positionning System

1.4 References

1.5 Overview of the remainder of the document

2. General description

2.1 Product perspective

Our Web site is an open source project.

This site will store and display data (GPS localisation from UltraTeamMV users ).

2.2 Product functions

  • Centralization and synchronization of data.
  • Data visualization.

2.3 User characteristics

The typical user is a hiker who did a hike using UltraTeamMV application. The user doesn't need specific or technical knowledge, just a basic Internet usage.

2.4 General constraints

To visualize the hike, the user will have to use an external application developed by our colleagues. An Internet connection will be necessary to upload data from the application to the server. (Not necessarily at any time of the hike)

2.5 Assumptions and dependencies

This project fully depends on UltraTeamMV project to collect data.

3.Specific requirements, covering functional, non-functional and interface requirements

  • document external interfaces,
  • describe system functionality and performance
  • specify logical database requirements,
  • design constraints,
  • emergent system properties and quality characteristics.


3.1 Requirement 1 : Load and store DATA

Function: Take data (user localization and distress state) via HTTP (REST API).

Description: We will collect information from users (Smart-phone application -> Server) through REST API.

Inputs: Information about the user (localization, distress state, ID, post date)

Source: User application (Smart-phone)

Outputs: Data stored in the server DB

Destination: Server

Action:

  • Smart-phone post request (input)
  • REST API - update the DB

Non functional requirements: None.

Pre-condition: Smartphone Application, Internet connection.

Post-condition: None.

Side-effects: None.


3.2 Requirement 2 : Send DATA

Function: Send data (user localization and distress state) via HTTP (REST API) to every hikers of the hike.

Description: We will send information (if necessary) to any hikers (who are in the same hike) (Server -> Smart-phone application ) through REST API.

Inputs: Request of information

Source: User application (Smart-phone)

Outputs: Information about users (localization, distress state, ID, post date)

Destination: User application (Smart-phone)

Action:

  • Smart-phone get request (input)
  • REST API

Non functional requirements: None.

Pre-condition: Smartphone Application, Internet connection.

Post-condition: None.

Side-effects: None.


3.3 Requirement 3 : Display Hikes

Function: Display details of a hike (user localization and hike information).

Description: We will display information of a specific hike and we will also display a map of the itinerary (with real time positions).

Inputs: User hike and localizations

Source: User (web-site)

Outputs: Information about a specific hike (localization, distress state)

Destination: User (web-site)

Action:

  • Connect to an user profile
  • Go on hike page
  • Select a specific hike

Non functional requirements: None.

Pre-condition: Internet connection, user account

Post-condition: None.

Side-effects: None.

4. Product evolution

What must be done to make this project evolve is to make the link between the mobile application and the web application.

The databases and data models between the two applications are already consistent. It will be necessary to be able to send messages (entity) from the mobile application to the web application with the REST API.

The SOS principle is also already implemented on the web application, all that remains is to make visible all the hikes with at least one SOS for users of the "Emergency" type (not currently implemented).

5. Appendices

5.1. SRS structure

The document is based on template of the Software Requirements Specification (SRS) inspired of the IEEE/ANSI 830-1998 Standard.

References:

6. Index

Retrieved from "https://air.imag.fr/index.php?title=RICM4_2017_2018_-_UltraTeam_7.1/_SRS&oldid=41209"