REPUBLIQUE DU CAMEROUN REPUBLIC OF CAMEROON

Paix – Travail – Patrie Peace – Work – Fatherland

***************************** ************************

UNIVERSITE DE DSCHANG UNIVERSITY OF DSCHANG

Scholae Thesaurus Dschangensis Ibi Cordum Scholae Thesaurus Dschangensis Ibi Cordum
********************************** ********************************
FACULTE DES SCIENCES FACULTY OF SCIENCES
COMPLEXITE
********************* ET
*********************
Département de Mathématiques Mathematics and Computer

Informatique Science Department

MASTER 1 MASTER’S 1
Email : recrorat@[Link] Email: recrorat@[Link]
Site Web: [Link] Website: [Link]

THEME 2:
Ingénierie des Exigences et Conception des Logiciels

N° NOM (S) & PRENOM (S) MATRICULE

1 DOUNTIO TCHIOFO David Duclair CM-UDS-21SCI1047
2 KAFACK WAMBA Kerol CM-UDS-21SCI0547
3 NJIKAM koupit Samira Fallone CM-UDS-19SCI0088
4 PEUHTAO GNEBE Tchinchacké CM-UDS-24SCI0763
5 ANON-KOYANE Moïse CM-UDS-24SCI0898
6 FOUELEFACK Kelie Syntia CM-UDS-20SCI0322
7 YUMKAM SIMO Elvira Audrey /
8 NGO KANDA SABINE Francine Alexandrie CM-UDS-22SCI1176
9 NONA FOGHAP Constantin CM-UDS-21SCI0195
10 MOYALBAYE Abdallah CM-UDS-24SCI0867
11 TCHATCHOUANG FEZZE Steve Anicet CM-UDS-19SCI1226
12 DOUKA PAHIMI Ouanbi /
13 DJIMRA Telro CM-UDS-19SCI0303
14 ATABONG Willy CM-UDS-20SCI1882
15 AVOMO TESSA romael wilson CM-UDS-21SCI1445
16 AKWUGEH VUGHOSE Blatsius /
17 AJAMAH MEZENZO Lovette /

Supervisé par : Dr Zekeng Ndadji Milliam Maxime

Année académique : 2024/2025

Ingénierie des Exigences et Conception des
Logiciels

Mentoré par Mme Nguedia Daniella

22 décembre 2024

2
Table des matières

Introduction 4

1 Software Requirement Document (SRD) 5

1.1 Définition, Rôle et Structure . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Définition du SRD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Objectifs principaux du SRD . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Contenu typique d’un SRD . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Techniques de Collecte des Exigences 6

2.1 L’entretien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Le brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Questionnaire et sondage . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Le prototypage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Reverse Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Use Cases et User Stories 9

3.1 Cas d’utilisation, acteurs, associations . . . . . . . . . . . . . . . . . . . . 9
3.2 Description textuelle d’un cas d’utilisation . . . . . . . . . . . . . . . . . 10
3.3 User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 Comparaison : Cas d’utilisation vs User Stories . . . . . . . . . . . . . . 13

4 Gestion des Dépendances entre Exigences et Ajustement des Priorités 13

4.1 Gestion des Dépendances entre Exigences . . . . . . . . . . . . . . . . . . 13
4.1.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.2 Catégories de Dépendances . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Ajustement des Priorités . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1 Techniques de Priorisation . . . . . . . . . . . . . . . . . . . . . . 14
4.2.2 Approches Contextuelles . . . . . . . . . . . . . . . . . . . . . . . 14
4.3 Interaction entre Dépendances et Priorités . . . . . . . . . . . . . . . . . 14
4.4 Collaboration et Adaptabilité . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4.1 Communication entre Équipes . . . . . . . . . . . . . . . . . . . . 14
4.4.2 Gestion des Imprévus . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.5 Cas Pratique : Gestion d’une Bibliothèque en Ligne . . . . . . . . . . . . 15
4.5.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.5.2 Exigences et Dépendances . . . . . . . . . . . . . . . . . . . . . . 15
4.6 Gestion des Imprévus et Ajustements . . . . . . . . . . . . . . . . . . . . 15
4.7 Outils et Approches Utilisés . . . . . . . . . . . . . . . . . . . . . . . . . 16

