Lezioni apprese nella gestione dei requisiti: errori di conversione delle unità

Nello sviluppo di prodotti hardware, gli ingegneri condividono numeri ogni giorno. Un valore passa da un ingegnere a un disegno, da una specifica a un componente, o dal tuo team a un fornitore. Nella maggior parte dei casi, tutto funziona perché tutti sanno cosa significa quel numero e quale unità utilizza.

Il rischio emerge quando quel valore attraversa un passaggio di consegne e le due parti non lo interpretano allo stesso modo. Una parte può lavorare in libbre mentre l'altra si aspetta chilogrammi. Un documento può usare un vecchio progetto in unità imperiali, mentre il nuovo progetto è metrico. Il numero può sembrare corretto da entrambe le parti, ma non sta più guidando la stessa decisione.

Le tre storie di ingegneria qui sotto mostrano quanto facilmente possa accadere:

Tre casi, un unico schema

Tre guasti ingegneristici, nell'arco di tre decenni, mostrano lo stesso problema di passaggio di consegne in forme diverse. In ciascun caso, un numero è passato da una parte del flusso di lavoro a un'altra. Il numero sembrava corretto agli utenti, ma erano in gioco due sistemi di misura. Il passaggio di consegne non chiariva quale unità usasse quel numero.

Volo Air Canada 143: il Gimli Glider

Il primo esempio è il Gimli Glider del 1983. Mostra cosa accadde quando una compagnia aerea, Air Canada, passò dalle unità imperiali a quelle metriche. Il volo 143, un Boeing 767 in servizio da Montreal a Edmonton, era il suo primo aeromobile metrico.

Quel giorno, il sistema di indicazione della quantità di carburante (FQIS) non funzionava, quindi l'equipaggio misurò il carburante manualmente. Usarono il valore di densità del rifornitore pari a 1,77, che era in libbre per litro, lo standard per il resto della flotta. Ma il 767 metrico richiedeva quel valore in chilogrammi per litro, dove il numero corretto era circa 0,8.

L'aereo decollò con solo metà del carburante che l'equipaggio si aspettava, causando lo spegnimento di entrambi i motori durante il volo. Fortunatamente, i piloti riuscirono ad atterrare in sicurezza.

Mars Climate Orbiter

Sedici anni dopo, il Mars Climate Orbiter andò perduto a causa di un errore di navigazione provocato dal mancato trasferimento delle unità inglesi in unità metriche. Il software di Lockheed Martin inviava i dati dei propulsori in pound-force second. Il software di navigazione della NASA si aspettava newton-second, che differiscono dai pound-force second di un fattore pari a 4,45.

La sonda avrebbe dovuto entrare in orbita tra 150 e 200 chilometri sopra Marte. Invece, scese fino a circa 57 chilometri e si disintegrò nell'atmosfera marziana.

Le montagne russe Space Mountain di Tokyo Disneyland

Nel 2003, le montagne russe Space Mountain di Tokyo Disneyland mostrarono un problema simile attraverso i disegni di progetto. L'attrazione fu ridisegnata passando da unità imperiali a metriche nel 1995, modificando il diametro di un asse da 44,14 a 45 millimetri. Tuttavia, i disegni più vecchi non furono ritirati dall'uso e, di conseguenza, esistevano due serie di disegni di progetto.

Nel 2002, quando fu riordinato un nuovo lotto di assi, l'ordine si basò sulla versione del progetto precedente al 1995. Di conseguenza, i componenti arrivarono sottodimensionati. Quella differenza di 0,86 millimetri rese il gioco del cuscinetto molto più ampio del previsto. Dopo mesi di utilizzo, l'asse si ruppe.

In tutti e tre i casi, il numero in sé non sembrava sospetto. Il problema è iniziato quando quel numero è diventato la base per la fase ingegneristica successiva e la sua unità o la sua origine non erano abbastanza chiare.

L'illustrazione ricorda che un valore può sembrare corretto a tutti ed essere comunque sbagliato: entrambe le parti del tuo passaggio di consegne concordano sull'unità?

Cosa possono imparare da queste storie i team hardware

La maggior parte dei team hardware non pilota aerei né lancia veicoli spaziali. Ma passaggi simili avvengono ogni giorno. Un valore passa da un requisito a un disegno, da una specifica a un componente, o dal tuo team a un fornitore. A ogni passaggio, l'unità deve restare associata al numero. Tre pratiche possono aiutare:

Specifica le unità per ogni valore di requisito

