Engenharia de Requisitos no Desenvolvimento de Hardware

Sejamos honestos: poucas pessoas ficam entusiasmadas com requisitos. Ainda assim, toda equipe de hardware já sentiu o custo de requisitos pouco claros: retrabalho que aparece tarde demais ou uma versão construída que não atende ao que as partes interessadas realmente pediram. 

A engenharia de requisitos (RE) é a disciplina que segue um processo estruturado de definição, documentação e gerenciamento de requisitos para que o produto final resolva o problema certo. Quando bem aplicada, ela detecta erros cedo, mantém a equipe alinhada e dá a todos a confiança de que o que será entregue é de fato o que foi acordado construir.

No entanto, o termo costuma gerar confusão porque tem raízes tanto na engenharia de software quanto na engenharia de sistemas de produtos de hardware. 

Neste artigo, você terá uma definição clara de engenharia de requisitos e do seu papel no desenvolvimento de produtos de hardware. Abordamos tanto uma visão teórica quanto uma estrutura prática de como ela é aplicada em um projeto de hardware, com exemplos do mundo real e uma lista dos erros mais comuns, além de como evitá-los.

Principais conclusões

• A engenharia de requisitos ajuda equipes de hardware a transformar a intenção de projeto em requisitos claros e a manter todos da equipe alinhados.
• Os requisitos orientam o projeto desde o planejamento inicial e o design até os testes, as mudanças e a documentação final.
• Um bom processo de requisitos ajuda as equipes de desenvolvimento a identificar problemas cedo, evitar reprojetos caros e garantir que o produto final atenda ao que foi acordado.

O que é engenharia de requisitos?

Engenharia de requisitos é uma abordagem sistemática e disciplinada para definir, documentar e gerenciar requisitos durante o desenvolvimento de produtos de hardware.

Ela ajuda as equipes a entender o problema que precisa ser resolvido, esclarecer e analisar as necessidades das partes interessadas, resolver conflitos e trade-offs, documentar o que o produto deve alcançar e manter esse entendimento atualizado à medida que o produto evolui.

Na prática, os requisitos criam um entendimento compartilhado entre as partes interessadas e as equipes de engenharia sobre o que está sendo desenvolvido, por que está sendo desenvolvido e como a equipe saberá se o produto final atende à intenção do projeto.

Benefícios da engenharia de requisitos

Quando a RE é bem executada, ela ajuda a evitar mal-entendidos e erros caros, mantém a equipe alinhada e ajuda a garantir que o produto final atenda aos seus requisitos.

Os principais benefícios da RE incluem:

• Visão compartilhada: Mantém as partes interessadas, os gestores e as equipes de engenharia alinhados em torno do mesmo entendimento sobre o que está sendo desenvolvido.
• Escopo claro: Deixa claro o que faz parte do projeto e o que não faz, ajudando a evitar adições descontroladas conhecidas como scope creep.
• Reduz erros caros: Ajuda a encontrar problemas nos requisitos logo no início, antes que se transformem em retrabalho de projeto caro, novos protótipos ou testes repetidos.
• Melhora o planejamento e o cronograma: Dá às equipes uma visão mais clara do que precisa ser desenvolvido, facilitando a estimativa do trabalho e a criação de cronogramas realistas.
• Melhora a qualidade do produto: Ajuda a garantir que o produto final faça o que foi acordado e atenda aos padrões de qualidade exigidos.

Evolução da disciplina de engenharia de requisitos

A engenharia de requisitos tem raízes tanto na engenharia de sistemas quanto na engenharia de software. Essas duas origens se desenvolveram em contextos de engenharia diferentes, por isso o termo ainda pode ter um escopo ligeiramente distinto dependendo da fonte.

No contexto da engenharia de software, o foco está principalmente nos requisitos de desenvolvimento de software: o que o software deve fazer, como deve se comportar e quais atributos de qualidade deve atender. Engenheiros de software pensam em requisitos funcionais e não funcionais documentados como user stories, casos de uso e critérios de aceitação. No contexto da engenharia de sistemas, o escopo é mais amplo. Requisitos se referem ao sistema inteiro, incluindo hardware, software, pessoas, processos, interfaces, condições de operação e outras características do sistema. Engenheiros de sistemas falam sobre requisitos em nível de sistema alocados para hardware, mecânica, elétrica, firmware e fatores de segurança, registrados como declarações formais de requisitos e matrizes de rastreabilidade de requisitos.

