Criação de um Plano de Gestão de Requisitos de Engenharia

Javier Alcina Espigado
|  Criada: Novembro 27, 2024
Criação de um Plano de Gestão de Requisitos de Engenharia

Identificar e estabelecer um conjunto de requisitos no ponto de partida de qualquer projeto é crucial para alcançar o sucesso. Este artigo, de maneira simples, visa introduzi-lo à criação de um plano de gestão de requisitos em projetos de engenharia através de alguns conceitos básicos e o uso do Altium 365 Requirements & Systems Portal.

Este blog é destinado a engenheiros, profissionais, gerentes de projeto, gerentes de produto e qualquer pessoa que precise entender como criar um plano de gestão de requisitos.

O Que É um Requisito?

Embora óbvio, vale a pena refletir sobre a questão 'o que é um requisito?' Um requisito, segundo o dicionário, é 'uma circunstância ou condição necessária para algo.' No mundo da engenharia, os requisitos são uma forma de comunicação entre usuários ou clientes e os desenvolvedores de um projeto. Às vezes, especialmente em projetos grandes, essa é uma das poucas maneiras possíveis de os usuários dizerem aos desenvolvedores o que querem.

Exemplo de um requisito em um projeto automotivo:

'Os usuários devem ser capazes de viajar automaticamente em velocidades pré-definidas por meio do controle de cruzeiro.'

Por Que os Requisitos São Tão Importantes?

Diz-se que: "uma definição e gestão pobres de requisitos podem custar uma fortuna e levar ao fracasso na execução do projeto."

A definição de requisitos é tão importante que geralmente formam a base dos contratos entre clientes e fornecedores. O que é definido nos requisitos deve ser considerado no projeto e pode ser exigido pelo cliente, no entanto, o que não aparece na definição dos requisitos não deve ser exigido na fase de entrega do projeto.

Portanto, se somos responsáveis por escrever os requisitos, devemos:

  • Descobrir exatamente as necessidades do cliente.
  • Criar um documento com uma estrutura clara e requisitos bem organizados.
  • Organizar uma reunião com o cliente para verificar se ambos os lados têm interesses escritos (contrato).
  • Garantir que a solução adotada seja fiel aos requisitos à medida que o projeto avança.
  • Verificar e testar a conformidade com os requisitos.

Este grupo de ações é conhecido como o plano de gestão de requisitos. É muito importante ter um gerente ou equipe de gestão na organização que identifica, define e rastreia os requisitos ao longo da vida do projeto.

Como Deve Ser Escrito um Requisito?

Escrever um requisito não é tão simples e trivial quanto pode parecer. É um documento que deve atender a certa quantidade de critérios. Portanto, um requisito deve:

  • Ser claro, preciso e específico: deve descrever clara e exatamente o que é necessário.
  • Ser conciso: usar o mínimo de palavras possível.
  • Usar linguagem simples: evitar confundir o leitor com termos técnicos ou palavras complicadas.

Exemplo de um requisito bem escrito:

  • Todos os componentes (SMD e thru-hole) devem ser colocados na face SUPERIOR.

Exemplo de um requisito mal escrito:

  • Os componentes SMD devem todos ser colocados do mesmo lado, e deve-se garantir que a solda dos componentes thru-hole esteja no lado oposto à solda dos componentes SMD.

No exemplo acima, o requisito bem escrito é conciso e define perfeitamente sem ambiguidade o que é requerido, enquanto o requisito mal escrito tem texto demais, o que não contribui para nada, confunde o leitor e é impreciso (não define em qual lado os componentes devem ser colocados).

Os requisitos são sempre obrigatórios e, portanto, devem ser escritos utilizando-se "deverá". Quando os requisitos são preferências ou desejos (não obrigatórios), "deveria" pode ser usado para defini-los ou até mesmo "pode" quando se trata de uma sugestão ou permissão concedida.

Regras Básicas Para Definir um Requisito

