Fatec. Curso Análise e Desenvolvimento de Sistemas. Requisitos de Software. Disciplina Teste de Software 3 Engenharia de Requisitos

Transcrição

1 Fatec Curso Análise e Desenvolvimento de Sistemas Disciplina Teste de Software 3 Engenharia de Prof. Edson Saraiva de Almeida Fevereiro/ de Software de um sistema São descrições dos serviços fornecidos pelo sistema e as suas restrições operacionais, refletem as necessidades dos clientes e ajudam a resolver algum problema. Engenharia de Processo de descobrir, analisar, documentar e verificar as necessidades dos clientes (serviços e restrições) O termo requisito não é utilizado de maneira consistente na indústria Em alguns casos é simplesmente uma declaração abstrata em alto nível, no outro extremo é uma definição formal e detalhada de uma função do sistema. 2 1

2 de Software de usuário de sistema Declarações, em uma linguagem natural de quais serviços são esperados do sistema e as restrições sob as quais ele deve operar. Definem detalhadamente, as funções, serviços e as restrições operacionais do sistema. O documento de requisitos de sistema pode ser parte do contrato entre o comprador e o desenvolvedor. 3 funcionais e não funcionais de sistema funcionais não funcionais Os requisitos de sistema de software são frequentemente classificados em requisitos funcionais e não funcionais. São declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações. Estabelecem as restrições sobre os serviços ou as funções oferecidas pelo sistema, incluem restrições de tempo de execução, restrições sobre o processo de desenvolvimento, uso de padrões, frequentemente aplicam-se ao sistema como um todo. 4 2

3 Tipos de RNF 5 Especificação de requisitos de sistema em linguagem estruturada Função Descrição Entradas Origem Saídas Destino Ação... Requer... Precondição... Póscondição... Efeitos colaterais... Bomba de Insulina Calcular a dose de insulina: nível seguro de acuçar Calcula a dose de insulina a ser liberada quando o nível medido de açúcar atual está na zona segura Leitura atual de açúcar Leitura atual de açúcar do sensor, outras leituras da memoria CompDose a dose de insulina a ser liberada Loop de controle principal 6 3

4 Casos de Uso: saque no caixa eletrônico UC01 Saque no caixa automático Descrição permite o saque de dinheiro em espécie Ator -cliente Fluxo básico 1. Este caso de uso é iniciado quando o cliente chega ao caixa eletrônico e insere o seu cartão. 2. O sistema requisita a senha do cliente. 3. O cliente fornece sua senha. 4. O sistema valida a senha e exibe o menu de opções.[a1] 5. O cliente seleciona a opção saque 6. O sistema solicita a quantia. 7. O cliente informa a quantia desejada e confirma a operação. [A2] 8. O sistema dispensa o valor solicitado e retorna para o menu principal.[a3] Fluxo alternativo [A1] -O sistema envia uma mensagem de senha invalida e retorna ao passo 2. [A2] -O cliente cancela a operação o caso de uso é encerrado. [A3]. O sistema envia uma mensagem de valor invalido e retorna ao passo 6. Evento disparador Interação Passo de validação 7 Documento de de Software Software Requirements Specification- SRS É a declaração oficial do que os desenvolvedores de sistemas devem implementar. Deve incluir os requisitos de usuário de um sistema e uma especificação detalhada dos requisitos de sistema. Nível de detalhamento Depende do tipo de sistema que está sendo desenvolvido e do processo de desenvolvimento utilizado. IEEE/ANSI Padrão mais amplamente conhecido para documentação de requisitos 8 4

5 O padrão IEEE Std 830 sugere a seguinte estrutura para o documento de requisitos Estruturas padronizadas -o padrão IEEE Std830 sugere a seguinte estrutura para o documento de requisitos 1. Introdução 1. Propósito 2. Escopo do produto 3. Definições, acrônimos e abreviaturas 2. Descrição geral 1. Perspectiva do produto 2. Funções do produto 3. Características dos usuários 4. Restrições gerais 5. Suposições e dependências. 3. específicos 4. Apêndices 5. Índice 9 ER atividades fundamentais Qualquer processo de ER tem um conjunto de atividades fundamentais atividade cíclica SOMMERVILLE, Ian. Integrated requirements engineering: A tutorial.software, IEEE, v. 22, n. 1, p ,

6 ER atividades fundamentais Gestão dos Gestão de Um modelo sistemático para: identificar, organizar e documentar os requisitos do sistema, e estabelecer e manter acordo entre o cliente e a equipe do projeto nos requisitos variáveis do sistema Acompanhamento das mudanças As atividades ligadas ao processo de acompanhamento das mudanças são denominadas de Gerência de Rastreabilidade A rastreabilidade esta intimamente associada a gerência de requisitos 11 ER atividades fundamentais Gestão dos Modelo de rastreabilidade A efetiva aplicação da rastreabilidade no processo de desenvolvimento de software depende da definição de um modelo de rastreabilidade Identificação A gestão de requisitos começa com a identificação. A cada requisito é atribuído um modo identificador. Uma vez identificado tabelas de rastreabilidade são desenvolvidas. Cada tabela de rastreamento relaciona os requisitos identificados a um ou mais aspectos dos sistema e seu ambiente. 12 6

7 Modelo de rastreabilidade - matriz de rastreabilidade Casos de Uso X Casos de Teste CT01 CT02 CT03 CT04 Cadastrar cliente Consultar cliente Alterar cliente Excluir cliente 13 Modelo de rastreabilidade - matriz de rastreabilidade Matriz de rastreabilidade a primeira coluna da matriz deverá ser preenchida com os requisitos; normalmente os requisitos são expressos em linguagem natural e numerados sequencialmente, mas também podem ser utilizadas outras formas de representação. As demais colunas devem representar artefatos gerados durante o processo de desenvolvimento; a correspondência nem sempre é da ordem de um para um (por exemplo, um requisito pode estar sendo verificado em diversos casos de teste, e vice-versa). 14 7

