Requisitos funcionais e não funcionais: SEO

Os requisitos funcionais e não funcionais é o conjunto de funções principais ou não que qualquer
programa deve executar, da mesma forma que serve para informar ao cliente as funcionalidades
que o programa irá executar. Aqui essas funções são nomeadas no sistema de posicionamento
web (SEO)
Requisitos funcionais
 Melhorar o posicionamento em relação às empresas concorrentes
 Atualizar a página da Web
 Gerar palavras-chave do site
 Gerar URLs possíveis
 Analisar conteúdo técnico do site (presença de tags e JavaScript ou flash)
 Calcule a taxa de rejeição para determinar a popularidade do site
 Calcular o número de palavras-chave por página

Requisitos não funcionais

 O sistema deve ter uma interface amigável (Interface)
 Conheça os objetivos da empresa
 Realizar manutenção no site (software)
 Analisar o tempo de carregamento das páginas principais (desempenho)
 Fazer uso de um banco de dados que contém as informações inseridas (software)

REQUISITOS FUNCIONAIS
Nome Base de dados
Cara Requisito
Prioridade Alto
Descrição Cada vez que uma nova conta é criada com os dados de
cada usuário deve ser armazenado no banco de dados (Estar
na unidade de armazenamento do PC ou servidor)
Entrada Dados inseridos pelo usuário
Processo Salvar dados do usuário
Saídas Registro de dados
Tabela 1: Requisitos funcionais - banco de dados

Nome Interface de registro de dados

Cara Requisito
 Prioridade Alto
Descrição O sistema terá uma interface amigável e intuitiva para que o
usuário preencha facilmente os dados de seu cadastro.
Entrada Informações do Usuário
Processo Interface de registro
Saídas Dados registrados
Tabela 2: Requisitos funcionais - Interface de registro de dados

Nome Sistema adaptável

Cara Requisito
Prioridade Alto
Descrição O sistema deve ter a capacidade de se adaptar a qualquer
dispositivo (computadores, celulares, Tablet).
Entrada Gerenciador de Conteúdo
Processo Adaptação ao dispositivo host
Saídas Usar o Gerenciador de conteúdo no dispositivo convidado
Tabela 3: Requisitos funcionais - Sistema adaptável
Nome Modelo de interface
Cara Requisito
Prioridade Alto
Descrição O sistema terá um template, que permite ao usuário fazer
modificações e adaptá-las ao seu gosto
Entrada Modelo de sistema
Processo Modelo de modelo por usuário
Saídas Adaptação do template ao gosto do usuário
Tabela 4: Requisitos funcionais - Modelo de interface

Nome Compatibilidade do navegador

Cara Requisito
Prioridade Alto
 Descrição O sistema deve ser compatível com os navegadores de
internet atuais (Internet Explorer, Mozilla Firefox, Google
Chrome).
Entrada Gerenciador de Dados
Processo Compatibilidade do navegador
Saídas Visualização no navegador
Tabela 5: Requisitos funcionais - Compatibilidade do navegador

REQUISITOS NÃO FUNCIONAIS

Nome Ataques de segurança

Cara Requisito
Prioridade Alto
Descrição O sistema deve ser capaz de evitar ataques como injeção de
SQL, ataques xss, middleware, ataques CSRF, validação de
formulário.
Entrada Ataques de injeção de SQL, ataques xss, Middleware,
ataques CSRF, validação de formulários.
Processo Detectar ataque
Saídas Parar ataque
Tabela 6: Requisitos não funcionais - Ataques de segurança

Nome Operacionalidade
Cara Requisito
Prioridade Alto
 Descrição O gerenciador de conteúdo deve ser fácil de usar para
usuários que não têm conhecimento no desenvolvimento de
páginas web
Entrada Ideia do site
Processo Design e configuração do site pelo usuário
Saídas Site encerrado pelo usuário
Quadro 7: Requisitos não funcionais - operacionalidade

Nome Acesso à Conta

Cara Requisito
gPrioridade Alto
Descrição O acesso às contas deve ser através de senhas de pelo
menos 6 dígitos
Entrada Início da seção
Processo Solicitar senha
Saídas Seção Iniciar
Tabela 8: Requisitos não funcionais - Acesso à conta
Nome Visualizando com navegadores
Cara Requisito
Prioridade Alto
Descrição O sistema deve ser visível nos navegadores atuais (Internet
Explorer, Mozilla Firefox, Google Chrome).
Entrada Executando projeto da Web
Processo Adaptação ao navegador
Saídas Ver o projeto atual
Tabela 9: Requisitos não funcionais - Exibindo com navegadores
Nome Tempo em vista
Cara Requisito
Prioridade Meia
Descrição O sistema não deve levar mais de 6 segundos para exibir o
 conteúdo modificado no gerenciador de conteúdo.
Entrada Projeto Web
Processo Modificar conteúdo
Saídas Alterações feitas no sistema de gerenciamento de conteúdo
Tabela 10: Requisitos não funcionais - tempo de exibição
Nome Usabilidade
Cara Requisito
Prioridade Alto
Descrição O sistema deve apresentar mensagens de erro que permitam
ao usuário identificar o tipo de erro
Entrada Problema apresentado ao usuário em algum lugar do projeto.
Processo Analise o problema
Saídas Determine que tipo de problema é e exiba-o
Tabela 11: Requisitos não funcionais – Usabilidade
Nome Limitação do modelo
Cara Requisito
Prioridade Meia
Descrição O sistema terá apenas um modelo base que pode ser
modificado pelo usuário
Entrada Modelo base
Processo Modificar o modelo base do gerenciador de conteúdo
Saídas Modelo modificado ao gosto do usuário
Tabela 12: Requisitos não funcionais - Limitação do modelo

