ECOM-1FO 1819 Sport L5 SRS
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