@atlashub/smartstack-cli 4.28.0 → 4.30.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.documentation/business-analyse.html +217 -0
- package/package.json +1 -1
- package/templates/skills/apex/references/frontend-route-wiring-app-tsx.md +29 -7
- package/templates/skills/apex/references/post-checks.md +42 -0
- package/templates/skills/apex/references/smartstack-frontend.md +23 -8
- package/templates/skills/apex/references/smartstack-layers.md +35 -19
- package/templates/skills/apex/steps/step-03-execute.md +10 -1
- package/templates/skills/apex/steps/step-04-examine.md +4 -0
- package/templates/skills/ba-generate-html/html/ba-interactive.html +207 -199
- package/templates/skills/ba-generate-html/html/src/partials/cadrage-context.html +9 -9
- package/templates/skills/ba-generate-html/html/src/partials/cadrage-scope.html +15 -15
- package/templates/skills/ba-generate-html/html/src/partials/cadrage-stakeholders.html +7 -7
- package/templates/skills/ba-generate-html/html/src/partials/cadrage-success.html +13 -13
- package/templates/skills/ba-generate-html/html/src/partials/consol-datamodel.html +4 -4
- package/templates/skills/ba-generate-html/html/src/partials/consol-flows.html +5 -5
- package/templates/skills/ba-generate-html/html/src/partials/consol-interactions.html +2 -2
- package/templates/skills/ba-generate-html/html/src/partials/consol-permissions.html +4 -4
- package/templates/skills/ba-generate-html/html/src/partials/decomp-dependencies.html +11 -11
- package/templates/skills/ba-generate-html/html/src/partials/decomp-modules.html +9 -9
- package/templates/skills/ba-generate-html/html/src/partials/handoff-summary.html +5 -5
- package/templates/skills/ba-generate-html/html/src/scripts/01-data-init.js +10 -2
- package/templates/skills/ba-generate-html/html/src/scripts/02-navigation.js +10 -10
- package/templates/skills/ba-generate-html/html/src/scripts/03-render-cadrage.js +1 -1
- package/templates/skills/ba-generate-html/html/src/scripts/04-render-modules.js +4 -4
- package/templates/skills/ba-generate-html/html/src/scripts/05-render-specs.js +57 -57
- package/templates/skills/ba-generate-html/html/src/scripts/06-render-consolidation.js +4 -4
- package/templates/skills/ba-generate-html/html/src/scripts/06-render-mockups.js +5 -5
- package/templates/skills/ba-generate-html/html/src/scripts/07-render-handoff.js +8 -8
- package/templates/skills/ba-generate-html/html/src/scripts/08-editing.js +3 -3
- package/templates/skills/ba-generate-html/html/src/scripts/09-export.js +2 -2
- package/templates/skills/ba-generate-html/html/src/scripts/10-comments.js +2 -2
- package/templates/skills/ba-generate-html/html/src/scripts/11-review-panel.js +8 -8
- package/templates/skills/ba-generate-html/html/src/styles/03-navigation.css +1 -1
- package/templates/skills/ba-generate-html/html/src/template.html +92 -92
- package/templates/skills/ba-generate-html/steps/step-02-build-data.md +5 -1
- package/templates/skills/business-analyse/questionnaire/01-context.md +12 -12
- package/templates/skills/business-analyse/questionnaire/02-stakeholders-scope.md +45 -45
- package/templates/skills/business-analyse/questionnaire/03-data-ui.md +39 -39
- package/templates/skills/business-analyse/questionnaire/05-cross-module.md +32 -32
- package/templates/skills/business-analyse/questionnaire.md +11 -11
- package/templates/skills/business-analyse/steps/step-00-init.md +2 -2
- package/templates/skills/business-analyse/steps/step-01-cadrage.md +3 -3
- package/templates/skills/business-analyse/steps/step-02-structure.md +2 -2
- package/templates/skills/business-analyse/steps/step-03-specify.md +15 -15
|
@@ -1,56 +1,56 @@
|
|
|
1
|
-
#
|
|
1
|
+
# Catégorie 2 : Parties prenantes et périmètre
|
|
2
2
|
|
|
3
|
-
> **Usage :** Identifier les profils utilisateurs, leurs droits, et
|
|
3
|
+
> **Usage :** Identifier les profils utilisateurs, leurs droits, et délimiter le périmètre fonctionnel
|
|
4
4
|
> **Quand charger :** TOUJOURS (noyau)
|
|
5
|
-
> **Objectif :** Comprendre QUI utilise le
|
|
5
|
+
> **Objectif :** Comprendre QUI utilise le système, avec quels DROITS, et QUOI il doit faire
|
|
6
6
|
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
## 2.1 Identification des utilisateurs
|
|
10
10
|
|
|
11
|
-
> **But :** Identifier les types de profils/
|
|
11
|
+
> **But :** Identifier les types de profils/rôles qui interagiront avec le système.
|
|
12
12
|
|
|
13
|
-
| # | Question | Type de
|
|
13
|
+
| # | Question | Type de réponse |
|
|
14
14
|
|---|----------|-----------------|
|
|
15
|
-
| Q2.1 | Qui sont les types de profils qui utiliseront ce
|
|
15
|
+
| Q2.1 | Qui sont les types de profils qui utiliseront ce système ? Décrivez leurs rôles et ce qu'ils font. | Liste de profils utilisateurs |
|
|
16
16
|
|
|
17
17
|
---
|
|
18
18
|
|
|
19
|
-
## 2.2
|
|
19
|
+
## 2.2 Tâches par profil
|
|
20
20
|
|
|
21
|
-
> **But :** Comprendre
|
|
21
|
+
> **But :** Comprendre concrètement ce que chaque type d'utilisateur fait.
|
|
22
22
|
|
|
23
|
-
| # | Question | Type de
|
|
23
|
+
| # | Question | Type de réponse |
|
|
24
24
|
|---|----------|-----------------|
|
|
25
|
-
| Q2.5 | Pour chaque type d'utilisateur : quelles sont les 3
|
|
25
|
+
| Q2.5 | Pour chaque type d'utilisateur : quelles sont les 3 à 5 tâches principales qu'il doit accomplir avec ce système ? | Tâches par profil utilisateur |
|
|
26
26
|
|
|
27
27
|
---
|
|
28
28
|
|
|
29
|
-
## 2.3 Les niveaux d'
|
|
29
|
+
## 2.3 Les niveaux d'accès
|
|
30
30
|
|
|
31
|
-
> **But :**
|
|
31
|
+
> **But :** Définir qui peut voir quoi et faire quoi.
|
|
32
32
|
|
|
33
|
-
| # | Question | Type de
|
|
33
|
+
| # | Question | Type de réponse |
|
|
34
34
|
|---|----------|-----------------|
|
|
35
|
-
| Q2.9 | Tous les utilisateurs doivent-ils voir les
|
|
36
|
-
| Q2.10 | Qui a le droit de modifier ou supprimer des informations ? Tout le monde ou seulement certaines personnes ? |
|
|
37
|
-
| Q2.11 | Y a-t-il des actions sensibles qui
|
|
35
|
+
| Q2.9 | Tous les utilisateurs doivent-ils voir les mêmes informations ? Si non, qui voit quoi ? | Règles de visibilité des données |
|
|
36
|
+
| Q2.10 | Qui a le droit de modifier ou supprimer des informations ? Tout le monde ou seulement certaines personnes ? | Règles de modification |
|
|
37
|
+
| Q2.11 | Y a-t-il des actions sensibles qui nécessitent une validation par un supérieur ? | Liste des actions à valider |
|
|
38
38
|
|
|
39
39
|
---
|
|
40
40
|
|
|
41
|
-
## 2.4
|
|
41
|
+
## 2.4 Périmètre fonctionnel
|
|
42
42
|
|
|
43
|
-
> **But :** Lister tout ce que le
|
|
43
|
+
> **But :** Lister tout ce que le système doit faire et ne pas faire, avec des priorités claires.
|
|
44
44
|
|
|
45
|
-
| # | Question | Type de
|
|
45
|
+
| # | Question | Type de réponse |
|
|
46
46
|
|---|----------|-----------------|
|
|
47
|
-
| Q2.12 | Listez toutes les
|
|
48
|
-
| Q2.13 | Parmi cette liste, quelles sont les
|
|
49
|
-
| Q2.15 | Y a-t-il des choses que le
|
|
47
|
+
| Q2.12 | Listez toutes les fonctionnalités que vous souhaitez dans ce système. Ne vous censurez pas. | Liste libre de fonctionnalités |
|
|
48
|
+
| Q2.13 | Parmi cette liste, quelles sont les fonctionnalités INDISPENSABLES ? Celles sans lesquelles le système n'a aucun intérêt ? | Liste de fonctionnalités vitales |
|
|
49
|
+
| Q2.15 | Y a-t-il des choses que le système ne doit explicitement PAS faire ? Des limites claires à poser ? | Liste d'exclusions |
|
|
50
50
|
|
|
51
|
-
**Test de
|
|
52
|
-
> Pour chaque
|
|
53
|
-
> "Si on enlevait cette
|
|
51
|
+
**Test de priorité :**
|
|
52
|
+
> Pour chaque fonctionnalité classée comme indispensable, poser la question :
|
|
53
|
+
> "Si on enlevait cette fonctionnalité, le système aurait-il encore de la valeur ?"
|
|
54
54
|
|
|
55
55
|
---
|
|
56
56
|
|
|
@@ -58,42 +58,42 @@
|
|
|
58
58
|
|
|
59
59
|
> **But :** Comprendre le flux de travail principal de bout en bout.
|
|
60
60
|
|
|
61
|
-
| # | Question | Type de
|
|
61
|
+
| # | Question | Type de réponse |
|
|
62
62
|
|---|----------|-----------------|
|
|
63
|
-
| Q2.16 |
|
|
64
|
-
| Q2.17 |
|
|
65
|
-
| Q2.18 | Que se passe-t-il quand quelque chose ne se
|
|
63
|
+
| Q2.16 | Décrivez le parcours typique d'un utilisateur du début à la fin : il ouvre le système, que fait-il en premier ? | Liste d'étapes ordonnées |
|
|
64
|
+
| Q2.17 | À quels moments l'utilisateur doit-il prendre une décision ? Quelles sont les options possibles ? | Points de décision et options |
|
|
65
|
+
| Q2.18 | Que se passe-t-il quand quelque chose ne se déroule pas comme prévu ? Quels sont les cas particuliers ? | Scénarios alternatifs |
|
|
66
66
|
|
|
67
67
|
---
|
|
68
68
|
|
|
69
|
-
## Guide d'
|
|
69
|
+
## Guide d'élicitation approfondi
|
|
70
70
|
|
|
71
71
|
### Techniques de relance
|
|
72
72
|
|
|
73
|
-
| Question | Si la
|
|
73
|
+
| Question | Si la réponse est vague | Relance recommandée |
|
|
74
74
|
|----------|------------------------|---------------------|
|
|
75
|
-
| Q2.1 (utilisateurs) | Un seul type
|
|
76
|
-
| Q2.5 (
|
|
77
|
-
| Q2.9 (
|
|
78
|
-
| Q2.13 (indispensable) | Tout est indispensable | "Si vous ne pouviez garder que 3
|
|
79
|
-
| Q2.15 (exclusions) | "Je ne vois pas" | "Certains utilisateurs pourraient-ils s'attendre
|
|
80
|
-
| Q2.16 (parcours) | Moins de 3
|
|
75
|
+
| Q2.1 (utilisateurs) | Un seul type mentionné | "Pensez aux différents moments de la journée : qui saisit ? Qui consulte les rapports ? Qui gère les cas particuliers ?" |
|
|
76
|
+
| Q2.5 (tâches) | Tâches génériques | "Quand il arrive le matin et ouvre le système, quelle est sa première action ?" |
|
|
77
|
+
| Q2.9 (visibilité) | Réponse ambiguë | "Un employé du service A peut-il voir les données du service B ? Un stagiaire voit-il la même chose qu'un directeur ?" |
|
|
78
|
+
| Q2.13 (indispensable) | Tout est indispensable | "Si vous ne pouviez garder que 3 fonctionnalités pour un premier lancement, lesquelles ?" |
|
|
79
|
+
| Q2.15 (exclusions) | "Je ne vois pas" | "Certains utilisateurs pourraient-ils s'attendre à des fonctionnalités que vous ne souhaitez PAS inclure ?" |
|
|
80
|
+
| Q2.16 (parcours) | Moins de 3 étapes | "Détaillons : l'utilisateur arrive sur l'écran d'accueil. Que voit-il ? Où clique-t-il ?" |
|
|
81
81
|
|
|
82
|
-
### Signaux d'alerte
|
|
82
|
+
### Signaux d'alerte à détecter
|
|
83
83
|
|
|
84
|
-
| Signal du client |
|
|
84
|
+
| Signal du client | Problème sous-jacent | Action de l'analyste |
|
|
85
85
|
|------------------|---------------------|----------------------|
|
|
86
|
-
| "Tous les utilisateurs font la
|
|
87
|
-
| "Tout le monde doit tout voir" |
|
|
88
|
-
| Tout est indispensable (> 10 vitaux) |
|
|
89
|
-
| Aucune exclusion
|
|
90
|
-
| Parcours
|
|
86
|
+
| "Tous les utilisateurs font la même chose" | Rôles non différenciés | "Qui peut supprimer ? Qui ne fait que consulter ? Qui valide ?" |
|
|
87
|
+
| "Tout le monde doit tout voir" | Sécurité non réfléchie | "Même les stagiaires ? Les prestataires externes ? Les données salariales ?" |
|
|
88
|
+
| Tout est indispensable (> 10 vitaux) | Priorités non définies | Appliquer le test de priorité |
|
|
89
|
+
| Aucune exclusion identifiée | Périmètre non borné | "Y a-t-il des aspects qui relèvent d'un autre projet ou d'une version future ?" |
|
|
90
|
+
| Parcours linéaire sans alternative | Seul le cas idéal est décrit | "Que se passe-t-il à l'étape X si la condition Y n'est pas remplie ?" |
|
|
91
91
|
|
|
92
92
|
---
|
|
93
93
|
|
|
94
94
|
## Mapping vers le cadrage
|
|
95
95
|
|
|
96
|
-
|
|
|
96
|
+
| Réponse | Alimente |
|
|
97
97
|
|---------|----------|
|
|
98
98
|
| Q2.1, Q2.5 | `cadrage.stakeholders[]` |
|
|
99
99
|
| Q2.9-Q2.11 | `cadrage.applicationRoles[]` |
|
|
@@ -1,8 +1,8 @@
|
|
|
1
|
-
#
|
|
1
|
+
# Catégorie 3 : Données et interface
|
|
2
2
|
|
|
3
|
-
> **Usage :**
|
|
4
|
-
> **Quand charger :** Par module, lors de la
|
|
5
|
-
> **Objectif :** Comprendre les
|
|
3
|
+
> **Usage :** Définir les entités, les règles de données et l'expérience utilisateur
|
|
4
|
+
> **Quand charger :** Par module, lors de la spécification (step-03)
|
|
5
|
+
> **Objectif :** Comprendre les données manipulées et comment elles sont présentées
|
|
6
6
|
|
|
7
7
|
---
|
|
8
8
|
|
|
@@ -10,69 +10,69 @@
|
|
|
10
10
|
|
|
11
11
|
| # | Question | Type de reponse |
|
|
12
12
|
|---|----------|-----------------|
|
|
13
|
-
| Q3.1 | Quelles sont les
|
|
14
|
-
| Q3.2 | Pour chaque
|
|
15
|
-
| Q3.3 | Quelles relations existent entre les
|
|
16
|
-
| Q3.5 | Pour chaque
|
|
17
|
-
| Q3.6 | Si auto-
|
|
13
|
+
| Q3.1 | Quelles sont les entités principales gérées par ce module ? | Liste d'entités |
|
|
14
|
+
| Q3.2 | Pour chaque entité : quels sont les attributs importants ? | Par entité |
|
|
15
|
+
| Q3.3 | Quelles relations existent entre les entités ? (appartient à, contient, référence) | Schéma relationnel |
|
|
16
|
+
| Q3.5 | Pour chaque entité : le Code doit-il être auto-généré ou saisi par l'utilisateur ? | Par entité |
|
|
17
|
+
| Q3.6 | Si auto-généré : quelle stratégie ? (séquentiel, timestamp, année, UUID court) | Par entité |
|
|
18
18
|
|
|
19
|
-
## 3.2
|
|
19
|
+
## 3.2 Règles de données
|
|
20
20
|
|
|
21
|
-
| # | Question | Type de
|
|
21
|
+
| # | Question | Type de réponse |
|
|
22
22
|
|---|----------|-----------------|
|
|
23
|
-
| Q3.7 | Quelles validations sur les
|
|
24
|
-
| Q3.8 | Y a-t-il des
|
|
25
|
-
| Q3.9 |
|
|
23
|
+
| Q3.7 | Quelles validations sur les données ? (champs obligatoires, formats, plages de valeurs) | Liste de règles |
|
|
24
|
+
| Q3.8 | Y a-t-il des règles inter-champs ? (date fin > date début, montant selon statut) | Liste de contraintes |
|
|
25
|
+
| Q3.9 | Données sensibles à protéger ? (données personnelles, financières, médicales) | Liste + niveau |
|
|
26
26
|
|
|
27
27
|
---
|
|
28
28
|
|
|
29
|
-
## 3.3 Interface et
|
|
29
|
+
## 3.3 Interface et écrans
|
|
30
30
|
|
|
31
|
-
| # | Question | Type de
|
|
31
|
+
| # | Question | Type de réponse |
|
|
32
32
|
|---|----------|-----------------|
|
|
33
|
-
| Q3.10 |
|
|
34
|
-
| Q3.11 |
|
|
35
|
-
| Q3.12 | Informations
|
|
36
|
-
| Q3.13 | Actions possibles par
|
|
33
|
+
| Q3.10 | Périphériques cibles ? (desktop, mobile, tablette) | Liste |
|
|
34
|
+
| Q3.11 | Écrans principaux nécessaires pour ce module ? | Liste d'écrans |
|
|
35
|
+
| Q3.12 | Informations clés par écran ? Quelles colonnes dans la liste, quels champs dans le formulaire ? | Par écran |
|
|
36
|
+
| Q3.13 | Actions possibles par écran ? (créer, éditer, supprimer, valider, exporter, changer statut) | Par écran |
|
|
37
37
|
|
|
38
38
|
## 3.4 Tableaux de bord
|
|
39
39
|
|
|
40
|
-
| # | Question | Type de
|
|
40
|
+
| # | Question | Type de réponse |
|
|
41
41
|
|---|----------|-----------------|
|
|
42
42
|
| Q3.14 | Des tableaux de bord ou indicateurs sont-ils requis pour ce module ? | Oui/Non + description |
|
|
43
|
-
| Q3.15 | KPIs
|
|
44
|
-
| Q3.16 | Types de graphiques
|
|
43
|
+
| Q3.15 | KPIs à afficher ? (nom, métrique, format, seuils d'alerte) | Par dashboard |
|
|
44
|
+
| Q3.16 | Types de graphiques souhaités ? (barres, lignes, camembert, cartes KPI) | Par KPI |
|
|
45
45
|
|
|
46
46
|
---
|
|
47
47
|
|
|
48
|
-
## Guide d'
|
|
48
|
+
## Guide d'élicitation approfondi
|
|
49
49
|
|
|
50
50
|
### Techniques de relance
|
|
51
51
|
|
|
52
|
-
| Question | Si la
|
|
52
|
+
| Question | Si la réponse est vague | Relance recommandée |
|
|
53
53
|
|----------|------------------------|---------------------|
|
|
54
|
-
| Q3.1 (
|
|
55
|
-
| Q3.1 (
|
|
56
|
-
| Q3.2 (attributs) | Champs techniques (ID, CreatedDate) | "Les champs techniques sont auto-
|
|
57
|
-
| Q3.3 (relations) | "1:N" sans
|
|
58
|
-
| Q3.11 (
|
|
59
|
-
| Q3.13 (actions) | "CRUD classique" | "Actions
|
|
54
|
+
| Q3.1 (entités) | Une seule entité | "Cette entité a-t-elle des sous-éléments ? (lignes de détail, pièces jointes, historique)" |
|
|
55
|
+
| Q3.1 (entités) | Mention de "User" | "L'utilisateur est géré par la plateforme. Décrivez l'entité MÉTIER (Client, Employee, Contact...)" |
|
|
56
|
+
| Q3.2 (attributs) | Champs techniques (ID, CreatedDate) | "Les champs techniques sont auto-gérés. Quels sont les attributs MÉTIER ?" |
|
|
57
|
+
| Q3.3 (relations) | "1:N" sans détail | "Un {Parent} peut avoir combien de {Children} max ? Un {Child} peut-il exister sans {Parent} ?" |
|
|
58
|
+
| Q3.11 (écrans) | "Un écran de liste" | "Avec pages dédiées pour création et édition ? Détail en page avec onglets ?" |
|
|
59
|
+
| Q3.13 (actions) | "CRUD classique" | "Actions métier spécifiques ? (valider, dupliquer, archiver, changer statut, assigner)" |
|
|
60
60
|
| Q3.14 (dashboards) | "Juste des chiffres" | "Les tendances ne seraient-elles pas plus lisibles en graphique ?" |
|
|
61
61
|
|
|
62
|
-
### Anti-patterns
|
|
62
|
+
### Anti-patterns à détecter
|
|
63
63
|
|
|
64
64
|
| Signal | Anti-pattern | Action |
|
|
65
65
|
|--------|-------------|--------|
|
|
66
|
-
|
|
|
67
|
-
| Attributs Id, TenantId, CreatedBy | Champs techniques comme
|
|
66
|
+
| Entité "User" avec attributs métier | Confusion User/Identity | La plateforme gère les Users via Identity |
|
|
67
|
+
| Attributs Id, TenantId, CreatedBy | Champs techniques comme métier | Ces champs sont auto-générés par AuditableEntity |
|
|
68
68
|
| "Un seul gros formulaire avec tout" | Formulaire monolithique | Proposer des onglets ou wizard par section logique |
|
|
69
|
-
| Actions sans confirmation | Actions destructives non
|
|
69
|
+
| Actions sans confirmation | Actions destructives non protégées | "La suppression nécessite-t-elle une confirmation ?" |
|
|
70
70
|
|
|
71
71
|
---
|
|
72
72
|
|
|
73
73
|
## RBAC Exclusion
|
|
74
74
|
|
|
75
|
-
> Les concepts suivants sont
|
|
75
|
+
> Les concepts suivants sont gérés par le système RBAC de la plateforme et NE DOIVENT PAS être modélisés comme attributs d'entité :
|
|
76
76
|
|
|
77
77
|
| Concept | Wrong (attribut) | Correct (RBAC) |
|
|
78
78
|
|---------|-----------------|----------------|
|
|
@@ -84,9 +84,9 @@
|
|
|
84
84
|
|
|
85
85
|
## Mapping vers le feature
|
|
86
86
|
|
|
87
|
-
|
|
|
87
|
+
| Réponse | Alimente |
|
|
88
88
|
|---------|----------|
|
|
89
|
-
| Q3.1-Q3.3, Q3.5-Q3.6 | `entities.json` (
|
|
90
|
-
| Q3.7-Q3.9 | `rules.json` (
|
|
89
|
+
| Q3.1-Q3.3, Q3.5-Q3.6 | `entities.json` (entités, attributs, relations, codePattern) |
|
|
90
|
+
| Q3.7-Q3.9 | `rules.json` (règles métier de validation et sécurité) |
|
|
91
91
|
| Q3.10-Q3.13 | `screens.json` (sections, resources, colonnes, actions) |
|
|
92
92
|
| Q3.14-Q3.16 | `screens.json` (sections dashboard, KPI resources) |
|
|
@@ -1,28 +1,28 @@
|
|
|
1
|
-
#
|
|
1
|
+
# Catégorie 5 : Impact cross-module
|
|
2
2
|
|
|
3
|
-
> **Usage :** Analyser l'impact sur les modules existants et les
|
|
4
|
-
> **Quand charger :** TOUJOURS pour les nouveaux modules (pas les
|
|
5
|
-
> **Objectif :**
|
|
3
|
+
> **Usage :** Analyser l'impact sur les modules existants et les dépendances partagées
|
|
4
|
+
> **Quand charger :** TOUJOURS pour les nouveaux modules (pas les améliorations)
|
|
5
|
+
> **Objectif :** Détecter les interactions, les entités partagées et les impacts d'intégration
|
|
6
6
|
|
|
7
7
|
---
|
|
8
8
|
|
|
9
|
-
## 5.1
|
|
9
|
+
## 5.1 Dépendances avec les modules existants
|
|
10
10
|
|
|
11
|
-
| # | Question | Type de
|
|
11
|
+
| # | Question | Type de réponse |
|
|
12
12
|
|---|----------|-----------------|
|
|
13
13
|
| Q5.1 | Avec quels modules existants ce nouveau module interagit-il ? | Liste de modules |
|
|
14
|
-
| Q5.2 | Quelles
|
|
15
|
-
| Q5.3 | Y a-t-il des
|
|
16
|
-
| Q5.4 | Ce module produira-t-il des
|
|
14
|
+
| Q5.2 | Quelles données sont partagées entre modules ? (entités, tables de référence) | Par module |
|
|
15
|
+
| Q5.3 | Y a-t-il des entités existantes que ce module va référencer ? (relations FK) | Liste de références |
|
|
16
|
+
| Q5.4 | Ce module produira-t-il des événements que d'autres modules consomment ? | Liste d'événements |
|
|
17
17
|
|
|
18
|
-
## 5.2
|
|
18
|
+
## 5.2 Évaluation d'impact
|
|
19
19
|
|
|
20
|
-
| # | Question | Type de
|
|
20
|
+
| # | Question | Type de réponse |
|
|
21
21
|
|---|----------|-----------------|
|
|
22
|
-
| Q5.5 | Les modules existants doivent-ils
|
|
23
|
-
| Q5.6 | Y a-t-il des composants UI ou des changements de navigation
|
|
24
|
-
| Q5.7 | Ce module affectera-t-il les permissions ou
|
|
25
|
-
| Q5.8 | Y a-t-il des
|
|
22
|
+
| Q5.5 | Les modules existants doivent-ils être modifiés pour supporter ce nouveau module ? | Liste de changements |
|
|
23
|
+
| Q5.6 | Y a-t-il des composants UI ou des changements de navigation partagés ? | Liste |
|
|
24
|
+
| Q5.7 | Ce module affectera-t-il les permissions ou rôles existants ? Quel impact sur l'intégration ? | Oui/Non + détail |
|
|
25
|
+
| Q5.8 | Y a-t-il des entités partagées modifiées par plusieurs modules ? Quel impact sur l'intégration ? | Évaluation de l'impact |
|
|
26
26
|
|
|
27
27
|
---
|
|
28
28
|
|
|
@@ -30,40 +30,40 @@
|
|
|
30
30
|
|
|
31
31
|
| Besoin | Pattern | Exemple |
|
|
32
32
|
|--------|---------|---------|
|
|
33
|
-
|
|
|
34
|
-
|
|
|
35
|
-
| Notification
|
|
36
|
-
|
|
|
33
|
+
| Référence une entité | Navigation property + FK | `Order.ClientId -> Client` |
|
|
34
|
+
| Données de référence partagées | Entité partagée dans Domain | `Status`, `Category` |
|
|
35
|
+
| Notification événementielle | MediatR notification | `OrderCreatedNotification` |
|
|
36
|
+
| Requête cross-module | DTO en lecture seule | `IClientQueryService` |
|
|
37
37
|
| Lien de navigation | NavRoute entry | `business/{app}/{module}` |
|
|
38
|
-
| Permission
|
|
38
|
+
| Permission partagée | Hiérarchie de permissions | `{app}.*` covers all modules |
|
|
39
39
|
|
|
40
40
|
---
|
|
41
41
|
|
|
42
|
-
## Guide d'
|
|
42
|
+
## Guide d'élicitation
|
|
43
43
|
|
|
44
44
|
### Techniques de relance
|
|
45
45
|
|
|
46
|
-
| Question | Si la
|
|
46
|
+
| Question | Si la réponse est vague | Relance recommandée |
|
|
47
47
|
|----------|------------------------|---------------------|
|
|
48
|
-
| Q5.1 (interactions) | "Aucun" | "Ce module est totalement
|
|
49
|
-
| Q5.2 (
|
|
50
|
-
| Q5.3 (FK
|
|
51
|
-
| Q5.4 (
|
|
52
|
-
| Q5.8 (impact) | "Pas d'impact" | "Deux modules modifient-ils la
|
|
48
|
+
| Q5.1 (interactions) | "Aucun" | "Ce module est totalement isolé ? Pas de lien avec des clients, produits, utilisateurs d'autres modules ?" |
|
|
49
|
+
| Q5.2 (données partagées) | "Je ne sais pas" | Utiliser le `{codebase_context}` : "J'ai trouvé les entités {list}. Ce module a-t-il besoin de les référencer ?" |
|
|
50
|
+
| Q5.3 (FK références) | Vague | "Une {entity} de ce module appartient-elle à un {existing_entity} ?" |
|
|
51
|
+
| Q5.4 (événements) | "Non" | "Quand un {entity} est créé/modifié/supprimé, faut-il notifier un autre module ?" |
|
|
52
|
+
| Q5.8 (impact) | "Pas d'impact" | "Deux modules modifient-ils la même entité ? Quel est l'impact sur l'intégration ?" |
|
|
53
53
|
|
|
54
|
-
### Anti-patterns
|
|
54
|
+
### Anti-patterns à détecter
|
|
55
55
|
|
|
56
56
|
| Signal | Anti-pattern | Action |
|
|
57
57
|
|--------|-------------|--------|
|
|
58
|
-
| Module totalement
|
|
59
|
-
| Duplication d'
|
|
60
|
-
| Modification d'
|
|
58
|
+
| Module totalement isolé | Silo de données | Rare qu'un module métier n'ait aucune connexion. Vérifier avec le codebase context. |
|
|
59
|
+
| Duplication d'entité existante | Entité dupliquée | Si `Client` existe déjà, ne pas créer `Customer`. Référencer l'existant. |
|
|
60
|
+
| Modification d'entité d'un autre module | Couplage fort | Utiliser des événements (MediatR) plutôt que des modifications directes. |
|
|
61
61
|
|
|
62
62
|
---
|
|
63
63
|
|
|
64
64
|
## Mapping vers la consolidation
|
|
65
65
|
|
|
66
|
-
|
|
|
66
|
+
| Réponse | Alimente |
|
|
67
67
|
|---------|----------|
|
|
68
68
|
| Q5.1-Q5.4 | `consolidation.crossModuleInteractions[]`, `consolidation.sharedEntities[]` |
|
|
69
69
|
| Q5.5-Q5.8 | `consolidation.impactAssessment[]`, `consolidation.permissionCoherence` |
|
|
@@ -53,27 +53,27 @@
|
|
|
53
53
|
|
|
54
54
|
### Phase de cadrage (step-01)
|
|
55
55
|
|
|
56
|
-
1. **
|
|
56
|
+
1. **Début :** Commencer par 01-context (contexte métier, identité application)
|
|
57
57
|
2. **Adapter :** Sauter les questions non pertinentes selon le contexte
|
|
58
|
-
3. **Approfondir :** Poser des questions de relance sur les
|
|
59
|
-
4. **Challenger :** Ne pas accepter "on verra plus tard" sur les
|
|
60
|
-
5. **Par lots :**
|
|
58
|
+
3. **Approfondir :** Poser des questions de relance sur les réponses vagues
|
|
59
|
+
4. **Challenger :** Ne pas accepter "on verra plus tard" sur les fonctionnalités indispensables
|
|
60
|
+
5. **Par lots :** Présenter 3 a 4 questions par interaction (AskUserQuestion)
|
|
61
61
|
|
|
62
62
|
### Phase de specification (step-03)
|
|
63
63
|
|
|
64
|
-
1. **Par module :** Charger 03-data-ui pour chaque module en cours de
|
|
65
|
-
2. **Cross-module :** Charger 05-cross-module si le module a des
|
|
64
|
+
1. **Par module :** Charger 03-data-ui pour chaque module en cours de spécification
|
|
65
|
+
2. **Cross-module :** Charger 05-cross-module si le module a des dépendances identifiées en step-02
|
|
66
66
|
|
|
67
67
|
### Questions de relance
|
|
68
68
|
|
|
69
|
-
Pour chaque
|
|
69
|
+
Pour chaque réponse vague, utiliser :
|
|
70
70
|
- "Pouvez-vous me donner un exemple concret ?"
|
|
71
71
|
- "Comment mesurez-vous cela aujourd'hui ?"
|
|
72
|
-
- "Que se passe-t-il si cette
|
|
73
|
-
- "Qui est
|
|
72
|
+
- "Que se passe-t-il si cette règle n'est pas respectée ?"
|
|
73
|
+
- "Qui est impacté par cette décision ?"
|
|
74
74
|
|
|
75
75
|
### Filtre de pertinence
|
|
76
76
|
|
|
77
|
-
Chaque question
|
|
78
|
-
> "La
|
|
77
|
+
Chaque question conservée passe ce test :
|
|
78
|
+
> "La réponse change-t-elle quelque chose dans le système a construire ?"
|
|
79
79
|
> Oui -> Conserver | Non -> Supprimer
|
|
@@ -239,7 +239,7 @@ Determine the language for analysis and code generation.
|
|
|
239
239
|
|
|
240
240
|
**Check config:**
|
|
241
241
|
- Retrieve `language` from `.business-analyse/config.json`
|
|
242
|
-
- Default: "fr" (
|
|
242
|
+
- Default: "fr" (Français)
|
|
243
243
|
|
|
244
244
|
**If not in config:**
|
|
245
245
|
```
|
|
@@ -247,7 +247,7 @@ Ask via AskUserQuestion:
|
|
|
247
247
|
question: "Quelle langue pour l'analyse ?"
|
|
248
248
|
header: "Langue"
|
|
249
249
|
options:
|
|
250
|
-
- label: "
|
|
250
|
+
- label: "Français (fr)"
|
|
251
251
|
- label: "English (en)"
|
|
252
252
|
- label: "Italiano (it)"
|
|
253
253
|
- label: "Deutsch (de)"
|
|
@@ -32,16 +32,16 @@ Frame the analysis scope at the **application level** through an interactive con
|
|
|
32
32
|
## EXECUTION FLOW — 5 PHASES
|
|
33
33
|
|
|
34
34
|
```
|
|
35
|
-
Phase 1:
|
|
35
|
+
Phase 1: ÉCOUTE → Read brief + codebase pre-research + silent pre-analysis
|
|
36
36
|
Phase 2: REFORMULATION → Rephrase the need back to the client for validation
|
|
37
37
|
Phase 3: APPROFONDISSEMENT → Challenge assumptions with targeted questionnaires
|
|
38
38
|
Phase 4: ANTICIPATION → Suggest unexpressed needs from domain expertise
|
|
39
|
-
Phase 5:
|
|
39
|
+
Phase 5: PÉRIMÈTRE → Bound scope with roles, coverage matrix (sections + resources)
|
|
40
40
|
```
|
|
41
41
|
|
|
42
42
|
---
|
|
43
43
|
|
|
44
|
-
## PHASE 1:
|
|
44
|
+
## PHASE 1: ÉCOUTE (Listen)
|
|
45
45
|
|
|
46
46
|
### 1. Read Current State
|
|
47
47
|
|
|
@@ -168,7 +168,7 @@ Write via ba-writer:
|
|
|
168
168
|
{
|
|
169
169
|
"code": "Employees",
|
|
170
170
|
"applicationCode": "HumanResources",
|
|
171
|
-
"name": "
|
|
171
|
+
"name": "Employés",
|
|
172
172
|
"featureType": "data-centric",
|
|
173
173
|
"priority": "must",
|
|
174
174
|
"entities": ["Employee", "Contract"],
|
|
@@ -179,7 +179,7 @@ Write via ba-writer:
|
|
|
179
179
|
}
|
|
180
180
|
],
|
|
181
181
|
"dependencies": [
|
|
182
|
-
{ "from": "Absences", "to": "Employees", "description": "Une absence
|
|
182
|
+
{ "from": "Absences", "to": "Employees", "description": "Une absence référence un employé" }
|
|
183
183
|
]
|
|
184
184
|
}
|
|
185
185
|
```
|
|
@@ -44,18 +44,18 @@ For each entity identified in step 02:
|
|
|
44
44
|
```json
|
|
45
45
|
{
|
|
46
46
|
"name": "Employee",
|
|
47
|
-
"description": "
|
|
47
|
+
"description": "Représente un employé de l'entreprise",
|
|
48
48
|
"attributes": [
|
|
49
49
|
{ "name": "code", "type": "string", "required": true, "description": "Identifiant unique" },
|
|
50
|
-
{ "name": "userId", "type": "guid", "required": true, "description": "
|
|
51
|
-
{ "name": "departmentId", "type": "guid", "required": true, "description": "
|
|
50
|
+
{ "name": "userId", "type": "guid", "required": true, "description": "Référence vers l'utilisateur" },
|
|
51
|
+
{ "name": "departmentId", "type": "guid", "required": true, "description": "Département d'affectation" },
|
|
52
52
|
{ "name": "hireDate", "type": "date", "required": true, "description": "Date d'embauche" },
|
|
53
|
-
{ "name": "position", "type": "string", "description": "Poste
|
|
54
|
-
{ "name": "status", "type": "enum", "options": ["Active", "Inactive", "OnLeave", "Terminated"], "description": "Statut de l'
|
|
53
|
+
{ "name": "position", "type": "string", "description": "Poste occupé" },
|
|
54
|
+
{ "name": "status", "type": "enum", "options": ["Active", "Inactive", "OnLeave", "Terminated"], "description": "Statut de l'employé" }
|
|
55
55
|
],
|
|
56
56
|
"relationships": [
|
|
57
|
-
{ "target": "Department", "type": "ManyToOne", "description": "Appartient
|
|
58
|
-
{ "target": "Contract", "type": "OneToMany", "description": "
|
|
57
|
+
{ "target": "Department", "type": "ManyToOne", "description": "Appartient à un département" },
|
|
58
|
+
{ "target": "Contract", "type": "OneToMany", "description": "Possède plusieurs contrats" }
|
|
59
59
|
]
|
|
60
60
|
}
|
|
61
61
|
```
|
|
@@ -69,7 +69,7 @@ For each entity/process, identify rules:
|
|
|
69
69
|
"id": "BR-VAL-EMPLOYEES-001",
|
|
70
70
|
"name": "Validation date embauche",
|
|
71
71
|
"category": "validation",
|
|
72
|
-
"statement": "La date d'embauche ne peut pas
|
|
72
|
+
"statement": "La date d'embauche ne peut pas être dans le futur",
|
|
73
73
|
"example": "Date embauche = 2027-01-01 → erreur car > date du jour",
|
|
74
74
|
"entities": ["Employee"],
|
|
75
75
|
"severity": "blocking"
|
|
@@ -85,19 +85,19 @@ For each stakeholder action:
|
|
|
85
85
|
```json
|
|
86
86
|
{
|
|
87
87
|
"id": "UC-EMPLOYEES-001",
|
|
88
|
-
"name": "
|
|
88
|
+
"name": "Créer un employé",
|
|
89
89
|
"actor": "Responsable RH",
|
|
90
90
|
"preconditions": ["L'utilisateur a la permission HumanResources.Employees.Create"],
|
|
91
91
|
"steps": [
|
|
92
|
-
"L'utilisateur ouvre la page de
|
|
93
|
-
"Il remplit les champs obligatoires (nom,
|
|
92
|
+
"L'utilisateur ouvre la page de création",
|
|
93
|
+
"Il remplit les champs obligatoires (nom, département, date embauche)",
|
|
94
94
|
"Il valide le formulaire",
|
|
95
|
-
"Le
|
|
96
|
-
"Le
|
|
95
|
+
"Le système vérifie les règles métier (BR-VAL-EMPLOYEES-001)",
|
|
96
|
+
"Le système crée l'employé et affiche la fiche"
|
|
97
97
|
],
|
|
98
|
-
"alternative": "Si les
|
|
98
|
+
"alternative": "Si les données sont invalides, le système affiche les erreurs",
|
|
99
99
|
"businessRules": ["BR-VAL-EMPLOYEES-001"],
|
|
100
|
-
"result": "L'
|
|
100
|
+
"result": "L'employé est créé avec le statut 'Actif'"
|
|
101
101
|
}
|
|
102
102
|
```
|
|
103
103
|
|