ANÁLISE E

PROJETO DE
SISTEMAS

Cleverson Ledur
 Revisão técnica:
Jeferson Faleiro Leon
Desenvolvedor de Sistemas
Especialista em Formação Pedagógica de Professores
Professor de curso Técnico em informática

L475a Ledur, Cleverson Lopes

Análise e projeto de sistemas [recurso eletrônico] /
Cleverson Lopes Ledur ; [revisão técnica: Jeferson Faleiro
Leon]. – Porto Alegre : SAGAH, 2017.

ISBN 978-85-9502-179-2

1. Computação. 2. Projeto de sistemas. 3. Análise de

projeto. I. Título.

CDU 004.41

Catalogação na publicação: Ana Paula M. Magnus – CRB 10/2052

Identificar requisitos
não funcionais
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:

„„ Descrever o que são requisitos não funcionais e suas características. 

„„ Identificar quais são os requisitos não funcionais da solução que
compõem o escopo. 
„„ Organizar a documentação de requisitos não funcionais.

Introdução
Requisitos não funcionais são as características e aspectos internos do
sistema, que envolvem, especificamente, a parte técnica. Ao contrário dos
requisitos funcionais, esses requisitos não são explicitamente expostos
pelo cliente, mas devem ser subentendidos pelo desenvolvedor. Nesse
tipo de requisito, consegue-se garantir que um sistema realize as ações
explícitas nos requisitos funcionais da melhor forma possível, evitando
possíveis problemas, como por exemplo, baixo desempenho, defeitos
e erros.
Neste texto, você vai estudar sobre os requisitos não funcionais, a partir
de conceitos e exemplos básicos. Além disso, você verá como identificar
e documentar os requisitos não funcionais.

Requisitos não funcionais

Na engenharia de sistemas e de requisitos, um requisito não funcional (NFR)
é um requisito que especifica critérios que podem ser usados ​​para julgar o
funcionamento de um sistema e não comportamentos específicos. Eles são
contrastados com os requisitos funcionais, que definem comportamentos ou
funções específicas. O plano para implementar requisitos funcionais é detalhado
no design do sistema. Assim, esse plano para a implementação de requisitos
2 Identificar requisitos não funcionais

não funcionais é detalhado na arquitetura do sistema, porque eles, geralmente,

são requisitos significativos de forma arquitetônica (CHUNG, 2012).
Em geral, os requisitos funcionais definem o que um sistema deve fazer e
os requisitos não funcionais definem como um sistema deve ser. Os requisitos
funcionais, geralmente, são na forma de (o sistema deve fazer <requisito>)
uma ação individual de parte do sistema, talvez, explicitamente, no sentido de
uma função matemática, uma descrição de caixa preta, uma saída, um processo
ou um modelo funcional de controle ou modelo IPO. Em contrapartida, os
requisitos não funcionais estão na forma de (o sistema deve ser <requisito>)
uma propriedade geral do sistema, como um todo ou de um aspecto particular
e não uma função específica. As propriedades gerais do sistema normalmente
marcam a diferença entre se o projeto de desenvolvimento conseguiu ou se
falhou.
Os requisitos não funcionais são chamados de atributos de qualidade de um
sistema. Outros termos para requisitos não funcionais são qualidades, objetivos
de qualidade, requisitos da qualidade de serviço, restrições e requisitos não
comportamentais. Informalmente, podem, também, serem chamados de qua-
lidades, de atributos, como estabilidade e portabilidade. As qualidades – que
são os requisitos não funcionais – podem ser divididas em duas categorias
principais (CHUNG, 2012):

„„ Qualidades de execução: como segurança e usabilidade, que são ob-

serváveis ​​durante a operação (em tempo de execução).
„„ Qualidades de evolução: como testabilidade, capacidade de manuten-
ção, extensibilidade e escalabilidade, incorporadas à estrutura estática
do sistema.

Exemplos de requisitos por domínio

Pode-se classificar os domínios dos requisitos não funcionais em precisão,
adaptabilidade, estética, configuração, consistência, documentação, extensibili-
dade, frequência, fatores humanos, instabilidade, localizabilidade, manutenção,
portabilidade, previsibilidade, recuperabilidade, confiabilidade, consumo de
recursos, tempo de resposta, e reutilização (GLINZ, 2007). Você vai, a seguir,
ver alguns exemplos de sistemas diversos de requisitos não funcionais divididos
pelas suas características de qualidade.
 Identificar requisitos não funcionais 3

Precisão

„„ Cada chamada telefônica, iniciada pelo discador automático, deve ter

