GL2023Chap5 Spécification

GI 21
CHAP 5 :
SPÉCIFICATION
Analyse et spécification: méthodes et
techniques
GI 21 Meriem Zaoui – Génie Logiciel - Chap5 2
Un problème de communication
✓ Expertise, jargon du domaine
Client
✓ 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
Développeur
✓ Spécifications souvent
incompréhensibles pour les non
initiés.
Analyse et Spécification des besoins
• L’une des étapes les plus importantes

• déterminante pour la suite
• sert à la définition des aspects contractuels (contrat, délai,
coût,etc.)
• L’une des étapes les plus difficiles

• intervenants multiples : client, utilisateurs, développeurs…
• le problème n’est pas encore formalisé
• Règle d’or à respecter : Les informaticiens sont aux

services du client, pas l’inverse
« La partie la plus difficile de la spécification des besoins

n’est pas de documenter ce que les utilisateurs veulent; il
s’agît plutôt de l’effort pour aider ceux-ci à déterminer ce
dont ils ont besoin qui peut leur être fourni avec succès »
Steve McConnell (Software Project Survival Guide, Microsoft Press)
Les besoins ?
• Quelle est la différence entre les types suivants

de besoins?
• Besoins d’affaires
• Besoins fonctionnels
• Besoin non-fonctionnels
Besoins ?
Besoins d’affaires:
Représentent des objectifs haut niveau d’une entreprise qui
justifient la nécessité de développer ce nouveau projet
• Ex: augmenter le taux de réponse aux campagnes de marketing
ciblées.
Besoins fonctionnels:
Dérivent des besoins d’affaires, c’est-à-dire expriment une action
que doit effectuer le système en réponse à une demande
• Ex: produire automatiquement un rapport de synthèse des ventes
hebdomadaires.
Besoins non fonctionnels:
Décrivent des qualités que le système doit avoir
• Ex: utilisabilité, performance, disponibilité/fiabilité, sécurité, etc.
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, celui pour descendre (resp.
monter).
• etc.
Selon IEEE 610.12, une exigence est :
• Une condition ou une capacité nécessaire à un
utilisateur pour résoudre un problème ou atteindre
un objectif
• Une condition ou une capacité que doit posséder un
système afin de satisfaire aux termes d'un contrat,
d’une norme ou d’une spécification formellement
imposée.
• La représentation documentée de cette condition ou
capacité.
Selon IEEE 830, une spécification d’exigences comprend :
• Les fonctionnalités : services et fonctions que le système
doit fournir.
• Les interfaces externes : identification des interactions
avec les utilisateurs et les autres systèmes avec lesquels le
nouveau système doit s'intégrer.
• La performance : contraintes d'opération du système en
disponibilité et en temps réponse.
• Les attributs du système : caractéristiques telles que la
portabilité, l'exactitude, la maintenabilité, la sécurité, etc.
• Les contraintes de conception: contraintes sur la façon de
développer le système.
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é
Catégories de besoins
• Besoins fonctionnels : ils expriment les fonctionnalités concrètes
du produit
• description des services (fonctions).

• description des données manipulées
• "Comment souhaite-on pouvoir utiliser le système?".
• Besoins non fonctionnels : ceux sont des indicateurs de qualité de

l’exécution des besoins 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.
Catégories de besoins
Besoins fonctionnels Besoins non fonctionnels
• Ils expriment une action que
• Besoin d’utilisabilité
doit effectuer le système en
réponse à une demande • Besoins de performance
• Besoins de
• Ex : Le système doit produire
disponibilité/fiabilité
automatiquement un rapport • Besoins de sécurité
de synthèse des ventes • Besoins matériels
hebdomadaires. • Besoins de déploiement
• NB : Chercher des critères

mesurables
Besoins non fonctionnels

Besoins d’utilisabilité (Usability)
• Ils font référence aux aspects généraux de l’interface
utilisateur
• Exemple : standard utilisé, capacité pour un user d’exécuter une tâche
après une formation, définition de la configuration minimale du
navigateur (Compatible avec le protocole de sécurité SSL; Accepte les témoins (cookies); etc.)
Besoins de performance
• Décrivent les performances d’exécution du système,
généralement en termes de temps de réponse.
• Exemple : (application Web) Temps de chargement d’une page :
Le chargement d’une page Web dans le navigateur ne devrait pas
prendre plus de 15 secondes en condition normale.

