Ingegneria dei requisiti nello sviluppo hardware

Siamo onesti: pochissime persone si entusiasmano per i requisiti. Eppure, ogni team hardware ha sperimentato il costo di requisiti poco chiari: rilavorazioni che emergono tardi oppure una build che non soddisfa ciò che gli stakeholder avevano effettivamente richiesto. 

Il requirements engineering (RE) è la disciplina che segue un processo strutturato per definire, documentare e gestire i requisiti, in modo che il prodotto finale risolva il problema giusto. Se applicato bene, consente di intercettare gli errori in anticipo, mantenere il team allineato e dare a tutti la certezza che ciò che viene rilasciato sia ciò che era stato effettivamente concordato di realizzare.

Tuttavia, il termine viene spesso frainteso perché affonda le sue radici sia nell’ingegneria del software sia nell’ingegneria dei sistemi applicata ai prodotti hardware. 

In questo articolo troverai una definizione chiara di requirements engineering e del suo ruolo nello sviluppo di prodotti hardware. Tratteremo sia una panoramica teorica sia un framework pratico di come viene applicato in un progetto hardware, con esempi reali e un elenco delle insidie più comuni, oltre a come evitarle.

Punti chiave

• Il requirements engineering aiuta i team hardware a trasformare l’intento progettuale in requisiti chiari e a mantenere allineate tutte le persone del team.
• I requisiti guidano il progetto dalla pianificazione e progettazione iniziali fino ai test, alle modifiche e alla documentazione finale.
• Un buon processo di gestione dei requisiti aiuta i team di sviluppo a individuare i problemi in anticipo, evitare costose riprogettazioni e garantire che il prodotto finale soddisfi quanto concordato.

Che cos’è il Requirements Engineering?

Il requirements engineering è un approccio sistematico e disciplinato alla definizione, documentazione e gestione dei requisiti durante lo sviluppo di prodotti hardware.

Aiuta i team a comprendere il problema da risolvere, chiarire e analizzare le esigenze degli stakeholder, risolvere conflitti e compromessi, documentare ciò che il prodotto deve ottenere e mantenere aggiornata questa comprensione man mano che il prodotto evolve.

In pratica, i requisiti creano una comprensione condivisa tra stakeholder e team di ingegneria su che cosa si sta realizzando, perché lo si sta realizzando e come il team stabilirà se il prodotto finale soddisfa l’intento progettuale.

Vantaggi del Requirements Engineering

Quando il RE è svolto bene, aiuta a prevenire incomprensioni ed errori costosi, mantiene il team allineato e contribuisce a garantire che il prodotto finale soddisfi i requisiti.

I principali vantaggi del RE includono:

• Visione condivisa: mantiene stakeholder, manager e team di ingegneria allineati sulla stessa comprensione di ciò che si sta realizzando.
• Ambito chiaro: chiarisce cosa fa parte del progetto e cosa no, aiutando a prevenire aggiunte incontrollate note come scope creep.
• Riduzione degli errori costosi: aiuta a individuare tempestivamente i problemi nei requisiti, prima che si trasformino in costose rilavorazioni di progetto, nuovi prototipi o test ripetuti.
• Migliore pianificazione e schedulazione: offre ai team un quadro più chiaro di ciò che deve essere realizzato, rendendo più semplice stimare il lavoro e creare tempistiche realistiche.
• Migliore qualità del prodotto: aiuta a garantire che il prodotto finale faccia ciò che è stato concordato e soddisfi gli standard di qualità richiesti.

Evoluzione della disciplina del Requirements Engineering

Il requirements engineering affonda le sue radici sia nell’ingegneria dei sistemi sia nell’ingegneria del software. Queste due tradizioni si sono sviluppate in contesti ingegneristici differenti, quindi il termine può ancora avere una portata leggermente diversa a seconda della fonte.

Nel contesto dell’ingegneria del software, l’attenzione è rivolta principalmente ai requisiti di sviluppo software: che cosa il software deve fare, come deve comportarsi e quali attributi di qualità deve soddisfare. Gli ingegneri del software pensano a requisiti funzionali e non funzionali documentati come user story, casi d’uso e criteri di accettazione. Nel contesto dell’ingegneria dei sistemi, l’ambito è più ampio. I requisiti si riferiscono all’intero sistema, inclusi hardware, software, persone, processi, interfacce, condizioni operative e altre caratteristiche del sistema. Gli ingegneri di sistema parlano di requisiti di livello di sistema allocati verso il basso in hardware, meccanica, elettronica, firmware e fattori di sicurezza, registrati come dichiarazioni formali di requisito e matrici di tracciabilità dei requisiti.