Un numero da solo non basta. “45” non dice alla persona successiva cosa costruire o testare. “45 mm” dà significato al numero. Mantieni sempre l'unità accanto al valore. Non è un dettaglio di formattazione; è parte del requisito.

Assegna una responsabilità nei passaggi di consegne ingegneristici

Le confusioni sulle unità si verificano spesso quando le informazioni passano da un team a un altro. Una parte può lavorare su un riferimento, mentre l'altra se ne aspetta un altro. Questo passaggio di consegne richiede un responsabile chiaro. Qualcuno dovrebbe verificare il sistema di unità, il formato dei dati e il documento sorgente prima che il valore venga usato a valle.

Mantieni tracciabili requisiti ed evidenze

Quando un valore cambia, il team deve poter individuare ciò che dipende da esso. Questo significa che requisito, disegno, componente, test ed evidenze non dovrebbero esistere come elementi scollegati. La tracciabilità aiuta il team a vedere da dove proviene un valore, cosa lo utilizza e cosa deve essere riesaminato quando cambia.

Come aiuta un flusso di lavoro dei requisiti connesso

Un migliore flusso di lavoro dei requisiti mantiene vicini il numero, la sua unità, il suo responsabile e il documento sorgente. Non tratta il valore come un semplice numero isolato in un foglio di calcolo, in un disegno o in una specifica.

Questo conta soprattutto nei passaggi di consegne. Quando un valore passa da un requisito al lavoro di progettazione o alla verifica, la persona successiva può vedere cosa significa il valore, quale unità utilizza e da dove proviene. Se il valore cambia, il team può anche individuare cosa deve essere riesaminato.

Altium Requirements Portal supporta questo tipo di flusso di lavoro mantenendo requisiti, responsabilità, tracciabilità e attività di verifica in un unico ambiente condiviso. Non sostituisce il giudizio ingegneristico. Aiuta a mantenere visibili l'unità, il responsabile e il contesto ingegneristico correlato prima che un valore venga utilizzato a valle.

Punti chiave

• Le confusioni sulle unità iniziano spesso nei passaggi di consegne, quando un valore passa a un altro team, documento o sistema e la sua unità non viene resa esplicita.
• Prima che un numero guidi la fase ingegneristica successiva, il team dovrebbe sapere da dove proviene e chi ne è responsabile.
• La tracciabilità aiuta i team a vedere cosa dipende da un valore prima che cambi o venga usato a valle.

Ogni numero nel tuo progetto è completo?

Ognuno di questi incidenti era evitabile. Non con una migliore ingegneria, ma con domande chiare poste al momento del passaggio di consegne:

• Ogni valore nei tuoi requisiti riporta un'unità?
• Ogni interfaccia tra team ha una persona responsabile?
• È chiaro quale versione di una specifica è quella corrente?
• Se qualcosa cambiasse domani, il tuo processo mostrerebbe cosa deve essere riesaminato?

Ora poniti le stesse domande sul tuo progetto. Se la risposta a una di queste è "probabilmente", sai già da dove iniziare.

Mantieni chiare e facili da verificare le informazioni ingegneristiche importanti a ogni passaggio di consegne con uno strumento di gestione dei requisiti che tutto il tuo team possa utilizzare.

Inizia con Requirements Portal →

Domande frequenti

Perché gli errori di conversione delle unità si verificano nei progetti di ingegneria?

Queste confusioni raramente derivano da calcoli sbagliati. Si verificano nei passaggi di consegne, quando un valore passa tra team, strumenti o documenti. Una parte può presumere che il valore sia in un'unità, mentre l'altra lo legge in un'altra. Il valore può anche essere corretto, ma è corretto rispetto all'ipotesi sbagliata.

Cosa dovrebbe includere un valore di requisito completo?

Un valore di requisito completo dovrebbe includere il numero, l'unità e il contesto necessario per utilizzarlo correttamente. Per esempio, “45” non basta; “45 millimetri” sì. Il team potrebbe anche dover conoscere la condizione in cui il valore si applica, il documento sorgente e chi è responsabile di quel requisito.

In che modo la tracciabilità aiuta a ridurre gli errori nei passaggi di consegne?

La tracciabilità collega un valore a tutto ciò che dipende da esso: dal requisito di livello superiore fino al componente, al test e al responsabile associati. Quando un valore cambia, questi collegamenti rendono più facile individuare cos'altro potrebbe richiedere una revisione. Questo riduce la probabilità che una vecchia specifica, un'unità poco chiara o un test non aggiornato restino in uso per errore.