#Étiquette du produit
Une spécification des exigences logicielles (SRS) décrit comment un système logiciel doit être développé. En termes simples, un SRS fournit à toutes les personnes impliquées une feuille de route pour ce projet.
Il offre des définitions de haute qualité pour les spécifications fonctionnelles et non fonctionnelles du logiciel, et peut également inclure des cas d’utilisation qui illustrent comment un utilisateur interagirait avec le système une fois terminé.,
Remarque: Laissez-nous vous aider à écrire une spécification logicielle requise. Demandez un appel auprès de notre CTO en remplissant ce formulaire.
Table des matières
Pourquoi un document SRS est-il important?
Supposons que vous souhaitiez créer une application de chat avec une apparence et des fonctionnalités spécifiques et que vous souhaitiez qu’elle soit spécifiquement destinée aux entreprises. Vous pensez que vous pouvez supprimer les fonctionnalités supplémentaires que les applications de chat commerciales utilisent pour attirer le public et se concentrer sur les fonctionnalités dont les entreprises ont besoin. Mais vous n’êtes pas un développeur.,
Vous devez donc externaliser le développement de l’application. Mais vous devez également vous assurer que celui que vous embauchez pour transformer votre idée en réalité sait exactement ce que vous essayez d’accomplir. Sans tous les détails pour terminer l’application, le temps et le coût peuvent rapidement devenir incontrôlables. Les développeurs peuvent prendre un mauvais virage et doivent refactoriser le code si le produit fini ne correspond pas à l’image que vous aviez dans votre tête.
Un document SRS vous oblige à mettre l’idée sur papier pour couvrir tous ces détails. Vous devez traduire cette idée dans un langage que les développeurs comprennent., Un document SRS décrit ce qu’un client veut et ce que les développeurs fourniront. C’est l’accord écrit sur chaque détail de l’application.
Avoir un ensemble clair d’exigences garantit qu’une équipe de développement crée des logiciels qui répondent aux besoins des clients. Un SRS aidera à estimer le coût des travaux et à couvrir la portée du projet. Il donne également aux codeurs une idée de la pile technologique dont ils auront besoin et les aide à planifier leur travail, mais ce n’est pas tout:
- Les concepteurs obtiennent des informations sur le projet grâce aux documents SRS afin qu’ils puissent faire correspondre la conception au cas d’utilisation.,
- Les testeurs obtiennent les directives pour créer des cas de test qui correspondent aux besoins de l’entreprise.
- Les utilisateurs finaux utilisent le SRS pour comprendre le logiciel.
- Il fournit aux investisseurs un aperçu des caractéristiques du système afin qu’ils puissent prendre des décisions d’investissement.
Un SRS est important car il est une source unique d’informations et d’attentes, ce qui évite les malentendus entre les chefs de projet, les développeurs, les concepteurs et les testeurs.
Qu’est-SRS Inclure?,
Un SRS doit avoir suffisamment d’informations pour que les développeurs puissent compléter le logiciel décrit. Il expose non seulement la description du logiciel en cours de développement, mais aussi le but qu’il servira: ce que le logiciel est censé faire et comment il devrait effectuer.,du logiciel ou ce qu’il est censé faire
La différence entre les exigences fonctionnelles et Non fonctionnelles
Les exigences fonctionnelles sont les objectifs du nouveau système que vous concevez., Ils décrivent le système et comment il fonctionnera pour aider avec les tâches d’un utilisateur. Ils définissent la façon dont le système réagira à l’entrée de l’utilisateur et ont des détails sur les calculs, la saisie de données et les processus métier. Vous pouvez considérer les exigences fonctionnelles une description détaillée des fonctionnalités de l’application et des besoins de l’utilisateur. Sans répondre aux exigences fonctionnelles, le système ne fonctionnera pas.
Alors que les exigences fonctionnelles spécifient ce que fait un système, les exigences non fonctionnelles décrivent comment le système le fera. Les exigences non fonctionnelles n’affectent pas la fonctionnalité de l’application., Même sans répondre aux exigences non fonctionnelles, le système effectuera les tâches souhaitées.
Les exigences non fonctionnelles sont également importantes car elles définissent les caractéristiques générales qui affectent l’expérience utilisateur. Au lieu de se concentrer sur les besoins des utilisateurs, ils se concentrent sur les attentes des utilisateurs et couvrent des sujets tels que les performances, la sécurité, la fiabilité, la disponibilité et la convivialité.,
Comment écrire un document de Spécification des exigences logicielles
Il est préférable d’organiser le processus que vous utilisez pour écrire un document SRS en commençant par un squelette et des informations générales sur le logiciel que vous développez, et en terminant en ajoutant des détails pour étoffer votre brouillon. Voici six étapes impliquées dans la création d’un document SRS:
Obtenir le Document de spécification des exigences logicielles
Nous avons aidé plus de 200 entreprises à créer leurs produits logiciels. Embauchez notre analyste d’affaires avec 6 ans d’expertise pour rédiger un SRS pour vous.,
Demande SRS
Créer un Contour
La première étape dans le processus est de créer un plan pour votre SRS. Vous pouvez le créer vous-même ou utiliser un modèle SRS existant comme point de départ. Voici un exemple de base d’un plan SRS:
Télécharger l’ebook
- Introduction
- Objet
- Public cible
- l’Utilisation Prévue
- Portée
- Définitions
- Description Générale
- les Besoins de l’Utilisateur
- Hypothèses et Dépendances
- Les Fonctionnalités du système et les Exigences de
- Exigences Fonctionnelles
- Interface Externe Exigences
- les Fonctionnalités du Système
- les Exigences Non-fonctionnelles
Définir la Fin
une Fois que vous avez un plan, vous devez chair il., Commencez par définir le but du produit dans l’introduction de votre SRS. Ici, vous décrirez le public visé et comment il utilisera le produit. Voici comment vous devez structurer l’objectif:
- Définir la portée du produit
- Décrire la valeur qu’il délivrera
- Montrer qui utilisera le logiciel
- Détailler comment il aidera avec le travail des utilisateurs visés
Donner un aperçu
Après avoir défini l’objectif du produit, résumez comment il fonctionnera., Vous trouverez ici une description générale des fonctionnalités du logiciel et de la manière dont elles répondent aux besoins de l’utilisateur.
Vous décrirez également les hypothèses que vous faites sur la fonctionnalité du produit et tout ce dont il dépend dans l’écosystème technologique actuel.
Décrivez les exigences fonctionnelles et non fonctionnelles
Maintenant que vous avez écrit les informations générales, il est temps d’être plus précis. Remplir votre aperçu avant de travailler sur les exigences fonctionnelles et non fonctionnelles vous donne une référence pour vous assurer de répondre aux besoins de base de l’utilisateur pendant que vous remplissez les détails.,
Cette description détaillée des exigences du système est l’élément le plus essentiel d’un document SRS. Décrivez les exigences fonctionnelles de manière suffisamment détaillée pour que les développeurs puissent se mettre au travail et les exigences non fonctionnelles telles que les spécifications de sécurité et les performances.
Voici où vous ajoutez des cas d’utilisation pour décrire clairement comment un utilisateur interagira avec votre système. C’est là que les objectifs de votre projet sont détaillés et mesureront l’avancement du projet pendant le développement.,
Ajouter des détails supplémentaires
La dernière étape de la création du brouillon de votre document SRS consiste à ajouter tous les détails qui pourraient aider les développeurs à terminer le travail sous forme d’annexes, de glossaires de termes et de références.
Obtenir l’approbation
Une fois que vous avez ajouté suffisamment de détails au SRS pour décrire ce que le système est censé faire, il est temps que les parties prenantes approuvent le document.
Vous devrez très probablement faire une présentation aux personnes impliquées dans le processus de développement., Ils peuvent demander des changements, et vous devrez mettre à jour le document SRS en fonction des commentaires des intervenants avant l’approbation finale.
C’est un bon signe. Cela signifie que les développeurs et les parties prenantes rendent le document plus précis, de sorte que le projet est moins comme sortir de la piste.
Comment écrire des cas d’utilisation de logiciels dans un SRS
Un cas d’utilisation décrit comment un utilisateur interagira avec le système. Il décrira le produit du point de vue de l’utilisateur final dans un format d’histoire simple. L’écriture de cas d’utilisation vous oblige à réfléchir à ce que les utilisateurs feront avec le logiciel et à la façon dont il réagira., C’est la visualisation réelle des exigences fonctionnelles.
Voici les étapes que vous pouvez suivre pour écrire un cas d’utilisation:
- Décrivez votre produit aux utilisateurs finaux.
- Concentrez-vous sur l’un de ces utilisateurs.
- Décomposez les interactions de cet utilisateur en cas d’utilisation. Chaque interaction est un cas d’utilisation.
- Décrire la séquence des événements pour chaque cas d’utilisation.
- Écrivez une description détaillée des actions de l’utilisateur et de la manière dont le système doit réagir.
- Développez chaque cas d’utilisation avec d’autres actions utilisateur et réponses système.
- Répétez 1-6 pour chaque type d’utilisateur final.,
Quelles sont les caractéristiques d’un grand SRS?
Il y a des caractéristiques spécifiques que chaque SRS devrait avoir. En examinant cette liste et en la comparant à votre SRS, vous pouvez vous assurer qu’elle sera un document utile pour toutes les parties prenantes.
Explicite
Un document SRS doit être facile à comprendre. Rien ne doit être vague, il n’y a donc pas de malentendus entre les parties prenantes.,
Mesurable
Les exigences de votre document SRS doivent être mesurables, de sorte que le produit fini peut être validé et vérifié par rapport aux spécifications.
Complete
Un document SRS doit contenir suffisamment d’informations pour permettre à votre équipe de développement de terminer le produit et aux testeurs de valider que le produit répond aux besoins de l’utilisateur sans bogues.
Viable
Les exigences doivent correspondre à la réalité de l’environnement actuel, y compris le budget, le calendrier et la technologie. Ils ne devraient pas dépendre des percées technologiques à venir.,
Flexible
Parce que les choses pourraient changer dans l’environnement de travail, votre document SRS devrait être suffisamment flexible pour permettre des mises à jour. N’ajoutez pas d’informations redondantes à plusieurs sections qui doivent être mises à jour à chaque modification.
Vérifiable
Tous les membres de l’équipe de développement doivent avoir accès au document afin de pouvoir le référencer aussi souvent que nécessaire. Les exigences doivent être précises afin que les membres de l’équipe n’aient pas à demander plus de détails. Ils devraient tous être disponibles dans le document SRS.,
Compatible
Les exigences doivent s’adapter les uns aux autres. Une section de votre document d’exigences ne doit pas entrer en conflit avec une autre. Le document doit être formaté de manière cohérente et utiliser la même terminologie tout au long.
Aucune contrainte d’implémentation
Un document SRS doit être suffisamment détaillé pour terminer le travail, mais ne doit pas être trop spécifique, car cela pourrait restreindre le développement. Beaucoup de développement dépend de services tiers sur lesquels les développeurs n’ont aucun contrôle.,
Précis
Les objectifs d’un document d’exigences doivent être précis pour éviter toute confusion. Évitez ce qui suit:
- Échappatoires: « L’application devrait se charger en 3 secondes si cela peut être fait. »
- Ambiguïté : » Le produit MVP doit être publié le plus rapidement possible. »
- Subjectivité: « L’interface utilisateur doit être conviviale. »
- Superlatifs: « Cela devrait être la meilleure application de sa classe.”
- Comparatif: « Cette application devrait être meilleure que Mou., »
Un exemple de Spécification d’exigences logicielles (SRS)
Voici un exemple réduit d’un document SRS pour une application de chat d’entreprise appelée eChat:
Introduction
Ce document détaille le plan de projet pour le développement de » eChat. »
Il est destiné aux développeurs, concepteurs et testeurs travaillant sur” eChat » ainsi qu’aux investisseurs de projets., Ce plan comprendra un résumé des éléments suivants:
- comment le système fonctionnera
- la portée du projet du point de vue du développement
- la technologie utilisée pour développer le projet et
- les mesures utilisées pour déterminer l’avancement du projet
- Description générale
Les entreprises ont besoin d’outils de communication à distance, surtout maintenant que plus de gens travaillent à domicile. Le problème est que la plupart des entreprises finissent par utiliser plusieurs applications pour y parvenir: une pour le chat texte, une pour le chat vidéo et une pour les conférences et les réunions., « eChat » résoudra ce problème en combinant ces fonctionnalités dans une seule application.
Télécharger le livre blanc
Clients
Les clients seront entreprises. Il ne ciblera pas le grand public.
Fonctionnalité
- Les utilisateurs doivent pouvoir s’inscrire avec des comptes LDAP d’entreprise.,
- Les utilisateurs doivent pouvoir créer des groupes de discussion ad hoc comprenant des ensembles d’utilisateurs et envoyer des messages privés à des utilisateurs individuels.
- Les utilisateurs devraient pouvoir avoir des discussions texte qu’ils peuvent diviser en threads.
- L’application devrait être capable de gérer le chat vidéo de groupe d’un maximum de 100 utilisateurs à la fois.
Plateforme
L’application sera développée Réagir Natif pour permettre la création d’une application basée sur le web, iOS l’application mobile, et un mobile Android app.
Ces applications se connecteront à une API REST construite avec .,NET Core pour stocker et récupérer des données à partir d’une base de données MySQL.
L’authentification se fera via les installations LDAP existantes.
Responsabilités de développement
Les développeurs de l’équipe « eChat” seront responsables de l’écriture de tout le code de l’application, du développement de la base de données et de la gestion des versions.,
Classe et caractéristiques des utilisateurs
Il y aura une classe d’utilisateurs appelée admin qui aura les autorisations d’accéder à toutes les fonctionnalités de l’application, y compris:
- Créer des canaux où plusieurs utilisateurs peuvent interagir
- Rendre ces canaux publics à l’ensemble de l’entreprise ou privés pour un groupe de personnes
- Supprimer ces canaux
- Archiver ces canaux
Les utilisateurs standard auront accès à toutes les fonctionnalités de l’application, sauf ceux énumérés ci-dessus.,
Caractéristiques du système
Exigences fonctionnelles
- Les utilisateurs devraient pouvoir créer des groupes de discussion ad hoc comprenant des ensembles d’utilisateurs et envoyer des messages privés à d’autres utilisateurs.
- Les utilisateurs devraient pouvoir avoir des discussions texte qu’ils peuvent diviser en threads.
- Les chats devraient pouvoir être archivés indéfiniment afin que les utilisateurs puissent référencer les chats passés.
- Les utilisateurs devraient pouvoir télécharger des fichiers dans les chats pour référence.
- Interface Externe Exigences
Interfaces Utilisateur
- logiciel Frontal: Réagir Natif
- Back-end du logiciel: .,s systèmes d’exploitation via leur navigateur Web par défaut
- iPhone
- Android
- Exigences non fonctionnelles
Exigences de performance
- L’application doit se charger et être utilisable dans les 3 secondes
- L’application doit mettre à jour l’interface lors de l’interaction dans les 2 secondes
- La base de données doit être normalisée pour éviter les données redondantes et améliorer les performances
- La base de données doit être distribuée pour éviter les pannes
- li>
Exigences de sécurité
- Les bases de données doivent utiliser le sharding pour être redondantes afin d’éviter la perte de données.,
- Les sauvegardes des bases de données doivent être effectuées toutes les heures et conservées pendant une semaine.
Exigences de sécurité
- Toutes les clés utilisées pour l’API REST doivent être stockées en toute sécurité.
- Seule l’API REST devrait pouvoir se connecter aux bases de données.
- Les bases de données doivent être derrière un pare-feu.
Attributs de qualité logicielle
- Disponibilité: Parce que cette application est essentielle à la communication d’entreprise, nous aurons un objectif de quatre neuf(99,99%) disponibilité.,
- Correction: L’application ne doit jamais permettre à quiconque de lire des messages ou des discussions qui ne sont pas destinés à cette personne.
- Maintenabilité: L’application doit utiliser une intégration continue afin que les fonctionnalités et les corrections de bugs puissent être déployées rapidement sans temps d’arrêt.
- Convivialité: L’interface doit être facile à apprendre sans tutoriel et permettre aux utilisateurs d’atteindre leurs objectifs sans erreurs.
Résumé
Un document SRS est une partie nécessaire de la réalisation d’un projet de développement logiciel., C’est la feuille de route qui donne une direction à toutes les personnes impliquées dans le projet, afin que le produit final réponde aux besoins de l’utilisateur.
Sans un document SRS complet en place avant de commencer un projet, il sera difficile de dire quand un projet est terminé et pourrait détourner le développement en créant des fonctionnalités involontaires. Un document SRS vous donne la possibilité d’estimer un projet avec précision et d’assigner des tâches efficacement.
La création d’un document SRS peut être un processus long et méticuleux., Heureusement, l’équipe de Relevant a aidé plus de 200 entreprises à créer des documents SRS et à lancer de nouveaux produits. Nous sommes prêts à vous aider avec votre prochain projet de logiciel, envoyez-nous simplement une ligne.