GÉNIE LOGICIEL

(SOFTWARE ENGINEERING)

3ÈME PARTIE – INGÉNIERIE DES BESOINS

(REQUIREMENT ENGINEERING)

Faculté des Sciences et Techniques

http://perso.univ-st-etienne.fr/jacquene/gl/

Francois.Jacquenet@univ-st-etienne.fr
 Plan de cette partie de cours
2

 Exigences fonctionnelles et non fonctionnelles

 Le document définissant les exigences logicielles
 Spécification des exigences
 Le processus d’ingénierie des exigences
 Elicitation et analyse des exigences
 Validation des exigences
 Management des exigences
 Ingénierie des exigences
3

 Processus qui définit les services attendus par le

client d’un système et les contraintes sous lesquelles
il s’exécutera et sera développé.

 Les exigences elles même correspondent aux

descriptions des services du système et les
contraintes mises en avant durant ce processus
d’ingénierie des exigences.
 Qu’est-ce qu’une exigence ?
4

 Peut aller d’une vision abstraite d’un service ou

d’une contrainte d’un système à une spécification
fonctionnelle mathématique détaillée
 Provient du fait que l’ingénierie des exigences
 Peut être la base d’une négociation d’un contrat  doit de
ce fait être ouverte aux interprétations
 Peut être la base du contrat lui même  doit être défini
suffisamment en détail
 Les différents types d’exigences
5

 Exigences utilisateur
 Enoncé en langage naturel (plus des diagrammes) des
services que le système proposera et ses contraintes
opérationnelles.
 Ecrites pour les clients

 Exigences système
 Un document structuré décrivant en détail les fonctions
du système et les contraintes.
 Définit ce qui devrait être implémenté et peut être faire
partie du contrat entre le client et l’informaticien.
 Exemple1
6

 Système d’information pour la gestion de patients

atteints de problèmes psychiatriques
 Pas d’hospitalisation des patients
 Rendez vous réguliers avec des médecins
 Rendez vous dans divers dispensaires
 Système de gestion de patients en
soins pychiatriques (SG-PSP)
7

 Le système de gestion de patients en soins

pychiatriques (SG-PSP) est un système d’information
visant à être utilisé dans les dispensaires
 Utilise une base de données centralisée contenant
des informations sur les patients
 Peut être utilisé sur un PC non connecté
 Lorsque les systèmes locaux ont un accès réseau 
 Accès à la BD centralisée
 Téléchargement et usage local de copies des infos
clients en mode déconnecté
 Objectifs du SG-PSP
8

 Générer des informations utiles aux managers pour

évaluer les performances des soins vis-à-vis des
objectifs locaux et gouvernementaux

 Fournir au personnel médical des informations à jour

sur le patient pour aider à son traitement
 Organisation du SG-PSP
9

PC local PC local PC local

SG-PSP SG-PSP SG-PSP

Serveur SG-PSP

Base de Données
Patient
 Principales caractéristiques du SG-PSP
10

 Gestion des soins individuels

 Le personnel médical peut
 Créer des dossiers pour les patients
 Éditer les informations contenues dans le système
 Visualiser l’historique des patients
 Le système doit être capable de gérer des synthèses afin que les médecins puissent
rapidement comprendre les problèmes clés et les traitements qui ont été prescrits.
 Contrôle des patients
 Le système doit contrôler les enregistrements des patients et détecter des
problèmes, déclenchant alors des alarmes
 Rapports administratifs
 Le système réalise des rapports mensuels montrant le nombre de patients traités
dans chaque dispensaire, le nombre de patients ayant quitté ou rejoint le système
de soins, les médicaments prescrits, leurs coûts, etc
 Points cruciaux du SG-PSP
11

 Respect de la vie privée (privacy)

 Les informations relatives aux patients doivent être
confidentielles
 Visibles que par le personnel médical autorisé et par le
patient lui même
 Sécurité (Safety)
 Certaines maladies peuvent conduire les patients à être
suicidaires ou à être dangereux pour les autres  alarme
envers le personnel médical dans de telles situations
 Le système doit être accessible lorsqu’il y en a besoin, sinon
il peut être impossible de prescrire correctement un soin aux
patients
 Exemple 2
12

 Pompe à insuline personnelle

 Système embarqué dans une pompe à insuline
 Utilisée par les diabétiques pour gérer le niveau de
glucose dans le sang
 Système de contrôle d’une pompe à
insuline
13

 Collecte les données d’un capteur de sucre sanguin et

calcule la quantité d’insuline devant être injectée
 Calculs basés sur le taux de changement des niveaux
de sucre dans le sang
 Envoi des signaux à une micro pompe pour injecter la
dose correcte d’insuline
 Système critique car des faibles taux de sucre dans le
sang peuvent conduire à des disfonctionnements
cérébraux, des comas, voir la mort. Inversement, de
hauts niveaux de sucre dans le sang peuvent avoir des
conséquences dramatiques, par exemple sur les yeux,
les reins…
 Modèle d’activité de la pompe à insuline
(diagrame UML)
14
 Exigences utilisateurs et système (SG-PSP)
15

 Exigence utilisateur
 Le SG-PSP doit générer tous les mois des rapports montrant le coût des
médicaments prescrits par chaque dispensaire durant ce mois

 Exigences système
 Le dernier jour de chaque mois le système doit générer une liste des médicaments
prescrits, leur coûts et les dispensaires qui les ont prescrit
 Le système doit autmatiquement générer le rapport à imprimer à 17h30 du dernier
jour travaillé du mois
 Un rapport doit être généré pour chaque dispensaire et doit lister les noms des
médicaments, le nombre total de perscriptions, le nombre de doses préscrites et le
coût total des médicaments prescrits
 Si des médicaments sont disponibles avec différents dosages, des rapports
différents doivent être générés pour chaque dosage
 L’accès aux rapports doit être limité aux personnels autorisés listés dans une liste de
contrôle d’accès gérée par la direction
 Exigences utilisateur et système (SG-PSP)
16

Managers client
Ingénieurs client
Exigences Utilisateurs finaux
Utilisateur Architectes logiciel
Managers fournisseur

