Creazione di un Piano di Gestione dei Requisiti di Ingegneria

Javier Alcina Espigado
|  Creato: novembre 27, 2024
Creazione di un Piano di Gestione dei Requisiti di Ingegneria

Identificare e stabilire un insieme di requisiti all'inizio di qualsiasi progetto è fondamentale per raggiungere il successo. Questo articolo, in modo semplice, mira a introdurvi alla creazione di un piano di gestione dei requisiti nei progetti di ingegneria attraverso alcuni concetti di base e l'uso di Altium 365 Requirements & Systems Portal.

Questo blog è destinato a ingegneri, professionisti, project manager, product manager e chiunque abbia la necessità di comprendere come creare un piano di gestione dei requisiti.

Cos'è un Requisito?

Sebbene possa sembrare ovvio, vale la pena riflettere sulla questione 'cos'è un requisito?' Un requisito, secondo il dizionario, è 'una circostanza o condizione necessaria per qualcosa.' Nel mondo dell'ingegneria, i requisiti sono un modo di comunicare tra utenti o clienti e gli sviluppatori di un progetto. A volte, specialmente in progetti di grandi dimensioni, questa è una delle poche modalità possibili per gli utenti di dire agli sviluppatori cosa vogliono.

Esempio di un requisito in un progetto automobilistico:

'Gli utenti devono essere in grado di viaggiare automaticamente a velocità predefinite mediante il controllo della crociera.'

Perché i Requisiti sono così Importanti?

Si dice che: "una cattiva definizione e gestione dei requisiti può costarti una fortuna e portare al fallimento nell'esecuzione del progetto."

La definizione dei requisiti è così importante che generalmente costituiscono la base dei contratti tra clienti e fornitori. Ciò che è definito nei requisiti deve essere considerato nel progetto e può essere richiesto dal cliente, tuttavia, ciò che non appare nella definizione dei requisiti non potrà essere richiesto nella fase di consegna del progetto.

Quindi, se siamo responsabili della stesura dei requisiti, dovremmo:

  • Scoprire esattamente le esigenze del cliente.
  • Creare un documento con una struttura chiara e requisiti ben organizzati.
  • Organizzare un incontro con il cliente per verificare che entrambe le parti abbiano interessi scritti (contratto).
  • Assicurare che la soluzione adottata sia fedele ai requisiti man mano che il progetto progredisce.
  • Verificare e testare la conformità ai requisiti.

Questo insieme di azioni è noto come il piano di gestione dei requisiti. È molto importante avere un manager o un team di gestione nell'organizzazione che identifichi, definisca e tracci i requisiti durante la vita del progetto.

Come Dovrebbe Essere Scritto un Requisito?

Scrivere un requisito non è semplice e banale come può sembrare. Si tratta di un documento che deve soddisfare determinati criteri. Pertanto, un requisito deve:

  • Essere chiaro, preciso e specifico: deve descrivere chiaramente ed esattamente ciò che è necessario.
  • Essere conciso: usare il minor numero di parole possibile.
  • Usare un linguaggio semplice: evitare di confondere il lettore con termini tecnici o parole complicate.

Esempio di un requisito ben scritto:

  • Tutti i componenti (SMD e thru-hole) devono essere posizionati sulla faccia SUPERIORE.

Esempio di un requisito scritto male:

  • I componenti SMD devono essere tutti posizionati sullo stesso lato, e si deve assicurare che la saldatura dei componenti thru-hole sia sul lato opposto rispetto alla saldatura dei componenti SMD.

Nell'esempio sopra, il requisito ben scritto è conciso e definisce perfettamente senza ambiguità ciò che è richiesto, mentre il requisito scritto male ha troppo testo, che non contribuisce a nulla, confonde il lettore ed è impreciso (non definisce su quale lato debbano essere posizionati i componenti).

I requisiti sono sempre obbligatori e, pertanto, dovrebbero essere scritti utilizzando "deve". Quando i requisiti sono preferenze o desideri (non obbligatori) "dovrebbe" può essere usato per definirli o anche "può" quando si tratta di un suggerimento o di un permesso concesso.

Regole Base per Definire un Requisito