todos os dígitos exatamente corretos, incluindo o código de área.
„„ As notas calculadas devem ser precisas para 1%.
„„ O sistema notificará o administrador do sistema, caso a fonte de dados
de entrada estiver corrompida.
„„ Todo vídeo deve ter uma identificação única.

Adaptabilidade

„„ O software acabado deve suportar novos tipos de funcionários sem

precisar ser reescrito ou recompilado.
„„ O software deve ser flexível.
„„ O software deve ser adaptável.

Estética

„„ Todo o texto deve ser rosa.

„„ O usuário deve estar satisfeito com a aparência da GUI.
„„ Compatibilidade.
„„ Todos os programas do cliente web devem interagir com o servidor
sem alterações no código do servidor.

Configuração

„„ O sistema deve usar um arquivo java .properties que contém pares de

valores chave que definem o driver jdbc para usar.
„„ O sistema deve se adaptar às mudanças em qualquer formato de registro
de entrada, sem a necessidade de recompilar qualquer código.

Consistência

„„ É necessária uma GUI consistente.

4 Identificar requisitos não funcionais

Documentação

„„ Toda a documentação do sistema deve ser incorporada ao código-fonte.

„„ O código-fonte deve ser autodocumentado, colocando-se a descrição
do design em um cabeçalho de método legível: Javadoc.

Extensibilidade

„„ Se o formato de dados de entrada muda, o desenvolvedor poderá fazer

as mudanças necessárias.
„„ Um novo formato de arquivo pode ser adicionado ao sistema sem alterar
nenhum arquivo .class existente.

Frequência/gravidade da falha

„„ O sistema falhará mais de uma vez para cada 10.000 transações.

„„ Não pode haver exceções não tratadas de entrada de usuário incorreta.

Fatores humanos

„„ A IU deve ser fácil de usar.

„„ A interface do usuário deve ser intuitiva.
„„ Todos os menus devem ter um formato consistente.

Instabilidade

„„ Deve ser possível criar e preencher o banco de dados a partir de um

arquivo de script.
„„ Um usuário pode instalar e operar o programa sem qualquer tipo de
assistência.
„„ Deve haver um programa de instalação.
„„ O processo de instalação será mantido no mínimo.
 Identificar requisitos não funcionais 5

Localizabilidade

„„ Deve ser possível operar o sistema em qualquer idioma.

„„ Todos os componentes da interface do usuário devem suportar a loca-
lidade do sistema.
„„ Se uma localidade não estiver disponível, o US English deve ser usado.
„„ A linguagem UI pode ser trocada de inglês para alemão, sem recompilar
nem reconstruir o programa.
„„ O produto pode alternar entre unidades inglesas e métricas, sem re-
compilar nem reconstruir o programa.

Manutenção

„„ Um desenvolvedor de software com seis meses de experiência poderá

corrigir qualquer defeito conhecido.
„„ O grupo de manutenção deve ser capaz de manter o software.
„„ Tempo médio de mudança para defeitos deve ser menor que dois dias.

Portabilidade

„„ O sistema será executado, sem modificação, em qualquer plataforma

de destino Java.
„„ O sistema não é portátil.
„„ Qualquer navegador da web habilitado para Java deve poder acessar
os dados do sistema.

Previsibilidade

„„ O sistema nunca pode falhar.

„„ O sistema deve produzir resultados previsíveis.

Recuperabilidade

„„ Durante um reinício do sistema, ele retornará a um estado de

funcionamento.
6 Identificar requisitos não funcionais

Confiabilidade

„„ O sistema estará disponível 100% do tempo.

„„ O sistema nunca deve falhar.

Consumo de recursos

„„ O sistema deve consumir um máximo de 1 GB de memória.

„„ O sistema não usará mais de 25% dos recursos do sistema.

Tempo de resposta

„„ O tempo de resposta da consulta deve ser rápido.

„„ Todas as consultas devem retornar uma resposta em período inferior
a 2 segundos.

Reutilização

„„ Todas as transações devem ser criptografadas.

„„ Somente o professor pode modificar notas.

Identificação dos requisitos não funcionais

A identificação de requisitos não funcionais é uma etapa bastante complexa
da modelagem de um sistema, já que muitas vezes é necessário conhecer
as tecnologias envolvidas na resolução dos problemas. Enquanto requisitos
funcionais apresentam o que o sistema fará, os requisitos não funcionais
apresentam como este sistema irá atender aos requisitos funcionais. Logo, se
deve fazer a ligação entre os requisitos funcionais e as possíveis soluções que
permitem o atendimento deles (CHUNG; LEITE, 2009).
É possível imaginar a criação de um jogo de corrida para computador.
Após o levantamento dos requisitos funcionais (por exemplo, o jogo deve
permitir ao jogador controlar o automóvel e o jogo ser multiplayer), deve-se
fazer o levantamento dos requisitos não funcionais. Para isso, é necessário
perguntar: o que o sistema precisa ter para permitir os requisitos funcionais?
 Identificar requisitos não funcionais 7

