Analyse des exigences

Que fait Analyse des exigences ?

Indications générales à appliquer lorsqu'une exigence (User Story + Règles Métier, le cas échéant) est reçue pour analyse — et non pour construction (cela relève de la skill implementer-requirement). Portable : applicable quel que soit le projet/client.

1. Lecture et extraction

• Lire le document complet et en extraire : objectif, périmètre, acteurs, flux, règles métier explicites.
• Signaler toute incohérence à l'intérieur même du document (ex. un élément mentionné dans l'Objectif mais jamais détaillé ensuite, ou une règle qui se contredit avec une autre partie du texte).
• Examiner également toutes les images/preuves embarquées (maquettes, écrans, tableaux de bord) — pas seulement les plus évidentes. Elles contiennent souvent des détails absents du texte et peuvent combler une lacune laissée par le texte.

2. Comparaison avec l'existant (si applicable)

• Si l'exigence touche ou ressemble à un module/processus/fonctionnalité déjà construite, la comparer avec le code réel du projet actuel pour déterminer ce qui peut être réutilisé vs. ce qui doit être nouveau.
• Si elle implique de modifier quelque chose qui est déjà en production (un autre module, une autre intégration, un autre flux partagé), évaluer le risque de cette modification sur l'existant et privilégier l'isolement du nouveau plutôt que d'altérer le comportement actuel, sauf si l'exigence demande explicitement ce changement.
• Vérifier les conclusions auprès de la base de données réelle DEV avant de les tenir pour acquises — ne pas présumer du schéma/données, le consulter. Serveur et identifiants : les demander à l'utilisateur s'ils ne sont pas déjà dans la conversation ; ne pas réutiliser des identifiants trouvés dans des commentaires/code sans autorisation explicite de l'utilisateur.

3. Questions ouvertes

• Lister explicitement tout point ambigu, non spécifié, ou dépendant d'une décision métier/client (ex. conditions d'une négociation, montants, délais, seuils, autorisations, exceptions).
• Marquer chaque point comme En attente jusqu'à réponse ; lorsque le client répond, documenter la réponse et passer à Résolu.
• N'inclure dans l'estimation rien qui dépende d'une question encore sans réponse.

4. Inventaire

Liste complète des objets de base de données, écrans, règles métier/validations et rapports affectés ou nouveaux, en indiquant (Nouveau) ou (Modification) pour chacun.

5. Livrables

• Analyse_Impact_[CODE].docx — document d'impact à envoyer à l'équipe de développement du client/prestataire.
• Estimation_temps_[CODE].xlsx — heures par objet/tâche, avec total.
• Plan_Implementation_[CODE].docx — plan par phases avec dépendances entre elles (pas tout dans une seule phase).
• Par défaut, lors de l'analyse d'une exigence, seul le fichier Estimation_temps_[CODE].xlsx est généré. Analyse_Impact_[CODE].docx et Plan_Implementation_[CODE].docx ne sont pas générés automatiquement en tant que fichiers — leur contenu (objectif, périmètre, règles métier, incohérences, comparaison avec l'existant, questions ouvertes, inventaire, phases du plan) est tout de même développé et reste disponible dans la conversation, prêt à être versé dans un document dès que l'utilisateur le demande explicitement (par ex. "génère l'Analyse d'Impact" ou "passe-le en Word").
• Estimation_temps_[CODE].xlsx doit être construit à partir d'un modèle existant (si un modèle se trouve déjà dans le dossier de l'exigence, le copier, ne pas recréer le tableau à partir de zéro ; s'il n'y en a aucun dans le projet, demander à l'utilisateur s'il dispose d'un modèle standard avant d'inventer le format). Format attendu sauf indication contraire de l'utilisateur : bandeau de titre + tableau avec colonnes N° | Activité | Hrs | Jrs (colonne Activité large, une ligne par activité, ligne Total en fin avec formule de somme et Jrs = Hrs./8). Ne pas inventer de colonnes supplémentaires (Type, Remarques, détail Analyse/Développement/Tests séparé, etc.) — si l'on souhaite détailler le type (Nouveau/Modification) ou des remarques, les inclure dans le texte de la cellule "Activité".
• Heures réalistes : créditer la réutilisation déjà confirmée à l'étape 2 (ne pas estimer comme si tout était nouveau), ne pas utiliser d'heuristiques uniformes pour toutes les tâches, et demander la capacité réelle de l'équipe si nécessaire pour traduire les heures en dates.

6. État et blocages

En fin d'analyse, résumer : ce qui est confirmé, ce qui reste en attente, et ce qui bloque le début de la construction (documentation manquante, réponses client/métier en attente, approbations, etc.).