Backlog

Liste des utilisateurs

[La descriptions des différents types d'utilisateurs de l'application, par exemple :]

• Administrateur : Les 4 étudiants du groupe auront l'accès en tant qu'admin. Etant donné que le client est développeur, il aura également accès au compte administrateur.

• Client connecté : Les clients pourront passer des commandes mais pour l'instant, ne pourront pas vendre leurs produits sur le site.

User Stories

[Toutes les User Stories utiles pour réaliser l'application. Elles doivent être nommées comme demandées et TRIEES PAR ORDRE DE PRIORITE, chacune avec un code/numéro unique. Les plus prioritaire doivent être bien décrites comme demandée. ATTENTION : si vous désirez décrire, voire même encoder les user story ailleurs dans un outil par exemple, il faut mettre ici le lien pour y accéder.]

[Pour les US persos : Indiquer le nom de l'étudiant responsable]

1. En tant que [Administrateur], je souhaite [Créer un article] afin que [Les clients puissent voir et potentiellement acheter ce produit] [Thibault Delime]
2. En tant que [Client], je souhaite [Ajouter un article dans mon panier] afin de [Passer commande] (https://github.com/LoicDeroWastaken/Ecommerce/wiki/US-personelles) [Loic Dero]
3. En tant que [utilisateur], je souhaite [action] afin de [objectif / valeur obtenue]
4. ...

[Pour rappel :

• La page "Analyse des besoins" du wiki reprend la liste des User Stories, sous forme "en tant que …, je souhaite… afin de…
• Chaque titre d'US est associée à un lien vers sa description complète (sur le wiki ou le gestionnaire de tâches)
• Le nom de l'auteur de l'US est clairement indiqué dans le backlog
• Les US sont estimées en terme de valeur pour le client.
• Les US sont numérotées et prioritisées dans le backlog. Il faut pouvoir voir toutes les US dans une liste ordonnées.
• Les US contienne un titre de forme : "en tant que …"
• Un nombre significatif d'US parmi les plus prioritaires possèdent une description complète.
• Une US analysée comporte : un nom correct, une description textuelle claire et complète accompagnée de maquettes, les critères d'acceptation ( ainsi - qu'une découpe en tâche technique avant de l'implémenter).
• L'apparence de l'interface utilisateur de la US est précisée : emplacement/navigation, layout, maquettes, …
• Les dépendances techniques de la US sont précisées : prérequis, endpoints API, tables de la DB, librairies utilisées, …
• Les US sont estimées en terme de complexité (par exemple, durée estimée en heure)
• Les US sont bien découpées. (Une US devrait porter sur un ajout fonctionnel utile au client. Idéalement une US devrait pouvoir être implémentée en une journée.) ]