# Categorie 3 : Perimetre fonctionnel

> **Usage :** Definir ce que le systeme doit faire et ne pas faire, avec des priorites claires
> **Quand charger :** TOUJOURS (noyau)
> **Objectif :** Delimiter le perimetre et hierarchiser les fonctionnalites

---

## 3.1 Les fonctionnalites attendues

> **But :** Lister tout ce que le systeme doit permettre de faire, puis hierarchiser.

| # | Question | Type de reponse |
|---|----------|-----------------|
| Q3.1 | Listez toutes les fonctionnalites que vous souhaitez dans ce systeme. Ne vous censurez pas, notez tout ce qui vous vient a l'esprit. | Liste libre de fonctionnalites |
| Q3.2 | Parmi cette liste, quelles sont les fonctionnalites INDISPENSABLES ? Celles sans lesquelles le systeme n'a aucun interet ? | Liste de fonctionnalites vitales |
| Q3.3 | Quelles fonctionnalites seraient tres utiles mais pourraient attendre une deuxieme version si necessaire ? | Liste de fonctionnalites importantes |
| Q3.4 | Y a-t-il des choses que le systeme ne doit explicitement PAS faire ? Des limites claires a poser ? | Liste d'exclusions |

**Reformulation guidee pour Q3.2 :**
```
question: "Quelles fonctionnalites sont absolument indispensables ?"
header: "Indispensable"
options:
  - label: "Creer et consulter les fiches"
    description: "La base : pouvoir ajouter de nouvelles informations et les retrouver"
  - label: "Suivre l'avancement"
    description: "Voir ou en est chaque element, son statut et son historique"
  - label: "Controler les acces"
    description: "S'assurer que chaque personne ne voit et fait que ce qu'elle a le droit"
  - label: "Generer des rapports"
    description: "Produire des syntheses et des indicateurs pour la prise de decision"
```

**Test de priorite :**
> Pour chaque fonctionnalite classee comme indispensable, poser la question :
> "Si on enlevait cette fonctionnalite, le systeme aurait-il encore de la valeur ?"
> - Si la reponse est "non" : c'est bien indispensable
> - Si la reponse est "oui, mais..." : c'est important mais pas vital

---

## 3.2 Le parcours principal

> **But :** Comprendre le flux de travail principal de bout en bout.

| # | Question | Type de reponse |
|---|----------|-----------------|
| Q3.5 | Decrivez le parcours typique d'un utilisateur du debut a la fin : il ouvre le systeme, que fait-il en premier ? Puis ensuite ? Comment termine-t-il sa tache ? | Liste d'etapes ordonnees |
| Q3.6 | A quels moments l'utilisateur doit-il prendre une decision ? Quelles sont les options possibles a chaque point de decision ? | Points de decision et options |
| Q3.7 | Que se passe-t-il quand quelque chose ne se deroule pas comme prevu ? Quels sont les cas particuliers ou les exceptions ? | Scenarios alternatifs |
| Q3.8 | Que se passe-t-il quand une erreur survient ? Comment l'utilisateur est-il informe ? Que doit-il faire pour corriger ? | Gestion des erreurs |

**Reformulation guidee pour Q3.5 :**
```
question: "Decrivez le parcours typique d'un utilisateur du debut a la fin"
header: "Parcours"
options:
  - label: "Saisie puis validation"
    description: "L'utilisateur cree une fiche, un responsable la valide, elle est publiee"
  - label: "Recherche puis action"
    description: "L'utilisateur cherche une information, puis effectue une action dessus"
  - label: "Reception puis traitement"
    description: "Une demande arrive, l'utilisateur la traite etape par etape"
  - label: "Suivi continu"
    description: "L'utilisateur surveille un tableau de bord et intervient quand necessaire"
```

---

## 3.3 Les besoins transversaux

> **But :** Identifier les fonctionnalites qui traversent tout le systeme.

| # | Question | Type de reponse |
|---|----------|-----------------|
| Q3.9 | Les utilisateurs ont-ils besoin de recevoir des notifications ou des alertes ? Si oui, dans quelles situations ? | Liste de situations de notification |
| Q3.10 | Faut-il pouvoir exporter des donnees du systeme (rapports, fichiers, impressions) ? Dans quel format et pour qui ? | Besoins d'export |
| Q3.11 | Faut-il pouvoir importer des donnees dans le systeme depuis une source externe (fichiers, autres logiciels) ? | Besoins d'import |
| Q3.12 | Faut-il garder un historique de qui a fait quoi et quand ? Pour quelles actions ? | Besoins de tracabilite |

**Reformulation guidee pour Q3.9 :**
```
question: "Les utilisateurs ont-ils besoin de recevoir des notifications ou des alertes ?"
header: "Alertes"
options:
  - label: "Oui, en temps reel"
    description: "Notifications instantanees quand quelque chose de nouveau arrive ou change"
  - label: "Oui, par email"
    description: "Recapitulatif par email quotidien ou a chaque evenement important"
  - label: "Oui, les deux"
    description: "Notification en temps reel dans l'application et recapitulatif par email"
  - label: "Non, pas necessaire"
    description: "Les utilisateurs consulteront le systeme de leur propre initiative"
```

---

## Guide d'elicitation approfondi

### Techniques de relance par question

