Requisitos não funcionais

Os requisitos não funcionais são requisitos que declaram restrições, ou atributos de qualidade para um software ou para o processo de desenvolvimento deste sistema. Segurança, precisão, usabilidade, performance e manutenabilidade são exemplos de requisitos não funcionais.

Conceito

Requisitos não-funcionais descrevem qualidades do sistema (como o sistema é) ao invés de suas funcionalidades (o que ele faz).

A qualidade afeta diretamente a satisfação do cliente e envolvidos com o sistema. Por isso requisitos não funcionais são importantes. A ideia é explorar essa questão para ter um cliente mais feliz no final do projeto.

A qualidade de um software pode ser avaliada de duas maneiras. A qualidade visível para o usuário final e a qualidade interna visível em tempo de desenvolvimento (mas que permite ou não evoluções do software).

Exemplos

Requisitos de qualidade visíveis ao usuário

  • Usabilidade: resista a solicitações como “O software deve ser amigável para o usuário”. Isso não é suficiente. Explore o assunto e questione: “Como podemos testar e garantir que o software é amigável? O que é esperado?”. Provavelmente o cliente responda: “Eu quero que o usuário não precise dar mais de 3 clicks para acessar as informações e possa acessar a ajuda online de qualquer página do sistema”. Pronto. Conseguimos extrair um requisito não funcional de usabilidade. 

  • Performance: “Todo o sistema deve ter a melhor performance possível” também não é um bom requisito de performance. Em um sistema grande nem sempre todas as partes do software tem que ter a mesma performance. Se explorarmos o assunto com o cliente muitas vezes ele pode dizer: “A parte principal do meu software é o cadastro e atendimento de solicitações e várias atendentes cadastram novas solicitações o tempo todo. Para ter produtividade o preenchimento e processamento desse cadastro não pode demorar mais do que 30 segundos. Mas os outros cadastros não são tão críticos”. Isso é um requisito não funcional mais adequado e possível de ser implementado. Os desenvolvedores podem focar no que realmente é importante, fazer politicas de cache para esse caso e outras estrategias sem aumentar o custo do software como um todo. 

Geralmente em tempo de levantamento de um software o usuário não se lembra de informar os requisitos não funcionais. Ele está preocupado com as funcionalidades do sistema. Por isso o Analista de Requisitos deve explorar e questionar esse assunto.

Segue um questionário que pode ser utilizado para iniciar a conversa sobre esse tema:


Questionário



  1. Quantas pessoas vão utilizar o software? Desse número, quantas utilizarão simultaneamente? (não precisa ser um valor fechado… pode ser um range: entre 100 e 200 pessoas utilizarão e é esperado que no máximo 50 utilizem simultaneamente)

  2. Dos relatórios previstos, quais podem ser gerados por processamento batch (de madrugada) e quais devem ser online (com dados do momento)? Qual o tempo aceitável para processar e gerar um relatório online?

  3. Qual o tempo de resposta esperado para as principais funcionalidades do sistema? E para as outras?

  4. Qual tipo de acesso a aplicação vai ter? Somente via intranet? Internet?

  5. Qual o perfil dos usuários que vão acessar a aplicação? Possuem conhecimento de internet? São usuários avançados?

  6. É desejável que a maior parte das funcionalidades da aplicação possam se acessadas via teclado (sem auxilio do mouse)?

  7. A aplicação deve ser compatível com quais versões do browser e/ou sistema operacional?

  8. Quais os padrões de implementação esperados? Os desenvolvedores podem escrever o código em qualquer idioma? Podem utilizar qualquer banco de dados e qualquer tecnologia?

  9. Qual a segurança esperada para o trafego de dados? Toda comunicação entre o servidor e o browser tem que ser criptografada usando SSL? Será adquirido o certificado SSL? Ou a aplicação não tem dados críticos e confidenciais / vai ser executada em uma rede segura?

  10. Qual a disponibilidade a aplicação deve ter? O tempo médio entre falhas, tempo máximo para acertar os problemas? Número máximo de bugs em cada versão? Nesse caso a resposta pode ser que aplicação deve obedecer um acordo de SLA ou que existem regras especificas para esse software de acordo com o negocio.

Muitas outras perguntas podem ser criadas para complementar esse questionário. Mas ele é o básico que precisamos saber para mapear os requisitos não funcionais e criar um software mais alinhado com a expectativa de qualidade esperada pelo cliente.

Fonte: Bruno Braga


Related Posts Plugin for WordPress, Blogger...