2. Analyse des besoins : Position dans le
cycle de vie
Contexte :
problème posé par le client : cahier des charges
Phase d'analyse des besoins :
formulation d'une réponse à ce problème (proposition)
→ dossier d'analyse
Phase suivante : planification
Terminologie alternative :
définition du produit, spécification
3. Contenu du dossier d'analyse
Description des fonctions du produit
complète et détaillée
y compris dans sa relation avec l'environnement
Attention :
seules les fonctions visibles de l'usager sont décrites
pas l'architecture modulaire du produit
→ « boîte noire »
4. Contenu du dossier d'analyse
spécifications fonctionnelles
spécifications non-fonctionnelles
première version du glossaire
(et dans le cas d'un cycle de vie en V :
+ tests de validation et de qualification
+ première version du manuel utilisateur)
6. Importance du dossier d'analyse
Donner une réponse à chacun des besoins de l’utilisateur
Contrat entre l’équipe de développement et le client.
protection du client (engagement des developpeurs)
protection de l’équipe de développement(attente client bien définie)
Attention!!!
Eviter les erreurs dans la spécification
→ coût important si découvert trop tard
7. Dossier d'analyse : fait par qui ?
Généralement réalisé par
des membres de l'unité de développement
Parfois réalisé par le client
attente d'un produit précis
Parfois donné par une norme
protocole, format d'échange, ...
8. Dossier d'analyse : fait pour qui ?
1) Pour le client :
description précise de ce qui sera réalisé
→ permet d'anticiper la mise en exploitation
2) Pour les développeurs :
référence précise, non ambiguë…
→ ce qu'il s'agit de réaliser
→ ce qu'il s'agit de tester
9. Plan type du dossier d'analyse
☛ plan indicatif !
(ne pas nécessairement le suivre à la lettre)
1) Introduction
– objectifs
– fonctionnalités attendues
– environnement
– faisabilité et justifications
– ressources nécessaires
– éléments de coût et échéancier
10. Plan type du dossier d'analyse
2) Concepts et terminologie
– glossaire de l'application
☛ Peut être en annexe, ou bien un document
autonome utilisé et partagé dans tout le projet
11. Plan type du dossier d'analyse
3) Description fonctionnelle externe
3.1) Pour chaque « fonction » :
(☛ fonctionnalité abstraite, pas une routine de programme !)
● entrées
● traitement
● sorties : effets
● détails éventuels :
– conditions d'arrêt
– exceptions, points de reprise, traitement des anomalies
– si traitement trop complexe à décrire : algorithme suggéré
12. Plan type du dossier d'analyse
3) Description fonctionnelle externe (suite)
...
3.2) Organisation logique des données
● types de données
● formats de présentation
3.3) Interface homme-machine
● fenêtres et écrans
● états (représentés ou non) et transitions
13. Plan type du dossier d'analyse
4) Description interne
4.1) Interaction avec l'environnement
● composants logiciels nécessaires aux fonctions en 3.1
(ex. base de données existante)
4.2) Contraintes
● contraintes de réalisation (ex. encombrement mémoire)
● contraintes de qualité (ex. précision du calcul)
● performances
● critères de vérification des contraintes
● priorités
14. Plan type du dossier d'analyse
5)Questions ouvertes et réponses apportées par les
développeurs
– précisions, faisabilité (éléments de prototypage)
– ...
6) Éléments de livraison
– cahier provisoire de recette
● tests de recette
● dates issues de la planification
15. Qualités du dossier d’analyse
Précis
formulation non ambiguë
Cohérent
pas de contradictions
Complet
pas d'oublis
couverture de tous les besoins (→ cahier des charges)
description exhaustive des fonctionnalités
16. Qualités du dossier d’analyse
Argumenté
liaison claire (références) avec:
les besoins exprimés dans le cahier des charges
(les objectifs exprimés dans la spécification d'objectifs)
☛ critère de traçabilité (→)
Traçable
pouvoir suivre le devenir des fonctionnalités dans les phases ultérieures
(implémentation, test)
Maintenable / flexible
comment prendre en compte les évolutions futures?
17. Forme du dossier d'analyse
Séparation des concepts
= 1 concept par paragraphe
Numérotation des paragraphes et/ou sections
→ facilité de référence
→ traçabilité (dans les phases ultérieures)
18. Modèle conceptuel
Donne une image « mentale » du produit (!)
Recense les fonctionnalités attendues
Point de départ à :
l'analyse des besoins
l'interface utilisateur
☛ Extrême importance
19. Modèle conceptuel
Élaboré à partir des interviews d'utilisateurs
Définit, pour chaque grande fonction du produit :
les objets (ou entités) que le produit crée/manipule
les attributs de ces objets
les opérations à réaliser sur ces objets
20. Exemple de définition d’un modèle
conceptuel
Messagerie téléphonique du type SMS / texto :
– consulter les messages dans la boîte de réception
– supprimer un message
– envoyer un message
– faire suivre ou répondre à un message
– consulter les contacts dans le répertoire
– ajouter et supprimer des contacts dans le répertoire
Quels sont les objets pouvant découlés de cette description et les
relations qui existent entre eux ?
21. Objets et relations dans une
messagerie textuelle téléphonique
Objets
– boîte de réception
– message (2 types : reçu, en cours de rédaction)
– répertoire
– contact
Relations
– la boîte de réception contient une liste de messages
– un message provient de / est destiné à un numéro
– un contact a un nom et un numéro
23. Importance du modèle conceptuel
Il structure
identification de concepts, objets, attributs, opérations et de leur articulation
Il fonde l'intuition
image mentale : analogie avec des concepts, objets, attributs et opérations connus
apprentissage réduit
Il facilite l'interaction
efficacité, productivité
Impact sur tous les acteurs
utilisateur
développeur (projet complexe)
décideur
24. Techniques et outils de spécification
Modèle conceptuel
Représentations tabulaires :
table de décision
table de transition
Représentations graphiques semi-formelles :
modèle entité-association
diagramme de flot de données
diagramme états-transitions
réseau de Petri, ...
Méthodes formelles
25. Interface Utilisateur
Souvent objet de concurrence entre applications
(peu de différences « sous le capot »)
Reflet des fonctionnalités du produit
Terminologie :
– français : interface homme-machine (IHM),
interface graphique
– anglais : graphical user interface (GUI) ]
26. Interface utilisateur : Méthodologie
Partir du modèle conceptuel des données et traitements
Définir un modèle conceptuel du dialogue
représentation de l'information
interactions
☛ Choix crucial d'un bon modèle conceptuel
27. Interface utilisateur : Ergonomie
Convivialité
facilité d'utilisation
mesure : ex. nombre de jours d'apprentissage
Efficacité
productivité des utilisateurs (→ mesure)
caractériser les types d'utilisateurs ciblés
compétence
but du travail
performances attendues, ...
28. Interface utilisateur : Ergonomie
Lisibilité
mise en avant des données pertinentes/prioritaires
regroupement des données similaires
alignement visuel des données
sens/ordre de lecture « ordinaire »
stabilité d'un écran à l'autre
Standardisation
marché, influence du système d'exploitation/fenêtrage
normes de l'entreprise
conventions liées au domaine
30. Maquettage et prototypage
Quand :
après le premier jet des spécifications fonctionnelles
Objectifs :
montrer au client à quoi ressemblera le produit
valider les besoins et les spécifications
31. Maquette
Système incomplet dont l'aspect extérieur est +/- le même que le produit
à réaliser
Destiné à tester l'ergonomie du produit
Instaure un dialogue développeur-utilisateur
Ne permet pas le test de performance
Souvent jetable
32. Prototype
Esquisser ce que sera le produit final
les fonctionnalités
sans contraintes (fiabilité, ...)
Valider les besoins utilisateur
réalisables ?
Valider les spécifications
complètes, réalistes, non contradictoires ?
Souvent jetable (sinon = prototype évolutif)
33. Prototype
Intérêt
évaluer rapidement la faisabilité, mais aussi :
mettre en évidence les incompréhensions développeur-utilisateur
identifier les services difficiles à utiliser
découvrir les contradictions
détecter les oublis de spécification
servir de base à l'écriture de spécifications complètes
34. Prototype
Ignorer les critères non-fonctionnels :
temps de réponse, contraintes mémoire
traitements d'erreur
standards
fiabilité, robustesse
...
35. Prototyper n'est pas spécifier
Un prototype ne remplace pas des spécifications
il ignore les critères non fonctionnels
il ne peut être une base fiable du contrat (à la différence du dossier d'analyse)
36. À retenir
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
