cap8sdasd

Prévia do material em texto

Requisitos Não-funcionais
Wilson José dos Santos
Pedro Luciano Leite Silva
Juliano Manabu Iyoda
Universidade Federal de Pernambuco
Departamento de Informática
Tópicos Avançados em Engenharia de Software 2
(Engenharia de Requisitos e CASE)
Prof. Jaelson Brelaz Castro
Prof. Alexandre Marcos Lins de Vasconcelos
Outubro / 1998
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
Traduzir objetivos gerais ou metas em 
declarações que se refiram às propriedades 
mensuráveis do sistema
Propostas de Modelos
 Chung modelo-orientado-a-metas 
 Dobson modelos lógicos 
 Kotonia (Kotonia and Sommerville, 1996) 
pontos-de-vista
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
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
Requisitos de Software (Preocupações)
Necessidades do
usuário
Preocupações do
usuário
Requisitos não-
funcionais
Função 1. Facilidade de uso
2. Acesso não autorizado
3. Possibilidade de falha
1. Usabilidade
2. Segurança
3. Confiança
Desempenho 4. Utilização de recursos
5. Desemp. de
verificação
6. Facilidade
comunicação
4. Eficiência
5. Verificabilidade
6. Interoperabili.
Alteração 7. Facilidade de reparar
8. Facilidade de alterar
9. Facilidade de
transportar
10. Facilidade de
expandir
7. Mantenabilidade
8. Flexibilidade
9. Portabilidade
10. Expansibilidade
Relacionamento entre necessidades do 
usuário e requisitos não funcionais
Safety
Colisão Descarrilamento AcidentePessoal
Excesso de Velocidade
para as condições de trajeto
Dano de trajeto
Que informação sobre 
dano de trajeto é solicitado
pelo sistema ?
Como é fornecida ?
O Sistema deve estar
apto a detectar e evitar
causas de descarrilamento
Sob que condições o excesso velocidade pode causar descarrilamento ?
O que sig. na verdade“excesso
de velocidade” ?
Decomposição de Preocupações
Sistema de Proteção de Trem
Compatibilidade
Hardware Software Física
Ambiente de
Execução
Tempo Interface
Um requisito
afetará o 
desempenho
do software ?
O requisito
necessita de
dados que
não estão
disponíveis
na Interface ?
O Sistema deve
ser executado num
ambiente de execução
ADA
Pode esta função ser fornecida pelo ambiente de execução ?
Decomposição de Preocupações
Sistema de Proteção de Trem
Processo Modelo de Empresa
 Loucopulos and Karakostas (1995)
 metas da empresa
 sub-metas 
 não-funcionais
 Vantagem rastrear os requisitos não-
funcionais 
Meta
Visualizar os cenários
de tráfego aéreo
Requer sistema de 
resposta em tempo real
Meta secundária
Todos os dados
dos cenários devem
ser mostrados
Os dados do radar
devem ser mostrados
em tempo real
A posição da aeronave
deve ser mostrada em 
menos de 0.165s
Mostrar 100
trajetos
Mostrar 100
vetores
Mostrar 500 tabelas
de símbolos
Requisitos 
não-funcionais 
quantitativos
Requisitos não-funcionais 
Relacionamento entre Empresa e 
Metas do Sistema
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 Métrica
Desempenho • transações processadas por segundo
• tempo de resposta para entrada do usuário
Confiança • taxa de ocorrência de falha
• tempo médio de falha
Disponibilidade • probabilidade de falha na demanda
Tamanho • kbytes
Usabilidade • tempo necessário para aprender 80% das
facilidades
• número de erros cometidos pelo usuário
num dado período de tempo
Robustez • tempo para reiniciar após uma falha no
sistema
Portabilidade • número de sistemas alvo
Representação 
das atividades 
NFR
Requisitos não Funcionais 
Pericles Loucopoulos e Vassilios Karakostas
Declarações
de Requisitos
dos stakeholders
Modelo
Empresarial
Modelo
requisitos
Funcionais
NFR
Estruturados
Sistemas críticos são sistemas cuja ‘falha’ 
causam danos significativos para as pessoas 
ou organizações.
Requisitos para Sistemas Críticos
 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
 I d e n t i f i c a d o s e x p l i c i t a m e n t e e n e g o c ia d o sI d e n t i f i c a d o s e x p l i c i t a m e n t e e n e g o c ia d o s
 C ó d i g o = > D e s e m p e n h o = > C o n f i a n ç a C ó d i g o = > D e s e m p e n h o = > C o n f i a n ç a
 C ó d i g o = > D e s e m p e n h o = > C o n f i a n ç a C ó d i g o = > D e s e m p e n h o = > C o n f i a n ç a
 S e g u r a n ç a = > S e g u r a n ç a = > U s a b i l i d a d e U s a b i l i d a d e
 S a f e t yS a f e t y c o n t r a d i z D i s p o n ib i l i d a d e d o s i s t e m ac o n t r a d i z D i s p o n ib i l i d a d e d o s i s t e m a
 c o m p r o m is s o e n t r e o s i n t e r e s s a d o s p a r ac o m p r o m is s o e n t r e o s i n t e r e s s a d o s p a r a
s a t i s f a z e r o s i s t e m as a t i s f a z e r o s i s t e m a
São Restrições no comportamento do sistema 
durante a execução
Requisitos de Confiança
 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
limitam a velocidade de operação de um 
sistema:
Requisitos de Desempenho
 Requisitos de resposta 
 sistema deve responder a uma solicitação do 
usuário dentro de 2 segundos.
 Requisitos throughput 
 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. 
Especificam a interface do usuário final e 
interações com o sistema.
Requisitos de Usabilidade
 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.
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)
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. 
 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.
Requisito de Segurança (Safety)
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 produzidonã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
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 Verificação
Validação da segurança
Manutenção operacional
BCS and 
IEE 1989
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
Requisitos
Elicitação Análise Documentação Validação
Processo de requisitos
Identificar considerações de
segurança associados
Identificar 
danos
requisitos de segurança 
abstratos
Sugestões de 
requisitosAvaliar riscos
Análise de segurança
Analisar danos
Derivando requisitos
Esmagar a mão do operador
Falha mecânica Erro do operador Falha do controlador
Falha na
trava
Falha no mecanismo
da lâmina
Falha de software Falha elétrica
Erro de implementação Erro de projeto Erro de especificação
Fault-tree
Levenson and Harvey
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)