Comprenez le besoin fonctionnel

Vous faites partie de TechFlow Solutions, une start-up dynamique.

Votre mission est cruciale : développer une application de gestion de tâches pour les équipes techniques. C'est un projet excitant, mais attention : si l'équipe commence à coder avant d'avoir parfaitement clarifié ce que le client attend, vous risquez des malentendus coûteux, des retards, et pire, la construction d’un outil que personne n'utilisera.

Dans ce chapitre, nous allons transformer cette idée initiale d’application de gestion de tâches en un ensemble d'exigences claires et non ambiguës. Vous apprendrez à passer du besoin métier flou à des critères d'acceptation précis, un élément fondamental pour tout projet réussi.

Identifiez le besoin métier

Avant de vous lancer dans la définition des fonctionnalités, vous devez adopter le rôle d’enquêteur.

Pour y parvenir, vous devez commencer par analyser le contexte du projet. Cela implique de définir clairement trois axes essentiels :

1. les objectifs (que veut-on atteindre ?),

2. les contraintes (temps, budget, technologies existantes)

3. et les utilisateurs cibles.

Dans le cas de notre start-up, les utilisateurs cibles sont les équipes techniques – ont-ils besoin d'une intégration avec des outils de développement spécifiques ? Ont-ils des contraintes de temps pour la mise à jour des tâches ? Ce sont des questions pragmatiques qui orienteront vos choix futurs.

Ensuite, votre travail consiste à identifier les besoins exprimés et implicites :

• Les besoins exprimés sont ceux que le client vous a clairement demandés (« Nous voulons pouvoir assigner des tâches »).

• Les besoins implicites sont ceux que le client n'a pas formulés, mais qui sont nécessaires au bon fonctionnement de l'application (« Si je crée une tâche, je dois pouvoir la modifier ou la supprimer »).

Pour recueillir ces informations de manière concrète, vous utiliserez des outils de recueil :

• Les entretiens individuels ou collectifs avec les équipes techniques vous permettront de saisir leurs frustrations actuelles et leurs attentes précises.

• Les questionnaires peuvent être utiles pour valider des hypothèses à grande échelle

• L'utilisation de User Stories (Histoires Utilisateur) est une approche particulièrement efficace dans la démarche Agile. Une User Story capture un besoin du point de vue de l'utilisateur final et constitue une excellente base pour la formalisation des exigences.

En adoptant une approche opérationnelle et pragmatique, vous vous assurez de ne pas simplifier à l'extrême, mais plutôt de faciliter la compréhension des besoins réels des équipes techniques.

Cette première étape est la fondation sur laquelle reposera toute l'architecture de votre future application de gestion de tâches.

Formalisez les exigences fonctionnelles et non fonctionnelles

Une fois que vous avez identifié les besoins bruts, il est impératif de les transformer en exigences formelles.

Pour cela, vous allez rédiger des cas d'utilisation clairs et complets.

Dans le contexte Agile, cela se traduit par la rédaction détaillée des User Stories et de leurs conditions d'exécution :

• Chaque exigence doit être formulée avec un vocabulaire précis et non ambigu.

• Il faut éviter les termes subjectifs comme « rapide », « facile » ou « intuitif » qui pourraient être interprétés différemment par le client, le Product Owner (PO) et les développeurs.

Le point critique de cette étape est de distinguer clairement les exigences fonctionnelles et non fonctionnelles :

• Les exigences fonctionnelles décrivent ce que le système doit faire. Pour l'application de la start-up, une exigence fonctionnelle serait : « L'application doit permettre la création, la modification et la suppression de tâches » (le "quoi").

• Les exigences non fonctionnelles décrivent comment le système doit fonctionner ou les contraintes qui pèsent sur lui. Elles peuvent concerner la performance, la sécurité, l'ergonomie, ou la maintenabilité (le "comment bien").

Imaginez, par exemple, que le client exige que l'application de gestion de tâches soit « rapide ». Cette exigence est floue. Votre travail consiste à la décomposer. Si elle est rapide, cela pourrait signifier : « Le temps de chargement de la liste des tâches ne doit jamais excéder 2 secondes, même avec 100 tâches actives. » Le premier est un souhait, le second est une exigence non fonctionnelle mesurable.

C'est en adoptant cette rigueur dans la formalisation que vous garantirez que les équipes techniques de la start-up comprennent exactement la portée du travail à réaliser et pourront livrer un produit qui répond réellement aux attentes métier.

Définissez les critères dʼacceptation

Nous avons maintenant des exigences claires.

C’est là qu'interviennent les critères d’acceptation, qui servent de jalon de validation.

Vous devez établir des critères mesurables pour valider chaque exigence. Ces critères sont essentiels pour que le client (ou le PO) puisse dire « oui, la fonctionnalité est terminée et elle fonctionne comme attendu ». Si vous avez une exigence fonctionnelle stipulant que l'on peut assigner une tâche, le critère d'acceptation pourrait être : « L'utilisateur reçoit une notification par email lorsque la tâche lui est assignée. »

