Cahier des charges d’un site Web pour une communauté partageant un inventaire d’objets

Ce document présente les spécifications du projet.

Nous vous indiquons les attendus, mais précisons aussi ce qui est contre-indiqué.

Ce cadrage laisse une certaine liberté dans la réalisation, sans pour autant vous faire prendre le risque de développements trop complexes ou trop longs. Le but est de rester dans le nombre d’heures affiché au début du module.

Essayez de coller aux entités du modèle de données décrites dans ce cahier des charges, sans en ajouter. Dans le doute, consultez les encadrants.

L’application fait fonctionner un site Web destiné à une communauté thématique de personnes souhaitant partager en ligne (et potentiellement aussi dans le monde physique), un ensemble d’[objets] en leur possession.

Différents utilisateurs, membres de cette communauté, utilisent simultanément cette même application, qui est hébergée sur le Web. Une même instance de l’application conserve les données de tous les membres.

Le site permet de gérer pour soi-même un [inventaire] d’[objets], et de rendre visible, sous forme de [galerie], une partie de ces [objets], qui devient donc accessible aux autres membres.

Les caractéristiques des [objets] contenus dans cet [inventaire] sont particulières, spécifiques au domaine thématique choisi (une guitare ne se décrit pas forcément de la même façon qu’une carte Pokemon).

Le site Web permet de rédiger des fiches détaillées pour les [objets] des membres, et de de consulter les fiches publiées par d’autres membres de la communauté.

Cela permet à la fois de gérer deux types d’informations :

• privées, réservées au membre qui se connecte à son tableau de bord :
  • les fiches de tous les [objets] de ses [inventaires] sont non-publiques;
  • elles sont accessibles au membre depuis partout sur Internet, quel que soit l’ordiphone ou l’ordinateur qu’iel utilise, à tout moment;
• publiques, partagées avec les autres membres de la communauté, pour commenter, échanger, partager (ou vendre, qui sait…)… mais tout ceci en dehors de l’application, pour simplifier l’ampleur des réalisations.

Par communauté, on entend l’ensemble des participants membres du même site (membres d’une association, qui paye pour l’hébergement de l’application sur un serveur, par exemple).

Pour simplifier, on ne gère pas des fonctions de type « réseau social » (liste d’amis, profil à réputation, etc.).

L’application est organisée en plusieurs ensembles de pages Web :

• une section « front-office » contenant :
  • les pages d’accueil destinées au grand public (visibles même si on n’est pas membre du site):
    • affichent des informations générales : les objectifs du site, son fonctionnement, une rubrique « Actualités » (nouveautés) et un lien contact pour joindre l’administrateur. Vous pouvez ajouter toute autre information que vous jugez utile (pas besoin d’un réalisme total).
    • permettent aux membres de se connecter à l’application (authentification avec un login et un mot de passe)
  • le cœur du site accessible aux membres de la « communauté », une fois connectés, permettant d’utiliser la plupart des fonctionnalités :
    • consultation des fiches d’[objet] publiées par les autres membres dans leurs [galeries], etc.;
    • un tableau de bord « Mon compte » permettant aux membres d’accéder à la gestion de l’ensemble de leur [inventaire] personnel, notamment les fiches d’[objet] qu’ils n’ont pas encore rendues publiques.

• une section « back-office » (optionnelle), accessible après authentification, uniquement pour les administrateurs du site. Les administrateurs sont des membres de la communauté particuliers (par exemple quelques membres de l’association délégués par le bureau)

  Sur une vraie application, ce back-office permettrait de gérer les inscriptions/adhésions des membres de la communauté, radiations, etc. Elle permettrait aux administrateursde résoudre des problèmes, assister les membres, gérer les conflits et autres demandes particulières (fermeture de compte, récupération, enquêtes judiciaires, etc.).

  Pour simplifier la réalisation (optionnelle), on se limite à une version « minimaliste » de cette section back-office, sous forme d’un habillage Web de la base de données, fait avec l’utilitaire EasyAdmin pour Symfony.

Vous pouvez ajouter tous les éléments nécessaires pour faire fonctionner le site au mieux, et de façon classique par rapport à la gestion d’un tel site Web… à condition de rester dans la mesure du temps imparti.

Le site Web de l’application doit :

• distinguer les visiteurs anonymes (passionnés d’[objet] intéressés pour rejoindre la communauté) et les membres authentifiés;
• disposer d’un accès privilégié pour l’administration du site. Les administrateurs sont des membres de la communauté ayant une vision supplémentaire de l’application : le back-office.

Voici les contraintes et les attentes pour le modèle de données de l’application.

Attention à respecter les contraintes méthodologiques ci-dessous.

L’objectif du projet est de valider les apprentissages avec un temps de travail limité, et pas d’en faire un site déployable pour une utilisation réelle.

Si certaines ou certains souhaitent aller au-delà, ils sont évidamment libres de le faire, sur leur temps libre, mais n’auront pas un bonus pour la quantité de travail additionnelle.

Attention à la complexité de réalisation, et au temps passé en codage et mise au point, qu’il est difficile d’estimer lors d’un premier projet avec un framework encore méconnu. Il est préférable de rester dans le cadre pédagogique que nous avons décrit, pour connaître votre « productivité ». Dans un deuxième projet (après ce module), vous pourrez mieux estimer la faisabilité, le temps et l’effort requis, et vous lancer dans des projets ambitieux.

Bon courage pour la réalisation.