Sommaire....................................................................................................................................................

1
Introduction.................................................................................................................................................2
I. Capture des Exigences et production d’un SRD..................................................................................3
1. Définition et Rôle d’un SRD..........................................................................................................3
2. Techniques de collecte des exigences............................................................................................3
3. Structure d’un SRD : exigences fonctionnelles, exigences non fonctionnelles, contrainte.......3
a. Exigences fonctionnelles............................................................................................................3
b. Exigences non fonctionnelles.....................................................................................................4
c. Contraintes.................................................................................................................................5
II. Expression des exigences avec des Uses Cases et des User Stories.....................................................6
1. Uses Cases......................................................................................................................................6
2. User Stories....................................................................................................................................7
3. Comparaison Uses Cases et User Stories.....................................................................................8
4. Quand utiliser les Uses Cases et les User Stories.....................................................................8
III. Techniques de classification et priorisation des exigences...................................................................10
1. Présentation de la méthode de priorisation Moscow.................................................................10
2. Modèle de Kano : La Priorisation de Satisfaction (Valeur Client)...........................................11
3. Méthode des points pondérés......................................................................................................11
4. Gestion des dépendances et des risques......................................................................................11
5. Organisation des exigences en sprints........................................................................................12
6. Gestion des dépendances.............................................................................................................12
Conclusion.................................................................................................................................................13

sommaire

Dans le domaine des réseaux et services distribués, la gestion des exigences est
aspect important pour mener à bien un projet. L’objectif sera alors de capturer, classifier et
prioriser les exigences à travers des techniques de documentation pour la conception des
logiciels. Une mauvaise gestion de ces exigences peut entrainer des dépassements de budget, des
retards voire même un produit final qui ne répond pas aux attentes et besoins de l’utilisateur.
Comment l’application rigoureuse des principes d’ingénierie des exigences peut-elle garantir la
qualité et le succès d’un projet logiciel ? Nous répondrons à cette question à travers ce projet en
parcourant les concepts clés tels que le SRD, les Uses Cases, les User Stories et les techniques de
priorisation.

introduction

• Définition et Rôle d’un SRD

Le SRD (Software Requirements Document) est un document formel qui décrit les exigences
fonctionnelles et non fonctionnelles d’un système logiciel. Il sert de référence pour la conception, les
développeurs, les testeurs et les utilisateurs pour garantir que le système répond aux besoins et aux
attentes.

II. Expression des exigences avec des Uses Cases et des User Stories

• Techniques de collecte des exigences

• Entretiens : discussions avec les utilisateurs et parties prenantes pour comprendre les
besoins et leurs attentes.
• Brainstorming : séances de travail en groupe pour générer des idées et des solutions.
• Observation : analyse des utilisateurs dans leur environnement de travail pour
comprendre leurs besoins et leurs comportements.
• Questionnaire et sondages : collecter des informations auprès d’un large public.
• Prototypage : créer des modèles pour clarifier les besoins.
• Structure d’un SRD : exigences fonctionnelles, exigences non
fonctionnelles, contrainte

Exemple d’un système de gestion de réservation de billets pour une agence :

• Exigences fonctionnelles
Elles décrivent ce que le système doit faire pour répondre directement aux besoins de
l'utilisateur et de l'entreprise. Dans notre exemple nous avons les cas suivants avec chacun ses
propres exigences :
 • Gestion des Utilisateurs et de l'Accès
• Le système doit permettre à un nouvel utilisateur de créer un compte et de se connecter
via une adresse e-mail et un mot de passe.
• Le système doit permettre aux utilisateurs de réinitialiser leur mot de passe via un lien
sécurisé envoyé par e-mail.
• Le système doit permettre à l'administrateur de gérer (ajouter, modifier, supprimer) les
comptes d'agents et de définir leurs niveaux d'autorisation.
• Recherche et Disponibilité
• Le système doit permettre à l'utilisateur de rechercher des billets en spécifiant l'origine,
la destination, les dates de départ/retour et le nombre de passagers.
• Le système doit afficher en temps réel la disponibilité et les prix des trajets
correspondants.
• Le système doit permettre de filtrer et de trier les résultats selon des critères (prix,
durée, compagnie, heure).

