Chapitre 3: exigences et ingénierie des besoins

1 Chapitre 3 1 Exigences et spécifications : Définition et catégorisation

2 Ingénierie des besoins

Exigences et ingénierie des  Étude de faisabilité

besoins  Analyse des besoins

 Spécification des exigences

 Validation de la spécification

L’importance des exigences Définition du terme exigence

3 4

 Les exigences influent toutes les phases de développement du Selon IEEE 610.12, une exigence est :
logiciel :  Une condition ou une capacité nécessaire à un utilisateur pour
o Architecture du système résoudre un problème ou atteindre un objectif
o Conception  Une condition ou une capacité que doit posséder un système afin
o Définition des tests de satisfaire aux termes d'un contrat, d’une norme ou d’une
o Validation spécification formellement imposée.

o Acceptation  La représentation documentée de cette condition ou capacité.

Une exigence exprime donc :
o Etc.
 Tout ce que le client veut
 Tout ce qui est nécessaire pour le développement du logiciel

1
 Définition du terme spécification
5 6
Selon IEEE 830 une spécification d’exigences comprend :
 Les fonctionnalités : services et fonctions que le système doit
fournir.
 Les interfaces externes : identification des interactions avec les
utilisateurs et les autres systèmes avec lesquels le nouveau système
doit s'intégrer.
 La performance : contraintes d'opération du système en
disponibilité et en temps réponse.
 Les attributs du système : caractéristiques intrinsèques telles que la
portabilité, l'exactitude, la maintenabilité, la sécurité, etc.
 Les contraintes de conception : contraintes sur la façon de
développer le système.
Catégorisation des exigences
7 8
 Exigences utilisateur :
o Indiquent ce que le logiciel doit faire et sous quelles
conditions de fonctionnement ;
 Exigences système :
o Indiquent des éléments sur le fonctionnement du logiciel
(ergonomie des interfaces, aspects graphiques...) ;
 Exigences logiciel :
o Apportent des détails sur des contraintes de conception et
implantation.
Catégorisation des spécifications
Deux points de vue dans la description d’un système :
 Point de vue externe celui des utilisateurs non
informaticiens, des décideurs :
o On définit une spécification des besoins : une description
de haut niveau d’abstraction des services que doit rendre le
système et les contraintes sous Lesquelles il opère.
 Point de vue interne celui des concepteurs, du personnel
technique :
o On définit une spécification du système : une description
la plus précise possible du système qui doit être réalisé.
Exigences du système
Trois grandes catégories d’exigence du système :
 Exigences fonctionnelles indiquent :
o Ce que le système doit faire
o Les liens entre les entrées et sorties du système.
 Exigences non fonctionnelles :
o Indiquent des contraintes sur la manière dont le service du
système est rendu.
o Exp: contraintes de temps, règles de développement, etc.
 Exigences du domaine :
o Ce sont des exigences, fonctionnelles ou non fonctionnelles,
issues du domaine d’application du système et qui reflètent
les caractéristiques du domaine
2
 Exigences fonctionnelles
9 10
 Les exigences fonctionnelles :
o Décrivent la fonctionnalité ou les services du système
 Exemple de besoins fonctionnels :
o Le logiciel doit gérer la facturation des ventes
o Le système doit fournir la facture des ventes toujours sur la
base d’une commande client
o Le logiciel ne doit accepter que les règlements par chèque
o Le logiciel doit afficher la liste des produits achetés par
client
o Le logiciel doit afficher la liste des factures non réglées
Exigences non fonctionnelles
11
Propriétés des exigences
Les exigences doivent être complètes :
o Inclure les descriptions de toutes les fonctionnalités et
les services requis
 Les exigences doivent être cohérentes:
o Absence de conflits et de contradictions dans les
descriptions des fonctionnalités et services du système
 Dans la pratique, il est difficile de produire un
document des besoins complet et cohérent
Exigences non fonctionnelles
12
 Exigences produits :
o Spécifient que le logiciel produit doit se comporter
avec une manière particulière exp: vitesse d’exécution,
fonctionnel sur plusieurs plateformes, etc.
 Exigences organisationnelles :
o Résultent des contraintes d’ordre politiques et
organisationnel
 Exigences externes
o Proviennent de facteurs externes au système et au
processus de développement. Ex: législation.
3
 Exigences orientés-produit Exigences orientés-produit
13 14

 Performance  Portabilité : fonctionne sur plusieurs plateformes

 Utilisabilité : effort requis pour apprendre, utiliser, fournir
 Modifiabilité : ajout de nouvelles fonctionnalités
l’entrée et interpréter les sorties d’un programme.
 Efficacité : usage minimal de ressources: mémoire, processeur,  Réutilisabilité : de composantes, de code, de
etc. designs, et même d’exigences dans d’autres
 Fiabilité: des calculs, de la précision systèmes
 Sécurité
 Robustesse : en présence de données invalides…
 Adaptabilité : à d’autres environnements ou problèmes
 Passage à l’échelle : pour grandes quantités ou données
 Coût: coût total de possession (TCO): achat, installation, usage

Exigences orientés-processus Mesure des besoins non fonctionnelles

