Chapitre 3 Cours « Génie

Logiciel 1 »
Niveau II2A

Analyse des besoins

 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

1-Problématique

◼Positionnement
Avant projet
Développement

Etude

Cours « GL-ACOO » ENSI

Préalable
Analyse des besoins

Expression
Première
définition
du
des besoins
problème

Spécification

2
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

Plan

1. Partie I : Expression des besoins

1. Problématique
2. Les Besoins

Cours « GL-ACOO » ENSI

3. Expression des Besoins
4. Cahier des charges

2. Partie II : Spécification
1. La Modélisation
2. Styles de spécifications
3. Approches (fonctionnelles, Approches objets)

3
 CHAPITRE 3:
ANALYSE DES
BESOINS

Partie I : Expression des

besoins

4
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

1-Problématique

▪ Difficultés de communiquer
▪ difficulté d’être précis, cohérent, complet,…
▪ Le client n’exprime pas toujours ces besoins clairement.

Cours « GL-ACOO » ENSI

▪ Différences de culture
▪ les utilisateurs ne sont pas des informaticiens…
▪ les informaticiens ne connaissent pas le domaine …
▪ Complexité du problème
▪ problème non formalisé ou innovant (non classique)
▪ Evolutivité
▪ Le client peut changer toujours ses besoins

5
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

2-Les Besoins

◼ Besoin (« requirement ») = exigence de ce que le système

devrait satisfaire

Cours « GL-ACOO » ENSI

◼Exemples : Système de contrôle d’un ascenseur
▪ B1. Le système devra planifier les activités de l’ascenseur.
▪ B2. Le système devra allumer l’indicateur panneau d’arrivée
correspondant à l’étage où l’ascenseur arrive
▪ B3. Au dernier (resp. premier) étage, le panneau d’appel ne
contient qu’un seul bouton, soit celui pour descendre (resp.
monter)
▪ B4. etc…

6
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

2-Les Besoins

Trois types de besoins

▪ Besoins fonctionnels

Cours « GL-ACOO » ENSI

▪ Besoins non fonctionnels
▪ Besoins du domaine

7
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

2-Les Besoins

2.1. Besoins fonctionnels

◼Décrivent les fonctionnalités ou les services du système.
▪ Exemple: gestion d’une bibliothèque

Cours « GL-ACOO » ENSI

▪ le système devra permettre l’ajout de nouveaux livres
▪ le système devra permettre d’effectuer des réservations de
livres
▪ Le système devra gérer les emprunts
▪ Etc.
◼Dépendent du type de logiciel, des utilisateurs prévus et du type de
système où le logiciel sera utilisé

8
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

2-Les Besoins

2.2. Besoins du domaine

◼ Dérivés du domaine d’application, ils décrivent les caractéristiques
et fonctions du système qui reflètent le domaine

Cours « GL-ACOO » ENSI

◼ Exemple: logiciel de comptabilité
▪ le système devra éditer des bilans comptables selon les normes
IAS/IFRS
◼ Peuvent être de nouveaux requis fonctionnels, des contraintes sur des
requis existants ou définissent des calculs
◼ Si les requis de domaines ne sont pas respectés, le système peut ne
pas être utilisable

9
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

2-Les Besoins

Problèmes avec les besoins du domaine

◼ Difficile à comprendre
▪ Les requis sont exprimés dans la langue d’application du domaine
◼ Implicite

Cours « GL-ACOO » ENSI

▪ Les spécialistes du domaine comprennent le domaine si bien qu’ils
ne pensent pas à rendre les requis de domaine explicites
◼ Manque de clarté
▪ La précision est difficile à obtenir sans rendre le document difficile
à lire
◼ Confusion dans les requis
▪ Les requis fonctionnels et non fonctionnels tendent à se mêler
◼ Amalgamation de requis
▪ Plusieurs requis différents peuvent être exprimés ensemble

10
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

2-Les Besoins

2.3. Besoins non fonctionnels

◼Des restrictions ou des contraintes qui pèsent sur un service du
système ou sur le système global

Cours « GL-ACOO » ENSI

▪ Ex: fiabilité, robustesse, facilité d’usage, etc.
◼Moins maîtrisés que les besoins fonctionnels
◼Trois principales classes
1. Requis de produit
2. Requis sur le processus
3. Requis externe

