Técnicas de Levantamento de Requisitos Aula 1

Transcrição

1 MBA em Gestão de Software Técnicas de Levantamento de Requisitos Aula 1

2 Agenda Introdução Conceitos Tipos de Requisitos Processo de Engenharia de Requisitos Princípios para Bons Requisitos Exercícios

3 Introdução No desenvolvimento de projetos de software nos deparamos com vários problemas como: Uma grande empresa inicia um projeto de desenho e construção de um sistema de integração de seus escritórios ao redor do mundo. Ao final do desenvolvimento, após dois anos e aproximadamente $10 milhões gastos, os escritórios recusamse em usar o produto porque o sistema não atendia às necessidades ou expectativas dos usuários. Em outro caso, Uma empresa líder no desenvolvimento de software ganha um contrato para realizar um projeto para um cliente importante. Mais tarde, a gerência desta empresa que ganhou o projeto fica surpresa quando o especialista informa que, de acordo com os verdadeiros requisitos do cliente, o escopo do projeto simplesmente dobrou.

4 Standish Group Um projeto bem sucedido é: completado no tempo, dentro do orçamento e com todas as funcionalidades. 3 tipos de projetos: Sucesso: dentro do prazo, dentro do orçamento e com todas as funcionalidades Problemáticos: acima do prazo, acima do orçamento e com menos funcionalidades Fracasso: cancelado antes de completar e nunca implantado

5 Fatores que contribuem para o fracasso dos projetos 1. Falta de interação do usuário 2. Requisitos e especificações inconsistentes e/ou incompletas 3. Mudanças nos requisitos e especificações 4. Falta de apoio da alta gerência 5. Incompetência tecnológica 6. Falta de recursos 7. Expectativas não realistas 8. Objetivos não claros 9. Projeção de tempo não realista 10. Novas tecnologias

6 O que é um requisito?

7 O que é um requisito? São objetivos ou restrições estabelecidas por clientes e usuários do sistema, que definem as diversas propriedades do sistema.

8 Conceitos - Requisitos Definição [IEEE Software Engineering Standards, 1987] Uma condição ou capacidade necessária para um usuário resolver um problema ou alcançar um objetivo, ou Uma condição ou capacidade que deve estar presente em um sistema para satisfazer um contrato, especificação, padrão ou outro documento formalmente imposto ao projeto.

9 Conceitos Requisitos [Sommerville] Requisitos do Usuário Declarações, em linguagem natural e também em diagramas, sobre as funções que o sistema deve fornecer e as restrições sob as quais deve operar. Escrito para os clientes. Requisitos do Sistema Estabelecem detalhadamente as funções e as restrições do sistema. O documento de requisitos, chamado de especificação funcional, pode servir como um contrato entre cliente e desenvolvedor.

10 Como descrever os requisitos? Linguagem utilizada Linguagem natural, informal apropriada para os requisitos do usuário e do sistema. Linguagens gráficas, semi-formais apropriada para os requisitos do sistema. Linguagens formais apropriada para uma especificação formal de software em métodos formais. A especificação dos requisitos deve ser: Completa deve descrever tudo o que é necessário. Consistente não deve haver conflitos e contradições. Não-ambígua não deve levar a interpretações diferentes por desenvolvedores e usuários.

11 Tipos de Requisitos Requisitos funcionais Como o próprio nome indica, apontam as funções que o sistema deve fornecer e como o sistema deve se comportar em determinadas situações. Requisitos não funcionais Propriedades ou qualidades globais de um software, como manutenibilidade, usabilidade, desempenho, custos. Descrevem restrições sobre as funções oferecidas, tais como restrições de tempo, de uso de recursos, etc.

12 Requisitos Funcionais Descrição das diversas funções que clientes e usuários querem ou precisam que o software ofereça. Exemplos: "o software deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal". "o software deve emitir relatórios de compras a cada quinze dias. "os usuários devem poder obter o número de aprovações, reprovações e trancamentos em todas as disciplinas por um determinado período de tempo.

13 Requisitos não Funcionais - Categorias Usabilidade Tempo de treinamento desejado para um usuário normal e um usuário máster se tronarem produtivos em determinada operação. Tempo de duração desejado para determinada operação no sistema. Ajuda on-line, documentação do usuário e material de treinamento. Confiabilidade Disponibilidade percentual de tempo do sistema disponível, horas de uso, números de acesso Tempo de correção tempo permitido para indisponibilidade do sistema após a ocorrência de uma falha.

14 Requisitos não Funcionais - Categorias Desempenho Tempo de resposta para uma transação Capacidade (número de usuários ou transações concorrentes que o sistema deve suportar) Suportabilidade Padrões de codificação Convenções de nomenclatura Bibliotecas de classes Outros (design, físicos, interface)

