Lições Aprendidas em Requirements Management: Falhas na Conversão de Unidades

No desenvolvimento de produtos de hardware, os engenheiros compartilham números todos os dias. Um valor passa de um engenheiro para um desenho, de uma especificação para um componente, ou da sua equipe para um fornecedor. Na maioria das vezes, isso funciona porque todos sabem o que o número significa e qual unidade ele usa.

O risco aparece quando esse valor cruza uma transferência, e os dois lados não o interpretam da mesma forma. Um lado pode trabalhar em libras, enquanto o outro espera quilogramas. Um documento pode usar um projeto imperial mais antigo, enquanto o novo projeto é métrico. O número pode parecer correto para ambos os lados, mas já não está orientando a mesma decisão.

As três histórias de engenharia abaixo mostram como isso pode acontecer com facilidade:

Três Casos, Um Padrão

Três falhas de engenharia, ao longo de três décadas, mostram o mesmo problema de transferência em formas diferentes. Em cada caso, um número passou de uma parte do fluxo de trabalho para outra. O número parecia correto para os usuários, mas dois sistemas de medição estavam em jogo. A transferência não deixou claro qual unidade o número usava.

Voo 143 da Air Canada: Gimli Glider

O primeiro exemplo é o Gimli Glider de 1983. Ele mostra o que aconteceu quando uma companhia aérea, a Air Canada, mudou de unidades imperiais para métricas. O voo 143, um Boeing 767 voando de Montreal para Edmonton, era sua primeira aeronave métrica.

Naquele dia, o sistema de indicação da quantidade de combustível (FQIS) não estava funcionando, então a tripulação mediu o combustível manualmente. Eles usaram o valor de densidade do abastecedor de 1,77, que era em libras por litro, o padrão para o restante da frota. Mas o 767 métrico precisava desse valor em quilogramas por litro, em que o número correto era cerca de 0,8.

A aeronave decolou com apenas metade do combustível que a tripulação esperava, o que fez com que ambos os motores parassem durante o voo. Felizmente, os pilotos conseguiram pousar em segurança.

Mars Climate Orbiter

Dezesseis anos depois, o Mars Climate Orbiter foi perdido devido a um erro de navegação causado por uma falha na conversão de unidades inglesas para métricas. O software da Lockheed Martin enviou dados dos propulsores em libra-força segundo. O software de navegação da NASA esperava newton-segundos, que diferem de libra-força segundo por um fator de 4,45.

A espaçonave deveria orbitar entre 150 e 200 quilômetros acima de Marte. Em vez disso, caiu para cerca de 57 quilômetros e se desintegrou na atmosfera de Marte.

Montanha-russa Space Mountain da Tokyo Disneyland

Em 2003, a montanha-russa Space Mountain na Tokyo Disneyland apresentou um problema semelhante por meio de desenhos de projeto. O brinquedo foi redesenhado de imperial para métrico em 1995, alterando o diâmetro de um eixo de 44,14 para 45 milímetros. No entanto, os desenhos antigos não foram retirados de uso e, como resultado, havia dois conjuntos de desenhos de projeto.

Em 2002, quando um novo conjunto de eixos foi encomendado, o pedido foi baseado na versão do projeto anterior a 1995. Como resultado, as peças vieram menores do que o especificado. Essa diferença de 0,86 milímetro tornou a folga do rolamento muito maior do que o previsto. Após meses de uso, o eixo quebrou.

Em todos os três casos, o número em si não parecia suspeito. O problema começou quando esse número se tornou a base para a próxima etapa de engenharia, e sua unidade ou origem não estava clara o suficiente.

A ilustração serve como lembrete de que um valor pode parecer correto para todos e ainda assim estar errado: os dois lados da sua transferência concordam quanto à unidade?

O que as Equipes de Hardware Podem Aprender com Essas Histórias

A maioria das equipes de hardware não está voando aeronaves nem lançando espaçonaves. Mas transferências semelhantes acontecem todos os dias. Um valor passa de um requisito para um desenho, de uma especificação para um componente, ou da sua equipe para um fornecedor. Em cada transferência, a unidade precisa permanecer junto com o número. Três práticas podem ajudar:

Especifique Unidades em Cada Valor de Requisito

