Lezioni apprese sulla gestione dei requisiti: il programma del sottomarino S-80

Il programma del sottomarino S-80 ci mostra perché requisiti, vincoli, modifiche di progetto e controlli di verifica devono rimanere collegati nei progetti di sviluppo di prodotti hardware.

Nello sviluppo di prodotti hardware, una modifica di progetto può risolvere il problema immediato sollevando al contempo nuove domande in altre parti del sistema. Per questo la gestione dei requisiti non consiste solo nel acquisire ciò che il prodotto deve fare, ma anche nel mantenere visibili i vincoli correlati, le decisioni di progetto e i controlli di verifica man mano che il progetto evolve.

Il programma spagnolo del sottomarino S-80 mostra chiaramente questo schema. Durante lo sviluppo, il programma ha affrontato una importante sfida legata a peso e galleggiabilità. La riprogettazione ha contribuito ad affrontare quel problema, ma le dimensioni aggiornate dell’imbarcazione hanno introdotto un nuovo problema pratico: il sottomarino era ora troppo lungo per il porto che avrebbe dovuto utilizzare.

Ecco una lezione trasferibile per tutti i team che sviluppano prodotti hardware, che si tratti di costruire un sottomarino o un dispositivo elettronico: quando requisiti, vincoli, modifiche di progetto e controlli di verifica sono scollegati, i team fanno fatica a vedere cos’altro potrebbe influenzare una modifica.

Punti chiave

• Conflitti nei requisiti emergono spesso quando vincoli critici si trovano al di fuori del flusso di lavoro utilizzato per esaminare le modifiche di progetto.
• I team possono ridurre questo rischio collegando i requisiti ai vincoli, alle decisioni di progetto e ai controlli di verifica che influenzano.
• Un flusso di lavoro dei requisiti connesso rende più facile vedere cosa è cambiato, cosa ne è influenzato e cosa deve essere rivisto prima che le rilavorazioni diventino costose.

Cosa è successo nel programma S-80

La Spagna ha avviato il programma S-80 per sviluppare una nuova classe di sottomarini. Durante lo sviluppo, il programma ha affrontato un serio problema di peso e galleggiabilità. L’imbarcazione era diventata più pesante del previsto, sollevando dubbi sul fatto che avrebbe avuto un margine di galleggiabilità sufficiente per riemergere in modo affidabile dopo l’immersione.

Il progetto è stato rivisto per affrontare il problema. Una delle modifiche principali è stata l’allungamento dello scafo, che ha contribuito a ripristinare il margine di galleggiabilità necessario. Questa revisione ha anche modificato le dimensioni fisiche dell’imbarcazione. Il sottomarino aggiornato ha quindi dovuto essere verificato rispetto all’infrastruttura in cui avrebbe operato, e tale verifica ha rivelato un problema pratico: non sarebbe più entrato nel porto.

Il problema infrastrutturale ha aggiunto un ulteriore livello di lavoro a un programma che aveva già richiesto una importante riprogettazione. Il programma è infine diventato più complesso, ha richiesto più tempo ed è risultato più costoso di quanto inizialmente previsto.

Questo esempio ci ricorda che ogni riprogettazione lascia sempre un’ulteriore domanda a cui rispondere: cos’altro deve ora essere verificato?

Cosa possono imparare i team hardware dal caso S-80

La maggior parte dei team hardware lavora su una scala più ridotta rispetto a un programma di sottomarini, ma lo stesso schema può comparire nello sviluppo quotidiano dei prodotti: una modifica di progetto può influenzare dimensioni, requisiti di conformità o vincoli di interfaccia al di là del problema che il team sta cercando di risolvere in quel momento.

Conoscere questi vincoli non basta. È qui che la gestione dei requisiti diventa importante: aiuta i team a mantenerli visibili, collegati e riesaminabili man mano che il progetto evolve. Per i team hardware, questo si traduce in tre abitudini pratiche:

