Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de changer d’annuaire.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer d’annuaire.
Visual Studio vous aide à comprendre, discuter et communiquer les besoins de vos utilisateurs en dessinant des diagrammes sur leurs activités et la partie que votre système joue pour les aider à atteindre leurs objectifs. Un modèle de configuration requise est un ensemble de ces diagrammes, dont chacun se concentre sur un aspect différent des besoins des utilisateurs.
Pour voir quelles versions de Visual Studio prennent en charge chaque type de modèle, consultez La prise en charge des versions pour les outils d’architecture et de modélisation.
Un modèle de exigences vous aide à :
Concentrez-vous sur le comportement externe du système, séparément de sa conception interne.
Décrivez les besoins des utilisateurs et des parties prenantes avec beaucoup moins d’ambiguïté que vous pouvez en langage naturel.
Définissez un glossaire cohérent des termes qui peuvent être utilisés par les utilisateurs, les développeurs et les testeurs.
Réduisez les lacunes et les incohérences dans les exigences.
Réduisez le travail nécessaire pour répondre aux modifications requises.
Planifiez l’ordre dans lequel les fonctionnalités seront développées.
Utilisez les modèles comme base pour les tests système, ce qui établit une relation claire entre les tests et les exigences. Lorsque les exigences changent, cette relation vous aide à mettre à jour les tests correctement. Cela permet de s’assurer que le système répond aux nouvelles exigences.
Un modèle de configuration requise offre un plus grand avantage si vous l’utilisez pour concentrer les discussions avec les utilisateurs ou leurs représentants, et le revoir au début de chaque itération. Vous n’avez pas à le terminer en détail avant d’écrire du code. Une application partiellement fonctionnelle, même si très simplifiée, constitue généralement la base la plus stimulante pour discuter des exigences avec les utilisateurs. Le modèle est un moyen efficace de résumer les résultats de ces discussions. Pour plus d’informations, consultez Utiliser des modèles dans votre processus de développement.
Note
Tout au long de ces rubriques, « système » signifie le système ou l’application que vous développez. Il peut s’agir d’une grande collection de nombreux composants logiciels et matériels ; ou une seule application ; ou un composant logiciel à l’intérieur d’un système plus grand. Dans tous les cas, le modèle de configuration requise décrit le comportement visible à partir de l’extérieur de votre système, qu’il s’agisse d’une interface utilisateur ou d’une API.
Tâches courantes
Vous pouvez créer plusieurs vues différentes des exigences des utilisateurs. Chaque vue fournit un type particulier d’informations. Lorsque vous créez ces vues, il est préférable de passer fréquemment d’un à l’autre. Vous pouvez commencer à partir de n’importe quelle vue.
| Diagramme ou document | Ce que décrit un modèle de exigences fonctionnelles | Section |
|---|---|---|
| Diagramme de classes conceptuelles | Glossaire des types utilisés pour décrire les exigences ; les types visibles à l’interface du système. | |
| Documents supplémentaires ou éléments de travail | Performances, sécurité, facilité d’utilisation et critères de fiabilité. | Description des exigences de qualité de service |
| Documents supplémentaires ou éléments de travail | Contraintes et règles non spécifiques à un cas d’usage particulier | Affichage des règles d’entreprise |
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 Créer des modèles pour votre application.
Affichage des règles d’entreprise
Une règle d’entreprise est une exigence qui n’est pas associée à un cas d’usage particulier et doit être observée dans tout le système.
De nombreuses règles métier sont des contraintes sur les relations entre les classes conceptuelles. Vous pouvez écrire ces règles métier statiques en tant que commentaires associés aux classes pertinentes sur un diagramme de classes conceptuelles. Par exemple:
Les règles d’entreprise dynamiques limitent les séquences autorisées d’événements. Par exemple, vous utilisez un diagramme de séquence ou d’activité pour montrer qu’un utilisateur doit se connecter avant d’effectuer d’autres opérations sur votre système.
Toutefois, de nombreuses règles dynamiques peuvent être plus efficacement et de façon plus générale remplacées par des règles statiques. Par exemple, vous pouvez ajouter un attribut booléen « Logged In » à une classe dans le modèle de classe conceptuelle. Vous devez ajouter "connecté" comme postcondition du cas d'usage de connexion et l'ajouter comme condition préalable de la plupart des autres cas d'usage. Cette approche vous permet d’éviter de définir toutes les combinaisons possibles de séquences d’événements. Il est également plus flexible lorsque vous devez ajouter de nouveaux cas d’usage au modèle.
Notez que le choix ici concerne la façon dont vous définissez les exigences et qu’il est indépendant de la façon dont vous implémentez les exigences dans le code du programme.
Les rubriques suivantes fournissent plus d’informations :
| Pour en savoir plus sur | Lire |
|---|---|
| Comment développer du code conforme aux règles d’entreprise | Modéliser l’architecture de votre application |
Description des exigences de qualité de service
Il existe plusieurs catégories d’exigence de qualité de service. Il s’agit notamment des facteurs suivants :
Performance
Security
Usability
Reliability
Robustesse
Vous pouvez inclure certaines de ces exigences dans les descriptions de cas d’usage particuliers. D’autres exigences ne sont pas spécifiques aux cas d’usage et sont les plus efficacement écrites dans un document distinct. Lorsque vous pouvez, il est utile d’adhérer au vocabulaire défini par le modèle d’exigences. Dans l’exemple suivant, notez que les mots principaux utilisés dans l’exigence sont les titres des acteurs, des cas d’usage et des classes dans les illustrations précédentes :
Si un restaurant supprime un élément de menu pendant qu’un client commande un repas, tout élément de commande qui fait référence à cet élément de menu s’affiche en rouge.
Consultez Modélisez l’architecture de votre application pour apprendre à développer du code conforme aux exigences de qualité de service.