Spécification des exigences logicielles (SRS) : Conseils et modèles
La communication est la clé du succès dans le développement de logiciels. Selon une étude qui a examiné pourquoi les sociétés de développement de logiciels luttent pour fournir aux clients des solutions logicielles qui répondent à leurs attentes, une mauvaise communication et des exigences imprécises sont parmi les principales raisons de l’échec des projets logiciels.
Des exigences claires et bien communiquées aident les équipes de développement à créer le bon produit, ce qui constitue la base d’un développement de produit réussi. Mais à quoi ressemblent réellement ces exigences et comment devraient-elles être communiquées ? La réponse est simple : avec une spécification des exigences logicielles (SRS).
Qu’est-ce qu’un SRS ?
Un SRS est un document dont le but est de fournir une description complète d’un produit logiciel à développer, y compris son but, les principaux processus métier qui seront pris en charge, les fonctionnalités, les paramètres de performance clés et le comportement. En tant que tel, il sert essentiellement de carte qui guide le processus de développement et maintient tout le monde sur la bonne voie.
Un SRS est généralement signé à la fin de la phase d’ingénierie des exigences, la première phase du processus de développement logiciel. Il contient à la fois des exigences fonctionnelles et non fonctionnelles. Les exigences fonctionnelles décrivent la fonction d’un système logiciel et de ses composantes (comme la pré-réservation de livres lorsqu’on décrit un système de bibliothèque collégiale), tandis que les exigences non fonctionnelles décrivent les caractéristiques de rendement du système logiciel et de ses composantes (comme la sécurité ou la disponibilité du service).
L'IEEE (Institut des ingénieurs électriciens et électroniciens) La spécification 830-1998 de l IEEE (Institute of Electrical and Electronics Engineers) décrit les méthodes et les approches recommandées pour définir un SRS, aidant les clients de logiciels à décrire avec précision ce qu’ils souhaitent obtenir tout en permettant aux fournisseurs de mieux comprendre ce que le client veut exactement.
Avantages de la rédaction d’un document SRS
En plus de fournir la base d’un développement de produit réussi en créant un alignement entre les clients et les fournisseurs et en maintenant tout le monde sur la même longueur d’onde, un SRS offre un certain nombre d’autres avantages qui font qu’il vaut la peine de faire l’effort nécessaire pour le rédiger.
Selon Kurosh Farsimadanun développeur de Rideau, “L’utilisation du SRS peut éliminer et prévenir les erreurs lors de la phase de conception puisque toutes les exigences et fonctions contradictoires qui nécessitent une validation peuvent être corrigées à ce point et que les intervenants peuvent être contactés pour une réévaluation”.
Il est toujours beaucoup moins coûteux d’apporter des changements au début du processus de développement logiciel que plus tard, lorsque des heures innombrables et beaucoup d’énergie et de ressources ont déjà été consacrées. Avoir un SRS bien écrit aide à optimiser le processus de développement en évitant la duplication des tâches et en structurant les problèmes de manière à ce qu’ils puissent être facilement résolus.
Toute autre documentation, tant technique que commerciale, peut être basée sur le SRS pour garantir sa cohérence et sa précision.
Composants d’un SRS
Il n’existe pas deux documents SRS identiques parce que tous les projets logiciels sont différents, certains utilisant le modèle de développement en cascade, d’autres pratiquant le développement agile. Cependant, il est encore possible de distiller les principaux composants d’un SRS et de créer une ébauche de ce à quoi il devrait ressembler :
- Introduction
- Objectif
- Audience
- Utilisation prévue
- Domaine
- Acronymes et définitions
- Description générale
- Besoins de l'utilisateur
- Dépendances et hypothèse
- Exigences et caractéristiques du système
- Exigences fonctionnelles
- Exigences relatives à l’interface externe
- Caractéristiques du système
- Exigences non fonctionnelles
La première section décrit le produit en cours d’élaboration, son but, son public cible, son utilisation prévue et sa portée. La deuxième section fournit plus d’information sur les besoins des utilisateurs et les facteurs qui pourraient éventuellement empêcher les exigences énoncées dans le SRS d’être satisfaites. La dernière grande section est consacrée aux exigences spécifiques, fonctionnelles et non fonctionnelles.
Comment rédiger un bon SRS ?
Un bon SRS doit répondre à plusieurs caractéristiques clés. Ça devrait être:
- Corriger: Il est important de s'assurer que le SRS reflète toujours la fonctionnalité et les spécifications du produit.
- Sans ambiguïté :Il vaut mieux être trop spécifique que ambigu. Le SRS n’est pas un chef-d’œuvre littéraire, de sorte que même les règles stylistiques les plus élémentaires peuvent être ignorées au nom de la clarté.
- ComplétéCe n’est jamais une bonne idée d’omettre une caractéristique demandée par le client.
- Pertinence :Tous les acronymes et définitions devraient être utilisés de façon uniforme dans l’ensemble du SRR.
- Classement selon l’importance et/ou la stabilité : Le temps est souvent une ressource rare pendant le processus de développement, il est donc bon de classer les exigences en fonction de leur importance et de leur stabilité.
- Vérifiable : Il devrait y avoir une méthode de vérification pour chaque exigence.
- Modifiable : Les modifications des exigences devraient être apportées de façon systématique et leur impact sur les autres exigences devrait être pris en considération.
- Traçable Toutes les exigences doivent être traçables dès leur origine.
Comment le logiciel RM peut vous aider à rédiger des documents SRS
Il est tout à fait possible d’écrire un bon document SRS dans Microsoft Word, Google Docs, ou tout autre traitement de texte. Le problème de cette approche est qu’elle peut être atrocement fastidieuse et prendre beaucoup de temps. Le fait est que même des projets de développement de logiciels relativement simples peuvent s’avérer exigeants. Lorsque les exigences changent, les limites des traitements de texte tels que Microsoft Word sont rapidement révélées.
Au lieu de rencontrer des obstacles plus tard dans le processus de développement, il est préférable d’utiliser un outil de gestion des exigences dédié comme Visure dès le début. Un outil dédié de gestion des exigences fournit un support intégral à l’ensemble du processus de gestion des exigences, gérant toutes les informations relatives aux exigences et leurs relations et interactions avec les utilisateurs.
Visure est un excellent exemple d’outil moderne de gestion des exigences parce qu’il est spécialement conçu pour fournir un support intégral à l’ensemble du processus des exigences, y compris la saisie, l’analyse, la spécification, la validation et la vérification des exigences, la traçabilité de, la gestion et la réutilisation. Visure est entièrement personnalisable et s’intègre à de nombreux outils tiers
Conclusion
Tous ceux qui ont travaillé sur un projet de logiciel savent à quelle vitesse les exigences peuvent s’accumuler et à quel point il peut être difficile de les gérer. Une spécification des exigences logicielles fournit une description complète d’un produit logiciel à développer et permet à tous de rester sur la même longueur d’onde. Avec les outils modernes de gestion des exigences, la rédaction d’une spécification d’exigences logicielles ne nécessite pas beaucoup d’efforts, et les avantages sont impossibles à ignorer.
