O que é um requisito não funcional

Requisitos Não Funcionais ou NFRs descrevem características de software que não são definidas em termos de funcionalidade. Geralmente estes são atributos ou restrições no sistema que terminam com '-ility' ou '-ilities'. Por exemplo:

  • manutenibilidade
  • escalabilidade
  • usabilidade

Tipos de requisitos não funcionais

Existem potencialmente dezenas de tipos NFR. A importância de cada tipo de NFR dependerá do tipo de software, do contexto e do caso de uso. Alguns dos tipos de NFR mais comumente considerados são:

  • Segurança
  • Desempenho
  • Escalabilidade
  • Confiabilidade
  • Usabilidade
  • Jurídico
  • Capacidade de manutenção
  • Portabilidade

A lista abrangente de NFRs está disponível na Wikipédia.

Segurança – um caso especial

Vale a pena dar uma olhada mais de perto na Segurança como uma NFR. Embora a segurança seja comumente considerada não funcional, na realidade a maioria dos requisitos de segurança são funcionais. Por exemplo, verificações de permissão antes de executar um processo provavelmente serão um requisito funcional. Em nossos estudos, mais de 90% todos os requisitos de segurança são funcionais.

Os benefícios da detecção automática de NFRs

Requisitos não funcionais são uma dimensão importante do software. Muitas vezes são negligenciados ou são de má qualidade (inespecíficos, incompletos ou inconsistentes). As NFRs podem ter um impacto significativo no trabalho de entrega de um software. Negligenciá-los pode aumentar o risco de um projeto.

Ao usar o ScopeMaster para analisar seus requisitos para possíveis NFRs, você pode criar uma lista de verificação para garantir que as NFRs sejam cobertas correta e adequadamente. Isso reduzirá o risco para o seu projeto. Além disso, você deseja evitar misturar requisitos funcionais com não funcionais, a menos que seja necessário.

Detecção NFR, Automatizado

O ScopeMaster verifica seus requisitos (ou histórias de usuários) em busca de pistas sobre requisitos não funcionais importantes.

Análise CRUD com ScopeMaster – captura de tela

O ScopeMaster analisa o texto dos seus requisitos de software. Isto detecta os requisitos não funcionais mais prováveis dentro de cada requisito.

Ele determina uma probabilidade de cada requisito ser ou conter um requisito não funcional.

Exemplos de casos de uso

A maioria das NFRs estão “enterradas” em outros requisitos e são difíceis de detectar. Os arquitetos muitas vezes precisam analisar centenas de requisitos para tentar filtrar NFRs que possam impactar a arquitetura de um sistema. Se estes não forem identificados suficientemente cedo, poderão ser tomadas decisões de design inadequadas. Essas decisões de projeto podem levar a retrabalhos dispendiosos ou dívidas técnicas. A capacidade do ScopeMaster de detectar essas NFRs desde o início ajuda a expor as NFRs antes que o trabalho de design seja realizado. Casos de uso típicos:

  • Você tem muitos requisitos e está tentando detectar todos os NFRs de uma categoria específica.
  • Você tem muitos requisitos e não tem certeza se incluiu algum NFR neles.
  • Você precisa verificar NFRs potencialmente conflitantes
  • Seus requisitos foram coletados por diversas pessoas e você precisa harmonizar as NFRs.

O ScopeMaster detecta a provável fraseologia dos requisitos que podem ser ou infere um requisito não funcional.

Requisitos Não Funcionais de Qualidade

O que contribui para NFRs de alta qualidade? Você deve sempre tentar quantificar os requisitos não funcionais em termos quantificáveis que façam sentido para a equipe e com os quais o cliente possa se identificar. Estes devem fornecer o “nível de aceitabilidade” de qualquer NFR. Por exemplo, todas as páginas da web devem carregar em 1,5 segundos, prontas para a interação do usuário.  

Exemplos de requisitos não funcionais

Aqui estão alguns exemplos de NFR, observe a especificidade de cada um. Critérios inequívocos de aprovação/reprovação estão incluídos em cada um:

Desempenho – Todas as páginas da web serão carregadas para interação em 2 segundos em uma conexão de 5 Mbs de qualquer lugar do mundo.

Capacidade – Com alterações insignificantes, o software deverá ser capaz de lidar com 3 milhões de registros de transações.

Jurídico – O sistema deve estar em conformidade com a legislação GDPR, incluindo a capacidade de relatar e/ou excluir registros pessoais mediante solicitação específica.

Usabilidade – O site deve estar em conformidade com WCAG 2.2 nível A