Requisitos não funcionais

A complexidade de um software é determinada

em parte por sua funcionalidade (requisitos
funcionais), ou seja, o que o sistema faz, e em
parte por requisitos gerais (requisitos não
funcionais) que fazem parte do desenvolvimento
do software como custo, performance,
confiabilidade, manutenibilidade, portabilidade,
custos operacionais entre outros
Requisitos Funcionais X Não Funcionais
Os requisitos funcionais são requisitos que expressam
funções ou serviços que um software deve ou pode ser
capaz de executar ou fornecer. As funções ou serviços são,
em geral, processos que utilizam entradas para produzir
saídas.

Os requisitos não funcionais são requisitos que declaram

restrições, ou atributos de qualidade para um software e/ou
para o processo de desenvolvimento deste sistema.
Segurança, precisão, usabilidade, performance e
manutenabilidade são exemplos de requisitos não
funcionais.
Requisitos não funcionais
São conhecidos como atributos de qualidade, restrições, objetivos
entre outros;
Não possuem mapeamento direto nas funcionalidades;
Não são fáceis de detectar;
Devem ser observados cuidadosamente ao longo do
desenvolvimento;
Se relacionam diretamente com o produto, suas funções e/ou com
o ambiente onde será implantado;
Desempenham um papel crítico durante o desenvolvimento de
sistemas e erros devido a não elicitação ou a elicitação incorreta
destes estão entre os mais caros e difíceis de corrigir, uma vez que
um sistema tenha sido implementado
Requisitos não funcionais
A distinção entre o que é um requisito funcional e o que é um não
funcional nem sempre é clara. Parte da razão advém para o fato de
que estão sempre relacionados a um requisito funcional;

Partindo da definição acima pode-se dizer que um requisito

funcional expressa algum tipo de transformação que tem lugar no
software, enquanto um não funcional expressa como essa
transformação irá se comportar ou que qualidades específicas ela
deverá possuir.
Um Exemplo
Suponhamos que estejamos no domínio de uma clinica médica: um
requisito funcional do sistema sistema seria:

“O sistema deve fornecer uma entrada de dados que possibilite a

designação de resultados a exames admitidos para um paciente por
técnicos, supervisores e chefes”.

Este mesmo requisito funcional poderá ter associado a ele o seguinte

não funcional:

“Alguns exames deverão ter tratamento especial para a entrada de

resultados. Para estes exames, valores acima ou abaixo de uma lista
pré-determinada, só poderão ser digitados por chefes de seção!”.
Detalhando o Exemplo
O requisito não funcional apresentado não exprime uma função do
sistema, e sim, uma restrição a uma função que deverá existir: Entrar
com os Resultados de Exames;
O que se vê é que essa funcionalidade do sistema deverá ser
restrita de forma que, quando utilizada por pessoas que não sejam
chefes, deverá restringir os valores a uma lista pré-definida;
Esse requisito não funcional diz respeito a segurança da aplicação,
já que não permite que pessoas não autorizadas insiram valores
críticos no sistema.
 É importante entender que este requisito demandará um trabalho
bem mais complexo daquele que seria implantado se apenas o
funcional tivesse sido especificado e que é vital para manter a
integridade e segurança da informação que o sistema irá armazenar.
Classificação de Requisitos Não Funcionais

Proposta do Mamani
Classificação de Requisitos Não Funcionais

Proposta do Sommerville
Usabilidade
Requisitos associados à facilidade de uso da aplicação;
Definem o nível de dificuldade que o usuário terá para executar as
operações;
Estão relacionados com a interação do usuário junto ao sistema
Normalmente associados a interface, mas podem estar associado a
outros elementos como: interação com o teclado, tempo de
treinamento, nível de conhecimento necessário para interação entre
outros;
Ex1.: Em um software infantil, é necessário que haja um
investimento grande em cores e objetos grandes para facilitar a
interação das crianças.
Ex2.: O usuário Zé das Coves, digita uma grande massa de dados por
mês e precisa que todas as operações CRUD, na janela de digitação,
sejam acessadas diretamente pelo teclado para que ele não perca
tempo indo ao mouse.
Confiabilidade
Associados à freqüência e severidade de falhas da aplicação e
habilidade de recuperação das mesmas

São requisitos não funcionais de confiabilidade:

Tempo médio de falhas;

Probabilidade de indisponibilidade;
Taxa de ocorrência de falhas;
Tempo de reinício após falha;
Percentual de eventos causando falhas;
Probabilidade de corrupção de dados após falha.
Desempenho
Associados à eficiência, uso de recursos e tempo de resposta da
aplicação (Transações processadas/seg, Tempo de resposta do
usuário/evento entre outros)
Ex1.: Uma consulta aos dados do empregado não pode demorar mais
de 10 milésimos;

Ex2.: Ao registrar um item sendo vendido, a descrição e preço devem

aparecer em 1 segundo;

Ex3.: A operação de cálculo de salário de empregados, não deve

exceder 20 segundos por empregado;
Segurança
Associados à integridade, privacidade e autenticidade dos dados da
aplicação;

Ex1.: A base de dados deve ser protegida para acesso apenas de

