Engenharia de Requisitos

Transcrição

1 Engenharia de Requisitos

2 Processo de Eng. Requisitos p Composto por quatro (ou cinco) atividades de alto nível (Soares, 2005): p Viabilidade p Identificação. p Análise e negociação. p Especificação e documentação. p Validação.

3 Viabilidade p interação com "as partes interessadas" (ou stakeholder em inglês) do projeto p reuniões ou entrevistas p Será que o sistema contribui para os objetivos da organização? p Dadas as restrições tecnológicas, organizacionais (econômicas, políticas, ambientais, recursos disponíveis) e temporais associadas ao projeto, será que o sistema pode ser implementado? p Se o novo sistema não fosse implementado, quais seriam as alternativas para a organização? p Quais são os problemas que os sistemas atuais apresentam e como é que um sistema novo irá resolver estas falhas? p Caso haja necessidade de integração entre diferentes sistemas, será que esta é possível?

4 Identificação p Compreensão do domínio: p Identificação das partes interessadas: p Captura: consiste na obtenção com o cliente dos requisitos (funcionais e não-funcionais) pretendidos para o sistema. p Identificação e análise de problemas: os problemas devem ser identificados (e a sua definição deve ser consensual) e devem ser propostas soluções em conjunto com as partes interessadas.

5 Técnicas para levantamento de requisitos p Entrevista e Questionários p Workshop de requisitos p Cenários p Prototipagem Versão inicial do sistema com poucos requisitos

6 Análise e negociação dos requisitos p Classificação: agrupamento de requisitos em "módulos" p Resolução de conflitos p Prioritização: consiste na atribuição de uma "prioridade" a cada requisito (por exemplo elevada/média/baixa); p Confirmação: Confirma com as partes interessadas a completude dos requisitos, sua consistência e validade.

7 Especificação e documentação p Requisitos Funcionais p Requisitos não-funcionais

8 Validação p demonstrar que o documento de requisitos produzido corresponde, de fato, ao sistema que o cliente pretende

9 Engenharia de Requisitos / Análise de Requisitos Trecho do Pequeno Príncipe: Antoine Saint-Exupéry, E ele repetiu-me então, brandamente, como uma coisa muito séria: - Por favor... desenha-me um carneiro... Quando o mistério é muito impressionante, a gente não ousa desobedecer. Por mais absurdo que aquilo me parecesse a mil milhas de todos os lugares habitados e em perigo de morte, tirei do bolso uma folha de papel e uma caneta. Mas lembrei-me, então, que eu havia estudado de preferência geografia, história, cálculo e gramática, e disse ao garoto (com um pouco de mau humor) que eu não sabia desenhar. Respondeu-me: -Não tem importância. Desenha-me um carneiro. Como jamais houvesse desenhado um carneiro, refiz para ele um dos dois únicos desenhos que sabia. O da jibóia fechada. E fiquei estupefato de ouvir o garoto replicar:

10 Engenharia de Requisitos / Análise de Requisitos - Não! Não! Eu não quero um elefante numa jibóia. A jibóia é perigosa e o elefante toma muito espaço. Tudo é pequeno onde eu moro. Preciso é dum carneiro. Desenha-me um carneiro. Então eu desenhei. Olhou atentamente, e disse: - Não! Esse já está muito doente. Desenha outro. Desenhei de novo. -Bem vês que isto não é um carneiro. É um bode... Olha os chifres... -Fiz mais uma vez o desenho. Mas ele foi recusado como os precedentes: - Este aí é muito velho. Quero um carneiro que viva muito. -Então, perdendo a paciência, como tinha pressa de desmontar o motor, rabisquei o desenho ao lado. E arrisquei: -Esta é a caixa. O carneiro está dentro. Mas fiquei surpreso de ver iluminar-se a face do meu pequeno juiz: - Era assim mesmo que eu queria! Será preciso muito capim para esse carneiro?

11 Engenharia de Requisitos / Análise de Requisitos Definindo o Sucesso do Software p Clientes satisfeitos p Eles estão satisfeitos quando você: Atende às expectativas Entrega no prazo Entrega no orçamento O Sucesso começa com a Gerência de Requisitos

12 Engenharia de Requisitos / Análise de Requisitos Principais Fatores de Falha dos Projetos o Falta de Input do Usuário o Objetivos não estavam claros o Falta de suporte do nível executivo o Ignorar um grupo de clientes o Requisitos e especificações incompletos o Requisitos e especificações instáveis (mudanças) o Omitir um grupo de requisitos o Permitir inconsistências entre grupos de requisitos o Aceitar requisito inadequado, incorreto, indefinido, ou impreciso o Aceitar um requisito ambíguo e inconsistente

13 Engenharia de Requisitos / Análise de Requisitos Como os Projetos podem ter sucesso? p Análise do Problema Entenda o problema Obtenha concordância dos envolvidos p Levantamento dos Requisitos Identifique quem usará o sistema (atores) Descubra como o sistema será usado (casos de uso) p Gerência de Requisitos Especifique os requisitos completamente Gerencie expectativas, mudanças e erros Controle o aumento do escopo Defina a equipe e a mantenha informada

14 Engenharia de Requisitos / Análise de Requisitos Mas o que são Requisitos? p Os requisitos de um sistema de computação constituem uma especificação das características e propriedades do sistema ou p Uma descrição do que o sistema deve fazer, de como ele deve se comportar, bem como das suas restrições de operação.

15 Engenharia de Requisitos / Análise de Requisitos Mas o que são Requisitos? p É importante ressaltar que os requisitos descrevem "o que o sistema deve fazer"- e também "o que ele não deve fazer"- sem dizer "o como fazer". p Quando o requisito é expresso em termos do comportamento do sistema, este comportamento deve ser possível de ser percebido por um observador externo ao sistema.

16 Engenharia de Requisitos / Análise de Requisitos O que são requisitos? Clientes Usuários Necessidades Limitações Impossibilidades Infra-Estrutura Tecnológica

17 Engenharia de Requisitos / Análise de Requisitos Requisitos e Especificação p Requisito (IEEE) Uma condição ou capacidade necessitada por um usuário para resolver um problema ou alcançar um objetivo Uma condição ou capacidade que deve ser satisfeita por um sistema para satisfazer um contrato ou um padrão p Especificação: descrição rigorosa e minuciosa das características que um material, uma obra, ou um serviço deverá apresentar processo de representação dos requisitos de uma forma que leva à implementação bemsucedida

18 Engenharia de Requisitos / Análise de Requisitos Importância da Especificação Correta p Uma compreensão completa dos Requisitos do Software é fundamental para obter um software e um processo de desenvolvimento com alta qualidade p Não importa quão bem projetado ou codificado está um programa, se ele for mal analisado e especificado desapontará o usuário e trará aborrecimentos ao desenvolvedor

19 Engenharia de Requisitos / Análise de Requisitos Especificação de Requisitos p ser a base para o desenvolvimento; p permitir o controle da qualidade do produto; p estabelecer a comunicação entre o pessoal envolvido no projeto; p auxiliar no entendimento do problema.

20 Engenharia de Requisitos / Análise de Requisitos Fase de Análise de Requisitos Engenharia de Sistemas de Computador PONTE ANÁLISE DE REQUISITOS Projeto de Software Escopo do Software Primeiro passo técnico Analista de Sistemas

21 Engenharia de Requisitos / Análise de Requisitos Conceito de Requisito Requisito é uma condição ou capacidade necessária para um usuário resolver um problema ou alcançar um objetivo; para satisfazer uma especificação em um sistema ou em um componente; com uma representação documentada. Em: The IEEE Standard Glossary of Software Engineering Terminology, Rocco, 2004

22 Engenharia de Requisitos / Análise de Requisitos Fase de Análise de Requisitos Engenharia de Sistemas de Computador PONTE ANÁLISE DE REQUISITOS Projeto de Software Escopo do Software Primeiro passo técnico Analista de Sistemas

23 Engenharia de Requisitos / Análise de Requisitos

24 Engenharia de Requisitos / Análise de Requisitos Requisitos de Software p A Norma ISO/IEC 9126 define seis características de qualidade de software que devem ser avaliados: Funcionalidade (finalidade do produto) Usabilidade (esforço para utilizar, aprender o produto) Confiabilidade (freqüência de falhas, recuperabilidade) Eficiência (desempenho) Manutenibilidade (esforço necessário para modificar) Portabilidade (capacidade de transferir o produto para outros ambientes)

25 Como os Projetos Podem Ter Sucesso? p Análise do Problema Entenda o problema Obtenha concordância dos envolvidos p Levantamento dos Requisitos Identifique quem usará o sistema (atores) Descubra como o sistema será usado (casos de uso) p Gerência de Requisitos Especifique os requisitos completamente Gerencie expectativas, mudanças e erros Controle o aumento do escopo Defina a equipe e a mantenha informada

26 Gerência de Requisitos Atividades de: - acompanhar o desenvolvimento - controlar as mudanças dos requisitos Ações: - planejamento desenvolvimento ( baseline ) - rastreabilidade com componentes de software - definição do estado e avaliação da qualidade - análise impacto e controle versões de mudanças Rocco, 2004

27 Necessidades da Elicitação p Faz p Faz p Faz Coleta de Fatos Identificação de Fontes de Informação Comunicação p Faz/Usa Ferramentas p Usa p Usa Pessoal Métodos p Depende de Pontos de Vista

28 Identificação das Fontes de Informação p O que são Stakeholders do sistema? Qualquer pessoa afetada de alguma forma pelo sistema (atores, cliente, usuário final, desenvolvedor) o A análise dos Stakeholders ajuda a determinar o impacto que um novo sistema de informação terá.

29 Coleta de Fatos p Entrevistas p Coleta e Leitura de documentos p Observação p Questionários p Análise de Protocolos p Enfoque antropológico (estudo do ser humano) p Reuniões p Reutilização p Recuperação (eng. reversa) do projeto do software

30 Características das TécnicasT p Brainstorm útil no início do processo levantamento de requisitos reunião conjunta objetivo estimular a imaginação e a geração de idéias não avalia um conjunto de soluções p Entrevistas não-estruturadas estruturadas

31 JAD - Joint Application Development p Usuários e desenvolvedores trabalham juntos em uma reunião com o objetivo de: identificar o problema propor elementos de solução negociar diferentes abordagens especificar um conjunto preliminar de requisitos de solução p Envolve: preparação para reunião a partir de uma requisição geral do produto reunião INTRODUZ TEMA MOSTRAR EXEMPLOS DISCUSSÃO CONSENSO DOCUMENTAÇÃO Processo Responsável PENDÊNCIA IMPASSE Gerência

32 Linguagem p A linguagem é reflexo da cultura de uma sociedade. p Para entendermos algo de importante para uma sociedade temos que entender sua linguagem. p Deve-se compreender a linguagem antes de elicitar as necessidades. Exemplos Fecha a mesa, Passagem de Resultados, Zipar, FTP, TCP/IP

33 Nível de Abstração p A comunicação pode ser ruidosa se os indivíduos estiverem dialogando em diferentes níveis de abstração. p Conflito presente entre generalistas e especialistas. Exemplo Devemos conquistar mercados (Diretoria) X Distribuir os vendedores (Gerência de Vendas)

34 Retroalimentação p Obrigar ao receptor da informação a recolocar a comunicação até que o emissor responda positivamente a recolocação. p Resumir, parafrasear, confirmar. a? a