Document d’Exigences — Task Management System

Introduction

Le Task Management System est une application collaborative permettant aux équipes d’organiser, suivre et gérer leur travail via des tâches et des projets. Il facilite l’attribution des tâches, le suivi de la progression et la coordination entre membres d’équipe, avec un contrôle d’accès basé sur les rôles.

Glossaire

Story Map

La story map représente le parcours utilisateur de bout en bout, découpé en rôles, activités, tâches utilisateur et releases.

Légende des couleurs - 🟣 #b39ddb — Rôles utilisateurs - 🔵 #90caf9 — Activités (épiques) - 🟡 #fff176 — Tâches utilisateur (user tasks) - 🟢 #a5d6a7 — Release 1 MVP - 🟠 #ffcc80 — Release 2 Collaboration - 🔴 #ef9a9a — Release 3 Pilotage

graph TD
    %% ── RÔLES ──────────────────────────────────────────────────────────
    R1["👤 Admin"]:::role
    R2["👤 Manager"]:::role
    R3["👤 Developer"]:::role
    R4["👤 Viewer"]:::role

    %% ── ACTIVITÉS ──────────────────────────────────────────────────────
    A1["📁 Gérer son compte"]:::activity
    A2["📂 Gérer les projets"]:::activity
    A3["✅ Gérer les tâches"]:::activity
    A4["👥 Collaborer"]:::activity
    A5["📊 Suivre & Piloter"]:::activity

    %% ── TÂCHES UTILISATEUR ─────────────────────────────────────────────
    T1["S'authentifier"]:::usertask
    T2["Gérer les rôles"]:::usertask
    T3["Créer un projet"]:::usertask
    T4["Lister les projets"]:::usertask
    T5["Créer une tâche"]:::usertask
    T6["Changer le statut"]:::usertask
    T7["Gérer la priorité"]:::usertask
    T8["Créer une équipe"]:::usertask
    T9["Attribuer une tâche"]:::usertask
    T10["Voir les retards"]:::usertask
    T11["Trier / Filtrer"]:::usertask
    T12["Tableau de bord"]:::usertask

    %% ── RELEASES ───────────────────────────────────────────────────────
    MVP["🟢 Release 1 — MVP"]:::mvp
    R2L["🟠 Release 2 — Collaboration"]:::rel2
    R3L["🔴 Release 3 — Pilotage"]:::rel3

    %% ── LIENS RÔLES → ACTIVITÉS ────────────────────────────────────────
    R1 --> A1
    R2 --> A2
    R2 --> A4
    R3 --> A3
    R4 --> A5

    %% ── LIENS ACTIVITÉS → TÂCHES ───────────────────────────────────────
    A1 --> T1
    A1 --> T2
    A2 --> T3
    A2 --> T4
    A3 --> T5
    A3 --> T6
    A3 --> T7
    A4 --> T8
    A4 --> T9
    A5 --> T10
    A5 --> T11
    A5 --> T12

    %% ── LIENS TÂCHES → RELEASES ────────────────────────────────────────
    T1 --> MVP
    T2 --> MVP
    T3 --> MVP
    T4 --> MVP
    T5 --> MVP
    T6 --> MVP
    T7 --> MVP
    T10 --> MVP

    T8 --> R2L
    T9 --> R2L
    T11 --> R2L

    T12 --> R3L

    %% ── STYLES ─────────────────────────────────────────────────────────
    classDef role     fill:#b39ddb,stroke:#7e57c2,color:#000
    classDef activity fill:#90caf9,stroke:#1565c0,color:#000
    classDef usertask fill:#fff176,stroke:#f9a825,color:#000
    classDef mvp      fill:#a5d6a7,stroke:#2e7d32,color:#000
    classDef rel2     fill:#ffcc80,stroke:#e65100,color:#000
    classDef rel3     fill:#ef9a9a,stroke:#b71c1c,color:#000

Découpage des Releases

Release 1 — MVP (Minimum Valuable Product) - Authentification et gestion des rôles utilisateurs - Création et gestion de projets - Création et gestion de tâches (description, priorité, échéance, statut) - Suivi des statuts et identification des tâches en retard - API RESTful pour toutes ces opérations - Validation des données

Release 2 — Collaboration - Authentification réelle via Keycloak (OpenID Connect, PKCE) - Création et gestion des équipes - Attribution des tâches aux membres - Association de projets aux équipes - Tri et filtrage des tâches - Pagination UI

Release 3 — Pilotage - Tableau de bord de progression - Historique des modifications - Notifications d’échéances

Exigences

Exigence 1 : Création de Tâches (MVP)

User Story : En tant que membre d’équipe, je veux créer des tâches avec des informations détaillées, afin de documenter le travail à accomplir.

Example Mapping

graph TD
    US1["👤 membre d'équipe\nCréer une tâche"]:::role

    R1_1["📏 Description non vide obligatoire\nmax 250 caractères"]:::rule
    R1_2["📏 Priorité par défaut = medium"]:::rule
    R1_3["📏 Échéance optionnelle"]:::rule
    R1_4["📏 Horodatage de création enregistré"]:::rule

    E1_1["✅ Créer 'Corriger le bug #42' priorité high\n→ statut todo"]:::example_ok
    E1_2["✅ Créer sans priorité\n→ priorité medium assignée"]:::example_ok
    E1_3["✅ Créer sans échéance\n→ tâche acceptée"]:::example_ok
    E1_4["✅ Créer une tâche\n→ createdAt et createdBy présents"]:::example_ok
    E1_5["❌ Soumettre description vide\n→ erreur HTTP 400"]:::example_ko
    E1_6["❌ Soumettre description de 251 caractères\n→ erreur HTTP 400"]:::example_ko

    US1 --> R1_1
    US1 --> R1_2
    US1 --> R1_3
    US1 --> R1_4
    R1_1 --> E1_1
    R1_1 --> E1_5
    R1_1 --> E1_6
    R1_2 --> E1_2
    R1_3 --> E1_3
    R1_4 --> E1_4

    classDef role       fill:#b39ddb,stroke:#7e57c2,color:#000
    classDef rule       fill:#ffcc80,stroke:#e65100,color:#000
    classDef example_ok fill:#a5d6a7,stroke:#2e7d32,color:#000
    classDef example_ko fill:#ef9a9a,stroke:#b71c1c,color:#000
    classDef question   fill:#e0e0e0,stroke:#757575,color:#000

