Agenda. Agenda. Gerência de Requisitos Estratégia Tecnologia da Informação Ltda 2

Transcrição

1

2 Agenda Requisitos na Engenharia de Software Processo de Engenharia de Requisitos (E.R.) Comunicação e Entendimento t de Requisitos it Documentação de Requisitos Aceitação de Requisitos Rastreabilidade d de Requisitos it Consistência de Requisitos Mudanças em Requisitos Agenda Estratégia Tecnologia da Informação Ltda 2

3 Motivação Requisitos são a base para aferição da qualidade Todos os modelos de processo indicam a Gerência de Requisitos como um passo inicial A experiência mostra que o investimento em qualidade de requisitos tem excelente retorno Satisfação dos envolvidos Menos re-trabalho Maior produtividade Estratégia Tecnologia da Informação Ltda 3

4 Estratégia Tecnologia da Informação Ltda 4

5 Definição de Requisito Segundo o Dicionário Aurélio (1) condição necessária para a obtenção de certo objetivo Um requisito para se ingressar no programa de mestrado da UFG é ter um diploma de graduação reconhecido pelo MEC (2) exigência legal Um requisito para se emitir uma carteira de motorista para os brasileiros é ter 18 anos de idade, ou mais Estratégia Tecnologia da Informação Ltda 5

6 Um Requisito em Software é (1) uma condição ou capacidade de que um usuário necessita para resolver um problema ou atingir um objetivo O usuário necessita imprimir uma nota fiscal (2) uma condição ou capacidade que precisa ser atingida por um sistema para satisfazer um contrato, norma, especificação ou algum outro documento Os cálculos efetuados pelo sistema devem ter uma precisão mínima de 20 casas decimais IEEE Standard Computer Dictionary Estratégia Tecnologia da Informação Ltda 6

7 Requisito ou Restrição? Requisitos costumam ser associados a uma necessidade específica do usuário que o sistema deve atender O sistema deve ser capaz de emitir boleto de cobrança com código de barras uma restrição que o projeto ou o produto (sistema) dele resultante deve obedecer Tamanho máximo do código-objetoobjeto deve ser 16Kbytes A requirement is a statement of a system service or constraint Kotonya and Sommerville, 1998 Estratégia Tecnologia da Informação Ltda 7

8 Quem define Requisitos? Todos os envolvidos (stakeholders) em um projeto de software têm requisitos Gerentes, diretores, desenvolvedores, testadores, projetistas, etc. Cada envolvido possui expectativas e necessidades que o projeto ou o produto (sistema) dele resultante deve obedecer Requisitos devem refletir as necessidades dos envolvidos, e não apenas dos usuários Estratégia Tecnologia da Informação Ltda 8

9 Requisitos na Engenharia de Software Requisitos definem como o sistema será construído Os recursos do projeto devem ser especificados em função dos requisitos que devem ser atendidos o que o sistema deve fazer O problema que o software precisa resolver deve ser entendido e representado em termos de requisitos em que condições o sistema deve operar O ambiente de operação e o comportamento que o sistema deve realizar devem ser claramente definidos como requisitos Estratégia Tecnologia da Informação Ltda 9

10 Engenharia de Requisitos A Engenharia de Requisitos (ER) pesquisa abordagens para controlar requisitos A disciplina de ER envolve diversos processos 1)) Elicitação (identificação) 2) Análise (modelagem e negociação) 3) Documentação (especificação) 4) Avaliação (validação) 5) Estratégia Tecnologia da Informação Ltda 10

11 Contexto da ER Platão O início é a parte mais importante do trabalho Aquisição de Sistema Engenharia de Requisitos Projeto de Sistema Estratégia Tecnologia da Informação Ltda 11

12 Erros em requisitos causam atraso (ou cancelamento) da entrega do sistema software que não atende as necessidades dos envolvidos Erros em requisitos são causados por falta de compreensão mudanças descontroladas A é responsável por minimizar esses erros Ela cuida da execução eficiente dos diversos processos da ER Garante mudança controlada Estratégia Tecnologia da Informação Ltda 12

13 Problemas relacionados a requisitos Sintomas Possíveis Causas Práticas Recomendadas Não atendimento das necessidades d dos usuários Interpretação incorreta dos requisitos; it ambigüidade; d comunicação deficiente Modelagem Visual WYSIWYG Protótipos Produto sem Instabilidade ou Aprovação e Controle de qualidade insuficiência de Mudanças em Requisitos requisitos Prejuízos ou pendências Mudanças no escopo Análise de impacto de judiciais do software Mudanças em Requisitos Estratégia Tecnologia da Informação Ltda 13

14 Taxonomias de Requisitos Existem inúmeras classificações de requisitos Muitas delas são incompatíveis entre si O importante é não omitir requisitos As classes de requisitos devem englobar todas as possibilidades Requisitos são inicialmente alocados ao Sistema de Informação A Engenharia de Sistemas distribui os requisitos entre os vários componentes do sistema Estratégia Tecnologia da Informação Ltda 14

15 Exemplos de Requisitos de Sistema O sistema deve manter registros de materiais bibliográficos, incluindo livros, periódicos, jornais e revistas, vídeos e áudio, relatórios, slides, CDs e DVDs permitir consulta por título, autor ou ISBN oferecer acesso via browser suportar pelo menos 20 transações por segundo ser demonstrável para o público cliente da biblioteca em no máximo 10 minutos Estratégia Tecnologia da Informação Ltda 15

16 Tipos de Requisitos de Software Requisitos Genéricos Apresentam uma visão geral do sistema O sistema deve manter registros de todos os materiais da Locadora incluindo fitas de vídeo, DVD e cartuchos de jogos Requisitos Funcionais Especificam a funcionalidade do sistema O sistema deve permitir que o usuário procure uma fita por título, diretor, ator, ou categoria de filme. Requisitos de Implementação Definem como o sistema deve ser implementado O sistema precisa estar disponível na Web Estratégia Tecnologia da Informação Ltda 16

17 Tipos de Requisitos de Software Requisitos de Desempenho São restrições sobre a velocidade de execução O sistema deve atender pelo menos 10 transações por segundo Requisitos de Usabilidade Descrevem como o sistema deve ser usado As funções disponíveis para o público devem ser demonstráveis em menos de 10 minutos Requisitos de Segurança São restrições sobre o acesso e a guarda do software O acesso ao sistema deve ser controlado por senha. A freqüência de backup deve ser diária. Estratégia Tecnologia da Informação Ltda 17