Oltre a quanto sopra, quando definiamo un requisito, questo deve seguire alcune regole base:

  • Deve avere un ID unico.
  • Dovrebbe essere comprensibile di per sé senza informazioni aggiuntive.
  • Deve essere coerente con il resto dei requisiti.
  • Deve essere sempre aggiornato (controllo della versione).
  • Deve essere fattibile (evitare requisiti impossibili).
  • La sua implementazione deve essere verificata tramite ispezione, dimostrazione o test.

Identificazione dei Requisiti

Ogni requisito definito deve avere un ID unico in modo che possa essere riferito durante la definizione e la revisione dei requisiti, così come in qualsiasi momento durante la fase di esecuzione del progetto. Un esempio di identificazione dei requisiti è mostrato utilizzando Altium 365 Requirements and Systems Portal.

Identification of Requirements in Altium 365 Requirements and Systems Portal

Quali Tipi di Requisiti Esistono e Come Sono Classificati?

Esistono principalmente due tipi di requisiti:

  • Requisiti Funzionali: Questi definiscono la funzionalità del sistema.
  • Requisiti Non Funzionali: Questi impongono vincoli o limitazioni alla soluzione (ambientali, affidabilità, compatibilità elettromagnetica, sicurezza, normative applicabili, requisiti di costo, tempistiche, ecc.).

La combinazione di questi requisiti funzionali e non funzionali costituisce quello che è noto come specifica del sistema. Nella specifica del sistema, i requisiti sono raggruppati secondo i seguenti livelli:

  • Requisiti iniziali o del cliente
  • Requisiti di sistema
  • Requisiti di sottosistema

Requisiti iniziali o del cliente sono quelli che vengono forniti direttamente dal cliente o dall'utente prima dell'inizio del progetto. Sono fondamentali, poiché catturano le esigenze del cliente e quindi servono come punto di partenza per creare la nostra matrice dei requisiti. Successivamente, la specifica del sistema organizza i requisiti in base al livello di dettaglio pertinente a ciascuna parte del progetto. In questo modo, abbiamo requisiti di sistema, che si applicano all'intero sistema, e requisiti di sottosistema, che si applicano solo a parti specifiche del sistema. Illustreremo questo con un esempio.

Supponiamo di essere impegnati nello sviluppo di un progetto per la creazione di un nuovo smartwatch. I requisiti di sistema, quindi, sono quelli applicabili all'insieme (vedi gli esempi di seguito):

  • REQ-01: Dovrà essere progettato per utenti adulti.
  • REQ-02: Dovrà visualizzare tutte le informazioni sullo schermo.
  • REQ-03: Dovrà essere ricaricabile.
  • REQ-04: Dovrà avere pulsanti o altri meccanismi per la navigazione dell'utente attraverso i menu.

Una volta definiti i requisiti di sistema, i restanti requisiti vengono suddivisi in diversi sottosistemi.

Seguendo l'esempio del progetto di sviluppo dello smartwatch, gli esempi di sottosistemi includono:

  • Sottosistema 1 – Cinturino
  • Sottosistema 2 – Display
  • Sottosistema 3 – Alimentazione
  • Sottosistema 4 – Comunicazioni
  • Sottosistema 5 – Interfaccia Utente

Quindi, la definizione dei requisiti dei sottosistemi potrebbe essere la seguente:

  • STRAP-01: Dovranno essere utilizzati materiali riciclabili.
  • STRAP-02: Dovrà poter essere fissato magneticamente.
  • DISPLAY-01: Il display dovrà essere di 2 pollici.
  • DISPLAY-02: La risoluzione dovrà essere di 368 x 448 pixel.
  • POWER-01: Dovrà essere alimentato da una batteria ricaricabile.
  • POWER-02: La durata della batteria deve essere di almeno 48 ore.
  • COMMS-01: Deve essere capace di comunicazione Bluetooth.
  • COMMS-02: Deve essere capace di comunicazione Wi-Fi.
  • UI-01: Deve avere un pulsante laterale sotto forma di manopola per la navigazione del menu.

Questa organizzazione strutturata dei requisiti permette una definizione, tracciamento e gestione più semplici. 

Smartwatch requirements example

Tracciabilità dei Requisiti

In un piano di gestione dei requisiti, la tracciabilità dei requisiti è essenziale; ciò significa tracciare o osservare l'evoluzione dell'implementazione dei requisiti durante tutto il progetto.

