Dans le développement de logiciels, il est normal de spécifier ce que le logiciel est censé faire. Selon la méthodologie proposée dans ce manuel, la spécification des besoins n’est pas facultative ! La spécification des besoins est la base de la méthodologie de développement.
D’abord, qu’est-ce qu’une exigence ? C’est une condition documentée à laquelle un logiciel (ou un système) doit satisfaire. C’est quelque chose qui facilite la vie d’un utilisateur ou qui amène une valeur socioéconomique.
Voici un exemple d’une exigence d’un système de messagerie instantanée (comme Discord ou Slack) :
Cette fonctionnalité a une utilité évidente : la communication. Il s’agit d’une exigence de fonctionnalité.
Si ces messages doivent être visibles à toutes les personnes dans le canal en moins de 0,5 seconde, alors il s’agit d’une exigence sur la qualité de la performance du système. Lorsqu’il s’agit des qualités d’un système comme la performance, on peut les appeler exigences non fonctionnelles, car elles ne sont pas des fonctionnalités. Il y a beaucoup d’exemples d’exigences non fonctionnelles, par exemple sur Wikipedia . Le nom porte à confusion, car une chose qui ne fonctionne pas est « non fonctionnelle ». Pour cette raison, elles sont aussi appelées des exigences sur les qualités ou sur les contraintes. On peut aussi les appeler informellement les « ilités », car ces qualités sont souvent des aptitudes du système : la maintenabilité, la convivialité, la testabilité, etc.
2.1 FURPS+
FURPS+ est un modèle (avec un acronyme) pour classer les exigences (besoins) d’un logiciel. Voici un résumé de FURPS+ (voir Larman, 2005, sect. 5.4 ) :
- Fonctionnalité (Functionality). Ce sont les exigences exprimées souvent par les cas d’utilisation, par exemple Traiter une vente. La sécurité est aussi considérée dans ce volet.
- Aptitude à l’utilisation (Usability). Convivialité : les facteurs humains du logiciel, par exemple le nombre de clics que ça prend pour réaliser une fonctionnalité, à quel point une interface est facile à comprendre par une personne, etc.
- Fiabilité (Reliability). Comment le logiciel doit se comporter lorsqu’il y a des problèmes ou des pannes. Par exemple, un logiciel de traitement de texte produit un fichier de sauvegarde de secours, ou une application continue à fonctionner même hors connexion (si le réseau Internet est coupé ou désactivé).
- Performance (Performance). Comment un logiciel doit se comporter lors d’une charge importante sur le système. Par exemple, lors de la période d’inscription universitaire, le système doit avoir un temps de réponse de moins de 2 secondes.
- Possibilités de prise en charge (Supportability). Adaptabilité ou maintenabilité : à quel point le logiciel sera facile à modifier face aux changements prévus. Par exemple, lors d’un changement de lois fiscales, quelles caractéristiques de la conception vont faciliter le développement d’une nouvelle version du logiciel.
- « + » : Comprend toutes les autres choses :
- Implémentation. Par exemple, le projet doit être réalisé avec des bibliothèques et des langages qui ne sont pas payants (logiciel libre).
- Interface. Par exemple, les contraintes d’interfaçage avec un système externe.
- Exploitation. Par exemple, l’utilisation d’un système d’intégration continue.
- Aspects juridiques. Par exemple, la licence du logiciel, les politiques de confidentialité et d’utilisation des données personnelles, etc.