Recolha de Requisitos: Guia Completo e Modelo

Estes pedidos tornam-se a lista de requisitos do projeto. O cumprimento dos requisitos determinará se o empreendimento é considerado um projeto bem-sucedido ou não. 

Os gestores de projetos utilizam documentos de requisitos e ferramentas de gestão de requisitos para acompanhar estes tipos de requisitos ao longo do projeto:

• Requisitos funcionais
• Requisitos técnicos
• Requisitos não funcionais
• Requisitos do sistema

Nota lateral:

A recolha de requisitos não se limita ao período que antecede a produção. A documentação de alterações, a documentação da garantia, etc. são formas úteis de documentação contínua de requisitos que revelam novos requisitos ao longo de um projeto — ou até depois do projeto!

 

Enquanto trabalhar com um cliente, a documentação estará sempre a crescer e a evoluir.

Porque é importante recolher requisitos?

A recolha de requisitos é importante pelas seguintes razões (tal como a documentação desses requisitos): 

1. Serve como ponto de referência para documentar a evolução de um projeto, as suas partes móveis e a sua implementação 
2. Serve como plano para que as partes interessadas no projeto compreendam melhor o que esperar do projeto (o quê, onde, quando e porquê do projeto).
3. Reduz a margem para erros e ambiguidades, uma vez que os requisitos são claramente documentados e acordados antes do início do trabalho.
4. Fornece mecanismos de controlo e verificação ao longo da produção e do controlo de qualidade do projeto, permitindo que os gestores de projetos e os membros da equipa consultem novamente essa documentação sempre que houver dúvidas sobre como proceder.

Além de definir aquilo que podem esperar, um planeamento eficaz da gestão de requisitos deve definir aquilo que não devem esperar. Incluir uma secção de “Pressupostos” e/ou “Exclusões” é uma abordagem sensata para eliminar o risco da temida imaginação do cliente. 

Exemplo de uma especificação de requisitos de software

Eis um exemplo de uma especificação de requisitos para um projeto de comércio eletrónico:

• O quê: Integração com o PayPal
• Onde: Finalização da compra
• Quando: Durante o passo 3 de 4 do processo de finalização da compra (após o formulário web do endereço de envio e antes da confirmação)
• Porquê: Uma integração estabelecida (por exemplo, PayPal) é uma solução melhor do que uma integração personalizada robusta para um serviço de pagamentos neste caso, porque cumpre facilmente os requisitos comerciais.

• Pressupostos
  • Taxa fixa para todo o envio e manuseamento
  • Todo o envio é efetuado dentro dos EUA (sem incluir o Alasca ou o Havai)
  • Não se aplicam impostos
• Exclusões 
  • Cálculos personalizados das taxas de envio e manuseamento
  • Envio internacional, para o Alasca ou para o Havai
  • Regras fiscais

Lembre-se: quanto menor for a diferença entre as expectativas do cliente e a realidade do seu produto digital, mais satisfeito ficará o cliente com o resultado final. A qualidade da sua gestão de requisitos está diretamente relacionada com a sua capacidade, enquanto gestor de projetos, de reduzir qualquer zona cinzenta no que diz respeito às expectativas do cliente. 

Na grande maioria das vezes, um cliente aceitará que limite o aumento descontrolado do âmbito se isso significar que está a preservar o orçamento; se explicar suficientemente ao cliente por que razão uma funcionalidade será abordada (ou não será abordada) e, em seguida, documentar a lógica subjacente a essa abordagem nos requisitos, será muito mais provável que o cliente colabore. 

Será mais provável que dê a sua aprovação e, mais tarde, quando estiver a realizar Testes de aceitação pelo utilizador (UAT), já terá uma noção inicial do "porquê" por detrás da solução da sua equipa.

Processo de recolha de requisitos em 6 passos

Embora a recolha de requisitos deva começar assim que um trabalho é iniciado e continuar ao longo de todo o ciclo de vida do projeto, nunca é demasiado cedo para começar a recolher e documentar requisitos. Na verdade, comece ontem.