Conclusion 17

3
Introduction
Dans le domaine en constante évolution du génie logiciel, la réussite d’un projet repose
largement sur une gestion efficace des exigences. Ces dernières représentent les fonde-
ments du système à concevoir, définissant ce que le logiciel doit accomplir et sous quelles
contraintes il doit opérer. Une mauvaise compréhension ou documentation des exigences
peut entraîner des dépassements de budget, des retards, ou encore un produit final qui
ne répond pas aux attentes des parties prenantes.
L’ingénierie des exigences joue un rôle clé dans la structuration de ce processus. Elle
consiste non seulement à capturer et formaliser les besoins des utilisateurs et des clients,
mais aussi à les organiser, les prioriser et les suivre tout au long du cycle de vie du projet.
À cet effet, le Software Requirements Document (SRD) constitue un outil essentiel. Ce
document formalise les exigences fonctionnelles, non fonctionnelles et les contraintes,
servant ainsi de référence pour toutes les phases du développement logiciel.
Par ailleurs, les techniques d’expression des exigences, telles que les Use Cases et les
User Stories, permettent de détailler les besoins sous des formats adaptés aux différents
publics cibles : les équipes techniques et les parties prenantes non techniques. La com-
paraison entre ces deux approches et leur utilisation dans des contextes spécifiques sont
cruciales pour maximiser leur efficacité.
Enfin, la classification et la priorisation des exigences, souvent réalisées à l’aide de mé-
thodologies comme MoSCoW ou Kano, garantissent une allocation efficace des ressources
et une gestion proactive des contraintes. Dans un cadre Agile, ces techniques sont inté-
grées à une gestion itérative et incrémentale, permettant une flexibilité et une réactivité
accrues face aux imprévus.
Ce rapport explore en détail ces concepts, depuis la capture et la documentation des
exigences jusqu’à leur priorisation et leur gestion dans des contextes complexes. À travers
des exemples concrets et des méthodologies éprouvées, il met en lumière les meilleures
pratiques pour assurer la réussite des projets logiciels.

4
1 Software Requirement Document (SRD)
1.1 Définition, Rôle et Structure
1.2 Définition du SRD
Un Software Requirements Document (SRD), ou Document de Spécifications des Exi-
gences Logicielles, est un document formel qui décrit de manière détaillée les exigences
fonctionnelles et non fonctionnelles d’un système logiciel. Il sert de guide tout au long du
cycle de vie du développement logiciel et joue un rôle clé dans la communication entre
les parties prenantes, notamment les clients, les utilisateurs finaux, les développeurs et
les testeurs.

1.3 Objectifs principaux du SRD

— Clarification des attentes : Établir une compréhension commune des fonction-
nalités et des contraintes du logiciel à développer.
— Documentation des exigences : Fournir un enregistrement officiel des exigences
qui peuvent être référencées tout au long du projet.
— Base pour la conception et le développement : Servir de référence pour
les équipes de conception et de développement, garantissant que le produit final
correspond aux besoins spécifiés.
— Facilitation des tests : Aider les testeurs à élaborer des cas de test en fonction
des exigences définies, assurant ainsi la qualité du logiciel.

1.4 Contenu typique d’un SRD

Un SRD est structuré pour inclure différentes catégories d’exigences, chacune ayant
un rôle spécifique. Voici un aperçu des sections clés :

⋆ Contexte : Présentation générale du projet, y compris son but et son importance.

