Requisitos Não-funcionais
Introdução
Requisitos Não-funcionais
Temas:

Classificação de Requisitos Não-Funcionais
 Derivando Requisitos Não-Funcionais
 Requisitos para Sistemas Críticos
 Engenharia de Requisitos para “Safety-Related
System”
Introdução
Objetivos



Colocar restrições Antes e durante o processo
desenvolvimento
Definir as qualidades globais do sistema
 Segurança (Safety ,Security)
 Usabilidade
 Confiança
 Requisitos de desempenho
Colocar restrições no serviço do sistema sobre
exigências do usuário (Interfaces, Qualidades,
Recurso, Tempo)
Introdução

Requisitos Não-funcionais/funcionais
Exemplo: Requisito de segurança

O sistema só permitirá acesso aos dados, com
autorização.
 O sistema terá um procedimento de autorização
de usuários, nos quais tenham que se identificar
usando um (login) e uma senha. Somente
usuários autorizados terão acesso aos dados
Classificação de Requisitos
Não-funcionais
CONTINUAÇÃO

Boehm-1976,( Deutsh e Willis,1998)


Qualidades exibidas por um software
Davis, 1992

Não-comportamental





Portabilidade
Confiabilidade
Eficiência
Engenharia humana
Testabilidade, Understandabilidade, Modificabilidade
Classificação de Requisitos
Não-funcionais

IEEE-Std 830 -1993

3 Specific Requeriments
3.1 Functional requeriments
3.2 Performance requeriments
3.3 Interface requirements
3.4 Operational requirements
3.5 Resource requirements
3.6 Verification requirements
3.7 Acceptance requirements
3.8 Documentation requirements
3.9 Security requirements
3.10 Portabiliry requirements
3.11 Quality requirements
3.12 Reliabiliry requirements
3.13 Maintainabiliry requirements
3.14 Safety requirements
Classificação de Requisitos
Não-funcionais
CONTINUAÇÃO

Sommerville

Considera:



Interoperabilidade de software e hardware
Processos de desenvolvimento seguidos
Fatores externos, como “Safety e Security regulations”
Classificação de Requisitos
Não-funcionais
CONTINUAÇÃO

Sommerville
Classificação de Requisitos
Não-funcionais
CONTINUAÇÃO

Requisitos de Produtos

Requsitos que podem ser formulado precisamente



O sistema X terá uma disponibilidade de 999/1000 ou 99%.
Isso significa, que a cada 1000 pedidos no serviço 999 devem
ser satisfeitos.
Um sistema X processará 8 transações por segundo .
O código executável em Z de um sistema está limitado em 512
Kb.
Classificação de Requisitos
Não-funcionais
CONTINUAÇÃO

Requisitos de Produtos

Requistos declarados no estado informal

O sistema será desenvolvido para PC e MACINTOSH.
 O sistema codificará todas as comunicações externas em
algoritmo RSA.
 O sistema X Será implementado usando a versão 5 da
BIBLIOTECA Y.

Conflitos em requisitos de Produto

Requisito de utilização de espaço pode entrar em conflito com
o requisito que especifica um compilador padrão, no qual não
gerará o código compacto a ser usado.
Classificação de Requisitos
Não-funcionais
CONTINUAÇÃO

Requisitos de Processos

O processo de desenvolvimento deve ser definido
claramente conforme o padrão ISO 9000

O sistema deve ser desenvolvido usando a seqüência XYZ
da ferramenta CASE.

O gerenciamento de relatórios deve ser produzido a cada
duas semanas, informando o esforço gasto, com a
identificação do componente do sistema.

Um esquema de recuperação no desenvolvimento do
sistema deve ser especificado para o caso de acidentes.
Classificação de Requisitos
Não-funcionais
CONTINUAÇÃO

Requisitos Externos

São requisitos que podem ser colocados no produto e no
processo e são derivados do ambiente que é desenvolvido.

Eles podem fundamentar-se nas informações de domínio
da aplicação.

Considerações Oeganizacionais

Necessidades com outros sistemas

Safety ou regulamentos de proteção dos dados

Leis básicas da física natural
Requisitos Externos
Exemplo 1

