Réponse.

L'analyste métier est responsable de la collecte, de la validation et de la documentation complètes non seulement des exigences fonctionnelles, mais aussi des exigences non fonctionnelles : rapidité de fonctionnement du système, sécurité, évolutivité, disponibilité, ergonomie de l'interface. Pour cela, il interagit étroitement avec les parties prenantes (en particulier avec l'entreprise et l'informatique), utilise des scénarios et analyse les normes. Il doit non seulement recueillir les attentes explicites, mais aussi identifier les besoins cachés (par exemple, la réglementation sur la protection des données). En fin de compte, l'analyste formalise les exigences non fonctionnelles dans la documentation, les valide avec l'équipe projet et technique, et contrôle le respect de ces exigences tout au long du projet.

Caractéristiques clés :

• Identification des exigences cachées et spécifiques par le biais d'entretiens et d'analyses de normes
• Assurer la documentation et la validation des exigences non fonctionnelles
• Contrôle de la conformité de la mise en œuvre aux critères non fonctionnels validés

Questions piégeuses.

Est-il suffisant de simplement décrire les exigences non fonctionnelles dans un texte sans métriques ni précisions ?

Non, les formulations abstraites ("rapide", "sûr") ne sont pas valables pour la validation. Des paramètres clairs sont nécessaires : par exemple, un temps de réponse ne dépassant pas 2 secondes.

Les exigences non fonctionnelles ne concernent-elles que les spécialistes techniques ?

Non, l'analyste doit identifier et formaliser ces exigences en collaboration avec l'entreprise, car leur non-respect entraînera une insatisfaction des intérêts clés de l'entreprise.

Est-il possible de reporter le travail sur les exigences non fonctionnelles aux étapes finales du projet ?

Non, ces exigences sont souvent critiques pour l'architecture de la solution. Leur identification à des étapes tardives conduit à des retouches et à des coûts élevés.

Erreurs typiques et anti-modèles

• Description implicite, formelle ou trop générale des caractéristiques non fonctionnelles
• Ignorer les normes de sécurité, SLA, exigences légales
• Identification tardive des exigences non fonctionnelles avec un risque de retravailler considérablement

Exemple de la vie réelle

Cas négatif : Des exigences de "commodité" et de "rapidité" ont été décrites dans le cahier des charges sans fixer de métriques spécifiques. Avantages : Moins coûteux au moment de la rédaction du document Inconvénients : Impossible de présenter des réclamations à l'équipe lorsque le résultat n'a pas satisfait le client

Cas positif : Validé : "La vitesse de chargement de la page — jusqu'à 2 secondes avec une charge de jusqu'à 1000 utilisateurs, niveau SLA — 99,95 %". Exigences formalisées concernant la protection des données personnelles. Avantages : Vérification claire du résultat, réduction des risques de retouches, transparence pour tous les participants Inconvénients : Nécessitait du temps et des validations avec l'informatique et les avocats