Ingénierie des Exigences

Lesson 2 – Spécification
Ian Sommerville, "Software Engineering", 9th Edition
Ingénierie des exigences
• Une exigence pour un système est la description d’un service offert
par le système et ses contraintes opérationnelles
• Les exigences reflètent les besoins du client pour satisfaire à l’objectif du
système
• L’ingénierie des exigences est le 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é.
• l'ingénierie des exigences est le processus de découverte, d'analyse, de
documentation et de vérification de ces services et contraintes

2
Types des exigences
• Les exigences de l’utilisateur = exigences de haut niveau d’abstraction
• Énoncé des services attendus du système et les contraintes sous lesquelles il
doit opérer
• Documenté en langage naturel + diagrammes
• Rédigés par le client
• Les exigences du système = description détaillée de ce que le système
doit faire
• Etablit en détail les fonctions et les services du système, et leurs contraintes
opérationnelles
• Définissent exactement ce qui sera implémenté,
• Fait partie du contrat entre le client et les développeurs

3
Exemple: système de gestion des hôpitaux
• Exigence utilisateur
• Le SGH doit générer tous les mois des rapports montrant le coût des médicaments prescrits
par chaque dispensaire durant ce mois
• Exigences système
• Le dernier jour de chaque mois le système doit générer une liste des médicaments prescrits,
leur coûts et les dispensaires qui les ont prescrit
• Le système doit automatiquement générer le rapport à imprimer à 17h30 du dernier jour
ouvrable du mois
• Un rapport doit être généré pour chaque dispensaire et doit lister les noms des
médicaments, le nombre total de prescriptions, le nombre de doses prescrites 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

4
Parties prenantes (stakeholder)
• Toute personne ou organisation
• Affecté par le système de quelque manière que ce soit
• A un intérêt légitime pour le système
• Typologie des intervenants
Exemple: Système de gestion des hôpitaux
• Utilisateurs finaux - Patients: les informations sont enregistrées dans le système
• Gestionnaires du système - Médecins : responsables de l’évaluation des patients
- Infirmières: coordonnent les soins aux patients
• Propriétaire du système - Personnel informatique: installation et maintenance du
• Parties prenantes externes système
- Réceptionnistes médicaux: accueil et gestion des RDV
- Archivistes: respect des procédure d’archivage des dossiers
- Les responsables du MINSANTE: obtiennent des informations
stratégiques
5
Exigences fonctionnelles et non-fonctionnelles
• Exigences fonctionnelles
• Enoncé des services que le système doit fournir. Ce que le système doit faire.
• 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 ou fonctions offerts par le système
• Une contrainte est une restriction sur une ou plusieurs valeurs d’une partie du système ou de tout le
système e.g. Contraintes de temps, Contraintes sur le processus de développement, Utilisation de
standards
• Caractérise une propriété (qualité) désirée du système telle que sa performance, sa
robustesse, sa convivialité, sa maintenabilité, etc
• S’applique souvent au système global plutôt qu’à des fonctions particulières
• Exigences du domaine
• Contraintes sur le système liées au domaine d’application

6
Exigences fonctionnelles
• Décrivent les fonctionnalités du système
• Dépendent du type de logiciel, des utilisateurs attendus et du type
d’installation où le logiciel est utilisé
• Les 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’EF pour le SGH :
• Un utilisateur doit pouvoir rechercher les listes de rendez vous de tous les centres de
santé
• 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

7
Complétude et consistance des exigences
• En principe, les exigences doivent être non ambiguës, complètes et consistantes
• Ambiguïté
• Le problème se pose lorsque les exigences fonctionnelles ne sont précisément énoncées
• Les exigences ambiguës peuvent être interprétées de différentes manière par les
développeurs et les utilisateurs
• Complet
• Inclure la description de toutes les facilités exigées (exigences)
• Consistent
• Pas de conflits ou de contradictions dans les descriptions des caractéristiques du système
• En pratique, il est impossible de produire un document complet et consistent, à
cause de la complexité de l’environnement et du système