Além do acima, quando definimos um requisito, ele deve seguir algumas regras básicas:

  • Deve ter um ID único.
  • Deve ser compreendido por si só sem informações adicionais.
  • Deve ser consistente com o restante dos requisitos.
  • Deve estar sempre atualizado (controle de versão).
  • Deve ser viável (evitar requisitos impossíveis).
  • Sua implementação deve ser verificada por meio de inspeção, demonstração ou teste.

Identificação de Requisitos

Cada requisito definido deve ter um ID único para que possa ser referenciado durante a definição e revisão dos requisitos, bem como em qualquer momento durante a fase de execução do projeto. Um exemplo de identificação de requisitos é mostrado usando Altium 365 Requirements and Systems Portal.

Identification of Requirements in Altium 365 Requirements and Systems Portal

Quais Tipos de Requisitos Existem e Como São Classificados?

Existem primariamente dois tipos de requisitos:

  • Requisitos Funcionais: Estes definem a funcionalidade do sistema.
  • Requisitos Não Funcionais: Estes impõem restrições ou limitações à solução (ambientais, confiabilidade, compatibilidade eletromagnética, segurança, regulamentações aplicáveis, requisitos de custo, prazos, etc.).

A combinação destes requisitos funcionais e não funcionais constitui o que é conhecido como especificação do sistema. Na especificação do sistema, os requisitos são agrupados de acordo com os seguintes níveis:

  • Requisitos iniciais ou do cliente
  • Requisitos do sistema
  • Requisitos do subsistema

Requisitos iniciais ou do cliente são aqueles que são diretamente fornecidos pelo cliente ou usuário antes do início do projeto. Eles são cruciais, pois capturam as necessidades do cliente e, assim, servem como ponto de partida para a criação da nossa matriz de requisitos. Posteriormente, a especificação do sistema organiza os requisitos com base no nível de detalhe pertinente a cada parte do projeto. Desta forma, temos requisitos do sistema, que se aplicam ao sistema completo, e requisitos do subsistema, que se aplicam apenas a partes específicas do sistema. Vamos ilustrar isso com um exemplo.

Vamos supor que estamos desenvolvendo um projeto onde um novo smartwatch será criado. Os requisitos do sistema, portanto, são aqueles que se aplicam ao conjunto (veja os exemplos abaixo):

  • REQ-01: Deve ser projetado para usuários adultos.
  • REQ-02: Deve exibir todas as informações na tela.
  • REQ-03: Deve ser recarregável.
  • REQ-04: Deve ter botões ou outros mecanismos para navegação do usuário pelos menus.

Uma vez que os requisitos do sistema tenham sido definidos, os demais requisitos são divididos em diferentes subsistemas.

Seguindo o exemplo do projeto de desenvolvimento do smartwatch, exemplos de subsistemas incluem:

  • Subsistema 1 – Pulseira
  • Subsistema 2 – Tela
  • Subsistema 3 – Energia
  • Subsistema 4 – Comunicações
  • Subsistema 5 – Interface do Usuário

Portanto, a definição dos requisitos dos subsistemas poderia ser a seguinte:

  • STRAP-01: Materiais recicláveis devem ser usados.
  • STRAP-02: Deve ser capaz de ser fixado magneticamente.
  • DISPLAY-01: A tela deve ser de 2 polegadas.
  • DISPLAY-02: A resolução deve ser de 368 x 448 pixels.
  • POWER-01: Deve ser alimentado por uma bateria recarregável.
  • POWER-02: A vida útil da bateria deve ser de pelo menos 48 horas.
  • COMMS-01: Deve ser capaz de comunicação Bluetooth.
  • COMMS-02: Deve ser capaz de comunicação Wi-Fi.
  • UI-01: Deve ter um botão lateral em forma de dial para navegação nos menus.

Esta organização estruturada de requisitos permite uma definição, acompanhamento e gestão mais fáceis. 

Smartwatch requirements example

Rastreabilidade de Requisitos

Em um plano de gestão de requisitos, a rastreabilidade de requisitos é essencial; isso significa acompanhar ou observar a evolução da implementação dos requisitos ao longo do projeto.