Critères d’Acceptation

  1. Scénario : Création d’une tâche complète

    Given un utilisateur authentifié
When il soumet une tâche avec une description "Corriger le bug #42", une échéance et une priorité "high"
Then le Task_Manager crée la Task avec ces informations et le statut "todo"
And la Task reçoit un identifiant unique
And le champ "createdAt" et "createdBy" sont enregistrés

  2. Scénario : Priorité par défaut

    Given un utilisateur authentifié
When il crée une tâche sans spécifier de priorité
Then le Task_Manager assigne la priorité "medium" par défaut

  3. Scénario : Tâche sans échéance

    Given un utilisateur authentifié
When il crée une tâche sans échéance
Then le Task_Manager accepte la Task sans exiger d'échéance

  4. Scénario : Rejet d’une description vide

    Given un utilisateur authentifié
When il soumet une tâche avec une description vide
Then le Task_Manager retourne une erreur HTTP 400
And le message d'erreur indique que la description est obligatoire

  5. Scénario : Rejet d’une description trop longue

    Given un utilisateur authentifié
When il soumet une tâche avec une description de 251 caractères
Then le Task_Manager retourne une erreur HTTP 400
And le message d'erreur indique que la description ne peut pas dépasser 250 caractères

Exigence 2 : Organisation des Tâches en Projets (MVP)

User Story : En tant que gestionnaire d’équipe, je veux organiser les tâches en projets, afin de regrouper le travail connexe.

Example Mapping

graph TD
    US2["👤 gestionnaire d'équipe\nOrganiser les tâches en projets"]:::role

    R2_1["📏 Un projet doit avoir un nom"]:::rule
    R2_2["📏 Plusieurs tâches peuvent appartenir\nau même projet"]:::rule
    R2_3["📏 Une tâche peut exister sans projet"]:::rule
    R2_4["📏 Consulter un projet liste ses tâches"]:::rule
    R2_5["📏 Pas de sous-projets"]:::rule

    E2_1["✅ Créer 'Sprint Q1'\n→ projet enregistré avec ID unique"]:::example_ok
    E2_2["✅ Associer T1, T2, T3 au projet P1\n→ association acceptée"]:::example_ok
    E2_3["✅ Créer une tâche sans projet\n→ tâche acceptée"]:::example_ok
    E2_4["✅ Consulter P1\n→ T1, T2, T3 affichées"]:::example_ok
    E2_5["❌ Créer un projet avec parentId\n→ erreur HTTP 400"]:::example_ko

    US2 --> R2_1
    US2 --> R2_2
    US2 --> R2_3
    US2 --> R2_4
    US2 --> R2_5
    R2_1 --> E2_1
    R2_2 --> E2_2
    R2_3 --> E2_3
    R2_4 --> E2_4
    R2_5 --> E2_5

    classDef role       fill:#b39ddb,stroke:#7e57c2,color:#000
    classDef rule       fill:#ffcc80,stroke:#e65100,color:#000
    classDef example_ok fill:#a5d6a7,stroke:#2e7d32,color:#000
    classDef example_ko fill:#ef9a9a,stroke:#b71c1c,color:#000
    classDef question   fill:#e0e0e0,stroke:#757575,color:#000

Critères d’Acceptation

  1. Scénario : Création d’un projet

    Given un utilisateur avec les permissions nécessaires
When il crée un Project avec le nom "Sprint Q1" et une description
Then le Task_Manager enregistre le Project avec un identifiant unique

  2. Scénario : Association de tâches à un projet

    Given un Project "Sprint Q1" existant
When plusieurs Tasks sont associées à ce Project
Then le Task_Manager permet ces associations multiples
And le Task_Manager lie chaque Task au Project

  3. Scénario : Affichage des tâches d’un projet

    Given un Project contenant plusieurs Tasks
When un utilisateur consulte ce Project
Then le Task_Manager affiche toutes les Tasks associées à ce Project

  4. Scénario : Tâche sans projet

    Given un utilisateur authentifié
When il crée une Task sans spécifier de Project
Then le Task_Manager accepte la Task sans association à un Project

  5. Scénario : Rejet de la création de sous-projet

    Given un Project existant
When un utilisateur tente de créer un Project avec un parentId
Then le Task_Manager retourne une erreur HTTP 400
And le message indique que les sous-projets ne sont pas supportés

Exigence 3 : Suivi du Statut des Tâches (MVP)

User Story : En tant que membre d’équipe, je veux mettre à jour le statut des tâches, afin que les autres puissent voir ma progression.

Example Mapping

graph TD
    US3["👤 membre d'équipe\nSuivre le statut des tâches"]:::role

    R3_1["📏 Seuls les statuts valides sont acceptés\ntodo / in-progress / completed"]:::rule
    R3_2["📏 La date de complétion est enregistrée"]:::rule
    R3_3["📏 Toutes les transitions sont permises\n(non contraintes)"]:::rule
    R3_4["📏 L'auteur de la modification est tracé"]:::rule

    E3_1["✅ Passer à in-progress\n→ accepté"]:::example_ok
    E3_2["❌ Passer à 'done'\n→ rejeté"]:::example_ko
    E3_3["✅ Passer à completed\n→ completedAt enregistré"]:::example_ok
    E3_4["✅ todo → completed directement\n→ accepté"]:::example_ok
    E3_5["✅ completed → todo\n→ accepté"]:::example_ok
    E3_6["✅ Modifier le statut\n→ updatedBy enregistré"]:::example_ok

    US3 --> R3_1
    US3 --> R3_2
    US3 --> R3_3
    US3 --> R3_4
    R3_1 --> E3_1
    R3_1 --> E3_2
    R3_2 --> E3_3
    R3_3 --> E3_4
    R3_3 --> E3_5
    R3_4 --> E3_6

    classDef role       fill:#b39ddb,stroke:#7e57c2,color:#000
    classDef rule       fill:#ffcc80,stroke:#e65100,color:#000
    classDef example_ok fill:#a5d6a7,stroke:#2e7d32,color:#000
    classDef example_ko fill:#ef9a9a,stroke:#b71c1c,color:#000
    classDef question   fill:#e0e0e0,stroke:#757575,color:#000

