Voici un exemple de scénario que votre application doit supporter :

Nous voulons mettre en place de nouveaux écrans sur les sites de l'IUT Fabron et Sophia. Des administrateurs site déclarent

• les deux sites,
• les populations attendues sur ces sites (milieu universitaire, population hétérogène), internationale, handicaps à prendre en charge
• puis précisons les écrans que nous envisageons :
  • Pour Fabron un très grand écran à l'entrée (dimensions) en précisant la sous-population
  • un écran en salle des profs de taille moyenne,
  • un écran à tous les étages.

Un ensemble de sources d'information sont sélectionnées (Twitter, Flux RSS de l'université, GPU, …). Certaines doivent être présentes sur tous les écrans (Alertes par exemple). D'autres sont présentes sur tous les écrans à destination des étudiants mais pas pour le grand publique (edt).

Une charte graphique est également choisie pour l'ensemble des écrans.

A partir de votre outil, nous devons pouvoir également déployer un système de diffusion d'informations au centre hospitalier Pasteur, sur le campus de Jussieu, etc.

L'administrateur du site décide de modifier son ancienne configuration pour ajouter un nouvel écran et modifier la charte graphique associée aux écrans.

Lorsque le site a été modélisé par l'administrateur de site, les administrateurs d'écran peuvent configurer les écrans qui leur sont affectés.

Pour chaque écran ou groupe d'écrans, l'administrateur d'écran décide de :

• Quelles sont les sources d'informations diffusées ?
• Durée d'affichage des écrans s'il y a lieu (de 7h45 à 19h30, par exemple)
• Les temps de diffusion de certaines informations (de 12h à 12h30, etc. les infos TV5, les vidéos de soirées, les albums photos…)
• La manière de visualiser une source d'information : la zone d'affichage (centrale ou scrolling en bas de l'écran par exemple), la manière de les afficher (une photo à la fois ou une mosaïque de photos), …

Il peut visualiser sa sélection à partir d'un jeu standard de données.

Une fois tous les écrans configurés et validés par l'administrateur du site, celui-ci déploie le site. Il obtient alors un ensemble d'archives qui seront déployées par les responsables système : des serveurs, des clients, … Le travail de déploiement par les responsables systèmes n'est pas pris en charge par votre application.

Une fois tous les écrans déployés, les administrateurs du site et les responsables systèmes peuvent visualiser l'ensemble des écrans, la charge des serveurs, les remontées d'erreurs, …. Ils peuvent également modifier les droits des utilisateurs par exemple en affectant de nouveaux administrateurs d'écrans, d'information, de site, affecter les écrans aux administrateurs d'écran, …

Il doit être possible aux différents intervenants autour des écrans d'émettre des demandes qui seront prises en charge soit par les administrateurs de site, soit stockées pour interventions ultérieures.

Un FAQ contient l'ensemble des demandes mémorisées et des réponses obtenues classées par types d'intervenants. In intervenant saisit une demande après s'être identifié. Toute demande est “automatiquement” parsée et si des demandes contenant les mêmes termes sont détectées, elles lui sont proposées. Il peut alors choisir ou non d'enregistrer sa demande comme une nouvelle demande. D'autres intervenants peuvent répondre à la demande.

Un administrateur de site peut faire une demande relative à la construction d'un site ou à l'administration d'un site. A ce type de demande, seuls des administrateurs de site de la communauté peuvent répondre. exemple : Comment modifier les droits d'un administrateur d'écran pour une durée limitée? Existe-t-il un moyen de connecter GPU à un système de diffusion d'information?

Un administrateur d'écran peut poster soit une demande soit une suggestion relative à la configuration d'un écran donné. Dans ce dernier cas, seuls les administrateurs du site répondent ou mémorisent la suggestion.