No desenvolvimento de hardware, a RE reúne essas duas perspectivas. Ela combina o rigor e o escopo multidisciplinar da engenharia de sistemas, necessários para lidar com custos de lista de materiais (BOM), restrições térmicas e limitações de manufatura, com a rastreabilidade ao longo do ciclo de vida usada na engenharia de software para manter os requisitos testáveis e conectados durante todo o desenvolvimento.

Disciplinas relacionadas à engenharia de requisitos

A engenharia de requisitos está intimamente relacionada a outras disciplinas de desenvolvimento de produtos, especialmente engenharia de sistemas e gestão de produto.

Engenharia de sistemas

A engenharia de sistemas enxerga um produto como um sistema completo. Um engenheiro de sistemas garante que diferentes partes, como hardware, software, componentes mecânicos e testes, funcionem adequadamente em conjunto e não entrem em conflito.

Isso está intimamente ligado à RE porque os requisitos dão a todas essas equipes uma referência comum sobre o que o produto precisa alcançar.

Se você gosta de analogias, imagine construir uma casa. Diferentes especialistas trabalham na fundação, na parte elétrica, no encanamento e no aquecimento, mas alguém ainda precisa garantir que todas essas partes realmente se encaixem em uma única estrutura completa. A engenharia de sistemas exerce exatamente esse papel no desenvolvimento de produtos.

Gestão de produto

A gestão de produto ajuda a decidir o que construir e por quê. Gestores de produto conversam com clientes, estudam o mercado, analisam concorrentes e trabalham com o negócio para decidir quais problemas valem a pena resolver e quais recursos são mais importantes.

Isso também está ligado à RE porque essas necessidades do cliente em alto nível e os objetivos de negócio se tornam o ponto de partida para definir os requisitos do produto.

Fases do processo de engenharia de requisitos

O processo de RE pode ser organizado de diferentes maneiras, dependendo da área de aplicação, das pessoas envolvidas e da organização. Em alguns projetos, as atividades acontecem principalmente uma após a outra, enquanto em outros elas são repetidas e revisitadas à medida que a equipe aprende mais.

Como descrito em um artigo publicado no Requirements Engineering journal, uma abordagem didática comum divide o processo de RE em quatro atividades centrais (fases):

• Elicitação de requisitos: coleta de requisitos das partes interessadas e de outras fontes para entender o que o sistema deve fazer e sob quais condições deve operar.
• Análise e especificação de requisitos: revisão do que foi coletado, resolução de informações pouco claras ou conflitantes e transformação disso em requisitos claros que a equipe de engenharia possa usar.
• Validação de requisitos: verificação de que os requisitos estão corretos, completos e descrevem o que o sistema pretende alcançar.
• Gerenciamento de requisitos: acompanhamento dos requisitos e de suas mudanças ao longo do tempo, incluindo por que mudaram e quais outros requisitos, trabalhos de projeto ou testes podem ser afetados.

Quem está envolvido no processo

Vários papéis-chave estão envolvidos na estrutura de RE, trabalhando juntos para definir o que um produto deve fazer:

• Responsável pelos requisitos: O engenheiro que pega necessidades vagas das partes interessadas, faz as perguntas certas e as transforma em um conjunto de requisitos que a equipe de engenharia possa realmente usar no desenvolvimento do produto. Muitas vezes, esse papel é desempenhado por um engenheiro de sistemas, engenheiro líder ou alguém com responsabilidade semelhante.
• Liderança técnica de produto: As pessoas que se comunicam com o lado das partes interessadas/do negócio, entendem suas necessidades e depois transformam essa demanda em um objetivo claro de produto. Isso pode incluir Product Managers, Program Managers ou funções semelhantes.
• Engenheiro de implementação: O engenheiro que usa esses requisitos definidos para projetar e construir sua parte do produto. Isso pode incluir engenheiros de eletrônica, mecânica, software ou firmware.
• Responsável pela verificação: A pessoa que decide como os requisitos serão testados e garante que as revisões e os testes necessários sejam concluídos. Isso pode incluir engenheiros de verificação, engenheiros de teste ou engenheiros de QA.

Estrutura prática de engenharia de requisitos para o desenvolvimento de hardware

Embora as quatro atividades acima definam o núcleo do processo de RE, as equipes de hardware precisam de uma maneira prática de aplicá-las ao longo de um projeto.

