Vous êtes sur la page 1sur 58

Chapitre 3 Cours « Génie

Logiciel 1 »
Niveau II2

Analyse des besoins

AU: 2021/2022
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. Exemple d’un standard

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

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

Plan

Cours « GL-ACOO » ENSI


Partie I : Expression des besoins

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

1-Problématique

 Beaucoup de systèmes existants sont mal utilisés voir même


jamais utilisés car ils ne correspondent pas aux besoins du
client !

Cours « GL-ACOO » ENSI


 « Ce n’est pas ce que je voulais… »
 « ça ne sert à rien... »
 « Comment je fais ça ?»
 « Ce n’est pas le bon résultat ! »
 « Je vous avais dis que je voulais ça ! »
 ...

4
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
des besoins
Première
définition
du
problème

Spécification

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

Cours « GL-ACOO » ENSI


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

1-Problématique
 Difficu l tés de communiq uer
 Difficulté d’être précis, cohérent, complet,…
 Le client n’exprime pas toujours ces besoins clairement.
 Le client ne sait pas toujours ce qu’il veut et n’exprime pas toujours ces besoins
clairement.

Cours « GL-ACOO » ENSI


 L’informaticien ne comprend pas le client (et vice versa !)
 Ce que le client demande n’est pas forcement ce dont il a besoin.
 Le client exprime souvent la solution à laquelle il pense et non son besoin réel (que vous
ne connaîtrez peut-être jamais).
 Le client ne connaît pas toujours l’informatique : il ne sait pas ce qui est possible et ce
qui ne l’est pas.
 Ce que le client veut n’est pas ce qu’il voulait
 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é
7
 Le client peut changer toujours ses besoins
Cours
Chapitre 3
« Génie Logiciel 1 »
Analyse des besoins
Niveau II2

Cours « GL-ACOO » ENSI


8
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


Synonyme: exigences, caractéristiques, requis.

 les besoins décrivent les exigences tel qu’ils


soient compréhensibles par les clients du
système qui n’ont pas forcément de
connaissances techniques détaillées

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

2-Les Besoins

 Exemple 1: Système de contrôle d’un ascenseur


 B1. Le programme doit planifier les activités de l’ascenseur de façon efficace et
raisonnable.
 B2. Le programme doit illuminer l’indicateur du panneau d’arrivée
correspondant à l’étage où l’ascenseur arrive.

Cours « GL-ACOO » ENSI


 B3. Au dernier (resp. premier) étage, le panneau d’appel ne contient qu’un seul
bouton, soit celui pour descendre (resp. monter).
 Exemple 2 : Système de surveillance des patients dans une unité de
soins intensifs
 B1. Le système sera installé dans l’unité de soins intensifs de l’hôpital. Cette unité
comporte 8 lits destinés à recevoir des patients dont l’état est critique et dont les
signes vitaux doivent être surveillés 24/24.
 B2. Les signes vitaux à surveiller sont l’électrocardiogramme, le rythme
respiratoire et la pression artérielle.
 B3. La surveillance consiste à saisir les signes vitaux, à les afficher sur des
moniteurs aux lits et au poste des infirmières, à les comparer avec une banque de
référence et à émettre éventuellement des alarmes.
 B4. Le système doit produire des rapports sur chaque patient.
 B5. Des capteurs en place devront être utilisés
 B6. Le système devra être opérationnel dans un an.
10
Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

2-Les Besoins

Il est essentiel de dissocier dans la description


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, . . . )

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

2-Les Besoins

Trois types de besoins

Cours « GL-ACOO » ENSI


Besoins fonctionnels

Besoins non fonctionnels

Besoins du domaine

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

2-Les Besoins

 Besoins fonctionnels (exigences fonctionnelles)


 À quoi sert le système?
 Ce que doit faire le système, les fonctions utiles
 description des services (fonctions).

Cours « GL-ACOO » ENSI


 "Comment souhaite-on pouvoir utiliser le système?".
 Description des données manipulés
 Besoins non fonctionnels : une restriction ou une contrainte qui pèse
sur un service du système (spécifications techniques)
 description des contraintes,
 chercher des critères mesurables
 Pour chaque fonction et pour le système global, il est possible
d’exprimer différents types de contraintes
 performance, sûreté, confidentialité, portabilité, etc.
 Besoins du domaine
 Requis qui proviennent du domaine d’application du système et qui
reflètent les caractéristiques de ce domaine

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