15 Requisitos Não Funcionais Exemplos: "a base de dados deve ser protegida para acesso apenas de usuários autorizados". "o tempo de resposta do sistema não deve ultrapassar 30 segundos". "o software deve ser operacionalizado no sistema Linux. "o tempo de desenvolvimento não deve ultrapassar seis meses".

16 Conflitos entre Requisitos Não Funcionais Exemplo: Espaço máximo ocupado pelo sistema = 4MB. Utilização da linguagem Ada, para desenvolvimento de software crítico e em tempo real. Contudo, pode não ser possível compilar um programa Ada com menos de 4MB.

17 Priorização de Requisitos Essencial Requisitos sem o qual o sistema não poderá entrar em funcionamento. Importante Requisitos importantes, mas que não impedem o funcionamento do sistema. Desejável Requisitos que não impedem a entrada em funcionamento do sistema sem sua implementação, podendo ser disponibilizados por último.

18 Priorização de Requisitos Idealmente, a priorização deve ser feita: Pelos usuários/clientes Sem considerar questões técnicas Estima-se que pelo menos 1/3 dos itens na lista de características devem ser críticos.

19 O Processo de Engenharia de Requisitos O processo de descobrir, analisar, documentar, verificar / validar requisitos e gerenciar as mudanças é chamado de processo de engenharia de requisitos. Os processos de Engenharia de Requisitos variam muito de uma organização para outra, mas, de maneira geral, a maioria deles é composta das seguintes atividades: Levantamento (ou Descoberta ou Elicitação ou Extração) de Requisitos. Análise de Requisitos. Especificação ou Documentação de Requisitos. Verificação e Validação de Requisitos. Gerência de Requisitos

20 Processo de Engenharia de Requisitos - RUP

21 Processo de Engenharia de Requisitos Entrevistas Levantamento Qustionários JAD Observação Validação Informação certificada Lista de problemas Ações corretivas Brainstorming Documento Análise Analisar o problema Identificação de requisitos Classificação de requisitos Especificação Descrição Problemas Restrições de Requisitos Produtos Gerência de Requisitos

22 1 - Levantamento (ou Descoberta ou Elicitação ou Extração) de Requisitos Fase do desenvolvimento de um sistema em que se identificam o que os utilizadores pretendem do sistema a ser desenvolvido. Nesta fase, os usuários, clientes e especialistas de domínio são identificados e trabalham junto com os engenheiros de requisitos para descobrir, articular e entender a organização como um todo, o domínio da aplicação, os processos de negócio específicos, as necessidades que o software deve atender e os problemas e deficiências dos sistemas atuais. Os diferentes pontos de vista dos participantes do processo, bem como as oportunidades de melhoria e restrições existentes, os problemas a serem resolvidos, o desempenho requerido e as restrições também devem ser levantados.

23 Consequências do Levantamento de Requisitos Por melhor que seja o levantamento, usuários podem ter reações diferentes ao ver o sistema rodando. Não há como garantir que todos os requisitos foram levantados.

24 Técnicas de Levantamento de Requisitos Questionários Entrevistas Observação in loco JAD Joint Application Development

25 Identificação de usuários e envolvidos Quem são os usuários do sistema? Quem é o cliente do sistema? Quem mais será afetado pelas saídas oferecidas pelo sistema? Quem avaliará e aprovará o sistema quando entregue? Quem irá manter o sistema? Alguém mais?

26 O Contexto Os envolvidos: Nem sempre sabem o que eles realmente querem Se expressam num vocabulário diferente dos desenvolvedores Podem ter requisitos conflitantes Não possuem da visão geral do processo Mudanças: Novos requisitos podem surgir durante o processo de levantamento/análise/especificação Novos envolvidos podem vir a participar do processo Podem haver mudanças externas ambiente ou regras de negócios

27 O Contexto Nem sempre o usuário... consegue descrever exatamente os procedimentos de seu trabalho (ele não foi treinado para isto) admite que não segue os procedimentos que são recomendados para uma atividade consegue expressar todos os caminhos alternativos de seu trabalho Funcionalidades do sistema muitas vezes não são intuitivas para os usuários... ou são consideradas muito óbvias e nem são comentadas Quando vêem o sistema em execução, melhoram sua percepção, e aí aparecem... requisitos novos

28 Problema x Solução Usuários não sabem exatamente o que querem ou sabem mas não são capazes de organizar suas idéias para explicar aos desenvolvedores. Usuários somente descobrem o que realmente querem quando os desenvolvedores lhes mostram algum resultado preliminar. Reconheça o usuário como o especialista da área e aprecie seu conhecimento; tente meios coletivos de identificação de requisitos. Gere protótipos rápidos antes de desenvolver o sistema propriamente dito, apenas para validação dos usuários.