18 Outras Taxonomias de Requisitos Requisitos Funcionais O que e quando o sistema deve realizar? Existem diferentes modos de operação? Requisitos de Documentação Qual a documentação que o sistema deve gerar? Para quem? E em que formato? Requisitos de Dados Qual o formato utilizado para entrada e saída? Os dados devem ser mantidos por qual período? Qual a correção e precisão de cálculos necessárias? Requisitos it de Interface Existe interação com outro(s) sistema(s)? Estratégia Tecnologia da Informação Ltda 18

19 Outras Taxonomias de Requisitos Requisitos de Qualidade em que grau os requisitos de qualidade referente à eficiência, utilizabilidade, manutenibilidade, confiabilidade e portabilidade devem ser satisfeitos Requisitos de Ambiente Físico Onde o sistema vai funcionar? Será em apenas um local ou vários? Há restrições ambientais (ex: temperatura, umidade, etc)? Fatores humanos (requisitos de uso) Quem vai usar o sistema? Existem diferentes tipos de usuário? Algum tem necessidades especiais? Há padrões de IHC? Qual o nível de experiência de cada usuário? Que tipo de treinamento deve ser realizado? Estratégia Tecnologia da Informação Ltda 19

20 Outras Taxonomias de Requisitos Propriedades Emergentes Requisitos do sistema que só aparecem quando todos os subsistemas são integrados Confiabilidade Manutenibilidade Desempenho Usabilidade Segurança Restrição de Acesso Estratégia Tecnologia da Informação Ltda 20

21 Dificuldades com Requisitos Estabelecer uma compreensão homogênea na equipe de desenvolvimento Equipe compreende técnicos e usuários envolvidos Refletir as reais necessidades dos usuários e do negócio Garantir consistência e/ou completitude Modificar requisitos it que já foram acordados d Isto vai acontecer! Controlar custos de desenvolvimento de requisitos de 15 a 40 por cento do orçamento e do cronograma de desenvolvimento! O que fazer? Engenharia de Requisitos! Estratégia Tecnologia da Informação Ltda 21

22 Processo de Engenharia de Requisitos Um Processo de Engenharia de Requisitos é um conjunto de atividades estruturadas para desenvolvimento de requisitos de sistemas Não há um Processo Ideal O Processo deve ser adequado para as necessidades de cada organização Idealmente, os processos de requisitos e de projeto de software deveriam ser separados Na prática isto é, em geral, impossível É preciso gerenciar mudanças de requisitos! Estratégia Tecnologia da Informação Ltda 22

23 Gerenciar Requisitos Necessidades Problema Espaço do problema Características Use-cases e requisitos Produto a ser construído Testes Design Doc. usuário Espaço da solução Estratégia Tecnologia da Informação Ltda 23

24 Gerenciamento de Requisitos Acompanha a tradução das solicitações dos clientes e usuários em um conjunto de necessidades e características (features) do sistema Detalhados, por sua vez, em especificações de requisitos funcionais e não-funcionais Estas especificações detalhadas são traduzidas em procedimentos de teste, design e documentação do usuário Garante a correspondência (traceability) entre produtos, permitindo Avaliar o impacto em uma mudança de requisitos Avaliar o impacto em uma falha de teste t de requisitos it Gerenciar o escopo do projeto Verificar se os requisitos estão sendo atendidos pela implementação Verificar se a aplicação só faz o que realmente foi proposto Gerenciar mudanças Estratégia Tecnologia da Informação Ltda 24

25 O Processo de Engenharia de Sistemas System requirements engineering System validation Architectural design System integration Requirements Sub-system partitioning patto development Software requirements engineering Estratégia Tecnologia da Informação Ltda 25

26 O Processo de Engenharia de Sistemas Engenharia de Requisitos de Sistema Estabelece os requisitos para o Sistema de Informação de forma compreensível para todos os envolvidos Projeto Arquitetural Decompõe o sistema em subsistemas Particionamento de Requisitos Aloca requisitos aos subsistemas Engenharia de Requisitos de Software Deriva requisitos mais detalhados para o(s) subsistema(s) de software Estratégia Tecnologia da Informação Ltda 26

27 O Processo de Engenharia de Sistemas Desenvolvimento de subsistema Subsistemas de hardware e software são projetados e implementados em paralelo Integração de Sistema Subsistemas de hardware e software são integrados para formar o Sistema de Informação Validação de Sistema O Sistema de Informação é validado d com relação aos requisitos definidos Estratégia Tecnologia da Informação Ltda 27

28 Engenharia de Sistemas O que é? Software é parte de um sistema. As demais partes também devem ser ser identificadas, requisitos eliciados, analisados, especificados, modeladas e validadas. Quem faz? Engenheiros de sistemas visam compreender os re- quisitos junto aos clientes/usuários. Por que é importante? Não se vê a floresta pelas árvores Quais são os passos? Objetivos e requisitos operacionais são eliciados. Uma especificação é produzida e validada. Controle é exercido sobre mudanças. Qual o resultado? Represen- tação do sistema. Fornece características operacionais, funcionais, comportamentais e visão da arquitetura. Como assegurar que fiz corretamente? Elicie os requisitos, avalie-os alie quanto à clareza, completitude e consistência. Estratégia Tecnologia da Informação Ltda 28

29 Motivação Nada é mais difícil e incerto do que conduzir a introdução de uma nova ordem de coisas. Machiavelli Estratégia Tecnologia da Informação Ltda 29

30 Engenharia de sistemas Objetivo Analisar ProjetarP j t Organizar elementos de um sistema Sistema pode ser Serviço Produto Tecnologia... que transforma ou controla informação (sistema baseado em computador) Estratégia Tecnologia da Informação Ltda 30

31 Objetivos em detalhes Engenharia de Sistema Colocar software em um contexto Atribuir um papel para software Conectar software com demais elementos Estratégia Tecnologia da Informação Ltda 31

32 É importante entender o contexto (fato) Engenharia de Sistema Inclui Engenharia de Software (conseqüência) Estratégia Tecnologia da Informação Ltda 32

33 Linha do tempo Engenharia de Sistema Engenharia de Software Estratégia Tecnologia da Informação Ltda 33

34 Ênfase da Engenharia de Sistemas Sistemas Educacionais Sistemas de Segurança Sistemas Políticos,... SISTEMAS BASEADOS EM COMPUTADOR (SBC) Estratégia Tecnologia da Informação Ltda 34

35 Sistema baseado em computador (SBC) Conjunto ou arranjo de elementos cujo objetivo beneficia-se do processamento de informações Elementos de SBCs: Software (programas, dados, documentos) Hardware Pessoas (usuários e operadores) Bases de dados (coleção de informações) Documentação (descrição do sistema) Procedimentos (define uso de cada elemento) Software Engenheiro de Software Estratégia Tecnologia da Informação Ltda 35

36 Engenheiro de Sistemas Pode definir vários modelos: uma solução completamente automatizada, uma semiautomatizada ou uma não automatizada Influência relativa dos elementos (pessoas, software e hardware) varia conforme o modelo Estratégia Tecnologia da Informação Ltda 36

37 SBC Software é um dos elementos cujas interações realizam trabalho útil Pessoas Hardware BD Software Procedimentos Estratégia Tecnologia da Informação Ltda 37

38 Engenharia de Sistema (tipos) SBC apóia Empresa comercial Engenharia de processos de negócios SBC é parte de Produto Engenharia de produtos (produção) Estratégia Tecnologia da Informação Ltda 38

39 Exemplos Engenharia de processos de negócios Sistema de Informação para auxiliar o departamento de pessoal SI para auxiliar o controle de estoque SI para auxiliar o cadastro de clientes Engenharia de produtos (produção) Software de controle de automóvel Software de controle de um robô Software de central telefônica Estratégia Tecnologia da Informação Ltda 39

40 Hierarquia da engenharia de sistemas Domínio de interesse Elemento de sistema Engenharia de Software Negócio ou produto Visão do mundo (supermercado) Visão do domínio (vendas) Visão de elemento (software de caixa) Visão detalhada (interface com leitora ótica) Estratégia Tecnologia da Informação Ltda 40

41 Sistema versus Software Não se seduza por visão centrada em software Considere todos os elementos do sistema antes de se concentrar no software Sistemas complexos são uma hierarquia de macro elementos que também são sistemas Uma boa engenharia de sistemas inicia-se com uma clara compreensão do contexto a visão do mundo e então progressivamente o foco se estreita até que os detalhes técnicos sejam compreendidos Estratégia Tecnologia da Informação Ltda 41

42 Engenharia de Sistemas Processo de Modelagem Modelos são criados para... Definir e representar processos Representar suposições Definir componentes exógenos e endógenos Representar ligações Comunicar o entendimento sobre o assunto Registrar compreensão compartilhada Estratégia Tecnologia da Informação Ltda 42

43 Simulação de sistemas Simulação envolve Quais os dados (objetos do negócio)? Quais os relacionamentos entre eles? Como os dados fluem na empresa? Por que simular? Eliminar problemas, reduzir custos Otimizar o processo, eliminar incertezas Estratégia Tecnologia da Informação Ltda 43

44 Engenharia de Processos de Negócios Negócio que efetivamente t usa informação Analisar e Projetar Dados e relacionamentos (p. ex.: cliente e produto) Softwares que transformam dados Infra-estrutura tecnológica (hardware e software) O que é preciso? Definição da hierarquia de atividades para o negócio Estratégia Tecnologia da Informação Ltda 44

45 Engenharia de Processos de Negócios Linha do tempo Engenharia de Sistema Planejamento estratégico de informação Análise de Área do Negócio Engenharia de Software (definição de requisitos de SI) Estratégia Tecnologia da Informação Ltda 45

46 Hierarquia Engenharia de Processos de Negócios Visão do mundo Empresa Planejamento estratégico de informação Visão de domínio área Análise de área de negócio Sistema de informação Visãodeelementos elementos Visão detalhada Engenharia de software Estratégia Tecnologia da Informação Ltda 46

47 Engenharia de Processos de Negócios Visão de mundo Planejamento estratégico de informação Todo o negócio é visto como uma entidade Identifica domínios (finanças, vendas,...) Define dados d visíveis i a todos Define relacionamento entre os dados Define como fluem os dados entre domínios Define objetivos Isola fatores de sucesso Estratégia Tecnologia da Informação Ltda 47

48 Engenharia de Processos de Negócios Visão do domínio Análise de área de negócio Detalhes de dados Requisitos funcionais Identificados por domínio Responde ao que é exigido em um negócio Reduz o escopo do planejamento estratégico Objetivo Isolar oportunidade de sistema de informação A partir deste ponto... a Engenharia de Software conduz Estratégia Tecnologia da Informação Ltda 48

49 Engenharia de Processos de Negócios Observação Engenheiro de software não se envolve em geral com Planejamento Estratégico té de Informação (PEI) Análise de Área do Negócio (AAN) Engenheiro de software envolve-se com Definição de requisitos de SI (suporte ao negócio) Se não foram realizadas Então o risco do projeto é muito alto! Estratégia Tecnologia da Informação Ltda 49

50 Engenharia de Processos de Negócios Resumo Visão do Mundo Visão de Domínio Visão de Elemento Planejamento estratégico de informação Objetivos estratégicos Fatores de sucesso Modelo da empresa é criado Análise de área de negócio Serviços e processos são modelados São estabelecidos relacionamentos entre eles Engenharia de software Análise, Projeto, Construção,... Estratégia Tecnologia da Informação Ltda 50

51 Engenharia de produtos Traduzir desejos do cliente em um produto Software, hardware, dados e pessoas (definir) Infra-estrutura de suporte Tecnologia para conectar componentes Documentos, vídeos,... Visão de mundo engenharia de requisitos Visão de domínio Componentes do sistema (hardware, software,...) Estratégia Tecnologia da Informação Ltda 51

52 Hierarquia Visão do mundo Engenharia de Produtos Produto Engenharia de requisitos Visão de domínio hardware software dados pessoas Engenharia de componentes Visão de elementos Visão detalhada função dados Comportamento Análise Projeto Construção Engenharia de software Componente de programa Estratégia Tecnologia da Informação Ltda 52

53 Problema em aberto Como assegurar que a especificação do sistema atende as necessidades dos clientes? Engenharia de Requisitos Mecanismos para entender o que o cliente deseja, analisar necessidades, avaliar a exeqüibilidade, negociar uma solução razoável, especificar solução não-ambígua, validar a especificação e gerenciar requisitos Software Requirements Engineering Thayer and Dorfman, IEEE Press, 1997 Estratégia Tecnologia da Informação Ltda 53

