Requisitos não funcionais

Um colega me perguntou ontem sobre o levantamento de requisitos não funcionais em sistemas, então vou aproveitar que estou devendo posts aqui e falar sobre isso.

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 idéia é 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 criticos 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 espectativa de qualidade esperada pelo cliente.