ECOM-1FO 1819 MySpectacle L5 SRS: Difference between revisions
Jump to navigation
Jump to search
Line 61: | Line 61: | ||
Scénario 2 : Nécessité d'avoir une configuration par défaut ? Demander au client |
Scénario 2 : Nécessité d'avoir une configuration par défaut ? Demander au client |
||
=3 Exigences particulières= |
|||
==3.1 Exigence 1 : Connexion au serveur== |
|||
'''Fonctionnalité''': |
|||
Connexion au serveur pour les utilisateurs (ouvreurs, spectateurs, gestionnaires, etc) |
|||
'''Description''': |
|||
Permet aux utilisateurs de récupérer les données en lignes |
|||
'''Inputs''': |
|||
'''Source''': |
|||
'''Outputs''': |
|||
'''Destination''': |
|||
'''Action''': |
|||
'''Non functional requirements''': |
|||
'''Pre-condition''': |
|||
'''Post-condition''': |
|||
'''Side-effects''': |
|||
=4 Evolution du produit= |
=4 Evolution du produit= |
Latest revision as of 08:31, 11 December 2018
1 Introduction
1.1 But du document
Ce SRS (Spécifications des exigences logicielles) identifie les exigences du projet ECOM MySpectacle. Il présentera
- les fonctionnalités de notre solution
- les problèmes résolus
- la liste de nos exigences système
1.2 Portée du projet
Réalisation d'un site internet et d'une application mobile pour la gestion de salles de spectacles. Plusieurs utilisateurs pourront se connecter avec notre plateforme :
Voici les différents utilisateurs du site web :
- L'administrateur : il gère le site internet et il a accès à toutes les données
- Les gestionnaires : un gestionnaire se connecte sur notre site internet, et il peut gérer sa salle de spectacle. Il peut indiquer la configuration de la salle (scène, chaises, orchestre, ...).
- Un superviseur : le superviseur est un gestionnaire qui s'occupe de la gestion des salles communales dans la globalité.
- Le client : un client se connecte au site web pour effectuer une réservation à un spectacle.
Pour l'application mobile
- L'hôte de caisse : l'hôte de caisse pourra utiliser l'application mobile pour scanner les billets des clients (pour leur indiquer leur place) ou bien créer une inscription et procéder au paiement (via PayPal).
1.3 Definitions, acronymes et abrévations
1.4 Références
2 Description générale
2.1 Perspective du produit
Notre produit a pour vocation d'être open-source
2.2 Fonctionnalités produit
- Visualisation des données (dashboard, vue avancée, ...)
- Réserver un spectacle
- Configurer une salle
- Scan pour la vérification des billets
- Génération de PDF
- Envoi d'e-mails
2.3 Caractéristiques de l'utilisateur
2.4 Contraintes générales
Mettre en place un serveur
2.5 Hypothèses et dépendances
L'ouvreur doit avoir un smartphone si un spectateur lui montre un QR code
Le spectateur doit avoir un smartphone fonctionel s'il possède un e-billet / QR code
Scénario 2 : Nécessité d'avoir une configuration par défaut ? Demander au client