Engenharia de Requisitos de Software

Transcrição

1 Engenharia de Requisitos de Software Marcelo Otone Aguiar, MSc, PMP PROJETOS 1

2 O que é Projeto Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. PMI (2008) O que é um Projeto? Projeto é um empreendimento não repetitivo, caracterizado por uma sequência clara e lógica de eventos, com início, meio e fim, que se destina a atingir um objetivo claro e definido, sendo conduzido por pessoas dentro de parâmetros predefinidos de tempo, custo, recursos envolvidos e qualidade. VIANA (2003) 2

3 Exemplos de Projeto Desenvolvimento de um novo produto ou serviço; Efetuar uma mudança de estrutura, de pessoal ou de estilo de uma organização; Desenvolvimento ou aquisição de um sistema de informações novo ou modificado; Construção de prédio ou infraestrutura; Implementação de um novo procedimento ou processo de negócios. Sucesso em Projetos O que é um projeto bem sucedido? O projeto ficou abaixo do orçamento previsto? O projeto terminou mais rápido? O projeto consumiu menos materiais e pessoas? O cliente ficou surpreendido pela qualidade do resultado do projeto? 3

4 Sucesso em Projetos Um projeto bem-sucedido é aquele que é realizado conforme o planejado. (VARGAS, 2011, p. 24) O sucesso está em atingir o planejado; O planejado deverá então atender as expectativas dos interessados nos resultados do projeto; Porque os projetos falham? Frequência na qual os Projetos têm Alcançado o Sucesso, em Termos de Prazo, Custo, Qualidade e Satisfação do Cliente (interno ou externo) 34% 66% Sempre ou na maioria das vezes Poucas vezes ou nunca Fonte: Adaptado de PMI Brasil (2010) 4

5 Porque os projetos falham? A Organização costuma ter problemas no cumprimento dos Prazos estabelecidos para os projetos 22% 78% Sim Não Fonte: Adaptado de PMI Brasil (2010) Porque os projetos falham? A Organização costuma ter problemas no cumprimento dos Custos estabelecidos para os projetos 39% 61% Sim Não Fonte: Adaptado de PMI Brasil (2010) 5

6 Porque os projetos falham? A Organização costuma ter problemas de Qualidade em seus projetos 44% 56% Sim Não Fonte: Adaptado de PMI Brasil (2010) Porque os projetos falham? Metas e objetivos mal estabelecidos; Pouco compreensão da complexidade do projeto; Projeto com muitas atividades, mas, pouco tempo para realizar; Estimativas financeiras pobres e incompletas; Projeto com informações insuficientes ou incompletas; Sistema de controle inadequado; VARGAS (2011) 6

7 Porque os projetos falham? Projeto sem gerente de projetos ou com vários gerentes em paralelo; Dependência no uso de softwares de gestão de projetos; Projeto estimado com base na experiência empírica, ou feelingdos envolvidos, deixando em segundo plano os dados históricos ou análises estatísticas; Treinamento e capacitação inadequados; VARGAS (2011) Porque os projetos falham? Faltou liderança do gerente de projeto; Não foi destinado tempo para estimativa e planejamento; Não se conhecia as necessidades de pessoal, equipamentos e materiais; Fracassou a integração dos elementos-chave do escopo do projeto; Cliente tinha expectativas distintas. VARGAS (2011) 7

8 Partes Interessadas (stakeholders) Fonte: Adaptado de PMBOK (2008) Partes Interessadas Clientes/Usuários: pessoas ou organizações que usarão o produto, serviço ou resultado do projeto; Patrocinador(Sponsor): a pessoa ou grupo que fornece os recursos financeiros para o projeto; Escritório de Projetos (PMO), Gerente de Projetos, Gerentes de Portfólio, Gerentes de Programas, Equipe do Projeto, Gerentes Funcionais, Fornecedores e Parceiros. 8

9 O que é Escopo Escopo, emgerenciamento de projetos, é a soma total de todos os produtos do projeto e seusrequisitosoucaracterísticas, e possui dois usos distintos: Escopo do Projeto e Escopo do Produto. VARGAS (2009) Escopo do Projeto é "o trabalho que precisa ser realizado para entregar um produto, serviço ou resultado com as características e funções especificadas." PMI (2008) 9

10 Escopo do Produto são "as características e funções que caracterizam o produto, serviço ou resultado." PMI (2008) Restrições do Projeto Satisfação do Cliente Restrições do Projeto Fonte: Mulcahy (2009, p. 25) 10

11 O que é Gerenciamento do Escopo Gerenciamento do Escopo É o controle dos trabalhos a serem realizados no projeto garantindo o cumprimento das necessidades do cliente em relação ao produto, ou serviço, a serem desenvolvidos pelo projeto. Vargas (2009) salienta que é papel do gerenciamento de escopo do projeto proporcionar o uso otimizado do esforço, sem abandonar nenhuma premissa estabelecida nos objetivos do projeto. 11

12 Limites do projeto Fonte: Adaptado de PMBOK (2008) Complexidade dos Projetos Detalhamento do escopo X complexidade no gerenciamento Fonte: Vargas (2009, p. 57) 12

