Workshop de Requisitos

  • 635 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
635
On Slideshare
0
From Embeds
0
Number of Embeds
4

Actions

Shares
Downloads
0
Comments
0
Likes
4

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Workshop de Requisitos 2011 31/Jan e 01/Fev Campus da UFC em Quixadá Prof. Camilo Almendra
  • 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. Workshop de Requisitos Parte 1
  • 4. Requisitos
  • 5. Prática #1
  • 6. Requisitos de software são... um problema de COMUNICAÇÃO
  • 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. 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. 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. Requisitos e Engenharia de Software AtividadesFundamentais Projeto e Especificação Implementação Evolução/ Validação Manutenção
  • 11. Requisitos e o RUP Analista de Negócios
  • 12. Requisitos e o Scrum Dono do Produto
  • 13. Requisitos e o XP Cliente Presente
  • 14. Facilitador (!= Intermediário) Interessados Analista de Negócios Dono do Produto EquipePatrocinadores Cliente Usuários Presente
  • 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. Conversando 1. Negócio •Por quê? 2. Estrutura 3. Processos •Quem/ o quê? •Quando? •Quanto? •Como? •Onde?
  • 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. Prática #2 Por quê?
  • 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. Prática #4• Perda na tradução Dono do Produto Analista Analista Equipe
  • 21. Conversando com os clientes/usuários• Sessões de Prototipação
  • 22. Conversando com clientes/usuários• Prototipação Online
  • 23. Conversando com clientes/usuários Observação Direta
  • 24. Conversando com clientes/usuários
  • 25. Fechamento
  • 26. Gestão de Requisitos...• ... ou de Conhecimento?
  • 27. Canais de comunicação
  • 28. Próximo dia• Recolher resultado do brainstorming
  • 29. Workshop de Requisitos Parte 2
  • 30. Qualidade dos Bons Requisitos• Completo• Correto• Viável• Necessário• Priorizado• Não ambíguo• Verificável
  • 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. 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. 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. 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. Como a solução será usada? Objetivo de ... Passos ... NegócioAtor/Usuário Cenário / Caso de Uso / Estória / ...
  • 36. Atores... Pessoas?• Tipos de Atores – Humano, Sistema, Tempo, Agente, Mago• Pessoas – As mais complexas, sem dúvida!
  • 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. 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. 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. Prática #6• Foco: – Sistema Gerenciador de Eventos• Questões: FOTO – Quais usuários? – Quais papéis? – Quais atributos?
  • 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. 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. Caso de uso - Níveis NEGÓCIO/SOLUÇÃO USUÁRIO SUBFUNÇÕES
  • 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. 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. 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. 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. 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. Prática #7• Escrever 1 (um) caso de uso – Pode englobar vários itens dos requisitos• Desenvolver as especificações básicas
  • 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. Motivação
  • 52. Como funciona? representa Requisitos Cartão do Cliente Conversas Confirmações
  • 53. Foco
  • 54. Características I npendente N egociável V aliosa E stimável S mall (pequena) T estável
  • 55. Como um <PERFIL> QUEM?eu quero/devo/posso<FUNCIONALIDADE> O QUE?para <OBJETIVO DE POR QUE? NEGÓCIO>
  • 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. 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. Prática #9• Parte 2: Conversas Conversa: • Lorem •Ip´sum •Sei-que lá •Não esquecer
  • 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. Prática #10• Parte 3: Confirmações Testes: • Lorem •Ip´sum •Sei-que lá •Não esquecer
  • 61. Fechamento
  • 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. Dinâmica• Cuidado com sua linguagem!
  • 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. 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. 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. Até a próxima...• Obrigado!• Licença