e8ad874015
- Task #6: WebSocket /ws/dashboard + Kafka events (5 topics) * Backend: KafkaEventProducer, KafkaEventConsumer * Mobile: WebSocketService (reconnection, heartbeat, typed events) * DashboardBloc: Auto-refresh depuis WebSocket events - Finance Workflow: approbations + budgets (backend + mobile) * Backend: entities, services, resources, migrations Flyway V6 * Mobile: features finance_workflow complète avec BLoC - Corrections DI: interfaces IRepository partout * IProfileRepository, IOrganizationRepository, IMembreRepository * GetIt configuré avec @injectable - Spec-Kit: constitution + templates mis à jour * .specify/memory/constitution.md enrichie * Templates agent, plan, spec, tasks, checklist - Nettoyage: fichiers temporaires supprimés Signed-off-by: lions dev Team
3.9 KiB
Spécification de fonctionnalité : [NOM DE LA FONCTIONNALITÉ]
Branche feature : [###-nom-court]
Créé le : [DATE]
Statut : Brouillon
Entrée : Description utilisateur : « $ARGUMENTS »
Pour UnionFlow : ne pas inventer de packages, routes ou features non listés dans .specify/memory/inventaire-code.md.
Scénarios utilisateur et tests (obligatoire)
User Story 1 - [Titre court] (Priorité : P1)
[Décrire ce parcours utilisateur en langage simple]
Pourquoi cette priorité : [Valeur et justification]
Test indépendant : [Comment tester cette story seule — ex. « Testable par [action] et livre [valeur] »]
Scénarios d'acceptation :
- Étant donné [état initial], quand [action], alors [résultat attendu]
- Étant donné [état initial], quand [action], alors [résultat attendu]
User Story 2 - [Titre court] (Priorité : P2)
[Décrire ce parcours utilisateur en langage simple]
Pourquoi cette priorité : [Valeur et justification]
Test indépendant : [Comment tester cette story seule]
Scénarios d'acceptation :
- Étant donné [état initial], quand [action], alors [résultat attendu]
User Story 3 - [Titre court] (Priorité : P3)
[Décrire ce parcours utilisateur en langage simple]
Pourquoi cette priorité : [Valeur et justification]
Test indépendant : [Comment tester cette story seule]
Scénarios d'acceptation :
- Étant donné [état initial], quand [action], alors [résultat attendu]
[Ajouter d'autres user stories si besoin, chacune avec une priorité]
Cas limites
- Que se passe-t-il quand [condition limite] ?
- Comment le système gère-t-il [scénario d'erreur] ?
Exigences (obligatoire)
Exigences fonctionnelles
- EF-001 : Le système DOIT [capacité, ex. « permettre aux utilisateurs de créer un compte »]
- EF-002 : Le système DOIT [capacité, ex. « valider les adresses e-mail »]
- EF-003 : Les utilisateurs DOIVENT pouvoir [interaction clé, ex. « réinitialiser leur mot de passe »]
- EF-004 : Le système DOIT [exigence données, ex. « persister les préférences utilisateur »]
- EF-005 : Le système DOIT [comportement, ex. « journaliser tous les événements de sécurité »]
Exemple de marquage d'exigences floues :
- EF-006 : Le système DOIT authentifier les utilisateurs via [À PRÉCISER : méthode non précisée — email/mot de passe, SSO, OAuth ?]
- EF-007 : Le système DOIT conserver les données utilisateur pendant [À PRÉCISER : durée de rétention non précisée]
Entités clés (si la feature concerne des données)
- [Entité 1] : [Ce qu'elle représente, attributs clés sans détail d'implémentation]
- [Entité 2] : [Ce qu'elle représente, relations avec les autres entités]
Critères de succès (obligatoire)
Résultats mesurables
- CS-001 : [Métrique mesurable, ex. « Les utilisateurs peuvent créer un compte en moins de 2 minutes »]
- CS-002 : [Métrique mesurable, ex. « Le système supporte 1000 utilisateurs concurrents sans dégradation »]
- CS-003 : [Métrique satisfaction, ex. « 90 % des utilisateurs réussissent la tâche principale du premier coup »]
- CS-004 : [Métrique métier, ex. « Réduire de 50 % les tickets support liés à [X] »]