Exigence (Ingénierie)

Exigence (ingénierie)

En ingénierie, et plus particulièrement dans les procédures d'appel d'offres publiques et privées, les exigences sont l'expression d'un besoin documenté sur ce qu'un produit ou un service particuliers devraient être ou faire. Elles sont le plus souvent utilisées dans un sens formel dans l'ingénierie des systèmes et dans l'ingénierie logicielle.

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 d'un produit.

La phase de développement des exigences peut avoir été précédée par une étude de faisabilité, ou une phase d'analyse conceptuelle du projet. La phase d'exigences peut être décomposée en :

• Mettre au jour les exigences : rassembler les exigences des parties prenantes ;
• Analyser : vérifier la cohérence et l'exhaustivité ;
• Définir : écrire les exigences sous une forme aisément compréhensible pour les utilisateurs et les développeurs ;
• Spécifier : créer une interaction initiale entre les exigences et la conception.

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

Distinguer plusieurs sortes d'exigences fonctionnel

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 « qualité des exigences 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 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 (ce qui est un 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, et les exigences fonctionnelles de sécurité informatique (confidentialité,...)

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.

Qualité des exigences

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 ambiguës – 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, elle doit, 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.
• 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.

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.

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

Dans le temps, les exigences peuvent changer.

Dans ce cas, une fois définies et approuvées, les exigences devraient être vérifiées par en:change control. Pour beaucoup de projets, des exigences 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

Article détaillé : Spécification (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'en: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.

Voir aussi

• Règles métier
• Analyse des exigences (en:Requirements analysis)
• Cas d'utilisation en:Use case
• Gestion des exigences (en:Requirements Management)
• Traçabilité des exigences (en:Requirements traceability)
• Spécification (informatique)

Ce document provient de « Exigence (ing%C3%A9nierie) ».