Exigences fonctionnelles et non fonctionnelles

Comprendre l’enjeu et le périmètre

Les formaliser tôt évite une solution qui fonctionne en démonstration mais ne supporte ni la charge, ni les risques, ni les conditions réelles d’utilisation.

Relier chaque exigence à un bénéficiaire, un contexte, une priorité, un critère d’acceptation et une méthode de vérification.

Passer à l’action

• Recueillir les scénarios métier et les contraintes
• Transformer les attentes vagues en critères testables
• Tracer les exigences jusqu’aux décisions et aux tests

Suivez une information plutôt qu'un organigramme : qui la crée, qui la transforme, qui la valide et qui s'en sert pour agir ? Les ruptures apparaissent souvent entre deux services, alors que chaque application semble fonctionner correctement prise isolément.

Responsabilités et moyens

Le métier précise le résultat, les experts qualifient les contraintes, et le sponsor arbitre les conflits de coût, délai et niveau de service.

Intégrer les coûts de test, d’environnement, de mesure et de maintien des exigences pendant les évolutions.

Produire et vérifier

Livrable utile

Un registre d’exigences versionné, accompagné des scénarios de recette et des arbitrages.

Preuve à rechercher

Pour une exigence de rapidité, préciser l’opération, la charge, la mesure et le seuil, rejeter les formulations impossibles à tester.

Indicateur à interpréter

Suivre la proportion d’exigences prioritaires testées et acceptées, sans assimiler couverture de test et absence de défaut.

Un schéma est une hypothèse de fonctionnement. Demandez à un utilisateur de raconter un dossier réel, y compris une exception et un retour en arrière. Notez les outils informels et les personnes indispensables plutôt que de les faire disparaître du dessin.

Arbitrages et dépendances

Des exigences comme « sécurisé » ou « rapide » laissent place à des interprétations incompatibles entre client et fournisseur.

Les contraintes réglementaires, les interfaces, les données, les volumes et les engagements contractuels doivent être pris en compte.

La bonne unité de raisonnement est le service rendu. Remplacer un logiciel sans traiter une validation ambiguë ou une information manquante peut déplacer le problème. Distinguez donc ce qui relève de l'organisation, de la donnée et de la technique avant de choisir une réponse.