Vous venez d'apposer le bandeau {{Demande de traduction}} du Projet:Traduction/*/Demandes.

Veuillez créer (exemple détaillé) la sous-page qui assurera le suivi du processus de traduction en cliquant sur Projet:Traduction/Exigence.

Puis suivez les instructions fournies sur la page ainsi créée.

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 la complétude ;
• 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

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 de mise en œuvre.

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 d'un point de vue haut niveau. Elles répondent aux exigences métier et sont couramment formulées comme les fonctionnalités que le sytème doit réaliser. On les appelle également exigences fonctionnellles ou spécification 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.

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

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 usuellement liées à des exigences de processus destinées à être une façon pratique de les obtenir.

For exemple, a non-functional requirement to be free from backdoors may be satisfied by replacing it with a process requirement to use en:pair programming. en:Avionics Software with its complicated safety requirements must follow the DO-178B development process.

Testability is essentially a form of clarity, which indeed is necessary but can divert attention from other important issues. A requirement can be testable yet incorrect; and assessing testability often will not detect incorrect requirements. Moreover, testability is totally irrelevant with regard to a requirement which has been overlooked. Mere analysis, inspection, or review alone will find some of these issues but generally is far weaker than usually is realized. There are more than 21 more powerful ways to test or evaluate requirements adequacy and more than 15 ways to strengthen testing or evaluation of design adequacyModèle:Fact.

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 en:software inspection rigoureuse ont été présentées pour aider à traiter de tels problèmes. Les ambiguïtés, les imperfections, et les incohérences qui peuvent être résolues dans la phase d'exigences coûtent typiquement des ordres de grandeur plus faibles à corriger 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).

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

Des méthodologies modernes en ingénierie logiciel comme l'en:Extreme programming posent la question du besoin de décrire rigoureusement les exigences logiciel, 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)