4. EXPRESSION DU BESOIN | JUSTIFIER SON BESOIN
+Un besoin doit toujours être justifié
Il a un coût pour l’entreprise
Il doit être pertinent au regard de l’usage d’une solution, la stratégie d’évolution d’un outil,
technologie, infrastructure
Les demandes conséquentes, structurantes, importantes doivent en plus décrire un enjeu; ces
demandes doivent donc être portées par un sponsor, membre d’une direction.
5chdessus@sqli.com - support de présentation
5. EXPRESSION DU BESOIN | DÉCRIRE L’UTILITÉ ET LA GARANTIE
+Utilité
Nouvelles fonctionnalités ou amélioration des fonctionnalités existantes
Nouvelles technologies, infrastructures ou évolution des infra existantes
Contraintes supprimées, gains de temps ou €
Sécurité
+Garantie
Niveau attendu de disponibilité, capacité, continuité
Performance attendue, montrer une amélioration par rapport à la situation existante ou passée
Capacité : estimer les volumes actuels + évolution prédite
Sécurité
6chdessus@sqli.com - support de présentation
6. EXPRESSION DE BESOIN | CONTENU
+Le demandeur est assez libre de décrire
› Situation actuelle
› Volumes actuels
› Situation future souhaitée
› Estimation de volumes futurs
› Contraintes, dépendances critiques
› Budget, délais
+Celui qui reçoit
S’assure de l’exhaustivité des besoins
Structure les besoins jusqu’à la livraison de la solution.
7chdessus@sqli.com - support de présentation
7. POURQUOI UN CLIENT-UTILISATEUR NE DONNE JAMAIS UNE
VISION EXHAUSTIVE DE SES BESOINS ?
+ Incompréhension humaine, niveau de langage différent : L’interlocuteur ne comprend pas
les attentes du concepteur/constructeur et vice-versa.
+ Contexte : celui qui imagine la vision future n’est pas celui qui la construit ni celui utilise
+ Inconfort avec le langage oral ou écrit
8chdessus@sqli.com - support de présentation
8. SATISFACTION DU BESOIN |MODÈLE DE KANO
+ Modèle de Kano
+ Satisfaction des clients
9chdessus@sqli.com - support de présentation
9. FORMALISATION DU BESOIN | OUTILS DE FORMALISATION
+ Découvrir le besoin : Exigence
« Je veux » ou « Je ne veux pas »
Utilité et garantie
+ Structurer la réponse au besoin : Décomposition fonctionnelle (PBS)
Fonctions souhaitées
Solution connue ou inconnue
Essentiellement utilité
10chdessus@sqli.com - support de présentation
11. STRUCTURER LES BESOINS |EXIGENCES
+ Une exigence est un besoin par rapport à l’outil à construire
Un service à rendre
Une contrainte à respecter
Une contrainte à enlever
12chdessus@sqli.com - support de présentation
12. STRUCTURER LES BESOINS |EXIGENCES
+Exigence = Demande client/utilisateur/sponsor/partie prenante
Des Exigences Fonctionnelles, techniques, sécurité….
Modèle FURPS+
+Les objectifs
S’assurer qu’on a bien compris les besoins du client
S’assurer que les produits du projet contiennent bien les besoins du client
13chdessus@sqli.com - support de présentation
13. STRUCTURER LES BESOINS |MODÈLE FURPS++
+Décrire les besoins fonctionnels
Un besoin, une exigence qui lorsqu’il est satisfait permet à un utilisateur de réaliser une fonction
ou lui enlève une contrainte.
+Décrire les besoins non fonctionnels
Généralement des contraintes qui pèsent sur le système. Exemple : 24/7
+++ Ne pas oublier les contraintes
D’implémentation : plateforme, ressources, intégration, déploiement, conformité aux standards,
contraintes physiques d’implémentation
D’interface :
› Ergonomie, facilité d’usage
› Interopérabilité avec les autres systèmes, flux
14chdessus@sqli.com - support de présentation
14. STRUCTURER LES BESOINS |MODÈLE FURPS++
+Functionnability
Généralités, capacité, fonction souhaitée y compris la sécurité
Connectivité, licences
+Usability
Accessibilité, facteurs humains, look & feel
Documentation
+Reliability
Résistance aux pannes, défaillances, temps moyen entre 2 défaillances
Capacité de restauration, continuité de service, suivi et surveillance
+Performance
Vitesse d’exécution, temps de réponse
Consommation de ressources
15chdessus@sqli.com - support de présentation
15. STRUCTURER LES BESOINS |MODÈLE FURPS++
+Supportability
Testabilité, Capacité d’évolution (extensibilité, montée en charge)
Compatibilité, portabilité
Maintenabilité, instabilité
Possibilité de configuration, adaptabilité aux besoins
16chdessus@sqli.com - support de présentation
16. STRUCTURER LES BESOINS |PÉRIMÈTRE
+Les exigences définissent le périmètre du projet
Intégrer tous les usages, y compris ceux des équipes support
+Les exigences évoluent au cours du projet
Traçabilité totale et systématique de tous les changements
Faire une analyse d’impact et rechiffrer
+Granularité
Une fonction simple, testable unitairement, dont on entrevoit la solution
On rédige le cas de test de l’exigence en même temps que l’exigence
17chdessus@sqli.com - support de présentation
17. EXIGENCES | DÉMARCHE DE DÉCOUVERTE
18chdessus@sqli.com - support de présentation
Indiquer pour chaque exigence COMMENT y répondre :
Quelle fonction mettre en œuvre ?
Quelles limites ?
Comment l’exigence est mise en œuvre : développement, paramétrage d’une solution
Indiquer le niveau de complexité de la mise en œuvre et la charge associée
Identifier les exigences
explicites
Capturer les exigences
implicites
Mener des échanges avec
le demandeur
Indiquer pour chaque
exigence la fonction à
implémenter
Lecture du cahier des charges
Classer les exigences par domaine, fonction
Conduire les réunions de revue du cahier des charges
Mettre à jour le référentiel
Conduire les réunions
Identifier toutes les contraintes et besoins induits des parties prenantes
Mettre à jour le référentiel et classer les exigences par domaine, fonction
Prioriser les exigences
Lier l’exigence à un enjeu du projet
Prioriser la mise en œuvre des exigences, lotir
Indiquer le niveau de prise en compte, partiel, total ou refus
Montrer la couverture des exigences
18. EXIGENCES | DÉMARCHE DE DÉCOUVERTE
+ Faire valider le référentiel au démarrage
+ Rédiger les critères de choix de la solution
+ Rédiger le plan de tests et le cahier de recette
+ Effectuer des revues d’exigences avec les parties-
prenantes tout au long du projet
+ Suivre l’avancement du projet : taux de couverture
19chdessus@sqli.com - support de présentation
Mettre en place un suivi régulier du périmètre
19. POURQUOI LES EXIGENCES NE SONT JAMAIS STABLES ?
+ Tout simplement parce que le besoin évolue avec le temps : maturité, maturation, priorités
de l’entreprise évoluent…
+ Chaque partie-prenante a sa vision limitée du projet, contexte, périmètre et cherche ses
réponses. Les points de frottement, consensus nécessaires apparaissent plus
tardivement.
+ Reformulation, retranscription successive : celui qui s’exprime retranscrit ce qu’il a
compris ou ce qu’il souhaite personnellement
+ Incompréhension humaine
+ Contexte différent : « chacun voit midi à sa porte »
20chdessus@sqli.com - support de présentation
20. SURVIVRE AVEC DES EXIGENCES INSTABLES
+ Effectuer des revues du référentiel à chaque fin de phase : exigences conçues,
paramétrées, testées, implémentées…
+ Communiquer sur l’avancement du projet aux parties-prenantes à partir du référentiel des
exigences
+ Tracer tous les changements de référentiel. Mesurer leur impact. Remonter au sponsor les
changements structurant
+ Tracer les exigences dans tous les livrables documentaires + code + test….
21chdessus@sqli.com - support de présentation
22. EXPRESSION DU BESOIN |FORMALISATION
+ Formaliser le besoin tel que exprimé par le demandeur
› Si la demande concerne l’architecture :
Donner une vision de la situation actuelle, situation future, le chemin de la situation actuelle vers la
situation future (si connu). Inclure des schémas.
› Si la demande est applicative
Décrire le besoin et le formaliser : texte, décomposition fonctionnelle, tableau des exigences…
› Si la demande est organisationnelle
Modéliser le processus, workflow sous forme d’un modèle
› Décrire les contraintes :
Niveaux de service
Fiabilité
Dépendances avec d’autres sujets, projets, activités
Urgence (1 non urgent, 2 normal, 3 critique pour le travail de tous les jours), justifier
23chdessus@sqli.com - support de présentation
23. STRUCTURER LE BESOIN | CONSTRUIRE LA SOLUTION ATTENDUE
24chdessus@sqli.com - support de présentation
24. STRUCTURER LE BESOIN | VÉRIFIER ET VALIDER
25chdessus@sqli.com - support de présentation
Dernière étape : valider l’atteinte
des objectifs du sponsor et
l’atteinte des enjeux initiaux
26. DÉCRIRE LES FONCTIONS À METTRE EN ŒUVRE
+ Le référentiel des exigences permet :
De grouper les exigences par thème
D’identifier les fonctions à mettre en œuvre
+ Structurer les fonctions de la solution
27chdessus@sqli.com - support de présentation
27. PBS | DÉFINITION
+ Décomposer le besoin tel qu’exprimé par le demandeur jusqu’à permettre d’identifier la
solution technique à mettre en œuvre.
+ Décomposer une solution, un produit, composant en sous produits techniques ou
documentaires.
+ Intérêt :
En mode projet : définition précise des livrables techniques et documentaires à produire
En maintenance :
› Suivi des livraisons, versions, changements
› Suivi de configuration des composants techniques et de leurs dépendances
Définition des besoins d’intégration entre sous-composants et interfaces avec d’autres composants.
28chdessus@sqli.com - support de présentation
28. PBS | DÉFINIR LE BESOIN – SOLUTION INCONNUE
+Reformuler le besoin c’est décrire l’usage de la solution future
+Penser à définir l’enjeu principal et les cas d’usage avant de
rechercher la solution (le POURQUOI et le QUOI)
› « Tous les jours, je me rends sur mon lieu de travail. Je ne
transporte que mon ordinateur et sac à main. En rentrant le soir, je
fais quelques courses. »
29chdessus@sqli.com - support de présentation
29. PBS | DÉFINIR LE BESOIN – SOLUTION INCONNUE
30
REFORMULATION DU BESOIN
chdessus@sqli.com - support de présentation
30. PBS | DÉFINIR LE BESOIN – SOLUTION INCONNUE
+Approfondir les besoins et effectuer un choix de solution.
Compléter le PBS reformulant les besoins et en proposant une
réponse technique.
› Prendre les transports en commun
› Véhicule à 2 roues avec un pédalier classique ou une assistance électrique ou à
moteur (solex)
› Véhicule léger à 3 roues disposant d’une remorque de transport et d’une capote
tissée de protection contre les intempéries
› Véhicule à 4 roues avec une carrosserie protectrice : voiture électrique ou un
autre système de propulsion (gaz, essence ou gasoil)
31chdessus@sqli.com - support de présentation
31. PBS | DÉFINIR LE BESOIN – SOLUTION INCONNUE
+ Choisir la solution
› Définir des critères à partir des exigences exprimées et modélisées
Définir aussi des critères de type « killer » : si la solution potentielle ne répond pas à ce critère, la solution
est immédiatement rejetée
› Donner une pondération Poids = Importance
Poids de 1 à 4
› Valider chaque solution potentielle au regard des critères pondérés Valider =
Noter
Note de 1 à 5
› Choisir la solution ayant la meilleure couverture des critères
+ Les critères peuvent être
› Fonctionnels
› Non fonctionnels : techniques, sécurité, organisationnels, réglementaires,
exploitation…
32chdessus@sqli.com - support de présentation
32. PBS | EXEMPLE DU CYCLE – SOLUTION CONNUE
+ Le choix de solution est effectué : proposer un cycle. En conception fonctionnelle, les fonctions de
services de la solution identifiée sont décrites.
+ En conception technique, la mise en œuvre des fonctions de service est décrite. Les fonctions
techniques sont définies au regard des besoins et contraintes : quel mode de propulsion, poids des
objets à transporter…
33chdessus@sqli.com - support de présentation
33. PBS | EXEMPLE
+La décomposition en FONCTIONS DE SERVICES permet de concevoir ou
fabriquer ou mettre en service n’importe quel cycle :
+La décomposition en FS doit être complétée
› Des exigences et contraintes du « client », « utilisateur » pour chaque fonction de
service (FS)
› Des choix de FONCTIONS TECHNIQUES (FT) décrivant la solution proposée (le
comment).
34chdessus@sqli.com - support de présentation
34. PBS | DOCUMENTATION
+Pour chaque bloc du PBS
Description
Usage
Contraintes techniques, maintenance (support, exploitation)
Exigences
Liens avec les autres éléments techniques
Performance attendue
Définir les niveaux de décomposition inférieur (MAX = 4)
… à compléter
35chdessus@sqli.com - support de présentation
35. PBS | DÉMARCHE
36chdessus@sqli.com - support de présentation
Expression du besoin
Concevoir/choisir la solution
pour l’usage attendu
Concevoir techniquement la
solution
Construire la solution
Maintenir la solution
QUOI, POURQUOI,
QUAND, COMBIEN,
POUR QUI, QUELLE
PERFORMANCE
QUOI, POURQUOI
COMMENT
Fonctions de
Service (FS)
Fonctions
Techniques
(FT)
Attentes des parties-prenantes : commanditaire, utilisateur direct ou
indirect
Pas forcément immédiatement structuré et complet
Celui qui conçoit doit structurer le besoin et le faire valider au
demandeur pour le compléter
Reformulation structurée de l’expression du besoin spécifications
fonctionnelles ou techniques
Choisir la solution
Traduction de la FS en composant technique
Description de la solution mise en œuvre : composants techniques et
documentaires
Description des configurations : liens entre les composants techniques
et documentaires
Fabriquer, vérifier, intégrer, déployer
Surveiller, exploiter, gérer en configuration
Corriger
Faire évoluer
Référentiel
Exigences
36. PBS | USAGE : GÉRER EN CONFIGURATION
+Définition de « configuration »
› Ensemble des caractéristiques fonctionnelles et physiques d'un produit
› Ces caractéristiques sont décrites par les documents techniques.
+Activités
› Gérer les composants, sous-composants de l’architecture technique et/ou logicielle mise
en œuvre
› Suivre et tracer leurs changements
› Mesurer les impacts des changements d’un composant sur les composants en relation.
37chdessus@sqli.com - support de présentation
37. PBS | USAGE : GÉRER EN CONFIGURATION
+ Décrire
à quoi ressemble le produit
ce qu’il est supposé faire
comment il doit être assemblé
comment il est supposé être utilisé
comment il est maintenu
+ Plusieurs niveaux de
décomposition
+ Plusieurs versions de
décomposition
38chdessus@sqli.com - support de présentation
Configuration
telle que
conçue
Configuration telle
que construite
Configuration telle
que déployée et
maintenue
FT maintenues
Consignes exploitation et
maintenance
Manuel d’utilisation
FT implémentées
Procédure d’installation et
intégration
Doc de paramétrage
FS et FT conçues
Spécifications
DAT
39. WBS ET PBS | USAGE COMBINÉ
+Pour déployer une infrastructure / composant technique :
› Effectuer la décomposition technique de l’architecture/composant/produit à mettre en
œuvre, jusqu’au niveau le plus fin PBS
› Décrire les étapes de travail permettant de construire la solutions, les fonctions
techniques WBS
+Le PBS est le document en entrée de la gestion de configuration de vos
architectures/infrastructures déployées.
+Le WBS est utilisé pour planifier les activités et suivre leur avancement.
40chdessus@sqli.com - support de présentation
40. WBS ET PBS | EXEMPLE
Concevoir le cadre du Solex Modèle XYZA
La solution : c’est l’ensemble des Fonctions Techniques mises en
œuvre et constituant un modèle/produit fini.
41chdessus@sqli.com - support de présentation
Activité
WBS
FS et FT
PBS
Solution à fabriquer
PBS
41. WBS ET PBS | USAGE COMBINÉ
42chdessus@sqli.com - support de présentation
WBS (COMMENT FAIRE)
• Décrire les étapes de
fabrication
• Décrire les responsabilités
• Planifier et suivre
l’avancement des livrables
Planning & jalons
PBS (QUOI FAIRE)
• Décrire les produits
techniques et documentaires à
fabriquer
• Décrire les liens entre les
sous-produits
• En lien avec le référentiel des
exigences
• Décomposition technique
42. STRUCTURER LA RÉALISATION DES ACTIVITÉS
43chdessus@sqli.com - support de présentation
Demande initiale
argumentée et
validée • Activités & actions
• Planning & jalons
• Livrables - Décisions
• Changements de
périmètre
• Anomalies de recette,
installation, intégration
• Risques
Produit – Solution - Logiciel
Infrastructure - Architecture
Processus - Procédures
Activités – Tâches - Rôles