Canevas 3 — Spécification globale Spécification système » History » Revision 2
Revision 1 (Redmine Admin, 06/18/2026 08:03 PM) → Revision 2/5 (Redmine Admin, 06/19/2026 02:28 AM)
# Canevas 3 — Spécification globale / Spécification système
## 1. Objet du document
### 1.1 Finalité de la spécification globale
Cette partie précise l’objectif du document.
La spécification globale, également appelée spécification système, traduit le besoin exprimé dans le cahier des charges en exigences structurées, compréhensibles et vérifiables. Elle décrit ce que le système complet doit faire, dans quelles conditions il doit le faire, avec quelles contraintes et dans quel environnement.
Elle ne doit pas encore détailler la solution interne de chaque sous-système. Elle doit rester au niveau du système complet, en décrivant les fonctions attendues, les interfaces externes, les modes de fonctionnement, les performances attendues, les contraintes de sécurité, de sûreté, d’exploitation et de validation.
**Exemple :**
> Le présent document a pour objectif de spécifier les exigences globales applicables au système. Il décrit les fonctions attendues, les modes de fonctionnement, les interfaces externes, les contraintes techniques, les exigences d’exploitation, les exigences de maintenance et les exigences de validation applicables à l’ensemble du système.
### 1.2 Positionnement dans le cycle en V
Cette partie situe la spécification globale dans le cycle en V.
La spécification globale se situe après le cahier des charges et avant l’architecture système, les spécifications détaillées et la conception. Elle constitue un document de référence pour les phases suivantes du projet.
Elle est utilisée pour établir :
```text
- l’architecture système ;
- l’allocation des fonctions vers le hardware, le software embarqué, les serveurs, le réseau ou les opérateurs ;
- les spécifications détaillées des sous-systèmes ;
- le plan de vérification ;
- les tests système ;
- le dossier de validation.
```
Dans le cycle en V, elle correspond au niveau qui sera vérifié par les **tests système** et confirmé par la **validation globale**.
```text
Cahier des charges client
↓
Spécification globale / système
↓
Architecture système
↓
Spécifications détaillées des sous-systèmes
↓
Conception détaillée
↓
Réalisation
↑
Tests unitaires
↑
Tests d’intégration
↑
Tests système
↑
Validation client / recette
```
### 1.3 Différence avec le cahier des charges
Cette partie précise la différence entre le cahier des charges et la spécification globale.
Le cahier des charges exprime le besoin du client. Il peut être formulé en langage métier, opérationnel ou contractuel. La spécification globale reformule ce besoin en exigences système organisées, non ambiguës, vérifiables et exploitables par les équipes techniques.
**Exemple :**
```text
Besoin client :
Le système doit continuer à fonctionner même si la communication avec le serveur est interrompue.
Spécification globale :
SYS-COM-004 — En cas de perte de communication avec le serveur, le système doit maintenir les fonctions locales critiques, conserver les données nécessaires localement et signaler l’état de communication dégradée à l’opérateur.
```
### 1.4 Différence avec la spécification détaillée
Cette partie précise la frontière avec les documents de spécification détaillée.
La spécification globale décrit le comportement attendu du système complet. Les spécifications détaillées décriront ensuite le comportement attendu de chaque sous-système : hardware, logiciel embarqué, application serveur, interface opérateur, infrastructure, réseau, etc.
**Exemple :**
```text
Spécification globale :
Le système doit générer une alarme lorsqu’une mesure dépasse un seuil configuré.
Spécification détaillée logiciel embarqué :
Le firmware doit comparer la mesure de température au seuil configuré toutes les 10 secondes.
Si la mesure dépasse le seuil pendant trois cycles consécutifs, le firmware doit créer un événement d’alarme TEMP_HIGH.
Spécification détaillée serveur :
Le serveur doit recevoir l’événement TEMP_HIGH, l’enregistrer en base de données et le rendre disponible à l’interface opérateur.
Spécification détaillée interface :
L’interface opérateur doit afficher l’alarme TEMP_HIGH dans la liste des alarmes actives avec son niveau, son horodatage et l’équipement concerné.
```
### 1.5 Responsabilité de rédaction et d’approbation
Cette partie précise qui rédige, relit et approuve la spécification globale.
Dans un projet industriel, la spécification globale est généralement rédigée par le fournisseur, l’ingénieur système ou le responsable technique, à partir du cahier des charges client. Elle doit être relue par les responsables hardware, software, infrastructure, tests, qualité, exploitation et maintenance si ces domaines sont concernés.
**Exemple :**
```text
Rédaction : ingénieur système / responsable technique fournisseur
Contributions : responsables hardware, software, infrastructure, tests, cybersécurité, maintenance
Relecture : chef de projet, qualité, responsable validation
Approbation : fournisseur et client si le document est contractuel
```
---
## 2. Références et documents applicables
### 2.1 Documents d’entrée
Cette partie liste les documents utilisés pour rédiger la spécification globale.
Les documents d’entrée doivent être identifiés avec leur référence, leur version et leur statut. Cela permet de savoir sur quelle base la spécification a été construite.
**Exemples :**
```text
- Cahier des charges client
- Dossier de validation client
- Contrat ou commande
- Expression du besoin
- Compte rendu de réunion de cadrage
- Analyse de l’existant
- Contraintes réglementaires
- Contraintes de sécurité et sûreté
- Contraintes d’exploitation
- Contraintes de maintenance
- Contraintes d’hébergement ou d’infrastructure
```
### 2.2 Documents applicables
Cette partie liste les documents qui s’imposent au projet.
Un document applicable est un document que le système doit respecter. Il peut s’agir d’une norme, d’un règlement, d’une procédure client, d’un standard interne ou d’une exigence contractuelle.
**Exemples :**
```text
- Norme électrique applicable
- Norme CEM applicable
- Standard de cybersécurité client
- Procédure d’exploitation client
- Référentiel qualité projet
- Exigences de traçabilité documentaire
- Règles de codification des équipements
- Règles d’identification des alarmes
```
### 2.3 Documents de référence
Cette partie liste les documents utiles mais non obligatoires.
Ils peuvent servir de contexte ou d’inspiration, sans constituer des exigences strictement applicables.
**Exemples :**
```text
- Documentation d’un système existant
- Manuel d’un équipement similaire
- Retour d’expérience d’un projet précédent
- Schémas préliminaires
- Notes techniques
- Études de faisabilité
- Rapport d’analyse de risques préliminaire
```
### 2.4 Gestion des versions de référence
Cette partie précise que toute évolution d’un document d’entrée peut nécessiter une mise à jour de la spécification globale.
**Exemple :**
> Toute modification du cahier des charges, du dossier de validation ou d’une contrainte réglementaire applicable devra faire l’objet d’une analyse d’impact sur la présente spécification globale.
---
## 3. Définitions, acronymes et conventions
### 3.1 Définitions
Cette partie définit les termes importants utilisés dans le document.
Elle permet d’éviter les ambiguïtés entre le client, le fournisseur, les équipes hardware, software, exploitation et maintenance.
**Exemples :**
```text
Système :
Ensemble constitué de l’équipement embarqué, de son logiciel, de l’infrastructure serveur, des interfaces opérateur, du réseau de communication et des procédures associées.
Équipement embarqué :
Sous-ensemble matériel et logiciel installé sur site, chargé d’acquérir des données, de piloter des entrées/sorties et de communiquer avec le serveur.
Mode dégradé :
Mode de fonctionnement dans lequel le système conserve une partie de ses fonctions malgré la perte ou l’indisponibilité d’une ressource.
```
### 3.2 Acronymes
Cette partie liste les acronymes utilisés.
**Exemples :**
```text
API : Application Programming Interface
CEM : Compatibilité électromagnétique
CPU : Central Processing Unit
IHM : Interface Homme-Machine
IP : Internet Protocol
SAS : Zone ou serveur d’échange contrôlé entre deux environnements
VPN : Virtual Private Network
```
### 3.3 Conventions de rédaction des exigences
Cette partie définit la manière de rédiger et d’identifier les exigences.
Une exigence doit être claire, unique, vérifiable et traçable. Il est préférable d’éviter les formulations vagues comme “simple”, “rapide”, “ergonomique”, “suffisant” ou “performant” sans critère mesurable.
**Exemple de codification :**
```text
SYS-FCT-001 : exigence fonctionnelle système
SYS-MOD-001 : exigence relative aux modes de fonctionnement
SYS-COM-001 : exigence de communication
SYS-SEC-001 : exigence de sécurité
SYS-CYB-001 : exigence de cybersécurité
SYS-MNT-001 : exigence de maintenance
SYS-VAL-001 : exigence de validation
```
### 3.4 Formulation recommandée des exigences
Cette partie précise les formes attendues.
**Exemples :**
```text
Correct :
SYS-FCT-001 — Le système doit acquérir la mesure de température toutes les 10 secondes.
Incorrect :
Le système devra être rapide pour lire la température.
Correct :
SYS-COM-002 — Le système doit signaler une perte de communication serveur si aucun échange valide n’est reçu pendant plus de 120 secondes.
Incorrect :
Le système doit gérer correctement les problèmes réseau.
```
---
## 4. Vue générale du système
### 4.1 Présentation générale
Cette partie donne une vue synthétique du système à réaliser.
Elle doit permettre à un lecteur qui ne connaît pas le projet de comprendre rapidement ce que fait le système, où il est installé, avec quels composants il interagit et à quoi il sert.
**Exemple :**
> Le système a pour objectif de surveiller un équipement industriel installé sur site, d’acquérir des mesures, de détecter des défauts, de transmettre les données à un serveur central et de permettre aux opérateurs de consulter l’état du système à distance.
### 4.2 Objectifs fonctionnels principaux
Cette partie reprend les objectifs principaux, mais sous une forme plus structurée que dans le cahier des charges.
**Exemples :**
```text
Le système doit permettre :
- l’acquisition périodique de mesures physiques ;
- la surveillance d’états et de défauts ;
- la génération d’alarmes ;
- le stockage local temporaire des données ;
- la transmission des données vers une infrastructure serveur ;
- la consultation des états par une interface opérateur ;
- la configuration de paramètres autorisés ;
- le diagnostic et la maintenance de l’équipement.
```
### 4.3 Composition générale du système
Cette partie décrit les grands éléments constitutifs du système.
**Exemples :**
```text
Le système comprend :
- un équipement embarqué installé sur site ;
- une carte électronique de contrôle ;
- un logiciel embarqué ;
- des capteurs et actionneurs ;
- un module de communication ;
- un serveur applicatif ;
- une base de données ;
- une interface opérateur ;
- un poste de maintenance ;
- un réseau de communication ;
- des procédures d’installation, de test et de maintenance.
```
### 4.4 Frontières du système
Cette partie précise ce qui appartient au système et ce qui est externe.
Elle est essentielle pour éviter les ambiguïtés sur les responsabilités.
**Exemple :**
```text
Inclus dans le système :
- équipement embarqué ;
- firmware ;
- serveur applicatif ;
- base de données ;
- interface opérateur ;
- procédures de sauvegarde ;
- documentation d’installation.
Externe au système :
- réseau Internet public ;
- alimentation générale du bâtiment ;
- système tiers de supervision client ;
- équipements non fournis par le projet ;
- infrastructure physique du site hors coffret livré.
```
### 4.5 Synoptique général
Cette partie doit contenir un schéma général du système.
Le schéma peut représenter les flux principaux entre l’équipement, le serveur, l’opérateur, les systèmes tiers et les moyens de maintenance.
**Exemple de représentation textuelle :**
```text
Capteurs / Actionneurs
↕
Équipement embarqué + firmware
↕
Réseau local / VPN / 4G
↕
Serveur applicatif
↕
Base de données
↕
Interface opérateur / interface maintenance
```
---
## 5. Périmètre fonctionnel global
### 5.1 Fonctions incluses
Cette partie liste les fonctions globales incluses dans le périmètre du système.
Chaque fonction peut ensuite être détaillée dans les sections suivantes ou dans les spécifications détaillées.
**Exemples :**
```text
FCT-01 : acquisition des mesures
FCT-02 : surveillance des seuils
FCT-03 : génération des alarmes
FCT-04 : stockage local
FCT-05 : communication serveur
FCT-06 : consultation opérateur
FCT-07 : configuration
FCT-08 : diagnostic
FCT-09 : maintenance
FCT-10 : sauvegarde et restauration
```
### 5.2 Fonctions exclues
Cette partie liste les fonctions explicitement non prises en charge par le système.
**Exemples :**
```text
Le système ne prend pas en charge :
- la fourniture du réseau Internet du site ;
- la maintenance des équipements tiers ;
- la certification réglementaire de l’installation complète ;
- le pilotage d’équipements non listés dans le périmètre ;
- l’hébergement dans un cloud public non validé par le client.
```
### 5.3 Fonctions optionnelles
Cette partie liste les fonctions qui ne sont pas incluses dans la version de base mais qui peuvent être prévues en option ou en évolution future.
**Exemples :**
```text
- application mobile ;
- export automatique vers un système tiers ;
- intelligence embarquée de diagnostic prédictif ;
- accès multi-sites ;
- synchronisation avec un ERP ou une GMAO ;
- tableau de bord avancé.
```
### 5.4 Priorité des fonctions
Cette partie classe les fonctions selon leur importance.
Cette classification aide à prioriser le développement, les tests et la validation.
**Exemple :**
```text
Critique :
- fonctions de sécurité ;
- maintien en état sûr ;
- détection des défauts majeurs.
Importante :
- acquisition des mesures ;
- transmission au serveur ;
- affichage des alarmes ;
- stockage local.
Secondaire :
- export de rapport ;
- personnalisation de l’affichage ;
- statistiques avancées.
```
---
## 6. Exigences fonctionnelles globales
### 6.1 Acquisition des données
Cette partie décrit les exigences relatives à l’acquisition des mesures, états, défauts et événements.
Elle doit préciser ce qui doit être acquis, à quelle fréquence, avec quelle précision éventuelle, dans quelles conditions et avec quel comportement en cas d’erreur.
**Exemples d’exigences :**
```text
SYS-FCT-001 — Le système doit acquérir les mesures définies dans la configuration active.
SYS-FCT-002 — Le système doit horodater chaque mesure acquise.
SYS-FCT-003 — Le système doit détecter l’absence d’une mesure attendue.
SYS-FCT-004 — Le système doit signaler toute mesure incohérente ou hors plage autorisée.
```
**Exemple explicatif :**
> Si le système surveille une batterie, les mesures peuvent inclure la tension, le courant, la température, l’état de charge et les défauts remontés par le BMS. Chaque mesure doit être horodatée afin de pouvoir reconstituer l’historique en cas d’incident.
### 6.2 Traitement des données
Cette partie décrit les traitements que le système doit réaliser sur les données acquises.
Il peut s’agir de filtrage, comparaison à des seuils, calcul d’indicateurs, agrégation, détection d’anomalies ou génération d’états synthétiques.
**Exemples d’exigences :**
```text
SYS-FCT-010 — Le système doit comparer les mesures acquises aux seuils configurés.
SYS-FCT-011 — Le système doit générer un événement lorsque la valeur d’une mesure franchit un seuil d’alerte.
SYS-FCT-012 — Le système doit distinguer les alarmes critiques, majeures, mineures et informatives.
SYS-FCT-013 — Le système doit conserver l’état courant de chaque équipement surveillé.
```
### 6.3 Commande et pilotage
Cette partie décrit les fonctions de commande ou d’action sur l’équipement.
Elle doit être particulièrement précise si le système peut déclencher des actions physiques : relais, contacteur, moteur, vanne, charge, arrêt, redémarrage, verrouillage.
**Exemples d’exigences :**
```text
SYS-CMD-001 — Le système doit autoriser l’activation d’une commande uniquement si les conditions de sécurité associées sont satisfaites.
SYS-CMD-002 — Le système doit journaliser toute commande opérateur.
SYS-CMD-003 — Le système doit refuser toute commande non autorisée pour le profil utilisateur connecté.
SYS-CMD-004 — Le système doit confirmer l’exécution ou l’échec d’une commande.
```
**Exemple explicatif :**
> Une commande de redémarrage contrôlé ne doit pas pouvoir être lancée par un utilisateur non habilité. Elle doit faire l’objet d’une confirmation, être horodatée, journalisée et associée à l’identité de l’utilisateur.
### 6.4 Gestion des alarmes
Cette partie décrit les exigences générales relatives aux alarmes.
Elle doit préciser les types d’alarmes, leur cycle de vie, leur affichage, leur acquittement et leur historisation.
**Exemples d’exigences :**
```text
SYS-ALM-001 — Le système doit générer une alarme lorsqu’un défaut critique est détecté.
SYS-ALM-002 — Chaque alarme doit comporter un identifiant, un niveau, une date d’apparition, une description et l’équipement concerné.
SYS-ALM-003 — Le système doit permettre l’acquittement des alarmes par un utilisateur autorisé.
SYS-ALM-004 — Le système doit conserver l’historique des alarmes apparues, acquittées et clôturées.
SYS-ALM-005 — Le système doit distinguer une alarme active d’une alarme historisée.
```
### 6.5 Stockage et historisation
Cette partie décrit les exigences relatives à la conservation des mesures, événements, alarmes, logs et configurations.
**Exemples d’exigences :**
```text
SYS-STO-001 — Le système doit enregistrer les événements significatifs dans un historique consultable.
SYS-STO-002 — Le système doit conserver localement les données non transmises en cas de perte de communication.
SYS-STO-003 — Le système doit empêcher la perte silencieuse de données critiques.
SYS-STO-004 — Le système doit signaler une saturation prochaine du stockage local.
```
### 6.6 Communication
Cette partie décrit les exigences globales de communication avec les serveurs, équipements tiers, interfaces utilisateurs ou systèmes externes.
**Exemples d’exigences :**
```text
SYS-COM-001 — Le système doit transmettre les données d’état vers le serveur applicatif.
SYS-COM-002 — Le système doit détecter une perte de communication avec le serveur.
SYS-COM-003 — Le système doit signaler l’état de communication à l’opérateur.
SYS-COM-004 — Le système doit reprendre automatiquement la transmission des données après rétablissement de la communication.
SYS-COM-005 — Le système doit garantir que les données retransmises après coupure restent correctement horodatées.
```
### 6.7 Supervision et interface opérateur
Cette partie décrit ce que les utilisateurs doivent pouvoir voir, comprendre et réaliser depuis l’interface.
**Exemples d’exigences :**
```text
SYS-IHM-001 — Le système doit afficher l’état courant de chaque équipement surveillé.
SYS-IHM-002 — Le système doit afficher les alarmes actives avec leur niveau de criticité.
SYS-IHM-003 — Le système doit permettre la consultation de l’historique des événements.
SYS-IHM-004 — Le système doit présenter une information compréhensible par un opérateur non développeur.
SYS-IHM-005 — Le système doit distinguer les informations d’exploitation des informations de maintenance.
```
### 6.8 Configuration et paramétrage
Cette partie décrit les exigences relatives aux paramètres système.
Elle doit préciser ce qui est configurable, qui peut modifier les paramètres, comment les modifications sont contrôlées et comment elles sont tracées.
**Exemples d’exigences :**
```text
SYS-CFG-001 — Le système doit permettre la consultation de la configuration active.
SYS-CFG-002 — Le système doit réserver la modification des paramètres critiques aux utilisateurs habilités.
SYS-CFG-003 — Toute modification d’un paramètre critique doit être journalisée.
SYS-CFG-004 — Le système doit permettre l’export de la configuration active.
SYS-CFG-005 — Le système doit refuser une configuration invalide.
```
### 6.9 Diagnostic
Cette partie décrit les exigences permettant d’identifier l’origine d’un dysfonctionnement.
**Exemples d’exigences :**
```text
SYS-DIAG-001 — Le système doit fournir des informations de diagnostic accessibles aux utilisateurs autorisés.
SYS-DIAG-002 — Le système doit permettre la consultation des versions matérielles et logicielles installées.
SYS-DIAG-003 — Le système doit permettre l’export des journaux nécessaires à l’analyse d’un incident.
SYS-DIAG-004 — Le système doit distinguer les défauts matériel, logiciel, communication et configuration lorsque cette distinction est possible.
```
---
## 7. Modes de fonctionnement globaux
### 7.1 Objet de la description des modes
Cette partie explique pourquoi les modes de fonctionnement sont décrits dans la spécification globale.
Les modes de fonctionnement permettent de préciser comment le système se comporte dans les différentes situations de vie : arrêt, démarrage, fonctionnement nominal, maintenance, défaut, mode dégradé, secours, arrêt d’urgence, mise à jour, etc.
Dans certains projets, les modes de fonctionnement feront l’objet d’un document séparé. Dans ce cas, la spécification globale doit en donner une synthèse et renvoyer au dossier détaillé des modes.
### 7.2 Liste des modes
Cette partie liste les modes prévus.
**Exemples :**
```text
MOD-01 : mode arrêt
MOD-02 : mode démarrage
MOD-03 : mode initialisation
MOD-04 : mode nominal
MOD-05 : mode maintenance
MOD-06 : mode diagnostic
MOD-07 : mode dégradé communication
MOD-08 : mode dégradé capteur
MOD-09 : mode secours
MOD-10 : mode mise à jour
MOD-11 : mode arrêt contrôlé
MOD-12 : mode arrêt d’urgence
```
### 7.3 Mode arrêt
Cette partie décrit le comportement attendu lorsque le système est arrêté.
**Exemples d’exigences :**
```text
SYS-MOD-001 — En mode arrêt, le système ne doit exécuter aucune commande active.
SYS-MOD-002 — En mode arrêt, le système doit conserver la configuration persistante.
SYS-MOD-003 — En mode arrêt, le système doit permettre un démarrage contrôlé si les conditions d’alimentation sont satisfaites.
```
### 7.4 Mode démarrage et initialisation
Cette partie décrit les exigences relatives au démarrage.
**Exemples d’exigences :**
```text
SYS-MOD-010 — Au démarrage, le système doit vérifier la validité de sa configuration.
SYS-MOD-011 — Au démarrage, le système doit initialiser les interfaces nécessaires au fonctionnement nominal.
SYS-MOD-012 — Le système doit signaler toute anomalie empêchant le passage en mode nominal.
SYS-MOD-013 — Le système doit passer en mode nominal uniquement si les conditions minimales de fonctionnement sont satisfaites.
```
### 7.5 Mode nominal
Cette partie décrit le fonctionnement normal du système.
**Exemple :**
> En mode nominal, le système acquiert les mesures prévues, surveille les seuils configurés, transmet les données au serveur, met à jour l’interface opérateur et génère les alarmes si les conditions associées sont rencontrées.
**Exemples d’exigences :**
```text
SYS-MOD-020 — En mode nominal, le système doit exécuter les fonctions d’acquisition, de surveillance, de communication et de journalisation.
SYS-MOD-021 — En mode nominal, le système doit signaler tout défaut détecté.
SYS-MOD-022 — En mode nominal, le système doit maintenir l’état courant du système disponible pour l’opérateur.
```
### 7.6 Mode maintenance
Cette partie décrit les exigences générales applicables au mode maintenance.
**Exemples d’exigences :**
```text
SYS-MOD-030 — Le passage en mode maintenance doit être réservé à un utilisateur habilité.
SYS-MOD-031 — Le système doit indiquer clairement qu’il est en mode maintenance.
SYS-MOD-032 — Les actions réalisées en mode maintenance doivent être journalisées.
SYS-MOD-033 — Le retour au mode nominal doit réactiver les fonctions temporairement inhibées, sauf exception explicitement confirmée.
```
### 7.7 Modes dégradés
Cette partie décrit les exigences générales applicables aux modes dégradés.
Un mode dégradé doit préciser ce qui est perdu, ce qui est maintenu, ce qui est interdit, ce qui est signalé et comment le retour à la normale est réalisé.
**Exemples d’exigences :**
```text
SYS-MOD-040 — En cas de perte de communication serveur, le système doit maintenir les fonctions locales critiques.
SYS-MOD-041 — En cas d’indisponibilité d’un capteur non critique, le système doit signaler l’anomalie et poursuivre les fonctions non dépendantes de ce capteur.
SYS-MOD-042 — En cas de défaut critique, le système doit se placer dans un état sûr.
SYS-MOD-043 — Le système doit historiser l’entrée et la sortie d’un mode dégradé.
```
### 7.8 Transitions entre modes
Cette partie décrit les conditions de passage d’un mode à un autre.
Pour un système embarqué ou industriel, cette partie est particulièrement importante. Les erreurs de transition entre modes sont une source fréquente de défauts.
**Exemple :**
```text
Arrêt → Démarrage :
Condition : alimentation présente et commande de démarrage reçue.
Démarrage → Nominal :
Condition : configuration valide, interfaces initialisées, aucun défaut bloquant.
Nominal → Dégradé communication :
Condition : absence de communication serveur pendant plus de 120 secondes.
Dégradé communication → Nominal :
Condition : communication rétablie et synchronisation des données réalisée.
Nominal → Maintenance :
Condition : demande utilisateur habilité et absence d’action critique en cours.
```
---
## 8. Interfaces externes du système
### 8.1 Objet de la description des interfaces
Cette partie précise les interfaces entre le système et son environnement.
Une interface externe peut être matérielle, logicielle, réseau, utilisateur, électrique, mécanique ou documentaire.
Cette section ne doit pas encore nécessairement contenir tous les détails de protocole ou de câblage, qui pourront être décrits dans un dossier d’interfaces détaillé. Elle doit néanmoins identifier toutes les interfaces importantes.
### 8.2 Interfaces matérielles
Cette partie décrit les interfaces physiques avec les capteurs, actionneurs, alimentations, connecteurs ou équipements tiers.
**Exemples :**
```text
- alimentation électrique ;
- entrées numériques ;
- sorties relais ;
- entrées analogiques ;
- bus série ;
- connecteurs de maintenance ;
- capteurs externes ;
- actionneurs externes ;
- coffret ou armoire électrique.
```
**Exemple d’exigence :**
```text
SYS-IF-HW-001 — Le système doit disposer d’une interface d’alimentation compatible avec les caractéristiques électriques définies dans le dossier d’installation.
```
### 8.3 Interfaces logicielles
Cette partie décrit les interfaces avec les logiciels externes, applications tierces, API ou systèmes de supervision.
**Exemples :**
```text
- API serveur ;
- interface de supervision ;
- import/export de fichiers ;
- interface de configuration ;
- interface de diagnostic ;
- échange avec un logiciel tiers.
```
### 8.4 Interfaces réseau
Cette partie décrit les interfaces de communication réseau.
**Exemples :**
```text
- Ethernet ;
- Wi-Fi ;
- 4G / 5G ;
- VPN ;
- réseau local client ;
- réseau isolé de test ;
- protocole HTTPS ;
- protocole MQTT ;
- protocole Modbus TCP ;
- protocole propriétaire.
```
**Exemple d’exigence :**
```text
SYS-IF-NET-001 — Le système doit communiquer avec le serveur applicatif via le réseau défini dans le dossier d’infrastructure.
```
### 8.5 Interfaces utilisateur
Cette partie décrit les interfaces entre le système et les utilisateurs.
**Exemples :**
```text
- interface opérateur ;
- interface administrateur ;
- interface maintenance ;
- voyants ou afficheurs locaux ;
- boutons physiques ;
- messages d’alarme ;
- rapports exportés.
```
### 8.6 Interfaces documentaires
Cette partie précise les documents nécessaires aux échanges entre client, fournisseur, installateur, exploitant et mainteneur.
**Exemples :**
```text
- fichier de configuration ;
- fichier d’export ;
- rapport d’incident ;
- rapport de test ;
- journal d’exploitation ;
- procédure de maintenance ;
- dossier de configuration livrée.
```
---
## 9. Exigences non fonctionnelles
### 9.1 Exigences de performance
Cette partie décrit les exigences de temps de réponse, fréquence d’acquisition, délai d’affichage, volume de données, capacité de traitement ou nombre d’utilisateurs.
Les performances doivent être mesurables.
**Exemples d’exigences :**
```text
SYS-PERF-001 — Le système doit acquérir les mesures critiques avec une période maximale de 10 secondes.
SYS-PERF-002 — Une alarme critique doit être affichée sur l’interface opérateur en moins de 5 secondes après réception par le serveur.
SYS-PERF-003 — Le système doit permettre la consultation de l’historique des alarmes sur une période minimale de 12 mois.
SYS-PERF-004 — L’interface opérateur doit permettre la connexion simultanée d’au moins 10 utilisateurs.
```
### 9.2 Exigences de disponibilité
Cette partie décrit les exigences relatives à la disponibilité du système.
**Exemples :**
```text
SYS-DISP-001 — Le système doit être conçu pour permettre une exploitation continue pendant les périodes définies par le client.
SYS-DISP-002 — Une perte temporaire du serveur ne doit pas interrompre les fonctions locales critiques de l’équipement embarqué.
SYS-DISP-003 — Le système doit permettre un redémarrage contrôlé après coupure d’alimentation.
```
### 9.3 Exigences de fiabilité
Cette partie décrit les exigences relatives à la robustesse et à la stabilité du système.
**Exemples :**
```text
SYS-FIAB-001 — Le système ne doit pas perdre de configuration lors d’un redémarrage contrôlé.
SYS-FIAB-002 — Le système doit détecter et signaler les erreurs internes significatives.
SYS-FIAB-003 — Le système doit éviter toute perte silencieuse de données critiques.
```
### 9.4 Exigences de maintenabilité
Cette partie décrit les exigences facilitant la maintenance.
**Exemples :**
```text
SYS-MNT-001 — Le système doit permettre l’identification de la version logicielle installée.
SYS-MNT-002 — Le système doit permettre l’export des journaux nécessaires au diagnostic.
SYS-MNT-003 — Les composants remplaçables doivent être identifiables.
SYS-MNT-004 — Les opérations de maintenance courante doivent être décrites dans une procédure dédiée.
```
### 9.5 Exigences d’évolutivité
Cette partie décrit les exigences relatives aux extensions futures.
**Exemples :**
```text
SYS-EVO-001 — Le système doit permettre l’ajout d’un nouvel équipement surveillé sans modification majeure de l’architecture.
SYS-EVO-002 — Le système doit permettre l’ajout de nouveaux types d’alarmes par configuration ou évolution logicielle maîtrisée.
SYS-EVO-003 — Le système doit permettre une évolution des interfaces externes sous contrôle de version.
```
### 9.6 Exigences d’ergonomie
Cette partie décrit les attentes en matière d’usage et de lisibilité.
**Exemples :**
```text
SYS-ERG-001 — Les alarmes critiques doivent être visuellement distinguables des alarmes mineures.
SYS-ERG-002 — Les messages affichés à l’opérateur doivent être compréhensibles sans connaissance du code interne.
SYS-ERG-003 — Les actions critiques doivent demander une confirmation explicite.
```
---
## 10. Exigences de sécurité, sûreté et cybersécurité
### 10.1 Sécurité des personnes et des biens
Cette partie décrit les exigences visant à éviter les dommages physiques.
**Exemples :**
```text
SYS-SEC-001 — Le système ne doit pas déclencher une commande pouvant mettre en danger une personne si les conditions de sécurité ne sont pas satisfaites.
SYS-SEC-002 — En cas de défaut critique, le système doit rejoindre ou maintenir un état sûr.
SYS-SEC-003 — Les actions manuelles de maintenance doivent être réalisées dans des conditions empêchant les commandes intempestives.
```
### 10.2 Sûreté de fonctionnement
Cette partie décrit les exigences liées aux pannes, défauts, erreurs et comportements de repli.
**Exemples :**
```text
SYS-SDF-001 — Le système doit détecter les défauts critiques définis dans la spécification.
SYS-SDF-002 — Le système doit signaler les défauts détectés à l’opérateur.
SYS-SDF-003 — Le système doit garantir qu’un défaut critique ne reste pas silencieux.
SYS-SDF-004 — Le système doit conserver un historique des défauts critiques.
```
### 10.3 Cybersécurité
Cette partie décrit les exigences de protection contre les accès non autorisés, les modifications non maîtrisées, l’exposition réseau et la compromission des données.
**Exemples :**
```text
SYS-CYB-001 — L’accès aux fonctions d’administration doit être réservé aux utilisateurs authentifiés et autorisés.
SYS-CYB-002 — Les communications sensibles doivent être protégées conformément aux contraintes du projet.
SYS-CYB-003 — Les actions d’administration doivent être journalisées.
SYS-CYB-004 — Les mises à jour logicielles doivent être réalisées selon une procédure contrôlée.
SYS-CYB-005 — Les mots de passe ou secrets techniques ne doivent pas être stockés en clair dans les fichiers de configuration accessibles.
```
### 10.4 Gestion des droits
Cette partie décrit les profils d’accès attendus.
**Exemple :**
```text
Profil opérateur :
- consulter les états ;
- consulter les alarmes ;
- acquitter certaines alarmes.
Profil maintenance :
- accéder aux diagnostics ;
- exporter les logs ;
- réaliser certains tests.
Profil administrateur :
- gérer les comptes ;
- modifier la configuration ;
- réaliser les opérations de sauvegarde/restauration.
```
### 10.5 Journalisation des événements sensibles
Cette partie décrit les exigences de traçabilité des actions importantes.
**Exemples :**
```text
SYS-LOG-001 — Le système doit journaliser les connexions utilisateur.
SYS-LOG-002 — Le système doit journaliser les modifications de configuration.
SYS-LOG-003 — Le système doit journaliser les passages en mode maintenance.
SYS-LOG-004 — Le système doit journaliser les commandes critiques.
```
---
## 11. Exigences d’exploitation
### 11.1 Conditions d’exploitation
Cette partie décrit les conditions dans lesquelles le système devra être utilisé.
**Exemples :**
```text
- exploitation locale ;
- exploitation distante ;
- fonctionnement 24 h / 24 ;
- exploitation uniquement pendant les heures ouvrées ;
- présence ou absence d’un opérateur permanent ;
- environnement industriel ;
- environnement extérieur ;
- environnement isolé ou connecté.
```
### 11.2 Supervision
Cette partie décrit les exigences relatives à la surveillance du système.
**Exemples :**
```text
SYS-EXP-001 — Le système doit fournir un état global de fonctionnement.
SYS-EXP-002 — Le système doit signaler les défauts techniques empêchant la supervision.
SYS-EXP-003 — Le système doit permettre la consultation de l’état de communication des équipements.
SYS-EXP-004 — Le système doit permettre l’identification d’un équipement non joignable.
```
### 11.3 Sauvegarde
Cette partie décrit les exigences générales de sauvegarde.
Le détail technique pourra être décrit dans le dossier infrastructure.
**Exemples :**
```text
SYS-SAV-001 — Le système doit permettre la sauvegarde des données critiques.
SYS-SAV-002 — Le système doit permettre la sauvegarde de la configuration active.
SYS-SAV-003 — L’échec d’une sauvegarde planifiée doit être signalé à un utilisateur autorisé.
```
### 11.4 Restauration
Cette partie décrit les exigences relatives à la restauration du système.
**Exemples :**
```text
SYS-REST-001 — Le système doit permettre la restauration d’une configuration sauvegardée.
SYS-REST-002 — Une procédure de restauration doit être fournie.
SYS-REST-003 — La restauration doit être vérifiable par un test dédié.
```
### 11.5 Archivage
Cette partie décrit les exigences de conservation longue durée.
**Exemples :**
```text
SYS-ARCH-001 — Le système doit permettre l’archivage des historiques au-delà de la période de consultation courante.
SYS-ARCH-002 — Les données archivées doivent rester associées à leur horodatage et à l’équipement d’origine.
```
---
## 12. Exigences de maintenance
### 12.1 Maintenance préventive
Cette partie décrit les exigences générales relatives aux opérations périodiques de maintenance.
**Exemples :**
```text
SYS-MNT-010 — Le système doit permettre la vérification de son état de fonctionnement.
SYS-MNT-011 — Le système doit fournir les informations nécessaires à la maintenance préventive.
SYS-MNT-012 — Les opérations de maintenance préventive doivent être décrites dans une procédure dédiée.
```
### 12.2 Maintenance corrective
Cette partie décrit les exigences permettant de diagnostiquer et corriger une anomalie.
**Exemples :**
```text
SYS-MNT-020 — Le système doit fournir des codes défauts ou messages permettant d’orienter le diagnostic.
SYS-MNT-021 — Le système doit permettre l’export des journaux techniques.
SYS-MNT-022 — Le remplacement d’un composant doit être possible selon une procédure documentée si le composant est prévu comme remplaçable.
```
### 12.3 Maintenance logicielle
Cette partie décrit les exigences relatives aux mises à jour logiciel ou firmware.
**Exemples :**
```text
SYS-MNT-030 — Le système doit permettre l’identification de la version logicielle installée.
SYS-MNT-031 — La mise à jour logicielle doit être réalisée selon une procédure contrôlée.
SYS-MNT-032 — Une mise à jour doit être journalisée.
SYS-MNT-033 — Le système doit permettre une vérification du bon fonctionnement après mise à jour.
```
### 12.4 Maintenance infrastructure
Cette partie décrit les exigences liées aux serveurs, bases de données, réseau et sauvegardes.
**Exemples :**
```text
SYS-MNT-040 — Le système doit permettre la vérification de l’état des services applicatifs.
SYS-MNT-041 — Le système doit fournir les informations nécessaires au diagnostic d’un défaut serveur ou réseau.
SYS-MNT-042 — Les procédures de redémarrage, sauvegarde et restauration doivent être documentées.
```
---
## 13. Exigences d’installation et de déploiement
### 13.1 Installation matérielle
Cette partie décrit les exigences globales liées à l’installation physique.
**Exemples :**
```text
SYS-INS-001 — Le système doit être installable dans les conditions environnementales définies par le projet.
SYS-INS-002 — Les interfaces électriques et mécaniques nécessaires à l’installation doivent être identifiées.
SYS-INS-003 — Une procédure d’installation matérielle doit être fournie.
```
### 13.2 Déploiement logiciel
Cette partie décrit les exigences globales de déploiement logiciel.
**Exemples :**
```text
SYS-DEP-001 — Le système doit être livré avec les éléments nécessaires à l’installation du logiciel.
SYS-DEP-002 — Les versions logicielles déployées doivent être identifiables.
SYS-DEP-003 — Une procédure de déploiement doit être fournie.
SYS-DEP-004 — Le déploiement doit permettre une vérification du bon fonctionnement après installation.
```
### 13.3 Environnements de déploiement
Cette partie décrit les environnements concernés.
**Exemples :**
```text
- environnement de développement ;
- environnement de test ;
- environnement de validation ;
- environnement de préproduction ;
- environnement de production ;
- environnement de maintenance.
```
### 13.4 Configuration initiale
Cette partie décrit les exigences relatives à la configuration au démarrage ou à la livraison.
**Exemples :**
```text
SYS-CFG-010 — Le système doit être livré avec une configuration initiale documentée.
SYS-CFG-011 — Toute configuration spécifique au site doit être identifiée.
SYS-CFG-012 — La configuration livrée doit être sauvegardée avant mise en service.
```
---
## 14. Exigences d’infrastructure
### 14.1 Objet des exigences d’infrastructure
Cette partie décrit les exigences globales relatives aux PC, serveurs, réseau, stockage, sauvegarde, environnements et services nécessaires au fonctionnement du système.
Le détail technique complet peut être placé dans le dossier d’infrastructure, mais la spécification globale doit identifier les exigences principales.
### 14.2 Serveurs
Cette partie décrit les exigences concernant les serveurs nécessaires.
**Exemples :**
```text
SYS-INF-001 — Le système doit disposer d’un environnement serveur permettant l’exécution de l’application.
SYS-INF-002 — Les rôles des serveurs de test, validation et production doivent être distingués.
SYS-INF-003 — Les versions des composants logiciels serveur doivent être identifiables.
```
### 14.3 Stockage
Cette partie décrit les exigences relatives au stockage des données.
**Exemples :**
```text
SYS-INF-010 — Le système doit disposer d’une capacité de stockage suffisante pour les données d’exploitation sur la durée définie.
SYS-INF-011 — Le système doit signaler une saturation prochaine du stockage si cette saturation peut affecter le fonctionnement.
SYS-INF-012 — Les données critiques doivent être protégées contre une suppression accidentelle non maîtrisée.
```
### 14.4 Réseau
Cette partie décrit les exigences réseau globales.
**Exemples :**
```text
SYS-INF-020 — Le système doit pouvoir fonctionner sur le réseau défini pour le projet.
SYS-INF-021 — Les flux réseau nécessaires au fonctionnement doivent être identifiés.
SYS-INF-022 — Le système doit pouvoir détecter une perte de communication avec les équipements ou serveurs critiques.
```
### 14.5 Sauvegarde et restauration
Cette partie décrit les exigences principales de sauvegarde et restauration.
**Exemples :**
```text
SYS-INF-030 — Les données et configurations critiques doivent être sauvegardables.
SYS-INF-031 — Une procédure de restauration doit permettre de récupérer un état exploitable du système.
SYS-INF-032 — La restauration doit être testée dans le cadre de la validation.
```
### 14.6 SAS et échanges contrôlés
Cette partie décrit les exigences relatives aux zones d’échange ou sas techniques, lorsqu’ils existent.
Un SAS peut être utilisé pour transférer des fichiers, configurations, mises à jour, rapports ou données entre deux environnements isolés.
**Exemples :**
```text
SYS-INF-040 — Les échanges entre l’environnement de test et l’environnement de production doivent être réalisés via un mécanisme contrôlé.
SYS-INF-041 — Les fichiers déposés dans le SAS doivent être identifiables et traçables.
SYS-INF-042 — Les mises à jour transférées via le SAS doivent être contrôlées avant déploiement.
```
---
## 15. Contraintes environnementales et réglementaires
### 15.1 Contraintes environnementales
Cette partie décrit les conditions physiques dans lesquelles le système doit fonctionner.
**Exemples :**
```text
- température ;
- humidité ;
- poussière ;
- vibrations ;
- chocs ;
- altitude ;
- environnement intérieur ou extérieur ;
- exposition aux projections d’eau ;
- contraintes CEM ;
- contraintes mécaniques.
```
**Exemples d’exigences :**
```text
SYS-ENV-001 — Le système doit fonctionner dans la plage de température définie pour l’installation.
SYS-ENV-002 — Les composants installés en extérieur doivent être protégés contre les conditions environnementales prévues.
SYS-ENV-003 — Le système doit respecter les contraintes de compatibilité électromagnétique applicables.
```
### 15.2 Contraintes réglementaires
Cette partie liste les règlements, normes ou obligations applicables au système.
**Exemples :**
```text
- réglementation électrique ;
- réglementation machine ;
- réglementation radio ;
- cybersécurité ;
- protection des données ;
- normes industrielles spécifiques ;
- exigences client sectorielles.
```
### 15.3 Contraintes qualité
Cette partie décrit les exigences qualité applicables au projet.
**Exemples :**
```text
SYS-QUA-001 — Les exigences système doivent être identifiées de manière unique.
SYS-QUA-002 — Les exigences critiques doivent être tracées jusqu’aux tests associés.
SYS-QUA-003 — Les versions livrées doivent être identifiables et reproductibles.
SYS-QUA-004 — Les anomalies détectées pendant les tests doivent être enregistrées et suivies.
```
---
## 16. Exigences de vérification et de validation
### 16.1 Testabilité des exigences
Cette partie précise que chaque exigence doit être vérifiable.
Une exigence non vérifiable doit être reformulée ou justifiée.
**Exemple :**
```text
Exigence non vérifiable :
Le système doit être simple à utiliser.
Exigence vérifiable :
Un opérateur formé doit pouvoir acquitter une alarme active en moins de trois actions depuis l’écran principal.
```
### 16.2 Méthodes de vérification
Cette partie décrit les méthodes possibles pour vérifier les exigences.
**Exemples :**
```text
Essai :
Exécution d’un test sur le système.
Analyse :
Vérification par calcul, étude ou raisonnement technique.
Inspection :
Vérification visuelle ou documentaire.
Démonstration :
Réalisation d’une fonction devant le client sans instrumentation lourde.
Revue :
Examen collectif d’un document ou d’un livrable.
```
### 16.3 Exigences liées aux tests système
Cette partie décrit les exigences relatives aux tests système.
**Exemples :**
```text
SYS-VER-001 — Les fonctions globales du système doivent être vérifiées par des tests système.
SYS-VER-002 — Les modes dégradés doivent faire l’objet de tests dédiés.
SYS-VER-003 — Les exigences critiques doivent être reliées à au moins un test.
SYS-VER-004 — Les résultats des tests système doivent être enregistrés dans un rapport.
```
### 16.4 Exigences liées à la validation client
Cette partie décrit les exigences liées à la recette ou validation finale.
**Exemples :**
```text
SYS-VAL-001 — Les scénarios de validation client doivent couvrir les fonctions critiques.
SYS-VAL-002 — Les critères d’acceptation doivent être définis avant l’exécution de la recette.
SYS-VAL-003 — Les anomalies bloquantes doivent être corrigées avant acceptation sans réserve.
SYS-VAL-004 — La validation doit donner lieu à un procès-verbal de recette.
```
### 16.5 Traçabilité exigences / tests
Cette partie impose la matrice de traçabilité.
**Exemple :**
```text
| ID exigence | Libellé | Criticité | Moyen de vérification | Test associé | Statut |
|---|---|---|---|---|---|
| SYS-COM-004 | Maintien local en perte réseau | Élevée | Essai | TEST-SYS-COM-002 | À vérifier| vérifier
```
---
## 17. Allocation préliminaire des exigences
### 17.1 Objet de l’allocation
Cette partie explique comment les exigences système sont réparties vers les sous-systèmes.
L’allocation permet de préparer les spécifications détaillées. Elle ne constitue pas encore une conception détaillée, mais elle indique quel sous-ensemble sera responsable de satisfaire chaque exigence.
### 17.2 Sous-systèmes concernés
Cette partie liste les sous-systèmes vers lesquels les exigences peuvent être allouées.
**Exemples :**
```text
- hardware ;
- logiciel embarqué ;
- application serveur ;
- base de données ;
- interface opérateur ;
- infrastructure réseau ;
- infrastructure de sauvegarde ;
- opérateur humain ;
- procédure de maintenance ;
- équipement tiers.
```
### 17.3 Exemple d’allocation
```text
Exigence système :
SYS-COM-004 — En cas de perte de communication avec le serveur, le système doit maintenir les fonctions locales critiques et conserver les données nécessaires.
Allocation :
- logiciel embarqué : détection de perte communication, stockage local ;
- hardware : maintien de l’alimentation et des fonctions locales ;
- serveur : reprise de synchronisation ;
- interface opérateur : affichage de l’état dégradé ;
- procédure maintenance : diagnostic en cas de perte prolongée.
```
### 17.4 Matrice d’allocation
Cette partie peut contenir une matrice.
**Exemple :**
```text
ID exigence | Hardware | Software embarqué | Serveur | IHM | Infrastructure | Procédure
SYS-FCT-001 | X | X | | | |
SYS-COM-004 | | X | X | X | X |
SYS-ALM-002 | | X | X | X | |
SYS-MNT-021 | | X | X | | | X
```
---
## 18. Hypothèses, contraintes et limites
### 18.1 Hypothèses projet
Cette partie liste les hypothèses prises pour rédiger la spécification globale.
**Exemples :**
```text
- Le réseau local du site sera disponible à la mise en service.
- Le client fournira les informations nécessaires à la configuration des accès.
- L’alimentation électrique respectera les caractéristiques définies.
- Les capteurs fournis par un tiers respecteront leur documentation technique.
```
### 18.2 Contraintes imposées
Cette partie liste les contraintes qui s’imposent au fournisseur ou au système.
**Exemples :**
```text
- utilisation d’un protocole imposé ;
- hébergement sur infrastructure client ;
- interdiction d’accès Internet direct ;
- utilisation d’un système d’exploitation validé ;
- format d’export imposé ;
- contraintes de cybersécurité client.
```
### 18.3 Limites connues
Cette partie décrit les limites acceptées du système.
**Exemples :**
```text
- fonctionnement local limité à 48 heures sans communication serveur ;
- absence de redondance serveur dans la première version ;
- nombre maximal d’équipements connectés ;
- compatibilité limitée à certains navigateurs ;
- stockage local limité par la capacité matérielle embarquée.
```
### 18.4 Points ouverts
Cette partie recense les questions non tranchées.
Chaque point ouvert doit être suivi, affecté et clôturé avant une étape projet définie.
**Exemple :**
```text
PO-001 — Le protocole exact d’échange avec le système tiers reste à confirmer.
Responsable : client
Échéance : avant validation de l’architecture système
Impact : dossier d’interfaces et spécification serveur
```
---
## 19. Traçabilité
### 19.1 Traçabilité avec le cahier des charges
Cette partie décrit comment les exigences de la spécification globale sont reliées aux besoins du cahier des charges.
**Exemple :**
```text
Besoin CDC-012 :
Le système doit permettre une supervision distante.
Exigences système associées :
SYS-COM-001 — Transmission des données au serveur.
SYS-IHM-001 — Affichage de l’état des équipements.
SYS-ALM-002 — Affichage des alarmes actives.
SYS-CYB-001 — Accès sécurisé aux fonctions d’administration.
```
### 19.2 Traçabilité vers les spécifications détaillées
Cette partie explique comment les exigences globales seront déclinées dans les documents détaillés.
**Exemple :**
```text
SYS-COM-004 :
Décliné dans :
- SW-REQ-COM-017 : détection de perte communication ;
- SW-REQ-STO-008 : stockage local des données ;
- SRV-REQ-SYNC-003 : resynchronisation serveur ;
- IHM-REQ-ALM-006 : affichage de l’état dégradé.
```
### 19.3 Traçabilité vers les tests
Cette partie explique comment les exigences système seront vérifiées.
**Exemple :**
```text
SYS-COM-004 :
Vérifié par :
- TEST-INT-COM-002 : coupure réseau de 30 minutes ;
- TEST-SYS-COM-004 : resynchronisation après retour réseau ;
- VAL-COM-002 : validation client du mode dégradé communication.
```
### 19.4 Matrice de traçabilité globale
Cette partie peut contenir la matrice centrale du document.
**Structure recommandée :**
```text
ID besoin client
ID exigence système
Libellé exigence système
Criticité
Sous-système alloué
Document détaillé associé
Test associé
Statut
Commentaire
```
---
## 20. Critères d’acceptation de la spécification globale
### 20.1 Complétude
Cette partie précise les critères permettant de considérer la spécification globale comme complète.
**Exemples :**
```text
La spécification globale est considérée comme complète si :
- tous les besoins client applicables sont pris en compte ;
- les fonctions principales sont décrites ;
- les modes de fonctionnement sont identifiés ;
- les interfaces externes sont identifiées ;
- les contraintes non fonctionnelles sont décrites ;
- les exigences critiques sont identifiées ;
- les exigences sont vérifiables ;
- les points ouverts sont listés.
```
### 20.2 Cohérence
Cette partie précise les critères de cohérence.
**Exemples :**
```text
La spécification globale ne doit pas contenir :
- d’exigences contradictoires ;
- d’exigences impossibles à vérifier ;
- d’exigences trop vagues ;
- de choix de conception détaillée non justifiés ;
- d’ambiguïtés sur le périmètre ;
- d’ambiguïtés sur les responsabilités.
```
### 20.3 Validation du document
Cette partie précise comment le document est approuvé.
**Exemple :**
```text
La spécification globale doit être relue par les responsables système, hardware, software, infrastructure, tests et validation. Elle doit être approuvée avant le démarrage des spécifications détaillées et de la conception globale.
```
---
## 21. Annexes
### 21.1 Liste des exigences système
Cette annexe peut contenir la liste complète des exigences sous forme tabulaire.
**Exemple :**
```text
ID | Catégorie | Libellé | Criticité | Vérification | Statut
SYS-FCT-001 | Fonctionnelle | Acquisition des mesures | Élevée | Essai | Approuvée
SYS-COM-004 | Communication | Maintien local en perte réseau | Élevée | Essai | Approuvée
SYS-CYB-001 | Cybersécurité | Accès administration sécurisé | Élevée | Test / inspection | À compléter
```
### 21.2 Liste des interfaces
Cette annexe peut reprendre la liste synthétique des interfaces identifiées.
**Exemple :**
```text
IF-HW-001 : alimentation équipement
IF-HW-002 : capteur température
IF-NET-001 : liaison équipement-serveur
IF-SW-001 : API serveur
IF-IHM-001 : interface opérateur
IF-DOC-001 : fichier d’export configuration
```
### 21.3 Liste des modes de fonctionnement
Cette annexe peut reprendre la liste des modes et renvoyer au dossier détaillé des modes de fonctionnement.
### 21.4 Glossaire
Cette annexe reprend les termes spécifiques au projet.
### 21.5 Points ouverts
Cette annexe peut centraliser les points à trancher avant la suite du projet.
**Exemple :**
```text
ID | Sujet | Responsable | Échéance | Impact | Statut
PO-001 | Protocole système tiers | Client | 15/07/2026 | Interfaces | Ouvert
PO-002 | Durée de conservation des données | Client | 20/07/2026 | Stockage / validation | Ouvert
```