Critères d’Acceptation

  1. Scénario : Mise à jour avec valeur valide

    Given une Task avec le statut "todo"
When un utilisateur change le statut à "in-progress"
Then le Task_Manager accepte la mise à jour
And enregistre l'utilisateur ayant effectué la modification

  2. Scénario : Rejet d’un statut invalide

    Given une Task existante
When un utilisateur soumet le statut "done"
Then le Task_Manager rejette la mise à jour
And retourne un message d'erreur listant les valeurs valides ("todo", "in-progress", "completed")

  3. Scénario : Enregistrement de la date de complétion

    Given une Task avec le statut "in-progress"
When un utilisateur change le statut à "completed"
Then le Task_Manager enregistre l'horodatage de complétion dans "completedAt"

  4. Scénario : Transition libre entre statuts

    Given une Task avec le statut "completed"
When un utilisateur change le statut à "todo"
Then le Task_Manager accepte cette transition sans restriction

Exigence 4 : Gestion des Priorités (MVP)

User Story : En tant que gestionnaire d’équipe, je veux définir les priorités des tâches, afin que l’équipe se concentre d’abord sur le travail important.

Example Mapping

graph TD
    US4["👤 gestionnaire d'équipe\nGérer les priorités"]:::role

    R4_1["📏 Seules les priorités valides sont acceptées\nlow / medium / high"]:::rule
    R4_2["📏 La priorité est modifiable à tout moment"]:::rule
    R4_3["📏 Les tâches sont triables par priorité"]:::rule

    E4_1["✅ Définir high\n→ accepté"]:::example_ok
    E4_2["❌ Définir 'urgent'\n→ rejeté"]:::example_ko
    E4_3["✅ Modifier low → high sur tâche in-progress\n→ accepté"]:::example_ok
    E4_4["✅ Lister triées par priorité\n→ high en premier"]:::example_ok

    US4 --> R4_1
    US4 --> R4_2
    US4 --> R4_3
    R4_1 --> E4_1
    R4_1 --> E4_2
    R4_2 --> E4_3
    R4_3 --> E4_4

    classDef role       fill:#b39ddb,stroke:#7e57c2,color:#000
    classDef rule       fill:#ffcc80,stroke:#e65100,color:#000
    classDef example_ok fill:#a5d6a7,stroke:#2e7d32,color:#000
    classDef example_ko fill:#ef9a9a,stroke:#b71c1c,color:#000
    classDef question   fill:#e0e0e0,stroke:#757575,color:#000

Critères d’Acceptation

  1. Scénario : Définition d’une priorité valide

    Given une Task existante
When un utilisateur définit la priorité à "high"
Then le Task_Manager accepte et enregistre la priorité

  2. Scénario : Rejet d’une priorité invalide

    Given une Task existante
When un utilisateur soumet la priorité "urgent"
Then le Task_Manager rejette la mise à jour
And retourne un message d'erreur listant les valeurs valides ("low", "medium", "high")

  3. Scénario : Modification de priorité sur tâche en cours

    Given une Task avec le statut "in-progress" et la priorité "low"
When un utilisateur change la priorité à "high"
Then le Task_Manager accepte cette modification

  4. Scénario : Tri des tâches par priorité

    Given plusieurs Tasks avec des priorités différentes
When un utilisateur demande la liste triée par priorité
Then le Task_Manager retourne les Tasks dans l'ordre "high", "medium", "low"

Exigence 5 : Gestion des Rôles Utilisateurs (MVP)

User Story : En tant qu’administrateur, je veux attribuer des rôles aux utilisateurs, afin de contrôler les permissions d’accès.

Example Mapping

graph TD
    US5["👤 administrateur\nGérer les rôles utilisateurs"]:::role

    R5_1["📏 Seuls les rôles valides sont acceptés\nadmin / manager / developer / viewer"]:::rule
    R5_2["📏 Un User peut avoir plusieurs rôles"]:::rule
    R5_3["📏 viewer ne peut pas modifier"]:::rule
    R5_4["📏 developer peut créer des tâches\net mettre à jour ses propres tâches\n(pas celles des autres)"]:::rule
    R5_5["📏 manager peut créer projets,\ntâches et attributions"]:::rule
    R5_6["📏 admin a tous les droits"]:::rule

    E5_1["✅ Créer User avec rôle viewer\n→ accepté"]:::example_ok
    E5_2["❌ Créer User avec rôle 'superuser'\n→ rejeté"]:::example_ko
    E5_3["✅ Assigner rôles developer ET manager\nau même User → accepté"]:::example_ok
    E5_4["❌ viewer tente de créer une Task\n→ refusé HTTP 403"]:::example_ko
    E5_5["✅ developer crée une Task\n→ accepté"]:::example_ok
    E5_6["❌ developer modifie la Task d'un autre\n→ refusé HTTP 403"]:::example_ko
    E5_7["✅ manager crée un Project\n→ accepté"]:::example_ok
    E5_8["✅ admin supprime un User\n→ accepté"]:::example_ok

    US5 --> R5_1
    US5 --> R5_2
    US5 --> R5_3
    US5 --> R5_4
    US5 --> R5_5
    US5 --> R5_6
    R5_1 --> E5_1
    R5_1 --> E5_2
    R5_2 --> E5_3
    R5_3 --> E5_4
    R5_4 --> E5_5
    R5_4 --> E5_6
    R5_5 --> E5_7
    R5_6 --> E5_8

    classDef role       fill:#b39ddb,stroke:#7e57c2,color:#000
    classDef rule       fill:#ffcc80,stroke:#e65100,color:#000
    classDef example_ok fill:#a5d6a7,stroke:#2e7d32,color:#000
    classDef example_ko fill:#ef9a9a,stroke:#b71c1c,color:#000
    classDef question   fill:#e0e0e0,stroke:#757575,color:#000

Critères d’Acceptation

  1. Scénario : Attribution d’un rôle valide

    Given un admin authentifié
When il crée un User avec le rôle "developer"
Then le Task_Manager enregistre le User avec ce rôle

  2. Scénario : Rejet d’un rôle invalide

    Given un admin authentifié
