Introdução
Separar esses dois tipos de requisito ajuda a evitar uma falha comum: construir funções sem definir as condições necessárias para que elas sejam realmente úteis. Um botão pode fazer o que foi programado e ainda assim ser lento, inacessível ou inseguro.
A classificação não precisa virar uma disputa de nomenclatura. Ela é uma ferramenta para lembrar que comportamento e qualidade precisam ser discutidos juntos.
O que são requisitos funcionais?
Requisitos funcionais descrevem o que o sistema deve fazer. Eles podem representar ações, cálculos, regras, respostas e fluxos. Exemplos: cadastrar uma pessoa, gerar um relatório, enviar uma notificação, calcular um valor ou bloquear uma operação sem autorização.
Um requisito funcional fica mais útil quando informa o contexto. Em vez de “o sistema terá busca”, prefira algo como “a pessoa autorizada poderá pesquisar registros por nome e receberá uma indicação quando nenhum resultado for encontrado”.
O que são requisitos não funcionais?
Requisitos não funcionais tratam de atributos de qualidade, restrições e condições de uso. Podem envolver segurança, desempenho, disponibilidade, acessibilidade, compatibilidade, privacidade, legislação ou padrões tecnológicos.
“A página deve ser rápida” é uma intenção, mas ainda precisa de um critério. A equipe pode definir um cenário de uso, uma condição de rede e uma forma de medir o tempo aceitável. O número escolhido deve nascer do contexto do produto, não de uma promessa genérica.
Os dois tipos trabalham juntos
Uma função depende de qualidades para entregar valor. Um cadastro precisa salvar dados corretos, controlar acesso e informar erros de maneira compreensível. Uma busca precisa responder com relevância e funcionar para pessoas que usam teclado ou tecnologias assistivas.
Durante a análise, associe requisitos não funcionais às funções afetadas. Isso facilita arquitetura, planejamento e testes. Também ajuda a negociar prioridades quando não é possível maximizar todas as qualidades ao mesmo tempo.
Exemplo: relatório de membros
Funcionalmente, o sistema deve permitir filtrar pessoas por situação e exportar o resultado. Não funcionalmente, apenas perfis autorizados podem consultar os dados; a exportação deve registrar quem realizou a ação; o arquivo deve ser legível; e a operação deve lidar com uma quantidade de registros compatível com o uso esperado.
Sem a segunda parte, a função pode existir na tela e ainda criar risco de exposição de dados ou uma experiência que não serve para o trabalho cotidiano.
Critérios de aceitação e testes
Critérios de aceitação descrevem as condições que precisam ser verdadeiras para considerar uma funcionalidade concluída. Eles podem ser exemplos de entradas e resultados, regras de negócio ou limites de qualidade.
Um requisito de recuperação de senha, por exemplo, pode ter critérios para e-mail válido, token expirado, tentativa repetida e registro de auditoria. Esses critérios orientam revisão e testes. O artigo O que são testes de software? mostra como transformar comportamentos esperados em verificações.
Exemplos mensuráveis
Quando possível, um requisito não funcional deve indicar medida, contexto e limite:
- “A busca deve apresentar os primeiros resultados em até dois segundos para até 5 mil registros, no ambiente definido para o projeto.”
- “Apenas perfis autorizados podem consultar o relatório, e cada tentativa deve gerar um registro de auditoria.”
- “O formulário deve ser navegável por teclado e informar erros de validação sem depender apenas de cor.”
Os números não devem ser inventados para parecer precisão. Eles precisam ser negociados com base no uso, no risco e na capacidade técnica disponível.
Comparação em uma situação real
| Necessidade | Requisito funcional | Requisito não funcional relacionado |
|---|---|---|
| Inscrição | Registrar uma inscrição em uma turma disponível. | Confirmar o resultado em até dois segundos em condições normais. |
| Consulta | Permitir filtrar inscrições por turma e situação. | Restringir o resultado a perfis autorizados e registrar a consulta. |
| Correção | Permitir que a secretaria corrija dados antes da aprovação. | Manter histórico da alteração com pessoa e data. |
A tabela mostra que os dois tipos se complementam. O comportamento funcional descreve a capacidade; a qualidade e a restrição definem condições para que ela seja confiável no uso real.
Conclusão
Requisitos funcionais dizem “o que o sistema faz”. Requisitos não funcionais explicam “com quais qualidades e restrições ele precisa fazer”. Os dois devem ser descobertos, discutidos e validados em conjunto. A ISO/IEC/IEEE 29148 é uma fonte confiável para aprofundar práticas de requisitos.