Eis os passos para recolher requisitos.

1. Tome notas

Em todas as reuniões em que participe — quer sejam internas, com a sua equipa de projeto, quer sejam externas, com o seu cliente — tome sempre notas. Nunca parta do princípio de que outra pessoa as está a tomar.

No momento, pode ser fácil assumir que tudo o que está a ser discutido será recordado, mas, três meses e 15 reuniões mais tarde, a sua equipa e o seu cliente agradecer-lhe-ão por ter um registo dessas discussões ao qual possam voltar.

Consulte aqui alguns dos procedimentos que recomendo para tomar notas sobre os requisitos:

• Antes de entrar na reunião, prepare o seu documento de notas de modo a refletir a agenda, para que seja mais fácil organizar os itens de ação e os pontos abordados. Desta forma, lembrar-se-á do que é necessário enquanto regista as informações relacionadas de forma organizada. 
• Depois de qualquer reunião, reserve 15-30 minutos para rever as suas notas, assimilar o que foi discutido, concluir a priorização dos itens de ação e identificar desafios/sinais de alerta ou necessidades de esclarecimento ou de reuniões adicionais.
• Envie as suas notas à sua equipa interna de projeto. Peça-lhes que revejam e verifiquem aquilo que identificou como itens de ação, sinais de alerta, etc. 
• Depois de a equipa lhe dar a sua aprovação, envie as suas notas ao cliente. 
• Por fim, utilize as suas notas como referência para criar tarefas a partir de cada item de ação. Adicione qualquer informação nova à documentação dos requisitos e agende as reuniões necessárias para investigação ou discussão adicionais. 

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

2. Analise os requisitos criativos

Não deixe as decisões de design e estilo ao critério de cada membro da equipa: formalize os requisitos criativos sempre que possível. As orientações criativas são inestimáveis para os programadores. No mínimo, certifique-se de que tem um guia de estilos à mão — mesmo que seja tão simples como indicar os tipos de letra e as cores da marca.

Reúna todos os recursos criativos, como logótipos ou tipos de letra da marca, e carregue-os para um espaço partilhado (como um software de gestão de recursos digitais) para garantir o acesso e a visibilidade de toda a equipa.

3. Redija o documento de requisitos

Ao iniciar a documentação, lembre-se: a sua primeira tentativa de documentar os requisitos será a mais difícil. Porquê? Porque não tem um documento anterior que possa utilizar (ou seja, COPIAR-COLAR). Felizmente, este artigo inclui um modelo de documentação de requisitos que lhe servirá de base.

Tal como apresentado neste modelo, organizo a minha documentação de requisitos em quatro partes:

1. Anotação: Inclui os números do seu design anotado. Se o design da sua página tiver 8 elementos, terá 8 anotações e a sua coluna de anotações terá 8 linhas
2. Elemento: Inclui os títulos dos elementos, conforme relacionados com cada anotação
3. Requisito funcional: Inclui uma definição (os requisitos, descritos detalhadamente) para cada elemento
4. Funcionalidade administrativa/CMS: Defina qualquer funcionalidade administrativa e/ou de CMS relacionada com o elemento correspondente

4. Realize uma revisão interna

Nesta parte do processo de recolha de requisitos, marque outra reunião interna com a sua equipa de projeto para rever a documentação dos requisitos. Esta é uma verificação e validação interna final para garantir que compreende a implementação.

Se possível, peça à equipa para rever a documentação dos requisitos antes da reunião, para que possa comparecer preparada com as suas perguntas e/ou comentários. Utilize a reunião para discutir quaisquer perguntas ou comentários sobre os requisitos.

Faça as revisões necessárias à documentação, com base na sua discussão interna. Por fim, volte a enviar a documentação dos requisitos revista à equipa para obter uma última aprovação. Assim que a equipa interna do projeto der a sua aprovação final à documentação dos requisitos, guarde o documento como PDF para garantir que permanece no seu estado finalizado para o passo seguinte: a definição das tarefas. 