A seguir, apresentamos uma visão prática da estrutura de engenharia de requisitos para o desenvolvimento de hardware, mostrando como os requisitos se encaixam em cada etapa.

Início do projeto: capturar a intenção

No início de um projeto, os líderes técnicos geralmente recebem informações vagas, como solicitações de clientes, requests for proposal (RFPs), objetivos de negócio ou restrições de custo, tamanho ou cronograma. Por exemplo, um cliente pode pedir um dispositivo menor que ofereça suporte a um caso de uso específico.

Junto com o responsável pelos requisitos, os líderes técnicos esclarecem o que é necessário e transformam essas informações em requisitos de alto nível que descrevem o que o produto deve alcançar.

Engenharia de requisitos: definir requisitos

Os requisitos de alto nível da fase de início do projeto ainda são amplos demais para o design detalhado. Nesta fase, o responsável pelos requisitos define o sistema geral, divide-o em partes e subsistemas e transforma esses requisitos de alto nível em requisitos mais específicos para cada parte.

Ele também verifica se os requisitos não entram em conflito, se nada importante está faltando e se cada um é claro e testável. O resultado é um conjunto acordado de requisitos que a equipe de engenharia pode usar como ponto de partida para o projeto do produto.

Implementação: desenvolver projetos

Os engenheiros de implementação usam os requisitos acordados para projetar e construir sua parte do produto, seja criando um esquemático, modelando uma peça 3D ou escrevendo software ou firmware. À medida que o projeto evolui, eles vinculam cada requisito ao recurso de projeto que o atende. Esses vínculos criam a rastreabilidade do projeto e ajudam o responsável pelos requisitos a ver como os requisitos foram implementados.

Verificação & validação: testar e verificar

Os requisitos também definem o que deve ser verificado durante revisões e testes. O engenheiro de verificação define como cada requisito será verificado e trabalha com os engenheiros de implementação para realizar as revisões, medições ou testes necessários, além de registrar os resultados. Isso conecta o que o produto precisava alcançar com as evidências que mostram se ele realmente alcançou esse objetivo.

Gerenciamento de mudanças: revisar e iterar

Os requisitos e os projetos de produto frequentemente mudam durante o desenvolvimento. Um requisito pode se mostrar impossível de atender, um componente pode se tornar indisponível no mercado ou uma nova restrição pode surgir. Quando isso acontece, o responsável pelos requisitos acompanha o que mudou, por que mudou e quais requisitos, partes do projeto ou testes são afetados.

Documentação & transferência: entregar o projeto

No final do projeto, o Responsável pelos Requisitos trabalha com o Engenheiro de Verificação e o restante da equipe para encerrar os requisitos, as revisões de projeto e as atividades de verificação. A documentação final deve fornecer um registro rastreável do que era necessário, do que foi construído e de como isso foi verificado. Clientes, fabricantes, auditores ou equipes que continuarem trabalhando no produto precisarão dessas informações mais tarde.

Exemplos de Engenharia de Requisitos

Engenharia de Requisitos em Dispositivos Médicos

A Engenharia de Requisitos é usada em produtos médicos e de tecnologia assistencial. Os requisitos acompanham o produto durante todo o desenvolvimento. As equipes transformam as necessidades das partes interessadas em requisitos de sistema estruturados, mantêm esses requisitos conectados à medida que as especificações mudam e os usam para planejar a verificação e documentar os resultados dos testes.

Os dispositivos médicos acrescentam uma camada regulatória. As equipes dedicam mais esforço à rastreabilidade, à verificação, à documentação e à papelada. Isso dá suporte à aprovação regulatória em estruturas como FDA 21 CFR Part 820 nos EUA e ISO 13485:2016 na UE e em outros mercados.

O protetor bucal HitIQ é um exemplo de dispositivo vestível médico em que as necessidades de segurança determinam cada especificação técnica. Descubra como isso é feito na história completa de sucesso do cliente.

Engenharia de Requisitos em Eletrônicos de Consumo e Industriais

O processo central de engenharia de requisitos é semelhante em eletrônicos de consumo e industriais, mas os produtos são desenvolvidos em condições diferentes. Produtos de consumo, como dispositivos para casas inteligentes ou wearables, são vendidos em grandes volumes e lançados rapidamente. Produtos industriais, como controladores lógicos programáveis (PLCs) ou acionamentos de motores, precisam operar por anos em condições severas.

Em ambos os casos, as equipes registram o que o produto deve fazer, vinculam cada requisito ao projeto, atualizam os requisitos quando algo muda e testam com base neles.