⋆ Objectifs du document : Expliquer pourquoi le SRD est élaboré et comment il
sera utilisé.
⋆ Parties prenantes : Identification des personnes ou groupes concernés par le
projet.
⋆ Portée du projet :
— Description du système : Ce que le système doit accomplir et les limites de son
fonctionnement.
— Objectifs globaux : Résumé des résultats attendus.
⋆ Exigences fonctionnelles : Décrivent ce que le système doit faire, avec des
exemples comme :
— Exigence 1 : "Le système doit permettre aux utilisateurs de créer un compte."
— Exigence 2 : "Le système doit permettre aux utilisateurs de se connecter avec
leurs identifiants."
⋆ Exigences non fonctionnelles :
— Performance : Exigences relatives à la rapidité et à l’efficacité du système.
— Sécurité : Exigences concernant la protection des données et l’accès au système.

5
 — Compatibilité : Exigences sur l’interopérabilité avec d’autres systèmes ou pla-
teformes.
⋆ Contraintes :
— Techniques : Limitations liées à la technologie utilisée.
— Réglementaires : Exigences légales ou normatives.
— Budgétaires : Limites financières.
— Temporelles : Contraintes liées au calendrier de développement.
⋆ Glossaire : Explication des termes techniques ou spécifiques au projet.
⋆ Diagrammes et modèles : Diagrammes de cas d’utilisation, de flux de données,
ou d’architecture.

2 Techniques de Collecte des Exigences

2.1 L’entretien
L’entretien est un échange direct avec la partie prenante (client) pour comprendre
leurs différents besoins, attentes et contraintes. Nous distinguons les entretiens structurés
(questions prédéfinies), les entretiens non structurés (sous forme de discussion libre), et
les entretiens semi-structurés (un mélange d’entretiens structurés et non).
Cette méthode présente plusieurs avantages comme :
— La clarification en temps réel : l’interaction directe permet d’ajuster ou de refor-
muler immédiatement les questions pour obtenir des informations plus précises.
— Identification des exigences implicites : Les émotions, les hésitations ou les priorités
peuvent être identifiées à travers le ton de voix, le langage corporel, etc.
Cette méthode présente aussi des inconvénients qui ne sont pas à négliger :
— Le temps nécessaire élevé.
— Manque de standardisation : Si plusieurs interviewers conduisent les entretiens, les
styles ou approches différents peuvent conduire à des variations dans les données
recueillies.

Exemple de dialogue avec un client :

Client : Bonjour ! Nous souhaitons développer une application pour gérer

notre bibliothèque. Pouvez-vous nous aider avec ça ?
Concepteur : Bonjour ! Bien sûr, je serais ravi de vous aider. Pouvez-vous
m’expliquer brièvement vos besoins ? Quelles fonctionnalités aimeriez-vous
voir dans l’application ?
Client : Nous voulons qu’un utilisateur puisse consulter la liste des livres
disponibles et potentiellement effectuer un emprunt.
Concepteur : Très bien. Est-ce que l’utilisateur doit être authentifié pour
consulter les livres disponibles ?
Client : Oui, seuls les utilisateurs enregistrés auront cet accès.
Concepteur : Quels sont les actions disponibles pour un visiteur non authen-
tifié ?
Client : Le visiteur pourra consulter une vue générale sur les services propo-
sés par l’application, mais pas la liste des livres ni les détails.
Concepteur : Compris. Est-ce que vous souhaitez permettre aux utilisateurs

6
 d’effectuer des emprunts directement via l’application ?
Client : Non, les emprunts se feront physiquement à la bibliothèque.
Concepteur : Bien noté. Est-ce que vous souhaitez inclure des miniatures
pour les livres dans la liste ?
Client : Oui, chaque livre aura une miniature.
Concepteur : Très bien. Quelle sera la taille moyenne d’une miniature ?
Client : Environ 1 Mo par miniature.
Concepteur : Combien de livres l’application contiendra-t-elle initialement ?
Client : Environ 1 000 livres.
Concepteur : D’accord. Le nombre de livres augmentera-t-il au fil du temps ?
Client : Oui, nous ajouterons régulièrement de nouveaux livres.