• Réservation et Paiement
• Le système doit permettre à l'utilisateur de sélectionner un trajet et de saisir les
informations détaillées des passagers.
• Le système doit permettre de calculer et d'afficher le prix total incluant les taxes et les
frais de service avant la confirmation finale.
• Le système doit s'interfacer avec des prestataires de paiement externes (cartes de
crédit, PayPal, etc.) pour finaliser la transaction.
• Le système doit générer un numéro de réservation unique et un billet électronique
après confirmation du paiement.

• Gestion Post-Réservation et Administration

• Le système doit envoyer une confirmation par e-mail contenant le récapitulatif du
voyage et le billet électronique.
• Le système doit permettre à l'utilisateur (ou à l'administrateur) de consulter, modifier
ou annuler une réservation selon les conditions tarifaires.
• Le système doit permettre à l'administrateur de générer des rapports sur les ventes, les
annulations et l'inventaire des sièges.

• Exigences non fonctionnelles

Elles décrivent comment le système fonctionne et définissent les critères de qualité. Elles
sont souvent cruciales pour la satisfaction client et la fiabilité.
• Performance
• (Temps de Réponse) : Le temps de réponse pour l'affichage des résultats de recherche
ne doit pas dépasser 3 secondes, même lors des pics d'affluence.
• (Capacité) : Le système doit pouvoir gérer un minimum de 500 réservations
simultanées sans dégradation notable de la performance.
• (Latence) : Le temps de latence entre la soumission du paiement et l'obtention du
statut de la transaction ne doit pas excéder 1 seconde.

• Sécurité
• (Confidentialité) : Toutes les informations de paiement doivent être transmises via un
protocole chiffré (SSL/TLS) et stockées en conformité avec la norme PCI DSS.
• (Authentification) : Le système doit exiger une authentification multi-facteur (MFA)
pour tous les comptes administrateurs.
• (Autorisation) : Seuls les utilisateurs connectés doivent pouvoir accéder à leurs
propres informations de réservation.

• Fiabilité et Disponibilité
• (Disponibilité) : Le système doit être disponible 99,9% du temps (ce qui équivaut à un
temps d'arrêt maximal d'environ 8,7 heures par an).
• (Tolérance aux Pannes) : En cas d'échec du serveur de paiement principal, le système
doit basculer automatiquement vers un serveur de secours sans interruption de service.
• (Intégrité) : Le système doit garantir que toute transaction réussie (paiement validé)
enregistre correctement le siège et génère le billet.

• Maintenabilité et Portabilité
• (Maintenabilité) : L'architecture du logiciel doit être modulaire pour permettre l'ajout
d'une nouvelle compagnie aérienne ou d'un nouveau moyen de paiement sans affecter
les fonctionnalités existantes.
• (Portabilité) : L'interface utilisateur doit être compatible et offrir une expérience
optimale sur les navigateurs Web majeurs (Chrome, Firefox, Safari) et sur les appareils
mobiles.
• (Évolutivité) : Le système doit être capable de doubler son volume de données
(nombre de vols et de réservations) sur une période de deux ans avec un effort de
maintenance minimal.
 • Contraintes
Elles décrivent les limites que le système doit respecter telles les contraintes de cout et les
contraintes techniques, légales ou organisationnelles.

III. Techniques de classification et priorisation des exigences

• Uses Cases
Ils décrivent les interactions entre les acteurs et le système. Le format UML (Unified
Modeling Language) regroupe les concepts de :
• Acteurs : représentant les utilisateurs ou systèmes externes. Ils sont symbolisés pars
une petite figure humaine.
• Cas d’utilisation : représentant les fonctionnalités ou actions réalisées avec le
système. Symbolisés par des ovales.
• Le système : représenté par un rectangle qui entoure le cas d’utilisation. Montre les
limites de ce que le système gère.
• Relations : lignes qui relient les acteurs aux cas d’utilisation pour montrer les
interactions.
Les scénarios ici seront représentés par des fonctions effectuées par l’utilisateur ; nous
aurons :
• Scénario nominal : déroulement idéal.
• Scénario alternatif : variantes du scénario nominal.
• Scénario d’exception : gestion des erreurs.
La figure ci-dessus montre le diagramme UML de notre système de réservation de billets :
Titre du cas d’utilisation : Rechercher un vol
Acteur principal : Utilisateur enregistré
Scénario nominal :
• L’utilisateur se connecte à son compte
• L’utilisateur recherche un vol
• L’utilisateur sélectionne son vol dans les vols disponibles
• L’utilisateur clique sur « rechercher »
• Le système enregistre le vol et affiche un message de confirmation
Scénarios alternatifs :
• Le vol n’est pas disponible : le système propose de réserver plus tard
• L’utilisateur n’a pas assez de fond dans son compte : le système affiche un message
d’erreur
Scénario d’exception :
• Le système est hors ligne : un message d’erreur est affiché et l’utilisateur est invité à
réessayer plus tard

