Requisitos Não-funcionais

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Clique para editar o estilo do título mestre
Clique para editar o estilo do subtítulo mestre
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
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 requisitos funcionais
Expressam requisitos críticos "holísticos”
sub-preocupações
lista de verificação
Preocupações x prioridades globais
Atender as preocupações em cada estágio é prioritário
Relacionamento entre necessidades do usuário e requisitos não funcionais
Necessidades do usuário
Preocupações do usuário
Requisitos não-funcionais
Função
Facilidade de uso
Acesso não autorizado
Possibilidade de falha
Usabilidade
Segurança
Confiança
Desempenho
Utilização de recursos
Desemp. de verificação
Facilidade comunicação
Eficiência
Verificabilidade
Interoperabili.
Alteração
Facilidade de reparar
Facilidade de alterar
Facilidade de transportar
Facilidade de expandir
Mantenabilidade
Flexibilidade
Portabilidade
Expansibilidade
Safety
Colisão
Descarrilamento
Acidente Pessoal
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
Requisitos não Funcionais 
Pericles Loucopoulos e Vassilios Karakostas
Declarações
de Requisitos
dos stakeholders
Representação das atividades NFR
Modelo
Empresarial
Modelo
requisitos
Funcionais
NFR
Estruturados
Requisitos para Sistemas Críticos
econômicos
físicos
humanos
Sistemas críticos são sistemas cuja ‘falha’ causam danos significativos para as pessoas ou organizações.
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
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
São Restrições no comportamento do sistema durante a execução
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
limitam a velocidade de operação de um sistema:
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
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.
Especificam a interface do usuário final e interações com o sistema.
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)
o sistema não deve permitir operação a menos que o responsável pela operação esteja presente
Requisitos “safety” são os requisitos ‘não devem’ que excluem situações inseguras das soluções do sistema.
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
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
Processo de requisitos
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)