15 16

Propriété Mesure
 Maintenabilité : modifications de fonctionnalités,
Vitesse Nombre de transactions par second (instruction/ seconde)
corrections Temps de réaction
Temps de rafraîchir l’écran
 Lisibilité : code, documents
Taille Kbytes, Mbytes, GBytes
 Testabilité : facilité à tester Facile pour utiliser Temps pour formation
Nombre d’écrans pages d’aide
 Compréhensibilité : conception, architecture et code
Fiabilité Temps moyen sans panne
facile à comprendre/apprendre Probabilité de refus d’accès
Fréquence d’apparition d’erreurs
 Intégrabilité : facilité à intégrer des composantes Disponibilité

 Complexité : degré d’interaction entre modules Robustesse Temps de restart après une panne.
Pourcentage des événements causant une panne
Probabilité de perte ou corruption des données
Portabilité Pourcentage des instructions qui son machine dépendantes.
Nombre de systèmes cibles

4
 Définition de l’ingénierie des besoins
17 18

 Processus qui a pour objet d'établir et de maintenir

un accord avec les parties prenantes sur les
2 Ingénierie des besoins exigences du système à construire.
Étude de faisabilité  Bonnes pratiques permettant de définir le contexte
Analyse des besoins de travail au sein d'un projet, à la fois d'un point de
Spécification des exigences vue contractuel et technique.
Validation de la  But: Réaliser un système conforme au juste
spécification besoin

Processus de l’ingénierie des besoins Processus de l’ingénierie des besoins

19 20

 Etude de faisabilité
o Vision, besoin ou opportunité d’affaire, étendue du système,
risques, etc.
 Explicitation et analyse des exigences
o Les exigences sont découvertes en consultant (et parfois
même en provoquant) les diverses parties prenantes.
o Les exigences sont analysées et les conflits résolus, souvent
par négociation.
 Spécification des exigences
o Un document précis décrivant les exigences est produit.

5
 Processus de l’ingénierie des besoins Étude de faisabilité
21 22

 L’étude de faisabilité sert à décider si l’étude du système

 Validation des exigences mérite un approfondissement ou si elle doit être suspendue.
o La spécification des exigences est vérifiée en termes de  L’objectif de cette phase est de répondre aux questions
suivantes :
cohérence et de complétude.
o Est-ce que le système va contribuer au développement de
 Gestion des exigences l’organisation ? Apporte-t-il un plus ? En quoi va-t-il aider à
o Maintenir la cohérence entre les exigences et l'ensemble des résoudre des problèmes s’il y en a ?
produits de l'ingénierie. o Est-ce que le système peut être réalisé avec la technologie
actuelle, dans les délais requis et avec les coûts indiqués ?
o Es-ce que le système peut être intégré aux autres systèmes
déjà existants ?

Étude de faisabilité Analyse des besoins

23 24

 Il faut déterminer les personnes intéressées par le système  L’analyse des besoins a lieu une fois que l’étude de
(stakeholders) et procéder à une extraction d’information faisabilité a reçu une réponse positive.
 Exemples de questions à poser :
 On doit alors expliciter et analyser les besoins.
o Que feriez-vous si le système n’était pas implémenté ?
o Quels sont les problèmes avec les systèmes existants ?
o Il s’agit d’une extraction minutieuse d’information.
o Pourquoi un nouveau système améliorerait cette situation ?
o Quelle contribution directe apporterait un tel système sur votre  Il est nécessaire de :
travail ?
o Définir les personnes affectées (stakeholders) par le
o Est-ce que des informations sont partagées avec des systèmes
système
externes ?
o Est-ce que le système nécessiterait une technologie inconnue des o D’évaluer leurs besoins par ordre d’importance
utilisateurs ? Quel serait du ressort du système et qu’est-ce qu’il
ne le serait pas ?

6
 Identification des exigences et leur analyse
25
 L’identification des exigences est liée à chaque domaine de systèmes
(banques, automobile, commande d’installation industrielle,
multimédia...).
 Les questions à se poser pour déterminer ce que doit faire le système sont
donc étroitement liées à la nature du système :
o Il faut être capable de répertorier les exigences,
o les classer par catégorie,
o leur donner des priorités,
o Et de déterminer à ce niveau les liens entre les différentes exigences,
Identification des exigences et leur
27
analyse
 L’équipe responsable de l’analyse des exigences doit alors :
o Communiquer avec d’autres équipes
o Utiliser leur savoir-faire,
o Eviter les erreurs commises dans d’autres projets
o Identifier des exigences même de manière partielle, voire
très incomplète, en identifiant des aspects au sujet desquels
le client ne connaît pas encore ce qu’il souhaite,
o Marquer ces exigences et revenir sur ces aspects plus tard.
(Ainsi, c’est mieux que de les ignorer totalement).
o En d’autres termes, il faut prévoir des changements dans la
spécification des exigences, voire des zones d’ombre
Identification des exigences et leur analyse
26
 Le travail est itératif et peut se poursuivre en parallèle avec le
BD, début des autres étapes du cycle de développement.
 Beaucoup de praticiens dans le GL conseillent l’identification