Figure 1: Diagramme UML de reservation de Billet

• User Stories
Elles décrivent l’exigence du point de vue de l’utilisateur et son bénéfice. Elles se
concentrent sur :
• Qui utilise le système
• Quoi il veut accomplir
• Pourquoi cela est important
Leur structure est la suivante: As a [type of user], I want [action], so that [benefit].
User Story :
En tant qu’utilisateur enregistré, je veux me connecter à mon compte afin de gérer mes
informations et accéder aux services.
Critères d’acceptation :
• L’utilisateur doit pouvoir se connecter avec un identifiant et un mot de passe valides.
• Le système doit afficher un message d’erreur en cas d’identifiants incorrects.
• L’utilisateur doit pouvoir réinitialiser son mot de passe en cas d’oubli.
Scénarios :
Scénario 1 : Authentification réussie.
Scénario 2 : Erreur d’authentification.
Scénario 3 : Réinitialisation du mot de passe.

• Comparaison Uses Cases et User Stories

Le tableau suivant relate les différences entre les Uses Cases et les User Stories :
Aspect Uses Cases User Stories
 Objectif Décrire les interactions Capturer les besoins de
détaillées entre l’utilisateur et le l’utilisateur de manière concise
système et centrée sur la valeur
Structure Inclut les scénarios, diagramme Format simple et textuel :
UML As a [type of user], I want
[action], so that [benefit].
Niveau de detail Très détaillé, avec des scénarios Minimaliste, se concentre sur
nominaux, alternatifs, et l’essentiel.
d’exception.
Orientation Orienté système Orienté utilisateur
Avantages Analyse exhaustive, utile Simple, compréhensible par
pour une documentation tous, flexible.
formelle.
Inconvénients Complexe et lourd pour les Manque de détails
projets agiles. techniques.

• Quand utiliser les Uses Cases et les User Stories

• Quand utiliser les Use Cases ?

Projets complexes : Pour capturer les exigences détaillées dans des systèmes avec de
nombreuses fonctionnalités.
Analyse fonctionnelle : Lorsque vous devez définir les processus métier de manière formelle.
Contexte technique : Lorsque les développeurs ou analystes ont besoin de comprendre le
workflow exact.
• Quand utiliser les User Stories ?
Projets agiles : Idéal pour travailler par itérations et ajuster rapidement les priorités.
Collaboration avec les parties prenantes : Lorsqu’il est important de garder le langage simple
et compréhensible pour tous.
Focus sur la valeur métier : Lorsque vous cherchez à répondre à ”Pourquoi cette fonctionnalité
est-elle importante ?

Cette étape transforme la liste des exigences en une feuille de route concrète, allouant
les ressources aux éléments les plus critiques.
 • Présentation de la méthode de priorisation Moscow