11
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

2-Les Besoins

1. Requis de produit
▪ Requis qui spécifie que le produit livré doit se comporter d’une
certaine façon. Ex: vitesse d’exécution, fiabilité, portabilité, etc.
2. Requis sur le processus

Cours « GL-ACOO » ENSI

▪ Requis qui concernent le processus de développement:
▪ devoir utiliser des processus standards,
▪ les besoins relatifs à l’implémentation tels que le langage de
programmation, la méthode de conception
▪ les besoins relatifs à la livraison qui définissent le produit et la
documentation qui doivent être livrés
3. Requis externe
▪ Requis qui provient de facteurs qui sont externes au produit et à
son processus de développement [Link]. besoins en terme de coûts,
requis législatif, etc.

12
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

2-Les Besoins

◼2.3. Besoins non fonctionnels

Besoins non fonctionnels

Cours « GL-ACOO » ENSI

sur le processus sur le produit externes

en en en en
utilisabilité efficacité fiabilité portabilité

en en en
livraison implémentation standards en en
légaux
coûts interopérabilité

en en
performance taille

13
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

2-Les Besoins

2.3. Besoins non fonctionnels

Attention!
◼ Les besoins non fonctionnels doivent être testables et doivent donc
pouvoir être mesurés à l’aide d’une métrique existante ou conçue

Cours « GL-ACOO » ENSI

spécialement pour un système.
◼ Exemples:
▪ Les contrôleurs expérimentés devraient pouvoir utiliser toutes les
fonctions du système au bout de deux heures d’entraînement.
Après cet entraînement, le nombre moyens d’erreurs fait par ces
utilisateurs expérimentés ne devrait pas dépasser deux par jour.
◼Un requis non fonctionnel vérifiable
▪ Le système devra être facile à utiliser par des contrôleurs
expérimentés et doit être organisé de tel sorte que les erreurs
d’usagers soient minimisées.
◼Un requis non fonctionnel non vérifiable
14
Propriété Mesure Cours
Chapitre 3 « Génie Logiciel 1 »
Vitesse Transactions traitées par seconde
Analyse des besoins Niveau II2
Temps de réponse
Temps de réécriture d’écran
2-Les Besoins
Taille Kilo octets Mesures des
Nombre de puces électroniques
requis
Facilité Temps d’entraînement
d’usage Nombres de pages d’aides

Cours « GL-ACOO » ENSI

Fiabilité Temps moyen avant échec
Probabilité de non disponibilité
Taux d’échecs
Disponibilité

Robustesse Temps de redémarrage après échec

Pourcentage d’évènements causant des échecs
Probabilité de corruption de données lors d’échec

Portabilité Pourcentage d’énoncés qui sont dépendants sur le

système cible
Nombre de systèmes cibles
15
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

2-Les Besoins

Caractéristiques d’un besoin

◼Clairs, sans ambiguïtés
◼Consistants: Il ne devrait pas y avoir de conflits ou

Cours « GL-ACOO » ENSI

contradictions dans les descriptions des services du système
◼Complets: tous les services requis par l’utilisateur sont spécifiés
◼Réalistes
◼Pertinents pour le client
◼Vérifiables
◼Traçable

16
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

3-Analyse des Besoins

Le processus d’analyse des besoins

A. Expression des besoins

Cours « GL-ACOO » ENSI

Cahier
des
Détermination Validation & Gestion
Charges
des besoins négociation des besoins

B. Spécification des besoins

Document
d’analyse &
Modélisation spécificatio
Validation n
Et spécification

A//B ou A;B
17
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

3-Analyse des Besoins

Il est essentiel de dissocier dans l’analyse d’un

système, les deux points de vue :
▪ externe (celui des utilisateurs non

Cours « GL-ACOO » ENSI

informaticiens, des décideurs, . . . ).
▪ interne (celui des concepteurs, des
développeurs, des personnels techniques, . . . )

18
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

3-Analyse des Besoins

Pour le point de vue externe

◼On définit une spécification des besoins de l’usager : une
description de haut niveau d’abstraction des services que doit

