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/
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
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
6
Système de gestion de patients en
soins pychiatriques (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é
7
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
8
Organisation du SG-PSP 9
PC local
SG-PSP PC local
SG-PSP
PC local
SG-PSP
Serveur SG-PSP
Base de Données
Patient
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
10
Points cruciaux du SG-PSP
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
11
Exemple 2
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
12
Système de contrôle d’une pompe à
insuline
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…
13
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 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
15
16
Exigences
Utilisateur
Managers client
Ingénieurs client
Utilisateurs finaux
Architectes logiciel
Managers fournisseur
Exigences
Système
Ingénieurs clients
Utilisateurs finaux
Architectes logiciel
Développeurs logiciel
Exigences utilisateur et système (SG-PSP)
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
produit
Exigences
organisationnelles
Exigences
externes
Exigences
d’utilisabilité
Exigences
d’efficacité
Exigences
fiabilité
Exigences
sécurité Exigences
de contrôle
Exigences
éthiques
Exigences
d’espace Exigences
de performance
Exigences
environnementales
Exigences
d’exécution
Exigences
de développement
Exigences
législatives
Exigences
sécurité
Exigences
comptables
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
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)
Objectifs et exigences (SG-PSP)
Métriques pour spécifier des exigences
non fonctionnelles
Chapter 4 Requirements engineering
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 Nombre de 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
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
Exigences de domaine
Problème des exigences de domaine
32
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
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
Clients
Managers
Ingénieurs
développement
Ingénieurs
tests
Ingénieurs
maintenance
Spécifient les exigences,
les lisent pour vérifier qu’elles
satisfont bien leurs besoins.
Spécifient les changements
dans les exigences
Utilisent le document de
spécification des exigences pour
planifier une négociation pour
le système et pour planifier le
processus de développement
Utilisent les exigences pour
comprendre le système
devant être développé
Utilisent les exigences pour
mettre au point les tests
de validation du système
Utilisent les exigences pour
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 exigences utilisateur
On décrit ici les services fournit par le système à l’utilisateur. Les 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 système
Présente une vision de haut niveau de l’architecture envisagée du système montrant la répartition des fonctionnalités à travers les modules. Les composants qui proviendront de réutilisation devraient être mis en avant.
38
Section Description
Spécification des exigences système
Décrit les exigences fonctionnelles et non fonctionnelles en détail. Les interfaces vers les autres systèmes peuvent être décrits.
Modèles du système
Modèles graphiques du système montrant les relations entre les composants du système et le système et son environnement. Exemple : use case, diagrammes de classe, etc
Evolution du système
Décrit les hypothèses sur lesquelles le système est fondé et toute évolution qui 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
Structure du document de
spécification des exigences
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
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 1 - Introduction
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
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 2 – Description générale
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
section 3 – Exigences spécifiques
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 structuré
Les exigences sont écrites avec un sous ensemble du langage naturel sous une forme standard, selon un modèle. Chaque champ fourni une information sur un aspect de l’exigence
Langages de conception
Utilise un langage de type langage de programmation mais d’un niveau plus abstrait permettant de définir un modèle opérationnel du système. Cette approche n’est plus beaucoup utilisée
Notations graphiques
Modèles graphiques, complétés par des annotations textuelles Les diagrammes de cas d’utilisation et les diagrammes de séquences UML sont communément utilisés
Spécifications mathématiques
Basés sur des concepts mathématiques tels que les machines à états finis, 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é
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
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 d’augmentation diminue ((r2 – r1) < (r1 – r0))
CompDose = 0
Niveau de sucre augmente et taux d’augmentation stable ou en
augmentation ((r2 – r1) ≥ (r1 – r0))
CompDose = round ((r2 – r1)/4) If rounded result = 0 then 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
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
Classification et 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é
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
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
Parties prenantes dans le cadre du SG-PSP
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
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’exigence peut-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
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
Gestion du changement des exigences
101
Analyse du problème
et spécification
du changement
Analyse du
changement et
de son coût
Implémentation
du
changement
Problème
identifié
Exigence
révisée
Top Related