Le MoSCoW est l'outil le plus utilisé pour classer les exigences selon leur importance
pour le lancement du système. La signification de chaque lettre, « o » étant pour pouvoir lire, est
la suivante :
Must have (M) : Essentiel. Le système ne fonctionne pas sans (Ex : Recherche de vols,
Paiement sécurisé).
Should have (S) : Important, mais contournable pour le MVP (Ex : Sélection du siège, Alertes
de retard).
Could have (C) : Souhaitable, apportant un plus si le temps le permet (Ex : Historique des
recherches).
Won’t have (W) : Reporté à une version ultérieure (Ex : Programme de fidélité complexe).
Le tableau suivant montre MoSCoW appliquée à notre système :
Application au Système de Réservation de
Catégorie Définition & Règle Billets
Sans cela, le système est Recherche de Vols (EF), Processus de
Must have Indispensable. Paiement Sécurisé (EF/ENF), Confirmation
inopérant ou illégal. de Réservation (EF).
Important. Apporte une valeur Sélection du Siège (EF), Envoi d'une alerte
Should significative, mais peut être contourné ou par SMS en cas de retard (EF).
have reporté si le temps manque.
Could Souhaitable. Ajoute du confort (la "cerise Historique des recherches sauvegardé,
have sur le gâteau"). Suggestion de vols similaires moins chers.
Reporté. Exclu de cette version pour se Intégration d'un programme de fidélité
Won’t complexe, Abonnement à une newsletter
have concentrer sur l'essentiel. personnalisée.

• Modèle de Kano : La Priorisation de Satisfaction (Valeur Client)

Le Modèle de Kano permet de classer les exigences selon leur potentiel à générer de la
satisfaction chez l'utilisateur du système de réservation. Le tableau suivant montre Kano
appliquée à notre système :
Application au Système de Réservation de
Catégorie Impact sur la Satisfaction Billets
Base leur absence génère une Le
Leur présence est neutre, mais système ne doit pas planter lors du
Exigences de paiement. L'affichage du prix doit inclure
(Must-be) insatisfaction majeure. toutes les taxes (ENF Transparence).
Exigences de Plus la performance est La vitesse de chargement de la page de
Performance (One- élevée, plus la satisfaction est résultats de recherche (ENF Performance).
Dimensional) grande (relation linéaire). Un grand choix de filtres (EF).
attendues, leur présence Une interface de carte interactive 3D pour
Exigences Attrayantes Non choisir le siège, un système de
génère de l'enchantement et recommandation
(Excitement) de destinations basé sur la
un facteur de différenciation. météo (ENF/EF différenciateurs).
 • Méthode des points pondérés
Cette méthode est utilisée pour prendre des décisions objectives en calculant un score de
priorité basé sur l'évaluation des parties prenantes. Le tableau suivant montre la méthode des
points pondérés appliquée à notre système :
Étape Action Application au Système de Réservation
1. Définir Sélectionner les facteurs Valeur : Revenu Potentiel (50%), Urgence Métier
les Critères d'évaluation. (30%), Alignement Stratégique (20%).
2. Définir Sélectionner les facteurs de Coût : Complexité Technique (60%), Temps de
les Coûts difficulté. Développement (40%).
Attribuer une note (ex. : 1 à 5) à Exigence "Paiement en X4 sans frais" : Note haute
3. Noter et chaque exigence pour chaque en Valeur (car augmente les ventes), mais note haute
Calculer critère, puis calculer le ratio en Coût (car implique l'intégration d'une nouvelle API
final. bancaire).
Classer les exigences par ordre On priorise les exigences qui ont un fort impact sur le
4. Décision décroissant du ratio Valeur / revenu pour un coût de développement modéré
Coût. (Exemple : "Alerte de baisse de prix").

• Gestion des dépendances et des risques

La priorité doit aussi prendre en compte :

Dépendances : Une exigence ("Payer un billet") dépend d'une autre ("Calculer le prix total").
L'ordre de réalisation est imposé.
Risques : Les fonctionnalités techniquement complexes (intégration d'API externes) peuvent
être traitées plus tôt, même si leur priorité client est moyenne, pour valider la faisabilité
technique.

• Organisation des exigences en sprints

La priorisation MoSCoW alimente le Product Backlog. L'équipe sélectionne les exigences les
plus prioritaires pour le Sprint (itération courte de travail). Exemple Sprint 1 (MVP) : Focus sur
les Must have (Authentification, Recherche de base, Paiement de base). Dans le cadre Agile, les
exigences sont organisées en sprints pour une livraison incrémentale.

• Gestion des dépendances

Certaines exigences nécessitent la réalisation d’autres exigences on parlera de
dépendances techniques. Pour adapter les priorités en fonction des contraintes du système ;
nous effectuerons des ajustements de priorités. Un exemple de matrice de dépendances adaptée à
notre système est la suivante :
Exigences Dépendances
• Réservation de billet • Création des comptes utilisateurs
• Système de de réservation • Réservation de billet
• Section des avis et recommandations •
 conclusion

Le succès du Système de Réservation de Billets repose sur la conversion d'une idée en un

SRD précis, d'une modélisation partagée (UC/US) et d'une priorisation efficace (MoSCoW).
L'application rigoureuse de l'Ingénierie des Exigences est la garantie principale de la Qualité et
du Succès d'un projet, car elle permet de prévenir les défauts au moment où le coût de correction
est le plus faible. L'IE reste la pierre angulaire du génie logiciel, même face aux systèmes
complexes (IA, DevOps), car la nécessité de définir clairement les objectifs et les contraintes de
qualité ne fait qu'augmente