Workshop de Requisitos

1,707 views

Published on

Published in: Technology

Workshop de Requisitos

  1. 1. Workshop de Requisitos 2011 31/Jan e 01/Fev Campus da UFC em Quixadá Prof. Camilo Almendra
  2. 2. Observações• Regra – Proibido uso de notebook• Horários – 31/Jan e 01/Fev – 08:30h às 11:30h – Intervalo de 10 min por volta de 10:00h• Certificados – Disponíveis na 1ª semana de aula – Atividade complementar (8 horas) – Apenas para quem compareceu aos dois dias
  3. 3. Workshop de Requisitos Parte 1
  4. 4. Requisitos
  5. 5. Prática #1
  6. 6. Requisitos de software são... um problema de COMUNICAÇÃO
  7. 7. O que são Requisitos? (BABoK 2.0)• Uma condição ou capacidade necessitada por um stakeholder para resolver um problema ou alcançar um objetivo;• Uma condição ou capacidade que deve ser atendida por uma solução (ou parte dela) para satisfazer um contrato, padrão, especificação, ou documento formal;• Um documento representando a condição ou capacidade citadas anteriormente. Ajudou em alguma coisa essa definição?
  8. 8. Tipos de Requisitos (BABoK 2.0) Requisitos de Metas, Objetivos e Necessidades da Negócio Empresa Requisitos de Necessidades de [um grupo de] Stakeholder stakeholders Requisitos de Características de uma solução para Solução atender RN e RS
  9. 9. Requisitos da Solução (BABok 2.0) Requisitos Requisitos Não- Funcionais Funcionais Características da Condições ambientais de operação solução descritas em + termos de Atributos de qualidades que devem comportamento estar presentes na solução
  10. 10. Requisitos e Engenharia de Software AtividadesFundamentais Projeto e Especificação Implementação Evolução/ Validação Manutenção
  11. 11. Requisitos e o RUP Analista de Negócios
  12. 12. Requisitos e o Scrum Dono do Produto
  13. 13. Requisitos e o XP Cliente Presente
  14. 14. Facilitador (!= Intermediário) Interessados Analista de Negócios Dono do Produto EquipePatrocinadores Cliente Usuários Presente
  15. 15. Análise de Negócios Modelagem Engenharia de Negócios de Requisitos Para ajudar a definir uma Entendendo o Entendendo o Negócio Usuário Solução para um Problema de Busca da Busca do Negócio Simplificação Detalhamento[BABok] Foco no Domínio Foco no Sistema
  16. 16. Conversando 1. Negócio •Por quê? 2. Estrutura 3. Processos •Quem/ o quê? •Quando? •Quanto? •Como? •Onde?
  17. 17. As 6 perguntas (6 W’s)• Negócios – Por quê esse negócio/projeto/sistema é importante?• Estrutura – Quem está envolvido? – Quantos recursos e pessoas? – Onde será usado?• Processos – Quando é usado? – Como.... MAIS DÍFICIL
  18. 18. Prática #2 Por quê?
  19. 19. Conversando com os clientes/usuários• Entrevista – Tradicional técnica de “coleta” – Estruturada ou não... • ... o importante é deixar que histórias sejam contadas – Bom uso: • Iniciar contatos e apresentações entre equipe e clientes/usuários • Estabelecer a visão geral do problema – Mau uso: • Ser a única forma de coleta de requisitos • Ser usada para “tirar pedidos” • Enviar o/a Analista SOZINHO
  20. 20. Prática #4• Perda na tradução Dono do Produto Analista Analista Equipe
  21. 21. Conversando com os clientes/usuários• Sessões de Prototipação
  22. 22. Conversando com clientes/usuários• Prototipação Online
  23. 23. Conversando com clientes/usuários Observação Direta
  24. 24. Conversando com clientes/usuários
  25. 25. Fechamento
  26. 26. Gestão de Requisitos...• ... ou de Conhecimento?
  27. 27. Canais de comunicação
  28. 28. Próximo dia• Recolher resultado do brainstorming
  29. 29. Workshop de Requisitos Parte 2
  30. 30. Qualidade dos Bons Requisitos• Completo• Correto• Viável• Necessário• Priorizado• Não ambíguo• Verificável
  31. 31. Conversando com clientes e usuários• Brainstorm (“Tóro de Palpites”) – Estimula o pensamento criativo sobre um problema – Aproveita a experiência e criatividade de todos os participantes – Vantagens: • Liberdade, exagero, conexões livres – Desvantagens: • Perda de foco, depende do entusiasmo dos participantes – É uma técnica. Não é bagunça! Preparação Sessão Análise
  32. 32. Prática #3• Preparação Brainstorm – Problema: • Gerenciar eventos – Foco da sessão: • Quais funções o sistema precisa apresentar para suportar as necessidades de Organizadores e Participantes? – 1 ou 2 escribas por equipe• Sessão – 15 minutos – Regras: • Não julgue, tudo é válido • Melhore a idéia do colega do lado • Quantidade! Muitas idéias!
  33. 33. Conversando com clientes e usuários• Análise do Brainstorm (prática na parte 2)• 6 chapéus do pensamento – Branco • Fatos, números, objetividade – Vermelho • Emoções, sentimentos, INTUIÇÃO – Preto • Falhas, barreiras, incompatibilidade – Amarelo • Positivo, benefícios, compatibilidade – Verde • Criatividade, provocação, investigação (“sessão”) – Azul • Pensamento sobre o pensamento, organização, condução
  34. 34. Prática #5• Análise do Brainstorm da parte 1• 6 chapéus do pensamento (5 minutos/ chapéu) – Branco • Fatos, números, objetividade – Vermelho • Emoções, sentimentos, INTUIÇÃO – Preto • Falhas, barreiras, incompatibilidade – Amarelo • Positivo, benefícios, compatibilidade – Verde • Criatividade, provocação, investigação (“sessão”) – Azul • Pensamento sobre o pensamento, organização, condução
  35. 35. Como a solução será usada? Objetivo de ... Passos ... NegócioAtor/Usuário Cenário / Caso de Uso / Estória / ...
  36. 36. Atores... Pessoas?• Tipos de Atores – Humano, Sistema, Tempo, Agente, Mago• Pessoas – As mais complexas, sem dúvida!
  37. 37. Quem?• Quais são os clientes da solução?• Quais são os usuários? – É possível para falar com todos? – São muitos? – E se for um produto novo?• Modelagem de Papéis de Usuário – Brainstorm – Organização – Consolidação – Refinar
  38. 38. Brainstorming• Um papel é um usuário Organização • Quais papéis possuem interseção? Consolidação • 100% de interseção = 1 papel de usuário • Parcial = generalização/ especialização Refinamento • Atributos, fatos, dados, informações
  39. 39. Personas• Representação imaginária para um papel – Papel que represente muitos usuários – Múltiplas personas para mesmo papel• Cada persona... – possui um nome – uma foto (!) – e descrição de hábitos, motivações, expectativas, objetivos.• Equipe deve sentir que “conhece” as personas• Baseado em dados quantitativos e qualitativos – Apesar de ser uma técnica bem subjetiva
  40. 40. Prática #6• Foco: – Sistema Gerenciador de Eventos• Questões: FOTO – Quais usuários? – Quais papéis? – Quais atributos?
  41. 41. Caso de Uso “Um caso de uso captura um contrato entre os stakeholders de um sistema, relativo ao seu comportamento. O caso de uso descreve o comportamento do sistema sob diversas condições, na medida em que o sistema responde a requisições de um dos stakeholders, chamado ator primário.” Alistair Cockburn Writing Effective Use Cases, 2001
  42. 42. Caso de Uso• Casos de uso são puro COMPORTAMENTO – Casos de uso não dizem COMO, dizem apenas O QUÊ o sistema faz• Ferramenta poderosa – Linguagem natural = flexibilidade – Pode ser usado para modelar processos de negócios, projeto de sistema, requisitos funcionais – Tanto de maneira casual como formal
  43. 43. Caso de uso - Níveis NEGÓCIO/SOLUÇÃO USUÁRIO SUBFUNÇÕES
  44. 44. Modelo de Caso de Uso• Após identificação inicial de casos de uso• Identificar relacionamentos entre casos de uso – Facilita entendimento – Facilita reuso e manutenção• 3 tipos de relacionamentos – <includes> – <extends> – <inherits>
  45. 45. Modelo de Caso de Uso• Relação de Inclusão – Uma parte de um caso de uso base pode ser encapsulada como um caso de uso adicional, e o caso de uso base somente depende do resultado do adicional Caso de Uso Base inclui Caso de Uso Adicional
  46. 46. Modelo de Caso de Uso• Relação de Extensão – Uma parte de um caso de uso base é opcional ou não- importante para o entendimento do principal objetivo, sendo assim encapsulada em um caso de uso adicional Caso de Uso Adicional estende Caso de Uso Base
  47. 47. Modelo de Caso de Uso• Relação de Herança – Casos de uso que compartilham comportamento comum, estrutura ou objetivo Caso de Uso Filho herda Caso de Uso Pai
  48. 48. Estrutura básica• Ator – Usuário/stakeholder que executa a funcionalidade• Objetivo (título) – O que o ator vai alcançar ao executar esse caso de uso• Fluxo principal – Passos principais para executar a funcionalidade• Fluxo alternativo – Exceções que podem ocorrer no fluxo principal• Pré-condições – Condições obrigatórias para que o caso de uso seja executado• Pós-condições – Condições esperadas após a execução com êxito do caso de uso
  49. 49. Prática #7• Escrever 1 (um) caso de uso – Pode englobar vários itens dos requisitos• Desenvolver as especificações básicas
  50. 50. O que são Estórias? Estória de Usuário Descrição Conversas Confirmações (Cartões) Planejamento Documentar Detalhes Expor Detalhes Lembrete Definir o “Pronto”
  51. 51. Motivação
  52. 52. Como funciona? representa Requisitos Cartão do Cliente Conversas Confirmações
  53. 53. Foco
  54. 54. Características I npendente N egociável V aliosa E stimável S mall (pequena) T estável
  55. 55. Como um <PERFIL> QUEM?eu quero/devo/posso<FUNCIONALIDADE> O QUE?para <OBJETIVO DE POR QUE? NEGÓCIO>
  56. 56. Prática #8• Parte 1: Cartões (Descrição da Estória de Usuário) Blá blá blá blá blé blu blo lorem ipsum
  57. 57. Conversas• Notas importantes• Ajudam a definir os limites da estória• Sem exagero de detalhesUm cliente pode fechar o pedido Um cliente pode fechar o pedidopagando com cartão de crédito pagando com cartão de créditoNota: aceitar MasterCard, Visa, Nota: aceitar MasterCard, Visa,Hipercard; Débito e Crédito. Hipercard; Débito e Crédito; Aceitar parcelamento em até 12x (se compra acima de R$100 ,00); Sistema guarda número cartão para uso futuro; Compras acima de R$200,00, pedir (...)
  58. 58. Prática #9• Parte 2: Conversas Conversa: • Lorem •Ip´sum •Sei-que lá •Não esquecer
  59. 59. Confirmações• Como o sistema será avaliado pelo cliente• Critérios de aceitação da entregaUm cliente pode fechar o pedido pagando com cartão decréditoNota: aceitar MasterCard, Visa, Hipercard; Débito e Crédito. Testes: • Usar Visa, MasterCard e Hipercard (ok) • Usar American Express (falha) • Entrar c/ números de cartões inválidos ou incompletos (falha) • Entrar com cartões expirados • Valores de compra distintos, incluindo valor acima do limite do cartão
  60. 60. Prática #10• Parte 3: Confirmações Testes: • Lorem •Ip´sum •Sei-que lá •Não esquecer
  61. 61. Fechamento
  62. 62. Hipóteses, não axiomas• Axioma – “um axioma ou postulado é uma sentença ou proposição que não é provada ou demonstrada e é considerada como óbvia ou como um consenso”• Hipótese – “é uma formulação provisória, com intenções de ser posteriormente demonstrada ou verificada, constituindo uma suposição admissível”• Requisitos não são axiomas!• Requisitos são meras hipóteses até que sejam testados!
  63. 63. Dinâmica• Cuidado com sua linguagem!
  64. 64. Espero que você tenha aprendido que...• Não se deve confiar demais em um documento – mesmo que você seja o próprio autor• O foco é em Software rodando – requisitos são apenas um meio• Que qualquer software faz parte de um ecossistema complexo – de pessoas, processos, outros sistemas• Requisitos tem tudo a ver com comunicação e gestão de conhecimento• Que você ainda tem muito a aprender sobre isso!
  65. 65. Uma pequena ação Que pequena ação (coisa) você pode se comprometer a fazer? Algo que você possa fazer hoje mesmo? Escreva no cartão (para si mesmo)!
  66. 66. Referências Principais User Stories Applied, Mike Cohn Subject to Change: creating great products and services, Adaptive Path Engenharia de Software, Ian Sommerville Escrevendo Casos de Uso Eficazes, Alistair Cockburn A Guide to the BABoK 2.0, IIBA (breve em português)
  67. 67. Até a próxima...• Obrigado!• Licença

×