Réponse.

SRS est un document structuré décrivant toutes les exigences du système en cours de développement. Sa mission est de traduire au mieux les attentes commerciales dans le langage de l'équipe projet. Sections principales :

1. Introduction (objectifs, domaine d'application, terminologie)
2. Description du produit et contexte commercial
3. Description des utilisateurs et de leurs rôles
4. Exigences fonctionnelles (cas d'utilisation, user stories)
5. Exigences non fonctionnelles (sécurité, performance, convivialité)
6. Contraintes
7. Interfaces
8. Dépendances externes
9. Critères d'acceptation des exigences
10. Glossaire des termes

Caractéristiques clés :

SRS contient à la fois des exigences fonctionnelles et non fonctionnelles.
Les exigences sont formulées de manière claire, avec un minimum d'ambiguïté.
SRS doit obligatoirement refléter les scénarios d'utilisation, les contraintes et les critères de réussite.

Pour contrôler l'exhaustivité et la qualité, l'analyste utilise des listes de vérification de validation, des modèles, les normes IEEE 830 et des validations régulières avec les principales parties prenantes.

Questions pièges.

Est-il suffisant de décrire uniquement les user stories pour une SRS complète ?

Non. Les user stories montrent le côté fonctionnel, mais ne couvrent pas les exigences non fonctionnelles, les contraintes, les interfaces, les scénarios d'exception et les critères d'acceptation.

Peut-on utiliser des termes différents pour la même entité dans le document ?

Non. Il est impératif de maintenir l'uniformité de la terminologie : pour cela, un glossaire des termes est créé et une revue croisée du document est effectuée.

La SRS doit-elle inclure des exigences de sécurité et de performance ?

Oui. Les exigences non fonctionnelles sont critiques : leur absence peut conduire à des dettes techniques ou à l'impossibilité d'exploiter le système.

Erreurs typiques et anti-modèles

Détail insuffisant des exigences, absence d'exemples et de critères d'acceptation.
Utilisation de formulations ambiguës : "rapide", "pratique", "fiable" sans caractéristiques chiffrées.
Ignorer les exigences non fonctionnelles.

Exemple de la vie réelle

Cas négatif

SRS rédigée uniquement sur la base des user stories, les exigences de performance et de sécurité sont oubliées.

Avantages :

Préparation rapide de la documentation.

Inconvénients :

Le projet n'a pas passé l'audit de sécurité, ne supporte pas le nombre nécessaire d'utilisateurs simultanés.

Cas positif

SRS couvre l'ensemble des attributs nécessaires — fonctionnalités, exigences non fonctionnelles, critères d'acceptation, glossaire.