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 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.

Usabilidade

Usabilidade é o mesmo que facilidade de uso. Se um produto é fácil de usar, 
o usuário tem maior produtividade: aprende mais rápido a usar, 
memoriza as operações e comete menos erros.

Shneiderman
1. Manter a consistência
2. Permitir atalhos aos utilizadores frequentes
3. Oferecer feedback informativo
4. Desenhar diálogos com princípio, meio e fim
5. Oferecer prevenção e recuperação
6. Permitir desfazer facilmente as operações
7. Favorecer a sensação de controlo
8. Reduzir a carga na memória de curta-duração.

As 10 heurísticas de Nielsen
1. Visibilidade do estado do sistema
2. Ligação entre o sistema e o mundo real
3. Liberdade e controlo por parte do utilizador
4. Consistência e standards
5. Prevenção de erros
6. Reconhecimento em vez do lembrar
7. Flexibilidade e eficiência de utilização
8. Desenho minimalista e estético
9. Ajuda no reconhecimento de erros, diagnóstico e
recuperação de erros
10. Ajuda e documentação.

Os 7 princípios de Norman
1. Utilizar simultaneamente o conhecimento do mundo (e.g.
disponibilizar a informação necessária) e interno ao utilizador
(e.g. teclas de atalho para maior rapidez).
2. Simplificar a estrutura das tarefas (e.g. automatizando parte da
tarefa).
3. Tornar as coisas visíveis: estreitar os desníveis de Execução e
Avaliação (e.g. o que pode ser feito e o resultado das
operações).
4. Efectuar as associações co ectamente (e.g. etiquetas dos
botões, metáforas).
5. Explorar o poder das limitações, tanto naturais como artificiais
(e.g. assistentes).
6. Desenhar para o e o.
7. Quando tudo falha, seguir o standard

Software para captura de telas (Screenshot)

Snagit é um editor de imagens perfeito para você trabalhar, ele captura e edita qualquer parte da tela.

A tela do computador muda constantemente. Textos, fotografias, gráficos, mensagens, imagens em movimento… O Snagit é a arma perfeita para você imortalizar todos esses elementos da forma que preferir.

O programa é um capturador de telas potente e muito fácil de usar. No Snagit basta clicar no botão “PrintScreen” para guardar uma cópia da tela. Mas as vantagens do aplicativo não param por aqui.

Utilize qualquer uma das capturas predeterminadas. Copie a tela inteira ou apenas a janela ativa. Se preferir, guarde uma área determinada da imagem. Acesse todos os modos de captura com um clique direito no ícone do Snagit da bandeja do sistema.

O Snagit traz ainda um editor para trabalhar com as imagens capturadas. Destaque elementos concretos, aplique filtros, modifique as bordas e as cores da imagem, insira notas e balões de texto.

Ainda oferece uma série de componentes adicionais para complementar as funcionalidades do software.

 

Link: http://www.techsmith.com/download/trials.asp

Gerador de CPF / CNPJ

Este gerador de CPF tem como proposta auxiliar
programadores, analistas, testadores e estudantes a gerar CPF ‘s
válidos para utilização em testes de aplicações em desenvolvimento.

Basta baixar o plugin e instalar no firefox.

Segue o link: https://addons.mozilla.org/pt-BR/firefox/addon/gerador-de-cpf-e-cnpj/

Tipos de teste

Alguns dos principais tipos de Teste de Sistema

Tipo de Teste	Descrição
Teste de Unidade	Teste em um nível de componente ou classe. É o teste cujo objetivo é um “pedaço do código”.
Teste de Integração	Garante que um ou mais componentes combinados (ou unidades) funcionam. Podemos dizer que um teste de integração é composto por diversos testes de unidade*1
Teste Operacional	Garante que a aplicação pode rodar muito tempo sem falhar.
Teste Positivo-negativo	Garante que a aplicação vai funcionar no “caminho feliz” de sua execução e vai funcionar no seu fluxo de exceção. *2
Teste de regressão	Toda vez que algo for mudado, deve ser testada toda a aplicação novamente.
Teste de caixa-preta	Testar todas as entradas e saídas desejadas. Não se está preocupado com o código, cada saída indesejada é visto como um erro.
Teste caixa-branca	O objetivo é testar o código. Às vezes, existem partes do código que nunca foram testadas.
Teste Funcional	Testar as funcionalidades, requerimentos, regras de negócio presentes na documentação. Validar as funcionalidades descritas na documentação (pode acontecer de a documentação estar inválida)
Teste de Interface	Verifica se a navegabilidade e os objetivos da tela funcionam como especificados e se atendem da melhor forma ao usuário.
Teste de Performance	Verifica se o tempo de resposta é o desejado para o momento de utilização da aplicação.
Teste de carga	Verifica o funcionamento da aplicação com a utilização de uma quantidade grande de usuários simultâneos.
Teste de aceitação do usuário	Testa se a solução será bem vista pelo usuário. Ex: caso exista um botão pequeno demais para executar uma função, isso deve ser criticado em fase de testes. (aqui, cabem quesitos fora da interface, também).
Teste de Volume	Testar a quantidade de dados envolvidos (pode ser pouca, normal, grande, ou além de grande).
Testes de stress	Testar a aplicação sem situações inesperadas. Testar caminhos, às vezes, antes não previstos no desenvolvimento/documentação.
Testes de Configuração	Testar se a aplicação funciona corretamente em diferentes ambientes de hardware ou de software.
Testes de Instalação	Testar se a instalação da aplicação foi OK.
Testes de Segurança	Testar a segurança da aplicação das mais diversas formas. Utilizar os diversos papéis, perfis, permissões, para navegar no sistema.

Muitos outros tipos de testes são possíveis. Entretando, é preciso entender os requisitos funcionais e não funcionais (garantia e utilidade) do negócio, para definir exatamente o nível de testes que pretende-se estabelecer para uma determinada aplicação. Testar demais é tão infeficiente quanto testar pouco.