2.2 Le brainstorming
Le brainstorming est une méthode de recherche qui consiste à réunir un groupe de
personnes pour discuter d’un sujet, chacun apportant sa contribution. Le flux d’idées et
les différents points de vue qui naissent de cette rencontre entre plusieurs esprits différents,
sans filtre ni jugement, peuvent déboucher sur une nouvelle inspiration créative.
Outre le brainstorming “classique”, il existe des variantes qui utilisent d’autres ap-
proches pour générer des idées :
— Questionstorming.
— Brainwriting.
— Le brainstorming imaginaire.
Pour mener à bien une séance de brainstorming, il faut respecter un certain nombre
de règles. Le centre Héraclès (Belgique) propose un moyen simple pour se souvenir de ces
règles avec l’acronyme D.R.E.A.M :
— Délire : Produire des idées folles, farfelues, etc.
— Respect : Interdire de critiquer les idées des autres ou les siennes (positif ou
négatif).
— Écrire : Noter toutes les idées qui sont émises (même par ceux qui parlent moins
fort que les autres).
— Associer : Enchaîner les idées avec celles des autres, ne pas hésiter à rebondir, à
s’inspirer.
— Maximum : Obtenir un maximum d’idées (300 idées en 45 minutes à 10 personnes
est un but atteignable pour une bonne séance de créativité).
Les avantages de cette technique sont :
— Permet d’explorer des idées variées et innovantes.
Comme inconvénients, nous avons :
— La peur des critiques.
— Trop de démocratie.

2.3 Questionnaire et sondage

C’est une méthode structurée utilisée pour collecter des informations auprès d’un
large éventail de parties prenantes dans les projets. Elle repose sur l’utilisation de ques-
tions prédéfinies, distribuées sous forme papier ou numérique, pour recueillir des retours,
identifier des besoins, ou comprendre des préférences.
Les étapes clés de la mise en œuvre de cette technique sont :

7
 — Définition des objectifs : Identifier clairement les informations à collecter (be-
soins fonctionnels, préférences utilisateurs, feedback sur une idée).
— Rédaction des questions : Élaborer des questions précises, claires et non biai-
sées.
— Les questions fermées : Elles favorisent une analyse quantitative (oui/non, choix
multiples, échelles de notation).
— Les questions ouvertes : Elles favorisent l’analyse qualitative ; ici les réponses
sont libres.
— Sélection des participants : Identifier les groupes cibles (utilisateurs finaux,
décideurs, parties prenantes).
— Moyen de diffusion : Choisir le format (en ligne, papier, via des outils comme
Google Forms ou SurveyMonkey).
— Analyse des réponses : Compiler les données, les analyser (statistiques, ten-
dances) et en tirer des conclusions exploitables.
Avantages de cette technique :
— Atteinte d’un large public.
— Coût relativement faible.
— Rapidité de la collecte.
Inconvénients :
— Manque de profondeur.
— Risque de mauvaise interprétation.
— Exclusion numérique : Les questionnaires en ligne peuvent exclure certaines parties
prenantes sans accès à internet ou peu à l’aise avec les outils numériques.

2.4 Le prototypage
C’est une méthode interactive utilisée pour collecter des exigences en développant un
modèle fonctionnel ou visuel qui reflète les principales fonctionnalités ou caractéristiques
d’un système, sans en être une version définitive. L’idée est d’aider les parties prenantes
à clarifier leurs besoins en les confrontant à une représentation tangible du produit.
Il existe plusieurs types de prototypage :
— Le prototypage basse fidélité.
— Le prototypage haute-fidélité.
— Le prototypage évolutif.
— Le prototypage jetable (throwaway).
Pour qu’un prototypage soit efficace, il faut qu’il respecte les étapes suivantes :
— Identification des objectifs : Définir ce que le prototype doit tester (interface,
fonctionnalités, flux de travail).
— Choix du type de prototype.
— Création initiale : Concevoir une version préliminaire avec un outil adapté (cro-
quis, maquette numérique, ou prototype fonctionnel).
— Test utilisateur : Faire interagir les parties prenantes avec le prototype pour
recueillir leurs retours.
— Interaction et amélioration : Affiner le prototype en fonction des retours jus-
qu’à atteindre un consensus sur les exigences.
— Documentation : Capturer les besoins validés pour guider les équipes de déve-
loppement.
Avantages :