Requisitos funcionais e não funcionais, exemplos e dicas

O desenvolvimento de software é uma daquelas atividades onde temos nomes e categorias para
tudo. E quero dizer tudo. Às vezes isso é redundante e inútil, mas às vezes há conceitos que são
muito bons de conhecer e diferenciar. Um exemplo disso é a diferença entre requisitos funcionais
(RF) e não funcionais (RNF). E como os requisitos do sistema de software são classificados (entre
outras coisas) dessa forma, as seguintes técnicas devem ser consideradas para a correta
identificação.

Requisitos funcionais

Requisitos funcionais são declarações dos serviços que o sistema irá fornecer, em como ele reagirá a
determinadas entradas. Quando falamos de entradas, não estamos necessariamente falando apenas
de entradas de usuários. Podem ser interações com outros sistemas, respostas automáticas,
processos predefinidos. Em alguns casos, os requisitos funcionais dos sistemas também declaram
explicitamente o que o sistema não deve fazer. É importante lembrar disso: um RF também pode ser
uma afirmação negativa. Desde que o resultado de seu comportamento seja uma resposta funcional
ao usuário ou a outro sistema, ele está correto. E, mais ainda, não só é correto, como é necessário
defini-lo. E isso nos leva ao próximo ponto.

Muitos dos problemas em engenharia de software (falando sobre o processo de desenvolvimento em

si) começam com especificações de requisitos imprecisas. É natural que um Analista de Negócios
(ou quem esteja definindo e documentando os requisitos do sistema) faça algumas suposições como
conhecimento universal, ou tome algum comportamento como garantido. Mas lembre-se, também é
natural que um desenvolvedor de sistemas interprete um requisito ambíguo da forma mais simples
possível, para simplificar sua implementação. Um exemplo claro desses problemas pode ser
encontrado nas funções comuns relacionadas à Experiência do Usuário:
 História do usuário: Como usuário, quero que o aplicativo seja fácil de usar, para que você não
precise gastar muito tempo aprendendo a usá-lo.
 O que significa ser "fácil de usar"?
 Fácil para quem?
 Como é medido?
 Como você rastreia isso?
 Como é testado? Com que critérios?
Isso não é algo contra desenvolvedores, mas sim contra o comportamento humano. Se você assume
algo, outros podem assumir algo diferente, e tudo bem. Mas o analista é responsável pela
documentação, então deve ser o próprio analista que tenta se certificar de que não há lacunas no
entendimento ou pontos cinzentos. É também por isso que as sessões de Pré-Planejamento e
Apresentação de Histórias são muito importantes para garantir que toda a equipe esteja na mesma
página em relação aos requisitos, seu objetivo de negócios e como implementá-los. Voltando ao
exemplo anterior, poderíamos dividir o requisito em vários novos, mais fáceis de entender,
desenvolver, testar, rastrear e entregar. Um deles poderia ser:
 História do usuário: Como usuário, quero que um tutorial seja exibido ao fazer login pela
primeira vez, para que você possa ver para que cada opção na tela inicial é usada.
 Você sabe o que mostrar, um tutorial.
 Você já sabe o que verificar, o que explica cada opção na tela inicial.
 Você sabe quando ele precisa ser exibido, no primeiro login do usuário (você pode explicar mais
tarde se o tutorial pode ser ignorado, mostrado em outros momentos, acessado de alguma seção
dentro do menu, etc.)
Voltando à RF, em princípio, a especificação dos requisitos funcionais de um sistema deve ser
completa e consistente. Completo significa que todos os serviços solicitados pelo usuário e/ou outro
sistema são definidos. Coerência significa que os requisitos não têm uma definição contraditória.
Requisitos não funcionais

São requisitos que não se referem diretamente às funções específicas fornecidas pelo sistema
(características do usuário), mas às propriedades do sistema: desempenho, segurança,
disponibilidade. Em palavras mais simples, eles não falam sobre "o que" o sistema faz, mas sobre
"como" ele faz isso. Alternativamente, Eles definem restrições do sistema, como a capacidade dos
dispositivos de entrada/saída e a representação dos dados usados na interface do sistema.
Os requisitos não funcionais originam-se da necessidade do usuário, devido a restrições
orçamentárias, políticas organizacionais, necessidade de interoperabilidade com outros sistemas de
software ou hardware, ou fatores externos como regulamentos de segurança, políticas de
privacidade, entre outros.

Existem diferentes tipos de requisitos e eles são classificados de acordo com suas implicações.
 Requisitos do produto. Eles especificam o comportamento do produto, como requisitos de
desempenho na velocidade de execução do sistema e na quantidade de memória necessária,
requisitos de confiabilidade que definem a taxa de falha do sistema como aceitável, requisitos de
portabilidade e requisitos de usabilidade.
 Requisitos organizacionais. São derivados das políticas e procedimentos existentes na
organização cliente e na organização do desenvolvedor: padrões nos processos a serem
utilizados; requisitos de implementação, tais como linguagens de programação ou o método de
concepção a utilizar; e requisitos de entrega que especificam quando o produto e sua
documentação serão entregues.
 Necessidades externas. Eles são derivados de fatores externos ao sistema e seu processo de
desenvolvimento. Eles incluem requisitos de interoperabilidade que definem como o sistema
interage com os outros sistemas da organização; os requisitos legais que devem ser seguidos
para garantir que o sistema funcione dentro da lei; e exigências éticas. Estes últimos são
impostos ao sistema para garantir que ele será aceito pelo usuário.