Ingénieurs clients
Exigences Utilisateurs finaux
Système Architectes logiciel
Développeurs logiciel
 Exigences fonctionnelles et non fonctionnelles
17

 Exigences fonctionnelles
 Enoncé des services que le système doit fournir
 Comment le système devrait réagir aux diverses entrées
 Comment le système devrait se comporter dans les diverses situations
 Peut également énoncer ce que le système ne devrait pas faire
 Exigences non fonctionnelles
 Contraintes sur les services et fonctions offertes par le système
 Contraintes de temps
 Contraintes sur le processus de développement
 Utilisation de standards
 S’applique souvent au système global plutôt qu’à des fonctions
particulières
 Exigences de domaine
 Contraintes sur le système dans son contexte d’utilisation
 Exigences fonctionnelles
18

 Décrivent les fonctionnalités du système

 Dépendent du type de logiciel, des utilisateurs
attendus et du type d’installation où le logiciel est
utilisé
 Les exigences fonctionnelles utilisateur peuvent être
des énoncés de haut niveau décrivant ce que le
système doit/devrait faire
 Les exigences fonctionnelles système décrivent les
fonctionnalités en détail
 Exemples d’exigences fonctionnelles
pour le SG-PSP
19

 Un utilisateur doit pouvoir rechercher les listes de

rendez vous de tous les dispensaires
 Le système doit générer chaque jour, pour chaque
dispensaire, une liste des patients ayant un rendez
vous pour ce jour
 Chaque membre du personnel médical utilisant le
système doit être identifié de façon unique par son
numéro d’employé sur 8 chiffres
 Imprécision des exigences
20

 Problèmes lorsque les exigences ne sont pas

définies précisément
 Exigences ambigües  diverses interprétations
selon développeurs et utilisateurs
 Exemple : “rechercher” dans exigence 1
 Selon utilisateur : rechercher un nom de patient dans
tous les rendez vous de tous les dispensaires
 Selon développeur : rechercher un nom de patient dans
un dispensaire. L’utilisateur choisit auparavant un
dispensaire avec la recherche du patient
 Complétude et consistance des exigences
21

 En principe les exigences doivent être complètes et

consistantes
 Complètes
 Doivent décrirent TOUTES les fonctionnalités
 Consistantes
 Pas de contradictions dans les descriptions des
caractéristiques du système
 En pratique : impossible de produire un document
complet et consistant
 Exigences non fonctionnelles
22

 Définissent les propriétés et contraintes du système

 Fiabilité
 Temps de réponse
 Taille de stockage
 Etc
 Exigences sur le processus de développement
 Environnement de développement
 Langage de programmation
 Méthode de développement
 Ces exigences peuvent être plus critiques que les
exigences fonctionnelles  si elles ne sont pas
satisfaites le système peut devenir inutilisable/inutile
 Mise en oeuvre des exigences non fonctionnelles
23

 Les exigences non fonctionnelles peuvent toucher l’ensemble

du système plutôt que des composants individuels
 Exemple : exigences de performance  minimiser les
communications entre composants
 Une simple exigence non fonctionnelle, par exemple
concernant la sécurité, peut générer des exigences
fonctionnelles définissant une fonctionnalité qui est alors
nécessaire
 Exemple : le système doit être accessible aux médecins et
infirmières  page de login/password
 Cela peut aussi générer des exigences qui vont restreindre des
exigences existantes
 Classification des exigences non fonctionnelles
24

Exigences
Non fonctionnelles

Exigences Exigences Exigences

produit organisationnelles externes

Exigences Exigences Exigences Exigences Exigences Exigences

d’efficacité fiabilité sécurité de contrôle éthiques législatives

Exigences
Exigences Exigences Exigences
d’utilisabilité
environnementales d’exécution de développement

Exigences Exigences
Exigences Exigences
de performance d’espace
comptables sécurité
 Classification des exigences non fonctionnelles
25

 Exigences produit
 Exigences qui spécifient que le produit à concevoir doit se comporter
d’une façon particulière (vitesse, fiabilité, etc)
 Exigences organisationnelles
 Exigences qui résultent de politiques organisationnelles, de procédures
(standards, etc)
 Exigences externes
 Exigences provenants de facteurs externes au système et à son processus
de développement (lois, éthique, etc)
 Exemples d’exigences non
fonctionnelles pour le SG-PSP
26

 Exigences produit
 Le SG-PSP doit être accessible à tous les dispensaires durant les
horaires de travail (lundi au vendredi, 8h30 à 18h). Le temps d’arrêt du
système durant les horaires de travail ne doit pas dépasser 5 secondes
par jour.
 Exigences organisationnelles
 Les utilisateurs du SG-PSP doivent s’authentifier en utilisant leur carte
d’identité médicale
 Exigences externes
 Le système doit implémenter le dispositif de protection de la vie
privée tel que décrit dans HSteNord-03-2010-priv
 Différence entre objectifs et exigences
27

 Les exigences non fonctionnelles peuvent être très difficiles à définir de

façon précise mais des exigences imprécises peuvent être difficiles à
vérifier
 Objectif
 Une intention générale
 Exemple : “facile d’utilisation”
 Exigence non fonctionnelle et vérifiable
 Un énoncé utilisant une mesure qui peut être objectivement testée
 Exemple : “le système ne doit pas nécessiter plus de 4h d’apprentissage”
 Les objectifs sont toutefois utiles aux développeurs du fait qu’ils
contiennent les intentions des utilisateurs du système
 Objectifs et exigences (SG-PSP)
28

 Le système devrait être facile d’utilisation par l’équipe

médicale et devrait être conçu de telle façon que les
erreurs utilisateur soient minimisées (objectif)

 L’équipe médicale doit être capable d’utiliser les

fonctions du système après une formation de 4 heures.
Après cette formation, le nombre moyen d’erreurs
effectuées par des utilisateurs expérimentés ne devra
pas excéder 2 par heure d’utilisation du système
(exigence non fonctionnelle testable)
 Métriques pour spécifier des exigences
non fonctionnelles
29

Propriété Mesure
Vitesse Instructions / seconde
Temps de réponse utilisateur/événement
Temps de rafraichissement écran

Taille Mbytes

