Engenharia de Requisitos de Software. Visão Geral

Transcrição

1 de Software Visão Geral João Sousa Apoio: Desenvolvimento de Sw - Como estamos? Segundo o Standish Group (CHAOS Report 2004): 34% dos projetos com sucesso. 15% dos projetos cancelados antes de completados. 51% dos projetos completados com problemas: Custo adicional médio: 46% Prazo adicional médio: 82% Entrega média: 52% do escopo previsto Nota: Já foi pior!! Veja relatório de 1994 Nota: E não tem melhorado Em % dos projetos com sucesso Slide 2 1

2 Fatores de Sucesso Características normalmente presentes em projetos bem sucedidos: Apoio da alta direção. Stakeholders comprometidos e participando efetivamente do projeto. Definição clara dos requisitos e método controlado de modificações. Processo de desenvolvimento organizado. Estimativas realistas. Gerenciamento efetivo do projeto (incluindo riscos). Slide 3 Disciplinas Uma disciplina é uma coleção de atividades que estão relacionadas a uma área de conhecimento. As disciplinas são: Modelagem de Negócios Requisitos Análise e Design Implementação Teste Implantação Gerência de Configuração e Mudança Gerenciamento de Projeto Slide 4 2

3 Relacionamento entre as Principais Disciplinas orientam Escopo Requisitos Gerência Projetos planeja projetados implementados verificados acompanha Análise e Design construídos Implementação avaliados Testes controlados Gerência de Configuração e Mudança Slide 5 Importância dos Requisitos A parte individual mais difícil da construção de um sistema de software é decidir o que construir. Nenhuma parte do trabalho danifica tanto o sistema resultante se for feita de forma incorreta. Nenhuma outra parte é mais difícil de se consertar depois. Fred Brooks Quanto mais tarde no processo de desenvolvimento um defeito for detectado, maior será o custo para consertá-lo. Estágio Requisitos 1-2 Design 5 Codificação 10 Teste de Unidade 20 Teste de Aceitação 50 Manutenção 200 Custo Relativo Slide 6 3

4 Importância dos Requisitos Problema Real Requisitos Especificação Correta Especificação com Erro Os erros são propagados e aumentam substancialmente quanto mais cedo forem cometidos. Erros em requisitos contribuem para 70% do retrabalho e podem consumir de 25% a 40% do orçamento do projeto. Fonte : Boehm e Papaccio Design Design Correto Design com Erro Design Baseado em Especificação com Erro Implementação Código Correto Código com Erro Código Baseado em Design com Erro Código Baseado em Especificação com Erro Testes Funções Corretas Erros Fácil Correção Erros Difícil Correção Erros Ocultos Slide 7 Requisito - Definição Algo que se deseja ou precisa (Webster s Dictionary) Uma característica que o usuário necessita para resolver um problema ou atingir um objetivo (IEEE Standard) Uma característica que o sistema deve possuir para satisfazer um contrato, padrão ou outro documento formal (IEEE Standard) Slide 8 4

5 Níveis de Abstração - Problema x Solução Visão Especificação Detalhada Necessidades Problema Características Solução (requisitos de alto nível) Requisitos detalhados do software Slide 9 Necessidade Eu preciso me comunicar com outras pessoas, seja por iniciativa minha ou delas, a qualquer tempo, onde quer que eu esteja. Slide 10 5

6 Solução O que diferencia uma solução da outra? Como conhecer essas diferenças? Slide 11 Refinamento de Requisitos Necessidade Acompanhar indicadores de qualidade ao longo do projeto. Visão Sistema de Controle de Defeitos Característica 63: Apresentar graficamente a evolução da quantidade de defeitos ao longo do projeto. Especificação Detalhada Requisito 63.1: Apresentar um relatório de histograma mostrando o tempo no eixo x e o número de defeitos encontrados no eixo y. Requisito 63.2: O usuário pode informar o período a ser apresentado no relatório em uma das seguintes unidades: dias, semanas ou meses. Padrão: semanas Requisito 63.3: O usuário pode informar o conjunto de módulos do sistema que serão considerados no relatório. Padrão: todos. Requisito 63.4: O relatório de histograma deve seguir o formato descrito no apêndice X. Slide 12 6

