Lições Aprendidas sobre Gerenciamento de Requisitos: Voo 501 do Ariane 5

O desastre do voo 501 do Ariane 5 mostra por que devemos sempre pensar duas vezes antes de reutilizar, sem adaptações, requisitos, projetos de engenharia e testes de projetos anteriores. 

No desenvolvimento de produtos de hardware, é comum reutilizar requisitos, rotinas de software, casos de teste ou decisões de projeto de projetos anteriores. Isso pode economizar tempo, mas somente se as condições que tornaram essas escolhas válidas ainda se aplicarem.

Ariane 5 Flight 501 foi o primeiro voo do foguete europeu Ariane 5, em 4 de junho de 1996. O foguete reutilizou parte do software de referência inercial do Ariane 4, um foguete europeu anterior no qual o software havia funcionado com sucesso. Mas o Ariane 5 seguiu um perfil de voo diferente, um valor excedeu a faixa que o software esperava, e o foguete foi destruído menos de um minuto após o lançamento.

A lição é simples, mas fácil de esquecer: antes de reutilizar trabalho de projetos anteriores, verifique se as mesmas premissas e condições operacionais ainda se aplicam ao novo projeto.

Principais Conclusões

• Reutilizar requisitos, software, testes ou decisões de projeto já comprovados economiza tempo, mas o contexto original precisa ser revisado.
• Revise os casos de teste reutilizados antes de usá-los para comprovar o mesmo requisito em outro produto.
• Reduza o risco mantendo requisitos, procedimentos de teste, evidências e status conectados.

O Que Aconteceu no Lançamento do Ariane 5

Em 4 de junho de 1996, o Ariane 5 fez seu primeiro voo a partir de Kourou, na Guiana Francesa, transportando quatro satélites de pesquisa Cluster para a Agência Espacial Europeia. A missão durou menos de um minuto. Cerca de trinta e sete segundos após o início do voo, o foguete se desviou de sua trajetória planejada e foi destruído.

O problema veio do sistema de referência inercial, que enviava dados de atitude e velocidade ao computador de bordo do foguete. O Ariane 5 reutilizou software do Ariane 4, incluindo uma rotina de alinhamento que permaneceu ativa por cerca de 40 segundos após o lançamento. Essa rotina havia funcionado no Ariane 4, mas o Ariane 5 seguia um perfil de voo diferente.

Por causa desse perfil diferente, várias coisas aconteceram em rápida sequência:

• Um valor de velocidade horizontal tornou-se maior do que o software esperava.
• O software tentou converter o valor de um número de ponto flutuante de 64 bits para um inteiro com sinal de 16 bits, mas ele já não cabia nesse formato.
• A conversão gerou estouro, e o sistema de referência inercial tratou isso como um erro e foi desligado.
• O sistema de backup executava o mesmo software e foi desligado pelo mesmo motivo.
• Sem dados de voo válidos, o computador de bordo usou dados de diagnóstico em seu lugar, emitiu comandos de voo incorretos e o foguete foi destruído.

É isso que torna esse caso útil para a gestão de requisitos. O software reutilizado havia funcionado antes, mas carregava uma premissa do foguete anterior: que esse valor permaneceria dentro de uma faixa segura. O Ariane 5 mudou o contexto em torno dessa premissa, por isso ela precisava estar visível e ser verificada novamente no novo sistema.

A ilustração serve como um lembrete de que o trabalho de engenharia reutilizado ainda precisa de uma verificação simples: as premissas por trás dele ainda são verdadeiras no novo sistema?

O Que as Equipes de Hardware Podem Aprender com o Caso Ariane 5

A maioria das equipes de hardware não está construindo foguetes, mas reutiliza trabalho comprovado o tempo todo. Um bloco de PCB de um produto anterior pode ser copiado para um novo projeto. Uma rotina de firmware pode ser transferida para uma nova revisão de hardware. Um procedimento de teste pode permanecer em uso depois que a arquitetura de alimentação muda. 

Isso é trabalho de engenharia normal. A reutilização ajuda as equipes a avançar mais rapidamente. O passo importante é garantir que o requisito, a premissa e a verificação ainda correspondam ao novo sistema.

Revise os Requisitos Reutilizados

Um requisito que funcionou em um produto não deve ser tratado como automaticamente válido no próximo. As mesmas palavras ainda podem parecer corretas, mas as condições operacionais ao redor delas podem ter mudado. Por exemplo, um limite de corrente, faixa térmica ou restrição de interface pode ser seguro em um projeto e precisar de revisão em outro. Antes de reutilizar um requisito, a equipe deve verificar se o novo produto ainda opera dentro das mesmas premissas.