Facilité d’utilisation Temps d’apprentissage

Nombre d’écrans d’aide
Fiabilité Temps moyen entre deux incidents
Probabilité d’inacessibilité
Taux d’erreurs
Disponibilité

Robustesse Temps pour redémarrer après incident

Pourcentage d’événements causant des incidents
Probabilité de corruption des données lors
d’incidents

Portabilité Pourcentage d’instructions dépendant du matériel

Chapter 4 Requirements
Nombre deengineering
systèmes cibles
 Exigences de domaine
30

 Le domaine de fonctionnement opérationnel du système

impose parfois des exigences sur le système
 Exemple : le système de contrôle d’un train doit prendre en
compte les caractéristiques de freinage dans diverses
conditions météorologiques
 Les exigences de domaine peuvent être de nouvelles
exigences fonctionnelles, des contraintes sur des
exigences existantes ou définir des calculs spécifiques
 Si les exigences de domaine ne sont pas satisfaites, le
système peut ne pas être utilisable
 Exigences de domaine
31

 Exemple d’exigence de domaine pour un système

de protection de train
 La décélération du train doit être calculée comme suit :
 Dtrain = Dcontrol + Dgradient
 Avec Dgradient = 9.81ms2 * gradient compensé /α avec
9.81ms2 /α qui a des valeurs connues pour divers types de
trains
 Il est difficile pour un non spécialiste de comprendre
les implications de cela et comment cela interagit
avec les autres exigences
 Problème des exigences de domaine
32

 Compréhensibilité
 Lesexigences sont exprimées dans le langage du
domaine d’application
 Cela n’est en général pas compris par l’informaticien
développant le système
 Information implicite
 Les spécialistes d’un domaine comprennent tellement
bien ce domaine qu’ils n’ont pas idée de rendre les
exigences de domaine explicites
 Le document de spécification des exigences
33

 Le document de spécification des exigences est

l’énoncé officiel de ce qui est attendu de la part
des développeurs du système
 Devrait inclure à la fois
 Exigences utilisateur
 Exigences système

 Ce n’est pas un document de conception

 Il privilégie le QUOI sur le COMMENT
 Exigences et méthodes agiles
34

 Les méthodes agiles pensent que produire un document

de spécification des exigences est une perte de temps
tellement les exigences changent rapidement
 De ce fait le document est toujours obsolète
 Des méthodes telles que XP utilisent des techniques de
conception incrémentale d’ingénierie des exigences 
“user stories”
 Possible pour des systèmes de type “business” (BD) mais
problématique pour les systèmes nécessitant de
nombreuses analyses pré-développement (systèmes
critiques) ou les systèmes développés par plusieurs
équipes
 Utilisateurs du document de spécification
des exigences
35

Spécifient les exigences,

les lisent pour vérifier qu’elles
Clients satisfont bien leurs besoins.
Spécifient les changements
dans les exigences

Utilisent le document de
spécification des exigences pour
Managers planifier une négociation pour
le système et pour planifier le
processus de développement

Utilisent les exigences pour

Ingénieurs
comprendre le système
développement
devant être développé

Utilisent les exigences pour

Ingénieurs mettre au point les tests
tests de validation du système

Ingénieurs Utilisent les exigences pour

maintenance Comprendre le système et
les relations entre ses composants
 Variabilité du document de
spécification des exigences
36

 L’information contenue dans le document dépend du

type de système et de la méthode de
développement utilisée
 Les systèmes développés incrémentalement auront
moins de détails dans le document
 Des standards ont été conçus
 Exemple : IEEE 830-1998
 Utilisables principalement pour les exigences de
grands systèmes
 Structure du document de
spécification des exigences
37

Section Description
Préface Définit les lecteurs attendus du document et décrit l’historique de la version

Introduction Décrit le pourquoi du besoin du système à développer. Décrit brièvement

les fonctions du système et explique comment il s’articulera vis-à-vis
d’autres systèmes. Décrit également comment le système s’adapte aux
objectifs économiques et stratégique de l’organisation demandant le
développement du système.
Glossaire Définit les termes techniques utilisés dans le document. Il ne faut pas faire
de supposition sur l’expertise des lecteurs potentiels du document.
Définition des On décrit ici les services fournit par le système à l’utilisateur. Les
exigences utilisateur exigences non fonctionnelles systèmes devraient également être décrites
dans cette section. Cette section peut utiliser le langage naturel, des
diagramme, d’autres notations qui seront compréhensibles par les clients.
Les standards qui devront être respectés devriaent être spécifiés dans
cette section.

Architecture du Présente une vision de haut niveau de l’architecture envisagée du système

système montrant la répartition des fonctionnalités à travers les modules. Les
composants qui proviendront de réutilisation devraient être mis en avant.
 Structure du document de
spécification des exigences
38

Section Description
Spécification des Décrit les exigences fonctionnelles et non fonctionnelles en détail. Les interfaces
exigences système vers les autres systèmes peuvent être décrits.

Modèles du Modèles graphiques du système montrant les relations entre les composants du
système système et le système et son environnement. Exemple : use case, diagrammes
de classe, etc

Evolution du Décrit les hypothèses sur lesquelles le système est fondé et toute évolution qui
système peut être anticipée sur l’évolution du matériel, les changements des besoins
utilisateurs, etc.
Utile pour les concepteurs pour les aider à éviter des décisions de conception qui
contraindraient des changements futures du système

Annexes Contient des informations spécifiques à l’application développée, par exemple des
description de la base de données (organisation logique des données), du
matériel (configuration minimale et optimale du matériel).

Index Divers indexes au document peuvent être insérés. Index alphabétic, index des
diagrammes, index des fonctions, etc
 Le standard IEEE 830-1998
39

1. Introduction
1.1 Objet (du document)
1.2 Portée (du projet)
1.3 Définitions, acronymes, abréviations
1.4 Références
1.5 Vue d’ensemble (plan de la suite du document)
2. Description générale
2.1 Environnement
2.2 Fonctions
2.3 Caractéristiques des utilisateurs
2.4 Contraintes
2.5 Hypothèses et dépendances
3. Exigences spécifiques
4. Annexes
5. Index
 Le standard IEEE 830-1998