54 Eliciar requisitos Não é simples? Basta perguntar ao cliente, ao usuário,... e registrar as informações obtidas Por que é difícil? Fronteiras do sistema mal definidas Clientes não estão seguros do que precisam Clientes não entendem as capacidades e limitações do ambiente computacional Clientes omitem informações óbvias Clientes especificam requisitos it contraditórios i com outros Requisitos mudam com o tempo Estratégia Tecnologia da Informação Ltda 54

55 Eliciar requisitos Existem diretrizes i para eliminar i tais problemas Avaliar a viabilidade técnica Identificar pessoas que conhecem a organização Identificar restrições,... Existem métodos IBIS, JAD, CORE, QFD, SSM, FAST,... Issues in Requirements Elicitation Michael G. Christel & Kyo C. Kang CMU/SEI-92-TR-12, September, 1992 Estratégia Tecnologia da Informação Ltda 55

56 Análise e Negociação de Requisitos Após coletados, os requisitos são analisados Categoriza e organiza em subconjuntos Valida relacionamento com outros Examina requisito quanto à consistência Verifica omissões e ambigüidade d Classifica (risco, prioridade, custo,...) Após analisados, requisitos it são negociados Conflitos Pi Prioridadesid d Elimine, combine e/ou modifique visando o consenso Estratégia Tecnologia da Informação Ltda 56

57 Engenharia de Requisitos Análise e Negociação de Requisitos Perguntas e respostas obrigatórias Cada requisito é consistente com o objetivo do produto? Todos os requisitos foram especificados? Todos são necessários ao objetivo? Quem deu origem ao requisito? Há conflitos? Cada requisito é viável tecnicamente no ambiente em que será desenvolvido? Cada requisito pode ser testado? Estratégia Tecnologia da Informação Ltda 57

58 Especificação de Requisitos Especificação pode ser registrada via Documento escrito Modelo gráfico Modelo formal Coleção de cenários (casos de uso) Protótipo ou combinação destes Modelo de especificação pode ser seguido Ex: IEEE 830 Estratégia Tecnologia da Informação Ltda 58

59 Validação de Requisitos Avaliação da qualidade Padronização da especificação Adequação aos propósitos Equipe de revisão inclui Engenheiros de sistema, clientes, usuários,... Checklists devem ser empregadas Tornam o trabalho mais objetivo Evitam omissões Estratégia Tecnologia da Informação Ltda 59

60 Identifica, controla e acompanha alterações nos requisitos em qualquer momento do projeto Para isto é preciso Identificar unicamente cada requisito Estabelecer conexões Clientes X Requisitos Requisitos derivados X Requisitos geradores Classificação (categoria) X Requisitos Estratégia Tecnologia da Informação Ltda 60

61 Requisitos, segundo Brooks A parte mais difícil da construção de um sistema de software é decidir o que construir. Nenhuma outra causa tantos t danos se feita de forma errada. Nenhuma outra é mais difícil il de corrigir. i Frederick Brooks No Silver Bullet: Essence and Accidents of Software Engineering IEEE Computer, vol 20(4), 1987, pp Estratégia Tecnologia da Informação Ltda 61

62 Especificação de sistema Produto final da engenharia de requisitos it Base para engenharia de software Para um sistema baseado em computador Descreve funções Descreve e o desempenho Descreve restrições Delineia cada elemento de sistema Descreve dados e controle que servem de entrada e saída do sistema Estratégia Tecnologia da Informação Ltda 62

63 Modelagem de sistema Para especificar é preciso um modelo Software pode ser modelado como entrada- processamento-saída Outras visões pode ser acrescentadas Interface com o usuário Manutenção e teste Visão orientada a objetos Um modelo fornece uma grande fotografia do que construir. Nem todo detalhe precisa ser especificado. Estratégia Tecnologia da Informação Ltda 63

64 Resumo Sistema de Informação inclui pessoas, software, e hardware Engenharia de sistemas ajuda a traduzir as necessidades do cliente em um modelo de sistema Inicie com a visão do mundo Especialize esta visão naquela do domínio Cada elemento é tratado pela sua engenharia A engenharia de sistemas produz a Especificação de sistema Estratégia Tecnologia da Informação Ltda 64

65 Documento de Requisitos Um processo de Engenharia deve produzir um Documento de Requisitos Artefato (formal?) para definição dos requisitos É uma ferramenta usada para comunicação entre usuários, desenvolvedores e gerentes Deve contemplar os requisitos de todos os envolvidos (stakeholders) e não apenas dos usuários diretos Estratégia Tecnologia da Informação Ltda 65

66 Conteúdo do Documento de Requisitos Deve descrever uma visão geral do sistema regras de negócio atendidas pelo sistema serviços e funções que o sistema deve prover propriedades e restrições para sua operação definições de interfaces e integração informações sobre o domínio de aplicação restrições ti sobre os processos usados para desenvolver o sistema descrição do hardware em que o sistema irá executar Estratégia Tecnologia da Informação Ltda 66

67 Conteúdo do Documento de Requisitos O documento deve conter Introdução Visão geral do sistema Necessidades de negócio suportadas pelo sistema Glossário explicação da terminologia adotada Estratégia Tecnologia da Informação Ltda 67

68 Usuários do documento de requisitos Clientes do sistema especificam os requisitos e lêem o documento para verificar que eles correspondem às suas necessidades Gerentes de Projeto usam o documento para planejar o processo de desenvolvimento Desenvolvedores e Mantenedores usam o documento para compreender o sistema Testadores usam o documento para desenvolver testes de validação Estratégia Tecnologia da Informação Ltda 68

69 Proposta de Estrutura do documento IEEE/ANSI Requisitos específicos 1. Introdução Propósito do documento, escopo do produto, definições, acrônimos e siglas, referências e visão geral do restante do documento 2. Descrição Geral Perspectiva do produto: funções, características dos usuários, restrições gerais, hipóteses e dependências abrangendo requisitos funcionais, não funcionais e de interface 4. Apêndices documentos complementares, normas, leis, etc. 5. Índice Estratégia Tecnologia da Informação Ltda 69

