Pour cette rencontre du groupe ADIRA Business Analysis, Dominique Houdier nous avait préparé un atelier sur « la vie d’un besoin », depuis son expression par le métier jusqu’à la définition des exigences de la solution.

1. Groupe ADIRA
Business Analysis
« Exigences »
Le 24 Mars 2017

2. Mon parcours :
Certified Business Analysis Professional (CBAP®) de l’IIBA
@ Capgemini
En Mai 2014
Business Analyst & AMOA
@ Capgemini
Depuis Juillet 1990
Ingénieur Concepteur
@ Différentes SSII
De Mai 1989 à Mai 1990
Capgemini Lyon | Manufacturing Consumer & Retail
Senior Business Analyst, CBAP®
Leader de la Communauté BA Capgemini Apps France
Membre du bureau IIBA France
(IIBA French chapter)
Animatrice du groupe ADIRA Business Analysis
Annick Rimbod-Pethiod

3. Mon parcours :
Dirigeant
@ COMPLIANCE Technologies
De Janvier 2004 à ce jour
Responsable Centre de Profit
@ Telelogic
De Février 1991 à Décembre 2003
Consultant
@ Verilog
De Juillet 1997 à Janvier 1999
Ingénieur Logiciel
@ Thales Information System
De Juillet 1989 à Juin 1997
COMPLIANCE Technologies
Consultant | Formateur en Ingénierie des Exigences
(Processus et outils - DOORS, Reqtify, Polarion…)
Membre de l’IREB et membre fondateur du SPECIEF
Dominique Houdier
Ingénierie
Des
Exigences
Notre Offre
Conseil
Formation
Certification
Cahier des
charges /
Expression du
besoin
Ligne de
produits
Déploiement
Processus
Outils
Modélisation
 Fondée en 2004
 Société de conseil, spécialisée en
Ingénierie des Exigences
en matière de processus, de
méthodes et d'outils (DOORS,
Reqtify, Polarion, Enterprise
Architect, etc.)
 Maîtrise et amélioration de la
conformité et de la qualité des
systèmes complexes et des
systèmes d’information
 Membre de l’IREB et membre
fondateur du SPECIEF
Normes et
Qualité
Nos Clients

4. Nos objectifs aujourd’hui
 Approfondir ce qui se cache derrière ce concept d'Exigence ?
Comment passer des Exigences utilisateurs (Besoins) aux
Exigences Système (Fonctions) ?
 Sur la base d’exercices pratiques, appréhender la bonne
formalisation des exigences

5. Les Exigences…
de la théorie,
à la pratique !
L’ingénierie des Exigences…

6. Différentes catégories d’exigence…
1) Une condition ou une capacité dont a besoin une partie prenante pour résoudre un
problème ou atteindre un objectif.
2) Une condition à laquelle la solution (ou une composante de la solution) doit répondre ou
une capacité qu’elle doit posséder pour respecter un contrat, une norme, une
caractéristique ou tout autre document officiellement exigé.
3) Une représentation documentée d’une condition ou d’une capacité décrite en 1. ou en 2.
ci-dessus.
Catégorie d’exigences (ex. une nouvelle Solution de Réservation de voyages) :
 Fonctionnelle  « Le voyageur doit pouvoir demander à entrer en
communication avec le poste de contrôle »
 Non-Fonctionnelle  « Le sysème doit protéger les données des utilisateurs contre une
utilisation frauduleuse »
 Contrainte  « L’application doit fonctionner, quelque soit le navigateur utilisé »
 Migration  « Les utilisateurs doivent pouvoir retrouver leurs données
personnelles lors du démarrage de la nouvelle solution »

7. Exemples de catégories d’exigences
Functional
requirements
Non-functional
requirements
behaviour
function
reliability
maintainability
availability
security
safety
human factors
development,
production,
delivery
design
performance
costs / time
Constraints
SYSTEM
integration
verification,
validation
data
Define non-functional characteristics of the system,
e.g. reliability, safety...
Define what the system must do,
i.e. task, action or activity which must be
carried out
Describe the factors which limit system
development e.g. design constraints
which limit design flexibility, such as
environment conditions, customer,
legislation… design features which cannot
be traded off