section 1 - Introduction
40

1. Introduction
1.1 Objet
1.2 Portée
1.3 Définitions, acronymes, abréviations
1.4 Références
1.5 Vue d’ensemble
2. Description générale
2.1 Environnement
2.2 Fonctions
2.3 Caractéristiques des utilisateurs
2.4 Contraintes
2.5 Hypothèses et dépendances
3. Exigences spécifiques
4. Annexes
5. Index
 Le standard IEEE 830-1998
section 1 - Introduction
41

1. Introduction
1.1 Objet
Formuler l’objet du document
Préciser les destinataires du document
1.2 Portée
1.3 Définitions, acronymes, abréviations
1.4 Références
1.5 Vue d’ensemble
 Le standard IEEE 830-1998
section 1 - Introduction
42

1. Introduction
1.1 Objet
1.2 Portée
Identifier le logiciel à développer par un nom
Expliquer ce que le logiciel fera et, si besoin, ne fera pas
Décrire l’application du logiciel spécifié (incluant avantages,
objectifs)
1.3 Définitions, acronymes, abréviations
1.4 Références
1.5 Vue d’ensemble
 Le standard IEEE 830-1998
section 1 - Introduction
43

1. Introduction
1.1 Objet
1.2 Portée
1.3 Définitions, acronymes, abréviations
Définition de tous les termes qui seront utilisés. Cela peut se
faire par référence à d’autres documents
1.4 Références
1.5 Vue d’ensemble
 Le standard IEEE 830-1998
section 1 - Introduction
44

1. Introduction
1.1 Objet
1.2 Portée
1.3 Définitions, acronymes, abréviations
1.4 Références
Liste complète des références utilisées dans le document
Titre, numéro de rapport), auteurs, date, éditeur
Source où les documents peuvent être obtenus
1.5 Vue d’ensemble
 Le standard IEEE 830-1998
section 1 - Introduction
45

1. Introduction
1.1 Objet
1.2 Portée
1.3 Définitions, acronymes, abréviations
1.4 Références
1.5 Vue d’ensemble
Décrit le reste du document et son organisation
 Le standard IEEE 830-1998
section 2 – Description générale
46

1. Introduction
1.1 Objet
1.2 Portée
1.3 Définitions, acronymes, abréviations
1.4 Références
1.5 Vue d’ensemble
2. Description générale
2.1 Environnement
2.2 Fonctions
2.3 Caractéristiques des utilisateurs
2.4 Contraintes
2.5 Hypothèses et dépendances
3. Exigences spécifiques
4. Annexes
5. Index
 Le standard IEEE 830-1998
section 2 – Description générale
47

2. Description générale
2.1 Environnement
Situer le produit dans le contexte des autres produits reliés
Si produit indépendant, le mentionner
Sinon :
Enoncer ici les exigences de ce système par rapport aux fonctions du logiciel
Décrire les interfaces entre le système et le logiciel
Peut être utile d’inclure un schéma fonctionnel montrant les principales composantes
du système et leurs relations, de même que les interfaces externes.
2.2 Fonctions
2.3 Caractéristiques des utilisateurs
2.4 Contraintes
2.5 Hypothèses et dépendances
 Le standard IEEE 830-1998
section 2 – Description générale
48

2. Description générale
2.1 Environnement
 Cette section devrait également indiquer à quelles contraintes doit se plier le logiciel,
notamment :
 Les interfaces avec le système
 Les interfaces avec les utilisateurs
 Les interfaces avec le matériel
 Les interfaces avec les logiciels
 Les interfaces de communication
 Les contraintes de mémoire
 Les activités
 Les exigences d’adaptation aux sites

2.2 Fonctions
2.3 Caractéristiques des utilisateurs
2.4 Contraintes
2.5 Hypothèses et dépendances
 Le standard IEEE 830-1998
section 2 – Description générale
49

2. Description générale
2.1 Environnement
2.2 Fonctions
Donner un résumé des fonctions principales que le logiciel doit exécuter
Exemple : spécification d’un programme de comptabilité 
maintenance des comptes des clients
relevés de compte
préparation des factures
sans mentionner les très nombreux détails qu’exige chacune de ses fonctions.
2.3 Caractéristiques des utilisateurs
2.4 Contraintes
2.5 Hypothèses et dépendances
 Le standard IEEE 830-1998
section 2 – Description générale
50

2. Description générale
2.1 Environnement
2.2 Fonctions
2.3 Caractéristiques des utilisateurs
Caractéristiques générales des utilisateurs du produit :
niveau d’instruction
expérience
connaissances techniques
2.4 Contraintes
2.5 Hypothèses et dépendances
 Le standard IEEE 830-1998
section 2 – Description générale
51

2. Description générale
2.1 Environnement
2.2 Fonctions
2.3 Caractéristiques des utilisateurs
2.4 Contraintes
Décrit de manière générale tout autre élément qui risque de limiter les options offertes au
concepteur, notamment :
 Politiques réglementaires
 Limites imposées par le matériel (p. ex. : exigences relatives à la synchronisation du signal)
 Interfaces avec les autres applications
 Exploitation en parallèle
 Fonctions de vérification
 Fonctions de contrôle
 Exigences relatives aux langages évolués
 Protocoles d’échange de signaux (par ex., XON-XOFF, ACK-NACK)
 Exigences de fiabilité
 Niveau d’importance de l’application
 Considérations relatives à la sécurité et à la sûreté
2.5 Hypothèses et dépendances
 Le standard IEEE 830-1998
section 2 – Description générale
52

2. Description générale
2.1 Environnement
2.2 Fonctions
2.3 Caractéristiques des utilisateurs
2.4 Contraintes
2.5 Hypothèses et dépendances
Enumère tous les facteurs qui influent sur les exigences énoncées dans la spécification. Ne
vise pas les contraintes de conception, mais les modifications éventuelles à ces
dernières, qui pourraient se répercuter sur les exigences.
Exemple, on pourrait poser comme hypothèse que le système d’exploitation sera disponible
pour le matériel que l’on choisit pour faire fonctionner le logiciel. S’il n’était pas
disponible, il faudrait modifier la spécification en conséquence.
 Le standard IEEE 830-1998