Você verá abaixo uma lista de possíveis requisitos não funcionais para o
exemplo do jogo de corrida:

„„ Pode ser executado em qualquer sistema operacional.

„„ Precisa do último JRE (Java Runtime) instalado para executar o projeto.
„„ A senha deve ser criptografada por segurança.
„„ O software deve ser executado em qualquer navegador.
„„ O site deve ser acessado a partir de qualquer local com acesso à internet.
„„ Precisa executar no site para acesso universal.
„„ O software deve ser confiável e não falhar.
„„ Deve estar livre de defeitos.
„„ Precisa falhar menos de uma vez por semana.
„„ O usuário tem uma senha para que nenhum outro usuário possa mexer
no seu jogo.
„„ Precisa usar requisitos mínimos de sistema/hardware.
„„ O software deve ser intuitivo ou facilmente compreendido depois de
se ler as regras.
„„ Precisa de um layout confortável que acolha novatos e veteranos.
„„ O layout deve ser autoexplicativo, suficiente para que qualquer usuário
não precise acessar ao manual três vezes para entender as funções do
produto.

Após olhar esses requisitos, se pode constatar que eles estão mais próximos
das tecnologias que serão utilizadas do que de aspectos característicos do pro-
duto final e serviços. Portanto, elenca-se as seguintes etapas da identificação
de requisitos não funcionais:

1. A partir dos requisitos funcionais, fazer o questionamento: o que o

sistema deve ter para satisfazer este requisito?
2. Validar requisito não funcional.
3. Documentar.
8 Identificar requisitos não funcionais

Especificação e documentação
Assim como na especificação de requisitos funcionais, os requisitos não
funcionais são descritos no documento de Especificação de Requisitos de Sof-
tware (SRS). Nele, há uma seção especial para esses requisitos não funcionais.
De forma geral, eles são descritos com o uso de uma escrita contínua ou de
tabelas (EELES, 2005). Veja no Quadro 1, um exemplo de uma especificação
de requisitos.

Quadro 1.

Identificador RNF001 Categoria Desempenho

Nome O jogo deve iniciar em menos de 10 segundos, mesmo em

computadores com configurações de hardware fracas.

Data de criação 01/01/2017 Autor João da Silva

Data da última N/A Autor N/A

alteração

Versão 1 Prioridade Essencial

Descrição O jogo deve iniciar em até 10 segundos após o usuário

clicar no botão “play” da tela inicial, mesmo se a
configuração de hardware for inferior. O usuário não
poderá ficar esperando mais do que 10 segundos, deve
ser apresentada alguma animação ou jogo com uma
jogabilidade inicial (mesmo que sendo limitada).

Nesta especificação, tem, basicamente, o identificador do requisito não

funcional, iniciado por RNF e uma numeração. A seguir, informa-se uma
categoria do requisito. Além disso, há o nome e a descrição que informam os
detalhes do requisito não funcional. Também, se tem informações adicionais,
como a data de criação, a última alteração, o autor, a versão e as prioridades.
 Identificar requisitos não funcionais 9

CHUNG, L. et al. Non-functional requirements in software engineering. New York: Sprin-

ger Science & Business Media, 2012. (International Series in Software Engineering, 5).
CHUNG, L.; LEITE, J. C. S. P. On non-functional requirements in software engineering.
In: BORGIDA, A. T. et al. (Ed.). Conceptual modeling: foundations and applications. Berlin:
Springer-Verlag, 2009. p. 363-379.
EELES, P. Non-functional requirements. New York: IBM Software Group, 2005.
GLINZ, M. On non-functional requirements. In: IEEE INTERNATIONAL REQUIREMENTS
ENGINEERING CONFERENCE RE’07. 15., New Delhi, 2007.Proceedings…Los Alamitos:
IEEE Computer Society, 2007.

Leitura recomendada
SLACK, N.; CHAMBERS, S.; JOHNSTON, R.; BETTS, A. Gerenciamento de operações e de pro-
cessos: princípios e práticas de impacto estratégico. 2. ed. Porto Alegre: Bookman, 2013.
 Encerra aqui o trecho do livro disponibilizado para
esta Unidade de Aprendizagem. Na Biblioteca Virtual
da Instituição, você encontra a obra na íntegra.
Conteúdo: