1ème Année Second Cycle

Semestre: S2
Responsable du Module:
Département Prof. Mimoun MALKI
d’Informatique

24/02/2024 1
 I. Introduction
 II. Notion de Système d’information
 III. Génie logiciel (Background) : Rappel
◦ Définition de logiciel
◦ Typologie de logiciel
◦ Définition GL
◦ Importance du Génie logiciel
◦ Processus de développement de logiciel
 IV. Notions de besoins (Exigences)
o Définitions
o Exigences fonctionnelles et non fonctionnelles
o Cahier des charges : Le document définissant les exigences logicielles
 V. Spécification des besoins
◦ Façon d’écrire des spécifications des besoins
◦ Spécification Structurée
◦ Spécification formatée
 VI. Processus d’ingénierie des besoins
◦ Elicitation des exigences
◦ Analyse des exigences
◦ Validation des exigences
◦ Management des exigences
VII. Schéma Directeur Informatique
24/02/2024 2
1. Roger Pressman, SOFTWARE ENGINEERING: A PRACTITIONER’S
APPROACH, EITH EDITION, Published by McGraw-Hill
2. Ian Sommerville SOFTWARE ENGINEERING, Ninth Edition, Addison Wisley
3. John W. Satzinger, Robert B. Jackson, Stephen D. Burd SYSTEMS ANALYSIS
AND DESIGN IN A CHANGING WORLD, Sixth Edition, CENPAGE
4. Yves Constantinidis, Michel Volle - Expression des besoins pour le système
d'information- Eyrolles (2010)

24/02/2024 3
 I. Introduction

 Les économies de toutes les nations développées dépendent du logiciel.

 De plus en plus de systèmes sont contrôlés par des logiciels.

 Les dépenses de logiciels représentent une part significative du PIB des nations
développées.

 Coût du logiciel > coût du matériel..

 Les logiciels coutent plus cher à maintenir qu’à développer. Systèmes à longue vie.

La maintenance coûte plusieurs fois le coût du développement.

24/02/2024 4
II. Notion de Système d’information
SI d’une Organisation
Un système organisé à partir de différentes ressources :
Un système d’information peut être défini à plusieurs niveaux
III. Génie logiciel : Background

Définition du terme « Logiciel » :

 On regroupe sous le terme de logiciel les différentes formes de programmes qui

permettent de faire fonctionner un ordinateur, et de l’utiliser pour résoudre des
problèmes, les données qu’ils utilisent et les documents qui servent à concevoir ces
programmes et ces données, à les mettre en œuvre, à les utiliser et à les modifier.

 Fait bien ressortir :

 Programmes
 Données
Documentation

24/02/2024 8
Définition du terme « Logiciel » (1)

 Produits logiciels génériques :

 Systèmes autonomes commercialisés auprès de tout client souhaitant les
acheter .
 La spécification de ce que doit faire le logiciel est maîtrisée par le
développeur et les décisions concernant les changements du logiciel sont
faites par le développeur
 Exemples : office, photoshop, jeux, …

 Produits logiciels adaptés aux clients

 Logiciels commandés par des clients spécifiques pour répondre à leurs
propres besoins.
 La spécification de ce que doit faire le logiciel est maîtrisée par le client de
ce logiciel et c’est lui qui décide des changements qu’il souhaite y apporter
 Exemples : systèmes de contrôle embarqués, logiciel de contrôle de traffic
aérien, …

24/02/2024 9
 Typologie de logiciel
Applications indépendantes : Applications fonctionnant sur un ordinateur local et
qui possède toute les fonctionnalités et ne nécessite donc pas de se connecter à
d’autres systèmes .
 Applications interactives à base de transactions : Applications qui s’exécutent sur
une machine distante accédée par l’utilisateur depuis sa machine (sites Web, e-
commerce, …) .
 Systèmes de contrôle embarqués : Logiciels de contrôlent de dispositifs matériels
(contrôle missiles, fusées, …)
 Applications batch : Principalement des applications de gestion destinées à traiter
de gros volumes de données pour produire de gros volumes de résultats en sortie
(gestion des comptes bancaires).
 Logiciels de jeux .
 Systèmes de modélisation et de simulation : Systèmes développés par les
scientifiques pour modéliser des processus physiques (météo, écoulement de fluide
sur les ailes d’avions, …).
 Systèmes de collectes de données (capteur sensor IOT ou objets connectés) :
Systèmes qui collectent des données à l’aide de capteurs et les transmettent à
d’autres systèmes pour traitement .
24/02/2024 10
Définition Génie logiciel
 Définition du terme « Génie Logiciel » : On appelle génie logiciel l’application de