7 Requisitos Funcionais x Não Funcionais Requisitos Funcionais Funcionalidades disponibilizadas pelo software, de modo a capacitar os usuários a executar suas tarefas e satisfazer às necessidades do negócio. São ações que o produto deve realizar de modo a fornecer funcionalidades úteis para seus usuários. Ex: emitir conta telefônica mensal Requisitos Não Funcionais São propriedades ou qualidades que o produto deve possuir Em sua maioria, não expressam nenhuma função a ser realizada pelo software, e sim necessidades e restrições que o mesmo deve satisfazer. Relacionados com a Arquitetura do Software Ex: desempenho, robustez, facilidade de uso,... Slide 13 Modelo Genérico da Levantamento dos Requisitos Análise e Negociação dos Requisitos Especificação dos Requisitos Verificação e Validação dos Requisitos Gerência dos Requisitos Slide 14 7

8 Levantamento Entender as atividades, os conceitos, os problemas, a cultura e a linguagem dos usuários para construir sistemas que atendam às suas necessidades. Entrevistas Observação / Demonstração Reuniões Estruturadas Brainstorming e Brainwriting Workshops JAD: Joint Application Development... Slide 15 Análise e Negociação Já falei com os interessados. Agora é só escrever os casos de uso, certo? Analisar o que foi levantado: Registrar os problemas / necessidades. Modelar o entendimento sobre o contexto (dados, processos, envolvidos, locais, eventos/ciclos temporais, motivações/regras). Entender a importância relativa das necessidades. Identificar conflitos, inconsistências, omissões. Propor e negociar alternativas de solução. Slide 16 8

9 Especificação Requisitos são especificados de forma que todos os envolvidos possam ter um entendimento comum sobre o que deve ser construído. Como especificar? User Stories Casos de Uso Especificações Tradicionais Preciso mesmo especificar? Nossa memória tem capacidade limitada. Projeto Boeing 777: requisitos!! Slide 17 Refinamento de Requisitos Até que nível de detalhe devemos ir? Definir: Cada entrada e saída Cada validação Cada transformação Os comportamento normais e alternativos Os comportamentos em cada exceção Não se esqueça das questões não funcionais Performance, robustez, confiabilidade, segurança, etc. E a Interface com o Usuário? Nível mais concreto observado pelo usuário. Deve ser validada antes de se investir grande esforço na construção. Processo de Refinamento: Os problemas surgem nos detalhes! Slide 18 9

10 Verificação e Validação Estamos construindo o produto correto? Estamos construindo o produto da forma correta? A especificação é examinada de forma a tentar assegurar que os requisitos foram definidos sem ambigüidades, inconsistências ou omissões, e que todos os defeitos foram detectados e corrigidos. Inspeção e utilização de Checklists Diferentes Perspectivas (Cliente, Testador,...) Protótipos e Maquetes. Slide 19 Gerência de Requisitos Define uma abordagem sistemática para levantar, organizar e documentar as modificações nos requisitos. É executada em paralelo durante todo o processo de desenvolvimento. Fornece instrumentos para apoiar a análise de impacto das mudanças. Verifica a consistência entre os requisitos e todos demais produtos relacionados (código, modelos, cenários de testes,...). Captura de informações de apoio à gerência do projeto: Importância, Risco, Release previsto,... Slide 20 10

11 Controlar as mudanças dos Requisitos Cliente Fornecedor Solicitar Mudança Identificar Requisitos Impactados Definir Impacto da Mudança Aprovar Solicitação de Mudança Estimar Impacto da Mudança Revisar Impacto da Mudança Implementar e Validar Mudança Ferramenta de Workflow para acompanhamento JIRA, ClearQuest,... Slide 21 Rastreabilidade Necessidade Característica Requisito Suplementar Caso de Uso Regra Caso de Teste Módulo Implementação Todos os itens de projeto e implementação partem de um requisito inicial e se identificam com ele! Slide 22 11