Às vezes, na prática, a especificação quantitativa de tais requisitos é difícil. Nem sempre é possível
para os clientes traduzir seus objetivos em requisitos quantitativos. Para alguns deles, como
manutenção, nenhuma métrica pode ser usada; O custo da verificação objetiva de requisitos
quantitativos não funcionais pode ser muito alto. E é por isso que também é muito importante ter
muito cuidado ao documentá-los. Um analista pode usar o suporte da equipe de desenvolvimento e
da equipe de teste para definir critérios mensuráveis, a fim de saber quando um requisito pode ser
marcado com sucesso como "Concluído".
Assim como falamos de requisitos funcionais, a generalização nunca é boa, mas neste caso é ainda
mais importante. Por que? Porque o resultado de um desenvolvimento de requisitos não funcionais
pode não ser explícito para o usuário final.
 Mau exemplo de RNF: O sistema deve ser seguro.
 Quão seguro é "seguro"?
 Em que situações?
 Existe uma norma a cumprir?
 Em quais seções?
 O que deve acontecer se o sistema não puder funcionar tão rápido quanto necessário?

Nesses casos, a implementação de um requisito não funcional mal definido pode ser problemática,
cara e demorada. Até porque, na maioria das vezes, uma RNF não é algo que a equipe trabalhe
isoladamente em um período fixo de tempo. O RNF pode ser abordado durante todo o projeto (e até
mesmo antes do início ou após a entrega, na fase de manutenção). Novamente, o exemplo acima
pode ser dividido em vários requisitos que são mais fáceis de rastrear e implementar.
 Bom exemplo de RNF: Todas as comunicações externas entre servidores de dados, o aplicativo e
o cliente do sistema devem ser criptografadas usando o algoritmo RSA.
 Você sabe que tipo de comunicações precisam ser criptografadas.
 Você sabe qual algoritmo usar e validar.

Os requisitos funcionais e não funcionais devem ser diferenciados no documento de requisitos, seja
um SRS, um portfólio de produtos ou qualquer artefato usado. Na prática, isso pode ser difícil. Se
um requisito não funcional é declarado separadamente dos requisitos funcionais, às vezes é difícil
ver a relação entre eles. Se os RNFs são declarados com requisitos funcionais, é difícil separar as
condições funcionais das não funcionais e identificar os requisitos que se relacionam com o sistema
como um todo. Deve ser encontrado um equilíbrio apropriado que dependa do tipo de sistema ou
aplicativo especificado. Por exemplo, se você estiver trabalhando com uma lista de pendências de
produtos, poderá ter histórias de usuário separadas para RNFs, mas adicionar um link para elas em
RFs que podem ser afetadas por elas. Esta é uma opção comum na maioria dos sistemas de
rastreamento de notas usados atualmente.

Em qualquer caso, tanto os FRs quanto os RNFs devem estar sempre documentados, mesmo que
seja difícil estabelecer a relação entre eles em artefatos. Isso ajudará a equipe a reduzir idas e vindas
de discussões, economizar tempo e, acima de tudo, problemas desnecessários com o cliente.

Requisitos funcionais: Exemplos

Os requisitos funcionais de um sistema são aqueles que descrevem qualquer atividade que ele
deve executar, em outras palavras, o comportamento ou função particular de um sistema ou
software quando determinadas condições são atendidas.

Normalmente, eles devem incluir funções executadas por telas específicas, descrições dos fluxos
de trabalho a serem executados pelo sistema e outros requisitos de negócios, conformidade,
segurança ou outros.
Neste artigo, apresentamos exemplos de requisitos funcionais, relacionados a funções de negócio,
dados que devem ser inseridos nas telas do sistema (interface gráfica), aqueles relacionados ao
controle de acesso ou emissão de relatórios exigidos por órgãos reguladores, entre outros.

PMOInformatica apresenta: 40 Exemplos de requisitos funcionais de um sistema.

Como os requisitos funcionais são descritos e classificados

Os requisitos funcionais de um software são geralmente registrados na matriz de rastreabilidade

de requisitos e na especificação de requisitos de software, esta última documentando as
operações e atividades que o sistema deve ser capaz de executar.
Os possíveis requisitos funcionais de um sistema incluem:
 Descrições dos dados a serem inseridos no sistema.
 Descrições das operações a serem realizadas por cada tela.
 Descrição dos fluxos de trabalho realizados pelo sistema.
 Descrição de relatórios do sistema e outras saídas.
 Definição de quem pode inserir dados no sistema.
 Como o sistema estará em conformidade com os regulamentos e regulamentos setoriais ou
gerais que lhe são aplicáveis.

Assim como outros tipos de requisitos de software, como os requisitos não funcionais, os
requisitos funcionais podem ser classificados de acordo com sua finalidade, como requisitos de
negócio, requisitos originados em aspectos regulatórios, segurança, entre outros.

Aqui estão os exemplos de requisitos funcionais, classificados por diferentes áreas:

Exemplos de requisitos de processos funcionais ou de áreas de negócio
 O sistema enviará um e-mail quando qualquer uma das seguintes transações for registrada:
ordem de venda do cliente, expedição de mercadoria para o cliente, emissão de nota fiscal para o
cliente e registro de pagamento do cliente.
 Será permitido o registro de pedidos de compra com dados obrigatórios incompletos, que
poderão ser concluídos posteriormente modificando o pedido. Antes que o pedido possa ser
aprovado, ele deve estar completo.
 Quando você aprovar um pedido, a solicitação passará para a próxima etapa no fluxo de