des scénarios de fonctionnement du système (cas d’utilisation
d’UML) pour mieux voir les interactions du système avec son
environnement et les interactions entre les sous-systèmes.
 Certains scénarios (cas courants d’utilisation) sont souvent
faciles à déterminer
 D’autres scénario au contraire ne peuvent être identifiés que
très tard dans le cycle de vie ou carrément une fois que le
système réalisé se trouve en situation d’échec (on ne peut pas
tout prévoir !)
Les personnes affectées par le système
28
 Les difficultés de l’interaction avec les personnes
affectées par le système sont multiples :
o Elles sont pour la plupart étrangères à l’informatique et
décrivent donc leur interaction avec le système en utilisant
des termes imprécis
o Elles n’ont pas de notion de ce qui est réalisable ou non.
o Elles n’ont pas conscience de la connaissance implicite sur
leur travail qu’elle véhicule dans leur discours.
o Les différentes stakeholders ont des besoins et des points de
vue différents (conflictuels), sur le système et la
hiérarchisation des fonctionnalités.
o Des considérations politiques peuvent rentrées en jeu.
o L’environnement économique, par définition changeant,
joue un rôle important sur l’évolution possible du système.
7
 Spécification des exigences Validation de la spécification
29 30

 Après avoir identifié et classé les exigences, il faut utiliser
des techniques formelles ou non pour spécifier ces
exigences.
 La spécification consiste à :
o Décrire les exigences en vue d’une utilisation dans les phases
suivante du cycle de développement.
o Construire une représentation tangible (un document) des
besoins,
 La tendance est de plus en plus vers l’utilisation de
techniques formelles (ou au moins semi-formelles) pour
spécifier les exigences.
 Un document précis décrivant les exigences est produit au cours de
cette phase .
 La validation de la spécification vise à montrer que
les besoins explicités correspondent effectivement à
ceux des utilisateurs du système.
 Elle sert aussi à débusquer les erreurs dans le
cahier des charges
 Dans le cas général, détecter une erreur dans la
spécification une fois que la conception, le
développement et la validation du système sont
terminés impliquent une nouvelle passe sur plusieurs
phases

Procédés de vérification Points de vérification

31 32

 Il faut toujours valider les exigences avant de passer aux

 Relecture systématique (reviews) du cahier des
charges par un ou plusieurs tiers.
 Écriture d’un prototype. (cf. les processus
évolutifs)
 Génération de cas des tests exécutables (test cases).
(cf. Extreme Programming)
phases suivantes du cycle de développement du logiciel.
 Si les erreurs et mauvaises interprétations sont découvertes
tard dans le cycle de développement, elles coûtent cher (voire
très cher) pour être corrigées.
 Pendant l’étape de validation, plusieurs contrôles doivent être
effectués :
o Contrôle de validité : est-ce les fonctions sont prévues pour
être utilisées par les bons acteurs, aux bons endroits, dans
les bonnes conditions ?

8
 Points de vérification Management d’une spécification
33 34

o Contrôle de cohérence : est-ce que certaines exigences ne
sont pas en conflit ou contradictoires avec d’autres ?
o Contrôle de complétude : est-ce tout ce dont a besoin a été
dit pour concevoir et réaliser le système ?
o Contrôle de réalisme : est-ce les objectifs fixés peuvent être
atteints avec les technologies ciblées ?
o Vérifiabilité : pour éviter les malentendus avec le client,
contrôler si tout a été écrit de manière à pouvoir vérifier
assertions (affirmations, dires, discours...) des uns et des
autres. Cette vérifiabilité est facilitée par l’utilisation de
méthodes de spécification formelles.
 Garder une trace de l’évolution d’une spécification est
essentiel car elle peut servir à justifier les choix qui ont été pris
(Eviter de revenir en arrière dans le développement)
 Maintenir une dépendance entre les différentes parties de la
spécification permet de déterminer rapidement les parties
impactées par une modification ou la prise en compte d’une
meilleure compréhension d’un point donné.
 Lorsqu’une modification de la spécification est issue d’une
évolution du logiciel, on peut évaluer les coûts et les
conséquences en termes de modifications de l’implémentation
plus efficacement.

Références
35

 Cours de Génie Logiciel By Dr. YENDE RAPHAEL Grevisse, 2019 à cette @

https://hal.archives-ouvertes.fr/cel-02116792
 Ian Sommerville, Software Engineering, Pearson, 9ème édition, 2010.
 B. Elhaddah, J. Oger, Scrum, de la théorie à la pratique,
 Y. Constantinidis, Expression des besoins pour le SI (3e édition). N°14331, 2015.
 Cours de Software Engineering du Prof. Bertrand Meyer à cette @:
http://se.ethz.ch/teaching/ss2007/252-0204-00/lecture.html
 Cours IGL de M. A. Mostefai et S. Batata (2011) à cette @:
https://fr.slideshare.net/mostefaiamine/igl-cours-4-expression-de-besoins
 Cours Éléments de génie logiciel, A. JMAL MAALEJ, R. ELLOUZE, S. BOUAZIZ, 2014.