Prima le cose importanti!

Clicca per la sezione precedente: Fase 0

I requisiti vengono prima in ogni progetto IoT ben gestito — prima degli schematici, prima del firmware, prima della prima riga di codice. Avete deciso che la vostra idea di prodotto merita di essere tenuta, e la tentazione ora è buttarvi direttamente nella costruzione. Resistete. La Fase 1 riguarda la raccolta dei requisiti, il fondamento di tutto ciò che segue. Può non sembrare eccitante come accendere un nuovo circuito o scrivere codice, ma pensatela come il tracciare la mappa prima di salpare. I viaggi senza mappe sono avventurosi, certo — semplicemente raramente finiscono bene.

Nella Fase 1: Requisiti degli stakeholder e di sistema, raccogliamo input da tutti gli attori chiave e definiamo esattamente cosa stiamo costruendo e perché: cosa deve fare il prodotto, le condizioni che deve soddisfare e i vincoli che deve rispettare. Il tempo investito qui viene ripagato dopo. Ogni decisione di design, ogni riga di codice e ogni test lungo il percorso risalirà a questi requisiti — sono la stella polare del progetto. Caricate senza di essi e rischiate di costruire la cosa sbagliata, o di scoprire dopo mesi di lavoro che una funzionalità chiave è stata trascurata o che un’assunzione era sbagliata.

In questo capitolo scomponiamo cosa significa catturare i requisiti degli stakeholder e di sistema: perché questa fase conta, i tipi di requisiti da considerare e come documentarli chiaramente. Condivideremo anche esempi che mostrano come definire bene i requisiti all’inizio può decretare il successo o il fallimento di un progetto IoT.

Cosa sono esattamente i requisiti?

Quindi cosa intendiamo per “requisiti”? In termini semplici, sono una descrizione dettagliata di cosa deve fare il vostro prodotto e in quali condizioni deve farlo — il regolamento del progetto, che cattura tutto ciò che ci si aspetta dal dispositivo prima di costruirlo. Se il vostro prodotto fosse una storia, i requisiti sarebbero la scaletta della trama: assicurano che tutti gli elementi chiave siano definiti così che la storia regga alla fine.

I requisiti si presentano in alcune varianti, ciascuna che copre un aspetto diverso del prodotto:

• Requisiti funzionali: Cosa il prodotto deve fare – le sue funzionalità e i suoi comportamenti.
• Requisiti non funzionali: Le qualità e i vincoli del prodotto – quanto bene funziona, quanto dura, e così via.
• Requisiti di interfaccia: Come il prodotto interagirà con altri sistemi e con il mondo esterno.

Attraverseremo ogni categoria in dettaglio. Per ora, ricordate che un buon requisito è chiaro, specifico e testabile. “Il dispositivo dovrebbe essere fantastico” non aiuterà il vostro team di ingegneria. “Il dispositivo deve misurare la temperatura da 0°C a 50°C con accuratezza di ±0,5°C” sì: chiunque lo legga sa esattamente cosa ci si aspetta, e dopo potete testare se il dispositivo lo soddisfa. Questo è il livello di chiarezza a cui puntare.

Requisiti funzionali

I requisiti funzionali descrivono le funzionalità, le funzioni e i comportamenti specifici del vostro prodotto IoT — cosa il sistema deve fare. Se qualcuno chiede “Cosa fa il tuo dispositivo?”, la risposta è un riassunto dei suoi requisiti funzionali: le azioni e i servizi che il dispositivo fornisce all’utente o ad altri sistemi.

Per un dispositivo IoT, i requisiti funzionali spesso includono:

• Rilevamento dati o azioni: Quali dati misura il dispositivo, o quali azioni esegue? (per esempio misura la temperatura, apre una valvola, traccia la posizione)
• Accuratezza e intervallo dei dati: Quanto sono accurate le misurazioni, e su quale intervallo? (per esempio misura la temperatura da 0°C a 50°C con accuratezza di ±0,5°C)
• Frequenza o timing: Con quale frequenza svolge la sua funzione — aggiornamenti ogni minuto, ogni ora? Con quale rapidità deve rispondere? (per esempio una lettura ogni 10 minuti, o una risposta entro 2 secondi)
• Gestione dei dati: Cosa succede ai dati — inviati al cloud, registrati su una memory card, mostrati su un display?
• Modalità o funzionalità specifiche: Per esempio, una modalità allarme quando viene superata una soglia, l’auto-calibrazione, o gli aggiornamenti firmware over-the-air.

