La gestion des exigences est une approche systématique pour trouver, documenter, organiser et suivre les exigences
changeantes d'un système.
Nous définissons une exigence comme :
Une condition ou une capacité que le système doit remplir.
Notre définition formelle de la gestion des exigences est qu'il s'agit d'une approche systématique pour :
-
Recueillir, organiser et documenter les exigences du système
-
Etablir et gérer un accord entre le client et l'équipe de projet sur les exigences changeantes du système
Les clés d'une gestion efficace des exigences consistent à établir un compte-rendu clair des Exigences, ainsi que des attributs applicables à chaque type
d'exigence et une Traçabilité à
d'autres exigences et d'autres produits du projet.
La collecte des exigences peut paraître une tâche simple. Dans les projets réels toutefois, vous rencontrerez des
difficultés parce que :
-
Les exigences ne sont pas toujours évidentes et peuvent provenir de plusieurs sources.
-
Les exigences ne sont pas toujours faciles à exprimer en mots.
-
Il y a différents types d'exigences à différents niveaux de détail.
-
Le nombre d'exigences peut devenir ingérable s'il n'est pas contrôlé.
-
Les exigences se rapportent les unes aux autres ainsi qu'à d'autres produits du processus de conception du
logiciel.
-
Les exigences ont des propriétés ou des valeurs de propriétés uniques. Par exemple, elles ne sont ni également
importantes ni également faciles à satisfaire.
-
Il y a plusieurs parties intéressées, ce qui signifie que les exigences doivent être gérées par des groupes de
personnes inter-fonctionnels.
-
Les exigences changent au fil du temps.
Alors, quelles compétences devez-vous développer au sein de votre organisation pour vous aider à gérer ces difficultés
? Nous avons appris que les compétences suivantes sont importantes à maîtriser :
L'analyse du problème est réalisée pour comprendre les problèmes, les besoins initiaux des parties prenantes, et
proposer des solutions de haut niveau. C'est un acte de raisonnement et d'analyse pour trouver « le problème derrière
le problème ». Durant l'analyse du problème, il s'agit de parvenir à un accord sur le(s) problème(s) réel(s), et sur
les parties prenantes concernées. Vous définissez également, d'un point de vue métier, les limites de la solution ainsi
que les contraintes métier imposées à la solution. Vous devrez également analyser l'étude de rentabilité du projet de
manière à ce qu'il y ait une bonne compréhension du retour sur investissement attendu pour le système en construction.
Voir aussi Activité : analyser le problème.
Les exigences proviennent de plusieurs sources, comme par exemple les clients, les partenaires, les utilisateurs et les
experts du domaine. Vous devez savoir comment identifier les sources appropriées, accéder à ces sources et extraire les
informations de ces sources. Les individus qui fournissent les sources principales de ces informations sont appelés
"parties prenantes" dans le projet. Si vous développez un système d'information destiné à être utilisé en interne au
sein de votre entreprise, vous pouvez adjoindre à votre équipe de développement des personnes ayant une expérience
d'utilisateurs et une expertise dans le domaine métier. Très souvent, vous commencez les discussions au niveau du
modèle métier, plutôt qu'au niveau système. Si vous développez un produit destiné à être vendu sur le marché, vous
allez utiliser largement les personnes du marketing pour mieux comprendre les besoins des consommateurs sur le marché.
Les informations nécessaires peuvent être obtenues en utilisant des techniques telles que les interviews, le
brainstorming, le prototypage conceptuel, les questionnaires ou les analyses concurrentielles. Le résultat est une
liste de demandes ou besoins qui sont décrits textuellement ou graphiquement, et auxquels il sera accordé une priorité
relative les uns par rapport aux autres.
Voir aussi Activité : comprendre les besoins des parties
prenantes.
Définir le système signifie traduire et organiser la compréhension des besoins des parties prenantes en une description
significative du système à construire. A un stade précoce de la définition du système, il convient de s'accorder sur le
terme "exigence", le format de la documentation, la formalité du langage, le degré de spécificité des exigences
(combien et à quel niveau de détail), la priorité des demandes et le travail estimé (deux évaluations très différentes
habituellement réalisées par différentes personnes dans des exercices séparés), les risques techniques et de gestion et
la portée initiale. Une partie de cette activité peut comprendre des prototypes et des modèles de conception précoces,
directement liés aux plus importantes demandes des parties prenantes. Le résultat de la définition du système est une
description du système aussi bien en langage naturel que graphique.
Voir aussi Activité : définir le système.
Pour conduire efficacement un projet, vous devrez hiérarchiser soigneusement les exigences en utilisant les entrées
provenant de toutes les parties prenantes, et gérer sa portée. Trop de projets souffrent de la multiplication des «
oeufs de Pâques » (fonctionnalités que le développeur trouve intéressantes et motivantes), auxquels les développeurs
consacrent beaucoup de temps au lieu que de se concentrer au plus tôt sur les tâches qui limitent les risques liés au
projet ou stabilisent l'architecture de l'application. Pour vous assurer que vous éliminez ou réduisez les risques dans
le projet aussi tôt que possible, vous devez développer votre système d'une manière incrémentielle, en choisissant
soigneusement les exigences pour chaque incrément susceptible de limiter les risques dans le projet. Pour ce faire,
vous devez négocier la portée (de chaque itération) avec les parties prenantes dans le projet. Ceci exige
habituellement de bonnes compétences dans la gestion des prévisions concernant les résultats du projet à ses
différentes phases. Vous devez également contrôler les sources des exigences, le format des produits du projet et le
processus de développement lui-même.
Voir aussi Activité : Activité : gérer la portée du
système.
La définition détaillée des besoins doit être présentée d'une manière que les parties prenantes peuvent comprendre,
accepter et cautionner. Elle doit couvrir non seulement la fonctionnalité, mais également la conformité à toutes les
exigences légales ou réglementaires, de convivialité, de performance, de prise en charge et de gestion. Une erreur
fréquemment commise consiste à croire que ce que vous percevez comme complexe à construire a également besoin d'une
définition complexe. Ceci conduit à des difficultés dans l'explication de l'objet du projet et du système. Les
personnes seront peut-être impressionnées, mais ne donneront pas un bon apport car elles ne comprendront pas. Vous
devez fournir beaucoup d'efforts pour la compréhension du public auquel s'adressent les documents que vous produisez
pour décrire le système. Vous serez souvent amené à produire des descriptions différentes pour différents publics.
Vous avez remarqué que la méthodologie des cas d'utilisation, souvent en association avec de simples prototypes
visuels, constitue un moyen efficace de communiquer l'objet du système et d'en définir les détails. Les cas
d'utilisation aident à mettre les exigences dans le contexte ; ils donnent un descriptif de la manière dont le système
sera utilisé.
La spécification de la manière dont le système doit être testé constitue un autre composant de la définition détaillée
du système. Les plans de test et les définitions des tests à effectuer nous renseignent sur les capacités du système
qui seront vérifiées.
Voir aussi Activité : préciser la définition du
système.
Quel que soit le soin que vous apportez à la définition de vos exigences, il y aura toujours des choses à changer. Ce
qui rend l'évolution des exigences complexe à gérer n'est pas seulement le fait qu'un changement d'exigence signifie
plus ou moins de temps passé dans l'implémentation d'une nouvelle fonctionnalité particulière, mais également qu'un
changement d'une exigence peut avoir un impact sur les autres exigences. Vous devez vous assurer que vous donnez à vos
exigences une structure facilitant la gestion des changements et que vous utilisez des liens de traçabilité pour
représenter les dépendances entre les exigences et autres produits du cycle de vie de développement. La gestion des
changements comprend des activités telles que l'établissement d'une version de référence, l'identification des
dépendances importantes à tracer, la définition de la traçabilité entre les éléments associés et le contrôle des
changements.
Voir aussi Activité : gérer les changements d'exigences.
Vous trouverez plus d'informations sur ce sujet dans :
Concept : Exigences
Concept : Types d'exigences
Concept : Traçabilité
Livre blanc : Application de la gestion des exigences avec des cas d'utilisation
|