Spécifications (ou exigences) non fonctionnelles : définition
Les exigences non fonctionnelles (ENF) ou NonFunctional Requirement en Anglais (NFR) ne sont pas directement liées aux caractéristiques et aux fonctionnalités de votre application, mais plutôt à d’autres aspects de la conception et du développement de votre application.
Plus précisément, les exigences non fonctionnelles concernent les performances, la disponibilité et l’évolutivité. Elles définissent la manière dont votre application doit fonctionner dans diverses circonstances, notamment en cas de charge ou d’erreur, ainsi que la manière dont elle évoluera en fonction des différents niveaux d’utilisation.
Les exigences non fonctionnelles peuvent être divisées en deux grandes catégories : les performances et l’évolutivité. Les performances font référence à la rapidité avec laquelle une application peut répondre lorsque les utilisateurs soumettent des demandes ou des données.
L’évolutivité fait pour sa part référence à la capacité d’une application à gérer des quantités croissantes de trafic sans causer de problèmes ou d’erreurs ou la faciliter d’implémenter de nouvelles fonctionnalités. Les exigences non fonctionnelles affectent donc la manière dont le code sera développé.
Les NFR doivent toujours être décrites en termes clairs, précis et non ambigus. Elles doivent être quantifiées – par exemple, le système doit pouvoir traiter 100 000 clients simultanément avec un temps de réponse inférieur à 2 secondes par utilisateur.
Que contiennent les spécifications fonctionnelles d’une application ?
Plus vous identifierez de contraintes, plus il sera facile de construire un système viable.
Tenez compte de l’environnement dans lequel votre système fonctionnera avant de concevoir votre solution.
Regardez la situation dans son ensemble pour vous assurer que votre application est conforme à toutes les réglementations, licences et normes applicables.
Lorsque vous construisez un système, réfléchissez à la facilité avec laquelle il sera possible de le mettre à jour ultérieurement ou de traiter les erreurs qui pourraient survenir. Si vous concevez une application destinée à être utilisée à l’étranger, gardez à l’esprit la facilité avec laquelle les utilisateurs d’autres pays pourront installer et exécuter votre programme.
Pour vous faciliter la vie, vous pouvez les répartir en différentes catégories :
- Contraintes pesant sur le système : prix maximum de la solution à développer, ressources humaines et matérielles imposées, …
- Conformité du système à un environnement : normes réglementaires, documentaires, conformité aux licences acquises, …
- Maintenabilité du système : traçage des erreurs, possibilité des mises à jour, extensibilité / modifiabilité du système initial, supportabilité en fonction de l’implantation géographique du futur système, testabilité…
- Performance du système : charge utilisateurs / transactions
- Portabilité du système : compatibilité avec diverses plateformes, facilité de remplacement d’autres systèmes en place, facilité d’installation et de désinstallation de l’application …
- Fiabilité du système : capacité à gérer les erreurs du système, densité des défauts de qualité, capacité à être remis en état rapidement, capacité à résister aux attaques…
- Sécurité du système : traçage des mises à jour des données dans le système, gestion de la confidentialité, gestion de l’intégrité des données, protection des données personnelles …
- Utilisation du système : facilité d’utilisation en limitant le nombre de clic à maximum 3 clics pour finaliser la transaction, rendre l’application attractive à une certaine audience (facteurs émotionnels), certification du système à une technologie particulière, capacité à respecter les exigences d’un pays, réutilisabilité de certains composants…
Exigences fonctionnelles et non fonctionnelles quelle différence ?
Lorsqu’on parle d’exigences fonctionnelles, il s’agit des exigences que l’utilisateur final demande spécifiquement comme des services de base rendus par le système.
Toutes ces fonctionnalités doivent nécessairement être intégrées au logiciel ou à l’application dans le cadre du contrat. Elles sont représentées ou énoncées comme l’entrée à donner au système, l’opération effectuée et la sortie attendue. Il s’agit essentiellement des exigences énoncées par l’utilisateur qui sont directement visibles dans le produit final, par opposition aux exigences non fonctionnelles.
Les exigences non fonctionnelles, quant à elles, peuvent être définies simplement comme des conditions ou des capacités qui doivent être respectées ou satisfaites par le système mais qui ne contribuent pas directement à satisfaire les besoins des utilisateurs finaux ou d’autres parties prenantes.
Comprendre la différence entre exigences fonctionnelles ou non fonctionnelles
Spécifications fonctionnelles | Spécifications non fonctionnelles |
Une exigence fonctionnelle définit un système ou son composant. | Une exigence non fonctionnelle définit l’attribut de qualité d’un système logiciel. |
Spécifient « Que doit faire le système logiciel ? » | Imposent des contraintes sur « Comment le système logiciel doit-il répondre aux exigences fonctionnelles ? » |
L’exigence fonctionnelle est spécifiée par l’utilisateur. | L’exigence non fonctionnelle est spécifiée par des personnes techniques, par exemple l’architecte, les responsables techniques et les développeurs de logiciels. |
Défini au niveau d’un composant. | Appliqué à un système dans son ensemble. |
Aident à vérifier la fonctionnalité du logiciel. | Aident à vérifier les performances du logiciel. |
Des tests fonctionnels tels que le système, l’intégration, de bout en bout, les tests d’API, etc. sont effectués. | Des tests non fonctionnels tels que les tests de performance, de stress, d’utilisabilité, de sécurité, etc. sont effectués. |
Exemple de spécifications non fonctionnelles
Exemple – Exigence fonctionnelle | Exemple – Exigence non fonctionnelle |
1) Authentification de l’utilisateur chaque fois qu’il se connecte au système. 2) Arrêt du système en cas de cyberattaque. 3) Un e-mail de vérification est envoyé à l’utilisateur chaque fois qu’il s’inscrit pour la première fois sur un système logiciel. | 1) Les e-mails doivent être envoyés avec une latence ne dépassant pas 12 heures à partir d’une telle activité. 2) Le traitement de chaque requête doit se faire dans les 10 secondes 3) Le site doit se charger en 3 secondes lorsque le nombre d’utilisateurs simultanés est > 10000 |
Les spécifications non fonctionnelles en bref
Malheureusement, dans beaucoup de projets informatiques, les spécifications ou exigences non fonctionnelles ne sont pas identifiées, voire mises de côté.
Il va sans dire que l’absence d’exigences non fonctionnelles peut mener à de gros problèmes lors des phases de conception et de développement.
Dans les meilleurs des cas, ces défauts et erreurs seront corrigés dans les phases de tests unitaires et fonctionnels à condition que des scénarios aient été mis en place et bien pensés.
Dans la plupart des cas, des exigences fonctionnelles non rédigées conduisent votre projet à l’échec.
L’absence de NFR (Nonfunctional requirements) peut rendre votre solution temporairement ou définitivement inutilisable.
Si vous dépensez du temps et de l’argent dans un projet d’application web ou mobile, ne négligez pas les spécifications non fonctionnelles ! Définir vos exigences, c’est s’assurer qu’elles seront prises en compte par l’équipe en charge de développer votre projet. Elles ont un impact sur la réussite du développement.
Vous souhaitez être accompagné dans la rédaction de votre cahier des charges, vos spécifications fonctionnelles, non fonctionnelles et techniques ?
Nous rédigeons vos spécifications non-fonctionnelles pour et avec vous. Chaque parcours utilisateur y est référencé et scénarisé avec un parcours optimal, les incidents possibles et les enchaînements. Cette étape est réalisée par un Business Analyst sous forme d’ateliers auxquels vous participez pour garantir la vision métier.