8
 — Clarification des exigences implicites.
— Feedback rapide.
— Réduction des coûts de développement : Corriger des erreurs ou ajuster des exi-
gences sur un prototype coûte moins cher que de modifier un produit en cours de
développement.
Inconvénients :
— Risque de confusion.
— Focalisation excessive sur l’apparence.

2.5 Reverse Engineering

La reverse engineering consiste à analyser un produit ou système existant pour iden-
tifier ses caractéristiques techniques et fonctionnelles ; déduire les exigences implicites à
partir de l’observation de son fonctionnement ou de son architecture ; créer une base pour
des améliorations, des modifications ou un remplacement du système existant.
Les étapes de la reverse engineering sont :
— Identification de l’objectif : Déterminer pourquoi le système doit être analysé
(ex. : compréhension, amélioration, migration).
— Collecte initiale d’information : Réunir toute la documentation existante ou
les connaissances des experts sur le système.
— Décomposition du système : Examiner le système ou produit en détail, souvent
en le divisant en sous-composants.
— Modélisation et documentation : Créer des représentations (modèles UML,
diagrammes de processus, etc.) pour formaliser les exigences observées.
— Identification des exigences : Extraire les exigences fonctionnelles et non fonc-
tionnelles en observant ce que le système fait et comment il le fait.
— Validation : Valider les exigences déduites avec les parties prenantes ou experts
pour s’assurer de leur exactitude.
— Mise à jour et intégration : Documenter les exigences et les intégrer dans un
projet d’amélioration ou de remplacement.
Avantages :
— Adaptation à de nouvelles exigences.
— Récupération des exigences perdues.
— Facilite la modernisation.
Inconvénients :
— Difficulté à capturer les exigences implicites.
— Complexité technique.

3 Use Cases et User Stories

3.1 Cas d’utilisation, acteurs, associations
Le diagramme de cas d’utilisation représente le plus simplement possible le système
et ses interactions avec son environnement immédiat. Le système y est décrit, vu de
l’extérieur, comme une boîte noire dont on ne connaît pas les détails d’implémentation.
La dimension technique est laissée de côté dans un premier temps, les documents des cas
d’utilisation formant les spécifications fonctionnelles du système.
On y retrouve :

9
 — Les acteurs : Décrivent les rôles de personnes ou d’autres systèmes qui inter-
agissent directement avec le système, sujet de l’étude. Définir l’ensemble des ac-
teurs permet de définir l’environnement immédiat du système, ce qui est dans le
système et ce qui est à l’extérieur.
— Les cas d’utilisation : Représentent les fonctionnalités “à gros grains” du système
du point de vue des acteurs. Le système est ainsi décomposé en fonctionnalités
sans pour autant tomber dans une décomposition fonctionnelle. Le titre du cas
d’utilisation représente un objectif particulier de l’acteur lors de son utilisation du
système.
— Les associations : Représentent les interactions entre les acteurs et le système
contextualisées par les cas d’utilisation, donc une utilisation du système par un
acteur dans un certain but.

3.2 Description textuelle d’un cas d’utilisation

— Titre du cas d’utilisation : Le titre du cas d’utilisation correspond à l’objectif
de l’acteur principal. Il est exprimé sous forme verbale à l’infinitif.
— Objectif : Résumé permettant de comprendre l’intention principale du cas d’uti-
lisation.
— Acteur principal : Acteur qui est à l’initiative du cas, celui qui réalise le cas
d’utilisation.
— Acteurs secondaires : Acteurs qui reçoivent de l’information ou qui sont utilisés
par le cas d’utilisation.
— Dates de création et mises à jour.
— Responsable.
— Version.
Scénarios :
— Scénario nominal : Déroulement classique, représentatif du cas.
— Scénarios alternatifs : Variantes du cas nominal.
— Scénarios d’exceptions : Survenues d’erreurs, le cas d’utilisation n’est pas at-
teint.
Autres précisions :
— Préconditions : Décrivent l’état dans lequel le système doit être avant le déclen-
chement du cas d’utilisation.
— Postconditions : État du système à la fin des différents scénarios.
— Exigences non fonctionnelles (ou techniques) : Tout ce qui n’entre pas dans
la description des scénarios ou des exigences plus globales.
— Règles de gestion : Description des besoins en termes d’interface graphique.