Continuando con l'esempio del progetto di smartwatch, una volta che gli schemi del prodotto sono progettati, ingegneri e manager devono tenere quanti più incontri necessari per verificare che la soluzione progettata soddisfi i requisiti definiti prima di passare al passo successivo, in questo caso, il layout del PCB.

Il portale Requisiti e Sistemi facilita questo compito, poiché offre visibilità dei requisiti definiti direttamente in Altium 365. Ciò significa che manager e ingegneri possono ora tracciare i requisiti nel progetto in tempo reale, tramite un browser web, consentendo loro di aggiungere commenti, assegnare compiti ai membri del team e fornire visibilità in tempo reale delle modifiche ai requisiti agli ingegneri progettisti, trasformando completamente il tradizionale paradigma di progettazione e revisione.

Come vengono gestiti i requisiti?

Esistono vari modi per gestire i requisiti. Le aziende con minori risorse finanziarie e i professionisti indipendenti spesso utilizzano strumenti semplici ed economici come fogli di calcolo controllati da versione, mentre le aziende più grandi tipicamente utilizzano software specializzati per la gestione dei requisiti come DOORS, Valispace, Confluence, ReqView, tra gli altri. Altium ha acquisito Valispace e ora integra lo strumento di gestione dei requisiti nell'ecosistema di Altium 365 attraverso il portale Requisiti e Sistemi.

Procedura del piano di gestione dei requisiti

Basandoci sulle sezioni precedenti, potremmo definire il piano di gestione dei requisiti come l'insieme di azioni attraverso le quali l'azienda definisce, gestisce, verifica e valida le esigenze o i requisiti degli stakeholder durante l'esecuzione del progetto, dalla concezione alla commercializzazione. L'immagine seguente illustra un flusso di lavoro di un piano di gestione dei requisiti standard.

A flowchart of a standard requirements management plan
Un flusso di lavoro di un piano di gestione dei requisiti standard

Conclusioni

L'Importanza di Avere un Piano di Gestione dei Requisiti

Ogni progetto di ingegneria deve avere un piano di gestione dei requisiti che assicura che il team di sviluppo comprenda pienamente le esigenze del cliente e tutti i requisiti di sistema e sottosistema.

Sapere Come Scrivere, Definire e Identificare Correttamente un Requisito

Devono essere seguite delle regole base per scrivere e definire i requisiti. Allo stesso modo, è essenziale comprendere i tipi di requisiti che esistono e come classificarli correttamente, così come comprendere cosa sia la tracciabilità dei requisiti.

Tracciabilità dei Requisiti

I requisiti sono stati scritti per essere soddisfatti, quindi, osservarli e tracciarli durante l'esecuzione del progetto è molto importante, poiché più presto viene rilevata una deviazione o una non conformità, minore sarà l'impatto sul progetto.

Utilizzare un Software Appropriato

Utilizza il Portale dei Requisiti e dei Sistemi per massimizzare il suo potenziale in combinazione con Altium 365. Questo consente un'interazione molto più stretta tra l'ingegneria dei requisiti e l'ingegneria dello sviluppo, riducendo la probabilità di deviazioni del progetto e accorciando i tempi di sviluppo.

Inizia oggi a utilizzare la gestione dei requisiti moderna e alimentata dall'IA!

Sull'Autore

Sull'Autore

Javier Alcina Espigado is an electronics engineer with more than 20 years of experience in electronic design. He has worked in different industrial sectors such as consumer electronics, automotive, security and aerospace.

He has developed his professional career as a hardware and PCB design engineer, even he has also participated in other disciplines such as firmware development for microcontrollers and management of multidisciplinary teams, such as mechanical (enclosure) design, software development, test and verification, electromagnetic compatibility which has allowed him to acquire a global knowledge in product development, from the idea or conception to its production covering all life cycling of the design.

He has participated in projects with important companies developing electronics in applications such as AR/VR headsets and he was the principal electrical engineer in a project Co-founded by European Union (Horizon 2020) in 2016 (Wardiam Perimeter), which was awarded at the Las Vegas ISC West (International Security Conference) for the best perimeter security product in 2017.

Currently, he is working as PCB Designer in a multinational company, developing electronics for aerospace industry and also provides design services as independent consultant.

Risorse correlate

Documentazione Tecnica Correlata

Tornare alla Pagina Iniziale
Thank you, you are now subscribed to updates.