Vous êtes sur la page 1sur 6

Exigence (ingénierie)

Une exigence est, dans le domaine de l'ingénierie, un besoin, une nécessité, une attente auquel un produit ou un service doit répondre ou une
contrainte qu'il doit satisfaire. L'exigence peut être exprimée par une partie prenante (utilisateur, client, commercial, analyste de marchés,
gestionnaire de produits, etc.) ou déterminée par les processus d'ingénierie et en particulier les activités d'études.

Sommaire
Principe général
Exigences dans l'ingénierie système et logiciel
Distinguer plusieurs sortes d'exigences fonctionnelles
Exigences produit & exigences de processus
Quelques facteurs pour une bonne définition des exigences
Classification
Qualité des exigences
Aptitude aux tests
Processus de développement des exigences
Rédaction des exigences
Analyse des exigences
Changements dans les exigences
Cas de l'ingénierie informatique
Vocabulaire spécifique
Débats concernant la nécessité de la rigueur dans les exigences logicielles
Un exemple d'exigence : la langue
Logiciels
Références
Voir aussi
Bibliographie
Articles connexes
Liens externes

Principe général
L'approche commune à tous les domaines d'ingénierie est de définir les besoins, d'envisager des solutions, et de livrer la solution la plus
1
appropriée . Plus précisément, les activités consistent à définir le problème, collecter les informations pertinentes, générer des idées de
2
solutions possibles, les analyser et choisir la plus appropriée, et mettre la solution en œuvre . Les exigences forment la clé de voute de ces
activités. En effet, le besoin ou le problème nécessite d'être traduit en exigences pour la solution, et les informations collectées, l'analyse, et des
résultats expérimentaux au cours de la réalisation sont susceptibles d'affiner et d'enrichir ces exigences.

Tout au long du cycle d'ingénierie, l'ingénieur va gérer les exigences en utilisant les termes, les formes et les techniques propres au domaine
3
d'ingénierie considéré. Cette activité consiste en principe à les :

Éliciter : identifier, collecter et approfondir les exigences des parties prenantes ou d'autres sources (par exemple
exigences réglementaires ou conditions techniques);
Analyser : vérifier la cohérence et l'exhaustivité des exigences, créer des modèles, déduire des exigences techniques,
négocier au besoin des exigences avec les parties prenantes ;
Spécifier : documenter les exigences sous une forme aisément compréhensible pour les parties prenantes et facilement
utilisable pour les ingénieurs aux autres spécialistes impliqués dans la conception de la solution et sa réalisation ;
Valider : les exigences font en principe l'objet d'une validation, par exemple sous forme d'une revue de la spécification,
d'une maquette ou d'une vérification expérimentale (prototype)

Le développement des exigences peut avoir été précédé par une étude de faisabilité, ou un cadrage du projet. Lorsque le produit ou le service
est réalisé à la commande, les exigences initiales exprimées par le client sont documentées, soit lors de la procédures d'appel d'offres public ou
privé, soit dans les documents contractuels.
Dans l'approche classique de l'ingénierie, les exigences sont considérées comme des prérequis pour les étapes de conception et de
développement du produit ou du service. Par contre, pour l'ingénierie simultanée et les approches agiles, la gestion des exigences est intégrée
avec les autres activités tout au long du projet pour tenir compte de l'élaboration progressive du produit ou du service, et la découverte de
nouvelles exigences qui en découle.

Exigences dans l'ingénierie système et logiciel

Distinguer plusieurs sortes d'exigences fonctionnelles

Dans l'ingénierie système, une exigence peut être la description de ce qu'un système doit faire. Ce type d'exigence spécifie quelque chose que
le système livré doit être capable de faire. Un autre type d'exigence spécifie quelque chose sur le système lui-même, et de quelle manière il
exécute ses fonctions. De telles exigences s'appellent souvent « exigences non fonctionnelles », « exigences de performance » ou « exigences
de qualité de service ». Exemples de ce type d'exigences : la disponibilité, la testabilité, la facilité de maintenance et la facilité d'utilisation.

Un ensemble d'exigences définit les caractéristiques ou propriétés du système désiré (exigé). Une « bonne » liste d'exigences évite de spécifier
la manière pour le système de mettre en œuvre ces exigences, laissant ce genre de décision pour les activités de conception. Un élément parmi
les exigences qui décrit comment mettre en œuvre le système s'appelle un biais.

En ingénierie logicielle, la même signification d'« exigences » est utilisée, à la différence près que l'attention se porte sur le logiciel lui-même.

Exigences produit & exigences de processus

Les projets sont soumis à trois sortes d'exigences :