Exemple :

10
 Figure 1 – Cas d’utilisation d’une bibliothèque en ligne

3.3 User Stories

Les user stories (histoires utilisateur) permettent de décrire les besoins fonctionnels
d’un logiciel à partir de la perspective de l’utilisateur final. Elles se concentrent sur qui
utilise le système, quoi il veut accomplir, et pourquoi cela est important.
Les user stories suivent une structure claire et standardisée :
As a [type of user], I want [action], so that [benefit].
— As a [type of user] : Qui est l’utilisateur (ou l’acteur) concerné ?
Exemple : un client, un administrateur, un visiteur.
— I want [action] : Quelle action ou fonctionnalité l’utilisateur souhaite ?
Exemple : effectuer un paiement, s’inscrire à un service, consulter une liste d’ar-
ticles.
— So that [benefit] : Pourquoi cette action est importante ? Quel est l’objectif ou

11
 le bénéfice attendu ?
Exemple : gagner du temps, accéder rapidement à l’information.

Exemple de User Story pour la connexion :

En tant que utilisateur enregistré,

Je veux pouvoir me connecter à mon compte
Afin de gérer mes informations et accéder aux services.

Critères d’acceptation
— Utilisation d’un identifiant et d’un mot de passe valide.
— Possibilité de réinitialiser le mot de passe en cas d’oubli.

Scénarios
Scénario 1 : Authentification réussie
1. Étant donné qu’un utilisateur visite la page de connexion,
2. Lorsqu’il saisit un identifiant valide (adresse e-mail ou nom d’utilisateur) et un
mot de passe valide,
3. Alors l’utilisateur est redirigé vers la page d’accueil de son compte.
Scénario 2 : Erreur d’authentification
1. Étant donné qu’un utilisateur tente de se connecter avec des identifiants incor-
rects,
2. Lorsqu’il saisit un identifiant ou un mot de passe invalide,
3. Alors un message d’erreur clair est affiché :
Exemple : "Identifiant ou mot de passe incorrect. Veuillez réessayer."
4. Et si le compte est verrouillé ou inactif, un message approprié est affiché :
Exemple : "Votre compte est désactivé. Contactez le support."
5. Et si des champs obligatoires sont vides, un message de validation est affiché :
Exemple : "Veuillez remplir tous les champs requis."

Sécurité
— Les mots de passe doivent être masqués (affichés sous forme de points ou d’asté-
risques).
— Le système doit limiter les tentatives de connexion (par exemple, bloquer tempo-
rairement après 5 tentatives infructueuses).
— Une session sécurisée (HTTPS) doit être utilisée pour toutes les communications.

Récupération de mot de passe

— Un lien "Mot de passe oublié ?" doit être disponible et rediriger l’utilisateur vers
une procédure de réinitialisation de mot de passe.

Expérience utilisateur
— Un bouton "Se connecter" doit être désactivé tant que les champs requis ne sont
pas remplis.
— Une option "Rester connecté" doit être disponible pour permettre à l’utilisateur
de rester connecté (selon les règles de sécurité définies).

12
Compatibilité technique
— La fonctionnalité doit fonctionner sur les principaux navigateurs (Chrome, Firefox,
Safari, Edge) et être adaptée aux appareils mobiles.

Accessibilité
— Les champs et les boutons doivent être accessibles via le clavier et compatibles
avec les lecteurs d’écran.

Tests d’acceptation
1. Cas où l’utilisateur se connecte avec succès.
2. Cas où l’utilisateur entre des identifiants incorrects.
3. Cas où l’utilisateur a oublié son mot de passe.
4. Cas où l’utilisateur tente de se connecter après plusieurs échecs.