8. Passer du Besoin à la Solution…
Besoin Je dois pouvoir me rendre de Lyon à Londres pour Noel
Comment satisfaire le besoin ?
Solution A. par avion / 250 EUR
Solution B. par train / 225 EUR
Solution C. en voiture / 340 EUR
Besoins additionnels (non exprimés)  Passeport (+ 86 EUR) ou
carte d’identité valide (délai de renouvellement : 2 mois).
 Les exigences définissent ce dont l’entreprise a besoin.
 La conception définit comment une solution satisfait ces besoins.
Etre plus rapide
Le cheval vapeur

9. Besoin versus Solution
Besoins
Exigences
Utilisateur
Domaine
du Besoin
Domaine
de la Solution
Exigences
Système
Ce que l’utilisateur
demande
Ce que le système
doit faire
Comment le système
est conçu
Conception
Développement
“Never tell people how to do
things. Tell them what to do,
and they will surprise you
with their ingenuity.”
Général Patton
Concepts & vocabulaire :
1) Besoin : objectif ou résultat souhaité, relatif à une Exigence utilisateur
2) Fonction : relative à une Exigence système
3) Contrainte : Condition sur le besoin/fonction
4) Performance : Quantification du besoin/fonction

10. Discussion – Besoin versus Solution
 Quelles sont les exigences utilisateur d’un carrefour à feux tricolores ?

11. Différencier le Besoin de la Solution
Besoin / Problème
 Exigences Utilisateur
 Une description du besoin
/ problème et de son
contexte
 Ce que veulent les parties
prenantes et ce qu’elles
attendent du système
= Propriété des parties
prenantes
Solution
 Exigences Système
 Une représentation
abstraite de la solution
 Ce que le système doit
faire
= Propriété des concepteurs
« La partie prenante doit pouvoir … » « Le système doit … »

12. Ex. de déclinaison en Exigence Solution
Exigences fonctionnelles
Le conducteur doit pouvoir
parcourir 800 km en autonomie
complète.
Exigences de sécurité
En cas de panne, le conducteur doit
pouvoir signaler sa position à une
distance de 200 mètres.
Contraintes
Le véhicule doit coûter au maximum
10 000 euros.
Exigences fonctionnelles
Le véhicule doit consommer en
moyenne 6l de carburant pour
100 km.
Exigences non-fonctionnelles
Le véhicule doit être équipé d’un
triangle rouge et d’un gilet jaune
fluorescent conformes à la
réglementation en vigueur.
Exigences Utilisateur Exigences Solution
Exigences
non-fonctionnelles

13. On décrit une “exigence” par…
 Un énoncé qui traduit ou exprime une capacité requise pour :
 Répondre à un besoin*
 Résoudre un problème
 Tenir compte des contraintes (techniques, coûts, délais…)
 Cet énoncé est rédigé dans un langage clair et précis qui peut
prendre la forme :
 d’un langage naturel
 d’une expression mathématique, informatique, schématique ou autre
(vues, UML…)
*Le besoin correspond aux attentes initiales (formulées ou non) des parties
prenantes du projet avant toute transformation sémantique en exigences

14. Enoncé d’une Exigence
 Ecrire une phrase simple, courte, complète et consistante
 Syntaxe :
[Condition], Sujet, Verbe, Complément (Résultat, [Performance])
 Spécifie :
 Le but ou le résultat à atteindre (exigence utilisateur)
 La fonction (exigence système)
 Une qualité
 Sinon une contrainte
 Contient les critères de vérification de l’exigence

15. Evaluation d’une Exigence
Le fermier doit être capable de creuser un trou de 40 cm de diamètre,
d’une profondeur de 4 mètres en moins de 2 heures.
 Points positifs :
 La partie prenante est identifiée fermier
 Le résultat est défini creuser un trou
 La performance est quantifiée trou de 40cm x 4m en moins de 2h
 Mais, 3 questions clés :
 Pourquoi? Quel est le but ?
 Est-ce réalisable ? Y’a-t-il d’autres solutions possibles ?
 Comment vérifier que l’exigence est satisfaite ?

16. Discussion – Besoin versus Souhait
Considérez l‘exemple d’exigence suivant, qui exprime ce que
le client pense avoir besoin (ce qu’il souhaite donc) :
“La boite doit être verte.”
Il vous faut comprendre quel est le réel besoin et en conclure que la
boite verte n’est qu’une des solutions candidates au réel besoin.
Toujours se demander “pourquoi” ?