Un esempio concreto. Supponiamo che stiate costruendo un semplice sensore di temperatura IoT per uso smart home. Alcuni requisiti funzionali potrebbero essere:

• Il dispositivo deve misurare la temperatura ambiente da 0°C a 50°C con un’accuratezza di ±0,5°C.
• Il dispositivo deve effettuare una lettura del sensore almeno una volta ogni 10 minuti (update rate).
• Dopo ogni lettura, il dispositivo deve trasmettere i dati del sensore a un cloud server entro 30 secondi (latenza dei dati).
• Il dispositivo deve far lampeggiare un LED e inviare un alert se la temperatura supera una soglia definita dall’utente.

Ciascuno descrive qualcosa che il sistema fa, di solito formulato come “Il dispositivo deve…” seguito da un comportamento specifico. Quel formato rende la verifica semplice in seguito: o il dispositivo fa X come specificato, o non lo fa.

Buoni requisiti funzionali dipingono un quadro chiaro delle capacità, così il team di ingegneria sa esattamente cosa implementare. Solo allora i designer hardware e software possono pensare a come realizzarlo — il cosa viene prima, ed è per questo che questi requisiti vengono definiti ora. Senza di essi, potete ritrovarvi con un prodotto che manca ciò di cui l’utente ha davvero bisogno: un’elaborata stazione meteo IoT, per dire, che viene spedita senza sensore di umidità perché nessuno l’ha scritto. Definire i requisiti funzionali all’inizio cattura le funzionalità irrinunciabili prima che ciò accada.

Requisiti non funzionali

I requisiti non funzionali specificano le qualità, le condizioni e i vincoli del prodotto anziché le sue funzionalità: quanto bene funziona, quanto è robusto e quali limiti deve rispettare. Stabiliscono i guardrail per la qualità complessiva, e sono critici quanto le funzionalità stesse — mantengono il dispositivo sicuro, affidabile e pratico nel mondo reale.

Considerazioni non funzionali comuni per un dispositivo IoT:

• Consumo energetico e durata della batteria: Quanto a lungo deve funzionare il dispositivo con una data fonte di alimentazione? Per esempio, “Il prodotto deve funzionare con una singola batteria AA per almeno 1 anno.” Questo forza il focus su componenti a basso consumo e una gestione efficiente dell’energia.
• Affidabilità e longevità: Quanto deve essere robusto il dispositivo nel tempo? Spesso espresso come Mean Time Between Failures (MTBF) o simile — “Il dispositivo deve funzionare ininterrottamente per almeno 5 anni senza un guasto critico.” Questo influenza la selezione dei componenti e i margini di design.
• Sicurezza e privacy: Come proteggerete i dati e la privacy degli utenti? Per esempio “Tutte le trasmissioni di dati devono essere cifrate con AES-256” o “Le credenziali utente devono essere conservate in modo sicuro e mai trasmesse in chiaro.” Nel panorama IoT di oggi, i requisiti di sicurezza sono essenziali per prevenire violazioni.
• Vincoli ambientali e fisici: Le condizioni che il dispositivo deve sopportare, più eventuali limiti di dimensione e peso. “Il dispositivo deve funzionare da -20°C a +60°C ed essere resistente all’acqua secondo IP67” garantisce che sopravviva ad ambienti difficili; “Il dispositivo non deve pesare più di 100 grammi e deve stare in uno spazio di 10cm x 5cm x 3cm” lo mantiene entro il form factor richiesto.
• Vincoli di costo: Probabilmente avete un costo target — “Il costo di produzione unitario non deve superare i 50 $.” Questo guida i compromessi: un componente più economico qui, una funzionalità eliminata là.
• Conformità normativa: Molti prodotti IoT devono soddisfare standard o certificazioni — “Il dispositivo deve essere conforme alle normative CE e FCC per la comunicazione wireless”, o “Deve aderire allo standard di sicurezza ISO 13849” se fa parte di un sistema di macchinario. Questi sono requisiti non negoziabili fissati dagli standard industriali e di sicurezza.

È una lista lunga, ma pensate ai requisiti non funzionali come agli attributi di qualità che il prodotto deve avere. Raramente finiscono nella brochure di marketing, eppure ignorarli fa fallire il prodotto in modi meno evidenti. Un sensore può riportare dati perfettamente (funzionale!) e comunque frustrare ogni utente perché la sua batteria muore in un giorno. Un dispositivo può funzionare bene in laboratorio e comunque cadere al primo attacco perché la sicurezza non è stata integrata fin dall’inizio.

