Técnicas de Levantamento de Requisitos. Técnicas de Levantamento de Requisitos

Transcrição

1 Régis Patrick Silva Simão Régis Simão 1/34

2 Agenda Síndromes relacionadas com o Levantamento de Requisitos Entrevista Workshops Brainstorming e Redução de Idéias Storyboarding Aplicação de Casos de Uso Prototyping Bibliografia Régis Simão 2/34

3 Síndromes relacionadas ao Levantamento de Requisitos Síndrome Sim, mas... Síndrome Ruínas não descobertas Síndrome Usuário e o Desenvolvedor Régis Simão 3/34

4 Síndrome Sim, mas... Sintomas: Wow, muito legal; nós podemos realmente usar isto, que trabalho legal,... Sim, mas, hmmmmm, deixe-me ver, e se fosse assim...? Não seria melhor deste jeito...? Que tal desta forma...? Causas: Esta síndrome faz parte da natureza humana. Construir software é um processo de intelectual intangível. Falta de validação dos usuários nas fases iniciais do sistema. Falta de protótipos ou modelos para validação. O primeiro contato com o sistema é depois de meses ou anos de desenvolvimento. Régis Simão 4/34

5 Síndrome Ruínas não descobertas Pesquisar requisitos é como pesquisar ruínas não descobertas Quanto mais se procura, mais se acha! Quando mais você acha, mais você sabe que ainda tem! O importante é saber que: Procurar requisitos é uma missão que nunca será completada. Deve-se procurar requisitos até o ponto onde possa-se dizer com segurança: Eu já tenho o bastante! Régis Simão 5/34

6 Síndrome Usuário e o Desenvolvedor Sintomas Usuários não sabem o que eles querem ou não sabem transmitir o que querem. Analistas pensam que conhecem o negócio dos usuários melhores que eles. Gap de comunicação: Vivem em mundos diferentes. Falam linguagens (vocabulários) diferentes. Têm cultura, motivações e objetivos diferentes. Solução: Uma comunicação mais eficiente, combinando as palavras dos usuários com as experiências dos desenvolvedores. Régis Simão 6/34

7 Entrevista Workshops de Requisitos Brainstorming e Redução de Idéias Storyboarding Aplicação de Casos de Uso Prototyping Outras Régis Simão 7/34

8 Fatores que influenciam na escolha da técnica de levantamento de requisitos Tipo da aplicação Habilidade e sofisticação da equipe de desenvolvimento Habilidade e sofisticação do cliente Escala do problema Criticidade da aplicação Tecnologia usada Singularidade da aplicação Sua experiência com as técnicas de levantamento de requisitos Régis Simão 8/34

9 Entrevista Um entrevistador e um entrevistado Trabalha a síndrome "Usuário e o Desenvolvedor" A cultura, a experiência e predisposição do entrevistador não devem interferir na troca livre de informação ou com o entendimento do problema real a ser resolvido. Régis Simão 9/34

10 Entrevista Preparação das Questões: Questões livre de contexto Não endereçam uma solução específica. Quem são os usuários do sistemas? Quem são os clientes? As necessidades deles são diferentes? Onde mais uma solução para este problema pode ser encontrada? Questões dentro de um contexto de solução. Busca visualizar a soluções ou novas idéias. Entrevista genérica, quase livre de contexto. Combina os dois tipos de questões. Busca alcançar requisitos não funcionais também. Régis Simão 10/34

11 Entrevista Realização da Entrevista: Prepare as questões e as revise antes da entrevista. Pode levar as questões e consultá-las durante a entrevista. Estude o contexto do entrevistado antes da entrevista e não pergunte questões que você poderia ter vistos as respostas antes. Escreva as respostas imediatamente, de forma tranquila, mas rapidamente. Se o entrevistado começar a falar muito, desenvolvendo uma linha de raciocínio não o interrompa. É isto que nós queremos! Você pode perguntar questões que não estavam planejadas sobre alguma informação fornecida. Depois de duas entrevistas, você começa a ter ganho de conhecimento sobre o problema em foco e, muito importante, sobre os sentimentos dos usuários sobre o que seria uma boa solução. Régis Simão 11/34

12 Entrevista Compilação dos dados: Seção Resumo do Analista: registrar as três mais importantes necessidades ou problemas. As necessidades de mais alta prioridade começarão a se repetir 10 entrevistas freqüêntemente criam somente diferentes necessidades. Deve-se manter um Repositório de Requisitos. Régis Simão 12/34