12 Processo Conjuntos de atividades definidas Insumos Resultados Papéis Instrumentos de apoio - Ferramentas e uma seqüência estabelecida entre elas pode conter ciclos deve conter possibilidade de paralelismo Define os artefatos que serão desenvolvidos Define quando e como eles serão desenvolvidos (atividades) Define o perfil de quem irá desenvolvê-los Slide 23 Processo Métodos / Técnicas Processo Pessoas habilitadas, treinadas e motivadas Ferramentas / Equipamentos / Tecnologia Slide 24 12

13 Processo de Requisitos Exemplo Necessidades An. Requisito Visão Geral Software Definir Escopo Projeto An. Requisito Lista de Casos de Uso Identificar Comportamento do Software M Aprovação Requisitos Cliente An. Requisto Detalhar Requisitos do Software Casos de Uso Aprovação Detalhamento M Cliente An. Requisito Plano Gerência Requisitos Atributos e Rastreabilidade Gerenciar Requisitos Slide 25 Definir a Visão Geral da Solução Entender o problema a ser resolvido. Identificar os stakeholders e suas necessidades. Definir as fronteiras da solução. Identificar restrições e premissas. Definir características funcionais que o software deve apresentar para atender as necessidades. Definir características suplementares que o software deve apresentar para atender as necessidades. Definir características que poderiam ser aplicáveis, mas que não serão contempladas pelo software. Slide 26 13

14 Caso de Uso O comportamento funcional do software pode ser descrito através da técnica de casos de uso. O comportamento do software é documentado em um modelo de Caso de Uso que ilustra as funcionalidades existentes no software (Casos de Uso), suas fronteiras (Atores) e os relacionamentos entre os Casos de Uso e os Atores (Diagramas de Caso de Uso). Um caso de uso é um curso completo de eventos iniciados por um ator, especificando as interações que ocorrem entre atores e o software, incluindo variações, de modo que um resultado de valor observável seja obtido. O papel mais importante deste modelo é comunicar o comportamento do software aos clientes ou usuários finais. Slide 27 Ator Representa alguém ou alguma coisa que interage com o software. Não fazem parte do software. Eles delimitam os elementos externos ao software. Escreva para cada ator uma breve descrição e defina as suas responsabilidades. Questões: Ator Cliente X Operador? Quem utiliza o sistema? Temporizador x Ator primário Slide 28 14

15 Identificando Casos de Uso Normalmente é difícil decidir se um determinado conjunto de interações constituem apenas um caso de uso ou vários casos de uso. Exemplo: Inserir latas e garrafas Solicitar impressão do recibo Quantos casos de uso você identifica neste exemplo? Slide 29 Decomposição Funcional Quebrar um problema em partes pequenas e isoladas. As partes trabalham juntas para prover a funcionalidade do sistema. Muitas vezes não fazem sentido isoladamente. Casos de Uso: NÃO é decomposição funcional. Mantém a funcionalidade agrupada para descrever um uso completo do sistema. Provê contexto. Mesmo nível de detalhe da decomposição funcional mas estruturados para facilitar o entendimento dos stakeholders Slide 30 15

16 Decomposição Funcional: Um Exemplo Inserir Cartão Entrar PIN Processar Transação Consórcio Bancos Selecionar Conta Destino Selecionar Transferência de Fundos Selecionar Saque Cliente Entrar Montante Selecionar Conta Origem Selecionar Saldo da Conta Slide 31 Evitar Decomposição Funcional Sintomas Casos de uso muito pequenos Muitos casos de uso Casos de uso sem resultado de valor Nomes com operações de baixo nível Operação + objeto Função + dados Exemplo: Inserir cartão Dificuldade em entender o modelo com um todo Ações Corretivas Buscar um contexto maior Por que estamos construindo o sistema? Coloque-se no papel do usuário O que o usuário quer alcançar? O objetivo de quem esse caso de uso satisfaz? Que valor este caso de uso agrega? Slide 32 16