70 Resultado da Engenharia de Requisitos Especificação de Requisitos de Software Na ausência de tal documento, bem escrito: desenvolvedores não sabem o que construir clientes não sabem o que esperar não há como validar o sistema construído Estratégia Tecnologia da Informação Ltda 70

71 Especificação de Requisitos Requisitos são geralmente escritos em linguagem natural suplementados por diagramas e equações Figuras complementam, mas não especificam requisitos! Alguns problemas uso de condições complexas e confusas terminologia inconsistente e ambígua redatores supõem que leitores conhecem o domínio Estratégia Tecnologia da Informação Ltda 71

72 Propostas para Especificação de Requisitos Requisitos são mais lidos do que escritos invista na elaboração de requisitos legíveis e compreensíveis não suponha que o leitor tem o mesmo nível de conhecimento que o redator do documento requisitos devem descrever o problema (caso contrário se transformam em restrições) aloque tempo para revisão e re-elaboração do documento defina critérios para aceitação de requisitos Estratégia Tecnologia da Informação Ltda 72

73 Diretivas para especificação Defina um meta-documento t ou algum tipo de padrão para descrição de requisitos a IEEE 830 pode ser um ponto de partida Use uma linguagem simples, consistente e concisa não suponha que o leitor use a sua terminologia i Faça revisão e garantia da qualidade da especificação a qualidade do produto depende disso! Estratégia Tecnologia da Informação Ltda 73

74 Diretivas para especificação Suplemente a linguagem natural com outras descrições dos requisitos use diagramas de maneira apropriada (complementando, não substituindo texto) fórmulas e exemplos são úteis Especifique requisitos quantitativamente é preciso saber validar cada requisito Estratégia Tecnologia da Informação Ltda 74

75 Processos em Engenharia de Requisitos Um processo é um conjunto organizado de atividades para transformar entradas em saídas Descrições de processos encapsulam conhecimento e permitem a sua reutilização Exemplos de descrições de processos Manual de Instrução da máquina de lavar Livro de receitas Manual de procedimentos bancários Manual da qualidade para desenvolvimento de software Estratégia Tecnologia da Informação Ltda 75

76 Processo de Engenharia de Requisitos Sistemas Existentes Necessidades de Usuários Padrões Organizacionais Leis, Normas e Regulamentos Informações do Domínio Processo de Engenharia de Requisitos Requisitos Acordados Especificação do Sistema Modelos do Sistema Envolve criatividade, capacidade de abstração, interatividade com um grupo heterogêneo de pessoas, visão de engenharia, experiência e conhecimento do problema Processos similares: escrever um livro, organizar uma festa, construir uma casa, desenvolver er um software Estratégia Tecnologia da Informação Ltda 76

77 Requisitos no Modelo Cascata System requirements engineering System requirements specification Software requirements engineering Software requirements specification Software design Software design specification Programming and unit testing Executable software system System testing Completed system System operation Estratégia Tecnologia da Informação Ltda 77

78 Requisitos no Modelo Espiral Decision point: Accept document or re-enter spiral Informal statement of requirements Requirements elicitation Requirements analysis and negotiation Requirements document and validation report START Agreed requirements Requirements validation Requirements documentation Draft requirements document Estratégia Tecnologia da Informação Ltda 78

79 Requisitos no Modelo de Prototipação ACTIONS Understand problem Establish outline requirements Select prototyping system Develop prototype Evaluate prototype Req. engineer Domain expert End-user Req. engineer End-user Software engineer Project manager Req. engineer Software engineer End-user Domain expert Req. engineer Software engineer RO LES Estratégia Tecnologia da Informação Ltda 79

80 Cuidados no processo de E.R. O processo de E.R. deve garantir que não haja Falta de envolvimento dos clientes ou dos técnicos Omissão de necessidades do negócio Conflitos de linguagem Requisitos Ambíguos não mensuráveis inconsistentes Incorretos implícitos incompletos Falta de gerência de requisitos Responsabilidades indefinidas Cronogramas não cumpridos Mudanças de requisitos excessivamente dispendiosas Estratégia Tecnologia da Informação Ltda 80

81 Caso de Sucesso Taj-Mahal Produto Desenvolver Desejo Eliciar Shah Jehan requisitos Modelo Estratégia Tecnologia da Informação Ltda 81

82 Situação típica Sobre as orelhas. Ok Estratégia Tecnologia da Informação Ltda 82

83 O que é comum e indesejável? Estou aqui para coletar os requisitos, levará só 30 minutos! Osr sr. Está de acordo? Sim, não é o que combinamos? Uma semana depois,... Estratégia Tecnologia da Informação Ltda 83

84 9 meses depois de muito esforço e atrasos... Ficou pronto!!?? O que é isso? Estratégia Tecnologia da Informação Ltda 84

85 Como evitar esta situação? Qual foi o problema? Estratégia Tecnologia da Informação Ltda 85

86 Entender o problema é o primeiro passo Não se pode modelar o que não se conhece Estratégia Tecnologia da Informação Ltda 86

87 Quais as reais necessidades? Engenheiro de requisitos Cliente (Usuário) No início ainda há diálogo! Estratégia Tecnologia da Informação Ltda 87

88 Eliciar requisitos Não há o que capturar, tem-se que eliciar! Resultado só ocorre após várias sessões! Você se sente melhor, hoje? Não sei doutor, sinceramente. Estratégia Tecnologia da Informação Ltda 88

89 Definindo o sistema Cuidado! Trecho com alto índice de acidentes! ER E.R Problema Solução Estrada não pavimentada Estratégia Tecnologia da Informação Ltda 89

90 O que os bons fazem? Usam modelos compreensíveis (DFDs, DTEs, OO,...) Portal web interno acessível aos interessados ER executada em várias rodadas Protótipos Alocação de 15% a 40% do esforço total para ER Revisões constantes com os usuários Integração de processos (técnico e organizacional) Estratégia Tecnologia da Informação Ltda 90

91 Atividades do Processo de E.R. Gerência Elicitação Negociação e Análise Documentação Validação Aspirações dos Documento Clientes, Requisitos de Requisitos Conhecimento do Acordados Modelos do Domínio, Sistema Sistemas Existentes, Leis e Normas, e mais... Aquisição Desenvolvimento / Manutenção Estratégia Tecnologia da Informação Ltda 91

92 Ferramentas de suporte Ferramentas CASE automatizam muitos processos da Engenharia de Software No entanto, o apoio à E.R. ainda é limitado devido à informalidade e a variabilidade do processo Há duas grandes classes de ferramentas Ferramentas de Modelagem e Validação apóiam o desenvolvimento de modelos para especificação do sistema e a verificação da completitude e da consistência desses modelos Ferramentas de Gerência ajudam a gerenciar o banco de dados de requisitos e a controlar as mudanças desses requisitos Estratégia Tecnologia da Informação Ltda 92

93 Teoria x Prática Algumas referências sobre Engenharia de Requisitos Supostos benefícios Propostas teóricas Realidade constatada Estratégia Tecnologia da Informação Ltda 93

94 Arquitetura de CASE para E.R. Browser de Req. Sist. Consulta a Req. Documento de Req. em Ling. Nat. Conversor de Req. BD de Requisitos Sist. Rastreament. Req. Conversor p/ Proc.Texto Ger.Relatório Relat. de Rastreabilidade Sist. Contr. Mudanças Relat. de Requisitos [Kotonya & Sommerville, 1998] Estratégia Tecnologia da Informação Ltda 94

95 Elicitação de Requisitos A identificação de requisitos começa quando se reconhece que existe um problema que necessita de uma solução surge uma idéia ou necessidade nova Técnicas para descoberta e compreensão de requisitos Etnografia, Análise de Tarefas, Análise de Cenários Projeto Centrado no Usuário, Ergonomia, Semiótica Técnicas de Reunião, Projeto Participativo (JAD, FAST) Workshops, Entrevistas, Questionários, Problem Frames Teoria de Agentes, Prototipação, Brainstorm Estratégia Tecnologia da Informação Ltda 95

96 Barreiras na Elicitação de Requisitos Há dificuldades de comunicação com o usuário entendimento completo do problema negociação de interesses conflitantes organização das informações controle de mudanças trabalho em equipe validação dos requisitos Estratégia Tecnologia da Informação Ltda 96

97 Exemplo: Aeroporto de Denver O aeroporto tem área para aterrissagem de 3 jatos ao mesmo tempo O sistema de controle de bagagem teria uma esteira de 29 km com capacidade de transportar as bagagens g de 20 companhias aéreas Este sistema seria controlado por 100 computadores ligados em rede, 5000 sensores eletrônicos, 400 receptores de radio, 56 leitoras de código de barra Tudo orquestrado para enviar as bagagens aos seu destino de forma segura, correta e rápida através de carrinhos inteligentes Data programada de inauguração: Out/1993 Valor do contrato do Sistema: US$ 234 milhões Custos do atraso: US$ 1 milhão/dia Inauguração do Aeroporto: Fev/1995 (com o sistema de bagagem provisório) Custo do Sistema provisório: US$ 63 milhões Estratégia Tecnologia da Informação Ltda 97

98 Razões do Insucesso Problema principal: escopo e requisitos mal definidos e instáveis Foram desperdiçados cerca de $193 milhões O atraso por dia gerava custos de 1 milhão em juros e custos operacionais A empresa desenvolvedora do sistema (BAE) não tinha previsão de quando o sistema estaria em funcionamento Na implantação verificou-se a falta de funcionalidades que não foram previstas no levantamento de requisitos funções que foram definidas, mas não operavam corretamente A BAE, líder mundial em sistemas de bagagens, propôs um prazo inicial de 4 anos Prazo contratual, estabelecido por exigência do cliente, foi de 2 anos Durante o desenvolvimento foram realizadas 17 grandes alterações nos requisitos, uma delas com custo de $ 100 milhões A complexidade e o caráter inovador do projeto foram subestimados A experiência anterior da empresa desenvolvedora (BAE) era com sistemas de bagagens g para uma única companhia Estratégia Tecnologia da Informação Ltda 98

99 Fatores Humanos na E. R. A E.R. reúne uma diversidade de papéis Alguns estão mais interessados no problema a ser resolvido, outros na solução que será proposta Desenvolvedores e seus gerentes, usuários e seus gerentes, agentes reguladores externos, especialistas no domínio,... O sucesso do processo depende de fatores sociais e organizacionais Diversidade de conhecimentos, de terminologia e de objetivos individuais e organizacionais Personalidade e status de cada ator no processo Influência política de cada ator na organização Influência do grupo em indivíduos Estratégia Tecnologia da Informação Ltda 99

100 Comunicação Desenvolvedor X Usuário Visão dos Desenvolvedores Usuários não sabem o que querem Usuário pedem sem necessidade Usuários não conseguem transmitir o que eles querem Usuários têm muitas necessidades puramente políticas Usuários não sabem priorizar suas necessidades Visão dos Usuários Desenvolvedores não entendem as necessidades operacionais Desenvolvedores colocam muita dificuldade em qualquer pequena solicitação Desenvolvedores querem definir o que os usuários devem fazer Desenvolvedores não conseguem transformar necessidades em um sistema de sucesso Estratégia Tecnologia da Informação Ltda 100

101 Comunicação Desenvolvedor X Usuário Visão dos Desenvolvedores Usuários se recusam a ter responsabilidade d pelo sistema Usuários não estão compromissados com o projeto Usuários mudam de idéia e não permanecem dentro do planejamento Visão dos Usuários Desenvolvedores estão sempre atrasados Desenvolvedores sempre querem mais tempo e menos esforço Desenvolvedores são incapazes de atender rapidamente as necessidades de modificação Estratégia Tecnologia da Informação Ltda 101

102 Técnicas de Análise e Documentação Envolvem representação, verificação e validação de requisitos it Métodos formais (VDM, Z, Lógica) Métodos estruturados Métodos Orientados a Objetos Dificuldades Classificar requisitos e estabelecer prioridades Detectar, negociar e resolver conflitos Identificar os limites do sistema e como ele deve interagir com o seu ambiente Garantir rastreabilidade de requisitos Estratégia Tecnologia da Informação Ltda 102

103 Especificação de Software Especificações são definições que descrevem várias perspectivas do software visão macroscópica: Especificação de Requisitos representações intermediárias: Artefatos de Design visão detalhada: Código de Programas, DDL, etc. Uma especificação de requisitos deve ser a base para o desenvolvimento permitir o controle da qualidade do produto estabelecer a comunicação entre o pessoal envolvido no projeto auxiliar no entendimento do problema validar o design e o produto resultante Estratégia Tecnologia da Informação Ltda 103

