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
104 lines
3.9 KiB
Markdown
104 lines
3.9 KiB
Markdown
# 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)*
|
|
|
|
<!--
|
|
Les user stories doivent être PRIORISÉES par ordre d'importance.
|
|
Chaque user story doit être TESTABLE INDÉPENDAMMENT : en n'implémentant qu'une seule,
|
|
on doit avoir un MVP (Minimum Viable Product) qui apporte de la valeur.
|
|
Priorités : P1, P2, P3, etc. (P1 = le plus critique).
|
|
Chaque story = slice autonome : développable, testable, déployable, démontrable seule.
|
|
-->
|
|
|
|
### 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** :
|
|
|
|
1. **Étant donné** [état initial], **quand** [action], **alors** [résultat attendu]
|
|
2. **É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** :
|
|
|
|
1. **É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** :
|
|
|
|
1. **Étant donné** [état initial], **quand** [action], **alors** [résultat attendu]
|
|
|
|
---
|
|
|
|
[Ajouter d'autres user stories si besoin, chacune avec une priorité]
|
|
|
|
### Cas limites
|
|
|
|
<!-- Remplir avec les vrais cas limites -->
|
|
|
|
- Que se passe-t-il quand [condition limite] ?
|
|
- Comment le système gère-t-il [scénario d'erreur] ?
|
|
|
|
## Exigences *(obligatoire)*
|
|
|
|
<!-- Remplir avec les exigences fonctionnelles réelles -->
|
|
|
|
### 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)*
|
|
|
|
<!-- Définir des critères mesurables, indépendants de la technologie -->
|
|
|
|
### 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] »]
|