Definire queste qualità all’inizio assicura che il prodotto finale non sia solo ricco di funzionalità, ma robusto, usabile e sostenibile. I requisiti non funzionali guidano le scelte dei componenti, l’architettura software (affidabilità, sicurezza), il design meccanico (durata, dimensioni) e persino il modo in cui testerete. Lavorano dietro le quinte, ma sono essenziali per soddisfare le aspettative degli stakeholder e sopravvivere al deployment nel mondo reale.

Requisiti di interfaccia

I requisiti di interfaccia definiscono come il vostro prodotto si connette e interagisce con il mondo esterno — fisicamente e logicamente. Le interfacce sono i punti di contatto tra il vostro dispositivo e tutto il resto: altro hardware, fonti di alimentazione, contenitori, utenti e sistemi software. Questa categoria assicura che il dispositivo si inserisca nel suo ecosistema previsto e comunichi correttamente al suo interno.

Aspetti coperti dai requisiti di interfaccia:

• Interfacce elettriche: Qualsiasi connessione o segnale elettrico. Il dispositivo ha bisogno di un ingresso di alimentazione specifico (USB-C, terminali per batteria)? Emette una tensione analogica (un segnale 0-5V) o fornisce un’interfaccia digitale (I²C, SPI, UART) verso altro hardware? Un requisito potrebbe essere “Il dispositivo deve avere una porta USB-C per alimentazione e connettività dati” o “Deve fornire un’uscita analogica 0-5V proporzionale alla lettura del sensore.”
• Interfacce di comunicazione: Come il dispositivo parla al cloud, a uno smartphone o ad altri dispositivi — rete e protocolli. Per esempio, “Il dispositivo deve connettersi al cloud via Wi-Fi e usare il protocollo MQTT per pubblicare i dati del sensore”, o “Deve supportare Bluetooth Low Energy (BLE) per comunicare con un’app per smartphone.” Se serve un’API, specificate anche quella: “Il servizio cloud deve fornire un endpoint REST API per il recupero dei dati del dispositivo.”
• Interfacce meccaniche: La forma fisica e l’adattamento. Quanto può essere grande il dispositivo, e come viene montato o racchiuso? “Il PCB del dispositivo deve essere 5cm x 5cm per entrare in un contenitore standard”, o “Deve avere fori di montaggio compatibili con una staffa in stile GoPro.” La protezione da acqua e polvere è sia un requisito ambientale sia una considerazione di interfaccia meccanica: “Il contenitore deve avere grado IP67 per la resistenza ad acqua e polvere.” Il punto è che il dispositivo si integri fisicamente ovunque debba andare.
• Interfaccia utente (UI) e controlli: Elementi con cui l’utente interagisce — pulsanti, schermi, LED. “Il dispositivo deve includere un pulsante di reset fisico accessibile all’utente”, o “Deve avere un indicatore LED che lampeggia durante la trasmissione dei dati.” Questi definiscono come gli utenti ottengono informazioni dal dispositivo o gli inviano comandi.

Definire bene i requisiti di interfaccia chiarisce come tutti i pezzi si collegano. Se state progettando un sensore che si attacca a una macchina industriale, un requisito di interfaccia meccanica specifica le dimensioni e il pattern dei fori per le viti così che entri davvero. Se il dispositivo è alimentato a batteria, un requisito di interfaccia elettrica assicura un connettore standard così che l’utente possa ricaricarlo facilmente. Ne mancate uno, e ottenete l’esito classico: un dispositivo perfettamente valido a cui nessuno riesce a connettersi perché manca la porta giusta.

In breve, i requisiti di interfaccia assicurano che il vostro dispositivo funzioni con il suo ambiente e i suoi utenti — che si tratti di una smart home, di un impianto industriale o di una persona con un telefono. Trascurarli è spesso la differenza tra un prodotto compatibile e facile da usare e uno che causa mal di testa durante l’integrazione.

Coinvolgere gli stakeholder fin da subito

