Votre objectif est de fournir à vos clients un produit qui répondra entièrement à leurs attentes. Il importe dès lors de fixer des exigences, afin que tous les membres de l’équipe soient sur la même longueur d’onde et visent les mêmes résultats. Pour éviter des coûts inattendus, faites-le au début du projet. Les exigences non fonctionnelles en particulier sont coûteuses mais si elles ne sont pas suffisantes, l’expérience utilisateur sera médiocre. Voici donc la différence exacte entre exigences fonctionnelles et non fonctionnelles et la manière d’établir des exigences optimales.
Qu’est-ce qu’une exigence fonctionnelle ?
Les exigences fonctionnelles définissent le système de base et déterminent donc ce que le système fera et ne fera pas. Il s’agit ici de la manière dont le système réagit aux apports, ce qui se traduit généralement en pratique par une situation hypothétique, comme les calculs, la saisie de données et les processus opérationnels. Les exigences fonctionnelles font donc en sorte que le système fasse ce qu’il doit faire. Si elles ne sont pas mises en œuvre, le système ne fonctionnera pas. L’accent est ici placé sur ce que l’utilisateur veut atteindre.
Qu’est-ce qu’une exigence non fonctionnelle ?
Alors que les exigences fonctionnelles déterminent ce qu’un système fait, leurs homologues non fonctionnelles définissent la manière dont il le fait. Elles sont non fonctionnelles car elles n’ont pas d’incidence sur ce que le système est en mesure de réaliser ou non. Sans exigences non fonctionnelles, le système fonctionnera mais pas de la manière souhaitée par l’utilisateur. Tout tourne donc autour de la convivialité pour l’utilisateur. Il s’agit des propriétés du produit et des attentes de l’utilisateur. Cliquer sur un onglet d’un site web en est un bon exemple. D’un point de vie fonctionnel, c’est la seule condition pour qu’une nouvelle page s’ouvre. Sur le plan non fonctionnel, il est important que cette page se charge rapidement. Si cela prend trop de temps, l’expérience utilisateur touchera le fond.
Comment définir des exigences ?
Vous pouvez assurément réunir les parties prenantes pour une séance de brainstorming, mais n’oubliez pas d’inviter aussi des membres du groupe cible. Si les parties prenantes ne sont pas les futurs utilisateurs, ils ne connaîtront pas réellement les besoins de ces derniers. Pour définir les exigences non fonctionnelles, vous dépendez donc principalement de votre public cible.
Lors du brainstorming, vous pouvez passer en revue quatre types d’exigences fonctionnelles. Le premier groupe comprend les business requirements. Il s’agit du but principal, par exemple un catalogue en ligne, un webshop ou un nouveau produit. Il englobe également le flux de travail et le choix de la personne qui validera. Vous avez aussi les fonctions administratives pour les tâches de routine qui seront exécutées par le système, comme les comptes rendus. Vous devez ensuite fixer les user requirements. Il s’agit de ce que l’utilisateur doit pouvoir effectuer dans le système, un achat en ligne par exemple. Enfin, vous devez vous pencher sur les exigences du système en lui-même. Vous définirez les spécifications en fonction du matériel et du logiciel, ainsi que les actions et réactions du système.
Viennent ensuite les exigences non fonctionnelles, que l’on peut aussi subdiviser en plusieurs catégories. Le premier type comprend la convivialité pour l’utilisateur. L’accent repose ici sur la conception de l’interface. Tout est-il bien lisible ? La taille des onglets est-elle suffisante ? Il faut ensuite prendre en compte la disponibilité du système. Doit-il être opérationnel en permanence ? La troisième catégorie d’exigences concerne l’évolutivité du système. Faut-il prévoir une marge d’évolution ? Pensez également à l’espace physique s’il s’agit de hardware. La catégorie suivante est axée sur les capacités de présentation, à savoir la vitesse du système. Le support technique du système est aussi un élément à prendre en compte. Cela se fera-t-il en interne ou faut-il prévoir un accès à distance pour une assistance externe éventuelle ? Enfin, la sécurité est un élément important. Tant l’installation physique que les données en ligne doivent être suffisamment protégées.
Le document de spécification des exigences
Il s’agit d’un outil courant pour répertorier les exigences. Commencez avec un objectif et un bref exposé du projet, pour placer les exigences dans un contexte et identifier des limites et hypothèses potentielles. Les exigences sont bien entendu narratives, mais les exprimer visuellement vous aidera aussi. Vos collègues moins familiers avec la technique doivent eux aussi pouvoir bien saisir les exigences.
Il existe trois autres manières de soutenir vos exigences. La première consiste à établir une work breakdown structure (WBS). Il s’agit de diviser le processus en fractionnant les exigences en éléments les plus petits possibles, avec une liste des tâches claire à la clé. Il est également utile de rédiger des témoignages d’utilisateurs. Vous y décrirez le fonctionnement du système du point de vue de l’utilisateur, compte tenu des souhaits de cet utilisateur spécifique. Dernière méthode de support : concevoir un cas d’utilisation. Vous y énumérerez étape par étape la marche à suivre pour permettre à l’utilisateur d’atteindre un but déterminé, par exemple passer commande en ligne.
Exemples d’exigences fonctionnelles et non fonctionnelles
Il existe bien entendu des zones grises, mais ces exemples mettront rapidement en évidence la différence entre fonctionnel et non fonctionnel. Une sauvegarde automatique de la base de données toutes les 24h, l’impression automatique des listes de commandes toutes les 4h, le rapport quotidien des erreurs à une certaine heure et l’accès aux données clients réservé aux managers constituent des exemples d’exigences fonctionnelles. Le respect du RGPD, la possibilité de consulter les informations d’un profil en quelques clics ou de charger des pages en 4 secondes, la capacité à satisfaire 3 millions d’utilisateurs, la couleur du fond d’écran… sont des exigences non fonctionnelles.
Dans la pratique, une exigence non fonctionnelle est souvent confrontée à une exigence fonctionnelle, comme en témoignent le quoi et le comment de l’ensemble du processus. Par exemple, l’envoi d’un mail de bienvenue lors de la création d’un nouveau compte est fonctionnel, tandis que l’envoi de ce mail dans un délai de 10 minutes est non fonctionnel. L’impression d’une adresse d’expédition une fois la commande finalisée est également une exigence fonctionnelle. En revanche, sur les dimensions de l’étiquette et le choix du papier pour l’impression sont des exigences non fonctionnelles.
Bonnes pratiques
Quelle que soit leur forme, les exigences doivent être faciles à comprendre et claires. Les décrire dans un langage courant est d’ailleurs un bon début. Privilégiez aussi une formulation active. Veillez à insérer dans chaque phrase un agent concis et efficace. Allez enfin droit au but dans vos formulations : utilisez ’doit’ plutôt que ’devrait’, afin d’exclure toute ambiguïté. Autre exemple : ne vous contentez pas d’indiquer qu’une page doit se charger ’rapidement’, mais citez aussi un nombre de secondes. Il est en outre important de maintenir une cohérence terminologique. Utilisez donc toujours le même mot pour les processus, phases, parties…
La possibilité de tester les exigences est un deuxième aspect à prendre en considération. En ce sens, vos exigences ne doivent poser qu’une seule condition. Cela les rendra plus synoptiques lors de la phase de test.
Troisièmement, il importe d’intégrer tous les scénarios possibles dans vos exigences, y compris ce que le système ne fera pas. Concentrez-vous sur les caractéristiques cruciales pour l’utilisateur. Des exigences trop nombreuses augmentent les coûts, réduisent l’impact et nuisent au produit. La convivialité pour l’utilisateur reste importante. Il est tout indiqué de vérifier si une exigence contribue à l’un des objectifs préétablis du projet.
Quatrième élément à prendre en compte : gardez une vue d’ensemble pendant le brainstorming. Essayez de comprendre la source des exigences des parties prenantes et des membres du groupe cible et leur lien avec les objectifs. Que visent-ils ? Il se peut que le but soit de résoudre un problème, mais il peut être utile de commencer par faire part du problème au groupe. Cela permettra de proposer plusieurs solutions lors du brainstorming, afin d’aboutir ensemble au meilleur résultat. Retenez aussi qui a posé quelle exigence. Vous devez également tenir compte de l’autorité de vos collègues. Il est évident que vous ne pouvez pas refuser une demande de votre chef de projet. Veillez enfin à ce que les exigences définitives soient réalisables et non contradictoires. Gardez à l’esprit que les exigences non fonctionnelles sont également importantes. Un site web qui met 30 secondes à charger aura beau répondre à toutes les exigences fonctionnelles, il sera inutilisable.
Source : www.qracorp.com
Envie d’en savoir plus ?
Vous aimeriez acquérir une connaissance approfondie de l’analyse fonctionnelle ? Faire en sorte que les exigences n’aient plus aucun secret pour vous ? Et pouvoir immédiatement mettre vos acquis en pratique ? La formation Analyse fonctionnelle est faite pour vous !