méthodes scientifiques au développement de théories, méthodes, techniques,
langages et outils favorisant la production de logiciels de qualité.
 Définition par l’IEEE du terme « Génie Logiciel » : L’application d’approches
systématiques, rigoureuses, quantifiables pour le développement, la mise en œuvre
et la maintenance d’un logiciel, c’est à dire l’application de l’ingénierie au domaine
du logiciel.

Importance du Génie logiciel

Les vies de plus en plus d’individus et de sociétés reposent sur des

systèmes logiciels évolués:

 produire des logiciels fiables

 produire des logiciels en qui l’on puisse avoir confiance
 produire des logiciels rapidement
 produire des logiciels avec des coûts maîtrisés

24/02/2024 11
Synthèse

24/02/2024 12
24/02/2024 13
 Processus de développement de logiciel

 Un ensemble structuré d’activités nécessaires pour développer un logiciel

 Un modèle de développement de logiciel est une représentation abstraite d’un
processus
 De nombreux modèles différents mais pour tous :
 Spécification : on définit ce que le système devra faire
 Conception et implémentation : on définit l’organisation du système et on
l’implémente
 Validation : on vérifie que le système fait bien ce que veut le client
 Evolution : on modifie le système en réponse aux changements des besoins
du client

24/02/2024 14
 Processus agile vs dirigé par planification

 Dans un processus dirigé par la planification, toutes les activités sont planifiées à
l’avance et les progrès sont mesurés vis-à-vis de ce plan .

 Dans les processus agiles, la planification est incrémentale. Il est alors plus facile
de changer le processus pour refléter les changements de besoins utilisateurs .

 En pratique : un peu des deux .

Il n’y a pas de bon ou mauvais choix

24/02/2024 15
 Les modèles de développement de logiciel

 Le modèle en cascade : Les phases traditionnelles de développement sont

effectuées simplement les unes après les autres, avec un retour sur les précédentes,
voire au tout début du cycle. Le processus de développement utilisant un cycle en
cascade exécute des phases qui ont pour caractéristiques :

24/02/2024 16
Modèle en V :

Le modèle du cycle en V a été imaginé pour pallier le problème de réactivité du

modèle en cascade. Ce modèle est une amélioration du modèle en cascade qui
permet en cas d'anomalie, de limiter un retour aux étapes précédentes. Les phases
de la partie montante doivent renvoyer de l'information sur les phases en vis-à-vis
lorsque des défauts sont détectés afin d'améliorer le logiciel.

24/02/2024 17
 Le modèle en spirale

Le cycle en spirale met plus l'accent sur la gestion des risques que le cycle en V. En
effet, le début de chaque itération comprend une phase d'analyse des risques.
Celle-ci est rendue nécessaire par le fait que, lors d'un développement cyclique, il y
a plus de risques de défaire, au cours de l'itération, ce qui a été fait au cours de
l'itération précédente.

24/02/2024 18
Développement incrémental (prototypage)
Dans le cycle itératif les deux premières phases classiques (top down, par la
structure) consistent en l’expression des besoins et la conception de la solution.
C’est lors de la troisième et dernière grande phase, la construction du produit
(bottom up, par le besoin) que la notion d’itérations intervient

24/02/2024 19
IV. Notions de besoins (Exigences)

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

24/02/2024 20
 IV. Notions de besoins (1)
IV.1 Définitions

Qu’est-ce qu’une exigence ?

 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

24/02/2024 21
 IV. Notions de besoins (2)

Les différents types d’exigences

 Besoins utilisateur

Enoncé en langage naturel (plus des diagrammes) des services que le

système proposera et ses contraintes opérationnelles.
Ecrites pour les clients

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

24/02/2024 22
IV. Notions de besoins (3)

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

24/02/2024 23
Système de gestion de patients en soins psychiatriques (SG-PSP)

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

24/02/2024 24
Objectifs du SG-PSP :

 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

24/02/2024 25
24/02/2024 26
Principales caractéristiques du SG-PSP

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

24/02/2024 27
Points cruciaux du SG-PSP (1)

 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

24/02/2024 28
Exigences utilisateurs et système (SG-PSP)

 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 automatiquement 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 prescriptions, 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

24/02/2024 29
IV. Notions de besoins (4)
III.2 Besoins fonctionnelles et non fonctionnelles

A. Besoins 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
B. Besoins 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.
C. Besoins de domaine:
 Contraintes sur le système dans son contexte d’utilisation.

24/02/2024 30
A. Besoins fonctionnelles

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

24/02/2024 31
Exemples d’exigences fonctionnelles pour le SG-PSP

 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 12 chiffres

24/02/2024 32
Exemples d’exigences fonctionnelles pour le SG-PSP

 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 12 chiffres