3.4 Comparaison : Cas d’utilisation vs User Stories

Aspect Cas d’utilisation User Stories

Objectif Décrire en détail les fonc- Capturer les besoins et at-
tionnalités et interactions tentes des utilisateurs
du système
Structure Inclut des scénarios, dia- Format simple, textuel
grammes UML
Niveau de détail Très détaillé Minimaliste
Orientation Orienté système Orienté utilisateur
Avantages Analyse exhaustive, utile Simple, compréhensible
pour une documentation par tous
formelle
Inconvénients Complexe et lourd pour les Manque de détails tech-
projets agiles niques

4 Gestion des Dépendances entre Exigences et Ajuste-

ment des Priorités
Dans les projets complexes, la maîtrise des interdépendances entre les exigences et
l’adaptation des priorités constituent des leviers essentiels pour garantir le succès tout en
restant flexible face aux contraintes. Ce document explore les meilleures pratiques et les
outils permettant une gestion efficace de ces aspects stratégiques.

4.1 Gestion des Dépendances entre Exigences

4.1.1 Définition
Une dépendance survient lorsqu’une tâche ou une exigence requiert l’accomplissement
préalable d’une autre pour être réalisée.

13
4.1.2 Catégories de Dépendances
Dépendances Séquentielles Chaque tâche repose sur l’achèvement d’une étape pré-
cédente. Exemples d’outils : Diagrammes de Gantt ou PERT pour modéliser les sé-
quences.

Dépendances Techniques Ces dépendances sont liées à des infrastructures ou contraintes

technologiques. Solutions : Tests anticipés et analyses de risques approfondies.

Dépendances Partagées Liées à l’utilisation de ressources communes, ces dépen-

dances sont souvent sources de conflits. Outils recommandés : Microsoft Project ou
Smartsheet pour optimiser la gestion des ressources.

4.2 Ajustement des Priorités

4.2.1 Techniques de Priorisation
Matrice d’Eisenhower Permet de classer les tâches selon leur urgence et leur impor-
tance :
— À exécuter immédiatement.
— À planifier.
— À déléguer.
— À éliminer.

Méthode MoSCoW Classement des exigences par criticité :

— Must : Indispensables.
— Should : Importantes mais non urgentes.
— Could : Optionnelles.
— Won’t : À exclure temporairement.

4.2.2 Approches Contextuelles

— Suivi continu : Des outils comme Kanban ou Gantt permettent d’ajuster les
priorités en temps réel.
— Méthodologies Agiles : Adaptations fréquentes basées sur les retours utilisateurs
ou les besoins émergents.

4.3 Interaction entre Dépendances et Priorités

Une dépendance non résolue peut bloquer la réalisation d’une tâche prioritaire. So-
lutions :
— Diagrammes de PERT ou Gantt pour cartographier les relations entre tâches.
— Matrices de dépendances pour une analyse rapide.

4.4 Collaboration et Adaptabilité

4.4.1 Communication entre Équipes
Actions :

14
 — Réunions régulières pour synchroniser les efforts.
— Utilisation d’outils collaboratifs centralisant les informations clés.

4.4.2 Gestion des Imprévus

— Analyse d’impact : Identification rapide des conséquences d’un retard.
— Plan de contingence : Préparation de solutions alternatives.

4.5 Cas Pratique : Gestion d’une Bibliothèque en Ligne

4.5.1 Contexte
Développement d’une plateforme numérique permettant la consultation, l’emprunt ou
la réservation d’ouvrages, tout en optimisant la gestion des opérations administratives.

4.5.2 Exigences et Dépendances

Gestion des utilisateurs Dépendance : Inscription préalable avant l’accès aux fonc-
tionnalités.
Priorité : Critique, à implémenter en premier.

Catalogue des livres Dépendance : Intégration d’une base de données des ouvrages.
Priorité : Haute, cœur de la plateforme.
Actions : Mise en place d’un système de recherche et de filtres.

Système de réservation et d’emprunt Dépendances : Statuts des utilisateurs et

