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.

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
Atividades
Fundamentais
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 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 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ócio
Ator/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 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
• 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 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
• 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