Spécifications (ou exigences) non fonctionnelles : définition
Les spécifications non fonctionnelles (SNF), exigences non fonctionnelles (ENF), ou encore Non Functional 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 spécifications non fonctionnelles doivent toujours être détaillées en des termes clairs et précis afin d’éviter toute ambiguïté. Elles doivent être quantifiables. Par exemple, le système doit pouvoir traiter 30 000 clients simultanément avec un temps de chargement de page inférieur à 3 secondes par utilisateur.
Que contiennent les spécifications non fonctionnelles d’une application ?
Les spécifications non fonctionnelles peuvent être catégorisées en 8 thématiques distinctes.
1. Les ressources : L’application dépendra des ressources allouées (prix plafond, ressources humaines mobilisées, méthodologies choisies…). Il convient donc de bien les détailler.
2. Les contraintes réglementaires : Appréhendées, elles peuvent se gérer plus facilement (normes, conformité aux licences acquises, règles spécifiques au métier…).
3. Le temps de réponse : Une application web ou mobile performante doit répondre rapidement aux requêtes des utilisateurs, avec un temps de chargement des pages au plus bas.
4. La sécurité et fiabilité : Les applications gérants des données sensibles doivent respecter des normes de sécurité strictes (pour protéger les informations des utilisateurs contre tout accès non autorisé, résister aux tentatives d’hacking, se remettre en état simplement…).
5. La performance : La performance doit être choisie, et non subie. Voici quelques exemples de spécifications non fonctionnelles liées à la performance : la capacité en nombre de visiteurs en simultané, le temps de chargement et la rapidité d’exécution et le nombre de langues supportées dans l’application.
6. L’ergonomie : L’utilisation de l’application doit être simple et claire. Une interface utilisateur intuitive et bien conçue améliore l’expérience globale des utilisateurs.
7. La disponibilité : Selon les besoins des utilisateurs, certaines applications, telles que les plateformes bancaires en ligne, doivent être disponibles 24h/24 et 7j/7. Pensez à prévoir un contrat d’infogérance pour garantir une disponibilité optimale.
8. La maintenance : Pour que votre application soit pérenne, sa maintenance est nécessaire (traçabilité des erreurs, mises à jour, testabilité…), elle doit être pensée pour éviter les bugs, crashs ou erreurs de chargement et pour mettre en place les évolutions logicielles.
En tenant compte de toutes ces spécifications non fonctionnelles dès le début du processus de développement, les entreprises ou organisations peuvent créer des produits fiables, performants et économiques, gagnant ainsi la confiance de leurs utilisateurs.
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.