section 3 – Exigences spécifiques
53

1. Introduction
1.1 Objet
1.2 Portée
1.3 Définitions, acronymes, abréviations
1.4 Références
1.5 Vue d’ensemble
2. Description générale
2.1 Environnement
2.2 Fonctions
2.3 Caractéristiques des utilisateurs
2.4 Contraintes
2.5 Hypothèses et dépendances
3. Exigences spécifiques
4. Annexes
5. Index
 Le standard IEEE 830-1998
section 3 – Exigences spécifiques
54

3. Exigences spécifiques
3.1 Exigences des interfaces externes
3.2 Exigences fonctionnelles
3.3 Exigences de performance
3.4 Exigences logiques relatives aux bases de données
3.5 Contraintes de conception
3.6 Attributs

Voir le standard pour diverses versions possibles en fonction :

du mode d’utilisation
de la classe d’utilisateur
des stimulus
etc
 Le standard IEEE 830-1998
section 3 – Exigences spécifiques
55

3.1 Exigences des interfaces externes

 Description détaillée de tous les intrants et les extrants du logiciel
 Devrait compléter plutôt que répéter la description des interfaces mentionnée en section 2 (description générale)
 S’intéresse aux aspects
 Interfaces avec les utilisateurs
 Interfaces avec le matériel
 Interfaces avec les logiciels
 Interfaces de communication
 Devrait inclure aussi bien le contenu et la forme :
 Nom de l’élément
 But
 Provenance des intrants ou destination des extrants
 Échelle, degré de précision et/ou degré de tolérance acceptable
 Unités de mesure
 Synchronisation
 Rapports avec les autres intrants/extrants
 Format et organisation des écrans
 Format et organisation des fenêtres
 Format des données
 Format des commandes
 Messages de fin
 Le standard IEEE 830-1998
section 3 – Exigences spécifiques
56

3.2 Exigences fonctionnelles

 Définissent les actions principales que doit exécuter le logiciel,
pour la réception et le traitement des intrants, ainsi que le
traitement et la génération des extrants.
 Généralement exprimées sous la forme « Le système doit… »
 Parmi ces exigences, on peut préciser notamment :
 Vérification de la validité des intrants
 Séquence exacte des activités
 Réponses aux situations anormales, y compris :
 Dépassement
 Installations de télécommunications
 Traitement des erreurs et récupération
 Effet des paramètres
 Rapports entre extrants et intrants, y compris
 Séquences intrants/extrants
 Formules de conversion d’intrant à extrant
 Le standard IEEE 830-1998
section 3 – Exigences spécifiques
57

3.3 Exigences de performance

 Précise les exigences numériques – statiques et dynamiques – qui doivent
être satisfaites par le logiciel ou par l’interaction entre l’humain et le
logiciel.
 Exigences statiques (parfois dans une section intitulée “capacité”)
 Le nombre de terminaux qu’il doit supporter
 Le nombre d’utilisateurs qu’il doit supporter simultanément
 Le volume et le type de données qu’il doit traiter
 Exigences numériques dynamiques peuvent comprendre
 nombre de transactions et de tâche
 volume de données à traiter au cours d’une certaine période,
 dans des conditions de travail normales
 lors des périodes de pointe.
 Doivent être énoncées de manière à être mesurables.
 “95% des transactions doivent être traitées en moins de 1 seconde”
 au lieu de “L’opérateur ne doit pas être obligé d’attendre la fin d’une transaction”
 Le standard IEEE 830-1998
section 3 – Exigences spécifiques
58

3.4 Exigences logiques relatives aux bases de données

 Décrit les exigences logiques relatives à toute information incorporée à
une base de données
 Peuvent inclure
 Les types d’information utilisées par les diverses fonctions
 La fréquence d’utilisation
 Les capacités d’accès
 Les entités et leurs relations
 Les contraintes d’intégrité
 Les exigences relatives à la rétention des données
 Le standard IEEE 830-1998
section 3 – Exigences spécifiques
59

3.5 Contraintes de conception

Précise les contraintes de conception qui peuvent être imposées
par d’autres normes, les limites du matériel, etc
 Conformité aux normes : précise les exigences qui sont
imposées par les normes et réglementations existantes
 Format des rapports
 Nom des données
 Procédures de comptabilité
 Traçage de vérification
 Le standard IEEE 830-1998
section 3 – Exigences spécifiques
60

3.6 Attributs
 Disponibilité : facteurs susceptibles de garantir le niveau de disponibilité spécifié pour le système dans son ensemble
 point de contrôle
 récupération
 redémarrage
 Sécurité : facteurs susceptibles de protéger le logiciel d’interventions accidentelles ou malveillantes
 L’utilisation de certaines techniques cryptographiques
 La conservation certains journaux de bord ou certains ensembles de données historiques
 L’assignation de certaines fonctions à des modules distincts
 La restriction des communications entre certaines parties du programme
 La vérification de l’intégrité des données de certaines variables clés
 Maintenabilité : attributs du logiciel liés à la facilité de maintenance
 Modularité
 Interfaces
 Complexité
 …
 Transférabilité : attributs du logiciel liés à sa transférabilité à d’autres ordinateurs hôtes et/ou systèmes d’exploitation
 % de composants dont le code est lié à l’ordinateur hôte
 % du code lié à l’ordinateur hôte
 utilisation d’un langage dont la transférabilité est éprouvée
 utilisation d’un compilateur ou d’un sous-ensemble de langage en particulier
 utilisation d’un système d’exploitation en particulier
 Le standard IEEE 830-1998
61

 Une spécification des exigences devrait être

 Exacte
 Non ambiguë

 Complète

 Cohérente

 Hiérarchisée en fonction de l’importance et/ou de la

stabilité
 Vérifiable

 Modifiable

 Traçable
 Spécification des exigences
62

 Processus d’écriture des exigences utilisateur et système

dans un document
 Les exigences utilisateur doivent être compréhensibles
par les utilisateurs finaux et les clients n’ayant pas de
bagages techniques
 Les exigences système sont des exigences plus
détaillées et peuvent donc contenir des informations
plus techniques
 Les exigences peuvent faire partie d’un contrat pour le