usuários autorizados;

Ex2.: Somente chefes de setor podem efetuar os pagamentos de

fornecedores;

Ex3.: Um log de todas as operações dos usuários;

Ex4.: Todas as operações do sistema que envolverem aprovação de

despesas, devem ser autorizadas através de re-autenticação com
usuário e senha e devem respeitar os limites de competência.
Implantação
Associados ao modo como será implantada a solução

Ordem de instalação dos Pacotes

Configurações iniciais necessárias

Ex1.: O sistema “contador de carneirinhos” precisa que o servidor,

responsável pelo gerenciamento da contagem, seja previamente
instalado na máquina servidora e os clientes, responsáveis por contar
os carneirinhos, instalados nas máquinas dos usuários e configurados,
conforme a tabela de configuração n.
Padrões
Associados a padrões ou normas que devem ser seguidos pela
aplicação ou pelo seu processo de desenvolvimento

Ex1.: O sistema deve atender ao padrão de desenvolvimento da

empresa, respeitando locais e nomes para variáveis, funções,
parâmetros e utilizar os objetos e funções comuns descritas na
mesma

Ex2.: O sistema deverá permitir a compra de materiais, atendendo as

necessidades descritas pelos usuários, sem desrespeitar a lei 8.666.
Hardware e Software
Associados a restrições de hardware e software usados para
desenvolver ou executar a aplicação;

Ex1.: O sistema precisará ser executado nas plataformas

operacionais: Microsoft Windows 95, Windows, 98, Windows
NT, Windows 2000 e XP

Ex1.: O sistema precisará de uma máquina, com no mínimo

512Mb de RAM, com o processador de 2.8Mghz ou superior
Conclusão
Uma especificação de requisitos só estará completa se
houver tanta preocupação com os requisitos funcionais
quanto com os requisitos não funcionais

Deve ser feito uma tabela relacionando os requisitos não

funcionais, com suas origens funcionais, já que todos os
requisitos não funcionais, existem para atender, por
completo, um requisito funcional

Não existe receita de bolo, para se definir os requisitos

não funcionais, é necessário partir dos funcionais
levantados e detalhá-los em busca de regras de
implementações
Pontos chaves sobre requisitos
. O processo de engenharia de requisitos incluem estudo de
viabilidade,o levantamento e a análise de requisitos, a
especificação de requisitos, a validação de requisitos e o
gerenciamento de requisitos.
. A análise de requisitos é um processo iterativo,que envolve a
compreensão do domínio, assim como a coleta, a classificação, a
estruturação, a priorização e a validação dos requisitos.
. Diferentes stakeholders do sistema têm diferentes requisitos.
Todos os sistemas complexos devem, portanto, ser analisados a
partir de uma série de diferentes pontos de vista. Os pontos de
vista podem ser fontes ou 'drenas' de dados; diferentes
representações ou entidades do sistema estão fora do sistema e
recebem serviços a partir dele.
Pontos chaves sobre requisitos
. Os fatores sociais e organizacionais têm forte influência sobre os
requisitos do sistema e podem determinar se o software será
realmente utilizado ou não.
. A validação dos requisitos é o processo de verificar os requisitos
quanto a sua validade, consistência, completeza, seu realismo e sua
facilidade de verificação. As revisões de requisitos e a
prototipação são as principais técnicas utilizadas para a validação
de requisitos.
. As modificações organizacionais, técnicas e de negócios
inevitavelmente levam a mudanças nos requisitos, em um sistema
de software. O gerenciamento de requisitos é o processo de
gerenciar e controlar essas mudanças.
. O processo de gerenciamento de requisitos inclui o planejamento
do gerenciamento, em que são especificados os procedimentos e as
políticas para o gerenciamento de requisitos, e o gerenciamento
de mudanças, em que as mudanças são analisadas e seu impacto é
avaliado. 1
Exercício I
1) Um sistema de software deve ser desenvolvido para automatizar
um catálogo de biblioteca. Esse sistema conterá informações sobre
todos os livros da biblioteca e será utilizado por seus funcionários,
leitores e pessoal que empresta livros da biblioteca. O sistema deverá
permitir 'navegar' no catálogo e fazer consultas, além de fornecer
recursos que possibilitem aos usuários enviar mensagens ao pessoal
da biblioteca, solicitando a reserva de livros que estão emprestados.
Identifique os principais pontos de vista que devem ser levados em
consideração na especificação desse sistema.
2) Para três dos pontos de vista identificados no sistema de catálogo
da biblioteca, sugira os serviços que podem ser fornecidos para cada
ponto de vista, os dados que o ponto de vista pode fornecer e os
eventos que controlam o fornecimento desses serviços.
3) Para os serviços identificados no Exercício 1-2, especifique quais
poderiam ser as restrições não funcionais mais importantes.
Exercício II
1) Quando mudanças de emergência têm de ser feitas em sistemas, o
software de sistema pode precisar ser modificado, antes que as
mudanças nos requisitos tenham sido aprovadas. Sugira um modelo
de um processo para fazer essas modificações, que assegure que o
documento de requisitos e a implementação do sistema não se tornem
inconsistentes.