8
Exigences non-fonctionnelles
• L’utilité d’un système logiciel est déterminée par ses exigences
fonctionnelles et ses caractéristiques non-fonctionnelles.
• Elles définissent les propriétés ou contraintes du système e.g. temps de réponse,
fiabilité, stockage, etc.
• Les exigences du processus peuvent aussi être spécifiées: IDE particulier, langage de
programmation ou la méthode de développement
• L’ensemble des fonctionnalités n’est pas utilisable sans certaines
caractéristiques non fonctionnelles.
• Si les exigences non-fonctionnelles ne sont pas satisfaites, le système peut être
inutilisable
• Doivent être vérifiables
• Sinon, elles ne sont que des buts

9
Mise en œuvre des exigences non-fonct.
• 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
10
Hiérarchie/classification des exigences NF

Classification de Ian Sommerville

Lesson 2 11
Classification des exigences NF
• 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 provenant de facteurs externes au système et à son processus de
développement (lois, éthique, etc)

12
Métriques pour spécifier des exigences NF
Propriété Mesure
Instructions / seconde
Vitesse Temps de réponse utilisateur/événement
Temps de rafraichissement écran
Taille Mbytes
Temps d’apprentissage
Facilité d’utilisation
Nombre d’écrans d’aide
Temps moyen entre deux incidents
Probabilité d’inacessibilité
Fiabilité
Taux d’erreurs
Disponibilité
Temps pour redémarrer après incident
Robustesse Pourcentage d’événements causant des incidents
Probabilité de corruption des données lors d’incidents
Pourcentage d’instructions dépendant du matériel
Portabilité
Nombre de systèmes cibles
13
Exemples: cas du SGH
• Exigences produit
• Le SGH doit être accessible à tous les centres de santé durant les horaires de
travail (lundi au vendredi, 7h30 à 18h). Le temps d’arrêt du système durant les
horaires de travail ne doit pas dépasser 5 secondes par jour.
• Les interfaces utilisateur doivent être implémentées en utilisant les récentes
technologies du web (HTML5, ReactJS, …)
• Exigences organisationnelles
• Les utilisateurs du SGH 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 les lois de la république

14
Processus d’ingénierie des
exigences

15
Processus d’ingénierie des exigences
• 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
Elicitation Analyse Validation Management
• Validation des exigences
• Management des exigences
• En pratique ces activités sont entremêlées
16
 Découverte

Elicitation et analyse des exigences Spécification

Classification
et
organisation

Priorité et

• Elicitation = Découverte
Négociation

• 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)
• 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/activités
❑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

17
Problèmes de l’analyse des exigences
• Les parties prenantes ne savent pas réellement ce qu’elles veulent
• Les parties prenantes expriment les exigences avec leurs propres
termes
• Différentes parties prenantes peuvent avoir des exigences
contradictoires
• Des facteurs organisationnels et politiques peuvent influencer les
exigences
• Les exigences changent durant le processus d’analyse. De nouvelles
parties prenantes peuvent apparaitre et remettre en cause le travail
déjà réalisé

