Sommaire

Chapitre 2, Section 2
« Analyse et spécification: méthodes et
techniques »

2.2.1 Les besoins (exigences)

2.2.2 Processus d’analyse des besoins
2.2.2.1 Expression des besoins
… Détermination des besoins
… Négociation et validation
… Gestion des besoins
… Cahier des charges

2.2.2.2 Spécification des besoins

… Styles de spécifications

Chap.2, Sect.2, p.2

 Un problème de communication
• Expertise, jargon du domaine
• Indécis, opinion changeant
selon l’offre
• Besoins ambigus, éléments
manquants

Analyse des besoins:

souvent
incomplète et imprécise

• Schémas
• Langages formels
• Spécifications souvent
incompréhensibles pour les
non initiés.

Chap.2, Sect.2, p.3

Chap.2, Sect.2, p.4
 2.2.1 Besoins (exigences)
„ Besoin («requirement») = exigence que le
système devrait satisfaire.

„ Exemples: 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).
… etc.

Chap.2, Sect.2, p.5

 Catégories de besoins
„ Besoins fonctionnels
… description des services (fonctions).
… description des données manipulées
… "Comment souhaite-on pouvoir utiliser le système".
„ Besoins non fonctionnels
… description des contraintes
… Pour chaque service et pour le système global, il est
possible d’exprimer différents types de contraintes:
„ contraintes de performance
„ contraintes de sécurité
„ contrainte de convivialité et d'apparence
„ Etc.

Chap.2, Sect.2, p.6

 Types de besoins
Les besoins peuvent traduire des exigences
concernant

„ L’environnement physique
„ Les interfaces
„ Les humains et utilisateurs
„ Les fonctionnalités
„ La documentation
„ Les données
„ Les ressources
„ La sécurité
„ L’assurance de la qualité

Chap.2, Sect.2, p.7

 Caractéristiques des besoins
„ Corrects
„ Clairs, sans ambiguïtés, intelligibles.
„ Cohérents
„ Complets (complétude interne et externe)
„ Réalistes
„ Pertinents pour le client
„ Vérifiables
„ «Traçables»

Chap.2, Sect.2, p.8

 2.2.2 Processus d’analyse des
besoins
A. Expression des besoins

Détermination
Cahier
des validation & Gestion des
besoins négociation des besoins charges
(«elicitation»)

B. Spécification des besoins

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

A // B ou A;B
Chap.2, Sect.2, p.9
 Processus d’analyse des besoins
„ 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.
„ Spécification de 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.

Chap.2, Sect.2, p.10

 2.2.2.1 Expression des besoins
A. Expression des besoins

1. Détermination
4. Cahier
des 2. Validation & 3. Gestion des
besoins négociation des besoins charges
(« elicitation »)

B. Spécification des besoins

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

Chap.2, Sect.2, p.11

 •Détermination des besoins

Détermination
Cahier
des validation & Gestion des
besoins négociation des besoins charges
(elicitation)

Chap.2, Sect.2, p.12

 Détermination des besoins
1. Méthodes traditionnelles

„ Entrevue avec clients et experts du domaine

„ Questionnaires (accompagnent généralement
l’entrevue)
„ Observation (passive ou active)
„ Étude des documents et des systèmes
logiciels existants

Chap.2, Sect.2, p.13

 Détermination des besoins
2. Méthodes actuelles
„ Prototypage
… Maquette démonstrative, première étude de
faisabilité.
… Identification des besoins conflictuels, omis ou mal
saisis
… Prototype jetable:
„ Pour évaluer des solutions, puis jeté.
„ Attention portée sur les besoins les moins bien compris.
… Prototype évolutif:
„ Raffiné pour produire versions intermédiaires jusqu’au
produit final.
„ Attention portée sur les besoins les mieux compris.

Chap.2, Sect.2, p.14

 Détermination des besoins
Méthodes actuelles (suite)
„ Développement conjoint d'application
(Joint Application Development)
… Série d'ateliers/réunion de travail auxquelles
participent clients et développeurs (workshop)
… Souvent organisé par firme de consultants.
… Participants: chef modérateur, secrétaire,
client/utilisateurs, développeurs.
… Avantages?
… Pour plus d’info: (html ici)
http://www.umsl.edu/~sauter/analysis/JAD.html

Chap.2, Sect.2, p.15

 Détermination des besoins
