O que é requisito não funcional em engenharia de software?
Carlos Moore
⚡ Resumo Inteligente
Os Requisitos Não Funcionais especificam atributos de qualidade como desempenho, segurança, usabilidade, confiabilidade, escalabilidade e portabilidade, definindo o quão bem um sistema de software deve se comportar e transformando expectativas vagas em metas de engenharia mensuráveis, testáveis e aplicáveis ao longo do ciclo de vida de desenvolvimento.
O que é um requisito não funcional?
A Requisito não funcional Um requisito não funcional (NFR) especifica um atributo de qualidade de um sistema de software. Os NFRs avaliam o sistema em termos de capacidade de resposta, usabilidade, segurança, portabilidade e outros atributos de qualidade que são críticos para o sucesso. Um exemplo comum de requisito não funcional é: “Quão rápido o site carrega?” A incapacidade de atender aos requisitos não funcionais resulta em sistemas que deixam os usuários frustrados.
Os requisitos não funcionais em engenharia de software impõem restrições ao projeto do sistema em todo o backlog ágil. Por exemplo, o site deve carregar em três segundos quando o número de usuários simultâneos exceder 10,000. Descrever os requisitos não funcionais é tão importante quanto descrever os requisitos funcionais.
Tipos de Requisitos Não Funcionais
As principais categorias de requisitos não funcionais são:
Tipos de requisitos não funcionais
- Usabilidade
- Facilidade de manutenção
- Manageability
- Recuperabilidade
- Total
- Integridade de Dados
- Capacidade
- Disponibilidade
- Global
- Interoperabilidade
- Confiabilidade
- Manutenção
- Conformidade Regulamentar
- Restrições ambientais
Exemplos de Requisitos Não Funcionais
Aqui estão exemplos práticos de requisitos não funcionais:
- Os usuários devem alterar a senha inicial após o primeiro login bem-sucedido, e a senha inicial nunca deve ser reutilizada.
- Os funcionários não estão autorizados a atualizar suas próprias informações salariais, e qualquer tentativa nesse sentido deverá ser comunicada ao administrador de segurança.
- Toda tentativa malsucedida de um usuário para acessar um item de dados deve ser registrada em uma trilha de auditoria.
- O site deverá suportar 20 milhões de usuários simultâneos sem comprometer o tempo de resposta.
- O software deve ser portátil, de forma que a transição entre sistemas operacionais não cause problemas.
- A privacidade das informações, a exportação de tecnologias restritas e os direitos de propriedade intelectual devem ser auditáveis.
Requisitos Funcionais vs. Requisitos Não Funcionais
As principais diferenças entre requisitos funcionais e não funcionais são:
| Parâmetros Técnicos | Requisito funcional | Requisito não funcional |
|---|---|---|
| O que é ? | Verbo | Atributos |
| Exigência | É obrigatório | Não é obrigatório |
| Tipo de captura | Ele é capturado no caso de uso. | É capturado como um atributo de qualidade. |
| Resultado final | característica do produto | Propriedades do produto |
| Capturar | Fácil de capturar | Difícil de capturar |
| Objetivo | Ajuda a verificar a funcionalidade do software. | Ajuda você a verificar o desempenho do software. |
| Área de foco | Concentre-se nos requisitos do usuário | Concentra-se na expectativa do usuário. |
| Documentação | Descreva o que o produto faz | Descreve como o produto funciona |
| Tipo de Teste | Teste funcional como testes de sistema, integração, ponta a ponta, testes de API, etc. | Testes não funcionais como desempenho, estresse, usabilidade, testes de segurança, etc. |
| Execução de Teste | A execução do teste é feita antes do teste não funcional. | Após o teste funcional |
| Informação do produto | características do produto | Propriedades do produto |
Vantagens dos Requisitos Não Funcionais
Os principais benefícios de Teste não funcional como:
- Os requisitos não funcionais garantem que o sistema esteja em conformidade com as normas legais e de compliance.
- Eles protegem a confiabilidade, a disponibilidade e o desempenho do sistema.
- Eles proporcionam uma boa experiência ao usuário e facilidade de operação.
- Eles definem a política de segurança do software.
Desvantagens dos Requisitos Não Funcionais
As desvantagens comuns dos requisitos não funcionais são:
- Requisitos não funcionais podem afetar diversos subsistemas de software de alto nível.
- Elas exigem considerações especiais durante a fase de arquitetura e projeto de alto nível, o que aumenta o custo.
- A implementação raramente se resume a um único subsistema de software.
- São difíceis de modificar depois de concluída a fase de arquitetura.
Modelo FURPS+ para Classificação de Requisitos Não Funcionais
FURPS+ é a taxonomia mais utilizada para requisitos não funcionais. Desenvolvida originalmente pela Hewlett-Packard, ela agrupa atributos de qualidade em cinco categorias principais, além de restrições adicionais marcadas com o símbolo “+”. O modelo ajuda os analistas de negócios a evitar que classes inteiras de requisitos sejam esquecidas.
- Funcionalidade: Capacidade, segurança e reutilização que vão além da lista básica de funcionalidades.
- Usabilidade: Fatores humanos, estética, consistência, documentação e capacidade de resposta da experiência do usuário.
- Confiabilidade: Disponibilidade, tempo médio entre falhas, capacidade de recuperação, previsibilidade e precisão.
- Desempenho: Velocidade, rendimento, capacidade, escalabilidade e consumo de recursos sob carga.
- Suportabilidade: Testabilidade, flexibilidade, instalabilidade, localizabilidade e facilidade de manutenção do sistema entregue.
- Mais (+): Design, implementação, interface e restrições físicas, como plataformas, padrões ou hardware necessários.
Equipes que mapeiam todos os requisitos não funcionais para uma categoria FURPS+ têm menos probabilidade de entregar um sistema que atenda aos requisitos de funcionalidade, mas falhe em desempenho, segurança ou facilidade de manutenção.
Como escrever requisitos não funcionais testáveis
Um requisito não funcional bem escrito é mensurável, verificável e tem prazo definido. Afirmações vagas como "o sistema deve ser rápido" ou "o aplicativo deve ser seguro" são aspirações, não requisitos. Siga os passos abaixo para converter uma intenção em um requisito não funcional testável.
- Identifique o atributo de qualidade. Mapeie a preocupação para uma categoria FURPS+ para que a equipe saiba se é um requisito de desempenho, usabilidade, segurança ou confiabilidade.
- Escolha uma métrica. Cada requisito não funcional (NFR) precisa de uma unidade — milissegundos, solicitações por segundo, usuários simultâneos, porcentagem de tempo de atividade ou um padrão de conformidade como a ISO 27001.
- Defina um limite numérico. Substitua "rápido" por "menos de 400 milissegundos no 95º percentil". Substitua "altamente disponível" por "99.9% de tempo de atividade mensal".
- Descreva a condição. Indique a carga, o ambiente ou o segmento de usuários ao qual o limite se aplica, como por exemplo, "durante o pico de vendas com 10,000 usuários simultâneos".
- Defina o método de verificação. Observe o tipo de teste — teste de carga, teste de penetração, experimento de caos, auditoria de acessibilidade — e a ferramenta que confirmará o limite.
- Aplique a verificação SMART. Confirme se o requisito é Específico, Mensurável, Atingível, Relevante e Temporalmente definido antes de entrar na lista de pendências.
Exemplo de reescrita: “O sistema deverá ser rápido” torna-se “A página de finalização da compra deverá responder em menos de 500 milissegundos no percentil 95 com 5,000 usuários simultâneos, verificado por um JMeter "Teste a carga de cada versão." A declaração revisada permite que os desenvolvedores projetem levando isso em consideração, os testadores verifiquem e os proprietários do produto aceitem sem questionamentos.