Besoins de disponibilité/fiabilité
• Le niveau de disponibilité qui doit être explicitement
défini pour les applications critiques
• Exemple : exigence de disponibilité 24/24, 7/7 sauf période de
maintenance (à spécifier…)
Besoins de sécurité
• Peuvent définir les niveaux d’accès possibles au système pour
les utilisateurs du système et les systèmes externes.
• Exemple : Toute information confidentielle fournie par les clients
via l’Internet sera cryptée avec le système XYZ ou par
l’algorithme, la méthode….

Besoins matériels
• Définissent les configurations matérielles minimales
nécessaires au fonctionnement du système
• Exemple : Pentium, 5G, carte graphique, résolution…
Besoins de déploiement
• Décrivent la façon dont l’application sera livrée à l’utilisateur
final
• Exemple : Tous les logiciels du côté client vont être téléchargés
et installés à partir du navigateur, sans que le poste du client ne
soit redémarré ou configuré manuellement
Besoins non
fonctionnels
Besoins non fonctionnels MESURABLES

• Besoin exprimé par l’utilisateur
Le système doit être facilement utilisé par des contrôleurs expérimentés
et il doit être organisé de telle façon que le nombre d’erreurs soit
minimisé.
• Besoin non fonctionnels vérifiable

Les contrôleurs expérimentés doivent être capables d’utiliser le système
après 2 heures de formation.
Après cette formation le nombre moyen d’erreurs faites par un utilisateur
expérimenté ne doit pas dépasser 2 par jour.
Besoins non fonctionnels MESURABLES

Propriété Mesure
Nombre de transactions par seconde
Vitesse Temps de réaction
Temps pour rafraichir l’écran
Taille MBytes, GBytes,…
Temps nécessaire pour la formation
Facile à utiliser
Nombre d’écrans ou pages d’aide
Temps moyen sans panne
Fiabilité
Disponibilité
Temps de restart après une panne
Robustesse
Probabilité de perte ou de corruption des données
Pourcentage de instructions qui sont « machines
Portabilité dépendantes »
Nombre de systèmes cibles
Caractéristiques des besoins

• Corrects
• Clairs, sans ambiguïtés.
• Cohérents
• Complets (complétude interne et externe)
• Réalistes
• Pertinents pour le client
• Vérifiables
• «Traçables»
Processus d’analyse des besoins

A. Expression des besoins
Détermination Validation et Gestion des Cahier des

des besoins négociation besoins charges
B. Spécification des besoins
Documents
Modélisation et
Validation d’analyse et de
spécification
spécification
A // B ou A puis B
Processus d’analyse 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.
B. 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.
1-Détermination 2-Validation et 3- Gestion des Cahier des

1. Détermination des besoins
Méthodes traditionnelles :
• Entrevue avec clients et experts du domaine

• Questionnaires (accompagnent généralement l’entrevue)
• Observation (passive ou active) : observer l’exécution des
tâches des utilisateurs que le futur système devra assurer.
• Étude des documents et des systèmes logiciels existants
Méthodes actuelles :
a. Prototypage
Maquette démonstrative, première étude de faisabilité.
Identification des besoins conflictuels, omis ou mal saisis.
• Prototype jetable:
• Pour évaluer des solutions.
• L’attention est portée sur les besoins les moins bien compris.
• Prototype évolutif:
• Raffiné pour produire des versions intermédiaires jusqu’au
produit final.
• L’attention est portée sur les besoins les mieux compris.
Méthodes actuelles (suite)

b. Développement conjoint d'application (JAD : Joint
Application Development)
• L’approche préconise une phase d’analyse par ateliers

courts, souvent organisée par une firme de consultants.
• => Série d'ateliers/réunion de travail auxquelles
participent clients et développeurs (workshop)
• Participants: chef modérateur, secrétaire,
client/utilisateurs, développeurs.
Méthodes actuelles (suite)

c. 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.
3. Description détaillée des scénarios d’exécution de chaque cas
d’utilisation.
Sources à consulter
• Description de la situation actuelle

• Modèles du domaine
• Composants réutilisables et politiques de réutilisation
• Documentation existante
• Systèmes et organisations existants
• Besoins exprimés par les parties (clients, utilisateurs)
2. Validation & négociation