5. Defina as tarefas

Forneça a versão em PDF da documentação dos requisitos à sua equipa de desenvolvimento. Idealmente, os seus programadores ou o responsável pelo desenvolvimento irão definir as tarefas necessárias para a implementação. 

Embora algumas organizações possam seguir um processo em que os gestores de projeto definem todas as tarefas, prefiro que os programadores definam as suas próprias tarefas; as poucas horas que isso lhes exige compensam.

Ainda pode fornecer orientações úteis à sua equipa enquanto esta define as tarefas de desenvolvimento e os resultados a entregar. Após a definição das tarefas, poderá obter uma estimativa horária final.

Compare essa projeção com o calendário do projeto que foi previamente comunicado ao seu cliente e faça a gestão em conformidade, se e quando necessário. Para saber mais sobre a estimativa de projetos, consulte este guia completo para estimar projetos.

6. Realize uma revisão externa

Chegou o momento de apresentar a documentação dos requisitos ao seu cliente. Forneça-a em formato PDF para garantir que não são feitas alterações. Isto (1) demonstra o seu empenho em garantir que o cliente compreende a solução digital e (2) servirá como proteção, permitindo-lhe dizer “eu avisei” (mas de forma muito mais eloquente) quando o inevitável aumento do âmbito do projeto surgir.

Informe o seu cliente. Explique-lhe detalhadamente esta valiosa documentação que preparou cuidadosamente para ele. Lembre-se: o cliente é o especialista no seu negócio. Você é o especialista na solução digital que lhe está a oferecer. O cliente está a pagar-lhe por esta solução. Informe e capacite o seu cliente. 

Assim que o cliente tiver confirmado que compreende a documentação dos requisitos, é altura de obter a aprovação formal. Envie a documentação dos requisitos assinada e aprovada à sua equipa e guarde-a num espaço partilhado, utilizando software de gestão de documentos, para que exista uma indicação formal de que o desenvolvimento pode começar.

Técnicas de recolha de requisitos

Eis algumas técnicas que o ajudarão a garantir que realiza o importante trabalho de recolha de requisitos da melhor forma possível:

1. Comece imediatamente

A documentação dos requisitos deve começar assim que as conversas tiverem início, antes de definir rigorosamente o plano ou os objetivos exatos do projeto. Registe tudo o que conseguir e, depois, reduza-o ao essencial. Eis algumas estratégias que pode experimentar com o seu cliente:

• Envie-lhe um questionário sobre o que gostaria de ver no projeto
• Realize uma sessão de brainstorming
• Organize um grupo de discussão

Em vez de remover informações do documento, categorize-as entre o que está incluído e o que não está incluído — isto evita pressupostos do cliente mais tarde.

Poderá extrair a documentação de requisitos WIP (em curso) e indicar onde essa informação foi registada, por que motivo poderá não estar incluída, a lógica subjacente à decisão e a data em que foi registada, tornando-a rastreável.

2. Utilize modelos

Depois de ter elaborado alguns documentos de requisitos, comece a utilizá-los e a transformá-los em modelos para utilização futura noutros projetos. Especialmente se estiver focado em projetos de comércio eletrónico ou de aplicações de aprendizagem, começará a identificar padrões de funcionalidade. Identifique onde pode reutilizá-los. 

3. O trabalho de equipa torna o sonho realidade

Se houver diferentes tipos de membros da equipa num projeto, os requisitos de cada área de especialização poderão ser elaborados pelos respetivos especialistas.

Em muitos casos, a conversa sobre os requisitos é um percurso sinuoso de chamadas telefónicas, várias reuniões e conversas separadas, etc. É por isso fundamental atribuir a documentação de requisitos aos respetivos membros da equipa à medida que procede à recolha e compilação dos requisitos.

4. Não se limite a registar requisitos — aprenda