O que muda é onde as equipes colocam o esforço extra. Em eletrônicos de consumo, isso vai para acompanhar mudanças rápidas, porque um único requisito mal compreendido pode significar reprojetar a placa. Em eletrônicos industriais, isso vai para a verificação, porque o produto precisa ser testado para longa vida útil e condições severas antes de ser enviado.

Para desenvolver hardware confiável que esteja em conformidade com as normas de segurança, é fundamental manter requisitos e mudanças de projeto conectados. Leia como a MakeSafe Tools gerencia isso na história completa de sucesso.

Como Evitar Armadilhas Comuns da Engenharia de Requisitos

A engenharia de requisitos traz alguns desafios comuns. Saber o que pode dar errado torna mais fácil identificar problemas cedo e evitá-los durante o desenvolvimento de produtos de hardware.

Aqui estão algumas das armadilhas mais comuns às quais você deve ficar atento e como evitá-las:

Ferramentas de Software para Engenharia de Requisitos

Gerenciar um pequeno conjunto de requisitos é relativamente simples. À medida que um projeto cresce, manter tudo organizado e atualizado exige mais esforço. Nesse ponto, a forma como você gerencia os requisitos começa a importar mais.

Na prática, as equipes geralmente trabalham com uma destas abordagens:

• Planilhas e Documentos: Familiares e fáceis de começar a usar, o que os torna úteis para projetos menores. No entanto, à medida que o projeto cresce, exigem mais trabalho manual para manutenção.
• Ferramentas Dedicadas de Gerenciamento de Requisitos (RM): Oferecem mais estrutura e controle à medida que os projetos se tornam mais complexos. A contrapartida é que algumas ferramentas também trazem mais processo do que uma equipe menor pode precisar.

O objetivo é usar estrutura suficiente para o projeto sem tornar o gerenciamento de requisitos mais complicado do que precisa ser.

Para equipes menores de hardware que já superaram as planilhas, mas não precisam de um grande fluxo corporativo de RM, Requirements Portal é uma opção prática a considerar. Ele foi projetado para dar a equipes menores uma forma mais estruturada de gerenciar requisitos sem a sobrecarga de um sistema corporativo tradicional.

Conclusão e Próximos Passos

Neste ponto, você já deve ter uma compreensão clara dos principais conceitos de engenharia de requisitos e de como eles se aplicam na prática.

Se você quiser continuar aprendendo sobre engenharia de requisitos, estes recursos são um bom ponto de partida:

• ISO/IEC/IEEE 29148:2018 fornece o padrão internacional para processos e práticas de engenharia de requisitos. Ele oferece orientações adicionais sobre como os requisitos devem ser escritos, estruturados, documentados e gerenciados.
• NASA Systems Engineering Handbook oferece orientação prática sobre como os requisitos são criados, redigidos, verificados e usados durante o desenvolvimento de sistemas.
• Guide to the Systems Engineering Body of Knowledge (SEBoK) explica como os requisitos se encaixam no processo mais amplo de engenharia de sistemas e como diferentes partes de um sistema são desenvolvidas em conjunto.
• Requirements Engineering journal publica pesquisas, exemplos do setor e diferentes abordagens para engenharia de requisitos com mais profundidade.

Se você está pronto para passar da teoria à prática, experimente Requirements Portal e comece a trabalhar com requisitos estruturados em um projeto real de hardware hoje mesmo, gratuitamente e sem necessidade de configuração.

Perguntas Frequentes

Por Que a Engenharia de Requisitos É Importante?

A engenharia de requisitos é importante porque ajuda a equipe a construir o produto certo ao compreender claramente as necessidades das partes interessadas antes que o projeto e o desenvolvimento avancem demais.

Qual É o Papel de um Engenheiro de Requisitos?

Um engenheiro de requisitos transforma as necessidades das partes interessadas em requisitos claros que a equipe de engenharia pode usar e mantém esses requisitos organizados à medida que o projeto muda. Ele atua como uma ponte entre clientes e equipes de desenvolvimento. 

Qual É a Diferença Entre Engenharia de Requisitos e Gerenciamento de Requisitos?

Engenharia de requisitos é todo o processo de descobrir, entender e registrar o que um sistema precisa fazer em primeiro lugar. Gerenciamento de requisitos é a parte específica desse trabalho que mantém esses requisitos organizados e acompanha quaisquer mudanças depois que eles são escritos.