Des besoins clairs aident les équipes de développement à créer le bon produit. Et une spécification des exigences logicielles (SRS) vous aide à poser les bases du développement du produit.
Nous définirons ce que c’est, quand vous en utiliserez un et cinq étapes pour rédiger un document SRS.
D’un coup d’œil, voici comment rédiger un document d’exigences :
- Définir l’objectif de votre produit.
- Décrire ce que vous construisez.
- Détailler les exigences.
- Faites-le approuver.
Qu’est-ce qu’un document de spécification des exigences logicielles (SRS)?
Une spécification des exigences logicielles (SRS) est un document qui décrit ce que le logiciel fera et comment il devra fonctionner. Il décrit également les fonctionnalités dont le produit a besoin pour répondre aux besoins de toutes les parties prenantes (entreprises, utilisateurs).
Un SRS typique comprend :
- Un objectif
- Une description globale
- Des exigences spécifiques
Les meilleurs documents SRS définissent comment le logiciel interagira lorsqu’il sera intégré au matériel – ou lorsqu’il sera connecté à d’autres logiciels. Les bons documents SRS tiennent également compte des utilisateurs de la vie réelle.
Pourquoi utiliser un document SRS ?
Une spécification des besoins logiciels constitue la base de l’ensemble de votre projet. Elle pose le cadre que chaque équipe impliquée dans le développement suivra.
Il est utilisé pour fournir des informations critiques à plusieurs équipes – développement, assurance qualité, opérations et maintenance. Cela permet de garder tout le monde sur la même page.
L’utilisation du SRS permet de s’assurer que les exigences sont satisfaites. Et il peut également vous aider à prendre des décisions concernant le cycle de vie de votre produit – par exemple, quand retirer une fonctionnalité.
La rédaction d’un SRS peut également minimiser le temps et les coûts de développement globaux. Les équipes de développement embarquées bénéficient tout particulièrement de l’utilisation d’un SRS.
Spécification des exigences logicielles par rapport à la spécification des exigences système
Une spécification des exigences logicielles (SRS) comprend des descriptions approfondies du logiciel qui sera développé.
Une spécification des exigences du système (SyRS) rassemble des informations sur les exigences d’un système.
« Logiciel » et « système » sont parfois utilisés de manière interchangeable comme SRS. Mais, une spécification des exigences du logiciel fournit plus de détails qu’une spécification des exigences du système.
>> Vous avez besoin de prouver votre conformité ? Voici comment créer une matrice de traçabilité >>
Comment rédiger un document SRS
Rédiger un document SRS est important. Mais ce n’est pas toujours facile à faire.
Voici cinq étapes que vous pouvez suivre pour rédiger un document SRS efficace.
Créer un plan (ou utiliser un modèle SRS)
Votre première étape consiste à créer un plan pour votre spécification des besoins logiciels. Il peut s’agir de quelque chose que vous créez vous-même. Ou vous pouvez utiliser un modèle SRS existant.
Si vous le créez vous-même, voici à quoi pourrait ressembler votre plan :
1. Introduction
1.1 Objectif
1.2 Public visé
1.3 Utilisation prévue
1.4 Champ d’application
1.5 Définitions et acronymes
2. Description générale
2.1 Besoins des utilisateurs
2.2 Hypothèses et dépendances
3. Caractéristiques et exigences du système
3.1 Exigences fonctionnelles
3.2 Exigences d’interface externe
3.3 Caractéristiques du système
3.4 Exigences non fonctionnelles
Une fois que vous avez votre schéma de base, vous êtes prêt à commencer à le remplir.
Téléchargez un livre blanc sur les meilleures pratiques de rédaction des exigences >>
Débutez par un objectif
L’introduction de votre SRS est très importante. Elle définit les attentes à l’égard du produit que vous construisez.
Donc, commencez par définir l’objectif de votre produit.
Public cible et utilisation prévue
Définissez qui, dans votre organisation, aura accès au SRS – et comment ils doivent l’utiliser. Il peut s’agir de développeurs, de testeurs et de chefs de projet. Il pourrait également s’agir de parties prenantes d’autres départements, notamment les équipes de direction, les ventes et le marketing.
Portée du produit
Décrire le logiciel en cours de spécification. Et inclure les avantages, les objectifs et les buts. Cela doit être lié aux objectifs généraux de l’entreprise, en particulier si des équipes extérieures au développement auront accès au SRS.
Définitions et acronymes
Il est judicieux d’inclure une définition des risques. Éviter le risque est en tête des préoccupations de nombreux développeurs – en particulier ceux qui travaillent dans des équipes de développement critiques pour la sécurité.
Voici un exemple. Si vous créez un dispositif médical, le risque pourrait être que le dispositif tombe en panne et provoque un décès.
En définissant ce risque dès le départ, il est plus facile de déterminer les exigences spécifiques dont vous aurez besoin pour l’atténuer.
>> Besoin de créer un PRD ? Voici un mode d’emploi avec des exemples >>
Donner un aperçu de ce que vous allez construire
Votre prochaine étape consiste à donner une description de ce que vous allez construire. S’agit-il d’une mise à jour d’un produit existant ? S’agit-il d’un nouveau produit ? Est-ce un ajout à un produit que vous avez déjà créé ?
Il est important de décrire ces éléments dès le départ, afin que tout le monde sache ce que vous construisez.
Vous devez également décrire pourquoi vous le construisez et à qui il s’adresse.
Besoins des utilisateurs
Les besoins des utilisateurs – ou classes et caractéristiques des utilisateurs – sont essentiels. Vous devrez définir qui va utiliser le produit et comment.
Vous aurez des utilisateurs principaux et secondaires qui utiliseront le produit de manière régulière. Vous devrez peut-être aussi définir les besoins d’un acheteur distinct du produit (qui peut ne pas être un utilisateur primaire/secondaire). Et, par exemple, si vous construisez un dispositif médical, vous devrez décrire les besoins du patient.
Hypothèses et dépendances
Il pourrait y avoir des facteurs qui ont un impact sur votre capacité à remplir les exigences décrites dans votre SRS. Quels sont ces facteurs ?
Y a-t-il des hypothèses que vous faites avec le SRS qui pourraient s’avérer fausses ? Vous devriez également les inclure ici.
Enfin, vous devriez noter si votre projet dépend de facteurs externes. Cela peut inclure des composants logiciels que vous réutilisez à partir d’un autre projet.
Détailler vos exigences spécifiques
La section suivante est essentielle pour votre équipe de développement. C’est ici que vous détaillez les exigences spécifiques pour la construction de votre produit.
Exigences fonctionnelles
Les exigences fonctionnelles sont essentielles à la construction de votre produit.
Si vous développez un dispositif médical, ces exigences peuvent inclure la perfusion et la batterie. Et au sein de ces exigences fonctionnelles, vous pouvez avoir un sous-ensemble de risques et d’exigences.
Exigences d’interface externe
Les exigences d’interface externe sont des types d’exigences fonctionnelles. Elles sont importantes pour les systèmes embarqués. Et elles décrivent comment votre produit s’interfacera avec d’autres composants.
Il existe plusieurs types d’interfaces pour lesquelles vous pouvez avoir des exigences, notamment :
- Utilisateur
- Matériel
- Logiciel
- Communications
Fonctionnalités du système
Les fonctionnalités du système sont des types d’exigences fonctionnelles. Ce sont des caractéristiques qui sont nécessaires pour qu’un système fonctionne.
Autres exigences non fonctionnelles
Les exigences non fonctionnelles peuvent être tout aussi importantes que les exigences fonctionnelles.
Ils comprennent :
- Performance
- Sécurité
- Qualité
L’importance de ce type d’exigences peut varier en fonction de votre secteur d’activité. Les exigences de sécurité, par exemple, seront critiques dans l’industrie des dispositifs médicaux.
L’IEEE fournit également des conseils pour la rédaction des spécifications des exigences logicielles, si vous êtes membre.
Obtenir l’approbation du SRS
Une fois que vous avez terminé le SRS, vous devrez le faire approuver par les principales parties prenantes. Et tout le monde devrait revoir la dernière version du document.
Rédiger un SRS dans Microsoft Word par rapport à un logiciel d’exigences
Vous pouvez rédiger votre spécification des exigences logicielles dans Microsoft Word. Une façon intelligente de le faire est de créer un modèle de SRS que vous pouvez utiliser comme point de départ pour chaque projet.
Cependant, même avec un modèle, écrire un SRS de cette façon peut être un processus laborieux. Et si une exigence change, votre SRS peut facilement tomber en désuétude. De plus, il peut y avoir des problèmes de versionnement avec les documents d’exigences sous Word.
Vous pouvez gagner du temps – et garantir la précision – en rédigeant plutôt un SRS dans Helix ALM.
Pourquoi Helix ALM est meilleur…
Helix ALM (qui est livré avec un outil de gestion des exigences dédié) ajoute de l’efficacité à travers tout votre processus de gestion des exigences.
En créant un SRS dans Helix ALM, vous assurerez une source unique de vérité sur votre SRS. Il sera plus facile de faire des revues d’exigences de votre SRS. Et cela vous aidera à obtenir des approbations plus rapides – pour que vos développeurs puissent commencer.
Une fois que vous avez des exigences dans un SRS, vous pouvez facilement les gérer tout au long de votre processus de développement.
Si vous rédigez également un PRD, vous pouvez lier ces exigences de fonctionnalité à l’exigence de haut niveau dans le SRS. Cela crée une traçabilité à travers votre processus d’exigences.
Vous pouvez également lier les exigences de votre SRS à des tests. Cela vous aidera à vous assurer que le produit que vous livrez remplit l’objectif et les exigences de votre SRS.
Voyez par vous-même à quel point il peut être facile d’écrire un SRS. Essayez gratuitement Helix ALM – et voyez comment un SRS efficace améliorera votre processus de développement. Vous pouvez également regarder notre démo pour voir plus de fonctionnalités.
Gagnez du temps en écrivant un SRS dans Helix ALM ▶️ regardez la démo First