Un autre aspect crucial de cette étape est de hiérarchiser les besoins. Toutes les fonctionnalités ne sont pas égales. C'est pourquoi vous devez classer les fonctionnalités selon leur importance.

La classification permet de déterminer l'ordre de développement et ce qui doit absolument être inclus dans la première version (le MVP, Minimum Viable Product).

Une méthode courante pour cette classification est la méthode MoSCoW :

• Must Have (Doit avoir) : Fonctionnalités absolument critiques sans lesquelles le produit ne peut pas fonctionner (ex : se connecter et créer une tâche).

• Should Have (Devrait avoir) : Fonctionnalités importantes mais contournables (ex : filtrage avancé des tâches).

• Could Have (Pourrait avoir) : Fonctionnalités désirables, mais non essentielles (ex : personnalisation des couleurs de l'interface).

• Won't Have (N'aura pas pour l'instant) : Fonctionnalités reportées à plus tard.

Enfin, vous devez identifier les dépendances techniques entre fonctionnalités. 

Par exemple, la fonction d'assignation de tâche dépend de l'existence d'une base de données d'utilisateurs. Comprendre ces dépendances est essentiel pour planifier le développement et éviter les blocages des équipes techniques de notre start-up.

En définissant des critères mesurables et en hiérarchisant le travail, vous vous assurez que le produit livré sera non seulement fonctionnel, mais aligné sur les priorités du métier.

Communiquez les besoins à lʼéquipe technique

La meilleure des analyses et la plus précise des formalisations ne servent à rien si elles ne sont pas communiquées efficacement. Pour que les développeurs de la start-up puissent coder le bon outil, la transmission des exigences doit être impeccable.

Votre rôle est de garantir un langage commun entre le client, le Product Owner (PO) et les développeurs :

• Les termes techniques utilisés par les développeurs (comme API, framework, latency) peuvent ne pas être compris par le client, et inversement, le vocabulaire métier du client doit être traduit en concepts que les développeurs peuvent implémenter.

• Le PO agit souvent comme ce traducteur essentiel, s'assurant que tout le monde utilise les mêmes définitions pour les mêmes concepts.

• Par exemple, si le client parle de "Projet", il faut s'assurer que pour le développeur, ce terme ne soit pas confondu avec un "Espace de travail" ou un "Tableau de bord".

Pour faciliter cette compréhension, il est crucial d'utiliser des supports visuels. Un simple diagramme peut clarifier un flux de travail complexe plus rapidement que dix pages de texte. 

Pour notre application de gestion de tâches, vous pourriez utiliser un mock-up (maquette) simple ou un diagramme d'activité montrant le processus de création et de clôture d'une tâche.

Enfin, si vous suivez la démarche Agile, cette communication passe par la formalisation du backlog produit.

C'est en transmettant un backlog clair, bien priorisé (grâce à MoSCoW) et doté de critères d'acceptation précis que vous fournirez à la start-up la feuille de route nécessaire pour transformer l'idée d'application de gestion de tâches en réalité fonctionnelle.

À vous de jouer !

Contexte

Vous travaillez pour TechFlow Solutions. L'équipe de la start-up a organisé une réunion initiale pour discuter de la future application de gestion de tâches. Les besoins sont exprimés, mais ils restent formulés de manière vague et ne sont pas mesurables (par exemple : « Il faut que l'on puisse assigner des gens aux tâches », « Il faut que l'application soit sûre »). Ces imprécisions risquent d’engendrer des malentendus coûteux si l'équipe technique commence à travailler sans clarification.

Consignes

Vous avez recueilli ces informations initiales et vous devez maintenant les formaliser.

1. Rédigez un minimum de trois User Stories pour le besoin "Création et assignation de tâche", en incluant pour chacune d'elles au moins un critère dʼacceptation mesurable.

2. Vous devrez également identifier au moins deux exigences non fonctionnelles (sécurité, performance, etc.) qui s'appliquent à l'application de gestion de tâches, et les formuler de manière précise.

En résumé

• Vous devez commencer par analyser le contexte du projet (objectifs, contraintes, utilisateurs cibles) et utiliser des outils comme les User Stories pour recueillir les besoins exprimés et implicites, afin de passer d'une idée floue à une base solide de travail.

• Il est crucial de rédiger des cas d'utilisation clairs en employant un vocabulaire précis et non ambigu, tout en distinguant rigoureusement les exigences fonctionnelles (ce que le système fait) de ses contraintes de qualité ou de performance (non fonctionnelles).

• Chaque exigence doit être validée par des critères d’acceptation mesurables (souvent rédigés selon le formalisme Gherkin) et les fonctionnalités doivent être classées selon leur importance, par exemple grâce à la méthode MoSCoW, pour structurer le développement.

• Pour éviter les malentendus coûteux, vous devez garantir un langage commun entre le client et l'équipe technique, utiliser des supports visuels pour clarifier les flux, et maintenir un backlog produit formalisé et documenté.

Vous avez défini le quoi de l'application (exigences fonctionnelles et critères d'acceptation mesurables). Il est maintenant temps de préparer le comment en rédigeant les spécifications techniques.