La production de l’étape des exigences du processus de développement logiciel est Spécifications des exigences logicielles (SRS) (également appelé un document d'exigences ). Ce rapport jette les bases des activités de génie logiciel et se construit lorsque des exigences complètes sont identifiées et analysées. SRS est un rapport formel, qui agit comme une représentation d'un logiciel permettant aux clients de vérifier s'il (SRS) est conforme à leurs exigences. En outre, il comprend les exigences des utilisateurs pour un système ainsi que des spécifications détaillées des exigences du système.

Le SRS est une spécification pour un produit logiciel, un programme ou un ensemble d'applications spécifique qui exécute des fonctions particulières dans un environnement spécifique. Il sert plusieurs objectifs selon celui qui l’écrit. Premièrement, le SRS pourrait être écrit par le client d'un système. Deuxièmement, le SRS pourrait être rédigé par un développeur du système. Les deux méthodes créent des situations totalement différentes et établissent des objectifs totalement différents pour le document. Le premier cas, SRS, permet de définir les besoins et les attentes des utilisateurs. Le deuxième cas, SRS, est rédigé à diverses fins et sert de document contractuel entre le client et le développeur.

Caractéristiques d’un bon SRS

Voici les caractéristiques d’un bon document SRS :

1. Exactitude : L'examen des utilisateurs est utilisé pour garantir l'exactitude des exigences énoncées dans le SRS. Le SRS est dit parfait s’il couvre tous les besoins réellement attendus du système.

2. exhaustivité : Le SRS est complet si, et seulement si, il comprend les éléments suivants :

(1). Toutes les exigences essentielles, qu'elles concernent la fonctionnalité, les performances, la conception, les contraintes, les attributs ou les interfaces externes.

comment retourner un tableau java

(2). Définition de leurs réponses du logiciel à toutes les classes réalisables de données d'entrée dans toutes les catégories de situations disponibles.

Remarque : Il est essentiel de spécifier les réponses aux valeurs valides et non valides.

(3). Étiquettes complètes et références à toutes les figures, tableaux et diagrammes du SRS et définitions de tous les termes et unités de mesure.

3. Cohérence : La SRS est cohérente si, et seulement si, aucun sous-ensemble d'exigences individuelles n'est décrit dans son conflit. Il existe trois types de conflits possibles dans le SRS :

(1). Les caractéristiques spécifiées des objets du monde réel peuvent entrer en conflit. Par exemple,

(a) Le format d'un rapport de sortie peut être décrit dans une exigence comme étant tabulaire mais dans une autre comme textuel.

(b) Une condition peut stipuler que tous les feux doivent être verts tandis qu'une autre stipule que tous les feux doivent être bleus.

(2). Il peut y avoir un conflit raisonnable ou temporel entre les deux actions spécifiées. Par exemple,

(a) Une exigence peut déterminer que le programme ajoutera deux entrées, et une autre peut déterminer que le programme les multipliera.

(b) Une condition peut stipuler que « A » doit toujours suivre « B », tandis qu'une autre exige que « A et B » coapparaissent.

(3). Deux ou plusieurs exigences peuvent définir le même objet du monde réel mais utiliser des termes différents pour cet objet. Par exemple, la demande d'entrée de l'utilisateur d'un programme peut être appelée une « invite » dans une exigence et un « signal » dans une autre. L’utilisation d’une terminologie et de descriptions standard favorise la cohérence.

4. Sans ambiguïté : Le SRS est sans ambiguïté lorsque chaque exigence fixe n'a qu'une seule interprétation. Cela suggère que chaque élément est interprété de manière unique. Dans le cas où une méthode est utilisée avec plusieurs définitions, le rapport sur les exigences doit déterminer les implications dans le SRS afin qu'il soit clair et simple à comprendre.

5. Classement par importance et stabilité : Le SRS est classé en fonction de son importance et de sa stabilité si chaque exigence qu'il contient comporte un identifiant pour indiquer soit l'importance, soit la stabilité de cette exigence particulière.

Généralement, toutes les exigences n’ont pas la même importance. Certaines conditions préalables peuvent être essentielles, en particulier pour les applications vitales, tandis que d'autres peuvent être souhaitables. Chaque élément doit être identifié pour rendre ces différences claires et explicites. Une autre façon de classer les exigences consiste à distinguer les classes d’éléments comme essentiels, conditionnels et facultatifs.

6. Modifiable : Le SRS doit être rendu aussi modifiable que possible et doit être capable d'obtenir rapidement des modifications dans le système dans une certaine mesure. Les modifications doivent être parfaitement indexées et croisées.

7. Vérifiable : SRS est correct lorsque les exigences spécifiées peuvent être vérifiées avec un système rentable pour vérifier si le logiciel final répond à ces exigences. Les exigences sont vérifiées à l’aide d’avis.

8. Traçabilité : Le SRS est traçable si l'origine de chacune des exigences est claire et si elle facilite le référencement de chaque condition dans la documentation de développement ou d'amélioration future.

Il existe deux types de traçabilité :

sauf

1. Traçabilité en amont : Cela dépend de chaque exigence faisant explicitement référence à sa source dans des documents antérieurs.

2. Traçabilité amont : Cela dépend du fait que chaque élément du SRS ait un nom ou un numéro de référence unique.

La traçabilité amont du SRS est particulièrement cruciale lorsque le produit logiciel entre en phase d'exploitation et de maintenance. Au fur et à mesure que le code et le document de conception sont modifiés, il est nécessaire de pouvoir connaître l'ensemble complet des exigences pouvant être concernées par ces modifications.

9. Indépendance de conception : Il devrait y avoir une option permettant de choisir parmi plusieurs alternatives de conception pour le système final. Plus précisément, le SRS ne doit contenir aucun détail de mise en œuvre.

10. Testabilité : Un SRS doit être rédigé selon une méthode telle qu'il soit simple de générer des cas de test et des plans de test à partir du rapport.

11. Compréhensible par le client : Un utilisateur final peut être un expert dans son domaine explicite mais peut ne pas être formé en informatique. Par conséquent, l’objectif des notations et symboles formels doit être évité autant que possible. Le langage doit rester simple et clair.

les meilleures voitures du monde

12. Le bon niveau d’abstraction : Si le SRS est rédigé pour l’étape des exigences, les détails doivent être expliqués explicitement. Alors que pour une étude de faisabilité, moins d’analyses peuvent être utilisées. Ainsi, le niveau d'abstraction change en fonction de l'objectif du SRS.

Propriétés d'un bon document SRS

Les propriétés essentielles d’un bon document SRS sont les suivantes :

Concis: Le rapport SRS doit être à la fois concis et sans ambiguïté, cohérent et complet. Les descriptions verbeuses et non pertinentes diminuent la lisibilité et augmentent également les risques d'erreur.

Structuré : Il doit être bien structuré. Un document bien structuré est simple à comprendre et à modifier. En pratique, le document SRS subit plusieurs révisions pour répondre aux exigences des utilisateurs. Souvent, les besoins des utilisateurs évoluent au fil du temps. Par conséquent, pour faciliter les modifications du document SRS, il est essentiel de bien structurer le rapport.

Vue boîte noire : Il doit uniquement définir ce que le système doit faire et s'abstenir d'indiquer comment le faire. Cela signifie que le document SRS doit définir le comportement externe du système et ne pas discuter des problèmes de mise en œuvre. Le rapport SRS doit considérer le système à développer comme une boîte noire et doit définir le comportement visible de l'extérieur du système. Pour cette raison, le rapport SRS est également connu sous le nom de spécification boîte noire d'un système.

Intégrité conceptuelle : Il doit faire preuve d'intégrité conceptuelle afin que le lecteur puisse simplement le comprendre. Réponse aux événements indésirables : elle doit caractériser les réponses acceptables aux événements indésirables. C’est ce qu’on appelle la réponse du système à des conditions exceptionnelles.

Vérifiable: Toutes les exigences du système, telles que documentées dans le document SRS, doivent être correctes. Cela signifie qu'il devrait être possible de décider si les exigences ont été satisfaites ou non dans une mise en œuvre.