Continuando com o exemplo do projeto de smartwatch, uma vez que os esquemas do produto são projetados, engenheiros e gestores devem realizar tantas reuniões quanto necessário para verificar se a solução projetada atende aos requisitos definidos antes de passar para a próxima etapa, neste caso, o layout da PCB.

O Portal de Requisitos e Sistemas auxilia nesta tarefa, pois proporciona visibilidade dos requisitos definidos diretamente no Altium 365. Isso significa que gerentes e engenheiros agora podem rastrear os requisitos no design em tempo real, por meio de um navegador web, permitindo que adicionem comentários, atribuam tarefas aos membros da equipe e forneçam visibilidade em tempo real das mudanças nos requisitos aos engenheiros de design, transformando completamente o paradigma tradicional de design e revisão.

Como os Requisitos são Gerenciados?

Existem várias maneiras de gerenciar requisitos. Empresas com menos recursos financeiros e profissionais independentes muitas vezes usam ferramentas simples e baratas como planilhas controladas por versão, enquanto empresas maiores tipicamente utilizam softwares especializados para gerenciamento de requisitos como DOORS, Valispace, Confluence, ReqView, entre outros. A Altium adquiriu a Valispace e agora integra a ferramenta de gerenciamento de requisitos no ecossistema Altium 365 por meio do Portal de Requisitos e Sistemas.

Procedimento do Plano de Gerenciamento de Requisitos

Com base nas seções anteriores, poderíamos definir o plano de gestão de requisitos como o conjunto de ações por meio das quais a empresa define, gerencia, verifica e valida as necessidades ou requisitos dos stakeholders ao longo da execução do projeto, desde a concepção até a comercialização. A imagem a seguir ilustra um fluxograma de um plano de gestão de requisitos padrão.

A flowchart of a standard requirements management plan
Um fluxograma de um plano de gestão de requisitos padrão

Conclusões

A Importância de Ter um Plano de Gestão de Requisitos

Todo projeto de engenharia deve ter um plano de gestão de requisitos que garanta que a equipe de desenvolvimento compreenda totalmente as necessidades do cliente e todos os requisitos do sistema e subsistema.

Saber Como Escrever, Definir e Identificar um Requisito Corretamente

Regras básicas devem ser seguidas para escrever e definir requisitos. Da mesma forma, é essencial entender os tipos de requisitos que existem e como classificá-los corretamente, bem como compreender o que é a rastreabilidade de requisitos.

Rastreabilidade de Requisitos

Os requisitos são escritos para serem atendidos, portanto, observá-los e acompanhá-los durante a execução do projeto é muito importante, já que quanto mais cedo um desvio ou não conformidade for detectado, menor será o impacto no projeto.

Usar Software Apropriado

Utilize o Portal de Requisitos e Sistemas para maximizar seu potencial em conjunto com o Altium 365. Isso permite uma interação muito mais próxima entre a engenharia de requisitos e a engenharia de desenvolvimento, reduzindo a probabilidade de desvios de projeto e encurtando os tempos de desenvolvimento.

Comece a usar hoje mesmo a gestão de requisitos moderna e potencializada por IA!

Sobre o autor

Sobre o autor

Javier Alcina Espigado is an electronics engineer with more than 20 years of experience in electronic design. He has worked in different industrial sectors such as consumer electronics, automotive, security and aerospace.

He has developed his professional career as a hardware and PCB design engineer, even he has also participated in other disciplines such as firmware development for microcontrollers and management of multidisciplinary teams, such as mechanical (enclosure) design, software development, test and verification, electromagnetic compatibility which has allowed him to acquire a global knowledge in product development, from the idea or conception to its production covering all life cycling of the design.

He has participated in projects with important companies developing electronics in applications such as AR/VR headsets and he was the principal electrical engineer in a project Co-founded by European Union (Horizon 2020) in 2016 (Wardiam Perimeter), which was awarded at the Las Vegas ISC West (International Security Conference) for the best perimeter security product in 2017.

Currently, he is working as PCB Designer in a multinational company, developing electronics for aerospace industry and also provides design services as independent consultant.

Recursos relacionados

Documentação técnica relacionada

Retornar a página inicial
Thank you, you are now subscribed to updates.