trabalho de aprovação configurado no sistema.
 O sistema permitirá que usuários autorizados insiram planos e cronogramas de projetos.
 O sistema permitirá que você aprove, altere ou atualize planos e cronogramas de projetos.
 O sistema permitirá o envio automatizado de cartas de entrega de pedidos diretamente
para o armazém.
 A cada pedido será atribuído um identificador único, que será usado para identificá-lo em
todos os processos subsequentes realizados nele.
 Ao inserir ordens de entrega, cada ordem de entrega será associada a uma ordem de
venda.
 O faturamento das ordens de venda será realizado em lotes, através de uma tela de
pedidos faturados pendentes, que mostrará os pedidos não faturados. Uma vez faturados, os
pedidos não serão exibidos nesta lista.
 O sistema também permitirá o registro de faturas manuais não associadas a pedidos, no
entanto, estas precisarão de autorização do grupo de Gerentes antes de serem lançadas.
 O processo de compra no sistema incluirá as seguintes etapas e transações: Entrada da
requisição, emissão da solicitação de cotação e emissão da ordem de compra.
 Os elementos do pedido de cotação serão os mesmos da requisição associada, bem como
os da ordem de compra. O sistema permitirá a emissão de solicitações de cotações e pedidos
parciais de compra.
 O lançamento de notas fiscais de venda e transações de faturas de compra podem ser
configuradas para serem realizadas automaticamente para o seu registro, ou manualmente em
lotes (Processo em lote).
 O software deve ser capaz de emitir as seguintes demonstrações financeiras: Balanço
Patrimonial, Demonstração de Lucros e Perdas, Demonstração de Fluxo de Caixa. Além disso,
você deve ser capaz de emitir uma lista de principais análises gerais e principais.
 As ordens de compra que excedem os valores definidos no fluxo de liberação de ordem
configurado devem passar pelas aprovações estabelecidas nesse fluxo de aprovação.

Exemplos de requisitos funcionais de interface gráfica

 A solução validará automaticamente o cliente associado a um pedido com o sistema de

gerenciamento de contatos.
 O campo de quantidade aceita apenas valores numéricos com duas casas decimais.
 O campo de data da transação aceita apenas datas anteriores a hoje (dia atual).
 O campo de nome aceita apenas caracteres alfabéticos.
 O campo de endereço aceita caracteres alfabéticos, numéricos e especiais.
 O campo país consistirá em uma lista de pré-selecionados. O país associado a um
endereço deve ser previamente registrado no sistema.
 O campo estado, província ou departamento consistirá em uma lista de selecionados. Os
usuários serão apresentados apenas com os estados associados ao país previamente
selecionado. O departamento ou província a ser selecionado deve ser registrado na
funcionalidade correspondente.
 O campo material do item da tela de requisições de compra será uma lista de pré-seleção,
mostrando apenas os materiais cadastrados no mestre de materiais.
 O campo data contábil aceita apenas datas que correspondem a períodos contábeis que
estão abertos no sistema.
 A tela de registro de pagamento pode imprimir os dados na tela para a impressora.
 O nome, o tamanho total, o espaço disponível e o formato de um pen drive ou pen drive
conectado à porta USB do computador serão exibidos.

Exemplos de requisitos funcionais legais ou regulamentares

 O sistema controlará o acesso e o permitirá apenas a usuários autorizados.

 O banco de dados será implementado com trilhas de auditoria.
 As planilhas protegerão os dados usando assinaturas eletrônicas.
 O sistema permitirá a elaboração e emissão do XX relatório regulatório, de acordo com os
requisitos estabelecidos na regulamentação e legislação aplicável.
 Os livros de compra e venda serão emitidos no formato estabelecido pelo fisco da matéria.

Exemplos de requisitos de segurança

O sistema controlará o acesso e o permitirá apenas a usuários autorizados. Os usuários devem

fazer login no sistema com um nome de usuário e senha.
 O sistema enviará um alerta ao administrador do sistema quando ocorrer algum dos
seguintes eventos: registro de nova conta, login no sistema pelo cliente, 2 ou mais tentativas
fracassadas de digitar a senha do usuário e alterar a senha do usuário.
 Os membros do grupo de usuários de analistas podem inserir solicitações, mas não podem
aprová-las ou excluí-las.
 Os membros do grupo de usuários do gerente podem inserir e aprovar solicitações, mas
não podem excluí-las.
 Os membros do grupo de usuários Administradores não podem inserir ou aprovar
solicitações, mas podem excluí-las.
 Qualquer troca de dados via internet realizada pelo software será realizada através do
protocolo criptografado https.

Exemplos de requisitos de interface externa (Hardware e Software)

 O software pode ser usado em sistemas operacionais Windows, Linux e OSX.
 O aplicativo deve ser utilizável sem a necessidade de instalar qualquer software adicional,
além de um navegador da Web.
 O aplicativo deve ser utilizável com os navegadores Chrome, Firefox e Internet Explorer.
Sobre os requisitos funcionais

Os requisitos funcionais devem ser escritos de tal forma que o leitor possa compreender o
funcionamento do sistema sem ter um conhecimento técnico particular do seu funcionamento.
O importante é definir uma forma padrão de expressar os requisitos e ser coerente com isso em
todos os documentos.
Da mesma forma, os requisitos funcionais não precisam necessariamente ser definidos na forma
de narrativas escritas, mas diagramas ou fluxos de processo também podem ser usados, que são
incluídos na especificação funcional do software ou sistema a ser desenvolvido.
Para identificar e documentar os requisitos funcionais do software, são seguidas duas etapas,
primeiramente são aplicadas técnicas de levantamento de requisitos, como observação,
entrevistas, observação, entre outras.

