De l'expression de besoins vers spécifications de la solution

chdessus@sqli.com
Date réunion : 23/02/2015
De l’expression des besoins aux spécifications de la
solution

SOMMAIRE
Besoin
Exigences
Formaliser - Structurer - Décomposer
Usage combiné des outils
chdessus@sqli.com - support de présentation 3

4
BESOINS
chdessus@sqli.com - support de présentation

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

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é

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.

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

SATISFACTION DU BESOIN |MODÈLE DE KANO
+ Modèle de Kano
+ Satisfaction des clients

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é

EXIGENCES

STRUCTURER LES BESOINS |EXIGENCES
+ Une exigence est un besoin par rapport à l’outil à construire
Un service à rendre
Une contrainte à respecter
Une contrainte à enlever

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

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

+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

+Supportability
Testabilité, Capacité d’évolution (extensibilité, montée en charge)
Compatibilité, portabilité
Maintenabilité, instabilité
Possibilité de configuration, adaptabilité aux besoins

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

EXIGENCES | DÉMARCHE DE DÉCOUVERTE
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

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
Mettre en place un suivi régulier du périmètre

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 »

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….

22
FORMALISER – STRUCTURER -
DECOMPOSER

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

STRUCTURER LE BESOIN | CONSTRUIRE LA SOLUTION ATTENDUE

STRUCTURER LE BESOIN | VÉRIFIER ET VALIDER
Dernière étape : valider l’atteinte
des objectifs du sponsor et
l’atteinte des enjeux initiaux

STRUCTURER LE BESOIN | OUTILS

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

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.

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. »

30
REFORMULATION DU BESOIN

+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)

+ 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…

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…

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).

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

PBS | DÉMARCHE
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

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.

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
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

USAGE COMBINÉ
EXIGENCES – PBS - WBS

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.

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.
Activité
WBS
FS et FT
PBS
Solution à fabriquer
PBS

WBS ET PBS | USAGE COMBINÉ
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

STRUCTURER LA RÉALISATION DES ACTIVITÉS
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

De l'expression de besoins vers spécifications de la solution

De l'expression de besoins vers spécifications de la solution

Contenu connexe

Tendances

Similaire à De l'expression de besoins vers spécifications de la solution

Plus de COMPETENSIS

Dernier

De l'expression de besoins vers spécifications de la solution