17. Propriétés d’une Exigence
 Chaque exigence doit être :
 Claire : clairement compréhensible,
 Atomique : un seul élément identifiable,
 Concise : une seule phrase,
 Unique : une identification unique,
 Réalisable : techniquement possible (coût et calendrier),
 Précise : non interprétable,
 Vérifiable : par des moyens de vérification connus,
 Abstraite : ne pas imposer une solution,
 Traçable : remontée vers la source,
 Justifiable : justifie l’existence de l’exigence.
 Qualités attendues des exigences :
 SMART (Spécifique, Mesurable, Atteignable, Réaliste, Testable)
 MUST (Mesurable, Utile, Simple, Traçable)

18. Discussion - Familles d’exigences
Vous entrez dans un magasin de dégustation de café.
 Que demandez-vous au serveur ?
 Mais qu’attendez-vous ?

19. Familles d’exigences Explicites / Implicites
• Les parties prenantes ont tendance à
ne spécifier que ce qui semble être
important à leurs yeux.
• Ils ne voient pas forcément ce qui
nécessaire et essentiel à la réussite
de la réalisation de la solution.
• Il faut donc savoir reconnaître ces
manques et les combler.
Ne pas considérer les exigences implicites conduit inévitablement à des problèmes
Explicites
Implicites

20. Les Exigences…
de la théorie,
à la pratique !
L’ingénierie des Exigences…

21. Modélisation et Exigences
 Comprendre et analyser un problème grâce à l’abstraction
 Diagramme de contexte - modélise les interactions avec l'environnement
 Scénarios - modélisent la façon dont le système sera utilisé
 Cas d’utilisation - modélise des fonctionnalités
 Mieux communiquer avec les parties prenantes
 Améliorer la complétude en identifiant de nouvelles exigences
Prof. George E. P. Box
“All models are
wrong; some models
are useful”

22. Langage naturel et modèles conceptuels
La combinaison du langage naturel et des modèles conceptuels d’exigences
permet d'exploiter les bénéfices et de limiter les défauts propres à
chaque forme de documentation.
Exemple :
R14
R13
R12
Rxx ?
Rxx ?

23. Concepts MBRE
Model Based Requirements Engineering
REQ-PP-COMPTA-0010
Le service comptabilité doit pouvoir effectuer
sa comptabilité générale.
Priorité : Forte
Couvre : N/A
REQ-MOD-COMPTA-0020
Le module COMPTA doit permettre de gérer
les factures et avoirs.
Priorité : Forte
Couvre : REQ-PP-COMPTA-0010
Spécification fonctionnelle
Spécification de la solution
REQ-MOD-COMPTA-0030
Le module COMPTA doit permettre de gérer
1000 dépenses spéciales.
Priorité : Forte
Couvre : REQ-PP-COMPTA-0010
REQ-MOD-COMPTA-0035
Le module COMPTA doit permettre de trier
les opérations par ordre chronologique.
Priorité : Forte
Couvre : REQ-PP-COMPTA-0010
Justifie
Justifie
Satisfait
1- Exigences Fonctionnelles
1.1 – Le service comptabilité
Justifie
REQ-PP-COMPTA-0015
L’assistant comptable doit pouvoir se connecter
au Système d’Information.
Priorité : Forte
Couvre : N/A
Justifie
Diagramme
de contexte
Diagrammes
de UC
Scénarios
Diagrammes
de classes
Diagrammes
de séquences
Diagrammes
d’activités
Diagrammes
d'états
IE centrée sur les documents
Domaine
du
Problème
Domaine
de la
Solution
(MOA)
(MOE)
Avec l’appui des modèles

24. Les Exigences…
de la théorie,
à la pratique !
L’ingénierie des Exigences…

25. TP - Identification d’exigences
 Dans le document à analyser, constituer le référentiel
d’exigences en identifiant et reformulant :
 les exigences utilisateurs
 les exigences système

26. TP- Revue d’exigences
 Passer en revue les exigences énoncées :
 Sont-elles exprimées en phrases ?
 Les parties-prenantes ou le système sont-ils bien identifiés ?
 Les exigences utilisateurs expriment-elles un besoin ?
 Les exigences sont-elles vérifiables ?
 Les exigences respectent-elles les critères d’une bonne “exigence” ?

27. Votre avis, votre expérience ?