Faculté des Sciences Économiques et de Gestion de Tunis
CHAPITRE2
Analyse et Spécification
des Besoins
2014-2015
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… »
05/04/2015
1
Les causes possibles
Le client ne sait pas toujours ce qu’il veut et n’exprime pas
toujours ses besoins clairement
L’informaticien ne comprend pas le client (et vice versa!)
Ce que le client demande n’est pas forcément ce dont il a besoin
Le client exprime souvent la solution à laquelle il pense et non son
besoin réel (ce 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
Les causes possibles
Difficultés de communiquer
difficulté d’être précis, cohérent, complet, etc.
différences de culture :
(cid:1) les utilisateurs ne sont pas des informaticiens…
(cid:1) les informaticiens ne connaissent pas le domaine …
Complexité du problème
problème non formalisé
problème complexe
Etc.
05/04/2015
2
Les Besoins
Besoins (Requirements) = exigences de ce que le système devrait
satisfaire
Exemple 1: Système de contrôle d’un ascenseur
B1. le système doit planifier les activités de l’ascenceur de
façon efficace et raisonnable
B2. le système doit illuminer l’indicateur panneau d’arrivée
correspondant à l’étage où l’ascenceur 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.
Les différents types de Besoins
Besoins fonctionnels
A quoi sert le système
Ce que doit faire le système, les fonctions et services
Description des données manipulées
Besoins non fonctionnels: une restriction ou une contrainte qui
pèse sur un service du système
Description des contraintes: sécurité, optimisation, convivialité
Pour chaque fonction et pour le système global, il est possible
d’exprimer différents types de contraintes
Besoins du domaine: relatifs à l’usage courant dans l’entreprise:
utilisation des normes internes de configuration, normes internes de
qualité, charte graphique, etc.
05/04/2015
3
05/04/2015
Analyse des Besoins
C’est
l’étude d’un domaine d’application pour engendrer
la
spécification d’un nouveau système
Son but est de définir ce que le système (à développer) doit faire (le
le faire (le
quoi) sans se préoccuper de la façon dont
comment)
il doit
Le
résultat de
le document de
spécifications (spécification fonctionnelle, cahiers des charges du
logiciel, etc.)
l’analyse des besoins
est
Analyse des Besoins
L’une des étapes les plus difficiles
différents intervenants: le client, les utilisateurs, les développeurs
(cid:1) clarifier les rôles (identifier, associer des priorités, etc.)
(cid:1)document orienté utilisateur (cahier des charges)
(cid:1)document
(dossier
spécification)
développeur
orienté
analyse &
difficile d’imaginer un système (surtout dans un nouveau
domaine)
(cid:1)travailler méthodiquement
L’une des étapes les plus importantes
Étape déterminante pour la suite
Aspects contractuels
(cid:1) valider les besoins
4
Processus de l’Analyse des Besoins
A. Expression des besoins
1
Détermination
des besoins
2
Validation &
Négociation
3
Gestion des
besoins
B. Spécification des besoins
1
Modélisation et
spécification
2
Validation
Processus de l’Analyse des Besoins
A. Expression des besoins
1
Détermination
des besoins
2
Validation &
Négociation
3
Gestion des
besoins
Méthodes traditionnelles
Entrevue avec les clients
Questionnaire
Observation
Étude de l’existant
(documents/logiciels)
etc.
Méthodes actuelles
Publicité
Prototypage
JAD: Joint Application Design
FAST:Functional Analysis System
Technique
QFD: Quality Function
Deployment
05/04/2015
5
Processus de l’Analyse des Besoins
Expression des besoins
Qui participent ? Analyste (maîtrise d’ouvrage), utilisateurs/clients
(maîtrise d’œuvre)
Sources
o Description de la situation actuelle
o Proposition des besoins à définir
o Documentation existante
o Systèmes et organisations existants
Documents produits: cahier des charges (contractuel)
o Mise en forme selon les normes ou standard du client
o Rédigé par le client en collaboration avec l’analyste
o En langue naturelle
o Découpage en paragraphes exprimant clairement les buts, les
besoins, les contraintes et les règles de gestion
Besoins Non Fonctionnels
Les besoins non fonctionnels peuvent être difficiles à énoncer
précisément et des besoins imprécis peuvent être difficiles à
vérifier
Besoin non fonctionnel non vérifiable
Exemple: Le système devra être facile à utiliser par des
contrôleurs expérimentés, et il devra être organisé de manière à
minimiser les erreurs d’utilisation
Besoin non fonctionnel vérifiable
Exemple: Il faudra que les contrôleurs expérimentés puissent
utiliser le logiciel après deux heures de formation, et que par la
suite, un utilisateur expérimenté ne devrait pas faire plus de
deux erreurs par jour.
05/04/2015
6
Besoins Non Fonctionnels
Vitesse
Nombre de transactions par secondes
Temps de réponse à un utilisateur/événement
Temps de rafraîchissement de l’écran
Taille KO, …
Facilité
d’utilisation
Durée de formation
Nombre d’écrans d’aides
Besoins Non Fonctionnels
Fiabilité
Temps moyen entre deux pannes
Probabilité de non disponibilité
Robustesse
Temps de redémarrage après une panne
05/04/2015
7
Processus de l’Analyse des Besoins
A. Expression des besoins
1
Détermination
des besoins
2
Validation &
Négociation
3
Gestion des
besoins
Tester le modèle auprès de l’usager pour le valider (être sûre qu’on
a décrit le bon problème)
1.Vérifier que la description des besoins est complète
2.Éliminer les besoins (non pertinents, irréalisables, conflictuels,
etc.)
Processus de l’Analyse des Besoins
Les besoins validés doivent être
o Clairs, sans ambiguités
o Complets: délimitation des attentes du client
o Cohérents et non conflictuels (entre eux, avec l’environnement
économique et l’environnement technique)
o Réalisables:
(disponibilité des compétences)
faisables
technologiquement
et
humainement
o Vérifiables: possibilité d’établir des plans de test
o Traçables: possibilité d’identifier
les
problèmes (établir le lien demande solution)
solutions portées
aux
05/04/2015
8
Processus de l’Analyse des Besoins
A. Expression des besoins
1
Détermination
des besoins
2
Validation &
Négociation
3
Gestion des
besoins
1. Identification et
classification des besoins
(Numérotation
(séquentielle avec ou sans catégories)
2. Hiérarchisation des besoins
o Un besoin peut se composer d’un ou plusieurs besoins plus
spécifiques, moins abstraits
Le Cahier de Charges
Un Cahier des charges doit :
spécifier uniquement les comportements externes du système
spécifier les contraintes de réalisation
être facile à mettre à jour
servir de référence à la maintenance
05/04/2015
9
Structure d’un Cahier de Charges
1. Présentation du projet
1.1 Contexte: Environnement dans lequel s'inscrit
(stratégie, enjeux, domaine, etc.)
1.2 Objectifs: Résultats que le projet doit atteindre.
1.3 Description de l'existant
Environnement logiciel et matériel du logiciel.
Système existant, le cas échéant.
1.4 Critères d'acceptabilité du produit
Procédure de validation + Critères d'acceptation.
le projet
2. Expression des besoins
2.1 Besoins fonctionnels
2.2 Besoins non fonctionnels
Structure d’un Cahier de Charges
3. Contraintes
3.1 Coûts: Budget alloué au projet + Moyens matériels et logiciels
mis à disposition.
Publicité
3.2 Délais
Date de livraison du produit + Echéances intermédiaires.
3.3 Autres contraintes
Autres contraintes à prendre en compte (normes techniques,
clauses juridiques, etc.)
4. Déroulement du projet
4.1 Planification
4.2 Plan d'assurance qualité
4.3 Documentation
4.4 Responsabilités
05/04/2015
10
Spécification des Besoins
B. Spécification des besoins
1
Modélisation et
spécification
2
Validation
Spécification des Besoins
Trois niveaux de formalité des techniques de spécification des
besoins :
informelle : basée sur le langage naturel
semi-formelle : basée sur un langage structuré textuel et/ou
graphique (dont la sémantique est faible)
formelle : basée sur un langage formel dont le vocabulaire, la
syntaxe et la sémantique sont formels
oSpécifications algébriques
oSpécifications basées sur des modèles mathématiques
05/04/2015
11
Spécification des besoins: Spécification Informelle
Exemple :
Fonction : Vérifier_validité_carte
Description : Cette opération vérifie que la carte introduite par
un utilisateur est lisible, qu’elle provient d'une banque reconnue,
que la date du jour est inférieure à la date d’expiration, et qu'elle
contient des informations sur le montant maximal autorisé
Entrées : Identification de la banque, numéro de compte, date
d'expiration, type de la carte
Origine : Bande magnétique de la carte
Sorties : Etat de la carte (OK, invalide)
Destination : Distributeur (l'état de la carte est passé à une autre
partie du logiciel)
etc.
Spécification des besoins: Spécification Informelle
Avantage :
liberté pour l'auteur
Inconvénients :
les besoins fonctionnels, non fonctionnels et les buts ne sont
pas clairement distingués
possibilité de regrouper plusieurs besoins distincts dans une
même phrase, d'où une difficulté de vérification de cohérence
05/04/2015
12
Spécification des besoins: Spécification Formelle
La syntaxe est celle des formules du calcul des prédicats
Les règles de déduction sont celles de la logique du premier ordre.
Repose sur des langages formels
Permet la réduction des erreurs et les omissions dans les besoins
Peuvent être automatisées et supportées par des outils
Spécification des besoins: Spécification Formelle
Un exemple de techniques formelles : le langage Z
Exemple de l’évaluation des propositions liées à des projets:
05/04/2015
13
Spécification des besoins: Spécification Formelle
Inconvénients :
Requiert un bagage mathématique
Nécessite une certaine qualification du client, utilisateurs et
développeurs
Phase de spécification plus longue
Spécification Semi-formelle des besoins
Modélisation
du
comportement
Modélisation
des
Fonctions
Modélisation
des
Données
05/04/2015
14
Modélisation des fonctions: DFD
DFD: Diagramme de flots de Données/ Data flow Diagram
Le système est décrit comme un ensemble de données manipulées
par des fonctions ou transformations (processus)
Représentation graphique du cheminement des données à travers
un système
Données organisées de différentes façons:
stockées dans des dépôts
Evoluant dans des flots
Transférées de/vers l’extérieur
Représentation avec un DFD
DFD peut être utilisé pour représenter le système à différents
niveaux d’abstraction
Le niveau d’abstraction le plus élevé (niveau 0) est appelé
diagramme de contexte
Une transformation peut être « éclatée » et donner naissance à un
nouveau DFD qui montre le traitement des données à un niveau
plus détaillé (niveau d’abstraction plus bas)
Le Top-Down peut continuer jusqu’à obtenir un degré de détails
satisfaisant pour la compréhension du système (ou problème)
05/04/2015
15
Représentation avec un DFD
Un DFD permet de développer les modèles:
du domaine des informations
du domaine fonctionnel
Une décomposition fonctionnelle est faite à chaque niveau de détail
Les données sont aussi raffinées à travers les processus
Représentation avec un DFD: les Primitives
Processus ou Fonction
Flots de Données
Dépôt de Données
Source ou Destination
05/04/2015
16
Exemple de DFD
Le système de prêt d’une bibliothèque
Il faut éclater le processus du niveau 0, les différentes activités sont:
Demande explicite de l’usager avec information sur le livre
Accès à la liste des titres
Accès à la liste des auteurs
Exemple de DFD
Client
Info livre
Info client
Données livres
Saisir
et
vérifier
Données auteurs
Prêts
Données clients
Publicité
Dde vérifiée
Accorder
le prêt
Comptoir
de prêt
On peut éclater le processus de « saisir et vérifier »
05/04/2015
17
Création d’un DFD
Au niveau 0 un seul processus (le système)
Les entités externes doivent être clairement définies
Le raffinement commence par l’isolation d’un processus avec les
données et dépôts
La continuité des flots doit être maintenue d’un niveau vers un
autre
Faire le raffinement d’un processus à la fois
Ne pas devancer les niveaux de détails
Modélisation des Données: DD
DD: Dictionnaire de Données ou Data Dictionnary
Complémentaire du Diagramme de Flot de Données
Sert à documenter la totalité du système. Il contient les noms et
descriptions de tous les éléments apparaissant dans les DFDs
Fournit de l’information sur la définition, la structure et l’utilisation
de chaque donnée que le système utilise
Exemple typique d’informations enregistrées dans un dictionnaire
des données:
Général: nom, description, etc.
Format: type, longueur, unités, etc.
Caractéristiques d’utilisation: éventail de valeurs,
d’utilisation, valeurs conditionnelles, etc.
Information de contrôle: source, date de création, utilisateurs,
etc.
fréquence
05/04/2015
18
Avantages du Dictionnaire des Données (DD)
Sert de source de documentation et de référence
Améliore la communication entre usagers et analystes en établissant
un ensemble consistant de définitions
Peut être réutilisé dans d’autres applications et éviter la redondance
Permet d’évaluer l’impact d’un changement dans les données du
système
Peut être le premier pas vers la création d’une base de donnes
Modélisation des Données: Modèle E/R
utilise le langage graphique pour exprimer les exigences logiques
relatives à des systèmes d’information
Description des données conventionnelles et leurs interrelations
Utilisé pour la représentation des Bases de Données
Un modèle E/R montre les données au repos alors qu’un DFD les
montre en mouvement
Il n’y pas de raffinement
05/04/2015
19
Modélisation de l’aspect Comportemental
Automate fini/machine à états finis
C’est une technique opérationnelle largement répandu pour décrire
les aspects liés au contrôle. Il consiste en :
un ensemble fini d’états (S),
un ensemble fini d’entrées (I),
une fonction de transition t : S x I -> S ; c’est une fonction
partielle. Une certaine entrée dans un certain état fait passer à
un autre état.
Graphiquement une machine à états finis est représentée par un
graphe (appelé diagramme d’états) dont les nœuds sont les états.
Un arc nommé a va de s1 à s2 si et seulement si t(s1,a)=s2.
Machine à états finis: Appel téléphonique
05/04/2015
20
Le Langage UML
Diag. de cas d’utilisation
Diag. de Séquence
STD: State transition Diagram
Et autres diag.
Le Document de Spécification
Un Document de spécification doit contenir :
Présentation générale du système
◦ objectifs, concepts d'utilisation
Expression complète des fonctions à satisfaire
◦ du point de vue de l'utilisateur et de l'environnement externe
◦ Hiérarchie des fonctions + description de chaque fonction
◦ Prévision pour les tests
Expression des performances exigées
◦ vitesse, etc.
Définition des interfaces (Homme-Machine)
Problèmes particuliers relatifs aux données
05/04/2015
21
05/04/2015
Besoins Non Fonctionnels
Énoncé des Besoins
des
utilisable
Le logiciel doit être développé de manière à
être
utilisateurs
par
inexpérimentés
Toute ligne contenant un mot mal écrit doit
être affichée
être
programmation
L'équipe
organisée en trois groupes avec pour chacun
d'eux un responsable dépendant directement
du chef de projet
devra
de
F Non
Mal Aucun
F
x
x
x
x
Besoins Non Fonctionnels
Énoncé des Besoins
Le logiciel doit être capable de traiter 300 mots
à la minute
Les commandes devront être données par
l'intermédiaire de menus
Les performances du système logiciel doivent
rester
raisonnables sous les conditions de
charge maximale
F Non
Mal Aucun
F
x
x
x
x
22