Um número sozinho não basta. “45” não informa à próxima pessoa o que construir ou testar. “45 mm” dá significado ao número. Mantenha a unidade ao lado do valor em todas as vezes. Não é um detalhe de formatação; faz parte do requisito.

Defina Responsabilidade nas Transferências de Engenharia

Confusões com unidades frequentemente acontecem quando a informação passa de uma equipe para outra. Um lado pode estar trabalhando com uma referência, enquanto o outro espera outra. Essa transferência precisa de um responsável claro. Alguém deve verificar o sistema de unidades, o formato dos dados e o documento de origem antes que o valor seja usado nas etapas seguintes.

Mantenha Requisitos e Evidências Rastreáveis

Quando um valor muda, a equipe precisa encontrar o que depende dele. Isso significa que o requisito, o desenho, o componente, o teste e a evidência não devem existir como partes desconectadas. Rastreabilidade ajuda a equipe a ver de onde veio um valor, o que o utiliza e o que precisa ser revisado quando ele muda.

Como um Fluxo de Trabalho de Requisitos Conectado Ajuda

Um fluxo de trabalho de requisitos melhor mantém o número, sua unidade, seu responsável e o documento de origem próximos entre si. Ele não trata o valor como apenas um número solto em uma planilha, desenho ou especificação.

Isso é mais importante nas transferências. Quando um valor passa de um requisito para o trabalho de projeto ou verificação, a próxima pessoa pode ver o que o valor significa, qual unidade ele usa e de onde veio. Se o valor mudar, a equipe também poderá identificar o que precisa ser revisado.

Altium Requirements Portal oferece suporte a esse tipo de fluxo de trabalho ao manter requisitos, responsabilidade, rastreabilidade e trabalho de verificação em um ambiente compartilhado. Ele não substitui o julgamento de engenharia. Ele ajuda a manter a unidade, o responsável e o contexto de engenharia relacionado visíveis antes que um valor seja usado nas etapas seguintes.

Principais Conclusões

• Confusões com unidades geralmente começam nas transferências, quando um valor passa para outra equipe, documento ou sistema e sua unidade não fica clara.
• Antes que um número oriente a próxima etapa de engenharia, a equipe deve saber de onde ele veio e quem é o responsável por ele.
• A rastreabilidade ajuda as equipes a ver do que um valor depende antes que ele mude ou siga para as etapas seguintes.

Todos os Números no Seu Projeto Estão Completos?

Cada um desses incidentes poderia ter sido evitado. Não com melhor engenharia, mas com perguntas claras feitas na transferência:

• Todo valor em seus requisitos inclui uma unidade?
• Toda interface entre equipes tem alguém responsável por ela?
• Está claro qual versão de uma especificação é a atual?
• Se algo mudasse amanhã, seu processo mostraria o que precisa ser revisado?

Agora faça a si mesmo as mesmas perguntas sobre o seu projeto. Se a resposta para qualquer uma delas for "provavelmente", você já sabe por onde começar.

Mantenha informações importantes de engenharia claras e fáceis de verificar em cada transferência com uma ferramenta de gerenciamento de requisitos que toda a sua equipe possa usar.

Comece a usar o Requirements Portal →

Perguntas Frequentes

Por que erros de conversão de unidades acontecem em projetos de engenharia?

Essas confusões raramente vêm de matemática ruim. Elas acontecem nas transferências, quando um valor passa entre equipes, ferramentas ou documentos. Um lado pode presumir que o valor está em uma unidade, enquanto o outro o lê em outra. O valor ainda pode estar correto, mas está correto para a suposição errada.

O que um Valor de Requisito Completo Deve Incluir?

Um valor de requisito completo deve incluir o número, a unidade e o contexto necessário para usá-lo corretamente. Por exemplo, “45” não basta; “45 milímetros” basta. A equipe também pode precisar saber a condição em que o valor se aplica, o documento de origem e quem é o responsável por esse requisito.

Como a Rastreabilidade Ajuda a Reduzir Erros de Transferência?

A rastreabilidade vincula um valor a tudo o que depende dele: do requisito de mais alto nível até o componente, teste e responsável por trás dele. Quando um valor muda, esses vínculos facilitam encontrar o que mais pode precisar de revisão. Isso reduz a chance de que uma especificação antiga, uma unidade pouco clara ou um teste desatualizado continue em uso por engano.