Rastreie as Premissas até os Procedimentos de Verificação

Algumas das premissas de engenharia mais importantes nunca são registradas como requisitos formais. Elas ficam em notas de projeto, planos de teste antigos ou na memória de alguém. Isso pode se tornar arriscado quando o trabalho é reutilizado. Se uma premissa afeta uma decisão de projeto, a equipe precisa de uma forma de conectá-la a uma verificação. Caso contrário, é fácil reutilizar a decisão sem perceber o motivo que a tornou segura em primeiro lugar.

Revise os Testes Quando os Requisitos Mudarem

Um caso de teste aprovado no projeto anterior nem sempre comprova a mesma coisa no projeto seguinte. Se o requisito mudar, ou se o sistema ao redor do requisito mudar, o procedimento de teste relacionado também pode precisar mudar. Isso é especialmente importante quando as equipes reutilizam casos de teste, critérios de aceitação ou evidências de conformidade.

Como um Fluxo de Trabalho de Requisitos Conectado Ajuda

Um fluxo de trabalho de requisitos melhor não trata um requisito como uma linha de texto isolada. Ele mantém o requisito conectado ao motivo por trás dele, ao trabalho de projeto que ele afeta e ao trabalho de verificação que mostra se ele ainda é válido. 

É isso que mais importa quando algo muda. Um requisito reutilizado ainda pode parecer correto, mas a premissa por trás dele pode não corresponder mais ao novo produto. Um teste ainda pode existir, mas talvez já não verifique a condição correta.

Em um fluxo de trabalho conectado, as equipes podem manter as partes importantes próximas umas das outras: o requisito, o contexto por trás dele, o método de verificação, o procedimento, o resultado, a evidência e o status atual. Em vez de procurar em documentos antigos ou relatórios de teste, os engenheiros podem ver o que está conectado e o que pode precisar de outra revisão.

Altium Requirements Portal oferece suporte a esse tipo de fluxo de trabalho ao manter requisitos, rastreabilidade, responsabilidade e trabalho de verificação em um único ambiente compartilhado. Isso ajuda as equipes a reutilizar trabalho comprovado com mais confiança, porque o requisito e as verificações ao redor dele permanecem conectados.

As Premissas Antigas do Seu Projeto Ainda São Verdadeiras?

Toda equipe de hardware reutiliza trabalho comprovado. Isso não é um atalho a ser evitado, mas uma forma prática de desenvolver mais rápido e levar boas decisões de engenharia adiante. 

A pergunta útil é o que mudou ao redor desse trabalho reutilizado:

• A faixa operacional mudou? 
• O teste precisa ser revisado? 
• As premissas por trás da decisão original ainda se aplicam?

Quando as equipes conseguem responder a essas perguntas, a reutilização se torna mais fácil de confiar. O requisito não fica isolado. O motivo por trás dele, a verificação e a evidência permanecem próximos o suficiente para que a equipe os revise quando o contexto do produto mudar. 

Essa é a lição que o Ariane 5 ainda oferece às equipes de hardware hoje: a reutilização funciona melhor quando o contexto por trás dela permanece conectado.

Torne as decisões de reutilização mais fáceis de verificar e confiar com uma ferramenta de gestão de requisitos que toda a sua equipe possa acessar.

Comece a usar o Requirements Portal →

Perguntas Frequentes

Reutilizar Trabalho de Engenharia Pode se Tornar Arriscado?

Reutilizar trabalho de engenharia pode se tornar arriscado quando o contexto do produto muda, mas as premissas originais, os limites operacionais ou as verificações de validação não são revisados novamente. O trabalho ainda pode parecer correto, mas as condições que o tornaram válido no projeto anterior podem não se aplicar mais.

O Que os Engenheiros Devem Verificar Antes de Reutilizar um Requisito, Teste ou Decisão de Projeto?

As equipes devem verificar se o novo produto usa as mesmas condições operacionais, interfaces, limites e critérios de aceitação do projeto original. Elas também devem confirmar que o método de verificação relacionado ainda comprova a coisa certa no novo sistema.

Como a Rastreabilidade Ajuda Quando Requisitos São Reutilizados?

A rastreabilidade ajuda as equipes a ver como um requisito se conecta a decisões de projeto, premissas, procedimentos de teste, evidências e status. Quando o trabalho reutilizado é levado para um novo projeto, esses vínculos facilitam ver o que ainda é válido e o que pode precisar de revisão.