Exercices genie logiciel serie 1 capture des besoins gi s5 g

Télécharger PDF

Série N° 1 : Capture Efficace et Hiérarchisation des Besoins en Génie Logiciel

Ce guide explore les fondamentaux de la capture et de la formalisation des besoins en génie logiciel, un processus crucial pour le succès de tout projet. Nous aborderons également des méthodes de hiérarchisation, telles que le modèle de KANO et les poids relatifs, pour assurer que les fonctionnalités les plus importantes soient développées en priorité.

Définition de la vision d’un projet web

Cette section est dédiée à la compréhension et à la description de la vision d'un projet, ainsi qu'aux défis et techniques associés à la capture et à la formalisation des besoins.

1. Décrire la vision d'un projet de site web de recrutement

La vision d'un projet est une déclaration concise et inspirante qui décrit l'objectif ultime du projet et la valeur qu'il apportera aux utilisateurs et à l'entreprise. Pour un site web de recrutement, elle pourrait être formulée comme suit pour convaincre votre direction :

Vision du projet : Créer une plateforme web intuitive et performante qui connecte efficacement les candidats qualifiés aux entreprises en offrant des outils de recherche avancés et des recommandations personnalisées, afin de simplifier le processus de recrutement et d'améliorer la satisfaction des deux parties.

Cette description met en évidence le problème à résoudre, la solution proposée et la valeur ajoutée, tout en restant suffisamment courte pour être facilement communiquée et comprise par les parties prenantes.

2. Difficultés rencontrées lors de la capture des besoins

La capture des besoins est une étape complexe qui peut être semée d'embûches. Parmi les difficultés les plus courantes, on trouve :

Ambiguïté et incomplétude : Les utilisateurs ont souvent du mal à exprimer clairement leurs besoins ou en oublient des aspects cruciaux.
Conflits d'intérêts : Différentes parties prenantes peuvent avoir des attentes contradictoires, rendant difficile l'établissement d'une vision unifiée.
Changement des besoins : Les besoins peuvent évoluer pendant le cycle de vie du projet, nécessitant une adaptation constante.
Communication inefficace : Un manque de clarté dans la communication entre les équipes techniques et les utilisateurs métier peut entraîner des malentendus.
Hypothèses non vérifiées : L'équipe de développement peut faire des suppositions erronées sur ce que les utilisateurs attendent réellement.
Complexité du domaine : Le domaine métier peut être intrinsèquement compliqué à comprendre et à modéliser, surtout pour les analystes non experts.

3. Solutions envisagées dans le contexte de la capture des besoins

Pour surmonter ces difficultés, plusieurs solutions peuvent être mises en œuvre pour améliorer l'efficacité de la capture des besoins :