2-Les Besoins

 2.1 Besoins fonctionnels


 Ils décrivent les fonctionnalités ou les services à offrir par le système
 Ils dépendent des utilisateurs prévus

Cours « GL-ACOO » ENSI


 Les requis fonctionnels de l’utilisateur peuvent être des énoncés de haut
niveau de ce que le système devrait faire mais les requis fonctionnels du
système devraient décrire en détails les services du système
 Exemples:
 L’usager devra pouvoir de faire une recherche dans soit l’ensemble initial des
bases de données soit choisir un sous-ensemble de celles-ci.
 Le système fournira des visualisateurs appropriés pour que les usagers puissent
lire les documents archivés sur le système.

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

2-Les Besoins

2.1 Besoins fonctionnels


Ils doivent être :

Cours « GL-ACOO » ENSI


 complets : ils doivent inclure les descriptions de
toutes les facilités requises

 cohérents : il ne doit pas y avoir des conflits ou des


contradictions dans les descriptions des facilités du
système

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

2-Les Besoins

2.1 Besoins fonctionnels


Exemple des besoins conflictuels pour un Système
d’astronefs :

Cours « GL-ACOO » ENSI


♦ Afin de minimiser le poids, le nombre de puces, dans le
système, devrait être minimisé.
♦ Afin de minimiser la consommation d’énergie, des puces à
faible consommation devraient être utilisés
♦ Toutefois, l’usage de puces à faible consommation
d’énergie peut vouloir dire davantage de puces devront
être utilisés.
 Il faut trouver un compromis 16
Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

2-Les Besoins

2.2 Besoins non fonctionnels


 Ils définissent les propriétés et les contraintes à respecter
par le système

Cours « GL-ACOO » ENSI


 p.ex. fiabilité, temps de réponse et besoins d’espace
mémoire.
 Ils peuvent concerner le processus de développement
 p.ex. l’usage d’un système AGL particulier
 p.ex. l’usage d’un langage de programmation particulier
 p.ex. l’usage d’une méthode de développement particulière
 Ils peuvent être plus critiques que les requis fonctionnels.
 S’ils ne sont pas respectés, le système est inutile
17
Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

2-Les Besoins

2.2 Besoins non fonctionnels


Classifications des Besoins non-fonctionnels :
Requis de produit

Cours « GL-ACOO » ENSI


: qui spécifie que le produit livré doit se
comporter d’une certaine façon p.ex. vitesse d’exécution, fiabilité,
etc.

Requis organisationnel : qui spécifie que le processus de


développement doit respecter certaines caractéristiques p.ex.
normes, requis d’implémentation, etc.

Requis externe : qui provient de facteurs qui sont externes au


produit et à son processus de développement p.ex. requis de
compatibilité, et requis législatif.
18
Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

2-Les Besoins

2.2 Besoins non fonctionnels


Besoins non fonctionnels

Cours « GL-ACOO » ENSI


sur le processus sur le produit externes

en en en en en
coûts utilisabilité efficacité fiabilité portabilité

en en en
livraison implémentation standards légaux en
interopérabilité
en en
performance taille
19
Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

2-Les Besoins

2.2 Besoins non fonctionnels


Buts Vs Besoins vérifiables

Cours « GL-ACOO » ENSI


 Un but est une intention générale de l’usager
 Les buts aident les développeurs parce qu’ils font ressortir les
intentions des usagers du système

 MAIS les Besoins non fonctionnels doivent être


vérifiables
♦ L’expression d’un BNF doit énoncer une unité de mesure
pour le vérifier et le tester objectivement 20
Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

2-Les Besoins

Exemple
Un but de système

Cours « GL-ACOO » ENSI


♦ 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 vérifiable


♦ 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 jours. 21
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
Nombre de puces électroniques
des 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 22
Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

2-Les Besoins
 2.3 Les Besoins du domaine
 Ils so nt dérivés d u do maine d ’a pplica tio n, ils dé crive nt les ca racté ristique s
et les foncti ons du système qui reflè tent le doma ine
 Ils peuvent être des nouveaux requis fonctio nnels ou des contra inte s
 Si le s re quis de d o maines ne sont pas re spe ctés, le systè me pe ut ne pa s ê tre

Cours « GL-ACOO » ENSI


utilisable
 Exemple : Requis du doma ine du systè me de bibliothè q ue
 Il doit y avoir un int er fa ce usage r st anda rd à toute s les ba se s de d o nnées qu i