Da dove vengono tutti questi requisiti? Non dal nulla — li raccogliete dai vostri stakeholder: tutti coloro che hanno un interesse nel successo del prodotto. Questo include i candidati ovvi, utenti finali e clienti, ma anche marketing, vendite, ingegneri di diverse discipline (hardware, software, firmware), project manager ed esperti di normative o conformità. Ogni gruppo ha i propri bisogni e le proprie preoccupazioni, e i requisiti dovrebbero catturare ogni prospettiva critica.

Identificate i vostri stakeholder e coinvolgeteli presto, perché sono loro a definire come sarà il “successo”. Il marketing potrebbe dire: “Deve costare meno di 50 $ e durare un anno con una carica — è quello che i nostri clienti si aspettano.” Gli utenti finali (o una persona rappresentativa) potrebbero aver bisogno che il setup sia semplice e la manutenzione minima. Il team software potrebbe aver bisogno di un’API robusta per integrarsi con una piattaforma cloud. L’esperto di sicurezza insisterà su cifratura e autenticazione. Un responsabile della conformità vi ricorderà i limiti di emissione radio FCC o gli standard di sicurezza elettrica. Tutti questi input diventano requisiti.

Far emergere questi bisogni ora costa molto meno che dopo. Sessioni di brainstorming, workshop o semplici interviste con ogni gruppo di stakeholder costruiranno un elenco completo. Non fatelo in una bolla: un requisito scritto senza l’input degli stakeholder può mancare il bersaglio. Saltate il team di assistenza clienti e potreste trascurare “Il dispositivo deve fornire un meccanismo di reset per ripristinare le impostazioni di fabbrica” — importante per la risoluzione dei problemi. Saltate la produzione e potreste specificare un design troppo costoso o troppo difficile da produrre in volume.

Il coinvolgimento precoce crea anche adesione. Quando le persone vedono le proprie preoccupazioni affrontate nei requisiti, sostengono il progetto, e meno sorprese emergono dopo. Gli stakeholder portano esperienza — usarla ora risparmia cambiamenti dolorosi lungo la strada.

Man mano che questi input si accumulano, prende forma il quadro dei requisiti funzionali, non funzionali e di interfaccia necessari. Questa fase è essenzialmente un colmare il divario tra un’idea promettente e un prodotto chiaramente definito: desideri sfumati (“Deve essere economico! Deve essere sicuro! Deve fare X e Y!”) diventano requisiti precisi con cui gli ingegneri possono lavorare, parlando con le persone giuste e facendo le domande giuste.

La raccolta dei requisiti è uno sport di squadra. Portate gli attori chiave nella stanza — letteralmente o figurativamente — e definite cosa deve fare il dispositivo. Più punti di vista incorporate ora, meno punti ciechi vi portate nelle fasi successive.

Documentare e tracciare i requisiti

Una volta raccolti, i requisiti devono essere scritti chiaramente e organizzati. Una registrazione ben strutturata mantiene tutti sulla stessa pagina e assicura che nulla vada perso. In pratica, i team usano metodi diversi:

• Documento formale dei requisiti: Molti progetti creano una System Requirements Specification (SRS) o un Product Requirements Document (PRD) — un documento strutturato (a volte secondo standard come IEEE 29148) in cui ogni requisito è elencato, spesso con un identificativo unico (per esempio REQ-001: Il dispositivo deve fare X). I documenti formali si adattano ai settori in cui serve tracciabilità rigorosa: aerospaziale, automotive, dispositivi medici.
• Backlog agile (user story): Alcuni team, specialmente quelli agili, catturano i requisiti come user story, epic o elementi in uno strumento come Jira o una wiki. Per esempio: “Come proprietario di casa, voglio che il sensore mi avvisi quando la temperatura di casa supera i 30°C così da poter accendere il condizionatore.” Una story come questa si scompone in requisiti specifici per il team di ingegneria (un requisito funzionale per un alert di sovratemperatura, per esempio). I formati agili sono più liberi, ma i requisiti sottostanti devono comunque essere specifici e testabili.

Qualunque formato scegliate, mantenete ogni requisito non ambiguo e testabile. Evitate parole vaghe come “ottimale”, “facile da usare” o “sufficiente” senza quantificazione; usate numeri concreti o criteri chiari. Invece di “la durata della batteria dovrebbe essere lunga”, scrivete “la durata della batteria deve essere di almeno 12 mesi con una singola carica con upload di dati orari.” È un obiettivo su cui i designer possono lavorare, senza congetture.