When il tente de créer un User avec le rôle "superuser"
Then le Task_Manager rejette la requête
And retourne un message d'erreur listant les rôles valides ("admin", "manager", "developer", "viewer")

  3. Scénario : Restrictions du rôle viewer

    Given un User avec le rôle "viewer"
When il tente de créer une Task
Then le Task_Manager refuse l'opération avec un code HTTP 403

  4. Scénario : Permissions du rôle developer

    Given un User avec le rôle "developer"
When il crée une Task ou met à jour le statut d'une Task qui lui est attribuée
Then le Task_Manager accepte ces opérations

  5. Scénario : Permissions du rôle manager

    Given un User avec le rôle "manager"
When il crée un Project, une Task ou un Assignment
Then le Task_Manager accepte ces opérations

  6. Scénario : Permissions du rôle admin

    Given un User avec le rôle "admin"
When il effectue n'importe quelle opération, y compris la gestion des Users
Then le Task_Manager accepte toutes ces opérations

Exigence 6 : Suivi des Échéances (MVP)

User Story : En tant que membre d’équipe, je veux voir les échéances des tâches, afin de prioriser mon travail et respecter les délais.

Example Mapping

graph TD
    US6["👤 membre d'équipe\nSuivre les échéances"]:::role

    R6_1["📏 Échéance stockée avec date et heure"]:::rule
    R6_2["📏 Tâche non complétée après échéance\n= en retard"]:::rule
    R6_3["📏 Tâches triables par échéance"]:::rule
    R6_4["📏 Échéance modifiable à tout moment"]:::rule
    R6_5["📏 Tâche complétée en retard\nconserve ce statut"]:::rule
    R6_6["📏 Fuseau horaire de référence\nGMT+1 (Europe/Paris)"]:::rule

    E6_1["✅ Créer Task avec échéance 2025-12-31T18:00:00Z\n→ stockée précisément"]:::example_ok
    E6_2["✅ Task non complétée, échéance hier\n→ identifiée en retard"]:::example_ok
    E6_3["✅ Lister triées par échéance\n→ ordre chronologique"]:::example_ok
    E6_4["✅ Modifier l'échéance d'une Task in-progress\n→ accepté"]:::example_ok
    E6_5["✅ Compléter une Task après son échéance\n→ retard préservé dans l'historique"]:::example_ok
    E6_6["✅ Évaluer le retard d'une Task\n→ comparaison en GMT+1"]:::example_ok

    US6 --> R6_1
    US6 --> R6_2
    US6 --> R6_3
    US6 --> R6_4
    US6 --> R6_5
    US6 --> R6_6
    R6_1 --> E6_1
    R6_2 --> E6_2
    R6_3 --> E6_3
    R6_4 --> E6_4
    R6_5 --> E6_5
    R6_6 --> E6_6

    classDef role       fill:#b39ddb,stroke:#7e57c2,color:#000
    classDef rule       fill:#ffcc80,stroke:#e65100,color:#000
    classDef example_ok fill:#a5d6a7,stroke:#2e7d32,color:#000
    classDef example_ko fill:#ef9a9a,stroke:#b71c1c,color:#000
    classDef question   fill:#e0e0e0,stroke:#757575,color:#000

Critères d’Acceptation

  1. Scénario : Stockage précis de l’échéance

    Given un utilisateur authentifié
When il crée une Task avec l'échéance "2025-12-31T18:00:00Z"
Then le Task_Manager stocke l'échéance avec une précision de date et heure

  2. Scénario : Identification d’une tâche en retard

    Given une Task non complétée dont l'échéance est passée
When le Task_Manager évalue l'état de la Task
Then il identifie cette Task comme en retard

  3. Scénario : Tri par échéance

    Given plusieurs Tasks avec des échéances différentes
When un utilisateur demande la liste triée par échéance
Then le Task_Manager retourne les Tasks dans l'ordre chronologique croissant

  4. Scénario : Modification d’échéance

    Given une Task existante avec une échéance
When un utilisateur modifie l'échéance
Then le Task_Manager accepte et enregistre la nouvelle échéance

  5. Scénario : Préservation du retard à la complétion

    Given une Task dont l'échéance est dépassée
When un utilisateur la marque comme "completed"
Then le Task_Manager enregistre la complétion
And préserve l'indicateur de retard dans l'historique

  6. Scénario : Fuseau horaire de référence GMT+1

    Given une Task non complétée avec une échéance à "2025-06-15T23:59:00+01:00"
When le Task_Manager évalue le retard à "2025-06-16T00:01:00+01:00"
Then il identifie cette Task comme en retard en se basant sur le fuseau GMT+1 (Europe/Paris)

Exigence 7 : Validation des Données (MVP)

User Story : En tant qu’administrateur système, je veux une validation des entrées, afin de maintenir l’intégrité des données.

Example Mapping

graph TD
    US7["👤 administrateur système\nValider les données"]:::role

    R7_1["📏 Description vide → rejetée"]:::rule
    R7_2["📏 Statut invalide → rejeté\navec liste des valeurs valides"]:::rule
    R7_3["📏 Priorité invalide → rejetée\navec liste des valeurs valides"]:::rule
    R7_4["📏 Échéance dans le passé\n→ acceptée avec avertissement"]:::rule
    R7_5["📏 Attribution à User inexistant\n→ rejetée"]:::rule

    E7_1["❌ Soumettre Task sans description\n→ erreur HTTP 400"]:::example_ko
    E7_2["❌ Soumettre statut 'done'\n→ erreur avec liste todo, in-progress, completed"]:::example_ko
    E7_3["❌ Soumettre priorité 'critical'\n→ erreur avec liste low, medium, high"]:::example_ko
    E7_4["✅ Créer Task avec échéance hier\n→ Task créée + warning retourné"]:::example_ok
    E7_5["❌ Assigner Task à userId inconnu\n→ erreur HTTP 404"]:::example_ko

    US7 --> R7_1
    US7 --> R7_2
    US7 --> R7_3
    US7 --> R7_4
    US7 --> R7_5
    R7_1 --> E7_1
    R7_2 --> E7_2
    R7_3 --> E7_3
    R7_4 --> E7_4
    R7_5 --> E7_5

    classDef role       fill:#b39ddb,stroke:#7e57c2,color:#000
    classDef rule       fill:#ffcc80,stroke:#e65100,color:#000
    classDef example_ok fill:#a5d6a7,stroke:#2e7d32,color:#000
    classDef example_ko fill:#ef9a9a,stroke:#b71c1c,color:#000
    classDef question   fill:#e0e0e0,stroke:#757575,color:#000