O sistema de registro de estudante.
O formato dos dados de registro de estudante disponível pelo
SREC (Student Record System)
Seqüência de registro de dados usada na anotação é como se segue:
Admission_No + Name + Address + University + Course
The individual data items are defined thus:
Admission_No = Year + Personal_Number
Year = 4{Digit}4
Personal_Number = 5{Dìgit}5 Digit = 0 |1| 1 | .. | 9
Name = Surname + (Middlename) + Fìrstname
Surname =1[Letter}15+ (Hyphen) +1{Lettex}15
Middlename = {Letter)10
FirstrLame =1{Letter}15
Letter= A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|X|Y|Z
Hyphen = Address =1{Char}140 Char = Digit |1| Letter | - | | ,
University =1{Letter}20
Course = 1{Letter}20
Requisitos Externos
Exemplo 2

Sistema de dados médicos.
Organização de proteção de dados oficial deve
certificar que todos os dados mantido, estejam de
acordo com a legislação de proteção de dados,
antes do sistema entrar em operação.
Requisitos Externos
Exemplo 3
Sistema de proteção nos
trens.
O tempo requerido para um trem
obter uma parada completa usa a
seguinte função computadorizada:
trem = controle+gradiente
onde
gradiente= 9,8ms-2/gradiente
compensado/alpha e esses
valores são conhecidos para os
diversos tipos de trens
Derivando Requisitos não Funcionais

Não são abordados adequadamente devido:

Dificuldade de elicitar

Limites relacionados ao projeto

Subjetivas => avaliações empíricas complexas.
Derivando Requisitos não Funcionais

Requisitos não funcionais estão relacionados a
requisitos funcionais.

Requisitos não funcionais tendem a conflitar entre
si.

Não há regras para os requisitos não-funcionais.

Uma solução é uma proposta para uma nova
solução
Propostas de Modelos

Chung modelo-orientado-a-metas
 Dobson modelos lógicos
 Kotonia (Kotonia and Sommerville, 1996)
pontos-de-vista
Traduzir objetivos gerais ou metas em
declarações que se refiram às propriedades
mensuráveis do sistema
Requisitos de Software (Preocupações)

Os interessados tem preocupações
importantes mas difícil de articular

São tipicamente não-funcionais

Objetivos críticos do negócio (padronização)

Características essenciais do sistema como

segurança

desempenho

funcionalidade

manutenabilidade
Requisitos de Software (Preocupações)
Atender as preocupações em cada estágio é
prioritário

Atender requisitos funcionais

Expressam requisitos críticos "holísticos”

sub-preocupações

lista de verificação

Preocupações x prioridades globais
Relacionamento entre necessidades do
usuário e requisitos não funcionais
Necessidades do
usuário
Função
Desempenho
Alteração
Preocupações do
usuário
1. Facilidade de uso
2. Acesso não autorizado
3. Possibilidade de falha
4. Utilização de recursos
5. Desemp. de
verificação
6. Facilidade
comunicação
7. Facilidade de reparar
8. Facilidade de alterar
9. Facilidade de
transportar
10.Facilidade de
expandir
Requisitos nãofuncionais
1. Usabilidade
2. Segurança
3. Confiança
4. Eficiência
5. Verificabilidade
6. Interoperabili.
7. Mantenabilidade
8. Flexibilidade
9. Portabilidade
10.Expansibilidade
Decomposição de Preocupações
Sistema de Proteção de Trem
Safety
Colisão Descarrilamento
Excesso de Velocidade
para as condições de trajeto
O Sistema deve estar
apto a detectar e evitar
causas de descarrilamento
Acidente Pessoal
Dano de trajeto
Que informação sobre
dano de trajeto é solicitado
pelo sistema ?
Como é fornecida ?
O que sig. na verdade“excesso
de velocidade” ?
Sob que condições o excesso velocidade pode causar descarrilamento ?
Decomposição de Preocupações
Sistema de Proteção de Trem
Compatibilidade
Hardware
Ambiente de
Execução
Software
Tempo
Um requisito
afetará o
desempenho
do software ?
Física
Interface
O requisito
O Sistema deve
necessita de
ser executado num
dados que
ambiente de execução
não estão
ADA
disponíveis
na Interface ?
Pode esta função ser fornecida pelo ambiente de execução ?
Processo Modelo de Empresa