Méthodes actuelles (suite)
„ Cas d’utilisation
Description des scénarios d’utilisation du logiciel
1. Identification des services (cas d’utilisation) offerts par le
système.
2. Identification des acteurs participant à chacun des cas
d’utilisation. Un acteur représente un rôle joué par une
entité (personne, machine, etc.) dans le système.
„ N.B. Un acteur est un rôle possiblement joué par plusieurs
entités. Une même entité peut tenir le rôle de plus d’un acteur.
3. Description détaillée des scénarios d’exécution de
chaque cas d’utilisation.

Exercice: Identifier les cas d’utilisation et les acteurs d’un guichet

bancaire automatique.

Chap.2, Sect.2, p.16

 Détermination des besoins
Sources à consulter

„ Description de la situation actuelle

„ Modèles du domaine
„ Composants réutilisables et politiques de réutilisation
„ Propositions des types de besoins à définir
„ Documentation existante
„ Systèmes et organisations existants
„ Besoins exprimés par les parties (clients, utilisateurs)

Chap.2, Sect.2, p.17

 •Négociation et validation

Détermination
validation & Cahier
des Gestion
négociation des
besoins des besoins charges
(elicitation)

Chap.2, Sect.2, p.18

 Validation & négociation
Les besoins répondent-ils aux exigences du client ?

„ Réviser la liste des besoins en vérifiant s’il sont

complets, cohérents, réalistes, pertinents, vérifiables,
traçables,…
„ Tout compromis doit être négocié avec le client.
„ Classer les besoins selon leur priorité et évaluer le
risque associé à chacun.

Chap.2, Sect.2, p.19

 Négociation et validation des
besoins
1. Elimination des besoins non pertinents ou
irréalistes
… Bien définir les frontières du système.
„ Construire un diagramme de contexte pour identifier les
entités externes, les entrées, les sorties.
„ Identifier les besoins qui ne répondent pas aux objectifs du
système, qui sont hors plan, etc.
… Faire la liste des besoins exclus pour cause de
„ trop grande difficulté de réalisation
„ mise en oeuvre par matériel hardware
„ inadéquation de la technologie existante
„ etc.

Chap.2, Sect.2, p.20

 Négociation et validation
2. Elimination des besoins
conflictuels et se
recoupant b1 b2 b3
„ Numéroter besoins et
construire matrice: b1 ok C
identification des paires
de besoins
R
… conflictuels: b2
discussion/négociation
avec le client
… se recoupant:
b3
reformulation.

Chap.2, Sect.2, p.21

 Négociation et validation
3. Evaluation 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 b.d., risques
politiques/légaux, risques de volatilité (besoins
qui changent durant développement)
„ Priorité:
1. Essentiel
2. Utile
3. Difficile
4. À décider
Chap.2, Sect.2, p.22
 •Gestion des besoins

Détermination
validation & Cahier
des Gestion
négociation des
besoins des besoins charges
(elicitation)

Chap.2, Sect.2, p.23

 Gestion des besoins
„ 1. Identification et classification des besoins
dans le cahier des charges
… identificateur
unique (manuel ou automatique par b.d)
… numérotation séquentielle
… numérotation séquentielle avec catégories

„ 2. Hiérarchisation des besoins

… Un besoin peut se composer d’un ou plusieurs sous-
besoins plus spécifiques, moins abstraits.
… On peut construire d'abord un modèle abstrait ne
considérant pas les sous-besoins...

Chap.2, Sect.2, p.24

 Gestions des besoins
„ Exemple.
… B1. Le programme doit planifier les activités de
l’ascenseur de façon efficace et raisonnable.
„ B1.1 Si l’ascenseur ne contient pas de passager, il devrait
demeurer au rez-de-chaussée en attendant la prochaine
requête.
„ B1.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.
„ …

„ Exemple d’un cahier de charge (html ici).

Chap.2, Sect.2, p.25

 Gestion des besoins
3. Gestion des modifications et traçabilité
Lorsqu’une exigence est changée, comment facilement retracer les documents,
modèles et bout de code à modifier?

Modifications facilitée par l’utilisation d'un outil de gestion de config.

„ Permet de tracer:
… Les besoins qui définissent ce que le système doit faire.
… Les modules de conception générés à partir des besoins
… Le code qui implémente la conception
… Les tests qui vérifient les fonctionnalités du système
… La documentation qui décrit le système

„ Gestion facilitée des versions et meilleure traçabilité lors des

changements.
„ Pour en savoir plus (html ici): http://linas.org/linux/cmvc.html

Chap.2, Sect.2, p.26

 •Cahier des charges

