A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Requisitos Não-funcionais. Introdução Temas:  Classificação de Requisitos Não-Funcionais  Derivando Requisitos Não-Funcionais  Requisitos para Sistemas.

Apresentações semelhantes


Apresentação em tema: "Requisitos Não-funcionais. Introdução Temas:  Classificação de Requisitos Não-Funcionais  Derivando Requisitos Não-Funcionais  Requisitos para Sistemas."— Transcrição da apresentação:

1 Requisitos Não-funcionais

2 Introdução 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”

3 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)

4 Introdução  Requisitos Não-funcionais/funcionais Exemplo: Requisito de segurança 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

5 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

6 Classificação de Requisitos Não-funcionais  IEEE-Std

7 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”

8 Classificação de Requisitos Não-funcionais CONTINUAÇÃO  Sommerville

9 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.

10 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.

11 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.

12 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

13 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 University = 1 {Letter} 20 Course = 1 {Letter} 20 Course = 1 {Letter} 20

14 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.

15 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: O tempo requerido para um trem obter uma parada completa usa a seguinte função computadorizada: trem = controle + gradiente trem = controle + gradiente onde onde gradiente= 9,8ms -2/ gradiente compensado/alpha e esses valores são conhecidos para os diversos tipos de trens gradiente= 9,8ms -2/ gradiente compensado/alpha e esses valores são conhecidos para os diversos tipos de trens

16 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.

17 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

18 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

19 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

20 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)

21 Relacionamento entre necessidades do usuário e requisitos não funcionais

22 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

23 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

24 Processo Modelo de Empresa  Loucopulos and Karakostas (1995)  metas da empresa  sub-metas  não-funcionais  Vantagem rastrear os requisitos não- funcionais

25 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

26 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

27 Exemplos de medidas métricas para requisitos não-funcionais

28 Representação das atividades RNF Requisitos não Funcionais Pericles Loucopoulos e Vassilios Karakostas Declarações de Requisitos dos stakeholders ModeloEmpresarial ModelorequisitosFuncionais RNF Estruturados

29 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

30 Requisitos para Sistemas Críticos Há três tipos principais:  Comerciais => dano econômico  Missão => realização de tarefas  Safety => dano humano/ambiental

31 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 )

32 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

33 Requisitos para Sistemas Críticos

34 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

35 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

36 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

37 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.

38 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.

39 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.

40 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)

41 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)

42 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

43 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

44 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

45 Ciclo de vida de sistemas críticos Análise de danosAvaliaçã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çãoProjeto e implementaçãoVerificação Validação da segurança Manutenção operacional BCS and IEE 1989

46 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

47 Derivando requisitos requisitos abstratos Requisitos ElicitaçãoAnáliseDocumentaçãoValidação Processo de requisitos Identificar considerações de segurança associados Identificar danos requisitos de segurança abstratos Sugestões de requisitos Avaliar riscos Análise de segurança Analisar danos

48 Derivando requisitos Esmagar a mão do operador Falha mecânicaErro do operadorFalha do controlador Falha na trava Falha no mecanismo da lâmina Falha de softwareFalha elétrica Erro de implementaçãoErro de projetoErro de especificação Fault-tree Levenson and Harvey

49 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

50 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

51 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

52 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)


Carregar ppt "Requisitos Não-funcionais. Introdução Temas:  Classificação de Requisitos Não-Funcionais  Derivando Requisitos Não-Funcionais  Requisitos para Sistemas."

Apresentações semelhantes


Anúncios Google