Les besoins répondent-ils aux exigences du client ?
• Réviser la liste des besoins en vérifiant s’ils 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.
2. Validation & Négociation
Les besoins répondent-ils aux exigences du client ?
• Démontrer que les besoins définissent le système désiré par le

client (Les erreurs sont trop chères)
• Propriétés qui doivent être vérifiées :
✓Validité : Sont-ils les mieux adaptées aux besoins du client?
✓Consistance : Y a-t-il des confits entres les besoins?
✓Totalité : Toute fonction est présente? (NB : ce qui n’est pas écrit,
n’existe pas)
✓Réalisable : Est-ce qu’on peut les développer?
✓Vérifiable : Peut-on les vérifier?
A. 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 œuvre par matériel hardware
• inadéquation de la technologie existante
• etc.
NB : Le diagramme de contextes modélise le périmètre d’un projet. Il

montre :
• les acteurs,
• les flux d’information avec les autres applications internes et les systèmes externes,
• Exemple :
B. Elimination des besoins

conflictuels et se recoupant
b1 b2 b3
• Numéroter les besoins et construire la
matrice. OK C
b1
• Identification des paires de besoins :
✓ Conflictuels => R
b2
discussion/négociation avec le
client
b3
✓ Se recoupant => reformulation.
32
C. Evaluation du risque associé aux besoins et évaluation

de leur priorité
• Risques : Quels sont les besoins qui pourraient causer des

problèmes pendant le développement?
• risques techniques, risques de performance, de sécurité,
d'intégrité de la BD, risques politiques/légaux, risques de
volatilité (besoins qui changent durant le développement)
• Priorité: 1. Essentiel
2. Utile
3. Difficile
4. À décider
3. Gestion des besoins
• Identification et classification des besoins dans le

cahier des charges
• identificateur unique (manuel ou automatique par BD)
• numérotation séquentielle
• numérotation séquentielle avec catégories
• 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...
3. 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.
• …
NB : Les besoins doivent être compris par tous ➔ langage naturel +

phrases courtes et simples + utiliser des schémas si nécessaire
3. Gestion des besoins
Gestion des modifications et traçabilité

Lorsqu’une exigence est changée, comment facilement retracer les documents,
modèles et les parties de code à modifier?
• Modifications facilitées par l’utilisation d'un outil de gestion de

configuration qui 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.
Doc : Cahier des charges

• C’est le document principal. Il doit contenir

• Les besoins d’utilisateur
• Les spécifications des besoins
• Objectif
• Base de contrat
• Base de conception et développement
• Pour le client : description précise de ce qui sera réalisé
• permet d'anticiper la mise en exploitation
• Pour les développeurs : référence précise et non ambiguë
• De ce qu'il s'agit de réaliser
• De ce qu'il s'agit de tester
Doc : Cahier des charges

• IEEE structure standard
• Introduction.
• Description générale.
• Besoins : spécifications.
• Appendices.
• Index.
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
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
Cahier des charges
4. Eléments du projet
4.1 Planning préliminaire
4.2 Budget préliminaire
Appendices
- Glossaire
- Documents et formulaires d'entreprise
- Références bibliographiques
B. Analyse et Spécification des besoins

B. Spécification des besoins
1- Modélisation et Documents d’analyse

2- Validation
spécification et de spécification
1. Modélisation et 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)
• Les interfaces IHM du système
1. Modélisation et Spécification
La spécification aura pour but de décrire avec rigueur :

• les données du système :
• dictionnaire de données, diagramme de classe, etc.
• les fonctions du système :

• diagramme de cas d’utilisation, diagramme de séquence
• les changements d’états et le contrôle du système

• diagramme d’états, diagramme d’activité
• les interfaces IHM du système :