Détermination Validation & Gestion Cahier

des négociation des des
besoins besoins
charges

Voici un modèle de cahier des charges

(Il existe plusieurs modèles de cahier des charges (IEEE, ANSI, etc.))

1. Description générale du projet

1.1 Intention et portée du projet
1.2 Contexte d'entreprise (planification stratégique)
1.3 Parties prenantes
1.4 Idées de solution
1.5 Plan du document
Chap.2, Sect.2, p.27
 Cahier des charges
2. Services du système
2.1 Portée du système (diagramme de contexte)
2.2 Besoins fonctionnels
2.3 Besoins des données
(attributs, interrelations)

3. Contraintes du système
3.1 Contraintes d'interface
3.2 Contraintes de performance
3.3 Contraintes de sécurité
3.4 Contraintes opérationnelles
3.5 Contraintes politiques et légales

Chap.2, Sect.2, p.28

 Cahier des charges
4. Eléments du projet
4.1 Problèmes ouverts
4.2 Planning préliminaire
4.3 Budget préliminaire

Appendices
- Glossaire
- Documents et formulaires d'entreprise
- Références bibliographiques

Chap.2, Sect.2, p.29

 2.2.2.2 Spécification des besoins
A. Expression des besoins

Détermination
Cahier
des Validation & Gestion des
besoins négociation des besoins charges
(« elicitation »)

B. Analyse et spécification
Document
Modélisation d’analyse &
Validation
et spécification spécification

Chap.2, Sect.2, p.30

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

… les données du systèmes (vue statique)

… les fonctions du système (vue fonctionnelle)
… les changements d’états et le contrôle du
système (vue comportementale)

Chap.2, Sect.2, p.31

 Styles de spécification
Trois axes de classification
Degré de Nature des
formalisme aspects décrits
„ Degré de formalisme
… Spécifications informelles: Style des
énoncés
„ Ex. langue naturelle, croquis, etc.

… Spécifications semi-formelles
„ Notation graphique dont la sémantique n’est pas
formellement définie. Ex. UML
… Spécifications formelles.
„ Ex.: Spéc. algébriques, spéc. logiques, réseaux de Petri,
langages de programmation, etc.

Chap.2, Sect.2, p.32

 Styles de spécification
„ Style des énoncés
… Spécifications opérationnelles
„ Tout en décrivant le « quoi ? », on suggère aussi le « comment ».
„ Ex. Réseaux de Petri, DFD, FSM, etc.
… Spécifications descriptives.
„ Description des propriétés désirées
„ Ex. Modèles E.-A., spéc. logiques, etc.
„ Nature des aspects décrits
… Spécifications statiques:
„ 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. définitions axiomatiques, etc.
… Spécifications dynamiques
„ On décrit ce qui change dans le système: les états, les réactions
aux stimuli.
„ Ex. FSM, réseaux de Petri, tables de décision, etc.

Chap.2, Sect.2, p.33

 Analyse et spécification (UML)
Plan
Modèle d’affaires Modèle d’analyse de test

Modèle des Manuels utilisateurs

Modèle des
cas d’utilisation
cas d’utilisation
(vue comportementale)
du domaine d’affaires Planification
(business use cases)

Modèle
des interactions
Modèle définissant et des changements d’état
la portée du système (vue statique
Modèle de
(diag. de contexte & comportementale) conception

Modèle des classes Modèle des

du domaine d’affaires classes Modèle
(business classes) (vue statique)
d’implémentation

Chap.2, Sect.2, p.34

 Analyse et spécification (UML)
„ Modèle d’affaires (business modèle)
… Développé lors de la phase d’expression des besoins.
… Modèle sommaire et abstrait résumant les services et entités du domaine
d’affaires.
… S’intègre au cahier des charges.
„ Modèle d’analyse
… Développé lors de la phase d’analyse.
… Modèle raffiné, moins abstrait que le modèle d’affaires.
… S’intègre au document d’analyse et de spécification.
… Modélisation UML:
„ Identification des cas d’utilisation
… Description textuelle
… Diagramme de cas d’utilisation
„ Diagramme de classes (décrivant les entités du domaine)
„ Diagrammes de séquence et d’activités pour mieux comprendre les
scénarios des cas d’utilisation.
„ Diagrammes d’état pour illustrer le comportement de certains objets.
„ Les modèles de conception et d’implémentation seront des
raffinements du modèle d’analyse et comporteront de nouveaux
diagrammes.
Chap.2, Sect.2, p.35