sera basé sur la norme Z39.50.
 E n raiso n d e s re st ri ctio ns de co pyrig ht , cer tains do cume nts de vro nt ê tre
effacé s imméd iate me nt sur r éce ption. Dé pe nda mment d es re quis de l’usa ge r,
ce s do cume nt s ser ont soit imprimé s lo ca leme nt sur le se rve ur du systè me
po ur ê tre e nvoyé ma nuell eme nt à l’usa ge r o u est ache miné ve r s une
imprimante réseau
 Exemple : Systè me de protectio n de train
La décé léra tio n d ’un tr ain se ra calc ulé co mme suit: Dtra in = Dcontr ol +
Dg radie nt où Dg radie nt est 9.8 1ms2 * com pe nsé se lon le gra die nt/alpha e t
où le s valeur s de 9 .81 ms2 / alpha so nt con nus po ur différe nts types de
tra ins. 23
Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

2-Les Besoins

2.3 Les Besoins du domaine


Problèmes avec les besoins du domaine

 Manque de clarté

Cours « GL-ACOO » ENSI


♦ La précision est difficile à obtenir

 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 24
Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

2-Les Besoins

2.3 Les Besoins du domaine


Problèmes avec les besoins du domaine

 Compréhension

Cours « GL-ACOO » ENSI


 Les requis sont exprimés dans la langue d’application du
domaine, ceci est souvent non compris par les développeurs
du système

Implicite
 Les spécialistes du domaine comprennent ce domaine si bien qu’ils
ne pensent pas à rendre les requis de domaine explicites

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

3-Analyse des Besoins

Le but est de définir ce que le système (à développer)


doit faire (le quoi) sans se préoccuper de la façon

Cours « GL-ACOO » ENSI


dont il doit le faire (le comment).

Le résultat de l’analyse des besoins est le document


d’analyse et de spécifications.

26
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écification
Validation
Et spécification

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

3-Analyse des Besoins

1. Expression des besoins


Participants: analyste, client et utilisateurs.
Document: cahier des charges

Cours « GL-ACOO » ENSI


Rédigé par: le client en collaboration avec l’analyste.
En langue naturelle.
Découpage: en paragraphes exprimant clairement les buts, les besoins et les
contraintes.
2. Spécification et modélisation des besoins
Participants: analyste
Document: dossier d’analyse et de spécification
Rédigé par: l’analyste.
Notation graphique ou textuelle rigoureuse.
Découpage: modèles statique, fonctionnel et comportemental.

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

3-Analyse des Besoins

 Expression des besoins


 Détermination
Cahier

Cours « GL-ACOO » ENSI


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

Méthodes
• Entrevue avec clients
• Questionnaires
• Observation
• Étude de l’existant (documents/logiciels)
• Brainstorming
• Prototypage, etc. 29
Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

3-Analyse des Besoins


 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, …)
Numéroter les besoins et construire une matrice:
identification des paires de besoins:
conflictuels: discussion/négociation avec le client
se recoupant: reformulation.

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

3-Analyse des Besoins


 Expression des besoins
 Négociation

Cours « GL-ACOO » ENSI


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

Évaluation du risque associé aux besoins et évaluation de leur priorité


Quels sont les besoins susceptibles de causer des problèmes pendant le développement???
risques techniques, risques de performance, de sécurité, d'intégrité de la BD, risques de
volatilité (besoins qui changent durant développement)
Priorité:

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

3-Analyse des Besoins


 Expression des besoins
 Gestion des besoins
Cahier
des
Détermination Validation & Gestion Charges

Cours « GL-ACOO » ENSI


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
 Exemple:
B1. Le programme doit planifier les activités de l’ascenseur de façon efficace et raisonnable.
B 1.1. Si l’ascenseur ne contient pas de passager, il devrait demeurer au rez-de-chaussée en attendant la
prochaine requête.
B 1.2. L’ascenseur ne devrait pas modifier le sens de son déplacement s’il contient des passagers qui n’ont
pas encore atteint leur destination.
B 1.3 ….

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

3-Analyse des Besoins

 Le Cahier des Charges (CC)

Un CC doit :

Cours « GL-ACOO » ENSI


 spécifier uniquement les comportements externes
(le quoi non le comment) du système

 spécifier les contraintes de réalisation

 être facile à mettre à jour

 servir de référence à la maintenance

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

3-Analyse des Besoins

 Un CC doit comporter :
I. Fondements du projet :