29 Problema x Solução Os analistas acham que entendem melhor os problemas do usuário do que o próprio usuário. Dificuldades de comunicação entre usuários e desenvolvedores (mundos diferentes, culturas e termos distintos) ou as expectativas dos usuários não são facilmente compreendidas pelos analistas Aproxime o analista do usuário de forma que este verifique se seu conhecimento procede neste caso. Busque aprender sobre a área de conhecimento dos usuários

30 2 - Análise de Requisitos Análise do Problema Objetivo: entender o problema a ser resolvido antes de iniciar o desenvolvimento da aplicação. Atividades: Atingir acordo sobre a definição do problema. Identificar usuários e pessoas envolvidas, cujos julgamentos determinam o sucesso ou fracasso do sistema. Determinar as fronteiras do sistema. Compreender as restrições impostas à solução.

31 3 - Especificação de Requisitos Descrição objetiva, precisa e completa dos requisitos do software. A especificação de um requisito funcional deve determinar o que se espera que o software faça, sem a preocupação de como ele faz. Requisitos funcionais podem ser descritos por Diagramas de Casos de Uso UML. Requisitos não funcionais são descritos textualmente.

32 Especificação de Requisitos Requisitos não incluem informações de projeto custos, prazos, etc - (deixe isto para o plano de projeto). Requisitos também não devem incluir decisões de projeto linguagem, arquitetura, estratégia de armazenamento etc. Requisitos Projeto O que o sistema precisa fazer Como o sistema fará

33 4 - Verificação e Validação de Requisitos A verificação de requisitos avalia se o Documento de Requisitos está sendo construído de forma correta, de acordo com padrões previamente definidos, sem conter requisitos ambíguos, incompletos ou, ainda, requisitos incoerentes ou impossíveis de serem testados. Já a validação diz respeito a avaliar se esse documento está correto, ou seja, se os requisitos e modelos documentados atendem às reais necessidades e requisitos dos usuários / cliente.

34 Checklist de Validação Os requisitos foram definidos claramente? Podem ser mal interpretados? Existem outros requisitos relacionados a este requisito? Eles são notados através de matriz de rastreabilidade ou outro mecanismo? A documentação foi criada de modo a facilitar o entendimento e a referência ao requisito? Possui índice? Os requisitos não funcionais foram claramente especificados? Existem requisitos implícitos? Existem requisitos ambíguos?

35 Princípios para Bons Requisitos Utilize e mantenha um glossário. Garanta que os requisitos não conflitem e sejam objetivos. Redação clara é essencial. Descreva o que precisa ser feito. Evite descrever os aspectos computacionais de como o sistema completa uma tarefa. Os requisitos não devem especificar itens de projeto, como: A divisão do software em módulos. O fluxo de informação/controle entre módulos. As estruturas de dados selecionadas. Estas informações confundem o patrocinador e complicam a validação.

36 Princípios para Bons Requisitos Composição das frases: Sujeito: Identifique a pessoa ou o sistema que está sendo discutido. Predicado: Identifique a ação, o resultado desta ação e a pessoa ou sistema que receberão os resultados. Verbos: utilize verbos e palavras que não possam ter dupla interpretação. Exemplo: O sistema deve registrar um novo correntista em um arquivo texto, separado por vírgula, contendo o número e nome da conta corrente.

37 Princípios para Bons Requisitos Sinais de requisitos problemáticos: Termos genéricos: geralmente, usualmente, frequentemente, normalmente, tipicamente, como possível, aproximadamente. Termos relativos: rápido, flexível, adaptativo, intuitivo. Termos furtivos: poderia, deveria, talvez, pode, provavelmente. Uso de jargão : plug-in-play.

38 Princípios para Bons Requisitos Consistência: Um conjunto de requisitos é dito consistente se nenhum subconjunto destes requisitos entra em conflito com os demais requisitos do sistema. Exemplo de conflito: Se o sistema estiver no estado X, faça P. Se o sistema estiver no estado X, faça Q.

39 Princípios para Bons Requisitos Consistência: Nem sempre os conflitos são tão claros. Funcionários com mais de 65 anos devem receber um bônus de $1000. Funcionários com mais de 10 anos de empresa devem receber um bônus de $100. O que fazer na caso de funcionários com mais de 65 anos e 10 anos de empresa? Somar? Maior valor? Menor valor?

40 Princípios para Bons Requisitos Issues in Requirements Elicitation ports/pdf/tr12.92.pdf Software Requirements ftp://ftp.sei.cmu.edu/pub/documents/90.report s/pdf/cm19.pdf

41 Exercícios Resolver a lista de Exercícios Aula 1 Elaborar resumo para o artigo Gerência de Requisitos: O principal problema dos projetos de software (José Roberto Blashek)