INGÉNIERIE DES BESOINS

(REQUIREMENT ENGINEERING
Définitions
Ingénierie des exigences:

 Processus qui définit

 les services attendus par le système coté client
(fonctionnel)
 les contraintes (non-fonctionnel)
 sous lesquelles il s’exécutera
 et sera développé.
Exigence :

 Peut représenter une vision abstraite d’un service ou d’une

contrainte d’un système
 Peut être la base d’une négociation ou offre d’un contrat
(ouverte aux interprétations)
 Utilisateur-client
 Peut représenter une vision détaillée donc une spécification
 Peut être la base du contrat ( défini en détail)
 Utilisateur-client-devellopement
Types d’exigences
 Exigences utilisateur
 Définition des Besoins des utilisateurs
 Enoncé des services que le système proposera et ses contraintes
opérationnelles
 en langage naturel (plus des diagrammes),écrites pour les clients

 Exigences système
 Définition du Produit ou analyse des besoins 
 Décrit en détail les fonctions du système et les contraintes
 Définit ce qui devrait être réalisé par le fournisseur
 Un document structuré (Spécification)
 Peut faire partie du contrat entre le client et le fournisseur
 Exemple
 Système d’information pour la gestion de patients atteints de
problèmes psychiatriques

 Exigence utilisateur
  Le système doit générer tous les mois des rapports montrant le coût des
médicaments prescrits par chaque dispensaire durant ce mois
 Exigences système
 Le dernier jour de chaque mois le système doit générer une liste des
médicaments prescrits, leur coûts et les dispensaires qui les ont prescrit
 Le système doit automatiquement générer le rapport à imprimer à 17h30
du dernier jour travaillé du mois ,,,
Développeurs ?
Parties prenante stakeholders

 Toute personne qui est concerné par le système

 Peut impliquer des
 utilisateurs finaux,
 gestionnaires ,
 ingénieurs ou personnel informatique
 experts du domaine, etc
Exigences fonctionnelles et non
fonctionnelles
 Exigences fonctionnelles
 Ils définissent des fonctions et des fonctionnalités du système logiciel.
 Enoncé des services que le système doit fournir et ne devrait pas faire
 Comment le système devrait se comporter dans les diverses situations
 Les exigences fonctionnelles utilisateur peuvent être des énoncés abstraits
décrivant ce que le système doit/devrait faire
 Les exigences fonctionnelles système décrivent les fonctionnalités en détai
 Exigences non fonctionnelles
 Contraintes ou caractéristiques sur les services et fonctions offertes par le
système
 Contraintes de temps
 Contraintes sur le processus de développement
 Utilisation des normes
 S’applique souvent au système entier
Problèmes liés au exigences fonctionnels

 Imprécision des exigences

 Ambigüité : diverses interprétations selon développeurs et utilisateurs
 Complétude
 Décrire TOUTES les fonctionnalités
 Consistance et cohérence
 Pas de contradictions dans les descriptions des caractéristiques du système

….Réalisable ?
 Caractéristiques des Exigences non fonctionnelles

 Peuvent être aussi ou plus critiques que les exigences

fonctionnelles du (coté de la validation par exemple)
 peuvent toucher l’architecture globale du système
 Exemple décider de décentraliser la base de donnés pour améliorer
les performances
 Une exigence non fonctionnelle, peut générer des exigences
fonctionnelles définissant une fonctionnalité qui est alors nécessaire
 Exemple authentification
Types d’exigences non-fonctionnelles
 Exigences produit
 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)
 Exemple exigences sur le processus de développement
 Environnement de développement
 Langage de programmation
 Méthode de développement
 Exigences externes
 Exigences provenant de facteurs externes
 lois
 Éthique,,,

 Exemple : Le système doit implémenter un dispositif

de protection de la vie privée
Problèmes liés aux exigences
non-fonctionnelles
 Objectifs très difficiles à définir de façon précise
 peuvent être difficiles à vérifier
 Exemple
 Le système devrait être facile d’utilisation par l’équipe
médicale
 L’équipe médicale doit être capable d’utiliser les fonctions
du système après une formation de 4 heures.
Le document de spécification des exigences et
cahier de charge et SRS
 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
 Inclus à la fois
 Exigences utilisateur
 Exigences système
Caractéristiques du document

 Le contenu dépend de
 Type de système
 Méthode de développement utilisée
 Des standards ont été conçu principalement pour les
exigences de grands systèmes
Exemple : IEEE 830-1998
Structure du document
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
 Peuvent faire partie d’un contrat pour le développement du
système
Exemples de langages
Spécification en langage naturel

 Ecrites sous forme de phrases en langage naturel,

