Rédiger une spécification des exigences logicielles, modèle inclus

Commençons par une petite analogie : nous avons tous lu de vieux livres avec ce sentiment de ne pas parler la même langue que les protagonistes de l’histoire. Or, n’en est-il pas de même au bureau lorsque nous devons échanger avec des développeurs en intelligence artificielle férus de technologie ou des analystes SEO mordus du Web ?

Il arrive en effet que la collaboration entre deux services aux antipodes l’un de l’autre soit nécessaire, malgré un langage technique différent. Et si vous avez déjà travaillé dans une équipe interfonctionnelle, vous savez à quel point il est difficile de mettre tout le monde sur la même longueur d’onde.

Les spécifications des exigences logicielles permettent aux chefs de projet, chefs de produit et autres business analysts de décomposer des objectifs commerciaux généraux en tâches que tous les membres de l’équipe pourront accomplir sans peine lors du processus de développement.

Qu’est-ce qu’une spécification des exigences logicielles (SRS) ?

Une spécification des exigences logicielles, ou software requirement specification document (SRS) en anglais, est un document qui rassemble l’ensemble des exigences, attentes, conceptions et normes pour un projet futur. Sont comprises les exigences commerciales à grande échelle qui dictent l’objectif du projet, les exigences et besoins des utilisateurs finaux, ainsi que la fonction du produit en termes techniques. En résumé, une SRS apporte une description détaillée du fonctionnement d’un produit logiciel et la façon dont votre équipe de développement doit le réaliser.

Imaginons que vous avez une bonne idée d’application. Vous savez ce que vous voulez en ce qui concerne ses fonctionnalités et son apparence, mais il faudra bien plus qu’une simple description verbale pour qu’un développeur sache comment s’y prendre pour lui donner vie. C’est là que la spécification des exigences logicielles entre en jeu.

Pourquoi utiliser une spécification des exigences logicielles ?

Sans instructions claires lors de la création d’un nouveau produit, vos développeurs risquent de perdre du temps, et vous finirez sans doute par dépenser plus que prévu pour atteindre le résultat souhaité.

La rédaction d’une spécification des exigences logicielles est l’occasion de mettre vos idées à l’écrit et de dresser une liste claire de vos exigences. Ce document sera l’unique source de référence de votre produit, pour que toutes vos équipes, du marketing à la maintenance, soient sur la même longueur d’onde.

Les spécifications des exigences logicielles sont des documents vivants et servent également de moyen de communication entre toutes les parties prenantes impliquée dans le processus du développement du produit. Les itérations sont inévitables lors de projets de développement logiciel : si les modifications sont bien consignées dans la SRS, tous les acteurs du projet pourront les examiner et les approuver. Les incertitudes liées aux exigences logicielles ne sont plus qu’un mauvais souvenir !

Éléments à inclure dans une spécification des exigences logicielles

Une spécification des exigences logicielles classique est composée de quatre parties : l’introduction, les exigences systèmes et fonctionnelles, les exigences d’interface et les exigences non fonctionnelles.

1. Introduction

L’introduction d’une spécification des exigences logicielles est pour le moins classique et consiste en un aperçu global du projet. Lorsque vous la rédigez, il est conseillé de décrire le but du produit, son public cible ainsi que la manière de l’utiliser. Veillez à inclure les éléments suivants :

• Portée du produit : la portée devrait être cohérente avec les objectifs commerciaux à grande échelle du produit. Ceci est d’autant plus primordial si plusieurs équipes ou prestataires ont accès au document. Dans ce cadre, vous dresserez une liste des avantages et des objectifs du produit.

• Valeur du produit : en quoi votre produit est-il si important ? Qu’apportera-t-il à votre public cible ? Quelle sera sa fonction ? Quel problème résoudra-t-il ? Demandez-vous quel intérêt les utilisateurs pourraient y trouver.

• Public cible : décrivez votre public cible. C’est lui qui sera au cœur des décisions liées à l’apparence et la prise en main de votre produit, ainsi qu’à la façon dont vous le présenterez et le vendrez.

• Utilisation prévue : imaginez comment votre public utilisera votre produit. Dressez une liste des fonctionnalités que vous développerez, ainsi que toutes les utilisations qu’il sera possible d’en faire selon le rôle ou la fonction de chacun. Il est également conseillé de recourir à des cas d’utilisation pour illustrer votre point de vue.