18
Interviews: technique de recueil des exigences
• Interviews (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
• Être 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.
19
Interview 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
• Problè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

20
Ethnographie: découverte des exigences
• Un spécialiste des sciences sociale passe un temps considérable à
observer et à analyser la façon dont les gens travaillent
• Les personnes n’ont pas à expliquer ou articuler leur travail
• Les facteurs d’importance sociaux et organisationnels devraient être
observés
• Les études d’ethnographie ont montré que le travail est généralement
plus riche et complexe que suggéré par de simples modèles du
système

21
Scénarios: découverte des exigences
• 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

22
Spécification des exigences

23
Spécification des exigences
• 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

24
Façons d’écrire la spécification des exigences
Notation Description
Les exigences sont écrites sous forme de phrases ordonnées en langage naturel.
Langage naturel
Chaque phrase devrait exprimer une exigence
Les exigences sont écrites avec un sous ensemble du langage naturel sous une
Langage naturel
forme standard, selon un modèle. Chaque champ fourni une information sur un
structuré
aspect de l’exigence
Utilise un langage de type langage de programmation mais d’un niveau plus
Langages de
abstrait permettant de définir un modèle opérationnel du système. Cette
conception
approche n’est plus beaucoup utilisée
Modèles graphiques, complétés par des annotations textuelles Les diagrammes
Notations
de cas d’utilisation et les diagrammes de séquences UML sont communément
graphiques
utilisés
Basés sur des concepts mathématiques tels que les machines à états finis ou les
Spécifications ensembles. Les clients ont en général de grosses difficultés de compréhension
mathématiques 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.
25
Spécification en langage naturel
• Les exigences sont écrites sous forme de phrases en langage naturel, complétées par des
diagrammes et tables
• Souvent utilisé car
• Expressif
• Intuitif
• Universel
• => compréhensible par le client
• 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

26
Problème avec le langage naturel
• Manque de clarté
• La précision est difficile à atteindre sans rendre le document très difficile à lire
• Confusion entre les exigences
• Les exigences fonctionnelles et non fonctionnelles ont tendance à être
mélangées
• Amalgame entre exigences
• Il est souvent difficile de n’exprimer qu’UNE exigence. Bien souvent plusieurs
exigences sont exprimées dans une seule phrase

27
Langage structuré
• 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
 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
28
Notations graphiques
• Les cas d’utilisation sont des techniques UML identifiant les acteurs
en interaction et qui décrivent les interactions elles-mêmes
• 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

29
Cas d’utilisation
• Objectif: comprendre les besoins du client pour rédiger le cahier des
charges fonctionnel
• Les questions à répondre
1. Définir les utilisations principales du système: à quoi sert-il.
2. Définir l’environnement du système: qui va l’utiliser ou interagir avec lui?
3. Définir les limites du système: où s’arrête sa responsabilité?
• Éléments de description:
• Diagramme de cas d’utilisation
• Description textuelle des cas d’utilisation
• Diagramme de séquence des scénarios d’utilisation

30
Cas d’utilisation
• Acteur: entité qui interagit avec le système
• Personne, chose, logiciel, extérieur au système en cours de developpement
• Représente un rôle => une entité peut jouer plusieurs rôles
• Identifié par le nom du rôle
• Cas d’utilisation: fonctionnalité visible de l’extérieur
• Ensemble de scénarios réalisant un objectif de l’utilisateur
• Action déclenché par un acteur
• Identifié par une action (verbe à l’infinitif)
• Vision du système centrée sur l’utilisateur

31
 Exemple de cas d’utilisation

Association
• Relation entre acteurs et cas d’utilisation
• Représente la possibilité pour l’acteur de déclencher le cas
32
 Généralisation de rôle

Situation: Y peut faire tout ce que fait X

Modélisation: faire apparaitre Y comme un cas particulier de X
33
 Relations entre cas d’utilisation

Généralisation : X est un cas particulier de Y

Tout ou partie du scénario de Y est spécifique à X
34
 Relations entre cas d’utilisation
Extension: X « extends » Y
• Cas d’utilisation X peut être déclenché au cours du scénario de Y
• X est optionnel pour Y

Inclusion: X « includes » Y
• Scénario de Y inclus dans le scénario de YY
• Cas d’utilisation Y déclenché au cours du scénario de X

35
Validation et management des
exigences

36
Validation et contrôle des exigences
• Validation: Sert à démontrer que les exigences définissent réellement
ce que veut le client
• Contrôle:
• Validité. Est-ce que le système propose les fonctions qui répondent le mieux
possible aux besoins du client ?
• Consistance. Y-a-t-il des exigences en conflit ?
• Complétude. Est-ce que toutes les fonctions demandées par le client sont
prévues ?
• Réalisme. Les exigences peuvent elles être mise en œuvre étant donné le
budget et la technologie ?
• Vérifiabilité. Les exigences peuvent elles être vérifiées ?
37
Techniques de validation des exigences
• Revue d’exigences
• Analyse manuelle/systématique/en groupe des exigences
• 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
• 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

38
Points à vérifier
• 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 ?

39