17 Casos de Uso (sem decomposição funcional) Sacar Dinheiro Cliente Transferir Fundos Depositar Fundos Consórcio Bancos Slide 33 Caso de Uso - Atividades de Identificação A identificação dos casos de uso é uma atividade de definição da solução É fundamental contextualizar o motivo da existência de cada caso de uso Entender como os casos de uso colaboram entre si para atender as necessidades e os objetivos da solução Combinar o entendimento funcional e de informações (domínio) Análise do problema para definição da solução Slide 34 17

18 Caso de Uso - Atividades de Identificação Definir Módulos Organizar os casos de uso em pacotes a partir do domínio do problema. Identificar Atores Identificar Casos de Uso Nome e Descrição Resumida Contextualizar o motivo da existência de cada caso de uso Relacionar Casos de Uso identificados com atividades, entidades(domínio) e eventos do negócio. Existe uma ordem de execução desses casos de uso? Representar o ciclo de vida para entidades que tiverem uma dinâmica de estados significativa. Slide 35 Elaborar Modelo de Domínio (Conceitual) Conferência Edição da Conferência 1 0..* 0..* 0..* Tópico de Interesse 1 * Remetente Pessoa Autor 1 * * Artigo * +classicado em * * Slide 36 18

19 Elaborar Modelo de Domínio (Estados) Visão Dinâmica da Entidade de Negócio Artigo UC - Cancelar Submissão UC - Submeter Artigo UC - Submeter Artigo Com Pendência Submetido UC - Cancelar Submissão Cancelado UC - Realizar Triagem Artigo : [ Artigo Não OK ] UC - Realizar Triagem Artigo : [ Artigo OK ] UC - Cancelar Submissão Liberado para Distribuição Slide 37 Casos de Uso Um caso de uso descreve um conjunto de caminhos que podem ser seguidos durante a utilização do sistema em um determinado contexto. Ex: Registrar Venda A) Venda normal B) Produto não está disponível C) Cancelamento de Item D) Cancelamento da Venda Fluxo normal e Fluxos alternativos/exceções Slide 38 19

20 Casos de Uso X Cenários Cenário de utilização é a descrição de uma situação real que os usuários do software poderão encontrar. Cada caso de uso está relacionado com uma coleção de cenários. Explorar os cenários auxilia na definição dos Casos de Uso. Cenários (concreto) x Caso de Uso (abstração). Slide 39 Cenários - Exemplo Caso de Uso Empréstimo de Filme - Cenário 1 O sócio José de matrícula 111 solicita o empréstimo do filme Avatar. O sócio não está com saldo devedor. O sócio não possui outros filmes emprestados em seu poder. Existem cópias do filme disponíveis (não estão nem emprestadas e nem reservadas por outro sócio). Slide 40 20

21 Cenários - Exemplo Caso de Uso Empréstimo de Filme - Cenário 2 O sócio José de matrícula 111 solicita o empréstimo do filme Avatar. O sócio não está com saldo devedor. O sócio possui cinco outros filmes emprestados em seu poder. Existem cópias do filme disponíveis (não estão nem emprestadas e nem reservadas por outro sócio). Slide 41 Cenários - Exemplo Caso de Uso Empréstimo de Filme - Cenário 3 O sócio José de matrícula 111 solicita o empréstimo do filme Avatar. O sócio não está com saldo devedor. O sócio não possui outros filmes emprestados em seu poder. Não existem cópias do filme disponíveis (todas as cópias estão emprestadas ou reservadas por outros sócios). Slide 42 21

