Analyse métier : du besoin aux spécifications
Analyse métier : du besoin aux spécifications est un cours de niveau intermédiaire de 5 leçons (environ 1 h 27), avec 15 exercices et 15 questions de quiz. Aucun prérequis. Les exercices s'exécutent dans le navigateur, sans installation.
- Compétences transverses
- Intermédiaire
- 5 leçons
- 1 h 27
- 15 exercices
- Exercices exécutés dans le navigateur
Le cours en bref
Ce cours vous apprend le métier d'analyste : comprendre un problème d'entreprise et le traduire en exigences qu'une équipe peut construire et tester. Vous cartographiez les parties prenantes, menez des entretiens, modélisez les processus en BPMN, rédigez des user stories et leurs critères d'acceptation, puis priorisez le périmètre avec MoSCoW et RICE. Toutes les notions sont pratiquées sur un même fil rouge, avec des exercices au résultat vérifiable.
Ce que tu sauras faire
- Cartographier les parties prenantes et mener des entretiens qui distinguent besoin et solution
- Formuler des exigences fonctionnelles et non fonctionnelles mesurables
- Modéliser un processus en BPMN (événements, tâches, passerelles, couloirs) et comparer AS-IS et TO-BE
- Rédiger des user stories INVEST et découper une epic verticalement
- Écrire des critères d'acceptation en Gherkin avec valeurs limites et règles de gestion tracées
- Prioriser avec MoSCoW, valeur / effort et RICE, et gérer les demandes de changement
Programme des 5 leçons
- Identifier et cartographier les parties prenantes d'un projet
- Mener un entretien ou un atelier de recueil du besoin
- Distinguer besoin et solution, exigences fonctionnelles et non fonctionnelles
Parties prenantesEntretien et atelier de recueilExigences fonctionnelles et non fonctionnelles
- 02
Modéliser les processus avec BPMN
- Lire et dessiner un processus BPMN avec événements, tâches, passerelles et couloirs
- Choisir la bonne passerelle (exclusive, parallèle, inclusive)
- Comparer un processus actuel (AS-IS) et cible (TO-BE) et en mesurer le gain
- 03
Rédiger des user stories
- Rédiger une user story au format rôle / action / bénéfice
- Vérifier la qualité d'une story avec les critères INVEST
- Découper une epic en stories livrables et les organiser en story map
- 04
Critères d'acceptation et spécifications
- Rédiger des critères d'acceptation précis, y compris les cas limites
- Écrire des scénarios Gherkin (Étant donné / Quand / Alors) et des plans de scénario
- Structurer une spécification fonctionnelle avec règles de gestion et traçabilité
Critères d'acceptationGherkin et exemplesRègles de gestionSpécification fonctionnelle
- 05
Prioriser et gérer le périmètre
- Prioriser des besoins avec MoSCoW, la matrice valeur / effort et le score RICE
- Construire un périmètre de première version qui tient dans une capacité donnée
- Gérer les demandes de changement en mesurant leur impact
Méthode MoSCoWScore RICE et valeur / effortPremière version et périmètreGestion des demandes de changement
Projet final
Dossier d'analyse pour la préparation des commandes en magasin
Une enseigne fictive de proximité veut outiller la préparation et le retrait des commandes en ligne. À partir d'au moins trois entretiens (réels ou joués, en le signalant) avec des rôles différents, produisez le dossier d'analyse complet qui permettra à une équipe de développer une première version.
Livrables
- La matrice pouvoir / intérêt des parties prenantes et les comptes rendus d'entretiens validés
- Les processus AS-IS et TO-BE en BPMN, avec le gain de durée estimé
- Une story map et au moins huit user stories INVEST
- Les critères d'acceptation en Gherkin de trois stories, avec valeurs limites
- Les règles de gestion numérotées, les exigences non fonctionnelles et une matrice de traçabilité
- Le périmètre de la première version justifié par MoSCoW ou RICE et une capacité donnée
Critères d'évaluation
- Les besoins sont distingués des solutions et rattachés aux entretiens
- Les schémas BPMN sont corrects (passerelles adaptées, flux de message entre bassins, fins nommées)
- Les stories respectent INVEST et sont découpées verticalement
- Les critères d'acceptation sont concrets, observables et couvrent les cas limites
- La priorisation est chiffrée, cohérente avec la capacité et traçable
Questions fréquentes
Faut-il savoir programmer pour devenir analyste métier ?
Non. Le métier repose sur l'écoute, la modélisation et la rédaction. Comprendre les bases du développement et des données aide toutefois à dialoguer avec l'équipe technique.
BPMN est-il difficile à apprendre ?
Les éléments de base (événements, tâches, passerelles, couloirs) suffisent pour la plupart des processus et s'apprennent en quelques heures. Le cours se concentre sur eux et sur les erreurs les plus fréquentes.
Ce cours est-il adapté aux méthodes agiles ?
Oui. User stories, critères d'acceptation, story mapping et priorisation sont au cœur des méthodes agiles ; le recueil du besoin et la modélisation des processus restent utiles quelle que soit la méthode.
Quelle différence entre analyste métier et product owner ?
L'analyste métier recueille, analyse et formalise les besoins ; le product owner porte la vision du produit et décide des priorités. Dans les petites équipes, une même personne joue souvent les deux rôles.
Ce cours, raconté pour ton métier
Dis ce que tu veux savoir faire : « Analyse métier : du besoin aux spécifications » prend sa place dans ton parcours, avec des exemples de ton secteur. Les notions restent celles du cours.