Nello sviluppo hardware, il RE riunisce entrambe le prospettive. Combina il rigore e l’ambito multidisciplinare dell’ingegneria dei sistemi, necessari per gestire i costi della bill of materials (BOM), i vincoli termici e le limitazioni produttive, con la tracciabilità lungo il ciclo di vita usata nell’ingegneria del software per mantenere i requisiti verificabili e collegati durante tutto lo sviluppo.

Discipline correlate al Requirements Engineering

Il requirements engineering è strettamente legato ad altre discipline dello sviluppo prodotto, in particolare all’ingegneria dei sistemi e al product management.

Ingegneria dei sistemi

L’ingegneria dei sistemi considera un prodotto come un sistema completo. Un ingegnere di sistema si assicura che le diverse parti, come hardware, software, componenti meccanici e testing, funzionino correttamente insieme e non entrino in conflitto.

Questo è strettamente connesso al RE perché i requisiti forniscono a tutti questi team un riferimento comune per ciò che il prodotto deve ottenere.

Se ti piacciono le analogie, immagina di costruire una casa. Diversi specialisti si occupano delle fondamenta, dell’impianto elettrico, dell’idraulica e del riscaldamento, ma serve comunque qualcuno che si assicuri che tutte queste parti si integrino davvero in un’unica struttura completa. L’ingegneria dei sistemi svolge esattamente questo ruolo nello sviluppo di prodotto.

Product Management

Il product management aiuta a decidere cosa costruire e perché. I product manager parlano con i clienti, studiano il mercato, analizzano i concorrenti e collaborano con il business per decidere quali problemi valga la pena risolvere e quali funzionalità contino di più.

Anche questo è collegato al RE, perché queste esigenze dei clienti e questi obiettivi di business di alto livello diventano il punto di partenza per definire i requisiti del prodotto.

Fasi del processo di Requirements Engineering

Il processo RE può essere organizzato in modi diversi a seconda dell’area applicativa, delle persone coinvolte e dell’organizzazione. In alcuni progetti, le attività avvengono per lo più una dopo l’altra, mentre in altri vengono ripetute e riviste man mano che il team apprende di più.

Come descritto in un articolo pubblicato sulla rivista Requirements Engineering, un comune approccio da manuale suddivide il processo RE in quattro attività fondamentali (fasi):

• Raccolta dei requisiti: raccolta dei requisiti da stakeholder e altre fonti per capire cosa il sistema deve fare e in quali condizioni deve operare.
• Analisi e specifica dei requisiti: revisione di quanto raccolto, risoluzione di informazioni poco chiare o in conflitto e trasformazione del tutto in requisiti chiari che il team di ingegneria possa utilizzare.
• Validazione dei requisiti: verifica che i requisiti siano corretti, completi e descrivano ciò che il sistema è destinato a ottenere.
• Gestione dei requisiti: tracciamento dei requisiti e delle loro modifiche nel tempo, inclusi i motivi del cambiamento e quali altri requisiti, attività di progettazione o test possano esserne influenzati.

Chi è coinvolto nel processo

Diversi ruoli chiave sono coinvolti nel framework RE e collaborano per definire cosa un prodotto deve fare:

• Responsabile dei requisiti: l’ingegnere che prende esigenze vaghe degli stakeholder, pone le domande giuste e le trasforma in un insieme di requisiti che il team di ingegneria possa effettivamente usare per lo sviluppo del prodotto. Spesso si tratta di un Systems Engineer, di un Lead Engineer o di una figura con responsabilità simili.
• Leadership tecnica di prodotto: le persone che comunicano con la parte stakeholder/business, ne comprendono le esigenze e poi trasformano quella richiesta in un obiettivo di prodotto chiaro. Possono includere Product Manager, Program Manager o ruoli simili.
• Ingegnere dell’implementazione: l’ingegnere che utilizza quei requisiti definiti per progettare e realizzare la propria parte del prodotto. Può trattarsi di ingegneri elettronici, meccanici, software o firmware.
• Responsabile della verifica: la persona che decide come verranno testati i requisiti e si assicura che le revisioni e i test necessari vengano completati. Può includere Verification Engineer, Test Engineer o QA Engineer.

Framework pratico di Requirements Engineering per lo sviluppo hardware

Sebbene le quattro attività sopra descritte definiscano il nucleo del processo RE, i team hardware hanno bisogno di un modo pratico per applicarle lungo tutto il progetto.

Di seguito presentiamo una visione pratica del framework di requirements engineering per lo sviluppo hardware, mostrando come i requisiti si inseriscono in ogni fase.

