✎ sdd:modele1:readme [pdc2]

<h1 class="page-header pb-3 mb-4 mt-5"><svg viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg" width="1em" height="1em" role="presentation" class="iconify mr-2"><path d="M13 9h5.5L13 3.5V9M6 2h8l6 6v12a2 2 0 0 1-2 2H6a2 2 0 0 1-2-2V4c0-1.11.89-2 2-2m9 16v-2H6v2h9m3-4v-2H6v2h12z"/></svg> Spécifications fonctionnelles — Applicateur de manchon</h1>
<div class="level1">

<p>
Ce dépôt contient les spécifications fonctionnelles de la machine d'application de manchon, formulées selon une approche BDD/SDD (Behavior/Specification-Driven Development) avec syntaxe Gherkin.
</p>

</div>

<h2 class="page-header pb-3 mb-4 mt-5">Objectif</h2>
<div class="level2">

<p>
Ces fichiers constituent la source de vérité fonctionnelle du comportement machine, partagée entre bureau d'études, automaticien et client. Ils sont écrits au niveau métier (ce que fait la machine), pas au niveau implémentation (comment c'est codé en Ladder/ST).
</p>

<p>
<b>Ces fichiers ne sont pas exécutables en l'état.</b> Pour devenir des tests automatisés, ils nécessitent une couche de step definitions (harnais de test) reliant chaque phrase Gherkin à un tag automate/IHM réel ou simulé. Voir <code>traceability/matrice_tags.md</code> pour un exemple de ce pont.
</p>

</div>

<h2 class="page-header pb-3 mb-4 mt-5">Structure du dépôt</h2>
<div class="level2">
<pre class="code">applicateur-manchon-specs/\\
├── README.md                          Ce fichier\\
├── GLOSSAIRE.md                       Vocabulaire métier commun (ubiquitous language)\\
├── features/\\
│   ├── cycle_nominal.feature          Cycle standard d'application de manchon\\
│   ├── gestion_defauts.feature        Détection et traitement des défauts\\
│   ├── changement_recette.feature     Changement de format/recette\\
│   ├── securite_acces_poste.feature   Sécurité machine (protecteurs, arrêt d'urgence)\\
│   └── ihm_supervision.feature        Comportement de l'écran tactile\\
├── docs/\\
│   └── brief_formulation.md           Méthodologie de rédaction (règles, checklist)\\
└── traceability/\\
  └── matrice_tags.md                Exemple de correspondance scénario ↔ tags automate\\

</pre><p> </p>

</div>

<h2 class="page-header pb-3 mb-4 mt-5">Convention de tags</h2>
<div class="level2">

<p>
Chaque scénario porte un tag de catégorie, utilisable pour une exécution ciblée une fois le harnais de test en place :
</p>

<p>
- <code>@nominal</code> — comportement standard, chemin heureux<br/>

- <code>@defaut</code> — gestion d'anomalie ou de panne<br/>

- <code>@securite</code> — fonctions liées à la sécurité machine (EN ISO 13849, EN 60204-1)<br/>

- <code>@recette</code> — gestion de format/paramétrage<br/>

- <code>@ihm</code> — comportement de l'écran tactile
</p>

</div>

<h2 class="page-header pb-3 mb-4 mt-5">Cycle de vie</h2>
<div class="level2">

<p>
1. <b>Discovery</b> : atelier avec automaticien, BE mécanique et qualité/client pour faire émerger les cas nominaux et limites (voir <code>docs/brief_formulation.md</code>).<br/>

2. <b>Formulation</b> : rédaction/mise à jour des fichiers <code>.feature</code> de ce dépôt.<br/>

3. <b>Automation</b> : implémentation du harnais de test (hors périmètre de ce dépôt) qui relie les steps aux tags réels via OPC-UA / S7comm / EtherNet-IP.
</p>

<p>
Toute évolution du comportement machine en cours de projet doit d'abord se traduire par une mise à jour du scénario concerné, avant modification du programme automate.
</p>

</div>

<h2 class="page-header pb-3 mb-4 mt-5">Périmètre couvert par cette première version</h2>
<div class="level2">

<p>
Cinq domaines fonctionnels sont couverts. Ce périmètre est volontairement incomplet et doit être complété au fil des ateliers de Discovery : diagnostics avancés, maintenance préventive, traçabilité qualité (numéro de lot, horodatage pièce) et communication MES/ERP ne sont pas encore traités.
</p>

</div>

Autoriser les tableaux complexes Hauteur de l'éditeur : px Activer la prise en charge supplémentaire du coller d'image Marche

Résumé: Changements mineurs