13 Complexidade dos Projetos A relação entre as partes interessadas e o projeto Fonte: PMI (2008, p. 24) Ciclo de Vida do Projeto Fonte: Adaptado de PMBOK (2008) 13

14 Trabalho Supérfluo (gold plating) Significa entregar adicionais ao cliente, como: Funcionalidade não solicitadas Componentes com qualidade mais elevada Escopo adicional Desempenho melhor do que o especificado Os projetos tem dificuldade em atender aos objetivos do cliente, de forma que, o esforço disponível deve ser usado para alcançar tais objetivos; MULCAHY (2009) 14

15 Gerenciamento do Escopo inclui: Coletar Requisitos Definir o Escopo Controlar o Escopo Criar a EAP Verificar o Escopo Grupos de Processos Fonte: Adaptado de PMBOK (2008) 15

16 Ciclo de Vida do Projeto Fonte: Adaptado de PMBOK (2008) Ciclo de Vida do Projeto Fonte: Adaptado de PMBOK (2008) 16

17 REQUISITOS Engenharia de Requisitos Objetivo Criar e manter um documento de requisitos Possui 4 subprocessos Estudo de viabilidade Vale a pena? Elicitação e análise de requisitos Obtenção de requisitos Especificação Colocar requisitos em algum formato padrão Validação de requisitos É isso que o cliente quer? 17

18 Engenharia de Requisitos Visão tradicional Estudo de Viabilidade Relatório de Viabilidade Elicitaçãoe Análise de Requisitos Especificação de Requisitos Validação de Requisitos Modelos de Sistema Requisitos de Usuário e de Sistema Documento de Requisitos Engenharia de Requisitos Estudo de viabilidade Atividade breve para responder Em que o sistema contribui? Pode ser implementado na tecnologia atual? Restrições de prazo e custos Pode ser integrado com outros sistemas? Atividade da fase de concepção Produz Relatório de Viabilidade 18

19 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 O 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 19

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

21 Tipos de Requisitos Requisitos Funcionais Requisitos Não-Funcionais Requisitos de Domínio Requisitos Funcionais Descreve funcionalidade e serviços do sistema Depende do Tipo do software Usuários esperados Tipo do sistema onde o software é usado 21

22 Exemplos de R.F. [RF001] Usuário pode pesquisar todo ou um subconjunto 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 Exercício Dê alguns exemplos de requisitos funcionais para: 1. Sistema da padaria de pequeno porte; 2. Sistema inteligente de preenchimento do IRPF; 3. Sistema de alocação docente. 22

23 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. Requisitos Não-Funcionais Devido à sua própria definição, requisitos nãofuncionais são esperados mensuráveis Assim, deve-se associar forma de medida/referência a cada requisito nãofuncional elicitado 23

24 Velocidade Tamanho Propriedade Facilidade de uso Confiabilidade Robustez Portabilidade Medidas de Requisitos (Não-Funcionais) 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 no destino 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.) 24

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

26 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 não prático 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 26

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

28 Requisitos Requisitos Usuário = df Sistema Funcionais Não-funcionais Domínio Produto Organização Externo Técnicas de Elicitação Entrevistas Questionários Casosde Uso Jogo de Funções Brainstorming Workshop de Requisitos 28

29 Jogo de Funções Engenheiro de requisitos Assume a função do usuário ou cliente Entender o domínio do problema Cliente Assume a função do usuário Entender os problemas que podem passar 57 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 58 29

30 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 59 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 Atrib. Prioridade Coleta de requisitos Resolução de conflito Classificação 30

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

32 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 Problema da Análise de Requisitos Stakeholdersem geral não sabem o que querem Stakeholdersexpressam requisitos em sua terminologia Stakeholdersdiferentes podem gerar requisitos conflitantes 32

33 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 muda 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 consulta para resolver conflitos (ambiguidades) 33

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

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

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

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

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

39 Rastreamento Requisitos Produto (Caracter.) Requisitos Detalhados (Casos de Uso) Req A 1 Req B Rastrearrequisitosdo usuário nos do sistema 2.Rastrearrequisitosno projeto 3. Rastrear requisitos nos procedimentos de teste 4.Rastrear requisitosdo usuário no plano Projeto Modelos Teste Suítes Teste Doc. Usuário Plano 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 39

40 Documento de Requisitos 1. Introdução 1.1 Propósito do documento 1.2 Escopodo sistema 1.3 Definições, acrônimos e abreviaturas 1.4 Referências 1.5 Descrição do resto do documento Documento de Requisitos 2. Descrição geral 2.1 Perspectiva do produto 2.2 Funçõesdo produto 2.3 Características dos usuários 2.4 Restrições gerais 2.5 Premissas e dependências 40

41 Documento de Requisitos 3. Requisitos específicos requisitosfuncionais, não-funcionais, GUI com o usuário: funcionalidade, interfaces externas, desempenho, restrições, atributosdo sistema, caract. qualidade,... Apêndices Índice 41