Les exigences métier (en anglais en:Business requirements) qui décrivent le quoi dans les termes du métier. Elles
décrivent ce qui doit être fourni ou réalisé pour produire de la valeur.
Les exigences produit qui décrivent le produit ou le système à un haut niveau. Elles répondent aux exigences métier et
sont couramment formulées comme les fonctionnalités que le système doit réaliser. On les appelle également exigences
fonctionnelles ou spécifications fonctionnelles.
Les exigences de processus qui décrivent le comment. Ces exigences prescrivent les processus que l'on doit suivre et
les contraintes auxquelles on doit se conformer pour la réalisation du système. Dans ce cas, on trouve par exemple des
exigences de sécurité, d'assurance qualité, ou de management.

Les exigences produit et de processus sont liées. Les exigences de processus sont souvent imposées pour atteindre les exigences produit de
haut niveau. Par exemple un coût maximum de développement (qui est une exigence de processus) peut être imposé afin d'atteindre une
exigence sur le prix de vente minimum (qui est une exigence produit). Une exigence de maintenabilité du produit (exigence produit) est
souvent accompagnée d'exigences de suivre un certain style de programmation (exigence de processus) telles que la programmation orientée
objet, les motifs de conception ou encore le respect de charte de nommage.

Les trois types d'exigences sont vitales pour tout développement de système.

Quelques facteurs pour une bonne définition des exigences

Classification

Les exigences sont classées généralement en trois catégories :

1) Exigences fonctionnelles - Elles décrivent les caractéristiques du système ou des processus que le système doit exécuter. On trouve dans
cette catégorie les règles métier

2) Exigences non fonctionnelles - Elles décrivent les propriétés que le système doit avoir ; par exemple les exigences techniques de sécurité
informatique (confidentialité, intégrité, disponibilité), de performance, d'accessibilité, selon des critères définis,

3) Contraintes - Les limites du développement en quelque sorte : comme définir un système d'exploitation sur lequel le système doit
fonctionner, ou définir quel langage de programmation doit être utilisé pour mettre en œuvre le système.

Les exigences sont notoirement difficiles à présenter à un niveau idéal. Souvent, des experts (voir en:expert users) sont employés pour établir
la relation entre les utilisateurs et les développeurs. Ces experts sont en principe capables d'exprimer des exigences fonctionnelles d'une façon
qui soit facilement interprétable dans les caractéristiques de conception du système, et de plus compréhensible par les utilisateurs finaux.
L'analyse de la valeur a été créée dans le but notamment d'interroger et de qualifier ce niveau d'exigence.

Qualité des exigences


4
De bonnes exigences doivent être :
Nécessaires – Elles doivent porter sur des éléments nécessaires, c'est-à-dire des éléments importants du système que
d'autres composants du système ne pourraient pas compenser.
Non ambigües – Elles doivent être susceptibles de n'avoir qu'une seule interprétation.
Concises – Elles doivent être énoncées dans un langage qui soit précis, bref et agréable à lire, et qui de plus
communique l'essence de ce qui est exigé.
Cohérentes – Elles ne doivent pas contredire d'autres exigences établies, ni être contredites par d'autres exigences. De
plus, elles doivent, d'un énoncé d'exigence au suivant, utiliser des termes et un langage qui signifie la même chose.
Complètes – Elles doivent être énoncées entièrement en un endroit et d'une façon qui ne force pas le lecteur à regarder
un texte supplémentaire pour savoir ce que l'exigence signifie.
Précise - Elles doivent inclure la précision ou une marge d'erreur (un intervalle, un pourcentage, supérieur / inférieur à ...),
cela permet lors de la vérification d'avoir de la souplesse surtout sur des tests sur plusieurs produits.
Accessibles – Elles doivent être réalistes quant aux moyens mis en œuvre en termes d'argent disponible, avec les
ressources disponibles, dans le temps disponible.
Vérifiables – Elles doivent permettre de déterminer si elles ont été atteintes ou non selon l'une de quatre méthodes
possibles : inspection, analyse, démonstration, ou test.

La qualité des exigences peut être évaluée par revue (relecture par des pairs) ou par des outils de vérification de la qualité des exigences. Selon
le formalisme utilisé pour exprimer les exigences (langage naturel, modèles formels ou semi-formels...) les outils seront capables de détecter
certaines erreurs :

Erreurs de syntaxe
Incohérences
Ambiguïtés

Aptitude aux tests

La plupart des exigences doivent être vérifiables par des tests. Si ce n'est pas possible, une autre méthode de vérification doit pouvoir être
utilisée (par exemple, analyse, inspection, ou analyse de la méthode de conception). Des exigences testables sont une composante importante
de la validation.

