Progettare un sistema per l’edificio significa trasformare esigenze e vincoli in requisiti verificabili, organizzare funzioni e responsabilità e preparare le prove di accettazione. Questo hub descrive il metodo a livello di sistema: non è un capitolato pronto all’uso né sostituisce il progetto per un edificio reale.
Livello tecnico · Intermedio
Dalle esigenze ai requisiti
Le domande sul contesto d’uso identificano chi utilizza e gestisce il sistema e quali risultati sono attesi. La guida NASA sulle aspettative degli stakeholder distingue bisogni e aspettative dai requisiti formulati per una soluzione. È un riferimento generale di systems engineering, non una prescrizione edilizia.
Un requisito funzionale descrive che cosa il sistema deve fare; altri requisiti possono riguardare prestazioni, uso, gestione, interfacce o condizioni operative. La definizione dei requisiti tecnici richiede che siano coerenti con bisogni e vincoli, non ridondanti e verificabili. Qui non fissiamo soglie universali: valori e condizioni devono derivare dal caso e dalle fonti applicabili. L’approfondimento su requisiti, matrice delle funzioni e criteri di verifica descrive come rendere tracciabile questo passaggio.
- Quale esigenza o vincolo giustifica il requisito?
- Chi ne conferma il significato e le condizioni di applicazione?
- Quale risultato osservabile consentirà di verificarlo?
- Quali assunzioni restano da risolvere prima di sceglierne la soluzione?
Architettura a livello di sistema
Una volta chiariti i requisiti, l’architettura descrive funzioni, elementi, relazioni e responsabilità senza ridursi a un elenco di prodotti. La decomposizione logica NASA è un modello metodologico utile per collegare requisiti e funzioni e rendere visibili le interfacce. La definizione tecnica dei confini fra sistemi distinti appartiene all’hub Integrazione e interoperabilità.
Le alternative architetturali possono richiedere un ritorno alla valutazione. Un vincolo scoperto durante il progetto può modificare una scelta precedente; documentare la ragione del cambiamento è più utile che fingere un percorso perfettamente lineare.
Verifica e criteri di accettazione
La verifica va pensata mentre si definisce il requisito: occorre sapere quale evidenza dimostrerà che la soluzione lo soddisfa e in quali condizioni. Nella distinzione NASA, verificare la conformità ai requisiti e validare l’idoneità all’uso atteso sono domande correlate ma diverse. Metodi e formalità vanno adattati al progetto, senza trasferire automaticamente procedure aerospaziali all’edificio.
I criteri di accettazione dovrebbero esplicitare il risultato atteso, la modalità di controllo, chi partecipa e come si registrano esiti e anomalie. Un esito non dimostrato resta aperto: non diventa conforme per assenza di contestazioni.
Commissioning e handover nel metodo generale
Il commissioning collega installazione, configurazione e prove al sistema progettato; l’handover rende disponibili a chi gestirà l’opera le informazioni necessarie, compresi limiti e punti ancora aperti. La trattazione NASA della transizione del prodotto è un riferimento generale per questa continuità documentale, non una procedura edilizia. La documentazione di transizione è trattata qui come elemento del metodo generale, non come procedura specifica KNX. Le istruzioni dettagliate per progettazione e consegna KNX spettano alle pagine figlie dedicate.
Dopo la consegna, configurazione, verifiche e decisioni devono restare comprensibili nel ciclo di vita. Questo hub si ferma alla logica progettuale: non attribuisce responsabilità professionali a persone o imprese non documentate.
Questo articolo ha finalità informative e non definisce un progetto o un intervento per un edificio specifico. Prima di applicarne i contenuti, verifica requisiti e condizioni del caso, nonché le versioni pertinenti di norme, software, prodotti e documentazione ufficiale. Quando la decisione comporta competenze o responsabilità professionali, richiedi una valutazione qualificata.