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...") |
|||
(7 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
+ | =1. Introduction= |
||
− | The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard. |
||
+ | ==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 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 : |
||
− | '''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] |
||
+ | * 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. |
||
− | {|class="wikitable alternance" |
||
+ | * 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. |
||
− | |+ Document History |
||
+ | * 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. |
||
− | |- |
||
− | | |
||
− | !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.3 References== |
||
− | |} |
||
+ | *Page principale du projet: [https://air.imag.fr/index.php/ECOM-1FO_1819_Sport] |
||
+ | =2. Description générale= |
||
+ | ==2.1 Perspectives du projet== |
||
+ | Ce projet est un projet open source. |
||
+ | L'application web sera amenée à enregistrer des données à propos des utilisateurs, des évènements et des inscriptions. |
||
− | =1. Introduction= |
||
− | ==1.1 Purpose of the requirements document== |
||
− | This Software Requirements Specification (SRS) identifies the requirements for project [https://air.imag.fr/index.php/RICM4_2017_2018_-_UltraTeam_7.1 UltraTeam 7.1] |
||
− | This document is a guideline about the functionalities offered and the problems that the system solves. |
||
− | == |
+ | ==2.2 Fonctionnalités== |
− | 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) |
||
+ | ===Diagramme de cas d'utilisation d'un participant=== |
||
− | This project may allow hikers to visualize their hikes. |
||
+ | [[File:UseCaseParticipant_ecom20182019_mescourses.png]] |
||
− | It will also permit the synchronization of positions during the hike. |
||
+ | ===Diagramme de cas d'utilisation d'un bénévole=== |
||
− | ==1.3 Definitions, acronyms and abbreviations== |
||
+ | [[File:UseCaseBenevole_ecom20182019_mescourses.png]] |
||
− | DB = Data Base |
||
− | GPS = Global Positionning System |
||
+ | ===Diagramme de cas d'utilisation d'un organisateur=== |
||
− | ==1.4 References== |
||
+ | [[File:UseCaseOrganisateur_ecom20182019_mescourses.png]] |
||
− | *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 |
||
+ | ==2.3 Les différents types d'utilisateurs== |
||
− | ==1.5 Overview of the remainder of the document== |
||
+ | * 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. |
||
+ | Nous avons définis avec notre client qu'il était possible que : |
||
− | =2. General description= |
||
+ | Le coureur pourrait avoir un age médian plutôt jeune, le bénévole pourrait être retraité, et l'organisateur pourrait être un salarié de la quarantaine. |
||
− | ==2.1 Product perspective== |
||
− | Our Web site is an open source project. |
||
+ | Mais que ces contraintes devaient être amenées à être supprimées car cela n'avait pas de sens de fixer des tranches d'ages pour un projet comme celui-ci. |
||
− | 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== |
||
− | *Centralization and synchronization of data. |
||
− | *Data visualization. |
||
− | ==2. |
+ | ==2.4 Contraintes== |
+ | Pour s'inscrire à un évènement, les utilisteurs devront s'être inscrits sur l'application web. |
||
− | 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. |
||
+ | Nous ne différencions pas les différents types d'utilisateurs dans ce projet. Tout le monde peut être un organisateur et/ou un coureur et/ou un bénévole. |
||
− | ==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 |
+ | ==2.5 Dépendances== |
+ | Pour ce projet, nous utilisons la librairie de gestion de cartes [https://leafletjs.com/ Leaflet] ainsi qu'une API permettant de transformer un lieu (en string) en coordonnées (lon, lat) : [https://adresse.data.gouv.fr/api API] |
||
− | This project fully depends on [https://air.imag.fr/index.php/RICM4_2017_2018_-_UltraTeamMV UltraTeamMV] project to collect data. |
||
+ | =3.Exigences spécifiques, couvrant les exigences fonctionnelles, non fonctionnelles et d'interface= |
||
− | =3.Specific requirements, covering functional, non-functional and interface requirements= |
||
− | * |
+ | * Documenter les interfaces externes, |
− | * |
+ | * décrire la fonctionnalité et la performance du système |
+ | * spécifier les exigences de la base de données logique, |
||
− | * specify logical database requirements, |
||
+ | * contraintes de conception, |
||
− | * design constraints, |
||
+ | * les propriétés du système émergent et les caractéristiques de qualité. |
||
− | * emergent system properties and quality characteristics. |
||
− | ==3.1 Requirement 1 : |
+ | ==3.1 Requirement 1 : Création d'un évènement sportif== |
− | '''Function''': |
+ | '''Function''': Création d'un évènement sportif. |
+ | '''Description''': Remplissage d'un formulaire par l'organisateur d'un évènemenent pour le créer. Contient différents champs comme le prix, le lieu (qui sera transformé automatiquement en longitude et latitude), la description, le nom, etc. |
||
− | '''Description''': We will collect information from users (Smart-phone application -> Server) through REST API. |
||
+ | '''Inputs''': Informations sur l'évènement : Organisateur, Titre, Description, Sport, Date, Heure, Longitude, Latitude, Lieu, Prix, Image 1, Image 2, Image 3, Image 4, Image 5, Participants |
||
− | '''Inputs''': Information about the user (localization, distress state, ID, post date) |
||
− | '''Source''': |
+ | '''Source''': Application web |
− | '''Outputs''': |
+ | '''Outputs''': L'évènement qui à bien été créé dans la base de données. |
− | '''Destination''': |
+ | '''Destination''': Serveur |
'''Action''': |
'''Action''': |
||
+ | * REST API - MAJ de la base de données |
||
− | * Smart-phone post request (input) |
||
− | * REST API - update the DB |
||
'''Non functional requirements''': None. |
'''Non functional requirements''': None. |
||
− | '''Pre-condition''': |
+ | '''Pre-condition''': Application web, connexion internet. |
'''Post-condition''': None. |
'''Post-condition''': None. |
||
Line 113: | Line 88: | ||
− | ==3.2 Requirement 2 : |
+ | ==3.2 Requirement 2 : Inscription à un évènement sportif== |
− | '''Function''': |
+ | '''Function''': Ajout d'un utilisateur dans les participants d'une course (MAJ de la base de données) |
+ | '''Description''': L'utilisateur remplis un formulaire et entre ses informations de paiement pour s'inscrire à un évènement. |
||
− | '''Description''': We will send information (if necessary) to any hikers (who are in the same hike) (Server -> Smart-phone application ) through REST API. |
||
+ | '''Inputs''': Informations à propos de l'utilisateur (préremplis) + informations de paiement |
||
− | '''Inputs''': Request of information |
||
− | '''Source''': |
+ | '''Source''': Application web |
− | '''Outputs''': |
+ | '''Outputs''': QR Code correspondant au dossard du participant |
− | '''Destination''': |
+ | '''Destination''': Application web |
'''Action''': |
'''Action''': |
||
− | * Smart-phone get request (input) |
||
* REST API |
* REST API |
||
'''Non functional requirements''': None. |
'''Non functional requirements''': None. |
||
− | '''Pre-condition''': |
+ | '''Pre-condition''': Application web, connexion internet. |
'''Post-condition''': None. |
'''Post-condition''': None. |
||
Line 141: | Line 115: | ||
− | ==3.3 Requirement 3 : |
+ | ==3.3 Requirement 3 : Scan du dossard== |
− | '''Function''': |
+ | '''Function''': Met à jour la base de données en fonction des données scannées pendant l'évènement. |
+ | '''Description''': Pendant l'évènement, un bénévole scanne le dossard d'un participant avec son smartphone (et l'application mobile que nous avons développés), cela upload des données sur notre serveur. Ces données contiennent l'utilisateur scanné, l'évènement ainsi que l'heure. |
||
− | '''Description''': We will display information of a specific hike and we will also display a map of the itinerary (with real time positions). |
||
− | '''Inputs''': |
+ | '''Inputs''': QRCode contenant les données |
− | '''Source''': |
+ | '''Source''': Application mobile |
− | '''Outputs''': |
+ | '''Outputs''': Données scannées du QRCode |
− | '''Destination''': |
+ | '''Destination''': Application web (base de données) |
'''Action''': |
'''Action''': |
||
+ | * REST API |
||
− | * Connect to an user profile |
||
− | * Go on hike page |
||
− | * Select a specific hike |
||
'''Non functional requirements''': None. |
'''Non functional requirements''': None. |
||
− | '''Pre-condition''': |
+ | '''Pre-condition''': Application mobile, connexion internet (3G/4G). |
'''Post-condition''': None. |
'''Post-condition''': None. |
||
Line 168: | Line 140: | ||
'''Side-effects''': None. |
'''Side-effects''': None. |
||
− | =4. |
+ | =4. Evolutions possibles= |
− | |||
− | 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. |
||
+ | Une très bonne base a été développée pour ce projet. L'ensemble des scénario n'ont pas tous été implémentés, pour le futur, il faudra commencer par implémenter ces scénario. |
||
− | 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= |
||
==5.1. SRS structure== |
==5.1. SRS structure== |
||
− | + | Le document est basé sur le modèle de la spécification SRS (Software Requirements Specification) inspirée de la norme IEEE/ANSI 830-1998. |
|
'''References:''' |
'''References:''' |
Latest revision as of 18:51, 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. Description générale
2.1 Perspectives du projet
Ce projet est un projet open source.
L'application web sera amenée à enregistrer des données à propos des utilisateurs, des évènements et des inscriptions.
2.2 Fonctionnalités
Diagramme de cas d'utilisation d'un participant
Diagramme de cas d'utilisation d'un bénévole
Diagramme de cas d'utilisation d'un organisateur
2.3 Les différents types d'utilisateurs
- 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.
Nous avons définis avec notre client qu'il était possible que : Le coureur pourrait avoir un age médian plutôt jeune, le bénévole pourrait être retraité, et l'organisateur pourrait être un salarié de la quarantaine.
Mais que ces contraintes devaient être amenées à être supprimées car cela n'avait pas de sens de fixer des tranches d'ages pour un projet comme celui-ci.
2.4 Contraintes
Pour s'inscrire à un évènement, les utilisteurs devront s'être inscrits sur l'application web.
Nous ne différencions pas les différents types d'utilisateurs dans ce projet. Tout le monde peut être un organisateur et/ou un coureur et/ou un bénévole.
2.5 Dépendances
Pour ce projet, nous utilisons la librairie de gestion de cartes Leaflet ainsi qu'une API permettant de transformer un lieu (en string) en coordonnées (lon, lat) : API
3.Exigences spécifiques, couvrant les exigences fonctionnelles, non fonctionnelles et d'interface
- Documenter les interfaces externes,
- décrire la fonctionnalité et la performance du système
- spécifier les exigences de la base de données logique,
- contraintes de conception,
- les propriétés du système émergent et les caractéristiques de qualité.
3.1 Requirement 1 : Création d'un évènement sportif
Function: Création d'un évènement sportif.
Description: Remplissage d'un formulaire par l'organisateur d'un évènemenent pour le créer. Contient différents champs comme le prix, le lieu (qui sera transformé automatiquement en longitude et latitude), la description, le nom, etc.
Inputs: Informations sur l'évènement : Organisateur, Titre, Description, Sport, Date, Heure, Longitude, Latitude, Lieu, Prix, Image 1, Image 2, Image 3, Image 4, Image 5, Participants
Source: Application web
Outputs: L'évènement qui à bien été créé dans la base de données.
Destination: Serveur
Action:
- REST API - MAJ de la base de données
Non functional requirements: None.
Pre-condition: Application web, connexion internet.
Post-condition: None.
Side-effects: None.
3.2 Requirement 2 : Inscription à un évènement sportif
Function: Ajout d'un utilisateur dans les participants d'une course (MAJ de la base de données)
Description: L'utilisateur remplis un formulaire et entre ses informations de paiement pour s'inscrire à un évènement.
Inputs: Informations à propos de l'utilisateur (préremplis) + informations de paiement
Source: Application web
Outputs: QR Code correspondant au dossard du participant
Destination: Application web
Action:
- REST API
Non functional requirements: None.
Pre-condition: Application web, connexion internet.
Post-condition: None.
Side-effects: None.
3.3 Requirement 3 : Scan du dossard
Function: Met à jour la base de données en fonction des données scannées pendant l'évènement.
Description: Pendant l'évènement, un bénévole scanne le dossard d'un participant avec son smartphone (et l'application mobile que nous avons développés), cela upload des données sur notre serveur. Ces données contiennent l'utilisateur scanné, l'évènement ainsi que l'heure.
Inputs: QRCode contenant les données
Source: Application mobile
Outputs: Données scannées du QRCode
Destination: Application web (base de données)
Action:
- REST API
Non functional requirements: None.
Pre-condition: Application mobile, connexion internet (3G/4G).
Post-condition: None.
Side-effects: None.
4. Evolutions possibles
Une très bonne base a été développée pour ce projet. L'ensemble des scénario n'ont pas tous été implémentés, pour le futur, il faudra commencer par implémenter ces scénario.
5. Appendices
5.1. SRS structure
Le document est basé sur le modèle de la spécification SRS (Software Requirements Specification) inspirée de la norme IEEE/ANSI 830-1998.
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