complétées par des diagrammes et tables
 Caractéristiques
 Expressif
 Intuitif
 Universel
 compréhensible par le client
 Bonnes pratiques
 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 pour identifier les parties
clés de l’exigence
 Eviter d’utiliser les termes techniques de
développement (ne plait pas au client)
 Inclure des justification montrant en quoi l’exigence
Processus d’ingénierie des exigences
Etapes

 Elicitation, définition ou rassemblement ou collecte des

exigences
 Analyse ou Spécification des exigences

 Validation des exigences

 Management ou gestion des exigences

Processus de collecte des exigences
Rassemblement des exigences

 Les analystes et les ingénieurs

 communiquent avec le client et les utilisateurs finaux

 pour connaître leurs idées sur ce que le logiciel doit

fournir comme fonctionnalités.
Techniques de découverte des éxigences

 Les interviews
 Les Questionnaires
 Analyse des tâches
 Analyse de domaine
 Brainstorming
 Prototypage
 Observation
Les interviews
 = des entretiens

 Entretiens non structurés (ouverts)ou structurés (fermés) :

 les informations à rassembler sont décidées à l'avance
ou pas

 Entretiens oraux ou écrits ;

 individuelles ou de groupe
Les Questionnaires

 Un document avec un ensemble prédéfini de questions

objectives et d'options respectives

 remis à toutes les parties prenantes pour répondre.

 si une option n’est pas mentionnée dans le questionnaire,

l’option ne sera pas traité.
Analyse des tâches

 Les ingénieurs et développeurs peuvent analyser

l’opération pour laquelle le nouveau système est requis.

 Si le client dispose déjà d'un logiciel pour effectuer

certaines opérations existe , il est étudié et pour collecter
les exigences du nouveau système
Analyse de domaine

 Chaque logiciel appartient à une catégorie de domaine.

 Les experts du domaine peuvent déterminer les besoins

généraux et spécifiques
Brainstorming

 Un débat informel a lieu entre les différentes parties

prenantes

 toutes leurs contributions sont enregistrées pour une

analyse plus approfondie des besoins.
Prototypage

 le développeur crée un prototype basé sur les exigences

initialement mentionnées.

 Le prototype est montré au client et le retour est noté.

 La rétroaction du client sert d'intrant pour la collecte des

exigences.
Observation

 Une équipe d'experts visite le lieu de travail.

 Ils observent le fonctionnement réel des systèmes
installés existants.

 Ils observent les activités et comment les problèmes

d’exécution sont traités.

 L'équipe tire des conclusions qui aident à former les

exigences attendues du logiciel
Ordonnancement de sexigences

 Les développeurs hiérarchisent et ordonnancent les

exigences par ordre

 d'importance,
 d'urgence
 et de commodité.
Négociation & discussion

 Si les exigences sont ambiguës ou s'il existe des conflits

dans les exigences des différentes parties prenantes,

 elles sont négociées et discutées avec les parties prenantes.

 Pour lever l’ambiguïté et les conflits, ils sont discutés

pour plus de clarté et d’exactitude
Spécification des besoins logiciels
 Spécification des besoins logiciels

 après que les exigences ont été recueillies auprès de diverses parties prenantes.

 l'analyste du système créé le SRS

 SRS (software requirement specification)

 cahier des charges
 description de l’environnement du logiciel

 spécification fonctionnelle
 les fonctions que le logiciel doit offrir

 comportement en cas d’erreurs

 cas où le logiciel ne peut pas accomplir une fonction

 performances requises
 temps de réponse, encombrement en mémoire, sécurité de
fonctionnement
 cahier des charges
 les interfaces avec l’utilisateur
 la présentation des écrans, la disposition des états imprimés, etc.

 interfaces avec d’autres logiciels et le matériel

 contraintes de réalisation
 l’environnement de développement
 le langage de programmation à utiliser,
 les procédures et normes à suivre, etc.
Langage du SRS

 Les exigences reçues du client sont écrites en langage naturel.

 les exigences destinées à l’équipe de développement sont en langage technique

4. Validation des besoins logiciels

Conditions de validation :

1. La mis en pratique est possible

2. Valides selon la fonctionnalité et le domaine du logiciel

3. absence d’ambiguïtés
 Références Bibliographiques

Kerzazi N, Exigences et spécifications du logiciel, Cours, Ecole polytechnique Montréal, Canada.

Jacquenet F,Génie logiciel, Cours, université st-etienne, France.

Boudaa B, Génie logiciel, Cours Master 1, Université Ibn khaldoun Tiaret , Algerie.

Raphael Y, Génie logiciel 2,Cours Master, Congo-Kinshasa, 2019.