Lições Aprendidas em Requirements Management: O Programa do Submarino S-80

O programa de submarinos S-80 nos mostra por que requisitos, restrições, alterações de projeto e verificações de validação precisam permanecer conectados em projetos de desenvolvimento de produtos de hardware.

No desenvolvimento de produtos de hardware, uma alteração de projeto pode resolver o problema imediato e, ao mesmo tempo, levantar novas questões em outra parte do sistema. Por isso, o gerenciamento de requisitos não se resume apenas a capturar o que o produto deve fazer, mas também a manter visíveis as restrições relacionadas, as decisões de projeto e as verificações de validação à medida que o projeto evolui.

O programa de submarinos S-80 da Espanha mostra esse padrão com clareza. Durante o desenvolvimento, o programa enfrentou um grande desafio de peso e flutuabilidade. O reprojeto ajudou a resolver essa questão, mas as dimensões atualizadas da embarcação introduziram um novo problema prático: o submarino agora era longo demais para o porto que deveria utilizar.

Aqui está uma lição aplicável a todas as equipes que desenvolvem produtos de hardware — seja um submarino ou um dispositivo eletrônico: quando requisitos, restrições, alterações de projeto e verificações de validação estão desconectados, as equipes têm dificuldade para enxergar o que mais uma mudança pode afetar.

Principais conclusões

• Conflitos de requisitos frequentemente surgem quando restrições críticas ficam fora do fluxo de trabalho usado para revisar alterações de projeto.
• As equipes podem reduzir esse risco vinculando requisitos às restrições, decisões de projeto e verificações de validação que eles afetam.
• Um fluxo de trabalho de requisitos conectado facilita ver o que mudou, o que isso afeta e o que precisa ser revisado antes que o retrabalho se torne custoso.

O que aconteceu no programa S-80

A Espanha lançou o programa S-80 para desenvolver uma nova classe de submarinos. Durante o desenvolvimento, o programa enfrentou um sério problema de peso e flutuabilidade. A embarcação havia se tornado mais pesada do que o planejado, levantando preocupações sobre se teria margem de flutuabilidade suficiente para emergir de forma confiável após o mergulho.

O projeto foi revisado para resolver o problema. Uma das principais mudanças foi o alongamento do casco, o que ajudou a restabelecer a margem de flutuabilidade necessária. Essa revisão também alterou as dimensões físicas da embarcação. O submarino atualizado então precisou ser avaliado em relação à infraestrutura onde operaria, e essa análise revelou um problema prático: ele não caberia mais no porto.

A questão de infraestrutura acrescentou outra camada de trabalho a um programa que já havia exigido um grande reprojeto. No fim, o programa se tornou mais complexo, levou mais tempo e ficou mais caro do que o esperado originalmente.

O exemplo serve como lembrete de que todo reprojeto ainda deixa uma pergunta a ser respondida: o que mais agora precisa ser verificado?

O que as equipes de hardware podem aprender com o caso do S-80

A maioria das equipes de hardware trabalha em uma escala menor do que um programa de submarinos, mas o mesmo padrão pode aparecer no desenvolvimento cotidiano de produtos: uma alteração de projeto pode afetar dimensões, requisitos de conformidade ou restrições de interface além do problema que a equipe está tentando resolver no momento.

Conhecer essas restrições não é suficiente. É aqui que o gerenciamento de requisitos faz diferença: ele ajuda as equipes a mantê-las visíveis, conectadas e passíveis de revisão à medida que o projeto evolui. Para equipes de hardware, isso se resume a três práticas concretas:

Mantenha restrições críticas visíveis

Restrições críticas não devem existir apenas em anotações de reuniões, planilhas ou na memória de alguém. Elas devem ser registradas com clareza e, sempre que possível, escritas em termos mensuráveis para que as equipes possam verificá-las conforme o projeto muda.

Conecte requisitos às decisões de projeto

Um requisito é mais útil quando está vinculado à área do sistema, bloco, objeto de projeto ou atividade de engenharia que ele afeta. Essa conexão ajuda os engenheiros a entender por que uma decisão de projeto é importante, quais requisitos ela atende e o que mais pode ser impactado quando o projeto muda.

Use rastreabilidade para revisar o impacto das mudanças

Rastreabilidade ajuda as equipes a responder a uma pergunta prática: o que mais esta mudança afeta? Quando os requisitos permanecem vinculados às decisões de projeto, restrições, verificações de validação e evidências, as equipes conseguem ver o que mudou, o que ainda está coberto e o que precisa ser revisado antes que o retrabalho se torne caro.

Como um fluxo de trabalho de requisitos conectado ajuda

As equipes de hardware precisam de mais do que um local para armazenar o texto dos requisitos. Documentos e planilhas podem registrar requisitos, mas se tornam mais difíceis de gerenciar à medida que a complexidade do projeto aumenta e cada requisito precisa permanecer conectado ao longo de toda a cadeia de engenharia.

Altium Requirements Portal foi projetado para dar suporte a esse fluxo de trabalho, gerenciando requisitos, rastreabilidade, responsabilidade e validação em um único ambiente compartilhado. Em vez de tratar requisitos como texto isolado, as equipes podem ver o que mudou, o que isso afeta, quem é responsável pela próxima etapa e como o requisito será verificado.

Qual é o “submarino” no seu projeto?

Todo projeto de desenvolvimento de hardware tem restrições que são fáceis de ignorar quando o projeto está avançando rapidamente. Elas podem ser mecânicas, elétricas, regulatórias, operacionais ou relacionadas ao processo. O risco não é que as equipes não tenham conhecimento, mas que conhecimentos importantes nem sempre sejam registrados, conectados e revisados quando o projeto muda.

É isso que torna o caso do S-80 útil além da sua escala. O mesmo padrão pode aparecer no desenvolvimento cotidiano de produtos quando a intenção de engenharia, as decisões de projeto e as evidências não permanecem conectadas ao longo do tempo.

Facilite o rastreamento do impacto de mudanças com uma ferramenta de gerenciamento de requisitos à qual toda a sua equipe possa acessar.

Comece a usar o Requirements Portal →

Perguntas comuns

O que causa problemas de gerenciamento de requisitos em projetos de hardware?

Problemas de gerenciamento de requisitos costumam surgir quando os requisitos não estão conectados ao trabalho de projeto, às restrições e às verificações de validação que afetam. Um requisito pode existir, mas, se a equipe não consegue ver a que ele está conectado, impactos importantes podem passar despercebidos quando o projeto muda.

Por que planilhas se tornam difíceis para o gerenciamento de requisitos?

Planilhas podem registrar o texto dos requisitos, mas se tornam mais difíceis de gerenciar à medida que a complexidade do projeto aumenta. As equipes precisam de uma maneira de manter os requisitos conectados ao trabalho de projeto, ao histórico de mudanças, ao status de validação e às evidências em toda a cadeia de engenharia.

Como a rastreabilidade ajuda a reduzir o retrabalho nas fases finais?

A rastreabilidade ajuda as equipes a responder a uma pergunta prática: o que mais esta mudança afeta? Ao vincular requisitos a decisões de projeto, restrições, verificações de validação e evidências, as equipes conseguem ver o que precisa ser revisado antes que o retrabalho se torne custoso.