figures – chapter 4 · ingénierie des exigences 3 processus qui définit les services attendus...

GÉNIE LOGICIEL (SOFTWARE ENGINEERING)

3ÈME PARTIE – INGÉNIERIE DES BESOINS

(REQUIREMENT ENGINEERING)

Faculté des Sciences et Techniques

[email protected]

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

Modèle d’activité de la pompe à insuline

(diagrame UML) 14

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é


mettre au point les tests

de validation du système


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.4 Références

1.5 Vue d’ensemble


2.1 Environnement

2.2 Fonctions


2.4 Contraintes



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.4 Références



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.4 Références




43

1. Introduction

1.1 Objet

1.2 Portée


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




44

1. Introduction

1.1 Objet

1.2 Portée


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




45

1. Introduction

1.1 Objet

1.2 Portée


1.4 Références


Décrit le reste du document et son organisation




section 2 – Description générale 46

1. Introduction

1.1 Objet

1.2 Portée


1.4 Références



2.1 Environnement

2.2 Fonctions


2.4 Contraintes



4. Annexes

5. Index

47


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.4 Contraintes



section 2 – Description générale

48


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.4 Contraintes




49


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.4 Contraintes




50


2.1 Environnement

2.2 Fonctions


Caractéristiques générales des utilisateurs du produit :

niveau d’instruction

expérience

connaissances techniques

2.4 Contraintes




51


2.1 Environnement

2.2 Fonctions


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é




52


2.1 Environnement

2.2 Fonctions


2.4 Contraintes


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.



53

1. Introduction

1.1 Objet

1.2 Portée


1.4 Références



2.1 Environnement

2.2 Fonctions


2.4 Contraintes



4. Annexes

5. Index


section 3 – Exigences spécifiques

54


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



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



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



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”



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



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



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


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


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

Vue en spirale du processus

d’ingénierie des exigences 76


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)


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


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


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

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’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

102

FIN DE LA 3ème PARTIE

figures – chapter 4 · ingénierie des exigences 3 processus qui définit les services attendus...

Documents