Du besoin à l’architecture : exigences, modèles et preuves

La formulation retenue est : « permettre le repérage du chemin extérieur pendant la période nocturne, sans réseau électrique permanent, tout en limitant éblouissement, consommation, obstacle et maintenance ». Elle ne promet ni capteur, ni batterie, ni panneau. Les parties prenantes directes sont les personnes qui empruntent le chemin et celles qui entretiennent le produit ; le gestionnaire fixe budget et continuité ; le voisinage et l'environnement sont exposés à la lumière, aux matières et à la fin de vie. Chaque attente devient ensuite une exigence mesurable ou un scénario de revue. P1 désigne une solution. P2 formule service, contexte et contrainte. P3 est une attente de maintenance, à traduire en un retour observable. P4 devient une exigence vérifiable seulement lorsque R et la méthode sont définis. Une attente peut donc produire une exigence ; les catégories représentent des étapes de précision, non des étiquettes sans relation.

Erreur à éviter. la phrase de besoin contient déjà panneau solaire, batterie et capteur infrarouge

Pourquoi elle échoue. Une architecture a été figée avant de comparer les services et contraintes. Les solutions alternatives deviennent invisibles et une exigence peut être inventée pour justifier le choix initial.

Comment la reprendre. Réécrire avec un verbe de service, l'objet ou la personne concernée, le contexte et les limites. Ranger les composants pressentis dans une liste d'options, pas dans la définition du besoin.

S-U1 passe la revue si chaque étape est décrite et si la lumière ne clignote pas. S-U2 passe si les deux retours fictifs désignent le même état et si le texte ne repose pas sur une couleur seule. S-U3 passe si les deux volumes restent hors du passage dans la fiche géométrique. Ces trois succès sont nécessaires pour REQ-USA-06 ; ils ne suffisent pas à certifier une accessibilité physique. S-D1 est une règle distincte de défaut sur banc simulé : commande inhibée et diagnostic maintenu. Une lampe éteinte sur un vrai chemin pourrait être dangereuse ; ce comportement ne doit pas être transposé à une installation. S-L1 contrôle la continuité entre deux passages.

Erreur à éviter. le dossier ne décrit que la personne moyenne marchant une fois par temps sec

Pourquoi elle échoue. Le scénario nominal a été pris pour la totalité du besoin. Les limites de cadence, d'énergie, d'environnement, de perception et de panne ne produisent alors aucune exigence.

Comment la reprendre. Ajouter une variante de frontière, une panne plausible et une barrière d'usage. Pour chacune, définir l'état observable attendu sans demander de mise en danger.

1. Le but. Transformer chaque attente en une question à laquelle un essai ou un calcul pourra répondre. Ne commence pas par choisir un mécanisme.

2. Choisir la grandeur. « Rapide » devient un temps entre l’événement qualifié et l’allumage ; « léger » devient la masse du prototype ; « économe » devient l’énergie consommée sur le scénario quotidien R.

3. Écrire la règle complète. Dans ce dossier fictif : temps de réponse ≤ 0,5 s ; masse ≤ 1,2 kg ; énergie quotidienne ≤ 8 Wh/jour. Le signe ≤ signifie que la valeur exactement égale au seuil est acceptée.

4. Garder les conditions. Un temps n’a de sens que si son instant de départ et son instant d’arrivée sont définis. Une énergie par jour exige le même scénario d’usage. Le test d’un autre scénario ne remplace pas silencieusement celui demandé.

5. Traiter l’accessibilité par des situations observables. Les trois scénarios du dossier vérifient notamment l’absence de clignotement et un retour non exclusivement visuel ; une note globale ne remplace pas ces vérifications.

6. Conclure. Chaque ligne conserve grandeur, unité, comparateur, niveau et méthode de vérification. Les seuils sont ceux de l’exercice ; ils ne constituent pas une norme applicable à un produit réel.

Erreur à éviter. le tableau compare 500 ms, 1,2 kg et 8 Wh comme des nombres sans unité

Pourquoi elle échoue. La colonne unité a été supprimée et les critères sont agrégés comme s'ils mesuraient la même grandeur. Toute comparaison ou pondération devient arbitraire.