Critères d’Acceptation

  1. Scénario : Rejet d’une description vide

    Given un utilisateur authentifié
When il soumet une Task avec une description vide
Then le Task_Manager retourne une erreur HTTP 400
And le message d'erreur indique que la description est obligatoire

  2. Scénario : Rejet d’un statut invalide

    Given une Task existante
When un utilisateur soumet le statut "done"
Then le Task_Manager retourne une erreur HTTP 400
And le message liste les valeurs valides : "todo", "in-progress", "completed"

  3. Scénario : Rejet d’une priorité invalide

    Given une Task existante
When un utilisateur soumet la priorité "critical"
Then le Task_Manager retourne une erreur HTTP 400
And le message liste les valeurs valides : "low", "medium", "high"

  4. Scénario : Échéance dans le passé avec avertissement

    Given un utilisateur authentifié
When il crée une Task avec une échéance dans le passé
Then le Task_Manager crée la Task
And retourne un avertissement indiquant que l'échéance est déjà dépassée

  5. Scénario : Rejet d’une attribution à un User inexistant

    Given une Task existante
When un utilisateur tente d'attribuer la Task à un userId inexistant
Then le Task_Manager retourne une erreur HTTP 404
And le message indique que l'utilisateur cible n'existe pas

Exigence 8 : API RESTful (MVP)

User Story : En tant que développeur, je veux une API RESTful, afin d’intégrer le système de gestion des tâches avec d’autres outils.

Example Mapping

graph TD
    US8["👤 développeur\nIntégrer via API RESTful"]:::role

    R8_1["📏 Endpoints Tasks suivent /api/tasks"]:::rule
    R8_2["📏 Endpoints Tasks d'un projet\nsuivent /api/projects/{id}/tasks"]:::rule
    R8_3["📏 Succès → HTTP 200, 201, 204"]:::rule
    R8_4["📏 Erreur client → HTTP 400, 403, 404"]:::rule
    R8_5["📏 Erreur serveur → HTTP 500"]:::rule
    R8_6["📏 Format d'erreur JSON cohérent"]:::rule
    R8_7["📏 Pagination obligatoire\nsur les endpoints de liste"]:::rule

    E8_1["✅ GET /api/tasks\n→ liste des tâches HTTP 200"]:::example_ok
    E8_2["✅ GET /api/projects/42/tasks\n→ tâches du projet HTTP 200"]:::example_ok
    E8_3["✅ POST /api/tasks\n→ Task créée HTTP 201"]:::example_ok
    E8_4["❌ GET /api/tasks/999 (inexistant)\n→ HTTP 404 + JSON d'erreur"]:::example_ko
    E8_5["❌ Erreur base de données\n→ HTTP 500"]:::example_ko
    E8_6["✅ Toute erreur\n→ JSON avec champ 'error'"]:::example_ok
    E8_7["✅ GET /api/tasks?page=1&limit=20\n→ résultats paginés avec métadonnées"]:::example_ok

    US8 --> R8_1
    US8 --> R8_2
    US8 --> R8_3
    US8 --> R8_4
    US8 --> R8_5
    US8 --> R8_6
    US8 --> R8_7
    R8_1 --> E8_1
    R8_2 --> E8_2
    R8_3 --> E8_3
    R8_4 --> E8_4
    R8_5 --> E8_5
    R8_6 --> E8_6
    R8_7 --> E8_7

    classDef role       fill:#b39ddb,stroke:#7e57c2,color:#000
    classDef rule       fill:#ffcc80,stroke:#e65100,color:#000
    classDef example_ok fill:#a5d6a7,stroke:#2e7d32,color:#000
    classDef example_ko fill:#ef9a9a,stroke:#b71c1c,color:#000
    classDef question   fill:#e0e0e0,stroke:#757575,color:#000

Critères d’Acceptation

  1. Scénario : Endpoints Tasks

    Given l'API est disponible
When un développeur accède à "GET /api/tasks"
Then le Task_Manager retourne la liste des Tasks avec HTTP 200

  2. Scénario : Endpoints Tasks d’un projet

    Given un Project avec l'id "42" existant
When un développeur accède à "GET /api/projects/42/tasks"
Then le Task_Manager retourne les Tasks de ce Project avec HTTP 200

  3. Scénario : Code HTTP à la création

    Given un utilisateur authentifié
When il crée une Task via "POST /api/tasks"
Then le Task_Manager retourne HTTP 201 avec la Task créée dans le corps de la réponse

  4. Scénario : Code HTTP pour ressource introuvable

    Given aucune Task avec l'id "999"
When un développeur accède à "GET /api/tasks/999"
Then le Task_Manager retourne HTTP 404
And le corps contient un message d'erreur JSON

  5. Scénario : Format d’erreur cohérent

    Given une requête API invalide
When le Task_Manager retourne une erreur
Then le corps de la réponse est un JSON avec au minimum un champ "error" contenant le message d'erreur

  6. Scénario : Pagination des résultats

    Given 50 Tasks existantes dans le système
When un développeur accède à "GET /api/tasks?page=1&limit=20"
Then le Task_Manager retourne les 20 premières Tasks avec HTTP 200
And la réponse contient les métadonnées de pagination (page, limit, total, totalPages)

  7. Scénario : Pagination par défaut

    Given des Tasks existantes dans le système
When un développeur accède à "GET /api/tasks" sans paramètres de pagination
Then le Task_Manager applique une pagination par défaut (page 1, limit 20)
And la réponse contient les métadonnées de pagination

Release 2 — Collaboration

Exigence 14 : Authentification Keycloak (Release 2)

User Story : En tant qu’administrateur système, je veux intégrer un fournisseur d’identité cloud-native (Keycloak), afin de sécuriser l’authentification des utilisateurs avec un standard industriel (OpenID Connect).

Example Mapping