gestion des stocks.
Priorité : Après le catalogue et les utilisateurs.

Paiement Dépendance : Connexion sécurisée et passerelles de paiement.

Priorité : Moins urgente, à implémenter ultérieurement.

Section des avis et recommandations Dépendance : Création de profils utilisa-

teurs.
Priorité : Fonctionnalité optionnelle, améliore l’expérience utilisateur.

4.6 Gestion des Imprévus et Ajustements

Retard dans l’intégration de la base de données Impact : Bloque le développe-
ment du catalogue.
Solution : Version minimaliste avec base fictive pour tests.

Bug dans le système de réservation Impact : Bloque les réservations/emprunts.

Solution : Équipe dédiée à la correction prioritaire.

15
4.7 Outils et Approches Utilisés
— Diagramme Gantt : Planification des étapes critiques.
— Méthode Agile : Découpage en sprints avec livraisons itératives.
— Kanban : Suivi visuel des tâches.

16
Conclusion
L’ingénierie des exigences et la conception des logiciels forment une discipline essen-
tielle pour garantir le succès des projets informatiques. La capture des exigences et la
production d’un Software Requirements Document (SRD) offrent une base solide pour
formaliser les besoins des utilisateurs et les contraintes du système, tout en facilitant la
communication entre les parties prenantes.
Les Use Cases et les User Stories constituent deux approches complémentaires pour
détailler les attentes fonctionnelles. Tandis que les Use Cases fournissent une vision tech-
nique et structurée du système, les User Stories privilégient une approche centrée sur
l’utilisateur, adaptée aux environnements Agile. La comparaison de ces deux méthodes
permet de choisir la plus appropriée en fonction des objectifs du projet et des publics
concernés.
La classification et la priorisation des exigences, à travers des techniques comme MoS-
CoW, Kano ou les points pondérés, permettent d’aligner les objectifs du projet sur les
contraintes techniques, temporelles et financières. Dans les cadres Agile, ces approches
sont intégrées à une gestion itérative, permettant d’adapter en temps réel les priorités en
fonction des besoins émergents et des retours des parties prenantes.
En somme, maîtriser l’ingénierie des exigences et les méthodologies de conception lo-
gicielle est indispensable pour répondre aux défis des projets complexes. L’intégration de
bonnes pratiques, la documentation claire et la collaboration active entre les parties pre-
nantes renforcent la probabilité de livrer des logiciels de qualité, conformes aux attentes
et aux objectifs initiaux. À mesure que les environnements logiciels continuent de se di-
versifier et de croître en complexité, cette discipline s’impose comme un levier stratégique
pour garantir innovation, efficacité et satisfaction des utilisateurs.

17
Références
[1] Ian Sommerville, Software Engineering, 10th Edition, Addison-Wesley, 2015.
[2] Roger S. Pressman, Software Engineering : A Practitioner’s Approach, 9th Edition,
McGraw-Hill, 2014.
[3] Klaus Pohl, Requirements Engineering : Fundamentals, Principles, and Techniques,
Springer, 2010.
[4] Mike Cohn, User Stories Applied : For Agile Software Development, Addison-Wesley,
2004.
[5] Martin Fowler, UML Distilled : A Brief Guide to the Standard Object Modeling
Language, 3rd Edition, Addison-Wesley, 2004.
[6] Karl E. Wiegers, Software Requirements, 3rd Edition, Microsoft Press, 2013.
[7] Dean Leffingwell, Agile Software Requirements : Lean Requirements Practices for
Teams, Programs, and the Enterprise, Addison-Wesley, 2011.
[8] Noriaki Kano, Attractive Quality and Must-Be Quality, Journal of the Japanese So-
ciety for Quality Control, 1984.
[9] Harold L. Davis, The Case for the Software Requirements Document, IEEE Software,
1982.
[10] Barry W. Boehm, Software Engineering Economics, Prentice-Hall, 1981.
[11] Alistair Cockburn, Agile Software Development, Addison-Wesley, 2002.
[12] JIRA Project: Online Library Management System, accessible en ligne.

18