Una buona progettazione dei sistemi di edificio non parte dal catalogo prodotti, ma da requisiti espliciti e verificabili. La funzione richiesta deve essere descritta in modo abbastanza preciso da poter essere trasformata in architettura, specifica, commissioning e criteri di accettazione.
Livello tecnico · Avanzato
Fonti primarie verificate nei registri pubblici: ANSI/ASHRAE/IES Standard 202-2024; ASHRAE Guideline 0-2019; CIBSE Commissioning Code C — Automatic Controls (2001, stato Active nel catalogo CIBSE); ISO/IEC/IEEE 29148:2018 per la terminologia di requirements engineering
Verifica delle fonti: 13 ottobre 2026
Version-sensitive: sìLa logica utilizzata in questa pagina distingue requisito, criterio di verifica, soluzione tecnica e prova finale. Le fonti di commissioning e systems engineering sono utilizzate come riferimenti metodologici; non trasformano questa pagina in una procedura normativa universale. Le formulazioni OPR e BOD devono essere confrontate con i documenti integrali applicabili.
Dal bisogno al requisito verificabile
Espressioni come “impianto intelligente”, “BMS completo”, “massimo comfort” o “integrazione totale” non sono requisiti sufficienti. Indicano un obiettivo generale, ma non specificano quale comportamento deve essere ottenuto né come verificarlo.
Un requisito utile dovrebbe chiarire almeno funzione, condizioni, prestazione attesa, interfacce, responsabilità e criterio di accettazione.
ESIGENZA → REQUISITO → CRITERIO DI VERIFICA → ARCHITETTURA → IMPLEMENTAZIONE → TEST → ACCETTAZIONE
Requisito e soluzione non sono la stessa cosa
Il requisito descrive ciò che il sistema deve ottenere. La soluzione descrive come si decide di ottenerlo. Confondere i due livelli può bloccare prematuramente il progetto su un prodotto, un protocollo o un’architettura prima di aver verificato se rispondono realmente all’esigenza.
“Regolare automaticamente la temperatura di ciascuna zona negli orari di occupazione” è un requisito funzionale. “Utilizzare il controller X con protocollo Y” è una possibile scelta progettuale. La seconda deve essere giustificata dalla prima, non sostituirla.
La matrice delle funzioni
Per sistemi complessi è utile trasformare i requisiti in una matrice delle funzioni. Ogni riga rappresenta una funzione da progettare e successivamente verificare.
- funzione richiesta;
- condizione di attivazione;
- input necessari;
- logica o decisione;
- output o comando;
- sistema responsabile;
- interfacce con altri sistemi;
- feedback richiesto;
- comportamento in fault;
- criterio di verifica;
- responsabile della prova.
La matrice non sostituisce schemi, specifiche o sequence of operation. Serve a rendere visibile il rapporto tra esigenza, implementazione e prova.
Una point list e una matrice funzionale non sono equivalenti. La prima elenca misure, stati, comandi, allarmi e variabili disponibili; la seconda descrive il comportamento richiesto, le responsabilità, le logiche, le priorità e i criteri di verifica. Una point list completa può non chiarire chi decide, quale priorità prevale o che cosa deve accadere quando un dato non è disponibile.
Owner’s Project Requirements e Basis of Design
Nel linguaggio del commissioning, gli Owner’s Project Requirements (OPR) descrivono esigenze, obiettivi e risultati attesi del committente; la Basis of Design (BOD) documenta criteri, assunzioni e scelte progettuali con cui si intende rispondere a tali esigenze. Si tratta di una sintesi metodologica: per definizioni formali, responsabilità e documentazione richiesta in uno specifico processo occorre consultare le edizioni pertinenti di ASHRAE Guideline 0 e ANSI/ASHRAE/IES Standard 202.
La distinzione è utile anche fuori da un processo formale ASHRAE: permette di separare ciò che il committente o il progetto richiede dalle scelte tecniche utilizzate per soddisfarlo.
Requisiti funzionali, prestazionali e informativi
Non tutti i requisiti descrivono lo stesso tipo di risultato.
- Funzionali: che cosa deve fare il sistema;
- prestazionali: con quali tempi, precisioni, capacità o limiti;
- di interoperabilità: quali dati, comandi e responsabilità devono attraversare un’interfaccia;
- di resilienza: quali funzioni devono continuare durante un guasto o una perdita di connettività;
- di sicurezza: quali accessi, ruoli, segmentazioni e protezioni devono essere previsti;
- informativi: quali dati, configurazioni, backup e documenti devono essere consegnati e mantenuti.
Criteri di verifica prima della scelta tecnologica
Ogni requisito importante dovrebbe avere un criterio di verifica definito prima della messa in servizio. Se non è chiaro come verificare una funzione, spesso il requisito non è ancora sufficientemente preciso.
Un criterio di verifica può riguardare stato osservabile, tempo di risposta, valore misurato, sequenza di eventi, persistenza dopo un riavvio, comportamento durante un fault, disponibilità di un dato o capacità di ripristino.
Nel contesto della realizzazione del sistema, la verification raccoglie evidenze che la soluzione soddisfi i requisiti specificati; la validation verifica invece che il sistema risponda all’uso previsto e alle esigenze degli stakeholder. Questa distinzione non va confusa con la requirements verification, che riguarda anche la qualità e la corretta formulazione dei requisiti.
Sequence of operation
Quando una funzione richiede più condizioni o stati, la sequence of operation deve descrivere il comportamento atteso in modo comprensibile e testabile.
Dovrebbe chiarire almeno condizioni iniziali, trigger, stati, priorità, temporizzazioni, fallback, interlock, override, feedback e condizioni di ritorno alla normalità.
Una sequence of operation incompleta viene spesso compensata in cantiere con decisioni implicite nel software. Questo rende più difficile verificare il progetto, trasferirne l’ownership e modificarlo nel tempo.
Interfacce e responsabilità
Ogni punto in cui due sistemi si incontrano deve essere trattato come un requisito di progetto, non come un dettaglio da risolvere successivamente.
Per ogni interfaccia vanno definiti dati, direzione, read/write, comandi, feedback, allarmi, timing, ownership e comportamento in fault. Per questo il progetto dei requisiti è strettamente collegato alla pagina dedicata a Integrazione e interoperabilità.
Progettare per il commissioning
ASHRAE Standard 202 e Guideline 0 impostano il commissioning come processo che collega requisiti del proprietario, documenti di progetto, verifiche, procedure, formazione e documentazione finale. Il principio utile è semplice: ciò che dovrà essere accettato alla fine deve essere progettato in modo da poter essere provato.
CIBSE richiama inoltre il concetto di design for commissionability: la possibilità di testare correttamente un sistema dipende anche da come è stato progettato, strumentato, documentato e reso accessibile.
Acceptance criteria
Un acceptance criterion definisce quando una prova può essere considerata superata. “Funziona” non è un criterio sufficiente.
È preferibile definire condizioni misurabili o osservabili: valore entro un intervallo, risposta entro un tempo, allarme generato nelle condizioni previste, continuità locale durante la perdita del server, ripristino automatico o manuale secondo la sequenza dichiarata.
Requirements traceability
Per i requisiti più importanti è utile mantenere una catena di tracciabilità:
REQUISITO → DOCUMENTO DI PROGETTO → COMPONENTE / LOGICA → TEST → RISULTATO → DOCUMENTAZIONE AS-BUILT
Questa catena consente di capire non solo se una funzione esiste, ma anche perché esiste, dove è implementata, come è stata verificata e cosa deve essere mantenuto nel ciclo di vita.
Il progetto deve descrivere anche il fault
Per le funzioni rilevanti il requisito dovrebbe distinguere almeno funzionamento normale, fault e recovery. Non basta descrivere il comportamento nominale: occorre considerare, quando pertinente, perdita di sensore, perdita di rete, indisponibilità del server, assenza di Internet o cloud, riavvio, perdita di alimentazione, dati non validi e indisponibilità di un sistema integrato.
Devono inoltre essere dichiarate le dipendenze necessarie alla funzione — alimentazione, controller, rete, gateway, server, servizi cloud, account o licenze — e le condizioni necessarie al ripristino. Questo rende visibili i failure domain e impedisce che dipendenze importanti emergano soltanto durante il guasto.
Handover: il requisito continua dopo il collaudo
La consegna deve rendere possibile esercizio, diagnosi, backup, modifica e ripristino del sistema. Per questo anche documentazione, software di engineering, credenziali, database, configurazioni e responsabilità sono requisiti di progetto.
Il tema continua nella sezione Ciclo di vita dei sistemi.
Checklist professionale
- qual è l’esigenza reale;
- qual è il requisito verificabile;
- chi è responsabile della funzione;
- quali condizioni attivano la funzione;
- quali input sono necessari;
- quali output o comandi sono previsti;
- quali prestazioni devono essere raggiunte;
- quali interfacce sono coinvolte;
- chi mantiene l’ownership;
- quale comportamento è richiesto in fault;
- quale feedback dimostra il risultato;
- qual è il criterio di accettazione;
- come viene eseguita la prova;
- chi registra il risultato;
- quale documentazione deve essere aggiornata;
- quali file o configurazioni devono essere consegnati;
- come viene effettuato il restore;
- quali requisiti dipendono da Internet o cloud;
- quali dipendenze dal fornitore devono essere dichiarate;
- come il requisito viene mantenuto nel ciclo di vita.
Riferimenti tecnici correlati
Per il contesto dei sistemi di gestione consulta BMS e BACS; per definizioni, versioni e confini tecnici consulta Riferimenti tecnici.
Per approfondire il passaggio fra requisiti e sistemi diversi vedi anche Gateway, mapping e ownership.