Modélisation des besoins des utilisateurs

Article
06/10/2015

Microsoft Visual Studio Ultimate vous permet de mieux comprendre, d'évoquer et de communiquer les besoins de vos utilisateurs en dessinant des diagrammes sur leurs activités et le rôle que joue votre système dans l'atteinte de leurs objectifs. Un modèle d'impératifs correspond à un ensemble de diagrammes de ce type, dont chacun se concentre sur un aspect différent des besoins des utilisateurs.

Pour une démonstration vidéo, consultez Modeling the Business Domain.

Un modèle d'impératifs vous permet :

de vous concentrer sur le comportement externe du système, indépendamment de sa conception interne ;
de décrire les besoins des utilisateurs et des parties prenantes avec bien moins d'ambiguïté que vous ne pouvez le faire en langage naturel ;
de définir un glossaire cohérent de termes utilisable par les utilisateurs, les développeurs et les testeurs ;
de réduire les écarts et les incohérences dans les impératifs ;
de réduire le travail nécessaire à la réponse aux modifications d'impératifs ;
de planifier l'ordre dans lequel les fonctionnalités seront développées ;
d'utiliser les modèles comme base pour les tests système, créant ainsi une relation claire entre les tests et les impératifs. Lorsque les impératifs sont modifiés, cette relation vous permet de mettre à jour les tests correctement. Cela permet également de vérifier que le système est conforme aux nouveaux impératifs.

Un modèle d'impératifs peut se montrer encore plus précieux si vous l'utilisez pour vous concentrer sur des discussions avec les utilisateurs ou leurs représentants, et que vous le revisitez au début de chaque itération. Il n'est pas nécessaire que vous l'exécutiez de manière détaillée avant d'écrire le code. Une application partiellement fonctionnelle, même si elle est extrêmement simplifiée, constitue généralement la base la plus stimulante en vue d'une discussion concernant les impératifs avec les utilisateurs. Le modèle est une manière efficace de résumer les résultats de ces discussions. Pour plus d'informations, consultez Utilisation de modèles dans le processus de développement.

Notes

Tout au long de ces rubriques, le terme « système » désigne le système ou l'application que vous développez.Il peut s'agir d'une grande collection comprenant de nombreux composants logiciels et matériels, une application unique ou encore un composant logiciel à l'intérieur d'un système plus grand.En tous les cas, le modèle d'impératifs décrit le comportement visible hors de votre système (que ce soit par le biais d'une interface utilisateur ou d'une API).

Tâches courantes

Vous pouvez créer plusieurs vues différentes des impératifs des utilisateurs. Chacune de ces vues fournit un type d'information particulier. Lorsque vous créez ces vues, il est préférable de passer fréquemment de l'une à l'autre. Vous pouvez démarrer à partir de n'importe quelle vue.

Diagramme ou document	Éléments décrits dans un modèle d'impératifs	Section
Diagramme de cas d'usage	Personnes qui utilisent le système et manière dont elles l'utilisent.	Description de l'utilisation de votre système
Diagramme de classes conceptuel	Glossaire des types utilisés pour décrire les impératifs ; types visibles au niveau de l'interface du système.	Définition des termes utilisés pour décrire des impératifs
Diagramme d'activités	Flux de travail et d'informations entre les activités exécutées par les utilisateurs et le système (ou ses composants).	Affichage du flux de travail entre les utilisateurs et votre système
Diagramme de séquence	Séquence d'interactions entre les utilisateurs et le système (ou ses composants). Autre vue du diagramme d'activités.	Affichage d'interactions entre les utilisateurs et votre système
Autres documents ou éléments de travail	Critères de performances, de sécurité, de facilité d'utilisation et de fiabilité.	Description des impératifs de qualité de service
Autres documents ou éléments de travail	Contraintes et règles non spécifiques à un cas d'usage particulier	Affichage des règles métier

Notez que la plupart des types de diagrammes peuvent être utilisés à d'autres fins. Pour obtenir une vue d'ensemble des types de diagrammes, consultez Développement de modèles pour la conception logicielle. Pour plus d'informations de base sur le dessin de diagrammes, consultez Modifier des modèles et des diagrammes UML.

