---
description: Phase 5 - User validation of specifications
agent: ba-validate
model: haiku
---

# Phase 5: Validation Utilisateur

> **Modèle:** Haiku (gate approbation, oui/non)
> **Coût estimé:** ~$0.01
> **Prérequis:** 3-functional-specification.md existant

---

## GATE VALIDATION (BLOQUANT)

```
╔══════════════════════════════════════════════════════════════════════════════╗
║  VALIDATION OBLIGATOIRE AVANT HANDOFF                                        ║
╠══════════════════════════════════════════════════════════════════════════════╣
║                                                                              ║
║  Cette phase est un GATE qui BLOQUE le passage au handoff si non approuvé.   ║
║                                                                              ║
║  Le sponsor/stakeholder DOIT valider:                                        ║
║  • Les cas d'utilisation sont complets                                       ║
║  • Les wireframes correspondent aux attentes                                 ║
║  • Les règles métier sont correctes                                          ║
║  • Les permissions sont appropriées                                          ║
║                                                                              ║
║  SI REJET:                                                                   ║
║  → Retour à /business-analyse:3-analyse pour révision                        ║
║  → Document versionné (incrémentation minor ou major)                        ║
║                                                                              ║
╚══════════════════════════════════════════════════════════════════════════════╝
```

---

## STEP 1: Charger les documents

```bash
FEATURE_ID=$1
FEATURE_DIR=$(find .business-analyse -type d -name "${FEATURE_ID}*" | head -1)
FRD_FILE="$FEATURE_DIR/3-functional-specification.md"

if [ ! -f "$FRD_FILE" ]; then
  echo "❌ ERREUR: 3-functional-specification.md non trouvé"
  echo "   Lancez d'abord: /business-analyse:4-specify $FEATURE_ID"
  exit 1
fi

# Charger les documents pour résumé
DISCOVERY=$(cat "$FEATURE_DIR/1-discovery.md" 2>/dev/null)
BRD=$(cat "$FEATURE_DIR/2-business-requirements.md" 2>/dev/null)
FRD=$(cat "$FRD_FILE")
```

---

## STEP 2: Afficher le résumé pour validation

```
================================================================================
                    VALIDATION DES SPÉCIFICATIONS - {FEATURE_ID}
================================================================================

DOCUMENTS À VALIDER:

1. DISCOVERY (1-discovery.md)
   ────────────────────────────────────────
   • Stakeholders identifiés: {N}
   • Questions ouvertes: {N}
   • Périmètre défini: ✅

2. BRD (2-business-requirements.md)
   ────────────────────────────────────────
   • Objectifs business: {N}
   • Règles métier: {N} (BR-001 à BR-XXX)
   • Processus modélisés: {N}

3. FRD (3-functional-specification.md)
   ────────────────────────────────────────
   • Cas d'utilisation: {N} (UC-001 à UC-XXX)
   • Exigences fonctionnelles: {N} (FR-001 à FR-XXX)
   • Wireframes: {N} écrans
   • Permissions: {N} définies
   • Scénarios Gherkin: {N}

================================================================================
```

---

## STEP 3: Demande de validation

```javascript
AskUserQuestion({
  questions: [
    {
      question: "Les cas d'utilisation couvrent-ils tous les besoins exprimés?",
      header: "Use Cases",
      options: [
        { label: "Oui, complets", description: "Tous les UC sont validés" },
        { label: "Partiellement", description: "Certains UC manquent ou sont incomplets" },
        { label: "Non", description: "Révision majeure nécessaire" }
      ],
      multiSelect: false
    },
    {
      question: "Les wireframes correspondent-ils à vos attentes?",
      header: "UI/UX",
      options: [
        { label: "Oui, validés", description: "Les écrans sont conformes" },
        { label: "Ajustements mineurs", description: "Quelques modifications à faire" },
        { label: "Non", description: "Refonte des wireframes nécessaire" }
      ],
      multiSelect: false
    },
    {
      question: "Les règles métier (BR-XXX) sont-elles correctes?",
      header: "Règles",
      options: [
        { label: "Oui, correctes", description: "Toutes les règles sont validées" },
        { label: "Corrections mineures", description: "Quelques règles à ajuster" },
        { label: "Non", description: "Règles incorrectes ou manquantes" }
      ],
      multiSelect: false
    },
    {
      question: "Les permissions sont-elles appropriées?",
      header: "Permissions",
      options: [
        { label: "Oui, validées", description: "Matrice permissions OK" },
        { label: "À ajuster", description: "Certains rôles/permissions à modifier" },
        { label: "Non", description: "Permissions à revoir entièrement" }
      ],
      multiSelect: false
    }
  ]
})
```

---

## STEP 4: Traitement de la décision

### Si toutes les réponses sont positives (Oui/Validé)