Collaboration active : Impliquer régulièrement les parties prenantes, y compris les utilisateurs finaux, tout au long du processus de définition des besoins.
Techniques de prototypage et maquettage : Développer des maquettes ou des prototypes interactifs pour visualiser et valider les besoins de manière concrète.
Ateliers de travail facilités : Organiser des sessions structurées avec les utilisateurs pour recueillir, discuter et affiner collectivement les exigences.
Documentation claire et standardisée : Utiliser des modèles de documentation éprouvés (comme les cas d'utilisation ou les user stories) pour rendre les besoins faciles à comprendre et à maintenir.
Gestion du changement des exigences : Mettre en place un processus formel pour suivre, évaluer et intégrer les évolutions des besoins.
Formation et expertise : S'assurer que les analystes d'affaires et les chefs de projet ont une bonne compréhension du domaine métier et des techniques de recueil.

4. Techniques possibles pour recueillir les besoins

Le recueil des besoins est une phase exploratoire où différentes techniques peuvent être combinées pour obtenir une vue complète et précise :

Entretiens : Discussions individuelles ou de groupe avec les parties prenantes clés pour explorer leurs attentes et contraintes.
Questionnaires et enquêtes : Utilisés pour recueillir des informations standardisées auprès d'un grand nombre d'utilisateurs.
Observation : Observer les utilisateurs dans leur environnement de travail pour comprendre leurs processus réels et identifier les besoins implicites.
Ateliers de brainstorming : Séances créatives pour générer de nouvelles idées et des exigences innovantes.
Analyse de documents existants : Étude des rapports, manuels d'utilisation, procédures et systèmes existants pour comprendre le contexte et les besoins fonctionnels et non fonctionnels.
Analyse des cas d'utilisation (Use Cases) : Décrire les interactions des acteurs avec le système pour atteindre un objectif spécifique.
Storytelling et jeux de rôles : Encourager les utilisateurs à raconter des scénarios d'utilisation pour mieux cerner leurs attentes.

5. Techniques de formalisation des besoins

Une fois recueillis, les besoins doivent être formalisés pour être clairs, non ambigus, testables et compréhensibles par toutes les parties. Voici quelques techniques de formalisation :

Spécifications des Exigences Logiciel (SEL) : Un document détaillé qui décrit toutes les fonctions, les contraintes, les interfaces et les critères de performance du système.
Cas d'utilisation (Use Cases) : Représentés par des diagrammes et des descriptions textuelles structurées, ils modélisent les interactions entre les utilisateurs (acteurs) et le système.
User Stories (Récits utilisateur) : Des descriptions courtes et simples d'une fonctionnalité du point de vue de l'utilisateur, suivant le format "En tant que [type d'utilisateur], je veux [action] afin de [bénéfice]". Elles sont particulièrement utiles en méthodes agiles.
Diagrammes UML (Unified Modeling Language) : Utilisation de diagrammes de classes, de séquences, d'activités, etc., pour modéliser différents aspects structurels et comportementaux du système.
Prototypes et maquettes : Des représentations visuelles et parfois interactives du futur système qui servent de support à la formalisation et à la validation des exigences.
Matrice de traçabilité des exigences : Un outil qui permet de suivre la mise en œuvre de chaque besoin à travers les différentes étapes du développement, de la conception aux tests.

Hiérarchisation des besoins

Après avoir identifié et formalisé les besoins, il est essentiel de les hiérarchiser pour concentrer les efforts de développement sur les fonctionnalités les plus impactantes et réalisables. Nous examinerons ici le modèle de KANO et celui des poids relatifs.

1. Application du modèle de KANO pour la priorisation des user stories

Le modèle de KANO est une approche de priorisation qui classe les fonctionnalités en fonction de leur potentiel à satisfaire ou à insatisfaire les clients. Il distingue cinq catégories de besoins :

Basique (Must-have) : Indispensables, leur absence cause une forte insatisfaction, mais leur présence n'apporte pas de satisfaction supplémentaire (elles sont simplement attendues).
Performance (One-dimensional) : Plus il y en a, plus la satisfaction augmente. La satisfaction est proportionnelle à la qualité ou à la quantité de la fonctionnalité.
Délice (Attractive) : Fonctionnalités inattendues qui ravissent les utilisateurs. Leur absence ne crée pas d'insatisfaction, mais leur présence génère un enthousiasme significatif.
Indifférent : N'affecte pas la satisfaction de l'utilisateur.
Inverse : Leur présence entraîne l'insatisfaction de l'utilisateur.

Appliquons le modèle de KANO aux user stories suivantes pour un site web de recrutement :

Je peux consulter des offres d’emploi. (Basique) : C'est la fonctionnalité minimale attendue d'un site de recrutement. Sans elle, le site est fondamentalement inutile.
Je peux consulter des offres d’emploi récentes. (Performance) : Une meilleure performance (accès rapide aux nouveautés) augmente la satisfaction de l'utilisateur.
Je peux rechercher des offres avec plusieurs critères. (Performance) : Plus les critères de recherche sont nombreux et précis (meilleure performance de recherche), plus l'utilité et la satisfaction de l'utilisateur augmentent.
Je peux directement consulter des offres ciblées en fonction de mon profil et de l’historique de mes recherches. (Délice) : Cette personnalisation est un "plus" inattendu qui ravit l'utilisateur sans causer d'insatisfaction si elle est absente.
Le site intègre une fonctionnalité d’envoi d’e-mails automatiquement en fonction de mon profil et de l’historique de mes recherches. (Délice) : Une alerte proactive est une fonctionnalité qui dépasse les attentes et crée un fort engagement en offrant un service supplémentaire.

2. Hiérarchisation via le modèle des poids relatifs

Le modèle des poids relatifs attribue une valeur numérique ou un score à chaque exigence en fonction de son importance relative pour le projet, de son urgence, de sa complexité de mise en œuvre, ou de sa valeur métier. Une méthode courante est la méthode MoSCoW (Must-have, Should-have, Could-have, Won't-have) ou l'attribution de scores pondérés.

Appliquons une approche simplifiée par poids relatifs aux mêmes user stories, en considérant par exemple l'importance métier et l'impact sur l'utilisateur :

Je peux consulter des offres d’emploi. (Poids très élevé / Must-have) : Fonctionnalité fondamentale et non négociable.
Je peux consulter des offres d’emploi récentes. (Poids élevé / Should-have) : Très important pour maintenir la pertinence et l'actualité du contenu.
Je peux rechercher des offres avec plusieurs critères. (Poids élevé / Must-have-Should-have) : Essentiel pour une recherche efficace et une bonne expérience utilisateur.
Je peux directement consulter des offres ciblées en fonction de mon profil et de l’historique de mes recherches. (Poids moyen / Could-have) : Ajoute une grande valeur et améliore l'expérience, mais n'est pas critique pour une première version.
Le site intègre une fonctionnalité d’envoi d’e-mails automatiquement en fonction de mon profil et de l’historique de mes recherches. (Poids moyen / Could-have) : Très utile pour la rétention, mais peut être implémenté dans des versions ultérieures après les fonctionnalités de base.

Les poids exacts dépendraient d'une matrice de décision spécifique au projet, prenant en compte des facteurs comme la valeur business, le coût de développement, le risque, et l'urgence.

3. Quelles différences coexistent entre les deux modèles ?

Bien que les deux modèles visent à prioriser les besoins, ils le font selon des perspectives différentes :

Nature de la classification : Le modèle de KANO se concentre sur la perception de la satisfaction utilisateur (la psychologie du client) et la manière dont les fonctionnalités affectent le plaisir ou le déplaisir. Les modèles des poids relatifs (comme MoSCoW ou des scores numériques) se basent plus sur la valeur métier, l'urgence, la faisabilité ou l'impact direct du besoin sur les objectifs du projet.
Objectif principal : KANO aide à comprendre quels types de fonctionnalités vont réellement ravir les utilisateurs ou simplement éviter leur insatisfaction, guidant la stratégie produit. Les poids relatifs visent à déterminer l'ordre de développement en fonction des contraintes de temps, de ressources et de la stratégie d'entreprise.
Granularité : KANO offre une classification qualitative en catégories larges. Les modèles des poids relatifs permettent souvent une hiérarchisation plus fine et quantitative au sein des catégories, grâce à l'attribution de scores numériques ou de labels de priorité précis.

En somme, KANO permet de comprendre "le type" de besoin et son impact émotionnel, tandis que les poids relatifs permettent de décider "quand" le développer en fonction de contraintes et d'objectifs opérationnels.

4. Proposer un modèle hybride qui combine les deux modèles

Un modèle hybride peut tirer parti des forces des deux méthodes pour une priorisation plus robuste et éclairée. Voici une approche possible :

Phase 1 : Classification KANO initiale : Commencer par évaluer toutes les user stories et les classer dans les catégories KANO (Basique, Performance, Délice, Indifférent, Inverse). Cela permet d'identifier rapidement les "must-have" (éléments de base), les "delighters" (avantages concurrentiels potentiels) et les "performance features" (qui apportent de la valeur incrémentale).
Phase 2 : Priorisation par poids relatifs au sein des catégories KANO : Une fois les fonctionnalités classées par KANO, appliquer une méthode de poids relatifs (comme MoSCoW, une notation pondérée par valeur/effort/risque, ou WSJF - Weighted Shortest Job First) au sein de chaque catégorie KANO.
- Besoins Basiques : Attribuer la priorité la plus élevée. Utiliser les poids relatifs pour gérer l'ordre de développement si plusieurs basiques sont concurrents. Sans ces fonctionnalités, le produit est inacceptable.
- Besoins de Performance : Attribuer une priorité élevée. Utiliser les poids relatifs pour choisir celles qui offrent le meilleur retour sur investissement en termes de satisfaction utilisateur par rapport à l'effort de développement.
- Besoins de Délice : Attribuer une priorité moyenne à élevée. Ces fonctionnalités peuvent être des différenciateurs clés. Les poids relatifs aideront à identifier celles qui sont réalisables, apportent le plus grand "effet wow" pour un effort raisonnable, et alignées avec la stratégie produit.
- Besoins Indifférents/Inverses : Attribuer une priorité basse, voire nulle. Ne pas développer ces fonctionnalités, sauf si leur nature ou leur perception évolue à l'avenir.

Cette approche hybride permet de s'assurer que les besoins fondamentaux sont couverts en priorité, que les fonctionnalités de performance sont optimisées, et que des éléments de délice sont intégrés stratégiquement pour maximiser la satisfaction client et la compétitivité, tout en gérant efficacement les contraintes du projet.

Foire Aux Questions (FAQ)

Qu'est-ce que la vision d'un projet web ?

La vision d'un projet web est une déclaration concise qui définit l'objectif à long terme du projet, le problème qu'il résout, et la valeur unique qu'il apporte aux utilisateurs et à l'organisation. Elle sert de guide stratégique pour toutes les décisions de développement et doit être courte et inspirante.

Pourquoi la capture des besoins est-elle si complexe ?

La capture des besoins est complexe car elle implique souvent des communications imparfaites, des attentes divergentes entre les parties prenantes, des besoins qui évoluent avec le temps, et la difficulté pour les utilisateurs de formuler précisément et complètement leurs exigences. Les ambiguïtés, l'incomplétude et les conflits d'intérêts sont des défis majeurs.

Comment le modèle de KANO aide-t-il à hiérarchiser les fonctionnalités ?

Le modèle de KANO hiérarchise les fonctionnalités en les classant selon leur impact sur la satisfaction client : Basiques (indispensables), Performance (plus il y en a, mieux c'est), et Délice (qui surprennent et ravissent). Cette classification aide à prioriser non seulement ce qui doit être fait absolument, mais aussi ce qui va réellement satisfaire, ou même enchanter, les utilisateurs, guidant ainsi les décisions d'investissement en développement.