graph TD
    US14["👤 administrateur système\nIntégrer Keycloak"]:::role

    R14_1["📏 Keycloak est le fournisseur d'identité\nunique du système"]:::rule
    R14_2["📏 Le frontend redirige vers Keycloak\npour l'authentification (PKCE)"]:::rule
    R14_3["📏 Le backend valide les tokens JWT\nvia JWKS (RS256)"]:::rule
    R14_4["📏 Les rôles sont gérés dans Keycloak\net synchronisés dans le JWT"]:::rule
    R14_5["📏 POST /api/auth/login échange\nle token Keycloak contre un session token"]:::rule

    E14_1["✅ Utilisateur non authentifié\n→ redirigé vers Keycloak"]:::example_ok
    E14_2["✅ Connexion réussie via Keycloak\n→ redirection vers /tasks"]:::example_ok
    E14_3["❌ Token Keycloak invalide\n→ HTTP 401"]:::example_ko
    E14_4["✅ Rôles Keycloak synchronisés\n→ permissions appliquées"]:::example_ok
    E14_5["✅ Token expiré\n→ refresh automatique"]:::example_ok

    US14 --> R14_1
    US14 --> R14_2
    US14 --> R14_3
    US14 --> R14_4
    US14 --> R14_5
    R14_1 --> E14_1
    R14_2 --> E14_2
    R14_3 --> E14_3
    R14_4 --> E14_4
    R14_5 --> E14_5

    classDef role       fill:#b39ddb,stroke:#7e57c2,color:#000
    classDef rule       fill:#ffcc80,stroke:#e65100,color:#000
    classDef example_ok fill:#a5d6a7,stroke:#2e7d32,color:#000
    classDef example_ko fill:#ef9a9a,stroke:#b71c1c,color:#000
    classDef question   fill:#e0e0e0,stroke:#757575,color:#000

Critères d’Acceptation

  1. Scénario : Redirection vers Keycloak

    Given un utilisateur non authentifié
When il accède à une page protégée
Then le Task_Manager redirige vers la page de connexion Keycloak

  2. Scénario : Connexion réussie via Keycloak

    Given un utilisateur sur la page de connexion Keycloak
When il saisit des identifiants valides
Then Keycloak retourne un authorization_code
And le frontend échange le code contre un access_token (PKCE)
And le frontend appelle POST /api/auth/login avec le token Keycloak
And le backend valide le token via JWKS et retourne un session_token
And l'utilisateur est redirigé vers /tasks

  3. Scénario : Rejet d’un token Keycloak invalide

    Given un token Keycloak invalide ou expiré
When le frontend appelle POST /api/auth/login
Then le Task_Manager retourne HTTP 401
And le message indique que le token est invalide

  4. Scénario : Synchronisation des rôles Keycloak

    Given un utilisateur avec le rôle "manager" dans Keycloak
When il se connecte via POST /api/auth/login
Then le Task_Manager synchronise le rôle "manager" dans la base de données
And les permissions RBAC sont appliquées selon ce rôle

  5. Scénario : Refresh automatique du token

    Given un utilisateur authentifié dont le token est expiré
When le frontend détecte l'expiration
Then il utilise le refresh_token pour obtenir un nouveau access_token
And l'utilisateur reste connecté sans interruption

Exigence 9 : Attribution de Tâches (Release 2)

User Story : En tant que gestionnaire d’équipe, je veux attribuer des tâches aux membres de l’équipe, afin que chacun connaisse ses responsabilités.

Example Mapping

graph TD
    US9["👤 gestionnaire d'équipe\nAttribuer des tâches"]:::role

    R9_1["📏 Une Task peut être attribuée à un User"]:::rule
    R9_2["📏 Une Task peut avoir plusieurs assignés"]:::rule
    R9_3["📏 Un User voit ses tâches attribuées"]:::rule
    R9_4["📏 Supprimer un Assignment\nne supprime pas la Task"]:::rule
    R9_5["📏 Horodatage d'attribution enregistré"]:::rule
    R9_6["📏 Un developer peut\ns'auto-attribuer une Task"]:::rule

    E9_1["✅ Attribuer T1 à U1\n→ Assignment créé avec assignedAt"]:::example_ok
    E9_2["✅ Attribuer T1 à U1 et U2\n→ deux Assignments distincts"]:::example_ok
    E9_3["✅ U1 consulte ses tâches\n→ T1 apparaît"]:::example_ok
    E9_4["✅ Retirer U1 de T1\n→ T1 existe toujours"]:::example_ok
    E9_5["✅ Developer s'auto-attribue T1\n→ Assignment créé"]:::example_ok

    US9 --> R9_1
    US9 --> R9_2
    US9 --> R9_3
    US9 --> R9_4
    US9 --> R9_5
    US9 --> R9_6
    R9_1 --> E9_1
    R9_2 --> E9_2
    R9_3 --> E9_3
    R9_4 --> E9_4
    R9_5 --> E9_1
    R9_6 --> E9_5

    classDef role       fill:#b39ddb,stroke:#7e57c2,color:#000
    classDef rule       fill:#ffcc80,stroke:#e65100,color:#000
    classDef example_ok fill:#a5d6a7,stroke:#2e7d32,color:#000
    classDef example_ko fill:#ef9a9a,stroke:#b71c1c,color:#000
    classDef question   fill:#e0e0e0,stroke:#757575,color:#000

Critères d’Acceptation

  1. Scénario : Attribution d’une tâche

    Given une Task et un User existants
When un manager attribue la Task à ce User
Then le Task_Manager crée un Assignment liant la Task au User
And enregistre l'horodatage dans "assignedAt"

  2. Scénario : Attribution multiple

    Given une Task existante
When elle est attribuée à deux Users différents
Then le Task_Manager crée deux Assignments distincts

  3. Scénario : Consultation des tâches attribuées

    Given un User avec des Assignments
When il consulte ses tâches attribuées via "GET /api/tasks?assignedTo={userId}"
Then le Task_Manager retourne toutes les Tasks liées à ce User

  4. Scénario : Suppression d’une attribution

    Given un Assignment existant entre une Task et un User
When un manager supprime cet Assignment
Then le Task_Manager supprime l'Assignment
And la Task existe toujours sans être supprimée

  5. Scénario : Auto-attribution par un developer

    Given un User avec le rôle "developer" et une Task existante