13 Entrevista Posso substituir uma entrevista por um questionário? Não!!! O contato com o cliente é fundamental, a percepção dos sentimentos dos clientes sobre os requisitos e sobre a solução. Use questionário como uma técnica para corroborar a informação. Faça entrevista como a primeira técnica de levantamento de requisitos. Faça entrevista para toda nova classe de problema e para todo novo projeto. Régis Simão 13/34

14 Workshop de Requisitos Coloque todos os stakeholders chaves juntos em um período curto e inteso de troca de idéias: não mais que 1 ou 2 dias. Brainstorm é a parte mais importante do workshop. Comece perguntando aos stakeholders: Se somente um requisito pudesse ser implementado na nova versão, qual seria? Workshop ajuda a fechar, de forma rápida, um consenso sobre os requisitos da aplicação e sobre o curso das ações: Constrói um time efetivo comprometido com o sucesso do projeto. Resolve problemas políticos. Uma versão preliminar dos requisitos é elaborada. Régis Simão 14/34

15 Workshop de Requisitos Preparação do Workshop: Venda a idéia para a organização, mostrando os benefícios da técnica Workshop. Identifique os stakeholders mais importantes que possam contribuir com o processo e de quem são as necessidades que o sistema deve implementar. Assegure a participação dos stakeholders do passo anterior. Garanta a logística para o workshop: convites apropriados, hospedagem, passagens, transporte, salas, recursos audio-visuais, coffee break, etc. Envie antecipadamente, para os participantes, material para leitura: Informações específicas de projeto: documentos de requisitos, relatório de tendências, dados sobre o mercado, etc. Preparação para fugir das práticas diárias: fugir das regras, das políticas da organização, etc. Régis Simão 15/34

16 Workshop de Requisitos Papel do Facilitador: É melhor que seja um profissional externo e experiente. Tem que ser treinado no processo de condução de reuniões. Tem que demonstrar habilidade com construção de consensos e formação de equipes. Deve ser uma pessoa que tenha o respeito do membros internos e externos. Ter uma forte formação em liderança. Não deve contribuir com idéias nem com as questões levantadas. Estabelecer um tom profissional a reunião: Começar e terminar na hora prevista Impor as regras Introduzir e gerenciar os objetivos e a agenda do encontro Régis Simão 16/34

17 Workshop de Requisitos Exemplo de Agenda: 08:00-08:30 08:30-10:00 10:00-12:00 12:00-13:00 13:00-14:00 14:00-15:00 15:00-16:00 16:00-17:00 Introdução Contexto Brainstorming Almoço Brainstorming Definição de Características/ Requisitos Redução de Idéias e priorização Fechamento das Idéias Régis Simão 17/34

18 Brainstorming Brainstorming é composto de duas etapas: Geração de idéias e Redução de idéias ( sintetização das idéias). Ajuda a tratar a síndrome "Ruínas não descobertas". Benefícios: Encoraja a participação de todos os presentes. Permite aos participantes tomarem conhecimento de todas as idéias. Um facilitador toma nota de todas as idéias. Permite uma carga alta de participação. Permite o surgimento de idéias mais livres de contexto, não presa as regras. Régis Simão 18/34

19 Brainstorming O processo de Brainstorming: Explicar inicialmente como será a reunião. Distribuir papel (Post-it) para escrita das idéias (Quant.:25). Realizar um pergunta por seção de Brainstorm: Que características/requisitos você gostaria de ver no produto? Que serviços você gostaria de ver no produto? Que coisas você gostaria que o produto possuísse? Permitir que os participantes falem suas idéias e as escrevam nos papeis. Em momentos de silêncio, repita a pergunta da mesma maneira ou de uma maneira um pouco diferente. O processo tende a ter um término natural. Régis Simão 19/34

20 Brainstorming O processo de Brainstorming: O processo de geração de idéias pode levar de 1 a 2 horas e originar em torno de 100 a 200 idéias. Já no processo de Redução de Idéias, o facilitador recolhe as idéias e as fixa na parede para que todos possam ver. Não permita comentários como: "Que idéia ruim!" e "Isso eu já tinha dito!" O facilitador passa por cada idéia perguntando se há algo a acrescentar ou é uma idéia fora do contexto do sistema. Retira as ideias fora do contexto. As ideias que têm validade ou que estão com votos contra e a favor devem ser pregadas em uma parede. As repetidas são colocadas juntas na parede. Régis Simão 20/34