Loucopulos and Karakostas (1995)

metas da empresa

sub-metas

não-funcionais

Vantagem rastrear os requisitos não-
funcionais
Relacionamento entre Empresa e
Metas do Sistema
Meta
Visualizar os cenários
de tráfego aéreo
Meta secundária
Requer sistema de
resposta em tempo real
Requisitos não-funcionais
Os dados do radar
Todos os dados
devem ser mostrados
dos cenários devem
em tempo real
ser mostrados
Requisitos
não-funcionais
quantitativos
Mostrar 100
trajetos
Mostrar 100
vetores
A posição da aeronave
deve ser mostrada em
menos de 0.165s
Mostrar 500 tabelas
de símbolos
Atributos de requisitos não-funcionais
(Deutsch and Willis, 1988; Sommerville, 1996)

eles devem ser objetivos

um requisito não-funcional é objetivo se não
expressa um desejo, uma meta, ou uma opinião
pessoal.

eles devem ser testáveis

um requisito não-funcional é testável se há algum
processo pelo qual o requisito possa ser testado
Exemplos de medidas métricas para
requisitos não-funcionais
Propriedade
Desempenho
Confiança
Disponibilidade
Tamanho
Usabilidade
Robustez
Portabilidade
Métrica
 transações processadas por segundo
 tempo de resposta para entrada do usuário
 taxa de ocorrência de falha
 tempo médio de falha
 probabilidade de falha na demanda
 kbytes
 tempo necessário para aprender 80% das
facilidades
 número de erros cometidos pelo usuário
num dado período de tempo
 tempo para reiniciar após uma falha no
sistema
 número de sistemas alvo
Requisitos não Funcionais
Pericles Loucopoulos e Vassilios Karakostas
Declarações
de Requisitos
dos stakeholders
Modelo
Representação
das atividades
Modelo
requisitos
Funcionais
RNF
Empresarial
RNF
Estruturados
Requisitos para Sistemas Críticos
Sistemas críticos são sistemas cuja ‘falha’
causam danos significativos para as pessoas
ou organizações.


econômicos
físicos
 humanos
Requisitos para Sistemas Críticos
Há três tipos principais:

Comerciais => dano econômico

Missão => realização de tarefas

Safety => dano humano/ambiental
Requisitos para Sistemas Críticos

As principais restrições não-funcionais:

confiança

desempenho

security (segurança para o sistema)

usabilidade

safety (segurança para o usuário/meio
ambiente )
Requisitos para Sistemas Críticos
requisitos não-funcionais são:

requisitos do sistema como um todo

pode levar a requisitos funcionais específicos
para o software ou outros sub-sistemas.

ocorre conflito entre eles
Requisitos para Sistemas Críticos

Identificados explicitamente e negociados





Código => Desempenho => Confiança
Código => Desempenho => Confiança
Segurança => Usabilidade
Safety contradiz Disponibilidade do sistema
compromisso entre os interessados para
satisfazer o sistema
Requisitos de Confiança
São Restrições no comportamento do sistema
durante a execução

Disponibilidade


exemplo: 3 minutos de indisponibilidade em 24
horas
Taxa de falha


ROCOF - taxa de ocorrência de falhas num dado
período de tempo
MTTF - tempo médio entre falhas no sistema
Requisitos de Desempenho
limitam a velocidade de operação de um
sistema:

Requisitos de resposta


Requisitos throughput


sistema deve responder a uma solicitação do
usuário dentro de 2 segundos.
processar pelo menos 10 transações por
segundo.
Requisitos de tempo

o sistema deve registrar os dados dos sensores
pelo menos 6 vezes por segundo
Requisitos de Desempenho

A memória RAM pode afetar


o comportamento do sistema na execução
a velocidade de operação do sistema.
Devem ser especificados quantitativamente
Requisitos de Segurança (Security)
Os requisitos de segurança são incluídos num
sistema para

assegurar que não seja permitido o acesso
não autorizado ao sistema e aos seus dados

para assegurar integridade do sistema
quando de danos acidentais e maliciosos.
Requisitos de Usabilidade
Especificam a interface do usuário final e
interações com o sistema.