```bash
# Créer le fichier validation.json
cat > "$FEATURE_DIR/validation.json" << EOF
{
  "featureId": "$FEATURE_ID",
  "validatedAt": "$(date -Iseconds)",
  "validatedBy": "{stakeholder}",
  "status": "APPROVED",
  "documents": {
    "discovery": { "version": "1.0", "status": "approved" },
    "brd": { "version": "1.0", "status": "approved" },
    "frd": { "version": "1.0", "status": "approved" }
  },
  "comments": "",
  "nextStep": "handoff"
}
EOF

echo "✅ VALIDATION APPROUVÉE"
```

**Output:**
```
================================================================================
                    ✅ VALIDATION APPROUVÉE - {FEATURE_ID}
================================================================================

Tous les documents ont été validés par le stakeholder.

DOCUMENTS VERROUILLÉS:
  • 1-discovery.md v1.0 ✅
  • 2-business-requirements.md v1.0 ✅
  • 3-functional-specification.md v1.0 ✅

FICHIER CRÉÉ: validation.json

================================================================================
PROCHAINE ÉTAPE
================================================================================

Générez le prompt de développement:

  /business-analyse:6-handoff {FEATURE_ID}

================================================================================
```

### Si réponses négatives ou partielles

```bash
# Créer le fichier validation.json avec status REJECTED
cat > "$FEATURE_DIR/validation.json" << EOF
{
  "featureId": "$FEATURE_ID",
  "validatedAt": "$(date -Iseconds)",
  "validatedBy": "{stakeholder}",
  "status": "REJECTED",
  "rejectionReasons": {
    "useCases": "{feedback}",
    "wireframes": "{feedback}",
    "businessRules": "{feedback}",
    "permissions": "{feedback}"
  },
  "requiredChanges": [
    "{change 1}",
    "{change 2}"
  ],
  "nextStep": "revise"
}
EOF

echo "❌ VALIDATION REJETÉE - Révision requise"
```

**Output:**
```
================================================================================
                    ❌ VALIDATION REJETÉE - {FEATURE_ID}
================================================================================

Le stakeholder a demandé des révisions.

POINTS À RÉVISER:
  □ Use Cases: {feedback détaillé}
  □ Wireframes: {feedback détaillé}
  □ Règles métier: {feedback détaillé}
  □ Permissions: {feedback détaillé}

FICHIER CRÉÉ: validation.json (status: REJECTED)

================================================================================
ACTION REQUISE
================================================================================

1. Relire le feedback dans validation.json
2. Réviser les documents concernés
3. Relancer les phases appropriées:

   # Si révision majeure (scope change)
   /business-analyse:3-analyse {FEATURE_ID}  # Incrémente version major

   # Si révision mineure (ajustements)
   /business-analyse:4-specify {FEATURE_ID}  # Incrémente version minor

4. Relancer la validation:
   /business-analyse:5-validate {FEATURE_ID}

================================================================================
```

---

## STEP 5: Collecte du feedback détaillé (si rejet)

```javascript
AskUserQuestion({
  questions: [{
    question: "Décrivez les changements nécessaires pour chaque point rejeté:",
    header: "Feedback",
    options: [
      { label: "Fourni ci-dessous", description: "Je vais détailler les changements" },
      { label: "Réunion nécessaire", description: "Je préfère discuter en réunion" }
    ],
    multiSelect: false
  }]
})
```

Si "Fourni ci-dessous":
- Collecter le feedback textuel
- Ajouter au validation.json
- Créer un fichier de tracking pour les changements

---

## Règles de versioning post-validation

| Situation | Action | Nouvelle version |
|-----------|--------|------------------|
| Approuvé | Verrouiller | 1.0 (locked) |
| Rejet mineur | Réviser specify | 1.1 |
| Rejet majeur | Réviser analyse | 2.0 |
| Change request post-handoff | CR process | via CR-FEAT-XXX-001 |

---

## Fichier validation.json

```json
{
  "featureId": "FEAT-XXX",
  "validatedAt": "2024-01-15T14:30:00Z",
  "validatedBy": "product.owner@company.com",
  "status": "APPROVED | REJECTED",
  "documents": {
    "discovery": { "version": "1.0", "status": "approved" },
    "brd": { "version": "1.0", "status": "approved" },
    "frd": { "version": "1.0", "status": "approved | needs_revision" }
  },
  "rejectionReasons": {
    "useCases": "string or null",
    "wireframes": "string or null",
    "businessRules": "string or null",
    "permissions": "string or null"
  },
  "requiredChanges": [],
  "comments": "string",
  "nextStep": "handoff | revise"
}
```

---

## Support

> **Questions sur le processus de validation?**
>
> 📧 **support@atlshub.ch**