Avvio del progetto: acquisire l’intento

All’inizio di un progetto, i Technical Lead ricevono solitamente input vaghi come richieste del cliente, richieste di offerta (RFP), obiettivi di business o vincoli su costi, dimensioni o tempi. Per esempio, un cliente potrebbe chiedere un dispositivo più piccolo che supporti uno specifico caso d’uso.

Insieme al Responsabile dei requisiti, i Technical Lead chiariscono ciò che è necessario e trasformano questi input in requisiti di alto livello che descrivono cosa il prodotto deve ottenere.

Requirements Engineering: definire i requisiti

I requisiti di alto livello della fase di avvio del progetto sono ancora troppo generici per la progettazione di dettaglio. In questa fase, il Responsabile dei requisiti definisce il sistema nel suo complesso, lo suddivide in parti e sottosistemi e trasforma quei requisiti di alto livello in requisiti più specifici per ciascuna parte.

Verifica inoltre che i requisiti non siano in conflitto, che non manchi nulla di importante e che ciascuno sia chiaro e verificabile. Il risultato è un insieme concordato di requisiti che il team di ingegneria può usare come punto di partenza per la progettazione del prodotto.

Implementazione: sviluppare i progetti

Gli ingegneri dell’implementazione utilizzano i requisiti concordati per progettare e realizzare la propria parte del prodotto, che ciò significhi creare uno schema elettrico, modellare una parte 3D oppure scrivere software o firmware. Man mano che il progetto si sviluppa, collegano ogni requisito alla caratteristica di progetto che lo soddisfa. Questi collegamenti creano la tracciabilità del progetto e aiutano il Responsabile dei requisiti a vedere come i requisiti sono stati implementati.

Verifica e validazione: testare e verificare

Anche i requisiti definiscono cosa controllare durante revisioni e test. Il Verification Engineer definisce come verrà verificato ciascun requisito e collabora con gli ingegneri dell’implementazione per eseguire le revisioni, misurazioni o prove necessarie, registrandone i risultati. Questo collega ciò che il prodotto doveva ottenere con le evidenze che mostrano se lo abbia effettivamente ottenuto.

Gestione delle modifiche: rivedere e iterare

I requisiti e i progetti di prodotto cambiano spesso durante lo sviluppo. Un requisito può rivelarsi impossibile da soddisfare, un componente può diventare indisponibile sul mercato oppure può emergere un nuovo vincolo. Quando ciò accade, il Responsabile dei requisiti tiene traccia di cosa è cambiato, perché è cambiato e di quali requisiti, parti del progetto o test risultano interessati.

Documentazione e handover: consegnare il progetto

Alla fine del progetto, il Responsabile dei Requisiti collabora con l’Ingegnere della Verifica e con il resto del team per chiudere i requisiti, le revisioni di progetto e le attività di verifica. La documentazione finale deve fornire una registrazione tracciabile di ciò che era richiesto, di ciò che è stato realizzato e di come è stato verificato. Clienti, produttori, revisori o team che continueranno a lavorare sul prodotto avranno bisogno di queste informazioni in seguito.

Esempi di Requirements Engineering

Requirements Engineering nei dispositivi medici

Il Requirements Engineering viene utilizzato in tutti i prodotti medicali e nelle tecnologie per l’assistenza. I requisiti accompagnano il prodotto durante tutto lo sviluppo. I team trasformano le esigenze degli stakeholder in requisiti di sistema strutturati, li mantengono collegati man mano che le specifiche cambiano e li usano per pianificare la verifica e documentare i risultati dei test.

I dispositivi medici aggiungono un ulteriore livello normativo. I team dedicano più impegno alla tracciabilità, alla verifica, alla documentazione e alle pratiche amministrative. Questo supporta l’approvazione normativa nell’ambito di framework quali FDA 21 CFR Part 820 negli Stati Uniti e ISO 13485:2016 nell’UE e in altri mercati.

Il paradenti HitIQ è un esempio di dispositivo medicale indossabile in cui le esigenze di sicurezza determinano ogni specifica tecnica. Scopri come viene realizzato nella Customer Success story completa.

Requirements Engineering nell’elettronica di consumo e industriale

Il processo di base del requirements engineering è simile nell’elettronica di consumo e in quella industriale, ma i prodotti vengono sviluppati in condizioni diverse. I prodotti consumer come i dispositivi per la smart home o i wearable vengono venduti in grandi volumi e lanciati rapidamente. I prodotti industriali come i controllori logici programmabili (PLC) o gli azionamenti motore devono funzionare per anni in condizioni difficili.