développement du système
  Les exigences doivent être les plus complètes possible
 Façon d’écrire des spécifications d’exigences
63

Notation Description
Langage naturel Les exigences sont écrites sous forme de phrases ordonnées en langage
naturel. Chaque phrase devrait exprimer une exigence

Langage naturel Les exigences sont écrites avec un sous ensemble du langage naturel sous
structuré une forme standard, selon un modèle. Chaque champ fourni une information
sur un aspect de l’exigence

Langages de Utilise un langage de type langage de programmation mais d’un niveau plus
conception abstrait permettant de définir un modèle opérationnel du système. Cette
approche n’est plus beaucoup utilisée

Notations Modèles graphiques, complétés par des annotations textuelles

graphiques Les diagrammes de cas d’utilisation et les diagrammes de séquences UML
sont communément utilisés

Spécifications Basés sur des concepts mathématiques tels que les machines à états finis,
mathématiques les ensembles. Les clients ont en général de grosses difficultés de
compréhension envers ce type de formalisation. Ils ont du mal à vérifier
qu’elles représentent ce qu’ils désirent et sont peu enclin à les accepter
comme la base d’un contrat.
Exigences vs Conception
 En principe
 Exigence = QUOI réaliser
 Conception = COMMENT le réaliser

 En pratique exigences et conception sont inséparables

 Une architecture du système peut être conçue pour structurer
les exigences
 Le système peut interopérer avec d’autres systèmes 
exigences de conception
 L’utilisation d’une architecture spécifique pour satisfaire des
exigences non fonctionnelles peut être une exigence de
domaine
 Spécification en langage naturel
65

 Les exigences sont écrites sous forme de phrases en

langage naturel, complétées par des diagrames et
tables
 Souvent utilisé car
 Expressif

 Intuitif

 Universel

 compréhensible par le client

Pistes pour écrire des exigences

 Inventer un format standard et l’utiliser pour toutes les

exigences
 Utiliser le langage de façon consistante
 Doit  exigence prioritaire obligatoire
 Devrait  exigence moins prioritaire, pas forcément obligatoire
 Utiliser des mises en relief typographiques pour identifier
les parties clés de l’exigence
 Eviter d’utiliser du jargon informatique (ne plait pas au
client)
 Inclure une justification (rationale) montrant en quoi
l’exigence est nécessaire
Problèmes avec le langage naturel

 Manque de clareté
 Laprécision est difficile à atteindre sans rendre le
document très difficile à lire
 Confusion entre les exigences
 Les exigences fonctionnelles et non fonctionnelles ont
tendance à être mélangées
 Amalgame entre exigences
 Ilest souvent difficile de n’exprimer qu’UNE exigence.
Bien souvent plusieurs exigences sont exprimées dans
une seule phrase
 Exemple d’exigence pour le logiciel de
pilotage de pompe à insuline
68

3.2 Le système doit mesurer le sucre dans le sang et déclencher l’injection d’insuline, si
besoin, toutes les 10 minutes. (Les changements du taux de sucre dans le sang sont
relativement lent et donc une mesure plus fréquente est inutile ; les mesures moins
fréquentes pourraient par contre conduire à des niveaux de sucre inutilement hauts)

3.6 Le système doit lancer une procédure automatique pour se tester lui même toutes
les minutes. Les conditions à tester et les actions associées sont définies à la table X.
(Une procédure de test peut découvrir des problèmes matériel et logiciel et alerter
l’utilisateur du fait que certaines opérations pourraient être impossible)
 Spécifications structurées
69

 Façon d’écrire des exigences où la liberté d’écriture

est limitée et les exigences sont écrites de façon
standard
 Cela fonctionne bien pour certains type
d’exigences, par exemple pour les systèmes de
contrôle embarqués
 Parfois trop rigide pour écrire des exigences pour
des systèmes d’information plus classiques
Spécifications formatées

 Définition de la fonction
 Description des entrées et d’où elles proviennent
 Description des sorties et où elles vont
 Informations nécessaires pour le traitement et autres
entités utilisées
 Description de l’action à réaliser
 Pré et post conditions (éventuellement)
 Effets de bords (s’il y en a) de la fonction
 Exemple de spécification structurée pour la
pompe à insuline
71

Logiciel de contrôle de pompe à insuline/IEL/3.3.2

Fonction : calcul dose insuline : niveau de sucre correct
Description :
Calcul la dose d’insuline à injecter lorsque le niveau courant de
sucre mesuré est dans une zone de sureté entre 3 et 7 unité
Entrée : Taux de sucre actuel (r2) ; les deux taux précédents
(r0 et r1)
Source : taux courant à partir de capteur. Autres taux à partir
de la mémoire
Sortie : CompDose – dose d’insuline à injecter
Destination : Boucle de contrôle principale
 Exemple de spécification structurée pour la
pompe à insuline
72

Action : CompoDose vaut zéro si le niveau de sucre est stable ou chute

ou si le niveau monte mais le taux d’augmentation décroit. Si le
niveau augmente et que le taux d’augmentation augmente, alors
CompDose est calculé en divisant la différence entre le niveau de
sucre courant et les précédents niveaux par 4 et en arrondissant le
résultat. Si le résultat est arrondi à 0 alors CompDose reçoit la dose
minimum qui peut être injectée.
Contrainte :
Deux mesures antérieures pour que le taux de changement du niveau
de sucre dans le sang puisse être calculé
Pré condition : le réservoir d’insuline contient au moins le maximum de
quantité autorisé d’une dose
Post condition : r0  r1 ; r1  r2
Effet de bord : aucun
Spécification tabulaire

 Utilisée pour remplacer le langage naturel

 Particulièrement utile lorsqu’on doit définir un
certain nombre de cas possibles d’actions
 Par exemple, la pompe à insuline base ses calculs
sur le taux de changement du niveau de sucre dans
le sang et la spécification tabulaire explique
comment calculer le niveau d’insuline à injecter pour
les différents scénarios
 Spécification tabulaire de calculs pour la
pompe à insuline
74

Condition Action

Niveau de sucre descend (r2 < r1) CompDose = 0

Niveau de sucre stable (r2 = r1) CompDose = 0

