CAP 09 - IDENTIFICAR REQUISITOS NÃO-FUNCIONAIS

Prévia do material em texto

Conteúdo:
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 
Catalogação na publicação: Ana Paula M. Magnus – CRB 10/2052
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
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 
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 funcionais2
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. 
3Identificar 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 funcionais4
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. 
5Identificar 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 funcionais6
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.
7Identificar 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.
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 
alteração
N/A Autor N/A
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).
Quadro 1.
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 funcionais8
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.
9Identificar requisitos não funcionais
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: