Latest revision as of 19:26, 19 October 2015

Document History
	Version	Date	Auteurs	Description	Validateur	Date de validation
	0.1.0	19/10/2015	Robin Eudes, Malek Mammar, Zhang Zhengmeng	Présentation des exigences ECOM-Restauration perosonalisée	X	X

Introduction

Objectif du document d'exigence

Ce document présente les exigences fonctionnelles, non fonctionnelles ainsi que les différents critères de qualité et risques intervenant dans le projet ECOM - Restauration Personnalisée.

Cadre du produit

Ce produit intervient dans le cadre de notre formation d'ingénieur RICM5 (Réseau Informatique & Communication Multimédia) de l'école Polytech Grenoble. Ce produit sera réalisé par une équipe de 3 étudiants, au cours du premier semestre de l'année 5 (RICM5).

Définitions, acronymes et abréviations

JavaEE : Java Enterprise Edition (anciennement J2EE).
EJB : Entreprise Java Bean , des composants du serveur d'application
Entity Beans : Un type de bean représentant des données persistantes stockées dans une base de données.
Session Beans : Un type de bean qui encapsule le code métier, sa durée de vie est limitée à la session. Ces beans seront invoqués par le client pour effectuer certaine taches au cours de la session.

Description générale

Le site porte sur un service de restauration personnalisée. Deux modes de fonctionnement vous sont possibles :

des formules sont proposées par des artisans restaurateurs, sur lesquelles il vous est possible d’imposer des contraintes (la cuisson,...) selon vos affinités gustative, si l’artisan le propose.

des thèmes culinaires sont proposés par des artisans restaurateurs qui se charge de répondre à votre demande de plat dans un temps imparti. Il est à noter que l’artisan peut librement accepter ou refuser le traitement de votre demande dans la mesure des stocks disponibles. Dans le cas d’un refus une proposition peut vous être faite par l’artisan.

Perspective du produit

Fonctions du produit

Acheter des plats personnalisés (assaisonnement ou concernant une allergie à un aliment)
- Sous la forme d'une formule (ensemble de plats)
- À l'unité

Proposer des plats personnalisables (assaisonnement ou concernant une allergie à un aliment)
- À l'unité
- Sous la forme de formules (menus)

Caractéristiques de l'utilisateur

Etudiant, tranche d'âge : 18-25 ou salarié
Habitué des commandes en ligne

Contraintes générales

Performance
Sécurité
Disponibilité
Interopérabilité

Hypothèses et dépendances

On suppose avoir à disposition un service de livraison performant (sans erreur), et sans surcoût sur le prix affiché lors de la commande.

Exigences spécifiques, exigences d'interface, exigences fonctionnelles, exigences non fonctionnelles

Exigences

Fonction : Création d'un site e-commerce

Description : Création d'un site de commande de restauration personnalisée.

Inputs : Ordinateur, smartphone, tablette

Outputs : Ordinateur, smartphone, tablette

Destination : Tout public, orienté Etudiant (18-25) et salariés

Action :

Exigences fonctionnelles :

Tâches prioritaires
- Gestion d'une session sécurisée
- Acteur client : Effectuer une commande
- Acteur client : Gérer son panier
- Acteur artisan : Gérer son catalogue

Tâches secondaires
- Acteur client : Effectuer un appel d'offre
- Acteur artisan : Répondre à un appel d'offre

Exigences non fonctionnelles :

Propriétés ACID sur les transactions (en particulier le paiement)
Interface user-friendly, selon Les critères ergonomiques de Bastien & Scapin
Gestion fine de l'utilisation de HTTPS
Résistance du système à la montée en charge (Temps de service constant)
Réduire au minimum le parcours de paiement
Portabilité (responsive design) PC, mobiles.

Risques :

Indisponibilité du service
Faille dans la sécurité (données utilisateurs sensibles)

Qualité :

Pré-condition :

Disposer d'un appareil compatible (ordinateur,smartphone,tablette)
Disposer d'un accès Internet

Post-condition :

Réception de la commande

Évolutions du produit

Accroître la compatibilité de notre service avec différents moyens de paiement (Paypal, Izly...)
Accroître notre base de restaurateurs proposant des plats
Développer un partenariat avec un service de livraison

@@ Line 1: / Line 1: @@
+ {|class="wikitable alternance"
-{|class="wikitable alternance"
  |+ Document History
  |-
@@ Line 6: / Line 5: @@
  !scope="col"| Version
  !scope="col"| Date
- !scope="col"| Authors
+ !scope="col"| Auteurs
  !scope="col"| Description
- !scope="col"| Validator
+ !scope="col"| Validateur
- !scope="col"| Validation Date
+ !scope="col"| Date de validation
  |-
  !scope="row" |
  | 0.1.0
- | TBC
+ | 19/10/2015
+ |[[User:Robin.Eudes|Robin Eudes]], [[User:Malek-Hadi.Mammar|Malek Mammar]], [[User:Zhengmeng.Zhang|Zhang Zhengmeng]]
- | Eudes, Rossi
+ | Présentation des exigences ECOM-Restauration perosonalisée
- | TBC
- | TBC
+ | X
- | TBC
+ | X
  |}
-=1.   Introduction=
+=Introduction=
+==Objectif du document d'exigence==
-==1.1   Purpose of the requirements document==
+Ce document présente les exigences fonctionnelles, non fonctionnelles ainsi que les différents critères de qualité et risques intervenant dans le projet '''''[http://air.imag.fr/index.php/ECOM_RICM5_Groupe5_2015 ECOM - Restauration Personnalisée]'''''.
-This Software Requirements Specification (SRS) identifies the requirements for this datacenter's webUI. The purpose of this document is to easily explain the development of this project and to provide instructions to understand and use the software.
-==1.2   Scope of the product==
+==Cadre du produit==
-The purpose of this project is to provide an userfriendly web interface to simulate and use a small datacenter.
+Ce produit intervient dans le cadre de notre formation d'ingénieur RICM5 (Réseau Informatique & Communication Multimédia) de l'école Polytech Grenoble. Ce produit sera réalisé par une équipe de 3 étudiants, au cours du premier semestre de l'année 5 (RICM5).
-Each node of the datacenter can perform some operations, users can interact with a group of nodes or a specific one.
-==1.3   Definitions, acronyms and abbreviations==
+==Définitions, acronymes et abréviations==
-* Frontend: intern server allowing to interact with OAR-docker
+* JavaEE : Java Enterprise Edition (anciennement J2EE).
-* OAR: task and resources manager
+* EJB : Entreprise Java Bean , des composants du serveur d'application
-* Docker: virtualization tools, using containers' technologies
+* Entity Beans : Un type de bean représentant des données persistantes stockées dans une base de données.
-* Containers: VMs sharing their OS, comprising only an application and its dependencies
+* Session Beans : Un type de bean qui encapsule le code métier, sa durée de vie est limitée à la session. Ces beans seront invoqués par le client pour effectuer certaine taches au cours de la session.
-* Cluster: group of nodes link together
-* Node: calculating unit
+=Description générale=
-==1.4   References==
+Le site porte sur un service de restauration personnalisée.
-* [https://www.grid5000.fr Grid'5000]
+Deux modes de fonctionnement vous sont possibles :
-* [http://oar.imag.fr OAR] OAR is a versatile resource and task manager (also called a batch scheduler) for HPC clusters and other computing infrastructures. It's used on Grid'5000.
-* [https://github.com/oar-team/oar-docker OAR-docker]: oar-docker is a set of docker images especially configured for deploying your own OAR cluster. The main idea is to have a mini development cluster with a frontend, a server and some nodes that launch in just a few seconds on a simple laptop.
-* [http://oar.imag.fr/sources/2.5/docs/documentation/OAR-DOCUMENTATION-API-USER/ API REST] API for OAR
-* [http://getbootstrap.com/ Boostrap ] CSS
-* [http://www.datatables.net/ Datatables ] JQuery plugin, allowing to use tables
-* [http://jquery.malsup.com/form/ JQuery Plugin Form] JQuery plugin, allowing to check form
+* des formules sont proposées par des artisans restaurateurs, sur lesquelles il vous est possible d’imposer des contraintes (la cuisson,...) selon vos affinités gustative, si l’artisan le propose.
-==1.5   Overview of the remainder of the document==
-The SRS document includes 3 main chapters :
-* General description, which contains the general characteristics of the project and our implementation choices.
-* Specific requirements, which gives the main requirements of each function.
-* Product evolution, which details the different steps of implementation we chose.
-=2.   General description=
-==2.1   Product perspective==
-Our project is based on a simulated infrastructure provided by OAR-docker. This cluster is made up of nodes, which can be used by only one user at a time.
-Our goal is to product a webUI easily understandable and usable by non-developers.
-As OAR-docker is designed only to test locally sub-developments' step, our webUI is not appropriate for external access.
+* des thèmes culinaires sont proposés par des artisans restaurateurs qui se charge de répondre à votre demande de plat dans un temps imparti. Il est à noter que l’artisan peut librement accepter ou refuser le traitement de votre demande dans la mesure des stocks disponibles. Dans le cas d’un refus une proposition peut vous être faite par l’artisan.
-==2.2   Product functions==
+==Perspective du produit==
-With this interface, users will be able to manage each node, submit a job to a node, cancel a job, create or delete a node.
+==Fonctions du produit==
-[[File:Diagramme_contexte.bmp]]
+* Acheter des plats personnalisés (assaisonnement ou concernant une allergie à un aliment)
+** Sous la forme d'une formule (ensemble de plats)
+** À l'unité
+* Proposer des plats personnalisables (assaisonnement ou concernant une allergie à un aliment)
-==2.3   User characteristics==
+** À l'unité
-The user can interacts with the interface even if he does not know how to manage the resources or deal with jobs.
+** Sous la forme de formules (menus)
+==Caractéristiques de l'utilisateur==
-[[File:Diagramme_utilisateur.bmp]]
+* Etudiant, tranche d'âge : 18-25 ou salarié
+* Habitué des commandes en ligne
+==Contraintes générales==
-==2.4   General constraints==
+* Performance
-We have to gain access to the simulation in a private environment where docker is installed.
+* Sécurité
+* Disponibilité
+* Interopérabilité
+==Hypothèses et dépendances==
-==2.5   Assumptions and dependencies==
+* On suppose avoir à disposition un service de livraison performant (sans erreur), et sans surcoût sur le prix affiché lors de la commande.
-* Web browser which can interpret AJAX
+=Exigences spécifiques, exigences d'interface, exigences fonctionnelles, exigences non fonctionnelles=
-=3. Specific requirements, covering functional, non-functional and interface requirements=
+==Exigences==
-==3.1 Requirement X.Y.Z (in Structured Natural Language)==
+'''Fonction'''  : Création d'un site e-commerce
-'''Function''':
-* Gather information from several nodes
-* Post information on a webUI, available from a browser
-'''Description''':
+'''Description'''  : Création d'un site de commande de restauration personnalisée.
-* Generate an interface allowing to check resources' states, create or delete nodes and jobs
-'''Inputs''':
+'''Inputs'''  : Ordinateur, smartphone, tablette
-* Information about the nodes of OAR-docker's cluster, sent in a json format.
+'''Outputs'''  : Ordinateur, smartphone, tablette
-'''Source''':
-* OAR API
+'''Destination'''  : Tout public, orienté Etudiant (18-25) et salariés
-'''Outputs''':
-* A website
-'''Destination''':
+'''Action'''  :
-* Searchers' team
+'''Exigences fonctionnelles'''  :
-'''Action''':
+* Tâches prioritaires
-* Create or delete nodes
+** Gestion d'une session sécurisée
-* Affect or suppress jobs
+** Acteur client : Effectuer une commande
+** Acteur client : Gérer son panier
+** Acteur artisan : Gérer son catalogue
+* Tâches secondaires
-'''Non functional requirements''':
+** Acteur client : Effectuer un appel d'offre
-* Easily usable: no user experience required
+** Acteur artisan : Répondre à un appel d'offre
-* Small: does only need a few mega octets of space
-* Safe: specific users can do specific actions
-* Ethic: free-software used
+'''Exigences non fonctionnelles'''  :
-'''Pre-condition''':
+* [https://fr.wikipedia.org/wiki/Propri%C3%A9t%C3%A9s_ACID Propriétés ACID] sur les transactions (en particulier le paiement)
+* Interface user-friendly, selon [http://www.ergolab.net/articles/criteres-ergonomiques-1.php Les critères ergonomiques de Bastien & Scapin]
+* Gestion fine de l'utilisation de HTTPS
+* Résistance du système à la montée en charge (Temps de service constant)
+* Réduire au minimum le parcours de paiement
+* Portabilité (responsive design) PC, mobiles.
+'''Risques'''  :
-*Software:
+* Indisponibilité du service
-::- OAR-docker
+* Faille dans la sécurité (données utilisateurs sensibles)
-'''Post-condition''':
+'''Qualité'''  :
-'''Side-effects''':
+'''Pré-condition'''  :
+* Disposer d'un appareil compatible (ordinateur,smartphone,tablette)
+* Disposer d'un accès Internet
+'''Post-condition'''  :
-=4. Product evolution=
+* Réception de la commande
-This webUI just use a part of what OAR-API can do, so it could be improved. Moreover, as OAR-docker is still in development, new functionalities can be added.
+=Évolutions du produit =
-=5. Appendices=
-This document is inspired of the IEEE/ANSI 830-1998 Standard.
+* Accroître la compatibilité de notre service avec différents moyens de paiement (Paypal, Izly...)
-'''References:'''
+* Accroître notre base de restaurateurs proposant des plats
-* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
+* Développer un partenariat avec un service de livraison
-* 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]

Difference between revisions of "SRS ECOM 2015 GRP5"