Cours « GL-ACOO » ENSI


1. But du projet

a. Problème de l’utilisateur ou contexte du


projet

b. Objectifs du projet

2. Personnes et organismes impliqués dans les


enjeux du projet

3. Utilisateurs du produit
34
Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

3-Analyse des Besoins

II. Exigences fonctionnelles :


Les exigences formulées dans un CC peuvent être

Cours « GL-ACOO » ENSI


regroupées suivant différents critères:
♦ Même catégorie de réponses du système
♦ Même catégorie d’utilisateurs du système
♦ Même type de fonctions du système
♦…

Dans la pratique, on procède à une combinaison de


plusieurs critères.

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

3-Analyse des Besoins

III.Exigences non fonctionnelles :


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

Cours « GL-ACOO » ENSI


et technologique 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 36
Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

3-Analyse des Besoins

Caractéristiques d'un cahier des charges

Non-ambiguë Réalisable

Cours « GL-ACOO » ENSI


Complet Modifiable
Vérifiable Indépendant de la
Cohérent conception

Compréhensible par le Concis


client Organisé

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

3-Analyse des Besoins

Cahier des charges (conseils à suivre)


Langue naturelle… mais technique :
♦ Faire des phrases courtes

Cours « GL-ACOO » ENSI


♦ Éviter les termes ambigus ou subjectifs
♦ Parler en termes de rôle plutôt que de personnes
♦ Utilisation de références précises
Utiliser un format standard pour le CC
Utiliser le langage de façon cohérente. Utiliser ‘doit
…’ pour les requis obligatoires et ‘peut …’ pour les
requis désirables
Organiser les besoins (hiérarchiser des besoins…) 38
Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

4- Exemple d’un standard


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

Cours « GL-ACOO » ENSI


1. Introduction
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 39
Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

4- 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

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

4- 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

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

4- 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

Cours « GL-ACOO » ENSI


est 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
42
Cours
Chapitre 3 « Génie Logiciel 1 »
Analyse des besoins Niveau II2

4- 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

Cours « GL-ACOO » ENSI


exigences et au testeur de 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 43
Cours
C h a pi t re 3 :
E x p r e s s io n d e s b e s o i ns & S p é c i f i c a t i o n « Génie Logiciel 1 »
Niveau II2

Plan

Cours « GL-ACOO » ENSI


Partie II : Spécification des besoins

44
Cours
C h a pi t re 3 :
E x p r e s s io n d e s b e s o i ns & S p é c i f i c a t i o n « Génie Logiciel 1 »
Niveau II2

Spécification 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écification
Validation
Et spécification

45
Cours
C h a pi t re 3 :
E x p r e s s io n d e s b e s o i ns & S p é c i f i c a t i o n « Génie Logiciel 1 »
Niveau II2

Spécification des Besoins

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


•Les données du système (vue statique)
•Les fonctions du systèmes (vue fonctionnelle)
•Les changements d’états et le contrôle du système (vue comportementale)
Les styles de spécifications

Cours « GL-ACOO » ENSI


Nature des aspects décrits
Spécification statique :
On décrit ce qui ne change pas dans le système, format des données, propriétés
des fonctions Ex: modèle E-A, DFD,…
Spécification dynamique :
On décrit ce qui change dans le système : les états, les réactions aux
événements Ex : réseaux de Pétri, ...
Le degré de formalisation
 spécification informelles : basée sur le langage naturel (selon un plan type, le
glossaire, présentation formatée…)
 spécification semi-formelles : basée sur un langage structuré graphique et textuel
(dont la sémantique est faible) Exemple : SA, SADT, USE-CASES, ...
 spécification formelles : basée sur un langage formel dont le vocabulaire, la
syntaxe et la sémantique sont formels: Spécifications algébriques, Spécifications
basées sur des modèles mathématiques
46
Cours
C h a pi t re 3 :
E x p r e s s io n d e s b e s o i ns & S p é c i f i c a t i o n « Génie Logiciel 1 »
Niveau II2

Spécification 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écification
Validation
Et spécification

47
Cours
C h a pi t re 3 :
E x p r e s s io n d e s b e s o i ns & S p é c i f i c a t i o n « Génie Logiciel 1 »
Niveau II2

1-La modélisation

Qu’est ce qu’un modèle?


 Un mo d è l e e s t
♦ une représentation théorique d'une réalité restreinte de la nature

Cours « GL-ACOO » ENSI


 I l a p o u r u t i l it é d e