Niveau de sucre augmente et taux CompDose = 0

d’augmentation diminue
((r2 – r1) < (r1 – r0))

Niveau de sucre augmente et taux CompDose =

d’augmentation stable ou en round ((r2 – r1)/4)
augmentation If rounded result = 0 then
((r2 – r1) ≥ (r1 – r0)) CompDose =
MinimumDose
 Processus d’ingénierie des exigences
75

 Les processus utilisés dans le cadre de l’ingénierie des

exigences varient largement selon les domaines
d’application, les personnes impliquées et l’organisation
développant les exigences
 Toutefois il y a un certain nombre d’activités génériques
communes à tous les processus
 Elicitation des exigences
 Analyse des exigences
 Validation des exigences
 Management des exigences
 En pratique ces activités sont entremélées
 Vue en spirale du processus
d’ingénierie des exigences
76
 Elicitation et analyse des exigences
77

 Elicitation = Découverte

  Equipe technique travaillant avec les clients pour

comprendre le domaine d’application, les services que le
système devrait fournir ainsi que les contraintes opérationnelles

  Peut impliquer des utilisateurs finaux, managers, ingénieurs

de maintenance, experts du domaine, etc. On les appelle les
parties prenantes (stakeholders)
 Elicitation et analyse des exigences
78

 Les ingénieurs logiciels travaillent avec de

nombreuses parties prenantes pour comprendre le
domaine d’application, les services que le système
doit fournir, les performances imposées, les
contraintes matérielles, etc
 Etapes
 Découverte
 Classificationet organisation
 Définition des priorités et négociation
 Spécification des exigences
 Problèmes de l’analyse des exigences
79

 Les parties prenantes ne savent pas réellement ce qu’elles

veulent
 Les parties prenantes expriment les exigences avec leurs
propres termes
 Différentes parties prenantes peuvent avoir des exigences
contradictoires
 Des facteurs organisationnels et politiques peuvent influencer
les exigences
 Les exigences changent durant le processus d’analyse. De
nouvelles parties prenantes peuvent apparaitre et remettre en
cause le travail déjà réalisé
 Processus d’élicitation et d’analyse des
exigences
80
Activités du processus d’ingénierie des
exigences

 Découverte
 Interaction avec les parties prenantes
 Classification et organisation
 Regrouper les exigences et les organiser en clusters cohérents
 Définition des priorités et négociation
 Définition des priorités et résolution des conflits entre les exigences
 Spécification des exigences
 Les exigences sont documentées et servent d’entrée au prochain tour de
la spirale
 Parties prenantes dans le cadre du SG-PSP
82

 Les patients, dont les informations sont enregistrées

dans le système
 Les docteurs, responsables de l’évaluation et du
traitement des patients
 Les infirmières, qui coordonnent les consultations avec
les docteurs et administrent des traitements
 Le personnel d’accueil, qui gère les rendez vous
 Le personnel informatique, responsable de l’installation
et la maintenance du système
 Parties prenantes dans le cadre du SG-PSP
83

 Un responsable de l’éthique médicale, qui doit

s’assurer que le système répond aux contraintes
éthiques vis-à-vis du patient
 Des responsables de santé, qui obtiennent des
informations stratégiques de la part du système
d’information
 Des membres du personnel médical, qui sont
responsables du bon usage du système
d’information
 Entretiens
84

 Entretiens formels et informels font partie de la plupart

des processus d’Ingénierie des Exigences.
 Types d’entretiens
 Entretiens fermés, basés sur une liste prédéfinie de questions
 Entretiens ouverts ou diverses pistes sont explorées avec les
parties prenantes
 Entretien efficace
 Etre ouvert d’esprit, éviter les idées pré-conçues, être en attente
d’écouter les parties prenantes
 Susciter les discussions avec la personne questionnée en
rebondissant entre questions, en proposant une exigence, en
travaillant ensemble sur un prototype.
Entretiens en pratique

 Un mélange d’entretiens fermés et ouverts

 Les entretiens sont intéressants pour obtenir une vision globale
de ce que souhaitent les parties prenantes et comment ils
envisagent l’interaction avec le système
 Les entretiens ne sont pas une bonne solution pour comprendre
les exigences de domaine
 Les ingénieurs en charge des exigences ne peuvent en général pas
comprendre la terminologie spécifique au domaine
 La connaissance du domaine est parfois tellement familière que les
personnes éprouvent de la difficulté à l’exprimer, ou même ne pensent
pas qu’il y a un intérêt à l’exprimer
Scénarios

 Les scénarios sont des exemples de la vie réelle

montrant comme le système doit être utilisé
 Ils devraient comprendre
 Une description de la situation de départ
 Une description du flux normal d’événements

 Une description de ce qui peut mal se passer

 Une information sur les autres activités parallèles

 Une description de l’état du système lorsque le scénario se

termine
 Exemple de scénario pour la collecte
d’historique médical avec le SG-PSP
87

 Hypothèse initiale : Le patient a rencontré un personnel médical d’accueil

qui a créé un enregistrement dans le système et a collecté les informations
personnelles (nom, adresse, age, etc). Une infirmière est connectée au
système et récupère l’historique médical

 Fonctionnement normal : L’infirmière recherche le patient par son nom de

famille. S’il y a plus d’un patient avec ce nom, il faut donner le prénom et la
date de naissance. L’infirmère choisi dans le menu “ajouter un historique
médical”. L’infirmière voit alors défiler un certain nombre d’écrans
d’interaction comme la saisie des consultations réalisées partout (texte libre
en entrée), les conditions médicales existantes (choix dans un menu), le
traitement actuellement en cours (choix dans un menu), les allergies (texte
libre) et le style de vie à la maison (formulaire).
 Exemple de scénario pour la collecte
d’historique médical avec le SG-PSP
88

 Fonctionnement anormal :
 l’enregistrement pour le patient n’existe pas ou ne peut pas être trouvé.
 Les symptômes du patient ou le traitement n’ont pas été saisies dans le menu. L’infirmière
devrait alors choisir l’option “autre” et entrer du texte libre.
 Le patient ne peut/veut pas fournir ses données médicales. L’infirmière devrait entrer du
