Exemplo De Requisitos Nao Funcionais

Um exemplo de requisitos não funcionais muito comum é a afirmação de que o sistema deve ser seguro, rápido e fácil de usar, pois esses critérios não descrevem uma função específica que o software execute, mas sim como ele deve se comportar sob certas condições.

O que são Requisitos Não Funcionais e sua Importância

Requisitos não funcionais são as características qualitativas que um sistema deve possuir, atuando como as regras de engenharia que definem a viabilidade, confiabilidade e usabilidade de uma solução.

Enquanto os requisitos funcionais descrevem *o que* o sistema faz — como um botão de login ou um cálculo financeiro — os não funcionais definem *como* esses recursos devem ser entregues, cobrindo aspectos como desempenho, segurança, manutenibilidade e escalabilidade.

Para o exemplo de requisitos não funcionais citado no início, a diferença é sutil, mas crucial: "O sistema deve processar login em até 2 segundos" é um requisito não funcional, pois mede uma característica de desempenho, enquanto "O sistema deve permitir login de usuário" é funcional, pois descreve uma ação.

Exemplos Práticos de Requisitos Não Funcionais por Categoria

Para tornar o conceito abstrato mais concreto, vamos analisar um exemplo de requisitos não funcionais organizado por categoria, que é a forma mais didática de entender sua aplicação.

Imagine um aplicativo de banco digital; nele, as regras de qualidade vão muito além da simples entrega de um cadastro de usuário.

Desempenho (Performance)

Essa categoria foca na velocidade e na capacidade de resposta do sistema.

• Exemplo de requisitos não funcionais de desempenho: A tela inicial deve ser carregada em menos de 1,5 segundos sob uma conexão 4G média.
• Exemplo de requisitos não funcionais: O sistema deve suportar até 10.000 requisições simultâneas sem degradação significativa da interface.

Segurança (Security)

A segurança garante que os dados e as funcionalidades estejam protegidos contra acessos não autorizados.

• Exemplo de requisitos não funcionais de segurança: Todas as comunicações entre o cliente e o servidor devem ser criptografadas utilizando o protocolo TLS 1.2 ou superior.
• Exemplo de requisitos não funcionais de autenticação: O sistema deve bloquear automaticamente a conta após 5 tentativas de login falhas consecutivas.

Usabilidade (Usability)

Este critério avalia a facilidade com que os usuários podem interagir com a aplicação.

• Exemplo de requisitos não funcionais de usabilidade: O aplicativo deve ser compatível com leitores de tela, atendendo aos critérios de acessibilidade WCAG 2.1 nível AA.
• Exemplo de requisitos não funcionais de feedback: Qualquer ação realizada pelo usuário (como enviar um formulário) deve gerar uma resposta visual ou sonora em até 300 milissegundos.

Confiabilidade e Disponibilidade (Reliability & Availability)

Sistemas críticos, como os de banco de dados ou de saúde, precisam de alta taxa de funcionamento contínuo.

• Exemplo de requisitos não funcionais de disponibilidade: O sistema deverá ter uptime de 99,9% ao ano, permitindo no máximo 8 horas de indisponibilidade não planejadas anualmente.
• Exemplo de requisitos não funcionais de recuperação: Em caso de falha total, o sistema deve ser totalmente restaurado a partir de backups em até 4 horas (RTO de 4h).

Como Especificar Requisitos Não Funcionais de Forma Clara

A principal armadilha ao trabalhar com requisitos não funcionais é a subjetividade; um requisito mal formulado como "o sistema deve ser rápido" é praticamente inútil, pois não mensura o desempenho.

Para evitar ambiguidades, utilize a técnica SMART (Específico, Mensurável, Atingível, Relevante, Temporal) ou padrões industriais como o IEEE 830.

Técnicas de Elaboração

A chave para um exemplo de requisitos não funcionais eficaz está na clareza das métricas.

• Formulação Vaga: "O site deve ser seguro."
• Formulação Clara (exemplo de requisitos não funcionais): "O portal de atendimento ao cliente deve estar em conformidade com a norma PCI DSS nível 1 e todos os dados de cartão de crédito devem ser armazenados com criptografia AES-256 em repouso."

Além disso, é vital priorizar esses requisitos, pois nem todos têm o mesmo custo de implementação.

• Prioridade Alta: Requisitos que impactam diretamente na segurança ou na vida do usuário (ex: criptografia de dados).
• Prioridade Média: Requisitos que melhoram a experiência, mas não a bloqueariam (ex: tempo de resposta de busca).
• Prioridade Baixa: Requisitos desejáveis, mas que podem ser deixados para futuras iterações (ex: personalização avançada de temas).

Desafios Comuns na Implementação

Muitas equipes de desenvolvimento focam exclusivamente nos requisitos funcionais, negligenciando a importância dos requisitos não funcionais até as fases de testes ou, pior, após o lançamento.

Um exemplo de requisitos não funcionais mal compreendido é a performance em um ambiente real: um banco de dados que funciona bem em testes locais pode sofrer gargalos em produção devido a latências de rede, exigindo ajustes específicos de configuração.

Testes automatizados de regressão geralmente cobrem apenas a funcionalidade, deixando brechas para problemas de usabilidade ou acessibilidade que só são descobertos por usuários reais ou em auditorias específicas.

Related Videos

A Valorização no Ciclo de Vida do Software

Incorporar um exemplo de requisitos não funcionais desde o início do projeto salva tempo, dinheiro e reputação a longo prazo.

Durante a fase de arquitetura, decisões como a escolha entre um banco de dados SQL ou NoSQL são fortemente influenciadas por requisitos não funcionais de escalabilidade e consistência de dados.

Portanto, tratar esses requisitos como tão importantes quanto os funcionais é o caminho para construir produtos de qualidade, que atendam não apenas as funcionalidades esperadas, mas que também ofereçam uma experiência robusta, segura e agradável ao usuário final.