Élicitation des Exigences

Capacités Clés

1. Extraire les Exigences — Identifier les exigences fonctionnelles et non-fonctionnelles à partir de multiples sources
2. Clarifier les Ambiguïtés — Signaler les spécifications peu claires et formuler des questions ciblées
3. Identifier les Contraintes — Trouver les limitations techniques, métier, sécurité et ressources
4. Catégoriser les Exigences — Organiser par type (fonctionnel, non-fonctionnel, sécurité, performance)

Approche

1. Lire et Comprendre

• Lire l'intégralité de la spécification attentivement, incluant tous les documents référencés
• Identifier la source principale (exigence majeure) vs. la documentation de support
• Noter la portée et le contexte de la demande

2. Extraire les Exigences Explicites

• Capturer les exigences clairement énoncées
• Documenter les spécifications exactes (signatures d'API, formats de données, métriques de performance)
• Préserver les détails techniques textuellement

3. Identifier les Exigences Implicites

• Déduire les exigences non énoncées mais nécessaires (gestion d'erreurs, validation, journalisation)
• Considérer les implications de sécurité selon les principes de sécurité Bitwarden (P01-P06)
• Identifier les besoins de classification des données (Vault Data, Protected Data, canaux sécurisés)

4. Signaler les Ambiguïtés et les Lacunes

• Documenter les informations peu claires ou manquantes
• Formuler des questions spécifiques pour résoudre les ambiguïtés
• Identifier les exigences conflictuelles entre sources
• Noter les hypothèses formées

5. Documenter les Contraintes

• Contraintes techniques (APIs, plateformes, compatibilité)
• Contraintes de sécurité (protection des données, authentification, autorisation)
• Contraintes de ressources (performance, stockage, bande passante)
• Contraintes métier (timeline, portée, dépendances)

6. Créer des Critères d'Acceptation

• Pour chaque exigence, définir des critères d'acceptation testables
• Spécifier les méthodes de vérification (commandes, tests, vérifications manuelles)
• Inclure les cas limites et scénarios d'erreur

Considérations Spécifiques à Bitwarden

Exigences de Sécurité

Toujours considérer et documenter :

• Classification des données — S'agit-il de Vault Data, Protected Data ou autre ?
• États des données — Exigences pour les données au repos, en utilisation, en transit
• Canaux de sécurité — Besoin de canaux sécurisés/de confiance ?
• Principes de sécurité — Lesquels (P01-P06) s'appliquent ?
• Scénarios de menace — Que pourrait-il se passer de mal ?

Types d'Exigences Courants chez Bitwarden

• Authentification/Autorisation — Qui peut accéder à quoi ?
• Chiffrement — Quelles données ont besoin de protection et comment ?
• Zero-knowledge — Le serveur ne doit pas avoir accès au texte en clair (P01)
• Multi-plateforme — Fonctionne sur tous les clients Bitwarden ?
• Compatibilité rétroactive — Maintient le comportement existant ?

Exemple

Voir examples/export-functionality.md pour un exemple complet travaillé.

Bonnes Pratiques

À Faire

• ✅ Poser des questions "quoi", pas "comment" — Se concentrer sur les exigences, pas l'implémentation
• ✅ Documenter les hypothèses explicitement — Rendre visibles les connaissances implicites
• ✅ Créer des critères d'acceptation testables — Éviter les mesures de succès vagues
• ✅ Considérer tous les types d'utilisateurs — Utilisateurs gratuits, premium, entreprise, admins
• ✅ Penser aux cas limites — Coffres vides, énormes coffres, défaillances réseau
• ✅ Référencer les principes de sécurité Bitwarden — Ancrer les exigences de sécurité dans P01-P06
• ✅ Utiliser le vocabulaire Bitwarden — Terminologie standard pour les données, canaux, sécurité

À Éviter

• ❌ Éviter : Prendre des décisions techniques d'implémentation — C'est le travail de l'architecte
• ❌ Éviter : Supposer que les exigences non énoncées sont évidentes — L'explicite est préférable
• ❌ Éviter : Des critères d'acceptation génériques — "Ça marche" n'est pas testable
• ❌ Éviter : Ignorer les implications de sécurité — La sécurité n'est jamais optionnelle chez Bitwarden
• ❌ Éviter : Sauter les contraintes — Elles sont aussi importantes que les exigences

Format de Sortie

Organiser les exigences extraites en sections structurées :

## Exigences Fonctionnelles

1. REQ-F-001: [Capacité spécifique que le système doit avoir]
   - **Critères d'Acceptation**: [Condition testable]
   - **Priorité**: Critique | Haute | Moyenne | Basse

## Exigences Non-Fonctionnelles

- **Performance**: [Temps de réponse, débit, utilisation des ressources]
- **Fiabilité**: [Gestion d'erreurs, cas limites, disponibilité]
- **Compatibilité**: [Support de plateforme, compatibilité rétroactive]
- **Utilisabilité**: [Attentes d'expérience utilisateur]

## Exigences de Sécurité

- **Classification des Données**: [Vault Data | Protected Data | Autre]
- **Principes de Sécurité**: [P01, P02, P03, P04, P05, P06 selon applicable]
- **Considérations de Menace**: [Que pourrait-il se passer de mal ?]

## Contraintes

- **Techniques**: [APIs, plateformes, dépendances]
- **Métier**: [Timeline, portée, ressources]
- **Sécurité**: [Conformité, chiffrement, authentification]

## Questions Ouvertes

1. [Question spécifique nécessitant l'avis des parties prenantes]
2. [Ambiguïté nécessitant clarification]
3. [Information manquante qui bloque une spécification complète]

## Hypothèses

- [Hypothèse 1: énoncé explicite de ce qui est supposé]
- [Hypothèse 2: doit être validé avec les parties prenantes]