Comment la reprendre. Conserver grandeur, unité et sens du comparateur dans chaque ligne. Normaliser seulement dans une matrice de décision documentée, après avoir appliqué les seuils éliminatoires.

La chaîne d'information qualifie présence et luminosité, décide d'un état puis génère une commande. La chaîne d'énergie stocke, protège, distribue et convertit l'énergie en lumière. Une fonction de diagnostic observe énergie et cohérence des informations. Les interfaces nomment la grandeur transmise et les risques, sans choisir encore la technologie du capteur. REQ-REP-03 est tracée vers qualification, décision et commande ; REQ-LUM-01 vers conversion et distribution optique ; REQ-ENE-02 et 04 vers toute la chaîne de puissance.

Erreur à éviter. le diagramme contient seulement batterie, Arduino, LED et PIR

Pourquoi elle échoue. Une nomenclature de composants a été présentée comme une architecture fonctionnelle. Les services, flux, diagnostics et exigences allouées ne sont plus visibles.

Comment la reprendre. Remplacer temporairement chaque composant par le verbe qu'il sert. Ajouter entrées, sorties et exigences ; seulement ensuite allouer une ou plusieurs solutions techniques à chaque fonction.

La qualification de présence est allouée au capteur et au filtrage ; la décision au programme exécuté par le microcontrôleur ; la conversion d'énergie au convertisseur et à la source lumineuse. L'interface capteur-commande annonce type de valeur, cadence maximale, domaine et valeur invalide. L'interface batterie-convertisseur annonce grandeurs électriques et protections, sans fournir ici un schéma de câblage. Chaque risque reçoit une détection ou une barrière et un test fictif. La matrice permet de remplacer le capteur sans perdre REQ-REP-03 ni le scénario de panne.

Erreur à éviter. deux blocs sont reliés par une flèche nommée données, sans unité, cadence ni valeur d'erreur

Pourquoi elle échoue. Le dessin montre une connexion visuelle mais aucun contrat testable. Les équipes peuvent implémenter des conventions incompatibles et découvrir tardivement le désaccord.

Comment la reprendre. Créer une fiche d'interface avec producteur, consommateur, sens, grandeur ou format, domaine, cadence, erreur, valeur par défaut et exigences concernées.

1. Le but. Vérifier la règle pédagogique R-A sur la moyenne des six indications, sans la transformer en certification du produit. Le seuil donné est 20 lx.

2. Garder toutes les données. La moyenne vaut 20,8 lx, l’écart-type s environ 0,518 lx et la composante uA = s/√6 environ 0,211345 lx. La valeur 19,9 lx reste dans le jeu : le critère porte sur la moyenne, pas sur chaque répétition.

3. Appliquer la bonne règle. Calculer 2uA = 0,42269 lx, puis la borne basse 20,8 − 0,42269 = 20,37731 lx. Cette borne dépasse 20 lx : R-A est satisfaite sur ce jeu.

4. Contrôler l’interprétation. L’intervalle associé à ce seul calcul est environ [20,38 ; 21,22] lx. Il ne recouvre pas le seuil, mais il ne représente pas automatiquement toute l’incertitude de mesure.

5. Conclure sans changer de périmètre. Le résultat est favorable pour la règle simplifiée fondée sur la répétabilité. Il manque les contributions d’étalonnage, de résolution, de position et d’ambiance pour une décision plus complète.

6. La suite utile. Caractériser les contributions manquantes puis appliquer une règle convenue. Le facteur deux utilisé ici n’est pas une garantie universelle de couverture à 95 %.

Erreur à éviter. Déclarer un échec du critère moyen parce qu’une répétition vaut 19,9 lx.

Pourquoi elle échoue. Le critère a été remplacé par un minimum sur chaque répétition. De plus, on a attribué à un budget incomplet un intervalle total inconnu ; ni cette substitution ni cette extrapolation ne sont soutenues par les données fournies.

Comment la reprendre. Garder les six valeurs, calculer la moyenne et uA, appliquer R-A à la moyenne, puis distinguer ce test favorable d’une satisfaction globale encore indéterminée.