When il s'attribue lui-même cette Task via "POST /api/tasks/{id}/assignments"
Then le Task_Manager crée un Assignment liant la Task à ce User
And enregistre l'horodatage dans "assignedAt"

Exigence 10 : Collaboration en Équipe (Release 2)

User Story : En tant que gestionnaire d’équipe, je veux créer des équipes et ajouter des membres, afin d’organiser les utilisateurs par département ou fonction.

Example Mapping

graph TD
    US10["👤 gestionnaire d'équipe\nCréer des équipes et ajouter des membres"]:::role

    R10_1["📏 Une Team doit avoir un nom"]:::rule
    R10_2["📏 Maximum 6 membres par Team"]:::rule
    R10_3["📏 Un User peut appartenir\nà plusieurs Teams"]:::rule
    R10_4["📏 Consulter une Team liste ses membres"]:::rule
    R10_5["📏 Un Project peut être associé\nà une Team"]:::rule

    E10_1["✅ Créer 'Frontend Team'\n→ Team enregistrée avec ID unique"]:::example_ok
    E10_2["✅ Ajouter U1, U2, U3 à Frontend Team\n→ trois membres enregistrés"]:::example_ok
    E10_3["❌ Ajouter un 7ème membre à une Team\n→ erreur HTTP 400"]:::example_ko
    E10_4["✅ U1 ajouté à 'Frontend' et 'Mobile'\n→ deux appartenances acceptées"]:::example_ok
    E10_5["✅ Consulter 'Frontend Team'\n→ U1, U2, U3 affichés"]:::example_ok
    E10_6["✅ Associer P1 à 'Frontend Team'\n→ association créée"]:::example_ok

    US10 --> R10_1
    US10 --> R10_2
    US10 --> R10_3
    US10 --> R10_4
    US10 --> R10_5
    R10_1 --> E10_1
    R10_2 --> E10_2
    R10_2 --> E10_3
    R10_3 --> E10_4
    R10_4 --> E10_5
    R10_5 --> E10_6

    classDef role       fill:#b39ddb,stroke:#7e57c2,color:#000
    classDef rule       fill:#ffcc80,stroke:#e65100,color:#000
    classDef example_ok fill:#a5d6a7,stroke:#2e7d32,color:#000
    classDef example_ko fill:#ef9a9a,stroke:#b71c1c,color:#000
    classDef question   fill:#e0e0e0,stroke:#757575,color:#000

Critères d’Acceptation

  1. Scénario : Création d’une équipe

    Given un manager authentifié
When il crée une Team avec le nom "Frontend Team"
Then le Task_Manager enregistre la Team avec un identifiant unique

  2. Scénario : Ajout de membres

    Given une Team "Frontend Team" existante avec moins de 6 membres
When un manager ajoute trois Users à cette Team
Then le Task_Manager enregistre les trois appartenances

  3. Scénario : Rejet du dépassement de capacité

    Given une Team avec 6 membres
When un manager tente d'ajouter un 7ème User
Then le Task_Manager retourne une erreur HTTP 400
And le message indique que la Team a atteint sa capacité maximale de 6 membres

  4. Scénario : Appartenance à plusieurs équipes

    Given un User existant
When il est ajouté à deux Teams différentes
Then le Task_Manager accepte ces deux appartenances

  5. Scénario : Affichage des membres

    Given une Team avec plusieurs membres
When un utilisateur consulte cette Team
Then le Task_Manager retourne la liste de tous les Users membres

  6. Scénario : Association d’un projet à une équipe

    Given une Team et un Project existants
When un manager associe le Project à la Team
Then le Task_Manager enregistre cette association

Release 3 — Pilotage

Exigence 11 : Tableau de Bord de Progression (Release 3)

User Story : En tant que gestionnaire d’équipe, je veux consulter un tableau de bord de progression, afin d’avoir une vue d’ensemble de l’avancement du travail.

Example Mapping

graph TD
    US11["👤 gestionnaire d'équipe\nConsulter le tableau de bord"]:::role

    R11_1["📏 Le tableau de bord affiche\nle nombre de tâches par statut"]:::rule
    R11_2["📏 Le tableau de bord est filtrable\npar projet et par équipe"]:::rule
    R11_3["📏 Le tableau de bord affiche\nle taux de complétion"]:::rule

    E11_1["✅ Consulter le dashboard\n→ compteurs todo / in-progress / completed affichés"]:::example_ok
    E11_2["✅ Filtrer par projet P1\n→ statistiques limitées aux tâches de P1"]:::example_ok
    E11_3["✅ Filtrer par équipe 'Frontend'\n→ statistiques limitées aux tâches de l'équipe"]:::example_ok
    E11_4["✅ 3 tâches completed sur 10\n→ taux de complétion 30% affiché"]:::example_ok

    US11 --> R11_1
    US11 --> R11_2
    US11 --> R11_3
    R11_1 --> E11_1
    R11_2 --> E11_2
    R11_2 --> E11_3
    R11_3 --> E11_4

    classDef role       fill:#b39ddb,stroke:#7e57c2,color:#000
    classDef rule       fill:#ffcc80,stroke:#e65100,color:#000
    classDef example_ok fill:#a5d6a7,stroke:#2e7d32,color:#000
    classDef example_ko fill:#ef9a9a,stroke:#b71c1c,color:#000
    classDef question   fill:#e0e0e0,stroke:#757575,color:#000

Critères d’Acceptation

  1. Scénario : Affichage des compteurs par statut

    Given un gestionnaire authentifié
When il consulte le tableau de bord
Then le Task_Manager affiche le nombre de Tasks pour chaque statut : "todo", "in-progress", "completed"

  2. Scénario : Filtrage par projet

    Given un gestionnaire authentifié et un Project "Sprint Q1" existant
When il consulte le tableau de bord filtré par ce Project
Then le Task_Manager retourne les statistiques uniquement pour les Tasks de ce Project

  3. Scénario : Filtrage par équipe

    Given un gestionnaire authentifié et une Team "Frontend" existante
When il consulte le tableau de bord filtré par cette Team
Then le Task_Manager retourne les statistiques uniquement pour les Tasks des projets de cette Team

  4. Scénario : Taux de complétion

    Given 10 Tasks dont 3 avec le statut "completed"
When un gestionnaire consulte le tableau de bord
Then le Task_Manager affiche un taux de complétion de 30%