Cours « GL-ACOO » ENSI

rendre le système et les contraintes sous lesquelles il doit opérer.
Pour le point de vue interne
◼On définit une spécification du système : une description la plus
précise possible du système qui doit être réalisé.

19
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

4-Expression des besoins

▪ Détermination
Cahier
des
Détermination Validation & Gestion

Cours « GL-ACOO » ENSI

Charges
des besoins négociation des besoins

1. Méthodes traditionnelles 2. Méthodes actuelles

• Entrevue avec clients • JAD, FAST, QFD…
• Questionnaire • Prototypage
• Observation
• Étude de l’existant
(documents/logiciels)

20
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

4-Expression des besoins

▪ Validation

Cours « GL-ACOO » ENSI

Cahier
des
Détermination Validation & Gestion
Charges
des besoins négociation des besoins

1. Vérifier que la description des besoins est complète et

cohérente
2. Éliminer les besoins ( non pertinents, irréalisables,
Conflictuels, …)
21
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

4-Expression des besoins

◼ Gestion des besoins

Cours « GL-ACOO » ENSI

Cahier
des
Détermination Validation & Gestion Charges
des besoins négociation des besoins

1. Identification et classification des besoins

▪ Numérotation (séquentielle avec ou sans catégories)
2. Hiérarchisation des besoins
▪ Un besoin peut se composer d’un ou plusieurs besoins plus
spécifiques, moins abstraits

22
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

5-Cahier des charges

◼Un cahier des charges doit :

▪ spécifier uniquement les comportements externes du
système;

Cours « GL-ACOO » ENSI

▪ spécifier les contraintes de réalisation;
▪ être facile à mettre à jour;
▪ servir de référence à la maintenance;
▪ spécifier les réponses aux événements non désirables.
◼Plusieurs normes pour l’écriture des cahiers des charges (IEEE, DoD,
ANSI, ISO, …)

23
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

5-Cahier des charges

I. Fondements du projet :
1. But du projet
a. Problème de l’utilisateur ou contexte du projet

Cours « GL-ACOO » ENSI

b. Objectifs du projet
2. Personnes et organismes impliqués dans les enjeux du projet
3. Utilisateurs du produit

II. Exigences fonctionnelles :

◼ Les exigences formulées dans un CC peuvent être regroupées suivant différents
critères:
▪ Même catégorie d’utilisateurs du système
▪ Même type de fonctions du système
▪ …

24
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

5-Cahier des charges

III. Exigences non fonctionnelles :

1. Environnement de fonctionnement du système actuel et applications
« partenaires » (décrire l’environnement physique et technologique

Cours « GL-ACOO » ENSI

dans lequel le produit sera installé).
2. De combien de temps l’équipe de développement dispose-elle pour
le projet
3. Quel est le budget affecté au projet
4. Contraintes sur le produit (ses qualités) et sur le développement
(langage de programmation particulier).

IV. Annexes

V. Références
25
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

5-Cahier des charges

Caractéristiques d'un cahier des charges

◼ Non-ambiguë ◼ Réalisable

Cours « GL-ACOO » ENSI

◼ Complet ◼ Modifiable
◼ Vérifiable ◼ Indépendant de la conception
◼ Cohérent ◼ Concis
◼ Compréhensible par le ◼ Organisé
client

26
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

6- Exemple d’un standard

Standard IEEE/ANSI 830-1993
Table des matières
Listes des figures et tableaux
1. Introduction

Cours « GL-ACOO » ENSI

1.1. Objectif : décrire le but du présent projet et l’audience visée
1.2. Portée du produit
- Identifier le produit à livrer
- Expliquer ce que le produit fera
- Décrire les usages du produit, ses avantages, les bénéfices attendus et/ou les
problèmes qu’il résoudra
1.3. Définitions, acronymes et abréviations (glossaire)
1.4. Références (mentionnées dans ce document)
1.5. Aperçu du document : ce que contient le reste du document
27
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

6- Exemple d’un standard

2. Description générale du produit

2.1. Perspective du produit

Cours « GL-ACOO » ENSI

▪ décrire la relation du produit avec son environnement

▪ mettre le produit en perspective par rapport à d’autres produits

similaires

