• 20 heures
  • Facile

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 15/10/2019

La démarche

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Lors de la première partie, nous avons vu ce qu’était UML et la démarche que je vous propose de suivre. Dans cette partie, nous allons à partir d’une étude de cas, suivre pas à pas l’analyse des besoins d’un projet en réalisant différents diagrammes. On tentera d’effectuer l’analyse des besoins d’un projet commun : créer une boutique en ligne.

Comme je vous le précisais dans la partie précédente, nous identifierons les premiers besoins grâce aux différents échanges avec le client. On découvrira au fur et à mesure les différents besoins et actions ce que le client souhaite intégrer dans son projet de logiciel, la boutique en ligne. Notre première mission sera donc de décrypter son discours au fur et à mesure afin de préciser ses besoins. C’est ce qu’on appelle la modélisation des besoins fonctionnels. Nous essaierons donc de répondre aux questions suivantes :

  • Qui sont les utilisateurs ?

  • Que veulent-ils faire avec le logiciel ?

Les étapes

Par quoi on commence ?

Comme je l’ai indiqué dans l’introduction, il ne sert à rien de commencer à coder sans avoir compris les besoins des utilisateurs au préalable. Sinon, on risque de créer un logiciel qui n’est pas utile, qui est bancal ou en tout cas non satisfaisant pour les utilisateurs.

Mais alors, c’est quoi l’analyse des besoins ?

Analyser les besoins, c’est découvrir des éléments de plus en plus précis. Voici les étapes :

Étape 1

On commence par décrire le contexte du logiciel à créer.

Qu’est-ce que c’est le contexte ? Eh bien, c’est l’environnement direct du logiciel. Il s’agit là de décrire QUI devra utiliser le logiciel.
Il faut donc se poser la question : à qui le logiciel devra servir ?

Imaginons par exemple que l’on ait fait partie d’une des équipes d’analyse et de conception de la société MicroSoft. Pour définir le contexte du logiciel « Word » par exemple, on a dû penser aux différents types d’utilisateurs qui s’en serviraient. Je sais, vous n’avez pas réellement fait partie d’une de ces équipes. Moi non plus d’ailleurs. Mais on peut facilement imaginer qu’ils ont pensé aux rédacteurs d’un texte, aux vérificateurs, aux lecteurs, etc.

Étape 2

On décompose ensuite le logiciel en plusieurs parties distinctes, histoire de ne pas avoir à analyser quelque chose de trop énorme d’un coup. On appelle ça la décomposition en packages. La décomposition peut se faire en réfléchissant à des « familles » de fonctionnalités qui seraient nécessaires.
Les questions à se poser ? Celles-ci par exemple !

  • Quelles sont les grandes parties qui doivent composer le logiciel ?

  • Pour une partie précise, qui, parmi les acteurs identifiés (ou utilisateurs) l’utilisera ?

Reprenons notre exemple du logiciel « Word ». On peut le décomposer en plusieurs parties ou packages : la partie « Accueil », la partie « Mise en page », la partie « Publipostage », etc. Oui, on pourrait considérer que chaque partie correspondra à un menu du logiciel.

La partie « Accueil » sera utilisé aussi bien par un rédacteur que par un vérificateur ou un lecteur.
La partie « Mise en page », en revanche, sera probablement seulement utilisé par un rédacteur.

Étape 3

Chaque partie est alors analysée séparément, en précisant QUI devra pouvoir faire QUOI grâce à cette partie du logiciel. C’est ce qu’on appelle définir les cas d’utilisation.
Par exemple, demandez-vous, « dans la partie X, qui devra faire quoi avec le logiciel ? »

Toujours sur le logiciel « Word », on distingue des utilisations différentes, en fonction du type d’utilisateur.
Par exemple, dans la partie «Accueil», le rédacteur peut écrire du texte, changer la police et la couleur du texte, aligner le texte, etc.
Dans la partie « Révision », le vérificateur peut insérer des commentaires, indiquer des modifications, etc. Dans cette même partie, le rédacteur peut accepter ou refuser des modifications. Il y a bien d’autres possibilités dans ce logiciel, mais je pense que vous avez saisie ce que je voulais dire.

Pour simplifier la compréhension, on peut considérer que chaque «utilisation» correspond à un sous-menu.

Les outils nécessaires

Pour illustrer chacune des étapes citées ci-dessus, on utilise un diagramme précis, que nous détaillerons au fur et à mesure du cours.

  • Pour décrire le contexte, on réalise un diagramme de contexte dans lequel on indiquera qui aura une utilité du futur logiciel.

  • Pour expliquer la décomposition du logiciel en parties distinctes, on se sert d’un diagramme de packages. Celui-ci nous permettra d’indiquer qui aura besoin de chacune des parties.

  • Enfin, pour illustrer ce que le logiciel doit permettre de faire, on utilise un diagramme des cas d’utilisation.

En fait, chaque diagramme est une précision du précédent. C’est comme si en ouvrant une grande boîte en carton, on découvrait d’autres boîtes. D’ailleurs, notre découverte ne s’arrêtera pas au diagramme des cas d’utilisation, mais là j’avance un peu sur les parties à venir…

Décomposition de l’analyse

Étude de cas

Comme promis, je vous propose de découvrir l’analyse de besoins d’un projet de logiciel à partir d’un projet commun : créer la boutique en ligne d’une entreprise de papeterie. Nous découvrirons pas à pas la démarche à suivre. Voici le projet.

Qui est notre client ?

Notre client, Monsieur Morin, est le directeur d’une petite entreprise commerciale, MORIN OFFICE, spécialisé dans les produits de bureau. Son entreprise est localisée à Blois.

Que vend-il ?

Voici la liste de produit qu’il vend sur place :

  • Matériel de base : crayons, stylos, gommes, papier, cahiers, etc. 

  • Matériel électronique : ordinateurs, imprimantes, téléphones, etc. 

  • Mobilier : tables, bureaux, chaises, armoires, etc. 

Pourquoi nous contacte-t-il ?

L’entreprise doit faire face à la concurrence de grandes enseignes et a le projet de moderniser toute sa démarche commerciale. Il souhaite passer au e-commerce, c’est-à-dire vendre ses produits sur Internet ! L’entreprise espère ainsi obtenir une meilleure visibilité et obtenir une augmentation des ventes.

Que souhaite-t-il faire sur le site de vente en ligne ?

Lors d’une première discussion avec notre client Monsieur Morin, nous avons pu obtenir les précisions suivantes :

  1. Le client (ou client potentiel) doit pouvoir consulter les produits et éventuellement procéder à un achat en ligne.

  2. Les commerciaux de la société doivent pouvoir consulter le catalogue des produits en ligne et enregistrer les achats des clients. 

  3. Le service des livraisons doit pouvoir consulter les commandes pour préparer les colis et les livrer au client.

  4. Le technicien doit pouvoir vérifier d’éventuelles remarques ou messages signalant un dysfonctionnement lors de l’achat en ligne.

  5. Le service administratif de la société doit pouvoir :
    - ajouter de nouveaux produits au catalogue en ligne ;
    - modifier les descriptions ou les prix des produits ;
    - retirer si besoin des produits que l’on ne souhaite plus proposer.

  6. Le directeur, quant à lui, souhaite avoir une vision globale des ventes. À travers le site, il souhaite pouvoir :
    - faire un suivi du chiffre d’affaires par mois, sur une certaine durée ;
    - voir quels produits sont les plus vendus sur une durée donnée. 

Exemple de certificat de réussite
Exemple de certificat de réussite