Description de l'utilisation de votre système

Créez des diagrammes de cas d'usage pour décrire les personnes qui utilisent le système et la manière dont elles l'utilisent. Un cas d'usage correspond à l'objectif d'un utilisateur du système, ainsi qu'à la procédure exécutée pour atteindre l'objectif.

Par exemple, un système de vente de repas en ligne doit permettre aux clients de sélectionner des éléments dans un menu, et aux restaurants proposant ce service de mettre le menu à jour. Vous pouvez résumer tout cela dans un diagramme de cas d'usage :

Cas d'usage pour le Client et le Restaurant

Vous pouvez également décrire la manière dont un cas d'usage se compose de plus petits cas. Par exemple, la commande d'un repas fait partie de l'achat d'un repas, lequel inclut également le paiement et la livraison :

Le Système intervient dans le paiement mais pas dans la livraison.

Vous pouvez également spécifier les cas d'usage qui font partie de la portée du système que vous développez. Par exemple, le système illustré ici ne fait pas partie du cas d'usage Livrer le repas. Cela permet de définir l'environnement de travail de développement. (Dans un diagramme de cas d'usage, des conteneurs de sous-systèmes peuvent être utilisés pour représenter le système ou ses composants.)

Cela permet également à votre équipe d'évoquer les éléments qui seront inclus lors des versions successives. Par exemple, vous pouvez déterminer si, dans la version initiale du système, Payer le repas fait l'objet d'un accord direct entre le restaurant et le client, plutôt que de passer par le système. Dans ce cas, vous pouvez déplacer Payer le repas hors du rectangle du système DinnerNow pour la version initiale.

Un diagramme de cas d'usage ne fournit qu'un résumé des cas d'usage. Pour fournir des descriptions plus détaillées, vous pouvez lier les cas d'usage du diagramme à des documents distincts ou encore à d'autres diagrammes. Pour savoir comment procéder, consultez Comment : lier un cas d'usage à des documents et diagrammes.

Le dessin d'un diagramme de cas d'usage permet à votre équipe :

de se concentrer sur les attentes des utilisateurs concernant le système, sans être distraite par des détails de l'implémentation ;
d'évoquer la portée de votre système ou de ses versions particulières.

Les rubriques suivantes contiennent plus d'informations :

Pour en savoir plus sur	Lecture
Informations plus détaillées concernant la création des cas d'usage	Diagrammes de cas d'usage UML : indications
Éléments d'un diagramme de cas d'usage	Diagrammes de cas d'usage UML : référence
Développement de code à partir de cas d'usage	Modélisation de l'architecture d'un système logiciel

Définition des termes utilisés pour décrire des impératifs

Vous pouvez utiliser des diagrammes de classes UML pour développer une terminologie cohérente des concepts métier utilisés aux fins suivantes :

