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 mais ne l'utilisera seulement lorsqu'il aura besoin d'accéder au management du site.

• Vendeur : Personne pouvant mettre en vente des produits.

• 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. Lien pour y accéder.]

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

1. En tant que vendeur, je souhaite ajouter un article à la vente afin que les clients puissent voir et potentiellement acheter ce produit. Lien [Thibault Delime]
2. En tant que Client, je souhaite Ajouter un article dans mon panier afin de Passer commande Lien [Loïc 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.) ]