Une exigence est ambiguë si elle a plus d’un sens. L’ambiguïté peut résulter d’un mauvais choix de mots et / ou des définitions différentes pour un mot ou une phrase.
Cohérente
Toutes les parties du cahier de charges doivent être cohérentes. Elles ne doivent pas se contredire les unes les autres.
Exemple de contradiction :
“Si vous supprimez une tâche toutes ses sous-tâches devrait être supprimé automatiquement” ;
“Vous devez toujours confirmer la suppression d’une tâche et de chacune de ses sous-tâches.
Modifiable
Les exigences devraient être structurées de telle sorte qu’il soit possible de les modifier à moindre coût. Ceci nécessite qu’elles soient structurées avec soin, par exemple, en séparant les exigences fonctionnelles des exigences non fonctionnelles, en fournissant un glossaire (une table de définitions),….
Traçable
Les exigences doivent être structurées de sorte qu’il soit possible de les identifier de manière unique.
Chacune doit avoir un numéro unique.
Cela permet d’y faire référence dans les tests finaux du logiciel fourni, et dans les discussions avec le client.
Evaluation
1. En considérant le cas des projets étudiants, proposés dans l’unité 0, effectuer les tâches suivantes:
2. Donner un aperçu et les objectifs du système que vous souhaitez développer 3. Énumérer les principaux besoins fonctionnels du système que vous souhaitez
développer.
4. Pour chaque exigence, fournir l’identificateur de l’exigence, la description et les références croisées.
Lister cinq exigences non fonctionnelles du système en utilisant le format spécifié.
Activité 3.2 - Cas d’utilisation Présentation
L’un des principaux objectifs de l’OO est de décomposer les exigences en concepts et en objets dans le domaine d’application et de produire un modèle conceptuel. Une technique importante pour aider à cette décomposition est de considérer les cas d’utilisation (description narrative des processus de domaine en termes d›interactions entre le système et ses utilisateurs).
Détails de l’activité
3.2.1 Concepts de cas d’utilisation
Un cas d’utilisation décrit la séquence des événements de certains types d›utilisateurs, appelés acteurs, en utilisant une partie de la fonctionnalité du système pour terminer un processus. Il est tout simplement une description d’un ensemble d’interactions entre un utilisateur et le système. En mettant en place un ensemble de cas d’utilisation, on peut décrire l’ensemble du système que nous prévoyons créer, d’une manière très claire et concise.
Par exemple, pour mener à bien le processus d’achat dans un magasin quand un Terminal de point de vente est utilisé :
• deux acteurs doivent être impliqués: le client et le caissier,
• la séquence d’événements suivante peut être réalisée:
• Le client arrive à une caisse avec les produits achetés,
• Le caissier enregistre la commande et le paiement,
• Enfin, le client quitte le magasin avec ses produits.
Par conséquent, pour un utilisateur, un cas d’utilisation est une façon d’utiliser le système. Un cas d’utilisation est décrit comme une séquence d’interactions entre des acteurs et le système par lequel le système fournit un service aux acteurs. Chaque cas d’utilisation décrit une partie des exigences fonctionnelles de certains utilisateurs. Tous les cas d’utilisation décrivent ensemble les exigences fonctionnelles globales du système.
La première étape du recueillement des besoins est d’assimiler les besoins aux cas
d’utilisation. Tous les cas d’utilisation permettent aux développeurs de logiciels et au client de se mettre d’accord sur les besoins, c’est-à-dire sur les conditions auxquelles le système doit se conformer. UML fournit une notation simple pour représenter un cas d’utilisation.
Acteurs
Un cas d’utilisation ne peut pas initier des actions de lui-même. Un acteur est une entité qui peut initier un cas d’utilisation. Un acteur représente un ensemble cohérent de rôles qui sont des entités externes au système pouvant utiliser le système, plutôt qu’une personne en particulier. Un acteur représente un type d’utilisateurs du système ou un système externe avec lequel le système interagit.
Unité 3: Analyse Orientée-Objet
Il est important de noter que :
• Un acteur stimule généralement le système avec des événements en entrée, et reçoit quelque chose en retour du système.
• Les acteurs communiquent avec le système en envoyant des messages et reçoivent des messages à partir du système tel que décrit dans les cas d›utilisation.
• Les acteurs représentent tout ce qui a besoin d’interagir avec le système pour un échange d’information: utilisateurs humains, systèmes informatiques, électriques ou dispositifs mécaniques tels que des minuteries.
• Un utilisateur physique peut représenter un ou plusieurs acteurs dans leur interaction avec le système et plusieurs utilisateurs individuels peuvent agir en tant que différentes occurrences d’un même acteur.
• S’il y a plus d’un acteur dans un cas d’utilisation, celui qui génère l’action de départ est appelé l’acteur initiateur et les autres sont des acteurs participants.
• Les acteurs qui interagissent directement avec le système sont des acteurs primaires / directs, les autres sont appelés acteurs secondaires.
Exemple:
Un système ATM (un système de guichet bancaire automatique) interagit avec des utilisateurs qui utiliseront le système pour retirer de l›argent à partir des comptes, déposer de l›argent sur des comptes, et de transférer de l›argent entre les comptes. Ce type d’utilisateurs est alors représenté par l’acteur Client de la Banque. Par conséquent, un modèle de cas d’utilisation peut être utilisé pour représenter les trois cas d›utilisation retirer de
l’argent, déposer de l’argent, et transférer de l’argent qui sont associés à l›acteur Client de la Banque comme le montre la figure 3.1.
Figure 3.1: Diagramme de cas d’utilisation d’un système ATM
Ainsi, les acteurs représentent des entités en dehors du système qui collaborent avec le système. Une fois que nous avons énuméré tous les acteurs d’un système, nous avons ainsi identifié l’environnement externe du système.
Figure 3.2: Cas d’utilisation système Terminal de point de vente