| Question | Si la reponse est vague ou insuffisante | Relance recommandee |
|----------|----------------------------------------|---------------------|
| Q3.1 (liste de fonctionnalites) | Moins de 5 elements | "Pensez a une journee complete de travail. De l'ouverture de session a la fermeture, quelles actions devriez-vous pouvoir faire ? Creation ? Recherche ? Modification ? Exportation ? Suivi ?" |
| Q3.2 (indispensable) | Tout est marque comme indispensable | "Si vous ne pouviez garder que 3 fonctionnalites pour un premier lancement, lesquelles choisiriez-vous ? Les autres sont tres importantes mais pourraient venir dans un second temps." |
| Q3.4 (exclusions) | "Je ne vois pas" | "Certains utilisateurs pourraient-ils s'attendre a des fonctionnalites que vous ne souhaitez PAS inclure ? Par exemple : gestion financiere, messagerie integree, application mobile ?" |
| Q3.5 (parcours principal) | Moins de 3 etapes | "Detaillons : l'utilisateur arrive sur l'ecran d'accueil. Que voit-il ? Ou clique-t-il ? Que remplit-il ? Que se passe-t-il quand il valide ? Qui est notifie ?" |
| Q3.6 (decisions) | "Il n'y a pas vraiment de choix" | "A chaque etape, l'utilisateur peut-il annuler ? Revenir en arriere ? Sauvegarder en brouillon ? Deleguer a quelqu'un d'autre ?" |
| Q3.7 (cas particuliers) | "Il n'y en a pas" | "Que se passe-t-il si l'utilisateur n'a pas toutes les informations ? Si une donnee est incorrecte ? Si deux personnes modifient la meme fiche en meme temps ?" |
| Q3.8 (erreurs) | "On verra" | "Prenons un exemple : l'utilisateur oublie un champ obligatoire. Le systeme le bloque ? L'avertit ? Le laisse continuer avec un rappel plus tard ?" |
| Q3.9 (notifications) | Reponse vague | "Quand un element change de statut, qui doit etre prevenu ? Quand une action urgente est requise, comment l'utilisateur le sait-il aujourd'hui ?" |
| Q3.12 (tracabilite) | "On ne sait pas" | "Si dans 6 mois quelqu'un demande 'Qui a modifie cette fiche et pourquoi ?', devez-vous pouvoir repondre ?" |

### Signaux d'alerte a detecter

| Signal du client | Probleme sous-jacent | Action de l'analyste |
|------------------|---------------------|----------------------|
| Tout est indispensable (> 10 elements vitaux) | **Priorites non definies** | Appliquer le test : "Si on enlevait cette fonctionnalite, le systeme aurait-il encore de la valeur ?" |
| Aucune exclusion identifiee | **Perimetre non borne** | "Y a-t-il des aspects qui relevent d'un autre projet, d'un autre service, ou d'une version future ?" |
| Parcours lineaire sans alternative | **Seul le cas ideal est decrit** | "Que se passe-t-il a l'etape X si la condition Y n'est pas remplie ? Si l'utilisateur change d'avis ?" |
| Melange fonctionnel et technique | **Solution dans le perimetre** | Separer : "gerer les commandes" (ce que fait le systeme) est fonctionnel, "utiliser tel outil" (comment il le fait) est technique |
| Fonctionnalites tres detaillees pour certains sujets et vagues pour d'autres | **Expertise inegale** | Approfondir les zones vagues : "Ce sujet semble moins detaille. Est-ce parce qu'il est moins important ou parce qu'il est moins bien connu ?" |

### Regles d'enchainement

| Apres | Si la reponse indique... | Alors |
|-------|-------------------------|-------|
| Q3.1 | Plus de 15 fonctionnalites | Passer plus de temps sur Q3.2 pour hierarchiser |
| Q3.2 | Plus de 10 elements indispensables | Challenger chaque element avec le test de priorite |
| Q3.5 | Parcours avec approbation | Charger les questions de workflow (categorie 11 cycle de vie) |
| Q3.7 | Beaucoup de cas particuliers | Prevoir de la complexite dans l'estimation des modules |
| Q3.9 | Notifications en temps reel souhaitees | Noter pour la specification : integration de notifications |
| Q3.11 | Import de donnees existantes | Charger le questionnaire de migration (categorie 12) |
| Q3.12 | Tracabilite requise | Noter pour la specification : journal d'activite |

---

## Mapping vers le cadrage

| Reponse | Alimente |
|---------|----------|
| Q3.1, Q3.2, Q3.3 | `cadrage.globalScope` (indispensable, important, optionnel, hors perimetre) |
| Q3.4 | `cadrage.globalScope.outOfScope` |
| Q3.5, Q3.6, Q3.7, Q3.8 | `cadrage.coverageMatrix` + base pour les cas d'utilisation |
| Q3.9, Q3.10, Q3.11, Q3.12 | `cadrage.coverageMatrix` + detection de modules transversaux |

---

## Strategie de questionnement

### Ordre des questions en 3 lots

**Lot 1 (Q3.1, Q3.2, Q3.3, Q3.4) : Quoi et dans quel ordre ?**
- Commencer par un brainstorming libre (Q3.1) puis hierarchiser
- Bien definir les limites (Q3.4) pour eviter les derives

**Lot 2 (Q3.5, Q3.6, Q3.7, Q3.8) : Comment ca se deroule ?**
- Cartographier le parcours principal puis les variantes
- Ne pas accepter un parcours uniquement ideal

**Lot 3 (Q3.9, Q3.10, Q3.11, Q3.12) : Quels besoins transversaux ?**
- Identifier les fonctionnalites qui traversent tout le systeme
- Ces reponses orientent le choix des questionnaires conditionnels