Par les utilisateurs eux-mêmes, pour évoquer le secteur d'activité dans lequel le système est utilisé.
Pour décrire les besoins des utilisateurs (par exemple, dans les descriptions de cas d'usage, de règles métier et de récits utilisateur).
Types d'informations échangées au niveau de l'API du système ou par le biais de l'interface utilisateur.
Descriptions de tests système ou d'acceptation.

Lorsqu'ils sont utilisés à cette fin, le contenu d'un diagramme de classes UML est appelé « diagramme de classes conceptuelles ». (Ce contenu est également appelé modèle de domaine ou modèle de classe d'analyse.)

Dans un diagramme de classes conceptuel, seules sont affichées celles nécessaires dans les descriptions des impératifs, et non les détails de la conception interne du système. En effet, le diagramme n'affiche aucun détail de la conception interne du système. En général, vous n'êtes pas appelé à afficher d'opération ni d'interface dans des classes conceptuelles.

Par exemple, vous pouvez dessiner ces classes conceptuelles pour le système DinnerNow :

Menu Classes, Commande, Élément de menu, Commander un élément.

Un diagramme de classes conceptuelles fournit la terminologie que vous utilisez dans le modèle d'impératifs. Par exemple, dans la description détaillée du cas d'usage Commander un repas, vous pouvez écrire :

Le client sélectionne un Menu à partir duquel il établit une Commande, puis crée des Éléments commandés dans la Commande en sélectionnant des Éléments de menu dans le Menu.

Notez que les termes utilisés dans cette description correspondent aux noms des classes du modèle. Le diagramme supprime les ambiguïtés des relations entre ces classes. Par exemple, il montre clairement que chaque Commande est associée à un seul Menu.

Les malentendus concernant les impératifs des utilisateurs correspondent fréquemment à ceux relatifs aux explications détaillées de termes. Par exemple, la plupart des restaurants partagent la même conception des termes Menu et Commande, mais la différence entre l'élément d'une Commande et l'élément d'un Menu est moins évidente. Il est important d'aborder ces différences lors de l'évocation des impératifs avec les parties prenantes professionnelles. Le diagramme de classes est un outil particulièrement utile qui vous permet de clarifier les termes et leurs relations.

Le modèle de classes conceptuelles peut constituer la terminologie de base grâce à laquelle la logique métier de votre système peut être décrite. Cependant, les classes du logiciel sont généralement bien plus complexes que le modèle conceptuel, car votre implémentation doit tenir compte de problèmes liés aux performances, à la distribution, à la souplesse, ainsi qu'à d'autres facteurs. Plusieurs implémentations différentes d'une classe conceptuelle sont fréquemment détectées sur un système.

Par exemple, Commandes peut être représenté en XML, SQL, HTML et C# dans différentes parties du système et dans différentes interfaces entre les parties. L'association entre une Commande et un Menu peut être représentée de nombreuses manières, comme des références au sein du code C#, des relations dans une base de données ou encore des ID faisant l'objet de références croisées dans XML. Cependant, en dépit de ces variations, le modèle conceptuel fournit d'importantes informations qui se vérifient dans toutes les parties du logiciel. Le diagramme de classes de notre exemple indique que toutes les implémentations ne comprendront qu'un Menu associé à chaque Commande.

Le dessin d'un diagramme de classes d'impératifs permet à votre équipe :

de définir et normaliser les termes de base utilisés lors de l'évocation des besoins des utilisateurs ;
de clarifier les relations entre ces différents termes.

Les rubriques suivantes contiennent plus d'informations :

Pour en savoir plus sur	Lecture
Informations plus détaillées concernant la recherche de classes d'impératifs	Diagrammes de classes UML : indications
Éléments d'un diagramme de classes conceptuelles	Diagrammes de classes UML : référence
Développement de code à partir de classes conceptuelles	Modélisation de l'architecture d'un système logiciel

En général, dans un diagramme de classes conceptuel, il n'est pas utile de définir des flèches sur les associations pour représenter la navigabilité. En effet, le diagramme ne représente pas une implémentation. Les associations représentent des relations entre les objets réels. L'extension Visual Studio suivante définit des flèches non directionnelles par défaut :Exemple : fonctionnalités de modélisation de domaine UML (page éventuellement en anglais).

Affichage des règles métier

Une règle métier est un impératif non associé à un cas d'usage particulier et qui doit être observé sur l'ensemble du système.

De nombreuses règles métier constituent des contraintes pesant sur les relations des classes conceptuelles. Vous pouvez écrire ces règles métier statiques sous la forme de commentaires associés aux classes pertinentes d'un diagramme de classes conceptuelles. Par exemple :

Règle dans le commentaire associé à la classe Order.

Quant à elles, les règles métier dynamiques exercent une contrainte sur les séquences d'événements autorisées. Par exemple, vous utilisez un diagramme de séquence ou d'activités pour montrer qu'un utilisateur doit se connecter avant d'exécuter d'autres opérations sur votre système.

Cependant, de nombreuses règles dynamiques peuvent être énoncées à la fois plus efficacement et plus génériquement si vous les remplacez par des règles statiques. Par exemple, vous pouvez ajouter un attribut booléen 'Connecté' à une classe du modèle de classes conceptuelles. Vous ajoutez Connecté en tant que post-condition de l'enregistrement dans le cas d'usage et en tant que condition préalable de la plupart des autres cas d'usage. Cette approche vous permet d'éviter de définir toutes les combinaisons de séquences d'événements possibles. Elle s'avère également plus souple lorsque vous devez ajouter de nouveaux cas d'usage au modèle.

Notez que, dans ce cas, le choix concerne la manière dont vous définissez les impératifs et qu'il est indépendant de celle dont vous implémentez les impératifs dans le code de programme.

Les rubriques suivantes contiennent plus d'informations :

Pour en savoir plus sur	Lecture
Informations plus détaillées concernant la recherche et l'enregistrement de règles métier statiques	Diagrammes de classes UML : indications
Éléments d'un diagramme de classes conceptuelles	Diagrammes de classes UML : référence
Développement de code qui respecte les règles métier	Modélisation de l'architecture d'un système logiciel

Description des impératifs de qualité de service

Il existe plusieurs catégories d'impératifs de qualité de service. Ces catégories sont les suivantes :

Performances
Sécurité
Facilité d'utilisation
Fiabilité
Robustesse

Vous pouvez inclure certains de ces impératifs aux descriptions de cas d'usage spécifiques. D'autres impératifs ne sont pas spécifiques à des cas d'usage et sont écrits plus efficacement dans un document séparé. Lorsque cela est possible, il est particulièrement utile de respecter la terminologie définie par le modèle d'impératifs. Dans l'exemple suivant, notez que les principaux termes utilisés dans l'impératif sont les titres des acteurs, des cas d'usage et des classes des illustrations précédentes :

Si un Restaurant supprime un Élément de menu alors qu'un Client commande un repas, toute Commande d'un élément qui se réfère à cet Élément de menu s'affiche en rouge.

Les rubriques suivantes contiennent plus d'informations :

Pour en savoir plus sur	Lecture
Informations plus détaillées concernant l'enregistrement des impératifs de qualité de service	Guidelines for Defining Quality of Service Requirements
Ajout d'autres documents à des cas d'usage	Comment : lier un cas d'usage à des documents et diagrammes
Développement de code qui respecte les impératifs de qualité de service	Modélisation de l'architecture d'un système logiciel

Affichage du flux de travail entre les utilisateurs et votre système

Vous pouvez utiliser un diagramme d'activités pour afficher le flux de travail entre différents cas d'usage. Il est souvent utile de commencer avec un modèle d'impératifs en dessinant un diagramme d'activités affichant les principales tâches qu'exécutent les utilisateurs (que ce soit dans ou hors du système).

Par exemple :

Activité avec trois actions et une boucle.

Vous pouvez dessiner des diagrammes de cas d'usage et des diagrammes d'activités pour afficher différentes vues des mêmes informations. Le diagramme de cas d'usage est plus efficace lorsqu'il s'agit d'afficher l'imbrication des plus petites actions avec les activités les plus importantes. Cependant, il n'affiche pas le flux de travail. Par exemple :

Cas d'usage pour les actions précédentes

Notez que vous pouvez également utiliser des diagrammes d'activités pour représenter les algorithmes de votre logiciel mais que, lorsque vous utilisez les diagrammes du processus d'entreprise, vous vous concentrez sur les actions visibles hors du système.

Les rubriques suivantes contiennent plus d'informations :

Pour en savoir plus sur	Lecture
Plus d'informations concernant la définition des flux de travail métier	Diagrammes d'activités UML : instructions
Éléments d'un diagramme d'activités	Diagrammes d'activités UML : référence
Développement de code à partir de diagrammes d'activité	Modélisation de l'architecture d'un système logiciel

Affichage d'interactions entre les utilisateurs et votre système

Vous pouvez utiliser un diagramme de séquence pour afficher l'échange de messages entre votre système et les acteurs externes, ou encore entre différentes parties de votre système. Vous obtiendrez ainsi une vue des étapes d'un cas d'usage qui affiche très clairement la séquence d'interactions. Les diagrammes de séquence se révèlent particulièrement utiles lorsque vous êtes en présence de plusieurs parties interactives dans un cas d'usage, ou encore lorsque votre système dispose d'une API.

Par exemple :

Diagramme de séquence avec le Système et les acteurs.

Les diagrammes de séquence permettent de voir facilement les messages qui entrent dans le système que vous développez. Pour concevoir le système, vous pouvez remplacer l'unique ligne de vie du système par une autre ligne de vie pour chacun de ses composants, puis afficher leurs interactions en réponse à chaque message entrant.

Les rubriques suivantes contiennent plus d'informations :

Pour en savoir plus sur	Lecture
Plus d'informations concernant la définition des interactions	Diagrammes de séquence UML : indications
Éléments d'un diagramme de séquence	Diagrammes de séquence UML : référence
Développement de code à partir de diagrammes de séquence	Modélisation de l'architecture d'un système logiciel

Utilisation d'un modèle permettant de réduire les incohérences

La création d'un modèle donne généralement lieu à une réduction considérable des incohérences et des ambiguïtés dans les impératifs des utilisateurs. Il arrive souvent que différentes parties prenantes aient chacune leur propre conception du métier dans lequel le système est utilisé. Par conséquent, votre première tâche doit consister à éliminer ces différences entre vos clients.

Comme vous pourrez le constater, de nombreuses questions concernant le secteur d'activités émergent naturellement lorsque vous créez un modèle. Le simple fait de poser ces questions à vos utilisateurs vous permet de réduire la nécessité d'apporter des modifications plus tard dans le projet. Voici quelques questions spécifiques que vous pouvez d'abord vous poser à vous-même avant de les soumettre aux parties prenantes métier, si la réponse obtenue manque de clarté :

Pour chaque classe dans le modèle d'impératifs, demandez « Quel cas d'usage crée des instances de cette classe ? ». Par exemple, dans le cadre d'un service en ligne de commande de repas, vous pouvez poser la question suivante : « Quel cas d'usage crée des instances de la classe Menu de restaurant ? ». Cela permettrait de déboucher sur une discussion sur l'inscription d'un nouveau restaurant au service et sur l'élaboration de son menu. Vous pouvez poser des questions similaires sur les éléments qui créent ou modifient les attributs et les associations.
Pour chaque cas d'usage du modèle d'impératifs, tentez de décrire le résultat (ou post-condition) de chaque cas d'usage à l'aide des termes fournis par les diagrammes de classes. Il est souvent utile d'afficher l'effet d'un cas d'usage en dessinant des instances des classes avant et après une occurrence du cas d'usage. Par exemple, si la post-condition d'un cas d'usage indique qu'un élément de menu est ajouté à la commande du client, dessinez les instances des classes Commande et Élément de menu. Affichez les effets du cas d'usage, tel qu'un nouveau lien ou un nouvel objet, dans une autre couleur ou dans un nouveau dessin. Cela conduit fréquemment à des discussions permettant de déterminer les informations nécessaires dans le modèle. Bien que les classes d'impératifs ne soient pas directement concernées par l'implémentation, elles décrivent les informations que votre système devra stocker et transmettre.
Renseignez-vous sur les contraintes concernant les attributs et associations, et notamment sur celles qui en impliquent plusieurs.
Posez également des questions sur des séquences de cas d'usage valides et non valides, en dessinant des diagrammes de séquence ou d'activités pour les illustrer.

En examinant les relations entre les vues que fournissent les différents diagrammes, vous pouvez rapidement comprendre les principaux concepts avec lesquels travaillent vos utilisateurs et les aider à comprendre ce qu'ils peuvent obtenir grâce au système. Vous comprenez également mieux les impératifs à propos desquels les parties prenantes sont le moins certaines. Vous pouvez envisager de développer ces fonctionnalités, au moins dans la forme simplifiée, lors de l'une des premières étapes du projet, pour permettre aux utilisateurs de les exploiter.