Requisitos

Os requisitos dizem o que o projeto tem de entregar e como se vai verificar que o fez. São a base do âmbito, do prazo e do custo: um requisito mal compreendido no início costuma custar muito mais a corrigir no fim.

Requisitos

Para cada requisito são criadas especificações técnicas, com as funções a alcançar e a testar e o que deve ser entregue como resultado do projeto.

Requisitos funcionais

O que o resultado deve permitir fazer. Por exemplo, «o utilizador consegue exportar o relatório em PDF».

Requisitos não funcionais

Não estão explicitamente no projeto, mas espera-se que sejam alcançados. Podem ser de desempenho, facilidade de uso, robustez, segurança, legais, operacionais ou outros. Por exemplo, «a página carrega em menos de 3 segundos».

Os não funcionais são os que mais falham, precisamente porque ninguém os escreveu. Perguntar ao cliente «o que seria inaceitável?» ajuda a descobri-los.

O que torna um requisito bom

• Necessário: responde a uma necessidade real do cliente ou do negócio.
• Claro e sem ambiguidade: admite uma só interpretação. Evitar «rápido», «fácil» ou «moderno» sem número.
• Verificável: tem um critério de aceitação que permite dizer se foi ou não cumprido.
• Consistente: não contradiz outros requisitos.
• Rastreável: tem origem identificada e pode ser seguido até ao teste.

Critérios de aceitação

Cada requisito deve ter um critério de aceitação escrito antes de se começar a trabalhar. Exemplo: «a exportação em PDF funciona para relatórios até 200 linhas, em menos de 5 segundos». Sem critério, a discussão sobre se o requisito foi cumprido só acontece no fim, quando já é cara.

Rastreabilidade

Rastreabilidade é poder seguir cada requisito desde a origem até à sua verificação, e perceber como da especificação se passou para:

1. Desenho
2. Desenvolvimento
3. Teste
4. Lançamento

O objetivo é comprovar que o requisito inicial foi satisfeito, e saber o que é afetado quando um requisito muda.

Requisito	Origem	Desenho	Teste	Estado
R1: exportar relatório em PDF	Cliente	D-04	T-12	Aceite
R2: carregar em menos de 3 s	Negócio	D-07	T-15	Em teste
R3: acesso por perfil	Segurança	D-09	T-18	Por testar

Os valores são ilustrativos. Uma matriz simples deste tipo, mantida atualizada, basta na maioria dos projetos.

Requisitos e mudança

Os requisitos mudam, e é normal. O que não pode acontecer é mudarem sem registo. Cada alteração deve passar pelo controlo de alterações, com avaliação do impacto no prazo, no custo e no equilíbrio entre as restrições, e refletir-se na baseline. O âmbito traduz-se depois em pacotes de trabalho (WBS).

Checklist de Requisitos

• O âmbito está escrito, incluindo o que fica de fora
• Cada requisito tem identificador, origem e critério de aceitação
• Os requisitos não funcionais foram perguntados e registados
• Os requisitos foram revistos e aprovados pelo cliente ou patrocinador
• Existe rastreabilidade até ao teste
• Existe processo para pedir e decidir alterações

Erros Frequentes

• Requisitos vagos, que cada pessoa interpreta de forma diferente.
• Esquecer os requisitos não funcionais até ao teste final.
• Descrever soluções («usar a tecnologia X») em vez de necessidades.
• Aceitar alterações sem registo nem impacto avaliado.
• Não envolver quem vai usar o resultado.

Como Aplicar em 30 Dias

1. Semana 1: delimitar o âmbito (dentro e fora) e identificar quem tem de ser ouvido.
2. Semana 2: recolher e escrever os requisitos funcionais e não funcionais, com critérios de aceitação.
3. Semana 3: rever com o cliente, aprovar e criar a matriz de rastreabilidade.
4. Semana 4: definir o processo de alterações e ligar os requisitos ao plano e aos testes.

Referências

As características de um bom requisito seguem a norma indicada abaixo. Os exemplos, as listas de verificação e o plano de 30 dias são prática e interpretação do autor.

• ISO/IEC/IEEE 29148:2018, Systems and software engineering: Life cycle processes: Requirements engineering.
• PMI, PMBOK Guide: gestão do âmbito do projeto e recolha de requisitos.
• IIBA, BABOK Guide.

Atualizado em: 03/10/2026