104 Especificação de Requisitos Descrição textual descrição dos dados, relações e funções do sistema Modelagem através de métodos específicos Software convencional Diagrama de fluxo de dados Diagrama entidade relacionamento Diagrama de transição de estados Software orientado a objetos Diagrama de casos de uso Diagramas de classes Diferentes de transição de estado Diagramas de comportamento Diagramas específicos dos diferentes métodos Estratégia Tecnologia da Informação Ltda 104

105 Tratamento de Requisitos Estratégia Tecnologia da Informação Ltda 105

106 Tratamento de Requisitos O slide anterior mostra uma visão geral (etapas) do workflow de Requisitos As atividades da etapa Analyze the Problem serão mostradas em destaque no próximo slide Os objetivos deste workflow são Estabelecer e manter o entendimento entre clientes e outros stakeholders sobre o que o sistema deve fazer e porquê Prover aos desenvolvedores do sistema um melhor entendimento dos requisitos do sistema Definir os limites do sistema Prover uma base para o planejamento do conteúdo técnico das interações, e para a estimativa de custo e tempo para desenvolver o sistema Definir uma interface para o usuário enfatizando suas necessidades e objetivos Para atingir estes objetivos, este workflow descreve como definir uma visão do sistema e traduzir a visão em um modelo de casos de uso que, com as especificações suplementares, define os requisitos detalhados do sistema Adicionalmente, descreve como usar os atributos de requisitos para ajudar a gerenciar o escopo e as mudanças no sistema Estratégia Tecnologia da Informação Ltda 106

107 Atividades da Disciplina de Requisitos O slide mostra as atividades e papéis envolvidos na execução deste workflow No destaque as atividades envolvidas na etapa Analisar o Problema Analisar o Problema O agrupamento destas atividades para a execução desta etapa, juntamente com os papéis e artefatos relacionados são mostrados no próximo slide Estratégia Tecnologia da Informação Ltda 107

108 Detalhamento de Analisar o Problema Para cada uma das atividades o processo fornece os passos que devem ser seguidos Por exemplo, para a atividade Encontrar atores e casos de uso os passos são: -Encontre atores -Encontre casos de uso -Descreva como atores e casos interagem -Empacote casos e atores -Apresente o Modelo em diagramas de casos de uso -Avalie os resultados Estratégia Tecnologia da Informação Ltda 108

109 Documento de Visão Define o Escopo Qual é o problema que queremos resolver com o produto? Quais são as causas para que o problema exista? Como o problema afeta os envolvidos no projeto? Quem são os usuários do sistema? Quais os benefícios que o produto trará para os usuários? Porque o produto precisa se desenvolvido? Quem será afetado pelos produtos do sistema? Quem irá avaliar e aprovar o sistema quando ele for implantado? Existe algum outro usuário interno ou externo cujas necessidades também serão atendidas? Com que sistemas já existentes o novo produto deve interagir? Estratégia Tecnologia da Informação Ltda 109

110 Requisitos obscuros exigem ciclo evolutivo Fase Concepção Elaboração Construção Transição Iteração Preliminar Elab#1 Elab#2 Const #1 Const #2 Const #N Trans #1 Trans #2 tempo Escopo Arquitetura Primeira Release versão do Produto Entender o problema operacional Entender a solução Tem uma solução Estratégia Tecnologia da Informação Ltda 110

111 Ciclo de Vida Evolutivo Fase de Concepção Estabelecer bl o escopo do projeto e as condições de limite, i incluindo uma visão operacional, critérios de aceitação, o que faz parte do produto e o que não faz Identificar os processos críticos do sistema, os cenários básicos de operação que conduzirão os principais compromissos de design Mostrar pelo menos uma arquitetura candidata de suporte a alguns destes cenários Estimar o custo e o cronograma para todo o projeto Estimar os riscos potenciais e fontes de imprevisibilidade Preparar o ambiente de suporte para o projeto Estratégia Tecnologia da Informação Ltda 111

112 Ciclo de Vida Evolutivo Fase de Elaboração Assegurar que a arquitetura, os requisitos e planos estão estáveis Garantir que os riscos foram suficientemente mitigados Tratar os riscos significativos do ponto de vista de arquitetura Produzir um protótipo poó po Demonstrar que a arquitetura irá suportar os requisitos do sistema Estabelecer um ambiente de suporte Estratégia Tecnologia da Informação Ltda 112

113 Ciclo de Vida Evolutivo Fase de Construção Minimizar os custos de desenvolvimento otimizando os recursos e evitando re-trabalho Produzir versões úteis (alfa, beta e outras de teste) Garantir qualidade com produtividade id d e praticidade id d Completar a análise, design, desenvolvimento e testes de todas as funcionalidades d requisitadas it Desenvolver interativa e incrementalmente uma aplicação completa, pronta para ser entregue à comunidade usuária Decidir se a aplicação, os sites e os usuários estão todos prontos para receber a aplicação Conseguir algum grau de paralelismo no trabalho das equipes de desenvolvimento Estratégia Tecnologia da Informação Ltda 113

114 Ciclo de Vida Evolutivo Fase de Transição Disponibilidade do beta teste para validação do novo sistema em função das expectativas do usuário Disponibilidade do beta teste e operação paralela com relação ao legado que está sendo substituído Conversão do banco de dados operacional Treinamento dos usuários e da equipe de manutenção Iniciativas de marketing, distribuição e força de venda Ai Atividades id d de ajuste tais como correção de erros, melhoria de desempenho e usabilidade Avaliação do produto como um todo e dos critérios i de sucesso Homologação do produto por parte dos usuários e stakeholders Estratégia Tecnologia da Informação Ltda 114

115 Critérios de Sucesso para o Ciclo Evolutivo Recursos disponíveis i para a próxima fase Produto suficientemente maduro para os clientes Aceite dos usuários ou fim do ciclo de vida Concepção Elaboração Construção Transição tempo Escopo Arquitetura Primeira Release versão do Produto Entender o problema operacional Entender a solução Tem uma solução Estratégia Tecnologia da Informação Ltda 115

116 Exemplos de boas práticas de E. R. Definir uma estrutura de documento padrão Definir precisamente termos básicos Usar cenários para eliciar requisitos Identificar univocamente cada requisito Especificar requisitos quantitativamente Usar listas de verificação para análise e validação Estabelecer políticas para gerência de requisitos Usar protótipos para animar requisitos Estratégia Tecnologia da Informação Ltda 116