In entrambi i casi, i team definiscono per iscritto ciò che il prodotto deve fare, collegano ogni requisito al progetto, aggiornano i requisiti quando qualcosa cambia e li testano rispetto a essi.

Ciò che cambia è dove i team concentrano lo sforzo aggiuntivo. Nell’elettronica di consumo, questo sforzo va nel tenere il passo con i cambiamenti rapidi, perché un requisito frainteso può significare riprogettare la scheda. Nell’elettronica industriale, va nella verifica, perché il prodotto deve essere testato per una lunga durata e per condizioni difficili prima della spedizione.

Per realizzare hardware affidabile e conforme alle normative di sicurezza, è fondamentale mantenere collegati requisiti e modifiche di progetto. Leggi come MakeSafe Tools gestisce questo aspetto nella storia di successo completa.

Come evitare gli errori comuni del Requirements Engineering

Il requirements engineering presenta alcune sfide comuni. Sapere cosa può andare storto rende più facile individuare i problemi in anticipo ed evitarli durante lo sviluppo di prodotti hardware.

Ecco alcuni dei problemi più comuni da tenere d’occhio e come evitarli:

Strumenti software per il Requirements Engineering

Gestire un piccolo insieme di requisiti è relativamente semplice. Man mano che un progetto cresce, mantenere tutto organizzato e aggiornato richiede più impegno. A quel punto, il modo in cui gestisci i requisiti inizia a contare di più.

In pratica, i team di solito lavorano con uno di questi approcci:

• Fogli di calcolo e documenti: familiari e facili con cui iniziare, il che li rende utili per progetti più piccoli. Tuttavia, man mano che il progetto cresce, richiedono più lavoro manuale per essere mantenuti.
• Strumenti dedicati di Requirements Management (RM): offrono più struttura e controllo man mano che i progetti diventano più complessi. Il compromesso è che alcuni strumenti introducono anche più processi di quanti un team piccolo possa aver bisogno.

L’obiettivo è usare un livello di struttura sufficiente per il progetto, senza rendere la gestione dei requisiti più complicata del necessario.

Per i team hardware più piccoli che hanno superato i limiti dei fogli di calcolo ma non hanno bisogno di un ampio flusso di lavoro RM enterprise, Requirements Portal è un’opzione pratica da considerare. È progettato per offrire ai team più piccoli un modo più strutturato di gestire i requisiti senza il sovraccarico di un sistema enterprise tradizionale.

Conclusione e passaggi successivi

A questo punto, dovresti avere una chiara comprensione dei principali concetti del requirements engineering e di come si applicano nella pratica.

Se vuoi continuare ad approfondire il requirements engineering, queste risorse sono un buon punto di partenza:

• ISO/IEC/IEEE 29148:2018 fornisce lo standard internazionale per i processi e le pratiche di requirements engineering. Offre indicazioni aggiuntive su come i requisiti dovrebbero essere scritti, strutturati, documentati e gestiti.
• NASA Systems Engineering Handbook fornisce indicazioni pratiche su come i requisiti vengono creati, scritti, verificati e utilizzati durante lo sviluppo del sistema.
• Guide to the Systems Engineering Body of Knowledge (SEBoK) spiega come i requisiti si inseriscono nel più ampio processo di systems engineering e come le diverse parti di un sistema vengono sviluppate insieme.
• Requirements Engineering journal pubblica ricerche, esempi industriali e diversi approcci al requirements engineering con maggiore approfondimento.

Se sei pronto a passare dalla teoria alla pratica, prova Requirements Portal e inizia oggi stesso a lavorare con requisiti strutturati su un progetto hardware reale, gratuitamente e senza necessità di configurazione.

Domande frequenti

Perché il Requirements Engineering è importante?

Il requirements engineering è importante perché aiuta il team a realizzare il prodotto giusto comprendendo chiaramente le esigenze degli stakeholder prima che progettazione e sviluppo vadano troppo avanti.

Qual è il ruolo di un Requirements Engineer?

Un requirements engineer trasforma le esigenze degli stakeholder in requisiti chiari che il team di ingegneria può usare e mantiene tali requisiti organizzati man mano che il progetto cambia. Funge da ponte tra clienti e team di sviluppo. 

Qual è la differenza tra Requirements Engineering e Requirements Management?

Il requirements engineering è l’intero processo di individuare, comprendere e mettere per iscritto ciò che un sistema deve fare fin dall’inizio. Il requirements management è la parte specifica di quel lavoro che mantiene tali requisiti organizzati e tiene traccia di eventuali modifiche una volta che sono stati scritti.