22 Formato da Especificação de Caso de Uso Vários formatos foram propostos por diferentes autores Componentes Principais Identificador do Caso de Uso (ID) Nome do Caso de Uso Descrição ou Resumo Objetivo do Caso de Uso Atores Participantes Pré-condições Pós-condições Fluxos de Eventos Fluxo Normal Sub-Fluxos Fluxos Alternativos Fluxos de Exceção Slide 43 Formato da Especificação de Caso de Uso Componentes Auxiliares Outros requisitos (tipicamente requisitos não funcionais) Regras de Negócio (específicas desse caso de uso) Dados (detalhamento dos fluxos de dados utilizados em diferentes pontos do caso de uso) Detalhamento das Interfaces Alternativas para os componentes auxiliares: Seção específica na descrição detalhada do caso de uso para os itens que relacionados só a um caso de uso específico. Documento específico para os itens relacionados a vários casos de uso. Repositório Corporativo (baseado em SGBD) melhor Slide 44 22

23 Formas de Detalhamento dos Fluxos Passos numerados com rótulos IDENTIFICAÇÃO DO SÓCIO 1. Atendente solicita ao sistema iniciar o registro de um aluguel de cópias. 2. Sistema solicita a identificação do sócio que está alugando as cópias. 3. Atendente informa o código do sócio. 4. Sistema verifica que o código informado corresponde a um sócio que pode alugar cópias. 5. Sistema apresenta o número máximo de cópias que o sócio pode levar. Slide 45 Formas de Detalhamento dos Fluxos Passos numerados com rótulos (estilo jornal) IDENTIFICAÇÃO DAS CÓPIAS 6. Atendente informa a identificação de cada cópia a ser alugada. 7. A cada cópia informada, o sistema apresenta o título do filme correspondente, o preço de aluguel da cópia e o valor total do aluguel. PAGAMENTO 8. Atendente informa o valor pago pelo sócio e confirma o aluguel. 9. Sistema emite o comprovante de aluguel de cópias. 10. O sistema registra as informações do aluguel realizado e o caso de uso se encerra. Slide 46 23

24 O que descrever nos Fluxos? Como e quando o caso de uso é iniciado Atendente solicita ao sistema iniciar o registro de um aluguel de cópias. Informações/eventos que são trocados entre um ator e o sistema Atendente informa a identificação de cada cópia a ser alugada. (Ação do Ator) Sistema apresenta o nome do filme correspondente, o preço de aluguel da cópia e o valor total devido (Resposta Externa) Armazenamento/Atualização de informações no sistema O sistema registra as informações do aluguel realizado. (Resposta interna) Indicação de verificações realizadas pelo sistema Sistema verifica que o código informado corresponde a um sócio que pode alugar cópias (Verificação). Como e quando o caso de uso termina Slide 47 Especificação Tudo se resume a especificar casos de uso? RNF GUI Caso de Uso Interações (Fluxos) Dados Regras 48 Slide 48 24

25 Recomendações Gerais Use um estilo consistente e padronizado de descrição (trabalho em equipe). Explore todos os cenários possíveis Evite advérbios e adjetivos (muito, mais, melhor,...). Cuidado com pronomes (seu, sua, dele,...) Evite utilizar termos que representem elementos concretos de interface com o usuário (botão, listbox, clicar,...) Seja conciso e objetivo Dilema - Diferentes perspectivas de detalhamento Comunicar ao usuário o funcionamento do software Comunicar aos desenvolvedores as funcionalidades a serem desenvolvidas Roteiro para os testes Documentar o Software Slide 49 Referências Managing Software Requirements: A Use Case Approach, Second Edition. Leffingwell, D.; Widrig, D. Addison-Wesley Pub Co, ISBN: X. Software Requirements, Second Edition. Wiegers, K. Microsoft Press, ISBN: Use Case Modeling. Bittner, K; Spence, I. Addison-Wesley Pub Co, ISBN: Writing Effective Use Cases. Cockburn, A. Addison-Wesley Pub Co, ISBN: Slide 50 25