8 Modelo de rastreabilidade - nomenclatura Exemplo: A cada requisito é atribuído um modo identificador. Requisito de Usuário REQ01 de Sistema REQ01UC01 REQ01UC02 Casos de Teste CT01UC01FBCadastrarFornecedor_com_sucesso CT01UC01A1CadastrarFornecedor_com_cnpj_invalido 15 Exemplo fase de elicitação Um estacionamento está iniciando um processo para automatizar a gestão da estadia de veículos para mensalistas. Em uma entrevista com o gestor da empresa as seguintes necessidades foram identificadas: Cadastrar os clientes Registrar a movimentação dos veículos Gerar boleto de cobrança mensal Gerar um relatório de faturamento mensal e inadimplência. 16 8

9 Exemplo fase de análise e documentação de usuário Req01 O sistema deve permitir o cadastro de clientes da rede com as seguintes informações: CPF, nome, endereço, telefone de contato. Req02 O sistema deve permitir o cadastro de veículos por cliente com as seguintes informações: placa, modelo, código do cliente (CPF), tamanho. Os veículos são classificados pelo tamanho em utilitário, médio e pequeno. Um cliente pode ter um ou mais veículos cadastrados no seu nome. Req03 O sistema deve registrar a entrada e saída do veículo considerando as seguintes informações: placa e horário Req04 O sistema deve gerar o boleto de cobrança mensal Req05 O sistema deve gerar o relatório de faturamento mensal e inadimplência. 17 Exemplo fase de análise e documentação Modelo de rastreabilidade - utilizando nomenclatura Rastreabilidade - requisito de usuário para requisito de sistema Req01UC01 Cadastrar cliente Req01UC02 Consultar cliente Req01UC03 Alterar cliente Req01UC04 Excluir cliente Um requisitos de usuário deu origem a 4 requisitos de sistema 18 9

10 Exemplo fase de análise e documentação Modelo de rastreabilidade utilizando matriz de rastreabilidade de Usuário de Sistema casos de uso REQ01 REQ02 REQ03 REQ04... Cadastrar Cliente, Consultar Cliente, Alterar Cliente, Excluir Cliente Cadastrar veiculo, Consultar veiculo,alterar veiculo, Excluir veiculo Registrar entrada, Registrar saída Gerar boleto de cobrança 19 Priorização de requisitos Testes revelam a presença de defeitos O teste de software é um conjunto de atividades que visa executar um programa com o objetivo de revelar a presença de defeitos. Durante o processo de desenvolvimento de software defeitos são introduzidos no programa durante sua construção. Atividades de teste consomem muito tempo e recursos Estratégias de teste baseadas no risco de falha das funções As atividades de teste de software consomem muito tempo e muitos recursos. Em função de limitações de prazos e orçamento, muitas vezes o teste de software é negligenciado e, consequentemente, o software é entregue ao usuário com defeitos não revelados que provocarão falhas em seu uso cotidiano. Neste cenário é importante estabelecer estratégias que maximizem o resultado do teste reduzindo o custo desta atividade. O teste baseado em riscos, consiste em atividades para identificação e análise de fatores de riscos associados aos requisitos do produto de software, priorizando esforços e alocando recursos para os componentes de software que necessitam ser testados mais cuidadosamente. Assim, pode-se planejar a alocação de recursos de teste de acordo com o impacto das falhas melhorando a eficácia da atividade de teste

11 Priorização de requisitos Potencial de exposição a falhas Análise de risco e priorização, os casos de teste são priorizados baseados na cobertura das funções de maior risco. Para cada requisito determinar Perfil operacional de uso identifica as funções mais utilizadas Probabilidade de falha (1-baixa, 2- média, 3-alta) Conseqüência (impacto da falha) (1-baixa,2-médio, 3-alta) Coeficiente de risco = probabilidade X consequência (impacto da falha) Classificar os requisitos De acordo com a análise do perfil operacional e do coeficiente de risco classificar os requisitos considerando a prioridade: alto, importante, moderado, baixo. MUSA, John D., Operational profiles in software-reliability engineering. Software, IEEE, v. 10, n. 2, p , SCHAEFER, Hans. Risk based testing. E. Van Veenendaal, The Testing Practitioner 2nd edition, UTN Publishing, ISBN, p , Priorização de - critérios Critérios Alto Importante Moderado Baixo Descrição As funções selecionadas afetam itens críticos relacionados ao desempenho do sistema As funções selecionadas afetam partes importantes para o desempenho do sistema As funçõesselecionadas afetam o desempenho do sistema, mas estratégias de contorno podem ser implementadas para compensar as perdas pelo não atendimento. As funções selecionadas têm efeito observávelno desempenho do sistema, mas somente criam inconvenientes para o usuário IEEE Std IEEE Standard for Software Verification and Validation,

12 Priorização de - exemplo 23 Priorização de Perfil Operacional de uso UC01 UC02 UC03 UC04 UC05 UC06 UC07 UC08 UC09 Adm 20% 20% 20% 20% 0 5% 5% 5% 5% Caixa % Coeficiente de impacto 24 12

13 Priorização de requisitos critérios de aceitação Requisito UC05-Liberação de Acesso UC01-Cadastra Usuário UC02-Consulta Usuário UC03-Altera Usuário UC04-Exclui Usuário UC06-Cadastra Perfil UC07-Consulta Perfil UC08-Exclui Perfil UC09-Altera Perfil Prioridade Alta Importante Importante Importante Importante Baixo Importante Baixo Baixo Critério de aceitação 25 Processo de priorização de requisitos 26 13