Difference between revisions of "ECOM-1FO 1819 Sport L5 SRS"
(Created page with "The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard. '''Read first:''' * http://www.cs.st-an...") |
|||
Line 1: | Line 1: | ||
− | The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard. |
||
− | |||
− | |||
− | '''Read first:''' |
||
− | * http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx |
||
− | * http://en.wikipedia.org/wiki/Software_requirements_specification |
||
− | * [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998] |
||
− | |||
− | {|class="wikitable alternance" |
||
− | |+ Document History |
||
− | |- |
||
− | | |
||
− | !scope="col"| Version |
||
− | !scope="col"| Date |
||
− | !scope="col"| Authors |
||
− | !scope="col"| Description |
||
− | !scope="col"| Validator |
||
− | !scope="col"| Validation Date |
||
− | |- |
||
− | !scope="row" | |
||
− | | 0.1.0 |
||
− | | TBC |
||
− | | TBC |
||
− | | TBC |
||
− | | TBC |
||
− | | TBC |
||
− | |||
− | |} |
||
− | |||
− | |||
=1. Introduction= |
=1. Introduction= |
||
− | ==1.1 |
+ | ==1.1 But du document== |
− | + | Cette spécification des exigences logicielles (SRS) identifie les exigences du projet [https://air.imag.fr/index.php/ECOM-1FO_1819_Sport]. |
|
− | + | Ce document est un guide sur les fonctionnalités offertes et les problèmes que le système résout. |
|
− | |||
− | ==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 [https://air.imag.fr/index.php/RICM4_2017_2018_-_UltraTeamMV UltraTeamMV] |
||
− | * Synchronize data between server and clients |
||
− | * Data visualization (from [https://air.imag.fr/index.php/RICM4_2017_2018_-_UltraTeamMV UltraTeamMV] hikes) |
||
− | |||
− | This project may allow hikers to visualize their hikes. |
||
− | |||
− | It will also permit the synchronization of positions during the hike. |
||
− | ==1. |
+ | ==1.2 Visée du projet== |
+ | Le but de ce projet est de réaliser une application web ainsi qu'une application mobile permettant la création, la gestion, l'inscription, la participation et le paiement des frais à des évènements sportifs comme des marathons, des courses à pied, des courses de vélo, etc. |
||
− | DB = Data Base |
||
+ | Les différents types d'utilisateurs que nous pourrons retrouver dans notre application sont : |
||
− | GPS = Global Positionning System |
||
+ | * L'organisateur, c'est lui qui créé les évènements, il peut accéder à son "Espace Organisateur" pour visualiser ses évènements, les participants, etc. |
||
⚫ | |||
+ | * Le bénévole, il peut s'inscrire gratuitement à un évènement en tant que bénévole pour différents roles : Kinésithérapiste, photographe, docteur, etc. |
||
− | *The main page of the project: [http://air.imag.fr/index.php/UltraTeam UltraTeam] |
||
+ | * Le coureur, c'est l'utilisateur de base, il peut s'inscrire à un évènement sportif et payer son inscription. Il pourra ensuite se rendre à l'évènement et y participer. |
||
− | *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 |
||
⚫ | |||
− | ==1.5 Overview of the remainder of the document== |
||
+ | *Page principale du projet: [https://air.imag.fr/index.php/ECOM-1FO_1819_Sport] |
||
=2. General description= |
=2. General description= |
Revision as of 12:35, 11 December 2018
1. Introduction
1.1 But du document
Cette spécification des exigences logicielles (SRS) identifie les exigences du projet [1]. Ce document est un guide sur les fonctionnalités offertes et les problèmes que le système résout.
1.2 Visée du projet
Le but de ce projet est de réaliser une application web ainsi qu'une application mobile permettant la création, la gestion, l'inscription, la participation et le paiement des frais à des évènements sportifs comme des marathons, des courses à pied, des courses de vélo, etc.
Les différents types d'utilisateurs que nous pourrons retrouver dans notre application sont :
- L'organisateur, c'est lui qui créé les évènements, il peut accéder à son "Espace Organisateur" pour visualiser ses évènements, les participants, etc.
- Le bénévole, il peut s'inscrire gratuitement à un évènement en tant que bénévole pour différents roles : Kinésithérapiste, photographe, docteur, etc.
- Le coureur, c'est l'utilisateur de base, il peut s'inscrire à un évènement sportif et payer son inscription. Il pourra ensuite se rendre à l'évènement et y participer.
1.3 References
- Page principale du projet: [2]
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:
- http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
- http://en.wikipedia.org/wiki/Software_requirements_specification
- IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998