• Définitions et acronymes : chaque secteur d’activité a son propre jargon et les acronymes qui vont avec. Regroupez les définitions des termes utilisés dans votre spécification des exigences logicielles pour vous assurer que toutes les parties comprennent vos propos.

• Table des matières : le plus souvent, une spécification des exigences logicielles complète sera longue. Incluez une table des matières pour que chacun puisse y trouver précisément ce qu’il cherche.

Votre introduction doit être la plus claire et la plus concise possible. Gardez à l’esprit qu’elle sera votre fil conducteur pour le reste de votre spécification des exigences logicielles, il est donc souhaitable que le document ne laisse pas de place à l’interprétation.

2. Exigences systèmes et fonctionnelles

Une fois l’introduction rédigée, il est temps de rentrer dans le vif du sujet. Les exigences fonctionnelles se composent des fonctions et fonctionnalités systèmes qui permettront à votre système de se comporter comme prévu.

Avec votre introduction comme référence, vérifiez que vos exigences répondent aux besoins fondamentaux des utilisateurs au fur et à mesure que vous les détaillez. Le nombre d’exigences fonctionnelles à inclure dépend de votre produit, et pourrait même se compter en milliers ! Nous vous présentons les plus courantes :

• Règles « If-Then »

• Logique du traitement des données

• Processus systèmes

• Traitement des transactions

• Fonctions administratives

• Exigences réglementaires et conformité

• Exigences de performance

• Détail des opérations menées pour chaque étape

C’est un peu trop pour vous ? Essayez plutôt de vous concentrer sur une exigence à la fois. Le degré de précision de vos exigences conditionnera le nombre de problèmes à régler par la suite ; ne lésinez pas sur les détails !

3. Exigences d’interface externe

Les exigences d’interface externe sont des exigences fonctionnelles qui garantissent la bonne communication du système avec les éléments externes. Par exemple :

• Interfaces utilisateurs : la clé de l’utilisabilité de votre application qui regroupe présentation du contenu, navigation de l’application et assistance utilisateur, entre autres.

• Interfaces matérielles : les caractéristiques de chaque interface qui relie les éléments logiciels et matériels du système, comme les types d’appareils pris en charge et les protocoles de communication.

• Interfaces logicielles : les éléments qui relient votre produit à d’autres éléments logiciels, comme les bases de données, les bibliothèques de ressources et les systèmes d’exploitation.

• Interfaces de communication : les exigences relatives aux fonctions de communication que votre produit utilisera, comme les e-mails ou les formulaires intégrés.

Les systèmes intégrés reposent sur les exigences des interfaces externes. Complétez le tout avec des dispositions d’écran, des fonctions de boutons et une description des dépendances de votre produit aux autres systèmes.

4. Exigences non fonctionnelles (NFR)

La dernière partie de votre spécification des exigences logicielles recouvre les exigences non fonctionnelles ou non-functional requirements (NFR) en anglais. Les exigences fonctionnelles abordées précédemment détaillent ce que le produit est censé faire, tandis que les exigences non fonctionnelles présentent la manière dont votre système mettra en œuvre ces fonctionnalités. Par exemple, votre système imprimera un bordereau d’expédition quand un client commandera votre produit (exigence fonctionnelle) et celui-ci sera imprimé sur des feuilles de papier blanc 10 x 15 cm, la taille standard pour ce genre d’impression (exigence non fonctionnelle).

Votre système ne respecte pas les exigences non fonctionnelles ? Il pourra toujours fonctionner malgré cela, mais les attentes des utilisateurs ou celles des parties prenantes sont susceptibles d’être compromises. Les exigences non fonctionnelles permettent d’encadrer les exigences fonctionnelles pour que certains paramètres ne soient pas exclus, comme le maintien d’un prix d’achat abordable et la facilité d’utilisation du produit.

Voici les « NFR » les plus courantes :

• Sécurité : les éléments pour assurer la protection de toutes les informations sensibles que votre logiciel collecte chez les utilisateurs.

• Capacité : les besoins présents et futurs en stockage de votre produit, accompagnés d’un plan qui indique comment votre système s’adaptera à un nombre de demandes grandissant.

• Compatibilité : les exigences matérielles minimum pour votre logiciel, comme les systèmes d’exploitation et les versions qui peuvent le prendre en charge.

• Fiabilité et disponibilité : la fréquence à laquelle vous prévoyez l’utilisation de votre logiciel, ainsi que la durée de panne lors d’une utilisation normale.