117 Exemplos de boas práticas de E. R. Reutilizar requisitos de outros projetos Melhorar continuamente o processo Entender o problema antes de começar a documentar modelos Desenvolver protótipos p que auxiliem ao usuário visualizar como seus requisitos serão atendidos Registrar a origem e a justificativa de cada requisito Utilizar múltiplas visões dos requisitos Priorizar requisitos Trabalhar para eliminar ambigüidades Estratégia Tecnologia da Informação Ltda 117

118 Qualidade de Requisitos Requisitos com qualidade evitam re-trabalho 75% dos erros são detectados depois das fases de codificação e teste de unidades 45% destes erros são erros de especificação e projeto Apenas 9% são erros de codificaçãocação 56% de todos os erros detectados em um software são devido a problemas na Engenharia de Requisitos São os erros que causam os maiores custos de correção Estratégia Tecnologia da Informação Ltda 118

119 Qualidade de Requisitos Erros Típicos em Requisitos 49% fatos incorretos 31% omissões 13% inconsistências 5% ambigüidades d 2% outros erros Esses erros são riscos para o projeto Tenha um plano de contingência Encontre o erro antes que o custo aumente Estratégia Tecnologia da Informação Ltda 119

120 Checklist para Qualidade de Requisitos os objetivos do sistema estão bem definidos? os requisitos definidos estão explícitos, corretos, completos e consistentes entre si? eles refletem as necessidades de todos os envolvidos? há margem para interpretações subjetivas de requisitos? o fluxo de informação do negócio está bem definido? Estratégia Tecnologia da Informação Ltda 120

121 Checklist para Qualidade de Requisitos os diagramas são claros e fáceis de entender? as funções estão adequadamente descritas? os riscos do projeto foram considerados? existem fatos implícitos, redundâncias ou omissões? todas as interfaces para outros elementos do sistema, inclusive com o usuário, foram definidas? id Estratégia Tecnologia da Informação Ltda 121

122 Verificação Contínua de Qualidade Minha aplicação faz o que é preciso? Requisitos: Funcionais de Desempenho de Confiabilidade Funcionalidade Verificação de cada cenário de uso Confiabilidade Minha aplicação responde satisfatoriamente? Verificação da sustentabilidade das operações da aplicação Desempenho Teste de desempenho sob carga esperada e no pior caso Meu sistema tem bom desempenho em produção? Estratégia Tecnologia da Informação Ltda 122

123 Gerenciar Mudanças As Solicitações de Mudanças têm sua origem em varias fontes através das iterações do ciclo de vida do produto Entradas Cliente/Usuário Final Canal único de aprovações Processo de Aprovação das Decisões Nova Característica Novo Requisito Bug Solicitação de Mudança Requisitos Modelagem Código Testes Manutenção Marketing Codificadores Testadores Suporte Técnico/ Usuário Final Estratégia Tecnologia da Informação Ltda 123

124 Maturidade do Processo de ER Nível inicial Nenhum processo de ER Problemas clássicos de requisitos são recorrentes, incluindo Volatilidade de requisitos Stakeholders insatisfeitos Alto custo de re-trabalho Sucesso depende de experiência e habilidades individuais Estratégia Tecnologia da Informação Ltda 124

125 Maturidade do Processo de ER Nível repetível Padrões definidos para documento de requisitos Verificação do padrão em todos os projetos Políticas e procedimentos estabelecidos para gerenciar mudanças em requisitos Visibilidade das decisões Negociação Análise de impacto Estratégia Tecnologia da Informação Ltda 125

126 Maturidade do Processo de ER Nível definido Padrões definidos para documento de requisitos Políticas e procedimentos estabelecidos para todas as atividades da ER Processo de ER definido com base em boas práticas e adaptado às necessidades da empresa Programa de melhoria contínua da ER ativo em todos os projetos Garantia de entendimento t de requisitos it Comprometimento com os requisitos Rastreabilidade de requisitos Controle de mudanças em requisitos Identificação de inconsistências entre requisitos e artefatos Estratégia Tecnologia da Informação Ltda 126

127 Artefatos Típicos Entendimento de requisitos Critérios para identificação de fornecedores de requisitos Critérios para avaliação e aceitação de requisitos Resultados de análise de critérios Requisitos acordados Estratégia Tecnologia da Informação Ltda 127

128 Artefatos Típicos Comprometimento com requisitos Análise de impacto e viabilidade de requisitos Documento de avaliação e aceitação de mudanças em requisitos Alocação de stakeholders (e não só do Analista) em atividades que envolvem análise de requisitos Documento de negociação de requisitos Estratégia Tecnologia da Informação Ltda 128

129 Artefatos Típicos Mudanças em requisitos Documento de solicitação de mudanças em requisitos Documento de avaliação e aceitação de mudanças em requisitos Identificação da fonte de cada requisito Relatório de status de requisitos Base histórica de definição de requisitos Base histórica de mudança de requisitos Estratégia Tecnologia da Informação Ltda 129

130 Artefatos Típicos Rastreabilidade de requisitos Identificação da fonte de cada requisito Baseline de requisitos Matriz de rastreabilidade de requisitos Procedimentos e métodos para análise de impacto de mudanças em requisitos Base histórica de mudança de requisitos Estratégia Tecnologia da Informação Ltda 130

131 Artefatos Típicos Consistência i entre requisitos it e artefatos t Procedimentos para verificação de consistência de requisitos it Registro de atividade de Garantia da Qualidade de requisitos Registro de inconsistência entre requisitos e artefatos Registro de procedimento para correção de inconsistências entre requisitos e artefatos Registro de acompanhamento de correção de requisitos Estratégia Tecnologia da Informação Ltda 131

132 Conclusões Não há Bala de Prata! Não é que eles não saibam a solução... Processos e ferramentas ajudam, O que eles não sabem é mas é preciso: qual é o problema!!! 1. Entender o problema requer: raciocínio, comunicação, conhecimento, colaboração, abstração 2. Descrever o problema requer: habilidade de expressão, atenção aos detalhes, precisão, concisão, domínio do contexto Sem E.R. é mais difícil negociar com os clientes estimar esforços saber se os objetivos foram atingidos garantir a qualidade do produto Estratégia Tecnologia da Informação Ltda 132