Un storyboard représente une description logique et conceptuelle de la fonctionnalité du système pour un scénario spécifique, y compris de l'interaction requise entre le système et ses utilisateurs. Un storyboard "raconte une histoire spécifique". 
Rôle :  Analyste système 
Caractère facultatif/Occurrence:  Facultatif. Produit au début de la phase d'élaboration, lors de l'énoncé des exigences.
Modèles et rapports : 
     
Exemples : 
     
Représentation UML :  Sans objet.
Informations supplémentaires :   
Entrée d'activités :    Sortie d'activités :   

Objet Haut de la page

Les personnes suivantes sont amenées à utiliser les storyboards :

  • Les analystes système, pour explorer, clarifier et répertorier les interactions en termes de comportement envisagées par l'utilisateur dans le cadre de l'énoncé des exigences.
  • Les concepteurs de l'interface utilisateur, pour concevoir cette interface et en construire un prototype.
  • les concepteurs des classes qui assurent la fonctionnalité de l'interface utilisateur. Ils exploitent cette information pour comprendre les interactions du système avec l'utilisateur afin de concevoir les classes adéquates qui implémenteront l'interface utilisateur.
  • Les intervenants chargés de concevoir la prochaine version du système, pour déterminer comment le système exécute le flux d'événements.
  • Les personnes qui testent les fonctions du système.
  • Le responsable, pour la planification et le suivi des tâches d'analyse et de conception.

Un storyboard peut être défini pour chaque cas d'utilisation, permettant ainsi une approche de l'ingénierie logicielle orientée cas d'utilisation et offrant une excellente méthode pour valider les attentes de l'utilisateur (acteur) vis à vis de ces cas d'utilisation et de leur rôle dans le flux d'événements.

Gardez présent à l'esprit que l'objet principal des storyboards est la compréhension du flux global et des interactions, et non pas de créer un prototype ou de tester l'apparence de l'interface utilisateur (cette mission est dévolue au Prototype de l'interface utilisateur). Le storyboard ne doit pas couvrir les outils graphiques de l'interface utilisateur, ni les autres questions touchant à cette interface (ces aspects doivent être abordés par le prototype de l'interface utilisateur).

Propriétés Haut de la page

Les storyboards peuvent être rendus à l'aide de représentations visuelles ou textuelles, ou d'une combinaison des deux. Pour des exemples spécifiques, voir Principes et conseils : Storyboard.

Calendrier Haut de la page

Les storyboards sont produits au début de la phase d'élaboration, lors de l'énoncé des exigences.

Ils sont générés dès que les flux qu'ils viennent décrire sont prêts à être envisagés depuis une perspective d'utilisabilité. Ils peuvent être produits en même temps que d'autres artefacts d'exigences, ou ultérieurement.

Responsabilité Haut de la page

Le rôle Analyste système est responsable de l'intégrité du storyboard et doit s'assurer que :

  • Le storyboard est intelligible et adapté à son objectif.
  • Le storyboard décrit correctement le comportement prévu du système.
  • Les exigences d'utilisabilité associées sont intelligibles et adaptées à leur objectif et représentent bien celles du système.

Pour plus d'informations sur le développement de storyboards, voir Principes et conseils : Storyboard.

Personnalisation Haut de la page

Déterminez quels storyboards seront utiles pour votre projet.  Leur contenu doit être personnalisé pour s'adapter aux besoins du projet.  Vous pouvez n'avoir à développer qu'un sous-ensemble de propriétés, et à personnaliser le niveau de formalité régissant la création et la gestion de ces propriétés. 

Les storyboards sont souvent considérés comme des artefacts éphémères, dont la maintenance est abandonnée une fois que les exigences de comportement sont comprises et que le prototypage et l'implémentation de l'interface utilisateur suit son train. Toutefois, il peut être salutaire, dans certaines circonstances, d'assurer leur maintenance à travers plusieurs itérations, par exemple lorsque l'interface utilisateur est confrontée à des exigences complexes longues à être comprises (plusieurs itérations). De plus, les storyboards, couplés avec l'interface utilisateur concrète, représentent un apport utile pour la documentation destinée à l'utilisateur final .



RUP (Rational Unified Process)   2003.06.15