Certaines exigences, de par leur structure même, ne sont pas testables. Elles comprennent par exemple les exigences qui disent que le système
ne montrera jamais ou qu'il montrera toujours telle propriété. Un test adéquat d'une telle exigence demanderait une infinité de cycles de test.
Ce genre d'exigence est souvent réécrit en donnant une période de temps finie et réaliste.

Des exigences non-fonctionnelles non-testables peuvent être gardées comme documentation à l'usage des clients ; cependant, elles sont
habituellement liées à des exigences de processus destinées à être un moyen pratique de les obtenir.

Par exemple, on peut satisfaire une exigence non-fonctionnelle consistant à s'affranchir des portes dérobées (backdoors) en la remplaçant par
une exigence de processus qui utilise la programmation en binôme. Les logiciels d'avionique avec leurs exigences complexes de sûreté doivent
suivre le processus de développement DO-178B.

L'aptitude aux tests consiste essentiellement à donner de la clarté, qui est effectivement nécessaire mais peut détourner l'attention par rapport à
d'autres problèmes importants. Une exigence peut être apte aux tests mais incorrecte ; et l'évaluation de l'aptitude aux tests ne détectera souvent
pas des exigences incorrectes. De plus, l'aptitude aux tests n'a pas de sens par rapport à une exigence qui a été ignorée. La pure analyse,
l'inspection, ou la revue seules pourront répondre à ces problèmes mais généralement plus faiblement qu'on ne le fait habituellement. Il y a plus
de 21 moyens plus puissants de tester ou d'évaluer l'adéquation d'exigences et plus de 15 moyens de renforcer les tests ou l'évaluation du bien-
fondé d'une conception. [réf. nécessaire]

Processus de développement des exigences

Rédaction des exigences

Les exigences doivent être écrites de telle manière qu'elles orientent la création et la modification d'un système selon les règles métier (ou
règles de gestion) appropriées au contexte et au domaine et dans lequel le système doit être utilisé.

Les systèmes doivent normalement se conformer au domaine d'activité dans lequel ils sont exploités.

Analyse des exigences

Les exigences sont sujettes à des problèmes d'ambiguïté, d'imperfections, et d'incohérence. Des techniques telles qu'une inspection de logiciel
rigoureuse ont été présentées pour aider à traiter de tels problèmes. Lorsque les ambiguïtés, les imperfections, et les incohérences sont résolues
dans la phase d'exigences, l'ordre de grandeur du coût de correction est moins élevé que lorsque ces mêmes problèmes se retrouvent dans des
étapes ultérieures de développement du produit. L'analyse des exigences s'efforce de résoudre ces problèmes.
Il y a une distinction en ingénierie entre les exigences qui sont trop vagues, et celles qui sont si détaillées qu'elles :

1. prennent du temps à être rédigées,


2. commencent à limiter les options de mise en œuvre disponibles,
3. sont coûteuses à produire.

Changements dans les exigences

Avec le temps, les exigences peuvent évoluer : c'est ce qui est pris en compte dans les re conception de mi-vie d'un produit.

De même durant un projet, un cahier des charges peut être revu. Dans ce cas, la modification du cahier des charges contractuel fait l'objet d'un
avenant au contrat.

Dans tous les cas, une fois les exigences définies et approuvées, elles doivent être gérées, vérifiées (contrôle qualité) et suivies (Contrôle des
modifications en:change control). Dans le cas de projets difficiles, des exigences peuvent être ne pas être atteintes ou peuvent être altérées
avant que le système ne soit terminé. Cette caractéristique des exigences a conduit à des études et des pratiques sur la gestion des exigences
(en:Requirements Management).

Cas de l'ingénierie informatique

Vocabulaire spécifique

En ingénierie informatique, les exigences sont traditionnellement de trois types appelés : spécifications générales, spécifications détaillées, et
spécifications techniques. On retrouve sensiblement les trois types d'exigences métier, produit, et processus.

Débats concernant la nécessité de la rigueur dans les exigences logicielles

Des méthodologies modernes en ingénierie logicielle comme l'Extreme programming posent la question du besoin de décrire rigoureusement
les exigences logicielles, qu'elles considèrent comme un objectif mouvant.

Ces méthodologies décrivent les exigences d'une façon informelle, en utilisant des retours d'expérience (REX), qui peuvent être appelés dans
certains cas « user stories » (résumés concis relatifs à une page indexée qui explique un aspect de ce que le système devrait faire), et composée
d'une série de cas de tests de validation pour ces retours d'expérience.

