Quelle est la définition des exigences non fonctionnelles, selon vous ? Qu’écrivez-vous dans ce paragraphe lorsque vous rédigez vos spécifications fonctionnelles générales et détaillées ?
Lorsque nous parlons d’exigences non fonctionnelles, nous entendons généralement par-là tout ce qui n’est pas lié directement aux fonctionnalités principales du système. Je vous explique dans cet article ce qu’il est usuel de décrire.
Imaginez par exemple un système de réservation en ligne de chambres d’hôtels. Dans les Spécifications Fonctionnelles Détaillées, on peut par exemple décrire la fonctionnalité permettant de comparer les tarifs et les prestations des chambres et des services. Également, celle qui permet de vérifier la disponibilité, ou encore qui enregistre les coordonnées du client et ses données de réservation.
Le Business Analyst peut aussi identifier la fonction permettant de proposer la meilleure offre possible de l’établissement, relativement à l’ensemble des caractéristiques des clients d’une même réservation : par exemple des parents avec leurs enfants de 12 à 14 ans se verraient proposer deux chambres communicantes au lieu d’une seule avec des lits d’appoint. On peut rajouter des dizaines d’autres fonctionnalités à ce système de réservation, internes ou externes (liens vers d’autres sites de locations de voiture ou de billets de transport etc).
Ces exigences sont toutes dites « fonctionnelles ».
Les exigences « non fonctionnelles » sont celles qui sont importantes voire critiques aux yeux des utilisateurs et qui assurent le bon fonctionnement du système.
Dans notre exemple, il peut s’agir d’être capable de calculer les disponibilités exactes en temps réel, ou encore de sécuriser l’accès aux données afin d’éviter des réservations simultanées d’une même chambre (notion d’intégrité des données).
Il peut également s’agir de prévoir un niveau de charge, par exemple 100000 utilisateurs simultanés, pour que le système ne se bloque pas, avec par exemple des pages qui ne se chargent pas rapidement ou pire, affichant des messages d’erreur empêchant de finaliser les étapes de réservation.
Les exigences non fonctionnelles 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 100000 utilisateurs simultanément avec un temps de réponse inférieur à 2 secondes par utilisateur.
Les termes génériques et subjectifs sont à proscrire ou à définir clairement. Par exemple, les termes « ergonomique », « qualitatif », « de niveau acceptable pour l’utilisateur » ne veulent rien dire s’ils ne sont pas expliqués et quantifiés.
On peut les répartir par catégories, notamment :
- 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…
Malheureusement, dans un projet informatique, les exigences non fonctionnelles ne sont pas systématiquement identifiées, et cela peut causer de sérieux problèmes lors de la mise en production, en situation réelle. Au mieux ces défauts sont-ils corrigés lors des tests d’intégration et des tests fonctionnels, si les tests sont automatisés et que les scenarii ont été bien pensés. Au pire, ces exigences non fonctionnelles non décrites rendent la solution inutilisable, temporairement ou définitivement… Je vous laisse imaginer les conséquences qu’elles peuvent avoir sur l’organisation cliente, et les effets de bords inévitables qu’elles créent.
Ne les négligez donc pas !
| ♥ Et pour recevoir gratuitement le template des Exigences Non Fonctionnelles, cliquez ici : Templates gratuits |
Vous avez aimé cet article? Partagez-le et suivez-moi sur les réseaux sociaux!