♦ décrire, d'interpréter et de prévoir des événements dans le cadre de cette réalité
♦ Exemple : le modèle atomique permet de décrire des phénomènes chimiques, mais pas
la gravité
 P o u rq uoi mo d él i s er ?
♦ Les modèles permettent de mieux comprendre le système que l’on développe
(maîtriser sa complexité)

48
Cours
C h a pi t re 3 :
E x p r e s s io n d e s b e s o i ns & S p é c i f i c a t i o n « Génie Logiciel 1 »
Niveau II2

1-La modélisation

Les quatre principes de modélisation


1. Le choix des modèles à créer a une forte influence sur la
manière d’aborder un problème et sur la nature de sa solution.

Cours « GL-ACOO » ENSI


2. Tous les modèles peuvent avoir différents niveaux de
précision.
3. Les meilleurs modèles ne perdent pas le sens de la réalité.
4. Parce qu’aucun modèle n’est pas suffisant à lui seul, il est
préférable de décomposer un système important en un
ensemble de petits modèles presque indépendants.

49
Cours
C h a pi t re 3 :
E x p r e s s io n d e s b e s o i ns & S p é c i f i c a t i o n « Génie Logiciel 1 »
Niveau II2

2-Les styles de spécification

Le degré de formalisation :
informel : basée sur le langage naturel

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
Spécifications algébriques, axiomatique, …

50
Cours
C h a pi t re 3 :
E x p r e s s io n d e s b e s o i ns & S p é c i f i c a t i o n « Génie Logiciel 1 »
Niveau II2

2-1 Spécification informelle

 Malheureusement, ces spécifications sont sujets à


des mécompréhensions:

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, ce qui complique la
recherche d’information.

51
Cours
C h a pi t re 3 :
E x p r e s s io n d e s b e s o i ns & S p é c i f i c a t i o n « Génie Logiciel 1 »
Niveau II2

2-1 Spécification informelle

Exemple :
La vérification de la validité de la carte consiste à vérifier que la carte

Cours « GL-ACOO » ENSI


introduite par un utilisateur provient d'une 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.

52
Cours
C h a pi t re 3 :
E x p r e s s io n d e s b e s o i ns & S p é c i f i c a t i o n « Génie Logiciel 1 »
Niveau II2

2-2 Spécification semi-informelle

On fixe :
 des patrons,

Cours « GL-ACOO » ENSI


 des modèles de fiches,
 et des formulations,
dont le sens est explicité de la façon la moins ambiguë possible dans
une partie initiale de la spécification.
La suite de la spécification (raffinement) doit s’appuyer sur ces
constructions.

53
Cours
C h a pi t re 3 :
E x p r e s s io n d e s b e s o i ns & S p é c i f i c a t i o n « Génie Logiciel 1 »
Niveau II2

2-2 Spécification semi-informelle

 Notation graphique :
 des diagrammes, annotés généralement par un texte en langage

Cours « GL-ACOO » ENSI


structuré, représentent le système.

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.

54
Cours
C h a pi t re 3 :
E x p r e s s io n d e s b e s o i ns & S p é c i f i c at i o n « Génie Logiciel 1 »
Niveau II2

2-2 Spécification semi-informelle

Cours « GL-ACOO » ENSI


55
Cours
C h a pi t re 3 :
E x p r e s s io n d e s b e s o i ns & S p é c i f i c a t i o n « Génie Logiciel 1 »
Niveau II2

2-3 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.

Avantage :
 automatisation
 Inconvénients :
 nécessite une certaine qualification du client, utilisateurs et développeurs

56
Cours
C h a pi t re 3 :
E x p r e s s io n d e s b e s o i ns & S p é c i f i c at i o n « Génie Logiciel 1 »
Niveau II2

2-3 Spécification formelle

 Exemple: Logiciel pour commander un ascenseur

Cours « GL-ACOO » ENSI


57
Cours
C h a pi t re 3 :
E x p r e s s io n d e s b e s o i ns & S p é c i f i c a t i o n « Génie Logiciel 1 »
Niveau II2

3- Les approches de spécification

 Toute approche de spécification aura pour but de décrire


avec rigueur :

Cours « GL-ACOO » ENSI


 Les composants ou les éléments du système (vue
structurelle)
 Les fonctions du systèmes (vue fonctionnelle)
 Les changements d’états du système (vue
comportementale)

58

Vous aimerez peut-être aussi