▪ mentionner si le produit est autonome ou s’il fait partie d’un système

plus large

▪ joindre toutes les figures et diagrammes

28
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

6- Exemple d’un standard

2. Description générale du produit

2.2. Vue d’ensemble des fonctionnalités

▪ décrire brièvement les fonctions essentielles du produit

Cours « GL-ACOO » ENSI

▪ si possible, produire des représentations graphiques qui résument
ces fonctions

▪ en particulier, définir les interfaces suivantes : interfaces utilisateurs,

avec le matériel, avec les autres produits logiciels et interfaces de
communication

29
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

6- Exemple d’un standard

2. Description générale du produit

2.3. Caractéristiques des utilisateurs
▪ définir les caractéristiques des utilisateurs auxquels le produit est

Cours « GL-ACOO » ENSI

destiné (niveau de connaissance, expérience, expertise technique,
existence de sous-catégorie d’usagers)
2.4. Contraintes d’ordre général
▪ décrire les facteurs qui limitent les options de l’équipe de
développement
▪ en matériel, considérations de sécurité, contraintes au niveau du
langage de programmation, facteurs organisationnels
2.5. Hypothèses et dépendances
▪ identifier tout facteur ou hypothèse implicite qui, si changé, peut
modifier les exigences
30
 Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

6- Exemple d’un standard

3. Description détaillée
▪ Cette partie décrit toutes les exigences du produit à un niveau de détail suffisant
pour permettre au concepteur de satisfaire ces exigences et au testeur de

Cours « GL-ACOO » ENSI

démontrer que les exigences sont respectées.
▪ Elle doit documenter et mentionner les interfaces externes, les performances
requises, les bases de données requises, les attributs et autres propriétés du
produit, les contraintes sur la conception, toutes les figures et diagrammes de ces
aspects.

4. Annexes
5. Index

31
 CHAPITRE 3:
ANALYSE DES
BESOINS
Partie II : Spécification des
besoins
1. La Modélisation
2. Styles de spécification
3. Approches (fonctionnelles,
Approches objets)

32
 Spécification

◼ La spécification aura pour but de décrire avec rigueur :

▪ La structure du système (vue structurelle)
▪ Les fonctions du système (vue fonctionnelle)

Cours « GL-ACOO » ENSI

▪ Les changements d’états et le contrôle du système (vue
comportementale)

Document
Modélisation d’analyse &
Validation
Et spécification spécification

33
 Chapitre 3 La Modélisation
Analyse des besoins

Pourquoi modéliser?

◼Accroissement exponentiel de la complexité des systèmes

informatiques
◼S’appuyer sur la notion de modèle pour :

Cours « GL-ACOO » ENSI

▪ Maîtriser la complexité
▪ Réutiliser des parties
▪ Séparer les préoccupations
▪ Faciliter la communication au sein des équipes de
développement et avec le client
▪ Générer du code

34
 Chapitre 3 La Modélisation
Analyse des besoins

Modèle

◼« une description (d’une partie) d’un système écrite

dans un langage bien défini »

Cours « GL-ACOO » ENSI

◼« un modèle est la simplification subjective d'un
système existant ou qui existera, cette simplification est
sous-tendue par une intention et le modèle obtenu est
alors capable de répondre à des questions à la place du
système qu'il représente. »

35
 Chapitre 3 La Modélisation
Analyse des besoins

Modèle

◼Un modèle permet de réduire la complexité d’un phénomène en

éliminant les détails qui n’influencent pas son comportement de
manière significative.

Cours « GL-ACOO » ENSI

◼Il reflète ce que le concepteur croit important pour la
compréhension et la prédiction du phénomène modélisé.

◼Les limites du phénomène modélisé dépendent des objectifs

du modèle.

36
 Chapitre 3 La Modélisation
Analyse des besoins

Exemple 1

Le plan d’un bâtiment

◼ Les plans sont des modèles qui donnent une vue d’ensemble du
système concerné.
◼ Pour la construction d’un immeuble, il faut préalablement élaborer de

Cours « GL-ACOO » ENSI

