Elicitação de requisitos e análise Esta atividade divide-se em dois esforços maiores: Elicitação dos requisitos em si Técnicas de elicitação Análise do que foi elicitado Processo de análise 1
Que é um requisito? Tanto pode ser Uma declaração abstrata de alto nível de um serviço Como uma restrição do sistema Quanto uma especificação funcional matemática detalhada 2
Elicitação de Requisitos Também denominada de descoberta de requisitos Envolve pessoal objetivando descobrir o domínio de aplicação, serviços que devem ser fornecidos bem como restrições Deve envolver usuários finais, gerentes, pessoal envolvido na manutenção, especialistas no domínio, etc. (Stakeholders). 3
Visão dos Requisitos Requisitos do Usuário Declarações em linguagem natural com diagramas de serviços que o sistema deve oferecer e suas restrições operacionais. Escrito para os clientes Requisitos do Sistema Documento estruturado com descrições detalhadas sobre os serviços do sistema. Contrato entre cliente e fornecedor 4
Tipos de Requisitos Requisitos Funcionais Requisitos Não-Funcionais Requisitos de Domínio 5
Requisitos Funcionais Descreve funcionalidade e serviços do sistema Depende do Tipo do software Usuários esperados Tipo do sistema onde o software é usado 6
Exemplos de R.F. [RF001] Usuário pode pesquisar todo ou um sub-conjunto do banco de dados [RF002] Sistema deve oferecer visualizadores apropriados para o usuário ler documentos armazenados [RF003] A todo pedido deve ser associado um identificador único (PID), o qual o usuário pode copiar para a área de armazenamento permanente da conta 7
Exercício Dê alguns exemplos de R.F.s para: 1. Sistema da padaria de pequeno porte; 2. Sistema inteligente de preenchimento do IRPF; 3. Sistema de alocação docente. 8
Requisitos Não-Funcionais Definem propriedades e restrições do sistema (tempo, espaço, etc) Requisitos de processo também podem especificar o uso de determinadas linguagens de programação, método de desenvolvimento Requisitos não-funcionais podem ser mais críticos que requisitos funcionais. Não satisfaz, sistema inútil. 9
Requisitos Não-Funcionais Devido à sua própria definição, requisitos não-funcionais são esperados mensuráveis Assim, deve-se associar forma de medida/referência a cada requisito nãofuncional elicitado 10
Medidas de Requisitos (Não-Funcionais) Propriedade Velocidade Tamanho Facilidade de uso Confiabilidade Robustez Portabilidade Medida Transações processadas/seg Tempo de resposta do usuário/evento K bytes N o de chips de RAM Tempo de treinamento N o de quadros de ajuda Tempo médio de falhas Probabilidade de indisponibilidade Taxa de ocorrência de falhas Tempo de reinício após falha Percentual de eventos causando falhas Probabilidade de corrupção de dados após falha Percentual de declarações dependentes do destino N o de sistemas destino 11
Classificação de R. N. F. Requisitos do Produto Produto deve comportar-se de forma particular (velocidade de execução, confiabilidade, etc.) Requisitos Organizacionais Conseqüência de políticas e procedimentos organizacionais (padrões de processo usados, requisitos de implementação, etc.) Requisitos Externos Conseqüência de fatores externos ao sistema e ao processo de desenvolvimento (legislação, etc.) 12
Exemplos de R. N. F. Requisitos do Produto [RNF001] Toda consulta ao B.D., baseada em código de barras, deve resultar em até 5 s Requisitos Organizacionais [RNF002] Todos os documentos entregues devem seguir o padrão de relatórios XYZ-00 Requisitos Externos [RNF003] Informações pessoais do usuário não devem ser vistas pelos operadores do sistema 13
Exercício Dê alguns exemplos de R.N.F.s para: 1. Sistema da padaria de pequeno porte; 2. Sistema inteligente de preenchimento do IRPF; 3. Sistema de alocação docente. 14
Requisitos de Domínio Derivados do domínio da aplicação e descrevem características do sistema e qualidades que refletem o domínio Podem ser requisitos funcionais novos, restrições sobre requisitos existentes ou computações específicas Se requisitos de domínio não forem satisfeitos, o sistema pode tornar-se impraticável 15
Requisitos de Domínio (Problemas) Entendimento Requisitos são descritos na linguagem do domínio da aplicação Não é entendido pelos engenheiros de software que vão desenvolver a aplicação Implicitude Especialistas no domínio entendem a área tão bem que não tornam todos os requisitos de domínio explícitos 16
Requisitos de Domínio (Exemplo 1) A desaceleração do trem deve ser computada através da fórmula D trem =D controle +D gradiente onde... 17
Exercício Dê alguns exemplos de domínio para: 1. Sistema da padaria de pequeno porte; 2. Sistema inteligente de preenchimento do IRPF; 3. Sistema de alocação docente. 18
Requisitos Requisitos Usuário Sistema Funcionais Não-funcionais Domínio Produto Organização Externo 19
Técnicas de Elicitação Entrevistas Questionários Casos de Uso Jogo de Funções Brainstorming Workshop de Requisitos 20
Entrevistas Técnica direta Pode ser usada na análise do problema e na elicitação de requisitos Objetivo Entender os problemas reais e soluções potenciais das perspectivas dos usuários, clientes, e outros stakeholders 21
Entrevistas Quem são o cliente e o usuário? Possuem necessidades diferentes? Quais são suas Capacidades Backgrounds Ambientes, etc. Qual é o problema? Como é resolvido atualmente? 22
Entrevistas Qual a razão para resolvê-lo? Qual o valor de uma solução bemsucedida? Onde mais uma solução pode ser encontrada? Note que algumas dessas perguntas já foram feitas no estudo de viabilidade. 23
Questionários Aplicabilidade a mercados específicos Onde perguntas são bem definidas Hipóteses Perguntas relevantes podem ser decididas antecipadamente Leitor ouve da maneira desejada Suprime o que é bom sobre análise Úteis após uma entrevista inicial 24
Casos de Uso Discuta com o cliente o que o sistema fará Identique quem interage com o sistema Identique que interfaces o sistema terá 25
Casos de Uso Verifique se não há requisitos faltando Verifique que os desenvolvedores entendem os requisitos Vantagem é ter apelo visual dos requisitos mais relevantes do cliente 26
Engenheiro de requisitos Assume a função do usuário ou cliente Cliente Jogo de Funções Entender o domínio do problema Assume a função do usuário Entender os problemas que podem passar 27
Brainstorming Regras para Brainstorming Estabeleça o objetivo da sessão Gere quantas idéias for possível Deixe sua imaginação livre Não admita críticas ou debates Ajuste e combine as idéias 28
Workshop de Requisitos Põe todos os stakeholders juntos por um período intensivo (focado) Facilitador conduz a reunião Todos têm sua vez de falar Resultados são disponíveis imediatamente Provê um ambiente para aplicar outras técnicas de elicitação 29
Exercício Quais técnicas poderiam ser usadas em: 1. Sistema da padaria de pequeno porte; 2. Sistema inteligente de preenchimento do IRPF; 3. Sistema de alocação docente. 30
Análise de Requisitos Definição e especificação de requisitos 7 8 Documento de requisitos Validação dos requisitos Entrada do processo Entendimento do domínio 1 6 5 Atrib. Prioridade Coleta de requisitos 2 3 4 Resolução de conflito Classificação 31
Entendimento do Domínio Desenvolver sistemas envolve domínios além de software e hardware Podemos ter que entender sobre Contabilidade Saúde Supermercados Etc. 32
Coleta de Requisitos Como vimos anteriormente, a coleta de requisitos é feita através de técnicas Nesta etapa, os requisitos são simplesmente documentados à medida que são coletados Resulta em documento preliminar (draft) 33
Classificação dos Requisitos Esta etapa consiste basicamente em agrupar os diversos requisitos coletados em categorias (clusters) bem-definidos Por exemplo Deve ser possível consultar o preço de uma mercadoria A consulta deve retornar uma resposta em no máximo 5s 34
Problema da Análise de Requisitos Stakeholders em geral não sabem o que querem Stakeholders expressam requisitos em sua terminologia Stakeholders diferentes podem gerar requisitos conflitantes 35
Problema da Análise de Requisitos Fatores políticos e organizacionais podem influenciar os requisitos do sistema Requisitos mudam durante o processo de análise. Stakeholders novos podem surgir e o ambiente de trabalho mudar 36
Resolução de Conflitos É normal que ocorram requisitos conflitantes Por exemplo R-23: O sistema deve... R-45: O sistema não deve... Cliente/usuário deve ser consultado para resolver conflitos (ambigüidades) 37
Atribuição de Prioridade Alguns requisitos são mais urgentes que outros É essencial determinar a prioridade dos requisitos junto ao cliente Requisitos de maior prioridade são considerados em primeiro lugar 38
Prioridade Requisitos podem ser vistos em três classes distintas Essenciais Importantes Desejáveis Em princípio, sistema deve resolver todos os requisitos de essenciais para desejáveis 39
Exemplo de Prioridade [RF001] Consulta X ao B.D. deve retornar dados A, B, C Prioridade: Essencial [RNF001] Consulta X ao B.D. deve visualizar dados segundo padrão Y Prioridade: Importante [RNF010] Consulta X ao B.D. deve usar cores azuis nos resultados Prioridade: Desejável 40
Validação dos Requisitos Será que realmente entendi o que o cliente deseja? Devo me certificar de que não houve falha em nossa interação (comunicação) Há diversas técnicas de validação 41
Validação de Requisitos Demonstrar que os requisitos definem o sistema que o cliente realmente deseja Custos com erros de requisitos são altos Consertar um erro de requisitos após entrega do sistema pode custar mais de 100 vezes o custo de um erro de implementação 42
Técnicas de Validação de Requisitos Revisões de Requisitos Análise manual sistemática dos requisitos Prototipação Uso de modelo executável do sistema para avaliar requisitos Geração de Casos de Teste Desenvolver testes específicos para os requisitos para avaliá-los Análise de Consistência Automática Avaliar uma especificação dos requisitos 43
Gerenciamento de Requisitos Gerenciamento de requisitos é o processo de controlar as mudanças dos requisitos durante O processo da engenharia de requisitos E desenvolvimento do sistema 44
Gerenciamento de Requisitos Requisitos são inevitavelmente incompletos e inconsistentes Requisitos novos surgem durante o processo de acordo com mudanças nas necessidades do negócio e um entendimento melhor do sistema é desenvolvido Diferentes pontos de vista têm diferentes requisitos e esses geralmente são contraditórios 45
Rastreamento Responsável por dependências entre requisitos, suas origens e projeto do sistema Rastreamento de Origem Associação entre requisitos e stakeholders que propuseram tais requisitos 46
Rastreamento Rastreamento de Requisitos Associação entre requisitos dependentes Rastreamento de Projeto Associação dos requisitos com o projeto Usar hipertexto ou referência cruzada Ou matriz de rastreamento 47
Rastreamento Requisitos Produto (Características) Requisitos Detalhados (Casos de Uso) 2 3 Req A 1 Req B 4 1.Rastrear requisitos do usuário nos do sistema 2.Rastrear requisitos no projeto 3.Rastrear requisitos nos procedimentos de teste 4.Rastrear requisitos do usuário no plano Projeto Teste Doc. Usuário Modelos Suítes Teste Plano 48
Rastreamento: Análise de Impacto Req A antes if return value > $5 Req A depois if return value > $2 Req B Req B Req C Req C Links dos requisitos devem ser marcados como revisar Links revisar devem ser analisados 49
Documento de Requisitos Fonte: IEEE/ANSI (830-1998) 1. Introdução 1.1 Propósito do documento 1.2 Escopo do sistema 1.3 Definições, acrônimos e abreviaturas 1.4 Referências 1.5 Descrição do resto do documento 50
Documento de Requisitos Fonte: IEEE/ANSI (830-1998) 2. Descrição geral 2.1 Perspectiva do produto 2.2 Funções do produto 2.3 Características dos usuários 2.4 Restrições gerais 2.5 Assertivas e dependências 51
Documento de Requisitos Fonte: IEEE/ANSI (830-1998) 3. Requisitos específicos requisitos funcionais, não-funcionais, GUI com o usuário: funcionalidade, interfaces externas, desempenho, restrições, atributos do sistema, caract. qualidade,... Apêndices Índice 52