Chap 3

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
Plan

Partie I : Expression des besoins
3
Cours
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 !

 « 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
1-Problématique
 Positionnement
Avant projet
Développement
Etude

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

6
Cours
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.

 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

8
Cours
2-Les Besoins
 Besoin (« requirement ») = exigence de ce

que le système devrait satisfaire

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

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

informaticiens, des décideurs, . . . ).
 interne (celui des concepteurs, des

développeurs, des personnels techniques, . . . )
11
Cours
2-Les Besoins
Trois types de besoins

Besoins fonctionnels
Besoins non fonctionnels
Besoins du domaine
12
Cours
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).

 "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
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

 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
2-Les Besoins
2.1 Besoins fonctionnels

Ils doivent être :

 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
2-Les Besoins
2.1 Besoins fonctionnels

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

♦ 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
2-Les Besoins
2.2 Besoins non fonctionnels

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

 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
2-Les Besoins

Classifications des Besoins non-fonctionnels :
Requis de produit

: 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
2-Les Besoins

Besoins non fonctionnels

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
2-Les Besoins

Buts Vs Besoins vérifiables

 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
2-Les Besoins
Exemple
Un but de système

♦ 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
Vitesse Transactions traitées par seconde
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

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

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
2-Les Besoins
2.3 Les Besoins du domaine

Problèmes avec les besoins du domaine
 Manque de clarté

♦ 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
2-Les Besoins
2.3 Les Besoins du domaine

Problèmes avec les besoins du domaine
 Compréhension

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

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
Le processus d’analyse des besoins

A. Expression des besoins

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
1. Expression des besoins

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

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
 Expression des besoins

 Détermination
Cahier

des
Charges
Méthodes
• Entrevue avec clients
• Questionnaires
• Observation
• Étude de l’existant (documents/logiciels)
• Brainstorming
• Prototypage, etc. 29
Cours

 Validation

Cahier
des
Charges
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

 Négociation

Cahier
des
Charges
É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

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

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
 Le Cahier des Charges (CC)
Un CC doit :

 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
 Un CC doit comporter :
I. Fondements du projet :

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
II. Exigences fonctionnelles :

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

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
III.Exigences non fonctionnelles :

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

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
Caractéristiques d'un cahier des charges
Non-ambiguë Réalisable

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

client Organisé
37
Cours
Cahier des charges (conseils à suivre)

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

♦ É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
4- Exemple d’un standard

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

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
2. Description générale du produit

2.1. Perspective du produit

 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

2.2. Vue d’ensemble des fonctionnalités
 décrire brièvement les fonctions essentielles du produit

 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

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

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

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

Partie II : Spécification des besoins
44
Cours
C h a pi t re 3 :
Niveau II2
Spécification des Besoins


Cahier
des
Charges
Document
d’analyse &
Validation
Et spécification
45
Cours
C h a pi t re 3 :
Niveau II2
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

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 :
Niveau II2


Cahier
des
Charges
Document
d’analyse &
Validation
Et spécification
47
Cours
C h a pi t re 3 :
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

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

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 :
Niveau II2
2-Les styles de spécification
Le degré de formalisation :
informel : basée sur le langage naturel

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 :
Niveau II2
2-1 Spécification informelle
 Malheureusement, ces spécifications sont sujets à

des mécompréhensions:

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 :
Niveau II2
2-1 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 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 :
Niveau II2
2-2 Spécification semi-informelle
On fixe :
 des patrons,

 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 :
Niveau II2
 Notation graphique :
 des diagrammes, annotés généralement par un texte en langage

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

55
Cours
C h a pi t re 3 :
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;

 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

57
Cours
C h a pi t re 3 :
Niveau II2
3- Les approches de spécification
 Toute approche de spécification aura pour but de décrire

avec rigueur :

 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

Langue

Chap 3

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Chap 3

Titre original :

Transféré par

Droits d'auteur :

Chapitre 3 Cours « Génie

Analyse des besoins

1. Partie I : Expression des besoins

Cours « GL-ACOO » ENSI

Cours « GL-ACOO » ENSI

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

Cours « GL-ACOO » ENSI

Cours « GL-ACOO » ENSI

Cours « GL-ACOO » ENSI

Cours « GL-ACOO » ENSI

Cours « GL-ACOO » ENSI

 Besoin (« requirement ») = exigence de ce

Cours « GL-ACOO » ENSI

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

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

Cours « GL-ACOO » ENSI

Il est essentiel de dissocier dans la description

Cours « GL-ACOO » ENSI

 interne (celui des concepteurs, des

Trois types de besoins

Cours « GL-ACOO » ENSI

Besoins non fonctionnels

 Besoins fonctionnels (exigences fonctionnelles)

Cours « GL-ACOO » ENSI

 2.1 Besoins fonctionnels

Cours « GL-ACOO » ENSI

2.1 Besoins fonctionnels

Cours « GL-ACOO » ENSI

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

2.1 Besoins fonctionnels

Cours « GL-ACOO » ENSI

2.2 Besoins non fonctionnels

Cours « GL-ACOO » ENSI

2.2 Besoins non fonctionnels

Cours « GL-ACOO » ENSI

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

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

2.2 Besoins non fonctionnels

Cours « GL-ACOO » ENSI

2.2 Besoins non fonctionnels

Cours « GL-ACOO » ENSI

 MAIS les Besoins non fonctionnels doivent être

Cours « GL-ACOO » ENSI

Un requis non fonctionnel vérifiable

Cours « GL-ACOO » ENSI

Robustesse Temps de redémarrage après échec

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

Cours « GL-ACOO » ENSI

2.3 Les Besoins du domaine

Cours « GL-ACOO » ENSI

 Confusion dans les requis

♦ Les requis fonctionnels et non fonctionnels tendent à se

♦ Plusieurs requis différents peuvent être exprimés

2.3 Les Besoins du domaine

Cours « GL-ACOO » ENSI

3-Analyse des Besoins

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

Cours « GL-ACOO » ENSI

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

3-Analyse des Besoins

Le processus d’analyse des besoins

Cours « GL-ACOO » ENSI

B. Spécification des besoins

3-Analyse des Besoins