21 Brainstorming O processo de Brainstorming: Pode-se pedir aos participantes para agrupar as idéias, nomeando os grupos: Novas caratecrísticas, questões de desempenho, melhoria de características, e interfaces de usuários e questões de usabilidade. Serviços aos clientes, departamento de vendas e marketing, serviços web, departamento de cobranças, etc. Para cada grupo de idéias, o processo de geração de idéias é reiniciado. Após terminar o processo de geração de idéias, o processo de Definição de Características (DC) é iniciado. No DC, o falicitador pede aos fornecedores das idéias que descrevam uma pequena descrição para cada uma das idéias. Essa descrição é apresentada e discutida com o grupos. Régis Simão 21/34

22 Brainstorming O processo de Brainstorming: Ao final, pode-se aplicar um método para priorização de idéias: Voto acumulativo: Teste dos $100 dolares. Dica: Limite um valor que pode ser pago para cada idéia. Categorização com Crítico (peso 9), Importante (peso 3) e Útil (peso 1). Dica: cada categorização só pode abranger 1/3 das idéias. Régis Simão 22/34

23 Storyboarding Consiste em apresentar para os stakeholders os esboços (croquis) de vários aspectos do sistema: Croquis das telas do sistema, mostrando adicionalmente os fluxos. Regras de negócio Algoritmos Relatórios Ajuda a identificar: os papeis (atores), o que eles podem fazer com o sistema e o que o sistema deve fazer. Trabalha a síndrome "Sim, mas " Régis Simão 23/34

24 Storyboarding Deve ser usada desde os estágios iniciais do projeto. Os croquis devem ser Simples Fáceis de criar e modificar Extremamente baratos Tipos de Storyboards Passivo: o analista passa os esboços para o cliente, explicando o que acontece com o sistema. Ativo: são automatizados ou animados. É como se o usuários estivessem vendo um filme que ainda não foi produzido. Interativo: permita que o usuário interaja (simule) com o sistema, muito similar com o a técnica de prototipágem. Pode permitir que o próprio usuário construa os croquis em tempo real. Régis Simão 24/34

25 Storyboarding Dicas para Storyboarding: Não invista muito em um croqui. Se você não mudar nada, você não aprendeu nada. Não faça o croqui muito bem feito. O cliente pode querer comprá-lo. Sempre que possível, faça o croqui interativo. Régis Simão 25/34

26 Aplicação de Use Case Identifica o quem, o o quê e o como do sistema. Um use case (UC) descreve as iterações entre um usuário e um sistema. O UC foca no o quê o sistema faz para o usuário ou no negócio do onde o sistema irá operar. Um modelo de UC consiste de todos os atores do sistema e de todos os UC com os quais os atores irão interagir. Mostra a totalidade do comportamento funcional do sistema. Os atores identificam os limites do sistemas, as entidades externas que interagem com o sistema: Papel dos usuários quando interagindo com o sistema. Hardware que interage com o sistema. Sistemas que interagem com o sistema em desenvolvimento. Régis Simão 26/34

27 Aplicação de Use Case A identificação dos atores passa anteriormente pela identificação de stakeholders e usuários do sistemas. A especificação de um UC deve ser escrita em linguagem natural, deve ser fácil de descrever e documentar. Deve ser escrita sob o ponto de vista do cliente. Trabalha-se também as interfaces que o sistema irá provê: mas os detalhes (cores, fontes e tipos de dados) destas interfaces devem ser deixados para fases posteriores. Ajuda a trabalhar a síndrome "Ruínas não descobertas". Não ajuda a endereçar requisitos não funcionais. Deve-se usar outro tipo de técnica. Régis Simão 27/34

28 Prototipagem É uma implementação parcial do software com objetivo de ajudar aos desenvolvedores, usuários e stakeholders a entender melhor os requisitos da aplicação. Ajuda a trabalhar as síndromes Sim, mas... e Ruínas não descobertas Faça prototipagem dos requisitos confusos, que embora sejam conhecidos, são fracamente definidos ou entendidos. Este técnica permite o usuário interagir e sentir o sistema como nenhuma técnica permite. Régis Simão 28/34

29 Prototipagem Tipos de protótipos: Descartável X Evolucionário Vertical (Qualidade) X Horizontal (Quantidade) Interface de Usuário X Algoritmo Requisitos X Tecnologia A escolha do tipo depende do problema que se está tratando: Somente testar a tecnologia, usa-se o tipo descartável Se pretende aproveitar o protótipo, use o tipo evolucionário Construa protótipos baratos, para justificar sua construção e não a da aplicação final. Os protótipos devem ser usados em ambientes que simulem o mais próximo possível o ambiente real. Régis Simão 29/34

30 Bibliografia: Capítulos 7, 9, 10, 11, 12, 13, 14 e 15 - Leffingwell, D. e Widrig, D., Managing Software Requirements: a unified approach. Addison-Wesley, Régis Simão 30/34

31 FIM!!! Régis Simão 31/34