O resultado da pesquisa de requisitos está documentado no documento de requisitos de software.

Compartilhamos um modelo abaixo:
> Documento de requisitos de software

Após o levantamento, são aplicadas técnicas de análise de requisitos para revisar as

informações obtidas no levantamento e desenvolver a especificação funcional, algumas dessas
técnicas são decomposição funcional, modelagem de processos, casos de uso e outras.
Referências

Eriksson, U.; Requisitos funcionais vs não funcionais. Publicado em ReqTest.

Eriksson, U.; A diferença entre requisitos funcionais e não funcionais. . Publicado em

ReqTest.

Sistemas Ofni. Requisitos funcionais

ReqView. Exemplos de documentação

Requisitos não funcionais: Exemplos

Apresentamos a terceira parte da série sobre requisitos não funcionais, com alguns exemplos que
podem servir de guia na sua definição.
Os requisitos não funcionais representam características gerais e restrições do aplicativo ou
sistema que está sendo desenvolvido.

Geralmente apresentam dificuldades em sua definição, uma vez que sua conformidade ou não
conformidade pode ser objeto de livre interpretação, por isso é aconselhável acompanhar sua
definição com critérios de aceitação que possam ser mensurados.

Dentre os exemplos de requisitos não funcionais apresentados, temos aqueles referentes a

atributos como eficiência, segurança, confiabilidade e usabilidade do sistema. Também
apresentamos exemplos de requisitos organizacionais e externos não funcionais.

O que são requisitos não funcionais e como são classificados?

Se você está procurando mais informações sobre o conceito de requisitos não funcionais,
recomendamos a primeira parte desta série Requisitos não funcionais: Por serem importantes

Em um primeiro nível, os requisitos não funcionais podem ser classificados em requisitos de

produto, organizacionais e externos, como mostramos no artigo sobre classificação de
requisitos não funcionais.

Em um segundo nível, os requisitos do produto podem ser classificados em requisitos de

usabilidade, eficiência, confiabilidade e segurança. Por sua vez, os requisitos organizacionais
podem ser classificados em requisitos de ambiente, organizacionais e de desenvolvimento. Da
mesma forma, os requisitos externos podem ser classificados em requisitos regulatórios, éticos e
legislativos.

Ao executar as fases de levantamento e análise de requisitos, os requisitos não funcionais podem

ser registrados em um documento de requisitos de software. Aqui compartilhamos um modelo:

Alguns exemplos de requisitos não funcionais

Como mostramos no artigo sobre classificação de requisitos não funcionais, em um primeiro

nível estes podem ser classificados em requisitos de produto, organizacionais e externos.

Em um segundo nível, os requisitos do produto podem ser classificados em requisitos de

usabilidade, eficiência, confiabilidade e segurança. Por sua vez, os requisitos organizacionais
podem ser classificados em requisitos de ambiente, organizacionais e de desenvolvimento. Da
mesma forma, os requisitos externos podem ser classificados em requisitos regulatórios, éticos e
legislativos.

Abaixo estão exemplos de requisitos não funcionais, classificados por essas diferentes áreas.

Exemplos de requisitos de produtos não funcionais

Eficiência

 O sistema deve ser capaz de processar N transações por segundo. Isso será medido por
meio da ferramenta SoapUI aplicada ao Software de Teste de Web Services.
 Todas as funcionalidades do sistema e transações comerciais devem responder ao usuário
em menos de 5 segundos.
 O sistema deve ser capaz de operar corretamente com até 100.000 usuários com sessões
simultâneas.
 Os dados modificados no banco de dados devem ser atualizados para todos os usuários
que o acessam em menos de 2 segundos.

Segurança lógica e de dados

As permissões de acesso ao sistema só podem ser alteradas pelo administrador de acesso a

dados.
 O novo sistema deve ser desenvolvido aplicando padrões de programação e
recomendações que aumentem a segurança dos dados.
 O backup de todos os sistemas deve ser feito a cada 24 horas. Os backups devem ser
armazenados em um local seguro localizado em um prédio diferente daquele onde o sistema
reside.
 Todas as comunicações externas entre servidores de dados, aplicativo e cliente do sistema
devem ser criptografadas usando o algoritmo RSA.
 Se forem identificados ataques de segurança ou violações do sistema, o sistema não
continuará a operar até ser desbloqueado por um administrador de segurança.

Segurança industrial

 O sistema não continuará a funcionar se a temperatura externa for inferior a 4 graus

Celsius.
 O sistema não continuará operando em caso de incêndio. (Ex. Um elevador).

Usabilidade

 O tempo de aprendizado do sistema por um usuário deve ser inferior a 4 horas.

 A taxa de erros cometidos pelo usuário deve ser inferior a 1% do total de transações
executadas no sistema.
 O sistema deve ter manuais de usuário devidamente estruturados.
 O sistema deve fornecer mensagens de erro que sejam informativas e orientadas para o
usuário final.
 O sistema deve ter um módulo de ajuda on-line.
 O aplicativo web deve ter um design "Responsivo", a fim de garantir a visualização
adequada em vários computadores pessoais, tablets e smartphones.
 O sistema deve ter interfaces gráficas bem formadas.
Confiabilidade

 O sistema deve ter uma disponibilidade de 99,99% das vezes que um usuário tenta acessá-
lo.
 O tempo para iniciar ou reiniciar o sistema não pode exceder 5 minutos.
 A taxa de tempos de falha do sistema não pode exceder 0,5% do tempo total de operação.
 A duração média das falhas não pode exceder 15 minutos.
 A probabilidade de falha do sistema não pode ser superior a 0,05.