24/02/2024 33
Imprécision des Besoins

 Problèmes lorsque les besoins ne sont pas définies précisément

 Besoins 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 au paravant un dispensaire avec la recherche du patient

24/02/2024 34
Complétude et consistance des exigences

 En principe les exigences doivent être complètes et consistantes

 Complètes :
 Doivent décrire 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.

24/02/2024 35
B. Exigences non fonctionnelles

 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

24/02/2024 36
Mise en œuvre des Besoins non fonctionnelles
 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

24/02/2024 37
 Classification des exigences non fonctionnelles

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) 24/02/2024 38
Exemples d’exigences non fonctionnelles pour le SG-PSP

 Exigences produit :
 Le SG-PSP doit être accessible à tous les dispensaires durant les horaires de
travail ( Dimanche au Jeudi, 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

24/02/2024 39
Différence entre objectifs et exigences

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

24/02/2024 40
Métriques pour spécifier des exigences non fonctionnelles

24/02/2024 41
C. Besoins de domaine

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

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

24/02/2024 42
C. Besoins de domaine(1)

 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

24/02/2024 43
Problème des exigences de domaine

 Compréhensibilité
Les exigences 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

24/02/2024 44
IV. Notions de besoins (5)
IV.3 Cahier des Charges: Le document de spécification des exigences

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

24/02/2024 45
Utilisateurs du document de spécification des exigences

24/02/2024 46
Variabilité du document de spécification des exigences

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

24/02/2024 47
Structure du document de spécification des exigences

24/02/2024 48
24/02/2024 49
V. Spécification des besoins

 Processus d’écriture des Besoins utilisateur et système dans un document.

 Les Besoins 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 .

24/02/2024 50
V. Spécification des besoins(1)
Façon d’écrire des spécifications des besoins

24/02/2024 51
V. Spécification des besoins(2)
Besoins vs Conception

 En principe
 Besoin (ou 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 .

24/02/2024 52
V. Spécification des besoins(3)
Spécification en langage naturel (besoins peuvent obtenus par des
interviews)
 Les exigences sont écrites sous forme de phrases en langage naturel,
complétées par des diagrammes et tables.
Souvent utilisé car
 Expressif
 Intuitif
 Universel
Compréhensible par le client
Problèmes
 Manque de clarté
La pré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
Il est souvent difficile de n’exprimer qu’une exigence. Bien souvent plusieurs
exigences sont exprimées dans une seule phrase 24/02/2024 53
V. Spécification des besoins(4)
Exemple d’exigences pour le logiciel de pilotage de pompe à insuline
 Objectifs :
 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

Fonctions:
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…

24/02/2024 54
V. Spécification des besoins(5)

Spécifications structurées

 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

24/02/2024 55
V. Spécification des besoins (6)

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

24/02/2024 56
Exemple de spécification structurée pour la pompe à insuline
Logiciel de contrôle de pompe à insuline

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

24/02/2024 57
Logiciel de contrôle de pompe à insuline (Suite)

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

24/02/2024 58
 VI. Processus d’ingénierie des besoins
 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

24/02/2024 59
VI. Processus d’ingénierie des besoins(1)
ELicitations et analyse des exigences (Etude de l’existant)

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

24/02/2024 60
Elicitation et analyse des exigences

 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
 Classification et organisation
 Définition des priorités et négociation
Spécification des exigences

24/02/2024 61
Problèmes de l’analyse des exigences

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

24/02/2024 62
Processus d’élicitation et d’analyse des exigences

24/02/2024 63
Yves Constantinidis, Michel Volle -Expression des besoins pour le système
d'information- Eyrolles (2010)

24/02/2024 64
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

24/02/2024 65
Parties prenantes dans le cadre du SG-PSP

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

24/02/2024 66
Parties prenantes dans le cadre du SG-PSP
 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

24/02/2024 67
Processus d’élicitation et d’analyse des exigences
Entretiens

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

24/02/2024 68
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

Question à large Spectre : Voir le livre de Yves Constantinidis, Michel Volle -

»Expression des besoins pour le système d'information- Eyrolles (2010) »

24/02/2024 69
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

24/02/2024 70
Exemple de scénario pour la collecte d’historique médical
avec le SG-PSP
 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, âge, 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’infirmière choisi dans le menu “ajouter un historique médical”.

24/02/2024 71
Exemple de scénario pour la collecte d’historique médical avec
le SG-PSP
 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

24/02/2024 72
Cas d’utilisation (use cases)
 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

24/02/2024 73
Exemple de cas d’utilisation pour le SG-PSP

24/02/2024 74
Validation des exigences

 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

24/02/2024 75
Contrôle des exigences
 Validité. Est-ce que le système propose les fonctions qui répondent le mieux
possible aux besoins du client ?

 Consistance. 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 œuvre étant donné le
budget et la technologie ?

 Vérifiabilité. Les exigences peuvent elles être vérifiées ?

24/02/2024 76
Techniques de validation des exigences

 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

24/02/2024 77
Revue d’exigences (Documentation ou Livrables)

 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

24/02/2024 78
Management des Besoins :

 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  Gestion des versions

 Il faut mettre en place un processus rigoureux pour faire des propositions de

changements et les relier aux exigences du système .

24/02/2024 79
Changer les exigences

 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

 . Reversse Engineering ( et Reengineering)

 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

24/02/2024 80
Planification du Management des exigences
 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

24/02/2024 81
Management des Changement des besoins

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

24/02/2024 82
 VII. Schéma Directeur Informatique
DEFINITION

 Le Schéma Directeur Informatique est la définition par l’organisation de

l’évolution souhaitée des SI et de leurs moyens pour réaliser sa stratégie.

 Il se traduit par la réalisation d’un document appelé également SCHEMA

DIRECTEUR qui indique les grandes orientations en matière d'architecture et
d'urbanisation du système d'information.
 Ses objectifs sont multiples et définis en un nombre limité de projets. Ce plan
stratégique prospectif permet d'anticiper et de prévoir les évolutions du SI,
même en environnement instable et incertain.

24/02/2024 83
Historique du SI et Analyse de l’existant

24/02/2024 84
 Exemples de notions contenues dans le document :

 la réduction des coûts informatiques,

 un déploiement multi-sites,
 l'accompagnement du lancement de projets stratégiques pour l'entreprise,
 la mise en œuvre d'une gouvernance, la création d'indicateurs de pilotage,
 l'urbanisation du système d'information,
 la création d'une démarche processus,
 la modernisation de l'infrastructure…

24/02/2024 85
 Urbanisation d’un SI

 Urbanisation : démarche qui consiste à rendre un système d’information plus

apte à servir la stratégie de l’entreprise et à anticiper les changements dans
l’environnement de l’entreprise.
 Urbanisation du système d’information : mise en œuvre du plan d’urbanisme
du système d’information.
 Urbanisme du système d’information : démarche qui consiste à définir un
système d’information cible qui puisse s’adapter et anticiper les différents
changements (stratégiques, organisationnels, juridiques…) touchant
l’entreprise.
 Plan d’urbanisme du système d’information : agrégation de la définition du
système d’information cible et des règles d’urbanisme avec la trajectoire à suivre
pour atteindre ce système.

24/02/2024 86
Intérêt du Schéma Directeur

24/02/2024 87
De l’Audit à la mise en œuvre

 Le Schéma directeur doit présenter un existant, un point de départ : l’étude des

besoins et la définition de systèmes cibles devront être faites après un état des
lieux.
 De manière objective, les forces et faiblesses de l’organisation (sur le plan
informatique) doivent être évoquées durant la phase d’Audit. Cette phase
débouche sur une représentation « photographique » du SI existant (architecture
technique, fonctionnelle, organisationnelle) puis sur une définition de la cible.

24/02/2024 88
La phase d’Audit

 Il s’agit de décomposer le SI en 4 « vues » en séparant bien la couche

informatique en 2 : la vue applicative (logiciels ) est distincte de la vue technique
(matériels ).

 Pour chaque besoin ou dysfonctionnement, on identifie la vue qui est concernée :

c’est la cible du besoin ou du dysfonctionnement.
 Puis dans un deuxième temps on détermine en descendant couche par couche, la
vue qu'il n’est pas nécessaire de modifier (couche invariante).
 Toutes les couches situées entre la couche cible (incluse) et la couche invariante
(non incluse) doivent être modifiées
24/02/2024 89
Le plan informatique

 La mise en œuvre du schéma directeur s’appelle le PLAN INFORMATIQUE.

 Il recense:

 Les projets informatiques à faire pour réaliser le schéma directeur

 informatique ,L’ordre d’exécution des projets

 Les moyens pour réaliser le projet

24/02/2024 90
Démarche de planification informatique

 Dans la pratique, planifier revient donc à se poser plusieurs questions :

1. Quels sont les besoins en information ?

2. Quels sont les moyens humains et technologiques nécessaires ?

3. Comment répartir les moyens dans le temps ?

4. Réalise-t-on le schéma directeur ?

5. Les projets informatiques sont-ils compatibles entre eux ?

6. Les projets informatiques sont-ils compatibles avec les moyens humains,

matériels et logiciels de l’organisation ?

24/02/2024 91