6 Étapes pour écrire un document SRS qui fonctionne + Modèle
Les documents de spécification logicielle sont parfois considérés comme des artefacts qui n’ont de sens que pour les développeurs. Cependant, un document SRS peut aller plus loin et devenir un guide pour les spécialistes du marketing, les parties prenantes, les équipes de conception et même les utilisateurs.
Cet article explique pourquoi la documentation logicielle est importante et comment rédiger votre document SRS pour en faire un guide pratique pour tous les spécialistes de l’équipe.
Qu’est-ce qu’un document SRS et pourquoi est-ce important?
Un document SRS (software requirement specification) est un artefact qui contient les exigences, les attentes et les normes pour un futur produit. Il peut couvrir des documents texte, des feuilles de calcul, des schémas, des précédents et d’autres éléments qui clarifient la vision du produit. En d’autres termes, un document SRS fournit une description détaillée du fonctionnement d’un produit et de la manière dont l’équipe de développement de produit doit le mettre en œuvre.
Imaginez-le comme construire un navire. Vous avez une vision du mât ou de la voile, et vous pouvez même imaginer comment il se déplace à travers les vagues. Cependant, vous avez besoin de détails plus stricts pour mettre le navire sur l’eau.
Il en va de même pour le développement de produits. Vous pouvez avoir une vision claire d’une application que vous souhaitez créer avec toutes les fonctionnalités, éléments de conception et boutons. Cependant, une description verbale des fonctionnalités ne suffit pas aux développeurs pour mettre en œuvre l’idée.
Pour que le résultat corresponde à l’image dans votre tête, vous devez expliquer sur papier exactement comment une fonctionnalité doit fonctionner. Un document SRS est un excellent instrument pour décrire de tels détails techniques.
.jpg)
Qui écrit un document SRS ?
Rédiger un document SRS signifie transférer des descriptions génériques de fonctionnalités, de tâches et d’objectifs vers le plan détaillé de leur mise en œuvre technique.
Les documents SRS sont généralement rédigés par des chefs de produit et de projet ou des analystes commerciaux, qui communiquent directement avec les clients ou qui font des recherches sur les utilisateurs (qui travaillent également sur des wireframes et savent comment le produit doit se comporter) et recueillent les exigences des futurs produits.
Pendant ce temps, ce document. Un bon document SRS n’est pas uniquement technique, car il couvre également les objectifs commerciaux, les métriques, les problèmes des utilisateurs, les personnalités des utilisateurs, etc.
3 Raisons pour lesquelles un document SRS est important
Ainsi, la valeur globale d’un document SRS est claire. Voici les raisons pour lesquelles les documents de spécification des exigences logicielles sont essentiels:
SRS est un Point de communication
En tant que document vivant, un document SRS sert de plate-forme de communication entre tous les spécialistes: développeurs, spécialistes du marketing et cofondateurs.
En expliquant les détails dans un document SRS, de manière formelle ou informelle, les gestionnaires s’entendent avec les clients sur les attentes en matière de résultats. En attendant, si les modifications sont apportées aux exigences, un client et / ou un product owner peut les vérifier et les valider dans le document. Et les développeurs sont responsables de répondre à ces attentes.
Description finale des fonctionnalités
SRS documente les versions finales du logiciel issues des hypothèses discutées avec les clients auparavant. Lors des réunions et des appels, des tests utilisateurs et des entretiens, les versions des produits peuvent changer très souvent. Parfois, même les chefs de produits peuvent être dépassés par les itérations de produits existantes. Le fichier SRS permet d’unifier toutes ces exigences en une seule norme et d’éliminer toute confusion concernant les exigences du produit.
SRS est un guide standard pour les développeurs de produits
En plus de décrire les exigences du produit, le document SRS guide l’équipe de développement sur les étapes à suivre pour créer un produit souhaité par un client.
Selon l’organisation du projet, les développeurs peuvent ou non être impliqués dans la partie analytique du projet. Dans les deux cas, ils doivent conclure comment le système doit fonctionner, définir les exigences et les paramètres de code qui lui conviennent.
De même, les professionnels de l’assurance qualité doivent comprendre tous les aspects techniques qui se cachent derrière le concept du produit. Ainsi, la documentation SRS sert de norme pour la planification et l’exécution des tests d’assurance qualité.
Enfin, les concepteurs obtiennent des informations sur le projet via des documents SRS pour faire correspondre la conception au cas d’utilisation.
6 Étapes à suivre pour rédiger un Bon document SRS
Les exigences fonctionnelles et non fonctionnelles occupent une grande partie de tout document SRS. Les chefs de produits ne prennent pas simplement ces exigences de nulle part. Ils sont le résultat de communications précises avec les clients et de recherches approfondies sur les utilisateurs et les techniques. Voici les principales étapes de la rédaction d’une excellente documentation SRS:
Étape 1. Communication avec une partie prenante
Nous éliminons la première couche d’incertitude en interrogeant les parties prenantes sur leurs attentes vis-à-vis du produit. Bien sûr, une telle interview donne juste un peu de compréhension des exigences. Cependant, cela reste un excellent point de départ pour la recherche.
Chez Uptech, nous discutons d’abord avec le client lors de l’appel de pré-vente et de lancement lorsque nous essayons de déterminer si nous nous adaptons les uns aux autres. Nous essayons de cristalliser les moindres détails sur le client pour comprendre son idée.
Pourtant, une simple communication ne donne pas suffisamment d’informations sur le public cible du produit et ses désirs et besoins. Nous continuons donc avec l’étape de découverte pour que ce soit clair.
Étape 2. Étape de découverte
L’étape de découverte est essentielle à la rédaction de la documentation SRS. À ce stade, nous avons l’occasion d’explorer le problème que le produit devrait résoudre, les intérêts et les besoins. Notre objectif ici est d’identifier les problèmes des utilisateurs et de définir des hypothèses de solutions possibles pour y faire face. Avec une telle approche, nous pouvons rendre l’application précieuse pour l’utilisateur.
Cas d’utilisation vs Histoires d’utilisateurs
Toutes les données utilisateur font partie d’un document SRS en tant que Cas d’utilisation et Histoires d’utilisateurs. La différence entre ces deux catégories est largement débattue au sein de la communauté du développement de produits.
En termes simples, les histoires d’utilisateurs sont davantage axées sur le résultat et les avantages qu’un utilisateur obtient lors de l’utilisation d’une fonctionnalité. Alors que les cas d’utilisation décrivent de manière plus granulaire la fonction elle-même.
Par exemple, après plusieurs entretiens avec les utilisateurs du projet Yaza, nous avons conclu que l’application devrait avoir une discussion. Ainsi, l’histoire de l’utilisateur pour un tel cas ressemblerait à: « En tant qu’utilisateur, je veux discuter avec un propriétaire de maison potentiel. »
Pendant ce temps, le cas d’utilisation de cette histoire décrirait chaque étape d’un utilisateur pour atteindre cet objectif – « En tant qu’utilisateur, je dois ajouter un contact dans ma liste de discussion et lui envoyer un message, de sorte que that ».
Étape 3. Construire la structure
Une fois la découverte terminée, nous continuons à écrire la documentation SRS. Premièrement, nous avons besoin d’une brève structure du document. Le contenu d’un document SRS peut varier considérablement, mais la structure de documentation SRS typique ressemblerait à ceci:
1. Introduction
L’introduction présente un résumé du contenu du document. Il est censé répondre aux questions suivantes:
- Brève description du contenu du document;
- Les lecteurs prévus de ce document;
- L’idée du logiciel que vous développez;
- Les lecteurs prévus.
1.1 Objectifs commerciaux
Configurez une liste d’objectifs que vous souhaitez atteindre sur le projet, comme la création d’un MVP, la création d’une application mobile multiplateforme ou le lancement d’un site Web.
En outre, cette section doit refléter les objectifs et les mesures de réussite de votre entreprise. Bien que certains puissent exclure cette partie du document, il est essentiel d’indiquer ces éléments, car ils influencent directement la recherche et le développement.
1.3 Utilisation prévue
Comment imaginez-vous qu’une personne utilisera votre produit? Quelles sont les fonctions que vous fournissez pour ce type d’utilisation? Décrivez toutes les façons possibles dont une personne peut utiliser votre produit quel que soit le rôle d’utilisateur qu’elle joue.
1.4 Portée
Cette partie décrira la portée du travail que vous devez effectuer pour donner vie à votre idée.
1.5 Définitions et acronymes
Celui-ci exposera les définitions des termes que vous utilisez dans le document pour assurer une compréhension complète par les utilisateurs.
2. Description globale
Voici la partie où vous expliquez l’idée de l’application, d’où elle vient et pourquoi elle peut être intéressante pour les utilisateurs.
2.1 Besoins de l’utilisateur
Un logiciel conçu pour tout le monde ne sert personne. Mais si vous savez exactement qui est votre public cible, où ils travaillent et leurs difficultés, vous aurez plus de chances de proposer une application largement adoptée par les utilisateurs.
3. Caractéristiques et exigences du système
Il est maintenant temps de décrire les exigences techniques de votre futur logiciel. Décrivez les caractéristiques que votre produit inclura, ainsi que les normes qui définissent la qualité de ces produits.
3.1 Exigences fonctionnelles
Les exigences fonctionnelles sont des spécifications système, sans lesquelles le logiciel ne fonctionnera pas correctement. La définition que vous donnerez aux fonctionnalités de votre logiciel déterminera comment elles seront mises en œuvre.
3.2 Exigences non fonctionnelles
Alors que les exigences fonctionnelles définissent ce que sera la fonction du système, les exigences non fonctionnelles déterminent comment le système mettra en œuvre ces fonctionnalités, par exemple la vitesse d’achèvement.
3.3 Pile technique
Une pile technique est un pool de solutions techniques utilisées pour créer et exécuter un logiciel ou un projet. Il est essentiel de l’indiquer dans le document SRS car il définit tous les autres détails techniques.
.jpg)
Étape 4. Faites une description générale
Avant de plonger dans les détails de votre produit, donnez un aperçu général des principales fonctionnalités de l’application. Expliquez simplement le but de votre application, ses fonctionnalités et comment elles résolvent le problème de l’utilisateur.
Étape 5. Définir les exigences fonctionnelles et non fonctionnelles
Le cœur de votre document SRS sera généralement constitué des exigences fonctionnelles et non fonctionnelles du produit. Avec de telles spécifications, vous ajoutez plus de détails à l’aperçu général et guidez ainsi l’équipe à travers les spécificités techniques de votre application.
La différence entre les exigences fonctionnelles et non fonctionnelles est un autre point d’achoppement dans la communauté du développement de produits. Nous avons partagé notre expertise sur ce sujet dans cet article.
Étape 6. Assurez-vous que l’Approbation du Client Sur la Même page
est une partie très attendue du développement. Cependant, les modifications du client peuvent parfois annuler la totalité du travail, terminé à un certain moment du projet.
Pour éviter la pression, nous recommandons d’accepter de petites parties de la documentation SRS complétée, plutôt que de soumettre tout un ensemble de documents à la fois. Cela aide à résoudre certains problèmes rapidement et est moins gênant.
Conseils d’experts sur la Rédaction d’une Excellente Documentation SRS
Il faut du temps pour perfectionner les compétences de rédaction d’une excellente documentation SRS. Nous avons tiré de notre expérience une liste de conseils d’experts sur la rédaction de la documentation SRS. Voici donc quelques informations qui rendront votre documentation SRS efficace:
Faites simple
Ce n’est pas un secret, mais des choses simples gouvernent le monde. Cela est certainement vrai pour tout type de documentation sur laquelle vous travaillez. Votre SRS est une description unifiée du futur produit pour toute votre équipe. Cela signifie que le langage, la structure et les formulations de votre document SRS doivent être aussi laconiques que possible.
Inclure les objectifs commerciaux
Bien qu’un document SRS se concentre principalement sur les caractéristiques techniques, y compris les objectifs commerciaux est une bonne pratique. Un document SRS est une instruction pour l’équipe de développement et le résumé du produit pour les spécialistes non techniques liés au produit. De plus, en incluant les exigences métier, comme les métriques et les objectifs, votre SRS deviendra un instrument unifié pour toute l’équipe.
Ajouter des données utilisateur
L’étape de découverte dévoile généralement les informations les plus précieuses sur un utilisateur. L’ajout de ces informations au document SRS en fera un document utile pour l’équipe de conception et de développement.
Traitez votre SRS comme un document vivant
Le document SRS ne doit pas être statique, même si vous avez compilé tous les packages nécessaires à votre projet. Dans les écosystèmes agiles, les projets acquièrent de nouvelles fonctionnalités à chaque itération. Toutes ces modifications et modifications doivent être transmises dans le document SRS et convenues avec le client.
Conclusion
La rédaction de documents SRS nécessite des recherches, des analyses et des efforts approfondis. Cependant, un document SRS complet qui couvre les caractéristiques de l’entreprise, les détails techniques et les données des utilisateurs sera payant avec un produit époustouflant qui répond aux attentes des clients et des utilisateurs.
Uptech a cinq ans d’expérience dans la création de produits pour des startups florissantes. Nous savons explorer les besoins de l’utilisateur et faire du document SRS un instrument de gestion de projet efficace plutôt qu’une pile de papiers recouverts de poussière.
F. A. Q.
Qu’est-ce que le SRS ?
Un SRS est un document couvrant une description détaillée des spécifications techniques et des exigences d’une application ou d’un logiciel. Un SRS indique également aux développeurs comment mettre en œuvre l’idée du produit pour répondre aux attentes du client.
Quel est le but d’un document SRS?
Le but d’un document SRS est de donner une description technique des caractéristiques d’un produit, de fournir des exigences techniques et non techniques et de guider l’équipe de développement sur la mise en œuvre.
Qui écrit Les documents SRS ?
Selon la composition de l’équipe, les documents SRS sont généralement rédigés par:
- Chef de produit;
- Chef de projet;
- Analyste d’affaires;
- Ingénieur technique.