Outros exemplos de requisitos do produto

 O sistema será desenvolvido para as plataformas PC e Macintosh.

 O aplicativo deve ser compatível com todas as versões do Windows, começando com o
Windows 95.
 O aplicativo deve consumir menos de 500 Mb de RAM.
 O aplicativo não pode ocupar mais de 2 GB de espaço em disco.
 O novo aplicativo deve lidar com fontes do alfabeto em inglês, idiomas latinos (espanhol,
francês, português, italiano), árabe e chinês.
 A interface do usuário será implementada para navegadores da Web apenas com HTML5 e
JavaScript.

Exemplos de requisitos organizacionais não funcionais

 O procedimento de desenvolvimento de software a ser utilizado deve ser explicitamente

definido (em manuais de procedimentos) e deve estar em conformidade com as normas ISO 9000.
 A metodologia de desenvolvimento de software será Behaviour Driven Development
(BDD) suportada pela Cucumber.
 O sistema deve ser desenvolvido utilizando as ferramentas CASE XYZ.
 O processo de desenvolvimento será gerenciado por meio de uma determinada ferramenta
web para gerenciar o processo de desenvolvimento de software.
 Um plano de recuperação de desastres deve ser especificado para que o sistema seja
desenvolvido.
 Relatórios gerenciais devem ser produzidos quinzenalmente mostrando o esforço investido
em cada um dos componentes do novo sistema.
 O teste de software será gerenciado com uma ferramenta de gerenciamento de teste de
software.
 Os testes de software serão executados usando Selenium e Ruby como ferramenta e
linguagem de script para automação de testes de software.

Exemplos de requisitos externos não funcionais

 Sistemas de Dados Médicos: O novo sistema e seus procedimentos de manutenção de

dados devem estar em conformidade com as leis e regulamentos de proteção de dados médicos.
 O novo sistema estará sujeito às regras de licenças públicas gerais (GNU), ou seja, será
livre, de código aberto, no qual qualquer pessoa pode alterar o software, sem patentes e sem
garantias.
 As páginas web a desenvolver devem cumprir a lei sobre a igualdade de tratamento para as
pessoas com deficiência.
 O sistema não deve divulgar aos seus operadores quaisquer dados pessoais dos clientes
para além de nomes e números de referência.

Requisitos não funcionais e requisitos funcionais

Os requisitos não funcionais são geralmente expressos de forma geral e sem referência a
qualquer módulo, transação ou característica do sistema, caso contrário se tornariam requisitos
funcionais.

Por exemplo:

O sistema deve garantir que os dados estejam protegidos contra acesso não autorizado

É aconselhável acompanhar as definições de requisitos não funcionais com critérios de aceitação

que possam ser medidos.

Os requisitos não funcionais podem, por sua vez, levar a requisitos funcionais, tomando como
exemplo o anterior:

O sistema incluirá um procedimento de autorização de usuário, no qual os usuários devem se

identificar usando um nome de usuário e senha. Somente usuários autorizados dessa forma
poderão acessar os dados do sistema.

Escrito dessa forma, o requisito se torna funcional.

No entanto, nem todos os requisitos não funcionais podem ser derivados em requisitos funcionais,
por isso é muito importante definir critérios de aceitação.

Exemplos de como definir requisitos funcionais

> Requisitos funcionais de um sistema de vendas

> Exemplos de requisitos funcionais

10 tipos de testes não funcionais
O teste não funcional se concentra em validar um sistema ou aplicativo por meio de seus
requisitos não funcionais, ou seja, a maneira como o sistema funciona e não por meio de
comportamentos específicos.

As características não funcionais de um sistema ou aplicativo são frequentemente quantificadas

em escalas variadas, como tempos de resposta em testes de desempenho.
O ISTQB afirma que a omissão de testes não funcionais pode levar a problemas de qualidade
potencialmente catastróficos após a produção de produção, no entanto, esses tipos de testes são
caros, portanto, os riscos devem ser avaliados antes de comprometer os recursos do projeto.

Neste artigo, apresentamos 10 tipos de testes não funcionais, especificamente testes de

usabilidade, segurança, carga, estresse, volume, configuração, desempenho, escalabilidade,
recuperação e manutenção.

10 tipos de testes não funcionais

Aqui está uma lista não limitadora de 10 tipos de testes não funcionais que você pode incluir em
seu plano de teste de software.

1. - Teste de carga

O teste de carga consiste em simular a demanda em um aplicativo de software e medir o

resultado. Esses testes são realizados sob demanda e também sob condições de sobrecarga
(picos de demanda).

Para executar esses testes, é necessário usar ferramentas de teste que simulam a carga, como
SoapUI.

O teste de carga ajuda a identificar a capacidade operacional máxima de um aplicativo, bem como
a identificar gargalos e causas de potencial degradação do desempenho.

Quando a carga de teste se eleva acima dos parâmetros esperados, esses testes são conhecidos
como testes de estresse.

2. - Testes de estresse

São testes de carga que são realizados com demandas superiores à capacidade operacional,
muitas vezes até atingir o ponto de ruptura.

Esse tipo de teste de software é utilizado para determinar a estabilidade de um sistema ou

aplicação, com especial atenção à disponibilidade e ao tratamento de erros diante da sobrecarga.

Quanto ao teste de carga, ferramentas que simulam a demanda são necessárias, o SoapUI é uma
dessas ferramentas que permite simular solicitações para servidores de aplicativos Web.