• Maquette d’IHM (jetable)
Styles de spécification
Degré de
formalisme Nature des
Trois axes de classification aspects décrits
Style des
1. Degré de formalisme énoncés
• Spécifications informelles
• 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.
2. Style des énoncés
• Spécifications opérationnelles
• Tout en décrivant le « quoi ? », on suggère aussi le
« comment ».
• Ex: Diagramme d’activité, réseau de Petri, DFD(Data Flow
Diagram), etc.
• Spécifications descriptives.
• Description des propriétés désirées
• Ex: Diagramme de classe, Modèles E.-A., spéc. logiques, etc.
3. 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: Diagramme de classe, Modèle E.-A (Entités Associations),
etc.
• Spécifications dynamiques
• On décrit ce qui change dans le système: les états, les
réactions aux stimuli.
• Ex: Diagramme d’état, diagramme de séquence, réseaux de
Petri, tables de décision, etc.
Spécification
2. Validation
3. Sortie : Générer le document d’analyse et de

spécification
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. C’est un modèle raffiné, moins abstrait que le
modèle d’affaires. Il 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.
• NB : Les modèles de conception et d’implémentation seront des raffinements du

modèle d’analyse et comporteront de nouveaux diagrammes.
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 Modèle de
(vue statique
(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
BILAN
• Qualités du dossier d'analyse

• précis, cohérent, complet, argumenté, traçable, flexible
• Extrême importance du modèle conceptuel

• image mentale : concepts, objets, attributs, opérations
• Représentations graphiques semi-formelles

• synthétiques, normalisées, non ambiguës
• des diagrammes différents pour des usages différents
• Ne pas oublier :
• + aspects non fonctionnels
Conclusion
• La notion de spécification recouvre différents aspects en fonction

du point de vue adopté sur le système.
• Définir une spécification, c’est expliciter des besoins de la façon la
plus méthodique, complète et cohérente possible.
• Une spécification se développe, se vérifie, et évolue.
• Elle se concrétise sous la forme d’un cahier des charges qui

dirigent la conception du système et sert de contrat entre les
différentes parties.

GL2023Chap5 Spécification

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

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 :

Formats disponibles

GL2023Chap5 Spécification

Transféré par

Droits d'auteur :

Formats disponibles

GI 21

Analyse des besoins:

Analyse et Spécification des besoins

• L’une des étapes les plus importantes

• L’une des étapes les plus difficiles

• Règle d’or à respecter : Les informaticiens sont aux

« La partie la plus difficile de la spécification des besoins

• Quelle est la différence entre les types suivants

• Besoin («requirement») = exigence que le système

• Exemples: Système de contrôle d’un ascenseur

• description des services (fonctions).

• Besoins non fonctionnels : ceux sont des indicateurs de qualité de

• description des contraintes

• NB : Chercher des critères

Besoins non fonctionnels

Besoins non fonctionnels

Besoins non fonctionnels

Besoins non fonctionnels

Besoins non fonctionnels MESURABLES

• Besoin non fonctionnels vérifiable

Besoins non fonctionnels MESURABLES

Caractéristiques des besoins

Processus d’analyse des besoins

Détermination Validation et Gestion des Cahier des

B. Spécification des besoins

Processus d’analyse des besoins

A. Expression des besoins

1-Détermination 2-Validation et 3- Gestion des Cahier des

1. Détermination des besoins

• Entrevue avec clients et experts du domaine

1. Détermination des besoins

1. Détermination des besoins

Méthodes actuelles (suite)

• L’approche préconise une phase d’analyse par ateliers

1. Détermination des besoins

Méthodes actuelles (suite)

Description des scénarios d’utilisation du logiciel

1. Identification des services (cas d’utilisation) offerts par le

1. Détermination des besoins

• Description de la situation actuelle

2. Validation & négociation

• Réviser la liste des besoins en vérifiant s’ils sont complets,

2. Validation & Négociation

Les besoins répondent-ils aux exigences du client ?

• Démontrer que les besoins définissent le système désiré par le

2. Validation & Négociation

A. Elimination des besoins non pertinents ou irréalistes

NB : Le diagramme de contextes modélise le périmètre d’un projet. Il

2. Validation & Négociation

B. Elimination des besoins

2. Validation & Négociation

C. Evaluation du risque associé aux besoins et évaluation

• Risques : Quels sont les besoins qui pourraient causer des

3. Gestion des besoins

• Identification et classification des besoins dans le

• Hiérarchisation des besoins

3. Gestions des besoins

NB : Les besoins doivent être compris par tous ➔ langage naturel +

3. Gestion des besoins

Gestion des modifications et traçabilité

• Modifications facilitées par l’utilisation d'un outil de gestion de

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

Doc : Cahier des charges