Mantenere visibili i vincoli critici

I vincoli critici non dovrebbero esistere solo in note di riunione, fogli di calcolo o nella memoria di qualcuno. Dovrebbero essere acquisiti in modo chiaro e, ove possibile, espressi in termini misurabili affinché i team possano verificarli man mano che il progetto cambia.

Collegare i requisiti alle decisioni di progetto

Un requisito è più utile quando è collegato all’area di sistema, al blocco, all’oggetto di progetto o all’attività di engineering che influenza. Questo collegamento aiuta gli ingegneri a capire perché una decisione di progetto è importante, quali requisiti supporta e cos’altro può essere influenzato quando il progetto cambia.

Usare la tracciabilità per esaminare l’impatto delle modifiche

La tracciabilità aiuta i team a rispondere a una domanda pratica: cos’altro influenza questa modifica? Quando i requisiti restano collegati a decisioni di progetto, vincoli, controlli di verifica ed evidenze, i team possono vedere cosa è cambiato, cosa è ancora coperto e cosa deve essere rivisto prima che le rilavorazioni diventino costose.

Come aiuta un flusso di lavoro dei requisiti connesso

I team hardware hanno bisogno di più di un semplice posto in cui archiviare il testo dei requisiti. Documenti e fogli di calcolo possono acquisire i requisiti, ma diventano più difficili da gestire con l’aumentare della complessità del progetto e quando ogni requisito deve rimanere collegato lungo tutta la catena di engineering.

Altium Requirements Portal è progettato per supportare questo flusso di lavoro gestendo requisiti, tracciabilità, responsabilità e verifica in un unico ambiente condiviso. Invece di trattare i requisiti come testo isolato, i team possono vedere cosa è cambiato, cosa influenza, chi è responsabile del passaggio successivo e come il requisito verrà verificato.

Qual è il “sottomarino” nel tuo progetto?

Ogni progetto di sviluppo hardware ha vincoli facili da trascurare quando il progetto procede rapidamente. Possono essere meccanici, elettrici, normativi, operativi o legati al processo. Il rischio non è che i team manchino di conoscenza, ma che le informazioni importanti non vengano sempre acquisite, collegate e riesaminate quando il progetto cambia.

Questo è ciò che rende utile il caso S-80 al di là della sua scala. Lo stesso schema può comparire nello sviluppo quotidiano dei prodotti quando intenti ingegneristici, decisioni di progetto ed evidenze non vengono mantenuti collegati nel tempo.

Rendi più facile tracciare l’impatto delle modifiche con uno strumento di gestione dei requisiti accessibile a tutto il tuo team.

Inizia con Requirements Portal →

Domande comuni

Quali sono le cause dei problemi di gestione dei requisiti nei progetti hardware?

I problemi di gestione dei requisiti emergono spesso quando i requisiti non sono collegati al lavoro di progettazione, ai vincoli e ai controlli di verifica che influenzano. Un requisito può esistere, ma se il team non riesce a vedere a cosa è collegato, gli impatti importanti possono sfuggire quando il progetto cambia.

Perché i fogli di calcolo diventano difficili da usare per la gestione dei requisiti?

I fogli di calcolo possono acquisire il testo dei requisiti, ma diventano più difficili da gestire con l’aumentare della complessità del progetto. I team hanno bisogno di un modo per mantenere i requisiti collegati al lavoro di progettazione, alla cronologia delle modifiche, allo stato della verifica e alle evidenze lungo tutta la catena di engineering.

In che modo la tracciabilità aiuta a ridurre le rilavorazioni nelle fasi avanzate?

La tracciabilità aiuta i team a rispondere a una domanda pratica: cos’altro influenza questa modifica? Collegando i requisiti alle decisioni di progetto, ai vincoli, ai controlli di verifica e alle evidenze, i team possono vedere cosa deve essere riesaminato prima che le rilavorazioni diventino costose.