podem ser especificados quantitativamente
 são pouco concretos
 preocupados em achar consistência através
de diferentes sistemas

decisões de projeto de sistema afetam que
formulários serão usados.
Requisito de Segurança (Safety)

Não há concenso sobre o que significa o termo
‘requisito seguro’ (safety requirement)
 requisitos que estão diretamente relacionados
para assegurar operação segura
 requisitos de sistemas de proteção que são
projetados para proteger contra acidentes.
 o uso específico do termo geralmente depende
da cultura e prática da organização na qual é
usado.
Requisito de Segurança (Safety)
Requisitos “safety” são os requisitos ‘não
devem’ que excluem situações inseguras das
soluções do sistema.

o sistema não deve permitir operação a
menos que o responsável pela operação
esteja presente
Requisito de Segurança (Safety)

o sistema não deve permitir que seja
aplicado ao paciente uma dose de sedativo
maior que o valor máximo determinado pelo
médico do pciente.
 o sistema não deve operar se a temperatura
externa estiver menor que 4 graus Celsius.
Os requisitos “safety” podem não definir a
funcionalidade de um sistema mas, ao inves
disso, descrever um comportamento
inaceitável ou indesejado do sistema.
ER em sistemas relacionados com
segurança (safety)

Sistemas em que uma falha pode causar
danos aos operadores, clientes, organização,
ambiente ou público em geral

Controle de tráfego aéreo

Controle de rotas de trem

Controle industrial

Produtos domésticos
ER em sistemas relacionados com
segurança (safety)

A segurança (safety) do sistema depende de
vários requisitos não-funcionais (não apenas
de segurança):

Confiabilidade

Segurança de acesso (security)

Desempenho

Usabilidade
ER em sistemas relacionados com
segurança (safety)

Como derivar requisitos ?

Atividade de análise de segurança

Preocupa-se em garantir que o sistema produzido
não coloca em perigo os usuários finais ou o
ambiente
Ciclo de vida de sistemas críticos
Análise de danos
Avaliação de riscos
BCS and
IEE 1989
Especificação dos requisitos de segurança
requisitos
funcionais
requisitos de
segurança
Definição dos sistemas de segurança
Planejamento da validação
Projeto e implementação
Validação da segurança
Manutenção operacional
Verificação
Derivando requisitos

Guilhotina automática para cortar papel

Lâmina vertical

Motor

Software de controle (controlador)

Botões de início e fim do corte

Um único operador

Sensores
Derivando requisitos
requisitos abstratos
Elicitação
Análise
Processo de requisitos
Documentação
Validação
Requisitos
Identificar considerações de
segurança associados
requisitos de segurança
abstratos
Identificar
danos
Avaliar riscos
Analisar danos
Sugestões de
requisitos
Análise de segurança
Derivando requisitos
Esmagar a mão do operador
Fault-tree
Levenson and Harvey
Falha mecânica
Falha na
trava
Erro do operador
Falha no mecanismo
da lâmina
Erro de implementação
Falha do controlador
Falha de software
Erro de projeto
Falha elétrica
Erro de especificação
Derivando requisitos

Falha mecânica

O sistema deve manter um log para verificar se a
manutenção está em dia. Se a manutenção
atrasar por 2 dias, o sistema é desabilitado

A lâmina da guilhotina deve estar ligada a duas
travas, ambas controladas pelo software
(controlador). Caso haja uma falha em alguma
trava, o sistema é desabilitado
Derivando requisitos

Erro do operador

Dois botões fisicamente separados por 30 cm
devem ser pressionados simultaneamente

Se algum dos botões (ou ambos) estiverem
pressionados por mais de 0,25 segundos o
sistema deve ser desabilitado
Derivando requisitos

Falha do controlador

O software de controle deve ser formalmente
especificado em Z e a consistência da
especificação deve ser demonstrada com
argumentos matemáticos

A integridade dos dados do sistema deve ser
checada duas vezes a cada segundo. Se alguma
inconsistência for detectada, o sistema é
desabilitado
Resumo

Requisitos não-funcionais definem
qualidades ou atributos gerais do sistema

Existem três tipos: produto, processo e
requisitos externos

As principais restrições são:

Confiabilidade, desempenho, usabilidade e
segurança (safety e security)