Aqui compartilhamos um tutorial SopaUI.

Com o teste de estresse é possível identificar pontos de interrupção, limites para o uso seguro da
aplicação, confirmar especificações de projeto, identificar as formas de falha do sistema, entre
outros aspectos.
3. - Testes de volume

O teste de volume consiste em validar a operação do aplicativo com determinados volumes de

dados.

Por exemplo, se você quiser ver o comportamento de um aplicativo com um tamanho de banco de
dados específico, expanda o tamanho do banco de dados para esses parâmetros e, em seguida,
execute consultas, processos ou funcionalidade do aplicativo, medindo seu desempenho.

O assunto de teste não está limitado a bancos de dados, ele também pode ser usado, por
exemplo, para medir o desempenho de uma interface quando o arquivo de interface (um arquivo
de texto, xml, etc.) excede um determinado tamanho.

O objetivo é verificar se determinados volumes de dados o aplicativo funciona normalmente, quais

são os limites máximos de volumes de dados para a operação e identificar condições de falha.

4. - Testes de configuração

Em vez de testar o desempenho de um aplicativo de uma perspectiva de carga, os testes de

configuração são usados para validar os efeitos de desempenho de determinadas alterações de
configuração.

Um exemplo típico dessa situação é experimentar diferentes métodos de balanceamento de carga

e ver a resposta do aplicativo a níveis semelhantes de sobrecarga.

Outro exemplo é verificar se o sistema é capaz de funcionar corretamente em diferentes versões

ou configurações de ambientes de hardware e software, como diversos navegadores de internet,
versões de navegadores, entre outros.

5. - Testes de usabilidade

Nos testes de usabilidade, os testadores de software se concentram em validar a facilidade de

uso de um aplicativo.

Os recursos avaliados em usabilidade incluem:

Facilidade de aprendizado: Como é fácil para os usuários executar funções básicas na primeira
vez que usam o aplicativo.
 Eficiência: A rapidez com que os usuários experientes podem executar suas tarefas.
 Memorização: Como é fácil memorizar o uso do aplicativo, ou seja, quando um usuário
passa muito tempo sem usar o aplicativo, ele pode se lembrar o suficiente para usá-lo
efetivamente da próxima vez, ou ele tem que começar a aprender novamente.
 Erros: Quantos erros atribuíveis ao design que o usuário faz, quão graves eles são e quão
fácil é se recuperar deles.
 Satisfação: O quanto o usuário gosta (ou não gosta) de usar o sistema.

6. - Testes de segurança

Consiste em testar os atributos ou características de segurança do sistema, se é um sistema

seguro ou não, se pode ser violado, se há controle de acesso através de contas de usuário, se
esses acessos podem ser violados.

Os testes de segurança também servem para validar se a equipe de desenvolvimento de software

seguiu as melhores práticas de segurança em sua programação.

Entre os recursos de segurança de um sistema estão confidencialidade, integridade, autenticação,

autorização e disponibilidade.

7. - Testes de estresse

O teste de resistência envolve submeter um sistema ou aplicação a uma determinada carga

durante um período de tempo, para determinar como ele se comporta após o uso prolongado.

Um sistema de computador pode se comportar normalmente durante as primeiras horas, no

entanto, após um certo tempo, problemas como vazamentos de memória geralmente causam
falhas.

Essas falhas no desenvolvimento de software não podem ser identificadas sob testes funcionais
normais, por isso é desejável envolver testes de estresse entre os tipos de teste de software.

8. - Testes de escalabilidade

O teste de escalabilidade consiste em verificar a capacidade de um aplicativo de escalar qualquer

uma de suas características não funcionais, como a carga que suporta, número de transações,
volumes de dados, entre outros.

Ao projetar casos de teste de escalabilidade, é aconselhável considerá-los em blocos

incrementais, dada a dificuldade de prever a carga real que um aplicativo terá depois de
implantado na produção.
Testar em blocos incrementais significa, por exemplo, primeiro testar com baixos níveis de
demanda, depois aumentar para níveis médios de demanda e, finalmente, testar com altos níveis
de carga. Desta forma, pode-se determinar que ele também dimensiona a aplicação e os
problemas que começam a surgir em diferentes níveis.

Para que os resultados sejam confiáveis, os ambientes de teste e sua configuração devem ser
mantidos constantes.

9. - Testes de recuperação
Os testes de recuperação são realizados para verificar a rapidez e o quão bem um aplicativo se
recupera após ocorrer uma falha de hardware ou software.

Portanto, para executar testes de recuperação requer forçar a falha e, em seguida, verificar se a
recuperação ocorre corretamente.

Por exemplo, quando um aplicativo estiver funcionando, desconecte o cabo de rede ou em um

aplicativo móvel, interrompa a conexão com a rede Wi-Fi ou com a operadora e restaure a
conexão.

10. - Testes de manutenibilidade

Basicamente, eles consistem em avaliar o quão fácil é manter um sistema ou aplicativo. Isso
significa como é fácil analisar, alterar e testar essas alterações.

Para realizar este teste, a forma como a aplicação é implementada deve ser avaliada, seguindo
boas práticas de engenharia de software. Ou seja, que os padrões recomendados de engenharia
de software estão sendo seguidos e que anti-padrões não estão sendo introduzidos
inadvertidamente, ou seja, que erros comuns de programação não estão sendo cometidos.
Somerville divide os requisitos não funcionais em três grandes tipos: requisitos do produto,
requisitos organizacionais e requisitos externos.

Requisitos do produto não funcional

Geralmente refere-se a limites ou restrições sobre o comportamento do sistema, por isso