• Évolutivité : les charges maximales que votre système peut supporter tout en fonctionnant normalement.

• Maintenabilité : la façon dont votre application doit utiliser une intégration en continu pour déployer des fonctionnalités rapidement et corriger les bugs.

• Utilisabilité : la facilité d’utilisation du produit.

Parmi les autres types de NFR, nous retrouvons également les exigences de performance, réglementaires et environnementales.

Modèle de document d’exigences logicielles

Prêt à vous lancer dans le développement d’un logiciel ? Notre modèle comprend les quatre éléments clés qui feront de votre spécification des exigences logicielles un document essentiel, apportant des informations pertinentes sur le produit à votre équipe. N’oubliez pas : des exigences détaillées, claires et concises seront le gage d’une vision partagée par tous.

Les bonnes pratiques à adopter pour créer sa spécification des exigences logicielles

Le but d’une spécification des exigences logicielles est d’assurer que toutes les équipes de chaque service travaillent à l’accomplissement d’un objectif clair. Toutefois, il existe de bonnes pratiques à suivre pour que votre SRS remplisse sa mission.

Enrichir votre SRS d’éléments visuels

L’inclusion d’éléments visuels tels que des diagrammes, des schémas et des modèles permettront une meilleure compréhension du processus. Ceux-ci sont particulièrement utiles pour illustrer les fonctions principales et le fonctionnement de votre logiciel.

Essayez d’élaborer une carte heuristique lors d’une séance de brainstorming sur votre projet. Idéale pour organiser idées, fonctionnalités, scénarios et mettre en évidence ce qui relie ces éléments entre eux, elle donnera de la structure à vos pensées au fur et à mesure que vous les rassemblez. Visuellement, la carte n’a pas besoin d’être particulièrement détaillée : la spécification des exigences virtuelles est là pour apporter les informations complémentaires. Focalisez-vous plutôt sur les fonctions principales de votre logiciel et leur corrélation.

Rester clair et concis

S’il y a bien une chose que personne ne souhaite, c’est que vos développeurs soient pris de doute en plein travail sur votre produit. Ne laissez aucune place à l’ambiguïté pour éviter que les membres de l’équipe ne prennent des libertés en cas d’imprécision. Donnez autant de détails que possible dans la description de vos exigences logicielles et ne commettez pas les erreurs suivantes :

• Utiliser des mots comme généralement ou approximativement

• Combiner des termes avec un « / », qui pourrait être interprété par « et » ou « ou »

• Utiliser des valeurs limites compliquées

• Utiliser des négations doubles ou triples

La relecture de la SRS par un pair est un excellent moyen de repérer d’éventuelles ambiguïtés. Discutez-en plus longuement avec chaque participant pour connaître sa compréhension des exigences et effectuer les modifications nécessaires.

Tenir compte de l’utilisateur final

Ajoutez vos recherches sur le terrain et entretiens avec les utilisateurs à votre SRS pour consolider la compréhension des exigences, des attentes et des besoins de vos utilisateurs finaux. Cela vous aidera à mieux visualiser les opérations que ces derniers pourraient effectuer avec le logiciel. Anticipez tous les scénarios possibles en insistant sur leur caractère hypothétique avant de les inclure dans votre spécification des exigences logicielles. Retenez bien que vos développeurs travailleront à partir des données disponibles dans le document, ni plus ni moins.

Prévoir une marge de flexibilité

Votre SRS est un document vivant : des nouvelles fonctionnalités et des modifications seront ajoutées à chaque itération. Prenez compte de cette réalité en prévoyant une certaine flexibilité pour vos exigences au cas où vous n’obtiendriez pas le résultat escompté. Il est également conseillé de conserver un historique des modifications apportées au document pour éviter tout malentendu. L’ensemble des participants devrait être en mesure de remonter à la source de chaque exigence et de connaître l’auteur, la date et la raison des modifications.

Clarifiez votre vision avec un document de spécifications des exigences logicielles

La rédaction d’une spécification des exigences logicielles n’est pas une mince affaire, tout comme la résolution des problèmes qui ne connaît pas de fin ou la gestion des désaccords au sein de votre équipe. Tous les efforts que vous aurez investis dans l’élaboration de votre spécification des exigences de votre logiciel résulteront en un produit exceptionnel qui fera votre fierté, ainsi que celle de vos parties prenantes.