nombreux plans :
▪ plans généraux du bâtiment et de sa structure ;
▪ plans d’implantation du bâtiment dans son environnement ;
▪ plans détaillées des différents locaux, bureaux, appartements, etc.
▪ plans des câblages électriques ;
▪ plans d’écoulements des eaux, etc.
◼ Ces plans modélisent différents points de vues.

37
 Chapitre 3
La Modélisation
Analyse des besoins

Exemple 2

◼ La carte est un modèle

Cours « GL-ACOO » ENSI

38
 Chapitre 3 Les styles de spécification
Analyse des besoins

Les styles de spécification

◼ Trois styles selon le degré de formalisation :

▪ informel : basée sur le langage naturel (libre, formaté…),
croquis, …

Cours « GL-ACOO » ENSI

▪ semi-formel : basée sur un langage structuré (graphique
et/ou textuel) dont la sémantique est faible
▪ formel : basée sur un langage formel dont le vocabulaire, la
syntaxe et la sémantique sont formels

39
 Chapitre 3 Les styles de spécification
Analyse des besoins

Spécification informelle

◼Exemple :
▪ La vérification de la validité de la carte consiste à vérifier
que la carte introduite par un utilisateur provient d'une

Cours « GL-ACOO » ENSI

banque reconnue, qu'elle est à jour, et qu'elle contient
des informations appropriées ainsi que des détails sur
les dates et les montants des précédents retraits.

40
 Chapitre 3 Les styles de spécification
Analyse des besoins

Spécification informelle

◼Avantage
▪ liberté pour l'auteur
◼ Inconvénients

Cours « GL-ACOO » ENSI

▪ Ambiguïté : un même mot ne fait pas toujours référence au
même concept chez deux locuteurs différents ou dans deux
contextes différents.
▪ Flexibilité excessive : un même concept peut être expliqué de
plusieurs façons différentes.
▪ Modularité difficile : le partage des mots entre différents
modules rend difficile la traçabilité des concepts (quel
module est en charge de quoi ?).

41
 Chapitre 3 Les styles de spécification
Analyse des besoins

Spécification semi-formelle

◼ Se base sur une notation graphique :

▪ Introduit un aspect formel mais diagrammes annotés
généralement par du texte informel (pour cette raison, on dit

Cours « GL-ACOO » ENSI

semi-fomelle).
◼Ces notations sont particulièrement pratiques pour fournir une
vue d’ensemble, statique ou dynamique, d’un système ou d’un
sous-système.
◼Cependant, leur sémantique doit être précisée.

42
 Chapitre 3 Les styles de spécification
Analyse des besoins

Spécification semi-formelle

Exemple:

Cours « GL-ACOO » ENSI

● Avantage :
● Compromis lisibilité-formalisme
● Support de communication
● Inconvénient :
● Sémantique faible
43
 Chapitre 3 Les styles de spécification
Analyse des besoins

Spécification formelle

◼ Une spécification d’un logiciel est formelle si elle est exprimée

avec un langage qui possède:
▪ un vocabulaire et une syntaxe formellement définis;

Cours « GL-ACOO » ENSI

▪ une sémantique basée sur les mathématiques.

44
 Chapitre 3 Les styles de
Analyse des besoins spécification

Exemple: résultats d’une course

Cours « GL-ACOO » ENSI

45
 Chapitre 3 Les styles de spécification
Analyse des besoins

Spécification formelle

◼Avantages :
▪ Améliorer la qualité du logiciel;
▪ Rigueur et précision des spécifications;

Cours « GL-ACOO » ENSI

▪ Automatisation (vérification, génération de code, etc.)
◼ Inconvénients :
▪ Nécessite une certaine qualification du client, utilisateurs et
développeurs
▪ Ne facilite pas la communication avec les utilisateurs;

46
 Chapitre 3 Approches de
Analyse des besoins spécification

Approches

◼Approche orientée objet

▪ Cours Analyse et Conception orientée objet
◼Approche fonctionnelle

Cours « GL-ACOO » ENSI

47
 Chapitre 3 Approches de
Analyse des besoins spécification

Axes de modélisation d’un système

Structurel (ce que le système EST)

Cours « GL-ACOO » ENSI

Statique

Fonctionnel
Comportemental e
iq
u (ce que le système FAIT)
(comment le a m
n
système EVOLUE) D
y

48