estabelece limites e restrições sobre o que designers (arquitetos de software) e engenheiros de
software podem fazer.

Alguns desses requisitos podem ser fáceis de quantificar, como desempenho e confiabilidade,
mas outros são mais difíceis, como usabilidade e adaptabilidade.

Os requisitos do produto podem ser classificados em (Sommerville):

 Requisitos de usabilidade: A usabilidade é definida como o esforço que um usuário

precisa fazer para aprender, usar, inserir dados e interpretar os resultados obtidos de um software
aplicativo. Nos últimos tempos, a usabilidade tornou-se muito importante, principalmente diante da
demanda por desenvolvimento de software para celulares e tablets.

 Requisitos de eficiência: Relacionado ao desempenho em termos de tempo de resposta,

número de operações por segundo, entre outras medições, bem como consumo de memória,
processador, espaço em disco ou recursos de rede.

Uma ferramenta útil para verificar a eficiência de um sistema é o SoapUI, que permite testes de
carga ou estresse em webservices. Aqui compartilhamos artigos sobre o assunto:

 Requisitos de confiabilidade: engloba vários atributos

o Disponibilidade: Prontidão do sistema para prestar serviço corretamente.
o Confiabilidade: Continuidade do serviço prestado pelo sistema.
o Segurança industrial: ausência de consequências catastróficas para o usuário ou
para o meio ambiente.
o Integridade: Ausência de alterações inadequadas no sistema.
o Manutenabilidade: Possibilidade de fazer modificações ou reparos em um processo
sem afetar a continuidade do serviço.

 Requisitos de segurança: Capacidades funcionais ou não funcionais que um sistema

deve ter para atender atributos na área de segurança da tecnologia da informação, segurança de
dados, segurança lógica, controle de acesso à informação (restrições de acesso), autenticidade da
informação, privacidade, entre outros aspectos.

Considerar os requisitos do produto é vital para alcançar a integração contínua de aplicativos e o

desenvolvimento de mudanças rápidas, mas sustentáveis ao longo do tempo.

Esse novo paradigma é necessário para implementar novas tecnologias de informação e

aplicações de software como mobilidade, internet das coisas, análise avançada de dados (Big
Data), evolução de sistemas para a nuvem e tecnologia da informação escalável.
Requisitos organizacionais não funcionais

Eles são derivados das políticas e procedimentos da organização, como padrões de processo ou
requisitos de implementação.

Podem incluir metodologias de desenvolvimento de software, padrões de programação

(codificação) e ferramentas de apoio ao desenvolvimento de software (por exemplo, ferramentas
CASE) que devem ser utilizadas (seguindo as políticas da organização), bem como relatórios para
a gerência que devem ser fornecidos, entre outros.

As ferramentas de gestão do desenvolvimento de software que conhecemos são definidas

como requisitos organizacionais não funcionais.
Os requisitos organizacionais podem ser classificados em (Sommerville):

 Requisitos ambientais: Eles descrevem o ambiente operacional no qual o sistema deve

operar.
 Requisitos operacionais: Procedimentos operacionais que descrevem como o sistema
será utilizado dentro do contexto da organização.
 Requisitos de desenvolvimento: Linguagem de programação a ser utilizada, padrões de
codificação, padrões (e antipadrões) de design e programação, ferramentas para gerenciar o
desenvolvimento de software, ambiente de desenvolvimento de software (ambiente de
desenvolvimento), ambiente de teste de software (ambiente de teste), entre outros aspectos.

Um dos aspectos que são documentados como requisitos funcionais organizacionais é o

ambiente, especificamente os procedimentos de manutenção e gerenciamento do ambiente
de desenvolvimento de software.

Essa administração também inclui procedimentos para gerenciar ambientes de teste de ponta
a ponta.

Requisitos externos não funcionais

Estes derivam do ambiente organizacional (não ambiente técnico) em que o sistema é

desenvolvido e podem ser feitos tanto sobre o produto (o software desenvolvido) ou também sobre
o processo de desenvolvimento de software.

Esses tipos de requisitos incluem limitações de natureza econômica, interação ou necessidade do

sistema de interoperar com outros sistemas, requisitos regulatórios na área de saúde, segurança
industrial ou proteção de dados, requisitos legais relativos a licenças, regulamentos ou
certificações que o produto precisa de acordo com a indústria em que opera, entre outros.

Somerville, por sua vez, classifica esses requisitos em:

Requisitos regulamentares: Leis e regulamentos que estabelecem o que o sistema deve fazer e
como deve cumpri-los. O foco de um sistema ou nova funcionalidade pode ser exclusivamente
cumprir um regulamento.
 Requisitos éticos: Requisitos que garantem que o sistema será aceitável para o usuário, o
público em geral e se adapta aos costumes da sociedade em que opera ou à qual presta serviços.
 Requisitos legislativos: Características que o sistema deve atender para cumprir a lei, por
exemplo, na área contábil (normas contábeis e normas financeiras), requisitos de segurança
industrial (para sistemas críticos), entre outros aspectos.

Importância da classificação dos requisitos não funcionais

A especificação incompleta ou imprecisa de requisitos não funcionais pode fazer com que seu
projeto de engenharia de software falhe.
Na verdade, não gerenciar requisitos não funcionais é um dos erros clássicos na gestão de
desenvolvimento de software definido por Steve McConnell.

Classificar corretamente cada requisito não funcional identificado é muito importante para garantir
esse processo.

https://www.youtube.com/user/codigofacilito
https://www.youtube.com/channel/UC4CEqh4d3-6RcyyJxhFCMGg
https://marvelapp.com/.