Difference between revisions of "ECOM-1FO 1819 Sport L5 SRS"

From air
Jump to navigation Jump to search
Line 94: Line 94:
 
'''Description''': L'utilisateur remplis un formulaire et entre ses informations de paiement pour s'inscrire à un évènement.
  
'''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
−
'''Inputs''': Request of information
  
   
−
'''Source''': User application (Smart-phone)
 +
'''Source''': Application web
   
−
'''Outputs''': Information about users (localization, distress state, ID, post date)
 +
'''Outputs''': QR Code correspondant au dossard du participant
   
−
'''Destination''': User application (Smart-phone)
+
'''Destination''': Application web
   
 
'''Action''':
  
'''Action''':
−
* Smart-phone get request (input)
  
 
* REST API
 
* REST API
   
 
'''Non functional requirements''': None.
  
'''Non functional requirements''': None.
   
−
'''Pre-condition''': Smartphone Application, Internet connection.
 +
'''Pre-condition''': Application web, connexion internet.
   
 
'''Post-condition''': None.
  
'''Post-condition''': None.
Line 116: Line 115:
   
   
−
==3.3 Requirement 3 : Display Hikes==
 +
==3.3 Requirement 3 : Scan du dossard==
   
−
'''Function''': Display details of a hike (user localization and hike information).
 +
'''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''': User hike and localizations
 +
'''Inputs''': QRCode contenant les données
   
−
'''Source''': User (web-site)
 +
'''Source''': Application mobile
   
−
'''Outputs''': Information about a specific hike (localization, distress state)
 +
'''Outputs''': Données scannées du QRCode
   
−
'''Destination''': User (web-site)
+
'''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''': Internet connection, user account
 +
'''Pre-condition''': Application mobile, connexion internet (3G/4G).
   
 
'''Post-condition''': None.
  
'''Post-condition''': None.

Revision as of 18:48, 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

UseCaseParticipant ecom20182019 mescourses.png


Diagramme de cas d'utilisation d'un bénévole

UseCaseBenevole ecom20182019 mescourses.png


Diagramme de cas d'utilisation d'un organisateur

UseCaseOrganisateur ecom20182019 mescourses.png

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. 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=ECOM-1FO_1819_Sport_L5_SRS&oldid=43592"