Faça mais do que tirar notas. Espere mais do que receber dos seus colaboradores um e-mail com uma parede de texto que componha a parte deles dos requisitos. Reserve tempo para se sentar com a sua equipa de programadores e conhecer as soluções que a equipa tem em mente para a implementação. Discuta o porquê e o como. Faça perguntas.

Antes de dizer: "Mas só temos um determinado tempo por dia — e quanto ao orçamento?", compreenda isto: se uma solução em que está a trabalhar for aplicável a mais do que um projeto, então este tempo adicional para obter uma compreensão mais aprofundada não tem necessariamente de ser faturável. Está a desenvolver a sua experiência no domínio, o que melhora diretamente o seu trabalho diário. 

5. Mantenha o seu cliente informado

Tenha um documento interno de requisitos, bem como um documento de requisitos WIP destinado ao cliente. No documento interno, poderá preocupar-se menos com a inclusão de notas mais transparentes.

Se não estiver a lidar com informação sensível, pode criar este espaço partilhado através de um Documento Google, com permissões que permitam ao cliente fazer comentários. Se estiver a lidar com informação sensível, partilhe semanalmente uma versão do documento de requisitos para fornecer ao cliente uma visão geral do que foi registado.

6. Parta do princípio de que o seu cliente quer sempre saber mais

Em vez de correr o risco de presumir que o seu cliente sabe mais do que realmente sabe — e de essa suposição vir a prejudicá-lo mais tarde —, parta do princípio de que o seu cliente quer sempre saber mais. Para cada anotação, pergunte a si próprio “Porquê?” cinco vezes, de modo a garantir o rigor de cada requisito. 

Perguntar a si próprio “Porquê?” cinco vezes para cada requisito desafia-o a considerar verdadeiramente a lógica subjacente a cada elemento e funcionalidade de cada tipo de página. Poderá surpreender-se com tudo o que aprende (ou percebe que precisa de aprender).

3 dicas de especialistas para redigir um documento de requisitos de projeto

1. Redija separadamente os requisitos dos elementos globais

Para eliminar redundâncias, inclua todos os elementos globais numa secção “Elementos globais” da documentação de requisitos. Isto aplica-se a elementos globais como os itens do menu de navegação principal, tudo o que se encontre no cabeçalho global e tudo o que se encontre no rodapé. 

Depois de redigir os requisitos para estes elementos globais, não se dê ao trabalho de os anotar nas restantes páginas; anote apenas os elementos específicos dessas páginas.

More Articles

• 16 Melhores Cursos de Formação em Gestão de Projetos para Frequentar em 2026

2. Copie e cole funcionalidades idênticas para garantir a consistência

Esta é apenas uma dica a ter em mente para preservar a sua sanidade (e a do seu cliente). Irá notar isto sobretudo em elementos comuns das páginas, como imagens principais/faixas, cabeçalhos ou ícones de “voltar” — entre muitas funcionalidades repetidas nos diferentes tipos de página (não confundir com elementos globais). 

3. Tenha em conta a área de administração e o CMS (ou a sua ausência)

Quando estamos tão focados na funcionalidade de cada elemento da página, é fácil descurar a funcionalidade administrativa e/ou do CMS. Se está a implementar uma solução que oferece funcionalidade administrativa e/ou de CMS, certifique-se de que a inclui como uma coluna própria nos seus requisitos. Veja o exemplo abaixo:

Modelo de documento de requisitos [Transferir]

As especificidades da definição dos seus requisitos dependerão da sua relação com o cliente, da experiência da sua equipa e de outros fatores.

No entanto, continuará a precisar dos elementos básicos de um documento de requisitos de projeto, que definem a funcionalidade, a localização, o design, etc. Eis o nosso modelo de documento de requisitos (terá de ser membro para lhe aceder):

Ganhe velocidade com mais de 100 modelos premium

Torne-se membro DPM para obter acesso a inúmeros modelos criados por especialistas, que o ajudarão a trabalhar de forma mais rápida e eficiente.