texte libre indiquant ce fait. Le système devrait imprimer un formulaire précisant que
l’absence d’information peut conduire au fait que le traitement sera limité. Ce document
doit être signé par le patient
 Autres activités :
 Les enregistrements peuvent être consultés mais non édités par les autres membres de
l’équipe
 Etat du système à la fin de l’utilisation :
 L’utilisateur est connecté. L’enregistrement du patient est ajouté à la base, une trace est
ajouté montrant l’heure de début, de fin, et l’infirmière impliquée dans l’action
 Cas d’utilisation (use cases)
89

 Les cas d’utilisation sont des techniques UML identifiant

les acteurs en interaction et qui décrivent les interactions
elles-même
 Un ensemble de cas d’utilisation devrait décrire toutes
les interactions possibles avec le système
 Ce sont des modèles graphiques augmentés de divers
détails sous forme tabulaire
 Des diagrammes de séquence peuvent être utilisés pour
ajouter des détails aux cas d’utilisation, montrant la
séquence d’événements traitée par le système
 Exemple de cas d’utilisation pour le SG-PSP
90
 Validation des exigences
91

 Sert à démontrer que les exigences définissent

réellement ce que veut le client
 Le coût des erreurs au niveau des exigences est très
élevé  la validation est très importante
 Détecter une erreur d’exigence à la livraison d’un
logiciel peut couter 100 fois le cout d’une erreur
détectée à l’implémentation
 Contrôle des exigences
92

 Validité. Est-ce que le système propose les fonctions qui

répondent le mieux possible aux besoins du client ?
 Consistence. Y-a-t-il des exigences en conflit ?
 Complétude. Est-ce que toutes les fonctions demandées par le
client sont prévues ?
 Réalisme. Les exigences peuvent elles être mise en oeuvre
étant donné le budget et la technologie ?
 Vérifiabilité. Les exigences peuvent elles être vérifiées ?
 Techniques de validation des exigences
93

 Revue d’exigences
 Analyse manuelle, systématique, en groupe, des
exigences
 Prototypage
 Par utilisation d’un modèle exécutable du système pour
contrôler les exigences
 Génération de cas de tests
 Développer des tests pour chaque exigence
 Revue d’exigences
94

 Des revues régulières devraient être mises en place

tout au long du processus de création de la
spécification des exigences
 Les clients et le fournisseur devraient participer aux
revues
 Les revues peuvent être formelles (avec des
documents à remplir) ou informelles. Une bonne
communication entre les développeurs, les clients, les
utilisateurs peut permettre de résoudre des
problèmes à des stades précoces du projet
 Points à vérifier
95

 Vérifiabilité
 L’exigence est-elle testable de façon réaliste ?
 Compréhensibilité
 L’exigence est-elle correctement comprise ?
 Traçabilité
 L’origine de l’exigence est-elle clairement établie ?
 Adaptabilité
 L’exigencepeut-elle être changée sans avoir un impact
trop grand sur les autres exigences ?
 Gestion des exigences
96

 La gestion des exigences est le processus qui gère les changements

des exigences durant le processus d’ingénierie des exigences et le
développement du système
 De nouvelles exigences émergent au fur et à mesure que le système
est développé et même une fois qu’il est en utilisation
 Il est nécessaire de garder une trace des exigences individuelles et
de maintenir les liens entre les exigences liées de telle façon que
l’on peut contrôler l’impact des changements sur les exigences
 Il faut mettre en place un processus rigoureux pour faire des
propositions de changements et les relier aux exigences du système
 Changer les exigences
97

 L’environnement économique et technique du système

change en permanence après son installation
 De nouveaux matériels peuvent apparaitre, on peut vouloir
interfacer le système avec de nouveaux autres systèmes, les
priorités économiques peuvent avoir changé, une nouvelle loi peut
apparaitre, etc

 Les personnes qui paient pour le système et celles qui

l’utilisent sont rarement les mêmes
 Les clients du système imposent souvent des exigences du fait de
contraintes budgétaires et organisationnelles. Cela peut entrer en
conflit avec les exigences des utilisateurs finaux et, après
livraison, de nouveaux services peuvent devoir être ajoutés pour
mieux les satisfaire
 Changer les exigences
98

 Les grands systèmes ont en général une large

communauté d’utilisateurs. Ceux-ci ont souvent des
exigences et priorités très variées qui peuvent être
en conflit ou contradictoire
 Les exigences du système final sont toujours un
compromis entre les exigences d’une large palette
d’utilisateurs et de ce fait, il est souvent découvert que
l’équilibre entre les exigences des divers utilisateurs
doit être remis en cause
 Planification de la gestion des exigences
99

 Définit le niveau de détail nécessaire dans la gestion des exigences

 Décisions à prendre dans la gestion des exigences
 Identification des exigences Chaque exigence doit être identifiée de façon
unique afin de pouvoir être référencée par d’autres exigences
 Processus de gestion des changements Ensemble d’activités permettant de
contrôler l’impact et le coût des changements
 Politique de traçabilité Ces politiques définissent comment enregistrer les
relations entre chaque exigence et entre les exigences et la conception du
système
 Outils utilisés Les outils utilisés peuvent varier d’outils spécialisés dans le
management des exigences aux simples tableurs ou bases de données
 Gestion du changement des exigences
100

 Décider si un changement d’exigence devrait être accepté

 Analyse du problème et spécification du changement
 Dans cette étape le problème ou la proposition de changement est analysée
pour vérifier qu’elle est valide. Cette analyse est retournée à celui qui
propose le changement. Il peut répondre avec une proposition plus spécifique
ou décider d’annuler sa proposition
 Analyse du changement et de son coût
 Les effets du changement proposé sont contrôlés en utilisant les informations
de traçabilité et la connaissance globale des exigences du système 
décision sur la réalisation du changement ou pas
 Implémentation du changement
 Le document de spécification des exigences, et éventuellement la conception
du système et son implémentation sont modifiés.
 Gestion du changement des exigences
101

Problème Exigence
identifié Analyse du problème Analyse du Implémentation révisée
et spécification changement et du
du changement de son coût changement
102

FIN DE LA 3 ème PARTIE