Artefact :
|
![]() |
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 : |
Les personnes suivantes sont amenées à utiliser les storyboards :
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).
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.
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.
Le rôle Analyste système est responsable de l'intégrité du storyboard et doit s'assurer que :
Pour plus d'informations sur le développement de storyboards, voir Principes et conseils : Storyboard.
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)
|