![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](https://image.slidesharecdn.com/workshopderequisitos2010-120913130112-phpapp01/85/Workshop-de-Requisitos-8-320.jpg)
![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](https://image.slidesharecdn.com/workshopderequisitos2010-120913130112-phpapp01/85/Workshop-de-Requisitos-15-320.jpg)
Carregado porCamilo Almendra
Workshop de Requisitos
Este documento resume um workshop sobre requisitos de software realizado nos dias 31 de janeiro e 1o de fevereiro. O workshop foi dividido em duas partes, abordando conceitos como tipos de requisitos, técnicas para elicitação como brainstorming e casos de uso, e estórias de usuário.
Workshop de Requisitos
- 1. Workshop de Requisitos2011 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.
- 5.
- 6. Requisitos de softwaresão... um problema de COMUNICAÇÃO
- 7. O que sãoRequisitos? (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 Engenhariade Software Atividades Fundamentais Projeto e Especificação Implementação Evolução/ Validação Manutenção
- 11. Requisitos e oRUP Analista de Negócios
- 12. Requisitos e oScrum Dono do Produto
- 13. Requisitos e oXP Cliente Presente
- 14. Facilitador (!= Intermediário) Interessados Analista de Negócios Dono do Produto Equipe Patrocinadores 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 osclientes/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 • Perdana tradução Dono do Produto Analista Analista Equipe
- 21. Conversando com osclientes/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.
- 25.
- 26. Gestão de Requisitos... •... ou de Conhecimento?
- 27.
- 28. Próximo dia • Recolherresultado do brainstorming
- 29. Workshop de Requisitos Parte 2
- 30. Qualidade dos BonsRequisitos • Completo • Correto • Viável • Necessário • Priorizado • Não ambíguo • Verificável
- 31. Conversando com clientese 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çãoBrainstorm – 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 clientese 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álisedo 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çãoserá usada? Objetivo de ... Passos ... Negócio Ator/Usuário Cenário / Caso de Uso / Estória / ...
- 36. Atores... Pessoas? • Tiposde Atores – Humano, Sistema, Tempo, Agente, Mago • Pessoas – As mais complexas, sem dúvida!
- 37. Quem? • Quais sãoos 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áriapara 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 Casode 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 Casode 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 Casode 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 Casode 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 • Escrever1 (um) caso de uso – Pode englobar vários itens dos requisitos • Desenvolver as especificações básicas
- 50. O que sãoEstórias? Estória de Usuário Descrição Conversas Confirmações (Cartões) Planejamento Documentar Detalhes Expor Detalhes Lembrete Definir o “Pronto”
- 51.
- 52. Como funciona? representa Requisitos Cartão do Cliente Conversas Confirmações
- 53.
- 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 • Parte1: 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 detalhes Um cliente pode fechar o pedido Um cliente pode fechar o pedido pagando com cartão de crédito pagando com cartão de crédito Nota: 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 • Parte2: Conversas Conversa: • Lorem •Ip´sum •Sei-que lá •Não esquecer
- 59. Confirmações • Como osistema será avaliado pelo cliente • Critérios de aceitação da entrega Um cliente pode fechar o pedido pagando com cartão de crédito Nota: 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 • Parte3: Confirmações Testes: • Lorem •Ip´sum •Sei-que lá •Não esquecer
- 61.
- 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