Définition de la solution

Comment décrire les exigences non fonctionnelles

exigences non fonctionnelles

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 !

Alice Svadchii
Alice Svadchii
Auteure du blog et Business Analyst enthousiaste

>> Cet article vous a plu ? Partagez-le !

>> Et pour en savoir plus sur les techniques, méthodes et bonnes pratiques du Business Analyst, cliquez ici !

4
Poster un Commentaire

avatar
  S’abonner  
plus récent plus ancien Le plus populaire
Notifier de
Stéphane
Invité
Stéphane

Bravo pour cet article Alice ! Les exigences non fonctionnelles (ENF) sont très importantes dans un projet puisque c’est souvent sur cet aspect du système que l’on va mesurer réellement le niveau de satisfaction des utilisateurs. En effet, à quoi sert-il de disposer de fonctionnalités si le système n’est pas performant, n’est pas sécurisé… ? Les ENF sont très difficiles à élucider car d’une part les équipes projet ont toujours tendance à se focaliser uniquement sur le fonctionnel et d’autre part, les ENF sont souvent considérées comme implicites (et donc non documentées). Elles ont également une très forte influence sur… Lire la suite »

Franck
Invité
Franck

Voilà encore un bel exemple de situation contraignante voire catastrophique. J’ai pu constater dans ma vie professionnelle dans différents secteurs que malheureusement les exigences non fonctionnelles sont souvent oubliées ou ignorées alors qu’elles sont le fondement du bon fonctionnement d’un outil. Les exemples les plus courants sont le nombre d’utilisateurs limité à une quantité bien inférieure au besoin réel ou encore le volume de données à traiter mal quantifié qui génère lenteur voire plantage du système. La vision dirigeant ou le concept programmeur sont souvent éloignés de l’exigence de l’utilisateur qui devrait être consulté plus souvent pour son retour d’expérience.… Lire la suite »