Guia Didático: Requisitos para Desenvolvimento de Sistemas

Introdução: O que é um “Requisito”?

Imagine que você vai construir uma casa. Antes de levantar uma parede sequer, é preciso ter uma planta: ela define onde ficarão os quartos, quantos banheiros haverá, o tipo de telhado, a localização das instalações elétricas e hidráulicas, entre outros detalhes.

No desenvolvimento de software, os requisitos são essa planta.

Um requisito é uma descrição clara do que o sistema deve fazer, como deve se comportar e quais restrições deve respeitar. Ele serve como ponte entre a necessidade do cliente (a ideia) e o produto final (o sistema funcional).

Atenção: Se os requisitos estiverem errados ou incompletos, não importa quão bem o sistema seja programado — ele será o sistema errado.

Parte 1: Os Dois Tipos Essenciais de Requisitos

Didaticamente, os requisitos são divididos em duas categorias principais: Funcionais e Não Funcionais.

1. Requisitos Funcionais (RF)

O que são?

Descrevem o que o sistema faz — ou seja, suas funcionalidades, ações e comportamentos esperados.

Como identificar?

Pergunte: “O que o sistema deve fazer?”

Analogia prática (um carro):

Deve acelerar ao pressionar o pedal.
Deve frear quando o freio é acionado.
Deve ligar os faróis ao girar o botão.

Exemplos em software:

“O sistema deve permitir login com e-mail e senha.”
“O sistema deve gerar um relatório de vendas em PDF.”
“O usuário deve poder adicionar produtos ao carrinho.”
“O sistema deve calcular o imposto com base no estado do cliente.”

2. Requisitos Não Funcionais (RNF)

O que são?

Descrevem como o sistema é ou como opera — ou seja, as qualidades, restrições e padrões que o sistema deve atender.

Como identificar?

Pergunte: “Quais são as características de qualidade ou restrições do sistema?”

Analogia prática (um carro):

Deve ser vermelho (estética).
Deve acelerar de 0 a 100 km/h em até 8 segundos (desempenho).
Deve ter 5 estrelas em testes de colisão (segurança).
Deve fazer 15 km por litro (eficiência).

Exemplos em software (por categoria):

Desempenho: “Qualquer página deve carregar em menos de 2 segundos.”
Usabilidade: “Um novo usuário deve concluir uma compra em até 3 minutos.”
Segurança: “As senhas devem ser armazenadas com criptografia forte (ex: bcrypt).”
Confiabilidade: “O sistema deve ter disponibilidade de 99,9%.”
Compatibilidade: “O site deve funcionar nos navegadores Chrome, Firefox e Safari.”
Legal/Regulatório: “O sistema deve estar em conformidade com a LGPD.”

Por que essa divisão importa? Um sistema pode executar todas as funções corretamente (RF), mas ser lento, inseguro ou difícil de usar (RNF ruim). Nesse caso, falha na experiência do usuário — e, portanto, falha como produto.

Parte 2: O Processo de Engenharia de Requisitos

Saber o que são requisitos não basta. É essencial entender como obtê-los, organiza-los e mantê-los ao longo do projeto. Esse processo é chamado de Engenharia de Requisitos e envolve quatro etapas fundamentais:

1. Elicitação (Levantamento de Requisitos)

Objetivo: Descobrir o que o cliente e os usuários realmente precisam.

Técnicas comuns:

Entrevistas com stakeholders (clientes, usuários, gestores).
Workshops colaborativos.
Análise de sistemas existentes ou documentos de negócio.
Observação direta do usuário em seu ambiente de trabalho.

Desafio principal: O cliente muitas vezes não sabe exatamente o que quer — cabe ao analista traduzir necessidades em requisitos claros.

2. Análise e Especificação

Objetivo: Organizar, priorizar e documentar os requisitos de forma clara, completa e sem ambiguidades.

Resultado esperado: Um documento formal chamado ERS (Especificação de Requisitos de Software).

Boas práticas:

Usar linguagem simples, mas precisa.
Evitar termos vagos como “rápido”, “fácil” ou “moderno” — substitua por métricas (ex: “carregar em <2s”).
Validar com o cliente durante a escrita.

3. Validação

Objetivo: Confirmar que os requisitos documentados refletem de fato as necessidades reais.

Como fazer:

Revisões com o cliente.
Protótipos de interface (wireframes ou mockups).
Cenários de uso (“histórias de usuário”).

Erro comum: Pular essa etapa e partir direto para o desenvolvimento — o que leva a retrabalho, custos extras e frustração.

4. Gerenciamento de Requisitos

Objetivo: Controlar mudanças nos requisitos durante o projeto.

Por que é necessário? Requisitos mudam — o cliente evolui, o mercado muda, novas leis surgem.

Boas práticas:

Usar ferramentas de rastreabilidade (ex: Jira, Trello com etiquetas de RF/RNF).
Manter versão controlada do ERS.
Criar um comitê de mudanças para avaliar impactos antes de aceitar novos requisitos.

Conclusão

Requisitos bem definidos são a base de qualquer projeto de software bem-sucedido. Eles evitam mal-entendidos, reduzem retrabalho e garantem que o time esteja construindo a solução certa, da maneira certa.

Invista tempo na engenharia de requisitos — o retorno será um produto mais alinhado, mais eficiente e mais valorizado pelos usuários.

Referências (Formato ABNT)

INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS. IEEE Std 830-1998: IEEE Recommended Practice for Software Requirements Specifications. New York: IEEE, 1998.
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de Software: uma abordagem prática. 9. ed. Porto Alegre: AMGH, 2021.
PROJECT MANAGEMENT INSTITUTE. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK®). 7. ed. Newtown Square: Project Management Institute, 2021.
SOMMERVILLE, Ian. Engenharia de Software. 10. ed. São Paulo: Pearson Education do Brasil, 2019.

Dica prática: Copie este conteúdo diretamente para um novo documento no Google Docs. Ele está formatado para facilitar a leitura, com títulos claros, exemplos concretos e linguagem acessível — ideal para estudos, apresentações ou guias internos de equipe.