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.
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.'
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:
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.
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:
Exemplo de um requisito bem escrito:
Exemplo de um requisito mal escrito:
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.
Além do acima, quando definimos um requisito, ele deve seguir algumas regras básicas:
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.
Existem primariamente dois tipos de requisitos:
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 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):
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:
Portanto, a definição dos requisitos dos subsistemas poderia ser a seguinte:
Esta organização estruturada de requisitos permite uma definição, acompanhamento e gestão mais fáceis.
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.
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.
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.
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.
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.
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.
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!