Un’altra abitudine utile: etichettate ogni requisito con come lo verificherete in seguito — pensate in anticipo a come dimostrerete che il prodotto lo soddisfa. Metodi di verifica comuni:

• Test: Testare direttamente il dispositivo contro il requisito. (Per esempio misurare quanto a lungo funziona con una batteria per verificare la durata di 12 mesi.)
• Analisi: Usare calcoli o simulazioni. (Per esempio analizzare gli algoritmi di cifratura contro i requisiti di sicurezza, o calcolare il consumo energetico per stimare la durata della batteria.)
• Ispezione: Verificare osservando o misurando il prodotto finito. (Per esempio misurare le dimensioni del dispositivo con un calibro contro il requisito di dimensione, o ispezionare il PCB per il conformal coating applicato per l’impermeabilità.)
• Certificazione/Dimostrazione: Verificare tramite certificazione o conformità dimostrata. (Per esempio inviare il dispositivo a un laboratorio per certificare che soddisfa gli standard normativi FCC/CE, o eseguire un test di ingresso dell’acqua per dimostrare il requisito IP67.)

Etichettare il metodo di verifica all’inizio — alcuni team aggiungono una colonna “Metodo di verifica” al documento dei requisiti — forza ogni requisito a essere formulato in modo da poter essere dimostrato in seguito. Vi risparmia anche il momento della fase di test in cui qualcuno chiede: “Aspetta, come controlliamo se abbiamo raggiunto questo obiettivo vago?”

Infine, mantenete il documento dei requisiti aggiornato. Man mano che il progetto evolve potreste rifinire o aggiungere requisiti (idealmente non troppi, se il lavoro iniziale è stato approfondito). Un elenco organizzato e sotto version control — anche un semplice foglio di calcolo o un documento vivo — mantiene tutti allineati sui requisiti concordati correnti, e aiuta i nuovi membri del team a mettersi in pari su cosa il prodotto dovrebbe fare.

In breve: non scarabocchiate i requisiti su post-it sperando nella buona sorte. Scriveteli in modo chiaro e strutturato — un documento formale o un backlog ben mantenuto. La chiarezza ora previene la confusione dopo, e pianificare la verifica presto spiana la strada a una fase di test più fluida.

Per concludere la Fase 1

Ancora una volta, prima di andare avanti: cambiare un requisito in ritardo è come decidere di aggiungere una camera da letto dopo che la casa è stata costruita — possibile, ma doloroso e costoso. Nell’IoT, “doloroso e costoso” può significare una riprogettazione completa del PCB perché un sensore è stato dimenticato, o una revisione importante del firmware perché un caso d’uso non era stato considerato. Può significare ritardi, sforamenti di budget o, nel peggiore dei casi, un prodotto che tradisce i suoi utenti e stakeholder.

Investire lo sforzo ora per catturare requisiti chiari degli stakeholder e di sistema dà al progetto il suo progetto e la sua roadmap. I requisiti diventano il punto di riferimento per tutti i coinvolti:

• Gli hardware engineer li usano per scegliere i componenti e progettare circuiti che soddisfano le specifiche.
• Gli sviluppatori software e firmware scrivono codice per implementare le funzioni e le prestazioni specificate.
• I tester creano piani di test direttamente dai requisiti — ogni requisito verificabile si traduce naturalmente in uno o più test case.
• I project manager tracciano i progressi spuntando i requisiti soddisfatti e assicurandosi che nulla di critico venga abbandonato.
• Gli stakeholder ottengono una visione trasparente di cosa il prodotto farà — e non farà.

Quando disaccordi o nuove idee appaiono in seguito, il documento dei requisiti è la stella polare che mantiene il team allineato. Se qualcuno propone feature creep a metà dello sviluppo, potete chiedere: “È nello scope secondo i nostri requisiti concordati? Se no, cosa sacrificiamo per aggiungerlo?”

Quindi prendetevi il tempo per fare bene la Fase 1. Fate entrare gli stakeholder, ragionate sulle funzioni e sui vincoli, scrivete tutto chiaramente e ricontrollate che il tutto regga. Iterare su una specifica costa molto meno che iterare su un dispositivo fisico o su una codebase. Fate bene questa fase, e preparate ogni fase che segue.

Con un solido insieme di requisiti degli stakeholder e di sistema in mano, siete pronti ad andare avanti verso il design e la costruzione di qualcosa che li soddisfi. E mentre lo fate, portate la mappa con voi — prima le cose importanti, fatte bene.