La typologie d'utilisation des systèmes doit diriger vers telle ou telle méthode. Un système de pilotage automatique d'avion ne pourra pas être
développé par retour d'expérience utilisateur. D'autre part, un site web dynamique dont on ignore encore le public avant sa conception ne
pourra pas faire l'objet d'exigences métiers formulées.

Un exemple d'exigence : la langue

Les exigences formulées dans le cadre d'un appel d'offres pour l'achat et la mise en œuvre d'un progiciel peuvent inclure des critères relatifs à
la langue du progiciel.

En France, il existe un dispositif réglementaire qui impose aux services et établissements publics de l'État d'utiliser les termes de la langue
française publiés au Journal officiel dans tous les documents administratifs (articles 11 et 12 du décret du 3 juillet 1996 relatif à l'enrichissement
de la langue française).

Logiciels
Il existe de nombreux outils de gestion des exigences.

La plupart intègrent le référentiel, c'est-à-dire que les exigences sont rédigées, enregistrées et maintenues dans le format propriétaire du logiciel:

Blueprint (Blueprint Software Systems)


Objectiver de l'éditeur Respect-IT
Integrity lié avec Windchill PDMLink de l'éditeur PTC
Accept 360°
CaliberRM
Compuware Optimal Trace
IBM Rational DOORS
Envision Requirements
GenSpec
IBM Rational RequisitePro
LDRA TBreq
Polarion REQUIREMENTS
PowerAMC intègre un outil de gestion d'exigences qui fonctionne avec Microsoft Office
Projet2Team intègre un outil de gestion d'exigences qui permet d'importer les cahiers des charges depuis Microsoft Word
Serena Dimensions RM
Un wiki (TWiki, XWiki, etc)
UProm
Visure IRQA
Requirements Quality Analyzer (RQA)
Semios for requirements, analyse la qualité des exigences et alerte le rédacteur sur des problèmes de compréhension
possibles

Certains outils exploitent un référentiel externe sous la forme de documents Microsoft WORD ou PDF:

Reqtify
ReqFlow
Reqchecker

Références
1. (en) Académie royale d'ingénierie, « Principles of engineering design » (https://www.raeng.org.uk/publications/other/armstro
ng-keynote), sur raeng.org.uk, 1999
2. (en) Bourque, Pierre, Fairley, R. E. (Richard E.) et IEEE Computer Society, Guide to the software engineering body of
knowledge (SWEBOK 3.0), 2014 (ISBN 9780769551661,
OCLC 1100623800 (https://worldcat.org/oclc/1100623800&lang=fr), lire en ligne (https://www.worldcat.org/oclc/110062380
0)), p. Chapitre 15 sur les fondements de l'ingénierie
3. (en) Bourque, Pierre, Fairley, Richard E. et IEEE Computer Society, Guide to the software engineering body of knowledge
(SWEBOK v3.0), 2014 (ISBN 9780769551661, OCLC 1100623800 (https://worldcat.org/oclc/1100623800&lang=fr), lire en
ligne (https://www.worldcat.org/oclc/1100623800)), p. Chapitre 1 consacré à la gestion des exigences
4. http://www.cours.polymtl.ca/log3410/bibliographie/IEEE/Pratique_Recommandee_Par_IEEE_pour_la%20_Specification.pdf

Voir aussi

Bibliographie
Livre en français : Ingénierie des exigences - Méthodes et bonnes pratiques pour construire et maintenir un référentiel (htt
ps://www.dunod.com/entreprise-economie/ingenierie-exigences-methodes-et-bonnes-pratiques-pour-construire-et-mainte
nir) - Ed. Dunod 2014

Articles connexes
Gestion des exigences (en anglais « Requirements Management »)
Analyse des exigences (en anglais « Requirements analysis »)
Cas d'utilisation (en anglais « Use case »)
Récit utilisateur (en anglais, « User story »)
Règles métier (en anglais « Business rule »)
Spécification (informatique)

Liens externes

Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Exigence_(ingénierie)&oldid=183387761 ».

La dernière modification de cette page a été faite le 30 mai 2021 à 11:04.

Droit d'auteur : les textes sont disponibles sous licence Creative Commons attribution, partage dans les mêmes conditions ; d’autres conditions peuvent
s’appliquer. Voyez les conditions d’utilisation pour plus de détails, ainsi que les crédits graphiques. En cas de réutilisation des textes de cette page, voyez
comment citer les auteurs et mentionner la licence.
Wikipedia® est une marque déposée de la Wikimedia Foundation, Inc., organisation de bienfaisance régie par le paragraphe 501(c)(3) du code fiscal des
États-Unis.

Vous aimerez peut-être aussi