Exigence 12 : Historique des Modifications (Release 3)

User Story : En tant que membre d’équipe, je veux consulter l’historique des modifications d’une tâche, afin de comprendre son évolution et tracer les changements.

Example Mapping

graph TD
    US12["👤 membre d'équipe\nConsulter l'historique des modifications"]:::role

    R12_1["📏 Chaque modification de statut\nest enregistrée dans l'historique"]:::rule
    R12_2["📏 Chaque modification de priorité\nest enregistrée dans l'historique"]:::rule
    R12_3["📏 L'historique contient l'auteur,\nla date et les valeurs avant/après"]:::rule
    R12_4["📏 L'historique est accessible\nvia l'API"]:::rule

    E12_1["✅ Changer statut todo → in-progress\n→ entrée d'historique créée"]:::example_ok
    E12_2["✅ Changer priorité low → high\n→ entrée d'historique créée"]:::example_ok
    E12_3["✅ Consulter historique de T1\n→ auteur, date, ancienne et nouvelle valeur présents"]:::example_ok
    E12_4["✅ GET /api/tasks/{id}/history\n→ liste des modifications retournée"]:::example_ok

    US12 --> R12_1
    US12 --> R12_2
    US12 --> R12_3
    US12 --> R12_4
    R12_1 --> E12_1
    R12_2 --> E12_2
    R12_3 --> E12_3
    R12_4 --> E12_4

    classDef role       fill:#b39ddb,stroke:#7e57c2,color:#000
    classDef rule       fill:#ffcc80,stroke:#e65100,color:#000
    classDef example_ok fill:#a5d6a7,stroke:#2e7d32,color:#000
    classDef example_ko fill:#ef9a9a,stroke:#b71c1c,color:#000
    classDef question   fill:#e0e0e0,stroke:#757575,color:#000

Critères d’Acceptation

  1. Scénario : Enregistrement d’un changement de statut

    Given une Task avec le statut "todo"
When un utilisateur change le statut à "in-progress"
Then le Task_Manager crée une entrée dans l'historique
And l'entrée contient l'auteur, la date, la valeur avant "todo" et la valeur après "in-progress"

  2. Scénario : Enregistrement d’un changement de priorité

    Given une Task avec la priorité "low"
When un utilisateur change la priorité à "high"
Then le Task_Manager crée une entrée dans l'historique
And l'entrée contient l'auteur, la date, la valeur avant "low" et la valeur après "high"

  3. Scénario : Consultation de l’historique via l’API

    Given une Task avec plusieurs modifications enregistrées
When un utilisateur accède à "GET /api/tasks/{id}/history"
Then le Task_Manager retourne la liste chronologique des modifications avec HTTP 200

  4. Scénario : Historique vide pour une nouvelle tâche

    Given une Task nouvellement créée sans modification
When un utilisateur accède à "GET /api/tasks/{id}/history"
Then le Task_Manager retourne une liste vide avec HTTP 200

Exigence 13 : Notifications d’Échéances (Release 3)

User Story : En tant que membre d’équipe, je veux recevoir des notifications lorsqu’une échéance approche ou est dépassée, afin de ne pas manquer mes délais.

Example Mapping

graph TD
    US13["👤 membre d'équipe\nRecevoir des notifications d'échéances"]:::role

    R13_1["📏 Une notification est générée\n24h avant l'échéance"]:::rule
    R13_2["📏 Une notification est générée\nlorsque l'échéance est dépassée"]:::rule
    R13_3["📏 Les notifications sont accessibles\nvia l'API"]:::rule
    R13_4["📏 Une notification est marquée\ncomme lue par l'utilisateur"]:::rule

    E13_1["✅ Task avec échéance dans 23h\n→ notification générée"]:::example_ok
    E13_2["✅ Task non complétée, échéance dépassée\n→ notification de retard générée"]:::example_ok
    E13_3["✅ GET /api/notifications\n→ liste des notifications retournée"]:::example_ok
    E13_4["✅ Marquer notification comme lue\n→ statut 'read' enregistré"]:::example_ok
    E13_5["✅ Task complétée avant échéance\n→ aucune notification de retard générée"]:::example_ok

    US13 --> R13_1
    US13 --> R13_2
    US13 --> R13_3
    US13 --> R13_4
    R13_1 --> E13_1
    R13_2 --> E13_2
    R13_2 --> E13_5
    R13_3 --> E13_3
    R13_4 --> E13_4

    classDef role       fill:#b39ddb,stroke:#7e57c2,color:#000
    classDef rule       fill:#ffcc80,stroke:#e65100,color:#000
    classDef example_ok fill:#a5d6a7,stroke:#2e7d32,color:#000
    classDef example_ko fill:#ef9a9a,stroke:#b71c1c,color:#000
    classDef question   fill:#e0e0e0,stroke:#757575,color:#000

Critères d’Acceptation

  1. Scénario : Notification 24h avant l’échéance

    Given une Task non complétée dont l'échéance est dans moins de 24h
When le Task_Manager évalue les échéances
Then il génère une notification pour les Users assignés à cette Task

  2. Scénario : Notification de retard

    Given une Task non complétée dont l'échéance est dépassée
When le Task_Manager évalue les échéances
Then il génère une notification de retard pour les Users assignés à cette Task

  3. Scénario : Pas de notification pour tâche complétée

    Given une Task avec le statut "completed" dont l'échéance est dépassée
When le Task_Manager évalue les échéances
Then il ne génère aucune notification de retard pour cette Task

  4. Scénario : Consultation des notifications

    Given un User avec des notifications non lues
When il accède à "GET /api/notifications"
Then le Task_Manager retourne la liste de ses notifications avec HTTP 200

  5. Scénario : Marquer une notification comme lue

    Given une notification non lue
When un User effectue "PATCH /api/notifications/{id}/read"
Then le Task_Manager marque la notification comme lue
And retourne HTTP 200

Notes

Ce document définit les exigences fonctionnelles du Task Management System selon la méthodologie BDD, organisées en Story Map avec un découpage en releases. Chaque User Story inclut un Example Mapping Mermaid coloré et des critères d’acceptation en format Gherkin (Given/When/Then), garantissant la clarté, la testabilité et la traçabilité des exigences.