Vous êtes sur la page 1sur 8

03/04/2020 UML : Recherche et analyse des besoins | SUPINFO, École Supérieure d'Informatique

Accéder à Open-Campus

ACCUEIL CURSUS COURS ADMISSIONS CAMPUS DOCUMENTATION ANCIENS ENTREPRISES LIBRAIRIES PUBLICATIONS

UML : Recherche et analyse des besoins


Par Jérôme RALITE • Publié le 15/11/2017 à 19:16:15 • Noter cet article: ☆☆☆☆☆ (0 votes)
Avis favorable du comité de lecture

Jérôme RALITE
Dans le développement d’applications, on distingue deux types de besoins :
1. Les besoins fonctionnels
2. Les besoins non fonctionnels, c’est-à-dire tout ce qui concerne la qualité, la abilité, les performances, les
aspects juridiques, ….

Les cas d’utilisation (use case) sont une technique qui permet de définir les
exigences fonctionnelles des utilisateurs. Le processus unifié (UP, cf.
1 - Recherche des besoins fonctionnels : Les cas d’utilisation
https://fr.wikipedia.org/wiki/Unified_process ) encourage le développement 2 - Analyse fonctionnelle : description des scénarios des cas d’utilisation
3 - Les besoins non fonctionnels : Les spéci cations Supplémentaires
piloté par les cas d’utilisation, c’est-à-dire que les cas d’utilisation sont utilisés
lors des différentes étapes du processus de développement logiciel (de
l’analyse jusqu’aux tests).
Les principales méthodes agiles, comme Extreme programming (XP) ou Scrum, n’utilisent pas explicitement les cas d’utilisation mais
décrivent des scénarios utilisateur (User story) qui ont beaucoup de similitudes avec les cas d’utilisation.

Une fois les différents scénarios recensés, ils peuvent être décrits de manière textuelle. Cependant ils peuvent également être
représenté sous d’autres forme en utilisant différentes notations UML (cf. https://fr.wikipedia.org/wiki/UML_(informatique)) :
1. Diagramme de cas d’utilisation
2. Diagramme de séquences
3. …

Quant aux exigences non fonctionnelles, elles peuvent être regroupées dans un document textuel que l’on appelle «  Spécification
supplémentaires » dans le processus unifié.

1 - Recherche des besoins fonctionnels : Les cas d’utilisation


Un cas d’utilisation est une description de l’application qui privilégie le point de vue de l’utilisateur. Il décrit de façon textuelle et
éventuellement graphique comment un acteur va utiliser l’application pour atteindre un objectif.
L’élaboration et la description des cas d’utilisation vont permettre aux développeurs de recenser et prendre en compte les exigences de
tous les utilisateurs de l’application et pas uniquement les exigences du client.

Nous allons voir comment rédiger des cas d’utilisation efficaces et voir comment il est possible d’enrichir un diagramme de cas
d’utilisation en y faisant figurer diverses relations (inclusion, extension et héritage).
Ensuite nous verrons l’une des principales difficultés dans la modélisation des cas d’utilisation, qui est de délimiter le périmètre de
l’application. En effet, l’informaticien ne doit pas négliger l’incidence que peut causer sa solution sur l’organisation du système
d’information.
Pour finir, nous verrons comment les cas d’utilisation peuvent être utilisés pour planifier un processus de développement itératif ou un
projet plus traditionnel en cascade (cf. https://fr.wikipedia.org/wiki/Cycle_de_d%C3%A9veloppement_(logiciel)).

1.1 - Elaboration et description des cas d’utilisation

La première étape consiste à déterminer les acteurs, c’est-à-dire les différents utilisateurs de l’application. Une fois cela fait, il faut définir
ce qu’ils attendent de l’application. Pour cela, il faut les interroger pour savoir comment ils souhaitent utiliser l’application. En effet, on
ne demande pas aux utilisateurs de s’adapter aux fonctionnalités de l’application, mais on demande à l’application de répondre aux

https://www.supinfo.com/articles/single/6549-uml-recherche-analyse-besoins 1/8
03/04/2020 UML : Recherche et analyse des besoins | SUPINFO, École Supérieure d'Informatique

fonctions utiles du point de vue de l’acteur. On parle d’approche orientée utilisateur.


De tout cela, vont découler différents scénarios que l’on va regrouper dans des cas d’utilisation. Ces cas doivent être décrirs de façon
textuelle, mais ils peuvent également être décrits de façon graphique sous forme de diagramme de cas d’utilisation. Ce diagramme doit
être suffisamment intuitif et accessible pour être lu par des non-informaticiens.

1.1.1 - Les acteurs

Un acteur représente un rôle joué par une personne ou un autre système qui interagit directement avec l’application. Donc, un acteur
peut être un utilisateur physique de l’application, mais également un responsable d’exploitation, de maintenance ou un autre système.
Attention, une même personne physique peut jouer le rôle de plusieurs acteurs, et réciproquement un acteur peut concerner plusieurs
personnes.
En UML tout est objet, c’est-à-dire que les acteurs sont représentés par des classes auxquelles on ajoute le stéréotype «  acteur  ». Une
deuxième notation existe, qui consiste à représenter un acteur sous la forme d’un stick man. La bonne pratique veut qu’on utilise le stick
man pour représenter des acteurs humains et les classes pour représenter les autres systèmes qui interagissent avec l’application.

1.1.2 - Les cas d’utilisation

Selon Jacobson (cf. https://fr.wikipedia.org/wiki/Ivar_Jacobson), un cas d’utilisation représente un ensemble de séquences d’actions qui
est réalisé par le système et qui produit un résultat observable intéressant pour un acteur particulier.
C’est-à-dire qu’un cas d’utilisation doit avoir une granularité moins fine que la fonctionnalité de l’application (il ne peut pas se limiter qu’a
une seule action). Un cas d’utilisation ne doit pas non plus être trop vaste (il doit se dérouler d’une seule traite).
Pour mieux comprendre, une autre définition selon Fowler (cf. https://fr.wikipedia.org/wiki/Martin_Fowler) : Un cas d’utilisation permet
de regrouper différents scénarios qui ont un objectif utilisateur commun. Cela signifie qu’un cas d’utilisation permet aux utilisateurs de
structurer leurs exigences suivant leurs objectifs en utilisant une terminologie proche du métier.
Jacobson indique que pour un gros projet, il ne doit pas y avoir plus de vingt cas d’utilisation (une douzaine pour un projet de taille
moyenne). S’il y en a plus, il faut se remettre en question pour savoir si l’on n’est pas en train de décrire des fonctionnalités plutôt que
des cas d’utilisation.
Pour réduire le nombre de cas, jacobson conseille de n’avoir qu’un seul cas d’utilisation CRUD (Create, Read, Update, Delete) par entité.
Les bonnes pratiques veulent que le nom d’un cas d’utilisation commence par un verbe à l’infinitif (objectif de l’acteur) et soit suivi d’un
complément.
Lors de la représentation graphique, un cas d’utilisation est illustré grâce à une ellipse. Les acteurs qui sont concernés par ce cas sont
reliés avec une association. Cette association peut avoir un sens de navigation ou non. Un acteur peut réaliser un ou plusieurs cas
d’utilisation et inversement.

Exemple: représentation d'un cas d'utilisation

Attention, tous les acteurs n’utilisent pas l’application de la même façon. On appelle acteur principal celui pour qui le cas d’utilisation
produit une action observable et acteur secondaire s’il est juste sollicité par le cas (ex : acteur qui consulte ou qui est juste informé par
l’application).

https://www.supinfo.com/articles/single/6549-uml-recherche-analyse-besoins 2/8
03/04/2020 UML : Recherche et analyse des besoins | SUPINFO, École Supérieure d'Informatique
1.1.3 - Le diagramme des cas d’utilisation

Le diagramme des cas d’utilisation permet de regrouper sur un même schéma plusieurs cas d’utilisation. Ce diagramme est un outil de
communication entre les informations qui réalise l’application et les utilisateurs. C’est pourquoi, il doit être simple, intuitif et privilégier la
lisibilité (pas plus de huit cas d’utilisation sur un diagramme).

Graphiquement, dans le diagramme des cas d’utilisation, les cas sont contenus dans un rectangle qui correspond au périmètre de
l’application. Les acteurs sont donc à l’extérieur du rectangle, par convention on place les acteurs principaux à droite du rectangle et les
autres à gauche.

Exemple: diagramme des cas d'utilisation

1.1.4 - Description d’un cas d’utilisation

Le diagramme des cas d’utilisation est donc très intuitif, cependant il décrit l’application de façon trop grossière pour être exploité lors
de la suite de l’analyse. Il est donc indispensable que chaque cas d’utilisation soit détaillé plus précisément textuellement, mais il est
également possible d’utiliser d’autres diagrammes UML (diagramme d’activité, diagramme global d’interaction).
Roques (cf. https://www.babelio.com/auteur/Pascal-Roques/28343), définit le diagramme des cas d’utilisation comme un «  sommaire
visuel » de la description des cas d’utilisation.

Représentation textuelle

La description textuelle des cas d’utilisation est très importante, parce que dans le processus unifié, ces descriptions vont être utilisées
dans toutes les étapes du processus (jusqu’aux tests). Il faut donc soigner le style et l’orthographe afin que ces cas soient le plus lisible
possible.

Les bonnes pratiques :


1. Privilégier les phrases courtes (sujet, verbe complément)
2. Le sujet de la phrase est soit un acteur, soit le système
3. Eviter la voix passive

On appelle scénario nominal, le scénario qui répond aux objectifs des acteurs par le chemin le plus direct. C’est-à-dire, le scénario qui est
supposé être le plus fréquent, où aucune erreur s’est produite.
Les scénarios qui aboutissent quand même à une fin normale mais par un autre chemin sont appelé les scénarios alternatifs.
Les scénarios d’erreurs sont les scénarios qui n’aboutissent pas.

En UML, il n’y a pas de façon standard pour rédiger un cas d’utilisation. Cependant, deux bonnes pratiques sont reconnues :
1. La description abrégée
2. La description détaillée

Exemple: description abrégée

Exemple: description détaillée

https://www.supinfo.com/articles/single/6549-uml-recherche-analyse-besoins 3/8
03/04/2020 UML : Recherche et analyse des besoins | SUPINFO, École Supérieure d'Informatique

Mais quel format utiliser en phase d’analyse ?

Dans le processus en cascade où au commencement du projet il faut définir le cahier des charges, la description détaillée est privilégiée.
Dans ce cas de figure il faut aussi essayer de décrire un maximum de scénarios alternatifs (il n’est pas possible de tous les décrire).
Il est aussi utile d’utiliser une description détaillée lors d’un projet à forte criticité, c’est-à-dire un projet ayant une faible tolérance aux
erreurs.
La description abrégée est plus projet à faible criticité, mais également pour les projets agiles, qui suivent un processus itératif où le
client n’est pas toujours conscient de ses besoins.

Représentation graphique : diagramme d’activité

Pour les cas d’utilisation complexes, il est possible de réaliser un diagramme d’activités, dans le but de décrire toutes les actions que
réalise l’application (en représentant tous les états et les conditions pour changer d’état). Le diagramme d’activité est un excellent outil
pour décrire le workflow d’une application. Cependant, il représente peut d’intérêt et il est plus complexe à lire pour le client que les
scénarios textuels.

Exemple: diagramme d'activité

Dans UML 2, il est possible de représenter différents scénarios d’un cas d’utilisation à l’aide d’un diagramme global d’interaction. Ce
diagramme est un mélange entre le diagramme d’activités et un diagramme de séquence. Il est intéressant pour représenter un
fragment de cas d’utilisation relié à d’autres cas pas une relation d’inclusion.

https://www.supinfo.com/articles/single/6549-uml-recherche-analyse-besoins 4/8
03/04/2020 UML : Recherche et analyse des besoins | SUPINFO, École Supérieure d'Informatique

1.2 - Relation entre cas d’utilisation

Il est possible d’affiner la sémantique d’un diagramme des cas d’utilisation en intégrant des relations entre les cas. Cependant il est
déconseillé de les utiliser pour communiquer avec les utilisateurs. En effet, on conseille généralement de ne pas perdre de temps à
analyser les relations entre les cas afin de se consacrer à leur rédaction.

1.2.1 - Inclusion

Définition : Le cas d’utilisation en incorpore implicitement un autre de façon obligatoire Cette relation permet de factoriser une partie du
traitement qui se répète dans plusieurs cas. Ainsi on utilisera une relation d’inclusion uniquement lorsque le cas inclu est partagé par
plusieurs autres cas d’utilisation.

Exemple: inclusion

1.2.2 - Extension

Définition : Le cas d’utilisation en incorpore implicitement un autre de façon optionnelle. La relation d’extension est un moyen de mettre
en avant une fonctionnalité optionnelle. Généralement, cette relation comporte une condition de garde.

Exemple: extension

1.2.3 - Héritage

Il est possible de réaliser un héritage entre les acteurs mais également entre les cas d’utilisation. Cependant la relation d’héritage entre
acteurs n’est souvent pas nécessaire puisqu’une même personne physique peut jouer le rôle plusieurs rôles. Depuis la version 1.1 d’UML,
l’héritage se différencie de la simple relation d’extension. En effet, elle sert à redéfinir des cas d’utilisation de manière spécifique
(« polymorphisme » de cas – cf. https://fr.wikipedia.org/wiki/Polymorphisme_(informatique))

Exemple: héritage

1.3 - Délimitation du périmètre de l’application

Généralement, les informaticiens utilisent les cas d’utilisation pour déterminer les fonctionnalités de l’application qu’ils doivent
développer. Le système étudié est alors l’application et l’on parle de cas d’utilisation système. Par conséquent, on s’intéresse
essentiellement aux interactions entre les utilisateurs de l’application et le système.
Cependant on peut aussi utiliser les cas des cas d’utilisation pour modéliser les processus métier d’une organisation. Le système étudier

https://www.supinfo.com/articles/single/6549-uml-recherche-analyse-besoins 5/8
03/04/2020 UML : Recherche et analyse des besoins | SUPINFO, École Supérieure d'Informatique

est alors le système d’information et on parle donc de cas d’utilisation métier.


Il est donc important de ne pas se mélanger et de bien définir le système étudier avant de rédiger les cas d’utilisation.

Il faut tout de même savoir, que les systèmes d’information et le système informatique sont étroitement liés. En effet, une modification
dans le système informatique peut influer l’organisation de l’entreprise. C’est pourquoi, il est conseillé de réaliser une analyse du
système d’information, pour concevoir une meilleure analyse du système informatique. En effet, en se concentrant sur les interactions
entre les utilisateurs et le système informatique, il est possible de passer à côté d’un cas où changer l’organisation du processus métier
serait une meilleure solution.

Dans le BPR (Business Process Reengineering – cf. https://en.wikipedia.org/wiki/Business_process_reengineering), l’étude du système


d’information doit permettre de bien comprendre la problématique métier et donc de ne rien négliger dans la future analyse du système
informatique. Cette approche (suggérée par les auteurs d’UML), peut être matérialisée à l’aide de différents schémas, comme le
diagramme des cas d’utilisation métier ou le diagramme d’activités. Il faut également savoir, qui dans la méthode du processus unifiée, il
est proposé de faire une étude de domaine et une étude d’activités de l’organisation en préambule de l’expression des besoins du
système informatique.

1.4 - Cas d’utilisation et planification

Dans les méthodes agiles, la planification est dite adaptative. Cependant il est important rédiger grossièrement les cas d’utilisation afin
d’inventorier les exigences fonctionnelles. Même si elles ne sont pas détaillées et pourront être modifiées par la suite, cela va permettre
de les hiérarchiser et de choisir les fonctionnalités qui seront développées lors du lancement d’une itération.
Une fois les cas d’utilisation récoltés, certaines méthodes agiles (Scrum par exemple) proposent d’estimer leur complexité selon deux
critères :
1. La valeur fonctionnelle, qui est la valeur qui va être ajoutée à l’application en développant ce cas d’utilisation
2. L’e ort technique, qui représente l’e ort à mettre en œuvre pour développer ce cas d’utilisation

Afin d’évaluer ces cas d’utilisation, dans les méthodes agiles il est possible d’effectuer un planning poker (cf.
https://fr.wikipedia.org/wiki/Planning_poker). Cette façon ludique de produire des estimations sur la complexité de fonctionnalités, à
l’avantage de permettre à tout le monde de donner son avis.

Ainsi grâce à ces estimations, il est plus facile de hiérarchiser les cas d’utilisation, puis en fonction de la vélocité (productivité) de l’équipe
de planifier leur implémentation dans différentes itérations. En général on place les cas d’utilisation en forte complexité dans les
premières itérations, ainsi en cas de retard il sera plus facile de faire les cas à faible complexité. Lorsque des cas d’utilisation on la même
valeur, on privilégiera plutôt le cas nécessite le moins d’efforts afin d’essayer de maximiser la valeur produite dans l’itération.

Il faut savoir qu’il est possible d’ajouter d’autres critères pour calculer la complexité d’un cas d’utilisation. Par exemple la méthode
Extreme programming (XP), propose de prendre en compte le critère du risque. En effet, les équipes de développement ont plus d’intérêt
à privilégier dans les premières itérations les cas à forte valeur et à risque élevé afin de réduire au plus vite l’incertitude.
Pour finir, le dernier critère à ne pas négliger est l’apprentissage de l’équipe. Dans les toutes premières itérations il est important que
l’équipe apprenne surtout à bien travailler pour augmenter sa vélocité. Cet apprentissage va bien entendu concerner la technologie (les
frameworks utilisés) mais également le métier (les exigences du client) et les estimations de cout et de délai.

Dans les projets plus traditionnels en cascade, il n’est pas utile de classer les cas d’utilisation, puisqu’en théorie tout ce qui est écrit dans
le cahier des charges doit être réalisé. Ce que l’on va donc planifier c’est les activités du projet c’est-à-dire l’étude de l’existant, la
rédaction des spécifications, la conception, les tests, ….
Le travail du chef de projet consiste donc à évaluer l’enveloppe globale du projet. Ensuite, il peut en fonction des ressources dont il
dispose, calculer le délai et le coût du projet. Avec cela, il découpe le projet taches et les ordonne selon un planning permettant une
utilisation optimale de ses ressources (Gantt). Ainsi, s’il constante une différence entre ce planning et l’avancement réel du projet, il
pourra réajuster ses ressources ou de modifier son planning.

2 - Analyse fonctionnelle : description des scénarios des cas d’utilisation


Comme vu précédemment, un cas d’utilisation peut se décomposer en plusieurs scénarios. Pour les scénarios les plus complexes il est
conseillé de les décrire graphiquement, afin de voir comment se succèdent les envois de messages entre les acteurs et l’application.

Pour se faire on peut utiliser un diagramme de séquence système, qui va permettre d’illustrer les évènements d’entrée et de sortie de
l’application.
Une fois le diagramme de séquence système réaliser il est possible de lister les différentes opérations du système de de définir
l’interface publique du système.

2.1 - Le diagramme de séquence système

Dans ce diagramme l’application est étudiée comme une boîte noire, c’est-à-dire qu’on ne se préoccupe pas du fonctionnement interne
de l’application. On étudie seulement les interactions entre l’acteur responsable du cas d’utilisation et l’application.

https://www.supinfo.com/articles/single/6549-uml-recherche-analyse-besoins 6/8
03/04/2020 UML : Recherche et analyse des besoins | SUPINFO, École Supérieure d'Informatique

Exemple: diagramme de séquence système

2.2 - L’interface publique du système

A partir de tous les diagrammes de séquences système réalisé, on va recenser les différentes opérations envoyées à l’application. Cette
liste correspond à l’interface publique de l’application. Cette interface peut être représentée avec la notation UML d’une interface comme
ci-dessous.

Exemple: interface publique du système

Le processus unifié préconise de rédiger un contrat d’opération pour chacune des opérations qui sera possible de faire sur l’application.
Dans tous les cas qu’un contrat soit rédiger ou non, ces opérations serviront pour la conception objet de l’application. Durant cette étape
il faudra de détailler les objets internes de l’application qui vont implémenter ces opérations. Pour cela on utilise un diagramme de
séquence d’interaction (cf. http://laurent-audibert.developpez.com/Cours-UML/?page=diagrammes-interaction)

3 - Les besoins non fonctionnels : Les spéci cations Supplémentaires


Les cas d’utilisation sont utiles pour définir les besoins fonctionnels, cependant il faut tenir compte de besoins non fonctionnels et des
diverses contraintes. Selon le processus unifié, ces besoins et contraintes sont recensés dans une liste appelée «  Spécifications
supplémentaires ».

Ces spécifications supplémentaires peuvent être d’ordres divers, pour être plus précis, voici quelques exemples :

• Fonctionnalités :

1. Les erreurs de connexion doivent être consignées dans un fichier log


2. Toute utilisation implique une authentification

• Ergonomie et interface :

1. La réception d’un message doit émettre un signal sonore


2. L’authentification doit se faire par biométrie

• Fiabilité :

1. En cas d’indisponibilité du système distant une solution locale provisoire doit être mis en place

• Performance :

1. La consultation des messages doit se faire en moins de deux secondes dans 90% des cas

• Support :

1. Les décisionnaires insistent pour utiliser les technologie Windows (WPF, WCF, …), selon eux cela facilite à long terme la
maintenance et simplifie le développement.

• Aspects juridiques :

1. Après un achat en ligne, un client bénéficie d’un délai de rétractation de 15 jours


2. Les données biométriques doivent être déclarées à la CNIL

• Règles et informations dépendantes du domaine

https://www.supinfo.com/articles/single/6549-uml-recherche-analyse-besoins 7/8
03/04/2020 UML : Recherche et analyse des besoins | SUPINFO, École Supérieure d'Informatique

1. La marge réaliser sur la ventes des produits est supérieur à 5%


2. Le calcul des diverses taxes est complexe et peut changer suite à des modifications de loi

Pour conclure, dans le processus unifié, l’étape de rédaction des besoins non fonctionnels est très importante. En effet, elle va permettre
de déterminer les contraintes techniques qui sont indispensables pour concevoir l’architecture physique et logique de la future
application. Il faut savoir, qu’il existe d’autres notations UML pour représenter ces choix de conception, tels que le diagramme de
déploiement, le diagramme de composants, le diagramme paquetages, …

A propos de SUPINFO | Contacts & adresses | Enseigner à SUPINFO | Presse | Conditions d'utilisation & Copyright | Respect de la vie privée | Investir

SUPINFO International University


Ecole d'Informatique - IT School
École Supérieure d'Informatique de Paris, leader en France
La Grande Ecole de l'informatique, du numérique et du management
Fondée en 1965, reconnue par l'État. Titre Bac+5 certifié au niveau I.
SUPINFO International University is globally operated by EDUCINVEST Belgium - Avenue Louise, 534 - 1050 Brussels

https://www.supinfo.com/articles/single/6549-uml-recherche-analyse-besoins 8/8

Vous aimerez peut-être aussi